Introduction to Software

Engineering

Software Life Cycle Models

Prof. Nasir Shahzad

Elite College of Management Sciences
 1

CLASSICAL WATERFALL MODEL

The classical waterfall model is intuitively the most obvious way to develop software. Though the classical waterfall
model is elegant and intuitively obvious, it is not a practical model in the sense that it cannot be used in actual
software development projects. Thus, this model can be considered to be a theoretical way of developing software.
But all other life cycle models are essentially derived from the classical waterfall model. So, in order to be able to
appreciate other life cycle models it is necessary to learn the classical waterfall model. Classical waterfall model
divides the life cycle into the following phases as shown in figure.

Feasibility study - The main aim of feasibility study is to determine whether it would be financially and technically
feasible to develop the product.
 At first project managers or team leaders try to have a rough understanding of what is required to be done by
visiting the client side. They study different input data to the system and output data to be produced by the
system. They study what kind of processing is needed to be done on these data and they look at the various
constraints on the behavior of the system.

 After they have an overall understanding of the problem they investigate the different solutions that are
possible. Then they examine each of the solutions in terms of what kind of resources required, what would be
the cost of development and what would be the development time for each solution.
 2

 Based on this analysis they pick the best solution and determine whether the solution is feasible financially
and technically. They check whether the customer budget would meet the cost of the product and whether
they have sufficient technical expertise in the area of development.

Requirements analysis and specification: - The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to document them properly. This phase consists of two
distinct activities, namely
 Requirements gathering and analysis
 Requirements specification

The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the
product to be developed. This is done to clearly understand the customer requirements so that incompleteness and
inconsistencies are removed.
The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed
from the users of the product and from the customer through interviews and discussions. For example, to perform the
requirements analysis of a business accounting software required by an organization, the analyst might interview all
the accountants of the organization to ascertain their requirements. The data collected from such a group of users
usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete
view of the system. Therefore it is necessary to identify all ambiguities and contradictions in the requirements and
resolve them through further discussions with the customer. After all ambiguities, inconsistencies, and
incompleteness have been resolved and all the requirements properly understood, the requirements specification
activity can start. During this activity, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document. The customer requirements identified during the requirements
gathering and analysis activity are organized into a SRS document. The important components of this document are
functional requirements, the nonfunctional requirements, and the goals of implementation.

Design: - The goal of the design phase is to transform the requirements specified in the SRS document into a
structure that is suitable for implementation in some programming language. In technical terms, during the design
phase the software architecture is derived from the SRS document. Two distinctly different approaches are available:
the traditional design approach and the object-oriented design approach.
 Traditional design approach -Traditional design consists of two different activities; first a structured
analysis of the requirements specification is carried out where the detailed structure of the problem is
examined. This is followed by a structured design activity. During structured design, the results of structured
analysis are transformed into the software design.
 Object-oriented design approach -In this technique, various objects that occur in the problem domain and
the solution domain are first identified, and the different relationships that exist among these objects are
identified. The object structure is further refined to obtain the detailed design.

Coding and unit testing:-The purpose of the coding phase (sometimes called the implementation phase) of software
development is to translate the software design into source code. Each component of the design is implemented as a
program module. The end-product of this phase is a set of program modules that have been individually tested.
During this phase, each module is unit tested to determine the correct working of all the individual modules. It
involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage.
Integration and system testing: -Integration of different modules is undertaken once they have been coded and unit
tested. During the integration and system testing phase, the modules are integrated in a planned manner. The
different modules making up a software product are almost never integrated in one shot. Integration is normally
carried out incrementally over a number of steps. During each integration step, the partially integrated system is
tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully
integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system
 3

conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of
testing activities:
 α – testing: It is the system testing performed by the development team.
 β –testing: It is the system testing performed by a friendly set of customers.
 Acceptance testing: It is the system testing performed by the customer himself after the product delivery to
determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan document. The system
test plan identifies all testing-related activities that must be performed, specifies the schedule of testing, and allocates
resources. It also lists all the test cases and the expected outputs for each test case.
Maintenance: -Maintenance of a typical software product requires much more than the effort necessary to develop
the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of
development of a typical software product to its maintenance effort is roughly in the 40:60 ratios. Maintenance
involves performing any one or more of the following three kinds of activities:

 Correcting errors that were not discovered during the product development phase. This is called corrective
maintenance.
 Improving the implementation of the system, and enhancing the functionalities of the system according to the
customer’s requirements. This is called perfective maintenance.
 Porting the software to work in a new environment. For example, porting may be required to get the software
to work on a new computer platform or with a new operating system. This is called adaptive maintenance.

Shortcomings of the classical waterfall model

The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the
engineers during any of the life cycle phases. However, in practical development environments, the engineers do
commit a large number of errors in almost every phase of the life cycle. The source of the defects can be many:
oversight, wrong assumptions, use of inappropriate technology, communication gap among the project engineers,
etc. These defects usually get detected much later in the life cycle. For example, a design defect might go unnoticed
till we reach the coding or testing phase. Once a defect is detected, the engineers need to go back to the phase where
the defect had occurred and redo some of the work done during that phase and the subsequent phases to correct the
defect and its effect on the later phases. Therefore, in any practical software development work, it is not possible to
strictly follow the classical waterfall model.
 4

ITERATIVE WATERFALL MODEL

To overcome the major shortcomings of the classical waterfall model, we come up with the iterative waterfall
model.

Here, we provide feedback paths for error correction as & when detected later in a phase. Though errors are
inevitable, but it is desirable to detect them in the same phase in which they occur. If so, this can reduce the effort to
correct the bug.
The advantage of this model is that there is a working model of the system at a very early stage of development
which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to
take corrective measures in a limited budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky software development
projects. This is because it is hard to break a small software system into further small serviceable
increments/modules.
 5

PRTOTYPING MODEL
Prototype
A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low
reliability, and inefficient performance compared to the actual software. A prototype is usually built using several
shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut
implementation of a function, for example, may produce the desired results by using a table look-up instead of
performing the actual computations. A prototype usually turns out to be a very crude version of the actual system.
Need for a prototype in software development
There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports,
and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the
customer’s needs:
 how the screens might look like
 how the user interface would behave
 how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many
researchers and engineers advocate that if you want to develop a good product you must plan to throw away the first
version. The experience gained in developing the prototype can be used to develop the final product.
A prototyping model can be used when technical solutions are unclear to the development team. A developed
prototype can help engineers to critically examine the technical issues associated with the product development.
Often, major design decisions depend on issues like the response time of a hardware controller, or the efficiency of a
sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical
issues.
A prototype of the actual product is preferred in situations such as:
• User requirements are not complete
• Technical issues are not clear

Fig: Prototype Model

 6

EVOLUTIONARY MODEL

It is also called successive versions model or incremental model. At first, a simple working model is built.
Subsequently it undergoes functional improvements & we keep on adding new functions till the desired system is
built.
Applications:
 Large projects where you can easily find modules for incremental implementation. Often used when the
customer wants to start using the core features rather than waiting for the full software.
 Also used in object oriented software development because the system can be easily portioned into units in
terms of objects.

Advantages:
 User gets a chance to experiment partially developed system
 Reduce the error because the core modules get tested thoroughly.

Disadvantages:
 It is difficult to divide the problem into several versions that would be acceptable to the customer which can
be incrementally implemented & delivered.
 7

SPIRAL MODEL

The Spiral model of software development is shown in figure. The diagrammatic representation of this model
appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral
represents a phase of the software process. For example, the innermost loop might be concerned with feasibility
study, the next loop with requirements specification, the next one with design, and so on. Each phase in this model is
split into four sectors (or quadrants) as shown in fig. 4.1. The following activities are carried out during each phase
of a spiral model.

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a
prototype system may be developed.
 8

Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks

Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration around the spiral.
• Progressively more complete version of the software gets built with each iteration around the spiral.

Circumstances to use spiral model

The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently
built into this model. The spiral model is suitable for development of technically challenging software products that
are prone to several kinds of risks. However, this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.
Comparison of different life-cycle models
The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments
of this model. However, the classical waterfall model cannot be used in practical development projects, since this
model supports no mechanism to handle the errors committed during any of the phases.
This problem is overcome in the iterative waterfall model. The iterative waterfall model is probably the most widely
used software development model evolved so far. This model is simple to understand and use. However this model is
suitable only for well-understood problems; it is not suitable for very large projects and for projects that are subject
to many risks.
The prototyping model is suitable for projects for which either the user requirements or the underlying technical
aspects are not well understood. This model is especially popular for development of the user-interface part of the
projects.

The evolutionary approach is suitable for large problems which can be decomposed into a set of modules for
incremental development and delivery. This model is also widely used for object-oriented development projects. Of
course, this model can only be used if the incremental delivery of the system is acceptable to the customer.
The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently
built into this model. The spiral model is suitable for development of technically challenging software products that
are prone to several kinds of risks. However, this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.
The different software life cycle models can be compared from the viewpoint of the customer. Initially, customer
confidence in the development team is usually high irrespective of the development model followed. During the
lengthy development process, customer confidence normally drops off, as no working product is immediately
visible. Developers answer customer queries using technical slang, and delays are announced. This gives rise to
customer resentment. On the other hand, an evolutionary approach lets the customer experiment with a working
product much earlier than the monolithic approaches. Another important advantage of the incremental model is that
it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of the product
via incremental phases provides time to the customer to adjust to the new product. Also, from the customer’s
financial viewpoint, incremental development does not require a large upfront capital outlay. The customer can order
the incremental versions as and when he can afford them.