A Comparison of the Essence 1.0 and SPEM 2.0 Specifications for Software Engineering Methods

Transcription

1 A Comparison of the Essence 1.0 and SPEM 2.0 Specifications for Software Engineering Methods Brian Elvesæter SINTEF ICT P. O. Box 124 Blindern N-0314 Oslo, Norway Gorka Benguria TECNALIA R&I Ed 202, Zamudio Spain Sylvia Ilieva IICT-BAS, acad. G. Bonchev str., bl. 25A Sofia 1113, Bulgaria ABSTRACT In this paper we present a comparison of the draft Essence 1.0 and Software & Systems Process Engineering Metamodel (SPEM) 2.0 specifications for software engineering methods from the Object Management Group (OMG). The comparison is based on results from the REMICS research project where we are defining an agile methodology for model-driven modernization of legacy applications to service clouds. The initial REMICS Methodology was defined using SPEM. Selected parts of the methodology are now being redefined in Essence to evaluate its applicability, in particular its promise of better support for definition of agile practices and method enactment compared to SPEM. The comparison shows that there are similarities in the authoring capabilities provided by the two specifications, but that there are key differences in the method architecture with respect to support for enactment. Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Languages, Methodologies. D.2.2 [Design Tools and Techniques]: Computer-aided software engineering (CASE). D.2.9 [Management]: Software process models. General Terms Design, Standardization, Languages, Theory. Keywords Software Engineering, Method Engineering, Method, Practice, SPEM, Essence. 1. INTRODUCTION The REMICS research project aims to develop a tool-supported agile methodology for model-driven modernization of legacy applications to service clouds. The agile REMICS Methodology [1-3] has been developed using the Eclipse Process Framework (EPF) that complies with the Software & Systems Process Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PMDE 2013, July 1, 2013, Montpellier, France. Copyright 2013 ACM /00/0010 $ Engineering Metamodel (SPEM) 2.0 specification [4]. The REMICS project has participated in the Software Engineering Method and Theory (SEMAT) initiative [5, 6] that has fronted a new specification named "Essence Kernel and Language for Software Engineering Methods" [7] as a response to the Request for Proposal (RFP) "A Foundation for the Agile Creation and Enactment of Software Engineering Methods" [8] issued by the Object Management Group (OMG). In March 2013 the Essence specification was officially endorsed by the OMG and is now undergoing finalization towards an official version 1.0 to be adopted. The Essence specification promises better support for definition of agile practices and method enactment compared to the SPEM specification. We are currently evaluating the applicability of the Essence specification with respect to updating parts of the agile REMICS Methodology. Based on this work, we present in this paper a comparison of the draft Essence 1.0 and SPEM 2.0 specifications for software engineering methods. The remainder of this paper is structured as follows: In Section 2 we give an overview and compare the main language concepts in the SPEM 2.0 and the draft Essence 1.0 specifications. Section 3 introduces our illustrative example based on Scrum [9] which is an agile software development practice used in the REMICS Methodology. In Section 4 we present the method authoring capabilities and in Section 5 we present the enactment capabilities defined in the two specifications. Section 6 provides a comparison and discussion of the capabilities of the two languages. Section 7 provides background on related work. Finally, Section 8 concludes this paper and gives directions for future research. 2. MAIN LANGUAGE CONCEPTS The Essence specification introduces a method architecture that distinguishes between kernels, practices and methods. A kernel provides a stripped-down, light-weight model of the essential aspects of software engineering. A practice is description of how to handle a specific aspect of a software engineering endeavour, e.g. User Stories [10] for requirements specification and Scrum for agile project management. The kernel is extended with practices that provide specific guidance to form a method suitable for the software endeavour and the needs of the development team. Below we present the main language concepts defined in the SPEM and Essence specifications according to this method architecture. Figure 1 shows the key language concepts defined in the SPEM specification. SPEM differentiates between method content and process content. Method content concepts such as Task, Work

2 Product and Role are used to define reusable descriptions that can be incorporated into several processes. The corresponding elements in the process content, i.e. Task Descriptor, Work Product Descriptor and Role Descriptor, are basically copies that contain the information from the method content counterparts, but can be locally adapted as part of the process description. The process content also includes Activity, Capability Pattern and Delivery Process that can be used to organize and define work breakdown structures and reusable process patterns. The method content includes Category that can be used to define custom categories, e.g. Discipline to categorize tasks and Tool to categorize tool-specific guidance. The Guidance concept can be used to define specific guidance types, e.g. Roadmap, Template, Checklist and Tool Mentor that can be associated with both method and process content. Practice is a special guidance kind for organizing elements that belong to the same practice. Kernel Content Alpha Alpha State < has targets > Kernel Activity Space < evidences organizes > Practice Content Work Product Activity Practice produces / updates > < helps create < qualify responsibilities Template Team Role Method Content Work Product Process Content Work Product Descriptor Competency Resource Pattern Example Resource and Pattern Figure 2. Overview of key language concepts in Essence Task < input > output Kernel Elements Standard Categories (subset) Standard Guidance Types (subset) Category Discipline Practice Role Tool Roadmap Guidance Role Descriptor Delivery Process Template Activity Checklist < input > output Task Descriptor Capability Pattern Tool Mentor Figure 1. Overview of key language concepts in SPEM Figure 2 shows the key language concepts defined in the Essence specification. A Kernel is expressed using the concepts Alpha, Activity Space and Competency. Alphas represent things to work with and have Alpha States to track their progress. Alphas can be seen as placeholders for Work Products. Activity Spaces represent things to do and can be seen as placeholders for Activities. Competencies represent skill sets. A Practice adds specific details by defining Work Products and Activities, but can also introduce new Alphas, Activity Spaces and Competencies. The language also include Resource to model different resource kinds, e.g. Template, and Pattern to model generic or specific patterns, e.g. Team Role. 3. ILLUSTRATIVE EXAMPLE SCRUM The initial release of the REMICS Methodology was not very agile and followed a more traditional software development approach. For the second release of the REMICS Methodology a particular implementation of Scrum [9], incorporating Scrum roles (i.e. Product Owner, Scrum Master, Scrum Team and Development Team), Scrum events (i.e. Sprint, Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective) and Scrum artefacts (i.e. Product Backlog, Sprint Backlog and Increment) were introduced to make it more agile. Scrum can be seen as an iterative and incremental software development practice where each iteration defines a Sprint that results in an incremental update of a potential shippable product. The REMICS Methodology defines Modernization Sprints (see Figure 3) that provide guidance on model-driven modernization of legacy applications to service clouds. Figure 3. Modernization Sprints and Scrum types According to the Scrum Guide [9], the Scrum practice is best suited for small development teams consisting of three to nine members. In order to scale the REMICS Methodology for large modernization projects, the methodology can be adjusted following a "Scrum of Scrums" approach by defining a number of Modernization Scrum types. Each Scrum type defines Sprint types with particular activities based on the initial REMICS Methodology activity areas (see Figure 3). The five Modernization Scrum types are Requirements (RqS), Recovery (RcS), Migration (MgS), Validation (VdS) and Supervise (SpS).

3 Different Scrum team types are associated with each Sprint type depending on the required skills for the particular Sprint type. Teams are self-organizing but with a certain degree of specialization due to the diverse and not so common skills needed for activities in the Sprint types. The Scrum team types integrate the Whole Team technique of XP as well. The Whole Team technique includes strategies to increase overall productivity through streamlining the organization structure of the team and through streamlining collaboration within the team. In addition to the Scrum types, a number of agile development techniques (e.g. modelling by two, pair modelling and continuous modelling), have been adopted and adjusted for the extensively used model-driven engineering activities in the REMICS project. The REMICS Methodology has been developed using the EPF Composer (EPFC) tool ( and is hosted as an EPF Wiki ( Further details of the agile REMICS Methodology are presented in [1-3]. In this paper we use the original Scrum practice as described in the Scrum Guide [9], which applies to each of the Modernization Sprints or Scrum types in the agile REMICS Methodology, as an illustrative example. We compare how the Scrum practice can be defined according to SPEM using the EPFC tool and how the practice can be defined according to Essence using the EssWork Practice Workbench (EWPW) tool ( The EWPW is a prototype tool that is currently being developed at Ivar Jacobson International as evidence of tool vendor support for the adoption of the Essence specification. 4. AUTHORING 4.1 Different Kernel Starting Points The SPEM specification does not include a standard kernel as specified in Essence. However, a kernel based on the OpenUP process is available as part of the EPF library ( The OpenUP library contains a core set of method plugins (see Figure 4) which define a kernel. The OpenUP kernel uses language concepts from the method content of SPEM and defines specific role types (e.g. analyst, architect, developer, project manager, stakeholder and tester) and discipline categories (e.g. requirements, architecture, development, testing, deployment and project management). The role types and disciplines can be used as a structural starting point for adding practices to your method and to categorize the content of the practices that are composed. While the OpenUP kernel is proprietary, the Essence specification defines a standard kernel. The Essence kernel, available as a download for the EssWork Practice Workbench, is packaged as a Practice Workbench project (see Figure 5). The Essence kernel claims to be practice-agnostic as it does not contain any specific guidance but only general checklists. The Essence kernel is defined using the concepts Alpha to define things to work with (i.e. Opportunity, Requirements, Software System, Stakeholders, Team, Way of Working and Work), Activity Spaces to define things to do (e.g. Shape the System, Implement the System, Test the System, Deploy the System, Prepare to do the Work, Coordinate Activity and Support the Team) and Competency to define skill sets (i.e. Analysis, Development, Leadership, Management, Stakeholder Representation and Testing). Figure 4. OpenUP kernel in EPFC Figure 5. Essence kernel in EWPW

4 The kernel representation in EPFC and EWPW provides a very different starting point as a baseline for defining your practice. In the following two sections we elaborate on how to define the Scrum practice in EPFC and EWPW following the SPEM and Essence specifications accordingly. 4.2 Scrum Represented in SPEM (EPFC) The predefined role types and categories in the OpenUP kernel are quite separated from the definition of the Scrum practice. This allows us the choice of following a top-down or bottom-up approach to define the practice as an independent reusable asset and associate it with the kernel elements through the variability mechanisms defined in the SPEM specification, e.g. contributes to which adds details to an already defined element and replaces which replaces and a predefined element with your own. Figure 6 shows the representation of the Scrum practice in EPFC with defined Scrum roles, tasks and work products. The tasks defined in the Scrum practice are categorized as project management tasks which contributes to the discipline Project Management defined in the OpenUP kernel. Figure 7. Activity detail diagram The roles, tasks and work products contain descriptive guidelines and can be associated with additional guidance elements. The Scrum practice itself is defined as a special Practice guidance element that references all method and process content that should be included as part of the practice (see Figure 8). Figure 8. The Scrum practice guidance element in EPFC The Sprint itself can be defined as a capability pattern that sequences the Scrum tasks. Figure 9 shows the activity diagram (created in EPFC) for the Sprint capability pattern. The tasks shown are actually task descriptors that correspond to the tasks defined in the method content. Figure 6. Scrum practice structure represented in EPFC The Scrum roles are related to work products through the responsible for association and to tasks through the primary performer or additional performer association. Tasks are related to work products through the mandatory input, optional input and output association. Figure 7 shows a partial view of an activity detail diagram (created in EPFC) that graphically illustrates that the Development Team is the primary performer of the Daily Scrum, which has the Sprint Backlog and the defined Sprint Goal as inputs, and that the output is an updated Sprint Backlog. Figure 9. Sprint activity diagram

5 4.3 Scrum Represented in Essence (EWPW) In order to define a practice utilizing the full language capabilities of the Essence language, knowledge of the Essence kernel is required. In this paper we only present a subset of the Essence kernel necessary to illustrate the principles. Figure 10 shows a subset of the alphas and activity spaces defined in the Essence kernel [7] that we use to describe the Scrum practice. The kernel defines a small set of universal alpha elements such as Requirements, Software System, Work and Team, and their relationships, and activity spaces for the endeavour such as Prepare to do the Work, Support the Team and Stop the Work. The relationships between the alphas and the activity spaces are also defined as part of the kernel. The alphas have predefined states and the activity spaces have completion criteria that relate to specific alpha states. For instance the activity space Prepare do to the Work has Team::Seeded, Work::Initiated and Work::Prepared as completion criteria. This implies that the practice author should place activities in this particular activity space that provides specific guidance on how to achieve these alpha states. Requirements < fulfils Software System < scope and constrain produces > Work Prepare to do the Work < performs and plans Support the Team Team Track Progress Figure 10. Subset of the Essence kernel Figure 11 shows the representation of the Scrum practice in EWPW. The Scrum practice populates the alphas of the kernel (i.e. placing Product Backlog in Requirements, placing Increment in Software System and placing Sprint sub-alpha in Work) and the activity spaces of the kernel (i.e. placing Sprint Planning Meeting in Prepare to do the Work, placing Sprint Retrospective in Support the Team, and placing Daily Scrum and Sprint Review in Track Progress). The practice also introduces the Scrum roles as patterns. Figure 11. Scrum practice structure represented in EWPW Let us look closer at the representation of a Sprint. Sprint is defined as a sub-alpha of Work. Figure 12 shows the alpha card for Work and the state card for the state Seeded according to the card layout defined in the Essence specification. Each of the states has its corresponding state card that contains its checkpoints. A checkpoint describes the entry criteria for entering a specific state of the alpha and can be used to measure the progress of the alpha in the software endeavour. Checkpoints are typically expressed in natural language and provide a basis for generation of descriptive checklists items that are interpreted by the practitioners. Figure 12. Alpha card for Work and state card for Seeded

6 As can be seen from the practice structure in Figure 11 we extend the Work alpha with a new sub-alpha Sprint. The Work alpha is typically used for the duration of a development project that may cover a number of sprints. The Sprint has its own states (see Figure 13). Scrum comes with its own specific set of rules that should be defined as part of the practice. These rules can be defined as checkpoints associated with the appropriate states. The state card in Figure 13 shows the Scrum-specific checkpoints for when a Sprint is in the Planned state. with the Requirements alpha, Increment is associated with Software System and Sprint Backlog is associated with Sprint. In comparison with SPEM, the Essence specification does not define role as a language concept. One way to represent a role in Essence is to define a pattern. Thus, for each of the Scrum roles we defined a specific pattern (see Figure 15). These patterns can be attached to any elements, e.g. the Scrum Team can be attached to the Team alpha and the other Scrum roles can be attached to a Team Member (see Section 5 for further details). Figure 15. Specification of Scum roles in EWPW Figure 13. Alpha card for Sprint and state card for Planned The Scrum events (except Sprint which is represented as an alpha) are represented as activities. Figure 14 shows the activity card for the Sprint Planning Meeting activity. Activities are associated with alphas through an alpha input property specified on the activity. In Figure 14 the Requirements alpha is specified as an input as it contains the Product Backlog required to plan the Sprint. Activities have completion criteria that can either specify the creation or update of a work product or the state to be reached on an alpha. In Figure 14 the activity has an alpha completion criterion specifying that the activity contains specific guidance on how to achieve the Planned state of the Sprint, which also implicitly makes the Sprint an output of the activity. Similar activity definitions are also created for the other Scrum events. 5. ENACTMENT Enactment is the act of applying a specific method or methodology for a particular purpose, e.g. a software modernization project following the processes described in the REMICS Methodology. The EPF Composer tool allows us to publish the methodology content as an EPF Wiki where the practitioners can browse, read and potentially modify the online guidance. Figure 16 shows the lifecycle delivery process of the REMICS Methodology in the EPF Wiki. The EPF Wiki can be seen as an online user guide, but assignment of tasks and monitoring of progress are not supported. According to Section 16 in the SPEM 2.0 specification [4], enacting SPEM processes are typically done through mappings, e.g. to project planning tools or workflow engines such as Rational Team Concert ( The Sprint Planning Meeting takes Requirements as an input The Sprint Planning Meeting activity provides guidance on how to achieve the Planned state of the Sprint. Figure 14. Activity card for Sprint Planning Meeting The Scrum artefacts are represented as work products associated with the appropriate alphas, i.e. Product Backlog is associated Figure 16. Lifecycle delivery process in the EPF Wiki

7 The process capabilities of SPEM allows us to define work breakdown structures, but according to [11, 12] the language architecture itself lacks built-in enactment capabilities. Moreover, agile approaches such as Scrum tend to downplay strict work breakdown structures and assignments of tasks. Tasks in the Sprint Backlog can be dynamic as they are estimated and broken down into suitable units of work, team members sign up for rather than being assigned tasks, and any team member can modify the Sprint Backlog, etc. This fits well with the fact that software development is a creative process and most of the progress within the software development endeavour is done by human agents [13]. Thus, process enactment of software engineering methods must acknowledge the human knowledge worker and provide means of monitoring and progressing the software endeavour through human agents first and automation second. Enactment may be partially supported by method repositories and process engines that are linked to tools such as project management and issue tracking systems. The dynamics semantics of the Essence language specifies domain classes for instantiating alphas, alpha states and work products as well as operations for generating guidance based on alphas and alpha states to support enactment. For example, assuming that the Sprint is in the Planned state, a list of activities that progress the Sprint to a specific target state e.g. Concluded can be generated. The alpha can be instantiated and used on a particular endeavour, it has states that can be tracked, and the dynamic semantics can be partially formalized and implemented in tools. The alphas defined in the Essence kernel can be viewed as top-level alphas of which there are only a few, e.g. Work, and the practices add sub-alphas, e.g. Sprint that divides the work into smaller units. Using the checkpoints of the alphas it is at the discretion of the team to decide when a state change has occurred. Figure 17 shows an alpha card for a particular Sprint instance which is in the Under Control state. Figure 18. Task management kernel extension in EWPW By applying the optional Task Management Extension, tooling that supports the Essence specification can populate teams with actual team members (each having their corresponding Team Member alpha instance representation) and actual tasks (represented by instances of the Task alpha) which can be monitored and progressed. Alpha instances can be associated with each other during the enactment to represent a specific team member signing up to a specific task, and patterns such as the Scrum roles can be applied to the appropriate team members. Figure 19 shows the alpha cards for Team Member and Task. Figure 17. Sprint in the Under Control state However, the Sprint alpha is still not at a suitable granularity as a means of defining tasks that team members can sign up for. The Essence specification acknowledges this and specifies optional kernel extensions. The Task Management Extension provides three additional alphas, i.e., Team Member, Practice Adoption and Task, to allow development teams to detail and progress the Team, Way of Working and Work alphas respectively. Figure 18 shows the three additional alphas and their defined states in the EWPW tool. Figure 19. Alpha cards for Team Member and Task The Practice Adoption sub-alpha has been included in the extensions as a means to monitor and assess the adoption of a practice itself, e.g. Scrum, since teams improve their way of working by adopting and adapting individual practices. For instance, the Sprint Retrospective activity of Scrum gives the

8 Scrum team an opportunity to reflect on and adjust the practices being applied. 6. COMPARISON AND DISCUSSION The Scrum example illustrated in Section 4 shows that there are some similarities between Essence and SPEM from an authoring perspective. Both specifications provide basic language concepts that allow us to define practices with guidance elements, but as illustrated in Section 5 the Essence language contains some different concepts or additional properties that better support enactment. One of the key differences is the notion of Alpha with alpha states and the usage of states as completion criteria of an Activity to monitor, track and drive the progress through generation of guidance advice. Table 1 below summarizes the correspondence between the key language concepts of SPEM and Essence (introduced in Figure 1 and Figure 2). Table 1. Mapping of SPEM and Essence concepts SPEM Essence Comment Task Activity Similar in concepts, but an Activity in Essence additionally defines completion criteria. Work Product Work Product Similar in concepts, but a Work Product in Essence additionally defines levels of details (not discussed in the illustrative example) to specify different ranges of details required. Role n/a Role allows to author responsibilities of work products and performers of tasks in SPEM. Essence does not specify the concept of a role and advices to use the Pattern concept to define roles. The rationale is that definitions of roles may differ from method to method. Category Tag Categories (both default and custom) are used to structure the elements of SPEM content, e.g. to support navigability in the published guidance. Essence provides the concept of a Tag (not discussed in the illustrative example) that allows adding user defined or tool specific information. Guidance Practice all elements Practice The Essence language does not differentiate between a specific guidance concept and other concepts such as Activity (which basically contains guidance for performing the work). SPEM defines Practice as a specific type of Guidance that can reference any element defined in SPEM. Essence on the other hand introduces Practice as a specific concept in the language which allows more Activity Capability Pattern Delivery Process n/a Resource or Pattern Activity Space and Activity Alpha operational semantics to support composition etc. to be formalized and better supported by tooling. If additional guidance types are needed the advice is to use Patterns or Resources. The Activity, Capability Pattern and Delivery Process concepts in SPEM allows to define work breakdown structures and reusable process content. The Essence language allows activity associations between abstract activities (which are either Activity Spaces or Activities) to represent a relationship or dependency between activities. The Alpha concept does not have an equivalent in the SPEM 2.0 specification, and is essential to the underlying method architecture of the Essence language to monitor, track and drive method enactment based on alpha states and completion criteria. In the comparison table we have restricted the analysis to the SPEM 2.0 specification. It should be noted that this specification is from 2008 and that the underlying method architecture supporting the EPF framework has evolved since 2008 with new capabilities not defined in SPEM 2.0. An example of a new capability is the concept of a Work Product Slot which is similar to an Alpha, except that there is no state information. Work product slots are used to decouple tasks, so a task can take requirements as an input, without specifying whether the requirements are e.g. use cases or user stories by marking it as a slot. A Work Product can fulfil a slot as part of the composition of practices. A new feature in the commercial counterpart to EPF from IBM, i.e. the Rational Method Composer (RMC), is support for user defined types which allows you to define your own type with attributes and relationships, assign the new type its own unique icons, and immediately start authoring these elements in your library. Since the focus of this paper has been on the comparison with the original SPEM 2.0 specification, we have not investigated the use of the new EPF framework capabilities in great depth. We did however do a small experiment to see how alphas could be represented in EPFC using work product slots (see Figure 20), but concluded that without the proper language support of Essence it would be cumbersome to use a tooling like EPFC to author Essence-compliant practices. RMC with its support for user defined types will probably be a better starting point if one where to revisit this tooling experiment.

9 [20] identify some of the same issues and propose method services towards practitioners. Hoppenbrouwers et al. [21] also identify similar challenges and the need for a light-weight approach towards the practitioners and propose a rule-based approach. One main criticism of SPEM 2.0 is the lack of enactment support [11, 12]. Although the EPF Wiki provides some functionality to support editing of online guidance, better enactment support is needed in the SPEM specification itself to guide tools to include capabilities such as monitoring, tracking and generation of advice, or have clearly defined APIs that allow software processes models to be linked with enactment tools. Bendraou et al. [22] has proposed extensions to SPEM 2.0 to support enactment, but we see no evidence that this will be included in revisions to the SPEM specification. Furthermore, the Situational Method Engineering (SME) community [23] has been working on related metamodelling approaches which has resulted in the ISO/IEC standard [24] that provides an alternative to the OMG SPEM 2.0 specification. Figure 20. Using Work Product Slots to represent Alphas 7. RELATED WORK Agile methods and techniques are widely adapted and successfully applied in many business and application domains today. The combination of Model-Driven Development (MDD) and agile software development, known as Agile MDD, is broadly researched and applied [14-16]. Although there are many existing Service-Oriented Architecture (SOA) methodologies, only few were found to be specifically concerned with incorporating agile software development (e.g. [17]). Furthermore, there are few methodologies that combine agile software development with both MDD and SOA for software reengineering. The mscrum4sosr is one such methodology, proposed by Chung et al [18]. The methodology extends Scrum with UML modelling and XP techniques in order to provide a comprehensive serviceoriented software reengineering process model. Another similar approach is the iterative development approach Model-driven Rapid Development Architecture (SMRDA), which unifies SOA and MDD in order to enhance the efficiency of the development efforts and the reusability of the developed services [19]. Based on the literature review we conducted, there are few methodologies that combine agile software development with both MDD and SOA for software reengineering. Moreover, we are lacking agile methodologies that specifically address modeldriven modernization to service clouds. This was one motivation for making the REMICS Methodology more agile. However, improving the initial release of the REMICS Methodology with agile practices resulted in the restructuring of the methodology authored in the EPF framework. One issue with these frameworks are that software processes defined by separate method engineers typically do not leave enough flexibility for the development team to customize and tailor the processes they use. Deneckère et al. 8. CONCLUSIONS AND FUTURE WORK In this paper we have presented and compared the key language concepts of the draft Essence 1.0 and SPEM 2.0 specifications applied to the Scrum practice in the context of the REMICS Methodology. The comparison is substantiated by proof-ofconcept implementations using two different tools supporting the specifications. The complete REMICS Methodology has been implemented using the SPEM-compliant EPF framework, i.e. authored using the EPF Composer tool and published online as an EPF Wiki. For the comparison with Essence we selected a specific part of the REMICS Methodology, i.e. the Scrum practice, which was authored in the Essence-compliant EssWork Practice Workbench tool. The comparison shows that although there are some similarities in the authoring capabilities of the two languages, there are some key differences in the method architecture with respect to support for enactment. The Essence specification provides means for monitoring, tracking and associating work to be done and things to work with through the progression of states on specific standardized kernel elements such as Requirements, Work and Task (expressed using the language concept Alpha). The Essence specification is now officially endorsed by the OMG and a final version is being prepared by a Finalization Task Force (FTF). The authors will continue to evaluate concepts from the Essence specification and provide feedback to the FTF based on development of prototyping tools and further improvements related to the REMICS Methodology. As part of this work we are currently working on re-authoring a larger part of the REMICS Methodology following the Essence specification. Acknowledgements. The research leading to these results has received funding from the European Union Seventh Framework Programme FP7/ under grant agreement n REMICS. The REMICS Methodology is available online at 9. REFERENCES [1] REMICS, "REMICS Handbook, Interim Release", REMICS Collaborative Project, Deliverable D2.4, 8 October

10 [2] REMICS, "REMICS methodology with agile extension, interim release", REMICS Collaborative Project, Deliverable D2.7, 31 August ethodology%20with%20agile%20extension%2c%20interim %20release.pdf [3] I. Krasteva, S. Stavros, and S. Ilieva, "Agile Model-Driven Modernization to the Service Cloud", in The Eighth International Conference on Internet and Web Applications and Services (ICIW 2013). Rome, Italy, [4] OMG, "Software & Systems Process Engineering Meta- Model Specification, Version 2.0", Object Management Group (OMG), Document formal/ , April [5] M. Kajko-Mattsson, M. Striewe, M. Goedicke, I. Jacobson, I. Spence, S. Huang, P. McMahon, B. MacIsaac, B. Elvesater, A. J. Berre, and E. Seymour, "Refounding software engineering: The Semat initiative (Invited presentation)", in Proc. of the 34th International Conference on Software Engineering (ICSE), Zürich, Switzerland, 2012, IEEE, pp [6] B. Elvesæter, M. Striewe, A. McNeile, and A.-J. Berre, "Towards an Agile Foundation for the Creation and Enactment of Software Engineering Methods: The SEMAT Approach", in ECMFA 2012 Joint Proceedings: Co-located Events at the 8th European Conference on Modelling Foundations and Applications, Kongens Lyngby, Technical University of Denmark (DTU), 2012, pp ISBN /proceedings/PDF/ECMFA-2012-Workshop- Proceedings.pdf [7] OMG, "Essence - Kernel and Language for Software Engineering Methods", Object Management Group (OMG), OMG Document ad/ , 18 February (Restricted to OMG members) & 3.pdf (Public) [8] OMG, "A Foundation for the Agile Creation and Enactment of Software Engineering Methods RFP", Object Management Group (OMG), OMG Document ad/ , 23 June [9] K. Schwaber and J. Sutherland, "The Scrum Guide", Scrum.org, October f [10] D. Leffingwell, "User Stories", in Agile Software Requirements, Addison-Wesley, 2011, pp ISBN [11] B. Henderson-Sellers and C. Gonzalez-Perez, "The Rationale of Powertype-based Metamodelling to Underpin Software Development Methodologies", in Proc. of the 2nd Asia-Pacific conference on Conceptual modelling - Volume 43, 2005, ACM. [12] C. Gonzalez-Perez and B. Henderson-Sellers, "Metamodelling for Software Engineering", John Wiley & Sons, Ltd, 2008, ISBN [13] P. Feiler and W. Humphrey, "Software Process Development and Enactment: Concepts and Definitions", Software Engineering Institute, Technical report CMU/SEI-92-TR- 004, September [14] R. Matinnejad, "Agile Model Driven Development: An Intelligent Compromise", in Proc. of the 9th International Conference on Software Engineering Research, Management and Applications (SERA), 2011, pp [15] R. Picek, "Suitability of Modern Software Development Methodologies for Model Driven Development", Journal of Information and Organizational Sciences, vol. 33, pp , [16] V. Mahé et al., "Crossing Model Driven Engineering and Agility: Preliminary Thought on Benefits and Challenges", in Proc. of the 3rd Workshop on Model-Driven Tool & Process Integration, in conjunction with Sixth European Conference on Modelling Foundations and Applications, Paris, France, 2010, pp [17] I. Christou et al., "Using the Agile Unified Process in Banking", IEEE Software, vol. 27, pp , [18] S. Chung et al., "A Model-Driven Scrum Process for Service-Oriented Software Reengineering: mscrum4sosr", in Proc. of the The 2nd International Conference on Computer Science and its Applications (CSA 2009), Jeju Island, Korea, 2009, pp [19] B. Wang et al., "A SOA based Model driven Rapid Development Architecture - SMRDA", in The 2nd International Conference on Education Technology and Computer (ICETC 2010). Shanghai, China, [20] R. Deneckère, A. Iacovelli, E. Kornyshova, and C. Souveyet, "From Method Fragments to Method Services", in 13th International Workshop on Exploring Modeling Methods for Systems Analysis and Design (EMMSAD'08). Montpellier, France, 2008, pp [21] S. Hoppenbrouwers, M. Zoet, J. Versendaal, and I. v. d. Weerd, "Agile Service Development: A Rule-Based Method Engineering Approach", in Engineering Methods in the Service-Oriented Context, 4th IFIP WG 8.1 Working Conference on Method Engineering, ME 2011, Paris, France, April 2011, Proceedings, Springer, 2011, pp [22] R. Bendraou, B. Combemale, X. Cregut, and M.-P. Gervais, "Definition of an Executable SPEM 2.0", in 14th Asia- Pacific Software Engineering Conference (APSEC '07). Nagoya, Japan, 2007, pp [23] M. A. Jeusfeld, M. Jarke, and J. Mylopoulos, "Metamodeling for Method Engineering", The MIT Press, [24] ISO/IEC, "Software Engineering Metamodel for Development Methodologies", International Organization for Standardisation (ISO), ISO/IEC 24744, 15 February 2007.