Software Process Solutions

At the configuration management training, the sole focus was on understanding the project manager's point of view. As an example, at one interview the project manager expressed the opinion that requirements specifications are elusive documents. In his particular project, the requirements were not settled until a few weeks before delivery. To him, a requirements specification was therefore not very useful for project planning and monitoring.

This came as a surprise to many in the SPI group and a long discussion followed in order to understand precisely what the project manager would take a requirements specification to be, and what were the causes of the problems he had experienced. The interview transcript shows that this discussion took almost 15 minutes and that the interviewers explored the issue at length to get a precise phrasing of the project manager's viewpoint and in a way that project manager's could relate.Thus, we may say that problem diagnosis is situated. It is created within a specific context, a problem situation, in which the main actors, the project managers, are involved as problem owners and thus as clients for the SPI group's investigation.This is in many ways in accordance with Schon's idea of reflection-in-action.

In Schon's work, there is a distinction between technical rationality, on the one hand, and reflection-in action on the other hand. From the point of view of technical rationality, a professional practice is seen as instrumental problem solving: the starting point is a set of given objectives and the task of the professional practitioner is to choose the optimal means to realize these objectives. In doing so, the practitioner uses scientific knowledge to perform specific tasks and to select techniques that apply to different types of situations. Within this view situations can be categorized scientifically.From the point of view of reflection-in-action, different situations are unique, complex, uncertain, and sometimes even discordant. Awareness of the uniqueness of the situation at hand is crucial and it is often only possible to see and comprehend smaller fragments of the situation. Within this view knowledge and action are intrinsically related. Practitioners do research in the situations in which they find themselves. They reflect while acting.

At the point where software process improvement is an intervention into the practices of the software developers, this is, in all respects, reflection-- in-action. This is irrespective of whether the process is guided by consultants and researchers from outside the organization or by an SPI group. Therefore, Schon's theory may provide us with some additional insight. From this we may see software process improvement in the following light:

Software process improvement situations are unique. Even software process problems are unique and they do not fall in pre-established pigeonholes. The definition of software process problems is thus central to SPI initiatives. Software process improvement is an intervention. There is, on the one hand, a potential for looking at software process problems from outside the organizational culture and arriving at some alternative appreciation of the situation. On the other hand, there is a risk that the interventionists misinterpret the problem situation and influence the SPI initiative in a misfortunate direction.