My client needed a SoDA template that would report on a variety of models. These models consist of a number of sections (Use Case, User Interface, Database Structure, etc.) Now in some cases we want to report on the only the Use Case section, in some cases we want to report on only the Database Structure section, in some cases we want to report on all three sections. (Bear in mind that this is only an example in reality my client has about 12 distinct sections). Now there are three ways to move forward from here:
- We can create 12 separate SoDA templates (one for each section) and have the designers manually splice the reports together after generation. This technique will not work for two reasons. The first is that people are strapped for time, and the menial job of combining documents is an incredible waist of recourse. The second is that the final report needs to be a complete document with consistent page numbers, table of context, and list of figures. Achieving this coherence with spliced together documents would be a greater headache then its worth.
- Our second option is to figure out all of the combinations that would typically occur and create a separate SoDA template for each. Already most people should see that this is not viable. Mathematically, the number of combinations of the 12 sections is huge! 495 to be precise. (And yes it took me a while to work that number out). Now obviously we are not going to need every single combination, but even if we whittle it down to 10, that’s still far too many. The redundancy involved becomes a huge threat. Changing one report feature will mean changing it in up to 10 places. The time involved and potential for error is too large for this to be a viable option.
- Our last option is to have a single report which has ‘options’. That is a report which allows you to select which sections you want to include and which sections you want to leave out. The problem here is that SoDA (being a simple Word Plug-in) does not give you this option. I even sent a mail to the trusted and helpful Rational Support Team to make sure that this functionality wasn’t ‘hidden’ in the background somewhere, but alas the answer was no.
So now we have a solid understanding of the problem we are trying to solve. We understand that option 3 would be our best solution. In ‘A More Dynamic SoDA (Part 2)’ I will discuss how I implemented option 3 using a bit of Template Magic. We will also talk about some of the benefits and drawbacks of my solution.
Until next time
Design quote of the day:
First you listen to the users; then you ignore them.