In This Issue:
--AMDD: Starting off on the Right Foot
--Recently on the AM Mailing List
--Hot Links
>>Starting Off on the Right Foot
Modeling is an important part of any agile software development project; many agilists prefer to take an Agile Model--Driven Development (AMDD) approach on projects. Project-level AMDD comprises two fundamental styles: initial modeling during the first cycle/iteration of a project and detailed modeling following iterations. Initial modeling helps you to identify and understand your project's scope and to identify the most promising candidate for its architecture. In detailed modeling, you explore narrowly focused, detailed issues during your project's course. In this newsletter, I explore initial modeling.
With AMDD initial modeling, you're gaining a general understanding of what is to be built and how you're going to do it -- not defining a comprehensive model for your system. You're not doing big requirements up-front (BRUF) or big design up-front (BDUF); you're going to do just enough modeling, and you're probably not going to write a lot of documentation.
A good rule of thumb, proposed by Craig Larman, is that you need roughly one day of initial modeling for every month of your project. Therefore, if you expect the current release to require six months of development, you should spend the first week modeling. This effort is typically a series of agile modeling sessions with both developers and project stakeholders participating. Your work room should have a lot of whiteboard space to allow you to work together as a team in a very flexible manner.
For your initial requirements model, you need some form of:
1. Usage model, such as a collection of features for a Feature Driven Development (FDD) project or a collection of user stories for an Extreme Programming (XP) project. As the name implies, usage models enable you to explore how users will work with your system.
2. Initial domain model; perhaps a collection of Class Responsibility Collaborator (CRC) cards or a UML class diagram. This domain model contains just enough information: the main domain entities, their major attributes and the relationships among these entities. Your model doesn't need to be complete; it just needs to cover enough information to make you comfortable with the primary domain concepts.
3. User interface model. For user interface intensive projects, you should consider developing some screen sketches or even a user interface prototype.
On the architecture side, I'll often create:
1. Free-form sketches. I've found that 99 percent of the time, we simply need to create some free-form diagrams on a whiteboard to explore how we think we'll build the system. It's important to remember that you still must prove that the architecture works through code.
2. Change cases. An optional, and very interesting technique is to identify change cases that are potential architecture-level requirements that your system may need to support. Change cases allow you to test the long-term viability of your architecture without requiring you to overbuild your system, because you can think through the impact of likely changes to assure yourself that your system will still work.
The secret to all this? Keep things simple. You don't need to model a lot of detail; you simply need to model enough. If you're writing use cases, this may mean that point-form notes are good enough. If you're domain modeling, a whiteboard sketch or collection of CRC cards is probably good enough. For your architecture, a whiteboard sketch overviewing how the system will be built end-to-end is good enough. Again, your goal is to build a shared understanding -- not to write detailed documentation.
Many traditional developers struggle with an agile approach to initial modeling because for years they've been told they must define comprehensive models early in a project. Agile software development isn't serial; it's iterative and incremental (evolutionary). With an evolutionary approach, detailed modeling is done just in time (JIT) during construction iterations. More worrisome to traditionalists is the idea that your AMDD detailed modeling efforts -- what Extreme Programmers would call a stand-up design session or a customer Q&A session -- often last only minutes and are immediately followed by several hours of coding. But that's a discussion for another column.
>>RECENTLY ON THE AM MAILING LIST
What Is a Model?
Once again, we've bandied about this definition. The main point of
contention is whether source code is a model. If you define a model as
an abstraction, source code clearly is a model. However, when
we originally developed AM, we made a scoping decision to exclude
source code from the definition.
Title for a Position
Many organizations employ people who are responsible for process
improvement and support for the software process -- but what should
they be called? Chief Process Officer, Process Mentor, Process Coach,
Process Engineer and several tongue-in-cheek titles were suggested.
Models Customers Will Use
Someone on the list was curious about which models stakeholders
actually understand and use. In his experience, user interface
prototypes work well, which makes sense because to most people, the
user interface is the system. However, discussions about domain modeling
and usage modeling are also important. The critical issue? You
must understand a wide range of models so that you can choose the right
one for your situation.
>>HOT LINKS
Agile Model-Driven Development (AMDD) is described at
http://www.agilemodeling.com/essays/amdd.htm
For a detailed discussion of what an agile model is, visit
http://www.agilemodeling.com/essays/whenIsAModelAgile.htm
For more information about using change cases to identify future
requirements, visit
http://www.agilemodeling.com/artifacts/changeCase.htm
For a description of how to use CRC models for domain modeling, visit
http://www.agilemodeling.com/artifacts/crcModel.htm
To learn how to write essential use cases, visit
http://www.agilemodeling.com/artifacts/essentialUseCase.htm
For examples of free-form diagrams in software development, see
http://www.agilemodeling.com/artifacts/freeForm.htm
User stories are summarized at
http://www.agilemodeling.com/artifacts/userStory.htm
The Agile Alliance homepage is the best starting point for
anyone interested in learning more about agile software development.
http://www.agilealliance.org
Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm
Get agile modeling training resources at
http://www.agilemodeling.com/training.htm
