Part 3a of “Using Rational Engineering Lifecycle Manager to answer hard Systems Engineering questions” blog series

Preamble: Our users have been asking us for more practical examples about how to unleash the power of linked lifecycle data in Rational Engineering Lifecycle Manager (RELM), so we have decided to kick off a blog series on the Jazz Team Blog to answer some of your most pressing questions! All of the examples that we will be providing in this blog series were created with problems IBM System Engineering domain users encounter, so many SSE customers will find these examples very relevant to their own process, and will be able to easily adapt the proposed solutions to their own needs. In previous blogs and postings related to RELM, members of our team explained the conceptual value of linked data, as well as provided overview of the Systems & Software Engineering (SSE) solution along with deployment tips, so you may want to start there if you are new to RELM and SSE.

In part one of this series we introduced the concept of practical examples to utilizing the RELM technology and our products, and provided the first example. Part two described another RELM example. Both of these examples demonstrate traceability in the context of change propagation.

In part three we are going to take a different direction, and explore how RELM can be used to detect violation of rules that span across tools. Moreover, we will also make use of custom attributes as well as user identities to answer users’ tough question.

Here we go…  A customer approached us with the following need:

Requirements may sometime have budget limitations associated with them. For example, a requirement to implement a certain system capability may be budgeted up to $5000. The expectation is that the organization will meet the requirement as well as the cost limit – and in fact, the cost limit must be treated as fundamental part of the requirement. The requirement is implemented via several workitems – each work item defines a part of the work and governs the progress of this part of work. But more importantly, each such work item is assigned estimated cost for development. Obviously the workitems are assigned to various team members based on their domain expertise, sub system ownership and so forth. In some cases, the aggregate estimated cost of all the work items goes above the budget allocated for the requirement. However, each of the individual team members assigned to a  workitem may not always be aware of the problem. And, depending on the work allocation and assignment, it may be the case that team members are aware of some problem, but as they own the workitem and not the requirement – they simple move on to progress on the task assigned to them.

What is needed is a solution that support several stakeholder types and scenarios:

• As a requirement owner: Detect possible budget to estimation mismatch scenarios, taking into account the aggregate estimation.
• As a workitem owner: Detect a scenario where a workitem assigned to me is part of a budget/estimation violation scenario

As done in the previous parts of this series, a representative data set was created to explore the problem and suggest a solution. Consider the following Impact Analysis diagram illustrating the data :

RELM Impact Analysis Diagram

Side note: Using RELM impact analysis tool is out of scope for this blog.

The “StatePolice” node on the left is an organization (captured in a SysML Rational Rhapsody model). It is assigned a few Rational DOORS Next Generation requirements (see the DerivedFrom OSLC links). Each such requirement can be assigned various Rational Team Concert (RTC) workitems. In this picture, we can see a requirement called “The State Police shall direct the traffic around the area” mapped to three workitems (189, 190, 187) using the ImplementedBy OSLC link.

As described above, each requirement has a budget custom property. And, each task has a cost estimation field , for example in this picture we can see that task 189 is estimated as 10,000 (see highlighted fields). Depending on the user process this could be man hours, dollar amounts etc.

Task Rich Hover Indicating Task cost

We have created a couple of queries and put them in a folder. Folders are very convenient way to organize RELM views and queries:

The queries used in the next steps

The first query finds all the requirements with a cost estimation that is not empty. For each such requirement, all the change requests are found and scanned for cost estimate. These cost estimates are aggregated and compared to the requirement budget amount. Running this query generates this result set:

Query #1 Result Set

As can be seen in these results in some cases the estimation is indeed bigger than the budgeted amount (as in line #1). In some other cases they are the same (see line #11). And in some other cases, the estimation is in fact smaller than the budget (see line #7). Of course it is kind of hard to skim this result set to detect all the violation scenarios. Instead we can run the second query titled focusing on cost violations only and get a narrow focused result:

Query #2 result set

Indeed this result set shows the manager all of the “problematic” requirements.

Looking back at the problem we wanted to solve, it is clear that these queries solve part pf the problem as they help the “requirement owner”. But what about the workitem owners ?  For these users , we implemented a “My Cost Violation” view. Any user invoking this view will get a clear concise display with results that are relevant to her (for more on how this is done check out the “under the hood” post). The result for the current logged in user look like this:

"My cost violations" view

This simple view shows that the current logged in user is part of a violating scenario. The user is assigned a task (in red) with an estimation of 3000. This task contributes to a budget-estimation mismatch. Note that the view was set up such that is shows the cost on the diagram. The color code we used is:

• Yellow: Requirement
• Blue: Task , not assigned to me
• Red: Task assigned to me

By now you know that RELM views are parametrized. We will now creatively use the user name as a parameter. This is useful for the manager who would like to check on various team members, for example, let us look at the user Pete:

Setting the view to explore Pete's violations

User Pete contributes to two such budget-estimation problems as seen in this view:

Pete's cost violations (two requirements found)

Or, as another example, let’s look at John and what he’s up to ….

Set the view to look at John

This user has a single very simple violation… a single task with estimation higher than the budget described in the requirement. John’s conversations seem to be simpler than Pete’s .

John's violation - one requirement found

This concludes part 3 example flow. With this information requirement owners and workitem owners can very quickly generate situational awareness views and get an insight that is hard to get from any one single tool.

For additional in depth information on this view and the queries behind it , take a look (you guessed it) “under the hood“.

Doron Ben-Ari
STSM, Systems & Software Engineering
dbenari@us.ibm.com