A Question About Measures

Can someone please help me with the following questions:

1. Are there examples of typical or common measurements than an organization can use for every process area? (different examples appear in Generic Practice (GP) 2.8)
2. Where I can look up them?
3. Are there some measurement standards that show or define typical or common measurements? Which?
4. Do they apply to a specific Process Area (PA)? If so, which PA?

Granted there are some common measures such as effort and time spent on an activity. But the underlying principle of the CMMI and more importantly Measurement and Analysis (MA) is to define your goals and objectives and use them to determine your measurement needs. Then you will be able to easily specify those measures that have the most value to your organization and projects. You have to understand why you are collecting a specific piece of data and how you are going to use the information to make a decision, otherwise you will have difficulties and over time people will forget why you are collecting and using the data. They will not see the benefits of these measures. As I have posted to this blog before, start with the MA Process Area and use the practices to define your measures, how you will collect , analyze, report, and use them. MA is based on Practical Software Measurement (PSM). Read the PSM book and visit the PSM web site http://www.psmsc.com/ . The book is very easy to read and understand. It contains several case studies and example measures that will help you define your organization’s measures.

Peer Review Defect Categories

During peer reviews and testing we find defects and record them in defect log sheet. These defects can be used further for defect data analysis or other purposes (defect prevention). Keeping all these in mind, what defect categories should the organization use for better and easy analysis?

Rather than ask what others are using as defect categories, you should be analyzing your defect data and determine the categories that your defects naturally fall into. These categories also need to have meaning for your organization. If you were to use someone else’s categories and these categories do not relate to your products, projects, or organization, then they will be meaningless. Just like the exercise you should be going through to define your measures (MA), you should also perform a similar exercise to decide on the defect categories. In point of fact, this decision is one of the Measurement and Analysis (MA) steps you should be doing to define your peer review measures. You are really talking about what the CMMI calls derived measures. One set of defect categories MIGHT be process defects, requirements defects, design defects, and interface defects. However, once again, you have to determine which categories support the information needs you should be documenting by following the MA process. Basically, what problem(s) are you trying to solve by performing peer reviews? Once you can clearly answer that question, then you will be able to determine your necessary defect categories.

Satish Kumar provided some addtional information to my response:

Typically IBMs Orthogonal Defect classification is widely used in software projects with minor additions / modifications to defect types. You can get more details about the same from the following link: http://www.research.ibm.com/softeng/ODC/ODC.HTM

The link takes you to IBM's "center for software engineering"site. Browse through the publications to find good information about defect classification.

Note: In your organization's defect types categories, avoid using a type named "Miscellaneous / others". My observation is when we included this type, people had a higher tendency to classify using this category and this is not useful to do any defect analysis.

Thanks & Regards,
Tumu Satish Kumar
SCAMPI Lead Appraiser
CMMI Instructor
Concept QA Labs Pvt. ltd.
www.conceptqalabs.com

CMMI-ACQ - Agreement Management

Agreement Management (AM) is a Maturity Level 2 (ML 2) Process Area (PA) in the CMMI-ACQ. Basically this PA is a more robust treatment of the CMMI-DEV PA Supplier Agreement Management (SAM) Specific Goal 2 (SG 2), Satisfy Supplier Agreements. The Specific Goal and most of the Specific Practices have the same titles between the two PAs. However, the details are quite different.

AM only has one Specific Goal - The terms of the supplier agreement are met by both the acquirer and the supplier. SAM uses the term project instead of acquirer. This difference means that AM is applied in a broader sense than SAM. SAM focusses on the project's needs for acquiring a product or service from a supplier. AM focusses on the acquirer, which may be
· Procurement
· Purchasing
· Outsourcing
· Supply chain
· Buyer
· Contracting
· Logistics
· Supply sourcing
etc.
Mike Phillips/SEI said in the CMMI-ACQ class that he has a list of 17 different terms for acquirer.