Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!mit-eddie!snorkelwacker.mit.edu!usc!sdd.hp.com!news.cs.indiana.edu!att!att!drutx!druhi!seb1
From: seb1@druhi.ATT.COM (Sharon Badian)
Newsgroups: comp.software-eng
Subject: Re: Info wanted on Guidelines for Metrics
Message-ID: <7634@drutx.ATT.COM>
Date: 25 Feb 91 14:58:23 GMT
References: <1991Feb22.163103.26489@e2big.mko.dec.com>
Sender: news@drutx.ATT.COM
Distribution: comp
Lines: 27

in article <1991Feb22.163103.26489@e2big.mko.dec.com>, fjs@bonz.enet.dec.com (Jay Shields) says:
> As for CHECKPOINT's application to the question at hand,  I thought
> that
> the request for information about starting a metrics program at the 
> project level was sufficiently general that CHECKPOINT would apply. 
> It's been my experience that starting a full-blown metrics program
> from
> scratch can be rather difficult; tools such as CHECKPOINT often form
> the 
> initial phase of such a program. It would be interesting to hear from
> anyone who uses tools such as CHECKPOINT as part of their metrics
> program
> (or from those who think it has no such place). 

I was the person who made the initial request and the person who has
CHECKPOINT. So, I can answer the question of CHECKPOINT as a metrics
tool. I don't find it too helpful because there is no focus. You can
collect tons of information and not be too sure what you are learning
about your process. It is overwhelming. I want a smaller set of metrics
that allow me to answer important questions about my software process,
not a million of them that tell me everything I would ever want to know
(including things I don't really care about). That's why I'm interested
in the Basili goal/question/metric paradigm. It links metrics directly
to things you care about.

Sharon Badian
att!druhi!seb1


Brought to you by Super Global Mega Corp .com