Just in Case You Wanted to Know Box 2.1

Winburg Mini Case Study

To reduce traffi c congestion in downtown Winburg, Indiana, the mayor convinces the city to set up a public transportation system. Bus-only lanes are to be established, and commuters will be encouraged to “park and ride”; that is, to park their cars in suburban parking lots and then take buses from there to work and back at a cost of one dollar per ride. Each bus is to have a fare machine that accepts only dollar bills.

Passengers insert a bill into the slot as they enter the bus. Sensors inside the fare machine scan the bill, and the software in the machine uses an image recognition

C

2.2 2.2

Just in Case You Wanted to Know Box 2.1

The term from scratch, meaning “starting with nothing,” comes from 19th century sports terminology. Before roads (and running tracks) were paved, races had to be held on open ground. In many cases, the starting line was a scratch in the sand. A runner who had no advantage or handicap had to start from that line, that is, “from [the] scratch.”

The term scratch has a different sporting connotation nowadays. A “scratch golfer” is one whose golfi ng handicap is zero.

sch76183_ch02_035-073.indd 38

sch76183_ch02_035-073.indd 38 04/06/10 12:34 PM04/06/10 12:34 PM

algorithm to decide whether the passenger has indeed inserted a valid dollar bill into the slot. It is important that the fare machine be accurate because, once the news gets out that any piece of paper will do the trick, fare income will plummet to effectively zero. Conversely, if the machine regularly rejects valid dollar bills, passengers will be reluctant to use the buses. In addition, the fare machine must be rapid. Passengers will be equally reluctant to use the buses if the machine spends 15 seconds coming to a decision regarding the validity of a dollar bill—it would take even a relatively small number of passengers many minutes to board a bus. Therefore, the requirements for the fare machine software include an average response time of less than 1 second and an average accuracy of at least 98 percent.

Episode 1 The fi rst version of the software is implemented.

Episode 2 Tests show that the required constraint of an average response time of 1 second for deciding on the validity of a dollar bill is not achieved. In fact, on average, it takes 10 seconds to get a response. Senior management discovers the cause. It seems that, to get the required 98 percent accuracy, a programmer has been instructed by her manager to use double-precision numbers for all mathematical cal-culations. As a result, every operation takes at least twice as long as it would with the usual single-precision numbers. The result is that the program is much slower than it should be, resulting in the long response time. Calculations then show that, despite what the manager told the programmer, the stipulated 98 percent accuracy can be at-tained even if single-precision numbers are used. The programmer starts to make the necessary changes to the implementation.

Episode 3 Before the programmer can complete her work, further tests of the sys-tem show that, even if the indicated changes to the implementation were made, the system would still have an average response time of over 4.5 seconds, nowhere near the stipulated 1 second. The problem is the complex image recognition algorithm.

Fortunately, a faster algorithm has just been discovered, so the fare machine software is redesigned and reimplemented using the new algorithm. This results in the average response time being successfully achieved.

Episode 4 By now, the project is considerably behind schedule and way over budget. The mayor, a successful entrepreneur, has the bright idea of asking the software development team to try to increase the accuracy of the dollar bill rec-ognition component of the system as much as possible, to sell the resulting pack-age to vending machine companies. To meet this new requirement, a new design is adopted that improves the average accuracy to over 99.5 percent. Management decides to install that version of the software in the fare machines. At this point, development of the software is complete. The city is later able to sell its system to two small vending machine companies, defraying about one-third of the cost overrun.

Epilogue A few years later, the sensors inside the fare machine become obsolete and need to be replaced by a newer model. Management suggests taking advantage of the change to upgrade the hardware at the same time. The software professionals point out that changing the hardware means that new software also is needed. They suggest reimplementing the software in a different programming language. At the

time of writing, the project is 6 months behind schedule and 25 percent over budget.

However, everyone involved is confi dent that the new system will be more reliable and of higher quality, despite “minor discrepancies” in meeting its response time and accuracy requirements.

Figure 2.2 depicts the evolution-tree life-cycle model of the mini case study.

The leftmost boxes represent Episode 1. As shown in the fi gure, the system was developed from scratch (⭋). The requirements (Requirements 1 ), analysis (Analysis ₁ ), design (Design ₁ ), and implementation (Implementation ₁ ) followed in turn. Next, as previously described, trials of the fi rst version of the software showed that the average response time of 1 second could not be achieved and the implementation had to be modifi ed. The modifi ed implementation appears in Figure 2.2 as Implementation ₂ . However, Implementation ₂ was never completed. That is why the rectangle repre-senting Implementation ₂ is drawn with a dotted line.

In Episode 3, the design had to be changed. Specifi cally, a faster image recogni-tion algorithm was used. The modifi ed design (Design ₃ ) resulted in a modifi ed imple-mentation (Impleimple-mentation ₃ ).

Finally, in Episode 4, the requirements were changed (Requirements ₄ ) to in-crease the accuracy. This resulted in modifi ed specifi cations (Analysis ₄ ), modifi ed design (Design ₄ ), and modifi ed implementation (Implementation ₄ ).

In Figure 2.2 , the solid arrows denote development and the dashed arrows de-note maintenance. For example, when the design is changed in Episode 3, Design ₃ replaced Design ₁ as the design of Analysis ₁ .

The evolution-tree model is an example of a life-cycle model (or model , for short), that is, the series of steps to be performed while the software product is developed and maintained. Another life-cycle model that can be used for the mini FIGURE 2.2 The evolution-tree life-cycle model for the Winburg mini case study. (The rectangle drawn with a dotted line denotes the implementation that was not completed.)

Implementation₂

Design₄

Episode 4 Episode 3

Episode 2 Episode 1

Analysis₄

Design₃

Implementation₃

Requirements₄

Analysis₁

Design₁

Implementation₄ Implementation₁

Requirements₁

Development Maintenance

⭋

40 Part A Software Engineering Concepts

sch76183_ch02_035-073.indd 40

sch76183_ch02_035-073.indd 40 04/06/10 12:34 PM04/06/10 12:34 PM

case study is the waterfall life-cycle model [Royce, 1970]; a simplifi ed version of the waterfall model is depicted in Figure 2.3 . This classical life-cycle model can be viewed as the linear model of Figure 2.1 with feedback loops. Then, if a fault is found during the design that was caused by a fault in the requirements, following the dashed upward arrows, the software developers can backtrack from the design up to the analysis and hence to the requirements and make the necessary corrections there.

Then, they move down to the analysis, correct the specifi cation document to refl ect the corrections to the requirements, and in turn, correct the design document. Design activities can now resume where they were suspended when the fault was discovered.

Again, the solid arrows denote development; the dashed arrows, maintenance.

The waterfall model can certainly be used to represent the Winburg mini case study, but, unlike the evolution-tree model of Figure 2.2 , it cannot show the order of events.

The evolution-tree model has a further advantage over the waterfall model. At the end of each episode we have a baseline , that is, a complete set of artifacts (recall that an

artifact is a constituent component of a software product). There are four baselines in Figure 2.2 . They are

At the end of Episode 1: Requirements ₁ , Analysis ₁ , Design ₁ , Implementation ₁ At the end of Episode 2: Requirements ₁ , Analysis ₁ , Design ₁ , Implementation ₂ At the end of Episode 3: Requirements ₁ , Analysis ₁ , Design ₃ , Implementation ₃ At the end of Episode 4: Requirements ₄ , Analysis ₄ , Design ₄ , Implementation ₄ The fi rst baseline is the initial set of artifacts; the second baseline refl ects the modifi ed (but never completed) Implementation ₂ of Episode 2, together with the unchanged requirements, analysis, and design of Episode 1. The third baseline is the same as the fi rst baseline but with the design and implementation changed. The fourth baseline is the complete set of new artifacts shown in Figure 2.2 . We revisit the concept of a baseline in Chapters 5 and 16 .

FIGURE 2.3 A simplifi ed version of the waterfall

life-cycle model. Requirements

Implementation Analysis

Design

⭋

Development Maintenance

2.3 Lessons of the Winburg Mini Case Study

The Winburg mini case study depicts the development of a software product that goes awry for a number of unrelated causes, such as a poor implementation strategy (the unnecessary use of double-precision numbers) and the decision to use an algorithm that was too slow.

In the end, the project was a success. However, the obvious question is, Is software devel-opment really as chaotic in practice? In fact, the mini case study is far less traumatic than many, if not the majority of, software projects. In the Winburg mini case study, there were only two new versions of the software because of faults (the inappropriate use of double-precision numbers; the utilization of an algorithm that could not meet the response time requirement), and only one new version because of a change made by the client (the need for increased accuracy).

Why are so many changes to a software product needed? First, as previously stated, soft-ware professionals are human and therefore make mistakes. Second, a softsoft-ware product is a model of the real world, and the real world is continually changing. This issue is discussed at greater length in Section 2.4.

42 Part A Software Engineering Concepts