Risiko Nr. 18 Ungeeigneter Softwareentwurf

Kategorie und Projektphase

Phasenueberblick

Risikosatz & Risikobeschreibung

Aus mangelnder Erfahrung der Softwaredesigner bzgl. fachliche Zusammenhänge und nicht ausreichend definierter Qualitätsmerkmale für die Designphase (z.B. Abstraktionsebene) könnte ein ungeeigneter Entwurf entstehen, der für die Lösung der fachlichen Anforderungen unzureichend geschnitten ist (fachlicher Prozess und Objekte wurden nicht berücksichtigt) oder zu viele Implementierungsdetails enthält, die unnötigen Pflegeaufwand im weiteren Verlauf verursachen.

Indikatoren

  • Softwaredesigner haben keine Erfahrung in der Anwendungs-domäne.
  • Schlechte Anforderungsqualität führt zu einer hohen Anzahl von Annahmen für den Softwareentwurf. Beispielsweise werden Ablaufprozesse „angenommen“ und nicht „gewusst“.
  • Der Entwurf ist sehr kleinteilig. Beispielsweise existiert in einer serviceorientierten Architektur eine Vielzahl von Services, die eigentlich zu einer Sinneinheit zusammengefasst werden könnten.
  • Der Entwurf ist zu grob. Beispielsweise besteht das Modell der Software ausschließlich aus farbigen Kästchen und Pfeilen in Powerpointfoliensätzen.

Risikomatrix und das magische Viereck

Risikomatrix

Maßnahmen

  • Architektur- bzw. Design-Vision entwickeln. (Was soll das Design leisten?) Ziele, die es erlauben Designentscheidungen des Teams zu leiten. Gegebenenfalls kann die Vision noch durch dokumentierte Vorgehensprinzipien/Qualitätskriterien detailliert werden.
  • Einem einfachen Design immer den Vorzug vor einem komplexen Design geben.
  • Systemanalytiker und Programmierer in den Softwareentwurf einbinden, um das technische und fachliche Verständnis zu steigern und Wissen weiterzugeben.
  • Architektur-Reviews durchführen: Design von fachlich und technisch erfahrenen Mitarbeitern prüfen lassen, bevor die Implementierung startet.
  • Architektur-Prototyp erstellen. Simulationen und Benchmarking einsetzen, um dessen Funktionsfähigkeit zu prüfen.
  • Design-Patterns verwenden. Dies sind erprobte Entwurfsvorlagen für häufig auftretende Probleme im Softwareentwurf.
  • Das Design auf Wiederverwendung ausrichten. Je länger das Projekt läuft, umso mehr Potential kann durch die Wiederverwendung von Entwürfen und Programmcode erzielt werden.
  • Das Verhältnis zwischen Design und Programmierung ins Gleichgewicht bringen: Das Design ist wichtiger als die Programmierung selbst.
  • Fachliches Modell der Software schaffen. Dieses sollte Daten, Funktionen und Ablaufprozess ausreichend beschreiben. Die Faustregel für die passende Abstraktionsstufe lautet: Der Auftraggeber muss das Modell auf seine Richtigkeit überprüfen können und der Programmierer muss aus dem Modell Schlüsse auf die Codestruktur ziehen können. Den Einsatz der Unified-Modeling-Language (UML) prüfen.
  • Prüfen, ob für die konkrete Anwendungsdomäne bereits Ansät-ze einer spezialisierten modellgetriebenen Architektur (MDA) vorliegen, die aufgenommen werden können.
  • Dekomposition: Ein gelungener Softwareentwurf zerlegt eine fachliche Domäne in ihre Teile und fasst Sinneinheiten zusammen.
  • Strukturierte Systemanalyse durchführen: Geschäftsprozesse und Anwendungsfälle beschreiben etc.

Beziehungen

Beziehungen zu Vorgängerrisiken und Nachfolgerrisiken

Identifizieren und Überwachen

  • Entdecker: Projektleiter, Teamleiter, Qualitätsmanager, Systemanalytiker, Softwaredesigner, Programmierer
  • Überwacher: Qualitätsmanager, Systemanalytiker, Softwaredesigner