Use of Enterprise Architect in a real project

[Knut Paulsen]

Hi guys,

I am a bit curious how you use EA on a daily basis. Consider the following scenario:

I kick off developers to work on Sprint 1.
I start working on requirements and use cases for next sprint, which includes changes to specifications for Sprint 1.
How do I avoid to confuse developers and keep my changes 'private' until we are ready to start sprint 2?

Cheers
Knut

[PeterHeintz]

There is not a best practice which fits in any scenario.
Do your developers just read the model or do they also change the model?

[Helmut Ortmann]

Hi Knut,

parallel developing of different releases isn't that easy with an UML tool.

One of the issues is that diff/merge isn't an easy task in daily work. In this forum you find a lot of enthusiastic discussions. This isn't only a tool restriction but a logical issue. It's just complicate and you can't compare a model diff with lots of relations and small entities with a text compare which doesn't care about dependencies to other text documents.

It will getter if you have a well defined use case.

Let's take your example: If you are just talking about use cases it's no big deal. If your Use Cases have a lot of relations with other things it quickly begins to get a mess.

To your answer: It's possible but....

Regards,

Helmut

[Knut Paulsen]

Thanks guys,

In theory, they should only read the model, but of course issues may arise which require changes to the model, which in turn should not interfere with the ongoing work for the next sprint.

It is hard for me to see how this can be accomplished within one EA project, so I am thinking of creating two EA projects for each project. Project_R is for requirements work and Project_D is for developers. When I am ready to start a sprint I create a baseline in Project_R, which I transfer to Project_D. Now, if some issue in ongoing sprint requires changes to the model, that change can be made in Project_D. However, these changes must of course be merged into Project_R at some point. Still have some research to do to see if that is feasible.

Cheers
Knut

[Helmut Ortmann]

Hi Knut,

If your changes during a sprint are just:

• Change of text, let say Use Case Text
• New Use Cases
• Renaming Use Cases
• Other well defined possible changes

I think it's feasible. It might be sufficient to export Use Case from one Model and Import it. You have to ensure that the sprint model is a copy with the same GUIDs.


Helmut

[Geert Bellekens]

Hi Knut,

I've seen it work in different modes.

The first one (which I like the most) is that we all use one repository with a mixed ASIS-TOBE model.
All work is Scrum/Agile/Kanban like organised in workitems (TFS) which have a number.(could be Jira, or internal numbers, doesn't really matter)
We use some kind of tagging to keep track of which elements in the model we changed for a particular workitem (number)
Using this number we have searches that show all the changed elements, and document generation that generates a document based on this search.

Our developers get he document, but also look in the model. Every now and then it happens that we are already analyzing the next feature while they are still developing the previous one. But in case of doubt the developer can always look at the document to find out what he is supposed to develop.

The other one is the classical waterfall/BigDesignUpFront way of working where we have Huge releases of the business analysis model which is then thrown over the wall to a team of functional analysts of a contractor who then proceed to make functional analyzes and send these over to India to get developed.

In this case we use two repositories. One where the next version of the business analyses is being developed, and one where the released version of the business analysis model is stored, and the Functional analyses model is being developed.

Geert