In spite of being a de facto standard for analysis and design, UML has some obvious shortcomings: the UML definition is at best semi-formal, the set of result types is far too large and heterogeneous, the tool-support is not satisfactory. If this is true - how do people get on with UML? How do they use it in their every day work? At sd&m (a medium size software company in Munich, Germany) we conducted a study of best practices. The study was restricted to analysis; we considered neither requirements specification (gathering requirements) nor design issues. The aim of the study was to answer the following questions: · What does a typical analysis documentation contain? · Which parts of UML are really used? · What kinds of non-UML documentation is used? Here is the surprising result: We identified 17 modules a typical analysis documentation consists of. These will be briefly described in the following sections. Only 3 out of 17 modules use UML at all. For the other modules, projects have defined their own standards, sometimes supported by cute home-made tools, while text takes up the major part of the documentations.
展开▼
