Original Function Point Paper
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.
10 Laws of Software Productivity
I have been teaching these productivity laws for years and these effects can be modeled in our SEER-SEM model. But the real point is you cant just mandate software completion dates and effort without paying the consequences. Consequences included technical debt, failing applications, unfortunate limited functionality (this is where agile can help in many situations by building the most critical functionality first) and more. Much of this is based on entropy (decreased productivity) as team sizes increase.
Some people make a case that there is no entropy or even more efficiencies as software gets bigger. When analysis is completed this is generally the result of natural reuse or copy / paste, more efficient reintegration and retest, and reduced rework. The 10 laws are: 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 or call us at +1 310 414-3222.
ScrumMaster and Techical Debt
Technical debt can be reduced by ensuring “done” is a robust “done” rather than a weak “done.” A robust “done” means the software is adequately tested, and meeting the objectives of the development. Unfortunately many projects use the exhaustive rule of testing… that is test until you run out of time, then ship. One of the major benefits of agile methods are (hopefully) that the software is sufficiently tested.
I recently heard of projects that had 10 teams of 10 doing agile approaches successfully on a single program. Hard to manage but working. This is a good thing.
It must be noted that Scrum addresses uncertain requirements and attempts to put multiple disciplines into a team. ScrumMasters are multi-talented and experienced. Just claiming to be doing Scrum, Agile, etc. is not a way to success.
Recent data showed about 80% of experienced agile teams do a macro level estimate upon project start. For larger projects this is essential… For very small projects it is probably OK to tell the stake holders you will be done when you are done since it will only be a few months. That doesn’t fly for larger programs.
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.
Barry Boehm Tribute
What a privilege it was to participate in the recent tribute to Dr Barry Boehm in Beijing. In addition to Professor Boehm himself, many of the icons of software research were present. There were some amazing presentations which should be posted on the web soon. The presentation I gave includes an introduction to Barry’s academic genealogy and his PhD legacies, Jo Ann Lane and Ricardo Valerdi, as well as an amplification of the 8 principles in Barry’s introduction to my book: Software Sizing, Estimation, and Risk Management.
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 Integrate Then Test
I have recently heard people referring to the integrate then test approach to software development and was concerned about its risks.
After an excellent talk by Rational’s Walker Royce, I now understand the approach and agree that it can reduce project risk.
Here is what is meant:
Essentially it doesn’t mean to not test units of software at all, just throwing initial compiled versions into the integration mix.
It does mean taking nominally working software components, before all the coverage testing, stress testing, etc. and integrating them to test the integration itself before spending all the time on the individual testing of software that might not integrate… working out the integration issues first. 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 or call us at +1 310 414-3222.
Opportunistic Software Reuse From Canceled Projects
This is a frightening article from IEEE Software entitled Scrapheap Software Development. Its point is that if a significant amount of development has been completed when a project is canceled, that portions of that software can be used to create low-cost systems.
“Salvaging components and functionality from abandoned software projects can provide a rapid, low-cost means to develop new products. Check out these guidelines on opportunistic software reuse.”
But here the assumption is that the developers know what is available in advance.
Scrapheap development requires knowing what scrap is available, where to obtain it, and how to render it useful to the current project.
I am all for software reuse and for reusable components. SEER analysis shows substantial cost savings by reusing software (often 65% or more). But Galorath has evaluated systems where just the reverse engineering to figure out what the existing systems did made them impracticable for reuse… less cost and less risk to start over.
We have also seen great savings, and some great tragedies, with unplanned reuse from existing systems to new systems. That is: where an existing system had components that could be reused but this was not considered by the original developers. But the successful situations used proven software, not abandoned, questionably viable components.
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.
Underestimation, Over Reliance on Modeling and Misunderstanding Risk in Cost Estimates in Software Development
Total Cost of Ownership (TCO) has been popularized by Gartner for estimating all of the costs, both direct and indirect, which go into a project. Managing a software development and implementation project is exceptionally difficult: estimating initial costs is hard enough, but how do you accurately estimate the cost of software maintenance or the burden placed upon IT infrastructure and support?
Many software projects result in total or partial project failure, indeed it can be said that many projects are planned to fail. Inaccurate initial cost assessments are compounded by increased uncertainty and misunderstanding over software maintenance and the true costs associated with support and operation. There is a serious risk of failing to understand the true project requirements combined with failing to adequately plan the project, which contributes to a loss of control once work commences.
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 Keynote ISPA March 2011
Today my conference presentation involved understanding and estimating value in software and IT systems as well as total ownership costs. It still amazes me how so many software and IT leaders do not want to think in terms of Return on Investment but just want to build things that seem to be good ideas. If we would build what has the most value IT could become a profit center. Key points were:
- Estimation is a key portion of business decision making
- Value must be considered in addition to cost
- Data doesn’t have to be perfect to be useful
- Estimators taking some responsibility for business value analysis can make a major improvement in business
I have included entire PowerPoint presentation here.
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 (Or Estimating) Lines of Code
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.
Software Project Monitoring & Control
Galorath’s Dr. Denton Tarbet offers thoughts on Project Monitoring & Control:
Galorath’s SEER SEM with Project Monitoring & Control (PMC) option provides a simple tool to overcome the schedule prediction shortcomings of traditional Earned Value Management (EVM) methods. In particular since EVM expresses project performance in terms of cost, the method loses the predictability of evaluating schedule at complete (Schedule EAC). As Walt Lipke Points out[i], “Eventually all budget will be earned as the work is completed, no matter how late you finish. The Schedule Variance improves as the project progresses and ends up with $0 variance at the end of the project.” Recall that SV = BCWP – BCWS which by definition will be 0 at the end of the project and the SPI will be 1.0.
To overcome that issue it is necessary to develop an earned schedule concept, with some additional effort. In lieu of adding effort to the EVM process, simply incorporating the EVM metrics as snapshots of project performance into the SEER PMC tool using the project model developed for the initial project estimates provides output that parallels the EVM output for cost and schedule, but the value of the schedule projections is retained throughout the project. PMC forecasts a realistic schedule variance from plan in terms of schedule metrics which is calibrated to reflect the actual accomplishments. In addition, it can be demonstrated that PMC provides the project control feedback to project management to provide a method to evaluate alternative options designed to improve project performance in an attempt to improve project schedule performance.
Robert Hunt, et al provides a relevant discussion of EVM on software intensive projects[ii]. Additional white papers and referenced articles on the Galorath website provide more detailed discussion related to using SEER SEM and PMC to develop and manage a successful software intensive project[iii].
[i] www.earnedschedule.com/Docs/ES%20-%20an%20extension%20to%20EVM%20EVA-10%202005%20Lipke
[ii] Data & Analysis Center for Software (DACS) Software Tech News –EVM issue (Volume 12, No. 1) DACS Software Tech News
[iii] http://www.galorath.com/search_results.html?q=EVM&cx=016648429445878925337%3Ajnoaofuymoe&cof=FORID%3A11&sa=Search#1304
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.
Project Prediction Infographic
