CHAPTER 2

1. An Introduction toObject-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 2 HOW INFORMATION SYSTEMS ARE DEVELOPED

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

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

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

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

7. Evolution Tree Model • Winburg Mini Case Study

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

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

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

11. Relative Cost to Detect and Correct a Fault

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

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

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

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

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

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

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

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

20. Iteration and Incrementation • (a) Iteration and (b) incrementation

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

22. Iteration and Incrementation (contd)

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

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

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

26. Iteration and Incrementation (contd) • Iteration is performed during each incrementation

27. 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)

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

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

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

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

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

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

34. The Winburg Mini Case Study Revisited

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

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

37. 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)

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

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

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

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

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

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

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

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

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

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

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