Content deleted Content added
m Open access bot: url-access updated in citation with #oabot. |
CortexFiend (talk | contribs) Link suggestions feature: 2 links added. |
||
Line 87:
|}
Another increasingly common problem in comparing SLOC metrics is the difference between auto-generated and hand-written code. Modern software tools often have the capability to auto-generate enormous amounts of code with a few clicks of a mouse. For instance, [[graphical user interface builder]]s automatically generate all the source code for a [[Graphical control element (software)|graphical control elements]] simply by dragging an icon onto a workspace. The work involved in creating this code cannot reasonably be compared to the work necessary to write a [[device driver]], for instance. By the same token, a hand-coded custom GUI class could easily be more demanding than a simple device driver; hence the shortcoming of this metric.
There are several cost, schedule, and effort estimation models which use SLOC as an input parameter, including the widely used Constructive Cost Model ([[COCOMO]]) series of models by [[Barry Boehm]] et al., [[PRICE Systems]] [[True S]] and Galorath's [[SEER-SEM]]. While these models have shown good predictive power, they are only as good as the estimates (particularly the SLOC estimates) fed to them. Many<ref>IFPUG [http://www.qpmg.com/pdf/articles/Quantifying_the_Benefits_Using_Function_Points.pdf "Quantifying the Benefits of Using Function Points"]</ref> have advocated the use of [[function point]]s instead of SLOC as a measure of functionality, but since function points are highly correlated to SLOC (and cannot be automatically measured) this is not a universally held view.
Line 123:
|}
David A. Wheeler studied the [[Red Hat]] distribution of the [[Linux|Linux operating system]], and reported that [[Red Hat Linux]] version 7.1<ref name = "Wheeler-RH7.1">{{cite web |date=2001-06-30 |url=http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html |author=David A. Wheeler |title=More Than a Gigabuck: Estimating GNU/Linux's Size }}</ref> (released April 2001) contained over 30 million physical SLOC. He also extrapolated that, had it been developed by conventional proprietary means, it would have required about 8,000 person-years of development effort and would have cost over $1 billion (in year 2000 U.S. dollars).
A similar study was later made of [[Debian GNU/Linux]] version 2.2 (also known as "Potato"); this operating system was originally released in August 2000. This study found that Debian GNU/Linux 2.2 included over 55 million SLOC, and if developed in a conventional proprietary way would have required 14,005 person-years and cost US$1.9 billion to develop. Later runs of the tools used report that the following release of Debian had 104 million SLOC, and {{As of|2005|alt=as of year 2005}}, the newest release is going to include over 213 million SLOC.
| |||