...
MO
- Modeling team does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
- #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates).
- #2: REFINING EXISTING MODEL - There are also Existing high level info-model requirements and the current release is focused on continuing or refining the model. Existing in a component that hasn't made it to the information model. Previously at design build-level that needs to be added into information model. For example, a need might have arisen in development but wasn't formalized. Long-lead, multi-release items might fall into this category. coded previously but no Use Case.
- #3: FORWARD LOOKING WORK (FLW) - Forward thinking requirement. For example, suppose there were a very large use case/requirement or project that is expected to come down the pipe, but if no advanced modeling work were done on it, it wouldn't make the current release. Thus, a model might be proposed in advance of the actual use case/requirement.
- Use Case Team (evaluating U/C proposals) presents their modeling needs. Each of the Use Case teams needs to come to the modeling S/C meetings to present their expected modeling needs and open a dialogue about potential model impacts so that they can be developed. Describing the the pre/post conditions, defining the overall definition.
- Architecture understanding reference model. Modeling S/C members should be aware of any updates to the current release's reference model so that potential can be known.
- ONAP Platform Components & PTL- High level release scope from PTLs (understand from ONAP components what updates)
- PTL - Joint PTL sync meeting
- Modeling team does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
...
M1
- Modeling team The info-model plan is established by the modeling team which summarizes the modeling requirements for a release. The model planning follows a template that is worked by the team. Info-model updates begin. An example template for R6 (Frankfurt) can be seen at this Wiki: ONAP R6 Modeling High Level Requirements.
- #1: MODELING REQUIREMENTS - A description of each of the modeling requirements are described in more detail. This can be contributed from the modeling team, PTLs or the Use Case teams.
- #2: USE CASE RELEVANCE - The relevance of use cases are identified and Use Case teams can give a more detailed explanation for use case requirements and how they tie to the high-level requirements. This allows for experts in the Info-model team to identify what fields of the existing info model could be enhanced and become aware of where the impacts are.
- #3: IMPACTED PROJECTS - The impacted projects from the info-model requirements (e.g. SO, VID, SDC etc) are identified. The tie-in from the ONAP platform components to the high level-modeling requirements are described.
- #4: OVERLAPPING PROPOSALS - Overlapping info-model impacts from different use cases or forward looking work (FLW) are identified.
- #5: MODEL REUSE - Finding Overlap from different use case and requirement proposals that are evaluated will lead to identifying where model reuse can occur. By the end of the Model overlap analysis overlapping areas will either cause overlaps to be merged or altered.
- #6: OWNER - The owner(s) for the item are identified. The owners might be PTLs, Modeling subcommittee, or Use Case team.
- #7: PRIORITY - A priority is identified for the info model requirements. these are general given by service providers or modeling subcommittee. A suggested High/Medium/Low is sufficient at this stage.
- #8: LOWER PRIORITY - Lower priority requirements are generally considered as "nice to haves". Low priority requirements are captured in the info-model plan and are documented.
- #9: DOCUMENTATION AFTER IMPLEMENTATION - Some modeling requirements are related to documenting implementation after the fact. When the model plan is established, this category of info-model requirements are identified and described in the info-model plan.
- #10: FORWARD LOOKING WORK (FLW) - FLW is another class of requirements which are intended to recognize future needs.
- Use Case Teams (Project Teams) - Use Case teams are cross-functional in nature: they are composed of a leader, developers and also (indirectly) the ONAP platform members from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to craft a Data Model.
- #1: SOCIALIZATION - The model team should become aware of the use cases for the current release. Use Case teams are expected to make presentations to the modeling sub-committee for use cases that may impact the information model. This should open a dialogue between the Use Case team and the modeling to identify model impacts and where there might conceptual overlaps to help streamline the design. The Use Case teams may also be agnostic to the broader information model and contact between the modeling sub-committee and the use case teams will also raise awareness of relevant information models that the Use Case teams will need.
- #2: DATA MODEL - Because the information model feeds the data models, the Use Case teams should take into account the new updates in the information model as a basis for their data model. The Use case teams should be identifying three things which will help the Modeling subcommittee understand better the model impacts. This will help the modeling team identify areas where model impacts will be. The Use Case teams should define their use cases in more detail ideally using the kind of information shown in this template: Proposed Functional Template for Use Cases
- PRECONDITIONS - Preconditions are the Information the use cases consume.
- POST-CONDITIONS - The post-conditions can capture the kind of information that is output from the use cases.
- INFORMATION EXCHANGES - information exchanges capture the type of information that passes from component to component, APIs, NBI and external interfaces. This helps to identify the relevant models that give that exchanged information structure
- Architecture - Every release, the architecture sub-committee refines the functional architecture, creates new flow updates, and may update component architectures.
- #1: SOCIALIZATION - Modeling team becomes aware of the new functional architecture and component architecture changes for the current release. Architecture should become aware of new modeling concepts. Cross-fertilization of new requirements, use cases and how they might impact model or how the model impact the upcoming proposed architecture changes. The idea is that the modeling S/C leads would queue some time in one of the architecture S/C calls (as a 1-off) to discuss the information model for that release and vice versa. Another possibility would be to reserve some time on the Architecture sub-committee call either on a regular basis or when the modeling S/C team is about to accomplish an objective, or about to make a vote on something (to call for consensus). It would also be good if the Architecture lead (PTL) could identify modeling impacts and flag them as they come across them.
- Components (PTL)- Each of the ONAP platform components (e.g. A&AI, SO, Controllers, SDC etc) may be impacted by new modeling changes and new use cases. Having the modeling S/C engage PTLs (or vice versa).
- #1: COMMITMENT & TRACKING - The data model eventually serves as the basis for API changes and development. Platform components need to update APIs based on new requirements, use cases and features. Requests to components need to be tracked & commitment by the PTLs and components. Ideally the PTLs and component leads should be engaged by the Use Case teams. SDC & A&AI often have more high-running modeling impacts than some of the other components. The modeling team members could attend some of the component calls to raise awareness. Identifying and tracking a modeling impacting item so they aren't lost. An issue impact matrix and tracking page could be developed to track issues (and maybe a Jira ticket).
- #1: COMMITMENT & TRACKING - The data model eventually serves as the basis for API changes and development. Platform components need to update APIs based on new requirements, use cases and features. Requests to components need to be tracked & commitment by the PTLs and components. Ideally the PTLs and component leads should be engaged by the Use Case teams. SDC & A&AI often have more high-running modeling impacts than some of the other components. The modeling team members could attend some of the component calls to raise awareness. Identifying and tracking a modeling impacting item so they aren't lost. An issue impact matrix and tracking page could be developed to track issues (and maybe a Jira ticket).
- Modeling team The info-model plan is established by the modeling team which summarizes the modeling requirements for a release. The model planning follows a template that is worked by the team. Info-model updates begin. An example template for R6 (Frankfurt) can be seen at this Wiki: ONAP R6 Modeling High Level Requirements.
...
M2 CHECKPOINTS & COLLABORATION
M3 (API Freeze)
- M3 MODELING SUBCOMMITTEE ACTIVITIES-
- REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean at M3. It is considered "base-lined" and "final", hence it is marked clean. Though, updates can still happen to the release information model and the model contributions therein. This means that certain elements within the model(s) could go to back to an experimental state. Note that only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. More often though, new additions could be added to a contribution model. In general, there would likely be just minor tweaks on the model. So when a contribution is clean it has to be at least preliminary. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature (see the IISOMI state diagram link).
- IISOMI STATES - A link to the IISOMI state diagram can be found here: Stereotypes
- NEW ADDITIONS - A contribution model could be clean, but things added afterwards and those elements would come in as experimental.
- STILL IN PROGRESS ITEMS IN RELEASE INFO MODEL - It is possible that as the modeling team enters the M3 milestone that there are still some things in progress, that are expected to be in the current release. They might still be marked experimental even though the release information model is clean. Thus, to open item are continue to be work; and it is expected it would not affect software if code were already associated to it.
- ITEMS IN DISCUSSION - e.g. when root contribution was done, with root party is an example as it was not agreed to, we made the decision to leave that experimental until a future date. There were aspects agreed, and other things left experimental to pursue in the future. The main contribution was split. These parts everyone agreed with and these part left experimental which would be taken up in a future contribution and re-discussed. This would likely occur at M2, and they might be discussed at M3. There was a conscious decision and agreement by the modeling team that the parts of the model still open would be pushed to the next release. So only theoretical discussion would happen at this point of how to proceed in the future release.
- FUTURE WORK - Things originally planned to be in a release could potentially transform into future work items. Some modeling work could be pushed to the next release if need be, if it is decided that it could not be completed in the current release.
- FUTURE WORK- Future work is typically identified as such at the start of a release at M0 in the release modeling planning page. Future Work can still proceed. For example, in R6 the geo-location modeling work is not tied to any active development yet. The location work is a good example of work that was worked in ADVANCE of when it is expected to be used (Future Work). It is also possible that some of the future work is building upon a foundation of work that had already been started (or was looked at) or implemented in a prior release.
- DEFER WORK - It might be decided the the future work could be deferred to the next release. On the current modeling high level requirements page to indicate that a particular future work has been deferred to a future release. In order not to lose the activity, it would be expected that it would be rolled into the next release's Modeling High-Level Requirements.
- CONTINUE WORK - Future Model work may continue to proceed in the current release..
- DOCUMENTATION AFTER IMPLEMENTATION IN PRIOR RELEASE WORK- This type of work is the model is catching up to already implemented software. It has already been identified as something that would be worked on for that release at M0. It is expected that it wouldn't immediately impact the current software. However, it may be extended eventually to incorporate new work. The way to proceed with this category of work is handled the same way as the future work (i.e. Defer or to Continue the work) given modeling improvement recommendations on how better to model a given concept.
- M3 CHECKLIST - The M3 check list modeling updates discussion is used by the modeling sub-committee. It is used as a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. See also the Use Case Team Engagement (section below). The Check list can be found here: Proposed M3 Checklist modeling updates discussion
- REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean at M3. It is considered "base-lined" and "final", hence it is marked clean. Though, updates can still happen to the release information model and the model contributions therein. This means that certain elements within the model(s) could go to back to an experimental state. Note that only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. More often though, new additions could be added to a contribution model. In general, there would likely be just minor tweaks on the model. So when a contribution is clean it has to be at least preliminary. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature (see the IISOMI state diagram link).
- Architecture Engagement - By M3, the architecture team has base-lined the release Functional Architecture. There may still be some component architecture and Architecture proposed enhancements in progress
- SYNC - Work underway still by the modeling sub-committee, such as refinements to the release information model, items still in progress, future work, and work documented after implement should be communicated to the architecture sub-committee in a sync-up before M3. The modeling sub-committee lead should reach out to the Architecture PTL either for a quick sync, a separate 1-off presentations, or reserved slots on either of the two regular weekly team calls.
- Use Case Teams Engagement -
- API Freeze - M3 is characterized by the API freeze. The main thing that happens at M3, the API is frozen by the Use Case Teams.
- Data Model Freeze - Developers identify a problem in the data model which affects the information model.
- SYNC UP - Since the Modeling S/C is familiar with the info-model; the Use Case Teams should present at the Modeling S/C their proposed data model that might be frozen so that the modeling S/C can assess it to see if might have impact to the Info-model. There should be some collaboration or check-point at M3 to discuss and potential ripple affects back to the information model.
- DATA MODEL IMPACTING INFO MODEL - If changes in the Data Model impact the information model, those changes need to be worked by the model S/C. The Modeling S/C would evaluate the change to the Information model and possibly make updates.
- USE CASE TEAMS INDICATE CHANGE - The Use Case teams may have enough knowledge of the info-model that they identify a data model change that may impact the information model. This presumes that the use case teams know that their changes in a data model may have impact to the information model.
- CONSIDER DATA MODEL - START: Input Data Model > verb Consider > END: Data Model in Discussion State
- The data model is a model that is used in a Use Case and is based on the Information Model. It is generally a self-contained model which depicts a particular capability or function of the system. The data model starts as a "input data model" and undergoes consideration by the Use Case teams. Consideration means that the Use Case teams is entertains & assesses if the input data model. If the Use Case teams think that the contribution is not ready for the current release that contribution it might postponed. It would be noted in the Release Management Project page as such.
- REVIEW & REFINE CONTRIBUTION - START: Data Model in Discussion State > verb Reviewing & Refine > END: Data Model in Discussion state
- The data model undergoes reviewing & refining during the discussion state. Reviewing & refining means that the Use Case Teams are discussing the data model and updating their data model based on feedback and comments from the Use Case team and modeling team. Each data model can be reviewed and refined independently and concurrently with other use case projects. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
- ENGAGE the Modeling Sub-Committee - The modeling sub-committee should be engaged during the review and refinement stage. Ideas should be solicited to see if the data model is in-line with the release information model
- MODELING S/C ENGAGEMENT - The Use Case teams may wish to solicit the opinion of the modeling S/C and present their data model for discussion and socialization.
- FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Data Model in Discussion State > verb Approving/Poll > END: Data Model in Discussion state
- (a) FINAL PRESENTATION - When the data model has gotten to a point where the use case team feels that it can start to undergo the approval process, the data model is brought one final time the use case team.
- (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a use case lead to the modeling team whereby final thoughts & input can be given. This final call for comments signals that the discussion is wrapping up for this contribution and will soon go to a poll.
- (c) INITIATING POLL - After final call and no further outstanding comments exist, the contribution is brought to a poll by a use case lead. A poll is created whereby use case team members can give the contribution a vote of "yes" or "no".
- APPROVING CONTRIBUTION - START: Data model is in Discussion State Post-Poll > verb Approving > Data model in Clean State
- After the poll has concluded, the data model has finished the approval process. The data model is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state. A gendoc is generated and put on the wiki page. The gendoc would be translated and published on the readthedocs site.
- Use Case Data Model Final - After each of the Use Case teams have reached a clean (approved) state, the use case teams can proceed to API freeze.
- RECONCILE Info Model & Data Model - Any inconsistencies identified by the modeling sub-committee should be reconciled with the data model. The info-model with the data-model after clean state should be congruent. M3 checklist. (API Freeze)
- M3 CHECKLIST - The M3 check list is used during the M3 milestone by the Use Case team. This is a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. The Check list can be found here: Proposed M3 Checklist modeling updates discussion
- ONAP Platform Components (PTL) Engagement -
- & PTL Engagement - Platform components (A&AI, DCAE, SO, SDN-C etc) are finalizing the APIs in various components hand-in-hand with the Use Case teams (which are either co-developing these APIs or using them directly).
- The ONAP Platform Components provide the functionality that is used by the Use Case Teams and require commensurate changes to support the API and Data Model needs of each of the Use Case Teams.
- A checklist for the platform components (AAI, DCAE, SO, SDN-C) should be used: Proposed M3 Checklist modeling updates discussion
- Information Exchanges - Verify that the information exchanges of the Platform component is satisfied
- Data Model - Verify that the data model for Shared Information from the Component-side is completed.
- Mapping - Verify that the data elements in platform component data models have been mapped to ONAP common information model
- Review - Review Data Models & Use case artifacts with the modeling sub-committee
- Tracking - Verify that issues arising from data/information model review are tracked.
- M3 MODELING SUBCOMMITTEE ACTIVITIES-
M4 (Code Freeze)
Code Freeze
Kickoff Information Model Requirements for Next Release
- READ THE DOCS - (M3 or M4?) The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the readthedocs. The read the docs can be found here: https://onap.readthedocs.io/en/latest/index.html . The word document is fed into some tools which generates the readthedocs output. The gerrit master model is periodically updated, and a snapshot of the eclipse/papryus model is taken and that is called the release model.
- 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
...