section5.tex

%TODO [OK] Cortar essa secão, manter somente de 3 a 4 parágrafos.

%TODO [OK] Tentar sintetizar os trabalhos em uma Tabela

\section{Related Work} \label{section5}

Our paper encompasses three main perspectives in industrial environments: (i) m-learning applications; (ii) SPL, with its benefits through variability management; and (iii) Experimental Software Engineering. Adopting SPL as methodology to develop m-learning applications allowed us to get positive evidence in a real industry environment about two measurable SPL benefits: quality of products and time-to-market, when experimentally compared with a singular software development process without a variability management approach to support the developers. Thus, our results come to complement the experiences related in other researches for these three perspectives.

In this context, \cite{bezerra09} conducted a systematic literature review of SPL applied to mobile middlewares, but only six studies were significant for the review. According to the authors, the few results obtained highlight the need of more research in the area. Besides that, \cite{chen11} in other systematic review, concluded the status of evaluation of variability management approaches in SPL engineering was quite unsatisfactory. Thus, we identified some relevant related works, described in order of importance in the Table \ref{tab:related-works}.

\begin{table}[ht]
\centering
\caption{Summary of Related Works}
\label{tab:related-works}
\resizebox{\textwidth}{!}{%
\begin{tabular}{|P{2.5cm}|P{2.85cm}|p{10.3cm}|}
\hline
\textbf{Author(s)} & \textbf{Domain} & \textbf{Findings} \\ \hline
\cite{gamez14} & SPL for mobile systems & Propose a self-adaptation of mobile systems with dynamic SPL. The management of variabilities is achieved using the Common Variability Language (CVL). \\ \hline
\cite{marinho10} & SPL for mobile and context-aware applications & Describe an architecture for nested SPL in the domain of mobile and context-aware applications. However, the authors did not specify how to improve the management of variabilities. \\ \hline
\cite{jaring02} & SPL variability management & Conducts a case study focused on professional mobile communication infrastructures. They discuss the need for handling variability in a more explicit manner, analysing the SPL and a method to represent and normalize variabilities. Some issues were highlighted, such as the need of a notation format to describe the variabilities. \\ \hline
\cite{hubaux10} & SPL variability management & Combine variability representation and industrial case studies evaluations. They developed a Textual Variability Language (TVL) combining graphical and textual notations and performed an evaluation through a quantitative and qualitative analysis, considering four cases from different companies, sizes and domains. \\ \hline
\cite{eriksson09} & SPL variability management & Describes an approach to manage natural-language requirements specifications in a SPL context. \\ \hline
\cite{ardis00} & SPL variability management and tests & Use the Family-Oriented Abstraction, Specification and Translation (FAST) approach as a development process for an SPL in a case study, covering all aspects of domain analysis with tests. According to the authors, test process in an SPL presents significant challenges.  \\ \hline
\cite{gacek01} & SPL tests & Presents a case study regarding the adoption of SPL in a small company. An holistic view of the challenges and changes in business was discussed, especially the automatization of tests in their developed components. \\ \hline
\end{tabular}%
}
\end{table}

%In mobile applications development domain, Gamez et al \cite{gamez14} proposed a self-adaptation of mobile systems with dynamic SPL. The management of variabilities is achieved using the Common Variability Language (CVL). Marinho et al \cite{marinho10} proposed an architecture for nested SPL in the domain of mobile and context-aware applications. However, the authors did not specify how to improve the management of variabilities.  

%Jaring and Bosch \cite{jaring02} presented a case study in a Dutch-based company, Rohill Technologies BV -- a system development for, mainly, professional mobile communication infrastructures. They discussed and analyzed the need for handling variability in a more explicit manner, discussing the SPL and a method to represent and normalize variabilities. Some issues were highlighted, as the limited insight into the consequences of selecting a particular variability mechanism for variability identification; the need of a notation format to describe variability; and the fact that dependencies between variability and features are not made explicit to variability dependencies.

%Hubaux et al \cite{hubaux10} combined variability representation and industrial case studies evaluations. They developed a Textual Variability Language (TVL) combining graphical and textual notations and performed an evaluation through a quantitative and qualitative analysis, considering four cases from different companies, sizes and domains. Positive benefits for TVL were identified, as the efficiency gained in terms of model comprehension, design and learning curve for the notation. Limitations were presented as well, such the difficulty in the adoption of the notation, since it can not be integrated in modeling tools. 

%Eriksson et al \cite{eriksson09} also presented a language, but to manage requirements specifications for SPL. Using a qualitative evaluation they compared the clone-an-own reuse with the proposed approach, which must be used together with a previously developed method to manage product line use cases models. Six variables were analyzed: adoption effort, expressiveness, scalability, ROI, risks and reuse infrastructure. The ROI variable presented negative results, whereas the others presented positive evidences for the proposed language. 

%Still in the context of SPL evaluation in industry, but focusing on quality through software testing, Ardis et al \cite{ardis00} used the Family-Oriented Abstraction, Specification and Translation (FAST) approach as a development process for an SPL in a case study, covering all aspects of domain analysis with tests. According to the authors, test process in an SPL presents significant challenges. Thus, they presented, for each case study, three testing strategies suitable for general use in SPL testing: (i) testing common code thoroughly; (ii) exploiting common aspects of variable code; and (iii) using scenarios from the commonality analysis. 

%Gacek et al \cite{gacek01} presented a case study regarding the adoption of SPL in a small company. An holistic view of the challenges and changes in business was discussed, especially the automatization of tests in their developed components. Firstly, each single component was tested and, then, the entire system at runtime, using a special code inserted in each component. If an error occurred, the inserted test code identified automatically which component misbehave. The testing process was conducted only for components that were present in the instantiated product, i.e., components were not tested in their full flexibility, with respect to all possible instantiations in the family.

%Batory et al \cite{batory02} defined a Product Line Architecture (PLA) with a Domain-Specific Language (DSL) to redesign an extensible command-and-control simulator for army fire support. In the case study, they collected preliminary results that PLA with DSL produce a more flexible way to implement the simulator and reduce the program complexity, if compared with the same simulator, with pure Java implementation. The complexity of the code was compared based on the number of methods, number of lines of code and tokens/symbols for both the adopted approach and the Java implementation.

It is important to highlight that neither \cite{gamez14} nor \cite{marinho10} allowed us to conduct a direct comparison with respect to our work, because these works explore a more generic SPL domain. On the other hand, the works of \cite{hubaux10}, \cite{eriksson09} and \cite{ardis00} proposed the specification of variabilities through language and graphical representations in industry case studies. In our research, the representation of variability was made using the  SMarty approach, which has already been evaluated in other experimental studies \cite{marcolino13,marcolino14a,marcolino14b,bera15,marcolino2017}.

Only two studies addressed some quality issues and tests, as our work. \cite{ardis00} defined a testing approach based on modeling test cases with an integer tuple. However, the proposed method was applied only in the context of SPL, not considering the SSD methodology. \cite{gacek01} adopted two-fold strategies in a case study to test the SPL products. Firstly, single components were tested by the developers themselves; secondly, the system was tested at runtime in the target environment using special test code inserted in each component. Similar to the \cite{ardis00} study, only the SPL methodology was considered, differing from our evaluation, which defined several test cases with a group of quality analysts from a software industry encompassing both SPL and SSD methodologies.

Finally, in spite of all related works having been applied in industry, but only few of them compared methodologies, such as SPL and singular development, highlighting which of these methodologies brings more quality and reduces time-to-market when supported by a variability management approach. Additionally, there still are several opportunities and open issues regarding the management of variabilities and experimental evaluation, particularly in the m-learning domain. This lack of researching in the area has motivated our work.