Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

Context: Technical debt (TD) is a metaphor used to describe technical decisions that can give the company a benefit in the short term but possibly hurting the overall quality of the software in the long term. Objective: This study aims to characterize the current state of practices related to TD payment from the point of view of software practitioners. Method: We used a survey research method to collect and analyze - both quantitatively and qualitatively - a corpus of responses from a survey of 432 software practitioners from Colombia, Chile, Brazil, and the United States, as a part of the InsighTD project. Results: We were able to identify that refactoring (24.3%) was the main practice related to TD payment, along with improving testing (6.2%) and improve design (5.8%). Also, we identify that small-sized systems and big-sized systems, along with young systems (less than one year) tend to use more refactoring. As a part of these results, we also could identify that some practices do not eliminate the debt by itself, but support a favorable scenario for TD payment or prevention. Additionally, after comparing the three major TD types cited (code debt, test debt and design debt) we could discover an important similarity of TD payment practices between code debt and design debt. Lastly, we identified that no matter the cause leading to TD occurrence, refactoring remained the most common practice. Conclusion: Definition of practices related to TD payment is an essential activity for software development teams. Developing healthy software systems that can be maintained in the future requires that companies find the right approaches for TD payment.

Architectural Technical Debt (ATD) is a metaphor used to describe consciously decisions taken by software architects to accomplish short-term goals but possibly negatively affecting the long-term health of the system. However, difficulties arise when repayment strategies are defined because software architects need to be aware of the consequences of these strategies over others decisions in the software architecture. This article proposes REBEL, a semi-automated model-driven approach that exploits natural language processing, machine learning and model checking techniques on heterogeneous project artifacts to build a model that allows to locate and visualize the impact produced by the consciously injected ATD and its repayment strategy on the other architectural decisions. The technique is illustrated with a data analytics project in Colombia where software architects are unaware of the consequences of the repayment strategies. This proposal seeks to support teams of architects to make explicit the current and future impact of the ATD injected as a result of decisions taken, focusing on the architectural level rather than code level.

In Software Architecture (SA), design decisions are considered valuable knowledge, and Architectural Knowledge (AK) is key to increase software quality. Several proposals address implementation of Knowledge Management for Software Architecture, but very few address sharing and distribution of AK. We propose that AK be shared as concrete usage scenarios, elicited from design meetings; this proposal builds on Knowledge Management sharing insights and on DVIA (Design Verbal Interventions Analysis), which identifies design decisions by mapping verbal interventions in recorded design meetings. Specifically, we show an scenario of decision impact analysis for introducing a new functional requirement. The approach was initially validated in a case study with undergraduate practitioners video-recorded while team-designing a command-and-control center for the pan-Andean spatial project. Initial qualitative results suggest that AK reuse is actually helped by sharing specific design scenarios.

This paper presents MONO, a tool to support interdisciplinary and geographically dispersed teams. MONO supports the definition, execution, and monitoring of collaborative processes to allow development engineers to interact with musicians, designers, and producers, to create digital contents such as video games or animated short films. MONO supports geographically distributed teams, involved in digital content software development projects, by means of dynamic and configurable executable processes, and coordination and monitoring tools. In this work, we describe our experience developing MONO and the results obtained in our initial validation.

There is currently a vast array of open source projects available on the web, and although they are searchable by name or description in the search engines, there is no way to search for projects by how well they perform on a given set of quality attributes (e.g. usability or maintainability). With OpenHub, we present a scalable and extensible architecture for the static and runtime analysis of open source repositories written in Python, presenting the architecture and pinpointing future possibilities with it.

During the last years, software architecture has become an increasingly necessary subject in IT education. At Universidad de los Andes, a software architecture course is taught midway through the Systems and Computer Engineering degree and aims to create skills within the student to identify quality requirements as well as designing software architectures for middle-sized systems. However, based on statistics over the last 8 years of our Software Architecture course, we've noticed that correctly identifying quality requirements seems to be a recurring issue among students. One of the course's objectives comprehends the construction of an architecture document during the semester, which must be done in groups who tend to find it difficult to get together and work as a team. This paper present Archinotes, a collaboration tool to support the teaching of software architectures by facilitating collaboration workload and providing useful information on the difficulties and progress of the students to the course's teacher. The conclusions of the paper prove Archinotes effective in helping students learn critical concepts and artifacts during the software architecture course.

In these days one of the most recurrent problem of the EA projects, is the elaboration of a roadmap that includes the set of initiatives, that close the gaps between an initial architecture (AS-IS) and a target architecture (TO-BE). The trouble of this task, is mostly because the choice of the transition plan that composes a roadmap, is made regardless the set of criteria and needs exposed by the organization. Based on that, the present proposal, includes the construction of a tool that facilitates the analysis and elaboration of a roadmap, whose composition is a set of transitions, chosen from the criteria established by the organization and the EA project. The choice of the number of transitions and initiatives for each one, is made through an optimization algorithm based in the criteria selected.

Service Oriented Architectures (SOA) can be used for the design and creation of reusable business services that may be shared across the company. The complexity of the business processes, and their changing environment sheds a highly complex SOA architecture solution as a result. Without an adequate control measure SOA could quickly lead to be unmanageable for IT administrators and architects. In this paper we propose a strategy based on Model-Driven Engineering (MDE) to provide support to architecture governance, allowing the definition of policies on SOA systems as well as the assessment of these policies within the solution architecture.

Certain diseases and clinical conditions can become serious public health issues. This is particularly true in neurology where chronic headache illness is a burden borne by a great extent of the population. Assertively diagnosing headaches requires the patient to fill out printed forms and collect d