Directions in Software Process Research

Directions in Software Process Research H. DIETER ROMBACH AND MARTIN VERLAGE Fachbereich lnformatik Universitdt Kaiserslautern Kaiserslautern, Germany

Abstract

Developing and maintaining software systems involves a variety of highly intemlated activities. The discipline of software engineering studies processes of both product engineeringand process engineering. Roduct engineering aims at developing software products of high quality at reasonable cost. Process engineering in contrast aims at choosing those product engineering processes appropriate for a given set of project goals and characteristics as well 88 improving the existing knowledge about those processes. Explicit models of both types of processes help a softwan development organizationto gain competitive advantage. This paper motivates the need for explicit process models, surveys existing languages to model processes, discusses tools to support model usage, and proposes a research agenda for future softwan process research.

1. Motivation.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Software Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Software Engineering. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Software Engineering Processes . . . . . . . . . . . . . . . . . . . . . . . 2. Product Engineering M e s s e s . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Life-Cycle (Coarse-Grain) Models . . . . . . . . . . . . . . . . . . . . . . 2.2 Development (Fine-Grain) Rocess Models . . . . . . . . . . . . . . . . . 3. M e s s Engineering Rocesses . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Improvement Rocesses . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Measurement M e s s e s . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Modeling and Planning Processes . . . . . . . . . . . . . . . . . . . . . . 3.4 Comprehensive Reuse Processes . . . . . . . . . . . . . . . . . . . . . . . 4. A Framework for Integrated Mutt and m e s s Engineering . . . . . . . . . . . 4.1 Product and Rocess Engineering. . . . . . . . . . . . . . . . . . . . . . . 4.2 Requirements for Process Engineering . . . . . . . . . . . . . . . . . . . . 4.3 Requirements for Roduct Engineering . . . . . . . . . . . . . . . . . . . . 5. Software Engineering Rocess Representation Languages. . . . . . . . . . . . . . 5.1 History.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVANCES IN COMPUTERS. VOL. 41

2 2 4 5 10

.

.

10

11 12 13 15 16 17 19 19

23

.

26 28 28

2

H. DIETER ROMBACH AND MARTIN VERLAGE

5.2 Survey of Existing Languages . . . . . . . . . . . . . . . . . . . . . . . . 5.3 M w - L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Support for Software Engineering Rocesses . . . . . . . . . . . . . . . . . . . . 6.1 Tools for Rocess Model Building and Project State Browsing . . . . . . . . . 6.2 Rocess-Sensitive Software Engineering Environments. . . . . . . . . . . . . 6.3 M V P - S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Future Directions in Software M e s s Research. . . . . . . . . . . . . . . . . . 7.1 Practice.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Research.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

. .

.

45 50 50

52 53 54 55 55

57 59

1. Motivation Sofhvare engineering as a field is currently evolving from an art to an engineering discipline (Shaw, 1990; Gibbs, 1994).One essential characteristicof engineering is the ability to model all elements of the respective discipline explicitly in order to plan, manage, and develop products better. Higher demands on software products and increasing competitiveness within the software business have triggered a push towards systematic software engineering approaches including explicit documentation of processes. In this section the need for establishing explicit software engineering knowhow in general and software processes in specific is motivated from a business perspective (Section 1.1). A broad definition of software engineering is presented in Section 1.2, aimed at identifying all types of relevant software engineering processes. These software engineering processes are described in more detail in Section 1.3.

1.1 Software Business Success in the sofhvare business requires explicit know-how in the form of product models, process models, and other experience (Fig. 1). Software process models addressboth engineeringand nonengineering issues. Softwareengineering process models capture both aspects related to the engineering of software products and the engineering of better software process models. Models of product engineering processes describe technical issues of product engineering (such as requirements engineering, design, coding, verification, integration, or validation) as well as managerial activities (such as product management, project management, quality assurance. or project data management). Models of process engineering processes describe aspects related to process improvement by cycles of planning, observing via measurement, and feedback. Nonengineering aspects are addressed by business processes (e.g., banking, acquisition, traffic, plant management) and social processes (e.g., communication, training, supervising).

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

3

Software Know-How

Business Process

Models

Social

Rocess

Models

Enginecring

ProcessModels

/ \ T&hnical

Engineering Process Models

Managerial Procw

Process -+ : %a" rclntionship Models FIG. 1. A tentative taxonomy of know-how related to software development and maintenance.

Models

Engineering and nonengineering-related processes are highly interrelated (AbdelHamid, 1993). Software engineering is crucial for success in any software-related business. However, the focus of software engineering know-how depends on the type of business and what is crucial for success within that business. If, for example, we distinguish between software products, software-intensiveservices, and softwareintensive products as business domains, the need for different kinds of knowhow becomes evident. In the case of pure software products [e.g., computeraided software engineering (CASE) tools, games], success is defined, for instance, in terms of time to market, features of the product, or interoperability. In the case of software-intensive services (e.g., banks, insurance companies, travel agencies), success is defined, for instance, in customer satisfaction, or usability. In the case of software-intensive products (e.g., airplanes, traffic control systems), success is defined, for instance, in terms of reliability, certifiability, or userfriendliness. Engineering demands are obvious in all areas, but tailored solutions for each case are needed. The demand for software engineering know-how is caused by stronger requirements on quality, productivity, predictability, certifiability, etc. Market pressure, not only for safety-critical software, triggers the need to evolve software engineering from an art to an engineering discipline. Currently, the software engineering demands are only satisfied more or less accidentally with existing approaches which are typically based on isolated development technologies (e.g., CASE tools, compilers) and human experience. This enables the development of highquality software provided that human experience is available to compensate for lack of explicit engineering know-how, but is not repeatable otherwise. In order for software engineering to become an engineering discipline, software engineers

4

H. DIETER ROMBACH AND MARTIN VERLAGE

have to represent essential software engineering know-how in an explicit, reusable form. Software businesses have to enable the build-up of explicit software engineering know-how tailored to their specific needs (Leveson, 1992). This requires an organizational setup for both building explicit models of software engineering with respect to their business demands, and using such models effectively in future, similar projects.

1.2 Software Engineering Sofrware engineering addresses the technical aspects of software-related businesses. The need for software engineering is most obvious when developing large systems with stringent quality requirements. The reasons are manyfold the specification of large systems covers functional and nonfunctional aspects, the system as a whole is not understandable in all details, often the specification is incomplete at the beginning of and not stable during the project, the project plans are subject to change, and the development is performed in teams, which are often large. It is obvious that these characteristics of large systems require to understand the basic principles of software development and maintenance. In the past few years it was recognized that software engineering processes must comprise more than only the application of sound methods, techniques, and tools. Since the creation of the term “software engineering,” its meaning has evolved. Early definitions reflected a purely technical view of software development. An example is the definition given by Bauer in 1972: “Software Engineering deals with the establishment of sound engineering principles and methods in order to economically obtain software that is reliable and works on real machines.” Software engineeringsupports development and maintenance of software products (for development and maintenance processes the term product engineering processes is used interchangeably). But software engineers do not simply apply their knowledge. Software engineers evolve their know-how with respect to what is developed (i.e,, the software products), how it is developed (i.e., the technical processes), and how well it is developed (i.e., the product and process qualities). The knowledge is captured in explicit models, describing real-world concepts, and evolves (for these processes the term process engineering processes is used). In contrast to early definitions, today a broader view on software engineering is needed to cover all aspects of systematic software development: Software engineering is concerned with the definition, refinement, and evaluation of principles, methods, techniques, and tools to support: 0

Individual aspects of software development and maintenance (i.e., design, coding, verification, validation, etc.)

DIRECTIONS IN SOFTWARE PROCESS RESEARCH 0

0

5

Planning of software developmentprojects(i.e., choosing appropriate methods, techniques, and tools and integrating them into project plans) Performing development,project management,and quality assuranceactivities according to the plan Assessing the performance of the development, feeding back, and improving products, methods, techniques, and tools

This definition implies that software engineering requires learning (based on experiments and case studies) in order to develop useful models and reusing in order to make software development efficient and effective (Rombach et al., 1993). The term model refers to an abstract representation of real-world phenomena in an explicit form. The models reflect an organization’s know-how about software development. Software engineering know-how has to be developed and maintained. Practical experience has shown the need for modeling software engineering entities (especially processes) (see Proceedings of the series of International Software Process Workshops, e.g., Ghezzi, 1994), measuring those entities (Rombach et al., 1993),reusing the models (Prieto-Diaz, 1993), and improving the models (Pfleeger and Rombach, 1994).

1.3 Software Engineering Processes For the development and maintenance of large software systems a variety of processes are proposed. In general, product engineeringprocesses can be classified into technical and managerial processes as described above (Fig. 1).The primary goal of technical processes is to transform and evolve product information from the problem description to the final system in a systematic way. The primary goal of managerial processes is to provide an environment and services for the development of software which meets the product requirements and project goals. Knowledge about these product engineering processes can be captured in models in order to allow process engineering processes to improve them systematically. In the following paragraphs a survey of software engineering processes (Lea, product engineering, and process engineering processes) is given. This is not to be understood as a comprehensive discussion of all software development-related processes. Instead an impression should be given about typical representatives of product and process engineering processes and how they differ from each other. Technical software engineering processes include, but are not limited to: 0

0

Requirements engineering. Starting from an (implicit or explicit) problem description, the requirements engineer develops a system requirementsdocument in conformance with existing documentation standards and quality requirements (e.g., completeness, consistency, and correctness). Design. Startingfrom the requirements document,the design engineer develops the design document, capturing the system’s architecture and main

6

H. DIETER ROMBACH AND MARTIN VERLAGE

0

0

0

0

algorithms and data structures in conformance with existing documentation standards and quality requirements (e.g., strong cohesion and low coupling of modules). The design documents contain requirements for single components (e.g., modules, subsystems, routines) considered as black boxes. Coding. Starting from a component requirement, the code engineer develops a component design and implementationin conformance with existing documentation standards and quality requirements (e.g., maintainability, performance). VeriJication. Starting from each developed document within the project, the verifier has to check for conformance with documentation guidelines, quality, and correspondence according to the source document. Verification is based on a formal basis (e.g., verifying source code against component requirements) or informal basis (e.g., verifying design document against requirements document). The latter is often called inspection, review, or audit. Integration. Starting with the set of object code components, the integration engineer has to link the parts of the system to build the complete application. This can be done in multiple steps, creating subsystems and different versions. Validation. Starting with each executable part of the system, test data is applied to components, subsystems, and the entire system by the validation engineer to check whether the behavior corresponds to the specification. Functional and nonfunctional features of the running system are observed. If failures occur, the corresponding fault is detected. After termination of rework performed by other processes, the system or its components are to be validated again.

It should be noted that this grouping of activities is made for communication purposes. A real project may require other aggregations or refinements of the processes. Nevertheless, there are different classes of processes, but they are strongly interrelated by means of data, control, and information flows. Product engineering processes that deal with management aspects are not directly related to a distinct phase of a software project, but may span over the whole lifetime. Managerial software engineering processes include, but are not limited to: 0

Product management provides a repository for all product-related documentation developed, used, and modified in a particular project, including product measurement data. It should provide access control to avoid security and integrity problems, manage product-related attributes (e.g.. producer, size, type, etc.), maintain relations among products (e.g., explicit documentation of module uses-relationship), and perform configuration management.

7

DIRECTIONS IN SOFWARE PROCESS RESEARCH 0

0

0

Project management supports the performance of the scheduled processes during the whole project, monitors progress, controls estimates about effort and time, and initiates replanning. Quality assurance controls deliverables and processes with respect to the quality goals (or quality requirements)specified in the project plan to provide confidencein their fulfillment (InternationalStandardsOrganization, 1991a). In contrast to project management, a quality assuranceengineer is interested in process and product attributes that may flag a problem concerned with quality (e.g., number of detected design defects per staff hour). Projecr data management provides a repository for all project-related documents like schedules, plans, or process measurement data. Its task is to record the history of a project (i.e., the project trace) by recording events, management data, and process attribute values related to quality.

Figure 2 gives an overview about the different product engineering processes and their relationships. All technical processes are in the middle of the figure. The arrows present the product flow between the processes (i.e., boxes). Products are represented by boxes with rounded comers. The introduced managerial pro-

Project Management

A

control informntion

I

Quality Assurance

FIG.2. Technical and managerial product engineering processes.

8

H. DIETER ROMBACH AND MARTIN VERLAGE

cesses are shown around the technical processes. The repositories of product and project data management (not shown in the figure) can be seen as integrated to a project database. Project management and quality assurance use the project database services (e.g., to trace the project). Moreover, they both stay in strong connection with the technical processes (e.g., assign tasks, check results). It is important to note that the processes and their relations shown in Fig. 2 are exemplarily. Other processes are conceivable. Learning within an organization can only take place if the experience gathered in single projects is captured, analyzed, organized, maintained, and reused after project termination and during planning of new projects. Systematic learning requires both explicit representation of knowledge and the performance of processes manipulating knowledge. The processes performed for organizationwide learning are called process engineering processes because their main focus is on the processes of development projects. We can distinguish between: 0

0

0

0

Improvement processes analyze the current state of the application of techniques, methods, and tools, make suggestions to evolve the processes, and assess whether the intended impact on process or product quality has been achieved. It should be noted that software development is an experimental discipline since little is known about the basic nature of products and processes (Rombach et al., 1993).Therefore modifications of the current state have to be assessed, which should be a separate improvement step. Modeling and planning processes are required for choosing software engineering objects and integrating them into a project plan for a given set of project goals and characteristics. Descriptive models of existing implicit processes are needed to document the current state of the practice. The set of all instantiated models is usually understood as the project plan. Measurement processes analyze the project goals, derive measures to allow characterizationof various kinds of objects in a quantitative manner, collect data for project control, validate and analyze the collected data, and interpret them in the context of the goals. Expressing product and process features in numbers allows scientific and managerial activities to be performed more traceable and systematicly (Rombach et al., 1993). Reuse processes organize experience and allow learning from project to project. They use the information available from each project. Knowledge in terms of products, processes, and measurement data is analyzed and validated for potential use in future projects. The packaged experience can be reused by other projects.

Figure 3 shows the process engineering processes listed above.' It should be noted that some of the process engineering processes are present in the environment of a particular project (i.e., measurement and modeling and planning), that

OiRECTiONS IN SOFTWARE PROCESS RESEARCH

9

FIG. 3. Process engineering processes.

improvement is concerned with the evolution of software know-how operating on the experience base, and that reuse processes offer an interface for both projects and the experience base. For example, product engineering processes are traced by measurement activities and recorded by reuse processes in order to allow improvement processes to make suggestions for better process performance. The improved process models can be used in later projects during modeling and planning to build a project plan with respect to the improved software engineering know-how. These relationships between process engineering processes are not shown in Fig. 3. Improvement processes establish a cycle of learning from project to project. Entries in the experience database are updated based on observations made primarily in projects. To summarize, software engineering is concerned with both product and process engineering processes. The evolution of these processes, which is a field of software engineering, is covered by the general term sofrware process research. We would characterize it this way: Software process research is concerned with the definition, refinement, and evaluation of principles, methods, techniques, and tools for a particular context to support:

10

H. DIETER ROMBACH AND MARTIN VERLAGE 0 0

0 0

Communication about software development processes Packaging of software engineering processes based on reusable components Analysis and reasoning about processes Project guidance and control using suitable methods and techniques (i.e., processes) Automated support through process-sensitive software engineering environments

Product engineering processes are (partially) the outcome of process engineering processes. This work gives a general overview of both kinds of processes in the first part (Sections 2-4) and discusses a specific infrastructure technology supporting software process research in the second part (Sections 5-7). The current states of product engineering processes and process engineering processes are presented in Section 2 and Section 3, respectively. An overall framework for integrating both kinds of processes conceptually is given in Section 4. This framework motivates the need for explicit process models and suggests requirements for models and process representation languages. Section 5 discusses to what extent these requirements have been met by presenting a sample set of approaches. Supporting methodology and technology for process representation languages is presented in Section 6. Finally, Section 7 lists possible future topics for practitioners and researchers for contributing to the field of software process research.

2. Product Engineering Processes Software development organizations have recognized the need for explicit models of both products and product engineering processes in order to develop software of high quality (see also International Standardization Organization, 1991b).This section gives a broad overview about what processes are modeled. Most of the documents are still used off-line during the project. The potential of explicit process models is still not used in real-world software development projects.

2.1 Life-Cycle (Coarse-Grain) Models Life-cycle models describe activities over a project’s lifetime on a high level of abstraction. They divide a project into several phases and describe temporal relationships (e.g., coding starts as soon as design terminates).This is an abstract view of a project, only suitable for educational, communication, and process classification purposes (i.e., functional module testing belongs to the validation phase, and is no subpart of it).2In general, life-cycle models are no special kind

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

11

of development process model. They are used to explain and classify them. Nevertheless, in the first years of their existence, life-cycle models were (mis) understood as process models and used for project planning and guidance, and sometimes they still are. The first life-cycle model that became known to a broader audience was the waterfall model (Royce, 1987). Its popularity stems from being one of the first attempts to clarify understanding of how software is developed. Subsequent modifications of the waterfall model were made to allow feedback and iteration. Criticism addressed its nonapplicability to certain kinds of projects. Mainly, this was caused by misunderstanding the waterfall model as a process model for software development, rather than a classification of its processes. A typical example was the waterfall model with overlapping phases, which tends to be more a process model than a life-cycle model. Nevertheless, all other life-cycle models proposed after the waterfall model share some commonality with it. The iterative enhancement model suggests dividing a specification into increments and then iterating over these increments (Basili, 1975). This enables learning in a project and allows one to deal with higher-risk (i.e., with respect to technical aspects or budget/schedule)system parts first. Each increment is developed following the waterfall model and an additional integration step. Prototyping is a life-cycle model introduced for specification validation using executable examples of the system to be developed (Davis, 1990). The intention is to give the end-user a feeling about the future system or to analyze feasibility of critical components. Several variations of the prototype model exist. Extreme ones are the development of a throwaway prototype, which is purely developed for specification validation, and the evolutionary approach, which modifies a system with respect to refined or corrected user specifications over multiple iterations. The spiral model covers both technical and managerial aspects of software development (Boehm, 1988). Sequential steps are performed to elaborate the system and to analyze risks caused by uncertainties (e.g., a weak requirement) and lack of know-how. The development steps may vary between a completely evolutionary approach and a two-phase prototype-waterfall approach. It differs from the other proposed life-cycle models in that it explicitly integrates nontechnical aspects like planning and management into the spiral.

2.2 Development (Fine-Grain) Process Models Development process models exist for both technicians and managers. Lifecycle models and development process models do not differ in what they describe, but they do it on different levels of abstraction and cover different aspects. In particular, development process models are more detailed and cover more aspects than life-cycle models. The documentation of these processes is at least done for

12

H. DIETER ROMBACH AND MARTIN VERLAGE

two reasons: (1) the engineers and managers need a guide through the technical details and steps of the employed methods and techniques, and (2) multiple techniques and methods are brought together by describing them in a single process model. The primary modeling concepts remain the same for both purposes. But it should be noted that technical and managerial process models, on the one hand, tend to be general when they cover several phases of software development, and, on the other hand, only present an isolated slice of how to apply product engineering technology. Technical and managerial process models often appear as standards. Some of them are published by public organizations [e.g., Institute of Electrical and Electronics Engineers [IEEE], American National Standards Institute (ANSI)] in order to spread technical knowledge among their members or to ensure specific qualities of the product or the process by their customers [e.g., in the case of U.S.Department of Defense (U.S. DoD) 2167A or International Standardization Organization (IS0)-9OOO family]. The standards usually make statements about the product (e.g., documentation), intermediate results (e.g., error reports), and the development processes (e.g., method to apply). A critical look at standards can be found in (Pfleeger et al., 1994). It is obvious that different process models are needed when concerned with different tasks (Section 1.1). But also different process models are needed when concerned with same tasks but in different contexts and with different expectations (e.g., quality requirements). Organization-specific standards, guidelines, and process models exist on various levels of granularity, the same process is described on company, division, department, project, and team level. Others may exist only on a particular level. Often the standards, guidelines, and process models do not contain the context-specific implications of the rules they should enforce. This sometimes makes it difficult to understand the reason or purpose of a rule for remote readers.

3. Process Engineering Processes There is a growing awareness in industry that process engineering is crucial for business success (Gibbs, 1994; Humphrey, 1991). Process engineering processes are performed to observe product engineering processes, to feed analysis results back to process performers, and to improve the already existing process models for use in future projects. First companies are starting to deal explicitly with process engineering processes in the context of process improvement programs (as, for example, conducted by the Software Engineering Institute (SEI) at Camegie-Mellon University, the BOOTSTRAP consortium (Haase et al., 1994), or the Software Technology Transfer Initiative (STTI-KL,) at UniversittIt Kaiserlautern). Nevertheless, explicitly and formally defined process engineering

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

13

processes are rare (although examples can be found in Madhavji et af., 1990; Hoisl, 1994).

3.1 Improvement Processes Improvement processes deal with an organization’s knowledge about how and how well to develop software. Models which reflect existing practices are used to plan and guide software projects. The projects are observed in order to determine problems or to detect relationships between phenomena not known previously. The new experience is brought into new models, reflecting improvements over the set of models which existed before the project was launched. Several process models for improvement have been discussed inside and outside the software process research community. They all share the basic principles of planning, observing, and giving feedback.

3.1.1 Plan-Do-Check-Act Improvement of industrial production lines or single processes is the goal of the Plan-Do-Check- Act approach (Deming, 1986). Observations made in Japanese companies have stimulated the formulation of an approach to change processes for the better. The general idea is that customer satisfaction is the key for business success. For this, statistical quality control is used to measure the impact of factors isolated by the organization on a product’s quality. A feedback cycle enables learning from past results. The approach consists of four steps: 1. Plan. Develop a plan for effective improvement (e.g., setting up quality measurement criteria and establishing methods for achieving them). The existing process is changed or a test is designed. Sometimes only new measurements (observations) are introduced to the process. 2. Do. The development organization carries out the plan, preferably on a small scale. 3. Check. After process termination, observe the effects of the change or test (i.e., check the product against the quality criteria set up in the plan phase). 4. Act. Study the results and document the lessons learned. Emphasis is on understanding the principles of the process, to predict product’s quality better and to suggest further improvement. The Plan-Do-Check-Act approach is designed to improve a single industrial production process within a team organization. Variations which likely exist in software engineering processes are not considered here. Moreover, the emphasis is on the product rather than on the process, and on one process attribute, namely, productivity. This suits for the evaluation of production, but

14

H. DIETER ROMBACH AND MARTIN VERLAGE

not as an approach for studying development processes themselves. The quality control methods are not justifiable for software development, also. Since the goal of the Plan-Do-Check- Act approach is eliminating product variations, it cannot be used for processes that produce no two outputs which are the same. A characteristic of the Plan-Do-Check-Act approach is the nontermination of this four-step improvement cycle. A process is seen as being continuously improvable, although it may have a good state already. The basic ideas that led to the formulation of this approach served also as input for designing the basic principles of Total Quality Management (TQM).

3.1.2 Total Quality Management TQM stems from the same roots as the Plan-Do-Check-Act approach, providing a rich framework for systematically achieving higher customer satisfaction, a more advanced organization, and improvements by modularizing the process into standardization, improvement, and innovation. It requires planning, measurement, and control for both products and processes throughout the whole project (Feigenbaum, 1991). Different measurement approaches are taken for observing product quality (statistical process control), customer satisfaction (e.g., quality function deployment), and advancing the organization (e.g., policy deployment). Improvement can therefore be demonstrated by comparing data taken from actual projects with quantitative characteristics of prior processes. TQM must be tailored to the specific needs of software development. In Zultner (1993), the adoption of TQM for software development organizationsis described. The report about a single software development organization out of 130 being awarded for quality improvement may indicate that the number of software development organizations currently establishing TQM is not as high as in pure production-oriented companies. A more detailed example for applying ideas of TQM to software development is described in Humphrey etal. (1991), connecting TQM and the SEI’s Capability Maturity Model (CMM) for assessing software development organizations.

3.1.3 Quality Improvement Paradigm The Quality Improvement Paradigm (QIP) is a six-step approach for systematically developing software and validating software engineering technology. The QIP is the result of the application of the scientific method to the problem of software quality. As such it is related to other methodological foundations (Basili, 1993). In particular, the QIP consists of the following steps for a development or improvement project (Basili et al., 1994a): 1. Characterize the project using models and baselines in the context of the

particular organization.

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

15

2. Set quantijiable improvement goals on the basis of the initial characterization and of the capabilities that have a strategic relevance to the organization for successful project and organization performance and improvement. 3. Choose an appropriate process for improvement, and supporting methods and tools, making sure that they are consistent with the goals that have been set. This plan is developed on the basis of the characterization of the environment and the goals that have been set. 4. Execute the plan to develop products, and provide feedback based on the data on goal achievement that are being collected. 5 . Analyze the collected data and information gathered during and at the end of each specificproject to evaluatethe current practices, determineproblems, record findings, and make recommendations for future project improvements. 6. Package the experience newly gathered in the form of new, updated, or refined models. Store them in an experience base so it is available for future projects. Tracing the effects of applied technology in the context of a defined context and with quantifiable goals leads to conclusions about the suitability of this technology in the given environment. Because product engineering processes are also a subject of study, all technical aspects of software development are potential candidates for improvement. This exemplifies that improvement processes cannot be seen as being equal to technical processes. Improvement processes survive projects; they study and change product engineering processes. The QIP has been demonstrated in various applications to be a sound methodology for quality improvement. This has helped to get better product engineering processes in order to meet quality goals. One example of successful quality improvement by employing the paradigm is National Aeronautics and Space Administration (NASA’s) Software Engineering Laboratory, Greenbelt, Maryland (Basili et al., 1992). This organization was awarded the first IEEE Computer Society Award for Software Process Achievement.

3.2 Measurement Processes Measurement processes are concerned with the definition of goals, the derivation of metrics, the collection of data, their validation and analysis, and finally the interpretation of the results in the context of the environment from which the measures were taken. The goals of measurement vary along five characteristics: (1) what software engineering objects are being measured (e.g., products, processes, projects); (2) why are they being measured (e.g., control, characterization, assessment, evaluation, prediction. improvement); (3) who is interested in this measurements

16

H. DIETER ROMBACH AND MARTIN VERLAGE

(e.g., designer, tester, manager, quality assurance engineer, entire software development organization); (4) which of their properties are being measured (e.g., cost, adherence to schedule, reliability, maintainability, correctness); ( 5 ) in what environment are they being measured (e.g., kinds of people involved, technology used, applications tackled, resources available) (Basili et al., 1994~). Goal definition is the central part of any measurement activity in the sense that it establishes a context for all other measurement activities. Object (e.g., design document, validation process), purpose (e.g., analysis, control), viewpoint (e.g., designer, manager), quality focus (e.g., completeness, effectiveness), and environment (e.g., project organization X) of a goal define a context that is used to select appropriate metrics (Rombach, 1991b; Basili, 1992). Derivation of metrics is performed in a traceable way by following the Goal Question Metric (GQM) approach (Basili et al., 1994b). Data collection is performed before, during, and after a project or process to get information about the subject of study. Various techniques are employed to collect the data, mainly we distinguish between manual and automatic collection. Sample support systems are listed in Lott (1994b). Validation of measurement data and its analysis are performed during the project or after its termination. Statistical techniques are selected with respect to measure qualities (e.g., scale) and employed to identify features and relationships of the data (e.g., correlation). Interpretation of the collected and validated data should be performed in the context of the measurement goal. This process uses results from data collection and analysis (e.g., in the case of control to check whether the goal has been met or not). Here automated support is valuable, but interpretation must be done by humans.

3.3 Modeling and Planning Processes One task of software engineering is the assessment and improvement of methods and techniques used for software development and maintenance. The nature of software and processes is the subject of study. This requires the observation of process and product qualities over time. To deal with these objects of study, it is necessary to describe them and formulate expectations about their behavior (Sec. 1.2). The former is usually called modeling and the latter planning. Modeling captures essential aspects of real-world entities and leaves irrelevant details out. A model is a general description (or representation) of an entity (i.e., specifies a possible set of real-world entities). The counterpart of the real world is the model world which contains all models. One can compare process, product, or quality models with types in programming languages. When modeling is based on observations of real-world objects, it is called descriptive modeling. What is relevant and what is not depends on the intended use or purpose of the models.

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

17

A general answer of which aspects to cover cannot be given. Also, the level of granularity depends on the context the models are used in. In the model world two layers are present (i.e., a generic and a concrete one). On the one hand, classes, templates, or types of processes are described in order to specify explicit, but generic knowledge about a set of real-world activities. These elements provide abstractions from projects. On the other hand, concrete objects are instantiated from these elements which directly correspond to activities, things, or other concepts in the real world (Dowson and Fernstrom, 1994). For example, on the type layer there exists a general process model design producing a design document. On the object layer there exist several design processes which all are instances of the same process model. These design processes are scheduled and assigned to different people in order to develop design documents for two different systems in different contexts. These processes have in common the information specified in the process model. The processes represent activities of a real-world project. Planning uses models (i.e., instantiates and relates them) to build a representation of the project to be performed with respect to the project’s goals and characteristics. Project goals are quality attributes (e.g., time, effort, reliability) with quantitative target values (e.g., 3.5 months, 960 staff hours, less than two critical error in acceptance testing). Project characteristicsare given by the project environment with respect to personnel (e.g., maximum eight persons, two of them unexperienced), process (e.g., waterfall model, methods and tools), and quality (e.g., estimation models). Experience of former projects helps the planner make estimations (e.g., about effort distribution or fault detection rate) and to set up internal project goals to be met (e.g., milestones or quality goals). Typically the overall process structure is a task breakdown structure that can be used for resource allocation and other management tasks. Various techniques to support these processes exist (for sample lists, see Gilb, 1988; von Mayrhauser, 1990).

3.4 Comprehensive Reuse Processes Reuse is often claimed to be a key to cost-effective software development. Reuse of software products has been an important area of software engineering for some time (Krueger, 1992). Different product reuse systems exist. Recently, all kinds of explicit knowledge were seen as objects of reuse (Prieto-Diaz, 1993).3 At least products, process models, and quality models can be considered as such software engineering knowledge. There are examples of systems providing support for reusing software engineering knowledge (Gish et al., 1994). In order to make reuse work, it must be embedded into software engineering processes. It must be considered during and integrated into software development (Matsumoto, 1992). The reuse process must be tailored to the objects stored in the repository. Nevertheless, basic principles are shared among them. On the one hand, the

18

H. DIETER ROMBACH AND MARTIN VERLAGE

characterization scheme of objects in a repository should consist of three parts, on the other hand the reuse process should be refined into several basic processes (Basili and Rombach, 1991). Both reuse candidates and required objects are described in a threefold manner. First, the object itself has to be documented. Second, the object’s interface must be specified. Finally, a comprehensiveobject documentationcontains the context the object is used in. This characterization scheme yields a complete description of software engineering knowledge (i.e., products, process models, or quality models). An example for a reuse object is given in Table I. How such a scheme can be used to retrieve objects from a repository is described in (Prieto-Diaz and Freeman, 1987). Often the reuse process is refined into the subprocesses identification, evaluation and selection, modijication, recording, and (re)packuging. Identification means computing the similarity between the required object and reuse objects residing in the repository. An example is given in Prieto-Diaz (1991). The identification process results in a set of possibly useful objects. The elements of that set have to be analyzed in depth to select the most suitable candidate. An exact match of reused and required object is ideal but unlikely to happen. Often a modification is required to meet the specification of the required object. At the end of a project, any experience gathered throughout the whole project has to be recorded and brought into the repository. This includes new objects and experiences made with reused objects. The repository itself must be organized TABLEI EXAMPLE PROCESS ASSET Dimensions

Design inspections Object

Name Function Type Granularity Representation

SeLinspection.waterfal1 Certify appropriateness of design documents Inspection method Design stage Informal set of guidelines Object interface

InpuVoutput Dependencies

Specification and design document Assumes a readable design, qualified reader Object context

Application domain Solution domain Object quality

Ground support software for satellites Waterfall Ada life-cycle model, standard set of methods Average defect detection rate (e.g., >0.5 defects detected per staff-hour)

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

19

and maintained to provide good support. Because of this functionality and its separation from the projects, this active part of an organization is called the experiencefactory (Basili ef af.. 1994a). The generic reuse process is discussed in detail in Basili and Rombach (1991). A detailed discussion of process steps for product reuse was made within the ESPRIT project Reboot (see, e.g., Morel and Faget, 1993). Reuse as a process engineering process is not only affected by technological issues, but also by environmental influence. This shows again (Section 1) that any kind of engineering process is embedded in the context of other processes, either engineering or managerial processes (see also Frakes and Isoda, 1994).

4. A Framework for Integrated Product and Process Engineering A variety of product and process engineering processes is needed for effective and efficient development of large software systems. Significant results were achieved in the last 25 years in evolving software engineeringprocesses (Sommerville and Paul, 1993). The reason why the software crisis is still alive is twofold First, software systems are becoming increasingly more complex because the application complexity is growing. Solutions provided by software engineering lag behind the demands of practical software development. Second, there are only a few attempts to integrate solutionsfrom different research areas. Principles, techniques, methods, and tools developed independently possibly influence each other. This should be a subject of study. Improvement of product engineering requires better models. Better models can be built empirically based on lessons learned from development projects. Improvement of both product engineering and model building cannot be achieved independently of each other. A framework is needed that supports sound product engineering and facilitates learning for the sake of process engineering.

4.1

Product and Process Engineering

The TAME model in Figure 4 presents an overall view of software engineering processes and where in the organization they should be performed (Basili and Rombach, 1988). The upper half of the figure denotes single projects being planned and performed. During a project’s lifetime, all product engineering processes are performed (i.e., technical and managerial). Some process engineering processes are also performed in the project environment (i.e., project planning and measurement). The project feedback cycle in Fig. 4 denotes that product and process engineering processes may be interrelated (i.e., quality assurance uses measure-

20

H. DIETER ROMBACH AND MARTIN VERLAGE

I Identification,Evaluation, Saiectlon. and Modnicatbn

ment data in order to check for quality constraints, or project management triggers replanning the project plan because of budget slippage). Process engineering processes also operate in the experience factory! From the experience factory's perspective, quality improvement following the six steps of the QIP requires learning from projects and providing software know-how in terms of models and objects for future projects. Another feedback cycle exists within a project. During project performance,measurement data is used to observe and analyze the current project state, and to give suggestions when deviations from the plan are detected. So far, the subject (i.e., the product engineeringprocesses) and the methods (i.e., the process engineering processes) of software process research are introduced. Repeatedly it was stated that deriving explicit models is crucial for the success of software process research. Explicitly documenting aspects of the product engineeringprocesses is also crucial for project success. For example, the following questions could emerge in real-world projects and should be answered objectively and traceably with the help of explicit representations of process, products, and qualities:

DIRECTIONS IN SOFTWARE PROCESS RESEARCH 0 0 0

0 0

0

21

What minimum coverage should be reached for structural testing in this project? How many omissions are detected in the different versions of the requirements document? Is there significantrelationshipbetween module complexity and effort distribution of module tests? What persons must be informed when a component specification must be revised? Is the fault detection rate in this project abnormal when compared to previous projects of that kind? Can the review of the requirements document be made more formal in order to allow earlier detection of design faults?

Product, process, and quality models are needed for communication, analysis, reasoning, guidance, control, and improvement purposes. Additionally, constraints often require documentation of relevant information [e.g., I S 0 9000-3 (International Standardization Organization, 1991b)]. The following discusses the potential benefits of explicit process representations in more detail, giving various examples of results of software process research. This is done to motivate representation languages as an infrastructure of software process research and to illustrate why there is such a diversity among them. No two different representation languages discussed in the second part of this work have the same goal (i.e.. communication, analysis, reasoning, guidance, control, automated support, or improvement) (Curtis er al., 1992). It is important to recognize why there are different motivations for the different approaches. Therefore, a list of five expected benefits (Bl-B5) is given in the following paragraphs (see also Rombach, 1991a). B 1: Explicit models support human communication. Software is developed in teams. Effective collaboration requires that each project member understands its responsibilities as well as its interfaces with the activities performed by other team members. Explicit representation of knowledge allows asynchronous communication of distributed parties. Moreover, the mere existence of product, process, and quality models supports different people understanding each other (e.g., by referring to a specific part of a representation). Experience gathered from software development organizations has shown the usefulness of explicit process documentation(Humphrey, 1989; Klingler et al., 1992). B2: Explicit models allow for packaging experience. Software engineering know-how is complex. The set of processes needs to be packaged attached with experience regarding their effectivenessand organized in an efficient way (Basili and Rombach, 1991). Complex objects and complex relationships are structured by writing them down in an orderly way (i.e., by

22

H. DIETER ROMBACH AND MARTIN VERLAGE

using a grammar). Aggregation, generalization, and classification hierarchies allow for sound process model management on various abstraction levels. Moreover, explicit process models establish maintenance of software engineering know-how. Different process model versions are managed and improvement can be demonstrated. Additional information is associated with packages. For example, quality models for prediction of efforts possibly are related to a class of process models. B3: Explicit models ease analysis and reasoning. Process representations possess features which are not directly encapsulated in language constructs (e.g., performance). Analysis is to be performed in order to allow statements about the process models. The spectrum of analysis techniques varies from human reasoning to formal verification of process models. An example for the first is given in Klingler et al. (1992): A reuse process was the subject of formalization and subsequent modification based on human analyses. An example for the latter (formal verification) is given in Gruhn (1991). It is obvious that here the set of applicable analysis techniques depends on the selected formalism. In contrast to static analysis and reasoning, several approaches allow studying dynamic properties of process models. One example for software process simulation is given in Kellner (1989). This is an appropriate way for humans to observe process behavior prior to application in real-world projects if formal techniques cannot be employed. B4: Explicit models provide project guidance and support control. Product engineers performing complex activities should be supported in a contextdependent way about what tasks to do next, what are the objects to be accessed, or what are the criteria for successful process termination (Saracelli and Bandat, 1993).Like a road map, explicit process documentation guides the developer through complex structures. A sound support can be achieved if the information is provided context-dependent with respect to the actual process state. By using a guidance system, one can determine whether the actual project performance meets the specification of the plan. This control is effective, if measurement of product and process features allows quantitative statements about the current state in relation to the prediction (Rombach et al., 1992). B5: Explicit models enable automated support through software engineering environments (SEES). Explicit representations of processes can be made accessible, under certain circumstances, to process-sensitive’ software engineeringenvironments (Fuggetta and Ghezzi, 1994). The process models are instantiated and interpreted in order to invoke tools and to compute the next project state. If product engineering processes are well understood, they can be automated with the help of this kind of environment (Penedo

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

23

and Riddle, 1993). But even if the whole functionality of an activity cannot be captured in a process model (e.g., because the process is not well understood or human creativity is not to be hindered), automated support can be given by managing an explicit project state and providing project information for all the users. Table I1 relates the benefits (i.e., Bl-B5) and the processes introduced in Section 1. For each kind of process it is expressed how explicit process models support it. The relations most obvious to us are given. Nevertheless, an empty table cell does not mean that explicit process models do not support this kind of process with respect to that benefit. But from our experience we see the listed relations as the relevant ones. In the next two sections requirements for process representation languages are elaborated and each requirement is related to the above-discussed benefits. If a requirement is fulfilled by a process representation language it is likely that the corresponding benefits are gained. We start with the discussion of requirements for process engineering (what language properties are useful when developing the models) and present requirements for product engineering (what language properties are useful when using the models) afterward.

4.2 Requirements for Process Engineering Process engineering deals with developing, tailoring, analyzing, and improving explicit models. The software engineeringmodels describe all aspects considered to be relevant in the context of a software development project. For example, during modeling, the concepts process, product, resource, attribute, and a variety of relationships like product flow, synchronization between processes, or refinement of objects have been identified as important to build models (Rombach, 1991a). Other types of elements may be justified (e.g., communication paths, events) depending on the process engineering tasks. In addition to the aspects captured in the models, the models themselves have to fulfill a set of requirements when acting as a tool during process engineering activities. The requirements for the models are intertwined with requirements for the process representation language. The following list of requirements expresses our idea of a suitable notation: R1: Natural Models. Project members should review the models built. The process models should not only capture all relevant aspects of the elements of software development, they should be able to represent these aspects in a natural (i.e., easy to identify) way. A one-to-one mapping between real-world phenomena and process model elements eases modeling and

24

H. DIETER ROMBACH AND MARTIN VERLAGE TABLE I1

PROCESS-BENEFIT COVERAGE Rocesses

Support by explicit process models

B1 Task definitions are offered to the product engineers. Real-world concepts must be easy to identify. Formal models allow for consistent interpretations. B4 Decisions about what course of action to take are supported by providing feedback in quantitative form and by showing alternatives. B5 The interpretation of flexible models tailored to specific contexts offers individual support for product engineers (e.g., by providing appropriate tools). B1 Explicit models help the process engineers to understand the Improvement processes. Improvements are documented to support future projects. B2 Model versions show how a process has evolved over time, documenting improvement steps. B3 Analyzing process traces and relationships between measurement data possibly leads to the identification of problems with respect to current models and stimulates suggestions for improving them. B2 A repository of process models reflects an organization’s software Reuse engineering experience. Models to be reused often must be tailored to new, different contexts. B3 Taking measurement data during process performance and checking consistency of different aspects on a formal basis validates the models and makes them more valuable for the experience factory. BI Formal models may be used to define a schema for data management. Measurement To ease interpretation of the schema they should describe realworld concepts in an understandable way. B4 Explicit models tell when, how, and what data to provide or collect. Moreover, the models build a context for multiple data. B5 Measurement activities are automated. Tools for data collection may be directly invoked from process descriptions. Modeling and planning B2 Formal models are selected, modified, and used as building blocks to create a new project plan, thereby generating a new package of explicit experience. B3 Formal languages allow for modeling processes and for checking them for consistency using tools. Project plans are built using experience from former projects and by reusing models and related information gathered through measurement.

Roduct engineering

maintenance of these models. This requirement is called elsewhere the general representation requirement (Gruhn. 1991). R2: Measurable Models. The impact of each applied technology in a particular development or improvement project can be observed on the effects that it has on the products and processes. Scientific evaluation of these effects

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

25

is needed in order to judge the efficiency and effectivenessof the technology and to detect relationships between process elements not known previously. In particular,the QIP (Section 3.1.3) relies heavily on measurement. Therefore process and product characteristics should be measured during the project. A proper definition of attributes and measurement data within the models is needed. For example, if the goal is to test for a possible relationshipbetween module complexity and test effort, collecting data from both products and processes must be able. R3: Tailorable Models. In some sense, process models represent generic information about multiple completed activities. On the one hand, to be useful for a number of projects, process models should describe the commonalities of the processes of these projects. On the other hand, the process environment is likely to evolve and change. Planning must consider the differencesand instantiatethe models using environment parameters (e.g., schedule, reliability). Tailorable models limit the number of models to be maintained and offer adaptability in different contexts (i.e., reuse). For example, requirements specification is likely to vary depending on the type of software to be developed. R4: Formal Models. Process engineering requires communication among different roles. Commonly, teams are concerned with those tasks. Moreover, there may be time gaps between modeling and use. Also, those people performingprocess engineeringand those performing product engineering are usually not the same. All these points require some degree of formality of the models in order to be understood in the same way by different people. If this were not true, implicit process knowledge would be sufficient, Thus, if a language fulfills this requirement, it means that there is a formal model implemented in this language which defmes the meaning of process model constructs. For example, the specification “product P is accessed by process A” should have a specific meaning (i.e., read write and paralleYexclusive access). It should be noted that it is important to allow for replanning of a project. Replanning means to interrupt a project, capture the current state, modify the plan and probably the models, adopt the state according to the new plan, and resume the project. Approaches tackling that problem exist (e.g., Bandinelli et al., 1993a), but the problem is currently unsolved. Nevertheless, this cannot be a requirement for a process representation language (it is r e f e d to the discussion of self-modifying code in the mid-1980s) nor a part of process engineering processes (an analogy would be that software developmenthas to do with changing process memory during runtime and ensuring that a modified system specification is met). This particular problem domain is beyond the scope of this work, taking into considerationthat this is a relevant issue of softwareprocess research.

26

H. DIETER ROMBACH AND MARTIN VERLAGE

4.3 Requirements for Product Engineering Product engineering deals with the development and maintenance of software based on explicit models suitable for a given set of project goals and characteristics. Explicit models are used in particular contexts to support development of software. They are parameterized or tailored with respect to the goals of *e activities which they support. Humans or machines interpret the process representations to perform the tasks. Consequently the developers emphasize different requirements from those concerned with the evolution of the used models. The following paragraphs present a list of requirements that should be fulfilled by any process representation language from the viewpoint of a developer in a particular project.

R5: Understandable models. Process models are used as a reference during the project either on-line or off-line. Because most of the activities concerning

process engineering rely on human rather than machine interpretation of the models, understandability is a crucial point for the success of any process representation language. In contrast to the requirements R l and R4 which address completeness and formality of the language, understandability is oriented toward the style of presentation and how difficult it is for the user of the process representation to retrieve information. For example, the validation engineer should understand by reading the process model how to apply a particular structural testing technique when a user interface component is to be tested. R6: Executable models. Standard procedures of software development are frequently implemented as tools. They can be seen as hardwired process representations. Process-sensitive SEES use variable process descriptions to integrate tools in order to provide more comprehensive automated support. Process representation languages must have specific features in order to allow interpretation or execution by a machine for tool invocation and file access. These features include constructs for expressing operation system's objects (e.g., files, streams, executables), and control and data flow primitives. R7: Flexible models. Processes performed by humans are characterized by creativity and nondeterminism. The use of process models should ensure that the important aspects of the current situation in the development project are reflected. Therefore, a process representation language should provide features for handling decisions made by humans. Such decisions typically affect control flow and product states. For example, only after termination of the design process, the number of modules to be coded is known exactly. But this decision affects the number of processes for coding or validating the modules.

27

DIRECTIONS IN SOFMlARE PROCESS RESEARCH

R8: Traceablemodels. The models should ensure traceability within and across

layers of abstraction (i.e., horizontal and vertical traceability). For each piece of information the developer should be able to determine the context it was originated, the processes which rely on that particular piece of information, and how the information was transformed. M e s s representation languages should provide constructs for explicitly stating different relationships between project plan elements. For example, when a local design error is detected, the project manager should know what developers to inform about interrupting their work and waiting for design modification [e.g., if a module is already at the validation stage, all affected roles (i.e., designer, programmer, and tester) are to be informed about additional rework on design, code, and other related documents].

Table 111 illustrates the relationship between the benefits of explicit process representations and the requirements for process and product engineering which have to be fulfilled by any language which is used to build such explicit models in order to gain the related benefits. Explicit process models which should serve for communication purposes should be described using real-world concepts (Rl),have the same meaning for different people (R4),and should be understandable (R5). Process models that should be reused in another context must allow for tailoring (R3), and should be formal because the recipient of the reused model is often not the one who defined the model (R4).To allow analysis and reasoning, process models must have measurable attributes to quantitatively define them (R2),must be formal in order to allow automated reasoning or analysis by human experts (R4), and should allow identifying relations among data (R8). To be useful for developers and managers in a specific project, an easy mapping between real-world phenomena and objects of the representation should be able (Rl), attributes of both the models need products and processes are needed to control the project (W), and finally the to be understood by the developers to tell them what to do (M), models should allow tracing of information (R8). And last but not least, if the TABLE I11 BENEF~T-REQUIREMENT CoVERAoE

B1 B2 B3 B4 B5

Benefit

R1

Communication Packaging Analysis and reasoning Project guidanceandcontrol Automated support

X X

R2

X X

R3

R4

R5

x

x x

x

X

X

X

R6

x

R7

x

R8

X X

28

H. DIETER ROMBACH AND MARTIN VERLAGE

process models are used as a basis for automated support by a software engineering environment they need to be tailorable to the specific context (i.e., allow one meaningful interpretation) (R3), must be understandable by an abstract machine (R6). and should possess flexibility in order to resume enactment even when the current course of action does not match the expectations (R7).

5. Software Engineering Process Representation Languages 5.1 History The need for an explicit documentation of software engineering knowledge in terms of product, process, and quality models exists. Representing, storing, and retrieving these models is required to enable use and improvement of the models. A language to represent the models must be designed to allow the models to be used in a way suited to the user (Rombach and Verlage, 1993). Different process representation languages were designed and implemented to serve as representation mechanisms for software engineering processes (i.e., to derive process models). Development of languages for representationof software engineering processes is performed at least by two major groups (i.e., tool integrators and process improvers) with different objectives. In the beginning, both communities operated independently. Ideas and results were interchanged later [e.g., see 1st International Software Process Workshop (ISPW) (Potts, 1984)-ISPW 9 (Ghezzi, 1994). Representation languages for processes exist within the tool building community. The beginning of software process research in this area was marked by the UNIX tool make (Feldman, 1979). Make automates a (construction) process by checking dependencies and calling tools. Later more sophisticated approaches were developed which are more complex tools. Today, some software engineering environments have a component called the process engine to interpret process representations in order to execute the processes (Fuggetta and Ghezzi, 1994). The languages to describe the processes include also powerful concepts for representing products, tool calls, user interaction, and control flow between processes. Moreover, the design of some languages recognized the need for flexible mechanisms [e.g., AppYA (Sutton et al., 1990)l. The tool building community emphasizes the understandability of process representations by machines. The languages are not designed to be interpreted by humans. Interaction between humans and computer is done mostly directly by the tools, which indicates that integration of human-based activities is not included. The other branch of language designers originates from the community which is concerned with process improvement. Years of experience in making software development more predictable and controllableled to the recognition that software

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

29

engineering processes need to be represented. A general motivation can be found in Humphrey (1989).Because the work on process models for process improvement was performed by different groups in different organizations, a landmark announcing the beginning of software process research cannot be determined. The main goals which can be identified in all of the approaches are to enable understanding, reasoning, and improvement of the processes of a software project performed by humans (for example, see Saracelli and Bandat, 1993).To reach these goals, languages developed for product engineering were often employed and extended to describe software engineering processes. Some languages were developed from scratch [e.g., MVP-L (Brkkers e? al., 1992)l. The language constructs can easily be matched with real-world concepts to ease descriptive modeling. The derived models can be checked by humans. Design of these languages for descriptive modeling was not for tool integration and automization purposes, but to facilitate the construction of models which humans can understand. Briefly, one can say that the tool integration community tries to automate software engineering processes starting from the bottom level of granularity, whereas the improvement community wants to start with representation of software engineering processes from the top. Both are working on closing the gap between the communities in order to provide a comprehensive support of the entire set of software engineering processes. Nevertheless, the existence of any process representation languages is justified. Every language was designed for its own purpose.

5.2 Survey of Existing Languages It is well known that no best programming language exists in general. For the same reason there is no besr software engineeringprocess representation language: requirements on the process representations vary too much, and there is no single use and application domain of the language. Therefore, process representation languages cannot be assessed with respect to each other generally. But comparing them helps to understand the different motivations for design and application of the languages and shows the variety of mechanisms developed to represent software engineering processes. The sample list of representation languages presented in this section is classified with respect to a common scheme. Additionally for each language it is stated whether the requirementsgiven in Section 4 are met. The classification scheme given below is an aggregate and extension of other surveys made with respect to software engineering process representation languages (i.e.. Armenise e? al., 1992;Kellner and Rombach, 1990; Curtis e? d., 1992). In particular, the emphasis of the scheme presented here is understanding the motivation for developing the languages and giving a flavor how they support software engineers, rather than discussing technical aspects of the languages

30

H. DIETER ROMBACH AND MARTIN VERLAGE

themselves. Nevertheless, issues of enactment are also discussed because the execution or interpretation mechanisms directly affect some properties of the models described in the languages (e.g., inference mechanism in some rulebased systems).

0

0

Process programming vs. process improvement. Product engineering uses different languages for different purposes and different levels of detail (e.g., specification, design, code). The same is true for process engineering languages, In particular, the languages for implementing processes (i.e., process Programming) and notations for conceptual modeling of processes (i.e., process improvement) are ends of a spectrum. Process programming languages offer an interface to operating system services and allow the direct invocation of tools for software development; process models are built in a bottom-up manner by coordinating them and establishing rules for their use. Process improvementlanguages combine well-defined building blocks, ignoring technical details. Both kinds of languages reflect the objectives of two different camps within the process engineering community. Efforts have started to integrate ideas of both camps in order to provide comprehensive support for process engineering. Hidden vs. guiding models. During interpretation of process models (i.e., project lifetime), the representation of the process models may be hidden from or presented to the developers. In the first case, the interaction scheme is completely encoded in the process models or the tools. They define the appearance to the user, and actively filter the information of the current project state. In the second case, the models themselves are used to inform the user. This case requires readability, well-structuredness, and problemorientedness of the models or their instances. The processes should form a modularized set of information for a particular recipient in order to support the task to be performed. Often languages for models guiding developers include special constructs directly reflecting real-world objects (e.g., file or manual) or abstract concepts (e.g., termination condition). Prescriptive vs. proscriptive process models. From the beginning of software process research the idea of automated process execution was seen as one of the benefits that would justify the efforts undertaken in recent years (Osterweil, 1987). In general, sequences of tool activations are described in process programs (e.g., an edit-compile-link cycle). The user modifies the product using tools and additionally provides process information when asked by the execution mechanism. This prescriptive style of “invoking” people has been subject to criticism. The other discussed style of human interaction is called proscriptive, which means a nonrestrictive style of formulating processes (Heimbigner, 1990). The process models or its instances provide sufficient information for the developer to support performance of the tasks. The developer is free, under the limitations set up by

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

0

31

the project plan, to decide what actions to do on the product or process state. This requires flexibility of control flow which is to be ensured by the process representation language. Languages similar to procedural programming languages support a prescriptive style, whereas the modeling of proscriptive processes is supported by rule-based approaches. Single-person vs. multiperson models. Today’s development projects are typically not performed by a single person. Collaboration, or cooperation, between persons, teams, organizations, and companies is undertaken when software is built (compare to Perry and Kaiser, 1991). On all these levels process models should exist in order to support synchronization,delegation, and distribution of work units. Current process research has concentrated mainly on process support for a single person and for teams. Process representations for a single-person document engineeringprocesses which should ensure the sound application of a particular technique or method. Only the activities of a developer’s workspace are managed. However, different people’s processes need to be coordinated. To integrateprocesses of multiple persons, it should be able to identify the local workspace and how communication is performed with the other team members. To allow reasoning, this information should be explicitly documented in the process models, i.e., the languages should provide specific features to express concepts of collaboration.

In general, all combinations of the characterization scheme’s attribute values may exist. Of course, some combinations are more likely to exist than others. For example, it is not meaningful to build a language for improvement which should be hidden from the recipients by using simulators or enactment machines. Reasoning on the basis of the original (or pretty printed) process documentation should be allowed. For each of the approaches, a table is given which summarizes its features and degree to which the language satisfies the requirements. The information under characterization explains to what end of each attribute’s spectrum the process representation language tends. The second group of rows, under the subtitle requirements satisfaction indicates, whether a requirement given in Sections 4.2 and 4.3is met fully (+), partially (0).or not (-). This evaluation should not be understood as an assessment. Again, there is no best process representation language. The evaluation is intended to allow reasoning about the suitability of a language in a given context which is defined in terms of software engineering processes. Using Table II and Table In, one should easily assess the suitability of a language within that context.

5.2.1 AppVA AppYA (Ada Process ProgrammingLanguage with Aspen) is one of the formalisms developed and maintained within the Arcadia project (Taylor et al., 1988).

32

H. DIETER ROMBACH AND MARTIN VERLAGE

The underlying philosophy is to automate all aspects of a software engineering process to the highest degree possible. The major goal is to build a processsensitive environment which enables engineers to concentrate on their creative work. AppYA is an extension to Ada that provides constructs for the specification, implementation, and use of relational data structures (Sutton et al., 1989). The 'extensions are relations for persistent product data storage, triggers which are tasklike units and react on modifications of the product data, predicates which are comparable to constraints on product states, and transactions on the product data. It should be noted that these extensions include pure technical constructs. No domain-specific concepts (e.g., document, schedule, developers) were added to Ada. For illustration, a procedure of an AppYA process program is given here6: procedure Reschedule-Tasks(c-task: i n task-enum; mg r-i d : emp-i d-t ype is R e s c h e d u l e t h e g i v e n t a s k and a n y dependent tasks Begin send-msg(mgr-id, " R e s c h e d u l e change p r o c e s s tasks'' 8 I' b e g i n n i n g w i t h t a s k I' 8 t ask- enum'i m ag e ( c - t a s k ) ) ; s e r i a l r e a d Change-Process-Team, Task-Assignments, Task-Status, Ta s k-S t a r t-S c hedu 1e, Ta s k-Or de r ; begin mg r-a s s ig n-t a s k s ( m-i d 1; mgr-schedule-tasks(m-id); upda t e-pr o j ec t-p 1ans (m-i d, s u b p r o j - i d ; n o t if y-a f f ec t ed-pe r sonne 1; end s e r i a l ; End Res c h edu 1e-Ta s k s ;

--

The main objectives of AppYA are analysis and execution of process models. The process is described at a low (Le., machine-executable) level, concentrating on the technical steps that are strongly supported by tools (e.g., coding and validation). The program is described in a procedural-like fashion. User interaction is performed by queries when the course of action cannot be computed on basis of the product states (e.g., choose an action on a product object). The user may change the project state only by using this interaction mechanism or acting via tools. Process representations written in AppYA are translated into executable Ada code. Processes are represented by concurrent threads of control, namely, Ada tasks. During execution of the processes, the Ada runtime system is used.

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

33

Table IV gives an overview of AppUA at a glance. AppYA is one of the first process representation languages for the implementation and automation of processes. Like many of the programming languagesAppV A lacks for problem-oriented constructs. The focus is on providing a sufficient functionality of the process models. Nevertheless, AppYA demonstrated that there is a strong relationship between languages developed for product development and the mechanisms needed for process representation.

5.2.2 TEMPO Because product and process data tend to become complex in a real-world project, adequate representations are provided in the Adele system by employing an entity relationship database with object-oriented extensions. Objects are aggregated to form complex part-of hierarchies and are allowed to have different versions or version branchs. The data is manipulated by an Activity Manager which understands process models as combinationsof events, triggers, and methTABLE IV CliARAclWzAnON AND EVALUATION OF hFWA Characterization m e s s programming AppYA is an extension of the programming language Ada. Hidden User interaction is implemented using message concept. Prescriptive Ada is a procedural programming language. Humans are asked to provide information. Multiperson Multiple persons may be represented as ordinary data structures. providing a communication port. Requirements satisfaction R1 Natural repr. R2 Measurable models

No software process-specific constructs are provided. Variables may store measurementdata. No support for data collection is provided. 0 As far as Ada provides genericity. 0 Rograms are executable,but process engineers must agree on mapping concepts on constructs. - Not designed for interpretation by people. The process program's functionality is spread over several places (i.e.. tasks, triggers, predicates, transactions). + AppYA code is translated into Ada code. - Hard-coded control flow.The user selects altcmatives during process Nntime. - Products are global data structures. Task coordination is done by triggers and messages.

-

R3 Tailorable models R4 Formality

R5 Understandability

R6 Executability R7 Flexibility R8 Traceability

34

H. DIETER ROMBACH AND MARTIN VERLAGE

ods. Single process steps are implemented as methods. Logic expressions are checked when a method is called. If the value is “true,” pretriggers may react on this event being executed before the method’s program part. Post-triggers may follow method‘s activation (Belkhatiret al., 1993). Both triggers and methods have a program part that specifies the actions to be taken when the method is executed or the triggers reacts on an event. The program part is comparable to process programs in AppVA. The absence of software process-related concepts, scattering of process information on different types of objects and relations, and the need for implementing a process model with multiple triggers have led to the definition of a process representation language within the Adele project, called TEMPO (Belkhatir and Melo, 1993). TEMPO allows the definition of work environments which describe the context for a particular process step (i.e.. products, users, tools) along with its definition. To tailor each entity of a project representation to a special context, the concept role is introduced. In a role definition it is described, what the purpose of each entity in the context is [e.g., the role of each module in context of process release is a component to become part of the release, the role of the program manager in context of process release is to modify (i.e., process development) and test (Le., process validation) the components]. For illustration, an excerpt of a TEMPO process program is given here:

TYPEPROCESS r e l e a s e 1 EVENT r e a d y = ( s t a t e := r e a d y 1; ROLE USER = PManager; ROLE i m p l e m e n t development; ROLE v a l i d = v a l i d a t i o n ; module ; C ROLE component ON r e a d y D O i 2 I F i m p l e m e n t . t o - c h a n g e . X n a m e . s t a t e == r e a d y THEN 3 implement.to-change.Xname.state := a v a i l a b l e ;

...

The process definitions do not hide information. For example, the process type release has unrestricted access to information of process instances of type development. This has a negative impact on understandability and traceability. Nevertheless, because a database approach is used, additional features like different types of browsers may overcome these shortcomings of TEMPO. Table V gives an overview of TEMPO at a glance. It should be noted that TEMPO allows both prescriptive and proscriptive process definition styles. Proscriptive style is used for coordinating chunks of prescriptive process programs (e.g., see Belkhatir et al., 1993). But it is still an

DIRECTIONS IN SOFIWARE PROCESS RESEARCH

35

open question whether the prescriptive style is appropriate for interpretation by humans. If not, TEMPO is more suitable for tool integration purposes than providing support for humans.

5.2.3 HFSP A Hierarchical and Functional Software Process Description [HFSP] (Katayama, 1989) documents software processes as mathematical definitions. Activities are seen as functions, primarily characterized by input and output data. Complex process models are refined in less complex functions. Several constructors exist to combine the functional process models. Complex data structures are stored in an Objectbase. TABLEV CHARACTERIWTION AND EVALUATION OF TEMPO (ADELE) Characterization Process programming Adding dynamic features to a database for software development projects is the motivation for Adele. Hidden The user invokes processes and observes effects. The programs are not intended to be interpreted by the user. Mproscriptive Program parts of triggers and methods are prescriptive, whereas conditions for events allow proscriptive process specification. Multiperson Adele supports concumnt process execution of multiple users, but the coordination mechanisms are implemented in the system rather than be specified in the process models. Rquirements satisfaction

0 Rocess-specific concepts are included (Lea,role), but are still too general (e.g., human agents and products use the same language constructs). R2 Measurable models - Objects may store measurement data. No support for data collection is provided. R3 Tailorable models + Inheritance mechanisms are used to refine and specialize process models. R4 Formality 0 Programs are executable, but process engineers must agree on mapping concepts on ConstNcts. R5 Understandability - Because of the dynamic features of TEMPO,it is difficult to derive the complete semantics of a process description. R6 Executability + TEMPO programs are executed by the Adele kernel. R7 Flexibility + Events and triggers allow appropriate reactions on the cumnt project state. R8 Traceability 0 Loosely coupled processes hinder proper representation of context. Establishing explicit relationships is needed. R1 natural repr.

36

H. DIETER ROMBACH AND MARTIN VERLAGE

Human-based interpretation, nondeterminism, and incremental specification during enactment require flexible mechanisms to compute the value of the functions (i,e., the final product) (Katayama, 1989). Therefore, reflection is used to allow objects to operate on their own status. Two functions are provided to capture the actual process state (i.e., snap) and to explicitly set a state for a process (i.e., resume). This allows manipulation of complex process trees. Moreover, there are mechanisms used for communication between different process trees. If each developer has his or her own process tree, the communication mechanisms can be employed for supporting collaboration. Functions (i.e,, processes) within an execution tree run concurrently and possibly are nondeterministic. Scheduling of functions is performed on basis of the availability of data that the processes have as input. Mechanisms of the objectbase are used to interrupt the performance of a function if the requested data item is locked by another function.’ Nondeterminism is expressed by specifying different decompositions of a function. At the moment the aggregate function is to be executed, guards decide what decompositionof this function to select. For illustration, a function of a HFSP process description is given here6: Test-Unit

(

code, t e s t p k g , h i s t o r y . i n I h i s t o r y . o u t , feedback.code, feedback.pkg, r e s u l t ) ( code, t e s t p k g I r e s u l t )

=>do-test where ( result 1 f e e d b a c k . c o d e = modify-code-req f e e d b a c k . p k g = modify-pkg-req ( r e s u l t 1 h i s t o r y . o u t = append-history ( h i s t o r y . i n , result 1

The system to executdenact the functional descriptions consists of four major components that allow for planning, backtracking, exception handling, and communicating with the user. Table VI gives an overview of HFSP at a glance. HFSP was one of the first approaches offering support for the definition on several abstaction levels. The need for clear process interfaces is caused by the complexity of processes in real projects. To manage this complexity it should be able to offer well-structured process programs to the people who maintain the process descriptions. Obviously this should especiallybe true when the process models are intended to be read by humans.

5.2.4 MSL-Marvel Strategy Language The Marvel system is a process-sensitive SEE,managing products in a repository called the engineering database (Columbia University, 1991). Processes are

DIRECTIONS IN SOF’TVVARE PROCESS RESEARCH

37

TABLE VI CHARACTERIZATION AND EVALUATION OF HFSP Characterization Tool integration Tools are seen as atomic processes in HFSP. Hidden Project members activate functions but the execution is completely left to an execution machine. Prescriptive There is a strict control flow. Multiperson Several people can coordinate each having an own process tree. Requirements satisfaction R1 Natural repr.

R2 Measurable models R3 Tailorable models R4 Formality

R5 Understandability R6 Executability R7 Flexibility RE Traceability

-

No software process-specific constructs are provided. Functionshave no attributes. Each metric has to be defined as a separate data item. 0 Functions have formal parameters. But tailoring must be performed mostly by hand. + A functionaldefinition of processes and tools allows for formal process models. Nevertheless, the formal model comprises only a few constructs and seems not to be sufficient for all process engineering Purpo*S. 0 Because the functionality of a process completely relies on tools, it is difficult to determine what the effect of an invocation is. + Functions describing processes may run on a process engine. + Reflection, backtracking, and concurrency control allow contextdependent courses of action. 0 Within an execution tree formal parameters allow for traceability. Relationships between cooperating execution trees are difficult to follow.

-

described using a rule-based approach focusing on the automatable activities. A developer’s working environment is formulated as a strategy, consisting of three parts (i.e., entities with their relations, tools, and rules). Entities are defined using a data description language, comparable to constructs of programming languages (e.g., C). For each tool a so-called envelope has to be specified, describing how the Marvel objects are transformed to be accepted as tool parameters, and how the tool is called from the system. A rule consists of a pre- and a postcondition, which describe the valid states for starting and terminating processes, and an activity, which describes the rule’s functionality. Rules are defined independently from each other. Activities are comparable to shell scripts. The flow of control is determined by forward- and backward-chaining during enactment. Chaining analyzes the pre- and postconditions with respect to the current state of the engineering database. Forwardchaining determines, by matching the postcondition of the current executed rule with all preconditions of all other rules, what rules may fire next. Chains of several

38

H. DIETER ROMBACH AND MARTIN VERLAGE

rules are computed hypothetically. Backward-chaining works in the opposite direction, i.e., it determines for a specific rule what activities must be executed before the precondition becomes true. For illustration, a rule of a Marvel process description is given here6: editC?f:DOCFILEl: # i f t h e f i l e has b e e n r e s e r v e d , you can go ahead and e d i t i t (f.reservation-status C EDITOR e d i t ? f 3 (and (?f.reformat-doc CurrentTioe));

= Checked-out) = Yes) ( ? f . t i m e s t a m p

=

The opportunisticevaluation of nonhierarchicrules makes it hard to understand the control flow and data flow statically. Testing of strategies is required in order to validate the results of process modeling. The Marvel system itself has evolved from a single-user environment to a multiuser environment (Ben-Shaul et al., 1992). But no communicationprimitives were added to MSL. Instead, coordination rules have to be specified to describe conflict resolution when multiple rules interfere in their behavior. This is performed strictly on basis of the engineering database. Table VII gives an overview of MSL at a glance. MSL is a good example of a language that has both characteristicshidden and proscriptive. The user is not intended to interpret the process programs, but is able to direct the flow of control, restricted by the limitations of the rules.

5.2.5 MERLIN An approach similar to Marvel and MSL is the system MERLIN (Peuschel et al., 1992). MERLIN uses also rules for implementing process models, but offers a more sophisticated set of constructs to the process model developer than MSL. In particular, MERLIN uses the concept of a role to be able to delegate different work contexts to distinct project members. A work context contains all products to work on when performing a specific task. Different kinds of relationships between the products can possibly exist. In addition, there is a list of processes in each work context specifying the actions on the objects. A work context contains all necessary information for a role performing a technical product engineering process. Therefore the work context is a particular view on the current project state offering only the information to the role which is needed in order to perform a process. Work contexts related to the same piece of project data are updated when one user changes the information.

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

39

TABLE VII CHARACTERIZATION AND EVALUATION OF MSL Characterization Rocess programming The purpose of Marvel is to provide process integration for tools. Hidden The user activates processes from a menu, but the execution of shell scriptlike process programs is performed by the system. Pdproscriptive A rule-based approach is used for specifying single processes which are themselves described in a prescriptive style. Chains of processes are computed on basis of the actual state of the product data. Single/multiperson Marvel has evolved from a single-userenvironment to a system coordinating developers. Requirements satisfaction - No software process-specific constructs are provided. R1 Natural repr. R2 Measurable models - Attributes express product features. No support for data collection is provided. Rules are not instantiated and theEfore not measurable. R3 Tailorable models - Except for instantiation parameters MSL models need to be tailored by hand. R4 Formality 0 The shell-likelanguage for describing activities lacks of clear semantics. R5 Understandability - Because of the highly dynamic features of Marvel. it is difficult to derive the complete semantics of a process description. R6 Executability + Process programs are executable shell-scripts. R7 Flexibility + Rule chains are computed at runtime using the rules' conditions. Each rule specifies a particular process step, not considering any other processes. Adding new rules does (mostly) not affect the definition of already existing ones. RS Traceability 0 Loosely coupled processes hinder proper representation of context. Establishing explicit relationships is needed.

The formalism used in MERLIN to describe process models is a PROLOGlike language. Forward- and backward-chaining is performed, which both are more powerful than the mechanism employed in the Marvel system. The backtracking adopted from PROLOG allows hierarchies of preconditions which result in smaller process models (Peuschel and Schiifer, 1991). Tools are invoked by a CALL. An envelope is used to transform data maintained by MERLIN in a form understandable by the tool and vice versa. In addition to tool invocation, the specification of a rule may contain also actions on the data stored in the repository (e.g., remove, insert, etc.). It should be noted that MERLIN manages users, roles, documents, and relationships between them. No additional information (i.e., amibutes) is provided by the process models. For illustration, a programmer's role definition specifying access to processes of a MERLIN description is given here:

40

work-on

H. DIETER ROMBACH AND MARTIN VERLAGE

,

,

module to-be-edited C specification error-report, review], C module 3 C3 I . work-on ( r e v i e w to-be-reviewed C specification module I , t review 3 C3 I. work-on ( object-code, to-be-executed C specification module 3 11 [object-code 3 1. (

,

,

,

,

,

,

,

,

,

,

Instantiated work contexts form hierarchies during a project’s lifetime. On the one hand, work contexts of teams form the basis for building work contexts of the team members. On the other hand, the building of work contexts for teams uses information provided in larger work contexts (e.g., project work context). Thus the hierarchy consists of three layers: a projectwide, a team-specific, and a layer of individual work contexts. Like Marvel, the first version of MERLIN was designed as single-user system. Later versions included mechanisms for multiuser support. Different work contexts can be offered to different people. This is one of the main advantages of the MERLIN system. Table VIII gives an overview of MERLIN at a glance. MERLIN can be seen as a system in which the main ideas of Marvel are picked up. Its originality stems from the fact that MERLIN allows the role specific definition of work context to offer an user an encapsulated piece of the whole project state.

5.2.6 SLANG The SPADE environment is a system for developing, analyzing, and enacting process models described in the language SLANG (Space LANGuage) (Bandinelli er al., 1993b). SLANG allows for both process modeling in-the-small and in-the-large. Process modeling in-the-small means to operate on a level of fine granularity where a direct relationship between operating system entities (e.g., files, tools, ports, etc.) and process model elements exists. Process modeling inthe-large refers to the development of conceptual process models, which possess a well-defined interface for reuse and are refined in a systematic way. SLANG offers concepts for both levels based on Petri net formalisms. SLANG is designed to allow incremental definition of process models and dynamic (i.e., during project’s lifetime) evolution of these models (Bandinelli er al., 1993b). In SLANG, tokens represent both product documents and control information. Control information is related to return values of tool invocations (e.g., module-

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

41

TABLEVIII CHARACTWGXTIONAND EVALUATION OF MERLIN Characterization

Process programming MERLIN is designed to integrate tools. User may decide what course of Hidden Proscriptive Singlehnultiperson

action to take. The user does not see the language. An interface is provided to manipulate the objects of a work context. The rule-based approach allows an opportunisticcourse of action throughout the whole project. The concept of a role is employed. There is a n :m-relationship between people and roles. Requirements satisfaction

~~~~

~

R1 Natural repr.

+

R2 Measurable models

-

R3 Tailorable models R4 Formality

-

R5 Understandability

-

R6 Executability

+

R7 Flexibility

+

R8 Traceability

-

+

Several constructs of MERLIN allow easy mapping between the real world and the model world. Rules are not instantiated. They represent no objects which can be measured. Except by using parameters, tailoring has to be performed by hand. The language constructs have fued and clear semantics (e.g., several document access rights can be specified). Because of the highly dynamic features of MERLIN, it is difficult to derive the complete semantics of a process description. An inference engine was developed from scratch for MERLIN that is able to interpret all definitions. Rule chains are computed on runtime using the rules’ conditions. Each rule specifies a particular process step, not considehg any other processes. Adding new rules does (mostly) not affect the defdtion of already existing ones. Information about roles, processes. and work contexts is spread over several definitions. Traceability of the c m n t project state is established by the use of tools and not by the models themselves.

_compilecisuccessfully). It cannot easily be distinguished between products and control information. The product flow between tools needs to be extracted out of all tokens. Single process steps (i.e., tools or processingof control information) are represented by transitions. So-called black transitions refer to tools. Time constraints may be associated to transitions specifying when a transition has to fire (i.e., process the information). Different types of arcs relate places and transitions.There are normal arcs, specifyingdata flow, read-only arcs, specifying that a copy from a token is taken by the transition instead of consuming it, and overwrite arcs, destroying tokens already existing on a place. User interaction is realized by representing user input with tokens and special places (represented by double-line circles) containing these tokens. Activities are introduced in

42

H. DIETER ROMBACH AND MARTIN VERLAGE

SLANG to build modules which support process modeling in-the-large. Each activity has a well-defined interface (specified by places) and an implementation which is represented by a Petri net (Bandinelli et al., 1993). For illustration, a transition (event) and its associated guard (condition for tokens to be removed from the places) and action of a SLANG description are given here: E v e n t P r e p a r e For T e s t ( D F T E : E x e c T e s t , CTR: TestSummary; RET: E x e c T e s t , TRBC: T e s t Summary 1 Guard CTR.#PendingTests > O Action RET = DFTE; TRBC.TestingModule = CTR.Tetsing\odule; TRBC.Results = CTR.Results; TRBC.#PendingTests = CTR.#PendingTests

-1;

Activities are both abstractionsof Petri nets and tokens. This reflective approach allows for specifyingprocess models and process engines interpreting the models. The evolution of process models can be described in SLANG (Bandinelli et al., 1993a). In particular, the definition of activities may change over time. This does not affect already existing activity instances. The change is visible only for later instances of the activity definition. Table IX gives an overview of SLANG at a glance. The use of a Petri net formalism has the advantage that algorithms for analyses of Petri nets (e.g., deadlocks, reachability, etc.) are easy to adapt for process engineering purposes (see also Gruhn, 1991).

5.2.7 STATEMATE The STATEMATE system was intended to aid in specifying and designing real-time reactive systems (Hare1et al., 1990).The tool supports product engineering. It was then used at the Software Engineering Institute (SEI), CarnegieMellon University, to model software engineering processes (Humphrey and Kellner, 1989).The parts of STATEMATE discussed here are its three graphical representation languages. We call them briefly “Statemate.” The language activity charts is used to specify functions (what is done) in a structured analysislike fashion from the functional perspective. The language statecharts captures the behavior of processes (when and how it is done). The language module charts helps to specify the organizational aspects of the system or environment, documenting where and by whom a task is to be accomplished

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

43

TABLEIX CHARACreRlUnON AND EVALUATION OF SPADE Characterization Process programming Petri nets specify data flow between tools. Complex nets are encapsulated in abstract building blocks (i.e., activity definitions). Hidden Users of the models do not see the representation in SLANG. Interaction is managed by the process engine and by tools. Prescriptive Arcs between places and transitions exactly describe what course of action to take. Each project state transition has to be specified in advance. Multiperson User input is specified as tokens on special places. Multiple users are managed, but are not represented in the process models. The coordination mechanisms are completely implemented in the models. Requirements satisfaction - Each piece of information (e.g.. documents, messages, user input, etc.) is represented by a token. There are no special constructs for products or processes. R2 Measurable models - Transitionand token properties are fixed. No mechanismsfor specifying attributes exist. R3 Tailorable models 0 The constructs for modeling-in-the-largeallow for encapsulation. But tailoring has to be performed mostly by hand. 0 ER nets (timed high-level Petri nets) are the formal basis of SLANG. R4 Formality But process engineers must agree on mapping conceptson constructs. R5 Understandability 0 Overall functionality of concurrent processes is difficult to understand. + The Petri nets used for process modeling are completely executable. R6 Executability + Late binding allows for changing models at runtime. The Petri nets R7 Flexibility themselves describe a fixed set of alternatives. Once a process model starts to be executed, only the internal definition of subprocesses to be executed in advance is allowed to be changed. + Activities and SLANG models give coherent infomtion about R8 Traceability single process steps. Process are directly c o ~ e ~ t by e da m representing product and information flow. R1 Natural repr.

(Kellner and Hansen, 1988). Abstraction hierachies may be expressed using these three notations. After modeling each view, the separate views of a software engineering process are connected subsequently to provide a comprehensive model of the real-world activity. Because of Statemate’s intended use (development of products), the languages lack special constructs for representing concepts dependent on software engineering processes. One of Statemate’s advantages is that it allows for modularizing process models with respect to different aspects (i.e., the perspectives). This eases understanding and modeling of processes. For illustration, a graphical representation (Fig. 5 ) and a textual definition of an activity in Statemate is given here6:

44

H. DIETER ROMBACH AND MARTIN VERLAGE

:T E S T m L S DEV-CODE MODIFY-CODE

i SW-DEVELOPMENT-FILES

c TEST-UNIT FDBK-RE-TESTS

-

FIG.5 . Activity chart of TEST-UNIT.

A c t i v i t y TEST-UNIT Type: INTERNAL Sub o f : TECHNICAL-STEPS D e f i n e d i n c h a r t : FUNCT-1 Description: Functional description f o r the p r o c e s s s t e p TEST-UNIT Imp 1emen t ed b y n o d u 1e : ORGAN-1: UN IT-T E ST-T E AN O u t p u t c o n d i t i o n s : FUNCT-1:REWORK-TESTS; F U N C T-1: R E W 0 R K-C 0 D E ; FUNCT-1 :PASSED; In p u t d a t a it ems : 0 RG AN-1 :HO D-U N IT-T E S T-PKG ; ORGAN-1:OBJECT-CODE; O u t p u t d a t a - i t e m s : ORGAN-1:COVERAGE-ATTAINED; ORGAN-1 :TEST-RESULTS; ORGAN-1: FDBK-RE-TESTS; ORGAN-1 :FDBK-RE-CODE; ORGAN-1: T E ST-S U C C ES S ;

-

The languages allow for several analyses. Consistency, completeness, and correctness of several aspects of a process model are checked (e.g., balance of information flow between different levels of abstractions, missing sources and targets of information, reachability, or loops in definitions). Moreover, STATEMATE allows for simulating the specifications. This validation facility prior to project enactment is very helpful when trying to observe dynamic aspects of the defined process models. The traces recorded during simulation are later analyzed in order to find model faults or to make quantitative predictions. STATEMATE

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

45

produces also executable code in the programming language C. Nevertheless, there is the problem to integrate tools into the process definition. Table X gives an overview of Statemate at a glance. STATEMATE is an example for using languages not originally developed for software process research. Other examples exist which use approaches designed for product development (e.g., see Saracelli and Bandat, 1993). They mostly use a specification or design language [e.g., Structured Analysis Diagram Technique (SADT)]. In general, those attempts are helpful for software process researchers in order to relate concepts of products and processes.

5.3 MVP-L MVP-L is the process modeling language of the MVP project (Multiview Process Modeling). The MVP project began at the University of Maryland, College Park, Maryland, and continues at Universitiit Kaiserslautern, Germany (Brtkkers et al., 1992). The MVP project aims at providing support for modeling, planning, enactment, measurement, recording, and packaging of software engineering processes. The main idea is to split process descriptions into views, each TABLE X CHARACTERIZATION AND EVALUATION OF STATEMATE Characterization Improvement STATEMATE is used to investigate concepts to ease understanding of processes and process models. Guidance The process description is intended to support project people, although the system itself is not used for managing project states. Prescriptive State transition diagrams and functional decompositiondescribe a strict control flow. Multiperson The examples developed by Kellner and co-workers are intended to-coordinatetasks of multiple engineers and teams. Requirements satisfaction

- No software process specific constructs are provided. R1 Natural repr. R2 Measurable models 0 Project trace can be recorded. A static set of properties is taken. R3 Tailorable models - Except by using parameters, tailoring has to be performed by hand. 0 Statemate’s charts are formal. But process engineers must agree on R4 Formality mapping concepts on constructs. R5 Understandability + Diagrams modularize processes with respect to different aspects. + Process models are simulated or code is generated. The capabilities R6 Executability for tool invocation are limited. - Changing the models is not allowed during execution. Each alternative R7 Flexibility course of action has to be planned in advance. + The three charts disDlav well-structured information. R8 Traceability

46

H. DIETER ROMBACH AND MARTIN VERLAGE

view is generally defined as projections of a process representation that focus on selected features of the process. The language MVP-L was designed with respect to: natural representation, representation of different kinds of elementary models, use of formal process model interface parameters, and instrumentation of software engineering processes for data collection. MVP-L’s basic concepts are models to describe products, processes, resources (i.e., humans and tools), and attributes which are related to the former three concepts. Attribute values correspond to measurement data collected throughout a project. The attributes along with the process, product, and resource model instances can be used to guide developers or inform management about the process states. In addition to guidance, attributes allow improvement processes to observe product, process, or resource objects in order to evaluate new introduced technology or to identify problems during analysis. The example in Fig. 6 shows a MVP-L process model describing a test process named Test-UnifStnrcfurul. The textual representation is only one style of displaying models to the process model builder or user. The processinterface lists the attributes of the process (exports) and the criteria for starting and terminating the process (entry-exitcriteria). The process model is an elementary one, that means that it has no refinement (i.e., there are no subprocesses). Instead the processbody contains the keyword implementation and a comment. This means that this process step is completely performed by humans, instead of being executed by the process engine. The processresources describe what agents should perform the process and what tool support is available for them. The language MVP-L was designed to support measurement activities within software development projects. The basic concepts were captured by interviewing project members at different organizations. The notations was validated in several industrial projects (e.g., Klingler et ul., 1992). Table XI gives an overview of MVP-L at a glance. A project plan in MVP-L instantiates multiple process, product, and resource models with their associated attributes. This set of objects is a representation in the model world for the activities, software documents, and agents in the real world. It is important to note that there is only a single representationof the project. All roles participating in a project retrieve information from that representation. Communication is enabled through use of the project’s representation described using MVP-L. The textual process description (as shown in Fig. 6) is suitable for machine interpretation. Humans need more sophisticated presentations of the models and the project state. Moreover, each role in a project has particular information requirements. There is a need for building excerpts from the models and the states. These views offer tailored support to any role. It is one of the major goals within the MVP project to develop standard views for typical project roles. For example, a project manager might be interested only in the task

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

47

proceu-model Test-Unit-Structural ( eflO: Proceu-effort ) m i procw-interface importr product-model Source-Code, Object-Code, Driver, Results, Stub, Test-Package, Coverage-Re~ults; procau-attribute-model Process-effort; exports eff : Process-effort := em; product-fiow conmume IC : Source-Code; oc : Object-Code; It : Stub& dr : Driver; produce cr : Coverage-Reoultq consumegroduce tpckg : Test-Packqe; context en try-exit-criteria local-entry-criteria (tpckg.coverage < 0.9) and (tpckg.mtatua = 'complete') and (oc.status = 'complete') and (dr.status = 'complete') and (kstatus = 'complete') and (crstatw != 'complete') and (mc.complexity > 10); global-entry-criteria local-exit-criteria (cr.status = 'complete'); global-exit-criteria end process-interiece process-body implementation -- Goal OJ fhir procerr i s f o apply the f c r f data fo fhe module. The generic coverage fool Aor t o be used. The coverage valuer are fo be inrerfed i n f o the rclafcd atiribute. end process-body process-resources person nel-assignment imports resource-model Tert-Engineer, Manager; objects tester : Test-Engineer; m g : Manager; tool-assignment iniports resource-model Code-Coverage-Tool; objects gct : Code-Coverage-Tool; end process-resources end process-model Test-Unit-SLructurd

----

FIG.6. MVP-L process model describing a test process.

breakdown structure and process attributes like state and effort. In particular, within the MVP project the GQM approach (Basili et al., 1994b) is used to define views on the project state in terms of measurementdata.The informationpresented to the manager might look like as shown in Fig. 7. The figure shows a task breakdown structure of a well-known reference example (Kellner et al., 1990). The view displays condensed information about the

48

H. DIETER ROMBACH AND MARTIN VERLAGE TABLE XI CHARACTERIZATIONAND EVALUATION OF W P - L Characterization

Improvement The language was designed to support the QIP. Several real-world activities were modeled and extended by measurement activities. Guidance MVP-L is intended to be interpreted by humans. A project state is managed by the MVP-System. Proscriptive A rule-based approach is employed. No control flow constructs are provided. Multiperson Humans may assume different roles and are assigned to processes in an unrestricted way (n : m-mapping). Requirements satisfaction

R1 Natural repr. R2 Measurable models R3 Tailorable Models

R4 Formality

R5 Understandability

R6 Executability

R7 Flexibility R8 Traceability

Main concepts of software development processes are considered in MVP-L one-to-one. Attributes are directly related to measures derived by using the GQM approach. Except of instantiation parameters MVP-L models need to be tailored by hand. The purpose is to design processes. The basic features are well-defined but there are minor ambiguities (i.e., in the definitions of multiple instantiations of objects (*-operator) and consistency between different levels of abstraction). MVP-L was designed by analyzing interviews with developers. The language reflects concepts of their understanding. The rule-based approach makes it sometimes difficult to determine the course of action in advance. MVP-L mainly supports processes enacted by humans. Interfaces between processes are managed, a project state is managed. Tool invocation is directly supported for measurement tools. Access to development tools is provided but they are not automatically invoked. Processes may be added or deleted without affecting other ones. Entry and exit criteria allow for specifying consistency constraints for the interpretation of models. Several relationships between objects ease browsing. Special ones only appear in project databases and are not considered in MVP-L (ex., uses-relationship between modules).

effort spent so far in the project and the state of each task which is listed in the project description. The process Test-UnitStrucfurul in the right-lower comer is the one described in Fig. 6. This view presents a snapshot of the project state. It could be used to monitor progress of the project or to control resources. Another example of a view derived from an MW-L description is shown in Fig. 8. This view is derived in order to guide a test engineer by providing information about the task the role has to perform.The objects on the left side

49

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

Legend:

I :nfinuncnt FIG.7. A project manager's view.

refer to products that are modified (i.e., testdocument) or read (i.e., module). The boxes in the middle denote activities that are to be performed by the human, which assumes the role test engineer; the round-cornered boxes denote intermediate results. It is intended that either restlrnitfunctioml or test-unitstmcturul is performed when enacting the process steps. The information on the right side shows the entry and exit criteria for each process (because of limited space the

...........

,' test-document

',

....................

tcstulun.statur = 'complete' A

tutguckagc.stutus = 'incomplete' tcstjackage.stutus = 'complete'

............. - - - - - - - - -.

...

,' module

vulidatc ....................

FIG.8. A test engineer's view.

aourte-code.compcxity z 10

... A cov-m.covcrage

> 0.9

specifiution.statur = 'complete' A rcsulu.rtamr = 'complete' testgrchgc.rtatus = 'complete' ( hilurcs.rtntus = 'complete' A failurcs.failurc-count= 0 ) v ( fuilurcs.stutus= 'complete' A failures.Mure-count > 0 )

A

............

A

50

H. DIETER ROMBACH AND MARTIN VERLAGE

criteria for functional and structural testing are (partially) omitted). The four circles in the middle of Fig. 8 denote attributes that possibly are used in a process criteria to specify control flow (e.g., the use of the coverage value in the tesr-unitstructurul s exit criteria). The dashed lines indicate aggregating objects of a higher abstraction level. The language MVP-L was used in several industrial projects to model technical processes (e.g., see Klingler et al., 1992). The experience gathered from the case studies helped to improve the formalism. Additionally, suggestions for tool support were made. Prototypical tools were developed (e.g., syntax-directed editor, model browser, consistency checker) and are used in projects between industry and the Software Technology Transfer Initiative Kaiserslautern (STTI-KL).

6. Support for Software Engineering Processes The focus of software engineering in the 1970s and 1980s was clearly on the product. Software process research has contributed to the understanding of software development. Emphasis on software development activities resulted in a better support for both product and process engineering processes. The ideas and approaches developed so far in the software process research community are present in a variety of tools. In general, we can distinguish between tools for developing software process models and tools for interpreting the models (i.e.. process-sensitive SEEs). In this section, a brief discussion about tool support for software process engineering processes is given in order to point out how future softwaredevelopmentand improvement of software engineeringknow-how could look like. In particular, Section6.1 presents some tools for process model development, Section 6.2 discusses process-sensitive SEEs, and finally Section 6.3 introduces the process-sensitive SEE MVP-S.

6.1 Tools for Process Model Building and Project State Browsing Tool support for process engineering is needed as for product engineering. Most of the systems developed for execution of process descriptions consist also of componentsfor management of process models. In this subsection we illustrate what tools are available for support of process model building and browsing of the project state. The structure of the brief overview is oriented toward the benefits Bl-B4 in Section 4.1. This issue is related to B5, process-sensitive SEEs, discussed in the next section. Tools for supporting human communication are needed because textual data entry and verification of process models is error-prone and it is difficult to

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

51

conceptually grasp the nature of the process models in textual from (Krasner et al., 1992). The tools can be classified either as filters or as translators. Filters reduce a representation’s complexity by removing information fsom a process model. This is helpful when one concentrates on a few aspects of a model (e.g., product flow). Translators build a representation of a model in a different style or language (e.g., graphical).Mostly a combination of both is present in a language system (e.g., browsers for displaying process model relationships). Graphical editors (which are filters and bidirectional translators) allow partial specification of a process model. Textual input is required to add more detailed information [e.g., RocessWEAVER (FernstrOm, 1993)l. Packaging of experience is the issue supported most weakly by existing model management tools. In particular, we know of only two examples where it is able to relate process models and experience (Le., Decker and Valett, 1992; Oivo and Basili, 1992). Data about product and process qualities is attached to objects or the corresponding models to allow use of experience in other projects. The Software Management Environment (Decker and Valett, 1992) does not use executable process models but is a good example of how improvement is supported in an organization. Analysis and reasoning is supported in several ways. In general, one can distinguish between analyses for checking static and dynamic properties, and simulation. Checks for static properties include parsing, type checking, completeness, and other checks comparable to those performed by a compiler for a usual programming language. Each system containing a process engine has a more or less powerful component to check for static properties. This is especially true for all approaches presented in Section 5. Checks for dynamic properties are based on a formal definition of process model behavior and allow for detection of properties like reachability of a particular state, or deadlocks. Petri net-based approaches offer such support more frequently than other approaches [e.g., the SPADE environment (Bandinelli et al., 1993b)l. The reason is that Petri net formalisms have a formal foundation. Algorithms developed for Petri nets in general can be adapted for process modeling. Simulation of project plans is useful when dynamic properties cannot be detected on a formal basis. The STATEMATE tool is the one introduced in Section 5 which has the most advanced facilities for observing process behavior. Tools for supporting project guidance and control offer particular views on project states. Often a graphical representation is provided to present the user the objects accessible and the processes the user is allowed to perform (e.g., Marvel, MERLIN). If graphical notations are used for model building, these languages are also used during interpretationto display process state information [e.g., RocessWEAVER (Fernstr6m, 1993)l. Sophisticated tools offer query mechanisms to provide answers for particular user questions (e.g., list all modules with state “coded”). An example can be found as part of Adele.

52

H. DIETER ROMBACH AND MARTIN VERLAGE

6.2 Process-Sensitive Software Engineering Environments The first generation of software engineering environments mainly supported performing technical processes. Management and process engineering processes were only supported frequently. Modern software engineering environments provide “automated support of the engineering of software systems and the management of the software processes (European Computer Manufacturers Association, 1993).” This definition includes support for all software engineering processes (i.e., product and process engineering above). Several schemes exist for classifying software engineering environments (for a sample list it is referred to Fuggetta, 1993). The environments are distinguished with respect to many dimensions. One of them distinguishes between classes of tool integration, i.e., how tools work together in the same environment (Thomas and Nejmeh, 1992): Presentation integration means that the tools’ appearance and behavior is similar and all tool realizations rely on the same interaction paradigm. 0 Data integration enables maintenance of consistent information being exchanged between tools. Format, meaning, and data must be known for each tool accessing the data. 0 Control integrarion complements data integration by allowing tools to share functionality. Functions are provided and used by other tools. 0 Process integration means the strength of a tool-set to support an entire process, to react in the same way on events, and to enforce constraints which restricts the some aspect of the process (i.e., constraints on data and process state.) 0

The task for software process research is to provide mechanisms for integration of tools to build process-sensitivesoftware engineering environments. Such environments promise an improvement over pure product-oriented environments in offering better support for coordinating developers (Penedo and Riddle, 1993). In general, the interpretationof an explicit process description allows determining the way tools interact. All of the languages discussed in Section 5 can be used to formulate process descriptions that can be understood by process engines. For example, AppUA is the language designed for the Arcadia environment. The process-sensitive software engineering environments developed so far focus on specific issues. A comprehensive discussion is out of the scope of this paper. We refer for example to Penedo and Riddle (1993). First versions of such environments are commercially available to support software development organizations (e.g., Christie, 1994). Several other systems exist as research prototypes (a sample list can be found throughout Section 5 ) . Nevertheless, automated and integrated support for process engineering processes is rare. An overview of measurement support for example can be found in Lott

DIRECTIONS IN SOFWARE PROCESS RESEARCH

53

(1994a). At the moment it seems that each process engineering process is supported by locally operating tools, but integration has not yet been accomplished. Current process-sensitive SEES tackle only a few problems of real software projects [e.g., backtracking in MERLIN (Peuschel and Schiifer, 1991) or process evolution in SPADE (Bandinelli et al., 1993a)l. The challenge now is to integrate all the ideas and solutions.

6.3 MVP-S The MVP (multiview process modeling) project at Universitiit Kaiserslautem aims at providing an environment for modeling and analyzing process models, instantiating them in project plans, enacting the plan by a process engine, recording project data, and packaging experience in explicit process and quality models. This environment is called MVP-S. Process models and a project plan are described in MVP-L (Section 5.3) using the modeling facilities of MVP-S. This plan is instantiated by the process engine to serve as an information system of the project. Moreover, the explicit project state maintained by MVP-S builds the context for development tools, and specifies dependencies between development processes. Project traces and measurement data are used later on to derive information about product and process qualities in order to improve the knowledge concerning software development and process performance. Figure 9 shows the overall design of MVP-S. The system is divided into three parts. Services are offered to the users of the system in order to manipulate models, project plans, and project states. Tools provide the functionality of MVP-S with respect to models and project plans. The object management systems maintains persistent objects, like models, project states, products, or measurement data. The grey shaded boxes refer to system parts which are already realized in a prototypical manner. Each of those subsystems needs to be evolved in order to provide a rich framework for supporting product and process engineering processes as described in Section 4.1. The current research prototype realizes the basic ideas presented in Lott and Rombach (1993). Measurement-based project guidance of product engineers is supported by MVP-S. First solutions with respect to multi-view modeling and packaging of experience exist. Multi-view modeling means to allow project members to describe their particular view on the processes they are involved in. Later integration is performed to build a comprehensive software process models out of the single views (Verlage, 1994). Packaging of experience is done either by building new model versions (e.g., specifying stronger criteria, or providing fine-tunedprocess refinements) or by adding quantitativedata to models or objects in the experience database. The design of MVP-S should not be understood as a general architecture for process-sensitive software engineering environments. Instead it should illustrate

54

0

H. DIETER ROMBACH AND MARTIN VERLAGE

-.objects( m o d c poduct. ~ { ~ ~p,m~c~w~UqM q. ... u a) l i t.,.Iy . G Q M .

project databaae project plans

-.GQMI

.pmduas

-. FIG.9. Functional design of MVP-S.

-.measurement data project wce

uses

what services are relevant for software engineering support. The need for each tool is caused by our definition of software engineering in Section 1.2. Building comprehensive object management systems for software development organizations which support process-sensitive software engineering environments is a complex problem domain for its own (Estublier, 1994). To give satisfactory solutions in all these areas is far beyond the goals of the MVP project. Moreover, to provide a complete set of support technology is a task for the whole process community.

7. Future Directions in Software Process Research Software process research originated because of the need to understand and manage software engineering processes. Economic pressure motivates organizations to invest in this area. Research should provide solutions to problems encountered in practical software projects. Answers to questions about the nature of software and softwaredevelopment should also be given in order to move software engineering from an art to a discipline. We now give a partial list of future activities in software process research both from a practical and a research perspective.

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

55

7.1 Practice Currently, the importance of process engineering has been recognized by industry. Especially the work on software maturity and CMM by the SEI has contributed to this increasing awareness (Humphrey, 1989, 1991). Process improvement groups are being established in many companies. However, most of the work performed by these groups can be characterized as organizational, informal, and qualitative. Explicit formal process models are rare (e.g., Klingler et af., 1992). Furthermore, many process measurement groups are being established in companies. However, most of the work performed by these groups can be characterized as exploratory (not tied to company goals and not based on a sound measurement process) and isolated (not related to explicit process models and therefore not contributing to process improvement). Sound measurement processes are rare (e.g., Pfleeger and Rombach, 1994). Most software process representation languages do not reflect practical needs (see the tables in Section 5). are not documented well, and are not supported by appropriate tools. Only a few languages have been used in real pilot projects, and only few tools and process-sensitive software engineering environments can be bought (e.g., see Christie, 1994). Nevertheless, it is important that industrial environments contribute to the further improvement of process technology by providing laboratory environments to: 0

0

0

Test existing technologies in pilot projects: Only studies and experiments in practical projects enable software process researchers to identify the strengths and weaknesses of existing technologies. Thereby, requirements and suggestions for further improvement are derived. Develop explicit models of their current processes, so the appropriateness of existing languages can be tested. The value of reference examples is demonstrated within the community (Kellner and Rombach, 1990; Kellner et al., 1990). Additionally, external process models are helpful to demonstrate suitability and point to problems (Klingler et af., 1992). Build prototype tools to support model building. Almost all of the actual process-sensitive environments require fine-grain process programs. Development and maintenance of these models needs effort that is difficult to justify. Building blocks or abstract languages are needed to ease modeling activities.

7.2 Research Software process research is a growing field of interest. Several forums allow for discussing process related issues and exchanging ideas (e.g., International Conference on Software Process, several sessions at the past InternationalConferences on Software Engineering [ICSE], International Software Process Work-

56

H. DIETER ROMBACH AND MARTIN VERLAGE

shops [ISPW], European Workshops on Software Process Technology [EWSFT], Workshop on Process-Sensitive Software Engineering Environment Architecture [PSEEA], Japanese Software Process Workshop [JSPW]. But there is still a demand for further research: 0

0

0

0

0

0

Provide a comprehensive, consistent framework and terminology for software process research. First steps toward this directions have been made (i.e. Conrad et al., 1992; Feiler and Humphrey, 1993; Lonchamp, 1993). But further efforts are needed to develop a common understanding in this rapidly emerging field, This is especially needed when solution islands developed so far are to be integrated. Business process (re)engineering is a related area (Swenson, 1993). Only a few attempts have been made to compare both fields with each other. Commonalities and differences between both areas have to be identified in order to compare them and to transfer solutions from one domain into the other. Team support requires special mechanisms. Computer Supported Cooperative Work (CSCW) researchers have developed models for coordinating the work of people with explicitprocess descriptions outside the process research area (Grudin, 1994). Software process researchers should investigate how far the solutions can be adopted. If they cannot be employed in processsensitive environments, it has to be checked what specialities restrict the adoption of technology from the similar CSCW domain. Process-sensitive software engineering environments have a potential to support the entire set of roles in a software project (Christie, 1994). Technicians and managers have to share the same project representation. This enables new concepts of guidance and coordination (Lott and Rombach, 1993). Measurement is supported and feedback about product and process qualities is given on-line to all interested parties. Methods for modeling software processes are needed in order to allow systematic development of process models. Most examples apply methods for product development in the process domain. But, tailored solutions are needed. It should be possible to define process models from different perspectives (e.g., developer, project manager, quality assurance engineer, etc.). Each of these role emphasizes different aspects of the process (Rombach and Verlage, 1993). An approach is needed to integrate the different views of these roles (Verlage, 1994). Project planning can use the explicit models to formulate project plans and attach quantitative goals to each process instance (e.g.. to specify deadlines or quality goals) (Saracelli and Bandat, 1993). An idea of combining approaches for measurement and project planning is given in Lott and Rombach

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

0

0

57

(1993). But more effort is needed in order to provide an integrated support for all participating roles. Project plans mostly do not remain stable over a project’s lifetime. Replanning is required to modify the plan according to the changed environment. Mechanisms for process evolution have to be provided (Conradi et al.. 1993). Some attempts have been made to tackle that problem (e.g., Bandinelli et al., 1993a). But more research has to be done in order to allow change of process models during enactment. Presenting process information to the user and the interaction paradigm between process engine and the engineer are crucial for the success of software process research results (Krasner et al., 1992). Graphical user interfaces should be tailored to the specific needs of humans when they are concerned with specific tasks. These interfaces should allow easy access to data and present the data in an understandable form. But presentation is not only a question what adequate presentation formalism to choose but moreover mechanisms for offering views on the project state are required.

8. Summary Software plays a crucial role in our lives. Therefore it is not acceptable that software is developed and maintained in a handcrafted way. Software needs to be developed and maintained in a predictable and certifiable way. This requires sound engineering principles. The principles are embodied in the methods, techniques, and tools used for development and should be recognized in the activities performed. Nevertheless, current engineering knowledge is of an unsatisfactory kind and diversity of development environments make it impossible, at least for the moment, to set up general rules which guarantee proper quality of software products when strictly followed. Therefore the product engineering processes are itself an object of study. Process engineering processes are performed to support and improve the product engineering processes. A framework integrates both kinds of processes by classifying project related and organization related processes (Section 4). It is oriented by the experience factory idea (Basili et al., 1994a). The experience factory approach illustrates the relationships between the different processes, which may become complex. Managing the processes needs support. The main focus of process engineering processes is on the activities which develop software, and therefore it is needed to document the product engineering processes. In particular, improvement, reuse, measurement, and modeling and planning benefit from explicit representations of process elements and their relationships in various ways. Supporting communication, structuring, analysis,

58

H. DIETER ROMBACH AND MARTIN VERLAGE

reasoning, guidance, control, and automation allows the design of improved processes through modification of the models. Notations are needed to capture the relevant aspects of the processes. Various suggestionswere made in recent years. A spectrumof example process representation languages is given in this chapter. Each of these languages tries to support at least one of the process engineering processes by addressing some of the benefits. The value of each process representation language in a particular context depends on the kind of support for each process engineering process. To allow reasoning about each language’s contribution, a three-step approach is taken: (1) It is stated how process engineering processes profit from explicit process models (Section 4.1), (2) requirements are set up which have to be fulfilled for achieving the benefits (Sections 4.2 and 4.3), and (3) for each language it is stated how far it fulfills the requirements (Section 5). Tracing this information from the back to the front gives an impression about how a language supports a particular process engineering process. Automated support for process model management exists in form of tools and process-sensitive software engineering environments. A brief discussion of already developed systems is given in Section 6. The sample set of process representation languages and software engineering environments is not expected to be a complete set offering solutions for each problem in the area of process engineering. Each of them tackles a distinct problem. Integration of the solutions is needed to offer comprehensive support. Moreover there are open issues that justify additional research effort. A tentative research agenda is given in Section 7.2 in order to give a flavor about what users of software process technology can expect Erom the community in the future, ACKNOWLEDGMENTS The authors would like to thank the entire research group at Universitiit Kaiserslautem for fruitful discussions and inspirations. All members of the Arbeitsgruppe Software Engineering have made a personal contribution to this work.

ENDNOTES I

The reuse process is represented by sub-processesto show the relationshipsbetween organizational

units in more detail.

* In fact, this is exactly the same way the various product engineering processes were introduced in Sec. 1.3. This is exactly the reason why the term reuse was not introduced as a product engineering process. The two boxes labeled Project Data Management and Product Management of Fig. 2 are part of the project database in Fig. 4. Also called process-centered or process-based. Taken from Example Solutions to a Common Process Modeling Problem Handout at the 6th International Software Rocess Workshop, Hakodate, Japan, October 1990. In the references nothing is stated about the deadlock problem.

’

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

59

Abdel-Hamid, T. K.(1993). A multiprojectperspective of single-project dynamics. J. Syst. Sofhvare 22(3), 151-165. Armenise. P., Bandinelli, S.,Ghezzi, C., and Monenti, A. (1992). Software process languages: Survey and assessment. In “Proceedings of the 4th Conference on Software Engineering and Knowledge Engineering, Capri, Italy,” pp. 455-462. IEEE Computer Society Press, Los Alamitos, CA. Bandinelli, S. C.. Fuggetta, A., and Ghezzi, C. (1993a). Software process model evolution in the SPADE environment. IEEE Trans. Sofrware Eng. SE-19(12), 1128-1 144. Bandinelli, S.C., Fuggetta, A., and Grigolli, S.(1993b). Process modeling in-the-large with SLANG. In “Proceedings of the 2nd International Conference on the Software Process” (L. Ostemeil, ed.), pp. 75-83. IEEE Computer Society Press, Los Alamitos, CA. Basili. V. R. (1975). Iterative enhancement: A practical techniques for software development. IEEE Trans. Sofnvare Eng. SE-1(4), 390-396. Basili, V. R. (1992). Software Modeling and Measurement: The Goal/Question/Metric Paradigm,” Tech. Rep. CS-TR-2956. Department of Computer Science, University of Maryland, College Park. Basili, V. R. (1993). The Experience Factory and its relationship to other improvement paradigms. In “Proceedings of the 4th European Software Engineering Conference” (I. SommeMlle and M. Paul, eds.), Lect. Notes Comput. Sci., No. 717. pp. 68-83. Springer-Verlag, Berlin. Basili, V. R., and Rombach, H. D. (1988). The TAME Project: Towards improvement-oriented software environments. IEEE Trans. Sofnvare Eng. SE-14(6), 758-773. Basili, V. R., and Rombach, H. D. (1991). Support for comprehensive reuse. Sofhvare Eng. 1. 6(5), 303-316. Basili, V.. Caldiera, G., McGany, F., Pajersky, R., Page, G.,and Waligora, S.(1992). The Software Engineering Laboratory-an operational Software Experience Factory. In “Roccedings of the 14th International Conference on Software Engineering,” pp. 370-381. ACR, New York,NY. Basili, V. R., Caldiera, G., and Rombach, H. D. (1994a). Experience Factory. In “Encyclopedia of Software Engineering” (J. J. Marciniak, ed.), Vol. 1. pp. 469-476. Wiley, New York. Basili, V. R., Caldiera,G..and Rombach, H. D.(1994b). Goal question metric paradigm.In “Encyclcpedia of Software Engineering’’ (J. J. Marciniak, ed.), Vol. I. pp. 528-532. Wiley, New York. Basili, V. R., Caldiera. G.,and Rombach. H. D. (1994c). Measurement.I n “Encyclopedia of Software Engineering” (J. J. Marciniak, ed.), Vol. 1, pp. 646-661. Wiley, New York. Bauer, F. L. (1972). “Software Engineering,” Information Processing. North-Holland Publ., Amsterdam. Bekhatir, N., and Melo, W. L. (1993). Supporting software maintenance processes in TEMPO. In “Proceedings of the Conference on Software Maintenance,”pp. 21-30. IEEE Computer Society Press, Los Alamitos, CA. Bekhatir, N., Estublier, J.. and Melo, W. L. (1993). Software process model and work space control in the adele system. In “Roceedings of the 2nd International Conferenceon the SoftwareProcess” (L. Osterweil, ed.), pp. 2-1 1. IEEE Computer Society Press, Los Alamitos, CA. Ben-Shaul, I. Z., Kaiser, G.E., and Heineman, G.T. (1992). An architecture for multi-user software development environments. In “Roceedings of the 5th ACM SIGSoftlSIGPLAN Symposium on S o h a r e Development Environments” (H. Weber, ed.), pp. 149-158. ACR, New York,NY. Appeared as ACM SIGSoft Sofrware Eng. Notes 17(5) (1992). Boehm. B. W. (1988). A spiral model of software development and enhancement. IEEE Compur. 21(5), 61-72. Brilckers,A., Lott, C. M., Rombach,H. D., Verlage,M. (1992). “MVPLanguageReport,” Tech. Rep. 229/92. Department of Computer Science, University of Kaiserslautern,Kaiserslautem, Germany. Christie, A. M. (1994). A Practical Guide to the Technology and Adoption of Software Process Automation, Tech. Rep. CMU/SEI-94-TR-007. Software Engineering Institute, Camegie-Mellon University, Pittsburgh, PA.

60

H. DIETER ROMBACH AND MARTIN VERLAGE

Columbia University (1991). “The 3.0.1 User’s Manual.” Columbia University, New York. conradi. R., Femswrn. C., Fuggetta. A., and Snowdon, R. (1992). Towards a reference framework for process concepts. In “Proceedings of the 2nd European Workshop on Software Process Technology” (J.-C. Derniame, ed.). pp. 3-17. Springer-Verlag, Berlin. Conradi, R., Fernswm. C., and Fuggetta, A. (1993). A conceptual framework for evolving software processes. ACM SIGSofr Software Eng. Nores 18(4),26-35. Curtis, B., Kellner, M. I., and Over, J. (1992). Process modeling. Commun. ACM 35(9), 75-90. Davis, A. M. (1990). “Software Requirements-Analysis and Specification.” Prentice-Hall, Englewood Cliffs, NJ. Decker W., and Vallet, J. (1992). “Software Management Environment (SME) Concepts and Architecture.” Tech. Rep. SEL-89-103. NASA Goddard Space Flight Center, Greenbelt, MD. Deming. W. E. (1986). “Out of the Crisis.” Massachusetts Institute of Technology, Cambridge, MA. Dowson, M., and Femswm, C. (1994). Towards requirements for enactment mechanisms. In “Proceedings of the 3rd European Workshop on Software Process Technology” (B. C. Warboys, ed.), Lect. Notes Cornput. Sci., No. 772. pp. 90-106. Springer-Verlag, Berlin. Estublier, J. (1994). What process technology needs from databases. In “Proceedings of the 3rd European Workshop on Software Process Technology” (B.Warboys, ed.), Lect. Notes Cornput. Sci., No. 772, pp. 271-275. Springer-Verlag, Berlin. European Computer Manufacturers Association (1993). “Reference Model for Frameworks of Software Engineering Environments,” Tech. Rep. TR-55. ECMA, Geneva. Feigenbaum, A. V. (1991). “Total Quality Control.” McGraw-Hill, New York. Feiler, P. H., and Humphrey, W. S. (1993). Software process development and enactment: Concepts and definitions. In “Proceedings of the 2nd International Conference on the Software Process” (L.Osterweil, ed.), pp. 28-40. IEEE Computer Society Press, Los Alamitos, CA. Feldman, S. I. (1979). Make-a program for maintaining computer programs. Softwure-Pract. Exper. 9,255-265. Fernswm, C. (1993). Process WEAVER: Adding process support to UNIX. In “Proceedings of the 2nd International Conference on the Software Process” (L. Osterweil, ed.), pp. 12-26. IEEE Computer Society Press, Los Alamitos, CA. and Isoda, S. (1994). Success factors of systematic reuse. IEEE Softwure 11(5), 14-22. Frakes, W., Fuggetta. A. (1993). A classification of CASE technology. IEEE Cornput. 26(12), 25-38. Fuggetta, A., and Ghezzi, C. (1994). State of the art and open issues in process-centered software engineering environments. J. Sysr. Sofrware 26(1). 53-60. Ghezzi. C., ed. (1994). “Proceedings of the 9th International Software Process Workshop, Airlie, Virginia.’’ IEEE Computer Society Press, Los Alamitos, CA. Gibbs, W.W.(1994). Software’s chronic crisis. Sci. Am., September, pp. 86-95. Gilb, T. (1988). “Principles of SoftwareEngineering Management.” Addison-Wesley,Reading, MA. Gish, J. W.,Huff, K., and Thomson, R. (1994). The GTE environment-supporting understanding and adaptation in software reuse. In “Software Reusability” (W. Schilfer, R. Prieto-Diaz, and M. Matsumoto. eds.), Chapter 6. Ellis Harwood, Chichester, England. Grudin. J. (1994). Computer supported cooperative work: History and focus. IEEE Compur. 27(5), 19-26. Gruhn, V. (1991). Validation and verification of software process models. Ph.D. thesis, University of Dortmund, Dortmund, Germany. Haase, V., Messnarz, R., Koch, G.,Kugler, H. J., and Decrinis, P. (1994). Bootstrap: Fine-tuning process assessment. IEEE Software 11(4), 25-35. Harel, D., Lachover. H.,Naarnad. A.. Pnueli, A., Politi, M.. Sherman, R., Shtull-Trauring, A., and Trakhtenbrot, M. (1990). Statemate: A working environment for the development of complex reactive systems. IEEE Trans. Softwure Eng. SE-16(4).

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

61

Heimbigner, D. (1990). Proscription versus prescription in process-centered environments.In “Proceedings of the 6th International Software Process Workshop” (T. Katayama. ed.), pp. 99-102. IEEE Computer Society Press, Los Alamitos. CA. Hoisl. B. (1994). “A Process Model for Planning GQM-Based Measurement,” Tech. Rep. STTI94-ME. Software Technology Transfer Initiative, Department of Computer Science, University of Kaiserslautern, Kaiserslautern, Germany. Humphrey, W. S. (1989). “Managing the Software Process.” Addison-Wesley, Reading, MA. Humphrey, W. S.(1991). Recent findings in software process maturity.In “Software Development Environments and Case Technology” (A. Endres and H. Weber, 4s.). Lect. Notes Comput. Sci., No. 509, pp. 258-270. Springer-Verlag,Berlin. Humphrey, W. S., Kellner, M. (1989). Software process modeling: Principles of entity process models. In “Proceedings of the 11th International Conference on Software Engineering,” pp. 331-342. IEEE Computer Society Press, Los Alamitos. CA. Humphrey, W. S.,Snyder, T. R., and Willis, R. R. (1991). Software process improvement at Hughes Aircraft. IEEE Sofrware 8, 11-23. International Standards Organization (1991a). “IS0 8402: 1991-Quality: Terms and Definitions.” ISO. International Standardization Organization (1991b). “IS0 9ooo: Quality Management and Quality Assurance Standards; Part 3: Guidelines for the Application of IS0 9001 to the Development, Supply and Maintenance of Software.” ISO, Geneva, Switzerland. Katayama, T. (1989). A hierarchical and functional software process description and its enaction. In “Proceedings of the 1lth International Conference on Software Engineering.” pp. 343-352. IEEE Computer Society Press, Los Alamitos, CA. Kellner, M. I. (1989). Softwareprocessmodeling:Value and experience.In “SEI Technical Review.” pp. 23-54. Software Engineering Institute, Camegie-Mellon University, Pittsburgh, PA. Kellner, M. I., and Hansen, G. A. (1988). “Software Process Modeling.” Tech. Rep. CMU/SEI88-TR-9. Software Engineering Institute, Camegie-Mellon University. Pittsburgh, PA. Kellner, M. I., and Rombach, H. D. (1990). Session summary: Comparisons of software process descriptions.In “Proceedings of the 6th International Software Process Workshop” (T. Katayama, ed.), pp. 7-18. IEEE Computer Society Press, Los Alamitos, CA. Kellner, M. I., Feiler, P. H., Finkelstein, A., Katayama, T., Osterweil. L. J.. Penedo, M. H.. and Rombach, H. D. (1990). Software process modeling example problem. In “Proceedings of the 6th International Software Process Workshop” (T. Katayama, ed.), pp. 19-29. IEEE Computer Society Press, Los Alamitos, CA. Klingler, C. D., Neviascr, M., Marmor-Squires, A., htt, C. M..and Rombach, H. D. (1992). A case study in process representation using MVP-L. In “Proceedings of the 7th Annual Conference on Computer Assurance (COMPASS 92);’ pp. 137-146. IEEE, New York, NY. Krasner, H., T e d , J.. Linehan, A., Amold, P., and Ett, W. H. (1992). Lessons learned from a software process modeling system. Comun. ACM 35(9), 91-100. Krueger, C. W. (1992). Software reuse. ACM Cornput. Sum. 24(2), 131-183. Leveson, N. G. (1992). High-pressure steam engines and computer software, keynote address. In “Proceedings of the 14th International Conference on Software Engineering. Melbourne. Australia,” pp. 2-14. ACR, New York, NY. Lonchamp, J. (1993). A structured conceptual and terminological framework for software process engineering. In “Proceedings of the 2nd International Conference on the Software Process,” (L. Ostemeil, ed.), pp. 41-53. IEEE Computer Society Press, Los Alamitos. CA. Lott, C. M. (1994a). Measurement support in software engineering environments. Inr. J. Somare Eng. Knowl. Eng. 43). Lon, C. M. (1994b). Data collection in a process-sensitive software engineering environment. In “Proceedings of the 9th International Software Process Workshop, Airlie, Virginia” (C. Ghezzi, ed.). IEEE Computer Society Press. Los Alamitos, CA.

62

H. DIETER ROMBACH AND MARTIN VERLAGE

La, C. M.. and Rombach. H. D. (1993). Measurement-based guidance of software projects using

explicit project plans. Inf: Sofrwure Technol. 35(6/7). 407-419. Madhavji. N.,Gruhn. V., Biters. W., and Schllfer, W. (1990). PRISM = methodology + processoriented environment.In “Proceedings of the 12th International Conference on Software Engineering,” pp. 277-288. IEEE Computer Society Press. Los Alamitos, CA. Matsumoto, M. (1992). Automatic software reuse process in integrated CASE environment. IEICE Trans. Inf: Syst. E75-D(5), 657-673. Morel, J.-M.. and Faget. J. (1993). The REBOOT environment. In “Proceedings of the 2nd International Conference on Software Reuse.” IEEE Computer Society Press, Los Alamitos, CA. Oivo, M.,and Basili. V. R. (1992). Representing software engineering models: The TAME goal oriented approach. IEEE Trans. Software Eng. 18(10), 886-898. Osterweil, L. (1987). Software processes are software too. In “Proceedings of the 9th International Conferenceon Software Engineering,” pp. 2-1 3. IEEE Computer Society Press, Los Alamitos. CA. Penedo, M. H.. and Riddle, W. (1993). Process-sensitive SEE architecture (PSEEA) workshop summary. ACM SIGSoft Software Eng. Nores 18(3).A78-A94. Perry, D. E..and Kaiser, 0. E. (1991). Models of software development environments. IEEE Trans. SoftwareEng. SE-17(3). 283-295. Peuschel. B.. and Schllfer, W. (1991). “Efficient Execution of Rule Based Persistent SoftwareProcess Models in MERLIN,” Tech. Rep. Memo No. 59. Lehntuhl Wr Software Technologie, University of Dortmund, Dortmund. Germany. Peuschel, B., Schiifer, W., and Wolf, S.(1992). A knowledge-based software development environment supporting cooperative work. Int. J. Softwure Eng. Knowl. Eng. 2(1), 79-106. Pfleeger. S. L., Fenton, N.,and Rombach. H. D., eds. (1994). “IEEE Software, Special Issue on Measurement-BasedProcess Improvement.” IEEE Computer Society Press, Los Alamitos, CA. Pfleeger, S.L., Fenton, N.,and Page, S. (1994). Evaluating software engineering standards. IEEE cornput. 27(9), 7 1-79. Potts, C., ed. (1984). “Proceedings of Software Process Workshop,” Egham. UK. IEEE Computer Society Press, Los Alamitos. CA. Prieto-Dim, R. (1991). Implementing faceted classification for software reuse. Commun. ACM 34(5), 89-97. Prieto-Dim, R., and Freeman, P. (1987). Classifying software for reusability. IEEE Sofrware 41). 6-16. Rombach, H. D. (1991a). “MVP-L: A Language for Process Modeling in-the-Large,” Tech. Rep. CS-TR-2709. Department of Computer Science. University of Maryland, College Park. Rombach, H. D. (1991b). Practical benefits of goal-oriented measurement. I n “Software Reliability and Metrics” (N.Fenton and B. Littlewood, eds.), pp. 217-235. Elsevier Applied Science, London. Rombach, H. D., Basili, V. R., and Selby, R. W. (1993). “Experimental Software Engineering Issues: A Critical Assessment and Future Directions,” Lect. Notes Comput. Sci., No.706. SpringerVerlag. Berlin. Rombach, H. D., Ulery, B. T., and Valett, J. (1992). Toward full life cycle control: Adding maintenance measurement to the SEL. J. Syst. Software 18(2), 125-138. Rombach, H. D.. and Verlage, M. (1993). How to assess a software process modeling formalism from a project member’s point of view. In “Proceedings of the 2nd International Conference on the Software Process” (L. Osterweil. ed.), pp. 147-158. IEEE Computer Society Press, Los Alamitos, CA. Royce, W. W. (1987). Managingthe developmentof large softwaresystems:Concepts and techniques. WESCON Tech. Pap. 14, All-1-All-9 (1970). Reprinted in “Proceedings of the 9th International Conference on Software Engineering, pp. 328-338. IEEE Computer Society Press. Los Alamitos, CA. 1987.

DIRECTIONS IN SOFTWARE PROCESS RESEARCH

63

Saracelli, K. D., and Bandat, K. F. (1993). Process automation in software application development. IBM S y ~ t J. . 32(3), 376-396. Shaw, M. (1990). Prospects for an engineering discipline of software. IEEE Sofrware 7 , 15-24. Sommerville, I., and Paul, M., eds. (1993). “Proceedings of the 4th European Software Engineering Conference, Garmisch-Partenkirchen.Germany,” Lect. Notes Comput. Sci., No. 717. SpringerVerlag, Berlin. Sutton, S. M.. Jr., Heimbigner, D., and Ostenveil. L. (1989). “Applla: A Prototype Language for Software Process Programming.” Tech. Rep. CU-CS-448-89. Department of Computer Science, University of Colorado at Boulder. Sutton, S. M.. Jr.. Heimbigner, D.. and Osterweil. L. J. (1990). Language constructs for managing change in process-centered environments. In “Proceedings of the 4th ACM SIGSoftlSIGPLAN Symposiumon Practical Software Development Environments,” pp. 206-217. Appeared as ACM SIGSofr Sofiware Eng. Notes 15(6), (1990). Swenson, K. D. (1993). Visual support for reengineering work processes. In “Proceedings of the Conference on Organizational Computing Systems.”Association of Computing Machinery, New York. Taylor, R. N., Belz, F. C., Clarke, L. A,, Ostenveil, L., Selby. R. W., Wileden. J. C., Wolf, A. L.. and Young, M. (1988). Foundations for the arcadia environment architecture. In “Proceedings of the 3rd ACM SIGSoftlSIGPLAN Symposium on Practical Software Development Environments” (P. Henderson,ed.),pp. 1-13. AppearedasACMSIGSofrSofiwareEng.Notes 1x5)(1988). Thomas, I., and Nejmeh, B. A. (1992). Definitions of tool integration for environments. IEEE Sofiware 9(2). 29-35. Verlage. M. (1994). Multi-view modeling of softwareprocesses. In “Proceedings of the 3rd European ) Notes Workshop on Software Process Technology, Grenoble, France” (B. C. Warboys, 4.Lect. Comput. Sci., No. 772, pp. 123-127. Springer-Verlag, Berlin. von Mayrhauser, A. (1990). “Software Engineering: Methods and Management.” Academic Press, San Diego, CA. Zultner, R. E. (1993). TQM for technical teams. Commun. ACM 36(10), 79-91.