￿Explicit processes for reasoning about system issues and performing trade studies

￿Early detection of errors

￿Integration as you go, better architecture

￿Traceability

Reduction of risk

MDSD, in conjunction with appropriate governance, can significantly reduce the risks of system development. The goal of many of the activities of MDSD is to reduce risk. The creation of models is the creation of an architecture. We build models to increase understanding, increased understanding reduces what is unknown both technically in the domain space, and operationally in the project management space—our technical knowledge increases as we complete iterations. At the same time, as we produce concrete deliverables we gain better estimates of time to completion. Increased levels of specificity reduce the variance in a solution space. However, MDSD does not create an artificial level of specificity at any point; the creation of false levels of specificity is often an unrecognized trap leading to false confidence and nasty surprises. Increase in knowledge and reduction of variance are prime risk reducers.

Enhanced team communication

Words can be slippery, elusive, and imprecise. Models can improve

communication because they make specific a particular aspect of a system.13 They also can make system issues visible through the use of diagrams. Often it

is easier to point to a picture or diagram than it is to describe something in words. The very act of modeling or diagramming can force you to be concrete and specific. We have seen many times in our consulting practice (and many years of experience across many industries) the value of looking at a diagram, set of diagrams, or models. In one customer we worked with, MDSD diagrams were printed out on a plotter, posted in a central lobby, and became the focal point for discussions about the system across a broad set of stakeholders.

Improved communication across a development organization also occurs as a result of MDSD. Engineers in different disciplines have a unifying language they can use to deal with systems issues. Systems engineers can create models that can be handed to the engineers in multiple disciplines (hardware, software, and others) as specification for their design; common use case models can drive system development, testing, and documentation.

13Again, see Booch et al., Object-Oriented Analysis and Design with Applications, 3rd Edition, Addison-Wesley, 2007, chapter 1: Models provide a means to reason about a part of the system—necessary due to cognitive limits of the human—while maintaining on overall coherence of the parts

Chapter 1. Introduction

9

Page 25
Image 25
IBM SG24-7368-00 manual Reduction of risk, Enhanced team communication