Exploring Lifecycle Projects

So in my first post I spoke about lots of coffee and working out how to deploy the Rational solution for Collaborative Lifecycle Management. That post focused on RRC,  Requirements Management and a little on traceability. There were of course other interests including development and quality management  represented in those discussions and before I got to diving into RRC, I needed to understand how the different roles, teams, projects, the artifacts they produced or consumed and the relationships between these constructs.

This is important from the point of view of dictating how the different artifact containers or project areas should be organised, particularly in relation to each other. Kai-Uwe Maetzel talks about “Lifecycle Projects”(henceforth referred to as LPs) in Countdown to CLM 2Q11: Part 1 – Administering Lifecycle Projects and the CLM Infocentre has more details on the various aspects of Lifecycle Project Administration. I like pictures so I went straight to the bottom of Kai’s blog and this image:

Starting out

I figured that what was good for the Jazz development team was good for me too. So I went about setting up a structure that looked similar. That is: a single LP (CLM in the figure above) consisting of (or composed of) three top-level artifact containers (aka Project Areas), one each for Requirements Management, Quality Management and Change & Configuration Management. Here’s what i got :

Starting out: My First Lifecycle Project with three artifact containers

The first thing I noticed was the different relationships (Providers and Users) that were created, based on the life-cycle template I had picked : Quality Professional, Analyst, Developer.

Another initial thought that crossed my mind was that perhaps it was important to give each of the artifact containers names that indicated the application (domain) of origin (QM, RM or CCM). In my case I had two named “Jazz Collaborative ALM”. I put that aside to process later.

Adding members

Now that I had my first LP I wanted to add some members to it, along the way exploring the RoleAassignment Rules (RAR). I downloaded the RAR XML, and added a rule to say

“If a user is assigned the Team Member role in the CCM artifact container, then require that the user be assigned the tester role in the QM artifact container and further require that the user be assigned the Commenter role in the RM artifact container”

The XML looks like this:

        <sourceRole id="Team Member" context="#rtc.project"/>
        <targetRole id="tester" context="#rqm.project"/>
        <targetRole id="Commenter" context="#rrc.project"/>

Once I uploaded the modified RAR, I then added Bob to the LP and as expected got the following:

Role Assignment Rules

Following the recommendation I gave Bob the appropriate roles and the errors went away.

Role Assignment Rules : No Error

Adding more projects and members: Episode I

So I had a first LP and I found it easy to add members and make sure they were given appropriate roles in related artifact containers. Now I went back to the picture in Kai’s article and noticed all those other project areas like “SVT_RTC“, “RCPR“, and decided I wanted something similar. So I first created a CCM project area called RCPR (at which point my thought on naming things came back but I pushed it aside), then I went to the Jazz Collaborative ALM project area and added a Provides Related Change link Requests association to the RCPR Project Area (artifact container), which shows up as :

Adding Provides association to Project Area

So now I that I had another related artifact container I thought (a momentary lapse of reason?) I could use the LPA to give Bob a role in the RCPR project area. However this isn’t the case since the new project was created and linked without the CLM LP’s ‘knowledge’, and I can only manage members for the project areas created when the LP was originally created. So the Lifecycle Project Membership page doesn’t change:

Lifecycle Poject Membership

Adding more projects and members: Episode II

I then went to the LP’s “main” admin page and added the RCPR as an Additional Artifact Container:

Add additional Container

So I can now “see” the RCPR artifact container in the context of the CLM LP and in the LP Membership page. I can now use the “Add member to All Artifact Containers” action to add Bob to the RCPR project:

Add Member to All Containers

and set his role:

Add New Member Role

Closing thoughts

Naming the containers (here’s that thought finally:-) with something to indicate the container type (CCM, QM or RM domain) may or may not be so important once the relationship types and their endpoints are understood. I was initially confused by the multiple containers named Jazz Collaborative ALM, until I started to examine the relationships and realized that in a Provides Defects to relationship, the source container is a CCM container while it’s namesake at the other end (the target) is a QM container. When the numbers of projects begin to number in the tens or maybe hundreds I would think it preferable to go with the default convention of appending at least a shortened indicator of the container type (domain) to the name.

If I’ve created an LP and decide to add additional containers as an afterthought, I need to manually create any links between the additional containers and the original containers.  The actual warning provided reads : “You are adding an additional artifact container to this life-cycle project. Links will not be automatically established between additional artifact containers and other artifact containers in the life-cycle project. You will need to establish any links that are needed in the artifact container editor.

If I’ve created an LP and decide to add additional containers as an afterthought LPA won’t allow me to pick and choose which additional containers I add a (new) member to – it’s all containers or none.

Going through Episode II, I liked the convenience of being able to manage container membership and role assignments in one place. Managing large numbers (tens,hundreds) of containers in this way may not have been one of the original design intentions, keeping in mind the potential caveat  about the all or nothing membership approach mentioned earlier.  A secondary side-effect also becomes apparent with a closer examination of the membership page:

Horizontal Explosion

Notice that the new RCPR CCM container is added as an additional column. Ergo, with large numbers of projects there would be a horizontal explosion of containers.

The GUI support isn’t there (yet?) for Role assignment Rules and it would be nice to have support for something like RTC‘s Team Advisor “Quick Fix” mechanism (“here’s a problem, and  a potential solution, would you like me to try to fix it?”).

Putting it all together and taken in conjunction with other mechanisms such as user self-registration and default license assignment , LPA makes the life of anybody setting up and managing CLM much easier.

Bottom line: when initially creating LPs, LPA removes the need for a ton of manual work, including setting up the various links between containers and managing memberships and roles.