Path: utzoo!utgpu!watmath!att!occrsh!uokmax!unmvax!aplcen!haven!purdue!bu-cs!snorkelwacker!mintaka!oliveb!pyramid!decwrl!dogie.macc.wisc.edu!uakari.primate.wisc.edu!ginosko!uunet!richsun!cweir
From: cweir@richsun.UUCP (Charles Weir)
Newsgroups: comp.software-eng
Subject: Re: Schedule and budget are secondary
Message-ID: <623@richsun.UUCP>
Date: 19 Oct 89 00:45:41 GMT
References: <16168@vail.ICO.ISC.COM> <6693@hubcap.clemson.edu> <16187@vail.ICO.ISC.COM> <1189@mrsvr.UUCP>
Reply-To: cweir@richsun.UUCP (Charles Weir)
Organization: RICH Inc. , Franklin Park,IL
Lines: 43

In article <1189@mrsvr.UUCP> hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163) writes:
>In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>>It is entirely possible to construct software which meets all such require-
>>ments, but which is poorly conceived or implemented.  Examples abound.  I
>
>Therefore   it  is  time  someone   addressed  the  issue   of how  to
>quantitatively    specify    nebulous  terms   like "user   friendly",
>"maintainable", "extendible", etc.  In  a requirements document, these
>terms have no meaning aside from the warm and  fuzzy connotations.  [...]
>How   does  one  specify  a  requirement   for "user  friendliness" or
>"well-written"? 
>

Tom Gilb, in his book "Principles of Engineering Management", devotes a
lot of attention to this problem.   He recommends a system of
metrication for all of these things.   It's not impossible - just
important:

The following is taken from a the chapter "Attributes Specification". ,
and is only section out of some twenty from an example specification:

MAINTENANCE COST:
SCALE=minutes/line of non-commentary source code maintained/year
TEST=Logged maintenace minutes for system/estimated code lines
WORST( New code, created by new process) = 0.2 min/LOC/year
WORST( Old code, existing today) = 0.5 min/LOC/year
PLAN(new code)= 0.1M/L/Y (based on Fagan's inspection experience)
PLAN( old)= 0.3 M/L/Y
NOW(estimated overall for Company today) = 0.5 M/L/Y
REFERENCE= now estimate is based on 5000 programs, avg. 5000
           loc/program, 70% of 250 programmers in maintenance

Note:   The targets (he calls them metrics) are measurable.   There are
best and worst values according to what actually happens: that answers
the question "Well how can I predict until I know exactly what I'm
doing?".    And the figures will provide a reference for estimating
success and failure.

I'ld be interested to know if anyone else out there is used to doing
this kind of analysis.   I find it valuable.

Charles Weir
Own Opinion.   Might be company's too.