home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / software / 4241 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  3.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!news.claremont.edu!ucivax!ejw
  2. From: ejw@siam.ics.uci.edu (Jim Whitehead)
  3. Subject: Scalability criteria
  4. Nntp-Posting-Host: siam.ics.uci.edu
  5. Message-ID: <2B01E1FA.14921@ics.uci.edu>
  6. Newsgroups: comp.software-eng
  7. Reply-To: ejw@ics.uci.edu (Jim Whitehead)
  8. Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.
  9. Lines: 72
  10. Date: 12 Nov 92 04:47:54 GMT
  11.  
  12.  
  13. As a grad. student at U.C. Irvine, I am currently taking a course on
  14. software engineering.  Recently we had our midterm exam, which
  15. contained the following interesting question:
  16.  
  17. A classic criticism of many proposed software engineering techniques
  18. is that they do not scale-up to large systems.  Give at least three
  19. criteria that need to be met in order for techniques to be scalable.
  20.  
  21. Since it was a take-home exam, there was enough time to examine the
  22. literature and software engineering texts.  I was not able to find
  23. any criteria for scalability in my searches, and so I present the
  24. question to the net.
  25.  
  26. The test is done and over and graded, so have no fear you'll be
  27. an accessory to breaking UCI's academic code.
  28.  
  29. I answered the question as follows, and I welcome comment:
  30.  
  31.  
  32. Scalibility criteria:
  33.  
  34. At the most fundamental level, the scalability of a technique depends
  35. on how the complexity of the technique increases with the size of the
  36. project to which it is applied.  Low complexity implies scalability.
  37. I see three cases:
  38.  
  39. Complexity varies linearly:
  40.  
  41. complexity_of_technique := scalability_constant * project_size
  42.  
  43. a) The scalability constant is small
  44.  
  45. b) The scalability constant is large
  46.  
  47. c) Complexity varies exponentially:
  48.  
  49.    complexity_of_technique := scalability_constant * project_size ^ exponent
  50.  
  51.  
  52. I defined my three criteria to handle these cases:
  53.  
  54. 1) Desirable results for projects of all sizes and types
  55.  
  56. This criteria handles case a) above where the complexity of the technique
  57. may be small, but the technique just doesn't produce good results for
  58. large projects.  One example of this is the method of stepwise refinement.
  59. Stepwise refinement can easily be used on projects of all sizes, but it
  60. just doesn't produce good results for medium to large projects.
  61.  
  62. 2) Economical for projects of all sizes and types
  63.  
  64. This criteria handles case b) above where the complexity of the technique
  65. is very large for large projects, but still varies linearly with project
  66. size.  The typical symptom of this behavior is that the technique becomes
  67. uneconomical for most users of the technique.  An example is software
  68. code inspections.  Using published estimation metrics, software code
  69. inspections should be appx. 15-25% of the total development cost.  Only
  70. big money projects would be able to afford such a technique.
  71.  
  72. 3) Feasibility for projects of all sizes and types
  73.  
  74. This criteria handles case c) above, where the complexity increases
  75. exponentially with project size.  This behavior is demonstrated by
  76. the Petri Nets specification technique.  As the size of the project
  77. being modeled increases, the number of model elements increases
  78. exponentially.  For even medium size systems, the full Petri Nets model
  79. is huge and unmanageable.
  80.  
  81. ---------------------
  82. Jim Whitehead
  83. ejw@paris.ics.uci.edu
  84.