I recently just started work on what I consider to be a fairly large project with a large number of complex requirements. A massive amount of requirements had already been collected, (over a thousand pages worth). Unfortunately, a large majority of the requirements were not scenario driven, but of the "the system should make sure that..." variety. Extremely hard to follow especially giving this scale.
I was tasked with applying some structure and some modeling driven techniques to help frame the requirements and set the stage for downstream delivery. Needless to say, the environment for this project could be definitely considered less than ideal from an agile point of view. Project management did not want any development to start until requirements were better structured, and we had a better understanding of how different requirements mapped to different technology components.
One of the recommendations I quickly made was to develop a business domain model using package, class, and sequence diagrams. I'd read an excellent book by Eric Evans called Domain Driven Design, which nicely combined business centric modeling, UML, and a pragmatic, agile approach. I was hoping to use the functional resources that were responsible for putting together the business requirements in a business domain expert/reviewer capacity, as well as use a team of more intermediate resources to do the bulk of the modeling effort, with myself providing direction and guidance . We were constrained with using Rational Architect as our modeling tool, as that is what the client owned .
After about a month of modeling efforts, I had to admit I was not entirely pleased with our progress. Given a couple of days to reflect, I believe that the source of much of our inertia was due to the following
1) white board-based models are too hard to change once significant amount of effort has been put into creating the model. Whiteboards, while inclusive, need to be erased eventually, and require way too much redrawing.
2) most UML modeling tools might be a little bit easier to change, but are not collaborative in nature. There is way too much overhead in either printing off the models so that a large number of resources can collaboratively review and modify, or setting up a projector. Any changes require further work with the tool, and the turnaround time between making changes and putting them in the tool take way too long.
3) if business domain experts are not involved in directly creating the model, they do not focus enough on the model to see if they are correct. Our functional resources had several chances to take a look at many of our models before showing them to the client, but it was only until we did a live session with the client where the functional resources were actually asked to help the modeling team defend some of the modeling decisions did it become apparent how wrong our models were.
4) UML and the associated tools, just offer way too much detail. This detail actually can get in the way of initial modeling efforts. Despite my best intentions, I frequently found myself concerned with issues that were just not relevant at this point in the process. I can personally reflect on many situations where I spent too much time concerned with directionality of relationships, the use of inheritance over other more flexible typing mechanisms, and other issues.
CRC cards to the rescue
Now I admit to having heard of CRC cards before, but I've never paid much attention. I've always been happy to use TogetherJ or some other modeling tool for the majority of my diagrams, reviewing my work with other resources, or handing them off as necessary. Whoever, I believe that the the incredible business complexity of this project, the relatively large number of resources on the team, and scope of the proposed application dictates a different approach. I was doing some Internet research on various modeling tools and techniques and came upon CRC cards by accident. It didn't take very much reading for me to realize this approach had fascinating potential. I'm not going to go into too much detail around what CRC modeling is, however in brief CRC modeling involves placing responsibilities (methods and properties for classes) onto index cards (one index card for each class) as well as placing the collaborations necessary (with other classes) to fill these responsibilities. Index cards that represent classes with the lot of collaboration are placed close to each other, index cards that represent classes that implement or extend other classes/interfaces can be placed on top of each other. Potential models can be rapidly re-factored by rearranging these index cards. One can then trace through a set of classes and their responsibilities to see if a model will support specific requirements. One excellent resource concerning CRC modeling can be found here.
I quickly played with some CRC cards for about half a day, and was amazed at the speed I was able to model a large portion of requirements. I believe CRC cards will enable me to be effective on this project for the following reasons.
1) east of use-unlike UML, as well as most UML modeling tools, CRC cards are incredibly easy to learn, and do not require a lot of technical skill or object oriented knowledge to understand.
2) collaborative-CRC cards are incredibly collaborative, many resources (both technical and business oriented) can sit around a large table, and create CRC cards together. The result is a model that will have a very high alignment with true business concept situations and processes.
3) low fidelity-CRC cards natively support a lower precision fidelity then UML modeling notation. This lack of detail is actually a benefit when trying to focus on the nature of responsibility and collaboration, parameter ordering, datatypes, and other details found in UML just get in the way of this kind of modeling.
4) extremely easy to change-models made from CRC cards are very easy to reorganize, modify, and extend. Cards can be very easily ripped up, replaced, and changed.
Once I get back to work from the Christmas holidays I plan to introduce this technique to the modeling team, I would like to use CRC cards until the majority of the model has been completed, then translate the results to a more official modeling tool. I will certainly post the results here.
No comments:
Post a Comment