Versions Compared

Old Version 33

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version 34

changes.mady.by.user Benjamin Cheung

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • M2

    • MODELING SUBCOMMITTEE -
    • For the RELEASE Information Model these are the activities that the Modeling sub-committee is engaged in leading up to M2.
      • RELEASE INFORMATION MODEL (Starting Point) - The release starts with a clean release information model from the PREVIOUS release (with all of its attendant contributions). Then new contributions of the current release are considered (see below the process for handling each specific contribution). Potentially a snapshot of the papyrus model and posted into the current release. The RST documentation that only contains things in the current release or everything that is approved.
      • TERMS & CONCEPTS -
        • IISOMI STATES - The concept of IISOMI states describes the state of individual classes, attributes, and associations/relationships. IISOMI states are noted within the elements of the contribution. For example, a particular parameter might be in the experimental state while another class might be tagged as in the preliminary state. These preliminary and experimental are states that are mutually exclusive so you can't have a class/attributes with two different IISOMI states simultaneously. During the discussion phase, the elements of the contribution should be out of experimental state. The exception is that there is a state of reference that can exist with other states. Some elements within the contribution could have different IISOMI states. The webpage for the IISOMI states can be found at: Informal Inter-SDO Open Model Initiative (IISOMI)
      • DELAYED ELEMENTS OF THE RELEASE INFO-MODEL - This may happen that are out of the control the modeling S/C. Use Cases get delayed, or a discussion can't wrap up. So, there could be a corner case where, for example, one or more things (parameters/classes) in a contribution can't make the current release (it stay experimental), what would happen to the overall contribution or release information model (is it allowed to go clean). This would not stop the other parts of the contribution or the release information model from going to a clean state.  #@# Example, Dynamic parameters in the common sub-model, generates the whole model then manually edited down to the DP. if things are marked experimental it will show experimental. Keep of Track (experimental?) communicate? reviews?
      • INFORMATION MODEL FREEZE - The aggregate / release information model for the release is approved by association with the fragment/ component reviews.  Each of the fragment (contributions) are individually approved, thus there is not a "re-approval" or approval of the entire aggregate (release) information model. Editorial clean-up such as misalignments, typos, or sections that were not put in proposal, fixing the template for GenDoc.
      • RELEASE INFO MODEL DECLARED CLEAN - After component reviews have concluded and release info model freeze by the modeling S/C the info model is called the "clean model" in this phase. At this point, the Use Case teams that are developing the Data Model can be pretty certain that the information model will be usable as shown. The diagrams and model wiki pages will indicate that this is a clean model. Put into the information model for that release. Unfinished contributions are postponed or discussed further.
    • DISCUSSION OF CONTRIBUTIONS - Each contribution discussed according to following process. This is where refining of each of the contribution models occurs by the Modeling Sub-committee (S/C). The release information model is not separately tracked, composed, updated, or released in this period of time. But, rather, each individual contribution has its own Wiki. Thus, for each contribution:
      • CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
        • An individual model contribution is a model that will eventually be a part of the total release information model. It is generally a self-contained model which depicts a particular capability or function of the system. This contribution starts as a "input contribution" and undergoes consideration by the modeling sub-committee. Consideration means that the modeling S/C is entertains & assesses if the input contribution should be accepted into the current (or a future release) by weighing the contribution against its relevance and the available resources (modelers) in the release. If the team thinks that the contribution is not ready for the current release that contribution will be put into a lower-priority and worked if there are no other contributions to be considered as they would take higher priority. Thus, the contribution would not necessarily be rejected, but would get attention as time allows.
      • REVIEW & REFINE CONTRIBUTION - START: Contribution in Discussion State (verb Reviewing & Refine) END: Contribution in Discussion state
        • The contribution undergoes reviewing & refining during the discussion state. Reviewing & refining means that the modeling S/C is discussing the modeling, and updating the contribution based on feedback and comments from the modeling team. Each contribution can be reviewed and refined independently and concurrently with other contributions. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
      • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Contribution in Discussion State (verb Approving/Poll) END: Contribution in Discussion state
        • (a) FINAL PRESENTATION - When the contribution has gotten to a point where the team feels that it can start to undergo the approval process, the contribution is brought one final time the modeling S/C for discussion and socialization.
        • (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a sub-team 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 sub-committee chair. A poll is created whereby modeling S/C members can give the contribution a vote of "yes" or "no". 
      • APPROVING CONTRIBUTION - START: Contribution in Discussion State Post-Poll (verb Approving) Contribution in Clean State
        • After the poll has concluded, the contribution has finished the approval process. The contribution 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.  

Image Removed

      • STEREOTYPE CHECK - The entities in the model has an experimental stereotype (down to the attribute level) when they are a proposal, when approved/clean, all of the entities in that proposal bear change from experimental to preliminary. Stereotypes can be on classes, attributes, data types and relationships. It is an ISOMII add into the model, at a high-level in the model things get stereotypes. E.g. when we approved the first VES model, which has many entities and many attributes; to update all of those from experimental to preliminary was tough. A stereotype is a status marker. Preliminary is approved for development.

CONTRIBUTIONS & THE RELEASE INFORMATION MODEL

Image Added

  • 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
  • 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.

M2 CHECKPOINTS & COLLABORATION

Image Added


  • M3

    • MODELING SUBCOMMITTEE -
    • REFINEMENTS TO THE RELEASE INFO MODEL - Updates can still happen to the release information model and contributions therein. Which basically means that certain elements within the model(s) could go to experimental state. Also, new additions can also be added to the model. In general, there would likely be just minor tweaks on the model. The Release Information Model is clean at M3. The Release Information Model is considered "baselined" and "final" hence it is marked clean.
    • STILL IN PROGRESS ITEMS IN RELEASE INFO MODEL - It is possible that as the team enters the M3 milestone that there are still some things are still in progress, that are expected to be in the release. They might still be marked experimental even though the release information model is clean. Thus, to continue work would not affect code. If code were tied to it. Thus, that piece could be pushed to the next release if need be.
    • FUTURE WORK - Future Work can still proceed. For example, in R6 the location modeling work, it is a work that a piece of development is not tied to. The location work is a good example of work that was worked in ADVANCE of when it is expected to be used (Future Work).

    • API Freeze

    • Add “Data Model Freeze” (Approval)

    • Add “Component Data Model Final” (Approval – Design Level Compliance)

    • MODELING SUBCOMMITTEE ACTIVITIES
    • Architecture Engagement -
      • S-P - B-
    • Use Case Engagement -
    • Components (PTL) Engagement -

  • M4

    • 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.

  • M3

    • API Freeze

    • Add “Infomodel Final”

    • Add “Data Model Freeze” (Approval)

    • Add “Component Data Model Final” (Approval – Design Level Compliance)

    • MODELING SUBCOMMITTEE ACTIVITIES
    • Architecture Engagement -
      • S-P - B-
    • Use Case Engagement -
    • 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

...