Iterate To Another Artifact: How to Avoid Analysis Paralysis

The basic idea of the Iterate to Another Artifact practice is that if you find yourself stuck when working on one thing then stop and work on something else to get unstuck. This act of being stuck is often referred to as “analysis paralysis” amongst modelers. In Figure 1 the boxes represent potential development artifacts, a matrix describing the relationships between the models is available as is a list linking to descriptions, and the lines represent good options when you are applying the practice Iterate to Another Artifact.

Figure 1. Strategies for iterating to another artifact.

Interesting implications of the diagram:

You have multiple models to choose from.
There is no starting point.
Development is serial in the large. You can see this in the fact that the left side of the diagram are mostly requirements artifacts, that as you proceed towards the right that the artifacts focus on analysis, then design, then finally code.
Development is iterative in the small. On any given day I am likely to work on several artifacts and will iterate back and forth between them.
The UML doesn’t provide a complete picture, instead you need to take a more realistic look at it.
No one model or artifact “drives” another. A common myth is that your data schema should drive your object schema (and vice versa). Instead you need to be prepared to take different strategies depending on your situation.
This diagram is arguably a high-level meta model relating development artifacts that implies traceability strategies for your team.
What I’m really talking about is “modeling normalization” — using each artifact for what it is good for and referring to information in other models (e.g. a use case refers to a business rule) but not copying that information. This approach ensures highly cohesive models that are loosely coupled to one another.

Figure 2, taken from the article Development Phases Examined, shows the various categories of models and how you iterate back and forth between them as needed. It’s basically an update, and generalization, of Figure 1.

Figure 2. Categories of models.

Printing This Article

If you’re trying to print this, you’ll likely need to print it in landscape mode.