Where can you find published metrics which can be used to estimate software development projects?
I need to create some high level top down estimates for a series of projects. The technology stacks will be microsoft based. All the projects are replacement systems so I have access to stats such as number of screens, reports, tables, LOC, etc.
Clarification added June 10, 2008:
I should add that we are independently getting estimates from the developers plus building up metrics accross existing projects for future use. My attempt to use published metrics is purely to "verify" the different sources of estimates.
Answers (6)
You need historical data from the team that will be building your software, especially if you don't intend to have the people doing the work provide an estimate. I can't tell from your question if you have this data already.
That being said, LOC, screens, reports, are, at best, normalizing measures and do not translate into hours.
Your best bet is to get estimates from the people who will be doing the work, and to break down the work into estimable chunks.
Links:
GianFranco A
International Business Development Vice President at Elsag Datamat S.p.A.
Best Answers in: Project Management (2), Software Development (2), Conference Planning (1), Government Contracts (1), Government Services (1), Offshoring and Outsourcing (1), Property Law (1), Organizational Development (1), Product Design (1), Enterprise Software (1)
A commonly used method to estimate the complexity (or cost) of an IT system is based on the "function point" analysis. This methodology (I have attached a link to the wikipedia page describing it and containing also some useful resources) is independent from the IT base-technology and can therefore be used to measure any kind of software, simply analyzing the screens, data tables, etc.
We use this methodology when estimating the development of new systems but also the re-usage of existing pieces of software.
There are also alternative methods, but they depend on the specific software product/technology underneath.
Let me know if you need more info on this subject.
Links:
Screens, reports, and LOC are metrics (at least for desktop application). But coefficient which gives you man-days from number or reports depends on the project and on the team. So you can collect metrics you have indicated to verify future estimations.
For me LOC is not a metric for new project since I do not know how many LOC it will require, but I very probably know number or reports, forms etc it requires and based on this I can compare new project with one already implemented.
In addition see the link I've attached, probably it helps you to process your metrics.
Links:
Richard Z
President at ZULTNER & COMPANY
Best Answers in: Project Management (8), Software Development (3), Planning (2), Quality Management and Standards (2), Organizational Development (1), Manufacturing (1), Market Research and Definition (1), Engineering (1), Product Design (1), Computers and Software (1)
If what you are looking for is to get "better" estimates for software projects, there is an alternative approach you might find interesting. Getting better estimates is the typically approach, but there are other approaches...
In Critical Chain Project Management (CC PM), you use expected durations (in the statistical sense) that are 50% likely AND estimate the variation of those estimates -- instead of just using the traditional high confidence durations (about 90% likely). This allows you to explicitly plan and manage the variation (risk) of your estimates. This means that accurate estimates are not required -- as long as the estimates are unbiased (just as likely to be low as they are to be high) we can define a buffer to "absorb" the variation (the estimation error) and assure the completion of the project on time -- even though none of the estimates were accurate. (And you can compensate for bias as well... )
The advantage of this is that even with excellent historical data, the variation for even routine tasks can be minus 30% and plus 80% -- or more. So even if on average your estimates are right on, the variation can kill you when it comes to project deadlines. So managing this risk explicitly can have major benefits.
Eli Goldratt's business novel is an interesting introduction to this approach.
Links:
I happen to be writing on this subject right now for the online version of Baseline Magazine. There are problems both with classic metrics (such as LOC) and with developer estimates ("We're 70% done!"). My first two columns deal with the problems and risks of metrics. But you appear to be heading in the direction of the solution I suggest (instrumentation and heuristics). ..bruce..
Links:
Madhusudhanan A
Assistant Vice President at GCI Solutions Private Limited
Best Answers in: Staffing and Recruiting (1), Exporting/Importing (1), Offshoring and Outsourcing (1), Telecommunications (1)
The process of estimating effort, normally is a two step process :
1. Estimate the complexity of the system using a platform neutral counting technique. Function Point Analysis uses data (ILFs, EIFs etc.) and functional complexity (EI, EO, EQ) along with GSC (General System Characteristics) to arrive at a platform neural size count. Function point analysis gives a platform neutral size count of the application. The unit of measure of this size is function points. The link given by
GianFranco Abbrescia on FP can be referred for this.
2. Use either internal productivity measures or published productivity numbers (based on empirical research over a number of projects) on various technology platforms to arrive at the approximate effort. The productivity numbers will be in terms of Function Points / Person Month by technology platform. Caper Jones table was available widely before, but it looks like that they have changed over to a one-time fee based subscription model now.
Hope this is useful ...
