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.
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,