Slide 14.1
An Introduction to
Object-Oriented
Systems Analysis and Design
with UML and
the Unified Process
McGraw-Hill, 2004
Stephen R. Schach
srs@vuse.vanderbilt.edu
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CHAPTER 14
MANAGEMENT ISSUES
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.2
Chapter Overview










Cost–Benefit Analysis
Risk Analysis
Improving the Process
Metrics
CPM/PERT
Choice of Programming Language
Reuse
Reuse Case Studies
Portability
Why Portability?
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.3
Cost–Benefit Analysis
Slide 14.4

An information system will be constructed only if it is
cost-effective to do so

A popular technique for determining this
– Compare estimated future benefits against projected
future costs
– This is termed cost–benefit analysis
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Cost–Benefit Analysis (contd)

Slide 14.5
Tangible benefits are easy to measure, but
– Intangible benefits can be hard to quantify directly

A way of assigning a dollar value to intangible
benefits is to make assumptions
– In the absence of data, this is the best that can be done
– Better assumptions mean better data and more accurate
calculation of intangible benefits

The same technique can be used for intangible
costs
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Cost–Benefit Analysis (contd)

Slide 14.6
Cost–benefit analysis is a fundamental technique for
deciding
– Whether a client should computerize his or her business
and, if so
– In what way

For each strategy, costs and benefits are computed
– Select the strategy for which the difference between
benefits and costs is the largest
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis

Slide 14.7
A risk is an event or condition that can cause the
delivery of an information system to be
–
–
–
–
Canceled
Delayed
Over budget, or
Not to meet its requirements
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis (contd)

Slide 14.8
Risks include:
– The project may not meet its time constraints
– The moving target problem can result in time and cost
overruns
– The delivered information system may not meet the
client’s real needs
– The developers may not have the needed expertise
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis (contd)
Slide 14.9
– The hardware may not be delivered in time
– The CASE tools may not be available, or may not have all
the needed functionality
– A COTS package with the same functionality may be put
on the market while the project is underway
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis (contd)

The first step
– List the risks in a project

Risk management is the process of
– Determining what the risks are, and then
– Attempting to mitigate them
» Minimize their impact
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.10
Risk Analysis (contd)

Slide 14.11
Example 1:
– To mitigate the risk that part of a proposed information
system will not work
» Build a proof-of-concept prototype

Example 2:
– To mitigate the risk that the development team will not
have the necessary skills
» Provide training
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis (contd)

Risks are like diseases
–
–
–
–
Sometimes they go away spontaneously
They often get better or worse without intervention
Minor ones merely need to be watched, but
Major ones need to be cured (mitigated)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.12
Risk Analysis (contd)
Slide 14.13

A risk list must therefore be maintained

For each item on the list, the following items are
recorded:
– A description of the risk
– The priority of the risk (critical, significant, or routine)
» The priority can change, in either direction
– The way the project is impacted by the risk
– The name of the person responsible for monitoring the risk
– The action to be taken if the risk materializes
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis (contd)

Risk analysis is integral to the Unified Process

During the inception phase
Slide 14.14
– The risk list is drawn up
– Attempts are made to mitigate the critical risks
– The use cases are prioritized according to their risks


During the elaboration phase
– The risks are monitored
– The risk list is updated
» Particularly with regard to priorities
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Risk Analysis (contd)

Slide 14.15
During the construction phase
– The risk list is again updated

During the transition phase
– Attempts are made to find any previously unidentified risks

Risk analysis does not terminate when the product
is delivered to the client
– The risk list must be maintained through the entire life
cycle of the product
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Improving the Process

Slide 14.16
The global economy is critically dependent on
computers
– And hence on information systems

Many governments are concerned about the
information system development process
– This includes the activities, techniques, and tools used to
produce information systems
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Improving the Process (contd)
Slide 14.17

The Department of Defense founded the Software
Engineering Institute at Carnegie Mellon University
in Pittsburgh

A major success of the Software Engineering
Institute is the Capability Maturity Model (CMM)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models

Slide 14.18
The capability maturity models of the Software
Engineering Institute
– A related group of strategies for improving the process for
developing information systems
» (Maturity is a measure of the goodness of the process itself)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Slide 14.19
The Software Engineering Institute has developed
CMMs for
– Software (SW–CMM)
– Management of human resources (P–CMM; the P is for
“people”)
– For systems engineering (SE–CMM)
– For integrated product development (IPD–CMM), and
– For software acquisition (SA–CMM)

In 1997 it was decided to develop a single integrated
framework for maturity models
– Capability maturity model integration (CMMI)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Slide 14.20
SW–CMM is presented here
– SW–CMM incorporates technical and managerial aspects
of the development of an information system

Underlying principle:
– The use of new techniques cannot result in increased
productivity and profitability
– Problems are caused by the way the process is managed
– Improving the management of the process will result in
» Improvements in technique
» Better-quality information systems, and
» Fewer projects with time and cost overruns
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Slide 14.21
Improvements in the process cannot occur overnight
– The SW–CMM induces change incrementally

Five different levels of maturity are defined
– An organization advances slowly toward the higher levels
of process maturity
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)
Slide 14.22

Maturity Level 1: Initial Level

No information system management practices are in
place
–
–
–
–

Instead, everything is done ad hoc
Most activities are responses to crises
The process is unpredictable
It is impossible to make accurate time and cost estimates
Most development organizations worldwide are still
at level 1
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Maturity Level 2: Repeatable Level

Basic information system project management
practices are in place
Slide 14.23
– Planning and management techniques are based on
experience
» Hence the name “repeatable”
– Measurements are taken
» The essential first step in achieving an adequate process
– 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 schedules for future projects
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)
Slide 14.24

Maturity Level 3: Defined Level

The process for information system development is
fully documented
– Managerial and technical aspects of the process are
clearly defined
» Continual efforts are made to improve the process

At this level, it makes sense to introduce new
technology such as CASE
– In contrast, “high tech” only makes the crisis-driven level 1
process even more chaotic
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

A number of organizations have attained maturity
levels 2 and 3
– Not many have reached levels 4 or 5

Slide 14.25
For most companies the two highest levels are
targets for the future
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)
Slide 14.26

Maturity Level 4: Managed Level

A level 4 organization sets quality and productivity
goals for each project
– These two quantities are measured continually
– Action is taken if there are deviations from the goals
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Maturity Level 5: Optimizing Level

The goal of a level 5 organization is continuous
process improvement
Slide 14.27
– Statistical quality and process control techniques are used
to guide the organization

The knowledge gained from each project is utilized
in future projects
– The process thus incorporates a positive feedback loop
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

The five maturity levels
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.28
Capability Maturity Models (contd)

Slide 14.29
To improve its process, an organization
– Attempts to understand its current process
– Formulates the intended process
– Determines and ranks in priority actions that will achieve
this process improvement
– Draws up and executes a plan to accomplish this
improvement

This series of steps then is repeated
– The organization successively improves its process
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Slide 14.30
Experience with the capability maturity model
– Advancing a complete maturity level usually takes from 18
months to 3 years
» But moving from level 1 to level 2 can take up to 5 years
» It is difficult to instill a methodical approach in a level 1 organization
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)
Slide 14.31

For each maturity level there are key process areas
that an organization should target to reach the next
maturity level

Example: The key process areas for level 2 include
–
–
–
–
–
Configuration control
Quality assurance
Project planning
Project tracking
Requirements management
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Slide 14.32
These areas cover the basic elements of information
system management:
– Determine the client’s needs (requirements management)
– Draw up a plan (project planning)
– Monitor deviations from that plan (project tracking)
– Control the pieces that make up the information system
(configuration management), and
– Ensure that the information system is fault free (quality
assurance)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)
Slide 14.33

A level 5 organization is far more advanced than a
level 2 organization

Example:
– A level 2 organization is concerned with quality assurance,
that is, with detecting and correcting faults
– The process of a level 5 organization incorporates fault
prevention, that is, ensuring there are no faults in the first
place
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Capability Maturity Models (contd)

Slide 14.34
An original goal of the CMM program was to raise
the quality of defense software
– By awarding contracts to only those defense contractors
who demonstrate a mature process

The U.S. Air Force stipulated conformance to SW–
CMM level 3 by 1998
– The Department of Defense as a whole subsequently
issued a similar directive

Today, the SW–CMM program is being implemented
by development organizations worldwide
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Process Improvement Initiatives

Slide 14.35
The International Organization for Standards (ISO)
– 9000-series standards

Set of five standards for industrial activities
– Standard ISO 9001 for quality systems
– Standard ISO 9000-3, guidelines to apply ISO 9001 to
information systems
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Process Improvement Initiatives

Slide 14.36
There is an overlap between ISO 9000 and CMM,
but they are not identical
– ISO 9000 is not process improvement
– The stress is on documenting the process
» With an emphasis on measurement and metrics
– ISO 9000 is required to do business with the E.U.
– Also by many U.S. businesses, for example, GE
– More and more U.S. businesses are ISO 9000 certified
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Process Improvement Initiatives

Slide 14.37
ISO/IEC 15504 is an international process
improvement initiative, like ISO 9000
– It was formerly known as SPICE
» (Software Process Improvement Capability dEtermination)

An international process improvement initiative
–
–
–
–
Started by the British Ministry of Defence (MOD)
It includes process improvement, software procurement
It extends and improves CMM and ISO 9000
It is a framework, not a method
» CMM and ISO 9000 conform to this framework
– Now it is referred to as ISO/IEC 15504
» Or just 15504 for short
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Costs and Benefits of Process Improvement
Slide 14.38

Implementing information system process
improvement leads to increased profitability

Example 1:
– Hughes Aircraft spent nearly $500,000 between 1987 and
1990 for assessments and improvement programs
– During this 3-year period, Hughes Aircraft moved up from
maturity level 2 to level 3
– Hughes Aircraft estimates its annual savings to be of the
order of $2 million
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Costs and Benefits of Process Improvement
Slide 14.39

These savings have accrued in number of ways,
including
–
–
–
–
Decreased overtime hours
Fewer crises
Improved employee morale
Lower turnover of information technology professionals
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Costs and Benefits of Process Improvement
Slide 14.40

Example 2:
– The Equipment Division at Raytheon moved from level 1
in 1988 to level 3 in 1993
– A twofold increase in productivity resulted, as well as
– A return of $7.70 for every dollar invested in the process
improvement effort

More and more organizations worldwide are
realizing that process improvement is cost effective
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CMM and CASE

Slide 14.41
Many CASE environments automate a manual
process
– If an organization selects a CASE environment that
enforces an inappropriate process
– Use of that CASE environment is counterproductive

It is worse when an organization at CMM level 1 or 2
uses a CASE environment
– Because there is no defined process in place
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CMM and CASE (contd)

Slide 14.42
Every organization should use CASE tools
– And there generally is little harm in using a workbench

However, an environment imposes an automated
process on the organization that uses it

If the organization is at level 3 or higher
– A CASE environment is appropriate to aid information
system production by automating that process

But if the organization is at levels 1 and 2
– No process as such is in place
– Introduction of a CASE environment leads to chaos
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Metrics

Measurements (or metrics) are essential to detect
problems early in the information system process
– Before they get out of hand

Slide 14.43
Metrics serve as an early warning system for
potential problems
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Metrics

A wide variety of metrics can be used, such as
–
–
–
–
–
–
LOC measurements
Mean time between failures
Effort in person-months
Personnel turnover
Cost
Efficiency of fault detection
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.44
Metrics (contd)

Slide 14.45
Gathering metrics data costs money
– Even when data gathering is automated, the CASE tool
that accumulates the information is not free
– Interpreting the output from the tool consumes human
resources

Numerous different metrics have been put forward
– Which metrics should an information system organization
measure?
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Metrics (contd)

There are five essential, fundamental metrics:
–
–
–
–
–

Size (in lines of code, or better)
Cost (in dollars)
Duration (in months)
Effort (in person-months), and
Quality (number of faults detected)
Each metric must be measured by phase or
workflow
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.46
Metrics (contd)

Slide 14.47
Data from these fundamental metrics can highlight
problems such as
– High fault rates during the design workflow
– Code output that is well below the industry average

A strategy to correct these problems is then put into
place

To monitor the success of this strategy, more
detailed metrics can be introduced
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT
Slide 14.48

More general types of management information are
also needed

Example:
– Critical path management (CPM), otherwise known as
– Program evaluation review techniques (PERT)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

When developing an information system
– Many hundreds of activities have to be performed
– Some activities have to precede others
– Other activities can be carried on in parallel
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.49
CPM/PERT (contd)

Slide 14.50
Example:
– Two activities are started at the same time
– They can be performed in parallel
– Both have to be completed before proceeding with the
project as a whole
– The first takes 12 days, but the second needs only 3 days
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Slide 14.51
The first activity is critical
– Any delay in the first activity will cause the project as a
whole to be delayed

However, the second activity can be delayed up to 9
days without adversely impacting the project
– There is a slack of 9 days associated with the second
activity
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

When using PERT/CPM, the manager inputs
– The activities
– Their estimated durations
– Any precedence relations
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.52
CPM/PERT (contd)

Slide 14.53
The PERT/CPM package will then
– Determine which of the hundreds of activities are critical
– Compute the slack for each of the noncritical activities
– Print out a PERT chart showing the precedence
relationships, and
– Highlight the critical path
» The path through the chart that consists of critical activities only
» If any activity on the critical path is delayed, then so is the project
as a whole
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Simple PERT chart
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.54
CPM/PERT (contd)

Slide 14.55
There are 12 activities and 9 milestones
– A milestone is an event used to measure progress, such
as the completion of an activity or set of activities

Starting with milestone A, activities AB, AC, and AD
can be started in parallel

Activity FJ cannot start until both BF and CF are
finished
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)
Slide 14.56

The project as a whole is complete when activities
HJ, FJ, and GJ are all complete

Completing the whole project will take at least 25
days
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Slide 14.57
The critical path is ACGJ
– If any one of the critical activities
» AC, CG, or GJ
is delayed in any way, the project as a whole will be
delayed

However, if activity AD is delayed by up to 15 days,
the project as a whole will not be delayed
– There is a slack of 15 days associated with activity AD

Now suppose that activity AD is delayed by 15 days
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Slide 14.58
The situation at day 17
– Actual durations of completed activities are underlined
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Slide 14.59
There are now two critical paths
– Activity DG has become critical

Simply printing out a PERT chart showing the
expected durations is useless
– Data regarding actual durations must be input continually
– The PERT chart must be updated
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Slide 14.60
How is the PERT data continually updated?
– The task is too large for humans—a CASE tool is needed
– All the information system development tools must
integrated
– Information of all kinds, including
»
»
»
»
»
Source code
Designs
Documentation
Contracts, and
Management information
must be stored in a system development database
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CPM/PERT (contd)

Slide 14.61
The CASE tool that generates the PERT chart then
obtains its information directly from the database
– Thus, what is needed is a CASE environment
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language

Slide 14.62
In what language should the information system be
implemented?
– This is usually specified in the contract

But what if the contract specifies
– The product is to be implemented in the “most suitable”
programming language

What language should be chosen?
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.63

Example
– QQQ Corporation has been writing COBOL programs for
over 25 years
– Over 200 software staff members, all with COBOL
expertise
– What is “the most suitable” programming language?

Obviously COBOL
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.64

What happens when new language (Java, say) is
introduced
–
–
–
–
–
–

New hires are needed
Existing professionals must be retrained
Future products are written in Java
However, existing COBOL products must be maintained
Expensive software is needed, and the hardware to run it
100s of person-years of expertise with COBOL are wasted
There are now two classes of programmers
– COBOL maintainers (despised)
– Java developers (paid more)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.65

The solution:
– OO-COBOL
» Object-oriented COBOL—2002

QQQ Corporation train their technical staff in
– The object-oriented paradigm in general, and
– OO-COBOL in particular

QQQ Corporation can then
– Develop new information systems in OO-COBOL, and
– Maintain existing information systems in traditional
COBOL
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.66

Where there is no clear reason for choosing one
programming language over another
– Use cost–benefit analysis
» Management must compute costs and benefits of each language
under consideration
» The language with the largest expected gain is chosen
– Alternatively, risk analysis can be used
» For each language, a list is made of the potential risks and ways of
mitigating them
» The language with the smallest overall risk is selected
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.67

Which is the appropriate object-oriented language
today?
– Twenty years ago, there was only one choice—Smalltalk
– Today the most widely used object-oriented language is
C++
– Java is in second place
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.68

C++ is popular because of its similarity to C
– C++ is a superset of C
– C++ is therefore a hybrid object-oriented language
– Managers therefore often assume that a C programmer can
quickly pick up the rest

Conceptually C++ is quite different from C
– C is for the traditional paradigm
– C++ is for the object-oriented paradigm

Before an organization adopts C+
– Training in the object-oriented paradigm must be given
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.69

Java is a pure object-oriented programming
language

Education and training are even more important with
Java than a hybrid object-oriented language
– Like C++ or OO-COBOL
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Choice of Programming Language (contd)
Slide 14.70

What of the future?

Existing information systems
– COBOL will remain the most widely used language

New information systems
– Will be written in object-oriented languages like
» C++
» Java
» C#
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Reuse

Slide 14.71
Instead of utilizing previously developed programs,
organizations all over the world develop their own
programs from scratch
– Why do information technology professionals continually
reinvent the wheel?
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Reuse Concepts

Slide 14.72
Reuse
– Using artifacts of one information system when developing
a different information system with different functionality

Reusable artifacts include
–
–
–
–
–
–
Modules
Code fragments
Design artifacts
Part of manuals
Sets of test data
Duration and cost estimates
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Reuse Concepts

Two types of reuse
– Accidental reuse (or opportunistic reuse)
» First, the information system is built
» Then, artifacts are put into the artifact database for reuse
– Planned reuse
» First, reusable artifacts are constructed
» Then, information systems are built using these artifacts
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.73
Reuse Concepts (contd)

Slide 14.74
A strength of deliberate reuse
– A artifacts specially constructed for reuse are likely to be
»
»
»
»
»

Easy and safe to reuse
Robust
Well documented
Thoroughly tested
Uniform in style
A weakness of deliberate reuse
– There can be no guarantee that such an artifact will ever
be reused
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Reuse Concepts (contd)

Slide 14.75
Reasons for reuse
– It is expensive to design, implement, test, and document
software
– On average, only 15% of new code serves an original
purpose
– Reuse of parts saves
»
»
»
»

Design costs
Implementation costs
Testing costs
Documentation costs
So why do so few organizations employ reuse?
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Impediments to Reuse

There are a number of obstacles to reuse:
–
–
–
–

Slide 14.76
The not invented here (NIH) syndrome
Concerns about faults in potentially reusable routines
The storage–retrieval problem
Costs of reuse
All these can be solved
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Impediments to Reuse

Slide 14.77
Legal issues can arise with a contract information
system
– The information system usually belongs to the client
– Reuse of an artifact for another client constitutes theft of
intellectual property
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Reuse Case Studies

Slide 14.78
Six case studies show that reuse is practical
– They span the 25-year period from 1976 to 2000

What reuse rates can be expected?
– The theoretical maximum is 85%
– The case studies show what can be achieved in practice
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Raytheon Missile Systems Division

Over 5,000 COBOL information systems were
analyzed

Planned reuse of
Slide 14.79
– Design artifacts
» 6 code templates (sort data, edit or manipulate data, combine data,
explode data, update data, report on data)
– COBOL code
» 3200 code artifacts

Reuse rate 60% (1976–1982)
– Productivity increase of 50%
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Toshiba Fuchu Works, Tokyo

Industrial process control systems

Accidental reuse of
–
–
–
–
–
–

Specifications
Designs
Modules
Contracts
Manuals
Standards
Reuse rate (1985)
– 33% design
– 48% code
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.80
NASA Software
Slide 14.81

Ground support system for unmanned spacecraft
control

Management permitted (but did not encourage)
accidental reuse

Accidental reuse of code modules

Reuse rate (1982)
– 28% reused unchanged
– 10% reused with minor changes
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
GTE Data Services
Slide 14.82

Data-processing software

Reuse was strongly encouraged by management
– Cash incentives when module was accepted for reuse
– Cash incentive when module was reused

Accidental reuse of modules

Reuse rate
– (1988) 15% reused code, $1.5 million saved
– (est. 1989) 20% reused code
– (est. 1993) 50% reused code
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Hewlett-Packard
Slide 14.83

Reuse has been implemented in many divisions of
the company

Software Technology Division
–
–
–
–
–
–
Resource planning software
Accidental reuse of code modules
4.1 faults per KLOC of new code, 0.9 for reused code
Overall fault rate decreased by 51%
Productivity increased by 57%
Cost $1 million, savings $4.1 million (1983–92)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Hewlett-Packard (contd)

Slide 14.84
San Diego Technical Graphics (STG)
– Planned reuse of firmware for printers
– The program cost $2.6 million, the savings were $5.6
million (1987–94)
– 24% reduction in faults
– 40% increase in productivity
– 24% decrease in delivery time
– Cost of developing reusable software—11% more
– Cost of reusing it—19% of developing it from scratch
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Hewlett-Packard (contd)

Slide 14.85
Hewlett-Packard makes a wide variety of printers
– They try to have common software in all printer models

Between 1995 and 1998, for a new printer model
– The effort to develop the code decreased by a factor of 4
– The time to develop the code decreased by a factor of 3

Over 70 percent of the components of the code are
reused, almost unchanged, from earlier products
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
European Space Agency

Slide 14.86
On June 4, 1996
– The Ariane 5 rocket blew up 37 seconds after lift-off

Cost: $500 million

Reason:
– A computer tried to convert a number from one format into
another
– The number being converted was too large for this
conversion to be possible

The on-board computers crashed, so did the rocket
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
European Space Agency (contd)

Slide 14.87
The conversion was unnecessary
– Computations on the inertial reference system can stop 9
seconds before lift-off
– But, if there is a subsequent hold in the countdown, it
takes several hours to reset the inertial reference system
– Computations therefore continue 50 seconds into the flight
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
European Space Agency (contd)

Slide 14.88
The cause of the problem
– Ten years before, it was mathematically proved that the
problem could not occur—on the Ariane 4
– The software was used, unchanged and untested, on
the Ariane 5
– However, the assumptions for the Ariane 4 did not hold
for the Ariane 5

Lesson
– Artifacts developed in one context needs to be retested
when integrated into a different context
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Size of Reused Components

Slide 14.89
NASA
– Most reused components were small

Toshiba
– Many large components were reused

GTE
– Many large components were reused

Reason
– A strong managerial commitment to reuse is needed
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Portability

Slide 14.90
Every information system must be portable
– That is, easily adapted to run on different hardware–
operating system combinations

Hardware is replaced every 4 years or so

There are several obstacles to portability
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Hardware Incompatibilities

Sources of incompatibilities include
– Diskette formats (PC vs. Macintosh)
– Character codes (EBCDIC vs. ASCII)
– Tape drives (different parities)

There is an economic reason for perpetuating
incompatibilities
– To force a customer to buy an expensive compatible
computer
» To avoid an even more expensive conversion to a cheaper
incompatible computer
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 14.91
Operating System Incompatibilities

Slide 14.92
An information system that runs under Windows will
not run under
– Linux
– Mac OS, or
– OS/370

Problems can arise even when upgrading the same
operating system
– Example: Windows
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Compiler Incompatibilities

Information systems should be implemented in a
widely used language such as
–
–
–
–

Slide 14.93
COBOL
C
C++, or
Java
Using only standard features of that language
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Why Portability?
Slide 14.94

Good information systems have a life of 15 or 20
years or more

Hardware usually is changed every 4 years

Solution 1:
– Buy upwardly compatible hardware and operating systems
– This may be expensive

Solution 2:
– Ensure that software is truly portable
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Why Portability? (contd)

Slide 14.95
Portability should be strongly encouraged by all
information technology managers, and
– Especially by top management
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.