Home > V-Model Development > Software Development Life Cycle

Software Development Life Cycle

The ideas about the software development life cycle (SDLC) have been around for a long time and many variations exist, such as the waterfall, and the V-model. These variations have many versions varying from those which are just guiding principles, to rigid systems of development complete with processes, paperwork, and people roles. However underlying all these are a set of common principles.

SDLC Common Principles

The common principles behind the SDLC are:

1. The process of developing software consists of a number of phases.
2. These phases are arranged in a precedence sequence of when they start.
3. The sequence of phases represents the passage through time of the software development.
4. Phases can and do overlap as previous phases are revisited, when more information becomes available.
5. The software becomes more complex and useful as the phases are followed.

These principles apply to whichever particular variation of the SDLC is looked at, with emphasis being placed on particular principles in each variation

SDLC Common Phases

As you look at the various methods they all have a number of particular phases they recommend. On my V-Model page I show a specific set of phases. This set is practical, but is not the definitive answer for all software development. The V-Model example is just to demonstrate the issues to be considered in development and how they affect each other.

I propose the “4D” model as a generic model for understanding the larger issues. This has four phases:

• Decide – What is it you want to build in software?
• Design – How will you map these decisions to a software environment?
• Develop – Build the software according to the designs.
• Demonstrate – Prove that the software delivers what was required.

Decide Phase

The Decide phase covers all those activities involved in deciding what it is that you want to build. The products from this phase typically include:

• Business cases to justify what is wanted in terms of business benefit.
• Feature lists of what is wanted to be included to deliver that benefit.
• Use Cases to explore how the features would work together.
• Non-functional requirements are the performance and development constraints placed on the system.
• System Specification which maps between what is wanted in the real world and what is possible in a computer system.

This phase is frustrating one – it is necessary but it can be perceived as delaying the eventual system. Also it requires a large commitment of user’s time to decide this, often while they are involved in doing their normal day job. As a result many projects have a poor set of deliverables from the Decide phase before the Design phase starts. If however there is a process to allow modification of these products throughout the project then the Decide products will improve.

Design Phase

The Design phase takes the products from the Decide phase and creates a design of the architecture and detail working of how the software system will deliver what is wanted. The key thing to note is that despite many efforts over the years there is no automatic way of deriving the Design products from the Decide products. Where this has been claimed before inevitably it has been by restricting the way the Decide products are written and forcing them to be expressed in the form of a computer design. However it is possible, and necessary, to compare the Design products with the Decide products to see if what is wanted has been included. The Design phase is done by the analyst and design team who should work closely with developers in the Develop team.

Develop Phase

The Develop phase is what most users consider to be what software development is about. Paradoxically in many ways it is the least important of the phases, even though it will consume a lot of the resources. The reason is that most systems are constructed from a set of standard parts with some configuration, some customisation, and some bespoke parts to make the system unique. These decisions would have been taken in the Design phase, and in the Develop phase the work of converting them into a software system takes place. The products from this phase then have to be shown to work.

Demonstrate Phase

The Demonstrate phase is about proving that the delivered system works and is what was wanted. This phase is not just about testing but contains activities such as document reviews and code walkthroughs. It has a high degree of overlap with the other phases as the earlier you can catch a problem results in higher quality in the final product. This phase is done by both the developers and the users.

SDLC Diagrams

I have called these four phases a “4D” model as it implies it is multi-dimensional including a time dimension. However these models are always depicted as a two-dimensional diagram and as a result some of the universal features of a SDLC are obscured or lost. Diagram 1 - 4D SDLC - is a non standard way of showing a SDLC showing several of the principles including:

1. There are four phases representing different things to be done.
2. The phases follow each other in sequence shown by the overlap and moving up the complexity and time scales.
3. They move along the time scale.
4. Phases overlap implying that there is no fixed finish between the start of one phase and the start of the next. It also implies that previous phases are revisited when further information is found.
5. The phases rising up imply both increasing complexity and also the amount of effort required to reach a final product.

This diagram is different compared with the normal waterfall approach such as in diagram 2 - Traditional SDLC.

Comparing this against the 5 principles shows:

1. It also clearly shows the four phases.
2. It also shows the precedence order.
3. They also move along the time scale.
4. However the diagram implies that there is a clear finish of each phase before the next starts. Very few Softeare Development Life Cycles recommend this, but this is the impression the diagram gives.
5. The products falling down give the visual impression of little effort being required, nor does it give an impression of the greater complexity being built up.

In practise if people are thoroughly aware of what needs to be done then it does not matter what diagram is used. Therefore in the rest of this site we will use similar waterfall type diagrams.

Conclusion

There are many ways of structuring a software development life cycle, but all of them should follow the “4D” phases. I illustrate two of these – the Waterfall and V-Model – on this site to show how they map against these common points.

Waterfall and V-Model Examples

• Waterfall Model - the seven stages of a waterfall model and how they match the four phases of the SDLC.
• From Waterfall model to V-Model - how the V-Model is derived from the waterfall model.