Konzept: Konkurrierende Stakeholder-Prioritäten ausgleichen
Dieses Prinzip bringt die Wichtigkeit eines Ausgleichs zwischen den Stakeholder-Bedürfnissen zum Ausdruck.
Hauptbeschreibung

Einführung

Dieses Prinzip bringt zum Ausdruck, wie wichtig es ist, zwischen den unterschiedlichen, sich oft widersprechenden Geschäfts- und Stakeholder-Bedürfnissen einen Ausgleich zu schaffen. Daraus ergibt sich dann die Notwendigkeit eines Ausgleichs zwischen der benutzerdefinierten Entwicklung und der Wiederverwendung von Assets zur Deckung dieser Bedürfnisse.

    
Vorteile
  • Anwendungen an geschäftlichen und Benutzerbedürfnissen ausrichten
  • Eigenentwicklung reduzieren
  • Geschäftlichen Nutzen optimieren
Muster
  1. Geschäftliche und Benutzerbedürfnisse definieren, interpretieren und nach Priorität ordnen
  2. Projekte und Anforderungen nach Priorität ordnen und Bedürfnisse Softwarefunktionen zuordnen
  3. Feststellen, welche Assets genutzt werden können
  4. Wiederverwendung von Assets mit Benutzerbedürfnissen abgleichen
Antimuster
  • Präzise Anforderungen zu Projektbeginn ausführlich dokumentieren und die Stakeholder dazu bewegen, diese Anforderungen zu akzeptieren
    • Beliebige Änderungen der Anforderungen verhandeln, wobei jede Änderung die Kosten des Projekts erhöhen und seine Dauer verlängern kann.
    • Anforderungen im Voraus festschreiben und dadurch die Möglichkeiten zur Nutzung vorhandener Assets verringern
    • Vorrangig Eigenentwicklung betreiben.
  • Ein System entwickeln, dass nur den Bedürfnissen der durchsetzungsstärksten Stakeholder gerecht wird.

Diskussion

Beispielsweise wünschen sich die meisten Stakeholder eine Anwendung, die exakt das tut, was sie möchten, und das bei möglichst geringen Entwicklungskosten und niedrigem Zeitaufwand. Diese Prioritäten stehen jedoch oft in einem Konflikt miteinander. Ein weiteres Beispiel: Bei Verwendung einer Standardsoftware kann eine Lösung schneller und preiswerter gefertigt werden, allerdings muss dann auch bezüglich vieler Anforderungen ein Kompromiss akzeptiert werden. Wenn hingegen eine Anwendung ganz neu erstellt wird, können alle gewünschten Anforderungen berücksichtigt werden, allerdings mit einem höheren finanziellen und zeitlichen Aufwand als es den Vorgaben entspricht.

Die Nutzung einer Komponente kann die Kosten und den Zeitaufwand, die für die Lieferung einer bestimmten Funktionalität veranschlagt sind, radikal senken. In vielen Fällen muss auch ein Kompromiss bezüglich mancher funktionaler oder technischer Anforderungen, wie z. B. Plattformunterstützung, Leistung oder physische Größe der Anwendung) akzeptiert werden.

Damit verschiedene Bedürfnisse ausgeglichen werden können, müssen erst die Anforderungen berücksichtigt werden, wie in Unterstützendes Material: Anforderungsmanagement beschrieben. Statt Teams von Programmierern alle Punkte in einer Anforderungsliste einzeln abarbeiten zu lassen, ist es wichtig, die Geschäfts- und Stakeholder-Bedürfnisse zu verstehen und nach Priorität zu ordnen. Das bedeutet, dass Geschäftsprozesse erfasst und Projekten und Softwarefähigkeiten zugeordnet werden müssen. Dieses Konzept bietet die Möglichkeit, Projekte und Anforderungen effektiv nach Priorität zu ordnen. Die Prioritäten können dann während des laufenden Projekts, wenn das Wissen über die Anwendung zunimmt und die Stakeholder-Bedürfnisse sich weiterentwickeln, geändert werden. Das bedeutet auch, dass der Kunde bzw. der Vertreter des Kunden in das Projekt einbezogen werden muss, damit dessen Bedürfnisse genau definiert werden können.

Gleichzeitig muss die Entwicklungsaktivität auf die Stakeholder-Bedürfnisse ausgerichtet werden. Beispielsweise kann die Weiterentwicklung der Stakeholder-Bedürfnisse während des laufenden Projekts durch den Einsatz der anwendungsfallbasierten Entwicklung und des benutzerzentrierten Designs als Funktion in den Entwicklungsprozess eingebunden werden. Diese Funktion bringt dann die sich ändernden Geschäftsbedürfnisse und das zunehmende Wissen über die für das Geschäft und die Endbenutzer wichtigen Leistungsmerkmale als Kenngröße ein. 

Schließlich muss geklärt werden, welche Assets verfügbar sind, und die Wiederverwendung der Assets muss mit den Stakeholder-Bedürfnissen abgeglichen werden. Beispiele für Assets sind traditionelle Anwendungen, wiederverwendbare Komponenten und Muster. Die Wiederverwendung von Assets kann in vielen Fällen die Projektkosten reduzieren. Die Wiederverwendung bewährter Assets bedeutet oft eine höhere Qualität in neuen Anwendungen. Der Nachteil ist, dass oft ein Kompromiss zwischen der Wiederverwendung von Assets und der hundertprozentigen Erfüllung der Benutzerbedürfnisse gefunden werden muss. Beispielsweise kann die Wiederverwendung einer Komponente die Entwicklungskosten für ein Feature um 80 Prozent senken, jedoch nur 75 Prozent der Anforderungen abdecken. Eine effektive Wiederverwendung erfordert also ein konstantes Abwägen der Wiederverwendung von Assets einerseits und der sich weiterentwickelnden Stakeholder-Bedürfnisse andererseits.