Change-Impact driven Agile Architecting.

Software architecture is a key factor to scale up Agile Software Development ASD in large softwareintensive systems. Currently, software architectures are more often approached through mechanisms that enable to incrementally design and evolve software architectures aka. agile architecting. Agile architecting should be a light-weight decision-making process, which could be achieved by providing knowledge to assist agile architects in reasoning about changes. This paper presents the novel solution of using change-impact knowledge as the main driver for agile architecting. The solution consists of a Change Impact Analysis technique and a set of models to assist agile architects in the change -decision-making- process by retrieving the change-impact architectural knowledge resulting from adding or changing features iteration after iteration. To validate our approach, we have put our solution into practice by running a project of a metering management system in electric power networks in an i-smart software factory

Modellbasiertes Regressionstesten von Varianten und Variantenversionen

The quality assurance of software product lines (SPL) achieved via testing is a crucial and challenging activity of SPL engineering. In general, the application of single-software testing techniques for SPL testing is not practical as it leads to the individual testing of a potentially vast number of variants. Testing each variant in isolation further results in redundant testing processes by means of redundant test-case executions due to the shared commonality. Existing techniques for SPL testing cope with those challenges, e.g., by identifying samples of variants to be tested. However, each variant is still tested separately without taking the explicit knowledge about the shared commonality and variability into account to reduce the overall testing effort. Furthermore, due to the increasing longevity of software systems, their development has to face software evolution. Hence, quality assurance has also to be ensured after SPL evolution by testing respective versions of variants. In this thesis, we tackle the challenges of testing redundancy as well as evolution by proposing a framework for model-based regression testing of evolving SPLs. The framework facilitates efficient incremental testing of variants and versions of variants by exploiting the commonality and reuse potential of test artifacts and test results. Our contribution is divided into three parts. First, we propose a test-modeling formalism capturing the variability and version information of evolving SPLs in an integrated fashion. The formalism builds the basis for automatic derivation of reusable test cases and for the application of change impact analysis to guide retest test selection. Second, we introduce two techniques for incremental change impact analysis to identify (1) changing execution dependencies to be retested between subsequently tested variants and versions of variants, and (2) the impact of an evolution step to the variant set in terms of modified, new and unchanged versions of variants. Third, we define a coverage-driven retest test selection based on a new retest coverage criterion that incorporates the results of the change impact analysis. The retest test selection facilitates the reduction of redundantly executed test cases during incremental testing of variants and versions of variants. The framework is prototypically implemented and evaluated by means of three evolving SPLs showing that it achieves a reduction of the overall effort for testing evolving SPLs.Testen ist ein wichtiger Bestandteil der Entwicklung von Softwareproduktlinien (SPL). Aufgrund der potentiell sehr großen Anzahl an Varianten einer SPL ist deren individueller Test im Allgemeinen nicht praktikabel und resultiert zudem in redundanten Testfallausführungen, die durch die Gemeinsamkeiten zwischen Varianten entstehen. Existierende SPL-Testansätze adressieren diese Herausforderungen z.B. durch die Reduktion der Anzahl an zu testenden Varianten. Jedoch wird weiterhin jede Variante unabhängig getestet, ohne dabei das Wissen über Gemeinsamkeiten und Variabilität auszunutzen, um den Testaufwand zu reduzieren. Des Weiteren muss sich die SPL-Entwicklung mit der Evolution von Software auseinandersetzen. Dies birgt weitere Herausforderungen für das SPL-Testen, da nicht nur für Varianten sondern auch für ihre Versionen die Qualität sichergestellt werden muss. In dieser Arbeit stellen wir ein Framework für das modellbasierte Regressionstesten von evolvierenden SPL vor, das die Herausforderungen des redundanten Testens und der Software-Evolution adressiert. Das Framework vereint Testmodellierung, Änderungsauswirkungsanalyse und automatische Testfallselektion, um einen inkrementellen Testprozess zu definieren, der Varianten und Variantenversionen unter Ausnutzung des Wissens über gemeinsame Funktionalität und dem Wiederverwendungspotential von Testartefakten und -resultaten effizient testet. Für die Testmodellierung entwickeln wir einen Ansatz, der Variabilitäts- sowie Versionsinformation von evolvierenden SPL gleichermaßen für die Modellierung einbezieht. Für die Änderungsauswirkungsanalyse definieren wir zwei Techniken, um zum einen Änderungen in Ausführungsabhängigkeiten zwischen zu testenden Varianten und ihren Versionen zu identifizieren und zum anderen die Auswirkungen eines Evolutionsschrittes auf die Variantenmenge zu bestimmen und zu klassifizieren. Für die Testfallselektion schlagen wir ein Abdeckungskriterium vor, das die Resultate der Auswirkungsanalyse einbezieht, um automatisierte Entscheidungen über einen Wiederholungstest von wiederverwendbaren Testfällen durchzuführen. Die abdeckungsgetriebene Testfallselektion ermöglicht somit die Reduktion der redundanten Testfallausführungen während des inkrementellen Testens von Varianten und Variantenversionen. Das Framework ist prototypisch implementiert und anhand von drei evolvierenden SPL evaluiert. Die Resultate zeigen, dass eine Aufwandsreduktion für das Testen evolvierender SPL erreicht wird

Mining and untangling change genealogies

Developers change source code to add new functionality, fix bugs, or refactor their code. Many of these changes have immediate impact on quality or stability. However, some impact of changes may become evident only in the long term. This thesis makes use of change genealogy dependency graphs modeling dependencies between code changes capturing how earlier changes enable and cause later ones. Using change genealogies, it is possible to: (a) applyformalmethodslikemodelcheckingonversionarchivestorevealtemporal process patterns. Such patterns encode key features of the software process and can be validated automatically: In an evaluation of four open source histories, our prototype would recommend pending activities with a precision of 60—72%. (b) classify the purpose of code changes. Analyzing the change dependencies on change genealogies shows that change genealogy network metrics can be used to automatically separate bug fixing from feature implementing code changes. (c) build competitive defect prediction models. Defect prediction models based on change genealogy network metrics show competitive prediction accuracy when compared to state-of-the-art defect prediction models. As many other approaches mining version archives, change genealogies and their applications rely on two basic assumptions: code changes are considered to be atomic and bug reports are considered to refer to corrective maintenance tasks. In a manual examination of more than 7,000 issue reports and code changes from bug databases and version control systems of open- source projects, we found 34% of all issue reports to be misclassified and that up to 15% of all applied issue fixes consist of multiple combined code changes serving multiple developer maintenance tasks. This introduces bias in bug prediction models confusing bugs and features. To partially solve these issues we present an approach to untangle such combined changes with a mean success rate of 58—90% after the fact.Softwareentwickler ändern Source-Code um neue Funktionalität hinzuzufügen, Bugs zu beheben oder um ihren Code zu restrukturieren. Viele dieser Änderungen haben einen direkten Einfluss auf Qualität und Stabilität des Softwareprodukts. Jedoch kommen einige dieser Einflüsse erst zu einem späteren Zeitpunkt zur Geltung. Diese Arbeit verwendet Genealogien zwischen Code-Änderungen um zu erfassen, wie frühere Änderungen spätere Änderungen erfordern oder ermöglichen. Die Verwendung von Änderungs-Genealogien ermöglicht: (a) die Anwendung formaler Methoden wie Model-Checking auf Versionsarchive um temporäre Prozessmuster zu erkennen. Solche Prozessmuster verdeutlichen Hauptmerkmale eines Softwareentwicklungsprozesses: In einer Evaluation auf vier Open-Source Projekten war unser Prototyp im Stande noch ausstehende Änderungen mit einer Präzision von 60–72% vorherzusagen. (b) die Absicht einer Code-Änderung zu bestimmen. Analysen von Änderungsabhängigkeiten zeigen, dass Netzwerkmetriken auf Änderungsgenealogien geeignet sind um fehlerbehebende Änderungen von Änderungen die eine Funktionalität hinzufügen zu trennen. (c) konkurrenzfähige Fehlervorhersagen zu erstellen. Fehlervorhersagen basierend auf Genealogie-Metriken können sich mit anerkannten Fehlervorhersagemodellen messen. Änderungs-Genealogien und deren Anwendungen basieren, wie andere Data-Mining Ansätze auch, auf zwei fundamentalen Annahmen: Code-Änderungen beabsichtigen die Lösung nur eines Problems und Bug-Reports weisen auf Fehler korrigierende Tätigkeiten hin. Eine manuelle Inspektion von mehr als 7.000 Issue-Reports und Code-Änderungen hat ergeben, dass 34% aller Issue-Reports falsch klassifiziert sind und dass bis zu 15% aller fehlerbehebender Änderungen mehr als nur einem Entwicklungs-Task dienen. Dies wirkt sich negativ auf Vorhersagemodelle aus, die nicht mehr klar zwischen Bug-Fixes und anderen Änderungen unterscheiden können. Als Lösungsansatz stellen wir einen Algorithmus vor, der solche nicht eindeutigen Änderungen mit einer Erfolgsrate von 58–90% entwirrt

Uma proposta para rastreabilidade no desenvolvimento de software

Orientador: Mario JinoTese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de ComputaçãoResumo: Rastreabilidade tem sido um tópico de pesquisa no desenvolvimento de software por pelo menos 40 anos, sendo adicionada a muitos padrões, como o DOD-STD-2167A e o IEEE 830-1998. Este último, por exemplo, afirma que uma boa especificação de requisitos de software deve ser rastreável. A rastreabilidade fornece muitos benefícios para projetos de software, tais como: identificação das razões para decisões de design, prevenção de problemas de dependência, identificação de responsabilidades em um projeto, estimação de impacto e de custo de modificações, e medição do progresso de desenvolvimento. Sucintamente, a rastreabilidade permite a geração de um produto de melhor qualidade. Dois principais focos surgiram na literatura nos últimos anos: desenvolvimento baseado em modelo e geração automática de rastros. O primeiro trata da modelagem de rastreabilidade, definindo relações e elementos de um projeto; o segundo trata da descoberta automática de relações entre elementos. Vários conceitos foram definidos até agora, como rastreabilidade bidirecional, rastreabilidade de especificações pré e pós-requisitos, rastreabilidade horizontal e vertical, e rastreabilidade explícita e implícita. Embora haja um consenso geral sobre a maioria dos conceitos relacionados a rastreabilidade, há uma falta de consenso sobre como, e o quê, deve ser rastreado; não há consenso sobre: quais relações são relevantes para os projetos de desenvolvimento de software, quais elementos devem ser rastreados, como as mudanças nos elementos de um projeto afetam as relações existentes, ou como atualizar as relações dadas certas mudanças. Os modelos de rastreabilidade visam responder a essas questões fornecendo um padrão para ser usado como uma guia em projetos de desenvolvimento de software; entretanto, não há consenso sobre o que um modelo deve conter. Existe uma variedade de modelos, cada um considerando diferentes tipos de relações, elementos, e possuindo diferentes focos. Além disso, a maioria dos modelos possui problemas que tornam o seu uso difícil, ou até mesmo impossível; por exemplo, existem modelos que não descrevem - suficientemente ou em nada - as ligações de rastreabilidade que propõem. Este trabalho visa a ajudar nesta questão, fornecendo uma contribuição dupla: um modelo de referência para criar e avaliar modelos de rastreabilidade, e um metamodelo abrangente, construído em cima do modelo de referência, para adicionar rastreabilidade a projetos de desenvolvimento de software. Nosso Modelo de Referência para rastreabilidade define os elementos básicos em um modelo de rastreabilidade e define conjuntos básicos de: ações, tipos de ligações, tipos de artefatos, e processos. Propriedades necessárias para o conjunto de tipos de ligações e o conjunto de tipos de artefatos também são fornecidas. Nosso Metamodelo para rastreabilidade é composto por: um modelo conceitual descrevendo e organizando os elementos de rastreabilidade; um conjunto de tipos de artefatos representando as atividades definidas no Modelo de Referência, além de um conjunto de tipos de artefatos criados para registrar decisões de design; um conjunto de tipos de ligações que modelam diferentes relações de rastreabilidade; e um conjunto de processos para garantir a consistência de projetosAbstract: Traceability has been a topic of research in software development for at least 40 years, being added to many standards, such as the DOD-STD-2167A and the IEEE 830-1998. The latter, for instance, states that a good software requirements specification should be traceable. Traceability provides many benefits to software projects, such as: identification of the reasons for design decisions, avoidance of dependency issues, identification of accountability in a project, estimation of impact and cost of modifications, and measurement of development progress. Succintly, traceability allows the generation of a better quality product. Two main focuses have emerged in the literature in recent years: model-based development and automated trace generation. The former concerns modeling traceability by defining relations and elements in a project; the latter concerns automatic discovery of relations between elements in a project. Several concepts have been defined so far, such as bidirectional traceability, pre and post-requirements specification traceability, horizontal and vertical traceability, and explicit and implicit traceability. While there is general consensus on most concepts related to traceability, there is a lack of consensus on how, and what, should be traced; there is no consensus on which relations are relevant for software development projects, which elements should be traced, how changes in elements of a project affects existing relations, or how to update relations given certain changes. Traceability models aim to answer these questions by providing a standard to be used as a guide in software development projects; however, there is no consensus on what a model should contain. There is a variety of models, each considering different types of relations, elements, and having distinct focuses. Also, the majority of models have issues which makes them difficult or even impossible to use; for instance, there are models which do not describe - sufficiently or at all - traceability links which they propose. This work aims to help in this issue by providing a twofold contribution: a reference model for creating and evaluating traceability models, and a comprehensive metamodel, built on top of the reference model, to add traceability to software development projects. Our Reference Model for traceability defines the basic elements in a traceability model and defines basic sets of: actions, link types, artifact types, and processes. Necessary properties for the sets of link types and artifact types are also provided. Our Metamodel for traceability is composed of: a conceptual model describing and organizing the elements of traceability; a set of artifact types representing the activities of the Reference Model, plus a set of artifact types created to record design decisions; a set of link types modeling different traceability relations; and a set of processes to ensure project consistencyDoutoradoEngenharia de ComputaçãoDoutor em Engenharia Elétrica1142618CAPE