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.
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.
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 Martins information engineering (# 2) and Orrs 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.
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 systems output to its input. If the feedback suggests a deviation from the expected value (the control), the system reacts by attempting to adjust itself.
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.
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.
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).
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 systems 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 analysts 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.