We would like to share a list of generic No Magic’s recommendations for the best practices on model management in Cameo tools suite. How should the model be broken up to optimize from the project architecture perspective and element reuse?
Do not split if you do not need
In general splitting project to many projects shall not be the goal. It is easier and more efficient to work in one project working in Teamwork Could – repository or on single standalone file. In general, Teamwork Cloud perform better with flat models (work is in progress to fine grain the cases when this applies).
So work in one project until you need to decompose it. Below are the reasons why you might consider decomposition. E.g. keeping reusable libraries as read-only separate projects (module(s)) that do not change on daily basis is fine and common case for reusability purposes.
Common factors to split
There are many factors that will influence determination when separate model projects need to be created. Common factors include:
- Separate model projects are needed when models exist across multiple security enclaves.
- Lower classification level models are used by higher classification level models that provide the complete integrated data set.
- Separate model projects are often employed for reuse libraries to manage deployment of revised baselines.
- As separate configuration items, they may be subject to independent CM/CCB lifecycles.
- Planned levels of Abstraction/Decomposition
- Typically the Conceptual, Logical and Physical Models are complete model project’s with horizontal traceability within the abstraction layer and vertical traceability between abstraction layers.
- As with reuse libraries, they may need to be controlled as separate configuration items with their own CM/CCB baselines and status accounting.
- Contract/Subcontract/WBS Boundaries and Network/Tool Boundaries
- Depending on access to the shared repository, contract terms and conditions or other “work flow” issues, contract boundaries for model content owned by subcontractors or contractor teams may not be sufficiently managed through package access and privileges. Separate models may be required to protect information or to provide means to establish contract baselines or exchange data effectively.
- Manage Releases. When you model multiple different sub-systems, which has different release cycles, you need to model every subsystem in a separate project to be able to baseline them separately. Later you can indicate which version of the sub-system you are using in particular configuration. The same applies for components, etc.
- Product Line Engineering (PLE). Current best practices in product line engineering is to have separate projects for different variants of the system.
- Requirements synch. Based on our experience working with Cameo DataHub and IBM DOORS we highly recommend having Requirements in separate project than your architecture. This helps you to version SRS separately from your architecture. It is helps you to revert easier to previous version if the synch fails and it also does not stop you from working while synchronization is in progress (sometimes it takes hours).
All cases are a bit different
From our experience model partitioning depends on the Work Breakdown Structure (WBS) and can be very individual. Though we can describe best practices, it is the expertise we deliver as a consulting service.
Director of Professional Services, No Magic, Inc.
Head of Solutions, No Magic Europe
Teamwork Cloud Product Manager