How modeling enables agile system development

Two years ago, I wrote here that agile system development for almost 50 years is practiced. Nevertheless, many people find it difficult in practice. There are many reasons for this: For example, many of the relevant standards are not necessarily written in an agile-friendly way. Furthermore, dealing with changes is still a challenge; however, changes are a central aspect of an agile approach ("Responding to change"). But without modeling, reacting to changes can be very time-consuming.

Modeling also helps in other areas of the agile manifesto, such as collaboration, both within the team and with the customer.

First of all, a brief word about modeling: I don't necessarily mean UML or SysML modeling, but also simple information models, such as those I used in the Articles about MBSE had described.

What is modeling?

Languages such as UML and SysML are extremely powerful, but I don't believe that they will be widely used in the medium term, but rather in specialist departments by a few people in depth. So when I refer to modeling as an enabler for agility, I'm not thinking of these languages. Instead, I'm thinking of simple information models that link the artifacts in system development with each other:

Models of this kind have also been around for a long time. DOORS made this possible 20 years ago, and technologies such as the Eclipse Modeling Framework make it possible to develop and link your own powerful models. Almost every tool designed for teamwork works with models, regardless of whether JIRA or Trello. As a user, you are often not even aware that you are modeling: You simply place the individual elements in a context that is intuitively correct and often makes it impossible to put them together incorrectly.

Good tools, such as JamaThe information model can be customized and worked with intuitively: for creating, editing and analyzing.

What is agile?

Also about agility I have already written quite a bit here. To understand how modeling can help with agile system development, let's take a look at the four statements of the Agile Manifesto to:

At first glance, this statement has nothing to do with modeling, but at second glance it does: because a model can define the context of the interaction, which contributes to scaling, overview and traceability.

A good example is gitHuba free platform for software development for open source projects. The model elements used there include program files, issues and patches. However, before a patch is incorporated into the source code, it can be discussed. And the discussion takes place directly in the context of this patch. If a year later someone asks why a certain line of code was included in the source code, this line (model element) is linked to the patch, and this in turn is linked to the discussion in which the answer can be found.

The opposite of this would be if the discussion takes place by e-mail, perhaps in a distribution list that is far too large. Finding this discussion again after a year is extremely time-consuming or even impossible.

Personal interaction is always preferable; but what would traditionally be discussed by email is better discussed in the context of a model element with the right people. [tweetthis]Instead of e-mail, discussions should take place in the context of model elements[/tweetthis].

This statement must of course be adapted somewhat for our purposes.

The problem with comprehensive documentation is that it is time-consuming to maintain for large systems. This is easier with models for two reasons: (1) Firstly, maintaining usually means changing, and as we will see in a moment, changing models is much easier, faster and less error-prone than changing documents. Secondly, documentation is usually a by-product of modeling, as it merely represents a view of the model.

Modeling alone is not enough to achieve functioning systems, but it does make it much easier to focus on the essentials.

Modeling can also set the context for collaboration with customers - as described above with regard to individuals and interactions. Unfortunately, collaboration is limited to reviews that take place every few years and where the customer is suddenly flabbergasted when they see the specification. Or vice versa, where the supplier is horrified that the customer sees everything completely differently.

A good example of how modeling can help here is JamaTheir Review Center also makes it possible to create a view of the model adapted for the review, which then only contains the required elements, attributes and relations. A discussion can then be held there again in the context of individual elements and decisions can be made and documented. In contrast to the gitHub approach described above, the Jama Reviewcenter is more formal and also addresses people outside the organization - such as, or in particular, customers.

As I said at the beginning, changes are one of the biggest challenges these days. Although changes are simple in principle, large developments quickly become complex and difficult to manage. In document-based work, it is difficult to understand which change in the document really affects which other parts of the specification. The finer granularity of modeling makes this much easier to understand.

If we look at the data model shown above and a stakeholder requirement changes, then basically everything downwards is "suspect" and must be checked. For example, all "functional requirements". Impact analyses can then be carried out based on this principle. This is also nothing new in itself; tools such as DOORS were already able to do this 20 years ago, which certainly contributed to its success.

The role of tools

I'm sure you've already heard it at one point or another: Modeling alone is not enough if the tool does not help the user to perceive the aspects shown here. I have already explained what you can do with models described elsewhere. Unfortunately, not all tools are able to do the things described there. And even if they can: Some tools are cumbersome and difficult to use. A good tool, on the other hand, should be so light that you don't even notice it. A good general example of this is the aforementioned Trelloan example from systems engineering is Jama.

There is a second caveat: in realistic real-world projects, there is always more than just one model, or one model and many documents: after all, tests, source code, CAD drawings and much more are also models, which usually have their own tools and are not managed in the requirements tool. Working across model boundaries creates completely different challenges, which I will write about another time.

Image: Jama Software
Publicity obligation: Jama is a customer of Formal Mind