Managing Technical Debt in Django Web Applications / Hantering utav teknisk skuld i Django webbapplikationerClasson, Per January 2016 (has links)
Technical debt is a metaphor that refers to the consequences of suboptimal software development. Developers will have to pay interest on this debt, in terms of costs of maintenance. The term helps developers communicate the importance of software quality. This thesis has studied technical debt in the context of Django web applications. In a survey conducted, the main causes of technical debt in Django applications were found to be architectural issues and lack of testing. This is in line with other studies of causes of technical debt. Tools and practices used in Django development were evaluated. From this evaluation several guidelines were formulated on how to best manage and limit technical debt. The results suggest that static code analyzers should be used to maintain code standards. Furthermore, the evaluation show that log aggregation tools like Sentry are helpful. Application monitoring should be used if there are performance issues, deprecation patterns can be used in refactorizations and the identification and removal of dead code is probably unnecessary. Finally, pre-commit tools help in preventing technical debt. / Teknisk skuld är en metafor som beskriver konsekvenserna utav suboptimal mjukvaruutveckling. Utvecklare måste betala ränta på denna skuld, i form utav kostnader för underhåll. Termen hjälper utvecklare att kommunicera vikten utav programvarukvalitet. Denna rapport har studerat teknisk skuld i kontexten utav Django webbapplikationer. En enkätundersökning gjordes och de främsta orsakerna till teknisk skuld i Django applikationer visade sig vara arkitektoniska problem och brist utav testning. Detta ligger i linje med andra studier utav orsakerna av teknisk skuld. Verktyg och metoder som används i Django utveckling utvärderades. Från denna utvärdering flera riktlinjer formulerades om hur man bäst hanterar och begränsar teknisk skuld. Resultaten visar på att statisk programanalys bör användas för att upprätthålla kod standarder. Dessutom visar utvärderingen att log aggregerings verktyg som Sentry är användbara. Applikations övervakning bör användas om det finns prestandaproblem, deprecation patterns kan användas i refaktoriseringar och identifiering av död kod är förmodligen onödigt. Slutligen visar sig pre-commit verktyg vara hjälpsamma i att förebygga teknisk skuld.
Technical debt management in the context of agile methods in software development / Gerenciamento de dívida técnica no Ccontexto de desenvolvimento de software ágil.Graziela Simone Tonin 23 March 2018 (has links)
The technical debt field covers an critical problem of software engineering, and this is one of the reasons why this field has received significant attention in recent years. The technical debt metaphor helps developers to think about, and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. It was created by Cunningham to improve the quality of software delivery. Many times the technical debt items are unknown, unmonitored and therefore not managed, thus resulting in high maintenance costs throughout the software life-cycle. We conducted an empirical study in an academic environment, during two offerings of a laboratory course on Extreme Programming (XP Lab) at University of São Paulo and in two Brazilian Software Companies (Company A and B). We analyzed thirteen teams, nine in the Academy and four in the Companies environment. The teams had a comprehensive lecture about technical debt and several ways to identify and manage technical debt were presented. We monitored the teams, performed interviews, did close observations and collected feedback. The obtained results show that the awareness of technical debt influences team behavior. Team members report thinking and discussing more on software quality after becoming aware of technical debt in their projects. We identified some impacts on the teams and the projects after having considered technical debt. A conceptual model for technical debt management was created including ways of how identifying, monitoring, categorizing, measuring, prioritizing, and paying off the technical debt. A few approaches and techniques for the technical debt management, identification, monitoring, measure, and payment are also suggested. / A metáfora de dívida técnica engloba um importante problema da engenharia de software e essa é uma das razões pelas quais este campo tem recebido uma grande atenção nos últimos anos. Essa metáfora auxilia os desenvolvedores de software a refletirem sobre e a monitorarem a qualidade de software. A metáfora se refere a falhas no software (geralmente causadas por atalhos para economizar tempo) que podem afetar a futura manutenção e evolução do mesmo. A metáfora foi criada por Cunningham com o objetivo de melhorar a qualidade das entregas de software. Muitas vezes as dívidas técnicas não são conhecidas, monitoradas e nem geridas, resultando em um alto custo de manutenção ao longo do ciclo de vida do software. Logo, conduziu-se um estudo empírico na academia, durante duas ofertas da disciplina de Programação Extrema (XP Lab) na Universidade de São Paulo e em duas empresas Brasileiras de desenvolvimento de software (Empresa A e B). Foram analisados treze times, sendo nove na academia e quatro nas empresas. Os times tiveram uma apresentação sobre dívida técnica e foram apresentadas algumas sugestões de abordagens para gerir dívida técnica. Monitorou-se os times, foram realizadas entrevistas, observações fechadas e informações foram coletadas. Os resultados mostraram que considerar dívida técnica influenciou o comportamento dos times. Eles reportaram que após considerar dívida técnica passaram a refletir e discutir mais a qualidade do software. Identificou-se alguns impactos nos times e nos projetos depois de considerarem dívida técnica. Um modelo conceitual para gestão de dívida técnica foi criado, incluindo formas, técnicas e abordagens de como identificar, monitorar, categorizar, medir, priorizar e pagar os itens de dívida técnica.
The importance of software code quality is increasing rapidly. With more code being written every day, its maintenance and support are becoming harder and more expensive. New automatic code review tools are developed to reach quality goals. One of these tools is SonarQube. However, people keep their leading role in the development process. Sometimes they sacrifice quality in order to speed up the development. This is called Technical Debt. In some particular cases, this process can be admitted by the developer. This is called Self-Admitted Technical Debt (SATD). Code quality can also be measured by such static code analysis tools as SonarQube. On this occasion, different issues can be detected. The purpose of this study is to find a connection between code quality issues, found by SonarQube and those marked as SATD. The research questions include: 1) Is there a connection between the size of the project and the SATD percentage? 2) Which types of issues are the most widespread in the code, marked by SATD? 3) Did the introduction of SATD influence the bug fixing time? As a result of research, a certain percentage of SATD was found. It is between 0%–20.83%. No connection between the size of the project and the percentage of SATD was found. There are certain issues that seem to relate to the SATD, such as “Duplicated code”, “Unused method parameters should be removed”, “Cognitive Complexity of methods should not be too high”, etc. The introduction of SATD has a minor positive effect on bug fixing time. We hope that our findings can help to improve the code quality evaluation approaches and development policies
Context. There is a need for developers to write clean code and code that adheres to a high-quality standard. We need developers not to introduce technical debt and code smells to the code. From a business perspective, developers that introduce technical debt to the code will make the code more difficult to maintain, meaning that the cost for the project will increase. Objectives. The main objective of this study is to gain an understanding about the perception the developers have about clean code and how they use it in practice. There is not much information about how clean code is perceived by developers and applied in practice, and this thesis will extend the information about those two areas. It is an effort to understand developers' perception of clean code in practice and what they think about it. Realization (Method). To understand the state-of-the-art in the area of clean code, we first performed literature review using snowballing. To delve into developers' perception about clean code and how it is used in practice. We have developed and sent out a questionnaire survey to developers within companies and shared the survey via social networks. We ask if developers believe that clean code eases the process of reading, modifying, reusing, or maintaining code. We also investigate whether developers write clean code initially or refactor it to become clean code, or do none of these. Finally, we ask developers in practice what clean code principles they agree or disagree with. Asking this will help identify which clean code principles developers think are helpful and which are not. Results. The results from the investigation are that the developers strongly believe in clean code and that it affects reading, modifying, reusing, and maintaining code, positively. Also, developers do not write clean code initially but rather refactor unclean code to become clean code. Only a small portion of developers write clean code initially, and some do what suits the situation, while some do neither of these. The last result is that developers agree with most of the clean code principles listed in the questionnaire survey and that there are also some principles that they discard, but these fewer. Conclusions. From the first research question, we know that developers strongly believe that clean code makes the code more readable, understandable, modifiable, or reusable. Also, developers check that the code is readable using code reviews, peer reviews, or pull requests. Regarding the second research question, we know that developers mostly refactor unclean code rather than write clean code initially. The challenges are that to write clean code initially, a developer must have a solid understanding of the problem and obstacles in advance, and a developer will not always know what the code should look like in advance. The last research question showed that most developers agree with most of the clean code principles and that only a small portion of developers disagree with some of them. Static code analysis and code quality gates can ensure that developers follow these clean code practices and principles.
As software systems grow in size they will also grow in complexity. If the increased complexity is not managed the system will be increasingly difficult to maintain. The effect of unmaintainable software is even more distinct when using a agile development process. By increasing the maintainability of the system these problems will be dealt with and the system can be extended with sustained efficiency. This thesis will evaluate the development process of a modern, agile company in order to find changes that will promote increased maintainability. The result is an modified process that will increase the maintainability with the smallest possible overhead for the development organisation. The result is based on earlier studies of development technologies that have proven to increase the maintainability. The implementation of these technologies are adjusted to fit the development team, and some of the technologies that are not suitable for the team are rejected.
Lindh, Melenie, Magnell, Rebecca
The development of Information Technology is, according to the Swedish Government, the most important area of development. The costs of IT in governmental agencies are somewhere in between 20 to 25 billion SEK, paid by taxpayers and one of the largest cost items in the Swedish governments resources. Despite this, every third Swedish governmental agency lacks an IT-strategy and is unable to meet needs for flexibility and control. The study aims to reveal barriers that prevent an active application lifecycle management (ALM) at Swedish governmental agencies and to answer the question: “How do Swedish authorities handle their proprietary applications from a lifecycle perspective; financially and technically?” The case study will be conducted at the Social Insurance Agency (SIA). The SIA distributed, in 2010, about 6 % of the Swedish GDP and is mainly funded by grants and loans from the Swedish National Debt Office. The survey will be studied from a management accounting and ALM perspective. Management accounting is the actions within organizations to achieve financial goals. ALM is the lifecycle of an application that consists of the phases; requirements specification, development, testing, deployment and maintenance. The study will also investigate the technical debt at the governmental agencies. Technical debt refers to the work which has to be completed before an application can be considered finished. The survey is a qualitative study based on interviews with an exploratory purpose. The results are generalised to reflect a greater part of the Swedish authorities and showed that Swedish governmental agencies have inadequate handling of their proprietary applications and that each application is financially linked to one or more projects simultaneously. The models made are to facilitate the understanding of the different stages of ALM in synergy with the management accounting. Theoretically, the Maintenance phase allocates approximately 90 % of the total costs, whereas in governmental agenises it stands for about 20 %. Theoretically 10 % of the total costs are allocated to the Development phase, whereas in governmental agencies the corresponding amount is 80 %. A consequence of this is increased technical debt. The technical debt at Swedish authorities is often funded with loans, which is not allowed according to the Swedish National Debt Office. The SIA exceed budgets without asking for increased funds and according to the Swedish Audit Office, so does also 1/3 of the Swedish governmental agencies, meaning that they must handle the financial complications internally by moving funds amongst different departments and projects, also spending money meant for development on maintenance. Future studies can be made as investigations on how management accounting and ALM can be implemented on a safe and effective manner in a governmental agency.
Hansson, Malin, Hognesius, Maria
It is arguably an important matter to track and eliminate poor quality. One way of doing this within software development is by applying the technical debt metaphor and using it as a basis when estimating the quality level. There was interest expressed in investigating whether this metaphor could be extended to the development of non-software products and use it as a starting point for developing features in a PLM (product lifecycle management) system able to track and help monitor technical debt throughout the lifecycle of a product. Thus, a case study based on a literature review and interviews analysed qualitatively were conducted. The result consists of the knowledge that similar notions as found in the technical debt research could successfully be applied to other development processes and phenomena as well, a framework consisting of types of technical debt and a “sketch” for how to measure it, and that in a technical debt-tracking feature it could be beneficial with functionality for implementing models for debt quantification, for allowing the organisation to set up rules, and for crawling through the product taxonomy in the PLM system, detecting deviances from aforementioned rules.
Gong, Zhixiong, Lyu, Feng
Context. Technical debt (TD) is a metaphor reflecting technical compromises that sacrifice long-term health of a software product to achieve short term benefit. TD is a strategy for the development team to obtain business value. TD can do both harm and good to a software based on the situation of TD accumulation. Therefore, it is important to manage TD in order to avoid the accumulated TD across the breaking point. In large-scale distributed projects, development teams located in different sites, technical debt management (TDM) becomes more complex and difficult compared with traditional collocated projects. In recent years, TD metaphor has attracted the attention from academics, but there are few studies in real settings and none in large-scale globally distributed projects. Objectives. In this study, we aim to explore the factors that have significant impact on TD and how practitioner manage TD in large-scale distributed projects. Methods. We conducted an exploratory case study to achieve the objectives. The data was collected through archival records and a semi-structured interview. For the archival data, hierarchical multiple regression was used to analyze the relationship between identified factors and TD. For interview data, we used qualitative content analysis method to get a deep understanding of TDM in this studied case. Results. Based on the results of archival data analysis, we identified three factors that show significant positive correlation with TD. These three factors were task complexity, global distance, and maturity, which were evaluated by the architect during the semi-structured interview. The architect also believed that these factors have strong relationships with TD. TDM in this case includes seven management activities: TD prevention, identification, measurement, documentation, communication, prioritization, and repayment. The tool used for TDM is an internally implemented tool called wiki page. We also summarize the roles involved and approaches used with respect to each TDM activity. Two identified TDM challenges in this case were TD measurement and prioritization. Conclusions. We conclude that 1) TDM in this case is not complete. Due to the lack of TD monitoring, the measurement of TD is static and lacks an efficient way to track the change of cost and benefit of unresolved TD over time. Therefore, it is difficult to find a proper time point to repay a TD. 2) The wiki page is not enough to support TDM, and some specific tools should be combined with wiki page to manage TD comprehensively. 3) TD measurement and prioritization should get more attention both from practitioners and academics to find a suitable way to solve such challenges in TDM. 4) Factors that make significant contribution to TD should be carefully considered, which increase the accuracy of TD prediction and improve the efficiency of TDM.
Avaliação de projeto de software em relação à dívida técnica / Software design evaluation in relation to technical debtSilva, Andrey Estevão da 11 September 2015 (has links)
Submitted by Cláudia Bueno (email@example.com) on 2015-12-04T17:46:01Z No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Approved for entry into archive by Luciana Ferreira (firstname.lastname@example.org) on 2015-12-07T11:12:37Z (GMT) No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Made available in DSpace on 2015-12-07T11:12:37Z (GMT). No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) Previous issue date: 2015-09-11 / The SoftwareTechnicalDebtaimstocalculatecostsfromthefailuretocomplywithqua- lity standardsinthedevelopmentprocess,suchaslackofdocumentation,baddevelop- ment practicesanddisobediencetospecificcodingrulesofaproject.Oneoftheconcerns of organizationsandsoftwareengineersistoensuresuchqualitystandards,however,the humane wayofdoingthiscontrolallowsmistakeswhichconsequentlycausesTechnical Debt, whichintheshorttermarenotaproblem,butinthelongruncandestroyentire softwarestructures.Basedonthisproblem,itwillbeproposedanapproachforcalcu- lating theDesignTechnicalDebtofapplicationsdevelopedinJava.Themethodsused for thispurposeinvolvedataminingofopensourcecoderepositories,defecttracking softwaredatabases,timecorrectionestimativeofdesignrulesviolationandarchitectural compliance check. / A estimativadeDívidaTécnicadeSoftwaretemcomoobjetivocalcularoscustosdonão- cumprimento depadrõesdequalidadenoprocessodedesenvolvimento,taiscomofaltade documentação, máspráticasdedesenvolvimentoedesobediênciaàsregrasdecodificação específicas deumprojeto.Umadaspreocupaçõesdeorganizaçõeseengenheirosde softwareégarantirtaispadrõesdequalidade,noentanto,aformahumanadefazereste controle permiteerrosque,consequentemente,ocasionamDívidaTécnica,queemcurto prazo nãosãoumproblema,masemlongoprazopodedestruirestruturasdesoftware inteiras. Combasenesteproblema,serápropostaumaabordagemparaocálculodaDívida Técnica deDesigndeaplicaçõesdesenvolvidasemJava.Osmétodosutilizadosparaeste fim envolvemamineraçãodedadosderepositóriosdecódigoaberto,bancosdedados de softwarederastreamentodedefeitos,estimativadotempodecorreçãodeviolaçãode regrasdedesigneverificaçãodeconformidadearquitetural.
In complex information flows where a lot of varied data is transmitted through many companies and divisions, incidents will occur. When Visma Spcs had an incident where invoices sent from Visma to Visma's customers were duplicated and the service meant to receive the transactions did not handle the duplicates properly. They decided that the receiver service was to be upgraded to prevent this incident from happening again, as well as fixing some other issues the service had had. Incidents like this one must be investigated and a solution must be implemented to decrease the likelihood that similar incidents will happen again. In this report, the reader will see examples on how this can be handled and the benefits of tackling technical debt, along with how much more complicated the solutions might get if the service is not allowed to be taken offline.
Page generated in 0.0466 seconds