=Paper=
{{Paper
|id=Vol-1554/PD_MoDELS_2015_paper_12
|storemode=property
|title=A Usable MDE-based Tool for Software Process Tailoring
|pdfUrl=https://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_12.pdf
|volume=Vol-1554
|authors=Luis Silvestre,María Cecilia Bastarrica,Sergio F. Ochoa
|dblpUrl=https://dblp.org/rec/conf/models/SilvestreBO15
}}
==A Usable MDE-based Tool for Software Process Tailoring==
https://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_12.pdf
A Usable MDE-based Tool for Software Process
Tailoring
Luis Silvestre, Marı́a Cecilia Bastarrica and Sergio F. Ochoa
Computer Science Department, University of Chile
Beauchef 851, Santiago - Chile
{lsilvest,cecilia,sochoa}@dcc.uchile.cl
Abstract—In order to systematize development, software com- project context model, and then use these models as input
panies define their organizational processes. The process engineer of a tailoring transformation, whose output is the project
is in charge of this activity. Tailoring software processes is an adapted process model [5]. Writing tailoring transformations
activity that allows project managers to adapt organizational
software processes to the needs of particular projects. Model- requires knowledge about model transformation programming
driven engineering (MDE) has been applied with that purpose languages, and also about the software process model and the
using process model tailoring transformations. Although this way its variability should be resolved according to the project
approach is technically feasible, there are still factors that context. These two kinds on knowledge –programming a
jeopardize its usage in industry. First, current transformation model transformation and configuring a software process– are
languages and tools are not simple for defining and applying
tailoring transformations. Second, the potential users -process almost never mastered by the same person in the company, and
engineers and project managers- do not usually have the required it is even less frequent in small software companies, where the
knowledge for writing transformations. Trying to deal with these average expertise of the staff is not high [8]. Moreover, even
usability challenges, this paper proposes an MDE-based tool that if there is someone that counts on both kinds of knowledge,
allows defining the models for the organizational software process manually writing complex model transformations is still an
and the organizational context, as well as tailoring rules using a
usable user interface, so that the project manager just requires error-prone activity.
to define the project context of the particular project in order to As part of a previous work [10], we have built a prototype
automatically obtain the tailored process. This usable interface toolset that allows specifying tailoring rules through a user
hides the complexities of the tool backend built as a megamodel, interface, and automatically generating the corresponding tai-
requiring from the process engineer and the project manager loring transformations. This toolset was composed of a set of
only knowledge about project characteristics and how they affect
tailoring. We report our experience of applying the tool in a loosely coupled tools that allowed defining just simple optional
real-world software process and we outline this experience in rules. However, while testing it in industrial scenarios, we
http://www.dcc.uchile.cl/gems/docs/DemoMODELS2015.pdf. have realized that more complex tailoring rules are required;
alternative options should be chosen as part of the tailoring
I. I NTRODUCTION activity, and there are some rules that require compound
Software process formal specification allows companies to conditions. Moreover, the toolset was not usable by our target
rigorously document their development process, and tool sup- users since it needed dealing with intermediate models and
port for process analysis and evolution. Development projects transformations, not for building them but to run each tool
faced by a particular company may be of different kinds, with the appropriate models and transformations.
e.g., large or small, complex or simple, new development In this paper we present an integrated MDE-based tool that
or evolution, and therefore the same process is not equally allows the process engineer defining the organizational process
appropriate for all of them. Process tailoring is the activity of and context as well as the transformation rules, and provides
adapting a general process to match the needs of the project the project manager an interface for defining the project
at hand. Such a tailoring activity is generally performed by context and obtaining the tailored software process. All these
the process engineer and the project manager: the process activities are executed without the need to manipulate models
engineer knows about the organizational process and how or transformations. The tool’s complete structure is shown in
project characteristics affect tailoring, while the project man- Fig. 1. Notice that its back-end is built as a megamodel [11]
ager knows about the project’s particular characteristics. There and the front-end contains all the user interfaces.
are several proposals for process tailoring, such as using the In this paper we show the application of the tool in the case
same process for addressing all projects, counting on a family of one of our industrial partners, Amisoft, a small Chilean
of predefined processes or configuring a process by putting software company. The case study includes the activities of
together appropriate pieces [7]. We have worked with MDE- the process engineer –the software process, context and rule
based process tailoring for the last five years and it has proved definition–, the transformation generation and the project man-
to be technically feasible [3]. ager activities –the project context definition and the tailoring
MDE-based tailoring consists of defining an organizational transformation execution–. We also show how this improved
software process model along with its variability and the tool is able to generate transformations that produce the correct
Fig. 2. Amisoft’s Requirement activity
Fig. 1. MDE-based tool general structure
scheduling using graph transformation rules. In this sense their
approach is similar to ours. However, in AToMPM rules still
tailored software processes in a usable manner, only requiring need to be specified using a custom language, and it only
from the process engineer and the project manager knowledge allows for simple conditions.
about the software process tailoring, but hiding the complexity There are also proposals such as MTBE (Model Transforma-
of managing models and writing model transformations. This tions By Example) [14] and MTBD (Model Transformation By
integrated tool is also more expressive than its previous Demonstration) [12], which present solutions for simplifying
version, being able to define more sophisticated rules. the implementation of model transformations by using strate-
Section II presents related work concerning MDE-based gies and patterns with a visual support. They both generate
tailoring and transformation generation. Section III describes part of the transformation code, but the user still needs to
how the process engineer interacts with the tool, Sec. IV complete the generated code, and thus the transformation rule
how the tailoring transformation is generated, and Sec. V generation becomes a semi-automatic process. Both proposals
the interaction of the project manager with the tool. Finally, highlight the need for developing new solutions that simplify
Sec. VI presents the conclusions and describes ongoing work. the rule definition, so that they become usable solutions for
II. R ELATED W ORK non-experts in MDE.
Proposals trying to address MDE solutions should balance III. P ROCESS E NGINEER ’ S U SER I NTERFACE
the formality required by MDE and the usability needed by the The process engineer is in charge of defining the organi-
process engineers. MOLA [4] and GREaT [1] allow specifying zational process model, the organizational context model, and
transformation rules through visual mapping patterns and the variation decision model, i.e., the model that represents
VIATRA [15] provides a textual rule editor for specifying the tailoring rules. Our tool integrates user interfaces for
patterns. These proposals still need the process engineer to performing each of these activities. We show the application of
interact with metamodels, models, classes or code to adjust the tool for the case of Amisoft, one of our industrial partners.
them to match the features of a specific project. Therefore, Amisoft is a small Chilean software company. For the last
if the user does not count on the required experience for 6 years, it has defined and enacted its software process.We
managing these elements, he could neither write nor maintain have applied the previous MDE-based software process tai-
the transformation code. loring toolset in Amisoft [2] and, although they validated the
Sijtema [9] proposes an extension to the Atlas Transforma- correctness of the resulting tailored processes, they admitted
tion Language (ATL), which is based on feature models and that building tailoring transformations was beyond their capa-
requires the specification of the so-called variability rules. In bilities, even though they counted on a vast experience with
the approach, variability rules are transformed to standard ATL formalized software processes. In the following sections we
code, i.e., variability is translated to called rules in ATL using show how the new integrated tool improved this situation.
a HOT. Although the proposal raises the abstraction level, the
process engineer still needs to understand the ATL extension A. Organizational Process Definition
and interact with code. Several Chilean software companies are already using EPF
AToMPM [13] is a Web-based metamodeling and transfor- Composer as the framework for defining their software pro-
mation tool for multi-paradigm modeling. It allows defining cess, even though there are other available tools [11]. We will
DSLs through an interactive interface for specifying their include this tool as part of our solution in order to enhance
abstract syntax. It also provides support for rule definition and adoption. It allows defining the process breakdown, including
Fig. 5. Generated Amisoft Optional Points
that allows the process engineer to create models through a
graphical user interface. This interface allows defining the
tailoring rules for each variation point of the software process
according to the values in the context; therefore, the interface
takes the Organizational Software Process and the Organiza-
Fig. 3. Amisoft’s Organizational Context Definition tional Context Model previously defined as input as shown in
Fig. 4. This tool implements a DSL formally defined in [10].
This activity involves two steps, the definition of tailoring
rules and the automatic generation of a Variation Decision
Model (VDM). In the first step, the tool guides the users
presenting them only the process elements defined as variable
and allowing them specify a rule either simple or complex for
each variation point. The tool also counts on a menu where
the context attributes and their potential values can be selected
not requiring any typing. The second step is done without the
user intervention.
We define process tailoring rules as a set of conditions,
conclusions and logical operators that decide an action about
a variable process element. Consequently, a VDM is a set
of rules of the form condition ⇒ conclusion, where a
condition is a predicate about the application domain, and the
Fig. 4. User interface for interactive tool for rule definition conclusion indicates how a variation point is resolved when
the condition holds. A condition may be simple, i.e., when
it states attribute = value, or it may be complex when it is
primitives for specifying process element variability, as well as
formed by a series of simple conditions combined with logical
process behavior using activity diagrams. EPF Composer al-
operations. The definition of the tailoring rule associated to the
lows exporting the software process as an XML file that is used
Requirements Specification task is shown in Fig. 4.
as input for other activities. Figure 2 shows the Requirements
activity, that is a portion of Amisoft’s software process. Notice IV. TAILORING T RANSFORMATION G ENERATION
that Requirement Specification and Prototyping are highlighted Transformation generation has two steps: generate the tai-
in the diagram for indicating optionality, even though this is loring transformation model and extract the tailoring transfor-
not standard SPEM [6]; internally in the tool, they are formally mation code, as shown as part of the megamodel back-end in
specified as optional. Fig. 1. This activity is completely automatic and transparent
for both users. It is only generated once and can be used to
B. Organizational Context Definition
tailor all particular project contexts.
We have developed a user interface for defining the or- We have built a Higher Order Transformation (HOT) that
ganizational context. Here, the process engineer defines the takes the VDM as input, and uses a transformation synthesis
attributes that may determine how the process should be pattern for generating the tailoring transformation model using
tailored, as well as their potential values. For example, in a M2M transformation. This HOT is an exogenous and ver-
Fig. 3, we see that the attribute Technical Knowledge may take tical. The resulting tailoring transformation model conforms
values High or Medium/Low. The user interface allows editing to the ATL metamodel. The tailoring transformation code is
this organizational context by adding or deleting attributes, obtained through a M2T transformation that takes the tailoring
and/or modifying their potential values. The output of this transformation model as input.
interface will be saved as the Organizational Context Model. Figure 5 shows an excerpt of the generated tailoring trans-
formation where variable process elements are identified as
C. Tailoring Rules Definition well as their corresponding helper rules for resolving their
By keeping in mind the goal of reducing the skills required inclusion in the tailored process. Figure 6 shows the rules for
to define tailoring transformation rules, we developed a tool Prototyping and Requirements Specification. We can see that
tailoring rules. These enhancements were motivated by the
application of the tool in three of our industrial partners.
We are currently applying the tool in two other small
Chilean companies. So far, the results are promising. Nev-
ertheless, we are aware that the reality of different software
companies may be also different, and thus the applicability of
our tool is not guaranteed. For instance, it may be the case that
some conditions for resolving variability do not just depend
on context values, but also on the way other variation points
Fig. 6. Generated Amisoft Tailoring Transformation are resolved; the tool does not support this kind of conditions
yet but we have not found the need in practice.
ACKNOWLEDGEMENTS
This work has been partly funded by Project Fondef
GEMS IT13I20010 and Luis Silvestre was also supported
by PhD Scholarship Program of Conicyt, Chile (CONICYT-
PCHA/2013-63130130).
R EFERENCES
[1] Daniel Balasubramanian, Anantha Narayanan, Chris vanBuskirk, and
Gabor Karsai. The graph rewriting and transformation language:
GReAT. Electronic Communications of the EASST, 1, 2007.
[2] Julio Ariel Hurtado Alegrı́a, Marı́a Cecilia Bastarrica, Sergio F Ochoa,
and Jocelyn Simmonds. MDE software process lines in small companies.
Journal of Systems and Software, 2012.
[3] Julio Ariel Hurtado Alegrı́a, Marı́a Cecilia Bastarrica, Alcides Quispe,
and Sergio F. Ochoa. MDE-based process tailoring strategy. Journal of
Fig. 7. Amisoft’s Project Context Definition Software: Evolution and Process, 26(4):386–403, 2014.
[4] Audris Kalnins, Janis Barzdins, and Edgars Celms. Model Transforma-
tion Language MOLA. In In proceedings of MDAFA 2004, volume 3599
of LNCS, pages 62–76, Twente, The Netherlands, 2005. Springer.
rule condition for Requirements Specification is the same as [5] Georg Kalus and Marco Kuhrmann. Criteria for Software Process
that specified with the tool in Fig. 4. Tailoring: A Systematic Review. In In proceedings of ICSSP 2013,
pages 171–180, New York, NY, USA, 2013. ACM.
[6] OMG. Software & Systems Process Engineering Metamodel Specifica-
V. P ROJECT M ANAGER ’ S U SER I NTERFACE tion (SPEM) Version 2.0. Technical Report 2008-04-01, Object Man-
The project manager is the final user of the tailoring tool agement Group, 2008. http://www.omg.org/spec/SPEM/2.0/PDF/.
[7] Oscar Pedreira, Mario Piattini, Miguel R. Luaces, and Nieves R.
since he is in charge of executing the tailored process in each Brisaboa. A Systematic Review of Software Process Tailoring. SIGSOFT
project. To this end, he defines the context of the project at Softw. Eng. Notes, 32(3):1–6, 2007.
hand, and the tool returns the tailored software process. [8] Alcides Quispe, Maira Marques, Luis Silvestre, Sergio F. Ochoa, and
Romain Robbes. Requirements engineering practices in very small
We have built a tool for defining the project context. software enterprises: A diagnostic study. In In Proceedings of SCCC
Figure 7 shows the use of this tool for defining a Maintenance 2010, Antofagasta, Chile, pages 81–87. IEEE Computer Society, 2010.
project where Technical Knowledge is High and Development [9] Marten Sijtema. Introducing Variability Rules in ATL for Managing
Variability in MDE-based Product Lines. In Marcos Didonet Del
Skills is High too. With these conditions, and according to Fabro, Frédric Jouault, and Ivan Kurtev, editors, Proceedings of the 2nd
rules included in Fig. 6, neither Prototyping nor Requirements International Workshop on Model Transformation with ATL, volume 10,
Specification will be included in the tailored software pro- pages 39–49, Malaga, Spain, 2010. CEUR Workshop.
[10] Luis Silvestre, Marı́a Cecilia Bastarrica, and Sergio F. Ochoa. A
cess since it is a Maintenance project. However, if it were Model-based Tool for Generating Software Process Model Tailoring
a Development project, Prototyping would be included, but Transformations. In In proceedings of MODELSWARD 2014, Lisbon,
Requirements Specification would still not be included since Portugal, pages 533–540. SciTePress, 2014.
[11] Jocelyn Simmonds, Daniel Perovich, and Marı́a Cecilia Bastarrica. A
Development Skills is High. Megamodel for Software Process Line Modeling and Evolution. In To
appear in Proceedings of MODELS 2015, Ottawa, Canada, 2015.
VI. C ONCLUSIONS AND F UTURE W ORK [12] Yu Sun, Jules White, and Jeff Gray. Model Transformation by Demon-
stration. In In proceedings of MoDELS 2009, volume 5795 of LNCS,
This article presents an MDE-based integrated tool for pages 712–726, Denver, CO, USA,, 2009. Springer.
defining and executing software process tailoring. It provides a [13] Eugene Syriani, Hans Vangheluwe, Raphael Mannadiar, Conner Hansen,
usable user interface that allows its users -the process engineer Simon Van Mierlo, and Hüseyin Ergin. Atompm: A web-based modeling
environment. In Demos/Posters/StudentResearch@ MoDELS 2013,
and the project manager- to deal only with process and pages 21–25. CEUR Workshop Proc., 2013.
context-related concepts hiding all the models and transforma- [14] Dniel Varr. Model transformation by example. In In proceedings of
tions involved. The tool is better than its predecesor [10] in two MoDELS 2006, volume 4199 of LNCS, pages 410–424. Springer Berlin
Heidelberg, 2006.
ways: it is an integrated tool that hides even the existence of [15] Dániel Varró, Gergely Varró, and András Pataricza. Designing the
models and transformations and not only their generation, and automatic transformation of visual languages. Science of Computer
it is more expressive since it allows specifying more complex Programming, 44(2):205–227, 2002.