Page History

...

M2 CHECKPOINTS & COLLABORATION

• M3

  • MODELING SUBCOMMITTEE M3 ACTIVITIES-
    • REFINEMENTS TO THE RELEASE INFO MODEL
    - Updates
    • - 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.
    Which basically
    • This means that certain elements within the model(s) could go to back to an experimental state
    . Also, new additions can also be added to the model. In general
    • . 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.
    The Release Information Model
    • So when a contribution is clean
    at M3. The Release Information Model is considered "baselined" and "final" hence it is marked 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
    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)

  • • • 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- 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).
      
      • DEFER WORK - It might be decided the the future work could be deferred to the next release.
      • CONTINUE WORK - Future Model work may continue to proceed.
    • DOCUMENTATION AFTER IMPLEMENTATION IN PRIOR RELEASE WORK- This type of work is where the modeling work is catching up to the software, and it fits in the same category as the future work, because it is planned and accepted but doesn't impact the current software. In this case the software is already in place, and modeling work is just catching up to it. The way to proceed with this category of work is handled the same way as the future work (i.e. Defer to continue).
    MODELING SUBCOMMITTEE ACTIVITIES
    • M3 CHECKLIST - The M3 check list is used. The Check list can be found here: Proposed M3 Checklist modeling updates discussion

  • API Freeze

  • Add “Data Model Freeze” (Approval)

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

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

  • 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

...