Jump to content

Software metric: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
unreliable source
No edit summary
 
(31 intermediate revisions by 17 users not shown)
Line 1: Line 1:
{{short description|Measure of the degree to which software possesses some property}}
{{Software development process}}
{{Software development process}}

A '''software metric''' is a standard of measure of a degree to which a [[software]] system or process possesses some property. Even if a metric is not a measurement (metrics are functions, while measurements are the numbers obtained by the application of metrics), often the two terms are used as synonyms. Since quantitative measurements are essential in all sciences, there is a continuous effort by [[computer science]] practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance, testing, software debugging, software performance optimization, and optimal personnel task assignments.
In [[software engineering]] and [[Software development|development]], a '''software metric''' is a standard of measure of a degree to which a [[software system]] or process possesses some property.<ref>{{Cite book|last=Fenton|first=Norman E.|url=https://www.worldcat.org/oclc/834978252|title=Software metrics : a rigorous and practical approach|date=2014|others=James Bieman|isbn=978-1-4398-3823-5|edition=3rd|location=Boca Raton, FL|oclc=834978252}}</ref><ref>{{Cite book|last1=Timóteo|first1=Aline Lopes|title=Software Metrics: A Survey|last2=Álvaro|first2=Re|last3=Almeida|first3=Eduardo Santana De|last4=De|first4=Silvio Romero|last5=Meira|first5=Lemos|citeseerx=10.1.1.544.2164}}</ref> Even if a metric is not a measurement (metrics are functions, while measurements are the numbers obtained by the application of metrics), often the two terms are used as synonyms. Since [[Quantitative research|quantitative measurement]]s are essential in all sciences, there is a continuous effort by [[computer science]] practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance, testing, software [[debugging]], software [[Program optimization|performance optimization]], and optimal personnel task assignments.


== Common software measurements ==
== Common software measurements ==
Common software measurements include:
Common software measurements include:
* [[ABC Software Metric]]
* [[Balanced scorecard]]
* [[Balanced scorecard]]
* [[Software bug|Bugs]] per line of code
* [[Software bug|Bugs]] per line of code
* [[Code coverage]]
* [[Code coverage]]
* [[Cohesion (computer science)|Cohesion]]
* [[Cohesion (computer science)|Cohesion]]
* Comment density<ref>{{cite web|title=Descriptive Information (DI) Metric Thresholds|url=http://www.lsec.dnd.ca/qsd_current_version/eng_support/di/metrics.htm|work=Land Software Engineering Centre|accessdate=19 October 2010|deadurl=yes|archiveurl=https://archive.is/20110706175332/http://www.lsec.dnd.ca/qsd_current_version/eng_support/di/metrics.htm|archivedate=6 July 2011|df=}}</ref>
* Comment density<ref>{{cite web|title=Descriptive Information (DI) Metric Thresholds|url=http://www.lsec.dnd.ca/qsd_current_version/eng_support/di/metrics.htm|work=Land Software Engineering Centre|access-date=19 October 2010|url-status=dead|archive-url=https://archive.today/20110706175332/http://www.lsec.dnd.ca/qsd_current_version/eng_support/di/metrics.htm|archive-date=6 July 2011}}</ref>
* [[Connascent software components]]
* [[Connascent software components]]
* [[COCOMO|Constructive Cost Model]]
* [[COCOMO|Constructive Cost Model]]
* [[Coupling (computer science)|Coupling]]
* [[Coupling (computer science)|Coupling]]
* [[Cyclomatic complexity]] (McCabe's complexity)
* [[Cyclomatic complexity]] (McCabe's complexity)
* Cyclomatic complexity density<ref>{{Cite journal|last1=Gill|first1=G. K.|last2=Kemerer|first2=C. F.|date=December 1991|title=Cyclomatic complexity density and software maintenance productivity|url=https://ieeexplore.ieee.org/document/106988|journal=IEEE Transactions on Software Engineering|volume=17|issue=12|pages=1284–1288|doi=10.1109/32.106988|issn=1939-3520}}</ref><ref>{{Cite web|title=maintainability - Does it make sense to compute cyclomatic complexity/lines of code ratio?|url=https://softwareengineering.stackexchange.com/questions/56056/does-it-make-sense-to-compute-cyclomatic-complexity-lines-of-code-ratio|access-date=2021-03-01|website=Software Engineering Stack Exchange}}</ref>
* Defect density - defects found in a component
* Defect density - defects found in a component
* Defect potential - expected number of defects in a particular component
* Defect potential - expected number of defects in a particular component
* Defect removal rate
* Defect removal rate
* [[DSQI]] (design structure quality index)
* [[DSQI]] (design structure quality index)
* [[Function Point]]s and Automated Function Points, an [[Object Management Group]] standard<ref>{{cite web|url=http://www.omg.org/news/releases/pr2013/01-17-13.htm |title=OMG Adopts Automated Function Point Specification |publisher=Omg.org |date=2013-01-17 |accessdate=2013-05-19}}</ref>
* [[Function Point]]s and Automated Function Points, an [[Object Management Group]] standard<ref>{{cite web|url=http://www.omg.org/news/releases/pr2013/01-17-13.htm |title=OMG Adopts Automated Function Point Specification |publisher=Omg.org |date=2013-01-17 |access-date=2013-05-19}}</ref>
* [[Halstead complexity measures|Halstead Complexity]]
* [[Halstead complexity measures|Halstead Complexity]]
* [[Instruction path length]]
* [[Instruction path length]]
* [[Maintainability#Software engineering|Maintainability index]]
* [[Maintainability#Software engineering|Maintainability index]]
* [[Source lines of code|Number of lines of code]]
* [[Source lines of code]] - number of lines of code
* [[Run time (program lifecycle phase)|Program execution time]]
* [[Run time (program lifecycle phase)|Program execution time]]
* [[Loader (computing)|Program load time]]
* [[Loader (computing)|Program load time]]
* [[Binary file|Program size (binary)]]
* [[Binary file|Program size (binary)]]
* [[Weighted Micro Function Points]]
* [[Weighted Micro Function Points]]
* [[Cycle time (software)]]
* [[CISQ]] [[Software quality#CISQ's Quality model|automated quality characteristics measures]]
* [[First pass yield]]
* Corrective Commit Probability<ref>{{cite arXiv|last1=Amit|first1=Idan|last2=Feitelson|first2=Dror G.|date=2020-07-21|title=The Corrective Commit Probability Code Quality Metric|class=cs.SE|eprint=2007.10912}}</ref>


== Limitations ==
== Limitations ==
As software development is a complex process, with high variance on both methodologies and objectives, it is difficult to define or measure software qualities and quantities and to determine a valid and concurrent measurement metric, especially when making such a prediction prior to the detail design. Another source of difficulty and debate is in determining which metrics matter, and what they mean.<ref name="integration_watch"/><ref name="when_why_how">{{cite web|last=Kolawa|first=Adam|title=When, Why, and How: Code Analysis|url=http://www.codeproject.com/KB/interviews/Code_Review.aspx|work=The Code Project|accessdate=19 October 2010}}</ref>
As software development is a complex process, with high variance on both methodologies and objectives, it is difficult to define or measure software qualities and quantities and to determine a valid and concurrent measurement metric, especially when making such a prediction prior to the detail design. Another source of difficulty and debate is in determining which metrics matter, and what they mean.<ref name="integration_watch"/><ref name="when_why_how">{{cite web|last=Kolawa|first=Adam|title=When, Why, and How: Code Analysis|url=https://www.codeproject.com/Articles/28440/When-Why-and-How-Code-Analysis|work=The Code Project|date=7 August 2008|access-date=14 February 2021}}</ref>
The practical utility of software measurements has therefore been limited to the following domains:
The practical utility of software measurements has therefore been limited to the following domains:
* [[Schedule (project management)|Scheduling]]
* [[Schedule (project management)|Scheduling]]
Line 38: Line 44:


A specific measurement may target one or more of the above aspects, or the balance between them, for example as an indicator of team motivation or project performance.
A specific measurement may target one or more of the above aspects, or the balance between them, for example as an indicator of team motivation or project performance.
<ref>{{cite news |last1=Mike |first1=John |title=Essential Metrics for Effective Incident Response Strategies |url=https://cybercentaurs.com/blog/essential-metrics-for-effective-incident-response-strategies/ |access-date=18 July 2021}}</ref>
Additionally metrics vary between static and dynamic program code, as well as for object oriented software (systems).<ref>{{Cite book|last1=Gosain|first1=Anjana|last2=Sharma|first2=Ganga|title=Information Systems Design and Intelligent Applications |chapter=Dynamic Software Metrics for Object Oriented Software: A Review |date=2015|editor-last=Mandal|editor-first=J. K.|editor2-last=Satapathy|editor2-first=Suresh Chandra|editor3-last=Kumar Sanyal|editor3-first=Manas|editor4-last=Sarkar|editor4-first=Partha Pratim|editor5-last=Mukhopadhyay|editor5-first=Anirban|chapter-url=https://link.springer.com/chapter/10.1007/978-81-322-2247-7_59|series=Advances in Intelligent Systems and Computing|volume=340|language=en|location=New Delhi|publisher=Springer India|pages=579–589|doi=10.1007/978-81-322-2247-7_59|isbn=978-81-322-2247-7}}</ref><ref>{{Cite book|last1=S|first1=Parvinder Singh|title=Dynamic Metrics for Polymorphism in Object Oriented Systems|last2=Singh|first2=Gurdev|citeseerx=10.1.1.193.4307}}</ref>


== Acceptance and public opinion ==
== Acceptance and public opinion ==
Some software development practitioners point out that simplistic measurements can cause more harm than good.<ref>{{citation |last=Kaner|first=Dr. Cem|title=Software Engineer Metrics: What do they measure and how do we know?|citeseerx=10.1.1.1.2542}}</ref> Others have noted that metrics have become an integral part of the software development process.<ref name="integration_watch">{{cite web|last=Binstock|first=Andrew|title=Integration Watch: Using metrics effectively|url=http://www.sdtimes.com/link/34157|work=SD Times|publisher=BZ Media |accessdate=19 October 2010}}</ref>
Some software development practitioners point out that simplistic measurements can cause more harm than good.<ref>{{citation |last=Kaner|first=Dr. Cem|title=Software Engineer Metrics: What do they measure and how do we know?|year=2004|citeseerx=10.1.1.1.2542}}</ref> Others have noted that metrics have become an integral part of the software development process.<ref name="integration_watch">{{cite web|last=Binstock|first=Andrew|title=Integration Watch: Using metrics effectively|url=http://www.sdtimes.com/link/34157|work=SD Times|date=March 2010|publisher=BZ Media |access-date=19 October 2010}}</ref>
Impact of measurement on programmer psychology have raised concerns for harmful effects to performance due to stress, performance anxiety, and attempts to cheat the metrics, while others find it to have positive impact on developers value towards their own work, and prevent them being undervalued. Some argue that the definition of many measurement methodologies are imprecise, and consequently it is often unclear how tools for computing them arrive at a particular result,<ref>{{citation|first1=Rüdiger|last1=Lincke|first2=Jonas|last2=Lundberg|first3=Welf|last3=Löwe|title=Comparing software metrics tools|year=2008|work=International Symposium on Software Testing and Analysis 2008|pages=131–142|url=http://www.arisa.se/files/LLL-08.pdf}}</ref> while others argue that imperfect quantification is better than none (“You can’t control what you can't measure.”).<ref>{{cite book | last = DeMarco | first = Tom | author-link = Tom DeMarco | title = Controlling Software Projects: Management, Measurement and Estimation | year = 1982 | publisher = Yourdon Press | isbn = 0-13-171711-1}}</ref> Evidence shows that software metrics are being widely used by government agencies, the US military, NASA,<ref>{{cite web |url=http://earthdata.nasa.gov/our-community/esdswg/metrics-planning-and-reporting-mparwg |title=NASA Metrics Planning and Reporting Working Group (MPARWG) |publisher=Earthdata.nasa.gov |access-date=2013-05-19 |url-status=dead |archive-url=https://web.archive.org/web/20111022023020/https://earthdata.nasa.gov/our-community/esdswg/metrics-planning-and-reporting-mparwg |archive-date=2011-10-22 }}</ref> IT consultants, academic institutions,<ref>{{cite web|url=http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html |title=USC Center for Systems and Software Engineering |publisher=Sunset.usc.edu |access-date=2013-05-19}}</ref> and commercial and academic [[Comparison of development estimation software|development estimation software]].
Impact of measurement on programmer psychology have raised concerns for harmful effects to performance due to stress, performance anxiety, and attempts to cheat the metrics, while others find it to have positive impact on developers value towards their own work, and prevent them being undervalued.

Some argue that the definition of many measurement methodologies are imprecise, and consequently it is often unclear how tools for computing them arrive at a particular result,<ref>{{citation|first1=Rüdiger|last1=Lincke|first2=Jonas|last2=Lundberg|first3=Welf|last3=Löwe|title=Comparing software metrics tools|year=2008|work=International Symposium on Software Testing and Analysis 2008|pages=131–142|url=http://www.arisa.se/files/LLL-08.pdf}}</ref> while others argue that imperfect quantification is better than none (“You can’t control what you can't measure.”).<ref>{{cite book | last = DeMarco | first = Tom | authorlink = Tom DeMarco | year = | title = Controlling Software Projects: Management, Measurement and Estimation | edition = | pages = | publisher = | isbn = 0-13-171711-1}}</ref>
== Further reading ==
Evidence shows that software metrics are being widely used by government agencies, the US military, NASA,<ref>{{cite web |url=http://earthdata.nasa.gov/our-community/esdswg/metrics-planning-and-reporting-mparwg |title=NASA Metrics Planning and Reporting Working Group (MPARWG) |publisher=Earthdata.nasa.gov |date= |accessdate=2013-05-19 |deadurl=yes |archiveurl=https://web.archive.org/web/20111022023020/https://earthdata.nasa.gov/our-community/esdswg/metrics-planning-and-reporting-mparwg |archivedate=2011-10-22 |df= }}</ref> IT consultants, academic institutions,<ref>{{cite web|url=http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html |title=USC Center for Systems and Software Engineering |publisher=Sunset.usc.edu |date= |accessdate=2013-05-19}}</ref> and commercial and academic [[Comparison of development estimation software|development estimation software]].

* J. Smith, ''Introduction to Linear Programming'', Acme Press, 2010. An introductory text.

* Reijo M.Savola, ''Quality of security metrics and measurements, Computers & Security, Volume 37, September 2013, Pages 78-90.''<ref>{{Cite journal|last=Savola|first=Reijo M.|date=2013-09-01|title=Quality of security metrics and measurements|url=https://www.sciencedirect.com/science/article/pii/S0167404813000850|journal=Computers & Security|language=en|volume=37|pages=78–90|doi=10.1016/j.cose.2013.05.002|issn=0167-4048}}</ref>


== See also ==
== See also ==
Line 49: Line 61:
* [[List of tools for static code analysis]]
* [[List of tools for static code analysis]]
* [[Orthogonal Defect Classification]]
* [[Orthogonal Defect Classification]]
* [[Software crisis]]
* [[Software engineering]]
* [[Software engineering]]
* [[Software package metrics]]
* [[Software package metrics]]
Line 62: Line 73:
external links are not for promotion.
external links are not for promotion.
------------------------------------------------------- -->
------------------------------------------------------- -->
* [http://www.ndepend.com/Metrics.aspx Definitions of software metrics in .NET]
* [http://www.sqa.net/softwarequalitymetrics.html Software Metrics] (SQA.net)
* [http://www.sqa.net/softwarequalitymetrics.html Software Metrics]
* [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.2542 Software Engineering Metrics: What do they measure and how do we know]
*[https://web.archive.org/web/20201016160155/https://standards.nasa.gov/standard/osma/nasa-std-87398 NASA Standard NASA-STD-8739.8 (Software Assurance and Software Safety Standard)]
* [http://www.kaner.com/pdfs/metrics2004.pdf Software Engineering Metrics: What do they measure and how do we know]
*[https://emenda.com/his/ HIS Source Code Metrics] (''outdated but for reference''; related see [[AUTOSAR]])
*[https://www.exida.com/Blog/software-metrics-iso-26262-iec-61508 HIS Source Code Metrics version 1.3.1 01.04.2008] (''outdated but for reference''; related see [[AUTOSAR]])
*[https://dl.acm.org/doi/10.1145/1839379.1839400 A framework for source code metrics]
*[https://swehb.nasa.gov/display/SWEHBVB/Metrics+-+Software+Metrics+Report NASA.gov]
*[https://docs.sonarqube.org/latest/user-guide/metric-definitions/ SonarQube Metric Definitions]
*[https://www.researchgate.net/publication/235759663_Metrics_of_Object_Oriented_Software/stats Metrics of Object Oriented Software] (2010)


{{DEFAULTSORT:Software Metric}}
{{DEFAULTSORT:Software Metric}}
[[Category:Software metrics|*]]
[[Category:Software metrics|*]]
[[Category:Metrics]]
[[Category:Metrics]]
[[Category:Software engineering]]

Latest revision as of 07:58, 11 July 2024

In software engineering and development, a software metric is a standard of measure of a degree to which a software system or process possesses some property.[1][2] Even if a metric is not a measurement (metrics are functions, while measurements are the numbers obtained by the application of metrics), often the two terms are used as synonyms. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance, testing, software debugging, software performance optimization, and optimal personnel task assignments.

Common software measurements

[edit]

Common software measurements include:

Limitations

[edit]

As software development is a complex process, with high variance on both methodologies and objectives, it is difficult to define or measure software qualities and quantities and to determine a valid and concurrent measurement metric, especially when making such a prediction prior to the detail design. Another source of difficulty and debate is in determining which metrics matter, and what they mean.[8][9] The practical utility of software measurements has therefore been limited to the following domains:

A specific measurement may target one or more of the above aspects, or the balance between them, for example as an indicator of team motivation or project performance. [10] Additionally metrics vary between static and dynamic program code, as well as for object oriented software (systems).[11][12]

Acceptance and public opinion

[edit]

Some software development practitioners point out that simplistic measurements can cause more harm than good.[13] Others have noted that metrics have become an integral part of the software development process.[8] Impact of measurement on programmer psychology have raised concerns for harmful effects to performance due to stress, performance anxiety, and attempts to cheat the metrics, while others find it to have positive impact on developers value towards their own work, and prevent them being undervalued. Some argue that the definition of many measurement methodologies are imprecise, and consequently it is often unclear how tools for computing them arrive at a particular result,[14] while others argue that imperfect quantification is better than none (“You can’t control what you can't measure.”).[15] Evidence shows that software metrics are being widely used by government agencies, the US military, NASA,[16] IT consultants, academic institutions,[17] and commercial and academic development estimation software.

Further reading

[edit]
  • J. Smith, Introduction to Linear Programming, Acme Press, 2010. An introductory text.
  • Reijo M.Savola, Quality of security metrics and measurements, Computers & Security, Volume 37, September 2013, Pages 78-90.[18]

See also

[edit]

References

[edit]
  1. ^ Fenton, Norman E. (2014). Software metrics : a rigorous and practical approach. James Bieman (3rd ed.). Boca Raton, FL. ISBN 978-1-4398-3823-5. OCLC 834978252.{{cite book}}: CS1 maint: location missing publisher (link)
  2. ^ Timóteo, Aline Lopes; Álvaro, Re; Almeida, Eduardo Santana De; De, Silvio Romero; Meira, Lemos. Software Metrics: A Survey. CiteSeerX 10.1.1.544.2164.
  3. ^ "Descriptive Information (DI) Metric Thresholds". Land Software Engineering Centre. Archived from the original on 6 July 2011. Retrieved 19 October 2010.
  4. ^ Gill, G. K.; Kemerer, C. F. (December 1991). "Cyclomatic complexity density and software maintenance productivity". IEEE Transactions on Software Engineering. 17 (12): 1284–1288. doi:10.1109/32.106988. ISSN 1939-3520.
  5. ^ "maintainability - Does it make sense to compute cyclomatic complexity/lines of code ratio?". Software Engineering Stack Exchange. Retrieved 2021-03-01.
  6. ^ "OMG Adopts Automated Function Point Specification". Omg.org. 2013-01-17. Retrieved 2013-05-19.
  7. ^ Amit, Idan; Feitelson, Dror G. (2020-07-21). "The Corrective Commit Probability Code Quality Metric". arXiv:2007.10912 [cs.SE].
  8. ^ a b Binstock, Andrew (March 2010). "Integration Watch: Using metrics effectively". SD Times. BZ Media. Retrieved 19 October 2010.
  9. ^ Kolawa, Adam (7 August 2008). "When, Why, and How: Code Analysis". The Code Project. Retrieved 14 February 2021.
  10. ^ Mike, John. "Essential Metrics for Effective Incident Response Strategies". Retrieved 18 July 2021.
  11. ^ Gosain, Anjana; Sharma, Ganga (2015). "Dynamic Software Metrics for Object Oriented Software: A Review". In Mandal, J. K.; Satapathy, Suresh Chandra; Kumar Sanyal, Manas; Sarkar, Partha Pratim; Mukhopadhyay, Anirban (eds.). Information Systems Design and Intelligent Applications. Advances in Intelligent Systems and Computing. Vol. 340. New Delhi: Springer India. pp. 579–589. doi:10.1007/978-81-322-2247-7_59. ISBN 978-81-322-2247-7.
  12. ^ S, Parvinder Singh; Singh, Gurdev. Dynamic Metrics for Polymorphism in Object Oriented Systems. CiteSeerX 10.1.1.193.4307.
  13. ^ Kaner, Dr. Cem (2004), Software Engineer Metrics: What do they measure and how do we know?, CiteSeerX 10.1.1.1.2542
  14. ^ Lincke, Rüdiger; Lundberg, Jonas; Löwe, Welf (2008), "Comparing software metrics tools" (PDF), International Symposium on Software Testing and Analysis 2008, pp. 131–142
  15. ^ DeMarco, Tom (1982). Controlling Software Projects: Management, Measurement and Estimation. Yourdon Press. ISBN 0-13-171711-1.
  16. ^ "NASA Metrics Planning and Reporting Working Group (MPARWG)". Earthdata.nasa.gov. Archived from the original on 2011-10-22. Retrieved 2013-05-19.
  17. ^ "USC Center for Systems and Software Engineering". Sunset.usc.edu. Retrieved 2013-05-19.
  18. ^ Savola, Reijo M. (2013-09-01). "Quality of security metrics and measurements". Computers & Security. 37: 78–90. doi:10.1016/j.cose.2013.05.002. ISSN 0167-4048.
[edit]