Slide 2.1
An Introduction to
Object-Oriented
Systems Analysis and Design
with UML and
the Unified Process
McGraw-Hill, 2004
Stephen R. Schach
[email protected]
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CHAPTER 2
Slide 2.2
HOW INFORMATION
SYSTEMS ARE DEVELOPED
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Chapter Overview










Information System Development in Theory
Winburg Mini Case Study
Lessons of the Winburg Mini Case Study
Teal Tractors Mini Case Study
Iteration and Incrementation
Iteration: The Newton–Raphson Algorithm
The Winburg Mini Case Study Revisited
Other Aspects of Iteration and Incrementation
Managing Iteration and Incrementation
Maintenance Revisited
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.3
Information System Development in Theory
Slide 2.4

Ideally, an information system
is developed as described in
Chapter 1
–
–
Linear
Starting from scratch
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Information System Development in Practice
Slide 2.5

In the real world, information system development
is very different
– We make mistakes
– The client’s requirements change while the information
system is being developed
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Winburg Mini Case Study

Episode 1: The first version is implemented

Episode 2: A mistake is found
Slide 2.6
– The system is too slow because of an implementation fault
– Changes to the implementation are begun

Episode 3: The requirements change
– A faster algorithm is used

Episode 4: A new design is adopted
– Development is complete

Epilogue: A few years later, these problems recur
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Evolution Tree Model

Winburg Mini Case Study
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.7
Waterfall Model

The linear life cycle model
with feedback loops

The waterfall model cannot
show the order of events
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.8
Return to the Evolution Tree Model

The explicit order of events is shown

At the end of each episode
– We have a baseline, a complete set of artifacts
(constituent components)

Example:
– Baseline at the end of Episode 4:
» Requirements3, Analysis3, Design4, Implementation4
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.9
Lessons of the Winburg Mini Case Study
Slide 2.10

In the real world, information system development
is more chaotic than the Winburg mini case study

Changes are always needed
– An information system is a model of the real world,
which is continually changing
– Information technology professionals are human, so we
make mistakes

Faults must be fixed quickly—see next slide
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Relative Cost to Detect and Correct a Fault
Slide 2.11
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Relative Cost to Detect and Correct a Fault (contd)
Slide 2.12

If a fault is not detected and corrected, it will be
carried over into the next phase

Correcting the fault means
– Fixing the fault itself; and
– Fixing the effects of the fault in subsequent phases

Between 60 percent and 70 percent of all detected
faults are requirements, analysis, and design faults

These faults must be detected and corrected early
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Teal Tractors Mini Case Study

While the Teal Tractors information system is
being constructed, the requirements change

The company is expanding into Canada

Changes needed include:
Slide 2.13
– Additional sales regions must be added
– The system must be able to handle Canadian taxes and
other business aspects that are handled differently
– Third, the system must be extended to handle two
different currencies, USD and CAD
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Teal Tractors Mini Case Study (contd)

These changes may be
– Great for the company; but
– Disastrous for the information system
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.14
Moving Target Problem
Slide 2.15

A change in the information system while it is
being developed

Even if the reasons for the change are good, the
information system can be adversely impacted
– Dependencies will be induced
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Moving Target Problem (contd)

Slide 2.16
Any change made to an information system can
potentially cause a regression fault
– A fault in an apparently unrelated part of the system

If there are too many changes
– The entire information system may have to be
redesigned and reimplemented
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Moving Target Problem (contd)

Slide 2.17
Change is inevitable
– Growing companies are always going to change
– If the individual calling for changes has sufficient clout,
nothing can be done about it

There is no solution to the moving target problem
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation

Slide 2.18
The basic information system development
process is iterative
– To iterate means to repeat

Each successive version is intended to be closer
to its target than its predecessor
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Miller’s Law
Slide 2.19

At any one time, we can concentrate on only
approximately seven chunks (units of information)

To handle larger amounts of information, use
stepwise refinement
– Concentrate on the aspects that are currently the most
important
– Postpone aspects that are currently less critical
– Every aspect is eventually handled, but in order of
current importance

This is an incremental process
– To “increment” means to increase
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation

(a) Iteration and (b) incrementation
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.20
Iteration and Incrementation (contd)
Slide 2.21

Iteration and incrementation are used in
conjunction with one another

There is no single “requirements phase” or “design
phase”

Instead, there are multiple instances of each phase
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation (contd)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.22
Iterative and Incremental Life-Cycle Model

Sample life cycle of an information system
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.23
Traditional Phases and Workflows
Slide 2.24

Sequential phases do not exist in the real world

Instead, the five core workflows (activities) are
performed over the entire life cycle
–
–
–
–
–
Requirements workflow
Analysis workflow
Design workflow
Implementation workflow
Test workflow
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Workflows
Slide 2.25

All five core workflows are performed over the entire
life cycle

However, at most times one workflow predominates

Examples:
– At the beginning of the life cycle
» The requirements workflow predominates
– At the end of the life cycle
» The implementation and test workflows predominate
– Planning and documentation activities are performed
throughout the life cycle
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation (contd)

Slide 2.26
Iteration is performed during each incrementation
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example

Slide 2.27
We use the Newton–Raphson algorithm (1690) to
compute the square root of a number N using
iteration

1 
N
newValue  currentValue 


2
currentValue 


Suppose
N = 123456

The initial guess is 100 (initial currentValue)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)

Slide 2.28
Plug this into the formula to get the first iteration
1 
654321
newValue  100 
 3321.605

2
100 

Nowour estimate of
123456
is 3321.605
– This becomes our next currentValue


We plug the value 3321.605 for currentValue into the
right-hand side of the formula
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)

Slide 2.29
Our second iteration is then
1 
654321 
newValue  3321.605 
1759.2972036147
2 
3321.605


Our estimate of
123456
is now 1759.2972036147
– This becomes our next currentValue


Again we plug this value into the right-hand side of
the formula for our third iteration
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)
Slide 2.30

Continuing yields the following results for newValue:

Third iteration: newValue =
Fourth iteration: newValue =
Fifth iteration:
newValue =
Sixth iteration:
newValue =
Seventh iteration: newValue =
Eighth iteration: newValue =





1065.6095067231
839.8220030538
809.4703353028
808.9013065842
808.9011064401
808.9011064401
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)

Slide 2.31
The seventh iteration and eighth iterations are the
same (to 10 decimal places)
– The Newton–Raphson iteration has converged to the
desired degree of precision

This iteration works well:
– The Newton–Raphson square root iteration always
works, for every positive starting value
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration

Slide 2.32
Not every iteration is successful
– When we build information systems, sometimes (say) the
eighth iteration of the analysis is worse than the seventh
iteration

If the eighth iteration is worse than the seventh
–
–
–
–

Discard the eighth iteration
Go back to the seventh iteration
Perform the eighth iteration a different way
Hopefully, this will result in a better eighth iteration
Key point: We do not need to start again from the
beginning
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
More on Incrementation
Slide 2.33

Consider the next slide

It shows the life cycle of one information system
(each one is different)

The evolution tree model has been superimposed
on the iterative and incremental life-cycle model
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
The Winburg Mini Case Study Revisited
Slide 2.34
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
More on Incrementation (cont

Each episode corresponds to an increment

Not every increment includes every workflow

Increment B was not completed

Dashed lines denote maintenance
– Corrective maintenance, in all three instances
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.35
Other Aspects of Iteration and Incrementation
Slide 2.36

We can consider the project as a whole as a set of
mini projects (increments)

Each mini project extends the
–
–
–
–
–

Requirements artifacts
Analysis artifact
Design artifacts
Implementation artifacts
Testing artifacts
The final set of artifacts is the complete
information system
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Aspects of Iteration and Increm. (contd)
Slide 2.37

During each mini project we
– Extend the artifacts (incrementation);
– Check the artifacts (test workflow); and
– If necessary, change the relevant artifacts (iteration)
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Aspects of Iteration and Increm. (contd)
Slide 2.38

Each iteration can be viewed as a small but
complete waterfall life-cycle model

During each iteration we select a portion of the
information system

On that portion we perform the
–
–
–
–
Traditional requirements phase
Traditional analysis phase
Traditional design phase
Traditional implementation phase
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Advantages of the Iter. and Increm. Model (contd)
Slide 2.39

There are multiple opportunities for checking that
the information system is correct
– Every iteration incorporates the test workflow
– Faults can be detected and corrected early

The robustness of the architecture can be
determined early in the life cycle
– Architecture—the various component modules and how
they fit together
– Robustness—the property of being able to handle
extensions and changes without falling apart
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Advantages of the Iter. and Increm. Model (contd)
Slide 2.40

We can mitigate risks early

We have a working version of the information
system from the start
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Managing Iteration and Incrementation
Slide 2.41

The iterative and incremental life-cycle model is as
regimented as the waterfall model …

… because the iterative and incremental life-cycle
model is the waterfall model, applied successively

Each increment is a waterfall mini project
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Maintenance Revisited

Traditional information system construction

Traditional development
– All activities before installation on client’s computer

Traditional maintenance
– All activities after installation on client’s computer

These definitions can lead to unexpected
consequences
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Slide 2.42
Traditional Maintenance Defn—Consequence 1
Slide 2.43

A fault is detected and corrected one day after the
information system was installed
– Traditional maintenance

The identical fault is detected and corrected one
day before installation
– Traditional development
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Traditional Maintenance Defn—Consequence 2
Slide 2.44

An information system has been installed

The client wants its functionality to be increased
– Traditional (perfective) maintenance

The client wants the identical change to be made
just before installation (“moving target problem”)
– Traditional development
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Traditional Maintenance Definition

Slide 2.45
The reason for these and similar unexpected
consequences
– The traditional definition of maintenance is temporal
– Maintenance is defined in terms of the time at which the
activity is performed
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modern Maintenance Definition
Slide 2.46

In 1995, the International Standards Organization
and International Electrotechnical Commission
defined maintenance operationally

Maintenance is nowadays defined as
– The process that occurs when an information system
artifact is modified because of a problem or because of
a need for improvement or adaptation
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modern Maintenance Definition (contd)

Slide 2.47
In terms of the ISO/IEC definition
– Maintenance occurs whenever an information system is
modified
– Regardless of whether this takes place before or after
installation of the information system
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
In the Rest of This Book
Slide 2.48

Development is the process of creating
information system artifacts

Maintenance refers to modifying those artifacts
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.