What is the focus of analysis: problem or solution?
This post is my shifted comment on Rafael’s post & discussion.
Rafael talks about analysis vs design in the software life-cycle, where problem is the requirement and solution the software to build.
First of all, IT or not, any answer makes sense as an answer only if it answers a question.
So, a solution is a solution to a problem. Still generally speaking, there are almost always several solutions to a problem. And the problem itself, as a question, is almost always a viewpoint on a problem area, or even I’d dare to say: the problem, taken as a problem for which we need to find a solution, is an abstraction of a problem domain.
But even if we details the problem at very fine-grained level the solution is not the problem, it’s a different thing. The solution is something concrete. A software as a solution is something executable (even if it’s bugged).
So: the problem is substantially an abstraction, while the solution is substantially concrete. However, the solution highly depends on the problem, by construction. So we need to weave(2) something concrete to something abstract.
Analysis often means focusing on the problem, while design means focusing on the solution. But how do we focus on the weaving(2) from an abstract problem to a concrete solution?
To my opinion, what is interesting to model in IT life-cycle is this weaving problem<>solution. The corresponding task is by nature an “analysis & design” work. In the “MDA like”(1) successful cases I know, this work is held by a ~PIM(3) model which takes into account business analysis and technical architectural design (which both need to adapt themselves to each other).
I don’t believe that “analysis & design” may generally be treated as a pure transformation from the problem to a solution, even with successive refinements. And my feeling is that when we find some occurrence of such an automated transformation the problem is, in those cases, sort of a “reverted solution” problem: a problem not issued from real life but issued from existing or projected IT life.
By the way, executable models are, by definition, models of a solution.
So, my answer is:
– We need a problem/solution weaving(2) which may not be derived from an analysis model, nor from a design model. Executable models or not. OO approach or not.
– Keeping analysis and design separate is a very well mean not to succeed in IT projects!
(1) Thanks to Ed Seidewitz for pointing out the original “MDA Guide Version 1.0.1” whose 80 printed pages are ready to be read during my next TGV travel to Nantes ;D
(2) I replaced “mapping” by “weaving” after TY comment. See my response to TY.
(3) I read the MDA Guide. More to come!
Featured image taken from http://f3fundit.com/blog/its-all-about-the-v-word-so-forget-the-problem-ideology-and-create-value-instead/
17 comments on “What is the focus of analysis: problem or solution?”
Leave a reply to caminao Cancel reply
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
IT Modernization < V. Hanniet 
Hi Vincent,
My understanding is that there are three very different problems to be solved:
– A business problem, eg how to value an asset or compute a missile trajectory.
– A functional problem: how the system could help solve the business problem.
– An operational problem: how the system could help different users solving interelated business problems.
Analysis deals with functional solutions, design deals with oprational ones.
Rémy
Hi Rémy,
… And business analysis deals with the business problem! At first glance, I guess I agree with this problem decomposition.
Hi Vincent,
Agree on many points. Executable UML/Shlaer&Mellor/MBD don’t seem to be interested in representing the problem explicitly – that is out of scope – instead, the goal of analysis (OOA) is to build a solution defined in terms of the problem space (but yet a solution). That was news to me, and that is why I wrote that post.
That is ok with me. But I feel a need for representing the problem in a executable manner, so we can ensure an OOA model satisfies the requirements. One easy way to address that is to use automated tests at the level of models (that is what we are doing in AlphaSimple – will blog about that soon).
Won’t that address the need you see of mapping problem solution?
Hi Rafael,
Executable problems sounds weird to me. A problem, taken at problem level, is not a solution (maybe this problem is a solution vs a meta-problem but that is out of scope).
So I don’t think that a problem all-in-one-model should even be tested. However, taken Rémy’s words, if we decompose the problem we maybe can find a part of it, name it operational problem, which is what you seek for. Maybe also, this operational problem is the part to weave (see TY comment) with the solution design to build the modeling level I seek for.
But the story don’t tell us how to extract the operational part from the whole problem itself!
Hi, Vincent
I very agree you opinion that “We need a problem/solution mapping which may not be derived from an analysis model, nor from a design model. Executable models or not. OO approach or not.” And further, I don’t even agree use ‘mapping’ to refer to the correspondence between problem and solution, especially on the context where has many voices of model-transformation.
Hi TY,
I fully agree with you, mapping has too much meaning in MDE field. I change it to weaving.
I think mapping is a kind of weaving. More specifically, we often call “mapping” simple types of weaving: frequently one to one matching, or even one to many matching. But weaving complexity stands in many to many matching. The kind of matching that can’t be reasonably decided by pure automation processes. And the “mapping” I talk about is of this very weaving nature…
Well, ‘weaving’ sounds better then ‘mapping’, and I think, that is the nature of ‘design’, as a whole, it had to be done by human-beings, unless the computer has reached a human like intelligence.
BTW, I think, in any case, whatever, it’s a good thing that a solution or a model (of design) somehow detailed in some way can be executed or auto-transformed – nevertheless, this is not a substitute for or direct addressing the ‘weaving’ between problem domain
I fully agree on your remark on necessary human-being intelligence.
I agree on the propriety “able to be executed/transformed” we should be attached on any design/model of a solution.
However, this does not mean that the result of this transformation is an “end user application”. Because the model of the solution is generally not expected to hold all the solution description. I think, again, it should however hold all the “architecture” (to be defined more precisely) decisions, both functional and technical.
Executable models are an extreme sample of a solution model which holds all business & functional decisions, and then may be executable as an en user application. I keep on not seeing this way as a productive one, nor reachable one, for 99% of IT project cases.
I’m not sure if my statement in English is enough correct :-p
I always had some doubt to so-called ‘Executable Model’, although it seems an inevitable result in the logic of MDA, but it also like a trap: if the models are fully executable or transformable, what are the difference with programs? Why we must say they’re models but not programs? To rise the abstract level is necessary and useful but not need to rename programming to modeling… From programming to visual programming, to modeling (visually), to modeling (textually and to be executable), it seems somehow return to the origin, isn’t it?
Sure, executable models come directly from the OMG’s MDA logic. And for sure, executable models promoters, and Ed Seidewitz among them, say that modeling may be a way of programming. Just as if executable modeling was a kind of AGL. And may argue that what we call programming today, may have been seen as modeling yesterday: if assembly language is a programming language, may we call C a modeling language?
I don’t think so. Further than that, I think that merging modeling and programming is a vicious bias that does not serve MDE (and I am still asking myself what goal it serves ;D). Not that it is scientifically wrong, but it just doesn’t make sense for leading IT market toward more MDE.
Pointer: Ed’s comments on this post https://vhanniet.wordpress.com/2011/04/29/mdamdd-model-is-not-code/
I’m writing a post about this topic:-)
Is the AGL you metioned “A Graphics Language” from HP?
Sorry, not AGL but CASE Tool. AGL (Atelier de Génie Logiciel) is the French acronym for CASE : Computer Aided Software Environment.
Looking forward to you next topic 😉
Pingback: Models: Execution or More « THINK IN MODELS
Briefly, it depends on the problem:
– Business problem, eg how to value an asset or compute a missile trajectory.
– Functional problem: how the system could help solve the business problem.
– Operational problem: how the system could help different users solving interelated business problems.
I would say that [requirements] analysis deals with the specification of functional problems. Due to the necessary functional consolidation and integration of the different domains and business processes, it usually entails some abstraction.
fully agree to “Keeping analysis and design separate is a very well mean not to succeed …”
keep asking myself if the 140 chars restriction in twitter is just a technical constraint sold as requirement ;o)
Very nice sample of mixed-up requirement! Both technical and functional… And nobody can tell today if it still is the best option ;D
Pingback: I read the MDA Guide v 1.0.1 « Vincent Hanniet * IT Modernization