![]() And none have the simplicity, understandability or clarity of intent that SLOC enjoys. As a result, only a few of these measures survive today. They include concepts such as functionality, complexity, user behavior or elements of architectural design. ![]() Most of these measures try to accomplish too much. Because of early misuse of SLOC, all sorts of alternatives to SLOC (e.g., Function Points and more than 35 variants, Story Points, Object Points, Use Cases and many, many others) were invented in an attempt to “fix” SLOC, but in the end these only complicated matters. Because of this purity, SLOC can be combined with other measures and software cost estimating relationships to estimate effort, duration or productivity (more in a future post). The purpose of SLOC in a measurement practice is simply to capture software size. ![]() There are even those who claim that “…in many situations usage of LOC metrics can be viewed as professional malpractice…” But, as you will see, SLOC has many benefits, when used intelligently. Despite its broad and continuous use (or perhaps because of it) SLOC seems to get the blame for many a failed software project, process improvement or software metrics initiative. ![]() ![]() There seems to be a love/hate relationship with the line of code measure. This blog post describes various uses of SLOC from the perspective of software measurement. Source lines of code (SLOC) is a measure of software size, in use since the 1960s. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |