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."|
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 conceptsthe "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).