Software Engineering

CHAPTER 3
THE SOFTWARE
PROCESS

Jerry Breecher
Clark University
Modified from the notes of

Stephen R. Schach
Chapter 3 1
 Overview
 The Unified Process
 WORKFLOWS
 The requirements workflow
 The analysis workflow
 The design workflow
 The implementation workflow
 The test workflow
 Post delivery maintenance

 PHASES of the Unified Process

 One- versus two-dimensional life-cycle models
 Improving the software process
 Capability maturity models
Chapter 3 2
 3.1 The Unified Process
 In Perspective:
 Most of the world is NOT object oriented and doesn’t use the process
we’re presenting here.
 However, in practice, they do something very similar that works for
them.

 In 1999, Booch, Jacobson, and Rumbaugh published a

complete object-oriented analysis and design methodology
that unified their three separate methodologies. Called the
Unified Process.

 The Unified Process is an adaptable methodology

It has to be modified for the specific software product to
be developed
Chapter 3 3
 The Unified Process (contd)
 UML is graphical
 A picture is worth a thousand words
 UML diagrams enable software engineers to communicate quickly and
accurately
 The Unified Process is a modeling technique
 A model is a set of UML diagrams that represent various aspects of the software
product we want to develop
 UML stands for unified modeling language
 UML is the tool that we use to represent (model) the target software product
 The object-oriented paradigm is iterative and incremental in nature
 There is no alternative to repeated iteration and incrementation until the UML
diagrams are satisfactory
 The version of the Unified Process in this book is for
 Software products small enough to be developed by a team of three students
during the semester or quarter
 However, the modifications to the Unified Process for developing a large
software product are also discussed Chapter 3 4
 Iteration and Incrementation

 The goals of this book include:

 A thorough understanding of how to develop smaller software products
 An appreciation of the issues that need to be addressed when larger software
products are constructed

 We cannot learn the complete Unified Process in one semester or quarter

 Extensive study and unending practice are needed

 The Unified Process has too many features
 A case study of a large-scale software product is huge
 In this book, we therefore cover much, but not all, of the Unified Process
 The topics covered are adequate for smaller products

 To work on larger software products, experience is needed

 This must be followed by training in the more complex aspects of the Unified
Process Chapter 3 5
 Iteration and Incrementation

 In this book, we cover much, but not all, of the Unified Process
 The topics covered are adequate for smaller products

 To work on larger software products, experience is needed

 This must be followed by training in the more complex aspects of the
Unified Process

 It takes 10 years to become an expert.

Chapter 3 6
 Process Overview
Phases (time)

Workflow Inception Elaboration Construction Transition

(tasks)
Requirements

Analysis

Design

Implementation

Test
Chapter 3 7
 Workflow
3.3 The Requirements Workflow (tasks)
Requirements
 The aim is to determine the client’s needs Analysis
 First, gain an understanding of the domain Design
 How does the specific business environment work Implementation
Testing
 Second, build a business model
 Use UML to describe the client’s business processes
 If at any time the client does not feel that the cost is justified, development
terminates immediately
 It is vital to determine the client’s constraints
 Deadline -- Nowadays software products are often mission critical
 Parallel running
 Portability
 Reliability
 Rapid response time
 Cost
 The aim of this concept exploration is to determine
 What the client needs, and
 Not what the client wants Chapter 3 8
 Workflow
3.4 The Analysis Workflow (tasks)
Requirements
Analysis
 The aim of the analysis workflow Design
 To analyze and refine the requirements Implementation
Testing
 Why not do this during the requirements workflow?
 The requirements artifacts must be totally comprehensible by the client
 The artifacts of the requirements workflow must therefore be
expressed in a natural (human) language
 All natural languages are imprecise
 Example from a manufacturing information system:
 “A part record and a plant record are read from the database. If it
contains the letter A directly followed by the letter Q, then calculate the
cost of transporting that part to that plant”
 To what does “it” refer?
 The part record?
 The plant record?
Chapter 3 9
 Or the database?
 The Analysis Workflow (contd)
 Two separate workflows are needed
 The requirements artifacts must be expressed in the language of the
client
 The analysis artifacts must be precise, and complete enough for the
designers
 Specification document (“specifications”)
 Constitutes a contract
 It must not have imprecise phrases like “optimal,” or “98 percent
complete”
 Having complete and correct specifications is essential for
 Testing, and
 Maintenance
 The specification document must not have
 Contradictions
 Omissions
 Incompleteness Chapter 3 10
 Software Project Management Plan
 Once the client has signed off the specifications, detailed planning and
estimating begins

 We draw up the software project management plan, including

 Cost estimate
 Duration estimate
 Deliverables
 Milestones
 Budget

 This is the earliest possible time for the SPMP

Chapter 3 11
 Workflow
3.5 The Design Workflow (tasks)
Requirements
The goal is to refine the analysis workflow until the material is in a Analysis
form that can be implemented by the programmers Design
 Many nonfunctional requirements need to be finalized at this time, Implementation
including: Choice of programming language, Reuse issues,
Testing
Portability issues.
Classical Design
 Architectural design
 Decompose the product into modules
 Detailed design
 Design each module using data structures and algorithms
Object Oriented Design
 Classes are extracted during the object-oriented analysis
workflow, and
 Designed during the design workflow
Mapping between Classical and OO
 Classical architectural design corresponds to part of the object-oriented
analysis workflow
 Classical detailed design corresponds to part of the object-oriented
design workflow Chapter 3 12
 Object-Oriented Design

 Classes are extracted during the object-oriented

analysis workflow, and
Designed during the design workflow

 Accordingly
Classical architectural design corresponds to part of the
object-oriented analysis workflow
Classical detailed design corresponds to part of the
object-oriented design workflow

Chapter 3 13
 The Design Workflow (contd)

 Retain design decisions

For when a dead-end is reached, and
To prevent the maintenance team reinventing the wheel

Chapter 3 14
 Workflow
3.6 The Implementation Workflow (tasks)
Requirements
Analysis
 The aim of the implementation workflow is to Design
implement the target software product in the Implementation

selected implementation language Testing

 A large software product is partitioned into subsystems

 The subsystems consist of components or code
artifacts

Chapter 3 15
 Workflow
3.7 The Test Workflow (tasks)
Requirements
Analysis
 The test workflow is the responsibility of Design
 Every developer and maintainer, and Implementation
 The quality assurance group Testing

 Traceability of artifacts is an important requirement for

successful testing

Chapter 3 16
 3.7 Artifacts / Products
Requirements:
 Starting point – every subsequent product must be traceable back to here.

Analysis
 The analysis artifacts should be checked by means of a review
 Representatives of the client and analysis team must be present
Design
 Design reviews are essential
 A client representative is not usually present
Implementation
 Each component is tested as soon as it has been implemented
 Unit testing
 At end of each iteration, completed components are combined and tested
 Integration testing
 When the product appears to be complete, it is tested as a whole
 Product testing
 Once the completed product has been installed on the client’s computer, the
client tests it
 Acceptance testing Chapter 3 17
 3.8 Post delivery Maintenance
 Post delivery maintenance is an essential component of
software development
 More money is spent on post delivery maintenance than on all other
activities combined

 Problems can be caused by

 Lack of documentation of all kinds

 Two types of testing are needed

 Testing the changes made during post delivery maintenance
 Regression testing

 All previous test cases (and their expected outcomes) need to

be retained
Chapter 3 18
 3.9 Retirement
 Software is can be unmaintainable because
 A drastic change in design has occurred
 The product must be implemented on a totally new hardware/operating
system
 Documentation is missing or inaccurate
 Hardware is to be changed—it may be cheaper to rewrite the software
from scratch than to modify it

 These are instances of maintenance (rewriting of existing

software)
 True retirement is a rare event

 It occurs when the client organization no longer needs the

functionality provided by the product Chapter 3 19
 3.10 The Phases of the Unified Process
 The
increments are
identified as
phases
 Workflow is
Technical
context of a
step
 Phase is
Business
context of a
step

Chapter 3 20
Figure 3.1
 The Phases of the Unified Process (contd)
 The four increments are labeled
 Inception phase
 Elaboration phase
 Construction phase
 Transition phase

 The phases of the Unified Process are the increments

 In theory, there could be any number of increments

 In practice, development seems to consist of four increments

 Every step performed in the Unified Process falls into

 One of the five core workflows and also
 One of the four phases

 Why does each step have to be considered twice?

Chapter 3 21
 Phases
The Inception Phase Inception Elaboration Construction Transition

 The aim of the inception phase is to determine whether the

proposed software product is economically viable. To do this
we need to:
 1. Gain an understanding of the domain

 2. Build the business model

 3. Delimit the scope of the proposed project

 Focus on the subset of the business model that is covered by the
proposed software product

 4. Begin to make the initial business case

Chapter 3 22
The Inception Phase : The Initial Business Case

 Questions that need to be answered include:

Is the proposed software product cost effective?
How long will it take to obtain a return on investment?
Alternatively, what will be the cost if the company decides
not to develop the proposed software product?
If the software product is to be sold in the marketplace, have
the necessary marketing studies been performed?
Can the proposed software product be delivered in time?
If the software product is to be developed to support the
client organization’s own activities, what will be the impact if
the proposed software product is delivered late?

Chapter 3 23
 The Inception Phase: The Initial Business Case

 What are the risks involved in developing the software

product, and
 How can these risks be mitigated?
Does the team who will develop the proposed software
product have the necessary experience?
Is new hardware needed for this software product?
 If so, is there a risk that it will not be delivered in time?
 If so, is there a way to mitigate that risk, perhaps by ordering back-up
hardware from another supplier?
Are software tools (Chapter 5) needed?
 Are they currently available?
 Do they have all the necessary functionality?

Chapter 3 24
 The Inception Phase: Risks

 There are three major risk categories:

Technical risks
 See earlier slide
The risk of not getting the requirements right
 Mitigated by performing the requirements workflow correctly
The risk of not getting the architecture right
 The architecture may not be sufficiently robust
 To mitigate all three classes of risks
The risks need to be ranked so that the critical risks are
mitigated first
 This concludes the steps of the inception phase that
fall under the requirements workflow
Chapter 3 25
 The Inception Phase: Analysis, Design. Test
 A small amount of the analysis workflow may be performed
during the inception phase
 Information needed for the design of the architecture is extracted
 Accordingly, a small amount of the design workflow may be
performed, too
 Coding is generally not performed during the inception phase
 However, a proof-of-concept prototype is sometimes build to test the
feasibility of constructing part of the software product
 The test workflow commences almost at the start of the
inception phase
 The aim is to ensure that the requirements have been accurately
determined

Chapter 3 26
 The Inception Phase: Planning

 There is insufficient information at the beginning of

the inception phase to plan the entire development
The only planning that is done at the start of the project
is the planning for the inception phase itself

 For the same reason, the only planning that can

be done at the end of the inception phase is the
plan for just the next phase, the elaboration phase

Chapter 3 27
 The Inception Phase: Documentation

 The deliverables of the inception phase include:

The initial version of the domain model
The initial version of the business model
The initial version of the requirements artifacts
A preliminary version of the analysis artifacts
A preliminary version of the architecture
The initial list of risks
The initial ordering of the use cases (Chapter 10)
The plan for the elaboration phase
The initial version of the business case

Chapter 3 28
 Phases
Elaboration Phase Inception Elaboration Construction Transition

 The aim of the elaboration phase is to refine the initial

requirements
 Refine the architecture
 Monitor the risks and refine their priorities
 Refine the business case
 Produce the project management plan

 The major activities of the elaboration phase are refinements

or elaborations of the previous phase

 The tasks of the elaboration phase correspond to:

 All but completing the requirements workflow
 Performing virtually the entire analysis workflow
 Starting the design of the architecture
Chapter 3 29
 The Elaboration Phase: Documentation

 The deliverables of the elaboration phase include:

The completed domain model
The completed business model
The completed requirements artifacts
The completed analysis artifacts
An updated version of the architecture
An updated list of risks
The project management plan (for the rest of the
project)
The completed business case

Chapter 3 30
 Phases
Construction Phase Inception Elaboration Construction Transition

 The aim of the construction phase is to produce the

first operational-quality version of the software
product
This is sometimes called the beta release
 The emphasis in this phase is on
Implementation, and
Testing
 Unit testing of modules
 Integration testing of subsystems
 Product testing of the overall system

Chapter 3 31
 The Construction Phase: Documentation

 The deliverables of the construction phase include:

The initial user manual and other manuals, as appropriate
All the artifacts (beta release versions)
The completed architecture
The updated risk list
The project management plan (for the remainder of the
project)
If necessary, the updated business case

Chapter 3 32
 Phases
The Transition Phase Inception Elaboration Construction Transition

 The aim of the transition phase is to ensure that the client’s

requirements have indeed been met

 Faults in the software product are corrected

 All the manuals are completed
 Attempts are made to discover any previously unidentified risks

 This phase is driven by feedback from the site(s) at which the beta
release has been installed

 The deliverables of the transition phase include:

 All the artifacts (final versions)
 The completed manuals

Chapter 3 33
 The Transition Phase: Documentation

 The deliverables of the transition phase include:

All the artifacts (final versions)
The completed manuals

Chapter 3 34
 Phase Deliverables
Inception Phase Elaboration Phase Construction Phase Transition Phase

The initial version of The completed  The initial user  All the artifacts (final
the domain model domain model manual and other versions)
The initial version of The completed manuals, as  The completed
the business model business model appropriate manuals
The initial version of The completed  All the artifacts
the requirements requirements (beta release
artifacts artifacts versions)
A preliminary version The completed  The completed
of the analysis analysis artifacts architecture
artifacts An updated version  The updated risk list
A preliminary version of the architecture  The project
of the architecture An updated list of management plan
The initial list of risks risks (for the remainder of
The initial ordering of The project the project)
the use cases management plan  If necessary, the
The plan for the (for the rest of the updated business
elaboration phase project) case
The initial version of The completed
the business case business case

Chapter 3 35
 Why a Two-Dimensional Model?

 The waterfall model

 The traditional method is Requirements

One-dimensional.
Analysis

 Doesn’t account for the Design

iterative nature of
development. Implementation

Development
Maintenance

Chapter 3 36
Figure 2.3 (again)
 Why a Two-Dimensional Model? (contd)
 Evolution tree model
 The Unified Process is Two-dimensional
 The two-dimensional figure shows
 The workflows (technical contexts), and
 The phases (business contexts)

Development
Maintenance
Requirements Requirements

Analysis Analysis

Design Design Design

Implementation Implementation Implementation Implementation

Chapter 3 37
Figure 2.2 (again)
 Why a Two-Dimensional Model? (contd)
 Are all the additional complications of the two-dimensional
model necessary?

 In an ideal world, each workflow would be completed before the

next workflow is started

 In reality, the development task is too big for this

 As a consequence of Miller’s Law

 The development task has to be divided into increments (phases)
 Within each increment, iteration is performed until the task is complete

 At the beginning of the process, there is not enough information

about the software product to carry out the requirements
workflow
 Similarly for the other core workflows Chapter 3 38
 Why a Two-Dimensional Model? (contd)
 A software product has to be broken into subsystems

 Even subsystems can be too large at times

 Modules may be all that can be handled until a fuller understanding of
all the parts of the product as a whole has been obtained

 The Unified Process handles the inevitable changes well

 The moving target problem
 The inevitable mistakes

 The Unified Process works for treating a large problem as a

set of smaller, largely independent sub problems
 It provides a framework for incrementation and iteration
 In the future, it will inevitably be superseded by some better
methodology
Chapter 3 39
 3.12 Improving the Software Process
 Capability Maturity Models
 A strategy for improving the software process
 Put forward in 1986 by the SEI

 Fundamental ideas:
 Improving the software process leads to
 Improved software quality
 Delivery on time, within budget
 Improved management leads to
 Improved techniques

 Five levels of maturity are defined

 Maturity is a measure of the goodness of the process itself

 An organization advances stepwise from level to level

Chapter 3 40
 The Levels
 Level 1. Initial Level
 Ad hoc approach
 The entire process is unpredictable
 Management consists of responses to crises

 Most organizations world-wide are at level 1

 Level 2. Repeatable Level

 Basic software management
 Management decisions should be made on the basis of previous
experience with similar products
 Measurements (“metrics”) are made
 These can be used for making cost and duration predictions in
the next project
 Problems are identified, immediate corrective action is taken

Chapter 3 41
 The Levels
 Level 3. Defined Level
 The software process is fully documented
 Managerial and technical aspects are clearly defined
 Continual efforts are made to improve quality and productivity
 Reviews are performed to improve software quality
 CASE tools are applicable now (and not at levels 1 or 2)

 Level 4. Managed Level

 Quality and productivity goals are set for each project
 Quality and productivity are continually monitored
 Statistical quality controls are in place

 Level 5. Optimizing Level

 Continuous process improvement
 Statistical quality and process controls
 Feedback of knowledge from each project to the next

Chapter 3 42
 Experiences with CMM

 It takes:
3 to 5 years to get from level 1 to level 2
1.5 to 3 years from level 2 to level 3
SEI questionnaires highlight shortcomings, suggest ways
to improve the process

Chapter 3 43
 Chapter Summary
 The Unified Process
 WORKFLOWS
 The requirements workflow
 The analysis workflow
 The design workflow
 The implementation workflow
 The test workflow
 Post delivery maintenance

 PHASES of the Unified Process

 One- versus two-dimensional life-cycle models
 Improving the software process
 Capability maturity models
Chapter 3 44