Object-Oriented and

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

Stephen R. Schach
srs@vuse.vanderbilt.edu
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
The Unified Process (contd)
• The Unified Process is not a series of steps for
constructing a software product
– No such single “one size fits all” methodology could exist
– There is a wide variety of different types of software

• The Unified Process is an adaptable methodology

– It has to be modified for the specific software product to be
developed

5
The Unified Process (contd)
 UML is graphical
 A picture is worth a thousand words

 UML diagrams enable software engineers to communicate

quickly and accurately

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

7
 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

 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

8
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

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

10
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

11
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

12
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

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

14
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

15
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

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

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

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

18
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

19
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

20
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

21
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

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

23
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

24
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

25
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

26
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

27
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)

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

 It occurs when the client organization no longer needs the

functionality provided by the product

29
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

31
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?

32
The Phases of the Unified Process (contd)
 Workflow
 Technical context of a step

 Phase
 Business context of a step

33
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

34
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

35
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

36
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

37
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

38
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

39
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

40
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

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

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

43 Figure 3.2
Why a Two-Dimensional Model?
• A traditional life cycle is a one-dimensional model
– Represented by the single axis on the previous slide
• Example: Waterfall model

• The Unified Process is a two-dimensional model

– Represented by the two axes on the previous slide

• The two-dimensional figure shows

– The workflows (technical contexts) and
– The phases (business contexts)

44
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

45
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

46
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

47