## 2 Software Metrics and the Maintainability
### Predicting Software Maintainability  
In general, software maintainability depends on various aspects of software modification, including correction, improvement, efficiency, and prevention [14]. The inability to measure maintainability directly and holistically remains the open challenge of software maintainability measurement. Additionally, the lack of a uniform definition of maintainability throughout different quality models leaves room for a variety of measurement approaches. Several prediction models have been proposed by researchers that measure software maintainability through indirect measures, such as change, maintainability index, and change proneness [14]. The indirect maintainability measures combined with a variety of software metrics that capture the quality of software's internal quality, represent efficient \begin{table}
\begin{tabular}{c c c c} \hline \hline \multicolumn{2}{c}{**C \& K Software Metrics**} & \multicolumn{2}{c}{**JHAWK Counterparts**} \\ \hline
**Metric** & **Description** & **Metric** & **Description** \\ \hline \multirow{2}{*}{CBO} & The number of classes to which & \multirow{2}{*}{CBO} & A measure represents the number of all \\  & a class is coupled. & & classes coupled to a class. \\ \hline \multirow{2}{*}{DIT} & Level for a class within its class & \multirow{2}{*}{DIT} & A measure represents the number of \\  & hierarchy. & & classes that a class inherits from. \\ \hline \multirow{4}{*}{LCOM} & The average percentage of & \multirow{4}{*}{LCOM} & A measure of the correlation between the \\  & methods in a class using each & & methods and the local instance variables \\ \cline{1-1}  & data filed in the class subtracted & & of a class. The measure follows the \\ \cline{1-1}  & from 100\%. & & definition of the LCOM metric revised by \\ \hline \multirow{2}{*}{NOC} & The number of immediate & \multirow{2}{*}{NSUB (Subclasses)} & The number of all the classes that have \\  & subclasses of a class. & & this class in their inheritance tree. \\ \hline \multirow{4}{*}{RFC} & Count of methods implemented & \multirow{4}{*}{RFC} & A summary of the complexity of a class in \\  & within a class plus the number & & terms of method calls. The value is \\ \cline{1-1}  & of methods accessible to an & \multirow{2}{*}{RFC} & A summary of the complexity of a class in \\ \cline{1-1}  & object class due to inheritance. & & methods in the class (excluding inherited \\ \hline \multirow{4}{*}{WMC} & Count of methods implemented & \multirow{4}{*}{TCC (Total Cyclomatic  Complexity)} & A summary of the complexity of methods in a class that is calculated from the \\ \cline{1-1}  & Count of methods implemented & & number of logical branch points (e.g., \\ \cline{1-1}  & within a class. & & conditional statement, if, switch, for, \\ \cline{1-1}  & & & while and catch) in the method, whereby \\ \cline{1-1}  & & & method itself is counted as one logical \\ \hline \hline \end{tabular}
\end{table} 
Table 1: The Chidamber & Kemerer (C&K) software metrics and their alternatives in JHawk. input for either statistical or machine learning algorithms to make useful prediction models. To establish a relationship between software design metrics as the independent variable and maintainability as the dependent variable, various techniques have been practised in the last two and half decades [9], including statistical algorithms, machine learning algorithms, nature-inspired techniques, expert judgment, and hybrid techniques [6; 19]. In 1993, researchers [PERSON] and [PERSON] [31] proposed a prediction model that estimated the maintainability of the software system based on the change metric, which was introduced as a measure of maintenance effort. Paper shows that more frequent changes, reflected in higher values of change metric, indicate lower maintainability of the software. Based on a change metric and a set of L&K metrics, the maintainability prediction model was built with the use of a multivarian regression analysis model.