Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - gartone

Pages: [1]
1
Uml Process / Re: Anyone recommend a good analysis book?
« on: March 09, 2004, 01:26:18 pm »
I just finished reading "Applying Use Case Driven Object Modeling With UML". I believe this is the book that JourneymanDave is referrencing. ISBN:0-201-73039-1. The book is relatively small, 153 pages, but is packed with practical examples and direction. The book shows how the robustness analysis helps you improve your use case text and identify all objects for your domain model. It does cover Boundary, Control and Entity discovery and usage.

Regards,

Jay

2
Uml Process / Re: Model Change Management
« on: March 09, 2004, 02:20:49 pm »
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

Pages: [1]