This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
1.1.3 Defect Severity – Defect severity by percentage of total defects. Defect Severity helps determine how close to
release the software is and can help in allocating resources.
– Critical – blocking other tests from being run and alpha release,
– Severe – blocking tests and beta release,
– Moderate – testing workaround possible, but blocking final release
– … very minor – fix before the “Sun Burns Out”, USDATA 1994.
– See the first graph on the next page.
1.1.4 Test Burnout Chart of cumulative total defects and defects by period over time periods. It is a measure of
the rate at which new defects are being found.
– Test Burnout helps project the point at which most of the defects will be found using current test cases and procedures, and therefore when (re)testing can halt.
– Burnout is projection or an observation of when no more or only a small number of new defects are expected to be found using current practices.
– Beware, it doesn’t project when your system will be bug free, just when your current testing techniques are not likely find additional Defects.
This tracks the number of defects found per tester. (not shown) This is only quantitative and not qualitative analysis,
– Reporting this may lead to quota filling by breaking defects into many small nits rather that one comprehensive report. – Remember Deming’s 14 Quality Principles.
– Many nits are harder to manage and may take more time to fix than having all related issues rolled into one bigger defect.
1.1.7 Root cause analysis What caused the defect to be added to the system – generally try to react to this by evolving
the software development process.
Sometimes this is also referred to Injection Source, although Injection Source is sometimes limited to Internal or External.
– Internal refers to defects caused by the development team (from Requirements Engineers, Designers, Coders, Testers, …).
– External refers to defects caused by non-development team people (customers gave you wrong information, 3rd party software came with defects, etc.)
1.1.8 How defects were found Inspections, walkthroughs, unit tests, integration tests, system tests, etc. If a quality assurance
technique isn’t removing defects, it is a waste of time and money.
1.1.9 Injection Points In what stage of the development cycle was the defect put into the system. This can help evolve
a process to try to prevent defects.
1.1.10 Detection Points In what stage of the development cycle was the defect discovered.
Want to look at the difference between the Injection Point and Detection Point– If there is a significant latency between Injection and Detection, then the process needs to
evolve to reduce this latency. Remember defect remediation costs increase significantly as we progress through
o Programming difficulty increases if additional operators are introduced (i.e., as n1 increases) and if an operands are repeatedly used (i.e., as N2/n2 increases)
Effort, E = V / L* = D* * V = n1* N2 * N * log2 n / (2 * n2) = 9989
o Two solutions may have very different Effort estimates.
A psychologist, John Stroud, suggested that human mind is capable of making a limited number of mental discrimination per second (Stroud Number), in the range of 5 to 20.
o Using a Stroud number of 18,
o Time for development, T = E/ 18 discriminations/seconds
The function point count is computed by multiplying each raw count by the weight and summing all values
FPs are very subjective -- depend on the estimator. They cannot be counted automatically
1.2.5
“In the late 1970's A.J. Albrecht of IBM took the position that the economic output unit of software projects should be valid for all languages, and should represent topics of concern to the users of the software. In short, he wished to measure the functionality of software.
Albrecht considered that the visible external aspects of software that could be enumerated accurately consisted of five items: the inputs to the application, the outputs from it, inquiries by users, the data files that would be updated by the application, and the interfaces to other applications.
After trial and error, empirical weighting factors were developed for the five items, as was a complexity adjustment. The number of inputs was weighted by 4, outputs by 5, inquiries by 4, data file updates by 10, and interfaces by 7. These weights represent the approximate difficulty of implementing each of the five factors.
In October of 1979, Albrecht first presented the results of this new software measurement technique, termed "Function Points" at a joint SHARE/GUIDE/IBM conference in Monterey, California. This marked the first time in the history of the computing era that economic software productivity could actually be measured.
Table 2 provides an example of Albrecht's Function Point technique used to measure either Case A or Case B. Since the same functionality is provided, the Function Point count is also identical.
The Function Point metrics are far superior to the source line metrics for expressing normalized
productivity data. As real costs decline, cost per Function Point also declines. As real productivity goes up, Function Points per person month also goes up.
In 1986, the non-profit International Function Point Users Groups (IFPUG) was formed to assist in transmitting data and information about this metric. In 1987, the British government adopted a modified form of Function Points as the standard software productivity metric. In 1990, IFPUG published Release 3.0 of the Function Point Counting Practices Manual, which represented a consensus view of the rules for Function Point counting. Readers should refer to this manual for current counting guidelines. “
Table 1 - SLOC per FP by LanguageLanguage SLOC per FP
The table below contains Function Point Language Gearing Factors from 2597 completed function point projects in the QSM database. The projects span 289 languages from a total of 645 languages represented in the database. Because mixed-language projects are not a reliable source of gearing factors, this table is based upon single-language projects only. Version 3.0 features the languages where we have the most recent, high-quality data.
The table will be updated and expanded as additional project data becomes available. As an additional resource, the David Consulting Group has graciously allowed QSM to include their data in this table.
Environmental factors can result in significant variation in the number of source statements per function point. For this reason, QSM recommends that organizations collect both code counts and final function point counts for completed software projects and use this data for estimates. Where there is no completed project data available for estimation, we provide the following gearing factor information (where sufficient project data exists):
the average the median the range (low - high)
We hope this information will allow estimators to assess the amount of variation, the central tendency, and any skew to the distribution of gearing factors for each language.
Note: That the applications that a Language is used for may differ significantly. C++, Assembly, Ada … may be used for much more complex projects than Visual Basic, Java, etc. – Rowe’s 2 cents worth.
2.1.1 “A Metrics Suite for Object Oriented Design” S.R. Chidanber and C.F. Kemerer, IEEE Trans. Software Eng., vol 20, no. 6, pp476-493, June 1994.
See metrics below
2.1.2 “A validation of Object-Oriented Design Metrics as Quality Indicators”V.R. Basili, L.C.Briand, W.L Melo, IEEE Trans. On Software Engineering, vol. 22, no. 10, Oct. 1996
WMC – Weighted Methods per Class is the number of methods and operators in a method (excluding those inherited from parent classes). The higher the WMC the higher the probability of fault detection.
DIT – Depth of Inheritance Tree, number of ancestors of a class. The higher the DIT the higher the probability of fault detection.
NOC – Number of Children of a Class, the number of direct descendants for a class. Was
inversely related to fault detection. This was believed to result from high levels of reuse by children. Maybe also if inheritance fan-out is .wide rather than deep, then we have fewer levels of inheritance.
CBO – Coupling Between Object Classes, how many member functions or instance variables of another class does a class use and how many other classes are involved. Was significantly related to probability of finding faults.
RFC – Response For a Class, the number of functions of a class that can directly be executed by other classes (public and friend). The higher the RFC the higher the probability of fault detection.
Many coding standards address these either directly or indirectly. For instance, limit DIT to 3or 4, provide guidance against coupling, provide guidance for methods per class.
2.2 Use of SPC in software quality assurance.
o Pareto for function. 80-20%; 80 of defect found in 20% of modules
o Control and run charts – if error rates increase above some control level, we need to take action
o Look for causes, modify process, modify design, reengineer, rewrite, …
2.3 Questions about Metrics
Is publishing metrics that relate to program composition actually Quality beneficial?