Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob_M

Pages: [1] 2 3 4
1
Suggestions and Requests / Re: 5.0 RTF templates
« on: June 02, 2005, 05:48:32 pm »
I second this list.

Especially bullet 2.

If we could somehow attach a template to a package, then use that template to generate the documenation for the package that would be great.

In this way, if I place requirements in one package, GUI layouts in another and class diagrams in a third I can format them differently.




2
Suggestions and Requests / Color Highlighting of Requirements and Issues
« on: August 09, 2004, 03:51:00 pm »
Nice touch on build 733 with the color coding for requirements and issues based on their status.

Can I have it for all UML element types?  ;)

Rob M

3
Suggestions and Requests / Re: Update Realized Interface Methods?
« on: January 27, 2004, 05:20:43 pm »
Delete the generalization relationship between interface and the realization class, then re-establish it.

Somewhat painful, but still easier than doing it by hand.

4
I find that forward engineering to a tmp file, then editing with gvim (wayyyy faster than emacs  :o ) then reverse engineering is faster than using this interface.

Rob

5
Suggestions and Requests / Re: Embedding Gifs/Jpgs etc.
« on: March 30, 2004, 08:20:40 am »
Thanks a bunch Bruce, thats exactly what I was looking for.

(How much is Geoffrey paying you?  ;) )

6
Suggestions and Requests / Embedding Gifs/Jpgs etc.
« on: March 29, 2004, 04:32:00 pm »
I would like to see a capability within EA that would allow the embedding of pictures of various types into the RTF generated documents.

As an example of how this could be generated, consider a new object type in the Custom drawer called "Picture". By dragging in the picture to the diagram, a box, much like the 'Screen' object appears.

Next, in the "Files" tab, we enter in the name of a file that represents the picture. When the RTF documentation is generated, the generator observes that the object type is picture, then pulls in the file representing the picture into the document.

In this way 'pictures' that describe interfaces, algorithms etc. could be embedded in EA generated documents.

Rob M

7
Suggestions and Requests / Re: Be able to change activity to a sub activity
« on: February 12, 2004, 03:19:42 pm »
Sweet, Thanks Jesse.

Rob

8
Suggestions and Requests / Be able to change activity to a sub activity
« on: November 21, 2003, 02:35:35 pm »
When creating an activity diagram, I would like to be able to change the type of an activity to a sub-activity, thereby adding in a linked diagram.

I expected such a feature to be found in Element->Change Type, then selecting sub-activity from the pull down menu.
Alas, sub-activity was nowhere to be found.

Rob

9
Suggestions and Requests / boundary stereotype
« on: February 07, 2004, 02:38:32 pm »
It would be nice if we could specify a stereotype for the use case boundary. It appears this is the way iterations are specified in sequence diagrams.

In this way we could simulate branching, sequence diagram referencing, and looping using boundaries on sequence diagrams with the stereotypes of alt, ref, loop as per UML 2.0 specification.

10
I hear what you are saying - I had to hand craft the order for a document I was generating.

You might also try using the automation interface to select the things in the order you want. Check the online stuff here:
http://www.sparxsystems.com.au/AutIntVB.htm


11
You might try taking a look at the report view. (View->Report VIew) Then click on the column you want to sort by.

Unfortunately this only works for modelling elements on the current diagram, not on elements in a package. I've already asked Sparks for the equivalent of report view on a package level.

Rob

12
Suggestions and Requests / Re: Requirements Management
« on: December 15, 2003, 04:15:23 pm »
Sparx has decided to extend the UML with some custom elements like Requirements, Test Cases, GUI Elements,  Issues.

The packages in the project view can be used to create a hierarchical breakdown. Of course that hierarchy can be anything you wish, however, I think most would agree that a breakdown into various subsystems works quite well. This is not so different from hierarchical breakdowns in pure requirements based tools.

Traceability can be achieved by linking the requirement to another object - perhaps a test case, perhaps a use case, perhaps a GUI element, perhaps a software component. This trace can really be any stereotype link (even your own), but we tend to either use a 'trace' stereotype, 'derived' stereotype or a 'realize' stereotype.

The trace can be drawn in diagrams thereby giving a graphical representation, or the trace can be performed simply by linking one object to another from the project browser - the diagram does not have to be present to create a link.

Links between the objects within packages can seen with the relationship matrix view from the view menu. One can place requirements along one side and test cases along the other, then it can be easily determined by observation that all requirments have an associated test case. (Although it would be nice if one could filter on elements that do not have a link -  AFAIK this is not possible.)

Unfortunately, the relationship matrix can only show direct links but not indirect ones. For example, if some use cases are linked to requirements and these requirements are linked to test cases, I can't place use cases on one side of the matrix, and test cases on the other and be able to observe the the indirect links through the requirements. This would be nice to have especially if one is deriving functional requirements from user requirements, and you want to see if all of your user requirements are addressed with test cases.(DOORS can do this indirect tracing.)

That's pretty much in a nutshell how one can use EA to manage requirements, and do tracing to other elements.

Rob

13
Suggestions and Requests / Re: Requirements Management
« on: December 12, 2003, 01:52:19 pm »
Hi Gil,

RM in EA is something we have spent a good deal of time looking into. We have EA and DOORs inhouse, and have looked at DOORS/Analyst, Caliber RM and iCore as possible replacements.

We generated a number of criteria to consider in tool selection and have found none of these tools really meets all criteria.

So, to answer your question - "Can it be done?" I think the answer is yes, especially when considering the #1 requirement management tool in use today is MS-Word, and the #2 is MS-Excel.

The weakest aspect of EA in our search criteria lies in version control, and identification of requirement deltas. Often in the course of developement, a set of requirements undergoes an evolution of revisions. In EA, (at least to my knowledge) there is no way to look at a single requirement and easily query what it may have been a couple of versions ago. Moreover, there is no way to look at a complete set of two requirement baselines and determine which requirements have change in the complete set.

It is true that XMI versions of a requirements package can be stored in a revision control system, but it is not  trivial to determine the difference between the two.

EA does have some nice feature though that other tools do not. First and foremost is its price. This should not be overlooked since the cost of placing a DOORS or Caliber RM product on everyone's desk is quite prohibitive. This may hinder accessibility of the requirements to the people within the organization. We are a 30 person organization. Placing DOORS on everyone's desk is around a $75000, whereas placing EA on everyone's desk is only about $3000.

When considering this price difference, you can begin to consider customizing EA onself through Acitive X plugins. With that in mind I am considering hiring an intern to build a requirements delta tool that looks at two configuration managed XMI versions. I can pay this intern for 2-3 years to develop this feature for the price difference.

One of EA's strong points is in traceability. Most requirement tools have traceability features, however, the elements that you are tracing the requirements to must be available within the tool. So for example, if you believe that requirements should be traced to use cases, and your requirements tool does not model use cases very well, then you have to create some sort of placeholder for the element you are tracing it to. This is probably such an inconvenience that it ends up not being done, unless your organization can afford some QA police to ensure that it does.

Since virtually all elements that one would wish to trace to are within EA itself, tracing is much easier. Those like ourself grasping towards SEI CMMI level 3 can appreciate this feature.

Another feature we find very useful from an RM perspective is the GUI mockup capability within EA. If your organization is involved in some way with GUI development, you can mockup a GUI, and link requirements to elements within the GUI. A requirement such as "There shall be a means to control the lights on a vehicle" can be connected through a realization link to the GUI button that performs this function. Requirement management purists will argue that this is more GUI design and should be separate from requirement elicitation, however, our experience has been that the process of GUI design space exploration goes hand in hand with requirement elicitation.  Our customers also relate to a GUI mockup much better than a bunch of 'thou shalls'.

Hope that helps.

Rob

14
Suggestions and Requests / Re: Request: Relationship matrix useability
« on: October 14, 2003, 06:28:24 pm »
And although this has already been stated, it is a feature that I think multilple people would like to see and that is the ability reduce the selection by matching on stereotype.

15
I would like to see separate fields for the short description, and auto-counter naming.

If I want a short description in addition to the auto-counter naming, they get combined.

This makes their separation a bit of a pain in automation programs as well as their appearance in diagrams. (Somtimes the Auto count is on a line by itself, while other have the first work along with the autocount on the same line.)

Pages: [1] 2 3 4