A while back, another architect mentioned the topic of change cases to me when we were discussing ways to evaluate software architectures. That was the first time I had ever heard the term, and I assumed it was a new technique. I filed it away as a topic to research later. Recently I was asked to provide some training on the topic of architecture evaluation and I decided to do that postponed research.
The two years I spent as a Guide at About.com taught me a lot about internet searches, so I was surprised when I was unable to turn up much in the way of relevant material (if you need to change text from upper to lower case or vice versa, I can tell you where to look). The only truly relevant information was on Scott Ambler’s Agile Modeling site – http://www.agilemodeling.com/artifacts/changeCase.htm. The most significant thing there was a link to the book Designing Hard Software by Douglas W. Bennett (http://www.amazon.com/exec/obidos/ASIN/0133046192), an out of print 1997 book. The only reasonable thing for me to do was buy one of the used books available on Amazon.
Bennett does a good job of identifying categories of change cases. Even if some of the specific examples seem a little out-dated, the concepts translate quite readily into problems being faced by systems under development today. What’s missing is any indication of what the content of the change case should be, and how they should then be used in the evaluation of a software system architecture and design. Scott Ambler offers the following as a change case template:
- Name: (One sentence describing the change)
- Identifier (A unique identifier for this change case, e.g. CC17)
- Description (A couple of sentences or a paragraph describing the basic idea)
- Likelihood (Rating of how likely the change case is to occur (e.g. High, Medium, Low or %))
- Timeframe (Indication of when the change is likely to occur)
- Potential Impact (Indication of how drastic the impact will be if the change occurs)
- Source (Indication of where the requirement came from)
That is a start on an answer to the first question – what is the content of a change case? But that content list raises a question of its own – how do we decide on the potential impact? Also, we still need to consider how we use this information. Is there a structured format for evaluating the impact of a change case?
One possibility is a variation on Robustness Analysis. This technique comes from some of Ivar Jacobson’s early work, as elaborated by Doug Rosenberg in the ICONIX process. In addition to the books that include this topic (http://iconixprocess.com/books/) there’s an article on the ICONIX web site (http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/) and one on the Dr. Dobb’s web site (http://www.ddj.com/architect/184414712). Robustness Analysis is applied to use cases in order to verify their completeness. A variation on this technique might help to identify what objects/components will need to have additional responsibilities and what new components might need to be added where it doesn’t make sense to change or extend an existing component.
A less structured approach might be to emulate the analysis of growth scenarios in the SEI’s Architecture Trade-off Analysis Method (ATAM) (http://www.sei.cmu.edu/architecture/ata_method.html). SEI evaluators often talk about pulling a thread to drill down wherever it is necessary to determine whether or not the architecture will support the growth. This approach works well for the experienced evaluators at the SEI, but may be quite challenging for someone without their level of experience.
My plan is to experiment with these techniques. If you have any suggestions for an alternative method, or a way to apply these two techniques, then please feel free to comment.