home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5120 < prev    next >
Encoding:
Text File  |  1992-12-22  |  4.8 KB  |  109 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!cs.utexas.edu!torn!nott!uotcsi2!news
  3. From: bwatt@csi.uottawa.ca (Bill Watt)
  4. Subject: Debugging the process
  5. Message-ID: <1992Dec22.164508.2582@csi.uottawa.ca>
  6. Sender: news@csi.uottawa.ca
  7. Nntp-Posting-Host: csij
  8. Organization: Dept. of Computer Science, University of Ottawa
  9. Date: Tue, 22 Dec 92 16:45:08 GMT
  10. Lines: 97
  11.  
  12.  
  13. Hypothesis: 
  14.   Software quality improvement should be done by 
  15.   inspecting products: first, to find and fix defects, and second, 
  16.   to gather data in order to identify and prevent defects.
  17.  
  18.  
  19. 1. It is not necessary to follow the SEI model to benefit from 
  20. statistical quality control in software development. Inspections 
  21. can be done on any product (specs, design, code, test cases, 
  22. documentation). One can start any time. One does not have to wait 
  23. until SEI level 5. Inspections serve two purposes: first, to find 
  24. and fix defects; second, to accumulate data on the kinds of 
  25. defects encountered and then guide management in removing the 
  26. causes of the defects. As Dr. Demming has shown, using inspections 
  27. to remove causes of defects reduces the cost of rejects, reduces 
  28. the cost of rework, and eventually reduces the cost of inspections.
  29.  
  30.  
  31. 2. Dr. Humphrey emphasizes in "Managing the Software Process" that 
  32. the SEI model is for the development of large, complex software 
  33. products. One example he uses is a product (an IBM operating 
  34. system, I believe) developed at 13 laboratories spread over 8 
  35. countries. For this kind of project the process should probably be 
  36. as complex as the SEI model. But not necessarily. One should start 
  37. with inspections and add management practices from the SEI list as 
  38. required to eliminate the causes of defects.
  39.  
  40.  
  41. 3. If software workers (are unionized and) object to inspections 
  42. because the findings may be used to substantiate terminations, an 
  43. independent auditor should moderate the inspections and provide a 
  44. periodic impersonal statistical summary of the defects to 
  45. management. These should be posted and employees encouraged to 
  46. offer suggestions on changing the process to eliminate causes of 
  47. defects. Defects arise mostly from problems in the way the work is 
  48. organized, not from the way individuals perform.
  49.  
  50.  
  51. 4. Eliminating defects is a 4-step process: first, identify the 
  52. defects; second, figure out what's causing them; third, figure out 
  53. how to stop causing them; and fourth, get people to stop causing 
  54. them. Not easy. Steps two and three can be addressed with a group 
  55. problem-solving method such as Kepner-Tregoe. (History is full of 
  56. horror stories about people using wrong solutions to problems.) 
  57. Software engineering isn't yet at the point where there are known 
  58. ways to prevent all types of defects. Inspections are used for 
  59. feedback.
  60.  
  61.  
  62. 5. After starting inspections, wait until the stats settle down 
  63. before making any management changes. Starting inspections will 
  64. tend to decrease defects without any management changes as workers 
  65. use the feedback to change their individual processing. After they 
  66. have done so take the remaining defects to management for changes 
  67. to the organization of the work. Also, as Dr. Demming points out, 
  68. if the process isn't stable you can't measure the effect of changes.
  69.  
  70.  
  71. 6. The SEI model is the process equivalent of the waterfall model. 
  72. As such it has limited application. Also, it is the wrong way 
  73. around in the sense that it leaves process improvement by 
  74. statistical quality control to the final level. The insistence 
  75. that the whole process be defined and in place in order to benefit 
  76. from statistical quality control is in error because the 
  77. individual worker (the indivisible atomic process) and and every  
  78. part of a process producing something tangible can benefit from 
  79. statistical methods.
  80.  
  81.  
  82. 7. Of the two approaches to quality, a) defined as having 
  83. desirable properties, b) defined as having no undesirable 
  84. properties (defects), the second is more promising in that it is 
  85. measurable and controlable with statistical methods.
  86.  
  87.  
  88. 8. The software development process is not the problem. The 
  89. quality of the input to the process is the greater problem. More 
  90. benefit will come from client capability assessment than from 
  91. software developer capability assessment. Software engineering 
  92. has been through this before as it was attempted to prove program 
  93. correctness. It should have been evident then that programmers 
  94. were not making the mistakes, customers and their systems analysts 
  95. were making the mistakes in not specifying requirements correctly. 
  96. One can't build systems for clients who a) don't know what they're 
  97. doing, b) can't agree among themselves on what they want, and c) 
  98. don't have any time to devote to the project.
  99.  
  100.  
  101.  
  102. Would like to hear from those studying cause and effect 
  103. relationships in software defects, and categorizing ways of 
  104. preventing different kinds of defects in different kinds of 
  105. systems.
  106.  
  107.  
  108. Wm. R. Watt
  109.