Any ramblings and blog posts associated with the UNISA ICT 2622 tag should be considered study notes for my lectures…
Objectives of Chapter 8
Prioritize the system requirements based on the desired scope and level of automation for the new system Describe the strategic decisions that integrate the application deployment environment and the design approach for the new system Determine alternative approaches for system implementation Evaluate and select an implementation approach based on the needs and resources of the organization Describe key elements of a request for proposal (RFP) and evaluate vendors proposals for outsourced alternatives Develop a professional presentation of findings to management. Key Words & Definitions application deployment environment – the configuration of computer equipment, system software, and networks for the new system. development environment – the programming languages, CASE tools, and other software used to develop application software facilities management – the outsourcing of all data processing and information technology to outside vendor packaged software – software that is already built and can be purchased as a package turnkey system – a complete system solution, including software and hardware, that can be turned over to the purchasing organization request for proposal (RFP) – a formal document, containing details on the system requirements, sent to vendors to request that they bid on supplying hardware, software, and/or support services benchmark – an evaluation of a system against some standard Example Questions for the Chapter What is meant by application deployment environment? Why is it important in the consideration of a developmental approach? Explain the fundamentals of facilities management What is meant by ERP? How does an ERP approach affect acquiring a new solution? Deciding on Scope & Level of Automation Prioritizing requirements includes tasks to define both the scope and the level of automation for the system.
Controlling a Projects Scope
A common problem with development projects is scope creep. One way to reduce scope creep is to formalize the process to identify, categorize, and prioritize the functions that will be included within the system. The team needs to decide which functions are critical and need to be included and which can be deferred until later.
Predictive projects are less prone to scope creep while due to the nature of adaptive projects scope creep is easier to occur.
Determining the Level of Automation
Usually the level of automation can be defined in three categories…
low – system only provides simple record keeping medium –combination from the high level & low level high – system takes over as much as possible Selecting Alternatives
After identified functions have been prioritized and the levels of automation have been analyzed, the project team reviews all the alternatives. The following list helps identify some of the key criteria used in the evaluation…
Strategic Plan – does the feature fall in line with the overall strategic plan Economic Feasibility – Higher levels of automation cost more Schedule & Resource Feasibility – Higher levels of automation take longer to implement and require more resources Technological Feasibility – Higher levels of automation make bigger demands on technology Operational, Organizational, and Cultural Feasibility – Changes in business process involve risk – higher automation leads to more risk Feasibility Factors – economic, schedule, resource, technological, organizational feasibility and risk are used to evaluate the initial feasibility of a project and the feasibility of each alternative.
Defining the Application Deployment Environment Application deployment environment is the configuration of computer equipment, system software, and networks for the new system. One of the primary considerations in developing a new information system is the application deployment environment.
Hardware, System Software, And Networks
When choosing or defining the deployment environment, analysts are concerned with several important characteristics including the following…
Compatibility with System Requirements Compatibility among Hardware and System Software Required Interfaces to External Systems Conformity with the IT Strategic Plan & Architecture Plan Cost & Schedule Development Tools
The development environment are the programming languages, CASE tools, and other software used to develop application software.
The deployment environment usually restricts choosing the development environment – i.e. if the client machines are Linux based you will probably not develop in .Net.
Application deployment environment choices, particularly the operating system, DBMS, and distributed software standard tend to limit the development environment tools.
Choosing Implementation Alternatives Once the requirements are defined & decisions are made on the level of automation necessary, implementation of the system needs to be determined. There are several alternatives…
Facilities management or Service provider Solutions Turnkey or Packaged Solutions Enterprise Resource Planning Solutions Custom-built solutions Facilities Management or Service Provider Solution
Facilities management is the outsourcing of all data processing and information technology to outside vendor. It is not an actual development technique or implementation alternative but more a strategic decision. Usually this decision is made by top level management.
Service Provider Solutions is when a company only buys the required services. No in-house computing capability is required. i.e. hosting a website.
With both facilities management and service provider solutions, the company depends entirely on outside providers.
Packaged, Turnkey Software & ERP Systems
A packaged software is software that is already built and can be purchased as a package. The definition implies that the software is used as is, with no modifications.
A turnkey system is a complete system solution, including software and hardware, that can be turned over to the purchasing organization. Basically the company gets the hardware and the software all set up and all they need to do is “turn it on”. One problem with turnkey solutions is that they often do not exactly meet the needs of an organization, and the business usually needs to modify they way it works to suit the software.
Custom-Built Software Systems
Custom built software are those that are developed partly or completely by an outside organization and tailored to the exact needs of the business. The new system is developed from scratch. The advantage is the software once implemented should meet the exact needs of the organization. The disadvantage is the time and cost to implement custom built software systems.
Selecting an Implementation Alternative
Selecting a new system is not just a matter of “make” or buy” or “outsourcing”. There are many combinations of implementations and support approaches to consider.
It is important that the criteria are well established for evaluating the best approach.
There are 3 major areas to consider in selecting an implementation alternative:
General requirements Technical requirements Functional requirements The following list identifies several criteria that can be included under general requirements…
Performance record of the provider Level of technical support from the provider Availability of experienced staff Development cost Expected value of benefits Length of time until deployment Impact on internal resources Requirements for internal expertise Organizational impacts Expected cost of data conversion Warranties and support services from outside vendor The following list identifies several criteria that can be included under technical requirements…
Robustness Programming errors Quality of code Documentation Ease of installation Flexibility Structure User-friendliness Performance Scalability Compatibility with operating environment Functional requirements would be identified based on the business needs.
Contracting with Vendors A Request for proposal (RFP) is a formal document, containing details on the system requirements, sent to vendors to request that they bid on supplying hardware, software, and/or support services. Often this is the best way to get a selection of alternatives to choose from.
Generating a RFP
Use of RFP’s is almost universal in government contracts. The project manager has primary responsibility for developing the RFP and evaluating submitted proposals. A RFP is often considered to be a contractual offer, and a vendor’s response represents an acceptance of that offer.
The RFP should clearly state the procedural requirements for submitting a valid proposal. For more detail on RFP’s see pages 305 & 306 of the book.
Benchmarking and choosing a vendor
Some applications are possible to benchmark. To benchmark a system is to evaluate the system against some standard.
If benchmarking is not possible, it is also possible to evaluate the system in other ways including seeing other implementations of the systems onsite, interviewing existing businesses that use the system etc.
Developing a contract
After a final decision is made, a contract is written.
Contracts can be divided into several types which sift the risk either to the purchaser or the vendor. Fixed value contracts put the most risk on the vendor. To compensate for this risk, the vendor usually hikes the price.
