Software Development Life Cycles

In this article we’re going to provide a very basic introduction to some of the more common Software Development Life Cycles (SDLC) in existence. A SDLC describes a process for making or altering software. Because there are many approaches to making software there are many different SDLCs. SDLC’s only exist because making software can be complex, and so SDLCs exist in an attempt to manage this complexity.

Despite the many different SDLCs out there in existence, most have a lot in common. Once you can understand one it is not usually difficult to understand another. Let’s start by looking at a basic generic SDLC:

In the above generic SDLC there are four distinct phases. A project will move through each phase one by one in turn until the project is complete and the software is in use by the customer. Each phase of the SDLC will produce outputs, called deliverables, which are required by the next phase.

The purpose of this phase is to specify exactly what the system needs to do. In this phase we will need to understand questions such as who will use the system? How will they use the system? What data needs to be input to the system? What data will be output from the system? Answering these questions will result in lots of information: how the use interface should work, what functions the system should perform (often called functionality), the logic by which data should be processed, and any security or performance requirements the system must meet.

Once we have the system requirements specifying what the software should do we enter the Design phase. In this phase the software architects will design structurally how the software will work, and how these different structural parts will communicate with each other. They will also define what hardware is required by the software.

This is where the business of writing the code is done by developers based on the design which has just been created. Once code is written it must be tested. Testing will normally happen alongside the coding and not wait until the coding is complete. The testing will involve trying different inputs to the software to ensure the correct outputs are observed. Good testing will ensure that extreme and unusual inputs are tested to check if the software behaves as it should during all situations.

In this phase the work of designing and creating the software has finished and the software is transitioned to real-world use, known as the maintenance phase. Despite all the design and testing effort that has gone before, in the real-world, defects can and will be found in this stage by actual users. When this happens, developers will examine the defect to find its root cause, and patch the software (change the code) to fix the problem.

Now that we’ve examined a generic model, we’re ready to look at some commonly used SDLCs:

This is the oldest and most well-known of all the SDLC’s, first described by Winston W Royce in 1970. In this model each phase is performed in turn, and we do not move to the next stage until we have completed the current stage. At the end of each stage a decision will be made as to whether to continue with the project or to scrap the project.

• Works well in situations where requirements, once defined, will not change.
• Simple to use and easy to understand.
• Because of the linear and strict nature of the model it is easy for project managers to enforce.

• Does not work well in environments where requirements will continually change up to the point at which the software is in use.
• Working software is not expected to be produced until the very end of the life cycle. There is thus substantial risk that the software will not meet the exact needs of the customer.

2. Spiral Model

1. Determine objectives and constraints
2. Identify risks
3. Evaluate alternatives
4. Coding
5. Plan next iteration

The software progresses through this model quickly as many times as is necessary until the software is complete. In the Spiral model, the width of the spiral represents the cost expended.

• Risk analysis forms an integral part of the life cycle.
• Software is produced early eliminating the risk of completing failing to meet the customers expectations.
• Works well in environments where requirements are likely to change throughout the project.
• Enhanced focus on risk management.

• No understanding of the final cost of the project at the outset.
• Applied differently within every organization, and differently for every piece of software.
• If you are not careful you can end up implementing the incremental model

The V-Shaped model is very similar to the Waterfall model except that it has extra emphasis placed on testing. Each phase must be completed before the next phase is started. We move through the model in turn, completing both sides of the v together, for example, at the beginning of the model we capture the user requirements whilst at the same time determining the tests we will use to ensure we have adequately implemented met the user requirements. We will not move to the next stage of the model until both sides of the V at a given level are complete.

We work down the V until we arrive at the bottom, where the coding is done. Once the coding is complete we work up the right side of the V, one stage at a time, where the test plans developed earlier are put into action. Once all testing has been successfully completed the software is ready. A simplified V-model is shown below:

• Simple and easy to use with each phase having very specific deliverables.
• Works well in environments where all requirements can be known up front.
• Because of the emphasis on testing, it works well for systems where high reliability is required, for example, flight systems and medical systems.

• Similarly to the Waterfall model, it’s ridgity makes it unsuited to environments where requirements change throughout the project.
• No working software is produced until the bottom on the V is reached

You can think of the incremental model as being a series of mini waterfalls. Here, the complete project is divided into smaller increments. These increments are smaller and with more easily defined goals than would be possible for the entire project. A working and tested version of the software is typically built in the first iteration. Subsequent iterations build on this software to eventually produce the final software.

• Working software is developed at an early stage of the project.
• It is easy to identify missing functions from the software at each stage.
• It supports a flexible design as changes are expected with each iteration.

Disadvantages

• There is no obvious way to ensure non-functional requirements are met, for example, performance requirements.
• Because requirements are expected to change the project may take much longer than would have been the case with other SDLC’s.