Mechanical vs Content Quality

I’m currently working with a client who is capturing a load of project knowledge into a single (EA) repository, pulling the skills & wisdom of 20-30 IT experts into one place.

Before they started doing this, they split up the problem into bits, so that each modeller could work semi-independently of the others, and not have everyone trip over everyone else. And this worked well for quite a while. They even had a small part of the model for obviously re-usable stuff, such as master lists of Actors and Components.

Now they are starting to put the bits together, and some other problems are emerging. To help them to make their model more consistent, and easier so other people to understand and re-use, I’ve been creating a family of tools & techniques to help them.

We’ve chosen to think about the errors into the model is two broad categories:

1. “Mechanical” errors, which can be fixed by applying some simple (ish) rules, with minimal human involvement and bags of automation. Mechanical errors are self-defining: they are the kinds of errors which can be found by mechanical means.
2. “Content” errors, are where, even though the ‘mechanics’ are correct, the model is  still wrong. These can’t be fixed – or even detected – by mechanical means. Another human needs to look at the content and think hard.

The remainder of this post is about the mechanical errors, and talks about using some new techniques we’ve used to find and fix the problems for users of Sparx Enterprise Architect.

Deciding what it's supposed to look like

Finding mechanical errors is about deciding what you think a model should look like, then checking to see if model looks that way.

There are some things we need to describe when defining what a model should look like:

• Which types of element you should use (e.g. ‘Requirement’, ‘User Story’, ‘Stakeholder’)
• Which stereotypes of those elements you should use (if any) e.g. you might decide to have <<Functional>> and <<Non function>>Requirements
• Which links you allow between those elements/stereotypes, and what those links mean
• Which of the built-in or additional attributes you’re going to use (in EA, additional attributes are called Tagged Values). For example, you might decide that each ‘User Story’ has an attribute called ‘Story points’, which, in EA, needs to be a Tagged Value
• What kinds of diagrams you are going to draw, and what they should/may/must contain

A description of this is called a meta-model: a model of what a model should or does look like. Some people call this an ontology, which is a shame, because even most first-language English speakers don’t know the word, so I won’t use it again. But’s it’s in the article now, in case some smart person Googles it.

Your model may be very large, but may still have a simple meta-model. For example, if your model contains 100s of Stakeholders and 1000s of Requirements:

You might say at this point that we should have decided what kinds of ‘things’ our model should contain before we started. This is excellent advice, but sadly, at the start of the project, we didn’t know what we’d need, so the meta-model has evolved very quickly.

This model of ‘what the model is supposed to look like’ we have called a ‘Reference Model’. If the meta-model which see in our day-to-day model is the same as the Reference model, then we have no (mechanical) issues.

What we have developed is set of tools which allow a day-to-day model to be analysed and fixed, by comparing it to a Reference model.

What we do is:

1. Analyse the day-to-day model to see what it’s reference model is like: it’s meta-model
2. Compare that meta-model to the reference meta-model, to see where it differs: where we have issues, or ‘violations’
3. Finally, once we have identified the issues, fix them.

See Model Expert for more details