Unit_I_T2_W14-15

Process Models

CSE325 Software Engineering

Unit I

Topic II: Process, Process Models

Software Lifecycle Models

A software lifecycle model is a standardised
format for
planning
organising, and
running
a new development project.
Hundreds of different kinds of models are known and used.

Many are minor variations on just a small number of basic models.

Planning with Models

SE projects usually live with a fixed financial budget. (An exception is maintainance?)
Additionally, time-to-market places a strong time constraint.
There will be other project constraints such as staff.
Project planning is the art of scheduling the necessary activities, in time, space and
across staff in order to optimise:
project risk [low]
profit [high]
customer satisfaction [high]
worker satisfaction [high]
long-term company goals
A project plan contains much information, but must at least describe:
resources needed (people, money, equipment, etc)
dependency & timing of work (flow graph, work packages)
rate of delivery (reports, code, etc)

It is impossible to measure rate of progress except with reference to a plan.

In addition to project members, the following may need access to parts of the project plan:

Management,
Customers
Subcontractors
Suppliers
Investors

1
 Unit_I_T2_W14-15
Process Models
Banks

Project Visibility
Unlike other engineers (e.g. civil, electronic, chemical etc.) software engineers do not
produce anything physical.
It is inherently difficult to monitor an SE project due to lack of visibility.

SE projects must produce additional deliverables (artifacts) which are visible, such as:

Design documents/ prototypes

Reports
Project/status meetings
Client surveys (e.g. satisfaction level)

A Lifecycle Model?

Definition.
A (software/system) lifecycle model is a description of the sequence of activities
carried out in an SE project, and the relative order of these activities.
It provides a fixed generic framework that can be tailored to a specific project.
Project specific parameters will include:
Size, (person-years)
Budget,
Duration.
project plan = lifecycle model + project parameters

Different lifecycle models

Waterfall,
V shaped
Code-and-fix
Spiral
Rapid prototyping
Unified process (up)
Agile methods, extreme programming (xp)
Cots
but many are minor variations on a smaller number of basic models.
By changing the lifecycle model, improvement and/or tradeoff can be made towrads

Development speed (time to market)

Product quality

2
 Unit_I_T2_W14-15
Process Models
Project visibility
Administrative overhead
Risk exposure
Customer relations, etc, etc.
Waterfall Model
The waterfall model is the classic lifecycle model it is widely known, understood
and (commonly?) used.
In some respect, waterfall is the common sense approach.
Introduced by Royce 1970.

Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule

Waterfall Deficiencies
All requirements must be known upfront
Deliverables created for each phase are considered frozen inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software development iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until it may be too late)

When to use the Waterfall Model

Requirements are very well known
Product definition is stable

3
 Unit_I_T2_W14-15
Process Models
Technology is understood
New version of an existing product
Porting an existing product to a new platform.

V-Shaped SDLC Model

A variant of the Waterfall that emphasizes the verification and validation of the product.
Testing of the product is planned in parallel with a corresponding phase of development

V-Shaped Steps
Project and Requirements Planning allocate resources
Product Requirements and Specification Analysis complete specification of the
software system
Architecture or High-Level Design defines how software functions fulfill the design
Detailed Design develop algorithms for each architectural component
Production, operation and maintenance provide for enhancement and corrections
System and acceptance testing check the entire software system in its environment
Integration and Testing check that modules interconnect correctly
Unit testing check that each module acts as expected
Coding transform algorithms into software

V-Shaped Strengths

4
 Unit_I_T2_W14-15
Process Models
Emphasize planning for verification and validation of the product in early stages of
product development
Each deliverable must be testable
Project management can track progress by milestones
Easy to use

V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities

When to use the V-Shaped Model

Excellent choice for systems requiring high reliability hospital patient control
applications
All requirements are known up-front
When it can be modified to handle changing requirements beyond analysis phase
Solution and technology are known

Code-and-Fix
This model starts with an informal general product idea and just develops code until a
product is ready (or money or time runs out).
Work is in random order.
Advantages
No administrative overhead
Signs of progress (code) early.
Low expertise, anyone can use it!
Useful for small proof of concept projects, e.g. as part of risk reduction.

Disadvantages
Dangerous!
o No visibility/control
o No resource planning
o No deadlines
o Mistakes hard to detect/correct
Impossible for large projects,
o communication breakdown, chaos.

Incremental SDLC Model

Construct a partial implementation of a total system
Then slowly add increased functionality

5
 Unit_I_T2_W14-15
Process Models

The incremental model prioritizes requirements of the system and then implements them in
groups.
Each subsequent release of the system adds function to the previous release, until all
designed functionality has been implemented.

Incremental Model Strengths

Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses divide and conquer breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

6
 Unit_I_T2_W14-15
Process Models

Incremental Model Weaknesses

Requires good planning and design
Requires early definition of a complete and fully functional system to allow for the definition
of increments
Well-defined module interfaces are required (some will be developed long before others)
Total cost of the complete system is not lower

When to use the Incremental Model

Risk, funding, schedule, program complexity, or need for early realization of benefits.
Most of the requirements are known up-front but are expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology

Rapid Application Model (RAD)

Requirements planning phase (a workshop utilizing structured discussion of business
problems)
User description phase automated tools capture information from users
Construction phase productivity tools, such as code generators, screen generators, etc.
inside a time-box. (Do until done)
Cutover phase -- installation of the system, user acceptance testing and user training
T e am # n
M o d e li n g
b u s in e s s m o d e lin g
d a t a m o d e lin g
p r o c e s s m o d e lin g

C o n s t r u c t io n
c o m p on e n t re u s e
T e am # 2 a u t o m a t ic c o d e
C o m m u n ic a t io n g e n e r a t io n
t e s t in g
M o d e ling
b u si n e s s m o d e l i n g
d a t a m o d e lin g
p ro c e s s m o d e l i n g

P la n n in g
C o ns t r uc t io n D e p lo y m e n t
T e am # 1 co m p o n e n t re u se i n t e g r at io n
a u t o m a t i c co d e
g e n e ra t i o n
d e liv e r y
M o d e li n g t e st i n g f e e d b ack
b u s in e s s m o d e lin g
d a t a m o d e lin g
p r o c e s s m o d e lin g

C o n s t r u c t io n
c o m p o n e n t re u s e
a u t o m at i c c o d e
g e n e r at i o n
t e s t in g

6 0 - 9 0 days

7
 Unit_I_T2_W14-15
Process Models
RAD Strengths

Reduced cycle time and improved productivity with fewer people means lower costs
Time-box approach mitigates cost and schedule risk
Customer involved throughout the complete cycle minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code (WYSIWYG).
Uses modeling concepts to capture information about business, data, and processes.

RAD Weaknesses
Accelerated development process must give quick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to rapid-fire activities in an abbreviated
time frame.

When to use RAD

Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized
Evolutionary development
Problems in Traditional Models
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

Spiral Model

Build some software

See if it meets customer requirements
Repeat Process.
This loop approach gives rise to structured

8
 Unit_I_T2_W14-15
Process Models
iterative lifecycle models.

In 1988 Boehm developed the spiral model as an iterative model which includes risk
analysis and risk management.

Key idea: on each iteration identify and solve the sub-problems with the highest risk.

Each cycle follows a waterfall model by:

o Determining objectives
o Specifying constraints
o Generating alternatives
o Identifying risks
o Resolving risks
o Developing next-level product
o Planning next cycle

Advantages
Realism: the model accurately reflects the iterative nature of software development on
projects with unclear requirements
Flexible: incoporates the advantages of the waterfal and rapid prototyping methods
Comprehensive model decreases risk
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

9
 Unit_I_T2_W14-15
Process Models
Complicated model, needs competent professional management. High administrative
overhead.
Rapid Prototyping
Idea: Customers are non-technical and usually dont know what they want/can have.
Prototypes are built when goals are general and not specific.
Prototyping can be used as a standalone process or by one of the processes presented.
The prototype serves as the first system. Users get a feel for the actual system and
developers get something built quickly.
A prototype is intended for short term use but too often they are used much longer.
Rapid prototyping emphasises requirements analysis and validation, also called:
o Customer Oriented development,
o Evolutionary prototyping

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

10
 Unit_I_T2_W14-15
Process Models

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.

When to use
Structured Evolutionary Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-oriented development.

Agile (XP) Manifesto

XP = Extreme Programming emphasizes:

Individuals and interactions
o Over processes and tools
Working software
o Over documentation
Customer collaboration
o Over contract negotiation
Responding to change
o Over following a plan

Agile Principles
Continuous delivery of software
Continuous collaboration with customer
Continuous update according to changes
Value participants and their interaction
Simplicity in code, satisfy the spec.
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.

11
 Unit_I_T2_W14-15
Process Models

XP Practices
Programming in pairs
Test driven development
Continuous planning, change , delivery
Shared project metaphors, coding standards and ownership of code
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.

Unified Process (UP)

Booch, Jacobson, Rumbaugh 1999.
Lifetime of a software product in cycles:

12
 Unit_I_T2_W14-15
Process Models
Each cycle has phases, culiminating in a new release (c.f. Spiral model)
Inception identify core use cases, and use to make architecture and design tradeoffs.
Estimate and schedule project from derived knowledge.
Elaboration capture detailed user requirements. Make detailed design, decide on build vs.
buy.
Construction components are bought or built, and integrated.
Transition release a mature version that satisfies acceptance criteria.

Reuse-oriented development
Based on systematic reuse where systems are integrated from existing components or
COTS (Commercial-off-the-shelf) systems
Process stages
o Component analysis
o Requirements modification
o System design with reuse
o Development and integration
This approach is becoming more important but still limited experience with it
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

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.

13
 Unit_I_T2_W14-15
Process Models

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
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

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 Waterfall Prototype Iterative Evolutionary Spiral RAD

Easily Yes No No No No Yes

Understandable
and defined

Change Quite No Yes No No Yes No

often

Defined in Early Yes No Yes Yes No Yes

Cycle

Indicating No Yes Yes Yes Yes No

Complexity of
system

14
 Unit_I_T2_W14-15
Process Models
Team Waterfall Prototype Iterative Evolutionary Spiral RAD

Less No Yes No No Yes No

Experience
on similar
Projects

Less Yes No Yes Yes Yes No

domain
Knowledge

Less Yes No No No Yes No

experience
on tools

Availability No No Yes Yes No Yes

of training

Users 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

15
 Unit_I_T2_W14-15
Process Models

Type of risk Waterfall Prototype Iterative Evolutionary Spiral RAD

Enhancement No No Yes Yes No Yes

of existing
system

Funding is Yes Yes No No No Yes

stable for
project

High No No Yes Yes Yes No

Reliability
Requirements

Tight Project No Yes Yes Yes Yes Yes

schedule

Use of No Yes No No Yes Yes

reusable
components

Resource No Yes No No Yes No

[Time, Cost,
People)scarcity

16