1. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, Stephen R. Schach

2. HOW INFORMATION SYSTEMS ARE DEVELOPED
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 =
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
This becomes our next currentValue
We plug the value for currentValue into the right-hand side of the formula

29. Iteration Example (contd)
Our second iteration is then
Our estimate of is now
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 =
Fourth iteration: newValue =
Fifth iteration: newValue =
Sixth iteration: newValue =
Seventh iteration: newValue =
Eighth iteration: newValue =

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