| Abstract |
Most software organizations perform their development and maintenance projects according to inadequately specified processes. The lack of explicit and formal process specifications createsa process experience transfer problem: It is difficult to transfer the organization's informal process knowledge (e.g., training new personnel).a process tailoring problem: The tailoring of processes to changing project goals and project environment characteristics is based on subjective rather than objective knowledge regarding the project differences and the effectiveness of candidate methods and tools.a process control problem: Controlling the adherence of a process execution to an inadequate specification is necessarily based on subjective judgement rather than objective criteria.a process improvement problem: The desired improvement of software processes requires an understanding of their current status, the identification of weaknesses regarding their current status, a systematic eradication of those weaknesses, and a validation that the new processes indeed represent an improvement. Without adequate process specifications this process will be random rather than systematic.All these problems are often hidden in very stable organizations for a long time. However, they surface as soon as the carriers of implicit process knowledge leave the organization or dramatic changes in application domain or software technology take place.There is agreement that more formal approaches to process specification are needed [3]. There is also agreement that only the integration of construction and measurement processes will provide the desired engineering control for project-specific process execution and organization-specific improvement. There is no consensus reached as to how such specifications should look like and how they should be used and supported.Our own experience in monitoring and evaluating software processes and products in a variety of organizations over more than a decade has resulted in a number of lessons learned [1, 2]. These lessons motivate the need toformalize the planning and specification of both processes and productsformalize the planning and specification of both construction and measurement oriented processesformalize the planning and specification of all aspects of measurement, ranging from data collection and validation to evaluation and feedbackuse consistent specification models for the measured processes, the measurement processes, and the measurement goalsprovide appropriate automated support for all planning and specification activities (construction and measurement)provide appropriate automated support for storing, formalizing, tailoring and reusing all accumulated process knowledgeAt the University of Maryland, several projects are aimed at building automated software environments based on these lessons learned. In the MVP (Multi-View Process specification) project, we are developing a process specification language (MVP-L) which addresses the lessons (Ll) - (L4) [4]. In the TAME (Tailoring A Measurement Environment) project, we are developing a measurement environment which addresses lessons (L5) and (L6) [2].In the MVP project, we have developed a first prototype language (MVP-L1) which allows the specification of all kinds of process aspects [4]. Its important concepts for specifically dealing with measurement aspects are:The combination of two different language paradigms is used to specify the execution of software processes: the procedural and constraint oriented paradigms.For example, the procedural paradigm allows us to explicitly specify sequential and parallel process execution via control flow and data flow relations. The constraint oriented paradigm allows us to limit the otherwise independent execution of processes via constraints.Three different ways to express the relationship between measurement processes and the to-be-measured construction processes: standard control flow constructs, constraints that need to be checked upon start or termination of the respective construction process, and a “tightly parallel execution” relation between construction and related measurement process. In this case any activity of the construction process triggers an activity of the measurement process.For example, this relationship can be used to express the coupling between a system testing process and the process of collecting all effort spent in performing that test process. If we assume that we are interested in measuring the effort spent during the system testing phase for activities such as data generation, test execution, test result assessment, fault isolation, fault correction, and regression test, we implicitly assume that system testing is performed according to this activity pattern. Very often this implicit assumption is not true. The test process may lack such detail of precision. Explicit specifications of both the system testing and the related measurement process will reveal such inconsistencies. Such inconsistencies leave one of three options: (i) the specification of the to-be-measured testing process needs to be specified more precisely, (ii) the measurement process needs to be relaxed, or (iii) rigid data validation procedures need to be imposed because the measurement process is not consistent with the measured process.Three concepts to structure large process specifications and/or organize a large number of process specifications: refine & compose relations, specialize & generalize relations, and roles.For example, refine & compose relations can be used to indicate that “specifications x, y, z are a refinement of specification A” or that “specification A is composed of specifications x, y, z”. The specialize & generalize relations can be used to indicate that “specification x, y are special instances of specification A” or that “specification A is a general version of specifications x, y”. The role concept allows the clustering of a set of processes and constraints indicating that they serve a common purpose or represent a project-specific view. A realistic project specification is expected to consist of a large number of basic processes which are structured according to the three concepts above. For example, all measurement processes together may be viewed as a separate role.The integration of measurement objectives and metrics with the construction and measurement processes.In the TAME project, for example, the relationships between project objectives and related metrics are specified via a goal/question/metric graph [2], the relationship between metrics and the measurement processes designed to compute them via a measurement process specification, and the integration of the measurement process with the to-be-measured construction process via the relations described in (C2).Currently, MVP-L1 is used on a trial basis to specify the maintenance processes in the NASA/SEL environment and to plan adequate measurement processes [5]. The use of a formal specification language has helped us to speed up the process of planning an initial set of working measurement processes. The experienced speed-up is basically due to the fact that formal process specifications enabled a systematic dialogue between us and the maintenance personnel as to whether our understanding of their processes is correct or not, and to reveal differences between different projects within that same environment. We developed two levels of process specifications for NASA: general ones which capture the commonalties among all maintenance projects, and specific ones which are tailored to reflect the specific characteristics of each project. The experience from this trial application will be fed back into the next improved prototype version of our process specification language.In the TAME project, we work towards adequate automated support for measurement. This includes support for the planning and specification of software construction and measurement processes, the execution of software processes according to their underlying specifications, the management of all process and product related knowledge accumulated during planning and execution, and the appropriate packaging of process and product knowledge in order to enhance its reuse potential. |
