...

• Architecture Engagement -
  • M2 ARCHITECTURE WORK - Before M2, the architecture team is working to refine their four basic things: (1) Functional Architecture, (2) Use case impacts (3) component architecture, (4) Architecture enhancements. At M2, the project teams working requirements and use cases should be aware of the reviews for the major architecture initiatives and be involved in reviews.
  • SYNC UP - The architecture sub-committee should have a sync up with the project teams to have a check-point to share updates to the project impacts.
• Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) revflease.
  
  • FEEDBACK - The platform PTLs should be updated and be involved with project teams requirements freezing and discuss if there are de-scoping that may be necessary. API impacts from projects should also be communicated to the project PTLs.
  • SOCIALIZATION - The socialization of project scope changes, and API updates should be made. Attendance at Project PTL meetings will help keep the project teams in sync with the project.

#@#

• M3 API FREEZE
  

  • USE CASE / REQUIREMENTS PROJECT TEAMS -
    • API FREEZE - M3 is characterized by the API freeze. The main thing that happens at M3, is that the API is frozen by the Use Case / Requirements Teams.
    • DATA MODEL FREEZE - Developers are working to review & finalize the data model in order to develop the API.
      • Info Model - The Modeling S/C is develops 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 provide assistance and assess if info-model impacts.
      • 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.
      • EVALUATE 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 DATA MODEL - 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.
      • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Data Model in Discussion State > verb Approving/Poll > END: Data Model in Discussion state
        • (a) FINAL DATA MODEL - 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 project team.
        • (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a use case lead 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.
    • RECONCILE DATA & INFO MODEL - Reconciling the info-model with the data-model. If there are impacts to the information model, it should be captured.
  • MODELING S/C ENGAGEMENT at M3-
    • 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.
    • REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean (base-lined) at M3. Though, updates can still happen to the release information model and the contributions. Certain elements within the model(s) could go to back to an experimental state. Only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. New additions could be added to a contribution model. 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.  
  • ARCHITECTURE ENGAGEMENT -
    • API FREEZE & ARCHITECTURE - API updates can impact that Component Architecture. That is architecture related to the ONAP components (A&AI, SO, SDC etc). Impacts to the API also affect the architecture landing page portal, and the architecture component descriptions. This is where the architecture team captures links to the API descriptions and documentation. Impacts to the API should have been identified during the architecture sub-committee review at M0.
  • COMPONENT  (PTL) ENGAGEMENT -
    • API FREEZE & COMPONENT IMPACT - The API freeze most directly affects the ONAP components (A&AI, SO, SDC etc). As the project teams working use cases & requirements will directly impact the software used by micro-services or platform components. Software changes are tracked in Jira, and should be coordinated with the PTL platform component technical leads.

#@#

• M4 CODE FREEZE

  • USE CASE / REQUIREMENTS PROJECT TEAMS -

  • 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.
  • MODELING S/C ENGAGEMENT at M4 -
    
    • f
  • ARCHITECTURE ENGAGEMENT -
    
    • S-P - B-
  • COMPONENT (PTL) ENGAGEMENT -
    • D-T - D-p.

...

This table has links to the other Way of Working (WoW) ONAP Process pages. The WoW for Architecture and Modeling are cross-collaborative, and the processes should align in places so it forms a cohesive whole if you are working on a project that has Use Case, Modeling and Architecture Impact.

SUPPORTING DOCUMENTS

...