Channels ▼


Assurance & Agile Processes

Cliff is founder of Assured By Design and author of High-Assurance Design (Addison-Wesley Professional, 2005). He can be contacted at [email protected]

Scott is a software process improvement consultant, mentor, and trainer with Ambysoft Inc. He can be contacted at

For organizations of all sizes, security failures can have devastating consequences. But security is only one aspect of overall application reliability. Indeed, it is often possible to equate the cost of a security failure with a given level of downtime. Thus, overall assurance of an application—that is, its ability to perform as required and resist or recover from failure of any kind—is really the key issue that organizations need to consider.

While the improved productivity achieved by agile software development practices is compelling, agile methods such as Extreme Programming (XP) do not explicitly address security and reliability. Why not? Because the assumption is that these issues will be addressed by the project's customers. Some have addressed the issues from the perspective of testing ( evaluating-test-suites-paper.pdf) and design (Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, by Scott Ambler, Wiley, 2002) or security (e.g., Beznosov, Towards Agile Security Assurance, presented at Still, there needs to be a cohesive agile framework that addresses assurance.

The Importance of Design for Assurance

To avoid constantly saying "architecture and design," we use the terms "architecture" and "design" interchangeably. After all, an architecture is merely a high-level design, and for purposes here the distinction is not important.

Newcomers to some agile methods think that design is passé, a myth dispelled in many sources ( whoNeedsArchitect.pdf). In Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, one of us (Scott) explains why long-term objectives need to be considered if they are important to the organization. For example, objectives such as maintainability may mean that certain kinds of documentation are required as deliverable artifacts. The key is to create "agile documents" ( agileDocumentation.htm).

Let's be clear about what a design is. A design is an enumeration or description of elements or attributes of an application's intended manifestation. Design may also address semantic elements, such as relationships between structural elements, sequence, cardinality, and in general, any aspects important for implementers to know to be able to produce an implementation that adheres to the design's intent.

The embodiment of a design is a set of artifacts. The artifacts can be code, unit tests, diagrams, or documented decisions about important technical issues. These are not mutually exclusive.

In 2004, Peter Neumann stated, "Good system and network architecture is perhaps the most fundamental aspect of any efforts to develop trustworthy systems..." ( neumann/chats4.html). The reason behind this belief is that a design embodies the concepts that ensure that the system has certain hard-to-test properties, such as being secure. The design addresses how these properties are achieved, via the components of the design and their required relationships.

A design should not only state what elements exist in an application, but it should also state why they exist. For example, if a particular software layer exists to protect an underlying resource, then the layer should not be eliminated in order to simplify the design. The layer exists to satisfy a security requirement, and the layer's design should state how that is achieved. To explain how, you must ask "why?"; otherwise, you are explaining how something happens that you do not even have an expressed justification for.

There is another reason that "why" is important: It expresses a conclusion about the adequacy of a feature. That conclusion is then open to challenge. Agile design is about evolving a solution over time, and about continually challenging each "why" and its associated conclusions.

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.