The

Software
Process
 House Requirements:
#rooms,
#bathrooms, kitchen size,
#floors, balcony, etc.

House Design:
Floor Plan. Electrical wireframe,
Plumbing, design specifications
House Construction:

House Maintenance:

How we build a House?

 House Requirements:
#rooms,
#bathrooms, kitchen size,
#floors, balcony, etc.

House Design:
Floor Plan. Electrical wireframe,
Plumbing, design specifications
House Construction:

Software Requirements:
Functional, non-
House Maintenance:
functional, constraints,
etc.

Software Design:
Architectural.
Subsystem/Component design
Detailed Design, Class Diagram Coding:
design specifications

Testing: Unit Testing,

Integration, System
Testing, UAT, etc.

How we build a Software? Operation &

Maintenance:
Change management,
bug fixing, etc.
 House Requirements:
#rooms,
#bathrooms, kitchen size,
#floors, balcony, etc.

House Design:
Floor Plan. Electrical wireframe,
Plumbing, design specifications
House Construction:

Software Requirements:
Functional, non-
House Maintenance:
functional, constraints,
etc.

Software Design:
Architectural.
Subsystem/Component design
Detailed Design, Class Diagram Coding:
design specifications

Testing: Unit Testing,

Integration, System
Testing, UAT, etc.

How we build a Software? Operation &

Maintenance:
Change management,
bug fixing, etc.
 Software Development in 60’s

The moon was promised …..

A lunar rover was

built …..

A pair of square wheels

were delivered…..
 Nature of Software Development:
The Past
• IBM survey, 1994
– 55% of systems cost more than expected
– 68% overran schedules
– 88% had to be substantially redesigned

• Advanced Automation System (Federal Aviation Administration, 1982-1994)

– industry average was $100/line, expected to pay $500/line
– ended up paying $700-900/line
– $6B worth of work discarded

• Bureau of Labor Statistics (1997)

– for every 6 new systems put into operation, 2 cancelled
– probability of cancellation is about 50% for biggest systems
– average project overshoots schedule by 50%
– 3/4 systems were regarded as ‘operating failures’
 • Since then, the problem is actively
investigated and researched
• ….and everything has been
blamed …
– Customer
What’s • What to you mean…I can’t
get the moon for $50?
Wrong – ‘Soft’ in the software

with SD? • If I could add one last

feature …
– Immature Processes…
– Developers…
– Young discipline…
–…
 What’s Wrong with SD?
Complexity Change
• The application domain • Requirements
– Problem
• People
– People
• Technologies
• The solution domain
– Product • Bug fixing
– Process
– Technology
And you need to deliver software…
• …Within the budget, the schedule, and user
perceived quality…!!!
The Software Problem – The 3 P’s
• The Product

• The Process

• The People
… and managing them all…! …
Software
Process ?
Software Development Life Cycle (SDLC)

Consists of…
• Requirement gathering, Analysis,
Specification, and Validation
• Design (Both high- and low-level designs)
• Construction
• Testing
• Maintenance (Evolution)
• Closure

12
 A Dual Emphasis in SDLC
• Product
– what is done
• Process Software Process
– how things are done

Product Engineering Process Management

Process Process

Development Project Management SCM QA

Process Process Process Process
 What is a (Software) Process?
• A series of steps involving activities, roles
constraints, and resources that produce an
intended outcome (useful Software Artifact)
of some kind
Roles Resources

Input Process V&V Output

[Preconditions] Step [Post-conditions]

A step in the Software Development Process

 How a Software Process Help?
• Imposes a structure and consistency on a set
of activities
• Guides our actions by allowing us to examine,
understand, control and improve the
activities that comprise the process
• Captures our experience and pass them along
to others
Software Process Characteristics

• Visibility
• Predictability
• Testability
• Maintainability
• Early defect
Removal
• Support Change
• Customizability
Process

16
Cost of Finding Flaws Late

CS 413 17
 Software Process Models
• Also termed as Software Life Cycle Models
– Water-Fall model
– Prototyping model
• Throw away prototyping
• Evolutionary prototyping
– Incremental model (Evolutionary model)
• Incremental Water-Fall model
• Time Boxing model
• Spiral model
• Synchronize & Stabilize model
– Commercially projected models like RUP, XP, SCRUM
18
 Waterfall Model
Requirements Requirements
Phase Description

Specification Specification,
Phase SPMP

Design
Phase Design Docs

Implementation Code

Product, Tests
Testing

Operations
Retirement
CS 413 Mode 19
 Waterfall Model cont…
• Advantages
– Simple
– Complete control on the software process
– Better quality control
• Disadvantages
– Complete and consistent set of requirements?
– Do not support iteration
– Change management is difficult
– Customer to have patience
– Does not facilitate good use of resources
– May choose outdated technology
 Waterfall Model cont…

• Suitable for
– Well understood problems
– Short duration projects
– Automation of existing manual systems
– Mission-Critical and Safety-Critical Systems
Prototyping Model
 Prototyping Model
• The task of requirement elicitation is easier
(+)
• Progress is visible and client is happy (+)
• More flexibility compared to Water-fall model
(+)
 Prototyping Model
• Evolutionary Prototyping
– A cheaper option (+)
– Allows faster development (+)
– May suffer from “short-sightedness” (-)
– May not estimate RISK correctly (-)
– Disallows efficient use of resources (-)
– May disallow later changes (-)
 Prototyping Model
• Throwaway Prototyping
– Allows better use of resources (+)
– Better RISK estimation is possible (+)
– May improve on “short-sightedness” (+)
– May allow later changes to be incorporated in a
better manner (+)
– May be costly (-)
– May take more time (-)
 Prototyping Model

• Suitable for
– Less experience teams
– System with novice users
– Requirements are not clear
– UI is very important
 Incremental Model
• Incremental Water-Fall Model
Build 1: Implementation,
Specifications Design integration Deliver to client

Specifications Design Implementation, Deliver to client

Build 2: integration

Implementation,
Build 3: Specifications Design integration Deliver to client

specification team

design team
…

…
implementation/integration team
Implementation,
Build n: Specifications Design integration Deliver to client
 Incremental Water-Fall Model
• Problems …
– identifying the core may be difficult
• a set of basic facilities that are used by different parts
of the system may not be obvious
– difficulty in situations when a Replacement system
is being developed
– conflicts with the procurement model of many
organizations like govt. agencies
 Spiral Model: Incremental model
• Always some risk involved in the software development
– people leave… other products not delivered on time… critical systems that
may compromise the safety or security … lack of domain knowledge … client
may be unreliable/unpredictable … change in political or business scenario
… govt. policies … technology being outdated … new technology …
requirements not clear …
• Key idea
– minimize risk
• e.g., building prototypes & simulations minimizes risks
• Precede each phase by
– looking at alternatives
– risk analysis
• Follow each phase by
– evaluation
– planning of next phase
Spiral Model [Bohm’88]
Spiral Model [Bohm’88]
Spiral Model [Bohm’88]
Spiral Model [Bohm’88]
Spiral Model [Bohm’88]
Synchronize & Stabilize Model (Microsoft)

• Requirements analysis
– interview potential customers
• Draw up overall product specifications
• Divide project into 3 or 4 builds
– each adds new functionality (1st gives base)
– each build carried out by small parallel teams
• At the end of day – synchronize (test & debug)
• At end of build – stabilize (fix & freeze build)
 Incremental Models
• Advantages
– Better Release Planning and Change Management
– Better use of Resources
– Faster Development (Reduced time to market)
– Reduce risk
• Disadvantages
– May result in a kind of ‘build and fix’ approach (may
result in inefficient design)
– More overheads
 Incremental Model
• Suitable for
– Risk is high
– Requirements are not clear but will evolve
– “Time to Market” is critical
– Big projects
– New concept/product development
Software Process Improvement

SPI
 Software Process Improvement
• Software processes are complex
– rely on people making decisions and judgments
– have evolved to take advantage of the capabilities
of the people in an organization and the specific
characteristics of the systems that are being
developed
– most organizations have developed their own
software processes and they use different
processes for different projects
 Improving the S/W Process
• Why does it need improvement?
– We still struggle with creating/maintaining software
• ’87 Department of Defense report
• 20 years of “unfulfilled promises about productivity & quality”
• problem is “inability to manage the software process”
– Global economy dependent on computer software
– Improved software process -> ?
• improved software quality
• delivery on time, within budget
• How to address this problem
– Software Engineering Institute (SEI) at Carnegie Mellon
• capability maturity model (CMM) - 1986
CMM Levels
 CMM Level 1: Initial Process
• Ad hoc approach
– Entire process unpredictable
– Management consists of responses to crises
• Many organizations world-wide are here!
– Pattern of time, resources and cost overruns
• Success depends totally on the staff
– As the staff changes, so does the process
CMM Level 2: Repeatable Process
• What is the key to this level?
– Metrics!
• Basic software project management
– Planning, management based on past experience
– Measurements (“metrics”)
• realistic costs and schedules
• can be used for predictions in next project
– Problems identified  take immediate corrective
action
 CMM Level 4: Managed Process
• Quality & productivity goals set for each project
• Quality, productivity continually monitored
– Corrective action taken upon deviation
– Rely on statistical quality controls
• distinguish random deviations & meaningful violations
• e.g., #faults detected per 1000 lines of code
• Metrics are defined and analyzed to suit the
development organization
• Encourage Reuse
 CMM Level 3: Defined Process
• Software process is Fully Documented
– Managerial & technical aspects clearly defined
– Intermediate products - well defined and easily
visible.
– Efforts to improve quality, productivity,
documentation
• Reviews to improve software quality
• Make use of CASE tools
 CMM Level 5: SPI and Optimizing
Process
• Continuous process improvement
• Statistical quality & process controls
• Feedback knowledge from completed projects
leads to continued improvement
• Benchmarking
• How does level 5 differ from level 2?
– Level 2 tries to find & correct faults
– Level 5 orgs practice defect prevention
• i.,e. ensure there are no faults in the first place
Moving Up in CMM
Summary

48