Object-Oriented and

Classical Software
Engineering
Seventh Edition, WCB/McGraw-Hill, 2007

Stephen R. Schach
[email protected]
CHAPTER 3

SOFTWARE
PROCESS

2
Overview

 The Unified Process

 The requirements workflow
 The analysis workflow
 The design workflow
 The implementation workflow
 The test workflow

3
Overview (contd)
• Postdelivery maintenance
• Retirement
• The phases of the Unified Process
• One- versus two-dimensional life-cycle models
• Improving the software process
• Other software process improvement initiatives
• Costs and benefits of software process
improvement

4
3.3 The Requirements Workflow
 The aim of the requirements workflow
 To determine the client’s needs

5
 Overview of the Requirements
Workflow
 First, gain an understanding of the application
domain (or domain, for short)
 That is, the specific business environment in which the
software product is to operate

 Second, build a business model

 A document that demonstrates the cost effectiveness of
the target product (cost can be financial or strategic)
 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

6
Overview of the Requirements Workflow
(contd)
• 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 client will rarely inform the developer how much
money is available
• A bidding procedure is used instead

7
Overview of the Requirements Workflow
(contd)
 The aim of this concept exploration is to
determine
 What the client needs
 Not what the client wants

8
3.4 The Analysis Workflow
• The aim of the analysis workflow
– To analyze and refine the requirements

• 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
9
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

10
The Specification Document (contd)
• Specification document (“specifications”)
– It constitutes a contract
– It must not have imprecise phrases like “optimal,”
or “98% complete”

• Having complete and correct specifications is

essential for
– Testing and
– Maintenance

11
The Specification Document (contd)
 The specification document must not have
 Contradictions
 Ambiguity
 Incompleteness

12
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

13
3.5 The Design Workflow
 The aim of the design workflow is to refine the
analysis workflow until the material is in a
form that can be implemented by the
programmers
 Many nonfunctional requirements need to be
finalized at this time, including
 Choice of programming language
 Reuse issues
 Portability issues

14
Classical Design
 Architectural design
 Decompose the product into modules

 Detailed design
 Design each module:
 Data structures
 Algorithms

15
The Design Workflow (contd)
 Retain design decisions
 For when a dead-end is reached
 To prevent the maintenance team reinventing the
wheel

16
3.6 The Implementation Workflow
 The aim of the implementation workflow is to
implement the target software product in the
selected implementation language
 A large software product is partitioned into
subsystems
 The subsystems consist of components or code
artifacts

17
3.7 The Test Workflow
 The test workflow is the responsibility of
 Every developer and maintainer, and
 The quality assurance group

 Traceability of artifacts is an important

requirement for successful testing

18
3.7.1 Requirements Artifacts
 Every item in the analysis artifacts must be
traceable to an item in the requirements
artifacts
 Similarly for the design and implementation
artifacts

19
3.7.2 Analysis Artifacts
 The analysis artifacts should be checked by
means of a review
 Representatives of the client and analysis team
must be present

 The SPMP must be similarly checked

 Pay special attention to the cost and duration
estimates

20
3.7.3 Design Artifacts
 Design reviews are essential
 A client representative is not usually present

21
3.7.4 Implementation Artifacts
• Each component is tested as soon as it has
been implemented
– Unit testing
• At the end of each iteration, the 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
22
Implementation Artifacts (contd)
 COTS software is released for testing by
prospective clients
 Alpha release
 Beta release

 There are advantages and disadvantages to

being an alpha or beta release site

23
3.8 Postdelivery Maintenance
 Postdelivery maintenance is an essential
component of software development
 More money is spent on postdelivery maintenance
than on all other activities combined

 Problems can be caused by

 Lack of documentation of all kinds

24
Postdelivery Maintenance (contd)
 Two types of testing are needed
 Testing the changes made during postdelivery
maintenance
 Regression testing

 All previous test cases (and their expected

outcomes) need to be retained

25
3.9 Retirement
• Software 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)

26
Retirement (contd)
 True retirement is a rare event

 It occurs when the client organization no

longer needs the functionality provided by the
product

27
3.10 The Phases of the Unified Process

 The increments are identified as phases

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

29
The Phases of the Unified Process (contd)
• 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?
30
The Phases of the Unified Process (contd)
 Workflow
 Technical context of a step

 Phase
 Business context of a step

31
3.10.1 The Inception Phase
 The aim of the inception phase is to
determine whether the proposed software
product is economically viable
 Obtaining the initial version of the business
case is the overall aim of the inception phase

32
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 (scope of
the software product as well as the financial details:
revenue projections, market estimates, initial cost
estimates).
33
3.10.2 Elaboration Phase
• 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

34
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

35
3.10.3 Construction Phase
 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

36
The Tasks of the Construction Phase
 The emphasis in this phase is on
 Implementation and
 Testing
 Unit testing of modules
 Integration testing of subsystems
 Product testing of the overall system

37
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

38
3.10.4 The Transition Phase
• 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

39
The Transition Phase: Documentation
 The deliverables of the transition phase
include:
 All the artifacts (final versions)
 The completed manuals

40
3.11 One- and Two-Dimensional Life-Cycle
Models

41 Figure 3.2
Why a Two-Dimensional Model?
(contd)
 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

42
Why a Two-Dimensional Model?
(contd)
• 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

• A software product has to be broken into

subsystems

• Even subsystems can be too large at times

– Components may be all that can be handled until a
fuller understanding of all the parts of the product
as a whole has been obtained
43
Why a Two-Dimensional Model?
(contd)
• The Unified Process handles the inevitable
changes well
– The moving target problem
– The inevitable mistakes

• The Unified Process is the best solution found

to date for treating a large problem as a set of
smaller, largely independent subproblems
– It provides a framework for incrementation and
iteration
– In the future, it will inevitably be superseded by
some better methodology
44