usage of issues

[kamil.svoboda]

Hi,
What's your experience with using model issues (system window) and packaged (object) issues in project?
How can I use them in project management? Why they aren't related? (They don't use common unique ids and are stored in different tabels...) Shall I choose one of them and use them for all issues in project?
Thanks for your advise.
Kamil

[thomaskilian]

Hi Kamil,
issues in the system tab are meant to keep track of open points/questions a.s.o. that arise during the course of a project. In that respect they are a very useful tool.

Honestly speaking I don't know what you mean by "packaged (object) issues". Could you please elaborate?

[Rob_M]

Under the Custom tool bar there are elements called "Issues" and "Change". I believe this is what kamil is referring to.

The short answer is use them as you see fit.

One consideration for "element" type issues is if you have a need (perhaps contractual) for tracing issues (or PCR or Deficiency reports or whatever your organization happens to call these things) to other elements that are affected. For example, and issue may require the rewrite of a number of requirements. You can create trace lines from these issues to requirements and then later to design elements. A relationship matrix can be viewed between issues and requirements/design elements to see if certain requirements/design elements are problematic.

As second use I have for them is in document generation. I have used EA to generate full software requirement specifications (SRS) by carefully tailoring the packages to correspond to sections within a document. Quite often in these documents you will have a revision change section (or perhaps multiple revision change sections if you use incremental development methods). By creating new issue elements in the "Revision" section you essentially have a created a revision change section for the document.

Those are two uses I have for the Issue and Change elements.
Note that you cannot create associations between "Model Issues" and other elements like you can with "Object Issues", nor can you select the placement of the model issue within the document.

Rob_M

[kamil.svoboda]

Thank you for your reply!

I think the "object issues" are very usefull. As you say I can trace them, associate with requierements, categorize by packages, etc.
But "system issues" have much more properties, which are also usefull. For example Date of resolution, Resolved by, etc.
"Object issue" is stereotyped comment element with limited properties. I know that I can use Tags for specification of wanted properties, but I have to set them for every "object issue" again  :-/ Predefined set of tags, which I can assign to selected element, would be a good feature... ¨
Also common id's counter for "object issues" and "system issues" is requested...
Kamil

[Rob_M]

If you want both features, i.e. the ability to trace and the added capability in the Model Issues, consider the Maintenance view that records Element Defects, Changes and Issues on a per Element basis. Since these are on a per Element basis, we can essentially have Element Issues for an Issue element. In this way, you might have a broad category recorded in an Issue element, then have a number of Element Issues, associated with the Issue Element.

[kamil.svoboda]

)) a good idea! A bit complicated, but it resolve my problem...
Thanks!