Who Develops Standards?
People frequently ask how they can get copies of standards, get to review them, even get to submit standards. The first thing to understand is who develops standards and how they get developed. Understanding the process makes it easier to understand how one gains access to standards and to their review/creation. The short answer to gaining access to standards for use is that "it depends." Some standards are in the public domain, but most require paying some fee to the standards development body which holds the copyright on the completed work, usually to cover the cost of administering the standards work and, of course, publishing and distributing them. But, the place to begin is an explanation of who generates standards and how the process of creation, review, and acceptance is conducted.
The major sources of software quality and process standards are:
- the IEEE’s Software & Systems Engineering Standards Committee (S2ESC)
- the ISO/IEC JTC1/SC7 Working Groups & national bodies (like the US SC7 TAG or Technical Advisory Group)
- Government agencies (e.g., in the USA, the Department of Defense, the Food and Drug Administration, the Department of Energy)
- Industry consortia (e.g., automotive, aerospace, telecom).
The first two generally address standards that are generic to all software development domains, though the very nature of some standards focuses on larger, more complex, and potentially safety/mission critical systems development. But, in general, the work coming out of the IEEE's S2ESC and ISO/IEC's JTC1/SC7 organization can be applied to just about any software development effort as the standards try to avoid domain-specific content. Government agencies and industry consortia tend to focus on domain-specific standards that are often adaptations of or extensions to standards developed by the IEEE or ISO.
There is a second level in answering the question of who creates standards, especially for the S2ESC and SC7: what companies, agencies, etc., participate? For government agencies and industry consortia, it is relatively clear who might participate and participation might even have certain restrictions related to demonstration of one's critical involvement in the area of the standard(s). The S2ESC and SC7 organizations are more "public" in that almost any organization can become involved, including government agencies and industry consortia. So who does, typically, get involved?
When it comes to product standards, many major computer manufacturers and software development organizations may participate since the standards directly affect their ability to create software that functions in a production setting. Again, this is because of the "requirements" nature of product standards. However, when it comes to software quality and process standards, there is a dramatic shift in participation. For process standards there is significant representation from those who create contracted, custom software with regulatory implications (e.g., telecom, aerospace, medical), including both customers and suppliers of such software. Therefore, government agencies are often participants in quality and process standards along with those who contract with such agencies.
In the case of both software product and quality/process standards, companies who do not sell software or software services rarely participate in such standards work, though their business and the products/services they do sell may be totally dependent on software. Surprisingly, manufacturing organizations whose products and/or manufacturing and test equipment have substantial software included with them are absent from most software quality and process standards activity. Certain industries where there is a substantial safety/mission-critical role played by software (e.g., automotive, aerospace, telecom) may participate. But in some domains, even those with otherwise extensive quality efforts in their own product design and manufacturing areas, may not involve quality departments much in the acquisition and acceptance of software.
What does it take to participate in standards development?
One factor which can discourage some from becoming involved in standards development is what is required to become involved. Formal participation requires time and money to:
- attend several meetings per year (domestically and perhaps abroad),
- read, contribute to, and review standards,
- provide consensus opinion from one's organization.
Some standards bodies levy an annual dues to be a member and formally require the membership to be through an organization/company which sends representatives to the meetings. Thus, individuals cannot, conveniently, become members of many standards bodies unless they are designated as a company's official representative.
A typical example of one such situation is the US SC7 TAG of which the ASQ SW Division is a member. There are annual dues levied on each organization and an organization must formally apply to the TAG for membership. Usually they must attend an initial meeting where their membership is approved and then, at the next meeting, they become a full voting member. Member companies are asked to supply a main representative and, at least, one alternate who can fill in if the main representative cannot attend a meeting or address ballots during some period of time. All representatives may attend all TAG meetings, but an organization is permitted only one vote.
The US TAG currently has two required meetings per year. In addition, some organizations also choose to support their representatives' participation in international meetings. The SC7 has one annual international plenary meeting. International work groups may hold one or two more meetings besides working at the plenary. Thus, a commitment to fully participate at all levels in ISO/IEC JTC1/SC7 work can involve over five meetings per year.
Of course, the expense of active participation in standards work is usually considerably more than the dues and travel expenses required. The time away from other work often means that representatives must have software quality and process standards activities be a formal part of their job descriptions. Therefore, unless an organization deems the standards to be critical to their marketplace, the cost justification for participation may simply not be possible. It may also be the case that, when a dedicated company representative changes assignments or moves to some other company, the member company may drop out of the standards work since the momentum to participate was largely the representative's personal interest in standards work.
How are standards bodies structured?
The answer to this question can be as varied as the number of standards bodies. However, for the sake of example, the International Organization for Standardization, known as ISO, is a good representative since it is a key body for quality and process related standards. Before getting into the details of an explanation of how ISO is structured, an explanation of the organization's name is appropriate since confusion is often displayed over the use of "ISO":
ISO's name, in English, is the International Organization for Standardization. The three letters, "ISO," are not an acronym for the name. That is, the name is not the International Standards/Standardization Organization to match the letters since that would only be a valid acronym in English. The acronym for the name expressed in other languages would be quite different. Hence, to have a "standard" way to refer to the organization, it was decided to use the Greek prefix "ISO" which has the sense of "equal" or "sameness," suggesting the way in which standards should apply equally to all.
The figure below illustrates the relationship between ISO, its committees, national bodies, national body committees, standards organizations and trade/industry groups, and users. ISO, itself, carries out work through a variety of technical committees (TCs) which may, themselves, have sub-committees (SCs) and other forms of working groups (WGs). National bodies (e.g., ANSI in the case of the USA) are the members of ISO and provide people who participate on the technical committees (and, by extension, sub-committees) in ISO. (Note: Not all members are voting members in all standards areas. Some choose only to have an "observer" status, keeping informed of standards work, but not formally voting on the standards developed.) National bodies, themselves, can have and work through various committees and advisory groups to form opinions on different standards and standards areas. In the USA, various groups such as the ASQ and the IEEE, for example, administer the work of the committees and advisory groups for ANSI, seeing to it that ISO membership, balloting, voting, document preparation, etc. rules and regulations are followed. The work and positions formed by the committees and advisory groups are then passed through these administrative bodies to ANSI to be reviewed and presented to ISO through formal ballot and reporting channels.
It is also possible for other standards organizations and industry/trade groups (national and international) to apply for and form a liaison relationship with ISO (and/or its technical committees and sub-committees) subject to approval by the voting members (at the level of the liaison relationship). Liaison organizations have no formal voting role, but can review and submit comments on standards work like a national body.
At the end of the process are the users of standards who include some portion of the national bodies, other standards organizations, and industry/trade groups as well as people and organizations not otherwise associated with standards development. The hope in developing standards is that those associated with the development do, in some substantive way, represent those who will end up using the standards.
Finally, some mention should be made of the software process standards work relates to the overall ISO structure. The standards work devoted to software (and system) engineering product quality and processes is performed within ISO/IEC JTC1/SC7. Both ISO and the International Electrotechnical Commission (IEC) recognized many years ago that they had mutual interest in computing standards. They decided to form a Joint Technical Committee (JTC) to address computing. Anticipating mutual interest in other domains, they called this the first of such shared committees (JTC1). For a variety of reasons, others did not materialize, so there is really just the one. The standards under JTC1 include hardware matters, communications, programming languages, character encoding systems (e.g., ASCII and EBCDIC), and software engineering, among others. Each of these areas was assigned to a Sub-Committee (SC) with the seventh (SC7) covering software (and some system) engineering matters. Hence, one ends up with the ISO/IEC JTC1/SC7 standards work.