Baselines

[Modesto Vega]

Could somebody please point in the direction of some good resources on how to manage Package Baselines?

Thanks

[PeterHeintz]

What do you mean with how to manage package baselines?
What menu items you have to press, or what are package baselines typically used for and on which package level,…?

[Modesto Vega]

What do you mean with how to manage package baselines?
What menu items you have to press, or what are package baselines typically used for and on which package level,…?

Not too worried about menu items, I am after best practice guidance: how to structure a complex project? how many pacakges? any issues with using packages within packages? how to lock previous baselines? and so on.

[qwerty]

YMMV

A model represents a current view about a system, i.e. how people think it should develop in the future. Baselines are about the past. Nobody is interested in the past state of a system. So what could a baseline be used for? I can imagine only one use case: "Uh! We ran into the wrong direction the last months. Let's start over from this and that baseline". If you have the money to independently branch a baseline and develop those lines to finally select the best one (remember "A Novel About Project Management." by Tom DeMarco?) that would be also a use. But that's fiction.

q.

[PeterHeintz]

Ok!
But a view people unfortunately are forced to be interested in the past as well.

We baseline some well-defined higher level packages (requirements package, architecture package,…). Those packages can have deep package levels underneath but element references (classifiers, associations,..) are only allowed to a defined set of other “higher level packages.
The baselines are used to prove what state of the packaged was e.g. verified and to analyze what has changed, because we have to provide change details, once a product is shipped (safety related stuff).

Another use case is to baseline “the View Package” where all our stuff of a certain system level is in. This is because we have “another View Package” where shared model stuff is in (some kind of read only Library).
Before we update to a new Library version, we baseline “the view Package” and the current “another View Package (LIB)” (just to be able to go back in case of disaster), afterwards we switch to the new Library Version and then we restore the baseline of “the view Package” we created shortly before. By doing so, associations added from our model to the old library version will be kept (hopefully in any future version of EA).

[Modesto Vega]

YMMV

A model represents a current view about a system, i.e. how people think it should develop in the future. Baselines are about the past. Nobody is interested in the past state of a system. So what could a baseline be used for? I can imagine only one use case: "Uh! We ran into the wrong direction the last months. Let's start over from this and that baseline". If you have the money to independently branch a baseline and develop those lines to finally select the best one (remember "A Novel About Project Management." by Tom DeMarco?) that would be also a use. But that's fiction.

q.

Baselines are not just about the past, they are also about the future. If you have an As Is architecture to be transformed into a To Be architecture. The As Is architecture is a baseline as they will be any intermediate architectures before the Target architecture is reached.
In this respect a baseline is essential to understand the impact changes are going to have in the baseline.

[Modesto Vega]

Ok!
But a view people unfortunately are forced to be interested in the past as well.

We baseline some well-defined higher level packages (requirements package, architecture package,…). Those packages can have deep package levels underneath but element references (classifiers, associations,..) are only allowed to a defined set of other “higher level packages.
The baselines are used to prove what state of the packaged was e.g. verified and to analyze what has changed, because we have to provide change details, once a product is shipped (safety related stuff).

Another use case is to baseline “the View Package” where all our stuff of a certain system level is in. This is because we have “another View Package” where shared model stuff is in (some kind of read only Library).
Before we update to a new Library version, we baseline “the view Package” and the current “another View Package (LIB)” (just to be able to go back in case of disaster), afterwards we switch to the new Library Version and then we restore the baseline of “the view Package” we created shortly before. By doing so, associations added from our model to the old library version will be kept (hopefully in any future version of EA).

Thanks Peter I will explore and feedback on this thread.

[qwerty]

Baselines are not just about the past, they are also about the future. If you have an As Is architecture to be transformed into a To Be architecture. The As Is architecture is a baseline as they will be any intermediate architectures before the Target architecture is reached.
In this respect a baseline is essential to understand the impact changes are going to have in the baseline.

I have just posted in a similar thread why this wont work. I'll have a look later to find it.

q.

P.S. Courtesy of Peter who found my post, here it is: http://sparxsystems.com/forums/smf/index.php/topic,30347.0.html