Page Comparison

...

• 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. For An example in template for R6 (Frankfurt) it was herecan be seen at this Wiki: ONAP R6 Modeling High Level Requirements.
    • #1: MODELING REQUIREMENTS - A description of each of the modeling requirements are given 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 and how they tie . The tie-in from the ONAP platform components to the high level-modeling requirements are described.
    • #4: OVERLAPPING PROPOSALS - Overlapping proposals info-model impacts from different use cases or forward looking work (FLW) are identified.
    • #5: MODEL REUSE - During this time, overlap Finding Overlap from different use case and requirement proposals that are evaluated can also 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". #8 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, modeling requirements documentation after implemented can be worked on.#9 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. This is separate from the ASAMI stereotype view "Experimental" because you can get consensus from the modeling team and the PTL.
      
  • Use Case Txeveloped x.
  • Architectureuxn be knownx.
  • PTL- Hixlx

  • Project Planning / Functional Architecture Defined / Architecture Approved

  • Add “Infomodel Plan Established”

  • Note:  Infomodel Updates Begin / Data Model Refinements Begin (M1.5)

  • Note:  Development Commitments for Infomodel Requirements?

• M2

  • Functionality Freeze

  • Add “Infomodel Freeze” (Approval)

  • Add “Data Model Freeze” (Approval)

  • Note:  Feed to Data Dictionary??

• M3

  • API Freeze

  • Add “Infomodel Final”

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

• M4

  • Code Freeze

  • Kickoff Information Model Requirements for Next Release

• 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

...