<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>software metrics &#8211; Science</title>
	<atom:link href="https://scienmag.com/tag/software-metrics/feed/" rel="self" type="application/rss+xml" />
	<link>https://scienmag.com</link>
	<description></description>
	<lastBuildDate>Tue, 13 Oct 2026 21:21:43 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

<image>
	<url>https://scienmag.com/wp-content/uploads/2024/07/cropped-scienmag_ico-32x32.jpg</url>
	<title>software metrics &#8211; Science</title>
	<link>https://scienmag.com</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">73899611</site>	<item>
		<title>Explainable AI Points to Reused Code as a Hidden Signal of Software Faults</title>
		<link>https://scienmag.com/explainable-ai-points-to-reused-code-as-a-hidden-signal-of-software-faults/</link>
		
		<dc:creator><![CDATA[Denise Maddox]]></dc:creator>
		<pubDate>Tue, 13 Oct 2026 21:21:43 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[challenges of black-box machine learning in development]]></category>
		<category><![CDATA[code reuse]]></category>
		<category><![CDATA[defect prediction]]></category>
		<category><![CDATA[early software defect identification]]></category>
		<category><![CDATA[explainable AI]]></category>
		<category><![CDATA[explainable AI in software engineering]]></category>
		<category><![CDATA[fault prediction]]></category>
		<category><![CDATA[impact of code reuse on bug detection]]></category>
		<category><![CDATA[interpretability of AI models in software testing]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[LIME]]></category>
		<category><![CDATA[Machine learning]]></category>
		<category><![CDATA[machine learning for bug prediction]]></category>
		<category><![CDATA[maintainability]]></category>
		<category><![CDATA[package cohesion]]></category>
		<category><![CDATA[package-level fault analysis]]></category>
		<category><![CDATA[reuse-aware software architecture]]></category>
		<category><![CDATA[role of code reuse signals in fault prediction]]></category>
		<category><![CDATA[SHAP]]></category>
		<category><![CDATA[software defect prediction techniques]]></category>
		<category><![CDATA[software engineering]]></category>
		<category><![CDATA[software fault prediction]]></category>
		<category><![CDATA[software metrics]]></category>
		<category><![CDATA[transparent fault detection models]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=269131</guid>

					<description><![CDATA[Researchers have built a reuse-aware, package-level fault prediction model for Java applications that pairs architectural metrics with SHAP and LIME explainable AI to show developers exactly why code is flagged as defect-prone.]]></description>
										<content:encoded><![CDATA[<p>Finding defects before they reach production has long been one of the most stubborn challenges in software engineering. A fault discovered after release can cost orders of magnitude more to fix than one caught during development, and as systems grow into millions of lines spread across hundreds of packages, manual inspection becomes hopeless. Machine-learning-based fault prediction has promised a way out: models trained on historical bug data learn which code characteristics foreshadow trouble, so that quality-assurance teams can focus their scarce testing effort where it matters most. Yet in practice these models have struggled to earn the trust of developers, largely because they behave as black boxes that flag a package as risky without explaining why. A new study published in Cluster Computing by Mohsin Shaikh of the University of Larkano, Sabina Akram of the University of Bari, Irfan Tunio, and Jawad Khan and Younhyun Jung of Gachon University tackles both problems at once, combining a package-level, reuse-aware view of software architecture with explainable artificial intelligence techniques that make the model&#8217;s reasoning transparent.</p>
<p>The researchers argue that the level of abstraction at which fault prediction operates matters enormously. Much of the classic literature works at the granularity of individual classes, scoring each class for its likelihood of harboring a defect using metrics such as lines of code, cyclomatic complexity, or the well-known CK metric suite. But modern Java applications are organized into packages, and it is at this architectural level that developers actually plan, review, and refactor their code. Predicting faults at the class level produces thousands of scattered warnings that no team can act on coherently, while predicting at the package level yields a shortlist of architectural units that managers and engineers can directly schedule for inspection, testing, or restructuring. The new model therefore treats the package, not the class, as its unit of analysis, and the authors demonstrate through empirical evaluation on standard benchmark datasets that this package-level abstraction is an effective and practical lens for fault prediction.</p>
<p>What distinguishes this work from earlier package-level studies is its explicit attention to code reuse. Software is rarely written entirely from scratch; developers routinely reuse classes, share functionality across packages, and lean on familiar patterns to accelerate development. Reuse is usually celebrated as a virtue, because well-tested, repeatedly exercised code tends to be stable. But reuse also creates hidden coupling: when several packages depend on the same reused components, a fault in that shared core can propagate widely, and a package whose cohesion depends on reused elements may behave very differently from one built from bespoke code. The authors&#8217; model therefore incorporates architectural metrics designed to capture cohesion, dependency structures, and reuse patterns simultaneously. In doing so it extends a line of research in which Shaikh and colleagues had previously shown that reusability-based package organization carries real signal about where bugs concentrate in object-oriented systems.</p>
<p>The metric suite at the heart of the model draws on decades of work in software modularization research. Cohesion metrics measure how tightly the elements inside a package belong together, on the premise that a package should implement a single, well-defined responsibility. Coupling and dependency metrics count and characterize the relationships between packages, since tangled dependency webs and cyclic references are notorious incubators of defects. Reuse metrics quantify how much of a package&#8217;s content is shared with or derived from other parts of the system. The study&#8217;s appendices provide precise mathematical definitions of these package-level measures, computed with tooling that includes the Understand static analysis environment, and the authors curated their datasets from widely used open-source Java systems, including Eclipse, Apache POI, Lucene, Camel, and the Eclipse JDT Core, with bug information drawn from established defect repositories used across the fault-prediction community.</p>
<p>On the learning side, the researchers assembled a multi-layered evaluation design rather than relying on a single train-and-test split. Cross-validation is used to check that predictive performance holds up across different partitions of the data rather than reflecting one lucky split. More distinctively, the authors adopt an effort-oriented perspective, following recent trends in just-in-time and effort-aware defect prediction. The insight behind this orientation is that raw accuracy is not the metric that matters to a development team; what matters is how many defects a reviewer can uncover per unit of inspection effort. A model that ranks the most defect-dense packages first delivers more practical value than one with a nominally higher classification score that wastes reviewers&#8217; time on sparsely buggy code. By evaluating their model through this effort-aware lens, the authors align the experimental protocol with the way fault prediction is actually consumed in industrial settings.</p>
<p>The third layer of the approach, and the one with the broadest implications, is explainable AI. The researchers integrate two of the most widely adopted interpretability techniques: SHAP, or SHapley Additive exPlanations, which borrows ideas from cooperative game theory to assign each input feature a fair share of credit or blame for an individual prediction, and LIME, or Local Interpretable Model-agnostic Explanations, which approximates a complex model locally around a given prediction with a simple, human-readable surrogate. Applied to fault prediction, these methods can tell a developer not merely that package X is flagged as fault-prone, but that the flag is driven, for example, by unusually low cohesion combined with heavy dependence on reused components and a dense web of outgoing dependencies. Such explanations transform the model&#8217;s output from an opaque verdict into an actionable diagnostic that points toward a specific remedy, whether that is remodularization, targeted testing, or dependency cleanup.</p>
<p>The empirical results, reported across multiple figures and algorithmic descriptions in the paper, support the central conjecture of the study: that package-level abstraction, enriched with reuse awareness and paired with interpretability, improves both the accuracy and the usefulness of fault prediction compared with traditional approaches. The authors note that traditional fault-prediction methods have often lacked scalability, interoperability, and smooth integration into software-quality workflows, and their architecture is designed to address precisely these shortcomings. Just as important, the explanation layer reveals which architectural properties the model has learned to associate with defects, giving the research community a window into the causal texture of software quality rather than a bare leaderboard of predictive scores.</p>
<p>Perhaps the most practically significant finding is the authors&#8217; conjecture that modular design of packages can significantly improve software maintainability and reliability. Because the explainable model surfaces cohesion, dependency, and reuse as the dominant predictors of fault-proneness, it indirectly validates a long-standing principle of software architecture: packages that are cohesive, loosely coupled, and organized around reusable responsibilities tend to be healthier and less buggy. This gives architects empirical, data-driven ammunition when they argue for refactoring a tangled package structure, and it suggests that quality-assurance budgets should be steered toward packages whose architectural metrics deviate from these healthy norms. The work also connects to a growing body of literature on explainable machine learning in software engineering, including studies applying SHAP-style interpretation to just-in-time defect prediction, which together signal a field-wide shift from pure prediction toward prediction that engineers can understand and act upon.</p>
<p>The study was supported by the Sindh Higher Education Commission of Pakistan through its Sindh Research Support Program, by a National Research Foundation of Korea grant funded by the Korean Ministry of Science and ICT, and by an Institute of Information and Communications Technology Planning and Evaluation grant under Korea&#8217;s Leading Generative AI Human Resources Development program, reflecting an international collaboration spanning Pakistan, Italy, and South Korea. The datasets and metric definitions described in the manuscript have been made available to the community, including a public repository of the package-level datasets used in the experiments, which lowers the barrier for other groups to replicate and extend the results. For an industry drowning in technical debt, the message of this research is refreshingly concrete: look at how your packages are organized, pay attention to reuse and coupling, let an interpretable model show you where the risk lives, and fix the architecture before the bugs fix your schedule for you.</p>
<p><strong>Subject of Research:</strong> Explainable AI-based fault prediction at the package level in object-oriented software</p>
<p><strong>Article Title:</strong> Reuse-aware package-level fault prediction with Explainable AI</p>
<p><strong>Article References:</strong> Shaikh, M., Akram, S., Tunio, I., Khan, J., &amp; Jung, Y. (2026). Reuse-aware package-level fault prediction with Explainable AI. <em>Cluster Computing, 29</em>(12), Article 705. <a href="https://doi.org/10.1007/s10586-026-06509-8" rel="noopener noreferrer">https://doi.org/10.1007/s10586-026-06509-8</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s10586-026-06509-8" rel="noopener noreferrer">10.1007/s10586-026-06509-8</a></p>
<p><strong>Keywords:</strong> software fault prediction, explainable AI, SHAP, LIME, package cohesion, code reuse, software metrics, machine learning, software engineering, Java, maintainability, defect prediction</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">269131</post-id>	</item>
		<item>
		<title>Chaos-Tuned AI Promises to Predict Which Software Will Break Before It Does</title>
		<link>https://scienmag.com/chaos-tuned-ai-promises-to-predict-which-software-will-break-before-it-does/</link>
		
		<dc:creator><![CDATA[Blake Davidson]]></dc:creator>
		<pubDate>Wed, 07 Oct 2026 07:11:20 +0000</pubDate>
				<category><![CDATA[Technology and Engineering]]></category>
		<category><![CDATA[AI-driven software reliability]]></category>
		<category><![CDATA[chaos theory in AI]]></category>
		<category><![CDATA[chaotic maps]]></category>
		<category><![CDATA[complex AI models for software analysis]]></category>
		<category><![CDATA[deep learning for software maintenance]]></category>
		<category><![CDATA[feature selection]]></category>
		<category><![CDATA[LSTM]]></category>
		<category><![CDATA[Machine learning]]></category>
		<category><![CDATA[machine learning data imbalance]]></category>
		<category><![CDATA[metaheuristic optimization]]></category>
		<category><![CDATA[neural network hyperparameter tuning]]></category>
		<category><![CDATA[opposition-based learning]]></category>
		<category><![CDATA[predictive analytics in software development]]></category>
		<category><![CDATA[sand cat optimization]]></category>
		<category><![CDATA[SMOTE]]></category>
		<category><![CDATA[software decay prediction]]></category>
		<category><![CDATA[software engineering cost reduction]]></category>
		<category><![CDATA[software maintainability prediction]]></category>
		<category><![CDATA[software metrics]]></category>
		<category><![CDATA[software module failure forecasting]]></category>
		<category><![CDATA[swarm optimization algorithms]]></category>
		<category><![CDATA[tunicate swarm algorithm]]></category>
		<category><![CDATA[walrus optimization]]></category>
		<guid isPermaLink="false">https://scienmag.com/?p=243611</guid>

					<description><![CDATA[Researchers in New Delhi have built a hybrid deep learning framework combining improved SMOTE, swarm-based feature selection, and chaos-assisted metaheuristic tuning that predicts software maintainability with up to 99 percent accuracy across five datasets.]]></description>
										<content:encoded><![CDATA[<p>Every piece of software begins to decay the moment it is written. Requirements shift, code is patched, and modules that once behaved predictably become tangled, fragile liabilities. The discipline of estimating how easily a program can be repaired and extended—known as software maintainability prediction—has long been one of the quieter front lines of software engineering. Now a research team in New Delhi has unveiled an unusually elaborate artificial intelligence framework that claims to push the accuracy of such predictions to nearly ninety-nine percent, using a combination of deep learning, swarm-inspired optimization algorithms, and mathematical chaos theory. The work, published in Cluster Computing by Varun Goel and Arvinder Kaur of Guru Gobind Singh Indraprastha University, describes a pipeline that systematically attacks the three chronic weaknesses of machine learning applied to software data: imbalanced datasets, noisy or redundant features, and poorly tuned neural network hyperparameters.</p>
<p>The stakes are far from academic. Maintenance routinely consumes the largest share of a software project&#8217;s lifetime budget, often dwarfing the original cost of development. If engineers could reliably flag, early in a project&#8217;s life, which modules are likely to become maintenance nightmares, they could refactor them before the costs spiral. The traditional approach relies on static code metrics—counts of lines, cyclomatic complexity, coupling between classes, depth of inheritance trees, and similar structural measurements—fed into statistical or machine learning models that classify modules as maintainable or problematic. Over the past two decades, researchers have tried everything from regression analysis and decision trees to support vector machines and ensembles, and more recently deep learning architectures such as long short-term memory networks, which are better at capturing nonlinear relationships among dozens of correlated metrics.</p>
<p>Yet deep learning brings its own difficulties, and the new framework is essentially a systematic campaign against them. The first obstacle is class imbalance. In real software repositories, the vast majority of modules are reasonably maintainable, while the genuinely troublesome ones form a small minority. A naive classifier can achieve deceptively high accuracy simply by predicting that everything is fine, while completely failing at its actual job of identifying the rare problem modules. Goel and Kaur address this with an improved variant of SMOTE, the Synthetic Minority Over-sampling Technique, which generates synthetic examples of the underrepresented class by interpolating between existing minority samples. Their improved version expands the sample generation space, producing more diverse synthetic instances so that the decision boundary the network learns is not distorted by the lopsided original distribution.</p>
<p>The second obstacle is feature selection. Software metrics datasets contain a bewildering array of overlapping measurements—average lines of code, average cyclomatic complexity in its several variants, counts of methods, comments, semicolons, coupling measures, and cohesion statistics—many of which carry redundant or misleading information. Feeding all of them into a neural network invites overfitting and slows training. The framework employs a binary version of a relatively new metaheuristic called the Multi-Strategy Sand Cat Optimization Algorithm, or BMSCSOA. Inspired by the hunting behavior of sand cats, which can detect prey underground with remarkable sensitivity, the algorithm treats each candidate solution as a binary vector in which a one means the corresponding feature is selected and a zero means it is discarded. Its multi-strategy design lets the search alternate between exploration of the vast feature space and exploitation of promising regions, gradually converging on the most salient subset of metrics.</p>
<p>The third and perhaps most technically inventive component concerns how the LSTM network itself is configured. Hyperparameters—the learning rate, dropout rate, batch size, number of layers, neurons per layer, epochs, and patience settings—profoundly affect performance, but tuning them by hand or by brute-force grid search is prohibitively expensive. Worse, standard optimization runs risk getting trapped in local optima, settling for a mediocre configuration simply because the search started in an unlucky region. The authors tackle this with a two-pronged strategy. First, they initialize the search population using chaotic maps combined with fast random opposition-based learning, or FROBL. Chaotic maps inject deterministic but ergonomically scattered sequences into the initial population, ensuring broad, even coverage of the search space, while opposition-based learning evaluates both a candidate solution and its mirror image, roughly doubling the chance of starting near a good region of the landscape.</p>
<p>Once the population is seeded intelligently, the framework turns to hyperparameter optimization proper, deploying a hybrid of two nature-inspired algorithms: the Tunicate Swarm Optimization Algorithm, which mimics the jet-propulsion and swarming behavior of marine tunicates, and the Walrus Optimization Algorithm, modeled on the social and foraging behavior of walruses. By running these optimizers and hybrids of them against the LSTM&#8217;s hyperparameter space, the framework searches for the configuration that yields the best classification performance on the balanced, feature-selected data. The result is a sequential pipeline—improved SMOTE, then BMSCSOA feature selection, then chaotic FROBL initialization, then tunicate-walrus hyperparameter tuning—that the authors call the Metaheuristic-ChaoticFROBL-LSTM framework, wrapped in a HybridMetaLSTM architecture.</p>
<p>The empirical evaluation is unusually broad. The team tested the framework on five datasets spanning very different eras and styles of software: UIMS and QUES, classic object-oriented systems from the early 1990s originally studied by Li and Henry; JM1, a large procedural dataset from the PROMISE repository of empirical software engineering data; and two newly collected datasets, AN and AK, drawn from Android NET versions 13 and 14 and Apache Kafka versions 3.6 through 3.7 respectively, which the authors themselves curated and published in 2025. The features span the full alphabet soup of software measurement, from Chidamber-Kemerer metrics such as weighted methods per class and depth of inheritance tree to dozens of line-count and complexity statistics. Performance was assessed with three standard classification metrics: accuracy, the area under the ROC curve, and the F1-score, which balances precision against recall.</p>
<p>The reported results are striking. Across all five datasets, the framework achieved accuracy ranging from 97.89 percent to 99.01 percent, AUC values between 97.94 and 99.13 percent, and F1-scores from 96.15 to 97.51 percent. According to the authors, these figures outperform a battery of existing state-of-the-art techniques, including gradient boosting, random forests, optimized extreme learning machines, naive Bayes, support vector machines, and earlier metaheuristic-tuned neural approaches. The consistency of the gains across datasets as different as a 1990s user interface management system and a modern streaming platform suggests the pipeline is not merely overfitting to one data distribution, although independent replication on additional industrial codebases would strengthen the claim considerably.</p>
<p>The broader significance of the work lies less in any single algorithm than in its demonstration that the messy, practical problems of applying machine learning to software engineering data can be engineered away layer by layer. Imbalance, redundancy, and hyperparameter sensitivity are not exotic difficulties; they afflict nearly every predictive model built on real-world software repositories, from defect prediction to effort estimation. By showing that a carefully orchestrated combination of resampling, binary swarm-based feature selection, chaos-assisted population initialization, and hybrid metaheuristic tuning can lift LSTM performance to near-ceiling levels, the study offers a template that other researchers in predictive software analytics are likely to adapt. It also joins a rapidly growing literature in which metaheuristics—sand cats, tunicates, walruses, chimp optimizers, and their many relatives—are routinely hybridized with deep networks for tasks ranging from renewable energy forecasting to medical diagnosis.</p>
<p>Caveats remain, as they always do. The datasets, while diverse, are still modest in size compared with the massive code corpora of large technology companies, and the computational cost of running multiple metaheuristics in sequence is nontrivial, which may matter for teams hoping to integrate such predictions into continuous integration pipelines. The authors report no external funding and declare no conflicts of interest, and they have made their datasets available for other researchers to scrutinize and extend. Whether chaotic maps and walrus-inspired search will become standard equipment in the software quality toolbox is an open question, but the message of the study is clear: the machinery for predicting which code will hurt tomorrow is getting sharper, and the economics of software maintenance may never look quite the same.</p>
<p><strong>Subject of Research:</strong> A metaheuristic and chaos-based LSTM framework for predicting software maintainability</p>
<p><strong>Article Title:</strong> A novel Metaheuristic-ChaoticFROBL-LSTM framework for enhancing software maintainability prediction</p>
<p><strong>Article References:</strong> Goel, V., &amp; Kaur, A. (2026). A novel Metaheuristic-ChaoticFROBL-LSTM framework for enhancing software maintainability prediction. <em>Cluster Computing, 29</em>(14), Article 829. <a href="https://doi.org/10.1007/s10586-026-06597-6" rel="noopener noreferrer">https://doi.org/10.1007/s10586-026-06597-6</a></p>
<p><strong>Image Credits:</strong> AI Generated</p>
<p><strong>DOI:</strong> <a href="https://doi.org/10.1007/s10586-026-06597-6" rel="noopener noreferrer">10.1007/s10586-026-06597-6</a></p>
<p><strong>Keywords:</strong> software maintainability prediction, LSTM, metaheuristic optimization, chaotic maps, opposition-based learning, SMOTE, feature selection, sand cat optimization, tunicate swarm algorithm, walrus optimization, software metrics, machine learning</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">243611</post-id>	</item>
	</channel>
</rss>
