Slide 2.

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 2 Slide 2.2

HOW INFORMATION
SYSTEMS ARE DEVELOPED

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

 Chapter Overview Slide 2.3

● 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.
 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 Slide 2.6

● Episode 1: The first version is implemented

● Episode 2: A mistake is found

– 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 Slide 2.7

● Winburg Mini Case Study

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

 Waterfall Model Slide 2.8

● 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.

 Return to the Evolution Tree Model Slide 2.9

● 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.

 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 Slide 2.13

● While the Teal Tractors information system is

being constructed, the requirements change

● The company is expanding into Canada

● Changes needed include:

– 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) Slide 2.14

● 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.

 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 Slide 2.20

● (a) Iteration and (b) incrementation

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
 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) Slide 2.22

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

 Iterative and Incremental Life-Cycle Model Slide 2.23

● Sample life cycle of an information system

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
 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 = 1065.6095067231

● Fourth iteration: newValue = 839.8220030538
● Fifth iteration: newValue = 809.4703353028
● Sixth iteration: newValue = 808.9013065842
● Seventh iteration: newValue = 808.9011064401
● Eighth iteration: newValue = 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 Slide 2.35

● 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.

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 Slide 2.42

● 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.

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.