OpsGL use cases (pls look for Monday)

QAWG --

The last detail of which I'm aware, in order to publish next OpsGL:  it 
must have some Use Cases, in order to be SpecGL compliant.  Here are a few 
ideas.

These summary-level descriptions would be in a subsection at the end of the 
introduction (see current editor's draft [1]), in the same way that SpecGL 
is doing its use cases.  (If we follow the SpecGL lead further, then there 
would be a more detailed description, with actors and enumerated steps, in 
a parallel section of OpsET.)

Comments?  Critiques of the content of any of them?  Should there be more 
than the 4 that I outlined?  (If 'yes', then specifically what?  In fact, 
how about writing it -- 5 or so sentences?)

### start UCs ###

(1) A new Working Group is forming, and the charter is just being 
drafted.  The Charter team, including prospective WG members, consults the 
"QA Framework:  Introduction".  Appreciating the value of early quality 
commitment and integration, the team refers to OpsGL.  Using the Charter 
Template (linked from OpsET), it writes into the WG's draft Charter its 
quality-level commitments, test material plans, anticipated QA 
deliverables.  It documents its intention to build the test materials 
within the WG (in this case), and in its Call for Participation it asks for 
participation by some QA specialists.

(2) A Working Group was chartered several months ago, before a stable 
version of Operational Guidelines (OpsGL) was available.  The WG has just 
finished writing its Requirements documents and Use Cases, and is beginning 
to draft its specification.  Concurrently, it is starting to discuss test 
suite plans, at a face-to-face meeting.  Consulting OpsGL, it immediately 
appoints a QA Moderator and a team that will work on the test suite (part 
time on QA, and part time on specification technical issues).  Using the QA 
Process Document (QAPD) template that is linked from Operational Examples & 
Techniques), it has drafted and posted its first version of its QAPD by the 
time the meeting is finished.

(3) A Working Group has been re-chartered to finish a Second Edition 
(maintenance release) of its standard, and to develop the next functional 
version, 2.0.  No test suite development was done during the first charter, 
but some test suite development has happened by a collaboration of outside 
organizations and an industry consortium.  The Working Group reaches 
agreement with the outside developers to transfer the suite to a stable 
home and repository in W3C.  Operational Guidelines is consulted for a 
detailing of preliminary steps, requirements, and specific activities 
involved in making a smooth and trouble-free transfer.

(4) A Working Group is almost ready to request Candidate Recommendation 
(CR), and has met its goal of having a comprehensive test suite (TS) built 
in time for the trial implementation period of CR.  As it looks at making 
the TS publicly available, it finds numerous procedural issues about TS 
publication, that it had not anticipated.  The issue of appropriate 
licenses for the TS is proving particularly hard -- some are adamant that 
the tests must be unalterable, to protect their integrity, but others point 
out that the TS cannot be applied by users without making some custom 
interface adaptations to their implementations.  Consulting Operational 
Guidelines (OpsGL), the WG settles on a component approach to applying 
licenses (W3C Software and/or Document).  In the bargain, other OpsGL 
suggestions about publication and promotion, including providing a WG 
sponsored Web space in which implementations can publish their TS results.

[(5) ???another about a Contribution & Review process... using 
not-yet-written, but anticipated, OpsET templates and examples???]
### end ###

Regards,
-Lofton.

[1] http://www.w3.org/QA/WG/2003/07/qaframe-ops-20030711.html#terminology

Received on Sunday, 27 July 2003 20:19:16 UTC