A client recently posed this question (and 4 others) to us - the internal discussion regarding this question is interesting ...
[AD: ]
There are techniques that can be taught - depends on what is meant by designer.
[AB: ]
Yup, agree these can be taught. Being able to break the system down into small enough chunks is the key to both estimation and design
[SM:]
a. Pre-requisite is a component based approach
b. Develop the custom to record estimates and actuals to develop an estimation database
c. Basic guidelines for estimation need to be developed.
[JE ]
At a basic level, because I’m not an expert in estimation:
- You need multiple estimating methods, each one giving a different view of the inputs. I like component based estimates since I’m programmer.
- Having a based architecture / previous similar system to estimate the total work on and in improves the accuracy of the estimate, especially if you can consult the people who worked on it. I know that I can build an environment to host a large, concurrent web service system in about 3 weeks with experienced staff, because we’ve done it before and we know the high-level architecture. From knowing that I have to then work through the deltas for a specific project to make sure my design fits, and all the requirements are met. After that we are estimating the build of the business functionality in the system independently of the plumbing.
- You should estimate pragmatically, apply the appropriate level of rigour given the input – there’s no point doing a class level estimate on a back-of-the-envelope design
- Having different people with equivalent skills do the same estimate, on the same input, in parallel is a great way to check the process and look for things the initial estimator missed
- It’s important to learning from prior experience – review an estimate in the context of work that was done to test the accuracy of the initial estimate and find out where the deltas are (but I think this kind of project post-mortem is important in the CMMI model?)
[SW ]
Experience and metrics.
[MC:]
I tend to use a component based approach for technical estimates. The best estimates are ones that are converged on from a few different directions though. Component estimate, functional estimate (FP Count) & realistic project schedule estimate (lets you map out overheads like keeping a PM or Architect on board ;) ).
For a component estimate for a single system, I like to break it into two distinct groups. Infrastructure Components & a common pattern.
The common pattern is basically the thing you’ll do over & over again in your application. i.e. How you do your CRUD. Basically you can estimate the CRUD pattern once (e.g. UI + Services + Data Access = 8days), then multiply across the number of times you’ll need to repeat it. A BDM or UI Nav Model helps immensely at this point.
The Infrastructure components are those that help you perform your CRUD, or are needed for other specific purposes in the app. These are your more traditional MeNtOR “components”. Logging, Auditing, Security, Data Access Frameworks, Queuing Mechanisms etc all fall into this category. Actually, anything that isn’t basic CRUD falls into this bucket. For these you need to estimate individually, and this comes down to experience with similar components in the past. Real numbers from previous projects are very useful here.
As an aside, these are also things that are good candidates for re-use across projects if they’ve been built with it in mind.
Finally, don’t forget all of the ancillary things the dev team will need to do (allow time for your process). A good project plan template will help not forget these. Things like catering for code reviews, setting up your build environment, documentation & release management costs can all really impact a schedule that was only put together with the pure cost of building the software in mind.
Carl Rogers - Principal Consultant & Process Development Architect