Filter
Top Products
Chapter 1. Introduction 9
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.
13
Again, 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