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 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Katel34 | 3/12/2018 | CII 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 Badging | Any 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. | High | Medium | Assessed |
| 2 | SDC | 3/12/2018 | ONAP DM Modeling SDC Requirements 2 new sets of normative types are required from the Modeling team:
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 :
If not then VoLTE use case will not be re certified by M4. | Descope this SDC Feature to support DM Modeling | High | High | Assessed |
| 3 | APPC | 3/13/18 | Late delivery of Nitrogen ODL We were expecting to be integration newer version of ODL in Sprint 2; however, due to late delivery, this work is falling into the last sprint for Beijing release. Nitrogen brings a lot of changes that will make the component unstable until completed and will impact testing, plus may take longer than 1 sprint to complete. In Amsterdam, it took us a couple of sprint to work through issues and there were a number of fixes that were needed in CCSDK discovered as we attempted integration. I expecting that we will have similar experience. | APPC | We are being trying to prioritize the features in APPC and update those that are needed for Beijing as top priority. Also working closely with CCSDK PTL on any issues found in CCSDK that may block us. | There is no alternative plan. CCSDK cannot support multiple versions of ODL at this time. | Medium at this time; will monitor to see how it goes in the next week and determine if risk level needs to change | High | Assessed |
| 4 | APPC | 3/13/18 | Late delivery of AAF-91 dependency This feature was expected by 2/15; however, as of 3/13, delivery of feature has not been received yet. Demo of feature provided did not deliver the requested scope. | APPC SDNC | Working closely with AAF team to get gap addressed to enable APPC to deliver AAF integration to secure APIs exposed via ODL apidoc. Based on current discussion with AAF team, we expect this to be a configuration change on APPC only. If that turns out not to be the case, delivering APPC-404 by code freeze may not be possible. | De-scope APPC-404 in Beijing and address in Casablanca. | Medium at this time; will monitor to see how it goes in the next week and determine if risk level needs to change. | Medium | Assessed |
| 5 | SO |
| Code Merge from ATT Ecomp 1806 to ONAP SO Risk as identified at M1 and M2 has materialized. ATT code is not merged yet. This may impact code quality (static code checks, security vulnerabilities and Licensing) and code coverage. Code merge may impact other current development. Code Merge is currently planned by March 14. | SO | Working closely for the merge to be on time. Code merge has been completed on 14th March and around 82K lines of added+ Modified code has been introduced new. | Need to re-asses the functional features commitment. | High | High | In Process |
| 6 | VF-C | 3/12/2018 | VF-C have planned to implement ETSI NFV compliant API in Beijing, some of the committing companies raised the IPR issue. VF-C also asked about LF suggestions.In order to avoid risks, the LF suggested that VF-C hold contribution until Casablanca or the intermediate version of Beijing and Casablanca | VF-C | VF-C hold contribution until Casablanca or the intermediate version of Beijing and Casablanca | VF-C provide the R1 APIs | High | Low | Assessed |