Domain Modeling of Software Process Models
Hassan Gomaa, Larry Kerschberg, and Ghulam A. Farrukh
George Mason University and The MITRE Corporation
hgomaa@gmu.edu, kersch@gmu.edu, and farrukh@mitre.org
Abstract
This paper presents a novel application involving
two important Software Engineering research areas:
process modeling and software reuse. The Spiral Model
is a risk-driven process model, which, depending on the
specific risks associated with a given project, may be
tailored to create a project-specific process model. The
software reuse area is that of domain modeling of
families of systems, which capture the similarities and
variations among the members of the family. The
domain modeling approach is used to create a domain
model of a Spiral Process Model (SPM), thereby
capturing the similarities and variations among a family
of process models. The SPM domain model has been
extended to capture the key process areas of the
Software Engineering Institute’s Capability Maturity
Model. The domain model is used to generate projectspecific process models.
This approach allows
managers to configure and reuse process models that
manage the risks associated with new software
development.
Keywords. Domain modeling, spiral process model,
process model reuse, knowledge-based software reuse.
1. Introduction
A software reuse area of growing importance is that
of domain modeling of families of systems (also
referred to as software product lines), where an
application domain is modeled by analyzing the
common and variant aspects of the family. This concept
has been investigated by several researchers and
practitioners [Batory92, Bosch99, Coplien98, Cuka98,
DeBaud99, Dionisi98, Kang90].
At George Mason University, a reuse-oriented
software lifecycle, the Evolutionary Domain Lifecycle
[Gomaa93], has been proposed, which is a highly
iterative lifecycle that takes an application-domain
perspective allowing the development of families of
systems [Parnas79]. A domain modeling method
[Gomaa95], which captures the similarities and
variations of the domain, and a proof-of-concept
prototype, the Knowledge-Based Software Engineering
Environment [Gomaa96] have also been developed.
Complex systems need a well-regulated software
process, which is flexible enough to be tailored to the
specific needs of the project. This paper describes the
application of the domain modeling method to process
modeling. In particular, it presents a domain model of
the Spiral Process Model [Boehm88], which is extended
to incorporate the key process areas of the Software
Engineering Institute’s Capability Maturity Model
(CMM). The domain model is for a family of software
process models, which can be tailored to generate a
process model for a specific project, given the project
drivers, which are the project specific risks.
Section 2 of this paper summarizes the domain
modeling method. Section 3 gives a brief overview of
the Spiral Process Model and the Capability Maturity
Model. Section 4 describes how the domain modeling
method can be applied to create a domain model of the
family of software process models. Section 5 describes
the domain model for the spiral model, with the addition
of the key process areas for CMM levels 2 and 3.
Section 6 describes how the prototype Knowledge
Based Software Engineering Environment was applied
to the process-modeling domain.
2. Domain modeling method
2.1. Domain modeling
A Domain Model is an analysis model for the
application domain that reflects the similarities and
variations of the members of the domain. Given a
domain model of an application domain, an individual
target system (one of the members of the family) is
created by tailoring the domain model given the
requirements of the individual system (Fig.1).
In a domain model, an application domain is
represented by means of multiple views, such that each
view presents a different aspect of the domain
[Gomaa95]. Four of the five views, the Aggregation
Hierarchy,
Object
Communication
Diagrams,
Generalization/Specialization Hierarchy, and Feature
/Object dependencies are described here, since they are
most relevant to this research. The fifth view, the State
Transition Diagram is not presented herein.
Domain
Requirements
Reusable
Specification
Domain
Modeling
Domain Reuse
Library
Target System
Requirements
Target
Target System System
Generation
Unsatisfied Requirements, Errors, Adaptation
Figure 1: Domain modeling for a family of systems
Aggregation Hierarchy. The Aggregation Hierarchy
is used to decompose complex aggregate object types
into less complex object types eventually leading to
simple object types at the leaves of the hierarchy.
Object types are either kernel, i.e., required in every
target system, or optional, i.e., only required in some
target systems. The Aggregation Hierarchy supports the
IS-PART-OF relationship linking object types to their
aggregate type.
Object communication diagrams. Objects in the
real world are modeled as concurrent tasks, which
communicate with each other using messages. Dynamic
relationships between objects, in the form of messages
passed between objects, are shown by means of object
communication diagrams. Objects types are either
kernel, i.e., required in every target system, or optional,
i.e., only required in some target systems.
Generalization/Specialization Hierarchy. As the
requirements of a given object type are changed to meet
the specific needs of a target system, the object type
may be specialized by adding or modifying operations.
In our domain modeling approach, the variants of a
domain object type are stored in a Generalization /
Specialization Hierarchy (GSH), which supports the ISA relationship linking subtypes to their supertype.
Feature/Object dependencies. A feature represents
one or more domain requirements, and this feature
analysis becomes an important aspect of domain
analysis [Cohen98, Dionisi98, Griss98, Kang90]. This
view relates the end-user’s perspective of the
application domain, namely the features supported by
the application domain, to the object types within the
domain model. Also defined are required prerequisite
features and any mutually exclusive features. This view
is particularly important for optional features, since it is
the selection of the optional features and their
supporting object types, that determines the structure of
the desired target system.
Rules for consistency checking between the multiple
views have been defined. These are enforced by the
domain modeling environment described in Section 5.
The domain modeling method is similar to other
object-oriented methods when used for analyzing and
modeling a single system [Booch94, Booch98,
Coleman94, Jacobson92, Rumbaugh91]. Its novelty is
the way it extends object-oriented methods to model
families of systems, in which the similarities and
variations in a family are explicitly modeled.
2.2. Target system specification generation
A Target System Specification is a problem-oriented
architecture for an individual target system, i.e., a
member of the family of systems that constitute the
domain. It is a tailored instance of the domain model.
Requirements’ reuse is achieved by selecting features
for a target system. The domain model is then tailored
to generate the target system specification, subject to the
appropriate feature-object dependency constraints. This
step is greatly assisted by automated support as
described in Section 5.
3. Process models and the CMM
3.1. Problems with software process models
Software process models provide explicit models of
the software development process. The earliest process
model was a phased approach to software development
referred to as the Waterfall Model [Boehm76]. Several
problems have been identified with the waterfall model
of software development [Agresti86]:
a) Software requirements, a key factor in any
software development, are not properly tested until a
working system is available to demonstrate to the endusers. These problems are compounded by the fact that
studies have shown that changes in requirements to a
delivered system are usually the most costly to correct
[Boehm76]. Prototyping [Agresti86, Gomaa97] and
operational specifications [Agresti86, Zave84] are two
approaches that have been used to help address this
problem. However these approaches are typically only
used to develop new systems and are less frequently
used in software reuse and evolution.
b) Difficulty in managing system evolution.
Requirements are assumed to be stable when they are
actually dynamic and evolutionary.
Thus a
requirements specification may correctly reflect the
user’s needs at the time of its “completion”. However,
by the time the system is delivered, evolutionary
changes in the operational environment often result in
the system no longer meeting user requirements.
Incremental development approaches [Agresti86,
Gomaa97] have been used to help address this problem.
However, managing system evolution remains a major
technological challenge [Lubars92].
Various approaches have been suggested to
providing reusable software process models, where the
software process can be adapted to the needs of the
project. Process reuse has been described as the “usage
of one process description in the creation of another
process description” [Frakes96]. Another approach to
reuse software processes has involved using the answers
to a series of questions to tailor a software process
[Henninger98].
3.2. The spiral model
The Spiral Model takes a different approach to
software process reuse. The Spiral Model is a riskdriven process model originally developed by Boehm
[Boehm88] to address known problems with earlier
process models of the software life cycle, in particular
the Waterfall Model. In the spiral model (Fig. 2), the
radial coordinate represents cost and the angular
coordinate represents progress in completion of a cycle
of the model. Each cycle involves traversing through
the four quadrants. The first quadrant is to determine
objectives, alternatives, and constraints for the cycle.
The second quadrant is a risk analysis and evaluation of
alternatives for the cycle. The third quadrant is to
develop and verify the next level product. The fourth
quadrant involves planning for the next phases.
Each cycle of the spiral model iterates through
these four quadrants. The number of cycles is projectspecific, so the description of the activities in each
quadrant is intended to be general enough so that they
can be included in any cycle.
The goal of the spiral model is that the software
process be risk driven, so that the risks within a given
cycle are determined during the Analyze Risks
quadrant. In order to manage these risks, certain
additional project-specific activities may be planned to
address the risks, such as Requirements Prototyping, if
the risk analysis indicates that the software requirements
are not clearly understood. These project-specific risks
are termed process drivers. For any process driver, one
or more project-specific activities must be performed to
manage the risk.
1. Define Objectives,
Alternatives, and Constraints
4. Plan Next Cycle
2. Analyze Risks
3. Develop Product
Figure 2: The spiral process model
The Spiral Model is intended to encompass other life
cycle models such as the Waterfall Model, the
Incremental Development model, and the Throwaway
Prototyping Model. During Risk Analysis, the key
characteristics of the project are determined, referred to
as process drivers. An example of a process driver is
“Low understanding of Requirements”. The process
drivers (comparable to features described in Section
2.1), are used to determine which process model is most
appropriate for the project. In this way, the Spiral Model
can be considered a process model generation
framework [Boehm89].
3.3. The capability maturity model
The Capability Maturity Model, developed at the
Software Engineering Institute [CMM95], is a software
process maturity framework to help organizations
improve their software process. Software process
maturity [Humphrey89] is defined as the extent to
which an organizational software process is explicitly
defined, managed, controlled, and effective. According
to CMM, there are five levels of software process
maturity: Initial, Repeatable, Defined, Managed, and
Optimized. This research concentrates on achieving
levels two and three.
Each maturity level consists of several key process
areas. Each key process area defines “what should be
done” to achieve that level, although the “how” is left to
organizations to select the practices they consider most
appropriate for their business.
The level 2 key process areas are requirements
management, software project planning, software
project tracking and oversight, software subcontract
management, software quality assurance, and software
configuration management.
Thus, an organization
operating at CMM level 2 must have policies and
procedures in place for these six key process areas. It is
to be noted that an organization cannot claim to be
operating at any CMM level unless (SEI approved)
independent assessors have certified it. However, many
organizations have initiated internal assessment
programs, which are less expensive than the SEI
certifications. These assessments provide the first
impetus for organizations to improve their software
development processes, and get certification from SEI
approved assessors. One of the authors, in a previous
position, was responsible for developing policies and
procedures to attain CMM level 2 certification.
The level 3 key process areas are training program,
integrated software management, software product
engineering, intergroup coordination, and peer reviews.
An organization can operate at level 3 if it is already
operating at CMM level 2 and have policies and
procedures in place for these five key process areas.
4. Domain modeling of the SPM
4.1. Introduction
As the Spiral Model encompasses several process
models, an intriguing problem is to what extent the
domain-modeling concept can be applied to the family
of process models. In particular, a domain model of the
Spiral Process Model (SPM) could be developed to
encompass other process models. This domain model
can be specifically tailored for a project by selecting
appropriate process drivers. In addition to the Spiral
Process Model, this domain model incorporates the key
process areas of levels 2 and 3 of the Capability
Maturity Model.
Before beginning the domain modeling effort, two
important decisions were made. First an object in the
domain model would be used to represent an activity in
the spiral model, and second a feature in the domain
model would be used to represent a process driver in the
spiral model.
In developing the SPM domain model, another
important issue is how to represent the cycles and
quadrants of the spiral model. Since an object in the
domain model is used to represent an activity in the
spiral model, an aggregate object may be used to
represent an aggregate activity, i.e., a composition of
several activities. The approach adopted is to model the
four quadrants of the spiral model as four aggregate
activities in the domain model. Each of these aggregate
activities is decomposed further. The first two levels of
decomposition represent activities performed in each
cycle. Beyond that, at the third level of decomposition,
additional cycle-specific activities are depicted, the
concept being that these activities are performed when
the appropriate cycle is activated.
4.2. An SPM domain model
The domain model of the SPM consists of the
Aggregation Hierarchy, Object Communication
Diagrams, Generalization / Specialization Hierarchy,
and Feature/Object Dependencies.
4.2.1. Aggregation Hierarchy.
The aggregation
hierarchy of the Spiral Process Model is shown in Fig.
3. This view captures the “is-part-of” relationship
among activities in the domain model. Fig. 3 shows
three levels of decomposition in the SPM domain
model. Each activity is shown as a box. An activity has
two properties, the first is whether it is kernel (K) or
optional (O), the second is whether it is aggregate (A) or
simple (S).
The first level of decomposition captures the four
quadrants of the Spiral Process Model. It is important to
note that three of these aggregate quadrant activities are
modeled as optional, while only one (Developing and
Verifying Product) is modeled as kernel. The reason for
this is that kernel of the SPM domain model, consisting
only of the kernel objects, constitutes the Waterfall
model. This means that a project considered low risk
could follow the waterfall life cycle.
Only the
Developing and Verifying Product aggregate activity is
needed for the Waterfall model, while other activities
are required for other variants of the domain model.
The second level of decomposition in Fig. 3 is
limited to the Developing and Verifying Product
aggregate activity. This activity has been further
decomposed into five activities, all of which are kernel
specific project needs as determined by the process
drivers.
The aggregation hierarchy, as shown in Fig. 3,
captures an overall view of the domain model of the
spiral process model. This view complements another
view in the domain model, the object communication
diagrams, which are described next.
4.2.2. Object Communication Diagrams. The first
level of decomposition of the spiral model domain
in the domain model. These activities broadly cover all
the technical tasks that must be performed in the
development of a software product, for which a
managed software process is required. In the context of
the spiral process model, each of these activities will be
performed in a different cycle. Any of these activities
can be revisited in a new cycle. This may be necessary
due to a requirements change or to address significant
problems discovered in an earlier cycle. Each of these
Spiral Process
Domain
KA
Defining Objectives,
Alternatives,
and Constraints
OA
Project
Planning
Cycle
KA
Requirements
Analysis and
Specification
KS
Requirements
Prototyping
OS
Analyzing
Risks
OA
Requirements Analysis
and Specification
Cycle
KA
Requirements
Review
OS
Developing and
Verifying Product
KA
Spiral
Planning
OA
Construction
and Test
Cycle
KA
Preliminary
Design
Cycle
KA
Architectural
Design
KS
Design
Prototyping
OS
System
Testing
Cycle
KA
Design
Performance
Analysis
OS
Architectural
Design Review
OS
Local Design
Tailoring
OS
Figure 3: Aggregation Hierarchy for the Spiral Process Model Domain Model
aggregate activities is further decomposed into simple
activities, although Fig. 3 only shows the decomposition
for the Requirements Analysis and Specification Cycle
and the Preliminary Design Cycle, which are described
next. The other aggregate activities at levels 2 and 3 in
Fig. 3 are not decomposed further for reasons of space.
The Requirements Analysis and Specification Cycle
activity is decomposed into three activities:
Requirements Analysis and Specification, Requirements
Prototyping, and Requirements Review. Of these, only
the first activity is kernel. The second and the third
activities are optional and are performed only in those
projects that have specific need for them. For example,
the Requirements Review activity will only be
performed if there is a need for the Requirements
Management process driver (Table 3, see last page).
The Preliminary Design Cycle activity is
decomposed into five activities: Architectural Design,
Design Prototyping, Design Performance Analysis,
Local Design Tailoring, and Architectural Design
Review. Except for the first activity, which is kernel, all
the others are optional and are performed to meet
model is shown as the top level of the Object
Communication Diagrams (OCD). There are four
aggregate objects, one for each of the main quadrants of
the spiral model. These are the Defining Objectives,
Alternatives, and Constraints, Analyzing Risks,
Developing and Verifying Product, and Spiral Planning,
as shown in Fig. 4. Each of these aggregate objects is
Project
Planning
Documents
Supporting
Documents
Estimate
of
Situation
1
Defining
Objectives,
Alternatives,
and Constraints
OA
Updated
Project
Planning
Documents
Supporting
Documents
Meeting
Minutes
Risk
Management
Plan
Project
Planning
Documents
Estimate
of
Situation
2
Analyzing
Risks
OA
Updated
Project
Planning
Documents
Meeting
Minutes
Risk
Management
Plan
Updated
Project
Planning
Documents
Supporting
Documents
Project
Planning
Documents
Updated
Project
Planning
Documents
4
Spiral
Planning
OA
Product
Status
Report
Updated
Project
Planning
Documents
Product
Baselines
3
Developing
and
Verifying
Product
KA
Project
Planning
Documents
Supporting
Documents
Product
Baselines
Product
Status
Report
Figure 4: Top Level OCD for Spiral Process Model
decomposed further to reflect the process activities
defined for each quadrant. In the OCDs, each activity is
depicted as a circle, with the arcs representing
information passed between activities.
In the domain model, there are kernel objects and
optional objects. Kernel objects correspond to activities
that are required in every process model generated from
the spiral model domain model. Optional objects
correspond to activities that are only required in some
generated process models if the specific process driver
the activities relate to is relevant to the project. For
example, on the Requirements Analysis and
Specification Cycle OCD (Fig. 5), Requirements
Analysis and Specification is a kernel object, as it is
activity, Architectural Design, with four optional
activities.
The optional activities are Design
Prototyping, Design Performance Analysis, Local
Design Tailoring, and Architectural Design Review. All
the optional activities interact with the kernel activity
and so there are no inter-dependencies among the
optional activities. The Design Prototyping and Design
Performance Analysis activities are both required if the
Performance Requirements process driver is selected
(Table 1), e.g., for a real-time development project.
4.2.3. Generalization/Specialization Hierarchy. In
this view of the domain model, a kernel or optional
activity type can be specialized to reflect a variation on
an activity that is only carried out in some generated
Risk
Management
3.2.3
Plan
Requirements
Review
OS
3.3.4
Local
Design
Tailoring
OS
Tailored Design
Specifications
Requirements
Specification
Project
Plan
Project Planning
Documents
Review Status
Report
Requirements
Specification
3.2.1
Requirements
Analysis and
Specification
KS
Requirements
Prototype
Product Status
Report
Requirements
Specification
Project Planning
Documents
Design
Performance
Report
3.2.2
Requirements
Prototyping
OS
Trained Staff
Design
Prototype
3.3.2
Design
Prototyping
OS
Preliminary
Architectural
Design Spec
3.3.3
Design
Performance
Analysis
OS
Figure 5: OCD for the Requirements Analysis
and Specification Cycle
assumed that every software project would include this
activity. However, Requirements Prototyping is an
optional object, as this activity is only required if there
is a poor understanding of requirements (a process
driver). Requirements Review is another optional
object, as this activity is only required if there is a need
for Requirements Management (another process driver).
The OCD for the Preliminary Design Cycle is shown
in Fig. 6, which shows the interactions of a kernel
Architectural
Design Spec
3.3.1
Architectural
Design
KS
Preliminary
Architectural
Design Spec
Product Status
Report
Preliminary
Requirements
Specification
Architectural Design
Specification
Architectural
Design Spec
Risk
Management
Plan
3.3.5
Architecture
Design
Review
OS
Review Status
Report
Figure 6: OCD for the Preliminary Design Cycle
process models. An example of specialization is Design
Method Selection. This activity type is specialized to
reflect the different kinds of method selection that can
be carried out, reflecting the characteristics of different
projects. These specialized activity types are Objectoriented Design Method Selection, Ada-based Design
Method Selection, Real-Time Design Method Selection,
and Distributed Design Method Selection (Fig. 7).
Selection of
Design Method
OVS
OO
Design Method
Selection
Ada Based
Design Method
Selection
Real Time
Design Method
Selection
Distributed
Design Method
Selection
Figure 7: Generalization/Specialization for Design
Method Selection
4.2.4. Feature/Object Dependencies. As stated earlier,
features in the domain model are represented as process
drivers in the spiral model. For the feature/object
dependency view of the domain model, all optional
process drivers are mapped to optional and/or variant
activities in the spiral model. These activities and
process drivers include the CMM-related activities and
process drivers. Table 1 shows risk related process
drivers and supporting activities, while Table 3 shows
all CMM related process drivers and supporting
activities.
For example, the process driver “Low
understanding of Requirements” is supported by the
activity “Requirements Prototyping”. This means that if
the requirements are not understood, then the
Requirements Prototyping activity must be carried out
for this project and so is included in the generated
process model for this project. Some process drivers are
supported by more than one activity. For example three
activities, Design Performance Analysis, Design
Prototyping, and Performance Testing support the
process driver “Performance Requirements”.
The domain model of the spiral model has some
feature/feature (or driver/driver) dependencies. Table 2
shows the risk related process driver constraints, while
Table 4 shows CMM related process driver constraints.
For example, the process driver “Real time system”
requires the driver “Performance requirements,” since
every real-time system has performance constraints.
4.2.5. Support for the CMM. The CMM levels 2 and
3 key process areas have been incorporated into the
spiral model domain model by adding optional process
activities corresponding to the levels 2 and 3 key
process areas. Each level 2 key process area has been
modeled as a process driver. Thus a company striving
to reach level 2 of the CMM can select the key process
areas it wishes to incorporate by selecting the
appropriate level 2 process drivers. Table 3 shows the
CMM Related Process Drivers, corresponding to the key
process areas, and supporting process activities.
A company that wishes to incorporate all CMM
Level 2 process activities can select the process driver
package CMM Level 2. This driver package requires
the six process drivers representing the level 2 key
process areas: Requirements management, Software
project planning, Software tracking and oversight,
Software subcontract management, Software quality
assurance, and Software configuration management, as
shown in Table 4.
The level 3 key process areas have also been
modeled as process drivers. Thus a company striving to
reach level 3 of the CMM can select the key process
areas it wishes to incorporate by selecting the
appropriate level 3 process drivers. A company that
wishes to incorporate all CMM Level 3 process
activities can select the process driver package CMM
Level 3. This driver package requires all six process
drivers representing the six key process areas of CMM
level 2 and the five process drivers representing the key
process areas of CMM level 3, as shown in Table 4.
4.2.6. Generating a project-specific process model.
The spiral model domain model is tailored according to
a particular 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. Each activity has an associated document
describing the detailed procedures to be performed.
Thus, a project specific process, generated from the
SPM domain model, contains all the relevant documents
that are needed to manage the project.
Fig. 8 shows the aggregation hierarchy of a tailored
version of the SPM domain model. The needs of this
project dictate the inclusion of two process drivers:
“Low
understanding
of
Requirements”
and
“Requirements management”. The Low understanding
of Requirements process driver is a risk-related driver
and is supported by the optional Requirements
Prototyping activity (Table 1). The Requirements
management process driver is a CMM-related process
driver and is supported by the optional Requirements
Review activity (Table 3). Both of these activities are
included in the project specific process, shown in Fig. 8.
Comparing Fig. 8 with Fig. 3 shows that those optional
activities not required for a specific project are omitted
from the project specific process, while all kernel
activities are included.
Spiral Process
Domain
Developing and
Verifying Product
Project
Planning
Cycle
Requirements Analysis
and Specification
Cycle
Preliminary
Design
Cycle
Requirements
Requirements Requirements
Analysis and
Prototyping
Review
Specification
Construction
and Test
Cycle
System
Testing
Cycle
Architectural
Design
Figure 8: Aggregation Hierarchy for a
Project Specific Process
5. Domain modeling environment
A prototype domain modeling environment has been
developed, called the Knowledge Based Software
Engineering Environment (KBSEE) [Gomaa94,
Gomaa96], which consists of an integrated set of
software tools to support domain modeling and target
system requirements elicitation. The environment uses
commercial-of-the-shelf software as well as custom
developed software. The graphical editors supported by
the Software through Pictures (StP) CASE tool are used
to represent the multiple views of the domain model.
However, the multiple views are interpreted
semantically according to the domain modeling method.
The information in the multiple views is extracted,
checked for consistency, and mapped to an object
repository. The feature / object dependencies are then
defined using a custom developed tool.
A knowledge-based requirements elicitation tool
(KBRET) is used to assist with eliciting target system
requirements and generating the target system
specification [Gomaa92]. The tool, implemented in
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 multiple views of the target system
specification.
The prototype KBSEE is a domain-independent
environment. Thus, it may be used to develop a domain
model for any application domain that has been
analyzed, and to generate target system specifications
from it.
A domain model of the Spiral Process Model has
been developed using the prototype KBSEE. For this
application, the KBSEE was used as a process model
generator and the Knowledge Based Requirements
Elicitation Tool was completely re-engineered to
become a Process Model Generator (PROGEN).
PROGEN, is implemented in NASA’s CLIPS shell and
the CLIPS Object Oriented Language (COOL).
The domain model is created using the KBSEE. The
StP graphical editors are used to represent the multiple
views of the domain model, namely the Aggregation
Hierarchy, the Activity (object) Communication
Diagrams, and the Generalization / Specialization
Hierarchies. The information in the multiple views is
extracted, checked for consistency, and mapped to an
object repository.
The process driver/ activity
dependencies are defined using the KBSEE Feature /
Object Editor.
PROGEN interacts with the project manager,
presenting the process drivers available for selection.
The project manager selects the drivers relevant to the
project. PROGEN then tailors the SPM domain model
to generate a project specific process model containing
the kernel process activities, together with the optional
and variant activities included to satisfy the selected
process drivers.
6. Conclusions
The software development process is susceptible to
risks, and project managers wish to mitigate those risks
by selecting the most appropriate process model for a
project. The domain model of the CMM augmented
Spiral Process Model allows managers to select those
features representing project risks, and allows them to
generate a tailored process model. Thus, the domain
modeling approach provides for large-scale reuse of the
SPM activities as well as configured process models that
have guided successful projects.
This paper therefore contributes to two important
areas in software engineering, software reuse and
process modeling, with the added advantage of creating
a reusable domain model and architecture for the family
of process models.
The Spiral Process Model is a risk-driven process
model, which, depending on the specific risks associated
with a given project, may be tailored to create a project
specific process model. The software reuse area
addressed is that of domain models of families of
systems, which capture the similarities and variations
among the members of the family. From the domain
model, target systems are generated given the specific
requirements of the target system.
The domain modeling method and environment
described in this paper are application independent.
Thus they can be applied to any domain model for
which a domain analysis has been carried out. We are
currently investigating using the Unified Modeling
Language (UML) [Booch98], as a notation for modeling
families of systems [Gomaa00]. Further worthwhile
investigations in this area include using statecharts
(hierarchical state transition diagrams), which are also
supported by UML [Booch98], to model the dynamic
aspects of the SPM, and to model process enactment,
i.e., the actual execution of a given project specific
software process model for validating purposes.
7. Acknowledgments
The authors gratefully acknowledge the contributions
of C. Bosch, E. O’Hara, R.G. Mohan, V. Sugumaran,
and I. Tavakoli, in developing the prototype Knowledge
Based Software Engineering Environment, and the
contributions of F. Carr and J. Yoon in its application to
process modeling. This research was supported in part
by the NASA Goddard Space Flight Center, the Virginia
Center of Innovative Technology, DARPA, the Virginia
Center of Excellence in Software Reuse, the Software
Productivity Consortium, and IDE Inc. The views and
conclusions expressed are those of authors and should
not be interpreted as representing the official policies or
endorsements, either expressed or implied, of NASA,
DARPA, The MITRE Corporation, or the Software
Productivity Consortium.
8. References
[Agresti86] Agresti W.W., New Paradigms for Software
Development, IEEE Computer Society Press, 1986.
[Boehm 76] Boehm, B. W., “Software Engineering," IEEE
Transactions on Computers, Vol. 25, No. 12, Dec 1976, pp.
1226-1241.
[Boehm88] Boehm, B., “A Spiral Model of Software
Development and Enhancement,” IEEE Computer, May 1988.
[Boehm89] Boehm, B. and F. Belz, “Experiences with the
Spiral Model as a Process Model Generator,” Proceedings of
th
5 International Software Process Workshop, 1989.
[Batory92] Batory D and S. O’Malley, “The Design and
Implementation of Hierarchical Software with Reusable
Components," ACM Transactions on Software Engineering
Methodology, 1(4), pages 355-398, October 1992.
[Booch94] Booch, G., Object-Oriented Analysis Design with
Applications, Addison Wesley, Second Edition, 1994.
[Booch98] Booch, G., J. Rumbaugh, and I. Jacobson, The
Unified Modeling Language User Guide, Addison Wesley,
Reading, MA, 1999.
[Bosch99] Bosch, J., “Product-Line Architectures in Industry:
A Case Study,” Proceedings of IEEE ICSE, Los Angeles, May
1999.
[CMM 95] CMU Software Engineering Institute, “The
Capability Maturity Model,” Addison Wesley, 1995.
[Cohen98] Cohen, S., and L. Northrop, “Object-Oriented
Technology and Domain Analysis”, Proceedings of IEEE
ICSR5, Victoria, June 1998.
[Coleman94] Coleman, D., et. al., Object Oriented
Development – The Fusion Method, Prentice Hall 1994.
[Coplien98] J. Coplien, D. Hoffman, D. Weiss, “Commonality
and Variability in Software Engineering”, IEEE Software,
Nov/Dec 1998.
[Cuka98] Cuka, D. and D. Weiss, “Engineering Domains:
Executable Commands as an Example”, Proceedings of IEEE
ICSR5, Victoria, June 1998.
[DeBaud99] DeBaud, J.M. and K. Schmid, “A Systematic
Approach to Derive the Scope of Software Product Lines,”
Proceedings of IEEE ICSE, Los Angeles, May 1999.
[Dionisi98] Dionisi, A. et al., “FODAcom: An Experience
with Domain Modeling in the Italian Telecom Industry”,
Proceedings of IEEE. ICSR5, Victoria, June 1998.
[Frakes96] Frakes, W. and C. Hollenbach, “Software Process
Reuse in an Industrial Setting”, Proceedings of IEEE ICSR4,
Orlando, April 1996.
[Gomaa92] Gomaa, H., L. Kerschberg, V. Sugumaran, “A
Knowledge-Based Approach for Generating Target System
Specifications from a Domain Model,” Proceedings of IFIP
World Computer Congress, Madrid, Spain, September 1992.
[Gomaa93] Gomaa, H., “A Reuse-Oriented Approach for
Structuring and Configuring Distributed Applications,”
Software Engineering Journal, March 1993.
[Gomaa94] Gomaa, H., et. al., “A Prototype Domain
Modeling Environment for Reusable Software Architectures”.
Proceedings of IEEE ICSR3, Rio de Janeiro, November 1994.
[Gomaa95] H. Gomaa, "Reusable Software Requirements and
Architectures for Families of Systems", Journal of Systems
and Software, April 1995.
[Gomaa96] Gomaa, H., et. al. "A Knowledge-Based Software
Engineering
Environment
for
Reusable
Software
Requirements and Architectures," Journal of Automated
Software Engineering, Vol. 3, Nos. 3/4, August 1996.
[Gomaa97] Gomaa, H., “The Impact of Prototyping on
Software Systems Engineering”, in System and Software
Requirements Engineering, edited by R. Thayer and M.
nd
Dorfman, IEEE Computer Society Press, 2 Edition, 1997.
[Gomaa00] Gomaa, H., Object Oriented Analysis and
Modeling for Families of Systems with UML, Proc. IEEE
International Conference on Software Reuse, Vienna, June
2000.
[Griss98] M. Griss, J. Favaro, M. D’Alessandro, “Integrating
Feature Modeling with the RSEB”, Proceedings of IEEE
ICSR5, Victoria, June 1998.
[Henninger98] Henninger, S., “ An Environment for Reusing
Software Processes”, Proceedings of IEEE ICSR5, Victoria,
June 1998.
[Humphrey89] Humphrey, W., Managing the Software
Process, Addison Wesley, 1989.
[Jacobson92] Jacobson, I., Object-Oriented Software
Engineering, Addison Wesley, Reading MA, 1992.
[Kang90] Kang, K.C. et. al., "Feature-Oriented Domain
Analysis", Technical Report No. CMU/SEI-90-TR-21,
Software Engineering Institute, November 1990.
[Lubars92] Lubars, M.D., C. Potts, and C. Richter, "Objectth
Oriented Analysis for Evolving Systems", Proceedings of 14
IEEE ICSE, pp. 173-185, 1992.
[Parnas79] Parnas, D., “Designing Software for Ease of
Extension and Contraction,” IEEE Transactions on Software
Engineering, March 1979.
[Rumbaugh91] Rumbaugh, J., et al., Object-Oriented
Modeling and Design, Prentice Hall, 1991.
[Zave84] Zave, P., "The Operational Versus the Conventional
Approach to Software Development", CACM, February 1984.
Table 1. Risk-Related Process Drivers and Supporting Activities
Process Driver
Need for project level prototyping
Activities required to support Process Driver
Project Level Prototyping
Lack of development method
Need for CASE tool
Low understanding of Requirements
Evolutionary development
Selection of Development Method
Selection of CASE Tool
Requirements Prototyping
Requirements Prototyping, Planning for Evolutionary Development, and
OOD Method Selection
Planning for Incremental Development, Planning for Evolutionary
Development, and OOD Method Selection
Design Performance Analysis, Design Prototyping, Performance Testing, and
Performance Testing Peer Review
Requirements Prototyping, Preparation of Enhanced Documentation
Design Prototyping
Requirements Prototyping, Planning for Incremental Development, and
Planning for Evolutionary Development
Planning for Incremental Development
RT Design Method Selection
Selection of Design Method
Design Method Training
Local Design Tailoring
Select or Adapt Reusable Components
Defining Objectives, Alternatives, & Constraints, Analyzing Risks,
Scheduling and Planning, Commitment To Planning, Monitoring and
Reviewing Product, Product Change Control, Project Progress Review,
Planning for Requirements Cycle, Planning for Architectural Design Cycle,
Planning for Construction and Test Cycle, Planning for System Testing Cycle
Operational life cycle
Performance requirements
Maintenance/support requirements
Complex system interfaces
Incremental development
Phasing
Real time system
Design method need
Design method training need
Existing hardware/software constraint
Reuse library exists
Spiral process
Table 2. Risk-Related Process Driver Relationships
(Left Column Driver Requires Right Column Driver)
Process Driver
Required Driver
Real time system
Performance requirements
Design method need
Design method training need
Lack of development method
Design method need
Table 3. CMM Level 2 Related Process Drivers and Supporting Activities
Process Driver
Activities required to support Process Driver
Requirements
management
Requirements Review
Software project
planning
Software Cost Estimation, Software Size Estimation, Critical Computer Resources Estimation,
Software Schedule Planning, Life Cycle Selection, Definition of Project Commitments, and
Planning Project Facilities & Support Tools
Software tracking
and oversight
Project Progress Review, Software Schedules Review, SW Effort and Cost Review, Critical
Computer Resources Review, Project Commitments Review, and Work Product Size Review
Software
subcontract
management
Planning Subcontract Management, Project Progress Review, and Tracking Subcontract
Progress
Software quality
assurance
Preparing SQA Plan, Project Progress Review, and SQA Audit of Work Products
Software
configuration
management
Preparing SCM Plan, Establishing CM Library, and Identification of SCM Work Products
Process Driver
CMM level 2
CMM level 3
Table 4. CMM-Related Process Driver Relationships
(Left Column Driver Requires Right Column Drivers)
Required Driver
Requirements management
Software project planning
Software tracking and oversight
Software subcontract management
Software quality assurance
Software configuration management
Training program
Integrated software management
Software product engineering
Intergroup coordination
Peer reviews
CMM level 2