View in EDS

Exploring Maintainability Index Variants for Software Maintainability Measurement in Object-Oriented Systems

Saved in:
Bibliographic Details
Title: Exploring Maintainability Index Variants for Software Maintainability Measurement in Object-Oriented Systems
Authors: Tjaša Heričko, Boštjan Šumak
Source: Applied Sciences, Vol 13, Iss 5, p 2972 (2023)
Publisher Information: MDPI AG
Publication Year: 2023
Collection: Directory of Open Access Journals: DOAJ Articles
Subject Terms: software maintenance, maintainability measurement, Maintainability Index, software metrics, object-oriented software, Java, Technology, Engineering (General). Civil engineering (General), TA1-2040, Biology (General), QH301-705.5, Physics, QC1-999, Chemistry, QD1-999
Description: During maintenance, software systems undergo continuous correction and enhancement activities due to emerging faults, changing environments, and evolving requirements, making this phase expensive and time-consuming, often exceeding the initial development costs. To understand and manage software under development and maintenance better, several maintainability measures have been proposed. The Maintainability Index is commonly used as a quantitative measure of the relative ease of software maintenance. There are several Index variants that differ in the factors affecting maintainability (e.g., code complexity, software size, documentation) and their given importance. To explore the variants and understand how they compare when evaluating software maintainability, an experiment was conducted with 45 Java-based object-oriented software systems. The results showed that the choice of the variant could influence the perception of maintainability. Although different variants presented different values when subjected to the same software, their values were strongly positively correlated and generally indicated similarly how maintainability evolved between releases and over the long term. Though, when focusing on fine-grained results posed by the Index, the variant selection had a larger impact. Based on their characteristics, behavior, and interrelationships, the variants were divided into two distinct clusters, i.e., variants that do not consider code comments in their calculation and those that do.
Document Type: article in journal/newspaper
Language: English
Relation: https://www.mdpi.com/2076-3417/13/5/2972; https://doaj.org/toc/2076-3417; https://doaj.org/article/d5d785d77ab0402882b5a6735e08a2b9
DOI: 10.3390/app13052972
Availability: https://doi.org/10.3390/app13052972
https://doaj.org/article/d5d785d77ab0402882b5a6735e08a2b9
Accession Number: edsbas.BBF64B09
Database: BASE
Description
Abstract:During maintenance, software systems undergo continuous correction and enhancement activities due to emerging faults, changing environments, and evolving requirements, making this phase expensive and time-consuming, often exceeding the initial development costs. To understand and manage software under development and maintenance better, several maintainability measures have been proposed. The Maintainability Index is commonly used as a quantitative measure of the relative ease of software maintenance. There are several Index variants that differ in the factors affecting maintainability (e.g., code complexity, software size, documentation) and their given importance. To explore the variants and understand how they compare when evaluating software maintainability, an experiment was conducted with 45 Java-based object-oriented software systems. The results showed that the choice of the variant could influence the perception of maintainability. Although different variants presented different values when subjected to the same software, their values were strongly positively correlated and generally indicated similarly how maintainability evolved between releases and over the long term. Though, when focusing on fine-grained results posed by the Index, the variant selection had a larger impact. Based on their characteristics, behavior, and interrelationships, the variants were divided into two distinct clusters, i.e., variants that do not consider code comments in their calculation and those that do.
DOI:10.3390/app13052972