Saturday, February 2, 2008

CRC cards-incredibly successful so far

During the last week of December I submitted a post discussing my intention to use CRC modeling techniques on what I would call a "massive" project. I needed a way to collaboratively build an overall domain model for an incredibly complex solution that was currently expressed in a thousand plus pages of linear, non-scenario-based business requirements. I said that I would report on my progress in a later post, and I'm happy to state that CRC modeling has been a fantastic success. While the overall constraints and structure of this project cannot in any way be called "Agile", applying this agile modeling approach across our internal team is providing a fantastic amount of value.

As I stated in my previous post, I initially followed a more traditional modeling approach, which involved a technical team:
1) Reviewing the requirements and creating models
2) Placing white board models into an official UML tool (Rational Software Architect)
3) Holding various workshops with business experts on our team to make sure that the models properly reflected the requirements

Again, as stated in my previous post, this approach had very limited success. The main problems being
1) Business resources were simply not a core part of creating the model. Reviews were simply not that successful/productive

2) UML repositories are really hard to share and maintain on a large team. Especially when rapid change is required.

Note: A lot of agile signatories (Scott Ambler especially) have strong cautions concerning using complex UML case tools; I never understood this before I tried using one with a team of 7 plus resources working on a shared model. It is difficult to overstate the aggravation involved in keeping this model in sync. An excellent resource on case modeling tools can be found on Scott Ambler's site here.

3) The case tool itself was causing the team (myself especially) to model with much more detail than required for this stage of the process. There's a lot of good advice out there on modeling that states that modeling should be at a high level until they can be validated through real implementation. UML diagrams by their very nature can sometimes seem too detailed for this initial analysis.

Within week one of the project restarting after Christmas break, (sometime around the second week of January) I had organized three parallel teams of two technical/modeler types and one business/functional resource. I myself played a floater role of mentor/facilitator/advisor across the three teams. Of course, I only had a week more experience than any of the other teams, but I'm used to doing what I call "just-in-time training". (meaning I train myself just in time to train somebody else)

The technical/modeling resources all had a pretty good understanding of OO and UML, while the business/functional resources had spent the last year and a half collecting 7000 plus business requirements, and thus had a pretty good understanding of what the solution needed to do in order to be successful.

We set up a process that involved spending three hours in the morning conducting modeling sessions using the separate teams mentioned above, then the modelers excluding the functional resources would spend the next half day consolidating the models, removing duplication, creating common structures and making sure that the separate work was combined into a cohesive whole.

Personally, I was personally concerned that CRC cards would not effectively scale, that it would be too hard to organize the cards//we organize them as necessary, that the model would be hard to maintain, and that we would be unable to get the right amount of detail. I was also concerned that the business/functional resources (who have no object oriented training whatsoever) would simply not be able to properly participate.

I have to say that my concerns had been completely unwarranted, every team appears to have had very good success in restating requirements into a CRC format that is now digestible in a matter of minutes, as opposed to hours. Even more important, functional/business resources have all played a vital role in deciphering/explaining business requirements and contributing to the quality/accuracy of our CRC models. I was personally satisfied we are on the right track when I saw specific CRC cards being built by these functional resources. Even more important, the proposed system appears to be a lot simpler than perceived by simply looking at the original requirements. Certainly there still is a lot of complexity, and this will by no means be an easy system to build, but it has become apparent that there is a lot of shared pieces that apply to 70 plus percent of the requirements.
Our client has also been very firm in wanting a Rational Software Architect version of the model. What that means is that we've spent the last week or so entering our CRC cards into this tool. The work involved in ensuring the integrity of the model within the tool, and the level of effort required to make simple changes more than validates the incredible flexibility provided by using simple index cards and particleboards. Changing the contents of a CRC-based model is incredibly easy, incredibly quick, and painless. I'll probably never attempt any serious modeling exercise without CRC cards again. And actually probably little embarrassed that I've never used a CRC before. So two thumbs up IMHO for CRC cards.


  1. Hi Jeff,

    Have you considered modeling your scenarios with just sequence diagrams instead of CRC cards?

    I find CRC cards a bit too vague when it comes to capturing the responsibilities and quickly become confusing when there are multiple objects of a type, or a longer collaboration is worked out, and because they mix object/class roles. Plus, they're only a vehicle for thought and still need to be converted into something more durable when the session is done.

    For me, sequence diagrams fit the bill perfectly for such work. They carry a bit more information but not so much as to get bogged down in details like types and inheritance.

    This is only feasible if you have an editor for such diagrams that makes it very fast to create & update them.

    I couldn't find any tool that let me do that so I created my own : Trace Modeler is any easy to use and smart editor for UML sequence diagrams.

    Here's a 30 sec demo of Trace Modeler in action if you're in a hurry.

    I'm always happy to get feedback, so if you give it a try let me know how you liked it.

    I think it would be a good (better?) alternative to your approach, what do you think?

    Best regards,

  2. Yanic,
    as I understand your tool, is basically a sequence diagramming tool with a mechanism to actually display explicit flows, if so I think it's very interesting!
    I've always had the need to "annotate" my UML in some nonstandard manner to make it more readable. Usually this involves exporting to an image, and MS paint. This looks better

    in terms of CRC cards being too vague, I've actually found them to be at exactly the "right" fidelity for the point in the process that I am in. The objectives for CRC modeling for me was to "re-state" and extract our requirements into a common model which could be further refined later. It's true that there is some cognitive work in associating the flow in a complex collaboration, I found that this was a necessary trade-off for speed in developing the model.

    I should also point out that we are actually converting the CRC cards into both class and sequence diagrams using rational software architect, were actually doing it right now.

    What's interesting to note though, is that the amount of effort involved in creating these high Fidelity diagrams would have killed us during our collaborative modeling sessions.

    So going forward I will probably use the following process
    1) CRC cards >brainstorming and modeling
    2) UML modeling tool (class + sequence) > refinement and documentation (if required by client)

  3. Ah but that was just what I was getting at : the crc cards are just a means to get to the hi fi model. If your modeler would be fast enough, you could try to skip the crc step.

    Trace Modeler allows you to create and change(!) the sequence diagrams really fast so I think it could be a contender towards that goal. - or at least a productive sidekick.

    I'd characterize it as 'basically a sequence diagram editor but a really really productive one'. The control flow highlight is just eye candy really :)

    Perhaps you could indicate how many sequence diagrams you end up with, I'm curious as to the extent of (the documentation of) the models people are creating.

  4. Yanic,
    certainly your tool is a good extension to existing UML notation .

    The point of CRC cards, is not that it offers an alternate notation to UML, rather it supports a collaborative forum for a relatively large group of resources to model at the same time. Using typical case tools means that one person gets access to the tool, while everyone else tells that person what to do.

    With CRC cards, anyone can pick up a card at any time, meaning that everybody in the room has ownership and investment in the resulting model.

    The other interesting point, is that it is much faster to create CRC card models than typical UML sequencing class diagrams using any of the popular tools (rational software architect, together soft, etc.)

    this combination of collaboration and speed makes CRC ideal for what I consider to be the "important" aspects of modeling which is deep knowledge crunching and analysis, rather than pretty documentation.

    If the pretty documentation is still needed, (as it often is in my project) than migrating to UML can happen later on.