Model Change Management

[Stephen]

[Scenario]
I have a complete model of my system, typical n-tier browser viewed system.

I receive a change request from the business to alter some aspect.

I can model a revised version of the system.

How does the panel manage the change within the (overall) model?
I'm clearly going to want to retain the previous set of artifacts, and the new set - with a bit of context so I know why the change was made. Anyone got any ideas about how to merge by change set of objects into the base design?

Cheers!

[mchiuminatto]

If you have installed Microsoft Visual Source Safe you can achieve a version control with this product, so you will have the history of Changes.


If you don't have MVSS, you should try CVS, it's free and open source (I've never tried with this one)

Basically you have to configure the Version Control Options:

Menu:Project\Version Control\Set Version Control Options.
There you link to the version control software.

The you go to the package options: Package Control\Version Control Options, where you specify the file name and that is intended to be under version Control

Next, you save the package to a file (xml)

After that,  go to your Version Control Software and check in the saved file.

Finally get the package from the version contro via ES with the package option: Package Control\Get PAckage, it will show a pop-up with te packages controlled in your Version Control Software: after you get the package you will be able to check in, check out etc. from within EA .

Regards

[sargasso]

Stephen,

Is your question aimed at the technical issues, which Marcello has answered, or at the procedural level?

If the latter, then there are many ways to achieve a result.  

The way we are moving new analysts into UML thinking is to use "as is" and "to be" models of the system.  We encourage them to keep both models very separate at first so they do not modify the wrong one.

EA provides several great features to asist "logical" change management - of these we emphasize use of the Maintenance Menu items - Element Defects, changes, Issues and Tasks the most.  This lets us pre-model the changes to the existing system, discuss that work with the users and when the "release" has crystalised in scope we then create a new model using the existing model as a base and begin work on requirements, analysis and design.  

Another feature we use is use cases stereotyped as <<changecase>> which highlights the impact of a change on the business use of the system, and provides a context point (in the 4+1 paradigm) for the changes to the system that will occcur in this cycle.

Finally, do not underestimate the use of the Phase and Version attributes in EA - they can be used in many of the reports and utilities to filter appropriately to the elements of interrest to a particular release.

hth
Bruce

[Stephen]

Very much thinking along the procedural level.

I was looking at creating an independent model of the changed system (the "to be" case), but then wondering how to manage that into the overall system model - or back out again if the change was reversed.

Bruce - you've lost me a bit with the reference to a "4+1 paradigm".

I'm not sure that using the EA attributes is going to help me manage my system model - though I accept the usefulness for reporting.
Do you ever re-cast your use-cases from <<changecase>> to ordinary use-case once the feature becomes part of the base system (??). Sound like you make a new model and swap over as opposed to a merge style operation.

I wanted to come up with a process that would help me manage "small" localised change within the context of a much larger model.

[Rob_M]

An idea I had for managing small localized changes involves a bit of manual object creation but it has the benefit of keeping the changes local.

Suppose you have a requirement object (or other object). If you want to make an incremental change to this object, but maintain the old old version consider first creating a copy of the object with Edit->Copy.

Then paste the object with Edit->Paste->as New
Give the object a new name with a suffix such as:
RQ-0015.1
Delete the object from the diagram.
In the Project view drag the RQ-0015.1 on top of RQ-0015.

Once you've 'backed up' your current copy of the element, you can now make changes to RQ-0015 to reflect the new mod.

Subsequent incremental mods can be numbered RQ-0015.2, RQ-0015.3 etc.

In this way, you have all your old versions of RQ-0015 by expanding the '+' in the project browser for RQ-0015 similar to a version control system.

It is very manual, and could be prone to error, but it keeps your old versions of an object in local proximity to the current one.

Not sure if that helps, but it was just an idea I was playing with. I was considering an ActiveX plugin to automate this process, but haven't got around to it.

Rob_M

[Stephen]

Good simple idea with the renumbering - I'll have to come up with something similar. I want to try and extend the idea to cover sets of artifacts (and possibly their associated diagrams)

I also need to adopt a naming convention for my model artifacts. I end up struggling for names when trying to tie together all the particiapants of an interface from database to presentation layer.

Sounds like merging into a "master model" is always going to be rather manual....

[gartone]

The procedural aspect of this is of great interest to me. I would like to solicit feedback on the way we are planning to handle our SDLC.

First, let me give you a picture of what we have now. We have started using EA Enterprise and utilize a SQL server shared repository for all projects. We have modeled all existing production applications in our domain using the iconix process. The main artifacts we have are requirements, domain model, use cases, robustness models, sequence models and implementation models.

We are planning on using the "as is" and "to be" notions as well. For example, when development of a new version begins, we plan to make a new copy of the production node and set it next to production.

--app name
               |-----v.1
               |-----v.2

You get the picture. This is only the case for major releases.

We plan to manage point releases differently. As part of our cm we will use version control software to capture every release, both major and point. In addition, we will encorporate the incremental changes of the point releases into the production trunk represented in EA.


--app name
               |-----v.1.1
               |-----v.2

The deltas in the models will be managed with a re-naming strategy similar to one described by Rob_M. The reasoning is that the maintenance team needs to know the current state of the software. The team working on the next release needs to incorporate fixes from the point releases into their version's design. We make it the responsibility of the team designing the new version to make sure that all fixes are represented in their model and tests.

As a major release occurs, we will archive the old production model off as an xmi and store it on a file system for quick reference. The version of the software that was just developed will now be the production version. If the next development copy has not already been created for the next major release, we will create it now. Most likely this will have already happened toward the end of the previous versions development cycle. We would end up with:

--app name
               |-----v.2
               |-----v.3


Does anybody see any flaws with this strategy? Does anybody have any suggestions or lessons learned in this area?

Regards,

Jay