15504-5 model in particular, have been done elsewhere, as for example, by Lepasaar et al. [19], Alexandre and. Habra [20] and Rout and Tuffley [21]. The iCMM ...
in Proceedings of The Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE'08), pp. 173-178, San Francisco, CA, USA, July 1-3, 2008
Unified Basic Concepts for Process Capability Models Clenio F. Salviano and Adriana M. C. M. Figueiredo Centro de Pesquisas Renato Archer – CenPRA Rod. D. Pedro I, km 143,6 – CEP 13069-901 - Campinas, SP, Brazil Clenio.Salviano @ { cenpra.gov.br, gmail.com }, Adriana.Figueiredo @ cenpra.gov.br
Abstract This article introduces a set of unified basic concepts for Process Capability Models for the unification, generalization and modeling of views of the structure and elements of relevant models, with more similar granularity of its leaf elements. This set is part of an ongoing research effort to evolve the current Software (and Systems) Process Improvement area towards a Model Driven Process Capability Engineering for Knowledge Working Intensive Organizations. The set is implemented in Eclipse Ecore. Its evaluation includes the modeling of a unified view of CMMI-DEV and ISO/IEC 15504-5 models as relevant examples.
of related generic “how good to do” good practices. Process Capability Profile is a model of a process, under the aspect of process capability, composed of pairs of a process capability area at a process capability level. The article is organized as follows. This first section is an introduction to the article. The second section presents the research context and methodology. The third section defines goals. The fourth section introduces a class diagram for the unified basic concepts. The fifth section describes CMMI-DEV and ISO/IEC 15504-5 views. The sixth section provides evaluation against the goals. The seventh section presents related and future work. Finally the eighth section presents conclusions.
Keywords Software Process Improvement (SPI), Model-Driven Engineering (MDE), and Knowledge Working
2. RESEARCH CONTEXT The set of unified basic concepts introduced in this article is part of an ongoing research effort [5, 6, 7, 8] proposing a Model-Driven Process Capability Engineering for Knowledge Working Intensive Organizations (MDPEK) for the evolution of the current SPI area. MDPEK is a Model Driven Engineering (MDE) [9, 10] for improving knowledge working (including software and system working) intensive organization, identifying and acting in relevant processes based on the concept of process capability, integrated with the organization strategy to better business results, driven by a Process Capability Profile defined with elements from one or more Process Capability Models [8]. The models are, for example, CMMI-DEV, ISO/IEC 15504-5, iCMM, eSCM-SP, OPM3, COBIT, ITIL, COMPETISOFT and MR-MPS and/or process capability views of different types of good practices models, such as ISO 9001, PMBOK, EFQM, SWEBOK and Agile Methodologies1. MDPEK focus on knowledge working processes, as defined first by Drucker [11]. In this sense, Process Capability Models not related with software or systems may also be used, as for example, the Process Capability Model for University Research Laboratories [12]. This research effort uses an industry-as-laboratory approach as proposed by Potts [13]. Potts argues that the traditional research-then-transfer approach is inadequate because it treats research and its application by industry as separate, sequential activities.
1. INTRODUCTION In a panel on Research Directions in Software Process Improvement (SPI), David Card pointed out that SPI “has become a driving force in the global software industry. … [however the majors SPI] approaches today are considered competitors. In reality they are all based on very similar concepts and techniques. The packaging obscures the underlying principles. Eliciting and refining underlying principles is the role of science” [1]. This article introduces a set of unified basic concepts as a proposal for the underlying principles of Process Capability Models that are a relevant part of SPI (now redefined as Software and System Process Improvement). SPI was established as a “driving force in the global software industry” around the development and successful usage of the Capability Maturity Model for Software (SW-CMM) [2]. Nowadays, the Capability Maturity Model Integration for Development (CMMIDEV) [3], the successor of SW-CMM, and the ISO/IEC 15504-5 Exemplar Process Assessment Model for Software Engineering (ISO/IEC 15504-5) [4] are the dominant reference models for SPI. A more generic term – Process Capability Model – is proposed to mean all good practices reference models organized with the concept of Process Capability. Three more generic terms are also introduced: Process Capability Area, Process Capability Level and Process Capability Profile. Process Capability Area is a set of related specific “what to do” good practices. Process Capability Level is a set
173
1
These fourteen models are well known. References for them are available elsewhere, for example, in Salviano [6, 8].
in Proceedings of The Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE'08), pp. 173-178, San Francisco, CA, USA, July 1-3, 2008
represents the leaf elements with more similar granularity, than the correspondent elements of CMMI-DEV and ISO/IEC 15504-5 models. Finally, the Goal G5 is that it supports the definition of process capability profiles with any combination among the elements of available models, reusing elements, preserving the original models and without the need to create new models.
Following the industry-as-laboratory approach, a MDPEK exemplar methodology (named as PRO2PI for Process Capability Profile to Process Improvement) has been developed and applied in the industry together with the development and utilization of MDPEK and the set of unified basic concepts [5, 6, 7, 8]. The set of basic concepts introduced in this article is the result of the second phase of a project in this research effort. Phase 1 is a proposal and initial specification as described by Salviano [6]. Phase 2 is the development and implementation of a revised version and the modeling of CMMI-DEV and ISO/IEC 15504-5 models as examples.
4. Geraes CLASS DIAGRAM FOR THE UNIFIED BASIC CONCEPTS The set of unified basic concepts for Process Capability Models is represented as the Geraes Class Diagram as illustrated in Figure 1 defined with TopCased [15], an Eclipse Modeling Framework [14] plugin to the definition of metamodels based on Ecore.
3. RESEARCH GOALS AND METHODOLOGY To guide the activities of the second phase, a main goal and five unfolded objective goals are defined. The main goal is that the unified basic concepts represent a useful proposal for the underling basic concepts of Process Capability Models. The first unfolded objective goal (Goal 1) is that the set of unified concepts generalize and unify the structure of CMMI-DEV and ISO/IEC 15504-5 models. The Goal G2 is that it has fewer, more generic and more flexible key basic concepts than the CMMI-DEV and ISO/IEC 15504-5 models. The Goal G3 is that it supports the mapping and unification of the elements of CMMI-DEV and ISO/IEC 15504-5 models. The Goal G4 is that it supports a hierarchy of elements and
Figure 1 – Geraes Class Diagram in Eclipse Ecore
174
in Proceedings of The Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE'08), pp. 173-178, San Francisco, CA, USA, July 1-3, 2008
an abstract class with two concrete subclasses each: the first one models the composition relation (with the Comp suffix) and the second one models the leaf element (with the suffix Leaf). The composition and the leaf element use as a name the aggregation of the initials of the root element name (PCA, PCL, PO, PP, PCP and PCM) followed by the suffix Elem or Comp.
In Figure 1, for legibility’s sake, the words Process, Capability and Profile are replaced by Proc, Cap and Prof. An organization defines and uses a ProcessCapabilityProfile as a model of its current or future process. A ProcessCapabilityProfile is composed of one or more ProcessAreaCapabilityProfiles. Each ProcessAreaCapabilityProfile is a ProcessCapabilityArea at a ProcessCapabilityLevel. Each ProcessCapabilityArea and each ProcessCapabilityLevel is composed of one or more ProcessOutcomes. Each ProcessOutcome is composed of one or more PracticeElements.
The class diagram in Figure 1 is named Geraes because its shape resembles the drawing in the cover of Milton Nascimento´s album named Geraes [17]2.
A ProcessCapabilityModel is a collection of one or more ReferencePractices. ReferencePractice is an abstract super class for (with the exception of ProcessCapabilityModelElements) all Process Capability Model elements, including the ProcessCapabilityModel itself. There are four attributes for ReferencePractice: id (identification), name, def (definition) and desc (description). ProcessCapabilityModelElements is a collection of all ReferencePractices. A ReferencePractice may refer to one or more PracticeGuidances. ProcessCapabilityModel and PracticeGuidance are two concrete subclasses of ReferencePractice. There are also three more subclasses of ReferencePractice: the abstract classes PracticeElement, PracticeGroup and PracticeSystem.
Figure 2 – Geraes Diagram and Geraes Album Cover
5. CMMI-DEV AND ISO/IEC 15504-5 VIEWS This section is a partial unified view of the complete modeling of CMMI-DEV and ISO/IEC 15504-5 models that is described in a technical report [18].
PracticeElement has four subclasses: ProcessOutcome, BasePractice, WorkProduct and Resource. PracticeGroup has two subclasses: ProcessCapabilityArea and ProcessCapabilityLevel. PracticeSystem has two subclasses: ProcessCapabilityProfile and ProcessAreaCapabilityProfile.
A CMMI-DEV´s Process Area is modeled as a ProcessCapabilityArea composed of one, two or three lower level ProcessCapabilityAreas. Those lower levels ProcessCapabilityAreas correspond to the CMMI-DEV´s Specific Goals. There are twenty-two process areas and forty-eight specific goals in CMMI-DEV. The process areas are organized into four process area categories. Each process area category is modeled as a higher level ProcessCapabilityArea. Therefore these three CMMIDEV concepts (process area category, process area and specific goal) are modeled as ProcessCapabilityAreas in three levels of composition.
ProcessAreaCapabilityProfile represents a ProcessCapabilityArea at a ProcessCapabilityLevel. ProcessCapabilityProfile is a collection of one or more ProcessAreaCapabilityProfiles. A ProcessCapabilityProfile is a collection of one or more ProcessAreaCapabilityProfile. Each ProcessCapabilityArea and ProcessCapabilityLevel is a collection of one or more PracticeElements. A PracticeElement is a collection of one or more ProcessOutcomes. A ProcessOutcome is a collection of one or more BasePractices, zero or more WorkProducts and zero or more Resources. ProcessOutcome, BasePractice, WorkProduct and Resource are subclasses of ProcessElement.
The CMMI-DEV Project management process area category, for example, is modeled as a ProcessCapabilityArea composed of six lower levels ProcessCapabilityAreas (with ids “PP”, “PMC”, “SAM”, “IPM”, “RSKM” and “QPM”). The PP ProcessCapabilityArea, for example, is composed of three lower levels ProcessCapabilityAreas (with names “Establish Estimates”, “Develop a Project Plan” and “Obtain Commitment to the Plan”. Each one of these three lower levels ProcessCapabilityAreas is a ProcessCapabilityAreaLeaf, while each one of the two higher levels ProcessCapabilityAreas (“Project Management” and “Project Planning”) is a ProcessCapabilityAreaComp.
The concrete class ProcessAreaCapabilityProfile is a connection between PracticeSystem and PracticeGroup. The concrete class ProcessOutcome is a connection between PracticeGroup and PracticeElement. ProcessCapabilityArea, ProcessCapabilityLevel, ProcessOutcome, BasePractice and ProcessCapabilityProfile are modeled with two more subclasses each, using the Composer Design Pattern [16]. This design pattern addresses the need to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. Each one of these classes is modeled as
2
175
The idea of an icon is inspired in Favre on the S Mega-Pattern: “The shape of the S pattern has been chosen to directly mimic the layout of the piece of art One and Three Chairs from Kosuth” [9, p. 6].
in Proceedings of The Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE'08), pp. 173-178, San Francisco, CA, USA, July 1-3, 2008
mined”. This first ProcessOutcome has only one BasePractice (id “MAN1.BP1”, name “Establish risk management scope”, and desc “Determine the scope of risk management to be performed”).
The four original CMMI-DEV process area categories, twenty-two process areas and forty-eight specific goals are modeled as forty-eight ProcessCapabilityAreaLeafs and twenty-two ProcessCapabilityAreaComps concrete classes. These twenty-two ProcessCapabilityAreaComps are the four process area category and the eighteen process areas with two or three specific goals. The four process areas with only one specific goal are modeled as ProcessCapabilityAreaLeaf because there is no difference between the original process area and its one specific goal.
A CMMI-DEV process capability level is a ProcessCapabilityLevel composed of one, two or ten lower level ProcessCapabilityLevel. Those lower levels ProcessCapabilityLevel are named Generic Goals in CMMI-DEV. There are six process capability levels in CMMI-DEV and seventeen Generic Goals. An ISO/IEC 15504-5 process capability level is a ProcessCapabilityLevel, composed of zero, one or two lower level ProcessCapabilityLevel. Those lower levels ProcessCapabilityLevel are named Process Attribute in ISO/IEC 15504-5. There are six process capability levels and nine process attributes in ISO/IEC 15504-5.
A CMMI-DEV specific goal is a ProcessCapabilityAreaLeaf composed of ProcessOutcomes. There is no concept of outcome in CMMI-DEV. A specific goal is composed of specific practices. In order to model an outcome, each specific practice is modeled as an outcome and as a practice. The outcome is the practice rewritten with the passive voice. The specific practice “SP 1.1 Elicit Needs”, for example, is modeled as a BasePractice (id “SP 1.1”, name “Elicit Needs”, and def “Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle”) and as a ProcessOutcome (id “Out 1.1”, name “Needs are elicited”, and def “stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle are elicited”).
The six original CMMI-DEV process capability levels and the six original ISO/IEC 15504-5 process capability levels are modeled as six ProcessCapabilityLevels composed of zero, one, two or three lower level ProcessCapabilityLevels. As both sets are based in the measurement framework of ISO/IEC 15504, they are similar. But they are not equivalent. Therefore, each set is modeled separated, but using a similar structure in order to facilitate further composition among them. The ISO/IEC 15504-5 “Managed process” capability level and the CMMI-DEV “Managed process” capability level are modeled as ProcessCapabilityLevel (id “2” and name “Managed process”). This capability level is defined in ISO/IEC 15504-5 as composed of two process attributes (PA2.1 and PA2.2). The corresponded capability level in CMMI-DEV is defined as composed of ten Generic Practices (GP2.1 to GP2.10). The correspondent ProcessCapabilityLevel is modeled as composed of three lower levels ProcessCapabilityLevels. Table 1 describes these three lower levels ProcessCapabilityLevels, identified in column “Unified Leaf PCL”. Some of the original Generic Practices and Outcomes are divided into two parts, identified as (p1) and (p2), in order to allow a correspondence to the other model.
An ISO/IEC 15504-5´s process is modeled as a ProcessCapabilityArea. There are forty-eight processes in ISO/IEC 15504-5 model that are organized in nine process groups. Each ISO/IEC 15504-5 process groups is modeled as a higher level ProcessCapabilityArea. The ISO/IEC 15504-5 process groups are further organized in three process categories. Each ISO/IEC 15504-5 process category is a higher level ProcessCapabilityArea. Therefore, these three ISO/IEC 15504-5 concepts (process category, process group and process) are modeled as ProcessCapabilityAreas in three levels of composition. The ISO/IEC 15504-5 organizational life cycle process category, for example, is modeled as a ProcessCapabilityArea (name “Organizational”). This ProcessCapabilityArea is composed of four lower levels ProcessCapabilityAreas (with names “Management”, “Process Improvement”, “Resource and Infrastructure” and “Reuse”). The Management ProcessCapabilityArea, for example, is composed of six lower levels ProcessCapabilityAreaLeafs.
Using the contents of Table 1 as a guide, the capability levels of the original CMMI-DEV, the original ISO/IEC 15504-5 and a unified view, can be modeled. They use a subset of the same fourteen ProcessCapabilityLevelLeafs. Unified 2.1.1, 2.1.6 and 2.3.4 exist in CMMIDEV but not in ISO/IEC 15504-5. Unified 2.1.2, 2.2.1 and 2.2.2 exist in ISO/IEC 15504-5 but not in CMMIDEV. A similar table is produced for capability level 3 (with also three ProcessCapabilityLevelLeafs), for capability level 4 and 5 (each one with two ProcessCapabilityLevelLeafs).
An ISO/IEC 15504-5 outcome and its correspondent base practices are a ProcessOutcome with BasePractices. Each base practice corresponds to one or more outcomes. When a base practice corresponds to more than one outcome, it is decomposed in a way that each element corresponds to only one outcome. The ISO/IEC 15504-5 Risk management process, for example, is a ProcessCapabilityArea with six ProcessOutcomes. The first ProcessOutcome is modeled with desc equal to “the scope of the risk management to be performed is deter-
A CMMI-DEV staged representation is modeled with four ProcessCapabilityProfiles, each one representing a maturity level.
176
in Proceedings of The Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE'08), pp. 173-178, San Francisco, CA, USA, July 1-3, 2008 Table 1 - Example of Unified View Generic Practices for CMMI-DEV Generic Goal 2 Id GP 2.1
Name Establish Organizational Policy
Unified Leaf PCL Id
Id
Name
2.1 .1 2.1.2
PA 2.1 a)
Objectives for the performance are identified; Performance of the process is planned;
GP 2.2
Plan the Process
2.1.3
PA 2.1 b) (p1)
GP 2.3
Provide Resources
2.1.4
PA 2.1 e)
GP 2.4
Assign Responsibility
2.1.5
PA 2.1 d)
Responsibilities and authorities are defined, (…);
PA 2.2 a)
Requirements for the work products are defined;
2.2.2
PA 2.2 b)
Requirements for documentation and control are defined;
GP 2.5
Train People
Resources and information necessary are identified, (…);
2.1.6
2.2.1
GP 2.6
Manage Configurations
2.2.3
PA 2.2 c)
Work products are appropriately identified, (…)
GP 2.9
Objectively Evaluate Adherence
2.2.4
PA 2.2 d)
Work products are reviewed and adjusted as necessary ;
GP 2.8 (p1)
Monitor and Control the Process
2.3.1
PA 2.1 b) (p2)
Performance of the process is monitored;
GP 2.8 (p2)
Monitor and Control the Process
2.3.2
PA 2.1 c)
Performance of the process is adjusted to meet plans;
GP 2.7
Identify and Involve Relevant Stakeholders
2.3 .3
PA 2.1 f)
Interfaces between the involved parties are managed.
GP 2.10
Review Status
goal, maturity level, capability profile) and one key implicit concept (process area capability profile) are modeled with four key concepts of the class diagram (ProcessCapabilityArea, ProcessCapabilityLevel, ProcessAreaCapabilityProfile and ProcessCapabilityArea). Four explicit key ISO/IEC 15504-5 concepts (process, process capability level, process capability profile and process attribute) and one key implicit concept (individual process capability profile) are modeled with the same four key concepts of the class diagram. For PracticeElement, four explicit key CMMI-DEV concepts (specific practice, generic practice, typical work product and sub practice) are modeled with four key concepts of the class diagram (BasePractice and WorkProduct). Six explicit key ISO/IEC 15504-5 concepts (outcome, base practice, work product, generic practice, generic resource and generic work product) are modeled with the four key concepts of the class diagram (ProcessOutcome, BasePractice, WorkProduct and Resource). As the same eight key concepts cover twelve CMMI-DEV concepts and eleven ISO/IEC 15504-5 concepts, this goal is considered satisfied.
Outcomes for ISO/IEC 15504-5 Process Attributes 2.1 and 2.2
The achievement of Goal G3 also is evidenced by the description of how the key elements of both models are modeled. The achievement of Goal G4 is evidenced by an analysis of what elements from CMMI-DEV and ISO/IEC 15504-5 are modeled as ProcessCapabilityAreaLeaf and ProcessCapabilityLevelLeaf. There are differences in terms of granularity among the original twenty-two process areas from CMMI-DEV, among the original forty-eight processes from ISO/IEC 15504-5, and between the two models as well. The Project Management process from ISO/IEC 15504-5 is similar to the set composed of two CMMI-DEV process areas: Project Management and Project Monitoring and Control. These two process areas have five specific goals. In order to make feasible the relationship among these two models, both, the ISO/IEC 15504-5 process and the pair of CMMI-DEV process area, are modeled as five ProcessCapabilityAreaLeafs. The forty-eight original ISO/IEC 15504-5 processes are covered by seventy-two ProcessCapabilityArea, and, the original twenty-two process areas of CMMI-DEV are covered by forty-eight ProcessCapabilityArea, with almost all of them already included in the seventy-two from ISO/IEC 15504-5.
2.3.4
The abstract class PracticeElement and its concrete subclasses ProcessOutcome, BasePractice, WorkProduct and Resources represent the elements of the original specific and generic goals of CMMI-DEV, composed of specific and generic practices and sub-practices and typical work products, and the original outcomes, base practices, work products and resources from ISO/IEC 15504-5.
The achievement of Goal G5 is evidenced by the class ProcessCapabilityModelElements as a collection of all elements. The reference to the elements is the only selfcontained reference and allows the reuse of each element in any model.
6. EVALUATION As an evaluation, the achievements of the five objectives goals are commented. The achievement of Goal G1 is evidenced by the modeling of CMMI-DEV and ISO/IEC 15504-5 models. The achievement of Goal G2 is evidenced by the number of key concepts. Seven explicit key CMMI-DEV concepts (process area, specific goal, process area category, process capability level, generic
7. RELATED AND FUTURE WORK Mappings, comparisons and harmonization among concepts and elements from Process Capability Models in general, and from a CMMI-DEV model and ISO/IEC 15504-5 model in particular, have been done elsewhere, as for example, by Lepasaar et al. [19], Alexandre and Habra [20] and Rout and Tuffley [21]. The iCMM and 177
in Proceedings of The Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE'08), pp. 173-178, San Francisco, CA, USA, July 1-3, 2008
thodology for Process Improvement (PRO2PI), in Proc. of The Fourth International SPICE Conference, Lisbon, Portugal, p. 77-84, April 28-29 (2004) 6 Salviano, C. F.: Uma proposta orientada a perfis de capacidade de processo para evolução da melhoria de processo de software (in Portuguese) (A proposal oriented by process capability profiles for the evolution of software process improvement), PhD thesis, FEEC Unicamp, Campinas, SP, Brazil (2006) 7 Salviano, C. F. and Jino, M.: Towards a {(Process Capability Profile)-Driven (Process Engineering)} as an Evolution of Software Process Improvement. In: EuroSPI Industrial Proc, Finland, p. 12.26-37 (2006) 8 Salviano, C. F.: Model-Driven Process Capability Engineering for Knowledge Working Intensive Organization, accepted for publication in The Eighth International SPICE Conference, Germany, May (2008) 9 Favre, J-M: Foundations of Model (Driven) (Reverse) Engineering: Models - Stories of The Fidus Papyrus and of The Solarus, www-adele.imag.fr/mda (2005) 10 Bézivin, J.: On The Unification Power of Models, in Software and System Modeling – SoSym, 4(2), p. 171-188 (2005) 11 Drucker, P.: Landmarks of Tomorrow - A Report on the New 'Post-Modern' World, Harper & Row, New York (1959) 12 Silva, J. L. da, Nabuco, O. F., Salviano, C. F., Reis, M. C., and Maciel Filho, R.: Strategic Management in University Research Laboratories, in Proc. Fourth International SPICE Conference, South Korea (2007) 13 Potts, C.: Software-Engineering Research Revised, IEEE Software, 10(5), pp. 19-28, Sep. (1998) 14 Eclipse Modeling Framework, at www.eclipse.org 15 TopCased plugin, http://www.topcased.org/ 16 Gamma, E., Helm, R., Johnson, R. and Vlissides, J.: Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley (1994) 17 Nascimento, M.: Geraes Album, EMI-ODEON(1977) 18 Salviano, C. F. and Figueiredo, A. M., Unified Basic Concepts of Capability Model for CMMI-DEV and ISO/IEC 15504-5 Models, CenPRA TecRep., (2008) 19 Lepasaar M., Mäkinen T., and Varkoi T.: Structural comparison of SPICE and continuous CMMI, In the Proc. of SPICE Conference, pp. 223-234, Italy (2002) 20 Alexandre, S., and Habra, N. UML modeling of five process maturity models. Tech. Rep. LQL-2003-TR02, CETIC-FUNDP, Charleroi-Namur (2003) 21 Rout, T. P., and Tuffley, A.: Harmonizing ISO/IEC 15504 and CMMI, in Software Process Improvement and Practice, 12(4), pp. 361-371 (2007) 22 Siviy, J. M. and Kirwan, P.: Process Improvement in Multimodel Environments: Past, Present, Future.
MR-MPS models combine elements from a CMMI model and ISO/IEC 15504-5 model. All of these related works address the goals G1 and G3, but they do not address the goals G2, G4 and G5. Siviy and Kirwan [22] present an initial reasoning framework for harmonizing process improvement efforts when multiple improvement technologies and models are in use. Geraes is a specific proposal, based in process capability, for that reasoning framework. As a future work, a phase 3 of the project is under way in which Geraes is under another revision in order to support the concepts of the other models listed in section 2. A preliminary analysis pointed out that most of these concepts are already supported. This revision is also a consolidation of the unified basic concepts as a complete formal specification and implementation Process Capability Profile Metamodel in order to define a consensual agreement on how elements of a process should be selected to produce a given Process Capability Profile. The concept of metamodel is used as proposed by Favre [9] and Bézivin [10]. 8. CONCLUSION This article proposes Geraes class diagram as a set of unified basic concepts for Process Capability Models, addressing the issue identified by Card [1]. The class diagram is evaluated against five defined goals, including the modeling of CMMI-DEV and ISO/IEC 15504-5 models. This proposal is part of an ongoing research effort to evolve the current SPI area towards MDPEK and PRO2PI. The class diagram helps the understanding the concepts of Process Capability Models independent of how a particular model implemented these concepts. This proposal is a relevant step towards a process capability profile metamodel that will support MDPEK and PRO2PI and therefore the consistent utilization of elements from multiple models to process improvement. ACKNOWLEDGMENTS The authors would like to thank all people from many projects and institutions and the anonymous reviewers for their comments and suggestions. REFERENCES 1 Card, D. N.: Research Directions in Software Process Improvement. In 28th IEEE International COMPSAC Conference, pp. 238--239, Hong Kong, China (2004) 2 Paulk, M. C., Weber, C. W., Curtis, B. and Chrissis, M. B.: The Capability Maturity Model, AddisonWesley, 441 pages (1994) 3 Chrissis, M. B., Konrad, M., Shrum, S.: CMMI: Guidelines for Process Integration and Product Improvement, 2nd Edition, Addison-Wesley (2007) 4 ISO/IEC, ISO/IEC 15504 - Information Technology Process Assessment – Part 5: An exemplar Process Assessment Model (2006) 5 Salviano, C. F., Jino, M., Mendes, M. J.: Towards an ISO/IEC 15504-Based Process Capability Profile Me-
Software Engineering Institute, Carnegie Mellon University, USA, slides presented at SEPG Conference (2008)
178
