Figure 2.2: Break-even point for a SPL
are capitalized by all products. An error detected in a product can be relatively easy to correct in all products of the line thanks precisely to the existence of the common framework offered by the product line. As a straight consequence from this point, the quality of the products is enhanced. The products built within a SPL are much less prone to have bugs because their code has already been tested for the rest of the products already built.
The last main advantage of using a SPL is the reduction of time to mar-
ket [PBL05], often a very critical success factor. Although the time to market for the first products of a SPL is higher, because the common artefacts have to be built first, as soon as the SPL is developed and running the time to market of new products is shortened since most of the code of the new products is already written. As opposite, in traditional development, this time is always linear to the number of products (see Figure 2.3). Even in the case that a customer requires a feature not provided by a SPL, a similar product an be generated with all the rest of the features and then this new feature can be added, shortening anyway the time to market of this new application.
2.3
Unsolved problems
There are many well-known success stories in the use of software product
16 Chapter 2. SPLE: state of the art
Figure 2.3: Time to market for a SPL
proposed, SPL still pose many challenges from the research point of view [MP14].
Some of them as discussed below.
• Optimizing the scope of a SPL. Instead of developing very specialized
product families, it would be interesting to optimize the scope of a product taking into account not only market aspects but technical aspects such as the life-cycle management of features, the core assets which implement them and the product architecture. Finally, the economic viability of the whole product line has to be considered as well.
• Describing the interrelation between scope, requirements, features
and other development activities. This is, traceability has to be explicitly
stated between all the stages of the development of a product within a SPL. This way, the impact of requirement changes and the evolution of both the platform of the SPL and the product can be properly handled. Maintaining a clear traceability also facilitates changing a specific core asset for a new version, for example.
• Eliciting and handling application-specific deviations. State of the art
SPL usually do not cope with customer-specific requirements. However, even when we are dealing with products belonging to a family, there are domains in which some application-specific requirements, features or components needs
2.3. Unsolved problems 17
have to be managed by th SPL in all the stages of the development process, from the design of the products to their maintenance, going through the derivation of the application-specific code. We deal with one of such domains in this work, web-based geographic information systems (see Chapter 5). In this work we address each one of this issues. The methodology we use to approach the definition of our product line, described in Chapter 3, specifically provides tasks for solving the first and second issue: most of the decisions regarding the product line are solved by taking into account technical aspects of existing products, literature and technical knowledge from experts; at the same time, traceability is maintained all over our process. Furthermore, handling application- specific deviations is totally achieved in our product line from the moment we deal with specific data model specifications for each product.
To conclude, the application of software product lines in the development companies of software has been limited to very specific contexts such as the
development of embedded systems [BRN+13,WCK06,Van02]. In other more complex
areas, such as the development of web applications or other fields with cutting-edge and changing technologies, the application of SPLE is becoming more frequent. But the proposals in the literature usually focus in the domain variability model at a higher abstraction level rather than in the management of variability at
the implementation level [MSC+14]. Therefore, there is a need for new SPL
3
Industrial expertise in the definition of a
Software Product Line: a new methodology
3.1
Introduction and motivation
One of the objectives of this work is to use the resulting tool within a real software development company, Enxenio. In order to achieve this goal, we have had the collaboration of GIS experts from the company all over our process, taking us
to a privileged and unusual context for carrying out this work. Enxenio is a
Spanish small and medium enterprise with expertise in geographic information
systems. In fact, this company is a leading provider of web-based geographic
information systems at the Galicia region, with many previous projects for the public administration and private clients. Enxenio has collaborated with the Database Laboratory at the University of A Coruña for a long time, and several works, such as [LPFCP09,BCLF+07,PBF+07], are some results from this relationship. For our present work, Enxenio has been helping with their expertise and their existing web- based GIS applications. This collaboration is not altruistic since Enxenio would benefit greatly from the outcome of this thesis, since the application of SPLE for the development of future GIS would give the company a strategic advantage.
In order to make the best from this collaboration, we have looked for the 19
20 Chapter 3. Industrial expertise in the definition of a SPL: a new methodology
most adequate methodology for the definition of our SPL. We have found that the methodology to follow must comply with the next requirements:
• The methodology has to make the role of experts with knowledge about
architectures, requirements and technology explicit.
• Considering that direct access to the souce code of the products may be
provided, the methodology must take the source code into account.
• The software product line domain (in our case, geographic information
systems) may have undergone a strong standardization effort that the methodology must not ignore.
• Finally, if the software product line is to be used in the real industry,
the platform and the generated products will evolve and therefore, the methodology must facilitate handling this evolution.
We have found two different methodologies that comply with some of this
requirements: Magro et al. [MGP09] and Nakagawa et al. [NBM13].
Magro et al. [MGP09] defines six steps based on the works of Bosch [Bos00],
DSouza & Wills [DW99], and Mili et al. [MMYA02], and shows an example of its
application for the construction of a SPL for validation systems. The six steps defined in this work are:
1. Definition and analysis of the domain, not only to use this information in furthers steps of the process but also to check if the application of SPLE in the selected domain is feasible and advantageous.
2. Product planning. All kind of requirements associated to the different
products of the domain have to be accounted for.
3. Design of the architecture of reference by identifying the architectural components, their design and their interactions.
4. Development of the reference architecture components. This fourth step
consisted in specifying and analysing the components of the architecture. 5. Architecture evaluation in order to detect problems and drawbacks. 6. Derivation of a specific product.
Nakagawa et al. in [NBM13] describe ProSA-RA2PLA, a methodology focused
on the product line architecture (PLA) design. They define an iterative process of five steps (see Figure 3.1):
3.1. Introduction and motivation 21
1. Reference architecture identification/selection, in which the reference archi- tecture is selected taking into account the needs and the scope of the product line.
2. Elements selection/prioritization. They sort the elements from the reference architecture in order of importance, and even not all of them need to be considered for the product line.
3. PLA structure building, the step in which the product line architecture is designed.
4. Variability model building. The PLA variability is identify and designed in this step.
5. PLA evaluation to check if the elements from the reference architecture that were considered important for the product line were indeed added to the final PLA.
Figure 3.1: Structure of ProSA-RA2PLA by [NBM13]
We adapted the methodology of Magro et al. by decomposing the steps related with the PLA design (three and four) into those suggested by Nakagawa et al. In
22 Chapter 3. Industrial expertise in the definition of a SPL: a new methodology
addition, we also considered the work of Diaz et al. [DPG14], since the traceability
among the requirements and the PLA is a key issue for guaranteeing the SPL
maintenance [AK04]. This issue was also considered by Iida et al. [IMY+16] for the
construction of an automotive braking system SPL.