Project-specific software engineering methods: composition, enactment, and quality assurance / Masud Fazal-Baqaie

Project-Specific Software Engineering Methods Composition, Enactment, and Quality Assurance Masud Fazal-Baqaie Faculty of Computer Science, Electrical Engineering, and Mathematics Paderborn University Dissertation submitted in partial fulfillment of the requirements for the degree of Doktor der Naturwissenschaften (Dr. rer. nat.) September 2016 I dedicate this thesis to all young people at the Hindu Kush who pursue knowledge and wisdom to overcome their boundaries. Acknowledgements This thesis has been made possible by support of various people. In the following, I would like to express my gratitude and thank them. First, I would like to thank my advisor Prof. Dr. Gregor Engels. Gregor, thank you for giving me the opportunity to pursue my degree in your research group and for advising me with critical feedback and motivating words. I am especially grateful for your continuous support in phases of intensive project work and during the final phase of writing up the thesis. To a very large extend my research is based on industrial experience that I gathered in projects within the s-lab – Software Quality Lab. Thus, I would also like to thank the managing director of s-lab and co-author of several of my papers, Dr. Stefan Sauer. I also thank the external co-reviewer of my thesis Prof. Dr. Marco Kuhrmann. Thank you Marco for the fruitful discussions on various venues and your thorough review and improvement suggestions on drafts of this thesis. In addition, I would like express my gratitude to Prof. Dr. Eric Bodden and Prod. Dr. Dennis Kundisch for being members of my doctoral committee. During my research, I collaborated with various people and I would like to thank all of them for the joint work on publications or their critical reviews and feedback. I would like to mention a couple of them explicitly. First, I would like to thank Dr. Markus Luckey for being the co-author of my first paper on my thesis topic. I would like to thank Dr. Marvin Grieger for our productive collaboration on several paper projects and for the sparring during writing up our theses. I also thank Dr. Baris Güldali and Prof. Dr. Christian Gerth for our collaboration. Dennis Wolters provided me with valuable feedback on several papers and presentations, thank you for that. In addition, I would like to acknowledge the following people that I advised. Thank you for your contributions to my tooling with your master theses and your work as student assistants: Subramanya Gurumurthy, Frank Kluthe, Karthik Neela, Karimuddin Cuddapah Shaik, Daniel Siebert. vi I would also like to express my gratitude to the various project partners that allowed me to gather practical insights. In particular, I thank HJP Consulting GmbH and S&N AG for the opportunity to work abroad. This thesis is also influenced by the discussions within the German-speaking community of the GI Special Interest Group on Process Models for the Development of Business Application Systems (GI-Fachgruppe Vorgehensmodelle für die betriebliche Anwendungsentwicklung). I would like to thank all former and current committee members for contributing to this community. Fortunately, the last couple of years in pursuit of my degree were not only characterized by work. I would like to thank the former colleagues for the warm and friendly environment of the Database and Information Systems Research Group and the s-lab, especially my office mates Dr. Christian Soltenborn, Dr. Hendrik Schreiber, and Enes Yigitbas. I also thank Ivan Jovanovic and Dr. Stefan Grösbrink for our basketball games and Mirko Rose for our discussions on exotic travels. Thanks to Dr. Henning Wachsmuth, who showed his support by joining my defense. I would also like to thank my friends outside of work – thank you for helping me to forget about work from time to time. I thank my former flatmates (Kircherweg, Königskinder, M7), the Paderborn salsa and climbing communities, and especially: Navneet Bhalla, Ph.D.; Olga Käthler; Regina Dirks; Christina Rieke; Sarah Altmann; Dr. Darko Jus; Danka Dasic; Simon Willmes; Christin Kirchhubel, Ph.D.; Dr. Jörg Clobes; Stephan Parzefall; Tine Niederhacke; Veben Neamen. Thank you Matthias Becker for being my best Bro and for being there, when I am in need for an open ear. Finally, I thank my parents and sisters for their unconditional love and support. I thank Irene Palnau for her patience and her sacrifices, when I was working on my thesis on evenings and on weekends. Rain-soaked hiking tours turn into light-hearted singing sessions with you, Irene. Abstract Software engineering methods describe structured, repeatable best practice approaches for the engineering of software systems. The project team of a software project enacts a method and applies the described activities. As methods are superior to ad-hoc build and fix approaches, they benefit the creation of high-quality software. However, for the efficient use of methods, first, they need to be based on state of the practice method content, second, they need to be tailored to the project context, and third, they need to be enacted as prescribed. Otherwise, outdated, unsuitable, or wrongly enacted methods can impede the creation of the software system. While other approaches focus on supporting some of these aspects, our approach is a holistic tool-supported approach that covers all of them. It allows creating formally defined composition-based method models. First, method models are composed from formal building blocks that represent method content and are stored in an extensible, updatable repository. Second, they are composed specifically for a project and tailored to its characteristics. Here the novel notion of method patterns is used to guide the composition process. Third, their correct enactment is supported with a process engine. Our proof-of-concept implementation demonstrates the feasibility of the approach. It provides tooling to define building blocks, to compose them to method models consistently, and to execute them with standard process engines. Zusammenfassung Softwareentwicklungsmethoden beschreiben Best-Practice-Ansätze für die Entwicklung von Softwaresystemen. Damit sind Methoden einfachen Ad-Hoc-Ansätzen überlegen und ihr Einsatz unterstützt die Entwicklung von hochqualitativer Software. Jedoch erfordert der effektive Einsatz von Methoden, drei Dinge: Erstens müssen Methoden auf aktuellen Methodeninhalten basieren, zweitens müssen sie auf den Projektkontext angepasst werden und drittens müssen sie wie vorgeschrieben von dem Projektteam angewendet werden. Ansonsten gefährden veraltete, unangepasste oder falsch angewendete Methoden den Projekterfolg. Während andere Ansätze nur einige dieser Aspekte abdecken, präsentieren wir einen umfassenden, werkzeugbasierten Ansatz, der alle Aspekte des Managements von Softwareentwicklungsmethoden abdeckt. Unser Ansatz ermöglicht die Erstellung von formalen, kompositions-basierten Methodenmodellen. Erstens werden Methodenmodelle aus formalen Methodenbausteinen zusammengesetzt. Diese repräsentieren, aktuelle Methodeninhalte und werden in einer aktualisierbaren Methodenbasis gehalten. Zweitens werden Methodenmodelle projektspezifisch und kontextbasiert komponiert. Drittens wird ihre korrekte Anwendung durch den Einsatz einer Process-Engine sichergestellt. Unsere Proof-Of-Concept-Implementierung demonstriert die Machbarkeit unseres Ansatzes und stellt Werkzeugunterstützung für die Definition von Methodenbausteinen, die konsistente Methodenmodellkomposition und die Ausführung mit Standard-Process-Engines zur Verfügung. xvi List of figures 3.14 The method pattern for the V-Modell XT is derived by creating constrained scopes for each decision gate . . . . . . . . . . . . . . . . 55 3.15 Constraint scopes that reflect the decision gate “System Designed” ofV-ModellXT ............................... 55 3.16 Relationship of the Work Products for Method Content Definition . 56 3.17 The MESP tools to define method content . . . . . . . . . . . . . . . . 57 3.18 The characterization of a project with basic elements from the method repository .................................. 58 3.19 Two method patterns combined to one pattern . . . . . . . . . . . . . 59 3.20 A partial method model with method services . . . . . . . . . . . . . 60 3.21 A partial method model with additional control and data flow . . . 61 3.22 A correctly specified partial method model . . . . . . . . . . . . . . . 62 3.23 Configuration Interface of the BPEL engine to set up users and roles 63 3.24 Relationship of the MESP Work Products for Method Tailoring . . . 64 3.25 The MESP tools for Method Tailoring . . . . . . . . . . . . . . . . . . 65 3.26 The coordination of activities via workflow tasks . . . . . . . . . . . 66 3.27 A workflow task for the method service Refine the Architecture . . . 67 3.28 Relationship of the MESP Work Products for Method Enactment . . 69 3.29 The MESP tools for Method Enactment . . . . . . . . . . . . . . . . . 69 4.1Extraction of method content from methods described in literature . 76 4.2Extraction of method content from the daily practice of organizations 79 4.3Excerpt of package structure of MESP meta-model . . . . . . . . . . 84 4.4 Illustration of division between Method Content and Process in SPEM (adopted from [OMG08]) ..................... 85 4.5 The basic method elements of our meta-model package BasicMethodElements ................................. 86 4.6 The basic characterization elements of our meta-model package BasicCharacterizationElements ................... 88 4.7 Excerpt of the package structure for method building blocks of the MESPmeta-model ............................. 91 4.8 The method service related meta-classes of our meta-model package MethodService ............................... 93 4.9A method service derived from OpenUP . . . . . . . . . . . . . . . . 94 4.10 The method pattern related meta-classes of our meta-model package MethodPattern ............................... 95 4.11 The condition related meta-classes of our meta-model package patternElements................................. 96 4.12 The service characterization related meta-classes of our meta-model package patternElements ........................ 98 4.13 The work product characterization related meta-classes of our metamodel package patternElements .................... 100 List of figures xvii 4.14 The object model of the method pattern derived from Scrum shown in Figure 3.12 ................................ 102 5.1 The project characteristics related meta-classes of our meta-model packageProjectMethod........................... 110 5.2 The control-flow related method elements of our meta-model packageProjectMethod ............................. 115 5.3 The data-flow related method elements of our meta-model package ProjectMethod................................ 118 5.4The object diagram for the composed method patterns of Figure 3.19 120 5.5The object diagram for the Develop constrained scope of Figure 3.22 121 5.6 The object diagram with the data flow specification between two method service descriptors according to Figure 3.22 .......... 123 5.7MESP’s quality model for software engineering method models . . . 126 5.8Overview of the quality assurance framework . . . . . . . . . . . . . 135 5.9OCL expression to find elements that violate precedence consistency 136 5.10 OCL definition of the helper function getNested() . . . . . . . . . . . 137 5.11 A Java code snippet for the translation of quantifiers to OCL . . . . . 138 5.12 A partial method model with quality issues . . . . . . . . . . . . . . 139 5.13 The generated OCL expressions for the middle constraint scope descriptor of Figure 5.12 .......................... 140 5.14 The execution of a BPEL/BPEL4People process model . . . . . . . . 144 5.15 Snippet of the resulting BPEL process for the end-to-end example . 149 5.16 The configuration interface of the BPEL engine to configure role assignment.................................. 150 5.17 View of the project repository with uploaded WorkProduct . . . . . 150 6.1A partial example method model based on the end-to-end-example 157 6.2The process model for the method model of Figure 6.1........ 158 6.3Task management view of architect Bob with a workflow task ready 159 6.4A workflow task to decide about a further run of an iteration . . . . 160 6.5The Architecture Notebook uploaded to the project repository by Bob161 6.6The workflow task for Envision the Architecture . . . . . . . . . . . . 162 6.7The workflow task for Refine the Architecture . . . . . . . . . . . . . 164 6.8The change log of the project repository . . . . . . . . . . . . . . . . . 165 7.1Definition of a Task using the EPF Composer . . . . . . . . . . . . . . 169 7.2Defining a Method Pattern using the Tree-based EMF Editor . . . . . 169 7.3The end-to-end example in the tree-based editor . . . . . . . . . . . . 171 7.4Composition of a process in the extended BPEL Designer . . . . . . 171 7.5A composed method model in the customized BPEL Designer . . . . 172 7.6The end-to-end example in the Sirius-based editor . . . . . . . . . . . 173 xviii List of figures 7.7 An issue reported in the Problems View and visualized in the Sirius Editor..................................... 174 7.8 The context menu of the tree-based editor showing the command to transform a method model to an BPEL process model . . . . . . . . 175 7.9The captured process for the certification of ePassports . . . . . . . . 177 7.10 Excerpt of the captured process for the certification of ePassports . . 178 7.11 The work products defined based on the BPMN process diagram . . 179 7.12 The tasks defined based on the BPMN process diagram . . . . . . . 179 7.13 The roles defined based on the BPMN process diagram . . . . . . . . 180 7.14 The derived method services for the case study . . . . . . . . . . . . 180 7.15 Details of the method service Perform ICAO Test . . . . . . . . . . . 181 7.16 The composed Method for the certification of ePassports . . . . . . . 182 8.1Contribution Overview of our thesis . . . . . . . . . . . . . . . . . . . 190 List of tables 2.1 Common requirements for software engineering method management solutions without refinement regarding software engineering management layers or assembly-based method engineering (adapted from [Ell+11]) ................................ 28 2.2 Evaluation of existing tool-supported approaches for assembly-based methodengineering ............................ 35 4.1Method definition requirements and the affected MESP tasks . . . . 74 5.1Method tailoring requirements and the affected MESP tasks . . . . . 107 5.2Evaluation Criteria for quality models (adopted from [GK09]) . . . . 133 5.3Refined requirements for the analysis framework . . . . . . . . . . . 134 5.4The mapping of MESP and BPEL/BPEL4People concepts . . . . . . 145 6.1Method Enactment Requirements and the affected MESP tasks . . . 155 7.1The data sets of process models for the scalability analysis . . . . . . 184 7.2Results of the scalability analysis of the Consistency Checker . . . . 185 7.3Results of the scalability analysis of the MESP2BPEL Transformer . 186 CHAPTER 1 Introduction In this chapter, we explain the motivation and problem statement for this thesis. We point out our solution approach and contributions. We present an overview of publications published in the context of this thesis and provide a structural overview of the thesis. 1.1Motivation and Problem Statement In software engineering 1 , similar to other engineering disciplines, a structured approach to the development of the software systems is seen as a key factor for the resulting product and service quality [FRO03]. Software development processes describe such a structured, repeatable best practice. We thereby understand software development processes to comprise project management aspects, organizational aspects, and methodological aspects. Project management aspects denote the scheduling and allocation of available resources, organizational aspects denote the definition of organizational units and allocation of responsibilities, and methodological aspects denote how a software system should be developed systematically. In the following, we focus on the method aspect of software development processes and use therefore the term software engineering method, in short, method. Software engineering methods prescribe who should carry out which activities in what order and thereby describe how artifacts should be derived from one another. In general, software engineering methods cover the typical lifecycle phases of a software engineering endeavor, e.g., a software project. These are software specification, 1Key terms are defined in Section 2.1.1and Section 2.1.2. 2Introduction software design and implementation,software validation, and software evolution. Normally, these phases are not carried out purely sequentially, but earlier phases are revisited regularly [Som11]. In most of the cases, software engineering methods are described textually together with some informal visualizations of the high-level process of activities or phases. If a method is described formally, e.g., by using a meta-model, we call it a software engineering method model or method model. There exist both methods for general-purpose software engineering and methods that are specialized to a specific discipline or domain, e.g., Testing [SLS14] or Automotive [Hoe08]. In this thesis, we focus on software engineering methods for software projects. That is, we do not discuss, organization-wide software engineering methods, often referred to as reference processes. The use of software engineering methods benefits a software project, primarily in two ways [CKO92]: First, it helps the group of involved people to coordinate the various activities and to establish a common vocabulary of how to plan, develop, and maintain a software system. Second, software engineering methods provide guidance for the individual on how to carry out a specific activity. During the past decades, several software engineering methods have been published as reference and best-practice examples based on the experience in different software engineering endeavors. For example, among others, the methods Quasar Enterprise [Eng08] and Rational Unified Process (RUP) [Kru99] where initially created by their respective IT companies for their own software engineering projects. Later, they were published as a reference for the public. While using a software engineering method is in general superior to an ad-hoc build-and-fix approach, there is nothing like an one-size-fits-all software engineering method [Gla04]. Instead, a method that is suitable and beneficial in one context can lead to quality issues in a different context. For example, several publications describe how methods are used successfully in smaller, co-located settings (e.g. [BT03]), while the same methods cause issues in a distributed, global software engineering setting (e.g. [Ram+06],[CR06],[FSH15]). Therefore, the reusability of methods is limited and they need to be customized to the context of the software engineering endeavor – they need to be tailored to the situation [Hen+14]. Looking at tailoring from a conceptual point of view, we can differentiate three layers of software engineering method management. We define this software engineering method management hierarchy consisting of method content definition, method tailoring, and method enactment as follows (adapted from [Hen06], cf. Fig. 1.1): On the upper method content definition layer of the hierarchy, reusable method knowledge is defined by experienced experts, for example, as published methods like RUP and Quasar Enterprise. On the middle method tailoring layer, these methods need to be tailored to the situation, for example, by the process manager of an organization or a project manager. On the lowest method enactment layer, the 1.1Motivation and Problem Statement 3 tailored method is then to be enacted by the organization or project team by following the method. Software engineering method management is the coordination of efforts to accomplish these objectives. The method-related content created on one layer influences the content on the layer below: the amount and form of available method content created on the topmost layer influences how easy the method can be tailored to the situation on the middle layer. For example, a textual representation defined on the top layer is more difficult to tailor in a consistent manner than a formal representation. If alternative activities are defined on the top layer, this additional choice eases the tailoring. The content and form of the tailored method on the middle layer, in turn, directly influences how easy the people can apply and follow the method. For example, a textual representation is more ambiguous than a formal one and a method that includes more detailed guidances and task descriptions is easier to enact. Method Content Definition Definition of Reusable Method Knowledge Method Tailoring Adaption of the Method to the Situation Method Enactment Following the Method as Prescribed Fig. 1.1The three conceptual layers of software engineering method management Challenges of Software Engineering Method Management Each layer of the software engineering method management hierarchy poses its individual challenges. In the following, we discuss the challenges for each layer. Regarding the definition of method content, it is difficult to update the content of methods incrementally in order to reflect current trends, best practices, and lessons learned [KF15]. For example, as the agile methodology [Mey14] is becoming more and more popular, many creators of methods face the challenge to integrate agile principles into their methods [VB15],[BT03]. Consequently, the users of these methods cannot make use of the advances and improvements before new versions of the methods are released. One major obstacle for updating methods is that they are typically described in a textual manner, what makes it difficult to clearly scope the area to improve and to assess the implications for the unchanged parts [WBV07]. 4Introduction Regarding the tailoring of methods, methods are sometimes defined in such a way that they do not especially address the need for tailoring or they even disallow it [Hen+14]. However, many comprehensive methods, e.g., RUP, Quasar Enterprise, V-Modell XT [KTF11], or MFESA [Fir09] acknowledge the need to tailor a method to a situation. They are published as software engineering method frameworks (termed process framework in [KFS13a]) that do not describe a uniform method to be used in every project, but support a certain degree of tailoring. Therefore, they require that as a preliminary step, the method has to be created by selecting and adjusting from the provided content. Agile methods, e.g., [SS13], [Bec00], [Coc05] follow a different approach to achieve the tailoring of the software engineering method to the situation. They focus on the lightweight description of some mandatory core roles, activities and artifacts, while the rest is left to be defined and adapted by the project team based on its experience and the current circumstances of the situation. For example, the popular and widely adopted software engineering method Scrum 2 [SS13] includes a periodical activity called Retrospective. This activity is dedicated to perform required changes (method tailoring) to the method itself. The actual software engineering activities (method content definition), however, are described in the most generic way possible. Irrespective of the underlying method, tailoring a method in a meaningful and consistent way is a non-trivial task that needs to be performed by experts [KF15],[Hei+10]. One of the reasons for this is that many methods have no underlying formalism at all and are described purely in natural language, e.g., Scrum, Quasar Enterprise, or the Crystal Family [Coc98; Coc02; Coc05]. Therefore, ensuring the consistency of a method is more difficult. Both RUP and V-Model XT evolved to a model-based approach, where the tailored methods are instances of a meta-model that describes the rules for consistent method models. However, there is only very limited support and guidance on how to tailor a method model with respect to the situation, e.g., whether an activity should be added or replaced. Even though the meta-model of RUP evolved to the industry standard Software & Systems Process Engineering Meta-Model Version 2.0(SPEM) [OMG08] in 2008, the modeling language is still not commonly used. In addition, the language itself has been criticized, because it does not allow specifying an executable method model [Ell+10], what makes it more difficult to follow the method properly. Regarding the enactment of methods, it has to be ensured that how the work is actually carried out corresponds to the defined method, otherwise there is the risk of missing out important activities or doing them wrongly [Ost87]. For example, in global software projects it is challenging to maintain sufficient overview and to coordinate the activities according to the defined method [NC13]. Typically, there is only generic tool-support for tailored methods available as these are often 2 Scrum focuses on the project management aspects of software development processes, but is typically complemented with agile principles. 1.1Motivation and Problem Statement 5 described in natural language and tool support cannot be derived automatically. While Application Lifecycle Management (ALM) suites [KV09] offer tool support of the implemented general-purpose methods, they typically do not provide guidance for the tailoring of methods. Problem Statement Acknowledging the difficulties of software engineering method management, the research area situational method engineering 3 is dedicated to the provisioning of situation-specific methods [Hen+14]. Here, several approaches to provide and manage method content, to derive situational software engineering methods, and to enact them were proposed in the past. Each approach varies in its level of support for the three software engineering method management levels. At present, existing approaches do not support all three levels sufficiently in one comprehensive solution. Approaches like [Har97; GP01; Ral04; KLR96; Spi15] lack in particular a formal foundation that allows checking tailored methods for consistency and that allows to execute them. Other approaches like [Ell+11; Ben+07; Wis+00] offer a modeling language that allows to model executable method models, but do not sufficiently support the tailoring of methods and the definition of reusable method content. In summary, to leverage the advantages of software engineering method management, the entire lifecycle of software engineering method models needs to be addressed. To that extend, a suitable solution for the definition of method content, its tailoring to a situation, and its enactment is required. Such a solution needs to address the following challenges: • It must enable updates of method content based on new trends, best practices, and lessons learned • It must enable the creation of consistent software engineering method models for specific situations based on defined method content • It must enable the proper enactment of the tailored method models according to their definition In this thesis, we introduce a comprehensive solution for software engineering method management that tackles the described challenges. Our solution is based on research and industrial project work performed within the s-lab – Software Quality Lab of the University of Paderborn in joint projects with HJP Consulting GmbH and other industrial partners. The research has been partly founded by the German Federal Ministry for Economic Affairs and Energy (Bundesministerium 3discussed in detail in Section 2.1.2 12 Introduction how to transition from a fixed method to a method management framework that allows creating situational methods. Here, we describe how to derive method building blocks based on the existing methods, experiences, and knowledge within that company. Beside the work on the generic MESP framework, we have also worked on a method engineering approach specific to the creation of software migration methods. Here, we described the framework for such an approach in [GF15a] and [Gri+16], the method base including fragments and patterns in [GFS16], and specific method engineering activities to improve the method definition based on experience and feedback from the method enactment in [Gri+14]. Beside the work on method engineering frameworks, we published a number of papers that reflect the experience in concrete, industrial method engineering projects performed within the s-lab – Software Quality Lab. In [Faz+13], we describe how to systematically create situation-specific requirements engineering methods and how to derive proper tool support for them. A number of publications focuses on the creation of situation-specific methods for global software development (GSD) projects. In [FSH14; FSH15], we describe an industrial project, where method building blocks were derived based on the existing practices within that company. In another publication, we explain how we improved the software engineering method and its tool support in order to improve the synchronization of team members in a GSD project [FGS15]. This is also the main theme for [GF15b] that highlights the synchronization of multiple teams in an agile GSD setting. In a further publication, we discuss how to arrive on a software engineering method in a collaborative, team-based setting [FR15]. Last, but not least, the work for this PhD thesis is also influenced by the discussions within the German-speaking community within the GI Special Interest Group on Process Models for the Development of Business Application Systems (GI-Fachgruppe Vorgehensmodelle für die betriebliche Anwendungsentwicklung). The author of this thesis is the vice chairman of the executive committee and volume co-editor of two proceedings [HMF13; Eng+15] of the annual conference. 1.4Structure of the Thesis The remainder of this thesis is organized as follows (cf. Figure 1.2): In Chapter 2, we introduce the background for software engineering method management, we discuss the solution requirements, and present a general overview of the related work in method engineering. In Chapter 3, we present an overview of our solution and introduce the different roles of the MESP approach and their tasks. We go into details for these roles in the following chapters. In Chapter 4, we describe the tasks of the senior method engineer and explain the formalization of method building blocks. Chapter 5is 1.4Structure of the Thesis 13 concerned with the tasks of the project method engineer. Here, we go into the details of the characterization of a situation, the composition of method models, their quality assurance, and the preparation of method models for execution. In Chapter 6, we explain the tasks of the project team. Here, we explain how the method is enactment with support of the BPEL engine and how the team reflects on the method enactment to support improving method content. We discuss the proof of concept implementation of our solution in Chapter 7. Here, we describe our prototypical tool implementation together with a first case study and scalability analysis experiment of the method composition. We conclude the thesis with the summary of our contributions, the discussion of the solution requirements, and an outlook on possible future work in Chapter 8. CHAPTER 2 Background In this chapter, we discuss the background of the work presented in this thesis. This chapter is structured as follows. In Section 2.1, we present the foundations of this thesis and clarify the used terminology. Thereafter, we discuss the requirements for our solution and the evaluation of the state of the art in software engineering management in Section 2.2. Finally, we conclude this chapter with a summary in Section 2.3. 2.1Foundations and Terminology 2.1.1Application Development with Software Engineering Methods 2.1.2Situational Method Engineering 2.1.3Executable Process Description Languages 2.2Solution Requirements and State of the Art 2.2.1Requirements for a Holistic Solution 2.2.2Evaluation of Existing Approaches 2.3Summary 16 Background 2.1Foundations and Terminology In this section, we give a general introduction to the use of software engineering methods in application development. Thereafter, we give an overview of the field of situational method engineering that deals with the creation of custom methods for specific projects and organizations. Finally, we will briefly explain the role of executable process description languages and their relationship to the enactment of methods. Throughout the chapter, we will present the definition of key terms for this thesis. 2.1.1Application Development with Software Engineering Methods Software engineering is an engineering discipline. Like in other engineering disciplines, engineers apply appropriate theories, methods, and tools to find solutions. Doing that, they recognize the existing organizational, schedule-related, and financial constraints. Definition 1 (Software Engineering) . “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering of software.” [IEE90] Software engineering thereby is not limited to the technical aspects of software development. It also includes, e.g., activities of software project management or the creation of tools and theories to support software development [Som11]. The systematic and structured approach used in software engineering is called asoftware development process. Definition 2 (Software Development Process) . A software development process is a goal-oriented activity in the context of engineering-style software development. It can be refined by subprocesses, each of which can also be refined and it usually transforms one or more input work products into one or more output work products by consuming further work products [Mün+12]. As described, software development processes comprise project management aspects, organizational aspects, and method aspects. In this thesis, we focus on the method aspect of software development processes and use the term software engineering method for descriptions of the method aspect, in short, method. Definition 3 (Software Engineering Method) . A software engineering method is the structured approach to create a software system. It consists of the activities, their order (process), the work products (artifacts) that are produced and used in them, and the roles that are responsible for them, as well as their description, supporting materials like tools to be used or checklists (guidances [OMG08]), as well as the relationship between all these elements (cf. [ES10] and [Hen+14]). 2.1Foundations and Terminology 17 The constituents of software engineering methods are explained in more detail in chapters 4and 5. In Figure 2.1, we illustrate further concepts that are related to methods. In the following, we describe them and their relationship. Software Development Process Method Aspect Software Engineering Method Software Engineering Method Model Software Engineering Method Meta- Model Software Project Software System Software Engineering Method Management Software Process Improvement Executable Method Model Executable Process Description Language Situation Software Engineering Endeavor Process Model Project Team Process Engine Activities Roles Process Work Products Guidances Software Process Management Software Method Improvement Tools creates enacts influences provides and maintains provides and maintains executes describes formalizes conforms to / instantiates guides conforms to / instantiates Fig. 2.1The concepts related to software engineering methods Software engineering method cover the typical (normally overlapping) lifecycle phases of a software project, which are software specification, software design and implementation, software validation, and software evolution [Som11]. They are enacted by a project team of a software project (or another software engineering endeavor) to create the software system. Definition 4 (Project Team) . The project team is the group of people that performs the activities of the method (the group that enacts the method). Individual team members are assigned to the roles used in the method and thereby are responsible for performing the associated activities (adapted from [Mün+12]). Definition 5 (Enactment) . We speak of enactment (of the method), if the project team performs activities that are part of the method (adapted from [Mün+12]). 18 Background Definition 6 (Activity) . An activity represents a unit of work in a method that needs to be performed in order to create the software system by following that particular method (adapted from [OMG08]). Beside the term activity, we use the term task, when we want to stress the way how work needs to be performed. Activity and task a differentiated in more detail in the content chapters 4and 5. Definition 7 (Software Engineering Endeavor) . A software engineering endeavor is the setting, in which the method is applied, e.g., an individual software project or a whole organization (adopted from [Hen+14]). In case of organization-wide software engineering methods, the term reference process is often used instead of method, because it typically serves as a coarse-grained reference that needs further refinement before it can be applied. In this thesis, we focus on software projects as the software engineering endeavor. Definition 8 (Software Project) . “A software project is a unique endeavor, which is limited by a start date and an end date and should achieve a goal.” [Mün+12] The use of software engineering methods benefits a software project in multiple ways (adapted from [CKO92]): first, it facilitates the understanding and communication about the activities to create a software system. Thus, it supports the coordination of those activities. Second, it offers guidance to individuals on how to carry out a specific task. Third, software engineering methods are typically the foundation for measurement and systematic improvement of the software engineering within an organization. In order to specify methods more formally, e.g., to reduce ambiguity, the can be described as an instance of a software engineering method meta-model. Definition 9 (Software Engineering Method Meta-Model) . A software engineering method meta-model is a meta-model for models that represent methods. It defines the valid structural properties of such models and can be used to instantiate conforming models. Thus, it is a specific kind of modeling language. We will use the term software engineering method model or, in short, method model, when we refer to the instance of such a method meta-model. Definition 10 (Software Engineering Method Model) . A software engineering method model is a formal model of a method that is based on and conforming to a meta-model (or other formalism). Despite the existence of the internationally standardized meta-models Software Engineering Metamodel for Development Methodologies (SEMDM) [ISO07] and SPEM [OMG08], very often software engineering methods are specified without using a common notation and with natural language only, e.g., [JBR99] or [SS13]. 2.1Foundations and Terminology 19 When the control and data flow within a software engineering method model is described formally enough, that is, in terms of an executable process description language, it can be executed with a process engine. We call this an executable method model. Definition 11 (Executable Process Description Language) . An executable process description language is a language to create models that represent processes and that can be executed with a process engine. Definition 12 (Executable Process Model) . An executable process model is a model that is created with an executable process description language and can be interpreted by process engines (adopted from [Mün+12]). Definition 13 (Executable Method Model) . An executable method model is a software engineering method model that is also an executable process model. Definition 14 (Execution) . We speak of execution of a method model (or process model), when the method model is interpreted by a process engine, typically to support a project team in the enactment of the method model (adopted from [Mün+12]). Definition 15 (Process Engine) . A process engine is a generic software that can interpret the process structure and work allocation rules of a process model (adopted from [AH02]). A process engine executes a process model and guides the project team. It coordinates its activities by assigning tasks to team members and by showing them guidances for their tasks. While not common for software engineering methods, business processes are commonly formalized using executable process description languages. What software engineering method is used depends on the context of the software project, we call it the situation. As there is no universal software engineering method, many different software engineering methods have evolved over the past 50 years. Definition 16 (Situation) . The situation is the sum of the local conditions of a software engineering endeavor that influence the suitability of a method or parts of it, e.g., the release frequency or the customer involvement (adopted from [Hen+14]). One very significant local condition (called situational factor) that influences as part of the situation what software engineering methods are used is that of the application type of the software system that is to be created. Application types are categories based on the nature of a software system (adapted from [Som11, pp. 10–11]): for example, interactive transaction-based applications are applications that are executed on a remote server or in the cloud and accessed by different users by their laptops, tablets, and mobile phones. They often have a large centralized database that is accessed with transaction-based requests. Examples for such 20 Background systems are modern business systems with cloud-based services and web-based or special-purpose clients (apps). Interactive transaction-based applications are often also referred to as information systems (e.g. in [CC05]). Another application type are embedded systems, which are low-level software systems that manage and control hardware devices. These embedded systems often run in resource-constrained environments and are sometimes safety-critical, for example, software that controls anti-lock braking in a car, and software in a microwave oven to control the cooking process. In this thesis, we focus on software engineering method management for interactive transaction-based applications as our work is mostly based on software engineering for this application type. Our solution might be usable or adapted also for other types, however, an in-depth investigation remains possible future work. Software engineering methods for interactive transaction-based applications are sometimes categorized as either plan-driven or agile [BT03]. Plan-driven refers to methods that typically differentiate multiple phases within a software project and where the activities are planned in advance and progress is measured against this plan, e.g., Quasar Enterprise [Eng08], V-Modell XT [KTF11], RUP [Kru99], or Unified Process [JBR99]. Agile refers to more lightweight, team-centered methods that typically to do not define separate phases, but integrate all activities into a development cycle that is performed throughout the project, e.g., extreme programming (XP) [Bec00] or Scrum [SS13]. In agile methods, planning is incremental and changing customer requirements can be accommodated easier at the cost of continuous rework. As discussed in [BT03], both approaches have their individual advantages and drawbacks and based on the project situation, a balance has to be found. Balancing plan-driven and agile principles based on the project context is one example for the need of software engineering method management. Another example is to update the method to take advantage of latest best practices [Som11]. In this thesis, we use the term software engineering method management for the activities illustrated in Figure 1.1. It includes, first, updating the defined method content, e.g., with new activities based on new best practices, second, providing methods suitable for a given situation, e.g., by balancing plan-driven and agile principles, and third, controlling the enactment of methods, e.g., by ensuring that the order of activities corresponds to the method. The management of software engineering methods includes software method improvement, a term that describes the effort to continuously asses and update the method content. Closely related is the term of software process improvement that is used to describe the continuous assessment and change of software development processes in the whole [HRT04]. In software process improvement so-called capability maturity models are used as an approach to measure the degree of formality and optimization of a software development process. Two well-known capability 2.1Foundations and Terminology 21 maturity models are Software Process Improvement and Capability Determination (formally Software Process Improvement and Capability Evaluation – SPICE and now part of ISO/IEC 15504) [Loo07] and Capability Maturity Model Integration (CMMI) [Sof10]. Capability maturity models can be seen as a generic frame of reference to assess different software engineering methods as they define requirements that must be met to reach specific maturity levels in separate disciplines. In the next section, we will give an overview of the research field that deals with the systematic creation of software engineering methods. 2.1.2Situational Method Engineering Over the past 50 years, many commercial or brand-named software development methods have evolved. However, as there is no single method that is suitable for all systems, organizations, or projects, in practice, these are not widely used and especially not in their entirety (cf. [FRO03] and [KF15]). With the lack of suitable fixed methods, customized methods were derived by tailoring, i.e., modifying existing methods. However, this tailoring was often performed in an unsystematic and especially informal manner [Ped+07] with outcome of varying quality [XR08]. We refer to this unsystematic and informal approach as free tailoring in this thesis. The observation that there is no single one-size-fits-all method and the need to systematically derive methods gave rise to the research area and engineering discipline of situational method engineering (SME) [HR10]. Situational method engineering includes all aspects of systematically creating and adapting software engineering methods based on local conditions (situations) as opposed to using unaltered offthe-shelf, fixed methods or unsystematic, free tailoring. SME is sometimes referred to as method engineering (ME), however, in strict terms SME is a subset of ME, the latter describing the systematic definition, adaption and enactment of methods for software development in general [BLW96]. Situational method engineering can be therefore seen as an attempt to provide generic solutions for software engineering method management. Definition 17 (Situational Method Engineering) . Situational method engineering is both the research area and engineering discipline that deals with the systematic creation and adaption of software engineering methods to situations (adopted from [HR10]). Situational method engineering approaches can be compared among several dimensions. Looking at the two dimensions degree of flexibility and tailoring effort, method engineering approaches can be grouped roughly into three groups: • the group of creation-based, • the group of assembly-based, and • the group of configuration-based approaches. 28 Background Table 2.1Common requirements for software engineering method management solutions without refinement regarding software engineering management layers or assembly-based method engineering (adapted from [Ell+11]) Common Requirement Description Scalability Large as well as small methods can be created and managed Decomposability Sub methods and compound methods can be defined Adaptability Tailoring a given method to the needs of a project must be straightforward Testability Plausibility checks can be performed automatically to help creating methods Easy-to-digest formalism Needed, because in the past complex formalisms have prevented adoption by practitioners Executability Methods can be directly interpreted by a machine or otherwise mapped to an executable language Automatic process execution A process engine is provided that supports the team in their work according to the method, triggers certain tasks on time, and controls the delivery of artifacts Electronic process guide A process engine actively guides team members by providing information that is sensitive to the task context at hand according to the method Automatic audit trail A process engine automatically keeps track of changes to work products and progress of the method enactment 2.2Solution Requirements and State of the Art 29 While the list of common requirements provides a good starting point, it can be improved in two ways. First, the requirements are not explicitly associated with the method engineering management layers or the described challenges. In particular, requirements for method content definition and method tailoring are not clearly separated. Thus, their relationship to the challenges is not stated explicitly. Second, the requirements are very generic and to not take into account specifics of assembly-based approaches. Based on the common requirements and characteristics of assembly-based approaches we refined SRs for a solution that addresses the software engineering method management challenges. The relationship between software engineering method management layers, common requirements and our solution requirements is shown in Figure 2.4. In the following, we discuss our solution requirements. Following the different levels of the software engineering method management hierarchy, we first discuss five method content-related criteria, afterward four tailoring-related criteria, and finally, three enactment-related criteria. Method Content Definition Method Tailoring Method Enactment SR 1.1: Abstract Orderings SR1.2: Explicit Interfaces SR1.3: Composite Building Blocks SR1.4: Method Repository SR1.5: High -Level Modeling SR2.1: Project Characterization SR2.2: Composition Guidance SR2.3: Consistency Analysis SR2.4: High -Level Composition SR3.1: Executable Process SR3.2: Enactment Support with Human Interface SR3.3: Enactment Logs Scalability Decomposability Adaptability Easy-to- digest formalism Testability Executability Automatic process execution Electronic process guide Automatic audit trail Layer Solution Requirements Common Requirements Fig. 2.4 The relationship between software engineering method management layers, our solution requirements (SRs), and the common requirements in [Ell+11] Solution Requirement 1.1– Abstract Orderings As a refinement of the scalability requirement, we define the criterion abstract orderings. Abstract orderings allow modeling orderings without referencing concrete building blocks. This ensures that the orderings can be used also for yet not defined building blocks. These ordering can then be used to speed up the definition of especially large methods and they serve as an additional guidance during method composition. 30 Background Solution Requirement 1.2– Explicit Interfaces As another criterion that is related to the scalability requirement, we define the criterion explicit interfaces. Explicit interfaces abstract from the content of method building blocks and make the information that is necessary to find and compose suitable building blocks available. Thus, they reduce the cognitive load when performing the related tasks. Solution Requirement 1.3– Composite Building Blocks As a refinement of the decomposability requirement, we define the criterion composite building blocks that assesses whether building blocks of an approach support the composite pattern. Composite building blocks allow hiding the complexity of building block compositions as they can be treated like ordinary building blocks. Solution Requirement 1.4– Method Repository As a refinement of the adaptability requirement, an assembly-based approach requires a method repository to store method building blocks. Some method engineering approaches additionally store composed methods and method enactment data in the method repository. Solution Requirement 1.5– High-level Modeling As a refinement of the easy-to- digest formalism requirement, this criterion expresses whether an approach offers a high-level modeling language and appropriate tooling to define method building blocks. This would ease the definition of method building blocks. Solution Requirement 2.1– Project Characterization As a refinement of the adaptability requirement, an assembly-based approach requires the characterization of the project in order to ease finding suitable building blocks for a project. Solution Requirement 2.2– Composition Guidance As another refinement of the adaptability requirement, this criterion expresses whether an approach offers guidance in composing a suitable method for a project. Solution Requirement 2.3– Consistency Analysis As a refinement of the testability requirement, we define the criterion consistency analysis. It measures, whether an approach offers consistency rules and tooling for it. This criterion is partially fulfilled, if the conformance to the meta-model can be checked automatically. It is fulfilled, if additional plausibility and quality checks are performed. Solution Requirement 2.4– High-level Composition As a refinement of the easy- to-digest formalism requirement, this criterion expresses whether an approach offers a high-level composition language and appropriate tooling to define method compositions. This would ease the composition of methods. 2.2Solution Requirements and State of the Art 31 Solution Requirement 3.1– Executable Process As a refinement of both, the executability and the automatic process enactment requirement, this criterion measures whether methods can be executed with a process engine. This criterion is fully fulfilled, if both flow of activities and the flow of work products is considered and supported. Solution Requirement 3.2– Enactment support with Human Interface As a refinement of the electronic process guide requirement, this criterion expresses whether an approach offers guidance for the enactment of a task and the GUI for the team member to interact with the method. This criterion is fully fulfilled, if the flow of work products is considered. This means that the team member can inquire about her input work products and report output work products. Solution Requirement 3.3– Enactment Logs As a refinement of the automatic audit trail requirement, this criterion expresses whether an approach offers support to log information about the enactment of a method in order to support the reflection of the method. The solution requirements are used to asses approaches proposed in related work in the following section. Later, we use the solution requirements to assess our proposed solution. 2.2.2Evaluation of Existing Approaches In this section, we discuss existing holistic tool-supported approaches for assemblybased method engineering and assess them against our solution requirements. Overview of Existing Approaches Related works for assembly-based method engineering exist on a broad range, however, often focusing on specific aspects. In the following, we give a brief overview of existing works and thereby focus on holistic solutions to assembly-based method engineering that are tool-supported. These works will be considered for the evaluation later in this chapter, while additional works will be also discussed in this section for the purpose of completeness. References to related work concerning specific aspects of assembly-based method engineering, such as modeling of executable processes, are not considered here but later in the respective chapters. Holistic Assembly-based Approaches In the following, we give a brief overview of works that provide holistic solutions to assembly-based method engineering and that are tool-supported. These works will be considered for the evaluation later in this chapter, while other works will be also discussed here for the purpose of 32 Background completeness. Brinkkemper and Harmsen presented an assembly-based method engineering approach that is accompanied by their tool Demacrone [Har97]. Their approach covers the definition of method building blocks and their storage in a method repository [HB95]. They also define dimensions for the project characterization and formulate assembly rules for the composition of methods that could be reused for later consistency analysis. Their solution offers the generation of a CAME environment and a process engine based on the composed method. However, they admit issues with the usability, performance, and reliability of their approach [Har97, p. 277]. In addition, their solution depends on low-level modeling languages and on outdated and proprietary technologies as the Prolan programing language of the CASE environment Maestro II and a character-based user interface. The method engineering approach for the tool MERU [GP01] is based on the creation of a implementation-independent Method Requirements Specification (MRS) by means of a MRS Creator. This MRS is used instead of the characterization of the project. The MRS can be analyzed for basic consistency violations and is then translated semi-automatically in several steps to method building blocks and then a composed method. From this method a suitable CASE environment is generated afterward [PS97]. The authors do not explain whether created method building blocks are supposed to be used for future methods. In addition, support for process enactment is missing. Another tool-supported approach is MENTOR [SRG96; Pli96]. This approach uses method building blocks that follow the NATURE contextual approach [Gro+97]. Thus, building blocks are tree-based structures that bundle situations to decisions, where situations reflect the state of products and decisions the intention of the engineer. Instead of characterizing a project and modeling the whole process explicitly, the core of the solution is the Guidance Engine that finds suitable building blocks according to a situation and the defined high-level process. Based on the selection of the method engineer, it executes them and thereby offers guidance to the application developer (or method engineer). The solution includes a method repository, but there is no support for consistency analysis and like Demacrone the tooling is based on outdated technologies. The tool family Method Management Tools [KLR96] is build on top of the meta- CASE environment MetaEdit+, whose successor is still available for current software platforms. It offers a method repository to store method building blocks, means to compose methods, basic means to check methods for consistency, and generators to generate a CASE tool customized to the method. Not covered by the solution is supporting the choice of suitable method building blocks and the enactment of the method with the guidance of the project team. An assembly-based approach that was proposed recently and that is based on modern technologies and standards is MOSKitt4ME [Cer+11]. It is build on top of an Eclipse-based [Ste+09] modeling platform called MOSKitt. The approach is 2.2Solution Requirements and State of the Art 33 based on the SPEM standard and supports the composition of methods based on a method repository of method building blocks and specifically focuses on deriving a suitable CASE environment for the method. Therefore, technical building blocks are part of the method definition. These define the tools that should be used to create and to process work products. After method composition these tools are automatically bundled into a CASE environment to use during method enactment. The approach has no process execution support as execution semantics are missing in SPEM. A consistency analysis and also support for abstract orderings is also missing. Ellner et al. [Ell+10; Ell+11] provide eSPEM, a tool-based approach for the modeling and execution of methods. The approach is based on extensions to SPEM to address SPEMs lack of executability and it is based on the Eclipse ecosystem [Ste+09]. It offers a method repository for the storage of method building blocks and visual editors to model reusable method building blocks and compose them to executable methods. The approach also offers rudimentary analysis support of created methods. While the extension of SPEM with execution support is one of the strengths of this approach and its tooling, there is no explicit support for situational method engineering in terms of characterizing method building blocks and the project nor for abstract orderings. Further Related Work Bendraou et al. [Ben+07] also propose an extensions to SPEM called xSPEM to address SPEMs lack of executability. However, creating situational methods is not in scope of their work and they only sketch some mappings between concepts of xSPEM and BPEL and, e.g., human interaction with executed methods is not discussed. In addition to these approaches, related work comprises other approaches worth mentioning here. Software engineering method frameworks (termed “process framework” in [KFS13a]) like V-Modell XT [KTF11] or Rational Unified Process (RUP) [Kru99] offer more flexibility than rigid methods and allow a certain degree of tailoring to a project or organization. These frameworks can be attributed to configuration-based method engineering, however, the offered guidance and tool support for tailoring varies among approaches. V-Modell XT for example offers explicit configuration points that lead to the inclusion or exclusion of activities in the method. Additionally, methods of software engineering method frameworks are based on a meta-model that provides a formal foundation and allows additional creation-based method engineering. Another configuration-based approach consists of the Method for Method Configuration and its tool support MC Sandbox [KÅ11; KÅ12]. Here, non-hierarchical method components are defined that express how to transform input work products into a defined output work product together with the rationale of such a transformation. For each assignment of a so-called characteristic (basically a configuration 34 Background point) a configuration package is created that describes which method components shall be included. Multiple characteristics are then covered by configuration templates that basically characterizes a complete development situation and a complete set of required method components. When changing the assignment for single characteristics, the tooling can compute the set of included method components and detect classification conflicts (contradicting method components) that then have to be handled manually. The enactment is supported with a project-specific method website that is derived from the included method components. In addition to the described method engineering approaches, various works propose approaches that focus on the conceptual level. We exemplarily present three of them. A more complete overview is provided in [Hen+14]. Spijkerman [Spi15] proposes the extension MetaMe++ as an improvement to the creation-based method engineering approach described in [ES10]. Here, method requirements are derived based on an as-is analysis of the specific situational context of an existing organization. These are then used to iteratively improve the method in several method improvement iterations. The method is thereby modeled based on the product and process meta-model of MetaMe++. The work by Geisen [Gei15] deals with the adaptation of a method during method enactment. Adaptions of the method are seen as necessary reactions to changes of the situational context of the project. The work describes a conceptual framework that is based on the adoption of the MAPE-K feedback loop [KC03] from the adaptive systems domain. Ralyté proposes two approaches to extract reusable method building blocks from existing methods and from scratch in [Ral04]. She uses the map formalism [RP96b] to model the approaches where a number of intentions is linked to a number of strategies. Another related group of work are ALM suites [KV09] that integrate with various tools, e.g., configuration management systems, change management systems, and IDEs into a distributed development and collaboration platform. Examples for these suites are Microsoft Team Foundation Server 4 (TFS), IBM Rational Team Concert 5 , and Method Park Stages 6 . These ALM suites offer to some extend method execution support and allow for the use of automated workflows defined in templates delivered by the ALM vendor. These workflows usually cover only limited parts of the whole software engineering method, e.g., they cannot determine the next possible steps in a process and guide team members accordingly [Ell+11, p. 80]. Manual adaption of these templates is possible, but especially the creation of situational methods is not supported explicitly. In [KKT14] Kuhrmann et al. describe a generic framework that allows generating templates for ALM suites like 4http://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx 5http://www.ibm.com/software/products/en/rtc 6http://stages.methodpark.de/ 2.2Solution Requirements and State of the Art 35 TFS, based on process models. However, situational method engineering is also not addressed explicitly here. Evaluation Existing related works for assembly-based method engineering exist on a broad range, however, often focusing on specific aspects. In our evaluation, we consider the holistic, tool-supported assembly-based method engineering approaches discussed in this section. Hence, we omit approaches that are not assembly-based ([KTF11], [Kru99], [KÅ11], [KKT14]), that focus only on specific layers of the software engineering method management ([Ben+07], [Ral04]), or that do not provide any tool support ([Spi15], [Gei15]). Table 2.2shows the result of our evaluation. Table 2.2 Evaluation of existing tool-supported approaches for assembly-based method engineering abstract orderings explicit interfaces composite building blocks method repository high-level modelling project characterization composition guidance consistency analysis high-level composition executable process enactment support with human interface enactment logs Demacrone [HB95],[Har97] - -□+-+(+) - - (+) - - MERU [GP01], [PS97] --□□□(+) (+) (+) □- - - MENTOR [SRG96],[Pli96] - +□+(+) -(+) (+) - (+) (+) □ Method Management Tools [KLR96] - -□+ + - - (+) + - - - MOSKitt4ME [Cer+11] -+□+ + - - - + - - - eSPEM [Ell+10], [Ell+11] -(+) + + + - - (+) + + + + Tailoring Support Enactment Support Content Definition + supported (+) partially supported -not supported □not considered Content Definition While several approaches differentiate different levels of granularity, none of the approaches provides support for abstract orderings. About half of the approaches support the definition of explicit interfaces for method building blocks and allow modeling them with high-level modeling support. While MENTOR and Method Management Tools use outdated technologies, the approaches eSPEM and MOSKitt4ME are build on top of the contemporary Eclipse platform and use the popular Ecore meta-model [Ste+09]. Except eSPEM, none of the approaches discusses composite building blocks. Except of MERU, where it is unclear, all 36 Background approaches offer a method repository. About half of the approaches support high-level modeling with visual languages. As stated, eSPEM and MOSKitt4ME are build on top of the contemporary Eclipse platform, while Method Management Tools and MENTOR use outdated technologies. Tailoring Support Regarding tailoring support, only the two approaches Demacrone and MERU offer means for explicit project characterization. In the latter approach, instead of the typical situational factors, a method requirements specification is created. Composition guidance and consistency analysis are provided only partially and only in roughly half of the approaches. In addition, only MERU and MENTOR provide both. Regarding high-level composition support, besides one exception, the support looks the same as that of the modeling of method building blocks. The exception is that MERU does not offer high-level composition support, as processes are not explicitly modeled in the approach. Enactment Support Most of the presented approaches offer, if at all, only weak enactment support. eSPEM is the only approach that supports all enactment-related criteria, however, it has its particular weakness in method tailoring. The only other approaches that offer some enactment support are Demacrone and MERU. 2.3Summary In this chapter, we provided the necessary background for the remainder of the thesis. We explained software engineering methods, discussed their creation with situational method engineering, and presented an evaluation of the state of the art in assembly-based method engineering. Based on this foundation, we now present our solution for software engineering method management that specifically addresses the weaknesses of the other approaches. We start off with an overview of our solution in the following chapter. CHAPTER 3 Solution Overview In this chapter, we provide a general overview of our solution and an end-to-end example. Details will then be discussed in the following chapters. This chapter is structured as follows. We provide an overview of our solution for software engineering method management in Section 3.1and discuss MESP roles, work products, and tooling. In Section 3.2, we illustrate our solution with a running example. We conclude the chapter with a summary in Section 3.3. 3.1Overview of the MESP Approach 3.1.1Overview of MESP Roles 3.1.2Overview of MESP Work Products 3.1.3Overview of MESP Tools 3.1.4Integrated Overview of MESP Solution 3.2End-to-End Example 3.2.1Method Content Definition 3.2.2Method Tailoring 3.2.3Method Enactment 3.3Summary 3.1Overview of the MESP Approach Our evaluation presented in Section 2.2.2revealed that existing approaches do not fulfill the requirements for software engineering method management. More pre- 44 Solution Overview MESP Tool Support Standard BPEL Engine MESP Tool Method Repository Method Building Blocks Editor Method Composer Consistency Checker MESP2BPEL Transformer Workflow Engine Task Engine Repository Browser Standard Project Repository Project Repository Fig. 3.4Overview of MESP Tool Support 3.1Overview of the MESP Approach 45 MESP Solution Define Method Services & Method Patterns Characterize Project Compose Project-Specific Method Assure Quality of Method Perform TasksCoordinate Activities methods, best practices lessons learned reusable method content method services & method patterns project characterization project situation composed method flawed method correct method enactment experience scheduled workflow tasks Method Content Definition Method Tailoring Method Enactment Method Composer Task Engine Method Composer Consistency Checker Process Engine Building Block Editor roles, situational factors, tasks, categories Method Repository process model + GUI Senior Method Engineer Define Basic Method Elements & Basic Characterization Elements Building Block Editor Senior Method Engineer informal information flow formal information flow Project Method Engineer Project Method Engineer Initialize Method MESP2BPEL Transformer Project Method Engineer Project Method Engineer Project Team Project Team Reflect Method BPEL Engine Project Team Responsible Role Extract Reusable Method Content Senior Method Engineer reusable method content method services & method patterns External Tool MESP Tool Activity buildingblock needs partly method method Project Repository Project Repository performed workflow tasks partly method services & method patterns BPEL Engine Fig. 3.5An Overview of the MESP Solution Framework 46 Solution Overview poses a project-specific method and stores it into the method repository. Thereby, she can use the consistency checker to assure the quality of the method. Once the method model is consistent, she can initialize the method model for execution. She derives a process model with the MESP2BPEL Transformer, deploys it to the BPEL engine and assigns project members to roles. On the method enactment layer, the process engine executes the process model and helps the project team to coordinate their activities. The task engine manages the performance of tasks and shows the responsible team members the task descriptions from the method model. After the project team reflects the method enactment and collects lessons learned, using the process execution information from the BPEL engine and the created work products from the project repository. 3.2End-to-End Example In the following, we provide an end-to-end example to illustrate our overall solution and in particular the tasks that we introduced in the previous section. Our example is a project from the eID domain as we described in [Faz+13] and deals with the introduction of a distributed ePassport system. Such a system is connected to several national (e.g. border control, civil register) and international (e.g. Interpol) databases and information systems. Typically such a system is developed using a plan-driven approach, either a fixed off-the-shelf method or by creating a method using configuration-based SME, e.g., V-Modell XT [HH08]. The project manager of such projects is typically a passport domain expert and not an experienced method engineer. Thus, when changes to a method are required, she is not able to tailor the method accordingly. One requirement might for example be to integrate agile aspects into the method to allow for stepwise refinement of the work products and to improve the communication among team members. The method has to be tailored such that it integrates meaningful agile aspects and still stays consistent. In addition, also its correct enactment has to be ensured. Using this scenario, we provide an end-to-end example for the use of MESP in order to illustrate the benefits of our solution. We will briefly exemplify each MESP task in the context of the scenario. We also describe the relationship between work products and tools of each layer. 3.2.1Method Content Definition In the following, we illustrate the tasks of the senior method engineer to define reusable method content. As described, these tasks are carried out independently of individual projects as an ongoing, long-term effort to maintain a repository of up-to-date method services and method patterns. In our scenario, the senior 3.2End-to-End Example 47 method engineer has to derive method content that is suitable to carry out eID projects with differing levels of customer involvement and system criticality. Extract Reusable Method Content With this task, the senior method engineer identifies and extracts reusable method content from literature and practice. This is a first step towards the formalization by creating new method services and method patterns. In the eID domain, projects are typically carried out with plan-driven methods following the v-model. Now agile aspects shall be incorporated to allow for stepwise refinement of work products. If possible, concrete guidance on how to refine these work products shall be given. In our example, the senior method engineer extracts content from the documented methods V-Modell XT, Scrum, and OpenUP to cover these requirements. V-Modell XT The senior method engineer investigates the V-Modell XT as a software engineering method framework that creates plan-driven methods based on the v-model. Figure 3.6illustrates the control flow of a V-Modell XT-based method that is denoted by its lifecycle. Each decision gate (left leaning parallelogram) marks the end of a lifecycle phase. At each decision gate, a set of documents has to be approved using a defined task “Project coming to a progress decision”. For example, Figure 3.7shows the documents that have to be approved for the decision gate System Designed. Consequently, these documents have to be produced with the designated V-Modell XT tasks before the decision gate can be passed. Thus, in methods based on V-Model XT, the sequence of decision gates indirectly specifies the order of activities that have to be performed. Requirements Specified Request for Proposal Released Offer Submitted Contract Awarded Acceptance Completed System Specified System Designed Detail Design Completed System Elements Realized System Integrated Delivery Conducted Fig. 3.6The gateways of the V-Modell XT method System Designed :System Architecture :Logistic Support Specification Fig. 3.7The decision gate "System designed" of V-Modell XT The first four decision gates include activities to determine the requirements of the system (decision gate: Requirements Specified), issue a tender (Request 48 Solution Overview for Proposal Released), receive offers (Offer Submitted), and select a supplier for the development of the system (Contract Awarded). The system is then specified according to the requirements specification (System Specified) and decomposed into components and subcomponents (System Designed, Detail Design Completed). Based on the design documents, the subcomponents are integrated to components (System Elements Realized) and components to the complete system (System Integrated). Finally, the system is integrated into the production environment (Delivery Conducted). Once the system is in place, it is tested and approved (Acceptance Completed). Due to the popularity of the v-model in the eID domain, the coverage of the complete project lifecycle, and the systematic development and sign-off of formal documents, the senior method engineer decides to extract the V-Model XT lifecycle with its decision gates. In addition, she decides to extract the related tasks and work products. Scrum In order to identify agile method content, the senior method engineer investigates the popular Scrum method [SS13]. Scrum is an iterative and incremental method, where the development is carried out in iterations of fixed length called sprint. Figure 3.8illustrates the control flow of Scrum. A sprint basically prescribes a sequence of fixed length, where planning activities are followed by implementation activities, which in turn are followed by reviewing activities. The implementation activities are repeated daily until the end of the sprint and coordinated with informal, short meetings in the morning called daily scrum. Product Backlog Sprint Backlog Potentially Shippable Software Sprint Daily Fig. 3.8Illustration of the process flow of Scrum Due to the popularity of Scrum, its iterative and incremental nature, and its informal coordination meetings, the senior method engineer decides to extract the Scrum sprint loop. In addition, she decides to extract the related tasks and work products. OpenUP In order to identify further helpful task descriptions that can be used in an iterative, incremental setting, the senior method engineer investigates the 3.2End-to-End Example 49 OpenUp 7 method. Among other tasks, she extracts the tasks to envision and refine a system architecture that she considers useful. Figure 3.9shows an excerpt of the task refine the architecture from its specification website. Glossary Feedback About Print WhereamI TreeSets Team IntroductiontoOpenUP GettingStarted DeliveryProcesses Practices Roles WorkProducts Tasks Architecture RefinetheArchitecture EnvisiontheArchitecture Deployment Development Environment ProjectManagement Requirements Test Guidance Tools ReleaseInfo 6. Manage 7. Home ThispageiscurrentlybeingmodifiedbyGioneideAndrade Tasks>Architecture>RefinetheArchitecture Task:RefinetheArchitecture  Refinethearchitecturetoanappropriatelevelofdetailtosupport development. Disciplines:Architecture ExpandAllSections  CollapseAllSections Purpose Tomakeanddocumentthearchitecturaldecisionsnecessarytosupportdevelopment. Backtotop Relationships MainDescription Thistaskbuildsupontheoutlinedarchitectureandmakesconcreteandunambiguous architecturaldecisionstosupportdevelopment.Ittakesintoaccountanydesignand implementationworkproductsthathavebeendevelopedsofar.Inotherwords,the architectureevolvesasthesolutionisdesignedandimplemented,andthearchitecture documentationisupdatedtoreflectanychangesmadeduringdevelopment.Thisisa key,sincetheactualimplementationistheonlyreal"proof"thatthesoftwarearchitecture isviableandprovidesthedefinitivebasisforvalidatingthesuitabilityofthearchitecture. Formoreinformation,seeConcept:ExecutableArchitecture. Theresultsarecapturedforfuturereferenceandarecommunicatedacrosstheteam. Backtotop Steps ExpandAllSteps CollapseAllSteps Refinethearchitecturalgoalsandarchitecturallysignificantrequirements Identifyarchitecturallysignificantdesignelements Fig. 3.9Decription of the task "refine the architecture" of OpenUP The MESP task Extract Reusable Method Content is carried out informally and without tool support as it is the preparation of formalizing method content. Define Basic Elements With this MESP task, the senior method engineer defines basic elements that are shared by method services,method patterns, and method models. There are two kinds of basic elements. Basic method elements are work products, roles and tasks. They are used to define the constituents of method services and they are also referenced 7http://epf.eclipse.org/wikis/openup/ 50 Solution Overview in method patterns. Basic characterization elements are situational factor values and categories. They are used to characterize method services, method patterns and projects (and thereby the method to be composed). Figure 3.10 shows an UML object diagram that illustrates some basic elements and their relationships that were defined for the method content extracted for V-Modell XT, Scrum, and OpenUP in our scenario. We explain how they were derived in the following. Prepare System Specification:Task - Description: string = The Decision Ga... System Architecture: Work Product Hold Standup Meeting:Task - Description: string = The Standup Mee... Architect:Role Define the Architecture:Task - Description: string = This task focus... Refine The Architecture:Task - Description: string = This task build... Team Lead:Role Architecture Notebook: Work Product Customer_Involvement.low: Situational Factor Value Customer_Involvement.medium: Situational Factor Value Customer_Involvement.high: Situational Factor Value System_Criticalityt.low: Situational Factor Value System_Criticalityt.medium: Situational Factor Value System_Criticalityt.high: Situational Factor Value Agile:Category Plan-Driven:Category Development:Category Design:Category Planing:Category Fig. 3.10 Basic elements created by the senior method engineer Basic Method Elements Regarding basic method elements, for example, the senior method engineer defines the task Prepare System Specification and the work product System Architecture for the extracted V-Modell XT decision gate shown in Figure 3.7. The required information is given explicitly in the V-Modell XT specification document. Instead of directly taking over the terminology used in V-Modell XT, she adopts it to fit to the existing basic elements in the method repository. Thus, instead of defining a role System Architect , she defines the role Architect that is also responsible for tasks derived from OpenUP. The V-Modell XT decision gate also defines tasks, roles, and work products for the logistic support. However, the senior method engineer sees no use for them right now and does not add them. For the content from Scrum, she creates the task Hold Standup Meeting that reflects the daily scrum meeting of Scrum. Again, she rephrases the terminology. 3.2End-to-End Example 51 As responsible role for the task, she defines a Team Lead role that did not exist yet. It is an adoption of the role Team that is described in the Scrum specification document. For the content from OpenUP, she creates the tasks Define the Architecture and Refine the Architecture , as well as the work product Architecture Notebook. Here, she can reuse the already defined role Architect. Basic Characterization Elements Regarding basic characterization elements, situational factor values determine, in which context a method building block should be included in the method and in which context not. These are usually not stated explicitly in the extracted method content and need to be derived based on secondary literature (e.g. [Bek+08] or [CO12]) and project experience. For example, the senior method engineer in our scenario defines the situational factor Customer_Involvement as she learns that in Scrum a lot of customer involvement is required, while in V-Modell XT it is required only selectively at some of the decision gates. She defines the three situational factor values Customer_Involvement.low , Customer_Involvement.medium , and Customer_Involvement.high . Situational factor values will be used later to characterize whether customer feedback can be given frequently in a project and whether it is required by a method building block. Another situational factor the senior method engineer defines is the System_Criticality as she knows that for critical systems certain plan-driven tasks are required, while they might be unsuitable for uncritical systems. Here, she defines the situational factor values System_Criticality.low , System_Critical- ity.medium, and System_Criticality.high. Categories are an additional means to characterize method building blocks independent of a project situation, for example by origin, discipline, or typical phase. This is used to describe useful method services for a method pattern. In our scenario, the senior requirements engineer for example creates the categories Agile , Plan-Driven , Development , Design , and Planning based on the method content she extracted. The basic elements define the formal terminology that is used to describe method services, method patterns, and methods. They therefore influence which method services and method patterns are interoperable. The MESP task Define Basic Elements is supported with tooling. Basic elements are created with the Method Building Block Editor and stored in the Method Repository. The Method Building Block Editor offers checks to ensure that the modeled elements are specified correctly and adhere to the MESP meta-model. Define Method Services & Method Patterns With this MESP task, the senior method engineer defines the reusable method building blocks that can be used to tailor project-specific method models. In our 52 Solution Overview scenario, based on the extracted method content and the basic elements, she creates method services and method patterns for V-Modell XT, Scrum, and OpenUP. Method Services In our scenario, the senior method engineer first creates a method service for the task refine the architecture from OpenUP. For this, she reuses the respective task element that she created, as described in the previous section. The method service wraps the task and associates it with suitable basic characterization elements that help to discover and compose it. For example, this method service shall be used in methods, where the system to be developed is somewhat critical (medium – high), otherwise it bears unnecessary overhead. In addition, it is suitable, if there is a certain level of customer involvement planned in the project (medium), as decisions need to be supported by the customer. If there a lot of customer involvement is available, however, the method service is less suitable than other (agile) alternatives. Figure 3.11 shows an UML object diagram of the created method service. It references several basic elements from the method repository that were defined before. As basic method elements, it references the task, with its role and its work products. As basic characterization elements, it references the situational factor values customer_involvement.medium , system_critical- ity.medium, and system_criticality.high. In a similar manner, the senior method engineer defines method services for the other tasks elements she created. Once she is done, she has created a set of method services to describe the necessary tasks for eID projects with different characteristics. Architect:RoleArchitecture Notebook: Work Product Refine The Architecture:Task - Description: string = This task build... Refine The Architecture: Method Service plan-driven:Category development:Category design:Category system_criticalityt.high: Situational Factor Value system_criticalityt.medium: Situational Factor Value customer_involvement.medium: Situational Factor Value +responsible +category +suitableFactor +suitableFactor +output +category +category +suitableFactor +referencedTarget +input Fig. 3.11 A method service derived from OpenUP referencing basic elements 3.2End-to-End Example 53 Method Patterns In addition to method services, the senior method engineer creates method patterns. For example, the senior method engineer wants to formalize the sprint from Scrum so that it can be used by project method engineers in their method models. As described previously, a sprint is mainly a time-boxed sequence where planning activities are followed by implementation activities, which in turn are followed by reviewing activities. If this was modeled with a method service, other method services could not be added into the Sprint during method composition. Thus, this would be very inflexible. So instead, the senior method engineer models a method pattern as described in the following. She wants to model three groups of planning, development, and reviewing activities that are executed repeatedly. Figure 3.12 illustrates the method pattern that she creates. It consists of three sequential constrained scopes, one for each group of activities, which are executed inside a loop. Each constrained scope contains a constraint and space where method services can be put in later when the pattern is used. The space of a constrained scope has to fulfill the constraint. For example, the middle constrained scope requires that all method services placed inside are of category development and that there is one method service that is the method service Hold Standup Meeting. Constraints are expressed with a specialized domain specific language created for MESP that we describe in more detail in Chapter 4. Like method services, method patterns are characterized with basic elements. This method pattern is associated with the situational factor values Customer_In- volvement.medium and Customer_Involvement.high as the customer is involved in the planning that takes place fairly often. In addition, it is associated with System_Criticality.low and System_Criticality.medium , because it is very challenging to apply the pattern to create correct critical systems [SA07]. The pattern is furthermore associated with the category Agile. Figure 3.13 shows an UML object diagram that illustrates the relationship between the method pattern and the basic elements in the method repository. As shown, the constraints are not expressed in plain natural language, but reference the according elements in the method repository. For example, the constraint in the middle constrained scope references the category Development and the method service Hold Standup Meeting. The senior method engineer also creates a pattern that represents the decision gates defined by V-Modell XT. It can be used by project method engineers to ensure that the method model they compose includes all tasks in order prescribed by the decision gates. Similar to the sprint loop method pattern, it consists of a sequence of constrained scopes that contain constraints. The resulting method pattern contains a constrained scope for each decision gate as illustrated in Figure 3.14. We use the decision gate System Designed of Figure 3.6as an example to show, how a constrained scope is derived. The resulting constrained scopes are illustrated 60 Solution Overview partially composed method model for the ePassport project. As the method services Hold Standup Meeting,Refine the Architecture, and Prepare System Specification are associated with the category Development and the method service Hold Standup Meeting was added, the constraint of the Develop constrained scope is fulfilled. By adding further method patterns and method services, Alice composes the method step by step until all output work products required by the project goal are created by methods services and all constraints of the used method patterns are fulfilled. Thereby, she composes a method model that is specific to the context of her ePassport project. Sequence Exists a MS Has Output [System Architecture] Iteration And All MS [Development] Of Category [Hold Stanup Meeting] Exists a MS That Is All MS [Review.] Of Cat. Exists a MS [Planning] Of Cat. Specification Plan Develop Review Hold Standup Meeting Refine the Architecture Envision the Architecture Prepare System Specification Method Service Fig. 3.20 A partial method model with method services Control Flow & Data Flow In order to compose a unambiguous method model, control and data flow information is added to the method model. For example, in Figure 3.20 is not clear, whether the three method services in the Develop constrained scope shall be enacted sequentially or in parallel. In addition, the data flow of work products is not specified, yet. If there were multiple method services with the same output, it would not be clear which input to take. Figure 3.21 shows a more advanced state of the method model composition. Here, Alice added additional control flow for the Develop constrained scope. The method service Hold Standup Meeting takes place repeatedly in parallel to the sequentially enacted method services. In addition, Alice specified the data flow between Envision the 3.2End-to-End Example 61 Architecture and Refine the Architecture. However, the method model is still not finished, as denoted by the . Sequence Exists a MS Has Output [System Architecture] Iteration And All MS [Development] Of Category [Hold Stanup Meeting] Exists a MS That Is All MS [Review.] Of Cat. Exists a MS [Planning] Of Cat. Specification Plan Develop Review Hold Standup Meeting Refine the Architecture Envision the Architecture Prepare System Specification Iteration Parallel Sequence Fig. 3.21 A partial method model with additional control and data flow The MESP task Compose Project-Specific Method is supported with tooling. The method model is composed with the Method Composer that allows adding method patterns and method services from the Method Repository and to specify additional control and data flow. Assure Quality of Method With this task, the project method engineer checks the composed method model for completeness and other quality characteristics. For example, she checks, whether all required input work products are provided for all method services and whether all method pattern constraints are fulfilled. The method model has to be free of certain quality issues in order to be executable with a process engine later during method enactment. For example, when Alice checks the partial method model in Figure 3.21 she finds out that the constraints for the constrained scopes Plan and Review are not fulfilled yet as indicated by the . To detect these and similar issues, Alice can use the quality analysis that we implemented as part of our tooling. In order to remove the issues, Alice searches for suitable method services and adds them to the method model. In some cases, this might require the refinement of the 62 Solution Overview project characterization. Thus, the tasks to characterize the project, compose the project-specific method, and to assure the quality of the method are carried out incrementally. Figure 3.22 shows the corrected partial method model. By adding the two method services Iteration Planning Meeting and Iteration Review Meeting and the data flow between them, all method patterns are fulfilled, and the data and control flow is specified. Sequence Exists a MS Has Output [System Architecture] Iteration And All MS [Development] Of Category [Hold Stanup Meeting] Exists a MS That Is All MS [Review.] Of Cat. Exists a MS [Planning] Of Cat. Specification Plan Develop Review Hold Standup Meeting Refine the Architecture Envision the Architecture Prepare System Specification Iteration Parallel Sequence Iteration Planning Meeting Iteration Review Meeting Fig. 3.22 A correctly specified partial method model After removing all issues from the method model, Alice has created a consistent method model for her ePassport project, where the method model combines method patterns and method services from V-Modell XT, Scrum, and OpenUP. The MESP task Assure Quality of Method is supported by an analysis component, as described. The Consistency Checker helps the project method engineer to detect and resolve quality issues in her method model. Initialize Method With this task, the project method engineer prepares the method for enactment by the project team. She derives a process model that can be executed with a standard BPEL/BPEL4People Engine and assigns project team members to roles used in the method. The process model contains only concepts of BPEL/BPEL4People, thus, each concept of the MESP method model has to be transformed appropriately. For example, each method service has to be transformed into an appropriate 3.2End-to-End Example 63 BPEL4People task for the team member, a HumanTask Invocation. We implemented this automated transformation as part of our tooling. In our scenario, after Alice finished the method model she invokes the automated transformation. The transformation creates the deployment file with the BPEL/BPEL4People process model and deploys it into the BPEL engine. Alice then uses the configuration interface of the BPEL engine to assign her team members to the roles used in the ePassport method. For example, she assigns the architect role to Bob and the team lead role to herself. Figure 3.23 shows a screenshot of the configuration interface of the BPEL engine. After the process model is deployed and the roles are assigned, Alice starts the process and enters the location URI of the requirements specification that is available at project start. The process model is then ready for execution. Management Console Help © 2008 - 2012 WSO2 Inc. All Rights Reserved. Configure Users and Roles Features Key Stores Logging Data Sources Service Discovery Transports Service Data Publishing Server Roles Multitenancy Add New Tenant View Tenants Home>Configure>Users and Roles User Management System User Store Change Password Signed-in as:[email protected] | Sign-out |Docs |About MainMonitor Configure Tools Users Roles Change My Password Fig. 3.23 Configuration Interface of the BPEL engine to set up users and roles The MESP task Initialize Method is supported by a transformation component, as described. The MESP2BPEL Transformer transforms the MESP method model to a BPEL/BPEL4People process model and deploys it to the Standard BPEL Engine, the execution environment of the process model. Work Products and Tools Figure 3.24 shows an UML class diagram that gives an overview of the relationship of the MESP work products for method tailoring. As explained, the project Characterization consists of the Project Goal that references required and provided work products and the Project Situation that references situational factor values. The project characterization is part of the MESP method model and can be seen as its interface as it describes inputs and outputs of the method and the nature of the project. The MESP Method references method patterns and method services from the project repository that are used in the method. The MESP method is transformed to a BPEL Process and especially BPEL4People HumanTask Invocations that are derived from the Method Services. 64 Solution Overview MESP Method Method Building Blocks Basic Method Element Method Pattern Method Service MESP Method Interface (Characterization) BPEL BPEL Process Human Task Invocation Basic Characterization Element Project Goal Project Situation references transformed to references references references transformed to Fig. 3.24 Relationship of the MESP Work Products for Method Tailoring Figure 3.25 shows an UML component diagram that gives an overview of the relationship of the MESP tools used to create the MESP work products for method tailoring. As explained, methods are composed with the Method Composer. Created methods are stored in the Method Repository. With the Consistency Checker, the project method engineer can analyze the quality of the composed methods and with the MESP2BPEL Transformer, she can transform MESP method models to BPEL/BPEL4People process models. These models can be deployed into a Standard BPEL Engine for their execution that supports the project team in enacting the method. 3.2.3Method Enactment In the following, we illustrate the tasks of the project team to enact the method as prescribed and to provide feedback for method content improvement. In our scenario, the project team, Alice, Bob and their colleagues have to enact the method defined specifically for their ePassport project. In addition to the tasks from the 3.2End-to-End Example 65 Standard BPEL Engine MESP Tool Method Repository Method Composer Consistency Checker MESP2BPEL Transformer Repository Browser Fig. 3.25 The MESP tools for Method Tailoring V-Modell XT that they are familiar with, the team has to carry out the novel tasks derived from Scrum and OpenUP. Coordinate Activities With this task, the project team coordinates what activities need to be carried out and what input work products to use. In particular, they have to ensure that they carry out the activities in the right order, that they notify each other when an activity is finished, and that they inform each other, where to find the output work products. The BPEL engine takes care of this task completely and coordinates the activities for the project team as illustrated in Figure 3.26. The BPEL engine executes the process model and whenever an activity is executed, it creates an appropriate workflow task (1). The assigned team member can access the workflow task via the BPEL engine (2) and mark it as finished, when it is done (3,4). Then, according to the control flow in the process model (5), the BPEL engine executes the following activity and creates a workflow task for it (6) and so on (7-10). In our scenario, Alice just finished her workflow task to host the Iteration Planning Meeting. According to the control flow of the method model (see Figure 3.22), the BPEL engine creates two workflow tasks, one for the method service Refine the Architecture and one for the method service Hold Standup Meeting. It assigns the first workflow task to Bob, as he is assigned the architect role. Once Bob performed his workflow task, the BPEL engine invokes the following method service Prepare System Specification and creates another workflow task for him. Once he finishes his workflow task and the iteration with Hold Standup Meeting is finished, the BPEL engine invokes the next activity Iteration Review Meeting. It creates the according workflow task and assigns it to Alice, who is assigned the team lead role. 66 Solution Overview Activity A (HumanTask Invocation) BPEL Process Workflow Task A Standard BPEL Engine Activity B (HumanTask Invocation) 12 3 4 5 10 Workflow Task B 6 9 … 7 8 Person 1 Person 2 Fig. 3.26 The coordination of activities via workflow tasks The MESP task Coordinate Activities is supported by the Standard BPEL Engine. As described, it executes the BPEL/BPEL4People process model and creates appropriate workflow tasks. Perform Tasks With this MESP task, members of the project team carry out the actual tasks defined within the method services of the method model. The responsible team member has to perform the task according to its description and by using the proper input work products. After finishing the task, the team member has to notify the teammates and inform them about the created output work products. Like the previous MESP task, this MESP task is also supported by the BPEL engine. As explained in the previous section, the BPEL engine creates appropriate workflow tasks for invoked activities. A project team member can access her due workflow tasks via the task engine that is part of the BPEL engine. As part of our automated transformation from MESP method models to BPEL/BPEL4People, each workflow task contains a description taken from the according task in the method repository. In addition, each workflow task shows the location URIs of the input work products and offers fields to enter the output work product URIs. It also shows general information about the state of the executed process, e.g., the number of the current iteration. As part of the standard task engine interface, the team member can mark a task as completed. The BPEL engine then invokes the following activity according to the control flow. In our scenario, Bob has to perform a workflow task for the method service Refine the Architecture. As shown in Figure 3.27, he is presented the description that corresponds to the original task description in the method repository (cf. Figure 3.9). 3.2End-to-End Example 67 He also sees the location of the input Architecture Notebook in the Redmine 8 ticket system that they the team uses as a project repository. After he uploaded his created output, he adds its URI to the workflow task. Once he marks his workflow task as finished, workflow tasks for the following activities will be created. So naturally, the MESP tasks to coordinate activities and to perform tasks alternate during method enactment. Details: <<_Back_to_Task_List Mon_Mar_g/_f,:A,:Aw_CET_gAf/ Mon_Mar_g/_fV:g-:Af_CET_gAf/ IN_PROGRESS Request: People: Bob To_make_and_document_the_architectural_decisions_necessary_to_support_developmentv Response: Complete Architecture_Notebook: Name Refine_the_Architecture Description This_task_builds_upon_the_outlined_architecture_and_makes_concrete_and_ unambiguous_architectural_decisions_to_support_developmentv_ It_takes_ into_account_any_design_and_implementation_work_products_that_have_ been_developed_so_farv_ In_other_wordsh_the_architecture_evolves_as_the_ solution_is_designed_and_implementedh_and_the_architecture_ documentation_is_updated_to_reflect_any_changes_made_during_ developmentv_ Role Architect Steps Refine_the_architectural_goals_and_significant_requirements_ Identify_architecturally_significant_design_elements_ Refine_architectural_mechanisms_ Define_development_architecture_and_test_architecture_ Validate_the_architecture_ Communicate_decisions_ Addv_Roles None Inputs Architecture Notebook_:_http:..redminevsylabvde.issues.fV_ Outputs Architecture Notebook Phase Development_Phase Iteration Development_Iteration:_f_ Description: Created On: Updated On: Status: Owner: Fig. 3.27 A workflow task for the method service Refine the Architecture The MESP task Perform Tasks is supported by the Standard BPEL Engine and a Standard Project Repository. The BPEL engine contains two components: the Task 8http://www.redmine.org/ 68 Solution Overview Engine manages the workflow tasks that are created by the Workflow Engine. The Worklfow Engine hosts and executes the process model. Reflect Method With this MESP task, the project team collects feedback about the method enactment in order to support the senior method engineer in improving method building blocks. The team might, for example, have feedback to improve the description of tasks or about the suitability of method services for their project. In our scenario, Alice and her team are not satisfied with their standup meetings. As they are not so familiar with agile practices yet, they hope for more tips and hints in the task description. They use the execution logs of the BPEL engine and the work products they created to illustrate their issues with the method to the senior method engineer. The MESP task Reflect Method is only indirectly supported with tooling. The BPEL engine tracks the execution of the method model, including the URIs for inputs and outputs. These can be found in the standard project repository. However, the actual findings are communicated informally to the senior method engineer. Work Products and Tools Figure 3.28 shows an UML class diagram that gives an overview of the relationship of the MESP work products discussed in this section. The BPEL Process model is executed within the BPEL engine that manages and logs Runtime Information about the state of execution. Whenever an HumanTask Invocation is executed, a Workflow Task is created and assigned to the person with the appropriate role. Figure 3.29 shows an UML component diagram that gives an overview of the relationship of the MESP tools used in the MESP tasks that were discussed in this section. The Standard BPEL Engine that executes the process model consists of two components. The Workflow Engine manages the state of the process model and the Task Engine manages the state of workflow tasks. The Workflow Engine instructs the Task Engine to create workflow tasks. The Task Engine in turn notifies the Workflow Engine about finished workflow tasks. The Project Repository is used to store the created work products within the project. The location of work products is referenced within workflow tasks. 3.3Summary In this chapter, we provided an overview of the tasks, roles, work products, and tools that are part of the Method Engineering with Method Services and Method Patterns (MESP) solution. We first explained the tasks and associated roles to 3.3Summary 69 Method Enactment Person BPEL BPEL Process Workflow Task Runtime Information Human Task Invocation creates captures assigned to captures Fig. 3.28 Relationship of the MESP Work Products for Method Enactment define method content, compose method models, and enact methods. We then presented the various work products that are created and used and discussed their relationship. We also explained what tools are used as part of our solution. Thereafter, we illustrated this with an end-to-end example from the eID domain. In the following chapters, we discuss the details of the method content definition, method tailoring, and method enactment with MESP. Standard BPEL Engine Workflow Engine Task Engine Standard Project Repository Project Repository Fig. 3.29 The MESP tools for Method Enactment 76 Method Content Definition Tasks of the Senior Method Engineer Method Content Definition Define Method Services & Method Patterns Define Basic Method Elements & Basic Characterization Elements Extract Reusable Method Content IndentifySources Indentifyand Asses Method Content Select and Extract Method Content Sources assessed method content reusable method content … Tasks of the Project Team Method Enactment Reflect Method … Informal information flow Control flow Responsible Role Activity lessons learned Fig. 4.1Extraction of method content from methods described in literature method content, e.g., based on lessons learned or missing method building blocks during method composition. In this case, the senior method engineer should identify and explicitly list all related problem areas and disciplines and then investigate them for related work as illustrated by [HLH02]. Related work can be collected by querying scientific databases, e.g., SpringerLink 9 , IEEExplore 10 , ACM Digital library 11 , Google scholar 12 or SCOPUS 13 . In order to perform a more directed and formal procedure, relevant literature can be identified using a structured literature review [KC07] as illustrated by [Sie15]. In the second case, there is no concrete need that needs to be addressed; however, the method repository shall be updated with the latest trends and best practices. In this case, the newest proceedings of national and international conferences or issues of journals concerned with software engineering methods can be reviewed, e.g., PROFES 14 , ICGSE 15 , and ICSSP 16 or TSE 17 , TOSEM 18 , and Journal of Software: Evolution and Process 19 . Searching for studies like [MW15],[KF15] that discuss the popularity and usage of software engineering methods is also a good approach. 9http://link.springer.com 10http://ieeexplore.ieee.org 11http://dl.acm.org 12http://scholar.google.com 13http://www.scopus.com 14http://www.profes-conferences.org 15http://www.icgse.org/ 16http://www.icsp-conferences.org 17http://www.computer.org/web/tse 18http://tosem.acm.org 19http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)2047-7481 4.2Extract Reusable Method Content 77 On the one hand, the identified work might present original work by the authors themselves that is worth disseminating directly. On the other hand, it might also discuss and reference other works, e.g., software engineering methods published as books [Eng08], industrial standards [ISO07], capability maturity models [Hoe08], or organizational patterns [CH05], which then serve as the source of method content that needs to be disseminated. Identify and Asses Method Content Especially, when many or extensive works are collected, it might be necessary to assess the contained method content to prioritize its dissemination. In the following, we explain a few heuristics that support the selection of suitable works. Appropriateness Is the work related to the created list of problem areas and disciplines? Is it related to currently defined method building blocks? Work discussing methods that relate to these areas are probably more worthy to disseminate. Granularity and Focus Is the work describing general-purpose methods or domain-specific methods? The first typically describe more generic tasks that are broadly applicable, but usually with less guidance and details. In addition, the terminology used is more generic. The latter typically provide specific descriptions and use a specialized terminology. Depending on the goals of the senior method engineer, content from general-purpose methods can fill gaps of missing method building blocks more easily, while content from domain-specific methods provides richer content for specific topics. Formality Is the description of methods based on a meta-model? Is it very structured, e.g., by applying templates repeatedly or by using many sections? Typically, the more structured the method is described, the easier it is to understand and extract content to formalize it later. Informal and unstructured descriptions of methods tend to be ambiguous and more difficult to prepare for extraction. If a description of method is based on a meta-model that is similar to the MESP meta-model then only little effort is necessary to extract and reuse method content. However, if the meta-models are dissimilar, then the effort needed may become as high as with unstructured method descriptions [Hen+14]. Similarity Is the work using a similar terminology, that is, does it use tasks, roles, and work products that are the same or close to those that are already in the method repository? If this is the case, then it is probably easier to extract method content. However, the benefit of the additional method content might be smaller as it represents similar ideas. 78 Method Content Definition Select and Extract Method Content When the method content is not based on a meta-model or one that is different to our meta-model, it might become difficult to define basic element and method building blocks right away, because many methods were not created to be modular [Ral04]. In addition, very extensive method descriptions are difficult to disseminate, if not done systematically. Thus, within this task method content is prepared for the definition based on our meta-model. Based on the assessment described in the previous section, method content is selected for further dissemination. For each described method or its part, the following steps are applied. As a first step, hierarchical and chronological concepts are identified. Examples are phases,stages,iterations,disciplines or decision gates. Often, these concepts are used to structure the method and therefore are good candidates to systematically break up the method as illustrated by [FLE13]. These orderings are also potential candidates to be later formalized with method patterns. As a second step, each of the identified concepts are decomposed further into groups of interconnected concepts. Examples for what we are looking for now are tasks,activities,task descriptions,events,roles,work products,states and artifacts. Important connections are for example containment,predecessor,successor,input of, output of,responsible for. The basic method elements used for these concepts and their relationships might be mentioned explicitly or only implicitly. In the latter case, the senior method engineer needs to identify them and make them explicit. In order to capture and document both kinds of concepts, based on our experience, natural language and semi-formal diagrams should be used, as it is often to difficult to formalize the concepts directly. However, if based on a similar meta-model, concepts can already be formalized by instantiation of basic method elements from our meta-model. As a last step, the terminology and situational factors mentioned in the method content are investigated. In order to define interoperable method building blocks, they must share the same base of basic method elements. As each method uses its own terminology, e.g., with respect to role or work products names, its terminology needs to be mapped to the one used in the method repository. This can be done by creating a mapping from the terms used in the method content to the names of basic method elements in the method repository. The mapping can be provided with a textual table. In order to define interoperable method building blocks, they must also share the same base of situational factors. In order to collect suitable situational factors, potential situational factors mentioned within the method descriptions should be listed in a textual table for later use. The senior method engineer should also reference identified concepts that are related to these situational factors according to the method description. 4.2Extract Reusable Method Content 79 After these steps, the senior method engineer has extracted reusable method content from methods described in literature. She can then formalize it by creating basic elements, method services, and method patterns. 4.2.2Extraction from the Daily Practice of Organizations Our approach to extract method content based on the daily practice of organizations consists of five tasks as illustrated by Figure 4.1. The first two task are enacted in parallel and lead to the task for the creation of method requirements. These first three tasks serve as the foundation of the following two tasks Process Enactment Feedback and Select and Extract Method Content. These two tasks are periodically carried out in order to continuously extend and refine the method repository based on the experience gained. In the following, we will discuss each task. Tasks of the Senior Method Engineer Method Content Definition Define Method Services & Method Patterns Define Basic Method Elements & Basic Characterization Elements Extract Reusable Method Content Analyze Existing Artifacts and Interview Experts Prioritize Goals with Management Create Method Requirements Select and Extract Method Content Process Enactment Feedback improvement potentials, project context strategic project goals method requirements reusable method content lessons learned … Tasks of the Project Team Method Enactment Reflect Method … refined method requirements Informal information flow Control flow Responsible Role Activity Fig. 4.2Extraction of method content from the daily practice of organizations Analyze Existing Artifacts and Interview Experts Before the senior method engineer can extract reusable method content from the daily practice of an organization, she needs to establish an overview of how software systems are created within that organization. Based on our experience [FCE14] and as proposed in [BR04], we propose to conduct interviews with project teams in order to capture the enacted method and its strengths and weaknesses. Relying solely on the documentation of methods results in less effort. However, there is the risk that it might not reflect the daily 80 Method Content Definition practice, when the method is typically not enacted according to its definition and both deviate from each other. In our opinion, interviews are a good trade-off between the effort for the analysis and the quality of the results. If desired, other approaches can be used, e.g., collaborative workshops [FR15] or apprenticing [AW05] that might cause more effort, but also give different results. In order to prepare the interviews, we propose to analyze existing artifacts related to the software engineering method. These are work products created within software projects, e.g., requirement specifications or design documents, but also method descriptions that describe the method or parts of it, e.g., task descriptions, document templates, or checklists. Based on the analysis, the senior method engineer can already postulate characteristics of the method, possible weaknesses, and strengths. One weakness might be that documentation for the implementation is incomplete for some projects. With the results of the analysis, the senior method engineer can then prepare the interviews with the project teams. She prepares questions in order to back up or refute the analysis results. The interviews should be representative such that with the involved project team members all roles, tasks, work products, and most situations should be covered. We propose to have the interviews with two interviewers and two interviewees as this provides second opinions when discussing the questions (interviewees) and later the results (interviewers). The questions should cover weaknesses and strengths regarding all parts of the software engineering method: activities, work products, roles, tools, the process, and the flow of information. They should also cover the method description with its provided guidances. Another important aspect are situational factors. The questions should assess, e.g., what situational factors are differentiated explicitly (e.g. local and global software projects) and what situational factors have influence on the used method, e.g., by affecting the performed tasks or used tools. One result might be that in the past global software projects, often project team members had differing expectations regarding the required documentation of the implementation. The results of artifacts analysis and expert interviews are used to derive method requirements and to extract method content in the following tasks. Prioritize Goals with Management A software engineering method is used by a project team to create a software system in a software project. While the project team has the primary goal of creating that software system within time and budget, the management of the organization pursues middle and long term goals. These might require mandatory activities within a method that are not primarily beneficial for that same project, but of strategically interest of the organization. One example might be the long-term maintainability of the software systems. 4.2Extract Reusable Method Content 81 In order to identify and consider these strategic method improvement goals, the senior method engineer should carry out workshops with the stakeholders that are responsible for the software projects. She can propose strategic method improvement goals based on the results of the interviews to initiate the discussion. Once a set of goals is identified, goals have to be prioritized with the managers, e.g., by letting each of them distribute a smaller amount of priority points among the goals. The prioritized strategic method improvement goals are used to derive method requirements in the following task. Create Method Requirements Especially, when not all aspects of the software engineering methods can be addressed at once, it is necessary to prioritize among them. Similar to [RR01], we therefore propose the use of method requirements to make the goals of method content extraction more transparent and to prioritize them with the stakeholders. Method requirements describe what needs to be ensured by methods, e.g., that the project team discusses the mutual expectations at project start or that certain tools are used. Thereby, method requirements provide guidance on what method content to extract (first). The senior method engineer proposes method requirements based on both, the results of the expert interviews and the prioritized strategic method improvement goals. As with the strategic method improvement goals, she then should carry out workshops with the stakeholders that are responsible for the software projects and discuss the method requirements. Once a set of method requirements is identified, it has to be prioritized by the managers, e.g., by letting them each distribute a smaller amount of priority points among the requirements. The prioritized method requirements are used as the basis to select and extract method content in the following task. Select and Extract Method Content With this task, method content is prepared to be formalized within the following tasks. The goal is to iteratively select and extract method content from the daily practice within the organization based on the initial set of method requirements and the refinements from the method enactment. Weaknesses in the existing methods are addressed by additionally disseminating method content from methods described in literature. Based on the prioritized method requirements, the senior method engineer selects and extracts method content from the daily practice of the organization. Similar to the initial analysis she can investigate artifacts and interview project teams to do this. The goal is to capture concepts that are perceived as being successful 82 Method Content Definition and proven by the project teams and that address the method requirements. If method requirements cannot be addressed by the daily practice of the project teams, the methods described in literature are investigated (see Section 4.2.1) for solutions. As before, the senior method engineer documents tasks, task descriptions, the process, roles, work products, guidances (tools, templates, checklists), and associated situational factors. For example, the method requirement for the project team to discuss the mutual expectations at project start could be fulfilled by a mandatory kick-off workshop, where these are discussed and documented. Based on the experience, this might be mandatory only for global software projects. Based on our experience, natural language and semi-formal diagrams should be used to capture the extracted method content and reference existing method descriptions as formalizing the concepts directly is often to difficult. By using an online document that is accessible via browsers, stakeholders can easily feedback the extracted method content and the senior method engineer can iteratively refine it. If the organization already uses a method model based on a meta-model similar to our meta-model, concepts can already be formalized by instantiation of basic method elements from our meta-model. Once feedback from method enactment is available it is used to refine the method requirements within the task Process Enactment Feedback. Similar to the initial set of method requirements these are used to select and extract method content from the daily practice of the organization and, if required, method requirements. As described in Section 4.2.1, the terminology and the situational factors need to be investigated and prepared, e.g., using textual tables. However, when extracting method content from the daily practice within the same organization typically it is more homogenous and does not require special preparation. After this step, the senior method engineer has extracted reusable method content from the daily practice of organizations. She can then formalize it by creating basic elements, method services, and method patterns. Process Enactment Feedback With this task, the senior method engineer uses the feedback from method enactment to check the fulfillment of method requirements and to possibly refine them. This ensures that the defined method building blocks fulfill the actual requirements and helps to maintain the transparency for the stakeholders of software projects. Based on the lessons learned of the project teams, the senior method engineer checks whether the method requirements were fulfilled and whether additional method requirements are necessary. She marks method requirements as fulfilled, e.g., when former weaknesses are successful mitigated. She adds additional and refined method requirements, if the lessons learned indicate that this is necessary. One example might be that although mutual expectations are discussed and documented at project start, the documentation for the implementation is still 4.3Define Basic Elements 83 incomplete for some projects. Then a refined method requirement might be to review the documentation of the implementation at the end of an iteration. After this step, the senior method engineer starts another iteration of method content extraction with the task Select and Extract Method Content. 4.3Define Basic Elements In this section, we discuss how our solution addresses the establishment of a common, updatable terminology (MDR2) and characterization (MDR3) of method building blocks. To fulfill these requirements, we need to define meta-classes than can be used to formalize the available terminology and characterization. These basic elements serve as a common frame of reference as all defined method building blocks will based on them. With respect to terminology-related basic method elements, several works discuss and present software engineering method meta-models. In [ES10], the authors present the meta-model of their creation-based situational method engineering approach MetaME and relate its meta-classes to the meta-classes of other popular approaches. In [Spi15], MetaME is extended to support continuous software method improvement. One of the first comprehensive software engineering method meta-models is OPEN [FH02]. Another comprehensive meta-model is provided by the software engineering method framework V-Modell XT that is prescribed for projects with the German government [KTF11], but a purely German standard with little international attention [KFS13b]. Standardization efforts resulted in two standards. First, the Software Engineering Metamodel for Development Methodologies known as the ISO/IEC 24744 International Standard [ISO07] and, second, Software & Systems Process Engineering Meta-Model Version 2.0[OMG08]. While the first has gained no impact and practical relevance, the latter has gained attention from industry and research [KFS13b]. With respect to characterization of method building blocks, many works discuss relevant situational factors for situational method engineering, however only few approaches consider a formalization. In [Bek+08], the authors propose a set of 27 situational factors identified as relevant for software product management. In [CO12] the authors consolidate related research into an initial reference framework of 44 situational factors and additional sub-factors affecting situational method engineering. Situational method engineerings approaches often use fixed sets of key-value pairs to formalize situational factors [Pli96],[Har97],[KDS07] or do omit an explicit characterization [RDR],[KLR96],[Ell+11]. In the following, we explain the basic elements of our software engineering method meta-model. Following the structure of or software engineering method meta-model illustrated in Figure 4.3, we first discuss basic method elements and 84 Method Content Definition show, how they are used to formalize terminology. Thereafter, we discuss basic characterization elements used to model situational aspects. Basic Method Elements Basic Characterization Elements Method Building Blocks Fig. 4.3Excerpt of package structure of MESP meta-model 4.3.1Definition of Basic Method Elements The basic method elements of our software engineering method meta-model are defined in reference to the tool implementation of SPEM, the EPF Composer 20 , for the following three reasons. First, SPEM is the most widespread software engineering method meta-model and it allows defining and updating method related terminology (MDR2). Second, with the EPF Composer there is tool support and an implementation of the meta-model for the popular development platform Eclipse available. Third, a large library of method content formalized with the EPF Composer is publicly available. As illustrated by Figure 4.4, SPEM separates reusable method content from its application in processes (methods). Thus, it differentiates between method content meta-classes and process meta-classes. Method content describes, e.g., tasks, roles, and work products that can be used in potentially many different processes, which reference this method content. Guidances can be defined with respect to both, method content and processes. As the process part is not relevant to our basic method elements, in the following, we focus on the method content of SPEM. As illustrated in Figure 4.4, to define method content in SPEM the meta-classes Task Definition , Step , Work Product Definition , Role Definition , and Guidance are used. Additionally and not shown in the figure, Task Definitions can associate a list of Qualifications instances that documents the qualifications required for the performance of a task. In addition, Task Definitions can associate a list of Tool Definitions that can be used to support the task. 20http://eclipse.org/epf/ 4.3Define Basic Elements 85 Method Content Process Task Definition Role Definition Work Product Definition Guidance Role Use Task Use Work Product Use Step references references references Fig. 4.4 Illustration of division between Method Content and Process in SPEM (adopted from [OMG08]) For our solution, we adopted the method content meta-classes of SPEM’s implementation, the EPF Composer. Thus, details slightly deviate from the SPEM standard. As we adopted only parts of the meta-model, we also simplified the structure of the meta-model by omitting abstract meta-classes and moving their relationships and attributes to the inheriting meta-classes. Meta-Classes In this section, we discuss the basic method element meta-classes of our MESP meta-model that are illustrated in Figure 4.5and were adopted from SPEM. Task Task is based on the SPEM Task Definition meta-class. It represents work being performed by Roles and it is associated with input and output Work Products . Inputs are differentiated in mandatory versus optional inputs. A Task must have a single Role that is responsible for it during method enactment and can have additional Roles that are associated as additional performers. A Task can recommend a specific set of Tools to be used to support the Task . It can also provide a list of Qualifications that the task typically requires to be performed versus optional inputs. A Task must have a single Role that is responsible for it during method enactment and can have additional Roles that are associated as additional performers. A Task can recommend a specific set of Tools to be used to support the Task . It can also provide a list of Qualifications that the task typically requires to be performed by one or more Roles and this list can be mapped against the provided Qualification list defined for Role . As illustrated, 92 Method Content Definition [Cau10]. However, beside the conceptualization, we require a formalization and executable notion of method services for our solution for software engineering method management. Especially, our method services have to fulfill the stated requirements MDR5, MDR6, and MDR7. In order to allow for the definition of executable method services that reflect both atomic and composite activities (MDR5), we use a variation of the composite pattern [Gam+07] in our meta-model and embed a process within each method service. This process is then comprised of a single reference to a task (atomic activity) or a flow of method service references (composite activity). Following the principles of other approaches based on method services, our method service comprises two parts, interfaces and a process. The interfaces describe the information necessary during method composition (MDR6), while the process part contains the operationalization of the method service. Both, the interfaces and the process part are designed to reuse basic elements instead of duplicating them in order to support consistency (MDR7). Meta-Classes In this section, we discuss the method service related meta-classes of our MESP meta-model as illustrated in Figure 4.8. MethodService MethodService is the main method building block of our approach. It represents the composable notion of work, both an atomic task or a flow of composed method services. MethodService contains two interfaces to describe its suitability with respect to situations and other method services. It also contains an executable Process with the actual description of work – the tasks that need to be performed. This process is the same meta-class that is used within method models (see Section 5.3.2). It references method services and tasks via TaskDescriptors and MethodServiceDescriptors to denote that they are executed as part of the process and thus, as part of the method service (control and data flow meta-classes used in a process are omitted in Figure 4.8). As illustrated, MethodService contains several attributes that allow giving it a name, its description, and to describe its purpose. CharacterizationInterface CharacterizationInterface characterizes the suitability with respect to a situation by referencing suitable and unsuitable situational factor values. In addition, it references suitable category values. StructuralInterface StructuralInterface characterizes the technical interoperability with respect to work products and roles. It describes the work products that are optionally or mandatory required in order to work properly and the work 4.4Define Method Services & Method Patterns 93 MethodService - name: String - briefDescription: String - purpose: String - mainDescription: String CharacterizationInterface StructuralInterface methodElements::Process methodElements::Role - name: String - briefDescription: String - purpose: String - mainDescription: String methodElements:: WorkProduct - name: String - briefDescription: String - purpose: String - mainDescription: String characterizationElements:: SituationalFactorValue - name: String - mainDescription: String characterizationElements:: CategoryValue - name: String - mainDescription: String methodElements::Activity - name: String - mainDescription: String methodElements:: TaskDescriptor - name: String methodElements:: MethodServiceDescriptor - name: String methodElements::Task - name: String - briefDescription: String - purpose: String - mainDescription: String methodElements:: AtomicActivity 1 0..* performedBy 0..* targetService 1 0..* optionalInput 0..* 1 1 0..* mandatoryInput 0..* 0..* excludedFactors 0..* 0..* includedFactors 0..* 1 0..* mandatoryOutput 0..* 0..* additionallyPerformedBy 0..* 0..* targetTask 1 0..* includedFactors 0..* Fig. 4.8 The method service related meta-classes of our meta-model package MethodService products that are produced. It also describes the roles that are used within the characterized unit, e.g., a method service. Usage With our formalization of method services, we enable the modeling of atomic and composite activities as the process of a method service can reference a single task or a complex flow of method services. Thus, the senior method engineer can summarize several tasks to more coarse-grained, executable, and composable units of work. Figure 4.9shows a refined illustration of the method service derived from OpenUP as shown in 3.11. As illustrated, both parts of the method service, the interface part and the process part, reuse basic elements to express the usage of work products, roles, and tasks as well as situational factor values and category values. 94 Method Content Definition Refine The Architecture: MethodService Refine The Architecture: Task :StructuralInterface :Process :TaskDescriptor:Sequence Development: CategoryValue Plan-driven: CategoryValue Design: CategoryValue System_Criticality.medium: SituationalFactorValue System_Criticality.high: SituationalFactorValue Customer_Involvement.medium: SituationalFactorValue :CharacterizationInterface ArchitectureNotebook: WorkProduct Architect: Role includedFactors performedBy includedCategories includedCategories targetTask includedFactors mandatoryOutput mandatoryInput includedCategories includedFactors Fig. 4.9A method service derived from OpenUP 4.4.2Definition of Method Patterns The second type of method building block in our solution is the method pattern that follows the pattern-based ideas as described by [TR07]. Our method patterns need to describe abstract orderings (MDR4) and thus abstract from concrete method services. However, while patterns are typically described informally, we need sufficient formalization of these patterns in order to help project method engineers to model executable method models and to precisely evaluate their fulfillment during the quality assurance of method tailoring. Thus, our notion of patterns goes beyond formalizations as presented in [DS98]. Our method patterns contain scopes that are connected by executable control flow and where each scope contains a constraint. A method pattern is successfully implemented in a method model, when all constraints are fulfilled. Constraints are defined with a Domain Specific Language (DSL), such that senior method engineers does not have to use low-level modeling, while constraints can still be evaluated automatically. In addition, our method services have to fulfill the stated requirements MDR6and MDR7. Meta-Classes In this section, we discuss the method pattern related meta-classes of our MESP meta-model. The main meta-classes are illustrated in Figure 4.10. The abstract syntax of the DSL to model constraints is also defined within the MESP meta-model. 4.4Define Method Services & Method Patterns 95 The related meta-classes are illustrated in Figure 4.11, Figure 4.12, and Figure 4.13 and will also be described in the following. MethodPattern - name: String - briefDescription: String - purpose: String - mainDescription: String serviceElements:: CharacterizationInterface ConstrainedScope - name: String - briefDescription: String - purpose: String - mainDescription: String methodElements:: ActivityWithActivity Condition - name: String - mainDescription: String methodElements::Activity - name: String - mainDescription: String characterizationElements: :CategoryValue - name: String - mainDescription: String characterizationElements: :SituationalFactorValue - name: String - mainDescription: String 0..* excludedFactors 0..* 0..1 0..* includedCategories 0..* 1 0..* includedFactors 0..* Fig. 4.10 The method pattern related meta-classes of our meta-model package MethodPattern MethodPattern MethodPattern is the second type of method building block of our approach. It represents abstract orderings of groups of method services, where these groups are paraphrased by constraints that need to be fulfilled by using the right method services. A MethodPattern contains a ConstrainedScope that represents the actual pattern content and a CharacterizationInterface that characterizes the suitability of the method pattern (see Section 4.4.1). As illustrated, MethodPattern contains several attributes that allow giving it a name, its description, and to describe its purpose. In particular, the mainDescription attribute can be used to describe intent, problem, context, and forces with natural language, as known form pattern descriptions like in [CS95]. ConstrainedScope ConstrainedScope represents the content of a method pattern. It consists of its content and a Condition that this content needs to fulfill. A control flow either can host an empty control flow element like a sequence or further constrained scopes connected by control flow. Thus, a ConstrainedScope can host a complex structure of constrained scopes. 96 Method Content Definition As illustrated, ConstrainedScope contains several attributes that allow giving it a name, its description, and to describe its purpose. Condition Condition formalizes the constraint of a ConstrainedScope that needs to be fulfilled by the method service descriptors used within a Constrained- Scope . The constraint is expressed with the DSL created for the usage by senior method engineers illustrated in the Figures 4.11–4.13. As illustrated, Condition contains attributes to give it a name and a description. Condition - name: String - mainDescription: String SingleConditionOrCondition AndCondition Expression - quantifier: Quantifier «enumeration» Quantifier AllFulFill AtLeastOneFulfills NoneFulfills MethodObjectCharacterization ServiceCharacterization WorkProductCharacterization leftCondition rightConditionrightCondition leftCondition Fig. 4.11 The condition related meta-classes of our meta-model package patternElements OrCondition As illustrated in Figure 4.11, OrCondition is one of the three kinds of conditions. It consists of two conditions, where at least one must be fulfilled in order for the OrCondition to be fulfilled. AndCondition AndCondition is the second of the three kinds of conditions. It consists of two conditions that both must be fulfilled in order for the AndCondition to be fulfilled. 4.4Define Method Services & Method Patterns 97 SingleCondition SingleCondition is the third of the three kinds of conditions. It consists of an expression that is either fulfilled or not fulfilled by the ConstrainedScope that hosts the SingleCondition. Expression Expression represents an expression about one or more method services or work products that is fulfilled or not. It contains a MethodObjectCharacterization that characterizes method services or method patterns. In addition, it has a quantifier that denotes that the MethodObjectCharacterization has to be true for all (AllFulfill), at least one (AtLeastOneFulfills), or no (NoneFulfills) method service or work product in order for the expression to be fulfilled. MethodObjectCharacterization MethodObjectCharacterization represents a characterization of one or more method services ( ServiceCharacterization ) or work products (WorkProductCharacterization) that is fulfilled or not. MethodServiceCharacterization MethodServiceCharacterization represents a characterization of one or more method services. The related meta-classes are illustrated in Figure 4.12. WorkProductCharacterization WorkProductCharacterization represents a characterization of one or more work products. The related meta-classes are illustrated in Figure 4.13. OrServiceCharacterization As illustrated in Figure 4.12, OrServiceCharacterization is one of the three kinds of service characterizations. It consists of two service characterizations, where at least one must be fulfilled in order for the OrServiceCharacterization to be fulfilled. AndServiceCharacterization AndServiceCharacterization is the second of the three kinds of service characterizations. It consists of two service characterizations that both must be fulfilled in order for the AndServiceCharacterization to be fulfilled. SingleServiceCharacterization SingleServiceCharacterization is the third of the three kinds of service characterizations. It consists of a ServiceIdentificationConstraint that characterizes method services. ServiceIdentificationConstraint ServiceIdentificationConstraint characterizes method services by identity, category, or usage of work products. 98 Method Content Definition «enumeration» OwningModifier Has HasNot «enumeration» IdentityModifier Is IsNot «enumeration» DataDirectionModifier AsInput AsOutput ServiceCharacterization WorkProductCharacterization OrServiceCharacterization SingleServiceCharacterization AndServiceCharacterization ServiceIdentificationConstraint ServiceIdentificationByIdentity - identityModifier: IdentityModifier ServiceIdentificationByCategory - owningModifier: OwningModifier ServiceIdentificationByWorkProduct - owningModifier: OwningModifier - dataDirection: DataDirectionModifier serviceElements::MethodService - name: String - briefDescription: String - purpose: String - mainDescription: String characterizationElements:: CategoryValue - name: String - mainDescription: String 0..* methodService 1 rightCharacterization rightCharacterization 0 categoryValue 1 leftCharacterization leftCharacterization Fig. 4.12 The service characterization related meta-classes of our meta-model package patternElements 4.4Define Method Services & Method Patterns 99 ServiceIdentificationByIdentity ServiceIdentificationByIdentity characterizes method services by identity. It references a method service and requires that one or more method service descriptors for that method service are present or not present, depending on the identityModifier being set to Is or IsNot, respectively. ServiceIdentificationByCategory ServiceIdentificationByCategory characterizes method services by their associated category. It requires that one or more method service descriptors that reference method services with that category are present or not present, depending on the identityModifier being set to Is or IsNot, respectively. ServiceIdentificationByWorkProduct ServiceIdentificationByWorkProduct characterizes method services by their usage of work products. It requires that one or more method service descriptors use a specific work product are present or not present, depending on the identityModifier being set to Is or IsNot, respectively. With the attribute owningModifier it is set whether the work product has to be used as input (AsInput) or output (AsOutput). Instead of specifying a work product directly, the work product is described with the contained WorkProductCharacterization as this is more flexible. OrWorkProductCharacterization As illustrated in Figure 4.13, OrWorkProduct- Characterization is one of the three kinds of work product characterizations. It consists of two work product characterizations, where at least one must be fulfilled in order for the OrWorkProductCharacterization to be fulfilled. AndWorkProductCharacterization AndWorkProductCharacterization is the second of the three kinds of work product characterizations. It consists of two work product characterizations that both must be fulfilled in order for the AndWorkProductCharacterization to be fulfilled. SingleWorkProductCharacterization SingleWorkProductCharacterization is the third of the three kinds of service characterizations. It consists of a WorkProductIdentificationConstraint that characterizes method services. WorkProductIdentificationConstraint WorkProductIdentificationConstraint characterizes work products by identity and their usage by method services. WorkProductIdentificationByIdentity WorkProductIdentificationByIdentity characterizes work products by identity. It references a work product and requires 100 Method Content Definition ServiceCharacterization WorkProductCharacterization OrWorkProductCharacterization AndWorkProductCharacterization SingleWorkProductCharacterization WorkProductIndentificationConstraint WorkProductIndentificationByIdentity - identityModifier: IdentityModifier WorkProductIndentificationByUse - usedAsModifier: DataDirectionModifier methodElements::WorkProduct - name: String - briefDescription: String - purpose: String - mainDescription: String leftCharacterization leftCharacterization 0..* workProduct 1 rightCharacterization rightCharacterization Fig. 4.13 The work product characterization related meta-classes of our meta-model package patternElements 4.5Summary 101 that it is used or not, depending on the identityModifier being set to Is or IsNot, respectively. WorkProductIdentificationByUse WorkProductIdentificationByUse characterizes work products by their usage within method services. Depending on the usedAsModifier attribute, it requires that work products are used as input (AsInput) or output (AsOutput) of specific method services. Instead of specifying a method service directly, the method service is described with a ServiceCharacterization as it is more flexible. Usage With our formalization of method patterns, we enable the modeling of abstract orderings with varying levels of complexity and with a high-level modeling language. Figure 4.14 shows the object model for the method pattern derived from Scrum that is illustrated in Figure 3.12. This method pattern is more complex and contains three constrained scopes within a sequence. Our formalization allows defining method patterns that are independent of concrete method services and that can be precisely evaluated for their fulfillment during the quality assurance of composed method models. The constraints in the figure characterize method services mostly by category values. Only the method service Hold Standup Meeting is referenced directly. This example also shows that method patterns reuse basic elements to express the usage of work products, situational factor values, and category values. 4.5Summary In this chapter, we presented the details of the method content definition with our approach that fulfills the MDRs explained in Section 4.1. In particular, we contributed two ways to extract reusable method content (MDR1), first, by extraction from methods described in literature, and second, by extraction from the daily practice of organizations. We then explained the formalization of basic elements, of basic method elements (MDR2) and basic characterization elements (MDR3). Thereafter, we showed how method services are formalized, our main type of method building blocks that is a reusable, compositional, interoperable, and executable unit of method based on the service-oriented paradigm (MDR5,MDR6). Furthermore, we explained the formalization of method patterns, our second type of method building block that captures abstract orderings of activities as a guidance for the project method engineer (MDR4). We showed, that both, the method service and the method pattern is formalized based on reusing existing meta-classes in order to support consistency (MDR7). 108 Method Tailoring 5.1.2Related Work Regarding the project characteristics, many approaches discuss the use of situational factors and associated values, e.g., [HV97], [NH03] and [KDS07], similar to the characterization of method building blocks. In [GGH08], the authors discuss a slightly different idea by considering so-called method goals. However, in these approaches have in common that the situation is determined by selecting one of the provided values for each attribute in a list. Regarding the identification of suitable method building blocks, most toolsupported approaches only offer facilities to browse the method repository manually for suitable method building blocks, e.g., [KLR96],[Cer+11],[Ell+11] and only few approaches offer additional support, e.g., by a textual query language [BSH01]. Proposals that go beyond that involve the use of similarity measures and backward chaining of activities based on the required output work products [GH08]. Regarding the formalization of method models only few assembly-based method engineering approaches allow modeling methods that are executable, e.g., Demacrone [Har97] and MENTOR [SRG96],[Pli96]. More recently proposed standard meta-models like SEMDM and SPEM lack support for executability. Extensions to these standards that enhance them for executability exist, e.g., [Ben+07] and eSPEM [Ell+10; Ell+11], however, they lack support for assembly-based method engineering. Regarding the analysis of method models for quality issues, there is no accepted and standardized notion of quality for software engineering method models. Only few works discuss measurable and quantifiable notions of quality and propose well-formedness rules or quality constraints, e.g., [Har97; BSH98], [Chr00], and [Per+11]. Regarding the initialization of method models for enactment, some approaches focus on creating documentation for the method to be used by the project team, e.g., EPF Composer, IBM Rational Method Composer, and MC Sandbox [KÅ11; KÅ12], while others derive a suitable Computer-aided software engineering (CASE) environment [PS97], [KLR96], [Cer+11]. Only few approaches discuss execution support, either supported natively by build-in execution support [Har97], [SRG96; Pli96], [Ell+10; Ell+11], or by a mapping to an executable process description language with process engine support [Ben+07]. 5.2Characterize Project In this section, we discuss how our solution addresses the formalization of project characteristics to support the search for method building blocks (MTR1). In the following, we first discuss related work and then explain our formalization. 5.2Characterize Project 109 The role of project characteristics and their formalization is discussed for example in [HV97]. Here the author proposes to determine the situation by assessing situational factors of the project. These should then be used to query for suitable method building blocks. However, a solution is not proposed. In [NH03], the authors discuss tool support for the OPEN approach [FH02] and propose the use of a set of situational factors and associated values. They list a first set of 16 situational factors, e.g., domain and product size and propose that these can best be elicited using a questionnaire. In [KDS07], the authors extend the assembly-based approach first proposed in [RR01] with the assessment of project characteristics. They also propose the use of situational factors and associated values. They discuss the four dimensions organizational,human,application domain, and development strategy, where each dimension contains several situational factors and their possible values. Related work specifically on situational factors, i.e., [Bek+08] and [CO12], is discussed in Section 4.3. In [GGH08], the authors discuss a slightly different idea by considering so-called method goals, e.g., product reliability or project time constraints, and then assign each method building block values that expresses its contribution, e.g., enhances or deteriorates. They propose the use of goal analysis (e.g. [Bre+04]) to find the best combination of method building blocks with respect to the prioritized method goals. However, they only explain how to determine the better of two sets of method building blocks, not how to come up with the set in the first place. In the following, we explain the formalization of the project characteristics with our software engineering method meta-model and then illustrate its usage. 5.2.1Meta-Classes In this section, we discuss the meta-classes of our MESP meta-model used to formalize the project characteristics as illustrated in Figure 5.1. ProjectMethod ProjectMethod represents the method model throughout its composition and contains all other method model related elements. Thus, the formalization of the project characteristics is modeled to be part of ProjectMethod : it contains a ProjectGoal and a ProjectSituation . In addition, ProjectMethod contains attributes that allow giving it a name and descriptions. ProjectGoal ProjectGoal is one of the two meta-classes that is used in our approach to formalize the project characteristics. Our notion of project goal differs from the goals used in [GGH08] as there the focus was on prioritizing among different qualities when choosing a set of method building blocks. However, our project goal captures what needs to be produced by the method in the project and what input is available at project start to do that. Thus, it is associated with input and output Work Products . It also associates the Roles that perform work 110 Method Tailoring ProjectMethod - name: String - briefDescription: String - mainDescription: String ProjectSituation - briefDescription: String - mainDescription: String ProjectGoal - briefDescription: String - purpose: String - mainDescription: String Role - name: String - briefDescription: String - purpose: String - mainDescription: String WorkProduct - name: String - briefDescription: String - purpose: String - mainDescription: String CharacterizationInterface CategoryValue - name: String - mainDescription: String SituationalFactorValue - name: String - mainDescription: String 0..* includedCategories 0..* 0..* mandatoryOutput 1..* 0..* includedFactors 0..* 0..* performedBy 1..* 0..* mandatoryInput 0..* 0..* excludedFactors 0..* Fig. 5.1 The project characteristics related meta-classes of our meta-model package Project- Method in the method model. While roles might not always be relevant as a requirement for project composition, the list of involved roles is helpful after the method is composed, for example during method initialization. ProjectGoal has attributes that allow giving it a descriptions and to explain the purpose of the method model. ProjectCharacterization ProjectCharacterization is the second of the two meta-classes that is used in our approach to formalize the project characteristics. It expresses the situation by sets of situational factor values and characterization values following the same idea as other approaches discussed in related work. The associations are established by inheritance from the meta-class CharacterizationInterface . In addition, ProjectCharacterization has attributes that allow giving a textual description of the situation. 5.2.2Usage Our formalization of the project characteristics allows us to capture textual descriptions of the project goal and the project characterization. More importantly, it allows us to formally associate work products, roles, situational factor values, and characterization values as we illustrated with Figure 3.18. The formal description eases the search for suitable method building blocks, but also benefits the quality assurance and initialization of the composed method model. While many approaches propose a fixed list of possible work products or situational factor values, our 5.3Compose Project-Specific Method 111 solution allows the senior method engineer to add new basic elements and the project method engineers to directly use them during project characterization. 5.3Compose Project-Specific Method In this section, we discuss how suitable method building blocks are identified with our solution and how they are composed to executable method models (MTR3) including support for combined patterns (MTR2). Regarding the identification of suitable method building blocks, many toolsupported approaches only allow manually browsing the method repository, e.g., [KLR96], [Cer+11],[Ell+11]. The tool Demacrone [Har97] additionally offers the textual query language MEL [BSH01] that is similar to SQL and allows querying for method building blocks that fulfill certain criteria, e.g., SELECT X Which PRODUCES Object Model and PARTICIPATION_TYPE = Much user participation . The tool MENTOR [SRG96; Pli96] also supports the identification of suitable method building blocks by presenting a list of candidate building blocks based on the situation and the context of a task. In [RR01], four generic strategies for the selection of method building blocks are discussed. The evaluation strategy describes the approach, where the degree of matching between the candidate method building block to the project characteristics is used. This can be calculated using similarity measures as also described in [MR06]. The decomposition strategy can be used, if a method building block is a composite building block. It proposes to deselect building block parts that are not required to fulfill the current requirements, i.e., the project characteristics. The aggregation strategy proposes to look for composite building blocks that contain the candidate building block, if it does not fulfill the requirements fully. The refinement strategy proposes to look for a different building block that also fulfills the requirements, but offers richer content, e.g., by having more guidances. In [GH08], the authors propose to create a method model by backward chaining the activities that produce the required output. Thus, based on the final work product of the method, the activities that produce these work products are identified and added as predecessors. Then for the required input work products of these predecessors, suitable activities are searched and added. This is done recursively until activities are added, where the required input work products are available at project start. Regarding the formalization of method models, only few assembly-based method engineering approaches allow modeling methods that are executable. Demacrone [Har97] and MENTOR [SRG96],[Pli96] support the creation of executable method models that are composed of method building blocks. However, both are based on outdated, proprietary technology, low-level specification languages and low-level (e.g. character-based) user interfaces. More recently proposed standard meta-models for software engineering methods like SEMDM and SPEM 112 Method Tailoring lack execution tool support (SEMDM) or execution support in general (SPEM). Bendraou et al. [Ben+07] and Ellner et al. [Ell+10; Ell+11] propose extensions to SPEM to address SPEMs lack of executability. Bendraou et al. propose xSPEM and present ideas to map it to BPEL in order to provide enactment support and sketch some mappings between concepts of xSPEM and BPEL [Ben+07]. They discuss that BPEL4People could be used to allow for human interaction, however no details are given. Also, assembly-based method engineering is not addressed. Ellner et al. developed eSPEM [Ell+10] and provide tooling based on the Eclipse ecosystem to model and execute software engineering methods [Ell+11]. However, situational method engineering support is very limited as method building blocks and the project cannot be characterized. Other approaches focus explicitly and solely on the provision of executable method models and corresponding process engines, however, neglecting situational method engineering. Based on the idea of process programs [Ost87], in [Wis+00] software engineering methods are described with Little-JIL, a language for programming the coordination of agents. As this language and the provided tool support focus on the coordination of tasks, the actual enactment of tasks is left to the agents and descriptions and guidances for tasks are not supported. In the following, we discuss how the project method engineer identifies suitable method building blocks for her project-specific method. Thereafter, we explain the formalization of method model compositions with our software engineering method meta-model and then illustrate its usage. 5.3.1Identifying Suitable Method Building Blocks Our approach to identify suitable method building blocks consists of three steps that are performed in parallel and represent three strategies to identify suitable method building blocks. While two are known from related work, one is based on our novel notion of method patterns. In the following, we will discuss each step. Identify based on Characterization In our approach, the project situation is characterized with the same situational factor values and category values that are used to characterize method services and method patterns. Therefore, suitable method building blocks can be identified using an evaluation strategy [RR01], i.e., based on the similarity of situational factor values and category values between the project situation and the characterization interface of building blocks. For example, if the project situation includes the situational factor customer_involvement.medium then method building blocks with customer_involvement.medium among their involved factors can be identified. Part of this step is also to refine the project situation based on the amount of matching method building blocks. To reduce the number of matching method 5.3Compose Project-Specific Method 113 building blocks, additional situational factors could be considered. For example, additionally taking into account the system criticality into the project situation with adding system_criticality.medium could reduce the number of matching method building blocks. On the contrary, if the search for method building blocks does not render sufficient results, the project characterization can be relaxed by reducing the number of situational factors (e.g. by removing system_criticality.medium) or by adding situational factor values that relax this condition, e.g., by adding criticality.low. Identify based on Work Products In our approach, the project goal is characterized with input and output work products and the roles to be involved via the method model. In addition, each method service describes the input and output work products and responsible role as part of its structural interface. Following the idea proposed in [GH08], suitable method building blocks can thus be identified by their provided output work products based on the currently needed work products. For example, when integration test results are required as an output of the method, the project method engineer can check the method repository for method services that provide that output. This strategy is not limited to the required output work products of the method, but can be used also to add method services that create the output work products needed as input by method services used in the method model. We propose additionally using the provided input work products that are available at project start to identify method services that process them towards the output work products. For example, if a requirements specification is provided at project start or created by a method service in the method model, the method service Create Test Cases could be added, as it uses a requirement specification as input. While it might turn out that this identified method service is not useful to progress towards the required outputs of the method model, this strategy can help to identify useful method services. It is not limited to the provided inputs at project start, but can be used also to add method services that consume an work product that is created by method services used in the method model. Identify based on Method Pattern Constraints As our solution for software engineering method management introduces the notion of method patterns, we propose a third strategy to identify suitable method building blocks. Method patterns used in the method model are fulfilled, when the condition of all of their constraint scopes is fulfilled. These conditions describe the necessity for the presence or absence of method services based on their identity (specifically named), associated category values, or processed or produced work products. Therefore, useful method services can be identified by searching for 114 Method Tailoring method services that fulfill the conditions. For example, the first constrained scope shown in Figure 3.15 is fulfilled with a method service that has a system architecture as its output work product. Consequently, the method service Prepare System Specification can be identified and a corresponding method service descriptor ca be added to the method model. 5.3.2Specification of Methods As SPEM is the most widespread software engineering method meta-model with available tool-support, we used it as the foundation for our basic method elements. However, as SPEM lacks execution-support and support for our method services and method patterns, we cannot use it or extensions like eSPEM [Ell+10] to model composed method models that are executable. Therefore, we introduce our own composition language to describe composed, executable method models, however, we rely on the two standards SPEM and BPEL. SPEM is the de facto standard for software engineering methods, however without support for executability. BPEL is one of the two de facto standard executable process description languages with broad and mature tool support, however without support for the typical terminology of software engineering methods and with a textual and very technical specification language. Our terminology is influenced by the Process-related classes of SPEM (cf. Figure 4.4), while we adopted the structure of BPEL processes. Similar to the idea of xSPEM [Ben+07], we provide a mapping of our language to BPEL to give it execution semantics. However, our approach goes beyond xSPEM, as we also support data flow and GUIs for the project team members. Hence, we also rely on BPEL4People. Our formalization of method models allows specifying executable compositions of method building blocks with deterministic control and data flow. The formalization is based on the scalable well-formed structure of BPEL process models, but allows the project method engineer to use a high-level language with the typical software engineering method related terminology. Meta-Classes In this section, we discuss the method-composition related meta-classes of our MESP meta-model that are adopted from SPEM and BPEL. Figure 5.2illustrates the control-flow related meta-classes of our meta-model, while Figure 5.3illustrates the data-flow related meta-classes. Some associations are omitted for better readability. Activity An Activity represents a general unit of work within a Process . It is sub-typed either to describe elemental steps of the process behavior or to describe deterministic control-flow logic. Therefore, Activity follows BPEL’s notion rather than the notion of activity in SPEM. In SPEM, activities group other elements only in terms of breakdown structures. As illustrated, Activity contains attributes that 5.3Compose Project-Specific Method 115 AtomicActivity - startDate: string - finishDate: string Activity - name: String - mainDescription: String - duration: string ActivityWithActivity DataHandlingActivity MethodServiceDescriptor Process Sequence DataHandlingActivity TaskDescriptor Flow Phase Iteration If ElseHumanDecision - mainDescription: String ActivityWithActivities Role - name: String - briefDescription: String - purpose: String - mainDescription: String ConstrainedScopeDescriptor MethodPatternDescriptor ConstrainedScope - name: String - briefDescription: String - purpose: String - mainDescription: String MethodPattern - name: String - briefDescription: String - purpose: String - mainDescription: String 1..* {ordered} methodPattern constrainedScope decider 1 0..1 1 Fig. 5.2 The control-flow related method elements of our meta-model package Project- Method allow giving it a name and a textual description. In addition, similar to planning data in SPEM, a duration can be given as an exact recommended duration or a ratio. AtomicActivity AtomicActivity inherits from Activity and represents an elemental step of the process behavior as it is sub-typed by MethodServiceDescriptor and TaskDescriptor . As illustrated, AtomicActivity contains attributes that allow giving it a planned start and finish date similar to planning data in SPEM. MethodServiceDescriptor MethodServiceDescriptor represents the use of a method service within a specific point in the control flow of a process, either the 116 Method Tailoring process of a method model or the process of a method service that represents a composite activity. The use of MethodServiceDescriptor as a proxy element within a process resembles the usage of Task and Task Use within SPEM. TaskDescriptor TaskDescriptor represents the use of a task within a specific point in the control flow of a process, either the process of a method model or the process of a method service. Typically, task descriptors are meant and should be used for the latter, as tasks do not have an interface description as opposed to method services. The use of TaskDescriptor as a proxy element within a process resembles the usage of Task and Task Use within SPEM. ActivityWithActivities ActivityWithActivities inherits from Activity and represents deterministic control-flow logic that specifies how the contained activities are executed. For this purpose, it is sub-typed by Sequence and Flow. Sequence Sequence contains one or more activities that are performed sequentially, in the lexical order of their containment within the Sequence element, following the semantics of BPEL. The Sequence completes when the last activity in the sequence has completed. If the HumanDecision of an activity evaluates to false then it is skipped and also considered completed. Flow Flow contains one or more activities that are performed in parallel, following the semantics of BPEL. Thus, a flow enables concurrency. The Flow completes when all of the activities within the flow have completed. If the HumanDecision of an activity evaluates to false then it is skipped and also considered completed. Thus, a flow also enables synchronization. ActivityWithActivity ActivityWithActivity inherits from Activity and is sub-typed by activities that can contain only one activity. These describe either deterministic control-flow logic that specifies how the contained activity is executed (i.e. Iteration , If , and Else ), add semantic structure to the process (i.e. Phase ), or describe the usage of method patterns. If multiple activities should be placed within an ActivityWithActivity then an ActivityWithActivities has to be used to specify their control-flow order. Iteration Iteration inherits from ActivityWithActivity . Adopting the definition in SPEM, it represents an important structuring element to organize work in repetitive cycles. In addition, Iteration follows the execution semantics of RepeatUntil in BPEL and provides for repeated execution of a contained activity. The contained activity is executed until its contained HumanDecision evaluates to 5.3Compose Project-Specific Method 117 false. The HumanDecision is tested after each execution of the body of the iteration. The iteration executes the contained activity at least once. If, Else If inherits from ActivityWithActivity and follows the execution semantics of BPEL. It provides conditional behavior. The activity consists of one conditional branch defined by the If element, followed by an optional Else element. If the HumanDecision of the If evaluates to true, the branch is taken, and its contained activity is performed. Otherwise, the Else branch is taken, if present. The If activity is completed, when the contained activity of the selected branch completes, or immediately, when the HumanDecision evaluates to false and no Else branch is specified. HumanDecision HumanDecision represents a Boolean decision that has to be taken by a project team member and that decides whether a certain activity is executed or not. The group of people that is requested to take the decision is determined by the referenced role. HumanDecision has an attribute that allows providing textual background for the decision. Phase Phase inherits from ActivityWithActivity . Adopting the definition in SPEM, it represents a significant period in a project, typically ending with activities that represent an major management checkpoint or produce a set of major work products. A Phase completes when its contained activity has completed. MethodPatternDescriptor MethodPatternDescriptor represents the use of a method pattern within a specific point in the control flow of a process. It has an association to the method pattern that it represents. While method services can be represented with atomic activities, a MethodPatternDescriptor has to allow the method engineer to specify what method service descriptors shall be used within the contained constrained scopes. Thus, similar to MethodPattern , a MethodPatternDescriptor is an ActivityWithActivity . It should contain the same structure as the content of the corresponding method pattern; however, for every constrained scope of the method pattern it has to contain a corresponding ConstrainedScopeDescriptor that represents a reference to it. Our formalization also allows combining two method service descriptors by nesting the one into the other. The use of MethodPatternDescriptor as a proxy element within a process resembles the usage of Task and Task Use within SPEM. ConstrainedScopeDescriptor ConstrainedScopeDescriptor represents the use of a constrained scope of a method pattern within a specific point in the control flow of a process. It has an association to the constrained scope that it represents and 124 Method Tailoring In [RB96], the authors propose to assess different methods based on their metamodels. They focus on the modeling of work products in different methods. Based on their meta-models (modeling languages), they propose different metrics based on the number of objects, attributes, and relationships to measure the complexity of a language. In a similar manner, in his PhD thesis [Har97] and in a following publication [BSH98], Harmsen discusses five quality characteristics, e.g., completeness and consistency, in the context of method models composed with Demacrone. He formalizes them with first order logic based on the set-based formalization of methods used in Demacrone. We use this set of quality characteristics as a foundation for our quality model and formalization. Following this line of thought, in [Chr00] the author describes a generalized meta-model for methods and postulates five well-formedness rules that should be fulfilled by method models, e.g., that for all work products there should exist a source (a producing activity) and a sink (a consuming activity). However, she does not categorize these rules with respect to a quality model. In an attempt to enable the check of method models for their conformance to CMMI, the authors in [Hsu+08] propose a UML-based approach to define, verify, and validate method models. They define rules formalized with the Object Constraint Language (OCL) for their validation, e.g., to express that a WorkPractice (activity) is performed by exactly one ProcessPerformer (role). As our formalization of quality characteristics is also based on OCL, this work is related to ours. However, the focus in [Hsu+08] is on the conformance to CMMI of method models modeled with an UML-based approach and it does not offer a quality model for method models. Related to the work in [Hsu+08] is eSPEM, using OCL in a SPEM-based approach. The authors of eSPEM claim that they implemented consistency rules based on OCL in their meta-model, however, details are not presented in the paper [Ell+11]. In [Per+11], the authors advocate the check of method models before enactment and propose well-formedness rules for SPEM in order to ensure the consistency of SPEM-based method models. On the one hand, the authors redefine the cardinality of some of the defined relationships of meta-classes, e.g., such that each TaskUse (activity) is associated to at least one ProcessPerformer (role). For more elaborated well-formedness rules the authors use first-order predicate logic, e.g., to ensure that work products are produced before they are consumed. The approach discussed in this paper is very closely related to our approach to formalize the quality of method models, but they do not discuss a possible implementation of their rules. In addition, the authors provide a list of low-level rules, but do not group or structure their well-formedness rules with respect to a quality model. Furthermore, their rules are limited to SPEM, which we had to extend due to its lack of executability. 5.4Assure Quality of Method 125 In the following, we first present our quality model for method models that we derived based on the related work. We then present our concept for the automated quality analysis. Thereafter, we illustrate the usage of the automated quality analysis. 5.4.1Quality Model As explained, a quality model is a set of quality characteristics that can be further divided into sub-characteristics and eventually quality attributes, where quality attributes are measurable properties of an object [ISO01]. As we did not find a suitable quality model for the quality assurance of method models, we define our own quality model. In the following, we first present our quality model and then discuss it with respect to evaluation criteria for quality models. The Quality Model of MESP The quality model that we propose is inspired by the quality model of the ISO/IEC 9126 standard for software product quality [ISO01] and based on the related work in the field of SME. In the following, we describe and discuss the hierarchical structure of our quality model that is visualized in Figure 5.7. The general structure of our quality model is the following. The overall method model quality consists of three parts: • Situation-independent and critical quality • situation-independent and non-critical quality • situation-dependent and non-critical quality Each of these parts is refined into quality characteristics, which in turn are refined into quality sub-characteristics. Omitted in the figure are quality attributes. They are used to measure quality sub-characteristics. Situation-Independent and Situation-Dependent Quality Quality characteristics can be classified based on whether their assessment is affected by the project situation. If they are, we call them situation-dependent. Otherwise, they are situationindependent. Critical and Non-Critical Quality Quality characteristics can be classified based on their importance for the executability of the method model. If quality characteristics must be fully fulfilled in order to preserve the executability of a method model, we call them critical. Otherwise, we call them non-critical. 126 Method Tailoring Software Engineering Method Model Quality Situation- Independent & Critical Quality Completeness Reference Completeness Input/Output Completeness Attribute Completeness Pattern Descriptor Completeness Consistency Precedence Consistency Input/Output Consistency Situation- Independent & Non- Critical Quality Efficiency Work Product Efficiency Control Flow Efficiency Soundness Method Pattern Fulfillment Maintainability Method Pattern Coverage Modularity Situation- Dependent, Non- Critical Quality Applicability Level of Abstraction Understandability Suitability Situational Factor Compliance Quality Characteristic Quality Sub- Characteristic Quality Fig. 5.7MESP’s quality model for software engineering method models 5.4Assure Quality of Method 127 Completeness Completeness is fulfilled, if all required objects, attributes, and associations of a method model are defined. As missing elements can lead to cases, where the method model is not executable, independent of situational factor values, it is a situation-independent and critical quality characteristic. We define completeness based on the quality characteristic with the same name defined in [Har97], where it requires that all method fragments referenced within a method model are existing and included. Completeness is refined into the quality sub-characteristics reference completeness, input/output completeness,attribute completeness, and method pattern completeness. Reference completeness is fulfilled, if all mandatory associations as defined in the meta-model from objects contained within a method model to objects within the method repository exist. The meta-classes that can cause a violation of the reference completeness are task descriptors, method service descriptors, activity input mappings, method pattern descriptors, constrained scope descriptors, and project goals. Thus, the counts of their missing associations serve as quality attributes for reference completeness. Input/output completeness is fulfilled, if the two following conditions are met. First, each activity within a method model that requires input work products contains the corresponding activity input mapping that specifies from where the input is coming. Second, for each output work product specified in the project goal of a method model the project goal must contain an activity output mapping that specifies from which activity the output is coming. Thus, the quality attributes are, first, the counts of missing activity input mappings for task descriptors and method service descriptors based on the mandatory input work products of the respective task or method service, and second, the counts of activity output mappings that are missing or that are missing mandatory associations based on the specified output work products in the project goal. As a stricter sub-characteristic of input/output completeness, we define the conditional input/output completeness that additionally takes into account, whether the source activity of the input work product is conditionally executed, thus might not produce the required input. This is the case, when the source activity is contained by an if, else if, or else activity ca and the consuming activity is not contained within the same ca. Conditional input/output completeness is fulfilled, if input/output completeness is fulfilled for all possible conditional control flows, ignoring activities that would not be executed. Attribute completeness is fulfilled, if all mandatory attributes as defined in the meta-model are defined for objects contained within a method model. These mandatory attributes are the name of the project method, the name of an atomic activity, and the main description of a human decision. The count of missing mandatory attributes serves as quality attribute. Pattern descriptor completeness is fulfilled, if each method pattern descriptor mpd in the method model has the same structure as the method pattern mp that it 128 Method Tailoring references. This means that for every activity ain the containment hierarchy of mp there is a corresponding activity ca in the containment hierarchy of mpd. In addition, if an activity ehas another activity ae in its containment hierarchy then the corresponding activity ca of ehas to have a corresponding activity to ae in its containment hierarchy. A corresponding activity ce is an object of the same type that represents eand has the same attribute values. An exception are constrained scopes, where the corresponding activity for a constrained scope cs is a constrained scope descriptor that references cs. From pattern descriptor completeness follows method pattern consistency and vice versa. Thus, we did not list it as a separate quality sub-characteristic. It means that the structure of method pattern descriptors and thus the control flow containment relationship between constrained scope descriptors corresponds to the relationship given by the method pattern and its constrained scopes. The count of missing corresponding activities serves as quality attribute for pattern descriptor completeness. Consistency Consistency is fulfilled, if the method model does not contain contradictions. Contradictions can lead to cases where the method model is not executable, independent of situational factor values; therefore, it is a situation-independent and critical quality characteristic. We define consistency based on the quality characteristic with the same name defined in [Har97], where it requires that elements and their relationships within a method model do not contain any contradictions and thus are mutually consistent. Consistency is refined into the quality sub-characteristics precedence consistency and input/output consistency.Precedence consistency is fulfilled, if for each data handling activity (cf. 5.3.2) that requires an input, the source of this input is a predecessor data handling activity or the input is already available initially at project start. This means that a source of an activity input mapping must be a predecessor, with respect to the control flow, of the data handling activity that contains the activity input mapping or it must be the data flow interface, hence the project goal. The quality attribute is the count of method service descriptors and task descriptors that have activity input mappings that do not fulfill this. Input/output consistency is fulfilled, if the type of the data flow in the method model corresponds to the interface specification of tasks and method services in the method repository or the work products specified in the interface (project goal) of the method model. This means that for each activity input mapping ip with a referenced work product wp two conditions must be fulfilled. First, the data handling activity that contains ip has to reference a method service or task in the method repository that has wp among its input work products. Second, if the input provider that is referenced as source of ip is a data handling activity, it has to reference a method service or task in the method repository that has wp among its output work products, otherwise, it has to be a data flow interface (e.g. 5.4Assure Quality of Method 129 project goal) that specifies the work product wp as an input available at project start. Similarly, for each activity output mapping op with a referenced work product wp the source data handling activity needs to reference a method service or task that has wp among its output work products and wp must be specified among the output work product of the data flow interface (project goal). The quality attribute for input/output consistency is the count of activity input mappings and activity output mappings that violate these conditions. Efficiency Efficiency is fulfilled, if the method model fulfills its duty at minimal cost and effort. Missing efficiency, however, does not lead to cases where the method model is not executable and it is independent of situational factor values. Therefore, it is a situation-independent and non-critical quality characteristic. We define efficiency based on the quality characteristic with the same name defined in [Har97], where it requires that activities that are not closely related in the method model do not produce the same output work products and that they do not receive input work products that are produced within that activity itself. As this definition is too strict, we define an adopted sub-characteristic. Efficiency is refined into the quality sub-characteristics work product efficiency and control flow efficiency. Work product efficiency is fulfilled, if each output in the method model that is produced by a data handling activity (cf. 5.3.2) is used either as an input by another data handling activity or as an output of the method model (i.e. as a final result). This means that for each data handling activity dha and each output work product wp that is specified as output by the task or method service referenced by dha, there exist an activity input mapping with dha as a source and wp as the input work product or an activity output mapping with dha as a source and wp as the output work product. In addition, each work product that is specified as input for the method model by the project goal needs to be the source for an activity input mapping within the method model. The quality attribute for work product efficiency is the count of the missing activity input/ouput mappings according to the stated conditions. Control Flow Efficiency is fulfilled, if the method model does not contain useless control flow constructs, which are flows, sequences, phases, iterations, ifs, else ifs, and elses that do not contain other elements (cf. 5.3.2). In addition, if-constructs, where the conditional (if) and the alternative (else) activities have the same content also violate this condition. The quality attribute for control flow efficiency is the count of useless control flow constructs. Soundness Soundness is fulfilled, if the method model is semantically correct and meaningful. A method model can be unsound, but syntactically correct and 130 Method Tailoring executable. Therefore, this is a situation-independent and non-critical quality characteristic. We define soundness based on the quality characteristic with the same name and definition in [Har97], but we define different sub-characteristics. For now, we only define the sub-characteristic method pattern fulfillment. Method pattern fulfillment is given, if all used method patterns in a method model are fulfilled. This means, that for each constrained scope descriptor in the method model, the contents of it must fulfill the constraint described by the referenced constrained scope. The quality attribute for method pattern fulfillment is the number of unfulfilled constraints of constrained scope descriptors. Maintainability Maintainability is fulfilled, if the method model can be easily adapted and managed. Missing maintainability, however, does not lead to cases where the method model is not executable and it is independent of situational factor values. Therefore, it is a situation-independent and non-critical quality characteristic. Maintainability is refined into the quality sub-characteristics method pattern coverage and modularity. Method pattern coverage is given, if all method service descriptors and task descriptors of the method models are placed within method pattern descriptors, which eases meaningful changes and updates, as the used method patterns and their constraints cover the whole method model. This means that every method service descriptor and task descriptor is contained within the containment hierarchy of a constrained scope descriptor of a method pattern descriptor. The quality attribute for method pattern coverage is the number of method service descriptors and task descriptors that are not in the containment hierarchy of any constrained scope descriptor. Modularity is given, if the method model is divided into manageable, welldefined units. In MESP, method models can reference method services and tasks. While the later are mainly textually described, atomic units of work, the former can wrap whole (sub-)processes that are described by a rich interface. Therefore, in method models the usage of method service descriptors instead of task descriptors is encouraged. In addition, regarding a group of method services (or tasks), the usage of a composite method service that includes them is encouraged over the usage of many single method services. The quality attributes for modularity are the number of method service descriptors, the number of task descriptors, and the number of tasks directly or indirectly referenced by the method model. Applicability Applicability is fulfilled, if the method model is appropriate for the enactment by a project team. Thus, it is a situation-independent and non-critical quality characteristic. 5.4Assure Quality of Method 131 Applicability is refined into the quality sub-characteristics level of abstraction and understandability.Level of abstraction describes on what level of detail the work to be performed is described. A low level of abstraction indicates that the method model describes the work to be performed in much detail, leaving less room and freedom for self-organization of the project team members, however, also requiring less qualification. On the contrary, a high level of abstraction indicates an abstract description of the work and more freedom for the project team members. The level of abstraction of a method model depends, on the one hand, on the number of tasks that it describes. On the other hand, it depends on the level of abstraction of each of these tasks. A task is less abstract, if it has a longer task description and less input and output work products, since this indicates a more detailed description of a smaller unit of work. Quality attributes for the level of abstraction are therefore the number of tasks directly or indirectly referenced by the method model as well as the length of the task description and the number of the input and output work products of each of these tasks. Understandability is given, if the method model is understandable in terms of the readability of the referenced task descriptions and the complexity of the control and data flow. The easier the task descriptions are to read and the simpler the control and data flow are, the higher is the understandability. Quality attributes for the understandability are therefore the readability of the task descriptions, the number of data flows, and the number of conditional paths of control flow. Suitability Suitability is fulfilled, if the process of the method model is appropriate for its project situation. As this quality characteristic does not affect the executability, it is a situation-dependent and non-critical quality characteristic. Suitability is refined into the quality sub-characteristic situational factor compliance. Situational factor compliance is given, if the situational factor values in the project situation of a method model match the ones that characterize the method services referenced by it. It is violated in the following two cases. First, a situational factor is referenced by one or more of its situational factor values as an included factor of the project situation, and also by a method service referenced from the method model, however, no situational factor value matches. This signifies that a situational factor is relevant, but does not comply. Second, a method service referenced from the method model has a situational factor value that is among the excluded factors of the project situation. Discussion of the Quality Model of MESP In the previous section, we described a quality model for method models. A quality model should be of high quality itself and the question arises how to evaluate the quality model. In [GK09], the authors compiled a list of evaluation criteria for 132 Method Tailoring quality models based on the existing literature on model quality. We list them in Table 5.2(translated from German). In the following, we discuss each of the evaluation criteria in the context of our quality model for MESP: Regarding Clarity & Structuredness, the quality characteristics of the MESP quality model are organized within a hierarchical tree structure providing a clear structure. Thus, this criterion is fulfilled. Regarding Consistency, as the quality characteristics of the MESP quality model are organized within a hierarchical tree structure, this criterion is also fulfilled. Regarding Cohesion & Modularity, the MESP quality model contains three layers of grouping and currently sixteen quality sub-characteristics. As all sub-characteristics belong semantically to their root characteristics, cohesion and modularity is provided. Regarding Unambiguity & Comprehensibility, the quality characteristics of the MESP quality model are described with natural language in order to enhance the comprehensibility and as a foundation for additional quality sub-characteristics. As natural language is ambiguous, ultimately, quality sub-characteristics should be formalized with a formal language. For some quality sub-characteristics, we discuss the formalization in Section 5.4.2. However, formalizing all quality characteristics is still an open research issue and beyond the scope of this thesis. Overall, we consider this criterion as fulfilled. Regarding Absence of Overlappings, the quality characteristics of the MESP quality model are free from redundancies. For example, as from pattern descriptor completeness follows pattern descriptor consistency and vice versa, we omitted the latter form the quality model. Thus, this criterion is fulfilled. Regarding Operationalizability, all quality characteristics of the MESP quality model are operationalizable and we either stated the quality attributes to measure or provide the operationalization with OCL as part of our solution. However, as described with respect to the unambiguity, the formalization of all quality sub-characteristics is beyond the scope of this thesis. Regarding Completeness & Relevance, our MESP quality model is intended to support project method engineers in assuring the quality of composed method models. In this regard, all presented quality characteristics are relevant as they influence the perceived quality of the method model. Regarding the completeness, this quality model is based on the related work in the field. However, we do not claim that the quality model is complete as further, especially non-critical, quality sub-characteristics might be proposed in the future. With respect to the critical quality characteristics, we consider it complete. Regarding Correctness and Consistency, the MESP quality model conforms to the discussed structure. Quality characteristics, especially quality sub-characteristics, and quality attributes are discussed with respect to the MESP meta-model and method models. Therefore, we consider this criterion fulfilled. Regarding Satisfiability, the quality characteristics of the MESP quality model are discussed with respect to structural features of method models. Hence, the underlying quality goals are realistic and satisfiable. 5.4Assure Quality of Method 133 Table 5.2Evaluation Criteria for quality models (adopted from [GK09]) Evaluation Criterion Description Clarity & Structuredness models need to be clear, readable, and structured as a hierarchy. Consistency quality characteristics need to be transitive, thus the quality model shall not contain two quality characteristics x and y, where both x is a (possibly indirect) sub-characteristic of y and y is a (possibly indirect) sub-characteristic of x. Cohesion & Modularity quality characteristics that belong together, should also be closely connected in the quality model. In addition, each quality characteristic of the quality model should represent only one aspect of quality. Unambiguity & Comprehensibility Every quality characteristic shall be clearly and comprehensibly described. Absence of Overlappings Quality characteristics must not be overlapping and should be pairwise disjoint and free of redundancies. Operationalizability All quality characteristics should be measurable (by quality attributes). If a subjective assessment is required, the quality characteristic should be labeled as such. Completeness & Relevance A quality model should comprise all quality characteristics and all their relationships that are relevant for its stakeholders, such that its value decreases, when quality characteristics and relationships are removed. Correctness & Consistency A quality model should be consistent to its meta-model. Additionally, its quality characteristics and quality attributes should conform to the nature of the domain. Satisfiability The quality goals expressed with the quality model and its quality characteristics should be realistic and satisfiable by the models.