About SW-Quality Safety SW-Entwicklung UML Nachschlagen Programme
Q-Kriterien
Basics
Prozess
CodingRules
SourceCode Metriken
ISO9000 und SW
Vereinfachung Abstraktion Akzeptanzprobleme
 
Vereinfachung hat Akzeptanzprobleme Was läuft falsch:
Ein Beispiel: 
Ein Consultant entwirt im Auftrag eine Software-Architektur für ein Datenbankauskunftssystem. Er entwirt im Kopf ein kleines Bild, welches den Ablauf und das GUI darstellt. Er weiß, dass das System trivial ist und wirklich nichts neues darstellt. Der Tagessatz des Consultant ist 1000€ und er braucht dafür 7 Tage. Um seine „hohen“ Kosten zu rechtfertigen verfasst  er eine Dokumentation, mit zeitgemäßen UML Diagrammen und vielen Fachbegriffen. Er übergibt dem Auftraggeber ein 70 Seiten starkes PDF Dokument. Dieser ließt die ersten 10 Seiten und gibt dann dieses Dokument an die Softwareentwicklung weiter. Das Softwareprodukt wird in 8 Wochen festiggestellt und dem Auftraggeber präsentiert. Diesem Missfällt dies und jedes und es fehlt eine wichtige Funktion. Die Software wird angepasst und ist nach weiteren 3 Wochen im Einsatz. Sechs Monate nach der Installation hat noch kein Anwender das System genutzt, alle finden das ältere Verfahren besser und verwenden deshalb dieses. 
  • Der Consultant meint viel Papier liefern zu müssen (Seitenzahl = Qualität = Preis).
  •  Der Auftraggeber meint viel bekommen zu haben.
  •  Im Prinzip reden beide aneinander vorbei. 
  •  Der Consultant wird also, wie früher der Programmierer in Lines of Code, am Umfang seines Textes gemessen. Am obigen Beispiel erkennt sicherlich jeder, dass es besser wäre, der Consultant hätte eine DIN-A4 Übersichtsskizze und einen GUI Prototypen angefertigt. Diese Übersicht hätte der Auftraggeber innerhalb 10 Minuten verstanden und das System hätte den späteren Anwendern erklärt werden können. 
  •  Bei der Vertragsunterzeichnung sollte schon der Umfang festgelegt sein. 
Weniger ist oftmals mehr!...
©; created Mon Aug 07 22:31:53 CEST 2006; eMail