Analysis Vs. Design
What is analysis? Is there an accepted definition? If you read through the software literature and textbooks, you will find that there are as many definitions of analysis, as there are authors. Ironically, analysis is something we know we must do; and yet have no real definition for.One of the most common ways to differentiate analysis from design is to say that analysis is "what" and design is "how". This sounds compelling at first. Clearly if we can first define "what" we want the system to do, then it will be easier to define "how" the system should do it. Indeed, vast quantities of man-hours have been spent attempting to separate the "what" from the "how". It is not uncommon for a conference room full of people to descend into the interminable argument over whether what we are currently doing is analysis or design.
Arguments like this are common because of the peculiar fact that every "what" is also a "how", and every "how" is also a "what". The arguments cannot be decided, because both sides are actually correct. If we use the "what" vs. "how" definition of analysis and design, then every concept that is an analysis concept is also a design concept and vice versa.
To demonstrate that every "what" is a "how" and vice versa, consider what I am currently doing.
What am I doing? I am writing a blog.
How am I doing it? I am typing on my laptop.
What am I doing? I am typing on my laptop.
How am I doing it? I am moving my fingers to hit keys that correspond to letters that are assembled into words.
What am I doing? I am moving my fingers to hit keys that correspond to letters that are assembled into words.
How am I doing it? The cognitive portions of my brain are putting words together and directing the motor portions of my brain to send signals to the muscles that control my fingers.
I could go on indefinitely. The fact that I could go on indefinitely means that "what" and "how" are associated by an equivalence relationship that leads to a recursive descent into detail. Every "how" become the "what" at the next level of recursion. Every "what" is just the "how" of the level above it. The number of levels is very large, and probably infinite. This means that "what" and "how" are separated by an infinitesimal and are virtually identical.
So, for all practical purposes, if we view analysis as "what" and design as "how" then they are equivalent operations that cannot be separated from each other. All analysis is design, and all design is analysis.
!commentForm
Certainly. Also, analysis could not be really completed without design and vice versa
It seems to me (from your example,) that the What only becomes a How once you zoom one level deeper, i.e. increase/decrease the scale of your vision.
The key, therefore, seems to be in establishing the right scale first. Only then can ew effectively tell the means from the ends. The problems only arise when we try to deal with different zoom levels at once.
From my experience, half of this can be achieved just by calling the things by their real name.
The key, therefore, seems to be in establishing the right scale first. Only then can ew effectively tell the means from the ends. The problems only arise when we try to deal with different zoom levels at once.
From my experience, half of this can be achieved just by calling the things by their real name.
I used to adopt the same simple what/how method to define analysis/design and I ended up to the same conclusion.
In my opinion It would be easier to define analysis as domain exploration (i.e. domain analysis). Here there is no system and so it's meangless to define what to do.
Design, on the other hand, involves WHAT the system must do (Requirements)and HOW the system should do it (Specification)
It is a design phase because when system definition comes into play you are designing not analyzing.
Of course, that's just from my experience.
In my opinion It would be easier to define analysis as domain exploration (i.e. domain analysis). Here there is no system and so it's meangless to define what to do.
Design, on the other hand, involves WHAT the system must do (Requirements)and HOW the system should do it (Specification)
It is a design phase because when system definition comes into play you are designing not analyzing.
Of course, that's just from my experience.
...but my answer got too big for a comment, so I pulled it out to my own blog: http://www.williamcaputo.com/archives/000236.html
At least they have an order before they become interchangeable, which gives us some guidance. For example, I cannot:
First ask - How am I doing it? I am moving my fingers to hit keys that correspond to letters that are assembled into words.
Then - What am I doing? I am typing on my laptop.
vishal
First ask - How am I doing it? I am moving my fingers to hit keys that correspond to letters that are assembled into words.
Then - What am I doing? I am typing on my laptop.
vishal
Analysis is not necessarily the process of defining the what and not the how. Analysis is the process of identifying the what and the how as well as identifying when to stop. The idea of equivalence of analysis(what) and design (how) is based on the premise of indefinite what's and how's. Analysis is the abstract definition of process and therefore both the what and how. Design is the physical manifestation of the abstract definition obtained by analysis and thereby depends on the what and the how. Based on my previous 2 statements I would argue that design start where analysis stops.
From your example above every what can be rephrased with a equivalent how . A rephrasing of you how's follows
What am I doing? I am writing a response.
What am I doing to write a response. I am typing on my keyboard
What am I doing to type on my keyboard? I am moving my fingers to correspond to letters that are assembled as word
My point being, the definition of analysis (based on what) and design (based on how) are not necessarily incorrect, just ambiguous
From your example above every what can be rephrased with a equivalent how . A rephrasing of you how's follows
What am I doing? I am writing a response.
What am I doing to write a response. I am typing on my keyboard
What am I doing to type on my keyboard? I am moving my fingers to correspond to letters that are assembled as word
My point being, the definition of analysis (based on what) and design (based on how) are not necessarily incorrect, just ambiguous
I think what is missing here is the actor, the one who is doing something.
In your case, the "how" is the way things are already done so your "hows" belong to analysis.
Design means doing things in a different way than they are actually done.
Anyway, it's a good practice to start designing throughout analysis to get feedback
from design to analysis. This way, the model constructed during analysis can prove its
value for design early so waste can be reduced to a minimum.
In your case, the "how" is the way things are already done so your "hows" belong to analysis.
Design means doing things in a different way than they are actually done.
Anyway, it's a good practice to start designing throughout analysis to get feedback
from design to analysis. This way, the model constructed during analysis can prove its
value for design early so waste can be reduced to a minimum.
'What am I doing? I am typing on my laptop' -- Does not really capture the requirement.
Requirement (what) could be that I need to write a blog.
Siva
Requirement (what) could be that I need to write a blog.
Siva
1)what are the qualities and objectives of design?
2)how can we plan for the design process?
3)how can we measure objective within the design process?
can you give the answer for this question? tq
2)how can we plan for the design process?
3)how can we measure objective within the design process?
can you give the answer for this question? tq
| 1)what are the qualities and objectives of design? |
| 2)how can we plan for the design process? |
| 3)how can we measure objective within the design process? |
Straight to the point. Pragmatic argument
I agree in general that analysis pertains to the problem, while design pertains to the solution. But as we've already seen in the original blog, the two bounderies between the two are ill-defined. A solution to one is a problem for the other. Even in the case of good classical programming. A specification (problem) is mapped to source code that, once compiled, provides one potential solution. This is now a new problem. How does the source code execute? More specifically, how does the code map into discrete instructions and how should the processor fetch and execute instructions, and pipeline these for efficiency.
But there two fundamental problems to this path of thinking.
1) The second order problem is too detailed, and operates within a deeper scope than the original problem.
2) The second order problem has already been solved! Optimising compilers and highly pipelined CPU architectures do a wonderful job of mapping higher-level source into binaries and subsequently executing these.
To cut to the chase, the problem A vs D problem is actually trivial, but because of its iterative nature, is one that is readily exposed to unnecessary complication. To avoid falling into the pitfall, one must define an upper bound on the scope of the problem that they are trying to solve. It should stop precisely at the order where a solution yet again morphs into a problem, but for which a solution already exists. For example, you're asked to build a system to solve a particular problem. Right from the early stages you realise that you can effectively combine some middleware, a relational DBMS, and some other technology, held together with a little glue J2SE code to solve the problem. Apart from elaborating on the glue, you should refrain yourself from delving any deeper into the high-level building blocks, for these have already been solved.
|Going back to the original blog, the author mentions the original problem, being the formulation of a blog. The other two orders are irrelevant, for their occur intuitively and need neither analysis nor design. I've talked before about the "upper bound" as opposed to the entire scope, because the analysis/design process could be evolutionary, taking place in increments. It doesn't matter how much is performed in each increment, as long as the upper bound is respected.
So keep design to the problem that YOU are trying to solve. All too often system architects and even requirements engineers go one (or two) levels deeper than what they have been commissioned to do. An architect should never have to draw a class diagram - even though this problem is yet to be solved by implementers, this is beyond the scope of architecture. The analysis is then all the understanding of the problem leading up to the design of the solution. Oh and by the way, the design process is not separated from programming. The derivation of source code, aka implementation, is littered with elements of design. In large systems, often one might find themselves implementing from a class diagram, but the latter does not specify intrinsic details of the source code, merely relations, attributes and method signatures. The implementor still has to design the internals of each method, branching, loop structure, e.g. whether to iterate or recurse.
[Emil Koutanov]
Add Child Page to AnalysisVsDesign