Chapter 2 – Software Process Models

1
Software process models

2
The waterfall model

3
Waterfall model phases

4
Waterfall model problems

5
 IS The Classical WATERFALL MODEL USEFUL
AT ALL?

6
ITERATIVE WATERFALL MODEL

Chapter 2 Software Processes 7

 ITERATIVE WATER FALL MODEL

 NECESSARY CHANGES(FEEDBACK PATH) FROM

EVERY PHASE TO PRECEEDING FACE IS INTRODUC
ED

CORRECTION OF EROORS COMMITTED DURING THE

PHASE WHEN THESE ARE DETECTED AT LATER
STAGE.
EXAMPLE : DESIGN ERROR
DESIGN IS TO BE REWORK AND CHANGES
TO BE REFLECTED BACK In DESIGN DOCUMENTS
8
SHORT COMING OF WATERFALL MODEL

 CAN NOT HANDLE DIFFERENT TYPE OF RISKS

 SCHEDULE SLIPPAGE
 TECHNOLOGY OBSELENCE
 MAN POWER SHORTAGE
To Achieve better efficiency & Better Productivity
 REAL PROJECT FIND IT DIFFICULT TO FOLLOW
RIGID PHASE SEQUANCE
IT WILL CREATE BLOCKING STATES IN THE
SYSTEM

9
 Increment Delivery not supported
 Phase overlap not supported
 Limited Customer Interaction
 Heavy Weight
 No support for risk Handling and Code Reuse

10
V SHAPE SDLC
MODEL

11
V SHAPE SDLC MODEL

 EXTENSION OF WATERFALL MODEL

 FOCUSES ON ENHANCING THE QUALITY OF THE
SOFTWATE BY EXTENDING TESTING PROCEDURE
IN THE SDLC
 INSTEAD OF MOVING IN A LINEAR WAY. V SAHPE
MODEL BENDS UPWARDS AFTER THE CODING
PHASE.
DEVELOPMENT & TESTING PHASES CAN BE
CONDUCTED In PARALLEL

12
 DEVELOPMENT PHASES ARE CALLED VERIFICATION
 TESTING PHASES ARE CALLED VALIDATION,.

 V SHAPE MODEL PRODUCES EXCELLENT WORK PODUCT DELIVERY

IN THE FORM OF DETAILED DOCUMENTS and QULAITY S/W

PRODUCTS.

13
The V-Model

14
 Coping with changes In S/W DEVELOPMENT

 Change is inevitable in all large software projects.

 Business changes lead to new and changed system
requirements
 New technologies open up new possibilities for improving
implementations
 Changing platforms require application changes
 Change leads to rework so the costs of change include
both rework (e.g. re- analysing requirements) as well as
the costs of implementing new functionality

15
Reducing the costs of rework

 Change avoidance, where the software process includes

activities that can anticipate possible changes before
significant rework is required.
 For example, a prototype system may be developed to show
some key features of the system to customers.
 Change tolerance, where the process is designed so that
changes can be accommodated at relatively low cost.
 This normally involves some form of incremental development.
Proposed changes may be implemented in increments that have
not yet been developed. If this is impossible, then only a single
increment (a small part of the system) may have be altered to
incorporate the change.

16
Software prototyping

17
 PROTOTYPING

 A prototype is an initial version of a software system that

is used to demonstrate concepts, try out design options,
and find out more about the problem and its possible
solutions.
 Rapid iterative development of the prototype is
essential so that costs are controlled and system
stakeholders can experiment with the prototype
early in the software process.

18
Benefits of prototyping

19
The process of prototype development

20
Throw-away prototypes

21
THROWAWAY PROTOPTYPE

22
EXPLORATORY PROTOPTYPE

Chapter 2 Software Processes 23

 THROW AWAY PROTOYPE ONLY PROVIDE RICH
SET OF REQUIREMENTS
A BETTER APPROACH WOULD BE TO PRODUCE
PROTOYPE WITH SOMEWHAT BETTER DESIGN AND
QUALITY MEASUUES SO THAT FINALLY AGREED
PROTOYPE MAY BE AMENDED INTO DELIVERABLE
SOFTWARE THROUGH MINIMAL MODIFICATION
RATHER THAN BEING DISCARDRD

24
 PROTYPE IS CREATED WITH APPROPRATE
QUALITY MEASURES in THE EXPLORATORY
MODEL.
 PROTOTYPES ARE DESIGNED IN EXTENDABE
MANNER SO THAT NEXT VERSION OF PROTOTYPE
 IS IMPLEMENTED ON THE TOP OF THE PREVIOUS
ITSELF.
 FINAL PRODUCT IS DELIVERED SOON AFTER THE
FINALIZATION OF SPECIFICATION

25
Incremental development

26
Incremental delivery

27
Incremental development and delivery

 Incremental development
 Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment;
 Normal approach used in agile methods;
 Evaluation done by user/customer proxy.
 Incremental delivery
 Deploy an increment for use by end-users;
 More realistic evaluation about practical use of software;
 Difficult to implement for replacement systems as increments
have less functionality than the system being replaced.

28
Incremental delivery

29
Incremental delivery advantages

30
Incremental development benefits

31
Incremental development problems

 The process is not visible.

 Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
 System structure tends to degrade as new increments
are added.
 Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.

32
Incremental delivery problems

 Most systems require a set of basic facilities that are

used by different parts of the system.
 As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities that
are needed by all increments.
 The essence of iterative processes is that the
specification is developed in conjunction with the
software.
 However, this conflicts with the procurement model of many
organizations, where the complete system specification is part of
the system development contract.

33
Reuse-oriented software engineering
 Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
 Commercial-off-the-shelf (COTS) software and services are built and delivered usually
from a third party vendor. COTS can be purchased, leased or even licensed to the general
public .
 Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 Reuse is now the standard approach for building many
types of business system
34
Reuse-oriented software engineering

35
 Component analysis given the requirements specification , a search is made
for components to implement that specification.
 Requirement modification during this stage the requirement are analyzed
using information about the component that have been discovered. They are
then modified to reflect the available component.
 System design with reuse during this phase the framework of the system is
designed or an existing framework is reused. The designer take into account
the component that are used and organized the framework to cater for this.
 Development and integration software that can not be externally procured is
developed and the components and COTS systems are integrated to create
a new system.

36
Types of software component that May be used

 Web services that are developed according to service

standards and which are available for remote invocation.
 Collections of objects that are developed as a package
to be integrated with a component framework such
as .NET or J2EE.
 Stand-alone software systems (COTS) that are
configured for use in a particular environment.

37
Boehm’s spiral model

38
Boehm’s spiral model of the software process

39
Spiral model sectors

40
Software Development Life Cycle Models

Strengths ,Weakness
&
Applicability
 Waterfall Model

Strengths
 It provides structure to technically weak or
inexperienced staff .
 When correctly applied, defects may be found early,
when they are relatively inexpensive to fix.
 It is easy to use as development proceeds one phase
after another.
Strengths

 It allows staff who have completed their phase activities

to be freed up for other projects.
 It is easy to track the progress of the project using a
timeline or Gantt chart.
 It provides a template into which methods for
analysis ,design,code,test,and support can be placed.
Weakness

 It has an inherently linear sequential nature – any

attempt to go back two or more phases to correct a
problem results in major increases in cost and schedule.
 Users can’t see quality until the end .They can’t
appreciate quality if the finished product can’t be seen.
Weakness

 It doesn’t reflect the problem –solving nature of software

development .Phases are tied rigidly to activities , not
how people or teams really work.
 It isn’t possible for the user to get used to the system
gradually .All training must occur at the end of the life
cycle ,when the software is running .
Weakness

 Tight management and control is needed because

there is no provision for revising the requirement .
 Each phase is a prerequisite for the succeeding activities
, making this method a risky choice for unprecedented
systems because it inhibits flexibility.
V-shaped Model

Strengths
 The model encourages verification and validation of all
internal and external deliverables, not just the software
product.
 The model encourages definition of the requirement
before designing the system , and it encourages
designing the software before building the components.
Strengths

 It defines the product that the development process

should generate ; each deliverable must be testable.
 It enables project management to track progress
accurately ; the progress of the project follows a timeline
, and the completion of each phase is a milestone.
 Model is easy to use .
Weakness

 It does not handle concurrent events .

 It does not handle iterations of the phases .
 The model is not equipped to handle dynamic changes in
the requirement throughout the life cycle.
 The requirement are tested too late in the cycle to make
changes without affecting the schedule for the project.
Structured Evolutionary rapid prototyping model

Strengths
 The end user can see the system requirements as they
are being gathered by the project team –customer gets
early interaction with the system .
 The model allows for flexible design and
development ,including multiple iterations through life
cycle phases .
Strengths

 Steady , visible signs of progress are produced , making

customer secure.
 Communication issues between customers and
developers are minimized.
 Users tend to be more satisfied when involved
throughout the life cycle.
 Risk control is provided.
Weakness

 The model may not be accepted due to a reputation

among the conservatives as a “quick –and –dirty”
method.
 Sometimes a system with poor performances is
produced ,especially if the tuning stage is skipped.
 If the user cannot be involved during the prototype
iteration phase of the life cycle , the final product may
suffer adverse effects .
Weakness

 Prototyping is habit –forming and may go on too

long .Undisciplined developers may fall into a code-and –
fix cycle, leading to expensive , unplanned prototype
iterations .
 There may be tendency for difficult problems to be
pushed to the future , causing the initial promise of the
prototype to not be met by subsequent products.
Rapid Application Development model

Strength
 Cycle time for the full product can be reduced due to the
use of powerful development tools
 Fewer developers are required because the system is
developed by a project team familiar with the problem
domain .
 The time –box approach mitigates cost and schedule
risk.
Strengths

 Constant integrations isolate problems and encourages

customer feedback.
 The focus moves from documentation to code –what you
see is what you get(WYSIWYG)
 It reuses existing program components.
 It makes effective use off –the-shelf tools and framework.
Weakness

 If the users cannot be involved consistently throughout

the life cycle, the final product will be adversely affected.
 Highly skilled and well-trained developers are required.
 It requires a system that can be properly modularized.
 Hard to use with legacy system.
Weakness

 Risk of never achieving closure

 It can fail if reusable components are not available.
Incremental Model

Strength
 Operational product is delivered first.
 The divide and conquer rule allows the problem to be
broken down into manageable pieces.
 Initial delivery cost is lowered.
 Risk of failure and changing requirements is reduced.
Strengths

 Customer can see the most important, most useful

function early.
 Risk is spread across several smaller increments instead
of concentrating in one large development.
 Project momentum can be maintained
Weakness

 The model does not allow for iteration within each

increment.
 The definition of complete and fully functional system
must be done early in the life cycle to allow for the
definition of the increments.
 Since some modules will be completed before others,
well defined interfaces are required.
Weakness

 Formal reviews and audits are difficult to implement on

increments than on a complete system.
 Use of general objectives, rather than complete
requirements, in the analysis phase can be
uncomfortable for managemnet.
Spiral Model

Strengths
 The spiral model allows users to see the system early,
through the use of rapid prototyping in the development
life cycle.
 It provides early indications of risk without much cost.
 It splits a potentially large development effort into small
chunks.
Strengths

 It provides early and frequent feedback from user to

developers, ensuring a correct product with high quality.
 All the money needed for the project need not be
allocated up-front when the spiral model is adopted.
 It provides productivity improvement through reuse
capabilities.
Strengths

 It does not rely on the impossible task of getting the

design perfect.
 Management control of quality, correctness, cost,
schedule and staffing is improved through reviews at
conclusion of each iteration.
Weakness

 The time spent evaluating the risk after each spiral is

costly.
 The model is complex to use.
 Considerable risk assessment expertise is required.
 The spiral may continue indefinitely, generated by each
of the customer’s response to the build initiating a new
cycle; closure may be difficult to achieve.
Weakness

 The large number of intermediate stages can create

additional internal and external documentation to
process.
 Use of model may be expensive and even unaffordable.
 It can be hard to define objective, verifiable milestones
that include readiness to proceed through the next
iteration.
 The industry has not had as much experience with the
spiral model as it has with others.
Spiral model usage

 Spiral model has been very influential in helping people

think about iteration in software processes and
introducing the risk-driven approach to development.
 In practice, however, the model is rarely used as
published for practical software development.

67
The Rational Unified Process

68
Phases in the Rational Unified Process

69
RUP phases

70
RUP iteration

 In-phase iteration
 Each phase is iterative with results developed incrementally.
 Cross-phase iteration
 As shown by the loop in the RUP model, the whole set of phases
may be enacted incrementally.

71
Static workflows in the Rational Unified Process

Workflow Description
Business modelling The business processes are modelled using business
use cases.
Requirements Actors who interact with the system are identified and
use cases are developed to model the system
requirements.

Analysis and design A design model is created and documented using

architectural models, component models, object
models and sequence models.

Implementation The components in the system are implemented and

structured into implementation sub-systems.
Automatic code generation from design models helps
accelerate this process.

72
Static workflows in the Rational Unified Process

Workflow Description
Testing Testing is an iterative process that is carried out in conjunction
with implementation. System testing follows the completion of
the implementation.
Deployment A product release is created, distributed to users and installed in
their workplace.
Configuration and This supporting workflow managed changes to the system (see
change management Chapter 25).
Project management This supporting workflow manages the system development (see
Chapters 22 and 23).
Environment This workflow is concerned with making appropriate software
tools available to the software development team.

73
RUP good practice

74
Chapter 3 – Agile Software Development

75
Rapid software development

 Rapid development and delivery is now often the most

important requirement for software systems
 Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
 Software has to evolve quickly to reflect changing business
needs.
 Rapid software development
 Specification, design and implementation are inter-leaved
 System is developed as a series of versions with stakeholders
involved in version evaluation
 User interfaces are often developed using an IDE and graphical
toolset.
76
Agile methods

77
Agile manifesto

 We are uncovering better ways of developing software

by doing it and helping others do it. Through this work
we have come to value:
 Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
 That is, while there is value in the items on the right, we
value the items on the left more.

78
The principles of agile methods

Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.

79
Agile method applicability

 Product development where a software company is

developing a small or medium-sized product for sale.
 Custom system development within an organization,
where there is a clear commitment from the customer to
become involved in the development process and where
there are not a lot of external rules and regulations that
affect the software.
 Because of their focus on small, tightly-integrated teams,
there are problems in scaling agile methods to large
systems.

80
Problems with agile methods

81
Agile methods and software maintenance

 Most organizations spend more on maintaining existing

software than they do on new software development. So,
if agile methods are to be successful, they have to
support maintenance as well as original development.
 Two key issues:
 Are systems that are developed using an agile approach
maintainable, given the emphasis in the development process of
minimizing formal documentation?
 Can agile methods be used effectively for evolving a system in
response to customer change requests?
 Problems may arise if original development team cannot
be maintained.
82
Plan-driven and agile development

 Plan-driven development
 A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced at
each of these stages planned in advance.
 Not necessarily waterfall model – plan-driven, incremental
development is possible
 Iteration occurs within activities.
 Agile development
 Specification, design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.

83
Plan-driven and agile specification

84
Most S/W Projects include practices From Plan Driven and Agile Approaches.
To Decide on the Balance between Plan Driven and agile Approach
We have to Answer following technical, human and organization Questions :

 Is it important to have a very detailed specification and design

before moving to implementation? If so, you probably need to use
a plan-driven approach.
 Is an incremental delivery strategy, where you deliver the software
to customers and get rapid feedback from them, realistic? If so,
consider using agile methods.
 How large is the system that is being developed? Agile methods
are most effective when the system can be developed with a small
co-located team who can communicate informally. This may not
be possible for large systems that require larger development
teams so a plan-driven approach may have to be used.

85
Technical, human, organizational issues

 What type of system is being developed?

• Plan-driven approaches may be required for systems that require a lot
of analysis before implementation (e.g. real-time system with complex
timing requirements).
 What is the expected system lifetime?
• Long-lifetime systems may require more design documentation to
communicate the original intentions of the system developers to the
support team.
 What technologies are available to support system development?
• Agile methods rely on good tools to keep track of an evolving design
 How is the development team organized?
• If the development team is distributed or if part of the development is
being outsourced, then you may need to develop design documents to
communicate across the development teams.

86
 Are there cultural or organizational issues that may affect the
system development?
• Traditional engineering organizations have a culture of plan-based
development, as this is the norm in engineering.
 How good are the designers and programmers in the
development team?
• It is sometimes argued that agile methods require higher skill levels
than plan-based approaches in which programmers simply translate
a detailed design into code
 Is the system subject to external regulation?
• If a system has to be approved by an external regulator (e.g. the
FAA approve software that is critical to the operation of an aircraft)
then you will probably be required to produce detailed
documentation as part of the system safety case.

87
 AGILE DEVELOPMENT MODELS

 Waterfall Model was not suitable for Present Day

Software Projects
 Requirement Request During Development Satge
 Caper jones Carried out resarch 800 Real time
Software Projects and concluded
 40% of the Requirements arrives after the Development
Begins
Several Models have been Proposed in Last two
Decades to overcome the short comings of WF Model

88
 TWO Changes have been Noticed last two Decades
 Development of Customized software
 Increased Emphasis and Scope for Reuse.

89
Reasons WHY WF Model is Unsuitable as PER
Modern Software Pracices

 Dynamic Reuirements
 Cutomised Applications becomes POPULAR
 W.F IS Heavy Weight Model
(two much emphasis on producing documentation &
usage of tools)
Customer Interaction is almost Nill

90
AGILE SOFTWARE DEVELOPMENT MODEL

 Proposed in 1995 to overcome the Shortcoming of W.F

Model
 Designed to adapt the Dynamic Requirements
 To Facilitate quick Project completion.
 Agility is achieved ( Removing activities that may not be
necessary for a Specific Project) also anything that
wastes time and effort is avoided.
 Agile model is being used as an umbrella term to refer
to a group of development Processes

91
Agility Principles - I

92
Agility Principles - II

93
Human Factors

94
 Methodology OF Agile Models

 Requirements are Decomposed into small Parts that can

be Incremented
 Adopts iterative approach( Each Increment Part is
Developed over an Iteration)
 Each iteration is Intended to be small and easily
Manageable and lasting couple of Days.
 At a time only one increment is planned , Developedand
then Deployed at customer site.
 No Long TERm Plan are Made.
 The time to complete an iteration is called time box

95
 The End Date Does not change ( Delivery Date is
considered Sacrosanct.

 Delivery of an increment is done after each time Box

96
Essential Idea Behind Agile Models

 To connect with customer during Development and to

gain a clear Understanding of domain Specific Issues.
 Each Agile Project usually includes Customer
representative in its team
 After each Iteration Progress is Monitored
 Distinguished Characteristic of Agile Models is frequent
Delivery of software increments to Customer
Agile Models Emphasis on Face to Face Communication
Development Team is kept Small (5-9)

97
 Suited for Small Projects
 Agile Models Emphasizes incremental Release of
working software as the Primary measure of Progress
 Deploy Pair Programming

98
 Limitations of Agile Method

Lack Of formal documents leaves Scope for Confusion

and Important Decision Taken during different phases
can be misinterpreted. At later point of time by team
members.

In the Absence of formal Documents it becomes difficult

To get important Project Decision such Desgin to be
reviewed by External Team experts
Maintenance is difficult.

99
AGILE SDLC MODELS

 Crystal
 Atern
 Scrum
 Extreme Programming(XP)
 Lean Development
 Unified Process

100
SPIRAL MODEL

101
Spiral Model

 Proposed by Boehm in 1988.

 Each loop of the spiral represents a phase
of the software process:
 the innermost loop might be concerned with
system feasibility,
 the next loop with system requirements
definition,
 the next one with system design, and so on.
 There are no fixed phases in this model,
the phases shown in the figure are just
examples. 102
Spiral Model (CONT.)

103
Spiral Model (CONT.)

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product

104
Objective Setting (First Quadrant)

105
Risk Assessment and Reduction (Second Quadrant)

106
Spiral Model (CONT.)

107
Spiral Model as a meta model

 Subsumes all discussed models:

 a single loop spiral represents waterfall model.
 uses an evolutionary approach --
• iterations through the spiral are evolutionary levels.
 enables understanding and reacting to risks during each
iteration along the spiral.
 uses:
• prototyping as a risk reduction mechanism
• retains the step-wise approach of the waterfall model.

108
Comparison of Different Life Cycle
Models
 Iterative waterfall model
 most widely used model.
 But, suitable only for well-understood problems.

 Prototype model is suitable for projects not well

understood:
 user requirements
 technical aspects

109
Comparison of Different Life Cycle
Models (CONT.)

110
 Selecting An Appropriate Life cycle Model
for A Project

 A suitable Life cycle Model Can possibly be Selected

based on an analysis of issues such as following
 1. Characteristics of the software to be Developed

 2. Charecteristics of the Development Team

 3. Charactetristcs of Development team

111
 REFERNCES

 1. Fundamental of software Engineering fourth Edition

Rajib Mall PHI 2014 Edition

2. Software Engineering : Ninth Edition 2014

Ian sommerville Pearson Education

112