A Domain Engineering Approach for Situational Method Engineering

Transcription

1 A Domain Engineering Approach for Situational Method Engineering Anat Aharoni and Iris Reinhartz-Berger Department of Management Information Systems, University of Haifa, Haifa 31905, Israel Abstract. Methodologies are one of the most significant key factors to the success of project development. Since there is no single methodology that can be uniquely pointed as the best", the discipline of situational method engineering (SME) promotes the idea of creating method components, rather than complete methodologies, and tailoring them to specific situations at hand. In this paper we present a holistic approach, called ADOM-SME, for representing method components and tailoring them into situational methodologies. This approach, whose roots are in the area of domain engineering (also known as product line engineering), supports specifying the five main methodological aspects (products, work units, stages, producers, and model units), as well as instantiating them into endeavour concepts, using a single frame of reference. Furthermore, the proposed approach enriches the standard metamodel for development methodologies, ISO/IEC 24744, by supporting the creation of valid situational methodologies and guiding their tailoring. Keywords: Method Engineering, Situational Method Engineering, Metamodeling, ISO/IEC 24744, Domain Engineering, Product Line Engineering. 1 Introduction The need for effective, appropriate, and flexible software development processes has increased as the complexity and variety of computer-based systems rose. Furthermore, the need to make method engineering more adaptable and flexible, taking into consideration organizational, technical, and human-related constraints and requirements, became important. The situational method engineering (SME) discipline [11, 15, 23] promotes the idea of creating method components rather than complete methodologies and tailoring them to specific situations at hand. Recently, efforts have been made for standardizing the area of (situational) method engineering, yielding the OPEN Process Framework (OPF) [21, 32], OMG's Software Process Engineering Metamodel (SPEM) [18], and ISO/IEC [5, 13]. ISO/IEC 24744, which is the most recent work and incorporates experience from earlier SME approaches, defines a metamodel for development methodologies. This standard refers to both methodologies and their instances (in the form of endeavours), as well as to five aspects of the modeled method components or methodologies: work units (the process aspect), work products (the artifact aspect), producers (the people aspect), stages (the temporal Q. Li et al. (Eds.): ER 2008, LNCS 5231, pp , Springer-Verlag Berlin Heidelberg 2008

2 456 A. Aharoni and I. Reinhartz-Berger aspect), and model units (the language aspect). All these aspects are described and specified using an object-oriented terminology, concentrating on the methodology structural aspects and paying less attention to the behavioral aspects. A designated graphical notation for ISO/IEC was proposed in [7]. This notation covers all concepts described by ISO/IEC 24744, but does not support the endeavour activities. This paper introduces an approach for representing methodologies and method components that also supports the integration and tailoring of method components into complete methodologies that best suit specific situations. This approach does not violate ISO/IEC 24744, but rather enriches it in order to support the creation of valid situational methodologies and guide their tailoring. It adapts a domain engineering approach, called Application-based DOmain Modeling (ADOM) [25, 30], to the special needs of the SME field. ADOM-SME is based on a three layered framework: application, domain, and language. The application layer includes the SME metamodel, which is a variation of that presented in ISO/IEC The domain layer includes the different method components and the developed situational methodologies. Finally, the language layer includes any modeling language that can be used for both describing metamodels and method component models. We chose to use Object- Process Methodology (OPM) [3] as the underlying language in this paper due to its balance treatment of structure and behavior specification, its formality (expressed through a metamodel [24]), and its accessibility to different types of users. OPM combines ideas from object-oriented and process-oriented approaches into a single frame of reference, enabling expression of mutual relationships and effects between objects and processes. Thus, ADOM-SME enables specifying in a single model work units, work products, producers, stages, and model units, as well as the structural and procedural relationships among them. The rest of the paper is organized as follow. Section 2 reviews recent works in the area of situational method engineering. Section 3 briefly describes ADOM and OPM, while Section 4 introduces and exemplifies the ADOM-SME approach and explains how it supports the different SME activities. Finally, Section 5 concludes and refers to future research plans. 2 Literature Review Situational Method Engineering (SME) [15, 23] deals with customizing and tailoring methodologies to specific situations. For this purpose, SME approaches treat methodologies as composed of method components, which are stored along with their usage features in method bases. Method engineers are responsible for searching, retrieving, and tailoring method components from those method bases according to the situations that they are facing. A situation in this context can be defined as a vector of characteristics that relate to the organization, the project, the developing team, the customer, etc. Two main aspects of method components and methodologies are structural (productrelated) and behavioral (process-related). Most of the current software development methodologies and a significant part of SME approaches focus on just a single aspect. The software process improvement community, centered on standards such as SPICE [12] and CMM [29], believes that these aspects are not completely separated and the quality of software products, for example, can be improved by improving the quality of

3 A Domain Engineering Approach for Situational Method Engineering 457 the processes that yield them [12]. Other approaches believe that complex systems cannot be viewed as predictable processes and, hence, they suggest concentrating on the products, which are changed less often. Gonzalez-Perez and Henderson-Sellers [6] further claim that products are more people-oriented and better at dynamically reorganizing the work to be done. Recently, more works have recognized the need to model both process and product aspects of methodologies. Some of them offer connection points for "plugging in" the complementary components, while others refer to the process and product aspects as elementary constituents of the approach. OMG's Software Process Engineering Metamodel (SPEM) [18], for example, is used for describing a concrete software development process or a family of related software development processes. Process enactment, i.e., planning and executing projects, is outside the scope of SPEM, although some examples of enactment are included for explanatory purposes. The OPEN Process Framework (OPF) [21, 32] is a free, public domain, industry-standard approach for the production of endeavor-specific development methods. It consists of a repository of reusable method components documented as hierarchical linked Web pages, including construction and usage guidelines. Its metamodel describes the organizational structure of the repository and includes six types of method components: Endeavor, Language, Producer, Stage, Work Product, and Work Unit. However, OPF mainly concentrates on the methodology layer at the expense of the endeavour layer and its relationships to the methodology layer. Recently, OPF's metamodel was reorganized to fit ISO/IEC OOSPICE [19] is an expansion of the Software Process Improvement and Capability determination (SPICE) approach that covers Component-based Development (CBD). OOSPICE refers only to the methodology layer and focuses on the processes, technology and quality concerns in component-based software development, neglecting the specification of structural and product aspects of methodologies. Its metamodel is directed at supporting the need for methodologies to be generated at various capability levels [8]. Incorporating experience from different works in the field, ISO/IEC [5, 13] defines a metamodel for development methodologies that refers to three modeling layers: metamodel, methodology, and endeavour. While the methodology layer is relevant to method engineers and includes models that are constrained and directed by the chosen metamodel, the endeavour layer is relevant to developers and includes models that are constrained and directed by the method in use. Instantiation relations (specified as belonging to the "powertype" class) are defined between these layers, such that an element in the endeavour (methodology) layer is a "powertype" instance of an element in the methodology (metamodel) layer. In particular, methodology elements are specialized into resources, which can be used as they are at the endeavour layer, and templates, which need to be instantiated at the endeavour layer. Five classes of templates and correspondingly five classes of endeavour elements are defined for representing work units, work products, producers, stages, and model units. All these concepts, including the behavioral ones such as work units and stages, are expressed via class diagrams (in UML notation), text tables, and a natural language, hurting the (semi-) formality of the methodology procedural aspects representation. The designated graphical notation for ISO/IEC that is proposed in [7] associates for each methodological concept a different symbol. Pre-conditions and post-conditions of actions are expressed as free textual expressions that are linked to

4 458 A. Aharoni and I. Reinhartz-Berger the corresponding action symbols. A methodology may be specified in this notation via several diagram types: lifecycle diagrams, which represent the overall structure of a method; enactment, which represent a specific enactment of a method and its relationship to the method specification; process diagrams, which describe the details of the processes used in a method; and action diagrams, which describe the usage interactions between tasks and work products. The notation specification does not explicitly refer to consistency issues between these types of diagrams. In particular, the same element can appear in several diagram types, playing different roles and exhibiting various (contradicting) features. Mirbel [16] divided SME approaches into three categories according to the different objectives they aim to achieve. The first category focuses on documenting the methodologies and their components (e.g., [22]). The second category deals with retrieving method components and evaluating their similitude (e.g., [2]). The focus of the third category is defining guidelines for reusing, tailoring, and customizing the different method components in daily developer tasks (e.g., [14]). Most SME approaches focus just on one activity, hence, belonging to a single SME category. OPF and SPEM, for example, mainly focus on the representation of method components. ISO/IEC also concentrates on the representation of method components, but provides implicit mechanisms for retrieving method components and basically tailoring them (e.g., the classes element kind, conglomerate, reference, and source). To summarize, the main shortcomings of existing SME approaches are: (1) supporting mainly the methodology layer, partially neglecting the endeavour layer which is needed for the developers who use situational methodologies, (2) using an objectoriented modeling language, specifying procedural aspects structurally, (3) applying multi-view approaches, potentially rising consistency problems, and (4) concentrating on just a single SME activity, making other activities more difficult and decreasing the ability for smooth transition between the different SME activities. The purpose of this paper is to present a holistic approach which overcomes these shortcomings without violating the ISO/IEC standard. 3 ADOM and OPM The Application-based DOmain Modeling (ADOM) approach [25, 30] aims at handling both reuse and validation of application models according to the domain knowledge. Its framework includes three layers: application, domain, and language. The application layer consists of models of particular applications, including their structure and behavior. The intermediate domain layer consists of specifications of various domains, i.e., families of applications that share common features as well as exhibit variability. Examples of domains that can be included in the domain layer are web applications, multi agent systems, and process control systems. The domain specifications capture the knowledge gained in specific domains in the form of concepts, features, and constraints. Finally, the language layer includes meta-models of modeling languages, such as UML. ADOM is a quite general approach and can be applied to different modeling languages. However, when applying ADOM to a specific modeling language, this language is used in both domain and application layers, easing the inter-layer tasks by employing the same terminology in both layers.

5 A Domain Engineering Approach for Situational Method Engineering 459 In the context of SME, development methodologies and processes can be considered as a domain. Thus, the application layer, which corresponds to the endeavour layer in ISO/IEC 24744, includes the different method components and the developed situational methodologies, while the domain layer, which corresponds to the methodology layer in ISO/IEC 24744, includes the SME metamodel. ADOM's reuse process is mainly done by configuration and specialization, such that the constraints enforced by the domain layer provide guidance to the reuse process and the development of models in the application layer. Configuration is the selection of a subset of existing elements from a domain model for the purpose of specifying a lawful specific application model. ISO/IEC refers to this type of operations through resources, which are methodology elements. Specialization, on the other hand, is the result of applying general knowledge derived from a domain model into a specific application model. In [28] five possible specialization operations are identified: refinement, sub-typing, contextual adoption, omission, and inclusion. ISO/IEC refers to this type of operations through templates, which are also methodology elements that are "powertype" instantiated by endeavour elements. The ADOM approach also explicitly enforces constraints among the different layers: the domain layer enforces constraints on the application layer, while the language layer enforces constraints on both the application and domain layers. Furthermore, as opposed to ISO/IEC 24744, the ADOM approach explicitly refers to validation issues and, in particular, whether an application model is considered as a valid instantiation of a domain model. More on this issue can be found at [25]. As noted, ADOM can be used with various modeling languages in order to support different development tasks, such as business modeling, requirement elicitation, and analysis and design. Indeed, the only requirement of ADOM from the associated modeling language is to have a classification mechanism that enables categorizing elements according to other elements (UML stereotypes are an example for such mechanism). However, ADOM promotes using the same modeling languages, techniques, and methods in both domain and application layers. The reasons for this are: (1) treating domain models similarly to application models utilizes to the fullest the expressiveness of the modeling language. In particular, it extends the ability to specify behavioral constraints or templates with respect to several domain analysis methods, and (2) using the same terminology in both layers makes the inter-layer tasks easier. In particular, the creation and validation of application models according to domain models in ADOM is quite straight-forward, consequently resulting in a more accessible approach for the developers and a simpler approach for tool developers. In this work we choose to use Object-Process Methodology (OPM) which supports the coexistence of structural and behavioral specifications in the same model, in order to support handling the five main methodological aspects presented by ISO/IEC 24744: product, process, producer, stage, and model unit. OPM [3] is a holistic approach to the modeling, study, development, and evolution of systems, supported by a CASE tool called OPCAT [20]. The main elements in OPM are entities and links. Entities generalize objects, processes, and states. Objects are things that exist, while processes are things that transform objects by creating or destroying them, or by changing their states. Two main features of OPM entities are affiliation, which determines whether the entity is systemic or external (environmental), and essence, which

6 460 A. Aharoni and I. Reinhartz-Berger determines whether the entity is physical or informational. Links, which connect entities (objects, processes, or states), can be structural or procedural. Structural links express static, structural relations between pairs of objects or processes. Aggregation, generalization, characterization, and instantiation are the four fundamental structural relations in OPM. General structural relations can take on any semantics, which is expressed textually by their user-defined tags. The behavior of a system is manifested in OPM in three major ways: (1) processes can transform (generate, consume, or change the state of) objects, (2) objects can enable processes without being transformed by them, and (3) objects can trigger events that (at least potentially, if preconditions are met) invoke processes. For each such way, different procedural links are defined. The complexity of an OPM model is controlled through three refinement/ abstraction processes, which enable the user to recursively specify and refine the system under development to any desired level of detail without losing legibility and comprehension of the complete system: in-zooming/out-zooming concentrates on behavioral and procedural refinement/abstraction, unfolding/folding focuses on structural refinement/abstraction, and state expressing/suppressing shows/hides the possible states of an object. These mechanisms enable smooth transition between the different development stages. Furthermore, a set of rules guarantees that the various diagrams in the same model are consistent with each other (these rules are enforced by OP- CAT). Soffer et al. [27] proved that OPM is ontologically complete according to the Bunge-Wand-Weber (BWW) evaluation framework, which aims to be a theoretical foundation for understanding the modeling of information systems. In OPM, each entity exhibits two additional features: role and multiplicity indicator. Like UML stereotypes, a role is a model entity whose information content and form are the same as those of the basic model entity, but its meaning and usage are different. Roles are used within an application model in order to associate an entity to its domain counterpart. They are recorded in the upper left corner of the entity frame. A special kind of role, called tailoring info, may appear in a domain model, indicating the tailoring information of the corresponding elements. As will be explained in Section 4, the tailoring info should get values in the application model rather than be specialized or configured and is used for retrieval purposes. As the number of tailoring info attributes may be very large, separate XML or SGML files can be maintained instead (or in addition to) the visual representation of the tailoring info in the domain models. The exact lists of features that characterize the different types of method components is derived from works that were done in the area of SME, such as [16, 17], from practitioners, and from the element kinds in ISO/IEC A multiplicity indicator, specified in the domain model, constrains the number of application elements that can be configured or specialized from the same domain element in any application in the domain. The multiplicity indicators of OPM entities (objects, processes, and states) are recorded in the lower right corner of their frame and is optionally many (0..m) by default, i.e., when not explicitly appear. The multiplicity indicators of links are specified closely to the link ends, similarly to cardinalities in application models, and they are mandatory single (1..1) by default, in order to preserve cardinality conventions from the application layer. Note that while link cardinality refers to the number of instantiations of a certain application concept in the data layer, multiplicity indicators of links refer to the number of instantiations of a certain domain concept (i.e., type) in the application layer.

7 A Domain Engineering Approach for Situational Method Engineering ADOM-SME and Its Supported Activities In this section, we explain how the different SME activities are supported in the ADOM-SME approach. Section 4.1 refers to the domain (methodology) layer, while Section 4.2 refers to the creation and representation of method components in the application (endeavour) layer. Finally, the retrieval and tailoring activities are the focus of Section The Methodology Layer in ADOM-SME Fig. 1 is the top-level diagram in the domain (methodology) layer of ADOM-SME. It includes the five methodological aspects mentioned in ISO/IEC However, as opposed to ISO/IEC where all these concepts are represented by object classes, work units and stages are represented in the proposed approach as process classes, emphasizing their procedural and behavioral nature. Due to the OPM ability to characterize objects by processes and processes by objects, one can specify the behavior of objects and associate informational features to processes. Furthermore, as opposed to work products and model units that are systemic (internal) and informational objects, producers are environmental (external) and physical objects that represent human stakeholders or groups of such. Similarly to the "actiontype" class in ISO/IEC 24744, ADOM-SME has means for expressing the relationships between processes and products: if a process creates a product than a result link connects them, if a process modifies a product than an effect link connects them, and if a process only reads a product than an instrument link connects them. However, the expressive of ADOM- SME goes beyond that of ISO/IEC in representing other relationships between the different concepts: a process can consume (destroy) a product, a product or a producer can trigger a process, and a process (product) can consist of other processes (products). Pre-conditions and post-conditions are expressed as objects (possibly in specific states) that are linked via in-coming or out-going links to processes. Partial Legend: informative, systemic object physical, environmental object process state generalization link characterization link aggregation link bi-directional structural link agent link instrument link effect link consumption/result link "or" relaionship Fig. 1. The top level domain (methodology) model in ADOM-SME

8 462 A. Aharoni and I. Reinhartz-Berger Due to space limitations, we concentrate here on the procedural aspects of the methodology which ADOM-SME uniquely treats, namely work units and stages. A work unit may be triggered by producers and use model units in order to affect (create, destroy, or modify) work products. Unfolding the work unit concept, Fig. 2 shows three specializations of work units: process, task, and technique. A process is a largegrained work unit operating within a given area of expertise. Tasks and techniques are small-grained work units: tasks focus on what must be done in order to achieve given purposes, and techniques refer to how to achieve these purposes. A process consists of (sub-) processes or tasks, and a technique may be mandatory, recommended, discourage, forbidden, or optional for a certain task [9]. Each work unit may need to save different types of statuses and periods. This is modeled in the domain (methodology) layer as two (mandatory many) attributes that a work unit should exhibit. In addition, work units exhibit four tailoring info attributes: Min Capability Level, which refers to the minimal requirements for the maturity of the organization regarding the performance of a given work unit; Unit Source, which indicates the methodologies from which the work unit is derived, Project Duration, which specifies the duration of projects to which the given work unit is suitable; and Flexibility to Changes, which specifies the forgivingness of the given work unit to frequent client changes. For clarity purposes, the tailoring info attributes are grayed, separating them from "regular" attributes in the methodology layer. In ISO/IEC 24744, stages are used for specifying the temporal aspect of methodologies and method components. Stages are divided into stages with duration, which are managed intervals of time within endeavours, and instantaneous stages, which are managed points in time within endeavours. We extend this usage in order to support tailoring of several work units into more meaningful method components. In other words, stages include different work units and guide their execution. Four common ways to tailor work units are sequentially, concurrently, incrementally, and iteratively. Fig. 3 exemplifies concurrent stages, in which the work units are executed independently and/or in parallel, and iterative stages, in which single work units are executed several times in order to improve the created work products. Both stages are Fig. 2. Unfolding the work unit concept in the domain (methodology) layer of ADOM-SME

9 A Domain Engineering Approach for Situational Method Engineering 463 (a) (b) Fig. 3. (a) Zooming into a concurrent stage. (b) Zooming into an iterative stage. specializations of the Stage concept. Note that in OPM the vertical axis within an inzoomed process defines the execution order: the sub-processes of a sequential process are depicted in the in-zoomed frame of the process stacked on top of each other with the earlier process on top of a later one, while sub-processes of a parallel process appear side by side, at the same height. 4.2 The Endeavour Layer in ADOM-SME In the application layer of ADOM-SME, the different (specific) method components and situational methodologies are specified, using the domain model terminology, rules, and constraints. For this purpose, each element in an application (endeavour) model is associated with domain (methodology) elements as its roles, such that an application element has to fulfill all the constraints induced by its associated roles (domain elements) in the domain layer. Furthermore, all the tailoring info attributes of a domain element have to get values (in the form of states) in the corresponding instantiated application elements. Fig. 4 demonstrates an endeavour method component taken from RUP [26]. All the roles of systemic, informational objects in these figures are specializations of work products as specified in the methodology layer. Fig. 4 (a) zooms into the "Requirement Extraction" process, modeling its conventions, documents, required participants, and the main tasks. Fig. 4 (b) unfolds the task called "obtain an understanding of the domain" to show its recommended and optional techniques. Finally, Fig. 4(c) specifies the situations to which the requirement extraction process is suitable: the organization capability level is at least 2, the project duration is at least one year, and the flexibility to changes is low. The unit source of this component is RUP. 4.3 Retrieving and Tailoring Method Components in ADOM-SME As noted, in the domain layer of ADOM-SME, the different methodological concepts exhibit tailoring info attributes which are instantiated in the application (endeavour) layer, specifying the exact situations (or ranges of situations) to which a given method component suits. The requirement extraction process from Fig. 4, for example, is suitable for CMMI requirements for Maturity Level of at least 2 [10], for customers who do not impose changes frequently, and for projects that are planned to be developed more than one year.

10 464 A. Aharoni and I. Reinhartz-Berger (a) (b) (c) Fig. 4. (a) The "Requirement Extraction" process in-zoomed. (b) The "Obtain an Understanding of the Domain" task unfolded, showing its recommended and optional techniques. (c) The "Requirement Extraction" process unfolded, showing its tailoring info. For carrying out the retrieval and tailoring activities, we treat the different method components as semantic Web services. Their inputs, outputs, pre- and post-conditions, and triggers are automatically translated to OWL-S [1], while the methodology layer serves as their ontology. Current semantic web services discovery solutions were developed in the context of automatic service composition. Thus, the client of the discovery procedure is an automated computer program rather than a human, with little tolerance, if any, to inexact results. However, in our case, method components which might be semantically distanced from each other can be manually glued by method engineers. Hence, we chose to use a semantic approach to approximate service retrieval, called OPOSSUM [31]. OPOSSUM's model relies on a simple and extensible keyword-based query language, and enables efficient retrieval of approximate results, including approximate service compositions. In order to retrieve compositions that contain method components from different methodologies, dependencies between method components are to be inferred. OPOSSUM treats two types of inferring dependencies between Web services (method components in our case): flow and empirical. Two method components q and p are flow-dependent if the output of q can be used as an input of p. Note

11 A Domain Engineering Approach for Situational Method Engineering 465 that the ontology (i.e., the domain model) is used for helping the tool find "correct" input-output matches. Parameter relaxation, concept hierarchy relaxation, instance relaxation, and property relaxation are used for inferring flow dependencies. Empirical dependencies are used when prior knowledge of relations between Web services exists. In particular, we can infer empirical dependencies from stages in the method base that integrate different work units. OPOSSUM handles the following constructs for inferring empirical dependencies: sequence, if-then-else, repeat-until, split, and split+join. When working with OPOSSUM, the method engineers define queries that specify the situations to which methodologies have to be created: the different types of tailoring info attributes are presented to the method engineers and they need to choose the relevant characteristics and their suitable values. Furthermore, the method engineers can decide whether the tailoring info will be checked for every method component or for complete compositions using aggregated functions, such as min, max, sum, avg, and count. The method base is first searched for method components that satisfy the component-related tailoring info conditions. Then, OPOSSUM runs on the retrieved (a) (b) Fig. 5. (a) The "Iterative Requirement Extraction" stage. (b) The "Requirement Extraction while On Site Customer" stage.

12 466 A. Aharoni and I. Reinhartz-Berger method components, yielding a ranked list of possible compositions. These compositions are presented to the method engineers as stages that tailor the different work units. The sequence construct, for example, is represented by the sequential stage, the split+join construct is represented by the concurrent stage, and the repeat-until construct is represented by the incremental or iterative stages, depending on the resolution of the work products that it modifies. Fig. 5 exemplifies two tailoring results: in Fig. 5 (a) the "Requirement Extraction" process is tailored iteratively since this process appears so in the context of other methodologies, such as RUP, causing OPOS- SUM infer an empirical dependency between an iterative stage and the requirement extraction process. In Fig. 5 (b), the same process is tailored concurrently to the "On Site Customer" work unit, taken from XP [4]. These components are tailored in parallel due to the absence of matching between their inputs and outputs. Note that the similar triggers and effects of these work units (e.g., Client and Contract) are percolated to the wrapping stage "Requirement Extraction while On Site Customer", improving the model readability. In both figures, the "signature" of the requirement extraction process is the same and is achieved by out-zooming Fig 4 (a). After yielding the ranked list of compositions from OPOSSUM, compositions that violate the composition-related tailoring info are removed. The method engineer, for example, may require getting compositions in which the maximal project duration of their work units is 10 years. Compositions that violate this constraint are removed at this step. 5 Conclusions and Future Work As there is no single universally applicable development methodology, the importance of SME approaches that support representing, retrieving, and tailoring method components to given situations has been increased. The proposed holistic ADOM- SME approach, whose roots are in domain engineering, overcomes several main shortcomings of existing SME approaches. First, ADOM-SME enables specifying both structural and behavioral aspects of the method components, as well as expressing the relationships between them. Second, the tailoring info attributes, defined in the methodology layer and used in the endeavour layer, support defining situations to which a specific method component suits, while the stage concept provides ways to tailor method components. Third, using OPOSSUM, approximate method component compositions are achieved, enabling the method engineer manually gluing and developing the missing parts. Finally, the ADOM-SME approach is supported by a case tool that helps maintaining the diagrams consistent and enables validating the endeavour models against the methodology models. As for the future, we plan to extend the repository of method components with methodologies from the literature and from the industry. We further plan to improve and empirically test the tailoring activity. Currently OPOSSUM treats the method components as close boxes (services) and does not refer to their inner structure and behavior. Looking into the method components may enable other, more sophisticated tailoring options. These options and their suitability to different situations will be questioned with experts and practitioners.

13 A Domain Engineering Approach for Situational Method Engineering 467 References 1. Ankolekar, A., Martin, D.L., Zeng, H.J.R., Sycara, K., Burstein, P.M., Lassila, O., Mcilraith, S.A., Narayanan, S., Payne: DAML-S: Semantic markup for web services. In: Proceedings of the International Semantic Web Workshop (SWWS), pp (2001) 2. Brinkkemper, S., Saeki, M., Harmsen, F.: Assembly techniques for method engineering. In: Pernici, B., Thanos, C. (eds.) CAiSE LNCS, vol. 1413, pp Springer, Heidelberg (1998) 3. Dori, D.: Object-Process Methodology A Holistic System Paradigm. Springer, Heidelberg (2002) 4. Extreme Programming Web Site (2006), 5. Gonzalez-Perez, C.: Supporting Situational Method Engineering with ISO/IEC and the Work Product Pool Approach. In: Proceedings on Situational Method Engineering: Fundamentals and Experiences, pp (2007) 6. Gonzalez-Perez, C., Henderson-Sellers, B.: A work product pool approach to methodology specification and enactment. J. Syst. Software (2007), doi: /j.jss Gonzalez-Perez, C., Henderson-Sellers, B.: Notation for ISO/IEC 24744, 07N3781%20MOS-006%20ISO_IEC% %20Notation% 20-%20NWI%20Form%20V1.0.pdf 8. Gonzalez-Perez, C., McBride, T., Henderson-Sellers, B.: A metamodel for assessable software development methodologies. Software Qual. J (in press, 2004) 9. Graham, I., Henderson-Sellers, B., Younessi, H.: The OPEN Process Specification. Addison-Wesley, Reading (1997) 10. Grundmann, M.: A CMMI Maturity Level 2 assessment of RUP, Henderson-Sellers, B.: SPI A Role for Method Engineering. In: Proceedings of the 32nd EUROMICRO Conference on Software Engineering and Advanced Applications (2006) 12. Humphrey, W.S.: Managing the Software Process. MA.ISO/IEC, ISO/IEC Software Process Assessment Part 1: Concepts and Vocabulary. Addison-Wesley, Reading (1989) 13. ISO/IEC. ISO/IEC 24744, Software Engineering Metamodel for Development Methodologies, 1st edn. (2007) 14. Mirbel, I., de Rivieres, V.: Adapting Analysis and Design to Software Context: the JECKO Approach. In: Bellahsène, Z., Patel, D., Rolland, C. (eds.) OOIS LNCS, vol. 2425, pp Springer, Heidelberg (2002) 15. Mirbel, I., Ralyté, J.: Situational method engineering: combining assembly-based and roadmap-driven approaches. Requirements Engineering 11(1), (2006) 16. Mirbel, I.: Rethinking ISD methods: Fitting project team members profiles. I3S technical report I3S/RR FR (2004), Mirbel, I.: Method chunk federation (2006), OMG, Software Process Engineering Metamodel Specification, Version 1.1 (2005), OOSPICE, OPCAT inc. OPCAT web site, OPEN Process Framework (OPF) Web Site,

14 468 A. Aharoni and I. Reinhartz-Berger 22. Punter, H.T., Lemmen, K.: The MEMA-model: towards a new approach for Method Engineering. Information and Software Technology 38(4), (1996) 23. Ralyté, J., Deneckere, R., Rolland, C.: Towards a generic model for situational method engineering. In: Eder, J., Missikoff, M. (eds.) CAiSE LNCS, vol. 2681, pp Springer, Heidelberg (2003) 24. Reinhartz-Berger, I., Dori, D.: A Reflective Metamodel of Object-Process Methodology: The System Modeling Building Blocks. In: Green, P., Rosemann, M. (eds.) Business Systems Analysis with Ontologies, pp Idea Group, Hershey (2005) 25. Reinhartz-Berger, I., Sturm, A.: Enhancing UML Models: A Domain Analysis Approach. Journal on Database Management (JDM) 19(1), (2007); special issue on UML Topics 26. Schach, S.R.: An Introduction to Object-Oriented Analysis and Design with UML and the Unified Process. McGraw-Hill/Irwin (2004) 27. Soffer, P., Golany, B., Dori, D., Wand, Y.: Modelling Off-the-Shelf Information Systems Requirements: An Ontological Approach. Requirements Engineering 6(3), (2001) 28. Soffer, P., Reinhartz-Berger, I., Sturm, A.: Facilitating Reuse by Specialization of Reference Models for Business Process Design. In: The 8th Workshop on Business Process Modeling, Development, and Support (BPMDS 2007), in conjunction with CAiSE 2007 (2007) 29. Software Engineering Institute, CMMI-SE/SW/IPPD/SS, V1.1, Continuous. CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development/Supplier Sourcing, Continuous Representation, version 1.1 (2002) 30. Sturm, A., Reinhartz-Berger, I.: Applying the Application-based Domain Modeling Approach to UML Structural Views. In: Atzeni, P., Chu, W., Lu, H., Zhou, S., Ling, T.-W. (eds.) ER LNCS, vol. 3288, pp Springer, Heidelberg (2004) 31. Toch, E., Gal, A., Reinhartz-Berger, I., Dori, D.: A Semantic Approach to Approximate Service Retrieval. ACM Transactions on Internet Technology 8(1) (2007), OPOSSUM is available at: Zowghi1, D., Firesmith, D.G., Henderson-Sellers, B.: Using the OPEN Process Framework to Produce a Situation-Specific Requirements Engineering Method. In: Proceedings of SREP 2005, pp (2005)