Software Process And Problem Diagnoses


A support team with members of the SPI group is assigned to follow and support the development project's improvement activities of configuration management. The support team records the development team's experiences with the changed practices to be used when implementing the improvements in the rest of the organization. The development team and the support team meet frequently in the beginning and periodically during the project to ensure the success of the initiative. Additional training of the project group in specific techniques, e.g., prototyping is provided as needed.

Problem diagnosis covers more projects than the Bootstrap assessment, which in turn involves more people. This is due to the fact that Bootstrap assessments interview whole project teams, whereas problem diagnosis focuses on those influential individuals whose perceptions are considered most important (in this case the project managers). Note also that the time spent refers only to interviews and workshop or feedback session. Both techniques require considerable work to analyze results and to write interview reports.

When comparing the resource requirements, one should take the impact on the organization into account too. The interviews in problem diagnosis involve only one person at a time and maybe carried out over several weeks. The assessment therefore introduces little organizational strain. A Bootstrap (or CMM) assessment, on the other hand, requires a concentrated effort from many people (assessors, software professionals, and managers). It therefore requires careful planning and is highly visible. However, this visibility is also an advantage since more people in the organization will have knowledge about the improvement project.

The recommendations from the two assessments cover roughly the same areas, but with differences regarding grouping and level of detail i.e., risk management and experiments with prototypes from the problem diagnosis are special cases of the software process area recommended in the Bootstrap assessment. Project conclusion similarly includes module and integration testing and configuration management. Software reuse did not result from the problem diagnosis per se, but was added for other reasons.

However, the interesting point in the present context is not whether the two assessments produced comparable results, but the type of knowledge about the software process that the problem diagnosis produced and how this knowledge may support further improvement work. This will be discussed in more detail below.

Problem diagnosis is oriented directly at understanding the software problems as perceived by important organizational actors. The problem diagnosis thus removes focus and attention from the established models of software processes, e.g., Bootstrap and CMM. Maturity in these models is characterized by two ideas: first, the models assert that there is a logical dependency between the individual process areas in the models. An organization must therefore master the basic processes, e.g., project management or configuration management, before embarking on more advanced improvement initiatives such as standardization of methods and management by metrics. Second, the maturity model should assist assessors in focusing on the basic software process problems relative to the organization's level and ignore problems with more advanced processes.