Sie befinden Sich nicht im Netzwerk der Universität Paderborn. Der Zugriff auf elektronische Ressourcen ist gegebenenfalls nur via VPN oder Shibboleth (DFN-AAI) möglich. mehr Informationen...
Proceedings IEEE Joint International Conference on Requirements Engineering, 2002, p.215
Ort / Verlag
IEEE
Erscheinungsjahr
2002
Quelle
IEEE Xplore
Beschreibungen/Notizen
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? We identified 17 modules a typical analysis documentation consists of. These are briefly described.