| 2. | The spectrum of complexity in software has two poles or extremes, as shown in the following figure. The left side of the figure shows high complexity due to fewer but multifunction or multioutput components. The right side shows high complexity due to too many single-function or single-output components. Experience and the limited use of Taguchi Methods to date (see the Kanchana example in Chapter 17) indicates that complexity in an enterprise software application may lie somewhere between these extremes, as shown by the catenary curve between the two poles or complexity extremes. In software, complexity is proportional to the sum of the power of the number of outputs each component has. It is also proportional to some power of the number of components making up the application. Thus, at design time a trade-off must be made between these implementation alternatives. For example, in the C language, it is most convenient to program in single-output functions, which produces a huge number of small, hierarchically organized single-output modules. In C++ or Java, it is more convenient to program in small or large hierarchically organized classes, which may have multiple outputs. As an example of inherent or intrinsic complexity for these two extremes, consider a jigsaw puzzle that has only 100 pieces but no picture to guide assembly. Compare this to the external or extrinsic complexity of a jigsaw puzzle with 1,000 pieces that comes with a picture of what it will look like when assembled. Describe a possible decision or design procedure to find the "golden mean" between these extremes shown by the dip in the curve. Describe one or more systems in your experience that show type A complexity (such as IBM's SanFranciso middleware) or type B complexity (such as Microsoft COM+ middleware). Can you summarize your consideration of this issue by a single "rule of thumb" that tends to reduce complexity to a minimum for any given enterprise application? |