| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
In this section, we examine: • what we mean by a “process” • software development products, • processes, and resources • several models of the software development process • tools and techniques for process modeling We saw in Section 1 that engineering software is both a creative and a step-by-step process, often involving many people producing many different kinds of products. In this section, we examine the steps in more detail, looking at ways to organize our activities so we can coordinate what we do and when we do it. We begin the section by defining what we mean by a process, so that we understand what must be included when we model software development. Next, we examine several types of software process models. Once we know the type of model we wish to use, we take a close look at two types of modeling techniques: static and dynamic. Finally, we apply several of these techniques to our information systems and real-time examples. 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 Section 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 activity 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 conception 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 brick layer, he may write down a description of the bricklaying process he uses so 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 Sara can lay bricks whether she is right- or left-handed. Similarly, a software development process 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 reason, the process helps to maintain a level of consistency and quality in products or services that are produced by many different people. A process is more than a procedure. We saw in Section 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 procedures, as long as the goal we are addressing is met. For instance, the process may re quire 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 procedure, 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 sever al procedures, such as buying the ingredients and finding the appropriate cooking utensils. 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”), constraints (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 mix ture 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 Section 1 that software development usually 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, requirements analysis and definition need as initial input a statement 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 document, and standards about the kinds of requirements to include and perhaps the notation used to express them. Each of these stages is addressed in this guide. 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, re sources, 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 combination. Software engineering researchers have suggested a variety of formats for such description, usually organized as a model that contains key process features. For the remainder of this section, we examine a variety of software development process models, to see how organizing process activities can make development more effective. 2. SOFTWARE PROCESS MODELS Many process models are described m the software engineering literature. Some are prescriptions for the way software development should progress, and others are descriptions of the way software development is done in actuality. In theory, the two kinds of models should be similar or the same, but in practice, they are not. Building a process model and discussing its subprocesses help the team understand this gap between what should be and what is. There are several other reasons for modeling a process: • When a group writes down a description of its development process, it forms a common understanding of the activities, resources, and constraints involved in software development. • Creating a process model helps the development team find inconsistencies, redundancies, and omissions in the process and in its constituent parts. As these problems are noted and corrected, the process becomes more effective and focused on building the final product. • The model should reflect the goals of development, such as building high-quality software, finding faults early in development, and meeting required budget and schedule constraints. As the model is built, the development team evaluates candidate activities for their appropriateness in addressing these goals. For example, the team may include requirements reviews, so that problems with the requirements can be found and fixed before design begins. • Every process should be tailored for the special situation in which it will be used. Building a process model helps the development team understand where that tailoring is to occur. Every software development process model includes system requirements as input and a delivered product as output. Many such models have been proposed over the years. Let us look at several of the most popular models to understand their commonalities and differences. Waterfall Model One of the first models to be proposed is the waterfall model, illustrated in FIG. 1, where the stages are depicted as cascading from one to another (Royce 1970). As the figure implies, one development stage should be completed before the next begins. Thus, when all of the requirements are elicited from the customer, analyzed for completeness and consistency, and documented in a requirements document, then the development team can go on to system design activities. The waterfall model presents a very high- level view of what goes on during development, and it suggests to developers the sequence of events they should expect to encounter. The waterfall model has been used to prescribe software development activities in a variety of contexts. For example, it was the basis for software development deliverables in U.S. Department of Defense contracts for many years, defined in Department of Defense Standard 2167-A. Associated with each process activity were milestones and deliverables, so that project managers could use the model to gauge how close the project was to completion at a given point in time. For instance, “unit and integration testing” in the waterfall ends with the milestone “code modules written, tested, and integrated;” the intermediate deliverable is a copy of the tested code. Next, the code can be turned over to the system testers so it can be merged with other system components (hardware or software) and tested as a larger whole. The waterfall model can be very useful in helping developers lay out what they need to do. Its simplicity makes it easy to explain to customers who are not familiar with soft ware development; it makes explicit which intermediate products are necessary in order to begin the next stage of development. Many other, more complex models are really just embellishments of the waterfall, incorporating feedback loops and extra activities.
Many problems with the waterfall model have been discussed in the literature, and two of them are summarized in Sidebar 1. The biggest problem with the waterfall model is that it does not reflect the way code is really developed. Except for very well- understood problems, software is usually developed with a great deal of iteration. Often, software is used in a solution to a problem that has never before been solved or whose solution must be upgraded to reflect some change in business climate or operating environment. For example, an airplane manufacturer may require software for a new air frame that will be bigger or faster than existing models, so there are new challenges to address, even though the software developers have a great deal of experience in building aeronautical software. Neither the users nor the developers know all the key factors that affect the desired outcome, and much of the time spent during requirements analysis, as we will see in Section 4, may be devoted to understanding the items and processes affected by the system and its software, as well as the relationship between the system and the environment in which it will operate. Thus, the actual software development process, if uncontrolled, may look like FIG. 2; developers may thrash from one activity to the next and then back again, as they strive to gather knowledge about the problem and how the proposed solution addresses it. == === = SIDEBAR 1 DRAWBACKS OF THE WATERFALL MODEL Ever since the waterfall model was introduced, it has had many Critics. For example, McCracken and Jackson (1981) pointed out that the model imposes a project manage merit structure on system development To contend that any life cycle scheme even with variations can he applied to all system development is either to fly in the face of reality or to assume a life cycle so rudimentary as to be vacuous. Notice that the waterfall model shows how each major phase of development terminates in the production of some artifact (such as requirements design or code) There is no insight into how each activity transforms one artifact to another such as requirements to design Thus the model provides no guidance to managers and developers on how to handle changes to products and activities that are likely to occur during development For inst hen requirements change during coding activities the subsequent changes to design and code are not addressed by the waterfall model. Curtis Krasner Shen and Iscoe (1987) note that the waterfall model s major shortcoming is its failure to treat software as a problem solving process The waterfall model’s derived from the hardware world presenting a manufacturing view of software are development. But manufacturing produces a particular item and reproduces it many times. Software is not developed like that rather it evolves ms the problem becomes understood and the alternatives are evaluated. Thus software is a creation process not a manufacturing process. The waterfall model tells us nothing about the typical back and forth activities that lead to creating a final product. In particular creation usually in trying a little of this or that developing and evaluating prototypes assessing the feasibility of requirements contrasting several designs, learning from failure and eventually settling on a satisfactory solution to the problem at hand. = = == = The software development process can help to control the thrashing by including activities and subprocesses that enhance understanding. Prototyping is such a subprocess; a prototype is a partially developed product that enables customers and developers to examine some aspect of the proposed system and decide if it is suitable or appropriate for the finished product. For example, developers may build a system to implement a small portion of some key requirements to ensure that the requirements are consistent, feasible, and practical; if not, revisions are made at the requirements stage, rather than at the more costly testing stage. Similarly, parts of the design may be prototyped, as shown in FIG. 3. Design prototyping helps developers assess alternative design strategies and decide which is best for a particular project. As we will see in Section 5, the designers may address the requirements with several radically different designs to see which has the best properties. For instance, a network may be built as a ring in one prototype and a star in another, and performance characteristics evaluated to see which structure is better at meeting performance goals or constraints. Often, the user interface is built and tested as a prototype, so the users understand what the new system will be like, and the designers get a better sense of how the users like to interact with the system. Thus, major kinks in the requirements are addressed and fixed well before the requirements are officially validated during system testing; validation ensures that the system has implemented all of the requirements, so that each system function can be traced back to a particular requirement in the specification. System testing also verifies the requirements; verification ensures that each function works correctly. That is, validation makes sure that the developer is building the right product (according to the specification), and verification checks the quality of the implementation. Prototyping is useful for verification and validation, but these activities can occur during other parts of the development process, as we will see in later sections.
The V model is a variation of the waterfall model that demonstrates how the testing activities are related to analysis and design (German Ministry of Defense 1992).As shown in FIG. 4, coding forms the point of the V. with analysis and design on the left, testing and maintenance on the right. Unit and integration testing addresses the correctness of programs, as we shall see in later sections. The V model suggests that unit and integration testing also be used to verify the program design. That is, during unit and integration testing, the coders and test team members should ensure that all aspects of the program design have been implemented correctly in the code. Similarly, system testing should verify the system design, making sure that all system design aspects are correctly implemented. Acceptance testing, which is conducted by the customer rather than the developer, validates the requirements by associating a testing step with each element of the specification; this type of testing checks to see that all requirements have been fully implemented before the system is accepted and paid for. The model’s linkage of the left side with the right side of the V implies that if problems are found during verification and validation, then the left side of the V can be re executed to fix and improve the requirements, design, and code before the testing steps on the right side are reenacted. In other words, the V model makes more explicit some of the iteration and rework that are hidden in the waterfall depiction. Whereas the focus of the waterfall is often documents and artifacts, the focus of the V model is activity and correctness. Prototyping Model We have seen how the waterfall model can be amended with prototyping activities to improve understanding. But prototyping need not be solely an adjunct of a waterfall; it can itself be the basis for an effective process model, shown in FIG. 5. Since the prototyping model allows all or part of a system to be constructed quickly to understand or clarify issues, it has the same objective as an engineering prototype, where requirements or design require repeated investigation to ensure that the developer, user, and customer have a common understanding both of what is needed and what is proposed. One or more of the loops for prototyping requirements, design, or the system may be eliminated, depending on the goals of the prototyping. However, the overall goal remains the same: reducing risk and uncertainty in development.
For example, system development may begin with a nominal set of requirements supplied by the customers and users. Then, alternatives are explored by having interested parties look at possible screens, tables, reports, and other system output that are used directly by the customers and users. As the users and customers decide on what they want, the requirements are revised. Once there is common agreement on what the requirements should be, the developers move on to design. Again, alternative designs are explored, often with consultation with customers and users. The initial design is revised until the developers, users, and customers are happy with the result. Indeed, sometimes considering design alternatives reveals a problem with the requirements, and the developers drop back to the requirements activities to re consider and change the requirements specification. Eventually, the system is coded and alternatives are discussed, with possible iteration through requirements and design again. Operational Specification For many systems, uncertainty about the requirements leads to changes and problems later in development. Zave (1984) suggests a process model that allows the developers and customers to examine the requirements and their implications early in the development process, where they can discuss and resolve some of the uncertainty. In the operational specification model, the system requirements are evaluated or executed in a way that demonstrates the behavior of the system. That is, once the requirements are specified, they can be enacted using a software package, so their implications can be assessed be fore design begins. For example, if the specification requires the proposed system to handle 24 users, an executable form of the specification can help analysts determine whether that number of users puts too much of a performance burden on the system. This type of process is very different from traditional models such as the waterfall model, The waterfall model separates the functionality of the system from the design (i.e., what the system is to do is separated from how the system does it), intending to keep the customer needs apart from the implementation. However, an operational specification allows the functionality and the design to be merged. FIG. 6 illustrates how an operational specification works. Notice that the operational specification is similar to prototyping; the process enables user and developer to examine requirements early on. Transformational Model Balzer’s transformational model tries to reduce the opportunity for error by eliminating several major development steps. Using automated support, the transformational process applies a series of transformations to change a specification into a deliverable system (Balzer 1981a). Sample transformations can include • changing the data representations • selecting algorithms • optimizing • compiling Because many paths can be taken from the specification to the delivered system, the sequence of transformations and the decisions they reflect are kept as a formal development record. The transformational approach holds great promise. However, a major impediment to its use is the need for a formal specification expressed precisely so the trans formations can operate on it, as shown in FIG. 7. As formal specification methods become more popular, the transformational model may gain wider acceptance. Phased Development: Increments and Interations In the early years of software development, customers were willing to wait a long time for software systems to be ready. Sometimes years would pass between the time the requirements documents were written and the time the system was delivered, called the cycle time. However, today’s business environment no longer tolerates long delays. Soft ware helps to distinguish products in the marketplace, and customers are always looking for new quality and functionality. For example, in 1996, 80 percent of Hewlett- Packard’s revenues were derived from products introduced in the past two years. Consequently, new process models were developed to help reduce cycle time. One way to reduce cycle time is to use phased development, as shown in FIG. 8. The system is designed so that it can be delivered in pieces, enabling the users to have some functionality while the rest is being developed. Thus, there are usually two systems functioning in parallel: the production system and the development system. The operational or production system is the one currently being used by the customer and user; the development system is the next version that is being prepared to replace the current production system. Often, we refer to the systems in terms of their release numbers: the developers build Release 1, test it, and turn it over to the users as the first operational release. Then, as the users use Release 1, the developers are building Release 2. Thus, the developers are always working on Release n + 1 while Release n is operational. There are many ways for the developers to decide how to organize development into releases. The two most popular approaches are incremental development and iterative development. In incremental development, the system as specified in the requirements documents is partitioned into subsystems by functionality. The releases are defined by beginning with one small, functional subsystem and then adding functionality with each new release. The top of FIG. 9 shows how incremental development slowly builds up to full functionality with each new release. However, iterative development delivers a full system at the very beginning and then changes the functionality of each subsystem with each new release. The bottom of FIG. 9 illustrates three releases in an iterative development.
To understand the difference between incremental and iterative development, consider a word processing package. Suppose the package is to deliver three types of functionality: creating text, organizing text (i.e., cutting and pasting), and formatting text (such as using different type sizes and styles). To build such a system using incremental development, we might provide only the creation functions in Release 1, then both creation and organization in Release 2. and finally creation, organization, and formatting in Release 3. However, using iterative development, we would provide primitive forms of all three types of functionality in Release 1. For example, we can create text and then cut and paste it, but the cutting and pasting functions might be clumsy or slow. So in the next iteration. Release 2, we have the same functionality, but have enhanced the quality; now cutting and pasting are easy and quick. Each release improves on the previous ones in some way. In reality, many organizations use a combination of iterative and incremental development. A new release may include new functionality, but existing functionality from the current release may have been enhanced. These forms of phased development are desirable for several reasons: 1. Training can begin on an early release, even if some functions are missing. The training process allows developers to observe how certain functions are executed, suggesting enhancements for later releases. In this way, the developers can be very responsive to the users. 2. Markets can be created early for functionality that has never before been offered. 3. Frequent releases allow developers to fix unanticipated problems globally and quickly, as they are reported from the operational system. 4. The development team can focus on different areas of expertise with different re leases. For instance, one release can change the system from a command-driven one to a point-and-click interface, using the expertise of the user-interface specialists; another release can focus on improving system performance. Spiral Model Boehm (1988) viewed the software development process in light of the risks involved, suggesting that a spiral model could combine development activities with risk management to minimize and control risk. The spiral model, shown in FIG. 10, is in some sense like the iterative development shown in FIG. 9. Beginning with the requirements and an initial plan for development (including a budget, constraints, and alter natives for staffing, design, and development environment), the process inserts a step to evaluate risks and prototype alternatives before a “concept of operations” document is produced to describe at a high level how the system should work. From that document, a set of requirements is specified and scrutinized to ensure that the requirements are as complete and consistent as possible. Thus, the concept of operations is the product of the first iteration, and the requirements are the principal product of the second. In the third iteration, system development produces the design, and the fourth enables testing. With each iteration, the risk analysis weighs different alternatives in light of the requirements and constraints, and prototyping verifies feasibility or desirability before a particular alternative is chosen. When risks are identified, the project managers must decide how to eliminate or minimize the risk. For example, designers may not be sure whether users will prefer one type of interface over another. To minimize the risk of choosing an interface that will prevent productive use of the new system, the designers can prototype each interface and run tests to see which is preferred, or even choose to include two different interfaces in the design, so the users can select an interface when they log on. Constraints such as budget and schedule help to determine which risk management strategy is chosen. We will discuss risk management in more detail in Section 3.
The process models presented in this section are only a few of those that are used or discussed. Other process models can be defined and tailored to the needs of the user, customer, and developer. As Sidebar 2 notes, we should really capture the development process as a collection of process models, rather than focusing on a single model or view. = = == = SIDEBAR 2 COLLECTIONS OF PROCESS MODELS We saw m Sidebar 1 that the development process is a problem-solving activity, but few of the popular process models include problem solving. Curtis, Krasner, and lscoe (1988) performed a field study of 17 large projects, to determine which problem-solving factors should be captured in process models to aid our understanding of software development. In particular, they looked at the behavioral and organizational factors that affect project outcomes. Their results suggest a layered behavioral model of software development, including five key perspectives: the business milieu, the company, the project, the team, and the individual. The individual view provides information about cognition and motivation, and project and team views tell us about group dynamics. The company and business milieu provide information about organizational behavior that can affect both productivity and quality. This model does not replace traditional process models: rather, it is orthogonal, supplementing the traditional models with information on how behavior affects the creation and production activities. As the developers and customers learn about the problem, they integrate their knowledge of domains, technology, and business to produce an appropriate solution. By viewing development as a collection of coordinating processes, we can see the effects of learning, technical communication, customer interaction, and requirements negotiation. Current models that pre scribe a series of development tasks “provide no help in analyzing how much new information must be learned by the project staff, how discrepant requirements should be negotiated, how a design team can resolve architectural conflicts, and how these and similar factors contribute to a project’s inherent uncertainty and risk” (Curtis, Krasner, and Iscoe 1988). However, when we include models of cognitive, social, and organizational processes, we begin to see the causes of bottlenecks and inefficiency. It is this insight that enables managers to understand and control the development process. And by aggregating behavior across layers of models, we can see how each model contributes to or compounds the effects of another model’s factors. No matter what process model is used, many activities are common to all. As we investigate software engineering in later sections, we will examine each development activity to see what it involves and to find out what tools and techniques make us more effective and productive. |
