Analysis of the Completeness and Quality of the Essence

paluno The Ruhr Institute for Software Technology

Institut für Informatik und Wirtschaftsinformatik Universität Duisburg-Essen

Masterarbeit

Analysis of the Completeness and Quality of the Essence specification

Use Case Analysis of the Essence Kernel and Language for Software Engineering Methods

Nicole Ignaciuk

2263948

Essen, 16. Juni 2014 Betreuung: Michael Striewe Erstgutachten: Prof. Dr. Michael Goedicke Zweitgutachten: Prof. Dr. Volker Gruhn Studiengang: Angewandte Informatik - Systems Engineering

Eidesstattliche Erklärung

Analysis of the Completeness and Quality of the Essence specification II

Eidesstattliche Erklärung

Hiermit versichere ich, dass ich die vorliegende Arbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Ich habe alle Stellen, die ich aus den Quellen wörtlich oder inhaltlich entnommen habe, als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.

(Nicole Ignaciuk)

Essen, am 16. Juni 2014

Zusammenfassung

Analysis of the Completeness and Quality of the Essence specification III

Zusammenfassung

Die vorliegende Masterarbeit beschäftigt sich mit der Essence Sprach- und Kernel-Spezifikation zur Beschreibung und Ausführung von Methoden im Software Engineering. Die Spezifikation wurde im Juli 2013 als OMG Standard im Beta Status veröffentlicht. Im Vorfeld der Spezifikation der Essence Sprache und des Kernels wurde eine Reihe von Anwendungsfällen definiert um die Anforderungen an die Spezifikation aufzustellen. Im Rahmen der finalen Standardisierung ist es das Ziel dieser Masterarbeit, die Qualität und Vollständigkeit der Spezifikation auf Basis dieser Anwendungsfälle zu analysieren. Als Ergebnis bewertet die Arbeit die Qualität und Vollständigkeit der Spezifikation aus Sicht der verschiedenen Akteure.

Abstract

This Master Thesis deals with the Essence language and kernel specification for the definition and the enactment of software engineering methods. The specification was published in July 2013 as OMG standard in beta status. Prior to the specification of the Essence language and kernel, a set of use cases was defined to establish the requirements. In the context of the finalisation of the standardisation, the goal of this thesis is to analyse the quality and completeness of the specification based on the defined use cases. As a result, the thesis evaluates the quality and completeness of the specification from the viewpoint of the different actors.

List of Figures

Analysis of the Completeness and Quality of the Essence specification IV

List of Figures

Figure 1 Layered architecture _____________________________________________ 11

Figure 2 Conceptual overview of the Essence language _________________________ 12

Figure 3 Language meta-levels ____________________________________________ 13

Figure 4 Example of Alpha States (Opportunity alpha) [OMG 2013] _______________ 16

Figure 5 Overview of Essence kernel alphas [OMG 2013] ________________________ 17

Figure 6 Overview of Essence kernel activity spaces [OMG 2013] _________________ 18

Figure 7 Overview of Essence kernel competencies [OMG 2013] __________________ 19

Figure 8 Use case "Define practice definition" _________________________________ 20

Figure 9 Use case "Extend practice" ________________________________________ 21

Figure 10 Use case actors ________________________________________________ 26

Figure 11 Conceptual overview of practice definition ___________________________ 38

Figure 12 Use Case “Define practice definition” - Step 2 ________________________ 42



Figure 15 Beginning and end of a practice ___________________________________ 89

Figure 16 Decomposition of a practice into the three areas of concern _____________ 91

Figure 17 Decomposition of a practice - Scrum example ________________________ 92

Figure 18 Decomposition of a practice into Software Engineering phases ___________ 93

Figure 19 Application development lifecycle example - Support phase _____________ 93

Figure 20 Decomposition of a practice - Combined view_________________________ 94

Figure 21 Evaluation of completion criteria and checkpoints _____________________ 96

Figure 22 Guidance for process configuration [Kruchten 2013] __________________ 104

Figure 23 Use Case "Plan based on method" - Step 1__________________________ 111




Figure 27 Essence monitoring and steering approach [Péraire and Sedano 2014] ____ 123

List of Tables

Analysis of the Completeness and Quality of the Essence specification V

List of Tables

Table 1 Example of checklist (Opportunity alpha) ______________________________ 16

Table 2 Example of Activity Space (Explore Possibilities) ________________________ 18

Table 3 Relation of use cases to phases of software process management __________ 22

Table 4 Classification of use cases _________________________________________ 23

Table 5 Use cases: documented attributes - management information _____________ 23

Table 6 Use cases: documented attributes - reference to context _________________ 24

Table 7 Use cases: documented attributes - content ___________________________ 24

Table 8 Use cases: documented attributes - supplementary information ____________ 25

Table 9 Use cases: documented attributes - validation__________________________ 25

Table 10 Comparison of use case actors _____________________________________ 27

Table 11 Defined and derived actors for all use cases __________________________ 28

Table 12 Use case template ______________________________________________ 29

Table 13 Use case “Define practice definition” ________________________________ 35

Table 14 Use case “Establish well-formed practice” ____________________________ 56

Table 15 Issues in well-formedness rules of abstract superclasses ________________ 71

Table 16 Issues in wellformdness rules of language constructs in basic path _________ 72

Table 17 Multiplicities of role names in singular and plural _______________________ 73

Table 18 Use case “Extend practice” ________________________________________ 74

Table 19 Use case “Compose method” ______________________________________ 79

Table 20 Use case “Evaluate method or practice” ______________________________ 87

Table 21 Use case “Compare method” _____________________________________ 101

Table 22 Domain characteristics __________________________________________ 105

Table 23 Use case “Plan based on method” _________________________________ 108

Table 24 Use case “Simulate method or practice” _____________________________ 116

Table 25 Use Case “Teach kernel language” _________________________________ 118

Table 26 Use Case “Understand Software Engineering” ________________________ 125

Table 27 Fulfilment of use cases __________________________________________ 130

Table 28 Quality and completeness form the view of the actors __________________ 131

Table of Contents

Analysis of the Completeness and Quality of the Essence specification VI

Table of Contents

Eidesstattliche Erklärung ....................................................................... II

Zusammenfassung ............................................................................... III

Abstract ................................................................................................ III

List of Figures ........................................................................................ IV

List of Tables .......................................................................................... V

Table of Contents .................................................................................. VI

1 Introduction ...................................................................................... 9

2 Essence Specification ....................................................................... 10

2.1 Guiding Principles ........................................................................ 10

2.2 Essence Language ....................................................................... 12

2.2.1 Metamodelling Technique .................................................... 12

2.2.2 Abstract Syntax and Semantics ............................................ 14

2.3 Essence Kernel ............................................................................ 14

2.3.1 Areas of concern ................................................................ 14

2.3.2 Alphas .............................................................................. 15

2.3.3 Activity Spaces .................................................................. 17

2.3.4 Competencies .................................................................... 18

3 Use Cases ........................................................................................ 20

3.1 Order of Use Cases ...................................................................... 21

3.2 Documented Use Case Attributes ................................................... 23

3.3 Use Case Actors .......................................................................... 25

4 Method ............................................................................................. 29

4.1 Formal Adaptation of Use Cases ..................................................... 29

4.2 Analysis Procedure ....................................................................... 30

4.3 Judgement of Quality and Completeness ......................................... 30

4.4 Naming Conventions .................................................................... 31

5 Analysis and Discussion ................................................................... 32

5.1 Use Case “Define practice definition” .............................................. 32

5.1.1 Definition .......................................................................... 32

5.1.2 Requirements .................................................................... 36

Table of Contents

Analysis of the Completeness and Quality of the Essence specification VII

5.1.3 Alternative paths ............................................................... 48

5.1.4 Qualities ........................................................................... 51

5.1.5 Discussion ........................................................................ 55

5.2 Use Case “Establish well-formed practice” ....................................... 55

5.2.1 Definition .......................................................................... 55

5.2.2 Requirements .................................................................... 56

5.2.3 Pre-Condition .................................................................... 58

5.2.4 Basic Path ......................................................................... 63

5.2.5 Alternative path ................................................................. 70

5.2.6 Discussion ........................................................................ 71

5.3 Use Case “Extend practice” ........................................................... 73

5.3.1 Definition .......................................................................... 73

5.3.2 Requirements .................................................................... 74

5.3.3 Basic Path ......................................................................... 74

5.3.4 Discussion ........................................................................ 78

5.4 Use Case “Compose method” ........................................................ 78

5.4.1 Definition .......................................................................... 78

5.4.2 Requirements .................................................................... 79

5.4.3 Basic path ......................................................................... 80

5.4.4 Alternative paths ............................................................... 86

5.4.5 Qualities ........................................................................... 86

5.4.6 Discussion ........................................................................ 86

5.5 Use Case “Evaluate method or practice” .......................................... 86

5.5.1 Definition .......................................................................... 86

5.5.2 Requirements .................................................................... 87

5.5.3 Basic Path 1: Evaluate effectiveness ..................................... 88

5.5.4 Basic Path 2: Evaluate efficiency .......................................... 98

5.5.5 Discussion ...................................................................... 100

5.6 Use Case “Compare method” ....................................................... 100

5.6.1 Definition ........................................................................ 100

5.6.2 Requirements .................................................................. 101

5.6.3 Related Work .................................................................. 102

Table of Contents

Analysis of the Completeness and Quality of the Essence specification VIII

5.6.4 Basic Path ....................................................................... 104

5.6.5 Alternative Paths ............................................................. 106

5.6.6 Discussion ...................................................................... 107

5.7 Use Case “Plan based on method” ................................................ 107

5.7.1 Definition ........................................................................ 107

5.7.2 Requirements .................................................................. 108

5.7.3 Basic Path ....................................................................... 110


5.7.5 Discussion ...................................................................... 116

5.8 Use Case “Simulate method or practice” ....................................... 116

5.8.1 Definition ........................................................................ 116

5.8.2 Requirements .................................................................. 117

5.8.3 Discussion ...................................................................... 118

5.9 Use Case “Teach kernel language” ............................................... 118

5.9.1 Definition ........................................................................ 118

5.9.2 Requirements .................................................................. 119

5.9.3 Basic Path ....................................................................... 120

5.9.4 Experiences .................................................................... 121

5.9.5 Discussion ...................................................................... 124

5.10 Use Case “Understand Software Engineering” ................................ 124

5.10.1 Definition ........................................................................ 124

5.10.2 Requirements .................................................................. 125

5.10.3 Basic Path ....................................................................... 126


5.10.5 Discussion ...................................................................... 128

6 Conclusion and Future Work .......................................................... 130

References ......................................................................................... 132

Appendix A: Documented Use Cases ........................................................ i

Introduction

Analysis of the Completeness and Quality of the Essence specification 9

1 Introduction

The SEMAT initiative was found in 2009 by Ivar Jacobson, Bertrand Meyer and Richard Soley with the aim of establishing a common ground for Software Engineering based on solid theory, proven principles and best practices for the application, education and research in Software Engineering. By now, the group is supported by a diverse group of internationally recognized software engineering professionals both from academia and industry with most of them having had great influence on the progress of software engineering as an engineering discipline within the last decades.

The objective of the initiative was to create a kernel and a language that are scalable, extensible, and easy to use and that allow people to describe the essentials of their existing and future methods and practices so that they can be composed, compared, evaluated, tailored, used, adapted, simulated and measured by practitioners as well as taught and researched by academics and researchers [Jacobson et al. 2012]. With special emphasis on the practitioners who apply software engineering methods in practice, the kernel aims to provide an actionable framework for teams to assemble, compose, evaluate and continuously improve their way of working, to reason about the progress they are making as well as the health of their endeavour and to understand where they are, what they should do next, and where they need to improve [Jacobson et al. 2012b].

In July 2013, the group’s efforts resulted in the specification of the Essence language and kernel as OMG standard in beta status [OMG 2013]. The aim is to achieve the status of a formally adopted standard in the course of 2014. In the initial phase of the SEMAT initiative and prior to the specification of the Essence language and kernel, the group elaborated on a set of use cases in order to gather and to define the requirements. The use cases encompass various requirements regarding the specification of the Essence kernel and language from the view of different actors such as the methodologist or the project manager. Within the finalisation phase of the standardization process, an important question is thus in how far the specification meets the demands of the defined use cases, especially from the viewpoint of the practitioners.

The goal of this master thesis is thus to reason about the quality and completeness of the specification in the scope of the defined use cases. Therefore, both the use cases and the specification of the Essence language and kernel are subject to a detailed analysis. As a result, this work evaluates the quality and completeness of the specification from the viewpoint of the different actors.

Section 2 provides a conceptual overview on the Essence kernel and language. Section 3 analysis the defined use cases in order to process the analysis of the specification. Section 4 outlines the analysis approach and describes how the quality and completeness of the specification is evaluated. Section 5 analyses each use case in detail and reasons in how far the specification fulfils the use case. Section 6 summarizes and discusses the findings.

Essence Specification


2 Essence Specification

The Essence specification defines a domain-specific language (i.e. the Essence language) and a kernel (i.e. the Essence kernel) in order to support the definition and the enactment of methods in the context of software engineering endeavours. While the language defines the theoretical and conceptual base to define and describe software engineering methods, practices and kernels, the kernel1 aims to provide a set of essential and universal elements which form the common ground of software engineering.

The following sections provide an overview on the Essence specification. In the first part, the guiding principles required to understand the underlying idea of the Essence kernel and the language are outlined. While the next part then explains the specification of the Essence language, the last part outlines the structure and contents of the Essence kernel.

2.1 Guiding Principles

Traditionally, a method is defined up-front before a team starts its work and described as a sequence of activities that have to be done. The Essence specification defines methods and practices as follows:

Practice: A repeatable approach to doing something with a specific purpose in mind. Each practice represents a separate concern of a method.

Method: A composition of practices forming a (at the desired level of abstraction) description of how an endeavour is performed.

Methods, practices, the kernel and the language form a layered architecture which is depicted in Figure 1 from a high level view. A method is defined as the composition of one or more practices which are based on an underlying kernel. Although a method references the underlying kernel, the actual composition happens in the context of the practice as practices actively use the elements included in the kernel. Both the kernel and practices are expressed in the Essence language. Although also methods are defined in terms of the Essence language, the language is actually applied within the scope of practices and kernels – methods can be seen more as a kind of formal container offering a mechanism to compose different practices.

1 Although the specification allows to define custom kernels and kernel extensions, in the following we refer to the Essence kernel in terms of the kernel.



Figure 1 Layered architecture

The underlying idea of the kernel is to separate the things which are prevalent in any software engineering endeavour from the things which are more specific in the context of a certain method. Based on these universals, the kernel forms the basic vocabulary to describe practices and methods.

The Essence language provides the language constructs used to express both the kernel as well as practices. On the one hand, the language therefore defines more abstract language constructs which are used to describe the things related to the universal and reusable nature of the kernel. On the other hand, the language also defines more concrete language constructs which serve to concretize certain aspects within the context of specific software engineering practices.

A practice definition would typically refer to a set of kernel elements in order to scope the practice using these universal elements (i.e. alphas, activity spaces, competencies). The practice definition would then add the details using more concrete specification elements (e.g., work products, activities). Figure 2 depicts the relationship between the definition of a method, the definition of a practice, the Essence kernel, and the Essence language from a more granular view. For reasons of transparency, the figure doesn’t include all language constructs which may be used to express kernels and practices but only the conceptually most essential ones.



Figure 2 Conceptual overview of the Essence language

2.2 Essence Language

The Essence language is a domain-specific language addressing the description and the enactment of practices and methods in software engineering. Therefore, the language provides the syntax and the semantics used to express methods, practices and kernels. It incorporates static features allowing the description of practices and methods as well as dynamic features enabling their enactment. The static base is given by the abstract syntax and the static semantics of the language. The dynamic features are defined by its operational semantics.

The Essence language is a properly defined (modelling) language as it defines its abstract syntax, its semantics, and a set of concrete syntaxes [Harel and Rumpe 2004]. The abstract syntax of the Essence language is defined using metamodelling technique. While the semantics (i.e. the meaning) of the language constructs is described in natural language, the operational semantics are formally defined. The concrete syntax is provided both in the form of a graphical as well as a textual representation.

2.2.1 Metamodelling Technique

The language is specified based on metamodelling technique which states the vocabulary and taxonomy of the language. It uses four levels of constructs (i.e. meta-classes):



Level 3 - Meta-language: the meta-language, i.e. the specification language used to express the language constructs on meta-level 2.

Level 2 - Construct: the language constructs used to express the specification elements available on meta-level 1.

Level 1 – Type: the specification elements used to express specific kernel and practices.

Level 0 – Occurrence: runtime instances representing real-life instances in the context of a running endeavour.

While the meta-level 3 represents the most abstract level defining the language used to specify the Essence language, meta-level 0 represents the most concrete level relating to the concrete real-life instances during runtime. Figure 3 exemplifies the hierarchies of the meta-levels including the editors who are dealing with each meta-level: On meta-level 3, the specification language is defined to express language specific concepts such as Meta-class. Specification languages defined on level 3 of the metamodel can be used to express various domain-specific languages as their concepts are independent from the application domain. Note that the metamodel is not limited to three levels but actually unlimited because also level 3, and in consequence, each level greater than level 3, need to be defined in terms of the next higher level. Though, typically, the metamodelling concept is depicted up to level 3. The actual specification of the Essence language happens at meta-level 2 where the specification language is used to define the Essence language constructs used to express the Essence concepts. For example, the language construct Alpha is defined as an instance of the specification language construct Meta-class. The language constructs defined at level 2 are then used at level 1 to express kernels and practices: While the kernel author uses these language constructs to define kernels, the methodologist uses them to define certain practices. Finally, on level 0, the defined specification elements on level 1 are instantiated into real-life instances; typically, it is the practitioner who enacts the running endeavour using these runtime instances.

Figure 3 Language meta-levels



2.2.2 Abstract Syntax and Semantics

While the Essence kernel is allocated at level 1 of the metamodel, the focus of the Essence language specification is on level 2 of the metamodel. The latter expresses the abstract syntax of the Essence language and some constraints on the structural relationships of the language constructs. For each language construct, invariants including additional operations are defined. The structural relationship between the language constructs and the invariants including additional operations define the static semantics of the language. The metamodel is specified using both a graphical and a textual representation. The graphical representation expresses the metamodel in the MOF formalism using the CMOF model [OMG 2011]. Each language construct is thus represented as an instance of a MOF class or association. The specification uses UML classes and package diagrams to depict the abstract syntax and the static semantics of the language. In parallel to the graphical visualization of the metamodel, each language construct is also specified textually using a unified text-based template. The template defines the abstract syntax and the static semantics of each language construct in a tabular format. It also defines a section including invariants and additional operations which are specified using the Object Constraint Language (OCL). The OCL invariants precise and complement the structural constraints of the language constructs as they express context constraints which are typically beyond the expressiveness of a modelling language. Furthermore, it defines a brief description of the language construct as well as its semantics in natural English language.

The dynamic base of the language is specified both informally and in a formal language. The informal description of the operational semantics is provided natural English language. The underlying denotational semantics are formally specified using VDM-SL in mathematical syntax.

2.3 Essence Kernel

The Essence kernel captures the idea of a common ground based on the things we always have, the things we always do, and the skills we always need in order to conduct software engineering endeavours. The objective of the kernel is to provide a set of universal elements to define, use and adapt methods and practices supporting the day-to-day activities of the software development team in a dynamic way while fostering communication and collaboration. In order to establish a common ground, the kernel addresses the customer, solution and endeavour facet of software engineering. Within these three areas of concern, the kernel defines alphas, activity spaces and competencies.

2.3.1 Areas of concern

The kernel is structured alongside three areas of concern: The customer area of concern, the solution area of concern, and the endeavour area of concern.



The customer area of concern deals with the actual use and exploitation of the software system to be developed. Within this area, the team understands the opportunity to build software, i.e. the value the software system provides to the other stakeholders.

The solution area of concern addresses the specification, design and implementation of the software system. Within this area, the team establishes a shared understanding of the requirements and implements, builds, tests, deploys and supports the software system.

The endeavour area of concern engages in the concerns of the team and the management of its work. Within this area, the team is formed and work is being planned and organized; the team progresses the work in alignment with the agreed way-of-working.

2.3.2 Alphas

Alphas can be regarded as one of the most central concepts of the kernel. Alphas represent the essential things to work with when conducting a software engineering endeavour, i.e. the things a team produces, manages and uses in the process of developing, maintaining and supporting software. As such, they form the base of the common ground for the definition of software engineering methods and practices. The kernel defines a set of seven alphas. Each alpha belongs to a specific area of concern. The customer area of concern specifies the Opportunity and Stakeholders alpha. Within the solution area of concern, the Requirements and the Software System alpha are defined. The endeavour area of concern includes the Team, the Work and the Way of Working alphas. During the execution of an endeavour, the team progresses the alphas from an initial state to a target state. Therefore, each alpha contains a set of pre-defined states. For example, the Opportunity alpha progresses through the states identified, solution needed, value established, viable, addressed and benefit accrued (see Figure 4).



Figure 4 Example of Alpha States (Opportunity alpha) [OMG 2013]

Alpha states allow to assess the progress and health of the alphas during the execution of the endeavour. Furthermore, the states allow to determine where the team currently stands and what to do next in order to progress. The assessment of each state is supported with a defined checklist associated with each state. For example, regarding the alpha Opportunity and its state Value Established, a checklist consisting of five items summarizes the required criteria to achieve that state (see Table 1).

Area of Concern Customer

Alpha Opportunity

State Value established

Checklist The value of addressing the opportunity has been quantified either in absolute terms or in returns or savings per time period (e.g. per annum).

The impact of the solution on the stakeholders is understood.

The value that the software system offers to the stakeholders that fund and use the software system is understood.

The success criteria by which the deployment of the software system is to be judged are clear.

The desired outcomes required of the solution are clear and quantified.

Table 1 Example of checklist (Opportunity alpha)



The kernel alphas interact within and across the three areas of concern. Within the customer area of concern, the Stakeholders provide the Opportunity and demand the Requirements. They use and consume the Software System and support the Team. The Opportunity focusses on the Requirements. Within the endeavour area of concern, the Work is set up to update and change the Software System. While the Team performs and plans the Work it produces the Software System and applies a Way of Working. The way of working guides the Work. Within the solution area of concern, the Requirements serve to scope and constrain the Work. The Software System helps to address the Opportunity and fulfils the Requirements (see Figure 5).

Figure 5 Overview of Essence kernel alphas [OMG 2013]

2.3.3 Activity Spaces

Activity spaces represent placeholders for the essential activities in software engineering endeavours. They complement the alphas and provide an activity based view on software engineering. An activity space serves as placeholders for one or more concrete activities. Each activity space has a set of objectives and is related to certain kernel alphas which are required as input or provided as output. Each activity space is defined including completion criteria which relate to certain alpha states. For example, the activity space Explore Possibilities is defined as the exploration of possibilities presented by the creation of a new or improved software system. Table 2 lists the objectives of this Activity Space, as well as the required and resulting alphas (i.e. input and output), and its completion criteria.

Area of Concern Customer

Activity Space Explore Possibilities

Objectives Involve the right stakeholders Understand the stakeholders’ needs Identify opportunities for the use of the software

system



Understand why the software system is needed Establish the value offered by the software system

Input None

Output Opportunity Stakeholders

Completion criteria Stakeholders are recognized Opportunity is identified The need for the solution of the opportunity must be

clear Value of opportunity is established

Table 2 Example of Activity Space (Explore Possibilities)

Figure 6 depicts an overview of all defined kernel activity spaces across the three areas of concern.

Figure 6 Overview of Essence kernel activity spaces [OMG 2013]

2.3.4 Competencies

The kernel competencies complement the kernel alphas and activity spaces with the key competencies required to conduct software engineering endeavours. The defined kernel competencies consist of communication, engineering and management capabilities. Figure 7 depicts the specified competencies across the three areas of concern.



Figure 7 Overview of Essence kernel competencies [OMG 2013]

Each competency can be assessed by five levels of achievements which build upon each other. Team members with competencies at level 1 (“Assists”) demonstrate a basic understanding of required concepts and can follow instructions. At level 2 (“Applies”), the concepts are applied in simple contexts based on first experiences. Level 3 (“Masters”) defines the competency to apply the concepts in most contexts. Team members possessing this competency are considered to have enough experience to work without supervision. Competencies at level 4 (“Adapts”) allow to judge when and how to apply the concepts in more complex contexts. Competencies at Level 5 (“Innovates”) represent recognized experts who extend concepts, apply them to new contexts, and inspire others.

Use Cases


3 Use Cases

The set of use cases encompasses ten use cases. Each use case is documented separately in textual form in natural English language (see Appendix A). As the use cases are not numbered, we list them in alphabetical order:

Compare methods

Compose method

Define practice definition

Establish well-formed practice

Evaluate method or practice

Extend practice

Plan based on method

Simulate practice or method

Teach kernel language

Understand Software Engineering

An overview of the use case documents shows that the use cases differ largely regarding their form and their documented contents. For example, the use case Define practice definition is extensively defined using a structured template including comments and additional information (see Figure 8) while the use case Extend practice is limited to a brief summary, its source and its value (see Figure 9).

Figure 8 Use case "Define practice definition"

Use Cases


Figure 9 Use case "Extend practice"

In order to analyse the use cases in a structured way and to reason about their quality and completeness consistently, it is thus necessary to analyse their contents and to systematically prepare them.

In the following, we therefore conduct a high level analysis of the use cases consisting of three parts: In the first part, we review the contents of the use cases in order to bring them into a reasonable analysis order. In the second part, we analyse the documented use case attributes in order to establish a consistent analysis process. In the third part, we analyse the actors of the use cases.

3.1 Order of Use Cases

The set of use cases encompasses various application areas in the context of software method definition and operation. In order to process our analysis in a comprehensible and reasonable way, those use cases which form the basis of other use cases need to be analysed first. For example, within the use case Define practice definition, the actor uses the Essence kernel and the Essence language to define a practice. As all other use cases implicitly assume that that the use case is fulfilled, it represents one of the most fundamental use case (if not even the most fundamental one). Hence, the use case Define practice definition should be analysed prior to all other use cases. The objective of this section is thus to bring the use cases into a reasonable order. Therefore, we first refer to the phases of software process management [Gruhn 1991] and classify the use cases according to these phases. As process phases typically build upon each other, the underlying assumption is that use cases which are processed in later phases implicitly require the use cases which are processed in earlier phases. Second, we derive a more detailed ordering of the use cases.

The six phases of software process management refer to the modelling of the software process, the instantiation of the software process models, the analysis of software process models, the execution of software process models, the animation of software process models, and the adaptation of software process models. The relation between these phases and the use cases is shown in Table 3 Relation of use cases to phases of software process management (the use cases within one phase are alphabetically ordered).

Use Cases


Phase Use Case

1) Modelling of the software process

Compose method

Define practice definition

Establish well-formed practice

Extend practice

2) Instantiation of software process models

n/a

3) Analysis of software process models

Compare methods

Evaluate method or practice

4) Execution of software process models

Plan based on method

Simulate practice or method

5) Animation of software process models

n/a

6) Adaptation of software process models

n/a

n/a Teach kernel language

Understand Software Engineering

Table 3 Relation of use cases to phases of software process management

The relation shows on the one hand that the use cases don’t cover all phases. On the other hand, two use cases exist which cannot be classified according to these phases. However, reasoning about the completeness of the use cases is not subject to this thesis. Based on this relation, we derive a more detailed and specific ordering: In order to limit the focus on the higher-level activities which are covered by the use cases, we classify the use cases in terms of application areas which we derive both from the covered phases of software process management as well as the not assignable use cases. Table 4 Classification of use cases shows the final classification and ordering of the use cases. The use cases Teach kernel language and Understand Software Engineering are analysed last as their actors aim to teach and understand the objectives which are mostly covered by the other use cases. Hence, we consider these use cases as dependant from the fulfilment of the other use cases.

Application area Use Case Name ID

Design DefinePracticeDefinition UC-01

EstablishWell-formedPractice UC-02

ExtendPractice UC-03

ComposeMethod UC-04

Assessment EvaluateMethodOrPractice UC-05

Use Cases


CompareMethods UC-06

Execution PlanBasedOnMethod UC-07

SimulatePracticeOrMethod UC-08

Education TeachKernelLanguage UC-09

UnderstandSoftwareEngineering UC-10

Table 4 Classification of use cases

3.2 Documented Use Case Attributes

All use case documents use explicit headings to point out the documented contents. Though, as the set of use case documents encompasses overall 23 different headings, it is difficult to analyse them in a consistent way. Furthermore, some use case documents are hard to read as they contain a special formatting or notation and additional comments. In order to assess the use case, the objective of this section is to conduct a high level analysis of the use cases with respect to the documented use case attributes. As a result, we establish a list of use case contents which will be primary subject to the analysis.

In order to investigate into the documented use case attributes, we analyse the headings of each use case and classify them as follows [Pohl 2010]:

Management information Reference to context Content (e.g., description, goals, use case specific attributes, quality criteria) Supplementary information Validation

The tables below list the documented attributes for each use case and order them according to the amount of use cases which includes this attribute.

Management Information: The documented attributes regarding management information include the identification (i.e. the name) and the author (i.e. owner) of the use case.

# Use CaseAttribute

UC-01

UC-02

UC-03

UC-04

UC-05

UC-06

UC-07

UC-08

UC-09

UC-10

Name X X X X X X X X X X

Owner/Author X X X X

Table 5 Use cases: documented attributes - management information

Reference to context: The documented attributes regarding the reference of the use case to its context include dependencies, opportunity, relationship to other use cases, source, stakeholders, stereotype, synonym, synonym from initial requirements brainstorming, and value. At this, both “source” and “dependency” relate to the output of the five working

Use Cases


tracks the SEMAT group defined during their initial brainstorming phase. We therefore merge these attributes.

# Use CaseAttribute

UC-01

UC-02

UC-03

UC-04

UC-05

UC-06

UC-07

UC-08

UC-09

UC-10

Stereotype X X X X X X X X X X

Source / Dependencies

X X X X X X X X X X

Value X X X X X X X X

Synonym from initial requirements brainstorming

X X X X X

Opportunity X X

Stakeholders X X

Relationship to other use cases

X

Synonym X

Table 6 Use cases: documented attributes - reference to context

Content: The documented attributes referring to the actual content of the use case include a description, the basic and alternative paths, the actor(s), pre- and post-condition, and scenarios. Furthermore, one use case also notes special requirements which go beyond the actual scope of the use case.

# Use CaseAttribute

UC-01

UC-02

UC-03

UC-04

UC-05

UC-06

UC-07

UC-08

UC-09

UC-10

Brief description

X X X X X X X X X X

Basic path X X X X X X

Alternate paths X X X X X X

Actors X X X X X

Pre-Condition X X X

Post-Condition X X

Scenarios X

Special requirements

X

Table 7 Use cases: documented attributes - content

Use Cases


Supplementary information: Some use cases also documented attributes which support the development of the use case, i.e. assumptions and constraints as well as additional and other supporting information.

# Use CaseAttribute

UC-01

UC-02

UC-03

UC-04

UC-05

UC-06

UC-07

UC-08

UC-09

UC-10

Assumptions and constraints

X

Additional information

X

Other supporting information

X

Table 8 Use cases: documented attributes - supplementary information

Validation: Documented attributes with focus on the validation of the use case are defined in terms of test cases.

# Use CaseAttribute

UC-01

UC-02

UC-03

UC-04

UC-05

UC-06

UC-07

UC-08

UC-09

UC-10

Testing / Test Case

X X

Table 9 Use cases: documented attributes - validation

Based on the use case attributes which document the contents of the use cases, we base our analysis primarily on the brief description, the basic path and the alternative paths of the use cases. If required, we include pre- and postconditions and special requirements in terms of qualities. With regard to the use case which documents scenarios we state that the scenarios are based on its basic and alternative path. As these are already subject to our analysis, we don’t explicitly evaluate the scenarios.

3.3 Use Case Actors

In order to analyse the completeness and quality of the use cases from the viewpoint of the actors, each use case must necessarily define an actor. Though, the analysis of the documented use case attributes shows that only 50% of the use cases explicitly document the actor. Within this section, we therefore analyse the use cases with respect to their actors in order to derive a complete list of all use cases including their actors.

A graphical overview was provided in addition to the use case documents depicting the relationship between some use cases and actors (Figure 10).

Use Cases


Figure 10 Use case actors

The use cases Use method and Tailor method don’t match the name of any of the actually provided use cases. As the use case documents represent our primary point of reference, we assume that these two use cases were more or less merged with the provided use cases: With regard to the use case Tailor method, the use cases Extend practice and Compose method outline in their value statement that practices can be tailored to suit different circumstances. Regarding the use case Use Method, the use case Plan Based on Method definitively represents an aspect of using a method during the execution of an endeavour.

When comparing the list of documented use cases and the overview of the use cases, it gets visible that the use cases and their actors are not synchronized. In order synchronize the information about the actors of the use cases, we name for each use case the documented actor and the actor in the use case overview (see Table 10).

ID Use Case Name Documented actor in the use case

Depicted actor in the use case overview

UC-01 Define practice definition

Practice Author Methodologist

UC-02 Establish well-formed practice

- -

UC-03 Extend practice - Practice/Method Developer

Use Cases


Project Manager

UC-04 Compose method Way of working master

Practice/Method Developer

UC-05 Evaluate method or practice

- Practice/Method Developer Project Manager

UC-06 Compare methods Assessor/ Appraiser Methodologist Assessor/Appraiser

UC-07 Simulate practice or method

- -

UC-08 Plan based on method

Way of working master

-

UC-09 Teach kernel language

- -

UC-10 Understand Software Engineering

Student -

Table 10 Comparison of use case actors

Comparing the actors of the use cases with the actors from the overview, we conclude that following actors are semantically equivalent:

Methodologist and Practice author Way of working master and Practice/Method developer

Furthermore, based on the classification of the use cases in the four application areas (i.e. design, assessment, execution, education) as well as the objectives of the use cases, we state that the actors Methodologist and Practice/Method developer focus both on the design of practices and methods (i.e. their definition, extension and composition). We therefore merge these actors into the actor Methodologist.

The use cases Establish well-formed practice, Simulate practice or method and Teach kernel language neither document the actor, nor are the actors listed on the overview. By analysing the contents of the use cases, following conclusions can be made:

Within its brief description, the use case Establish well-formed practice contrasts the automatic validation of the well-formedness of practices by means of tool support with activities conducted by human actors (i.e. practice author and the user of the practice/method). We therefore conclude that the actor of the use case is a tool or the tool author.

The use case Simulate practice or method states following objectives in its brief description: to model the execution of an existing practice, to simulate it using a tool, and to validate that the practice is coherent and fits its purpose. As the use case deals

Use Cases


with the validation of a practice definition, we consider the methodologist as the most suitable actor. With regard to the other use cases, this use case can also be seen as the logical consequence of the methodologist’s prior activities: For example, in the use case Define practice definition, the methodologist defines (well-formed) practices/methods for a specific purpose. In the use case Compare practices or methods, he then compares them to select the most appropriate one with regard to a specific purpose within a specific context. Finally, he simulates the practice or method in an experimental setting to validate its dynamic behaviour.

Regarding the use case Teach Kernel Language, the activities outlined in the brief description focus on teaching the kernel and the language concepts. We therefore consider the actor Teacher as appropriate actor.

Table 11 summarizes the defined and derived actors for all use cases.

ID Use Case Name Actor

UC-01 Define practice definition Methodologist

UC-02 Establish well-formed practice Tool/Tool author

UC-03 Extend practice Methodologist, Project Manager

UC-04 Compose method Methodologist

UC-05 Evaluate method or practice Methodologist, Project Manager

UC-06 Compare methods Methodologist, Assessor/Appraiser

UC-07 Simulate practice or method Methodologist

UC-08 Plan based on method Methodologist

UC-09 Teach kernel language Teacher


Student

Table 11 Defined and derived actors for all use cases

Method


4 Method

Based on the analysis of the use cases in section 3 and the objectives of this thesis, this section presents the analysis approach. First, a unified template is presented which supports the analysis of all use cases in structured, consistent and comprehensive way. Second, the analysis procedure is outlined. Next, the criteria to reason about the quality and the completeness of the specification are defined. Finally, naming conventions with regard to a consistent and unambiguous usage of the terms related to the Essence language and kernel are stated.

4.1 Formal Adaptation of Use Cases

In order to limit the focus of our analysis on the contents of the use case and to analyse each use case step by step in a systematic and consistent way, we migrate the use cases to a unified template (Table 12). The template attributes are based on the documented use case content attributes resulting from the high level analysis of the use cases (see 3.2).

Name

Actors

Brief description

Basic path 1

2

3

4

…

Alternative paths 1

…

Pre-Condition

Post-Condition

Qualities

Table 12 Use case template

The template contains the name of the use case and the use case specific attributes which are considered as relevant to reason about the fulfilment of the use case (i.e. actor, brief description, basic path, alternative paths, pre-condition, post-condition). Some use cases include special requirements, for example, within their brief description or a dedicated section. In order explicitly consider and evaluate these aspects, we extract these requirements in terms of qualities.

Method


In order to reason in how far the specification fulfils each use case, each use case should name at least one requirement and specify it in terms of the basic path. Although most use cases define a basic path, some of them only state a brief description. Reviewing these descriptions, we state that they implicitly include some kinds of requirements. For each of these use cases, we therefore decompose the brief description into a basic path consisting of one step and/or its qualities. This makes these requirements more explicit and allows us to explicitly evaluate them. If the brief description includes a step wise description to achieve the goal of the use case, we compile a basic path consisting of a sequence of steps.

During the migration of the use cases into the unified template both grammatical errors and misspellings as well as incomplete or semantically incorrect sentences were corrected. Furthermore, upper- and lower case spelling was aligned (see section 4.4).

4.2 Analysis Procedure

For each use case, we first summarize the actions and the objective of the actor. Next, we clarify the underlying requirements, i.e. the concepts and principles the specification must provide so that the actor can execute the use case. We then investigate in detail into the basic path, the alternative paths and the qualities of each use case (if defined). For each requirement item (i.e. each step or each quality) we name the concepts the specification provides to fulfil it, describe how the actor applies it, and reason in how far the specification fulfils the requirement item. Finally, we reason in how far the complete use case is fulfilled by the specification.

4.3 Judgement of Quality and Completeness

With regard to the completeness of the specification, we analyse for each use case whether its defined requirements (i.e. basic path, alternative paths, and qualities) are fulfilled. Regarding the basic path and the alternative paths, we analyse in how far each step is fulfilled to conclude about the completeness of the path. Similarly, we analyse quality item and reason whether the specification fulfils it. We argue, if a requirement is not subject to the specification and thus, not relevant in the scope of our analysis. We consider the specification as complete in the scope of a certain use case, if all relevant paths and qualities are fulfilled.

We evaluate the quality from the view of the different use case actors. As each use case focusses on a specific target group, we evaluate the quality of the specification based on the overall fulfilment of all use case from the perspective of their actor(s). We consider the specification of high quality from the view of a certain actor, if all use cases which include this actor are fulfilled. We consider the quality as medium, if the use cases are partly fulfilled. If no use case is fulfilled with regard to a certain author, we judge the quality as low. Parts which are considered as not relevant or out of scope of the specification won’t be included in the judgement.

Method


4.4 Naming Conventions

During the execution of the use cases, the actors deal on the one hand with concepts of the real-world (i.e. existing methods and practices) and on the other hand with the concepts defined in terms of the Essence language and the Essence kernel. The terminology which is specified to name the Essence language constructs as well as the Essence kernel elements equals in many cases the terminology commonly used in software engineering to describe these concepts. At this, the specification intends the same or similar semantics as observed in the real world. For example, the term activity represents an activity being performed in the real world but relates also to an activity definition in terms of the Essence language. The same counts for example for the kernel element Stakeholders which represents both in the real world as well as in the context of the Essence kernel the people, groups, or organization who affect or are affected by a software system. In order to state clear in our analysis whether we refer to a real-world concept or to a concept in terms of the Essence language and kernel, we use following naming conventions:

When referring to a language construct (i.e. language meta-level 2) we write its name in italic including a capital letter (e.g., “Competency”, “ActivitySpace”).

When referring to a specification element (i.e. language meta-level 1) we write its name in italic including a capital letter (e.g., “Requirements”, “Software System”).

When referring to an unnamed instance of a language construct or a set of instances of language constructs of the same type, we use the name of the language construct and write it in small letters (e.g., “alpha”, “activity spaces”). If the context requires to avoid further ambiguities, we apply the postfix definition to indicate that we refer to a concept defined in terms of the Essence language. For example, when dealing concurrently with activities of an existing method and activities in terms of the Essence language, we refer to the latter as “activity definitions”. In the context of the kernel, we alternatively use the prefix kernel, for example “kernel activities”.

We will apply these naming conventions also in the context of the use case template, i.e. we adapt the naming used in the use cases according to our naming conventions.

Analysis and Discussion


5 Analysis and Discussion

5.1 Use Case “Define practice definition”

5.1.1 Definition

Name Define practice definition

Actor Methodologist

Short description

Establish a well-formed practice based on an existing method

Establish practice based on an existing method Ensure the practice is well-formed (include use case “Establish

well-formed practice”)

Basic path 1 Analyse method

a) Identify and name the activities that the method directs to be performed.

b) Identify and name all the work products that the method requires to be produced.

2 Scope the practice

a) Identify and name the alphas that the method progresses that are described by the alpha definitions in the kernel.

b) For each identified alpha, identify and name the states that the method covers.

c) For each identified activity, identify and name the activity spaces that are described by the activity space definitions in the kernel that match the objectives of the activity.

d) Identify skills required to perform each activity.

e) For each activity, relate activities to the alphas that are progressed or checked.

f) For each activity, relate the activity space in the kernel that match the objectives of the activity.

g) For each work product, identify the alpha that it describes.

h) For each work product, identify the activity that creates or updates it.

i) Check that the alphas, work products and activities form the basis of a reasonable practice

3 Outline the practice

a) Create a practice definition for the identified practice:

Name the practice.



Briefly describe the practice.

b) Bring in alpha definitions:

Associate the practice definition with the alpha definitions that scope the practice.

Identify the alphas that are used as sources of information that the practice requires (inputs).

c) Create an activity definition for each activity identified:

Name the activity definition.

Briefly describe the purpose of the activity in the activity definition.

d) Create a work product definition for each type of work product identified:

Name the work product definition.

Briefly describe the work product definition.

e) Associate activity definitions to alpha definitions and states:

Identify the alpha states that performing the activity will achieve.

Associate the activity definitions with the corresponding alpha definitions and its state definitions.

Sequence the activity definitions to describe the basic flow of the practice.

Adjust the sequence of the activity definitions to align with the order of the state definitions.

f) Associate work product definitions to alpha definitions: Connect each work product definition to an alpha definition that specifies its subject (the thing that the work product will be produced to describe or represent the alpha).

g) Associate work product definitions to activity definitions: For each activity definition, update the activity definition stating the relationship to the work product definitions that describe the creation or update of the work product.

h) Bring in activity space definitions: For each activity definition, associate the activity definition with the activity space definition that match the objectives of the activity.

i) Bring in skills/roles/competencies: For each identified activity definition candidate, identify the competency definition candidates that are required to enact the activity definition candidate and the skill level definition of each competency definition required to enact the activity definition successfully.

j) Validate the practice definition.



4 Complete the practice definition

a) Enhance work product definition: For each work product definition, identify the levels of detail definition that the work product requires.

b) Enhance activity definition:

For each activity definition candidate, update the activity definition with the levels of detail achieved for each work product created or enhanced by the activity.

For each activity definition candidate, identify the approaches that can be enacted to perform the activity.

c) Re-factor activities, work products and competencies to include just the essentials.

d) Include use case “Establish well-formed practice”.

Alternative path 1 Subject not covered by the kernel: Prior to step 2 of the basic path, if the subject matter is not covered by the identified kernel elements then

give the subject matter a name,

decide what states would be useful as stepping stones to be able to progress the subject matter to a successful conclusion,

define each state in terms of unambiguous goals – so accurate judgments can be made whether the state has been achieved.

The use case continues at step 1a) of the basic path.

2 Require more specific subject: Prior to step 2 of the basic path, if the subject is covered by the kernel, but there could be many instances of that subject and requires finer grained control, create a sub-Alpha.

3 Require extra competencies: If new competencies have been identified that are not in the kernel then

decide on the levels of competence the competency encompasses, from beginner to expert, and how to decide when a level of competence has been reached,

provide further guidance on what the essential qualities of the competency are (e.g., staffing ideas for a particular endeavour, skills).

4 Require new activity space.



5 Extend scope of the kernel alphas: At the end of the alternative path 1, consider if the subject should be included in the kernel (i.e. applicable to all kernel related endeavours).

6 Method gives rise to more than one practice.

7 Activity not found a home.

8 Work product not found a home.

Pre-Condition The method is known.

Post-Condition A well-formed practice definition that integrates with and can be combined with other practice definitions to form a method for a particular situation.

Qualities 1. Easy to use and understand: Designed for the developer community (not just process engineers and academics) - use uncomplicated terminology.

2. Built in terms of universals.

3. Covers all relevant practices, patterns & their composition, in today's methods.

4. Have an abstract syntax.

5. At least one concrete syntax (textual / graphical).

6. Have state to represent work progress.

7. Practice must be measurable.

8. A practice is a separate concern of a method. Examples are “development from requirements to test”, “iterative development”, “component-based development”.

9. Every practice shall be described on its own, separately from any other practice.

10. Every practice, unless explicitly defined as a continuous activity, has a clear beginning and an end.

11. Every practice brings defined value to its stakeholders.

12. Every practice must be assessable; its description must include criteria for its assessment. Whenever applicable, the assessment criteria must include quantitative elements; correspondingly, the description must include suitable metrics.

13. Must not generate more paper than the original method.

Table 13 Use case “Define practice definition”

The format of the documented use case was adapted as follows: The original use case document uses a specific structure and notation to document the basic path. It also defines some kind of proprietary tags which are denoted in brackets (e.g., {Bring in Alpha Definitions}) repeating the information which follows the tag. We assume these tags were



generated out of a tool and serve as headings to separate sections of sub steps from each other. In order to reduce the complexity of the use case, we consolidated these tags and consolidated multiple levels of redundant information. As several sub steps include some kind of “for each”-loop (e.g., for each activity, do following things), we decomposed these structures into a set of separate sub steps in order to analyse each aspect on its own.

Content wise, the original use case document lacks of clearness regarding the aspect of bringing in skills, roles, and competencies and of the relation between the alternative paths and the basic path: The identification and definition of required skills, roles and competencies is present both in the basic path and the alternative path A9 of the original use case document. We consider both occurrences as semantically equivalent. In order to assign this requirement to either the basic path or alternative path we analysed the statements in these paths: The basic path denotes the requirement in a notation which is uncommon for the documentation format (i.e. <<identify skills required to perform each activity>>;<<bring in skills/roles/competencies>>). The alternative path uses a notation and formulation similar to other requirements of the basic path although the {begin} and {end} tags are missing. We assume that the contents of the alternative path A9 actually belong to the basic path for three reasons: First, as the notation and formulation of the statement in the alternative path matches the style of the basic path. Second, a comment enclosing the alternative path indicates that more work to be done here. Thus, it might be the case that this aspect has not been fully elaborated in the use case and is therefore mentioned twice. Third, we refer to the fact that one of the goals of this use case is to identify and apply the elements from the kernel in order to author a practice. At this, the kernel contains three types of elements: alphas, activity spaces and competencies. Alphas and activity spaces are already covered in the basic path. Hence, we decide to handle this requirement within the basic path rather than the alternative path and combine the ninth alternative path with <<bring in skills/roles/competencies >>.

For some alternative paths, the use case denotes specific tags to document the location where the alternative path holds in the basic path, and where it continues. As more than half of the tags are not present in the basic path of the use case document, it is not possible for us to reproduce the location. However, we consider the context information provided in each alternative path as sufficient to relate it to the according locations in the use case, although not exactly. As we analyse each alternative separately, we don’t consider this issue as critical. In the template, we include the information of the tags only in those cases where the tag is present in the basic path.

5.1.2 Requirements

The goal of the use case Define Practice Definition is to define a practice based on an existing method. The use case therefore defines a basic path describing the process the methodologist follows to author a practice. Basically, the methodologist conducts following activities:



He analyses the activities and work products of an existing method.

He identifies the alphas, activity spaces, and competencies defined in the Essence kernel which scope the existing method.

He creates a practice definition and defines the identified activities and work products.

He associates the identified kernel elements with the defined practice and establishes the relations between these kernel elements and the defined work products and activities.

He refines the practice definition.

Beside the basic path, the use case defines nine alternative paths. The first four alternative paths hold if the methodologist needs certain elements (i.e. alphas, subordinate alphas, competencies, and activity spaces) which are not included in the kernel. The fifth alternative path focusses on extending the kernel. In the sixth alternative path, the methodologist requires a solution if the method gives rise to more than one practice. The seventh and eighth alternative paths consider the case that the methodologist is not able to place an activity or a work product in the practice. The qualities encompass a set of various requirements ranging from usability and applicability aspects as well as practical considerations up to conceptual demands.

During the execution of the use case, the methodologist maps the concepts of the existing method on the defined Essence concepts (i.e. the language constructs and kernel elements). A method can exist in many forms, for example in the form of documented processes, implicit knowledge or some established way of working. The activities of the methodologist can be differentiated into the analysis of the existing method, the identification of the appropriate kernel elements, the definition of practice specific elements, and the creation of associations within the set of the identified kernel elements and the defined practice elements. Figure 11 exemplifies the intended mapping process from a conceptual point of view. On the one hand, the actor identifies the universal elements from the kernel which scope the practice. On the other hand, he details the practice with the specification elements which allow him to concretize the practice.



Figure 11 Conceptual overview of practice definition

Although the language encompasses a much wider set of specification elements based on the defined language constructs, for the reason of simplicity, the figure only shows the elements which essentially scope a practice. The more abstract and universal elements (i.e. alphas including states, activity spaces and competencies) are typically subject to the kernel. A practice definition is typically based on the definition of work products, activities and sub-alphas as these elements serve to concretize the alphas and activity spaces defined in the kernel. Resource and pattern definitions can be attached to any element in the context of the practice to indicate certain relationships (e.g., roles, milestones). While the definition of a kernel is restricted to the more abstract and universal elements, the methodologist may define all kinds of specification elements in the context of a practice. This means that he might also define new alphas, activity spaces and competencies within his practice.

Within the basic path of the use case, it is assumed that the existing method gives rise to exactly one practice, i.e. from a practical point of view, the practice actually represents the method (or vice versa). Within the analysis of the use case we will therefore refer to the definition of a practice rather than the definition of a method. The alternative, i.e. the case when the method gives rise to more than one practice, is handled in the context of the alternative paths.

In order to fulfil the use case, the specification must provide all necessary kernel elements and language constructs which define and scope the method as described in the basic path. Furthermore, it must provide the mechanisms and characteristics which are required to cover the alternative paths and the required qualities.



Step 1: Analyse method

Within these two sub steps, the methodologist analyses the existing method with regard to the activities which are performed, and the products which are developed. Neither the analysis of activities and work products of existing methods nor guiding the methodologist through this analysis process is subject to the specification. Hence, we don’t consider this step as relevant.

Step 2: Scope the practice

a) Identify and name the alphas that the method progresses that are described by the alpha definitions in the kernel.

The Essence kernel includes a set of seven alphas (i.e. Opportunity, Stakeholders, Requirements, Software System, Work, Team, and Way of working). The specification provides an overview of all kernel alphas including their relationship within the three areas of concern (i.e. customer, solution and endeavour area of concern). Each kernel alpha is defined including its purpose, the way it is progressed, and a justification. The methodologist thus browses through the defined kernel alphas and analyses which kernel alphas the method progresses. As a result, he names the identified alphas. Under the assumption that the kernel contains all alphas which are progressed by the method, we state that the methodologist is able to master the step. The alternatives are covered in the first and second alternative paths. As a result, we consider this sub step as fulfilled by the specification.

b) For each identified alpha, identify and name the states that the method covers.

For each kernel alpha, the specification defines a set of states. It provides a brief description for each state as well an extensive description of how the set of alpha states is progressed. The methodologist thus looks up the states of each identified kernel alpha and analyses which of its states are progressed by the method. As a result, he names the identified states. We state that the specification fulfils this sub step.

c) For each identified activity, identify and name the activity spaces that are described by the activity space definitions in the kernel that match the objectives of the activity.

The kernel contains a set of 15 activity spaces. The specification provides an overview of these activity spaces within the three areas of concern (i.e. customer, solution and endeavour areas of concern) as well as an extended description of each activity space. The latter includes a list of objectives for each activity space. The methodologist thus browses through the activity space definitions of the kernel. Based on the objectives of each activity space he identifies which activity spaces match the objectives of the identified activities. He names each identified activity space. Under the assumption that all identified activities are reflected in the activity spaces of the kernel, we state that the methodologist is able



to master the step. The alternative is covered in the fourth alternative path. As a result, we consider this sub step as fulfilled by the specification.

d) Identify skills required to perform each activity.

The specification covers skills in terms of competencies. The kernel contains a set of six competencies. The specification provides an overview of all kernel competencies within the three areas of concern (i.e. the customer, solution and endeavour area of concern), as well as an extended description of competency. For each competency, the specification provides a list of competency levels including a brief description of each level. The methodologist thus browses through the competency definitions of the kernel. He identifies which competencies are required to perform the identified activities (see step 1). Under the assumption that the kernel contains all required competencies, we state that the methodologist is able to master the step. The alternative is covered in the third alternative path. As a result, we consider this sub step as fulfilled by the specification.

e) Relate each identified activity to the alphas that are progressed or checked.

While the definition of each kernel alpha describes the alpha from a high level and goal-oriented perspective, the definition and description of its states, its progress and especially of its checklist items offer the methodologist a more concrete option to associate certain activities. For each identified activity, the methodologist thus looks up the states of the identified kernel alphas including their checklist items and analyses whether the activity contributes to the progress of a certain state or the achievement of a checklist item. For example, assume that the methodologist has identified the activity conduct project kick-off meeting with stakeholders in his existing method. Furthermore, we assume that the methodologist has then identified the kernel alpha Stakeholders in the step 2a. He now evaluates the states of the Stakeholder alpha with regard to the identified activity. As a result, he determines that the activity contributes to the achievement of the state Represented. As a results, the methodologist relates the activity to the alpha Stakeholders. Under the assumption that all identified activities are reflected in the identified kernel alphas, we state that the methodologist is thus able to master the step. The alternative is covered in the seventh alternative path. Hence, we consider this sub step as fulfilled by the specification.

f) For each activity, relate the activity space in the kernel that matches the objectives of the activity.

The methodologist has already successfully conducted this activity (see step 2c).

g) For each work product, identify the alpha that it describes.

Similarly to step 2d, the methodologist looks up each identified kernel alpha including its description, its states and its checklist items. For each identified work product, he analyses



whether it represents an identified kernel alpha. For example, the methodologist has identified the work product user manual. Within the first sub step of step 2 of the use case, the methodologist has already identified the kernel alpha Software System. He browses through the kernel alphas and their states and recognizes the state Ready. He double checks the checklist of that state and finds the checklist item Installation and other user documentation are available. Therefore, he concludes that the work product user manual describes the alpha Software System. Under the assumption that all identified work products are reflected in the identified kernel alphas, we state that the methodologist is able to master the step. The alternative is covered in the eighth alternative path. As a result, we consider this sub step as fulfilled by the specification.

h) For each work product, identify the activity that creates or updates it.

In order to execute this step, the methodologist analyses the relationship between the identified work products and the identified activities (see step 1). As the focus of this sub step is limited to the concepts of the real world (i.e. the existing method), it is not subject to the specification. For the same reasons as in step 1, we thus don’t consider this sub step as relevant.

i) Check that the alphas, work products and activities form the basis of a reasonable practice.

Within this step, the methodologist reasons whether the results of his preceding activities form the basis of a reasonable practice. He therefore checks the identified work products and activities from the existing methods, the identified alphas, activity spaces and competencies from the kernel, and the relations he established. In case he encounters discrepancies in the identified concepts and the established relations, he might reconsider his results and repeat the preceding activities. As this step evaluates the preceding activities, we consider the success of this step as dependent from the prior sub steps. Regarding the question whether the specification fulfils this sub step, we thus refer to the analysis results of the prior steps.

Figure 12 summarizes the results of step 1 of this use case from a conceptual point of view. On the left-hand side, the methodologist is shown including the concepts he identified in the context of the existing method. On the right-hand side, the Essence kernel is sketched including its types of specification elements. As a result of the execution of the sub steps 2a - 2h, the arrows depict the identification of the kernel elements which match the concepts of the existing method. Each arrow is denoted with the number of the according sub step.



Figure 12 Use Case “Define practice definition” - Step 2

Step 3: Outline the practice

a) Create a practice definition for the identified practice.

The specification captures the concept of a practice in the language construct Practice. A practice definition contains all elements necessary to express the desired work guidance. A practice definition must include the name, a brief description, a more detailed description, and the purpose of the practice. Hence, the methodologist creates a practice definition (i.e. an instance of the language construct Practice), names it and provides a brief and a more detailed description. Furthermore, the methodologist states the purpose of the practice. As a result, we state that the specification fulfils this sub step.

b) Bring in alpha definitions.

Within this sub step, the methodologist associates the previously identified alphas from the kernel with the created practice. Therefore, the methodologist references the kernel alphas in the context of the practice definition. As a result, the kernel alphas are available as referred elements within the practice. The specification defines this relationship in the language metamodel: Both a kernel and a practice are element groups which can refer to or own other language elements.

Furthermore, the methodologist defines the alphas which are used as sources of information. Therefore, the specification provides the practice attribute entry which allows



naming the expected characteristics of elements required to start a practice. The methodologist thus identifies the required inputs and names them in the entry attribute of the defined practice. As a result, we state that the specification fulfils this sub step.

c) Create an activity definition for each activity identified.

Regarding the definition of activities, the specification provides the language construct Activity. An activity definition must include the name, a brief description, and a more detailed description of the activity. Furthermore, at least one approach how to accomplish the activity must be named. For each identified activity, the methodologist thus creates an activity definition (i.e. an instance of the language construct Activity). He names the activity, provides a brief and a more detailed description, and defines its approach. As a result, we state that the specification fulfils this sub step.

d) Create a work product definition for each type of work product identified.

With respect to the definition of work products, the language defines the language construct WorkProduct. A work product definition must include the name, a brief description, and a more detailed description of the work product. The methodologist thus creates a work product definition (i.e. an instance of the language construct WorkProduct) for each identified work product. For each work product, he provides a name, a brief description, and a more detailed description. As a result, we state that the specification fulfils this sub step.

e) Associate activity definitions to alpha definitions and states.

The specification defines the relationship between activities and alphas based on the language construct CompletionCriterion. A completion criterion represents a condition used to determine whether an activity (or activity space) is completed. For each defined activity or activity space, at least one completion criterion must be defined. A completion criterion can either refer to an alpha state or a levels of detail of a work product. The definition of a completion criterion must include a description. In order to conduct this step, the methodologist refers to the previously conducted steps: In sub step 2e, he related the identified activities to the identified kernel alphas. In sub step 3c, he created the activity definitions. Now, in order to define the associations between the activities and the alpha and their states, the methodologist looks up for each activity its previously related alphas. For each alpha state that performing this activity will achieve, he defines a completion criterion in the context of the activity definition. At this, he also provides a description for the completion criterion. As a result, we state that the specification fulfils this aspect.



In order to describe the basic flow of the practice based on its activities, the specification provides activity associations. An activity association is an instance of the language construct ActivityAssociation. With respect to the definition of sequences between activities (or activity spaces), the specification defines four kinds of associations: start-before-start, start-before-end, end-before-start, end-before-end. Although also a fifth kind of association (i.e. part-of) is defined, it is not considered as relevant in this context (see step 2 h). The specification provides a description of each kind of association in the semantics of ActivityAssociation. In order to establish the basic flow with regard to the activities defined in the context of the practice, the methodologist associates the activities by creating activity associations (i.e. instances of the language construct ActivityAssociation) and names each kind of association. In order to adjust the sequence of activities, he checks if the order of the states in the completion criteria of the activities aligns with the overall order of the states in each alpha. We state that the specification fulfills this aspect. As a result, we state that the specification fulfils this use case sub step.

f) Associate work product definitions to alpha definitions.

While alphas represent relatively abstract concepts, work products can describe an alpha on a more concrete level from different perspectives. For example, different types of requirements specifications (e.g., non-functional requirements; functional requirements) can be considered as work products representing the alpha Requirements. The specification defines the relationship between work products and alphas based on the language construct WorkProductManifest. Work product manifests represent a tri-nary relationship from a practice to a work product used to describe an alpha. At this, several work products may be bound to an alpha. In order to conduct this step, the methodologist refers to the previously conducted steps: In sub step 2g, he already determined the alphas which describe the identified work products, i.e. he established the relations between the identified kernel alphas and the identified work products. In sub step 3d, he provided the work product definitions. Now, in order to associate the work products with the alphas, the methodologist creates a work product manifest for each identified relation. As a result, we state that the specification fulfils this step.

g) Associate work product definitions to activity definitions.

Within this sub step, the methodologist associates the work product and activity definitions to state whether an activity creates or updates a work product. This relationship can be established via actions which are based on the language construct Action. Actions represent operations related to work products (and alphas) involved in a certain activity. Actions can be used to define more granular and more specific tasks than activities. When defining an action, the kind of operation performed on the work product (or alpha) must be named. With regard to work products, the specification differentiates between four kinds of operations: create, read, update, and delete. For each activity, an unlimited number of



actions can be defined. In order to define an operation which touches a work product, the methodologist determines whether the activity creates, reads, updates or deletes the work product. He then creates an action (i.e. an instance of the language construct Action) in the context of the activity, names the affected work product and defines the kind of operation which is executed on the work product. As a result, we state that the specification fulfils this step.

h) Bring in activity space definitions.

Within this sub step, the methodologist associates the identified activity spaces from the kernel (see sub step 2c) with the defined activities (see sub step 3c). While activity spaces represent placeholders or abstractions of something to be done, activities name concrete tasks which need to be conducted. Activities and activity spaces are related to each other as one or more activities typically populate one activity space. Activity spaces and activities thus express a kind of work breakdown structure. In order to represent the relation between activities and/or activity spaces, the specification defines the language construct ActivityAssociation. An activity association may be described based on five different kinds of associations. When defining an activity association between activity spaces and activities, the kind of association must be defined as part-of which reflects the work breakdown structure. For each relation between an activity spaces and an activity, the methodologist thus creates an activity association (i.e. an instance of the language construct ActivityAssociation) and defines its kind as part-of. As a result, we state that the specification fulfils this sub step.

i) Bring in skills/roles/competencies

Within the first part of this sub step, the methodologist associates the defined activities (see sub step 3c) with the identified competencies from the kernel (see sub step 2d). As already mentioned in the analysis of the sub step 2d, the specification covers skills in terms of competencies. Hence, this part of the sub step counts for both skills and competencies. For each activity definition, the methodologist identifies and names the competency level of the identified kernel competency required to perform the activity. He defines the competency level in the context of the activity definition. Each competency level is per se associated with its competency, i.e. the methodologist doesn’t need to provide any further associations to explicitly state the relationship between the activity definition and the competency. The definition of required competency levels is optional. As a result, we state that the specification fulfils this part of the sub step.

Regarding the definition of roles, the specification defines the language construct Pattern which represents a generic mechanism to name concepts (e.g., roles, milestones) referring to several practice and/or kernel elements. In order to associate the related concepts with each other, the specification defines the language construct PatternAssociation. A pattern association is a named association which introduces elements to take part in a pattern. The name of the pattern association refers to the purpose of the associated element within



the pattern. For example, the specification proposes to name the pattern association “used for” when referring to an activity, or, “used on” when referring to a work product. In order to define a role, the methodologist thus creates a pattern (i.e. an instance of the language construct Pattern), provides it with a name, a brief description and a more detailed description, and associates the relevant elements with this pattern. In order to classify this pattern he enhances its definition with a type (e.g., <Role>) based on the language construct Type. For example, the methodologist could create a pattern of type <Role> named Testing Team. The role could then be described with the objective and responsibilities of the Testing Team. Furthermore, the pattern could be associated with the activity space Test the System and the competency Testing. As a result, we state that the specification fulfils this part of the sub step. With regard to the overall sub step, we consider it as fulfilled.

j) Validate the practice definition

Similar to the sub step 2i, the methodologist validates whether the results of his preceding activities form the basis of a reasonable practice. He validates the practice by inspecting the practice, i.e. the definitions of its elements, the related kernel alphas, and all defined relations. In case he encounters discrepancies in the defined and related elements and the established relations, he might reconsider his results and repeat the preceding activities. As this step actually evaluates the preceding activities, we consider the success of this step as dependent from the prior sub steps. Regarding the question whether the specification fulfils this sub step, we thus refer to the analysis results of the prior steps.

Figure 13 summarizes the resulting practice definition from the sub steps 3a - 3i from a conceptual point of view. Each sub step is noted with its number.




Step 4: Complete the Practice Definition

a) Enhance work product definition

Within this sub step, the methodologist identifies the levels of details required to enhance the work product definitions. Although not explicitly stated by the use case, the methodologist also creates the level of detail definitions as he refers to these definitions in the next sub step. In order to define work products levels of details, the specification provides the language construct LevelOfDetail. A level of detail specifies the amount of detail or the range of contents in a work product. For example, a work product defining a piece of software can be produced in the form of a sketch, a diagram, pseudo-code, or executable source-code. Each work product can be enhanced with an unlimited number of levels of detail. The definition of a level of detail must include a name and description. Furthermore, the methodologist must indicate whether the level of detail represents a work product as sufficiently detailed. As opposed to alpha states, the levels of detail of a work product don’t necessarily relate to the completeness of a work product, i.e. a work product may be in the most advanced level of detail but still not completed. For each work product, the methodologist identifies its levels of detail and creates levels of detail definitions (i.e. instances of the language construct LevelOfDetail) in the context of the work product. As a result, we state that the specification fulfils this step.

b) Enhance activity definition

Within this sub step, the methodologist first updates the activity definitions with completion criteria related to levels of details of work products to state whether the successful execution of an activity achieves a certain level of detail of a work product. Establishing this relation follows principally the same way as associating alphas and activities, i.e. via completion criteria (see step 3e). In order to conduct this step, the methodologist refers to the previously conducted steps: In sub step 2h, he already related the identified work products to the identified activities. In the sub steps 3c, 3d, and 4a, he created the according activity and work product definitions as well as the definitions of the levels of detail of the work products. Now, the methodologist looks up for each work product definition(s) its related activity definition(s). He then identifies the level of detail of the work product that performing this activity will achieve. For each identified work product level of detail he defines a completion criterion in the context of the activity. At this, he also provides a description for the completion criterion. As a result, we state that the specification fulfils this part of the sub step.

Regarding the definition of approaches that can be enacted to perform the activity, the specification defines the activity definition attribute approach. Given the fact that the approach must be mandatorily defined when defining an activity, we already pointed out this attribute in the sub step 3c. As the format of the attribute is of type String, the approach may be defined, for example, in terms of a short description of the approach. In order to define the approach, the practice thus identifies the approach and defines it by



populating the activity attribute approach. As a result, we state that the specification fulfils this sub step.

c) Re-factor activities, work products and competencies

Similar to the sub step 2i and 3j, the methodologist checks the results of his preceding activities. In case he encounters discrepancies in the defined practice, he reconsiders his results and repeats the preceding activities. As this step actually evaluates the preceding activities, we consider the success of this step as dependent from the prior sub steps. Regarding the question whether the specification fulfils this sub step, we thus refer to the analysis results of the prior steps.

Figure 8 provides an update on Figure 13 with respect to introduced specification element level of detail and depicts the resulting practice definition from a conceptual view.


d) Include use case “Establish well-formed practice”

As a result of the analysis of this use case we state that the specification does not completely fulfil this step.

5.1.3 Alternative paths

A1: Subject not covered by the kernel

In order to investigate into this path, we first clarify how to interpret the term subject matter: Within the sub steps of this path, the methodologist decides what states would be



useful as stepping stones to be able to progress the subject matter to a successful conclusion. As alphas represent the essential elements which are progressed based on their states, we conclude that this step targets the definition of a new alpha including its states. This conclusion is strengthened by the fact that the alternative path holds prior to the identification of the kernel alphas.

All element types which are typically defined in a kernel (i.e. alphas, activity spaces and competencies) may also be defined in the context of a practice. In case an alpha is not defined in the kernel, the methodologist may thus define a new alpha within the practice. Therefore, he creates a new alpha (i.e. an instance of the language construct Alpha) in the context of the practice and gives it a name. He also defines its brief description and description as these attributes are mandatory. For each stepping stones the methodologist identified, he creates a state (i.e. an instance of the language construct State) including name and description. For each state, he defines a set of checkpoints (i.e. instances of the language construct Checkpoint) including name and description which serve as the criteria to determine whether the state has been achieved. As the specification allows to create and associate all these elements in the context of a practice, we consider this path as fulfilled by the specification.

A2: Require more specific subject

As already outlined in the analysis of the first alternative path, the subject matter refers to a certain alpha progressed by the method. In order to derive a more specific subject, the specification provides the concept of sub-alphas. Sub-alphas represent more granular and specific alphas and drive the states of higher, more abstract alphas. Sub-alphas are based on the definition of sub-alpha relationships. The methodologist creates a sub-alpha by creating a new alpha (i.e. an instance of the language construct Alpha) and defining it as the sub-alpha of an existing alpha. Therefore, he associates the two alphas and establishes a relationship (i.e. an instance of the language construct AlphaContainment) which defines the sub- and the superordinate alpha. Similar to the first alternative path, the practice author then defines the states of the sub-alpha respectively their checkpoints. We thus consider this path as fulfilled by the specification.

A3: Require extra competencies

As already mentioned in the first alternative path, all element types which are typically defined in a kernel (i.e. alphas, activity spaces and competencies) may also be defined in the context of a practice. In case a competency is not defined in the kernel, the methodologist thus creates a new competency (i.e. an instance of the language construct Competency) in the context of the practice and gives it a name. He also defines its brief description and a description as these attributes are mandatory. For each competency, he defines a set of competency levels (i.e. instances of the language construct CompetencyLevel). He names each competency level (e.g., beginner, expert), defines the level in terms of an Integer value and a brief description. Although the specification doesn’t



define specific attributes for the essential qualities of a competency, skills or staffing ideas as stated in the alternative path, the practice author can use the description attribute to define these characteristics. We thus consider this path as fulfilled by the specification.

A4: Require new activity space

As already mentioned in the first alternative path, all element types which are typically defined in a kernel (i.e. alphas, activity spaces and competencies) may also be defined in the context of a practice. In case an activity spaces is not defined in the kernel, the methodologist thus creates a new activity spaces (i.e. an instance of the language construct ActivitySpace) in the context of the practice and gives it a name. He also defines its brief description and a description as these attributes are mandatory. We thus consider this path as fulfilled by the specification.

A5: Extend scope of the kernel alphas

The specification provides the possibility to extend the kernel. We describe this mechanism in detail within the Use Case “Extend Method/Practice”. As a result of the analysis of this use case, we state that the specification fulfils this path.

A6: Method gives rise to more than one practice

One of the essential concepts of the specification is the separation of concerns, i.e. the composition of methods based on one or more modular practices. Hence, if the method gives rise to more than one practice, the methodologist creates and defines further practices. With regard to the composition of practices, we refer to the analysis of the use case “Compose methods”. As a result of the analysis of this use case, we state that the specification fulfils this path.

A7: Activity not found a home

We interpret the term activity not found a home as the fact that an activity could not be located to an activity space. As the alternative path doesn’t provide any details how to handle this situation, we investigate into possible reasons and name possible solutions.

One reason could be that the activity is actually somehow related to an alpha or work product, but the methodologist is not able to locate it to an activity space. Therefore, we propose to enhance the scope of the activity spaces of the kernel and to create a new activity space in the context of the practice. We describe this mechanism in detail within the Use Case “Extend Method/Practice”. As a result of the analysis of this use case, we state that the specification would fulfil this solution. A second reason could be that the activity is not related to software engineering and thus, out of scope of the Essence kernel. One solution could be to consider whether a second practice should be defined based on another kernel or kernel extension (e.g., the business or development kernel extension



provided in the appendix of the specification). Both practices could then be composed into a method as described in the analysis of the use case “Compose methods”. As a result of the analysis of this use case, we state that the specification would fulfil this solution. A second solution would be to check whether this activity provides any value or whether it is critical for the execution of the practice. If it is neither critical nor valuable, a – quite rigorous – solution would be, just to drop the activity in the context of the practice definition. Under the consideration of the named solutions, we consider this path as fulfilled by the specification.

A8: Work product not found a home

We interpret the term work product not found a home as the fact that a work product could not be bounded to an alpha. As the alternative path doesn’t provide any details how to handle this situation, we investigate into possible reasons and name possible solutions.

A reason could be that the work product is actually somehow related to the practice, but the methodologist is not able to bind it to an appropriate alpha. Therefore, we propose to enhance the scope of the alphas of the kernel as described in the fourth or fifth alternative path and to bind the work product to the new (sub-)alpha. As a result of the analysis of this path, we state that the specification would fulfil this solution. A second reason could be that the work product is not related to software engineering and thus, out of scope of the Essence kernel. One solution could be to consider whether a second practice should be defined based on another kernel or kernel extension (e.g., the business or development kernel extension provided in the appendix of the specification). Both practices could then be composed into a method as described in the analysis of the use case “Compose methods”. As a result of the analysis of this use case, we state that the specification would fulfil this solution. A second solution would be to check whether this work product provides any value or whether it is critical for the execution of the practice. If it is neither critical nor valuable, a – quite rigorous – solution would be, just to drop the work product in the context of the practice definition. Under the consideration of the named solutions, we consider this path as fulfilled by the specification.

5.1.4 Qualities

Easy to use and understand

We consider the question whether the specification is easy to use and understand as quite difficult to answer theoretically. Typically, one would gather data answering this question based on real-life experience, for example based on a survey or a case study. Although experience is steadily growing in applying the kernel and the language (e.g., [Péraire and Sedano 2014], [Ng and Huang 2013], [Jacobson et Al. 2014]), a dedicated quantitative assessment of the ease of use and understandability is not known. Though, the work of [Péraire and Sedano 2014] explicitly outlines qualitative feedback from students who applied the kernel with overall positive results. Furthermore, as stated by the use case, an



uncomplicated terminology can support the ease of use and the understandability. Although this aspect is also quite subjective due to the skill level, the knowledge and experience of the practitioner, we overall state that the naming of all the kernel elements and the language elements is based on a terminology common in software engineering. For example, real-world activities are represented based on the language construct Activity and completion criteria are represented based on the language construct CompletionCriterion. The specification also names the attributes of elements based on a common terminology. For example, the brief description of an element is captured in the attribute briefDescription. Within this thesis, it was even required to establish naming conventions in order to clearly distinguish whether we refer to real-life concepts or the concepts in terms of the Essence language. Based on the requirement to use an uncomplicated terminology we thus consider this quality as conceptually fulfilled.

Built in terms of universals

The specification defines the kernel in terms of a common ground of the things we always have and things we always do when developing software and hence, representing the essence of software engineering [Jacobson et al. 2012b]. From a conceptual point of view, we consider this requirement as fulfilled as the design of the kernel elements intends to be reusable and abstract enough to be applied independent from a certain project setting or context. However, reasoning whether the elements included in the kernel really represent the universals of software engineering is beyond the scope of this thesis. The authors of the Essence language and kernel state that defining such a set of widely-agreed on elements is a pragmatic exercise requiring people with long experience in software engineering and the knowledge of many existing methods [Jacobson et al. 2012b]. From a practical point of view, we consider that real-life case studies are required to prove that the kernel elements represent practically relevant universals. Hence, while we judge the quality as fulfilled from a high-level conceptual viewpoint, we consider reasoning about its validity as out of scope within this thesis.

Covers all relevant practices, patterns & their composition, in today's methods

We interpret this quality in terms of the question whether the specification is able to represent all these practices, patterns and their composition. Due to the huge amount and variety of existing methods, we don’t consider it as possible to reason about this requirement in the context of this thesis. In fact, probably more than 100,000 methods exist [Jacobson et al. 2014]. In order to show whether this requirement is fulfilled, one would need to model all relevant practices, patterns and their composition. We thus don’t consider this requirement as relevant with respect to our analysis.

Have an abstract syntax

The language is defined including an abstract syntax (see 2.2.22.2). We thus consider this requirement as fulfilled.



At least 1 concrete syntax (textual / graphical)

The specification provides both a textual and a graphical syntax. We thus consider this requirement as fulfilled.

Have state to represent work progress

The specification represents work progress based on the progress of the alpha states. We thus consider this requirement as fulfilled.

Practice must be measurable

Based on the concept of the alphas, the health and progress of a software engineering endeavour can be determined at any time during the execution of the method or practice. Therefore, the specification offers actually two approaches which allow measuring a practice: The first approach represents one of the most essential and important concepts of the specification. It is based on the alpha states which indicate the progress and health of a software engineering endeavour during its execution. The achieved alpha states express how far the team has come and how well it progresses. At this, the set of alphas allows a multidimensional view on the software engineering endeavour as the alphas represent different dimensions of the endeavour. The second approach to measure practices is based on the practice attribute measures which allows to attach certain measures with regard to the performance of the practice. We thus consider this requirement as fulfilled.

A practice is a separate concern of a method. Examples are “development from requirements to test”, “iterative development”, “component-based development”.

One of the main guiding principles of the specification is to capsule the separate concerns of methods within practices. This approach is supported by the modular structure of the kernel which supports the definition of custom practices, i.e. practices which are concerned with a specific aspect of an endeavour. For example, a practice might target a specific area of concern of an endeavour, or it might focus on a certain phase of the software engineering lifecycle. Although a practice might also cover the whole software engineering lifecycle, the intention of the kernel is to provide the possibility to model practices as separate concerns of a method. We thus consider this requirement as fulfilled.

Every practice shall be described on its own, separately from any other practice.

As methods are defined as compositions of practices, the kernel allows to systematically combining practices into methods. Multiple practices thus don’t need to be merged into one in order to represent them. Although we consider this requirement as fulfilled, it is



clearly subject to the practice author whether he defines each practice separately or if he represents multiple practices within one defined practice.

Every practice, unless explicitly defined as a continuous activity, has a clear beginning and an end.

We analyse this requirement in detail within the analysis of the Use Case “Evaluate Method/Practice”. As a result of this analysis, we state that the specification fulfils this requirement.

Every practice brings defined value to its stakeholders.

As outlined in the analysis of the use case “Evaluate Method/Practice”, the concept of value is typically difficult to grasp as the value depends on the context of the endeavour (e.g., its objective; its stakeholders; the quality of the results) and furthermore on the question in how far the value is measurable. Though, with regard to the things that need to be produced, we state that it’s actually possible to inspect a practice to determine whether these things add some value in the context of the practice definition. We therefore refer to the analysis of the use case “Evaluate Method/Practice”. Though, the question whether a certain practice adds real value to its stakeholders must be determined individually within the practice context and on the level of its actual occurrence. For example, the application of one practice could result in measurable monetary value while another practice might turn out to be useless to its stakeholders. It might be even the case that the value will not show before finishing a practice in a certain context or that the value cannot be clearly attributed to the application of a certain practice. We therefore consider this requirement as out of scope with regard to both the specification and this thesis.

Every practice must be assessable

In order to assess a practice, we refer to the analysis of the use case “Evaluate Method/Practice”. As a result of this analysis, we state that the specification fulfils this requirement.

Must not generate more paper than the original method

One of the guiding principles of the specification is to emphasize dynamic use of methods rather than method description, i.e. the specification values the enactment of methods rather than spending time with documenting methods. Therefore, the execution of a method is guided by the states of the kernel alphas which are successively progressed. The elements included in the kernel are always existent in any software engineering endeavour and documented in the specification. Hence, i.e. there is no need to repetitively describe these recurring elements. Overall, we consider this requirement as fulfilled by the specification although individual cases might deviate from this result (e.g., in case the



original method was not documented at all and the Essence approach led to the generation of several sketches and a lightweight documentation of the practice composition).

5.1.5 Discussion

With regard to the basic path, the analysis shows that the specification fulfils all relevant steps except the step which includes the use case “Establish well-formed practice”. The latter constrains the success of the basic path as the specification lacks of quality and completeness with regard to this use case (see section 5.2). Hence, while the methodologist is able to define a practice definition based on an existing method, he is not able to automatically check the well-formedness of the defined practice using a tool. As we reason about the completeness and quality of the specification with regard to the use case “Establish Well-formed Practice” separately, we limit the scope of our judgement with regard to this use case on the parts which are subject to the primary actor of the use case, i.e. the methodologist. From this point of view we state that the specification fulfils the basic path and handles all alternative paths as well as the qualities. Hence, we consider the specification as complete with regard to this use case under the condition that the included use case is handled separately.

5.2 Use Case “Establish well-formed practice”

5.2.1 Definition

Name Establish well-formed practice

Actors Tool

Short description Ensure the practice conforms to the rules/semantics defined by the kernel language so it can be deemed a well formed practice and can be composed/ be extended by/ extend with other practices to form a method. N.B. This would involve automatic validation by the tools, as opposed to the “Evaluate method” use case, which is undertaken by the practice author, or the assessment of the practice/method once enacted by the user of the practice/method. Establish Well-Formed Practice is an <<include>> use case for “Define Practice Definition”

Basic path 1 For a given practice Check Alphas Check Alpha States Check Work Products Check Activities Check Competencies

Alternative path 1 Practice is not well-formed

Pre-Condition Abstract superclasses are well-formed.



Post-Condition n/a

Qualities n/a

Table 14 Use case “Establish well-formed practice”

The pre-condition “abstract superclasses are well-formed” was added as it is required to fulfil the basic path (see following section).

5.2.2 Requirements

The goal of the use case is to ensure the well-formedness of practices using tools. Within the basic path, the well-formedness of the essential language constructs required to build a practice (i.e. Alpha, State, WorkProduct, Activity, and Competency) is automatically checked using tools.

We consider a model as well formed, iff it conforms to the static semantics of the language, i.e. it satisfies the multiplicities and the OCL constraints of its metamodel [Czarnecki and Pietroszek 2006]. Hence, a well-formed practice must conform to the static semantics (i.e. the well-formedness rules) of the language metamodel. In order to automatically check whether a specified element conforms to its well-formedness rules, a tool must be able to integrate the well-formedness rules unambiguously. The specification defines the well-formedness rules of the language in a formal way, i.e. in terms of structural constraints specified in the metamodel (i.e. multiplicities of association ends) and invariants specified in OCL (including additional operations). We thus state that the well-formedness rules are principally suited to be automated using tools.

The well-formedness rules must also be specified syntactically and semantically correct and they must be complete with regard to the semantics (i.e. the meaning) of the language element. The objective of this section is thus to analyse the quality of the well-formedness rules so that they can be implemented unambiguously by the tool author. For each language construct, we therefore analyse the syntactical correctness, the semantic correctness, and the completeness of (1) the multiplicities of its association ends and (2) its invariants including additional operations. In order to reason about the quality of the well-formedness rules for each language construct, we sum up the identified issues.

We analyse the quality of the specified multiplicities of association ends based on the class diagram. A multiplicity defines an inclusive interval of non-negative integers using a lower and a (possibly infinite) upper bound [OMG 2011b]. The default value for each bound is one. Thus, a “missing” multiplicity represents no issue with regard the syntactical correctness or completeness. As a multiplicity is defined for each association end by default, we don’t explicitly analyse their completeness. The number of identified issues regarding the completeness of the multiplicities of association ends is thus always zero. In order to define a multiplicity with zero as lower bound and an infinite number as upper bound, the UML infrastructure specification allows both the notations “*” and “0..*”. As



both notations are correct, we don’t consider the usage of both alternatives as a syntactical issue. However, within our analysis we consistently use the notation “0..*”.

Invariants and additional operations are expressed using OCL. All invariants must conform to the syntax and the static semantics of OCL. This accounts also for all additionally specified operations in OCL. In contrast to the multiplicities of association ends depicted in the class diagram, the functionality of OCL invariants and operations is often not easy to grasp at first sight. We therefore briefly explain the specified OCL invariants and operations. We evaluate the completeness of the well-formedness rules according to the semantics of the language element. If the semantics don’t require a specific invariant, the invariant true must be specified. As the invariants are not numbered in the specification we reference them in the order of their appearance.

Regarding the necessary well-formedness rules of the language constructs related to the specification elements named in the basic path of the use case, we identified additional requirements: First, we note that the language construct Practice must be included as it represents the basic container for all elements defined in a practice. We assume that this aspect is implicitly included in the use case regarding its overall goal. We thus explicitly include the language construct Practice in our analysis. Furthermore, the language constructs which are subject to our analysis represent subclasses of abstract superclasses. A practice and its specified elements are thus only well-formed if these language constructs also conform to the well-formedness rules of their abstract superclass(es). Although these classes are not instantiable and thus, not visible to the methodologist, we consider this as an important aspect regarding the implementation of the necessary well-formedness rules. We assume that the abstract superclasses are not included in the basic path for following two reasons: First, the methodologist doesn’t get directly in touch with them when creating a practice. Second, we assume that the concept of abstract super classes has not been elaborated in that detail by the time the use case was defined. However, in order to take these concepts into account, following abstract superclasses need to be considered: All elements listed in the basic path are subclasses of abstract super classes specified in the Foundation Package of the language (i.e. ElementGroup, BasicElement, and LanguageElement). In addition, the language construct Activity is also the subclass of the abstract superclass AbstractActivity. We thus include the language elements ElementGroup, BasicElement, LanguageElement, and AbstractActivity in our analysis prior to the analysis of the basic path in terms of the pre-condition.

For each language element, we first analyse its multiplicities, and then its invariants. As a result, we summarize the quality of the well-formedness rules in terms of the number of issues observed in the analysis of the syntactic correctness, semantic correctness and completeness.



5.2.3 Pre-Condition

Abstract superclass: LanguageElement

Multiplicities of Associations

LanguageElement is associated with ElementGroup, Tag and Resource. All multiplicities of the association ends are specified syntactically correct.

owner : ElementGroup [0 .. 1]

Some language elements such as Method or Kernel represent element groups and thus, don’t need an owner, i.e. the multiplicity must have a lower bound of zero. For all other types of language elements, an owner must be defined. Therefore, the upper bound of the multiplicity is specified as one. The multiplicity of the association end is thus semantically correct.

Tag : Tag [0 ..*]

Associating language elements with tags (i.e. tagging the language element) allows the user to define an infinite number of non-empty labels for a language element. Therefore, the upper bound is specified as an infinite number. Defining one or more tags is optional. Thus, the lower bound is zero. The multiplicity is thus specified semantically correctly.

resource : Resource [0 ..*]

Associating language elements with resources allows the user to define sources of information or content which are relevant to the language construct and reside outside the Essence model. A language construct may be optionally associated with one or more resources. Therefore, the lower bound is specified correctly as zero while the upper bound is specified as an infinite number. The multiplicity of the association end is thus semantically correct.

Invariants including additional operations

Two invariants are provided.

Invariant 1

The first invariant specifies the multiplicity of the association end with the role name owner: It ensures that all language elements that are not an element group need an owner. Relating this to all types of element groups, the invariant concretely says that all language elements except methods, kernels, practices, libraries, and



practice assets must have (exactly) one owner. Vice versa, any language construct which is an element group mustn’t necessarily be owned by another element group. The invariant is both semantically as well as syntactically correct.

Invariant 2

The second invariant ensures that each and every instance of LanguageElement may be related to each other via endeavour associations. The concept of endeavour properties and endeavour associations provides the possibility to define individual properties on instance level to track these during an endeavour. The invariant is semantically correct. Though, it contains two syntactic errors: The first error is a syntax error and located in line 5: Instead of a.member it must be a.memberEnd.

1

2

3

4

5

6

‐‐ Each and every instance of LanguageElement may be related to each other

via endeavour associations

LanguageElement::allInstances‐>forAll(e1,e2 : LanguageElement |

EndeavourAssociation::allInstances‐>exists(a: EndeavourAssociation |

a.member‐>exists(p1,p2 : EndeavourProperty | p1.owningAssociation=e1 and

p2.owningAssociation=e2)))

The second error violates the static semantics. It is located in lines 5 and 6: The goal of the OCL condition is to ensure that there is an endeavour association defined between all language elements (on meta-level 2). At this, the correct expression must name p1.languageElement = e1 and p2.languageElement = e1.

1

2

3

4

5

6

‐‐ Each and every instance of LanguageElement may be related to each other

via endeavour associations

LanguageElement::allInstances‐>forAll(e1,e2 : LanguageElement |

EndeavourAssociation::allInstances‐>exists(a: EndeavourAssociation |

a.member‐>exists(p1,p2 : EndeavourProperty | p1.owningAssociation=e1 and

p2.owningAssociation=e2)))

We consider the set of invariants for this language construct as complete.

Abstract superclass: ElementGroup

Multiplicities of associations

ElementGroup is associated with MergeResolution, ExtensionElement and twice with LanguageElement. All multiplicities of the association ends are specified syntactically correct.

mergeResolution : MergeResolution [0..*]



The purpose of a merge resolutions is to handle conflicts when composing element groups, e.g. a kernel and a practice. A merge resolution may be required in the composition of element groups, in case two or more members of the composed element groups have the same name and the same type. If the names of all elements of the same type are distinct, a merge resolution is not required. Thus, the lower bound of the multiplicity is specified correctly as zero. Though, it might be required to define multiple merge resolutions in the context of an element group. The upper bound of the multiplicity is thus specified correctly as an infinite number. Hence, the multiplicity is specified semantically correct.

extension : ExtensionElement [0..*]

Extensions serve to modify language elements. Using extensions, the values of the attributes of the language construct may be altered in the context of an element group (i.e. only the element group is aware of the modification). Defining one or more extensions within an element group is optional. Hence, the multiplicity of the association end is specified semantically correct.

referredElements : LanguageElement [0..*]; ownedElements : LanguageElement [0..*]

An element group may own or refer to multiple elements. The upper bound of the multiplicity is thus specified correctly as infinite number. The lower bound specified as zero doesn’t contradict the semantics, i.e. an element group may also be empty (e.g. an empty practice or empty method).The multiplicity of the association end is thus semantically correct.

With regard to the associations with the language elements MergeResolution and ExtensionElement, we note that these associations are missing in the textual listing of the associations of the language element.


The specification defines two invariants and one additional operation for the element.

Invariant 1

The first invariant defines that an element group may not own itself. The constraint is required as ElementGroup is a subclass of LanguageElement. The invariant considers both the ownership by reference and by value. It is syntactically and semantically correct.

Invariant 2



The second invariant ensures that an element group may only extend elements it owns. The invariant is semantically correct. It is syntactically not correct as it contains one syntax error: The reference to the name of the association end is noted in plural while the class diagram specifies the role name of the association end in singular.

1

2

self.extensions‐>forAll(e | self.allElements(e.targetElement.oclType())‐

>includes(e.targetElement))

Additional operation: allElements

The additional operation allElements provides the possibility to get all elements of a particular type which are available within this group and its referenced groups. The operation is used across the specification of all invariants for all language elements. The operation is syntactically correct, but lacks of semantic correctness: The recursive call of the operation allElements(ElementGroup) within the body of the operation leads to an infinite loop.

1

2

3

4

Context ElementGroup::allElements(t:OclType) Set(t)

body:self.referredElements‐>select(e|e.oclIsKindOf(t))‐

>union(self.allElements(ElementGroup)‐>collect(c|c.allElements(t))‐

>union(self.ownedElements‐>select(e|e.oclIsKindOf(t)))

The operation unions three sets of elements: In line 2, it selects all instances of type t the element group refers to. Similarly, in line 4, it selects all instances of type t the element group owns. In line 3, the operation intends to select all instances of type t within the element groups of the element group. In order to get all element groups (owned and referred to), the operation calls itself with the parameter ElementGroup. The problem is that the statement self.allElements(ElementGroup) is called over and over again in the same context whenever the operation allElements() is called and reaches line 3. Following example illustrates the situation: Let myPractice be an instance of Practice. In the context of myPractice, the operation allElements() is called to select all alphas within myPractice, i.e. self.allElements(Alpha) is called.

The first call of the operation is:

1 myPractice.allElements(Alpha)

The instantiated body looks as follows (the provided input parameter is highlighted in green):



1

2

3

4

myPractice.referredElements‐>select(e|e.oclIsKindOf(Alpha))‐>

union(myPractice.allElements(ElementGroup)‐

>collect(c|c.allElements(Alpha))‐>

union(myPractice.ownedElements‐>select(e|e.oclIsKindOf(Alpha)))

In line 2, the operation allElements() is called to gather all element groups the element group contains (highlighted in blue). In turn, the instantiated body looks as follows (the provided input parameter is highlighted in green):

1

2

3

4

myPractice.referredElements‐>select(e|e.oclIsKindOf(ElementGroup))‐>

union(myPractice.allElements(ElementGroup)‐

>collect(c|c.allElements(ElementGroup))‐>

union(myPractice.ownedElements‐>select(e|e.oclIsKindOf(ElementGroup)))

Again, in line 2 the operation allElements() is called to gather all element groups the element group contains (highlighted in blue). Thereby, the operation continues calling allElements(ElementGroup) over and over again in the context of the original element group, without abortion.

We propose following solution to search recursively for all language elements of type t within an element group (changes to the original operation are highlighted in blue):

1 2 3 4 5 6

context ElementGroup::allElements(t:OclType) Set(t) body:self.referredElements‐>select(e|e.oclIsKindOf(t))‐>union(self.referredElements‐>select(e|e.oclIsKindOf(ElementGroup))‐>collect(c|c.allElements(t)))‐>union(self.ownedElements‐>select(e|e.oclIsKindOf(ElementGroup))‐>collect(c|c.allElements(t)))‐>union(self.ownedElements‐>select(e|e.oclIsKindOf(t)))

In line 3, 4 and 5, the operation selects the element groups in all referred and owned elements. For each set of element groups, the operation calls allElements(t) to repeat searching for the elements of type t in the element group, and so on. The recursion stops when no further element group is found, i.e. the resulting set of element groups is null and thus, allElements(t) is not called any more.

With regard to the completeness of the invariants we state that a constraint is missing which ensures that two or more members of an element group with the same type mustn’t have the same name. Especially with respect to the merging mechanism, an operation could be defined which gathers all members of an element group with the same name and type. If the set of elements is zero, then the names of all members are distinct. If it is greater than zero, the invariant is violated and the merging mechanism could be triggered.



Abstract superclass: BasicElement


The language construct is not associated with other language elements.


The only invariant defined for this element is true. Hence, it is syntactically and semantically correct. We consider the set of invariants for this language construct as complete.

Abstract superclass: AbstractActivity


The language construct is associated with CompletionCriterion. The multiplicity of the association end is specified syntactically correct.

completionCriterion : CompletionCriterion [1..*]

An abstract activity has to have completion criteria to tell the practitioner when the abstract activity (i.e. the activity space or the activity) is completed. Therefore, the lower bound of the multiplicity is specified correctly as one. Multiple completion criteria may be defined as reflected by the upper bound representing an infinite number. Hence, the multiplicity of the association end is semantically correct.


The only invariant defined for this element is true. Hence, it is syntactically and semantically correct. We consider the set of invariants for this language construct as complete.

5.2.4 Basic Path

Practice


The language construct is not associated with other language elements.




The specification defines overall six invariants for this language construct ensuring that the elements used in a practice are available within the practice (i.e. owned by value or by reference).

Invariant 1

The first invariant ensures that the alphas and work products associated by the work product manifests are visible within the practice. The invariant therefore checks if the alphas and work products associated in the work product manifest are included in the set of alphas and work products the practice owns or refers to. The invariant is specified both syntactically and semantically correct.

Invariant 2

The second invariant ensures that associated activities are visible within the practice. The invariant therefore checks if the activities and activity spaces associated by activity associations are included in the set of activities and activity spaces the practice owns or refers to. The invariant is specified both syntactically and semantically correct.

Invariant 3

The third invariant ensures that all alphas and work products involved in actions of activities are available within the practice. The invariant therefore checks if the alphas and work products involved in actions of activities are included in the set of alphas and work products the practice owns or refers to. The invariant is specified both syntactically and semantically correct.

Invariant 4

The forth invariant ensures that completion criteria are only expressed in terms of states which belong to alphas or levels of details which belong to work products which are available in the practice. The invariant checks that at for each completion criterion either an alpha state or a level of detail of a work product must be defined. If the completion criterion depends on an alpha state, the alpha state referred by the completion criteria must be included in the set of alpha states in the practice. If the completion criterion depends on a level of detail of a work product, the level of detail of the work product referred by the completion criteria must be included in the set of level of details of the work products in the practice. The invariant is semantically correct. Though, it contains three syntactic errors.



The first error is a syntax error located in the expression wp.levelsOfDetails in line 8. Instead of wp.levelsOfDetails it must be wp.levelOfDetail as this is the correct name defined in the model. The second error is a syntax error located in the expression self.allEments(WorkProduct) in line 7. The expression is written correctly self.allElements(WorkProduct).

1

2

3

4

5

6

7

8

‐‐ Completion criteria are only expressed in terms of states which belong

to alphas or levels of detail which belong to work products which are

available in the practice.

self.allElements(ActivitySpace)‐>forAll (as | as.completionCriterion‐

>forAll (cc | cc.state<> null and cc.workProduct = null and

self.allElements(Alpha)‐>exists(a | a.states‐>includes(cc.state))) or

(cc.state = null and cc.workProduct<> null and self.allEments(WorkProduct)‐

>exists(wp | wp.levelsOfDetail‐>includes(cc.workProduct)))))

The third error violates the static semantics. It is related to the expression cc.workProduct which uses the associated attribute workProduct in the context of completionCriterion. The intention of the expression is to refer to the levels of details of the work product. Thus, the correct statement must be cc.levelOfDetail instead of cc.workProduct as the according to the role name of the association end is levelOfDetail.

1

2

3

4

5

6

7

8

‐‐ Completion criteria are only expressed in terms of states which belong

to alphas or levels of detail which belong to work products which are

available in the practice.

self.allElements(ActivitySpace)‐>forAll (as | as.completionCriterion‐

>forAll (cc | cc.state<> null and cc.workProduct = null and

self.allElements(Alpha)‐>exists(a | a.states‐>includes(cc.state))) or

(cc.state = null and cc.workProduct<>self.allEments(WorkProduct)‐

>exists(wp | wp.levelsOfDetail‐>includes(cc.workProduct)))))

Invariant 5

The fifth invariant ensures that the activities’ required competencies are visible within the practice. The invariant therefore checks if the competency levels addressed by the activities of the practice are included in the set of possible competency levels of the competencies the practice owns or refers to. The invariant is specified both syntactically and semantically correct.

Invariant 6

The sixth invariant ensures that all elements associated with a pattern are visible within the practice. The invariant therefore checks if the language elements



associated with patterns are included in the set of language elements the practice owns or refers to. The invariant is semantically correct. Though, it is syntactically not correct as it contains one syntax error. The error is located in line 4: The operation forall must be written correctly forAll.

1

2

3

4

‐‐ All elements associated with a patterns are visible within the practice.

self.allElements(Pattern)‐>forAll (p | p.associations‐>forAll (pa |

pa.elements‐>forall (pae | self.allElements(pae.oclType)‐> includes (pae))

The set of invariants is not complete as the containment of practices is not constrained, i.e. a practice may own or refer to any type of language element. Thereby, a practice may contain methods. According to the semantics, methods compose practices and kernels, but the intention is not that they may be owned by practices.

Alpha


The language construct is associated with State. The multiplicity of the association end is specified syntactically correct.

state : State [1..*]

States serve to track the evolution of alphas. Therefore, an alpha must have at least one state as reflected by the lower bound of the multiplicity. The number of states an alpha may have is not limited. Therefore, the upper bound is specified as an infinite number. The multiplicity is thus specified semantically correctly.


The specification defines one specific invariant for this language element.

Invariant 1

The invariant ensures that all states of an alpha must have different names. The invariant therefore checks for all states of an alpha if the names of the states are disjoint. The invariant is specified both syntactically and semantically correct.

The set of invariants is complete. Though, we note that according to the semantics, the instances of alphas (i.e. sub- and superordinate alphas) form acyclic graphs. At this, no invariant constrains that cyclic graphs may be formed. As the relationship is realized via alpha containments, an according invariant is not subject to the language construct Alpha. Therefore, we don’t consider this as an issue regarding the well-formedness of an alpha.



State


The language construct is associated with Checkpoint, and itself. All multiplicities of the association ends are syntactically correct.

checkListItem : Checkpoint [0..*]

According to the semantics of State, a state of an alpha is determined by evaluating its checklist items: If all checklist items are met, the state has reached an important milestone in the evolution of an alpha. The semantics thus imply that a state must have at least one checklist item to determine its state. Though, the lower bound of the multiplicity states is zero and thus, defining checklist items for a state is specified as optional. It is thus questionable how the state of the alpha shall be evaluated if it has no checklist items defined. Thus, the lower bound of the association should be one. The upper bound of the multiplicity reflects correctly that an infinite number of checklist items may be defined.

Successor : State [0..1]

The states of an alpha are linearly progressed, i.e. the states are linked. The navigated association represents the relationship between the states as a singly-linked list. At this, the semantics of the language construct Alpha state that the states of an alpha are not just one-way linear progressions: If the check list items of a state are not met, it is allowed to go back to a previous state while the linear ordering of states just denotes the usual way of progression. Though, this mechanism is not related to the structural relationship between states, but subject to the dynamic semantics: During the execution of a practice, a state may be reassessed and, if required, the state of the alpha may be set back. Therefore, it is semantically correct to model the association as singly-linked list.

A state has no successor if only one state is defined for an alpha, i.e. the lower bound of the multiplicity is specified correctly as zero. The state has one successor, if more than one state is defined and if a state is not the last state in the linked list of states. A state may not have multiple successors in order to progress the states in a deterministic way. The upper bound of the multiplicity is thus correctly specified as one.

Invariants

The specification defines two invariants and one additional operation for this language element.



Invariant 1

The first invariant ensures that all checkpoints of a state have different names. The invariant therefore checks for all checklist items of a state if the names of the checklist items are disjoint. The invariant is specified both syntactically and semantically correct.

Invariant 2

The second invariant ensures that a state may not be its own direct or indirect predecessor, i.e. the states may not be linked to each other in a cyclic way. The invariant therefore ensures that a state is not included in the set of its successors. In order to get the set of successor states for a given state, it uses the additional operation allSuccessors. The invariant is specified both syntactically and semantically correct.

Additional operation: all Successors

The additional operation allSuccessors returns all successors for a given state. Therefore, it recursively populates a set of states with all states succeeding the given state. The recursion stops if a state has no successor. The operation is specified both syntactically and semantically correct.

The set of invariants is complete.

WorkProduct


The language construct is associated with LevelOfDetail. The multiplicity of the association end is syntactically correct.

levelOfDetail : LevelOfDetail [0..*]

The semantics state that a work product could be described at different levels of details, i.e. it doesn’t necessarily have to be described at different levels of detail. Thus, both the lower bound of zero is specified correctly. However, multiple levels of detail can be used to describe a work product. The upper bound is thus correctly specified with an infinite number. The multiplicity of the association end is semantically correct.





Invariant 1

The invariant ensures that all levels of detail of a work product must have different names. For all levels of detail of work product, the invariant therefore checks if the names of the levels of detail are disjoint. The invariant is specified both syntactically and semantically correct.


Activity


The language construct is associated with CompetencyLevel and Action. The multiplicities of the association ends are syntactically correct.

requiredCompetencyLevel : CompetencyLevel [0..*]

For any instance of activity, a collection of required competency levels can be defined. The required competency levels indicate the competencies required by the person who conducts this activity to succeed in its completion. The semantics don’t indicate that competencies including competency levels must be necessarily defined within a practice. Thus, we consider the lower bound of zero as semantically correct. The semantics of Activity state that the performer of an activity might require multiple competencies to perform the activity successfully. The upper bound of the multiplicity is thus specified correctly with an infinite number.

action : Action [0..*]


The only invariant defined for this element is true. Hence, it is syntactically and semantically correct.

The set of invariants for this language construct is not complete: The kernel specification states that higher competencies build upon lowers, i.e. a higher level has all traits of the lower level. However, this is not clearly stated in the semantics of the language specification. With respect to the competencies required for an activity, an instance of activity may even have multiple required competency levels of the same competency. We thus consider this issue as a missing invariant.



Competency


The language construct is associated with CompetencyLevel. The multiplicity of the association end is syntactically correct.

possibleLevel : CompetencyLevel [0..*]

While a competency describes a certain kind of competency, the competency levels add a qualitative grading to them. At this, the semantics are not clear whether for each competency at least one competency level must be necessarily defined, or not. However, the semantics assume that for each team member, a level of competency for each individual competency can be defined. Furthermore, a competency without competency levels cannot be actively incorporated in a practice model: The link that integrates the functionality of the competency is established between an activity and the required competency level (rather than between activity and competency). We thus question the semantic correctness of the lower bound of the multiplicity which is specified as zero, and state it should be specified as one. As multiple competency levels may be defined for a competency, the specification of the upper bound with an infinite number is correct.



Invariant 1

The invariant ensures that the possible levels are distinct. For all possible levels, the invariant therefore checks if the names of possible levels are disjoint. The invariant is specified both syntactically and semantically correct.


5.2.5 Alternative path

This alternative path considers the case that a practice is not well-formed. Though, the path doesn’t describe any mechanism how to handle this issue. As the basic path is primarily considered with a tool supporting the methodologist by automatically validating the well-formedness of the defined practice, we also focus on the tool support within this alternative path. As a result of the event which leads to this paths, the tool should highlight the detected issues and give recommendations how to solve the issue. As such tooling implementation is not subject to the specification, we don’t consider this alternative path as relevant.



5.2.6 Discussion

The analysis investigated into the quality of the well-formedness rules for the language constructs in the basic path including their abstract superclasses. For each language construct, the multiplicities of its association ends and its OCL invariants including additional operations have been analysed with regard to their syntactical correctness, their semantic correctness, and their completeness.

With regard to the pre-condition (i.e. the well-formedness of the abstract superclasses), errors were found regarding the syntactic and semantic correctness of the specified invariants and additional operations in OCL (Table 15).

Language construct

Well-formedness rules

# Issues syntactic correctness

# Issues semantic correctness

# Issues completeness

LanguageElement

Multiplicities of association ends

0 0 (0)

Invariants incl. additional operations

2 0 0

ElementGroup


0 0 (0)


1 1 1

BasicElement


0 0 (0)


0 0 0

AbstractActivity


0 0 (0)


0 0 0

Summary Multiplicities of association ends

0 0 (0)


3 1 1

Table 15 Issues in well-formedness rules of abstract superclasses

As all language constructs named in the basic path are dependent on the well-formedness of these abstract superclasses, strictly speaking, these errors prevent establishing a well-formed practice right up front. Especially the semantic error refers to an operation which is reused across the specification leading to severe error propagation.



Also regarding the basic path, several errors – especially in the context of the language construct Practice - were found in the specified OCL invariants and additional operations (Table 16).

Language construct

# Issues Syntactic correctness

Semantic correctness

Completeness

Practice Multiplicities of association ends

0 0 (0)


4 0 1

Alpha Multiplicities of association ends

0 0 (0)


0 0 0

State Multiplicities of association ends

0 0 (0)


0 0 0

WorkProduct Multiplicities of association ends

0 0 (0)


0 0 0

Activity Multiplicities of association ends

0 0 (0)


0 0 1

Competency Multiplicities of association ends

0 1 (0)


0 0 0

Summary Multiplicities of association ends

0 1 (0)


4 0 2

Table 16 Issues in wellformdness rules of language constructs in basic path

Two of the syntax errors in the analysed OCL invariants result from inconsistencies in the specification of the role names of the association ends. Most of the role names are specified in singular while some are specified in plural. An analysis of the multiplicities and role names of all association ends for all specified language constructs shows that the



inconsistency between singular and plural occurs when the upper bound of the multiplicity is defined as greater than one [Table 17].

Multiplicity 1 0 .. 1 0 .. * * 1 .. * 2 .. *

Role name in plural

0 0 3 1 1 0

Role name in singular

19 7 8 9 2 1

Table 17 Multiplicities of role names in singular and plural

The associations with role name in plural and upper bound of multiplicity greater than one are:

PatternAssociation elements : LanguageElement [*] LanguageElement properties : EndeavourProperty [0 ..*] ElementGroup ownedElements : LanguageElement [0 ..*] ElementGroup referredElements : LanguageElement [0 ..*] Alpha states : State [1.. *]

The lack of consistency in naming the role names is not only reflected in the syntax errors in the OCL invariants, but also in inconsistencies in the textual listing of the associations. For example, the association ends resource and tag are denoted in singular in the class diagram while in the textual listing of the associations they are denoted in plural.

While the syntactic errors are supposed to be relatively easy to identify and to correct, one of two missing invariants might lead to fundamentally badly formed practices as the containment of practices is not restricted, i.e. a practice may contain methods which in turn may contain practices which in turn may contain methods and so on.

In summary, the specification lacks of completeness as three missing invariants were identified. Furthermore, the specification lacks of quality as the specified invariants and operations in OCL suffer from syntactic and semantic issues. As a result we state that the specification fulfils this use case only partly.

5.3 Use Case “Extend practice”

5.3.1 Definition

Name Extend Practice

Actors Practice/Method Developer Project Manager

Short description To provide the mechanisms to enable extension of existing practices – by addition, subtraction and modification.



Basic path Enable extension of existing practices

addition of elements

subtraction of elements

modification of elements

Alternative path n/a

Pre-Condition n/a

Post-Condition n/a

Qualities n/a

Table 18 Use case “Extend practice”

The use case doesn’t name a basic path. We therefore extracted a basic path consisting of one step from its brief description.

5.3.2 Requirements

The goal of the use case is to extend practices in order to tailor practices regarding different circumstances. By extension, the use case names the modification, addition, and subtraction of elements in the context of a practice. Thus, in order to fulfil the use case, the language must provide the possibility to add, subtract and modify elements in an existing practice. The objective of the analysis is thus to identify in how far the specification provides these mechanisms.

5.3.3 Basic Path

Modify elements in an existing practice

In order to modify an element to suit a new context, the language provides an extension mechanism. The language therefore defines the language construct ExtensionElement which is available to the practice author (i.e. on meta-level 1) in terms of an extension. An extension allows changing the value of an attribute of an element in the context of an element group. ExtensionElement has one associated attribute targetElement which refers to the language construct to be extended, one class attribute targetAttribute to name the target attribute, and another class attribute extensionFunction to define a function (i.e. an OCL post condition) how the value of the target attribute should be changed.

The attributes and the structural relationship of the language construct ExtensionElement (on meta-level 2) define following rules regarding the application of an extension:

ExtensionElement represents an associated attribute of ElementGroup. The association is defined as composition, i.e. an extension can only be defined in the context of an element group. The extension is then part of the element group. The



multiplicity of the association end extension is 0..*. Thus, multiple extensions may be defined in the context of one element group.

The association between ExtensionElement and LanguageElement specifies that any type of language construct may be defined as target element. Though, an invariant ensures that the target element mustn’t be an instance of ExtensionElement or MergeResolution, i.e. it is not allowed to extend extensions or merge resolutions. The multiplicity of the association end with the role name targetElement is 1 while the multiplicity on the other end of that association is 0..*. Hence, each extension may extend one target element, while a target element may be extended by multiple extensions.

Using an extension, the modification of the element is only visible from the viewpoint of the element group which contains the target element and the extension. Thereby, an extension is aspectual and non-destructive way with respect to the extended element. It is aspectual as the extended element is not aware of the modification. It is non-destructive as the extended element is by itself not changed.

Besides the specification of the language construct in the metamodel of the language, the specification provides a detailed description of the extension mechanism in the section Composition and Modification. At this, all rules implied by the structure of ExtensionElement in the metamodel align with the principles described in that section. In addition, the section explains how precedence and chaining is handled by the mechanism:

Extensions are applied cumulatively, i.e. if an element group A extends the element X, and element group A is referenced by element group B which also extends X, then both extensions are applied. At this, the extensions added to X by A are applied first. The extension added to X by B are applied on top.

An element may be both subject to extension and merging. If an element is subject both to extension and merging, then the extensions are applied first, and merging is applied second.

Furthermore, the section explains how to define an extension function. An extension function names an OCL post condition for a function which uses the type of the target attribute as input. As a result, the function returns a value of the type of the target attribute. The OCL post condition defines how the input should be changed. At this, two exemplary templates defining two OCL post conditions are included in the specification. The first template replaces the value of the target element with some fixed output, while the second template defines a replacement to be applied on a pattern in the target attribute. At this, we remark that the first post condition template contains a syntactic error regarding the expression Tuple:

1

2

post: result = input.regexReplaceAll(OrderedSet(Tuple(“somePattern”,

“someReplacement”)))



According to the OCL specification [OCL Specification], the expression Tuple is not applied correctly. In order to provide an argument representing an ordered set of tuples, the post-condition template should name correctly as follows:

1

2

post: result = input.regexReplaceAll({Tuple{somePattern=‘somePattern’,

someReplacement=‘someReplacement’}})

At this, the operation regexReplaceAll must be defined with the signature

1

2

regexReplaceAll(input : OrderedSet(TupleType(somePattern:String,

someReplacement:String))) : String

The specification recommends that tools should at least supply extension functions which satisfy the two post-condition templates provided in the specification. It is recommended that they support even more post conditions.

The extension mechanism also provides the possibility to suppress elements. As this aspect is close to the subtraction of elements within a practice, we will explain this mechanism within the third goal of this use case (“subtract elements from an existing practice”).

Hence, in order to extend an element, the practice author first creates an extension. Second, he references the target element, i.e. the element whose attributes are subject to change. Third, he specifies the name of the attribute of the target element which is to change. Finally, he defines an OCL post condition for the extension function. For example, the new value might be a fixed value independent from the original value, or might depend on the original value.

We consider the goal of extending elements as fulfilled by the specification. We don’t consider the syntactical error in both post-condition as critical to this use case as these issues are more subject to tool implementation (methodologists are typically not expected to define OCL conditions). However, as the specification provides recommendations for tools to support the practice author (which is not explicitly required by the use case), we consider this part of the basic path as fulfilled by the specification.

Add elements to an existing practice

In order to add elements to an existing practice, the practice author has two options. The first option is to refer to already existing elements defined in a kernel or other practices/methods. The second option is to create new elements. Independently of the chosen way, the practice author may add following elements:



(Subordinate) alphas including states (including checkpoints) Work products including levels of details (including checkpoints) Activity spaces including completion criteria Activities including actions and completion criteria Competencies including competency Levels Patterns, tags, and resources

In order to integrate the added elements in the existing Practice, the practice author may link the added elements to the existing elements. For example, he may create a new work product and bind it to an existing alpha. Furthermore, he may use the extension mechanism (see first goal of the use case) to modify existing elements so that he can integrate the new elements. For example, he may insert a new activity into the existing chain of activities. At this, he changes the association ends of the predecessor and the successor activity of the new activity so that the ends point to the new activity.

Regarding the extension of practices with additional alphas, the language specification also provides the possibility to define subordinate alphas. Subordinate alphas are more granular alphas which contribute to the states of a more abstract alpha. The definition of subordinate alphas is realized based on the language construct AlphaContainment. An alpha containment represents a subordinate-alpha relationship between alphas. At this, one alpha is defined as the subordinate alpha, while the other alpha is defined as the super alpha. The relationship between subordinate alphas and super alphas may generally be many-to-may. A lower and an upper bound indicate the number of instances of subordinate alphas. In order to add a subordinate alpha, the practice author creates an alpha and defines its superordinate alpha(s). He then specifies the number of instances of the subordinate alpha. We consider this part of the basic path as fulfilled by the specification.

Subtract elements from an existing practice

In order to subtract elements from a practice, the practice author is offered two possibilities: He may either physically remove an element from the practice model, or he may suppress it.

When suppressing an element, the element is not visible, but still physically available in the practice. Suppression is enabled using the extension mechanism. With respect to the explanation of the general functionality of the extension mechanism, we refer to the analysis of the first goal of the use case. In order to suppress elements, an extension can be applied which sets the attribute name of an element to null. Defining such an extension function is only allowed for language elements that have their attribute isSuppressable set to true.

The specification constrains the application of the suppression mechanism as follows: An element which is associated with another unsuppressed element in the same element group may not be suppressed if the association is mandatory for the other element. Doing



so would result in a pending reference. For example, a superordinate alpha of a subordinate alpha may not be suppressed as the association is mandatory for the subordinate alpha.

With regard to tool support, the specification names following requirements:

If the practice author wants to suppress an element which is referenced necessarily by another unsuppressed element, tools should support cascading extensions, i.e. prompt the practice author to make suitable extensions to the referencing element. Thereby, the practice author may suppress the element he wants to while retaining the model consistent.

Tools must automatically suppress unnamed elements which represent links between elements (i.e. links represented by instances of AlphaContainment, WorkProductManifest, and ActivityAssociation) if one of their ends is suppressed.

In order to physically remove an element, the practice author may delete or remove it. The element is being deleted if it is owned by the practice (i.e. the element doesn’t exist anymore). If the practice refers to an element in another kernel or practice, only the reference to the element is being removed (i.e. the element still exists in the other kernel or practice).

With regard to tool implementation, the specification doesn’t consider how to handle dangling references when deleting or removing elements: If an element is deleted which is associated with another element, a tool needs to implement a mechanism how to handle the dangling association. Dangling associations may occur when defining links of type AlphaAssociation, AlphaContainment, WorkProductManifest, and ActivityAssociation. For example, when deleting an associated alpha, the tool could either delete the association, or it could assign a null value to the according association end. In the latter case, the practice is not consistent until the practice author has provided a new alpha for the association end. Another option would be that the tool prompts the user to decide which action should be taken. However, as this aspect is subject to tool implementation, we don’t consider it as critical to this use case. We consider this part of the basic path as fulfilled by the specification.

5.3.4 Discussion

The specification fulfils all three parts of the basic path. As a result, we consider the specification as complete regarding this use case.

5.4 Use Case “Compose method”

5.4.1 Definition

Name Compose method



Actors Practice/Method Developer

Short description Compose selected practices, and or practice extensions with a kernel into a method.

Basic path 1 Create method Name the Method Definition that is to be created

Add a description introducing the purpose of the Method

2 Add appropriate kernel Browse available Kernel Definitions

Select the specific Kernel Definition that is appropriate for the method Definition that is being created

3 Add practice to be composed with the kernel Browse available Practice Definitions

Select the specific Practice Definition that is to be composed with the chosen Kernel Definition to form the Method Definition

4 Combine practice with kernel to form method For each Alpha element in the Practice Definition: Find the

referenced Kernel element

5 Publish the method

Alternative path 1 Alpha not in Method (new element)

2 Insert new Alpha state

3 Insert new Work product level of detail

Pre-Condition Kernel and practices have been authored and comply to the language definition

Post-Condition An executable Method. I.e. one that can be used to generate work to achieve the goals.

Qualities Provide clear rules describing what may happen during merge conflicts

Provide a mechanism to allow the user to decide to be informed at the time of the merge and be able to resolve the conflict.

Table 19 Use case “Compose method”

We decomposed the brief description into “brief description” and “qualities”, in order to make the required qualities explicit.

5.4.2 Requirements

The goal of the use case is to compose selected practices with a kernel into a method. In the context of the Essence specification, a method is defined as a set of practices expressing a particular way of working which addresses a specific aspect of an endeavour



(see 2.1). The specification explicitly supports composing practices and kernels into a method. However, it might be required to solve conflicts as all elements within an element group (i.e. also within methods) must be unique. For example, it might happen that the kernel and the practice both contain an element with the same name. As outlined by the use case, the specification must provide clear rules handling such conflicts. With regard to tool support, the use case also demands a mechanism to inform the user at the time of the merge and to support him in resolving the conflict.

The use case defines one basic path, and three alternative paths. The basic path composes a single practice with a kernel. The alternative paths hold when the practice author needs to insert a new alpha, a new alpha state, or a new work product level of detail.

The objective of our analysis is to analyse in how far the specification allows the practice author to compose a method based on a practice and a kernel, including the resolution of conflicts and tool support. With respect to the steps number one to three, we analyse how the specification supports the practice author in creating the method, selecting the relevant kernel, and selecting the relevant practice. In step number four, we describe how the practice author finalizes the composition. With regard to the conflicts which may arise, we analyse in detail what might happen if both the kernel and the practice contain an alpha with the same name.

5.4.3 Basic path

Step 1: Create method

The language specifies the language construct Method which serves as a container for practices. A method is an element group and thus must be defined including a name, a brief description and a description. Optionally, an icon may be defined. Each method has also an attribute purpose representing an explicit short statement of the goal of the method. Each method references one base kernel, i.e. the kernel the method is based on.

In order to create a method, the practice author thus defines and names a method. He provides a brief description and a more detailed description of the method, and names the purpose of the method. Optionally, he defines an icon. Referencing the base kernel of the method is subject to the next step.

We consider the step as fulfilled by the specification.

Step 2: Add appropriate kernel

According to the precondition of the use case, the kernel has been authored and complies with the language definition, i.e. the kernel has a name, a brief description and a description defined. Thus, the practice actor is able to browse through the kernel definitions



and to select the appropriate kernel. When the practice author has selected the appropriate kernel, he defines the kernel as the base kernel of the method.


Step 3: Add practice to be composed with the kernel

According to the precondition of the use case, practices have been authored and comply with the language definition, i.e. each practice has a name, an objective, a brief description and a description defined. Thus, actor is able to browse through the available practice definitions, and to select the practice to be composed with the chosen kernel definition. In order to evaluate whether the selected practice suits the purpose of the method, we refer to the use case “Evaluate Method/Practice”.


Step 4: Combine practice with kernel to form method

When composing two element groups (e.g. a kernel and a practice) into a new one, the new element group must remain consistent regarding uniqueness of the names of its elements. For example, suppose two element groups B and C which are composed into a new element group A. If the names of the elements in B are distinct from the elements in group C, all elements in group A have unique names and thus, element group A is composed without any complications. If there is an element in group B and an element in group C with the same name, it is required to check in how far a conflict exists, and decide how to solve it.

The specification therefore distinguishes between three cases:

1) The two elements are of same name but different type. 2) The two elements are of same name and same type, and semantically equivalent,

i.e. all attributes with the same label have the same non-null values. 3) The two elements are of same name and same type, but semantically distinct, i.e.

they have at least two attributes with the same label but a different non-null value.

Following rules apply:

In the first case, an extension must be defined on one of these elements to modify its name. With respect to the extension mechanism, we refer to the analysis of the use case “Extend Practices”.

In the second case, the elements are automatically merged into one element using the basic merge algorithm: The element in the new element group is formed using the same non-null values for its attributes for the same labels as the original elements. If one of these elements has a non-null value for an attribute with a



specific label while the other element has not, the basic merge algorithm uses the non-null value for the attribute of that label in the new element. Again, the merge is only visible from the perspective of the new element group.

In the third case, a merge resolution must be defined. A merge resolution allows defining a specific value to be used in the new element for the attribute with a specific label where the original elements differ in their non-null values. The merge resolution is defined in the context of the element group which composes the other element groups.

A merge resolution is an instance of the language construct MergeResolution. MergeResolution has three class attributes: targetAttribute names the attribute whose values are in conflict; targetName names the name of the element in the composed element group; resolutionFunction defines a function (i.e. an OCL post condition) to determine how the value of the target attribute should be changed to solve the conflict. The result of the function is a single value used for the target attribute in the new element group.

The attributes and the structural relationship of the language construct MergeResolution (on meta-level 2) define following rules on (meta-level 1) regarding its application:

MergeResolution represents an associated attribute of ElementGroup. The association is defined as composition, i.e. a merge resolution can only be defined in the context of an element group. The merge resolution is then part of the element group. The multiplicitiy of the association end mergeResolution is 0..*. Thus, multiple merge resolutions may be defined in the context of one element group.

A merge resolution doesn’t reference the target element, but defines the name of the target element. Thus, it is not possible to define a merge resolution for the name attribute of an element.

Merging is local to the composed element group, i.e. it is aspectual and non-destructive with regard to the merged elements. It is aspectual as the neither the element groups being composed, nor their merged elements are aware of the merge. It is non-destructive as the contents of the composed element groups including their elements remain the same.

Besides the specification of the language construct in the metamodel of the language, the specification provides a detailed description of the mechanism in the section Composition and Modification. At this, all rules implied by the structure of MergeResolution in the metamodel align with the principles described in that section. Furthermore, the section provides following rules:

Language elements without name representing a link between elements (i.e. links of type AlphaContainment, WorkProductManifest, ActivityAssociation) are automatically equipped with a derived name to detect and handle merge conflicts. The name is then formed by concatenating the names of associated elements.



If two elements in the element groups being composed are merged, and (one of or both of) the element groups being composed extend the element, then the extended version is merged in the composed element group, i.e. extensions of elements in an element group are applied prior to merging these elements in another element group.

If an element group A merges two elements x, and another element group B then references A, B may extend the element x, and may merge it with another element x from an element group C.

Furthermore, the section explains how to define the merge resolution function. A merge resolution names an OCL post condition for a function which uses as input the names of the merged element groups and the values of the attributes with the same label which differs in their values. The input is defined as a set of tuples. The result of the function is a single value which is used for the target attribute in the new element group.

We remark that (1) a closing bracket is missing (line 2), and (2) the argument is syntactically not correct:

1

2

merge(input : Set(Tuple(String,

targetAttribute.oclType())):targetAttribute.oclType()

According to the OCL specification, the type Tuple must be defined as follows:

1

2

merge(input : Set(TupleType(elementGroupName:String,

targetAttrValue:targetAttribute.oclType()))):targetAttribute.oclType()

We defined the names of the arguments within the tuple based on their meaning, i.e. one could also name them differently. We also remark that the provided example for the input to the function includes syntactical errors regarding the labelling of the first member of the tuple:

1 {(B,”London”),(C,”Paris”}

As the first argument of the tuple is of type string, it must be enclosed in quotation marks:

1 {(“B“,”London”),( “C“,”Paris”}

The OCL post condition defines the value of the target attribute. At this, two exemplary templates are provided defining two OCL post conditions for this function. The first template provides some fixed value for the attribute of the target element. The second template uses the attribute value of one of the element groups which is provided as input for the function.



Regarding tool support, the specification emphasizes that tools must support the practice author in case a merge conflict remains unresolved (i.e. an element group is badly formed):

Tools must detect badly formed element groups and prompt the user to resolve the issue.

Tools should prevent that a badly formed element group may be referenced, or instantiated.

Tools should detect if an already referenced or instantiated element group is edited and rendered badly formed, and prompt the user to resolve this issue.

In reference to the use case step, we describe the outlined mechanisms with respect to the alphas within the combined kernel and practice. Hence, in order to combine the practice with the kernel to form the method, the practice author refers to the selected practice in the context of the method. The method then owns the practice by reference.

If the names of the alphas in the kernel and the names of the alphas in the practice are distinct, then the discipline that each name is unique in the context of the method is maintained. Hence, the application of an extension to change the name of one of the alphas is not relevant here. The alphas are neither subject to the basic merging algorithm nor to merge conflict resolution, and no action is required from the practice author.

If there exists an alpha in the practice which has the same name as an alpha in the kernel, two possibilities exist:

(1) Both the alpha in the practice and the alpha in the kernel offer the same non-null value for the same attribute label.

(2) Both the alpha in the practice and the alpha in the kernel offer a different non-null value for the same attribute label.

In the first case, the basic merging algorithm holds: For all attribute with the same label where both the alpha in the kernel and the alpha in the practice offer the same value, that value is used for the attribute with that label for the alpha in the method. If one alpha offers a non-null value for an attribute with a specific label while the other doesn’t, then the non-null value is used for the attribute with that label for the alpha in the method. At this, the alpha in the method is formed automatically without any action required from the practice author.

In the second case, a merge conflict exists which requires a merge resolution to determine the value for the attribute of the relevant label. The action of the practice author is required to resolve this conflict: Therefore, the practice author defines a merge resolution by creating an instance of type MergeResolution in the context of the method. He defines the target name as the name of the relevant alpha, and the target attribute as the label of the relevant attribute. Finally, he defines an OCL post condition for the merge resolution function.



We exemplify the process as follows: Suppose two alphas with the name “Work” in a kernel K and in a Practice P. Both alphas differ in their brief description. More precisely, the values of their attributes with the label briefDescription differ. In order to compose K and P into a method, the practice author must determine a value for the attribute with the label briefDescription in the context of the composed method. Therefore, he defines a merge resolution. He assigns the name of the alpha (i.e. “Work”) to the attribute targetName, and he assigns the label of the attribute (i.e. briefDescription) to the attribute targetAttribute. The input for the resolution function then would be, for example:

1 {(“K”, “Activity involving mental or physical effort done in order to achieve

a results”),(“P”,” Physical or mental effort or activity directed toward the

production or accomplishment of something2.”)}

The author decides for example, to keep the brief description of the alpha in the kernel K. Therefore, he defines the OCL post condition

1 post: result = input.selectValueFrom(“K”)

where selectValueFrom is a function which selects the attribute value of the tuple with the name of the element group provided as argument.

We consider the step as fulfilled by the specification. We don’t consider the syntactical errors in the OCL expressions as critical to this use case as these issues are more subject to tool implementation (methodologists are typically not expected to define OCL conditions).

In addition, we state that the two required qualities are considered: Rules handling merge conflicts are clearly specified. With respect to a mechanism allowing the user to decide to be informed at the time of the merge, the specification considers this rightly as a tooling issue: As the specification serves to define the principles of the language independently from tool implementation, this aspect is not part of the standard. However, the specification names and considers this aspect as far as possible and thus, we consider this quality as fulfilled in the extent it is possible.

Step 5: Publish the method

We consider the publishing of the method as tooling issue. Thus, we don’t consider this step as relevant.

2 Definition „work“ [The Free Dictionary: http://www.thefreedictionary.com/works ]



5.4.4 Alternative paths

The alternate paths (i.e. extension the practice with alphas, alpha states and work products) are covered within the analysis of the use case “Extend Practice”. In order to reason about the completeness of the alternate paths we thus refer to that use case. As a result of its analysis, we state that the specification fulfils the alternative paths.

5.4.5 Qualities

The analysis of the basic path outlines that the specification provides clear and concise rules describing what may happen during merge conflicts and how to handle this. With respect to the provision of a mechanism which allows the user to decide to be informed at the time of the merge and be able to resolve the conflict, we argued that this is out of scope of the specification.

5.4.6 Discussion

The specification fulfils both the basic path as well as the alternative path and the qualities (provided that they are relevant). As a result, we consider the specification as complete regarding this use case.

5.5 Use Case “Evaluate method or practice”

5.5.1 Definition

Name Evaluate method or practice

Actors Practice Author/ Project Manager

Practitioner

Short description Evaluate practice against a set of rules that defines whether a practice is good.

Basic path 1 Practice Author/ Project Manager: Evaluate effectiveness of a practice against a set of rules, for example

whether it clearly defines the purpose of the practice

whether is has a beginning and an end

in what circumstances to apply it

what problem or opportunity or endeavour it helps with

does it contain all the necessary things that need to be done to achieve the goal

does it contain all necessary things that need to be produced

what kind of skills are required to do the work



ensure the users know when something has been achieved

ensure whether the things that needed to be produced meet the criteria set down by the initial statement of the problem or opportunity or endeavour

ensure whether the things that needed to be produced add value

Basic path 2 Practitioner: Evaluate efficiency of a practice against a set of rules

whether the practitioners have achieved the goals laid out in the practice

how easy it was to follow

any metrics about the method or practice that can be gathered to measure its effectiveness


Pre-Condition n/a

Post-Condition n/a

Qualities n/a

Table 20 Use case “Evaluate method or practice”

The use case doesn’t name a basic path. Though, in the extensive description of the original use case document, the use case defines two levels of practice evaluation (i.e. effectiveness and evaluation). We thus decomposed the description into a brief description and – based on the two levels of practice evaluation – extracted the actions of the actors. As seen, the basic path actually consists of two independent basic paths. The first path, i.e. the evaluation of the effectiveness, is conducted by the practice author / project manager after defining a practice and prior to its enactment. The second basic path, i.e. the evaluation of its efficiency from the viewpoint of the practitioner is conducted after the execution of the practice. We therefore consider that these two paths should actually be defined as two separate include use cases. However, it is not subject to this thesis to restructure the use cases content wise. Although untypically, we therefore analyse two basic paths in the context of this use case.

5.5.2 Requirements

The goal of the use case is to evaluate practices and methods. Therefore, the use case defines two levels of evaluation. The first level of evaluation (e.g. the first goal) targets the effectiveness of a practice from the viewpoint of the practice author or project manager. The second level of evaluation (e.g. the second goal) targets the efficiency of a practice from the viewpoint of the practitioner who enacts the practice. Evaluating the effectiveness aims to reason in how far the right things are being done while evaluating the efficiency determines in how far the things are being done right. In order to determine the effectiveness and efficiency of a practice (or method), evaluation questions are



required. Typically, evaluation questions help structuring and guiding the evaluation process to assess the evaluation goals on a sound base. For each level of evaluation, the use case therefore names a set of exemplary evaluation questions.

In order to fulfil the basic paths of the use case, the language must either provide one or more explicit attributes which can be used to answer each question, or it must be possible to inspect (i.e. decompose) the practice in a way that offers valuable clues about answering the evaluation question.

The objective of the following analysis is thus to analyse in how far the specification offers the possibility to evaluate the effectiveness and efficiency of a practice with respect to the evaluation questions of the use case. For each goal, we analyse how to answer each of its evaluation questions and summarize in how far the specification fulfils the goal. As the use case describes the set of provided evaluation questions as exemplary, we analyse for each goal whether the specification allows answering even more evaluation questions

5.5.3 Basic Path 1: Evaluate effectiveness

Step 1: Determine whether the practice clearly defines the purpose of the practice

The purpose of a practice is captured in its mandatory attribute objective. At this, the specification clearly advises to define the objective in the form of an explicit and concise phrase. In order to determine whether the practice clearly defines its purpose, the practice author thus looks up the attribute objective of the practice and checks whether it is clearly stated.

Step 2: Determine whether the practice has a beginning and an end

In order to determine the beginning and the end of a practice, we distinguish between the following views:

From an activity view, the beginning and the end of a practice can be characterized by the things which must be done first, and the things which must be done last. In the context of a practice, this view relates to the initial and final activities of the practice.

From a delivery-based view, the beginning of a practice can be characterized as the state where all things to be produced are in their initial state (and maybe even don’t exist yet at all) while the end of a practice can be characterized as the state where all things to be produced are accomplished. In the context of a practice, this view relates to the work products which must be produced (in a certain level of detail) during the execution of the practice.



From a process view, the beginning of a practice can be characterized as the state when no progress has been made, while the end of the practice can be characterized as the state when everything has been progressed. In the context of a practice, this view relates to the alpha states which must be progressed during the execution of the practice.

Taking all three views together, the beginning of a practice can be characterized as the activities which are conducted first to progress the initial alpha states, and – if defined - to produce the first work products (in a certain level of detail). The end of a practice can be characterized by the activities which result in an achievement of all final alpha states and the achievement of all work products (in the required level of detail) as depicted in Figure 15.

Figure 15 Beginning and end of a practice

In addition to these views, the specification allows scoping the beginning and the end of a practice in terms of the things which must be in place to begin a practice, and the things which must be in place when a practice is finished. The entry attribute of a practice allows defining the expected characteristics of elements required as inputs before starting a practice. The results attribute of a practice allows defining the expected characteristics of elements required as outputs after the execution of the practice. The format of both entries and results is not specified in more detail, i.e. they may relate, for example, to specific characteristics of alphas or work products, or legal regulations which have to be in place.

In order to determine the beginning and the end of a practice, the practice author thus looks up the activities which progress the initial states of the alphas and/or which produce the first required work products. He determines these activities by looking up their completion criteria. In order to check whether any constraints apply on the beginning and the end of the practice, he checks the entry and result of the practice.



Step 3: Determine in what circumstances to apply the practice

We consider the question in what circumstances to apply the practice as very vague and hard to interpret. For example, one could interpret the term circumstances as a specific application context, for example a certain project context or domain. With respect to this interpretation, we refer to the analysis of the use case “Compare practices / methods”. As a result of this analysis, we state that evaluating this question is out of scope of the specification: Whether a practice is suited for a specific application context depends heavily on real-world experience of applying a practice in a certain context. As a method description is in itself closed, i.e. independent from a specific context, it is not possible to determine this by solely inspecting a method. However, as the intention of this step is not clear to us, we consider this step as not analysable.

Step 4: Determine what problem or opportunity or endeavour the practice helps with

Ideally, the problem or opportunity or endeavour a practice helps with is captured within the purpose of the practice. However, if this is not the case, one has the possibility to inspect the practice in order to determine the problem or opportunity or endeavour based on the elements the practice is composed of.

The structure of the Essence kernel allows determining the problem or opportunity or endeavour a practice deals with from two views: The first view relates to the three areas of concern. As each kernel element is related to one area of concern, the main area of concern a practice deals could be determined based on it the main area(s) of concern of its kernel elements. Practices supporting managerial objectives (e.g., Scrum) would typically focus on kernel elements related to the endeavour area of concern while practices supporting the actual construction of the system (e.g., XP; FDD) would typically focus on kernel elements related to the solution area of concern. Practices dealing with the customer interface would typically focus on kernel elements related to the customer area of concern.

In order to determine the main area of concern, a practice can be decomposed the alphas and work products, activity spaces and activities, and competencies related to the three areas of concern (Figure 16).



Figure 16 Decomposition of a practice into the three areas of concern

As alphas represent the essential elements of any endeavour, it might also be sufficient to decompose a practice into its alphas and to investigate which areas of concern they relate to. Though, as also seen in the following example, the focus of a practice gets definitively clearer when decomposing it into the elements outlined above.

Based on the practice Scrum which is modelled in the appendix of the specification, Figure 17 exemplifies the decomposition of this practice and the relationship of its elements to the areas of concern of the kernel. As a result, it gets visible that the practice doesn’t focus on the customer area of concern. While the practice uses alphas from both solution and endeavour area of concern, its activities are settled only within the endeavour area of concern. Hence, Scrum can be characterized as a practice which supports with endeavour area of concern, i.e. managerial aspects of a software engineering endeavour, with focus on the development of the solution.



Figure 17 Decomposition of a practice - Scrum example

Though, in some cases it is necessary to apply a more granular view. For example, when only a part of the states of an alpha is progressed indicating that the focus of the alpha is more limited compared to its complete lifecycle. Therefore, a second view can be applied which is related to the alphas and their states. As the main objective of the specification is to support software engineering endeavours, we propose a classification according to the phases or activities within the software engineering lifecycle. For example, depending on the alpha states covered in a practice, one could to distinguish between the phases inception, construction, and operation (Figure 18).



Figure 18 Decomposition of a practice into Software Engineering phases

Figure 19 depicts a similar example which includes all alphas from the kernel. The example can be found in the appendix of the specification. The practice focusses on the operation of a software system. As shown, only specific alpha states are progressed. The alphas from the customer and solution area of concern are in a very advanced state: The opportunity is addressed, stakeholders are in agreement, the requirements are fulfilled and the system is operation. At the same time, the operation picks up its work.

Figure 19 Application development lifecycle example - Support phase



Taking both views together would result in an even more detailed decomposition and hence, allow a very granular view on the problem, opportunity, or endeavour a practice deals with. Therefore, one would decompose a practice into its main elements and assess both the areas of concern the elements relate to as well as the alpha states indicating the covered software engineering lifecycle (Figure 20).

Figure 20 Decomposition of a practice - Combined view

Hence, in order to determine the problem, opportunity or endeavour a practice deals with, the practice author decomposes the practice into alphas and work products, activity spaces and activities, and competencies. If he considers that further decomposition is required, he inspects the alphas states. As a results, he concludes which areas of concern and which software engineering lifecycle activities are covered by the practice.

Step 5: Determine whether the practice contains all the necessary things that need to be done to achieve the goal

In the context of the specification, the necessary things that need to be done are captured in terms of activities and activity spaces. While activities represent the concrete things to be done, activity spaces serve as containers for these activities from a high-level view. Each activity or activity space contributes to the progress of at least one alpha (in terms of achieving a certain state) or one work product (in terms of achieving a certain level of detail).

In order to determine whether the practice contains all required activities and activity spaces, the practice author checks whether the defined activities and activity spaces reflect the activities of the endeavour appropriately and completely. Furthermore, he double



checks whether the set of activities and activity spaces is complete with regard to the achievement of all alpha states and all levels of details of the work products.

Step 6: Determine whether the practice contains all necessary things that need to be produced

In the context of the specification, the things that need to be produced are defined in terms work products. Work products are used to concretely describe alphas. At this, several work products might be required to represent all relevant aspects of an alpha.

In order to determine whether the practice contains all necessary things that need to be produced, the practice author checks whether all things needed to be produced are reflected in terms of work products. For each alpha, he furthermore double checks whether the set of associated work products represents the alpha from all its relevant and required aspects.

Step 7: Determine what kinds of skills are required to do the work

In the context of the specification, skills are represented in terms of competencies and competency levels. For each activity, a competency level may be assigned representing a level of certain skills required to do the work.

In order to determine the required skills, the practice author checks the defined competency levels respectively the related competency. For each activity, he evaluates if the set of competency levels meets the demands of the activity.

Step 8: Ensure the users know when something has been achieved

As the evaluation question doesn’t further specify what it means by something, we distinguish between achieving something to be done (i.e. an activity), achieving something to be produced (i.e. a work product in a certain level of detail), achieving a milestone (i.e. an alpha state).

With regard to the achievement of activities, the specification defines completion criteria which are used to determine whether an activity or activity space has been successfully executed. For each activity and activity space at least one completion criterion must be defined. A completion criterion refers either to a specific alpha state or a level of detail of a work product.

Regarding the achievement of level of detail of work products as well as the achievement of alpha states, the specification allows defining checkpoints. Checkpoints are used to determine whether a certain level of detail of a work product, or a certain state of an alpha is accomplished. Several checkpoints may be defined for each alpha state and each level of detail of a work product. For example, the kernel defines seven checkpoints for the state



Usable of the alpha Software System including “The system is fully documented”, “The functionality of the system has been tested” and “The added value provided by the system is clear”. During the execution of an endeavour, checkpoints are evaluated as true or false. An alpha has achieved a certain state if all its checkpoints are evaluated as true. A work product has reached a certain state if one of its checkpoints is evaluated as true. Though, as the definition of checkpoints is optional both for alpha states and levels of detail of work products, answering this aspect of the evaluation question requires that checkpoints are defined. Given that work products may be defined without levels of details, the application of checkpoints additionally requires that work products are defined including levels of detail.

Figure 21 depicts the evaluation of completion criteria and checkpoints during the execution of the endeavour (i.e. after an activity has been conducted) and the resulting knowledge about the achievement of activities, alpha states and work product levels of detail. For the reason of simplicity, the figure focusses only on activities and does not depict activity spaces. However, the same counts for activity spaces.

Figure 21 Evaluation of completion criteria and checkpoints

Hence, in order to ensure the users know when an activity or activity space are achieved (i.e. indeed accomplished), the practice author thus checks for each activity and activity space whether at least one completion criterion (i.e. a certain alpha state or a certain level of detail of a work product) is defined. During the execution of the endeavour, the users are then able to know whether an activity or activity space is accomplished. Furthermore, in order to ensure the users know when a work product has achieved certain level of detail, the practice author checks for all work products whether checkpoints are defined. Similarly, in order to ensure the users know when an alpha has achieved certain state, the practice author checks for all alpha states whether checkpoints are defined. During the execution of the endeavour, the users are then able to evaluate the checkpoints and to determine whether an alpha state or work product level of detail has been achieved.



Step 9: Determine whether the things that needed to be produced meet the criteria set down by the initial statement of the problem or opportunity or endeavour

In the context of the specification, the things needed to be produced are represented in terms of work products. The initial statement of the problem or opportunity or endeavour can be characterized as the challenge to progress the endeavour in order to achieve a certain objective. In the following, we thus regard the initial statement of the problem or opportunity or endeavour in terms of the objective of the practice. In order to answer whether the work products meet the criteria set down by the objective of the practice, the specification must thus allow defining criteria for work products which are related to the objective of the practice.

The specification defines the practice attribute results which represents the expected characteristics of elements after executing a practice, i.e. when the objective of the practice is met. As the specification doesn’t constrain the contents of this attribute, it may be used to define criteria related to the resulting work products. In order to be able to answer this evaluation question, the practice author must ensure that the results of a practice are defined including criteria related to the work products resulting from the practice.

Step 10: Determine whether the things that needed to be produced add value

Typically, the concept of value is difficult to grasp as the value depends on the context of the endeavour (e.g., its objective; its stakeholders; the quality of the results) and furthermore on the question in how far the value is measurable. However, the language supports the practice author in approaching the value of the things being produced (i.e. the work products) as it makes the definition and development of work products explicit. It also defines that work products must be bounded to an alpha and thus, represent a concrete aspect of progressing the endeavour. The value of work products which are not bounded to an alpha is thus questionable.

In order to determine whether the work products produced add value, the practice author assesses whether each work product is bound to an alpha, and whether it concretely represents a valuable aspect of the alpha. While the latter is of subjective matter, the required association between a work product and an alpha can be objectively assessed.

Further evaluation questions

During our analysis we found that the specification allows answering even more evaluation questions, for example:

Determine the progress of an endeavour: While a practice is executed, the alphas progress from their initial states to their final states. A state represents an important milestone in the life of an alpha. Hence, a milestone with respect to the overall



endeavour could be defined as the set of states of certain alphas. Therefore, the language allows defining patterns which can be used to define milestones aligning a set of alphas and synchronizing the progress of alphas.

Determine whether the things being done add value: The language ensures that the accomplishment of each activity and activity space is related to at least one completion criterion referring to either an alpha or work product. However, a progress of an alpha or an achievement of a certain level of detail of a work product is not necessarily based on the achievement of a certain activity or activity space. Hence, based on the completion criteria of each activity and activity space, the specification allows to evaluate whether the things being done add value. Though, the actual evaluation is subject to the assessor.

Determine and evaluate the consistency of a practice: Typically, a consistent practice is more effective than an inconsistent practice as inconsistencies might hinder the execution of a practice. In order to prevent inconsistencies, the language requires that each practice is defined including consistency rules. Consistency rules express specific constraints to ensure the consistency of a practice. Therefore, the language provides the practice attribute consistencyRules. Consistency rules are specified using OCL.

With special regard to the effectiveness of a method, the specification allows, for example, to evaluate following question:

Determine and evaluate the coherency, consistency and completeness of the set of practices which articulate a method: The effectiveness of a method is related to the set of practices which articulate the method. At this, the set of practices should be coherent, consistent, and complete. According to the semantics of the language construct Method, the set of practices is coherent if the objective of each practice contributes to the purpose of the method. It is consistent if each of its entries and results are interrelated and useful for the method. It is complete, if the achievement of the objectives of all practices in the method fulfils entirely the purpose of the method.

5.5.4 Basic Path 2: Evaluate efficiency

Step 1: Determine whether the practitioners have achieved the goals laid out in the practice

The kernel provides the Work alpha which addresses everything that the team does to meet the goals of the endeavour. The alpha progresses the states initiated, prepared, started, under control, concluded and closed. Tasks related to these states include for example prioritizing the work, estimating cost and effort, continuously reassessing and minimizing risks, monitoring the progress of the work, and applying selected measure to



show its progress and velocity. The state under control for example expresses the fact that work is going well, risks are under control, and productivity is satisfactory. The state closed expresses that the work results have been achieved.

By applying the Work alpha within the practice, the practitioners can determine in how far they have achieved their goal. In order to determine whether they have achieved the goal, they reason in how far the Work alpha has achieved the state concluded.

Step 2: Determine how easy it was to follow

The kernel provides the Way of Working alpha which supports the practitioners in continuously reflecting about their way of working, independent from the team organization and the kind of work it conducts. The alpha progresses the states principles established, foundation established, in use, in place, working well, retired. Tasks related to these states include for example defining and agreeing on practices and tools, inspecting the way of working, handling feedback on the way of working, and continually improving the way of working. At this, the state working well expresses the situation when the team members progress as planned by applying the way of working, and by constantly adapting it to suit their working environment. The way of working is considered as key enabler for a team to work together effectively. Hence, the Way of Working alpha can be regarded as central to this use case goal as it actually represents the practice with focus on its effectiveness and efficiency.

The application of the alpha Way of working thus helps the practitioners to determine how easy it was (or is) to follow the practice. Therefore, they evaluate - for example - either retrospectively, or after achieving each state of the alpha, how easy it was to achieve. The team could also apply a measurement regarding the time it took to achieve the state working well. Furthermore, the alpha defines the state retired which advises to conduct and share lessons learned. Hence, the practitioners are not only supported in determining the efficiency of the practice, but also in improving the practice.

Step 3: Apply any metrics about the method or practice that can be gathered to measure its effectiveness

The specification defines two concepts to measure the effectiveness of a method or practice. The first concept represents one of the most fundamental concepts of the specification and is related to the measurement of the health and progress of the alphas which form a practice. As the states of the alphas are progressed during the execution of the endeavour, the progress and the health of the endeavour (i.e. its efficiency and effectiveness) can be defined as how quickly a certain state (i.e. a goal) is reached.

When measuring the effectiveness of a method or practice, the kernel alphas defined in the endeavour area of concern (e.g. Team, Work, Way of Working) can be considered of special importance. They focus on the way the endeavour is executed and support the



practitioners in effectively planning, leading, monitoring and conducting their work efficiently and effectively. Hence, these alphas might serve as a base to derive measures related to the effectiveness of a practice from the practitioners’ point of view. For example, the kernel provides the Team alpha which assists the team in reflecting how well the team works together and in keeping track of its performance. It progresses the states seeded, formed, collaborating, performing and adjourned. The team has achieved a crucial level of efficiency and productivity when it achieves the state performing. Hence, a practice can be considered as efficient and effective if the team achieves and keeps the state performing well and quickly.

The second approach relates to instances of the language construct Practice which may be defined including the attribute measures representing a list of selected performance measures. These measures are intended to be used to evaluate the performance of the practice. The specification doesn’t prescribe the content and format of the measures. The measures can be related, for example, to time, cost or velocity. One could also use dedicated productivity metrics such as Story Points or Function Points to determine productivity and thus, to reason in how far the practice supports a productive way of working.

Though, with regard both concepts, the performance of a practice or method might be subject to various reasons which don’t necessarily relate to the design of the practice or method. For example, simple requirements, low risks or highly skilled team members might contribute to a better performance. We thus recommend to carefully observe and relate the context of the practice or method to its progress when reasoning about its effectiveness.

5.5.5 Discussion

Within our analysis, we investigated all evaluation questions provided by the use case to evaluate the effectiveness of a practice. As a result, we state that the specification allows answering all questions, i.e. it allows the practice / method author and the project manager to evaluate the effectiveness and the efficiency of a given method or practice. Especially with regard to the evaluation of the effectiveness of a practice, we showed that the specification not only allows to evaluate the given questions but also offers the possibility to evaluate even more aspects. Though, in order to answer all questions, the practice author must ensure that all required definitions are provided within the practice.

5.6 Use Case “Compare method”

5.6.1 Definition

Name Compare Methods

Actors Methodologist



Assessor/Appraiser

Short description The Compare Methods service provides a ranking of methods within the context of specified domains. The resulting ranking is dependent on key characteristics/factors relevant to the specified domains (e.g. Security, Safety, Reliability, Usability, Size, Personnel skills, Geographic distribution…). When comparing any set of methods there will be similarities and differences, a union and possible intersection. The use-case Compare Methods should help us understand these relationships between methods and how their usage interrelates.

Basic path 1 Identify and define the set of applicable domains

2 Identify and define the key characteristics and factors relevant to each domain

3 Decompose methods into kernel language elements, patterns, practices, definitions, universals, and theories. Understand each method as a system of these components.

4 Compare method composition in the context of the domains and the relevant characteristics and factors of those domains.

5 Draw conclusions and rankings based on a contextual comparison of methods, their composition, and usage within the domains

Alternative paths 1 Resourcing: Reference essential areas of skill against current available resources and determine any recruitment needs.

Pre-Condition -

Post-Condition -

Qualities -

Table 21 Use case “Compare method”

The use case is described including its opportunity, assumptions and test scenarios. As this information serves primarily the development of the use case, we don’t explicitly include it in our use case template. As short description, we adapted the brief description of the use case.

5.6.2 Requirements

The use case Compare methods investigates into the question which methods work well in which context. The main objective of this use case is to compare methods with respect to the key characteristics of a given domain. As a result, the use case aims to provide a ranking of methods in the context of that domain in order to understand differences and commonalities between methods and how these methods interrelate. Therefore, the use case defines a basic path in which the actor characterizes a set of application domains and



analyses a set of given methods. The actor compares the methods in the context of the different domains and draws conclusions on the applicability of each method within each of the domains. The alternative path pays special attention to required skills with regard to the sourcing of resources.

The use case names the concept of contextual domains as a key concept to compare methods and practices in the context of different domains. The contextualization of domains requires a set of characteristics to describe the domains (e.g., security, safety, reliability, usability, size, personnel skills, and geographic distribution). However, it is not subject to the specification to define such characteristics – neither for domains nor for methods or practices. Though, the specification should support the definition and evaluation of characteristics which allow to characterize and to compare methods and practices with regard to their applicability in different domains.

In order to support the development of this use case, the original use case document proposes to investigate into the work of Ambler [Ambler 2009] and Boehm/Turner [Boehm and Turner 2003]. Based on a literature review on the contextualization of domains in order to assess and compare methods, we consider the work of Kruchten [Kruchten 2013] of special importance regarding the objective of this use case. While Boehm/Turner and Ambler define characteristics to assess a project context in order to adopt, tailor or scale an approach, Kruchten takes this idea a step further towards the objective of this use case and sketches the idea of comparing practices with regard to the characteristics of a given context. In the following, we first investigate into the work of Boehm/Turner, Scott Ambler and Kruchten. We then analyse the specification to answer in how far it fulfils the basic and the alternative path.

5.6.3 Related Work

Balancing agility and discipline (Boehm and Turner, 2008)

Boehm and Turner [Boehm and Turner 2003] deal with the question how to balance agile and plan-riven approaches in order to benefit from both worlds. Depending on the characteristics of a certain project, in some cases a purely agile approach may be appropriate while in other cases a purely plan-driven approach is the better choice. However, as both approaches have their benefits and risks it might be even recommendable to incorporate practices both from agile and plan-driven methods to get the most out of both worlds. Therefore, the authors propose to assess (1) the project context with respect to a set of characteristics and (2) the risks related to the application of an agile and a plan-driven approach within this context. In order to characterize the project context, the authors derive five critical factors considered as dimensions affecting method selection with regard to agile and plan-driven methods: size, criticality, dynamism, personnel, and culture. These five factors are considered as the home ground of a project to assess whether it is better suited for an agile or a plan-driven approach. Based on the characterization of the home ground, the authors propose a risk-based assessment to



evaluate the home ground with regard to risks related to the application of an agile and plan-driven method. As a result, one can determine whether an agile or a plan-driven approach is better suited, or even whether an incorporation of both approaches is considered the best solution. Based on the risk assessment, risk mitigation strategies can then be derived. For example, if the home ground is both characterized as agile and plan-driven, and the risk assessment results in high risks both for applying an agile and a plan-driven strategy, one could, for example, apply an overall plan-driven framework while selectively applying agile practices.

Agility@Scale (Ambler, 2009)

Ambler focusses on the question how to scale agile strategies to meet the challenges of rising complexity. Therefore, he proposes the Agile Scaling Model (ASM) which defines a contextual framework supporting the adoption and tailoring of agile practices and methods. The ASM distinguishes between three scaling categories which build upon each other. The first category focusses on core agile development based on core agile methods (e.g., Scrum, XP). Methods and practices related to this category support the actual construction of the system. The second category named disciplined agile delivery focusses on agile methods which cover the full lifecycle of software delivery. Compared to core agile development, disciplined agile delivery thus considers the whole complexity of software delivery including pre-construction activities, deployment, operation and support activities, and even activities related to the retirement of the system. It moves from partial methods to a full-fledged lifecycle model. In order to establish disciplined agile delivery, the combination and tailoring of practices is proposed – which is quite similar to the Essence approach. The third category - agility at scale – deals with the adaptation of disciplined agile delivery due to challenges resulting from higher complexity. Therefore, the degree of complexity is assessed based on eight scaling factors: team size, geographical distribution, regulatory compliance, domain complexity, organizational distribution, technical complexity, organizational complexity, and enterprise discipline. The more factors are determined to be more complex, the more it is required to adapt the disciplined agile delivery process. In order to tailor a strategy and thus, scale it to higher complexity, either tailoring of mainstream agile practices or the adoption of new practices is proposed. Compared to the approach of Boehm and Turner, Amber assumes that an agile method covering the whole development lifecycle is already in place. The characterization of the project context thus serves to determine how to address factors required to scale a method rather than to decide whether to principally apply an agile or plan-driven method.

Contextualizing agile software development (Kruchten, 2013)

Kruchten addresses the question how to establish a contextual framework for situating agile practices with special regard to the adoption of agile practices when the project scope is outside the agile sweet spot. The agile sweet spot is the context in which agile practices have been defined and where they are considered to work the best. In order to determine how well an agile practice works in a given context, he proposes to relate the practice to a



set of factors which characterize the organization and the project-setting (e.g., size, criticality, team distribution, rate of change, age of system). The objective of assessing these factors is to carefully select the agile practices which are address the context appropriately, rather than applying one agile method in its total. As a future work, he proposes to derive a kind of recommendation system giving advice on which practices are most appropriate for which context characteristics. Figure 22 shows a sketch of such a system. However, as Kruchten mentions, the main obstacle in deriving this kind of recommendation is to populate the system with reliable data, i.e. data which is objectively derived and supported by evidence (e.g., gathered from experience reports or empirical studies).

Figure 22 Guidance for process configuration [Kruchten 2013]

5.6.4 Basic Path

Step 1: Identify and define the set of applicable domains

The identification and definition of the set of applicable domains is subject to the methodologist and not relevant to the specification.

Step 2: Identify and define the key characteristics relevant to each domain

The identification and definition of factors characterizing a domain is not in the scope of the specification. However, based on the related work named in the original use case document, the methodologist could use an existing set of factors to characterize the domains (Table 22).



Boehm and Turner, 2008 Ambler, 2009 Kruchten, 2013

Size Criticality Dynamism Personnel Culture

Team size Geographical

distribution Regulatory compliance Domain complexity Organizational

distribution Technical complexity Organizational

complexity Enterprise discipline

Organizational level Business domain Number of instances Maturity of organization Level of innovation Culture Project level Size Stable architecture Business model Team distribution Rate of change Age of system Criticality Governance

Table 22 Domain characteristics

Step 3: Decompose methods

Within this step, the methodologist decomposes a method into its kernel language elements, patterns, practices, definitions, universals, and theories. At this, the question arises what use case means by decomposing a method into its universals and theories. We therefore assume (1) that the main objective of this step is the structural decomposition of a method and (2) that the use case has been written from a high level view when the components of a method have not yet been defined. Based on the specified structure of a method, the methodologist is now able to decompose a method into its practice(s) and its base kernel. In turn, he can decompose the kernel into its elements, i.e. alphas, activity spaces and competencies, and each of its practices into its work products, activities, patterns and resources. Furthermore, he can decompose the practice into the areas of concerns, and compare which areas the practice targets. As a result, one could compare, for example, whether a method is more related to managerial challenges, or the challenge of the actual construction of the system. An example of assessing a practice (i.e. Scrum) this way and gaining valuable insights about the practice is provided within the analysis of the Use Case “Evaluate method/Practice”. Although it is possible to further decompose these components (e.g., to decompose an alpha into its states respectively its checkpoints), we consider a further decomposition as not appropriate in the context of this use case: While the comparison of method in the context of different domains is located on a rather high level, the total decomposition of a method represents a view which is too granular suit as comparison criteria.



Step 4: Compare method composition in the context of the domains

Although the specification allows the structural decomposition of methods and thus, theoretically the comparison of these components in the context of different domains, their actual comparison is out of scope of the specification for one main reason: Comparing the applicability of a method or its practices in the context of different domains must be based on real experience (e.g., empirical data derived from industrial case studies or experience reports). Kruchten [Kruchten 2013] explicitly outlines this challenge while Boehm and Turner [Boehm and Turner 2008] as well as Ambler [Ambler 2009] also refer to their experience and available empirical data when relating a certain method or practice to a certain context. Setting up a ranking of methods within the context of certain domain must thus be successively derived from industrial experience. Therefore, it is also required to (1) systematically evaluate a set of given context characteristics when applying a method, and (2) to rate the applicability of the method and its components with respect to these characteristics after having applied the method.

In order to define the set of context characteristics, one idea could be to describe the context within the description of a method (or practice) or to define a pattern which relates certain language elements to each other in order to characterize the context. However, when describing the context within the description of a method (or practice) there would be no systematic way to ensure that every practice uses the same context characteristics (if at all). When defining a pattern, one would be limited to the available language constructs which make up the method (or practice). For example, how to get hold of the team size, the criticality or the rate of change within the method description? At this, it must be considered that the specification primarily serves to define methods and practices rather than their application context.

We thus conclude that both comparing methods in the context of domains, as well as deriving a ranking is not feasible solely by the specification and requires additional efforts both from research and industry. We thus consider this step as not fulfilled by the specification.

Step 5: Draw conclusions and rankings based on a contextual comparison of methods

Given that step 4 is not fulfilled by the specification, we consider this step as not reachable. The same argumentation applies as provided in step 4.

5.6.5 Alternative Paths

A1: Resourcing

As the basic path is partially fulfilled, we consider the alternative path still as relevant. With respect to the objective of this path, we refer to the use case “Evaluate method/practice”



where we explicitly analyse how the specification allows the determination of required skills. As a result, we consider the alternative path as fulfilled.

5.6.6 Discussion

The analysis of the basic path as well as the results of the study of the related work shows that the comparison of methods is principally possible. Though, in order to establish a relation between both practices and methods and their applicability in the context of certain domains, it requires systematic recording of practical experience. As a result, we state that the use case is partly fulfilled: The specification allows and supports the structural decomposition and comparison of methods which is required to assess them. Though, the actual comparison of methods with respect to different domains is not subject to the specification.

5.7 Use Case “Plan based on method”

5.7.1 Definition

Name Plan based On method

Actors Practice/Method Developer

Short description Work must be driven based on goals that need to be achieved. The kernel language should support this planning approach i.e. an executable method. A mechanism for this may be to introduce 'states' on the things that are of concern - i.e. Alphas, and generate the work based in the initial and target state.

Basic path 1 Create instance of an alpha of interest to represent aspect of endeavour The use case starts when the Enactment actor request to

establish an Alpha Instance

The system provides a list of Alphas available from the Method instance and requires the actor select one

The actor selects an Alpha and provides a suitable name

The system registers the Alpha Instance and reports its available States

2 Establish current as-is position state The actor sets the Alpha Instance Current State

3 Set target state The actor sets the Alpha Instance Target State

4 Request new work bundle set



The actor requests a Work Bundle Set from the Alpha Instance States

5 Generate work bundle set The system generates a Work Bundle Set for the given

Alpha Instance and its Current and Target States and registers and association with the Alpha Instance

Alternative path 1 Plan from previously created Alpha Instance Create new Work Bundle Set from a previously established

Alpha Instance

2 Browsing Work Bundle Set View the contents of a Work Bundle Set and its associated

attributes and links

3 Editing Work Bundle Set Edit a Work Bundle Set to modify and update its contents

Pre-Condition Instance of method

Post-Condition n/a

Qualities n/a

Table 23 Use case “Plan based on method”

5.7.2 Requirements

The objective of the use case is to provide work guidance to the practitioner who enacts a method. Within the basic path of the use case, the actor establishes the current state of an alpha instance and sets the next target state. As a result, he is provided with a work bundle set. In order to fulfil this path, the specification must define how to establish run-time instances of methods and how to perform methods. The latter objective must include explicit work guidance, i.e. the specification must define a mechanism which instructs the practitioner on what to do next to achieve the goals of the endeavour. The alternative paths define additional requirements: The first alternative path allows the actor to get a work bundle based on a previously achieved state. The second and third alternative paths allow the actor to browse and edit the work bundle set.

In order to establish run-time instances and to enact methods, the specification defines dynamic semantics which complement the static description of methods. The dynamic semantics are specified in terms of operational semantics describing how the run-time model is populated, how the current state of the endeavour is determined, and how work guidance is generated. The operational semantics are based on the language metamodel (see 2.2.1): While the run-time instances are established at meta-level 0, the method definition is established at meta-level 1 using language constructs from meta-level 2. In order to realize the operational semantics based on the metamodelling technique, the specification uses certain naming conventions and abstract superclasses.



The naming conventions allow to unambiguously address the inhabitants of each meta-level during the execution of the endeavour. Therefore, the inhabitants of the meta-levels are referred to with prefixes and postfixes based on the names of the language constructs at meta-level 2. This mechanism works as follows: Assume a language construct defined at meta-level 2 with the name X. An instance of X represents a type on meta-level 1 and is prefixed with my_ resulting in my_X. In turn, instances of types defined at meta-level 1 represent occurrences on meta-level 0 and are postfixed with _instance resulting in my_X_instance. For example, instances of the language construct Alpha (which is defined at meta-level 2) represent types of Alpha at meta-level 1 and are referred to as my_Alpha. In turn, instances of my_Alpha represent occurences of my_Alpha on meta-level 0, and are referred to as my_Alpha_instance. The second mechanism used by the specification to realize the operational semantics

The concept of the abstract superclasses ensures that instances on meta-level 0 own certain runtime characteristics which allow to assess the runtime state so that the operational semantics can be executed. The set of superclasses is defined at meta-level 1. The naming of each abstract superclasses is related to its according language construct on meta-level 2. The set of superclasses encompasses my_Alpha, my_State, my_WorkProduct, and my_LevelofDetail. For example, the abstract superclass my_Alpha owns the attributes instanceName and currentState. While instanceName refers to the name of the occurrence, currentState points to the current state of the occurrence. Hence, during the execution of an endeavour, any occurrence of an Alpha can be identified by its instance name and its current state.

The functions required to define the operational semantics are formally specified using VDM-SL. When referring to these functions during the analysis of the use case paths, we name the signature of each function and describe how the function works. With regard to their complete formal specification, we refer to the specification.

With regard to the following analysis of the use case paths, we exemplify their execution in order to make their execution more tangible. Therefore, we use following scenario throughout the use case: Assume a project which aims to develop a software system. The project team consists of three distributed teams in Germany, France and India. The requirements have already been elaborated and describe a system which is acceptable to the stakeholders. The focus of the teams is thus on the implementation of the actual solution. Therefore, a method has been defined based on a practice using the Essence kernel. The practice uses the alphas Requirement and Software System. In order to ensure that the distributed teams work together well, the practice also uses the alphas Team and Work. In order to visualize and track the progress of the practice, the project team uses a digital whiteboard.



5.7.3 Basic Path

Step 1: Create instance of an alpha of interest to represent aspect of endeavour

In order to instantiate an alpha, an execution environment is required. The execution environment executes the operational semantics and holds the level 0 model (i.e. the actual occurrences) as well as a copy of the level 1 model (i.e. the defined method). The execution environment doesn’t necessarily have to be a tool (e.g., a software application), but it can also be represented as a cognitive activity supported, for example, by physical notes attached to a whiteboard. As the execution environment holds a copy of the level 1 model, it is able to provide a list of available alphas, i.e. the alphas of the defined method. The actor is thus able to select an alpha and create an instance of it.

Based on the abstract superclass my_Alpha, any alpha instance is endowed with the attribute instanceName defining the name of the occurrence. The actor is thus able to endow the alpha instance with a name.

On a conceptual level, the execution environment registers the new alpha instance in its level 0 model. The realization of the actual registration of the alpha within the execution environment is subject to the execution environment. For example, by using a whiteboard, one could attach a note to the whiteboard representing the alpha instance. Or, when using a software tool, the tool could implement some kind of factory pattern to generate and register the instances within the level 0 model. However, the implementation of such a tool is not subject to the specification.

The execution environment reports the states of the instantiated alpha by referring to the level 1 model, i.e. the defined method which includes all types of alphas respectively their states.

With respect to our scenario, Figure 23 depicts a simplified digital whiteboard representing the execution environment. The digital whiteboard consists of three areas: On the left side, the defined method (i.e. the level 1 model) is visualized. The middle area serves to hold the run-time instance of the method (i.e. the level 0 model). The right side serves to depict the resulting work guidance during runtime.



Figure 23 Use Case "Plan based on method" - Step 1

The defined method is visualized including an explicit area with the available alpha types (1). The actor selects the Team alpha (2) and names the instance Team_Germany (3). The alpha instance is then registered within the level 0 model, i.e. visualized on the middle area of the whiteboard (4). Based on the alpha states defined in the method, the available states are also shown in the middle area of the whiteboard (5).

Step 2: Establish current as-is position state

The overall state of the software engineering endeavour is determined based on the states of its alpha instances. For each alpha instance, its states are evaluated based on their checkpoints. A state is deemed as the most advanced state if all currently fulfilled checkpoints are met and if there is no outgoing transition to another state which has also all currently fulfilled checkpoints met.

In order to establish the current (i.e. the most advanced) state of an alpha instance, the specification explicitly doesn’t prescribe whether that state is set directly by the user, or whether it is handled as a derived property (i.e. automatically determined by a tool). In order to derive the most advanced state, the specification defines the function derive_current_state. The function is defined as follows:



derive_current_state: my_Alpha my_State

The function takes as argument an alpha instance and returns its most advanced state. First, the function determines the initial state in the state graph of the alpha instance. If the state has no successor state, then this state becomes the most advanced state. If the state has a successor state, the function looks up the checkpoints of the successor state and determines whether all its checkpoints are met. In case not all checkpoints are met, then the current state is stated to be the most advanced state. Otherwise, the same procedure is continued on the next state of the state graph until the final state is reached.

With regard to our scenario, the team manually evaluates the checkpoints of the states of the alpha instance Team_German. As a result, the state Formed is determined as the current state (Figure 24).


Step 3: Set target state

The target state is the state of the alpha instance which the team aims to reach next. Regarding the state graph of the alpha instance, the target state can be any state which succeeds the current state. Work guidance is then generated based on the things that must be done in order to reach that state. As a method typically consists of more than one alpha, several target states may be named. Work guidance is then generated for each alpha instance (i.e. with respect to each target state). The target state may be either set manually by the team or derived according to the function nextAlphaStatesToReach. The function is defined as follows:



nextAlphaStatesToReach: my_Alpha* my_State*

This function basically looks up all alpha instances in order to determine the direct successor for each current state of each alpha instance. As a result, it returns a set of states consisting of all direct successors of the current states of all alpha instances. At this, the team must be aware of alphas which are not instantiated at this point: Typically, run-time instances of alphas (and associated work products) are created as soon as they are considered within the endeavour, i.e. some alphas may exist right from the beginning and some may be created during the endeavour. Hence, there might be alphas which will be instantiated in one of the next steps and are not taken into account by this function. Using this function, it is only possible to generate work guidance for already instantiated alphas.

Regarding our scenario, the team decides to define the state Collaborating as the next target state of the alpha instance Team_Germany (Figure 25).


Step 4: Request new work bundle set

We consider the process step of requesting a new work bundle set as subject to tool or process implementation. For example, using a software tool, the team could press a certain button to request the work bundle. Within our scenario, the team could, for example, name and address a responsible person which takes care of the next work bundle set.



Step 5: Generate work bundle set

The essential idea of generating work bundle sets is to check all activities of the method and determine those activities which have the defined target state(s) among their completion criteria. This can be done either manually by inspection of all activities or, if tool support is available, automatically using the guidance function defined by the specification. Formally, the guidance function is defined as follows:

guidance: (my_Alpha, State)* (my_Alpha, Activity*)*

The guidance function uses as arguments a set of pairs consisting of an alpha instance and its target state. As a result, a set of activities is returned consisting of the activities related to each alpha instance. These activities need to be conducted to bring all alpha instances from their current state to the target state. In order to define this functionality, the specification uses four more functions: statesAfter, fullPath, to_do, and completionStates. We briefly outline the mechanism behind these functions.

The guidance function determines for each state of the alpha instance the required activities using the to_do function. The to_do function is defined as follows:

to_do: (my_Alpha, State)* (my_Alpha, Activity*)

As arguments, it takes the alpha instance and the target state resulting in a pair consisting of the alpha instance and a set of activities. For each activity defined in the practice, it checks whether its completion criterion is related to an alpha state which is within the sequence of states between the current state and (including) the target state of the alpha. The function therefore uses the functions completionStates and statesAfter.

The statesAfter function is defined as follows:

statesAfter: (State, State)* State*

It uses as arguments the current state and the target state. As a result, it returns the set of states which must be passed through to get from the current state to the target state. At this, it includes the target state but excludes the current state. In order to determine the set of states, the function uses the function fullPath which is defined as follows:

fullPath: (State, State)* State*

The function takes as arguments the current and the target state passed from the statesAfter function. It basically determines the set of states which must be passed through to get from the current state to the target state.

The function completionStates (used by the to_do function) determines the set of states forming the completion criteria of an activity. It is defined as follows:



completionStates: CompletionCriterion* State*

With respect to a given state, the function takes as arguments all completion criteria for a given activity and returns those states which are among the completion criteria and equal the respective state.

With respect to our scenario, the team manually checked all activities which have the state Collaborating among their completion criteria. As a result, the team compiled the list of resulting activities and put it on the right side of the whiteboard (Figure 26 Use Case "Plan based on method" - Step 4).



Alternative Path 1

An alpha state graph doesn’t necessarily represent a liner one-way progression, although this is considered as the usual way. Whenever a state is reassessed, it might be the case that not all its checkpoints are met. Reasons might be, for example, that the assessment of a previous state has not been made thoroughly enough, or because the context has simply changed. It is thus not only allowed, but even necessary to go back to a previous state. As already described within step 2 of the basic path, the team is free to set the current state of the alpha instance. This includes resetting the current state to a previously met state. We thus consider this path as fulfilled.



Alternative Path 2

Based on the definition of the language construct Activity, the actor is able to browse through the competency levels and actions associated with the activity instance. With regard to the actions of the activity instance, the actors looks up the actions related alpha instance and work product instances. We thus consider this path as fulfilled.

Alternative Path 3

The modification of activities during the execution of the endeavour is allowed as the level 1 model holds a local copy of the method description, i.e. changes made to the model (e.g., the modification of activities) don’t affect the method description on a global level but only in the context of the executed endeavour. The actor may thus edit the contents of an activity instance (i.e. work bundle set). We consider this path as fulfilled.

5.7.5 Discussion

We analysed the specification for each step of the basic path as well as the alternative paths and exemplified the actions of the actor using a scenario. Based on our results, we summarize that the specification fulfils the basic path as well as the alternative paths.

5.8 Use Case “Simulate method or practice”

5.8.1 Definition

Name Simulate Practice Or Method

Actors Methodologist

Short description Practices are constructed in such a way that their execution may be modelled and possibly simulated using a tool of some sort

Basic path Conduct simulation

Validate that the practice is coherent and it fits its purpose.

Understand its dynamic behaviour in an experimental environment to enable value judgments.


Pre-Condition Practice is modelled.

Practice is enactable.

Post-Condition n/a

Qualities n/a

Table 24 Use case “Simulate method or practice”



The use case only provides a brief description without a basic path. We therefore decomposed the brief description into a short description and the goals of the use case. As a pre-condition we add that a practice must be modelled and it must be executable in order to simulate it.

5.8.2 Requirements

The objective of the use case is the simulation of practices using a tool to validate them and to understand its dynamic behaviour in an experimental environment. Therefore, the use case states that practices must be constructed in a way that they can be simulated. With respect to the preconditions of the use case, we state that both preconditions are fulfilled: The analysis of the use case “Define Practice Definition” shows that practices can be modelled while the analysis of the use case “Plan based on method” describes the enactment of methods based on the operational semantics provided by the specification. In order to analyse the use case in more detail, we briefly outline how simulation fits in the context of the specification and what is needed to conduct a simulation.

The implementation of a new method (or practice) is typically accompanied with uncertainties regarding its performance. For example, whether the desired outcome will be achieved or how productivity is affected. While the evaluation of a method based on its static description (see Use Case Evaluate method or practice) might in some cases be sufficient to reason about the performance of a practice, it cannot assess its dynamic behaviour, i.e. its real behaviour in practice. Simulation is thus used to answer questions related to certain run-time conditions which are typically not assessable by the static analysis of a given subject. The wide variety of purposes for conducting simulations encompasses strategic management, planning, control and operational management, process improvement and technology adoption, understanding, and training and learning [Keller et. Al 1999]. Compared to the risks of just trying out a new method in practice, experimental simulation also offers a relatively inexpensive way to analyse the dynamic behaviour of the system before deploying the new method to the organization. Using simulation, an organization can gain valuable insights about existing or future situations. The organization can also use the simulation results as reference for expected simulation results and thus, avoid simulation errors when applying the method in real context. Simulation is typically conducted using a tool which executes a computerized simulation model. The simulation model represents the reality to be simulated with regard to a certain goal. Typically, it must be parameterized to fit a specific context (e.g., time, event triggers, resources). It must also be assessable in a way which answers the questions related to the goal of the simulation, i.e. it must be possible to attach certain metrics and to inspect the characteristics of the occurences and their relationships during run-time. In order to execute the simulation model, some kind of execution environment is required, i.e. a tool or a language [Van der Aalst and Voorhoeve 2010]. The execution environment allows executing the simulation model including the assessment of its run-time characteristics. Furthermore, it typically allows to control run-time aspects such as concurrency and decisions.



With regard to the definition of a simulation model, we state that the specification doesn’t provide any guidance on how to establish such a model. Although the specification defines how to establish and enact a method (see Use Case “Plan based on method”), additional run-time characteristics would be required to parameterize the model before and during runtime, similarly to the definition of the abstract superclasses at meta-level 0 which endow the occurences with attributes supporting the dynamic semantics.

Regarding tools or executable languages supporting the simulation of practices, we state that the implementation of such a tool or language is not subject to the specification. Experience regarding the simulation of Essence models is also not known.

5.8.3 Discussion

Basically, the specification supports the use case as practices and methods are generally executable and thus, theoretically, can be simulated. Though, when conducting a simulation, specific conditions must be considered (e.g., the simulation goal, the simulation environment, input and output parameters). As a result of the analysis, we state that the specification doesn’t touch the topic of simulation: It lacks of guidance on defining a simulation model as well as of the semantics defining the execution of the simulation model. However, as the preconditions required to simulate a practice are in place, we consider the goal of this use case as partly fulfilled.

5.9 Use Case “Teach kernel language”

5.9.1 Definition

Name Teach Kernel Language

Actors Teacher

Short description Ensure the concepts and the language used in the kernel language definition are simple to grasp.

Basic path 1 Introduce elements of the kernel language a) their definitions b) their relationships to other elements c) their attributes d) their semantics


Pre-Condition n/a

Post-Condition Students are able to author practices

Qualities n/a

Table 25 Use Case “Teach kernel language”



The description of the use case is quite short and contains content wise only a brief description and a value statement. In order to be able to analyse the use case, we decomposed the brief description into an even shorter description, a basic path, and a post-condition.

5.9.2 Requirements

The goal of the use case is to teach the kernel language to enable students the authoring of practices. In the basic path of the use case, the teacher introduces the kernel language to his students, i.e., the different types of language constructs defined on meta-level 2 of the language (e.g., Alpha, Activity space, Competency). As stated by the use case, these elements must be defined including their definitions, their relationships to other elements, their attributes and their semantics. The post-condition ensures that the students are able to author practices. Though, in order to express specific practices, the students need to apply the different types of different language constructs which is related to meta-level 1 of the language. We consider this task as very difficult to achieve when being only taught in the language constructs, but without knowing a concrete set of elements which can be applied to author practices (e.g., a kernel). In order to author practices, the students thus also need to be introduced into the kernel elements (e.g., alphas, activity spaces and competencies). As opposed to the introduction of the language, the use case doesn’t name any path or criteria for the introduction of the kernel elements. However, in order to introduce a new subject in an understandable way, it is beneficial if its concepts are clearly structured and described. Hence, in order to introduce the kernel elements, the kernel specification should be well-organized and the description of the elements should be clearly outlined.

With respect to the overall goal of the use case we note that the capability to teach something in a way that is understandable is typically quite subjective to the teacher and his students and thus, difficult to determine objectively. With regard to the post-condition of the use case, the question whether the students are able to author practices is even more difficult to determine theoretically (perhaps even impossible). However, experience in teaching the kernel in software engineering courses at university has already been recorded. In order to complement our theoretical considerations, we will thus address these real-world experiences and analyse in how far the teachers succeeded to teach the kernel to the students.

We first analyse in how far the specification allows the teacher to follow the basic path. Second, with regard to the post-condition, we analyse in how far the kernel and its elements are well-organized clearly described so that the students have (theoretically) the ability to author practices. Third, we analyse three experience reports of teaching the kernel in academia and summarize the experiences stated by the authors. Finally, we summarize our findings and reason in how far the goal of the use case is fulfilled



5.9.3 Basic Path

Introduce kernel language

The specification of all language elements follows a fixed structure. All language elements are clustered into six packages. For example, the package AlphaAndWorkProduct contains all basic elements to create domain models including work products related to the abstract domain elements while the package ActivitySpaceAndActivity contains elements to enrich a practice expressing activities. When introducing the language, the elements contained in the packages can be differentiated into the core of the language, its basic concepts and more advanced concepts. For example, the elements contained in the Foundation package include the abstract superclasses of the languages as well as auxiliary elements such as Library and Pattern and ExtensionElement. The packages AlphaAndWorkProduct, ActivitySpaceAndActivity, and Competency primarily contain the basic concepts to form practices. The packages UserDefinedTypes as well as View represent more advanced concepts not necessarily required when defining practice. When introducing the kernel language in order to teach the authoring of practices, the teacher might thus focus on a subset of language elements representing the required basic concepts rather than covering all language elements.

The specification of all language elements follows a fixed structure. First, the characteristics of the language construct in terms of its representation as an UML class are listed. Second, a brief description of the element is provided. This description can be considered as its definition as it concisely defines the element. Third, the attributes of the element are listed. Fourth, its associations to other elements are named. Fifth, its invariants (including additional operations) are defined in OCL representing constraints which must hold when applying the element. Finally, its semantics are described.

We state that the specification provides all characteristics required by the basic path of the use case. The teacher is thus able to introduce the language elements including their definitions, their relationships to other elements (i.e. associations), their attributes, and their semantics.

Introduce kernel elements

The organization of the kernel elements is based on a multi-dimensional view which allows looking at the kernel from (1) alphas, activity spaces and competencies across all areas of concern and (2) each area of concern including its alphas, activity spaces and competencies. The first view provides a brief description of each element and visualizes the relationship of each set of element types (i.e. alphas, activity spaces and competencies) across the three areas of concern. The second view goes into the details of each element: The specification of an alpha includes its definition, its relationship to other elements and a justification. Furthermore, its states and the way it is progressed are described. The latter is visualized including a brief description of the states. The description of the progression



of the alpha is supported with examples and recommendations. The specification of an activity space includes its objectives, its inputs and its completion criteria. The specification of a competency includes its objective, its skills, its competency levels and a justification.

The teacher might thus first provide an overview of all kernel alphas, activity spaces and competencies across all areas of concern. Based on each area of concern, he then might then introduce the alphas, activity spaces, and competencies in more detail. Based on the description provided for each element, he can explain its purpose, its characteristics and its application. The teacher can easily visualize the relationship of the elements based on the visuals provided in the specification. With special regard to the progression of the alphas, he can also give recommendations how to progress the alpha. As alphas represent the essential elements of the software engineering endeavour, we consider the latter as important aspect helping the students to better understand how to apply alphas in order to describe the progress of a software engineering endeavour.

We consider the specification of the kernel and its elements as well-organized and clearly described. Thus, we state that the teacher is able to introduce the kernel elements.

5.9.4 Experiences

In the following we outline three experiences of teaching the kernel concepts in academia. At this, we note that the extent and detailedness of the described experiences depends on the available experience reports. In order to capture all relevant aspects of each experience, we resign from shortening the experiences just to align the length of the descriptions.

Experiences at KTH Royal Institute of Sweden

Sjögren and Kajko-Mattson introduced and applied the kernel in first- and second-year software engineering courses at KTH Royal Institute of Sweden [Jacobson et al. 2012b]. Students of first-year software engineering courses were introduced into the kernel alphas. Based on the projects they had previously conducted, they were asked to match them to their project results and to inspect the progress and the health of their projects. The second-year students were asked to actively apply the kernel alphas when running their projects. At this, the students used the alphas to describe the development method they followed. During the execution of their projects, they evaluated the alpha states and their checklists. The authors outline that students were able to consider all essential aspects of software engineering based on the kernel. They were able to identify the good and the bad sides of their development method. The authors state a good relation between the effort required to teach the kernel and the resulting ability of students to grasp the total scope of software engineering endeavours, thus preparing them for industrial needs.



Experiences at Chinese Universities

In December 2012, Ng and Huang introduced the kernel in the context of a software engineering workshop involving students from the 7 of the top 10 universities in China [Ng and Huang 2013]. Students were asked to (1) identify challenges in software engineering, (2) to map these challenges to the kernel elements, (3) to describe and compare different software development lifecycles using alpha states, and (4) to describe the scope of the undergraduate curricula using alpha states. The authors outline following results: First, students saw the importance of having a consensus on a common terminology when referring to challenges in software engineering. Thus, they realized the benefits of the terminology provided by the kernel. Second, students were able to map the challenges from the previous exercise to the kernel alphas although some help was required. Third, students were able to represent different software development lifecycles using alpha states. Students thus saw that the kernel allows representing a wide range of software engineering challenges as well as different software development lifecycles. Fourth, students indicated that their curricula don’t cover all alpha states. Especially with regard to the alphas in the customer and endeavour area of concern, they saw a lack in the business-social aspects of their software engineering curricula. Overall, the authors state that the participants were greatly satisfied when leaving the workshop and saw value in addressing the gap between education and research by applying the kernel.

Experiences at Carnegie Mellon University

In spring and summer semester 2013, Péraire and Sedano conducted a field study on seven graduate master student teams during their practicum projects [Péraire and Sedano 2014]. The objective of the field study was to evaluate the effectiveness of the Essence framework (specifically the kernel alphas and their states) in following a state-based and goal-driven project steering approach. The first pilot projects were conducted on three geographically distributed teams in spring 2013. The authors incrementally introduced the kernel alphas in a number of 30 minutes sessions and provided each student with physical Essence cards. The second pilot projects in were conducted on four co-located teams in summer 2013. As opposed to the first pilot projects, a 90 minutes workshop was conducted to introduce the Essence framework (i.e. all kernel alphas) including exercises how to apply the monitoring and steering approach using one alpha at a time. Each team both of the first and the second pilot was supervised and supported by a faculty member. Throughout all practicum projects, the teams were asked to assess their current project state based on each of the alphas and to identify possible work items and actions to help transitioning from the current alpha states to the next target states. In order to analyse and interpret the results, the authors collected students’ feedback during weekly sessions, course reflection reports, and a final survey.

As follows the results of the field study from the students perspective: First, the students indicated that they see value in applying the monitoring and steering approach based on the kernel alphas and the states. Second, the students considered the assessment of the



various alphas and resulting discussions throughout their projects as beneficial for following reasons: The discussions enabled the students to step back from their daily tasks and examine the project holistically. The assessment of the alphas helped them to record the progress, the achievements and the remaining tasks of their projects. Furthermore, the students considered the framework as useful to seek structure and guidance to transition to a higher project state. In addition, the framework allowed the teams to decide on their own how to reach the target goals rather than prescribing the use of any existing method. Figure 27 illustrates the iterative process applied by the students.

Figure 27 Essence monitoring and steering approach [Péraire and Sedano 2014]

As a third result, the authors outline that the students saw the greatest value in applying the approach at the beginning of the project. This is due to the fact that the teams reached a stable state after a few weeks and kept working on it without progressing to a next alpha state, while progressing again at the end of the project. The authors outline that the monitoring and steering mechanism proved to be most effective during project initiation and at release level, while the value of the approach decreased during the iterations. With regard to further limitations, the students pointed out some disambiguities in the alpha checklist definitions.

From the educator’s perspective, the authors share following insights: When comparing the incremental versus workshop approach to introduce the kernel, the incremental approach brought immediate value to the students while producing minimum overhead. The workshop approach enabled the teams to look right upfront holistically at their projects, though it requires initial overhead. As a result, the authors primarily recommend the workshop approach. With respect to the order of introducing the alphas, the authors recommend to introduce the alphas in the customer area of concern before drilling down into solution and endeavour areas of concern. At this, the Stakeholder alpha should be introduced prior to the Opportunity alpha as the students found it easier to understand the Stakeholders alpha.



The authors summarize their findings as follows: From the students’ point of view, the kernel offers a holistic, lightweight, non-prescriptive and method-agnostic way to monitor progress and control projects. Furthermore, it provides students an effective structure for team reflection and risk management. From the teacher’s point of view, the kernel offers an effective mechanism to monitor and steer student software projects.

5.9.5 Discussion

Our analysis shows that the teacher is able to introduce the kernel language and elements to students. In addition, the experiences in teaching the kernel in academia show that students understand the kernel and are able to author practices. Furthermore, experience shows that the students are not only able to author practices, but also able to apply the kernel and execute their practices in student projects. We thus state that the specification entirely fulfils the goal the use case.

5.10 Use Case “Understand Software Engineering”

5.10.1 Definition

Name Understand Software Engineering

Actors Student

Short description The scope, depth and breadth of Software Engineering is not clearly understood, or at the very least agreed upon.

Whereas teams or organizations develop their own, often tacit, understanding of terms and concepts the lack of a common, generally accepted, grasp of roles, responsibilities and terms of reference, leads to conflicts, confusion and inefficiencies when interacting with external people and groups, be these new members of the team or external working partners.

Software Engineering practitioners sometimes exhibit a parochial view focused on their own role-based domains, often lacking an understanding of the goals and responsibilities of team members working in upstream and downstream dependent roles.

When approaching personal development or learning, students and professionals alike can find it difficult to place their own body of knowledge within a suitable framework to progress; often relying on inferred understanding when making training decisions.

Software Engineering training programs are not based on a common understanding of the discipline and as such leave



students requiring significant realignment and retraining as they enter industry following completion of academic studies.

Organizations continue to have difficulty estimating the cost of Software Engineering endeavours due to lack of clear understanding of the depth and breadth of the challenge.

Basic path Improve Understanding of Software Engineering

1 Referring to the definition of Software Engineering to establish the context.

2 Referring to the universal elements to understand the essence of software engineering.

3 Understanding the sequential goals that provide incremental value in the production of the Software System.

4 Understanding the extent of the kinds of activities involved in delivering the Software System, and how these contribute towards the goals.

5 Understanding the necessary skills required to perform the activities.

Alternative paths 1 Create Development Plan: Identify gaps in knowledge and develop a personal development plan or training strategy.

2 Work Better in My Team: Understand the other skills and areas of responsibilities of one’s peers assigned to the production of a Software System.

3 Validate Cost Estimation: Validate a cost estimation model for a proposed Software System endeavour; qualifying that it has considered all essential elements in the production of a Software System.

Pre-Condition n/a

Post-Condition n/a

Qualities n/a

Table 26 Use Case “Understand Software Engineering”

The use case does not provide a brief description although it describes the opportunity of the use case. We thus adapted the opportunity of the use case as its brief description.

5.10.2 Requirements

The use case addresses in its brief description principally following requirements:

1) The Essence specification should offer a common understanding of terms and concepts to improve the general understanding of the scope, depth and breadth of Software Engineering.

2) It should support the practitioners with clearly defined roles including their goals and responsibilities.



3) It should provide a common framework which helps to improve personal learning within the context of software engineering. At this, it should serve as a common base for training programs or curricula which aligns with industrial requirements and thus prepares students for entering industry appropriately.

4) Organizations should be able to understand an endeavour in its depth and breadth so that they can apply appropriate cost estimates.

The basic path of the use case addresses the first requirement. The other requirements are captured within the alternative paths. In order to fulfil the use case, the specification must fulfil the basic path and the requirements of the alternative paths.

As each path deals with a different aspect of the specification, we handle the requirements of each path separately. For each path, we analyse in how far the specification fulfils it. As a result, we reason in how far the use case is fulfilled.

5.10.3 Basic Path

Step 1: Refer to the Definition of Software Engineering

In order to refer to the definition of software Engineering to establish the context, the specification must provide a definition of software engineering. Although the specification includes a glossary of terms and definitions relevant to software engineering, a definition of software engineering is not provided. This can be explained by the fact that the intention of the specification is to define a kernel and a language for the creation, use and improvement of software engineering methods rather than to (re)define software engineering. As a logical consequence, the execution of the basic path stops at this point and the succeeding steps are not achievable. For example, how to refer to the universal elements representing the essence of software engineering, if no definition of software engineering is established? As a result, we state that the specification doesn’t fulfil the use case.

Nevertheless, we will conduct an analysis of the alternative paths as we might gain valuable insights about the specification - independent from the fact that the specification is not able to fulfil the basic path. The analysis of the following paths is thus decoupled from reasoning of the overall fulfilment of the use case. Hence, we don’t describe how the actor executes them.


A1: Create Development Plan

This alternative path aims to create a development plan, e.g. to identify gaps in knowledge and develop a personal development plan or training strategy. In order to fulfil the path, the specification must offer the possibility to identify gaps in knowledge, and the possibility to develop personal training plans to address these gaps.



Therefore, both the student and the instructor may benefit from the modular structure of the kernel: The kernel is structured in three areas of concern while each area of concern specifies its essential elements, activities and skills. All areas and elements are extensively described including objectives, justifications, and their role in the context of a software engineering endeavour. Thus, the kernel makes it possible to evaluate which areas are well understood and which require more training. For example, in order to identify possible gaps, one could ask for the essential elements (e.g. alphas), essential activities (e.g. activity spaces) and essential skills (e.g. competencies) required to execute a software engineering endeavour. Personal development plans or training strategies could then be developed to fill the knowledge gaps. For example, one could develop a training focusing on the alphas, activity spaces and competencies in the endeavour area of concern. The kernel even supports this approach as it explicitly defines the language construct Library which can serve to define a structured library of practices and thus, provide a learning roadmap for individuals of an organisation.

Experience of identifying gaps in knowledge based on the kernel has already been recorded by Ng and Huang who conducted a workshop in academic context to introduce the Essence kernel and language in 2012 reported experience [Ng and Huang 2013]. One of the exercises the participants faced was to describe the scope of their undergraduate curricula using alpha states. As a result, the participants identified gaps related to certain alpha states, and in particular, gaps related to the alphas of the endeavour area of concern. Experience thus shows that it is indeed possible to identify gaps in software engineering knowledge based on the Essence kernel.

A2: Work better in my Team

In the context of the use case (i.e. understanding software engineering) we regard the expression production of software system from a holistic point of view and interpret it in terms of executing a software engineering endeavour - rather than limiting the focus on the implementation the system to be build.

In order to understand the skills and areas of responsibilities of other team members within the software engineering endeavour, the specification must provide the possibility to assign skills and responsibilities to individuals. Skills and responsibilities can be considered as the basic characteristics which form a role. Although the specification doesn’t directly specify the concept of roles, it allows defining roles in terms of patterns based on the language construct Pattern. At this, the format of defining roles is not prescribed. Thus, roles can be related, for example, to specific competencies, alphas and activity spaces. For example, the role of the Senior Requirements Engineer could be defined as follows: “The responsibility of the Senior Requirements Engineer is the progress of the alpha Requirements from its initial state until its final state. He actively contributes to the progress of the alphas Opportunity, Stakeholders and Software System. He is lead of the activity space Understand the Requirements. He contributes to the activity spaces Understand Stakeholders Needs, Ensure Stakeholder Satisfaction, Shape the System, and



Use the System. Essential competencies include Stakeholder Representation (competency level 5) and Analysis (competency level 5).” Based on this example, we thus state that the kernel supports the definition of roles including required skills and areas of responsibility. Hence, an organization or a team can define roles and assign them to the team members so that skills and responsibilities of each team member are clear to his peers.

A3: Validate Cost Estimations

Analogue to the alternative path 2, we regard the expression production of software system from a holistic point of view and interpret it in terms of executing a software engineering endeavour.

With regard to the objective of this path, we state that the validation of cost models is not applicable to the Essence kernel and language: Generally, the validation of a model aims to ensure that the model behaves correctly according to its operational needs. Typically, a cost model would be validated, for example, based on empirical studies or reviews by experts. Though, the Essence kernel and language neither provide nor represent a method or technique to validate cost models. Furthermore, cost models aim to provide precise cost estimates in early project stages as opposed to the objective of the Essence kernel and language which is the creation, usage and improvement of methods to engineer software systems. The objectives of both approaches thus differ largely. We thus state that the Essence kernel and language are neither suited to validate cost models, nor is it their intention. We thus don’t consider this point as relevant.

However, the concept of cost estimation and the Essence kernel and language don’t exclude each other. In fact, they might indeed support each other: Typically, a sound cost estimate starts with the definition of some kind of work breakdown structure which includes, for example, a list of tasks, objectives and deliverables related to the production of the final product. The activity spaces and activities defined in an Essence practice might thus contribute to define such work breakdown structures. Furthermore, practices based on the Essence kernel and language scope the software engineering endeavour in a systematic way as they define all necessary things to be done (i.e. activities and activity spaces), to be produced (i.e. work products) and to be progressed (i.e. alphas). A well-defined practice might thus support cost models in the analysis of a software engineering endeavour to provide more precise estimates. Vice versa, a cost model might also complement an Essence practice: The Work alpha focusses on controlling and processing the work in a systematic way. At this, it also includes the monitoring of risks and cost estimates. Hence, a cost model might support a practice in providing the cost estimates which then can be used in the context of the Work alpha.

5.10.5 Discussion

As stated in the first step of the basic path, the specification is not able to fulfil the use case as it does not fulfil the first step of the basic path. Therefore, we don’t take the



other steps of the basic path as well as the alternative paths into account when summarizing in how far the specification fulfils the use case. Though, independent from the basic path, we state that the specification generally supports the alternative paths 1 and 2. Regarding the alternative path 3, we argued that we don’t consider it as relevant in the context of the specification.

Conclusion and Future Work


6 Conclusion and Future Work

Within this thesis, we analysed a set of ten use cases in order to reason about the quality and completeness of the Essence language and kernel specification. Table 27 outlines the results.

Application Area

ID Use Case Name Actor Fulfilled

Design UC-01 Define practice definition

Methodologist Yes

UC-02 Establish well-formed practice

Tool/Tool author Partly

UC-03 Extend practice Methodologist, Project Manager

Yes

UC-04 Compose method Methodologist Yes

Analysis UC-05 Evaluate method or practice

Methodologist, Project Manager

Yes

UC-06 Compare methods

Methodologist, Assessor/Appraiser

Yes, but partly out of scope

Execution UC-07 Simulate practice or method

Methodologist Yes, but partly out of scope

UC-08 Plan based on method

Methodologist Yes

Education UC-09 Teach kernel language

Teacher Yes


Student Partly

Table 27 Fulfilment of use cases

From the viewpoint of the methodologist, the ability to design and execute practices and methods is overall fulfilled although the specification lacks of qualitative issues regarding the specification of the well-formedness rules, especially with regard to OCL. Though, as the latter primarily affects the quality of the specification from the viewpoint of the tool/tool author, we state a high quality from the view of the methodologist. With regard to the quality of the specification from the viewpoint of the tool/tool author, the results are two-fold: On the one hand, the specification gives recommendations regarding tool support although this is not necessarily in the scope of the specification. On the other hand, we state serious issues regarding the specification of OCL invariants and operations not only in the use case Establish well-formed practice but all across the specification. We thus judge the quality from the viewpoint of the tool/tool author as medium. The quality from

Conclusion and Future Work


the viewpoint of the project manager and the teacher is considered as high. With regard to quality from the view of the assessor/appraiser we state that the actor is involved in only one use case which is partly out of scope. We thus don’t consider this as a suitable base to make a sound statement about the quality from this actor’s view. From the viewpoint of the student, we consider the quality of the specification as medium as the specification fulfils the relevant use case only partly. Table 28 summarizes our findings.

Actor Quality

Methodologist High

Tool/Tool author Medium

Project Manager High

Assessor/Appraiser n/a

Teacher High

Student Medium

Table 28 Quality and completeness form the view of the actors

With regard to future work, we consider two topics as very important: First, tool implementation which covers the use cases which are predestined for automation should be realized. For example, in order to automatically extend and to compose practices, to check the well-formedness of practices, or to assess practices or methods. At this, we strongly recommend to review and correct the definition of invariants and operations in OCL. Our analysis also showed that simulation is not in the scope of the specification although it is considered as a fundamental use case. Therefore, future work should investigate into the simulation of practices and methods, with special regard to tool support. Furthermore, the generation of work guidance based on the operational semantics should be automated so that the practitioners can concentrate on their work rather than manually determining the next steps. The second topic which we consider of high importance is to investigate into the application and research of the kernel and the language in practice. During our analysis we touched several issues where an argumentation on a conceptual level is possible to a certain degree but does not replace validation in practice. For example, while we could strengthen the fulfilment of the use case Teach kernel language with experiences already made in academic context, a general and sound answer on the fulfilment of the use case Compare methods must currently remain open.

References


References

[Ambler 2009] Scott W. Ambler. 2009. The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments.

[Boehm and Turner 2003] Barry Boehm and Richard Turner. 2003. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

[Czarnecki and Pietroszek 2006] Krzysztof Czarnecki and Krzysztof Pietroszek. 2006. Verifying feature-based model templates against well-formedness OCL constraints. GPCE 2006: 211-220

[Gruhn 1991] Volker Gruhn. 1991. Validation and verification of software process models. 1991. In Proceedings of the European symposium on Software development environments and CASE technology, A. Endres and H. Weber (Eds.). Springer-Verlag New York, Inc., New York, NY, USA, 271-286.

[Jacobson et al. 2012] Ivar Jacobson, Shihong Huang, Mira Kajko-Mattsson, Paul Mcmahon, and Ed Seymour. 2012. Semat - Three Year Vision. Program. Comput. Softw. 38, 1 (January 2012), 1-12.

[Jacobson et al. 2012b] Ivar Jacobson, Pan-Wei Ng, Paul McMahon, Ian Spence, and Svante Lidman. 2012. The Essence of Software Engineering: The SEMAT Kernel. Queue 10, 10, pages 40 (October 2012), 12 pages.

[Jacobson et al. 2014] Ivar Jacobson, Pan-Wei Ng, Ian Spence, and Paul E. McMahon. 2014. Major-league SEMAT: Why Should an Executive Care?. Queue 12, 2, pages 20 (February 2014), 9 pages.

[Kellner et Al. 1999] Marc I. Kellner, Raymond J. Madachy, David M. Raffo. 1999. Software process simulation modeling: Why? What? How?. Journal of Systems and Software, Volume 46, Issues 2–3, 15 April 1999, Pages 91-105.

[Kruchten 2013] Philippe Kruchten. 2013. Contextualizing agile software development. Journal of Software: Evolution and Process 25(4): 351-361 (2013)

[Ng and Huang 2013] Pan-Wei Ng and Shihong Huang. 2013. Essence: A framework to help bridge the gap between software engineering education and industry needs. 2013 IEEE 26th Conference on Software Engineering Education and Training (CSEE&T), pp.304,308, 19-21 May 2013.

References


[OMG 2011] Object Management Group. 2011. Meta Object Facility (MOF) Core Specification. Version 2.4.1. OMG Document formal/2011-08-05. http://www.omg.org/spec/MOF/2.4.1, last accessed 14.06.2014.

[OMG 2011b] Object Management Group. 2011. Infrastructure Specification. Version 2.4.1. OMG Document formal/2011-08-05. http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF, last accessed 14.06.2014.

[OMG 2013] Object Management Group: Essence - Kernel and Language for Software Engineering Methods 1.0. 2013. http://www.omg.org/spec/Essence/1.0/Beta1/PDF, last accessed 14.06.2014.

[Péraire and Sedano 2014] Cécile Péraire and Todd Sedano. 2014. State-based monitoring and goal-driven project steering: field study of the SEMAT essence framework. In: Proceedings of the 36th International Conference on Software Engineering (ICSE Companion 2014). ACM, New York, NY, USA, 325-334.

[Pohl 2010] Klaus Pohl. 2010. Requirements Engineering. Springer-Verlag Berlin Heidelberg 2010.

[Van der Aalst and Voorhoeve 2010] W.M.P. van der Aalst and M. Voorhoeve. 2010. Business process simulation. Lecture notes 2ii75, 2010-2011.

Appendix A: Documented Use Cases

Analysis of the Completeness and Quality of the Essence specification i



Analysis of the Completeness and Quality of the Essence specification ii


Analysis of the Completeness and Quality of the Essence specification iii


Analysis of the Completeness and Quality of the Essence specification iv


Analysis of the Completeness and Quality of the Essence specification v


Analysis of the Completeness and Quality of the Essence specification vi


Analysis of the Completeness and Quality of the Essence specification vii


Analysis of the Completeness and Quality of the Essence specification viii


Analysis of the Completeness and Quality of the Essence specification ix


Analysis of the Completeness and Quality of the Essence specification x


Analysis of the Completeness and Quality of the Essence specification xi


Analysis of the Completeness and Quality of the Essence specification xii


Analysis of the Completeness and Quality of the Essence specification xiii


Analysis of the Completeness and Quality of the Essence specification xiv


Analysis of the Completeness and Quality of the Essence specification xv


Analysis of the Completeness and Quality of the Essence specification xvi


Analysis of the Completeness and Quality of the Essence specification xvii


Analysis of the Completeness and Quality of the Essence specification xviii


Analysis of the Completeness and Quality of the Essence specification xix

Documents

Analysis of the Completeness and Quality of the Essence