This chapter is from the book
This chapter is from the book
This chapter is from the book
The Software Development Process
So far we have talked about examining the software development process without defining exactly what it entails. One reason for not being specific is that there is no one development process that is best suited for all rapid development projects. You might want to develop an embedded controller for a heart pacemaker as "rapidly as possible," but you are not likely to use the same process that a friend down the street is using to develop an online dictionary.
Shari Pfleeger (2001) defines a process as "a series of steps involving activities, constraints, and resources that produce an intended output of some kind." The following is adapted from Pfleeger's list of the attributes of a process:
The process prescribes all of the major process activities.
The process uses resources, subject to a set of constraints (such as a schedule), and provides intermediate and final products.
The process may be composed of subprocesses that are linked in some way. The process may be defined as a hierarchy of processes, organized so that each subprocess has its own process model.
Each process activity has entry and exit criteria, so that we know when the activity begins and ends.
The activities are organized in a sequence or in parallel to other independent subprocesses, so that it is clear when one activity is performed relative to the other activities.
Every process has a set of guiding principles that explains the goals of each activity.
Constraints or controls may apply to an activity, resource, or product. For example, the budget or schedule may constrain the length of time an activity may take or a tool may limit the way in which a resource may be used.
When a process relates to the building of a product, it is often called a life cycle. The development of a software product is therefore called a software life cycle. A software life cycle can be described in a variety of ways, but often a model is used that represents key features of the process with some combination of text and illustrations.
One of the first software life cycle models used was the waterfall, shown in Figure 1.2. A main characteristic of the waterfall model is that each phase or component of the model is completed before the next stage begins. The process begins with a definition of the requirements for the system, and in the waterfall model the requirements are elicited, analyzed, and written into one or more requirements documents before any design work begins. The system design, program design, coding, and testing activities are all self-contained and thoroughly documented phases of the process. It should be noted that different names are commonly used for some of the phases; for example, the system design phase is often called "preliminary design," and the program design phase is often called "detailed design."
){kind=link}
Figure 1.2 Waterfall life cycle model.
The waterfall model has a number of critics. One criticism questions the possibility of capturing all the requirements at the front-end of a project. Suppose you are asked to state all the requirements for a new car before it is designed and built. It would be impossible as a customer to conceive of all the detailed requirements that would be needed to design and build a car from scratch. Yet, this is the kind of demand that the waterfall model places upon customers and analysts at the front-end of a waterfall process.
Curtis, Krasner, Shen, and Iscoe (1987, cited in Pfleeger, 2000) state that the major shortcoming of the waterfall model is that it fails to treat software as a problem-solving process. The waterfall was adapted from the world of hardware development, and represents a manufacturing or assembly-line view of software development in which a component is developed and then replicated many times over. But software is a creation process rather than a manufacturing process. Software evolves iteratively as the understanding of a problem grows. There are a lot of back and forth activities that involve trying various things to determine what works best. It is not possible, in other words, to accurately model the software development process as a set of self-contained phases as the waterfall attempts to do. Other models such as the spiral, staged delivery and evolutionary prototype models are better suited to the iterative nature of software development. Iterative models are discussed further in Chapter 2.
If you have worked as a test engineer in a waterfall environment, you may have direct experience with another problem that is all too common with the waterfall. Unless certain precautions are taken, all the errors made in defining the requirements, designing the system, and writing the code flow downhill to the test organization. If the waterfall is used, the test team may find a lot of bugs near the end of development—bugs that have to be sent back upstream to be fixed in the requirements, design, or coding of the product. Going back upstream in a waterfall process is difficult, expensive, and time-consuming because all the work products that came from the supposedly "completed" phases now must be revised.
In spite of its problems, the waterfall model is worth understanding because it contains the basic components that are necessary for software development. Regardless of the model used, software development should begin with an understanding of what needs to be built; in other words, an elicitation and analysis of the requirements. The development process should include design, coding, and testing activities, whether they are done in a linear sequence as in the waterfall, or in an iterative sequence as in the evolutionary prototyping or staged delivery models. We use the waterfall as a context for discussing process improvement, but the basic principles of rapid testing should be applicable to whatever life cycle model is used.