In the previous issue
The previous part of this article described ISO/IEC/IEEE 12207 and 15288, the standards describing life cycle processes for software and systems. Despite their size, the standards are not just for process-heavy users. In fact, the standards are intended to be an entry-point for organizations establishing repeatable processes. 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:

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 system components.
• Organizations desiring to improve project management may want to consider the processes shown in the project group.
• Software developers may want to apply the software implementation processes shown in the middle column of the Engineering group, while systems engineers may be more interested in the processes to their left.
• Those interested in improving software quality may want to consider the processes at the far right.
• Finally, those interested in software quality may want to look at the processes listed at the far right.
• Of course, it is completely reasonable to select a single process for which improvement is desired, such as Software Configuration Management, the example that I will use in this paper.

Although most entry-level users would never want to tackle the entire process set at once, the important thing is that the set exists. The comprehensive scope of the processes assures us that there is something here for everyone. The processes have been designed so that they are cohesive, meaning that each can be implemented independently. Finally, they have been designed to interoperate with all of the others, so that additional processes can be implemented at a time that the user desires.

The bottom line is that the developers of the standards had to create a sizable set of processes so that users can pick individual ones or small groups and still be confident that they aren’t headed into a dead end. Users should keep in mind that, in any field, most catalogs are large even though most of us might order only a single item.

Varying Levels of Detail
The 12207 and 15288 standards describe each process at two levels of detail and provide information regarding where even more detail can be found.

At the top level of detail, each process is described with a name, a statement of purpose and a list of outcomes. Here’s the example of the Software Configuration Management process:

That’s all of it. If you have an existing process and wonder if it is doing all that it should, a quick check of the outcomes may suffice to determine if you could use more assistance. It should be noted that the outcomes are not simply summary fluff. The conformance statement for the standard reads, in part, as follows:

…conformance is achieved by demonstrating that all of the requirements of the declared set of processes have been satisfied using the outcomes as evidence…

In other words, all of the additional details of the standard (to be discussed shortly) are there to help the user achieve the outcomes.

At the next level of detailed are a set of activities and tasks that could be executed to achieve the outcomes. Some (marked by “shall”) are requirements and others are recommendations (“should”) and permissions (“may”). Activities are intended to group together related tasks.

Here’s the complete set of activities and tasks from the Software Configuration Management process. (This example is atypical because each activity has only a single task.):

The description is not quite as brief, and now phrased differently. It describes things that are required or recommended to be done to achieve the outcomes.

Both descriptions contain “Notes”. In an ISO/IEC standard, a note is never a requirement; it merely provides guidance to the user. The activities/tasks description contains notes suggesting packaging of documentation and associated process. The note just below the title of the process is more interesting, though. It suggests that, in some circumstances, one might want to apply the more general Configuration Management process—one that is suited to hard and soft items—that can be found elsewhere in the standard. This is just another example of the degree of flexibility afforded to the user of 12207.

Suppose the user wants even more detail and guidance in implementing the process. Well, in Annex G of 12207 and Annex F of 15288, there is material entitled, “Relationship to other IEEE Standards”. Most of the text is a big table with a row for each process. Here’s the row for Software Configuration Management:

This entry references a 27-page IEEE standard that provides substantial additional detail on planning for software configuration management.

So, in short, for our example, Software Configuration Management, the 12207 standard provides:

1. A brief, outcome-oriented description;
2. A slightly less brief, task-oriented description;
3. A reference to a standard providing even more detail; and
4. The permission to use a more general configuration management standard if appropriate

This example is not unusual. All of the processes provide the first two levels of detail, many provide the third item, and several (in 12207) provide the fourth item.

Next issue
The next and final part of this article will finish describing how ISO/IEC/IEEE 12207 and 15288 stack up against the needs of users who are just entering into process definition.

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 writers of the standard did not consider themselves competent to describe all of the business processes of an organization, so they deliberately described the minimum necessary organization-level processes.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment