Strategic Reuse Management and the Rational Unified Process (RUP)
- Strategic Reuse Management and the Rational Unified Process (RUP)
- References and Recommended Reading
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many organizations have adopted, or are in the process of adopting, the Rational Unified Process (RUP) (Kruchten 2000). There's a good reason for this: the RUP is a very good, rigorous software process, arguably the defacto standard within the IT industry. But these days organizations are eager to do more than adopt a new software process. They're just as eager to increase the level of reuse on software projects to both reduce overall cost and time to delivery. The problem is that the RUP doesn't have much to say when it comes to reuse. I suspect this is because reuse is a cross-system issue whereas the RUP focuses on the development of a single system. In this article I'll show that by thinking outside of the RUP box you can easily tailor a strategic reuse management process into the RUP. You can have your process cake and eat it, too.
I define strategic reuse management as "the identification, generalization and/or development of, and support of potentially reusable artifacts" (Ambler and Constantine 2000b). Strategic reuse management is a complex endeavor, one that spans all of the projects within your organization. Your development teams should strive to identify and reuse existing artifacts wherever possible, to buy instead of build where that makes sense, and to produce high-quality artifacts that can potentially be generalized for reuse when that makes sense.
If strategic reuse management requires a cross-project effort, yet the RUP only focuses on the development of a single system, what do you do? Extend the RUP, of course. This is exactly what the Enterprise Unified Process (EUP) does by adding a new discipline called Infrastructure Management (Ambler 2002). Figure 1 depicts the lifecycle for the RUP and Figure 2 the lifecycle for the EUP - you can see how the EUP extends the RUP with two new disciplines (Infrastructure Management and Operations and Support) and one new phase (Production). The focus of this article is on strategic reuse management, one of several critical cross-project issues encompassed by the Infrastructure Management discipline. Other cross-project issues include portfolio management (also called program management), enterprise configuration management, enterprise architecture, enterprise requirements modeling, enterprise process management, and enterprise administration. The bottom line is that practice shows that in order to achieve economies of scale in developing software, to increase the consistency and quality of the software that you develop, and to increase reuse between projects, you must effectively manage your common infrastructure -- you need the EUP's Infrastructure Management discipline.
)
Figure 1. The lifecycle for the Rational Unified Process (RUP).
)
Figure 2. The lifecycle for the Enterprise Unified Process (EUP).
In my experience the most effective way to define a strategic reuse management process is to begin by defining its philosophical foundation. These philosophies should be brainstormed and then debated by a representational group within your organization, thus ensuring the widest acceptance. As a starting point you should consider the following philosophies:
Quality, not quantity, is the goal. You are far better off developing ten high-quality items that people actually need than one hundred low-quality items of interest to no one. High-quality items will help to build the reputation of your reuse program, motivating developers to submit more high-quality items over time. Success breeds success.
Building reusable items is difficult. Reusable items must be of high quality, but they also must be sufficiently general in nature so as to be useful across the widest range of purposes. They also require accompanying documentation, examples, and configuration strategies. This is a significant amount of work that must be performed by experienced people. Steve Adolph (1999) shows this concept well in his implementation of a simple class to simulate dice. He masterfully shows that building something to make it reusable is significantly harder than building it to meet your specific needs at the time. The point is that you shouldn't underestimate the effort to make something reusable.
You can reuse more than just code. A fundamental concept in reuse management is that there are a wide variety of things that you can reuse on a software project, and that different types of reuse offer varying levels of value to your overall effort. My experience (1998) is that there are eight categories of reuse...
- artifact reuse
- code reuse
- component reuse
- domain-component reuse
- framework reuse
- inheritance reuse
- pattern reuse
- and template reuse
...that you may apply on your software projects. It is important to understand each category: different people apply each type of reuse in a different manner to different aspects of your overall development efforts. For example, your programmers typically apply code and component reuse, whereas pattern reuse is typically applied by modelers. It is interesting to note that several of the most effective forms of reuse, such as domain-component reuse and framework reuse, require other infrastructure management efforts, such as enterprise architectural modeling, in order to be successful.
A reuse repository is a good start, but only a start. Over the years I have found that a common mistake that organizations make is that they believe that all they need to do is purchase a reuse repository and they'll automatically improve their levels of reuse, an anti-pattern that I call Repository-Driven Reuse (Ambler 2000). There is more to strategic reuse management than just a good tool — your process and culture must also reflect your reuse strategy. Remember, it's people, process, and tools not just tools.
An asset is reusable only after it has been reused. A good rule of thumb is that you truly know that something is reusable only when three different project teams have reused. Many strategic reuse management programs flounder when the owners of a reuse repository fill it with items that developers aren't interested in. Reuse is in the eye of the beholder - something isn't reusable simply because you declare it to be so.
Reuse isn't free. Reusability has an ongoing cost beyond its initial price of acquisition - you must also manage your reusable assets and support the people using them. Assets must evolve, or be retired when they are no longer viable.
Beware reward systems. I do not believe in rewarding people for reuse. My philosophy is that developing and reusing high-quality artifacts is a fundamental aspect of a software developer's job. Having said that, many organizations decide to embark on a reward program anyway. If this is the case for your organization it is important to explore effective incentives. Roland Racko (1996) believes that a reward program can be useful to help kick-start a reuse program, but you must be prepared to dismantle your reward system as reuse becomes a permanent aspect of your software culture. In short, be smart about how you use rewards.
Many organizations succeed at strategic reuse management, but that's because they go into it with their eyes wide open. You can implement a reuse program within the RUP if you choose to, but to do so you'll have to think outside of the box a bit. Success, after all, is a choice.