Requirements

  1. All ONAP projects that commit code to a repository are subject to an architectural review.
  2. ONAP projects that do not plan to participate in a release are still subject to architectural review, if they plan to commit code to a repository during the timeframe of the release.
  3. Project teams/Feature Sponsors must demonstrate that they have requested an arch review in order to pass M1.
  4. Arch review status and results will be published in the release notes.

Process

Prior to M1

  1. Project PTLs/Feature Sponsors request a review by email from the chair of the arch subcommittee.
  2. The chair of the arch subcommittee creates a JIRA issue for the review and emails a link to the project PTL.
  3. The project PTL/Feature Sponsor adds the JIRA issue link to the architecture review JIRA task in the M1 epic, as confirmation that a review has been requested.

Prior to M2/M3

  1. The project PTL/Feature Sponsor completed the Component Architecture Description Form and adds a link to it in the architecture review JIRA task.
  2. The project PTL/Feature Sponsor completed the Functional Architecture Description Form and adds a link to it in the architecture review JIRA task. 
  3. The arch subcommittee schedules a review with the project PTL.
  4. At the scheduled time, the project PTL and the Arch Subcommittee meet to conduct the project review:
    1. The project PTL/Feature Sponsor presents the project, including the submitted forms.
    2. The arch subcommittee reviews the changes and asks the PTL questions.
    3. The subcommittee may approve the project at that point, or ask for changes, or additional information, followed by another review.
  • No labels

5 Comments

  1. Catherine Lefevre

    Virtual Event (4/21) question - How does a requirement owner track the impact on multiple components?

    #1 EPIC will be created to capture the requirement description then 1 story per component will be created and these stories will be attached to the EPIC for tracking purpose.

    #2 It is also recommended to update Guilin Impact View per Component 

  2. Trevor Lovett

    Requirement #1 may be overly broad. The VNF Requirements project has some code in its repository, but it's not used by any end users of ONAP.  It just has some simple scripts to automate some documentation quality checks and generate some some documentation like release notes.  Does the arch committee want to review that? My assumption is that your only really interested in projects that deliver, support, or test platform capabilities.  However, if you want us to create architectural reviews it's not that big of a deal.  I'm not sure how many other projects would fit into the space that VNFRQTS occupies.

  3. Eric Debeau

    I agree with Trevor Lovett about Requireemnts #1. Some projects like Documentation, Integration are also developing some scripts or test tools and I am sure that Architecture committee needs to review these projects.

    Requirement #2 is a bit strange. If we need to commit code for a patch, why does the need an architecture review ?

    Prior to M2/M3: OK to complete the Component Architecture Description. How do we maintain consistency between this description and the code delivered ?

    Step 4c => what happens if the subcommittee does not approve the project ?

    Globally I believe that we are still following a waterfall process. We should globally review our  process to get more agility and spend more time on developing/testing/documenting

  4. Catherine Lefevre

    Chaker Al-Hakim - can we integrate to this process prior M1 - ONAP Project and Component Lifecycle review?


  5. Gervais-Martial Ngueko

    It will be helpful to put the link to "Component Architecture Description Form" and "Functional Architecture Description Form" templates/samples, this will help newcomers quickly get an idea of what is the content expected for those 2 forms.