You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This centralized page, for all Beijing projects, is aimed at identifying the risks as they are foreseen within the release lifecycle.

A Risk that materialized becomes an Issue.

Status:

  • Identified: a risk that has been identified, but has not yet been analyzed / assessed yet 
  • Assessed: an identified risk which currently has no risk response plan 
  • Planned: an identified risk with a risk response plan
  • In-Process: a risk where the risk response is being executed 
  • Closed: a risk that occurred and is transferred to an issue or the risk was solved/avoided
  • Not occurred: a risk that was identified but that did not occur 
  • Rejected: created and kept for tracking purposes but considered not to be used yet


Risk ID

Project Team or person identifying

the risk

Identification

Date

Risk

(Description and potential impact)

Team or component impacted by the risk

Mitigation Plan

(actions to prevent the risk to materialize)

Contingency Plan - Response Plan

(actions in case the risk materialized)

Probability of occurrence

(probability the risk

materialized)

High-Medium-Low

Impact

High-Medium-Low

Status
1Katel343/12/2018CII Badging - Beijing Release Criteria is addressing Critical Security issues (7-10) but not Severe Security issues (4-6) identified by Nexus IQ Server. Therefore some projects might not pass their CII BadgingAny Project team who has marked 'Unmet' concerning "There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days"Fix any remaining Severe security issue post-M4 that will not jeopardize the Integration Testing activities (no major architecture change)Provide an impact analysis about the remaining "Severe" security vulnerabilities and a delivery plan as part of the Casablanca Release.HighMediumAssessed
2SDC3/12/2018

ONAP DM Modeling SDC Requirements

2 new sets of normative types are required from the Modeling team:

  1. Tosca NFV-based types to replace the current types used in the VOLTE use case.
  2. ETSI SOL-based set of types to support the HPA functionality.

Impact on vVOLTE Use Case

SDC impacted by Modeling project

To be able to meet M4 all this items need to be delivered by 3/16/2018 :

  1. The 2 new sets of normative types be onboarded into SDC.
  2. The CSAR need to be updated and validated in SDC.


If not then VoLTE use case will not be re certified by M4.

Descope this SDC Feature to support DM ModelingHigh

High

Assessed










  • No labels