home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / software / 4248 < prev    next >
Encoding:
Text File  |  1992-11-12  |  2.7 KB  |  62 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!ftpbox!motsrd!mothost!white!sapphire.rtsg.mot.com!emerald!georgerj
  3. From: georgerj@rtsg.mot.com (Richard J. George)
  4. Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
  5. Message-ID: <georgerj.721551764@emerald>
  6. Sender: news@rtsg.mot.com
  7. Nntp-Posting-Host: emerald
  8. Organization: Motorola Inc., Cellular Infrastructure Group
  9. References: <20991@plains.NoDak.edu> <9210081531.AA16269@bangalore.esf.de> <1992Oct14.233846.6292@news.arc.nasa.gov> <1992Oct19.094707.9256@netcom.com> <1992Oct20.233155.9778@news.arc.nasa.gov> <1992Oct26.195131.29756@litwin.com> <1992Oct29.191549.21368@news.arc.nasa.gov> <1992Nov9.153429.25476@litwin.com>
  10. Date: Thu, 12 Nov 1992 07:02:44 GMT
  11. Lines: 49
  12.  
  13. claird@litwin.com (Cameron Laird) writes:
  14.  
  15. >Successful software organizations of the year
  16. >2000, in my estimation, will not be those that
  17. >regard applications problems as solved by "coding
  18. >up a program"--the tradition in which most of us
  19. >grew up--or even by design, in its lower-level
  20. >senses.  They will, as one contributor recently
  21. >complained, have a "de-skilling" attitude.  They
  22. >will expect their employees to show facility at
  23. >combining standard components, at translating
  24. >high-level specifications into solutions, and at
  25. >carrying out their business within a *measured*
  26. >workplace.
  27.  
  28. I disagree with the assumption that the role of the software engineer
  29. will be de-skilled in years to come.  From looking at tools which are
  30. available now (ilogix for example), I see the skill moving further
  31. up the lifecycle.  More pride will be placed in getting a complete
  32. set of requirements, and producing a design that satisfies those 
  33. requirements.
  34.  
  35. Coding itself is (should be) cranking the handle.  It is the bricks
  36. and mortar of the architect - and how many bridge building engineers
  37. get their hands dirty?
  38.  
  39. Mr Laird talks about car manufacturing.  The car designers work very 
  40. much as they did thirty years ago - but with computers instead of drawing
  41. boards and slide rules.  Yes, they do use standard components, but so do
  42. we.  An example of that is the greenleaf libraries for comms.
  43.  
  44. What we lack is a accepted 'front end' to requirement capture and design.
  45. CASE tools have attempted to solve this, but none have all the features
  46. that we crave for.  If a front end is accepted by the industry, the
  47. library producers can produce representations of their products to included
  48. by the software engineers in their designs - similar to how hardware 
  49. engineers work with simulation packages.
  50.  
  51. This is not a magic bullet - just one more device that would help to raise
  52. the quality of software.
  53.  
  54. Regards, Richard
  55.  
  56.  
  57. >-- 
  58. >Cameron Laird        +1 713 996 8546
  59.  
  60. >claird@litwin.com
  61. >claird@Neosoft.com
  62.