...
MO
- ARCHITECTURE SUB-COMMITTEE - The following are M0 activities with the Architecture Sub-committee. Release content defined.
- #1 FUNCTIONAL ARCHITECTURE (Proposals) - 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 (Proposals) - The 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. Architecture reviews are setup & scheduled for component architecture impacts/proposals. Component architecture diagrams would be updated.
- #3 REQUIREMENTS ARCHITECTURE (Proposals) - 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. Architecture reviews are setup & scheduled for requirements architecture impacts/proposals.
- #4 ARCHITECTURE ENHANCEMENTS (Proposals) - 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.
WIKI LINKS References for the Use Case Teams at M0
WIKI LINKS REFERENCE AT M0 M0 Description Wiki Link 1 Functional Reference Architecture Architecture 2 Architecture Portal Page https://safratech.net/onapdocs/ 3 Release Architecture Page All of the architecture reviews that were conducted:
4 Requirements Proposals 6 Release Tracking page Release Planning Mod Modeling Release Planning Page ONAP R7 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 are specifying their business drivers via the template: Business Driver Template for Use Cases
- #2: REQUIREMENTS SUB-COMMITTEE - Develop their proposals for the release to the Requirements Sub-committee: Requirements subcommittee
- #3: REQUIREMENTS RELEASE TRACKING - After making a presentation to the Requirements sub-committee, requirements are put into the release proposed functional requirements page. An example for Release 7 (GuiLin) is at this Example wiki: Guilin release - functional requirements proposed list
- #4: USE CASE DEFINITIONS - Use Case team fill out the Template detailing their Use Case: 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. The TSC reviews and provides its gives disposition on all submitted projects proposalproposals. These are also tracked on at 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.
- ARCHITECTURE SUB-COMMITTEE - The following are M0 activities with the Architecture Sub-committee. Release content defined.
APIs producing consuming at architecture review
Modeling S/C to understand - Identify APIs information that retreiving updating across those APIs.
Esp. anything NEW. Info-Model → impacts exposing new stuff on an API indicating new information being shared should have RELATED Modeling
Here's new INFO on expensing
Devloping updates on an API. related info-modeling activity.
M1
- ARCHITECTURE SUBCOMMITTEE leading up to M1 -
- #1 FUNCTIONAL ARCHITECTURE (
M1
- ARCHITECTURE SUBCOMMITTEE at M1 -
- #1 FUNCTIONAL ARCHITECTURE (Requirements) - 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 (Requirements) - The 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 (Requirements) - 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 (Requirements) - 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.
- WIKI LINKS References for Architecture at M1
The following table has the links for important M1 architecture pages
WIKI LINKS REFERENCE AT M1 M1 DESCRIPTION WIKI LINK 1 Architecture Portal Page https://safratech.net/onapdocs/ 2 Architecture Release Page 3 Milestone Checklist Deliverables for Planning Milestone Checklist Template 4 x
- USE CASE TEAMS - The Use Case Teams prepare their proposals. The Use case teams are defining their requirements and detailed proposals. 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 Case teams 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 are used by the Use Case teams. 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 WORK - The model subcommittee team becomes aware of the use cases for the current release.
- #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.
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 The following are from the Deliverables for Planning Milestone Checklist Template
AREA CHECKLIST ITEM LINK 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.
- ARCHITECTURE SUBCOMMITTEE leading up to M1 -
M2
- Use Case Team Engagement -
- FUNCTIONAL TEST CASES - Each Project team has defined and documented their Functional Test Cases.
- API DOCUMENTATION - The Use Case Teams have identified the API that they will be introducing in the current release and at least started to document that API changes that are associated with their use case. The APIs need to be documented and available in the Use Case Wiki.
- VNF REQUIREMENTS - Base set of impacts to VNF Requirements identified by use case/ project.
- INFORMATION & DATA MODEL DEVELOPMENT - Discussion Info Model & Data model development by Use Case team with input from the Modeling sub-committee. Active discussion and interaction between Use Case Team and the Modeling S/C to make sure that the information model and the data model development are in lock-step. The modeling sub-committee will communicate the clean release information model as a refining input to the development of the data model for use by the Use Case Teams on specific projects.
- INFORMATION & DATA MODEL REVIEW - Reviews of Data Model with Project (Use Case) Teams. The Data Model is being reviewed by the Use Case Teams with inputs from the Modeling S/C by bringing the developing data model (in the discussion state) to the modeling S/C. It would not be feasible to for the members of the modeling S/C to attend all of the various U/C meetings; although one-off sync-ups might occur in this stage. For those U/C that have significant data modeling work, it would be advised that that U/C team reserves a slot in the modeling S/C meeting(s) to present their data modeling changes and information flows so that the modeling S/C team can advise the U/C team as they develop their data model.
- MAPPING BETWEEN INFORMATION & DATA MODEL - Mapping of information model and the data model is also done between the modeling S/C and the Use case teams. This might happen in the project teams, or on the modeling S/C calls.
- CROSS REFERENCING JIRA TICKETS - The modeling S/C uses Jira tickets to track activities; and the Use Case teams also use Jiras to track platform work, modeling work, epics & stories. So it would be smart to link or associate relevant Jira tickets together.
- JOINT REVIEWS - The Data model should be reviewed with the Modeling S/C. Data model being developed by the component team is using the component model as input.
- FUNCTIONALITY IDENTIFIED - The release intended functionality has been identified, agreed to and frozen. No new visible functionality is to be added to the current ONAP release at the point of M2.
- MODELING SUBCOMMITTEE -
- For the RELEASE Information Model these are the activities that the Modeling sub-committee is engaged in leading up to M2.
- RELEASE INFORMATION MODEL (Starting Point) - The release starts with a clean release information model from the PREVIOUS release (with all of its attendant contributions). Then new contributions of the current release are considered (see below the process for handling each specific contribution). Potentially a snapshot of the papyrus model and posted into the current release. The RST documentation that only contains things in the current release or everything that is approved.
- TERMS & CONCEPTS -
- IISOMI STATES - The concept of IISOMI states describes the state of individual classes, attributes, and associations/relationships. IISOMI states are noted within the elements of the contribution. For example, a particular parameter might be in the experimental state while another class might be tagged as in the preliminary state. These preliminary and experimental are states that are mutually exclusive so you can't have a class/attributes with two different IISOMI states simultaneously. During the discussion phase, the elements of the contribution should be out of experimental state. The exception is that there is a state of reference that can exist with other states. Some elements within the contribution could have different IISOMI states. The webpage for the IISOMI states can be found at: Informal Inter-SDO Open Model Initiative (IISOMI)
- DELAYED ELEMENTS OF THE RELEASE INFO-MODEL - This may happen that are out of the control the modeling S/C. Use Cases get delayed, or a discussion can't wrap up. So, there could be a corner case where, for example, one or more things (parameters/classes) in a contribution can't make the current release (it stay experimental), what would happen to the overall contribution or release information model (is it allowed to go clean). This would not stop the other parts of the contribution or the release information model from going to a clean state. #@# Example, Dynamic parameters in the common sub-model, generates the whole model then manually edited down to the DP. if things are marked experimental it will show experimental. Keep of Track (experimental?) communicate? reviews?
- INFORMATION MODEL FREEZE - The aggregate / release information model for the release is approved by association with the fragment/ component reviews. Each of the fragment (contributions) are individually approved, thus there is not a "re-approval" or approval of the entire aggregate (release) information model. Editorial clean-up such as misalignments, typos, or sections that were not put in proposal, fixing the template for GenDoc.
- RELEASE INFO MODEL DECLARED CLEAN - After component reviews have concluded and release info model freeze by the modeling S/C the info model is called the "clean model" in this phase. At this point, the Use Case teams that are developing the Data Model can be pretty certain that the information model will be usable as shown. The diagrams and model wiki pages will indicate that this is a clean model. Put into the information model for that release. Unfinished contributions are postponed or discussed further.
- DISCUSSION OF CONTRIBUTIONS - Each contribution discussed according to following process. This is where refining of each of the contribution models occurs by the Modeling Sub-committee (S/C). The release information model is not separately tracked, composed, updated, or released in this period of time. But, rather, each individual contribution has its own Wiki. Thus, for each contribution:
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
- An individual model contribution is a model that will eventually be a part of the total release information model. It is generally a self-contained model which depicts a particular capability or function of the system. This contribution starts as a "input contribution" and undergoes consideration by the modeling sub-committee. Consideration means that the modeling S/C is entertains & assesses if the input contribution should be accepted into the current (or a future release) by weighing the contribution against its relevance and the available resources (modelers) in the release. If the team thinks that the contribution is not ready for the current release that contribution will be put into a lower-priority and worked if there are no other contributions to be considered as they would take higher priority. Thus, the contribution would not necessarily be rejected, but would get attention as time allows.
- REVIEW & REFINE CONTRIBUTION - START: Contribution in Discussion State (verb Reviewing & Refine) END: Contribution in Discussion state
- The contribution undergoes reviewing & refining during the discussion state. Reviewing & refining means that the modeling S/C is discussing the modeling, and updating the contribution based on feedback and comments from the modeling team. Each contribution can be reviewed and refined independently and concurrently with other contributions. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
- FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Contribution in Discussion State (verb Approving/Poll) END: Contribution in Discussion state
- (a) FINAL PRESENTATION - When the contribution has gotten to a point where the team feels that it can start to undergo the approval process, the contribution is brought one final time the modeling S/C for discussion and socialization.
- (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a sub-team lead to the modeling team whereby final thoughts & input can be given. This final call for comments signals that the discussion is wrapping up for this contribution and will soon go to a poll.
- (c) INITIATING POLL - After final call and no further outstanding comments exist, the contribution is brought to a poll by a sub-committee chair. A poll is created whereby modeling S/C members can give the contribution a vote of "yes" or "no".
- APPROVING CONTRIBUTION - START: Contribution in Discussion State Post-Poll (verb Approving) Contribution in Clean State
- After the poll has concluded, the contribution has finished the approval process. The contribution is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state. A gendoc is generated and put on the wiki page. The gendoc would be translated and published on the readthedocs site.
- STEREOTYPE CHECK - The entities in the model has an experimental stereotype (down to the attribute level) when they are a proposal, when approved/clean, all of the entities in that proposal bear change from experimental to preliminary. Stereotypes can be on classes, attributes, data types and relationships. It is an ISOMII add into the model, at a high-level in the model things get stereotypes. E.g. when we approved the first VES model, which has many entities and many attributes; to update all of those from experimental to preliminary was tough. A stereotype is a status marker. Preliminary is approved for development.
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
- Use Case Team Engagement -
- Project & Release planning tables
The architecture checklist is from the Deliverables for Planning Milestone Checklist Template
AREA CHECKLIST ITEM LINK Architecture Ax Axr Ha x Is tx Ha Is txp
- 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.
- 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).
APIs producing consuming at architecture review
Modeling S/C to understand - Identify APIs information that retreiving updating across those APIs.
Esp. anything NEW. Info-Model → impacts exposing new stuff on an API indicating new information being shared should have RELATED Modeling
Here's new INFO on expensing
Devloping updates on an API. related info-modeling activity.
M2
- ARCHITECTURE SUBCOMMITTEE leading up to M2 -
- #1 FUNCTIONAL ARCHITECTURE (Architecture Reviews) - 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 (Architecture Reviews) - The 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 (Architecture Reviews) - 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 Reviews) - 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.
- Use Case Team Engagement -
- FUNCTIONAL TEST CASES - Each Project team has defined and documented their Functional Test Cases.
- API DOCUMENTATION - The Use Case Teams have identified the API that they will be introducing in the current release and at least started to document that API changes that are associated with their use case. The APIs need to be documented and available in the Use Case Wiki.
- VNF REQUIREMENTS - Base set of impacts to VNF Requirements identified by use case/ project.
- INFORMATION & DATA MODEL DEVELOPMENT - Discussion Info Model & Data model development by Use Case team with input from the Modeling sub-committee. Active discussion and interaction between Use Case Team and the Modeling S/C to make sure that the information model and the data model development are in lock-step. The modeling sub-committee will communicate the clean release information model as a refining input to the development of the data model for use by the Use Case Teams on specific projects.
- INFORMATION & DATA MODEL REVIEW - Reviews of Data Model with Project (Use Case) Teams. The Data Model is being reviewed by the Use Case Teams with inputs from the Modeling S/C by bringing the developing data model (in the discussion state) to the modeling S/C. It would not be feasible to for the members of the modeling S/C to attend all of the various U/C meetings; although one-off sync-ups might occur in this stage. For those U/C that have significant data modeling work, it would be advised that that U/C team reserves a slot in the modeling S/C meeting(s) to present their data modeling changes and information flows so that the modeling S/C team can advise the U/C team as they develop their data model.
- MAPPING BETWEEN INFORMATION & DATA MODEL - Mapping of information model and the data model is also done between the modeling S/C and the Use case teams. This might happen in the project teams, or on the modeling S/C calls.
- CROSS REFERENCING JIRA TICKETS - The modeling S/C uses Jira tickets to track activities; and the Use Case teams also use Jiras to track platform work, modeling work, epics & stories. So it would be smart to link or associate relevant Jira tickets together.
- JOINT REVIEWS - The Data model should be reviewed with the Modeling S/C. Data model being developed by the component team is using the component model as input.
- FUNCTIONALITY IDENTIFIED - The release intended functionality has been identified, agreed to and frozen. No new visible functionality is to be added to the current ONAP release at the point of M2.
- MODELING SUBCOMMITTEE -
- For the RELEASE Information Model these are the activities that the Modeling sub-committee is engaged in leading up to M2.
- RELEASE INFORMATION MODEL (Starting Point) - The release starts with a clean release information model from the PREVIOUS release (with all of its attendant contributions). Then new contributions of the current release are considered (see below the process for handling each specific contribution). Potentially a snapshot of the papyrus model and posted into the current release. The RST documentation that only contains things in the current release or everything that is approved.
- INFORMATION MODEL FREEZE - The aggregate / release information model for the release is approved by association with the fragment/ component reviews. Each of the fragment (contributions) are individually approved, thus there is not a "re-approval" or approval of the entire aggregate (release) information model. Editorial clean-up such as misalignments, typos, or sections that were not put in proposal, fixing the template for GenDoc.
- RELEASE INFO MODEL DECLARED CLEAN - After component reviews have concluded and release info model freeze by the modeling S/C the info model is called the "clean model" in this phase. At this point, the Use Case teams that are developing the Data Model can be pretty certain that the information model will be usable as shown. The diagrams and model wiki pages will indicate that this is a clean model. Put into the information model for that release. Unfinished contributions are postponed or discussed further.
- DISCUSSION OF CONTRIBUTIONS - Each contribution discussed according to following process. This is where refining of each of the contribution models occurs by the Modeling Sub-committee (S/C). The release information model is not separately tracked, composed, updated, or released in this period of time. But, rather, each individual contribution has its own Wiki. Thus, for each contribution:
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
- An individual model contribution is a model that will eventually be a part of the total release information model. It is generally a self-contained model which depicts a particular capability or function of the system. This contribution starts as a "input contribution" and undergoes consideration by the modeling sub-committee. Consideration means that the modeling S/C is entertains & assesses if the input contribution should be accepted into the current (or a future release) by weighing the contribution against its relevance and the available resources (modelers) in the release. If the team thinks that the contribution is not ready for the current release that contribution will be put into a lower-priority and worked if there are no other contributions to be considered as they would take higher priority. Thus, the contribution would not necessarily be rejected, but would get attention as time allows.
- REVIEW & REFINE CONTRIBUTION - START: Contribution in Discussion State (verb Reviewing & Refine) END: Contribution in Discussion state
- The contribution undergoes reviewing & refining during the discussion state. Reviewing & refining means that the modeling S/C is discussing the modeling, and updating the contribution based on feedback and comments from the modeling team. Each contribution can be reviewed and refined independently and concurrently with other contributions. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
- FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Contribution in Discussion State (verb Approving/Poll) END: Contribution in Discussion state. The modeling team issues a call for comments and poll for each contribution.
- APPROVING CONTRIBUTION - START: Contribution in Discussion State Post-Poll (verb Approving) Contribution in Clean State
- After the poll has concluded, the contribution has finished the approval process. The contribution is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state. A gendoc is generated and put on the wiki page. The gendoc would be translated and published on the readthedocs site.
- CONSIDER CONTRIBUTION - START: Input Contribution (verb Consider) END: Contribution in Discussion State
- M2 ARCHITECTURE WORK - Before M2, the architecture team is working to refine their Functional Architecture, the component architecture, and Architecture proposed enhancements. Conceptually, many would consider the development of the release information model as actually architecture work. Thus, engaging the actual architecture sub-committee during the point in the time that the release information model is becoming frozen is important.
- SYNC UP - The architecture sub-committee should have a sync up with the modeling sub-committee to have a check-point to share the release information model. The key triggering milestone is that the release information model has just achieved a clean state, and the architecture sub-committee should be aware of this, and some of the highlights in the model. For example, the key contributions in the release that comprise the model. The modeling sub-committee should get on the agenda of the architecture S/C or vice versa when the release information model is ready. Alternatively, a regular sync up with the architecture sub-committee, such as once a quarter or bi-annually could also serve this purpose.
- ARCHITECTURE SUBCOMMITTEE leading up to M2 -
- Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) review clean Information Model impacts for the release.
- FEEDBACK - Component platform work can feedback to the Modeling S/C for updates to the information model during the refining the info model phase and should also provide input during the review. Modeling S/C should take into account component platform updates vis-a-vis the Use Case and modeling requirements for the release.
- SOCIALIZATION - The socialization of the clean release information model should include updates for the PTLs. The platform PTLs must become aware that the clean release information model has gone to approval. The PTLs also attend the TSC. An email to the PTLs. Possibly a joint call with the PTLs in attendance might help to socialize the information model. Because this is a major milestone of the modeling S/C. Perhaps a modeling notification email distribution list could be made that would send major updates from the modeling S/C and that would not flood notifications from the modeling team. An email announcement of polls, in this case the baseline of a clean release information model.
...