home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / pc / MS_ARCAD.ZIP / ARC5_1.CHP < prev    next >
Encoding:
Text File  |  1993-06-15  |  4.5 KB  |  118 lines
  1. %
  2. #EF
  3. #T15,1,Chapter 5     General Design Considerations     Pg. 1
  4. #HS,1,4,80,25,11,1
  5. #C4,R5
  6.                      ~W~IStructured Design And Development~Y~I
  7.  
  8. Back in the days of the brontosaurus and the saber-toothed tiger, say the
  9. 50's and 60's, producing software was a new discipline and programs tended
  10. to resemble spaghetti. After a while people much wiser than myself found
  11. that structured programs were more easily maintainable, more portable, and
  12. more reliable.
  13.  
  14. #WN
  15.                           ~W~IWhy Structured Design?~Y~I
  16.  
  17. I was in computing for several years before I realized one basic fact;
  18. computer programs ~R~Iaren't written to be read by computers~Y~I, they're written
  19. so ~R~Ihumans can read them~Y~I.
  20.  
  21. #WN
  22. Surprised? ~G~IIt's true~Y~I. There's not a single computer on the market today
  23. that can read a C program directly. Every one of them need a program to
  24. translate C to binary. We call those programs compilers.
  25.  
  26. #WN
  27. %
  28. #EF
  29. #T15,1,Chapter 5     General Design Considerations     Pg. 2
  30. #HS,1,4,80,25,11,1
  31. #C4,R5
  32. ~Y~IIf programs are meant to be read by humans, then what can we do to make
  33. them more readable? Well one answer is to use ~C~Istructured design and
  34. programming techniques~Y~I. Structured design will also help us build software
  35. that is easily integrated into a large variety of games. And that's what I
  36. like, getting the most mileage out of my efforts.  I tell my students that,
  37. in programming, ~W~I~Flaziness is a virtue~Y~I~N. The more use they can get out of a
  38. piece of code that they have written, the more successfully lazy they have
  39. been.
  40.  
  41. #WN
  42. Another reason for using these techniques is that you might want to sell
  43. your program to a software publisher for them to market. That may mean they
  44. will take over the maintenance of the program. If so, they'll be much more
  45. willing to |buy your code| if it's well organized and easily maintainable.
  46.  
  47. #WP
  48. %
  49. #EF
  50. #T15,1,Chapter 5     General Design Considerations     Pg. 3
  51. #HS,1,4,80,25,11,1
  52. #C4,R5
  53. ~Y~ISoftware has a given length of time that is its ~M~Iuseful lifespan~Y~I. The
  54. lifespan of some software is short. Most software for the CP/M operating
  55. system came and went rather quickly. Other pieces of software continue for
  56. a long time. The vi editor for Unix is about as old as I am. We call this
  57. lifespan the |software life cycle|.
  58.  
  59. #WN
  60. #C4,R11
  61. ~KDuring the life cycle of a program there are several distinct phases. First
  62. is usually analysis and design. Next comes development, then maintenance.
  63. Figure 5.1 on the next screen shows the software life cycle.~k
  64. #WP
  65. %
  66. #EF
  67. #T15,1,Chapter 5     General Design Considerations     Pg. 4
  68. #HS,1,4,80,25,11,1
  69. #C4,R5
  70.                                 ~W~IFigure 5.1~Y~I
  71.                           The Software Life Cycle
  72.  
  73.  
  74.              │            │            │            │
  75. Maintenence  │                                      ┌───────────┐
  76.              │            │            │            └───────────┘
  77.              │                                      │
  78. Testing      │            │            ┌────────────┐
  79.              │                         └────────────┘
  80.              │            │            │            │
  81. Development  │            ┌────────────┐
  82.              │            └────────────┘
  83.              │            │            │            │
  84. Design       │ ┌──────────┐
  85.              │ └──────────┘            │            │
  86.              └──────────────────────────────────────────────────
  87.                Time -->
  88.  
  89. #WP
  90. %
  91. #EF
  92. #T15,1,Chapter 5     General Design Considerations     Pg. 5
  93. #HS,1,4,80,25,11,1
  94. #C4,R5
  95. ~Y~IOf the three main phases shown in the figure above, which do you think
  96. costs the most? Most of my students usually answer that development is the
  97. most expensive, but that's not correct. It's ~R~Imaintenance~Y~I.
  98.  
  99. #WN
  100. Fixing bugs, adding new features, and other maintenance tasks are often
  101. where 75% to 85% of the money spent on a piece of software goes. In my
  102. experience, it's closer to 85% than to 75%. This means that anything we can
  103. do to bring down the cost of maintenance will save us money.
  104.  
  105. #WN
  106. At many large software companies, they've found that extra time and money
  107. spent in design and development can sometimes lead to an order of
  108. magnitude savings during maintenance. Almost without exception, the extra
  109. time in the early phases of the project is used to do structured design and
  110. development.
  111.  
  112. #WN
  113. Structured design may add a bit more overhead to a program, but it is well
  114. worth it.
  115. #WP
  116. #QT,T,arc5_1
  117. #X
  118.