home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 5094 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.0 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!network.ucsd.edu!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!latcs1!amdahl1.lat.oz.au!baragry
  2. Newsgroups: comp.software-eng
  3. Subject: Re: Putting Engineering into Software Engineering
  4. Message-ID: <1992Dec20.234713.10503@latcs1.lat.oz.au>
  5. From: baragry@amdahl1.lat.oz.au (Jason Baragry)
  6. Date: Sun, 20 Dec 1992 23:47:13 GMT
  7. Sender: news@latcs1.lat.oz.au (news)
  8. References: <rzeplins.722559935@sfu.ca> <1992Nov28.032512.26295@mole-end.matawan.nj.us> <BzHKr6.DGr@fiu.edu>
  9. Organization: Comp Sci, La Trobe Uni, Australia
  10. Nntp-Posting-Host: amdahl1.lat.oz.au
  11. Lines: 49
  12.  
  13. In article <BzHKr6.DGr@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
  14. |> In article <1992Nov28.032512.26295@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
  15. |> >In article <rzeplins.722559935@sfu.ca>, rzeplins@fraser.sfu.ca (George Zygmunt Rzeplinski) writes:
  16. |> >> What is needed to call Software Engineering "engineering"?
  17. |> >
  18. |> >(This discussion, again?)
  19. |> >
  20. |> >Models that assist understanding, communication and recording of analysis
  21. |> >and design, and that are universally applicable and universally indispensible.
  22. |> >
  23. |> >In electrical engineering, there are circuit theory, transmission line
  24. |> >theory, and electromagnetic field theory.
  25. |> >
  26. [...]
  27. |> >
  28. |> >All of these illustrate what software is missing.
  29. |> >-- 
  30. |> 
  31. |> Gee..   what about logic, computability theory, formal languages, cohesion,
  32. |> coupling, and knowledge representation?
  33. |> 
  34. |> I'd consider any of those as universally applicable in software engineering.
  35. |> 
  36.  
  37.     I think the difference is that in other engineering disciplines these
  38. modelling / analysis techniques provide a way to analyse the properties of the
  39. components which constitute the system. In these engineering fields there is
  40. a high level of reuse and to compare components you need some way of
  41. representing the properties of these components.
  42.     Sure, algorithms in SE can be measured by speed but if I am looking
  43. at which electronic components I would want to reuse to meet my needs I can
  44. use circuit analysis, frequency & phase analysis, transmission line theory,
  45. etc to do it. How can I analytically compare to high-level SE components to
  46. see which one meets my needs the best? (assumming people may one day actually
  47. think like this!) I have to rely on written documentation of what the thing
  48. does and how the thing does it. Perhaps there isn't any way of modelling high
  49. level SE components. Perhaps the only way to compare SE modules without
  50. simply relying on documentation (which is very quantifiable) is to animate
  51. those components and compare their operating performance.
  52.  
  53. Jason.
  54.  
  55. -------------------------------------------------------------------------------
  56. Jason Baragry.            |    Amdahl Australian Intelligent 
  57. Dept Comp. Sci. & Comp. Eng.,    |        Tools Program
  58. La Trobe University.,        |    baragry@latcs1.lat.oz.au
  59. Bundoora. 3083.            |    Phone:    +61 3 479 1477
  60. Australia.            |    Fax:    +61 3 470 4915
  61. --------------------------------------------------------------------------------
  62.