Database Reference
In-Depth Information
Table 5: Modeling and design activities in the selected set of Agile Methodologies
XP
FDD
Agile Modeling Extreme Modeling
Scope
Development
process
Development
process
Modeling and
design
Development process
(not detailed)
Amount of
modeling
Low
Low
Middle
Middle
Tool support
No
Not specifi ed
(possible UML-
supportive)
The simplest
possible, e.g.,
whiteboard
Extensive support
(transfer model to code)
Notation
User stories, CRC
cards, Sketches of
classes
Features, Objects/
Classes, Sequence
diagrams
UML + User
stories, UI
screens, Data
modeling, etc.
Formerly Petri nets,
now standard UML and
code
Architecture
design
Metaphor,
Architecture
Spikes, First
Release
Based on object
model
Domain
packages
Based on object
orientation
Requirements
elicitation
User stories
Features
Use cases + user
stories
Use cases
Using
components
No
No
To some extent
To some extent
Business
modeling
No
No
Yes
No
Model
repositories
No
N/A
No
Yes
Designing large
systems
No
To some extent
Yes
Yes
Incremental
Yes
Yes
Yes
Yes
Iterative
Yes (very small
increments)
Yes, only two
phases
Yes, sequential
and iterative
Model and code
constantly in sync
Complexity
Low
Low
Middle
Middle - advanced tool
support
Model
reusability
No
No
No
Yes
Agile vs. Traditional Methods
It is obvious that Agile Methodologies claim to address the challenges of high change
rates, short time-to-market, increased return-on-investment and high quality software by
emphasizing communication between project stakeholders, iterative and incremental develop-
ment with the focus on software code, as well as high response to changes in requirements.
On the other hand, traditional, more formal methodologies, such as Rational Unifi ed Process
(RUP) (Jacobson et al., 1999) and Catalysis (D'Souza & Wills, 1999) suggest rigorous
modeling and a clear plan to follow in transferring business requirements into working
software. The current Object Management Group initiative over Model-Driven Architecture
is in line with that way of thinking. MDA stresses the importance of a platform-independent
and platform-specifi c model to separate abstract domain knowledge from concrete imple-
