You are on page 1of 48

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.

You might also like