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

HOW INFORMATION SYSTEMS ARE DEVELOPED CHAPTER 2 HOW INFORMATION SYSTEMS ARE DEVELOPED

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

Information System Development in Theory Ideally, an information system is developed as described in Chapter 1 Linear Starting from scratch

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

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

Evolution Tree Model Winburg Mini Case Study

Waterfall Model The linear life cycle model with feedback loops The waterfall model cannot show the order of events

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

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

Relative Cost to Detect and Correct a Fault

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

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

Teal Tractors Mini Case Study (contd) These changes may be Great for the company; but Disastrous for the information system

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

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

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

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

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

Iteration and Incrementation (a) Iteration and (b) incrementation

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

Iteration and Incrementation (contd)

Iterative and Incremental Life-Cycle Model Sample life cycle of an information system

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

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

Iteration and Incrementation (contd) Iteration is performed during each incrementation

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)

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

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

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

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

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

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

The Winburg Mini Case Study Revisited

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

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

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)

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

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

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

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

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

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

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

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

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

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

In the Rest of This Book Development is the process of creating information system artifacts Maintenance refers to modifying those artifacts