1 / 15

OMA-TP-2003-0408- OMA Work Plan & Dependencies OMA Work Plan & Dependencies

OMA-TP-2003-0408- OMA Work Plan & Dependencies OMA Work Plan & Dependencies. Submitted To: Technical Plenary Date: 21 st August 2003 Availability: Public OMA Confidential Contact: Philippe Lucas ph.lucas@orangefrance.com Source: Technical Plenary vice-chair. X.

abner
Télécharger la présentation

OMA-TP-2003-0408- OMA Work Plan & Dependencies OMA Work Plan & Dependencies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OMA-TP-2003-0408-OMA Work Plan & DependenciesOMA Work Plan & Dependencies Submitted To: Technical Plenary Date: 21st August 2003 Availability: Public OMA Confidential Contact: Philippe Lucas ph.lucas@orangefrance.com Source: Technical Plenary vice-chair X USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT. THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.

  2. Contents of the presentation • Overview of process • Release & tracking process • Handling of work orginating from affilliate organisations • OMA Approved WIs and Work Programme

  3. OMA has three processes • The OMA organisation and process document • Deals with general procedural matters for the Technical Plenary and in particular handling of Work Items and the subsequent specification/enabler development life cycle • The OMA IOP process document • Deals with interoperability processes, policies and principles • The OMA Work Programme and Release Handling process document • Deals with procedures for the OMA work programme and the release of enablers

  4. OMA Work Programme and Release Handling process • The process deals with the following topics: • What kind of information the WP tracks • When the information need to be made available to the WP • How the information needed as input to the WP is to be collected and distributed • How the information collected as part of the WP is intended to be used • How OMA Releases are defined and named • How OMA Releases are planned and managed • How specifications and releases from incoming affiliates are handled

  5. OMA Release Programme • OMA working process is a market driven, continuous program designed to deliver three key milestones • Ensures products and services work together seamlessly • Requires thorough interoperability testing • 3 Phases • Phase 1: Candidate Enabler Release • Phase 2: Approved Enabler Release • Phase 3: Interoperability Release

  6. OMA Release Programme • OMA uses a Work Item List to scope an activity in OMA, including: • a list of deliverables, • a time schedule for the work to be undertaken • any dependencies that the WI may have towards other ongoing work within or outside of OMA • An Enabler Release is a collection of specifications that when combined form an enabler for a service area, e.g a download enabler, browsing enabler, etc. • An Interoperability Release is a number of Enablers that have gone through the OMA Interoperability process and have proven interoperability

  7. Tracking of work in progress • All working groups that have ownership of Work Items are required to maintain time schedules for the work that is related to the Work Item • Information of time schedules for the work is collected on a regular basis by the Release Planning and Management Committee • The result is compiled and made available to the Technical Plenary and its working groups

  8. Release process (1/4) Phase1 CandidateSpecification Review andapproval bythe TP CandidateSpecification CandidateEnablerRelease EnablerReleaseDefinition Supportingdocuments DraftSpecification + + • The WG responsible for a WI identifies specifications to be included in an enabler and kicks off drafting the Enabler Release Definition (ERELD) • When the specifications, ERELD and Enabler Test Requirements have been drafted and considered to be complete, they undergo a consistency review • After the complete enabler package with the Requirements Document and Architecture Document, plus supporting information is submitted to the TP for review and approval • The TP approval of the release results in a Candidate Enabler Release where all specifications belonging to it also get Candidate status

  9. Release process (2/4) Phase2 (1/2) IUT IOT Test Fest IUT CandidateEnablerRelease IOTEnablerTestcases IUT EnablerTest Report + + • The Candidate Enabler Release plus the IOT enabler test cases and IUT (Implementations Under Test) are used as input to OMA Test Fests for interoperability testing • The Test Fests are likely to result in a number of Problem Reports (PRs) and Change Requests (CRs) that lead to updates of the specifications and test cases • A successful Test Fest proves interoperability on enabler level and is documented in a Enabler Test Report

  10. Release process (3/4) Phase2 (2/2) Incorporate CRs ApprovedCRs CandidateEnablerRelease UpdatedCandidateEnablerRelease ApprovedCRs ApprovedCRs based on PRs + Review andapproval bythe TP UpdatedCandidateEnablerRelease EnablerTest Report ApprovedEnablerRelease + • The documents in the Candidate Enabler Release are updated with the approved CRs to get a clean release • The updated Candidate Enabler Release plus the final Enabler Test Report are brought to the Technical Plenary for approval • The Technical Plenary approves the release becoming an Approved Enabler Release where all specifications belonging to it

  11. Release process (4/4) Phase3 Review andapproval bythe TP ApprovedEnablerRelease ApprovedEnablerRelease ApprovedEnablerRelease Interopreleasedefinition ApprovedInter-operabilityRelease + • Progress of the work items that are intended to be included in an Interoperability Release is tracked • Based on this input, the TP combines Approved Enabler Releases with an Interoperability Release definition and this combined forms an Interoperability Release • The Approved Interoperability Release is made publicly available by OMA after TP approval

  12. Work Item Approved • OMA maintains a list of approved WIs To be updated before the Workshop

  13. Work programme summary (1)

  14. Work programme summary (2)

  15. Summary • Release planning process is well defined • OMA maintains a work programme in which WI and enabler specifications are well referenced and tracked • OMA work can be shared with partner organisations, in particular 3GPP

More Related