Die Komponentenspezifikation leitet sich in erster Instanz aus den Anforderungen an das Gesamtsystem und aus dem Systemmodell ab. Es werden konkrete Anforderungen an die Subsysteme erstellt und mögliche komponentenspezifische Lösungsansätze erdacht. Diese Lösungsansätze werden während der Phase des Entwicklungszyklus überprüft und weiterentwickelt werden.
Checkpoints dienen zur Synchronisation des Entwicklungsstands aller Komponenten sowie zum Testen des Zusammenspiels der Subsysteme innerhalb des Gesamtsystems. Zu diesem Zweck findet hier eine (Teil-)Integration der Subsysteme statt, mit entsprechenden Verifizierungs- und Validierungstests bezüglich der Anforderungen an das Gesamtsystem. Da die Entwicklung jedes Subsystems ein eigenes Vorgehen erlaubt, ist ein unterschiedlich schneller Fortschritt je Komponente zu erwarten. Nicht alle Komponenten müssen aktiv an jedem Checkpoint teilnehmen.
Bei der Festlegung, wann und nach welchen Kriterien ein Checkpoint stattfindet, können unterschiedliche Strategien verfolgt werden. Obwohl auch eine klassische Meilensteinplanung möglich ist, die viele Vorteile hinsichtlich der Planbarkeit birgt, wird ein agileres Konzept empfohlen. Der Unterschied von Checkpoints zu formalen Meilensteinen ist, dass nicht zwingend ein definierter Entwicklungsstand vorgegeben werden muss. Hinsichtlich der Checkpoint-Planung sind folgende Strategien möglich:
Die featurebasierte Strategie:
Ein bestimmtes Feature oder eine bestimmte Anforderung sollen bis zum nächsten Checkpoint umgesetzt werden. Diese Strategie orientiert sich an der Umsetzung der sogenannten „User Story“ im agilen Vorgehensmodell SCRUM. Wichtig ist, dass während der Entwicklung nur Designentscheidungen getroffen werden, die zur Umsetzung des Features und zur Erreichung eines Minimalproduktes (Minimum Viable Product) notwendig sind. So werden schlussendlich Kosten bei Umentscheidungen gespart.
Die reifegradbasierte Strategie:
Ein Checkpoint ist immer dann erreicht, wenn mindestens zwei Subsysteme einen bestimmten Reifegrad erworben haben. Reifegrade können hier z. B. sein:
- Vorläufige Analyse (Proof of Concept)
- Sicherstellen von Grundfunktionalitäten
- Erfüllung der Leistungsmetriken (KPI)
- Leistungssteigerung/-optimierung
- Optimierung der Nutzerfreundlichkeit
Je nach Anwendungsfall können die Reifegrade weiter spezifiziert und unterteilt werden. Sie stellen somit Zwischenziele auf dem Weg zum fertigen Produkt dar.
Die zeitbasierte Strategie:
Ein Checkpoint ist zu einem regelmäßigen Zeitpunkt erreicht, z. B. immer nach einer Woche. Hier besteht die Herausforderung, dass die Arbeitspakete bis zum nächsten Checkpoint so gewählt werden, dass dann eine (Teil-)Integration mit allen Neuerungen möglich ist. Da jedoch nicht alle Komponenten zusammen an einem Checkpoint teilnehmen müssen, sind auch hier verschiedene Zeitintervalle je Komponente möglich.
Sowohl bei der Verfolgung einer Strategie als auch bei der Kombination verschiedener Strategien ist es wichtig, dass im Verfeinerungsschritt der jeweils nächste Checkpoint klar definiert wird. Dazu gehören die Fragen, welche Subsysteme an der (Teil-)Integration teilnehmen und wann ein Checkpoint erreicht ist.
Leitfragen
- Welche komponentenspezifischen Lösungsansätze sollen verfolgt werden?
- Welche Informationen stehen dem KI-Subsystem als Eingabe zur Verfügung (Feature-Vektor)?
- Welche Güte muss das KI-Subsystem erreichen und wie erfolgt der Nachweis?
- Welche Datengüte muss zu welchem Checkpoint vorliegen, damit die KI-Subsystem-Entwicklung voranschreiten kann? Wie erfolgt der Nachweis der Güte?
Ergebnisse
- Dokumentation aller initialen Spezifikationen
- Dokumentation der Strategie für die Checkpoints
→ Zur nächsten Phase von PAISE®: Entwicklungszyklus
← Zurück zur vorherigen Phase von PAISE®: Funktionale Dekomposition