home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16786 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.6 KB
  1. Xref: sparky comp.lang.c:16786 comp.software-eng:4398
  2. Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!destroyer!ncar!noao!arizona!optima.UUCP
  3. From: rws@optima.UUCP (Ronald W. Schmidt)
  4. Newsgroups: comp.lang.c,comp.software-eng
  5. Subject: maintenance questions
  6. Message-ID: <26750@optima.cs.arizona.edu>
  7. Date: 19 Nov 92 09:21:15 GMT
  8. References: <1992Nov19.052343.14116@netcom.com>
  9. Sender: news@cs.arizona.edu
  10. Followup-To: comp.lang.c
  11. Lines: 46
  12.  
  13.  
  14.     My initial posting of some questions got a few answers, some
  15. agreeing, some disagreeing - both helpful.  What I was really trying
  16. to assess was the potential utility of a MYCIN type symptom based
  17. expert diagnostic system for software maintenance.  If maintenance is 
  18. carried out by the original authors of the system then a symptom based
  19. diagnostic approach will not be very helpful.  Human intelligence will
  20. be better than expert intelligence.  The utility of such an approach
  21. is clearly most useful in a situation where people whose familiarity
  22. with the system is not so great must do maintenance and where the most
  23. frequent resolution to a problem is to match symptoms against known
  24. problems and give known solutions.   I worked under such circumstances
  25. and am wondering how common they are in the software industry as a
  26. whole.  I would expect that such circumstances would be most likely
  27. at places that produced software which had a wide distribution so 
  28. that there is no chance for the original developers to handle all 
  29. questions.
  30.  
  31.     I did manage to find a book with more recent maintenance statistics
  32. than Boehm et al.  Capers Jones book on _Programming Productivity_
  33. gives some helpful statistics.  Unfortunately the impact of modern
  34. programming languages on field maintenance was only touched on
  35. and most of the answers to my questions were not directly addressed.
  36.  
  37.     For any who did not care to comment the first time, or would
  38. like to try again in the above mentioned context.  
  39.  
  40. 1) In a competitive market there is a need for short term corrective 
  41.     maintenance that is not quite like software evolution.  There
  42.     is a need for fixes that get a customer around a problem safely 
  43.     and immediately to prevent the customer from switching to another 
  44.     product.
  45.  
  46. 2) Companys hire special group of people for maintenance.
  47.  
  48. 3) In corrective maintenance creating new fixes is burdensome and undesireable
  49.     and infrequent compared to the distribution of already known
  50.     inter-release fixes.
  51.  
  52. 4) By the time the decision is made to modify software a lot of information
  53.     has been gathered by a support person attempting to avoid making
  54.     any modification.
  55.  
  56.  
  57. Thanks in Advance
  58. -Ron
  59.