CHANGES IN SOFTWARE
2.1 THE MEANING OF PROCESS
When we provide a service or create a product, whether it be developing software, writing a report, or taking a business trip, we always follow a sequence of steps to accomplish a set of tasks. The tasks are usually performed in the same order each time;
for example, you do not usually put up the drywall before the wiring for a house is installed or bake a cake before all the ingredients are mixed together. We can think of a set of ordered tasks as a process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind.
A process usually involves a set of tools and techniques, as we defined them in Chapter 1. Any process has the following characteristics:
• The process prescribes all of the major process activities.
• The process uses resources, subject to a set of constraints (such as a schedule), and produces 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 sub- process has its own process model.
• Each process activity has entry and exit criteria, so that we know when the activ- ity begins and ends.
• The activities are organized in a sequence, so that it is clear when one activity is performed relative to the other activities.
• Every process has a set of guiding principles that explain 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 the process involves the building of some product, we sometimes refer to the process as a life cycle. Thus, the software development process is sometimes called the software life cycle, because it describes the life of a software product from its concep- tion to its implementation, delivery, use, and maintenance.
Processes are important because they impose consistency and structure on a set of activities. These characteristics are useful when we know how to do something well and we want to ensure that others do it the same way. For example, if Sam is a good bricklayer, he may write down a description of the bricklaying process he uses so that Sara can learn how to do it as well. He may take into account the differences in the way people prefer to do things; for instance, he may write his instructions so that Sara can lay bricks whether she is right- or left-handed. Similarly, a software development pro- cess can be described in flexible ways that allow people to design and build software using preferred techniques and tools; a process model may require design to occur before coding, but may allow many different design techniques to be used. For this rea- son, the process helps to maintain a level of consistency and quality in products or ser- vices that are produced by many different people.
A process is more than a procedure. We saw in Chapter 1 that a procedure is like a recipe: a structured way of combining tools and techniques to produce a product. A process is a collection of procedures, organized so that we build products to satisfy a set of goals or standards. In fact, the process may suggest that we choose from several pro- cedures, as long as the goal we are addressing is met. For instance, the process may require that we check our design components before coding begins. The checking can be done using informal reviews or formal inspections, each an activity with its own pro- cedure, but both addressing the same goal.
The process structure guides our actions by allowing us to examine, understand, control, and improve the activities that comprise the process. To see how, consider the process of making chocolate cake with chocolate icing. The process may contain several procedures, such as buying the ingredients and finding the appropriate cooking utensils.
Section 2.1 The Meaning of Process 47 The recipe describes the procedure for actually mixing and baking the cake. The recipe contains activities (such as “beat the egg before mixing with other ingredients”), con- straints (such as the temperature requirement in “heat the chocolate to the melting point before combining with the sugar”), and resources (such as sugar, flour, eggs, and chocolate). Suppose Chuck bakes a chocolate cake according to this recipe. When the cake is done, he tastes a sample and decides that the cake is too sweet. He looks at the recipe to see which ingredient contributes to the sweetness: sugar. Then, he bakes another cake, but this time he reduces the amount of sugar in the new recipe. Again he tastes the cake, but now it does not have enough chocolate flavor. He adds a measure of cocoa powder to his second revision and tries again. After several iterations, each time changing an ingredient or an activity (such as baking the cake longer, or letting the chocolate mixture cool before combining with the egg mixture), Chuck arrives at a cake to his liking. Without the recipe to document this part of the process, Chuck would not have been able to make changes easily and evaluate the results.
Processes are also important for enabling us to capture our experiences and pass them along to others. Just as master chefs pass on their favorite recipes to their colleagues and friends, master craftspeople can pass along documented processes and procedures.
Indeed, the notions of apprenticeship and mentoring are based on the idea that we share our experience so we can pass down our skills from senior people to junior ones.
In the same way, we want to learn from our past development projects, document the practices that work best to produce high-quality software, and follow a software development process so we can understand, control, and improve what happens as we build products for our customers. We saw in Chapter 1 that software development usu- ally involves the following stages:
• requirements analysis and definition
• system design
• program design
• writing the programs (program implementation)
• unit testing
• integration testing
• system testing
• system delivery
• maintenance
Each stage is itself a process (or collection of processes) that can be described as a set of activities. And each activity involves constraints, outputs, and resources. For example, the requirements analysis and definitions stage need as initial input a state- ment of desired functions and features that the user expresses in some way. The final output from this stage is a set of requirements, but there may be intermediate products as the dialog between user and developer results in changes and alternatives. We have constraints, too, such as a budget and schedule for producing the requirements docu- ment, and standards about the kinds of requirements to include and perhaps the nota- tion used to express them.
Each of these stages is addressed in this book. For each one, we will take a close look at the processes, resources, activities, and outputs that are involved, and we will learn how
they contribute to the quality of the final product: useful software.There are many ways to address each stage of development; each configuration of activities, resources, and outputs constitutes a process, and a collection of processes describes what happens at each stage.
For instance, design can involve a prototyping process, where many of the design decisions are explored so that developers can choose an appropriate approach, and a reuse process, where previously generated design components are included in the current design.
Each process can be described in a variety of ways, using text, pictures, or a com- bination. Software engineering researchers have suggested a variety of formats for such descriptions, usually organized as a model that contains key process features. For the remainder of this chapter, we examine a variety of software development process mod- els, to see how organizing process activities can make development more effective.