Software Engineering For Students: A Programming Approach Part 32 pot

288 Chapter 20 ■ Groups 20.1 Assess the effectiveness of structured walkthroughs. 20.2 Evaluate pair programming. 20.3 Compare and contrast the structured walkthrough technique with pair programming. 20.4 Argue a case for either walkthroughs or pair programming and suggest how it might be introduced into an organization. 20.5 Try to introduce ego-less programming into your college, university or organization in the following way. When you have written your next program and have a clean- compiled listing, ask one of your colleagues to look through it for you. Explain that you would appreciate comments of any kind on the program’s clarity, correctness, etc. Explain that you are trying to identify problems sooner rather than later. Offer to do the same in return. 20.6 Suggest features for software tools that could assist in using each of the following techniques: ■ walkthroughs ■ inspections. Exercises • Further reading • The classic book which introduced the idea of ego-less programming, the precursor to walkthroughs and inspections. It deals at length and in a most interesting way with the informal, social aspects of working in a team. It is most enjoyable to read. G. Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, l971. The original reference describing the technique of inspections: M.E. Fagan, Design and code inspections to reduce errors in program development, IBM Systems Journal, 15 (3) (July 1976), pp. 182–211. Full of practical advice and case studies, jointly authored by one of the industry gurus, all you ever wanted to know about inspections is explained in: Tom Gilb and Dorothy Graham, Software Inspection, Addison-Wesley, 1993. A collection of useful papers on how to do inspections and what the benefits are: David A. Wheeler, Bill Brykczynski and Reginald N. Meeson, Software Inspection: An Industry Best Practice, IEEE Computer Society Press, 1996. There is a website simply for pair programming, with links to sites that report on eval- uations, at: http://www.pairprogramming.com/ This is a useful book on pair programming: Laurie Williams and Robert Kessler, Pair Programming Illuminated, Addison-Wesley, 2002. BELL_C20.QXD 1/30/05 4:25 PM Page 288 PART E PROCESS MODELS BELL_CPARTE.QXD 1/30/05 4:31 PM Page 289 BELL_CPARTE.QXD 1/30/05 4:31 PM Page 290 The waterfall model is an established approach that dominated software development for a number of years and is widely used. It has the virtue of simplicity. In the waterfall model, software development is split up into a number of independent steps (Figure 21.1). These steps are carried out in sequence one after the other. Each stage produces a product which is the input into the next stage. It is important to real- ize that each stage is pursued until its conclusion before the next stage is begun. Thus, for example, all the coding is completed before testing starts. Like all process models, the waterfall model says nothing about what methods are used at any of its stages, nor does it stipulate what notations are used for the products at each stage. (This whole book is about the different methods and notations that are available.) It merely provides a framework for a development. Different people and authors have slightly different ideas about what exactly the steps should be. For example, some people include a feasibility study as the first step. However, the essentials of the approach are the same. 21.2 ● Principles of the model 21.1 ● Introduction CHAPTER 21 The waterfall model This chapter explains: ■ how to use the waterfall model for software development ■ the principles behind the waterfall model. BELL_C21.QXD 1/30/05 4:25 PM Page 291 292 Chapter 21 ■ The waterfall model The principles of the waterfall model are: ■ it is a series of steps (like a factory production line) ■ each step is well defined ■ each step creates a definite product (in some cases a piece of paper) ■ each product forms the basis for the next step ■ the correctness of each step can be checked (verification or validation). The waterfall model gets its name because each stage produces a product, like a stream of water which passes on to the next stage. So the complete development process is like a series of small waterfalls – see Figure 21.1. Just as water cannot flow up a waterfall, information does not flow backwards in the waterfall model. Once a step is complete, there is no going back. Requirements Engineering Architectural design Detailed design Coding Acceptance Unit testing System testing Figure 21.1 The waterfall model SELF-TEST QUESTION 21.1 Draw up a process model for preparing a meal, including buying the ingredients and washing up afterwards. Don’t forget to identify the product at each stage. The inputs and outputs for each step of the waterfall model are shown in this table. BELL_C21.QXD 1/30/05 4:25 PM Page 292 21.3 Feedback between stages 293 One of the drawbacks of a strict waterfall model is that the water cannot flow upwards – if a problem is found at a particular stage in development, there is no way of redoing an earlier stage in order to rectify the problem. For example, testing usually finds errors in the (preceding) coding stage, but in the strict waterfall approach, the coding cannot be corrected. When preparing a meal, if you find that some ingredient is missing when you get to the stage of cooking the vegetables, you need to go back to the shopping stage. To overcome this obvious drawback, a variation of the waterfall model provides for feedback between adjoining stages, so that a problem uncovered at one stage can cause remedial action to be taken at the previous stage. Thus the waterfall model with feed- back between stages is as shown in Figure 21.2. You will see, however, that this approach only provides for feedback to the immedi- ately preceding step. But, in reality, any step may necessitate changes in any of the pre- ceding stages. For example: ■ during system testing, an architectural design fault is revealed ■ during user acceptance, a problem with the specification becomes evident. So the reality of using the waterfall model is that development does not proceed in one direction, step by step. Instead, there is commonly frequent feedback to earlier stages, requiring rework (which can seriously disrupt the timescale of a project). To be more realistic, Figure 21.2 should show arrows leading backwards from every activity to every preceding activity. This, of course, undermines the model and any planning. 21.3 ● Feedback between stages requirements engineering none requirements specification architectural design requirements specification architectural design detailed design architectural design module specifications coding module specifications coding unit testing coding tested modules system testing tested modules tested system acceptance tested system satisfied client Stage Input Output SELF-TEST QUESTION 21.2 Someone enhances the waterfall model by including a user interface design stage immediately after the requirements engineering stage. What are its inputs and outputs? BELL_C21.QXD 1/30/05 4:25 PM Page 293 294 Chapter 21 ■ The waterfall model The instigators of the waterfall model clearly and wrongly perceived software devel- opment to be simple and straightforward, with development proceeding smoothly onwards from stage to stage without disruption. But, as we have seen, there are funda- mental problems with using the waterfall model as a basis for a project plan. Nonetheless, it is common to use this process model. The strengths of the waterfall model are: ■ it divides a complex task into smaller, more manageable tasks ■ each task produces a well-defined deliverable. Thus the process is well-defined. Anyone can see exactly what has been completed and what remains to be done. Perhaps the most serious problem with the waterfall model is that the client only gets to see the product at the very end of the development – and if it is not what they want, it is too late! The problem is the huge gap between requirements analysis at an early stage in a project and acceptance testing near the end. There is no opportunity to validate the user requirements at an early stage in development. This is a major prob- lem with the waterfall model. But there are also less obvious, but equally important drawbacks. If a problem is dis- covered at any stage which reveals a mistake at an earlier stage, nothing can be done about it. 21.4 ● Discussion Requirements Engineering Architectural design Detailed design Coding Acceptance Unit testing System testing Figure 21.2 Modified waterfall model with feedback BELL_C21.QXD 1/30/05 4:25 PM Page 294 Exercises 295 21.1 Draw up a waterfall process model for a large civil engineering project, such as building a road bridge across the channel between England and France. Identify similarities and differences between this project and a large software development project. 21.2 Validation and verification are clearly important. Identify where validation is carried out and where verification is carried out in the waterfall model. 21.3 Create an outline plan for developing each of the systems in Appendix A using the waterfall model. 21.4 Evaluate the waterfall model using the following criteria: ■ capability to accommodate risk ■ capability to meet user requirements ■ capability to respond to changed requirements ■ visibility of the progress of the project. 21.5 Identify the main goals and the main techniques of each of the following process models: ■ waterfall ■ spiral ■ prototyping ■ incremental ■ open source ■ XP ■ UP 21.6 “The waterfall model is useless.” Discuss. Exercises Summary The essence and the strengths of the waterfall model are that: ■ it divides a complex task into smaller, more manageable tasks ■ each task produces a well-defined deliverable. ■ each stage is carried out in sequence – there is no going back. The goal of this approach is to maintain control during development. • BELL_C21.QXD 1/30/05 4:25 PM Page 295 296 Chapter 21 ■ The waterfall model Answers to self-test questions 21.1 1. buy ingredients (product is ingredients) 2. prepare vegetables (prepared vegetables) 3. cook meat (cooked meat) 4. cook vegetables (cooked vegetables) 5. serve meal (meal on table) 6. wash up (clean utensils). 21.2 The input is the requirements specification. The output is the specification of the user interface. BELL_C21.QXD 1/30/05 4:25 PM Page 296 The main feature of the spiral model is the recognition that there is often enormous uncertainty at many stages during a software development project. It therefore incor- porates periodic risk assessment. These assessments are followed by identifying alterna- tive actions, selection of the best action and re-planning. This model is shown in Figure 22.1. Progress is shown as a line that spirals out from near the centre of the diagram. Each cycle of the project passes through four steps, shown as the four quarters of the diagram. The project spirals outwards from the center of the dia- gram to convey the increasing expenditure of time, effort – and progress. As the diagram shows, each cycle consists of four steps: 1. analyze risks and plan 2. analyze requirements 3. construct 4. evaluate. 22.2 ● The spiral model 22.1 ● Introduction CHAPTER 22 The spiral model This chapter: ■ explains the principles behind the spiral model ■ explains some of the practical aspects of using this model. BELL_C22.QXD 1/30/05 4:26 PM Page 297 . waterfall model. But there are also less obvious, but equally important drawbacks. If a problem is dis- covered at any stage which reveals a mistake at an earlier stage, nothing can be done about. shopping stage. To overcome this obvious drawback, a variation of the waterfall model provides for feedback between adjoining stages, so that a problem uncovered at one stage can cause remedial action. 4:25 PM Page 288 PART E PROCESS MODELS BELL_CPARTE.QXD 1/30/05 4:31 PM Page 289 BELL_CPARTE.QXD 1/30/05 4:31 PM Page 290 The waterfall model is an established approach that dominated software development for