1.2.1.

Software Development Life-cycle Models

1.2.1.1. Stages of Software Development

A typical software development has following stages.

1. Requirements Gathering
2. Architecture
3. Design
4. Development
5. Testing
6. Maintenance

During the ‘Requirements Gathering’ stage, requirements for the software is gathered by various
means. It is primarily done by the Marketing teams, with involvement from the Architects and the
Project Manager of the development team. There are various ways to gather requirements like
surveying the customers and potential users, studying similar products, adding potential innovations
etc. At the end of requirement gathering, a document containing ‘Product Specification’ is generated.

The next stage is to come up with the ‘Architecture’ of the product. Architecture is arrived at based
on the requirements specified in the ‘Product Specification’. At the end of this stage, the Architecture
document should be generated, which becomes an input for the next stage.

‘Design’ stage follows the Architecture stage. In this stage, the detailed design is done based on the
architecture of the product. End result of this stage should be a ‘Design Document’ which should be
as detailed as possible so that the implementation is not ambiguous.

The next stage is ‘Development’ stage, where the coding is done as per the design document. The
coding of each module should be followed by unit testing of the same module. Unit testing is
responsibility of the person doing the corresponding coding.

Once code of each of the module is ready after corresponding unit testing, all of these modules are
integrated together and corresponding integrated testing is done. The integration can be hierarchical.
Here hierarchical means, at the beginning modules related to same functionalities are integrated and
then integration continues till all the modules are integrated. Usually quality assurance team does the
integration testing. For integration testing, a corresponding test bench and test tools may have to be
developed. The bugs generated during the integration testing, need to be fixed.

Once the product is satisfactorily bug free and matches all the requirements, it is ready to be released
to the customer. This is done by coming up with the release criteria and the product should match all
the criteria. Once it is released to the customer, customer may find some bugs, which need to be fixed
by the developers. Customer may ask for some more features, which need to be implemented by the
development team. These activities are part of the ‘Maintenance’ phase.

All these stages constitute Software Lifecycle.

These are different models of Software Lifecycle, which have been followed in the industry at different
point of times. Subsequent sections will discuss about some such models.
1.2.1.2. Waterfall Model

Fig 1.2.1.1 shows the waterfall model of software development.

Fig. 1.2.1.1. Waterfall model of software development

In this model, the stages are followed sequentially. For example, first requirements are frozen. Then
the corresponding architecture is frozen and so on. There could be iteration before ending a stage,
but iterations are related to that stage only. This appears simple and traditionally this was the way of
software development. But there are disadvantages of this model. For example, is an architecture
issue is found out in testing phase, then we have to revisit all the stages from the architecture stage
since each stage has impact on its following stage. This has adverse impact on the completion timeline
of a project. Similarly, customer may request to add some new features during the project lifecycle.
Such request will again delay because of the reasons stated.

These are the reasons, why this model is not followed now a days.

1.2.1.3. V Model

Fig 1.2.1.2 shows the V model of software development. This model is an improvement over the
waterfall model. Here the Quality Assurance team (or System Validation team) is involved from the
beginning stage of the project, so that the testbench development, test cases development etc
happen in parallel. During ‘Requirement’ phase, quality assurance team should be involved in
understanding the requirements and creating the top level test plan. Similarly during ‘Design’ phase
‘Integration and Testing’ phase should also start creating the testcases. This reduces the overall
project duration, since the test infrastructure related tasks are in parallel (unlike in case of waterfall
model, where these activities starts after Development stage is done). Since the development team
and the quality assurance team are working together from the beginning, there will be better
synchronization between development and testing.

Since the diagram is in the V shape, it is called V model.

Fig. 1.2.1.2. V model of software development

1.2.1.4. Spiral Model

In this model, initially a set of features are taken and tried to be implemented. Implementing these
subset of features follows all the stages from requirement gathering till testing. At the end of this, a
prototype of the product is developed. Then some more features are added to the existing prototype
and similar stages of development and another prototype is developed. This process goes on until all
features are implemented.

The advantage of this model is that at each prototype stage, we can very well make assessment of the
product being developed. Customer can provide feedback on the features implemented. This
eliminates surprises by the customer when the product is released to the customer.

Since the development happens like a spiral, it is called spiral model. Fig 1.2.1.3 shows the spiral
model.
Fig. 1.2.1.3. Spiral model of software development

Source: https://en.wikipedia.org/wiki/Spiral_model#/media/File:Spiral_model_(Boehm,_1988).svg

1.2.1.5. Agile Scrum

Agile Scrum methodology is quite popular method of software development now a days. It is a specific
case of Spiral Model.

Here the entire development cycle is divided into multiple ‘sprints’. A sprint is usually of 2 to 3 weeks.
But there can be slight variation from this as well.

The entire requirements are called ‘Product Backlog’. This product backlog is divided into multiple
buckets meant for each sprint. The subset of product backlog meant for a sprint is called ‘Sprint
Backlog’. In a sprint, the requirements specified by the sprint backlog should be implemented.

Each sprint needs to have all stages of software development e.g. Architecture to Testing
(Requirements phase is not there, since requirements are specified by the sprint backlog. Similarly
maintenance phase comes after the product is released, hence that is also not there). At the end of a
sprint, the outcome of the sprint is shown to the customer (customer can be internal or external
customer) and feedback from the customer is taken. This is called ‘Sprint Review’. The sprint outcome
can be even a document which is the case at the beginning of the project. At later part of the project
the sprint output is usually a prototype. At the end of this review, if customer suggested any change,
then those change request are included as part of the Sprint Backlog for the next sprint. Similarly if
any requirements were not implemented during the current sprint, those requirements also should
be included in the sprint backlog of the following sprint.

The Agile process is team driven. So in the team, there should be one or more architects, few
developers and few testing folks. There will be a person called ‘Scrum Master’ whose job is to manage
the sprints. The ‘product owner’ will provide the product backlog to the team. The product owner can
be the project manager or the customer.

The team conducts a meeting called ‘stand-up’ meeting everyday before starting the work, where the
team member could discuss that next to be done, if any help is needed by anyone etc. Usually it
happens on the cubicles of the team members, that’s why it is called ‘stand-up’ meeting.

There are many details related to this process. Interested people should study relevant documents.
There are several tools available to manage the projects following agile scrum methodology.

The main advantage of this process is the involvement of customer from the beginning of the project.
This way it avoids last minute customer surprises.

This also keep the team members in sync all the time thereby improving the project delivery time and
quality.

Fig 1.2.1.4 shows Agile Scrum methodology.

Fig. 1.2.1.4. Agile Scrum Model