Presentation on theme: "TGac Ad-hoc lifecycle model"— Presentation transcript:
1 TGac Ad-hoc lifecycle model Month Yeardoc.: IEEE yy/xxxxr0TGac Ad-hoc lifecycle modelDate:Authors:John Doe, Some Company
2 Revision historyR1: 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-hocEarlier 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?
5 Establishing requirements Purpose of this phase is to determine the features that the ad-hoc is supportingDuring this phase we expect to see justification of featuresi.e. performance simulations/results, complexity estimatesOutput 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 designe.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 textDuring this phase, the ad-hoc writes text for incorporation into the draft amendment.Only “low level design” decisions are made at this stageAll feature decisions and top-level design decisions have been made in previous phases of the lifecyclePhase 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 TGacThis 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 ballotIf we have a hard switch, we need to formalize two transitions:From requirements to top-level designFrom top-level design to drafting textIf have a “soft” switch, an ad-hoc can move between phases as it needse.g., to reflect learnings from design back into requirementsWhich 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 decisionsWe have only two documents so far:FrameworkDraft AmendmentDo 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 Yeardoc.: IEEE yy/xxxxr0Comparison of the ‘Hard Switch’ and ‘Soft Switch’ Approaches‘Hard Switch’‘Soft Switch’‘Requirements Definition’‘Systems Design’‘Spec Text Development’System Design DocumentSpec Framework DocumentSystem Design DocumentDraft TextDraft TextSource: Rolf de Vegt (this and next slide)Slide 11Page 11John Doe, Some Company
12 Alternatives for Major Taskgroup Decision Points Month Yeardoc.: IEEE yy/xxxxr0Alternatives for Major Taskgroup Decision PointsFramework UpdateSystem DesignDraft TextCoexPHYMACMUFramework UpdateSystem DesignDraft TextHard SwitchLetter BallotFramework UpdateSystem DesignDraft TextFramework UpdateSystem DesignDraft TextSystem DesignDraft TextCoexPHYMACMUSystem DesignDraft TextSoft SwitchLetter BallotSystem DesignDraft TextSystem DesignDraft Text= Taskgroup Approval Decision PointSlide 12Page 12John Doe, Some Company
13 Straw poll 1Should we have a separate system design document, or should we use the framework document to hold the system design?Separate 6Framework 24Don’t know yet 34
14 Straw poll 2Should 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 0Allow iteration 36Don’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 PollDoes an ad-hoc need TGac permission before starting to consider/generate draft text?Yes – needs TGac permission - 2No – can generate draft text whenever it likes - 32Don’t know- 27
17 Straw Poll 2If 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-hocA single decision point across all ad-hocs.Don’t know