China
Africa
Explore chapters and articles related to this topic
Post-Release Support (PRSA1 5)
Published in James F. Ransome, Anmol, Mark S. Merkow, Practical Core Software Security, 2023
James F. Ransome, Anmol, Mark S. Merkow
Most important to this discussion is that the technical debt in legacy software may contain security vulnerabilities. Over the course of a project, it is tempting for an organization to become lax regarding software quality and security. Most commonly, this results when teams are expected to complete too much functionality in a given time frame, or quality and security are simply not considered high-priority characteristics for the software.14 In these situations, there may be security vulnerabilities in the legacy code that exist as a result of the technical debt. From a software product security perspective, the key task when looking at legacy code is to balance the ROI of addressing the security technical debt against the risk of leaving it in. Two primary decisions must be considered: How much new code presumably scrubbed by the SDL are you writing to replace the existing old code? At what rate will the volume of old code be replaced, and what security risk is there for whatever remains?Reviewing old code is a slow and tedious process. Serious ROI decisions must be made. You must reserve resources for this work to reduce the technical security debt for current resources. The level of effort for this work will depend on whether the SDL existed at the time the code was developed. If there was no SDL at the time the legacy code was being developed, the level of effort will be high.
Requirements Specification and Agile Methodologies
Published in Phillip A. Laplante, Mohamad H. Kassab, Requirements Engineering for Software and Systems, 2022
Phillip A. Laplante, Mohamad H. Kassab
Technical debt is a metaphor referring to the eventual consequences of poor system architecture and system development within a codebase (Cunningham 1992). The debt can be thought of as work that needs to be done before a particular job can be considered complete. In agile development, the technical debt can be thought of as the amount of work that is left to be done from previous iterations (sprints), when a new iteration starts. The buildup of technical debt is the main reason for projects to miss deadlines. As with monetary debt, the cost of never paying down a technical debt may accumulate an “interest” making it harder to implement changes. The debt can be paid off by simply completing the uncompleted work.
Outlook and Future Directions
Published in Ivan Mistrik, Matthias Galster, Bruce R. Maxim, Software Engineering for Variability Intensive Systems, 2019
Bruce Maxim, Matthias Galster, Ivan Mistrik
Technical debt is a software engineering concept used to describe the implied cost of additional rework caused from having chosen an easy solution now rather than looking for a better approach that would take longer. The cause of technical debt is often attributed to scheduling pressures. Using iterative or agile software development processes does not allow developers to ignore technical debt. Working with variability-intensive systems such as product line software can cause technical debt to grow even more rapidly unless time is taken for proper software design and planning for component reuse.
Do we need to pay technical debt in blockchain software systems?
Published in Connection Science, 2022
Yubin Qu, Tie Bao, Xiang Chen, Long Li, Xianzhen Dou, Meng Yuan, Hongmei Wang
Approach. To present a detailed information of technical debt, we have counted technical debt in different projects according to the result of Section 4. The source code comments have been extracted and cleaned up; next, we count technical debt from another perspective. We counted the technical debt in different projects at the granularity of files and analysed the percentage of technical debt in different files. Data description from the file level is used to demonstrate the approximate distribution of technical debt. This is because these six open-source blockchain software projects use multiple programming languages, including C++, Python, go, Rust, Solidity, etc. Then we sum the code comments with SATD and resource debt as comments as technical debt, which are shown in Table 4 with “#TD”.
Technical debt as an indicator of software security risk: a machine learning approach for software development enterprises
Published in Enterprise Information Systems, 2022
Miltiadis Siavvas, Dimitrios Tsoukalas, Marija Jankovic, Dionysios Kehagias, Dimitrios Tzovaras
One interesting software-related factor that may indicate software security risks is Technical Debt (TD) (Cunningham 1993). TD, a notion inspired by the financial debt, is utilised as a quality metric. More specifically, it is used to quantify long-term software quality problems that are caused by quality compromises that provide short-term benefits. In fact, it is used to quantify the effort that is required for fixing design and code quality issues (i.e. code smells and violations of coding rules and best practices), which are introduced by the developers due to sacrifices they make to the quality of the code they produce usually in an attempt to meet strict production deadlines. As a result, an increased value of TD indicates that the corresponding software product contains an increased number of quality issues, which, in turn, indicates poor overall quality.