150 likes | 288 Views
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.
E N D
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.
Contents of the presentation • Overview of process • Release & tracking process • Handling of work orginating from affilliate organisations • OMA Approved WIs and Work Programme
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
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
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
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
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
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
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
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
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
Work Item Approved • OMA maintains a list of approved WIs To be updated before the Workshop
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