A reuse-based economic model for software reference architectures

The growing size and complexity of software systems, together with critical time-to-market needs, demand new software engineering approaches for software development. To remain competitive, organizations are challenged to make informed and feasible value-driven design decisions in order to ensure the quality of the systems. However, there is a lack of support for evaluating the economic impact of these decisions with regard to software reference architectures. This damages the communication among architects and management, which can result in poor decisions. This paper aims at opening a path in this direction by presenting a pragmatic preliminary economic model to perform cost-benefit analysis on the adoption of software reference architectures as key asset for optimizing architectural decision-making. A preliminary validation based on a retrospective study showed the ability of the model to support a cost-benefit analysis presented to the management of an IT consulting company.Preprin

On the Temporality of Introducing Code Technical Debt

Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy work-load, tight delivery schedule, unawareness of good practices, etc. To shed light into the context that leads to technical debt accumulation, in this paper we investigate: (a) the temporality of code technical debt introduction in new methods, i.e., whether the introduction of technical debt is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of technical debt introduction and the development team’s workload in a given period. To answer these questions, we perform a case study on twenty-seven Apache projects, and inspect the number of Technical Debt Items introduced in 6-month sliding temporal windows. The results of the study suggest that: (a) overall, the number of Technical Debt Items introduced through new code is a stable metric, although it presents some spikes; and (b) the number of commits performed is not strongly correlated to the number of introduced Technical Debt Items

Applying static code analysis for domain-specific languages

The use of code quality control platforms for analysing source code is increasingly gaining attention in the developer community. These platforms are prepared to parse and check source code written in a variety of general-purpose programming languages. The emergence of domain-specific languages enables professionals from different areas to develop and describe problem solutions in their disciplines. Thus, source code quality analysis methods and tools can also be applied to software artefacts developed with a domain-specific language. To evaluate the quality of domain-specific language code, every software component required by the quality platform to parse and query the source code must be developed. This becomes a time-consuming and error-prone task, for which this paper describes a model-driven interoperability strategy that bridges the gap between the grammar formats of source code quality parsers and domain-specific text languages. This approach has been tested on the most widespread platforms for designing text-based languages and source code analysis. This interoperability approach has been evaluated on a number of specific contexts in different domain areas

The temporality of technical debt introduction on new code and confounding factors

Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy workload, tight delivery schedule, or developers’ lack of experience. Since a software system grows mostly through the addition of new code, it is interesting to study how TD fluctuates along this process. Specifically, in this paper, we investigate: (a) the temporality of code TD introduction in new code, i.e., whether the introduction of TD is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of TD introduction to the development team’s workload in a given period, as well as to the experience of the development team. To answer these questions, we have performed a case study on 47 open-source projects from two well-known ecosystems (Apache and Eclipse) as well as additional isolated projects from GitHub (not selected from a specific ecosystem) and inspected the number of TD issues introduced in 6-month sliding temporal windows. The results of the study suggested that: (a) overall, the number of TD issues introduced through new code is a stable measure, although it presents spikes; and (b) the number of commits performed, as well as developers’ experience are not strongly correlated to the number of introduced TD issues.</p

Apoio a promoção da visibilidade da dívida técnica

Trabalho de Conclusão de Curso (graduação)—Universidade de Brasília, Faculdade UnB Gama, 2018.A Dívida Técnica é uma metáfora que retrata a perda de qualidade no código, sendo utilizada para tomada de decisões durante o desenvolvimento. Essa dívida técnica parece estar mais presente nas metodologias ágeis de desenvolvimento de software devido a ênfase em entrega de funcionalidades, em que a dívida pode acabar prejudicando a produtividade do time a longo prazo, sendo interessante para essas metodologias poderem tomar decisões relacionadas a dívida técnica de modo mais estratégico para beneficiar a organização. Mas para isso é necessário que essa dívida esteja visível para as partes interessadas, sendo que a dívida precisa ser identificada, coletada e comunicada na organização. Este trabalho discute sobre como é possível promover a visibilidade da Dívida Técnica dentro de um contexto de metodologias ágeis de desenvolvimento. Para isso foi identificado que técnicas existem para se identificar, medir e comunicar a dívida, e bem quais métricas existem para se estimar a dívida. Por fim, é proposto um método para promover a visibilidade, que permite a identificação, medição e comunicação da dívida, podendo fornecer os valores estimados em duas métricas diferentes, a de esforço e em valores financeiros.The Technical Debt is a metaphor that portrays the loss of quality in the code, being used for decision making during development. This technical debt seems to be more present in the agile methodologies of software development due to the emphasis on functional delivery, in which the debt can end up harming the team’s productivity in the long term, being interesting for these methodologies to be able to make decisions related to technical debt in a way to benefit the organization. But for this it is necessary for the debt to be visible to the interested parties, being that the debt needs to be identified, estimated and communicated in the organization. This work discusses how it is possible to promote the visibility of the Technical Debt within a context of agile methodologies of development. For this, it was identified what techniques exist to identify, measure and communicate the debt, and well what metrics exist to estimate the debt. Finally, a method is proposed to promote visibility, which allows the identification, measurement and communication of the debt, and can provide the estimated values in two different metrics, effort and financial figures

Practical Consequences of Quality Views in Assessing Software Quality

open access articleThe authors’ previously published research delved into the theory of software product quality modelling, model views, concepts, and terminologies. They also analysed this specific field from the point of view of uncertainty, and possible descriptions based on fuzzy set theory and fuzzy logic. Laying a theoretical foundation was necessary; however, software professionals need a more tangible and practical approach for their everyday work. Consequently, the authors devote this paper to filling in this gap; it aims to illustrate how to interpret and utilise the previous findings, including the established taxonomy of the software product quality models. The developed fuzzy model’s simplification is also presented with a Generalized Additive Model approximation. The paper does not require any formal knowledge of uncertainty computations and reasoning under uncertainty, nor does it need a deep understanding of quality modelling in terms of terminology, concepts, and meta-models, which were necessary to prepare the taxonomy and relevance ranking. The paper investigates how to determine the validity of statements based on a given software product quality model; moreover, it considers how to tailor and adjust quality models to the particular project’s needs. The paper also describes how to apply different software product quality models for different quality views to take advantage of the automation potential offered for the measurement and assessment of source code quality. Furthermore, frequent pitfalls are illustrated with their corresponding resolutions, including an unmeasured quality property that is found to be important and needs to be included in the measurement and assessment process