One of the most common misunderstandings or missteps in following a particular software process is to follow that process in a blind, one-size-fits all fashion. This is especially true if you are mandated organizationally to use a particular software process. Just as the founding fathers could not have foreseen the challenges of the modern world when authoring the Constitution, there is no way that the creators of a generic software process could understand the nuances of every particular project where their process would be used.
Processes need to be malleable so that they don’t incite the “baby with the bathwater” response in which the entire process is tossed aside because it proves too inflexible. Good processes can and should be customized. There are several methods that can be used to achieve this end. One of my favorite articles on this topic is an oldie from Per Kroll (“Dr. Process”), entitled How Can We Customize the RUP? In this article, Per lays out 3 basic methods that can be used to customize the RUP:
- Make comprehensive changes to the RUP with the Process Workbench (Heavy)
- Produce a custom RUP configuration using RUP builder (Lighter)
- Create your own development case and place it in the project-specific Web site. (BINGO)
First reading this article caused me to re-examine the development case, an often overlooked project artifact. I fell in love with the idea of the development case but the RUP and online examples I could find at the time didn’t live up to my expectations. Between online examples, my ideas, and a great section on the development case in the book Software Development for Small Teams: A RUP-Centric Approach, I pulled together a template that I’ve carried with me, more or less unchanged, until this very day. I’ve included a copy of this template for you to download. The version that is included in Pennsylvania’s BSCoE Software Engineering Process (SEP) is very similar in many ways. You can find that version in the center ring of the online SEP.
The beauty of the development case is that: (1) it’s very lightweight, just a Word file; (2) it works equally well with a commercial process tool or with no process tool; (3) facilitating a meeting to walk through a development case forces people to communicate about what will and won’t work for them and to make decisions that often have very beneficial impacts for their projects. The best part of the development case is that it works very much like object-oriented inheritance. Customizations from higher levels in an organization can trickle down to lower layers of an organization with customizations and/or additions being provided at every layer where this is required to add value.