The real point is that SCM practices prevent defects and help insure the
quality of the code. The important metrics to consider are # defects
resolved by your development effort and an affirmation that these defects
are NEVER the result of a configuration management mistake. I have worked in
a number of companies where they had to create several releases (a week!)
just because they couldn't get the versions of the header files correct. We
fixed that.
The important thing is also to consider the validity of the metrics you
collect. A valid metric can be traced to some other criteria.
You mentioned some metrics that I think could be counterproductive. It's
best not to measure a person's performance using metrics. Measure the
process instead.
Good luck!
> -----Original Message-----
> From: Pease, Kevin [SMTP:Kevin.Pease@FMR.COM
> Sent: Friday, January 28, 2000 12:49 PM
> To: 'cciug@rational.com'
> Subject: [cciug] Suggestions for common metrics?
>
>
>
> > Hi all,
> >
> > I've received a rather vague request from the managers of a
> > ClearCase environment I provide support for, to "provide metrics" for
> this
> > environment. I have very little experience with metrics, however, and
> my
> > customer hasn't been very forthcoming about exactly what their
> > requirements are, so this is making it a bit hard to show them metrics.
> > What they've asked for is for me to come up with some suggestions as to
> > what might be useful metrics to track. So, this all leads up to my
> > question:
> >
> > What "common" metrics do you folks track? I've gotten some
> > suggestions already, namely:
> >
> > Number of builds, broken down by # of successes, # of failures; #
> > of failures broken down by "cause of failure":
> > 1. Development error - e.g., code change broke the build,
> > developers didn't check in all required code, etc.
> > 2. Systems error - e.g., build server crashed during build,
> > network died, etc.
> > 3. Scm error - e.g., release engineer didn't start the
> > build on time; build scripts failed; scm system crashed or hung in
> some
> > way, etc.
> >
> > Various ClearCase-specific numbers, e.g., # of branches, # of
> > elements, # of views, # of VOBs, etc etc.
> >
> > Changes between builds -- # of files changed, # of source lines
> > changed / deleted / added, etc.
> >
> > Can anybody offer any other suggestions about what kinds of metrics
> > you would care to collect (and would find useful)? Specifically, this
> is
> > a ClearCase 3.2.1 environment running on Solaris servers, with multiple
> > repositories on containing source in C, C++, perl, and various shell
> > scripting languages.
> >
> > Also, can anybody offer suggestions on good reference materials for
> > software metrics? (Title at least, preferably with author?)
> >
> > Any suggestions you folks can offer would be greatly appreciated!
> >
> > Thanks,
> >
> > Kevin Pease
> >
> > ----------
> > Kevin B. Pease FISC - SCME
> > Fidelity Investments Systems Company
> > kevin.pease@fmr.com (617) 392-9022
> > SkyTel Page: 1-800-759-8888, Pin # 4713841
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:41 EDT