home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5166 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.9 KB  |  68 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!udel!rochester!rocksanne!news
  3. From: kirby@xerox.com (Mike Kirby)
  4. Subject: Re: Appeal to SEI (was: Debugging the proc
  5. Message-ID: <1992Dec28.220147.11493@spectrum.xerox.com>
  6. Sender: news@spectrum.xerox.com
  7. Reply-To: kirby.roch803@xerox.com
  8. Organization: Xerox Corporation, Webster NY
  9. References: <1992Dec28.193911.20735@asl.dl.nec.com>
  10. Date: Mon, 28 Dec 1992 22:01:47 GMT
  11. Lines: 55
  12.  
  13. In article 20735@asl.dl.nec.com, terry@asl.dl.nec.com writes:
  14. >Hi folks,
  15. >
  16. >In article <1992Dec28.113148.15707@sei.cmu.edu> mcp@sei.cmu.edu
  17. >(Mark Paulk) writes:
  18. >
  19. >> What we intend the CMM to say is that an organization has to have a good
  20. >> metrics program in place to achieve level 4...  We do not say that an
  21. >> organization cannot, or should not, have metrics in place much earlier...
  22. >> The belief that the SEI requires that "you have to be level 4 to do
  23. >> measurement" is a fairly widespread misconception that we have tried
  24. >> repeatedly to correct...
  25. >
  26. >From the perspective of a critic, I would definitely concur that the SEI
  27. >concept of process progress has always had a strong metrics flavor from
  28. >the get-go.  It shows up clearly in level 2, let alone 3 and 4.  Indeed,
  29. >one of my complaints was that it unclear what a level 2 organization as
  30. >defined in early SEI materials would DO with their metrics it was clearly
  31. >supposed to collect.
  32.  
  33. KEY KEY point.  What do you do when you collect process metrics from a level 2 
  34. organization.  This means that your metrics are management metrics, and there
  35. are no engineering metrics because you have no engineering process.  Now that
  36. we have our measurements, at some point we must decide that our process is
  37. bad based on our measurements and then change the process to bring our
  38. metrics back to a reasonable level.  However, we have no way of determining
  39. how this will affect the engineering non-process.  If we had a process,
  40. we could measure it, and we could measure the effect of management process change
  41. to ensure that it isn't causing any undo problems.  Of course this doesn't even
  42. begin to talk about what are the "right" metrics and what are the "correct"
  43. values.
  44.  
  45. It is my belief that product metrics are much more effective in non-process
  46. shops.  It is fairly easy to measure something like defects/kloc or complexity,
  47. and order additional testing or longer development time based on those numbers.
  48.  
  49.  
  50. >
  51. >
  52. >                Cheers,
  53. >                Terry Bollinger
  54. >
  55. >
  56. >+--------------------------------------------+-------------------------------+
  57. >| Terry Bollinger                            | Phone: 214-518-3538           |
  58. >| Advanced Switching Laboratory, NEC America |   Fax: 214-518-3499           |
  59. >| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: terry@asl.dl.nec.com   |
  60. >+--------------------------------------------+-------------------------------+
  61.  
  62.  
  63.  
  64. Mike Kirby
  65. Xerox Corp
  66. E-mail: kirby.roch803@xerox.com
  67.  
  68.