Slide 2.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach

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 l Information System Development in Theory l Winburg Mini Case Study l Lessons of the Winburg Mini Case Study l Teal Tractors Mini Case Study l Iteration and Incrementation l Iteration: The Newton–Raphson Algorithm l The Winburg Mini Case Study Revisited l Other Aspects of Iteration and Incrementation l Managing Iteration and Incrementation l Maintenance Revisited

Slide 2.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Information System Development in Theory l 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 l 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 l Episode 1: The first version is implemented l Episode 2: A mistake is found –The system is too slow because of an implementation fault –Changes to the implementation are begun l Episode 3: The requirements change –A faster algorithm is used l Episode 4: A new design is adopted –Development is complete l 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 l Winburg Mini Case Study

Slide 2.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Waterfall Model l The linear life cycle model with feedback loops l 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 l The explicit order of events is shown l At the end of each episode –We have a baseline, a complete set of artifacts (constituent components) l Example: –Baseline at the end of Episode 4: »Requirements 3, Analysis 3, Design 4, Implementation 4

Slide 2.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Lessons of the Winburg Mini Case Study l In the real world, information system development is more chaotic than the Winburg mini case study l 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 l 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) l If a fault is not detected and corrected, it will be carried over into the next phase l Correcting the fault means –Fixing the fault itself; and –Fixing the effects of the fault in subsequent phases l Between 60 percent and 70 percent of all detected faults are requirements, analysis, and design faults l 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 l While the Teal Tractors information system is being constructed, the requirements change l The company is expanding into Canada l 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) l 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 l A change in the information system while it is being developed l 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) l Any change made to an information system can potentially cause a regression fault –A fault in an apparently unrelated part of the system l 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) l 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 l 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 l The basic information system development process is iterative –To iterate means to repeat l 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 l At any one time, we can concentrate on only approximately seven chunks (units of information) l 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 l 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 l (a) Iteration and (b) incrementation

Slide 2.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Iteration and Incrementation (contd) l Iteration and incrementation are used in conjunction with one another l There is no single “requirements phase” or “design phase” l 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 l 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 l Sequential phases do not exist in the real world l 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 l All five core workflows are performed over the entire life cycle l However, at most times one workflow predominates l 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) l Iteration is performed during each incrementation

Slide 2.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Iteration Example l We use the Newton–Raphson algorithm (1690) to compute the square root of a number N using iteration l Suppose N = l The initial guess is 100 (initial currentValue )

Slide 2.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Iteration Example (contd) l Plug this into the formula to get the first iteration l Now our estimate of is –This becomes our next currentValue l We plug the value for currentValue into the right-hand side of the formula

Slide 2.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Iteration Example (contd) l Our second iteration is then l Our estimate of is now –This becomes our next currentValue l Again we plug this value into the right-hand side of the formula for our third iteration

Slide 2.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Iteration Example (contd) l Continuing yields the following results for newValue : l Third iteration: newValue = l Fourth iteration: newValue = l Fifth iteration: newValue = l Sixth iteration: newValue = l Seventh iteration: newValue = l Eighth iteration: newValue =

Slide 2.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Iteration Example (contd) l 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 l 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 l Not every iteration is successful –When we build information systems, sometimes (say) the eighth iteration of the analysis is worse than the seventh iteration l 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 l 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 l Consider the next slide l It shows the life cycle of one information system (each one is different) l 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 l Each episode corresponds to an increment l Not every increment includes every workflow l Increment B was not completed l 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 l We can consider the project as a whole as a set of mini projects (increments) l Each mini project extends the –Requirements artifacts –Analysis artifact –Design artifacts –Implementation artifacts –Testing artifacts l 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) l 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) l Each iteration can be viewed as a small but complete waterfall life-cycle model l During each iteration we select a portion of the information system l 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) l 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 l 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) l We can mitigate risks early l 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 l The iterative and incremental life-cycle model is as regimented as the waterfall model … l … because the iterative and incremental life-cycle model is the waterfall model, applied successively l Each increment is a waterfall mini project

Slide 2.42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Revisited l Traditional information system construction l Traditional development –All activities before installation on client’s computer l Traditional maintenance –All activities after installation on client’s computer l 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 l A fault is detected and corrected one day after the information system was installed –Traditional maintenance l 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 l An information system has been installed l The client wants its functionality to be increased –Traditional (perfective) maintenance l 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 l 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 l In 1995, the International Standards Organization and International Electrotechnical Commission defined maintenance operationally l 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) l 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 l Development is the process of creating information system artifacts l Maintenance refers to modifying those artifacts