Standards for Process Definition: ISO/IEC/IEEE

[article]
Part 1
Summary:
Before meeting standards like the 12207 for software life cycle process, and the the 15288 standard for system life cycle process, it's crucial to know why those standards exist, and what they're designed to help you and your team accomplish. This three-part series looks at these standards.

In 2008, the 12207 standard for software life cycle processes and the 15288 standard for system life cycle processes were revised in an effort that finally harmonized system and software processes as well as bringing the respective IEEE and ISO/IEC standards into complete agreement. Some users mistakenly believe that these standards are targeted only to large organizations able to make a substantial investment in a complete suite of software and systems processes. However, these standards are also the best entry point for beginning users who desire guidance on as few as a single process. This three-part article will explain how entry-level users can apply the two standards.

Standards are Names

Many users would like to believe that standards are prescriptions for product improvement, but this is not the case. Standards typically prescribe what not how. They provide the criteria for determining what subset of a universe of items qualify to be named by the standard. Generally, then, a standard considers a multi-dimensional trade space of product characteristics and defines a bounded region within that space. The subset of products falling within the bounded region qualifies for the name provided by the standard. For example, not all wireless data transmission schemes are 802.11. The 802.11 standard provides the criteria for the subset that can be called 802.11. In short, IEEE Std 802.11 is a name for a subset of wireless data transmission schemes. The name is important because it permits buyers and sellers; regulators and industry; and insurers and the insured to communicate concisely and accurately.

It's commonplace to criticize standards on the grounds that there are too many of them, but consider the alternative. Is it a better situation for a buyer to understand and select from 802.11a, 802.11b, 802.11g and 802.11n or is it better for a buyer to understand and specify the nearly infinite combination of choices that are actually possible? Although the namespaces provided by standards may be large, they are infinitesimal compared to the ranges of choices available a priori .

Electrical engineering and radio technology are mature disciplines with a well-defined nomenclature for describing their principles. Newer disciplines, such as software engineering, do not share this characteristic. Even the most fundamental of terminology is subject to interpretation and mis-interpretation. So the creation of agreed names is even more important in software engineering. These names can be vitally important in communication between buyers and sellers. For example, suppose a subcontractor is developing a software component of my system and I want to know what review practices they use. They might write a 20-page description of their practices, which I have to take the time to read, question and understand. Or, they might simply say that they use IEEE Std 1028, Software Reviews - an answer which saves both of us considerable effort and which reassures me that they use practices that, at least, meet a minimum set of responsible criteria.

Names can be a useful tool in effective communication, but problems can arise when different namespaces are created for different purposes. A geographical metaphor can explain the point. The IEEE Operations center in Piscataway, New Jersey is located at 445 Hoes Lane. That is a useful name from the driver's point of view. However, workers at the regional postal processing center use a different name, 08855-1331. For taxation purposes, the town clerk might use a name something like "Tract 15, Lot 25, Liber 227, Plat 22." If the land is ever sold, a title researcher might use a description like "the portion of the 1677 royal grant of Charles II to Robert C. Smith,

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09