toc ch2>

1 The systems development life cycle

1.1 Purpose
1.2 Strengths, weaknesses, and limitations
1.3 Inputs and related ideas
1.4 Concepts
1.4.1 Information systems
1.4.2 The system life cycle
1.4.3 Methodologies
1.4.4 The waterfall method
1.5 Key terms
1.6 Software
1.7 References

1.1 Purpose

The purpose of a methodology is to specify a set of well-defined steps or phases, coupled with a set of clear, measurable exit criteria, for solving a complex problem (such as developing an information system). The system development life cycle (SDLC) is a set of steps that serves as the basis for most systems analysis and design methodologies.

1.2 Strengths, weaknesses, and limitations

A methodology (such as the system development life cycle) acts as a memory aid by imposing discipline, thus reducing the risk that key details will be overlooked. Communication is enhanced because the methodology imposes a consistent set of documentation standards. The steps in the methodology enhance management control, providing a framework for scheduling, budgeting, and project management. The tools associated with a good methodology make it easier to solve the problem. Finally, a good methodology increases the likelihood that significant errors are detected early.

There are dangers associated with using a methodology, however. Some people become so bogged down in the mechanics of following the steps and completing the exit criteria that they fail to solve the real problem. (There is a fine line between discipline and rigidity.) Additionally, no matter what methodology is chosen, there will be problems for which that methodology is (at best) inappropriate, and it is a mistake to try to force the application to fit the tool.

There is always a concern that the system developed may not accurately reflect the current business environment. The elapsed time between the initial proposal and system completion can be quite lengthy (often one or more years). Many methodologies require that specifications be “frozen” as work progresses from one step to the next, and user requirements do change over time. Given the fast pace of technology, this problem is particularly acute with hardware and/or software selected early in the process.

The traditional methodologies are not optimal for developing some types of information systems, such as expert systems and real-time processing systems. Additionally, fourth-generation, fifth-generation, and objected-oriented languages require modifications to the traditional approach.

Sometimes management is tempted to believe (or hope) that technology can replace technical experts. A good methodology makes a competent analyst more productive, but no methodology can convert an unskilled, untrained person into a competent analyst.

1.3 Inputs and related ideas

The system development life cycle provides a framework or structure for virtually all the tools and techniques discussed in this course.

The system development life cycle implies a phased approach, with complex tasks decomposed into smaller phases (stages, steps) that are easier to achieve, control, and manage. Many traditional methodologies, such as Martin’s information engineering (# 2) and Orr’s structured requirements definition (# 4), emphasize the phased approach, with clearly defined entrance and exit criteria for each individual phase. Practicing analysts often deviate from the rigidly phased approach defined by the methodology, however.

The project management life cycle is similar to the system development life cycle, with stages or phases defining a schedule and triggering resource allocations. Note, however, that a given project might encompass several related systems, and a given system might be divided into several sequential or concurrent projects.

1.4 Concepts

A system (Figure 1.1) is a set of interrelated components that function together in a meaningful way. A system is delimited from its environment (its suprasystem) by a boundary. A system accepts inputs at its boundaries. Outputs flow back across the boundaries. A process is an activity that changes the system in some way. Of particular interest are the interfaces, the points at which the various systemcomponents communicate or interact. As a general rule, the more interfaces a system contains, the more complex the system.


Figure 1.1  A system.

In addition to inputs, processes, interfaces, and outputs, the system also includes control and feedback mechanisms that together allow the system to determine if it is achieving its purpose. Feedback is the return of a portion of the system’s output to its input. If the feedback suggests a deviation from the expected value (the control), the system reacts by attempting to adjust itself.

1.4.1 Information systems

This course is concerned with the analysis and design of information systems. An information system is a set of hardware, software, data, human, and procedural components intended to provide the right data and information to the right person at the right time.

1.4.2 The system life cycle

Every system has a life cycle (Figure 1.2). 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.


Figure 1.2  The system life cycle.

1.4.3 Methodologies

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 set of well-defined steps or phases, each of which ends with a clear, measurable set of exit criteria. 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).

1.4.4 The waterfall method

The basis for most systems analysis and design methodologies is the system development life cycle or SDLC (Figure 1.3). It is sometimes called the waterfall method because the model visually suggests work cascading from step to step like a series of waterfalls. (Note: In reality, there is considerable feedback between the various steps or phases.)


Figure 1.3  The system development life cycle is sometimes called the waterfall method.

The first step is problem definition. The intent is to identify the problem, determine its cause, and outline a strategy for solving it.

Given a clear problem definition, analysis begins. The objective of analysis is to determine exactly what must be done to solve the problem. Typically, the system’s logical elements (its boundaries, processes, and data) are defined during analysis.

The objective of design is to determine how the problem will be solved. During design the analyst’s focus shifts from the logical to the physical. Processes are converted to manual procedures or computer programs. Data elements are grouped to form physical data structures, screens, reports, files, and databases. The hardware components that support the programs and the data are defined.

The system is created during development. (Note: Because the entire process is called the system development life cycle, some experts prefer to use other labels, such as system creation, for this stage.) Programs are coded, debugged, documented, and tested. New hardware is selected and ordered. Procedures are written and tested. End-user documentation is prepared. Databases and files are initialized. Users are trained.

Once the system is developed, it is tested to ensure that it does what it was designed to do. After the system passes its final test and any remaining problems are corrected, the system is implemented and released to the user. After the system is released, maintenance begins. The objective of maintenance is to keep the system functioning at an acceptable level.

1.5 Key terms

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.
Boundary —
An entity that serves to delimit or separate a system from its environment.
Control —
An expected value that can be compared with feedback. If the feedback suggests a deviation from the expected value (the control), the system reacts by attempting to adjust itself.
Design —
The third step in the system development life cycle (following analysis and preceding development) during which the responsible people determine how the problem will be solved by specifying the system’s physical components.
Development —
The fourth step in the system development life cycle (following design and preceding testing) during which the system is created.
Feedback —
The return of a portion of the system’s output to its input.
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.
Information system —
A set of hardware, software, data, human, and procedural components intended to provide the right data and information to the right person at the right time.
Interface —
A mechanism or point of interaction between two or more system components.
Maintenance —
The final step in the system development life cycle (following implementation) intended to keep the system functioning at an acceptable level.
Methodology —
A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. Often implemented as a set of well-defined steps or phases, each of which ends with a clear, measurable set of exit criteria.
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.
Process —
An activity that changes a system in some way.
Suprasystem —
A system’s environment.
System —
A set of interrelated components that function together in a meaningful way.
System development life cycle (SDLC) —
A set of steps for solving information system problems; the basis for most systems analysis and design methodologies.
System life cycle —
A model that stresses the stages of system usefulness. The stages are birth, development, growth, maturity, and death.
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.

1.6 Software

Not applicable.

1.7 References

1.  Davis, W. S., Business Systems Analysis and Design, Wadsworth Publishing, Belmont, CA, 1994.
2.  Fertuck, L., System Analysis and Design with CASE Tools, William C. Brown Publishing, Dubuque, IA, 1992.
3.  Kendall, K. E. and Kendall, J. E., Systems Analysis and Design, Prentice-Hall, Englewood Cliffs, NJ, 1992.
4.  Laudon, K. C. and Laudon, J. P., Managing Information Systems: A Contemporary Perspectives, 2nd ed., Macmillan, New York, 1991.
5.  Modell, M. E., A Professional’s Guide to Systems Analysis, McGraw-Hill, New York, 1996.
6.  Whitten, J. L., Bentley, L. D., and Dittman, K. C., Systems Analysis and Design Methods, Richard D. Irwin, New York, 1997.
toc ch2>