Betrifft mich aktuell nicht, aber auch ich habe schon „fictitious documentation“ verfasst:

Fictitious documentation refers to documentation that fails a lie detector test but which passes the project manager’s approval. (zum Artikel)

Idealerweise entspricht die Dokumentation dem Ist-Stand; realistischerweise ist regelmäßig ein Soll-Stand abgebildet, da z.B. nur eine unvollständige Software-Vorversion verfügbar ist. Auch das Verschweigen bestimmter Eigenschaften (besonders solcher, die potentiell Benutzer verärgern) ist nicht selten.

Der zitierte Artikel bezieht sich primär auf echte Bugs und die Frage, ob diese beschrieben werden sollen. Hier findet sich eine Stärke von Open-Source-Systemen – da für diese niemand Geld zahlt, ist es üblich, z.B. bei Modulen ausführlich zu warnen, wenn bestimmte Einschränkungen vorhanden sind. Bei Kaufsoftware dagegen, die zumindest scheinbar einen stabilen, geprüften, fehlerfreien Stand liefern soll, werden Bugs lieber nicht erwähnt, wenn es sich vermeiden lässt…

Share
© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha