Nur die Frage, ob das was der Teamstudio Analyzer ausspuckt, wirklich ausreichend als Doku ist.
Das kann man sicherlich durch ein paar weitere Sachen ergänzen.
Und an der Dokumentation krankte es oft im Notesbereich.
Das können imho auch einfach adhoc Diagramme nach eigenen Regeln sein.
Modellieren ist ja sowas ähnlich wie Dokumentation, nur eben ex-ante und nicht ex-post.
Z.B. wird von den wahren Modellier-Freaks gesagt, dass nicht jedes Modell UML sein muß, sondern dass ad hoc Modelle sehr hilfreich sein können. Ich benutze z.B. für eine Sammlung von Notes-Gestaltungselementen für ein generelles tif-mit-xml-Deskriptor Archiv-export-Tool (die auch andere in ihre Datenbanken tun können) ein paar mit Visio erzeugte Diagramme. Versuch mich dabei in die reinzuversetzen, die das nutzen sollen. Diese Dokumentations-Diagramme sind Weiterführungen von Modellen, die ich für die Entwicklung benutzt habe.
Der Vorteil von einem mehr model driven Ansatz (den ich auch noch nicht so richtig draufhabe) ist, dass aus den Modellen im Laufe des Projekts durch eine geringfügige Transformation Dokumentation werden kann. Die Software Factories Schule geht ja sowieso davon aus, dass irgendwann endgültig aus Modellen Code generiert wird. Das funktioniert natürlich an vielen Stellen noch nicht.
Aber die Idee, dass Artefakte im Projektlebenszyklus in die nächste Stufe einfliessen (Modell -> Code oder Modell -> Dokumentation) halte ich für richtig und gut und dürfte auch in gewissen Grenzen für Notes anwendbar sein.
Was ist die Intention von Dokumentation?
Den unterschiedlichen stakeholdern (Weiter-)Entwicklern, Administratoren, User, Projekt-Management einen Überblick über die Anwendung zu liefern. Dafür ist Teamstudio Analyser nicht ausreichend.
Gruß Axel
Thema: Dokumentationstool für Eigenentwicklungen gesucht (Gelesen 4859 mal)