Uma abordagem reativa de construção de linhas de produto de software baseada em TDD e refatoração

Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós-Graduação em Ciência da Computação, Florianópolis, 2014Linhas de Produto de Software (LPS) trazem diversos benefícios, como a diminuição do tempo de entrada no mercado, a redução dos custos de desenvolvimento, o aumento da produtividade e a melhora da qualidade do produto final. Uma das práticas que auxilia na garantia de qualidade é a prática de testes. No entanto, ainda existem desafios e lacunas na utilização desta prática no desenvolvimento de LPSs. Nem todas as técnicas de testes utilizadas no desenvolvimento de um produto único podem ser aplicadas em LPSs e, portanto, novas adaptações e propostas são necessárias. Além disso, o desenvolvimento tradicional de LPSs também demanda um alto investimento inicial de longo prazo e oferece riscos para mercados dinâmicos, onde mudanças são difíceis de prever. Entretanto, já existem propostas para levar as vantagens de LPSs para mercados dinâmicos por meio da utilização de práticas de desenvolvimento ágil de software, essa união é denominada Engenharia de Linha de Produto Ágil (ELPA). Esta dissertação visa a elaboração de uma abordagem para a construção de LPSs, utilizando a ELPA. Nesta proposta as práticas ágeis de Desenvolvimento Dirigido por Testes (Test-Driven Development - TDD) e Refatoração conduzem a criação de uma LPS de abordagem reativa sem a tentativa de prever variações futuras. Para dar suporte à prática de testes unitários no desenvolvimento reativo de LPSs, foi desenvolvido um framework de testes com a proposta de adaptar padrões de testes unitários que facilitem a verificação da exatidão das aplicações geradas. Os padrõesde teste Framework de Automação de Testes e Testes Dirigidos por Dados fornecem a reutilização da lógica de testes e a automação dos mecanismos de implementação, reduzindo o esforço necessário para testar as variações de cada aplicação. A proposta foi avaliada através de um exemplo que mostrou a aplicação da abordagem e do framework de testes em uma LPS que foi construída de forma reativa a partir de uma aplicação existente. Como resultado foi visto um alto grau de reuso de testes, com 89% de reuso na segunda aplicação, após a modificação de três features, 97% na terceira aplicação, após a adição de uma feature e modificação de outra, e 100% na quarta aplicação onde nenhuma feature foi adicionada ou modificada, e a aplicação foi construída com variantes existentes.Abstract: Software Product Line (SPL) brings benefits such as lower time-to market, less development costs, increased productivity, and improved quality. The quality assurance can be reached through the testing area, however this area still has challenges and gaps in the SPL development. Since not all testing techniques used in a single product development can be applied to SPL, thus some adaptations and new proposals are required. Traditional SPL also requires a high initial investment and offers long-term risks to dynamic markets where changes are difficult to predict. Currently, proposals bring the advantages of SPL for dynamic markets through the use of agile software development practices, which is called Agile Product Line Engineering (APLE). This work presents the development of the necessary steps for building SPL using the APLE. In this proposal the agile practices Test-Driven Development (TDD) and Refactoring lead a reactive development of SPL without attempting to predict future variations. It is also proposed to adapt unit test patterns in the context of SPL. The test patterns Test Automation Framework and Data-Driven Tests provide the reuse of test logic and automation of the implementation mechanisms, reducing the effort required to test variations of each application. The result of this adaptation is a testing framework to be used during application engineering to configure tests through parameterized tests and verify the correctness of generated applications. Thus, this work shows how the agile practices TDD and Refactoring may cause a SPL to evolve and acquire variation points on demand. The proposal was evaluated through an example of a SPL that was built with a reactive approach from an existing application. As a result, it was obtained a high degree of tests reuse, with 89% of reuse in the second application after modifying three features, 97% in the third application after adding one feature and modifying another one, and 100% of reuse in the fourth application where no feature was added or modified, and the application was built with existing variants

Representing Variability in Software Architecture: A Systematic Literature Review

Variability in software - intensive systems is the ability of a software artefact (e.g., a system, subsystem, or component) to be extended, customised or configured for deployment in a specific context. Software Architecture is a high - level description of a software - intensive system that abstracts the system implementation details allowing the architect to view the system as a whole. Although variability in software architecture is recognised as a challenge in multiple domains, there has been no formal consensus on how variability should be captured or represented. The objective of this research was to provide a snapshot of the state - of - the - art on representing variability in software architecture while assessing the nature of the different approaches. To achieve this objective, a Systematic Literature Review (SLR) was conducted covering literature produced from January 1991 until June 2016. Then, grounded theory was used to conduct the analysis and draw conclusions from data, mini mising threats to validity. In this paper , we report on the findings from the study

Representing Variability in Software Architecture

Software Architecture is a high level description of a software intensive system that enables architects to have a better intellectual control over the complete system. It is also used as a communication vehicle among the various system stakeholders. Variability in software-intensive systems is the ability of a software artefact (e.g., a system, subsystem, or component) to be extended, customised, or configured for deployment in a specific context. Although variability in software architecture is recognised as a challenge in multiple domains, there has been no formal consensus on how variability should be captured or represented. In this research, we addressed the problem of representing variability in software architecture through a three phase approach. First, we examined existing literature using the Systematic Literature Review (SLR) methodology, which helped us identify the gaps and challenges within the current body of knowledge. Equipped with the findings from the SLR, a set of design principles have been formulated that are used to introduce variability management capabilities to an existing Architecture Description Language (ADL). The chosen ADL was developed within our research group (ALI) and to which we have had complete access. Finally, we evaluated the new version of the ADL produced using two distinct case studies: one from the Information Systems domain, an Asset Management System (AMS); and another from the embedded systems domain, a Wheel Brake System (WBS). This thesis presents the main findings from the three phases of the research work, including a comprehensive study of the state-of-the-art; the complete specification of an ADL that is focused on managing variability; and the lessons learnt from the evaluation work of two distinct real-life case studies

Supporting the grow-and-prune model for evolving software product lines

207 p.Software Product Lines (SPLs) aim at supporting the development of a whole family of software products through a systematic reuse of shared assets. To this end, SPL development is separated into two interrelated processes: (1) domain engineering (DE), where the scope and variability of the system is defined and reusable core-assets are developed; and (2) application engineering (AE), where products are derived by selecting core assets and resolving variability. Evolution in SPLs is considered to be more challenging than in traditional systems, as both core-assets and products need to co-evolve. The so-called grow-and-prune model has proven great flexibility to incrementally evolve an SPL by letting the products grow, and later prune the product functionalities deemed useful by refactoring and merging them back to the reusable SPL core-asset base. This Thesis aims at supporting the grow-and-prune model as for initiating and enacting the pruning. Initiating the pruning requires SPL engineers to conduct customization analysis, i.e. analyzing how products have changed the core-assets. Customization analysis aims at identifying interesting product customizations to be ported to the core-asset base. However, existing tools do not fulfill engineers needs to conduct this practice. To address this issue, this Thesis elaborates on the SPL engineers' needs when conducting customization analysis, and proposes a data-warehouse approach to help SPL engineers on the analysis. Once the interesting customizations have been identified, the pruning needs to be enacted. This means that product code needs to be ported to the core-asset realm, while products are upgraded with newer functionalities and bug-fixes available in newer core-asset releases. Herein, synchronizing both parties through sync paths is required. However, the state of-the-art tools are not tailored to SPL sync paths, and this hinders synchronizing core-assets and products. To address this issue, this Thesis proposes to leverage existing Version Control Systems (i.e. git/Github) to provide sync operations as first-class construct

Ambidexterity in large-scale software engineering

Software is pervading our environment with products that become smarter and smarter every day. In order to follow this trend, software companies deliver continuously new features, in order to anticipate their competitors and to gain market share. For this reason, they need to adopt processes and organization solutions that allow them to deliver continuously. A key challenge for software organizations is to balance the resources in order to deliver enough new features in the short-term but also to support the delivery of new features in the long-term. In one word, companies need to be ambidextrous. In this thesis we investigate what ambidexterity is, what are the factors that hinder large software companies to be ambidextrous, and we provide initial solutions for the mitigation of such challenges. The research process consists of an empirical investigation based on the Grounded Theory approach, in which we conducted several case studies based on continuous interaction with 7 large software organizations developing embedded software. The results in this thesis are grounded in a large number of data collected, and corroborated by a combination of exploratory and confirmatory, as well as qualitative and quantitative data collection. The contributions of this thesis include a comprehensive understanding of the factors influencing ambidexterity, the current challenges and a proposed solution, CAFFEA. In particular, we found that three main challenges where hampering the achievement of ambidexterity for large software companies. The first one is the conflict between Agile Software Development and software reuse. The second one is the complexity of balancing short-term and long-term goals among a large number of stakeholders with different views and expertize. The third challenge is the risky tendency, in practice, of developing systems that does not sustain long-term delivery of new features: this is caused by the unbalanced focus on short-term deliveries rather than on the system architecture quality. This phenomenon is referred to as Architectural Technical Debt, which is a financial theoretical framework that relates the implementation of suboptimal architectural solutions to taking a debt. Even though such sub-optimal solutions might bring benefits in the short-term, a debt might have an interest associated with it, which consists of a negative impact on the ability of the software company to deliver new features in the long-term. If the interest becomes too costly, then the software company suffers delays and development crises. It is therefore important to avoid accumulation, in the system, of Architectural Technical Debt with a high interest associated with it. The solution proposed in this thesis is a comprehensive framework, CAFFEA, which includes the management of Architectural Technical Debt as a spanning activity (i.e., a practice shared by stakeholders belonging to different groups inside the organization). We have recognized and evaluated the strategic information required to manage Architectural Technical Debt. Then, we have developed an organizational framework, including roles, teams and practices, which are needed by the involved stakeholders. This solutions have been empirically developed and evaluated, and companies report initial benefits of applying the results in practice