Agile modeling

From Wikipedia, the free encyclopedia

(Redirected from Agile Modeling)

Agile modeling (AM) is a methodology for modeling and documenting software systems based
on best practices. It is a collection of values and principles, that can be applied on an (agile)
software development project. This methodology is more flexible than traditional modeling
methods, making it a better fit in a fast changing environment.[1] It is part of the Agile software
development tool kit.
Agile modeling is a supplement to other agile methodologies such as Scrum, extreme
programming (XP), and Rational Unified Process (RUP). It is explicitly included as part of
the disciplined agile delivery (DAD) framework. As per 2011 stats, agile modeling accounted for
1% of all agile methodologies.[2]
Contents
[hide]

1 Best practices
o 1.1 Modeling
o 1.2 Documentation
2 History
3 Limitations
4 See also
5 References
6 External links

Best practices[edit]
There are several best practices:

Modeling[edit]
1. Just barely good enough (JBGE) artifacts. A model or document needs to be sufficient for
the situation at hand and no more. This is an application of the KISS principle.
2. Architecture envisioning. At the beginning of an agile project, high-level architectural
modeling is done to identify a viable technical strategy.
3. Lookahead modeling is used to reduce overall risk.
4. Multiple models can be used. Each type of model has its strengths and weaknesses.
Effective developers have a range of models in their intellectual toolkit enabling them to
apply the right model in the most appropriate manner for the situation at hand.
5. Active stakeholder participation. Stakeholders are important for funding the process and
accepting the results, that is why they are involved as soon as possible. Stakeholders
provide information in a timely manner, make decisions in a timely manner, and are as
actively involved in the development process as possible.
6. Requirements envisioning. At the beginning of an agile project, time is invested to identify
the scope of the project and to create the initial prioritized stack of requirements.
7. Prioritized requirements. Requirements are implemented in priority order, as defined by
their stakeholders, so as to provide the greatest return on investment possible. Collecting
the low hanging fruit.
8. Iteration modeling. At the beginning of each iteration, a bit of modeling is done as part of
the iteration planning activities.
9. Test-driven development (TDD). Requirements are written like a test. Tests are
performed and then just enough code is made to fulfill that test. TDD is a JIT approach to
detailed requirements specification and a confirmatory approach to testing.

10. Model storming. Throughout an iteration a brainstorming session can be hold, called
"model storm" on a just-in-time (JIT) basis for a few minutes to explore the details behind
a requirement or to think through a design issue.

Documentation[edit]
1. Document continuously. Documentation is made throughout the life-cycle, in parallel to
the creation of the rest of the solution.
2. Document late. Documentation is made as late as possible, avoiding speculative ideas
that are likely to change in favor of stable information.
3. Executable specifications. Requirements are specified in the form of executable
"customer tests", instead of non-executable "static" documentation.
4. Single-source information. Information (models, documentation, software), is stored in
one place and one place only, to prevent questions about what the "correct" version /
information is.