Channels ▼
RSS

Implicit to Formal: Validating Agile Models


Agile Modeling



I firmly believe that you should test often and early, that if you can build something, you should validate it, and that if something isn't worth validating, it isn't worth building. These tenets pertain to agile models as well as other development artifacts. Although most agile models are discarded almost immediately--for example, whiteboard sketches are typically erased a few minutes after being drawn--some agile models evolve to become part of your permanent documentation. Therefore, it makes sense to validate these models.

There are several model validation strategies to choose from:

  1. Implicit reviews. This review occurs as part of another activity within your software process; for example, the combination of Extreme Programming (XP)'s Pair Programming and Collective Ownership practices. On an XP project, everyone can work on any part of the code--and as a side effect, the code is continually being reviewed; with pair programming, at least two pair of eyes examine each line of code. Implicit reviews also work in Feature-Driven Development (FDD), which prompts developers to pow-wow with domain experts before breaking into smaller groups to create domain object models; then reforming to compare and combine the results in a follow-up modeling session. This follow-up modeling session is arguably an implicit review.

  2. Impromptu model reviews. This is the most common technique for validating models, as it's the easiest to organize, often the result of a simple request such as "Sally and John, could you spend a few minutes looking at this diagram?" In this review, you show your work to a few people, get some quick feedback, update your work accordingly and then move forward.

  3. Playacting. With this approach, your project stakeholders simulate working with the system based on the vision described in the models. With usage scenario testing, you take a scenario (perhaps part of a use case or several use cases in combination) and work through it a step at a time, following the logic through your domain model. I've used this technique effectively on several projects, having users walk through the responsibilities described in an object domain model.

  4. Informal model reviews. This style of review is often called a walkthrough. Informal reviews are scheduled a few days ahead of time, and the material to be reviewed is made available before the review. Informal reviews often become modeling sessions in their own right because discussion between the reviewers and the creators of the model is encouraged. This is particularly applicable when the group decides to discuss potential solutions to identified issues.

  5. Formal model reviews. Formal reviews are rigorous, with review agendas and formal review packages distributed before the review and minutes distributed afterward. A trained facilitator leads a formal review and reviewers follow predefined procedures. The goal is to identify problems, but not solutions, and in many formal reviews, the modelers are not allowed to interact with the reviewers.

Although these techniques are presented in the order of potentially most agile to potentially least agile, in the right situation, a formal review may be the most agile option available to you. For example, a team working on an air traffic control system may be required by federal regulations to submit to a series of reviews. Agility is relative: Depending on how you approach these reviews, they could be little more than an effort to conform to regulations, or very productive and valuable.

When developers and project stakeholders work together closely, you'll discover that your work is being validated as a matter of course and that specific reviews aren't as necessary as in lone-wolf efforts. You have several options for validating models, including several styles of reviews and several play-acting techniques. By keeping your approach simple, by focusing on communication and people issues, and by having a outlook, you'll find that you can easily validate models in an agile manner.

Recently on the Agile Modeling Mailing List:

Support for Maintenance
A few weeks ago, it was pointed out that maintenance issues aren't often discussed within the agile community. Unfortunately, this seems to be true, although there's some excellent material out there. I pointed out that Agile Modeling (AM) includes a very good discussion of agile documentation techniques for writing effective system documentation. Charlie Poole and J.W. Huisman have also written about their maintenance experiences at IONA after the adoption of XP, describing how maintenance actually became easier. Another list member said that agile's emergent approach can be a better option than a traditional big-design up-front (BDUF) approach when replacing a poorly documented legacy system--a topic I'm sure someone will discuss in detail in the future.

Are Use Cases Valid for All Systems?
This question was posed to the group, and it seems to be a recurring theme in the IT community, as people seem to regularly ask various flavors of it in modeling-oriented newsgroups. Experience shows that when you want to describe how your users work with your system, use cases are a good option. However, if your users don't understand use cases, or if your underlying process expects another type of artifact--for example, XP requires user stories and FDD requires features--use cases aren't a good option. The AM principle Multiple Models tells you that you have a choice of artifacts, and its practice Apply the Right Artifact(s) advises you to pick the best one(s) for the job. Therefore, use cases aren't always valid, although in many cases, they're a very good option.

Limits of Communication
An interesting conversation started when someone pointed out that in some circumstances, pictures communicate some things, to some people, better than words. In other situations, words communicate some things, to some people, better than pictures. Hence, diagrams aren't always your best option, and your audience will often determine how you'll render your models. Knowing your audience is one aspect of AM's Model with a Purpose principle, and the principle Content Is More Important than Representation provides the "wiggle room" to move away from official notations such as the UML to use the approach best suited to your audience's needs.

Hot Links:

"Agile Documentation" by Scott W. Ambler.
www.agilemodeling.com/essays/agileDocumentation.htm

Agile Modeling Mailing List.
www.agilemodeling.com/feedback.htm

Cutter IT Consortium's Agile Home Page.
www.cutter.com/itjournal/agile.html
Link to a more detailed discussion of agile model validation from this page.

"Extreme Maintenance" by Charles Poole and Jan Willem Huisman.
www.xpuniverse.com/2001/pdfs/Method02.pdf

Extreme Programming Explained--Embrace Change by Kent Beck (Addison-Wesley, 2000).
www.amazon.com/exec/obidos/ASIN/0201616416/ambysoftinc/103-7190775-8163854

"A Lightweight Methodology for Design and Code Reviews" by Alan Shalloway and Rhett Alden.
www.netobjectives.com/download/design%20reviews.PDF

The Object Primer, 2nd Edition: The Application Developer's Guide to Object Orientation by Scott W. Ambler (Cambridge University Press, 2001).
www.ambysoft.com/theObjectPrimer.html

"Object Testing Patterns" by Scott W. Ambler (Software Development magazine, July 1999).
www.sdmagazine.com/documents/s=756/sdm9907o/9907o.htm

A Practical Guide to Feature-Driven Development by S. Palmer and J.M. Felsing (Prentice Hall, 2002).
www.amazon.com/exec/obidos/ASIN/0130676152/ambysoftinc


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video