home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5112 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!The-Star.honeywell.com!saifr00.cfsat.honeywell.com!shanks
  3. From: shanks@saifr00.cfsat.honeywell.com (Mark Shanks)
  4. Subject: Re: When do we inspect
  5. Message-ID: <1992Dec21.215642.5706@saifr00.cfsat.honeywell.com>
  6. Organization: Honeywell Air Transport Systems Division
  7. References: <BzJK8L.6r0@NeoSoft.com> <1992Dec21.184224.21056@den.mmc.com>
  8. Date: Mon, 21 Dec 92 21:56:42 GMT
  9. Lines: 51
  10.  
  11. In article <1992Dec21.184224.21056@den.mmc.com> jhull@vulcan-gw.den.mmc.com writes:
  12.  
  13. >In article 6r0@NeoSoft.com, 
  14. >claird@NeoSoft.com (Cameron Laird) writes:
  15. >cl> I assert:  source code should go into the CM system
  16. >cl> from its first day.  ...  Some object
  17. >cl> that checking in source is too much overhead; for
  18. >cl> me, that's only a symptom that the check-in process
  19. >cl> isn't yet adequate.  Coders should *want* the benefits
  20. >cl> of even the most rudimentary CM:  automated regression
  21. >cl> testing, static semantic analysis, validation of
  22. >cl> porting considerations, ...
  23. >
  24. >Au contraire.  Since we are not yet, and may never be, at a
  25. >point where we all think alike and work alike, I suggest that
  26. >each programmer should be allowed to do his or her own work 
  27. >in whatever manner allows them to be most productive.  If
  28. >that involves some form of CM, fine.  But if not, so what.
  29. >
  30. >I suggest that a unit of code should enter a "Software
  31. >Development Library" at the time when the individual team
  32. >member has finished coding and unit testing it
  33.  
  34. >I further suggest that there should be a "Project Software
  35. >Library" controlled and managed by a Software Quality
  36. >Assurance group/team/organization, and that Unit A must be
  37. >entered in the PSL prior to being released for use by Team
  38. >B.
  39.  
  40. I believe Cameron misunderstood me, or perhaps has a different
  41. working model for "CM" than I do. I was referring to a simple
  42. "vault" type of tool; no regression testing, no semantic analyses,
  43. no nothing but a freeze on the code and enforced procedures to
  44. check it out and make changes.
  45.  
  46. I guess Jeff's description of a "SW Development Library" is
  47. less restrictive than a typical CM system. I can understand
  48. a customer's desire for tracking changes, but IMHO, taking a
  49. "snapshot" at CDR time accomplishes that function without
  50. incurring the truly prodigious overhead entailed by some
  51. CM systems (check out package, make changes, inspect, fill
  52. out software change request (SCR) form, meet with configuration
  53. control board, edit SCR, check package back in, get change from
  54. customer, goto line 1). I'm on a program using Ada, heading a
  55. team of 10 software designers producing well over 200 Ada
  56. packages and close to 20,000 LOC. Multiply that by 30 or 40
  57. such teams and see how much time will be spent on CM alone.
  58. Why start that process any sooner than necessary?
  59.  
  60. Mark Shanks
  61. shanks@saifr00.cfsat.honeywell.com
  62.