Dear Software Development Reader,
Software Development invites all vendors to participate in the 14th Annual Software Development Jolt Product Excellence Awards. We're looking for products, books and websites that have made a difference to developers in 2003 -- products that have "jolted" the industry. Will your product join the ranks of distinguished products recognized this year? Eligible books and products must have been published or had a significant version release in the calendar year 2003. Websites may be nominated even if they originated prior to 2002. Please do not nominate books in press, beta versions or unreleased products. For category descriptions go to http://sdmagazine.com/jolts/categories.html
The categories this year include:
Books: Practical/General Developer Interest
Business Integration and Data Tools
Change and Configuration Management
Design and Analysis Tools
Languages and Development Environments
Libraries, Frameworks and Components
Mobile Development Tools
Project Management Tools
Web Development Tools
Websites and Developer Networks
Deadline for nominations is December 15, 2003. The nomination fee is $150. Nominations received prior to November 15, 2003, will receive an early-bird discount of $50. Nonprofit makers of open-source products may waive their nomination fee.
More information on the Jolt Product Excellence and Productivity Awards is available at http://www.sdmagazine.com
CMP Media LLC
600 Harrison Street
San Francisco, CA 94107
-->THE AGILE ANALYSIS TOP 10
Ambler's 10 tips for successful agile analysis.
1. Active stakeholder participation is crucial.
You need to work together closely with your stakeholders to explore the business domain in detail. They must be available to supply information, to model with you, to provide feedback, and to make timely decisions.
2. Agile software development is an evolutionary process.
When you're analysis modeling on an agile project, you'll typically focus on a very small subset of the requirements at a time. For example, on an XP project, you and your programming pair may work with a project stakeholder to analyze a single user story, one of hundreds, and then move on to design and implement it. This analysis effort often takes several minutes, depending on the nature of the user story, as does the design effort. Then you'll spend several hours or days implementing the requirement only to start again with a new user story. Other agile approaches, such as Feature-Driven Development ( http://www.featuredrivendevelopment.org ), may invest a bit more time in analysis and design but they still work in a similar, evolutionary manner.
3. Analysis isn't a phase.
Analysis is something you'll do on a daily basis as an agile developer, because you're working in an evolutionary manner. It involves working with your stakeholders, as well as your fellow developers, to understand the problem domain whenever you need to. Analysis could be something as simple as asking a stakeholder, "What did you mean by this?", or as complex as drawing several diagrams to explore an aspect of what you're building. It's a much more informal than formal process, requiring open and honest communication.
4. Multiple models.
Effective developers realize that each type of model has its strengths and weaknesses; therefore they need to apply the right model(s) for the job at hand. Because software development is complex, you quickly realize that you need to know about a wide range of models in order to be effective. All of the models mentioned in this newsletter, and more, are described at the Agile Models Distilled page ( http://www.agilemodeling.com/artifacts/ ).
5. You typically need only a subset of the models.
Although there are many modeling techniques available to you, the fact is that any given project team will require only a subset. Think of it like this: In your toolbox at home, you have a wide array of screwdrivers, wrenches, pliers and so on. For any given repair job, you'll use only a few of those tools -- different jobs, different tools. You never need all of your tools at once, but over time you'll use all of them in a variety of manners.
6. Models evolve over time.
You may start with an essential use case but quickly decide to evolve it into several system use cases. Or you may decide to develop a collection of Object-Role Model (ORM) diagrams on a whiteboard as input into your design-level UML class diagram, which in turn will evolve into Java source code. It's quite common to discard the interim artifacts and keep only the final products -- remember Agile Modeling (AM)'s Travel Light principle.
7. Analysis models need to be just barely good enough.
Keep your models as simple and lightweight as possible. Focus on understanding, not documentation. Use the simplest, most inclusive tools available. Recognize that your models don't need to be perfect.
8. Each model can be used for a variety of purposes.
Data flow diagrams can be used as both an analysis technique to explore your existing business processes as well as a design technique to redefine them. Similarly, Class Responsibility Collaborator models can be used for both analysis and design and use cases for requirements, analysis and sometimes even design.
9. Modeling lines are often blurred.
The traditional concept of development phases -- requirements, analysis, designs, coding, testing and deployment -- has left many people with the idea that we need to distinguish among various types of modeling. Yet when a stakeholder describes a requirement, such as the need to capture a student's home address, we'll often work through the phases within seconds of each other. We'll start thinking about what the user interface should look like, the various data elements that will be captured, the need for an Address class, the possibility of applying the Contact Point pattern, the need for an Address table in the database, and how to code it all in Java, moving from requirements through analysis through design to code without stopping to create a complete requirements model or a complete analysis model, and so on. While it's important to ask questions such as what do you need (requirements), what does that mean (analysis), and how are we going to build it (design), often we'll be doing so in an iterative, not a serial manner.
10. Use your stakeholders' terminology.
Don't force artificial, technical jargon onto your project stakeholders. They're the ones the system is being built for; therefore, you should use their terminology to model the system.
This newsletter has been modified from forthcoming book The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 (Cambridge University Press, March 2004).
-->NEWS AND VIEWS FROM THE AM MAILING LIST
Joint Application Design
Joint Application Design (JAD) is a facilitated meeting technique popularized by IBM in the late 1970s for modeling-related activities. Dynamic System Development Method (DSDM) adherents use facilitated workshops for modeling that often take a JAD approach. The person who started the thread was curious as to the relationship between DSDM JADs and traditional JADs -- consensus seemed to be that you should make a JAD only as formal as it needs to be and no more, as you don't want to incur needless overhead.
Definition of a Model
A regular participant on the list is working in an organization that was struggling to define the term model. Debate raged over what a model is, ranging from an "abstraction" to "an abstraction of reality" to "just barely good enough." The important things are that you settle on a definition that reflects your situation and that you realize the context in which the definition applies. Your definition should be suitable for you, but it might not be for me.
Getting It Right the First Time vs. Refactoring
Within the development community, refactoring seems to be a religious issue -- agilists find that refactoring works well in practice, whereas many non-agilists seem to be adamantly against it. I suspect that many people see refactoring as a replacement for modeling, which it definitely isn't, and therefore see getting it right the first time and refactoring as opposite extremes. It doesn't have to be this way. You can take an Agile Model Driven Development (AMDD) approach to development and do just enough modeling before you implement, with refactoring as a potential part of your implementation efforts, and iterate as needed.
In "Active Stakeholder Participation," I outline why project
stakeholders must be actively involved with the software
The Agile Alliance home page is the best starting point
for anyone interested in learning more about agile software
My essay, "Agile Analysis," explores how to take an agile
approach to analysis.
"Agile Model Driven Development (AMDD)" overviews how to
take an AMDD approach on a software development project.
Visit the Agile Modeling Mailing List at
Find agile modeling training resources at
"Agile Models Distilled: Potential Artifacts for Agile
Modeling" provides links to pages containing overviews of
various modeling artifacts such as business rules, use cases,
user interface flow diagrams and UML activity diagrams.
The Database Refactoring home page describes the process
for refactoring database schemas.
Find the DSDM Consortium and details about the DSDM
Mei C. Yatco's essay, "Joint Application Design/Development"
reveals the history of JAD and the fundamentals of the technique.
Martin Fowler's Refactoring home page is the best place to
start when looking for refactoring-related information.