Unified Process and EA

[Nicholas Blumhardt]

Hi all,

obviously there are people out there using EA with Unified Process-type processes... Our company is about to undertake its first UP cycle using EA, and I'm looking for suggestions of how to best use EA with respect to the following UP facets:

* Iteration planning - can an attribute of use cases be used to track the iteration plan? (The phase attribute ) The IP needs to be pretty flexible and gets used a lot. Am I better off using Excel or similar?

* Model organisation - is there any harm in deleting each of the default views, and replacing them with 'Requirements View', 'Analysis View' etc. in line with the UP workflows? Is this the best way to go?

Any tips appreciated,

Nick

[Tjerk]

Hi Nick,

Some answers regarding your issues:

--- Iteration planning ---
You are able to use the phase attribute, but the tool does not really have any managing abilities for phases. This means that a Software Development Plan needs to be written to describe and plan phases.

--- Model organisation ---
The default views can be deleted without worry, as far as I can see, the default views concern only the icons used for the views and not any functionality.

--- The way to go ---
The way to go is depending on the outcome (deliverables) you want to deliver. Because of the tree organisation of a project, you have to make some choices. The way I did organise the project is purely based on the documents that need to be delivered (J-Std-016 / Mil-Std-498 in my case). This corresponds to phases like system requirements, system design, software requirements, software design, etc. This will be the same for UP, I guess. This results also in a tree underneath views & packages being the responsibility of one project, development group or analyst / developer.

If the target of the model is solely for code generation, the model will probably look more like the actual code organisation (modules, components, etc.).

--- Summary ---
My personal feeling is that EA can be customised extensivly and it will therefore fit many processes and deliverables. If you have more questions, please reply.

Greetings,
Tjerk

[Nicholas Blumhardt]

Thanks Tjerk,

I've decided to go with breaking up the model according to UP 'disciplines' - Requirements, Analysis, Design, Implementation and Test - I'm glad to hear that the tool will still behave. I made this decision because semantically a class diagram has different meanings in UP depending on the discipline producing it, e.g. a class diagram produced in Requirements is most likely a conceptual 'domain model' as opposed to a similar diagram that might be produced in Design.

I'll keep this thread up to date with my experiences in doing this.

For iteration planning, I might consider using the Automation interface to synchronise with an external (Excel, SQL) iteration plan if the need becomes apparent, but I'll start out by managing the iterations outside of EA and go from there.

Thanks again for your help,

Nick

[PhilR]

I have been using EA to quite happily model software life-cycle processes.  Why not model your Disciplines as packages and your phases as Another set of packages.  Activities can be used to describe instances of discipline activities performed within a phase or iteration. (Hope this makes sense.  See the OMG SPEM model for a meta model of life cycle processes).

You could then use the matrix function of EA (Project|Relationship matrix...) to cross reference use cases to phases.  Not sure about reporting though?

When a new project is created EA uses a "model project" as a template.  The default one that comes with EA has a standard set of views.  Nothing to stop you defining a UP "model project" and ignoring the standard one.

Hope this helps,
PhilR

[NickB]

Thanks Phil, I'll keep those ideas in mind- I've started out using disciplines as views, and the models as packages beneath them. As I go I'm sure to need to decompose further, so your ideas could help then for sure.

Cheers
Nick