Versions Compared

Old Version 48

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version 49

changes.mady.by.user Benjamin Cheung

Saved on

Key

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

...

  • M1 PROJECT APPROVAL

    • USE CASE TEAMS - The Use Case Teams prepare their proposals. At M1 the project submission, proposal and planning have occurred with the TSC. Use Case teams are cross-functional in nature: they are composed of a leader, developers and also (indirectly) the ONAP platform members & PTLs from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to think about their Data Model. 
      • #1 RELEASE PLANNING TEMPLATE - Use the release planning template to help you think about your scope, minimum viable product, architecture, risks, and epics. The release planning template can be found here: Release Planning Template
      • #2 MILESTONE CHECKLIST - The milestone checklist template contains a master blueprint of all of the major areas of a use case that need to be tracked. The Use Case teams should discuss and fill out for themselves this milestone checklist, and particularly, the product management and release management sections (see below). The major topic areas of the checklist are: documentation (M4), security (M2), product management (M0/M1), release management (M0/M1), testing & integration (RC0-RC2) and development (M4). This checklist can be found at this wiki link: Deliverables for Planning Milestone Checklist Template
      • #3 PROJECT DELIVERABLES - The Use Case teams are defining their project deliverables which include the functional architecture, scope, and dependencies.
      • #4 MODELING TEAM SYNC - The model subcommittee team should become aware of the use cases for the current release. Use Case teams are expected to make presentations to the modeling sub-committee for use cases that may impact the information model. This should open a dialogue between the Use Case team and the modeling to identify model impacts and where there might conceptual overlaps to help streamline the design. The Use Case teams may also be agnostic to the broader information model and contact between the modeling sub-committee and the use case teams will also raise awareness of relevant information models that the Use Case teams will need. At this point, the Modeling sub-committee is using their release planning page to determine what to work on in a release. For an example see this wiki:  ONAP R7 Modeling High Level Requirements
      • #5 EARLY DATA MODEL GROUNDWORK - Because the information model feeds the data models, the Use Case teams should take into account the new updates in the information model as a basis for their data model. The Use case teams should be identifying three things which will help the Modeling subcommittee understand better the model impacts. This will help the modeling team identify areas where model impacts will be. The Use Case teams should define their use cases in more detail ideally using the inputs, outputs and data flows.
        • PRECONDITIONS - Preconditions are the Information the use cases consume.
        • POST-CONDITIONS - The post-conditions can capture the kind of information that is output from the use cases.
        • INFORMATION EXCHANGES - Component-to-component information that is passed, APIs, NBI and external interfaces helps to identify models.
      • #6 TEST CASES & AUTOMATION - To reach M1, a set of high-level test cases should be identified. Some consideration to testing automation for your use case can also get underway. These are important to eventually define in more detail, and link off of in the Use Case wiki for each team. Historically, each use cases has had dedicated testing & integration pages created from either ONAP's integration team or each Use Case team's integration group.
      • #7 REQ-1 - Create your requirements JIRA. Which will be used to track your requirement/use case work in the TSC. Make a Clone ++ of REQ-1. You can listen to the recording of how to do that at: Use Case Realization Call: May 6, 2020

    • WIKI LINKS References for the Use Case Teams at M1

      WIKI LINKS REFERENCE AT M1
      M1DescriptionWiki Link
      #1Release Planning TemplateRelease Planning Template
      #2M1 Milestone ChecklistDeliverables for Planning Milestone Checklist Template
      #4Modeling High Level Requirements

      ONAP R7 Modeling High Level Requirements

      #5REQ-1

      Jira Legacy
      serverSystem Jira
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
      keyREQ-1


    • Project & Release planning tables
    • 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 modeling team. The release platform Information model updates begin. An example template for R7 (Frankfurt) can be seen at this Wiki: ONAP R7 Modeling High Level Requirements
      • #1: Modeling TEAM SYNC - The Use Case teams need to engage the Modeling Sub-committee to make the team aware of potential model impacts arising from their use cases. The modeling team should also become aware of those at a high-level what impacts a use case might have to the release information model. The use cases also need to get into the ONAP Modeling High-level requirements planning page.
    • Architecture - Every release, the architecture sub-committee refines four things: (1) the release functional architecture, (2) impacts arising from component architectures, (3) architecture impacts from requirements & use cases, and (4) architecture enhancement (e.g. new flow updates):
      • #1: FUNCTIONAL ARCHITECTURE IMPACTS - Each release the functional architecture is updated. A link to the functional architecture can be found here: Architecture. The Use Case teams should become aware of proposed functional architecture updates. The Use case teams can reserve some time on the Architecture sub-committee team meeting to align the use cases with the functional architecture and learn about new updates. The Architecture lead (PTL) can also flag impacts of the functional architecture to individual use cases and vice versa.
      • #2: PLATFORM ARCHITECTURE IMPACTS - Each platform component (e.g. A&AI, SO, SDN-C etc) may have architecture changes for the current release. At M1, those should be in the proposal & planning phases within the architecture sub-committee. Use Case teams should become aware of new impacts to the Platform components arising from news use cases & requirements. The idea is that the use case leads would queue some time in a architecture S/C call (or hold a 1-off meeting) to discuss the use cases that may impact platform components for that release.
    • Components (PTL)- Each of the ONAP platform components (e.g. A&AI, SO, Controllers, SDC etc) may be impacted by new use cases. Having the use case leads engage PTLs.
      • #1: COMMITMENT & TRACKING - The use case teams need to engage the Platform component teams and the PTLs if they have impact to that Platform components. Requests for changes to components need to be tracked & get commitment from the PTLs. Ideally, engagement of the PTLs (component lead) should be initiated from the Use Case teams. The Use case team members can attend the component weekly calls to raise awareness. The component teams need to Identify and track Use case impacts in the release planning page. 
      • #2 RELEASE TRACKING PAGE - The release tracking page also tracks Use Case impacts for each of the platform components. For example in R6 you see this wiki: Release Planning

...

  • M4 CODE FREEZE

    • USE CASE / REQUIREMENTS PROJECT TEAMS -

    • CODE FREEZE - The Use Case Teams are delivering the Software for the release. Requirements and use case teams are working to complete their software defined in their jiras and wiki pages. These will include the following tasks listed here.

    • COMPONENT S/W DELIVERY - S/W drops should be coordinated with PTL (components). Sync up with each component and PTLs should be done. Each component that is impact should have already been tracked in M0 and M1. Each of the component S/W impacts should be tracked by Jira tickets. Historically, it is the case that sometimes certain functionality of a component may not be able to be delivered. In this case, an assessment should be made if this will impact other platform components or other aspects of the use case.
    • JIRA TICKETS - Jira tickets should be updated with S/W delivery status. Delayed or Jira tickets that cannot be completed need to be communicated to the ONAP project release manager. Jira tickets that are tracking the overall project, the REQ-tickets need to be updated if there have been changes in content or status.
    • DEFERRED - Deferred elements that could not be delivered in the release should be noted. These can now be scheduled for the next release as generally by M4, the next ONAP release content is already starting to be considered and early planning is occurring.
    • INTEGRATION WORK - Integration work and test-cases should be worked. The integration teams need to be aware of any delays in software component delivery. If there are things can cannot make it into the current release test cases need to be updated.
    • API UPDATES - Swagger updates and API updates should be made if necessary. The API delivery was in M3 however, some things may change going into or during M4 which may cause API updates.

    • JIRA S/W BUGS COMMUNICATED - Tracking new software bugs with Jira tickets as necessary. As new software issues are encountered, they need to be communicated to the release.

    • RELEASE MANAGEMENT REPORTING - During M4, status of the projects are tracked for evaluation and software delivery. Potential delays needs to be communicated to ONAP project management. The TSC will consider and assess the status or each requirement/use case and the health of the release based on the Jira tickets. Any deferrals should be noted with the project management.
    • TSC REPORTING - The TSC is tracking delivery and health of the release at M4
    • MARKETING RELEASE - The marketing report of overall ONAP is being drafted at this point.

    • DOCUMENT GENERATION - Read the docs updates should be made for the Use Case. The read the docs can be found here: https://onap.readthedocs.io/en/latest/index.html

    • The following shows some of the key tasks to be completed at M4 by a PTL.

      TASKTASKitem

      		review License Scan Issues

      Refer to most recent license scan, to determine is license scan are issues and resolve license scan issues.

      If your project issues open source software, it may have licensing issues. For example if open source or proprietary software


      		Merge Requests

      		Address all security Issues

      Security Violation page. Some are common vulnerabilities across all of ONAP.

      Depending on libraries used.


      		FOSS Wiki -

      Maven command to show dependency tree and uploaded. 

      Project FOSS


      		High Priority Jira IssuesHigh Priority Jira Issues and document any remaining open issues.

      		Release Platform Maturity & CII

      Platform Maturity Requirements (S3P).

      Performance stability resilience security Scalability manageability scalablity

      Project Maturity Review for AAI

      CII Badging Scorecard.

      The Analytics (what used to be Bitergia) is used to show the different commits, different project committing, and showing that it is an active projects and the span of committers across different companies. To find outliers, and project not being supported to evaluate for maturity review.

      https://lfanalytics.io/projects/lfn%2Fonap/dashboard


      		Test Coverage

      Verify test coverage goals have been met

      This is done in Sonar Cloud. Sonar cloud shows lines of code that are test are not covered.

      J-Unit tests are cross-indexed against the software and statistics are compiled for each component in Sonar Cloud.

      Overall Line coverage. meaning that the tests cover >50% of the code.

      An example: components:

      https://sonarcloud.io/organizations/onap/projects

      Quality profiles are generated. Bugs, Vulnerabilities; Code Smells, Security hotspots; and Active rules are applied

      and identify code duplication. Suggested Bug fixes.


      		Undocumented Risk

      		Integration Weatherboard

      Integration Weatherboard

      0: Integration Weather Board for Frankfurt Release


      		Update the INFO Yaml

      Review and uupdate the INFO. yaml

      Info about project, life cycle state. Comiters.

      Project meta-data. Stating committers, PTLs etc.

      through Oracle VM VirtualBox

      Keep track of project changers.

      , , , , ,

      Each Micro-service of the project has a INFO.yaml

      Apply for project status:


    • Examples of steps performed at this milestone:

    • MODELING S/C ENGAGEMENT at M4 -

      • PLATFORM INFORMATION UPDATES FROM SWAGGER UPDATES - Any API changes from Use Cases should also be communicated to the modeling team.
      • DOCUMENT GENERATION-  The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the Readthedocs.  Model updates from use case teams can be contributed to that subcommittee.
      • NEXT RELEASE - The Use Case teams can feed input into the next release. The High level modeling requirements page for the next releases are usually being worked near the end of a release. For example, in R7 Guilin release, the R8 Honolulu high level model requirements were open: ONAP R8 Modeling High Level Requirements

    • ARCHITECTURE ENGAGEMENT -

      • Architecture Sync - Any API or Platform component architecture impacts coming from M4 development should be communicated to the architecture sub-committee and updates to the platform component diagrams should be made.

    • COMPONENT (PTL) ENGAGEMENT -

      • Component Deliveries - Platform component deliveries are being made by each of the Use Case Teams. Impacts to components and things might be descoped should be considered. Each of the component teams are working to deliver code by M4.

...

  • RC0/RC1/RC2 RUN-TIME COMPLIANCE

    • USE CASE / REQUIREMENTS PROJECT TEAMS -
      • Integration Tasks must be filled out
      • Test & Integration pages should be filled in.
    • MODELING S/C ENGAGEMENT at M4 -
      • f
    • ARCHITECTURE ENGAGEMENT -
      • S-P - B-
    • COMPONENT (PTL) ENGAGEMENT -
      • D-T - D-p.

ARTIFACTS

  • API

    • API development

    • API Specification

    • Swagger Updates

    • Mapping to Information Model

  • DATA MODEL ARTIFACTS

    • Component Data Model

    • Contains objects, attributes, & relationships (more detail than information model)

    • Mapping to Information Model

    • Feed to Data Dictionary

  • READ THE DOCS

    • Updated Documentation

    • Read the Docs project updates

...




WAY OF WORKING PROCESSES

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.

...