Over a million developers have joined DZone.

Estimating a Software System

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

(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.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Simon Brown, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}