Measure effectiveness of Checkpoint reviews in various phases

Primary tabs

Suggest measures of effectiveness in the Checkpoint reviews in Requirement, External design, Internal Design and Program Specification phases.


 To reiterate, this question implies, how you would measure effectiveness of the checkpoint reviews during the various phases of software lifecycle. The following things can be measured for each phase, assuming checkpoint review process is carried out

 Requirements: 

·        Unambiguous          - Number of clarifications or questions raised during High level design or system requirements.

·        Completeness – Number of Additions or updations to requirements after requirements are freezed. Or Number of change requests.

·        Feasibility: Number of requirements feasible given the project constraints.

·        Alternatives:

Internal Design: 

  • Maintainability: Time taken to make enhancements and bug fixes
  • Reuse:              how many modules were reused?
  • Performance:  How did the software measure with performance?
  • Resources used: number of system and other resources used by software.
  • Impact The impact of any other module design on the design under review. This is important during the integration phase.

 External design.·

  •          Requirements Traceability:Number of design elements that were not easily mapped to stated requirements (The requirements, which are defined, should match the design or the prototype submitted.) 
  •  Stability:  Measured by results of stability tests and reliability tests ·        
  • Flexibility:Number of modules that were flexible enough to handle design and requirement changes. ·        
  • Alternatives:  Number of alternatives found to the designed solution that was better than finalized design. ( Many module designed can have an alternative solution, and whether the alternative solution has explored.·        
  • Error handling: Number of error conditions missed or not effectively handled (proposed design should handle all error conditions.) 

Program Specification

  • Resources: number of resources used by classes.
  • Modeling :  Number of components that accurately model the actual business scenario
  • Tiers: Measure how well was the n-tier architecture designed.

Comments

Kishore.Mavuri's picture

To add a point to the above given info, i have one more small methodology to measure the effectiveness of Checkpoint Reviews in various phases of SDLC.

For this mechanism to work there should be pre-defined condition that, ROOT-CAUSE_PHASE is to be found for every issue/bug/defect encountered through-out the Life-cycle. (It is advisable to find the Root-cause_Phase during the correction stage of every issue/bug/defect)

Lets suppose we have 'n' defined phases P1, P2, P3,... Pn. So for every issue/bug/defect, the possible Root-case_phases are P1, P2, .... , Pn.

Once we have the phase-wise defect data along with the respective root-causes, we can find the Checkpoint Effectiveness with the formula,

Checkpoint Review Effectiveness of Phase Pn = (No. of defects found after the phase Pn with root-cause_phase Pn)/(Total number of defects with the root-cause_phase Pn)

In ideal case, this value should be 1.0 which means we have an absolute effective review mechanism in place for that phase. If the values is below the Xpected value (Xpected values can be set with past data), the Checkpoint review mechanism is to be altered as per the need (by introducing more checklists or strict reviews,... etc).

With this we can arrive at basic level of review effectiveness values for all phases.

Plz give your comments at Kishore.Mavuri@gmail.com

Regards,
Kishore Mavuri