home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5108 < prev    next >
Encoding:
Text File  |  1992-12-22  |  4.2 KB  |  98 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!agate!boulder!csn!news.den.mmc.com!thor!jhull
  3. From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
  4. Subject: Re: When do we inspect
  5. Message-ID: <1992Dec21.184224.21056@den.mmc.com>
  6. Sender: news@den.mmc.com (News)
  7. Nntp-Posting-Host: thor.den.mmc.com
  8. Reply-To: jhull@vulcan-gw.den.mmc.com
  9. Organization: Martin Marietta Astronautics Group
  10. References: <BzJK8L.6r0@NeoSoft.com>
  11. Date: Mon, 21 Dec 1992 18:42:24 GMT
  12. Lines: 84
  13.  
  14. In article <1992Dec18.145952.26062@saifr00.cfsat.honeywell.com> shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
  15. ms>WHEN should software be inspected? ...
  16. ms>Should software be inspected and put into
  17. ms>a configuration management system months before design is
  18. ms>complete and months before scheduled delivery ...
  19.  
  20.  
  21. In article 6r0@NeoSoft.com, 
  22. claird@NeoSoft.com (Cameron Laird) writes:
  23. cl>I assert:  source code should go into the CM system
  24. cl>from its first day.  ...  Some ob-
  25. cl>ject that checking in source is too much overhead; for
  26. cl>me, that's only a symptom that the check-in process
  27. cl>isn't yet adequate.  Coders should *want* the benefits
  28. cl>of even the most rudimentary CM:  automated regression
  29. cl>testing, static semantic analysis, validation of
  30. cl>porting considerations, ...
  31.  
  32. Au contraire.  Since we are not yet, and may never be, at a
  33. point where we all think alike and work alike, I suggest that
  34. each programmer should be allowed to do his or her own work 
  35. in whatever manner allows them to be most productive.  If
  36. that involves some form of CM, fine.  But if not, so what.
  37.  
  38. I suggest that a unit of code should enter a "Software
  39. Development Library" at the time when the individual team
  40. member has finished coding and unit testing it.  At that 
  41. time, some or all of the team should review it to ensure
  42. that it meets the team's internal quality standards (what
  43. ever they are).  The SDL should be controlled by the team
  44. lead (or his/her designated representative) and any
  45. changes to code entered into the SDL require the team lead's
  46. signature.  The team lead, in conference with the team,
  47. should decide how much or little formality and checking
  48. is required for such changes.
  49.  
  50. Suppose Team A is responsible for developing software Unit 
  51. A and Team B for Unit B and that Unit B must use some
  52. service of Unit A.  
  53.  
  54. I further suggest that there should be a "Project Software
  55. Library" controlled and managed by a Software Quality
  56. Assurance group/team/organization, and that Unit A must be
  57. entered in the PSL prior to being released for use by Team
  58. B.  The SQA team, in conference with all other development
  59. teams, should develop an appropriate set of quality checks
  60. and procedures for entering such software into the PSL and
  61. for changing/enhancing it as the project moves through the
  62. development cycle.  These checks and procedures should 
  63. include notification of all teams "registered" as users of 
  64. a given unit that the unit has been changed, notification
  65. to the developing team that an error has been found, etc
  66. and should focus on being flexible enough that they do not
  67. impede the development process.  These procedures should be
  68. designed to make things easier for developers; they are
  69. *not* intended to ensure the quality of the final product
  70. (i.e., if there is any conflict between facilitating the
  71. development process and ensuring that the final product
  72. meets spec, it should be resolved in favor of facilitating
  73. the development process).
  74.  
  75. The SQA team, in conference with all other development teams 
  76. and personnel from the corporate staff, should also develop 
  77. an appropriate set of quality checks and procedures for 
  78. verifying the function and performance of the software prior
  79. to delivery to the customer.  This set of checks and pro-
  80. cedures should be quite different from the set suggested
  81. above (i.e., if there is any conflict between facilitating 
  82. the development process and ensuring that the final product
  83. meets spec, it should be resolved in favor of ensuring the
  84. quality of the final product).
  85.  
  86.  
  87.  
  88.  
  89. -- -- -- --  --
  90.        _   _
  91.     /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
  92.    //_) -/- -/-   1544 S. Vaughn Cir  
  93. /_/ \_/ /   /      Aurora, CO 80012    303-977-1061
  94.  
  95. No matter where you go ... there you are.
  96. #include <standard.disclaimer.h>
  97.  
  98.