Support Process Improvement

• Identify all the necessary components of a high-yield software development or maintenance process. In phase one of the study, use of the APPL/A notation allowed us to completely code the implementation of all process steps, using Ada constructs. However, at the low level of abstraction needed to identify all process components, understandability suffered. In phases two and three we were not able to identify all process components at the lowest level. We did not use APPL/A in these phases and the and MVP-L do not allow coding of the implementation of processes at the lowest level.

• Reuse well-defined and effective software processes on future projects. In the first phase of our study, no reuse was possible. In phases two and three, we were able to reuse and MVP-L code from the previous phases. MVP-L is a modular language and units can be easily reused. For example, in phase two we reused the Asset Evaluation Product Model from phase one.

• Compare alternative software processes. The graphical notation makes manual comparison of processes much easier than using English descriptions. In phase three of the study, we showed alternative reuse process definitions to reuse experts. They were able to compare the definitions and give us feedback as to which definition was correct. None of the notations used in our study had tools available for automatic comparison of process definitions.

• Estimate the impacts of potential changes to a software process without first putting them in to actual practice. No tools were available for any of the notations for simulating process execution. We were therefore unable to measure impact of changes.

• Assist in the selection and incorporation of technology (tools) into a process. Using MVP-L, we were able to specify tools used to carry out processes in the resource section of a process definition. Since APPL/A is a full programming language, we were able to call tools in the environment from APPL/A code. In phase one of the study, we coded interfaces to the C system command and the NDBM database management system in our APPL/A program.

• Facilitate organizational learning regarding effective software processes. We did not evaluate this goal in our study.

• Support managed evolution of a process. The understanding gained from our formal definitions helped us to organize the process designs, to add required information, and to remove inconsistencies in the informal descriptions in all phases of the study. An example of an inconsistency that we uncovered was our failure to specify the preparation guidelines as input to a ``prepare asset'' process. Another problem which we discovered was that a process used a product that was not available to that process. The original informal descriptions were modified to reflect our increased understanding of the processes.

  As we progressed from creating English descriptions of processes to Abstraction Hierarchy Diagrams, , and MVP-L, we were able to improve our entire process definition, in all notations. The tool in particularly made evolution of our process definition very simple. A change made at one level in the graphical hierarchy was automatically reflected in the other levels. When a requested change would cause the deletion of items at other levels, the tool warned of the deletions before the change was made.