Custom WI attributes vs. associating links

Description
JoernTietjen
Posts: 36
Joined: Tue Jan 10, 2012 2:08 pm
Location: nr Hamburg, Germany

Custom WI attributes vs. associating links

Postby JoernTietjen » Tue Jan 10, 2012 2:59 pm

Hi all,

as I'm not sure about the best way to model requirement properties I would like to learn from your experience.
Would you recommend to model properties as custom WI attributes in general or do you prefer links for it?
Example:
Given that a requirement should be tagged belonging to a certain subsystem of your product (e.g. 'GUI'), would you add a 'subsystem' attribute to the corresponding work item class and set the value of the related instances to 'GUI'. Or would you rather configure a generic subsystem work item class, create an instance of it by the name of 'GUI' and link it to all the requirements related to this subsystem?

IMHO there are many potential WI properties which may either be modeled as custom attributes or by links.
Which way makes it easier to filter for specific sets of work items?
Any further caveats, pros and cons?
Is lacking inheritance of attributes an issue in multi-level work item hierarchies?
Any advice, hints or comments are very much appreciated!

Regards
Joern

Morris
Posts: 3
Joined: Thu Jan 12, 2012 8:41 am

Re: Custom WI attributes vs. associating links

Postby Morris » Thu Jan 12, 2012 8:46 am

Hello Joern in your example I would use the Categories attribute.
You can define some categories in Polarion which are available in each WI. You can set this categorie to 'GUI' in your example.
After you set this attribute you can filter and/or search for it.

Was this helpfull or are you searching for a different solution?

JoernTietjen
Posts: 36
Joined: Tue Jan 10, 2012 2:08 pm
Location: nr Hamburg, Germany

Re: Custom WI attributes vs. associating links

Postby JoernTietjen » Wed Jan 18, 2012 9:33 am

Hi Morris,
thanks for pointing me to the Categories field. This perfectly fits for my simple example.

However, I see some benefits using links to define subsets of WIs:
- a single WI can have multiple links pointing to it (could be also achieved by multi-value fields)
- changing links would not change the contents of a WI, thus would not result in suspicion
- having various custom fields for categorizing WIs to allow different perspectives for subset filtering may overload basic WI types and makes them unnecessarily complex.

Linking seems to be a good approach for 'loose' coupling of WIs, whereas attributes/fields result in close coupling.
Just my two cents.

Regards
Joern

martins
Posts: 181
Joined: Thu Nov 05, 2009 3:24 pm

Re: Custom WI attributes vs. associating links

Postby martins » Fri Jan 20, 2012 3:38 pm

Hello Joern,

I think there's not THE ultimate solution - every solution has its pros and cons:

The pro of using custom attributes is that your configuration and your data stay slim because you do not produce additional WIs and hyperlinks which might become more difficult to handle and flood your system with additional data. That won't be a problem when you calculate with just some hundreds of WIs in your project but if you expect some thousands of WIs to be handled in one project you might get lost in WIs and links :)

Furthermore it's much easier to build queries based on custom fields than on linked (or back-linked) Workitems.

The advantage of using linked WI's is that those linked WI's can store more information than a simple custom field. E. g. in a Workitem of type "Subsystem" you can describe your GUI in detail while an custom attribute just stores an ID and you have to describe the configuration of your GUI in another place.

You can also use a mixture of both approaches: Define a custom enum attribute "subsystem" in your requirement and define a Workitem of type "Subsystems" with the same custom enum "subsystems". Than you can select your subsystem "GUI" from a select list within your requirement and don't have to generate a link to a WI. You just have to make sure that you have exactly one WI of type "Subsystems" for each entry in your subsystem enum. Then in Wiki pages it's rather easy to connect your requirements and subsystems by querying for the WI of type "Subsystems" that has the same value in the custom attribute "subsystem".

You see there are always different possibilities.

It's similar to designing a database: You can either use just one table with many entities or you can use many tables with little numbers of entities but additional relations. Both solutions might be best choice for one purpose but not for another purpose. It's depending on many details (e. g. the number of records expected, used views or queries, your personal taste…).

Kind regards

Martin


Return to “Polarion Application Lifecycle Management (ALM)”

Who is online

Users browsing this forum: Brantpync, RidgeJelo and 9 guests