Am 5

Examining the Model Driven Architecture (MDA)
The Model-Driven Architecture (MDA) defines an approach to modeling that separates the specification of system functionality from the specification of its implementation on a specific technology platform. In short it defines a guidelines for structuring specifications expressed as models. The MDA promotes an approach where the same model specifying system functionality can be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms. It also supports the concept of explicitly relating the models of different applications, enabling integration and interoperability and supporting system evolution as platform technologies come and go. Download: Point-Counterpoint article in IEEE Software (September/October 2003) (90k PDF) As I have written in Enterprise Architecture Techniques I'm concerned about the viability of the MDA. My feeling is that although the MDA is a very wonderful idea I suspect that it will succeed in only a very small percentage of organizations. Because of my writings questioning the viability of the MDA vision I was invited to be involved in a Point-Counterpoint article in IEEE Software. Interesting questions that I think need to be asked regarding the MDA: 1. 2. What level of education and training is required by developers to use MDA tools? What makes us think that the tool vendors will honestly try to support model sharing standards in a competitive marketplace? Particularly when past experiences with other industry standards such as CORBA have shown a willingness of vendors to announce support for standards but in practice to implement the standard in their own unique manner? 3. What makes us think that the underlying modeling language, the UML, is sufficient for the task at hand? Perhaps we should define the modeling languages which we use via open source, not via committee? I suspect that we need to extend the UML beyond object and component technology. 4. How will MDA-based models be tested? 5. How will MDA-based models handle the inherent complexities of legacy system integration? 6. What evidence exists that MDA isn't simply a repeat of the 1980s I-CASE vision? 7. Is developing these complex models really more productive than other options, such as agile development techniques? 8. How will configuration management of models work in team-based environments? 9. How could you possible develop a "platform independent model (PIM)" when there isn't a standard action semantic language (ASL) supported across the toolsets of various vendors? The PIMs will be dependent on the modeling tool. 10. Have you ever had one of your business stakeholders ask you to develop detailed, sophisticated, platform independent models using a precise industry-standard modeling language which describes their business? 11. Are You Ready For the MDA? 12. Is the MDA vision simply a solution desperately looking for a problem? The Point-Counterpoint article is Copyright 2003 IEEE. Reprinted from (all relevant publication info). This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of my products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by sending a blank email message to pubs-permissions@ieee.org. You can also visit http://computer.org/copyright.htm for more information.
Recommended Resources
Agile Modeling Best Practices Be Realistic About the UML Comparing the Various Approaches to Modeling in Software Development David I's (of Borland Fame) Blog entry describing the OOPSLA 2004 that I was on
The Diagrams of UML 2.0 Introduction to the Diagrams of UML 2 Introduction to Object Orientation (OO) and UML Open Sourcing our Modeling Languages MDA: The Vision with the Hole? (Ashley McNeile) MDA Distilled (Steve Mellor) MDA From a Developer's Perspective MDA: Revenge of the Modelers or UML Utopia (Dave Thomas) Modeling Style Home Page A Roadmap for Agile MDA Why Extend the UML Beyond Object and Component Technology?
Generalizing Specialists: Improving Your IT Career Skills
I believe that to become an agile software developer that you need to move away from being a narrowly focused specialist to become more along the lines of what I like to call a generalizing specialist (a concept I first discussed in Agile Modelingalthough I introduced the term in Agile Database Techniques). This article is organized into the following sections:
Generalizing specialist: A definition Becoming a generalizing specialist Why generalizing specialists? Generalizing specialists and the whole team practice What about specializing generalists? Generalists vs. generalizing specialists Is there still room for some specialists?
Generalizing Specialist: A Definition A generalizing specialist is someone who:
1. Has one or more technical specialties (e.g. Java programming, Project Management, Database
2. 3. 4. Administration, ...). Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.
Generalizing specialists are often referred to as craftspeople, multi-disciplinary developers, cross-functional developers, deep generalists, polymaths, versatilists, or even "renaissance developers".
Becoming a Generalizing Specialist When you get your first job as an IT professional it is often in the role of a junior programmer or junior DBA. You will initially focus on becoming good at that role, and if youre lucky your organization will send you on training courses to pick up advanced skills in your specialty. Once youre adept at that specialty, or even when youve just reached the point of being comfortable at it, it is time to expand your horizons and learn new skills in different aspects of the software lifecycle and in your relevant business domain. When you do this you evolve from being a specialist to being a generalizing specialist.
Figure 1. How a generalizing specialist's skills may evolve over time.
Figure 1 depicts a fictional skills assessment of an IT professional, showing how it evolves over time. In this example, the person has solid skills in Java development, and some initial skills in modeling, testing, and database administration (DBA). Then, two years later, they've improved all of their skills, including their Java programming skills. They may have achieved this through training & education,mentoring, or collaborative techniques such asmodeling with others or pair programming. Then, three years later their skills have improved further, although it's interesting to note that focus on a new skillset (.Net programming) may have motivated the person to let their Java programming skills go stale. It's incredibly rare for someone to become "super skilled" at everything, more on this later, although it is quite common for a generalizing specialist to become more skilled than either a generalist or a specialist. As an individual it's an incredibly good strategy to become a generalizing specialist. The greater your skillset, the more likely that you'll be in demand and the easier it will be for your to gain employment. Furthermore, you'll likely get better jobs than you would have because of your greater productivity and versatility. Just like you wouldn't have a stock portfolio with a single stock in it (that's an incredibly risky investment strategy) you shouldn't have a skills portfolio with only one specialty.
Just like multidisciplin ary teams are a good idea, so are multidisciplin ary people.
Why Generalizing Specialists? There are several reasons why you should prefer to build teams from generalizing specialists:
1. Improved communication and collaboration. A generalizing specialist is someone with a good

grasp of how everything fits together. As a result they will typically have a greater understanding and appreciation of what their teammates are working on. They are willing to listen to and work with their teammates because they know that theyll likely learn something new. Specialists, on the other hand, often dont have the background to appreciate what other specialists are doing, often look down on that other work, and often arent as willing to cooperate. Specialists, by their very nature, can become a barrier to communication within your team. Another challenge with specialists is that they have difficulty working together effectively with others because they dont have the background to understand the issues that the others are trying to deal with. Less documentation. Specialists are often motivated to create far more documentation than is required, when all you can do is write use cases then those use cases will end up including information that could be better recorded elsewhere, and very likely require reviews of said documentation when they provide it to other specialists. The implication is that the same piece of information will often be captured by several specialists because theyre afraid that theyll lose that information. Its quite common on projects dominated by specialists to see a business rule captured in a user interface specification, in a business rule specification, in a logical data model (LDM), in a UML class diagram, in acceptance tests, and in source code. Clearly theres a chance that the business rule will be described inconsistently (thereby motivating more bureaucracy in the form of traceability) let alone the obvious overhead involved with reviewing and maintaining each version of it. A generalizing specialist will write less documentation than a specialist because they have a greater range of options available to them. Instead of having a user interface specialist capture the rule in a screen specification, the data specialist capture it in an LDM and so on the generalizing specialist will instead capture it in the most appropriate place(s). In this case that could be in the form of one or more acceptance tests as well as in the source code. In short, a generalizing specialist can choose the best artifact to to capture the information in one and one only place. The implication is that a team composed of generalizing specialists will be more effective than one composed of specialists. Improved flexibility. In his discussion of integrating usability specialists onto an agile team, Paul Hodgetts discusses several practices which result in productivity loss which are motivated by having specialists on your team. Specializations forces the team to pre-assign tasks to individuals, thereby hindering the team's ability to dynamically allocate tasks as new circumstances emerge. Less risk. Specialization drives teams to break down their iteration tasks to accommodate each person's specialty, resulting in finer-grained tasks and more points of hand-off between people. This can be seen in the diagram of Figure 2 where each specialist does their work, handing it off to the next specialist. The problem is that every time there is a hand-off between people there is information loss, documentation is the worst option for communicating information between people (see discussion about the CRUFT calculation), thereby increasing overall project risk. Figure 3 shows
2.
3.
4.
5.
how an agile team would be organized -- instead of throwing artifacts "over the wall" to one another agile team members instead share the artifacts between them, working together to evolve the artifacts as needed and when needed, learning from each other as they do so. This lowers overall risk because there is less information, greater knowledge of the system amongst individual team members, and growing skills amongst team members. Fewer bottlenecks. Specialists become bottlenecks, reducing overall team efficiency, when work queues up for them. For example, a single database administrator (DBA) is assigned to support four development teams due to lack of database expertise amongst other people. This would be perfectly fine if the four teams generated less than one person's worth of data work in total, but in most organizations as soon as it was recognized that the DBA had slack time available to them they'd likely be assigned to one or more other teams until they finally had no more slack time available to them. So, because work load isn't consistent work will queue up for them sometimes, which means that the teams which they're supporting need to wait for them to get the work done, reducing overall team efficiency as a result. The specialist in effect becomes a bottleneck. Sadly, assigning experts to multiple teams is perceived by traditionalists as efficient because they look at it from the point of view of resource allocation instead of the point of view of overall team effectiveness.
Figure 2. A traditional software development team.
Figure 3. An agile software development team.
Generalizing Specialists and the Whole Team Practice The Whole Team practice, popularized by Extreme Programming (XP), recommends that you include everyone on the team with the skills and perspectives required for the team to succeed. Furthermore, it
recommends that everyone on an agile team contributes in any way that they can. If people are generalizing specialists then it becomes much easier to form whole teams because it will be easier to find someone with the skills that you need. If people are specialists then you'll find it much more difficult, and you'll often be forced to have a single person work on multiple teams because those teams need someone with their specialty.
What About Specializing Generalists? Sure, why not? In this case someone starts as a generalist and then picks up one or more specialties. This would be just another path, albeit a rare one, to the same strategy.
Generalists vs. Generalizing Specialists A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few. Big difference. A team of generalists can easily flounder because none of them have the skills to get things done. Similarly, a generalizing specialist is more than just a specialist. A specialist is narrowly focused on a single topic, making them very effective at that topic but not at others. Specialists will often be blind to the issues which Figure 4. Between the extremes. other specialists focus on, and as a result will struggle to work with those other specialists effectively. As Figure 4 indicates, people who are generalizing specialists are in the "sweet spot" between the two extremes of being either just a specialist or just a generalist, enjoying the benefits of both but not suffering from their drawbacks. Figure 5 compares people following different skilling strategies -- in this case I'm showing only four potential skills (S1 to S4) to make my point, but in the real world you would consider much more than just four. There are three important points that I hope to make with this diagram: 1. Generalizing specialists are not just generalists. Time and again I've found that people confuse the concept of a generalizing specialist with that of a generalist, but as you can see a generalizing specialist has a much different skills profile than a generalist. Remember, a generalizing specialist has a general knowledge PLUS one or more specialties, whereas a generalist just has general knowledge. Figure 5. Comparing various skill strategies. 2. Generalizing specialists are typically not "super skilled". Although a generalizing specialist will eventually become more skilled than either someone who is just a specialist or just a generalist, that doesn't mean that they are an expert at everything. The IT industry changes too quickly so that someone can become expert at everything (regardless of what their ego may be subconsciously telling them) so it's clearly unrealistic to expect this of someone. 3. Generalizing specialists are not just specialists. A specialist is someone who is narrowly focused in a single skill, although will likely have minimal skills in a few other domains as you see in Figure 5.
Is There Still Room For Some Specialists? The quick answer is yes, depending on the context. There are two categories of situation where your team may find the need for specialists:
1. Short-term unique activities. For example, your team may find that it needs to setup and configure a
database server. Although you could figure it out yourselves, its probably easier, faster, and less expensive if you could have someone with deep experience help your team for a few days to work with you to do so. This person could be a specialist in database administration. These one-off situations often occur at the beginning of a project or at the end of the project, what Disciplined Agile Delivery (DAD) would refer to as the Inception or Transition "phases" of your project. In scaling situations. At scale you may find that the complexities you're dealing with may require specialists focused on addressing those complexities in an ongoing manner throughout your project. The scaling factors called out in the Agile Scaling Model (ASM) can help to make this a bit clearer. For example, your team may find itself in a situation with high technical complexity, which in turn makes your build so complex that you need someone(s) specifically focused on being "buildmeisters". In situations of domain complexity or organizational complexity you may bring one or more business analyst specialists onto the team to help you explore the problem space youre working in.
2.
Bottom line is that it it isnt a black and white world and you will need specialists from time to time.
Conclusion In many ways a generalizing specialist is simply a software craftsperson. The reason why I dont use the term software craftsperson is that it is a loaded one that is likely to turn off a large number of traditional developers that prefer something along the lines of "software engineer". I believe that generalizing specialist is more palatable. In short, my experience is that generalizing specialists are much more effective than either specialists or generalists. The best developers are generalizing specialists, or at least actively are trying to become so. There is still room for specialists within your IT department, they can often act as internal consultants to your development teams, but as IT departments become more agile I suspect that we will see fewer specialists surviving over time. Robert A. Heinlein said it best: "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
Evidence that Agile Software Development Scales Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes (Paul Hodgetts) The Longevity of IT Skills Rethinking Business Analysts Roles on Agile Teams: From Small to Large
Strategies for Effective Training and Education (T&E) in I.T. Inclusive Modeling: User Centered Approaches for Agile Software Development
One of the core practices of Agile Modeling (AM) is Active Stakeholder Participation, which insists that stakeholders be available to provide information, make decisions, and even be involved in modeling. Although many traditionalists will tell you that its preposterous to expect stakeholders to be actively involved in modeling, agilists know otherwise, as do user centered design (UCD) practitioners. Unfortunately most stakeholders don't understand the complex diagrams preferred by many traditional modelers, nor do they want to take the time to learn them (the same thing can be said of many developers, but that's a different discussion). The implication is that the models typically supported by software-based modeling tools will hinder communication with stakeholders rather than foster it. The secret is to adopt inclusive models which use simple tools and simple techniques that stakeholders can easily learn and therefore use to help capture and analyze requirements for your system. Yes, some stakeholders have the ability to understand some of the more
sophisticated modeling techniques, and can learn to use complex modeling tools, but it's rare to find such people in practice (when you do, act accordingly). The point is that "inclusive" is situational, although my experience is that the simpler the tool or technique the more inclusive it becomes. Inclusive models can be used to improve the communication which you have with your project stakeholders. Stakeholders can be active participants in modeling if developers are willing to work with inclusive models. Yes, you will very likely find that you need to use other types of models in order to design your software, and thats ok. Inclusive models and inclusive tools are an important aspect of model storming. If you truly value interactions and individuals over processes and tools as theAgile Alliance suggests then youll consider adopting inclusive modeling techniques.
Simple Tools There are many simple tools available to you, including:
Whiteboards Index cards Post-its Flip chart paper String Word processor (ok, not so simple but most people know how to use them)
The DDJ 2008 Modeling and Documentation survey explored how people approach modeling and documentation. Figure 1 summarizes the results of the question that looked into the primary approach to modeling, and regardless of development paradigm sketching was the most common approach to modeling. The point is that inclusive modeling is a common strategy. Figure 1. Primary approaches to modeling.
Simple Techniques The following table summarizes common inclusive modeling techniques, and Agile Models Distilled summarizes a larger number of models (many of which are technical in nature). The examples are from a university system case study or from an online e-commerce system. Techniq Sugges Usage Example
ue
ted Tool Change case: Registration will occur completely via the Internet. Likelihood: Medium likelihood within two to three years, very likely within ten years. Impact: Unknown. Although registration will be available online starting in September, we currently expect less than one quarter of registrations to be made via the Internet this year. Response time will be an issue during the peak use periods, which are the two weeks prior to the beginning of classes each term, as well as the first week of classes.
Change Cases
In Explore potential, architectural level requirements to identify potential changes which W could occur in the future.
Class Responsi bility Collabor ator (CRC) cards
Explore business entities, such as Student and Seminar, and the relationships between them via domain In modeling. Developers can use CRC cards to do detailed structural modeling of their object designs.
Essential Use Cases
Explore how people will Name: Enroll in Seminar

Fl use a system. Identifier: UC 17
Basic Course of Action:
Student provides her name and student number Registrar verifies the student is eligible to enroll in seminars. If not eligible then student informed and use case ends. Registrar asks student which seminar theyd like to enroll in. If they dont know registrar provides student with course catalog if required. Student chooses a seminar or decides not to enroll at all. Registrar checks student record to see if student has previously passed prerequisite courses. If not eligible student is asked to choose another. Registrar validates the seminar fits into students schedule. Registrar calculates fees Student verifies the cost and either indicates she wants to enroll or not. Registrar enrolls the student in the seminar and bills them for it. The registrar writes enrollment receipt.

Essential User Interface Prototyp es
Fl
Identify user interface requirements without committing to a design too early in the project. Po

Features
Add a student to a seminar waiting list.
In Identify what people would like from the system W
Calculate the average mark on a transcript.
Drop a student from a seminar.
Free Form Diagram s
Pretty much everything.

W
Pa

User Interface Sketch
W Define rough design of a screen or page.
Pa
User Stories
Explore how people will

In use a system.
Agile Analysis Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Best Practices Agile Requirements Change Management Agile Requirements Modeling Agile Testing Strategies Best Practices for Agile/Lean Documentation The "Change Prevention" Anti-Pattern Examining the "Big Requirements Up Front (BRUF)" Approach Inclusive Modeling Model a Bit Ahead Prioritized Requirements: An Agile Best Practice Rethinking Business Analysts
Change Cases Change cases (Bennett 1997) are used to describe new potential requirements for a system or modifications to existing requirements. Change cases are modeled in a simple manner. You describe the potential change to your existing requirements, indicate the likeliness of that change occurring, and indicate the potential impact of that change. Figure 1presents two change cases, one potential change that is motivated by technical innovation this case the use of the Internet in and a second by a change in your business environment. Notice how both change cases are short and to the point, making them easy-to-understand. The name of a change case should describe the potential change itself. Figure 1. Change cases. Change case: Registration will occur completely via the Internet. Likelihood: Medium likelihood within two to three years, very likely within ten years. Impact: Unknown. Although registration will be available online starting in September, we currently expect less than one quarter of registrations to be made via the Internet this year. Response time will be an issue during the peak use periods, which are the two weeks prior to the beginning of classes each term, as well as the first week of classes. -----------------------------------------------------------------------------------------------------------Change case: The university will open a new campus. Likelihood: Certain. It has been announced that a new campus will be opened in two years across town. Impact: Large. Students will be able to register in classes at either campus. Some instructors will teach at both campuses. Some departments, such as Computer Science and Philosophy, are slated to move their entire programs to the new campus. The likelihood is great that most students will want to schedule courses at only one of the two campuses, so we will need to make this easy to support.
Change cases can be identified throughout the course of your overall development efforts, although I have a tendency to create them when Im focusing on architectural modeling. Change cases are often the result of brainstorming with your project stakeholders. Good questions to consider include:
How can the business change?
What is the long-term vision for our organization? What technology can change? What legislation can change? What is your competition doing? What systems will we need to interact with? Who else might use the system and how?
My experience is that you can use change cases in a very agile manner. First, they enable you to consider long term issues and potential changes that your system may need to support. This puts you in a position to make better architectural decisions, such as choosing one platform over another, and thus increase the chance that youre taking the best approach. This in turn reduces your desire to overbuild your system because youre not as worried about the architectural choices youve made. Second, change cases provide an easy way for you to justify architectural decisions that youve made because you can show that youve considered a wide range of issues. This can help to reduce the politics that your team has to endure, allowing you to spend more time actually building software instead of attending meetings. Third, if you identify a very high-likelihood change case you can simply write it up as a normal requirement(s) with your stakeholders. They can prioritize the requirement(s) as usual and your team can then implement it as appropriate. Your architecture should be based on real requirements, otherwise you risk goldplating your system with really cool features that your stakeholders dont actually need. Fourth, they're simple. See the Change Case Template available for free download.
Source This artifact description is excerpted from Chapter 10 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.
Suggested Reading
Artifacts for Agile Modeling: The UML and Beyond Change Case Template Modeling Style Guidelines Why Extend the UML Beyond Object and Component Technology?
Essential (Low Fidelity) User Interface Prototypes The user interface (UI) is the portion of software with which a user directly interacts. An essential user interface prototype (Constantine and Lockwood 1999), also known as an abstract prototype or paper prototype, is a low-fidelity model, or prototype, of the UI for your system. It represents the general ideas behind the UI, but not the exact details. Essential UI prototypes represent user interface requirements in a technology independent manner, just as essential use case models do for behavioral requirements. An essential user interface prototype is effectively the initial statethe beginning pointof the user interface prototype for your system. It models user interface requirements, requirements that are evolved through analysis and design to result in the final user interface for your system, enabling you to explore usability aspects of your system. Two basic differences exist between essential user interface prototyping and traditional UI prototyping. First, with essential UI modeling the goal is to focus on your users and their usage of the system, not system features. This is one of the reasons you want to perform essential use case modeling and essential user interface prototyping in tandem: they each focus on usage. Second, your prototyping tools are simple, including whiteboards, flip-chart paper, and sticky notes. The minute you introduce electronic technology to your prototyping efforts you have most likely made a design decision about the implementation technology. If you use an HTML development tool to build a user interface prototype, then you may immediately narrow your design space to the functionality supported within browsers. If you choose a Java development environment, then you may narrow your design space to Java, and if you choose a Windows-based prototyping tool, you may narrow your design space to whatever is supported on the Windows platform. Right now, you should be focused
on requirements, not design; therefore, you dont currently want to use technology-based prototyping tools. Understand the problem first, and then solve it. So how do you use sticky notes and flip-chart paper to create an essential user interface prototype? Lets start by defining several terms. A major user interface element represents a large-grained item, potentially a screen, HTML page, or report. A minor user interface element represents a small-grained item, widgets such as user input fields, menu items, lists, or static text fields such as labels. When a team is creating an essential user interface prototype, it iterates between the following tasks:
1. Explore system usage. Your team will explore system usage via several means. First, you will likely
work together on a whiteboard to discuss ideas, work on initial drawing together, and generally take advantage of the dynamic nature of whiteboards to come to an understanding quickly of the portion of the system you are discussing. For example, with the university system, you may gather around a whiteboard to make an initial drawing of what a university transcript would contain or what a seminar enrollment submission would contain. Second, as you have seen, essential use case modeling is an effective technique for understanding the behavioral requirements for your system. Model major user interface elements. Major user interface elements, such as potential screens and reports, can be modeled using flip-chart paper. I say potential because whether something is a screen or printed report is a design decisiona university transcript could be implemented as an HTML page your users view in a browser, as a paper report that is printed and mailed to students, or as an application screen. Each piece of flip-chart paper is given a name, such asStudent Transcript or Seminar Enrollment Request, and has the appropriate minor user interface elements added to it as needed. Pieces of flip-chart paper have several advantages: they can be taped to a wall; they are good for working in groups because they make it easier for everyone to see and interact; they are large enough so you can put many smaller items such as sticky notes on them; you can draw on them; and they can be stored away between modeling sessions. Model minor user interface elements. Minor UI elements, such as input fields, lists, and containers (minor UI elements that aggregate other minor UI elements) are modeled using sticky notes. Constantine and Lockwood (1999) suggest using different color notes for different types of components, for example, bright colors (yellow or red) for active user interface elements such as input fields versus subdued colors (white or tan) for passive interface elements such as containers.Figure 1 depicts an essential UI prototype to enroll students in seminars. The Student name sticky note is a container that includes four active elements: First name, Surname, Middle, and Title. The other sticky note represents a list of the seminars a student has taken or is currently enrolled in. Notice how each sticky note has a name that describes its purpose, but not how it is implemented. You can look at the sticky note and immediately know how it is used. Different sizes of sticky notes are used, indicating the relative size of each UI element. Also notice how the relative order of the UI elements are indicated by the order of the sticky notes: a students title comes before his first name, then come his initials and his surname. This ordering may change during design but for now it is close enough. Whenever you realize you may need a minor user interface element, you simply take a sticky note, label it appropriately, and place it in the general area on a major user interface element where your stakeholder believe it belongs. Sometimes you identify a minor UI element that may not have a major UI element on which to place it. Dont worry. This is an iterative process, so attempt to identify an appropriate major UI element and continue. The very fact that sticky notes do not look like a real GUI widget is a constant visual reminder to your team that you are building an abstract model of the user interface and not the real thing. Each sticky note is, effectively, a placeholder that says you need something there, but you dont yet know yet the best way to implement it, so for now, you want to leave it open. Explore the usability of your user interface. Highly usable systems are learnable, they enable user productivity, their use is easy to remember, and they are supportable.
2.
3.
4.
Figure 1. Essential UI prototype for enrolling in seminars.
Lets examine Figure 1 in greater detail. This prototype was created using a standard piece of flip-chart paper; you should use one piece of flip-chart paper per major user interface element. The name, in this case Enroll in Seminar, is typically written across the top. Notice how there is two containers, which I drew on the paper to help bound different sections of the UI. The pink sticky notes, such as Student Number and Student Name, represent input fields, whereas the yellow ones are display only.Student Name is interesting because it is a bit of a cheat, listing four separate data elements on the one sticky note. I will often do this when I know some thing always come in a group and when I think I will need the room, which, as you can see I do. The blue sticky notes, such as Search and Help, represent actions items. Action items are often implemented as push buttons, function keys, or hot key combinations, such as CTRL-SHIFT-S. All of the lists support selection of the information within them, for lists that dont support selection, you should indicate this information. I like to ask questions about how your essential user interface prototypes would be used. For example, what should happen if a student really wants to enroll in a seminar that is currently full? Should she be given the opportunity to add herself to a waiting list? If so, how does that affect the user interface? You likely need to support the capability to indicate a waiting list of X number of people already exists, as well as a way to request being added to, or removed from, the waiting list. Should obtaining detailed information about the professor teaching a seminar be possible? Should obtaining detailed information about the seminars in the prerequisite list be possible? In Figure 1 you see it is possible to search for a seminar by inputting its number or name. Should searching by the department that offers the seminar be possible? Or, by day of the week on which it is offered (when I was a student I had a 1.5 hour commute, so I tried to enroll in seminars that all were held on the same days)? Or, by the name of the instructor teaching it? These are all interesting questions, the answers for which could potentially result in new requirements. However, always remember that your project stakeholders are the official source of requirements, not developers. If you identify some new functionality that you think is required you need to convince your stakeholder that its a good idea, have them prioritize it, and add the new requirement to the stack. When youre following Agile Modelings practice of Active Stakeholder Participation this is very easy to accomplish because your stakeholder(s) would have been part of the modeling exercise to begin with.
We have been jumping through hoops not indicating implementation decisions for the major user interface elements. The reality is that you know that the seminar enrollment prototype is going to be implemented as either a screen or an HTML page, so why not admit it? When a major user interface element contains one or more minor user interface elements that permit editing, then you know its going to be a screen or a page. When it contains no editable elements, then it will be a report. If you are going to a lot of unnatural effort to make your major user interface elements independent of implementation technology, then you may want to loosen up a bit and distinguish between reports and screens/pages. In fact, once the architectural decision of how were going to deploy the system has been made, I have a tendency to draw screen sketches on a white board which enables me to get a more accurate rendering of what the screen/report may look like. However, as always my advice is always to choose the most appropriate tools and techniques for your situation.
Suggested Reading
Agile Usability: User Experience Efforts on Agile Software Projects Artifacts for Agile Modeling: The UML and Beyond Modeling Style Guidelines User Interface Design Tips, Techniques, and Principles Why Extend the UML Beyond Object and Component Technology?
Introduction to Features A feature is a small, client-valued function expressed in the form <action><result><object>. As the name implies, features are an important aspect of Feature-Driven Development (FDD) (Palmer and Felsing 2002). Figure 1 shows several features for the university system. Features are very small and typically can be implemented within a few hours. Figure 1. Features.
Add a student to a seminar waiting list. Calculate fee for a parking pass. Calculate the average mark on a transcript. Display the name and address of a student on a transcript. Drop a student from a seminar. Enroll a student in a seminar. List the prerequisites for a seminar. List the seminars of a student on a transcript. Track number of parking passes.
The features in Figure 1 are basically a formalized version, wording wise at least, of traditional features. Another formalized approach is to write features as shall statements. For example calculate the average mark on a transcript would be worded The system shall calculate the average mark on a transcript. Although the wording changes slightly in the end features and shall statements are effectively the same thing in my experience. Although one of the primary advantages of features is that their small size makes them easy to estimate and to implement their size also poses a problem in that one feature by itself rarely provides significant value to stakeholders. The solution is to organize features into groups called feature sets. Figure 2 depicts how the
features of Figure 1 would be organized into three feature sets Transcript, Enrollment, and Parking Passes. As you can see each feature set contains two or more related features.
Figure 2. Feature sets. Transcript
Calculate the average mark on a transcript. List the seminars of a student on a transcript. Display the name and address of a student on a transcript.
Enrollment
List the prerequisites for a seminar. Enroll a student in a seminar. Drop a student from a seminar. Add at student to a seminar waiting list.
Parking Passes
Calculate fee for a parking pass. Track number of parking passes.
From a requirements point of view features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are to XP theyre a primary source of requirements and the primary input into your planning efforts. However, from a size point of view feature sets are much closer conceptually to use cases. Features are estimated and prioritized in a similar manner to user stories. Because features are so simple to create it is common to use very simple tools such as index cards or a spreadsheet to capture them.
Suggested Reading
Artifacts for Agile Modeling: The UML and Beyond Modeling Style Guidelines Why Extend the UML Beyond Object and Component Technology?
User Interface Prototypes
User interface (UI) prototyping is an iterative analysis technique in which users are actively involved in the mocking-up of the UI for a system. UI prototypes have several purposes:
As an analysis artifact that enables you to explore the problem space with your stakeholders. As a requirements artifact to initially envision the system. As a design artifact that enables you to explore the solution space of your system. A vehicle for you to communicate the possible UI design(s) of your system. A potential foundation from which to continue developing the system (if you intend to throw the prototype away and start over from scratch then you dont need to invest the time writing quality code for your prototype).
As you see in the activity diagram depicted in Figure 1 there are four high-level steps in the UI prototyping process. The first step is to analyze the user interface needs of your users. User interface modeling moves from requirements definition into analysis at the point you decide to evolve all or part of your essential user interface prototype into a traditional UI prototype. This implies you convert your hand-drawings, flip-chart paper, and sticky notes into something a little more substantial. You begin this process by making platform decisions which in effect is an architectural decision. For example, do you intend to deploy your system so it runs in an Internet browser, as an application with a windows-based graphical user interface (GUI), as a cross-platform Java application, or as a mainframe-based set of green screens? Different platforms lead to different prototyping tools, for a browser-based application, you need to use an HTML-development tool, whereas a Java-based application would require a Java development tool and a different approach to the user interface design.
Figure 1. UI prototyping process.
While youre determining the needs of your stakeholders you may decide to transform your essential user interface prototypes, if you created them to begin with, with sketches. Figure 2 depicts an essential UI and Figure 3 a sketch of two potential screens or HTML pages based on that prototype. Transform really isnt the right word here seeing as Im using a completely different modeling technology now (a whiteboard instead of paper) so in effect Im replacing the essential UI prototype with the sketches.
Figure 2. Essential user interface.
I chose to split the prototype in two for cohesion issues I prefer screens that fulfill a single purpose, in this case capturing basic student information and enrolling a student in seminars respectively. This is arguably a design issue (theres a fine line between analysis and design which youll cross all the time). The sketches provide a final level of detail than the paper prototypes do, it is much easier to get a feel for how the screen will be implemented from than it is from Figure 2, although the sketch isnt as flexible because its hard to shift widgets from one part of the diagram to another whereas with the paper it is very easy.
Figure 3. Screen sketches.
As you iterate through UI prototyping you will often discover information better captured in other artifacts. Thats okay, you can follow the AM practice Iterate to Another Artifact and capture that information in the proper place. It also points to the importance of the AM practice Create Several Models in Parallel you often need to work on several things at once to get the job done. Agile software development is an evolutionary process, so this is normal. Once you understand the UI needs of your stakeholders the next step is to actually build a prototype. Using a prototyping tool or high-level language you develop the screens, pages, and reports needed by your users. With the user interface platform selected, you can begin converting individual aspects of your essential UI prototype into your traditional UI prototype. You may want to create sketches such as you see in Figure 3 or go straight to a concrete implementation, such as the HTML page depicted in Figure 4. The sketches are more inclusive, your stakeholders can be actively involved in creating them, although the actual HTML page is much closer to working code (your primary goal). Figure 4. Concrete UI prototype (HTML page).
It is critical to understand that you dont need to create a prototype for the entire system. It is very common to prototype a small portion of the user interface, perhaps a single screen or HTML page, before moving on to implementing it. Remember, agile developers work in an evolutionary manner the dont need to define everything up front before moving on. Sometimes you will need to prototype a large portion of your system, perhaps as part of an envisioning exercise or perhaps even to help define the system scope so that you can obtain project funding. After a version of the UI prototype is built, it needs to be evaluated by your stakeholders to verify that it meets their needs. Sometimes this is as easy as asking someone to spend a few minutes to look at what youve built and other times its as complicated as scheduling a meeting so that you can demonstrate the software to a group of people. I prefer the first approach. When evaluating a UI prototype Ive always found that the following questions provide me with significant feedback:
What is good about the UI prototype? What is bad about the UI prototype? What is missing from the UI prototype?
After evaluating the prototype, you may find you need to scrap parts of it, modify parts, and even add brand-new parts. You want to stop the UI prototyping process when you find the evaluation process is no longer generating any new ideas or it is generating a small number of not-so-important ideas. Otherwise, back to exploring your stakeholders UI needs.
Suggested Reading
Agile Usability: User Experience Efforts on Agile Software Projects Artifacts for Agile Modeling: The UML and Beyond Essential user interface prototyping Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Modeling Style Guidelines User Interface Design Tips User Interface Prototyping Tips and Techniques UI RUPture Why Extend the UML Beyond Object and Component Technology?
Introduction to User Stories User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. This article covers the following topics:
Introduction to user stories Initial user stories (informal) Initial user stories (formal) User stories and planning User stories throughout the agile lifecycle Detailing a user story Epics Themes
1. Introduction to User Stories A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it's a reminder to do some just-intime analysis. In short, user stories are very slim and high-level requirements artifacts.
2. Initial User Stories (Informal)
As you can see in Figure 1 user stories are small, much smaller than other usage requirement artifacts such as use cases or usage scenarios. It's important to recognize that each of the statements inFigure 1 represents a single user story. Figure 1. Example user stories.
Students can purchase monthly parking passes online. Parking passes can be paid via credit cards. Parking passes can be paid via PayPal . Professors can input student marks. Students can obtain their current seminar schedule. Students can order official transcripts. Students can only enroll in seminars for which they have prerequisites. Transcripts will be available online via a standard browser.
Important considerations for writing user stories:
1. Stakeholders write user stories. An important concept is that your project stakeholders write the user 2. 3.
stories, not the developers. User stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the stakeholders) write them. Use the simplest tool. User stories are often written on index cards as you see in Figure 2 (at least when your project team is co-located). Index cards are very easy to work with and are therefore aninclusive modeling technique. Remember non-functional requirements. Stories can be used to describe a wide variety of requirements types. For example in Figure 1 the Students can purchase parking passes online user story is a usage requirement similar to a use case whereas the Transcripts will be available online via a standard browser is closer to a technical requirement. Indicate the estimated size. You can see in Figure 2 that it includes an estimate for the effort to implement the user story. One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2.5 hours per point; therefore the user story in Figure 2will take around 10 hours to implement. Indicate the priority. Requirements, including defects identified as part of your independent parallel testing activities or by your operations and support efforts, are prioritized by your project stakeholders (or representatives thereof such as product owners) and added to the stack in the appropriate place. You can easily maintain a stack of prioritized requirements by moving the cards around in the stack as appropriate. You can see that the user story card includes an indication of the priority; I often use a scale of one to ten with one being the highest priority. Other prioritization approaches are possible priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card its own unique priority order number (e.g. 344, 345, ). You want to indicate the priority somehow in case you drop the deck of cards, or if you're using more sophisticated electronic tooling. Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack. The implication is that your prioritization strategy needs to support this sort of activity. My advice is to keep it simple.
4.
5.
6. Optionally include a unique identifier. The card also includes a unique identifier for the user story,
in this case 173. The only reason to do this would be to do this is if you need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.
Figure 2. User story card (informal, high level).
2. Initial User Stories (Formal) In User Stories Applied Mike Cohn suggests a more formal approach to writing user stories. He suggests the format: As a (role) I want (something) so that (benefit). For example, the user story of Figure 2 could be rewritten as "As a Student I want to purchase a parking pass so that I can drive to school", as you see in Figure 3. My experience is that this approach helps you to think about who a certain feature is built for and why, and as a result is the approach that I typically prefer to take. The best advice that I can give is to try both and see which approach works best for you. Figure 3. User story card (formal, high level).
4. User Stories and Planning
There are two areas where user stories affect the planning process on agile projects:
1. Scheduling. Figure 4 depicts the agile change management management process where work
items, including stories, are addressed in priority order. So, the implication is that the priority assigned to a story affects when the work will be done to implement that requirement. As discussed earlier, project stakeholders are responsible for prioritizing requirements. Note that in Figure 2 a numerical prioritization strategy was taken (perhaps on a scale of 1 to 20) whereas in Figure 3 a MoSCoW (Must Should Could Won't) approach was used. Stakeholders also have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, stakeholders must also be responsible for making decisions and providing information in a timely manner. Estimating. Developers are responsible for estimating the effort required to implement the things which they will work on, including stories. The implication is that because you can only do so much work in an iteration, the size of the work items (including stories), affect when those work items will be addressed. Although you may fear that developers dont have the requisite estimating skills, and this is often true at first, the fact is that it doesnt take long for people to get pretty good at estimating when they know that theyre going to have to live up to those estimates. If you've adopted the pair programming practice then a user story must be able to be implemented by two people in a single iteration/sprint. Therefore if youre working in one week iterations each user story must describe less than one week worth of work. Of course, if you aren't taking a non-solo development approach such as pair programming the user story would need to be implementable by a single person within a single iteration. Large stories, sometimes called epics, would need to be broken up into smaller stories to meet this criteria.
2.
Figure 4. Disciplined agile change management process.
5. User Stories Throughout the Agile Life Cycle As you can see in the agile delivery life cycle of Figure 5, there are several distinct "phases" or seasons in the life cycle (some people will refer to the agile delivery life cycle as a release rhythm). Figure 6 depicts the AMDD project life cycle, which calls out modeling activities during the delivery life cycle. There are three common times when stories will be worked on during an agile project:
1. Iteration 0. You often create a stack of user stories during iteration 0 as part of your requirements
envisioning activities to identify the scope of your system.
2. Construction. During construction iterations you will identify new stories, split existing stories when
you realize that theyre too large to be implemented in single iteration, reprioritize existing stories, or remove stories that are no longer considered to be in scope. The point is that your stories evolve over time just like other types of requirements models evolve. Furthermore, enhancement requests may be identified by your support staff during the production phase and then forwarded to a development team as they are working on an upcoming release. These enhancement requests are effectively new stories (albeit in a different format). Release. Sometimes new stories will be identified during the release phase, although this isn't very common as the focus of release is on hardening the system and not on new functionality. But it does happen, and these stories would be prioritized and placed on the stack in priority order just as you normally would.
3.
Figure 5. A detailed agile SDLC.
Figure 6. The AMDD lifecycle: Modeling activities throughout the life cycle of a project.
6. Detailing a User Story Because user stories contain so little information you will need to flesh them out a bit when you first work with them. There are three common times when you would do this:
1. During JIT analysis/model storming with stakeholders. Remember the early definition of "user
stories are a reminder to have a conversation with your stakeholders"? Well, during that conversation you're going to explore the details behind that user story. It is quite common the create screen sketches with stakeholders to explore what they want. It is also common to identify the acceptance criteria, or confirmations, which the stakeholders will use to validate that the user story has been implemented correctly. Figure 7 shows how the back side of a user story card can be used to capture the confirmations. Of course, other tools which are more sophisticated than index cards can be used for this purpose as well. During iteration planning. As part of the estimation effort it is quite common to list programming tasks required to implement the user story. During implementation. When you start to work on implementing the user story you may decide to create some rough sketches of what youre going to build, perhaps a flow chart or UML activity diagram representing the relevant business logic.
2. 3.
Figure 7. User story card (formal, with confirmations).
7. Epics Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. Epics are typically lower priority user stories because once the epic works its way towards the top of the work item stack, see Figure 4, it is reorganized into smaller ones. It doesn't make sense to disaggregate a low-priority epic because you'd be investing time on something which you may never get to addressing, unless a portion of the epic is high priority and needs to be teased out. Remember to defer commitment, in this case model on a just-in-time (JIT) basis, to increase your overall productivity.
8. Themes A theme is a collection of related user stories. For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing. Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.
9. Suggested Reading
Agile Data Home Page Artifacts for Agile Modeling: The UML and Beyond Modeling Style Guidelines Why Extend the UML Beyond Object and Component Technology?
An Introduction to Agile Modeling Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of softwarebased systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. As you see in Figure 1 AM is meant to be tailored into other, full-fledged methodologies such as XP or RUP, enabling you to develop a software process which truly meets your needs. Figure 1. AM enhances other software processes.
The values of AM, adopting and extending those of eXtreme Programming v1, are communication, simplicity, feedback, courage, and humility. The keys to modeling success are to have effective communication between all project stakeholders, to strive to develop the simplest solution possible that meets all of your needs, to obtain feedback regarding your efforts often and early, to have the courage to make and stick to your decisions, and to have the humility to admit that you may not know everything, that others have value to add to your project efforts. AM is based on a collection of principles, such as the importance of assuming simplicity when you are modeling and embracing change as you are working because requirements will change over time. You should recognize that incremental change of your system over time enables agility and that you should strive to obtain rapid feedback on your work to ensure that it accurately reflects the needs of your project stakeholders. You should model with a purpose, if you don't know why you are working on something or you don't know what the audience of the model/document actually requires then you shouldn't be working on it. Furthermore, you need multiple models in your intellectual toolkit to be effective. A critical concept is that models are not necessarily documents, a realization that enables you travel light by discarding most of your models once they have fulfilled their purpose. Agile modelers believe that content is more important than representation, that there are many ways you can model the same concept yet still get it right. To be an effective modeler you need to recognize that open and honest communication is often the best policy to follow to ensure effective teamwork. Finally, a focus on quality work is important because nobody likes to produce sloppy work and that local adaptation of AM to meet the exact needs of your environment is important. To model in an agile manner you will apply AM's practices as appropriate. Fundamental practices include creating several models in parallel,applying the right artifact(s) for the situation, and iterating to another artifact to continue moving forward at a steady pace. Modeling in small increments, and not attempting to create the magical "all encompassing model" from your ivory tower, is also fundamental to your success as an agile modeler. Because models are only abstract representations of software, abstractions that may not be accurate, you should strive toprove it with code to show that your ideas actually work in practice and not just in theory Active stakeholder participation is critical to the success of your modeling efforts because your project stakeholders know what they want and can provide you with the feedback that you require. The principle of assume simplicity is a supported by the practices of creating simple content by focusing only on the aspects that you need to model and not attempting to creating a highly detailed model, depicting models simply via use of simple notations, and using the simplest toolsto create your models. You travel light by single sourcing information, discarding temporary models and updating models only when it hurts. Communication is enabled by displaying models publicly, either on a wall or internal web site, through collective ownership of your project artifacts, through applying modeling standards, and by modeling with others. Your development efforts are greatly enhanced when you apply patterns gently. Because you often need to integrate with other systems, including legacy databases as well as web-based services, you will find that you need to formalize contract models with the owners of those systems. Read this article for a better understanding of how AM's practices fit together. I would argue that AM is an agile approach to modeling, that at its core AM is simply a collection of practices that reflect the principles and values shared by many experienced software developers. With an Agile Model Driven Development (AMDD) (see Figure 2) approach you typically 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 do modeling as part of youriteration planning activities and then take a just in time (JIT) model storming approach where you model for several minutes as a precursor to several hours of coding. Figure 2. Agile Model Driven Development (AMDD).
Another way to look at Agile Modeling is as a collection of best practices, as you see in Figure 3. Figure 3. The best practices of Agile Modeling.
My experience is that these practices can be applied to most software development projects, you don't have to be working on an project following an agile software process (such as XP) to take advantage of the approaches described by AM, although one of AM's goals is to explain how to model when following the XP approach. A project team doesn't need to apply all of the practices, principles, and values of AM to benefit from it -- I have always been a firm believer that you should tailor your software process to reflect the unique needs of your environment -- although it is my opinion that like XP you are much more likely to succeed if you do adopt all of AM.
Agile Analysis Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Best Practices Agile Requirements Change Management Agile Requirements Modeling Frequently Asked Questions (FAQ) Inclusive Modeling Introduction to Agile Modeling PPT Slides (free download) Is Agile Crossing the Chasm? Practices of AM Principles of AM
Where Do I Start? Introduction to the Diagrams of UML 2.0

Understanding the thirteen diagrams of UML 2.x is an important part of understanding OO development. Although there isfar more to modeling than just the UML the reality is the UML defines the standard modeling artifacts when it comes to object technology. There are three classifications of UML diagrams:
Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams. Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams. Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.
Table 1 summarizes the thirteen, up from nine in UML 1.x, diagram types of UML 2.x. In the diagram column the links will take you to description pages for the artifact. The learning priority column indicates how important it is for a business application developer to learn the artifact (IMHO). Table 1. The diagrams of UML 2. Diagram Description Learning Priority High
Activity Diagram Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. See UML Activity diagram guidelines. Class Diagram Shows a collection of static model elements such as High classes and types, their contents, and their relationships. See UML Class diagram guidelines. Communication Shows instances of classes, their interrelationships, Low Diagram and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. See UML Collaboration diagram guidelines. Component Depicts the components that compose an Medium Diagram application, system, or enterprise. The components,
their interrelationships, interactions, and their public interfaces are depicted. See UML Component diagram guidelines. Composite Depicts the internal structure of a classifier (such as Low Structure a class, component, or use case), including the Diagram interaction points of the classifier to other parts of the system. Deployment Shows the execution architecture of systems. This Medium Diagram includes nodes, either hardware or software execution environments, as well as the middleware connecting them. See UML Deployment diagram guidelines. Interaction A variant of an activity diagram which overviews Low Overview the control flow within a system or business Diagram process. Each node/activity within the diagram can represent another interaction diagram. Object Diagram Depicts objects and their relationships at a point in Low time, typically a special case of either a class diagram or a communication diagram. Package Shows how model elements are organized into Low Diagram packages as well as the dependencies between packages. See Package diagram guidelines. Sequence Models the sequential logic, in effect the time High Diagram ordering of messages between classifiers. See UML Sequence diagram guidelines. State Machine Describes the states an object or interaction may be Medium Diagram in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. See UML State chart diagram guidelines. Timing Diagram Depicts the change in state or condition of a Low classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events. Use Case Shows use cases, actors, and their Medium Diagram interrelationships. See UML Use case diagram guidelines.
Source This material has been excerpted from The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2.
Be Realistic About the UML Pavel Hruby's UML 2.0 Stencil for Visio UML Modeling Style Guidelines A UML Profile for Data Modeling
Why Extend the UML Beyond Object and Component Technology? Modeling Style Guidelines
Style (n): A particular manner or technique by which something is done, created, or performed.
- Merriam Webster's Collegiate Dictionary, 10th Edition. Many resources - books, magazine articles, and web sites - focus on how to work with the artifacts of the Unified Modeling Language (UML) as well as other modeling techniques. These resources introduce you to various modeling artifacts, describe a methodology for applying the artifacts in practice, or describe how to apply patterns and strategies for creating better models. Unfortunately few of these resources touch on the subject of style and when they do they rarely devote little space to it. This includes my own book, The Object Primer 3/e, which provides an excellent overview of UML artifacts (as well as a few others because the UML isn't sufficient for real-world development) and how to take them all the way to Java code and a relational database on the back end. The focus of these pages is style. That's it. It presents guidelines to improve the quality and readability of your software diagrams, making them easier to understand and to work with. Included are guidelines for applying various modeling notations effectively, such as when to apply aggregation between two classes instead of association, but excluded are design patterns such as Strategy or Facade. Note that the primary focus of this site, at least at first, will be the UML, the industry standard for modeling systems using object-oriented and component-based systems. Data modelers may find www.agiledata.org to be of interest. Topics:
General diagramming guidelines UML 2 Activity diagram guidelines UML 2 Class diagram guidelines UML 2 Collaboration diagram guidelines UML 2 Component diagram guidelines UML 2 Deployment diagram guidelines UML 2 Interface Guidelines UML 2 Frame Guidelines UML 2 Note Guidelines UML 2 Package diagram guidelines UML 2 Sequence diagram guidelines UML 2 State machine diagram guidelines UML 2 Stereotype Guidelines UML 2 Use case diagram guidelines
Are You Ready For the MDA? Be Realistic About the UML Examining The Model Driven Architecture (MDA) Introduction to the Diagrams of UML 2 Introduction to Object Orientation (OO) and UML Modeling Style Guidelines Pavel Hruby's UML 2.0 Stencil for Visio Roadmap for Agile MDA Why Extend the UML Beyond Object and Component Technology? XP and the UML?
Development Phases Examined: Why Requirements, Analysis, and Design Phases No Longer Make Sense (If They Ever Did) For years I have discussed the idea that modeling doesn't occur in nice, neat phases. Instead of spending time in
the "Requirements Phase", then the "Analysis Phase", then the "Design Phase" it is far more common to iterate back and forth between these so-called modeling activities. When you think about it, these different phases are more a reflection of theTayloristic thinking of the early 1900s than it is of effective software development.
1. Rethinking the Concept of Modeling Phases Many people, particularly generalizing specialists with a wide understanding of development will hear a requirement, ask a few questions to analyze what is actually needed, and then proceed to designing it in their heads. This typically occurs within a matter of minutes if not seconds. Clearly the concept of modeling phases is questionable, but I'm also beginning to wonder if the idea of focusing on requirements, analysis, and even design makes much sense these days. Perhaps we should just talk about modeling in general, or perhaps we should focus on other types of modeling instead. Assume that we decide to focus on modeling, or better yet agile modeling, in general. I think that it is still valuable to consider requirements, which to me should identify what our stakeholders want; analysis, which investigates the details pertaining to the requirements; and design, which focuses on identifying how we intend to fulfill those requirements. Very useful concepts, but not very useful phases. Now let's take a different tack and try to identify what concepts should replace the activities of requirements, analysis, and design. One way that we could do this is to take a bottom up approach by considering potential modeling artifacts and identifying categories which they belong to. Or we could take a top-down approach and consider existing categories of modeling prevalent within software development. Or we could combine the two approaches, which is what I've done, to identify the following categories of modeling activities:
1. Usage modeling. The focus of usage modeling is to identify how people work with your system.
Potential artifacts include essential use cases, system use cases, UML 2 use case diagrams and user stories. Usage modeling crosses the boundary of traditional requirements and analysis, and arguably even design, because when you model usage you explore what users will do with the system as well as how the system will support that usage (e.g. by considering user interface and deployment decisions). Personas and scenarios should also be considered. Process modeling. The goal of process modeling is very similar to usage modeling in that it is to explore how people work with the system, taking into account the flow of the activities being performed. The main difference is that usage modeling techniques don't fully address the flow of artifacts, including but not limited to information, within a system whereas process models do. Potential process models include data flow diagrams (DFDs), flow charts, and UML 2 activity diagrams. User interface (UI) modeling. UI modeling can include UI requirement identification via essential UI prototypes, traditional prototyping, and/or user interface flow modeling (storyboarding). Usability issues are clearly an important concern when developing the UI. Supplementary requirements modeling. There is more to identifying what stakeholders need than usage or UI modeling, hence the need for supplementary artifacts which address these critical details. For example many systems have complex business rules, constraints, glossaries, or technical requirementsand sometimes a requirement is best identified via a simple feature definition. Conceptual domain modeling. The goal of conceptual domain modeling, sometimes simply called either conceptual modeling or domain modeling, is to identify the entities, their responsibilities, and their relationships within your problem domain. Potential models which you may want to consider include class responsibility collaborator (CRC) models, logical data models (LDMs), object role model (ORM) diagrams, robustness diagrams, or UML 2 class models. Architectural modeling. Architectural modeling should focus on the high-level design of a system or that of an enterprise as the case may be. Although virtually any model can be used for architectural modeling, I prefer models which can be used to explore the general landscape of your efforts. This includes free-form diagrams, UML 2 component diagrams, UML 2 package diagrams, UML 2 deployment diagrams, and network diagrams. A supporting model arechange cases, a form of architectural requirement which enables you to explore potential requirements. Dynamic design modeling. The goal of dynamic design modeling is to explore the behavioral aspects of an object system. UML interaction diagrams -- including UML 2 communication/collaboration diagrams, UML 2 composite structure diagrams, UML 2 interaction overview diagrams, and UML 2 sequence diagrams -- can be used as can UML 2 state machine diagrams and UML 2 timing diagrams. Structural design modeling. Structural design modeling, using UML 2 class diagrams, UML 2 object diagrams, and/or physical data models (PDMs).
2.
3. 4.
5.
6.
7.
8.
My experience is that it is better to consider modeling categories instead of modeling phases/disciplines. Figure 1 depicts this idea, showing the eight different modeling categories described above and listing potential models within each category.
Figure 1. Iterative modeling.
It's interesting to observe that this is very similar conceptually to Phillipe Kruchten's 4+1 View of Modeling, albeit one with eight views instead of five. These categories are also similar to the six columns of the Zachman Framework (ZF), arguably a different take on the same basic idea. Although I would like to say that you should simply pick one model per category it's not that simple. Here's my advice:
1. You need one or more models from the usage and process modeling categories. This choice will
often be driven by your chosen software process, following either the Rational Unified Process (RUP) or Enterprise Unified Process (EUP) you will need use case artifacts, with Extreme Programming (XP) user stories, and with a structured analysis and design approach data flow diagrams (DFDs). It is also quite common to use process models to analyze the information contained in usage models. Create user interface models as needed. Some systems are UI intense whereas others are not, some developers prefer to start with essential models whereas others prefer to go straight to prototyping or even development of the actual source code itself. As always, Apply The Right Artifact(s). Model supplementary requirements as appropriate. I'm a firm believer in using each type of model for what it's good at and for recording information in one place only. Supplemental requirements such as business rules and technical requirements can and should be referred to within other development artifacts such as use cases, class models, and source code. Create one type of conceptual domain model. You need to understand the business domain, and conceptual domain models are very good at that. Pick one model that best meets your needs. Create architectural, dynamic design, and structural design models as needed. You often need several views of your architecture, so create the model(s) that reflect your situation. Similarly you are likely to discover that you need one or more dynamic design models from time to time, sequence
2. 3.
4. 5.
diagrams are a popular choice as are state machine diagrams. Structural design diagrams are often the mainstay of modeling as they are very close to object code as well as data schemas.
2. Towards Inclusive Modeling So how do these categories change the development landscape? First, I believe that they make the complexity of modern software development more explicit. These categories focus on the high-level issues that you should consider modeling, instead of modeling phases, and as a result provide better guidance to developers. Second, they provide insight into the types of models that you should create. Figure 2 maps the modeling categories to individual modeling techniques, indicating which techniques are inclusive and which are complex. Inclusive techniques use simple tools (paper, whiteboards,...) and are simple in and of themselves (and are therefore easy to learn). I call these techniques inclusive because they are simple enough that stakeholders can use them, thus enabling the practice Active Stakeholder Participation. Figure 2. Inclusive to complex techniques.
3. The Modeling Lifecycle Figure 3 depicts the lifecycle of Agile Model Driven Development (AMDD), which is much different from the waterfall lifecycle of yesteryear. High level modeling, also called envisioning, is first done during "Iteration 0" and the details are gathered on a just-in-time (JIT) basis during development iterations. The goal of initial requirements envisioning and initial architecture envisioning is to understand at a high level what the scope and technical strategy of your project is. The other activities iteration modeling, model storming, reviews, and implementation via TDD potentially occur during any iteration, including iteration 0. It is during these activities that detailed modeling occurs, not during phases. Requirements analysis, architecture, and design are so important to agilists that we do these things every day, not just during specific phases.
Figure 3. The Agile Model Driven Development (AMDD) lifecycle for software projects.
4. Adopting this Approach It's fair to ask what impediments exist to implementing this vision. The first impediment is the prevailing culture within the IT industry. For years we've been told that the modeling phases reflect how development occurs but it never really seemed to ring true with many developers, people who often threw out the "modeling baby" with the "phases bath water" when they abandoned the idea of serial development. The second impediment is existing IT specialists. There are many people who identify themselves as requirements analysts, architects, object designers, or database designers, all jobs which reflect "phasist thinking". It would be far more effective if people could identify themselves as the more general concept of modelers or better yet simply as developers who happen to have solid modeling skills.
One person's design element is another person's requirem ent.

In short, I'm simply not convinced that the modeling phases of requirements, analysis, and design make sense any more. Nor, in the case of the various flavors of the Unified Process, do they make sense as disciplines. We need to rethink our approach to modeling within the IT industry, and my experience is that the categories which I have described above are far more realistic of an approach. Think about it.
Source Parts of this article have been excerpted from The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2.
Agile Analysis Agile Data Home Page Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Best Practices Agile Requirements Change Management Agile Requirements Modeling Agile Testing Strategies Best Practices for Agile/Lean Documentation The "Change Prevention" Anti-Pattern Examining the "Big Requirements Up Front (BRUF)" Approach Inclusive Modeling Iteration Modeling Model a Bit Ahead The "One Truth Above All Else" Anti-Pattern Prioritized Requirements: An Agile Best Practice Rethinking Business Analysts
Why Extend the UML Beyond Object and Component Technology? Agile Modeling (AM) Practices v2
Agile Modeling (AM) defines a collection of core and supplementary practices, based on the principles of AM. Some of the practices have been adopted from extreme Programming (XP) and are well documented in Extreme Programming Explained. As with AM's Principles, the practices are presented with a focus on modeling efforts so material adopted from XP may be presented in a different light. The AM practices are organized into two lists, core practices which you must adopt to be able to claim that you're truly taking an Agile Model Driven Development (AMDD) approach and supplementary practices which you should consider tailoring into your software process to meet the exact needs of your environment. There are also some really good ideas which you should consider adopting but which aren't part of AMDD. In January 2005 I added a third list, deprecated practices which I've decided to remove in the second release of the AMDD methodology in order to simplify it.
Core Practices
Supplementary Practices
Active Stakeholder Participation Apply the Right Artifact(s) Collective Ownership Create Several Models in Parallel Create Simple Content Depict Models Simply Display Models Publicly
Apply Modeling Standards Apply Patterns Gently Discard Temporary Models Formalize Contract Models Update Only When It Hurts
Iterate to Another Artifact Model in Small Increments Model With Others Prove it With Code Single Source Information Use the Simplest Tools
Core Practices:
Active Stakeholder Participation. An expansion of XP's On-Site Customer which describes the need to have on-site access to users that have the authority and ability to provide information pertaining to the system being built and to make pertinent and timely decisions regarding the requirements, and prioritization thereof. AM expands XP's On-Site Customer practice to have project stakeholders -including direct users, their management, senior management, operations staff, and support (help desk) staff -- actively involved in the project. This includes making timely resourcing decisions by senior management, public and private support for the project by senior management, active participation of operations and support staff in the development of requirements and models pertaining to their respective areas. You can easily promote active stakeholder participation on your projects if you adopt inclusive modeling techiques. Model With Others. When you Model With a Purpose you often find that you are modeling to understand something, that you are modeling to communicate your ideas to others, or you are seeking to develop a common vision on your project. This is a group activity, one in which you want the input of several people working together effectively. You will often find that your development team needs to work together to create the core set of models critical to your project. For example, to develop the metaphor or architecture for you system, you will often need to model with a group of people to develop a solution everyone agrees on as well as one that is as simple as possible. Most of the time the best way to do this is to talk the issue through with one or more people. Modeling with others is an example of "Non-Solo Development", as is pair programming. Apply The Right Artifact(s). Each artifact has its own specific applications. For example, a UML activity diagram is useful for describing a business process, whereas the static structure of your database is better represented by a physical data or persistence model. Very often a diagram is a better choice than source code -- If a picture is worth a thousand words then a model is often worth 1024 lines of code when applied in the right circumstances (a term borrowed from Karl Wiegers Software Requirements) because you can often explore design alternatives more effectively by drawing a couple diagrams on whiteboards with your peers than you can by sitting down and developing code samples. The implication is that you need to know the strengths and weaknesses of each type of artifact so you know when and when not to use them. Note that this can be very difficult because you have Multiple Models available to you, in fact the Agile Models Distilled page lists over 35 types of models and it is by no means definitive. Iterate To Another Artifact. When you are working on a development artifact -- such as a use case, CRC card, sequence diagram, or even source code -- and find that you are stuck then you should consider working on another artifact for the time being. Each artifact has its strengths and weaknesses, each artifact is good for a certain type of job. Whenever you find you are having difficulties working on one artifact, perhaps you are working on a use case and find that you are struggling to describe the business logic, then that's a sign that you should iterate to another artifact. For example, if you are working on an essential use case then you may want to consider changing focus to start working on an essential UI prototype, a CRC model, a business rule, a system use case, or a change case. By iterating to another artifact you immediately become "unstuck" because you are making progress working on that other artifact. Furthermore, by changing your point of view you often discover that you address whatever it was that causing you to be stuck in the first place. See the essay Iterate to Another Artifact for more thoughts. Prove It With Code. A model is an abstraction, one that should accurately reflect an aspect of whatever you are building. But will it work? To determine so, you should prove your model with code. You've developed a sketch of an HTML page for accepting billing address information? Code it and show the resulting user interface to your users for feedback. You've developed a UML sequence diagram representing the logic to implement a complex business rule? Write the testing code, the business code, and run the tests to ensure that you've gotten it right. Never forget that with an iterative approach to software development, the norm for the vast majority of projects, that modeling is only one of many tasks that you will perform. Do some modeling, do some coding, do some testing (amongst other things).
Use The Simplest Tools. The vast majority of models can be drawn on a whiteboard, on paper or even the back of a napkin. Whenever you want to save one of these diagrams you can take a picture of it with a digital camera, or even simply transcribe it onto paper. This works because most diagrams are throwaways; their true value comes from drawing them to think through an issue, and once the issue is resolved the diagram doesnt offer much value. As a result a whiteboard and markers are often your best modeling tool alternative: Use a drawing tool to create diagrams to present to important project stakeholders and occasionally use a modeling tool if and only if they provide value to my programming efforts such as the generation of code. Think of it like this: If youre creating simple models, often models that are throwaways because if you are modeling to understand you likely dont need to keep the model(s) around any more once you do understand the issue, then you likely dont need to apply a complex modeling tool. Model In Small Increments. Incremental development in which you organize a larger effort into smaller portions that you release over time, hopefully in increments of several weeks or a month or two, increases your agility by enabling you to deliver software into the hands of your users faster. Single Source Information. Information should be stored in one place and one place only. In other words, not only should you apply the right artifact you should also model a concept once and once only, storing the information in the best place possible. When you are modeling you should always be asking the questions "Do I need to retain this information permanently?", "If so, where is the best place to store this information?" and "Is this information already captured elsewhere that I could simply reference?". Sometimes the best place to store information is in an agile document, often it's in source code. Read here for more details. Collective Ownership. Everyone can work on any model, and in fact any artifact on the project, if they need to. Create Several Models in Parallel. Because each type of model has its strengths and weaknesses no single model is sufficient for your modeling needs. For example when you are exploring requirements you may need to develop some essential use cases or user stories, an essential UI prototype, and some business rules. In combination with the practice of iterating to another artifact agile modelers will often discover that they are far more productive working on several models simultaneously than if they are only focusing on one at any given time. Create Simple Content. You should keep the actual content of your models -- your requirements, your analysis, your architecture, or your design -- as simple as you possibly can while still fulfilling the needs of your project stakeholders. The implication is that you should not add additional aspects to your models unless they are justifiable -- if you do not have a requirement to add system auditing features then don't add that features to your models. Have the courage to trust that you can in fact add this feature when, and if, it is ever asked of you. This is along the lines of XP's practice of Simple Design. Depict Models Simply. When you consider the potential diagrams that you could apply (UML diagrams, user interface diagrams, data models, and so on) you quickly realize that the majority of the time you only require a subset of the diagramming notation available to you. A simple model that shows the key features that you are trying to understand, perhaps a class model depicting the primary responsibilities of classes and the relationships between them, often proves to be sufficient. Yes, you could model all the scaffolding code that you will need to write, all the getter and setter operations that your coding standards tell you to use, but what value would that add? Very little. Display Models Publicly. You should display your models publicly, often on something called a "modeling wall" or a "wall of wonder." This supports open and honest communication on your team because all of the current models are quickly accessible to them, as well as with your project stakeholders because you aren't hiding anything from them. Your modeling wall is where you post your models for everyone to see; the modeling wall should be accessible to your development team and other project stakeholders. Your modeling wall may be physical, perhaps a designated whiteboard for your architecture diagram(s) or a place where you tape a printout of your physical data model. Modeling walls can be virtual, such as an internal Web page that is updated with scanned images. See Ellen Gottesdiener's Specifying Requirements With a Wall of Wonder for a similar viewpoint.
Supplementary Practices:
Apply Modeling Standards. This practice is renamed from XP's Coding Standards, the basic idea is that developers should agree to and follow a common set of modeling standards on a software project. Just like there is value in following common coding conventions, clean code that follows your chosen coding guidelines is easier to understand and evolve than code that doesn't, there is similar value in following common modeling conventions. There is a wide variety of common modeling standards available to you, including the Object Management Group's Unified Modeling Language (UML) which defines the notation and semantics for common object-oriented models. The UML
provides a good start but it isn't sufficient -- as you can see in Be Realistic About The UML not all possible modeling artifacts are encompassed by the UML. Furthermore, it says nothing about modeling style guidelines to create clean-looking diagrams. What is the difference between a style guideline and a standards. WRT to source code, a standard would be to name attributes in the format attributeName whereas a style guideline is to indent the code within a control structure (an if statement, a loop, ...) by one unit. WRT to models, a standard would be to use a square rectangle to model a class on a class diagram and a style guideline would be to have subclasses placed on diagrams to the south of their superclasses. Apply Patterns Gently. Effective modelers learn and then appropriately apply common architectural, design and analysis patterns in their models. However, as Martin Fowler points out in Is Design Dead? developers should consider easing into the application of a pattern, to apply it gently. This reflects the value of simplicity. In other words, if you SUSPECT that a pattern applies you should model it in such a way as to implement the minimal amount you need today but that makes it easy to refactor it later when it is clear that applying the full-fledged pattern is in fact the simplest approach possible. In other words, don't over model. For example, you may recognize a good spot in your design to apply the GoF's Strategy pattern, but at the current moment you only have two algorithms to implement. The simplest approach might be to encapsulate each strategy in its own class and build an operation that chooses them appropriately and passes them the appropriate input. This is a partial implementation of Strategy that leaves you in a position to refactor your design if more algorithms need to be implemented, yet does not require you to build all the scaffolding that Strategy requires -an approach that enables you to ease into application of the pattern. Discard Temporary Models. The vast majority of the models that you create are temporary/working models -- design sketches, low fidelity prototypes, index cards, potential architecture/design alternatives, and so on -- models that have fulfilled their purpose but no longer add value now that they have done so. Models quickly become out of sync with the code, and there is nothing wrong with that. You must then make the decision to synchronize the models if doing so adds value to your project or to simply discard them because the investment to update the models won't be recouped by the value of having done so (there's negative payback). This practice is particularly important for agile documentation. Formalize Contract Models. Contract models are often required when an external group controls an information resource that your system requires, such as a database, legacy application or information service. A contract model is something that both parties should mutually agree to and mutually change over time if required. Examples of contract models include the detailed documentation of an application programming interface (API), a file layout description, an XML DTD or a physical data model describing a shared database. As with a legal contract, a contract model often requires you to invest significant resources to develop and maintain the contract to ensure that its accurate and sufficiently detailed. Your goal is to minimize the number of contract models for your system to conform to the XP principle of traveling light. Note that you will almost always use an electronic tool to develop a contract model because the model must be maintained over time. Update Only When It Hurts. You should update a model only when you absolutely need to, when not having the model updated is more painful than the effort of updating it. With this approach you discover that you update a smaller number of models than you would have in the past because the reality is that your models don't have to be perfect to provide value. The street map that I have to my town is over five years old, I know this because my own street doesn't appear on it and it's been in place for a little over five years, yet the map is still useful to me. Yes, I could purchase an updated map, one comes out every year, but why bother? Missing a few streets isn't painful enough to warrant this investment, it simply doesn't make sense to spend the money to purchase a new map every year when the one that I have is good enough. Too much time and money is wasted trying to keep models and documents in sync with source code, an impossible task to begin with, time and money that could be better spent developing new software. This practice is particularly important for agile documentation.
Really Good Ideas: The following practices are complementary to AM but are not explicitly included as a part of it:
Refactoring. This is a coding practice in which you make small changes, called refactorings, to your code to support new requirements or to keep your design as simple as possible. From the view of AM this practice ensures that your design remains clean and clear as you work on your code. Refactoring is an integral part of XP. You can read more about code refactoring and database refactoring here. Test-First Design. This is a development practice where you first consider and then code a test case before writing the business code which satisfies this test case. From the point of view of AM this
practice forces you to think through your design before you write your code, removing the need for detailed design modeling. Test-first design is an integral part of XP and you can read more about it here.
Practices Deprecated From Agile Modeling Version 1 To simplify AM, I chose to remove several practices in January of 2005. Although these are still valid ideas which are not going away, they won't be considered "first order practices" anymore. I found over the years that as I training and mentored people in AMDD that I didn't need to discuss them very much for people to understand the approach. The practices which I removed are:
v1 Practice
Description When you are modeling you should be constantly asking yourself "How are we going to test this?" because if you can't test the software that you are building you shouldn't be building it. Modern software processes include testing and quality assurance activities throughout the entire project lifecycle, and some even promote the concept of writing tests first before writing software (this is an XP practice).
Reason for Removal
Consider Testability
Although this is a great idea but when you're taking a TDD approach, which most agilists do, along with an AMDD approach you find that this practice becomes moot.
One reason to model is to communicate with people external to your team or to create a contract model. Because the customers for Model To some models are outside your team, you may Communicate need to invest the time to make your model(s) look pretty by using electronic tools such as word processors, drawing packages or even sophisticated CASE tools.
This is a great motivator for modeling, but not really a practice, therefore I deprecated it.
Model To Understand
The most important application of modeling is to explore the problem space, to identify and analyze the requirements for the system, or to compare and contrast potential design alternatives to identify the potentially most I removed this for the same simple solution that meets the requirements. reasons that I removed Following this practice you often develop modeling to communicate. small, simple diagrams that focuses on one aspect of your software, such as the life cycle of a class or the flow between screens, diagrams that you often throwaway once you are finished with them.
There is a wealth of information that agile modelers can take advantage from. For example, perhaps some analysis or design patterns are appropriate for you to apply gently to your system. Or perhaps you can take advantage of an existing enterprise Reuse Existing requirements model, business process models, Resources physical data models or even models of how systems are currently deployed within your user community. Its true that these models either dont exist or are out of date in many organizations, although youre often likely to uncover reasonably accurate models with a bit of research.
This is a great idea which all developers should practice, but it's a general concept which goes beyond modeling and documentation.
Agile Modeling (AM) Principles v2
Agile Modeling (AM) defines a collection of core and supplementary principles that when applied on a software development project set the stage for a collection of modeling practices. Some of the principles have been adopted from eXtreme Programming (XP) and are well documented in Extreme Programming Explained, which in turn adopted them from common software engineering techniques. For the most part the principles are presented with a focus on their implications to modeling efforts and as a result material adopted from XP may be presented in a different light. The AM principles are organized into two lists, core principles which you must adopt to be able to claim that you're truly taking an Agile Model Driven Development (AMDD) approach and supplementary principles which you should consider tailoring into your software process to meet the exact needs of your environment. In January 2005 I added a third list, deprecated principles which I've decided to remove in the second release of the AMDD methodology in order to simplify it. Core Principles Supplementary Principles
Assume Simplicity Embrace Change Enabling the Next Effort is Your Secondary Goal Incremental Change Maximize Stakeholder ROI Model With a Purpose Multiple Models Quality Work Rapid Feedback Working Software Is Your Primary Goal Travel Light
Content is More Important Than Representation Open and Honest Communication
Core Principles:
Model With A Purpose. Many developers worry about whether their artifacts -- such as models, source code, or documents -- are detailed enough or if they are too detailed, or similarly if they are sufficiently accurate. What they're not doing is stepping back and asking why they're creating the artifact in the first place and who they are creating it for. With respect to modeling, perhaps you need to understand an aspect of your software better, perhaps you need to communicate your approach to senior management to justify your project, or perhaps you need to create documentation that describes your system to the people who will be operating and/or maintaining/evolving it over time. If you cannot identify why and for whom you are creating a model then why are you bothering to work on it all? Your first step is to identify a valid purpose for creating a model and the audience for that model, then based on that purpose and audience develop it to the point where it is both sufficiently accurate and sufficiently detailed. Once a model has fulfilled its goals you're finished with it for now and should move on to something else, such as writing some code to show that the model works. This principle also applies to a change to an existing model: if you are making a change, perhaps applying a known pattern, then you should have a valid reason to make that change (perhaps to support a new requirement or to refactor your work to something cleaner). An important implication of this principle is that you need to know your audience, even when that audience is yourself. For example, if you are creating a model for maintenance developers, what do they really need? Do they need a 500 page comprehensive document or would a 10 page overview of how everything works be sufficient? Don't know? Go talk to them and find out. Maximize Stakeholder ROI. Your project stakeholders are investing resources -- time, money, facilities, and so on -- to have software developed that meets their needs. Stakeholders deserve to invest their resources the best way possible and not to have resources frittered away by your team. Furthermore, they deserve to have the final say in how those resources are invested or not invested. If it was your resources, would you want it any other way? Note: In AM v1 this was originally called "Maximize Stakeholder Investment". Over time we realized that this term wasn't right because it sounded like we were saying you needed to maximize the amount of money spent, which wasn't the message.
Travel Light. Every artifact that you create, and then decide to keep, will need to be maintained over time. If you decide to keep seven models, then whenever a change occurs (a new/updated requirement, a new approach is taken by your team, a new technology is adopted, ...) you will need to consider the impact of that change on all seven models and then act accordingly. If you decide to keep only three models then you clearly have less work to perform to support the same change, making you more agile because you are traveling lighter. Similarly, the more complex/detailed your models are, the more likely it is that any given change will be harder to accomplish (the individual model is "heavier" and is therefore more of a burden to maintain). Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. Someone trekking across the desert will benefit from a map, a hat, good boots, and a canteen of water they likely won't make it if they burden themselves with hundreds of gallons of water, a pack full of every piece of survival gear imaginable, and a collection of books about the desert. Similarly, a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code. Multiple Models. You potentially need to use multiple models to develop software because each model describes a single aspect of your software. What models are potentially required to build modern-day business applications? Considering the complexity of modern day software, you need to have a wide range of techniques in your intellectual modeling toolkit to be effective (see Modeling Artifacts for AM for a start at a list and Agile Models Distilled for detailed descriptions). An important point is that you don't need to develop all of these models for any given system, but that depending on the exact nature of the software you are developing you will require at least a subset of the models. Different systems, different subsets. Just like every fixit job at home doesn't require you to use every tool available to you in your toolbox, over time the variety of jobs you perform will require you to use each tool at some point. Just like you use some tools more than others, you will use some types of models more than others. For more details regarding the wide range of modeling artifacts available to you, far more than those of the UML as I show in the essay Be Realistic About the UML. Rapid Feedback. The time between an action and the feedback on that action is critical. By working with other people on a model, particularly when you are working with a shared modeling technology (such as a whiteboard, CRC cards, or essential modeling materials such as sticky notes) you are obtaining near-instant feedback on your ideas. Working closely with your customer, to understand the requirements, to analyze those requirements, or to develop a user interface that meets their needs, provides opportunities for rapid feedback. Assume Simplicity. As you develop you should assume that the simplest solution is the best solution. Don't overbuild your software, or in the case of AM don't depict additional features in your models that you don't need today. Have the courage that you don't need to over-model your system today, that you can model based on your existing requirements today and refactor your system in the future when your requirements evolve. Keep your models as simple as possible. Embrace Change. Requirements evolve over time. People's understanding of the requirements change over time. Project stakeholders can change as your project moves forward, new people are added and existing ones can leave. Project stakeholders can change their viewpoints as well, potentially changing the goals and success criteria for your effort. The implication is that your project's environment changes as your efforts progress, and that as a result your approach to development must reflect this reality. You need an agile approach to change management.
Incremental Change. An important concept to understand with respect to modeling is that you don't need to get it right the first time, in fact, it is very unlikely that you could do so even if you tried. Furthermore, you do not need to capture every single detail in your models, you just need to get it good enough at the time. Instead of futilely trying to develop an all encompassing model at the start, you instead can put a stake in the ground by developing a small model, or perhaps a high-level model, and evolve it over time (or simply discard it when you no longer need it) in an incremental manner. Quality Work. Nobody likes sloppy work. The people doing the work don't like it because it's something they can't be proud of, the people coming along later to refactor the work (for whatever reason) don't like it because it's harder to understand and to update, and the end users won't like the work because it's likely fragile and/or doesn't meet their expectations. Working Software Is Your Primary Goal. The goal of software development is to produce highquality working software that meets the needs of your project stakeholders in an effective manner. The primary goal is not to produce extraneous documentation, extraneous management artifacts, or even models. Any activity that does not directly contribute to this goal should be questioned and avoided if it cannot be justified in this light.
Enabling The Next Effort Is Your Secondary Goal. Your project can still be considered a failure even when your team delivers a working system to your users part of fulfilling the needs of your project stakeholders is to ensure that your system robust enough so that it can be extended over time. As Alistair Cockburn likes to say, when you are playing the software development game your secondary goal is to setup to play the next game. Your next effort may be the development of the next major release of your system or it may simply be the operations and support of the current version you are building. To enable it you will not only want to develop quality software but also create just enough documentation and supporting materials so that the people playing the next game can be effective. Factors that you need to consider include whether members of your existing team will be involved with the next effort, the nature of the next effort itself, and the importance of the next effort to your organization. In short, when you are working on your system you need to keep an eye on the future.
Supplementary Principles:
Content Is More Important Than Representation. Any given model could have several ways to represent it. For example, a UI specification could be created using Post-It notes on a large sheet of paper (an essential or low-fidelity prototype), as a sketch on paper or a whiteboard, as a "traditional" prototype built using a prototyping tool or programming language, or as a formal document including both a visual representation as well as a textual description of the UI. An interesting implication is that a model does not need to be a document. Even a complex set of diagrams created using a CASE tool may not become part of a document, instead they are used as inputs into other artifacts, very likely source code, but never formalized as official documentation. The point is that you take advantage of the benefits of modeling without incurring the costs of creating and maintaining documentation. Open And Honest Communication. People need to be free, and to perceive that they are free, to offer suggestions. This includes ideas pertaining to one or more models, perhaps someone has a new way to approach a portion of the design or has a new insight regarding a requirement; the delivery of bad news such as being behind schedule; or simply the current status of their work. Open and honest communication enables people to make better decisions because the quality of the information that they are basing them on is more accurate.
Principles Deprecated From Agile Modeling Version 1 To simplify AM, I chose to remove several principles in January of 2005. Although these are still valid ideas which are not going away, but they just won't be considered "first order principles" anymore. I found over the years that as I training and mentored people in AMDD that I didn't need to discuss them very much for people to understand the approach. The principles which I removed are:
v1 Principle
Description
Reason for Removal This is a great idea, one that seems to be followed by the vast majority of agilists, but it's very general and therefore does not need to be a principle of a specific modeling methodology.
Everyone Can Learn You can never truly master something, there is From Everyone Else always opportunity to learn more and to extend your knowledge. Take the opportunity to work with and learn from others, to try new ways of doing things, to reflect on what seems to work and what doesn't. Technologies change rapidly, existing technologies such as Java evolve at a blinding pace and new technologies such as C# and .NET are introduced regularly. Existing development techniques evolve at a slower pace but they still evolve -- As an industry we've understood the fundamentals of testing for quite awhile although we are constantly improving our understanding through research and practice. The point to be made is that we work in an industry where change is the norm, where you must take
every opportunity to learn new ways of doing things through training, education, mentoring, reading, and working with each other. Knowing what you're doing is always a good Because you have multiple models that you can idea, but did it Know Your Models apply you need to know their strengths and really need to weaknesses to be effective in their use. be an explicit principle? Likely not. Software, such as diagramming tools or modeling tools, have a variety of features. If you are going Same issue as to use a modeling tool then you should knowing your understand its features, knowing when and when models. not to use them. Your approach to software development must reflect your environment, including the nature of your organization, the nature of your project stakeholders, and the nature of your project itself. Issues that could be affected include: the modeling techniques that you apply (perhaps your users insist on concrete user interfaces instead of initial sketches or essential prototypes); the tools that you use (perhaps there isn't a budget for a digital camera, or you already have licenses for an existing CASE tool); and the software process that you follow (your organization insists on XP, or RUP, or their own process). You will adapt your approach at both the project level as well as the individual level. For example, some developers use one set of tools over another, some focus on coding with very little modeling whereas others prefer to invest a little more time modeling. I'm a firm believer that you should tailor a software process to meet your exact needs. However, that doesn't mean that this idea needs to be part of AM, instead it needs to be part of your overall software process improvement (SPI) strategy.
Know Your Tools
Local Adaptation
When someone feels that something isn't going to work, that a few things are inconsistent with one another, or that something doesn't "smell right" then there is a good chance that that is actually the case. As you gain experience developing software your instincts become sharper, and what your instincts are telling you subconsciously can often be an important input into your modeling efforts. If your instincts tell you that a requirement doesn't make sense or it isn't Same issue as Work With People's complete investigate it with your users. If your everyone can Instincts instincts tell you that a portion of your learn from architecture isn't going to meet your needs build a everyone else. quick technical end-to-end prototype to test out your theory. If your instincts tell you that design alternative A is better than design alternative B, and there is no compelling reason to choose either one of them, then go with alternative A for now. It's important to understand that the value of courage tells you that should assume you can remedy the situation at some point in the future if you discover your instincts were wrong.
Simple Tools for Software Modeling -ORIt's "Use the Simplest Tool" not "Use Simple Tools"
A common misunderstanding about Agile Modeling is that it is only focused on inclusive modeling using simple tools such as whiteboards and paper. The fact is that some agile modelers use very sophisticated, software-based modeling tools. In this article I discuss:
1. Use the simplest tools? 2. Simplicity enables agility 3. When should you use CASE tools?
o o o
Potential CASE tool costs Potential CASE tool benefits Selecting a CASE tool
4. What modeling tools are agilists using in practice?

1. Use the Simplest Tools? One of the most commonly asked questions asked by developers is What tool(s) should we use? Although there are as many answers to this question as people asking it, I would like to provide a few words of advice to help guide you: Use the simplest tools possible. Why simple tools? Simple tools are easy to learn, easy to use, and very often easy to share with others. Yes, complex tools have their place, assuming they provide the best value for your investment in them, but never underestimate the effectiveness of simple tools either. Some simple tools for modeling:
Index cards. The eXtreme Programming (XP) community swears by the use of standard index cards for a wide variety of modeling techniques, and in particularClass Responsibility Collaborator (CRC) modeling. Post-It notes. Post-It notes are also an option for you, for example you can develop an abstract/essential user interface prototype using Post-Its on large sheets of paper. This is part of a technique called essential user interface modeling, described in Software For Use by Larry Constantine and Lucy Lockwood or my ownThe Object Primer 3/e. Paper. Pieces of paper, or index cards, tacked onto a whiteboard and connected by strings can be used for a wide variety of models. For example the individual sheets of paper can represent database tables and the lines relationships between tables on a physical data model, or the sheets can represent screens and the strings navigation flows between screens on a user interface flow diagram, or the sheets can represent use cases and actors and the strings represent associations between them on a UML use case diagram. Plain old whiteboards (POWs). A whiteboard for sketching on is likely the most common modeling tool in use. A digital camera can easily make copies of sketches that you want to keep.
Why simple tools for modeling? I always advise that you should ask yourself why you are modeling, my philosophy being that you should develop something with an exact purpose in mind otherwise you shouldnt develop. If you are modeling to understand something then the value isnt in the model that you create but in the modeling itself. Therefore, you dont need to invest significant effort using a CASE tool to make your model look pretty, or to add comprehensive documentation to it. Instead youre better off using a simple tool, such as index cards or a whiteboard, to enable you to get your modeling done quickly so you can get back to developing software. More importantly, when you also adopt simple techniques you discover that your models are inclusive for your stakeholders, enabling active stakeholder participation. 2. Simplicity Enables Agility When should you use simple tools? My rule of thumb is that the greater the amount of uncertainty surrounding the issue that you are modeling the greater the flexibility you will want in your tools, therefore the simpler your tools need to be. As you gain a greater understanding of an issue you can migrate to more complicated tools as required, assuming that the tools provide the best value possible for your investment in their usage, typically starting with manual tools such as index cards or white boards and eventually moving to a design CASE tool or programming IDE. For example, when I am first exploring how I intend to build a screen I will often use Post-It notes, sticking them to the nearest flat surface (a desktop, a whiteboard, ) that I can find. Post-Its are easy to work with, you can write brief descriptions on them or little sketches, and easy to move around. Furthermore they stay where you
put them because of the glue on their backside. Post-Its are great at the beginning of screen design because you can get a feel for the layout very quickly, adding and removing widgets quickly. Once Im happy with the layout Ill either move straight to coding the screen or to the whiteboard. I base this decision on my initial purpose for developing the screen layout model in the first place. If my goal was to simply get a strategy for organizing the major widgets that will make up the screen then Ive very likely satisfied that purpose and can therefore move on. If my goal is to determine how I will organize the screen and to identify the widgets that I intend to use then I will very likely move to a whiteboard first. With a whiteboard I can draw the widgets with greater accuracy, drawing them to their relative size as reasonable facsimiles of the actual type of widget (check box, single-line entry field, multiple-line entry field, ). However, whiteboards arent as flexible as Post-Its if I discover that I need to move several widgets then I may have a lot of erasing and redrawing with a whiteboard, whereas with Post-Its I simply move them around. The observation is that I the gain in fidelity by moving to a whiteboard was counter-acted by a loss in agility. Once Im happy with the whiteboard drawing the purpose for developing the model would once again determine my next step. If I was simply modeling to understand the design of the screen then I would go straight to code. However, if I was modeling to communicate, perhaps my organizations process insists on the development of detailed screen specifications before any coding can begin (clearly not a very agile process) then that would be my next step. Actually my next step would very like to be to fight this tooth and nail, but fighting the bureaucrats within your organization is another issue entirely. If I am forced to create comprehensive documentation Ill likely use a CASE tool that specializes in the type of documentation that Im trying to create, in this case a screen specification. As an aside, an important lesson to take away from this discussion is that models are not necessarily documents I would consider both the Post-It notes and the whiteboard sketches to be models, likely ones I will discard. Why not jump straight to code? First, code isnt as flexible as either Post-Its or whiteboard sketches, I cant move things around as easily as I can with Post-It notes and I very likely cant change widget types as easily as I can sketch. In short, I suspect that a few minutes working with Post-It notes and possible drawing some sketches will very likely pay for itself several times over in saved coding time. Second, Post-Its and sketches are more inclusive than code, non-developers such as my direct users can become actively involved with the effort which makes a lot of sense to me because were working on something they can directly relate to (the user interface). 3. When Should You Use CASE Tools? On the surface it is easy to assume that if you're an agile modeler that you aren't going to use a CASE tool. Poppycock! An agile modeler uses a tool, any tool, when that tool makes the most sense for that situation. Just like a carpenter will use a manual screwdriver sometimes and other times a electric screwdriver, sometimes an agile modeler will use an index card and other times a complex software design tool. Any tool, including Computer Aided System Engineering (CASE) tools, should be used only when it is the option that provides the maximal value for your investment in it. This is basic investment theory if you can invest your money one way and get a 10% overall return, or you can invest your money another way and get a 15% overall return, everything else being equal youre better off with the second investment. With respect to modeling tools, you always have several choices: use simple tools such as index cards and white boards, use a diagramming tool such as Microsoft Visio, or a more complicated tool such as Compuware's OptimalJ, Borlands Together, Rational System Architect, or Computer Associates ERWin. So how do you calculate the expected value for your investment in a tool? I suggest that you dont, at least not from in strict accounting sense of the idea. Yes, you could prepare a complex spreadsheet listing all the costs, both quantitative costs that have a clear dollar value and qualitative costs that need to be fudged into a dollar value, and then compare them with the expected benefits, both quantitative and qualitative. Youd naturally have to calculate the net present value (NPV) of all of those figures to ensure that youre comparing apples to apples. Ive got a pretty good write-up of how to do all this in my book Process Patterns if youre really interested, but I highly suggest against this sort of lengthy analysis. Why? Because its a lot of work that is more often than not a faade used to justify a political decision anyway.
3.1 Potential CASE Tool Costs
Initial training and education
Evaluation costs Maintenance of the model over time (its even worse when the model has outlasted its usefulness but youre still maintaining it for posterity) Upgrade costs of the tool Ongoing usage/maintenance fees Time lost waiting for the tool to do its job Time lost over-using the tool (e.g. making your diagrams look pretty, extraneous information, and so on) Migration costs to port models to another tool Increased effort to synchronize models with other artifacts, such as source code CASE tools often promote syntax over communication between developers (in other words, your model looks good but doesnt necessarily work) Generated code often too simplistic, or cluttered with extraneous information required by the tool Poor user interfaces often hamper the modeling effort Inadequate integration with other tools reduces productivity and/or requires integration work Complex tools are often prevent the inclusion of non-developers in your modeling efforts
3.2 Potential CASE Tool Benefits
Forward engineering (code generation) Reverse engineering of existing code Support for changing levels of abstraction (e.g. from requirements to analysis to design to code) Testing of the consistency and validity of your models Synchronization of models with delivered code Support for different views and/or potential solutions to a problem Generation of documentation
3.3 Selecting a CASE Tool The principle Model With a Purpose tells you that you should know why you are creating an artifact. Knowing the purpose for an artifact indicates the extent of the work that you need to perform to complete your model, you stop as soon as your model fulfills its purpose, and this in turn provides insight into what you require of your tools. By knowing your actual requirements you can then determine whether a given tool will actually provide the most value for your situation. My experience is that a gut-feel approach to choosing your tools is often the most effective approach, albeit one that senior management may not trust you to take. Furthermore, you should know the features of the tools that you are using, and the practice Use the Simplest Tools tells you to select the most simple tool (even if its a CASE tool) that will do the job. Consider some examples: 1. You are modeling simply to explore the potential structure of several Java classes. You clearly need a tool that supports class diagramming and perhaps supports generation of Java code. My two best options would likely be a whiteboard, I would sketch the classes and then proceed to write code, or Together/J, I would use the tool to diagram the classes and then generate the code from the diagram. My deciding factor would be how well I know Together/J and how likely is it that I would need to work with the tool in the future If I know the tool well or it was likely that I would be doing enough Java development in the future to warrant my learning the tool, then Together/J would be a good choice for me because one of its primary strength is its support for Java developers. You are developing the table structure for a database. Yes, you could choose to sketch the schema on a whiteboard and then start coding the data definition language (DDL) code to create those tables, and the procedural code for any triggers, but thats a lot of work. Several CASE tools exist, Computer Associates ERWin is one, that supports the ability to generate the DDL and triggers automatically from a data model. Once again, the deciding factors are skill with the tool and whether it is worth the investment to learn the tool. Your organization has won a bid to identify and document the requirements for a system, with the hope that you will win the next stage of the project (the actual development itself). Ignoring the dysfunctional aspects of the serial nature of this project, the reality is that many projects, particularly those for the U.S. Federal Government, work this way. In this situation I would be tempted to use a
2.
3.
variety of tools a Word Processor for textual information, a tool that supports creation of use case diagrams (Visio, PowerPoint, Rational Rose), and perhaps even a tool to manage the requirements (Requisite Pro or DOORS).
4. What Modeling Tools Are Agilists Using In Practice? In my Agile Adoption Rate survey in March 2007 I asked about the effectiveness of various approaches to modeling was on agile teams. The results is summarized in the histogram of Figure 1. As you can see, Agilists do in fact model in practice, and that inclusive tools such as whiteboards and paper seem very popular. It's interesting to note that CASE tools are also in use, although only 68% of the teams doing so find them useful in practice. Furthermore, I suspect that drawing tools such as Visio are being lumped into the CASE tool category. Figure 1. Adoption Rates of Modeling on Agile Teams.
The DDJ 2008 Modeling and Documentation survey explored how people approach modeling and documentation. Figure 2 summarizes the results of the question that looked into the primary approach to modeling, and regardless of development paradigm sketching was the most common approach to modeling (SBMT = Software Based Modeling Tool, my term for CASE). Figure 2. Primary approaches to modeling.
4. Recommended Resources
Active Stakeholder Participation Agile Modeling Best Practices Agile Requirements Best Practices Inclusive Models Roadmap for Agile MDA
Agile Requirements Best Practices To be honest, I'm not very enamored with the term "best practice". I believe that the term "contextual practice" makes far more sense because what is a "best practice" in some situations proves to be a "worst practice" in others. Having said that, people are interested in best practices so here they are when it comes to agile requirements modeling:
1. Stakeholders actively participate 2. Adopt inclusive models 3. Take a breadth-first approach 4. Model storm details just in time (JIT) 5. Treat requirements like a prioritized stack 6. Prefer executable requirements over static documentation 7. Your goal is to implement requirements, not document them 8. Recognize that you have a wide range of stakeholders 9. Create platform independent requirements to a point 10. Smaller is better 11. Question traceability 12. Explain the techniques 13. Adopt stakeholder terminology 14. Keep it fun 15. Obtain management support 16. Turn stakeholders into developers
1. Stakeholders Actively Participate When you are requirements modeling the critical practice is Active Stakeholder Participation. There are two issues that need to be addressed to enable this practice availability of project stakeholders to provide requirements and their (and your) willingness to actively model together. My experience is that when a project team doesnt have adequate access to project stakeholders that this is by choice. You have funding for your project, dont you? That must have come from some form of project stakeholder, so they clearly exist. Users must also exist, or at least potential users if youre building a system you intend to provide to the public, so there clearly is someone that you could talk to. Yes, it may be difficult to find these people. Yes, it may be difficult to get them to participate. Deal with it. In Overcoming Common Requirements Challenges I discuss several common problems that development teams often face, including not having full access to project stakeholders. My philosophy is that if your project stakeholders are unable or unwilling to participate then that is a clear indication that your project does not have the internal support that it needs to succeed, therefore you should either address the problem or cancel your project to minimize your losses. Active Stakeholder Participation is a core practice of Agile Modeling (AM). What does it mean for a project stakeholder to actively participate? Figure 1 presents a high-level view of the requirements process, using the notation for UML activity diagrams, indicating the tasks that developers and project stakeholders are involved with. The dashed line is used to separate the effort into swim lanes that indicate what role is responsible for each process. In this case you see that both project stakeholders and developers are involved with identifying ideas or suggestions, discussing a potential requirement, and then
modeling and potentially documenting it. Project stakeholders are solely responsible for prioritizing requirements, the system is being built for them therefore they are the ones that should set the priorities. Likewise, developers are responsible for estimating the effort to implement a requirement because they are the ones that will be doing the actual work it isnt fair, nor advisable, to impose external estimates on developers. Although prioritization and estimation of requirements is outside the scope of AM, it is however within the scope of the underlying process such as XP or UP that you are applying AM within, it is important to understand that these tasks are critical aspects of your overall requirements engineering effort. For further reading, see the Agile Requirements Change Management article.
Figure 1. A UML activity diagram overviewing the requirements engineering process.
My philosophy is that project stakeholders should be involved with modeling and documenting their requirements, not only do they provide information but they actively do the work as well. Yes, this requires some training, mentoring, and coaching by developers but it is possible. I have seen project stakeholders model and document their requirements quite effectively in small start-up firms, large corporations, and government agencies. Ive seen it in the telecommunications industry, in the financial industry, in manufacturing, and in the military. Why is this important? Because your project stakeholders are the requirements experts. They are the ones that know what they want and they can be taught how to model and document requirements if you choose to do so. This makes sense from an agile point of view because it distributes the modeling effort to more people.
2. Adopt Inclusive Models To make it easier for project stakeholders to be actively involved with requirements modeling and documentation, to reduce the barriers to entry in business parlance, you want to follow the practice Use the Simplest Tools. Many of the requirements artifacts listed in Table 1 below can be modeled using either simple or complex tools a column is included to list a simple tool for each artifact. Figure 2 and Figure 3 present two inclusive models created using simple tools, Post It notes and flip chart paper was used to model the requirements for a screen/page in Figure 2 (an essential UI prototype) and index cards were used for conceptual modeling in Figure 3 (aCRC model). Whenever you bring technology into the requirements modeling effort, such as a drawing tool to create clean versions of use case diagrams or a full-fledged CASE tool, you make it harder for your project stakeholders to participate because they now need to not only learn the modeling techniques but also the modeling tools. By keeping it simply you encourage participation and thus increase the chances of effective collaboration.
Figure 2. An essential user interface prototype.
Figure 3. Two CRC cards.
3. Take a Breadth-First Approach My experience is that it is better to paint a wide swath at first, to try to get a feel for the bigger picture, than it is to narrowly focus on one small aspect of your system. By taking a breadth-first approach you quickly gain an overall understanding of your system and can still dive into the details when appropriate. Many organizations prefer a "big modeling up front (BMUF)" approach to modeling where you invest significant time gathering and documenting requirements early in the project, review the requirements, accept and then baseline them before implementation commences. This sounds like a great idea, in theory, but the reality is that this approach is spectacularly ineffective. A 2001 study performed by M. Thomas in the U.K. of 1,027 projects showed that scope management related to attempting waterfall practices, including detailed, up-front requirements, was cited by 82 percent of failed projects as the number one cause of failure. This is backed up by other research according to Jim Johnson of the Standish Group when requirements are specified early in the lifecycle that 80% of the functionality is relatively unwanted by the users. He reports that 45% of features are never used, 19% are rarely used, and 16% are sometimes used. Why does this happen? Two reasons:
When project stakeholders are told that they need to get all of their requirements down on paper early in the project, they desperately try to define as many potential requirements (things they might need but really aren't sure about right now) as they can. They know if they don't do it now then it will be too hard to get them added later because of the change management/prevention process which will be put in place once the requirements document is baselined. Things change between the time the requirements are defined and when the software is actually delivered.
The point is that you can do a little bit of initial, high-level requirements envisioning up front early in the project to understand the overall scope of your system without having to invest in mounds of documentation.
Through initial, high-level
modeling you can gain the knowledge that you need to guide the project but choose to wait to act on it.
4. Model Storm Details Just In Time (JIT) Requirements are identified throughout most of your project. Although the majority of your requirements efforts are performed at the beginning your project it is very likely that you will still be working them just before you final code freeze before deployment. Remember the principle Embrace Change. Agilists take an evolutionary, iterative and incremental, approach to development. The implication is that you need to gather requirements in exactly the same manner. Luckily AM includes practices such asCreate Several Models in Parallel, Iterate To Another Artifact, and Model In Small Increments which enable evolutionary modeling.
The shorter the feedback cycle between model storming a requirement and implementing it, the less need there is for documenting the details.
5. Treat Requirements Like a Prioritized Stack Figure 4 overviews the agile approach to managing requirements, reflecting both Extreme Programming (XP)s planning game and the Scrum methodology. Your software development team has a stack of prioritized and estimated requirements which needs to be implemented co-located agile teams will often literally have a stack of user stories written on index cards. The team takes the highest priority requirements from the top of the stack which they believe they can implement within the current iteration. Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers. If you do this then any change to a requirement youre currently implementing should be treated as just another new requirement.
Figure 4. Agile requirements change management process.
6. Prefer Executable Requirements Over Static Documentation During development it is quite common to model storm for several minutes and then code, following common Agile practices such as Test-First Design (TFD) andrefactoring, for several hours and even several days at a time to implement what you've just modeled. This is where your team will spend the majority of its time. Agile teams do the majority of their detailed modeling in the form of executable specifications, often customer tests or development tests. Why does this work? Because your model storming efforts enable you to think through larger, cross-entity issues whereas with TDD you think through very focused issues typically pertinent to a single entity at a time. With refactoring you evolve your design via small steps to ensure that your work remains of high quality. 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 its done effectively. This is why we need to go beyond TDD to consider AMDD.
7. Your Goal is To Effectively Implement Requirements, Not Document Them Too many projects are crushed by the overhead required to develop and maintain comprehensive documentation and traceability between it. Take an agile approach to documentation and keep it lean and effective. The most effective documentation is just barely good enough for the job at hand. By doing this, you can focus more of your energy on building working software, and isn't that what you're really being paid to do?
The urge to write requirements documentation should be transformed into an urge to instead collaborate closely with your stakeholders and
then create working software based on what they tell you.
8. Recognize That You Have a Wide Range of Stakeholders End users, either direct or indirect, aren't your only stakeholders. Other stakeholders include managers of users, senior managers, operations staff members, the "gold owner" who funds the project, support (help desk) staff members, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project. To name a few. These people aren't going to agree with one another, they're going to have different opinions, priorities, understandings of what they do, understandings of what others do, and visions for what the system should (or shouldn't) do. The implication is that you're going to need to recognize that you're in this situation and then act accordingly. Figure 5 shows how agile teams typically have someone in a stakeholder representative role, this role is called product owner in Scrum, whom they go to as the official source of information and prioritization decisions. This works well for the development team, but essentially places the burden on the shoulders of this person. Anyone in this role will need to:
1. Have solid business analysis skills, particularly in negotiation, diplomacy, and requirements
2.
3.
4.
elicitation. Educate the team in the complexity of their role. Be prepared to work with other product owners who are representing the stakeholder community on other development teams. This is particularly true at scalewith large agile teams. Recognize that they are not an expert at all aspects of the domain. Therefore, they will need to have good contacts within the stakeholder community and be prepared to put the development team in touch with the appropriate domain experts on an as-needed basis so that they can share their domain expertise with the team.
Figure 5. You'll work with a range of stakeholders.
9. Platform Independent Requirements to a Point Im a firm believer that requirements should be technology independent. I cringe when I hear terms such as object-oriented (OO) requirements, structured requirements, or component-based requirements. The terms OO, structured, and component-based are all categories of implementation technologies, and although you may choose to constrain yourself to technology that falls within one of those categories the bottom line is that you should just be concerned about requirements. Thats it, just requirements. All of the techniques that I describe below can be used to model the requirements for a system using any one (or more) of these categories.
However, I also cringe when I hear about people talk about Platform Independent Models (PIMs), part of the doomed Model Driven Architecture (MDA) vision from the Object Management Group (OMG). Few organizations are ready for the MDA, so my advice is to not let the MDA foolishness distract you from becoming effective at requirements modeling. Sometimes you must go away from the ideal of identifying technology-independent requirements. For example, a common constraint for most projects is to take advantage of the existing technical infrastructure wherever possible. At this level the requirement is still technology independent, but if you drill down into it to start listing the components of the existing infrastructure, such as your Sybase vX.Y.Z database or then need to integrate with a given module of SAP R/3, then you've crossed the line. This is okay as long as you know that you are doing so and don't do so very often.
10. Smaller is Better Remember to think small. Smaller requirements, such as features and user stories, are much easier to estimate and to build to than are larger requirements, such as use cases. An average use case describes greater functionality than the average user story and is thus considered larger. They're also easier to prioritize and therefore manage.
11. Question Traceability Also, think very carefully before investing in a requirements traceability matrix. Traceability is the ability to relate aspects of project artifacts to one another, and a requirements traceability matrix is the artifact that is often created to record these relations it starts with your individual requirements and traces them through any analysis models, architecture models, design models, source code, or test cases that you maintain. My experience is that organizations with traceability cultures will often choose to update artifacts regularly, ignoring the practice Update Only When it Hurts, so as to achieve consistency between the artifacts (including the matrix) that they maintain. They also have a tendency to capture the same information in several places, often because they employ overly specialized people who "hand off" artifacts to other specialists in a welldefined, Tayloristic process. This is not traveling light. A better approach is to single source information and to build teams of generalizing specialists. The benefits of having such a matrix is that it makes it easier to perform an impact analysis pertaining to a changed requirement because you know what aspects of your system will be potentially affected by the change. However, if you have one or more people familiar with the system, which you want to have anyway if you want to be effective at enhancing the system, then it is much easier and cheaper to simply ask them to estimate the change. My experience is that traceability matrices are highly overrated because the total cost of ownership (TCO) to maintain such matrices, even if you have specific tools to do so, far outweigh the benefits. Make your project stakeholders aware of the real costs and benefits and let them decide after all, a traceability matrix is effectively a document and is therefore a business decision to be made by them. If you accept the AM principle Maximize Stakeholder ROI, if you're honest about the TCO of traceability matrices, and if you adopt tools which automatically provide most of your traceability needs anyway then formal traceability truly becomes questionable. I'm a firm believer in traceability if you have actual regulatory compliance needs, for example the Food and Drug Administration's CFR 21 Part 11 regulations requires it, then clearly you need to conform to those regulations. I question traceability which is solely motivated by "it's a really good idea", "we need to justify the existence of people on the CCB" (it's rarely worded like that, but that's the gist of it), or "CMMI's Requirements Management process area requires it". In reality there's lots of really good ideas out there with much better ROI, surely the CCB members could find something more useful to do, and there aren't any CMMI police so don't worry about it. In short, just like any other type of work product, you should have to justify the creation of a traceability matrix.
It's requirements analysis, not retentive
analysis. ;-)
12. Explain the Techniques Everyone should have a basic understanding of a modeling technique, including your project stakeholders. Theyve never seen CRC cards before? Take a few minutes to explain what they are, why you are using them, and how to create them. You cannot follow the practice Active Stakeholder Participation if your stakeholders are unable to work with the appropriate modeling techniques.
13. Adopt Stakeholder Terminology Do not force artificial, technical jargon onto your project stakeholders. They are the ones that the system is being built for, therefore, it is their terminology that you should use to model the system. As Constantine and Lockwood say, avoid geek-speak. An important artifact on many projects is a concise glossary of business terms.
14. Keep it Fun Modeling doesnt have to be an arduous task. In fact, you can always have fun doing it. Tell a few jokes, and keep your modeling efforts light. People will have a better time and will be more productive in a fun environment.
15. Obtain Management Support Investing the effort to model requirements, and in particular applying agile usage-centered design techniques, are new concepts to many organizations. An important issue is that your project stakeholders are actively involved in the modeling effort, a fundamental culture change for most organizations. As with any culture change, without the support of senior management you likely will not be successful. You will need support from both the managers within you IS (information system) department and within the user area.
16. Turn Stakeholders Into Developers An implication of this approach is that your project stakeholders are learning fundamental development skills when they are actively involved with a software project. It is quite common to see users make the jump from the business world to the technical world by first becoming a business analyst and then learning further development skills to eventually become a full-fledged developer. My expectation is that because agile software development efforts have a greater emphasis on stakeholder involvement than previous software development philosophies we will see this phenomena occur more often keep a look out for people wishing to make this transition and help to nurture their budding development skills. You never know, maybe some day someone will help nurture your business skills and help you to make the jump out of the technical world.
Active Stakeholder Participation Agile Analysis Agile Requirements Agile Requirements Change Management
Best Practices for Agile/Lean Documentation The "Change Prevention" Anti-Pattern Comparing the Various Approaches to Modeling in Software Development Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Sense Document Late: An Agile Best Practice The "Flexible Features Split" Pattern Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Iteration Modeling Model a Bit Ahead Overcoming Common Requirements Modeling Challenges Examining the "Big Requirements Up Front (BRUF)" Approach Prioritized Requirements: An Agile Best Practice Rethinking How You View Requirements Management Rethinking the Role of Business Analysts The Unchangeable Rules of Software Change (Brad Appleton, Robert Cowham, and Steve Berczuk) Introduction to Agile Usability User Experience Activities on Agile Development Projects
This article presents a coherent strategy for bringing usability practices into agile project, summarizing Chapter 4 of Maturing Usability: Quality in Software, Interaction, and Value. User experience (UEX) and agile practitioners need to learn about and respect each others philosophies and techniques, and then actively find ways to work together. This requires both communities to make minor changes to the way that they work, but if they choose to make these changes I suspect that their work products will be much better for it. With an agile UEX approach you will do high-level, very broad modeling at the beginning of the agile project to address the majority usability and UI issues facing the team. You dont need a detailed answer, the details can come later on a JIT basis during development, but you do need a strategy. During development usability practitioners should be embedded within the development team, working on UEX tasks when needed but also working with their teammates on non-UEX activities. Agile teams are made up ofgeneralizing specialists with the ability to work on a wide range of things, instead of narrowly focused specialists typically found on traditional teams. User testing, including usability testing, is done throughout the lifecycle, it isnt left to the end of the project where it is invariably too late to act. In The Inmates Are Running The Asylum Alan Cooper indicates that many of todays software-based products suffer from usability challenges. He believes that the key to solving the problem is to perform what he calls interaction design before the programming effort to design the way that software behaves before it is built. Cooper believes programmers consciously design the code inside programs but only inadvertently design the interaction with humans. Although programmers work hard to make their software easy to use, their frame of reference is themselves and as a result they make it easy for other software engineers, not normal human beings. He argues that programmers have too much influence over the design of the human interface and due to a lack of skills in this area do a poor job of it. In other words, the programming inmates are running the software development asylum. My experience is similar to Coopers, there is a need for improved interaction design skills within the programming community, although I dont agree with his proposed solution. Reading between the lines of both The Inmates Are Running the Asylum and a discussion between Kent Beck and Alan Cooper, it seems to me that most of Coopers experiences are with traditional development teams but not agile teams. Although I believe that his observations about the interaction design skill levels of developers apply to both the traditional and agile software development (ASD) communities, I fear that his advice is difficult for traditionalists to implement and all but impossible for agilists. The goal of this article is to show how to make the advice of the user experience community palatable, or perhaps usable is a better term, to the agile community.
Table of Contents
1. 2. 3. 4. 5. 6.
7. 8.
Agile Software Development (ASD) User Experience (UEX) Activities Current state of the art Addressing some misconceptions User experience modeling on an agile project User testing on an agile project o Acceptance testing o Usability testing o Usage testing A call to action Potential Challenges
1. Agile Software Development (ASD) To address the challenges faced by software developers an initial group of 17 methodologists formed the Agile Software Development Alliance, often referred to simply as the Agile Alliance, in February of 2001. An interesting thing about this group is that they all came from different backgrounds, yet were able to come to an agreement on issues that methodologists typically dont agree upon. This group of people defined a manifesto which defines 4 values and 12 principles for encouraging better ways of developing software; this manifesto defines the criteria for ASD processes. Just as the Software Engineering Institutes Capability Maturity Model Integrated (CMMI) defines the requirements for a heavy-weight software development process, the agile manifesto defines the requirements for an agile software process. Agile processes which reflect these requirements include:
Agile Data (AD) Agile Microsoft Solutions Framework (MSF) Agile Modeling (AM) Agile Unified Process (AUP) Dynamic System Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) Scrum Usage-Centered Design (UCD)
The vast majority of agile projects are teams of less than ten people, are co-located, have direct access to stakeholders, have access to inclusive modeling tools such as whiteboards and corkboards, have their own development machines, and have access to the development tools that they require, including testing tools. Having said that, some agile teams are very large (upwards of several hundred people), some are dispersed geographically, and some do not always have easy access to stakeholders (Eckstein 2004). Although most agile teams take an test-driven development (TDD) approach where they write a unit test before writing just enough production code to fulfill that unit test, they typically do not have access to UI testing tools. Furthermore, they rarely have access to a usability lab, so in this respect agile is little different than traditional development. Figure 1 depicts my rendition of a generic agile SDLC, which is comprised of four phases: Iteration 0, Development, Release, and Production. Although many agile developers may balk at the idea of phases, the fact is that it's been recognized that processes such as XP, AUP, and Agile MSF (which calls phases "tracks" instead) do in fact have phases.
Figure 1. The Agile SDLC.
Lets consider each phase in turn:
1. Iteration 0. The first week or so of an agile project is often referred to as "Iteration 0" or Cycle 0
(cycle is an alternative term for iteration). The goal during this period is to initiate the project by garnering initial support and funding for the project; actively working with stakeholders to initially envision the requirements of the system at a high-level; starting to build the team; modeling an initial architecture for the system; and setting up the environment. Development phase. During development iterations agilists incrementally deliver high-quality working software which meets the changing needs of stakeholders. Release phase. During the release iterations(s) agile practitioners transition the system into production. Production. The goal of this phase is to keep systems useful and productive after they have been deployed to the user community. The fundamental goal is to keep the system running and help users to use it.
2. 3. 4.
On the surface, the agile SDLC of Figure 1 looks very much like a traditional SDLC, but when you dive deeper you quickly discover that this isn't the case. Because the agile SDLC is highly collaborative, iterative, and incremental the roles which people take are much more robust than on traditional projects. In the traditional world a business analyst created a requirements model that is handed off to an architect who creates design models that are handed off to a coder who writes programs which are handed off to a tester and so on. On an agile project, developers work closely with their stakeholders to understand their needs, they pair together to implement and test their solution, and the solution is shown to the stakeholder for quick feedback. Instead of specialists handing artifacts to one another, and thereby injecting defects at every step along the way, agile developers aregeneralizing specialists with full lifecycle skills. More importantly, from a user experience point of view, they take a very different approach to modeling and testing than traditionalists do.
2. User Experience (UEX) Activities Usability is a quality attribute of a system which encompasses learnability, efficiency, memorability, error recovery, and end-user satisfaction (Neilson 1994). User-centered
design, also known as UCD although I will use that abbreviation for usage-centered design, is a highly structured, product development process where the focus is on understanding the needs and goals of the user of the product. Interaction Design (ID) is a methodology described by Alan Cooper where the goal is to provide end users with functions that are both desirable and useful. In ID, interaction designers focus on whats desirable, engineers on what theyre capable of building, and business stakeholders on whats viable I use the term user experience (UEX) to encompass all of these concepts although there is good reason to distinguish between the various ideas, that isnt relevant for my current discussion. An important question to ask is why should agile practitioners consider UEX important? Jeff Patton believes that UEX addresses several issues which are critical to the success of ASD teams:
UEX places emphasis on the usage necessary for roles to meet their goals. UEX helps meet the goal of identifying the behavior the software should have. UEX practices can be applied with varying degrees of formality, thereby making them compatible with agile methodologies.
Other important terminology which I use in this article includes:
System. The product, which often includes software, under development. User. Also known as an end user, a user is a person who will actually work with the system/product being built. Developer. An IT professional involved with the creation of the system. Stakeholder. A stakeholder is anyone who has a stake in the creation or operation of the system. This includes people who are a direct user, indirect user, manager of users, senior manager, developer, operations staff member, support (help desk) staff member, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project. Some agile methodologies, XP in particular, uses the term customer. Acceptance testing. A testing technique, the goal of which is to determine whether a system satisfies its acceptance criteria and to enable the stakeholder(s) to determine whether to accept the system Usability testing. A method by which users of a system are asked to perform certain tasks in an effort to measure the systems ease-of-use, task time, and the user's perception of the experience. Usability testing can be both formal and informal, using dedicated rooms and equipment to simply using physical mock ups of the system. User testing. Testing activities, including both acceptance and usability testing, where stakeholders are actively involved.
3. Current State of the Art First the good news. I believe that there is a growing recognition within both the agile and UEX communities that they can benefit by working closely with the other. Within the agile community Larry Constantines UCD work is well respected and the UEX community seems intrigued by the promises of ASD. There is an active Agile Usability mailing list where ASD and UEX practitioners interact regularly. There are agile usability tutorials at conferences, including both UPA 2005 and Agile 2005 recently. There seems to be a will to bring the two communities together. Now for the bad news. There are several challenges which need to be overcome if were to work together effectively, and just the fact that we talk about two different communities indicates that we have a problem. These challenges include:
Different goals. Software engineers focus on the technical design, implementation, and maintenance of software system. UEX practitioners focus on developing systems so end-users can use them effectively. Unfortunately each group seems to all-but-ignore the issues addressed by the other. Different approaches. UEX methodologies are centered on the user whereas agile methodologies take a broader view and focus on the stakeholder. With UEX methods one tries to get a holistic view of the user needs and comes up with an overall plan for the user interface before starting
implementation. Agile methods favor little up front design and instead focus on delivering working software early. Organizational challenges. The agile community follows a highly collaborative and fluid organizational strategy where teams are self organizing. This doesnt appear to always be the case with the centralized UEX groups within some organizations. While a center for UEX is important to provide the needed practices, tools, and standards, a strong organizational and management hierarchy can be problematic. Process impedance mismatch. The agile community forgoes detailed modeling up early in the project, something they refer to as Big Design Up Front (BDUF). Many within the UEX community prefer more comprehensive modeling early in the project to design the user interaction properly before construction begins. UEX practitioners struggle to be heard. Although this is true within traditional teams as well, my experience is that this isnt as problematic with agile teams for the simple reason that agile practitioners favor high levels of collaboration. Jokela and Abrahamsson (2004) believe that UEX practitioners often complain that the results of their work are not considered in the design decisions. They also point out that no UEX practitioners were invited to participate in the formation of the Agile Alliance, which may be why there has been insufficient UEX influence to date within the ASD community. Our thought leaders may be a bit too extreme. This was exhibited in the discussion between Kent Beck and Alan Cooper, the founders of Extreme Programming (XP) and Interaction Design (ID) respectively. Many interesting points came out of the discussion pertaining to the differences between the agile and UEX philosophies, summarized in Table 1. Unfortunately, both Beck and Cooper seem to be at the extreme end of the discussion, and you can see in the interview there were bones of contention that werent resolved.
Table 1. Comparing agile and UEX philosophies. Agile Philosophies UEX Philosophies
Asks How can what we have now be improved this iteration? You should work closely with your stakeholders/customers to identify their exact needs. Details behind requirements can be identified on a just-intime (JIT) basis during development. Detailed, up-front modeling is a risky endeavor at best. Interaction design has a role to play from the beginning of a project, as a way to come up with the metaphors for the project.
Asks What is the ideal system? Defining the behavior of software-based products and services is very difficult and it has to be done from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems. All behavioral issues need to be addressed before construction begins.
4. Addressing a Few Misconceptions To help promote effective collaboration between the two communities we need to clear up a few misconceptions that each community may have with the other. There are several that UEX practitioners may have about the agile community:
Agilists dont model. The actual fact is that agile practitioners do in fact model, its just that they discourage extensive up-front design work in favor of more agile approaches to modeling. Agilists are continually deploying software into production. Although some teams do this, its not the norm. What is common is to deliver working software on a regular basis, perhaps every few weeks, into an internal environment for system and user testing. Deployment into production may occur every six-to-twelve months, if not longer, based on need and the ability of our end users to accept new releases. XP is the only game in town. This is a serious misunderstanding because UEX practitioners who believe this miss agile methods such as Scrum, Agile Modeling, MSF for Agile, and DSDM which are arguably more attuned to their philosophies. There is no role for UEX practitioners. Many agile methods forgo the concept of specific roles in favor of more generic roles such as developer/programming, coach/leader, and customer/stakeholder. Agilists arent specialists. This is partly true because agilists prefer to be generalizing specialists". User interfaces shouldnt be refactored. Many people fear refactoring the user interface, often because they believe the UEX issues will be forgotten or that end users will not be able to deal with continual change. The reality is that UI refactoring results in the slow but safe evolution of the UI, thereby improving its design. To ensure that UEX issues aren't forgotten, people with UEX skills should be involved with the development and evolution of the UI. Yes, the UI changes, hopefully for the better, but the only people affected by the changes on a continual basis are those actively involved in user testing. And when you stop to think about it, shouldnt developers act on the findings of usability testing efforts and thereby improve the UI?
The agile community equally suffers from debilitating misperceptions about the UEX community:
All you need is a good set of UI guidelines. Thats a good start, but there is a fair bit more to UEX than creating consistent UIs. Working closely with stakeholders is good enough. Thats also a good start, but Jokela and Abrahamsson (2004) found that even a close and frequent co-operation between developers and stakeholders does not ensure good usability at all. UEX is just about UI design. UI design is clearly a part of UEX, but so is understanding how your users will work with your system and what their goals for using the system are so that you can build something that is usable by them. This requires significant modeling and collaboration skills to accomplish. UEX relies on comprehensive up-front modeling. Although some people (Cooper 2004) in the UEX community want you to believe that, many others believe different. In many ways getting the UI right is similar to getting your architecture right, it often requires some up front thought although that doesn't imply that you need to take a serial approach to development.
5 User Experience Modeling on an Agile Project ASD practitioners are very pragmatic when it comes to modeling. The Agile Modeling (AM) methodology describes in detail how agilists approach both modeling and documentation. Figure 2 overviews the lifecycle of an Agile Model Driven Development (AMDD) approach to ASD, an approach which originally grew out of the XP community but which seems to capture the essence of the modeling approach on agile projects in general. Each box in the diagram represents a development activity. The initial modeling activity during iteration 0 includes two main sub-activities, initial requirements envisioning and initial architecture envisioning which are done iteratively in parallel. Theiteration planning/modeling, model storming and implementation activities potentially occur during any iteration, including iteration 0 (yes, the rumors are true, agile practitioners will often implement working software the very first week of a project). The time indicated in each box represents the length of an average session: for example, during development youll often model storm for a few minutes with a stakeholder to explore a requirement and then code for several hours.
Figure 2. The Agile Model Driven Development (AMDD) lifecycle.
The initial envisionment effort is typically performed during the first week of a project. For short projects (perhaps several weeks in length) you may do this work in the first few hours and for long projects (perhaps on the order of twelve or more months) you may decide to invest up to two weeks in this effort. There are two aspects to the initial envisioning effort:
1. Requirements modeling. You need to identify the high-level requirements as well as the scope of
the current release. The goal is to get a good gut feel what the project is all about, and to do that you will likely need to create an initial usage model to explore how users will work with your system (e.g. use cases or usage scenarios), an initial domain model which identifies fundamental business entity types and the relationships between then, and optionally other important artifacts exploring technical requirements. Architectural modeling. The goal of the initial architecture modeling effort is to try to identify an architecture that has a good chance of working. 99% of the time agile practitioners simply gather around a whiteboard and create free-form diagrams as they discuss various architectural strategies. When the UI architecture is an important consideration, agile modelers will create a UI navigation diagram (see Figure 3) which explores initial relationships between important screens/pages and reports (thereby giving you a birds-eye view of the UI, enabling you to ask fundamental usability questions).
2.
Figure 3. A UI navigation model for a university system (hand drawn).
In later iterations your initial models will evolve as you learn more, but during Iteration 0 the goal is to get something that is just barely good enough so that the team can get going. You dont need to model a lot of detail, and I cannot stress this enough: the goal is to build a shared understanding, it isnt to write detailed documentation. During development iterations the vast majority of modeling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These model storming sessions are "just in time" (JIT) efforts: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before. Sometimes modeling storming isnt enough. Perhaps you need to model complex requirements which require input from someone outside of your immediate team, or perhaps you need to model a legacy asset which can take a significant amount of time. In other words, you may need to model a bit ahead of actually implementing a requirement. This is actually a rare occurrence, regardless of what traditional modelers may hope for, but it does happen every so often. All of this begs the question how can UEX activities fit in to an agile project? The easy answer is that agilists need to adopt usage-oriented requirements artifacts, such aspersonas, scenarios, or even use cases. The quickly explore user interface requirements, it is common to create abstract/low fidelity prototypes out of paper, such as the one in Figure 4 created from a flip chart sheet and sticky notes. This allows to you quickly explore the UI without doing a lot of up front work, and even enables agile usability testing. In fact several agile methodologies have done so, respectively Agile MSF, Agile Modeling, and the AUP. After this, its not so easy. Figure 4. An abstract UI prototype created with paper.
UEX practitioners can rail about the need for doing lots of design up front, but that message falls on deaf ears within the agile community. The bottom line is that from an agile perspective, traditional UEX techniques arent very usable for them, which is rather ironic when you stop and think about it. To make UEX techniques usable to agile practitioners, they must reflect the agile lifecycle. Luckily, this can be accomplished by:
Doing some UI modeling up front. You need to establish 3 things: Overall organization for the parts of the UI that fits with the structure of user tasks; a common scheme for navigation among all the parts; a visual and interaction scheme that provides a consistent look-and-feel to support user tasks. Yes, this takes some up-front work, but for the vast majority of systems this could easily be accomplished during Iteration 0. Remember that the amount of modeling that you need to do up front is dependent upon the context -- some teams will need to do more than others. Using modeling tools which reflect agile practices. For example, XP teams prefer to work with index cards, not documents, and AUP teams prefer whiteboard sketches. Luckily paper and whiteboards are common tools with many UEX practitioners. Modeling a bit ahead when appropriate. If you need to, explore important aspects of the UI before you implement them. Conducting a user session often involves scheduling specialized facilities that are in high demand, and making appointments with the appropriate stakeholders. Therefore you need to model a bit ahead. Doing UI development on a JIT basis the majority of the time. The UI is important, but then again so are many other aspects of a system (such as the network, the database design, and so on) and therefore the UI should be treated differently only when appropriate. When the goal of design is limited to a single feature or small set of features it is effective to perform UEX activities as part of the development of those features during the iteration. Adopt UEX-friendly requirements artifacts. As I pointed out earlier, some agile methods such as AUP, DSDM, and Agile MSF already do this. This same philosophy could be applied in XP, and frankly many XP teams already capture the need to implement a UI view as a user story.
6 User Testing on an Agile Project For the sake of this article, user testing encompasses:
Acceptance testing Usability testing Usage testing
6.1 Acceptance Testing The agile community has embraced the importance of acceptance testing, having built tools such as Fit (Mugridge and Cunningham 2005) to help automate it. The automated tests will be run often, at least daily if not several times a day. Manual user testing, on the other hand, is typically done an iteration behind. At the end of an iteration, many agile teams will deploy the working system into a QA/testing environment where user and system testing is performed. The team continues on, developing version N+1 of the system while obtaining defect reports pertaining to version N. Defect reports are treated just like any other requirement: they are estimated, prioritized, and put on the requirements stack to be addressed at some point in the future.
6.2 Usability Testing Usability testing is considered optional, and I have no doubt that many UEX practitioners will find that frustrating. Agile teams are little different from traditional teams in this respect, they very likely dont appreciate the need for usability testing (or other UEX practices for that matter). True usability testing requires repeated testing with numbers of users under controlled settings. Just like acceptance testing can be done regularly throughout development, so can usability testing. On agile projects usability testing should occur during the user testing effort after each iteration, assuming of course that someone on the team has those skills. There is a range to usability testing. At the "agile end" of the spectrum is Jeff Patton's agile usability testing. In a workshop at the Agile 2006 conference Patton described a technique where people simulate the system using abstract prototypes (see Figure 4). Using this strategy one developer simulates the system. They're not allowed to speak, only help the user navigate between "screens" (the paper prototypes). At least one user, although two seems to work well, works through a scenario via the paper prototype. For example, in a university system a scenario might be that they try to enroll in a seminar. The user(s) should narrate/discuss what they're thinking as they use the system. One or more developers act as observers, taking notes but not fixing the paper prototypes as the users work with the system. At the formal end of the spectrum is traditional usability testing where users are observed in a usability lab which is typically a room where a user can be observed working with the system. Usability labs often have one-way windows which enable people to watch the user, often a valuable learning experience for developers who mistakenly think that they've done a great UI design job. Some labs will even be outfitted with cameras so that you can record the exact interactions, in the hope of replaying the usage and hopefully acting to improve the design to support more effective usage. There is nothing stopping you from taking an agile approach to usability testing at some points in your project and formal usability testing at other points. Nor is there anything stopping you from doing something in between.
6.3 Usage Testing Usage scenario testing is a technique that can be used to test the logic captured within your design before you invest in implementing it. This is an inclusive technique which stakeholders can be actively involved with which can and should be performed in parallel with your modeling efforts to ensure that your model accurately reflects your business requirements. Using one ore more usage scenarios (a series of steps describing how someone works with your system) you walkthrough your class model and validate that it is able to support the scenario(s). If it does not, you update your model appropriately (or your code, as the case may be). Figure 5 presents usage scenario testing from the point of view of walking through a class model, although the same logic can also be followed to validate your user interface prototype (even if it is an abstract prototype).
Figure 5. The process of usage scenario testing (for a class model).
7. A Call to Action If the agile and UEX communities are going to work together effectively, they need to find a middle ground. I believe that middle ground exists, but that both communities need to adopt several changes in order to succeed. First, agile professionals must:
Learn UEX skills. Developers should be trained in, and adopt into their practices, UEX techniques. This will enable developers to work more collaboratively and effectively with UEX practitioners. Accept that usability is a critical quality factor. Luckily, agile practitioners are quality infected they understand the importance of doing high-quality work and have a proven track record of adopting techniques such as test-first programming, code refactoring, and database refactoring. Good usability of an end product can be ensured only by systematic usability engineering activities during the development iterations. Adopt UI and usage style guidelines. Developers must understand that not only should their code follow common guidelines, so should their UIs.
Similarly, UEX practitioners must make some changes. They need to:
Go beyond UEX. I believe that many of the challenges experienced between programmers and UEX practitioners are due to overspecialization of roles and hand-offs between people in those roles. Agilists have mostly abandoning the concept of building teams of specialists and instead favor teams of generalizing specialists. The implication is that although UEX practitioners bring a critical skillset to a development team, they still need to learn a wider range of skills to become truly effective. Furthermore, agile practitioners have tightened the feedback loop on software projects, and thereby reduced both risk and cost, by increased collaboration which in turn results in decreased hand-offs. Become embedded in ASD teams. By embedding UEX practitioners on agile teams, not only will this increase the chance UEX issues are addressed, it will help to promote UEX skills within the agile community because people pick up new skills from one another as they collaborate. Give ASD approaches a chance. Kent Beck suggested to Alan Cooper that a week be invested at the beginning of a project to explore interaction issues, although Cooper believed that wasnt sufficient. The easiest way to find out who is right is to actually try it in practice. Start looking beyond XP. Ive said it before and Ill say it again, there is more to ASD than XP. Agile methodologies are flexible, theyre not meant to be used out of the box but instead to be tailored to meet the exact situation which the project team finds itself in. To address UEX concerns you will very likely find that you need to tailor some of the principles and practices of Agile Modeling and/or the techniques of User-Centered Design into your base software process.
8. Potential Challenges It is very easy to suggest that agile practitioners take the time to learn UEX skills, and to adopt appropriate guidelines, but the reality is that these skills are competing for attention along with other equally important skills such as database design and modeling. To make matters worse, few developer-oriented books cover UI/usability issues, and the few that do such as my own The Object Primer rarely seem to devote more than a chapter to it. I fear that many agile practitioners arent even aware of the issue. Similarly, UEX practitioners receive mixed signals. Although Im calling for them to become generalizing specialists, the industry still rewards specialization UEX specialists are paid very well, and most organizations expect them to focus on doing that specific sort of work. Agile practitioners also suffer from this challenge: Why take an introductory UI design course when you can take a Java programming course which leads to certification and more pay? Its also easy to say that UEX professionals should be embedded into agile projects, but that only works when you have UEX professionals available. Few organizations have such people on staff, and worse yet believes that few organizations think in terms of interaction design as part of the requirements planning or project planning process. Therefore, many organizations may not see the need to hire anyone with these skills. The lack of UI design ownership means that everyone wants to be involved with UI design, regardless of their skill level, which can lead to design by committee. Although a common philosophy throughout the agile community is that agile practitioners should have the humility to know their limits, and the respect of others with the appropriate skills to address a specific issue, it doesnt always work out that way apparently agile practitioners are still only human. It is possible for UEX practitioners to make a valuable contribution on agile teams, and I suspect that there is a much greater chance of them succeeding as compared to working with traditional teams. Up until this point the UEX community has had little success in their attempts to become an active part of mainstream development teams, so it is time for a new approach. My suggestion is that UEX practitioners should work closely with the agile inmates to try to get the prison under reasonable control.
9. Acknowledgements I'd like to acknowledge the input from Paul Oldfield and Tim Tuxworth on the Agile Modeling list which helped me to evolve this article.
Agile Model Driven Development (AMDD) Agile Product Design (Jeff Patton's Site) Agile Testing and Quality Strategies: Discipline Over Rhetoric The Agile System Development Lifecycle (SDLC) Are Agile and Usability Methodologies Compatible? Best Practices for Agile/Lean Documentation Evidence that Agile Software Development Scales Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes. Extending FDD for UI Extreme Programming vs. Interaction Design Generalizing Specialists: Improving Your IT Career Skills Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Interaction Design Meets Agility: Practicing Usage Centered Design in an Agile Software Development Environment Prioritized Requirements: An Agile Best Practice
Process Agility and Software Usability: Toward Lightweight Usage-Centered Design Roles on Agile Teams: From Small to Large Usability Testing for Agile Development. Blog posting by Jonathon Boutelle. Ambler, S. W. (2003). Agile Database Techniques: Effective Strategies for the Agile Software Developer. New York: Wiley. Astels D. (2003). Test Driven Development: A Practical Guide. Upper Saddle River, NJ: Prentice Hall. Beck, K. (2005). Extreme Programming ExplainedEmbrace Change. Reading, MA: Addison Wesley Longman. Beck, K. (2003). Test Driven Development: By Example. Boston: Addison-Wesley. Constantine, L. L., and Lockwood, L. A. D. (1999). Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. New York: ACM Press. Cooper, A. (2004). The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis: SAMS Publishing. Eckstein, J. (2004). Agile Software Development in the Large: Diving into the Deep. New York: Dorset House Publishing. Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Menlo Park, CA: AddisonWesley Longman. Jokela, T. and Abrahamsson, P. (2004). Usability Assessment of an Extreme Programming Project: Close Co-operation with the Customer Does Not Equal Good Usability. Product Focused Software Process Improvement: 5th International Conference, PROFES 2004 Proceedings, PP 393-407. Berlin: Springer-Verlag. Mugridge, R. and Cunningham, W. (2005). Fit for Developing Software : Framework for Integrated Tests. Boston: Addison-Wesley.
Comparing the Various Approaches to Modeling in Software Development Contrary to what the computer aided system engineering (CASE) proponents may tell you, there is a wide range of modeling approaches which you can take on a software development project, some of which involves software-based modeling tools but other which involve simpler tools such as paper or whiteboards. Agile modelers use the simplest tools for the job, and sometimes that's a whiteboard, sometimes that's a unit regression testing tool, and sometimes that's a complex modeling tool. This article, overviewed in Figure 1, compares the various approaches to modeling, mapping the four common modeling paradigms (MDA, Software Factories, AMDD, and Agile MDA) to these approaches, and estimates therate of adoption for each modeling approach. Figure 1. Comparing the various approaches to modeling.
Throughout this article I use the term CASE (computer aided system/software engineering) tool to indicate software-based modeling tools. CASE as a term has gone out of favor in recent years because the CASE tool vendors have realized that the term has far too many negative connotations for those of us who were around for the integrated CASE (I-CASE) debacle of the late 1980s. Many vendors prefer the term "modeling tool" over the term CASE because it doesn't have the negative connotation and because it has the side effect that many developers have been brainwashed to think that in order to "officially model" you need a software-based modeling tool. The fact, as I will show in this article, is that the vast majority of developers do in fact model but that they use simple/inclusive tools such as whiteboards and paper to do so.
Modeling Approaches Figure 1 compares the following approaches to modeling software-based systems:
1. No modeling. Basically, you're not doing any of the other things in this list. A serious problem in the 2.
IT industry is that too many people think that just because they aren't using a CASE tool that they're not modeling. Discussion. When you are discussing a problem, either in the problem domain or the solution domain, you're effectively modeling it in your head as you talk about it. The important thing is that you are thinking the issue through before you code the solution, therefore you're still modeling albeit in a very low fidelity manner. Sketching/Paper. I believe that the vast majority of visual modeling is done by hand using simple/inclusive tools such as whiteboards or paper (see Figure 1for some survey findings). Furthermore, I also believe that the real thinking is often done in such modeling sessions, and that drawing and CASE tools are simply used for documentation and detailing purposes. The sketching approach to modeling should be taken just as seriously as the blueprint form of
3.
4. 5. 6.
7. 8.
modeling, yet it always seems to get short shrift in the literature (it's fairly hard to find modeling books with hand-drawn sketches in them, even though the authors are usually willing to admit that they do a lot of sketching in their modeling practices). Test Driven Design (TDD). With a TDD approach you create a test then write enough production code to fulfill that test. In other words, the tests form your detailed design model (as executable specifications), arguably making TDD a modeling approach. Drawing Tools. Many people use drawing tools such as Visio, or perhaps even PowerPoint, to draw technical diagrams. For the most part these tools are used to draw pretty pictures, which can be important, for documentation and/or presentation purposes. Documentation CASE. CASE tools that can only be used for documentation purposes. These tools are often called front end CASE, logical CASE, platform independent CASE, or enterprise CASE. Although you can draw and capture information with documentation CASE tools, you cannot generate working software (or source code from which you could then create working software) from them. Generative CASE. CASE tools that are "close to the metal" and can both engineer and reverse engineer source code and/or working software. Integrated CASE. Simply put: documentation CASE + generative CASE.
The DDJ 2008 Modeling and Documentation survey explored how people approach modeling and documentation. Figure 2 summarizes the results of the question that looked into the primary approach to modeling, and regardless of development paradigm sketching was the most common approach to modeling (SBMT = Software Based Modeling Tool). Figure 2. Primary approaches to modeling.
Modeling Paradigms The right hand side of Figure 1 presents the following modeling paradigms:
1. Model Driven Architecture (MDA). The MDA is based on the idea that a system or component can
be modeled via two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). PIMs are further divided into Computation Independent Business Models (CIBMs) and Platform Independent Component Models (PICMs). As the name implies PIMs do not take technology-specific considerations into account, a concept that is equivalent to logical models in the structured methodologies and to essential models within usage-centered techniques. The CIBMs represent the business requirements and processes that the system or component supports and the PICMs are used to model the logical business components, also called domain components. PSMs bring technology issues into account and are effectively transformations of PIMs to reflect platformspecific considerations. Software Factories. Software factories is a paradigm for automating software development that integrates these advances to increase agility, productivity, and predictability across the software life cycle. A software factory schema is a graph of viewpoints used to separate concerns, relating work
2.
3.
4.
done at one level of abstraction, in one part of a system, or in one phase of the life cycle, to work done at other levels, or in other parts and phases, and about how the schema can be used to deliver guidance and to support its enactment through model transformation, constraint checking and other techniques. Agile Model Driven Development (AMDD). As the name implies, AMDD is the agile version of Model Driven Development (MDD). MDD is an approach to software development where extensive models are created before source code is written. The difference with AMDD is that instead of creating extensive models before writing source code you instead create agile models which are just barely good enough. With AMDD there is an initial envisioning/modeling activityduring iteration 0 where you do initial requirements modeling and initial architecture modeling. Then, during development cycles/iterations, you model storm on a just-in-time (JIT) basis. Agile MDA. With an agile approach to MDA you still have the PIM and PSM modeling efforts, but you also have inclusive modeling using simple tools to enable effective interaction with your project stakeholders. Furthermore, an agile approach enhances the MDA with a comprehensive testing effort.
It's interesting to see how well each modeling paradigm does when compared to the various modeling techniques. Traditional MDA and Software Factories are the most narrowly focused, requiring sophisticated tooling for them to work. From a modeling point of view they are very similar: first, the MDA is UML-based whereas the software factories approach employs smaller domain specific models (DSMs); second, the software factories approach seems closer to the metal than does the UML, likely a reflection of the practical nature of Microsoft compared to the far more theoretical nature of the OMG. AMDD is the most expressive of the four modeling paradigms, being applicable to every modeling approach except TDD (TDD was purposefully left out of scope for AMDD). Agile MDA also fairs well, which makes sense because it adopts the best of breed from the MDA, AMDD, and TDD.
Estimated Adoption Rates These adoption rates are my gut feel estimates, I don't know of any studies that have looked at the full range of modeling options.
Agile Best Practices for Data Warehouse (DW)/Business Intelligence (BI) Projects Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Best Practices Agile Requirements Change Management Best Practices for Agile/Lean Documentation Examining the MDA Executable Specifications: An Agile Best Practice Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Model a Bit Ahead Prioritized Requirements: An Agile Best Practice
Examining the "Big Requirements Up Front (BRUF) Approach" Traditional project teams take a (near) serial approach to development in which requirements are defined and documented early in the project, they may or may not be reviewed and accepted by the project stakeholders, and theyre provided to developers. Requirements creep, also known as scope creep, is contained through a change management process (or more accurately, a change prevention process). Traditional change management processes typically involve one or more people, often referred to as a change control board (CCB), to act as a gateway through which changes are evaluated and potentially accepted. The goal is usually to minimize, if not prevent, requirements creep so as to stay on budget and schedule. In this article I argue that BRUF leads to significant wastage, that an evolutionary approach to development is must less financially risky than
serial development, and that you should take an agile approach to requirements.
BRUF Leads to Significant Wastage The Chaos Report shares some interesting statistics pertaining to the effectiveness this sort of approach. The Chaos Report, looks at thousands of projects, big and small, around the world in various business domains. The Chaos Study reports that 15% of all projects fail to deliver at all, and that 51% are challenged (theyre severely late and/or over budget). However, the Standish Group has also looked at a subset of traditional teams which eventually delivered into production and asked the question, Of the functionality which was delivered, how much of it was actually used? The results are summarized in Figure 1: an astounding 45% of the functionality was never used, and a further 19% is rarely used. In other words, on these so-called successful projects there is significant wastage. Figure 1: The effectiveness of a serial approach to requirements.
This wastage occurs for several reasons:
1. The requirements change. The period between the time that the requirements are finalized to the
time that the system is actually deployed will often span months, if not years. During this timeframe changes will occur in the marketplace, legislation will change, and your organizations strategy will change. All of these changes in turn will motivate true changes to your requirements. Peoples understanding of the requirements change. More often than not what we identify as a changed requirement is really just an improved understanding of the actual requirement. People arent very good at predicting what they want. They are good at indicating what they sort of think that they might want, and then once they see what youve built then can then provide some feedback as to how to get it closer to what is actually needed. Its natural for people to change their minds, so you need an approach which easily enables this. People make up requirements. An unfortunate side effect of the traditional approach to development is that weve taught several generations of stakeholders that its going to be relatively painless to define requirements early, but relatively painful to change their minds later. In other words, theyre motivate to brainstorm requirements which they think that they just might need at some point, guaranteeing that a large percentage of the functionality that they specify really isnt needed in actual practice. You effectively put a cap on what you will deliver. Very often with a BRUF approach you in effect define the best that will be delivered by the team and then throughout the project you negotiate downwards from there as you begin to run out of resources or time.
2.
3.
4.
Why do organizations choose to work this way? Often, they want to identify the requirements early in the lifecycle so that they can put together what they believe to be an accurate budget and schedule. This ignores the fact that in the past that this hasnt worked out very well (51% of projects are arguably challenged) but I guess hope springs eternal. Yes, the more information that you have the better your budget and schedule can be, but software development is so dynamic that at best all we can do is define a very large range at the beginning of a project and narrow it down as the project progresses. Although such an estimates may be soothing to the people
desperately trying to manage the project, I personally wouldnt want to invest much effort in putting this estimate together, particularly when there are better alternatives. Many organizations tend to treat custom software as if they were purchasing it off the shelf -- they treat it as a one time purchase. The reality is that you're building a system which will be maintained and evolved for many years to come, it's really a product (involving many releases over time, often implemented as a series of "projects") that you need to manage, not a project. Therefore, a fixed set of requirements with a budget tied to meeting those requirements is an unrealistic way to work. Many organizations are convinced that software is very hard to change. This is true if it's difficult to redeploy newer versions of the software, but most organizations these days have automated their release process for the majority of their systems. The data community often convinces themselves that it's difficult to refactor databases, which is simply not true, or that they must negotiate a one data truth in order to proceed with development (also not true). Worse yet, some people naively think that developers do their work based on what is in the requirements document. If this was true, wouldnt it be common to see printed requirements documents open on every programmers desk, or displayed in a window on their screens? If you walk around your IT department one day I suspect youll only need one hand to keep track the number of people actually doing this. An interesting question that wasn't asked, to my knowledge, was how much required functionality wasn't delivered as the result of a BMUF approach. We have no measure, yet, of the opportunity cost of this approach. To recap, many organizations are motivated to comprehensively define requirements early in a project in order to put together an accurate estimate and schedule. Ignoring the fact that most projects are challenged, even when this approach is successful as Figure 1 shows roughly two thirds of your investment is a waste. Although this should be enough to motivate you to change your approach, it just gets worse.
Take an Evolutionary Approach to Development Assuming that you can live with two-thirds wastage, as the majority of organizations seem to do, a serial approach to development is still a poor way to work. Figure 2depicts the break even graph for a fictional project team taking a serial approach to development whereas Figure 3 shows the similar graph for a team taking an evolutionary approach. With an evolutionary approach you work iteratively and deliver incrementally. With an iterative approach, instead of trying to define all the requirements up front, then developing a design based on those requirements, then writing code, and so on you do a little modeling, then a little coding, then some more modeling, and so on. When you deliver incrementally you release the system a piece at a time. As you can see, the serial team developed the entire system over a 16 month period whereas the evolutionary team had an initial release after 8 months, then another 4 months later, then one more after another 4 months. Figure 2. Break even for a serial project.
Figure 3. Break even for an evolutionary project.
The serial teams break even point occurs 26 months after the start of the project, whereas the evolutionary teams achieves break even after 14 months. With the evolutionary approach you not only spend less money at first, you also start receiving the benefits of having working software in production earlier. Better yet, if you develop the highest priority requirements first (more on this in a minute), you gain a higher rate of return on your initial investment with the evolutionary approach. Furthermore, the evolutionary approach is less risky from a financial point of view. Not only does it pay off earlier, always a good thing, you can easily stop development if you realize that an interim release really does deliver the critical functionality that you actually need. So, to recap once again, a traditional approach to software develop result in roughly two-thirds wastage in delivered software. Worse yet, this approach produces a longer break even point than does an evolutionary approach, increasing the risk to your project. In short, although waterfalls are wonderful tourist attractions they are spectacularly poor ways to organize software development projects.
Consider an Agile Approach So what is the solution? First, as Figure 4 depicts you should take an agile approach to requirements elicitation where initial requirements areinitially envisioned at a very high level and then the details are explored via iteration modeling or via model storming on a just-in-time (JIT) basis. As Figure 5 indicates, for the first release of a system you need to take several days, with a maximum of two weeks for the vast majority of business systems, for initial requirements and architecture envisioning. The goal of the requirements envisioning is to identify the high-level requirements as well as the scope of the release (what you think the system should do). Model storming sessions are typically impromptu events, one project team member will ask another to model with them, typically lasting for five to ten minutes (its rare to model storm for more than thirty minutes). The people get together, gather around a shared modeling tool (e.g. the whiteboard), explore the issue until their satisfied that they understand it, then they continue on (often coding). Model storming is JIT modeling: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before. Extreme programmers (XPers) would call modeling storming sessions stand-up design sessions or customer Q&A sessions. Figure 4. The Agile Model Driven Development (AMDD) lifecycle for software projects.
Figure 5. The value of modeling.
This streamlined, JIT approach to requirements elicitation works for several reasons:
1. You can still meet your "project planning needs". By identifying the high-level requirements early
you have enough information to produce an initial cost estimate and schedule.
2. You minimize wastage. A JIT approach to modeling enables you to focus on just the aspects of the 3.
system that you're actually going to build. With a serial approach, you often model aspects of the system which nobody actually wants, as you learned earlier. You ask better questions. The longer you wait to model storm a requirement, the more knowledge you'll have regarding the domain and therefore you'll be able to ask more intelligent questions.
4. Stakeholders give better answers. Similarly, your stakeholders will have a better understanding of
the system that you're building because you'll have delivered working software on a regular basis and thereby provided them with concrete feedback. Because requirements change frequently you need a streamlined, flexible approach to requirements change management. Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first. Agilists strive to truly manage change, not to prevent it, enabling them to maximize stakeholder ROI. Figure 6 overviews the agile approach to requirements change management, reflecting both Extreme Programming (XP)s planning game and the Scrum methodology. Your software development team has a stack of prioritized and estimated requirements which needs to be implemented XPers will literally have a stack of user stories written on index cards. The team takes the highest priority requirements from the top of the stack which they believe they can implement within the current iteration. Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers. If you do this then any change to a requirement youre currently implementing should be treated as just another new requirement. Figure 6. An Agile Approach to Change Management.
New requirements, including defects identified as part of your user testing activities, are prioritized by your project stakeholders and added to the stack in the appropriate place. Your project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, stakeholders must also be responsible for making decisions and providing information in a timely manner. At first this strategy appears to be a radical approach to requirements management, but it has several interesting benefits:
1. Stakeholders are in control of the project scope. They can change the requirements at any point in 2. Stakeholders are in control of the project budget. They can fund the project for as long as they 3. 4.
want, to the extent that they want. When you reach the end of the budgeted funds, you either decide to continue funding the effort or you decide to put whatever you've got into production. Stakeholders are in control of the project schedule. See point #2. Wastage is minimized. Because the project is continually driven by the stakeholders' priorities, each increment provides the greatest possible gain in stakeholder value. Because stakeholders review each incremental delivery, progress is always visible and it's unlikely that the team will be sidetracked by unimportant issues or deliver something that doesn't meet stakeholder needs. In other words, developers maximize stakeholder return on investment. time, as they need to.
The only major impediment to this approach is cultural inertia. Many organizations have convinced themselves that they need to define the requirements up front, that they need comprehensive documentation before project teams can begin development. They often do this in the name of minimizing financial risk, they want to know what they're going to get for their money, and as a result incur incredible wastage and actually increase financial risk by delaying the break even point of their deployed system. Choosing to succeed is one of the hardest things that you'll ever do.
Evolutionary Approaches Produce Better Results The Dr. Dobb's Journal 2008 Project Success Survey found that both iterative and agile approaches to software development were more effective at delivering systems which implemented functionality that people actually wanted, as you can see in Figure 7. What's interesting is that they also result in greater quality, better return on investment (ROI), and greater ability to deliver systems in a timely manner. Furthermore, this isn't the only study that has found that agile approaches are more effective than traditional approaches. Figure 7. Success factors by paradigm (Scale is from -10 to +10).
Acknowledgements I'd like to thank Phil Doherty, Daniel Hoey, Huet Landry, and Scott Preece for their feedback regarding this article.
Active Stakeholder Participation Agile Analysis Agile and Iterative Development: A Manager's Guide. This book, written by Craig Larman, includes a very interesting chapter on the evidence for why traditional approaches don't seem to be that effective and why evolutionary approaches are. This is a great book in general, but the evidence chapter alone is well worth the money because it will really start to open your eyes.
Agile Requirements Agile Requirements Change Management Agile Testing and Quality Strategies: Discipline Over Rhetoric Best Practices for Agile/Lean Documentation Big Modeling Up Front (BMUF) Anti-Pattern The "Change Prevention" Anti-Pattern Detailed Requirements Specification: A Worst Practice? Document Late: An Agile Best Practice Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Is Agile Crossing the Chasm? IT Projects Sink or Swim. This paper by Andrew Taylor in the January 2000 issue of the British Computer Society's Computer Bulletin overviews a study of 1,027 IT projects cited scope management related to serial practices as the single largest contributing factor to project failure in 82% of the projects and was given a overall weighted failure influence of 25%. Overcoming Common Requirements Modeling Challenges Lean Software Development by Mary and Tom Poppendieck, describes how agile/lean techniques can minimize the wastage on software development projects. This book is a must read for anyone interested in SPI. The "Model a Bit Ahead" Pattern The "One Truth Above All Else" Anti-Pattern The Process of Database Refactoring Prioritized Requirements: An Agile Best Practice Rethinking How You View Requirements Management Rethinking the Role of Business Analysts The Risks With Traditional Approaches to Modeling The Unchangeable Rules of Software Change (Brad Appleton, Robert Cowham, and Steve Berczuk)
How Can Enterprise-Level Professionals Be Agile?
Many people mistakenly assume that enterprise-level activities, such as enterprise architecture or strategic reuse, need to be performed in a traditional and even bureaucratic manner. As I've shown with the Enterprise Unified Process (EUP), nothing could be further from the truth. The way that enterprise professionals organize themselves and work with their customers, which include both software development teams as well as business stakeholders, can be agile. My experience is that there are several strategies which enterprise professionals, such as enterprise architects or enterprise data administrators, can adopt to become more agile. Agile strategies for enterprise professionals include:
1. Collaborate, dont control. Agilists collaborate with others to achieve their goals. They inherently
know that communication is critical to their success and they do everything possible to break down any barriers to communication which may exist. They realize that the best use of their time is to actively work with others, that trying to control others from afar via defined procedures or decrees is a futile effort at best. Focus on delivering working software on a regular basis. Software development teams are an important customer of enterprise groups, and the primary goal of software development teams should be to develop software. If you are able to help them to this then you will be perceived as a valuable resource to work with, otherwise you will be perceived as an impediment to success and they will find ways to go around you. Yes, project teams are often narrowly focused on their own goals and are usually under tight time constraints, but that doesnt mean you cant help them to take enterprise concerns into account without impeding their progress. But its up to you to find a way to be an effective member of that team. Focus on working closely with business stakeholders. Active stakeholder participation is a critical success factor for any IT endeavor, be it a single development project, a program of projects, or some sort of enterprise modeling effort. It is easy to forget this, or to convince yourself that you know best and therefore can take on the role of stakeholder, or to give up when your stakeholders claim that theyre too busy to be actively involved. The risk of building something which doesnt meet the true needs of the business far outweigh the cost of obtaining active stakeholder participation.
2.
3.
4. Embrace change, dont fight it. Change truly new requirements, an improved understanding of
existing requirements, or new/improved technologies is a cold, hard reality that we all face. Agilists accept that change happens and find ways to become efficient at responding to change. This can be very difficult at first, particularly because it involves the adoption of a new mindset and new ways of working. In the end, isnt it better to follow an agile approach which reflects your environment rather than a traditional approach which doesnt, even though you may not yet be comfortable or familiar with this new approach? Be customer oriented. A primary goal of enterprise architects should be to support and hopefully guide both software development teams and even the business. To do this effectively enterprise architects must be customer-oriented and that implies that they must find ways to work in a manner which reflects their customer base. It is important to recognize that a business modeling team will very likely work in a different manner than a team of seven developers taking anExtreme Programming (XP) approach who in turn will take a different approach than a forty-person Feature Driven Development (FDD) project team. Therefore, customer-oriented enterprise architects will find ways to work with each of these groups in a manner which reflects their unique situation. The implication is that an enterprise group must be flexible and prepared to work in ways which may not be ideal for them. Share your skills. An important agile philosophy from the EUP is that enterprise professionals should be responsible for sharing their skills with others. Figure 1depicts how creation and support of development guidance, training of people in enterprise architectural concepts and the architecture itself, and mentoring people in those topics is an important aspect of the overall enterprise architecture discipline. Creating development standards and enterprise architectural models is important, but it's unlikely that they'll be followed without direct support from the people responsible for them.
5.
6.
Figure 1. Enterprise architects should support development teams.
7. Adopt a governance approach based on collaboration and enablement.

Traditional governance approaches often take a command-and-control approach, which is exactly opposite of the way you should work with intellectual workers. A better strategy is to adopt a lean development governance approach strategy based on close collaboration and enablement which reflects the way that intellectual workers behave in practice.
8. Focus on value. Agilists are constantly asking the question what is the value of 9. Constantly ask if theres a better way. Agilists will also ask themselves if there
is a better way to achieve the same sorts of goals. For example, the fundamental goal of holding a review is to ensure that several people have examined an artifact to ensure that it meets the needs for which it was created and that it was of sufficient quality. There are more effective ways to achieve the same goal: the adoption of practices such as collective ownership, pair programming, and modeling with others ensures that several people will work with the code or models respectively. The point is that you need to question your assumptions, many traditionalists will assume that you need to do reviews because you cant trust the work of development teams whereas the real problem is that people on the teams worked in relative seclusion from one another and therefore were in a position to create poor quality work that wouldnt be detected without a review. A side effect these practices is that reviews are effectively held in parallel. Context counts reviews are best practices on traditional projects that dont promote collaborative work, but they often prove to be ineffective practices on agile projects which take a highly collaborative approach. doing something, and if there isnt value then they rethink their approach.
10. Optimize the whole, not the parts. Many enterprise-level efforts fail when they
attempt to sub-optimize one or more disciplines, such asoperational database administration or human resource management, instead of optimizing the whole IT lifecycle. The end result is that although your data management processes may be effective on their own, when taken into the overall context of the rest of IT they're not only out of synch with everything else but they're actually hampering your organization's ability to be effective. Optimizing the whole is one of the lean principles. I hope that you have noticed that my first four strategies are basically rewordings of the four values of the Agile Alliance (AA). The AA has some pretty good advice to share with you, I highly suggest visiting this site on a regular basis.
Agile Enterprise Architecture Agile Enterprise Administration The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments Agile Strategies for Enterprise Architecture (in Enterprise Architecture Trends 2007, Cutter Consortium) EUP Discipline: Enterprise Business Modeling EUP Discipline: Portfolio Management EUP Discipline: Enterprise Architecture EUP Discipline: Strategic Reuse EUP Discipline: Software Process Improvement Imperfectly Agile: You Too Can Be Agile Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning Practical Guide to Enterprise Architecture
Interviewing Tips and Techniques for IT Professionals Interviewing is an important technique for eliciting requirements from your stakeholders. When interviewing stakeholders you have several potential goals to accomplish:
You might want to broaden your understanding of the domain You might want to determine who to invite to modeling sessions and/or be active members of your
team
You might want to directly identify new or existing requirements for your application.
Interviewing is a skill that takes years to master, one that cannot possibly be taught in a few paragraphs. However, here are a few helpful pointers to help you to improve your interviewing skills:
1. 2. 3. 4.
Send ahead an agenda so as to set expectations and allow your interviewee to prepare for the interview. Verify a few hours ahead of time that the interview is still on because peoples schedules can change. When you first meet the person, thank them for taking time out of their busy day. Tell the interviewee what the project is about and how they fit into the overall process. This lets them know that their input is important. 5. Summarize the issues that you want to discuss, and verify how long the interview will go. This helps to set their expectations and they will help you to manage the time taken during the interview. 6. Ask the critical questions as soon as possible, that way if the interview is cut short you have gotten the important information. 7. Ask them if you have missed anything, or if theyd like to add something. This gives them a chance to voice their concerns and will often open new avenues of questioning. 8. Do not assume that you know everything, especially if you think you have already heard it before. Your users will rarely have a consistent view of the world, and part of the requirements definition process is to understand where everyone is coming from. If everyone has the same view on everything thats great, but its incredibly rare so do not shut down your users with a comment like Ive already heard this before 9. End the interview by summarizing the main points. This gives you a chance to review your notes and ensure that you understood everything. 10. Thank the person again at the end of the interview. 11. Inform the interviewee when you will summarize the interview notes (hopefully immediately after the interview when its still fresh in your mind) and tell them that you will send them a copy for their review. This helps to put them at ease because they know that their input wasnt taken out of context and it also helps to improve the quality of your notes because they review them and give you feedback. 12. Remember, theres more to interviewing people than just talking to them -- you also need to listen. 13. Interviewing is just one of several requirements elicitation techniques. The best place to get training in interviewing is at journalism school. Because interviewing is recognized as a key skill needed by journalists, journalism schools tend to have top-notch interviewing courses. Although interviewing is also a key skill needed by computer professionals, very few computer science programs teach it.
Agile Analysis Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Best Practices Agile Requirements Change Management Agile Requirements Modeling Agile Testing Strategies Best Practices for Agile/Lean Documentation The "Change Prevention" Anti-Pattern Examining the "Big Requirements Up Front (BRUF)" Approach Inclusive Modeling Model a Bit Ahead Prioritized Requirements: An Agile Best Practice
Rethinking Business Analysts Agile Best Practice: Model A Bit Ahead
Sometimes you find yourself in a situation where you can't easily model storm a requirement or design issue for a few minutes on a just-in-time (JIT) basis. Perhaps your stakeholder(s) aren't available 100% of the time, perhaps they don't fully understand a difficult issue, or perhaps you are so tight for time that you don't mind potentially wasting money on over modeling for the sake of shaving a week or two off your schedule. In these situations you may decide to have someone "model a bit ahead" of the developers on your team, gathering information, exploring requirements, and thinking through the detailed design before you actually implement the software. This modeling is done in parallel to the development effort, often a few days or weeks before the information is actually needed. Motivation There are several reasons why you might want to model ahead:
1. Stakeholders are only available at certain times. I once worked on a project where the business
stakeholders were available for one-to-three days per month and specific individuals had to be scheduled two months in advance. During these modeling sessions we would first address any domain questions which we had identified since the last modeling session, then we started exploring new concepts which we believed we would run into during the coming iteration. Scheduling challenges forced us to model ahead. Stakeholder time is valuable. You may want to prepare for modeling sessions with these stakeholders so as not to waste their time by not understanding the fundamentals of what they're talking about. Your goal would be to understand their area of expertise and therefore be able to ask more intelligent questions. Unfortunately, you risk coming to the table with preconceived notions or having a firmer understanding of the issue because the stakeholder hasn't yet done the requisite thinking, so be careful. Sometimes a requirement or technical solution is very difficult. One of my clients implements very difficult financial business rules, and some of these rules are so complex that the expert(s) need to work through them first before trying to explain them to the developers. The stakeholders know what theyre talking about, many of them have PhDs in the subject matter, and the developers have a solid understanding of the domain as well; even so, it is still more efficient for the stakeholders to first work through the logic of the business rule with a modeler before they discuss it to the developers. The stakeholders are still available to work with the developers to answer their questions on a JIT basis, but they first work with the modeler for several hours to coalesce their ideas. Another example is that in some large organizations it takes time to come to some sort of agreement regarding the nature of their source data (my advice: you need just good enoughdata for your situation, not a perfect "one truth"). You need to integrate with a poorly documented legacy asset. Legacy analysis is often a difficult and time consuming effort. If your architecture indicates that you need to interact with such an asset, and the requirement to do so is fast approaching, you should consider doing this analysis just before you need the information. Usability issues need to be considered. Many user-centered design techniques, such as doing user research, require up-front work, even on agile teams. Sometimes you require specific resources such as usability labs, or access to specific people, both of which must be scheduled in advance. In other words, you may need to do usability modeling a bit ahead of the actual development of the UI aspects of your system. You can speed up development. Some project teams like to quicken the pace of development cycles by getting a head start by modeling upcoming requirements. During iteration N they model various aspects of iteration N+1, increasing their understanding of what needs to be built and thereby enabling them to more accurately identify the work to be done. By parallelizing development activities like this they decrease their overall schedule. Furthermore, when the customers/product owner come prepared to the iteration planning/modeling effort at the beginning of an iteration you can reduce the time required for this activity substantially, leaving more time in the iteration for development activities. There are differing stakeholder opinions. Most projects have a wide range of stakeholders, and one result is that they often don't agree. So, it is common to model a bit ahead in these situations, at least an iteration ahead, so that the team doesn't have to wait for the stakeholders to come to agreement.
2.
3.
4.
5.
6.
7.
Figure 1. The AMDD lifecycle: Modeling activities throughout the lifecycle of a project.
Solution As Figure 2 indicates, agilists work treat requirements (and other types of work item for that matter) as if they existed on a prioritized stack which changes to reflect the current needs of the stakeholders. With agile modeling a bit ahead your team does just enough modeling to understand a requirement which has been assigned to some point in the near future, such as an upcoming iteration or even just later in the current iteration. This modeling will potentially go down to the design level, although you will rarely need this level of detail (remember, you should still only model just barely enough to meet your exact needs). Most commonly, you look ahead to the next iteration to explore upcoming requirements. To remain agile you want to model just the complicated requirements of the coming iteration, not every single one. In other words, apply thisprocess pattern sparingly. Figure 2. Agile requirements change management process.
Some teams will choose to employ a business analyst (BA) who models a bit ahead of the rest of the team, gathering the domain information before the team needs it. The primary danger with this approach, of course, is that the BA will filter the information (often inadvertently) which is presented to the team. This person may even act as the primary customer to your team, or product owner, representing your project stakeholders to your team while working with them behind the scenes to gather the requisite information. A BA is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.
Remember, BA is also the abbreviation for band-aid
Consequences On the one hand, with model a bit ahead you clearly run the risk of modeling something you eventually dont need to build: your stakeholders might decide to drop or radically change a requirement between the time you model it and the time you go to implement it. In short, the further ahead that you model, the greater the chance of falling victim to the problems surrounding big modeling up front (BMUF). Furthermore, you risk forgetting the information the greater the period between modeling it and implementing it, motivating you to write more documentation and thereby slow down your overall effort. On the other hand, modeling a bit ahead provides the opportunity to streamline development efforts during the coming iteration by ensuring you have the detailed understanding that you need to build the software effectively. In some ways this is the equivalent of recognizing that the road that you're traveling has a few potholes coming soon and sending someone ahead of your team to fill in the potholes so that the rest of the team doesn't get into trouble when they hit them. The software development game is a series of trade-offs, and you need to make the right ones for your situation. Some agile developers will tell you that modeling ahead is heresy, but frankly Im more interested in strategies which work in practice than with conforming to religious dogma. There is a big difference between agile modeling ahead and taking a BMUF approach. With BMUF you attempt to do all of the modeling early in the project and then recording the results via comprehensive documentation. Yes, you definitely want to avoid the disadvantages of BMUF, which include an inflexible approach to development that often results in significant
wastage, over-investment in documentation, and lower productivity due to over-specialization of IT professionals (if you hire good modeling specialists, theyll create a lot of good models whether you need them or not).
Acknowledgements I'd like to thank Paul Oldfield for his feedback regarding this article.
Agile Model Driven Development (AMDD) Agile Modeling Best Practices Agile Requirements Change Management The Agile System Development Lifecycle (SDLC) Examining the Big Requirements Up Front (BRUF) Approach Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes (Paul Hodgetts) The "Flexible Features Split" Pattern Iteration Modeling "Just Barely Good Enough" Models and Documents? The "One Truth Above All Else" Anti-Pattern Prioritized Requirements: An Agile Best Practice
Rethinking the Role of Business Analysts Overcoming Requirements Modeling Challenges

To be agile at requirements modeling you need to be in a situation where it is possible to succeed, and for many project teams this unfortunately is not the case. Very often requirements modeling efforts are undermined by your environment it is common to discover that an organizations culture isnt conducive to effective software development efforts or project stakeholders do not understand the implications of their decisions. In this article I identify common challenges, or at least issues which are perceived as challenges, that many development teams face when it comes to requirements modeling and discuss potential solutions for dealing with those challenges. These common challenges are:
1. Limited access to project stakeholders 2. Geographically dispersed project stakeholders 3. Project stakeholders do not know what they want 4. Project stakeholders change their minds 5. Conflicting priorities 6. Too many project stakeholders want to participate 7. Project stakeholders prescribe technology solutions 8. Project stakeholders are unable to see beyond the current situation 9. Project stakeholders are afraid to be pinned down 10. Project stakeholders dont understand modeling artifacts 11. Developers dont understand the problem domain 12. Project stakeholders are overly focused on one type of requirement 13. Project stakeholders require significant formality regarding requirements 14. Developers don't understand the requirements
Challenge #1. Limited or No Access to Project Stakeholders This happens time and again for some reason senior management is willing to invest in the development of a system, sometimes spending millions of dollars on it, but is unwilling or unable to provide you with the right people to tell you what the system needs to do. This is often the result of a serious lack of understanding of how software is developed, that developers need active support of project stakeholders to be successful, or because theyve always worked this way and simply dont know any better. The first step to address this problem is to communicate to your project stakeholders that you need to work with them closely, that they must invest some of their valuable time to work with you. In some situations there isnt an identifiable user of the system yet, this is often the case when you a developing a shrink-wrapped product for sale or a new web-based system for use by your (potential) customers, and therefore a surrogate user should be identified. Good candidates for surrogate users are marketing and sales staff that are familiar with your customer base, the person(s) who had the initial vision for your system, or the potential customers themselves (you may need to work with your existing client base to discover what they want of a new system or simply hire people off the street that fit the identified customer profile for your product). My experience is that you can always find someone to provide requirements for your system, and Ive been in many situations where people were convinced they couldnt possibly find someone to work with. Remember that your project stakeholders include more than just direct users of your system, although also recognize that you are going at risk if you do not include some direct users in your software development efforts. For more details, read Techniques for Eliciting Requirements for a range of options that you can apply, not all of them depend on constant access to stakeholders. Also, you might want to consider applying the "Model a Bit Ahead" pattern.
Challenge #2. Project Stakeholders Are Geographically Dispersed An issue related to having limited or no access to project stakeholders, and often a reason why your access is limited, is because some or all of your project stakeholders are at another location(s) than the development team. This is a common problem for projects within large organizations, projects that have been outsourced to an external organization, or projects performed by a consortium of organizations. There are several ways to address this situation. First, attempt to co-locate the developers and project stakeholders that can actively participate with the team as I discuss in the communication article the best way to communicate is face-to-face at a POW. If that fails your next best strategy is to have your project stakeholders on site with your developers on a part-time basis and available via other means the rest of the time (in my communication article I discussed alternatives means of communication such as email, videoconferencing, and the use of collaborative modeling tools). I was once involved with a 300 person project where some of our project stakeholders were on the floor actively working with the developers one week out of every three and available via phone and email the other two weeks and that worked reasonably well. The next best solution is to fly the developers to the project stakeholders and have them work with the stakeholders there. Ive tried this on several projects, successfully, although have noticed that this is very tough on the people who end up doing the traveling (usually me, but luckily I like to travel). Another alternative is to place business analysts, people responsible for working with project stakeholders to understand their needs, at the disparate locations and have them work with the development team to define the requirements. Of course you can combine these techniques as needed.
Challenge #3. Project Stakeholders Don't Know What They Want This issue should motivate you to spend some time modeling, exploring with your project stakeholders what their needs are and what is important to them. The business world is complex, project stakeholders will very often sense that there is a problem or opportunity that should be addressed but they dont know how. This is completely and utterly normal. Have you ever redecorated a living room, or simply re-arranged furniture? You know that you want a better living space, but you often dont what you want. Perhaps you look in some magazines at pictures of other living rooms, you visit furniture stores, or simply look at how your friends have organized their homes. If youve had difficulties defining a vision for a living room, imagine how difficult it must be for your project stakeholders to identify what they want a system to do. Start by accepting that this situation as the norm. Tell your users that if they cant tell you exactly what they want that its okay, all they need to do is tell you what they want you to work on right now. Staying with the redecorating analogy, perhaps you dont have a vision for the entire living room yet but you could start by
focusing on installing book shelves. Focus on the aspects of the system that they have the best vision, model that small portion, and implement a working system (along the lines of the practice Prove it With Code) that they can work with and provide you feedback about. If they arent able to identify requirements for even a small part of they system, you may not even be sure that you want books in your living room at all, then start by exploring how they currently work. By modeling existing work processes you will gain a better understanding of what they do and what their potential needs may be and worst case can suggest some potential requirements to them.
Challenge #4. Project Stakeholders Change Their Minds Project stakeholders are people, yes they really are despite your darkest suspicions, and people change their minds. Ever arranged furniture in your living room into a configuration that you just knew was going to work, but when you stepped back to look at it you realized it wasnt what you wanted? If youve done that with something as simple as furniture arrangement what are the chances that your stakeholders will change their minds about something as complicated as the system you are building for them? One hundred percent. The first step to addressing this issue is to accept reality and follow AMs principle of Embrace Change. The next step is to explore whatever is changing, thats what modeling is all about, because you will often find that either they didnt know what they wanted in the first place (see above) or perhaps you didnt understand what they were asking for. As you are working with your stakeholders you want to build an understanding of their perspective and their terminology, to both ensure that you do not have differing assumptions and to improve the quality of communication between you. I was involved with the development of an administration system for an e-commerce system, for which we had fairly specific requirements. The first week we put up two web pages, one that presented a home page containing menu items of critical functionality and another that enabled administrators to perform a high-priority function. We built exactly what our stakeholders asked for and when we showed it to them they realized that what they originally wanted wasnt going to work well and had us refactor it. Change happens. Finally, when you are exploring an area of your system that your users have changed their minds about you may discover that the real problem is that your stakeholders simply dont understand the problem they are trying to address, an indication that you need to hold some sort of visioning session with them, or individual project stakeholders have different visions that are not being properly managed. Your best bet is to adopt an agile change management approach, not a traditional change prevention approach.
Challenge #5. Conflicting Project Stakeholder Priorities The system that you are building must reflect the needs of several constituencies, including direct users, senior management, your operations and support staff, and your maintenance developers. Each of these groups have different priorities and goals, as do individuals within these groups. There will be conflicts, conflicts that must be addressed. Once again, the first step it to accept the situation. Somebody is going to have to negotiate to identify what the priorities for your system will be. Note what I just said you need to identify the priorities for your SYSTEM. Each project stakeholder has their own priorities, and thats fine, but your goal it to settle on priorities for the system and that will often be different than those of individuals. One approach is to simply identify someone(s) who can represent the larger group of project stakeholders and let them work this out. You may also decide to lead the negotiation efforts yourself, but this can be time consuming and could result in ill-will towards you and your project team my advice it to let someone else do your dirty work if possible. If the negotiation efforts fail then your last resort should be to call in the gold owner, the person paying for your project, and ask them to arbitrate a solution. I once worked on an e-commerce system that was to be deployed internationally. Some of my stakeholders wanted to support several languages American English, British English, Spanish, German, Japanese, and Cantonese at first so we could serve each major market uniquely. Other stakeholders wanted to get our system up and running quickly and wanted to deploy it in American English only because they felt that this would be acceptable to our customers (okay, sometimes your project stakeholders are clueless). We couldnt come to an agreement on this issue so I had the issue pushed up the management chain and the decision was to support American English only for the first release and then evaluate the need to support other languages when it proved necessary (which it quickly did).
Challenge #6. Too Many Project Stakeholders Want to Participate Sometimes you discover that you have too many people offering to work with your project team. This is often the case at the beginning of a project when excitement about it is too high or your project is a political winner that people want to be associated with. The best solution is to thank everyone for their enthusiasm, to make them aware that you have more help than you currently need, that you have selected a portion of them to work with you, and that you will call on them in the future if you need their help. Whenever Im in this situation Ill try to pick the best people for the job, looking for project stakeholders that are likely to provide the best insight and who are willing to invest the time to work with my team. I will also ensure that I do not alienate the people that dont immediately work with my team, we may want to work with them in the future to provide specific expertise or simple to act as a sounding board for what were doing often the project stakeholders who are actively participating with a project team will become too familiar with the system and loose perspective and be unable to identify potential problems, thus it is valuable to have access to a qualified outsider.
Challenge #7. Project Stakeholders Prescribe Technology Solutions Ive been in situations where a project stakeholder has said that we need to use a specific technology, such as "Oracle vX.Y.Z" to solve a problem when what I really needed from them was behavioral requirements such as Customers need to be able to deposit money into an account". Yes, there are always technical constraints that your team needs to be aware of, perhaps what your stakeholder was really trying to communicate was the fact that Oracle is your organizations corporate database standard. Often times the real issue is that your stakeholders are having difficulty differentiating between requirements for a system and architectural alternatives for a system, perhaps the person is technically oriented and hence likes to focus on technical issues, or perhaps its something as simple as them having just read an article in the most recent issue of Business Week that described a successful project using Oracle databases. The best approach to dealing with this issue is to define the rights and responsibilities of project stakeholders to help put a framework in place which enables you to focus their efforts on defining what the system will do and the developers efforts on how the system will do it. Another tack would be to ask the stakeholder if you had that technology in place, what would it do for you thats important or how would you use this technology in an effort to identify the actual requirements.
Challenge #8. Stakeholders are Unable to See Beyond the Current Situation In many organizations people have been doing their jobs the same way using the same tools for years they may not have ever seen another way to do things nor have they thought it could be different. They may also be scared of change, perhaps theyre afraid they wont have the skills required to work with the new system or they will be replaced by it, and are motivated to formulate requirements in terms of what they are comfortable with. The best approach is to talk about the current situation with them, to identify what works well and what doesnt, and to explore how the current situation came about. For example, youre working on the SWA Online system and are identifying requirements when one of your project stakeholders tells you that customers can only order ten things on any given order? What? Appears thats the way that its always been done in this company and thats the way it has to be in the new system. What? Needless to say you decide to question her about this and soon discover that the current system is based on a process where customer service representatives input orders that come in via mail and fax, and the order forms only have ten lines on the page and knowing this the builders of the original green-screen system built screens that only allowed ten order items. You point out to her the true reason for only supporting ten order items, lack of room on the paper form, and show explain to her that you can easily build a system that allows more than ten items. After awhile she realizes that its possible to do so, particularly when you visit the web sites of your competitors and see that they dont have this preset limit.
Challenge #9. Project Stakeholders Are Afraid to Be Pinned Down Project stakeholders will sometimes give vague requirements because they dont want to commit to a specific answer. The problem is that theyre afraid to be wrong their previous experiences with serial approaches has
taught them that its too expensive to reimplement a changed requirement and therefore you have to get them correct up front. They very likely sense the impossibility of doing so and therefore choose not to commit. To address this problem impress on your project stakeholders that you are ready to embrace change, that you are taking an iterative and incremental approach that reduces the cost of change, and that your goal is to identify and implement the best solution for them which means that some requirements will evolve over time. Then do exactly as you say, be receptive and supportive of change over time your stakeholders will learn that they can make a decision today and safely change it tomorrow if needed. When you deliver working software each iteration, software that your stakeholders see evolves as their understanding of the system evolves, their fear of committing will quickly dissipate.
Challenge #10. Project Stakeholders Dont Understand the Artifacts Youre Creating The vast majority of project stakeholders, and I suspect the vast majority of developers, have not received a formal education in modeling. It is very likely that they dont know how to read a UML activity diagram, or a data model, or a UML use case diagram because thats not a skill that is required of their day-to-day job. The problem is that they need to understand the artifacts that you are working with in order to understand what it is that you are trying to communicate to them and to become active members of your modeling efforts. Your first step is identify artifacts that your project stakeholders will need to understand so you know which ones to focus on. This is where the practice Use The Simplest Tools helps you if you strive to model with simple tools such as index cards, paper, and POWs you reduce the learning curve for your stakeholders. The second step is to teach these techniques to your stakeholders, I prefer a just in time (JIT) approach where I do a brief tutorial during a modeling session on the proper application of a technique when we first need it and then dive right into applying the technique at that point (Im also a firm believer in hands-on experience). Ive also given brief tutorials that overview common modeling techniques at the beginning of a project to give stakeholders a feel for what theyll be doing and provided them with reading material, typically The Object Primer 3/e: AMDD With UML 2, that describes the techniques in detail. Following the JIT approach to training Ive taught techniques such as CRC modeling and essential UI prototyping, both of which use simple tools, in less than fifteen minutes each to project stakeholders that had never modeled before. Ive taught more complex techniques, such as flowcharting or class modeling, to stakeholders over a period of time so as to build up the techniques slowly. The third step is to build working software based on their models, providing concrete feedback as quickly as possible. When you do this the models are no longer abstract, your project stakeholders readily see that their essential UI prototype created from flip chart paper and Post It notes has become a functional HTML page and that theirCRC card describing the concept of a customer has been reflected in the functionality of the software.
Challenge #11. Project Stakeholders Are Overly Focused on One Type of Requirement Sometimes you will find that your project stakeholders are providing you with great usage requirements, perhaps in the form of use cases or usage scenarios, but are falling short when it comes to non-behavioral requirements (or vice versa). This is a very good indication that you arent working with the right people, perhaps youre missing someone that represents a major constituency such as your operations and support staff, and therefore need to reconsider the mix of project stakeholders that youre working with to model requirements.
Challenge #12. Developers Dont Understand the Problem Domain A common problem at the beginning of a project is that the developers dont understand the problem domain, making it difficult to communicate with your project stakeholders. This is understandable, just like it isnt part of the day-to-day job of a stakeholder to understand modeling it isnt part of the day-to-day job of a developer to be an expert at jobs of their stakeholders. This is why both groups of people need to actively participate in requirements modeling, they both have something of value to offer to the overall effort because everyone can learn from everyone else. Overtime, by modeling with others and pair programming, developers will becomegeneralizing specialists with an understanding of both software development and the problem domain. Developers need to invest the time to learn the domain, theyll eventually learn it as the project progresses but will often find that this isnt quick enough and therefore must do something to enhance the learning experience.
Years ago I worked for a company that truly understood the importance of developers understanding their business. The first three days that I worked for the company myself and another new hire sat through training sessions presented by Vice Presidents, this was a multi-billion dollar financial institution, who described the fundamentals of what their divisions did. One Vice President trained two, yes two, developers for several hours in each session. If your organization isnt this enlightened then Ive found that simply picking up a book that overviews the domain, introductory college text books are ideal, are a great starting point to learn the fundamentals. Im also a firm believer that developers should read widely. I read The Economist and National Geographic on a regular basis in addition to publications such as Software Development, The Communications of the ACM, and IEEE Software. By reading widely I have a broad knowledgebase from which to work when I get into a new situation.
Challenge #13. Project Stakeholders Require Significant Formality Regarding Requirements Many stakeholders perceive formality scheduled meetings, official requirements documents that they review and sign off on, and formal presentations as inherent to professionalism. In my experience this expectation is often the result of the serial software process mindset that our industry has had for the past two generations, our stakeholders often dont know that there is another way to work. It is also the result of the bad relationship that the IT community has with the business community our project stakeholders dont trust us to deliver and insist on greater formality in the belief that it gives them greater control over the development process which they often dont understand. To address this issue you need to communicate that there is another way of operating, a more agile way, and communicate the inherent downsides (slower development, less chance of understanding the requirements, greater cost, ...) of their current approach. Ask your stakeholders what their real goals are. Is it to develop a working system or is it to have meetings and produce documentation? If it's the first goal, which it should be, then ask them why they insist on this formality. Dont accept their initial answer and keep digging until youre at the root cause. As I indicate in Agile Documentation chances are very good that they don't trust you and this is their way of holding your feet to the fire. The next step is to ask them to trust you, which is often difficult for them depending on how bad their previous software development experiences have been, and to remove some of the formality. Then deliver working software, showing them that it is possible to be successful without being burdened by too much formality. Iterate through cycles of reducing the formality and then delivering working software until you read a point where you can work effectively.
Challenge #14. Developers Don't Understand the Requirements A common complaint on non-AM projects is that the requirements artifacts that are being created by the business analysts with their users aren't understandable by the developers expected to implement those requirements. Luckily, this is a problem that you should not have on an AM project. First, your should know your models and know your tools, implying that developers should have sufficient training and experience with the artifacts being generated and the tools used to do so. If they don't then they must be given sufficient training and mentoring, removing the problem of simply being unfamiliar with the techniques. Second, the principle Incremental Changeadvises that you work on your system in small chunks, building it up over time, a philosophy that is reflected in the practice Model in Small Increments. This avoids the problem of developers being swamped by a large requirements document that defines too many requirements to comprehend all at once. Third, the practice Active Stakeholder Participation ensures that your project stakeholders are available to explain their requirements to developers and that developers are open to doing so. Fourth, the practices Create Simple Content and Depict Models Simply ensure that your requirements models are as understandable as possible.
Active Stakeholder Participation Agile Analysis Agile Requirements Best Practices Agile Requirements Change Management Agile Requirements Modeling
Best Practices for Agile/Lean Documentation The "Change Prevention" Anti-Pattern Document Late: An Agile Best Practice Examining the "Big Requirements Up Front (BRUF)" Approach Initial High-Level Architectural Envisioning Initial High-Level Requirements Envisioning The "Model a Bit Ahead" Pattern Overcoming Common Requirements Modeling Challenges Rethinking How You View Requirements Management Rethinking the Role of Business Analysts
Why Extend the UML Beyond Object and Component Technology? For years I've written that the UML isn't complete, at least from the point of view of business application development, and that we therefore need to extend it. In fact, I believe that I was the first one in the IT industry to argue this: I can't remember which was physically published first, but both the first edition of Building Object Applications That Work and an article I wrote reviewing the initial release of the UML published in Object Magazine (the first such UML article they published) came out within a few months of each other. Both the book and the article pointed out the need to include fairly obvious things such as user interface, business process/workflow, and data modeling to the UML so that we could actually model a business application. Since then I've expanded on this idea in several publications, but what I've never really done is written, at least in one place, about why extending the UML beyond object and component technology is so important to the IT industry. Until now. By extending the UML, we would:
1. Support the full range of business application development. There's more to business application
development than object/component technology. There are user interfaces on the front end and databases on the back end. We're now taking a service-oriented architecture (SOA) approach with web services, transaction processing (TP) technologies (e.g. CICS), and even stored procedures that are used to wrap database access. Call me old fashioned, but I think it's a good idea to model the UI, the database, and services (not to mention a myriad of other aspects) when it makes sense to do so. Make it a truly unified language. The word "unified" is wonderful marketing rhetoric describing the consolidation of major object-oriented (OO) modeling languages in the mid-1990s. This is a great start, but to have a truly unified modeling language I believe that it should address the other important aspects of development too. Break down communication barriers. A common language, with a common notation and semantics, promotes communication between people. We've seen this work within the object community, now it's time to do so within the IT community as a whole. Break down cultural barriers. By having a common, comprehensive modeling language IT professionals will come to understand the issues that other specialists have to deal with. More importantly, they may even realize that being a specialist reduces their overall effectiveness and that they should instead strive to become a generalizing specialist. Provide direction to developers. Many developers, if they choose to take a formal approach to modeling at all, will focus on UML-based techniques (often class diagrams, sequence diagrams, and use case diagrams from what an informal poll has shown) but not other techniques. I suspect that this is in part due to the effective marketing of the UML tool vendors, in part due to OO books which only cover UML-based techniques, and in part due to over specialization within organizations (e.g. you don't need to learn how to model data because the data folks do that work). By including non-object/component modeling techniques in the UML they're at least put on the radar scope of these developers, increasing the chance that they'd pick up the requisite skills to apply them effectively. Provide guidance to tool vendors. I often see developers struggle to use UML modeling tools effectively. Sometimes their management has forced them to use the modeling tool but they haven't been given adequate training to use it. Unfortunately there's not much I can do about that problem other than to advise against it. Other times, however, the developers have the UML skills, they have a good UML tool, yet they still struggle because the tool doesn't fully reflect what they need to do. Often, the tool is either limited to just the UML or has includes a less-than-stellar implementation of non-UML models (more on this in a minute). For example, if the UML included a physical data modeling profile then O/R mapping tool vendors (see my list of existing O/R mapping tools) might be motivated to build something that maps between a standard class diagram and a standard data
2.
3. 4.
5.
6.
model. Right now, although there are a lot of great O/R mapping tools out there, they're all pretty much limited to a subset of platforms. There are several significant challenges to this approach:
1. The UML is arguably too big already. Although the breadth of the UML is still a bit challenged, the
depth proves to be quite impressive. The UML exhibits such detail due to the needs of the MDA tool vendors, which is great for them, but most UML practitioners neither need nor want this detail. Most people are happy with the 20% of the UML notation that they already use, struggle to see the point of the other 80%, and really aren't all that concerned about adding to the UML. Object purists don't like the idea. The original goal of the UML was to define a common approach to modeling OO software. That scope was later expanded for component-based software. Some purists feel that the scope of the UML is fine the way that it is. Non-object purists don't like the idea. This seems to be a problem withing the data community in particular, although to be fair it's really a problem with a very small minority within the data community. They see modern technologies and techniques, such as agile software development approaches or object technology itself, as a threat. And you know what, they're absolutely right: the changes that have been underway within the application development community since the early 1990s are very different that the traditional data management approaches which some people within the data community still prefer. This is one aspect of the unfortunate cultural impedance mismatch between the object and data communities, a mismatch that we've been trying to address with the Agile Data method and its surrounding techniques.
2. 3.
Why I think we will see the UML extended:
1. The tool vendors are extending the UML on their own. You'd be hard-pressed
to find a "UML modeling tool" that simply restricted itself to "pure UML", and that's perfectly fine. The tool vendors need to meet the actual needs of their clients, and their clients are trying to use their tools to build actual software. This is why you see companies such as IBM, Oracle, and Sybase selling CASE tools which support their own version of "UML data modeling" (respectively, these tools are Rational Software Architect, JDeveloper, and PowerDesigner). Similarly, some UML modeling tools support UI modeling, business process modeling, and web service modeling using their own UML profiles. The methodologists are extending the UML on their own. Many UML book authors describe their techniques for UI, process, and data modeling using the UML. I cover all three in The Object Primer 3rd Edition (I started writing about all three in Building Object Applications That Work and continued to do so in Process Patterns and The Object Primer 2nd Edition). Craig Larman covers similar ground in Applying UML and Patterns. More specifically, for UI modeling via the UML, Mark Harmelen's Object Modeling and User Interface Design is a good read. For UML process modeling, there's Penker and Eriksson's and Business Modeling with UML. For UML data modeling, we have Robert Muller's Database Design for Smarties, Naiberg and Maksimchuk's UML for Database Design, and my own Agile Database Techniques.
2.
3. The OMG is finally starting to extend the UML. They've brought the Business
Process Modeling Notation (BPMN) into their fold, indicating movement towards a standardized approach to process modeling via the UML. They've also issued an RFP for a data modeling notation in December 2005, which is the first step to developing an industry standard. Unfortunately, the data community has never gone to the effort of defining an industry standard notation (not that you can blame them, it's a truly thankless task) so there isn't an existing standards body to work with, unlike with BPMN. In short, it's already happening. Recommended Resources
Agile Model Driven Development (AMDD) Agile Modeling Best Practices
Agile Models Distilled Agile Requirements Best Practices Be Realistic About the UML
Best Practices for Agile/Lean Documentation Introduction to the Diagrams of UML 2 Introduction to Object Orientation
(OO) and UML UML Data Modeling Profile UML Style Guidelines

Am 5

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Am 5

Enviado por

Direitos autorais:

Formatos disponíveis

Examining the Model Driven Architecture (MDA)

Generalizing Specialists: Improving Your IT Career Skills

Generalizing Specialist: A Definition A generalizing specialist is someone who:

Figure 1. How a generalizing specialist's skills may evolve over time.

1. Improved communication and collaboration. A generalizing specialist is someone with a good

Figure 2. A traditional software development team.

Figure 3. An agile software development team.

Class Responsi bility Collabor ator (CRC) cards

Essential Use Cases

Explore how people will Name: Enroll in Seminar

Basic Course of Action:

Add a student to a seminar waiting list.

In Identify what people would like from the system W

Calculate the average mark on a transcript.

Drop a student from a seminar.

Free Form Diagram s

Pretty much everything.

W Define rough design of a screen or page.

Explore how people will

How can the business change?

Figure 1. Essential UI prototype for enrolling in seminars.

Figure 2. Feature sets. Transcript

Calculate fee for a parking pass. Track number of parking passes.

User Interface Prototypes

Figure 1. UI prototyping process.

Figure 2. Essential user interface.

Figure 3. Screen sketches.

2. Initial User Stories (Informal)

Important considerations for writing user stories:

Figure 2. User story card (informal, high level).

4. User Stories and Planning

Figure 4. Disciplined agile change management process.

Figure 5. A detailed agile SDLC.

Figure 7. User story card (formal, with confirmations).

Where Do I Start? Introduction to the Diagrams of UML 2.0

Figure 1. Iterative modeling.

One person's design element is another person's requirem ent.

Reason for Removal

Agile Modeling (AM) Principles v2

Content is More Important Than Representation Open and Honest Communication

Know Your Tools

4. What modeling tools are agilists using in practice?

3.1 Potential CASE Tool Costs

Initial training and education

3.2 Potential CASE Tool Benefits

Figure 1. A UML activity diagram overviewing the requirements engineering process.

Figure 2. An essential user interface prototype.

Figure 3. Two CRC cards.

Through initial, high-level

Figure 4. Agile requirements change management process.

then create working software based on what they tell you.

Figure 5. You'll work with a range of stakeholders.

It's requirements analysis, not retentive

17. Recommended Resources

Figure 1. The Agile SDLC.

Lets consider each phase in turn:

Other important terminology which I use in this article includes:

Figure 2. The Agile Model Driven Development (AMDD) lifecycle.

Figure 3. A UI navigation model for a university system (hand drawn).

Acceptance testing Usability testing Usage testing

Figure 5. The process of usage scenario testing (for a class model).

10. Recommended Resources