CHAPTER 3

THE SOFTWARE
PROCESS

1
 INTRODUCTION
• The software process is the way we produce
software

• It incorporates
• The methodology with its underlying software life-
cycle model
• Techniques and tools we use
• The individuals building the software

• Different organizations have different software

processes
2
 3.1 The Unified Process

• Methodology is one component of a

software process

• The primary object-oriented methodology

used today is the Unified Process

3
 The Unified Process …
• The Unified Process is not a specific series of steps
for constructing a software product
• No such single “one size fits all” methodology could exist,
because there is a wide variety of different types of
software
• For example, many application domains exist, such as
insurance, aerospace, and manufacturing.

• The Unified Process can be viewed as an adaptable

methodology
• It must be modified for the specific software product to be
developed
4
 3.2 Iteration and Incrementation within the
Object-Oriented Paradigm
• The object-oriented paradigm uses modeling throughout
• A model is a set of UML diagrams that represent various aspects of the
software product to be developed

• UML stands for Unified Modeling Language

• UML is the tool that we use to represent (model) the target software
product

• UML is graphical
• A picture is worth a thousand words

• UML diagrams enable software engineers to communicate more quickly

and accurately than if only verbal descriptions were used.
5
 Iteration and Incrementation within the
Object-Oriented Paradigm …
• The object-oriented paradigm is
iterative and incremental in nature
• Each workflow consists of a
number of steps
• The steps are repeatedly performed
until the development team is
satisfied that they have an
accurate UML model
• There is no alternative to
repeated iteration and
incrementation until the UML
diagrams are correct 6
 Iteration and Incrementation within the
Object-Oriented Paradigm …
• In other words, initially, the best possible UML diagrams are
drawn in the light of the knowledge available at the beginning of
the workflow.

• Then, as more knowledge about the real-world system being

modeled is gained, the diagrams are made more accurate
(iteration) and extended (incrementation).

7
 Iteration and Incrementation within the
Object-Oriented Paradigm …

• We cannot learn the complete Unified Process in one

semester.
• Extensive study and practice are needed
• The Unified Process has too many features
• A case study of a large-scale software product is huge

8
 3.3 The Requirements Workflow

• The aim of the requirements

workflow
• To determine the client’s needs

9
 Overview of the Requirements Workflow
• First, gain an understanding of the application domain
• That is, the specific business environment in which the
software product is to operate. E.g. banking, automobile
manufacturing, etc.

• Second, build a business model

• A document that demonstrates the cost-effectiveness of the
software
• If at any time the client does not feel that the cost is
justified, development terminates immediately

10
Overview of the Requirements Workflow …
• At an initial meeting between the client and
developers, the client outlines the product as he or she
conceptualizes it.

• From the viewpoint of the developers, the client’s

description of the desired product may be:
• Vague
• Unreasonable
• Contradictory,
• or simply impossible to achieve.
11
Overview of the Requirements Workflow …
• It is vital to determine what the client needs and to find out
what constraints exist.
• Deadline: Nowadays, software products are often mission-
critical. Any delay in delivering the target product is
detrimental to the organization.

• Reliability: for example, the product must be operational 99%

of the time.

• Cost
• The client will rarely inform the developer how much
money is available
• A bidding procedure is used instead 12
Overview of the Requirements Workflow …
• Preliminary investigation of the client’s needs is often called
concept exploration

• The aim of this concept exploration is to determine

• What the client needs (indispensable to survive)
• Not what the client wants (desires)

• In subsequent meetings between members of the development

team and the client team, the functionality of the proposed product
is successively refined and analyzed for technical feasibility and
financial justification.

13
Overview of the Requirements Workflow …
• Often, when the software is delivered, it is not what the
client wanted

• Software is complex, and it is difficult for the client to

visualize a piece of software and its functionality.

• The Unified Process can help in this regard.

• UML diagrams of the Unified Process can assist the client in
gaining the necessary detailed understanding of what needs
to be developed.
14
 3.4 The Analysis Workflow
• The aim of the analysis workflow
• To analyze and refine the requirements with the goal of
achieving a detailed understanding of the requirements essential
for developing a software product correctly and maintaining it
easily.

• Discuss: 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
• However, all natural languages are vague
15
 The Analysis Workflow …
• 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?
• Or the database?
16
 The Analysis Workflow …
• Ambiguities are unlikely to arise if a mathematical
language is used
• However, the client is unlikely to understand,
which can lead to miscommunication between the
client and developers.

• Consequently, the software product developed to

satisfy those requirements may not meet the client’s
needs.

17
 The Analysis Workflow …
• The solution is to have two separate workflows.
• The requirements artifacts must be expressed in the
language of the client
• The analysis workflow must be in a more precise
language that ensures that the design and
implementation workflows are correctly carried out.
• More detail is added during the analysis workflow,
• details not relevant to the client’s understanding of
the target software product
• but essential for the software professionals who
will develop the software product.

18
 The Specification Document
• Specification document
• It constitutes a contract.
• The software developers are deemed to have completed
the contract when they deliver a product that satisfies
the acceptance criteria of the specifications.
• Therefore, the specification document must not have
imprecise phrases like “optimal,” or “98% complete”,
“suitable”, “convenient”, “ample,” or “enough.”

• Having complete and correct specifications is essential for

• Testing and
• Maintenance 19
 The Specification Document …
• Unless specifications are precise, it cannot be determined
• Whether they are correct
• Whether the product meets the specifications

• With the unified process, a specification document consists of UML

diagrams

• These UML diagrams and their descriptions can prevent

many (but by no means all) of the problems of the classical
specification document.

• During analysis, the architecture of the product is determined

• Classes
• Attributes (data) of classes
20
 The Specification Document …
• The specification document must not have
• Ambiguities
• Contradictions
• Errors
• Incompleteness

• For example (considering a product that controls the

fermentation process)
• One place in the specification document may state, “If the pressure
exceeds 35psi, valve M17 must be shut.”
• Another place may state, “If the pressure exceeds 35psi, the operator
must immediately be alerted; only if the operator takes no remedial
action within 30 seconds should valve M17 be shut automatically.”

• Software development cannot proceed until such problems in the

specifications have been corrected.
21
 The Specification Document …

• Many of these problems can be reduced by using the

Unified Process.

• This is because UML diagrams together with

descriptions of those diagrams are less likely to
contain ambiguity, incompleteness, and
contradictions.

22
 Software Project Management Plan
• Once the client has signed off the specifications,
detailed planning and estimating begins.

• The specification document is only said to be finalized after

the software project management plan (SPMP) has been
drawn up.

• The SPMP describes the software process in

fullest detail.
23
 Software Project Management Plan …
• No client authorizes a software project without
knowing in advance how long the project will take
and how much it will cost.

• If the developers underestimate the cost of a project,

then the client pays the agreed-upon fee, which may
be significantly less than the developers’ actual cost.

• Conversely, if the developers overestimate what the

project costs, then the client may turn down the
project or have the job done by other developers
whose estimate is more reasonable.
24
 Software Project Management Plan …
• Similar issues arise with regard to duration estimates.

• If the developers underestimate how long completing a project

will take, then the resulting late delivery of the product,
• at best, results in a loss of confidence by the client.
• At worst, lateness penalty clauses in the contract are invoked, causing
the developers to suffer financially.

• Again, if the developers overestimate how long it will take for

the product to be delivered, the client may well award the job to
developers who promise faster delivery.

25
 Software Project Management Plan …
• For the developers, merely estimating
the duration and total cost is not enough.
• The developers need to assign the
appropriate personnel to the various
workflows of the development process.
• A software project management plan
(SPMP) must be drawn up that
• reflects the separate workflows of the
development process
• and shows which members of the
development organization are involved
in each task,
• as well as the deadlines for completing
each task.
26
 Software Project Management Plan …
• Without the SPMP, complete planning cannot be done
because the project is too vague or shapeless.
• The developers must know exactly what is to
be built before they can specify all aspects of
the plan for building it.

• This emphasizes the importance of the SPMP.

27
 Software Project Management Plan …
• The software project management plan (SPMP) should include:
• Cost estimate
• Duration estimate
• Deliverables
• Milestones
• Budget
• Life cycle model to be used
• Project responsibilities
• Managerial objectives and priorities
• Detailed schedules, budgets, and resource allocations

• The plan describes the software process in fullest detail.

• The earliest that such a detailed plan can be drawn up is when the
specifications have been finalized. 28
 3.5 The Design Workflow
• Specifications
• What the product must do

• Design
• How the product is to do it

• The aim of the design workflow is to

refine the artifacts of the analysis
workflow
• until the material is in a form
that can be implemented by the
programmers
29
 The Design Workflow …
• During the classical design phase, the design
team determines the internal structure of the
product.

• The designers decompose the product into

modules - independent pieces of code with well-
defined interfaces to the rest of the product.
• The interface of each module (that is, the arguments passed to
the module and the arguments returned by the module) must
be specified in detail.
30
 The Design Workflow …
• Once the team has completed the
decomposition into modules (the architectural
design),
• the detailed design is performed.

• For each module:

• Algorithms are selected, and
• Data structures are chosen.

31
 Object-Oriented paradigm
• The basis of the OO paradigm is the class – a specific type
of module.
• Classes are extracted during the analysis workflow, but
• Designed during the design workflow
• Methods are extracted and assigned to classes
• Interfaces between methods are determined
• Algorithms are chosen for each method
• Attributes are extracted during analysis,
• but formats are assigned during the design

32
 Object-Oriented paradigm …
• The design team must retain design decisions
• For when a dead-end is reached and the design team
must backtrack and redesign.
• Having a written record of why specific decisions
were made will assist the team. Why? Discuss.
• To facilitate future enhancements (postdelivery
maintenance).
• There may be the need to add new classes or replace an
existing class.
• The task of the redesign team is considerably easier if the
team members are provided with a record of the reasons
for all the original design decisions. 33
 3.6 The Implementation Workflow
• The aim of the implementation
workflow is to implement the target
software product in the selected
implementation language
• A small software is sometimes
implemented by the designer.
• A large software product is partitioned
into subsystems (implemented in
parallel by coding teams)
• The subsystems consist of components
or code artifacts (implemented by an
individual programmer)
• Usually, the programmer is only given
the relevant design artifact.
34
 The Implementation Workflow …
• For example, in the case of the classical paradigm, the
programmer is given the detailed design of the module he or
she is to implement.
• The detailed design usually provides enough information for
the programmer to implement the code artifact without too
much difficulty.
• If there are any problems, they can quickly be cleared up by
consulting the responsible designer.
• However, there is no way for the individual programmer to know
if the architectural design is correct.
• Only when integration of individual code artifacts commences do the
shortcomings of the design as a whole start coming to light.
35
 The Implementation Workflow …
• Suppose that:
• A number of code artifacts have been implemented and integrated and
the parts of the product integrated so far appear to be working correctly.
• A programmer has correctly implemented artifact a45, but when this
artifact is integrated with the other existing artifacts, the product fails.
• The cause of the failure is not because of a fault in artifact a45 itself, but
rather in the way that artifact a45 interacts with the rest of the product,
specified in the architectural design.
• Unfortunately, the programmer who just coded artifact a45 tends
to be blamed for the failure.
• This should not be, because the programmer has simply followed the
instructions provided by the designer and implemented the artifact
exactly as described in the detailed design for that artifact.

36
 The Implementation Workflow …

• The members of the programming team are rarely

shown the “big picture,” that is, the architectural
design, let alone asked to comment on it.

• This is yet another reason why it is very important

for the design to be correct in every respect.

• The correctness of the design (as well as the other

artifacts) is checked as part of the test workflow.
37
 3.7 The Test Workflow
• In the Unified Process,
testing is carried out in
parallel with the other
workflows.
• The test workflow is the
responsibility of
• Every developer and
maintainer, and
• The quality assurance
group
38
 The Test Workflow …
• Traceability of artifacts is an
important requirement for
successful testing.
• Traceability is the ability to trace work
items across the development
lifecycle.
• Traceability works by creating
dependencies between work items, such
as requirements or test cases.
• For example, you might link a bug to
code changes that eliminate that bug.
• You can then use the link to verify that
the bug was fixed, when, and by whom.
39
 The Test Workflow …
• Traceability example:
• Imagine we're developing a mobile app for ordering food. We want to
ensure that our app works correctly and meets the requirements.
• Requirement: "Users can search for restaurants by location“
• We create a requirement document (Artifact 1) with this statement.
• We then create test cases (Artifact 2) based on this requirement,
such as:
• Test Case 1: Search by city
• Test Case 2: Search by zip code
• We link these test cases to the original requirement document (Artifact
1).
• When we run the tests, we mark the results in a test report (Artifact
3).
• If a test fails, we create a bug report (Artifact 4) and link it to the failed
test case (Artifact 2) and the original requirement (Artifact 1).
40
 The Test Workflow …
• Traceability example:
• Traceability in Action
• Now, let's say we need to change the requirement to "Users can
search for restaurants by location or cuisine". We can easily:
• 1. Update the requirement document (Artifact 1)
• 2. Identify the affected test cases (Artifact 2) linked to the original
requirement
• 3. Update or create new test cases to cover the changed requirement
• 4. Run the updated tests and update the test report (Artifact 3)
• 5. Verify that the bug reports (Artifact 4) are still valid or update them
accordingly
• By maintaining traceability, we ensure that all related items
are updated and aligned throughout the development
lifecycle. This helps us deliver a high-quality app that meets
the requirements and works as expected. 41
 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

• If the requirements have been presented methodically,

properly numbered, cross-referenced, and indexed, then
• the developers should have little difficulty tracing
through the subsequent artifacts and ensuring that
they are indeed a true reflection of the client’s
requirements.

• Traceability simplifies the task of the SQA

group also.
42
 3.7.2 Analysis Artifacts

• Major source of faults in the delivered system are caused by

undetected faults in the specifications

• Therefore, the analysis artifacts should be carefully and thoroughly

checked.
• This can be achieved by means of a review (walkthroughs and inspections)
• Representatives of the client and analysis team must be present and the
meeting is chaired by a member of SQA group.
• Feasibility must also be determined

• The SPMP must be similarly checked

• Pay special attention to the cost and duration estimates

43
 3.7.3 Design Artifacts
• Design reviews are essential
• A client representative is not usually present due to the technical nature of the
review
• Members of the design team and SQA work through
• Design as a whole
• Each separate design
• Types of faults to look for include
• Logic faults
• Interface faults
• Lack of exception handling
• Non-conformance to the specifications
• Each part of the design must be able to be linked (traceability) to an
analysis artifact

44
 3.7.4 Implementation Artifacts

• Each unit is tested by the programmer while it is

being implemented (desk checking)
• After it has been implemented, the code is run against test
cases
• Each component is tested by SQA as soon as it has
been implemented
• Unit testing

45
 Implementation Artifacts …
• At the end of each iteration, the completed components are combined and
tested
• Integration testing

• This ensures that the (partially) completed product can always

function as a whole

• The way in which components are integrated (all at once or

individually), the order (top to bottom to bottom to top) can
influence the quality of the resulting product.

• Testing interfaces
• Order, type and number of arguments 46
 Implementation Artifacts …
• When the product appears to be complete, it is tested as
a whole by the SQA group.
• Product testing
• Functionality is tested against specifications, in particular,
the constraints listed in the specifications must be
tested.
• A typical example is whether the response time has been met.
• The robustness of the software must also be tested
• Intentionally erroneous input data are submitted to
determine whether the product will crash or whether its
error-handling capabilities are adequate for dealing with bad
data.
47
 Implementation Artifacts …
• Once the completed product has been installed on the
client’s computer, the client tests it using actual data
• Acceptance testing
• No matter how methodical the development team or
the SQA group might be,
• there is a significant difference between test cases,
which by their very nature are artificial, and actual
data.
• A software product cannot be considered to satisfy its
specifications until the product has passed its acceptance
test.

48
 Implementation Artifacts …
• In the case of Commercial off-the-shelf software (COTS), as
soon as product testing is complete, versions of the complete
product are supplied to selected possible future clients for
testing on-site.
• This version is called alpha release
• The corrected alpha release is called Beta release
• The beta release is intended to be close to the final version.
• So that as many faults as possible come to light as early as
possible, developers of COTS software frequently give alpha
or beta releases to selected companies.
• There are advantages and disadvantages to being an
alpha or beta release site
• Alpha release is fault ridden
• Companies get head start ahead of competitors 49
 3.8 Postdelivery Maintenance

• Postdelivery maintenance is an essential

component of software development
• Coding must be performed with future maintenance kept in
mind.
• More money is spent on postdelivery maintenance than on
all other activities combined

• Problems can be caused by

• Lack of documentation of all kinds

50
 Postdelivery Maintenance …
• Two types of testing are needed
• Testing that the required changes made during
postdelivery maintenance have been implemented
correctly
• Regression testing by using previous test cases (while
making required changes, no other inadvertent
changes were made)

• All previous test cases (and their expected outcomes)

need to be retained, together with the results of
running those test cases. 51
 3.9 Retirement
• After many years of service, a stage is reached when further
postdelivery maintenance is no longer cost-effective.
• Software can be unmaintainable because
• A drastic change in design has occurred. In such a case, it is less expensive
to redesign and recode the entire product.
• So many changes have been made to the original design that
interdependencies occur and even a small change to one component might
have a drastic effect on the functionality of the product as a whole.
• The documentation may not have been adequately maintained, thereby
increasing the risk of a regression fault to the extent that it would be
safer to recode than maintain.
• 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)
52
 Retirement

• True retirement is a rare event

• It occurs when
• the client organization no longer needs the
functionality provided by the product

53
3.10 The Phases of
the Unified Process
• The increments are
identified as phases
• The four increments are
labeled
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

• The phases of the

Unified Process are the
increments
54
 The Phases of the Unified Process …
• 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?

55
 The Phases of the Unified Process …
• Consider the requirements workflow.
• To determine the client’s needs, one of the steps is, to
build a business case.
• In other words, within the framework of the requirements workflow,
building a business case is presented within a technical context.
• A business case is also built within the framework of the
inception phase, the phase in which management decides
whether to develop the proposed software product.
• That is, building a business case shortly is presented within an
economic/business context
• The same step is considered twice, but at different level
of detail
56
 3.10.1 The Inception Phase
• The aim of the inception phase is to determine
whether the proposed software product is
economically viable
1. Gain an understanding of the domain.
• If the developers do not fully understand the
domain, little reliance can be placed on what they
subsequently build.
2. Build the business model
• Understand how the client organisation
operates in that domain
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
57
 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?

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

• Answers to these questions are needed by the end of the inception phase so that the initial
business case can be made

59
 The Inception Phase:
Risks
• The next step is to identify the risks.

• There are three major risk categories:

• Technical risks
• 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

60
 The Inception Phase:
Risks …

• 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

61
 The Inception Phase:
Analysis, Design Workflows

• A small amount of the analysis

workflow may be performed during
the inception phase
• All that is usually done is to extract
the information needed for the design of
the architecture
• Accordingly, a small amount of the
design workflow may be performed, too

62
 The Inception Phase:
Implementation Workflow
• Coding is generally not performed during the inception phase
• However, a proof-of-concept prototype is sometimes built to test the feasibility
of constructing part of the software product.
• Let's say you want to build a mobile app that allows users to order food
from local restaurants.
• During the inception phase, you might build a simple prototype to test the idea.
• Prototype:
• A basic web page or a PowerPoint presentation that simulates the app's
user interface
• A few buttons, screens, and sample data to demonstrate the ordering
process
• Maybe some mockup screens showing how the app would look and feel

63
 The Inception Phase:
Test Workflow

• The test workflow

commences almost at the
start of the inception phase
• The aim is to ensure that the
requirements have been
accurately determined

64
 The Inception Phase:
Planning
• Recall planning is an essential part of
every phase.
• 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

65
 The Inception Phase:
Documentation
• Documentation, too, is an essential part of every phase.
• 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 use cases (Chapter 10)
• The plan for the elaboration phase
• The initial version of the business case

66
 The Inception Phase:
The Initial Business Case …
• Obtaining the initial version of the business case is the overall aim of the
inception phase
• This initial version incorporates
• A description of the scope of the software product
• Financial details
• If the proposed software product is to be marketed, the business case
will also include
• Revenue projections, market estimates, initial cost estimates
• If the software product is to be used in-house, the business case will
include
• The initial cost–benefit analysis

67
 3.10.2 Elaboration Phase
• The aim of the elaboration phase
(second increment) 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
68
 The Tasks of the Elaboration Phase

• The tasks of the elaboration phase correspond to:

• All but completing the requirements workflow
• Chapter 11
• Performing virtually the entire analysis workflow
• Chapter 13
• Starting the design of the architecture
• Section 8.5.4

69
 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

70
 3.10.3 Construction Phase

• The aim of the

construction phase (third
increment) is to
• produce the first
operational-quality
version of the software
product
• Sometimes called the beta
release

71
 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

72
 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

73
 3.10.4 The Transition Phase
• The aim of the transition phase
(fourth increment) 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
74
 The Transition Phase:
Documentation
• The deliverables of the
transition phase include:
• All the artifacts (final
versions)
• The completed manuals

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

76
 Why a Two-Dimensional Model?
• A traditional life cycle is a one-
dimensional model
• Represented by the single axis in
(a)
• Example: Waterfall model
• The Unified Process is a two-
dimensional model
• Represented by the two axes in (b)
• The two-dimensional figure shows
• The workflows (technical
contexts) and
• The phases (business contexts)

77
 Why a Two-Dimensional Model? …
• 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, a software product is too large to
handle as a single unit.
• It must be broken into subsystems
• Even subsystem can be too large at
times
• 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 78
 Why a Two-Dimensional Model? …
• 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

79
 3.12 Improving the Software Process
• Our global economy depends critically on computers and
hence on software.

• For this reason, the governments of many countries are

concerned about the software process.

• Software process improvement initiatives

• Capability maturity model (CMM)
• ISO 9000-series
• ISO/IEC 15504

80
 3.13 Capability Maturity Models
• The capability maturity models are a related group of strategies for improving
the software process, irrespective of the actual life-cycle model used.
• SW–CMM for software
• P–CMM for human resources (p stand for “people”)
• SE–CMM for systems engineering
• IPD–CMM for integrated product development
• SA–CMM for software acquisition

• These strategies are unified into CMMI (capability maturity model

integration)

81
 Capability Maturity Models:
SW–CMM
• A strategy for improving the software process

• Put forward in 1986 by the Software Engineering

Institute (SEI).
• The institute was founded by a task force of the U.S.
Department of Defense

• Fundamental ideas:
• Improving the software process leads to
• Improved software quality
• Delivery on time, within budget
• Improved management leads to
82
• Improved techniques
 Capability Maturity Models:
SW–CMM …
• Five levels of maturity are defined

• An organization advances stepwise from level

to level

83
 Level 1. Initial Level
• No sound software engineering management practices
are in place in the organisation.

• Instead, everything is done on an ad hoc basis.

• The entire process is unpredictable

• Most activities are responses to crises rather than
preplanned tasks.

• Most organizations worldwide are at level 1

84
 Level 2. Repeatable Level
• Basic software management practices are in place
• Management decisions should be made on the basis of previous
experience with similar products
• At level 2, measurements are taken – an essential first step in
achieving an adequate process.
• The organization starts tracking important measurements like costs
and schedules.

• Instead of functioning in a crisis mode, as in level 1,

• managers identify problems as they arise and take immediate
corrective action to prevent them from becoming crises.

85
 Level 2. Repeatable Level …

• The key point is that, without measurements, it is

impossible to detect problems before they get out of
hand.

• Also, measurements taken during one project can be

used to draw up realistic duration and cost schedules
for future projects.

86
 Level 3. Defined Level
• At this 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 environments (Section 5.8) are applicable
now (and not at levels 1 or 2)
• CASE – Computer-aided Software Engineering

87
 Level 4. Managed Level
• A managed-level organization set quality and
productivity goals for each project
• Quality and productivity are continually monitored
using data and statistics.
• This helps distinguish between:
• Random deviations (one-time mistakes) and
• Systemic issues (repeated problems that need attention)

88
 Level 5. Optimizing Level
• The goal of an optimizing-level organization is
continuous process improvement
• Statistical quality and process controls techniques
are used to guide the organization
• The knowledge gained from each project is utilized in
future projects.
• The process, therefore, incorporates a positive feedback
loop, resulting in a steady improvement in
productivity and quality.

89
Summary

90
 Experiences with SW–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

91
3.14 Other Software Process Improvement
Initiatives

• ISO 9000-series

• ISO/IEC 15504

92
 ISO 9000
• ISO 9000 stresses documenting the process in both words and
pictures to ensure consistency and comprehensibility.

• Also, the ISO 9000 philosophy is that adherence to the standard does
not guarantee a high-quality product but rather reduces the risk of a
poor-quality product.

• Also required are management commitment to quality, intensive

training of workers, and setting and achieving goals for continual
quality improvement.

93
 ISO 9000 …

• ISO 9000-series standards have been adopted by over 60

countries, including the United States, Japan, Canada, and the
countries of the European Union (EU).

• This means, for example, that if a U.S. software organization

wishes to do business with a European client, the U.S.
organization must first be certified as ISO 9000 compliant.

94
 ISO/IEC 15504

• Original name: Software Process Improvement Capability

dEtermination (SPICE)
• It is an international process improvement initiative
• Started by the British Ministry of Defence (MOD)
• Includes process improvement, software procurement
• Extends and improves CMM, ISO 9000
• A framework, not a method
• CMM, ISO 9000 conform to this framework

95
3.15 Costs and Benefits of Software Process
Improvement
• Results indicate that implementing software process
improvement leads to increased profitability

• Hughes Aircraft (Fullerton, CA) spent $500K (1987–

90)
• Savings: $2M per year, moving from level 2 to level 3

• Raytheon moved from level 1 in 1988 to level 3 in

1993
• Productivity doubled
• Return of $7.70 for every dollar invested in process
improvement 96
 Costs and Benefits of Software Process
Improvement …

• Tata Consultancy Services (India) used ISO 9000

and CMM (1996–90)
• Errors in estimation decreased from 50% to 15%
• Effectiveness of reviews increased from 40% to 80%

• Motorola GED has used CMM (1992–97)

• See results in the next slide

97
 Results of 34 Motorola Projects

• NB
• MEASL – Million equivalent assembler
source lines
• Productivity is measured relative to that of a
selected level-2 project
• No fault or productivity data available for
level-1 projects (by definition)
98