Observe and examine without proposing any change
Introduction to the notion
To analyze is to observe thoroughly.
The term evokes breaking down the subject into its finer grained elements and paying attention to details. The posture of a modeler during analysis is characterized by:
- Passivity (she/he does not take initiatives; she/he is content with documenting what she/he observes).
- Attention to detail and exhaustiveness.
- Ability to trace dysfunctions with the aim of providing input for reviews (as-is analysis, auditing).
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.
Comment
- 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.).
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.