Why should be convenient to exploit models in a software project? Are there some tangible economic advantages in using them, especially considering the effort needed to create and maintain them in the long-term?
Software models can enhance the quality of both the delivered system and the development environment, but only if they are built since the beginning with some careful examination of the final goals that we want to achieve. For example, if we want to exploit models (e.g. UML diagrams plus some related specifications) during testing activities, we have to explicitly model those system elements subjected to test. The resulting model would be very different from the “same” model created with architectural design goals in mind. Understanding the relation between the shape of a model and the designer’s goals is essential in order to exploit modeling in a cost-effective manner. Indeed, in my experience too often the adoption of UML is perceived by managers and team members as the “one size fits all” approach: if we have some class diagrams, they are suitable for analysis & design, code implementation, and test automation. This is not true. The shape of a model influences a lot communication and activities performed on it. Indeed, the same model can be very effective for assuring testability by design, and resulting very poor for design pattern mining. So, as a preliminary step, we need to be very clear about the intended rewarn expected by introducing modeling in the software life-cycle.
The true advantage of modeling (complex) software systems goes beyond the production of a documentation (I will discuss the use of UML to document both the design and the designer’s rationale that eventually motivated it in a future post). An explicit model is essential for bridging the gap between the intended, partially stated user requirements (typically hidden in the mind of stakeholders, analysts, and programmers) and the concrete implementation. In other words, models provides the maximum benefits when they help us to better reason on the system, especially when we try to manage important variations in requirements that affect the structure, other than the functionalities delivered. When the complexity of the system gets out of hand, the developer no longer understand the software well enough to change it safely. In these cases, the model can be the last resort to handle the design. Complex designs should always be based on a model.
Another benefint of software modeling is in making explicit concepts and business rules often hidden in the design. Many changes to the code happen when developers recognize such concepts which were implicit or totally absent in their design. Most of these discoveries come from a lot of experimentation. Indeed, experimentation is the way we learn how things work (or do not work at all). To experiment only at the code level is not usually convenient because we have to delve with many details related more to technology than to the concepts we need to arrange. In these cases, working at the model level, where we concentrate only to the essential things, is economically more convenient.