CCIUG,
RE: This is a follow-on to my 2/2/2000 email to CCIUG, about the use of
UCM's "project" objects
I've already received some very useful advice by CCIUG responders (notably
Brad Appleton) to my initial email. (Actually the reply I *enjoyed* the
most was from Taher Jaafri, dated 02/03/2000 02:09 AM GMT.)
I'd appreciate some more help with our planning for use of UCM's
"projects". This time my question is on the same topic, but more specific.
QUESTION
------------------
For the entire time span during which we're doing code development on ACME
Release 1.0 and its subsequent ACME 1.x patches should we:
A) Employ just one UCM "project" for ACME 1.x code-development work.
With each developer using his/her one-and-only (for ACME 1.x) development
stream for all their work in support of ACME 1.x.
Or should we:
B) Employ a sequence of UCM "project", each for a particular phase of
development. Where each developer will use a new, distinct development
stream for their work in support of each associated UCM "project".
BTW ---- I'm leaning heavily towards solution B.
Our Development Life-Cycle for ACME 1.x
--------------------------------------------------------------
This is pretty typical stuff, but I thought it best explicitly write it out
some specific requirements.
The life-cycle of ACME 1.x will be broken down (a prophetic description?)
into sequenced phases.
Some particulars:
1) There are two types of development phases: pre-release-1.0 phases
involving most of our developers, and post-release-1.0, "patch", phases
involving very few developers. For this discussion, I'm primarily
interested in managing the pre-release-1.0 phases.
2) Each phase's code development begins with (is based lined on) an
interim code set of a sequentially "earlier" phase.
3) Each pre-release phase will last about 2 to 3 months.
4) It's expected that code phases will have some overlap (in the time
domain). That is, activities created during some sequentially "later"
phases will begin earlier (in time) in the life cycle of sequentially
"earlier" phases, or perhaps even before (in time) work on some
sequentially "earlier" phases has even begun.
5) Code modifications of activities created in a sequentially "later" phase
should not destructively disrupt the functionality of activities that are
to be completed in sequentially "earlier" phases.
6) Development activities supporting each phase will be scheduled for
creation and completion during that particular phase. Of course, a
significant number of activities that are created in one phase will spill
over or be interrupted and rescheduled to a later phase. Occasionally, an
activity created in one phase will be postponed and rescheduled to an
earlier phase.
7) Each phase's activities target a "major-build" transmittal of a
pre-release version of the 1.x product to our test group, for system-level
testing.
8) By the time of a phase's "major build" all of the phase's activities
should have been completed, abandoned, or postponed and rescheduled to a
later phase. However, invariably, work will continue on few of the phase's
activities that are not complete, but that must be completed in the same
phase, even if the schedule of that phase needs to be extended.
8) If the test group finds that a phase's transmit-to-test, pre-release
version does not satisfy the requirements on that phase, then management
may decide to extend work on the phase. Actually, you could safely bet
your next paycheck on the extension.
9) The extension's activities will usually include significant bugfix and
minor activity-completion work on the phase's code, and will proceed as a
series of "Transmit-->System_test-->Code" iterations, over a period of
about 2 weeks.
Thanks,
Dan
Dan Rickhoff
Centigram Communications Corp.
91 East Tasman Drive
San Jose, CA 95134
Tele: 408 432-2764
Fax: 408 428-3827
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:02 EDT