The Model Discipline

The goal of this discipline is to understand the business of the organization, the problem domain being addressed by the project, and to identify a viable solution to address the problem domain.

Workflow
Tips
Phase by phase
Suggested reading

Workflow

Tips

You don't need to create all of the models shown in the workflow diagram above, just the ones that are appropriate to your situation
You don't need a lot of details during the Inception and Elaboration phases (see Figure 1), so don't invest much time in detailed modeling and documentation.
Model storming (see Figure 1) is done on a just-in-time (JIT) basis to get the details that you need, typically during Construction.
Your goal is to create models which are just barely good enough for the situation at hand, you can always go back and improve your models later on when you need more details or the situation changes.
Most models are discarded after they're used, a small minority are kept.
Most models are done using simple tools, often plain-old-whiteboards (POWs), and are discarded when they are no longer needed. This is particularly true of your "analysis models" because they are rarely needed once the requirement has been implemented successfully.
There is a wide range of approaches to modeling: CASE tools are great, but they're not your only option
Take advantage of enterprise assets such as an enterprise architecture model, any reference architectures, or enterprise guidance.
Look for opportunities for reuse, you can reuse more than just code.
The wider the range of models that you understand, the greater the chance that you will be able to apply the right work product for your situation. The UML is an important part of your modeling toolkit, but it's only a subset and frankly it needs to be extended beyond it's current scope.
Always model with others. Software development is a lot like swimming, it's very dangerous to do it alone.
Trace your requirements through your models to your code only if it's an actual requirement, and keep it as simple as possible if you do.
Active stakeholder participation is critical to your success.
The easiest way to travel light is to single source information: document something in one place only, ideally the best place. This is often the source code.
Operations and support staff are important project stakeholders who not only understand the issues with the current system, they also have unique requirements which your system will need to implement.
Layer your architecture.
There is significant evidence showing that a serial approach to modeling results in significant wastage.

Figure 1. The Agile Model Driven Development (AMDD) lifecycle (modified).

Phase by Phase

Phase	Activities
Inception	Initial, high-level requirements modeling (see Figure 1). Your stakeholders should actively participate in the development of a high-level requirements model which defines the initial scope for the project and provides sufficient information for a rough estimate. You should consider: Exploring usage by writing point-form use cases. Identifying the business process(es) via the creation of data flow diagrams (DFDs). Identifying the major business entities and their relationships by working on a slim domain model. Identifying major business rules and technical requirements. For now, the name of the business entities, rules, and technical requirements are likely sufficient (you can get the details through model storming during the Construction phase). Starting development of a glossary describing important business and technical terms. Understanding the political structure within your stakeholder community via organizational modeling. Treating requirements like a prioritized stack which evolve over time (this supports true change management, not change prevention). Use cases, business rules, and technical requirements all belong on the stack. Initial, high-level architectural modeling (see Figure 1). Your goal is to identify a viable architectural strategy, critical input into the project planning activity as well as into your implementation efforts. The best way to work is to get several technical people, including some if not all of the developers, together in a room to develop an architectural strategy as you're talking around a plain-old-whiteboard (POW) creating free-form diagrams and perhaps some form of initial deployment model.
Elaboration	Identify technical risks. Your requirements work products, in particular your use cases and technical requirements, will reveal potential technical risks to your project. These risks may include the introduction of new technology to your organization, a new use of existing technologies, significant load/stress on your application, or interfacing to external/legacy systems. The highest priority risks should be addressed by your implementation efforts in the development of an end-to-end skeleton of the system. Architectural modeling. As you build the architectural prototype you will need to model storm some details to to think through portions of the architecture. User interface prototyping. In parallel to the development of the architectural prototype you should also consider user interface prototyping of several major screens. You don't want to do too much prototyping because your requirements are likely to change and therefore your work will need to be discarded. Your goal at the time should be to understand the main screens/pages of your user interface, with the understanding that they will change during Construction, and to identify the basic "look and feel" of your system.
Construction	Analysis model storming. During Construction iterations you will need to work closely with your project stakeholders to understand their needs on a just-in-time (JIT) basis. Important issues: Active stakeholder participation and inclusive modeling which use simple tools and techniques are critical to your success. You may want to flesh out the details of your use cases, perhaps visually using flow charts or UML activity diagrams instead of text descriptions. Explore the business rules and technical requirements in the same manner. You may need to interface to legacy assets such as existing systems or databases. Legacy analysis can be difficult and "politically charged" work. Instead of use case descriptions, business rule descriptions, and technical requirement descriptions you may find it more effective to simply write acceptance test cases instead. This enables you to come close to single sourcing information because you don't need to capture the requirement in both a requirements document and a test description. Because the user interface is the system to many of your stakeholders, you will likely discover that they prefer to focus on what the screens and reports look like instead of the development of other work products, so be prepared to prototype. Keep your project glossary up to date if you have one. Design model storming. During Construction iterations your goal is to do just enough modeling to think through the design of a single requirement, or portion thereof, before implementing the requirement. Agile modelers model directly with developers, they don't simply hand off models to them, and often take on the role of developer. You will likely want to create: UML sequence diagrams. These diagrams depict the dynamic logic within your source code. They are part of your object model but are usually throwaways unless you have a good CASE tool with reverse engineering capabilities. Whiteboards are great tools to create new ones. Deployment model. You typically need to create some sort of "overview diagram" depicted the deployment/network architecture of your system. Free-form diagrams. Typically created on whiteboards and then erased when no longer needed. Free-form diagrams are likely the most common model drawn. System overview documents typically include several free-form diagrams. UML class diagrams. If you're going to do any class diagramming use a modeling tool which generates source code. Your class diagrams should be based on your domain model (if any). Security threat model. If security issues are a concern then you should consider modeling them to help you think through the potential threats as well as how to address those threats. Physical data models. This is likely your most important design model, one which you should consider using a CASE tool to develop and maintain over time, particularly a tool which generates DDL code. It is possible to take an agile approach to data modeling. Document critical design decisions. As you make design decisions you should consider recording any that don't seem obvious, or that you believe someone else in the future would really like to know, as a start to your system overview documentation.
Transition	Model storming. You will need to do some JIT modeling to try to understand the root cause of a defect. Finalize system overview documentation. The best time to finalize your system overview documentation is during this phase when the scope of your system has truly stabilized. Use your critical design decisions, if you documented them during Construction, as the base from which to build this document. Other important information that you'll want in this document is a summary of the scope of the system and critical architecture diagrams (now might be the time to turn those free-form whiteboard sketches into nice looking diagrams using a drawing tool).

The Model Discipline

Workflow

Tips

Phase by Phase

Suggested Reading