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

October 28, 2011 · Filed Under General, IT Estimating, Risk, Software Estimating, Software Sizing, Ten Step Project Estimation Process · Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Why We Estimate Schedule & Cost

August 31, 2011 · Filed Under Cost Estimating, Estimating, Software Estimating, Software Sizing, Systems Estimating · Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



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

August 31, 2011 · Filed Under General, Software Sizing · Comment 

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:

Read more

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Original Function Point Paper

July 14, 2011 · Filed Under General, Software Estimating, Software Sizing · 1 Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Counting (Or Estimating) Lines of Code

March 2, 2011 · Filed Under General, Software Estimating, Software Sizing · Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Issues in Software Measurement & Estimation ISMA 2010

August 20, 2010 · Filed Under Estimation Process, General, measurement, Software Sizing · Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



New Code Counter Update Available from USC

July 7, 2010 · Filed Under Software Sizing · Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Software Code Counter Review and Recommendations

May 5, 2010 · Filed Under Software Estimating, Software Sizing · 1 Comment 

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:

Read more

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



RICE Objects Definition

February 27, 2010 · Filed Under Software Estimating, Software Sizing · 1 Comment 

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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Rand Monograph on Software Sizing

January 12, 2010 · Filed Under Software Sizing · Comment 

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

  1. Specification or design uncertainty
  2. Development method uncertainty
  3. 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, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.



Next Page »