Agile Construction and Evolution of Product-Line Architectures

Software Product Line Engineering (SPLE) has proved to have significant advantages in family-based software development, but also implies the up¬front design of a product-line architecture (PLA) from which individual product applications can be engineered. The big upfront design associated with PLAs is in conflict with the current need of "being open to change". However, the turbulence of the current business climate makes change inevitable in order to stay competitive, and requires PLAs to be open to change even late in the development. The trend of "being open to change" is manifested in the Agile Software Development (ASD) paradigm, but it is spreading to the domain of SPLE. To reduce the big upfront design of PLAs as currently practiced in SPLE, new paradigms are being created, one being Agile Product Line Engineering (APLE). APLE aims to make the development of product-lines more flexible and adaptable to changes as promoted in ASD. To put APLE into practice it is necessary to make mechanisms available to assist and guide the agile construction and evolution of PLAs while complying with the "be open to change" agile principle. This thesis defines a process for "the agile construction and evolution of product-line architectures", which we refer to as Agile Product-Line Archi-tecting (APLA). The APLA process provides agile architects with a set of models for describing, documenting and tracing PLAs, as well as an algorithm to analyze change impact. Both the models and the change impact analysis offer the following capabilities: Flexibility & adaptability at the time of defining software architectures, enabling change during the incremental and iterative design of PLAs (anticipated or planned changes) and their evolution (unanticipated or unforeseen changes). Assistance in checking architectural integrity through change impact analysis in terms of architectural concerns, such as dependencies on earlier design decisions, rationale, constraints, and risks, etc.Guidance in the change decision-making process through change im¬pact analysis in terms of architectural components and connections. Therefore, APLA provides the mechanisms required to construct and evolve PLAs that can easily be refined iteration after iteration during the APLE development process. These mechanisms are provided in a modeling frame¬work called FPLA. The contributions of this thesis have been validated through the conduction of a project regarding a metering management system in electrical power networks. This case study took place in an i-smart software factory and was in collaboration with the Technical University of Madrid and Indra Software Labs. La Ingeniería de Líneas de Producto Software (Software Product Line Engi¬neering, SPLE) ha demostrado tener ventajas significativas en el desarrollo de software basado en familias de productos. SPLE es un paradigma que se basa en la reutilización sistemática de un conjunto de características comunes que comparten los productos de un mismo dominio o familia, y la personalización masiva a través de una variabilidad bien definida que diferencia unos productos de otros. Este tipo de desarrollo requiere el diseño inicial de una arquitectura de línea de productos (Product-Line Architecture, PLA) a partir de la cual los productos individuales de la familia son diseñados e implementados. La inversión inicial que hay que realizar en el diseño de PLAs entra en conflicto con la necesidad actual de estar continuamente "abierto al cam¬bio", siendo este cambio cada vez más frecuente y radical en la industria software. Para ser competitivos es inevitable adaptarse al cambio, incluso en las últimas etapas del desarrollo de productos software. Esta tendencia se manifiesta de forma especial en el paradigma de Desarrollo Ágil de Software (Agile Software Development, ASD) y se está extendiendo también al ámbito de SPLE. Con el objetivo de reducir la inversión inicial en el diseño de PLAs en la manera en que se plantea en SPLE, en los último años han surgido nuevos enfoques como la Ingeniera de Líneas de Producto Software Ágiles (Agile Product Line Engineering, APLE). APLE propone el desarrollo de líneas de producto de forma más flexible y adaptable a los cambios, iterativa e incremental. Para ello, es necesario disponer de mecanismos que ayuden y guíen a los arquitectos de líneas de producto en el diseño y evolución ágil de PLAs, mientras se cumple con el principio ágil de estar abierto al cambio. Esta tesis define un proceso para la "construcción y evolución ágil de las arquitecturas de lineas de producto software". A este proceso se le ha denominado Agile Product-Line Architecting (APLA). El proceso APLA proporciona a los arquitectos software un conjunto de modelos para de¬scribir, documentar y trazar PLAs, así como un algoritmo para analizar vel impacto del cambio. Los modelos y el análisis del impacto del cambio ofrecen: Flexibilidad y adaptabilidad a la hora de definir las arquitecturas software, facilitando el cambio durante el diseño incremental e iterativo de PLAs (cambios esperados o previstos) y su evolución (cambios no previstos). Asistencia en la verificación de la integridad arquitectónica mediante el análisis de impacto de los cambios en términos de dependencias entre decisiones de diseño, justificación de las decisiones de diseño, limitaciones, riesgos, etc. Orientación en la toma de decisiones derivadas del cambio mediante el análisis de impacto de los cambios en términos de componentes y conexiones. De esta manera, APLA se presenta como una solución para la construcción y evolución de PLAs de forma que puedan ser fácilmente refinadas iteración tras iteración de un ciclo de vida de líneas de producto ágiles. Dicha solución se ha implementado en una herramienta llamada FPLA (Flexible Product-Line Architecture) y ha sido validada mediante su aplicación en un proyecto de desarrollo de un sistema de gestión de medición en redes de energía eléctrica. Dicho proyecto ha sido desarrollado en una fábrica de software global en colaboración con la Universidad Politécnica de Madrid e Indra Software Labs

A Systematic Process for Implementing Gateways for Test Tools

Test automation is facing a new challenge because tools, as well as having to provide conventional test functionalities, must be capable to interact with ever more heterogeneous complex systems under test (SUT). The number of existing software interfaces to access these systems is also a growing number. The problem cannot be analyzed only from a technical or engineering perspective; the economic perspective is as important. This paper presents a process to systematically implement gateways which support the communication between test tools and SUTs with a reduced cost. The proposed solution does not preclude any interface protocol at the SUT side. This process is supported using a generic architecture of a gateway defined on top of OSGi. Any test tool can communicate with the gateway through a unique defined interface. To communicate the gateway and the SUT, basically, the driver corresponding to the SUT software interface has to be loaded

A model for tracing variability from features to product-line architectures: a case study in smart grids

In current software systems with highly volatile requirements, traceability plays a key role to maintain the consistency between requirements and code. Traceability between artifacts involved in the development of Software Product Lines (SPL) is still more critical because it is necessary to guarantee that the selection of variants that realize the different SPL products meet the requirements. Current SPL traceability mechanisms trace from variability in features to variations in the configuration of product-line architecture (PLA) in terms of adding and removing components. However, it is not always possible to materialize the variable features of a SPL through adding or removing components, since sometimes they are materialized inside components, i.e. in part of their functionality: a class, a service and/or an interface. Additionally, variations that happen inside components may crosscut several components of architecture. These kinds of variations are still challenging and their traceability is not currently well-supported. Therefore, it is not possible to guarantee that those SPL products with these kinds of variations meet the requirements. This paper presents a solution for tracing variability from features to PLA by taking these kinds of variations into account. This solution is based on models and traceability between models in order to automate SPL configuration by selecting the variants and realizing the product application. The FPLA modeling framework supports this solution which has been deployed in a software factory. Validation has consisted in putting the solution into practice to develop a product line of power metering management applications for Smart Grids

A model-driven engineering process for autonomic sensor-actuator networks

Cyber-Physical Systems (CPS) are the next generation of embedded ICT systems designed to be aware of the physical environment by using sensor-actuator networks to provide users with a wide range of smart applications and services. Many of these smart applications are possible due to the incorporation of autonomic control loops that implement advanced processing and analysis of historical and real-time data measured by sensors; plan actions according to a set of goals or policies; and execute plans through actuators. The complexity of this kind of systems requires mechanisms that can assist the system?s design and development. This paper presents a solution for assisting the design and development of CPS based on Model-Driven Development: MindCPS (doMaIN moDel for CPS) solution. MindCPS solution is based on a model that provides modelling primitives for explicitly specifying the autonomic behaviour of CPS and model transformations for automatically generating part of the CPS code. In addition to the automatic code generation, the MindCPS solution offers the possibility of rapidly configuring and developing the core behaviour of a CPS, even for nonsoftware engineers. The MindCPS solution has been put into practice to deploy a smart metering system in a demonstrator located at the Technical University of Madrid

Designing and simulating smart grids

Growing energy demands and the increased use of renewal energies have changed the landscape of power networks leading to new challenges. Smart Grids have emerged to cope with these challenges by facilitating the integration of traditional and renewable energy resources in distributed, open, and self-managed ways. Innovative models are needed to design energy infrastructures that can enable self-management of the power grid. Software architectures smoothly integrate the software that provides self-management to Smart Grids and their hardware infrastructures. We present a framework to design the software architectures of autonomous Smart Grids in an intuitive domain-oriented way and to simulate their execution by automatically generating the code from the designed autonomous smart grid architectures

Model-to-Code transformation from product-line architecture models to aspectJ

Software Product Line Engineering has significant advantages in family-based software development. The common and variable structure for all products of a family is defined through a Product-Line Architecture (PLA) that consists of a common set of reusable components and connectors which can be configured to build the different products. The design of PLA requires solutions for capturing such configuration (variability). The Flexible-PLA Model is a solution that supports the specification of external variability of the PLA configuration, as well as internal variability of components. However, a complete support for product-line development requires translating architecture specifications into code. This complex task needs automation to avoid human error. Since Model-Driven Development allows automatic code generation from models, this paper presents a solution to automatically generate AspectJ code from Flexible-PLA models previously configured to derive specific products. This solution is supported by a modeling framework and validated in a software factory

A Cost-Benefit analysis model for technical debt management considering uncertainty and time

In the last few years, technical debt has been used as a useful means for making the intrinsic cost of the internal software quality weaknesses visible. This visibility is made possible by quantifying this cost. Specifically, technical debt is expressed in terms of two main concepts: principal and interest. The principal is the cost of eliminating or reducing the impact of a, so called, technical debt item in a software system; whereas the interest is the recurring cost, over a time period, of not eliminating a technical debt item. Previous works about technical debt are mainly focused on estimating principal and interest, and on performing a cost-benefit analysis. This cost-benefit analysis allows one to determine if to remove technical debt is profitable and to prioritize which items incurring in technical debt should be fixed first. Nevertheless, for these previous works technical debt is flat along the time. However the introduction of new factors to estimate technical debt may produce non flat models that allow us to produce more accurate predictions. These factors should be used to estimate principal and interest, and to perform cost-benefit analysis related to technical debt. In this paper, we take a step forward introducing the uncertainty about the interest, and the time frame factors so that it becomes possible to depict a number of possible future scenarios. Estimations obtained without considering the possible evolution of the interest over time may be less accurate as they consider simplistic scenarios without changes

An exploratory study in communication in Agile Global Software Development

Global software development (GSD) is gaining ever more relevance. Although communication is key in the exchange of information between team members, multi-site software development has introduced additional obstacles (different time-zones and cultures, IT infrastructure, etc.) and delays into the act of communication, which is already problematic. Communication is even more critical in the case of Agile Global Software Development (AGSD) in which communication plays a primary role. This paper reports an exploratory study of the effects of tools supporting communication in AGSD. More precisely, this paper analyses the perception of team members about communication infrastructures in AGSD. The research question to which this study responds concerns how development teams perceive the communication infrastructure while developing products using agile methodologies. Most previous studies have dealt with communication support from a highly technological media tool perspective. In this research work, instead, observations were obtained from three perspectives: communication among team members, communication of the status of the development process, and communication of the status of the progress of the product under development. It has been possible to show that team members perceive advantages to using media tools that make them feel in practice that teams are co-located, such as smartboards supported by efficient video-tools, and combining media tools with centralized repository tools, with information from the process development and product characteristics, that allow distributed teams to effectively share information about the status of the project/process/product during the development process in order to overcome some of the still existing problems in communication in AGSD

Change-impact driven agile architecting

Trabajo Ya Publicado de Congreso CORE

Providing a consensus definition for the term "Smart Product"

The term "Smart Product" has become commonly used in recent years. This is because there has been an increasing interest in these kinds of products as part of the consumer goods industry, impacting everyday life and industry. Nevertheless, the term "Smart Product" is used with different meanings in different contexts and application domains. The use of the term "Smart Product" with different meanings and underlying semantics can create important misunderstandings and dissent. The aim of this paper is to analyze the different definitions of Smart Product available in the literature, and to explore and analyze their commonalities and differences, in order to provide a consensus definition that satisfies, and can therefore be used by, all parties. To embrace the identified definitions, the concept of "Smart Thing" is introduced. The methodology used was a systematic literature review. The definition is expressed as an ontology