Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!oliveb!amdahl!pacbell!rtech!linda From: linda@rtech.rtech.com (Linda Mundy) Newsgroups: comp.software-eng Subject: Re: Software QUALITY Engineering Message-ID: <3828@rtech.rtech.com> Date: 16 Oct 89 19:46:51 GMT References: <135@quame.UUCP> <4331@ae.sei.cmu.edu> <3806@rtech.rtech.com> <4472@ae.sei.cmu.edu> Reply-To: linda@rtech.UUCP (Linda Mundy) Organization: Relational Technology Inc, Alameda CA Lines: 101 In article <4472@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <3806@rtech.rtech.com> Linda Mundy writes: > >>In article <4331@ae.sei.cmu.edu> Richard S D'Ippolito writes: >>>In article <135@quame.UUCP> Bryan A. Woodruff writes: >>> >>>>The scary thought is that the Japanese are beginning to use this philosophy >>>>to work with software (philosophy -> Deming philosophy). >>>>If all follows, they will have perfected the software development process, >>>>and produce higher quality software (error free), faster and cheaper. >>> >>>I have to disagree here -- error free does not equate to quality. The best >>>process in the world can not turn a poor design into a good one; all it can >>>do is produce faithful copies of the design. >>> >>I have some problems with your response. >> >>First, while "error free" is not the whole story of software quality, it's >>certainly a key element, not to be waved away lightly. > >Beg pardon, but I don't see why there is a problem here -- I can't see where >I said otherwise. We have a large process group here at the SEI. > I read your response as a dismissal of Bryan's concerns. While that may not have been your intent, I don't see that my reading was out of line, since you not only pointed out that error-free does not equate to quality (I agree), you also went on to downplay the role of process in software design. > >>Second, you imply that improving the software development process somehow means >>ignoring design issues, while also managing to imply that neither the Japanese >>nor Deming's system deal with those issues. I find this attitude both smug and >>naive. > >Indeed, it is naive, but it is not my attitude. My comments were that >quality means more than absence of errors and that a perfect process does >not guarantee quality (nor even absence of all errors!). Yes, I wrote >"perfect" process. > I don't believe that there can be such a thing as a "perfect" process. I do believe, however, that process can have a huge influence on quality. Of course, there are never any guarantees: that's what keeps life interesting! > >>In fact, it reinforces Mr. Woodruff's comments -- it is a scary thought >>indeed that the Japanese will proceed with improvements in the software process, >>while our own engineers sneer at "process" and believe that they can produce >>quality software while ignoring process. > >I don't find that attitude prevalent in the large-system industries, and I'd >have to conclude that anyone who sneers at processes is not an engineer. >Perhaps we'd better settle on a definition of process lest we pass in the >dark. What is it to you? Are you refering to the design process or to the >production process? Are methodologies included? > Okay. Process exists at many levels: from inception of an idea, to the more detailed design level, to the initial software construction (where, for example, CASE tools may help to track relationships between modules, etc.), to the methods of building a system, to handoff/testing/CM procedures, to shipping. Some of these have methodologies (e.g. CASE, CM tools) which may be used; some don't. > >Later, you reproduce several quotes (from Tom Peters) that separate design >and engineering, using those quotes in an attempt to prove that for >software, production process control is the same as the design process. As >a professional design engineer, I disagree. Furthermore, the products cited >do not have the same kind of post-deployment modification/enhancement >requirements. We simply can't expect to upgrade a Taurus to a Town Car. > Actually, I am not trying to "prove" anything. And while I don't believe that design and production are the same thing, I think that one can influence the other, and I think that Peters' points are valid for software too. You say, for example, that software is unique in its enhancement requirements. In the book cited, however, Peters points out that Japanese motorcycle manufacturers can introduce one new model *per month*, on average, because of flexibility in the production process. Such flexibility can only be attained with designs which allow flexibility also (like modularity). No, we can't upgrade a Taurus to a Town Car. But, can the production line be changed, thus allowing the manufacturer more flexibility in response to market demand? Actually, software customers don't upgrade models either -- we send them a new model. But in order to do this, we need to have the process to do so. Given that software is more readily and frequently modified, then isn't the payoff even greater if we can design it in a modular fashion, so that changes are more easily (and robustly) plugged in? I am not just speaking at the lowest code level, rather, look at functional units, look at build processes, look at how the software can be put together on the different target platforms; all of these things can influence *flexibility*, and they can influence design. > >Rich >-- >We use kill ratios to measure how the war is going. >We use SLOC ratios to measure how our software is coming. >(Idea from Gary Seath) rsd@sei.cmu.edu >----------------------------------------------------------------------------- -- "Who are you to tell me to question authority?" Linda Mundy {ucbvax,decvax}!mtxinu!rtech!linda