Download presentation
Presentation is loading. Please wait.
1
TGac Ad-hoc lifecycle model
Month Year doc.: IEEE yy/xxxxr0 TGac Ad-hoc lifecycle model Date: Authors: John Doe, Some Company
2
Revision history R1: Added straw polls and results during am1 TGac meeting. R2: Added discussion and straw poll related to generation of draft text.
3
Introduction TGac Ad-hocs are starting up activity this week
There needs to be a clear expectation of the phases of activity (the “lifecycle”) performed by an ad-hoc Earlier work (11-09/0237) addressed the contents of the framework document. It did not address how high-level design decisions should be recorded. This submission highlights the need to record these design decisions before drafting text. Also there are two questions that need to be discussed and addressed now: Are transitions between phases of activity formalized (e.g. formal sign-off that requirements are complete)? Do we record high-level design decisions in the Framework document, or some other document?
4
Lifecycle Establishing requirements Making top-level design decisions
Writing draft text Resolving comments
5
Establishing requirements
Purpose of this phase is to determine the features that the ad-hoc is supporting During this phase we expect to see justification of features i.e. performance simulations/results, complexity estimates Output is the Framework document, e.g. “Preamble shall support colored training symbols” ** ** The example is fictitious :0)
6
Making top-level design decisions
During this lifecycle phase, the ad-hoc considers alternative proposals that show how to meet its requirements (which have been documented in the framework doc). Eventually the group decides on mechanisms/methods/structures that meet its requirements. The output is in a TBD document (could be Framework document, or new system design document), containing high-level design e.g. “The preamble supports colored training symbols through the following structure: following the single spatial stream VHT SIG field there will be n VHT-LTFs, where n is the total number of spatial streams. the colors of the LTFs will be selected in order from: red, green, blue, red, green, blue … ” ** * This is still a fictitious example
7
Writing draft text During this phase, the ad-hoc writes text for incorporation into the draft amendment. Only “low level design” decisions are made at this stage All feature decisions and top-level design decisions have been made in previous phases of the lifecycle Phase is complete when the draft is approved for ballot
8
Resolving comments Comments will be received during letter ballot
The ad-hoc will be asked to provide resolutions for comments “in scope” of its charter, to be approved by TGac This phase completes when the IEEE Standards Board have approved the amendment
9
Moving between phases of the lifecycle
Do we have a hard switch? i.e. Once an ad-hoc has started making top-level design decisions, is it allowed to go back and change its requirements? Switch into comment resolution is necessarily “hard” because it is dependent on entry to letter ballot If we have a hard switch, we need to formalize two transitions: From requirements to top-level design From top-level design to drafting text If have a “soft” switch, an ad-hoc can move between phases as it needs e.g., to reflect learnings from design back into requirements Which is going to be the most effective way to operate?
10
Recording the top-level design
We need a place to record top-level design decisions We have only two documents so far: Framework Draft Amendment Do we need a third document “System design spec”, or can we use the framework document to capture this output?
11
Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches
Month Year doc.: IEEE yy/xxxxr0 Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches ‘Hard Switch’ ‘Soft Switch’ ‘Requirements Definition’ ‘Systems Design’ ‘Spec Text Development’ System Design Document Spec Framework Document System Design Document Draft Text Draft Text Source: Rolf de Vegt (this and next slide) Slide 11 Page 11 John Doe, Some Company
12
Alternatives for Major Taskgroup Decision Points
Month Year doc.: IEEE yy/xxxxr0 Alternatives for Major Taskgroup Decision Points Framework Update System Design Draft Text Coex PHY MAC MU Framework Update System Design Draft Text Hard Switch Letter Ballot Framework Update System Design Draft Text Framework Update System Design Draft Text System Design Draft Text Coex PHY MAC MU System Design Draft Text Soft Switch Letter Ballot System Design Draft Text System Design Draft Text = Taskgroup Approval Decision Point Slide 12 Page 12 John Doe, Some Company
13
Straw poll 1 Should we have a separate system design document, or should we use the framework document to hold the system design? Separate 6 Framework 24 Don’t know yet 34
14
Straw poll 2 Should we use a formal switch (i.e. by motion in task group to switch between requirements and system design) between requirements and design phases, or should we allow iteration between them? Formal switch 0 Allow iteration 36 Don’t know 16
15
When can we generate draft text?
It is clear that changes to the framework document, or changes to the draft text require 75% TGac approval. It is not clear (i.e., we haven’t discussed this in TGac yet) whether TGac approval is needed to switch between “requirements/system-design” and “drafting” phases in the ad-hoc.
16
Straw Poll Does an ad-hoc need TGac permission before starting to consider/generate draft text? Yes – needs TGac permission - 2 No – can generate draft text whenever it likes - 32 Don’t know- 27
17
Straw Poll 2 If permission is required for an ad-hoc to start generating draft text, is this permission granted independently, or coordinated across all ad-hocs? Independent decision points for each ad-hoc A single decision point across all ad-hocs. Don’t know
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.