...
MO
- ARCHITECTURE SUB-COMMITTEE - The following are M0 activities with the Architecture Sub-committee
- #1 FUNCTIONAL ARCHITECTURE - The functional reference architecture is the high-level architecture overview diagram for all of ONAP. Enhancements to the functional architecture may be driven by new project proposals, updates to the diagram, and architectural changes that may be planned for the release. At M0 impacts to the functional architecture are proposed.
- #2 COMPONENT ARCHITECTURE - The
- #3 REQUIREMENTS ARCHITECTURE - The
- #4 ARCHITECTURE ENHANCEMENTS - The
- #1: BUSINESS DRIVER TEMPLATE - The Use Case Teams should develop their business driver template and consider their purpose and business impact for their use case. This would detail the executive summary, business impact, business markets, financial impacts and management and strategy. The template for the business driver case can be found here: Business Driver Template for Use Cases
- #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release which focus on defining their business imperatives. When ready, the Team needs to present their business drivers and requirements to the requirements sub-committee. The presentation are given to the Requirements Sub-committee: Requirements subcommittee
- component architecture impacts originate from the ONAP platform components. Examples of platform components are SO, A&AI, CCSDK, SDN-C. Each release there may be architecture impacts from the platform components. At M0, component architecture impact proposals are submitted.
- #3 REQUIREMENTS ARCHITECTURE - These are architecture impacts coming from the requirements and use case work in a release that may impact the functional architecture, platform architecture, or may need architectural guidance. At M0, the requirements and use cases are being proposed for the release. And an early assessment of which ones that might impact the architecture should be considered, and they made translate into requirements architecture proposals.
- #4 ARCHITECTURE ENHANCEMENTS - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include documentation enhancements, landing page enhancements, architecture component description work, flow descriptions and process work. At M0, initial proposals are submitted to the architecture sub-committee.
- ARCHITECTURE SUB-COMMITTEE - The following are M0 activities with the Architecture Sub-committee
WIKI LINKS References for the Use Case Teams at M0
#3: REQUIREMENTS RELEASE TRACKING - After making a presentation to the Requirements sub-committee. Their requirements would then be put into the release proposed functional requirements page. An example for Release 7 (GuiLin) is at this wiki:WIKI LINKS REFERENCE AT M0 M0 Description Wiki Link 1 Functional Reference Architecture Architecture 2 Architecture Portal Page 3 Release Architecture Page 4 Requirements Proposals - #4: USE CASE DEFINITIONS - The team can then use the Use Case Template to fill out more details about their Use Case. The use Case Template can be found here: Use Case Tracking Template
- #5: INTENTION TO PARTICIPATE - Teams can indicate their corporate intention to participate
- #6: RELEASE TRACKING - Each release has a release tracking page. The page can be found here: Release Planning
- #7: PROJECT SUBMISSION, PROPOSAL, PLANNING - The TSC coordinates the project submission, proposal and planning. A project submission, the intention to participate is announced. The TSC reviews and provides its disposition on all submitted projects proposal. In Project Planning closure, the submissions from all of the new projects have been submitted in wiki their Release Planning materials. These are also tracked on the Release Planning page.
WIKI LINKS References for the Use Case Teams at M0
- #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates). The Use Case Teams should engage the modeling team to propose new requirements into their release planning page.
- #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model. Previously designs that need to be added into information model.
- #3: FORWARD LOOKING WORK (FLW) - Modeling future forward looking requirements.
6 Release Tracking page Release Planning Mod Modeling Release Planning Page ONAP R6 Modeling High Level Requirements - Modeling team - At MO the Modeling S/C does MODEL PLANNING. The planning develops into “High Level Info-model Requirements”. These High level info-model requirements fall into 3 categories:
- #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates). The Use Case Teams should engage the modeling team to propose new requirements into their release planning page.
- #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model. Previously designs that need to be added into information model.
- #3: FORWARD LOOKING WORK (FLW) - Modeling future forward looking requirements.
- USE CASE TEAMS At M0, the Use Case teams are working on the following things:
- #1: BUSINESS DRIVER TEMPLATE - The Use Case Teams should develop their business driver template and consider their purpose and business impact for their use case. This would detail the executive summary, business impact, business markets, financial impacts and management and strategy. The template for the business driver case can be found here: Business Driver Template for Use Cases
- #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release which focus on defining their business imperatives. When ready, the Team needs to present their business drivers and requirements to the requirements sub-committee. The presentation are given to the Requirements Sub-committee: Requirements subcommittee
- #3: REQUIREMENTS RELEASE TRACKING - After making a presentation to the Requirements sub-committee. Their requirements would then be put into the release proposed functional requirements page. An example for Release 7 (GuiLin) is at this wiki: Guilin release - functional requirements proposed list
- #4: USE CASE DEFINITIONS - The team can then use the Use Case Template to fill out more details about their Use Case. The use Case Template can be found here: Use Case Tracking Template
- #5: INTENTION TO PARTICIPATE - Teams can indicate their corporate intention to participate
- #6: RELEASE TRACKING - Each release has a release tracking page. The page can be found here: Release Planning
- #7: PROJECT SUBMISSION, PROPOSAL, PLANNING - The TSC coordinates the project submission, proposal and planning. A project submission, the intention to participate is announced. The TSC reviews and provides its disposition on all submitted projects proposal. In Project Planning closure, the submissions from all of the new projects have been submitted in wiki their Release Planning materials. These are also tracked on the Release Planning page.
- PTL- High level release scope from PTLs (understand from PTL which ONAP components are expected to have updates)
- PTL - The Use Case teams should attend the PTL planning meetings if there are expected to be requirements impacts for your use case. It is also where the Release Planning page is developed by the PTL team.
M1
- 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 from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to craft a 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. The major topic areas of the checklist are: documentation, security, product management, release management, testing & integration and development. This checklist can be found at this wiki link: Deliverables for Planning Milestone Checklist Template
- #3 PROJECT DELIVERABLES - are defined including functional architecture, scope, 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.
- #5 EARLY DATA MODEL CONCEPTS - 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 - information exchanges capture the type of information that passes from component to component, APIs, NBI and external interfaces. This helps to identify the relevant models that give that exchanged information structure
WIKI LINKS References for the Use Case Teams at M1
WIKI LINKS REFERENCE AT M1 M1 Description Wiki Link 1 Release Planning Template Release Planning Template 2 Milestone Checklist Deliverables for Planning Milestone Checklist Template 3 Modeling High Level Requirements ONAP R6 Modeling High Level Requirements - Project & Release planning tables
The following are from the Deliverables for Planning Milestone Checklist Template
AREA CHECKLIST ITEM LINK Product Management Are Product Backlog Epics entered in Jira? Are Product Backlog Stories entered in Jira? Create a Backlog item Are Product Backlog Stories linked to Product Backlog Epics? Work in a Sprint Are Product Backlog Stories prioritized? Prioritize a Backlog item Is the project team ready to estimate the top Stories (for coming Sprint) in Product backlog? Estimate a Backlog item Is the project team ready to create a 2 weeks Sprint in Jira? Create a Sprint Are Team Members willing to create Tasks and associate them with Stories in Jira? Create a Backlog item Has the project team plan to contribute to Platform Maturity Improvement? Release Management Is there a Release Planning Template available and completed in wiki? Release Planning Template Has the Platform Maturity Table been updated with current status and Release goal? Casablanca Release Platform Maturity Have all the "Release Components Name" been defined in Resources and Repositories for your project? (this includes all Sub-Components Names, Sub-Components Repositories Names, Maven Group ID, Sub-Components Description) Resources and Repositories Have all the "Resources committed to the Release" been defined in Resources and Repositories for your project? This includes First and Last names, LFID, Email Address and Location for PTL, Project Manager, Committers and Contributors. Resources and Repositories Have new developers made themself familiar on the Onboarding Process? Joining the ONAP Technical Community Is the project team aware of the Release milestone? Any misses will required TSC exception. Release Planning (legacy)
- 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 team. Info-model updates begin. An example template for R6 (Frankfurt) can be seen at this Wiki: ONAP R6 Modeling High Level Requirements.
- #1: SYNC - The Use Case teams need to engage the Modeling Sub-committee to make the team aware of model impacting use cases. The modeling team should also become aware of at a high-level what impacts a use case might have. The use cases also need to get into the ONAP Modeling High-level requirements planning page.
- #1: SYNC - The Use Case teams need to engage the Modeling Sub-committee to make the team aware of model impacting use cases. The modeling team should also become aware of at a high-level what impacts a use case might have. The use cases also need to get into the ONAP Modeling High-level requirements planning page.
- Architecture - Every release, the architecture sub-committee refines the functional architecture, creates new flow updates, and may update component architectures.
- #1: SOCIALIZATION - The Use Case teams should become aware of the new functional architecture and component architecture changes for the current release. Architecture should become aware of new modeling concepts. Cross-fertilization of new requirements, use cases and how they might impact model or how the model impact the upcoming proposed architecture changes. The idea is that the use case leads would queue some time in one of the architecture S/C calls (as a 1-off) to discuss the use cases that may impact platform components for that release. The Use case teams can reserve some time on the Architecture sub-committee team meeting to align the use cases with the architecture. The Architecture lead (PTL) can also flag impacts of the functional architecture to use cases and vice versa.
- 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 data model developed by the use case teams eventually serve as the basis for API changes. Platform components need to update APIs based on new requirements, use cases and features. Requests to components need to be tracked & commitment by the PTLs and components. Ideally the PTLs and component leads should be engaged by the Use Case teams. SDC & A&AI often have more high-running modeling impacts than some of the other components. The modeling team members could attend some of the component calls to raise awareness. Identifying and tracking a modeling impacting item so they aren't lost. An issue impact matrix and tracking page could be developed to track issues (and maybe a Jira ticket).
- #2 RELEASE TRACKING PAGE - The release tracking page also tracks the platform components.
- #1: COMMITMENT & TRACKING - The data model developed by the use case teams eventually serve as the basis for API changes. Platform components need to update APIs based on new requirements, use cases and features. Requests to components need to be tracked & commitment by the PTLs and components. Ideally the PTLs and component leads should be engaged by the Use Case teams. SDC & A&AI often have more high-running modeling impacts than some of the other components. The modeling team members could attend some of the component calls to raise awareness. Identifying and tracking a modeling impacting item so they aren't lost. An issue impact matrix and tracking page could be developed to track issues (and maybe a Jira ticket).
- 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 from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to craft a Data Model.
...