Versions Compared

Old Version 3

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version Current

changes.mady.by.user Benjamin Cheung

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It illustrates 5 stages that the Use Case teams are concerned with, the High Level requirements, to the release plan, defining the use case, to data model development, to API freeze and code development.

Image Removed

Use Case Teams Process

  • MO

    • USE CASE TEAMS - The Use Case Teams prepare their proposals.
      • #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

...

  • #1: NEW USE CASES - items from the expected Use Cases in the release (Scope of modeling, continuing, introducing, standards updates).
  • #2: REFINING EXISTING MODEL - There are also Existing high level info-model requirements and the current release is focused on continuing or refining the model. Existing in a component that hasn't made it to the information model. Previously at design build-level that needs to be added into information model. For example, a need might have arisen in development but wasn't formalized. Long-lead, multi-release items might fall into this category. coded previously but no Use Case.
  • #3: FORWARD LOOKING WORK (FLW) - Forward thinking requirement. For example, suppose there were a very large use case/requirement or project that is expected to come down the pipe, but if no advanced modeling work were done on it, it wouldn't make the current release. Thus, a model might be proposed in advance of the actual use case/requirement.

...

M1

...

  • #1: MODELING REQUIREMENTS - A description of each of the modeling requirements are described in more detail. This can be contributed from the modeling team, PTLs or the Use Case teams.
  • #2: USE CASE RELEVANCE - The relevance of use cases are identified and Use Case teams can give a more detailed explanation for use case requirements and how they tie to the high-level requirements. This allows for experts in the Info-model team to identify what fields of the existing info model could be enhanced and become aware of where the impacts are. 
  • #3: IMPACTED PROJECTS - The impacted projects from the info-model requirements (e.g. SO, VID, SDC etc) are identified. The tie-in from the ONAP platform components to the high level-modeling requirements are described.
  • #4: OVERLAPPING PROPOSALS - Overlapping info-model impacts from different use cases or forward looking work (FLW) are identified.
  • #5: MODEL REUSE - Finding Overlap from different use case and requirement proposals that are evaluated will lead to identifying where model reuse can occur. By the end of the Model overlap analysis overlapping areas will either cause overlaps to be merged or altered.
  • #6: OWNER - The owner(s) for the item are identified. The owners might be PTLs, Modeling subcommittee, or Use Case team.
  • #7: PRIORITY - A priority is identified for the info model requirements. these are general given by service providers or modeling subcommittee. A suggested High/Medium/Low is sufficient at this stage.
  • #8: LOWER PRIORITY - Lower priority requirements are generally considered as "nice to haves". Low priority requirements are captured in the info-model plan and are documented.
  • #9: DOCUMENTATION AFTER IMPLEMENTATION - Some modeling requirements are related to documenting implementation after the fact. When the model plan is established, this category of info-model requirements are identified and described in the info-model plan.
  • #10: FORWARD LOOKING WORK (FLW) - FLW is another class of requirements which are intended to recognize future needs.

...

  • #1: SOCIALIZATION - The model 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.
  • #2: DATA MODEL - 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 kind of information shown in this template: Proposed Functional Template for Use Cases
    • 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

...

  • #1: SOCIALIZATION - Modeling team becomes 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 modeling S/C leads would queue some time in one of the architecture S/C calls (as a 1-off) to discuss the information model for that release and vice versa. Another possibility would be to reserve some time on the Architecture sub-committee call either on a regular basis or when the modeling S/C team is about to accomplish an objective, or about to make a vote on something (to call for consensus). It would also be good if the Architecture lead (PTL) could identify modeling impacts and flag them as they come across them.

...

  • #1: COMMITMENT & TRACKING - The data model eventually serves as the basis for API changes and development. 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).

Atomic requirements are expected to be grouped together to coalesce into a Use Case. And the Use Case teams would work on a set of related requirements to deliver a "minimum viable product". The requirements sub-committee tracks individual requirements, but this process page discusses a process at the Use Case level. Requirements are often subsumed within a Use Case, but the reverse is not true (a Use Case is not subsumed within a Requirement).

A new process starting R7 is trying to also introduce the concept of working on atomic requirements, which may have Requirements team working on just that one requirement.

A Use Case teams are cross-functional in nature: they are composed of a use case leader, developers/committers/contributors, and also (indirectly) the ONAP platform members & PTLs from components that need to be involved. Use case teams are dynamic in nature, they are formed when new use cases are defined.

Image Added


Diagram showing the cross-interaction with other teams:

Image Added

Use Case Teams Process

  • MO PROJECT PROPOSALS

    • USE CASE TEAMS - The Use Case Teams prepare their proposals.
      • #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 Use Case owner would propose and select the requirements that would be worked on in that release. The requirements Sub-Committee can evaluate and identify cross-interactions between proposals. The requirements S/C can make prioritization recommendations to the TSC. The TSC (with EUAG input) can then make a decision to adopt or alter the prioritization recommendations. The presentation are given to the Requirements Sub-committee: Requirements subcommittee (is merged into ARCCOM)
      • #3: REQUIREMENTS PROPOSALS - 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. Note: (see above), again, a Use Case is a comprised of a set of Requirements. 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. Wiki can be found here: Release Planning . You will need to clone REQ-1 (see link below)
      • #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.
      • #8: MODEL PLANNING - If you have model impact add to the model planning page ONAP R7 Modeling High Level Requirements

  • WIKI LINKS References for the Use Case Teams at M0

    WIKI LINKS REFERENCE AT M0
    M0DescriptionWiki Link
    1Business Driver TemplateBusiness Driver Template for Use Cases
    2Requirements S/CRequirements subcommittee (is merged into ARCCOM)
    3Functional Requirements ProposalsGuilin release - functional requirements proposed list
    3aRequirements TemplateTemplate to be fulfilled per each requirement
    4Use Case Tracking TemplateUse Case Tracking Template
    6Release Tracking page

    Release Planning (R6)

    https://wiki.onap.org/display/DW/Guilin+Release+Requirements (R7)

    ModModeling Release Planning Page

    ONAP R7 Modeling High Level Requirements

    Modeling Current Activity Status

    ModGeneric Information Element Template

    If you think you have modeling impact fill out the following template and include in your project Wiki Page:

    Generic Information Element Template

    ArcArchitecture Reference ArchitectureArchitecture
    ArcArchitecture S/C presentation Template

    R7 Guilin Architecture Review (template) - functional requirements

    Project Architectural Review Requirements and Process (Draft)

    REQ1Requirement Template

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-1

    INSTRUCTIONS: Documenting Release Requirements and Use Cases in JIRA

    • Project component (A&AI, SDNC SO etc) impacts, and test only impacts
    • Create an user story per impacted project
    • Which companies will develop and test each requirement per component?
    • How many developers per component?
    • Date for your Architecture sub-committee Review? and LINK.
    • Date of Requirements Review

    (REQ-1 TEMPLATE):

    Project (ONAP Component) IMPACT: TO/C
    * Impact Type: TO/C (Test-only/Code)
    * Companies Supporting: xyz
    * Resources: xyz
    * NFR Support: xyz (support for non-functional requirement)

    Story

    Jira

    		Creating STORY JirasCreate a STORY Jira per impacted Project


  • 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 Requirements/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. An example of the Modeling S/C planning page for R6 is here: ONAP R7 Modeling High Level Requirements
    • #2: REFINING EXISTING MODEL - Refining Existing info-model that has not made it to the information model; Use case teams to be aware of these changes to the model.
    • #3: EXPERIMENTAL WORK - At this stage, the Use Case/Requirements teams may not be entirely sure of modeling impacts; They should still schedule into the Modeling Roadmap (as Experimental).
  • Architecture - The Architecture team should be aware of any major updates coming from the requirements & use case teams. If there is architectural impact arising from your use case or requirements comprising your use case, you can make presentations at the Architecture sub-committee meetings. Changes may include impacts to the functional architecture, or platform architecture.
    • #1 ARCHITECTURE PROPOSALS - Teams must make Architecture sub-committee presentations following the template: R7 Guilin Architecture Review (template) - functional requirements

    • #1a REQ link to ARCH-Jira link

      Steps to LinkDescription
      Link your REQ Jira to the ARCH-jira
      1. Before a requirement may be reviewed by the arch subcommittee, the requirement must be documented in JIRA (REQ), and the REQ reference must be submitted when requesting an arch review.
      2. After the arch review subcommittee has completed its review and made a determination, please add an issue link to the REQ issue for your review.
        1. Navigate to your requirement issue in JIRA (REQ)
        2. Select edit
        3. Scroll down until you find the "Linked Issues" field (see attachment)
        4. Make sure that the link type is "Is blocked by" (see attachment)
        5. Add the JIRA reference for your arch review (ONAPARC) to the "issue" field. (see attachment)
        6. Click the "Update" button.


    • Image Added
    • #2: PROCEDURE - Schedule presentations with the Architecture sub-committee Project Architectural Review Requirements and Process (Draft)
  • PTL - The Use Case teams should engage the PTLs to inform them that the requirements in the use cases may have impact to their particular platform component. This can be done via attending the individual component meetings or coordinated at the Use Case Realization calls. Often, the platform components each have a release planning page as well.


  • M1 PROJECT APPROVAL

    • 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 & PTLs from components that need to be involved. Working towards M1, the Use case teams are defining their requirements and starting to think about their 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 (see below). The major topic areas of the checklist are: documentation (M4), security (M2), product management (M0/M1), release management (M0/M1), testing & integration (RC0-RC2) and development (M4). This checklist can be found at this wiki link: Deliverables for Planning Milestone Checklist Template
      • #3 PROJECT DELIVERABLES - The Use Case teams are defining their project deliverables which include the functional architecture, scope, and 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. At this point, the Modeling sub-committee is using their release planning page to determine what to work on in a release. For an example see this wiki:  ONAP R7 Modeling High Level Requirements
      • #5 EARLY DATA MODEL GROUNDWORK - 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 - Component-to-component information that is passed, APIs, NBI and external interfaces helps to identify models.
      • #6 TEST CASES & AUTOMATION - To reach M1, a set of high-level test cases should be identified. Some consideration to testing automation for your use case can also get underway. These are important to eventually define in more detail, and link off of in the Use Case wiki for each team. Historically, each use cases has had dedicated testing & integration pages created from either ONAP's integration team or each Use Case team's integration group.
      • #7 REQ-1 - Create your requirements JIRA. Which will be used to track your requirement/use case work in the TSC. Make a Clone ++ of REQ-1. You can listen to the recording of how to do that at: Use Case Realization Call: May 6, 2020

    • WIKI LINKS References for the Use Case Teams at M1

      WIKI LINKS REFERENCE AT M1
      M1DescriptionWiki Link
      #1Release Planning TemplateRelease Planning Template
      #2M1 Milestone ChecklistDeliverables for Planning Milestone Checklist Template
      #4Modeling High Level Requirements

      ONAP R7 Modeling High Level Requirements

      #5REQ-1

      Jira
      serverONAP JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyREQ-1


    • Project & Release planning tables
    • 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 modeling team. The release platform Information model updates begin. An example template for R7 (Frankfurt) can be seen at this Wiki: ONAP R7 Modeling High Level Requirements
      • #1: Modeling TEAM SYNC - The Use Case teams need to engage the Modeling Sub-committee to make the team aware of potential model impacts arising from their use cases. The modeling team should also become aware of those at a high-level what impacts a use case might have to the release information model. The use cases also need to get into the ONAP Modeling High-level requirements planning page.
    • Architecture - Every release, the architecture sub-committee refines four things: (1) the release functional architecture, (2) impacts arising from component architectures, (3) architecture impacts from requirements & use cases, and (4) architecture enhancement (e.g. new flow updates):
      • #1: FUNCTIONAL ARCHITECTURE IMPACTS - Each release the functional architecture is updated. A link to the functional architecture can be found here: Architecture. The Use Case teams should become aware of proposed functional architecture updates. The Use case teams can reserve some time on the Architecture sub-committee team meeting to align the use cases with the functional architecture and learn about new updates. The Architecture lead (PTL) can also flag impacts of the functional architecture to individual use cases and vice versa.
      • #2: PLATFORM ARCHITECTURE IMPACTS - Each platform component (e.g. A&AI, SO, SDN-C etc) may have architecture changes for the current release. At M1, those should be in the proposal & planning phases within the architecture sub-committee. Use Case teams should become aware of new impacts to the Platform components arising from news use cases & requirements. The idea is that the use case leads would queue some time in a architecture S/C call (or hold a 1-off meeting) to discuss the use cases that may impact platform components for that release.
    • 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 use case teams need to engage the Platform component teams and the PTLs if they have impact to that Platform components. Requests for changes to components need to be tracked & get commitment from the PTLs. Ideally, engagement of the PTLs (component lead) should be initiated from the Use Case teams. The Use case team members can attend the component weekly calls to raise awareness. The component teams need to Identify and track Use case impacts in the release planning page. 
      • #2 RELEASE TRACKING PAGE - The release tracking page also tracks Use Case impacts for each of the platform components. For example in R6 you see this wiki: Release Planning


  • M2 REQUIREMENTS & FUNCTIONALITY FREEZE

    • USE CASE TEAM ENGAGEMENT -
      • FUNCTIONALITY IDENTIFIED - The Use Case/requirements functionality has been specified, agreed to and frozen. No new visible functionality is to be added to the use case after M2.
      • FUNCTIONAL TEST CASES - Each Project team at M2 has defined and documented their Functional Test Cases. The integration teams have been engaged, and each individual project will likely have its own dedicated integration team wiki page.
      • DESCOPING IDENTIFIED - At this point, if functionality cannot be delivered, the Requirements JIRA (your clone of REQ-1) should be updated, and descoped items should be identified and reported to the project management team/TSC.
      • API DOCUMENTATION - The Use Case Teams have identified the basic changes for their API that they will be introducing and have 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. API freeze is in M3.
      • VNF REQUIREMENTS - Base set of impacts to VNF Requirements identified by use case/ project. The VNF requirements project documents requirements for both PNF and VNFs. Requirements updates should be coordinated with the VNF-REQTS project.
      • DATA MODEL DEVELOPMENT - Discussion of the Data model by Use Case/requirements team with input from the Modeling sub-committee. 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.
      • 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

  • 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.

CONTRIBUTIONS & THE RELEASE INFORMATION MODEL

Image Removed

  • Architecture Engagement -
    • 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.
  • Use Case Team Engagement -
    • INFORMATION & DATA MODEL DEVELOPMENT - Discussion Info Model & Data model development with input from the Model S/C. 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 the Use Case Teams.
    • 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
      • Active discussion and interaction between Use Case Team and the Modeling S/C
      uses Jira tickets to
      • to make sure that the information model and the data model development are in lock-step.
      • 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
      .
    • SYNC UP & SOCIALIZATION - Either the Use Case weekly meeting, or the Use Case Realization weekly call would be a good meeting to communicate and socialize the clean release information model. Announcing the results of the poll to move to clean release information model. An email should be sent to the ONAP group lists with links of where to find the clean release information model. Announcements by email and presentation by the Modeling S/C leads to the Use case committee, and TSC (and architecture see above) can be made at this time. If there is some debate, there might be times where we need to reconcile a difference of ideas; and the development of models, the U/C committee meeting, the U/C realization call, and/or the 5G U/C call are all forums where many of the U/C projects team attend. And those are meetings where people discuss and work through the development of a data and information model.
  • 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.

M2 CHECKPOINTS & COLLABORATION

Image Removed

      • .
      • VENDOR EQUIPMENT - If there is any vendor equipment that needs to be delivered it will be sent in this time frame.
    • MODELING SUBCOMMITTEE ENGAGEMENT -
    • 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).
      • DELAYED ELEMENTS OF THE RELEASE INFO-MODEL - Any delayed elements (parameters/classes) in a contribution can't make the current release (it stays experimental), what would happen to the overall contribution or release information model (is it allowed to go clean).
      • 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.
      • 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 M2. The Use Case teams developing Data Models can be 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.
    • 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.
      • 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. Discussion state classes, attributes and relationships are tagged IISOMI experimental.
      • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Contribution in Discussion State (verb Approving/Poll) END: Contribution in Discussion state
        • (a) FINAL PRESENTATION - The contribution undergo the approval process, and brought one to 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.

Image Added

  • Architecture Engagement -
    • M2 ARCHITECTURE WORK - Before M2, the architecture team is working to refine their four basic things: (1) Functional Architecture, (2) Use case impacts (3) component architecture, (4) Architecture enhancements. At M2, the project teams working requirements and use cases should be aware of the reviews for the major architecture initiatives and be involved in reviews.
    • SYNC UP - The architecture sub-committee should have a sync up with the project teams to have a check-point to share updates to the project impacts.
  • Components (PTL) Engagement - ONAP Platform Teams (A&AI, SO, SDC etc) revflease.
    • FEEDBACK - The platform PTLs should be updated and be involved with project teams requirements freezing and discuss if there are de-scoping that may be necessary. API impacts from projects should also be communicated to the project PTLs.
    • SOCIALIZATION - The socialization of project scope changes, and API updates should be made. Attendance at Project PTL meetings will help keep the project teams in sync with the project.


  • M3 API FREEZE

    • USE CASE / REQUIREMENTS PROJECT TEAMS -
      • API FREEZE - M3 is characterized by the API freeze. The main thing that happens at M3, is that the API is frozen by the Use Case / Requirements Teams.
      • DATA MODEL FREEZE - Developers are working to review & finalize the data model in order to develop the API.
        • Info Model - The Modeling S/C is develops the info-model; the Use Case Teams should present at the Modeling S/C their proposed data model that might be frozen so that the modeling S/C can provide assistance and assess if info-model impacts.
        • DATA MODEL IMPACTING INFO MODEL - If changes in the Data Model impact the information model, those changes need to be worked by the model S/C. The Modeling S/C would evaluate the change to the Information model and possibly make updates.
        • EVALUATE DATA MODEL - START: Input Data Model > verb Consider > END: Data Model in Discussion State
          • The data model is a model that is used in a Use Case and is based on the Information Model. It is generally a self-contained model which depicts a particular capability or function of the system. The data model starts as a "input data model" and undergoes consideration by the Use Case teams. Consideration means that the Use Case teams is entertains & assesses if the input data model. If the Use Case teams think that the contribution is not ready for the current release that contribution it might postponed. It would be noted in the Release Management Project page as such.
        • REVIEW & REFINE DATA MODEL - START: Data Model in Discussion State > verb Reviewing & Refine > END: Data Model in Discussion state
          • The data model undergoes reviewing & refining during the discussion state. Reviewing & refining means that the Use Case Teams are discussing the data model and updating their data model based on feedback and comments from the Use Case team and modeling team. Each data model can be reviewed and refined independently and concurrently with other use case projects. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
        • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Data Model in Discussion State > verb Approving/Poll > END: Data Model in Discussion state
          • (a) FINAL DATA MODEL - When the data model has gotten to a point where the use case team feels that it can start to undergo the approval process, the data model is brought one final time the use case project team.
          • (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a use case lead 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 use case lead. A poll is created whereby use case team members can give the contribution a vote of "yes" or "no". 
        • APPROVING CONTRIBUTION - START: Data model is in Discussion State Post-Poll > verb Approving > Data model in Clean State
          • After the poll has concluded, the data model has finished the approval process. The data model is now considered to be in the clean state. The items that are in the IISOMI experimental state get promoted to a preliminary state.
      • RECONCILE DATA & INFO MODEL - Reconciling the info-model with the data-model. If there are impacts to the information model, it should be captured.
      • SWAGGER - Publish Swagger, Edge Rules.

      • MAINTENANCE RELEASE -

      • INSIGHTS STATISTICS PAGE - https://lfanalytics.io/projects/lfn%2Fonap/dashboard


      • TASKTASK TOPICDESCRIPTION
        1Update API documentation
        2

        Verify that merge requests are code reviewed


        3

        Update the OOM Port list


        4

        Data models are shared with the Modeling subcommittee


        5

        Complete the Architecture Sub-committee Review

        		Go to the Architecture subcommittee and present at the meeting and hold a component review.
        6Integration Blocker
        7Review License Scan Issues
        8Update documented Risks.Update the Project Status Page. Release milestone exceptions. Submit and exception Request.
        9Resolve all high priority bugs in JiraAny high priority bug left by M3 should be resolved if possible. Release notes will be updated with open issues if not completed.


      • Example of A&AI tasks at M3:
      • Image Added
    • MODELING S/C ENGAGEMENT at M3-
      • MODELING S/C ENGAGEMENT - The Use Case teams may wish to solicit the opinion of the modeling S/C and present their data model for discussion and socialization.
      • REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean (base-lined) at M3. Though, updates can still happen to the release information model and the contributions. Certain elements within the model(s) could go to back to an experimental state. Only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. New additions could be added to a contribution model. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature.  
    • ARCHITECTURE ENGAGEMENT -
      • API FREEZE & ARCHITECTURE - API updates can impact that Component Architecture. That is architecture related to the ONAP components (A&AI, SO, SDC etc). Impacts to the API also affect the architecture landing page portal, and the architecture component descriptions. This is where the architecture team captures links to the API descriptions and documentation. Impacts to the API should have been identified during the architecture sub-committee review at M0.
    • COMPONENT  (PTL) ENGAGEMENT -
      • API FREEZE & COMPONENT IMPACT - The API freeze most directly affects the ONAP components (A&AI, SO, SDC etc). As the project teams working use cases & requirements will directly impact the software used by micro-services or platform components. Software changes are tracked in Jira, and should be coordinated with the PTL platform component technical leads.


  • M4 CODE FREEZE

    • USE CASE / REQUIREMENTS PROJECT TEAMS -

    • CODE FREEZE - The Use Case Teams are delivering the Software for the release. Requirements and use case teams are working to complete their software defined in their jiras and wiki pages. These will include the following tasks listed here.

    • COMPONENT S/W DELIVERY - S/W drops should be coordinated with PTL (components). Sync up with each component and PTLs should be done. Each component that is impact should have already been tracked in M0 and M1. Each of the component S/W impacts should be tracked by Jira tickets. Historically, it is the case that sometimes certain functionality of a component may not be able to be delivered. In this case, an assessment should be made if this will impact other platform components or other aspects of the use case.
    • JIRA TICKETS - Jira tickets should be updated with S/W delivery status. Delayed or Jira tickets that cannot be completed need to be communicated to the ONAP project release manager. Jira tickets that are tracking the overall project, the REQ-tickets need to be updated if there have been changes in content or status.
    • DEFERRED - Deferred elements that could not be delivered in the release should be noted. These can now be scheduled for the next release as generally by M4, the next ONAP release content is already starting to be considered and early planning is occurring.
    • INTEGRATION WORK - Integration work and test-cases should be worked. The integration teams need to be aware of any delays in software component delivery. If there are things can cannot make it into the current release test cases need to be updated.
    • API UPDATES - Swagger updates and API updates should be made if necessary. The API delivery was in M3 however, some things may change going into or during M4 which may cause API updates.

    • JIRA S/W BUGS COMMUNICATED - Tracking new software bugs with Jira tickets as necessary. As new software issues are encountered, they need to be communicated to the release.

    • RELEASE MANAGEMENT REPORTING - During M4, status of the projects are tracked for evaluation and software delivery. Potential delays needs to be communicated to ONAP project management. The TSC will consider and assess the status or each requirement/use case and the health of the release based on the Jira tickets. Any deferrals should be noted with the project management.
    • TSC REPORTING - The TSC is tracking delivery and health of the release at M4
    • MARKETING RELEASE - The marketing report of overall ONAP is being drafted at this point.

    • DOCUMENT GENERATION - Read the docs updates should be made for the Use Case. The read the docs can be found here: https://onap.readthedocs.io/en/latest/index.html

    • The following shows some of the key tasks to be completed at M4 by a PTL.

      TASKTASKitem

      		review License Scan Issues

      Refer to most recent license scan, to determine is license scan are issues and resolve license scan issues.

      If your project issues open source software, it may have licensing issues. For example if open source or proprietary software


      		Merge Requests

      		Address all security Issues

      Security Violation page. Some are common vulnerabilities across all of ONAP.

      Depending on libraries used.


      		FOSS Wiki -

      Maven command to show dependency tree and uploaded. 

      Project FOSS


      		High Priority Jira IssuesHigh Priority Jira Issues and document any remaining open issues.

      		Release Platform Maturity & CII

      Platform Maturity Requirements (S3P).

      Performance stability resilience security Scalability manageability scalablity

      Project Maturity Review for AAI

      CII Badging Scorecard.

      The Analytics (what used to be Bitergia) is used to show the different commits, different project committing, and showing that it is an active projects and the span of committers across different companies. To find outliers, and project not being supported to evaluate for maturity review.

      https://lfanalytics.io/projects/lfn%2Fonap/dashboard


      		Test Coverage

      Verify test coverage goals have been met

      This is done in Sonar Cloud. Sonar cloud shows lines of code that are test are not covered.

      J-Unit tests are cross-indexed against the software and statistics are compiled for each component in Sonar Cloud.

      Overall Line coverage. meaning that the tests cover >50% of the code.

      An example: Image Added components: Image Added

      https://sonarcloud.io/organizations/onap/projects

      Quality profiles are generated. Bugs, Vulnerabilities; Code Smells, Security hotspots; and Active rules are applied

      and identify code duplication. Suggested Bug fixes.


      		Undocumented Risk

      		Integration Weatherboard

      Integration Weatherboard

      0: Integration Weather Board for Frankfurt Release


      		Update the INFO Yaml

      Review and uupdate the INFO. yaml

      Info about project, life cycle state. Comiters.

      Project meta-data. Stating committers, PTLs etc.

      through Oracle VM VirtualBox

      Keep track of project changers.

      Image Added , Image Added , Image Added , Image Added , Image Added,

      Each Micro-service of the project has a INFO.yaml Image Added

      Apply for project status: Image Added


    • Examples of steps performed at this milestone:Image Added

    • MODELING S/C ENGAGEMENT at M4 -

      • PLATFORM INFORMATION UPDATES FROM SWAGGER UPDATES - Any API changes from Use Cases should also be communicated to the modeling team.
      • DOCUMENT GENERATION- 

    M3

    M3 MODELING SUBCOMMITTEE ACTIVITIES-
  • REFINEMENTS TO THE RELEASE INFO MODEL - The Release Information Model is clean at M3. It is considered "base-lined" and "final", hence it is marked clean. Though, updates can still happen to the release information model and the model contributions therein. This means that certain elements within the model(s) could go to back to an experimental state. Note that only certain elements (e.g. attributes, ranges) are likely to go to the experimental state NOT the entire contribution. More often though, new additions could be added to a contribution model. In general, there would likely be just minor tweaks on the model. So when a contribution is clean it has to be at least preliminary. A contribution cannot be clean and experimental. Clean has a relationship to the IISOMI states. For an entity to be clean it must be either preliminary or mature (see the IISOMI state diagram link).
    • IISOMI STATES - A link to the IISOMI state diagram can be found here: Stereotypes 
    • NEW ADDITIONS - A contribution model could be clean, but things added afterwards and those elements would come in as experimental. 
  • STILL IN PROGRESS ITEMS IN RELEASE INFO MODEL - It is possible that as the modeling team enters the M3 milestone that there are still some things in progress, that are expected to be in the current release. They might still be marked experimental even though the release information model is clean. Thus, to open item are continue to be work; and it is expected it would not affect software if code were already associated to it.
    • ITEMS IN DISCUSSION - e.g. when root contribution was done, with root party is an example as it was not agreed to, we made the decision to leave that experimental until a future date. There were aspects agreed, and other things left experimental to pursue in the future. The main contribution was split. These parts everyone agreed with and these part left experimental which would be taken up in a future contribution and re-discussed. This would likely occur at M2, and they might be discussed at M3. There was a conscious decision and agreement by the modeling team that the parts of the model still open would be pushed to the next release. So only theoretical discussion would happen at this point of how to proceed in the future release.
    • FUTURE WORK - Things originally planned to be in a release could potentially transform into future work items. Some modeling work could be pushed to the next release if need be, if it is decided that it could not be completed in the current release.
    • FUTURE WORK- Future work is typically identified as such at the start of a release at M0 in the release modeling planning page. Future Work can still proceed. For example, in R6 the geo-location modeling work is not tied to any active development yet. The location work is a good example of work that was worked in ADVANCE of when it is expected to be used (Future Work). It is also possible that some of the future work is building upon a foundation of work that had already been started (or was looked at) or implemented in a prior release.
    • DEFER WORK - It might be decided the the future work could be deferred to the next release. On the current modeling high level requirements page to indicate that a particular future work has been deferred to a future release. In order not to lose the activity, it would be expected that it would be rolled into the next release's Modeling High-Level Requirements.
    • CONTINUE WORK - Future Model work may continue to proceed in the current release..
    DOCUMENTATION AFTER IMPLEMENTATION IN PRIOR RELEASE WORK- This type of work is the model is catching up to already implemented software. It has already been identified as something that would be worked on for that release at M0. It is expected that it wouldn't immediately impact the current software. However, it may be extended eventually to incorporate new work. The way to proceed with this category of work is handled the same way as the future work (i.e. Defer or to Continue the work) given modeling improvement recommendations on how better to model a given concept.
  • M3 CHECKLIST - The M3 check list modeling updates discussion is used by the modeling sub-committee. It is used as a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. See also the Use Case Team Engagement (section below). The Check list can be found here: Proposed M3 Checklist modeling updates discussion
  • Architecture Engagement -
    • S-P - B-
  • Use Case Engagement -
    • API Freeze - M3 is characterized by the API freeze. The main thing that happens at M3, the API is frozen by the Use Case Teams.
    • Data Model Freeze - Developers identify a problem in the data model which affects the information model.
      • SYNC UP - since the Modeling S/C is familiar with the info-model; the Use Case Teams should present at the Modeling S/C their proposed data model that might be frozen so that the modeling S/C can assess it to see if might have impact to the Info-model. There should be some collaboration or check-point at M3 to discuss and potential ripple affects back to the information model.
      • DATA MODEL IMPACTING INFO MODEL - If changes in the Data Model impact the information model, those changes need to be worked by the model S/C. The Modeling S/C would evaluate the change to the Information model and possibly make updates.
      • USE CASE TEAMS INDICATE CHANGE - The Use Case teams may have enough knowledge of the info-model that they identify a data model change that may impact the information model. This presumes that the use case teams know that their changes in a data model may have impact to the information model.B
      • CONSIDER DATA MODEL - START: Input Data Model > verb Consider > END: Data Model in Discussion State
        • The data model is a model that is used in a Use Case and is based on the Information Model. It is generally a self-contained model which depicts a particular capability or function of the system. The data model starts as a "input data model" and undergoes consideration by the Use Case teams. Consideration means that the Use Case teams is entertains & assesses if the input data model. If the Use Case teams think that the contribution is not ready for the current release that contribution it might postponed. It would be noted in the Release Management Project page as such.
      • REVIEW & REFINE CONTRIBUTION - START: Data Model in Discussion State > verb Reviewing & Refine > END: Data Model in Discussion state
        • The data model undergoes reviewing & refining during the discussion state. Reviewing & refining means that the Use Case Teams are discussing the data model and updating their data model based on feedback and comments from the Use Case team and modeling team. Each data model can be reviewed and refined independently and concurrently with other use case projects. Things in the discussion state are classes, attributes and relationships are tagged as IISOMI experimental.
      • MODELING S/C ENGAGEMENT - The Use Case teams may wish to solicit the opinion of the modeling S/C and present their data model for discussion and socialization.
      • FINAL CALL FOR COMMENTS & INITIATE POLLING - START: Data Model in Discussion State > verb Approving/Poll > END: Data Model in Discussion state
        • (a) FINAL PRESENTATION - When the data model has gotten to a point where the use case team feels that it can start to undergo the approval process, the data model is brought one final time the use case team.
        • (b) FINAL CALL FOR COMMENTS - After that, a final call for comments is issued by a use case 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 use case lead. A poll is created whereby use case team members can give the contribution a vote of "yes" or "no". 
      • APPROVING CONTRIBUTION - START: Data model is in Discussion State Post-Poll > verb Approving > Data model in Clean State
        • After the poll has concluded, the data model has finished the approval process. The data model 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.  #@# do data models also use ISOMII states?
    • Component Data Model Final - x.
    • RECONCILE - Reconciling the info-model with the data-model. M3 checklist. (API Freeze)
    • M3 CHECKLIST - The M3 check list is used. This is a vehicle to engage the Use Case (project teams) and reconcile the Use Case Teams with the modeling S/C team's work. The Check list can be found here: Proposed M3 Checklist modeling updates discussion
  • Components (PTL) Engagement -

    • M4

    • Code Freeze

    • Kickoff Information Model Requirements for Next Release

    • READ THE DOCS - (M3 or M4?)
      • The model editor provides a final gendoc word document which serves as the basis for what will be incorporated into the
      readthedocs. The read the docs can be found here: https://onap.readthedocs.io/en/latest/index.html . The word document is fed into some tools which generates the readthedocs output. The gerrit master model is periodically updated, and a snapshot of the eclipse/papryus model is taken and that is called the release model.
    • DOCUMENT GENERATION - The RST documentation that only contains things in the current release or everything that is approved.
    • PAPYRUS GENERATION - The Papyrus snapshot is generated. The RST document is created. The readthedocs documentation is generated.
    • Note that the papyrus model includes what was/had accepted into the previous release and also anything that is still a work in progress.
    • Architecture Engagement -
      • S-P - B-
    • Use Case Engagement -
      • D-T - D-p.
    • Components (PTL) Engagement -

  • RCx

    • Runtime Compliance

  • Observations

    • Establishes and Evolves a Common Model

    • Project (Component) Team Involvement in Modeling Solution

    • Governance of Common Model and Corresponding Component Models

    • Update possible in M3 and M4 (bug fixes) per exception process

Artifacts

  • Information Model Artifact Contains

    • Classes

    • Relationships with Multiplicity

    • Important Attributes with Multiplicity 

    • Definitions

    • Data Types 

    • Feed to Data Dictionary

    • Tooling - Papyrus with GitHub

  • Component Data Model Artifacts (Implementation Specific)

    • Component Data Model

      • Contains objects, attributes, & relationships (more detail than information model)

    • Mapping to Information Model

    • Feed to Data Dictionary?

  • API Artifacts

    • API Model

    • Mapping to Information Model

New Roles – Model Governance

  • Information Model

    • Internal Committers

    • Internal Approvers

    • Impacted Project (Component) Approvers

    • Impacted API Approvers

    • Architecture Group Approvers

  • Component Data Models

    • Internal Committers

    • Modeling Team Approvers

    • Architecture Approvers

    • Impacted API Approvers

  • API Definitions

    • Modeling Team Approvers

    • Impacted Project (Component) Approvers

    • Architecture Approvers

Benefits

  • Establishment and Evolution of a Common Model (Model Consistency)

  • Continue Move Toward a Model Driven Design

  • Improve Data Quality

Modeling S/C, Use Case Team and Architecture team touch points, interactions and cooperation:

      • Readthedocs.  Model updates from use case teams can be contributed to that subcommittee.
      • NEXT RELEASE - The Use Case teams can feed input into the next release. The High level modeling requirements page for the next releases are usually being worked near the end of a release. For example, in R7 Guilin release, the R8 Honolulu high level model requirements were open: ONAP R8 Modeling High Level Requirements

    • ARCHITECTURE ENGAGEMENT -

      • Architecture Sync - Any API or Platform component architecture impacts coming from M4 development should be communicated to the architecture sub-committee and updates to the platform component diagrams should be made.

    • COMPONENT (PTL) ENGAGEMENT -

      • Component Deliveries - Platform component deliveries are being made by each of the Use Case Teams. Impacts to components and things might be descoped should be considered. Each of the component teams are working to deliver code by M4.

#@#

  • RC0/RC1/RC2 RUN-TIME COMPLIANCE

    • USE CASE / REQUIREMENTS PROJECT TEAMS -
      • Integration Tasks must be filled out
      • Test & Integration pages should be filled in.
    • MODELING S/C ENGAGEMENT at M4 -
      • f
    • ARCHITECTURE ENGAGEMENT -
      • S-P - B-
    • COMPONENT (PTL) ENGAGEMENT -
      • D-T - D-p.




WAY OF WORKING PROCESSES

This table has links to the other Way of Working (WoW) ONAP Process pages. The WoW for Architecture and Modeling are cross-collaborative, and the processes should align in places so it forms a cohesive whole if you are working on a project that has Use Case, Modeling and Architecture Impact.

TypeWiki
Architecture WoWONAP Architecture Team Process - Old
Modeling WoWProposed ONAP Release Process Updates for Information and Data Modeling

...

SUPPORTING DOCUMENTS

250
DOCFILE
Way of Working (Modeling S/C, Use Case Teams, Architecture)
View file
nameModelingUseCaseArchWoW_BC02July2019v5.pptx
height