Author Topic: UP/SPEM modeling in EA  (Read 1216 times)


  • EA Novice
  • *
  • Posts: 5
  • Karma: +0/-0
  • Wibble, Wibble, Fish
    • View Profile
UP/SPEM modeling in EA
« on: January 18, 2004, 08:18:35 pm »
I've been working on modeling our development practices (based on UP) using the SPEM profile provided by EA, and was wondering if there are any "best practices" :) out there.

My main objectives are to provide an easy way for us to document and later find "how to do things".  This means I want it easy to add/alter WorkDefinitions, and at the same time make it easy to navigate and find information in the area of work the developer is currently working in.

I found the examples with the SPEM profile did not provide what I wanted so I've played around a little.

This is what I came up with. Any comments would be appreciated, especially as I'm new to a lot of this.

This is an example of the package structure I'm using. Points of interest:
the leaf nodes are WorkDescriptions (UseCases) which can contain a diagram and any elements specific to the description. Activities can be very simple and only contain text in the notes of the activity.

I package every WorkDescription. Several reasons for this. Better documents (headings) and composite WorkDescriptions (easier control of default diagrams if everything is packaged seperately!).

Note, the default diagram for a package will be the diagram for the WorkDescription within it.

The standard diagram for a WorkDescription follows this format:

Points of interest:
I add the WorkDescription for the diagram to the top left of the diagram. As well as a reminder of what the diagram is about, it can show any Roles or WorkProduct involved and provides direct access to any information within the element (notes, relationships etc)

The rest of the diagram is flexible, it could be based on other WorkDefinitions, state diagrams etc.

Other things:
I put all the Roles in a Roles Package and all the WorkProducts in a WorkProducts package.

I have ProcessComponent packages to store other disciplins. These could include "Using EA/UML", programming tips in "Javascript", ".NET" etc.
This is so the processes are directly findable and can be pulled into other processes as required. A example would be that any UML Diagram based workProduct would be linked to the "How to..." WorkDescription on that type of diagram.

I think thats enough for now  ;)