ISO/IEC 24744:2014

Software engineering — Metamodel for development methodologies

Development methodologies may be described in the context of an underpinning metamodel, but the precise mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the elements that compose the methodology and, at the same time, of the entities (such as work products) created when the methodology is applied. ISO/IEC 24744:2014 introduces the Software Engineering Metamodel for Development Methodologies (SEMDM), a comprehensive metamodel that makes use of a new approach to defining methodologies based on the concept of powertype. The aim of SEMDM is to define methodologies in information-based domains, i.e. areas characterized by their intensive reliance on information management and processing, such as software, business or systems engineering. The SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks, allowing the seamless integration of process, modelling and people aspects of methodologies. Examples are given where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided. Various methodologies are defined, used, or implied by a growing number of standards, and it is desirable that the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM. Conformance to this metamodel will ensure a consistent approach to defining each methodology with consistent concepts and terminology.

Ingénierie du logiciel — Métamodèle pour les méthodologies de développement

General Information

• Status: Published
• Publication Date: 04-Nov-2014
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Current Stage: 9093 - International Standard confirmed
• Start Date: 08-Jan-2026
• Completion Date: 12-Feb-2026

Relations

• Revises: ISO/IEC 24744:2007/Amd 1:2010 - Software Engineering — Metamodel for Development Methodologies — Amendment 1: Notation
• Effective Date: 25-Aug-2012
• Revises: ISO/IEC 24744:2007 - Software Engineering — Metamodel for Development Methodologies
• Effective Date: 25-Aug-2012

Overview

ISO/IEC 24744:2014 defines the Software Engineering Metamodel for Development Methodologies (SEMDM). It provides a formal, generic metamodel for describing and extending development methodologies in information‑based domains (IBD) such as software, business and systems engineering. SEMDM unites process, product and people aspects of methodologies using a powertype (dual‑layer) approach to enable expressive, harmonized method definitions and tool interoperability.

Key topics and technical requirements

• Metamodel scope: Defines core classes for processes, producers (people/tools), products (work products and models) and supporting elements.
• Powertype and clabject concepts: Uses a dual‑layer modelling pattern to allow simultaneous definition of element kinds and their runtime instances.
• Process–product integration: Mechanisms to link process elements (tasks, stages, actions) with resulting work products and constraints.
• Method engineering: Support for creating, tailoring and packaging methodologies by method engineers; includes rules and guidelines for usage and extension.
• Conformance and consistency: Conformance clauses ensure that methodologies defined to SEMDM use consistent concepts and terminology.
• Extensibility: Rules for extending the metamodel to create domain‑specific methodology metamodels without compromising interoperability.
• Graphical notation and examples: A proposed visual notation, worked examples, and mappings to other approaches (see Annex B) to assist adoption and tooling.

Practical applications and who uses it

• Method engineers and process architects - design, compose, and tailor methodologies (packaged or project‑specific) using a standardized metamodel.
• Tool vendors - implement interoperable modelling and methodology support tools that can exchange method fragments and enactments.
• Standards bodies and integrators - harmonize concepts across methodologies used in standards (e.g., mapping to SPEM, ISO/IEC 12207, 15288, 15504, UML as referenced in Annex B).
• Organizations adopting or integrating methods - assemble methodologies from repositories of method fragments, compare alternatives, and ensure consistent terminology and assessment.

Related standards and practical value

• Direct mappings and comparisons are provided to other metamodelling approaches (OMG SPEM, ISO/IEC 12207/15288, ISO/IEC 15504, UML), facilitating method harmonization and tool interoperability.
• Conformance to ISO/IEC 24744:2014 promotes consistent methodology definitions, smoother integration across teams and tools, and reuse of method fragments for faster, more predictable process design.

Keywords: ISO/IEC 24744:2014, SEMDM, metamodel, development methodologies, powertype, method engineering, information‑based domains, process–product integration, tool interoperability.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 24744
Second edition
2014-11-15
Software engineering — Metamodel for
development methodologies
Ingénierie du logiciel — Métamodèle pour les méthodologies de
développement
Reference number
©
ISO/IEC 2014
©  ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2014 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1  Scope . 1
2  Conformance . 1
3  Terms and definitions . 1
4  Naming, diagramming and definition conventions, and abbreviated terms . 3
4.1  Naming, diagramming and definition conventions . 3
4.2  Abbreviations . 4
5  Basic Concepts . 4
5.1  Method Engineering . 5
5.2  Dual-Layer Modelling . 5
5.3  Powertypes and Clabjects . 5
5.4  Uniting Process and Product . 6
5.5  Process Assessment . 6
6  Introduction to the SEMDM . 7
6.1  Highly Abstract View . 7
6.2  Abstract View and Core Classes . 7
6.3  Process Classes . 8
6.4  Producer Classes . 10
6.5  Product Classes . 11
6.6  Connection between Process and Product . 12
6.7  Support Classes . 13
7  Metamodel Elements . 14
7.1  Classes . 14
7.2  Enumerated Types . 61
8  Using the Metamodel . 62
8.1  Usage Rules . 62
8.2  Usage Guidelines . 63
9  Extending the Metamodel . 64
9.1  Extension Rules . 64
9.2  Extension Guidelines . 65
Annex A (informative) Worked Example . 66
A.1 SimpleMethod Description . 66
A.2 Construction of Process Components . 66
A.3 Construction of Producer Components . 68
A.4 Construction of Product Components . 68
A.5 Connection Between Process and Product Components . 70
Annex B (informative) Mappings to Other Metamodelling Approaches . 72
B.1 OMG SPEM 1.1 . 72
B.2 OOSPICE . 73
B.3 OPEN . 73
B.4 LiveNet . 74
B.5 ISO/IEC 12207 and 15288 . 74
B.6 ISO/IEC 15504 (SPICE). 75
B.7 ISO/IEC 19501 (UML 1.4.2) . 75
Annex C (informative) Graphical Notation . 76
C.1 Introduction . 76
© ISO/IEC 2014 – All rights reserved iii

C.2 Notation Elements .77
C.3 Diagram Types .88
C.4 Abbreviation Tables .94
Bibliography .96

Table of Figures
Figure 1 – The three areas of expertise, or domains, which act as a context for SEMDM. Arrows mean "is
represented by". . 4
Figure 2 – Example of a powertype pattern and clabject. The Document class is partitioned by the
DocumentKind powertype. The RequirementsSpecificationDocument class plus the rsd object represent a
particular kind of document, making up a clabject. The rsd1 object represents a particular requirements
specification document. . 6
Figure 3 – Highly abstract view of the SEMDM . 7
Figure 4 – Abstract view of the SEMDM, showing the core classes in the metamodel . 8
Figure 5 – Work units . 9
Figure 6 – Stages . 10
Figure 7 – Producers . 11
Figure 8 – Work product and modelling classes . 12
Figure 9 – Actions and constraints . 13
Figure 10 – Support classes . 13
Figure C.1 – A lifecycle diagram showing the temporal structure of a complete method . 89
Figure C.2 – A lifecycle diagram showing the content structure as well as the temporal structure of a method
.................................................................................................................................................................... 90
Figure C.3 – An enactment diagram for the “Construction” phase kind of Figure C.2 . 91
Figure C.4 – A dependency diagram based on a refinement of Figure C.2 . 92
Figure C.5 – A process diagram showing the details of the “Requirements Engineering” and “Requirements
Quality Assurance” processes . 93
Figure C.6 – An action diagram showing the interaction between some task kinds pertaining to the
“Requirements Engineering” and “Requirements Quality Assurance” processes and some related
document kinds . 94

iv © ISO/IEC 2014 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO
list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 7, Systems and
Software engineering.
This second edition cancels and replaces the first edition (ISO/IEC 24744:2007), which has been technically
revised. It also incorporates the Amendment ISO/IEC 24744:2007/Amd.1:2010.
© ISO/IEC 2014 – All rights reserved v

Introduction
Development methodologies may be described in the context of an underpinning metamodel, but the precise
mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do
not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the
elements that compose the methodology and, at the same time, of the entities (such as work products)
created when the methodology is applied. This document introduces, as a (potential) standard, the Software
Engineering Metamodel for Development Methodologies, a comprehensive metamodel that makes use of a
new approach to defining methodologies based on the concept of powertype. The SEMDM is aimed to the
definition of methodologies in information-based domains, i.e. areas characterized by their intensive reliance
on information management and processing, such as software, business or systems engineering. The
SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks,
allowing the seamless integration of process, modelling and people aspects of methodologies. Refer to
Annex B where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided.
Various methodologies are defined, used, or implied by a growing number of standards and it is desirable that
the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM.
Conformance to this metamodel will ensure a consistent approach to defining each methodology with
consistent concepts and terminology.
This document also presents a proposed notation for the ISO/IEC 24744 standard metamodel. The notation
presented here is mainly graphical and supports most of the classes found in ISO/IEC 24744.
Purpose
The SEMDM follows an approach that is minimalist in depth but very rich in width (encompassing domains
that are seldom addressed by a single approach). It therefore includes only those higher-level concepts truly
generic across a wide range of application areas and at a higher level of abstraction than other extant
metamodels. The major aim of the SEMDM is to deliver a highly generic metamodel that does not
unnecessarily constrain the resulting methodologies, while providing for the creation of rich and expressive
instances.
In order to achieve this objective, the SEMDM incorporates ideas from several metamodel approaches plus
some results of recent research (see [4, 5, 6, 7, 9, 10, 17] for details). This will facilitate:
 The communication between method engineers, and between method engineers and users of
methodology (i.e. developers).
 The assembly of methodologies from pre-existing repositories of method fragments.
 The creation of methodology metamodels by extending the standard metamodel via the extension
mechanisms provided to this effect.
 The comparison and integration of methodologies and associated metamodels.
 The interoperability of modelling and methodology support tools.
The relation of SEMDM to some existing methodologies and metamodels is illustrated in Annex B.
Audience
Since many classes in the SEMDM represent the endeavour domain (as opposed to the methodology domain),
it might look like developers enacting the methodology would be direct users of the metamodel. This is not
true. Classes in the SEMDM that model endeavour-level elements serve for the method engineer to establish
the structure and behaviour of the endeavour domain, and are not used directly during enactment. Only
vi © ISO/IEC 2014 – All rights reserved

methodology elements, i.e. classes and objects created by the method engineer from the metamodel, are
used by developers at the endeavour level, thus supporting both the creation of “packaged” methodologies as
well as tailored, project-specific methodologies.
Here the term “method engineer” refers collectively to either a person constructing a methodology on site for a
particular purpose or a person creating a "packaged" methodology as a "shrink-wrapped" process product.

© ISO/IEC 2014 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 24744:2014(E)

Software engineering — Metamodel for development
methodologies
1 Scope
This International Standard defines the Software Engineering Metamodel for Development Methodologies
(SEMDM), which establishes a formal framework for the definition and extension of development
methodologies for information-based domains (IBD), such as software, business or systems, including three
major aspects: the process to follow, the products to use and generate, and the people and tools involved.
This metamodel can serve as a formal basis for the definition and extension of any IBD development
methodology and of any associated metamodel, and will be typically used by method engineers while
undertaking such definition and extension tasks.
The metamodel does not rely upon nor dictate any particular approach to IBD development and is, in fact,
sufficiently generic to accommodate any specific approach such as object-orientation, agent-orientation,
component-based development, etc.
2 Conformance
A metamodel is defined in accordance with this International Standard if it:
a. Describes the scope of the concepts in the metamodel in relation to the scope of the elements defined
in clause 7.
b. Defines the mapping between the concepts that are addressed in the metamodel, and that are within
the scope of this International Standard, and the corresponding elements of this Standard (i.e. the
elements of the standard cannot be substituted by others of identical intent but different construction).
A development methodology is defined in accordance with this International Standard if it is generated from a
conformant metamodel as defined in the first paragraph of this clause (2 Conformance).
A development or engineering tool is developed in accordance with this International Standard if it implements
a conformant metamodel as defined in the first paragraph of this clause (2 Conformance). If the purpose of the
tool involves the creation of methodologies, then it is developed in accordance with this Standard if it also
implements the necessary features so as to make the mechanisms described in sub-clause 8.1 available to
the tool’s users. If the purpose of the tool involves the extension of the metamodel, then it is developed in
accordance with this Standard if it also implements the necessary features so as to make the mechanisms
described in sub-clause 9.1 available to the tool’s users.
NOTE 1 The metamodel thus defined does not necessarily have to include all the elements defined in clause 7 – only
those that are relevant to the purpose of the said metamodel are required.
NOTE 2 Conformance for methodologies or conformance for tools can be established without any necessity of
explicitly including the detailed metamodel for any relevant work product kind or model unit kind. It is adequate to define
the mappings of any such work products to the WorkProductKind and ModelUnitKind classes of the SEMDM.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE This Standard uses a self-consistent set of core concepts that is as compatible as possible with other
standards (such as ISO/IEC 12207, ISO/IEC 15504, etc.).
© ISO/IEC 2014 – All rights reserved 1

3.1
information-based domain
realm of activity for which information is the most valuable asset
Note 1 to entry: This means that information creation, manipulation and dissemination are the most important
activities within information-based domains. Typical information-based domains are software and systems engineering,
business process reengineering and knowledge management.
3.2
methodology
method
specification of the process to follow together with the work products to be used and generated, plus the
consideration of the people and tools involved, during an IBD development effort
Note 1 to entry: A methodology specifies the process to be executed, usually as a set of related activities, tasks and/or
techniques, together with what work products must be manipulated (created, used or changed) at each moment and by
whom, possibly including models, documents and other inputs and outputs. In turn, specifying the models that must be
dealt with implies defining the basic building blocks that should be used to construct these models.
Note 2 to entry: The term “methodology” is used throughout this Standard, reserving the term “method” for
conventional phrases such as “method engineer” or “method fragment”.
3.3
metamodel
specification of the concepts, relationships and rules that are used to define a methodology
3.4
endeavour
IBD development effort aimed at the delivery of some product or service through the application of a
methodology
Note 1 to entry: Projects, programmes and infrastructural duties are examples of endeavours.
3.5
methodology element
simple component of a methodology
Note 1 to entry: Usually, methodology elements include the specification of what tasks, activities, techniques, models,
documents, languages and/or notations can or must be used when applying the methodology. Methodology elements are
related to each other, comprising a network of abstract concepts. Typical methodology elements are Capture
Requirements, Write Code for Methods (kinds of tasks), Requirements Engineering, High-Level Modelling (kinds of
activities), Pseudo-code, Dependency Graphs (notations), Class, Attribute (kinds of model building blocks), Class Model,
Class Diagram, Requirements Specification (kind of work products), etc.
3.6
endeavour element
simple component of an endeavour
Note 1 to entry: During the execution of an endeavour, developers create a number of endeavour elements, such as
tasks, models, classes, documents, etc. Some examples of endeavour elements are Customer, Invoice (classes), Name,
Age (attributes), High-Level Class Model number 17 (a model), System Requirements Description (a document), Coding
Cycle number 2, Coding Cycle number 3 (tasks), etc.
3.7
generation
act of defining and describing a methodology from a particular metamodel
Note 1 to entry: Generating a methodology includes explaining the structural position and semantics of each
methodology element using the selected metamodel. Thus, what methodology elements are possible, and how they relate
to each other, are constrained by such a metamodel. Usually, method engineers perform generation, yielding a complete
and usable methodology.
2 © ISO/IEC 2014 – All rights reserved

3.8
enactment
act of applying a methodology for some particular purpose, typically an endeavour
Note 1 to entry: Enacting a methodology includes using the existing generated methodology to create endeavour
elements and, eventually, obtain the targeted IBD system. Thus, what kinds of endeavour elements can be created, and
how they relate to each other, is governed by the methodology being used. Usually, technical managers, together with
other developers, perform enactment.
3.9
method engineer
person who designs, builds, extends and maintains methodologies
Note 1 to entry: Method engineers create methodologies from metamodels via generation.
3.10
developer
person who applies a methodology for some specific job, usually an endeavour
Note 1 to entry: Developers apply methodologies via enactment.
3.11
powertype
type, the instances of which are subtypes of another type called the “partitioned type”
Note 1 to entry: This definition must be interpreted in the context of the object-oriented paradigm. For example, the
class TreeSpecies is a powertype of the class Tree, since each instance of TreeSpecies is also a subclass of Tree.
3.12
clabject
dual entity that is a class and an object at the same time
Note 1 to entry: This definition must be interpreted in the context of the object-oriented paradigm. Because of their
dual nature, clabjects exhibit a class facet and an object facet, and can work as either at any time. Instances of
powertypes are usually viewed as clabjects, since they are objects (because they are instances of a type, the powertype)
and also classes (subtypes of the partitioned type).
4 Naming, diagramming and definition conventions, and abbreviated terms
4.1 Naming, diagramming and definition conventions
The SEMDM is defined using different kinds of instruments that complement each other. These instruments
are:
 Definitions. Each concept in the SEMDM is defined using natural language. Also, a description is
given, including the context in which the concept occurs and its most distinctive properties. Examples
are also given for each concept.
 Class diagrams. Concepts of interest to the SEMDM are formalized as classes. Consequently, class
diagrams are used to show these classes together with their attributes and relationships. UML 1.4.2
(i.e. ISO/IEC 19501) is used throughout with some noticeable exceptions. First, a special notation is
used to depict powertype patterns, consisting of a dashed line between the powertype and the
partitioned type with a black dot on the side of the powertype. Secondly, “white diamonds” are used to
depict whole/part relationships without making any reference to their secondary characteristics (see
[2] for more details).
 Text tables. Text tables are included to provide additional descriptions of attributes and relationships.
 Mappings to other approaches. Each concept in the SEMDM is related to equivalent or similar
concepts in other metamodelling approaches, so that translation between approaches is easier.

These instruments are used simultaneously.
© ISO/IEC 2014 – All rights reserved 3

Two different types of class diagrams are provided. Clause 6 presents some diagrams that aim to give an
overall picture of the structure of SEMDM. These diagrams are designed to give an idea of the main classes
and relationships within the metamodel, and are not comprehensive, i.e. do not display every single detail of
the metamodel. Clause 7, on the other hand, includes a class diagram for each class in the metamodel. The
class under discussion is shown in the centre, and is surrounded by its closest neighbours. Each of these
diagrams, together with the accompanying attribute and relationship tables, do contain all the details for the
particular class being discussed.
The philosophy of the SEMDM is to offer broad coverage for all the issues often found in methodology
definition avoiding, at the same time, unnecessary structural constraints on the resultant methodologies.
Therefore, only a minimal set of attributes and associations is provided by the metamodel. Using powertype
pattern instantiation (see sub-clause 8.1.2), and thanks to the usage of powertypes in the metamodel,
additional attributes and associations can be easily added at the methodology domain.
4.2 Abbreviations
IBD information-based domain
5 Basic Concepts
Metamodels are useful for specifying the concepts, rules and relationships used to define methodologies.
Although it is possible to describe a methodology without an explicit metamodel, formalizing the underpinning
ideas of the methodology in question is valuable when checking its consistency or when planning extensions
or modifications. A good metamodel must address all of the different aspects of methodologies, i.e. the
process to follow, the work products to be generated and those responsible for making all this happen. In turn,
specifying the work products that must be developed implies defining the basic modelling building blocks from
which they are built.
Metamodels are often used by method engineers to construct or modify methodologies. In turn,
methodologies are used by developers to construct products or deliver services in the context of endeavours.
Metamodel, methodology and endeavour constitute, in this approach, three different areas of expertise that, at
the same time, correspond to three different levels of abstraction and three different sets of fundamental
concepts. As the work performed by developers at the endeavour level is constrained and directed by the
methodology in use, the work performed by the method engineer at the methodology level is constrained and
directed by the chosen metamodel. Traditionally, these relationships between “modelling layers”, here called
“domains”, are seen as instance-of relationships, in which elements in one layer or domain are instances of
some element in the layer or domain below (Figure 1).
Endeavour Domain
Methodology Domain
Metamodel Domain
Figure 1 – The three areas of expertise, or domains, which act as a context for SEMDM. Arrows mean
"is represented by".
Regarding the methodology domain, it must be noted that more than one “methodology” may exist at this level,
interlinked by refinement relationships. For example, it is common that organizations create organization-wide,
generic methodologies from a metamodel, and then adjust and customize said methodologies for each
particular endeavour. In cases like this, both kinds of methodologies (organization-wide and endeavour-
4 © ISO/IEC 2014 – All rights reserved

specific) belong in the methodology domain and are connected via a refinement relationship (as opposed to
instance-of). Cases with more than two steps of refinement are also possible.
5.1 Method Engineering
In accordance with most of the above-mentioned approaches to metamodelling, the SEMDM accepts the idea
of method engineering (see [3, 18] for an introduction), defining the metamodel as a set of classes from which
“methodology chunks” can be generated and then composed into a usable methodology [8]. However, the
method engineering approach has been used primarily in the process realm (and hence the often-used name
of “process engineering”), whereas the SEMDM extends it to the modelling domain as well (see next section).
5.2 Dual-Layer Modelling
Most metamodelling approaches define a metamodel as a model of a modelling language, process or
methodology that developers may employ. Following this conventional approach, classes in the metamodel
are used by the method engineer to create instances (i.e. objects) in the methodology domain and thus
generate a methodology. However, these objects in the methodology domain are often used as classes by
developers to create elements in the endeavour domain during methodology enactment. This apparent
contradiction, not solved by any of the existing metamodelling approaches, is addressed by the SEMDM and
solved by conceiving a metamodel as a model of both the methodology and the endeavour domains. While
offering a strict model of the endeavour domain in the metamodel, the SEMDM maintains a high degree of
flexibility, allowing the method engineer to configure the development process and address the modelling
issues as necessary.
5.3 Powertypes and Clabjects
Two concepts, new to methodology modelling, must be introduced in order to support the features required by
the SEMDM. First of all, modelling the methodology and endeavour domains at the same time gives rise to
pairs of classes in the metamodel that represent the same concept at different levels of classification. For
example, the Document class in the metamodel represents documents managed by developers, while the
DocumentKind class in the metamodel represents different kinds of documents that can be managed by
developers. Notice how Document represents a concept that belongs in the endeavour domain (documents
that people manage) while DocumentKind represents a concept that belongs in the methodology domain
(kinds of documents described by the methodology). For example, the concept of ClassDiagram is an
instance of DocumentKind, but a given class diagram in the endeavour, with a particular author and creation
time, is an instance of Document. In turn, these two classes are related by a classification relationship, since
every document (in the endeavour domain) is an example (instance) of some particular kind of document (as
defined in the methodology domain). This pattern of two classes in which one of them represents “kinds of”
the other is called a powertype pattern, since the class with the “kind” suffix is a powertype (see [15, 16] for an
introduction to the powertype concept) of the other class, called the partitioned type. In this Standard, the
notation Document/*Kind is used to refer to the powertype pattern formed by the powertype DocumentKind
and the partitioned type Document.
At the same time, endeavour-level elements must be instances of some methodology-level elements, and
methodology-level elements must be instances of metamodel-level elements. This means that (at least some)
elements in the methodology domain act at the same time as objects (since they are instances of metamodel
classes) and classes (since endeavour-level elements are instances of them). This class/object hybrid
concept has been described in [1] and named clabject. Clabjects have a class facet and an object facet.
Within the SEMDM, clabjects are the means to construct a methodology from the powertype patterns found in
the metamodel. In this way, a powertype pattern can be “instantiated” into a clabject by making the object
facet of the clabject an instance of the powertype class in the powertype pattern, and the class facet of the
clabject a subclass of the partitioned type in the powertype pattern. For example, a method engineer wanting
to support requirement specification documents in the methodology that he or she is constructing would create
the clabject RequirementsSpecificationDocument (in the methodology domain) as an instance of Document-
Kind and a subclass of Document. By using clabjects at the methodology level, every single element
susceptible of being instantiated during enactment is represented by a class, which is appropriate for
instantiation, and by an object, which is appropriate for automated manipulation by tools. See Figure 2 for an
example.
© ISO/IEC 2014 – All rights reserved 5

Document
DocumentKind
Title
Metamodel
Version
Name
CreationTime
Description
LastChangeTime
Status
rsd: DocumentKind
Requirements
SpecificationDocument
Methodology
Name = “RequirementsSpecificationDocument”
SignOffTime Description = “A document that describes the
requirements of a system…”
rds1: Requirements
SpecificationDocument
Title = “Requirements for My System”
Version = “1.2”
Endeavour
CreationTime = 21-Apr-2013
LastChangeTime = 3-May-2013
Status = Complete
SignOffTime = null
Figure 2 – Example of a powertype pattern and clabject. The Document class is partitioned by the
DocumentKind powertype. The RequirementsSpecificationDocument class plus the rsd object
represent a particular kind of document, making up a clabject. The rsd1 object represents a particular
requirements specification document.
Notice how a given attribute of the powertype class acts as discriminator of the powertype pattern, meaning
that unique values of that attribute will be assigned to each of the instances of the powertype class, and the
same value will be used to name the corresponding subclass of the partitioned type. For example, in the
Document/*Kind powertype pattern, DocumentKind.Name is the discriminator. This means that each instance
of DocumentKind will have a unique value for Name and its associated class (a subtype of Document) will be
named with that value. Following the previous example, a given instance of DocumentKind would have Name
= “ClassDiagram”, and its corresponding subclass of Document would be called ClassDiagram. The
discriminator attribute thus acts as the bond between the two facets of the clabject.
5.4 Uniting Process and Product
Most of the existing metamodelling approaches focus either on the process or on the modelling (i.e. product)
side of methodologies. Most of these approaches, however, offer connection points for “plugging in” the
complementary, as yet undefined, component of a full-fledged methodology. The SEMDM goes a step beyond
by offering a complete metamodel that covers the process and modelling aspects of methodologies evenly.
Not doing so would be like trying to define the actions to be performed without defining the concepts on which
these actions must act (process focus), or the concepts to use without knowing what to do with them
(modelling focus). This approach has the benefit of allowing a rich definition, at the methodology level, of the
interactions between a process and the products generated by it.
5.5 Process Assessment
Usually, the maturity or capability of an organization regarding the performance of a process is measured by
assigning a capability level to its enactment. The SEMDM adopts the concept of capability level and attaches
it to work unit kinds, so a method engineer can easily establish the minimum capability level at which each
work unit kind may be performed. Although different assessment approaches and standards have slightly
different ranges of capability levels (see [11] for an example), the following exemplar list is generic enough to
be applicable to nearly every situation:
 Incomplete (level 0): the organization fails to successfully execute the process.
6 © ISO/IEC 2014 – All rights reserved

 Performed (level 1): the process is successfully executed but may not be rigorously planned and
tracked.
 Managed (level 2): the process is planned and tracked while it is performed; work products conform
to specified standards and requirements.
 Established (level 3): the process is performed according to a well-defined specification that may use
tailored versions of standards.
 Predictable (level 4): measures of process performance are collected and analysed, leading to a
quantitative understanding of process capability and an improved ability to predict performance.
 Optimizing (level 5): continuous process improvement against business goals is achieved through
quantitative feedback.
6 Introduction to the SEMDM
6.1 Highly Abstract View
From the most abstract perspective, the SEMDM defines the classes MethodologyElement and Endeavour-
Element that represent, respectively, elements in the methodology and the endeavour domains. Methodology-
Element, in turn, is specialized into Resource and Template, corresponding to methodology elements that are
used “as is” at the endeavour level (i.e. resources) and methodology elements that are used by instantiation at
the endeavour level (i.e. templates) [6]. Since Template is the abstract type of all elements at the methodology
level that will have instances at the endeavour level, and EndeavourElement is the abstract superclass of the
same elements, these two classes form a powertype pattern in which Template is the powertype, Endeavour-
Element is the partitioned type and Template.Name is the discriminant. Powertype patterns and their usage
are discussed in sub-clause 5.3. See Figure 3 for a graphical representation.
Element
+DisplayText
MethodologyElement
Resource Template EndeavourElement
+Name
Figure 3 – Highly abstract view of the SEMDM
At the same time, a top class Element is defined to generalize MethodologyElement and EndeavourElement
and allow homogeneous treatment of all elements across the methodology and endeavour domains when
necessary. The DisplayText attribute of Element gives a short text describing each instance suitable to be
shown to the instance’s final users.
6.2 Abstract View and Core Classes
There are three clusters of core classes: methodology templates, specializing from Template; methodology
resources, specializing from Resource; and endeavour classes, specializing from EndeavourElement.
The powertype pattern formed by Template and EndeavourElement is refined into more specialized
powertype patterns formed by subclasses of these two, namely: StageKind and Stage (representing a
managed time frame within an endeavour), WorkUnitKind and WorkUnit (a job performed, or intended to be
performed, within an endeavour), WorkProductKind and WorkProduct (an artefact of interest for the
© ISO/IEC 2014 – All rights reserved 7

endeavour), ProducerKind and Producer (an agent that has the responsibility to execute work units) and
ModelUnitKind and ModelUnit (an atomic component of a model). See Figure 4 for a graphical depiction.

Figure 4 – Abstract view of the SEMDM, showing the core classes in the metamodel
At the same time, Resource is specialized into Language (a structure of model unit kinds that focus on a
particular modelling perspective), Notation (a concrete syntax, usually graphical, which can be used to depict
models created with certain languages), Guideline (an indication of how some methodology elements can be
used) and Constraint (a condition that holds or must hold at certain point in time).
6.3 Process Classes
The WorkUnit/*Kind powertype pattern is specialized into Process/*Kind (large-grained, operating within a
given area of expertise), Task/*Kind (small-grained, focusing on what must be done in order to achieve a
given purpose) and Technique/*Kind (small-grained, focusing on how the given purpose may be achieved).
WorkUnitKind is characterized by a purpose and a minimum capability level at which it makes sense to be
performed, and is related to OutcomeKind in a many-to-many fashion,
...