Software Development Life Cycle Models

Before, whenever a developer is tasked to perform programming or coding, he immediately would jump to it, start programming with or without full knowledge of what the system would look like, how the features are arranged, etc. It is probably okay only if you’re just building a very simple system. However, if you’re building a complex and sophisticated system, it will take a long time for you to finish. Worse, you start to suffer from “groping in the dark” syndrome since your full of ideas, you want to implement them all, but you tend to forget about them because other features need to be prioritized.

That was before. Now, whether an IT system is small, medium or large scale, it is important to have a proper software/system development plan from beginning to end. It saves time, features of the system are well documented and will not be forgotten regardless of priority, and above all, there is proper management and execution of plans.

System Development Life Cycle (SDLC) models help in the complete development of a system, right from the conceptual stage to the customer delivery stage. SDLC is very useful if one has a complicated system to build. SDLC is the overall process of developing information systems through a multi-step process, from investigation of initial requirements to analysis, design, implementation and maintenance.

To properly illustrate the SDLC models, I shall present them in bullet form.

1. Waterfall Model

· One of the older SDLC models

· Each single step in the process of system development is first written down in the form of specifications and reports. Only then are the actual phases initiated in practice

· The execution of a project appears as a sequence of stages in which the output of each stage becomes the input for the next

· The stages in Waterfall method are divided into the ff:

1. Project planning / feasibility study – commonly known as Requirements Stage. It is in this stage that developers/stakeholders determine the project goal

2. System analysis – refines project goals into defined functions and operations. It also analyses end-user information needs (Specification stage)

3. System design – describes desired features and operations in detail (Design stage)

4. Implementation / Coding (Implementation stage)

5. Integration and testing – brings all the individual system components into one, then testing it for errors, bugs, etc. (Integration stage)

6. Acceptance, Installation, Deployment – final stage of development where the software is put into production

7. Maintenance – this goes on apparently forever since changes, additions, etc are always essential, important and needed in a software application especially in the area that involves business and monetary transactions.

· Drawbacks

1. Works well on simplistic activities

2. Assumes that the only role of users is in specifying requirements and that all requirements can be specified in advance. Unfortunately, requirements grow and change

3. It is, thus, well suited to projects that has low risk in the areas of user interface and performance

2. Spiral Model

· Most generic of the models. Most life cycle models can be derived as special cases of the spiral model

· Set of important requirements are selected for each prototype. Thus, developers can split the requirements and work first on those with high priority

· Employs a risk management approach to software development especially in the stages of Specification, Design, Implementation and Integration

· Emphasizes the need to reiterate earlier stages a number of time as the project progresses

· Actually a series of short waterfall cycles, each producing an early prototype, representing a part of the entire project. It’s like using the waterfall model as guide in doing one prototype only.

· If one prototype is finished (except perhaps the polishing of graphics), a developer can proceed to the next prototype. Build, test and integrate to the first prototype

· Helps demonstrate a proof of concept early in the cycle

· Incorporates prototyping and software quality objectives

· Gives early focus to reusable software

· Accommodates life cycle evolution, growth and requirement changes

· Focus on early detection and design (architecture) flaws

· Useful in hardware-software projects

3. Build and Fix Model

· Crudest of the models

· Implementation of system without specification nor design

· May work for small scale projects

· Code is written, then modified until client is happy

· VERY RISKY!

· I know of a developer who does just this kind of work strategy. He was given an assignment, but instead of planning properly, he will just code it immediately without specification or design. He improves it until his client is happy. If the client is dissatisfied, he doesn’t give a damn about it.

4. Rapid Prototyping Model

· Emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness

· Develop a system with reduced capability

· Present to client for approval

· Once the prototype is approved, it is discarded and the “real” software is written.

· Develops specification with better understanding

· Exactly like the Spiral Model, where a prototype or only “shadow” of the real software is made, where the system (during implementation stage) is not that graphically perfect but features are functioning well for testing purposes

· Only difference is, in Rapid Prototyping, it requires client approval prior to the building of the “real” software

5. Incremental Model

· Divides the product into builds, where sections of the project are created and tested separately

· Each build contains an operational quality subsystem

· Each additional build, a new subsystem is integrated with the previous build

· You will notice that this model is very much like the Spiral Model except that instead of prototype, they’d rather call it builds. These builds, like prototypes, are tested separately first. Each build has a subsystem in Incremental Method, whereas in Spiral, subsystems may or may not be used

· Likely to find errors in user requirements quickly

6. Synchronize and Stabilize Model

· Type of Incremental Model

· Allows many teams to work efficiently in parallel

· A nightly compilation of builds of the entire project is made to piece together all current components

· An alpha release was done for internal testing, a couple of beta releases took care of a wider testing range outside the company. Finally, a release candidate leading to the final version, called a gold master, was released to manufacturing

· At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs

· There is heavy emphasis in schedule management and perfection

7. Fountain Model

· Support Incremental Development

· Recognizes that some activities can’t stand before others, yet there’s a considerable overlap of activities throughout the development cycle

· Implies that you do some analysis, then some design, then some implementation

· Parallelism among various phases and iteration within phases

· Development of an object-oriented system that more likely to lead us to focus on sections of the whole known as clusters or subsystems

· Subsystems are collections of classes which work closely together

· Supports human learning and is recommended for most projects

SDLC is a systems approach to problem solving and is made up of several phases. A developer may or may not use or apply SDLC, but based on my experience, it is highly advantageous to use one. We did a system before where we didn’t plan much how we will execute, start and finish building a system. The result was a complete catastrophe! We suffered “groping in the dark” syndrome, regretted ever working with one another, and suffered too many expenses and too much time delay. Learning from the lesson, it is, thus, highly recommended to properly plan the flow of activities in building a system through SDLC as one of the tools in management.

plobrin@gmail.com