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.
Help for Japan
Our hearts and thoughts go out to all our friends and associates in Japan, as well as the nation as a whole. We recommend all join with Galorath in supporting the Japan relief efforts via the Red Cross..
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.
Embedded Designs Integration Cost Challenges
Embedded design integration is the integration of all efforts (hardware, software, etc.) within an system that is typically dedicated to perform one or a few functions. Typically there are real-time computing requirements involved in these types of designs. Integration costs can at times become a considerable portion of the overall cost on a project. The continuous introduction of newer technologies continue to drive up integration efforts.
Use of old factors that estimated Integration Assembly and Test ( IAT) as a function of overall top effort were weak before but now can produce dangerously low estimates. Part of the reason why IAT costs have classically been painful can be attributed to the fact that it is at this stage where the complicate blend of hardware to hardware or hardware to software comes to a point and must all meet specifications at once! What worked in recent simulations or in isolated tests now becomes painfully clear won’t work at a combined level. This invariably leads to the continuous waves of adjustments, partial redesigns, re-architecting, retests in a desperate effort to close in on the minimum requirements.
For estimation purposes, careful consideration has to be given to the work break down structure of the embedded systems being modeled to ensure adequate estimation of integration effort and risk are covered at all levels. For instance, just applying a 10-35% IAT factor at an enclosure level in order to capture integration of all board and SW underneath it might be okay for some simple systems but not newer technologies which bring along extra complexities. An example is where the design involves custom components (ASICs, FPGAs, etc) which in turn have embedded processors within their fabrics. In these System on a Chip (SOC) designs, it make sense to break out the cost of integrating the SW onto the chip itself. At the next level one could add another rollup to cover the integration of SW to the main board running a general purpose processor, etc.
Another example could be designs that involve multiple separate custom chips running on the board since there might be a significant effort to get these chips to work with each other.
In our SEER H hardware model, we break out these sections with a separate roll up to calculate the IAT. At this point, we take care to set the parameters that describe the complexity of the effort and the experience of the folks doing the work. If this type of design is done often, we would create a knowledgebase (default template) to capture and standardize the estimation approach. As can be seen, many designs can involve layers of IAT which in turn can drive up the final overall IAT numbers considerably beyond 35%.
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 Defects in Fielded Software: Cast Analysis
Cast Software has identified the number of potential errors and possible costs of maintenance after software has been deployed.
Average cost per thousand lines $2819
Average business application 374,000 lines
Average number of serious problems in fielded software per thousands of lines of code:
ABAP 20
COBOL 89
.net 169
C/c++ 438
j2EE 463
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.
Project Prediction Infographic
