Woo! Below 500! Below 440 actually.

Day 5…

  • As long as you think of the CMMI as a collection of good practices that warrant consideration to improve the effectiveness and efficiency of your projects, it’s hard to go wrong – there’s some pretty good stuff in there. Once you lose sight of this approach and start getting focused solely on achieving a CMMI maturity level, you’re likely to lose your way and drift into the weeds.
  • With high maturity organizations, most have addressed ML4 and ML5 concerns concurrently – without really doing so explicitly.
  • ML4 is the only maturity level in the CMMI that isn’t really about IMPROVING anything. Rather, it’s about performing ever more consistently to your known level of capability. Your performance is so consistent that the measures streaming off the process reflect this stability and can be subjected to quantitative techniques such as statistical process control, regression analysis, multivariate analysis, etc. to understand variation in the process.
  • ML5 is all about getting even better than you already are. That is, with the deep quantitative understanding provided by ML4, you can introduce process or technology change in a controlled way, establishing and verifying (or denying) hypothesized benefits from each proposes and piloted change.
  • Object Oriented Models
    • An object model is a static representation of the system resolution area considered. In a practical term, its the class diagram arrived after detailed analysis of the problem area. This is a static
      functional representation of a use case. So, its a clear object oriented concept.
    • Functional model need not be represented in OOPs concepts. But a simple representation of functions & sub-functions of a system. Please remember, the sub-functions can still be broken down to the leastpossible unit of software unit…ex: a subroutine.
    • The behavioural model is the state transition diagram of the represented system. Lets subject the static “object model” to stimuli from the external world, the a level of dynamism is included in the object model which will represent the various states of the object due to external stimuli. These will be represented in State transition diagram & forms a part of detailed design analysis.
  • The biggest issue (to implementing CMMi) is the cultural change that is needed in ML2 when you have to plan your process and following it during the project.
  • “Six Sigma” training makes its graduates effective “change managers.”
  • One suggestion would be to investigate the “IDEAL” model on the SEI site. It is a way to describe the broad approach to improvement changes in a disciplined fashion.
  • Practical Software Measurement resources
  • Schedule Variance = Actual Duration – Planned Duration / Planned Duration
  • Some examples of schedule variance
    • Only 60% work completed in 100% efforts
    • Schedule revised by 30%
  • The first step in determining the success or failure of process improvement is to first define what YOUR organization means by the word “improvement.”
  • Requirement Stability Index. It is the ratio of “Number of requirement changes” to “Number of stated requirements”.
    eg: Lets say the customer had stated 10 requirements and baselined. Now there are 2 more requirements which creep in.
    The RSI would be [1 – (2/10)]*100 = 80
    The RSI value should be very high which means the requirement elicitation process was very effective.
  • Measures are only useful if they lead to better decisions or appropriate actions. Determine what you want to know or what problem you’re trying to solve before you just implement a measure because the CMMI (or some other goofy model) tells you to! (Assuming that was the motivation behind your original question).
  • Risk
    • “Risk” has two major attributes – it’s a probabilistic event where the probability is less than 100% AND it’s a BAD thing
    • Risk Exposure = Pobability * Impact
    • By sorting the risk list by Risk Exposure, you can determine which risk statements warrant the most attention. As an organization, we may declare that any risk whose Risk Exposure is 10 or greater must have a risk mitigation plan, and an risk whose Risk Exposure is 12 or higher must also have a risk contingency plan.
  • “Normal Mode” is a process/procedure that includes all cases or explains in detail the steps of process. “Expert Mode” is a quick-reference to work. It contain the same steps that process or procedure with a little explanation.
  • No time for testing? Just implement a customer satisfaction checklist to explore why your customers are now buying your competitors’ products.Quote of the Day I think
  • Traceability
    • With CMMi V1.2, the definition of bi-drectional traceability is being revised to its simplest form: “an association among two or more logical entities that is discernable in either direction (i.e., to and from an entity.)”
    • Horizontal Traceability to show relationships across work products that are at a similar level of hierarchy. Eg, traceability between related requirements, or traceability between related modules, or traceability between related interfaces.
    • Vertical Traceability to show relationships among work products that are at different levels of hierarchy, eg, trace between reqs to code, or code to test cases, or test cases back to requirements.
  • Despite the fact it’s an older book (1996), “Chapter 7 contains the best overview of the various software development life cycles that I’ve seen.”