[CMC] Re: [CESG] Proposed new development time limits
Jean-Luc.Gerner at esa.int
Jean-Luc.Gerner at esa.int
Thu Aug 17 07:16:55 EDT 2006
Rather than putting an a-priori universal time-limit on the cycles of
production of WBs, RBs and BBs, I would advocate dedicating more time from
the outset to evaluate the amount of resources and time needed for these
cycles. The durations you propose may be achievable for 'easy' standards but
not for the complicated ones. My feeling is that those books most appreciated
from the users community are those which demanded the greatest effort and
longest time (e.g. Image Compression).
I would like to highlight a few quotes from the CCSDS Restructuring Book
A02.1-Y-0.2 that should not be forgotten when embarking into a new standard
and setting-up a schedule:
3.2.1 CCSDS Proposed Standard (White Book)
"Proposed Standards will generally go through several "Issues" during which
they will progressively become more mature."
"As they progress, it is desirable to prototype Proposed Standards in some
kind of test system in order to gain experience and to validate and clarify
the specification."
"CESG may require prototyping and/or operational experience prior to granting
Proposed Standard status"
3.2.2 CCSDS Draft Standard (Red Book)
"A Draft Standard must be well understood and known to be quite stable, both
in its semantics and as a basis for developing an implementation. It will
generally go through several "Issues" during which time it will progressively
become more mature. Every time that an Issue of a Draft Standard is
published, it automatically triggers a formal Agency review and the results
of that review must be satisfactorily incorporated before a new Issue can be
published.
"At some point in the evolution of a Draft Standard ..., at least one
hardware or software prototype (or other implementation) must exist which
demonstrates and exercises all of the options and features of the
specification in an operationally relevant environment, either real or
simulated... the
implementation must exist prior to issuing a "final" Draft Standard"
Jean-Luc Gerner
TEC-ETN
Tel: +31 71 565 4473
"Adrian J. Hooke"
<adrian.j.hooke at jp
l.nasa.gov> To
Sent by: CCSDS Engineering Steering Group -
cesg-bounces at mailm ADs <cesg at mailman.ccsds.org>, CCSDS
an.ccsds.org Management Council
<cmc at mailman.ccsds.org>
cc
27/07/2006 20:38 CCSDS Secretariat
<secretariat at mailman.ccsds.org>
Subject
[CESG] Proposed new development time
limits
In a Secretariat meeting this week at the AIAA headquarters in Reston, VA, we
discussed the perennial problem of "how do we track and manage the progress
of work". It was noted that ISO has a public development process that
parallels ours:
http://www.iso.org/iso/en/stdsdevelopment/whowhenhow/proc/deliverables/schema.html
What isn't so well known is that ISO establishes strict time limits on how
long a standard can remain in each stage without being canceled. Basically,
if a standard stalls then this event will trigger clear warnings that are
sent out to announce slow progress and eventually - if corrective action
isn't taken - the work will be canceled by ISO management.
In our case, we have no standards that set the schedule for developing a
document. Basically, the current working groups have wildly different
schedules and it's difficult to track them all. Yet, in reality, there is a
natural maximum development time - about three years - beyond which it is
questionable whether data systems standard is any longer useful. That led us
to propose the following set of general principles:
1. When a Working Group is chartered, it must produce its first Draft
Standard/Practice for Agency review within 18-months. In most cases, that is
a Red-1 book accompanied by a Green-1 book.
2. That document must be ready for final Agency review within 12-months
(presumably, that is no more than two cycles, i.e., Red-2/Green-2 and
possibly Red-3/Green-3)
3. Publication of the final document (Blue-1, Magenta-1, Green-n) must occur
within a further 6-months.
This schedule is indicated on the attached graphic. If adopted as a standard
"way of doing business", we believe that it could make tracking and reporting
of progress significantly simpler and it could also make it easier to
automate the web-based generation of Working Group charters and their
accompanying milestones.
As noted, this would be a "general principle" rather than a rigid rule and in
some circumstances a document would be permitted a longer cycle; but we think
that those would be the exceptions, rather than the common case.
Comments are invited.
Best regards
Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)
(Embedded image moved to file: pic26292.jpg)Emacs!
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic26292.jpg
Type: image/jpeg
Size: 206321 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cmc/attachments/20060817/bd9b0a04/pic26292-0001.jpg
More information about the CMC
mailing list