Recommendations for file with many packages?

[bockfu]

I am on the verge of starting a new project and plan to use version control to enable multi-user collaboration of the eap file.

My question relates to what is the recommended package layout?  Is there a single best-practice or is this comperable to 'branch policies' where there are many valid practices, each having pluses and minus?

For example:

Given two complex software components to model, should packages be split by models or components?

Model approach:

+ Requirements Model
   - Component A
   - Component B
+ Use Case Model Model
   - Component A
   - Component B

Component approach:

+ Component A
   - Requirements Model
   - Use Case Model
+ Component B
   - Requirements Model
   - Use Case Model

In general the approach I plan on taking is to start simple and add the complexity and component scoping when necessary.

Any recommendations or pitfalls to watch out for?

[Geert Bellekens]

I think, from a usability point of view (independent of version control considerations) the first option is best.
It will allow you to more easily spot similar requirements, usecases,.. since they are closer together.
If they are hard to spot (like in the second option) that might result in a lot of "double" elements since you didn't see that a similar thing, that can be reused by two parts already existed.
Another consideration is the fact that some elements are "transversal", in other words, they are valid for multiple components. (the higher up the chain you go the bigger the chance of seeing those). Trying to "force" these type of transversal items into a component structure might be problematic.

If you purely look at version control ease of use then the second approach is easier since you can checkout a whole component at once (if you wanted to).

In any scenario, the key to getting version control to work in a multi-user environment is to keep the packages as small as possible. This to avoid blocking each other when working on the model.

Geert

[bockfu]

I am leaning towards option 1 for the reasons including the ones you stated.

After time there will be component specific Class or Data Models, but it all starts with the business process & requirements.  At time zero there are no components.  Adding the concept of 'component' is forcing the documentation into a box determined by an implementation.

Thank you.

[AndyJ]

Sorry to add to the mix, but we've decided to go with your option 2. This allows the two "component" teams to manage their own version control at a higher level.

I'm planning to also maintain a separate Master project file that with be version controlled with input from the two component projects.

Another one to watch out for... Make sure that any packages that you version control have unique names...

Otherwise you can overwrite component 1 Requirements package with component 2 Requirements package etc.

This can be managed through careful selection of file names, but looks brittle to me, so we have C1 Requirements as a package, and C2 Requirements as a package.

[Paul Lotz]

My way of looking at it is that I need to have a requirements package, a use case package, a statemachine package, and a detailed model package (for example) for each set of functionality.  What is important is that I control each of these packages.

Then at the .eap (project) level (or the top-level Model level) I can arrange the packages as I need them.  If I am looking at the system requirements I can get all the requirements packages (and these can be in a hierarchy) for a system-wide view.  When I am working on a particular component (much more often the case beyond the early stages of a project) then I can include the requirements, use case, statemachine, and detailed design classes just for that component (and any common packages).  I think this sort of flexibility is a great advantage of the model-based approach.