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