Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!chinacat!uudell!pmafire!mike
From: mike@pmafire.inel.gov (Mike Caldwell)
Newsgroups: comp.software-eng
Subject: Re: How Is Your Project?  How Do You Know?
Message-ID: <1991Apr18.193508.27102@pmafire.inel.gov>
Date: 18 Apr 91 19:35:08 GMT
References: <460@wrdis01.af.mil>
Organization: WINCO
Lines: 67

In article <460@wrdis01.af.mil> kmccook@wrdis01.af.mil (Ken McCook) writes:
>
>I'm posting this to both groups to draw a wider response and because I write
>Ada code and think and design software systems in Ada. 
>
>(*PLEASE* follow-up to comp.software-eng).
>________________________________________________________________________________
>
>My Boss has asked that we try and define a statistical method that he can use
>to take the pulse of any given project so he'll have a *TRUE* indication
>of how that project is going.  He's looking for a Total Quality Management (TQM)
>consistent indicator using statistical process control (SPC).  
>
>I know software management is different from software engineering, but does 
>software engineering allow us to better measure a projects health?  We've toyed 
>with this notion for more than a year now to no avail.  I thought I'd put it 
>to the net and see what comes up.
>
>How do other managers and other development shops determine how well they are
>doing on a given project?  Can you develop indicators on the intangibles 
>involved in software development?  If software engineering is going to help us
>to build software like structural engineering builds bridges, what do other
>engineers use to measure their projects by?  I've read all the back-postings
>and have seen some good discussion about software projects each being as 
>different as a dam is from a suspension bridge, but can there be commonalities?
>Are they measurable?
>
>Someone must have a handle on this, after all, if a contractor/vendor couldn't
>predict with some degree of accuracy his capabilities to produce software
>products and how well he was doing compared to his estimate, then all projects
>would be underbid and overdue, and soon he'd be out of business.(?)
>
>Hope you find this thread worth some discussion!  I'm interested in all
>viewpoints.


You have to do it just like engineers do,  use your experience and
best judgement.  Periodically, you have to revise your estimates using
the results to date.  I've done estimates for both engineering
projects and software projects, and definitely find that software
projects are harder to estimate.  This may be lack of experience, but
I suspect most engineering projects tend to work with more concrete
items and that makes them easier.  It is easy to see that I need x ft
of wire or pipe betwen here and there.  I've got to go through x
number of walls at so much time and expense.

The real important thing is to start keeping track of the data now.
Know how much each line of code really costs.  Know how much each page
of documentation is costing. And keep an idea of the difficulty of the
project.  If you are estimating a project that appears to be similiar
in size to a previous project.  Knowing how difficult the project was,
can give you a good estimate.  If the project is twice as hard, triple
the estimates.  Also keep track of how hard you thought the project
was at the beginning and how and when your estimates changed of the
difficulty.  This will give you feed back on what you need to consider
when estimating new projects.  

There is a lot of documentation out there on how much a foot of wire
or pipe costs.  There are similiar estimates for software.
Unfortunately, the software varies a lot more than a pipe.


Just rambling,
Mike
-- 
Mike Caldwell (mike@pmafire.inel.gov or mike@inel.gov)
Paths: ...uunet!pmafire!mike