Download Software Development Process Models: Waterfall, Incremental, Spiral, and Concurrent Models and more Study notes Software Engineering in PDF only on Docsity!
CHAPTER 4 PROCESS MODELS 41
advantage under unpredictable environments. Change occurs when there is some structure so that the change can be organized, but not so rigid that it cannot occur. Too much chaos, on the other hand, can make coordination and coherence impossi- ble. Lack of structure does not always mean disorder. The philosophical implications of this argument are significant for software engineering. Each process model described in this chapter tries to strike a bal- ance between the need to impart order in a chaotic world and the need to be adaptable when things change constantly.
The purpose of process models is to try to reduce the chaos pres- ent in developing new software products.
4.1 P R E S C R I P T I V E P R O C E S S M O D E L S
A prescriptive process model^1 strives for structure and order in software devel- opment. Activities and tasks occur sequentially with defined guidelines for prog- ress. But are prescriptive models appropriate for a software world that thrives on change? If we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? There are no easy answers to these questions, but there are alternatives available to software engineers. In the sections that follow, we examine the pre- scriptive process approach in which order and project consistency are domi- nant issues. We call them “prescriptive” because they prescribe a set of process elements—framework activities, software engineering actions, tasks, work prod- ucts, quality assurance, and change control mechanisms for each project. Each process model also prescribes a process flow (also called a work flow )—that is, the manner in which the process elements are interrelated to one another. All software process models can accommodate the generic framework activi- ties described in Chapters 2 and 3, but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner.
4.1.1 The Waterfall Model
There are times when the requirements for a problem are well understood— when work flows from communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made (e.g., an adaptation to ac- counting software that has been mandated because of changes to government regulations). It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable.
WebRef An award-winning “pro- cess simulation game” that includes most important prescriptive process models can be found at: http://www.ics .uci.edu/˜emilyo/ SimSE/ downloads.html.
Prescriptive process models define a prescribed set of process elements and a predictable process work flow.
1 Prescriptive process models are sometimes referred to as “traditional” process models.
42 PAR T ONE THE SOFTWARE PROCESS
The waterfall model, sometimes called the classic life cycle , suggests a system- atic, sequential approach 2 to software development that begins with customer specification of requirements and progresses through planning, modeling, con- struction, and deployment, culminating in ongoing support of the completed software ( Figure 4.1). A variation in the representation of the waterfall model is called the V-model. Represented in Figure 4.2, the V-model [Buc99] depicts the relationship of quality assurance actions to the actions associated with communication, modeling, and early construction activities. As a software team moves down the left side of the V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution. Once code has been generated, the team moves up the right side of the V, essentially performing a series of tests (quality assurance actions) that validate each of the models cre- ated as the team moves down the left side. 3 In reality, there is no fundamental difference between the classic life cycle and the V-model. The V-model provides a way of visualizing how verifi cation and validation actions are applied to earlier engineering work. The waterfall model is the oldest paradigm for software engineering. How- ever, over the past four decades, criticism of this process model has caused even ardent supporters to question its efficacy [Han95]. Among the problems that are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indi- rectly. As a result, changes can cause confusion as the project team proceeds. 2. It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natu- ral uncertainty that exists at the beginning of many projects.
Why does the waterfall model sometimes fail?
2 Although the original waterfall model proposed by Winston Royce [Roy70] made provision for “feedback loops,” the vast majority of organizations that apply this process model treat it as if it were strictly linear. 3 A detailed discussion of quality assurance actions is presented in Part 3 of this book.
Communication project initiation requirements gathering
Planning estimating scheduling tracking
Modeling analysis design Deployment delivery support feedback
Construction code test
FIGURE 4.1 The waterfall model
The V-model illustrates how verification and validation actions are associated with earlier engineering actions.
44 PAR T ONE THE SOFTWARE PROCESS
linear process. In addition, there may be a compelling need to provide a limited set of software functionality to users quickly and then refine and expand on that functionality in later software releases. In such cases, you can choose a process model that is designed to produce the software in increments. The incremental model combines the elements’ linear and parallel process flows discussed in Chapter 3. Referring to Figure 4.3, the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable “increments” of the software [McD93]. For example, word-processing software developed using the incremental par- adigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document pro- duction capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth incre- ment. It should be noted that the process flow for any increment can incorporate the prototyping paradigm discussed in the next subsection. When an incremental model is used, the first increment is often a core prod- uct. That is, basic requirements are addressed but many supplementary fea- tures (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed evaluation). As a result of use and/ or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is re- peated following the delivery of each increment, until the complete product is produced.
The incremental model delivers a series of releases, called increments, that provide progressively more functionality for the customer as each increment is delivered.
increment # 1
increment # 2
delivery of 1st increment
delivery of 2nd increment
delivery of n th increment
increment # n
Project Calendar Time
Software Functionality and Features
Communication Planning Modeling (analysis, design) Construction (code, test) Deployment (delivery, feedback)
FIGURE 4.
The incremen- tal model
Your customer de- mands delivery by a date that is impossible to meet. Suggest deliv- ering one or more in- crements by that date and the rest of the software (additional increments) later.
CHAPTER 4 PROCESS MODELS 45
4.1.3 Evolutionary Process Models
Software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds, making a straight line path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, you need a process model that has been explicitly designed to accommodate a product that grows and changes. Evolutionary models are iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software. In the paragraphs that follow, we present two common evolutionary process models.
Prototyping. Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adapt- ability of an operating system, or the form that human-machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach. Although prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models noted in this chapter. Regardless of the manner in which it is applied, the prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are fuzzy. The prototyping paradigm (Figure 4.4) begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly, and mod- eling (in the form of a “quick design”) occurs. A quick design focuses on a rep- resentation of those aspects of the software that will be visible to end users (e.g., human interface layout or output display formats). The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine require- ments. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better understand what needs to be done. Ideally, the prototype serves as a mechanism for identifying software require- ments. If a working prototype is to be built, you can make use of existing pro- gram fragments or apply tools that enable working programs to be generated quickly.
Evolutionary process models produce an increasingly more complete version of the software with each iteration.
uote:
“Plan to throw one away. You will do that, anyway. Your only choice is whether to try to sell the throwaway to customers.” Frederick P. Brooks
When your customer has a legitimate need, but is clueless about the details, develop a prototype as a first step.
CHAPTER 4 PROCESS MODELS 47
available and known; an inefficient algorithm may be implemented simply to demonstrate capability. After a time, you may become comfortable with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system. Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders should agree that the prototype is built to serve as a mechanism for defi ning requirements. It is then discarded (at least in part), and the actual software is engineered with an eye toward quality. The Spiral Model. Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary software process model that couples the iterative na- ture of prototyping with the controlled and systematic aspects of the waterfall model. It provides the potential for rapid development of increasingly more
Selecting a Process Model, Part 1Selecting a Process Model, Part 1 The scene: Meeting room for the software engineering group at CPI Corporation, a (fictional) company that makes consumer products for home and commercial use. The players: Lee Warren, engineering manager; Doug Miller, software engineering manager; Jamie Lazar, software team member; Vinod Raman, software team member; and Ed Robbins, software team member. The conversation: Lee: So let’s recapitulate. I’ve spent some time dis- cussing the SafeHome product line as we see it at the moment. No doubt, we’ve got a lot of work to do to simply define the thing, but I’d like you guys to begin thinking about how you’re going to approach the software part of this project. Doug: Seems like we’ve been pretty disorganized in our approach to software in the past. Ed: I don’t know, Doug, we always got product out the door. Doug: True, but not without a lot of grief, and this project looks like it’s bigger and more complex than anything we’ve done in the past. Jamie: Doesn’t look that hard, but I agree... our ad hoc approach to past projects won’t work here, particu- larly if we have a very tight time line.
Doug (smiling): I want to be a bit more professional in our approach. I went to a short course last week and learned a lot about software engineering... good stuff. We need a process here. Jamie (with a frown): My job is to build computer programs, not push paper around. Doug: Give it a chance before you go negative on me. Here’s what I mean. (Doug proceeds to describe the process framework described in Chapter 3 and the prescriptive process models presented to this point.) Doug: So anyway, it seems to me that a linear model is not for us... assumes we have all requirements up front and, knowing this place, that’s not likely. Vinod: Yeah, and it sounds way too IT-oriented... probably good for building an inventory control system or something, but it’s just not right for SafeHome. Doug: I agree. Ed: That prototyping approach seems okay. A lot like what we do here anyway. Vinod: That’s a problem. I’m worried that it doesn’t provide us with enough structure. Doug: Not to worry. We’ve got plenty of other options, and I want you guys to pick what’s best for the team and best for the project.
S AFE H OME
48 PAR T ONE THE SOFTWARE PROCESS
complete versions of the software. Boehm [Boe01a] describes the model in the following manner: The spiral development model is a risk -driven process model generator that is used to guide multi-stakeholder concurrent engineering of software intensive systems. It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its de- gree of risk. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions. Using the spiral model, software is developed in a series of evolutionary re- leases. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. A spiral model is divided into a set of framework activities defined by the soft- ware engineering team. For illustrative purposes, we use the generic framework activities discussed earlier. 4 Each of the framework activities represent one seg- ment of the spiral path illustrated in Figure 4.5. As this evolutionary process be- gins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk (Chapter 35) is considered as each revolution is made. Anchor point milestones —a combination of work products and conditions that are attained along the path of the spiral— are noted for each evolutionary pass.
The spiral model can be adapted to apply throughout the entire life cycle of an application, from concept development to maintenance.
4 The spiral model discussed in this section is a variation on the model proposed by Boehm. For further information on the original spiral model, see [Boe88]. More recent discussion of Boehm’s spiral model can be found in [Boe98].
Communication
Planning
Modeling
Construction Deployment delivery feedback
Start
analysis design
code test
estimation scheduling risk analysis
FIGURE 4.
A typical spiral model
