Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Assurance & Agile Processes


Agile Assurance

To address assurance from an agile perspective, the practices in Table 4 should be followed.

1. When a requirement cannot be effectively verified using execution tests, use the design (not the code) as the focus of evidence of correctness and completeness.
2. Ensure that requirements that are collected include assurance objectives.
3. Use test-driven development and other techniques to continually verify compliance of the implementation with ongoing design (the AM effort; see below) as well as with requirements.
4. Augment 3 with randomized testing to empirically assess actual assurance.

Table 4: Agile assurance practices.

Thus, for assurance-related requirements, our focus shifts to design rather than implementation, leaving implementation as a concurrent activity. A software implementation is merely a low-level design, and if a high-level design must remain authoritative for some aspects, then the low-level design is, by definition, subordinate to it for those aspects. We use the term "agile assurance" (AA) to refer to our approach.

To explain this approach, we discuss its implementation within the context of XP. Let's take the elements of our agile assurance approach, one by one.

Design as Evidence. Approach 1 in Table 4 states that the design is a focus on an AA effort. A design is not an objective in its own right; rather, a design is an instrument for verifying that assurance is achieved. Further, a design must be adequately documented, to the extent necessary to achieve assurance objectives, including proving that the code agrees with the design intent, and ensuring that future maintenance also complies with design intent. For this to be achievable, the design must be maintained in a concrete and durable form, such as unit tests, a document, code comments, rules specified via a design language, or any means appropriate for a project. Thus, because a high-assurance design must be sufficiently documented, in the rest of this article we use the term "design" as synonymous with "design specification."

Here, we propose an approach for capturing design (www.agilemodeling.com/ essays/amdd.htm). Agile Model Driven Development (AMDD) is the application of the principles and practices of AM on an agile project.

Identification of Stakeholders and Requirements Collection. In AMDD, stakeholders are defined as anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, support (help desk) staff member, developers working on other systems that interact with the one under development, or maintenance professionals potentially affected by the development/deployment of a software project (www.agilemodeling.com/essays/ activeStakeholderParticipation.htm).

Requirements such as security, reliability, failure recovery, disaster recovery, maintainability, and manageability cannot be treated as implicit. An agile design in a high-assurance environment requires that all assurance requirements be expressed through stakeholder stories. This requires that all of the application's stakeholders must be represented in collecting requirements. Those who have the most dynamic requirements—typically the end users—should be met with each iteration.

Continual Design Verification Augments TDD. Agile proponents know the value of test-driven design (TDD), in which a test is written and then enough production code is written to fulfill that test. Again, a primary purpose of a design should be to explain why certain features exist in the application. AMDD addresses TDD by differentiating between high-level design, which utilizes agile modeling, and detailed design, which uses TDD to define detailed behavior.

An agile design must be continually verified, in the same manner that the implementation must be continually tested. Verification must occur from two perspectives:

  • Agreement between the design and the implementation (for instance, as-built equals as-designed).
  • Verification that the design meets assurance requirements.

Empirical Testing. The very nature of assurance requirements, in that they tend to be negative requirements specifying that something cannot be done, means that it is difficult to create a high-coverage test suite. This means that some amount of empirical testing, with inputs that are randomly chosen, is necessary to measure the actual soundness of the application so that it can be compared with the designed soundness.


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.