Domain Modeling of Software Process Models

Transcription

1 Domain Modeling of Software Process Models Hassan Gomaa, Larry Kerschberg, and Ghulam A. Farrukh George Mason University and The MITRE Corporation and 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).

2 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 Domain Modeling Target System Reusable Unsatisfied, Errors, Adaptation Domain Reuse Library Target System Generation Target System 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 IS- A 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 Target system specification generation A Target System 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. 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 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

3 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. 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] 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 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 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. 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] The capability maturity model 2. Analyze Risks 3. Develop Product 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

4 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 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 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

5 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 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 Object Communication Diagrams. The first level of decomposition of the spiral model domain Spiral Process Domain Defining Objectives, Alternatives, and Constraints Analyzing Risks Developing and Verifying Product Spiral Analysis and Preliminary Construction and Test System Testing Analysis and KS Prototyping Review KS Prototyping Performance Analysis Local Tailoring Review 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 Analysis and and the Preliminary, 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 Analysis and activity is decomposed into three activities: Analysis and, Prototyping, and 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 Review activity will only be performed if there is a need for the Management process driver (Table 3, see last page). The Preliminary activity is decomposed into five activities:, Prototyping, Performance Analysis, Local Tailoring, and 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, as shown in Fig. 4. Each of these aggregate objects is Supporting Supporting Meeting Minutes Updated Estimate of Situation 1 Defining Objectives, Alternatives, and Constraints Updated 4 Spiral Updated Estimate of Situation Product Status Updated Product Baselines Supporting Meeting Minutes 2 Analyzing Risks Risk Management Plan Product Baselines 3 Developing and Verifying Product Product Status Risk Management Plan Updated Supporting Figure 4: Top Level OCD for Spiral Process Model

6 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 Analysis and OCD (Fig. 5), Analysis and is a kernel object, as it is Risk Management Plan Review activity,, with four optional activities. The optional activities are Prototyping, Performance Analysis, Local Tailoring, and Review. All the optional activities interact with the kernel activity and so there are no inter-dependencies among the optional activities. The Prototyping and Performance Analysis activities are both required if the Performance process driver is selected (Table 1), e.g., for a real-time development project 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 Local Tailoring Tailored s Plan Prototype Analysis and KS Prototyping Review Status Preliminary Product Status Figure 5: OCD for the Analysis and assumed that every software project would include this activity. However, Prototyping is an optional object, as this activity is only required if there is a poor understanding of requirements (a process driver). Review is another optional object, as this activity is only required if there is a need for Management (another process driver). The OCD for the Preliminary is shown in Fig. 6, which shows the interactions of a kernel Performance Spec Risk Management Plan KS Preliminary Spec Prototyping Performance Analysis Architecture Review Prototype Product Status Spec Trained Staff Preliminary Spec Review Status Figure 6: OCD for the Preliminary process models. An example of specialization is Method Selection. This activity type is specialized to

7 reflect the different kinds of method selection that can be carried out, reflecting the characteristics of different projects. These specialized activity types are Objectoriented Method Selection, Ada-based Method Selection, Real-Time Method Selection, and Distributed Method Selection (Fig. 7). OO Method Selection Ada Based Method Selection Selection of Method OVS Real Time Method Selection Distributed Method Selection Figure 7: Generalization/Specialization for Method Selection 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 is supported by the activity Prototyping. This means that if the requirements are not understood, then the 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, Performance Analysis, Prototyping, and Performance Testing support the process driver Performance. 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 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: 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 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 and management. The Low understanding of process driver is a risk-related driver and is supported by the optional Prototyping activity (Table 1). The

8 management process driver is a CMM-related process driver and is supported by the optional 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. Analysis and Analysis and Prototyping Spiral Process Domain Developing and Verifying Product Preliminary Review Construction and Test 5. Domain modeling environment Figure 8: Aggregation Hierarchy for a Specific Process System Testing 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 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

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

10 Engineering, edited by R. Thayer and M. Dorfman, IEEE Computer Society Press, 2 nd Edition, [Gomaa00] Gomaa, H., Object Oriented Analysis and Modeling for Families of Systems with UML, Proc. IEEE International Conference on Software Reuse, Vienna, June [Griss98] M. Griss, J. Favaro, M. D Alessandro, Integrating Feature Modeling with the RSEB, Proceedings of IEEE ICSR5, Victoria, June [Henninger98] Henninger, S., An Environment for Reusing Software Processes, Proceedings of IEEE ICSR5, Victoria, June [Humphrey89] Humphrey, W., Managing the Software Process, Addison Wesley, [Jacobson92] Jacobson, I., Object-Oriented Software Engineering, Addison Wesley, Reading MA, [Kang90] Kang, K.C. et. al., "Feature-Oriented Domain Analysis", Technical No. CMU/SEI-90-TR-21, Software Engineering Institute, November [Lubars92] Lubars, M.D., C. Potts, and C. Richter, "Object- Oriented Analysis for Evolving Systems", Proceedings of 14 th IEEE ICSE, pp , [Parnas79] Parnas, D., ing Software for Ease of Extension and Contraction, IEEE Transactions on Software Engineering, March [Rumbaugh91] Rumbaugh, J., et al., Object-Oriented Modeling and, Prentice Hall, [Zave84] Zave, P., "The Operational Versus the Conventional Approach to Software Development", CACM, February Table 1. Risk-Related Process Drivers and Supporting Activities Process Driver Need for project level prototyping Lack of development method Need for CASE tool Low understanding of Evolutionary development Operational life cycle Performance requirements Maintenance/support requirements Complex system interfaces Incremental development Phasing Real time system method need method training need Existing hardware/software constraint Reuse library exists Spiral process Activities required to support Process Driver Level Prototyping Selection of Development Method Selection of CASE Tool Prototyping Prototyping, for Evolutionary Development, and OOD Method Selection for Incremental Development, for Evolutionary Development, and OOD Method Selection Performance Analysis, Prototyping, Performance Testing, and Performance Testing Peer Review Prototyping, Preparation of Enhanced Documentation Prototyping Prototyping, for Incremental Development, and for Evolutionary Development for Incremental Development RT Method Selection Selection of Method Method Training Local Tailoring Select or Adapt Reusable Components Defining Objectives, Alternatives, & Constraints, Analyzing Risks, Scheduling and, Commitment To, Monitoring and Reviewing Product, Product Change Control, Progress Review, for, for, for Construction and Test, for System Testing

11 Table 2. Risk-Related Process Driver Relationships (Left Column Driver Requires Right Column Driver) Process Driver Real time system method need Lack of development method Required Driver Performance requirements method training need method need Table 3. CMM Level 2 Related Process Drivers and Supporting Activities Process Driver management Software project planning Software tracking and oversight Software subcontract management Software quality assurance Software configuration management Activities required to support Process Driver Review Software Cost Estimation, Software Size Estimation, Critical Computer Resources Estimation, Software Schedule, Life Selection, Definition of Commitments, and Facilities & Support Tools Progress Review, Software Schedules Review, SW Effort and Cost Review, Critical Computer Resources Review, Commitments Review, and Work Product Size Review Subcontract Management, Progress Review, and Tracking Subcontract Progress Preparing SQA Plan, Progress Review, and SQA Audit of Work Products Preparing SCM Plan, Establishing CM Library, and Identification of SCM Work Products Process Driver CMM level 2 CMM level 3 Table 4. CMM-Related Process Driver Relationships (Left Column Driver Requires Right Column Drivers) Required Driver 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