Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!dkuug!iesd!iesd.auc.dk!sbang From: sbang@iesd.auc.dk (Stig Bang) Newsgroups: comp.software-eng Subject: Software Quality 2.0 Message-ID: Date: 26 Mar 91 15:19:30 GMT Sender: news@iesd.auc.dk Distribution: comp.software-eng Organization: Mathematics and Computer Science, University of Aalborg Lines: 146 Greetings again all professionals: First of all, we would like to thank all of You who have responded on our initial posting on software quality (either by e-mail or through this newsgroup). We have received so many responses that we cannot reply all of them. Instead, we would like to comment some of the most significant statements we have received, and try to clarify our view of "obtaining software quality", as some of You have requested. First, we would like to apply the Pareto principle on the subject. It states that one should deal with the "vital few" before the "trivial many". E.g. the discussion on metrics; the subject should not be discarded, but we think that it is not among the issues that should be dealt with *first*. Below, some of the answers we have received have been quoted and commented. The quotes are anonymous, as we do not wish to expose people, but rather to create a debate on the issue. This posting can be regarded as a brief commented summary: -- > In the United States more so than in other nations, there is an > emphasis on quarterly earnings. How does this affect product cycles, > research cycles, and software quality? How does time-to-market > stack up against comittment-to-market? Yes, how does these things affect quality? Since we are students, we have no direct experience with this. Are they major problems? We have, however, experienced that on the project level, people are always judged by schedule and budget conformance, since it can easily be evaluated by the management. The quality of the software must be proven-in-use, which takes time. Quality is always rated 2nd (or 3rd) in the minds of the software developer, because it is appreciated in that order. -- > Motivation and engagement are natural byproducts of an environment > which produces quality products. It is not the converse. Is it? Any comments on this? If it is so, there's little hope for any progress of quality! I has to start somewhere, quality does not come from nowhere. We claim that it is a necessity that all parts of an organization (= all individuals) must adopt "the spirit" to get the thing working. You cannot produce better quality unless you have faith in what you are doing. -- > It's harder to get management to change than it is to get > everyone else to change. Agreed, our research has confirmed this statement. And this is a *huge* problem, since it is hard (if not impossible) to introduce a total quality control system without managers being involved. -- > You can always blame problems on management if others are unable to > do their work well--management should have forseen that and helped > them. But this begs the question. Most managers don't know what to > do about the problems their engineers will face. But neither do the > engineers. Software Engineering is not a modern science today--it is > at the alchemy stage; managers learn through experience that certain > circumstances are strongly correlated with failure, and others with > success. But they do not understand why this is, nor how to create or > avoid such circumstances. Managers are still looking for the > philosopher's stone that will turn software lead into gold. But it > doesn't work because that's an overly simple model of chemistry--but > there is no atomic theory for software yet that would account for > fissioning lead into gold. So people keep trying to use the crude > theories that are out there. > > If we step away from blaming management for things that no one > understands, I would claim that the underlying problems in software > are cognitive in their roots. We generally agree here, except that this statement could apply to all sciences, not just computer science. Just because mechanical engineers have Newton's laws of mechanics it does not tell them how to make e.g cars. -- > Get a firm grounding in business, and you'll understand the > mise en scene we operate in. Finance, marketing, development/engineering, > quality, manufacturing, sales, and most importantly CUSTOMERS > all interplay in a maelstrom of change. Understand it, and > you'll advance the science. Ignore business, and you're doomed > to the backwaters of academia. Learn from the lesson of > macroeconomics! So we will do! We certainly hope to be in business soon, as we all 5 graduate this summer. ------------------------------------------------------------------------ The way we identify quality is: "Quality is present when expectations are matched or exceeded by what is experienced." Note that this statement captures some of the problems of contractual work; what is expected is not always stated. This "definition" could be illustrated graphically as follows: Experienced ^ (45 degrees) | :-) / | / | / :-( | / :-) : Quality | / :-( : Not Quality |/ --------> Expected This picture allows you to experience more than than expected, which could be viewed as "gold plating". Cost effective quality then lies along the line (which should 45 degrees). This is a crude picture, of course. What is Your "definition" of quality? ------------------------------------------------------------------------- ___ _ _ ______ / _ \ | | | | / _____\ Group S10D-E2218, / / \ \ | | | | / / Aalborg University Center, / /___\ \ | | | | | | Institute for Electronic Systems, / _______ \ | | | | | | Department of Mathematics / / \ \ \ \___/ / \ \______ and Computer Science, /_/ \_\ \_____/ \______/ Fredrik Bajersvej 7, DK-9220 Aalborg Ost, Denmark. The common sense principle: Telephone: +45 98 15 85 22 Common sense is uncommon. Telex: 69790 aub dk -- Tom Gilb. Telefax: +45 98 15 81 29 -- sbang@iesd.auc.dk