<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - decomposition tag</title>
  <link>http://www.codingthearchitecture.com/tags/decomposition/</link>
  <description>Software architecture for developers</description>
  <language>en</language>
  <copyright>Coding the Architecture</copyright>
  <lastBuildDate>Wed, 16 May 2012 08:01:04 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Estimating a software system</title>
    <link>http://www.codingthearchitecture.com/2010/07/13/estimating_a_software_system.html</link>
    
      
        <description>
          &lt;p&gt;
One of the things that we teach people on &lt;a href=&#034;http://www.softwarearchitecturefordevelopers.com&#034; target=&#034;_blank&#034;&gt;our Software Architecture for Developers training course&lt;/a&gt; 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 
&lt;a href=&#034;http://www.codingthearchitecture.com/pages/book/start-with-the-big-picture.html&#034;&gt;we&#039;ll start with the big picture&lt;/a&gt; before breaking up the overall system into &lt;a href=&#034;http://www.codingthearchitecture.com/pages/book/architectural-constructs.html&#034;&gt;a number of different constructs&lt;/a&gt;.
&lt;/p&gt;

&lt;p&gt;
I don&#039;t often talk about the requirements side of the software design process, but it&#039;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&#039;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 &lt;a href=&#034;http://www.codingthearchitecture.com/pages/book/architectural-constructs.html&#034;&gt;systems, containers and components.&lt;/a&gt;
&lt;/p&gt;

&lt;div align=&#034;center&#034;&gt;
&lt;img src=&#034;http://www.codingthearchitecture.com/images/20100713-architecture.jpg&#034; alt=&#034;Architecture, design and estimation&#034; /&gt;
&lt;/div&gt;

&lt;p&gt;
The photos above summarise a software design exercise that I&#039;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&#039;s been a very collaborative exercise where 3 of us have designed the system down to its &lt;a href=&#034;http://www.codingthearchitecture.com/pages/book/components.html&#034;&gt;components and services&lt;/a&gt;, using a CRC card approach. We&#039;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&#039;ve been able to use this approach to decompose the overall problem and put together some estimates as a result.
&lt;/p&gt;

&lt;p&gt;
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&#039;t need to do &lt;i&gt;big&lt;/i&gt; design up-front, but &lt;i&gt;some&lt;/i&gt; design up-front does have its benefits.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>How do you define software architecture?</category>
    
    <comments>http://www.codingthearchitecture.com/2010/07/13/estimating_a_software_system.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2010/07/13/estimating_a_software_system.html</guid>
    <pubDate>Tue, 13 Jul 2010 21:53:25 GMT</pubDate>
  </item>
  
  </channel>
</rss>

