Dr. Dobb's Agile Newsletter

AMDD and TDD go hand-in-hand


February 19, 2007
URL:http://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-newsletter/197007231

In This Issue

Model Storming Before Testing

Test-driven development (TDD) has taken the agile world by storm. Rightfully so -- it's an incredibly effective technique. TDD promotes confirmatory testing of your application code and detailed specification of that code. Customer tests, also called "agile acceptance tests," can be thought of as a form of detailed requirements and developer tests as detailed design. Having tests do "double duty" like this is a perfect example of single sourcing information, a practice which enables developers to travel light and reduce overall documentation. However, detailed specification is only part of the overall picture -- high-level specification is also critical to your success, when it's done effectively. This is where Agile Model Driven Development (AMDD) comes in.

In previous newsletters I've discuss the initial modeling efforts which occur during "Iteration 0" of an agile software development project. At the beginning of a project you need to do just enough modeling to understand the scope of the system and to identify the initial architectural vision for the system. In this newsletter I want to explore the relationship between just-in-time (JIT) detailed model storming which occurs during construction iterations and the detailed specification effort which occurs as part of TDD. On disciplined agile projects, particularly those which need to scale beyond a handful of people co-located in a single room, AMDD and TDD go hand-in-hand.

Customer tests are one form of detailed requirements specification, a particularly effective one considering that it also validates the requirement (if you're using the right tools). However, sometimes we need more than a detailed definition. Models, in particular those which explore usage such as use cases, provide context for the customer tests. A single use case could encapsulate 10 or more customer tests, showing how they interrelate with each other and more importantly providing motivation for further acceptance tests which validate a complete business transaction.

Other models provide important views which text-based customer test can never hope to address. For example, a user interface sketch or prototype can be used to explore the layout of a screen whereas a user interface flow diagram explores the flow between screens. Because the user interface is the system to the vast majority of end users, these models can be critical to create because they reveal potential usability problems long before a line of code is ever written.

I want to be perfectly clear about the fact that you don't need to create these models up front, nor do you need to invest a lot of time creating them in detail. Instead you can create them in a JIT manner via model storming to the level of detail that you require at the time. A model storming session typically lasts just a few minutes -- several people get together in an impromptu manner, explore an issue, and then continue doing something else. For example, on an Extreme Programming (XP) project you might pick a user story off the work queue which is worded something like "Capture the Shipping Address Upon Checkout". It would be reasonable to model storm with your stakeholder(s) for a few minutes, drawing a whiteboard sketch of what this part of the user interface should look like. Once you're satisfied that you understand the requirement, you then identify a related customer test and implement enough code to fulfill that test. You would iterate through writing a test and then enough code to fulfill that test until the functionality is fully implemented. The model storming effort may take between 5 to 10 minutes and the TDD-based implementation several hours or even days. Yet that simple model, merely a hand-drawn sketch, would capture the critical thinking required to ensure success which wouldn't have easily been captured in the customer tests. In other words, there's still value in modeling.

On the design side of things sometimes a model can provide important context for your development TDD efforts. Design models enable you to think through issues before diving into the code, thereby avoiding costly mistakes. This doesn't mean that you need to do a lot of detailed modeling up front: some whiteboard sketching to explore several alternatives before jumping into coding can save days, and sometimes weeks, of effort going down the wrong technical path.

My main point is that AMDD enables you to think through high-level issues whereas TDD is well suited for the detailed issues. The secret is to apply the right technique for the situation at hand -- sometimes you want to create a model, sometimes you want to write a test. TDD is a wonderful development technique, very likely one of the most important ones to come our way in quite a long time, yet like all other techniques it's limited in scope. AMDD addresses the weaknesses of TDD, and AMDD would be little more than drawing pretty pictures without development techniques such as TDD.

Although I've mentioned whiteboards several times, my experience is that whiteboards are one of the most effective tools available to a development team, this doesn't say that you can't model storm using sophisticated modeling tools as well. If you have the modeling tools available to you, and the skill to use them properly, then you can dramatically increase your overall productivity. But that's a topic for another newsletter.

Book Review: Journey to Data Quality

From a theoretical point of view Journey to Data Quality, by Y.W. Lee et. al, is a great read which I highly suggest to all data professionals and to senior IT management. The book starts with a discussion of the cost/benefit of data quality, something which should be an eye-opener to any IT professional -- some estimates claim that business is impacted by poor quality data by as much as 8-12 percent of revenue. Chapters 3 through 5 describe how to assess the quality of data, the first step in understanding where to invest effort for addressing the data problems that your organization faces. Chapter 6 describes the root causes of data quality problems and Chapter 7 works through a case study within a health-care organization. Chapter 8 is arguably the most valuable one within the book, arguing that information should be managed as a product, not just as a by-product of systems, a philosophy which motivates quality practices within an organization. Chapter 9 overviews a type of model known as an information product (IP) map, a combination of a flow chart and data-flow diagram (DFD). Chapter 10 describes another case study, Chapter 11 summarizes the main points of the book, and Chapter 12 provides a vision for succeeding at the long journey ahead of you.

From a practical point of view this book was a bit of a disappointment. Although there is a lot of advice which organizations can use to improve their overall data quality processes, most of them seem to be based on increasing the overall complexity of your software process and the supporting bureaucracy. There was no mention of testing at all. Call me old fashioned, but a comprehensive testing strategy should be part of any quality program that you embark on. Without a doubt this book is a good start on the path to data quality, but it will only get you so far.

Journey to Data Quality

Y.W. Lee, L.L. Pipino, J.D. Funk, and R.Y. Wang.

MIT Press, 2006

www.amazon.com/exec/obidos/ASIN/0262122871/ambysoftinc/

--SWA

Hot Links

The Agile Alliance is the best starting point for anyone interested in learning more about agile software development.

Agile Model Driven Development (AMDD) is described in detail here.

My January 2007 column, Agile Testing Strategies, describes how agilists go about testing their systems.

The article System Use Cases overviews how to write use cases in several different styles from point-form to very detailed.

Introduction to User Interface Flow Diagrams describes how to draw high-level diagrams which explore the UI architecture of your system.

Introduction to Acceptance Tests as Requirements Artifacts describes acceptance/customer tests and shows how they are an important type or requirement specification.

Introduction to Test Driven Development (TDD) overviews the process behind TDD.

Agile Models Distilled provides links to overviews of a wide variety of models.

The Principles of Agile Modeling v2 are described here.

The Practices of Agile Modeling v2 are described here.

Check out the Agile Modeling mailing list.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.