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 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:
7.2.2 Software Configuration Management Process
NOTE The Software Configuration Management Process is a specialization of the Configuration Management Process from the Project Process Group in this International Standard. 7.2.2.1 Purpose The purpose of the Software Configuration Management Process is to establish and maintain the integrity of the software items of a process or project and make them available to concerned parties. 7.2.2.2 Outcomes As a result of successful implementation of the Software Configuration Management Process: a) a software configuration management strategy is developed; b) items generated by the process or project are identified, defined and baselined; c) modifications and releases of the items are controlled; d) modifications and releases are made available to affected parties; e) the status of the items and modifications are recorded and reported; f) the completeness and consistency of the items is ensured; and g) the storage, handling and delivery of the items are controlled. |
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.):
7.2.2.3 Activities and Tasks The project shall implement the following activities in accordance with applicable organization policies and procedures with respect to the Software Configuration Management Process. 7.2.2.3.1 Process implementation. This activity consists of the following task: 7.2.2.3.1.1 A software configuration management plan shall be developed. The plan shall describe: the configuration management activities; procedures and schedule for performing these activities; the organization(s) responsible for performing these activities; and their relationship with other organizations, such as software development or maintenance. The plan shall be documented and implemented.
7.2.2.3.2 Configuration identification. This activity consists of the following task: 7.2.2.3.2.1 A scheme shall be established for identification of software items and their versions to be controlled for the project. For each software item and its versions, the following shall be identified: the documentation that establishes the baseline; the version references; and other identification details. 7.2.2.3.3 Configuration control. This activity consists of the following task: 7.2.2.3.3.1 The following shall be performed: identification and recording of change requests; analysis and evaluation of the changes; approval or disapproval of the request; and implementation, verification, and release of the modified software item. An audit trail shall exist, whereby each modification, the reason for the modification, and authorization of the modification can be traced. Control and audit of all accesses to the controlled software items that handle safety or security critical functions shall be performed. NOTE The Software Problem Resolution Management Process could provide support for this activity. 7.2.2.3.4 Configuration status accounting. This activity consists of the following task:
7.2.2.3.5 Configuration evaluation. This activity consists of the following task: 7.2.2.3.5.1 The following shall be determined and ensured: the functional completeness of the software items against their requirements and the physical completeness of the software items (whether their design and code reflect an up-to-date technical description). 7.2.2.3.6 Release management and delivery. This activity consists of the following task: 7.2.2.3.6.1 The release and delivery of software products and documentation shall be formally controlled. Master copies of code and documentation shall be maintained for the life of the software product. The code and documentation that contain safety or security critical functions shall be handled, stored, packaged, and delivered in accordance with the policies of the organizations involved. |
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:
Category | Clause | Process |
Relevant
|
|
|
| Software Configuration Management Process |
| This standard specifies the content of a software configuration management plan along with requirements for specific planning activities. |
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:
- A brief, outcome-oriented description;
- A slightly less brief, task-oriented description;
- A reference to a standard providing even more detail; and
- 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.
Part 2
Part 2 of this article, Applying Entry-Level Process Definition Standards: ISO/IEC/IEEE describes how ISO/IEC/IEEE 12207 and 15288 stack up against the needs of users who are just entering into process definition.
About the Author:
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.
