Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!tivoli!alan From: alan@tivoli.UUCP (Alan R. Weiss) Newsgroups: comp.software-eng Subject: Re: Software Quality Message-ID: <478@tivoli.UUCP> Date: 15 Mar 91 15:07:51 GMT References: Reply-To: alan@tivoli.UUCP (Alan R. Weiss) Distribution: comp.software-eng Organization: Tivoli Systems Inc., Austin, TX Lines: 126 In article sbang@iesd.auc.dk (Stig Bang) writes: > >Greetings all professionals: > >We are a group of engineering students from Aalborg University Center >(AUC), Denmark, who are currently working with aspects of obtaining >Software Quality. We have read both books and articles on the general >quality aspects (Pirsig; Juran; Deming; Crosby; Feigenbaum; etc.) and >some related to software quality (Glass; Vincent, Waters & Sinclair; >etc.) I commend you for studying this new engineering and business discipline. You may choose to study other researchers in this field, such as Fletcher Buckley, William Howden, Boris Beltzer, Tom Gilb, Michael Fagin, and others. Keep reading this newsgroup for net.luminaries. >We do _not_ believe in counting significant source statements and >cyclomatic code analysis, and similar stuff as primary activities for >achieving better software quality. Could you please state your case as to why you do not "believe" that these tools are useful? I don't believe that anyone advocates them as primary activities; rather, they are the moral equivalent of hammers and screwdrivers: mere tools to be used with discretion. BTW, I AM a believer in measuring cyclometric complexity; its a useful data point to guide developers/engineers in re-examining specific modules, and can help estimate test efforts. Lines of code vs. function points .... Regardless of which you prefer (please no more tedious flames on this), you need to measure defect density somehow. Any ideas from your group? > >Instead, we think that: > > a) Software Quality is primarily achieved through good > management of the development process. We have a saying here in America: "mom and apple pie." Your statement is valid; but can you define "good management of the development process?" > > b) Successful Quality Management requires motivation > and engagement of the individual and a professional > attitude towards software development. Good point. But, again, this is fairly evident. The *real* problem comes in analyzing WHY so many software project seem to go astray. Most engineers I know WANT to produce good software. Most Managers I know WANT their engineers to produce good software. So what's the *REAL* problem, folks? Can you say, "schedule?" :-) For more information, look at Barry Boehm's papers and articles. > > c) The hardest task of introducing Quality Management > in a company is the change of peoples' habits, > not the application of new tools and methodologies. True, so true. The question now shifts to, "WHY don't people want to change?" Perhaps this young science of software QA has not proven its value? Most of us know better. Unfortunately, as in any young science, new techniques (which involve both tools and methodologies) are created, promoted, and then the logic of the market takes over. Some succeed, some fail. We need to find a way to increase the velocity of the experiments, trumpet the successes, and learn from the failures. This, of course, is exactly what management expert Tom Peters calls the "try it/break it/fix it/try it" system. Notice that it is indeed a management problem. 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? Fruitful areas for your group to research!! >What do YOU think about Software Quality issues? Can anyone confirm >or dispute any of these statements? What literature would you >recommend in this area? > 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! > > ___ _ _ ______ sbang@iesd.auc.dk > / _ \ | | | | / _____\ 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 _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 "I speak only for myself, not for TIVOLI" _______________________________________________________________________