sbang@iesd.auc.dk (Stig Bang) (03/26/91)
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
daves@hpopd.pwd.hp.com (Dave Straker) (03/28/91)
>> 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? Deming has a lot to say about this (Point #11: Eliminate targets). Targets causes inappropriate behaviour. People focus on the target, not the improvement. Quality becomes meeting the target, not satisfying the customer. >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. A classic project management model is a triangle of quality, cost and time. You can sit somewhere inside the triangle - i.e. you can't have 100% of all three. Short-term targets (as previous item) cause focus on cost and time (which is a function of cost). >> 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. Consider Maslow's hierarchy of needs. Producing quality goods feeds the top layers (esteem and self-actualisation). >> 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. Deming's 'germ theory' suggests that it is analogous to Pasteur telling doctors that they've been doing it wrong, and by not sterilising, they are killing their patients. Managers are often too busy chopping down trees to sharpen the axe. >> 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 Deming again: 85% of the problems are with the process, and are hence a management responsibility. > >So we will do! We certainly hope to be in business soon, as we all 5 >graduate this summer. Good luck -- although I suspect you won't need it. >The way we identify quality is: > > "Quality is present when expectations are matched or exceeded > by what is experienced." Excellent description. It notes that quality is what is perceived by the customer. > Experienced > ^ (45 degrees) > | :-) / > | / > | / :-( > | / :-) : Quality > | / :-( : Not Quality > |/ > --------> Expected > Have you seen the Kano model? It's one I especially like. >What is Your "definition" of quality? Personally, I go with the 'expection'. It should also include words like 'continuous': quality is a moving target. HP uses a FURPS+ model for its products: F = Functionality U = Usability R = Reliability S = Supportability P = Performance + = everything else :-) including Portability, Localisability Dave Straker Pinewood Information Systems Division (PWD not PISD) [8-{) HPDESK: David Straker/HP1600/01 Unix: daves@hpopd.pwd.hp.com
daves@hpopd.pwd.hp.com (Dave Straker) (04/16/91)
> to the problem. If a problem resides in the code coming from one person, > then how do you improve the process without taking some action with respect to > that person that includes the measured information on bug rates? What > does the team do, ignore it? What does management do? Say that they know that > the code is buggy but that no action can be taken because that action would be > using a metric to evaluate a person? How about an answer? What do you do? > Say you are in a level five organization, and want to improve the process but > you have to keep removing bugs introduced by one person. What is the action > you take? If a person is introducing more bugs, then you help him produce less, in a non-threatening manner. He probably knows, more than anyone, that he's screwing up, and is feeling pretty guilty about it anyway. So, the manager privately and carefully investigates. The guy may be having personal problems (so give him some space). He may be unskilled in areas he is working on (so train him). He may just be being careless or be trying to do to much (so slow him down and get him to check). In the end, it comes down to man-management. If there *really* is no other answer, then take him off coding. There are many other activities in software engineering. Dave Straker Pinewood Information Systems Division (PWD not PISD) [8-{) HPDESK: David Straker/HP1600/01 Unix: daves@hpopd.pwd.hp.com
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (04/25/91)
In article <36650003@hpopd.pwd.hp.com>, daves@hpopd.pwd.hp.com (Dave Straker) writes: > If a person is introducing more bugs, then you help him produce > less, in a non-threatening manner. He probably knows, more than anyone, > that he's screwing up, and is feeling pretty guilty about it anyway. > So, the manager privately and carefully investigates. The guy may > be having personal problems (so give him some space). He may be unskilled > in areas he is working on (so train him). He may just be being careless > or be trying to do to much (so slow him down and get him to check). > In the end, it comes down to man-management. If there *really* is no other > answer, then take him off coding. There are many other activities in > software engineering. You have just used metrics to evaluate a person. Justify that in the light of quotes from Humphrey about not using metrics information to evaluate a person. BTW, not trying to put you on the spot here, but this situation seems to me to be a very real problem. You are measuring a process that intimately involves real people doing real things. How are these different from time management studies that purport to help a person to define and do their job better (and maybe sometimes actually do). The process is not separate from the people doing it. GXKambic standard disclaimer