A Comparison of the Essence 1.0 and SPEM 2.0
Specifications for Software Engineering Methods
Brian Elvesæter
Gorka Benguria
Sylvia Ilieva
SINTEF ICT
P. O. Box 124 Blindern
N-0314 Oslo, Norway
+47 22 06 76 74
TECNALIA R&I
Ed 202, Zamudio 48170
Spain
+34 600 645 586
IICT-BAS, acad.
G. Bonchev str., bl. 25A
Sofia 1113, Bulgaria
+35 928 717 127
brian.elvesater@sintef.no
gorka.benguria@tecnalia.com
sylvia@acad.bg
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 1-58113-000-0/00/0010 …$15.00.
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
Method Content
Kernel Content
Practice Content
Kernel
Practice
Alpha
< has
Work
Product
< helps create
organizes >
Activity Space
Template
produces
/ updates >
< evidences
Alpha
State
targets >
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.
< qualify
responsibilities
Activity
Team Role
Process Content
Work Product
Work Product Descriptor
Competency
Resource
Pattern
Example
Resource
and Pattern
< input
> output
< input
> output
Figure 2. Overview of key language concepts in Essence
Role
Descriptor
Role
Task
Descriptor
Task
Activity
Kernel
Elements
Category
Standard
Categories
(subset)
Standard
Guidance
Types
(subset)
3. ILLUSTRATIVE EXAMPLE – SCRUM
Guidance
Capability
Pattern
Discipline
Practice
Tool
Roadmap
Delivery
Process
Template
Checklist
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.
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).
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 (http://www.eclipse.org/epf/) and is hosted
as an EPF Wiki (http://epf.remics.eu/wikis/remics/index.htm).
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
(http://www.ivarjacobson.com/EssWork_Practice_Workbench/).
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.
Figure 4. OpenUP kernel in EPFC
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
(http://www.eclipse.org/epf/downloads/praclib/praclib_downloads
.php). 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 5. Essence kernel in EWPW
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 7. Activity detail diagram
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.
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
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.
< fulfils
Software
System
< scope and
constrain
produces >
Requirements
< performs and plans
Work
Prepare to
do the Work
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
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
5. ENACTMENT
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.
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 (http://www-142.ibm.com/software/products/us/en/rtc/).
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
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
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).
…
Resource
or Pattern
Activity
Capability
Pattern
Delivery
Process
Activity
Space and
Activity
Table 1. Mapping of SPEM and Essence concepts
SPEM
Essence
Task
Activity
Work
Product
Work
Product
Role
n/a
Category
Tag
Guidance
Practice
all
elements
Practice
Comment
Similar in concepts, but an
Activity in Essence additionally
defines completion criteria.
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 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.
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.
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
n/a
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.
[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
24744 standard [24] that provides an alternative to the OMG
SPEM 2.0 specification.
8. CONCLUSIONS AND FUTURE WORK
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.
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/2007-2013 under grant agreement n° 257793
REMICS. The REMICS Methodology is available online at
http://epf.remics.eu/wikis/remics/index.htm
9. REFERENCES
[1] REMICS, "REMICS Handbook, Interim Release", REMICS
Collaborative Project, Deliverable D2.4, 8 October 2012.
http://www.remics.eu/system/files/REMICS_D2.4_V1.0.pdf
[2] REMICS, "REMICS methodology with agile extension,
interim release", REMICS Collaborative Project, Deliverable
D2.7,
31
August
2012.
http://www.remics.eu/system/files/D2.7%20REMICS%20m
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, 2013.
[4] OMG, "Software & Systems Process Engineering MetaModel Specification, Version 2.0", Object Management
Group (OMG), Document formal/2008-04-01, April 2008.
http://www.omg.org/spec/SPEM/2.0/PDF/
[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.
1649-1650.
http://dx.doi.org/10.1109/ICSE.2012.6227214
[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. 279-290. ISBN
9788764310146.
http://www2.imm.dtu.dk/conferences/ECMFA2012/proceedings/PDF/ECMFA-2012-WorkshopProceedings.pdf
[12] C.
Gonzalez-Perez
and
B.
Henderson-Sellers,
"Metamodelling for Software Engineering", John Wiley &
Sons, Ltd, 2008, ISBN 978-0-470-03036-3.
[13] P. Feiler and W. Humphrey, "Software Process Development
and Enactment: Concepts and Definitions", Software
Engineering Institute, Technical report CMU/SEI-92-TR004, September 1992.
[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. 197-202.
[15] R. Picek, "Suitability of Modern Software Development
Methodologies for Model Driven Development", Journal of
Information and Organizational Sciences, vol. 33, pp. 285295, 2009.
[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. 97-108.
[17] I. Christou et al., "Using the Agile Unified Process in
Banking", IEEE Software, vol. 27, pp. 72-79, 2010.
[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. 1-8.
[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, 2010.
[7] OMG, "Essence - Kernel and Language for Software
Engineering Methods", Object Management Group (OMG),
OMG Document ad/2013-02-01, 18 February 2013.
http://www.omg.org/cgi-bin/doc?ad/13-02-01 (Restricted to
OMG
members)
&
http://semat.org/wpcontent/uploads/2013/02/Essence_final_submission_18Feb1
3.pdf (Public)
[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.
80-96.
http://sunsite.informatik.rwthaachen.de/Publications/CEUR-WS/Vol-337/paper7.pdf
[8] OMG, "A Foundation for the Agile Creation and Enactment
of Software Engineering Methods RFP", Object
Management Group (OMG), OMG Document ad/2011-0626, 23 June 2011. http://www.omg.org/members/cgibin/doc?ad/11-06-26.pdf
[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. 184189.
[9] K. Schwaber and J. Sutherland, "The Scrum Guide",
Scrum.org,
October
2011.
http://www.scrum.org/storage/scrumguides/Scrum_Guide.pd
f
[10] D. Leffingwell, "User Stories", in Agile Software
Requirements, Addison-Wesley, 2011, pp. 99-117. ISBN
978-0-321-63584-6.
[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.
[22] R. Bendraou, B. Combemale, X. Cregut, and M.-P. Gervais,
"Definition of an Executable SPEM 2.0", in 14th AsiaPacific Software Engineering Conference (APSEC '07).
Nagoya,
Japan,
2007,
pp.
390-397.
http://dx.doi.org/10.1109/APSEC.2007.38
[23] M. A. Jeusfeld, M. Jarke, and J. Mylopoulos,
"Metamodeling for Method Engineering", The MIT Press,
2009.
[24] ISO/IEC, "Software Engineering – Metamodel for
Development Methodologies", International Organization
for Standardisation (ISO), ISO/IEC 24744, 15 February
2007.