Supporting Defect Causal Analysis in Practice with Cross-Company Data on Causes of Requirements Engineering Problems

[Context] Defect Causal Analysis (DCA) represents an efficient practice to improve software processes. While knowledge on cause-effect relations is helpful to support DCA, collecting cause-effect data may require significant effort and time. [Goal] We propose and evaluate a new DCA approach that uses cross-company data to support the practical application of DCA. [Method] We collected cross-company data on causes of requirements engineering problems from 74 Brazilian organizations and built a Bayesian network. Our DCA approach uses the diagnostic inference of the Bayesian network to support DCA sessions. We evaluated our approach by applying a model for technology transfer to industry and conducted three consecutive evaluations: (i) in academia, (ii) with industry representatives of the Fraunhofer Project Center at UFBA, and (iii) in an industrial case study at the Brazilian National Development Bank (BNDES). [Results] We received positive feedback in all three evaluations and the cross-company data was considered helpful for determining main causes. [Conclusions] Our results strengthen our confidence in that supporting DCA with cross-company data is promising and should be further investigated.Comment: 10 pages, 8 figures, accepted for the 39th International Conference on Software Engineering (ICSE'17

Divergências na adoção das IPSAS no setor público : uma análise comparativa internacional da demonstração da posição financeira

Trabalho de conclusão de curso (graduação)—Universidade de Brasília, Faculdade de Economia, Administração e Contabilidade, Departamento de Ciências Contábeis e Atuariais, Bacharelado em Ciências Contábeis, 2013.Este estudo tem como objetivo evidenciar as divergências na forma de elaboração da Demonstração da Posição Financeira (Balanço Patrimonial) elaboradas entre os anos de 2010 e 2011 pelos Governos de sete países em processo de convergência: Brasil, Canadá, Estados Unidos, França, México, Reino Unido e União Européia, tendo por base a proposta apresentada na IPSAS 1 — Presentation of Financial Statements, por meio de uma análise da forma dos itens presentes no balanço e da relação entre o patrimônio líquido (PL) e seus ativos. Trata-se de estudo de natureza exploratória, com abordagem de pesquisa do tipo qualitativa, com coleta de dados realizada de forma essencialmente documental. A justificativa para o estudo está na percepção de que, com relação às IPSAS, os países vêm adotando estratégias para atender suas tipicidades locais, o que pode prejudicar a aceitação e a convergência internacional a essas normas. Os resultados mostram que, na elaboração da Demonstração da Posição Financeira, nenhum dos sete países analisados atende integralmente aos itens presentes na IPSAS 1, e que o Brasil foi o único país cuja variação patrimonial apresentou-se positiva ao adotar os procedimentos patrimoniais indicados pelas IPSAS, o que reforça a recomendação sobre a necessidade de se manter um maior cuidado antes de as novas regras serem institucionalizadas pelos países adotantes

Understanding automated and human-based technical debt identification approaches-a two-phase study

Context: The technical debt (TD) concept inspires the development of useful methods and tools that support TD identification and management. However, there is a lack of evidence on how different TD identification tools could be complementary and, also, how human-based identification compares with them. Objective: To understand how to effectively elicit TD from humans, to investigate several types of tools for TD identification, and to understand the developers’ point of view about TD indicators and items reported by tools. Method: We asked developers to identify TD items from a real software project. We also collected the output of three tools to automatically identify TD and compared the results in terms of their locations in the source code. Then, we collected developers’ opinions on the identification process through a focus group. Results: Aggregation seems to be an appropriate way to combine TD reported by developers. The tools used cannot help in identifying many important TD types, so involving humans is necessary. Developers reported that the tools would help them to identify TD faster or more accurately and that project priorities and current development activities are important to be considered together, along with the values of principal and interest, when deciding to pay off a debt. Conclusion: This work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered

Theory Use In Software Engineering: A Systematic Mapping Study

<p><strong>Abstract </strong></p> <p><strong>Context:</strong> A theory is a well-substantiated explanation of an aspect of the natural world that can incorporate laws, hypotheses, and facts. Its thinking process is often associated with an observational study or research. However, in many disciplines, the nature, role, and even the necessity of theories remains controversial, particularly in young or practical disciplines such as software engineering (SE).</p> <p><strong>Objective:</strong> This study aims to provide an overview of SE theoretical research with respect to the research efforts that have been put into theory use and theory building to date.</p> <p><strong>Method:</strong> We conducted a systematic mapping study to classify evidence on theory definitions, studies’ quality, research topics, methods, types, theory types, theory roles and publication venues.</p> <p><strong>Results:</strong> The mapping study includes 42 studies located from online database searches, forward and backward snowballing of references. Our results showed that the term “theory” varied among SE studies due to inconsistent terminology use, necessitating a comprehensive approach for accurate identification. Most studies showed good quality of rigor and relevance, and acceptable credibility; as for reporting, many studies were unsatisfactory. Most of the extracted theories fall within the Explanation and Prediction (42.9% of the studies) and Prediction (11.9% of the studies) categories, whereas Analysis (7.1% of the studies) was the least employed.</p> <p><strong>Conclusion:</strong> We highlighted the research gaps and implications for research and practice to support theory use and theory building in SE.</p&gt

Making technical debt visible using hybrid sankey diagrams: An industrial case study

Technical debt (TD) is a challenge for companies who develop software on which their critical operations depend. To properly manage TD, it is necessary to make it visible to the different stakeholders involved to support informed decisions. Objective: To validate a TD visualization approach based on hybrid Sankey diagrams that makes the TD visible by showing (a) technical and business aspects, and (b) the flow of value and TD impacts. This approach regards visualizations as boundary objects. Method: We performed a multi-case study in a large multi-industry state-owned company. The objective was to validate the effectiveness of such visualizations and to explore their possible uses in TD management. We first used a retrospective case study on a TD decision-making scenario and, later, visualization usage scenarios using focus groups to evaluate its usefulness. Results: The results suggest that the proposed approach: (a) provides a structured process for systematic TD visualization to help the decision-making process; (b) enables the communication at knowledge boundaries between stakeholders to make informed decisions; (c) uses flow representations that are important for assessing the impact in multiple functional areas; and (d) enables documentation and reuse. Conclusion: The study results suggest that TD decision-making events can benefit from using our TD visualizations based on hybrid Sankey diagrams as boundary objects to portray the impact of TD in business, services, and technical aspects.UCR::Vicerrectoría de Docencia::Ingeniería::Facultad de Ingeniería::Escuela de Ciencias de la Computación e InformáticaUCR::Vicerrectoría de Investigación::Sistema de Estudios de Posgrado::IngenieríaUCR::Vicerrectoría de Investigación::Unidades de Investigación::Ingeniería::Centro de Investigaciones en Tecnologías de Información y Comunicación (CITIC

Technical debt payment and prevention through the lenses of software architects

Context: Architectural decisions are considered one of the most common sources of technical debt (TD). Thus, it is necessary to understand how TD is perceived by software architects, particularly, the practices supporting the elimination of debt items from projects, and the practices used to reduce the chances of TD occurrence. Objective: This paper investigates the most commonly used practices to pay off TD and to prevent debt occurrence in software projects from the architect’s point of view. Method: We used the available data from InsighTD, which is a globally distributed family of industrial surveys on the causes, effects, and management of TD. We analyze responses from a corpus of 72 software architects from Brazil, Chile, Colombia, and the United States. Results: Results showed that refactoring (30.2%) was the main practice related to TD payment, followed by design improvements (14.0%). Refactoring, design improvements, and test improvements are the most cited payment practices among cases of code, design and test debt. Concerning the TD preventive practices, we find that having a well-defined architecture and design is the most cited practice (13.6%), followed by having a well-defined scope and requirements. This last practice is the most cited one for expert software architects. Finally, when comparing preventive practices among the three major roles derived from the survey (software architects, engineer roles, and management roles), we found that none of the roles shared the most cited practice, meaning that each role had its worries and focus on different strategies to reduce TD’s presence in the software. Conclusion: The lists of TD payment and prevention practices can guide software teams by having a catalog of practices to keep debt controlled or reduced

Identification and management of technical debt: A systematic mapping study update

Technical debt is a concept used to describe the lack of good practices during software development, leading to several problems and costs. Identification and management strategies can help reduce these difficulties. In a previous study, Alves et al. (2016) analyzed the research landscape of such strategies from 2010 to 2014. This paper replicates and updates their study to explore the evolution of technical debt identification and management research landscape over a decade, including literature from 2010 until 2022. We analyzed 117 papers from the ACM Digital Library, IEEE Xplore, Science Direct, and Springer Link. Newly suggested strategies include automatically identifying admitted debt in comments, commits, and source code. Between 2015 and 2022, more empirical evaluations have been performed, and the general research focus has changed to a more holistic approach. Therefore, the research area evolved and reached a new level of maturity compared to previous results from Alves et al. (2016). Not only are code aspects considered for technical debt, but other aspects have also been investigated (e.g., models for the development process).Universidad de Costa Rica/[834-B4-412]/UCR/Costa RicaUCR::Vicerrectoría de Docencia::Ingeniería::Facultad de Ingeniería::Escuela de Ciencias de la Computación e InformáticaUCR::Vicerrectoría de Investigación::Sistema de Estudios de Posgrado::Ingenierí

La realidad Virtual en la enseñanza artística universitaria : pedagogías de nuevo discursos

Nos hallamos sumergidos en una nueva revolución digital que se ha ido desarrollando de forma vertiginosa en la última década y que nos ha hecho pasar de una tecnología 2.0 a unos sistemas de herramientas basadas en la web 3.0, donde la búsqueda de la máxima interacción e inmersión son dos pilares principales en su desarrollo (Caballero, 2011, p 48). El uso de las TIC se ha vuelto protagonista en nuestra vida diari