Traceability within codeBeamer

Within maturity and reference models like: CMMI (Capability Maturity Model Integration) or Spice/ISO 15504 (Software Process Improvement and Determination)etc. you see that one issue is essential to all these models -> “Traceability”
One of the great things in codeBeamer is the capability to support you with traceability. codeBeamer gives you the foundation to do this by linking all kind of project artefacts together.

codeBeamer offers two ways to do this:
• it can be done by predefined functionality “Add Association” via menu
• or it can be done by interwiki links

The benefit of such associations is pretty easy to explain. Once done, a user of codeBeamer is able to trace all project artefacts which have impacts to each other. Let me show you an example: assume that a “customer” has a change request based on a word document which includes descriptions of requirements. The nice thing with codeBeamer is that the relevant person who has to deal with this change request is now able to trace the complete impact of this change request. E.g. from the word document forward to tasks, requirement etc. down to the affected source code.

However, as I explained before associations can be used in different ways and for various reasons. I would like to share some ideas about using this associations and how they might help in the development.

Let me first start with the more structured “predefined” functionality of adding Associations via the menu:
First of all codeBeamer makes it very easy to bring two artefacts together in the edit Associations dialog the user might take the relevant artefact from a history list of the last 100 project Items used or he might search within codeBeamer or he just uses a URL.

After assigning the artefact you are able to define the Association Type

There are 4 possibilities to specify the association:
• Depends
• Parent
• Child
• Related

Depends

This type of association might be used if you want to point out that one artefact has a strong relationship to another and that it can not exist without the other. A nice example for such an associations is the dependency between tasks. So you can assume that one task can only start if the depended task is finished.

Parent / Child

The link might point from a child artefact to parent artefact. That type of link might be used when you have a refining situation.
An example of a refining situation could be our word document with the requirements from the customer the requirements in the requirements tracker might now be refined out this document. So the requirement-tracker-items are linked as child requirements to the parent word document.

Related

This type of association should be used whenever you need to express a generic relationship between project artefacts. Let’s stay with our example of requirements management. Assume that we derived the requirements out of the word document into the requirement tracker. Now you have very often situation that such requirements have dependencies to other requirements but not the Parent / Child situation as mentioned above. The type of related associations helps now to build up such relationships.
This type of association are the most general ones and might be used if none of the other relationships can be applied

Interwiki links
Another way to build up associations between project artefacts is the way to use interwiki links.
Due to the fact that codeBeamer uses in the description area for artefacts Wiki, it is very easy to set up associations within these descriptions to all kind of project artefacts.

Also here you might use the history of the used artefacts and just copy and paste them into your Wiki description to build a new interwiki link.

Building associations with interwiki links is probably the easiest way of building relationships between project artefacts one thing that is definitely lacking in doing associations with interwiki links is the fact that you are not able to define them as directed link like you might do it with the menu based associations.

There is no doubt that such help for traceability within development projects has a tremendous impact on TCO and ROI. A really nice example how this traceability can be visualized and analyzed is the travis tool from the University of Mannheim. Mr. Hildenbrand and Mr. Geisser who are the “fathers” of this tool did a lot of research regarding traceability in the software development process and in Globally Distributed Software Development Projects.

Please see also:
http://www.ics.uci.edu/~redmiles/publications/C066-deSHR07.pdf
http://www.ics.uci.edu/~redmiles/publications/J011-RvdHA-A+07.pdf

Posted at 04:32PM Jun 27, 2007 by Jean-Pierre in Business  |  Comments[2]