-In order to systematize development, software companies define their organizational processes. The process engineer is in charge of this activity. Tailoring software processes is an activity that allows project managers to adapt organizational software processes to the needs of particular projects. Modeldriven engineering (MDE) has been applied with that purpose using process model tailoring transformations. Although this approach is technically feasible, there are still factors that jeopardize its usage in industry. First, current transformation languages and tools are not simple for defining and applying tailoring transformations. Second, the potential users -process engineers and project managers- do not usually have the required knowledge for writing transformations. Trying to deal with these usability challenges, this paper proposes an MDE-based tool that allows defining the models for the organizational software process and the organizational context, as well as tailoring rules using a usable user interface, so that the project manager just requires to define the project context of the particular project in order to automatically obtain the tailored process. This usable interface hides the complexities of the tool backend built as a megamodel, requiring from the process engineer and the project manager only knowledge about project characteristics and how they affect tailoring. We report our experience of applying the tool in a real-world software process and we outline this experience in http://www.dcc.uchile.cl/gems/docs/DemoMODELS2015.pdf.
Software process formal specification allows companies to
rigorously document their development process, and tool
support for process analysis and evolution. Development projects
faced by a particular company may be of different kinds,
e.g., large or small, complex or simple, new development
or evolution, and therefore the same process is not equally
appropriate for all of them. Process tailoring is the activity of
adapting a general process to match the needs of the project
at hand. Such a tailoring activity is generally performed by
the process engineer and the project manager: the process
engineer knows about the organizational process and how
project characteristics affect tailoring, while the project
manager knows about the project’s particular characteristics. There
are several proposals for process tailoring, such as using the
same process for addressing all projects, counting on a family
of predefined processes or configuring a process by putting
together appropriate pieces [
MDE-based tailoring consists of defining an organizational
software process model along with its variability and the
project context model, and then use these models as input
of a tailoring transformation, whose output is the project
adapted process model [
As part of a previous work [
In this paper we present an integrated MDE-based tool that
allows the process engineer defining the organizational process
and context as well as the transformation rules, and provides
the project manager an interface for defining the project
context and obtaining the tailored software process. All these
activities are executed without the need to manipulate models
or transformations. The tool’s complete structure is shown in
Fig. 1. Notice that its back-end is built as a megamodel [
In this paper we show the application of the tool in the case of one of our industrial partners, Amisoft, a small Chilean software company. The case study includes the activities of the process engineer –the software process, context and rule definition–, the transformation generation and the project manager activities –the project context definition and the tailoring transformation execution–. We also show how this improved tool is able to generate transformations that produce the correct tailored software processes in a usable manner, only requiring from the process engineer and the project manager knowledge about the software process tailoring, but hiding the complexity of managing models and writing model transformations. This integrated tool is also more expressive than its previous version, being able to define more sophisticated rules.
Section II presents related work concerning MDE-based tailoring and transformation generation. Section III describes how the process engineer interacts with the tool, Sec. IV how the tailoring transformation is generated, and Sec. V the interaction of the project manager with the tool. Finally, Sec. VI presents the conclusions and describes ongoing work.
Proposals trying to address MDE solutions should balance
the formality required by MDE and the usability needed by the
process engineers. MOLA [
Sijtema [
AToMPM [
There are also proposals such as MTBE (Model
Transformations By Example) [
The process engineer is in charge of defining the organizational process model, the organizational context model, and the variation decision model, i.e., the model that represents the tailoring rules. Our tool integrates user interfaces for performing each of these activities. We show the application of the tool for the case of Amisoft, one of our industrial partners.
Amisoft is a small Chilean software company. For the last
6 years, it has defined and enacted its software process.We
have applied the previous MDE-based software process
tailoring toolset in Amisoft [
Several Chilean software companies are already using EPF
Composer as the framework for defining their software
process, even though there are other available tools [
We have developed a user interface for defining the organizational context. Here, the process engineer defines the attributes that may determine how the process should be tailored, as well as their potential values. For example, in Fig. 3, we see that the attribute Technical Knowledge may take values High or Medium/Low. The user interface allows editing this organizational context by adding or deleting attributes, and/or modifying their potential values. The output of this interface will be saved as the Organizational Context Model.
By keeping in mind the goal of reducing the skills required
to define tailoring transformation rules, we developed a tool
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
Organizational Context Model previously defined as input as shown in
Fig. 4. This tool implements a DSL formally defined in [
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 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 formed by a series of simple conditions combined with logical operations. The definition of the tailoring rule associated to the Requirements Specification task is shown in Fig. 4.
Transformation generation has two steps: generate the tailoring transformation model and extract the tailoring transformation code, as shown as part of the megamodel back-end in Fig. 1. This activity is completely automatic and transparent for both users. It is only generated once and can be used to tailor all particular project contexts.
We have built a Higher Order Transformation (HOT) that takes the VDM as input, and uses a transformation synthesis pattern for generating the tailoring transformation model using a M2M transformation. This HOT is an exogenous and vertical. The resulting tailoring transformation model conforms to the ATL metamodel. The tailoring transformation code is obtained through a M2T transformation that takes the tailoring transformation model as input.
Figure 5 shows an excerpt of the generated tailoring transformation where variable process elements are identified as well as their corresponding helper rules for resolving their inclusion in the tailored process. Figure 6 shows the rules for Prototyping and Requirements Specification. We can see that rule condition for Requirements Specification is the same as that specified with the tool in Fig. 4.
The project manager is the final user of the tailoring tool since he is in charge of executing the tailored process in each project. To this end, he defines the context of the project at hand, and the tool returns the tailored software process.
We have built a tool for defining the project context. Figure 7 shows the use of this tool for defining a Maintenance project where Technical Knowledge is High and Development Skills is High too. With these conditions, and according to rules included in Fig. 6, neither Prototyping nor Requirements Specification will be included in the tailored software process since it is a Maintenance project. However, if it were a Development project, Prototyping would be included, but Requirements Specification would still not be included since
This article presents an MDE-based integrated tool for
defining and executing software process tailoring. It provides a
usable user interface that allows its users -the process engineer
and the project manager- to deal only with process and
context-related concepts hiding all the models and
transformations involved. The tool is better than its predecesor [
We are currently applying the tool in two other small Chilean companies. So far, the results are promising. Nevertheless, 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 are resolved; the tool does not support this kind of conditions yet but we have not found the need in practice.
This work has been partly funded by Project Fondef GEMS IT13I20010 and Luis Silvestre was also supported by PhD Scholarship Program of Conicyt, Chile (CONICYTPCHA/2013-63130130).