Management of Technical Debt for Reformation of Legacy Software Systems
Raivonen, Timo (2019-12-18)
Management of Technical Debt for Reformation of Legacy Software Systems
(18.12.2019)
Julkaisu on tekijänoikeussäännösten alainen. Teosta voi lukea ja tulostaa henkilökohtaista käyttöä varten. Käyttö kaupallisiin tarkoituksiin on kielletty.
suljettu
Julkaisun pysyvä osoite on:
https://urn.fi/URN:NBN:fi-fe2019122049252
https://urn.fi/URN:NBN:fi-fe2019122049252
Tiivistelmä
Technical Debt (TD) metaphor is a way to contextualize unrefined code in a software
and how that ”debt” can have interest attached to it. This interest reflects the possibility
of increase of more problems if the debt is not paid before the interest is realized. The
metaphor of ”debt” was coined in 1992 by Ward Cunningham but it was started to be
used in its current form after 2007 when Martin Fowler introduced a way to categorize it.
While the term has started to gain more use, it is still not defined as something specific,
but rather the term can be used to refer to things that do not represent bad or unrefined
code.
This thesis describes the TD and aims to define it in a way that would be usable as a
tool for management of reformation for legacy software systems. And more specifically,
if it is fitting to be used for a project that was reformed from a legacy software system
and then found lacking in usability, reliability and maintainability. The project and its
functionality is described alongside with the problems of it. As the TD is only used
as a tool for management, the reformation of the software is a separate issue. For this
issue, multiple good practices are described to handle it and to highlight possible forms
of unrefined code.
The TD is used to present a way how the unrefined code could be identified and managed
in the target project. The found TD is then used as basis of redesign and reformation of the
target project in a way to that the desired features are achieved. To provide more usability
for the TD, a more generalized guide of handling legacy software systems through the use
of it is also presented.
As a conclusion of this thesis the TD can be seen as a usable tool for management of
reformation for legacy software systems. While the TD can be used as a management
tool, it does not offer a solution for the reformation, but it can be used as a basis to then
guide the already known best practices of legacy software system reformation.
and how that ”debt” can have interest attached to it. This interest reflects the possibility
of increase of more problems if the debt is not paid before the interest is realized. The
metaphor of ”debt” was coined in 1992 by Ward Cunningham but it was started to be
used in its current form after 2007 when Martin Fowler introduced a way to categorize it.
While the term has started to gain more use, it is still not defined as something specific,
but rather the term can be used to refer to things that do not represent bad or unrefined
code.
This thesis describes the TD and aims to define it in a way that would be usable as a
tool for management of reformation for legacy software systems. And more specifically,
if it is fitting to be used for a project that was reformed from a legacy software system
and then found lacking in usability, reliability and maintainability. The project and its
functionality is described alongside with the problems of it. As the TD is only used
as a tool for management, the reformation of the software is a separate issue. For this
issue, multiple good practices are described to handle it and to highlight possible forms
of unrefined code.
The TD is used to present a way how the unrefined code could be identified and managed
in the target project. The found TD is then used as basis of redesign and reformation of the
target project in a way to that the desired features are achieved. To provide more usability
for the TD, a more generalized guide of handling legacy software systems through the use
of it is also presented.
As a conclusion of this thesis the TD can be seen as a usable tool for management of
reformation for legacy software systems. While the TD can be used as a management
tool, it does not offer a solution for the reformation, but it can be used as a basis to then
guide the already known best practices of legacy software system reformation.