I have recently been assigned to a Software Development project that involves re-coding an existing PC based program, to a Web based platform. I am aware of a method whereby you can estimate software development costs by estimating the number of source lines of code (SLOC) for a given programming language and then, recalculating this number for SLOC reuse. However, this requires the PM to rely on accurate estimates by the developer. If the PM is unaware of how to estimate the new SLOC, s/he can be somewhat left in the dark.
Is there a method by which PM’s can estimate Software Development Costs? Saving Changes...
Migrating to the web is generally a misnomer. The effort involved is akin to a new project- you save only on the RA phase, and maybe in the testing. I have found doing a Function Point count effective. Please check out International Function Point Users Group, Function Point Counting Practices Manual (Release 4.1), May, 1999. Available at: www.ifpug.org Saving Changes...
Steven BergsteinSenior Program ManagerHingham, Ma, United States
Developing a reliable software development estimation approach is the holy grail of software project management. There are many approaches - ultimately, I believe, that you need to pick something you like and try it.
Then (here's a big leap from what I've seen done in the real world), you need to track actual effort vs. estimated effort and adjust your estimating approach accordingly. Of course, you need to do things like managing scope creep along the way.
Personally, I like to count less ambiguous things than LOCs. I try to quantify the size of an application by estimating the number of pages/windows/screens, database tables, reports, batch programs, interfaces to other systems, shared code modules, etc. Sometimes (but not always) I'll categorize each of the things I count as small, medium or large. Then, I'll take an educated guess at how long it will take to design and then program and unit test each of the things above.
To get estimates for "system testing", I'll use a rule of thumb about the relationship between the size of the programming task and the testing task (I've seen rules that say that system testing is anywhere from 25% to 100% of programming).
Let me reiterate one of my points above: once you build a model like the one I've described above, you need to tune it by comparing actuals to estimates. Saving Changes...
"We are ashamed of everything that is real about us; ashamed of ourselves, of our relatives, of our incomes, of our accents, of our opinions, of our experience, just as we are ashamed of our naked skins."
