CHAPTER 2

SOFTWARE DEVELOPMENT
LIFE CYCLE
CONVENTIONAL LIFE CYCLE MODELS

• Build and Fix Model

• Waterfall Model
• Prototype Model
• Iterative Enhancement Model
• Spiral Model
• Extreme Model
BUILD AND FIX MODEL
 WATERFALL MODEL
• It has five phases: requirement analysis, design, implementation and unit
testing, integration and testing, and deployment and maintenance.
• The phases are completed in sequential order and do not overlap with each
other.
• Each phase defines its own set of functions that are distinct from those of
the other phases.
• Each phase should be completed before the commencement of the next
phase. The output from one phase goes as input into the next phase.
 PROTOTYPING MODEL
• In prototyping model, a working prototype is constructed in order to
determine and understand the customer’s needs.
• The customer evaluates this prototype and then the final SRS document is
prepared on the basis of refined requirements.
• Since the prototype will finally be discarded, it need not be flexible,
maintainable and fault tolerant.
ITERATIVE ENHANCEMENT MODEL

• The iterative enhancement model broadly consists of three iterative phases—design,

implementation and analysis by customer.
• After the requirement analysis, these phases are carried out repeatedly until complete
functionality is delivered to the customer.
• After the final release, the system goes into the maintenance phase.
• The iterative enhancement model allows to accommodate changing requirements
and adds new features to the software during each phase.
• In the iterative enhancement model, the later software increments may require
modifications in earlier ones which may increase costs.
 SPIRAL MODEL
• The spiral model is a risk-driven model that deals with uncertainty of the outcome of an
activity.
• Risk measures the combined effect of probability of occurrence of failure and the impact
of that failure on the software operation.
• High risk activities may cause threat to the project.
• The spiral model is divided into four phases: determine objectives, alternatives and
constraints; evaluate alternatives, identify and resolve risks; develop and verify next-level
product; and plan next phases.
• Each cycle of the spiral model begins with identification of objectives, determination of
alternative means of implementing the specified part of the product and identification of
constraints imposed on the completion of the portion of the product.
 • The spiral model repeats the four phases to the following rounds as shown in Figure.
Round 0:
Feasibility study: As recommended by Boehm (1986), the initial round 0 must be carried out in order to
determine the feasibility of the system in terms of resources, cost, schedule and productivity.
Round 1:
Concept of operation: The output of this round is a basic requirement of the life cycle plan for the
implementation of the concepts emerged till now.
Round 2:
Top-level requirements analysis: In this round, the requirements are specified and validated following the
risk-driven approach. The output produced is the development plan.
Round 3:
Software design: A preliminary design is created, verified and validated. Integration and test plan is produced
after the completion of round 3.
Round 4:
Design, implementation and testing: Round 4 constructs the detailed design of the product. This includes
coding, unit testing, integration testing and acceptance testing.
 EXTREME PROGRAMMING
• XP is based on the principles of agile processes.
• Agile means the ability to move quickly and easily.
• The agile process is both quick and easy.
• Agile processes are based on team cohesiveness, quick feedbacks,
incremental development, experienced developers and automated testing.
• Extreme programming (XP) is a new, lightweight approach to developing software. XP uses rapid
feedback and high-bandwidth communication to maximize delivered value, via an on-site
customer, a particular planning approach, and constant testing.
• The features of XP include simple processes, continuous feedback, incremental growth, high
communication and courage. For this, the customer (a domain expert) is available at all the times.
• This reduces the feedback time greatly as the solution to a problem is obtained in a very short time
(few minutes to few hours).
• The software is developed iteratively and the self organizing teams adapt to the changes in the
methodologies easily.
OBJECT ORIENTED LIFE CYCLE
MODEL
• 1. Object-oriented requirement analysis: In this phase, the use case approach is used
for capturing requirements from the customer. The SRS document containing the use
case description may be produced during this phase.
• 2. Object-oriented analysis: In this phase, the objects and the interrelationships
between these objects are identified. The functions of the objects are determined. An
ideal structure is created in order to build high-quality maintainable software.
• 3. Object-oriented design: In this phase, the objects are defined in detail keeping in
mind the implementation environment. All the objects identified during the
object-oriented analysis phase must be traced to the design phase.
• 4. Object-oriented programming and testing: The objects, the functions
encapsulated in these objects and interactions amongst the objects are implemented in
terms of source code. The existing developed and well-tested components may be used
and new components are created. This feature supports reusability of the source code.
The developed components are tested using object-oriented testing techniques.
OBJECT ORIENTED LIFE CYCLE MODEL

• Fountain Model
• Rational Unified Process Model
 FOUNTAIN MODEL

• The fountain model provides a clear representation of iterations and overlapping

phases. The model emphasizes the reusability of the source code. The circles depict
the overlapping phases and the arrows within the circles depict iterations within the
phases. The smallest circle represents the maintenance phase showing that the
maintenance phase is the smallest in the fountain model.
• Changes can be easily made between class specification and requirement
specification. Since the system is developed in terms of classes, the phases of the
software development life cycle can be applied to individual classes rather than
system as a whole.
RATIONAL UNIFIED PROCESS MODEL

• Rational unified process (RUP) is maintained by Rational Software. It

provides a process framework that may be adapted by organizations
according to their needs.
• The RUP supports iterative software development where the software goes
through a series of short length mini projects called iterations.
• The RUP forms the basis for providing guidelines on the use of Unified
Modelling Language (UML).
 • The process can be divided into two structures:
1. Static structure: It provides the process description in terms of roles, activities,
artifacts, disciplines and workflows. The static structure of the RUP describes who
(roles) does how (activities), what (artifacts) and when (workflows). Five major
elements form the static structure of the RUP: role, activities, artifacts, disciplines
and workflows.
2. Dynamic structure: The dynamic aspect of the process can be viewed in terms
of iterative development. It consists of four phase: inception, elaboration,
construction and transition. Each phase achieves a predefined milestone that
ascertains the status of the project.
 • Inception is basically a non-iterative process as compared to the other phases which are highly
iterative. An iteration plan is developed that describes during which iteration which use case will be
implemented. The essential activities of the inception phase are as follows:
1. Establishment of scope and boundary of the project.
2. Determination of cost and schedule of the project.
3. Identification of actors and use cases.
4. Development of initial iteration plan.
5. Determination of high-level risks
• The elaboration phase consists of planning and architectural design. The requirements gathered in
the form of use cases are documented in the software requirement specification document. The
essential activities of the elaboration phase are as follows:
1. Establishment and validation of architectural baselines.
2. Addressing significant risks.
3. Design of use case model.
4. Selection of components and formation of policies for their purchase and usage.
5. Creation of detailed iteration plans.
6. Development of prototypes.
 • On the basis of architecture and design developed in the elaboration phase, the product
is developed and tested in the construction phase. During this phase, the remaining
requirements are determined. The deployable products are produced from this phase.
The essential activities of the construction phase are as follows:
1. Optimization of resources by avoiding rework and unnecessary coding.
2. Assessment and verification of quality.
3. Testing all the functionalities of the product. Testing activities include unit, integration
and system testing.
• The objective of this phase is to hand over the software product to the customer. This
phase includes delivering, training users and maintaining the software. Elaboration
involves beta releases, bug fixes and enhancement releases. Product release produces the
product that conforms to the customer’s requirements. The outcome of the transition
phase includes various reports and documents such as beta test reports, release notes,
training material and end-user support material.