Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!ogicse!zephyr.ens.tek.com!orca.wv.tek.com!baldwin!dougs From: dougs@baldwin.WV.TEK.COM (Doug Schwartz;685-2700;61-252;Baldwin) Newsgroups: comp.software-eng Subject: Re: Software Quality Message-ID: <10412@orca.wv.tek.com> Date: 22 Mar 91 16:16:27 GMT References: <1991Mar20.043236.1236@ox.com> Sender: nobody@orca.wv.tek.com Reply-To: dougs@baldwin.WV.TEK.COM (Doug Schwartz) Distribution: comp.software-eng Organization: Tektronix, Inc., Wilsonville, OR Lines: 28 In article <1991Mar20.043236.1236@ox.com> jih@ox.com (John Hritz) writes: >Although I agree with your three premises, I would not rule out the use of >metrics as a method for quality improvement. Without an objective >measurement by which to gauge success, you're just taking pot shots at >the defect issue. As I think you are asserting, quality starts from the And of course we are forgetting that there can be different levels of defects or the code can function in a manner that some of us might call defective: Returns incorrect value Program won't let you do something that you think it should Program does something unexpected Inconsistent user interface Confusing/missing/incorrect messages Program bombs with tricky/difficult to reproduce input parameters Program looks like it works, but doesn't Program doesn't save work or saves junk Installation program mucks with user/system files at will Trips switch to start WWIII Although all could be considered defects, I think the last is more serious than any of the previous (or all combined). What about defects by omission? How do we rate them? e.g. if you don't test for divide-by-zero, is this a defect? -- Doug Schwartz dougs@orca.wv.tek.com Tektronix Wilsonville, OR