Major Developmental Decision Points

The following major decision points are asserted here, in approximate sequential order1:

  1. When the developer and customer agree on the “big picture” of their objectives for the system to be developed2;
  2. When the developer and customer agree on a “big picture” approach for achieving those objectives in a single design3;
  3. When the developer and customer agree that the developer has identified and characterized the major pieces of the system expected to achieve those objectives;
  4. When the developer and customer agree that the developer has a detailed design(n) of those pieces, including the detailed criteria for 1) proving satisfaction of the objectives, and 2) showing correct fabrication of an instance of the design’s pieces;
  5. When the developer and customer agree that the developer has proven the detailed design to achieve the stated objectives to within an uncertainty that is both reasonable and sufficient to the purpose;
  6. When the producer and customer agree that the producer has a detailed manufacturing plan for fabricating, assembling, and accepting the elements of that design.

Figure 1 loosely illustrates the sequence of these decision points, with each decision occurring at the end of the correspondingly numbered block.  I say “loosely”, because this particular figure doesn’t show all the opportunities for iteration, parallelization, integration4, developmental efficiency, customization, and evolution.  Its an archetype, for the general purpose of concept exposition.  The reader should not expect to ever witness a project exclusively executing the sequence precisely as shown.

 

major_decision_figure-v2
Figure 1. Archetypical Flow of Tasks Corresponding to the Major Decision Points.

The first two items in the Figure provide an intentionally over-simplified bootstrap framework.  Together, they provide a reasonably coherent set of inputs to the set comprised of the second three decisions, which are then recursively applied with more tightly focused scope5.  The last decision maps to those recursions in both identity and scope.  The last decision can be (but rarely is) semi-decoupled from the first five decisions; it can be (and usually is) applied individually for each recursion of steps three through five.

For clarity of description, I break the detailed examination of these three into three distinct discussions.  I recommend (however) that a first-read be conducted out of execution order, as follows:

  1. The CI Development Cycle (decision points 3, 4, and 5).
  2. Project Startup (decision points 1 and 2).
  3. Production Development (decision point 6).

 

Footnotes
  1. We could argue for days about why these particular decision points were identified in the legacy as being critical.  Let’s not![↩]
  2. It might be inferred that this phrasing implies that our process applies to CRAD only.  This may, or may not, be true, depending on the exact definitions of “customer” and “developer”. [↩]
  3. which might actually be a family of similar parts[↩]
  4. which can be either vertical or horizontal, or both[↩]
  5. The “focus”, however, can be in any of many different domains.  More to come![↩]