home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / software / 5191 < prev    next >
Encoding:
Text File  |  1993-01-04  |  4.0 KB  |  90 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!cs.utexas.edu!torn!nott!uotcsi2!news
  3. From: bwatt@csi.uottawa.ca (Bill Watt)
  4. Subject: Debugging the process
  5. Message-ID: <1993Jan4.162006.8223@csi.uottawa.ca>
  6. Sender: news@csi.uottawa.ca
  7. Nntp-Posting-Host: csia
  8. Organization: Dept. of Computer Science, University of Ottawa
  9. Date: Mon, 4 Jan 93 16:20:06 GMT
  10. Lines: 78
  11.  
  12. Thanks for the comments on, and corrections to, my initial posting 
  13. on this subject.
  14.  
  15. "There is no short cut, because there is no end."  Korean anon.
  16.  
  17.  
  18.  
  19. 1. Smaller firms
  20. "There are approximately 10,000 firms in the [Canadian] software 
  21. industry. ... Ninety percent have less than ten employees and only 
  22. one percent have fifty or more employees." Software - Human 
  23. Resource Issues and Opportunities, Canadian government report, 
  24. March 1992. There must be as many small firms in other countries. 
  25. The future for software engineering is bright. Let's not let 
  26. capability assessment models for large organizations discourage 
  27. the existence of smaller innovative software engineering firms. 
  28. Already, Bell Canada has a capability assessment checklist 
  29. [Trillium draft 2.2] based on the SEI model, but with additional 
  30. requirements. Where is this leading? I did a plan for advancing a 
  31. firm from Bell's definition of level 3 to level 4. The fixed cost 
  32. overhead would discourage the existence of smaller firms. 
  33. "Managing the Software Process" says a capable company must assess 
  34. its subcontractors for conformance to the SEI model (Appendix A - 
  35. A Software Process Maturity Framework "Subcontracting"). On page x 
  36. of "Managing the Software Process" it says "In addition to working 
  37. with very large projects, however, we have found that the same 
  38. methods are effective for smaller groups." I'd like to believe 
  39. this.
  40.  
  41.  
  42. 2. Precise definition
  43. I may have a somewhat different perspective. My research in system 
  44. science has been modelling "system development" with a knowledge 
  45. engineering tool. A KE tool forces one to define and relate 
  46. concepts precisely. Based on my KE model of system development, 
  47. the software engineering "process" should be defined as a 
  48. combination of the design and construction "processes" (rather 
  49. than "production of quality software", "Managing the Software 
  50. Process" pg 248). Requirements analysis should be a separate 
  51. "process" from software engineering (a separate knowledge domain 
  52. in my model).  The output from analysis would be the *input* to 
  53. software engineering. With a more precise definition it should be 
  54. easier to simplify a capability assessment model for smaller 
  55. firms.
  56.  
  57. BTW, I managed the development of scientific software without 
  58. having a lot of the problems I've heard about in the industry. Our 
  59. "software process", if I may call it that, wasn't superior. I 
  60. believe the difference was the *input* - formal math specs (often 
  61. reviewed and published) from knowledgeable clients. I write this 
  62. having studied of Dr. Humphrey's discussion on pg 25 that its a 
  63. misconception that "we must begin with firm requirements".
  64.  
  65.  
  66. 3. Project/process management
  67. Using a KE tool would force clarification of the distinction 
  68. between process management and project management (chapters 6 and 
  69. 13 of "Managing the Software Process"). PM is an established 
  70. management discipline with its own body of knowledge and proven 
  71. procedures. One of those areas of knowledge, according to the 
  72. Project Management Institute, is the management of quality.
  73.  
  74.  
  75. 4. The internal process
  76. The software development process is partly external and partly 
  77. internal (mental). Its up to the participants collectively to 
  78. improve the external process. (Management is just a 
  79. specialization.) Its up to the individual, with the support of the 
  80. others, to improve the internal process. I've had good results 
  81. helping invdividuals improve their internal process by handing 
  82. back assignments to be done over again until they get it right. :-)
  83.  
  84.  
  85. "Doan' you mind what Denis say", he whispered to me, "Denis, he 
  86. quite a cutup. Sometime he run off at de mouf'."
  87.  Last line of Jas. A. Michener's "Tales of the South Pacific"
  88.  
  89.  
  90.