Project Planning & Estimation » Software Sizing

Galorath / DCG IT Estimation For Business Value and Project Success Clinic

galorath — Fri, 28 Oct 2011 11:07:26 +0000

Here are the slides from the Galorath / David Consulting Group estimating clinic held in New York City. There were interesting discussions encompassing dealing with impossible demands, understanding risk and risk management, sizing, and a number of other topics. Note: The Galorath slides and the DCG slides are combined in the one PDF file.

Concepts of IT providing business value to the organization were also discussed in detail.

Thanks to all who attended and especially to Mike Harris and David Herren for their insights.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Galorath / Reifer Team To Provide Large Project Success Via Risk Assessments We are excited to announce a new addition to the...
Another View of Project Success From Dr. Dobbs While the Standish Group’s surveys are the most widely known...
The Business Value Of IT Book I opened my copy of this book, The Business Value of...

Why We Estimate Schedule & Cost

galorath — Thu, 01 Sep 2011 03:07:29 +0000

I stumbled across a working draft of an excellent document on my hard drive, produced, I believe, by a gentleman from Texas Instruments some years ago. I thought this list of why we estimate cost and schedule was excellent and still relevant.

Why We Estimate Schedule & Cost

To scope proposed tasks
To explore alternative system concepts

design to cost/budget

To explore alternative design concepts
To explore alternative proposals for enhancements and upgrades
To identify key design elements
To identify key process parameters

prioritize needs vs wants

To identify key assumptions
To identify and quantify uncertainties
To identify tasks and their relationships
To assess schedule feasibility
To identify, allocate and schedule resources
To assess an organization’s ability to perform within targeted costs
To evaluate the consequences of internal and external constraints
To establish achievable objectives
To establish a basis for quality service
To establish commitments
To bound the risk against customer needs
To balance levels of risk against customer needs
To provide a basis of successful risk management

build vs buy analysis

To prepare successful proposals
To evaluate proposals from competing bidders
To establish baselines for project tracking

enhance/reuse vs redesign analysis

To predict life-cycle costs
To predict returns on investments
To provide information for establishing business and investment strategies

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Step One: Establish Estimate Scope and Purpose Establish Estimate Scope and Purpose Define and document expectations. When...
Step Seven: Estimate Validation and Review Step Seven: Estimate Validation and Review At this point in...
Design To Cost Metrics Can Help Increase Project Value While Reducing Cost An interesting paperBy Quentin Redman and George Stratton in the...

Cost of Independent Software Verification & Validation (IV&V)

galorath — Thu, 01 Sep 2011 00:42:45 +0000

It has long been that IV&V (Independent Verification & Validation) was purchased by the pound, in other words spend what you want. That is beginning to change. Galorath’s Bob Hunt briefed a method for performing a cost estimate and return based on defects and estimating the optimal spend with ROI considerations for IV&V on critical software. Bob rightly claims this approach needs refinement but it is a great start. Here are the basics:

•Assumptions:

•A Software Development program has a Total Development Cost of $X =($x/SM)(SM)*

•The Cost of Internal Software Testing (IST) is 50% of the total Software Development cost, or IST = (0.5)($X)=($x/size)(Zsize)

•IV&V cost 2 times IST or IV&V=(2)(0.5)($x/size)(Zsize)

•There are Y delivered defects per size metric

•The Cost of Defect Recovery and Removal follows the “1:10:100” rule and we all “Y” defects would have been found after fielding

•The simple cost Break Even Point is reached when:

•IV&V cost = IV&V Savings

•(2)(0.5)($x/size)(Zsize)= (100)(Y)($x/SM)

•Zsize = 100Y

•Zsize/100 = Y

*SM – size metric could be expressed as Lines of Code, Function Points, …

•Assume 7 to 10 delivered defects per KSLOC

•Code Complete by Steve McConnell:

•(a) Industry Average: “about 15 – 50 errors per 1000 lines of delivered
code.

•(b) Microsoft Applications: “about 10 – 20 defects per 1000 lines of code
during in-house testing, and 0.5 defect per KLOC (KLOC IS CALLED AS 1000 lines of code) in released product (Moore 1992).

(c) “Harlan Mills pioneered ‘cleanroom development’, a technique that has
been able to achieve rates as low as 3 defects per 1000 lines of code during in-house testing and 0.1 defect per 1000 lines of code in released product (Cobb and Mills 1990). A few projects – for example, the space-shuttle software – have achieved a level of 0 defects in 500,000 lines of code using a system of format development methods, peer reviews, and statistical testing.“

•Capers Jones assumes 5 to 7 defects per function point

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Estimating The Cost of Software Independent Verification & Validation (IV&V) Since IV&V is a level of effort activity (purchase a...
Software Defects in Fielded Software: Cast Analysis Cast Software has identified the number of potential errors and...
Dealing With Generated Lines of Code We have gotten several questions recently on how to estimate...

Original Function Point Paper

galorath — Thu, 14 Jul 2011 19:57:18 +0000

Here is (one of) the original papers on Function Points, circa 1983.

I love the simple definition of function points in the paper: “…essentially the weight sum of the number of inputs, outputs, master files, inquiries provided to or generated by the software.”

Today function points are a widely used method of defining software size or scope. Many organizations use them for estimating. Many also use them for executive oversight of software development using metrics such as hours per function point and number of defects per function point.

It is interesting to note that one of the major findings was the high correlation between lines of code and function points and the work pointing to Halstead’s software science and their relation to function points. He demonstrated a correlation from .854 to .997 of lines of code to function points in this paper.

It is also a walk down memory lane for me. My foray into estimating, after my project being killed due to my estimate, was Halstead’s software science.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Function Point Simple Introduction I keep meaning to post Galorath’s Ton Dekker concise introduction to...
COSMIC Function Points In SEER SEER for Software supports the COSMIC function point estimation counting...
Lines of Code Versus Functon Points Versus Use Cases For Sizing I, along with many others, have written about the virtues...

Counting (Or Estimating) Lines of Code

galorath — Wed, 02 Mar 2011 18:19:14 +0000

Counting or estimating lines of code is a viable sizing method so long as consistant counting rules are used and hand generated code is counted seperately. Here are some of the counting rules Galorath recommends. They are consistant with the industry:

SLOC Attribute	Included	Excluded
What is Included/Excluded
Executable statements	X
Non-executable data declaration statements and compiler directives	X
Comments, continuation lines, banners, blank lines, instantiated SLOC and nonblank spacers.		X
How Lines Are Produced	Include	Exclude
Manually/hand programmed SLOC	X
Lines developed for use as input to a Source Code Generator	X
Lines generated as output from a Source Code Generator. Note: Software from a Source Code Generator is estimated best via function point sizing, not SLOC. Some people estimate generated lines by counting the total number of generated lines and applying reuse factors to them to reduce the effective size that will be used by the cost model.		X
Lines converted with automated code translators. However, these lines should be considered as pre-existing Lines of Code, and the amount of rework required on the translated code should be defined through the use of rework percentages. See chapter 8 Software Reuse.	X
Copied, reused, or modified lines of code. Again, these lines should be considered as Pre-existing SLOC and the Lines of Code.	X
Deleted lines of code. The rework percentages of the remaining SLOC account for the work to make the program execute correctly without the deleted lines.		X
The Origin of Each Line	Include	Exclude
New lines developed from scratch.	X
Pre-existing lines taken from a prior version, build or release.	X
Invocation statements or pre-existing lines requiring rework from COTS or other off-the-shelf packages. Again, rework percentages need to be calculated.	X
Invocation statements for modified vendor-supplied or special support libraries, but not the unmodified library code itself.	X
Modified vendor-supplied or special support libraries, commercial libraries, reuse libraries, or other software component libraries. Rework percentages should be calculated for modifying these lines.	X
Lines that are part of an unmodified vendor-supplied operating system or utility or other non-developed code.		X
End Usage of Each Line	Include	Exclude
Lines that are in, or part of, the primary product.	X
Lines that are external to, or in support of, the primary product, only if they are part of the final or deliverable program.	X
Lines that are external to, or in support of, the primary product, but are not deliverable, or any other non-deliverable lines.		X

Hers is a higher level definition of lines. It can be useful when dealing with a new language:

Logical Source Line Rules

Include

Exclude

Control statements (DO While, DO Until, GOTO etc.)Mathematical statements (ex: i = a*b)Conditional statements (IF, THEN, ELSE)

Deliverable Job Control (JCL) statements

Data declarations

Data typing and equivalence statements

INPUT/OUTPUT format statements

CommentsBlank linesBEGIN statements from Begin-End pairs (count one line only for each pair)

Non-delivered programmer debugging statements

Continuation of formatting statements

Machine or library-generated data statements

The following example shows a C++ program. It is 9 logical lines even thought it is 36 physical lines. THis captures lines that do work without cluttering with formatting, comments, etc.

Example C++ Program	Physical Carriage Returns	Physical Lines	Logical Lines	Logical Lines Using Language Rules
extern double MessageMonitor(double dfComplexity, double dfSuccessRate);	1	1	1	1
/**	2		comment
* function: ExampleFunction	3		comment
*	4		comment
* purpose: Demonstrate counting of C code	5		comment
*	6		comment
* arguments: x [IN]: first argument	7		comment
* y [IN]: second argument	8		comment
* bar [IN]: third argument, an array of…	9		comment
*	10		comment
* returns: return value	11		comment
*	12		comment
**/	13		comment
double ExampleFunction(double x, double y, int *bar) {	14	2	partial	2
	15		blank
int n = (int) ((x + y) / 2);	16	3	2	3
int SuccessfulAlert = 0;	17	4	3	4
	18		Blank
if (x < MessageMonitor (y, n))	19	5	Partial	5
	20		Blank
/* this is a comment */	21		Comment
	22		Blank
SuccessfulAlert = bar[n] + 5;	23	6	4	6
	24		Blank
else	25	7	Partial
	26		Blank
while (n > 0) {	27	8	Partial	7
	28		Blank
SuccessfulAlert += (int) MessageMonitor (x, n);	29	9	5	8
	30		Blank
n–;	31	10	6	9
	32		Blank
}	33	11	7
	34		Blank
return (++x + SuccessfulAlert + bar(n));	35	12	8	10
}	36	13	9

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Counting XML Source Lines of Code A customer recently asked how to count XML for their...
Software Code Counter Review and Recommendations Galorath’s Mike Churchman did a comprehensive evaluation of numerous code...
Dealing With Generated Lines of Code We have gotten several questions recently on how to estimate...

Issues in Software Measurement & Estimation ISMA 2010

galorath — Fri, 20 Aug 2010 23:18:36 +0000

Measurement is a wonderful thing. However measurement without standards and definition can be worse than no measurement at all. This paper which I will be presenting at the 2010 ISMA conference begins the attack, highlighting the need and proposing that additional work commences in standards for estimation and measurement. Software Estimation and Measurement 2010

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Measurement and Providing Value to the Business ISMA Keynote 2011 Here is a copy of my keynote talk at the...
The Future of Software Analysis Measurement Webinar Featuring Bill Curtis, David Herron and Dan Galorath We have some exciting events coming up this month with...
Weight Management = Measurement and Estimation Weight management is all about measurement and estimation. Estimating quantity...

New Code Counter Update Available from USC

galorath — Wed, 07 Jul 2010 16:29:13 +0000

The University of Southern California has been developing and updating line of code counters for a number of years. Such code counters can be very handy when using lines of code as a size measure. I know, many object to using lines of code, but when used correctly they can work well. We see users who have just as much success with lines of code as they do with function points, use cases, etc.

Even if you are a functional size user, knowing the SLOC for legacy can be useful, rather than counting the function points, etc. Here is the announcement from USC:

We are pleased to announce that a new version of the Unified CodeCount (UCC) tool is now available to the public at http://sunset.usc.edu/research/CODECOUNT/. This Release 2010.07 supports new programming languages (e.g., Fortran, Python, ColdFusion, Bash and C-Shell script) and the CSV output format among other enhancements and bug fixes. Please refer to the release notes document for further details at http://sunset.usc.edu/research/CODECOUNT/download/2010/UCC_Release_Notes_v.2010.07.pdf

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Software Code Counter Review and Recommendations Galorath’s Mike Churchman did a comprehensive evaluation of numerous code...
New Code Counting Tool Made Available A new version of the USC code counting tool has...
Dealing With Generated Lines of Code We have gotten several questions recently on how to estimate...

Software Code Counter Review and Recommendations

galorath — Wed, 05 May 2010 17:08:02 +0000

Galorath’s Mike Churchman did a comprehensive evaluation of numerous code counting tools and provided recommendations.

While some people may wonder why anyone would want to count code (it can be useful when estimating the amount of work in reuse as well as gaining a benchmark for estimating new code when using lines as a size measure) Mike’s evaluation is very useful.� I am including only the report on the top two tools.

Recommendations:

C/C++

USC CodeCount

�Java

USC CodeCount

Perl

USC CodeCount (if you can get around the bug)

PHP

CLOC.EXE, with adjustment factor

Python

CLOC.EXE, with adjustment factor

Test files:

For Java, Perl, PHP, and Python, he used several files which I pulled from various SourceForge projects. For C++, he used our standard sample file from the manual and Dan’s book.

Manual count (Control)

In the test files, he counted partial lines separately from SLOC, simply because he wasn’t sure about what to do with them, so my initial SLOC count simply doesn’t include partials at all.

The code counters which he tested were (for the most part) smart enough to tell the difference between blank lines, comments, and actual code. With very few exceptions, their blank-line and comment counts agreed, and matched my hand-counts.

There was, however, some significant variation in the SLOC numbers which they reported.

C/C++, Java, and Perl:

The USC code counter generally gave the most conservative SLOC counts — ranging from the same as mine, to over 25% less. In many cases, the USC count was about 4% to 10% lower than his hand count.

Perl bug:

He found one bug in the USC code counter for Perl: it appears that if the number of opening and closing quotes in a comment block don’t match, the counter stops counting SLOC, although it will continue to count comments and blank lines. Unfortunately, it also fails to recognize a quote character at the end of a comment line, unless it is followed by two spaces.

PHP and Python:

The USC code counters don’t handle PHP and Python. The best of the ones that are available all give reasonably accurate counts of code (as opposed to comment or blank) lines, but they count partial lines as full lines. One promising-looking application, for example, counts (according to the online documentation) physical, rather than logical lines.

Suggestion:

For PHP and Python (and for Perl, if you can’t find any practical way around the USC counter’s bug), you could use CLOC.EXE, which seems to give accurate total counts for SLOC + partial lines, then apply an adjustment factor to the output to get something reasonably close to an accurate SLOC count.

How do you come up with and adjustment factor? His first impulse would be to take some representative samples of code from various sources (the test files that I’ve been using might be sufficient, although we may want something larger), hand-count SLOC and partials, get an average SLOC-to-total (SLOC + partials) ratio for each language, and use that as a multiplier.

Other Code Counters:

Universal Code Counter gives counts which generally match CLOC.EXE, sometimes, however, it seems to be rather far off the mark, and it reverses the counts for blanks and comments, which leaves me somewhat in doubt of its accuracy. Most of the other counters were less accurate, or at least less reliable.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

New Code Counter Update Available from USC The University of Southern California has been developing and updating...
New Code Counting Tool Made Available A new version of the USC code counting tool has...
Counting (Or Estimating) Lines of Code Counting or estimating lines of code is a viable sizing...

RICE Objects Definition

galorath — Sat, 27 Feb 2010 21:16:29 +0000

RICE is SAP Terminology (R)eports, (I)interfaces, (C)onversions, (E)nhancements

Reports: Number of formatted and organized presentations of data, including output forms.
Interfaces: Number of boundaries across which two independent systems meet and act on or communicate with each other
Conversions: Number of processes that transfer or copy data from an existing system to load production systems.
Enhancements (Extensions): Number of programs that are in addition to an existing standard program.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Tongue In Cheek Definition of Cost Analysis From an Aerospace Corporation course: “The art of estimating the...
Towards a Standard Definition of IT Infrastruture In the article “IT Policy: An Essential Element of IT...
What Is IT Infrastructure: A Definition and a Taxonomy There are probably as many definitions of IT Infrastructure as...

Rand Monograph on Software Sizing

galorath — Tue, 12 Jan 2010 09:36:03 +0000

The Rand corporation has posted its report on software sizing

I especially enjoyed the paragraphs on risks in size estimation…

They identify three types of uncertainty

Specification or design uncertainty
Development method uncertainty
Estimation process uncertainty

It is encouraging to see people referring to estimation process uncertainty as a risk.

As we view estimate maturity in many organizations we sometimes find that estimation is not considered important… until the project is late or over budget.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.

Step Four: Software Sizing Size is generally the most significant (but certainly not the...
Book “Software Sizing, Estimation & Risk Management” Is Now Available Electronically Dan’s book, Software Sizing, Estimation & Risk Management, is now...
List of Documents On Software Sizing he following is a list of documents on software sizing. ...