A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am just throwing this out there for opinions. Looking for an interesting discussion.
Monday, September 11, 2006
There isn't one ... it's a continuum!
There are however a lot of companies that create a boundary and throw the analysis over the proverbial wall. So when the Architects and Systems Engineers think their done, it's time for the Software Engineers to start designing.
My personal favorite is this:
Analysis - Specifies the problem domain.
Design - Specifies how the software solves the problem.
The beauty of agile development is short-cycling the interations of this process. The pitfall of agile development is that there are often interdependencies that need to be considered as a whole and it much more likely you'll focus on too small a problem domain.
Analysis: "Complex problems are made simpler by separating them into more understandable elements", says http://www.google.ca/url?sa=X&start=9&oi=define&q=http://www.ojp.usdoj.gov/BJA/evaluation/glossary/glossary_a.htm
So, analysis is subdividing a problem into its component elements.
Because you might have different software components to solve different parts of the problem, there is therefore some overlap from the problem analysis into the solution space.
But I'd say that design is more like synthesis than analysis: it's working out how to assemble, fit together, the software components.
The difference between analysis and design is equivalent to the difference between having sex and raising a child.
Tuesday, September 12, 2006
When I first started "real" programming, this was one of those quesy areas for me. It felt quesy because everyone assured me there was a clear and distinct boundary, yet I could never find this boundary for myself.
Whenever I got beyond the most basic analysis (i.e., "Well...we probably needs a datasource and a UI"), it's basically inevitable that I start thinking at least partially about how to implement it.
Maybe that's an example of "premature" optimization or whatever, but I simply cannot cleanly separate analysis and design. When designing something, your experiences with implementing things will *inevitably* be guiding your thinking.
I believe there is clearly a symbiotic relationship between analysis and design.
For me, they both work together in my own mind as I'm reviewing the specifications for an application.
I think about how the information can best be presented to the user through the UI (design) while simultaneously thinking about what kind of programming protocols by way of functions and procedures will be needed (analysis). I subsequently then begin to disaggregate the functions and procedures (in my own mind) into component elements of functionality such as With statements, Case Select statements, If statements, and then begin (in my own mind) to rebuild the app from the code up.
All of this is done in my head while I'm reviewing specs or while I'm in meetings with project managers.
It's quite a natural process, the result of which is a UI that just "works" when it comes time for implementation during the development process.
If you think about it, the specifications quite naturally drive the UI design and the code of an application. In others words, once due diligence of analysis and design have been performed, the UI and its associated code begin to fit together like a puzzle....natural, effective and very powerful.
Oh, they are two sides of the same coin. Analysis involves looking at a problem in terms of the design of the current system or the description of what the system will accomplish. Whereas the process of design is really explaining how a particular set of approaches to a problem hold up well under analysis.
Problem: I'm overweight:
Analysis: I'm overweight because I eat bad food and don't exercise
Design: If I eat better and exercise, I won't be overweight.
As you refine, it becomes more apparent that you are really just talking about analysis versus design in terms of past versus future causality.
Analyis: The high content of fat in my stomach derives from the fast food I eat, as evidenced by studies.
Design: A reduction in fast food consumption would result in reduced fat in my tummy, as predicted by experience.
What's REALLY important is that you actually DO the analysis/design to the level of detail warranted by the problem. If you skip right to implementation, you're in trouble.
Problem: A bridge would be nice here
Implementation: Let's go get some concrete!
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz