Software process models

Topic – 2
Module -I
 Software Processes

• Coherent sets of activities for

specifying, designing, implementing
and testing software systems
 Software Process
• Fundamental Assumption:
– Good processes lead to good software
– Good processes reduce risk
– Good processes enhance visibility
 Variety of Software Processes
• Software products are very varied...
• Therefore, there is no standard process for all
software engineering projects
• BUT successful software development projects
all need to address similar issues.
• This creates a number of process steps that
must be part of all software projects
Basic Process Steps in all Software
Development
• Feasibility and planning
• Requirements
• Design
• Implementation
• Acceptance and release
• Operation and maintenance
 Combining the Process Steps

Feasibility and
Planning Requirements There are many
ways to combine the
processes

Design

Operation and
Implementation Maintenance
 Sequence of Processes
Every software project will include these basic processes, in some
shape or form, but:
• They may be formal or informal
• They may be carried out in various sequences
Examples:
• A feasibility study cannot create a proposed budget and
schedule without a preliminary study of the requirements and a
tentative design.
• Detailed design or implementation usually reveals gaps in the
requirements specification.
 Prescriptive Process Models

• Developed to bring order and structure to

the software development process.

•To get away from the chaos of most

development processes.
 Software Development Approaches
• Generic Software Process Models
1.The waterfall model
• Separate and distinct phases of specification and development

2.Evolutionary development
• Specification, development and testing are interleaved

• Formal systems development (example -

ASML)
– A mathematical system model is formally
transformed to an implementation
 The Waterfall Model
Feasibility study Requirements

Requirements analysis
Design

System design

Implementation
Program design

Coding

Testing

Acceptance

Operation & maintenance

 The Waterfall Model
• Advantages:
• Process visibility
• Separation of tasks
• Quality control
• Cost control

• Disadvantages:
– Each stage in the process reveals new understanding
of the previous stages, that requires the earlier stages
to be revised.
What is wrong with waterfall?
Requirements
Analysis

Maintenance System
Design

Installation Object
Design

Testing Coding

Interrelated  nonlinear, sequential

 Waterfall model problems
• Inflexible partitioning of the project into distinct
stages

• Difficult to respond to changing customer

requirements

• Therefore, this model is only appropriate when the

requirements are well-understood
 Why No to Waterfall?
Because software is different :
 No fabrication step
 Program code is another design level
 Hence, no “commit” step – software can always be changed…!
 No body of experience for design analysis
 Most analysis (testing) is done on program code
 Hence, problems not detected until late in the process
 Waterfall model takes a static view of requirements
 Ignore changing needs
 Lack of user involvement once specification is written
Unrealistic separation of specification from the
design
Doesn’t accommodate prototyping, reuse, etc
 Modified Waterfall Model
Feasibility study Waterfall model with
feedback
Requirements This is better!

System design

Program design

Coding

Testing

Acceptance

Operation & maintenance

 V-model
Requirements Acceptance
less detail

Analysis is validated by Testing

System System
Design Testing

Object Unit
Design Testing
more detail

Coding

build system validate system

• Advantages
❖ The model is simple and easy to use.
❖ The V model focuses on testing of all intermediate products, not only the
final software.
❖ The model plans for verification and validation activities early in the life
cycle thereby enhancing the probability of building an error free and good
quality product.
• Disadvantages
❖ The model does not support iteration of phases and change in requirements
throughout the life cycle.
❖ It does not take into account risk analysis.
 Incremental development
• The development and delivery is broken
down into increments
• Each increment delivering part of the
required functionality.
• User requirements are prioritised
• Highest priority requirements are included
in early increments.
• Once the development of an increment is
started, the requirements are frozen.
 The Incremental Model

increment # n
Co m m u n i c a t i o n
Pla nning

M ode ling
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

deliv ery of
nt h increment
increment # 2

Co m m u n i c a t i o n
Pla nning

M ode ling
analy s is Co n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment

Co m m u n ic a t io n
Pla nning
M ode ling
analy s is Co n s t ru c t i o n
des ign c ode De p lo y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k

1st increment

project calendar t ime

 Incremental Model
• Advantages
– System functionality is available earlier
– Early increments act as a prototype to help elicit
requirements for later increments
– Lower risk of overall project failure
– The highest priority system services tend to receive the
most testing
• Disadvantages
– First step gets a quick version that does part of project.
– Successive increments get better and more complete
software.
 Rapid Application Development

• Rapid Application Development – an

incremental model that emphasizes a short
development cycle.
 Rapid application development (RAD)

Team #1
Modeling
Communication
Construction

Planning

Deployment
Team #N
Modeling

Construction

Developed by James Martin

at IBM in 1980s
60 – 90 days
RAD has largely been discredited because it has not proved successful
"RAD is back", says IBM, Information Age, Feb. 10, 2006
 RAD
Advantages:
• Reduces risk of incorrect user requirements
• Good where requirements are changing/uncommitted
• Regular visible progress aids management
• Supports early product marketing

Disadvantages:
• An unstable/badly implemented prototype often becomes the final product.
• Requires extensive customer collaboration
– Costs customers money
– Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad market
• Difficult to know how long project will last
• Easy to fall back into code-and-fix without proper requirements analysis,
design, customer evaluation and feedback.
 Evolutionary Process Models
• Software evolves over time (web pages are a prime
example)

• Limited version is needed to meet business pressures.

• Time does not allow a full and complete system to be

developed.

• Evolutionary models are iterative as software

engineers develop increasingly more complete and
complex systems
 Characteristics of Evolutionary Development

• Modern development processes take evolution as fundamental,

and try to provide ways of managing, rather than ignoring, the
risk.
• System requirements always evolve in the course of a project.
• Specification is evolved in conjunction with the software – No
complete specification in the system development contract.
Difficult for large customers.
• Two (related) process models:
– Iterative development
– Spiral development
 Evolutionary Development
Concept: Initial implementation for user comment, followed
by refinement until system is complete.
• Vaporware: user interface mock-up
• Throw-away software components
• Dummy modules
• Rapid prototyping
• Successive refinement
Get something working as quickly as possible!
 Evolutionary Development
The feasibility Concurrent
study is Activities
continuous

Initial
Version
Requirements

Outline Intermediate
Description Design
Versions

Implementation Final
Version
 Prototyping

Communication

Feedback Quick plan

Delivery Quick modeling

Construct
Prototype
 Prototyping

• Built when goals are general and not specific.

• Can be used as a standalone process or by one
of the processes presented.
• Serves as the first system.
• Provide a feel for the actual system and
something built quickly.
• Intended for short term use but too often they
are used much longer.
 Prototyping - Types
• Exploratory
 Objective is to work with customers and to
evolve a final system from an initial outline
specification. Should start with well-understood
requirements
• Throw-away
 Objective is to understand the system
requirements. Should start with poorly
understood requirements
Shark tooth model

[from Michael Black]

 The Spiral Model

• An evolutionary model that couples the iterative

nature of prototyping with the controlled, systematic
aspects of waterfall model.

• Spiral model is often developed in a series of releases

or versions.

• Better for large projects.

 Cumulative cost Evaluate alternatives,
Determine objectives, Identify & resolve risks
alternatives & constraints

Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment RequirementsConcept Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance Develop & verify
Plan next phase
Testing next-level product
 Advantages
1. Realism: the model accurately reflects the
iterative nature of software development on
projects with unclear requirements
2. Flexible: incoporates the advantages of the
waterfal and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
 Disadvantages
• Needs technical expertise in risk analysis to
really work
• Model is poorly understood by non-technical
management, hence not so widely used
• Complicated model, needs competent
professional management. High administrative
overhead.
 Concurrent Development Model

• All activities exist concurrently but are in different

states.

• Some activities are in full production while others are

awaiting changes.

• As events occur, then the flow works forward into the

system.
 Concurrent
Each activity can be in a different state:

none under development

awaiting changes under review

under revision
baselined

done
 Evolutionary development
• Problems
 Lack of process visibility
 Systems are often poorly structured
 Special skills (e.g. in languages for rapid
prototyping) may be required
• Applicability
 For small or medium-size interactive systems
 For parts of large systems (e.g. the user
interface)
 For short-lifetime systems
 Life Cycle Model Selection

• Based on Requirement Characteristics

• Based on development Team
• Based on Users Participation
• Based on Type of risk
 Based on Requirement Characteristics

Requirements Water Prototype Iterative Evolutionary Spiral RAD

fall
Easily Yes No No No No Yes
Understandable
and defined
Change Quite No Yes No No Yes No
often
Defined in Yes No Yes Yes No Yes
Early Cycle
Indicating No Yes Yes Yes Yes No
Complexity of
system
 Based on development Team
Team Waterfall Prototype Iterative Evolutionary Spiral RAD
Less No Yes No No Yes No
Experience
on similar
Projects
Less domain Yes No Yes Yes Yes No
Knowledge
Less Yes No No No Yes No
experience on
tools
Availability No No Yes Yes No Yes
of training
 Based on Users Participation
User’s Waterfall Prototype Iterative Evolutionary Spiral RAD
Participation
In All Phases No Yes No No No Yes
Limited Yes Yes Yes Yes
No Previous No Yes Yes Yes Yes No
experience of
participation
Experts of No Yes Yes Yes No No
problem
domain
 Based on Type of risk
Type of risk Waterfall Prototype Iterative Evolutionary Spiral RAD
Enhancement of No No Yes Yes No Yes
existing system
Funding is Yes Yes No No No Yes
stable for project
High Reliability No No Yes Yes Yes No
Requirements
Tight Project No Yes Yes Yes Yes Yes
schedule
Use of reusable No Yes No No Yes Yes
components
Resource [Time, No Yes No No Yes No
Cost,
People)scarcity
 Other Process Models
• Component based development
When reuse is a development objective
• Formal methods
Emphasizes the mathematical specification of requirements
• AOSD
Provides a process and methodological approach for
defining, specifying, designing, and constructing aspects
• Unified Process
 “use-case driven, architecture-centric, iterative and
incremental” software process closely aligned with the
Unified Modeling Language (UML)
 Other Process Models
• Agile process model
• Adaptive Software Development
 Component Based Development

• COTS or Commercial Off-The-Shelf components are

becoming more available.

• Most (not all) COTS components have targeted functionality

with good interfaces that enable the component to be
integrated.

• This approach incorporates many of the aspects of the spiral

model.
 COTS
• COTS =
Commercial Off-The-Shelf software
• Engineer together a solution from existing
commercial software packages using minimal
software ”glue”.
• E.g. using databases, spread sheets, word
proccessors, graphics software, web browsers,
etc.
Advantages
• Fast, cheap solution
• May give all the basic functionality
• Well defined project, easy to run
Disadvantages
• Limited functionality
• Licensing problems, freeware, shareware,
etc.
• License fees, maintainance fees, upgrade
compatibility problems
 Reuse-oriented development
• Based on systematic reuse where systems are integrated from
existing components or COTS (Commercial-off-the-shelf)
systems
• Process stages
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration
• This approach is becoming more important but still limited
experience with it
 Aspect-Oriented S/W Development

• Nearly all SW has localized features, functions and

information content.

• User or customer concerns or needs must be included.

These can be high-level concerns like security or
lower-level such as marketing business rules or
systemic such as memory management.

• Aspect-Oriented process is new and still developing.

 Formal Methods Development Model

• Formal mathematical specification of the software.

• Specify, develop and verify by rigorous math
notation.
• Eliminates ambiguity, incompleteness, and
inconsistency.
• Used more where safety-critical software is
developed, e.g., aircraft avionics, medical devices,
etc.
 Formal systems development
• Based on the transformation of a
mathematical specification through different
representations to an executable program

• Transformations are „correctness-preserving‟

so it is straightforward to show that the
program conforms to its specification

• Embodied in the „Clean room‟ approach to

software development
 Formal systems development

Requirements Formal Formal Integration and

definition specification transformation system testing
 Formal systems development
• Problems
 Need for specialised skills and training to apply
the technique
 Difficult to formally specify some aspects of the
system such as the user interface
• Applicability
 Critical systems especially those where a safety
or security case must be made before the system
is put into operation
 Unified process
software
increment Communication inception

Deployment Planning

transition elaboration

Construction Modeling

construction

• Incremental, iterative
• “Unified”  same originators as UML
• Also called Rational Unified Process (RUP)
• Based on spiral model, developed at Rational Software, a division of IBM since 2003
 Unified process work products

Inception phase Elaboration phase Construction phase Transition phase

vision document use-case model design model SW increment
initial use-case model requirements SW components beta test reports
initial business case analysis model test plan user feedback
initial risk list preliminary model test procedure ...
project plan revised risk list test cases
prototype(s) preliminary manual user manual
... ... installation manual
...
 Project Failure – the trigger for Agility

• One of the primary causes of project failure

was the extended period of time it took to
develop a system. Costs escalated and
requirements changed.

• Agile methods intend to develop systems more

quickly with limited time spent on analysis and
design.
 Agile development
• S/W development is unpredictable
– requirements will change (which ones?)
– design and construction are interleaved
(how much design is needed?)
– analysis and testing, too
• Solution: Use an adaptable process
– incremental development strategy
 An Agile method?

• Focus on the code rather than the design.

• Based on an iterative approach to software development.

• Intended to deliver working software quickly.

• Evolve quickly to meet changing requirements.

• There are claims that agile methods are probably best suited to
small/medium-sized business systems or PC products.
 Agile principles
• Agile Manifesto (2001) values
– individuals and interactions over processes and tools
– working software over comprehensive documentation
– customer collaboration over contract negotiation
– responding to change over following a plan
• Agile principles:
– satisfy customer (highest priority)
– early and frequent S/W delivery
– welcome changing requirements
– work daily with business people and developers
– build projects around motivated individuals
– simplicity: maximize the amount of work NOT done
– self-organizing teams
– regular reflection to adjust behavior to improve effectiveness
Summary of Principles of Agile methods

Principle Description
Customer involvement The customer should be closely involved throughout the
deve lopment process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of t he system.
Incremental d elivery The software is developed in increments w ith t he customer
specifying the requireme nts to be included in each i ncrement.
People not process The skills of t he development tea m should be recognised and
exploited. The team should be left to develop their own ways of
working w ithout prescriptive processes.
Embrace change Expect the sys tem requirements to change and design the sys tem
so that it can acc ommodate th ese changes.
Maintain sim plicity Focus on sim plicity in both the software be ing d eve loped and in
the development process used. Wherever possible, actively w ork
to eliminate complexity from the system.
 The Agile attitude focuses on:

1. Talent & Skill (fewer better people)

2. Proximity (developers - developers - users)
3. Communication (morale, daily standup)
4. Just-in-time requirements and design
5. Frequent Delivery (incremental development)
6. Reflection
7. Less paper, more tacit / verbal communication
8. Tools
9. Quality in work
10. Different strategies for different projects
What are the Agile Methodologies?

 eXtreme Programming has received the most

attention, but here is a list:
 XP  FDD
 SCRUM  dX (agile RUP)
 DSDM  Open Source
 The Crystal Family  Agile Modeling
 ASD  Pragmatic Programming

Since Larman is based on (R)UP, dX might be interesting.

 eXtreme Programming

• Development and delivery of very small

increments of functionality.
• Relies on constant code improvement, user
involvement in the development team and pair
wise programming.
• Emphasizes Test Driven Development (TDD)
as part of the small development iterations.
 Extreme programming (XP)

Kent Beck became project leader of Chrysler’s payroll project in 1996

Project canceled in 2000

[Kent Beck, Extreme Programming Explained, 1999] [from extremeprogramming.org]

 A simpler view of XP
spike solutions
CRC cards (prototypes)
design

planning coding

refactoring
test
unit test
acceptance test
continuous integration
S/W increment
 XP principles
1. Test-driven development
2. The planning game
3. On-site customer
4. Pair programming
5. Continuous integration
6. Refactoring
7. Small releases
8. Simple design
9. System metaphor
10. Collective code ownership
11. Coding standards
12. 40-hour work week
 Advantages
• Lightweight methods suit small-medium size
projects
• Produces good team cohesion
• Emphasises final product
• Iterative
• Test based approach to requirements and
quality assurance
 Disadvantages
• Difficult to scale up to large projects where
documentation is essential
• Needs experience and skill if not to degenerate
into code-and-fix
• Programming pairs is costly
• Test case construction is a difficult and
specialised skill.
 Adaptive S/W development (ASD)
• ASD focuses on human collaboration and team
self-organization

collaboration

speculation learning

S/W increment
[Highsmith 2000]
 Scrum
• Backlog – prioritized list of project requirements or features
• Sprints – work units required to achieve a requirement
– deliver within fixed time (30 days)
– no changes to requirement allowed during that time

• Daily meetings (15 min.)

– What did you do?
– What obstacles are you encountering?
– What is your plan?

• Demos – S/W increments delivered to customer (can ship final

product upon demand)
 Claimed Problems with agile methods

• It can be difficult to keep the interest of customers

who are involved in the process.
• Team members may be unsuited to the intense
involvement that characterizes agile methods.
• Prioritizing changes can be difficult where there are
multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other
approaches to iterative development.
 Summary
• Process
• Process models
– Traditional
– Evolutionary
– Others
• Comparison