Types of SDLC Model

Waterfall Model :

Let’s have a look on Waterfall model which is basically divided into two subtypes:-

· Big Bang waterfall model.
· Phased waterfall model.

As the name suggests Waterfall means flow of water always goes in one direction so
when we say waterfall model we expect every phase/stage is freezed.

Big Bang waterfall model:

The figure shows waterfall Big Bang model which has several stages and are described as
below:-

•  Requirement stage : - This stage takes basic business needs required for the project which is from a user perspective so this stage produces typical word documents with simple points or may be in a form of complicated use case documents. 

• Design stage: - Use case document / requirement document is the input for this stage. Here we decide how to design the project technically and produce technical document which has Class diagram, pseudo code etc.

• Build stage:-This stage follow the technical documents as an input so code can be generated as an output by this stage. This is where the actual execution of the project takes place.

• Test stage:-Here testing is done on the source code produced by the build stage and final software is given a green flag. Deliver stage: - After succeeding in Test stage the final product/project is finally installed at client end for actual production. This stage is start for the maintenance stage.

In water fall big bang model, it is assumed that all stages are freezed that means it’s a
perfect world. But in actual projects such processes are impractical.

Phased Waterfall model :

In this model the project is divided into small chunks and delivered at intervals by different teams. In short, chunks are developed in parallel by different teams and get integrated in the final project. But the disadvantage of this model if there is improper planning may lead to fall of the project during integration or any mismatch of coordination between the team may cause huge failure.

Iterative model :

Iterative model was introduced because of problems faced in Waterfall model. Now let’s try to have a look on Iterative model which also has a two subtype as follows:-

Incremental model  :

In this model work is divided into chunks like phase waterfall model but the difference is that in Incremental model one team can work on one or many chunks which was unlike in phase waterfall model.

Spiral model:

This model uses series of prototype which refine on understanding of what we are
actually going to deliver. Plans are changed if required as per refining of the prototype. So every time in this model refining of prototype is done and again the whole process
cycle is repeated.

V-model :

This type of model was developed by testers to emphasis the importanceof early testing. In this model testers are involved from requirement stage itself. So below is the diagram  (V model cycle diagram) which shows how for every stage some testing activity is done to ensure that the project is moving as planned.

For instance,

• In requirement stage we have acceptance test documents created by the testers.Acceptance test document outlines that if these test pass then customer will accept the software.

•  In specification stage testers create the system test document. In the coming section system testing is explained in more elaborate fashion.

• In design stage we have integration documents created by the testers. Integration test documents define testing steps of how the components should work when integrated. For instance you develop a customer class and product class. You have tested the customer class and the product class individually. But in practical Scenario the customer class will interact with the product class. So you also need to test is the customer class interacting with product class properly.

• In implement stage we have unit documents created by the programmers or testers.

Lets try to understand every of this testing phase in more detail.

Unit Testing
Starting from the bottom the first test level is "Unit Testing". It involves checking that
each feature specified in the "Component Design" has been implemented in the
component.
In theory an independent tester should do this, but in practice the developer usually does
it, as they are the only people who understand how a component works. The problem
with a component is that it performs only a small part of the functionality of a system,
and it relies on co-operating with other parts of the system, which may not have been
built yet. To overcome this, the developer either builds, or uses special software to trick
the component into believe it is working in a fully functional system.

Integration Testing
As the components are constructed and tested they are then linked together to check if  they work with each other. It is a fact that two components that have passed all their tests, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers.
Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the "System Design". The "System Design" defines relationships between components. The tests are organized to check all the interfaces, until all the components have been  built and interfaced to each other producing the whole system.

System Testing
Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact it is one giant component. System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements:

· Performance - Are the performance criteria met?
· Volume - Can large volumes of information be handled?
· Stress - Can peak volumes of information be handled?
· Documentation - Is the documentation usable for the system?
· Robustness - Does the system remain stable under adverse circumstances?