Productmetrics for code, testing and maintenance.Md.Ashikul Islam, 24387Rhine-WaalUniversity of Applied Sciences. ashikul.
[email protected] AbstractIn this paper, I show the knowledge of software qualityproduct metrics of code, testing and maintenance. Software product metrics areused to measure the attributes those have been used to build the softwareproduct. Keywords: Measurement, Metrics, KLOC, Cohesion, MaturityIndex, fan-in.1 IntroductionMeasurement is the key of any engineering process.It is required to measure the understanding of the attributes used for theproduct or system. “It is impossible to manage without measurement” (DeMarco, 1982).
The act of obtaining measure provides a quantitative indication of size of someproduct or process attribute; E.g., number of errors.
Software engineers canget actual insights how the product should be designed and constructed. Somemetrics can easily be measure while some are measured indirectly. The goals ofsoftware metrics are to reduce cost, overtime, workloads and identify how toimprove the product.
For better productivity, software engineers use metrics toprioritize, track and solve any kind of issues during the building of thesoftware. The sooner the problems are detected, the easier and less cost ittakes to troubleshoot them.Software product metrics have been important overa decade for it for the decision makings throughout the software developmentprocess. The first step to measure the metrics are to represent the data thatis collected. Then the metrics are analyzed and computed. At the last stage,modification and verification are performed through requirements, design,source code, testing and maintenance. 2 Software quality metricsSoftware quality metrics are classified into threemajor categories.
i. Product metrics ii. Project metrics iii.
Process metrics. “Software quality metrics should be simple andcomputable, empirical and intuitively persuasive, consistent and objective,consistent in the use of units and dimensions, independent of programminglanguage and effective mechanism for quality feedback” (Ejiogu, 1991). 2.1 Direct MetricsSoftware quality is a multidimensional concept.
For every softwareproduct, there are few metrics which are essential and inevitable. Understandingis the most important metric. Any new user who is using the software productshould gain the basic understandings of the features in minimum time. A newuser must learn how to perform the basic functions of the software. Operationtime of software must be minimum for the new users to perform any operations.
The product is communicativeness only when the human factor is working welllike there is minimum number of negative feedbacks from the users. But it isnever easy to build software with such comprehensive measurements. There arealways some challenges, difficulties in the process of building a product.Complexity measurement is a consistent metrics for the software engineers asthere can arise complexities in every step. 2.2 Quality factorsAccording to McCall, software quality factors are mainly into threedivisions. They arei. Product revisionii.
Product transition iii. Product operation. These three factors relate more to the quality of the delivered productrather than product in development process. In the product revision part, thereare maintainability, flexibility and testability. Maintainability ensures ifthe product can be fixed, testability ensures if it can be tested andflexibility ensures if it can be changed to another version of this product orcompletely into new product.
In the product operation part, there arecorrectness, reliability, efficiency, integrity, usability. Correctness ensuresif the product is what the customer wants. Reliability ensures if the productis working perfectly all the time. Efficiency ensures that it takes minimumtime to solve intended problems. Integrity ensures the security part whileusability ensures if the product is running. In the transition part, there areportability, reusability and interoperability. The portability part ensures ifthe product can be used on another different machine, reusability ensures ifany part of this product can be reused and interoperability ensures if theproduct interfaces with different system. Fig.
McCall’s Software Quality Factors.2.3 Software product metricsBased on IEEE Computer Society definition, “Theapplication of a systematic, disciplined, quantifiable approach to thedevelopment, operation and maintenance of software; that is, the applicationengineering to software.” (IEEE 610.12). But product metrics for software maybe imperfect. It helps to find out catastrophic defects potential solutions forthose problems. Product metrics assessed the quality of the product while it isengineered.
To accomplish the perfect measurement, few certain rules areneeded. 3. MethodSoftware product metrics have some attributes whichare needed to be measured properly in order to build a. A metric must havemathematical properties. It should measure a factor independently to otherfactors. Here are some product metrics factorsi. Total numbers of defects throughoutthe building process and their types.
ii. Documentation page numbers.iii. Source code line numbers before and afterdelivery.
iv. Avg. module complexity.v. Avg. module size.
vi. Module numbers.vii. Unit testing bug numbers.
viii. Integration testing bug numbers.ix. Validation testing bug numbers.x. KLOC productivity.3.
1 Software product metrics for source codeMaurice Halstead proposed measurement of metricsfor source code. Using complete program length, minimum algorithm volume, actualvolume, program level, language level and some other features, the length andvolume N = n1log2n1+ n2log2n2 V = Nlog2(n1+ n2)Where, n1 = distinctoperator numbersn2 = distinctoperand numbersN1 = operatoroccurrence numbersN2 = operandoccurrence numbers3.2 software product metrics for testingAnalysis, design, code metrics must be measuredbefore starting testing metrics. There are two types of metrics for testing.i. Breadth of testing: Total number ofrequirements that have been tested.
ii. Depth of testing: percentage ofindependent basis paths covered by testing versus total number of basis pathsin the program.Maurice Halstead measurements illustrate how to estimatetesting efforts. Using the definitions for program volume V and program levelPL, Halstead efforts e can be measured as PL=1 / (n1/2) x(N2/n2) e=V/PLMetrics for object-oriented testing differs tonormal testing. For object-oriented, there are lack of cohesion methods,percent public and protected, public access to data members, number of rootclasses, fan-in, and number of children and depth of inheritance tree.
3.2 Software product Metrics for maintenanceFor stable software product, Software MaturityIndex (SMI) by IEE Std. 982.1-2005IEEE05 is the best suggestion. If SMI=1.0, then the software is stable.SMI correlates the mean time to produce stable software.
Software Maturity Index(SMI)MT =number of modules in the current releaseFc = numberof modules in the current release that have been changedFa = numberof modules in the current release that have been addedFd = numberof modules from the preceding release that were deleted in the current releaseSMI = MT – (Fc + Fa + Fd) / MT4 DiscussionSoftware quality metrics ensures the quality ofthe product before it is built. Halstead providesan intriguing set of metrics at the source code level. Using the number ofoperators and operands present in the code, software science provides a varietyof metrics that can be used to assess program quality. Few product metrics havebeen proposed for direct use in software testing and maintenance. However, manyother product metrics can be used to guide the testing process and as amechanism for assessing the maintainability of a computer program.
A widevariety of OO metrics have been proposed to assessthe testability of an OO system.References1. Roger S. Pressman, Bruce R. Maxim, “Software engineering- apractitioner’s approach” 8th edition, 2015.2.
K. Naik and P. Tripathy: “Software Testing and Quality Assurance”,Wiley, 2008.
3. Ian Sommerville, Software Engineering, 8th edition, 2006.4.
Aditya P. Mathur,”Foundations of Software Testing”, Pearson Education,2009.5. D. Galin, “Software Quality Assurance: From Theory to Implementation”,Pearson Education, 20046.
David Gustafson, “Theory and Problems of Software Engineering”, Schaum’sOutline Series, McGRAW-HILL,2002.7. https://www.developer.