Chap 002

of 48 /48
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 [email protected]

Embed Size (px)

Transcript of Chap 002

Slide 2.1

An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004

Stephen R. [email protected] 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

CHAPTER 2

Slide 2.2

HOW INFORMATION SYSTEMS ARE DEVELOPED

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Chapter Overviewq q q q q q q q q q

Slide 2.3

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 NewtonRaphson Algorithm The Winburg Mini Case Study Revisited Other Aspects of Iteration and Incrementation Managing Iteration and Incrementation Maintenance RevisitedCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Information System Development in Theoryq

Slide 2.4

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

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Information System Development in Practiceq

Slide 2.5

In the real world, information system development is very different We make mistakes The clients requirements change while the information system is being developed

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Winburg Mini Case Studyq

Slide 2.6

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

q

q

Episode 3: The requirements change A faster algorithm is used

q

Episode 4: A new design is adopted Development is complete

q

Epilogue: A few years later, these problems recurCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Evolution Tree Modelq

Slide 2.7

Winburg Mini Case Study

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Waterfall Modelq

Slide 2.8

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

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Return to the Evolution Tree Modelq

Slide 2.9

The explicit order of events is shown At the end of each episode We have a baseline, a complete set of artifacts (constituent components)

q

q

Example: Baseline at the end of Episode 4: Requirements3, Analysis3, Design4, Implementation4

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Lessons of the Winburg Mini Case Studyq

Slide 2.10

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

q

q

Faults must be fixed quicklysee next slide

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Relative Cost to Detect and Correct a Fault

Slide 2.11

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Relative Cost to Detect and Correct a Fault (contd)Slide 2.12

q

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

q

q

Between 60 percent and 70 percent of all detected faults are requirements, analysis, and design faults These faults must be detected and corrected earlyCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

q

Teal Tractors Mini Case Studyq

Slide 2.13

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 CADCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

q

q

Teal Tractors Mini Case Study (contd)q

Slide 2.14

These changes may be Great for the company; but Disastrous for the information system

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Moving Target Problemq

Slide 2.15

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

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Moving Target Problem (contd)q

Slide 2.16

Any change made to an information system can potentially cause a regression fault A fault in an apparently unrelated part of the system

q

If there are too many changes The entire information system may have to be redesigned and reimplemented

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Moving Target Problem (contd)q

Slide 2.17

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

q

There is no solution to the moving target problem

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration and Incrementationq

Slide 2.18

The basic information system development process is iterative To iterate means to repeat

q

Each successive version is intended to be closer to its target than its predecessor

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Millers Lawq

Slide 2.19

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

q

q

This is an incremental process To increment means to increaseCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration and Incrementation

Slide 2.20

q

(a) Iteration and (b) incrementationCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration and Incrementation (contd)q

Slide 2.21

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

q

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration and Incrementation (contd)

Slide 2.22

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iterative and Incremental Life-Cycle Model

Slide 2.23

q

Sample life cycle of an information systemCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Traditional Phases and Workflowsq

Slide 2.24

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

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Workflowsq

Slide 2.25

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

q

q

At the end of the life cycle The implementation and test workflows predominate

Planning and documentation activities are performed throughout the life cycleCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration and Incrementation (contd)q

Slide 2.26

Iteration is performed during each incrementation

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration Exampleq

Slide 2.27

We use the NewtonRaphson algorithm (1690) to compute the square root of a number N using iteration 1 N newValue = currentValue + 2 currentValue

q

Suppose N = 123456 The initial guess is 100 (initial currentValue)

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration Example (contd)q

Slide 2.28

Plug this into the formula to get the first iteration1 654321 newValue = + 100 = 3321.605 2 100

q

Now our estimate of

123456

is 3321.605

This becomes our next currentValueq

We plug the value 3321.605 for currentValue into the right-hand side of the formula

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration Example (contd)q

Slide 2.29

Our second iteration is then1 654321 newValue = 3321.605 + = 1759.2972036147 2 3321.605

q

Our estimate of

123456

is now 1759.2972036147

This becomes our next currentValueq

Again we plug this value into the right-hand side of the formula for our third iteration

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration Example (contd)q

Slide 2.30

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 = 1065.6095067231 839.8220030538 809.4703353028 808.9013065842 808.9011064401 808.9011064401

q q q q q q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iteration Example (contd)q

Slide 2.31

The seventh iteration and eighth iterations are the same (to 10 decimal places) The NewtonRaphson iteration has converged to the desired degree of precision

q

This iteration works well: The NewtonRaphson square root iteration always works, for every positive starting value

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Iterationq

Slide 2.32

Not every iteration is successful When we build information systems, sometimes (say) the eighth iteration of the analysis is worse than the seventh iteration

q

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

q

Key point: We do not need to start again from the beginningCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

More on Incrementationq

Slide 2.33

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

q

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

The Winburg Mini Case Study Revisited

Slide 2.34

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

More on Incrementation (contq

Slide 2.35

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

q

q

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Other Aspects of Iteration and Incrementationq

Slide 2.36

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

q

q

The final set of artifacts is the complete information system

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Other Aspects of Iteration and Increm. (contd)q

Slide 2.37

During each mini project we Extend the artifacts (incrementation); Check the artifacts (test workflow); and If necessary, change the relevant artifacts (iteration)

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Other Aspects of Iteration and Increm. (contd)q

Slide 2.38

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 phaseCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

q

q

Advantages of the Iter. and Increm. Model (contd)Slide 2.39

q

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

q

The robustness of the architecture can be determined early in the life cycle Architecturethe various component modules and how they fit together Robustnessthe property of being able to handle extensions and changes without falling apartCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Advantages of the Iter. and Increm. Model (contd)Slide 2.40

q

We can mitigate risks early We have a working version of the information system from the start

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Managing Iteration and Incrementationq

Slide 2.41

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

q

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Maintenance Revisitedq

Slide 2.42

Traditional information system construction Traditional development All activities before installation on clients computer

q

q

Traditional maintenance All activities after installation on clients computer

q

These definitions can lead to unexpected consequencesCopyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Traditional Maintenance DefnConsequence 1Slide 2.43

q

A fault is detected and corrected one day after the information system was installed Traditional maintenance

q

The identical fault is detected and corrected one day before installation Traditional development

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Traditional Maintenance DefnConsequence 2Slide 2.44

q

An information system has been installed The client wants its functionality to be increased Traditional (perfective) maintenance

q

q

The client wants the identical change to be made just before installation (moving target problem) Traditional development

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Traditional Maintenance Definitionq

Slide 2.45

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

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Modern Maintenance Definitionq

Slide 2.46

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

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Modern Maintenance Definition (contd)q

Slide 2.47

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

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

In the Rest of This Bookq

Slide 2.48

Development is the process of creating information system artifacts Maintenance refers to modifying those artifacts

q

Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.