Channels ▼
RSS

Design

Assurance & Agile Processes


Methodological Challenges

Some agile methodologies such as XP have raised questions among security and reliability experts. Their questions primarily focus around the concerns in Table 3.

1. Need for a focus on a comprehensive design.
2. Need for a focus on documentation of the design and its intent.
3. Need for a focus on nonfunctional testing.
4. Need for a separation of high-risk modules, in light of "collective code ownership."

Table 3: Assurance concerns often raised for agile methods.

For example, in their paper "Modeling and Implementing Software Architecture with Acme and ArchJava," Abi-Antoun et al. assert that the benefits of architecture are "contingent upon correct implementation [with respect to] program understanding, software evolution, checking architectural constraints, [and] analysis of quality attributes" (www.cs.cmu.edu/~aldrich/ papers/icse05-demo.pdf). This is a widely held view in the security and software assurance communities.

Items 1 and 2 in Table 3 have to do with defining, disseminating, and perpetuating architectural intent. "Intent" is the "why" that we previously discussed. Because TDD focuses on specification in the form of a unit test suite, the TDD-style of checking architectural intent would be to implement architectural rules as a test suite. A less formal approach is for the architects to be active members of the development team, thereby ensuring that design intent is adhered to because they're actually building it themselves (see The Practical Guide to Enterprise Architecture, by James McGovern et al., Prentice Hall PTR, 2003). Still, the assumptions and concepts—the "why"—should be written down and maintained.

Agile Modeling (AM) was specifically designed to be tailored into other agile methods to address the modeling and documentation issue. Similarly, TDD can be tailored to address assurance testing issues (www.testing.com/cgi-bin/blog/2003/08/ 21#agile-testing-project-1).


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