A development life cycle for a software product involves capturing
the initial requirements from the customer, expanding on these to
provide the detail required for code production, writing the code and
testing the product, ready for release.
A simple development model is shown below. This is known traditionally as the waterfall model.
Waterfall model
The waterfall model in above figure shows the steps in sequence
where the customer requirements are progressively refined to the point
where coding can take place. This type of model is often referred to as a
linear or sequential model. Each work-product or activity is completed
before moving on to the next.
In the waterfall model, testing is carried out once the code has
been fully developed. Once this is completed, a decision can be made on
whether the product can be released into the live environment.
This model for development shows how a fully tested product can be
created, but it has a significant drawback: what happens if the product
fails the tests? Let us look at a simple case study.
CASE STUDY—DEVELOPMENT PROCESS
In a factory environment producing rivets for an aircraft fuselage,
checks are made by operators to assess the rivets on a conveyor belt.
This assessment may reveal a percentage of the rivets to be defective.
Usually this percentage is small, and does not result in the whole batch
of rivets being rejected. Therefore the bulk of the product can be
released.
Consider now the same aircraft, but the product is the software
controlling the display provided for the aircrew. If, at the point of
testing, too many defects are found, what happens next? Can we release
just parts of the system?
In the waterfall model, the testing at the end serves as a quality
check. The product can be accepted or rejected at this point. As we saw
in the case of rivet production, a single point of quality checking may
be acceptable, assuming that most rivets pass the quality check.
In software development, however, it is unlikely that we can simply
reject the parts of the system found to be defective, and release the
rest. The nature of software functionality is such that removal of
software is often not a clean-cut activity—this action could well cause
other areas to function incorrectly. It may even cause the system to
become unusable.
In addition, we may not be able to choose not to deliver anything at
all. The commercial and financial effects of this course of action
could be substantial.
What is needed is a process that assures quality throughout the
development life cycle. At every stage, a check should be made that the
work-product for that stage meets its objectives. This is a key point,
work-product evaluation taking place at the point where the product has
been declared complete by its creator. If the work-product passes its
evaluation (test), we can progress to the next stage in confidence. In
addition, finding problems at the point of creation should make fixing
any problems cheaper than fixing them at a later stage. This is the cost
escalation model as covered in the post.
The checks throughout the life cycle include verification and validation.
Verification—checks that the
work-product meets the requirements set out for it. An example of this
would be to ensure that a website being built follows the guidelines for
making websites usable by as many people as possible. Verification
helps to ensure that we are building the product in the right way.
Validation—changes the focus of work-product evaluation to
evaluation against user needs. This means ensuring that the behavior of
the work-product matches the customer needs as defined for the project.
For example, for the same website above, the guidelines may have been
written with people familiar with websites in mind. It may be that this
website is also intended for novice users. Validation would include
these users checking that they too can use the website easily.
Validation helps to ensure that we are building the right product as far
as the users are concerned.
There are two types of development model that facilitate early work-product evaluation.
The first is an extension to the waterfall model, known as the
V-model. The second is a cyclical model, where the coding stage often
begins once the initial user needs have been captured. Cyclical models
are often referred to as iterative models.
We will consider first the V-model.
V-Model (Sequential Development Model)
There are many variants of the V-model. One of these is shown in below Figure.
V-model for software development
As for the waterfall model, the left-hand side of the model focuses
on elaborating the initial requirements, providing successively more
technical detail as the development progresses. In the model shown,
these are:
- Requirement specification—capturing of user needs.
- Functional specification—definition of functions required to meet user needs.
- Technical specification—technical design of functions identified in the functional specification.
- Program specification—detailed design of each module or unit to be built to meet required functionality.
These specifications could be reviewed to check for the following:
- Conformance to the previous work-product (so in the case of
the functional specification, verification would include a check against
the requirement specification).
- That there is sufficient detail
for the subsequent work-product to be built correctly (again, for the
functional specification, this would include a check that there is
sufficient information in order to create the technical specification).
- That it is testable—is the detail provided sufficient for testing the work-product?
The
middle of the V-model shows that planning for testing should start with
each work-product. Thus, using the requirement specification as an
example, acceptance testing would be planned for, right at the start of
the development.
The right-hand side focuses on the testing activities. For each
work-product, a testing activity is identified. These are shown in above
Figure:
Testing against the requirement specification takes place at the acceptance testing stage.
Testing against the functional specification takes place at the system testing stage.
Testing against the technical specification takes place at the integration testing stage.
Testing against the program specification takes place at the unit testing stage.
This allows testing to be concentrated on the detail provided in
each work-product, so that defects can be identified as early as
possible in the life cycle, when the work-product has been created.
Remembering that each stage must be completed before the next one
can be started, this approach to software development pushes validation
of the system by the user representatives right to the end of the life
cycle. If the customer needs were not captured accurately in the
requirement specification, or if they change, then these issues may not
be uncovered until the user testing is carried out.
Iterative-Incremental Development Models
Let us now look at a different model for software
development—iterative development. This is one where the requirements do
not need to be fully defined before coding can start. Instead, a
working version of the product is built, in a series of stages, or
iterations—hence the name iterative or incremental development. Each
stage encompasses requirements definition, design, code and test. This
is shown diagrammatically in below figure.
Iterative development
This type of development is often referred to as cyclical—we go
‘round the development cycle a number of times’, within the project. The
project will have a defined timescale and cost. Within this, the cycles
will be defined. Each cycle will also have a defined timescale and
cost. The cycles are commonly referred to as time-boxes. For each
time-box, a requirement is defined and a version of the code is
produced, which will allow testing by the user representatives. At the
end of each time-box, a decision is made on what extra functionality
needs to be created for the next iteration. This process is then
repeated until a fully working system has been produced.
A key feature of this type of development is the involvement of user
representatives in the testing. Having the users represented throughout
minimizes the risk of developing an unsatisfactory product. The user
representatives are empowered to request changes to the software, to
meet their needs.
This approach to software development can pose problems, however.
The lack of formal documentation makes it difficult to test. To
counter this, developers may use test-driven development. This is where
functional tests are written first, and code is then created and tested.
It is reworked until it passes the tests.
In addition, the working environment may be such that developers
make any changes required, without formally recording them. This
approach could mean that changes cannot be traced back to the
requirements or to the parts of the software that have changed. Thus,
traceability as the project progresses is reduced. To mitigate this, a
robust process must be put in place at the start of the project to
manage these changes.
Another issue associated with changes is the amount of testing
required to ensure that implementation of the changes does not cause
unintended changes to other parts of the software (this is called
regression testing)
Forms of iterative development include prototyping, rapid
application development (RAD) and agile software development. A
proprietary methodology is the Rational Unified Process (RUP).
