Sources of standards

2.2 Sources of standards

It was stated in Section 2.1 that standards should cover as much of the overall SLC as is practical and appropriate for a given organization. That is clearly a large, as well as important, task. Certainly, in an organization of more than minimum size, it will involve more than just one or two persons. Even then, to create all the standards needed can be an overwhelming task and one that cannot be accomplished in a timely manner. The goal should be to identify the minimum set of standards that will serve the organization's actual needs and then identify the sources for those standards.

Software standards can come from many sources. The standards coordinator (or whoever has the responsibility for standards) can make use of some or any of the standards-acquisition means and sources. The three main standards-acquisition methods are as follows:

1. Developing them in-house;

2. Buying them from consultants or other similar organizations;

3. Adapting industry prepared and consensus-approved standards.

The three main standards sources are as follows:

1. External standards developers;

2. Purchased standards;

3. In-house development.

2.2.1 External standards developers

Standards can be found in several locations and are available from several sources. Some externally available standards are useful as starting points for an in-house standards program. Some are likely to be imposed as a condition of commerce with a particular business field or with other countries.

One advantage to the standards developed by the various industry and other groups is that they reflect the consensus of the groups involved. Several industry-segment points of view are usually represented so that a wide range of applications is available. Table 2.1 presents some typical standards subjects and representative external standards and sources applicable to them. The list is certainly not all-inclusive, but it does indicate the breadth of standards available.

Table 2.1: Representative Standards Sources

Major Subject	Specific Area	Standard Developer	Standard Number
Software life cycle	Life-cycle processes	IEEE ISO/IEC	1074, 1074.1 12207
	Project management	IEEE	1058
	Development	DoD IEEE ISO	498 1074 12207
	Reviews	IEEE NIST	1028, 1059 500-165
	Testing	IEEE NIST	829, 1008, 1012,1059 500-75, 500-165
	Quality program	IEEE AS ISO NRC	1298 3563.1, 3563.2 9000 et al NUREG/CR-4640
	Metrics	IEEE ISO/IEC	982.1, 982.2, 1044, 1044.1, 1045, 1061 9126
	Case tools	IEEE	1175, 1209, 1343
Documentation	Quality plans	IEEE IEEE/EIA	730, 730.1 1498/IS 640
	Requirements specifications	IEEE ISO/IEC	830 12207
	Design specifications	IEEE ISO/IEC	1016, 1016.11 12207
	User documentation	IEEE	1063
Naming	CM	IEEE EIA	1042, 828 649
User development	Software packages	ISO/IEC	12119

International standards Of increasing interest is the activity within the international sector with respect to software standards. The ISO has published what is called the 9000 series of standards (ISO 9000, 9001, 9002, 9003, 9004) dealing with quality. Standard 9001, "Quality Systems-Model for Quality Assurance in Design, Development, Production, Installation and Servicing," is the one most often applied to software development since it includes all aspects of product development from requirements control through measurements and metrics applied to the quality program and the control of the products. (The 2000 edition merges 9002 and 9003 into 9001.)

Written from a primarily manufacturing point of view, ISO 9001 has been difficult to relate to the software realm. Therefore, ISO subsequently added an annex to ISO 9000, called Part 3. This annex explains how the requirements of ISO 9001 can be applied to software. A working group of Standards Australia subsequently prepared AS 3563, which is a better interpretation of ISO 9001 for software.

More recently, the responsibility for 9000 Part 3 has been transferred to ISO/IEC JTC1/SC7 (JTC1), another international group dedicated to information technology standards. JTC1 includes several subcommittees that undertake the development of software standards. Organizations that do, or expect to do, business with countries other than their own, are well advised to seek out and comply with the tenets of the international standards. At the time of this writing, JTCl's subcommittee SC7 had published IS 12207 "Information Technology-Software Life Cycle Processes" and was working on several standards that will support 12207.

It is important to recognize that simply adhering to a process is no guarantee of quality if the process itself is flawed. For example, a concrete life preserver built to an established, fully ISO 9000-compliant and carefully followed process, would probably fail to garner customer kudos for its quality.

Industrial and professional groups Several industry and professional societies are developing generic standards that can be used as is or tailored as appropriate.

A number of professional and technical societies are increasingly active in the preparation of software standards. The IEEE and the Electronic Industries Association (EIA) have ongoing working groups addressing standards and guidelines in the software engineering area. The American National Standards Institute (ANSI) is the coordinating body for standards of all types within the United States. Another group becoming active in the software area is the American Society for Quality.

These, and other, groups are preparing generic software engineering standards that can be adopted as they are written or adapted by an individual organization. Many of them are also suitable for inclusion in software acquisition contracts, as well as in-house use.

Government agencies In addition to the previously mentioned groups, many software standards are available from various government agencies. In particular, the Department of Defense (DoD), the Nuclear Regulatory Agency, the National Institute of Standards and Technology (NIST), and various other governmental agencies are standards sources. As a large buyer of software, as well as a developer, the federal government has prepared and is still generating standards meant primarily for software acquisition contracts. These are frequently applicable, in whole or in part, to a specific organization's internal standards needs. The DoD recently declared its intention to cease active writing of its own standards and to adopt existing software standards.

Manufacturers' user groups Another source of software standards can be found in computer user groups. GUIDE International and SHARE (IBM), DECUS (DEC), and other major user groups often address the question of software standards as a part of their activities. The standards generated by these user groups are usually generic in nature. They are sometimes standalone, but frequently benefit from adaptation.

2.2.2 Purchased standards

Standards can be purchased and then adapted to the needs of a specific organization. Companies sometimes will provide their standards manuals to other, similar companies for a fee. This is especially true in industries in which there is a great deal of interaction or interfacing such as between telephone companies. Although there may be strong resistance to this in industries in which competition is strong, in general, most organizations are willing to share, even on an informal basis, their software standards in the interest of overall improvement in the software area. It must be remembered, though, that standards received from another company, no matter how similar, are specific to that company's specific situation and needs. Standards obtained in this way represent only a starting point for the standards effort in the receiving company.

Another avenue for purchased standards is through a consultant or consulting company. Many consultants will prepare a full set of software standards specific to a client company. This can be an easy way to get an initial set of the most critical standards in place quickly. The consultant can then continue the standards development effort or turn the rest of the task over to the client company. The advantage of this approach is rapid standards development, usually using the consultant's prior experience in the particular industry and software area. The main disadvantage is the perception of the consultant as an outsider who "doesn't really understand the situation." Involvement of the affected departments, as "internal consultants" to, or joint participants with, the real consultant can usually diminish this perception. In some cases, the consultant could even be used to gain acceptance of in-house-developed standards that were being resisted. However, paying an outside consultant to deliver standards, regardless of the actual source of those standards, sometimes lends undeserved value to them.

2.2.3 In-house development

Standards, from whatever external source, usually need to be adapted to the individual needs and environment of the specific organization or project. In-house development is the only way to assure that each standard reflects the organization's actual needs and environment. There are at least three major approaches to in-house standards development, in addition to an enormous number of variations and combinations. The three major approaches are as follows:

1. Ad hoc standardization;

2. Standards groups;

3. Standards committees.

Ad hoc standardization Any of the SLC staff may be assigned, as an additional but temporary part of their job, the responsibility and authority to create and institute software standards. Since the affected staff is involved with various parts of the entire life cycle of all projects, they have a high degree of insight into the SLC and its standardization needs. They can become aware of areas and tasks that need standardization, observe the various methods in use, and propose the most appropriate methods as candidates to be standards. As the monitor of SLC activities, the software quality practitioner is in the proper position to determine the appropriateness of the standard once it is in use.

An advantage of ad hoc standardization is that the experts in the area being standardized can be called on to write-and to follow-the standard. A disadvantage is that the writers may not be aware of side issues or potential conflicts with other standards. The "corporate memory" of the continuity and consistency of the standards program may also be lost.

In general, it is not recommended that the software quality practitioner write standards. That role could place practitioners in the position of imposing standards on tasks and activities that they themselves do not perform. For example, the software quality practitioner does little coding, rarely operates the data center, and usually does not perform data entry.

Standards groups A second method of in-house development is through a separately chartered standards group (SG). Since the SG has, as its whole task, the management of the body of standards, it can often spend more time researching a standard or looking to outside sources for a particular standard. The advantage of having an SG is maintaining the continuity and corporate memory of the standards program.

The SG, however, suffers the same disadvantage as the software quality practitioner-standardizing from outside a task or activity. That is, the SG members usually are not in a position to follow the standards they create. In addition, an SG usually does not have the insight available to the software quality practitioner as to needed standards or standards appropriateness.

Standards committees The third major approach to standards development is the chartering of a standards committee (SC). Usually the SC comprises the managers of each department in the data processing organization: applications development, operations, systems programming, and so on, as shown in Figure 2.4. The SC is responsible for identifying needed standards and those requiring modification or replacement. The specific generation of a standard is assigned to the manager of that department that will be most affected by the standard-language standard to applications development, database definition standard to database administration, and so on. The advantage of this approach is that the most knowledgeable and affected department prepares the standard with inputs from all other interested departments. The disadvantage is the usually difficult task of involving the actual department managers so that full departmental visibility is ensured.

Figure 2.4: Standards committee.

Standards coordinator In any of the previously mentioned approaches, or combinations thereof, a specific person should have the job of ensuring that needed standards are identified, created, and followed. That person, the standards coordinator, may be a software quality practitioner, manager of the SG, or chairperson of the SC. The important matter is that he or she has the ear of the software quality practitioner or upper management to ensure that standards receive the attention they merit and require.

It is the role of the standards coordinator to ascertain the standards requirements for each installation and situation and then arrange for those needed standards to be available, invoked, and followed. As is the case with the software quality practitioner, the standards coordinator usually should not prepare the standards.

It is the responsibility of the standards coordinator to provide standards as needed and monitor compliance with them. It is the role and responsibility of everyone in the organization to identify potential standards needs and adhere to those standards that have been applied. It is the role of management to enforce the application of and compliance with the implemented standards.