Versions Compared

Old Version 30

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version 31

changes.mady.by.user Benjamin Cheung

Saved on

Key

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

...

Frankfurt Release M3 API Freeze Milestone Checklist

Use Case Teams Process per M-gate

  • MO

    • ARCHITECTURE SUB-COMMITTEE

      - The following are M0 activities with the Architecture Sub-committee. Release content defined.
      • #1 FUNCTIONAL ARCHITECTURE (Proposals) - The functional reference architecture is the high-level architecture overview diagram for all of ONAP. Enhancements to the functional architecture may be driven by new project proposals, updates to the diagram, and architectural changes that may be planned for the release. At M0 impacts to the functional architecture are proposed.
      • #2 COMPONENT ARCHITECTURE (Proposals) - The component architecture impacts originate from the ONAP platform components. Examples of platform components are Policy, CLAMP, SO, A&AI, CCSDK, SDN-C. Each release there may be architecture impacts from the platform components. At M0, component architecture impact proposals are submitted. Architecture reviews are setup & scheduled for component architecture impacts/proposals. Component architecture diagrams would be updated.
      • #3 REQUIREMENTS ARCHITECTURE (Proposals) - These are architecture impacts coming from the requirements and use case work in a release that may impact the functional architecture, platform architecture, or may need architectural guidance. At M0, the requirements and use cases are being proposed for the release. And an early assessment of which ones that might impact the architecture should be considered, and they made translate into requirements architecture proposals. Architecture reviews are setup & scheduled for requirements architecture impacts/proposals. The requirements Sub-Committee can evaluate and identify cross-interactions between proposals. The requirements S/C can make prioritization recommendations to the TSC. The TSC (with EUAG input) can then make a decision to adopt or alter the prioritization recommendations.
      • #4 ARCHITECTURE ENHANCEMENTS (Proposals) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include documentation enhancements, landing page enhancements, architecture component description work, flow descriptions and process work. At M0, initial proposals are submitted to the architecture sub-committee.

    • WIKI LINKS References for the Use Case Teams at M0

      WIKI LINKS REFERENCE AT M0
      M0DescriptionWiki Link
      1Functional Reference ArchitectureArchitecture
      2Architecture Portal Page
      		https://safratech.net/onapdocs/
      3Release Architecture Page

      All of the architecture reviews that were conducted:


      4Requirements Proposals

      Requirements subcommittee

      Guilin release - functional requirements proposed list

      ModModeling Release Planning PageONAP R7 Modeling High Level Requirements
      U/CArchitecture Review ProcessProject Architectural Review Requirements and Process (Draft)
      U/CArchitecture Review TemplateR7 Guilin Architecture Review (template) - functional requirements


    • Modeling team - At MO the Modeling S/C 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). The Use Case Teams should engage the modeling team to propose new requirements into their release planning page.
      • #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model. Previously designs that need to be added into information model.
      • #3: FORWARD LOOKING WORK (FLW) - Modeling future forward looking requirements.
    • USE CASE TEAMS At M0, the Use Case teams are working on the following things:
      • #1: BUSINESS DRIVER TEMPLATE - The Use Case Teams are specifying their business drivers via the template: Business Driver Template for Use Cases
      • #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release to the Requirements Sub-committee: Requirements subcommittee .
      • #3: REQUIREMENTS RELEASE TRACKING - Requirements put release requirements page. Example wiki: Guilin release - functional requirements proposed list
      • #4: USE CASE DEFINITIONS - Use Case team fill out the Template detailing their Use Case: Use Case Tracking Template
      • #5: INTENTION TO PARTICIPATE - Teams can indicate their corporate intention to participate
      • #6: RELEASE TRACKING - Each release has a release tracking page. The page can be found here: Release Planning
      • #7: PROJECT SUBMISSION, PROPOSAL, PLANNING - The TSC coordinates the project submission, proposal and planning. The TSC reviews and gives disposition on submitted proposals. These are tracked at the Release Planning page.
      • #8: ARCHITECTURE REVIEW - The use cases & requirements undergo Architecture Review


        REVIEW STEPDESCRIPTION
        MODELING INPUT

        The Use case teams should engage the modeling sub-committee and schedule their use case into the model planning page before architecture review. They should identify information is consumed, produced, and utilized by their use case. This should also be scheduled in the Model Planning page: ONAP R7 Modeling High Level Requirements

        CROSS DEPENDENCIES

        Use Case teams should identify cross-dependencies upon other requirement/use cases and/or ONAP components cross-dependencies impacts. For example BBS dependent on PNF registration, it is nice to know about that dependency so that the two teams know to work together. This should be identified before the architecture review if possible.

        CONTROL LOOPSIdentify potential Policies and Control Loops that might be altered or new with your requirements/use case.
        API IMPACTS

        Use Case teams should identify API impacts. The team should highlight the differences between what exists today (the old API) and the new API that they expect to update it to. This should be put in the presentation made to the architecture review.

        INTERFACE IMPACTS

        Interface (northbound and southbound) impacts should be identified

        REQ JIRAS

        The release tracking Jiras should be created. See the ONAP Use Case / Requirements Teams Process Way of Working (WoW)

        ARCH JIRA

        The Architecture Tracking Jira is created. The Architecture Chair will create the ONAPARC Jira tickets before the review. The reviews are scheduled week by week. Navigate to the Architecture Meeting Notes (weekly) ONAP Archecture Meeting Notes (New)

        ARCH REVIEWWhen the template and checklist has been completed, create a presentation to walk through at the Architecture sub-committee and schedule a review.
        REQ to ONAPARC JIRA LINKING
        1. LINK - Before a requirement may be reviewed by the arch subcommittee, the requirement must be documented in JIRA (REQ), and the REQ reference must be submitted when requesting an arch review.
        2. STEPS - After the arch review subcommittee has completed its review and made a determination, please add an issue link to the REQ issue for your review.
          1. Navigate to your requirement issue in JIRA (REQ)
          2. Select edit
          3. Scroll down until you find the "Linked Issues" field (see attachment)
          4. Make sure that the link type is "Is blocked by" (see attachment)
          5. Add the JIRA reference for your arch review (ONAPARC) to the "issue" field. (see attachment)
          6. Click the "Update" button.
          7. image2020-6-11_11-45-39.png


    • PLATFORM / PTL- High level release scope from PTLs (understand from PTL which ONAP components are expected to have updates). If a component is resolving technical debt or software development that is entirely self-contained.
    • PTL - The Use Case teams should attend the PTL planning meetings if there are expected to be requirements impacts for your use case. It is also where the Release Planning page is developed by the PTL team.

...

  • RCx (Runtime Compliance)

    • ARCHITECTURE SUBCOMMITTEE at RC0/RC1/RC2 -
      • #A RELEASE CERTIFICATION - The API reviewed were the ones that were tested by the integration teams. The high-level requirements drive the low-level requirements. They would drive test cases. Test cases are run, if they pass and there is something that is wrong with the requirements/epics/user stories, the test cases don't change and then re-test happens. The feedback with a problem they need to make sure that problems are also notified in the architecture sub-committee.
      • #B NEXT RELEASE ARCHITECTURE FOCUS - Discussions are happening around what the focus of the Architecture efforts for the next release are happening. For example at the end of R7 the Architecture sub-committee was discussing aligning the Platform component wiki pages, and also the next steps for the Architecture flow diagrams that were started in R4.
      • #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include architecture portal landing page enhancements, architecture component description work, and process work. Because the teams are fully engaged trying to meeting delivery deadlines, the Architecture enhancements are fully self-contained activities within the Architecture sub-committee they can continue to evolve during M3, M4 and RCx. For example, suggestions for common templates can be discussed in this time frame. This also sets the stage for making the focus of the next release more coherent.

    • Use Case Engagement -
      • API - Uxnent pages.
    • Components (PTL) Engagement -
      • Axions - Upd

Artifacts

  • Information Model Artifact Contains

    • Tooling - Papyrus with GitHub

  • Component Data Model Artifacts (Implementation Specific)

    • x

  • API Artifacts

    • odel

...

  • The following summarizes the artifacts of the Architecture Subcommittee


  • TopicDescription
    Functional Architecture

    The following diagram is an example of the functional architecture:

    Image Added

    This is one of the main outputs of the Architecture Sub-committee.

    Component Architectures

    The component architecture pages capture the architecture per component.

    The R7 component wikis can be found here:

    ONAP Architecture Component Description - Guilin-R7


    Architecture Portal Page

    The Architecture Portal page can be found here:

    https://safratech.net/onapdocs/

    The page looks like this:

    Image Added


...

Roles – Architecture Sub-Committee

...


  • The following table shows some of the key roles within the Architecture Sub-committee


  • RoleDescription
    ChairThe Architecture Chair coordinates the Architecture work and sets a vision for the sub-committee.








SUPPORTING LINKS & DOCUMENTS

...