A great benefit of iterative development is that it allows development teams to continuously improve the quality of everything they produce during a project as they move from iteration to iteration. This applies not only to code quality, as the teams discover and correct defects, but also to the quality of other work products, such as requirements specifications, designs, tests, and project plans. But how do you ensure that these work products are being assessed at the right times by the right people?

This article provides a simple solution for this challenge. It explains how to effectively use the Development Case and Review Record -- both elements of the IBM Rational Unified Process®, or RUP®, -- to ensure process compliance for RUP-based projects. This approach helps increase the quality of all project-related work products and reduce the risk that team members will not collaborate effectively.

Although RUP does a fine job of describing the Development Case and Review Record, it does not fully explain their interrelationship -- something I will do in this article. In addition, I will provide a practical adaptation of RUP's Microsoft Word templates for these documents that readers can use within their own organizations.

Using the RUP Development Case

Rather than call RUP a "methodology," it is more accurate to describe it as a process framework. RUP provides a rich set of candidate work products with which to define, specify, validate, communicate, and assess your software development effort. Some users refer to these work products as a "smorgasbord"; you can select those that add value for your project and leave the rest on the table. Every work product you choose to create requires that you use the labor of individuals fulfilling roles on the project, so it is important to choose judiciously.

Over the years, I have observed that RUP novices mistakenly assume that they need to complete many of these work products "just in case I need them," -- or worse, as a "learning exercise."¹ This unduly increases the RUP learning curve (and may lower productivity relative to the organization's former process, or lack thereof), as well as project costs, contributing to a stakeholder misperception that RUP is bloated and expensive. Unfortunately, in these situations, an organization may back away from their RUP implementation due to the misperception that the process is inefficient. Therefore, I recommend that those new to RUP use fewer work products than in the past until they get a successful RUP project under their belts.

The Development Case is designed to help you identify which work products to use for a particular project. In the Inception phase of a RUP project, it is important to complete work products that will help you understand the scope, cost, schedule, and risk parameters of the project so that you can decide whether it makes sense to proceed with it. The degree of process you use on the project will be an exponential factor in calculating your effort.² Keeping the number (and formality) of work products to a minimum will also help you minimize costs -- without increasing project risk to an unacceptable level. The result of no process is chaos, but the result of too much process is waste.

Tables 1A-C represent a section of a sample Development Case produced with Microsoft Word. I adapted the format from the version supplied in RUP. Note that Rational Method Composer 7.0 provides a more comprehensive, Excel-based version of this Development Case template that you may use to augment the sample below. My version includes a section to explain the columns in subsequent tables. For the purposes of this example, I included only a set of organizational-specific candidate work products for the RUP Requirements Discipline. I also added a sample non-RUP organizational-specific work product -- a Questionnaire -- for eliciting stakeholder requests.

Note that the RUP template provides a "Tools Used" column that I removed. As table column space is valuable, I specify what tools are used for the various types of work products in a separate table, to free up some space.

You may choose to add your own values to the "Must, Should, Could, Won't" (MoSCoW)³ options in the RUP template. I often use "Shouldn't" to indicate, for example, that we shouldn't update the Developers' Handbook because an organizational standard already exists.

Tailoring the Development Case for your organization and projects

Experienced RUP mentors can help remove work products from the Development Case that will never be necessary for your organization. Those who build software for air traffic control systems, for example, need certain work products to ensure multiple reliability checks, regulatory compliance, and so forth. If your organization is creating software to support more conventional business processes, you can safely remove these work products from the Development Case.

Most organizations have at least one non-RUP work product that they are expected to produce as part of any software development project -- a Post-Implementation Review, for example. An internal audit department or Project Management Office (PMO) might also require certain work products. These can be added as lines within the appropriate Discipline section of the Development Case.

Deleting unnecessary work products and adding organizational-specific ones will result in a Development Case that specifies the process required for the largest project your organization might undertake -- in terms of both activities and degree of ceremony. The result of this process is an organizational-level Development Case template.

Some organizations use multiple organizational Development Cases, each specifying a different type of project, such as application development, COTS (Commercial Off-the-Shelf) implementation, business modeling, or legacy evolution. Then, they use these Development Cases as templates to tailor project-specific Development Cases.

When organizations first adopt RUP, completing such a series of Development Cases can be an onerous, time-consuming process. This is a necessary investment as part of rolling out your customized RUP implementation. Often, that job is assigned to a process engineer, who has to explain the purpose and application for each work product. The good news is that subsequently, the process is much quicker if you create a project-specific Development Case. The project manager now understands the value of these work products, and he or she can quickly negotiate with the process engineer as to which ones are required for a particular project. In this manner, project managers and process engineers can simply tweak previously completed Development Cases to adapt them for the new project's needs.

In many organizations, the most experienced project manager takes on the role of process engineer by default. However, if this individual has been schooled in a conventional, high-ceremony process approach, then he or she is likely not the right person to tailor the Development Case. The person who fills the process engineer role should be knowledgeable and willing regarding the use of modern, agile project management practices. He or she should be constantly on the lookout for opportunities to streamline process without sacrificing quality -- and that includes keeping project work products to a minimum.

Getting stakeholders to sign off on work product selections

When creating their project-specific Development Case from the organization-level Development Case template some project managers, in the interest of reducing the size of their Development Case, delete the rows in the template for work products that they choose not to do. This is a mistake! Instead of deleting the rows for work products not produced, entering "Won't" next to the name of a work product shows that you have carefully considered its merits, assessed the risks of not completing it, and explicitly decided not to do it. Your process engineer (or your organization's process expert) should sign off on the Development Case (or approve it in a less formal way -- via email, for instance) so that everyone understands exactly what work products are required. You want to avoid all-too-common scenarios such as this one:

Marilyn, a project manager, has worked for weeks on a RUP-based project that is about to go live. She sends a request to the operations department, but they refuse to deploy the application without a Disaster Recovery Plan (a non-RUP work product) that is specific to her organization. She goes to Dave, the operations manager, to complain. "We agreed that we didn't need a Disaster Recover Plan for such a small project," Marilyn says. "That's ridiculous," Dave replies. "I would never agree to deploy an application without a DRP!"

Marilyn could have avoided this situation by using a Development Case to specify during the Inception Phase what work products would be required for the project, and then getting certain stakeholders to review and sign off on it. That way, the operations manager could have objected to the shortcut early on, and Marilyn could have added the Disaster Recovery Plan to her work product list. Or, he might have approved the shortcut, and Marilyn would not have encountered this unpleasant obstacle to deployment.

That is the beauty of RUP. It frees you to be as agile as you dare -- provided that you have support from your stakeholders. Conventional methodologies often have no provisions for taking shortcuts. How many times have you been stuck with completing work products that you know have negligible value and will probably never be read by anyone -- just because your boss might get in trouble for not doing it?

Using a Development Case to specify reviews

Based on my experience, the column entitled "Review Type" in the RUP-provided Development Case is not adequate for a typical organization. People do not know what "Formal-External" means in reference to a review.⁴ Instead, I encourage people to use organization-specific terms. For instance, if your steering committee is called a "Project Management Committee (PMC)," then enter "PMC" as a value in the appropriate review column. You can even enter individual's names if you like. For example, a data model for a "Consulted" review type might be "Gary." Do what will be most understandable to others in your organization.

Some people just wish to read work products for awareness; others are accountable for the content; still others are responsible for actually producing them. Table 1B adds columns to support a more specific review model than that in the standard RUP template. The values indicate roles and responsibilities with respect to reviews: "R" for responsible; "A" for accountable; "C" for consulted, and "I" for informed. They allow the PM to clearly outline responsibilities for the content of each work product. Table 1B also adds a column to indicate whether a sign-off is required. In this case, the stakeholder identified in the Accountable column is the one who must sign off on the work product.

Using a RUP Review Record to complement a Development Case

If you are using the Development Case to define a custom process for your project, congratulations are in order. You will save thousands of dollars by not creating work products of questionable value. But how will you know that your projects are actually following the roadmap you outlined in the Development Case?

By using the Review Record provided in RUP. This valuable work product, which is too often overlooked, is a complement to the Development Case and a key to achieving project quality. Essentially, it is a log of all the reviews related to your project.⁵ But it is much more than a list of sign-offs, which are typically tracked on projects, regardless of methodology. It includes all types of reviews, regardless of their formality -- and RUP is relatively unique in recognizing the importance of these reviews.

The Development Case defines what reviews you need; essentially, it is your process compliance roadmap. The process engineer can see who needs to review various work products at certain points during the project -- as quality assurance measures for the right work products at the right times. The Review Record is the instrument he or she can use to record and track these quality assurance reviews (see Figure 1).

The best time to do quality reviews is in real-time -- when the work products are actually being created. If you wait until they are complete and then ask your stakeholders to formally "bless" them, it will be too late for reviews to have any real effect on quality.⁶

Have you ever heard an enterprise architect or database architect complain, when a project was nearing completion, that "I wasn't consulted on that design"? The Review Record can help you avoid this situation by logging all reviews that take place during your project, no matter how informal. For example, suppose you send the architect (who is designated to be "Consulted" on this work product) a note saying, "Here is my design. If I don't hear back from you in a week, I will consider it fine." Although you are not asking for a formal sign-off, your request for a review represents a cross-team collaborative approach and reduces your risk of producing a design that does not conform to enterprise architecture standards. You can record it on the Review Record and refer back to it as necessary.

Reviews can take many different forms. Perhaps a group of people who have received copies of a Vision document sit together around a table to view a presentation on the Vision and afterwards debate the proposed feature list. (Although some organizations regularly conduct such high-ceremony reviews, we try to streamline reviews as much as possible). Perhaps the project manager publishes a document on a portal and invites comments from multiple stakeholders. This flexibility in the formality of reviews is a good thing. It helps you ensure that the right people are consulted at the right time, in the most sensible and productive fashion.

Figure 1: The RUP Review Record complements the RUP Development Case

You can choose a level of granularity for the reviews you log. If you were to do an entry every time you "I"nformed someone about a new version of a work product, you would spend a lot of time on logging. I tend to log only "C"onsultations. Table 2 is an example of a Review Record adapted from the version provided with RUP.

Note a few things:

• If the review results in a sign-off, this is captured on a separate sheet and attached to the work product, if applicable.
• The first column, RUP Iter., refers to the RUP iteration in which the review took place (e.g., I1 = 1^st Iteration of Inception).
• The Cum. Review Effort column captures the total effort expended on reviews. As row one shows, a meeting that brings ten people together in a room for an hour to see and discuss a presentation on the Vision document is a very expensive meeting. Capturing the entire investment required for reviews will allow you to make better trade-offs between doing reviews vs. making quality improvements.
• The values in the Review Method column could include: meeting, e-mail, presentation, etc.

As teams create and review each work product, the project manager creates an entry in the Review Record to record the fact that the review took place and specify next steps, if any. Keeping a Review Record (or Record of Reviews) is not an onerous task; it takes very little time.

In my current engagement, I act as the process engineer for a medium-size organization, which includes working with project managers to define their Development Cases. I am well suited for this role because I have many years of experience managing RUP projects and have seen many successes as well as failures. In my opinion, a good consultant is someone who has made lots of mistakes and has learned from them -- you pay that person to ensure that you won't repeat those mistakes. It is also important to draw upon internal mentors if your organization is new to iterative development or RUP.⁷

Once the project managers and process engineer agree upon what work products to keep in the Development Case, project managers can use it as a roadmap, assigning work to team members to create appropriate work products. The Development Case defines expected review points for these work products, so it is also of great use to a Project Management Office, or PMO (the organization represented by the sample in Table 2 has a PMO). Part of a PMO's mission is to ensure that work products are created and reviewed at appropriate times. At Phase reviews, the PMO can simply check the list of expected work products in the Development Case against the Review Record to see whether all required reviews actually took place. If project managers know that they will be asked for their Review Records, they are typically quite diligent about getting the work products reviewed.

Process improvement with the Development Case and Review Record

RUP suggests that organizations should strive for continuous process improvement as they move through iterations within a project rather than waiting to make improvements between projects. The Development Case and Review Record can support these efforts. Although those new to RUP sometimes assume that the Development Case is a "snapshot" work product to formulate during the Inception phase and then never change, this is not true. As part of the Assess Iteration task, teams often identify either work products they produced that were not very useful or additional work products that would have been helpful. In such cases, they should update the Development Case and Review Record to reflect these improvements so that project managers can adjust their subsequent Iteration Plans accordingly.

Pointers and benefits

As we have seen, the Development Case and Review Record go hand-in-hand to ensure that development teams produce the right products at the right time, and get them reviewed by the right people in an appropriate fashion. Use them to:

• Make sure that you are creating the right work products (no more than necessary) by using a customized version of the Development Case.
• Make sure that you put these work products through an early quality review and correction cycle by using the Review Record -- to avoid scrap and rework later in the development lifecycle.
• Focus on assessing quality efficiently, not on completing 100 percent of your work products.

In addition to the obvious benefits of collecting feedback from stakeholders at key point in the development lifecycle, obtaining enterprise reviews for work products enables teams to harvest best practices from projects and then propagate them across the organization. In this way, using both the Development Case and Review Record supports process improvement and improves the quality of all work products.

In recent years, we have learned to strive for the most agile process possible; we can save thousands of dollars by cutting the fat from our software development projects. However, this does not mean that project managers can take process shortcuts that place communication and quality at risk. Together, the Development Case and Review Record provide a clean, simple roadmap that covers all important bases and represents an effective balance of agility and discipline.⁸

Acknowledgments

My thanks to Bruce MacIsaac and Scott Ambler for their insights on this article.

Notes

¹ For anti-patterns on using too much process, see the chapter on "Common Mistakes When Adopting and Using the RUP" in Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy, 2003

² For more information on software effort estimation, see Barry Boehm et al., Software Cost Estimation with Cocomo II, Prentice-Hall: 2000.

³ For more information, see the Dynamic System Development Method (DSDM) MoSCoW rules. By searching on these terms, your favorite search engine will return a number of Web-based resources.

⁴ See the RUP Development Case template for more information on suggested values for Review Type.

⁵ Scott Ambler suggests that this document could be called a Quality Log or Compliancy Record, as many people associate the word "review" with overly formal or onerous process. I prefer Record of Reviews, or Review Log. Use the name that makes sense for you.

⁶ See Scott Ambler's "Best Practice or Process Smell?" posted at: www.agilemodeling.com

⁷ When it is published later this year, Joshua Barnes's book, Implementing the IBM Rational Unified Process and Solutions: A Guide to Improving Your Software Development Capability and Maturity, 2007, ISBN: 0321369459, will include a discussion on the value of mentors when implementing RUP.

⁸ For a discussion of problems related to using too much process, see the chapter "Common Mistakes When Adopting and Using the RUP", in Kroll & MacIsaac, Agility and Discipline Made Easy: Practices from OpenUP and RUP, Addison-Wesley Professional: 2006.

⁹ Pareto's Law says that we can achieve 80 percent of our required work with only 20 percent of the total effort available. By implication, we often waste 80 percent of our effort on completing the remaining 20 percent of work. So it's important to choose which 20 percent of work is worthwhile.

About the author

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Using the RUP Development Case
• Tailoring the Development Case for your organization and projects
• Getting stakeholders to sign off on work product selections
• Using a Development Case to specify reviews
• Using a RUP Review Record to complement a Development Case
• Process improvement with the Development Case and Review Record
• Pointers and benefits
• Acknowledgments
• Notes
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rational offerings on the IBM Cloud

Quickly scale develop & test environments

Special offers