Additional issues

1.3 Additional issues

Several other issues can, and will, impact the scope and authority of the software quality system. These include maintaining the software once it is in operation, documenting the software's development and configuration, deciding where to place the software quality practitioners within the overall organization, and the concerns of implementing the quality system.

1.3.1 Maintenance

Software maintenance can best be viewed and treated as an extension or repetition of the development process.

Software maintenance includes two primary activities: correction of defects that were not found during development and testing, and enhancement of the software to meet new or changed requirements after installation. As suggested in Figure 1.8, each maintenance action or project is treated in much the same way as original development, and the parallels with the SDLC can be seen. The maintenance process begins with identifying the need for a change. The occurrence of a failure due to a previously unencountered defect will trigger a change. New requirements may come from user requests; the need for increased throughput in the data center; a change in processing technology, such as moving from mainframes to a client-server approach; or just the desire to reengineer old legacy code.

Figure 1.8: Recycling the life cycle.

Whatever the reason for the change, effort is expended to determine exactly what will be needed (concept definition and requirements specification); how the change will be affected (design); the actual creation of the new or modified software (code and unit test); and the testing, approval, and installation of the change (integration, testing, and installation). Thus, in almost all cases (there are exceptions to most rules), maintenance can be seen primarily as a return to the regular SDLC activities, though usually on a smaller scale.

It is important to note the need for rigorous CM during the maintenance phase. Especially during periods of rapid change, such as might be found during the modification of software to address new government regulations, or the introduction of a new weapon system in a combat vehicle, there is significant danger of making changes to the wrong version of a module or subsystem. If multiple changes are being made simultaneously, as is often the case, one change may unknowingly affect another. In today's world of the Internet, World Wide Web, and e-commerce, changes are not only necessarily very rapid but also very visible. Errors may be seen or experienced by hundreds or even thousands of on-line users in the space of a short time.

CM must be part and parcel of changes in this environment, and the software quality practitioner must take an aggressive role in confirming that all CM procedures are being followed. This is in addition to the software quality practitioner's regular monitoring role in all software development activities, whether original development or maintenance.

1.3.2 Documentation

The purpose of documentation is to record what is required of the software, how it is to be accomplished, proof that it was provided, and how to use and maintain it. The role of the software quality practitioner is to monitor the documentation activities and keep management apprised of their status and quality.

It is like the old adage, if you don't know where you're going, any road will take you there (but it doesn't matter, because you won't realize that you've arrived, anyway). Without adequate documentation, the task at hand is never accurately specified. What is really wanted is not made clear. The starting and ending points are poorly specified, and no one is sure when the project is complete. Inadequate documentation is like not knowing where you are going. The system designers are not sure what the customer or user really wants, the programmer is not sure what the designer intends, and the tester is not sure what to look for. Finally, the customer or user is not sure that they got what they wanted in the first place.

The depth of the documentation depends on the scope of the specific project. Small projects can be successful with reduced documentation requirements. But, as the size of the project increases, the need for more complete documentation also increases. In the case of small or uncomplicated projects, the information contained in some documents can be provided in higher-level documents. As system size increases, additional documents may be needed to adequately cover such topics as interfaces and data design. More comprehensive test documentation will also be required such as specific test plans, cases, and reports.

Too much documentation can be as bad as too little. Overdocumentation can induce a user to say, "I'm not going to read all that!" The time spent documenting a project is wasted if the documentation does not add to the required body of knowledge about the project. Overdocumentation can introduce inconsistencies, conflicting information, and other kinds of defects that detract from performance in the long run.

Documentation should be sufficient to accurately and completely tell what to do (concept and requirements), how to do it (plan and design), how to show that it was done (test), and how to use the system (user). The software quality practitioner monitors and reviews the documentation to see that it satisfies this need.

1.3.3 Organizational considerations

The placement of the software quality practitioner or group within the organization is a critical factor in its effectiveness.

While there are several acceptable structures, each dependent on the specific total business organization, there are certain conditions that must be observed to enable the SQS to be effective. Figure 1.9 depicts several possible organizational reporting arrangements. Each has its merits and faults, which will be explored in Chapter 11.

Figure 1.9: Traditional organizational styles.

It is important to note that, in some companies, the SQS functions and activities may not be under the auspices of a formal software quality group at all. Remembering that the SQS functions are to be carried out by those parts of the organization best qualified to perform them, there are some companies that stop at that point and have various managers responsible for individual SQS functions. This approach would seem to have some economies connected with it, since there is not the cost of a dedicated staff just for software quality. However, the coordination among the various responsible managers may, in fact, be time-consuming enough to actually cost more than a software quality group. In addition, when a manager has an assignment such as the development of a new software system, and some ancillary tasks such as documentation coordination, CM, training, security, or software quality, the development task usually gets the bulk of the manager's attention, and other tasks may be given less attention or effort.

Software quality is, as has been said frequently, everyone's individual responsibility. Each participant in the SLC is expected to do his or her job correctly. Unfortunately, this is often an unachieved goal. Software quality tasks, then, must be assigned to the group or individual who can, and will, be accountable for the assessment of, and reporting on, the quality of the software throughout its life cycle.

1.3.4 Implementation of the total software quality system

Implementation of a software quality system requires a delegation of authority (a charter to perform the activities), cooperation of the organization (which is usually gained through demonstration of usefulness over time), and order (a logical progression of steps leading to the actual application and performance of the SQS activities).

No activity should be started until a formal charter of responsibilities, accountabilities, and authority vested in the SQS is created and assigned to the software quality practitioner or group by management. This, however, only creates the SQS. It does not establish the set of functions and activities that must be performed, nor the order in which they will be inaugurated. The software quality practitioners themselves must plan, design, and implement the overall SQS.

The four major elements in a successful software quality system are the quality culture of "do it right the first time," a quality charter that specifies the responsibilities and authorities of each person with respect to quality, a software quality manual that details the various components of the organization's SQS, and the SQS standards and procedures themselves. Table 1.1 shows how the various affected parts of the organization must contribute to the elements for the institution of an effective and acceptable SQS.

Table 1.1: Key Software Quality Roles

Senior Management	SQS Program Element	Technical Personnel
Insist upon	Culture	Input to
Commit to	Charter	Input to
Input to	Manual	Input to
Fully support	Total SQS	Cooperate with

One very important aspect of the whole process is the continued involvement of the development group from the very beginning. As each part of the SQS is conceived and planned, the quality charter established, the quality manual prepared, and the SQS implemented, the involvement of the producers will help to assure their acceptance and cooperation. Their participation, from the beginning, reduces the elements of surprise and, sometimes, distrust on the part of those whose work is the subject of the software quality activities.

Management, too, must be kept fully apprised of the activities and progress of the implementation of the SQS. They have provided the initial impetus for the SQS with their insistence on the concept of an organizational culture based on quality. Next, they have started the process through their demonstrated commitment to the quality charter. Continued support for the effort depends on their continued belief that an SQS will be beneficial in the long run. By maintaining close contact with management during the startup period, potential future pitfalls can be recognized and avoided.

Finally, a logical implementation plan must be worked out and accepted by all affected groups and by management. The needs of the various groups and their priorities must be reflected in the actual implementation schedule.

In the final analysis, the startup of the SQS closely resembles the creation of a software system. Each part of the SDLC is paralleled and each must be carefully addressed. Most of all, however, all affected organizations should be a party to the planning, design, and implementation of the SQS.