A conventional life cycle of requirements analysis, design, code, integration, test, and maintenance as suggested in [9] seems to be appropriate for process definition. We found it useful to have notations available for all stages of process definition, just as it is useful to have notations for design and code when writing conventional software programs.
We found in our study that the easiest method of defining processes
was to follow a conventional life cycle. In the latter phases of our
study, we first defined the process requirements using English
descriptions. We then created a high-level process design using
Abstraction Hierarchy Diagrams and . These
graphical diagrams made communication of the process much easier.
We proceeded to detailed design using
MVP-L to create the specifications and
interfaces for the major subprocesses. The exercise of producing
MVP-L
code uncovered some deficiencies in our high-level designs, which
were modified accordingly. Had time permitted, we would have
proceeded to process coding, using APPL/A. Process definition will
proceed to this code stage
only if an executable definition is needed to analyze the
process,
to perform automated process tasks, or
to
guide manual activities.
Unfortunately, we had to translate manually from one notation to the other when following the above life cycle steps. Much less time would have been spent if we could have automatically translated from one notation to the next. It still would have been necessary to add more details at each step, but much tedious, error-prone manual translation would have been avoided. Unfortunately, no automatic translators between process notations exist today.