Explicit, formal definitions of the ways in which software engineers develop and maintain software offer potential for understanding, improving, and automatically executing these processes. Software processes have traditionally been defined either implicitly by the activities performed by software engineers, or informally by standards and policies documents. Implicit processes and informal process descriptions are impossible to analyze, difficult to discuss, impractical to teach, and problematic to change. Problems with implicit processes or informal descriptions can easily hide in stable environments, but soon become apparent when the organization is subjected to significant changes such as personnel turnover, shifts in the application domain, or shifts in technology [3]. Explicit definitions of processes assist in gaining intellectual control over software projects by formalizing currently existing implicit or informal processes.
In [9], Osterweil suggests that the development of process definitions should follow a paradigm similar to development of a conventional software product, and should include activities such as requirements analysis, design, code, integration, test, and maintenance. Osterweil continues this analogy by suggesting that the activity of building explicit, formal software process definitions be referred to as process programming, and that the resulting definitions be called process programs. A process program may consist of a set of requirements, a process design, process code, and process test cases. Different process notations can be used to represent the different aspects of a process program, just as conventional software products may be designed and coded using different notations. To avoid the mechanistic connotations of process programming, we use the term process definition in this paper.
At the Sixth International Software Process Workshop [5], eighteen process definition notations were compared. Some of these notations were developed for system modeling and have existed for several years. Some have been specifically developed for process definition. In [1], Clough groups process definition notations into four approaches:
Processes can also be defined at many levels of abstraction. In [3], Humphrey breaks software process notations into three levels. The Universal level provides a high-level overview. The Worldly level is the working level that is familiar to most programmers and managers. The Atomic level provides more detailed refinement, and can support automation of the process. In any process definition effort, the abstraction levels defined will depend on the goals.
Another consideration in process definition is the view used in defining the process. For example, a manager's view of the development process would probably include less detail on individual programming tasks and more detail on management activities than a programmer's view.