Traditional Systems Life Cycle (Waterfall)

Traditional Systems Lifecycle (Waterfall)

The lifecycle methodology is a very formal approach to building a system, dividing systems development into formal stages that must take place in a sequential order. All the activities in each stage must be completed before the next stage can begin.

The goal of the Traditional System Life Cycle is to keep the project under control and assure that the information system produced, satisfies the requirements. The traditional system life cycle divides the project into four phases, i.e. 

1. Planning
2. Analysis
3. Design
4. Implementation

SDLC aims o produce high quality systems that meet or exceed customer expectations, based on customer requirements, by delivering systems which move through each clearly defined phase, within scheduled time-frames and cost estimates.

In many ways, building an information systems is similar to building a hospital. First, the hospital (or the information system) starts with a basic idea. Second, this idea is transformed into a simple drawing that is shown to the customer (owner of the hospital) and refined (often through several drawing, each improving on the other) until the customer agrees that the picture depicts what owner of the hospital wants (customer).

Planning:

The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it. The first phase of SDLC, in which an organizations total information system needs are analyzed and arranged, and in which a potential information systems project is identified and an argument for continuing or not continuing with the project is presented.  

Analysis:

The second phase of SDLC in which the current system is studied and alternative replacement systems are proposed. The analysis phase answers the questions of who will use the system, what the system will do, and where it will be used. During this phase, project team investigates any current system identifies improvement opportunities, and develops a concept for the new system.

Design:

The third phase of SDLC in which the system chosen for development in systems analysis is first described independently of any computer platform, (logical design) and is then transformed into technology – specific details (physical-design) from which all programming and system construction can be accomplished. The design phase decides how the system will operate in terms of the hardware, software, and network infrastructure that will be in place; the user interface, forms, and reports that will be used; and the specific programs databases, and files that will be needed. Although most of the strategic decisions about the system are made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate.

Implementation:

The final phase is SDLC is the implementation phase, during which the system is actually built (or purchased, in case of packaged software design). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps.

(i) First step – System construction

(ii)   Second step – Installation of system process

(iii)   Third step – Support plan for the system

The system life cycle is still used for building large complex system that require a rigorous and formal requirements analysis, predefined specifications, and tight controls over the systems – building process. However, the systems life cycle approach can be costly, time consuming, and inflexible. Although systems builders can go back and forth among stages in the life cycle, the systems life cycle is predominantly a "Waterfall" approach in which tasks in one stage are completed before work for the next stage begins. The Waterfall model, sometimes called the classic-life cycle, suggests a systematic sequential approach to software development that begins with customer specification of requirements and progress through planning, modeling, construction, and deployment culminating in – on – going support of the completed software.

The waterfall model can be very useful in helping developers layout what they need to do. Its simplicity makes it easy to explain to customers who are not familiar with software development; it makes explicit with intermediate products are necessary in order to begin the next stage of development. Many other, more complex models are really just embellishments of the waterfall, incorporating feedback looks and extra activities.