Purpose
This template is to be used for the “Parallel Deep Dive Sessions to Align with architecture / Use cases” at the may ONAP developers event
Instructions.
The purpose of each section is to translate the use cases and functional architecture into specific identified needs for the components, and to identify potential projects to be proposed. There are three parts to this exercise:
- Identify needs based on the use case and architecture on this module, and potential dependencies on other modules or external artifacts.
- Group these into projects. Consider that coding, documentation, and testing is required. Include an initial scope for the project.
- If time, mapping the needs into the projects.
The need identification table has the following columns
- Identified need: <slogan for the identified need>
- Brief need description: <a few sentences describing the need>
- Driver:<Related use case or architecture change, if any>
- Dependencies:<identify dependencies on other modules or artifacts (e.g. other onap module, models, …)
- Project: <If time, after the projects are identified, suggest in which project the need would best fit>
Time keeping suggestion: The exercise time is 45 minutes. A good practice would be to split into 20 minutes on need identification and 20 minutes on project proposals.
Exercise output.
ONAP Meeting Session name: <insert onap module name>
Need Identification:
Identified Need | Description | Driver | Dependencies | Project fit |
| Normalization ECOMP/OPEN-O | Need for normalizing Data Collection | 1 | ||
| TOSCA Alignment (Service Modeling) | On-Boarding Artifacts with Service Creation on Evetn | 1 | ||
| Co-Project with CLAMP (Control Loop) | Control Loop Creation to get to an Action | 2 | ||
| Role of Infrastructure Events (AIC, Other Cloud) | Control Loop Creation to get to an Action | 3 | ||
| Event Trigger Scenarios Related to Life Cycle Management | How configurable parameters can be changed within VNF Deployemnt/Life Cycle. | 3 | ||
| Role of PNF in DCAE | PNF Data Collected and if handled by DCAE | 1 | ||
| Building Catalogue | We need a catalogue of what data is colected what building blocks are used | 1 | ||
| Micro-Services | How Micro-Service to be used and catalogued | 1 | ||
| VES | Define VF Evetn Screaming and its use by ONAP | 1 | ||
| DCAE Controller: Federation - Edge/Central | DACE Component Placement | 1 | ||
| Improve DCAE/Controller Environment, Evolution | Relation ship between DCAE and ONAP Controller and its evolution | 1 | ||
| New User Case Support | Support fo New Use Cases | 3 | ||
| Improve DCAE/Controller Environment, Evolution | Relation ship between DCAE and ONAP Controller and its evolution | 3 | ||
| Predictive Analytics | Data used for Soft Alarms | 3 | ||
| Artificial Intelligence/Machine Learning | Using intelligence based on Data Stored to take intellegent actions | 3 |
Project proposals.
[repeat for each project. Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]
Project 1:
Project Name:
-
Project Description
- Provide a high level description of the project
Scope:
- Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
- Identify baseline code (if any)
Project 2:
Project Name:
- Provide a brief project name.
Project Description
- Provide a high level description of the project
Scope:
- Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.
- Note of any particular deliverables to highlight.
- If anything is out of scope, not it down
Other:
- Identify baseline code (if any)