Hi,
Thanks for the response.
You can look into the auditing feature if you're after change traces. It's easy to use and proven but (DB) memory consuming. Also you can also look into package snapshots (Package control context menu).
I recently had auditing set up to check who, what, when, etc.. that sort of thing as it had not been configured before. However, from my second question in my initial query, we are looking to trace the LOGIC contained in elements e.g. the logic of an old use case being broken down into the logic of 3 or so newer (smaller) use cases.... and then being able to show that the new use cases are an abstraction of the old. Is this doable with the auditing facility you have mentioned?
Also:
- connection to version control
- regular backups
- HTML exports
- Generated documents
Anyway, the idea is that a model only represents one single version of your system. Never try to keep multiple versions of the same object in the same model.
Geert
For the other "versioning" techniques, we have in place DB backup already and I recently set us up to start using Baseline snapshots. We do generate reports for use with various stakeholders. I have not done version control such as SVN as I read somewhere on this forum that it is not ideal in the least with Sparx. I have no idea what HTML exports is but will look into it.
I agree that it would be ideal to have one single version of the model, and that is what I am trying to work towards. Unfortunately the challenge I have run into is that the previous model setup literally has no structure. Everything was dumped into a single view with a couple of packages that are either incorrectly named (compared to their contents) or is a mixture of "LIVE elements", "experimental elements" or "deprecated elements" WITHOUT the appropriate labels/tags to make the distinction. Only a few old heads who have been with the company long can tell the difference, so tracing what is "LIVE" today is proving non-trivial; Unless it is just my lack of familiarity with Sparx EA??.
The transitional plan so far is to allow multiple versions of objects in the same model using three views for separation of the versions
- old/former model view (containing all the folders of the elements as they exist today)
- future solution view
- current solution view (with restricted access)
Versioning of elements would follow the path:
a) ----> Elements in the
former model view that are required/impacted in the next release are cloned into the
future solution view for the design modeling tasks
b) ----> Once signed off, the approved release elements are promoted to the
current solution view on deployment
c) ----> for the next release, the "current release" in the
current solution view folder is cloned into the
future solution view and designed as appropriate. However, if an element/diagram that is required in this future release is not in the package, then it will be cloned from the
former model view...
the process is repeated
It is worth noting that a release does not cover the entire end-to-end system processes but I have been made to understand that after about 6 iterations of this process, all the LIVE elements will have been impacted at least once, which means I can then have a "FULL" current solution at that point. and I can then retire the former model view and move the current solution into a separate model or view.
It is also worth noting that trying a bottom-up approach i.e. getting to grips with the physical model is non-trivial too; because delivery of the solution is via a 3rd party company, hosted on another 3rd party private cloud and any request for documentation results in no less that 2000 pages of gibberish. I am also working to change this.
I am happy to hear any alternative approaches that may ease my predicament. But so far, this is the planned course of action based on what I know about the tool so far.
Regards,
Shapirho Modisha
