1 / 92

ETSI Work Programme Management (WPM)

WPM is an application program used by ETSI to track all technical work conducted by ETSI technical bodies, including partnership projects such as 3GPP. This presentation provides an overview of the WPM application and its features.

fatkins
Download Presentation

ETSI Work Programme Management (WPM)

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. Work Programme Management WPM What’s behind the icon?

  2. WPM is an application programme running on the ETSI corporate network. It provides access to the ETSI central database used for tracking all technical work conducted by ETSI technical bodies – including partnership projects such as 3GPP. A simplified, read-only, version of WPM is available via the web for external browsing: http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp This presentation deals with the ETSI-internal application and is intended primarily for the benefit of MCC personnel.

  3. WPM uses ETSI nomenclature which differs in some respects from 3GPP nomenclature, and this can lead to confusion … WPM term Work Item project : : : 3GPP term specification / spec work item You have been warned!

  4. On opening WPM, you are confronted with the “Work Item Select”window.

  5. There are three tabs with a variety of fields you can use to select the Work Item records of interest.

  6. Tab 1: fields related to the identity and ownership of the items • Reference id • Deliverable type / number • Responsible committee / working group

  7. Tab 2: sundry fields • Title • STF • Current state (drafting, in Public Enquiry, published, etc.) • EC mandate

  8. Tab 3: relational fields and rapporteur • Keywords (AND combination possible) • Projects (AND combination possible) • Rapporteur (editor) name

  9. In addition, it is possible to distinguish between “active” and “stopped” items. • “Active” includes completed items (published deliverables) – even those which have been withdrawn. It is not restricted only to items which are still being worked on.

  10. For 3GPP work, WPM holds two types of records … The first is the “generic” record. There is one record per spec per Release. The second is the “deliverable-specific” record. There is one record per spec version published by ETSI.

  11. Consider first the GENERIC records … These have the deliverable type “3TS” or “3TR”, depending on whether the underlying 3GPP document is a Technical Specification or a Technical Report.

  12. For example, take 3GTS 22.002. Record for Release 1999 (version 3.y.z) Record for Release 4 (version 4.y.z)

  13. Release 1999 record has Reference ending in “v3”. Release 4 record has Reference ending in “v4”. D = original document R = revision (i.e. subsequent release) TS or TR The spec number Working Group

  14. 1st line of title is always “3rd Generation Partnership Project”. 2nd line of title is always the full name of the responsible TSG. 4th line of title is the technical part of the title of the spec (only). 3rd line of title is the technical part of the title of the spec, followed by the Release identity in parentheses. Scope field should bear a technical description of the work to be performed – or if not available, just a copy of the working title.

  15. When a new version in the same Release of the spec is produced – normally by the approval of a Change Request …

  16. Open the record for update. 2. Choose “user-specified milestone” procedure. 3. Select the last line of the schedule. 4. Insert new milestone.

  17. 4. Enter the milestone name in the form “TSG#n” or, for GERAN, “GERAN#n”where “n” is the meeting number. In the case of the “usual” meeting arrangement whereby TSGs RAN, T and CN meet concurrently, followed by TSG SA the following week, the date entered should be, for all specs regardless of “ownership”, the day after the end of the SA meeting. 5. Enter the new version number of the spec. 6. Enter as target date the day after the last day of the meeting which approved the CR.

  18. 7. Check that the rapporteur’s name is correct.Verify it by comparing it with that shown in the MCC database.

  19. 8. When the spec has been made available in the Specs area of the 3GPP file server (and not until!), enter the date this was achieved.The difference between the target date and the achieved date is used for statistical performance checking.

  20. When a version corresponding to a new Release of a spec is first created, it is necessary to create a new record. (Remember, one record per spec per Release.) 1. Open the existing record for the previous Release.

  21. 2. Duplicate it.

  22. 5. Check that the WG is correct.If it is not, you need to change it in the previous Release(s) record(s) too! 8. Do not copy comments. 6. Schedule setting = “default”. 4. Change the last digit to correspond to the version number for this Release. 7. VERY IMPORTANT!Select option “Revision”. 2. Change D to R if necessary. 3. Document type should be already correct.

  23. 9. Other fields should be OK.Duplicate! 10. And confirm.

  24. 11. Update.

  25. 13. Edit the title to show the correct Release. 12. Enter spec number.(Gets lost during the copying process for some unknown reason.)

  26. 14. Choose project code for new Release …

  27. 15. … and remove code for previous Release.

  28. 16. Select surplus milestones in schedule ... 18. Confirm. 17. … and delete them.

  29. 19. Edit scope to indicate update to next Release.

  30. 21. Save. 20. Add a remark: “Record created”.

  31. The remaining procedures are as for updating an existing record …

  32. 22. Enter the milestone name in the form “TSG#n” or, for GERAN, “GERAN#n”where “n” is the meeting number. 24. Enter as target date the day after the last day of the meeting which approved the CR. 23. Enter the new version number of the spec.

  33. 25. Check that the rapporteur’s name is correct.

  34. 26. When the spec has been made available in the Specs area of the 3GPP file server enter the date this was achieved.

  35. For 3GPP work, WPM holds two types of records … The second is the “deliverable-specific” record. There is one record per spec version published by ETSI.

  36. Consider now the DELIVERABLE-SPECIFIC records … These have the deliverable type “TS” or “TR”, depending on whether the underlying 3GPP document is published as an ETSI Technical Specification or an ETSI Technical Report.

  37. Click “Duplicate” to create a new WI record based on the present one.

  38. You will be offered this panel.

  39. Deliverable class: “R” indicates a revision of an existing item. Only use “D” for a brand new deliverable document (spec).

  40. Deliverable type: will probably be same as previous: TS = Technical SpecificationTR = Technical Report

  41. Serial number: use existing value modified according to these rules:

  42. If moving to a new year’s release, increment the number at the end. This shows the major version number. Here we see 03.46 v7.x.x i.e. release 1998. Change this to 8 for a release 1999 spec i.e. 03.46 v8.x.x . Rule 1 0346Q7 0346Q8

  43. If providing an update to an existing release, add a suffix R1. If there is already a suffix R1, change it to R2. (Or change R2 to R3, etc..) Here we see 03.46 v7.0.0 (say) being changed to 7.1.0 (say). Rule 2 0346Q7 0346Q7R1

  44. Leave the creation date as the current date unless there is some very good reason to change it.

More Related