The software production

process

Ch. 7

Questions
What is the life cycle of a software
product?
Why do we need software process
models?
What are the goals of a software
process and what makes it different
from other industrial processes?

Ch. 7

Life cycle
The life cycle of a software product
from inception of an idea for a
product through
requirements gathering and analysis
architecture design and specification
coding and testing
delivery and deployment
maintenance and evolution
retirement
Ch. 7

Software process model

Attempt to organize the software life
cycle by
defining activities involved in software
production
order of activities and their relationships

Goals of a software process

standardization, predictability,
productivity, high product quality, ability
to plan time and budget requirements
Ch. 7

Code&Fix
The earliest approach
Write code
Fix it to eliminate any errors that have
been detected, to enhance existing
functionality, or to add new features
Source of difficulties and deficiencies

impossible to predict
impossible to manage
Ch. 7

Models are needed

Symptoms of inadequacy: the
software crisis
scheduled time and cost exceeded
user expectations not met
poor quality

The size and economic value of

software applications required
appropriate "process models"
Ch. 7

Process model goals

(B. Boehm 1988)

"determine the order of stages involved in

software development and evolution,
and to establish the transition criteria for
progressing from one stage to the next.
These include completion criteria for the current
stage plus choice criteria and entrance criteria
for the next stage. Thus a process model addresse
the following software project questions:
What shall we do next?
How long shall we continue to do it?"
Ch. 7

Process as a "black box"

Informal
Requirements

Process
Product

Ch. 7

Problems
The assumption is that requirements
can be fully understood prior to
development
Interaction with the customer occurs
only at the beginning (requirements)
and end (after delivery)
Unfortunately the assumption
almost never holds
Ch. 7

Process as a "white box"

Informal
Requirements

Process
Product

feedback

Ch. 7

10

Advantages
Reduce risks by improving visibility
Allow project changes as the
project progresses
based on feedback from the customer

Ch. 7

11

The main activities

They must be performed
independently of the model
The model simply affects the flow
among activities

Ch. 7

12

Feasibility study
Why a new project?
cost/benefits tradeoffs
buy vs make
Requires to perform preliminary
requirements analysis
Produces a Feasibility Study Document
1. Definition of the problem
2. Alternative solutions and their expected
benefits
3. Required resources, costs, and delivery dates
in each proposed alternative solution
Ch. 7

13

Requirements engineering
activities

Ch. 7

14

Requirements engineering
Involves

eliciting
understanding
analyzing
specifying

Focus on
what qualities are needed, NOT on
how to achieve them
Ch. 7

15

What is needed
Understand interface between the
application and the external world
Understand the application domain
Identify the main stakeholders and
understand expectations
different stakeholders have different
viewpoints
software engineer must integrate and
reconcile them
Ch. 7

16

The requirements
specification document
Provides a specification for the
interface between the application
and the external world
defines the qualities to be met

Has its own qualities

understandable, precise, complete,
consistent, unambiguous, easily
modifiable
Ch. 7

17

A case study

railway automation
Who are the stakeholders?

management of the train company

train drivers and their unions
passengers (customers)
contractors

Each has different goals

Ch. 7

18

Case study

how to classify requirements

Safety requirements
the probability of accidents should be
less than 10-9 per year

Utility requirements
level of usefulness of the system as
perceived by the various stakeholders

Ch. 7

19

Case study

the produced document

Introduction: the mission of the
system
Architecture: the main structure of the
system
Specific requirements associated with
each subsystem
discussion of how the subsystems
requirements guarantee that the overall
goals are indeed achieved
Ch. 7

20

Software architecture and

detailed design activity
The result of this activity is a
Design Specification Document
Usually follows a company
standard, which may include a
standard notation, such as UML

Ch. 7

21

Coding and module testing

activity
Company wide standards often
followed for coding style
Module testing
based on black box/white box criteria

Ch. 7

22

Integration and system test

activity
These activities may be integrated
with coding and module testing
Integration may be done
incrementally through subsystems
top down vs. bottom up

The last step is system test

may be followed by alpha testing
Ch. 7

23

Delivery, deployment, and

maintenance activities
Delivery
real delivery may be preceded by
beta testing

Deployment
components allocated on physical
architecture

Maintenance
corrective, adaptive, perfective
Ch. 7

24

Maintenance
Requirements errors are main
cause of maintenance activities
Late discovery of requirements
errors causes increased costs

Ch. 7

25

Other software activities

Documentation
Verification
Management
They can be considered as parts of
any kind of software related
activity
Ch. 7

26

Overview of software
process models

Ch. 7

27

Waterfall models (1)

Invented in the late 1950s for large
air defense systems, popularized in
the 1970s
They organize activities in a
sequential flow
Exist in many variants, all sharing
sequential flow style
Ch. 7

28

Feasibility study

A waterfall model

Requirements

Design
Coding and module testing
Integration and system testing

Delivery, deployment, and

maintenance

Ch. 7

29

Waterfall models (2)

Organizations adopting them
standardize the outputs of the
various phases (deliverables)
May also prescribe methods to
follow in each phase
organization of methods in
frameworks often called methodology

Example: Military Standard (MILSTD-2167)

Ch. 7

30

Critical evaluation of the

waterfall model
+sw process subject to discipline,
planning, and management
+postpone implementation to after
understanding objectives
linear, rigid, monolithic
no feedback
no parallelism
a single delivery date
Ch. 7

31

Waterfall with feedback

Feasibility study
Requirements
Design
Coding and
module testing
Integration and
system testing
Delivery, deployment, and
maintenance

Ch. 7

32

Problems with waterfall

Estimates made when limited
knowledge available
Difficult to gather all requirements
once and for all
users may not know what they want
requirements cannot be frozen

Ch. 7

33