Modeling Governance

Per the presentation and discussion on the Tuesday, April 24th Modeling Subcommittee meeting and the more informal discussion on 5/14 on this topic, following is a proposal regarding model governance.

A requirement is to handle toe development and approval process efficiently.   A tool should add value, yet not be a bottleneck to the model development process.   At the same time, we do not want to have to review and approve a model multiple times.

The Proposal -

1. Anyone can contribute during input and discussion phases via the WIKI
2. A model editor will participate in the calls, capturing the evolving model details (classes, relationships, attributes, diagrams, etc) in Papyrus for some model sub-team / sub-model 
3. The sub-model editor will share the Papyrus model via
1. UML Diagrams posted to the WIKI
2. Gendoc output (diagrams, tables, etc) as outlined below
3. If useful, the gendoc table can be copied and pasted directly into a WIKi page (it formats well). 
   This can be useful for direct viewing and commenting
4. When development of the model is finishing up, the Papyrus model is reviewed (via Word Doc publish) until ‘clean’ is achieved (agreement by Subteam) if the Papyrus model is current.    If the Papyrus model is not current, the WIKI is used.   This is to assure that the Papyrus tool is not a reason for delay.
5. The Clean model (Papyrus Word Output if current, WIKI otherwise) is socialized with modeling Subteam along with other sub-team’s work (reconciliation between parallel work), and approval by Subteam is reached.
6. Model is converted  to RST format (Papyrus Gendoc output if current, WIKI otherwise) and provided to DOC team.
7. If the Papyrus model was not used for steps 4-6, then an additional step is required to assure that the Papyrus model at some later point reflects the accepted model. 
   Note that this means two reviews and approvals, which is not ideal or efficient, but is the unfortunate result of the model not being current and available for review and approval in steps 4-6.

Note that in the above process no one other than the model editor is required to use Papyrus, but anyone can (it is open source), yet we gain a better model via use of a modeling tool.

A visual view of the above is as follows:  

A sample Papyrus diagram (a picture says a thousand words?)

Conclusion is that for the 'regular' participant, they can use the WIKI to share concepts, yet gain the benefits from use of a modeling tool and the resulting better model.

If interested, we can provide a short demo of Papyrus - create a couple classes, a few attributes, a definition, association between the classes with multiplicity, assign a profile value (input, discussion, clean), do a quick gendoc publish, share the diagram back to the WIKI as well as a class table back to the WIKI, etc.