...
- Architecture Engagement -
- M2 ARCHITECTURE WORK - Before M2, the architecture team is working to refine their Functional Architecture, the component architecture, and Architecture proposed enhancements. Conceptually, many would consider the development of the release information model as actually architecture work. Thus, engaging the actual architecture sub-committee during the point in the time that the release information model is becoming frozen is important.
- SYNC UP - The architecture sub-committee should have a sync up with the modeling sub-committee to have a check-point to share the release information model. The key triggering milestone is that the release information model has just achieved a clean state, and the architecture sub-committee should be aware of this, and some of the highlights in the model. For example, the key contributions in the release that comprise the model. The modeling sub-committee should get on the agenda of the architecture S/C or vice versa when the release information model is ready. Alternatively, a regular sync up with the architecture sub-committee, such as once a quarter or bi-annually could also serve this purpose.
- Use Case Team Engagement -
- INFORMATION & DATA MODEL DEVELOPMENT - Discussion Info Model & Data model development with input from the Model S/C. Active discussion and interaction between Use Case Team and the Modeling S/C to make sure that the information model and the data model development are in lock-step. The modeling sub-committee will communicate the clean release information model as a refining input to the development of the data model for the Use Case Teams.
- INFORMATION & DATA MODEL REVIEW - Reviews of Data Model with Project (Use Case) Teams. The Data Model is being reviewed by the Use Case Teams with inputs from the Modeling S/C by bringing the developing data model (in the discussion state) to the modeling S/C. It would not be feasible to for the members of the modeling S/C to attend all of the various U/C meetings; although one-off sync-ups might occur in this stage. For those U/C that have significant data modeling work, it would be advised that that U/C team reserves a slot in the modeling S/C meeting(s) to present their data modeling changes and information flows so that the modeling S/C team can advise the U/C team as they develop their data model.
- MAPPING BETWEEN INFORMATION & DATA MODEL - Mapping of information model and the data model is also done between the modeling S/C and the Use case teams. This might happen in the project teams, or on the modeling S/C calls.
- CROSS REFERENCING JIRA TICKETS - The modeling S/C uses Jira tickets to track activities; and the Use Case teams also use Jiras to track platform work, modeling work, epics & stories. So it would be smart to link or associate relevant Jira tickets together.
- JOINT REVIEWS - The Data model should be reviewed with the Modeling S/C. Data model being developed by the component team is using the component model as input.
- SYNC UP & SOCIALIZATION - Either the Use Case weekly meeting, or the Use Case Realization weekly call would be a good meeting to communicate and socialize the clean release information model. Announcing the results of the poll to move to clean release information model. An email should be sent to the ONAP group lists with links of where to find the clean release information model. Announcements by email and presentation by the Modeling S/C leads to the Use case committee, and TSC (and architecture see above) can be made at this time. If there is some debate, there might be times where we need to reconcile a difference of ideas; and the development of models, the U/C committee meeting, the U/C realization call, and/or the 5G U/C call are all forums where many of the U/C projects team attend. And those are meetings where people discuss and work through the development of a data and information model.
- Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) review clean Information Model impacts for the release.
- FEEDBACK - Component platform work can feedback to the Modeling S/C for updates to the information model during the refining the info model phase and should also provide input during the review. Modeling S/C should take into account component platform updates vis-a-vis the Use Case and modeling requirements for the release.
- SOCIALIZATION - The socialization of the clean release information model should include updates for the PTLs. The platform PTLs must become aware that the clean release information model has gone to approval. The PTLs also attend the TSC. An email to the PTLs. Possibly a joint call with the PTLs in attendance might help to socialize the information model. Because this is a major milestone of the modeling S/C. Perhaps a modeling notification email distribution list could be made that would send major updates from the modeling S/C and that would not flood notifications from the modeling team. An email announcement of polls, in this case the baseline of a clean release information model.
M3
API Freeze
Add “Infomodel Final”
Add “Data Model Freeze” (Approval)
Add “Component Data Model Final” (Approval – Design Level Compliance)
- MODELING SUBCOMMITTEE ACTIVITIES
- M3 CHECKLIST - The M3 check list is used. The Check list can be found here: Proposed M3 Checklist modeling updates discussion
- Architecture Engagement -
- S-P - B-
- Use Case Engagement -
- D-T - D-p.
- RECONCILE - Reconciling the infomodel with the data-model. M3 checklist. (API Freeze)
- M3 CHECKLIST - The M3 check list is used. The Check list can be found here: Proposed M3 Checklist modeling updates discussion
- Components (PTL) Engagement -
M4
Code Freeze
Kickoff Information Model Requirements for Next Release
- DOCUMENT GENERATION - The RST documentation that only contains things in the current release or everything that is approved.
- PAPYRUS GENERATION - The Papyrus snapshot is generated. The RST document is created. The readthedocs documentation is generated.
- Note that the papyrus model includes what was/had accepted into the previous release and also anything that is still a work in progress.
- Architecture Engagement -
- S-P - B-
- Use Case Engagement -
- D-T - D-p.
- Components (PTL) Engagement -
RCx
Runtime Compliance
Observations
Establishes and Evolves a Common Model
Project (Component) Team Involvement in Modeling Solution
Governance of Common Model and Corresponding Component Models
- Update possible in M3 and M4 (bug fixes) per exception process
...