Rules of Software Process Improvement

Software process improvement is a complicated, systematic, and highly professional activity in software engineering that requires theory and models, skilled technical and managerial staff, as well as motivated top management commitment. A set of basic rules that predominate over software process improvement is summarised as follows:

Rule 1: Software process improvement is complicated system engineering.

A process improvement programme has to be thoroughly planned.

There will be little achievement if an organization attempted to improve only a part of the many identified necessary processes in order to improve the whole process system and its performance.

Rule 2: Software process improvement itself is a goal-driven and a continuous process.

It is goal-driven because process improvement should have pre-determined goals and pre-designed approaches to achieve these goals. It is a continuous process because the trace of software process improvement is spiral-like and endless. During a software process improvement programme, the goals may aim to higher, organizational requirements may dynamic, and implement complicity may be increasing. Therefore, there is no absolute final end for a process improvement.

Rule 3: Software process improvement is an experiment process.

Empirical improvement recommendations and rules of thumbs should be treated as hypotheses. Impact and effectiveness of process improvement activities should be monitored and checked by periodical process reviews and/or assessments.

Rule 4: Software process improvement is risk-prone.

With regard directly to Rule 3, it can be seen that risks are naturally attached to any process improvement activities. Therefore, process improvement risks and potential impacts on other processes for an improvement should always be predicted. Also, risks for not implementing required improvement for identified problems should be estimated.

Rule 5: Software process improvement is a time varying system.

Process improvement is working in a dynamic environment, for varying application domains, and fast changing technical platforms. This means there is no specific model one can completely copy; and no specific methodology one can always follow. Therefore, model and methodology adaptation is always required in process improvement.

Rule 6: Software process improvement is a random system dominated by human factors.

Parallel to Rule 5, process improvement is carried out by human being. The features of human factors in software engineering are mainly of diversity and goal-orientation.

A basic assumption is that a skilled software engineer as individual is an intelligent unit in a software engineering process, who would automatically adjusting one’s activities to an optimising goal in the system.

It is noteworthy that process improvement solutions for an identified problem would be multiple; implementation for an recommended solution would be achieved by multiple approaches; and times and effort spend on implementation of an approach would be varying greatly by different individuals or teams. All these varying human factors should be taking into account in a plan of process improvement.

Rule 7: Software process improvement has preconditions.

Process improvement requires formally defined, established and experienced process systems. Process improvement on virtual processes has been proven wasteful.

Software process improvement can only be started based on established software processes. Otherwise, it's effect would be virtual if the process system is virtual itself.

Rule 8: Process improvement is based on process system reengineering.

Process system reengineering is the kernel of SPI. Reengineering can be carried out by: a) enhancing a process; b) changing a process; c) adapting a process; d) merging processes; e) cancel a process; and f) re-organising a process system.

Rule 9: Software process improvement achievement is cumulative.

At all above technical, organizational and cultural costs, the benefits of process improvement achievement, fortunately, can be cumulated permanently, if an organization continuously pursues software process improvement in a systematic and consistent way.