Here's the biggest tips I could give anyone starting to use EA on a real system.
[glb]1) Decide early and clearly what your reasons for using the tool are![/glb]
To me there are three general ways you can use EA (or indeed most of the good UML tools):
As a power tool- A repository based approach (method) is fundamental
- Use all the tool's features - avoid having external (unintegrated) utilities such as issue logs, change logs etc
- Documentation is secondary as it is a snapshot of the analysis or design at a particular point
- The repository is an asset of the system, not the project, and as such must be treated with the proper respect.
As a craftsman tool- System design remains bound to external documentation
- Use the majority of the tool features to design the document content
- Don't expect to glean the benefits of re-use - it wont happen in a document bound methodology.
As a handyman tool- Uses a limited set of the tool's features
- Analsysis and design information is still in documents
- IOW, the tool is used as a drawing tool only
[glb]2) Decide what the scope of usage of the tool will be[/glb]
Information Gathering, documentation & review - Requirements
- Design
- Logical and technical
- Software and data
- Architecture
Maintenance & EnhancementTestingProject Management[glb]3) Define a suitable repository structure[/glb]
(This bit relates to the original question)If your intended use is focussed more towards "power tool" use and/or wider scope, then spend a good deal of time determining the proper structure for your teams' use of the system. (or hire a good process consultant - I could name one in particular
)
The structure you pick should be built with one idea in mind - communication of the analysis and design decisions. Don't worry about getting the structure "right" for the tool users only as it is covered by the last tip below
Provide "work in progress" areas for analysts and designers to use informally - i.e. as scratch pads while they analyse and design. Once the team has agreed that a model component has been adequately worked, move the elements into the formal model structure. IOW:
[glb]4) Dont use the formal structure branches as a working area[/glb]
I have been using EA for over three years now, as my preferred tool. Each client I work with has their own formal model structure, developed (albeit from a general model set) to suit the particular culture of the organisation concerned and the level of formal communication needed for system decision making. Indeed one of the strengths of EA is the ability to set up a tailored structure - my current client has had me working on the repository structures (amongst other things) for the last 4 months. We use several "starter models" dependant on the technology of the system involved (desktop, internal multiplatform, web app, etc) So even within an organisation it is possible that more than one model structure is viable/needed.
Given that the organisation is "large" and much formal communication is necessary in the majority of projects - we have based the structure on the traditional IT development phases: Requirenments, Analysis, Design, Implementation - as in this case there are viable reasons for keeping such models separate.
Good Luck!
Bruce
