Software process modeling languages: A systematic literature review

Software process modeling languages: A systematic literature review L. García-Borgoñón a,b , M.A. Barcelona a,b , J.A. García-García b , M. Alba b , M.J. Escalona b a Aragón Institute of Technology, Zaragoza, Spain b IWT2 Research Group, University of Seville, Seville, Spain Keywords: Software process modeling Software process language Systematic literature review abstract Context: Organizations working in software development are aware that processes are very important assets as well as they are very conscious of the need to deploy well-defined processes with the goal of improving software product development and, particularly, quality. Software process modeling languages are an important support for describing and managing software processes in software-intensive organizations. Objective: This paper seeks to identify what software process modeling languages have been defined in last decade, the relationships and dependencies among them and, starting from the current state, to define directions for future research. Method: A systematic literature review was developed. 1929 papers were retrieved by a manual search in 9databases and 46 primary studies were finally included. Results: Since 2000 more than 40 languages have been first reported, each of which with a concrete purpose. We show that different base technologies have been used to define software process modeling languages. We provide a scheme where each language is registered together with the year it was created, the base technology used to define it and whether it is considered a starting point for later languages. This scheme is used to illustrate the trend in software process modeling languages. Finally, we present directions for future research. Conclusion: This review presents the different software process modeling languages that have been developed in the last ten years, showing the relevant fact that model-based SPMLs (Software Process Modeling Languages) are being considered as a current trend. Each one of these languages has been designed with a particular motivation, to solve problems which had been detected. However, there are still several problems to face, which have become evident in this review. This let us provide researchers with some guidelines for future research on this topic. Contents 1. Introduction . . . ...................................................................................................... 104 2. Related work. . . ...................................................................................................... 104 3. Method . . . . . . . ...................................................................................................... 105 3.1. Research questions . . . . . ......................................................................................... 105 3.2. Search strategy . . . . . . . . ......................................................................................... 105 3.3. Study selection and the inclusion and exclusion criteria . . . . . . . . . . ...................................................... 105 3.4. Quality assessment . . . . . ......................................................................................... 106 3.5. Data collection and analysis . . . . . . . . . . . . . . ......................................................................... 106 4. Results. . . . . . . . ...................................................................................................... 106 4.1. Search results . . . . . . . . . ......................................................................................... 106 4.2. Quality evaluation . . . . . . ......................................................................................... 107 5. Discussion. . . . . ...................................................................................................... 107 5.1. RQ1. What software process modeling languages have been defined? Why?. . . . . . . . . . . . . ................................... 107 5.2. RQ2. What is the current trend when selecting base technology to define a SPML? . ......................................... 108 5.3. RQ3. What are the limitations of current research? . . . . . . . . ............................................................ 111 5.4. Limitations of our study . . . . . . . . . . . . . . ............................................................................ 111 5.4.1. Search strategy . . . . . . . . . ................................................................................. 111 5.4.2. Study selection . . . . . . . . . ................................................................................. 112 5.4.3. Quality assessment. . . . . . ................................................................................. 112 5.4.4. Data extraction and author bias . . . . . . . . . . . ................................................................. 113 6. Directions for future research . . ......................................................................................... 115 7. Conclusions and future work. . . ......................................................................................... 115 Acknowledgements . . . . . . . . . . ......................................................................................... 115 References . ......................................................................................................... 115 1. Introduction Today, software applications are used extensively to support day to day business activities in every kind of company. Organizations working in software development are aware that software processes are very important assets as well as they are very conscious of the need to deploy well-defined processes with the goal of improving the software products development and, of course, quality [3]. Due to their importance, a challenging goal for software development organizations is to find the best way of describing and managing software processes. A software process may be defined as the set of partially ordered steps, with subsets of related artifacts, human and computerized resources, and organizational structures and constraints intended to produce and maintain the requested software deliverables [7]. This definition shows the large amount of factors that may influence software development processes. Software processes are more complex and unpredictable than typical production processes [2] as they depend on people and circumstances. After Osterweils’ statement: ‘‘Software processes are software too’’ [8],many process languages and models have emerged. Since the late 1980s, the software community has shown a growing interest in finding the best way to describe software processes to be understood and institutionalized within organizations, becoming an important research topic in Software Engineering. It achieved such a relevance that sometimes people talked about several generations of software process modeling languages [13]. Software process languages have been created from different sources, such as programming-based languages, Petri net-based languages or rule-based languages. There was no clear trend to select one as a foundation. The most recent literature offers some possibilities, such as UML, as a basis to cope with this possible de facto standardization. Therefore, as software-intensive organizations (defined as private or public organizations extensively using or developing software [4]) have not yet adopted any of these proposals in a practical sense, it may not be determined which technology should work as basis or standard. Despite the status of the topic, the state-of-the art is not yet very clear, and the different approaches are widely spread in the literature. Previous reviews and surveys [11] [12] have been found, although they are not very recent, as well as comparisons among some specific work [2] [5]. Nevertheless, a complete view of the last years is not available. Consequently, the general aim of this systematic review is to capture the current state-of-the art in software modeling languages and identify needs and opportunities for future research work. This systematic literature review contributes to ongoing research in the field of software process modeling in four ways: (1) by reviewing and showing all software process modeling languages that have been created since 2000, as well as their description and motivation, (2) by summarizing what problems have been addressed in Software Process Engineering through software process modeling languages, (3) by creating a new taxonomy for software process modeling languages in order to classify them by their base technology, and (4) by offering directions for future research. This paper is structured as follows. Section 2summarizes related work. In Section 3, the method used for the systematic review is introduced. Section 4shows the results of the review, and then, Section 5offers discussions on these results. In Section 6, directions for future research are pointed out and finally, Section 7states conclusions and future work based on the findings obtained. 2. Related work Although this topic has been discussed and studied for many years, we have found too few literature reviews and surveys in this area. We have also sought some comparison between several languages as a starting point for our review. The next paragraphs summarize the most relevant work we have found in our searches. Zamli [11] conducted a survey about the state-of-the art of the second generation PMLs (Process Modeling Languages). Sutton and Osterweil [9] stated that a PML belongs to the second generation, if published after 1996. This work proposes a simple classification based on process enactment support. They classified a PML as non-enactable, simulated or enactable. Non-enactable PMLs only support process modeling, but not process enactment. Simulated PMLs enable a high-level simulation, but do not provide finegrained control of the software process. Finally, enactable PMLs permit the process model to be enacted to control a software process. Besides this classification, they introduced five areas that a PML must support: modeling support, enactment support, evaluation support and human dimension support, and they tabulated support areas in accordance with the aforementioned classification in three groups. Some years later Zamli et al. [12] studied in depth the classification of the PMLs by using the taxonomy and support areas described in their previous work, and listed features covered by each PML in a specific support area. A comparison of six UML-based languages for software process modeling was presented in [2]. The authors selected the most predominant and common ones from the many requirements identified in the literature related to process modeling languages. Then, they evaluated those six languages against requirements and compared them. Henderson-Sellers et al. [5] examined critically four metamodels that have been constructed to underpin and formalize methodologies. Based on this analysis, the authors proposed a new metamodel that supported both the software development and capability assessment, which was used in ISO 24744 standard. In summary, too few studies have conducted a systematic review of SPMLs, and those existing are neither very recent and have limited coverage. Therefore, we consider our work to be an important starting point to find which SPMLs have been proposed. 3. Method Systematic literature review has been the method chosen to achieve the goal described in Section 1. It allows identifying, evaluating and interpreting all available research data relevant to a particular research question in a specific investigation area. The guidelines proposed by Kitchenham [6], which are among the most widely accepted in software engineering, have been followed to carry out this work. These guidelines establish that a review should comprise three phases: planning, conducting and reporting. The planning activity deals with developing the review protocol as well as deciding how the researchers should work and interact to conduct the review. This protocol prescribes a controlled procedure for executing the review and includes research questions, search and evaluation strategies, inclusion/exclusion criteria, quality assessment, data collection form and methods of analysis. The second phase focuses on executing the protocol as it has been defined. Finally, the last phase describes how the final report has been elaborated. Fig. 1 outlines all the activities included in each phase. They will be described in detail in the following sub-sections. 3.1. Research questions Defining and describing the software process is not a new problem. Over the years, different approaches, languages and metamodels have been proposed to describe processes with a unique goal: to find the best way of representing the software process to obtain a successful application in industry. Due to this goal concerning understanding the existing research proposals within software process modeling, a general research question (RQ) was defined: ‘‘What is the state-of-the art in software process modeling languages?’’. As this question was too general, it was reformulated into these three more specific questions, which guided this research work: RQ1. What software process modeling languages have been defined? Why? RQ2. What is the current trend when selecting a base technology to define an SPML? RQ3. What are the limitations of the current research? 3.2. Search strategy An exhaustive search for papers was carried out to answer these research questions. It was mainly focused on major digital libraries since journal articles, workshop and conference papers were the objective to be covered. First of all, the keywords for the search were selected. As this selection was known to be relevant for the quality of results, general terms were used with the aim of confirming that most of the research papers were included in the study. After some pilot testing, the final search strings consisted of the following Boolean expression ‘‘AAND (B1 OR B2 OR B3) AND (C1 OR C2)’’ where search expressions are represented in Table 1 as follows: The search was carried out through the following consulted databases: ACM Digital Library, Ei Compendex, IEEE Xplore, ISI Web of Knowledge, Science Direct, SCOPUS and Wiley InterScience Journal Finder. Both, an excel file to store the completed searches and Jabref [1], a reference manager tool which helped us to manage the references and perform the systematic search, were used to manage results. 3.3. Study selection and the inclusion and exclusion criteria The study selection process was performed in 6 phases as outlined in Table 2. The goal of such a selection process was to identify the relevant articles that may match the objectives of the systematic literature review. The search strings were too general and it was expected that not all studies found would be chosen for the final phase in the selection process. JabRef [1] supported the study selection, which allowed the team to manage more efficiently the duplicate references among databases and generate an integrated file with the first version of results. In this process, there were two consensus meetings where all researchers jointly decided whether the studies were considered relevant for the work. The first one focused on the abstracts, keywords and titles, whereas the second was based on the full text. The guidelines of a systematic review strongly recommend the participation of several researchers in the process, and this was evidenced by less subjective decisions and the fact that researchers jointly made decisions according to the agreed criteria. The systematic review protocol selected explicitly defines inclusion and exclusion criteria, as it is shown in Table 3. Fig. 1. Activities in the systematic review. Table 1 Search expressions. A. Software process B1. Description C1. Metamodel B2. Definition C2. Language B3. Modeling 3.4. Quality assessment A questionnaire, which had to be filled in for each included paper, was elaborated with the purpose of assessing the quality of the obtained studies. Three possible answers could be chosen for each question, yes,no or partially. Table 4 shows both the quality assessment questions and the criteria described to evaluate them. 3.5. Data collection and analysis A data collection form was defined to extract the most relevant information from the selected studies and facilitate the process of analyzing the compiled data. From now on, this form will be referred as schema, as it is shown in Table 5. In a further review, all researches evaluated the selected studies and completed the schema. After that, all participants discussed and agreed on all issues in the final data collection. 4. Results This section presents the results of the systematic literature review. On the one hand, the search results are analyzed and on the other hand, quality evaluation results are shown. 4.1. Search results Once the protocol was defined, it was executed. First of all, the selection process was performed with the aim of identifying the relevant papers for the systematic review. As mentioned above, the search strings were so general that they influenced the search results. As there is no standard way of conducting searches for all search engines, we executed a set of manual queries and integrated the results in each search engine. Fig. 2 represents firstly, the papers that were retrieved from each search engine after all queries were executed and secondly, the number of different studies that were collected from each search engine after removing duplicated entries for the same search engine. Finally, we show the number of papers that were included in this work following the inclusion criteria defined. Fig. 3 shows the number of studies finally included in our analysis and retrieved from the search engine divided by the number of studies selected from all search engines. It can be observed that Ei Compendex and SCOPUS provided us with more than 60% of the studies. The second value represents the studies finally included in our analysis and retrieved from the search engine divided by all different studies retrieved from the same search engine. It shows that most of them include 10% of the results approximately. Those studies that were included and found in various search engines have been also included in Figs. 2 and 3,, to avoid penalizing any search engine. Fig. 4 shows the number of search engines Table 2 Inclusion phases. Phase Relevance analysis phase description Involvement P1 Search-based studies selection Leading researcher P2 Screening: exclusion based on date Leading researcher P3 Screening: exclusion based on titles, abstracts and keywords Two researchers P4 Consensus meeting All researchers P5 Relevance analysis: exclusion based on full text All researchers P6 Consensus meeting All researchers Table 3 Inclusion and exclusion criteria per phase. Phase Inclusion/exclusion criteria P1 Not duplicated Only published work Contains the search strings P2 Date of publication after 2000 P3 Not editorials, prefaces, discussions P4 Not summaries of tutorials, workshops or panels P5 Only English Full text obtained P6 New language or a language modification proposed Neither surveys nor reviews Table 4 Quality assessment questionnaire. Quality question – score QA1: Did the study make a review of previous research for the topic? Yes: it either extensively compared previous research with a contextual situation or mentioned different generations in software process languages Partially: it only mentioned a few previous researchers and did not establish a clear background for the topic No: it did not mention any previous research QA2: Did the study mention a base technology for its proposal? Yes: it explained which was the starting point and why Partially: it commented on the support base, but did not explain why No: it started from scratch without any justification QA3: Did the study show the further continuous research? Yes: it showed future research in the field of the software process modeling language Partially: it showed only future work on its proposal No: no future research work was shown Table 5 Data schema. Basic info It means title and author Publication info It refers to book, journal, conference or technical paper where the study was published Year It makes reference to the year when the study was published Language defined It deals with the name of the language defined in the study, the problem addressed, its description and motivation Based-on It refers to the technology or reference language on which this new language is based and the advantages and disadvantages of other alternatives Related work It lists the name of studies cited and whether the study has a state-of-the art section Cited by It identifies the study and whether it is referenced explicitly in other selected studies Future work It proposes future work and challenges shown in the study related to the research questions that found studies included in our analysis. It can be observed that 56% of the studies were found in one or two search engines, and the remaining 44% has been obtained from three or more of them. None were found in more than 5 search engines. The process was carried out according to the six phases previously presented, whereby the number of selected papers decreased. Fig. 5 and Table 6 show the number of included and excluded studies per phase. All included references are listed in the References section. Excluded studies are not mentioned due to space restrictions. 4.2. Quality evaluation The included studies underwent a quality evaluation by means of the questionnaire presented in Table 4, with the aim of measuring their degree of representativeness that may enable obtaining relevant conclusions. The three quality questions were rated for each included study in accordance with the criteria established in the quality questionnaire. After that, responses to the quality questions were discussed in order to find their degree of coverage. Fig. 6 shows the coverage of every QA in the studies included. It shows that QA1 and QA2 were covered in a rate higher than 80% by Yes or Partially answers. In contrast, QA3 has less coverage. All of them were covered at least at 70% by Yes or Partially answers. 5. Discussion This section will discuss one by one the answers to the three research questions defined as the target to fulfill this systematic literature review. Then, the weaknesses of this study will be pointed out. 5.1. RQ1. What software process modeling languages have been defined? Why? Fig. 7 is a summary of the SPMLs defined since 2000. Thus, every year, it includes the languages that have been reported. After this first snapshot, in which all relevant SPMLs have been identified, the following Tables 7–10 offer a short description of each SPML and the motivation for which it was created. Fig. 2. Studies retrieved through search engines. Fig. 3. Analysis of retrieved results from search engines regarding the total studies included. Table 11 summarizes the main problems faced to answer the first research question. As this table shows, problems appointed in these papers can be grouped in four major topics: support for static process documentation, support for analysis and management of processes before their enactment, dynamic process support (automation and flexibility) and support tools and environments for software processes. 5.2. RQ2. What is the current trend when selecting base technology to define a SPML? We aim to find how SPMLs have been classified in the literature to answer this question. Historically, some SPML generations have been considered as a way to classify them [2]. The first generation relates to those software process modeling languages which are Petri nets-based, rule-based or programming language-based. These focus on process execution and formality, which make them become complex, inflexible and difficult to understand. The second generation coincides with the moment when UML became mature as a standard language in the software industry. The idea is to Fig. 4. How many search engines found the studies included in our analysis? Fig. 5. Studies removed in the revision phase. Table 6 Included and excluded studies per phase. Phase Included Removed Found 1929 752 P1 1177 534 P2 643 230 P3 413 233 P4 180 48 P5 132 82 P6 50 4 Included 46 0 explore the possibility of using it as a process modeling language. Some UML-based languages or approaches have appeared, mainly characterized by expressiveness and lack of formality, which have influenced the possibility of running (enacting) the process models. However, by checking the results on Tables 7–9, we conclude that to talk about generations of languages is not particularly appropriate, since although more second-generation proposals have been launched from some years ago up to date, there are recent proposals which can be classified as first-generation languages. Thus, a new taxonomy for SPMLs has been established. For this, we have considered the base technology used in the SPML development. We have structured SPMLs in three groups according to the results of the review, as can be seen in Fig. 8. The first group of grammar-based languages includes all studies that focus on formal languages, mathematical and programming, by means of rules or restrictions. A second group contains several versions of UML-based SPMLs, and finally, the last group includes metamodel-based SPMLs or DSLs. Fig. 9 outlines the correspondence among each SPML obtained in RQ1 and the aforementioned groups. Following the proposed taxonomy defined in Fig. 8, grammar-based SPMLs are shown with no background color or frame, UML-based SPMLs are shown with background color and model-based SPMLs are shown with a frame. A relevant issue for us was to identify why a base technology was chosen in each SPML. Thus, Tables 12 and 13 summarize the main advantages and disadvantages the authors highlighted regarding the base technologies. In light of this, it can be concluded that UML has been considered a suitable base technology, since it constitutes a standard in Software Engineering. However, its weakness is the lack of capability to execute processes, although some UML diagrams can be executed (simulated) if an execution semantics are assigned to them. Considering this fact and the temporal view of SPMLs, the trend Fig. 6. Quality assessment results per question and type of assessment response. Fig. 7. Summary of software process modeling languages. Table 7 Description of existing software process modeling languages. Year SPML [Ref.] Based on Description Motivation 2000 APER-2 [25] PML It is a developer-centered (people-centered) language to facilitate the calculation of the workload and model multiple concurrent activities There were only product-centered and activity-centered languages 2000 SoftPM [49] Petri-Nets The paper proposes a PSEE (process-centered software engineering environment) based on a high-level Petri net formalism for process modeling and exploits a multi-level modeling mechanism for software processes representation There was no PSEE that has different ways to represent processes (easy to do and not ambiguous) and in addition to preserving formality 2000 Noock [50] UML The language proposed in the paper is a UML-centered approach to manage knowledge in a large software development organization There was a gap regarding modeling a process that integrates engineering and management practices, in order to get manageable tasks, exchangeable components and comparable projects 2000 Podnar et al. [52] PML The paper proposes a specification and description language-based approach (a formal object-oriented language for communicating systems) for software process modeling Software processes had similar characteristics to real-time systems (since a timely response to external stimuli is required), so that an ITU-T standard was used 2002 FLEX [24] PML It is an object-oriented, rule and constraint-based language that supports semantic richness, simplicity of use, flexibility, scalability, re-usefulness and distribution. It is also analyzable, executable and evolutionary Existing process models were too fine-grained, so their understandability and reuse were difficult 2002 Di Nitto et al. [29] UML The papers proposes a language that offers the possibility of applying a subset of UML as an executable PML by transforming UML models to enactable workflow models UML was conceived as non-executable, semi-formal language, but it was very popular, so the authors tried to achieve process enactment through UML 2002 APSEE [43] [53] Graph PML It is a graph grammar-based PML that provides support for dynamic changes (flexibility) in enacting processes Existing PSEE did not offer flexibility for process enactment and integrated support for tools and services to automate process analysis and improvement (i.e. simulation and reuse facilities) 2003 PROMENADE [33] UML The language proposed in the paper covers process reuse (the ability to construct new processes by assembling those which have been already built) and process harvesting (the ability to build generic processes that may be further reused from existing ones) Existing SPMLs had some limitations: expressiveness, standardization, modularity and flexibility and the authors tried to improve them 2003 Ruiz et al. [54] UML It proposes a language for using MOF and XMI to represent software processes There was no concrete technological proposal applied to SPML 2003 VRPML [59] Graph PML It is a control-flow PML based on graph theory focused on visual modeling Existing SPMLs lacked dynamic creation and assignment of tasks and resources, support for awareness and visualization issues (to have enactable PMLs) Table 8 Description of existing software process modeling languages (cont). Year SPML [Ref.] Based on Description Motivation 2004 Atkinson et al. [15] [16] PML It is a control-based PML that tries to cover simplicity, flexibility, expressiveness and enactability The authors tried to support evolutionary model development and verification 2004 DPEL [26] PML The paper proposes a decentralized process enactment model to build a distributed PSEE Existing PSEEs were centralized, so that they presented a single point of failure and a bottleneck related to process enactment 2004 PROPEL [37] [19] UML The paper proposes a language for providing concepts attending to a semiformal description and relation among process patterns The authors tried to support flexible processes through process patterns 2005 UML4SPM [18] [19] [22] [20] [21] UML The language proposed in the paper is a MOF-compliant metamodel that has four objectives: expressiveness, understandability, precision and executability The authors tried to cover the limitations of OMG SPEM 1.1 which had not yet reached the required level for the specification of executable models 2005 PBOOL+ [55] Graph PML It is a graph PML focused on reusing software processes through process components and process patterns The authors studied the problem of characterizing reusable process components 2006 Lee et al. [42] UML The language proposed in the paper is a UML-based metamodel approach for task assignment policy in software process There was no proposal regarding task assignment policy in software process 2006 i ⁄ PML [23] The paper proposes a language for using both an agent-oriented language to model processes and a goal-driven procedure to design them There was no proposal regarding agent-oriented technologies applied in software process modeling 2006 Combemale et al. [27] SPEM 1.1 The language proposed in the paper is a SPEM 1.1 extension specialized on semantics The authors tried to cover the limitations of OMG SPEM 1.1 which only partly formalized the semantics and did not help building a process model 2006 UML-EWM [28] UML The paper proposes a language to cover workflows processes modeling There was no proposal that established a mapping between a development methodology and a workflow process 2006 MOPN-SP-net [34] [35] Petri- Nets The language proposed in the paper is a multi-view software process model-based on multi-object Petri nets The authors argued that both Petri-nets and the multiple views of a software process seemed to be similar 2007 Tran et at [56] UML The language proposed in the paper allows an explicit representation of process patterns in process models The authors tried to cover building and also improving process models 2007 Washizaki [57] SPEM 1.1 The paper proposes a language that deals with stating clearly the commonality and variability in process workflows when they are modeled as UML activity diagrams Existing proposals were not always oriented toward overall optimization and did not lead to generally applicable process model structures deals with using metamodels as base technology when generating new SPMLs. 5.3. RQ3. What are the limitations of current research? The aim of this question is to reflect on the state of the current research in software process modeling language area, and this is going to be revised from two points of view. We are going to consider data collected from ‘‘Future work and Conclusions’’ sections appearing in papers included in this study. Table 14 summarizes them, grouping those that are common to several papers. Table 15 shows the open issues to be addressed in the future. We have decided to group them into related subjects, as issues to take into account when considering new proposals: to integrate software process models with decision support tools, to improve process evolution, to verify usefulness in practice, to reach consensus on what topics should be covered in software process modeling and how technologies could be integrated into software process modeling. A proposal that may allow establishing both, a modeling and execution environment, maintaining suitable levels of understandability, would result in an important alternative in this area, also entailing the possibility of being applied in software-intensive organizations. 5.4. Limitations of our study The systematic literature review guidelines proposed by Kitchenham [6] have been followed in order to carry out this work which has been supported by a pre-defined study protocol and continuous interaction among authors. Nevertheless, it has some limitations. 5.4.1. Search strategy The first important activity to undertake this work was to define the search strategy, that is, where we must look for and what keywords must be used. Clearly, the set of search engines used determined the overall number of studies on which then we applied the Table 9 Description of existing software process modeling languages (cont). Year SPML [Ref.] Based on Description Motivation 2007 UPME [58] UML The language proposed in the paper allows modeling software processes in three steps: metamodel, model instantiation, and model compilation in order to translate them into objectoriented code skeleton (s) for process enactment The authors tried to cover complexity reduction through process reuse by using metamodeling 2007 xSPEM [17] SPEM 2.0 The language proposed in the paper tries to extend SPEM2.0 to allow process models to be checked through a mapping with Petri nets and monitored through a transformation into BPEL The authors provided a definition of an Executable SPEM 2.0 2008 Hsueh et at [38] UML The paper proposes a language to define, verify, and validate an organization’s process The authors proposed an approach to validate processes in a simulation environment 2008 PMMM [39] Powertypes The paper proposes a language for Domain-Specific Process Management The authors tried to separate general process modeling principles from domain specific languages 2008 Kang et at [40] XML It is an evolutionary process component description language There was no systematic method for describing a software evolution process component 2008 FlexUML [47] UML The language proposes a two-step approach to model controlled flexibility in software processes There was a need of process participants being able to express and control the amount of flexibility allowed in those processes 2009 Maciel et at [44] SPEM 2.0 The paper proposes an integrated approach for MDA process modeling and enactment based on some SPEM 2.0 concepts specialization There was a lack of standard terminology and notation addressing design aspects of a MDA process because tools were only focused on defining and executing model transformations 2009 FlexSPMF [48] SPEM 2.0 The paper proposes a framework for modeling and learning flexibility in software processes The authors tried to improve process flexibility when dynamic activities that had to evolve to cope with changes occur 2010 MODAL [41,51] SPEM 2.0 The language proposed in the paper is a SPEM extension to improve co-design process models There was a lack in current PML to achieve integration of MBE (Model Based Engineering) into system and software process models 2010 eSPEM [31] SPEM 2.0 The language proposed in the paper is a SPEM Extension for Enactable Behavior Modeling There was a lack in SPEM because it covered a rather coarse description of processes behavior. Support for a more finegrained behavior model and life-cycle modeling was missing Table 10 Description of existing software process modeling languages (cont). Year SPML [Ref.] Based on Description Motivation 2011 Aoussat [14] SPEM 2.0 The paper proposes a SPEM extension that defines explicit software process connectors that facilitate, adapt and control software process interactions The authors tried to cover the limitations of OMG SPEM 1.1 regarding architectural concepts for software process modeling based on software architectures 2011 Ellner et al. [30] OMG’s FUML The paper proposes a FUML-based distributed execution machine for enacting software process models FUML was insufficient to execute software process models to drive realistic projects with large and geographically spread teams 2011 Ferreira [32] UML The paper is a modeling approach for software process design and implementation dealing with increasing the size and complexity of large process systems There was no proposal regarding the incremental size and complexity of processes 2011 vSPEM [45] [46] SPEM 2.0 The paper proposes a language that models variability in software processes There was no variant-rich SPML so that a process can be customizable to specific project goals and environments 2011 CoMProM [36] UML The paper proposes a component-based language to automate the software development processes allowing the flexibility to take processes as components There were many current approaches offering processes as components but they failed to provide the execution semantics for these process components