SDLC Models

Several models exist to streamline the development process. Each one has its own pros and cons, and it's up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more suitable. Let’s examine few development models.

Waterfall model

This model is mainly apt for small and relatively easy software projects. Software companies working according to this model complete each stage in consecutive order and review its results before proceeding to another stage, which renders the waterfall model inflexible and unsuitable for complex long-term software projects.

The waterfall model shows a process, where developers are to follow these phases in order:

1. Requirements specification (Requirements analysis)
2. Software design
3. Implementation and Integration
4. Testing (or Validation)
5. Deployment (or Installation)
6. Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by supporters of other more "flexible" models.

Advantages

• Simple and easy to use.
• Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.

Disadvantages

• Changes in the requirements cannot be accommodated.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Poor model for complex and object-oriented projects.
• Poor model for long and ongoing projects.

Spiral model

The essence of this model is in the underscored importance of a risk-analysis during the development process. The spiral model presupposes that each stage of the classical waterfall model is divided into several iterations; each iteration undergoes planning and risk analysis. As a result this model allows a software company to produce working software after each iterative stage, while evaluating the risks on an ongoing basis. However, adopting the spiral model may result in notably higher costs.

The key characteristic of a Spiral model is risk management at regular stages in the development cycle. In 1988, Barry Boehm published a formal software system development "spiral model," which combines some key aspect of the waterfall model and rapid prototyping methodologies, but provided emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems.

The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities:

1. formulate plans to: identify software targets, selected to implement the program, clarify the project development restrictions;
2. Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk;
3. the implementation of the project: the implementation of software development and verification;

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows:

1. The spiral model emphasizes risk analysis, and thus requires customers to accept this analysis and act on it. This requires both trust in the developer as well as the willingness to spend more to fix the issues, which is the reason why this model is often used for large-scale internal software development.
2. If the implementation of risk analysis will greatly affect the profits of the project, the spiral model should not be used.
3. Software developers have to actively look for possible risks, and analyze it accurately for the spiral model to work.

The first stage is to formulate a plan to achieve the objectives with these constraints, and then strive to find and remove all potential risks through careful analysis and, if necessary, by constructing a prototype. If some risks cannot be ruled out, the customer has to decide whether to terminate the project or to ignore the risks and continue anyway. Finally, the results are evaluated and the design of the next phase begins.

Advantages

• High amount of risk analysis
• Good for large and mission-critical projects.
• Software is produced early in the software life cycle.

Disadvantages

• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

Incremental Model or Iterative Model

This model is widely used when the software undergoes many changes during the development phase. Here the changes and the requirements are added and released as several versions till the actual product is developed. The product will be delivered in several releases. The difference is that the product will have additional functionalities in each release. It is suitable for products which has constant changes in the requirements. The basic structure is waterfall model. The requirements are freezed at the initial stages and the changes are accommodated in the next release.

Agile development

This development model adopts the iterative model as a baseline, while putting an emphasis on the human factor, which is achieved by software team feedbacks throughout the ongoing development process. In this method the customer takes part in all the development phase and will give constant feedback about the software which will help to develop the right product without any deviation. Upon the satisfaction and approval of the customer the development moves to the next phase. This is widely followed by companies as the customer will give constant feedback about the process at various phases. The model is a cyclic process until the correct product is developed.

Prototype Model

This model is used when the customer himself don’t know what kind of products he want. Here the company or the solution provider will give some prototype product to the customer to find if it is the actual product required by the customer. The initial prototype is developed by the known requirements and the prototype is enhanced further with the feedback from the customer. Upon arrival of the satisfied prototype, the prototype is ignored and the requirements are derived from the prototype and actual product is developed.

V-shaped model

This model is similar to the waterfall model, though the main emphasis is placed on the verification stage and testing, which overlap all the other stages of the software development lifecycle. Tests are planed starting from the documentation stage, then throughout integration and coding and after the actual implementation of a software product testing itself is initiated. Therefore, the V-shape is formed due to the upward direction of Testing, i.e. test execution. 

Advantages

• Simple and easy to use.
• Each phase has specific deliverables.
• Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
• Works well for small projects where requirements are easily understood.

Disadvantages

• Very rigid, like the waterfall model.
• Little flexibility and adjusting scope is difficult and expensive.
• Software is developed during the implementation phase, so no early prototypes of the software are produced.
• Model doesn’t provide a clear path for problems found during testing phases.

The V-Model and the Software Testing

The major drawbacks of the other models are that the testing is not carried out alongside during the development stages. So the defects and failures will come up only during the implementation stage or in Live Usage of the software which is very costly to fix and difficult to identify which part of the code went wrong.

In order to overcome this, the V-Model was developed in such a way that various testing activities are carried out along the development cycle. Please refer to the figure below,

Although variants of the V-model exist, a common type of V-model uses four test levels. The four test levels used, each with their own objectives, are:

• Component testing: Process of testing the basic building components of the software. Eg. The user name text box in Login page. Can also be called as Unit testing.

• Integration testing: Process of testing the interfaces between components, interactions to different parts of a system such as an operating system, files system and hardware or interfaces between systems.

• System testing: Concerned with the behavior of the whole system/product as defined by the scope of a development project or product. The main focus of system testing is verification against specified requirements.

• Acceptance testing: Testing if the software is built as per the customer needs. Usually done by the customer or customer representative. The system will be tested in terms of the business verticals and how it will be used in the live scenario.