PROGEN: A Process Model Generator for the ESPM

PROGEN: A Knowledge-based System for Process Model Generation, Tailoring and Reuse

Principal Investigators:

Larry Kerschberg
Hassan Gomaa

Graduate Research Assistants:

Rajan Girish Mohan

Ghulam Ahmad Farrukh

Center for Information Systems Integration and Evolution

Department of Information and Software Systems Engineering

George Mason University

Fairfax, Virginia, 22030-4444

November 1995

Introduction

This report presents the PROGEN knowledge-based system for process model generation, tailoring and reuse. The PROGEN system is based on the Knowledge-based Requirements Elicitation Tool (KBRET) within the Knowledge-Based Software Engineering Environment (KBSEE) described in a companion paper of this report. PROGEN has been completely re-engineered to take advantage of the CLIPS object-oriented language COOL.

PROGEN is application-domain independent in that it can process any domain model specified according to the methods supported by the KBSEE. The KBSEE outputs a domain-dependent knowledge base, as shown in Appendix B, which serves as the initial fact base for PROGEN. PROGEN then processes the facts representing a domain model into its COOL object-oriented representation. The PROGEN user-interface has been "tailored" to deal with Spiral Model generated process models, but, in general, it may be tailored for any domain model.

PROGEN is used to assist with project-specific driver selection and project-specific process model generation. PROGEN, is implemented in NASA's CLIPS shell and the CLIPS Object Oriented Language (COOL). PROGEN conducts a dialog with the human process engineer, prompting the engineer for the project-specific process information. The output of this tool is a reusable project-specific process model.

PROGEN provides a knowledge-based environment required to successfully complete the generation of project-specific process model from a domain model or from an existing process model. The architecture of PROGEN separates the application domain knowledge from the control knowledge required to generate the process model. Hence PROGEN can be applied to any application domain which has been modeled using the EDLC (Evolutionary Domain Life Cycle) method.

The remainder of this report is organized as follows. Section 2 presents an overview of the PROGEN architecture and the major processing steps. Section 3 focuses on the Application Domain Knowledge Base and provides examples of object-oriented specification for the major objects types of the SPM domain model: activities, drives, driver-activity relationships, driver-driver relationships, multiple views expressed in aggregation hierarchies and generalization/ specialization hierarchies. Section 4 deals with the various PROGEN control knowledge sources. Section 5 presents our conclusions, and Appendix B provides the SPM domain model as input facts for PROGEN.

The PROGEN Architecture

PROGEN consists of two major components as depicted in Figure 1:

1) Control knowledge sources which handle the dialog and reasoning tasks associated with process model generation.

2) Application domain knowledge sources which describe a specific domain model such as the SPM domain model.

The control knowledge sources consist of modules which control: 1) the user interface, 2) the domain model browser, 3) driver selection, deletion, and dependency checking, 4) process model generation and 4) process model storage, retrieval and reuse.

The application domain knowledge is used by the control knowledge source in process model specification and generation. The application domain knowledge is derived from the domain model. The application domain knowledge base consists of three knowledge sources, namely, a) Driver and Activity Definitions, b) Driver/Activity Dependency View, and c) Multiple Views. Consequently, the application domain knowledge base of PROGEN contains the above mention knowledge sources, as shown in figure 1.

The application domain knowledge derived from the domain model is expressed as facts, using common knowledge representation scheme as shown in Appendix B. This representation is application domain independent, so that the domain knowledge derived from any EDLC-based domain model, can be expressed in this knowledge representation scheme. Figure 1 below depicts the PROGEN architecture. Figure 2 shows the major processing steps supported by PROGEN.

Figure 1: The PROGEN Architecture

Step 1: Load PROGEN and SPM Domain Model

E.g.: (load "PROGEN")

E.g.: (load "SPM")

Step 2: Select a mode of operation

Browsing Phase - Step 3

Process Driver Specification/ Deletion Phase - Step 4

Target Process Model Generation Phase - Step 5

Target Process Specification Loading Phase - Step 6

Exit - Step 7

Step 3: Browsing Phase

Select a process driver from the displayed list.

Display explanation for the selected driver

Return to Step 3

Return Step 2

Step 4: Process Driver Specification/Deletion Phase

Select a process driver from the displayed list.

Perform dependency check to ensure the integrity of the target system.

Include/Delete driver based on the outcome of the dependency check.

Return to Step 4.

Return to Step 2.

Step 5: Target Process Model Generation Phase

Ensure Target Process Model Generation consistency constraints satisfied.

Assemble Target Process Model.

Display

Target Process Drivers,

Target Process Model Leaf Level Activity Types,

Target Process Model Aggregate and Leaf Activity Types.

Save Target Process Model.

Return to Step 2

Step 6: Target Process Specification Loading Phase

Request filename for saved Target Process Model specification.

Ensure syntactic and semantic file format.

Load Target Process Model specification.

Rebuild Target Process Model specification.

Return to Step 2

Step 7: Exit Phase

Save target process model specification.

Quit PROGEN

Figure 2: Major Processing Steps in Generating a Project-Specific Process Model

Application Domain Knowledge Base
Driver and Activity Definitions

The format for the PROGEN fact that represents the domain object types and their properties is given below:

(Activity: id name properties)

where id is the activity identification number

name is the activity name, and

properties is a list of properties describing the role of the

activity within the domain model. The properties can be

kernel or optional, simple or aggregate, agh_root or

gsh_root, and variant.

For example:

Figure 3: Example of a PROGEN Activity fact,
the COOL class definition and an instance of this class

The format for the PROGEN fact that represent the domain driver types is given below:

(Driver: id name)

where id is the driver identification number and

name is the driver name.

For example:

Figure 4: Example of a PROGEN Driver fact,
the COOL class definition and an instance of this class

For each domain driver, there is short annotation which briefly explains the driver's role in the domain model. The annotation is also expressed as a PROGEN fact, which is of the form shown below:

( driver-explanation id name annotation)

where id is the driver identification number,

name is the driver name, and

annotation is the description of the driver.

For example:

Figure 5: Example of a PROGEN Driver-explanation fact,
the COOL class definition and an instance of this class

The name of the domain is also contained in the Driver and Activity Definition Knowledge sources. This is expressed a PROGEN fact in the form given below.

(Name-of-domain name)

where name corresponds to the name of the domain model.

Driver/Activity Dependency View

The various relationships among drivers and between drivers and activities types are captured in the Driver/Activity Dependency View. The driver-driver dependencies supported include a) requires b)set-of-exactly-one-of c) set-of-atmost-one-of and d) set-of-atleast-one-of. The Driver/Activity dependency is captured by the supported-by dependency which indicates the activity types that are required to support a driver.

The format for the PROGEN fact that captures the prerequisite relationship between features is given below:

(PROGEN name₁ Driver id₁ requires name₂ Driver id₂)

where name₁and id₁ correspond to the name and identifies of the

driver that requires the presence of another driver whose name and

identifier correspond to the term name₂ and id₂.

The following example shows a case of the "requires" driver-driver dependency:

The format of the PROGEN fact that represents the "supported-by" relationship is shown below:

(d-name Driver dr-id supported-by ac-id a-name properties)

where d-name and dr-id correspond to the name and identifier of

the driver which is supported by the activity type with identifier ac-id,

name a-name, and properties given by the properties term.

The following example shows the supported-by dependency between drivers and activities:

The format of the PROGEN fact that represents the "Set-of-exactly-one-of" relationship is shown below

(Set-of-exactly-one-of: id name Driver-ids: list-of-driver-ids)

where the terms id and name are the identifier and name of the

exactly-one-of driver set and the list-of-driver-ids contains the list

of identifiers for the drivers that are members of this set.

The format of the PROGEN fact that represents the "Set-of-atleast-one-of" relationship is shown below

(Set-of-atleast-one-of: id name Driver-ids: list-of-driver-ids)

where the terms id and name are the identifier and name of the

atleast-one-of driver set and the list-of-driver-ids contains the list

of identifiers for the drivers that are members of this set.

The format of the PROGEN fact that represents the "Set-of-atmost-one-of" relationship is shown below

(Set-of-atmost-one-of: id name Driver-ids: list-of-driver-ids)

where the terms id and name are the identifier and name of the

atmost-one-of driver set and the list-of-driver-ids contains the list

of identifiers for the drivers that are members of this set.

Multiple views

The multiple views knowledge source contains the different views created using the EDLC method, in particular, the aggregation hierarchy and the generalization/specialization hierarchies. The aggregation hierarchy is expressed using the "is-part-of" key word and generalization/specialization hierarchy is expressed using the "is-a" keyword.

The format for the PROGEN fact that expresses the "is-part-of" relationship between activity types in the aggregation hierarchy is as follows:

(is-part-of id₁ name₁ id₂ name₂ )

where the terms id₁ and name₁ correspond to the identifier and

name of the parent activity type and terms id₂ and name₂

correspond to the identifier and name of the child activity type.

For example:

The format for the PROGEN fact that expresses the "is-part-of" relationship between activity types in the aggregation hierarchy is as follows:

(is-part-of id₁ name₁ id₂ name₂ )

where the terms id₁ and name₁ correspond to the identifier and

name of the supertype and terms id₂ and name₂

correspond to the identifier and name of the subtype.

For example:

Reusable Project-Specific Process Model

Once a project-specific process model has been generated, the specification is stored for subsequent retrieval and reuse. The information stored include the domain name, the process model name and the drivers selected. On retrieval, the process model is reconstructed and is ready for modification.

PROGEN Control Knowledge Base

As shown in figure 1, the domain independent knowledge base is composed of the following knowledge sources: a) User interface Manager, b) Domain Model Browser, c) Driver Selection/Deletion Handler, d) Project-Specific Process Model Generator, and e) Project-Specific Process Model Storage, Retrieval and Reuse Module. These knowledge sources incorporate control knowledge required to support the various activities necessary to generate the project-specific process model from an EDLC based domain model. This control knowledge is expressed as rules in each of these knowledge sources. Note that the control knowledge is independent of the application domain; hence these knowledge sources can be applied to domain models of any application, assuming the domain models are created using the EDLC method.

User Interface Manager

The User Interface Manager knowledge source initializes the system and carries out a session with the process engineer. It also provides mechanisms for invoking the different phases of the project-specific process model generation. The User Interface Manager is implemented as a set of production rules. The current version has a dialog-based user interface. In order to facilitate the process model generation, the User Interface Manager provides a menu, as shown in Figure 6. The user can select any activity by entering the corresponding choices.

The User Interface Manager contains rules to translate these choices and fires the appropriate rules to perform the desired action. The following actions are currently supported.

(a) Browse the Domain Model: When the user makes this choice, the user interface responds by firing appropriate rules to invoke the browsing phase. Once, the browsing phase is initiated, the Domain Model Browser knowledge source takes control. The domain browser also provides a mechanism for ending the browsing phase.

(b) Driver Selection/Deletion: The user may enter this phase after browsing the domain model. The user may also bypass the browsing phase and move directly to driver selection/deletion phase. The User Interface Manager initiates the driver selection phase by firing appropriate rules.

***************************************************

* *

Knowledge Based Process Model Generation Tool

PROGEN

* *

***************************************************

Requirement Elicitation for spiral:spiral_dm

You may browse the drivers incorporated in the

spiral:spiral_dm domain model, or

Specify the drivers for the Project, or

Start the Project-Specific Process Model generation or

quit PROGEN .

Choices Perform

******* *******

1 Browse the Domain Model

2 Specify Drivers for the Project

3 Initiate Project-Specific Process Model Generation Phase

4 Load a Project-Specific Process Model

e Quit PROGEN

Please type your choice and press return: 1

Figure 6: Main Menu

The Driver Selection/Deletion Handler knowledge source receives control and facilitates the driver selection/deletion process by working closely with the Dependency checker knowledge source to ensure consistency. The Driver Selection/Deletion Handler provides the mechanism to end the driver selection phase.

(c) Project-Specific Process Model Generation: Once the desired drivers for a project have been selected, the user can initiate the process model generation phase by making the corresponding choice. Once a consistent process model has been generated by the process-specific process model generation knowledge source, control is transferred to the User Interface Manager Knowledge source.

(d) Project-Specific Process Model retrieval: In order to reuse a previously generated process model, the load feature is added to PROGEN. The user can specify a filename, which PROGEN verifies for syntactic correctness. The drivers consistent with the named process model are displayed to the process engineer for approval. After approval, the original state of the retrieved process model is restored. The process engineer may proceed to add or delete drivers to suit the particular project at hand.

(e) Quit PROGEN: By making this choice, the user can end the session with PROGEN.

Domain Model Browser

The Domain Model Browser knowledge source provides the mechanisms for browsing the domain model. It incorporates rules for facilitating and terminating the browsing phase, and also for accessing the appropriate facts of the SPM domain model to browse those parts of the domain model the process engineer wishes to explore. The Domain Browser presents the domain model drivers in a list and the user can select the driver number to explore further. Figure 7 shows the explanation for Driver 1: CMM level 2.

Driver Viewing

*************

1 CMM level 2

2 Complex system interfaces

3 Design method need

4 Design method training need

5 Evolutionary development

6 Existing hardware/software constraint

7 Incremental development

8 Integrated software management KPA

9 Intergroup coordination KPA

10 Lack of development method

11 Maintenance/support requirements

12 Need for CASE tool

13 Need for project level prototyping

14 Operational life cycle

15 Peer reviews KPA

16 Performance requirements

17 Phasing

18 Real time system

19 Requirements management KPA

20 Reuse library exists

21 Software configuration management KPA

22 Software product engineering KPA

23 Software project planning KPA

24 Software quality assurance KPA

25 Software subcontract management KPA

26 Software tracking and oversight KPA

27 Spiral process

28 Throw away prototyping

29 Training program KPA

e EXIT

Enter your selection:1

Driver 1 is CMM level 2

Explanation: This process driver package addresses the CMM level 2 KPAs.

Enter c to continue (c): c

Figure 7: Browsing Phase

When the user selects a driver, the Domain Model Browser retrieves the annotation for that driver from the Driver and Activity Definitions knowledge source.

After browsing the domain model, the process engineer may initiate the driver selection process for the specific project.

Driver Selection/Deletion Handler

The Driver Selection/Deletion Handler knowledge source is responsible for the "driver-elicitation" processing in which the process engineer specifies the relevant drivers in the project. It incorporates rules for managing the selection and deletion of drivers.

During the driver-elicitation process, the SPM domain model drivers are presented to the user in the form of list. To select a driver, the user simply enters a driver number of his choice. During the driver selection, if the user indicates that a particular driver is desired, the Driver Selection/Deletion Handler requests that the Dependency Checker knowledge source to verify and enforce the inter-driver dependencies. After performing the dependency checking, the Dependency Checker indicates that the driver has been selected successfully and also compiles a list of both explicitly-selected and implicitly-selected drivers. Implicitly-selected drivers are those which are included in the selection because they are "required" by some other explicitly-selected driver. The dependency checker also verifies whether any drivers may be prevented from selection (through set-of-exactly-one-of, set-of-atmost-one-of constraints) due to the currently selected drivers and provides a list indicating this.

The entire selection operation is treated as one atomic operation. All related facts asserted during the selection process are appended with a unique transaction identification number dedicated for the particular operation performed. Each operation is conceptually represented as a tree with the explicitly selected driver as the root. The children of a node in the tree consists of drivers that are "required" by the parent.

The user is only allowed to select from a listed drivers that are available for selection, and hence, is assured of a successful selection. After the successful addition of the desired driver, control is transferred to the Driver-Selection/Deletion Handler. The Driver Selection/Deletion Handler keeps track of drivers that can be selected and drivers that cannot be selected during the driver selection process.

The user may return to the previous menu by exiting from the selection phase. If one or more drivers were selected, the user is now presented with a "Delete" option as well. If this option is selected, the user is presented with only those drivers that were selected explicitly. If a driver is to be deleted, the Dependency Checker is called upon to perform the inter-driver dependency checking. The Dependency Checker determines the transaction number which caused the driver to be selected, and methodically removes all facts that were asserted in order to select the driver. This process also ensures that the status of related drivers (if any) is updated to indicate the change. The result is a list of drivers that were selected explicitly with no trace of the deleted driver or its (if any) implicitly-selected "required" drivers.

Driver Specification Phase

**************************

-----------------------------------------

Driver # | Driver

-----------------------------------------

1 CMM level 2

2 Complex system interfaces

3 Design method need

4 Design method training need

5 Evolutionary development

6 Existing hardware/software constraint

7 Incremental development

8 Integrated software management KPA

9 Intergroup coordination KPA

10 Lack of development method

11 Maintenance/support requirements

12 Need for CASE tool

13 Need for project level prototyping

14 Operational life cycle

15 Peer reviews KPA

16 Performance requirements

17 Phasing

18 Real time system

19 Requirements management KPA

20 Reuse library exists

21 Software configuration management KPA

22 Software product engineering KPA

23 Software project planning KPA

24 Software quality assurance KPA

25 Software subcontract management KPA

26 Software tracking and oversight KPA

27 Spiral process

28 Throw away prototyping

29 Training program KPA

e EXIT

Enter your selection:1

Please wait.

Checking Dependencies ....

Driver: 1 CMM level 2 REQUIRES Driver: 26 Software tracking and oversight KPA

Driver: 26 can be selected

Driver: 1 CMM level 2 REQUIRES Driver: 25 Software subcontract management KPA

Driver: 25 can be selected

Driver: 1 CMM level 2 REQUIRES Driver: 24 Software quality assurance KPA

Driver: 24 can be selected

Driver: 1 CMM level 2 REQUIRES Driver: 23 Software project planning KPA

Driver: 23 can be selected

Driver: 1 CMM level 2 REQUIRES Driver: 21 Software configuration management KPA

Driver: 21 can be selected

Driver: 1 CMM level 2 REQUIRES Driver: 19 Requirements management KPA

Driver: 19 can be selected

...Dependency Check - complete

Driver 1: CMM level 2 has been selected successfully.

Figure 8: Driver Selection Phase

Dependency Checker

The Dependency Checker knowledge source is tightly-coupled with the Driver Selection/Deletion Handler knowledge source in supporting driver selection and deletion. It enforces the inter-driver dependencies. The Driver/Activity dependency checking is deferred until process model generation. The inter-driver dependencies are obtained from the Driver/ Driver Relationships knowledge source which is shown in figure 1. The Dependency Checker knowledge source contains rules that implement the dependency checking algorithms for driver selection and driver deletion.

Dependency Checking for Driver Selection:

As mentioned in the previous section each operation is represented by a tree in a forest of operations. Before a driver can be selected for the project, one has to ensure that if the driver "requires" other drivers, and whether those drivers are already selected. As drivers that cannot be selected successfully are not available to the user for selection, the selection is ensured to be successful. The user need not proceed on a trial-and-error basis. The dependency checking algorithm for the driver selection employs a depth-first-strategy in traversing the driver tree. An example of driver graphs are shown in figure 9 below.

Figure 9: Driver Dependency Tree

The branches between the nodes indicate the "requires" relationship. The root of the tree corresponds to the explicitly-selected driver whereas the other nodes indicate the drivers that were included implicitly.

The algorithm begins by gathering the successors of the node to be selected and their successors in turn, repeatedly in a depth-first order. Starting from the leaves, the algorithm first checks whether the node is prevented from being selected by virtue of some previous selection operation. If so, then the operation is aborted. If not, then the algorithm continues to ensure exactly-one-of and atmost-one-of constraints are satisfied. This process repeated for all elements in the successor list until the root node is selected.

Dependency Checking for Driver Deletion

The Driver Deletion operation is handled easily because of the unique transaction id and the associated data structure. The user is presented with only those drivers that were selected explicitly. Hence, the user can only delete drivers that occur at the root of some tree in the forest of selections. The Driver Selection/Deletion Handler passes the identification number of the driver to be deleted to the Dependency Checker. The Dependency Checker traces out the tree with the specified driver occurring at the root and removes all facts related to that selection operation. It also updates the status of both the explicitly-selected and implicitly-selected features.

For example Figure 9 shows a forest consisting of two selection operations: Select A and Select B. If the user requests B to be deleted, the Dependency Checker would simply delete all traces of the tree with B at the root. However, B would still exist in the forest as it was "required" by some other driver, namely A.

Project-Specific Process Model Generator:

Assembling the spiral_cmm Project-Specific Process Model. Please Wait.......

To view the components of the spiral_cmm Project-Specific Process Model,

Please select one of the following choices:

Choices Perform

******* *******

1 View the selected Project-Specific Process Model Drivers

2 View Project-Specific Process Model leaf level Activity types

3 View Project-Specific Process Model aggregate and leaf level Activity types

4 Change Driver Selection for Project-Specific Process Model

5 Save Project-Specific Process Model

e End viewing spiral_cmm Project-Specific Process Model components and Quit PROGEN

Please type your selection and press return: 1

This section describes the Project-Specific Process Model Generator knowledge source which assembles and generates the process model by tailoring the SPM domain model. The process engineer is queried for a process model name and a project-specific process model is generated under the specified name. The following figure shows a process model generated under the name spiral_cmm.

Figure 10: Process Model Generation Phase

Figure 10 Shows the menu of choices presented to the user after the process model is assembled. Choice 1 provides a list of all (explicitly and implicitly) selected drivers. Figure 11 shows the result of the selection of drivers CMM level 2, Requirements management KPA, Software configuration management KPA, Software project planning KPA, Software quality assurance KPA, Software subcontract management KPA, and Software tracking and oversight KPA.

The Driver selected thus far

*****************************

CMM level 2

Requirements management KPA *

Software configuration management KPA *

Software project planning KPA *

Software quality assurance KPA *

Software subcontract management KPA *

Software tracking and oversight KPA *

Figure 11: List of drivers selected (*- indicates implicitly-selected drivers).

Choice 2 provides a list of all leaf level activities arranged in alphabetical order, as shown in Figure 12.

Architectural_Design_KS (kernel)

Critical_Computer_Resources_Estimation_OS(optional)

Critical_Computer_Resources_Review_OS(optional)

Definition_of_Project_Commitments_OS(optional)

Detailed_Design_KS (kernel)

Establishing_CM_Library_OS(optional)

Identification_of_SCM_Work_Products_OS(optional)

Integration_Testing_KS (kernel)

Life_Cycle_Selection_OS(optional)

Planning_Project_Facilities_and_Support_Tools_OS(optional)

Planning_Subcontract_Management_OS(optional)

Preparing_SCM_Plan_OS(optional)

Preparing_SQA_Plan_OS(optional)

Project_Commitments_Review_OS(optional)

Project_Progress_Review_OS(optional)

Requirements_Analysis_and_Specification_KS (kernel)

Reviewing_Technical_Product_KS (kernel)

SQA_Audit_of_Work_Products_OS(optional)

SW_Effort_and_Cost_Review_OS(optional)

Software_Cost_Estimation_OS(optional)

Software_Development_Planning_KS (kernel)

Software_Requirements_Review_OS(optional)

Software_Schedule_Planning_OS(optional)

Software_Schedules_Review_OS(optional)

Software_Size_Estimation_OS(optional)

System_and_Acceptance_Testing_KS (kernel)

Tracking_Subcontract_Progress_OS(optional)

Unit_Coding_KS (kernel)

Unit_Testing_KS (kernel)

Work_Product_Size_Review_OS(optional)

Figure 12: List of all leaf level activities - for Drivers CMM Level 2 & 3

Choice 3 shows the Aggregation Hierarchy of the Project-Specific Process Model as depicted in Figure 13.

Spiral_Life_Cycle_Domain_KA (kernel aggregate agh_root)

Spiral_Planning_OA (optional aggregate)

Reviewing_Progress_OA (optional aggregate)

Work_Product_Size_Review_OS (optional)

Tracking_Subcontract_Progress_OS (optional)

Software_Schedules_Review_OS (optional)

SW_Effort_and_Cost_Review_OS (optional)

SQA_Audit_of_Work_Products_OS (optional)

Project_Progress_Review_OS (optional)

Project_Commitments_Review_OS (optional)

Critical_Computer_Resources_Review_OS (optional)

Developing_Product_KA (kernel aggregate)

Reviewing_Technical_Product_KS (kernel)

Developing_and_Verifying_Product_KA (kernel aggregate)

System_Testing_Cycle_KA (kernel aggregate)

System_and_Acceptance_Testing_KS (kernel)

Requirements_Analysis_and_Specification_Cycle_KA (kernel aggregate)

Software_Requirements_Review_OS (optional)

Requirements_Analysis_and_Specification_KS (kernel)

Project_Planning_Cycle_KA (kernel aggregate)

Software_Development_Planning_KS (kernel)

Planning_Subcontract_Management_OS (optional)

Management_Planning_OA (optional aggregate)

Software_Size_Estimation_OS (optional)

Software_Schedule_Planning_OS (optional)

Software_Cost_Estimation_OS (optional)

Preparing_SQA_Plan_OS (optional)

Preparing_SCM_Plan_OS (optional)

Planning_Project_Facilities_and_Support_Tools_OS (optional)

Life_Cycle_Selection_OS (optional)

Identification_of_SCM_Work_Products_OS (optional)

Establishing_CM_Library_OS (optional)

Definition_of_Project_Commitments_OS (optional)

Critical_Computer_Resources_Estimation_OS (optional)

Preliminary_Design_Cycle_KA (kernel aggregate)

Architectural_Design_KS (kernel)

Construction_and_Test_Cycle_KA (kernel aggregate)

Unit_Testing_KS (kernel)

Unit_Coding_KS (kernel)

Integration_Testing_KS (kernel)

Detailed_Design_KS (kernel)

Figure 13: Project-Specific Process Model for Selected Drivers

Choice 4 returns the user to the main menu where the domain model can be tailored further. Choice 5 provides the user with the facility to provide a filename and save the Process Model Specification.

Once driver selection has been completed, the Process Model Generator knowledge source begins the process of assembling the process model. It consists of rules for tailoring the domain model to generate the process model. Before assembling the target system, it checks if the exactly-one-of and atleast-one-of constraints are satisfied.

The project-specific process model (PSPM) generated by this knowledge source consists of:

1. PSPM_DRIVERS_SET which contains the features supported by the target system,

2. PSPM_LEAF_ACTIVITIES which contains the leaf level activity types that make up the target system,

3. PSPM_AGGR. which contains the target system aggregation hierarchy, and

4. PSPM_GEN_SPEC which contains the tailored versions of the generalization/ specialization hierarchies for the target system.

The Project-Specific Process Model Generator knowledge source contains rules to display the process model. The Drivers and leaf level objects are presented to the user in separate lists. The Process Model is displayed to the user in an indented form to show the different levels of the hierarchy. This knowledge source also includes rules to save the process model specification for later retrieval.

Project-Specific Process Model Storage, Retrieval and Reuse Module

The Project-Specific Process Model Storage, Retrieval and Reuse Module knowledge source contains rules to store the process model specification for later reuse.

You may browse the drivers incorporated in the

spiral:spiral_dm domain model, or

Specify the drivers for the Project, or

Start the Project Specific Process Model generation or

quit PROGEN .

Choices Perform

******* *******

1 Browse the Domain Model

2 Specify Drivers for the Project

3 Initiate Project Specific Process Model Generation Phase

4 Load a Project Specific Process Model

e Quit PROGEN

Please type your choice and press return: 4

Please enter the filename of the Project Specific Process Model or Enter c to cancel:spiral.cmm

Loading Specified Project Specific Process Model......

File Name : spiral.cmm

Project Specific Process Model Name : CMM

Process Drivers Selected : 1

1 CMM level 2 Package

If this is the correct file, enter c to continue, or

enter e to return to main menu :c

...... loading complete

Figure 14: Process Model Retrieval Phase

The user specifies the name of a process model specification file. The Retrieval module retrieves the file and display the contents for the user to verify. Once the user confirms that the file is the required one, it is loaded with assistance from the Driver Selection/Deletion Handler. The user in now free to make any modification necessary for the particular project at hand.

Conclusions

This report has described the PROGEN knowledge-based system for process model generation, tailoring and reuse. The PROGEN system is based on the Knowledge-based Requirements Elicitation Tool (KBRET) within the Knowledge-Based Software Engineering Environment (KBSEE). It has been completely re-engineered to take advantage of the CLIPS object-oriented language COOL. PROGEN is application-domain independent in that it can process any domain model specified according to the methods supported by the KBSEE. The KBSEE outputs a domain-dependent knowledge base, which serves as the initial fact base for PROGEN, as shown in the Section 8 Appendix. PROGEN then processes the facts representing a domain model into its COOL object-oriented representation. The PROGEN user-interface has been tailored to deal with SPM-generated process models, but, in general, it may be tailored for any domain model.

Acknowledgments

The domain modeling research and development of the Knowledge-Based Software Engineering Environment was sponsored in part by NASA Goddard Space Flight Center and the Virginia Center of Innovative Technology. The Software Through Pictures CASE tool was donated to GMU by Interactive Development Environments. We gratefully acknowledge the continuing support of the Northrop/Grumman Corporation as an Industrial Partner of the Center for Information Systems Integration and Evolution (CISIE). Portions of the research were sponsored by an ARPA grant, administered by the Office of Naval Research under grant number N00014�92�J�4038. The application of the domain modeling technology to process modeling was sponsored by the Virginia Center of Excellence in Software Reuse and the Software Productivity Consortium. We also gratefully acknowledge the Consortium for providing us with information on the Spiral Model. The authors gratefully acknowledge the contributions of C. Bosch, E. O'Hara-Schettino, V. Sugumaran, and I. Tavakoli, in developing the prototype Knowledge-Based Software Engineering Environment. The PROGEN implementation was done by G. R. Mohan, based on the KBRET specification and implementation of V. Sugumaran's doctoral dissertation.

References

[Boehm 88] Boehm B., "A Spiral Model of Software Development and Enhancement," IEEE Computer, May 1988.

[Boehm 89] Boehm B. and F. Belz, "Experiences with the Spiral Model as a Process Model Generator," Proc. 5th International Software Process Workshop, 1989.

[CMM 93] Paulk M.C., B. Curtis, M.B. Chrissis, C.V. Weber, "Capability Maturity Model for Software," Version 1.1, CMU/SEI-93-TR-24, ESC-TR-93-177, Software Engineering Institute, CMU, Pittsburgh, PA, February 1993.

[Gomaa 89] Gomaa H, R Fairley and L Kerschberg, "Towards an Evolutionary Domain Life Cycle Model," Proc. Workshop on Domain Modeling for Software Engineering, OOPSLA'89, New Orleans, October 1989.

[Gomaa 91a] Gomaa H and L Kerschberg, "An Evolutionary Domain Life Cycle Model for Domain Modeling and Target System Generation," Proc. Workshop on Domain Modeling for Software Engineering, International Conference on Software Engineering, Austin, May 1991.

[Gomaa 91b] Gomaa H, L. Kerschberg, C. Bosch, V. Sugumaran, I Tavakoli, "A Prototype Software Engineering Environment for Domain Modeling and Reuse," Proc Fourth Annual Workshop on Software Reuse, Herndon, VA, November 1991.

[Gomaa 92] Gomaa H, L. Kerschberg, V. Sugumaran, "A Knowledge-Based Approach for Generating Target System Specifications from a Domain Model," Proc. IFIP World Computer Congress, Madrid, Spain, September 1992.

[Gomaa 93] Gomaa H, "A Reuse-Oriented Approach for Structuring and Configuring Distributed Applications," Software Engineering Journal, March 1993.

[Gomaa 94] Gomaa H, L. Kerschberg, C. Bosch, V. Sugumaran, I Tavakoli, "A Prototype Domain Modeling Environment for Reusable Software Architectures". Proc IEEE International Conference on Software Reuse, Rio de Janeiro, Brazil, November 1994.

[Gomaa 95] Gomaa H and L Kerschberg, "Domain Modeling for Software Reuse and Evolution," Proc. Seventh International Workshop on Computer-Aided Software Engineering, Toronto, Canada, July 1995.

Appendix - Spiral Process Model Domain Model Expressed as facts for PROGEN

( deffacts domain_model_facts " "

( name-of-domain spiral:spiral_dm)

( Activity: 1 Ada_Based_Design_Method_Selection optional variant )

( Activity: 2 Analyzing_Defect_Data_OS optional )

( Activity: 3 Analyzing_Risks_OA optional aggregate )

( Activity: 4 Architectural_Design_KS kernel )

( Activity: 5 Architectural_Design_Peer_Review_OS optional )

( Activity: 6 Code_Unit_Peer_Review_OS optional )

( Activity: 7 Commitment_To_Planning_OS optional )

( Activity: 8 Construction_and_Test_Cycle_KA kernel aggregate )

( Activity: 9 Critical_Computer_Resources_Estimation_OS optional )

( Activity: 10 Critical_Computer_Resources_Review_OS optional )

( Activity: 11 Defining_Approach_OS optional )

( Activity: 12 Defining_Objectives_Alternatives_and_Constraints_OA optional aggregate )

( Activity: 13 Definition_of_Project_Commitments_OS optional )

( Activity: 14 Design_Method_Training_OS optional )

( Activity: 15 Design_Performance_Analysis_OS optional )

( Activity: 16 Design_Prototyping_OS optional )

( Activity: 17 Detailed_Design_KS kernel )

( Activity: 18 Detailed_Design_Peer_Review_OS optional )

( Activity: 19 Developing_Product_KA kernel aggregate )

( Activity: 20 Developing_Training_Plan_OS optional )

( Activity: 21 Developing_and_Updating_EoS_OS optional )

( Activity: 22 Developing_and_Verifying_Product_KA kernel aggregate )

( Activity: 23 Distributed_Design_Method_Selection optional variant )

( Activity: 24 Establishing_CM_Library_OS optional )

( Activity: 25 Identification_of_SCM_Work_Products_OS optional )

( Activity: 26 Integrated_Software_Management_Planning_OA optional aggregate )

( Activity: 27 Integration_Testing_KS kernel )

( Activity: 28 Integration_Testing_Peer_Review_OS optional )

( Activity: 29 Life_Cycle_Selection_OS optional )

( Activity: 30 Local_Design_Tailoring_OS optional )

( Activity: 31 Management_Planning_OA optional aggregate )

( Activity: 32 Monitoring_and_Reviewing_OA optional aggregate )

( Activity: 33 Monitoring_and_Reviewing_Product_OS optional )

( Activity: 34 Object_Oriented_Design_Method_Selection optional variant )

( Activity: 35 Performance_Testing_OS optional )

( Activity: 36 Performance_Testing_Peer_Review_OS optional )

( Activity: 37 Performing_Risk_Analysis_OS optional )

( Activity: 38 Planning_Peer_Review_Management_OS optional )

( Activity: 39 Planning_Project_Facilities_and_Support_Tools_OS optional )

( Activity: 40 Planning_Risk_Aversion_Strategy_OS optional )

( Activity: 41 Planning_Subcontract_Management_OS optional )

( Activity: 42 Planning_for_Architectural_Design_Cycle_OS optional )

( Activity: 43 Planning_for_Construction_and_Test_Cycle_OS optional )

( Activity: 44 Planning_for_Evolutionary_Development_OS optional )

( Activity: 45 Planning_for_Incremental_Development_OS optional )

( Activity: 46 Planning_for_Requirements_Cycle_OS optional )

( Activity: 47 Planning_for_System_Testing_Cycle_OS optional )

( Activity: 48 Planning_to_Identify_Critical_Engineering_Dependencies_OS optional )

( Activity: 49 Planning_to_Manage_Cost_and_Effort_OS optional )

( Activity: 50 Planning_to_Manage_Critical_Computer_Resources_OS optional )

( Activity: 51 Planning_to_Manage_Critical_Paths_and_Dependencies_OS optional )

( Activity: 52 Planning_to_Manage_Size_of_Work_Products_OS optional )

( Activity: 53 Preliminary_Design_Cycle_KA kernel aggregate )

( Activity: 54 Preparation_of_Enhanced_Documentation_OS optional )

( Activity: 55 Preparing_SCM_Plan_OS optional )

( Activity: 56 Preparing_SQA_Plan_OS optional )

( Activity: 57 Product_Change_Control_OS optional )

( Activity: 58 Project_Commitments_Review_OS optional )

( Activity: 59 Project_Level_Prototyping_OS optional )

( Activity: 60 Project_Plan_Peer_Review_OS optional )

( Activity: 61 Project_Planning_Cycle_KA kernel aggregate )

( Activity: 62 Project_Progress_Review_OS optional )

( Activity: 63 Project_Risks_Review_OS optional )

( Activity: 64 Real_Time_Design_Method_Selection optional variant )

( Activity: 65 Requirements_Analysis_and_Specification_Cycle_KA kernel aggregate )

( Activity: 66 Requirements_Analysis_and_Specification_KS kernel )

( Activity: 67 Requirements_Prototyping_OS optional )

( Activity: 68 Requirements_Specification_Peer_Review_OS optional )

( Activity: 69 Resolving_Risks_OS optional )

( Activity: 70 Reviewing_Context_OS optional )

( Activity: 71 Reviewing_Progress_OA optional aggregate )

( Activity: 72 Reviewing_Risk_Analysis_OS optional )

( Activity: 73 Reviewing_Technical_Product_KS kernel )

( Activity: 74 Revising_Training_Plan_OS optional )

( Activity: 75 SQA_Audit_of_Work_Products_OS optional )

( Activity: 76 SW_Effort_and_Cost_Review_OS optional )

( Activity: 77 Scheduling_and_Planning_OS optional )

( Activity: 78 Select_or_Adapt_Reusable_Components_OS optional )

( Activity: 79 Selection_of_CASE_Tool_OS optional )

( Activity: 80 Selection_of_Design_Method_OVS optional gsh_root )

( Activity: 81 Selection_of_Development_Method_OS optional )

( Activity: 82 Software_Cost_Estimation_OS optional )

( Activity: 83 Software_Development_Planning_KS kernel )

( Activity: 84 Software_Requirements_Review_OS optional )

( Activity: 85 Software_Schedule_Planning_OS optional )

( Activity: 86 Software_Schedules_Review_OS optional )

( Activity: 87 Software_Size_Estimation_OS optional )

( Activity: 88 Spiral_Life_Cycle_Domain_KA kernel aggregate agh_root )

( Activity: 89 Spiral_Planning_OA optional aggregate )

( Activity: 90 System_Testing_Cycle_KA kernel aggregate )

( Activity: 91 System_and_Acceptance_Testing_KS kernel )

( Activity: 92 System_and_Acceptance_Testing_Peer_Review_OS optional )

( Activity: 93 Technical_Planning_OA optional aggregate )

( Activity: 94 Tracking_Critical_Engineering_Dependencies_OS optional )

( Activity: 95 Tracking_Peer_Reviews_OS optional )

( Activity: 96 Tracking_Subcontract_Progress_OS optional )

( Activity: 97 Unit_Coding_KS kernel )

( Activity: 98 Unit_Testing_KS kernel )

( Activity: 99 Unit_Testing_Peer_Review_OS optional )

( Activity: 100 Updating_Spiral_Planning_Documents_OA optional aggregate )

( Activity: 101 Work_Product_Size_Review_OS optional )

( Driver: 1 CMM level 2 )

( Driver: 2 CMM level 3 )

( Driver: 3 Complex system interfaces )

( Driver: 4 Design method need )

( Driver: 5 Design method training need )

( Driver: 6 Evolutionary development )

( Driver: 7 Existing hardware/software constraint )

( Driver: 8 Incremental development )

( Driver: 9 Integrated software management KPA )

( Driver: 10 Intergroup coordination KPA )

( Driver: 11 Lack of development method )

( Driver: 12 Maintenance/support requirements )

( Driver: 13 Need for CASE tool )

( Driver: 14 Need for project level prototyping )

( Driver: 15 Operational life cycle )

( Driver: 16 Peer reviews KPA )

( Driver: 17 Performance requirements )

( Driver: 18 Phasing )

( Driver: 19 Real time system )

( Driver: 20 Requirements management KPA )

( Driver: 21 Reuse library exists )

( Driver: 22 Software configuration management KPA )

( Driver: 23 Software product engineering KPA )

( Driver: 24 Software project planning KPA )

( Driver: 25 Software quality assurance KPA )

( Driver: 26 Software subcontract management KPA )

( Driver: 27 Software tracking and oversight KPA )

( Driver: 28 Spiral process )

( Driver: 29 Throw away prototyping )

( Driver: 30 Training program KPA )

( PROGEN CMM level 2 Driver 1 requires Requirements management KPA Driver 20 )

( PROGEN CMM level 2 Driver 1 requires Software configuration management KPA Driver 22 )

( PROGEN CMM level 2 Driver 1 requires Software project planning KPA Driver 24 )

( PROGEN CMM level 2 Driver 1 requires Software quality assurance KPA Driver 25 )

( PROGEN CMM level 2 Driver 1 requires Software subcontract management KPA Driver 26 )

( PROGEN CMM level 2 Driver 1 requires Software tracking and oversight KPA Driver 27 )

( PROGEN CMM level 3 Driver 2 requires CMM level 2 Driver 1 )

( PROGEN CMM level 3 Driver 2 requires Integrated software management KPA Driver 9 )

( PROGEN CMM level 3 Driver 2 requires Intergroup coordination KPA Driver 10 )

( PROGEN CMM level 3 Driver 2 requires Peer reviews KPA Driver 16 )

( PROGEN CMM level 3 Driver 2 requires Software product engineering KPA Driver 23 )

( PROGEN CMM level 3 Driver 2 requires Training program KPA Driver 30 )

( PROGEN Design method need Driver 4 requires Design method training need Driver 5 )

( PROGEN Lack of development method Driver 11 requires Design method need Driver 4 )

( PROGEN Real time system Driver 19 requires Performance requirements Driver 17 )

( PROGEN Complex system interfaces Driver 3 supported-by 16 Design_Prototyping_OS optional )

( PROGEN Design method need Driver 4 supported-by 80 Selection_of_Design_Method_OVS optional gsh_root )

( PROGEN Design method training need Driver 5 supported-by 14 Design_Method_Training_OS optional )

( PROGEN Evolutionary development Driver 6 supported-by 34 Object_Oriented_Design_Method_Selection optional variant )

( PROGEN Evolutionary development Driver 6 supported-by 44 Planning_for_Evolutionary_Development_OS optional )

( PROGEN Evolutionary development Driver 6 supported-by 67 Requirements_Prototyping_OS optional )

( PROGEN Existing hardware/software constraint Driver 7 supported-by 30 Local_Design_Tailoring_OS optional )

( PROGEN Incremental development Driver 8 supported-by 44 Planning_for_Evolutionary_Development_OS optional )

( PROGEN Incremental development Driver 8 supported-by 45 Planning_for_Incremental_Development_OS optional )

( PROGEN Incremental development Driver 8 supported-by 67 Requirements_Prototyping_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 49 Planning_to_Manage_Cost_and_Effort_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 50 Planning_to_Manage_Critical_Computer_Resources_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 51 Planning_to_Manage_Critical_Paths_and_Dependencies_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 52 Planning_to_Manage_Size_of_Work_Products_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 63 Project_Risks_Review_OS optional )

( PROGEN Integrated software management KPA Driver 9 supported-by 77 Scheduling_and_Planning_OS optional )

( PROGEN Intergroup coordination KPA Driver 10 supported-by 48 Planning_to_Identify_Critical_Engineering_Dependencies_OS optional )

( PROGEN Intergroup coordination KPA Driver 10 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Intergroup coordination KPA Driver 10 supported-by 77 Scheduling_and_Planning_OS optional )

( PROGEN Intergroup coordination KPA Driver 10 supported-by 94 Tracking_Critical_Engineering_Dependencies_OS optional )

( PROGEN Lack of development method Driver 11 supported-by 81 Selection_of_Development_Method_OS optional )

( PROGEN Maintenance/support requirements Driver 12 supported-by 54 Preparation_of_Enhanced_Documentation_OS optional )

( PROGEN Maintenance/support requirements Driver 12 supported-by 67 Requirements_Prototyping_OS optional )

( PROGEN Need for CASE tool Driver 13 supported-by 79 Selection_of_CASE_Tool_OS optional )

( PROGEN Need for project level prototyping Driver 14 supported-by 59 Project_Level_Prototyping_OS optional )

( PROGEN Operational life cycle Driver 15 supported-by 34 Object_Oriented_Design_Method_Selection optional variant )

( PROGEN Operational life cycle Driver 15 supported-by 44 Planning_for_Evolutionary_Development_OS optional )

( PROGEN Operational life cycle Driver 15 supported-by 45 Planning_for_Incremental_Development_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 5 Architectural_Design_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 6 Code_Unit_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 18 Detailed_Design_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 28 Integration_Testing_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 38 Planning_Peer_Review_Management_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 60 Project_Plan_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 68 Requirements_Specification_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 77 Scheduling_and_Planning_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 92 System_and_Acceptance_Testing_Peer_Review_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 95 Tracking_Peer_Reviews_OS optional )

( PROGEN Peer reviews KPA Driver 16 supported-by 99 Unit_Testing_Peer_Review_OS optional )

( PROGEN Performance requirements Driver 17 supported-by 15 Design_Performance_Analysis_OS optional )

( PROGEN Performance requirements Driver 17 supported-by 16 Design_Prototyping_OS optional )

( PROGEN Performance requirements Driver 17 supported-by 35 Performance_Testing_OS optional )

( PROGEN Performance requirements Driver 17 supported-by 36 Performance_Testing_Peer_Review_OS optional )

( PROGEN Phasing Driver 18 supported-by 45 Planning_for_Incremental_Development_OS optional )

( PROGEN Real time system Driver 19 supported-by 64 Real_Time_Design_Method_Selection optional variant )

( PROGEN Requirements management KPA Driver 20 supported-by 84 Software_Requirements_Review_OS optional )

( PROGEN Reuse library exists Driver 21 supported-by 78 Select_or_Adapt_Reusable_Components_OS optional )

( PROGEN Software configuration management KPA Driver 22 supported-by 24 Establishing_CM_Library_OS optional )

( PROGEN Software configuration management KPA Driver 22 supported-by 25 Identification_of_SCM_Work_Products_OS optional )

( PROGEN Software configuration management KPA Driver 22 supported-by 55 Preparing_SCM_Plan_OS optional )

( PROGEN Software product engineering KPA Driver 23 supported-by 2 Analyzing_Defect_Data_OS optional )

( PROGEN Software product engineering KPA Driver 23 supported-by 33 Monitoring_and_Reviewing_Product_OS optional )

( PROGEN Software product engineering KPA Driver 23 supported-by 54 Preparation_of_Enhanced_Documentation_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 9 Critical_Computer_Resources_Estimation_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 13 Definition_of_Project_Commitments_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 29 Life_Cycle_Selection_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 39 Planning_Project_Facilities_and_Support_Tools_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 82 Software_Cost_Estimation_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 85 Software_Schedule_Planning_OS optional )

( PROGEN Software project planning KPA Driver 24 supported-by 87 Software_Size_Estimation_OS optional )

( PROGEN Software quality assurance KPA Driver 25 supported-by 56 Preparing_SQA_Plan_OS optional )

( PROGEN Software quality assurance KPA Driver 25 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Software quality assurance KPA Driver 25 supported-by 75 SQA_Audit_of_Work_Products_OS optional )

( PROGEN Software subcontract management KPA Driver 26 supported-by 41 Planning_Subcontract_Management_OS optional )

( PROGEN Software subcontract management KPA Driver 26 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Software subcontract management KPA Driver 26 supported-by 96 Tracking_Subcontract_Progress_OS optional )

( PROGEN Software tracking and oversight KPA Driver 27 supported-by 10 Critical_Computer_Resources_Review_OS optional )

( PROGEN Software tracking and oversight KPA Driver 27 supported-by 58 Project_Commitments_Review_OS optional )

( PROGEN Software tracking and oversight KPA Driver 27 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Software tracking and oversight KPA Driver 27 supported-by 76 SW_Effort_and_Cost_Review_OS optional )

( PROGEN Software tracking and oversight KPA Driver 27 supported-by 86 Software_Schedules_Review_OS optional )

( PROGEN Software tracking and oversight KPA Driver 27 supported-by 101 Work_Product_Size_Review_OS optional )

( PROGEN Spiral process Driver 28 supported-by 7 Commitment_To_Planning_OS optional )

( PROGEN Spiral process Driver 28 supported-by 11 Defining_Approach_OS optional )

( PROGEN Spiral process Driver 28 supported-by 21 Developing_and_Updating_EoS_OS optional )

( PROGEN Spiral process Driver 28 supported-by 33 Monitoring_and_Reviewing_Product_OS optional )

( PROGEN Spiral process Driver 28 supported-by 37 Performing_Risk_Analysis_OS optional )

( PROGEN Spiral process Driver 28 supported-by 40 Planning_Risk_Aversion_Strategy_OS optional )

( PROGEN Spiral process Driver 28 supported-by 42 Planning_for_Architectural_Design_Cycle_OS optional )

( PROGEN Spiral process Driver 28 supported-by 43 Planning_for_Construction_and_Test_Cycle_OS optional )

( PROGEN Spiral process Driver 28 supported-by 46 Planning_for_Requirements_Cycle_OS optional )

( PROGEN Spiral process Driver 28 supported-by 47 Planning_for_System_Testing_Cycle_OS optional )

( PROGEN Spiral process Driver 28 supported-by 57 Product_Change_Control_OS optional )

( PROGEN Spiral process Driver 28 supported-by 62 Project_Progress_Review_OS optional )

( PROGEN Spiral process Driver 28 supported-by 69 Resolving_Risks_OS optional )

( PROGEN Spiral process Driver 28 supported-by 70 Reviewing_Context_OS optional )

( PROGEN Spiral process Driver 28 supported-by 72 Reviewing_Risk_Analysis_OS optional )

( PROGEN Spiral process Driver 28 supported-by 77 Scheduling_and_Planning_OS optional )

( PROGEN Throw away prototyping Driver 29 supported-by 67 Requirements_Prototyping_OS optional )

( PROGEN Training program KPA Driver 30 supported-by 20 Developing_Training_Plan_OS optional )

( PROGEN Training program KPA Driver 30 supported-by 74 Revising_Training_Plan_OS optional )

( PROGEN Training program KPA Driver 30 supported-by 77 Scheduling_and_Planning_OS optional )

( driver-explanation 1 CMM level 2

"This process driver package addresses the CMM level 2 KPAs.

" )

( driver-explanation 2 CMM level 3

"This is CMM level 3 package.

" )

( driver-explanation 3 Complex system interfaces

"This process driver addresses numerous and difficult interface.

" )

( driver-explanation 4 Design method need

"This process driver addresses the need for a design method.

" )

( driver-explanation 5 Design method training need

"This process driver addresses the need for training in the selected software design method.

" )

( driver-explanation 6 Evolutionary development

"This process driver addresses the need for evolutionary development.

" )

( driver-explanation 7 Existing hardware/software constraint

"This process driver addresses compatibilty with existing hardware or software.

" )

( driver-explanation 8 Incremental development

"This process driver addresses the need for incremental development.

" )

( driver-explanation 9 Integrated software management KPA

"This process driver is a CMM level 3 KPA.

" )

( driver-explanation 10 Intergroup coordination KPA

"This process driver is a CMM level 3 KPA.

" )

( driver-explanation 11 Lack of development method

"This process driver addresses the lack of an overall software development method.

" )

( driver-explanation 12 Maintenance/support requirements

"This process driver addresses difficult requirements for maintenane or support.

" )

( driver-explanation 13 Need for CASE tool

"This process driver addresses the need for a CASE tool or 4GL.

" )

( driver-explanation 14 Need for project level prototyping

"This process driver addresses the need for project level prototyping due to lack of understanding.

" )

( driver-explanation 15 Operational life cycle

"This process driver addresses the issue that the system will be fielded for a long time.

" )

( driver-explanation 16 Peer reviews KPA

"This process driver is a CMM level 3 KPA.

" )

( driver-explanation 17 Performance requirements

"This process driver addresses difficult requirements for processing speed, memory, and efficiency.

" )

( driver-explanation 18 Phasing

"This process driver addresses the need for phasing with system increments.

" )

( driver-explanation 19 Real time system

"This process driver addresses the development of a Real time system.

" )

( driver-explanation 20 Requirements management KPA