-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsection4.tex
22 lines (13 loc) · 3.51 KB
/
section4.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
\section{Lessons Learned}\label{section4}
As the main lessons learned during the execution of the activities discussed herein, we highlight:
\begin{itemize}
\setlength\itemsep{1em}
\item \textbf{Domain Characteristics:} domain analysis can be considered one of the most important activity for the creation of an SPL. The evolution of the requirements catalog \cite{filho13} significantly contributed in terms of domain knowledge, supporting the adoption of the proactive model for the development of \texttt{M-SPLear\allowbreak ning}.
\item \textbf{Variability Management:} the adoption of SMarty helped in the identification of the variation points during the design of \texttt{M-SPLear\allowbreak ning}, ensuring more quality in the implemented components from the SPL. It also contributed to the better assimilation of the SPL concept. However, those involved must be trained accordingly, so SMarty can be used consistently.
\item \textbf{SPL Architecture:} SPL requires mechanisms to allow a transparent and easy manner to reflect all updates in the core assets in the architecture, and vice versa. That is, changes to the core assets require more efforts to maintain architectural integrity. Additional tools and analysis must be done to guarantee that all changes, or in the architecture or in the components, are reflecting all features and behaviors that the line has until that moment.
\item \textbf{SPL Development:} considering \texttt{M-SPLear\allowbreak ning}, the implementation of something generic and customizable is significantly different from a single-product-at-time approach. Therefore, developing features in an SPL requires a greater effort, which is justified by the subsequent gains of reuse \cite{clements02}.
On the other hand, the single-product development methodology hinders the maintenance of the products, without any rigorous development process defined. As all developers tend to program in their own way, giving support for each product developed, in most cases, can take more time and costs. If an SPL practice is adopted, being rigorously followed, time and cost to give support tend to decrease.
\item \textbf{Experimental Evaluation:} researches show that test executions in SPL are scarce and need to be evaluated and validated \cite{engstrom11}. Thus, the authors decided to apply the test cases in the products generated by the SPL, enabling an interesting comparison with an alternative methodology of development.
The experimental evaluation provided relevant results for the adoption of \texttt{M-SPLear\allowbreak ning}. The choice for active practitioners from the industry contributed to the reduction of the training session. However, experience and understanding of the concepts by the participants is always a difficult issue to be measured.
In addition, the use of testing techniques in the traditional development process and new ways to quickly test products from an SPL require more attention and research. One benefit in the adoption of SPL is about the quality improvement, since the products and their components are tested in several instances, leading to a quickly fix for the final client. Despite the use of the components in a large number of products and, consequently, for a higher number of target users for SPL, the way that the components and products were tested could be improved to be done in more aligned manner with the SPL specificities. Literature reflects more concern to test the SPL architecture in comparison to test the final components and products \cite{machado2014,net2011}.
\end{itemize}