850 message left. The catch-up continues.

Day 3…

  • An analogy to help understand RD (Requirements Development) 2.1, 2.3 and 3.2.
    So, you find that 2.1 deals with translating customer requirements into product requirements (aka technical specifications). For example, the customer requirements for an automobile might include aspects such as safety, cruising range, fuel efficiency, carrying load capacity, passenger capacity, towing capacity, and “fun to drive”. Each of these will be converted into a technical specification (especially the last one). 2.2 now will allocate the product requirements to the various components: drive train, fuel system, passenger compartment, braking system, entertainment system, etc. As for 3.2, although the title includes the word “define”, in fact, you see that it’s really “analyse” the functionality. Here we might see that in fact some of the functional requirements are synergistic (towing capacity and hauling capacity, for example) while others are contradictory (towing capacity versus fuel efficiency for example). Now, you may ask, why aren’t these three practices performed simultaneously or iteratively or even recursively; and you’d be right in all three cases. Remember that the model doesn’t impose or even infer an execution order. But these three practices are indeed independent and non-redundant.
  • Models MUST be used with your brain in the “ON” position.
  • We fully expect the “real” answers in organizations will be different from the precise answers in the model — and that these answers will usually be right for the organization, and the model again somewhat “wrong.” – Mike Phillips, CMMI Product Manager
  • Focus on the key points and use a 4- or 5-point Likert scale – Fully Compliant, Mostly Compliant, Somewhat Compliant, Not Compliant. This results in PPQA’s intervention serving as more of a consulting opportunity does using a simple “Yes/No” checklist. It also prevents the process executor from trying to do the absolute bare minimum to rationalize checking the “Yes” box.
  • Each documented process include the PPQA process verification checklist as part of the appendix.
  • How to choose a CMMi consultant
    • 5-10 yrs experience in cmm / cmmi
    • They apply the service (consulting or training session) to the real world problems of your organization. Hypothetical case studies are not used
    • They provide you with ideas or assistance in transitioning the concepts into use after the initial education
    • They are willing to customize the service to make it right for your situation
    • They provide a lifetime warranty on each service. You can call them at any time, and you don’t need a new contract for them to answer the phone
    • They return all phone and E-mail questions, before the next business day. They don’t leave you hanging for two weeks on important decisions
    • Their previous clients are satisfied. You checked
    • If they don’t have the expertise, they admit it, and refer you to someone who does.
  • Some of the real keys to quantitative management include
    • Stabilizing process performance – QM is about quantitatively managing PROCESSES, not just applying quantitative methods to a bunch of available DATA. Without stable processes you can still plot control charts, but they will do nothing other than give you a false sense of “insight” (and perhaps result in an unwarranted ML4 rating!)
    • Identifying “leading indicator” processes and related process data – it’s not good enough to just gain additional insight into your current status; it’s about gleaning insight into how it will all turn out – in terms of field reported defects, customer satisfaction, product performance, etc.
    • QM isn’t just something that’s applied at the end of the life cycle – leading indicator data is most useful when there is adequate lead time to take aggressive action to repeat previous success.
    • Measures are captured at the “process event” level – that is, process measures are captured and consumed as the events occur, not a week or a month later.
  • On Non Billable costs in the COQ (Cost of Quality) – If the updates are given by the customer after the delivery of the product, then it will come under external failure cost
  • Define the metrics in a way that gets YOU the best information, establish your current baseline, and look for ways to maintain or improve your measures.
  • “I see SOOO many software people (who should know better) write “processes” where these 2 steps are done once, these 4 steps are done when this trigger occurs, and these 4 steps are done on the first of the month. They’d never partition code so poorly, yet they do with processes. then they wonder why they can’t identify clear entry and exit criteria! All the basic SW engineering principles (modularity, information hiding, cohesion, coupling) should be applied when laying out your processes. You can also write separate processes for stuff that gets “called” from other processes (like peer reviews, or meetings), or when it’s a long and complicated bit, or when there are two ways of doing this bit (make them pick one).”
  • Build process documentation for the seasoned practitioner, NOT the ignorant person who is new to the role. You should have training material to accelerate that person through their transient state of ignorance, but don’t overburden your process documentation with a lot of “how-to” detail.
  • Buisnesses do not ,and should not,operate as the model is orginized.The model must be interpreted and mapped against the way the orginization does buisness.In fact,whenever we see orginizations whose processes align one-for-one with the practices by process area,we know we have lot of work to do
  • The sub-practice # 2 of OPD (Orginzational Process Description) 1.1 specifies the elements in a documented procedure. This could be adopted as a template.
  • Developing a Software Process Improvmement Plan