Post on 07-Jun-2020
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.