Lifecycles

Software development can only be achieved using one lifecycle.

It is true, despite signs to the contrary. The different methodologies that have been defined to produce software (e.g. Waterfall, 'V' Model, Spiral, Incremental, Iterative) all follow the same steps to develop software. The final quality of the software is normally influenced by the level of granularity of the steps, the management of risk, the complexity of the system, and the quality of development staff. So, what are these steps?

They are are pretty obvious, to be honest. The steps are:

1. Plan the work
2. Define the requirement
3. Design the solution
4. Implement the solution
5. Test the solution
6. Release the solution

It is impossible to write software any other way. So why do 75%+ of projects fail to deliver on time? Because some of the developers try to miss steps out and end up re-working the problem. A bit of a waste really.

This is where a good QMS starts to become useful. Each of the methodologies for developing software try to reduce failure for a particular system. Unfortunately, the target system itself evolves over time in most cases and forces organisations to adopt different methodologies according to the nature of the change to be made.

The waterfall or cascade development approach is probably the oldest software development method and closely matches the electronics development approaches of the 1960's and 1970's. The Systems Engineering lifecycle still reflects the methodology, and variations of it exist to facilitate integration with non-software aspects. Two of the most influential standards over the waterfall approach are MilStd 2167A and MilStd 498. These standards introduced the concept of phasing. The NASA and ECSS standards follow a very similar phase breakdown, as does the Air Traffic Industry. Although there are variations, the basic phases are:

• PRR - Project Requirements Review
• SRR - System Requirements Review
• SW-SRR - Software Requirements Review
• SW-PDR - Software Preliminary Design Review
• SW-CDR - Software Critical Design Review
• SW-TRR - Software test Readiness Review
• SW-TRB - Software Test Review Board
• DRB - Delivery Review Board
• AR - Acceptance Review
• MR - Maintenance Review (performed at intervals)

Other reviews may be interspersed if hardware is involved. These reviews may be scaled up or down according to the level at which software is developed.

The main weakness this waterfall approach suffers is that the final system is not completed until all the money and resource has been utilised. Its awkward when the final system does not work or cannot be adequately validated against its original requirements.

The 'V' Model life cycle was devised when a number of large projects encountered the problem of not being able to test a system properly after it was built. It was the first attempt to break a system problem down into smaller subsystems. This approach was originally devised for the electronics projects, as more and more components were commoditised allowing organisations to mix off-the-shelf items with the purpose-built or customised items.

The same approach was tried in the software industry as operating systems and commercial applications became available. Companies no longer had to write their own hardware specific drivers for commercial products. The breakdown of a system into its applications worked for the most part, but complete software applications were still treated like monolithic architectures, so the waterfall model was followed even within the confines of a 'V' Model project.

As it stands, the 'V' Model approach is still a robust and risk-averse method for developing software, especially critical software, like that used in the nuclear, space, aerospace, and medical industries. The value it gives is the ability to assess a software component from a testing and architecture interfacing perspective, using resources different to those that design and implement software.