Agile Zone is brought to you in partnership with:

Simon lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of "Coding the Architecture" (a website about pragmatic, hands-on software architecture) and the author of "Software Architecture for Developers" (an e-book that is being published incrementally through Leanpub). He still likes to write code too, primarily in .NET and Java. Simon is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Estimating a Software System

  • submit to reddit
(Free Estimation Ebook)

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.

Architecture, design and estimation

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.

Published at DZone with permission of Simon Brown, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)