Der wesentliche Unterschied zwischen beiden Methoden liegt im Entwurf der Modelle. Werden bei MDSD zuerst umfangreiche Modelle erstellt (zum Beispiel in UML) bevor mit dem Schreiben des Quellcodes begonnen wird, erfolgt in AMDD die Erstellung der Modelle mit möglichst geringem Aufwand (zum Beispiel Whiteboard), um zuerst nur die wichtigsten Grundanforderungen abzubilden. Die Modelle sollen für den aktuellen Arbeitsaufwand "gerade gut genug" sein. In weiteren Iterationen (Development Iterations) werden die Grundanforderungen verfeinert und optimiert.

Die Phasen im AMDD-Prozess

Envisioning:

Zu Projektbeginn erfolgt eine enge Zusammenarbeit mit den Stakeholdern, um die wichtigsten Grundanforderungen zu ermitteln und den Umfang grob zu modellieren. Die Systemarchitektur wird ebenfalls grob modelliert, um die technische Richtung vorzugeben. Die gesamte Modellierung in dieser Phase ist undetailliert und lediglich ausreichend. Wichtig ist, dass das Problem an sich verstanden wird.

Development Iterations:

Am Anfang jeder Iteration plant das Team seine Arbeit und priorisiert die Anforderungen. Durch die enge Zusammenarbeit zwischen Stakeholder und Entwickler können in jeder Iteration neue bzw. erweiterte Anforderungen entwickelt werden. Die Entwicklung erfolgt durch Test Driven Development (TDD).

Release:

Innerhalb dieser Phase erfolgen Schluss- sowie Akzeptanztest, um die Funktionalität des Gesamtsystems zu überprüfen. Treten Fehler auf, werden diese korrigiert. Endanwender werden geschult, um mit dem System effektiv arbeiten zu können.

Production:

Ziel ist hierbei, das System aufrecht zu erhalten und die Anwender beim Umgang zu unterstützen. Die Phase endet, wenn ein System oder der Support für das System ausläuft.

Bewertung BQI Research

AMDD deckt unter den Disziplinen des Software Engineering die des Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Integration/Einführung (INT), Wartung (W) und Betrieb (B) sowie für Implementierung (IMP). Auf mittlerem Niveau bewegen sich das Qualitäts-Management (QM), Requirements-Management (RM) und das Systemdesign/technische Konzeption (SD) während für Projekt-Management (PM) nur wenig Unterstützung kommt.

• Bekanntheitsgrad und Verbreitung sind eher gering.

• Es gibt keine spezielle Tool-Unterstützung.

• Die Methode ist nicht normiert/standardisiert oder zertifiziert.

• Keine Lizenzierung erforderlich.

• Es gibt keinen Support.

Text