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 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
RICE Objects Definition
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.
Related Posts Computer Generated
Rand Monograph on Software Sizing
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 fid 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.
Related Posts Computer Generated
New Code Counting Tool Made Available
A new version of the USC code counting tool has been made available to the public. Code counters are useful for understanding the volume of pre-existing software inherited by a project and to provide actual counts for organizations that use lines of code as a metric. Such counts can be put into cost estimating models such as SEER or USC’s COCOMO as well. I realize this can start significant arguments but lines of code are a valuable measure in some environments, just like function points or use cases are valuable in others. Beware, there are many buggy or malfunctioning code counting tools on the web.  I know the USC team and those who assisted and this is likely to be more robust. USC’s announcement follows:
Dear Affiliates and CodeCount Users:
We are pleased to announce the release of an upgraded version of the CodeCount toolset called Unified CodeCount or UCC. The software source code and supporting materials are available to the public from http://sunset.usc.edu/research/CODECOUNT/
We would like to thank for the continued support of the CSSE Affiliates for the development and maintenance of the CodeCount toolset. The project has been a collaborative effort of the USC CSSE, the Northrop Grumman Mission Systems, the Aerospace Corporation, and NRO. We would like to thank Mathy Pandian of Aerospace Corporation; Lori Vaughan, Michael Klug, Aaron Shumate, Mike Wheeler of Northrop Grumman Mission Systems; Jill Dunn of NRO, and student contributors for contributions to this effort. We would also like to thank the users of the early versions of the tool for valuable feedback and bug reports.
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
Have We Lost Our Ability to Estimate Software Size?
Following is an update to Galorath’s David DeWitt’s article on software sizing:
Have We Lost Our Ability to Estimate Software Size?
by David DeWitt
“I’ve Been Slimed!” – Dr. Peter Venkman, Ghost Buster
I can clearly remember that day I arrived at work – towards the end of the year 2003 – it was easily before 6am. I was leading a small team tasked with prototyping a test environment for a NASA proposal. I stood there amazed as I watched my two programmers demonstrate a completely reengineered satellite simulation environment. Wait – let me be clear – within only a few days – they rewrote close to 30,000 lines of FORTRAN and another 4,000 lines of assembly code.  How did they do it? They called it “goop.” “The hand cleaner?” I asked – rather befuddled.  No, they were referring a new development language by LabVIEW (National Instruments) called “GOOP” – short for Graphical Object Oriented Programming.
That was the day I decided to stop being a programmer. I was, at my ‘age,” no longer really interested in keeping up with the latest programming paradigms (and vernacular – such as “paradigm”). I decided to abandon the past and embrace my role as a program manager. But now, looking back I wish I had asked a few more questions.
Measuring Failure
In 1995 the Boston, Mass. – based IT project management research and consulting firm The Standish Group released their first CHAOS Summary report. The report quickly became an industry score card for measuring the success or failure of IT projects; due mostly in part to the astounding percentage of failed projects disclosed in the report. The report served as a wake-up call that appears to have been heard – the 10th anniversary CHAOS report announced that the percentage of failed projects had been reduced by more than half. But alas, within a mere five years, the number of failed projects is back on the rise; the 2009 Standish Group CHAOS report indicates that nearly 1 in 4 projects are doomed. But why?
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
Have We Lost Our Ability to Estimate Software Size
I really enjoyed Galorath’s David DeWitt’s article “Have We Lost Our Ability to Estimate Software Size, AKA I’ve Been Slimed”, posted below:
David DeWitt,
“I’ve Been Slimed!” – Dr. Peter Venkman, Ghost Buster
I can clearly remember that day I arrived at work – towards the end of the year 2003 – it was easily before 6am. I was leading a small team tasked with prototyping a test environment for a NASA proposal. I stood there amazed as I watched my two programmers demonstrate a completely reengineered satellite simulation environment. Wait – let me be clear – within only a few days – they rewrote close to 30,000 lines of FORTRAN and another 4,000 lines of assembly code.  How did they do it? They called it “goop.” “The hand cleaner?” I asked – rather befuddled.  No, they were referring a new development language by LabVIEW (National Instruments) called “GOOP” – short for Graphical Object Oriented Programming.
That was the day I decided to stop being a programmer. I was, at my ‘age,” no longer really interested in keeping up with the latest programming paradigms (and vernacular – such as “paradigm”). I decided to abandon the past and embrace my role as a program manager. But now, looking back I wish I would have asked a few more questions.
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
T-Shirt Sizing Software Projects
What a concept. T-Shirt sizing involves gross level estimates of tasks… small, medium large, extra large, etc. to scope the order of magnitude in tasks. It is certainly better than nothing. And could have a place with other manual estimating methods. Rumor is this is used within Microsoft these days.
PS . Microsoft used to send me T-Shirts since we are partners. I haven’t gotten one in a few years.
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
Agile Estimating User Stories
There is an interesting article on estimating agile software with user story points   agile estimating. While the intent of the article avoids the big picture, I think it does a decent job at the lowest levels. Some of its sage advice includes:
When building a size scale, use the powers of two rather than 1, 2, 3: Because business people can grasp the difference between a 2 and an 8 in size better than a 1 and a 3.
Require Attendance of All Developers: Since any of them may end up working on the story.
Redo stale estimates: If the project changes, change the estimates.
Bring “Special Snacks”: This is one I wouldn’t have thought of… The author suggests bringing high quality snacks, such as fresh bakery goods to the estimation sessions to make people happier and more cooperative.
—————-
And a second article on agile software planning poker… Which is essentially a technique to make root level estimating more like Delphi.Â
All these root level techniques share the risks of manual over and underestimating which can actually make a project take longer and cost 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.