35,601 research outputs found

    Technical Debt Prioritization: State of the Art. A Systematic Literature Review

    Get PDF
    Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review among 384 unique papers published until 2018, following a consolidated methodology applied in Software Engineering. We included 38 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and optimizing on different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We report an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that technical Debt prioritization research is preliminary and there is no consensus on what are the important factors and how to measure them. Consequently, we cannot consider current research conclusive and in this paper, we outline different directions for necessary future investigations

    An analysis of techniques and methods for technical debt management: a reflection from the architecture perspective

    Full text link
    Technical debt is a metaphor referring to the consequences of weak software development. Managing technical debt is necessary in order to keep it under control, and several techniques have been developed with the goal of accomplishing this. However, available techniques have grown disperse and managers lack guidance. This paper covers this gap by providing a systematic mapping of available techniques and methods for technical debt management, covering architectural debt, and identifying existing gaps that prevent to manage technical debt efficiently

    Human Dimensions of the Ecosystem Approach to Fisheries: An Overview of Context, Concepts, Tools and Methods

    Get PDF
    This document aims to provide a better understanding of the role of the economic, institutional and sociocultural components within the ecosystem approach to fisheries (EAF) process and to examine some potential methods and approaches that may facilitate the adoption of EAF management. It explores both the human context for the ecosystem approach to fisheries and the human dimensions involved in implementing the EAF. For the former, the report provides background material essential to understand prior to embarking on EAF initiatives, including an understanding of key concepts and issues, of the valuation of aquatic ecosystems socially, culturally and economically, and of the many policy, legal, institutional, social and economic considerations relevant to the EAF. With respect to facilitating EAF implementation, the report deals with a series of specific aspects: (1) determining the boundaries, scale and scope of the EAF; (2) assessing the various benefits and costs involved, seen from social, economic, ecological and management perspectives; (3) utilizing appropriate decision-making tools in EAF; (4) creating and/or adopting internal incentives and institutional arrangements to promote, facilitate and fund the adoption of EAF management; and (5) finding suitable external (non-fisheries) approaches for financing EAF implementation

    Technical Debt Prioritization: State of the Art. A Systematic Literature Review

    Get PDF
    Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring of Technical Debt should be prioritized with respect to developing features or fixing bugs.Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review of 557 unique papers published until 2019, following a consolidated methodology applied in software engineering. We included 44 primary studies.Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and proposing optimization regarding different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We present an impact map of such factors. However, there is a lack of empirical and validated set of tools.Conclusion. We observed that Technical Debt prioritization research is preliminary and there is no consensus on what the important factors are and how to measure them. Consequently, we cannot consider current research\ua0conclusive. In this paper, we therefore outline different directions for necessary future investigations

    Road to Microservices

    Get PDF
    This document intends to elucidate the complexity of microservices decomposition and this its inherent process of implementation. Developments in technology and design, achieving higher performance, reliability, or lowering costs are valid reasons to consider controlling the product’s quality by guaranteeing its conformance with established characteristics and standards. Control is made possible by adding quality control, inspection routines, and trend analysis to a manufacturing process. These techniques are established in the Quality field academically and business-wise. Repeat Part Management (RPM) is software that allows users to apply these techniques efficiently and has brought value to the company. However, RPM has been growing, and issues have emerged due to customer needs - accumulated technical debt. These ever-growing modifications are common through different business areas, and architectures’ research evolution has accompanied them. This demand for highly modifiable, rapid development, and independent systems has resulted in the adoption of microservices. There is a concern for existing systems for decomposition due to the characteristics of microservices, which encourages approach/technique research. This architecture promotes legacy system analysis to map current functionalities and dependencies between components. Furthermore, critical concepts in a microservices architecture are researched and implemented in a new system that encompasses Repeat Part Management’s functionalities. This thesis explores the microservices’ architecture evolution with an already defined mature domain in quality assessment.Este documento pretende especificar a complexidade do processo de decomposição em microsserviços e do seu processo de implementação. Avanços na tecnologia e design, alcançar melhor performance, ou a confiabilidade do produto, ou diminuir custos são justificações válidas para considerar controlar a qualidade do produto e, inerentemente, garantir a sua conformidade com as características previamente definidas e com padrões da indústria. É possível garantir controlo sob os produtos ao acrescentar, ao processo produtivo, métodos de controlo de qualidade, rotinas de inspeção e análise de tendências (de desvio). Estas técnicas estão bem estabelecidas academicamente e, de um ponto de vista do mercado, na área da Qualidade e garantia da qualidade. O Repeat Part Management (RPM) é um software que permite aos seus utilizadores a utilização eficiente destas técnicas de qualidade, o que resulta numa adição de valor para a empresa. Porém, devido às crescentes necessidades dos clientes, alguns problemas têm sido identificados - relacionados com o conceito de acumulação de technical debt. Esta crescente necessidade de alteração é comum em diversas áreas de negócio, e a investigação de soluções arquiteturais tem acompanhado esta pesquisa. Esta solução arquitetura pode ser caracterizada pela facilidade de sistemas facilmente modificáveis, pelo rápido desenvolvimento e implementação, e pela independência dos serviços decompostos. Aquando de uma migração para microsserviços num sistema maturo, existe uma maior preocupação na decomposição da aplicação e definição dos serviços dada a característica dos microsserviços, o que incentiva a uma pesquisa detalhada sobre as técnicas de decomposição. Pela mesma razão, esta arquitetura incentiva ao mapeamento e documentação das dependências entre serviços e componentes e o estudo da aplicação legacy. Para além disto, estes conceitos, e a sua implementação devem ser planeados, justificados e documentados, o que explica a complexidade do processo de migração e implementação, que deve ter em consideração as funcionalidades existentes no Repeat Part Management. Dessa forma, esta tese explora a implementação desta arquitetura numa aplicação matura na área de Garantia de Qualidade

    Technical Debt in Software Development : Examining Premises and Overcoming Implementation for Efficient Management

    Get PDF
    Software development is a unique field of engineering: all software constructs retain their modifiability — arguably, at least — until client release, no single project stakeholder has exhaustive knowledge about the project, and even this portion of the knowledge is generally acquired only at project completion. These characteristics imply that the field of software development is subject to design decisions that are known to be sub-optimal—either deliberately emphasizing interests of particular stakeholders or indeliberately harming the project due to lack of exhaustive knowledge. Technical debt is a concept that accounts for these decisions and their effects. The concept’s intention is to capture, track, and manage the decisions and their products: the affected software constructs. Reviewing the previous, it is vital for software development projects to acknowledge technical debt both as an enabler and as a hindrance. This thesis looks into facilitating efficient technical debt management for varying software development projects. In the thesis, examination of technical debt’s role in software development produces the premises on to which a management implementation approach is introduced. The thesis begins with a revision of motivations. Basing on prior research in the fields of technical debt management and software engineering in general, the five motivations establish the premises for technical debt in software development. These include notions of subjectivity in technical debt estimation, update frequency demands posed on technical debt information, and technical debt’s polymorphism. Three research questions are derived from the motivations. They ask for tooling support for technical debt management, capturing and modelling technical debt propagation, and characterizing software development environments and their technical debt instances. The questions imply consecutive completion as the first pursued tool would benefit from—possibly automatically assessable—propagation models, and finally the tool’s introduction to software development organizations could be assisted by tailoring it based on the software development environment and the technical debt instance characterizations. The thesis has seven included publications. In introducing them, the thesis maps their backgrounds to the motivations and their outcomes to the research questions. Amongst the outcomes are the DebtFlag tool for technical debt management, the procedures for retrospectively capturing technical debt from software repositories, a procedure for technical debt propagation model creation from these retrospectives, and a multi-national survey characterizing software development environments and their technical debt instances. The thesis concludes that the tooling support, the technical debt propagation modelling, and the software environment and technical debt instance characterization describe an implementation approach to further efficient technical debt management. Simultaneously, future work is implied as all previously described efforts need to be continued and extended. Challenges also remain in the introduced approach. An example of this is the combinatorial explosion of technology-development-context-combinations that technical debt propagation modelling needs to consider. All combinations have to be managed if exhaustive modelling is desired. There is, however, a great deal of motivation to pursue these efforts when one re-notes that technical debt is a permanent component of software development that, when correctly managed, is a development efficiency mechanism comparable to a financial loan investment.Ohjelmistokehitys on uniikki tekniikan ala: kaikki ohjelmistorakenteet säilyttävät muokattavuutensa — otaksuttavasti ainakin — asiakasjulkaisuun asti. Yhdenkään projektiosakkaan tietämys ei kata koko projektia ja merkittävä osa tästäkin tiedosta karttuu vasta projektin suorittamisen aikana. Nämä ominaisuudet antavat ymmärtää, että ohjelmistokehitysala on sellaisten suunnitelupäätösten kohde, joiden tiedetään olevan epätäydellisiä—joko tarkoituksella tiettyjen projektiosakkaiden intressejä painottavia tai tahattomasti projektia vahingoittavia puutteelliseen tietoon perustuvia. Tekninen velka on konsepti, joka huomioi nämä päätökset sekä niiden vaikutukset. Konseptin tarkoitus on havaita, seurata ja hallita näitä päätöksiä sekä tuloksena syntyviä teknisen velan vaikutuksen alla olevia ohjelmistorakenteita. Edellisen kuvauksen valossa ohjelmistokehitysprojekteille on erityisen tärkeää huomioida tekninen velka sekä mahdollistajana että hidasteena. Tämän vuoksi kyseinen väitöskirja perehtyy tehokkaan teknisen velan hallinnan fasilitointiin moninaisille ohjelmistokehitysprojekteille. Väitöskirjassa tarkastellaan teknisen velan roolia osana ohjelmistokehitystä. Tarkastelu tuottaa joukon premissejä, joihin perustuen esitellään lähestymistapa teknisen velan hallinnan toteuttamiselle. Viisi väitöskirjan alussa esitettyä motivaatiota kiinnittävät ne premissit,joille ratkaisu esitetään. Motivaatiot rakennetaan olemassa olevaan teknisen velan sekä ohjelmistotekniikan tutkimustietoon perustuen. Näihin lukeutuvat muun muassa subjektiivisuus teknisen velan estimoinnissa, teknisen velan informaatiolle nähdyt päivitystaajuusvaatimukset sekä teknisen velan polymorfismi. Havainnoista johdetaan kolme tutkimuskysymystä. Ne tavoittelevat työkalutukea teknisen velan hallinnalle, velan propagoitumisen havainnointia sekä mallinnusta kuin myös ohjelmistotuotantoympäristöjen ja niiden velka instanssien kuvaamista. Tutkimuskysymykset implikoivat peräkkäistä suoritusta: tavoiteltu työkalu hyötyy—mahdollisesti automaattisesti arvoitavista—teknisen velan propagaatiomalleista. Valmiin työkalun käyttöönottoa voidaan taas edistää jos kuvaukset kehitysympäristöistä sekä niiden velkainstansseista ovat käytettävissä työkalun räätälöintiin. Väitöskirjaaan sisältyy seitsemän julkaisua. Väitöskirja esittelee ne kiinnittämällä julkaisujen taustatyön aikaisemmin mainittuihin motivaatioihin sekä niiden tulokset edellisiin tutkimuskysymyksiin. Tuloksista huomioidaan esimerkiksi DebtFlag-työkalu teknisen velan hallintaan, retrospektiivinen prosessi teknisen velan kartoittamiselle versionhallintajärjestelmistä, prosessi teknisen velan mallien rakentamiselle näistä kartoituksista ja monikansallinen kyselytutkimus ohjelmistokehitysympäristöjen sekä näiden teknisen velan instanssien luonnehtimiseksi. Väitöskirjan yhteenvetona huomioidaan, että teknisen velan hallinnan työkalutuki, teknisen velan propagaatiomallinnus ja ohjelmistokehitysympäristöjen sekä niiden teknisen velan instanssien luonnehdinta muodostavat toteutustavan, jolla teknisen velan tehokasta hallintaa voidaan kehittää. Samalla implikoidaan jatkotoimia, sillä kaikkia edellä kuvattuja työn osia tulee jatkaa ja laajentaa. Toteutustavalle nähdään myös haasteita. Eräs näistä on kombinatorinen räjähdys teknologia- ja kehityskontekstikombinaatioille. Kaikki kombinaatiot tulee huomioida mikäli teknisen velan propagaatiomallinnuksesta halutaan kattavaa. Motivaatio väitöskirjassa esitetyn työn jatkamiselle on huomattavaa ja sitä kasvattaa entuudestaan edellä tehty huomio siitä, että tekninen velka on pysyvä komponentti ohjelmistokehityksessä, joka oikein hallittuna on kehitystehokkuutta edistävänä komponenttina verrattavissa finanssialan lainainvestointiin.Siirretty Doriast

    Architectural technical debt:A grounded theory

    Get PDF
    corecore