Domain Modeling of the Spiral Process Model
Principal Investigators:
Hassan Gomaa
Larry Kerschberg
Graduate Research Assistants:
Ghulam Ahmad Farrukh
Rajan Girish Mohan
Center for Information Systems Integration and Evolution
Department of Information and Software Systems Engineering
George Mason University
Fairfax, Virginia, 22030-4444
November 1995
1. Introduction
This report describes the application of the domain modeling method and the prototype Knowledge Based Software Engineering Environment, developed at George Mason University, to process modeling. In particular, it describes a domain model of the Spiral Process Model. In addition it describes how the key process areas of Software Engineering Institute's Capability Maturity Model can be incorporated into the domain model.
Section 2 of this paper briefly summarizes the domain modeling method and the prototype Knowledge Based Software Engineering Environment. Section 3 gives a brief overview of the Spiral Process Model developed by Barry Boehm and SEI's Capability Maturity Model (CMM). Section 4 describes the general approach of mapping the domain modeling concepts to process modeling. Section 5 describes the domain model for the spiral model, with the addition of the key process areas for level 2 and level 3.
It should be noted that the domain model is an abstraction of the spiral model, so it does not reflect every aspect of it. Its main goal is to demonstrate how a domain model of the spiral model could be used to support a process model generator.
2. Domain Modeling and the Knowledge Based Software Engineering Environment
2.1 Introduction
At George Mason University, a project is underway to support software engineering lifecycles, methods, and environments to support software reuse at the requirements and design phases of the software lifecycle, in addition to the coding phase. A reuse-oriented software lifecycle, the Evolutionary Domain Lifecycle [Gomaa89, Gomaa91a], has been proposed, which is a highly iterative lifecycle that takes an application domain perspective allowing the development of families of systems. Current emphasis is on the domain analysis and specification phase of the EDLC for developing an application domain model, which captures the similarities and variations of the domain.
2.2 Domain Modeling
A Domain Model is a problem-oriented architecture 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.
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 [Gomaa93]. The different views are developed iteratively.
a) 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. Objects 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.
b) 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.
c) State transition diagrams. Since each object is modeled as a sequential task, an object may be defined by means of a state transition diagram, whose execution is by definition strictly sequential.
d) 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, modifying or suppressing operations. In domain modeling, the variants of a domain object type are stored in a Generalization / Specialization Hierarchy (GSH), which supports the IS-A relationship.
e) Feature / Object dependencies. This view relates the end-user's perspective of the domain, namely the features supported by the domain, to the object types in the domain model. It shows for each feature (domain requirement) the object types required to support the feature. Also defined are any prerequisite features required and any mutually exclusive features. This view is particularly important for optional features, since it is the selection of the optional features, and the object types required to support them, that determine the nature of the desired target system.
2.3 Generation of Target System Specification
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 are reused by selecting those features required in the target system and then tailoring the domain model, subject to the appropriate feature object dependency constraints, to generate the target system specification.
2.4 Knowledge Based Software Engineering Environment
A proof-of-concept experiment has also been carried out to develop a prototype domain modeling environment [Gomaa94, Gomaa95], which consists of an integrated set of software tools that 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 CASE tool are used to represent the multiple views of the domain model, namely the Aggregation Hierarchy, the Object Communication Diagrams, the Generalization / Specialization Hierarchies and the State Transition Diagrams. However, the multiple views are semantically interpreted 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 defined using a Feature / Object Editor.
A knowledge based tool is used to assist with target system requirements elicitation and generation of the target system specification [Gomaa92]. The tool, implemented in NASA's 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 the multiple views of the target system specification.
The prototype environment is a domain independent environment. Thus it may be used to support the development of a domain model for any application domain that has been analyzed, and to generate target system specifications from it.
3. Process Models and the Capability Maturity Model
3.1 The Spiral Model
The Spiral Model is a 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, the radial coordinate represents cost and the angular coordinate represents progress in completion of a cycle of the model. Each cycle involves traversing through 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.
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. The process drivers 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 generator [Boehm89].
The spiral model consists of four quadrants:
Defining Objectives, Alternatives, and Constraints
Analyzing Risks
Developing Product
Spiral Planning
Each cycle of the spiral model iterates through these four quadrants. The number of cycles is project specific, so the description of the activities in each quadrant are intended to be general enough that they can be included in any cycle.
The goal of the spiral model is to be risk driven, so that the risks in a given cycle are determined during the Analyzing Risks section. 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 need to be performed to manage the risk.
3.2 The Capability Maturity Model
3.2.1 Introduction
The Capability Maturity Model was developed at the Software Engineering Institute [CMM 93]. It is a software process maturity framework to help organizations improve the software process. This section presents an overview of the CMM and is based on [CMM 93].
Software process maturity is the extent to which a software process is explicitly defined, managed, controlled, and effective. A maturity level is a well-defined plateau on the way to achieving a mature software process. Each level consists of a set of process goals that, when achieved, stabilize an important component of the software process. In the CMM, there are five levels of Software Process Maturity.
3.2.2 Levels of Software Maturity
Level 1: Initial. The software process is characterized as ad-hoc and occasionally even chaotic. Few processes are defined and success depends on individual effort.
Level 2: Repeatable. Basic project management processes are established to track cost, schedule and functionality. The necessary process discipline is in place to repeat similar successes on projects with similar applications.
Level 3: Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's software process for developing and maintaining software.
Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
Level 5: Continuous software process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
3.2.3 Level 2 Key Process Areas
Each maturity level consists of several key process areas. Each key process area defines "what should be done" to achieve that level, but not "how". Thus organizations may select the practices that are most appropriate for their business in order to achieve the goals of a key process area.
The Level 2 key process areas are as follows:
a) Requirements management. A common understanding is established between the customer and the software project of the customer's requirements.
Software requirements are controlled to establish a baseline. Software requirements are reviewed and agreed to by the customer. Software plans, products and activities are kept consistent with software requirements.
b) Software project planning. Reasonable plans are established for developing the product and managing the project.
Software estimates are documented for use in planning and tracking project. Software project activities and commitments are planned and documented. Affected groups and individuals agree to commitments.
c) Software project tracking and oversight. Adequate visibility of progress established so that effective action can be taken when project performance differs significantly from the project plan.
Actual results and performances are tracked against software plans. Corrective actions are taken and managed to closure when actual results and performance differs significantly from plan.
d) Software subcontract management. Select qualified software subcontractors and manage them effectively.
Software subcontract management combines the issues related to the level 2 key process areas (requirements management, project planning, project tracking and oversight, as well as software QA and configuration management), and applies them to control the subcontractor as appropriate.
e) Software quality assurance. Management is provided with visibility into the process being used and the products being built.
Software QA activities are planned. Adherence of software products and activities to standards, procedures and requirements is verified objectively. Affected groups and individuals are informed of software quality assurance activities and results. Unresolved noncompliance issues are addressed by senior management.
f) Software configuration management. The integrity of products of software project are established and maintained throughout the lifecycle.
Software configuration management activities are planned. Selected software work products are identified, controlled and available. Changes to software work products are controlled. Affected groups and individuals are informed of status and content of software baselines.
3.2.4 Level 3 Key Process Areas
The Level 3 key process areas are as follows:
a) Organization process focus. Organizational responsibility is established for software process activities. This enables an organization to improve the organization's overall software process capability.
b) Organization process definition. A usable set of software process assets is developed and maintained to improve process performance across the projects. It provides a basis for cumulative, long-term benefits to the organization.
c) Training program. A training program is established and maintained for a company's employees. This enables them to remain up to date in current technologies and benefits both the employees and the company.
d) Integrated software management. This key process area enables the integration of software engineering and management activities into a coherent, defined software process.
e) Software product engineering. This key process area enables an organization to consistently perform a well-defined engineering process. Such a process integrates all the software engineering activities to produce correct and consistent software products.
f) Intergroup coordination. This key process area enables the software engineering group to actively participate with other engineering groups so the project is better able to satisfy the customer's needs effectively and efficiently.
g) Peer reviews. Peer reviews are used to remove defects from the software work products early. An important aspect of peer reviews is to develop a better understanding of the software work products and of the defects that might be prevented.
4 Domain Modeling of the Evolutionary Spiral Process Model
4.1 Introduction
As the Spiral Process Model (SPM) encompasses several process models within it, an intriguing problem is to what extent the application domain modeling concept can be applied to the domain of process models.
Figure 1: Domain Modeling of Process Models
A domain model of the Spiral Process Model has been developed. By selecting the appropriate process drivers for a given project, the SPM domain model can then be adapted to generate a process model specifically tailored for the project. The domain modeling approach applied to process models is illustrated in Figure 1.
The approach for mapping the domain modeling concepts to the SPM captures the spiral effect more closely. Furthermore, the domain model also incorporates the key process areas of levels 2 and 3 of the CMM.
4.2 Mapping Domain Modeling Concepts to the SPM
In developing the SPM domain model, an important issue is how to represent the cycles and quadrants of the spiral model. First it was decided that an object in the domain model would be used to represent an activity in the spiral model and an aggregate object would be used to represent an aggregate activity, i.e., a composition of several activities.
In an earlier domain modeling effort, a decision was made to represent each cycle by means of an aggregate object, which had the effect of graphically straightening out the spiral. The aggregate object for a given cycle was then decomposed further at one or more levels of detail to show the activities in each quadrant. Although this approach demonstrated that a domain modeling could indeed be developed of the Spiral Model, it had the disadvantage of inflexibility if the number of cycles changed radically.
Instead, the approach now being adopted is to model the four quadrants of the spiral model as four aggregate activities in the domain model, each of which is decomposed further to reflect the activities carried out in each step. 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 idea being that these activities are performed when the appropriate cycle is being enacted.
4.3 Overview of SPM Domain Model
The first level of decomposition of the spiral model domain model is shown as the top level of the Aggregation Hierarchy (AH) and 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 Product, and Spiral Planning. Each of these aggregate objects is decomposed further to reflect the process activities defined for each quadrant.
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. In addition a kernel or optional object type can be specialized to reflect a variation on an activity that is only carried out in some generated process models. For example, Requirements Analysis and Specification is a kernel object, as it is 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).
An example of specialization is Design Method Selection. This object type can be specialized to reflect the different kinds of method selection that can be carried out, reflecting the characteristics of different projects. These specialized object types are Object-oriented Design Method Selection, Ada-based Design Method Selection, Real-Time Design Method Selection, and Distributed Design Method Selection.
The kernel of the spiral model domain model, consisting only of the kernel objects, constitutes the Waterfall model. This means that a project considered low risk can follow the waterfall life cycle.
4.4 Support for Process Drivers
The spiral model domain model is tailored according to a particular project's 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.
For example, the process driver "Throw away prototyping" is supported by the activity "Requirements Prototyping". This means that if the requirements are not understood, then the Requirements Prototyping activity needs to 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 the process driver "Performance Requirements" is supported by three activities, Design Performance Analysis, Design Prototyping, and Performance Testing. The Risk-Related Process Drivers and Supporting Activities are shown in Table 1.
There may also be driver / driver dependencies. Thus the process driver "Real-Time system" requires the driver "Performance requirements," since every real-time system has performance constraints. The Risk-Related Process Driver Relationships process drivers and supporting activities are shown in Table 2.
4.5 Support for the CMM
The CMM levels 2 and 3 key process areas have been incorporated into the spiral model by adding optional process activities corresponding to the levels 2 and 3 key process areas. The level 2 key process areas are described in Section 3.3.3 and level 3 key process areas are described in Section 3.3.4.
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. Table 3 shows the CMM Related Process Drivers, corresponding to the key process areas, and supporting process activities. Five of the seven key process areas have been modeled. These are Training program, Integrated software management, Software product engineering, Intergroup coordination, and Peer reviews. These are shown in Table 4. The two key process areas not modeled are Organization Process Focus and Organization Process Definition, which have been omitted because of their organizational aspects.
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.
There are certain activities which are supported either by the SPM or CMM. Table 5 shows the relationship that exists between the spiral model activities and CMM activities. There are five columns in Table 5, which has separate sections for each key process area in CMM levels 2 and 3. The first two columns contain the activity number and activity name in each key process area. The third column contains the node number of the activity (see SPM domain model in appendix). The fourth column lists whether the activity is supported by the SPM or not. The fifth column lists whether this is a kernel (K) or optional (O) activity. Table 5 is useful for project managers and/or external reviewers to decide whether a project is following the CMM criteria set forth for it.
5. Domain Model of the Evolutionary Spiral Process Model
The domain model of the spiral model is shown in the appendix. It consists of the aggregation hierarchy, object communication diagrams, one generalization specialization hierarchy, the process drivers and their supporting activities.
This section provides the object specifications for each leaf level activity in the domain model. These are brief informal English descriptions of what takes place in the activity. The numbers and names correspond to the numbering on the object communication diagrams:
1. Defining Objectives, Alternatives, and Constraints
1.1 Defining Approach
During this activity an approach is defined for solving the problem in the current cycle.
1.2 Developing and Updating EoS
During this activity the Estimate of Situation (EoS) is developed and updated. It takes Supporting Documents, Project Planning Documents, and Updated Project Planning Documents (for the current cycle) as input and produces the Draft Estimate of Situation, which is sent to Reviewing Context (1.3).
1.3 Reviewing Context
During this activity the context of the problem is reviewed using the Draft Estimate of Situation. The Draft Estimate of Situation is also reviewed and approved. The Approved Estimate of Situation is sent to the next quadrant, Analyzing Risks.
2. Analyzing Risks
2.1 Performing Risk Analysis
During this activity the Approved Estimate of Situation, Project Planning Documents, and Supporting Documents are used to perform risk analysis activities. The output from this object is a Draft Risk Management Plan (RMP), which is sent to the Reviewing Risk Analysis activity.
2.2 Reviewing Risk Analysis
Risk analysts review the Draft Risk Management Plan and approve it with any necessary changes. The output from this activity is sent to the Planning Risk Aversion Strategy activity.
2.3 Planning Risk Aversion Strategy
During this activity a risk aversion strategy is developed and included in the Approved Draft Risk Management Plan. The Updated Draft Risk Management Plan is sent to the Resolving Risks activity.
2.4 Resolving Risks
This activity takes the Updated Draft Risk Management Plan as input and produces the Risk Management Plan. During this activity, all the major risks of cycle are resolved. The Risk Management Plan is sent to the next quadrant, Developing Product.
3. Developing Product
3.1 Developing and Verifying Product
3.1.1 Project Planning Cycle
3.1.1.1 Software Development Planning
During this activity, a project plan is developed by a team of project planners. The Project Plan includes technical and management plans which are developed in activities Technical Planning and Management Planning.
3.1.1.2 Technical Planning
3.1.1.2.1 Selection of Development Method
During this activity, selection of the development method is done. This process involves consideration of project requirements and technical requirements.
3.1.1.2.2 Selection of Design Method
Selection of design method is done during this activity. This process also involves project and technology considerations, as well as the personnel and company considerations.
3.1.1.2.3 Design Method Training
For every selected design method it is determined if enough trained personnel are available to carry out the design activity. If there are not enough people, training is provided to the personnel working on the project.
3.1.1.2.4 Selection of CASE Tool
In order to utilize CASE tools in a project, a study is done during this activity to select one or more CASE tools for the project. However, in some projects, there may not be any CASE tools used or a CASE tool may already have been selected.
3.1.1.2.5 Project Level Prototyping
During this activity, an overall prototype is developed for the whole project. This prototype can be useful in understanding the scope of the project and the product under development.
3.1.1.3 Management Planning
3.1.1.3.1 Software Cost Estimation
During this activity, the cost of the software product is estimated. Different techniques to estimate the cost of the software product are used and compared.
3.1.1.3.2 Software Size Estimation
During this activity, the size of the software product is estimated. Different techniques to estimate the size of the software product are used and compared.
3.1.1.3.3 Critical Computer Resources Estimation
During this activity, the critical computer resources for the development environment are estimated in this activity. Project and product requirements play a significant role in determining these resources.
3.1.1.3.4 Software Schedule Planning
Planning the software schedule is also an important activity. It takes the software size estimate as input.
3.1.1.3.5 Preparing SQA Plan
A software quality assurance (SQA) plan is prepared during this activity. An SQA plan is necessary to help ensure a high quality of the software product.
3.1.1.3.6 Preparing SCM Plan
A software configuration management (SCM) plan is prepared during this activity. This plan is necessary to keep track of different versions of a product, both code and documentation.
3.1.1.3.7 Establishing CM Library
A configuration management (CM) library is established during this activity. The CM library is used to store all work products of the project.
3.1.1.3.8 Life Cycle Selection
During this activity, a software life cycle is selected for the project based on the characteristics of the project and the environment.
3.1.1.3.9 Definition of Project Commitments
During this activity, definitions of project commitments are made and stored for future reference.
3.1.1.3.10 Project Facilities and Support Tools
During this activity, project facilities and support tools are identified for the project.
3.1.1.3.11 Identification of SCM Work Products
During this activity, software configuration management (SCM) work products (WPs) are identified. These work products will be stored in the CM library.
3.1.1.4 Planning Subcontract Management
During this activity, planning for subcontract management is done.
3.1.1.5 Project Plan Peer Review
During this activity, peer review for the project plan is performed.
3.1.1.6 Integrated Software Management Planning
3.1.1.6.1 Scheduling and Planning
During this activity, technical activities are identified and defined, and methods, practices, or tools to be used to complete each task are specified. The output of this activity is a SW Development Schedule and Plan and is sent to Software Development Planning activity.
3.1.1.6.2 Developing Training Plan
A training plan is developed during this activity according to the organization's documented procedure.
3.1.1.6.3 Planning to Manage Size of Work Products
Planning to manage size of Work Products is done during this activity.
3.1.1.6.4 Planning to Manage Cost & Effort
During this activity, planning for cost and effort management is done.
3.1.1.6.5 Planning to Manage Critical Computer Resources
During this activity, planning to manage critical computer resources is done.
3.1.1.6.6 Planning to Manage Critical Paths & Dependencies
During this activity, planning to manage critical paths and dependencies is done.
3.1.1.6.7 Planning to Identify Critical Engineering Dependencies
During this activity, planning to identify critical engineering dependencies is done.
3.1.1.6.8 Planning Peer Review Management
Planning for peer review management is done in this activity.
3.1.1.6.9 Commitment To Planning
In this activity, cycle plan is approved and thus, a commitment to the planning is made.
3.1.2 Requirements Analysis and Specification Cycle
3.1.2.1 Requirements Analysis and Specification
During this activity, the requirements of the product are analyzed and a comprehensive requirements specifications is prepared. This is a kernel activity in the cycle.
3.1.2.2 Requirements Prototyping
During this activity, a requirements prototype may be developed if needed. A requirements prototype helps in understanding the scope of the product. A software requirements specification (SRS) document is produced during this activity.
3.1.2.3 Software Requirements Review
During this activity, the customer software requirements are reviewed. This activity is performed before requirements are specified in the software requirements specification (SRS) document.
3.1.2.4 Requirements Specification Peer Review
During this activity, peer review for the requirements specification is performed.
3.1.3 Preliminary Design Cycle
3.1.3.1 Architectural Design
This is the main activity in performing the architectural design for the product. It uses the design method selected previously to develop the architectural design for the product. An architectural design document is produced as a result of this activity.
3.1.3.2 Design Prototyping
A design prototype may be developed during this activity if needed. Design prototypes are used to improve understanding of design issues related to the product under development.
3.1.3.3 Design Performance Analysis
During this activity, a performance analysis of the architectural design is done. The performance requirements defined in the requirements specification are used as criteria for this analysis.
3.1.3.4 Local Design Tailoring
During this activity, the architectural design is tailored to interface to any local software products or to meet local hardware constraints.
3.1.3.5 Architectural Design Peer Review
During this activity, peer review for the architectural design specification is performed.
3.1.4 Construction and Test Cycle
3.1.4.1 Detailed Design
This is the activity for performing detailed design of individual modules in the product under development.
3.1.4.2 Preparation of Enhanced Documentation
During this activity, enhanced software documentation is performed. This
is normally in cases where the software product is expected to have a long
life cycle and undergo many future changes.
3.1.4.3 Select or Adapt Reusable Components
During this activity, already existing reusable components are selected as is or with modifications. These reusable components are stored in a reusable library.
3.1.4.4 Detailed Design Peer Review
During this activity, peer review for the detailed design specification is performed.
3.1.4.5 Unit Coding
This is the activity for actual implementation of individual components in the product under development. The development method selected previously is used to carry out the development process.
3.1.4.6 Code Unit Peer Review
During this activity, peer review for individual code units is performed.
3.1.4.7 Unit Testing
This is the activity for testing individual code units.
3.1.4.8 Unit Testing Peer Review
During this activity, peer review for individual tested units is performed.
3.1.4.9 Integration Testing
During this activity, integration testing of the modules developed previously is performed. Modules are combined into subsystems and gradually tested.
3.1.4.10 Integration Testing Peer Review
During this activity, peer review for the system integration testing is performed.
3.1.5 System Testing Cycle
3.1.5.1 System and Acceptance Testing
During this activity, system and acceptance testing for the newly developed product is done.
3.1.5.2 Performance Testing
During this activity, the performance of the newly developed product is tested. The performance of the system is tested against the performance requirements defined in the requirements specification.
3.1.5.3 System and Acceptance Testing Peer Review
During this activity, peer review for system and acceptance testing is performed.
3.1.5.4 Performance Testing Peer Review
During this activity, peer review for performance testing is performed.
3.2 Monitoring and Reviewing
3.2.1 Monitoring and Reviewing Product
This activity captures and analyzes the status of the cycle to provide management with insight into the cost, schedule, and technical performance status of the cycle.
3.2.2 Analyzing Defect Data
During this activity, defect data is analyzed.
3.3 Reviewing Technical Product
During this activity, stake holders review the product or part of the product developed to ensure that cycle objectives and success criteria were met. Stake holders approve the developed product or part of product and also a configuration id is issued to the approved product.
4. Spiral Planning
4.1 Product Change Control
A product baseline is produced during this activity for the product developed in the previous step of this cycle. Also changes in the configuration status of the product are also tracked during this activity.
4.2 Reviewing Progress
4.2.1 Project Progress Review
During this activity, the overall project progress is monitored and tracked.
4.2.2 Software Schedules Review
During this activity, the software schedule is monitored and reviewed. Any proposed changes to the schedule are reviewed and approved.
4.2.3 SQA Audit of Work Products
During this activity, an audit of the work products is done against the criteria defined in the software quality assurance (SQA) plan.
4.2.4 SW Effort and Cost Review
During this activity, the software effort and cost is reviewed and monitored. Any changes to the original plan are reviewed and approved.
4.2.5 Critical Computer Resources Review
During this activity, the usage of critical computer resources is reviewed.
4.2.6 Project Commitments Review
During this activity, project commitments are reviewed and updated accordingly.
4.2.7 Work Product Size Review
During this activity, the size of the work products is reviewed and monitored.
4.2.8 Tracking Subcontract Progress
During this activity, progress of subcontracts is tracked.
4.2.9 Project Risks Review
During this activity, project risks are reviewed.
4.2.10 Tracking Critical Engineering Dependencies
During this activity, critical engineering dependencies are tracked.
4.2.11 Tracking Peer Reviews
During this activity, peer reviews are tracked.
4.3 Updating Spiral Planning Documents
4.3.1 Planning for Requirements Cycle
During this activity, planning for the requirements cycle is done.
4.3.2 Planning for Architectural Design Cycle
During this activity, planning for the architectural design cycle is done.
4.3.3 Planning for Construction and Test Cycle
During this activity, planning for the construction and test cycle is done.
4.3.4 Planning for Evolutionary Development
During this activity, planning for Evolutionary development is done. This is an optional activity, which is only performed if an evolutionary development approach is being used.
4.3.5 Planning for Incremental Development
During this activity, planning for Incremental development is done. This is an optional activity, which is only performed if an incremental development approach is being used.
4.3.6 Revising Training Plan
During this activity, training plan is revised.
4.3.7 Planning for System Testing Cycle
During this activity, planning for the system testing cycle is done.
6. Conclusions
This report has described the application of the domain modeling method to the Spiral Process Model. A domain model of a spiral model has been developed. The domain model incorporates the level 2 and level 3 key process areas of the Software Engineering Institute's Capability Maturity Model. The domain model of the spiral model is described together with the risk-related process drivers, the CMM level 2 and level 3 process drivers.
7. Acknowledgments
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, and the contributions of F. Carr and J. Yoon in its application to process modeling. The domain modeling research and development of the Knowledge Based Software Engineering Environment was sponsored primarily by NASA Goddard Space Flight Center with additional support from the Virginia Center of Innovative Technology. Portions of the work were sponsored by an ARPA grant, administered by the Office of Naval Research under grant number N0001492J4038. 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 Software Through Pictures CASE tool was donated to GMU by Interactive Development Environments, Inc.
8. 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
Table 1: Risk-Related Process Drivers and Supporting Activities
Process Driver |
Supported By |
Node |
| Need for project level prototyping | Project Level Prototyping | 3.1.1.2.5 |
| Lack of development method | Selection of Development Method | 3.1.1.2.1 |
| Need for CASE tool | Selection of CASE Tool | 3.1.1.2.4 |
| Throw away prototyping | Requirements Prototyping | 3.1.2.2 |
| Evolutionary development | Requirements Prototyping Planning for Evolutionary Development OOD Method Selection |
3.1.2.2 4.3.4 3.1.1.2.2v |
| Operational life cycle | Planning for Incremental Development Planning for Evolutionary Development OOD Method Selection |
4.3.5 4.3.4 3.1.1.2.2v |
| Performance requirements | Design Performance Analysis Design Prototyping Performance Testing Performance Testing Peer Review |
3.1.3.3 3.1.3.2 3.1.5.2 3.1.5.4 |
| Maintenance/support requirements | Requirements Prototyping Preparation of Enhanced Documentation |
3.1.2.2 3.1.4.2 |
| Complex system interfaces | Design Prototyping | 3.1.3.2 |
| Incremental development | Requirements Prototyping Planning for Incremental Development Planning for Evolutionary Development |
3.1.2.2 4.3.5 4.3.4 |
| Phasing | Planning for Incremental Development | 3.3.5 |
| Real time system | RT Design Method Selection | 3.1.1.2.2v |
| Design method need | Selection of Design Method | 3.1.1.2.2 |
| Design method training need | Design Method Training | 3.1.1.2.3 |
| Existing hardware/software constraint | Local Design Tailoring | 3.1.3.4 |
| Reuse library exists | Select or Adapt Reusable Components | 3.1.4.3 |
| Spiral process | 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 |
1 2 3.1.1.6.1 3.1.1.6.9 3.2.1 4.1 4.2.1 4.3.1 4.3.2 4.3.3 4.3.7 |
Table 2: Risk-Related Process Driver Relationships
Driver/Driver dependencies |
Requires |
| Real time system | Performance requirements |
| Design method need | Design method training need |
| Lack of development method | Design method need |
Table 3: CMM Related Process Drivers and Supporting Activities
Process Driver |
Supported By |
Node |
| CMM Level 2 | ||
| Requirements management | Software Requirements Review | 3.1.2.3 |
| Software project planning | Software Cost Estimation Software Size Estimation Critical Computer Resources Estimation Software Schedule Planning Life Cycle Selection Definition of Project Commitments Planning Project Facilities & Support Tools |
3.1.1.3.1 3.1.1.3.2 3.1.1.3.3 3.1.1.3.4 3.1.1.3.8 3.1.1.3.9 3.1.1.3.10 |
| Software tracking and oversight | Project Progress Review Software Schedules Review SW Effort and Cost Review Critical Computer Resources Review Project Commitments Review Work Product Size Review |
4.2.1 4.2.2 4.2.4 4.2.5 4.2.6 4.2.7 |
| Software subcontract management | Planning Subcontract Management Project Progress Review Tracking Subcontract Progress |
3.1.1.4 4.2.1 4.2.8 |
| Software quality assurance | Preparing SQA Plan Project Progress Review SQA Audit of Work Products |
3.1.1.3.5 4.2.1 4.2.3 |
| Software configuration management | Preparing SCM Plan Establishing CM Library Identification of SCM Work Products |
3.1.1.3.6 3.1.1.3.7 3.1.1.3.11 |
| CMM Level 3 | ||
| Training program | Scheduling and Planning Developing Training Plan Revising Training Plan |
3.1.1.6.1 3.1.1.6.2 4.3.6 |
| Integrated software management | Scheduling and Planning Planning to Manage Size of Work Products Planning to Manage Cost & Effort Planning to Manage Critical Computer Resources Planning to Manage Critical Paths & Dependencies Project Progress Review Project Risks Review |
3.1.1.6.1 3.1.1.6.3 3.1.1.6.4 3.1.1.6.5 3.1.1.6.6 4.2.1 4.2.9 |
| Software product engineering | Monitoring and Reviewing Product Analyzing Defect Data Preparation of Enhanced Documentation |
3.2.1 3.2.2 3.1.4.2 |
| Intergroup coordination | Scheduling and Planning Planning to Identify Critical Engineering Dependencies Project Progress Review Tracking Critical Engineering Dependencies |
3.1.1.6.1 3.1.1.6.7 4.2.1 4.2.10 |
| Peer reviews | Scheduling and Planning Planning Peer Review Management Project Plan Peer Review Requirements Specification Peer Review Architectural Design Peer Review Detailed Design Peer Review Code Unit Peer Review Unit Testing Peer Review Integration Testing Peer Review System and Acceptance Testing Peer Review Project Progress Review Tracking Peer Reviews |
3.1.1.6.1 3.1.1.6.8 3.1.1.5 3.1.2.4 3.1.3.5 3.1.4.4 3.1.4.6 3.1.4.8 3.1.4.10 3.1.5.3 4.2.1 4.2.11 |
Table 4: CMM-Related Process Driver Relationships
Driver/Driver dependencies |
Requires |
| CMM level 2 | Requirements management Software project planning Software tracking and oversight Software subcontract management Software quality assurance Software configuration management |
| CMM level 3 | Training program Integrated software management Software product engineering Intergroup coordination Peer reviews CMM level 2 |
Table 5: CMM Activities Supported by SPM
Requirements Management KPA |
||||
| Activity No | Supported By | Node | SPM? | K/O |
| Activity 1 | Software Requirements Review | 3.1.2.3 | O | |
| Activity 2 | Requirements Analysis and Specification | 3.1.2.1 | SPM | K |
| Activity 3 | Requirements Prototyping | 3.1.2.2 | SPM | O |
Software Project Planning KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Software Requirements Review | 3.1.2.3 | O | |
| Activity 2 | Planning for Requirements Cycle | 4.3.1 | SPM | O |
| Activity 3 | Software Requirements Review | 3.1.2.3 | O | |
| Activity 4 | Commitment To Planning Software Development Planning |
3.1.1.6.9 3.1.1.1 |
SPM SPM |
O K |
| Activity 5 | Life Cycle Selection | 3.1.1.3.8 | SPM | O |
| Activity 6 | Software Development Planning | 3.1.1.1 | SPM | K |
| Activity 7 | Software Development Planning | 3.1.1.1 | SPM | K |
| Activity 8 | Definition of Project Commitments | 3.1.1.3.9 | O | |
| Activity 9 | Software Size Estimation | 3.1.1.3.2 | O | |
| Activity 10 | Software Cost Estimation Software Size Estimation |
3.1.1.3.1 3.1.1.3.2 |
O O | |
| Activity 11 | Critical Computer Resources Estimation | 3.1.1.3.3 | O | |
| Activity 12 | Software Schedule Planning | 3.1.1.3.4 | O | |
| Activity 13 | Software Cost Estimation Software Size Estimation Software Schedule Planning |
3.1.1.3.1 3.1.1.3.2 3.1.1.3.4 |
O O O | |
| Activity 14 | Planning Project Facilities and Support Tools | 3.1.1.3.10 | O | |
| Activity 15 | Software Development Planning | 3.1.1.1 | SPM | K |
Software Project Tracking and Oversight KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 2 | Planning for Requirements Cycle Planning for Architectural Design Cycle Planning for Construction and Test Cycle Planning for System Testing Cycle |
4.3.1 4.3.2 4.3.3 4.3.7 |
SPM SPM SPM SPM |
O O O O |
| Activity 3 | Reviewing Technical Product | 3.3 | SPM | K |
| Activity 4 | Project Commitments Review | 4.2.6 | SPM | O |
| Activity 5 | Work Product Size Review | 4.2.7 | SPM | O |
| Activity 6 | SW Effort and Cost Review | 4.2.4 | SPM | O |
| Activity 7 | Critical Computer Resources Review | 4.2.5 | SPM | O |
| Activity 8 | Software Schedules Review | 4.2.2 | SPM | O |
| Activity 9 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 10 | Project Risks Review | 4.2.9 | SPM | O |
| Activity 11 | Monitoring and Reviewing Product | 3.2.1 | SPM | O |
| Activity 12 | Monitoring and Reviewing Product | 3.2.1 | SPM | O |
| Activity 13 | Reviewing Technical Product | 3.3 | SPM | K |
Software Subcontract Management KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Planning Subcontract Management | 3.1.1.4 | O | |
| Activity 2 | Planning Subcontract Management | 3.1.1.4 | O | |
| Activity 3 | Planning Subcontract Management | 3.1.1.4 | O | |
| Activity 4 | Planning Subcontract Management | 3.1.1.4 | O | |
| Activity 5 | Planning Subcontract Management | 3.1.1.4 | O | |
| Activity 6 | Planning Subcontract Management | 3.1.1.4 | O | |
| Activity 7 | Tracking Subcontract Progress | 4.2.8 | O | |
| Activity 8 | Tracking Subcontract Progress | 4.2.8 | O | |
| Activity 9 | Reviewing Technical Product | 3.3 | SPM | K |
| Activity 10 | Tracking Subcontract Progress | 4.2.8 | O | |
| Activity 11 | Tracking Subcontract Progress | 4.2.8 | O | |
| Activity 12 | Reviewing Technical Product System and Acceptance Testing |
3.3 3.1.5.1 |
SPM SPM |
K K |
| Activity 13 | Tracking Subcontract Progress | 4.2.8 | O |
Software Quality Assurance KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Preparing SQA Plan | 3.1.1.3.5 | O | |
| Activity 2 | Preparing SQA Plan | 3.1.1.3.5 | O | |
| Activity 3 | Software Development Planning | 3.1.1.1 | SPM | K |
| Activity 4 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 5 | SQA Audit of Work Products | 4.2.3 | O | |
| Activity 6 | SQA Audit of Work Products | 4.2.3 | O | |
| Activity 7 | SQA Audit of Work Products | 4.2.3 | O | |
| Activity 8 | SQA Audit of Work Products | 4.2.3 | O | |
Software Configuration Management KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Preparing SCM Plan | 3.1.1.3.6 | O | |
| Activity 2 | Preparing SCM Plan | 3.1.1.3.6 | O | |
| Activity 3 | Establishing CM Library | 3.1.1.3.7 | O | |
| Activity 4 | Identification of SCM Work Products | 3.1.1.3.11 | O | |
| Activity 5 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 6 | Product Change Control | 4.1 | SPM | O |
| Activity 7 | Product Change Control | 4.1 | SPM | O |
| Activity 8 | Project Progress Review SQA Audit of Work Products |
4.2.1 4.2.3 |
SPM | O O |
| Activity 9 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 10 | SQA Audit of Work Products | 4.2.3 | O | |
Training Program KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Developing Training Plan | 3.1.1.6.2 | O | |
| Activity 2 | Revising Training Plan | 4.3.6 | O | |
| Activity 3 | Design Method Training | 3.1.1.2.3 | SPM | O |
| Activity 4 | Scheduling and Planning | 3.1.1.6.1 | SPM | O |
| Activity 5 | Design Method Training | 3.1.1.2.3 | SPM | O |
| Activity 6 | Revising Training Plan | 4.3.6 | O |
Integrated Software Management KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Scheduling and Planning | 3.1.1.6.1 | SPM | O |
| Activity 2 | Life Cycle Selection | 3.1.1.3.8 | SPM | O |
| Activity 3 | Software Development Planning | 3.1.1.1 | SPM | K |
| Activity 4 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 5 | Software Development Planning Software Size Estimation |
3.1.1.1 3.1.1.3.2 |
K O | |
| Activity 6 | Planning to Manage Size of Work Products | 3.1.1.6.3 | O | |
| Activity 7 | Planning to Manage Cost & Effort | 3.1.1.6.4 | O | |
| Activity 8 | Planning to Manage Critical Computer Resources | 3.1.1.6.5 | O | |
| Activity 9 | Planning to Manage Critical Paths & Dependencies | 3.1.1.6.6 | O | |
| Activity 10 | Performing Risk Analysis Reviewing Risk Analysis Planning Risk Aversion Strategy Resolving Risks |
2.1 2.1 2.3 2.4 |
SPM SPM SPM SPM |
O O O O |
| Activity 11 | Project Risks Review | 4.2.9 | O |
Software Product Engineering KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Software Development Planning | 3.1.1.1 | SPM | K |
| Activity 2 | Requirements Analysis and Specification | 3.1.2.1 | SPM | K |
| Activity 3 | Architectural Design | 3.1.3.1 | SPM | K |
| Activity 4 | Detailed Design Unit Coding |
3.1.4.1 3.1.4.5 |
SPM SPM |
K K |
| Activity 5 | Unit Testing | 3.1.4.7 | SPM | K |
| Activity 6 | Integration Testing | 3.1.4.9 | SPM | K |
| Activity 7 | System and Acceptance Testing | 3.1.5.1 | SPM | K |
| Activity 8 | Software Development Planning Requirements Analysis and Specification Architectural Design Detailed Design Preparation of Enhanced Documentation Unit Coding Unit Testing Integration Testing System and Acceptance Testing |
3.1.1.1 3.1.2.1 3.1.3.1 3.1.4.1 3.1.4.2 3.1.4.5 3.1.4.7 3.1.4.9 3.1.5.1 |
SPM SPM SPM SPM SPM SPM SPM SPM SPM |
K K K K O K K K K |
| Activity 9 | Analyzing Defect Data | 3.2.2 | O | |
| Activity 10 | Reviewing Technical Product | 3.3 | SPM | K |
Intergroup Coordination KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Defining Approach Developing and Updating EoS Reviewing Context |
1.1 1.2 1.3 |
SPM SPM SPM |
O O O |
| Activity 2 | Monitoring and Reviewing Product | 3.2.1 | SPM | O |
| Activity 3 | Commitment To Planning | 3.1.1.6.9 | SPM | O |
| Activity 4 | Tracking Critical Engineering Dependencies | 4.2.10 | O | |
| Activity 5 | Project Progress Review | 4.2.1 | SPM | O |
| Activity 6 | Project Commitments Review Reviewing Technical Product |
4.2.6 3.3 |
SPM |
O K |
| Activity 7 | Project Progress Review | 4.2.1 | SPM | O |
Peer Reviews KPA |
||||
Activity No |
Supported By |
Node |
SPM? |
K/O |
| Activity 1 | Scheduling and Planning Planning Peer Review Management |
3.1.1.6.1 3.1.1.6.8 |
SPM | O O |
| Activity 2 | Project Plan Peer Review Requirements Specification Peer Review Architectural Design Peer Review Detailed Design Peer Review Code Unit Peer Review Unit Testing Peer Review Integration Testing Peer Review System and Acceptance Testing Peer Review |
3.1.1.5 3.1.2.4 3.1.3.5 3.1.4.4 3.1.4.6 3.1.4.8 3.1.4.10 3.1.5.3 |
O O O O O O O O | |
| Activity 3 | Project Progress Review Tracking Peer Reviews |
4.2.1 4.2.11 |
SPM | O O |