© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP 2009 3GPP The Training Course / Module 10 1 All you always wanted to know about.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

SEM10-04 Initiation of a Work Item ETSI Seminar © ETSI All rights reserved.
SEM16-05 Maintenance & withdrawal of documents ETSI Seminar © ETSI All rights reserved.
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 12a 1 All you always wanted to know about.
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 4 1 All you always wanted to know about.
Configuration Management
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 14 1 All you always wanted to know about.
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 3 1 All you always wanted to know about.
The MCC Specs database A guided tour. The Specifications panel …
Prescriptive Process models
Configuration Management
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 8 1 All you always wanted to know about.
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 1 1 All you always wanted to know about.
7 Feb 2000JMM1 Editing a GSM spec - tips for experts.
All you always wanted to know about 3GPP … but were too afraid to ask.
MCC 3G and GSM Specification Handling Ian Doig, MCC.
EvalS Application User Guide version September 17, 2011.
MIS 2000 Class 20 System Development Process Updated 2014.
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 7 1 All you always wanted to know about.
How ETSI publishes 3GPP specifications. 15 October 2000JMM2 A 3GPP specification is based on the standard template (available from
Software Configuration Management
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
CS 501: Software Engineering
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 2 1 All you always wanted to know about.
Software Compliance: Are we there yet? Looking back and moving forward.
The change control cycle Or Where little 3GPP specifications come from …
By: Farzad Dadgari Soil and Environmental Specialist SWHISA.
1 CMPT 275 Software Engineering Software life cycle.
INFO 637Lecture #81 Software Engineering Process II Integration and System Testing INFO 637 Glenn Booker.
Chapter 2 The process Process, Methods, and Tools
Information Systems Security Computer System Life Cycle Security.
Software Engineering Modern Approaches
System Analysis and Design
Chapter 8: Systems analysis and design
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Introduction to HTML5. History of HTML HTML first published – Tim Berners-Lee HTML 2.0 HTML 3.2 HTML 4.01 XHTML 1.0 XHTML 2.0.
Configuration Management Matti Kuikka CONFIGURATION MANAGEMENT by Matti Kuikka, Unit Manager, Ericsson, Turku, Telecom R&D, Wireless Charging.
System Analysis (Part 2) The System Development Life Cycle Problem Selection and Feasibility Study.
WPM What’s behind the icon? Work Programme Management.
The life-cycle of a 3GPP Spec Abridged for family viewing.
Event Management & ITIL V3
Definition of a Vehicle Type for IWVTA + Extension of Approvals SGR Transmitted by OICA.
Click to edit Master text stylesClick to edit Master text styles Second levelSecond level Third levelThird level Fourth levelFourth level Fifth levelFifth.
1. To start the process, Warehouse Stationery (WSL) will invite you to use The Warehouse Group Supplier Electronic Portal and will send you the link to.
Software Engineering Chapter 3 CPSC Pascal Brent M. Dingle Texas A&M University.
Recommendations for transfer from TISPAN to 3GPP SP For information Source: Goran Engstrom: TISPAN WG1 chairman Stephen Hayes: 3GPP SA Chairman.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
The change control cycle Or Where little 3GPP specifications come from … Move to next slide.
Quick Recap Monitoring and Controlling. Lesson 11: Monitoring and Controlling Project Work Topic 11A: Identify the Monitor and Control Project Work Process.
DICOM to ISO-DICOM Report to joint ISO TC215/WG2 – DICOM WG10 meeting January 24, 2004, San Diego.
ACT476 CAPSTONE WRITING AN USER MANUAL. Developers VS Users Developers want to write code Have little time to document or write user’s manuals Users on.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Click to edit Master text styles –Second level Third level –Fourth level »Fifth level 1 WPM What’s behind the icon? Work Programme Management.
Welcome to Software Project Management. CONVENTIONAL SOFTWARE MANAGEMENT The BEST and WORST thing about software is its flexibility. 1.Software development.
44222: Information Systems Development
The lifecycle of a GSM spec Or All you ever wanted to know about where little GSM specs come from.
GMAP Grant Management, Application, and Planning Consolidate Application Training.
Software Maintenance1 Software Maintenance.
Software Design and Development Development Methodoligies Computing Science.
CT WG6 status report to TSG CT #75
Consistent version numbering across drafts & deliverable
Configuration Management and Prince2
Software Configuration Management
Life Cycle Models PPT By :Dr. R. Mall.
The lonely road or How a spec gets from WG Secretary to the server, and how it gets published as an ETSI deliverable 1.
3GPP Status.
Start page CM001 Spec Maintenance
Presentation transcript:

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 1 All you always wanted to know about 3GPP … but were too afraid to ask. The 3GPP Seminar

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 2 The 3GPP Seminar Module 10 Drafting and maintaining the Technical Specifications

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 3 Drafting and maintaining the technical specifications The work items result in new technical specifications, or enhancements to existing ones …

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 4 A named individual – the “rapporteur” - is identified for each spec. It is the rapporteur’s responsibility to initiate the drafting of the spec, and to maintain it throughout the drafting process. scribble scribble scribble scribble Spec numbers are allocated by the Support Team. The drafting process (1)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 5 The rapporteur issues the specification as version Release field Technical field Editorial field The Editorial field of the version number is incremented each time an editorial change is made to the document. It is reset to zero every time the Technical field is updated. The Technical field of the version number is incremented each time a technical change is made to the document. It is reset to zero every time the Release field is updated. The Release field of the version number is incremented each time major new functionality is made to the system (rather than to the individual document). The drafting process (2)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 6 The initial draft is discussed in the working group. v0.0.0 v0.1.0 And a new draft is produced, bearing technical changes. The drafting process (3)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 7 v0.1.0v0.2.0v0.3.0 … The process is iterative, until … v0.8.0 … the working group is happy with the draft. v1.0.0 Draft is presented for information to the plenary TSG (Technical Body). The drafting process (3)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 8 v1.0.0v1.1.0v1.2.0 … The document returns to the working group, and drafting continues until … v1.5.0 … the working group believes the draft to be stable enough to come under formal “change control”. v2.0.0 Draft is presented for approval to the plenary TSG (Technical Body). The drafting process (4)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module 10 9 v2.0.0v2.1.0v2.2.0 … If the TSG does not approve the draft, it may return to the working group for further refinement. This is exceptional. v3.0.0v2.3.0 When the draft is approved to come under change control, it is upgraded to version (assuming Release 1999 – see later). The drafting process (5)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module The “system” is composed of a coherent set of related specifications. Change control (1) It is still possible to develop the standard further, to add the missing parts, and to correct errors and omissions as the overall system becomes better defined.

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Consider an individual standard … v3.0.0 If the responsible working group wishes to make a change to it, however small, … … the working group must raise a Change Request. The CR consists of a cover page … … and an extract from the specification under consideration showing, using revision marks, all additions and deletions. Change control (2)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module For example, a CR to TS may be twice revised during the course of discussions in the WG before it is agreed. CR 4 to CR 4 rev 1 to CR 4 rev 2 to Several iterations of a CR may be required until the WG is happy with it. Change control (3)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module CR 4 rev 2 to CR 5 rev 1 to CR 6 to All CRs against a given specification (or a given work item) are gathered together by the Support Team* prior to each TSG plenary. A single TDoc is created, with a cover page introducing each individual CR. * In practice, by the Secretary of the WG responsible for the spec. The TSG examines each CR and approves or rejects each. Some CRs may be reworked during the TSG meeting and re-presented (with a new revision number). Change control (4)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module CR 4 rev 2 to CR 5 rev 1 to The Support Team (MCC) incorporates the approved CRs into the base specification … v3.0.0v3.1.0 Change control (5)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module v3.1.0v3.2.0v3.3.0 … The controlled revision of specifications can continue in the same manner, with CRs being produced and approved. CRs allow full traceability of the changes wrought on a document since its original approval. Change control (6)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Using the Change Control mechanism described, it is always possible to: See the differences from one version of a spec to the next. See the differences from one version of a spec to the next. If necessary, back-track by de-implementing Change Requests which prove to be flawed. If necessary, back-track by de-implementing Change Requests which prove to be flawed. Know exactly what set of specifications a system is to be built to. Know exactly what set of specifications a system is to be built to. Change control (7)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module The initial “system” is composed of a coherent set of related standards. All these standards have version numbers of the form 3.y.z and are known as Release1999. Eventually, the functionality of Release 1999 became stable. The Release was “frozen”. Once frozen, no more functionality may be added to a Release (or, therefore, to its component specifications). Only essential corrections are permitted. Change control (8)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module It is now possible to add further functionality in carefully designed features forming part of a new “Release”. Feature 1 specFeature 2 specFeature 3 spec Change control (9)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module … it is possible to raise Change Requests to each specification to include the new functionality. v3.3.0 Change control (10)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module v3.3.0v4.0.0v4.1.0 … The addition of the new features to the system implies an upgrade to the next “Release” of the entire system specification. Change control (11)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module New functionality may equally result in an entirely new specification rather than a change to an existing one. v0.0.0  v1.0.0   v4.0.0 Change control (12)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Release 1999Release 4 The result, in due course, is two complete sets of specifications: one for each Release. Implementors (operators and equipment vendors) can choose which Release to build their systems to. Generally, newer Releases will be richer in features, but less tried and tested. Change control (13)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module A disadvantage of the “release” approach … Release 1999Release 4 An error discovered here … … may require not one CR but two to fix it … … because the same error may have been inherited from the earlier Release! Note that maintaining several parallel releases of the same specification implies very well defined procedures and highly disciplined handling !! Change control (14)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module A change control system along the lines described enabled the GSM specifications to undergo five controlled releases before the creation of 3GPP, and has allowed a smooth transition from second generation digital mobile communications to third generation and beyond, re-using as many of the basic elements as possible. This mechanism requires meticulous project planning and control… Change control (15)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Usually, an individual version of a spec may be withdrawn after its production only if it is replaced with a revised version. For example, a new version of v9.3.0 is produced after meeting SA#50. It is immediately noticed that one CR was incorrectly implemented. A new version is produced straight away to correct the fault, and version is withdrawn. Version will never be transposed into a publication of the OPs. However … Version will remain in the archive directory on the 3GPP server for ever. Withdrawing obsolete specs (1)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Consider now that a new version of , v9.4.0, is produced after SA#50. Version is not withdrawn, but remains in the meeting directory pertaining to SA#50. It also remains in the archive directory. But it is obviously superseded by v9.4.0 at SA#51. No maintenance will be done on v9.3.0 once becomes available. Withdrawing obsolete specs (2)

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Short answer: on the 3GPP file server. So where do I find the 3GPP Technical Specifications?

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module Longer answer: on the 3GPP file server. The following directories are maintained: So where do I find the 3GPP Technical Specifications? Meeting-related directories Hold all specs current as a result of implementing the approvals at the corresponding SA plenary meeting. Latest Holds the latest version of each spec currently under change control. Latest drafts Holds the latest version of each draft spec (i.e. those not yet under change control). Archive Holds every version of every spec, including stopped / withdrawn ones.

© 3GPP 2009 Mobile World Congress, Barcelona, 19 th February 2009© 3GPP GPP The Training Course / Module For more information visit Or contact