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.
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.
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.
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.
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.
Why Do Estimation Webinar With Geoff Hewson and Dan Galorath
I have had a good time developing a webinar with Geoff Hewson of the Software Productivity Center. It should be very informative and hopefully entertaining as well.
Register by clicking
Date and time: Tuesday, March 10, 2009 8:30 am
Pacific Daylight Time (GMT -07:00, San Francisco)
Description: Software estimation, planning and control can be keystones to successful projects. Companies that estimate strategically are able to zero in their projects so they deliver to business targets. Despite this many treat estimation as a black art or worse – a guess.
Dan Galorath and Geoff Hewson will explain the key concepts that drive successful software estimation in support of planning and managing successful software development and maintenance projects:
1. Decisions and deliverables needed to design estimation procedures tuned to your organization.
2. Guidance in setting up the infrastructure you need to realize the most benefit from your new estimation capabilities.
3. Establishing a “negotiating culture” to allow you to deal effectively with the results of your estimates and focus projects on business success.
SEER for Software concepts will support the discussion.
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.
Dealing With Generated Lines of Code
We have gotten several questions recently on how to estimate using lines of code when the lines are generated, that is there is a preprocessor that allows specification of the solution and the code is automatically generated to implement the solution.
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.
COSMIC Function Points In SEER
SEER for Software supports the COSMIC function point estimation counting rules as well as traditional IFPUG and others and has done so for some time. While this BLOG does not cover religious issues it is good to see how every sizing method is supported. When reviewing an estimating process I see that we added a second COSMIC sizing method for COSMIC Function Point “Data Movements” And using the data movements provided estimates just about spot on to actuals. It is so important to be able to deal with any sizing method that users might come up with. That is just one more reasons why SEER for Software lead in project estimation, planning and control. Continuous product improvement by a development and analyst staff who understand the domain. Thanks to Galorath’s Ton Dekkers for his involvement in COSMIC and in making the alternate approach work so well with SEER.
Supporting the numerous methods of software sizing is critical to providing a full service solution.
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.
Function Point Simple Introduction
I keep meaning to post Galorath’s Ton Dekker concise introduction to Function Points. Ton is an expert in IFPUG Function points as well as COSMIC Function Points and a host of other functional sizing measures. I always appreciate Ton’s simple and clear approaches.
Learn how Galorath can help with function point estimation.
| http://www.galorath.com/wp/function-point-simple-introduction.php |
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.
How Galorath Made Use Case Points Viable For Accurate Estimating
Use case points provide a measure of size based on Use Cases, a natural artifact of the software process. The original concept was developed by Objectory AB (now part of IBM Rational Software.) There have been many detractors of use case points including Rational Software itself and USC. The Galorath team approached Use Case estimating with a number of approaches. Lee Fischman, who led the project came up with the concept of Normalized Use Cases (NUCs), a new metric based on Use Case Points He also had Galorath’s Dr. Tarbet set off to create better results from Use Case Points. Use Case Points are based on:
- Based on the number of actors and transaction for each case.
- Categorization into simple, medium and difficult.
- Linear combination of weighted counts
When Dr. Tarbet finished his analysis he obtained an Adjusted Correlation Coefficient (R2 ) = 0.984802, showing an exceptional value to the enhanced Use Case Point method.
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
