Friday, July 30, 2004

Quality Assurance & Over-modeling

David Greenfield, in comments to yesterday’s post, asks me to comment on modeling and quality and on whether it is possible to “over model”.

Quality Assurance

Firstly, let’s look at modeling and quality. I’ve talked a lot about this recently at the Chicago and Scottish agile developer’s groups. You might like to view my slides from these talks and then apply these words to them.

Modeling in FDD and specifically Coad Method color UML domain modeling, is the key to quality assurance because it is the key underpinning of communication in the project. The domain model acts as the project glossary - all communication should happen in the context of the domain model and its class names, features (method names) and attributes. All team working assignments are based off the domain model and all further design activity is based off and ought to be congruent with the domain model. The domain model is the map of what is to be done, the constraint on what is being done and the foundation on how it is being done.

When I use the term “quality assurance” I use it in the Edwards Deming form, meaning forward loop built-in quality rather than return loop quality control (or testing). Quality assurance is the art of the craftsman, the engineer who takes pride in his/her work. The domain model in FDD is the foundation for that quality assurance.

FDD has several quality assurance mechanisms built into it. Firstly, there is team working. As I said before, “there is no I in FDD.” So work is collaborative and that improves quality. Design work is also done using the domain model as a constraint. A design review should include the domain model and the requirements as the standard against which the design is reviewed. If the design modifies or lies out with the domain model then it should be rejected or an exception recorded and a meeting of the senior members of the team held to discuss whether the model needs to change. The design which is by this time congruent with the domain model is then used along with the coding guidelines as the constraints on a code review. The code produced should match with the design and be within the coding guidelines. Again, if the code is not congruent with these constraints then it should be rejected or an exception recorded.

Exceptions recorded at code reviews are reviewed at a monthly meeting of the chief programmers, architects and development manager where the existing coding guidelines are reviewed and potentially extended. The new document is then circulated to the whole team with any new inclusions highlighted. The new document becomes the new standard (or constraint) for all code reviews. And hence, learning - even at the coding level - is built into FDD.

Over-modeling

Over-modeling and/or analysis paralysis are dangers in the initial FDD process - Build a Domain Model. Analysis paralysis is most likely to happen with novice or apprentice modelers who get into arguments about “is this green or yellow?” and “do we use a blue or create an inheritance hierarchy?” The master or expert will know what to do and move on. Over-modeling in my experience happens with individuals who have had a heavy and often high quality exposure to RUP in their careers - they have been trained to model deep and thrash out every detail.

In much of my writing about the difference between agile and older heavyweight or waterfall approaches, I have highlighted the what I see as the key difference - agile embraces uncertainty whilst traditional methods seek to drive out uncertainty and strive for perfect information at every stage. I feel that RUP attempted to achieve this through the five architectural views - get five views on something just in case you missed something in only one perspective. The Coad Method says - one perspective is good enough and let’s move on.

Avoiding over-modeling or achieving optimal modeling is a skill which has to be learned. It may be the case, that simply sticking names onto classes in a DNC pattern is under-modeling. Coad, Palmer et al advise that you validate the model by trying a few key features on it to show that it provides the structure to answer the questions. The real skill is in knowing how many features to use. The answer is “less than you think but more than none”. My advice is use the law of diminishing returns. If you find that you design a feature and nothing on the model changed and this happens two or at most three times, then move on to another section of the model.