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, bounded by..." All of these names describe the same location, but are not related in any way that is obvious to the casual observer-that is, unless you have a map. If we plot each of these descriptions onto a map, we can determine immediately that they designate the same location.

In disciplines that - for whatever reason - multiple namespaces are used, it is important to have maps that relate the namespaces. The 12207 and 15288 standards are maps of the namespace of life cycle processes. One can use the set of processes that are named by 12207 and 15288 or one can use the standards to describe the processes that one uses.

Role of 12207 and 15288

ISO/IEC/IEEE 15288 gives names to 25 processes covering the entire life cycle of any human-made system. ISO/IEC/IEEE 12207 gives names to 43 processes covering the entire life cycle of any software product or element of a system. They comprise 84 and 138 pages respectively. The two were written separately by ISO/IEC JTC 1/SC 7 (software and systems engineering) and separately adopted, with minor changes to 12207, by IEEE. In addition, SC 7 created amendments to 12207 that IEEE had not adopted. The result was a situation where, in effect, three versions of 12207 existed and where 15288 was not obviously interoperable with any of the versions. SC 7 and IEEE entered into a joint revision project that resulted, in 2008, in the creation of revised versions that were completely interoperable and common to both organizations.

The two standards contain process models that are nearly identical. The differences that exist are rational and well-explained rather than accidental. The 15288 standard describes the processes at a system level. The 12207 standard specializes the same processes to software and adds processes specific to software. So, three usage situations can be identified:

• To deal with a general system, use 15288;

• To deal with a software element of a system or a software-intensive system, use 15288 and the software-specific processes of 12207;

• To deal with a software product or service (with minimal contextual system), use 12207.

The names of the processes described in the standards are important so that acquirers and suppliers can communicate regarding their intent. For example, if one contracts for "implementation" of a software element, does that include integration testing? If one contracts for work done in accordance with the processes of 12207, the answer to that question is known.

Furthermore, the named processes are important for process evaluation and improvement and for the implementation of improved practices. After all, how can one describe an improved practice for requirements analysis unless we agree on the meaning of requirements analysis? That agreement is provided by the processes described in 12207.

Life Cycle Concepts
The most fundamental mistake made by many is to confuse life cycle processes with life cycle stages (also called phases), life cycle models or with the life cycle itself. The concepts are quite distinct and understanding the distinction is fundamental to applying the standards.

Everything has a life cycle by virtue of its existence. My own life cycle began 61 years ago and will continue for a few more, I hope. A particular systems or a software product also has a life cycle, covering the period from its conception to its final retirement or disposal. Although every unique entity has its own unique life cycle, it is sometimes desirable to talk about life cycles that share certain characteristics. The abstraction that we use is a life cycle model. For example, the much-maligned "waterfall" is a life cycle model which abstracts a certain set of properties from a huge number of actual life cycles that shared those properties. When we talk about life cycle models, it is often convenient to subdivide them into stages (or phases), each with different concerns. A commonly used set of stages is concept, development, production, utilization, support and retirement, representing differing goals and purposes at different points in the life cycle. It is important to understand that different elements of a system may transition from one stage to another at different points in time. In fact, it is sometimes useful to consider stages that are concurrent, such as utilization and support. Life cycle models are useful because they can be applied in developing the plan for a project; their usage guides the allocation of resources appropriate to the different stages. When applied to a project, stages are often viewed as being separated by decision gates, a formal process for determining that the system, or an element of the system, may now be regarded as being in a different stage because the desired outcomes of the stage being exited have been achieved.
Life cycle processes may be applied to any stage of a life cycle model in order to support achievement of the outcomes of that stage. A very simple example is the requirements analysis process. Using my exemplar set of stages above, the requirements analysis process is certainly applied during development. It would also be applied during support, to define maintenance actions, and during retirement, in order to consider issues such as legal requirements for disposing of systems. Having a distinct concept of a life cycle process is useful because it allows us to discuss relevant activities and practices in one place rather than separately for each stage.

Nevertheless, the single most common error made by those who are not expert in process engineering is to confuse life cycle processes with life cycle stages. Whenever, you hear a comment like, "12207 defines a waterfall", then you are hearing the result of this confusion. In fact, both the 12207 and 15288 standards confine themselves exclusively to describing life cycle processes; it is up to the user of the standard to define appropriate stages and select the appropriate processes to be applied to each stage.

Next issue
The next part of this article will describe what user's need in an entry-level process standard and describe how ISO/IEC/IEEE 12207 and 15288 stack up against some of those criteria.

James W. Moore is a 40-year veteran of software engineering in IBM and, now, the MITRE Corporation. He serves as the IEEE Computer Society's Vice-President for Professional Activities and as a member of its Board of Governors. He was an Executive Editor of the Society's 2004 "Guide to the Software Engineering Body of Knowledge" and a member of the Editorial Board of the recent revision of the "Encyclopedia of Software Engineering." He performs software and systems engineering standardization for the IEEE, serving as its liaison to ISO/IEC JTC1/SC7 and as a member of the Executive Committee of the IEEE Software and Systems Engineering Standards Committee. The IEEE Computer Society has recognized him as a Charter Member of their Golden Core; the IEEE selected him as a recipient of their Third Millennium Award and recently named him as a Fellow of the IEEE. His latest book on software engineering standards was published in 2006 by John Wiley & Son. He holds two US patents and, dating to times when software was not regarded as patentable, two "defensive publications". He graduated from the University of North Carolina with a BS in Mathematics, and Syracuse University with an MS in Systems and Information Science.

[1] The author's affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed by the author.