Software Processes

Lesson 2

a

SOFTWARE PROCESSES

common mistake people make concerning software is assuming that the majority of software development is programming. When they think of programming, their minds conjure up the image of a late-night hacker pounding out code on an old computer in the basement of a musty apartment. While this is certainly one approach to programming, it is hardly the norm and definitely not the way the majority of current software is developed. In fact, programming is only a fraction of the software development process. Today, many other steps are involved in the successful development and deployment of computer software. Taken together, all these steps are referred to as the software life cycle. Often models called software life cycle models describe these steps. In the next two lessons we will examine two of these models: the waterfall model and the spiral model. First, however, we need to describe the basic processes that make up the software life cycle.

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 or 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 involved a set of tools and techniques. process has the following characteristics:

Any

The process prescribes all of the major process activities. The process uses resources, subject of 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 subprocess has its own process model.

Lesson 2: Software Processes __________________________________________________________________

11

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. 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. 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. The process structure guides our actions by allowing us to examine, understand, control, and improve the activities that comprise the process. 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 development process so we can understand, control, and improve what happens as we build products for our customers. Most models of the software life cycle include the following six processes: requirements engineering, design, programming, integration, delivery, and maintenance. The list below gives a description of each process and will be discussed in details in the succeeding lessons. Requirements Engineering During this process, developers and clients meet to discuss ideas for the new software product. Developers use a variety of techniques in order to assess the real needs of the client. One such technique is rapid prototyping in which a prototype program is built that can mimic the functionality of the desired software. Using this prototype, clients can better understand how the final product will behave and can determine whether this behavior is what they really Software Project Management _________________________________________________________________

___________________________________________________ Software Engineering: A Computer Science Approach

need. Unless the requirements engineering process is done properly, the resulting software will not be useful to the client even though it may run correctly. The requirements engineering process is completed when the specifications for the new software product are written in a formal document called the requirements specification document.

12 Design During this process, the developers decide how they will construct the software so that it meets the specifications agreed upon in the requirements specification document. Usually the design of the software goes through several stages in which it becomes progressively more detailed. This approach to design is called stepwise refinement, and it allows the developers to manage the complexity of software by postponing decisions about details as late as possible in order to concentrate on other important design issues. When the design is complete, it is recorded in the design specification document. Programming During this process, teams of programmers write the actual code of the software. The software is divided into separate units called modules in order to handle the complexity of the programming process. Not only are these teams responsible for coding their modules, they are also responsible for proper documentation describing their code and for testing the code to insure correctness. Integration During this process, the individual modules of the software product are combined to form the integrated software product. Since the modules were developed separately, testing is crucial to the integration process. Even with a good design, incompatibilities between modules are likely to exist. These problems need to be identified and corrected to complete the integration. Delivery During this process, the developers deliver the completed software to the clients. Usually the clients will conduct acceptance testing on the software to determine whether or not it meets the specifications agreed upon in the requirements specification document. Once the software is accepted, it is installed and used by the client. Maintenance During this process, the software undergoes various changes after delivery in order to fix bugs, add new functionality, port the software to new platforms, or adapt the software to new technologies. Although it may seem that the software should be finished after delivery, this is far from true. All successful software _________________________________________________________________ Software Project Management

Lesson 2: Software Processes __________________________________________________________________

products evolve over time to meet the changing needs of the clients.

13 Approximate relative costs of the phases of the software life cycle [Schach 1999]

You may be surprised to discover that of all these processes, maintenance dominates the cost of the life cycle. The graph on the previous page shows the relative cost of the processes that make up the software life cycle. Because maintenance costs are so important, many developers are beginning to use design approaches that result in software that is easier to maintain. At the end of this module we will examine one of these approaches: the object-oriented paradigm. Many different models have been created to represent the software life cycle. Although these models use various names for the processes of the life cycle, they all include the six processes described above in one way or another. In addition, these models usually emphasize some other aspect of software development such as a particular design technique (e.g., rapid prototyping), management technique (e.g., risk management), or the model describes a limited domain of software development (e.g., real-time software).

The Waterfall Model The Waterfall Model is the classic software life cycle model. According to Schach [1999], this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model. Input Product

Process

Software Project Management _________________________________________________________________

Output Product

___________________________________________________ Software Engineering: A Computer Science Approach

Communicated Requirements

Requirements Engineering

Requirements Specification Document

Requirements Specification Document

Design

Design Specification Document

Design Specification Document

Programming

Executable Software Modules

Executable Software Modules

Integration

Integrated Software Product

Integrated Software Product

Delivery

Delivered Software Product

Delivered Software Product

Maintenance

Changed Requirements

Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:

A gray box represents each product and a solid arrow connecting the boxes represents each process. To learn more about these processes and products, view the Waterfall Model illustrations on the Appendices part. In addition to the six processes and seven products that make up the Waterfall Model, several other important development activities and characteristics are represented in the model. One of these activities is testing. According to Schach, "inherent in every phase of the Waterfall Model is testing. Testing is not a separate phase to be performed only after the product has been constructed; it is not to be performed only at the end of each phase. Instead...testing should proceed continuously throughout the software process." [Schach 1999] Testing actually involves two steps: verification and validation. Verification is substantiating that the software has been transformed from one form into another as intended with sufficient accuracy. For example, the design process transforms the design specification document into the executable software modules. Verification in this case is determining that the software modules really are the entities that the design document describes. Verification answers the question "Are we building the software right?" _________________________________________________________________ Software Project Management

14

Lesson 2: Software Processes __________________________________________________________________

Validation is substantiating that the software functions with sufficient accuracy with respect to its requirements specification. Using the same example as before, validating the executable software modules is determining that they behave as described in the requirements specification. Validation answers the question "Are we building the right software?" [Balci 1998] Testing involving verification and validation should be conducted in parallel with the development of the software product. In order to represent the testing activity as an ongoing process, the V&V boxes appear under each product of the Waterfall Model.

Verification deals with building the software right. Validation deals with building the right software. V&V of testing

15

One important characteristic of the Waterfall Model is the iteration arrows that join the processes together. These arrows show how the development of one product can influence the development of previous products. A good example of this is the programming process loop. In the diagram on the next page, notice how the programming process and the accompanying iteration arrow form a loop between the design specification document and the executable software modules.

It is possible that design flaws will be revealed during the programming of the software. When this happens, the design specification must be changed to reflect the correction, these changes must be tested, and finally the new design must be entered into the programming process again. This loop is repeated for all the design flaws that are discovered during programming. Notice that in the complete Waterfall Model diagram (see Appendices), the iteration arrows connect all the processes with the exception of the delivery process. Like the programming process, requirements engineering, design, and integration are all iterative processes that involve progressive refinement of the resulting product. Software Project Management _________________________________________________________________

___________________________________________________ Software Engineering: A Computer Science Approach

Another important characteristic of the Waterfall Model is the maintenance arrows that connect the delivered software product to the various other products in the life cycle. Remember that any changes made to the software product after deliveries are considered maintenance. A small change such as the correction of a programming error may only require a change in the code of the software. The arrow connecting the delivered software product with the executable software modules represents these types of changes. Other changes such as the addition of new functionality require a change in the requirements specification of the software. The arrow going to the Changed Requirements product represents these types of changes. Notice that a change in the requirements affects almost the entire life cycle since these requirements become input to the design process and so on. While the Waterfall Model presents a straightforward view of the software life cycle, this view is only appropriate for certain classes of software development. Specifically, the Waterfall Model works well when the software requirements are well understood (e.g., software such as compilers or operating systems) and the nature of the software development involves contractual agreements. The Waterfall Model is a natural fit for contract-based software development since this model is document driven; that is, many of the products such as the requirements specification and the design are documents. These documents then become the basis for the software development contract. According to Boehm, however, this model "does not work well for many classes of software, particularly interactive end-user applications." Specifying the requirements for such applications is notoriously difficult since interface design is highly subjective and clients rarely ever understand the real needs the software should meet. As a result, "document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decision-support functions, followed by the design and development of large quantities of unusable code" [Boehm 1988]. The problem is that a contract is signed before the real requirements of the system are properly understood. In addition to this shortcoming, the Waterfall model provides no means for risk assessment and management during the life cycle. Consider the case of the baggage-handling system at the Denver International Airport (DIA) again. Initially, DIA had intended that each individual airline would be responsible for building its own baggage-handling system. However, when American Airlines (AA) decided to use DIA as its second-largest hub airport, AA commissioned BAE Automatic Systems to develop an automated _________________________________________________________________ Software Project Management

16

Lesson 2: Software Processes __________________________________________________________________

baggage-handling system efficient enough to allow AA to turn aircraft around in under thirty minutes. As the construction of the airport progressed, a larger vision emerged "for the inclusion of an airport-wide integrated baggage-handling system that could provide a major improvement in the efficiency of luggage delivery." To accommodate the vision, DIA negotiated a new contract with BAE to develop the airport-wide baggage system. This new plan, however, "underestimated the high complexity of the expanded system, the newness of the technology, and the high level of coordination required among the entities housed at DIA that were to be served by the system" [Montealegre 1996]. Despite the enormous change in the specifications of the project, no one gave any thought to risk assessment. Had the developers considered the risks involved with changing the system requirements radically at a late stage of development, they may have concluded that the expanded plan was infeasible. In the end, DIA had to settle with a much less ambitious plan, and Montealegre reports "six months after the de-scaling of the system, the airport was able to open and operate successfully."

The Spiral Method In 1988, Barry Boehm proposed a more comprehensive life cycle model called the Spiral Model to address the inadequacies of the Waterfall Model. According to Boehm, "the major distinguishing feature of the Spiral Model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties" [Boehm 1988]. Software projects encompass many different areas of risk such as project cost overruns, changed requirements (e.g., the DIA baggage system), loss of key project personnel, delay of necessary hardware, competition from other software developers, technological breakthroughs that obsolete the project, and many others. The essential concept of the Spiral Model is "to minimize risks by the repeated use of prototypes [emphasis added] and other means. Unlike other models, at every stage risk analysis is performed... The Spiral Model works by building progressively more complete versions of the software by starting at the center of the spiral and working outwards. With each loop of the spiral, the customer evaluates the work and suggestions are made for its modification. Additionally, with each loop of the spiral, a risk analysis is performed which results in a 'go / no-go' decision. If the risks are determined to be too great then the project is terminated" [Frankovich 1998]. Thus, the Spiral Model addresses the problem of Software Project Management _________________________________________________________________

17 ___________________________________________________ Software Engineering: A Computer Science Approach

requirements engineering through development of prototypes, and it addresses the need for risk management by performing risk analysis at each step of the life cycle (See Appendix for details).

_________________________________________________________________ Software Project Management

Lesson 2: Software Processes __________________________________________________________________

In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].

Template Objectives

Explanation The goals of the software project

18

Example Phase Significantly improve software quality

Within three years Without large-scale capital investment Without radical change to company standards Reuse existing certified software Possible ways to achieve Alternatives Introduce formal specification and verification the objectives Invest in testing and validation tools No cost effective quality improvement possible Quality improvements may increase costs Potential risks for this Risks excessively phase New methods might cause existing staff to leave Literature survey, Pilot project, Survey of Risk Strategies for reducing potential reusable components, Assessment of Resolution the risks available tool support, Staff training and motivation seminars Experience of formal methods is limited - very hard to quantify improvements Results of applying risk Limited tool support available for company Results resolution strategies standard development system Reusable components available but little reuse tool support Explore reuse option in more detail Development plans for Plans Develop prototype reuse support tools the next phase Explore component certification scheme Commitment Resources needed to Fund further 18-month study phase Constraints

Limitations which the project must meet

Software Project Management _________________________________________________________________

___________________________________________________ Software Engineering: A Computer Science Approach achieve the plans

Spiral Model Template

In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff knows very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components. The model on Appendices illustrates how the eight management elements of the Spiral Model template are organized in each phase.

19

The final phase of the Spiral Model is analogous to the Waterfall Model. At this point in the project, the software requirements should be well understood through the development of several prototypes. The project should also have resolved the major risks involved with building the final version of the software. With these issues resolved, the detailed design of the software enters the last three processes of the Waterfall Model, and the software is created. Although some of the labels in the Spiral Model are different, the same processes are represented. The table below shows the correspondence between the final phase of the Spiral Model and the Waterfall model.

Waterfall Model

Spiral Model

Design Specifications

Detailed design

Programming

Code, Unit test

Integration

Integration and test

Delivery

Acceptance test, Implementation

Notice, however, that the maintenance process that appeared as dashed lines in the complete Waterfall Model seems to be missing from the Spiral Model. What happened to this process? Boehm _________________________________________________________________ Software Project Management

Lesson 2: Software Processes __________________________________________________________________

[1988] explains: "The answer to [this question] involves an observation that the spiral model applies equally well to development or [maintenance] efforts. In either case, the spiral gets started by a hypothesis that a particular operational mission could be improved by a software effort." Thus maintenance simply becomes another spiral or phase in the life cycle of the software. Like the previous phase, the maintenance efforts undergo risk assessment to evaluate whether changes are feasible.

EXERCISES 1. What is the software life cycle? 2. List the six processes of the software life cycle. 3. What is stepwise refinement and how does it help during the development of software? 4. Which process consumes the most resources during the life cycle? 5. What are the two important elements of the Waterfall Model? Explain why. 6. What are the seven products described by the Waterfall Model? 7. When is software testing performed in the Waterfall Model?

20

8. What is software verification? 9. What is software validation? 10.Explain the purpose of iteration in the Waterfall Model. 11.Which process is the only process that does not involve iteration? 12.When is the Waterfall Model an appropriate software life cycle model to use? 13.What major shortcoming of the Waterfall Model does the Spiral Model address? 14.How does the Spiral Model address the need of accurately determining the software requirements? 15.How does the management?

Spiral

Model

handle

Software Project Management _________________________________________________________________

the

need

for

risk

___________________________________________________ Software Engineering: A Computer Science Approach

16.What are the eight management elements of the Spiral Model? 17.How many spirals does the Spiral Model contain? 18.How does the Spiral Model represent maintenance? 19.Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems: a system to control anti-lock braking in a car; a virtual reality system to support software maintenance; a university accounting system that replaces an existing system; an interactive system for railway passengers that finds train times from terminals installed in stations. 20.Explain how both the waterfall model of the software process and the prototyping model can be accommodated in the spiral process model.

_________________________________________________________________ Software Project Management