To invent
Introduction to the notion
To design is to invent.
The posture of this modeler is very different to the one who analyzes. It is expected of him/her to imagine one or several solutions to a given problem or a requirement. The characteristics of this activity are:
- Taking into account requirements (which have, beforehand, been formalized and analyzed) or the coverage of a need.
- Inventiveness, applied to experience in the state of the art and its potential.
- Qualitative and quantitative evaluations of the proposed solutions.
Analysis versus Design
The “analysis/design” dichotomy is very familiar in software engineering (and to engineering on the whole). However, recent evolutions (notably in the widespread use of iterative approaches) have led to a blurring of this simple contrast.
Traditional development approaches identified activities (analysis or design) with phases (separation of tasks into units). They respected the waterfall model which arranges activities into specific sequences. Now, it is necessary to distinguish between the two notions, as the same phase can contain both types of activities. Iterative development cycles, often, include both analysis and design in a single iteration. The RUP methodology distinguishes the notions of phases from types of activities, or “disciplines”.
Having said this, it is necessary to eliminate the troublesome connotations that these terms drag along with them. Analysis is perceived to be work that is considered generic or functional, whereas design dives into the details. This is not our approach. Before taking steps in a life cycle, analysis and design reflect alternative behaviors of the same reality.
Messages
- Analysis and Design activities apply to all aspects of the System. The “business” or upstream aspects (semantic, organizational and geographical) are just as likely to be candidates for design proposals as are the more technical aspects.
- Be it analysis or design, a model is not complete until it has been described in detail. This does not forbid the production of generic or incomplete models which correspond to a particular intention (sketches, architecture decisions, etc.).
Comment
This is not really a definition but more a reminder about the importance of the posture and the fact that it applies to all aspects of the Enterprise System.
