Software Process 1

Software Dev Process

Process is distinct from product
products are outcomes of executing a process
on a project

SW Eng. focuses on process

Premise: Proper processes will help achieve

project objectives of high QP

Software Process 2
Software Process…
Process: A particular method, generally
involving a number of steps
Software Process: A set of steps, along
with ordering constraints on execution, to
produce software with desired outcome

Many types of activities performed by diff

people
Software process is comprising of many
component processes

Software Process 3
Key Processes

Software Process 4
Software Dev Processes
Two major processes
Engineering– “development and quality steps
needed to engineer the software”
Project management – “planning and
controlling the development process”

Key Roles
Developers execute Engineering process
 Software architects, lead developers, ...

Project manager(s) executes the mgmt process

Software Process 5
Other Processes…
Other processes
Configuration management: manages the
evolution of artifacts
Change management: how changes are
incorporated
Inspection process: how inspections are
conducted on artifacts
Process Improvement Process:

Software Process 6
Process Specification

Process is generally a set of phases

Each phase performs a well defined task and
generally produces an output
Intermediate outputs – work products
At top level, typically few phases in a process
Variety of methodologies have been proposed
for each phase
Software Process 7
ETVX Specification
ETVX approach to specify a phase
Entry criteria: what conditions must be
satisfied for initiating this phase
Task: what is to be done in this phase
Verification: the checks done on the outputs of
this phase
eXit criteria: when can this phase be
considered done successfully
A phase also produces info for mgmt

Software Process 8
ETVX approach

Software Process 9
ETVX Example: Change
management

Software Process 10
Key Dev Process Properties
Provide high Q&P by
1. Early defect removal
2. Execute in a Predictable and repeatable
manner
3. Support Change

Software Process 11
1) Early Defect Removal…
Provide high Q&P
Support testability
 testing can consume 30 to 50% of total development
effort
Support maintainability
 maintenance can be more expensive than
development;
 over life up to 80% of total cost

Remove defects early, as cost of removing

defects increases with latency

Software Process 12
1) Early Defect Removal…
Cost of a defect increases with latency
fixing a req defect
 During requirements: x
 During operation: 100x

the process must support early defect

removal

That is why there is a V in ETVX, and quality

control tasks in the sw process

Software Process 13
3) Early Defect Removal…

Software Process 14
2) Predictability and
repeatability
Process should repeat its performance when
used on different projects
outcome of using a process should be predictable!

Without predictability,
 can’t estimate effectively,
can’t say anything about quality or productivity

With predictability,
past performance can be used to predict future
performance
Software Process 15
2) Predictability…

Software Process 16
2) Predictability…
Predictable process is said to be under
statistical control
Repeatedly using the process produces similar
results
Results – properties of interest like quality,
productivity, …
To consistently develop sw with high Q&P,
process must be in control

Software Process 17
3) Support Change
Software changes for various reasons
Requirements change
Infrastructure changes
Designs change

Changes in Requirements
cannot be wished away or treated as “bad”
must be accommodated in the SW development
process

Software Process 18
Summary
Process – method for doing something
Process typically has stages, each stage
focusing on an identifiable task
Stages have methodologies

Software process - methods for developing

software
Best to view it as comprising of multiple
processes

Software Process 19
 How are we going to go about it?

Software Process 20
Development Process
A set of phases and each phase being a
sequence of steps
For each phase there are
A variety of methodologies
Corresponding to different sequence of steps for a
phase

Why have phases?

To employ divide and conquer
Each phase handles a different part of the problem
Helps in continuous validation

Software Process 21
Development Process
Commonly has these activities:
1. Requirements analysis,
2. Design
3. Coding,
4. Testing,
5. Delivery

Different models perform them in different

manner!

Software Process 22
1. Requirement Analysis
State the problem precisely!
Forms the basis of agreement between user
and developer
Specifies “what” not “how”
Hard task - needs often not understood well
Requirement specifications of even medium
systems can be many hundreds of pages
Output is the SW Requirements Spec (SRS)
document

Software Process 23
2. Design
A major step in moving from problem
domain to solution domain
Three main tasks
1. Architecture design – components and
connectors that should be there in the system
2. High level design – modules and data
structures needed to implement the
architecture
3. Detailed design – logic of modules
Most methodologies focus on architecture
or high level design
Outputs are arch/des/logic design docs
Software Process 24
3) Coding
Converts design into code in specific
language
Goal: Implement the design with simple
and easy to understand code

Coding phase affects both testing and

maintenance
Well written code reduces testing and
maintenance effort
Output is code

Software Process 25
4) Testing & Quality Assurance
Defects are introduced in each phase
Must be found and removed to achieve
high quality
Goal: Identify most of defects
Very expensive task; must be properly
planned and executed
Outputs are
Test plans/results, and
the final tested (hopefully reliable) code

Software Process 26
4) Typical Effort Distribution ?
Req. - ?
Design - ?
Coding - ?
Testing - ?

Software Process 27
4) Typical Effort Distribution
Distribution of effort :
Req. - 10-20%
Design - 10-20%
Coding - 20-30%
Testing - 30-50%

Coding is not the most expensive!

Software Process 28
4) Distribution of effort…
How programmers spend their time?
Writing programs ?
Reading programs and manuals ?
Job communication ?
Others ?

Software Process 29
4) Distribution of effort…
How programmers spend their time
Writing programs - 13%
Reading programs and manuals - 16%
Job communication - 32%
Others - 39%

Programmers spend more time in

reading programs than in writing them.

Writing programs is a small part of

their lives.
Software Process 30
4) Delivery
What the “Operations” group does.

Varies by distribution model

Shrink Wrapped Software
In house software
Web-based
Software As A Service (SaaS)
…

From a users perspective my be as

important as design!
Software Process 31
When are defects introduced?
Distribution of error occurrences by phase is
Req. - 20%
Design - 30%
Coding - 50%

Defects can be injected at any of the major

phases.

Cost of latency: Cost of defect removal

increases exponentially with latency time.

Software Process 32
Defects…
Cost to fix
Error ( log scale)

Time
Cheapest way to detect and remove
defects close to where it is injected.

Hence must check for defects after

every phase.
Software Process 33
CSE Methodologies
Common Methods
Waterfall – the oldest and widely used
Prototyping – Prototype, followed by Waterfall
Iterative – used widely in product dev
Timeboxing – Iterative 2.0
Agile - Lightweight" methodologies (Speaker)

Software Process 34
Waterfall Model
Linear sequence of stages/phases
Requirements -> HLD –> DD –> Code –> Test
–> Deploy

A phase starts only when the previous has

completed; no feedback!

The phases partition the project, each

addressing a separate concern

Software Process 35
Software Process 36
Waterfall…
Linear ordering implies each phase should
have some output

The output must be validated/certified

Outputs of earlier phases: work products

Common outputs of a waterfall: SRS, project

plan, design docs, test plan and reports, final
code, supporting docs
Software Process 37
Waterfall Advantages
Natural approach for problem solving

Conceptually simple, cleanly divides the

problem into distinct independent phases

Easy to administer in a contractual setup –

each phase is a milestone

Software Process 38
Waterfall disadvantages
Assumes that requirements can be specified
and frozen early

May fix hardware and other technologies too

early

Follows the “big bang” approach – all or

nothing delivery; too risky

Very document oriented, requiring docs at

the end of each phase

Software Process 39
Waterfall Usage
Well suited for projects where requirements
can be understood easily and technology
decisions are easy

Has been used widely

For standard/familiar type of projects it still

may be the most optimum

Well suited to the out sourcing model

Software Process 40
Prototyping
Addresses the requirement specification
limitation of waterfall

Instead of freezing requirements only by

discussions, a prototype is built to understand
the requirements

Helps alleviate the requirements risk

A small waterfall model replaces the

requirements stage

Software Process 41
Prototyping

Software Process 42
Development of prototype
Starts with initial requirements
Only key features which need better
understanding are included in prototype
No point in including those features that are
well understood
Feedback from users taken to improve the
understanding of the requirements

Software Process 43
Prototyping
Cost can be kept low
Build only features needing clarification

“quick and dirty” – quality not important,

scripting etc can be used

Things like exception handling, recovery,

standards are omitted

Cost can be a few % of the total

Learning in prototype building will help in

building, besides improved requirements
Software Process 44
Prototyping
Advantages
Requirement will be more stable and more likely
to satisfy user needs
Early opportunity to explore scale/performance
issues
Ability to modify or cancel the project early
Enhanced user engagement

Disadvantages:
Potential hit on cost and schedule
Potential false sense of security if prototype does
not focus on key (high risk) issues

Software Process 45
Prototyping
Applicability:
When req are hard to elicit
When confidence in reqs is low
Where reqs are not well understood
When design is driven by user needs

Variants
Paper Prototypes
UI Prototypes
Technology Proving
Rapid Prototyping environments

Software Process 46
Iterative Development
Counters the “all or nothing” drawback of
the waterfall model
Combines benefit of prototyping and
waterfall
Develop and deliver software in
increments
Each increment is complete in itself
Can be viewed as a sequence of waterfalls
Feedback from one iteration is used in the
future iterations
Software Process 47
Iterative Enhancement

Software Process 48
Iterative Development
Most Software Products follow it

Used commonly in customized development

also
Businesses want quick response for sw
Cannot afford the risk of all-or-nothing

Newer approaches like XP, Agile,… all rely on

iterative development

Software Process 49
Iterative Development
Benefits
Get-as-you-pay
feedback for improvement

Drawbacks
Architecture/design may not be optimal
Amount of refactoring may increase
Total cost may increase

Software Process 50
Iterative Development
Applicability
where response time is important,
risk of long projects cannot be taken,
all req not known

Execution
Each iteration is a mini waterfall – decide the
specs, then plan the iteration
Length of iteration driven by amount of new
functionality to be added in an iteration

Software Process 51
Timeboxing
Time boxing is like Iterative development but
fix an iteration duration, then determine the
specs

Divide iteration in a few equal stages

Use pipelining concepts to execute iterations

in parallel

Software Process 52
Timeboxing Execution
Linear Timeboxing
Requirements Build Deploy
TB1

Requirements Build Deploy

TB2

Pipelined Timeboxing Software

Requirements Build Deploy

TB1

Requirements Build Deploy

TB2

Requirements Build Deploy

TB3

Requirements Build Deploy

TB4

Software Process 53
Time Boxed Iterations
General iterative development – fix the
functionality for each iteration, then plan and
execute it

In time boxed iterations – fix the duration of

iteration and adjust the functionality to fit it

Completion time is fixed, the functionality to

be delivered is flexible

Software Process 54
Linear Timeboxing
This itself very useful in many situations
Has predictable delivery times
Overall product release and marketing can be
better planned
Makes time a non-negotiable parameter and
helps focus attention on schedule
Prevents requirements bloating
Overall dev time is still unchanged

Software Process 55
Pipelined Timeboxing
Multiple iterations executing in parallel
Can reduce the average completion time by
exploiting parallelism
For parallel execution, can borrow pipelining
concepts from hardware
This leads to Pipelined Timeboxing Process
Model

Software Process 56
Pipelined Timeboxing Model –
Basics
Development is done iteratively in fixed
duration time boxes
Each time box divided in fixed stages
Each stage performs a clearly defined task
that can be done independently
Each stage approximately equal in duration
There is a dedicated team for each stage
When one stage team finishes, it hands
over the project to the next team

Software Process 57
Example
An iteration with three stages – Analysis,
Build, Deploy
These stages are appx equal in many situations
Can adjust durations by determining the
boudaries suitably
Can adjust duration by adjusting the team size
for each stage
Have separate teams for A, B, and D

Software Process 58
Pipelined Execution
A Team starts executing it-1
A Team finishes, hands over it-1 to B Team,
starts executing it-2
A Team finishes it-2, hands over to B Team; B
Team finishes it-1, hands over to D Team; AT
starts it-3, B Team starts it-2 (and D Team, it-
1)
…

Software Process 59
Timeboxing Execution
Software

Requirements Build Deploy

TB1

Requirements Build Deploy

TB2

Requirements Build Deploy

TB3

Requirements Build Deploy

TB4

Software Process 60
Timeboxing execution
Duration of each iteration still the same
Total work done in a time box is also the
same
Productivity of a time box is same
Yet, average cycle time or delivery time has
reduced to a third

Magic?
Are we getting something for nothing?

Software Process 61
Team Size
No magic, bigger teams
In linear execution of iterations, the same
team performs all stages
If each stage has a team of size S, in linear
execution the total team size is S
In pipelined execution, the total team size is
three times (one for each stage)

Total team size in timeboxing is larger; and

this what reduces cycle time

Software Process 62
Brook’s Law
“Adding manpower to a late
software project makes it later".
Fred Brooks, The Mythical Man-Month (1975)

http://en.wikipedia.org/wiki/Brooks's_law

Software Process 63
Team Size
Merely by increasing the team size we cannot
reduce cycle time - Brook’s law
Timeboxing allows structured way to add
manpower to reduce cycle time
Note that we cannot change the time of an
iteration – Brook’s law still holds
Work allocation different to allow larger team
to function properly

Software Process 64
Work Allocation of Teams

Requirements Requirements Requirements Requirements Requirements

Team Analysis for TB1 Analysis for TB2 Analysis for TB3 Analysis for TB4

Build Team Build for TB1 Build for TB2 Build for TB3 Build for TB4

Deployment
Deployment for TB1 Deployment for TB2 Deployment for TB3
Team

Software Process 65
Timeboxing
Advantages:
 Shortened delivery times,
 other adv of iterative,
 distr. Execution

Disadvantages:
 Larger teams,
 proj mgmt is harder,
 high synchronization needed,
 CM is harder

Applicability
 When short delivery times
 When architecture is stable
 Flexibility in feature grouping
 For larger heavily managed teams

Software Process 66
Summary
Process is a means to achieve project
objectives of high Q&P

Process models define generic process, which

can form basis of project process

Process typically has stages, each stage

focusing on an identifiable task

Many models for development process have

been proposed
Software Process 67
Summary – waterfall
Strength Weakness Types of
Projects
Simple All or nothing – too Well understood
Easy to execute risky problems, short
Intuitive and Req frozen early duration projects,
logical May chose automation of
outdated existing manual
Easy contractually systems
hardware/tech
Disallows changes
No feedback from
users
Encourages req
bloating
Software Process 68
Summary – Prototyping
Strength Weakness Types of
Projects
Helps req Front heavy Systems with
elicitation Possibly higher novice users; or
Reduces risk cost and schedule areas with req
Better and more Encourages req uncertainity.
stable final system bloating Heavy reporting
Disallows later based systems
change can benefit from
UI proto

Software Process 69
Summary – Iterative
Strength Weakness Types of
Projects
Regular deliveries, Overhead of For businesses
leading to biz planning each where time is imp;
benefit iteration risk of long
Can accommodate Total cost may projects cannot be
changes naturally increase taken; req not
Allows user System arch and known and evolve
feedback design may suffer with time
Avoids req Rework may
bloating increase
Naturally
prioritizes req
Allows reasonable Software Process 70
Summary – Timeboxing
Strength Weakness Types of
Projects
All benefits of PM becomes more Where very short
iterative complex delivery times are
Planning for Team size is larger very important
iterations Complicated – Where flexibility in
somewhat easier lapses can lead to grouping features
Very short losses Arch is stable
delivery times

Software Process 71