Modeling Variability in Software Process with EPF Composer ...

Modeling Variability in Software Process with EPF Composer andSMartySPEM: An Empirical Qualitative Study

Jaime W. Dias and Edson OliveiraJrInformatics Department, State University of Maringa, Maringa-PR, Brazil

Keywords: Annotative Approach, Compositional Approach, Eclipse Process Framework, Empirical Qualitative Study,SMartySPEM, Variability.

Abstract: Nowadays, organizations are increasingly seeking to customize their software processes according to the mar-ket needs and projects experiences. Therefore, a systematic way to achieve such an objective is the SoftwareProcess Line (SPrL) technique, in which each member is a customized software process derived from a setof similarities and variabilities of process elements. Compositional and annotative approaches are most refer-enced for variability management. In this sense, the objective of this paper is to present a comparison betweencompositional and annotative approaches targeting variability representation capabilities from the point ofview of practitioners and academic experts. The Eclipse Process Framework by means of the EPF Composertool represents compositional approach, whereas SMartySPEM represents the annotative approach. The ob-tained results provided initial evidence that the annotative approach (SMartySPEM) takes advantage over thecompositional approach (EPF).

1 INTRODUCTION

Software development companies need to quickly de-velop software with quality, which makes them adoptsoftware reuse techniques (Aleixo et al., 2013). Sucha reuse aims at improving productivity, reducing cod-ing effort and increasing quality as the software hasbeen already verified and validated.

The current scenario of competitiveness has ledsoftware companies to seek solutions beyond soft-ware reuse in order to reduce time-to-market and in-crease return on investment (ROI). Thus, software de-velopment projects need to be tailored according tothe needs of a company and its development domain(Garcia-Borgonon et al., 2014). Therefore, the Soft-ware Process Line (SPrL) technique (Rombach, 2005)is an alternative for process customization based onsimilar and variable process elements. Such ele-ments can be defined based on the concept of variabil-ity, from the Software Product Line (SPL) technique(Linden et al., 2007).

Currently, there are several tools and languagesfor software process modeling (Garcia-Borgononet al., 2014), as well as approaches that guide suchmodeling, as for instance, compositional, annotative,transformational and model-driven (Kastner, 2010;Kastner et al., 2008; Kastner and Apel, 2008). Each

approach is used in specific ways to represent vari-ability among process elements (Aleixo et al., 2013).Therefore, this work presents a qualitative empiri-cal study comparing the compositional approach, rep-resented by the Eclipse Process Framework (EPF)and its Composer tool, and the annotative approach,represented by the SMartySPEM (OliveiraJr et al.,2013) approach for variability representation in soft-ware process elements.

2 BACKGROUND

This section presents essential concepts of soft-ware process lines, variability and the OpenUP-basedSPrL, used in our qualitative study.

2.1 Software Processes and ProcessLines

A software process can be defined as a set of tech-niques and technologies to support, evaluate and im-prove software development activities. The need tospecifying software processes arises from the fact thatthe products quality can be directly influenced by theprocess adopted for their productions (Chemuturi and

Dias, J. and OliveiraJr, E.Modeling Variability in Software Process with EPF Composer and SMartySPEM: An Empirical Qualitative Study.In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 1, pages 283-293ISBN: 978-989-758-187-8Copyright c© 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

283

Cagley, 2010). The ISO/IEC 15504 standard (ISO,2012) defines a process as a set of activities that areinterrelated or interacting to transforming inputs intooutputs. This set of activities serves as a guide forthose who will be responsible for the process execu-tion and monitoring.

A software development process has four basicsteps (Sommerville, 2015): specification of the soft-ware features and premises for its development; de-sign for constructing the software according to itsspecifications; validation to ensure that the softwaremeets the users needs; and evolution in order to ac-commodate prospective necessary modifications.

Modeling of such steps are essential for a com-plete understanding of the process (Garcia-Borgononet al., 2014). Basic elements and concepts are essen-tial for software process modeling: Role, which de-scribes how people act in the process and their respon-sibilities; Task, which is an action performed by a rolefor executing or monitoring a project; Activity, whichis a set of tasks that lead to produce/consume one ormore controlled quality artifacts; Artifact, which rep-resents the result of a task; and Process, which is anorganized collection of activities.

Basic elements of a software process are essen-tial to enable process tailoring and customization,which is currently an important research topic fromthe academic and industrial point of view (Martınez-Ruiz et al., 2012; Kalus and Kuhrmann, 2013; Car-valho et al., 2014). Therefore, the term Software Pro-cess Line (SPrL), proposed by Rombach (Rombach,2005), has been considered in the last years, sug-gesting the adoption of important concepts from soft-ware product lines, such as similarities and variabil-ities. An SPrL provides techniques and mechanismsfor modeling existing similarities and variabilities in afamily of software processes, as well as the derivationof customized software processes that meet the spe-cific needs of a given software development project(Rombach, 2005; Aleixo et al., 2011).

SPrLs may contain variation points, which areprocess elements that can be instantiated in differ-ent ways. For each variation point there are vari-ant elements, which can be selected to resolve a spe-cific variation point (OliveiraJr et al., 2013). Fig-ure 1 illustrates an excerpt of an SPrL, in whichthe similar (mandatory) part is composed of the roleDeveloper and two tasks: Design the solutionand Implement solution. Such a figure also il-lustrates two variabilities: (i) the inclusion of devel-oper tests practices (Implement developer testsand Run developer tests), and (ii) the inclusion ofintegration and creating of a build (Integrate andcreate build). This excerpt can generate four dis-

tinct process instances: (i) with common elementsonly by discarding the variabilities, keeping manda-tory process elements, (ii) only resolving the variabil-ity concerned with Developer test, (iii) only re-solving the variability concerned with Integrationcontinues, and (iv) resolving both variabilities con-sidering all the elements.

2.2 The OpenUP-based SPrL

The OpenUP process complies with the principles ofthe Agile Software Development Manifest, thus it canbe taken as an agile version of the Unified Process(UP), meeting UP good practices. OpenUP is an itera-tive and incremental approach, with no specific tools.

Several activities of the OpenUP are optional,however, it does not define which elements of the pro-cesses vary from the SPrL point of view. Thus, in thework of (Aleixo et al., 2011), Aleixo et al. presentsexcerpts of the OpenUP modeled as an SPrL, definingsimilar features and variabilities. To do so, three realresearch and development projects based on OpenUPin addition to experienced practitioners were involvedin the definition of such an SPrL. The first projectdealt with the development of a software system toaudit telephone networks, the second project involvedthe development of a module of a distributed systemand the third project involved the implementation ofan integrated academic and administrative manage-ment. As a result of this analysis it was identified 586features, from which: 273 mandatory features, 239optional features and 74 alternative features.

3 VARIABILITY MODELING INSPRL WITH COMPOSITIONALAND ANNOTATIVEAPPROACHES

The success of an SPrL depends on the accuracy ofits variability management activity (Rombach, 2005).Thus, such a management is a key requirement in thedevelopment of SPrLs to provide support to specifica-tion, implementation, variability resolution and cus-tomized processes generation. Variability manage-ment defines how common and variable artifacts arerepresented and treated in order to generate processinstances from an SPrL.

There are different approaches and techniques forvariability management in the literature. They canbe classified as (Galster et al., 2013): compositional,annotative, transformational, and model-driven. Thisstudy concerns on compositional and annotative ap-

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

284

Figure 1: Excerpt of an SPrL (Aleixo et al., 2013).

proaches as they are highly referenced in the litera-ture.

3.1 Compositional Approach

The compositional approach supports modularity ofphysical features, thus generation of products occursby means of selecting and composing modules thatimplement features of desired products (Galster et al.,2013). Therefore, development techniques are high-lighted: Feature-Oriented Programming (FOP) (Leeand Kang, 2013) and Aspect-Oriented Programming(AOP) (Kiczales et al., 1997). FOP provides supportto the similarities and variabilities be modularized andeach feature implemented in a distinct module. Sucha module is an increment in the functionality of a basesystem (step-wise refinement).

An example of software process modeling usingthe compositional approach is the Eclipse ProcessFramework (EPF), which allows editing, configuringand publishing of software processes. EPF persistsprocess information according to the Unified MethodArchitecture (UMA) meta-model, developed based onthe SPEM 1.0. Subsequently, UMA inspired the cre-ation of the SPEM 2.0.

Figure 2 presents the EPF framework main partsusing the EPF Composer, a process modeling toolbased on the EPF framework, as follows:

• Method Content: standardizes representation andmanages reusable component libraries. It definesroles, tasks, work products and their relationships;

• Process: determines the sequence of phases, iter-ations and activities, and defines when tasks areperformed;

Figure 2: EPF Excerpt Illustrating Method Content, Pro-cess, Plug-ins and Configurations using the EPF ComposerTool.

• Plug-ins: represent a set of Method Content andprocess packages, allowing process customiza-tion;

• Configurations: selects a subset of Method Con-tents to form a specific process by publishing it inHTML or exporting it to MS Project or XML.

The EPF framework allows representing artifactsvariability in order to control the evolution and reuseof software processes. There are four possible typesof variability in EPF, which are:

• Contributes - contributing (variability) elementadds to a base element;

• Replaces - replacing (variability) element replacesparts of the base element;

Modeling Variability in Software Process with EPF Composer and SMartySPEM: An Empirical Qualitative Study

285

• Extends - extending (variability) element inheritscharacteristics of the base element. The base ele-ment is unchanged; and

• Extends-Replaces - combines the effects of ex-tends and replaces variability, allowing one to se-lectively replace specific attributes and relation-ships of the base element. Extending-replacing(variability) element replaces values in the baseelement that have been redefined in the extending-replacing element.

3.2 Annotative Approach

The annotative approach provides the use of prepro-cessor directives to annotate code snippets associatedwith a particular feature (Kastner et al., 2008). The Cand C++ languages already support preprocessor di-rectives. Products generation occurs by defining thevalue of the symbolic constant of pre-processing di-rectives associated with selected features, before pre-building, in order to define the presence of the featuressnippets selected in the generated product. Just as inJava annotations, which provide the option of usingmetadata over code that can be later interpreted bya compiler or pre-compiler that performs predefinedtasks. Another way of annotation is the UML stereo-types that add semantics to existing elements with nochanges in their meta-model.

Stereotype-based Management of Variability forthe SPEM meta-model (SMartySPEM) (OliveiraJret al., 2013) is an approach that provides the separa-tion of elements and their management by using a vi-sual annotation that associates notes and stereotypesto each type of process elements variability.

The SMartySPEM approach aims at supportingthe identification and representation of variabilityin processes elements modeled with SPEM. To doso, SMartySPEM introduces the profiling mecha-nism based on the SMarty approach (OliveiraJr et al.,2010) for representing variability in SPEM modeledelements with specific stereotypes. SMartySPEMis composed of a UML 2.0 compliant profile, theSMartySPEMProfile, with the following stereotypes(OliveiraJr et al., 2013):

• �variability� - represents the concept of vari-ability (UML note);

• �variationPoint� - represents the concept ofvariation point (VP icon), in which a variable pro-cess element provides a set of choices for cus-tomizing a software process;

• �mandatory� - represents compulsory pro-cess elements (MDT icon), present in every cus-tomized software process;

• �optional� - represents an optional variant;

• �alternative OR� - represents inclusive vari-ants (OR icon) to resolve a variation point;

• �alternative XOR� - represents mutually ex-clusive variants (XOR icon) to resolve a variationpoint;

• �mutex� - represents mutual exclusion con-straint (dependency relationship) among variants;and

• �requires� - represents that a given variant re-quires the presence of another variant (depen-dency relationship).

Figure 3 presents an excerpt of anArchitectural Analysis activity modeledaccording to SMartySPEM. It contains the vari-ation point Analysis Class with three relatedinclusive variants: Control Class, EntityClass and Boundary Class. Another variationpoint is Architectural Analysis with threevariants: Identifying Common and SpecialRequirements, Identifying Obvious EntityClasses and Develop Business Type Model.Architect is a mandatory element for performingthe Architectural Analysis activity. There areoptional variants, such as, Use-Case Model andArchitecture Description, which may or maynot be present in derived processes (OliveiraJr et al.,2013).

4 EPF COMPOSER VS.SMartySPEM: A QUALITATIVESTUDY

This study aims at comparing compositional andannotative approaches represented, respectively, byEPF Composer and SMartySPEM. The comparisoncriteria to be adopted were proposed in the works(Kastner, 2010; Kastner et al., 2008; Kastner andApel, 2008), namely: modularity, traceability, errordetection, granularity, adoption and systematic vari-ability management. These criteria were also used inthe qualitative study of Aleixo et al. (Aleixo et al.,2012).

The criterion of modularity aims at analyzingthe modularization degree of processes elements as-sociated with specific features, enabling a better un-derstanding and facilitating the maintenance and evo-lution of SPrLs. Traceability allows one to analyzehow difficult is viewing and mapping of all processelements along with their associated features. Theerror detection criterion analyzes how efficient is


286

Figure 3: An Excerpt of Architectural Analysis Modeled with SMartySPEM (OliveiraJr et al., 2013).

an approach for identifying cohesion errors in the def-inition of an SPrL and its elements, as well as itsderived processes. Granularity evaluates the ap-proach support for representing variability in coarseand fine granularity, considering the division of theprocess in small or large parties. The adoption crite-rion discusses the difficulty of adopting an approach,analyzing necessary pre-knowledge to be taken to ap-plying such an approach. Systematic variabilitymanagement analyzes the mechanisms provided by anapproach for specifying variability.

4.1 Objective

The aim of this study is to obtain experts’ feedbackwith regard to the criteria for each approach. Then,compare such approaches in order to be able to draw

initial evidence based on each criterion.

4.2 Planning

As study object we used the OpenUP-based SPrLfrom Section 2.2. As such an SPrL is too largewith hundreds of features, we chose only theRequirements Specification feature.

Participants were given eight documents: a studyconsent stating the confidentiality of the responses;a characterization questionnaire to measure the par-ticipant’s experience; a document with main con-cepts of SPrL; a document about the compositionalapproach using the EPF framework; a documentabout the annotative approach using SMartySPEM; adocument with the modeling of the RequirementsSpecification feature in EPF (Figure 4); and a


287

document with the modeling of the RequirementsSpecification feature in SMartySPEM (Figure 5).After the trainning session, each participant was giventwo questionnaires containing six questions. Eachquestion with regard to each criterion for each ap-proach. Then, participants should answer the follow-ing questions, replacing TYPE OF APPROACH with“Compositional” or “Annotative”:

1. The modularity criterion measures the quan-tity of modules (groups of process elements)necessary for representing an SPrL, thus isit possible to measure the modularity of theTYPE OF APPROACH approach?

2. The traceability criterion allows analyzing thevisualization and mapping difficulty of all pro-cess elements along with their features, thus isit possible to visualize the traceability of theTYPE OF APPROACH approach?

3. The error detection criterion analyzes how ef-ficient is an approach to identify cohesion errorsin the definition of an SPrL and its elements,as well as the derived processes from the SPrL.Is it possible to detect cohesion errors in theTYPE OF APPROACH approach?

4. The granularity criterion aims at evaluating theapproach support for representing variability incoarse and fine granularities (level of abstraction),thus considering the process division in small orlarge parts, is it possible to evaluate the granular-ity at the TYPE OF APPROACH approach?

5. The adoption criterion discusses the difficultyof adopting an approach, analyzing the amountof previous knowledge for applying an approach,thus have you experienced any difficulties forunderstanding the TYPE OF APPROACH ap-proach?

6. The systematic variability managementanalyzes the provided mechanisms of an ap-proach for specifying variability. Do you considersufficient the variability mechanisms of theTYPE OF APPROACH approach?

Participants of this study were carefully selectedbased on their experience with software process. Inaverage, each participant had ten years of experienceworking with software processes. Thus, twelve par-ticipants were invited for this study, from which oneparticipant was invited for a pilot study for evaluat-ing our instrumentation, thus his/her results were dis-carded. Amongst the participants are researchers andpractitioners from the State University of Maringa(UEM), Federal University of Sao Carlos (UFSCar),Federal Technological University of Parana (UTFPR)

Figure 4: The OpenUP-based SPrL Requirements Specifi-cation Using the EPF Composer.

and University of York, all of them with masters orPh.D.

The realization of a pilot study led us to changes inthe study planning as, for instance, in the study dura-tion time. At first, we distributed all the materials andasked the pilot study participant to answer the two setsof six questions. This whole process took about twohours and forty minutes, making the participant tiredand bored. Thus, we decided two divide it into twoparts, each part in different days: the first one involv-ing only one of the approaches and the second one theother approach. Therefore, each part of the study tookno longer than 50 minutes.

Another necessary change based on the pilotproject results was removing the uniformity criterionthat aimed at assessing the technology or indepen-dent meta-model. As the two approaches depend onspecific tools (EPF Composer and a UML Tool), weunderstand that such a criterion could be a potentialthreat to our study as the participants do not haveenough experience with these tools, especially EPFComposer.


288

Figure 5: The OpenUP-based SPrL Requirements Specification According to SMartySPEM.

For reducing the threats to validity of the study, foreach participant we changed the order of the evaluatedapproach. Then, five participants firstly received theannotative approach (SMartySPEM), whereas six par-ticipants firstly received the compositional approach(EPF Composer).

Responses from the experts were qualitativelyanalyzed using Grounded Theory (GT) procedures(Corbin and Strauss, 2008). The GT approach isbased on coding concepts. Coding allows one to as-sign codes or labels for text snippets (Open Coding),which can be grouped and classified (Axial Coding)according to an idea expressed in order to elucidatea given phenomenon (Corbin and Strauss, 2008). Asa result, such codings enabled the creation of a con-ceptual model. During the encoding process two cat-egories were created “Feasible Criteria” and “Non-Feasible Criteria”, thus grouping answers with re-spect to each criterion. An assistance tool for qual-itative analysis was used, named Dedoose. Such atool allows one to import a spreadsheet with results,then creating codings in specific excerpts of the an-swers. The created codings can relate to one anotherin a significant level. Then, after creating all codingsone can produce graphical representations, such as,charts with different results visualizations.

4.3 Results

Figure 6 presents the results of this study as a com-

parison of the answers for each criterion of EPFComposer and SMatySPEM. The more centralizedthe line is (red or blue) in the chart the worse isthe evaluation of a given criterion. As a result, thecompositional approach was better evaluated for cri-teria Modularity and Error Detection, whereasthe annotative approach was better evaluated for cri-teria Traceability, Granularity, Adoption andSystematic Variability Management.

Modularity in the annotative approach obtainednine positive evaluations, for example, expert #3 an-swered that “...it is possible to measure such a modu-larity, as well as presenting the relationship betweenprocess elements in a module. Such a view contributesto the comprehension of what happens in each processmodule and, consequently, enables better understand-ing the tasks of a given derived process...”. However,it took two negative answers. Expert #5 stated that“...SMartySPEM does not appear to enable an effec-tive organization of the process elements of an SPrL.It is possible to establish the relations, but not dis-tribute them so efficiently...”. Expert #4 answered that“...as the process model grows, measuring modular-ity becomes more complex as it depends on the vi-sualization (annotations) of all process elements in adiagram...”. In fact, for large SPrLs, visualization ofthe modules is jeopardized due to the amount of el-ements and annotations in a same diagram. On theother hand, the compositional approach took 100% ofpositive answers as it allows grouping the SPrL com-


289

!

"

#

$

%

& !

& "

!"#$%&'()*

+'&,-&.(%()*

/''"'01-)-,)("2

3'&2$%&'()*

4#"5)("2

6*7)-8&)(,09&'(&.(%()*0!&2&:-8-2)

422")&)(;-0455'"&,< ="85"7()("2&%0 455'"&,<

Figure 6: Spider Chart for Evaluating Compositional and Annotative Approaches based on the Defined Criteria.

ponents in hierarchical packages, with a better visu-alization of the modules as, for instance, reported bythe expert #5 “...EPF Composer is able to encapsu-late the compositional elements in a satisfactory way.The use of plugins, method contents and configura-tions enables reusing such modules in an agile andintuitive way...”.

The error detection criterion was not satisfactoryfor both compositional and annotative approaches, asnone of them provides verification activities. How-ever, the compositional approach took a subtle ad-vantage as the EPF Composer checks models at spe-cific process publication (derivation) time as statedby expert #11 “...it has some kind of support mech-anisms for error detection. Some filters, as in theassociation with variabilities avoid wrong contri-butions/replacements/extensions of incompatible pro-cess elements...”. On the other hand, in the annota-tive approach, as it is an UML extension and it allowsthe relationship among several different elements, itis difficult to detect errors, as said by expert #8 “...Be-cause there is no automation of the approach, theonly way to detect errors would be based on reviewsand in-depth analysis comparing the process model-

ing with the description of the SPrLs elements...”.

Traceability obtained all the positive ratings forthe annotative approach as it has a very visual ap-peal, facilitating the identification and traceabilityamong process elements, as well as the realizesmeta-attribute of the stereotypes �variability� and�variationPoint�, which represents a collection oflow-level models that realizes a given variability. Anexample is the statement from expert #8 ”...traceabil-ity is perceived by means of dependencies amongprocess elements, as well as the realizes meta-attribute from variabilities or optional and variationpoint elements...”. For the compositional approacheight positive answers were given as such an approachallows relationships among process elements. How-ever, various negative aspects were pointed out as thedifficulty of graphically visualization of the relationsbetween elements, and hiding of variability elementsas stated by the expert #5 ”...The user accessing thepublished process, in html format, generated by theEPF Composer can not visualize inherited packagesand configurations of a given element, when its vari-ability allows such a visualization...”.

The granularity criterion had much more positive


290

evaluations for the annotative approach than the com-positional due to the possibility of modeling differ-ent types of diagrams representing different abstrac-tion levels of SPrLs. For instance, flow of activitieswith Activity elements for coarse-grained granularityand diagram description of a process with activitiesas fine-grained granularity. We can observe these ex-amples from the expert #2 answer excerpt as follows:“...the annotative approach clearly presents two lev-els of abstraction encompassing both fine and coarse-grained granularity, as the Activity process elementprovides such an abstraction. Abstraction levels al-low and facilitate the visualization of the whole pro-cess, as well as make it easier identifying the vari-ation of each of the process elements in lower-levelabstraction levels...”. In the compositional approachthis criterion obtained seven negative evaluations, be-cause of the approach consider only one low abstrac-tion level, not allowing a wide view of the SPrL. Ex-amples of this characteristic are the expert #5 answer“...the compositional approach has fine-grained gran-ularity as the EPF Composer is aimed at configuringall aspects of the process by structuring it in detail...”and the expert #1 answer “...There is no higher ab-straction level in order to compare variabilities of anSPrL...”.

The adoption criterion obtained nine positive eval-uations for the annotative approach against seven forthe compositional approach. We understand that thisis straightforwardly related to the influence that theannotative approach because of the UML standard no-tation as we can see in the statements of expert #4“...the level of difficulty on applying the approachis low...”, expert #10 “...I had no difficulty at under-standing the approach as the number of elements to belearned for adopting the approach is not very large. Iwould adopt the approach without much effort...” andexpert #11 “...I believe that the difficulty of adoptingthis approach is low, as its stereotypes, comments andelements are quite similar to UML representations...”.On the other hand, in the compositional approach, be-havior complexity and use of variability types influ-ences the adoption of such an approach, as well asdifficulties in using the EPF Composer tool to manip-ulate the SPrL elements, as reported by the expert #2“...I had difficulties mainly in the elements that definevariability. Also, such a tool needs extra effort on cre-ating and maintaining process elements...”.

For systematic variability management thecompositional approach was highly unsatisfactory,according to the experts evaluation, because of itsvariability mechanisms, because of the visualizationof the applied variabilities to process elements. Inaddition, the experts judged that the four variabil-

ity types are not enough. It can be noted in theexpert #10 statement “...as I have knowledge of otherapproaches for variability representation in softwareproduct lines, I understand that different variabil-ity mechanisms could be added to the EPF Com-poser. Thus, I judge such a set of mechanisms insuffi-cient...”, and in the statement of the expert #9 “...somenew mechanisms of variability types are necessaryas, once there is the extend mechanism, it must ex-ist include, mandatory and optional mechanisms...”.In the annotative approach variability mechanismshad more positive evaluations as such an approachhas specific stereotypes for representing variabilityof each process element type. Exemplary statementsexcerpts from experts are: expert #1 stated that “...Ibelieve the variability mechanisms are sufficient asstereotypes allow the specification of different vari-ability types...”; expert #3 said “...I understand theSMartySPEM variability mechanisms are sufficientto significantly demonstrate the types of relation-ships between a variation point and variants...”; andexpert #10 said “...I consider the variability mecha-nisms adequate for representing mandatory, alterna-tive and optional elements. Furthermore, the mech-anisms allow clearly visualize where variation pointsand variants take place in a non-ambiguous basis forthose who use process models...”.

4.4 Validity Evaluation

Results validity evaluation is an essential issue of em-pirical studies (Wohlin et al., 2000). We discuss themain threats relevant to our study, as follows:

Internal Validity. Tasks performed by expertswere conducted in a similar manner except the orderof the application of the study objects and question-naires, which were random. Experts were trained onthe basics of SPrLS and variability in compositionaland annotative approaches using EPF Composer andSMartySPEM. We reduced the fatigue effects allow-ing the experts to answer the questionnaires in at mostfifteen days;

External Validity. Features related to Require-ment Specification of the OpenUP-based SPrL wereused during both the training sessions and the empiri-cal study. This could jeopardize the external validity,thus we tried to use original and technical documentsof the OpenUP;

Conclusion Validity. The major threat to con-clusion is related to the sample size, eleven experts.However, prior knowledge of such experts is signifi-cant. Therefore, we understand that for a qualitativestudy in which grounded theory procedures, such asCoding, were established eleven experts is a satisfac-


291

tory number;Contruct Validity. This study was planned based

on a pilot project carried out for evaluating the instru-mentation and its duration time for the application ofquestionnaire. Although the knowledge level requiredon software process and variability is essential, partic-ipants presented a high level of expertise.

5 RELATED WORK

Compositional and annotative integration and/or com-parative studies have been carried out in the litera-ture for several different domains, such as embed-ded systems and software product lines (Kastner andApel, 2008; Ferreira Filho et al., 2013; Behringer,2014). For software process lines or process tailor-ing/customization there is a lack of such a study type.

The study of Aleixo et al. (Aleixo et al., 012a) isthe most direct related work to ours in the literature,in which they empirically compare variability capa-bilities in compositional and annotative approachesfor SPrL based on EPF Composer and GenArch-P.GenArch-P is a model-driven approach to managingand customizing software process variabilities pro-posed in (Aleixo et al., 2010). The comparison isbased on the same criteria adopted in our study, ex-cept that we discarded the uniformity criterion. As inour study, Aleixo et al. come up with better results forthe annotative approach.

6 CONCLUSION

This paper presented an empirical qualitative studycomparing the representation of variability in com-positional and annotative approaches. Such a studyprovided, although initial, evidence that the anno-tative approach, in this study represented by SMar-tySPEM, has more advantages over the compositionalapproach, represented by EPF Composer. Althoughthe criteria of modularity and detection errors hadlower results in the annotative approach, they mightbe improved by using UML packages for modularityand applying inspection activities for error detectionsuch as in (Geraldi et al., 2015).

As future work, we intend to plan and conductempirical quantitative studies in order to compare ourannotative approach, the SMartySPEM, to other com-positional and annotative approaches. In addition, weare working on the establishment of a Scrum-basedSPrL by taking real projects experience from indus-try as well as practitioners as Scrum Masters exper-tise as there is no real SPrL available in the literature

for carrying out empirical studies and evaluating ourSPrL-related theories and tools.

As a potential future work, we are consideringstudying the granularity criterion on the specificationof lower-level software process activities, such as, inbusiness process models, allowing one to customizethe steps of the activities as, for instance, in multite-nancy architectures of Software as a System (SaaS).

ACKNOWLEDGEMENTS

The authors would like to thank Masters and Ph.D.lecturers an practitioners experts for attending thisstudy and for their valuable contribution on assessingthe compositional and annotative approaches.

REFERENCES

Aleixo, F., Freire, M., Santos, W., and Kulesza, U. (2010).A Model-driven Approach to Managing and Cus-tomizing Software Process Variabilities. In Interna-tional Conference on Enterprise Information Systems,pages 92–100. SCITEPRESS.

Aleixo, F. A., Freire, M., Alencar, D., Campos, E., andKulesza, U. (2012a). A Comparative Study of Com-positional and Annotative Modelling Approaches forSoftware Process Lines. In Brazilian Symposium onSoftware Engineering, pages 51–60.

Aleixo, F. A., Freire, M. A., Santos, W. C., and Kulesza,U. (2011). Automating the Variability Manage-ment, Customization and Deployment of SoftwareProcesses: a Model-Driven Approach. In Filipe, J. andCordeiro, J., editors, Enterprise Information Systems,volume 73 of Lecture Notes in Business InformationProcessing, pages 372–387. Springer Berlin Heidel-berg.

Aleixo, F. A., Kulesza, U., Freire, M. A., da Costa, D. A.,and Neto, E. C. (2012). Modularizing software pro-cess lines using model-driven approaches - a compar-ative study. In International Conference on EnterpriseInformation Systems, pages 120–125. SCITEPRESS.

Aleixo, F. A., Kulesza, U., and OliveiraJr, E. (2013). Mod-eling Variabilities from Software Process Lines withCompositional and Annotative Techniques: a Quanti-tative Study. In International Conference on Product-Focused Software Development and Process Improve-ment, pages 153–168.

Behringer, B. (2014). Integrating Approaches for Fea-ture Implementation. In ACM SIGSOFT InternationalSymposium on Foundations of Software Engineering,pages 775–778, New York, NY, USA. ACM.

Carvalho, D. D., Chagas, L. F., Lima, A. M., and Reis, C. A.(2014). Software Process Lines: A Systematic Lit-erature Review. In Mitasiunas, A., Rout, T., OCon-nor, R., and Dorling, A., editors, Software ProcessImprovement and Capability Determination, volume


292

477 of Communications in Computer and InformationScience, pages 118–130. Springer International Pub-lishing.

Chemuturi, M. K. and Cagley, T. M. (2010). MasteringSoftware Project Management: Best Practices, Toolsand Techniques. J. Ross Publishing, Inc.

Corbin, J. M. and Strauss, A. L. (2008). Basics of Qualita-tive Research: Techniques and Procedures for Devel-oping Grounded Theory. Sage Publications, Inc.

Ferreira Filho, J. a. B., Barais, O., Acher, M., Baudry, B.,and Le Noir, J. (2013). Generating Counterexam-ples of Model-based Software Product Lines: An Ex-ploratory Study. In International Software ProductLine Conference, pages 72–81, New York, NY, USA.ACM.

Galster, M., Weyns, D., Tofan, D., Michalik, B., and Avge-riou, P. (2013). Variability in Software Systems ASystematic Literature Review,. IEEE Transactions onSoftware Engineering, pages 81–90.

Garcia-Borgonon, L., Barcelona, M. A., Garcia-Garcia,J. A., Alba, M., and Escalona, M. J. (2014). Soft-ware Process Modeling Languages: a Systematic Lit-erature Review. Information and Software Technol-ogy, 56(2):103–116.

Geraldi, R. T., OliveiraJr, E., Conte, T. U., and Steinmacher,I. F. (2015). Checklist-based Inspection of SMartyVariability Models: Proposal and Empirical Feasibil-ity Study. In International Conference on EnterpriseInformation Systems, pages 268–275. SCITEPRESS.

ISO (2012). ISO/IEC 15504-5:2012 Information technol-ogy – Process Assessment – Part 5: An ExemplarSoftware Life Cycle Process.

Kalus, G. and Kuhrmann, M. (2013). Criteria for SoftwareProcess Tailoring: A Systematic Review. In Interna-tional Conference on Software and System Process,pages 171–180, New York, NY, USA. ACM.

Kastner, C. (2010). Virtual Separation of Concerns: To-ward Preprocessors 2.0. PhD thesis, Otto von Guer-icke University Magdeburg.

Kastner, C. and Apel, S. (2008). Integrating Compositionaland Annotative Approaches for Product Line Engi-neering. In Workshop on Modularization, Composi-tion and Generative Techniques for Product Line En-gineering, pages 35–40.

Kastner, C., Apel, S., and Kuhlemann, M. (2008). Gran-ularity in Software Product Lines. In InternationalConference on Software Engineering, pages 311–320.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C.,Lopes, C., Loingtier, J.-M., and Irwin, J. (1997).Aspect-Oriented Programming. In European Confer-ence on Object-Oriented Programming, pages 220–242. Springer Berlin Heidelberg.

Lee, H. and Kang, K. C. (2013). A Design Feature-basedApproach to Deriving Program Code from Features:A Step Towards Feature-oriented Software Develop-ment. In International Workshop on Variability Mod-elling of Software-intensive Systems, pages 1–6, NewYork, NY, USA. ACM.

Linden, F. J. v. d., Schmid, K., and Rommes, E. (2007).Software Product Lines in Action: The Best Indus-

trial Practice in Product Line Engineering. Springer-Verlag New York, Inc., Secaucus, NJ, USA.

Martınez-Ruiz, T., Munch, J., Garcıa, F., and Piattini, M.(2012). Requirements and Constructors for TailoringSoftware Processes: a Systematic Literature Review.Software Quality Control, 20(1):229–260.

OliveiraJr, E., Gimenes, I. M. S., and Maldonado, J. C.(2010). Systematic Management of Variability inUML-based Software Product Lines. Journal of Uni-versal Computer Science, 16:2374–2393.

OliveiraJr, E., Pazin, M. G., Gimenes, I. M. S., Kulesza,U., and Aleixo, F. A. (2013). SMartySPEM: a SPEM-based Approach for Variability Management in Soft-ware Process Lines. In International Conference onProduct-Focused Software Development and ProcessImprovement, pages 169–183. Springer Berlin Heidel-berg.

Rombach, D. (2005). Integrated Software Process andProduct Lines. In International Conference on Uni-fying the Software Process Spectrum, pages 83–90.Springer-Verlag Berlin.

Sommerville, I. (2015). Software Engineering. Pearson, 10edition.

Wohlin, C., Runeson, P., Host, M., Ohlsson, M. C., Reg-nell, B., and Wesslen, A. (2000). Experimentation inSoftware Engineering: an Introduction. Kluwer Aca-demic Publishers, Norwell, MA, USA.


293

Modeling Variability in Software Process with EPF Composer ...

Documents