SOLUTION
SIDEBAR 1.2 PERSPECTIVES ON QUALITY
1.6 AN ENGINEERING APPROACH
Section 1.6 An Engineering Approach 21 approach may incorporate a series of stages, each of which frees the previous system from another such constraint. For example, stage 1 may add a new piece of hardware, stage 2 may replace the software performing a particular set of functions, and so on.The system is slowly drawn away from old software and hardware until it reflects the new system design.
Thus, system development can first incorporate a set of changes to an actual sys- tem and then add a series of changes to generate a complete design scheme, rather than trying to jump from present to future in one move. With such an approach, we must view the system in two different ways simultaneously: statically and dynamically. The static view tells us how the system is working today, whereas the dynamic view shows us how the system is changing into what it will eventually become. One view is not com- plete without the other.
test the wiring circuits, plumbers make sure that pipes do not leak, and carpenters adjust for variation in wood so that the floors are smooth and level. Finally, the Howells move in. If there is something that is not constructed properly, McMullen may be called in to fix it, but eventually the Howells become fully responsible for the house.
Let us look more closely at what is involved in this process. First, since many people are working on the house at the same time, documentation is essential. Not only are floor plans and the architect’s drawings necessary, but details must be written down so that specialists such as plumbers and electricians can fit their products together as the house becomes a whole.
Second, it is unreasonable to expect the Howells to describe their house at the beginning of the process and walk away until the house is completed. Instead, the How- ells may modify the house design several times during construction. These modifica- tions may result from a number of situations:
• Materials that were specified initially are no longer available. For example, certain kinds of roof tiles may no longer be manufactured.
• The Howells may have new ideas as they see the house take shape. For example, the Howells might realize that they can add a skylight to the kitchen for little additional cost.
• Availability or financial constraints may require the Howells to change require- ments in order to meet their schedule or budget. For example, the special windows that the Howells wanted to order will not be ready in time to complete the house by winter, so stock windows may be substituted.
• Items or designs initially thought possible might turn out to be infeasible. For example, soil percolation tests may reveal that the land surrounding the house can- not support the number of bathrooms that the Howells had originally requested.
McMullen may also recommend some changes after construction has begun, perhaps because of a better idea or because a key member of the construction crew is unavail- able. And both McMullen and the Howells may change their minds about a feature of the house even after the feature is completed.
Third, McMullen must provide blueprints, wiring and plumbing diagrams, instruc- tion manuals for the appliances, and any other documentation that would enable the Howells to make modifications or repairs after they move in.
We can summarize this construction process in the following way:
• determining and analyzing the requirements
• producing and documenting the overall design of the house
• producing detailed specifications of the house
• identifying and designing the components
• building each component of the house
• testing each component of the house
• integrating the components and making final modifications after the residents have moved in
• continuing maintenance by the residents of the house
Section 1.6 An Engineering Approach 23 We have seen how the participants must remain flexible and allow changes in the origi- nal specifications at various points during construction.
It is important to remember that the house is built within the context of the social, economic, and governmental structure in which it is to reside. Just as the water- monitoring system in Figure 1.10 depicted the dependencies of subsystems, we must think of the house as a subsystem in a larger scheme. For example, construction of a house is done in the context of the city or county building codes and regulations. The McMullen employees are licensed by the city or county, and they are expected to per- form according to building standards.The construction site is visited by building inspec- tors, who make sure that the standards are being followed. And the building inspectors set standards for quality, with the inspections serving as quality assurance checkpoints for the building project. There may also be social or customary constraints that suggest common or acceptable behavior; for example, it is not customary to have the front door open directly to the kitchen or bedroom.
At the same time, we must recognize that we cannot prescribe the activities of build- ing a house exactly; we must leave room for decisions based on experience, to deal with unexpected or nonstandard situations. For example, many houses are fashioned from pre- existing components; doors are supplied already in the frame, bathrooms use pre-made shower stalls, and so on. But the standard house-building process may have to be altered to accommodate an unusual feature or request. Suppose that the framing is done, the dry- wall is up, the subfloor is laid, and the next step is putting down tile on the bathroom floor.
The builders find, much to their dismay, that the walls and floor are not exactly square.
This problem may not be the result of a poor process; houses are built from parts that have some natural or manufacturing variation, so problems of inexactitude can occur.The floor tile, being composed of small squares, will highlight the inexactitude if laid the standard way. It is here that art and expertise come to play. The builder is likely to remove the tiles from their backing, and lay them one at a time, making small adjustments with each one so that the overall variation is imperceptible to all but the most discerning eyes.
Thus, house building is a complex task with many opportunities for change in pro- cesses, products, or resources along the way, tempered by a healthy dose of art and expertise. The house-building process can be standardized, but there is always need for expert judgment and creativity.
Building a System
Software projects progress in a way similar to the house-building process. The Howells were the customers and users, and McMullen was the developer in our example. Had the Howells asked McMullen to build the house for Mr. Howell’s parents to live in, the users, customers, and developer would have been distinct. In the same way, software development involves users, customers, and developers. If we are asked to develop a software system for a customer, the first step is meeting with the customer to determine the requirements. These requirements describe the system, as we saw before. Without knowing the boundary, the entities, and the activities, it is impossible to describe the software and how it will interact with its environment.
Once requirements are defined, we create a system design to meet the specified requirements. As we will see in Chapter 5, the system design shows the customer what
the system will look like from the customer’s perspective. Thus, just as the Howells looked at floor plans and architect’s drawings, we present the customer with pictures of the video display screens that will be used, the reports that will be generated, and any other descriptions that will explain how users will interact with the completed system.
If the system has manual backup or override procedures, those are described as well.At first, the Howells were interested only in the appearance and functionality of their house; it was not until later that they had to decide on such items as copper or plastic pipes. Likewise, the system design (also called architectural) phase of a software project describes only appearance and functionality.
The design is then reviewed by the customer. When approved, the overall system design is used to generate the designs of the individual programs involved. Note that it is not until this step that programs are mentioned. Until functionality and appearance are determined, it often makes no sense to consider coding. In our house example, we would now be ready to discuss types of pipe or quality of electrical wiring. We can decide on plastic or copper pipes because now we know where water needs to flow in the structure. Likewise, when the system design is approved by all, we are ready to dis- cuss programs. The basis for our discussion is a well-defined description of the software project as a system; the system design includes a complete description of the functions and interactions involved.
When the programs have been written, they are tested as individual pieces of code before they can be linked together. This first phase of testing is called module or unit testing. Once we are convinced that the pieces work as desired, we put them together and make sure that they work properly when joined with others. This second testing phase is often referred to as integration testing, as we build our system by adding one piece to the next until the entire system is operational. The final testing phase, called system testing, involves a test of the whole system to make sure that the functions and interactions specified initially have been implemented properly. In this phase, the system is compared with the specified requirements; the developer, cus- tomer, and users check that the system serves its intended purpose.
At last, the final product is delivered. As it is used, discrepancies and problems are uncovered. If ours is a turnkey system, the customer assumes responsibility for the sys- tem after delivery. Many systems are not turnkey systems, though, and the developer or other organization provides maintenance if anything goes wrong or if needs and requirements change.
Thus, development of software includes the following activities:
• requirements analysis and definition
• system design
• program design
• writing the programs (program implementation)
• unit testing
• integration testing
• system testing
• system delivery
• maintenance
Section 1.7 Members of the Development Team 25 In an ideal situation, the activities are performed one at a time; when you reach the end of the list, you have a completed software project. However, in reality, many of the steps are repeated. For example, in reviewing the system design, you and the cus- tomer may discover that some requirements have yet to be documented.You may work with the customer to add requirements and possibly redesign the system. Similarly, when writing and testing code, you may find that a device does not function as described by its documentation. You may have to redesign the code, reconsider the sys- tem design, or even return to a discussion with the customer about how to meet the requirements. For this reason, we define a software development process as any description of software development that contains some of the nine activities listed before, organized so that together they produce tested code. In Chapter 2, we will explore several of the different development processes that are used in building software. Subse- quent chapters will examine each of the subprocesses and their activities, from require- ments analysis through maintenance. But before we do, let us look at who develops software and how the challenge of software development has changed over the years.