Download presentation
Presentation is loading. Please wait.
Published byTabitha Haugh Modified over 10 years ago
1
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #1 [OMA-Template-SlideDeck-20030826] OMA-TP-2003-0407-OMA Working Methods OMA Working Methods 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.http://www.openmobilealliance.org/UseAgreement.html THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS. 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
2
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #2 [OMA-Template-SlideDeck-20030826] Contents of the Presentation Group Types Liaison Decision making process Types of documents and document numbering Process Work activities : process flow
3
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #3 [OMA-Template-SlideDeck-20030826] OMA structure
4
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #4 [OMA-Template-SlideDeck-20030826] Group Types
5
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #5 [OMA-Template-SlideDeck-20030826] Groups TP Committees (TP Committees) Work of TP committees is not covered by Work Items May produce normative and informative documents Does not produce specifications Documents to be approved by TP Birds of a Feather (BoF) BoF serves as a forum to review issues not covered by WIs BoF created by TP before they may meet Request for BoF to address purpose and issue to review BoFs are not chartered BoFs do not produce normative documents May produce an informative report and/or draft WI for TP consideration BoF duration is limited in time (typically 6 months)
6
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #6 [OMA-Template-SlideDeck-20030826] Groups Working Groups (WG) Working Groups Report to the TP and are chartered to produce work based on WIs Working groups produce normative and informative docs WG permanent documents are approved by TP WGs may create Sub-Working Groups Sub-Working Groups (SWG) SWG are chartered by its parent WG SWG charter is within scope of parent WG All decisions are agreed by the parent WG SWG can not be formally subdivided (ie. no SubSubWG) SWGs may support liaison activities
7
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #7 [OMA-Template-SlideDeck-20030826] Liaison Liaison is used to communicate with external organisations Until a relationship is established – an interim liaison process exists Once Established Liaisons May Be Exchanged Scope Limited to Agreement Info Outside of Scope Require TP/Board Approval Liaison Contacts Help Manage Flow Work Groups Empowered to Engage Work Groups Inform TP of Requirements for Liaison Once agreed – working groups can directly work with the external organisation
8
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #8 [OMA-Template-SlideDeck-20030826] Technical Decision Making Consensus driven approach Groups Should Seek Consensus on Decisions Votes Possible When Consensus is Not Achievable – should remain the exception Consensus in Physical or Real-Time Meetings Can Determine Status in meeting Should Not Use Sparse Attendance to Drive Issues Through Consensus in Non-Real-Time Meetings Should Permit Delegates Have at Least 7 Days to Respond Chair Should Consider Outside Factors in Setting Timeline Holidays, Scheduled Meetings, System Outages Voting – If needed Voting may be secret or open as decided by the group 67% threshold to approve
9
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #9 [OMA-Template-SlideDeck-20030826] Document Numbering Permanent Documents Specifications and Reports Internal Documents Documents Submitted to a Particular Meeting
10
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #10 [OMA-Template-SlideDeck-20030826] Permanent Document Numbering FieldUse, Format and RemarksExamples This field MAY be provided to indicate the affiliate organisation that produced the spec. The future usage of affiliate names requires further consideration, and it is desirable that any new work initiated in OMA does not have the affiliate name in the document name. SYNCML, LIF, WV, WAP etc. This field SHALL be provided. The field provides an abbreviated name of the document function in the working group. It shall be a unique identification of the functional area, distinguishing between different working groups that may be working on the same functional area. DLOTA-REQ, DLOTA-ARCH, WML, etc. This field SHALL be provided. This field shall refer to a version of the document. V1_0, V2_1. This field SHALL be provided and is the date when the document was posted to the document archive. 20020620 This field SHALL be provided and indicates the state of the specification, these states being: ‘A’ for Approved ‘C’ for Candidate ‘D’ for Draft ‘E’ for Expired ‘O’ for Obsolete ‘R’ for Restricted Draft (OMA Internal) Existing other states from OMA affiliates not accommodated or mappable into this list should be preserved and not reused if there is any risk of confusion. D, A etc. “OMA-“ { “-”} “-” “-” “-” OMA-WV_Arch-V1_1-20021001-A
11
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #11 [OMA-Template-SlideDeck-20030826] Permanent Document Version FieldUseRemarks Major Version Indicator This field shall identify the major version of the document, as determined by the working group. This field SHALL be provided. Major versions are likely to contain major feature additions; may contain incompatibilities with previous document or specification revisions; and though unlikely, could change, drop, or replace standard or existing interfaces. Initial releases are “1_0”. Minor Version Indicator Minor version of the document. This field shall be provided. It is incremented every time a minor change is made to the document by the working group. Minor versions are likely to contain minor feature additions, be compatible with published the preceding Major_Minor specification revision including existing interfaces, although it may provide evolving interfaces. The initial minor release for any major release is “0”, i.e. 1_0 Service IndicatorService indicator for the document. Incremented every time a change is made to the published document by the working group. This field is optional, i.e. the equivalent of “_0” for initial Major_Minor releases but SHALL be provided whenever a service release of the document is made. The first service indicator release SHALL be “_1” for any Major_Minor release. Service indicators are intended to be compatible with the Major_Minor release they relate to but add bug fixes. No new functions will be added through the release of Service Indicators. = “V” “_” { “_” }
12
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #12 [OMA-Template-SlideDeck-20030826] Work Activities : Process Flow WORK ITEM CREATION Step1 ASSIGNMENT BY TP TO WG Step2 REQUIREMENTS Step3 DETAILED TECHNICAL WORK Step4 VALIDATION & IOP Step5 Work with other Fora Eg. 3GPP (MMS) Approved Specs
13
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #13 [OMA-Template-SlideDeck-20030826] Work Activities : Process Flow (1 of 3) Work Item Development Stage 1: WI Creation Stage 2: WI Refinement (Following Failure to Approve) Stage 3: Submission of a WI to the TP Stage 4: Technical Plenary Approval of WIs Charters Reflecting the WI Scope Stage 4.1: Assignment of WI in the Scope of WG Stage 4.2: Assignment of WI not in the Scope of WG Stage 4.3: Assignment to a New WG Stage 5: Review of Revised / New Charters for Assigned WIs Stage 6: Approval of Revised / New Charters for Assigned WIs
14
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #14 [OMA-Template-SlideDeck-20030826] Work Activities : Process Flow (2 of 3) High Level Requirements Document (RD) Stage 7: Producing the Requirements Document Stage 8: Requirements Document Review Stage 9: R&A of the RD by the Technical Plenary Detailed Specification Creation Stage 10: Creation of the Architecture Document Stage 10.1: Architecture Document Review Stage 11: Creation of the Enabler Package Stage 11.1: Consistency Review Stage 12: Candidate Submission for Review and Approval Stage 13: Approval of the Candidate Specification
15
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #15 [OMA-Template-SlideDeck-20030826] Work Activities : Process Flow (3 of 3) Candidate Validation and Approval Stage 14: Public Review Stage 15: Validation Task Transfer to IOP Stage 16: Enabler Test Plan and Enabler Test Specification Document Creation Stage 17: Interoperability Testing, Problem Report Generation and Handling Stage 18: Submission of Final Candidate Spec(s) for Approval Stage 19: Approving the Candidate as an Approved Spec Stage 20: Post Technical Plenary Approval Process
16
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #16 [OMA-Template-SlideDeck-20030826] Process reviews Required reviews Requirements Document Architecture Document Enabler Packages : collection of specifications suite defining an enabler Handling Reviews Preliminary Reviews Scheduling of Formal Reviews Availability of Material Handling of Comments Update of Material and Review Response Follow-up Reviews Submission to Technical Plenary
17
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #17 [OMA-Template-SlideDeck-20030826] Access to OMA specifications Specifications can be retrieve from the public web site www.openmobilealliance.org Traditionally this has been approved and candidate specification New policy of openness will expose draft specification, … Technical reflector for comments from anyone outside OMA
18
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #18 [OMA-Template-SlideDeck-20030826] Summary TP is fully responsible for the technical work in OMA Decisions are consensus driven A well defined process exists to create technical specifications Non blocking process WI driven & market driven requirements
19
© 2003 Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0407Slide #19 [OMA-Template-SlideDeck-20030826] Thank you!
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.