Agiles Datawarehousing
Dieser Artikel wurde aufgrund von inhaltlichen Mängeln auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+)
Begründung: Artikel steht im Verdacht nur Werbeplattform für ein kürzlich erschienenes Werk zu sein, siehe Diskussionspunkt "SEO" und Versionsgeschichte; sofern relevant: Reputable Quellen fehlen; belegen dass es sich nicht um WP:TF handelt; WP:OMA wird nicht Genüge getan; zudem wikifizieren. Artikel ist fast verwaist, nur 1 Referenz hierauf. --Hamburger 11:01, 6. Feb. 2012 (CET)
Agile Data Warehousing (ADW) ist ein Vorgehensmodell, das die beiden Ansätze Scrum und Extreme Programming (XP) vereint. Im ADW-Modell werden Scrum-Methoden als Projektmanagement-Rahmen übernommen und mit XP- Entwicklungstechniken zusammengeführt.[1]
Das ADW-Modell ist ein sechsstufiges Vorgehensmodell, dass aus den folgenden Stufen besteht:
- räumlich zusammenhängendes und selbstorganisiertes Team
- Aufbau von Epen und Beurteilung der Fähigkeiten
- Releaseplanung
- Prototypen und testgetriebene Auslieferung
- nebenläufige Auslieferungsgruppen
- kontinuierlicher Integrationstest
Inhaltsverzeichnis |
[Bearbeiten] Bedeutung der ADW-Stufen
[Bearbeiten] Räumlich zusammenhängendes und selbstorganisiertes Team
Wie im Scrum liefert das Entwicklungsteam die Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge. Grundlage dafür ist das Team und Product Owner räumlich zusammengeführt werden.
[Bearbeiten] Aufbau von Epen und Beurteilung der Fähigkeiten
Mit dem Aufbau von Epen ist der Aufbau des aus Scrum bekannten Product Backlogs gemeint. Epen gruppieren dabei die sich im Product Backlog befindlichen User Storys. Diese User Storys werden dann über die Beurteilung der Fähigkeiten des Team mit Story-Points bewertet. Diese Story-Points dienen als Mass für die Komplexität einer User Story.[2]
[Bearbeiten] Releaseplanung
In dieser Stufe wird ein Releaseplan erstellt, der den gesamten Umfang eines Projektes umreisst. Außerdem werden in dieser Stufe die Anzahl an Iterationen, die analog zu Scrum Sprints genannt werden, festgelegt.
[Bearbeiten] Prototypen und testgetriebene Auslieferung
In dieser Stufe liefert der Product Backlog genaue Anforderungen und das Team implementiert Prototypen. Diese Prototypen entsprechen im Wesentlichen aber schon den Anforderungen des Product Backlog. Testgetriebene Auslieferung stellt die Qualität der Prototypen sicher und soll dazu betragen die vollendeten Prototypen in das laufende System zu übernehmen.
[Bearbeiten] Nebenläufige Auslieferungsgruppen
In dieser Stufe werden nebenläufige Auslieferungsgruppen formuliert, damit ist gemeint, dass Entwicklungsphasen, wie Spezifikation, Design, Implementierung und Auslieferung parallel ablaufen.
[Bearbeiten] Kontinuierlicher Integrationstest
Diese Stufe rundet die ADW-Qualitätssicherungsstrategie ab, in dem jedes Modul kontinuierlich integriert wird, sobald es von Entwickler abgeschlossen wurnden ist. Durch eine solche Auslieferung findet eine kontinuierliche Validation statt.
[Bearbeiten] Ablauf eines ADW-Sprints
Ein ADW-Sprint beginnt, wie ein normaler Sprint in Scrum, mit einer Sprintplanungsitzung. In der Sprintplanungsitzung werden User-Storys aus dem Product Backlog ausgewählt und innerhalb des Sprints umgesetzt. Für die Umsetzung werden Techniken benutzt die aus Extreme Programming bekannt sind. Diese Techniken definieren die eigentlichen Entwicklungsschritte, die in einem ADW-Projekt durchgeführt werden. Solche Entwicklungsschritte sind z.B. das systematische Testen, Erstellen von Prototypen und die kontinuierliche Integration. Ein ADW-Sprints endet mit einem Sprint-Review, darin wird reflektiert, ob und wie die Ziele eines Sprints erreicht worden sind. Dann erfolgt eine Rekursion in Form eines neuen Sprint. Im neuen dem Sprint werden die einzelnen Schritte erneut durchlaufen.[3]
[Bearbeiten] Abdeckungsgrad zu bestehenden Standards
Die Normenreihe DIN 69901:2009 beschreibt Grundlagen, Prozesse, Prozessmodell, Methoden, Daten, Datenmodell und Begriffe im Projektmanagement. In Norm DIN 69901:2009 wird ein Mindeststandard definiert, der im Projektmanagement eingehalten werden sollte und aus fünfzehn Prozessen besteht. Das ADW-Modell implementiert alle Prozesse und ist damit mit dem Mindeststandard konform.[4]
Die Norm DIN EN ISO 9001:2008 beschreibt allgemeine Anforderungen für ein QM-System. Das ADW-Modell entspricht in vielen Punkten den Vorgaben der Norm. Doch werden wesentliche Punkte nicht implementiert und müssen angepasst werden, um eine vollständige Kartierung zu erlangen.
Capability Maturity Model Integration (CMMI) ermöglicht eine Klassifizierung in fünf Stufen und gruppiert eine Menge von zusammenhängenden Praktiken in Prozessgebieten (engl.: process areas). Diese Praktiken sind erfüllt, wenn alle Ziele eines bestimmten Gebietes umgesetzt werden. Um den Abdeckungsgrad zwischen ADW und CMMI zu ermitteln, müssen die 48 spezifischen Ziele erreicht werden.[5]
[Bearbeiten] Einzelnachweise
- ↑ Hughes, Ralph: Agile Data Warehosing 101: An Introduction to Accelerated BI/DW Development. sigs datacom, 2011.
- ↑ Hughes, Ralph: Survival Skill: Requirements Management for Agile Data Warehousing Projects. sigs datacom, 2011.
- ↑ Hughes, Ralph: Fast and Thorough: Quality Assurance for Agile Data Warehousing Projects. sigs datacom, 2011.
- ↑ Zuther, Bernd: Agile Methoden zur Einführung eines ERP-Systems am Beispiel einer Internetagentur. Akademikerverlag, 2012.
- ↑ Hughes, R.: Agile Data Warehousing. iUniverse, Inc., 2009.
[Bearbeiten] Weblinks
- Agile Best Practices for Data Warehousing (DW)/Business Intelligence (BI) Projects
- Q and A: Agile Data Warehousing
- Principles of Agile data warehousing
- Anforderungsmanagement im agilen Data Warehousing
