Aufwandsschätzung in Data-Vault-2.0-Projekten
In Data-Vault-2.0-Projekten empfehlen wir, den Aufwand mithilfe einer Function-Point-Analyse (FPA) zu schätzen. Bei der Auswahl einer Methode zur Aufwandsschätzung in agilen IT-Projekten stehen zahlreiche Optionen zur Verfügung. In diesem Artikel erfahren Sie, warum die FPA eine gute Wahl ist und warum Sie die Nutzung dieser Methode für Ihre eigenen Data-Vault-2.0-Projekte in Betracht ziehen sollten.
Das gute alte Planning Poker zur Aufwandsschätzung
Die wahrscheinlich bekannteste Methode zur Aufwandsschätzung in agilen Projekten ist Planning Poker. Im Verlauf des Prozesses werden sogenannte Story Points verwendet, die auf der Fibonacci-Folge (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 und 100) basieren, um den Aufwand einer bestimmten Aufgabe zu schätzen. Zu Beginn des Prozesses kommt das gesamte Entwicklungsteam zusammen und jedes Mitglied weist jeder User Story gleichzeitig die aus seiner Sicht angemessenen Story Points zu. Stimmen die Story Points überein, steht die finale Schätzung fest. Kann kein Konsens erzielt werden, wird der Aufwand so lange diskutiert, bis eine Entscheidung getroffen ist.
Es ist jedoch wichtig zu beachten, dass diese Technik einen hohen Aufwand verursacht, wenn entweder zu viele Aufgaben vorliegen oder das Team zu groß ist. Es stellt sich also die Frage: Funktioniert Planning Poker für Data-Vault-Projekte? Die kurze Antwort lautet: „Es ergibt wenig Sinn“. Da in Data Vault 2.0 die fachlichen Anforderungen in kleine Einheiten zerlegt werden, gibt es zahlreiche Aufgaben, die alle diskutiert und bewertet werden müssen. Zudem handelt es sich bei den Teilaufgaben in Data Vault 2.0 um standardisierte Artefakte wie Hubs, Links und Satellites. Im Prinzip stellen diese Artefakte stets denselben Aufwand dar.
Warum eignet sich die Function-Point-Analyse so gut?
Hier kommt die FPA ins Spiel und das ist auch der Grund, warum sie in agilen Softwareprojekten weit verbreitet ist. Die Idee besteht darin, dass Software aus den folgenden Charakteristika besteht, welche die Function Point Types darstellen:
- External Inputs (EI) → Daten, die in das System gelangen
- External Outputs (EO), External Inquiries (EQ) → Daten, die das System auf die eine oder andere Weise verlassen
- Internal Logical Files (ILF) → Daten, die innerhalb des Systems erzeugt und gespeichert werden
- External Interface Files (EIF) → Daten, die außerhalb des Systems verwaltet werden, aber zur Ausführung der Aufgabe erforderlich sind
Bei der FPA zerlegen Sie die Funktionalität für eine bessere Analyse in kleinere Einheiten. Wie bereits erwähnt, geschieht dies in Data-Vault-2.0-Projekten aufgrund der standardisierten Artefakte ohnehin schon. Aus diesem Grund eignet sich die FPA hervorragend für Data-Vault-Projekte.
Wie Sie die FPA in Data Vault 2.0 anwenden
Um die FPA in der Data-Vault-2.0-Methodik gewinnbringend einzusetzen, müssen die funktionalen Merkmale von Software – External Inputs, External Outputs, External Inquiries, Internal Logical Files und External Interface Files – an Data-Vault-Projekte angepasst werden. Die funktionalen Merkmale von Data Warehouses, die mit Data Vault aufgebaut sind, werden wie folgt definiert:
- Stage load (EI)
- Hub load (ILF)
- Link load (ILF)
- Satellite load (ILF)
- Dimension load (ILF)
- Fact load (ILF)
- Report build (EO)
Bitte beachten Sie, dass auch weitere funktionale Komponenten definiert werden können, wie beispielsweise Business-Vault-Entitäten, Point-in-Time-Tabellen usw. Sobald Sie diese Komponenten definiert haben, sollten Sie eine Tabelle erstellen, die diese den Function Points zuordnet. Function Points dienen dazu, den Umfang der fachlichen Funktionalität zu quantifizieren, die ein Element einem Anwender bietet. Im Allgemeinen wird empfohlen, zunächst einen Komplexitätsfaktor hinzuzufügen.
| Complexity Factor | Person Hours per Function Point |
| Easy | 0.1 |
| Moderate | 0.2 |
| Difficult | 0.7 |
Verwenden Sie anschließend die Komplexitätsfaktoren und die zugewiesenen Function Points pro Komponente, um die geschätzte Stundenzahl zu berechnen, die für das Hinzufügen der jeweiligen Funktionalität erforderlich ist. Hier ist ein kurzes Beispiel dafür, wie eine solche Zuordnungstabelle für Sie aussehen könnte:
| Component | Complexity Factor | Estimated Function Points | Estimated Total Hours |
| Hub Load | Easy | 2 | 0.2 |
| Dimension Load | Difficult | 3 | 2.1 |
| Report Build | Difficult | 5 | 3.5 |
Das Ziel der Schätzung besteht darin, die Entwicklung operationaler Informationssysteme zu standardisieren, indem der Aufwand berechenbarer gemacht wird. Wenn Sie einen systematischen Ansatz verwenden, um den erforderlichen Aufwand für das Hinzufügen von Komponenten zu schätzen, können Sie die geschätzten Werte nach Bereitstellung der Funktionalität mit den tatsächlichen Werten vergleichen. Durch den Vergleich beider Werte kann Ihr Team aus vergangenen Schätzungen lernen und künftige Schätzungen verbessern, indem die Function Points pro Komponente angepasst werden. Denken Sie auch daran, dass Ihre Entwickler im Laufe der Zeit an Erfahrung gewinnen oder durch Personalwechsel Erfahrung verloren gehen kann.
Fazit
Ich hoffe, dieser erste Einblick in die FPA hilft Ihnen zu verstehen, welchen grundlegenden Mehrwert sie Ihrem Team in Data-Vault-2.0-Projekten bieten kann. Einen tieferen Einblick in die Anwendung der FPA in Data-Vault-2.0-Projekten erhalten Sie im Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ von Michael Olschimke und Dan Lindstedt.
