| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
5. A SYSTEMS APPROACH The projects we develop do not exist in a vacuum. Often, the hardware and software we put together must interact with users, with other software tasks, with other pieces of hardware, with existing databases (i.e., with carefully defined sets of data and data relationships), or even with other computer systems. Therefore, it is important to provide a context for any project by knowing the boundaries of the project: what is included in the project and what is not. For example, suppose you are asked by your supervisor to write a program to print paychecks for the people in your office. You must know whether your program simply reads hours worked from another system and prints the results or whether you must also calculate the pay information. Similarly, you must know whether the program is to calculate taxes, pensions, and benefits or whether a report of these items is to be provided with each paycheck. What you are really asking is: Where does the project begin and end? The same question applies to any system. A system is a collection of objects and activities, plus a description of the relationships that tie the objects and activities together. Typically, our system definition includes, for each activity, a list of inputs required, actions taken, and outputs produced. Thus, to begin, we must know whether any object or activity is included in the system or not. The Elements of a System We describe a system by naming its parts and then identifying how the component parts are related to one another. This identification is the first step in analyzing the problem presented to us. Activities and Objects. First, we distinguish between activities and objects. An activity is something that happens in a system. Usually described as an event initiated by a trigger, the activity transforms one thing to another by changing a characteristic. This transformation can mean that a data element is moved from one location to another, is changed from one value to another, or is combined with other data to supply input for yet another activity. For example, an item of data can be moved from one file to another. In this case, the characteristic changed is the location. Or the value of the data item can be incremented. Finally, the address of the data item can be included in a list of parameters with the addresses of several other data items so that another routine can be called to handle all the data at once. The elements involved in the activities are called objects or entities. Usually, these objects are related to each other in some way. For instance, the objects can be arranged in a table or matrix. Often, objects are grouped as records, where each record is arranged in a prescribed format. An employee history record, for example, may contain objects (called fields) for each employee, such as the following: First name: Postal code Middle name: Salary per hour Last name: Benefits per hour Street address: Vacation hours accrued City: Sick leave accrued State Not only is each field in the record defined, but the size and relationship of each field to the others are named. Thus, the record description states the data type of each field, the starting location in the record, and the length of the field. In turn, since there is a record for each employee, the records are combined into a file, and file characteristics (such as maximum number of records) may be specified. Sometimes, the objects are defined slightly differently. Instead of considering each item as a field in a larger record, the object is viewed as being independent. The object description contains a listing of the characteristics of each object, as well as a list of all the actions that can take place using the object or affecting the object. For example, consider the object “polygon.” An object description may say that this object has characteristics such as number of sides and length of each side. The actions may include calculation of the area or of the perimeter. There may even be a characteristic called “polygon type,” so that each instantiation of “polygon” is identified when it is a “rhombus” or “rectangle,” for instance. A type may itself have an object description; “rectangle” may be composed of types “square” and “not square,” for example. We will explore these concepts in Section 4 when we investigate requirements analysis, and in depth in Section 6 when we discuss object-oriented development. Relationships and the System Boundary. Once entities and activities are defined, we match the entities with their activities. The relationships among entities and activities are clearly and carefully defined. An entity definition includes a description of where the entity originates. Some items reside in files that already exist; others are created during some activity. The entity’s destination is important, too. Some items are used by only one activity, but others are destined to be input to other systems. That is, some items from one system are used by activities outside the scope of the system being examined. Thus, we can think of the system at which we are looking as having a border or boundary. Some items cross the boundary to enter our system, and others are products of our system and travel out for another system’s use. Using these concepts, we can define a system as a collection of things: a set of entities, a set of activities, a description of the relationships among entities and activities, and a definition of the boundary of the system. This definition of a system applies not only to computer systems but to anything in which objects interact in some way with other objects. ===
=== Examples of Systems. To see how system definition works, consider the parts of you that allow you to take in oxygen and excrete carbon dioxide and water: your respiratory system. You can define its boundary easily: If you name a particular organ of your body, you can say whether or not it is part of your respiratory system. Molecules of oxy gen and carbon dioxide are entities or objects moving through the system in ways that are clearly defined. We can also describe the activities in the system in terms of the interactions of the entities. If necessary, we can illustrate the system by showing what enters and leaves it; we can also supply tables to describe all entities and the activities in which they are involved. FIG. 8 illustrates the respiratory system. Note that each activity involves the entities and can be defined by describing which entities act as input, how they are processed, and what is produced (output). We must describe our computer systems clearly, too. We work with prospective users to define the boundary of the system: Where does our work start and stop? In addition, we need to know what is on the boundary of the system and thus determine the origins of the input and destinations of the output. For example, in a system that prints paychecks, pay information may come from the company’s computer. The system out put may be a set of paychecks sent to the mail room to be delivered to the appropriate recipients. In the system shown in FIG. 9, we can see the boundary and can under stand the entities, the activities, and their relationships. Interrelated Systems The concept of boundary is important, because very few systems are independent of other systems. For example, the respiratory system must interact with the digestive system, the circulatory system, the nervous system, and others. The respiratory system could not function without the nervous system; neither could the circulatory system function without the respiratory system. The interdependencies may be complex. (Indeed, many of our environmental problems arise and are intensified because we do not appreciate the complexity of our ecosystem.) However, once the boundary of a system is described, it is easier for us to see what is within and without and what crosses the boundary.
In turn, it is possible for one system to exist inside another system. When we de scribe a computer system, we often concentrate on a small piece of what is really a much larger system. Such a focus allows us to define and build a much less complex system that the enveloping one. If we are careful in documenting the interactions among and be tween systems affecting ours, we lose nothing by concentrating on this smaller piece of a larger system. Let us look at an example of how this can be done. Suppose we are developing a water-monitoring system where data are gathered at many points throughout a river valley. At the collection sites, several calculations are done, and the results are communicated to a central location for comprehensive reporting. Such a system may be implemented with a computer at the central site communicating with several dozen smaller computers at the remote locations. Many system activities must be considered, including the way the water data are gathered, the calculations performed at the remote locations, the communication of information to the central site, the storage of the communicated data in a database or shared data file, and the creation of reports from the data. We can view this system as a collection of systems, each with a special purpose. In particular, we can consider only the communications aspect of the larger system and develop a communications system to transmit data from a set of remote sites to a central one. If we carefully define the boundary between the communications and the larger system, the design and development of the communications system can be done independently of the larger system. The complexity of the entire water monitoring system is much greater than the complexity of the communications system, so our treatment of separate, smaller pieces makes our job much simpler. If the boundary definitions are detailed and correct, building the larger system from the smaller ones is relatively easy. We can describe the building process by considering the larger system in layers, as illustrated in FIG. 10 for our water-monitoring example. A layer is a system by itself, but each layer and those it contains also form a system. The circles of the figure represent the boundaries of the respective systems, and the entire set of circles incorporates the entire water-monitoring system. Recognizing that one system contains another is important, because it reflects the fact that an object or activity in one system is part of every system represented by the outer layers. Since more complexity is introduced with each layer, understanding any one object or activity becomes more difficult with each more-encompassing system. Thus, we maximize simplicity and our consequent understanding of the system by focusing on the smallest system possible at first. We use this idea when building a system to replace an older version, either manual or automated. We want to understand as much as possible about how both the old and new systems work. Often, the greater the difference between the two systems, the more difficult the design and development. This difficulty occurs not only because people tend to resist change, but also because the difference makes learning difficult. In building or synthesizing our grand system, it helps dramatically to construct a new system as an incremental series of intermediate systems. Rather than going from system A to system B, we may be able to go from A to A’ to A” to. B. For example, suppose A is a manual system consisting of three major functions, and B is to be an automated version of A. We can define system A’ to be a new system with function 1 automated but functions 2 and 3 still manual. Then A” has automated functions 1 and 2, but 3 is still manual. Finally, B has all three automated functions. By dividing the “distance” from A to B in thirds, we have a series of small problems that may be easier to handle than the whole. In our example, the two systems are very similar; the functions are the same, but the style in which they are implemented differs. However, the target system is often vastly different from the existing one. In particular, it is usually desirable that the target be free of constraints imposed by existing hardware or software. An incremental development 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 hard ware, 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 tern 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 complete without the other. 6. AN ENGINEERING APPROACH Once we understand the system’s nature, we are ready to begin its construction. At this point, the “engineering” part of software engineering becomes relevant and complements what we have done so far. Recall that we began this section by acknowledging that writing software is an art as well as a science. The art of producing systems involves the craft of software production. As artists, we develop techniques and tools that have proven helpful in producing useful, high-quality products. For instance, we may use an optimizing compiler as a tool to generate programs that run fast on the machines we are using. Or we can include special sort or search routines as techniques for saving time or space in our system. These software-based techniques are used just as techniques and tools are used in crafting a fine piece of furniture or in building a house. Indeed, a popular collection of programming tools is called the Programmer’s Workbench, because programmers rely on them as a carpenter relies on a workbench. Because building a system is similar to building a house, we can look to house building for other examples of why the “artistic” approach to software development is important. Building a House Suppose Chuck and Betsy Howell hire someone to build a house for them. Because of its size and complexity, a house usually requires more than one person on the construction team; consequently, the Howells hire McMullen Construction Company. The first event involved in the house building is a conference between the Howells and Mc Mullen so the Howells can explain what they want. This conference explores not only what the Howells want the house to look like, but also what features are to be included. Then McMullen draws up floor plans and an architect’s rendering of the house. After the Howells discuss the details with McMullen, changes are made. Once the Howells give their approval to McMullen, construction begins. During the construction process, the Howells are likely to inspect the construction site, thinking of changes they would like. Several such changes may occur during construction, but eventually the house is completed. During construction and before the Howells move in, several components of the house are tested. For example, electricians test the wiring circuits, plumbers make sure that pipes do not leak, and carpenters ad just 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 be ginning 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 modifications 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 requirements 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 ex ample, 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 be cause of a better idea or because a key member of the construction crew is unavailable. 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, instruction 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 making final modifications after the residents have moved in • continuing maintenance by the residents of the house We have seen how the participants must remain flexible and allow changes in the original 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 FIG. 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 perform according to building standards. The construction site is visited by building inspectors, 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 building 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 drywall 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 in exactitude 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 processes, 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 soft ware 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 Section 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 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 discuss 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 com pared with the specified requirements; the developer, customer, 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 system 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 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 customer 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 system 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 Section 2, we will explore several of the different development processes that are used in building software. Subsequent sections will ex amine each of the subprocesses and their activities, from requirements 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. 7. MEMBERS OF THE DEVELOPMENT TEAM Earlier in this section, we saw that customers, users, and developers play major roles in the definition and creation of the new product. The developers are software engineers, but each engineer may specialize in a particular aspect of development. Let us look in more detail at the role of the members of the development team. The first step in any development process is finding out what the customer wants and documenting the requirements. As we have seen, analysis is the process of breaking things into their component parts so that we can understand them better. Thus, the development team includes one or more requirements analysts to work with the customer, breaking down what the customer wants into discrete requirements. Once the requirements are known and documented, analysts work with designers to generate a system-level description of what the system is to do. In turn, the designers work with programmers to describe the system in such a way that programmers can write lines of code that implement what the requirements specify. After the code is generated, it must be tested. Often, the first testing is done by the programmers themselves; sometimes, additional testers are also used to help catch faults that the programmers overlook. When units of code are integrated into functioning groups, a team of testers works with the implementation team to verify that as the system is built up by combining pieces, it works properly and according to specification. When the development team is comfortable with the functionality and quality of the system, attention turns to the customer. The test team and customer work together to verify that the complete system is what the customer wants; they do this by comparing how the system works with the initial set of requirements. Then, trainers show users how to use the system. For many software systems, acceptance by the customer does not mean the end of the developer’s job. If faults are discovered after the system has been accepted, a maintenance team fixes them. Moreover, the customer’s requirements may change as time passes, and corresponding changes to the system must be made. Thus, maintenance can involve analysts who determine what requirements are added or changed, designers to determine where in the system design the change should be made, programmers to implement the changes, testers to make sure that the changed system still runs properly, and trainers to explain to users how the change affects the use of the system. FIG. 11 illustrates how the roles of the development team correspond to the steps of development. Students often work by themselves or with small groups as a development team for class projects. The documentation requested by the instructor is minimal; students are usually not required to write a user manual or training documents. Moreover, the assignment is relatively stable; the requirements do not change over the life of the project. Finally, student-built systems are likely to be discarded at the end of the course; their purpose is to demonstrate ability but not necessarily to solve a problem for a real customer. Thus, program size, system complexity, need for documentation, and need for maintainability are relatively small for class projects.
However, for a real customer, the system size and complexity may be large and the need for documentation and maintainability great. For a project involving many thou sands of lines of code and much interaction among members of the development team, control of the various aspects of the project may be difficult, To support everyone on the development team, several people may become involved with the system at the beginning of development and remain involved throughout. Librarians prepare and store documents that are used during the life of the system, including requirements specifications, design descriptions, program documentation, training manuals, test data, schedules, and more. Working with the librarians are the members of a configuration management team. Configuration management involves maintaining a correspondence among the requirements, the design, the implementation, and the tests. This cross reference tells developers what program to alter if a change in requirements is needed, or what parts of a program will be affected if an alteration of some kind is proposed. Configuration management staff also coordinate the different versions of a system that may be built and supported. For example, a software system may be hosted on different platforms or may be delivered in a series of releases. Configuration management ensures that the functionality is consistent from one plat form to another, and that it doesn’t degrade with a new release. The development roles can be assumed by one person or several. For small projects, two or three people may share all roles. However, for larger projects, the development team is often separated into distinct groups based on their function in development. Sometimes, those who maintain the system are different from those who design or write the system initially. For a very large development project, the customer can even hire one company to do the initial development and another to do the maintenance. As we discuss the development and maintenance activities in later sections, we will look at what skills are needed by each type of development role. |
