After 6 days, I’m all caught up now. Which of course is Yahoo’s queue to send the next batch at me.

Day 6…

  • Adopt ISO first, CMMI later, because ISO is easier to understand and implement. It can quickly help set basic for our process improvement, especially some organizational and operational processes also included.
  • Create a mapping of your processes to the standard you are targetting
  • IPPD goes beyond “collaboration of relevant stakeholder” and might be thought of as “integration of relevant stakeholders.”
  • The advantages with CMMI SW/SE model are:
    1. SW will help you to manage the project and follows the SDLC.
    2. SE will help you to select the better technology to develop a particular project.
    3. It will help you to take the appropriate technical decisions and at teh same time provide the solutions also. Ex. If there are three approaches to do a particular module then which approach is the best.
    4. Other processes which can help you to increase the quality are RD, VER and VAL in SE.
  • Audit is done against a known defined standard, process, methodology. Subjectivity and judgement is at a minimum here the definition rules.
  • Review on the other hand can be based on personal views and experiences and questions the assumptions and approach. Subjectivity and judgement play a role here.
  • Defect Density
    • Defect density: Weighted Defects / Size of project
    • Weighted defects: (number of critical defects * multiplying factor 1) + (number of major defects * multiplying factor 2) + (number of minor defects * multiplying factor 3) where multiplying factors may be 10 for critical, 6 for major, 2 for minor
    • Size: size of a software project can be in
      • Function Points
      • Use case Ponts
      • KLOC (kilo lines of code)
  • Value based Quality Engineering
  • In very simple terms, Contigency is “corrective” and mitigation is “preventive”. These terms are associated with Risk. For example, Contigency plan gives you the corrective actions which should be taken to eliminate a particular risk and Mitigation plan tells about the preventive actions to prevent the identified risks from occuring.
  • CONTINGENCY is for PAST and MITIGATION is for FUTURE.
  • CM is about making sure you have the stuff, the right stuff, and nothing but the stuff; whatever “stuff” you create.
  • There are four types of configuration audits
    1. FCA (Functional Config Audit)
    2. PCA (Physical Config Audit)
    3. In-Process Audits
    4. Traceability Audits
  • Causes of Variation
    • Common cause and special cause refer to types of variation that can be seen in the various run charts commonly used to plot process control baselines. Common causes of variation are the ups and downs we see as a normal consequence of performing our process. If the process is stable the variation we will see is around the centerline or mean and it will stay within limits.
    • Special causes of variation are caused by abnormal or transient circumstances. It is a variation that exceeds the control limits or violate the generally accepted rules defined the Western Electric Handbook that indicate an unstable process. Special causes are also referred to as assignable causes in some texts.
    • Both of these causes of variation can be analyzed using the CAR process. Remove special causes to return the process to stable and identify and work with common causes to improve process performance.
  • Good discussion around control charts and variation (including the criteria for categorization) in the book starting on page 66.
  • The CMMI Goals are “required” model components. You MUST satisfy all of the goals in the applicable maturity level 2 process areas or the result of the appraisal will be a maturity level 1 rating.
  • The specific and generic practices within the applicable ML2 process areas are “expected” model components. You must perform each of the practices given in the model OR perform an alternative practice that supports the corresponding goal equally well.
  • Quality of software by Mr. Client is Validation
  • Quality of software by Your Company is Verification
  • Early validation techniques include things like prototyping, storyboarding, mocking up screens, etc. These early validation techniques are intended to get user/customer feedback early and often to ensure that the ultimate product will meet the customer’s needs and work in their environment.
  • Too many people think that it must be something “extra” to meet CMMI requirements, when in truth, it all ought to just be common sense
  • OT is primarily strategic and equipping people to fill the roles defined in the organizational processes
  • The CMMI glossary got it right; it defines “training” as: “formal and informal learning options, which may include in-class training, informal mentoring, Web-based training, guided self-study, and formalized on-the-job training programs. The learning options selected for each situation are based on an assessment of the need for training and the performance gap to be addressed.”
  • . Chapter 3, “Managing the Process Improvement Project”. He breaks the process improvement project
    into 8 phases, and provides MS Project snippets for 5 or 6 of them.
  • A simple approach that you can use with the Continuous model to create a plan for progressing to higher maturity without having to plan every step for the next two years or so.
    1. Plan for your initial evaluation of your current state versus the CMMI practices.
    2. Identify 4-6 key practice areas which cause your team members (not upper management) the most headaches. People are most willing to make changes that promise to ease their own suffering.
    3. Prioritize these areas from lowest to highest maturity level. (Remember that areas affecting different team members can improve in parallel.)
    4. Create detailed plans for the first 2 or 3 areas, covering 2-4 months, with more general plans for the other 4-6 practice areas (and any others beyond those.) Any improvement plans beyond 4 months are dubious at best.
    5. As you proceed with the first areas, pay attention to the shift in problem areas reported officially and unofficially by the team members.
    6. Revise your plan each month to re-prioritize and add detail to the areas that have general plans. This approach is palatable to the “grand plan” folks, because they can see everything that you are planning to address. The lack of detail in the “out-months” is similar to what they are used to seeing with large plans, so they can accept that as well.
  • The word “development,” when used in the CMMI Product Suite, implies not only development activities, but also maintenance activities. Projects that benefit from the best practices of CMMI can focus on maintenance, development, or both.
  • Agile and CMMI address different sides of the problem – CMMI works on the “what” side, Agile methods are mostly focused on the “how” side.
  • “What I DO care about is that my people have the skills and knowledge to fulfill their roles effectively and efficiently – whether they get that from training, from job experiences at a previous employer, from on-the-job training, from conferences and seminars, from books, etc. The CMMI considers all of these knowledge-enhancing events as “training,” but too often we interpret “training” in the limited context of “classroom-based training” – don’t fall into that trap!”
  • Traceability in Forward direction – The requirements (identified to the smallest details and numbered e.g. each requirement addressing various individual functionality e.g. as small as possible) are traced for these having been adressed in designing, defining test-cases, coding & testing (unit,integration,system & UAT) & also keeping track of nos. of review-defects and/or test- bugs found at each subsequent stage. To check completeness of addressing all the requirements.
  • Traceability in Backward direction – At each stage whenever a defect/bug is noticed, it must be analyzed if the same is due to some deficiency (e.g. lack of understanding) at which earlier stage i.e. at that earlier stage the review/testing was not good enough to detect that deficiency and also find the cause (root- cause) of the incomplete work at the earlier stage which was detected at subsequent stage resulting into much costlier rework. these causes are to be removed to improve quality of work in subsequent phase/projects. To identify and undertake preventive action to improve quality i.e. process performance at each stage.