Opinions wanted about Tracking Issues

[Anibal Rojas]

Hi everybody,

   I have been evaluating the Issue tracking in EA. And found the following:

* The issues STATUS are different in the Project, in the Element Project Management, and when the Issued is an Element:
Project: Open, Under Review, and Closed;
Project Management: New, Verified and Completed.
Issue Element: Proposed, Approved, Mandatory, Validated and Implemented.

* The people/role are different in the Project, in the Element Project Management, and when the Issued is an Element:
Project: Owner and Resolver.
Project Management: Reporter and Resolver.
Issue Element:Author

I think that the Issue tracking should be consistent across the whole project in order to be usefull. And that the Project Issues should include ALL the issues, and allow the filtering of them so I can check, responsibilities, dates, status, packages, etc.

I think EA is a great tool, that is focused in a TRUE development conditions. And that this feature would help a lot to keep the Project under control.

I woul like to ear your opinions about this points. Thanks in advance.

[Steve_Straley]

Hi,

I will let Geoff and Paul step in with a formal response; however, I wanted to jump in with some thoughts.   You raise some interesting points that are really at the scratch of the surface; namely, proper project management and planning using EA.  To that issue we are writing a tutorial outlining our project, the progress, the ideas we came up with... including using CVS and other tools along with EA.

I think the general problem here is the term "issue": it means something different to the scope of what you are looking at within EA.   Issue Elements actually can be modified within EA under the REFERENCE -> GENERAL TYPES -> STATUS TYPES.  Here, an "issue" deal directly with an implementable thing (like a functional requirement, for example).   However, in Project Management, an "issue" to me is something higher in scope... is it new, has it been verified, is it completed, et cetera.  The same thing, IMO, can be said for a project in general.

With regards to People and Roles, this actuall is the first section in our tutorial (Geoff has a copy of the start of it).  Again, the role and the people are different depending on what it is you are looking it.  

I know it can be confusing (along with the word "TAG" ).  I hope these brief thoughts help.

Steve

[dltodd]

I would like to see the issues have the option of tying them to a specific thing. Maybe there is a way I didn't see. But I view issues having a direct connection potentially with any element in the system. Writing issues is one thing, having it tied directly to the class, usecase, scenario, component whatever has even more meaning. It is easier for me to establish responsibility. So If I have any diagram open, and I want to attach an issue, another possible tab on the properties would be "Issues". Then I can track them exactly with that specific element. The project mgr could ask for all issues. Or all issues associated with a UseCase and all of it's relationship objects, etc.

Dennis

[Steve_Straley]

Dennis,

Valid points and they would be nice additional features.  I know, for example, I've put in a request to add a To Do report and to have "to do" status levels modifiable... this, I think, would require additional table support for such items.   Back to the subject at hand, the ability to cross link an issue to a specific item, like a class or whatever, would be handy indeed.   But turning back to your original question, those are "specific" issues at a specific level whereas at something more general (like at the project level), the specificity (spelling) is not generally bound and thus, meaning is somewhat depricated.   I think the term "issue" like the word "tag" has all sorts of different meanings depending on how it is applied and where it is applied.   I'm not sure how this would be expanded and thus handled incorporating your great feature requests and the way it (EA) currently behaves.

I know for us, we use the term "issue" in a more general way applying to all things at the project level.  At least, this is the way I'm writing about it in my tutorial-in-progress <lol>.

Cheers,

Steve

[Anibal Rojas]

I did't found any Standard for such things as Issues, Bugs, etc... Have you see any reference to such thing?

It looks like an Issue is anything that must be tracked and solved in order to keep the project going on. So I think the only way is adding the " would require additional table support for such items" proposed by Steve... This way each one whould be able to decide what to track, and under which states.

And attaching Issues to everything is the way to let everybody decide where to attach them. My point here is that I need a central point where I can query the status of the Issues in order to know the status of the whole project.

Thanks for your interest!

[Larry Skelly]

About issues being related to objects... I spent a number of years as the architect of a commercial process management tool, that had a pretty mature underlying repository. We built a couple of tools that managed issues, changes, faults, test cases, releases, components, etc.  In essence everything in our repository should be an object, and with some limitations (that tend to shrink every time you look at them) an object such as an issue should be capable of being linked to any other object, for various reasons: sub-issue (containment), related issue (association), issue related to test case, issue related to change, issue associated with one or more artifacts,, etc.  The same is true for changes, faults, glossary items, resources, almost any object.

A model this abstract is more difficult to build, but is ultimately more powerful.

So it would be very useful to be able to attach a list of related objects to many objects, and navigate to an object with a double-click.