[CMC] Re: Proposed new development time limits
Adrian J. Hooke
adrian.j.hooke at jpl.nasa.gov
Fri Jul 28 12:33:28 EDT 2006
--------------------------------------------
>At 02:56 AM 7/28/2006, Gilles Moury Gilles:
>... it seems to me that time limits should be at least increased to :
> - phase 1 : 24 months
> - phase 2 : 12 months (2 cycles), 18 months (3 cycles)
> - phase 3 : 6 months
--------------------------------------------
>At 03:22 AM 7/28/2006, Jean-Francois.Kaufeler at esa.int wrote:
>I agree with the principle. I am less sure about the time figures. It
>would mean 3 years between start of work and standard publication! This
>may be the case for ISO, but our ambition should be to do it faster e.g. 2
>years.
---------------------------------------------
We clearly have some differing opinions about the amount of time that
should be allocated between chartering a Working Group and requiring it to
deliver its final product(s).
Many of us favor a short development horizon with very clear stages of
development and firm milestones for deliverables. It has also been proposed
that the CMC should manage by schedule, and not by resource allocations. If
a WG bogs down and fails to meet its deliverables, it's a warning sign that
needs the attention of the CMC. Right now, the WGs pretty much set and
modify their own schedules and, without an automated mechanism to monitor
progress and issue appropriate management alerts, the CMC tends to lose
visibility.
---------------------------------------------
At 03:52 PM 7/27/2006, Eduardo Bergamini wrote:
>Is it not the case to also add a separate track, with an appropriate
>scheduling, for the document version updating task ?
---------------------------------------------
Eduardo raises a good point, which is that an update to an existing
standard should theoretically require less time than developing a new
standard. However, this is not really a separate track: the process for an
update (White -> Pink -> Blue/Magenta) is the same for the original
development, but the schedule will usually be compressed.
Best regards
Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cmc/attachments/20060728/0ea9946b/attachment.html
More information about the CMC
mailing list