 | Level: Introductory Jeff Smith, Software Development Methodologist, IBM
Dan Popescu (dpopescu@us.ibm.com), RUP Content Development, IBM
14 Jul 2006 from The Rational Edge: The authors describe a four-step process for creating a fully customized software development process based on libraries provided in the Rational Method Composer product.
 You can readily find discussion on process implementation and process adoption. But less has been written on starting a process development effort.1 This article addresses the topic of how to jumpstart a process development project from a process tooling perspective.
Rational Method Composer (RMC) provides a unique way to design a customized software development process. The plug-in architecture, re-use through referencing, and the separation of content and process lifecycle provide flexibility in how you construct and tailor a development process. This article describes usage scenarios based on working from the existing RMC method content library to more effectively start your process development effort.
One of the most difficult things to do when developing a process is starting such an endeavor. Some commonly encountered problems are:
- Don't know where to start. Should you start from scratch? Sometimes it's worse to start with some processes already in place.
- Information overload. Often there are many different sources of information that need to be reviewed to begin to develop the process; static information overload (documents, documents, documents...).
- Balance between different process owner interests. Different roles in an organization maintain different interests in various aspects of the process development and process generally.
- Organization of process-related information. Often it's hard to keep all the different elements of your process organized, and even more difficult to update and maintain this information.
- Development environment constraints. Manual static documents can make it hard to conceptualize the process, and hard to see what the process is and all its related elements.
- Inherent process complexity. The process is often dauntingly complex and can't easily be tackled without the aid of some type of tooling platform.
One way to overcome some of these problems is to begin your process development effort using the Rational Unified Process®, or RUP®, as your base. RMC comes with a default method content library consisting of plug-ins that can be used directly from within the RMC tool, and the RUP plug-in is included out of the box in the RMC plug-in library. We will describe one way to use this existing library to jumpstart your process development. This is a simple four-step approach based on 1) reviewing the RUP library, 2) creating a roadmap, 3) performing a RUP gap analysis, and finally, 4) using the RMC's content variability feature to customize your process further.
Reviewing the RUP library
RMC out of the box ships with a wealth of process content. Just as with any other development environment, before you can become proficient with it, you must become familiar with the libraries that are available. Imagine that you are asked to write a Java program within an IDE. Before you begin coding, you would first get up to speed on what library or libraries to import. This way, you can write code more efficiently by knowing what to extend or implement off of. Similarly, in RMC, before you begin building your process, you should first familiarize yourself with the process content that comes in the form of plug-ins in the default method library mentioned above. A plug-in consists of a method side (Method Content package) and a process side (Processes package) as shown in Figure 1.
Figure 1: RMC Method Library plug-ins
To review the plug-ins, explore the method content packages and the processes. Once you get comfortable with these plug-ins, you can "publish" a plug-in to see how it all fits together in the published format. In RMC, publication is in large part the end goal of the process development. The publication of your process represents the deployment of your process in HTML format. Publication is done by means of a method configuration.2
The use of plug-ins in RMC is facilitated by means of a base plug-in. For example, locate the rup_soa_plug-in and double-click on it. The "Referenced Plug-ins" section displays additional plug-ins that are referenced by the rup_soa_plugin. In this case, you can see how it is based on the rup and rup_bm plug-ins.
Now that you have reviewed the RMC method content library, you can create your own method plug-in to build on. In this case, we will use RUP as a base in order to build a software project management process. To start things off, right-click in the method library view. Select New Method Plug-in from the context menu. In the New Method Plug-in window, name the plug-in "acme software project management." You will see something like the screen shown in Figure 2.
Figure 2: The "software project management process" plug-in
Creating a roadmap
In this next step, you will write up a story about how your area of the software development lifecycle functions. (After you have reviewed this roadmap with key stakeholders, you will translate this story into your "software project management process" plug-in.) At this point, you don't need to be concerned at all with RMC. Simply start by describing the activities performed in your process. Here's an example written from a software project manager's perspective of a four-phased process:
Feasibility
Feasibility activities identify the technical, financial, and schedule feasibility of the project. The software project manager creates and manages the software feasibility plan. This plan is used along with the software development plan and the risk management plan to assess the project feasibility. If the software steering committee considers the project feasible, then the project proceeds to the analysis phase, otherwise, the project is ended.
Analysis
In analysis activities, the project manager and the project review team put together an iteration plan to manage the entire project's iterations. In addition, because the project is focused now on requirements and software architecture, the software project manager is responsible for compiling a risk list. This is a formal artifact that will be maintained throughout the project. The software project manager with the help of the management review team updates the software development plan as needed.
Development
The majority of project management in development activities consists of updating the software development plan, maintaining project review records, creating and trapping project metrics, and conducting project iteration assessments based on the software project management group's iteration planning.
Transition
Transition activities involve deploying and implementing the software for the customer. The software project manager is responsible for ensuring that the software project comes to a successful completion as captured in the Project Closeout Report. In addition, the software project management group uses the Post-Launch Review Report and Project Post-Mortem Analysis Document to continually improve the software project management effort.
After you have reviewed this roadmap of activities with key stakeholders, you translate it into your "software project management process" plug-in. This is a simple process in RMC. To begin, follow these steps:
- Go to the software project management process plug-in.
- Expand the Method Content package, and right-click on the Content Packages.
- Select New--»Content Package. In the Name field, type Guidance.
- Go to File--»Save All.
- Expand the Guidance content package. You'll see that RMC has automatically populated Roles, Tasks, Work Products, and Guidance for you. You can use this to group these items that are related to the plug-in's guidance.
- To create the roadmap, right-click on the Guidance element within the Guidance content package. RMC presents you with a context menu of the different types of guidance you can create here.
- Select New--»Roadmap.
- In the Name field, type software_pm_process_roadmap. This is the file name associated for this roadmap.
- In the Presentation Name field, type Software Project Management Process Roadmap. This is the presentation name that appears when you view this roadmap.
At this point, you can take your roadmap story created and approved earlier and put it directly into your process by entering this roadmap content in the Main Description field. To facilitate authoring this content, click on the rich text editor icon to the left of the Main Description. RMC provides you with a convenient rich text editor capability for building your process content. Figure 3 shows an example of our roadmap in the Preview mode, which you can access from the Preview tab of the Roadmap itself.
Figure 3: Preview of the Software Project Management Roadmap
Now that we have the story documented, refining this roadmap based on further stakeholder feedback is as easy as accessing our plug-in, opening the roadmap in RMC, and updating the Main Description. RMC organizes and maintains this roadmap within the process for you.
There are many different forms these roadmaps might take. Before you begin writing yours, browse the method plug-in library for examples from method plug-ins such as rup, rup_legacy_evol_plugin, rup_j2ee_plug-in, rup_soa_plugin, and rup_ux_modeling_plugin.
Performing a RUP gap analysis
With stakeholder agreement on your process story, you can now begin to identify key differences between your process and RUP. Start with the work products. Table 1 shows some of the gaps between your software project management process and RUP.
Table 1: Work product mapping
| SW Project Management Process Work Product | RUP Work Product |
|---|
| Software Feasibility Plan | X | | Software Development Plan | Software Development Plan | | Risk Management Plan | Risk Management Plan | | Iteration Plan | Iteration Plan | | Risk List | Risk List | | Project Review Records | Project Review Records | | Project Metrics | Project Measurements | | Iteration Assessment | Iteration Assessment | | Project Closeout Report | X | | Post-Launch Review Report | X | | Post-Mortem Review Document | X | | X | Business Case | | X | Deployment Plan | | X | Issues List | | X | Status Assessment | | X | Work Order |
As you build these comparisons, it is important to check the integrity of these comparison tables. You need to ensure a couple of things. First, where there is a RUP complement to your work product, does it in fact capture what you want? If there is a RUP work product but no counterpart in your software project management process, should you add this work product? Is it possible to take some of your work products and collapse them into a RUP work product? As you perform this analysis, it is a good idea to provide a rationale for your mapping.
After you feel comfortable with the work product comparison, you should next address the roles. Assess these roles according to the goals of the phases for feasibility, analysis, development, and transition. Finally, identify the tasks that allow you to achieve these goals.
Using content variability
Once you have achieved agreement on the work products, roles, phases, phase goals, and tasks, you can now begin to fine tune your process by using RMC's content variability feature. Content variability allows you to build off of existing process elements by means of contribution, extension, or replacement. These three types of variability are briefly described in Table 2 below.
Table 2: Variability types| Variability Type | Description |
|---|
| Contributes | A contributing element adds to the base element. Contributes provides a way for elements to contribute their properties into their base element without directly changing any of its existing properties, such as in an additive fashion.
| | Replaces | A replacing element replaces parts of the base element. Replaces provides a way for an element to replace a base element without directly changing any of the base element's existing properties. This is, in most cases, used for method plug-ins that aim to replace specific content elements such as roles, tasks, or activities with either a completely new variant or to change the fundamental relationships of these elements. The effect of this is that the base content element is logically replaced with the new replacing element to which all incoming associations still point as before, but which has potentially new attribute values and outgoing association properties. | | Extends | An extending element inherits characteristics of the base element. Extends allows method plug-ins to easily reuse elements from a base plug-in by providing a kind of inheritance for the extending element. Attribute values and association instances are inherited from the "based-on" element to the extending element. The result is that the extending element has the same properties as the "based-on" element, but might define its own additions. Extends is not used to modify content of the base plug-in, but to provide the ability for the extending plug-in to define its own content, which is a variant of content already defined. |
After you review your work product mapping, for example, you find that the RUP software development plan is a close approximation of what you want in your process. Rather than create another work product, you decide to contribute to the RUP software development plan by using the contribution variability type. Perform the following steps in RMC:
- Go to the software project management process plug-in in the Library View.
- Expand the Method Content package, and right-click on the Content Packages.
- Select New--»Content Package. In the Name field, type Software Project Management.
- Go to File--»Save All.
- Expand the Software Project Management content package. You'll see that RMC has automatically populated Roles, Tasks, Work Products, and Guidance for you. You can use this to group these items that are related to the plug-in's guidance.
- To contribute to the RUP software project management plan and use this in your process, right-click on the Work Product element within the Software Project Management content package. RMC presents you with a context menu of the different types of work products in the form of artifacts, deliverables, or outcomes. Since the software development plan in RUP that we want to contribute is an artifact, select New--»Artifact.
- In the Name field, type sw_development_plan. Leave the Presentation Name field blank. (Since you are contributing to the RUP software development plan, you will retain the presentation name of RUP artifact.)
- Scroll down to the bottom of the sw_development_plan to where it says "Content Variability." In the Variability type drop down, select Contributes.
- In the Base field just below, select the Select button. (For convenience, in the Select Artifacts Dialog window, click the Collapse All button.)
- Now expand the RUP plug-in and expand the Management package and expand the Project Planning package. Select the rup_software_development_plan artifact, and click Ok.
- Now, any text you type in any field for your software development plan artifact will be added to the end of the text of the RUP software development plan. Try this now, but, for example, typing "This plan serves as the overarching plan for the entire software development effort." in the Main Description field of your artifact. Click Save All.
You now have a software development plan for your process with everything from the RUP software development, plus your additional content for the Main Description. (Note: To see how RMC resolves this content variability, you need to switch to the Browsing perspective. This is beyond the scope of this paper.)
Next steps
RMC makes a clear distinction between the method dimension and process dimension. The method content answers the questions "What will be produced?" "Who's responsible and what skills are needed?" and "How will the work products be generated?" The process dimension deals with the "when" question -- in other words, how the method content elements are temporally related into semi-ordered sequences.
In a follow-up article, we will address specifically how to take the next steps in developing the method dimension together with the process dimension -- i.e., capability patterns. In addition, we will focus on preparation for publication of your process, including how to define views through custom categories.
Summary
Process development can be a complex undertaking, with unique challenges. Disparate sources of process information, conflicting stakeholders' needs, information overload, process complexity, just to name a few, are all potentially major obstacles in developing a process. The RMC tool will not solve all these problems. But it will make the job of starting such an effort easier by means of plug-in re-use and method content organization.
Notes
1 See, for example, Maria Ericsson, Zoe Eason, Lynn Mueller, "Transforming your software development capabilities: A framework for organizational change" at http://www.ibm.com/developerworks/rational/library/sep05/eason/; Michael F. Hanford "Getting started with portfolio management" at http://www.ibm.com/developerworks/rational/library/may06/hanford/index.html; and Bill Higgins "Ground rules for managing business process integration projects" at http://www.ibm.com/developerworks/rational/library/jul05/higgins/
2 For more information on how to publish a process, see Peter Haumer, "IBM Rational Method Composer Part 1: Key concepts" at http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html
About the authors | | | Jeff Smith is a software development methodologist with IBM, contributing to the definition of IBM’s commercial method development with a focus on testing/validation. Before joining the IBM Rational commercial methods content team, he developed software in the medical devices domain. Jeff holds a MSc in the analysis, design, and implementation of information systems from the London School of Economics (LSE). |
| | | Dan Popescu is a member of the RUP Content Development team. He has nineteen years of software development experience on two continents and holds a MSc in electrical engineering. Before joining IBM Rational, Dan was involved in developing systems for the telecommunications and semiconductor equipment industries, playing a variety of roles, including software architect, team lead, and process engineer. |
Rate this page
| |
