System Development Life Cycle

Lecture 3 By Mamoon Al Rasheed Department of CSE, SUB

System Development Life Cycle

Every system has a life cycle. An information system is born when a problem is recognized. After the system is developed, it grows until it reaches maturity. Eventually, a change in the nature of the problem or increasing maintenance costs degrade the value of the system, so it dies and a new or replacement system is born to take its place.

System Development Life Cycle Development Life Cycle is a System

methodology. A key purpose of a methodology is ensuring that nothing is overlooked in the process of solving a complex problem (such as developing a complex information system). A methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. Often, a methodology is implemented as a

Impetus for change

New employment compensation may make it necessary to change the reporting procedure, or file structures. An organization acquires another organization. A local bank branches into the suburbs. A Department spends 80% of its budget in one month. Two departments are doing essentially the same work, and each department head insists that the other department should be eliminated.

Impetus for change

A request for a new form discloses the use of bootleg forms. Top management suspects various report ( suspicion of transparency ). Heads of different departments inquire about the delays in service delivery. Documentation of various activities cannot be found.

System Development Life Cycle

Motivation behind the feasibility study: The risks and potential returns. Managements bias toward the user. Financial cost and the funds available for system work. Priorities of other projects in the firm. The persuasive ability of the user.

The feasibility study

It 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 three major questions: What are the users demonstrable needs and how does a candidate system meet them? What resources are available for given candidate systems? Is the problem worth

The result of the feasibility study summarizing what is known and It is a proposal
what is going to be done. It consists : Statement of the problem- a carefully worded statement of the problem that led to analysis. Summary of findings and recommendations- a list of major findings and recommendations of the study. Details of findings. Recommendations and conclusions.

System Development Life Cycle definition The first step in the system Problem
development life cycle during which the problem is identified, its cause determined, and a strategy for solving it developed. Analysis To attack a problem by breaking it into sub-problems. The second step in the system development life cycle (following problem definition) during which the responsible people determine exactly what must be done to solve the problem.

System Development Life Cycle

Problem definition The first step in the system development life cycle during which the problem is identified, its cause determined, and a strategy for solving it developed. Problem may include the duplication of effort, bottlenecks, inefficient existing procedures, or whether parts of the existing system would be candidates for computerization. The analysts first task is to prepare a statement specifying the scope and objective of the problem. S/he then reviews it with the user. This may be

System Development Life Cycle The third step in the system development Design
life cycle (following analysis and preceding development) during which the responsible people determine how the problem will be solved by specifying the systems physical components. Development The fourth step in the system development life cycle (following design and preceding testing) during which the system is created.

System Development Life Cycle

Testing The fifth step in the system development life cycle (following development and preceding implementation) intended to ensure that the system does what it was designed to do. Implementation The sixth step in the system development life cycle (following testing and preceding maintenance) during which the system is installed and released to the user. Maintenance The final step in the system development life cycle (following

Stages

Key Question

Result

1. Recognition of Need: What is the a. Statement of scope and Preliminary survey/initial problem or opportunity ? objectives Investigation b. Performance criteria 2. Feasibility Study a. What are a. Technical/ users a. Evaluation of existing Behavioural system or procedure demonstrable Feasibility b. Analysis of need? b. Cost/benefit alternative candidate b. Is the analysis systems problem c. Cost Estimates worth solving? c. How can the problem be

Stages

Key Question

Result

3. Analysis: What must be Logical model of Detailed evaluation of done to solve the system (Data the problems? Flow diagram, present system. Facts? Data Data collection dictionary etc.) 4. Design (general and detailed specification) a) Output b) Input c) Files d) Procedures How must Design of problem be alternative solved? What Solutions is the system Final cost/benefit flow? Analysis Hardware specification Cost estimates

Stages

Key Question

Result

5. Testing How well do the Testing plans a. Unit testing program/module Security, audit and b. Combined moduletest out? operating testing procedures How ready are c. User acceptance Programs for Actual hardware testing use acceptance test? Formal system Test 6. Implementation User training File/System conversion What is the actual operation? Are the user manual ready? Training program User-friendly documentation

Stages

Key Question Result

6. Posta) Is the system User requirements Implementation running met and Maintenance properly? Satisfied User a. Problem Solving b) Should the system be b. Enhancements modified?

Project Termination
A systerm project may be dropped at any time prior to implementation although it becomes more difficult and costly when it has passed the design phase. Reasons may include: Changing objectives or requirements of the user cannot be met by the existing design. Benefits realized from the candidate system do not justify commitment to implementation.

Project Termination
There is a sudden change in the users budget or an increase in design costs beyond the estimate made during the feasibility study. The project greatly exceeds the time and cost schedule. In each case described above, a system project may be terminated at the users request.

System failure

System failure
There are many reasons a new system does not meet user requirements: Users requirements were not clearly defined or understood. The user was not directly involved in the crucial phases of system development. The analyst, programmer, or both were inexperienced.

System failure
The systems analyst (or the project team) had to do the work under stringent time limitations. Consequently, not enough went into the feasibility study and system design. User training was poor. Existing hardware proved deficient to handle the new application. The new system was not user-friendly.

System failure
The new system left users in other departments out of touch with information that the old system had provided. Users changed their requirements. The user staff was hostile. Besides these, there may be other causes. The important point is that the analyst, with his latest software and hardware, still needs experience, creative ability, knowledge and support from users.

Considerations for candidate systems

The basic problem is to match the demands for services with available resources. How much one project is favored over another depends on technical, behavioral and economic factors. Technical factors: is the system departments ability to handle a project. It depends on the availability of qualified analysts, designers and software

Considerations for candidate systems

Behavioral factors: The users past experience with an existing system. The success record of the analyst. The influence the user can exert on upper management to finance a candidate system. Economic factors: The systems potential for return on investment. Cost effectiveness of the proposed system.

Considerations for candidate systems

Political factors: Politics is the art of using influence and building coalitions when routine procedures do not achieve the right results. In developing a system one should focus on: convincing the right people to gather support. achieving a collaborative relationship with the end user. anticipating resistance early and turning into support.

Prototyping
A preliminary, working, physical model of a system or a subsystem. The analysts objective is to gather information about the users requirements from the bottom up by allowing the user to interact with the prototype. In effect, the prototype serves as a preliminary version of the system or component from which requirements are extracted and on which subsequent versions are based.

Prototyping
Prototyping is a powerful, bottom up alternative or supplement to logical modeling. The basic idea is to build a reasonably complete, working, physical model (or prototype) of the system. As a minimum, the analyst can use screen painters, menu builders, and report generators to prepare a slide show of sample screens, dialogues and reports. In a more complete prototype, preliminary

Prototyping
The prototyping process can be viewed as a loop. Following problem definition and preliminary analysis, a first draft of the prototype is created. The user then interacts with the prototype and identifies its strengths and weaknesses. Assuming that the first draft is less than totally acceptable, the prototype is modified to reflect the users suggestions and the user interacts with the new, improved version. The refine-and-test cycle continues until

Prototyping
Prototyping is iterative. The process starts with a set of partial requirements, and new or expanded requirements are continuously incorporated into the system based on user feedback. During the refine-and-test cycle, the emphasis is on quick turnaround, with changes made on the spot or within at most a few days. Instead of conceptualizing needs, the users work with and react to the prototype and the analyst observes and interprets their reactions. To many people, manipulating a working model seems more natural than answering questions in an interview or trying to link an abstract model to reality. Sometimes, the prototyping process continues until a finished system emerges.

Prototyping
Advantages: During the analysis stage, prototyping can be used to replace or supplement logical modeling, particularly when the users are uncomfortable with abstract models. Prototyping is valuable on projects with long development times because the user gets to see something physical. Prototyping is an excellent tool when the requirements are highly uncertain or too abstract to specify, or when no comparable system has been previously developed. Generally, if reaching a solution calls for simulation, experimentation, or

Prototyping
Disadvantages: Creating a large, complex system from the bottom up can be very difficult, and integrating subsystem prototypes can prove almost impossible because there is no clear way (short of a parallel top-down logical or data model) to visualize subsystem relationships. Prototyping is not a good choice for algorithm-driven projects that involve heavy calculation.

Prototyping
Disadvantages: Prototyping can bias the systems analysis process in subtle ways. Because the prototype is developed on a computer, the system will almost certainly be implemented on a computer and manual alternatives are unlikely to be considered. Because it is a working model, people will inevitably think of the prototype as the solution. A related danger is that the system will never be developed properly because the prototype seems too good.

Prototyping
Disadvantages: Prototypes generally lack security, auditing, and other controls and data integrity may be difficult to ensure. Additionally, prototypes are often inefficient and difficult to maintain. For example, it is difficult to trace the ripple effects that result from modifying a prototype, and that affects maintainability. Economy of scale is another problem; prototypes that