Domain Modeling of Software Process Models

Hassan Gomaa, Larry Kerschberg, and Ghulam A. Farrukh George Mason University and The MITRE Corporation hgomaa@gmu.edu, kersch@gmu.edu, and farrukh@mitre.org

Abstract
This paper presents a novel application involving two important Software Engineering research areas: process modeling and software reuse. The Spiral Model is a risk-driven process model, which, depending on the specific risks associated with a given project, may be tailored to create a project-specific process model. The software reuse area is that of domain modeling of families of systems, which capture the similarities and variations among the members of the family. The domain modeling approach is used to create a domain model of a Spiral Process Model (SPM), thereby capturing the similarities and variations among a family of process models. The SPM domain model has been extended to capture the key process areas of the Software Engineering Institutes Capability Maturity Model. The domain model is used to generate projectspecific process models. This approach allows managers to configure and reuse process models that manage the risks associated with new software development. Keywords. Domain modeling, spiral process model, process model reuse, knowledge-based software reuse.

1. Introduction
A software reuse area of growing importance is that of domain modeling of families of systems (also referred to as software product lines), where an application domain is modeled by analyzing the common and variant aspects of the family. This concept has been investigated by several researchers and practitioners [Batory92, Bosch99, Coplien98, Cuka98, DeBaud99, Dionisi98, Kang90]. At George Mason University, a reuse-oriented software lifecycle, the Evolutionary Domain Lifecycle [Gomaa93], has been proposed, which is a highly iterative lifecycle that takes an application-domain perspective allowing the development of families of

systems [Parnas79]. A domain modeling method [Gomaa95], which captures the similarities and variations of the domain, and a proof-of-concept prototype, the Knowledge-Based Software Engineering Environment [Gomaa96] have also been developed. Complex systems need a well-regulated software process, which is flexible enough to be tailored to the specific needs of the project. This paper describes the application of the domain modeling method to process modeling. In particular, it presents a domain model of the Spiral Process Model [Boehm88], which is extended to incorporate the key process areas of the Software Engineering Institutes Capability Maturity Model (CMM). The domain model is for a family of software process models, which can be tailored to generate a process model for a specific project, given the project drivers, which are the project specific risks. Section 2 of this paper summarizes the domain modeling method. Section 3 gives a brief overview of the Spiral Process Model and the Capability Maturity Model. Section 4 describes how the domain modeling method can be applied to create a domain model of the family of software process models. Section 5 describes the domain model for the spiral model, with the addition of the key process areas for CMM levels 2 and 3. Section 6 describes how the prototype Knowledge Based Software Engineering Environment was applied to the process-modeling domain.

2. Domain modeling method

2.1. Domain modeling
A Domain Model is an analysis model for the application domain that reflects the similarities and variations of the members of the domain. Given a domain model of an application domain, an individual target system (one of the members of the family) is created by tailoring the domain model given the requirements of the individual system (Fig.1).

In a domain model, an application domain is represented by means of multiple views, such that each view presents a different aspect of the domain [Gomaa95]. Four of the five views, the Aggregation Hierarchy, Object Communication Diagrams, Generalization/Specialization Hierarchy, and Feature /Object dependencies are described here, since they are most relevant to this research. The fifth view, the State Transition Diagram is not presented herein.
Domain Requirements Reusable Specification

Domain Modeling

Domain Reuse Library

Target System Requirements

Target

Target System System Generation

domain object type are stored in a Generalization / Specialization Hierarchy (GSH), which supports the ISA relationship linking subtypes to their supertype. Feature/Object dependencies. A feature represents one or more domain requirements, and this feature analysis becomes an important aspect of domain analysis [Cohen98, Dionisi98, Griss98, Kang90]. This view relates the end-users perspective of the application domain, namely the features supported by the application domain, to the object types within the domain model. Also defined are required prerequisite features and any mutually exclusive features. This view is particularly important for optional features, since it is the selection of the optional features and their supporting object types, that determines the structure of the desired target system. Rules for consistency checking between the multiple views have been defined. These are enforced by the domain modeling environment described in Section 5. The domain modeling method is similar to other object-oriented methods when used for analyzing and modeling a single system [Booch94, Booch98, Coleman94, Jacobson92, Rumbaugh91]. Its novelty is the way it extends object-oriented methods to model families of systems, in which the similarities and variations in a family are explicitly modeled.

Unsatisfied Requirements, Errors, Adaptation

2.2. Target system specification generation

A Target System Specification is a problem-oriented architecture for an individual target system, i.e., a member of the family of systems that constitute the domain. It is a tailored instance of the domain model. Requirements reuse is achieved by selecting features for a target system. The domain model is then tailored to generate the target system specification, subject to the appropriate feature-object dependency constraints. This step is greatly assisted by automated support as described in Section 5.

Figure 1: Domain modeling for a family of systems

Aggregation Hierarchy. The Aggregation Hierarchy is used to decompose complex aggregate object types into less complex object types eventually leading to simple object types at the leaves of the hierarchy. Object types are either kernel, i.e., required in every target system, or optional, i.e., only required in some target systems. The Aggregation Hierarchy supports the IS-PART-OF relationship linking object types to their aggregate type. Object communication diagrams. Objects in the real world are modeled as concurrent tasks, which communicate with each other using messages. Dynamic relationships between objects, in the form of messages passed between objects, are shown by means of object communication diagrams. Objects types are either kernel, i.e., required in every target system, or optional, i.e., only required in some target systems. Generalization/Specialization Hierarchy. As the requirements of a given object type are changed to meet the specific needs of a target system, the object type may be specialized by adding or modifying operations. In our domain modeling approach, the variants of a

3. Process models and the CMM

3.1. Problems with software process models
Software process models provide explicit models of the software development process. The earliest process model was a phased approach to software development referred to as the Waterfall Model [Boehm76]. Several problems have been identified with the waterfall model of software development [Agresti86]: a) Software requirements, a key factor in any software development, are not properly tested until a

working system is available to demonstrate to the endusers. These problems are compounded by the fact that studies have shown that changes in requirements to a delivered system are usually the most costly to correct [Boehm76]. Prototyping [Agresti86, Gomaa97] and operational specifications [Agresti86, Zave84] are two approaches that have been used to help address this problem. However these approaches are typically only used to develop new systems and are less frequently used in software reuse and evolution. b) Difficulty in managing system evolution. Requirements are assumed to be stable when they are actually dynamic and evolutionary. Thus a requirements specification may correctly reflect the users needs at the time of its completion. However, by the time the system is delivered, evolutionary changes in the operational environment often result in the system no longer meeting user requirements. Incremental development approaches [Agresti86, Gomaa97] have been used to help address this problem. However, managing system evolution remains a major technological challenge [Lubars92]. Various approaches have been suggested to providing reusable software process models, where the software process can be adapted to the needs of the project. Process reuse has been described as the usage of one process description in the creation of another process description [Frakes96]. Another approach to reuse software processes has involved using the answers to a series of questions to tailor a software process [Henninger98].

quadrant is intended to be general enough so that they can be included in any cycle. The goal of the spiral model is that the software process be risk driven, so that the risks within a given cycle are determined during the Analyze Risks quadrant. In order to manage these risks, certain additional project-specific activities may be planned to address the risks, such as Requirements Prototyping, if the risk analysis indicates that the software requirements are not clearly understood. These project-specific risks are termed process drivers. For any process driver, one or more project-specific activities must be performed to manage the risk.

1. Define Objectives, Alternatives, and Constraints

2. Analyze Risks

4. Plan Next Cycle

3. Develop Product

Figure 2: The spiral process model

3.2. The spiral model

The Spiral Model takes a different approach to software process reuse. The Spiral Model is a riskdriven process model originally developed by Boehm [Boehm88] to address known problems with earlier process models of the software life cycle, in particular the Waterfall Model. In the spiral model (Fig. 2), the radial coordinate represents cost and the angular coordinate represents progress in completion of a cycle of the model. Each cycle involves traversing through the four quadrants. The first quadrant is to determine objectives, alternatives, and constraints for the cycle. The second quadrant is a risk analysis and evaluation of alternatives for the cycle. The third quadrant is to develop and verify the next level product. The fourth quadrant involves planning for the next phases. Each cycle of the spiral model iterates through these four quadrants. The number of cycles is projectspecific, so the description of the activities in each

The Spiral Model is intended to encompass other life cycle models such as the Waterfall Model, the Incremental Development model, and the Throwaway Prototyping Model. During Risk Analysis, the key characteristics of the project are determined, referred to as process drivers. An example of a process driver is Low understanding of Requirements. The process drivers (comparable to features described in Section 2.1), are used to determine which process model is most appropriate for the project. In this way, the Spiral Model can be considered a process model generation framework [Boehm89].

3.3. The capability maturity model

The Capability Maturity Model, developed at the Software Engineering Institute [CMM95], is a software process maturity framework to help organizations improve their software process. Software process maturity [Humphrey89] is defined as the extent to which an organizational software process is explicitly

defined, managed, controlled, and effective. According to CMM, there are five levels of software process maturity: Initial, Repeatable, Defined, Managed, and Optimized. This research concentrates on achieving levels two and three. Each maturity level consists of several key process areas. Each key process area defines what should be done to achieve that level, although the how is left to organizations to select the practices they consider most appropriate for their business. The level 2 key process areas are requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management. Thus, an organization operating at CMM level 2 must have policies and procedures in place for these six key process areas. It is to be noted that an organization cannot claim to be operating at any CMM level unless (SEI approved) independent assessors have certified it. However, many organizations have initiated internal assessment programs, which are less expensive than the SEI certifications. These assessments provide the first impetus for organizations to improve their software development processes, and get certification from SEI approved assessors. One of the authors, in a previous position, was responsible for developing policies and procedures to attain CMM level 2 certification. The level 3 key process areas are training program, integrated software management, software product engineering, intergroup coordination, and peer reviews. An organization can operate at level 3 if it is already operating at CMM level 2 and have policies and procedures in place for these five key process areas.

domain model would be used to represent an activity in the spiral model, and second a feature in the domain model would be used to represent a process driver in the spiral model. In developing the SPM domain model, another important issue is how to represent the cycles and quadrants of the spiral model. Since an object in the domain model is used to represent an activity in the spiral model, an aggregate object may be used to represent an aggregate activity, i.e., a composition of several activities. The approach adopted is to model the four quadrants of the spiral model as four aggregate activities in the domain model. Each of these aggregate activities is decomposed further. The first two levels of decomposition represent activities performed in each cycle. Beyond that, at the third level of decomposition, additional cycle-specific activities are depicted, the concept being that these activities are performed when the appropriate cycle is activated.

4.2. An SPM domain model

The domain model of the SPM consists of the Aggregation Hierarchy, Object Communication Diagrams, Generalization / Specialization Hierarchy, and Feature/Object Dependencies. 4.2.1. Aggregation Hierarchy. The aggregation hierarchy of the Spiral Process Model is shown in Fig. 3. This view captures the is-part-of relationship among activities in the domain model. Fig. 3 shows three levels of decomposition in the SPM domain model. Each activity is shown as a box. An activity has two properties, the first is whether it is kernel (K) or optional (O), the second is whether it is aggregate (A) or simple (S). The first level of decomposition captures the four quadrants of the Spiral Process Model. It is important to note that three of these aggregate quadrant activities are modeled as optional, while only one (Developing and Verifying Product) is modeled as kernel. The reason for this is that kernel of the SPM domain model, consisting only of the kernel objects, constitutes the Waterfall model. This means that a project considered low risk could follow the waterfall life cycle. Only the Developing and Verifying Product aggregate activity is needed for the Waterfall model, while other activities are required for other variants of the domain model. The second level of decomposition in Fig. 3 is limited to the Developing and Verifying Product aggregate activity. This activity has been further decomposed into five activities, all of which are kernel

4. Domain modeling of the SPM

4.1. Introduction
As the Spiral Model encompasses several process models, an intriguing problem is to what extent the domain-modeling concept can be applied to the family of process models. In particular, a domain model of the Spiral Process Model (SPM) could be developed to encompass other process models. This domain model can be specifically tailored for a project by selecting appropriate process drivers. In addition to the Spiral Process Model, this domain model incorporates the key process areas of levels 2 and 3 of the Capability Maturity Model. Before beginning the domain modeling effort, two important decisions were made. First an object in the

in the domain model. These activities broadly cover all the technical tasks that must be performed in the development of a software product, for which a managed software process is required. In the context of the spiral process model, each of these activities will be performed in a different cycle. Any of these activities can be revisited in a new cycle. This may be necessary due to a requirements change or to address significant problems discovered in an earlier cycle. Each of these
Spiral Process Domain KA

specific project needs as determined by the process drivers. The aggregation hierarchy, as shown in Fig. 3, captures an overall view of the domain model of the spiral process model. This view complements another view in the domain model, the object communication diagrams, which are described next. 4.2.2. Object Communication Diagrams. The first level of decomposition of the spiral model domain

Defining Objectives, Alternatives, and Constraints OA

Analyzing Risks OA

Developing and Verifying Product KA

Spiral Planning OA

Project Planning Cycle KA

Requirements Analysis and Specification Cycle KA

Preliminary Design Cycle KA

Construction and Test Cycle KA

System Testing Cycle KA

Requirements Analysis and Specification KS

Requirements Prototyping OS

Requirements Review OS

Architectural Design KS

Design Prototyping OS

Design Performance Analysis OS

Local Design Tailoring OS

Architectural Design Review OS

Figure 3: Aggregation Hierarchy for the Spiral Process Model Domain Model

aggregate activities is further decomposed into simple activities, although Fig. 3 only shows the decomposition for the Requirements Analysis and Specification Cycle and the Preliminary Design Cycle, which are described next. The other aggregate activities at levels 2 and 3 in Fig. 3 are not decomposed further for reasons of space. The Requirements Analysis and Specification Cycle activity is decomposed into three activities: Requirements Analysis and Specification, Requirements Prototyping, and Requirements Review. Of these, only the first activity is kernel. The second and the third activities are optional and are performed only in those projects that have specific need for them. For example, the Requirements Review activity will only be performed if there is a need for the Requirements Management process driver (Table 3, see last page). The Preliminary Design Cycle activity is decomposed into five activities: Architectural Design, Design Prototyping, Design Performance Analysis, Local Design Tailoring, and Architectural Design Review. Except for the first activity, which is kernel, all the others are optional and are performed to meet

model is shown as the top level of the Object Communication Diagrams (OCD). There are four aggregate objects, one for each of the main quadrants of the spiral model. These are the Defining Objectives, Alternatives, and Constraints, Analyzing Risks, Developing and Verifying Product, and Spiral Planning, as shown in Fig. 4. Each of these aggregate objects is
Estimate of Situation

Project Planning Documents

Updated Project Planning Documents

Supporting Documents Project Planning Documents Estimate of Situation

Meeting Minutes Risk Management Plan 2 Analyzing Risks OA Updated Project Planning Documents

Supporting Documents Meeting Minutes

1 Defining Objectives, Alternatives, and Constraints OA

Updated Project Planning Documents Supporting Documents Project Planning Documents Updated Project Planning Documents 4 Spiral Planning OA Product Status Report Updated Project Planning Documents Product Baselines

Risk Management Plan

3 Developing and Verifying Product KA

Project Planning Documents Supporting Documents

Product Baselines

Product Status Report

Figure 4: Top Level OCD for Spiral Process Model

decomposed further to reflect the process activities defined for each quadrant. In the OCDs, each activity is depicted as a circle, with the arcs representing information passed between activities. In the domain model, there are kernel objects and optional objects. Kernel objects correspond to activities that are required in every process model generated from the spiral model domain model. Optional objects correspond to activities that are only required in some generated process models if the specific process driver the activities relate to is relevant to the project. For example, on the Requirements Analysis and Specification Cycle OCD (Fig. 5), Requirements Analysis and Specification is a kernel object, as it is
Risk Management 3.2.3 Plan Requirements Review OS

activity, Architectural Design, with four optional activities. The optional activities are Design Prototyping, Design Performance Analysis, Local Design Tailoring, and Architectural Design Review. All the optional activities interact with the kernel activity and so there are no inter-dependencies among the optional activities. The Design Prototyping and Design Performance Analysis activities are both required if the Performance Requirements process driver is selected (Table 1), e.g., for a real-time development project. 4.2.3. Generalization/Specialization Hierarchy. In this view of the domain model, a kernel or optional activity type can be specialized to reflect a variation on an activity that is only carried out in some generated
3.3.4 Local Design Tailoring OS Tailored Design Specifications Architectural Design Specification Product Status Report 3.3.1 Architectural Design KS Architectural Design Spec Trained Staff

Requirements Specification Project Plan

Review Status Report Requirements Specification

Requirements Specification Project Planning Documents

Project Planning Documents

3.2.1 Requirements Analysis and Specification KS

Product Status Report

Preliminary Architectural Design Spec

Design Prototype

Requirements Prototype

Preliminary Requirements Specification

Design Performance Report

3.2.2 Requirements Prototyping OS

3.3.2 Design Prototyping OS

Preliminary Architectural Design Spec

Figure 5: OCD for the Requirements Analysis and Specification Cycle

assumed that every software project would include this activity. However, Requirements Prototyping is an optional object, as this activity is only required if there is a poor understanding of requirements (a process driver). Requirements Review is another optional object, as this activity is only required if there is a need for Requirements Management (another process driver). The OCD for the Preliminary Design Cycle is shown in Fig. 6, which shows the interactions of a kernel
Architectural Design Spec Risk Management Plan

3.3.3 Design Performance Analysis OS Review Status Report

3.3.5 Architecture Design Review OS

Figure 6: OCD for the Preliminary Design Cycle

process models. An example of specialization is Design Method Selection. This activity type is specialized to

reflect the different kinds of method selection that can be carried out, reflecting the characteristics of different projects. These specialized activity types are Objectoriented Design Method Selection, Ada-based Design Method Selection, Real-Time Design Method Selection, and Distributed Design Method Selection (Fig. 7).
Selection of Design Method OVS

OO Design Method Selection

Ada Based Design Method Selection

Real Time Design Method Selection

Distributed Design Method Selection

Figure 7: Generalization/Specialization for Design Method Selection

4.2.4. Feature/Object Dependencies. As stated earlier, features in the domain model are represented as process drivers in the spiral model. For the feature/object dependency view of the domain model, all optional process drivers are mapped to optional and/or variant activities in the spiral model. These activities and process drivers include the CMM-related activities and process drivers. Table 1 shows risk related process drivers and supporting activities, while Table 3 shows all CMM related process drivers and supporting activities. For example, the process driver Low understanding of Requirements is supported by the activity Requirements Prototyping. This means that if the requirements are not understood, then the Requirements Prototyping activity must be carried out for this project and so is included in the generated process model for this project. Some process drivers are supported by more than one activity. For example three activities, Design Performance Analysis, Design Prototyping, and Performance Testing support the process driver Performance Requirements. The domain model of the spiral model has some feature/feature (or driver/driver) dependencies. Table 2 shows the risk related process driver constraints, while Table 4 shows CMM related process driver constraints. For example, the process driver Real time system requires the driver Performance requirements, since every real-time system has performance constraints. 4.2.5. Support for the CMM. The CMM levels 2 and 3 key process areas have been incorporated into the spiral model domain model by adding optional process activities corresponding to the levels 2 and 3 key

process areas. Each level 2 key process area has been modeled as a process driver. Thus a company striving to reach level 2 of the CMM can select the key process areas it wishes to incorporate by selecting the appropriate level 2 process drivers. Table 3 shows the CMM Related Process Drivers, corresponding to the key process areas, and supporting process activities. A company that wishes to incorporate all CMM Level 2 process activities can select the process driver package CMM Level 2. This driver package requires the six process drivers representing the level 2 key process areas: Requirements management, Software project planning, Software tracking and oversight, Software subcontract management, Software quality assurance, and Software configuration management, as shown in Table 4. The level 3 key process areas have also been modeled as process drivers. Thus a company striving to reach level 3 of the CMM can select the key process areas it wishes to incorporate by selecting the appropriate level 3 process drivers. A company that wishes to incorporate all CMM Level 3 process activities can select the process driver package CMM Level 3. This driver package requires all six process drivers representing the six key process areas of CMM level 2 and the five process drivers representing the key process areas of CMM level 3, as shown in Table 4. 4.2.6. Generating a project-specific process model. The spiral model domain model is tailored according to a particular projects process drivers to generate a specific process model for that project. The way this is achieved in the domain modeling method is by defining feature/object dependencies, where the features correspond to optional requirements and the objects are optional or variant objects. Applying this to the spiral model domain model, the features correspond to process drivers. The objects in the feature / object dependencies reflect optional or variant activities. Thus by selecting a process driver, the activities required to support it are chosen. Each activity has an associated document describing the detailed procedures to be performed. Thus, a project specific process, generated from the SPM domain model, contains all the relevant documents that are needed to manage the project. Fig. 8 shows the aggregation hierarchy of a tailored version of the SPM domain model. The needs of this project dictate the inclusion of two process drivers: Low understanding of Requirements and Requirements management. The Low understanding of Requirements process driver is a risk-related driver and is supported by the optional Requirements Prototyping activity (Table 1). The Requirements

management process driver is a CMM-related process driver and is supported by the optional Requirements Review activity (Table 3). Both of these activities are included in the project specific process, shown in Fig. 8. Comparing Fig. 8 with Fig. 3 shows that those optional activities not required for a specific project are omitted from the project specific process, while all kernel activities are included.
Spiral Process Domain

Developing and Verifying Product

Project Planning Cycle

Requirements Analysis and Specification Cycle

Preliminary Design Cycle

Construction and Test Cycle

System Testing Cycle

Requirements Requirements Requirements Analysis and Prototyping Review Specification

Architectural Design

Figure 8: Aggregation Hierarchy for a Project Specific Process

5. Domain modeling environment

A prototype domain modeling environment has been developed, called the Knowledge Based Software Engineering Environment (KBSEE) [Gomaa94, Gomaa96], which consists of an integrated set of software tools to support domain modeling and target system requirements elicitation. The environment uses commercial-of-the-shelf software as well as custom developed software. The graphical editors supported by the Software through Pictures (StP) CASE tool are used to represent the multiple views of the domain model. However, the multiple views are interpreted semantically according to the domain modeling method. The information in the multiple views is extracted, checked for consistency, and mapped to an object repository. The feature / object dependencies are then defined using a custom developed tool. A knowledge-based requirements elicitation tool (KBRET) is used to assist with eliciting target system requirements and generating the target system specification [Gomaa92]. The tool, implemented in NASAs CLIPS shell, conducts a dialog with the human target system requirements engineer, prompting the

engineer for target-system-specific information. The output of this tool is used to adapt the domain model to generate multiple views of the target system specification. The prototype KBSEE is a domain-independent environment. Thus, it may be used to develop a domain model for any application domain that has been analyzed, and to generate target system specifications from it. A domain model of the Spiral Process Model has been developed using the prototype KBSEE. For this application, the KBSEE was used as a process model generator and the Knowledge Based Requirements Elicitation Tool was completely re-engineered to become a Process Model Generator (PROGEN). PROGEN, is implemented in NASAs CLIPS shell and the CLIPS Object Oriented Language (COOL). The domain model is created using the KBSEE. The StP graphical editors are used to represent the multiple views of the domain model, namely the Aggregation Hierarchy, the Activity (object) Communication Diagrams, and the Generalization / Specialization Hierarchies. The information in the multiple views is extracted, checked for consistency, and mapped to an object repository. The process driver/ activity dependencies are defined using the KBSEE Feature / Object Editor. PROGEN interacts with the project manager, presenting the process drivers available for selection. The project manager selects the drivers relevant to the project. PROGEN then tailors the SPM domain model to generate a project specific process model containing the kernel process activities, together with the optional and variant activities included to satisfy the selected process drivers.

6. Conclusions
The software development process is susceptible to risks, and project managers wish to mitigate those risks by selecting the most appropriate process model for a project. The domain model of the CMM augmented Spiral Process Model allows managers to select those features representing project risks, and allows them to generate a tailored process model. Thus, the domain modeling approach provides for large-scale reuse of the SPM activities as well as configured process models that have guided successful projects. This paper therefore contributes to two important areas in software engineering, software reuse and process modeling, with the added advantage of creating

a reusable domain model and architecture for the family of process models. The Spiral Process Model is a risk-driven process model, which, depending on the specific risks associated with a given project, may be tailored to create a project specific process model. The software reuse area addressed is that of domain models of families of systems, which capture the similarities and variations among the members of the family. From the domain model, target systems are generated given the specific requirements of the target system. The domain modeling method and environment described in this paper are application independent. Thus they can be applied to any domain model for which a domain analysis has been carried out. We are currently investigating using the Unified Modeling Language (UML) [Booch98], as a notation for modeling families of systems [Gomaa00]. Further worthwhile investigations in this area include using statecharts (hierarchical state transition diagrams), which are also supported by UML [Booch98], to model the dynamic aspects of the SPM, and to model process enactment, i.e., the actual execution of a given project specific software process model for validating purposes.

7. Acknowledgments
The authors gratefully acknowledge the contributions of C. Bosch, E. OHara, R.G. Mohan, V. Sugumaran, and I. Tavakoli, in developing the prototype Knowledge Based Software Engineering Environment, and the contributions of F. Carr and J. Yoon in its application to process modeling. This research was supported in part by the NASA Goddard Space Flight Center, the Virginia Center of Innovative Technology, DARPA, the Virginia Center of Excellence in Software Reuse, the Software Productivity Consortium, and IDE Inc. The views and conclusions expressed are those of authors and should not be interpreted as representing the official policies or endorsements, either expressed or implied, of NASA, DARPA, The MITRE Corporation, or the Software Productivity Consortium.

8. References
[Agresti86] Agresti W.W., New Paradigms for Software Development, IEEE Computer Society Press, 1986. [Boehm 76] Boehm, B. W., Software Engineering," IEEE Transactions on Computers, Vol. 25, No. 12, Dec 1976, pp. 1226-1241. [Boehm88] Boehm, B., A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1988.

[Boehm89] Boehm, B. and F. Belz, Experiences with the Spiral Model as a Process Model Generator, Proceedings of th 5 International Software Process Workshop, 1989. [Batory92] Batory D and S. OMalley, The Design and Implementation of Hierarchical Software with Reusable Components," ACM Transactions on Software Engineering Methodology, 1(4), pages 355-398, October 1992. [Booch94] Booch, G., Object-Oriented Analysis Design with Applications, Addison Wesley, Second Edition, 1994. [Booch98] Booch, G., J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Addison Wesley, Reading, MA, 1999. [Bosch99] Bosch, J., Product-Line Architectures in Industry: A Case Study, Proceedings of IEEE ICSE, Los Angeles, May 1999. [CMM 95] CMU Software Engineering Institute, The Capability Maturity Model, Addison Wesley, 1995. [Cohen98] Cohen, S., and L. Northrop, Object-Oriented Technology and Domain Analysis, Proceedings of IEEE ICSR5, Victoria, June 1998. [Coleman94] Coleman, D., et. al., Object Oriented Development The Fusion Method, Prentice Hall 1994. [Coplien98] J. Coplien, D. Hoffman, D. Weiss, Commonality and Variability in Software Engineering, IEEE Software, Nov/Dec 1998. [Cuka98] Cuka, D. and D. Weiss, Engineering Domains: Executable Commands as an Example, Proceedings of IEEE ICSR5, Victoria, June 1998. [DeBaud99] DeBaud, J.M. and K. Schmid, A Systematic Approach to Derive the Scope of Software Product Lines, Proceedings of IEEE ICSE, Los Angeles, May 1999. [Dionisi98] Dionisi, A. et al., FODAcom: An Experience with Domain Modeling in the Italian Telecom Industry, Proceedings of IEEE. ICSR5, Victoria, June 1998. [Frakes96] Frakes, W. and C. Hollenbach, Software Process Reuse in an Industrial Setting, Proceedings of IEEE ICSR4, Orlando, April 1996. [Gomaa92] Gomaa, H., L. Kerschberg, V. Sugumaran, A Knowledge-Based Approach for Generating Target System Specifications from a Domain Model, Proceedings of IFIP World Computer Congress, Madrid, Spain, September 1992. [Gomaa93] Gomaa, H., A Reuse-Oriented Approach for Structuring and Configuring Distributed Applications, Software Engineering Journal, March 1993. [Gomaa94] Gomaa, H., et. al., A Prototype Domain Modeling Environment for Reusable Software Architectures. Proceedings of IEEE ICSR3, Rio de Janeiro, November 1994. [Gomaa95] H. Gomaa, "Reusable Software Requirements and Architectures for Families of Systems", Journal of Systems and Software, April 1995. [Gomaa96] Gomaa, H., et. al. "A Knowledge-Based Software Engineering Environment for Reusable Software Requirements and Architectures," Journal of Automated Software Engineering, Vol. 3, Nos. 3/4, August 1996. [Gomaa97] Gomaa, H., The Impact of Prototyping on Software Systems Engineering, in System and Software

Requirements Engineering, edited by R. Thayer and M. nd Dorfman, IEEE Computer Society Press, 2 Edition, 1997. [Gomaa00] Gomaa, H., Object Oriented Analysis and Modeling for Families of Systems with UML, Proc. IEEE International Conference on Software Reuse, Vienna, June 2000. [Griss98] M. Griss, J. Favaro, M. DAlessandro, Integrating Feature Modeling with the RSEB, Proceedings of IEEE ICSR5, Victoria, June 1998. [Henninger98] Henninger, S., An Environment for Reusing Software Processes, Proceedings of IEEE ICSR5, Victoria, June 1998. [Humphrey89] Humphrey, W., Managing the Software Process, Addison Wesley, 1989. [Jacobson92] Jacobson, I., Object-Oriented Software Engineering, Addison Wesley, Reading MA, 1992.

[Kang90] Kang, K.C. et. al., "Feature-Oriented Domain Analysis", Technical Report No. CMU/SEI-90-TR-21, Software Engineering Institute, November 1990. [Lubars92] Lubars, M.D., C. Potts, and C. Richter, "Objectth Oriented Analysis for Evolving Systems", Proceedings of 14 IEEE ICSE, pp. 173-185, 1992. [Parnas79] Parnas, D., Designing Software for Ease of Extension and Contraction, IEEE Transactions on Software Engineering, March 1979. [Rumbaugh91] Rumbaugh, J., et al., Object-Oriented Modeling and Design, Prentice Hall, 1991. [Zave84] Zave, P., "The Operational Versus the Conventional Approach to Software Development", CACM, February 1984.

Table 1. Risk-Related Process Drivers and Supporting Activities Process Driver Need for project level prototyping Lack of development method Need for CASE tool Low understanding of Requirements Evolutionary development Operational life cycle Performance requirements Maintenance/support requirements Complex system interfaces Incremental development Phasing Real time system Design method need Design method training need Existing hardware/software constraint Reuse library exists Spiral process Activities required to support Process Driver Project Level Prototyping Selection of Development Method Selection of CASE Tool Requirements Prototyping Requirements Prototyping, Planning for Evolutionary Development, and OOD Method Selection Planning for Incremental Development, Planning for Evolutionary Development, and OOD Method Selection Design Performance Analysis, Design Prototyping, Performance Testing, and Performance Testing Peer Review Requirements Prototyping, Preparation of Enhanced Documentation Design Prototyping Requirements Prototyping, Planning for Incremental Development, and Planning for Evolutionary Development Planning for Incremental Development RT Design Method Selection Selection of Design Method Design Method Training Local Design Tailoring Select or Adapt Reusable Components Defining Objectives, Alternatives, & Constraints, Analyzing Risks, Scheduling and Planning, Commitment To Planning, Monitoring and Reviewing Product, Product Change Control, Project Progress Review, Planning for Requirements Cycle, Planning for Architectural Design Cycle, Planning for Construction and Test Cycle, Planning for System Testing Cycle

Table 2. Risk-Related Process Driver Relationships (Left Column Driver Requires Right Column Driver) Process Driver Real time system Design method need Lack of development method Required Driver Performance requirements Design method training need Design method need

Table 3. CMM Level 2 Related Process Drivers and Supporting Activities Process Driver Requirements management Software project planning Software tracking and oversight Software subcontract management Software quality assurance Software configuration management Activities required to support Process Driver Requirements Review Software Cost Estimation, Software Size Estimation, Critical Computer Resources Estimation, Software Schedule Planning, Life Cycle Selection, Definition of Project Commitments, and Planning Project Facilities & Support Tools Project Progress Review, Software Schedules Review, SW Effort and Cost Review, Critical Computer Resources Review, Project Commitments Review, and Work Product Size Review Planning Subcontract Management, Project Progress Review, and Tracking Subcontract Progress Preparing SQA Plan, Project Progress Review, and SQA Audit of Work Products Preparing SCM Plan, Establishing CM Library, and Identification of SCM Work Products

Process Driver CMM level 2

Table 4. CMM-Related Process Driver Relationships (Left Column Driver Requires Right Column Drivers) Required Driver Requirements management Software project planning Software tracking and oversight Software subcontract management Software quality assurance Software configuration management Training program Integrated software management Software product engineering Intergroup coordination Peer reviews CMM level 2

CMM level 3