Documente Academic
Documente Profesional
Documente Cultură
process
Ch. 7 1
Questions
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
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
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
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
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
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
*
Item Header Body
group
*
* Net item
Transfer transfer
record
2. close files
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
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
Ch. 7 81