Towards an Agile Foundation for the Creation and Enactment of Software Engineering Methods: The

SEMAT Approach

Brian Elvesæter1, Michael Striewe2, Ashley McNeile3 and Arne-Jørgen Berre1

1 SINTEF ICT, P. O. Box 124 Blindern, N-0314 Oslo, Norway {brian.elvesater, arne.j.berre}@sintef.no

2 University of Duisburg-Essen, Gerlingstrasse 16, D-45127 Essen, Germany michael.striewe@s3.uni-due.de

3 Metamaxim, 48 Brunswick Gardens, London W8 4AN, UK ashley.mcneile@metamaxim.com

Abstract. The Software Engineering Method and Theory (SEMAT) initiative seeks to develop a rigorous, theoretically sound basis for software engineering methods. In contrast to previous software engineering method frameworks that rely on separate method engineers, the primary target of SEMAT are practition-ers. The goal is to give software development teams the opportunity to them-selves define, refine and customize the methods and processes they use in soft-ware development. To achieve this goal SEMAT proposes a new practitioner-oriented language for software engineering methods that is focused, small, ex-tensible and provides formally defined provides formally defined behaviour to support the conduct of a software engineering endeavour. This paper presents and discusses how the proposed language supports an agile creation and enact-ment of software engineering methods. The SEMAT approach is illustrated by modelling parts of the Scrum project management practice.

Keywords: Method engineering, software engineering methods, SEMAT, SPEM, ISO/IEC 24744, Scrum

1 Introduction

The Software Engineering Method and Theory (SEMAT)1 initiative seeks to develop a rigorous, theoretically sound basis for software engineering methods. Previous software engineering frameworks and standards such as the Software and Systems Process Engineering Metamodel (SPEM) 2.0 [1] mainly target method engineers by providing rich but consequently often complex languages for detailed process defini-tion; but generally not supporting enactment [2]. In contrast, the primary objective of SEMAT is to target practitioners (i.e., architects, designers, developers, program-mers, testers, analysts, project managers, etc.) by providing a focused, small, extensi-

1 http://www.semat.org

ble domain-specific language that allows them to create and enact software engineer-ing methods in an agile manner.

An agile approach to software engineering methods is one that supports practition-ers in dynamically adapting and customizing their methods during the preparation and execution of a project, controlled through company-specific governance, use of ex-amples and other means. This enables practitioners to accurately document how they work and effectively share their experiences with other teams. To go beyond the cur-rent state of the practice a robust and extensible foundation for the agile creation and enactment of software engineering methods is required.

This paper presents and discusses the main new ideas and language concepts from the Essence specification [3] which has been submitted by SEMAT as a response to the Request for Proposal (RFP) “A Foundation for the Agile Creation and Enactment of Software Engineering Methods” [4] issued by the Object Management Group (OMG). The remainder of the paper is structured as follows: In Section 2 we present and summarise the language requirements stated in the OMG RFP. In Section 3 we present the language architecture of the Essence specification and its main language constructs. In Section 4 we illustrate the SEMAT approach by modelling parts of the Scrum project management practice. Section 5 discusses this approach to related work. Finally, Section 6 concludes this paper and describes some future work.

2 Language Requirements and the Meta-Object Facility (MOF)

The OMG RFP “A Foundation for the Agile Creation and Enactment of Software Engineering Methods” [4] solicits proposals for a foundation for the agile creation and enactment of software engineering methods. This foundation is to consist of a kernel of software engineering domain concepts and relationships that is extensible (scalable), flexible and easy to use, and a domain-specific modelling language that allows software practitioners to describe the essentials of their current and future practices and methods. In this paper we focus on the language. The requirements for the language are summarised in Table 1 below.

Table 1. Language definition (1.x) and language features (2.x) requirements

ID Name Description 1.1 MOF metamodel Abstract syntax defined in MOF. 1.2 Static and operational

semantics Static and operational semantics defined in terms of the ab-stract syntax.

1.3 Graphical syntax Graphical syntax that maps to the abstract syntax. 1.4 Textual syntax Textual syntax that maps to the abstract syntax. 1.5 SPEM 2.0 metamodel

reuse Reuse SPEM 2.0 metamodel where appropriate.

2.1 Ease of use Easy to use by practitioners. 2.2 Separation of views Separation of two different views of a method for practitioners

and method engineers. 2.3 Specification of kernel

elements Description, relationships, states, instantiation and metrics.

2.4 Specification of practices Cross-cutting concern, element instantiation, work products, work progress, verification.

ID Name Description 2.5 Composition of practices Overall concerns, merging elements, separating elements,

practice substitution. 2.6 Enactment of methods Tailoring, communication, managing, coordinating, monitor-

ing, tooling.

The language definition (1.x) requirements mandate that the language must be com-pliant with the MOF metamodel architecture. The Meta-Object Facility (MOF) speci-fication [5] serves as a foundation for the OMG Model-Driven Architecture (MDA) [6] approach and provides us with a formalism to define and integrate modelling lan-guages. The left side of Fig. 1 illustrates the MOF four-layer architecture. MOF de-fines a meta-metamodel or meta-language at the M3 layer which can be used to define a metamodel or language to support method engineering at the M2 layer. A method engineering modelling language typically defines language constructs to support the definition and composition of methods out of reusable model fragments or templates. These model templates at the M1 level are typically defined by method engineers and are instantiated during a software endeavour, i.e., software development project, and used by the software practitioners (M0 level).

The right side of Fig. 1 illustrates an instance tree. MDA positions MOF as the sin-gle meta-language (M3), so there is only one top node for which different languages (M2) can be defined. Each of these modelling languages can be used to define various models (M1) of which different instantiations can be made (M0). In this paper we focus our discussion on a single domain-specific language to support method engi-neering. Thus in the remainder of this paper we will focus on the M2 layers and below as illustrated by the dashed boxes.

Fig. 1. MOF metamodel architecture and instantiation tree

The language features (2.x) requirements focus in particular on the ability to specify practices, compose practices into methods and enact those methods. The requirements also state that existing foundations such as the SPEM 2.0 [1] should be reused where appropriate.

3 The SEMAT Approach

The Essence specification [3], which is the initial response to the OMG RFP from the SEMAT community, defines a kernel of essentials for software engineering and an

 

...

... ...

... ... ... ...Endeavour

(process instance)

Model(method template)

Metamodel(language)

Meta-metamodel(meta-language)

instance_of

instance_of

instance_of

M3

M2

M1

M0

associatedardised bJacbosonnity is itaccepted

Fig. 2 illutheir propis a kerneware engengineerisential ththat are uresents thSupport t

A Pracspecific Checkpoihand. Thein [8] as “

The ladynamic namic sem

3.1 St

The staticdescribe tto allow

2 http://ww

d language fobaseline. This n et al. in [7] werating and imkernel and lan

ustrates the Sposed graphicel, i.e., a com

gineering that ing methods. hings to work universal to sohe essential ththe Team, etc.ctice (e.g., Usguidelines exint, Pattern ane practices are“a systematic anguage contasemantics andmantics which

tatic Semanti

c semantics ofthe kernel, prafor easier und

ww.ivarjacobson

or describing papproach dra

which is suppomproving on nguage that ca

Fig. 2. Overv

EMAT approal notation. A

mmon ground,can be used aThe kernel dewith (e.g., R

oftware enginehings to do (e.).

ser Story, Scruxpressed usinnd Work Prode composed toway of doing

ains four partd 4) graphicah will be elabo

cs – Creation

f the languageactices and mederstanding an

n.com/process_

practices and aws inspiratioorted by the tothese ideas w

an be standard

view of the SEM

oach and someA key idea is t, which includas a standardiefines a comp

Requirements, eering and a sg., Prepare to

um, etc.) use tng language duct addressino form a methg things in a pats, 1) abstractal syntax. Thisorated in the f

n of Software

e specifies a methods. The land usage of di

_improvement_

methods usinon from the iool EssWork2

with the goaldised by the O

MAT approach

e of the key lathat in all softdes a few esseised baseline pact set of AlpWork, Team,

small set of Ao do the Work

the kernel as aconstructs su

ng a particulaod. A definitiarticular discipt syntax, 2) cs paper focusefollowing subs

e Engineering

metamodel thaanguage has bifferent subse

_technology/ess

g the kernel adeas presente. The SEMAT

l of defining OMG.

anguage constware endeavoential elementfor describingphas that repr

Software SysActivity Spacesk, Coordinate

a baseline anduch as State,ar aspect of thon of a methopline”. composition aes on the statisections.

g Methods

at contains coneen structuredts. Fig. 3 belo

work

as a stand-ed by Ivar T commu-a widely-

structs and ours, there

nts of soft-g software resents es-stem, etc.) s that rep-the Work,

d provides , Activity, he work at od is given

algebra, 3) ic and dy-

nstructs to d as layers ow shows,

in a sligheach laye

Fig. 3. La

The Kernis a set oneering erepresenthealth ofwhose evstate grapout its lifthat the Aalphas, e.quiremenin the sofware engwithout dto the wostates ma

The PWork Proproach toand teach 3 In the Es

layer is

htly simplifieder.

anguage specifi

nel layer contaof elements usendeavour. Alpts an essentialf a software volution we waph with well-dfecycle. Each Alpha must fu.g., for splittin

nt Items. An Aftware enginegineering endedefining or coork. When th

ay have changePractice layeroduct, Alpha o doing somethable way of

ssence specificas divided into tw

d form3, the l

cation – static s

ains the constsed to form alpha is short fl element that engineering eant to understdefined states.state has a co

ulfil to be in thng Software SActivity Spaceering endeavoeavour at an nstraining how

he work is coed.

contains theManifest andthing with a addressing a p ation, the languwo: for simple a

layers of the

semantics (mod

tructs Kernel,a common grofor Abstract-Lt is relevant toendeavour. Atand, monitor,. The states deollection of chhat particular

System into Coe provides a pour. Activity Sabstract leve

w it is done. Aoncluded the A

e constructs Pd Pattern. A Pspecific purpparticular asp

uage is actually and advanced p

language and

dified and simpl

Alpha and Aound for descLevel Progreso the assessm

Alphas are use direct and coefine a controheckpoints thstate. An Alp

omponents orlaceholder forSpaces frame

el, capturing wActivity SpacAlphas are up

Practice, ActiPractice is a ose in mind,

pect of the wo

structured as fpractices.

d the key con

lified metamode

ctivity Space. ribing a softwss Health Attrent of the proed to describentrol. Each A

olled evolutionat describes thpha may also r Requirementr something tthe activities

what needs toes take Alphapdated and he

vity, Activity general, repeaproviding a s

ork at hand. A

four layers, as th

nstructs of

del excerpt)

A Kernel ware engi-ribute and ogress and e subjects

Alpha has a n through-he criteria have sub-

ts into Re-to be done s of a soft-o be done as as input ence their

Manifest, eatable ap-systematic

An Activity

the Practice

defines oActivity Mis an arteManifest mechanistional alp

The Mhow an en

3.2 Dy

In contrasify a metmodel at ties for thing to the

Fig. 4 illumain. Thstandard lighted _Esemantic and class

one or more kManifest bindsefact of value

binds a collesm for defininphas or extend

Method layer cndeavour is ru

ynamic Sema

st to the statictamodel at ththe M1 layer

he "run-time" e MOF archite

Fig

ustrates the de M2:Metamoproposed by Ext class in Mdomain defin

s instances of

inds of work s a collection and relevanceection of wor

ng a structure d existing alphontains the coun. A Library

antics – Enac

c semantics ofe M2 layer inr. This model occurrences d

ecture.

g. 4. Language s

dualism of theodel, M1:Kern

the Essence M1:Dynamic anes constructsf these metacl

and gives guof activities t

e for a softwark products tin a practice.

has with sub-aonstructs Meth

includes a co

ctment of Soft

f the languagen the MOF ardefines abstr

during the end

specification –

e static semannel and a set ospecification,are extension

s such as Alphlasses at M1

uidance on howto an activity are engineerinto an alpha. A

The practice lphas. hod and Libraollection of pra

tware Engine

, the dynamicrchitecture (se

ract superclassdeavour, i.e.,

dynamic seman

ntics and the of M1:Dynami, while the Ms added by a

ha, Activity ansuch as Sprin

w to perform space. A Worg endeavour. A Pattern is may also spe

ry. A Methodactices and me

eering Metho

semantics doee Fig. 1), buses that contaiat the M0 laye

ntics

dynamic semic classes are p

M1:Static and practitioner.

nd Work Prodnt, Sprint Plan

these. An rk Product An Alpha a general

ecify addi-

d describes ethods.

ods

o not spec-ut rather a ain proper-yer accord-

mantics do-part of the the high-

The static duct at M2 nning and

Product my_AlphaWork Pro

The geer containsemantic such as rualphas, eduration fined in tnism by d

The resupportedHaving smethods needs of t

4 Il

This sectScrum prmapped tfrom a seage of thThe Scrued with th

4.1 Cr

In this paprinciplesEssence ssuch as Ractivity sWork, Sup

Backlog. Tha, my_Activityoduct class inseneralization mn slots that hadomains. Us

un-time endea.g., my_Alphathat should ap

the kernel. Modefining operaelationship betd by tools ansuch mechanias described,the endeavour

lustrative A

tion illustrateroject manageto the Essenceet of well-defihe method is um practice dehe alphas and

reating the S

aper we only ps. Fig. 5 represpecification Requirements,spaces for thepport the Tea

Fig. 5. A

he dynamic sy and my_Wostances from tmechanism enave been defining this mechavour propertia_Ext that conpply to Sprintoreover, dynamations using thtween the stat

nd services thsms in place , but also refir.

Approach –

es the SEMAement practicee Kernel and ined Practicessupported by

efines specificactivity space

crum Practic

present a subsesents a subse[3]. The KernSoftware Sys

e endeavour sm, Track Prog

Alpha and Activ

semantic domorkProduct fothe static semansures that thened both fromhanism one coies that shoulntains propertt instances thamic semanticshe superclassetic elements anhat allow prec

will providefine and custo

– Scrum

AT approach e [9] and explLanguage. A s that plugs in

y language's cc work produces defined by

ce and Metho

set of the Esset of the alphanel defines a sstem, Work ansuch as Prepagress and Stop

vity Space subs

main defines or the respectiantic domain.e instances on

m the static semould also defid only apply ties such as sat are sub-alps can be formes of the dynamnd their dynamcise definitione practitionersomize the me

by modellingores how the particular Me

nto the Kernecomposition acts and activitithe kernel.

od

ence Kernel ias and activitsmall set of unnd Team, and are to do thep the Work.

et defined by th

superclassesive Alpha, Ac

the endeavoumantic and theine specific exto certain subtateTime, endhas of Work t

malized with thmic semantic mic counterpan of these asss the ability tthods accordi

g selected parScrum practicethod can be cel. Compositiond dynamic sies that can be

in order to illuy spaces definniversal alphatheir relationWork, Coord

he Kernel

s such as ctivity and

ur M0 lay-e dynamic

extensions, bclasses of dTime and that is de-

his mecha-domain.

arts can be sociations. to use the ing to the

arts of the ce may be composed

on and us-semantics. e associat-

ustrate the ned in the a elements

nships, and dinate the

Since theWork alpthe check

A checkpcan be uspoints areof descrip

We extypically sprints. Telled as aown staterules thatand its asmapped tright side

Fig. 7. T(mid

e paper focusha. Fig. 6 sho

kpoints associa

Fig. 6. Stat

point describesed to measure typically exptive checklistxtend the Wor

used for the Thus we defina work produce graph (see mt should be dessociated checto correspondie of Fig. 7).

The Sprint sub-addle) and mappi

es on the enaows the states ated with each

tes of work, stat

s the entry crire the progresxpressed in nats items that ark alpha for Sduration of a

ne a new sub-ct that is assocmiddle part of efined as partckpoints are ming activities a

alpha extends thng of Scrum ac

actment part wof work, the

h state.

te descriptions

iteria for entess of the alphaatural languagare interpretedScrum (see lef

development-alpha called ciated with thef Fig. 7). Scrumt of the practimore general. and associated

he Work alpha ctivities to the A

we only elabcorresponding

and associated

ering a specifia in the softw

ge and provided by the practitft side of Fig.

project that mSprint. The S

e Sprint sub-am comes withce, whereas tThe identifiedd with the pro

(left), the statesActivity Spaces

orate the detag state descrip

checkpoints

c state of the ware endeavoue a basis for gtioners. 7). The Wormay cover a nSprint Backloalpha. The Sprh its own speche Work stated Scrum even

oper activity sp

s of the Sprint sof the Kernel (

ails of the ptions and

alpha and ur. Check-generation

rk alpha is number of

og is mod-rint has its cific set of e machine

nts may be paces (see

sub-alpha (right)

4.2 En

The enacis a creatdeavour iing methovide meaagents folaborates supportedproject m

The cocomposedpurpose, card for tse cards cgress the checkpoin

Using thea state chinstead ogress fromsupports

5 R

One mainSPEM prproject plmapping workflow

nacting the S

tment supporttive process ais done by humods and practans of monitooremost and au

on decision-d by method r

management anoncrete syntaxd practices, i.the concept o

the Sprint alphcan be used fostates of the

nts are ticked

Fig.

e checkpoints hange has occf the checklism one state tthe definition

Related Wor

n criticism ofrocesses are tylans and enacprocesses to a

w engine [1]. D

crum Method

t in the Essencand most of thman agents [1ices must ack

oring and proutomation sec

-making, planrepositories annd issue trackix of the lang.e., the metho

of Alpha state ha at the initiaor reading andSprint accordoff.

8. Sprint state c

of the Alphascurred. These st items one cto another, orof different v

rk and Disc

f SPEM 2.0 isypically done cting these wia business flowDesigning nat

d

ce language rhe progress w

10]. Thus, procknowledge theogressing the condly. In ena

nning and exend process ening systems.

guage has beeod, should becards is intro

al state (left) ad understandinding to the che

card (initial stat

s it is at the dstate cards m

could get a lisr which workviews suitable

cussions

s the lack of through mappith project plaw or executiotive dynamic s

ecognizes thawithin the sofcess enactmene human knowsoftware endactment, a teaecution. Enactngines that are

en designed soe easy for theoduced. Fig. 8and in the Plang the practicecklist defined

te and planned

discretion of thmay also have st of activities

k products to for different k

enactment suping, e.g., (1) anning and enon language ansemantics into

t software devftware developnt of software wledge workereavour througam of practitiotment may be linked to too

o that the usae practitioners8 below showanned state (rie, and also hod. This requir

state)

he team to decdifferent view

s to do in ordproduce. Thekinds of pract

pport [8, 11].mapping proc

nactment systend executing to the language

velopment pment en-

e engineer-er and pro-gh human oners col-e partially ols such as

age of the s. For this

ws the state ight). The-ow to pro-res that all

cide when ws so that der to pro-e language titioners.

. Enacting cesses into ems or (2) this with a e is argua-

bly one oture.

The Sirelated m[13] that the key cmetamodlinked topowertyptwo typesour elemhave a powertypConstrainrequiring

Since advMOF thesupport dleaves outhat is Msemanticsat the M1deavour pusing powillustratesProductKWorkProfication.

of the main re

ituational Metmetamodelling

provides an aclasses in the del that definogether throupes to model ss of methodol

ments which incorresponding

pe relationshipnt, Outcome a the need for i

F

vanced metame ISO 24744 dynamic semaut the endeavo

MOF compliants and the mod1 layer of the properties at twertypes but s the differen

Kind metaclasduct (at M2 lStandardised

equirements th

thod Engineerapproaches w

alternative to ISO 24744 m

nes Methodolough the consoftware develogy element ncludes Stageg methodolop. Resource

and Guideline,instantiation a

Fig. 9. Overview

modelling consstandard use

antics. This mour M0 layer.t and define tdel of the dynMOF archite

the endeavourmaintains co

ce between thsses from theayer) and my_endeavour p

hat will requi

ring (SME) cowhich has resu

the OMG SPmetamodel. Thogy elements

ncept of powelopment metclasses, name

e, WorkUnit, ogy element

constructs, w, represents elat the endeavo

w of the ISO 24

structs such ass a different

metamodelling. In the SEMtwo separate dnamic semantiecture (see Figr M0 layer. Tompatibility whe two approe ISO/IEC 24_WorkProducproperties on

ire a redesign

ommunity [12ulted in the ISPEM 2.0 speche metamodel and Endeav

wertypes [14]thods is descrely TemplateWorkProduct...Kind type

which includelements that arour level.

4744 metamode

s powertypes ametamodel a

g issue is not AT approach domains, the mics. We compg. 4) to suppoThis is very siwith the MOFaches. The W

4744 standardct (at M1 layer

WorkProduc

of the SPEM

2] has been wSO/IEC 24744cification. Figl can be seen vour elements]. An explanibed in [11]. and Resourceand Produce

represented e Language, re directly use

el

are not compaarchitecture [1

present in SPwe propose

metamodel ofpose these twort both methomilar to the cF architecture

WorkProduct ad are equivaler) in the Essen

ct (ISO 24744

M architec-

working on 4 standard

g. 9 shows n as a dual s that are

anation of There are

e. Endeav-er, always

d using a Notation,

ed without

atible with 11, 13] to PEM as it a solution

f the static o domains od and en-concept of e. Fig. 10 and Work-ent to the nce speci-4) can be

representextensiondone thro(Essence)both appr

6 C

In this paSEMAT Enactmenand dynaby model

The prthe M2 lael on theintended tioners. Texamplesmodel focurrent anenactmenand similISO/IEC

ted as properns and properough extension). The resultinroaches.

Fig. 10. C

onclusions

aper we have pas a response

nt of Softwareamic semanticlling selected proposed languayer in the MOe M1 layer in

to simplify sThe concepts os of such requor software ennd future pracnt, in softwarelarities betwee24744.

rties on my_Wrties such as ns of the domng slots in the

Comparison of

and Futur

presented the e to the OMGe Engineerings of the Essenparts of the Sc

uage contains OF architectur

the MOF arcsoftware engiof Kernel, Alpuired languagengineering anctices that aftee endeavours. en the Essence

WorkProductversion on P

main classes ase ProductBac

f the ISO 24744

re Work

main ideas oG RFP “A Fog Methods” [4nce language acrum project ma static semanre and a dynamchitecture. Thineering methpha, Activity Se constructs.

nd provide a erwards are adOur discussioe approach an

(Essence). AProductBacklos shown using

cklog instance

and Essence ap

f the Essenceundation for ]. This paper and illustratedmanagement pntics part defimic semanticshe proposed lhod modellingSpace and PraThe kernel elstandardised b

dapted and cuson has tried tond other relate

Additional useog (ISO 24744g my_WorkPro

at M0 are th

pproaches

language subthe Agile Crehas explained

d the enactmenpractice. ined as a metas part defined anguage cons

g adaptation factice are intrlements form baseline for dstomized for uo clarify the ded standards su

er-specific 44) can be roduct_Ext he same in

bmitted by eation and d the static nt support

amodel on as a mod-

structs are for practi-roduced as

a domain describing usage, i.e., differences uch as the

We are currently progressing this work in the context of SEMAT where we are preparing a revised submission to the OMG RFP. The aim is to take advantage of recent development and experiences from software engineering and method engineer-ing communities in order to give the best possible direct support towards software practitioners.

Acknowledgments. This research was co-funded by the European Union in the frame of the NEFFICS project (FP7-ICT-258076) (www.neffics.eu) and the REMICS pro-ject (FP7-ICT-257793) (www.remics.eu), and SINTEF in the frame of the SiSaS pro-ject (sisas.modelbased.net). The authors acknowledge and thank collaboration with colleagues within SEMAT (www.semat.org) for foundational input and feedback.

References

[1] OMG, "Software & Systems Process Engineering Meta-Model Specification, Version 2.0", Object Management Group (OMG), Document formal/2008-04-01, April 2008. http://www.omg.org/spec/SPEM/2.0/PDF/

[2] 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. 390-397. http://dx.doi.org/10.1109/APSEC.2007.38

[3] OMG, "Essence - Kernel and Language for Software Engineering Methods, Initial Submission - Version 1.0", Object Management Group (OMG), OMG Document ad/12-02-04, 20 February 2012. http://www.omg.org/cgi-bin/doc?ad/12-02-04

[4] OMG, "A Foundation for the Agile Creation and Enactment of Software Engineering Methods RFP", Object Management Group (OMG), OMG Document ad/2011-06-26, 23 June 2011. http://www.omg.org/members/cgi-bin/doc?ad/11-06-26.pdf

[5] OMG, "Meta Object Facility (MOF) Core Specification, Version 2.0", Object Management Group (OMG), Document formal/06-01-01, January 2006. http://www.omg.org/spec/MOF/2.0/PDF/

[6] OMG, "MDA Guide Version 1.0.1", Object Management Group (OMG), Document omg/03-06-01, June 2003. http://www.omg.org/cgi-bin/doc?omg/03-06-01.pdf

[7] I. Jacobson, P. W. Ng, and I. Spence, "Enough of Processes - Lets do Practices", Journal of Object Technology, vol. 6, no. 6, pp. 41-66, 2007. http://www.jot.fm/issues/issue_2007_07/column5

[8] C. Gonzalez-Perez and B. Henderson-Sellers, "Metamodelling for Software Engineering", John Wiley & Sons, Ltd, 2008, ISBN 978-0-470-03036-3.

[9] K. Schwaber and J. Sutherland, "The Scrum Guide", Scrum.org, October 2011. http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf

[10] P. Feiler and W. Humphrey, "Software Process Development and Enactment: Concepts and Definitions", Software Engineering Institute, Technical report CMU/SEI-92-TR-004, September 1992.

[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] M. A. Jeusfeld, M. Jarke, and J. Mylopoulos, "Metamodeling for Method Engineering", The MIT Press, 2009.

[13] ISO/IEC, "Software Engineering – Metamodel for Development Methodologies", International Organization for Standardisation (ISO), ISO/IEC 24744, 15 February 2007.

[14] J. Odell, "Power Types", Journal of Object-Oriented Programming, vol. 7, no. 2, pp. 8-12, 1994.