The CI Development Cycle (2 of 4): Introductory Discussion

As a Lead Mechanisms Design Engineer, I typically started my new-hires with some variation of the archetypical sequence shown in Figure 1 (extracted directly from Major Developmental Decision Points, Figure 1).

ci_development_figure_1v6
Figure 1. Archetypical CI Developmental Sequence

Figure 1 allowed me to explain how I wanted them to approach the design process on my watch, using words that ran something like the following:

  1. Figure out what your dingus needs to do and be, and what restrictions might need to be imposed on it1.  Come see me when you think you’ve got that far.
  2. Figure out how you want to deal with that.  Come see me when you think you’ve got that far.  A hand sketch might be adequate for that discussion, but bear in mind that the devil is in the details.  Bring the Manufacturing Engineer you worked with to conclude your basic idea is feasible.  If a “controlled” hardware item, bring your Software Engineer, too.
  3. Figure out how you plan to prove to me that your design actually works2.  Come see me when you think you’ve got that far.  Be advised in advanced that “Because I Can’t Think Of A Reason It Won’t Work” won’t be an acceptable opening position.  Bring the Materials and Process Engineer, Test Planner and whatever Analysts you worked with to arrive at your position on the subject.

A brief discussion usually follows.  Depending on how much experience the designer has had before joining my group, the discussion might be highly animated and punctuated with gestures of social and (improbable) anatomical significance.  It can be pretty entertaining for onlookers!

If the discussion survives long enough, we almost always cover the concept of a Configuration Item (CI) and how the concept fits into the program’s big picture.  Even though not all design tasks involve entire CI’s, it comes in handy later, and this is usually a good time to introduce the notion.

This basic conversation, with altered verbiage, applies equally to algorithm development3.  I usually don’t apply it to coding, because I find it best to leave such issues to Software Professionals4.

←Back to Preface

On to Part II: Intermediate Discussion→

Footnotes
  1. I often supply a first cut at these as part of that same conversation, but not always.[↩]
  2.   That is, qualification, but I don’t usually invoke that term in a first introduction.[↩]
  3. Except that algorithms are never stand alone CI’s.[↩]
  4. When it comes to software, I regard myself as a hobbyist.  However, I consider development of the algorithms that control the hardware as being in scope to hardware design, rather than Software Engineering.[↩]