The software production

process

Ch. 7 1
 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 2
 Outline
• Traditional answer: "waterfall" lifecycles
• Flexible, incremental processes
• Case studies
– "synchronize-and-stabilize" (Microsoft)
– the "open source" development model
• Organizing the process
– software methodologies
– the "Unified Process"
• Organizing artifacts: configuration
management
• Standards
Ch. 7 3
 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 4
 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 5
 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 6
 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 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 addresses
the following software project questions:
What shall we do next?
How long shall we continue to do it?"
Ch. 7 8
Process as a "black box"

Informal
Requirements
Process

Product

Ch. 7 9
 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 10
Process as a "white box"

Informal
Requirements
Process

Product

feedback

Ch. 7 11
 Advantages
• Reduce risks by improving visibility
• Allow project changes as the project
progresses
– based on feedback from the customer

Ch. 7 12
 The main activities
• They must be performed independently
of the model
• The model simply affects the flow
among activities

Ch. 7 13
 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 14
Requirements engineering
activities

Ch. 7 15
 Requirements engineering
• Involves
– eliciting
– understanding
– analyzing
– specifying
• Focus on
– what qualities are needed, NOT on
– how to achieve them

Ch. 7 16
 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 17
 The requirements
specification document (1)
• 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 18
 The requirements
specification document (2)
• Must be analyzed and confirmed by the
stakeholders
– may even include version 0 of user manual
• May be accompanied by the system test
plan document

Ch. 7 19
 The requirements
specification document (3)
• As any large document, it must be
modular
– "vertical" modularity
• the usual decomposition, which may be
hierarchical
– "horizontal" modularity
• different viewpoints
• Defines both functional and non
functional requirements
Ch. 7 20
 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 21
 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 22
 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 23
 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 24
 Coding and module testing
activity
• Company wide standards often followed
for coding style
• Module testing
– based on black box/white box criteria

Ch. 7 25
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 26
 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 27
 Maintenance
• Requirements errors are main cause of
maintenance activities
• Late discovery of requirements errors
causes increased costs

Ch. 7 28
 Other software activities

• Documentation
• Verification
• Management

They can be considered as parts of any

kind of software related activity

Ch. 7 29
Overview of software
process models

Ch. 7 30
 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 31
Feasibility study
A waterfall model
Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, and

maintenance

Ch. 7 32
 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 (MIL-STD-
2167)
Ch. 7 33
 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 34
 Waterfall with feedback
Feasibility study

Requirements

Design

Coding and
module testing

Integration and
system testing

Delivery, deployment, and

maintenance

Ch. 7 35
 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 36
 Evolutionary models
• Many variants available
• Product development evolves through
increments
– "do it twice" (F. Brooks, 1995)
– evolutionary prototype
• Evolutionary process model (B. Boehm, 1988)
"model whose stages consist of expanding
increments of an operational software product,
with the direction of evolution being determined
by operational experience"

Ch. 7 37
 Incremental delivery
• Identify self-contained functional units
that may be delivered to customers
• To get early feedback
– According to T. Gilb, 1988:
• Deliver something to the real user
• Measure the added value to the user in all
critical dimensions
• Adjust design and objectives

Ch. 7 38
 Transformation model
• Guided by formal methods
• Specifications transformed into
implementations via transformations
• Still a theoretical reference model

Ch. 7 39
 Transformation model
Decisions & rationale

Reusable
components

Lower level
Formal
Requirements Requirements specifications specifications
analysis and Optimization
specification

Verification Tuning

Recording of
developmental history
Ch. 7 40
Spiral model
B. Boehm, 1989

Ch. 7 41
 A final model assessment(1)
• Waterfall
– document driven
• Transformational
– specification driven
• Spiral
– risk driven

Ch. 7 42
A final model assessment(2)
• Flexibility needed to reduce risks
– misunderstandings in requirements
– unacceptable time to market
• Waterfall may be useful as a reference
structure for documentation
– describes the "rationale" a posteriori
(Parnas and Clements, 1989)

Ch. 7 43
Legacy software

Ch. 7 44
 Software evolution
• Existing software must evolve because
requirements change
• Re-engineering
– process through which an existing system
undergoes an alteration, to be reconstituted in a
new form
• Reverse engineering
– from an existing system to its documentation,
which may not exist, or may be incomplete
– includes program understanding
– preventive maintenance

Ch. 7 45
 Case study

Synchronize&Stabilize
(The Microsoft Software Process)

Ch. 7 46
 The process
• Planning phase
– vision of the product, specification, schedule
• Development
– team composed of 2 groups
• developers and testers (continuous testing)
– process prescribes
• daily synchronization
• product stabilization
Ch. 7 47
 Case study

The Open Source Approach

Ch. 7 48
 Open source
• Regulates licensed software, specifying
its use, copy, modification, and
distribution rights
• Business does not derive from selling
software, but rather from other, indirect
activities (services, accessories,
advertisement, etc.)

Ch. 7 49
 The process
• Highly distributed process characterized
by frequent iterations
– wide availability of source code
– openness to contributions from a large
community of developers
• Enabling technology
– Internet (large scale and fast collaborations)
– repositories with version control and
configuration management
Ch. 7 50
Methodologies to organize
the process

Ch. 7 51
 SA/SD
• Structured Analysis/Structured Design
• 3 major conceptual tools for modeling
– data flow diagrams
• functional specifications
– data dictionaries
• centralized definitions
– Structured English
• to describe transformation of terminal bubbles
Ch. 7 52
 DFDs: a reminder
A file

A
data
transformer

An output
An input device
device

Ch. 7 53
 Em ployee_2

Em ployee_1 Authorization
Reques t

Reques t
Regis tration
Res ult

Em ployee_3

Res pons e

Authorized_reques ts

Order_reques t
Analysis of
office work
Proces s Proces s Proces s

Em ployee_6
Em ployee_5
Em ployee_4
Com plete_order

Ch. 7 54
 Letter forms

Authorized requests
Get letter Letter
form form
Order Type of
request Extract letter
order
data Quantity
to order

Compose
Addressee
order

Automated Address
portion
Complete
order
Get
address

Address

Addresses

Ch. 7 55
 From analysis to design
• Use of Structured Diagrams (SDs)
• A "method" is provided to transform
DFDs into SDs; tries to
– minimize coupling
– maximize cohesion

Ch. 7 56
 SD
• A DAG of functional modules
(direction of arrow is implicitly downward)

M1 M2 M3

Ch. 7 57
 Decorated SDs

selection
M loop
data flow X

A C

M1 M2

Ch. 7 58
 Decorated SDs
M M1 abstract input
M2 transformation
Y M3 abstract output
X
X Y

M1 M2 M3

X
X1 X1

M 1,1 M 1,2

Ch. 7 59
SD for the "order" DFD

Order
main

A
Q A L
AE
T
T L Q
AE

Produce Print
Get data for order form
data order form

Ch. 7 60
 JSD and JSP
• Jackson's System Development
– modeling stage
• analysis and modeling of the external world
– entities
– actions (described by process structure diagram)
– network stage
• system modeled as a network of
interconnected and communicating processes—
system specification network (SSN)
– implementation stage
Ch. 7 61
 A
PSD
(a) sequence
(b) selection
(c) iteration
B C D

(a)
X

*
Y
o o
L M
(c)

Ch. 7 62
(b)
 Network stage (SSNs)

P A Q

(a) Processes connected by data structure

P' A' Q'

(b) Connection by state vector

Ch. 7 63
Implementation stage (JSP)
Transfer
order Output
file report

*
Item Header Body
group

*
* Net item
Transfer transfer
record

o o Input and output data structures

Receipt Delivery Correspondence between nodes

Ch. 7 Program structure 64

 Program
1. open files

2. close files

Generate 3. read (item_id, movement)

Generate
header body
4. net_item_movement := 0

5. net_movement_item := net_movement_item + movement

Generate *
line by
6. net_movement_item := net_movement_item - movement
item group

7. write (header)
Output net
Process
movement 8. write (net_item_movement_line)
item
line
group

*
Process
record The resulting program
o
structure
Process o
Process
receipt delivery

Ch. 7 65
 Program
1, 3, 7 2

Generate Generate

Annotated program
header body

Generate * structure
Trivially translatable
4 line by 8
item group

Output net
into a program
Process
item transfer
group line

*
3 Process
record

o o
Process Process
receipt 5 delivery 6

(c)

Ch. 7 66
 Unified Software
Development Process
(UP)

Ch. 7 67
 Principles
• Development of an OO system
• Uses the UML notation throughout the
process
• Supports an iterative and incremental
process
• Decomposes a large process into
controlled iterations (mini projects)

Ch. 7 68
Cycles and phases of a cycle
product
releases

cycle1 cycle2 ... cycle n

time
death

product
Inception Elaboration Construction Transition release

milestone

Ch. 7 69
 Distribution of workflows
over phases
inception elaboration construction transition

Requirements

Analysis

Design

Implementation

Testing
Iter1 Iter2 ... ... ... ... ... ... ... ... Iter n

Ch. 7 70
 Organizing artifacts
Configuration management

Ch. 7 71
 CM concepts
• Configuration
– identifies components and their versions
• Configuration management
– discipline of coordinating software
development and controlling the change
and evolution of software products and
components

Ch. 7 72
 Key CM issues
• Multiple access to shared repository
• Handling product families
– different members of the family comprise
components which may have different
versions

Ch. 7 73
 Component database
Member 1

A A B
1 1 E
B

C1 D A2 A
3

C C
1 2

Member 2

A2
Member 3
B
A3
C2
D

Ch. 7 74
 Baseline and private
workspaces
• Project baseline
– central repository of reviewed and
approved artifacts that represent a given
stable point in system development
• Private workspaces
– private and intermediate versions of
components

Ch. 7 75
 Versions
• Can be refined into
– revisions
• new version supersedes the previous
• define a linear order
– variants
• e.g., alternative implementations of the same
specification for different machines, or access
to different I/O devices

Ch. 7 76
 Derived versions
• Further logical relations may exist
among versions of components
• A component may be derived from
another
– object code component is a derived version
of a source code component

Ch. 7 77
Software standards

Ch. 7 78
 Why standards?
• They are needed to achieve quality in
both software products and processes
• They may be imposed internally or
externally
– e.g., MIL-STD 2167A imposed to
contractors for military applications
• Other examples: ISO series, IEEE

Ch. 7 79
 Main benefits
• From the developers' viewpoint
– standards enforce a uniform behavior within an
organization
– they facilitate communication among people,
stabilizes the production process, and makes it
easier to add new people to ongoing projects
• From the customers' viewpoint
– they make it easier to assess the progress and
quality of results
– they reduce the strict dependency of customers on
specific contractors
Ch. 7 80
 Issues with standards

• Freezing premature standards

– can inhibit acceptance of new ideas
• Standards proliferation
• De-facto standards vs. official standards

Ch. 7 81