iSixSigma

SW-CMM

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #26007

    Clueless
    Participant

    Hi!  I have three questions regarding SW-CMM which I have listed below. I’d be glad if someone will help me in clearing my doubts.
    A) What are the deliverables of each KPA?   I have tried  to list out some of the deliverables according to my understanding, but I am not too sure. Please correct me where I am wrong and add where something is missing.
      LEVEL 2: Repeatable

     Requirements Management  : System Requirements allocated to the software
    Software Project Planning     : SOW(Statement of Work), SDP (Software Development Plan)
    Software Project Tracking and Monitoring
    Software Subcontract Management
    Software Quality Assurance
    Software Configuration Management   : Software Baseline library, Configuration Management library system
      LEVEL 3: Defined

    Organization Process Focus
    Organization Process Definition   : Organization Standard Software Process, SDLC, tailoring guidelines
    Training Program
    Integrated Software Management  : Project’s defined S/w process
    Software Product Engineering
    Intergroup Corodination
    Peer Reviews
      LEVEL 4: Managed
     

    Quantitative Process Management
    Software Quality Management
       LEVEL 5: Optimising
     

    Defect Prevention
    Technology Change Management
    Process Change Management
     
    B) Who is responsible for carrying out the actvities of each KPA
     
    C) SW-CMM continuosly talks of Project Manager and Projects Software Manager. How are these 2 designations different in terms of responsibility and authority?
     
    Thanks

    0
    #63189

    John J. McDonough
    Participant

    CMM is not a deliverables based methodology, it is an assesment framework which attempts to measure the maturity of a software development process.  CMM requires no deliverables, however, it is looking for evidence that you have processes in place to achieve certain goals, and a defined methodology which specifies certain deliverables could be evidence of that process.
    However, the goals CMM outlines tend to be fairly far reaching.  Just to take your top KPA as an example.  Your SRAS deliverable is probably a component, but certainly not sufficient to satisfy the KPA.  You not only need requirements, but you need evidence that the later artifacts in the project derive from those requirements.  So, for example, your design documents should describe what requirements they satisfy, your code should have some traceability back to the design,  you should have test plans and results which test that you satisfied the requirements, etc.
    In addition, you need to manage the requirements.  Anyone who has developed software for more than fifteen minutes quickly realizes that the concept of “freezing” the requirements is folly.  Requirements change, and better to recognize that than pretend it doesn’t happen.  So the assessor will expect that you identify these changes, and then reflect them in your development plans and downstream deliverables.  Your methodology may have deliverables to facilitate this, or there may be some items within your requirements and design deliverables to track these changes.  There needs to be in place a process, which may or may not be facilitated by deliverables, to recognize and track these changes, and to make decisions as to how the project will respond to these requirements changes and whether the budget and/or schedule changes brought about by these requirements changes will require that the project authorization be renegotiated.
    And this is just requirements management.
    Every KPA has similar impacts, so attempting to describe CMM in terms of deliverables is difficult, indeed.  Clearly, each KPA is going to impact some deliverables, and probably not all.  But to determine which requires that you have a well defined, detailed process, and you have articulated the process response to satisfy each KPA.
    –McD
     

    0
    #63200

    Gary A. Gack
    Participant

    I agree (as usual) with everything in John McD’s response, and add the following:
    1. CMM/CMMI are about defining the generally accepted attributes of effective software process elements (KPAs/PAs) – these definitions are deliberately permissive – you can satisfy them in many different ways, and the choices are up to you. PSP and TSP are examples of defined processes that substantially satisfy the goals/requirements of CMM/CMMI.
    2. Similarly, assignment of responsibilities and roles is a local choice – any structure that meets CMM/CMMI goals and intent is fine.
    3. As McD indicates, deliverables are not defined – you might look to software standards such as those developed by the IEEE or ISO for illustrations of deliverables produced by particular processes. Those standards will to a great extent align with KPAs/PAs.
    The role of Six Sigma in all of this is to make sure whatever you decide aligns with quantifiable business objectives and is both optimized and controlled.
    best regards,

    0
    #63216

    Khandekar
    Participant

    Even if CMM does not tell you how to satisfy it’s requirements, it generally tends to be deliverable based in actual implementation. Your process and it’s deliverables should be able to satisfy each key feature (under committment, ability, measurement, activities and verification) of each KPA. Some deliverables will be project specific and others will be more towards policy of the organization.
    Just to take an example of Req mgmt. Your process may require a defined set of requirements in a defined template for each project. You will also need a policy that guides RM. You will then need a defined meathod for change control, a way of measuring requirements and a way of verifying RM activities. All this and you still have mot satisfied all key features.
     

    0
    #63219

    Thomas Gorham
    Member

    As McD points out, making the leap from knowing the right questions to ask in order to assess capability and knowing the right answer to realize a capability in  your environment (let alone getting your entire organization to behave accordingly) is far from trivial. 
    A pragma Systems white paper estimates that, based on the SEI’s data, the typical cost of turning the SW-CMM into a deliverables based methodology and rolling it out to a certifiable level runs between $750,000 and $10,000,000.   
    Regardless of onerous implementation estimates, it provides a sound framework for identifying the capabilities that every development shop needs to be moving toward whether certification is the goal or the benefits of the individual practices are the goal. 
    As you explore, be aware that SW-CMM has been superceded by the CMMI (the I is for integration) which comes in a traditional feeling “staged” version and in a new “continuous” version that, to my thinking at least, makes more sense in a value driven environment.   
    Thomas Gorham

    0
Viewing 5 posts - 1 through 5 (of 5 total)

The forum ‘Software/IT’ is closed to new topics and replies.