Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Assurance & Agile Processes Emergent Properties Methodological Challenges Agile Assurance Agile Modeling

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 (www.ambysoft.com/services/ 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.

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 (www.hpl.hp.com/techreports/ 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.

Conclusion

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.

Previous Page | 1 Assurance & Agile Processes | 2 Emergent Properties | 3 Methodological Challenges | 4 Agile Assurance | 5 Agile Modeling

RELATED ARTICLES Logging In C++ : Part 2 OutSystems Updates Agile Platform SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting recls 100% .NET		TOP 5 ARTICLES No Top Articles.