Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!ut-emx!tivoli!alan From: alan@tivoli.UUCP (Alan R. Weiss) Newsgroups: comp.software-eng Subject: Re: Personal growth and software engineering! Message-ID: <581@tivoli.UUCP> Date: 12 Apr 91 15:28:49 GMT References: <9233@castle.ed.ac.uk> <1991Mar25.164133.29674@unislc.uucp> <549@tivoli.UUCP> <1991Apr8.163111.3968@cbnewsm.att.com> Reply-To: alan@tivoli.UUCP (Alan R. Weiss) Organization: Tivoli Systems Inc., Austin, TX Lines: 128 In article <1991Apr8.163111.3968@cbnewsm.att.com> lfd@cbnewsm.att.com (Lee Derbenwick) writes: >In article <549@tivoli.UUCP>, alan@tivoli.UUCP (Alan R. Weiss) writes: > >> If the metrics are bogus, then fix them by including the workers >> in the process. In this case, "process" can mean calling a short >> meeting, identifying dumb metrics, and coming up with meaningful ones. > >And how are the workers to know how to measure the process? We may be >able to _reject_ certain measures as bogus, but that is much easier >than creating good measures, which is an open research area. While I believe that this *IS* an open area of research, as you say, I TRULY believe that people-who-are-doing-the-work ("workers") MUST be involved in setting their own standards. How are they to know? Management outlines the broad parameters of the problem and/or improvement goals, and then provides leadership. If you do not believe this, then you are ignoring the last 10 years of management research (In Search of Excellence, Theory Z, One Minute Management, Japanese Management, etc. ad nauseum). It is easy to start the measuring process IF you get participant buy-in, something scientists forget is crucial to success. (But hey, lots of managers forget this, too!). Once you get buy-in to the concept, you step-wise refine the metrics selected as you LEARN what makes sense. You do a GREAT disservice trying to avoid the learning process itself. Organizations and people MUST be encouraged to react quickly, make mistakes, and fix them. >Here are a couple of quality metrics I would _like_: they seem to capture >two key areas of software quality -- faults and maintainability. Both, >unfortunately, violate causality: > >1. Total number, severity, and time-to-discovery of remaining faults that > will be experienced by customers as software failures. > >2. Cost of introducing the next several enhancements that will be required > of this code. The first one should be "mom and apple pie" for all software orgs. The second one is basic risk analysis, and its good, too. >Please suggest how a "short meeting" of software developers could come up >with _feasible_ versions of these. (It is _not_ feasible to wait a year >or two for the results of measurement -- by then, you've already made >changes to your development process and probably to your staff, so the >time constant is too long to use the metrics for process improvement.) Hire me and I'll set this up for you :-) Just kidding ... I LIKE TIVOLI Systems. Look, this is deceptively easy: 1. Do your homework and find out what your current state is (the SEI calls this Self-Assessment). 2. Decide what needs to be improved, and make it quantifiable. 3. Define some *preliminary* metrics and ways to go about measuring. 4. Go around to the development managers and get their buy-in. 5. Go around to the key influencers in the organization and clue them in. 6. Have the Development Managers and QA call a joint meeting on the theme "Development Quality Program" 7. Learn to listen. 8. Explain what you're trying to do, how it adds value by saving money, schedule, and improves market share, etc. etc. Be prepared to back it up with case studies and evidence. 9. Outline the broad objectives, then turn the meeting over to THEM. 10. Listen. Guide. Brainstorm. Then set some preliminary goals. 11. At various checkpoints, review your data and analyzed information to see if its telling you what you need to know. Keep the developers/engineers psted on the data. This is not QA's game, this is a Development effort. 12. Stepwise refine. Now, its going to be VERY easy to poke lots of holes in this process, so I suggest you contact the Watts Humphrey at the Software Engineering Institute (SEI) at Carnegie-Mellon for a more formalized definition.` But frankly, I just use common sense. :-) QA SUPPORTS THE DEVELOPMENT PLAN AND THE BUSINESS PLAN. >> Clearly the absence of measurements relegates software creation to >> the arts, rather than as an engineering and/or scientific discipline. > >Yes, the _absence_ of measurements would relegate software creation >to the arts. But the fact that our measurement capabilities are >incomplete forces it to be a mix of science and art -- just as the >other branches of engineering are. Looking for the magic bullet reminds me of cancer research: prevention is a LOT better than correction. >Note that I am _not_ saying that there is no basis for measurements, >but many of the ones I've seen published seem to rest on very shaky >assumptions. E.g., cost to maintain may be statistically correlated >with some function of the cyclomatic numbers of the routines composing >a module, but a statistical correlation doesn't say anything about any >specific case. Treating it as if it does (unless the correlation is >nearly perfect) is pseudo-science, not science. Yes. > > -- Speaking strictly for myself, > -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ > -- lfd@cbnewsm.ATT.COM or !att!cbnewsm!lfd Good posting. Hope I've helped a little. _______________________________________________________________________ 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 necessarily my firm" _______________________________________________________________________