Post on 15-Aug-2014
Slide 2.1
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
An Introduction toObject-Oriented
Systems Analysis and Design with UML and
the Unified Process
McGraw-Hill, 2004
Stephen R. Schachsrs@vuse.vanderbilt.edu
Slide 2.2
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
CHAPTER 2
HOW INFORMATION SYSTEMS ARE DEVELOPED
Slide 2.3
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
Slide 2.4
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Information System Development in Theory
Ideally, an information system is developed as described in Chapter 1
– Linear– Starting from scratch
Slide 2.5
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Information System Development in Practice
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
Slide 2.6
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– 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
Slide 2.7
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Evolution Tree Model
Winburg Mini Case Study
Slide 2.8
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Waterfall Model
The linear life cycle model with feedback loops
The waterfall model cannot show the order of events
Slide 2.9
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
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
Slide 2.10
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Lessons of the Winburg Mini Case Study
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
Slide 2.11
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Relative Cost to Detect and Correct a Fault
Slide 2.12
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Relative Cost to Detect and Correct a Fault (contd)
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
Slide 2.13
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:– 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
Slide 2.14
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
Slide 2.15
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Moving Target Problem
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
Slide 2.16
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Moving Target Problem (contd)
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
Slide 2.17
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Moving Target Problem (contd)
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
Slide 2.18
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation
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
Slide 2.19
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Miller’s Law
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
Slide 2.20
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation
(a) Iteration and (b) incrementation
Slide 2.21
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation (contd)
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
Slide 2.22
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation (contd)
Slide 2.23
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iterative and Incremental Life-Cycle Model
Sample life cycle of an information system
Slide 2.24
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Traditional Phases and Workflows
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
Slide 2.25
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Workflows
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
Slide 2.26
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration and Incrementation (contd)
Iteration is performed during each incrementation
Slide 2.27
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example
We use the Newton–Raphson algorithm (1690) to compute the square root of a number N using iteration
Suppose N = 123456
The initial guess is 100 (initial currentValue)
newValue 12
currentValue N
currentValue
Slide 2.28
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)
Plug this into the formula to get the first iteration
Now our estimate of is 3321.605– This becomes our next currentValue
We plug the value 3321.605 for currentValue into the right-hand side of the formula
newValue 12
100654321
100
3321.605
123456
Slide 2.29
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)
Our second iteration is then
Our estimate of 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
newValue 12
3321.605654321
3321.605
1759.2972036147
123456
Slide 2.30
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)
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
Slide 2.31
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration Example (contd)
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
Slide 2.32
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Iteration
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
Slide 2.33
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
More on Incrementation
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
Slide 2.34
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
The Winburg Mini Case Study Revisited
Slide 2.35
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
Slide 2.36
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Aspects of Iteration and Incrementation
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
Slide 2.37
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Aspects of Iteration and Increm. (contd)
During each mini project we – Extend the artifacts (incrementation); – Check the artifacts (test workflow); and– If necessary, change the relevant artifacts (iteration)
Slide 2.38
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Other Aspects of Iteration and Increm. (contd)
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
Slide 2.39
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Advantages of the Iter. and Increm. Model (contd)
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
Slide 2.40
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Advantages of the Iter. and Increm. Model (contd)
We can mitigate risks early
We have a working version of the information system from the start
Slide 2.41
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Managing Iteration and Incrementation
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
Slide 2.42
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
Slide 2.43
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Traditional Maintenance Defn—Consequence 1
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
Slide 2.44
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Traditional Maintenance Defn—Consequence 2
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
Slide 2.45
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Traditional Maintenance Definition
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
Slide 2.46
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modern Maintenance Definition
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
Slide 2.47
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
Modern Maintenance Definition (contd)
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
Slide 2.48
Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.
In the Rest of This Book
Development is the process of creating information system artifacts
Maintenance refers to modifying those artifacts