Applying Entry-Level Process Definition Standards: ISO/IEC/IEEE

Part 2
The previous part of this article described ISO/IEC/IEEE 12207 and 15288, the standards describing life cycle processes for software and systems. The standards are not just for process-heavy users. This part of the article will explain how entry-level users can apply the two standards.

Part 1 of this article, Standards for Process Definition: ISO/IEC/IEEE , described the ISO/IEC/IEEE 12207 and 15288, the standards describing life cycle processes for software and systems. The standards are not just for process-heavy users. This part of the article will explain how entry-level users can apply the two standards .

What we want in an Entry-Level Process Standard

Organizations and individuals who are new to process definition and improvement have some particular desires in the standards that they use. Those desires, in turn, levy a requirement for particular characteristics in the standard. Some of the important ones are summarized in the table below:

What an entry-level user wants…

What the standard should provide…

Start small: The user should be able to select a few high-priority processes that are important to their needs.

The standard should provide a comprehensive set of processes so that the user’s desire is likely to be addressed by one or more of them. The standard should offer cohesive processes, so that any one of them can be selected and implemented without the need to pull in others.

Start simple: The user should be able to select a level of detail that is appropriate to initial implementation.

The standard should describe processes in varying levels of detail and provide information regarding where additional detail is available.

Provide credibility: The standard should reward its users by allowing them to make succinct, unhedged claims about their processes—claims that customers can understand and respect.

The standard should provide conformance criteria that customers can easily understand and that separate responsible implementers from irresponsible ones.

Allow for growth: When the user decides to add more processes, implement them in greater detail, or grow in capability level, they should not have to throw away existing processes and start over again.

The standard should support adding processes, adding detail, and improving capability without inducing incompatibility. Furthermore, improvements in the standard itself should be done in a compatible manner, so that users are not disrupted when the standard is revised.

Adapt to needs: Users should be able to implement processes that are recognizable and sensible in the context of their business

The standard should provide processes that are widely applicable and capable of further adaptation.

The remainder of this article will explain how 12207 and 15288 can provide these characteristics to entry-level users.

A Broad Set of Coherent, Cohesive Processes

The figures below summarize the set of processes defined by 15288 and, for comparison, the processes defined by 12207. The 15288 standard is intended to provide all of the technical processes of the life cycle of a system. (I mean “all” literally. Later in this article, I will treat that subject.) The standard also provides all of the Project management processes needed for any stage in a system’s life. On the other hand, it provides just enough organization-level processes to enable the execution of projects.[1] The 12207 standard specializes the processes of 15288 to the specific concerns of software, changing the names of some of them for clarification. It adds additional processes that are unique to software.

At first, the large number of processes may seem overwhelming, but they are grouped for sensible comprehension. Considered individually, most of the process names will be familiar to most users; and most will have an intuitive understanding of what they mean.

Entry-level users will want to select a single process, or a related group of processes for initial implementation. A few groups suggest themselves immediately:

    • The acquisition and supply processes (shown at the bottom of the organization group) are helpful for those who subcontract for software or


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

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

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