Decomposing a Project Using Modules

General discussions about teamwork

Moderator: Moderators

Decomposing a Project Using Modules

Postby » Tue Oct 03, 2017 6:16 am

My team has a top level DoDAF 2.0 project on Teamwork Server. This project has several different systems, one of those systems (System X) we plan on decomposing to the next level using SysML. The team performing the decomposition will be a separate group and will not have access to our Teamwork Sever. Given this, we were thinking of separating that system into its own module. Does anyone have any experience with the best way to go about this? Some questions/thoughts I'm having are:
-- What do we include in that module to start? Do we just include System X but all the system data exchanges, traces, and other relations stay in the main project so the top level team can still update and modify the top level diagrams?
-- Should we make the module read-only so only the team working on the System X decomposition can modify?
-- Will we be able to get drops of the system X teams decomposition and easily load that into to a newer version of the top level project in Teamwork Server?
-- What is the best way to decompose the system data exchanges? For example, if we only have "commands" in the top level project and the decomposition team for System X will decompose that into the various messages into the interface specification do we just need to have them be the same "Type" or do something else?

Forum Newbie
Forum Newbie
Posts: 2
Posts Rating:0
Joined: Tue Oct 03, 2017 5:54 am

Re: Decomposing a Project Using Modules

Postby Edita Mileviciene » Tue Oct 10, 2017 5:51 am


We recommend managing your projects as follows:
- As the team that will perform system decomposition using SysML will have no access to the whole model, we recommend separating that system in DoDAF 2.0 model into its own module. The module should include System X only. All the inner relations of the system should be included into this module, but all the relations with other systems shall reside in the main project. Note that you will need to precisely define all the communication points and possible types of communication inside of the System X module.
- We recommend having all the modules read-only. System X model should be edited by opening it as separate project. Read-write mode should be used for modules refactoring only.
- A SystemX decomposition in SysML shall be done in a separate project. If you need traceability, it shall use SystemX description in DoDAF 2.0 module. The traceability relations can be created from SysML to DoDAF module to show how concepts, exchanges and communications map from SysML to DoDAF.
- Later, if there is a need – you can add System X description to teamwork and to the main project.
- When decomposing data exchanges from commands into the more specific messages, you can mark that this is the same concept using abstraction relation from message to a concept. If you need more precise descriptions, the data types in SysML may be inherited from DoDAF data types, but this is not necessary.

Kind Regards,
No Magic Inc. Customer Support
Edita Mileviciene
Customer Support
Customer Support
Posts: 69
Posts Rating:1
Joined: Wed Jan 13, 2010 5:35 am

Return to Merging, branching, modules, team collaboration

Who is online

Users browsing this forum: No registered users and 0 guests