Any tools, including CASE tools, should be used only when using the tool is the option that provides the maximal value for your investment. This is basic investment theory -- if you can invest your money one way and get a 10 percent overall return, or if you can invest your money another way and get a 15 percent overall return, everything else being equal, you're better off with the second investment. With respect to modeling tools, you always have several choices:
- Use simple tools such as index cards and whiteboards.
- Use a diagramming tool such as Microsoft Visio.
- Use a more complicated tool such as TogetherSoft's Together/J, Rational Rose, or Computer Associate's ERWin.
So how do you calculate the expected value for your investment in a tool? I suggest that you don't, at least not from a strict accounting sense of the idea. Yes, you could prepare a complex spreadsheet listing all the costs (see costs for suggestions), both quantitative costs that have a clear dollar value and qualitative costs that need to be fudged into a dollar value -- and then compare them with the expected quantitative and qualitative benefits (see benefits). And of course, you'd naturally have to calculate the net present value (NPV) of all of those figures to ensure that you're comparing apples to apples. I've got a pretty good write-up of how to do all this in my book Process Patterns if you're really interested, but I strongly recommend against this sort of lengthy analysis. Why? Because it's a lot of work that is, more often than not, just a facade used to justify a political decision anyway.
- Initial training and education
- Evaluation costs
- Maintenance of the model over time (it's even worse when the model has outlasted its usefulness but you're still maintaining it for posterity)
- Upgrade costs of the tool
- Ongoing usage/maintenance fees
- Time lost waiting for the tool to do its job
- Time lost over-using the tool (e.g. making your diagrams look pretty, extraneous information, and so on)
- Migration costs to port models to another tool
- Increased effort to synchronize models with other artifacts, such as source code
- CASE tools often promote syntax over communication between developers (in other words, your model looks good but doesn't necessarily work)
- Generated code is often too simplistic, or cluttered with extraneous information required by the tool
- Poor user interfaces often hamper the modeling effort
- Inadequate integration with other tools reduces productivity and/or requires integration work
- Complex tools often prevent the inclusion of non-developers in your modeling efforts
- Forward engineering (code generation)
- Reverse engineering of existing code
- Support for changing levels of abstraction (for example, from requirements to analysis to design to code)
- Testing of the consistency and validity of your models
- Synchronization of models with delivered code
- Support for different views and/or potential solutions to a problem
- Generation of documentation
Acknowledgements: I'd like to thank Malte Finsterwalder, Larry O'Brien, and Jack Surveyor for their insights posted on the Agile Modeling (AM) mailing list regarding this subject.
- Agile Modeling (AM) Home Page.
- The Object Primer 2nd Edition, by Ambler, S.W. New York: Cambridge University Press, (2001).
- Process Patterns: Building Large-Scale Systems Using Object Technology, by Ambler, S.W. New York: Cambridge University Press, 1998.
- CETUS Links OOA&D Tool Links.
- CASE modeling tool vendors:
Scott W. Ambler is a Practice Leader for Agile Development within the IBM Methods group. He develops process materials, speaks at conferences, and works with IBM clients worldwide to help improve their software processes. Scott is author of several books, listed on his Web site at www.ambysoft.com. Scott is also a recognized Ratonal Thought Leader, whose homepage may be viewed here.




