Channels ▼


Assurance & Agile Processes

Agile Modeling

Development of the Agile Modeling (AM) methodology was led by one of us (Scott). Agile Modeling is a collection of values, principles, and practices for modeling software that can be applied on a software-development project in an effective and lightweight manner. AM provides a framework of practices for developing and maintaining an application design. AM is meant to be tailored into other, full-fledged methodologies such as XP, RUP, or the Agile Unified Process ( agileUP.html), letting you develop a software process that truly meets your needs.

Agile Model Driven Development (AMDD). Agile Model Driven Development (AMDD) is the application of AM to the software design and development process. Figure 1 shows that with AMDD, you do just enough high-level modeling at the beginning of a project to understand the scope and potential architecture of the system, and then during development iterations you take a just-in-time (JIT) model-storming approach where you model for several minutes as a precursor to several hours of coding. Extreme programmers (XPers) would call model-storming sessions stand-up design sessions or customer Q&A sessions.

Figure 1: The AMDD Lifecycle.

The Use of Agile Modeling (AMDD) for Achieving Assurance. The goal of AMDD is to provide a structure to the design aspect of agile development. There are four AM practices that have strong assurance benefits:

  • Apply the Right Artifact(s). The design should address how each assurance requirement is satisfied. This should include a discussion of the intent of each design element, in the context of any applicable abstract models that were developed.
  • Collective Ownership. We claim that assurance concerns mandate some moderation of the XP tenet of collective code ownership. A strong case can be made that high-risk modules should be updateable only by a subset of the developers on a project—the implication for a pair programming team is that at least one member of a pair must be allowed to do such an update. This applies to the design of those modules as well, and the contracts that specify their interfaces.
  • The reason for this separation comes back to risk management. Not everyone on a team is as experienced in the issues that are pertinent to the design of every module in an application.
  • Formalize Contract Models. There is a long history in the security and reliability professions of the importance of hierarchical decomposition of function. Contracts between different layers or different components are extremely important and such contracts need to be formalized and verified.
  • There is also a long-established security concept of minimizing the trusted computing base. This concept applies to reliability as well. For it to succeed, the most failure-critical portions of an application should be delineated so that special attention can be paid to them. This is simple risk management. "Risk" is simply the product of the cost of failure and complexity ( 2001/HPL-2001-132.html). Establishing formal contracts between high-risk modules and other modules helps to ensure that risk is contained within those components that are considered to represent the highest risk.
  • Update Only When It Hurts. Keeping the model up-to-date addresses a major concern of assurance experts. For example, the assertion cited by Abi-Antoun et al. that the benefits of architecture are "contingent upon correct implementation" is addressed by ensuring that it reflects the implementation.


Assurance does not conflict with agility—it merely challenges it. For those applications that need it, a high-assurance process can be employed that retains the agility that the business needs to be able to respond to market changes and organizational changes. Explicit steps must be taken to ensure that the required assurance will be provided by the software application, so that it holds up under the stresses of high-visibility, high-usage, and mission-critical dependence that is characteristic of so many of today's Internet-facing applications in large organizations.

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.