[linux-l] Dokumentenspeicher

[Volker Grabsch]

On Wed, Oct 04, 2006 at 07:04:46AM +0200, Norman Steinbach wrote:
> >>Vielleicht sollte man die Dokumentation durch geziehlt ohne 
> >>Programmier-Hintergrund ausgewählte Beta-Tester vornehmen lassen?
> >In dem Moment sind schon alle Züge abgefahren. Sicher ist
> ?? Wie kann ich eine Dokumentation (=Benutzerhandbuch) zu einer Software 
> schreiben, bevor diese geschrieben ist?

Indem ich mir *vorher* Gedanken mache, und nicht wild drauf los
schreibe, um im Nachheinein (beim Vorführen der Software) festzustellen,
dass die Hälfte davon nutzloser Murks ist.

Bei "Dokumentation" muss man natürlich immer aufpassen, wie Peter
schon schrieb. Es gibt mehrere Dokumente. Vom eher groben Lastenheft
zum feineren Pflichtenheft bis hin zum späteren Administrations-
Handbuch und Benutzer-Handbuch. Diese Dokumente verändern sich natürlich
ebenfalls mit der Zeit. Sie sind genauso

> >ein riesengroßer Nachteil ist, dass die Dokumentation in
> >solch einem Fall nicht mehr die Anforderungen widerspiegelt,
> >sondern die Funktionsweise der Software. 
> Sollte sie das nicht? Oder verstehen wir unter Dokumentation etwas 
> anderes?

Natürlich müssen beim einem Release auch die Bugs dokumentiert
sein. Aber eigentlich sollte man erst dann releasen, wenn sich
das Programm so verhält, wie man ursprünglich wollte.

Wenn man ein anderes Verhalten *will*, dann ändert man idealerweise
erst die Dokumentation, vermerkt vielleicht noch, dass dieser
Teil intensiv getestet werden muss, bis alles *wirklich* so läuft,
wie es da steht (also wie es sein soll).

Für dieses "vorher Dokumentieren" gibt es gerade in großen Entwicklungs-
Umgebungen viele gute Gründe. Eine Bug-Tracking-Datenbank ist übrigens
auch nicht verkehrt. Abstrakt betrachtet könnte man sogar jeder in
der Doku beschriebene, aber noch nicht implementierte, Feature als
Bug auffassen. Dieser Bug wird "behoben", indem besagtes fehlendes
Feature implementiert wird. (Natürlich hat ein Bug vom Typ "fehlendes
Feature" viel geringere Priorität als ein Bug vom Typ "Programmier-
fehler".)

> >Das heißt, auch Bugs,
> >Denkfehler, etc. sind mit Dokumentiert, aber als Funktionsweise,
> >nicht als Fehler.
> Hey, das haben große Softwarekonzerne doch inzwischen Kultiviert: It's 
> not a Bug, it's a Feature! undsoweiter...

Ja klar. Aber wir sprachen hier doch davon, "wie's sein soll", oder?

Dass sich jemand auf seinen Elfenbeinturm verkriecht, irgendwas baut,
was er "cool" findet, in dieser Zeit mit niemanden darüber redet, und
am Ende von der Welt ein großes Lob für sein Produkt erwartet, ist
doch genau das, was wir nicht wollen, richtig?

> Habe auch mal von einem Windows-Entwickler gehört, dass es z.B. 
> schwierig sei, ein Binärkompatibles OS zu Win (ReactOS) zu basteln, weil 
> die Entwickler von Win-Anwendungen sich die Bugs ebenfalls zu Nutze 
> machen...

Jep. Sowas nennt man "bug for bug compatibility". Im Ernst, einige
Systeme *müssen* das tatsächlich können. Hier ist der Programmierer
an vielen Stelle gezweungen entgegen der Dokumentation zu arbeiten,
und es ist einer der unangenehmsten Aufträge, die man als Programmierer
IMHO haben kann.

Aber gerade  in solch einem Fall ist es sinnvoll, erstmal die Original-
Dokumentation zu nehmen (z.B. die Win32 API) und dort alle Bugs, die
aufgefallen sind, zu notieren. Denn gerade in diesen "schwammigen"
Gebieten ist es für Entwickler ungeheuer wichtig und erleichternd,
wenn sie sich an etwas fest halten können.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR