kmccook@wrdis01.af.mil (Ken McCook) (04/17/91)
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. ________________________________________________________________________________ Ken McCook U.S.A.F. 1926th CCSG Robins AFB GA (912) 926-3224 kmccook@wrdis01.af.mil (DSN) 468-3224 ________________________________________________________________________________
mike@pmafire.inel.gov (Mike Caldwell) (04/19/91)
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
ksh@ai.mit.edu (K. Shane Hartman) (04/23/91)
Software Productivity Research, Inc. (Burlington, MA) sells an integrated Estimation/Measurement/Assessment package called Checkpoint. We also provide consulting services to aid in the implementation of a measurement program and to provide guidance in the use of measurement to improve your software development process. We call this Applied Software Measurement. Checkpoint provides the ability to capture information about individual projects at several levels, including Deliverable Sizes Defects, by severity, total and origin Staffing Effort Schedule Cost Checkpoint provides support for modern functional metrics (such as function points and feature points) as well as lines of code. Finally, important business metrics such as NPV, IRR, and Risk/Value analysis can be captured. All of the above can be captured across a variable set of 140 tasks (so almost any system development methodology can be represented). Checkpoint is also capable of estimating the above quantities, based on knowledge collected in the course of consulting (our database consists of 4000 projects collected from MIS, Systems, Government and Commercial contracts collected over the course of the last 10 years). You can measure what you know and Checkpoint will estimate any missing pieces. You can compare (assess) your performance on individual projects against this knowledge base. Since hard data is inadequate for determining what was "right" or "wrong" with a particular project, Checkpoint also collects some 200 "soft factors". These soft factors (multiple choice questions) describe the Technology, Personnel, Process, and Environment associated with a particular project. The approach is similar but superior to the SEI software maturity level (the latter is based on a series of binary yes/no questions and uses a peculiar grading scheme which is not applicable to measuring incremental process imporvements). Both hard and soft data can be aggregated into a portfolio which can be used as a standard for comparison or a template for estimation. If you want more information, please contact us at 617-273-0140. Shane Hartman Director, R&D
cml@tove.cs.umd.edu (Christopher Lott) (04/23/91)
About Mr. Shane Hartman's article plugging his product: Ok. I advertise stuff from our group, but it's FREE. I'm certain that Mr. Hartman is in the s/e business for PROFIT. Folks, please do NOT post such articles in this (comp.software-eng) group. The piece on the product(s?) sounds interesting and all, but it reads to me like an ad. Net etiquette on Usenet forbids such postings. If you MUST post about your company's product, please make it SHORT. I mean REALLY short - a few lines plus a contact-point will suffice. If I want to hear all about the newest CASE tools sold by the kabillion consultants and companies in s/e, I'll contact them. In the mean time, let's keep the signal-to-noise ratio in this group up. Thanks. chris... p.s. If I'm waaay out in left field on this one, uh, flame away I guess. -- Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 cml@cs.umd.edu /\ 4122 AV Williams Bldg 301 405-2721 <standard disclaimers>
ksh@ai.mit.edu (K. Shane Hartman) (04/24/91)
Sorry, I just started reading this stuff (and so was not aware that such things are considered bad taste). I did not mean to plug the product, I meant to answer the man's question. I will keep such responses private in the future. Actually, I am not in the software business for profit, though. I love it as a profession (in fact, I can't believe that people pay money to have this much fun!). As long as my mortgage is paid, I don't care where the money comes from or how much. Shane Hartman
kmccook@wrdis01.af.mil (Ken McCook) (04/24/91)
Hi Shane, I didn't mind a bit. Hey, I look at it from the point of view that if someone has the answers I'm looking for and is willing to share the information with me, then that's *GREAT*!! I've used USENET to find vendors & contractors that had products for sale that might satisfy a need we have. It's a unique way for our community to share knowledge & info and I'm glad to have it. It's our resource to use as we wish. So don't sweat it! Again, I *APPRECIATE* the reply! Ken McCook, Computer Programmer Warner Robins Air Logistics Center 1926th Communications-Computer Systems Group Software Development Branch Robins AFB, GA 31098-6346 Commercial (912) 926-3224 (DSN) 468-3224 Email kmccook@logdis1.wr.aflc.af.mil