Subscribe via RSS

Connecting the Dots Between Analysis and Design

Filed Under Software Process

Most software teams seem to lump together the terms Analysis and Design into one pre-development phase. This is unfortunate because with enough effort in first determining what you wish to build (aka Analysis) it is possible to understand the domain enough not to need up front architecture (aka Design).

I find this much like a children’s connect-the-dots puzzle. For example, if each user story (or requirement) is flushed out ahead of time, it might be possible to view and understand the entire domain without connecting any lines.

Elephant No Lines

Understandably, it may not be possible to completely comprehend the domain solely on user stories. In essence, the definition of design or prototyping – connecting the minimum number of dots together to understand the full picture.

Elephant

Determining what needs to be built is the hardest part of development. Now that the development team has a shared vision of what needs to be accomplished, they can fill in the implementation with relative ease.

Elephant with Lines

This process, while simple, still takes a lot of maturity to accomplish. Some pre-develoment teams attempt to solve the entire puzzle at the same time of gathering the requirements. Attempting to solve a larger puzzle with only a subset of the information is only an exercise at best. Lack of information, misinformation, and unorganized information may all start leading your team to start drawing pictures of the domain that do not represent the true domain.

Elephant Partial

Do not fall prey to Analysis Paralysis; sometimes good enough has to be good enough. Equally as dangerous is false starting by assuming that you have enough information to act upon. Remember that being agile does not shield you from prematurely drawing a picture of a horse’s ass instead of an elephant.

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.

Comments

6 Responses to “Connecting the Dots Between Analysis and Design”

  1. Russell Ball on October 29th, 2007 6:36 am

    Ah, the classic children’s connect-the-dot analogy. Brilliant. It not only provides an accurate depiction of BDUF vs correct agile vs premature agilization, but it also gives us great insight into what kind of hobbies you engage in during your free time…:-)

  2. Jugimaster on October 29th, 2007 9:05 am

    Hi there.

    I just found your blog.

    I like it 🙂

  3. Jeremy N on October 29th, 2007 12:53 pm

    Separation of finding out what the problem is and trying to solve the problem always seems to be a difficult line for technology folks to see.

    According to Men are from Mars Women are from Venus it is a man issue altogether (www.marsvenus.com).

    But with that said this is where I think an experienced software developer, project manager, or business analyst really earn their money as we have already made those mistakes or learned from others who have.

    As experienced professionals we need to push back on the madness that force projects into a corner where the only possible outcome is failure. In my consulting jobs I notice way to many times when totally irrational behavior is not only accepted but often promoted! The question begs to be asked, how much further would we be ahead if we valued experience by LISTENING to it?

  4. Tales from the SharpSide on October 29th, 2007 5:49 pm

    Links from the Sharpside [10.29.07]

    Links from the Sharpside [10.29.07]

  5. dg on July 29th, 2010 10:35 pm

    Design is not architecture. This blog is full of fail.

  6. Priyank on September 7th, 2010 8:42 am

    Kindly share if any more datum is there ???

Max Pool - © 2024 - {codesqueeze}. Sycorr Banking Solutions