Ring. Hat. Toss.
See, now that's interesting. I see it a little differently.
In my view EA is an enthusiast's tool -- not a professional's. In order to make good use of EA you need someone in the organization who knows the ins and outs of the tool. It's not enough to know the modelling language.
EA is a toolkit. It's a rag-bag of features that don't work well together, and which sometimes are different attempts to implement the same functionality. Unless you intend to work only within the tool, it comes with nothing to help you in any given usage scenario: no usable project setups, model structures, or document templates. What's there is all demo-level stuff. On the IT side of things, EA integrates poorly and clunkily. And even the extension mechanisms are limited: you can access the most basic functions through the API, but only a very small number of the high-level ones.
Navigating this quagmire requires deep insight, which must either be built up within the organization, or purchased from a third party. All of this makes EA a far more expensive tool to use than the purchase price would suggest.
......
What he said. But in my opinion, i think the first step in making EA less of everything above (to those outside Sparx) and more like the tool Sparx thinks it is, requires no code changes, and while it is work, is pretty simple in concept.
Publish a user manual.
All we have now is documentation, which is not the same thing at all.
Also it is mostly auto-generated documentation - I know, i actually tried to read it. It is 10x the size of the source, due to pointless repetition. Worse, the current documentation is useless unless you know what you are looking for, and why you need it, which is also the opposite of documentation. I often find myself in bait-n-switch circular link references which only cost me time and tell me nothing. So i have to come here, go to google, or flail around aimlessly in a multiplicity of options pages, which then send me back to the bait-n-switch....
Anything else, no,
everything else, becomes easier for everybody with a manual, because EA will then be used by everybody in approximately the same way, which is also the as it was designed to be used. Hard coded 'Magic Number' ENUMS (such as Project Task/Issue status fields) should then make sense, as the reason for them, and the workflow they automate is clear. Bugs and feature requests are on point and in context, feature overlap is explained, or at least mitigated. Example documents and templates can be made useful out of the box, Less duct-taping hacks together to make primitives/out of the box things work the way you think they should, rather than the expected usage. Whitepapers are just documents laying out a particularly clever hack, and do not count as manuals IMHO.
Sparx has to do this. All the community can do without this is reverse engineer intent, or overlay/hack in out interpretation of intent.
