Carol: Okay. Now, did the people in India...We were talking about goal question metrics, starting out with your goals of measurement before you actually pick your metrics. And I know a lot of my clients will come to me and say, "We need to implement function points," "We need to implement defect tracking." And they say, "What do we have to do?" And I say, "Well, what do you want to do with this?" And they're silent at the end of the line. Do companies in India...Are they more receptive to the goal question metrics? Do they do more planning?
David: I think along that score, perhaps they're really not any different. As I talked to...We actually incorporate the notion of GQM into a lot of the training that we do. And really try to get people to think through first, what's the purpose of gathering some data anyway? What do you really want to know? Not, what should I measure? We start with, what do you want to know and why? And it's interesting, because quite often, the first question is, what should I measure? And you've got to push people back. And there's the analogy there with requirements. You don't just start coding. You have to figure out, what are we trying to do here? What do we want to accomplish? And the same thoughts really apply to measurement. What we actually have done - a useful way for companies to proceed along this line, we have a course called Implementing Goal-Driven Software Measurement. And one of the things that we do is, we get people to think about what is it they want to know, or what do they want to learn. Draw me the indicator, or the graph. What would help you make that decision? What would help you understand the current status of the project? Whatever it is, whatever the purpose is, draw me the picture or the graph with sort of a mock-up, if you will, with the display, the line chart, the bar chart, scatter diagram, whatever it is, that would help you answer the question. Because that in turn can become the specification for what do you really need to measure, with what kind of frequency, where are you going to find the data in your processes, how is it going to be generated... It really becomes the specification for laying out, what then do you need to go out and measure. So we find that that's a pretty useful elicitation technique in terms of helping people think through what do they want to measure and how to get their measurement activities started.
Carol: And it's aligning what you're going to be measuring with something that's coming down the pike in the future. So if level 4 says you must use the measures to manage and make decisions, at level 3 we need to be saying, what decisions are we going to need to make?
David: We need to do that, and one of the real differences is between establishing arbitrary thresholds, however important they may be, and really understanding, if you will, the voice of the process, which is a level 4 concept.
Carol: And we'll be back to close out with more of Dr. David Zubrow and Quality Plus e-Talk! with Carol Dekkers after this short message.
And we're into our final segment with Dr. David Zubrow of the Software Engineering Institute. And David mentioned at the break that there's going to be a brand-new community profile. What's it exactly called, David?
David: It's the Community Maturity Profile, and