1,749 research outputs found
ScrumBut as an Indicator of Process Debt
Peer reviewe
Technical Debt Decision-Making Framework
Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items
Technical Debt Decision-Making Framework
Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items
Correspondence of OOP Refactoring Techniques in PL\SQL Environment: A Case Study of Agile Project Code
scrum is one of the most popular agile approaches for developing software, which has code quality challenges that affect software functionality, maintainability, reliability, usability, efficiency, and portability. However, many techniques are applied to enhance code quality by analyzing and reviewing the code using code conventions, standards, and refactoring. In the Scrum development framework, handling code quality issues requires focusing on the practices that cause such issues (i.e., short testing volume). Therefore, this study aims to investigate how refactoring affects scrum source code quality and code maintainability. This study followed an experimental approach, including a case study for a large and complex Oracle PL/SQL software program through its development phase. The source code of the chosen sprint is analyzed to evaluate its quality and identify the probability of code smell existence. Nine refactoring techniques are applied to the collected data to identify code smells for the chosen PL/SQL software. The study findings show that choosing a suitable refactoring technique positively affects the maintainability of sprint code
Discovering and Assessing Enterprise Architecture Debts
The term Enterprise Architecture (EA) Debts has been coined to grasp the difference between the actual state of the EA and its hypothetical, optimal state. So far, different methods have been proposed to identify such EA Debts in organizations. However, these methods either are based on the transfer of known concepts from other domains to EA or are time and resource intensive. To overcome these shortcomings, we propose an approach that uses an interview format to identify EA Debts in enterprises and a method that allows a qualitative assessment of identified EA Debts. The proposed approach is supported by the designed framework that consists of an interview format and a process for determining thresholds of certain EA Smells
Software Architecture in Practice: Challenges and Opportunities
Software architecture has been an active research field for nearly four
decades, in which previous studies make significant progress such as creating
methods and techniques and building tools to support software architecture
practice. Despite past efforts, we have little understanding of how
practitioners perform software architecture related activities, and what
challenges they face. Through interviews with 32 practitioners from 21
organizations across three continents, we identified challenges that
practitioners face in software architecture practice during software
development and maintenance. We reported on common software architecture
activities at software requirements, design, construction and testing, and
maintenance stages, as well as corresponding challenges. Our study uncovers
that most of these challenges center around management, documentation, tooling
and process, and collects recommendations to address these challenges.Comment: Preprint of Full Research Paper, the 31st ACM Joint European Software
Engineering Conference and Symposium on the Foundations of Software
Engineering (ESEC/FSE '23
A heuristic-based approach to code-smell detection
Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache
Architectural design decisions that incur technical debt — An industrial case study
Context: During software development, some architectural design decisions incur technical debt, either deliberately or inadvertently. These have serious impact on the quality of a software system, and can cost significant time and effort to be changed. While current research efforts have explored general concepts of architectural design decisions and technical debt separately, debt-incurring architectural design decisions have not been specifically explored in practice. Objective: In this case study, we explore debt-incurring architectural design decisions (DADDs) in practice. Specifically, we explore the main types of DADDs, why and how they are incurred in a software system, and how practitioners deal with these types of design decisions. Method: We performed interviews and a focus group with practitioners working in embedded and enterprise software companies, discussing their concrete experience with such architectural design decisions. Results: We provide the following contributions: 1) A categorization for the types of DADDs, which extend a current ontology on architectural design decisions. 2) A process on how deliberate DADDs are made in practice. 3) A conceptual model which shows the relationships between the causes and triggers of inadvertent DADDs. 4) The main factors that influence the way of dealing with DADDs. Conclusion: The results can support the development of new approaches and tools for Architecture Technical Debt management from the perspective of Design Decisions. Moreover, they support future research to capture architecture knowledge related to DADDs
- …