In der objektorientierten Programmierung gibt es zwei Begrifflichkeiten, die jeder kennen sollte: Generalisierung und Spezialisierung (Vererbung).
Alle Gemeinsamkeiten eines Objektes werden ermittelt und in der Basisklasse beschrieben (Generalisierung). Die eigentliche Implementierung erfolgt in einer abgeleiteten Klasse (Spezialisierung). Daraus schließen wir:
 |
| Requirements-Engineering - Anforderungen identifizieren |
Anforderungen an die Aufgabe recherchieren (Generalisierung)
- Anforderungen aufnehmen und die Grundbegriffe der
Fachdomäne und deren Zusammenhänge erarbeiten;
- Lösungsmöglichkeiten und Alternativlösungen betrachten
und analysieren:
- Wurde dieses oder ein
ähnliches Thema bereits erfolgreich umgesetzt? Welche grundlegenden
Gemeinsamkeiten und Konzepte können wiederverwendet werden?
- Wenn es ähnliche
erfolgreich umgesetzte Themen gibt, dann gibt es sicherlich auch
Negativbeispiele? Was können wir aus diesen Negativbeispielen lernen, um
nicht die gleichen Fehler zu begehen?
- Welche Fachexperten
gibt es bei uns im Unternehmen die uns im Bezug auf die Fachdomäne und
damit bei der Identifizierung von Heraus- und Anforderung helfen können?
- Prototypen entwerfen und Alternativlösungen
gegenüberstellen (sogenannte Spikes) sind ein probates Mittel um
frühzeitig soviel wie möglich über die Anforderungen zu erfahren und diese
in Fachkonzepte einfließen zu lassen.
- Das Ergebnis eines
Spikes muss analysiert und dokumentiert werden um daraus zu lernen und
Entscheidungen ableiten zu können. Fehler sollen wenn möglich nur einmal
begangen werden.
- Welche Anforderungen und Ergebnisse können in welchem Kontext zusammengeführt, also gemeinsam betrachtet werden (APIs, Design Patterns, Technologien, etc.)?
Anforderungen an die Aufgabe konkretisieren (Spezialisierung)
Anstatt die Anforderung in einem generischen Ansatz lösen zu wollen, empfiehlt es sich die "Spezialfälle" als erstes zu betrachten. In den meisten Fällen lösen mehrere Spezialfälle zugleich den generischen Fall.- Was ist die Hauptanforderung an einen möglichen
Lösungsansatz (Plain Vanilla)?
- Kann diese Hauptanforderung noch weiter zerlegt (die
Spezialisierung vertieft) werden?
- Welche Fehler können in diesem (Plain Vanilla)-Ansatz
auftreten?
- Was ist das schlimmste Szenario was im Fehlerfall
eintreten kann (Worst-Case-Szenario)?
- Mit welchen kritischen Szenarien würden wir uns
konfrontiert sehen, wenn wir (die Entwickler) die Anforderung stellen
würden? Was würden wir anders machen? Welche Entscheidungen müssten/würden
wir überdenken?
- Der Perspektivenwechsel
ist hier im Design von Oberflächen (GUIs) sehr spannend. Als Entwickler
habe ich kein Thema damit, mehrere Buttons hintereinander klicken zu
müssen, aber wie sieht das der Endanwender im alltäglichen?
- Laufzeiten stören den einzelnen Entwickler während der Entwicklungsphase nicht unbedingt. Als Endanwender können mehrere Sekunden Wartezeit das positive Erlebnis einer neuen Softwareapplikation schnell verkehren.
Der heilige Gral
Softwareentwickler neigen oft dazu, einen Prototypen (womöglich aus einem Spike entstanden) als Einstieg in ein potentielles Produkt zu sehen. Die Vorteile liegen auf der Hand:- Stakeholder können sich einen praktischen Eindruck von
der meist eher abstrakten Anforderungsbeschreibung verschaffen
- Der Entwickler erhält einen Vertrauensvorschuss
("das Meiste ist ja schon erledigt“)
Leider kann dieser Ansatz schnell in einer Sackgasse enden, da nicht alle Risiken und Unwägbarkeiten erfasst wurden. Wenn erst alle Risiken abgeschätzt und die komplexen Anforderungen erfüllt werden, wird ein "vorzeigbares" Ergebnis für den Stakeholder viel später vorliegen aber dafür sind alle Unwegsamkeiten bereits gelöst.
Vor dem Beginn einer Realisierung sollte unabhängig für welchen Weg sich entschieden wird geklärt sein: Welche Risiken und Unwegsamkeiten liegen vor und welche Lösungsstrategien versprechen Abhilfe!
