To understand system development, we need to recognize that a candidate system has a life cycle, much like a living system or a new product. Systems analysis and design are based to the system life cycle. According to Dennis, Wixom, and Tegarden(2009) “the systems development life cycle (SDLC) is the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users.” The stages are described below. The analyst must progress from one stage to another methodically, answering key questions and achieving results in each stage.
Step 1: Recognition of Need – What is the Problem?
One must know what the problem is before it can be solved. The basis for a candidate system is recognition of a need for improving an information system or a procedure. For example, a supervisor may want to investigate the system flow in purchasing. Or a bank president has been getting complaints about the long lines in the drive – in. This need leads to a preliminary survey or an initial investigation to determine whether an alternative system can solve the problem. It entails looking into the duplication of effort bottlenecks, inefficient existing procedures, or whether parts of the existing system would be candidates for computerization. If the problem is serious enough, management may want to have an analyst look at it, such an assignment implies a commitment, especially if the analyst hired from the outside. In larger environments, where formal procedures are the norm, the analyst’s first task is to prepare a statement specifying the scope and objective of the problem. He/she then reviews it with the user for accuracy at this stage, only a rough “ball parle” estimate of the development cost of the project may be reached. However, an accurate cost of the next phase – the feasibility study – can be produced.
Step 2: Feasibility Study
Depending on the results of the initial investigation, the survey is expanded to a more detailed feasibility study. As we shall learn, a feasibility study is a test of a system proposal according to its workability impact on the organization, ability to meet user needs, and effective use of resources. It focuses on there major questions:
- What are the user’s demonstrable needs and how does a candidate system meet them?
- What resources are available for given candidate systems? Is the problem worth solving?
- What are the likely impact of the candidate system on the organization? How will it fit within the organization’s master MIS plan?
Each of these questions must be answered carefully. They revolve around investigation and evaluation of the problem, identification and description of candidate systems, specification of performance and the cost of each system, and final selection of the best system.
The objective of a feasibility study is not to solve the problem but to acquire a sense of its scope. During the study, the problem definition is crystallized and aspects of the problem to be included in the system are determined. Consequently, costs and benefits are estimated with greater accuracy at this stage.
The result of the feasibility study is a formal proposal. This is simply a report – a formal document detailing the nature and scope of the proposed solution. The proposal summarizes what is known and what is going to be done. It consists of the following.
- Statement of the Problem – a carefully worded statement of the problem that led to analysis.
- Summary of Findings and Recommendations – a list of the major findings and recommendations of the study. It is ideal for the user who required quick access to the results of the analysis of the system under study. Conclusions are stated, followed by a list of the recommendations and a justification for them.
- Details of Findings – An outline of the methods and procedures undertaken by the existing system, followed by coverage of objectives & procedures of the candidate system. Included are also discussions of output reports, file structures, and costs and benefits of the candidate system.
- Recommendations and Conclusions – special recommendations regarding the candidate system, including the personal assignments costs, project schedules, and target dates.
Three key considerations are involved in the feasibility analysis: economic, technical, behavioural. Let’s briefly review each consideration and how it relates to the systems effort.
- Economic Feasibility: Economic analysis is the most frequently used method for evaluating the effectiveness of a candidate system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. Otherwise, further justification or alterations in the proposed system will have to be made if it is to have a chance of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle.
- Technical Feasibility: Technical feasibility centers around the existing computer system (hardware, software etc.) and to what extent it can support the proposed addition. For example, if the current computer is operating at 80 per cent capacity – an arbitrary ceiling – then running another application could overload the system or require additional hardware. This involves financial considerations to accommodate technical enhancements. If the budget is a serious constraint, then the project is judged not feasible.
- Behavioural Feasibility: People are inherently resistant to change, and computers have been known to facilitate change. An estimate should be made of how strong a reaction the user staff is likely to have towards the development of a computerized system. It is common knowledge that computer installations have something to do with turnover, transfers, retraining, and changes in employee job status. Therefore, it is understandable that the introduction of a candidate system requires special effort to educate, sell, and train the staff on new ways of conducting business.
After the proposal is viewed by management it becomes a formal agreement that paves the way for actual design and implementation. This is a crucial decision point in the life cycle. Many projects die here, whereas the more promising ones continue through implementation. Changes in the proposal are made in writing, depending on the complexity, size, and cost of the project. It is simply common sense to verify changes before committing the project to design.
Step 3: Analysis
It is a detailed study of the various operations performed by the system and their relationship within and outside of the system. A key question is – what must be done to solve the problem? One aspect of analysis is defining the boundaries of the system and determining whether or not a candidate system should consider other related systems. During analysis, data are collected on available files, decision points, and transactions handled by the present system. We shall learn about some logical system models and tools that are used in analysis. It requires special skills and sensitivity to the subjects being interviewed. Bias in data collection and interpretation can be problem. Training, experience and common sense are required for collection of the information needed to do the analysis. Once analysis is completed the analyst has a firm understanding of what is to be done. The next step is to decide how the problem might be solved. Thus, in the systems design, we move from the logical to the physical aspects of the life cycle.
Step 4: Design
The most creative and challenging phase of the system life cycle is system design. The term design describes both a final system and a process by which it is developed. It refers to the technical specifications (analogous to the engineer’s blueprints) that will be applied in implementing the candidate system. It also includes the constructions of programs and programme testing. The key question here is – How should the problem be solved?.
The first step is to determine how the output is to be produced and in what format. Samples of the output (and input) are also available. Second, input data and master files (data base) have to be designed to meet the requirements of the proposed output. The operational (processing) phase are handled through programe construction and testing, including a list of the programmes needed to meet the system’s objectives and complete documentation. Finally, details related to justification of the system and an estimate of the impact of the candidate system on the user and the organization are documented and evaluated by management as a step toward implementation.
The final report prior to the implementation phase includes procedural flowcharts, record layouts, report layouts, and a workable plan for implementing the candidate system. Information on personnel, money, hardware, facilities and their estimated cost must also be available. At this point, projected costs must be close to actual costs of implementation.
In some firms, separate groups of programmer do the programming whereas other firms employ analyst programmers who do analysis and design as well as code programmes. For this discussion, we assume that analysis and programming is carried out by two separate persons. There are certain functions, though, that the analyst must perform while programes are being written operating procedures and documentation must be completed. Security and auditing procedures must also be developed.
Step 5: Testing
No system design is ever perfect. Communication problems, programmers negligence or time constraints create errors that most be eliminated before the system is ready for user acceptance testing. A system is tested for online response, volume of transactions, stress, recovery form failure and usability. Then comes system testing, which verifies that the whole set of programs hangs together, following system testing is acceptance testing or running the system with live data by the actual use.
System testing requires a test plan that consists of several key activities and steps for programs, string, system and user acceptance testing. The system performance criteria deal with turnaround time, backup, file protection, and the human factor.
Step 6: Implementation
This phase is less creative than system design. It is primarily concerned with user training, site preparation, and file conversion. When the candidate system is linked to terminals and remote sites the telecommunication network and tests of the network along with the system are also included under implementation.
During the final testing, user acceptance is tested, followed by user training. Depending on the nature of the system, extensive user training may be required, conversion usually takes place at about the same time the user is being trained or later.
In the extreme, the programmer is falsely viewed as someone who ought to be isolated from other aspects of system development. Programming is itself design work, however. The initial parameter of the candidate system should be modified as a result of programming efforts. Programming provides a “reality test” for the assumptions made by the analyst. It is therefore a mistake to exclude programmers from the initial system design. System testing checks the readiness and accuracy of the system to access, update and retrieve data from new files. Once the programmes become available, test data are read into the computer and processed against the file(s) provided for testing. If successful, the program(s) is then run with “live” data. Otherwise, a diagnostic procedure is used to local and correct errors in the program. In most programs, a parallel run is conducted where the new system runs simultaneously with the ‘old’ systems. This method, though costly, provides added assurance against errors in the candidate system and also gives the user-staff an opportunity to gain experience through operation. In some cases, however, parallel processing is not practical. For example, it is not plausible to run two parallel online point-to-sale (POS) systems for a retail chain. In any case, after the candidate system proves itself, the old system is phased out.
Step 7: Evaluation
During systems testing, the system is used experimentally to ensure that the software does not fail. In other words, we can say that it will run according to its specifications and in the way users expect. Special test data are input for processing, and the results examined. A limited number of users may be allowed to use the system so that analyst can see whether to use it in unforeseen ways. It is desirable to discover any surprises before the organization implements the system and depends on it.
Implementation is the process of having systems personnel check out and put new equipment into use, train users, install the new application and construct any files of data needed to use it. This phase is less creative than system design. Depending on the size of the organisation that will be involved in using the application and the risk involved in its use, systems developers may choose to test the operation in only one area of the Firm with only one or two persons. Sometimes, they will run both old and new system in parallel way to compare the results. In still other situations, system developers stop using the old system one day and start using the new one the next.
Evaluation of the system is performed to identify its strengths and weaknesses. The actual evaluation can occur along any one of the following dimensions:
- Operational Evaluation: Assessment of the manner in which the system functions, impact.
- Organizational Impact: Identification and measurement of benefits to the organisation in such areas as financial concerns, operational efficiency and competitive impact.
- User Manager Assessment: Evaluation of the attitudes of senior and user manager within the organisation, as well as end-users.
- Development Performance: Evaluation of the development process in accordance with such yardsticks as overall development time and effort, conformance to budgets and standards and other project management criteria.
Step 8: Post – Implementation and Maintenance
Maintenance is necessary to eliminate errors in the working system during its working life and to tune the system to any variations in its working environment. Often small system deficiencies are found as a system is brought into operation and changes are made to remove them. System planners must always plan for resource availability to carry out these maintenance functions. The importance of maintenance is to continue to bring the new system to standards.
After the installation phase is completed and the user staff is adjusted to changes created by the candidate system, evaluation and maintenance being. Like any system there is an ageing process the requires periodic maintenance of hardware & software. If the new information is inconsistent with the design specifications, then changes have to be made. Hardware also requires periodic maintenance to keep in time with design specification. The importance of maintenance is to continue to bring the new system to standards.