Designentscheidungen und Designbewertung

„Es gibt keinen Königsweg“. In der Softwareentwicklung lassen sich die Aufgaben auf mehrere Arten lösen. Welcher Lösungsansatz sich nachher durchsetzt ist eine Designentscheidung. Vor der Designentscheidung steht die Designbewertung (oft werden Entscheidung und Bewertung von unterschiedlichen Personen durchgeführt), diese beschreibt die Vor- und Nachteile der Lösung bezogen auf die Aufgabenstellung.
Die Designbewertung muß sich ggf. auf Annahmen stützen. Die Beantwortung des Kriteriums „Wie gut deckt die Lösung die in diesem Jahr wahrscheinlichen Erweitungen ab und wie lange dauert die Umsetzung?“ beinhaltet neben der technischen Bewertung (also dem Ergebnis) auch Annahmen über die wahrscheinlichen Erweiterungen.
Ist die Designentscheidung getroffen, so muß sie an das Entwicklungsteam kommuniziert werden. Hier bietet sich UML an, falls das Entwicklungsteam UML beherrscht. Ansonsten kann auf Text, Pseudocode oder Codeschnipsel zurückgegriffen werden.
Die Designbewertung kann das Design nicht im leeren Raum betrachten, sondern muss immer die Aufgabenstellung berücksichtigen. Ein Beispiel: Zwei Alternativen, welche ist (ohne Betrachtung der Aufgabe) besser?
Alternative 1

Alternative 2
Früher (direkt nach dem Studium) hätte ich die erste Alternative ohne Betrachtung der Aufgabe als „besser“ bezeichnet, sie „fühlt“ sich besser an. Grund ist hier, dass dieses Modell einige Constraints besitzt, während das zweite Modell ein Tausendfüßler-Rind erlaubt. Aber in der Natur gibt es auch Ausnahmen: Ein Rind mit zwei Köpfen wurde bereits geboren, und ein Rind, das ein Bein verloren hat, ist immer noch ein Rind. Und soll eine Software für einen Schlachthof erstellt werden, hat das zweite Modell einige Vorteile.
Deshalb muss bei der Designbewertung stets auf die zu lösende Aufgabe eingegangen werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.