(This is the first in a series of blog posts where we will talk about enhancements and changes planned for the upcoming release of our Collaborative Lifecycle Management solution, comprising: Rational Team Concert, Rational Quality Manager, and Rational Requirements Composer.*)
Linking artifacts to express relationships and to establish traceability is at the heart of lifecycle management. Do you remember what it takes to set up the 2009 versions of RRC, RTC, and RQM in such a way that a user can link requirements to tasks and test cases or to navigate previously established links?
As I remember it: You had to configure the applications so that they could securely communicate. Next, you had to create project areas in each of the products. Once you had the project areas, you needed to link them using the correct link types. You also had to ensure that there was an account for each user in each of the products and that the user IDs had the appropriate roles assigned.
It was laborious, manual, and error prone. On top of this, we missed a good way to talk about the network of linked project areas. After we had shipped the 2009 versions of our tools, it was clear that we had to improve this situation, so we did. You can see the results of our work so far in the beta and the recent release candidates.
On the terminology side we introduced “Lifecycle Project” to refer to the network of linked project areas. These project areas are the containers for all the artifacts that can be linked to each other. In the context of a lifecycle project we therefore call them “Artifact Containers”. This name also emphasizes that artifact containers may be realized differently than by project areas. Figure 1 shows you one example of a lifecycle project.
On the functional side we introduced the ability to create, change, and delete lifecycle projects and manage their members. We call this Lifecycle Project Administration, or LPA.
You encounter the first entry point into LPA on the last page of the CLM setup wizard. Later you can always get to LPA by choosing the Lifecycle Project Administration entry in the Home menu. See Figure 2.
If you don’t know what to expect from CLM in general or LPA in particular, I recommend that you deploy the “Money that Matters” sample project. You can find the creation wizard conveniently on the Sample tab in LPA. The sample is a snapshot of a lifecycle project spanning requirements management, change and configuration management, as well as quality management. Each artifact container hosts a rich set of linked artifacts. Once the sample data is created you can explore the lifecycle project and familiarize yourself with CLM. This scenario guides you through this process.
The LPA home page shows you the list of all existing lifecycle projects. You can reveal more details and drill into each project. Each lifecycle project has artifact containers. The artifact container types roughly correspond to the different disciplines your lifecycle project covers. In case you wondered, technically, the types correspond to OSLC domains as the artifact containers are OSLC service providers. Figure 3 shows the overview of the Sample lifecycle project. As you can see, LPA shows the same pieces of information depicted in Figure 1.
The members of a lifecycle project are managed on the Members tab. It shows you who the members are, in which of the artifact containers they are members, and to which container they have read access. The information about roles is available when revealing the details for a member. See Figure 4.
Lifecycle membership is really just the union of the members of each of the artifact containers. Read access, membership, and role assignments are crucial to lifecycle projects as they define who can establish which traceability links and who can read and navigate them. The compact table presentation allows for quick scanning of a large number of project members while the more detailed presentation allows for concrete administration steps.
Adding a new member to a lifecycle project adds the user as a member to each of the artifact containers. The next step is to assign the user appropriate roles in each of the artifact containers. Remember that today artifact containers are really just project areas. Being a member of an artifact container means that you are a member of the project area or any of its team areas. When you add a member to an artifact container, the user becomes a member of the project area. The roles, which can be assigned, are the roles available in the project area.
Depending on what scenarios you want to support there are dependencies between roles in different artifact containers. For example, if you use Scrum as your process in the Change and Configuration Management artifact container and you assign Peter the Product Owner role, you certainly want him to be able to edit requirements in the Requirements Management artifact container too. So, since Peter is not the only one, every time you assign the Product Owner role you have to remember to also assign the Author role. If you don’t remember then Peter and the others in the same situation are only in a partially functional state.
In LPA we provide a way to express these role relationships in the form of Role Assignment Rules. (We first called them Role Rules. Try to say this quickly three times. As a non-native English speaker, I failed predictably. So, we changed the name.) Role assignment rules are captured in an XML file that you can associate with a lifecycle project within the lifecycle project editor. We don’t provide you yet with a specific editor to author role assignment rules. You need to use your favorite text editor. It’s not perfect, but the syntax is not too complicated. Here is an XML snippet showing an example:
<sourceRole context="#rtc.project" id="Product Owner"/>
<targetRole context="#rrc.project" id="Author"/>
Once you have your rules in place, LPA validates whether roles have been assigned according to the rules and it shows the violations. See Figure 5. Violations can then easily be fixed in place by modifying role assignments.
Besides modifying and deleting existing lifecycle projects, you can also create new ones. A lifecycle project is created based on a template. The template describes how many artifact containers should be part of the project and of which type each of them should be. You can either create a lifecycle project using existing containers or you can let LPA create the artifact containers for you. In the latter case, as artifact containers are project areas for now, a template specifies which process templates you can pick from for each of the artifact containers. Figure 6 shows what this looks like.
If you choose to create artifact containers during lifecycle project creation, you to specify where the artifact container should be created. The solution to this comes from the conceptual architecture we employ for CLM so you don’t really have to do anything: Rather than being a set of independent products, a CLM configuration consists of a Jazz Team Server and a set of registered applications. Requirements Management, Change and Configuration Management, and Quality Management are those applications, which are of interest to us. Figure 7 shows this architecture. The applications receive common services such as Lifecycle Project Administration and user management from the Jazz Team Server.
When creating a lifecycle project you can therefore choose any registered application that is capable of hosting an artifact container of the type you need. You don’t have to know which application can do this. Each application tells LPA, and LPA only shows you the subset of the registered applications that is a good match.
We deliver LPA with a set of predefined lifecycle project templates. This simplifies getting started. Although we put a lot of thinking into this set of predefined templates, they are only starting points. You can download, copy, and modify the templates to create a set that matches your needs, contains the right role rules, and is synchronized with your process templates. As role rules, lifecycle project templates are XML files, and your text editor is your friend. We certainly hope that we can provide you with better support going forward.
If the discussion above should have led you to believe that LPA only works for simple configurations, Figure 8 might convince you otherwise. It shows the lifecycle project we use in our daily work to develop the upcoming release of our Collaborative Lifecycle Management products. I will leave leave the detailed explanation to a future blog post.
Despite so many words in this post, I could only provide you with an overview. If you happen to be at Innovate 2011 please drop by when I talk about LPA in more detail. The session is ALM-2166A, “Lifecycle Project Administration for IBM Rational CLM”. So, here is my summary for now:
LPA is not perfect but it makes the life of those who administer lifecycle projects a lot easier. If our out-of-the-box templates are not matching your needs, the pay-off for handcrafting your own lifecycle project templates and role rules are significant.
We have already started to think about what’s next. One interesting question is whether project areas will become less important within the individual applications and lifecycle project will become a more first class concept within the applications. It will be interesting to see how this discussion will evolve. As always you are invited (and encouraged) to be part of this discussion either by commenting below, posting in our forums, and creating and commenting work items.
Jazz Foundation Chief Architect