Estimating a Software System
Start by decomposing the big picture
One of the things that we teach people on our Software Architecture for Developers training course is how to design software if all you have is a set of requirements and a blank sheet of paper. The approach that we present is based upon the way that we work ourselves, where we'll start with the big picture before breaking up the overall system into a number of different constructs.
I don't often talk about the requirements side of the software design process, but it's *really* important that some analysis is undertaken to understand exactly what needs to be built and why. I typically gather a first draft of the major requirements and, if the domain is new or complex, I'll additionally do some high-level domain modelling to flesh out the business concepts. Only then will I dive into the software design process, identifying the systems, containers and components.
The photos above summarise a software design exercise that I've been doing over the past couple of days. As it turns out, the business domain here *is* fairly complex but we needed to understand enough about it in order to be able to estimate how much it would cost to build a bespoke system to meet the requirements. It's been a very collaborative exercise where 3 of us have designed the system down to its components and services, using a CRC card approach. We've probably spent about a day looking into the business domain/requirements and the same designing the system. The project owes me £4.68 for the index cards and Blu-Tack that we used, but we've been able to use this approach to decompose the overall problem and put together some estimates as a result.
While you *can* estimate a software system top-down from the big picture, I find it easier and more accurate to decompose the overall problem into a number of logical components/services and estimate bottom-up. You don't need to do big design up-front, but some design up-front does have its benefits.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)