Evaluation of SPL Approaches for WebGIS Development: SIGTel, a ...

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

Evaluation of SPL Approaches for WebGIS Development: SIGTel, a Case Study Juan Manuel Moreno-Rivera, Elena Navarro University of Castilla-La Mancha {juanmanuel.moreno, Elena.navarro}@uclm.es

Abstract WebGIS development is currently based on the reuse of existing components. There has been an increase in both the number of new components available and the functions demanded by customers. There are also a larger number of firms working on the WebGIS domain so that competition is harder than ever. To deal with this new market situation, SIGTel Geomática has to improve its development process and increase the number and quality of products available in its portfolio. SPL have emerged as a suitable alternative to meet these goals. This paper presents a systematic review (SR) of existing approaches in the SPL domain based on the requirements of SIGTel in particular and the WebGIS domain in general. We evaluate the existing SIGTel process and establish the critical concerns for applying an SPL approach in a small company and describe the lessons learned from our own experience, so that those in a similar situation can benefit from our work. In addition, as SPL approaches and tools are evaluated and the SR method is used to collect documentation, other researchers may also find the results useful.

1. Introduction A Geographical Information System (GIS) is any system that captures, stores, analyzes, manages, and presents data that are linked to a location. The web versions of these systems, Web-based GIS (WebGIS), are becoming more and more complex, the demand for new functionalities is growing so fast and the market is so competitive that WebGIS development and component reuse is now a difficult task. Competition is more intense than ever and the time to market for projects is being reduced in order to be more competitive. Most of the firms that develop WebGIS solutions are small to medium enterprises (SME) that deploy software-intensive production of WebGIS applications to survive in such difficult market conditions. WebGIS development is based on the synthesis of existing components to produce bigger and more complex systems and the reuse of

one’s own and third party components to build the final systems that frequently share a high percentage of commonalities. In this context of intensive software development, Software Product Lines (SPL) [10] emerge as an alternative to establishing a systematic production process for reusing existing software components and other assets like documentation and test benchmarks. In order to be able to evaluate and adopt an SPL approach, it is necessary to understand the main concerns related to it, as well as to be familiar with the existing methodologies and tools. From the beginning, our objective was to establish the needs of SIGTel and define the process and organizational changes necessary to adopt this approach. Different development methodologies were analyzed, as well as the tools available for their support, in order to determine their pros and cons. This work presents the results of the Systematic Review (SR) [28] carried out on SPL and the concerns they cover. We also collect information about the most significant SPL knowledge and dissemination sources, from which we obtained the most important methodologies and tools to support SPL approaches. The results of the evaluation of the existing methodologies and tools are presented, indicating the extent to which they cover the whole SPL life cycle and those most suitable for incorporation into SIGTel. The answers to these questions may be useful to new researchers in SPL, as well as to the more experienced who may be interested in this new domain, in which research on reuse approaches and formal methods can provide solutions to current problems. An evaluation of the state of the SIGTel reuse process is presented as an example of an SME in the WebGIS domain. Finally, the conclusions and lessons learned are presented and the issues that need to be settled when a small company adopts an SPL approach are defined, so that WebGIS developers in similar contexts can benefit from the lessons learned in this case study.

1530-1605/11 $26.00 © 2011 IEEE

1

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

2. The WebGIS domain WebGIS is simply a web-based GIS and is becoming an increasingly popular application. Just about everybody uses WebGIS nowadays, even though he/she does not know it, the most popular example being Google Maps© [18]. WebGIS’s central feature is a map along with a system to analyze, edit and produce spatial information. In the last decade, GIS has jumped from the desktop to the web, evolving from complicated applications for expert users to applications with easy-to-use interfaces and simple processes for all types of internet users. This situation has produced a change in the market and demand has exploded with a lot of large and small firms fighting for the new business. New users are becoming more familiar with WebGIS and are requesting new features. Complicated desktop processes are being adapted to a web-based system as new technologies become available. Beside the increasing complexity of WebGIS, the Open GIS community is growing and offering more possibilities for incorporating new products. Software development firms are now expected to develop new WebGIS systems in a shorter time with better features and improved quality. This situation makes reuse an ever more difficult task. Each component needs to be adapted and be more flexible to demands for new features. This situation is more critical for small firms, so that SIGTel finds it hard to maintain production levels and keep up to date with new market trends. Big firms have R&D departments but small companies have to use the traditional software development methodologies. The development time of final products is too long and the quality is often not what users expect due to the complications involved in testing WebGIS. In theory, these problems should not happen since new WebGIS developments are usually based on reuse of existing components and on the adaptation of existing systems. There are also widely used communications standards defined by the Open Geospatial Consortium (OGC) [38] that can be used to simplify this aspect of WebGIS development.

2.2. Problems found The situation of software development in the WebGIS domain has caused certain problems that need to be solved. These can be divided into three categories, according to the area concerned:

− Software development: WebGIS development needs to increase reuse and improve the quality of the final products. • Requirements engineering: the WebGIS domain is a new technology, unfamiliar to many users so that it is difficult to define requirements. This situation requires a fast prototyping process that can be supported by an SPL approach. • Reference architecture: this concept is common to WebGIS and the SPL approach, which offers a simple and robust framework for this reference architecture. • Cloning: due to the intensive nature of software development, this practice is frequently used [12], thus increasing costs. This problem is particularly significant in WebGIS, where most clients demand a customized software solution combined with maintenance and updating service. SPL applications can maintain the reference architecture and avoid the overuse of cloning. • Testing: in WebGIS there are test benchmarks for isolated components, but it is hard to define a test process for the whole system. Obviously, the automatic generation of test assets would help, although there are still no clear guidelines to define test benchmarks for complex WebGIS systems. • Development documentation: the problems of small firms when deploying traditional software methodologies, usually involving documentation problems, are well known. This has encouraged the development of new approaches [32]. The SPL approach includes documentation as part of the reuse assets, so that every new system is deployed with basic and consistent development documentation. • Quality: as a consequence of the previous issues mentioned, the quality of the final products and related services is not as good as it should be. Improving enterprise competitiveness implies improving final products quality. SPL approaches generally do not consider quality as the main issue, but their processes and tools do make it possible to improve this aspect. − Organization: teams, roles and processes necessary to achieve successful projects have not been sufficiently defined. • Confusing roles: the existing mixture of developers and researchers in the WebGIS domain makes it difficult to distinguish between people responsible for innovating and developing new features and those in charge of

2

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

producing new products. SPL provide mechanisms to support the definition and collaboration of these roles. • Training of new developers: whenever new developers are hired, they need a lengthy training period to get used to the existing components. This problem is more pronounced in the WebGIS domain, where basic GIS concepts are not often present in developer profiles. Automatic generation of documentation and tests would help in simplifying the information necessary to develop new WebGIS software. − Market conditions: some limitations have been found in the business model defined by SIGTel and it seems to be a common fault in other WebGIS producers. • Focus on public administrations: Most clients are public organizations because e-government is being increasingly used and the European Union is promoting the use of open source WebGIS by public organizations [17]. However, there are other potential clients that need WebGIS systems as management tools or to add mapping functions to their existing systems. • Local, regional and national markets: although the current business model focuses mainly on local and regional markets, SIGTel has a wider field of action. However, they have not ventured into the international field, even though their products could be of interest in other countries. Greenfield et al. [20] made a survey on the economic impact of these and other problems in software development. For a small producer to survive in this business context, products must include added value based on innovation and quality. SPL approaches could provide SIGTel with a means of improving production methods and at the same time solve the present problems in WebGIS development.

3. Research context: SIGTel SIGTel [42] is a spin-off enterprise that was created by the Earth Observation and GIS group (EOGIS) [46] at the University of Castilla-La Mancha (UCLM) [49]. The synergy between SIGTel and EOGIS created an R&D technological transfer environment between the academic and industrial fields with high potential benefits. EOGIS and SIGTel have also carried out a very important dissemination task of explaining how these

Information Systems (IS) can be used in a real life context and can be combined with Earth Observation technologies for use in different domains such as water resource management, agricultural monitoring, e-government, archeology and many others. The number of WebGIS applications developed by EOGIS has increased enormously in the last five years. The development of this kind of applications was the basis to start up SIGTel Geomática in 2008. The SIGTel’s main objective is to market services and products generated by EOGIS technology. R&D therefore not only defines its activities but also its business model. The synergy between EOGIS and SIGTel is based on the EOGIS roles of conducting R&D, establishing new research lines and adapting existing ones to new market demands. SIGTel is responsible for adding new products and services to its portfolio by considering both existing and new assets from the EOGIS group. SIGTel also carries out market analysis to provide EOGIS with feedback on the state of the market and any new trends. The research group can then update and customize existing assets to meet new demands. This synergy provides research results that can be directly applied to real life solutions and is one of the foundations of SIGTel’s technological portfolio. However, SIGTEL still has not implemented either a well-defined process or a role assignment that would systematically allow it to transfer, reuse and maintain the assets developed by EOGIS. This involves a technology transfer problem, as SIGTel needs long adaptation periods to include these assets in its portfolio and is critical because of the limited human resources available in both groups. EOGIS has 5 developers and SIGTel about 10, so that they need to be efficient to profit from the available technology and resources. To cope with this situation, SIGTel has adopted several lines of action, the first of which is to evaluate possible systematic processes and to determine which of the existing assets should be adapted first, according to market conditions. Another important task is to identify the critical elements in the EOGIS-SIGTel synergy that need to be improved.

4. Evaluation of SIGTel’s reuse practices According to [30], there are four major independent reuse mechanisms: packaged software [41], SPL [10], model-driven platform [29] and the platform for legacy integration [16]. SPL was chosen because WebGIS development is based on the customization of existing systems to user requirements, which fits perfectly with the SPL

3

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

development philosophy. Another reason for choosing this approach is that SPL concepts like reference architecture, domain engineering, application engineering or mass-customization are familiar processes in EOGIS and SIGTel. Some initiatives have already been deployed to develop basic components for reuse. The first attempt was in the definition of our own WebGIS reference architecture, which was used to provide a solution for three different clients. However, the lack of a systematic maintenance process for this reference architecture meant that the cost of upgrading and maintenance was high and led to its withdrawal. The second attempt was to develop a simple and easy-totrack core map viewer that could be used in other similar projects. The core functions of WebGIS applications could thus be totally reused and the necessary maintenance work could be shared between different projects to reduce costs. However, the maintenance and support of these systems is not as simple as it should be, due to their complexity and the lack of a systematic reuse process. Shared maintenance of this core map viewer was finally ruled out and it is now too expensive and time consuming to keep these systems up to date. There is now another work line that exploits the previous attempts while trying to establish a methodology to keep the assets up to date and reusable. These examples show how reuse efforts have been implemented and how a basic SPL concept, the reference architecture, is already present in SIGTel. To conduct this overview of reuse in SIGTel we evaluated the existing family of products according to the Family Evaluation Framework (FEF) [33], considering the four dimensions proposed by the BAPO model: Business, Organization, Architecture and Process. For each of these dimensions, FEF defines five levels with three to four evaluation aspects assigned to each. The Business dimension establishes how the business model supports SPL and how variability is managed. The architecture dimension measures the correctness of the interaction between domain and application engineering, as well as the way variability is incorporated into the SPL. The process dimension is based on the SEI’s Capability Maturity Model Integration (CMMI) [45], which is widely used and familiar to developers. This dimension measures the existing process maturity to maintain and update an SPL. Finally, the organization dimension measures the distribution of roles and resources involved in SPL throughout the organization. The four dimensions are defined in

such a way that they are easy for practitioners to use. The concepts are easy to understand and suitable for the real world environment. We therefore concluded that this evaluation framework was appropriate for our business context. The results of this evaluation are given in detail in Table 1. These results highlight a non-methodological and informal philosophy for developing WebGIS systems and reflect the general situation present in the domain of geospatial developments, as shown by other studies such as [7], where it can be seen how informal code standards and non-methodological approaches to GIS development are common. More details of the evaluation process can be found in Section 5.3.

5. Research method Both practitioners and researchers have been working on SPL for the last 20 years and a great deal of research has been carried out on this area. New companies that look for SPL approaches as a solution to their problems have the difficult task of wading through a huge bibliography. Although there are many alternatives available (each one appropriate for different purposes), not all have complete documentation. We considered the best option for this study was an SR of the literature, which gives an insight into a specific issue from the domain point of view. Our intention was to compile the available SPL methodologies and tools to determine the best options for SIGTel’s day-to-day needs. The process (see Fig. 1) was based on the following research questions (RQ): − RQ1: Are there any SRs on SPL? If so, which concerns do they cover? − RQ2: What are the most important SPL knowledge and dissemination sources? − RQ3: What methodologies and tools are available for supporting SPL approaches? − RQ4: Do they cover the whole SPL life cycle? − RQ5: Which of the existing SPL methodologies and tools is the best for SIGTel? The answers to these questions are given in Section 6. RQ1 is answered in 6.1, RQ2 in 6.2 and the discussion on RQ3, RQ4 and RQ5 is in Section 6.3.

4

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

Table 1. FEF evaluation of SPL situation in EOGIS-SIGTel Dimension Business: Project-based (Level 1) Architecture: Independent Development (Level 1) Process: Initial (Level 1)

Organization: Reuse (Level 2)

Aspect Commercial Financial Vision Strategic Reuse Reference Variability Domain Engineering Application Engineering Collaboration Roles Structure Collaboration

SIGTel Situation Variability and domain engineering is not included in the business model. Individual systems for individual projects There is no budget for SPL The business objectives do not include SPL management and maintenance Everyone knows that there are some existing assets that can be reused in other projects There is no systematic reuse Previous attempts have been made but architecture deterioration finally emerges Variability is not managed but there are clearly identified variation points It is not considered in the process The application engineering process is based on traditional approaches Development based on developer’s talent; there is no defined standard process. Project objectives are accomplished late and frequently exceed the planned budget There is no domain engineering and application engineers are the ones who coordinate different projects Project-based. Some components have already been used in many projects There is collaboration between project managers and developers who work in different projects

5.1. SR of SRs on SPL Following the guidelines for applying this kind of research in software engineering (SE) [28], the first step was a review of the existing SRs on SPL. This review aims to obtain a list of the concerns covered by these SRs, as well as to determine significant sources of documentation for evaluating the adoption of SPL by SIGTel or other companies interested in this approach. The search engines used were Google Scholar [19] and The ACM Portal [47] and the text string pattern was: ("software product line" OR "software product lines" OR "software product family" OR "software product families") AND ("systematic review" OR "systematic literature review"). Alternative spelling and synonyms were incorporated to this string pattern using the Boolean operator “or” and the main terms were linked using the Boolean operator “and” The outputs of this process are: a) a list of concerns related to SPL approaches (see Section 6.1); and, b) a list of sources for SPL methodologies and for dissemination of research results obtained during this research work (see Section 6.2). The filters defined to consider articles in this SR were not necessarily very strict due to the reduced number of SRs in the SPL domain. Subsequently, the following restrictions were defined: − R1: articles written in English;

− R2: the whole article available in electronic form; − R3: articles published in international conferences or journals.

5.2. SR on SPL methodologies and tools The SR carried out on methodologies and tools focused on the search for SPL proposals and their supporting tools. The SR was based on the lists of references and sources obtained during the previous step and exploited SIGTel developers’ experience of developing WebGIS. The search engines used were the same as in the previous process, but this time they looked for methodologies and tools to support SPL approaches in general. The terms in the previous step, mainly the list of concerns given in Table 2, were also used to improve the queries whenever necessary. Finally, the basic Google® search engine was also used to cover the large number of unpublished documents on SPL tools and technical reports. A preliminary list of methodologies was extracted from the articles included in the previous SR. The restrictions of the previous searches were maintained along with those introduced for this step: − R4: containing SPL/SPLE references; − R5: describing significant SPL methodologies; − R6: introducing tools/methodologies for SPL support; In addition, the following quality criteria were also included to exclude certain articles: − Q1: self-referenced articles;

5

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

− Q2: non relevant modifications or adaptations of previous methodologies. We thus obtained a list of methodologies and tools, shown in Table 4, that support the SPL approach along with the bibliography necessary for their evaluation. An implicit result of this research was an understanding of these methodologies, so that those responsible for evaluating the adoption of this approach were able to consider all the consequences of deploying the selected approach.

separately to compare the different points of view of the technical and business areas. Finally, a meeting with all the experts of both environments was held to present the conclusions of the previous interviews, so that each development unit was able to explain its points of view to the whole group. The output of these meetings composes the list of problems found in WebGIS development as described in Section 2, the FEF evaluation given in Table 1 and some of the conclusions presented in Section 6.

6. Evaluation of SPL approaches for WebGIS developments

5.3. Evaluation of SIGTel The evaluation of results was mainly based on a series of technical meetings with EOGIS and SIGTel experts, a process that lasted for six months. These experts had at least three years of experience in WebGIS and GIS development, or had worked as project managers for more than five years in GISrelated projects. Nine were developers familiar with WebGIS, another 3 were familiar with desktop GIS development, 5 were project managers and 2 business development managers. All had collaborated with other enterprises and groups so that the interviews reflect a more general situation, not only that related to SIGTel. During the initial meetings, the basic concepts of SPL approaches were introduced and were used as a guide to analyze both the potential impact of an SPL approach and the issues the developers needed to clarify. Information on the different approaches was then presented, concerning organizational issues and the experts’ expectations. Finally, an evaluation of the current situation on component reuse and product families in the EOGIS and SIGTel context was presented to the people involved in WebGIS development. Several personal interviews were also conducted to identify personal points of view on SIGTel software development. Meetings with the EOGIS and SIGTel development departments were conducted

The results of the previous steps are introduced in the following sections. First, the concerns list is introduced in Section 6.1, the list of significant sources in 6.2, with statistics from the papers retrieved from each source. The evaluation of methodologies for SIGTel requirements in the WebGIS domain is described in Section 6.3.

6.1. SPL concerns list Table 2 shows the concerns covered by the SR and the timeframes covered by each systematic review. 16 SR were found and, after applying the filters defined in 5.1, eight remained. The first conclusion is that almost all of the SRs were compiled during the last two years, which shows that this is a recent technique in the SPL domain. This collection of SRs and their references cover publications and methodologies from the last 20 years and include almost all SPL aspects. However, we did not find an SR on SOA and SPL for web applications. Other important concerns that should be covered by SRs are the SPL organizational [5] and adoption aspects ([6]) and [39]), despite finding papers that highlight their importance. These concerns are especially important to SIGTel, whose

Fig. 1 SR Process and Research Questions

6

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

organizational constraints imposed by its SMEcharacteristics [32] could affect the successful deployment of an SPL approach. The missing concerns have also been included in Table 2 (in italics) along with some basic references found during this study, in order to offer readers a starting point for every single concern. Table 2. List of concerns related to SPL Author Khurum Khurum Morais Lamancha Chen Rabiser Chen Lisboa Bosch Bosch/Pohl

Time frame 20002007 19962007 20022008 20002008 19902008 19902009 19982007 19902009 -

Year

Paper

Covered Concern

2008

[26]

Economics

2009

[27]

2009

[37]

2009

[31]

Domain analysis: case studies Domain Example: Mobile Middleware Testing

2009

[9]

2009 2009 2010 2001 2005

Variability Management Product [40] Derivation [8] Variability Modeling [34] Domain analysis: Tools SOA Web development [5] Organization [6]/[39] Adoption

6.2. Significant sources of SPL knowledge and dissemination The list of the most significant sources is shown in Table 3 describing the papers retrieved from each source and the ones finally selected. Some papers were excluded due to the restrictions defined in 5.1 and 5.2. Most of the sources found were included in previous SRs. The main group refers to conferences (C) and journals (J). SEI [45] technical reports (R) were included due to their pragmatic relevance. SPLC and ICSE conferences that cover the SPL domain and IEEE and IST are the most important journals. Books by Clements et al. [10], Linden [33] and Atkinson [2] (B) were also included. Clements’ book is a very interesting introduction to SPL. Linden’s is useful as a guide to FEF and as a reference book. Atkinson’s [2] is a reference book for component-based SPL. Table 3. List of significant sources found with statistics. Source Name SPLC ICSE

Type C C

Retrieved 10 6

Selected 8 6

IEEE ICSR IST Books SEI Reports Others Total

J C J B R -

4 2 2 7 3 35 69

3 2 2 3 3 15 41

6.3. Evaluation of methodologies and tools The approaches were chosen for evaluation from the documentation already gathered in the previous step after filtering with the quality criteria in 5.2. The first conclusion we drew is that there are two clearly different approaches: features-based and componentbased. The problem is that few of the existing tools cover all the phases of the SPL life cycle and others were developed in an industrial context and are not available for general purposes. Another conclusion was that although both approaches are attractive for the WebGIS domain, those based on components are more appropriate since most of the WebGIS development applications are based on component reuse. Regarding the SPL life-cycle, we identified Requirements, Design and Realization Phases for both Domain Engineering and Application Engineering as the basic ones to identify minimum coverage of the different approaches to be considered. Only the testing phase could be optional, due to the reduced number of proposals that offer support for this phase. Feature-based proposals are more sophisticated, as they came out in the 90s and there are a lot of tools available for them. FORM is especially important and its tool ASADAL [25], which provides support to all of its phases. However, ASADAL is strongly linked to its original domain, embedded software systems. The QADA approach [35] is perhaps the one with the most complete set of supporting tools for the whole SPL life cycle. QADA focuses on the quality aspects of an SPL and the tools supporting this methodology are based on Eclipse Framework. However, it is based on features and would be difficult to adapt its whole life cycle to WebGIS domain that is more similar to a component-based approach. Among the existing component-based proposals, we consider that KobrA [2] is the most appropriate for the WebGIS domain. It uses components as the basic unit for development, reflects exactly how WebGIS are conceived, and covers almost all the phases of an SPL life cycle. The concept of component trees, the models defined for each component, the option available to configure them according to specific user requirements, as well as

7

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

interfaces with other components and external elements of the system fit perfectly with the daily routine of WebGIS development. For example, a map viewer component can be configured with edition support, with only basic mapping tools or with advanced tools depending on user needs. In addition, a map viewer can also offer an API and OGC standard support to provide other components and external elements with access to its functionality. This is typical of the general behavior of WebGIS components and is similar to the KobrA approach concepts. However, this proposal is not as established as feature-based ones and its supporting tool is not available outside the company where it was defined. This methodology also covers more SPL life cycle phases. The only component-based approach covering the same lifecycle phases is CoPaM, developed by Philips. However, it focuses on embedded systems and is not available for external use. Table 4. SPL life cycle phases covered by existing methodologies and type of SPL

FODA ODM RSBE FAST FORM PuLSE KobrA QADA CoPaM SPLIT COVAMOF PLUSS

Feat. Gen. Feat. Gen. Feat. Gen. Comp. Feat. Comp. Comp. Feat. Feat.

[23] [43] [21] [22] [24] [3] [2] [35] [1] [11] [44] [15]

9 9 9 9 9 9 9 9 9 9 9 9

Application Eng.

9 9 9 9 9 9 9 9 9 9 9 9

8 8 9 9 9 9 9 9 9 9 9 8

8 8 8 8 8 8 8 8 8 8 8 8

9 8 9 9 9 9 9 9 9 8 9 9

8 8 91 91 9 9 9 9 9 8 9 9

Realization

Domain Eng.

8 8 8 91 9 9 9 9 9 8 9 8

Tests

Ref.

Design

Type

Requirements Design Realization Tests Requirements

Method.

8 8 8 91 8 8 8 8 8 8 91 8

Commercial tools that can be used to support SPL, such as Gears [4] or MetaEdit+ [36] are also available, although somewhat complex for application in an SME context, not so used to work with metamodels. One of the constraints imposed by SIGTel on the SPL approach is that it should both allow developers to adapt the existing assets and be easy to introduce in the company. Current developments in SIGTel are based on the Eclipse Framework [13], so that adding functionality to 1

Available documentation mentions this activity but does not provide details

support SPL in this framework will facilitate the introduction of the SPL approach. The Eclipse Modeling Framework (EMF) [14] is the core framework to be used. Topcased [48], a model-driven environment, primarily dedicated to the development of critical embedded systems based on EMF, offers also many suitable tools for the implementation of SPL. In addition to these frameworks, some of the tools supporting the QADA approach can be reused as well to cover part of a SPL approach as they are based on EMF and Topcased. The integration of these tools and QADA would be very interesting because support for quality management could be introduced in our SPL. In a small company, the developers’ firm belief in the benefits of this approach is critical for its application. Drastically changing the tools used for development would seriously reduce support for the current technological portfolio and would probably ensure failure of the SPL approach.

7. Conclusions and future work The main contribution of this paper is to summarize existing approaches and concerns related to SPL, so that other practitioners interested on SPL deployment can benefit from the work done. This paper also established the problems and challenges in WebGIS development and offers a good starting point for researchers to meet this new and emerging domain. We concluded that SRs are a useful way of accessing research issues like SPL. However, it is a new concept coined only a few years ago. Thus, there could be previous reviews not considered when collecting existing SR because they did not use this term to describe their contribution. The first step carried out to recover previous SRs on SPL helped this study to save time on gathering all the information necessary to evaluate the available options and provided us with bibliographic resources and a compilation of the main SPL-related concerns. Several proposals have been presented to date to guide SPL development and exploitation, although they do not cover the whole SPL life cycle. Other approaches are strongly linked to the domains where they were defined or there is no detailed documentation available. The evaluation of the current situation in the EOGIS and SIGTel context helped us to settle the critical issues for the successful application of SPL in this context. However, the deployment is still in the early stages, so that other problems cannot be ruled out in the following steps. A well-defined and versatile product line could drastically improve SIGTel’s product and service quality, as this would make it possible to customize

8

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

products to individual requirements and would also assist in establishing a systematic software development process. Another important benefit of this approach is the improvement of traceability, maintenance and system testing, all tasks with high costs that need to be reduced to increase company profits. The development and maintenance support framework can also be used as an efficient technology transfer support platform between EOGIS and SIGTel. Being a small company, establishing a new development framework is easier, due to the low number of people involved. On the other hand, the project-based philosophy used for many years does not offer too many expectations on a budget designed for SPL maintenance and updating. Developers therefore need to believe in the benefits of the approach to be able to define a process that could become gradually more sustainable through systematic reuse of the existing assets. During the survey, the experts expressed their doubts about the suitability of drastically changing SIGTel’s development philosophy. All of them pointed out that the benefits of an SPL approach would help to increase competitiveness, but they also emphasized the importance of the work already done. It is therefore essential to find a solution that adds value to the existing Eclipse-based development process. They also recognized the problems involved in funding SPL and that it would be necessary to define an adaptive process that can be sustained by the current project-based SIGTel model. However, we think that the lessons learned from other successful stories about SPL adoption in SME, like Market Maker [33], can help us to deploy SPL in SIGTel. The next steps are: finishing the experimental phase, testing the KobrA proposal and planning the implementation of the SIGTel SPL. The KobrA models fits perfectly into the WebGIS development philosophy, but the progress from these models towards the final products will need a lot of improvement due to the strong focus on design for reuse and the lack of model transformation facilities. We are also examining the incorporation of an application modeling tool into the EOGIS and SIGTel daily routine that can be integrated into the Eclipse Framework by reusing existing tools. The idea is to adapt the KobrA domain engineering phase to the WebGIS domain and then to offer support with this tool to the application engineering phase of the SPL life cycle.

Spanish Ministry of Science and Innovation through the Torres Quevedo Program and CAPCOL Project TIN2008-06596-C02-01. We also want to thank the reviewers for their great inputs that have helped us to improve the presented work.

Acknowledgements

[15] Eriksson, M., Börstler, J., Borg, K., “The PLUSS Approach - Domain Modeling with Features, Use Cases and Use Case Realizations,” SW Product Lines, Springer, 2005, pp. 33-44.

This work has been partially sponsored by SIGTel Geomática, the EOGIS group (UCLM) and the

References [1] America, P., Obbink, H., Ommering, R., Linden, F., “CoPaM: A Component-Oriented Platform Architecting Method Family for Product Family Engineering,” SPLC, 2000. [2] Atkinson, C., Bayer, J., Muthig, D., “Component-based product line engineering with UML,” Pearson Education, 2002. [3] Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen, T., DeBaud, J., “PuLSE: a methodology to develop software product lines,” Symposium on SW Reusability, 1999, pp. 122-131. [4] BigLever Software Gears, Available at http://www.biglever.com/solution/product.html and accessed August 31, 2010. [5] Bosch, J., “Software product lines: organizational alternatives,” Int. Conf. on SW Engineering (ICSE), 2001, pp. 91-100. [6] Bosch, J., “Staged adoption of software product families,” Software Process: Improvement and Practice 10, 2005, pp. 125-142. [7] Bowman, D., “Geospatial Developer Survey Results,” Available at http://blog.davebouwman.com and accessed August 23, 2010. [8] Chen, L., Ali Babar, M., “A Survey of Scalability Aspects of Variability Modeling Approaches,” SPLC, 2009. [9] Chen, L., Ali Babar, M., Ali, N., “Variability Management in Software Product Lines: A Systematic Review,” SPLC, 2009. [10] Clements, P., Northrop, L., “Software Product Lines: Practices and Patterns,” Addison-Wesley, 2002. [11] Coriat, M., Jourdan, J., Boisbourdin, F., “The SPLIT Method,” SPLC, 2000. [12] Dikel, D., Kane, D., Ornburn, S., Loftus, W., Wilson, J., “Applying software product-line architecture,” Computer, 30, 1997, pp. 49-55. [13] Eclipse Framework, Available http://www.eclipse.org/ and accessed March 09, 2010.

at

[14] EMF “Eclipse Modeling Framework project” Available at http://www.eclipse.org/modeling/emf/ and accessed August 31, 2010.

9

Proceedings of the 44th Hawaii International Conference on System Sciences - 2011

[16] Erl, T., “Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services,” Prentice Hall, 2004.

[33] Linden, F.J.V.D., Schmid, K., Rommes, E., “Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering,” Springer, 2007.

[17] European Commission, INSPIRE: Infrastructure for Spatial Information in Europe, Available at http://inspire.jrc.ec.europa.eu/ and accessed May 25, 2010.

[34] Lisboa, L.B., Garcia, V.C., Lucrédio, D., Almeida, E.S.D., Meira, S.R.D.L., Fortes, R.P.D.M., “A systematic review of domain analysis tools,” IST, 52, 2010, pp. 1-13.

[18] Google Maps, Available at http://maps.google.com/ and accessed August 31, 2010.

[35] Matinlassi, M., Niemelä, E., Dobrica, L., "Qualitydriven architecture design and quality analysis method, A revolutionary initiation approach to a product line architecture,” VTT Technical Research Centre of Finland, Espoo, 2002.

[19] Google Scholar, Available http://scholar.google.com/ accessed August 31, 2010.

at

[20] Greenfield, J., Short, K., Cook, S., Kent, S., “Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools,” Wiley, 2003. [21] Griss, M.L., Favaro, J., Alessandro, M.D., “Integrating th Feature Modeling with the RSEB,” 5 Int. Conf. on SW Reuse, 1998, pp. 76. [22] Harsu, M., “FAST product-line architecture process,” Tampere University of Technology, Technical Report. [23] Kang, K., Cohen, S., Hess, J., Nowak, W., Peterson, S., “Feature-Oriented Domain Analysis (FODA) Feasibility Study,” SW Eng. Institute, 1990. [24] Kang, K., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M., “FORM: A feature-oriented reuse method with domainspecific reference architectures,” Annals of SW Eng, 5, 1998, pp. 143-168. [25] Kim, K., Kim, H., Ahn, M., Seo, M., Chang, Y., Kang, K.C., “ASADAL: a tool system for co-development of software and test environment based on product line th engineering,” 28 Int. Conf. on SW Eng., 2006, pp. 783786. [26] Khurum, M., Gorschek, T., Pettersson, K., “Systematic Review of Solutions Proposed for Product Line Economics,” 12th SPLC, 2008.

[36] MetaCase - Domain-Specific Modeling with MetaEdit+, Available at http://www.metacase.com/ and accessed March 9, 2010. [37] Morais B., Y., Pereira, T.A.B., Silveira, G.E.D., “A Systematic Review of Software Product Lines Applied to Mobile Middleware,” 6th Int. Conf. on Information Technology, 2009, pp. 1024-1029. [38] OpenGIS Consortium “Standards and Specifications,” Available at http://www.opengeospatial.org/ and accessed August 31, 2010. [39] Pohl, K., Böckle, G., Linden, F.J.V.D., “Software Product Line Engineering: Foundations, Principles and Techniques,” Springer, 2005. [40] Rabiser, R., Grünbacher, P., Dhungana, D., “Requirements for product derivation support: Results from a systematic literature review and an expert survey,” IST, 2009. [41] Sawyer, S., “Packaged software: implications of the differences from custom approaches to software development,” Eur. J. Inf. Syst. 9, 2000, pp. 47-58. [42] SIGTel Geomática, Available at http://www.sigtel.es and accessed August 31, 2010.

[27] Khurum, M., Gorschek, T., “A systematic review of domain analysis solutions for product lines,” JSS, 82, 2009, pp. 1982-2003.

[43] Simos, M.A., “Organization domain modeling (ODM): formalizing the core domain modeling life cycle,” SIGSOFT SW. Eng. Notes, 20, 1995, pp. 196-205.

[28] Kitchenham, B., Charters, S., “Guidelines for performing Systematic Literature Reviews in Software Engineering,” Keele University and Durham University Joint Report (2007).

[44] Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J.: “COVAMOF: A Framework for Modeling Variability in Software Product Families,” SW Product Lines, 2004, pp. 25-27.

[29] Kleppe, A., Warmer, J., Bast, W., “MDA Explained: The Model Driven Architecture: Practice and Promise,” Addison-Wesley Professional, 2003. [30] Kruithof, G.H., Meijler, T.D., “Strategic Dimensions of Software Development in a Supply Chain,” Information Systems Development, 2009, pp. 1-9. [31] Lamancha, B.P., Usaola, M.P., Velthius, M.P., “Software Product Line Testing - A Systematic Review,” ICSOFT, 2009, pp. 23-30. [32] Laporte, C.Y., Alexandre, S., O’Connor, R.V., “A Software Engineering Lifecycle Standard for Very Small Enterprises,” Software Process Improvement, 2008, pp. 129-141.

[45] Software Engineering Institute, Available at http://www.sei.cmu.edu/ and accessed August 30, 2010. [46] Teledetección y SIG, Available at http://www.teledeteccionysig.com/ and accessed August 30, 2010. [47] The ACM Portal, Available at http://portal.acm.org and accessed August 31, 2010. [48] Topcased, Available at http://www.topcased.org/ and accessed August 31, 2010. [49] Universidad de Castilla-La Mancha, Available at http://www.uclm.es/ and accessed August 31, 2010.

10