Software maintenance is a significant part of software system lifetime. Softwaresystem lifetime incorporates many processes including software adaptation and software evolution. These processes collide into one another and create confusion as theboundaries that separate them are often difficult to distinguish. Knowing what exactly these concepts indicate and how they are related can bring simplicity to futuredevelopment of adaptive systems. The following document presents a performed systematic literature review, which aims to outline the similarities and the differences ofadaptation and evolution and further explain how they are related. The results of thestudy show that adaptation and evolution have become more entwined with growthof interest to self-managing dynamic software.

Submitted by Renata Lopes (renatasil82@gmail.com) on 2015-12-01T13:21:15Z No. of bitstreams: 1 jacimarfernandestavares.pdf: 4117614 bytes, checksum: 6d7763e08f1653c32b20373c9e55ec2b (MD5) / Made available in DSpace on 2015-12-01T13:21:15Z (GMT). No. of bitstreams: 1 jacimarfernandestavares.pdf: 4117614 bytes, checksum: 6d7763e08f1653c32b20373c9e55ec2b (MD5) Previous issue date: 2015-03-16 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Existem diversas tecnologias desenvolvidas nas areas de manuten c~ao e evolu c~ao colaborativa de software associadas a visualiza c~ao de software, objetivando resolver problemas de empresas e grupos de usu arios. Em muitos casos e necess ario integrar solu c~oes dessas areas visando resolver um dado problema relacionado a evolu c~ao do software. Este problema se torna mais intenso quando se trata de equipes geogra camente distribu das. Neste sentido, foi desenvolvida GiveMe Infra, uma infraestrutura para apoio a realiza c~ao de atividades de manuten c~ao e evolu c~ao de software, realizadas por equipes co-localizadas ou geogra camente distribu das. Tais atividades s~ao apoiadas por diferentes visualiza c~oes de software que permitem ao usu ario obter diferentes perspectivas sobre as informa c~oes disponibilizadas. Um estudo experimental foi realizado objetivando veri car a viabilidade de uso da solu c~ao. Os resultados obtidos s~ao apresentados, bem como os trabalhos futuros em rela c~ao a infraestrutura proposta. / There are several technologies developed to support collaborative software maintenance and evolution, as well as software visualization, in order to solve problems of companies and group of users. In many cases is necessary to integrate solutions already available in these areas to solve a given problem. These problems become intense when geographically dispersed groups are involved in software maintenance and evolution activities. In this sense, an infrastructure, named GiveMe Infra, was developed to support these activities when performed by co-located or geographically distributed teams. These activities are supported by di erent software visualizations that allow the user get di erent perspectives about the provided information. An experimental study were carried out aiming to verify the feasibility of the solution as well as the hypotheses. The obtained results related to the experiments and future works are presented

Manter os documentos de requisitos atualizados e recuperar os requisitos de um software são desafios enfrentados por desenvolvedores no seu dia a dia durante o desenvolvimento, a manutenção e a evolução de sistemas. Embora existam técnicas para gestão de requisitos, muitas vezes estas técnicas não são aplicadas, os requisitos não são atualizados e a única fonte de informação confiável sobre um software passa a ser seu código-fonte. Esta tese apresenta a TDRRC, uma técnica para a documentação e recuperação dos requisitos no código-fonte usando anotações. A TDRRC possibilita a reengenharia de requisitos sem que haja uma interrupção no desenvolvimento e permite que os requisitos sejam documentados em ambientes de desenvolvimento ágil. A TDRRC contribui para a redução dos problemas relacionados à atualização dos requisitos, pois o desenvolvedor responsável pelo programa passa a ser responsável pela documentação e atualização dos requisitos no código-fonte que ele escreve e mantém. Este trabalho apresenta também formas de aplicar a TDRRC na reengenharia de requisitos, em métodos ágeis e na gestão de requisitos, assim como a sua aplicação em um estudo de caso. / Keeping requirements documents updated and recovering requirements of a software are common challenges faced by developers on their day to day activities. Although there are many requirements management techniques, usually these techniques are not applied, requirements are not updated and the only reliable source of information about a software becomes its source code. This thesis presents TDRRC, a technique that can be used to document and retrieve requirements from the source code using annotations. Applying TDRRC, it is possible to reengineer the requirements of a software without interrupting its development. Also requirements can be documented in a agile environment. TDRRC also contributes to minimize requirements documents update issues as the developer will be clearly responsible for documenting and updating the requirements in the source code he is programming. This thesis also presents how to apply the technique in a requirement reengineering project, in a agile development environment and in a requirements management process. Finally a case study is presented.

This work concerns with dynamic evolution of applications written in Java. It investigates existing solutions implemented in both Java and other programming languages. Following part analyses complete substitution of object in running application in various situations. A framework for dynamic updating of Java-based applications is designed. The framework is implemented and is used in illustrative application. Finally, achieved results are evaluated and additional possible enhancements are stated.

Code decay is a gradual process that negatively impacts the quality of a software system. Developers need trusted measurement techniques to evaluate whether their systems have decayed. This dissertation aims to assess code decay by discovering software architectural violations. Our methodology uses Lightweight Sanity Check for Implemented Architectures to derive architectural constraints represented by can-use and cannot-use phrases. Our methodology also uses Lattix to discover architectural violations. We also introduce measures that indicate code decay in a software system. We conducted two case studies of proprietary systems (9 versions of System A and 14 versions of System B) to demonstrate our methodology for assessing code decay. Resulting architectural constraints and architectural violations were validated by the expert of each system. Our results show that the net violations of System A increased from one version to other version even though there were architecture changes. However, in System B, the number of net violations decreased after changes in the architecture. The proposed code decay metrics can give managers insight into the process of software development, the history of the software product, and the status of unresolved violations. Our results and qualitative analysis showed that the methodology was effective and required a practical level of effort for moderate sized software systems. Code decay values increase because of an increase in the number of violations over multiple versions. We compared our code decay measures with definitions in the literature, namely coupling metrics. In addition, our empirical results showed that coupling is qualitatively correlated with the size of a system as expected. We note that coupling is an opportunity for architectural violations. We concluded that coupling is not consistently related to violations.

Software maintenance is one of the most crucial aspects of software development. Software engineering researchers must develop practical solutions to handle the challenges presented in maintaining mature software systems. Research that addresses practical means of mitigating the risks involved when changing software, reducing the complexity of mature software systems, and eliminating the introduction of preventable bugs is paramount to today’s software engineering discipline. Giving software developers the information that they need to make quality decisions about changes that will negatively affect their software systems is a key aspect to mitigating those risks. This dissertation presents work performed to assist developers to collect and process data that plays a role in change decision-making during the maintenance phase. To address these problems, developers need a way to better understand the effects of a change prior to making the change. This research addresses the problems associated with increasing architectural complexity caused by software change using a twoold approach. The first approach is to characterize software changes to assess their architectural impact prior to their implementation. The second approach is to identify a set of architecture metrics that correlate to system quality and maintainability and to use these metrics to determine the level of difficulty involved in making a change. The two approaches have been combined and the results presented provide developers with a beneficial analysis framework that offers insight into the change process.

No description available.

We propose a Capabilities-based approach for constructing complex emergent systems such that they are change-tolerant, and the development effort promotes change-reduction. The inherent complexity of software systems increases their susceptibility to change when subjected to the vagaries of user needs, technology advances, market demands and other change inducing factors. Despite the inevitability of change, traditional Requirements Engineering strives to develop systems based on a fixed solution. This is a mostly unsuccessful approach as evidenced by the history of system failures. In contrast, we utilize Capabilities — functional abstractions that are neither as amorphous as user needs nor as rigid as system requirements — to architect systems to accommodate change with minimum impact. These entities are designed to exhibit desirable characteristics of high cohesion, low coupling and balanced abstraction levels. Capabilities are generated by a two-phased process called Capabilities Engineering. Phase I mathematically exploits the structural semantics of the Function Decomposition graph — a representation of user needs — to formulate change-tolerant Capabilities. Phase II optimizes these Capabilities to conform to schedule and technology constraints. Results from an empirical evaluation of a real-world Course Evaluation System indicate, with statistical significance, that a Capabilities-based design is more change-tolerant than a requirements-based design. In addition, we observe that the use of the CE process inherently reduces change, otherwise generated, during the regular development effort. Empirical analysis on the change-requests of Sakai, a complex emergent system, supports this claim. Finally, we observe that the process of Capabilities Engineering assists in pre-requirement specification traceability by bridging the complexity gap between the problem and solution spaces. / Ph. D.

Software maintenance is such an integral part of its evolutionary process that it consumes much of the total resources available. Some estimate the costs of maintenance to be up to 100 times the amount of developing a software. A software not maintained builds up technical debt, and not paying off that debt timely will eventually outweigh the value of the software, if no countermeasures are undertaken. A software must adapt to changes in its environment, or to new and changed requirements. It must further receive corrections for emerging faults and vulnerabilities. Constant maintenance can prepare a software for the accommodation of future changes. While there may be plenty of rationale for future changes, the reasons behind historical changes may not be accessible longer. Understanding change in software evolution provides valuable insights into, e.g., the quality of a project, or aspects of the underlying development process. These are worth exploiting, for, e.g., fault prediction, managing the composition of the development team, or for effort estimation models. The size of software is a metric often used in such models, yet it is not well-defined. In this thesis, we seek to establish a robust, versatile and computationally cheap metric, that quantifies the size of changes made during maintenance. We operationalize this new metric and exploit it for automated and efficient commit classification. Our results show that the density of a commit, that is, the ratio between its net- and gross-size, is a metric that can replace other, more expensive metrics in existing classification models. Models using this metric represent the current state of the art in automatic commit classification. The density provides a more fine-grained and detailed insight into the types of maintenance activities in a software project. Additional properties of commits, such as their relation or intermediate sojourn-times, have not been previously exploited for improved classification of changes. We reason about the potential of these, and suggest and implement dependent mixture- and Bayesian models that exploit joint conditional densities, models that each have their own trade-offs with regard to computational cost and complexity, and prediction accuracy. Such models can outperform well-established classifiers, such as Gradient Boosting Machines. All of our empirical evaluation comprise large datasets, software and experiments, all of which we have published alongside the results as open-access. We have reused, extended and created datasets, and released software packages for change detection and Bayesian models used for all of the studies conducted.

Software development is driven by the development team's decisions. Communicating the rationale behind these decisions is essential for the projects success. Although the software engineering community recognizes the need and importance of rationale, there has been a lack of in-depth study of rationale for code changes. To bridge this gap, this dissertation examines the rationale behind code changes in-depth and breadth. This work includes two studies and an experiment. The first study aims to understand software developers' need. It finds that software developers need to investigate code changes to understand their rationale when working on diverse tasks. The study also reveals that software developers decompose the rationale of code commits into 15 separate components that they could seek when searching for rationale. The second study surveys software developers' experiences with rationale. It uncovers issues and challenges that software developers encounter while searching for and recording rationale for code changes. The study highlights rationale components that are needed and hard to find. Additionally, it discusses factors leading software developers to give up their search for the rationale of code changes. Finally, the experiment predicts the documentation of rationale components in pull request templates. Multiple statistical models are built to predict if rationale components' headers will not be filled. The trained models are effective in achieving high accuracy and recall. Overall, this work's findings shed light on the need for rationale and offer deep insights for fulfilling this important information need. / Doctor of Philosophy / Software developers build software by creating and changing the software's code. In this process, developers make decisions and other developers need to understand these decisions. The rationale behind code changes is an important piece of information that leads to development success if well explained and understood. In this work, we study the developers' need for rationale by conducting two studies and an experiment. In the first study, we found that software developers often need to look into the rationale behind code changes to understand them better while working on different tasks. We identified 15 different parts of rationale that developers seek when searching for rationale for code changes. The second study focused on the experiences of software developers when looking for and recording rationale. We discovered some challenges that developers face, like difficulty in finding specific rationale parts and the factors that make developers give up searching for rationale. The experiment predicts if developers would document rationale in specific templates. We built models to predict if certain parts of rationale would be left empty, and the models were effective. Overall, this research provides a better understanding of software developers' need, and it provides valuable insights to help fulfill this important information need.