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