Agile Modeling

Agile Modeling (AM) is a practice-based methodology for effective modeling of software-based systems. Where the Unified Modeling Language (UML) defines a subset of the modeling techniques that software professionals require, AM defines practices that enables developers to model in an efficient and effective manner. This paper provides a brief overview of AM’s values, principles,
and practices; defined what agile models are; and summarizes the scope of AM.

When is a Model Agile?
To understand AM you need to understand the difference between a model and an agile model. A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem. Traditionally, models are thought of as zero or more diagrams plus any corresponding documentation. However non-visual artifacts such collections of CRC cards, a textual description of one or more business rules, or the structured English description of a business process are also considered to be models. An agile model is a model that is just barely good enough. But how do you know when a model is good enough? Agile models are good enough when they exhibit the following traits:
(1) They fulfill their purpose and no more.
(2) They are understandable.
(3) They are sufficiently accurate.
(4) They are sufficiently consistent.
(5) They are sufficiently detailed.
(6) They provide positive value.
(7) They are as simple as possible.

What Is(n’t) Agile Modeling?
I am a firm believer that when you are describing the scope of something, be it a system or in the case of AM a methodology, that you should describe both what it is and what it isn’t. The following points describe the scope of AM:
(1) AM is an attitude, not a prescriptive process.
(2) AM is a supplement to existing methods, it is not a complete software development methodology.
(3) AM is a way to work together effectively to meet the needs of project stakeholders.
(4) AM is effective and is about being effective.
(5) AM is something that works in practice, it isn’t an academic theory.
(6) AM is not a silver bullet.
(7) AM is for the average developer, but is not a replacement for competent people.
(8) AM is not an attack on documentation.
(9) AM is not an attack on CASE tools.
(10)AM is not for everyone.
(11)AM is complementary to the UML.

Ta,
~SA