Asking for your opinion about managing a UMLmodel

[manfredw]

Hello folks,

I'm modelling a project that has to be delivered in slices.
Each slice must contain a detailed specification model, design model etc. of one part of the final software.

The problem is that the slices have been decided arbitrarily across the whole model and many elements, diagrams etc. from different slices are referenced in other slices.

When generating the documentation for one slice I run into problems because I cannot document just half of the dagrams etc.
Imagine a use case diagram with 10 use cases but only 3 of them are part of the slice. these use cases have their scenarios, activity and sequence diagrams, links to the requirements etc.

I wonder whether some of you have experience with large scale clustered projects like this and how you have mastered their organization and especially the documentation!

looking forward to reading you input!  
cheers,
Manfred

[qwerty]

Is there a reason for cutting the project into these odd slices? I'd rather organize the project so each single part is as self-contained as possible and has clear interfaces. That way you can setup the model more "logically" than - as it seem - "randomly". I hope it isn't you, but I'd kick the system architect into his/her ass.

q.

[manfredw]

hello qwerty,

you're right that's the way I usually organize my models.
Unfortunately for this project these slices have been imposed by the commercials, due to some weird market rules with the customer.
 
The problem is that the model has been organized and the general specification been done before the slices were decided. Even worse, some of these slices are modified on the fly... and they expect the documentation to follow these changes...

[qwerty]

Well, I know what you're talking about. So all I can say is: Good Luck.

The only promise I can make: the project will run out of budget and schedule. In Germany we say: they bridled the horse from the back.

q.

[Robert Sheridan]

I have experienced a similar nightmare scenario with constantly changing releases which had to delivered as Word documents.  It was very difficult to come up with a satisfactory solution.  The techniques I used are as follows (apologies, it is very difficult to describe succinctly and accurately):
1. use virtual documents to generate the specification for each 'release'
2. create features with all their associated use case, requirements etc. underneath them so that they can be moved as a unit.
3. use change elements to record how a future release will need to change a feature scheduled for a earlier release so that you do not have to unpick a use case if the release order changes after you have done the analysis
4. update use cases etc. in line with the change elements only when the use case etc. has been committed to a release.
5. you can also use diagrams as the source for RTF file generation, thus you can create a release folder with diagrams for each part of the specification and drag on to the diagrams the use cases from wherever in the model.
6. use the status and version properties to identify elements that have been implemented
7. I moved the features from a project area to a release area and then into a live area or a backlog.
8. we also used a additional mapping, e.g. services to features, so that we could generate alternative views which did not give the detail (which was in a master document) but listed all the features, regardless of release, which were needed from the selected view point.

Hope this helps.

[manfredw]

Hello Robert,

Thank you for your input!
I'm working with master documents for each release as well.
Your suggestion with multiple diagrams is fine as long as you only show the diagrams or list, say the use cases. But I did not find a way to list the elements connected to these use cases unless they are physically in the same package.
 
It is very interesting to see you have used changes. Could you please explain a bit more in detail how you do that?

thanks in advance!
cheers
Manfred

[Geert Bellekens]

We use some kind of custom tagging to keep track of the elements (and attributes, operations, diagrams, etc...) we change for a specific issue (issues are managed in TFS but without connection to EA)

We have defined an SQL Search that will return all elements that have been tagged for an issue

We use our custom document generator generate a word document. This document generator allows us to choose and pick elements to include, starting from our custom searches.

Geert

[Robert Sheridan]

I am working in an environment where I need to keep the techniques used to the standard GUI functionality rather than using SQL etc. (which I suspect gives a much slicker solution).

I have created stereotypes for changes etc. so that we can capture additional information against them in  a structured way.  The way we use changes is a cludge: they literally describe how an existing use case needs to be changed to meet new requirements and the new requirements are placed under the change until such time as the use case is updated when they are moved under the use case and there is the option to archive or delete the change.

[manfredw]

Hello Geert,

Thank you four your description!
I created some tagged values for usecases and requirements that correspond to the "slices/release" but I find it very dificult to keep all these tagged values up to date and coherent.
Let's say you have a usecase UC1 tagged with release R1, the UC realizes one requirement REQ1 which will be tagged as well to R1.
When generating the doc, all is well.
But what if REQ1 is realized as well by another UC2 which is part of the second release R2. When I generate the doc for R2, I will have a missing REQ1. Ok I could tag it R2, but in this case it won't be part of R1 anymore...  

one more question Geert, can you launch an SQL query or a ModelSearch for a specific Package only, or does it look always in the whole model?

Hello Robert,
Thanks for the explanation, I'll have to study that a bit more in detail. So far I never really actively used changes.

cheers
Manfred

[qwerty]

...but I find it very dificult to keep all these tagged values up to date and coherent....

Sure. That is one price you have to pay for a system which is designed badly. Blame the guys that were responsible for that. Make clear that now you have the extra effort (there will be more than just keeping tags in synch). Still: good luck.

q.

[KP]

When generating the documentation for one slice I run into problems because I cannot document just half of the dagrams etc.
Imagine a use case diagram with 10 use cases but only 3 of them are part of the slice.

Would diagram filters be useful here? You could show the diagram with the irrelevant use cases greyed out. The question would be what property you filter on: perhaps you could use an element's Phase to hold the name of the slice that it belongs to.

[manfredw]

qwerty, thanks I guess I really need that - LUCK ...  

Hello KP,

Yeah, that's a good point, but unfortunately that does not solve the problem I described above to Geert (eg requirement that is realized in 2 different slices).

Is there a way to use diagram filters in an rtf template? I mean define a specific filter for each rtf template so that you don't need to define it manually before generating a doc?

cheers
Manfred

[OpenIT Solutions]

I think diagram filters can be used to help when something appears in multiple "slices", we for example use a comma seperated list of releases that an element applies to (ie R1, R2 etc) and a filter that will hide elements that don't "Contain" R1 or R2 etc.

[manfredw]

Hello OpenIT,

The idea to use a list of releases is very good but how do you manage to "hide" some elements on a diagram in an rtf template?  :-?

Manually, I know I can use the Diagram's context filter to highlight some elements of the diagram, but how would that work in an RTF template?
I really would appreciate if you could explain that in detail!  

thanks in advance and best regards,
Manfred

[Robert Sheridan]

I have never used it but I believe you can use search conditions when generating a RTF so you could run the report against the whole project just pulling out elements that meet the search condition.

I suspect that you need to take a step back and review your SDLC method so that you can identify what element properties you use and what additional tags you need and the related code sets for each tag / property.

If you can stick to using only properties then there is bulk update facility in EA which you can run at the package level by right clicking and selecting package control> update package status; otherwise you are back to using the automation interface or SQL to do bulk updates (I have done it by using the automation interface to output to a spreadsheet where I make the changes and then reimport).