Chapter 12: Modelling
Previous chapter: 11 Iterative Development
12 Modelling
12.1 Introduction
One of the main sources of errors and failures in projects is cited as the lack of good communication and the consequential misunderstandings between different stakeholder groups. Each stakeholder group (customers, users, managers, developers, technical experts) typically has its own particular jargon, which can lead to confusion and misinterpretation.
Modelling techniques are designed to improve communications and prompt the right questions. They provide an early means of checking that the solution being developed is what is required. They are a valuable aid to achieving project success. The purpose of modelling requirements is:
- To improve understanding through visual representations
- To support transparency by simplifying core elements of a requirement, usually in a picture
- To abstract the most relevant information for clarity (see below)
- To allow cross-checking for consistency
Many organisations benefit from the use of models, prototypes and mock-ups to establish requirements, to confirm expectations and to test the achievability of objectives. These models can be as different as:
- A storyboard to represent a television advertisement
- Architectural blue-prints to define a housing development
- An artist’s impression of a landscaped park
- A scale model of a car to be built
- Process diagrams to establish the required functionality to be supported by a software solution
- A network diagram showing components of a communications network
|
For example: In a business change project:
|
12.2 What is a Model?
A model can be defined as:
- A description or analogy used to help visualise something that cannot be directly observed
- A small but exact copy of something
- A pattern or figure of something to be made
Models may be physical (a built version of some part of an eventual solution - a prototype) For example, a prototype of working software or may be expressed in a specialised language. For example, a diagramming convention, with its own rules and symbols.
DSDM has the principle communicate continuously and clearly, and advocates using visual communication. This means choosing the appropriate medium for communication, with a focus on the right type of communication for the target audience, used at the right time in the project, and using a format and style that can be understood.
Modelling helps to make elements of the solution visible as early as possible. Examples of this could be the use of diagrams, or acting out a new process to be supported by a new IT system. However, the amount of time and effort put into a model should only be just enough to satisfy the purpose of the model and no more.
To enhance clarity, modelling usually incorporates some degree of abstraction, which involves omitting certain information from the model to allow clearer focus on another specific aspect. A different diagram, for a different purpose and different target audience may be used to show these other features. It is usually far too complex and confusing to try to address several target audiences in a single model.
|
For example: The map of the underground railway/subway in a city shows just what it needs to, in order to communicate specific information to its target audience (the traveller). The underground/subway map allows travellers to move from Station A to Station B, and therefore only shows the stations and the links between them. It omits everything else, including the most rudimentary aspects of geography that would indicate how close together stations on different lines are.. If the underground railway/subway is closed and the traveller is sent above ground (for example in an emergency) a different model will be needed (a road map, showing as a minimum compass direction and distances). |
Modelling, like communication in any form, is used to answer specific questions. As a minimum the project always needs to know:
- Who is this for?
- What do they need it for?
12.3 Modelling and Prototyping
Modelling and prototyping are linked concepts. A prototype is always a kind of model; a model is not necessarily a prototype. For example, we can model an existing situation: a building; a staffing structure; a database structure.
A prototype usually implies a new structure.
In IT, the term model has traditionally been used to refer to a set of diagrams.
12.3.1 Target audience for the model
It is important that the level of detail and the language used in the model is appropriate for its target audience. In DSDM, models are used to communicate between teams of mixed specialisms (business, technical, etc.). It is vital to consider the effectiveness of any particular modelling approach to the whole target audience.
Figure 12a: Modelling perspectives
A coherent picture of a solution area can be gained by considering the perspectives: “what”, “where”, “when”, “how”, “who” and “why”, and the relationships between them. For example: who performs which processes; what data is needed to support each process. Matrices can be helpful in drawing these relationships.
The table below shows an interpretation of these perspectives from an IT system point of view, but parallels can easily be drawn for other types of project.
| WHAT | The information within the solution area, data, relationships and business rules |
| HOW | The functions, features and processes within the solution area |
| WHERE | The locations at which the business operates, in relation to the solution area |
| WHO | The people: customers, users, stakeholders |
| WHEN | The events of importance to the business (times and scheduling) |
| WHY | The business objectives and strategy, as related to the project |
DSDM does not require the drawing of models to cover every perspective, unless there is value in doing so.
However, it is worth checking during a project whether any perspective has been missed (overlooked) rather than intentionally omitted.
During the Foundations phase of the project, when a high-level Prioritised Requirements List is being compiled, models can help the whole team be clear about the scope and the boundaries of the solution. One modelling example for foundations is the use of user story mapping.
A user story map is a visual way of making a link between the User Stories (see Chapter 17 - Requirements and User Stories), to allow focus on the bigger picture and to see how the individual User Stories relate to one another. This visualisation then allows the stories to be organised to reflect priorities and their relationships to one another, to form the basis for creation of the Delivery Plan and Timebox Plans.
There are many modelling techniques to choose from, some focusing on a business viewpoint, others used purely for IT. Some of the commonly used techniques are currently:
- Storyboards
- Flowcharts
- Swim-lane diagrams
- Process models
- Class models (IT)
- Use case diagrams (IT)
12.4 Modelling in the Agile Lifecycle
The level of modelling at each phase of the DSDM lifecycle must be appropriate to the level of complexity and characteristics of the project/programme in question.
12.4.1 Pre-project
Pre-Project, existing high-level models may be useful to illustrate how this project, or the solution it could deliver, would fit into a wider picture of change, for example as part of a larger programme.
12.4.2 Feasibility
During the Feasibility phase, models are likely to support a relatively simple ‘big picture’ view of what is being proposed and are used to explore possibilities and help communicate options. Feasibility prototypes may be used to help establish what is possible from a technical perspective as well as helping visualise what a solution might look like from a business perspective.
12.4.3 Foundations
During the Foundations phase, more precise and elaborate models may be created. These models will help communicate plans and intentions to a variety of audiences. Models of business process and business organisation (as they are today and as they are proposed in the future) may be valuable as might high-level designs of technical solutions such as system architecture models and data models. At this point models and prototypes can be used to help clarify scope and support high-level planning by revealing omissions, inconsistencies and dependencies.
12.4.4 Evolutionary Development
During the Evolutionary Development phase it is likely that, where they add ongoing value, high-level models will continue to be evolved in terms of depth and detail as a way of helping to explore the detail of requirements and ways that these may be met as part of the Evolving Solution. Where appropriate, models may be developed that will help with Deployment and with the ongoing operation and support of the solution in live use.
12.4.5 Deployment
It is unlikely that new models will be created during this phase but some that were created to help with the Deployment will be used at this time and perhaps refined for future Project Increments where applicable. In addition, models created to help operate and support the solution may be refined as it transitions into live use.
12.4.6 Post-Project
In post-project, the models used help to operate and support the solution will continue to be refined in line with any changes to the Deployed Solution over time.
12.4.7 Progressive business change
As the solution is deployed, the “as is” models of the current situation give way to the “to be” models which represent the new product or service. It is necessary to make a clear distinction between these two similar models and to be explicit about which is being modelled to avoid later confusion.
It is usually advisable to keep ”as is” models as simple as possible unless there is a strong reason to do otherwise: for example, if the detail is needed to support business change initiatives, or to understand the transition work. The Business Visionary and Business Ambassador roles are embodiments of such “as is” information and should be available throughout the project and during the transition to the new ways of working. The Business Analyst will have the modelling skills to evolve such useful diagrams. The Business Visionary and Business Ambassadors’ availability helps to limit the amount of excessive detail which can sometime obscure such models and reduce their effectiveness.
12.5 Conclusion
Whatever the product or business solution being developed, DSDM recommends an iterative, incremental and collaborative approach to modelling, following the DSDM lifecycle. This approach relies heavily on effective communication.
- DSDM advocates clear and continuous communication, using rich communication techniques. Modelling is one of DSDM’s key practices to support effective communication. Models should be developed iteratively, taking a top-down approach through to the detail and modelling from different perspectives
- Models should always be an aid and never a bureaucratic overhead. The aim of models is to enhance the effectiveness of communication for all members and levels of the development process
- The choice of model should be influenced by the intended audience; use models they will understand
- The use of models, and the formality with which they are created and reviewed, depends on the reason for the model, the nature of the project and on the skills and experience of the team
- The level of models required to support the building of a new power station will be significantly different from the level of models required to support development of a small web-site
- DSDM does not advocate any particular modelling techniques, although there are some well-defined standard modeling approaches. The simplest rules are:
- Do what works for the project and the organisation; capitalise on the skills which exist within the organisation
- Use diagrams and models to establish a common language between the teams
- Do enough appropriate modelling and no more
- Modelling is intended to help people visualise complex things
- Models can help clarify the overall picture at a high level
- Models can help break down the project into comprehensible blocks of work
- Models can be used as a basis for increment and timebox planning
The overriding goal for DSDM is development of a working solution, or a partial solution, as soon as possible. However, an appropriate amount of design up front (EDUF) supported by a few well-chosen models and prototypes at the appropriate time can save the cost of expensive communication errors.