Issues in Software Measurement & Estimation ISMA 2010
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.
Related Posts Computer Generated
New Code Counter Update Available from USC
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.
Related Posts Computer Generated
Software Estimating: Sources and Uses of Data and Data Driven Estimates Intro
These days software estimation vendors are competing to have the largest repositories of completed software projects, and the customer is encouraging this competition, which is fundamentally good. However, there is more to insuring the accuracy of an estimation model than just having a lot of data points sitting on the proverbial shelf.
Where Data Comes From
The first question asked of a vendor is, where does your data on completed software projects come from? Early on, much of it came from Government agencies, who in turn collected from contractors. Over time, public sources have emerged that contain voluntarily submitted information from private companies worldwide; the prime example of this being the International Software Benchmark Standards Group (ISBSG). Galorath has obtained software project data over the years through numerous private and public sources. The data comprises many thousands of total observations that have passed data quality tests. Most observations contain size and effort information, thousands more do not contain all the desired fields.
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.
Related Posts Computer Generated
Live From UK Williams Formula 1: Ford Motor Company Europe Uses SEER for Software and IT
This morning Ford Motor Company’s European operation presented their development process, how estimating is improving their developments and how they tie IT infrastructure and IT services into the estimate with SEER to see the complete costs, make trade-offs and produce successful solutions. They have several gates where estimates are required and a lessons learned post mortem. In an excellent talk the speaker pointed out that even when the requirements are known, there is requirements growth. This is modeled with the SEER “requirements volatility” parameter.
The presentation will be available at www.galorath.com in the next few days.
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.
Related Posts Computer Generated
Software Code Counter Review and Recommendations
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:
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.
Related Posts Computer Generated
Variances In Personnel Can Change Productivity By a Factor of 10
I got a question today from someone defining best practices on productivity based on personnel. They wanted to know what the differences might be based on their capabilities. It was easy to perform such a trade study in SEER-SEM for the overall productivity or just a partial.
Knowledge bases normally set these so no work is required unless there are known or anticipated specific circumstances. But this trade study took seconds. Here is part of the answer provided:
SEER people-specific parameters include:
Analyst Capabilities: Capabilities of the team to function (not just the individuals) and the impacts of management, motivation, etc. on that team
Analyst Application Experience: Average experience of the software team that will work on the project with the overall domain (such as finance or command & control)
Programmer Capabilities: Capabilities of the team to function (not just the individuals) and the impacts of management, motivation, etc. on that team
Programmers Language Experience: Average team experience with the programming language(s) that will be used in this implementation activity
Development System Experience: Average team experience with the computers, operating systems and other items that will be used to develop the software
Target System Experience: Average team experience with the target computers, operating systems and other items that will be used to execute the software in the end (target) environment
Practices & Methods Experience: Average team experience with the development processes, methods, standards and procedures used on this project
Knowledge bases set these in normal ranges so individual ratings are not required. And if you do know or want to do tradeoffs: One of the important things is to rate the team, not just the individuals, and how they will perform together. And of course the range allows the expressions of your uncertainty up-front.
Looking at the full range, from the worst of the worst to the best of the best, can provide a 10 to 1 variance in cost.
Also, here is a chart showing how those parameters increase costs when they are at the worst case.
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.
Related Posts Computer Generated
Software Staff Size Still Impacts Productivity: Brooks Law Lives!
When drawing conclusions from data it is important to analyse all the relevant considerations and not just one variable. For example, the first chart “effective productivity versus effective functions” shows a slight increase in productivity as the project gets bigger. Some people have jumped to conclusions stating that bigger projects are more productive. However, when looking at staff levels the fallacy becomes apparent.
Of course it is important to define what productivity is. If someone changes a 10,000 function point system and adds 5, the productivity is not 10,005. The effective productivity id based on the new functionality and the work involved in redesign, reimplementation, and retest, forming an effective productivity. Some studies leave out such detail.
The second chart, from the same data-set, shows that as the staff gets bigger the productivity gets lower, exactly what Brooks Law stated.
Note this analysis was performed using a portion of our database that includes function points, and effective function points as well a effort and staff.
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.
Related Posts Computer Generated
C Language is AGAIN the Most Widely Used Programming Language
I hear so often tha tthe “C” programing language is dying or dead. I suppose I hear it mostly from Java lovers.. but I can recall having similar conversations with Galorath staff and others.
A new study came out this month showing the C programming language is number one most widely used, followed by JAVA, C++, PHP, Visual Basic, and C#. The rise of C was really a drop in JAVA. Very interesting since the PHP and Visual Basic take less time to master and are much less powerful. According to studies encapsulated in SEER, it takes about 6 months to become a black belt in Basic or PHP and a year in C, JAVA, C+ and C#.
Interestingly ABAP (SAP language) is number 17 on the list, COBOL is number 29 and good old FORTRAN (where I cut my teeth) is number 34.
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.
US Software Costs In Rank Order
Thanks to Capers Jones for passing this list rank ordered list of software costs. As most of us know, software is in crisis and knowing the issues can lead us to solutions.
Here is a ranked list of U.S. software cost drivers:
U.S. Software Costs in Rank Order:
1. The cost of finding and fixing bugs
2. The cost of cancelled projects
3. The cost of producing English words
4. The cost of security flaws and attacks
5. The cost of requirements changes
6. The cost of programming or coding
7. The cost of customer support
8. The cost of meetings and communication
9. The cost of project management
10. The cost of renovation and migration
11. The cost of innovation and new kinds of software
12. The cost of litigation for failures and disasters
13. The cost of training and learning
14. The cost of avoiding security flaws
15. The cost of assembling reusable 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.
Related Posts Computer Generated
More Software Project Failure / Challenge Information From CAI
Bob Lawhorn of CAI, one of my favorite speakers, had a list of recent software project failure information.
- Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year (Forrester Research)
- 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)
- 50% are rolled back out of production (Gartner)
- 40% of problems are found by end users (Gartner)
- 25% – 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
- Up to 80% of budgets are consumed fixing self-inflicted problems (Dynamic Markets Limited 2007 Study)
Bob also listed reasons why projects fail including:
Requirements Issues: Unrealistic project goals, uncontrolled scope creep with no allowance for such in the plan.
Estimating Issues:Inappropriate schedule, no process to re-estimate when the project changes, no reasonableness chekcks.
Quality issues: Trying to test in quality rather than a process that implements quality throughout
Poor Team Productivity: High rework (doing the same thing multiple times due to issues with the initial work)
Project Management Issues: (Lack of planning, earned value, impact of changes and issues… No estimates so no earned value)
Cultural Issues: Hiding the bad news
Bob also touched on how their automated project office product can help with many of these issues and can integrate with Galorath’s SEER-SEM for estimation.
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.