Handling pending changes

[lubos]

Hello,

I'm looking for some 'metodology' how to hadle process used in our company.
We have the following sequence of activities:

1) Customer requests some new features
2) A proposal (New/Updated UseCases + domain model is prepared) + the calculation of capacities ( = price)
3) Customer decide if he really wants it
4) The proposal is implemented and delivered

The problem is, that customer quite often decide not to realize requested changes and
that the implementation is done typically a few month after the proposal was made (we do two releases per year).

When creating a proposal it's very appropriate to use a case tool (EA) since it's desired for it.
But the model  serves as a documentation as well and this is not actual since it contains not yet realized chages.
It's very dificult to "remove" proposals decided not to realize from the model as well.

We found the merging between models not easy usable for typical user. We would use status indicators or some other system of tagging of pending changes.
But we often do proposals for the same usecase and some are realized and some are not. I'm afraid that any
system of tagging of pending chages will grow wild shortly.

So we do proposals as a word documents and when the proposal is confirmed it's modeled afterward. But we deprive of the advantage of case tool in creative work.

any hints welcomed

[MagnusH]

Hi,

We are in the phase of introducing EA in our organization and we have exactly the same questions. If you find any good solution please indicate how you did.

// Magnus

[nisha]

Hello

We are also having the same issues. Has anyone found a good solution?

Nisha

[Geert Bellekens]

I'm afraid there is no easy solution for this.
You basically have two choices:
- You learn to live with the fact that your model is a mix of the AS-IS documentation, TOBE documentation and some "Could have been but was never implemented" documentation
- You work with version control integration, branches, and all the merging overhead that comes with it.

Geert

[son-of-sargasso]

I'm afraid there is no easy solution for this.

Yes, and no.  There is no "easy" way to herd cats, but it doesn't stop us doing it.
Some moons ago there was a guy in these forums (who looked a lot like me but with much less grey hair), who kept saying "The model is NOT the system".  Again this is applicable here.
Firstly, I do not recall seeing any legislation anywhere that says there can be only one EA model of a system.  Like the photos of the kids, we take lots of them but only keep the ones we like.  Yes, it may be a bit disconcerting to throw out a particular photo of Jimmy-boy or Mary-lou if we spent hours designing and creating that particular fancy dress costume, but if the kid looks like (whatever) in it then....
So, every (any) time a new possibility for the system comes along, copy the model, play with it, dress it up, nurture it and if it becomes a nothing then throw it away.
Secondly, if it does become something (someone makes a decision to go ahead with the proposal) then decide whether or not the changes are likely to become a branch or are likely to become merged into the mainstream.  Branches are pretty easy to handle, they're actually a different system.
Save the "proposal" copy of the model with the proposal.  You'll need it later on!
Save the current mainstream model too.  Your support staff need it. Don't merge until the changed system becomes the mainstream.  (Why so many development organisations don't do this is totally beyond me.  I don't know how many times I've asked for the "specs" of the current implementation only to be told, "Oh, they've changed now for the new release".)
So we've now got a mainstream model and a proposal model.  The latter should only reflect the requirements for the changed behavior of the system and perhaps some POC structural engineering.  (Guideline! ymmv)  Now, build another model from the baseline mainstream model and the proposal model as the change model.  Clearly distinguish the changes using all those EA wizbang features like "Change requirements".  Mark all usecases, system artifacts etc clearly as unchanged, changed, added, deleted (N.B. Don't delete them from the model!) or whatever categorization suits you.  Enforce the traceability.  This model becomes the work order for the developers.
Thirdly, after the change project has delivered, "finish the paperwork".  Save the change model, merge stuff where necessary and properly finalise the project.  
"But doesn't this add overhead and increase costs?"  Well, think of it this way,  you can try to drive the car, read the roadmap, put on your makeup, answer the mobile and change the babies nappy all at the same time but in my experience stopping the car to change the kid is a lot safer for all concerned.
cheers
bruce

[son-of-sargasso]

BTW, on the topic of merging.  
I have found it a lot easier to use a combined approach to this in EA.  I move the merge items into separate EA packages (separate from the actual model structure packages I mean) , merge them via export/import, and finally move them into the "proper" packages in the target model.
I have not found, IME, that the XMI synchronization features result in "what I really want" in the target model, so I prefer this sanitized way of doing it.

bruce

[Oliver F.]

This all sounds so familiar to me

All those nifty modelling tools have not been created with iterating product development in mind. One can clearly state that Rose, EA, et. al. have been designed for maintaining project work in a fire-and-forget environment, with a limited lifecycle. Create a project, start modelling, agree on everything, implement it, test it, maintain it for a while, forget about it.
Products with an iterative lifecycle are not covered at all as the primary idea is to start a new project one after the other.

What you are requesting is typical lifecycle management with branching. Absolutely typical for product environments but not considered in most tools.
As your product evolves new requirements come in overlapping with the current work. So you would have to open a new "branch" with the updated requirements, update the existing ones and merge the changes in the HEAD if they become reality.
This gets even worse if the overlap covers several phases of current projects which would require more branches.

And as a conclusion I'd like to cite Craig Larman talking about lean development: "Branching kills". Which I find a totally agreeable statement. Well.

Oliver

[lubos]

Thanks for all replies.
I wanted to avoid branching and consequental merging but I understand it is the only possible/reasonable  way.
But there are another things to take into account.
Many people (developers particullary, analytics some times) hates this (UML) tools because they find them unnecessary...they know what to do, so why to document it ;-)
It's very difficult to persude them of doing it. We have also quite complicated environmet -- many EA projects connected with ClearCase where we have quite a lot of branches for source codes.
It is very difficult to hadle these branches for models too. And force the people to do a correct merge it's not possible at all :-) for me.
And project managers want to have a corect and up-to-date documentation.
The result is that we use the model for documenting purposes mainly and as a inspiration for new proposals, that are created outside the model (in Word documents as a "free" text) . Only when they are being developed it's putted into model in a formal way.

I will think about some compromise....

[Oliver F.]

Many people (developers particullary, analytics some times) hates this (UML) tools because they find them unnecessary...they know what to do, so why to document it ;-)
[...]
And project managers want to have a corect and up-to-date documentation.
The result is that we use the model for documenting purposes mainly and as a inspiration for new proposals, that are created outside the model (in Word documents as a "free" text) . Only when they are being developed it's putted into model in a formal way.

This is a common misunderstanding in software development and it is dangerous.
Developers tend to believe that they are the only important instance in the life cycle of a product as they are doing the ground works which leads then to the final product. This is wrong.
A project/product has multiple stakeholders and there are two purposes of documentation which are often ignored:

• Satifsfy the needs of all stakeholders
  
• Minimize the propability of future risks for the further evaluation of your product/project

Documentation is often seen as a budget killer in the development phase while ignoring the fact that it saves budget in the often underestimated maintenance phase and the analysis of evolutionary new features later on.
Documentation is an investment in the future. Besides the fact that a good analysis and design prevents from flaws and misunderstandings in the whole development chain.
Developers thinking the way you described must be made aware that they are minimising the overall benefit your company as a whole. It  reduces the focus of a complex environment to just delivering a product while ignoring the key part of todays industry: Delivering satisfaction to all stakeholders involved (customer, management, maintenance, developers, etc.)
Awareness about this is crucial today in the software industry- otherwise it is a risk to the whole company and its success. Documentation must be part of todays architectural risk management.

Oliver

[son-of-sargasso]

A project/product has multiple stakeholders

Oliver, you just said it all!

I don't know how many times it is that I have said to "young and brilliant developers" ,

"Your code is not the system, it's not the answer and it's not a baby.  Document it, stop crying and get over it."

(IIRC it may have been sometime in 1980's when I first said it and 30 odd years later it's still true.)

One day...

bruce

[lubos]

I think everybody here will agree.
Sometimes a compromise has to be done.
E.g.: You are short of time and people for some period ... in this situation coding is usually prefered  to modelling since there is no time to do both -- I know  you can do better code with modelling phase ... but everybody is lucky when any working code will be in time ;-) ...then the model is not up to date --> the model is not truthworthy --> the model is useless.
You try  to force people to update the model after busy period, but the model is not as good as when created in time of development.
...and this is a typical scenario in our company. :-/   and I believe its not much better elsewhere

[Oliver F.]

I know  you can do better code with modelling phase ... but everybody is lucky when any working code will be in time ;-)

In that case you prioritize "some code" over "quality code and overall satisfaction" which definitely fails to focus on primary goals and key factors of our business.
Because delivering code is not the primary goal in the software industry. Overall satisfaction is. Code is just a tool to get you there.
People usually fail to recognize this and define any code working somehow as the end of the chain. Being surprised about higher maintenance costs afterwards and reduced satisfaction.

Oliver

[beginner]

BTW, on the topic of merging.  
... I move the merge items into separate EA packages ...

Most likely the best approach. Though IT managers do not like the extra effort they have to pay now and prefer the hot-potatoe-tactics to move to someone-else's-budget (which again proofs the correctness of 42 as another form of someone-else's-problem).

b.

[lubos]

Yes I do agree and I'm not happy with that too.
It seems the speed is more distinguishable competitive benefit than the quality :-/  .. if the systems works "somehow" the difference in quality couldn't be distinguishable at all...