Software methodology in the harsh light of economics

Software methodology in the harsh light of economics K C Kang and L S Levy* Design methodologies have as their objective the provision o f a rational framework for the sequencing o f choices in producing a design. Thus the so-called waterfall model establishes a sequence o f stages--requirements, specifications, demon, coding, testing and maintenance--to guide the development process. The success o f a methodology can be measured by how well it accomplishes its intended function. A methodology is useful if it allows technical people and managers to allocate properly resources during development and makes the job o f monitoring accomplishment easier. The waterfall method has been under considerable criticism recently because it is believed to misallocate resources, owing to it having an improper model o f the software development process. A successful methodology must be founded on sound technical and economic bases. The use o f economic methods is emphasized primarily as a rational basis for choice among alternatives, not as a monetary criterion. The concerns with productivity and the recent emphasis on software reuse stress both these aspects. Software development methodologies are analysed from both the technical and economic perspectives. Quantitative models consider the various organizational approaches to software development as well. In one o f these models a quantitative analysis of the conditions needed for software reuse is provided, as well as an explanation o f why it has generally not achieved the projected levels o f success. Other models analyse the role o f experts in the software development process, and the division o f labour. software economics, design methodologies, object-oriented pro9rammm9, expert systems, metaprogrammin9, software reuse METHODOLOGY Design methodologies have as their objective the provision of a rational framework for the sequencing of choices in producing a design. Thus the so-called waterfall model establishes a sequence of stages--requirements, specifications, design, coding, testing and maintenance--to guide the development process. The success of a methodology can be measured by how well it accomplishes its intended function. A methodology is useful if it allows technical people and managers to allocate resources properly during development and makes the job of monitoring accomplishment easier. The waterfall method has been under considerable criticism recently because it is believed to misallocate resources, Software Engineering Institute, Carnegie-Mellon University, Pittsburgh,PA 15213,USA. *AT&T Bell Laboratories, Warren, NJ 07060, USA vol 31 no 5 june 1989 owing to it having an improper model of the software development process 1-3. A successful methodology must be founded on sound technical and economic bases. The use of economic methods is emphasized primarily as a rational basis for choice among alternatives, not as a monetary criterion. The concerns with productivity and the recent emphasis on software reuse stress both these aspects. A design methodology should be adapted to the objectives of the design process. As the cost of design can depend strongly on the amount of optimization that is performed, it is necessary to know the cost trade-offs of optimizations. What is the value of increased speed or decreased memory? How many products are likely to be affected by the design? For example, a design process that invests heavily in components intended for reuse needs to know the intended form of reuse and how the investment in reuse can be recovered. In this paper software development methodologies are analysed from both the technical and economic perspectives. The quantitative models consider the various organizational approaches to software development as well. In one of these models a quantitative analysis of the conditions needed for software reuse is provided, as well as an explanation of why it has generally not achieved the projected levels of success. Other models analyse the role of experts in the software development process and the division of labour. In this paper it cannot be expected to anticipate all the factors that must be considered or the potential relations between these factors. The models used are intentionally chosen as 'back of the envelope' models intended to provide some intuitive feeling for how the economic models might be refined into a more quantitative study of methodology. OBJECT-ORIENTED PROGRAMMING W h a t is object-oriented programming? A short summary Object-oriented programming ( O O P ) 4'5 is a program development methodology of which the constituent techniques are: • program decomposition functions) based 0950-5849/89/050239-12 $03.00 © 1989 Butterworth & Co (Publishers) Ltd on objects (not 239 • program design based on data abstraction and encapsulation • program implementation based on information hiding An object-oriented methodology decomposes an application based on the objects that the application manipulates. For example, for an inventory system, objects might be inventory items, customers, files, catalogues, orders, etc. The identified objects are categorized and abstracted to object types, and then attributes that apply to each object type (class) are identified. This process decomposes application systems into modules based on categories of similar objects (object types). After objects (object types) are identified, the operations that may be performed on objects are defined for each object type. For example, operations such as 'find part', 'add part', 'delete part', and 'update part information' may be defined for catalogues (i.e., for the object type catalogue). The defined operations establish interfaces between objects, i.e., establish relationships between modules. In implementing each module, implementation details that need not be known to the users are made inaccessible (information hiding). Object-oriented languages provide a mechanism for separating public parts (interfaces) from private parts (hidden implementation details). Although any programming languages may be used with an object-oriented programming methodology, object-oriented languages (OOLs) provide language primitives for 'conveniently' applying and enforcing the methodology. Technical advantages of O O P and O O L S O O P and OOLs impact programming in at least three ways. First, programming is done based on the application domain-oriented concepts, and mapping problems to solutions becomes easier than with other languages. Second, object-oriented development promotes the identification of the generic concepts within an application domain, and modules can be defined more consistently among applications with this approach than with function-oriented approaches. Third, primitives for defining classes and subclass facilitate the development of general, therefore reusable, modules. The features of the object-oriented languages that promote reusable software development are: • data abstraction through high-level definitions of a data structure and the operations on the data structure • information hiding through separation of public data from private data, which is defined for implementation and can be hidden from users • generic program development through inheritance of the definitions of existing objects in defining new objects • loose coupling of modular components (objects) through message passing or late binding 240 In addition to enforcing software engineering principles 6, including abstraction, modularity, information hiding, and locality, OOP and OOLs provide other benefits over traditional methodologies. They allow developers to defer functional commitments until objects are identified. What a system does (functions) is more likely to change than what the system manipulates (objects). For example, in an inventory system, the logical structure of the objects that the system manipulates or maintains, such as part inventory information, customer information, catalogue, etc., may not change over a long period, whereas new functions (e.g., new reports) may be added, or existing functions (e.g., user interface) may be changed or enhanced. With OOP, implementation of functions is deferred until objects are identified and defined. In other words, functions are implemented after a sound foundation is laid in terms of objects. Costs of O O P Start-up costs Although object-oriented methodologies and languages provide benefits over conventional methodologies and languages, it is expected that the transition cost will be high. The major cost factors are programmer training, asset reprogramming, and software tool and environment acquisition. Programmers should learn new languages and be able to solve problems from the object-oriented viewpoint (i.e., OOP), which is different from the traditional function-oriented thinking. Programmer training and initial low productivity are the major cost factors. Another major cost factor for the organizations that have been building up asset bases is that the assets may have to be reprogrammed to make them compatible with new languages and methods. Application-oriented software may be more likely to be reprogrammed than generic software (e.g., math libraries). Other start-up costs such as tool and environment acquisition might be relatively low compared with the programmer training and asset reprogramming costs. Steady state costs At the steady state, it is expected that software costs with an object-oriented methodology will be much lower than with traditional languages and methods. The asset buildup cost might be somewhat higher, but the asset maintenance cost and cost for building new applications are expected to be much lower, and the overall software cost will be lower than the cost with traditional methods and languages. Economic analysis of O O P The economic of OOP are analysed in terms of the time required to reach the break-even total cost. The assumptions here are that the productivity is higher with OOP than with function-oriented methodologies and that the information and software technology transition cost will be substantial. Under these assumptions, the aim is to analyse the time required to reach the point where the total '.frost will be the same as that without OOP. Beyond mat point, cost saving will incur. Suppose that the total software cost with OOP, Co(t ), is Co(t)=S 0+Cx I g(t) J po(t) the formula, there is 2.06 years to the break-even point. (This is the minimum value owing to the assumptions made on the productivity function.) If O O P increases productivity by 25 per cent, then it will take less than a year to reach the break-even point. EXPERT SYSTEMS What are expert systems? where • • • • SO is the start-up cost C is the cost factor per unit of effort g(t) is the amount of effort required at time t po(t) is the productivity with O O P at time t The productivity function po(t) asymptotically increases to P0. The cost function without OOP, C(t), is g(t) C(t) = C × I J P where P is the productivity without OOP. Here, the productivity is defined as the amount of work accomplished in a unit of time. From the above equations, the interest is in finding the time t where Co(t) is C(t). To simplify the problem, assume further that the time required for the productivity function po(t) to reach Po is negligible, and the amount of work, g(t), is constant at g. Then this gives So+Cx g×t_Cx Po gxt P and So t= Cxg (; - or t---- So X C x gP(1 + x ) where x is the ratio of productivity improvement over the current one. In an hypothetical example, suppose that: • SOis $500 000 • C, the yearly operational cost, is $2 000 000 • g, the amount of code that should be produced, is 200 000 lines per year • P, the current productivity level, is 150 000 lines per year Suppose further that O O P increases the current productivity by 10 per cent. Then, by substituting the values to vol 31 no 5 june 1989 Expert systems, also known as knowledge-based systems or rule-based systems, are systems that employ heuristic reasoning to solve problems that are typically associated with the judgment and experience of a human expert. Developments over the last two decades have shown that it is often possible to encapsulate much of the human expertise in some limited domains in sets of patternaction rules. The rationale for this approach is the observation that a considerable amount of applied expertise uses the so-called shallow reasoning that can be captured in if-then rules. Many successful expert systems have been built, and commercial exploitation of this technology is very active. The architecture of a typical rule-based expert system consists of: • a database of facts • a set of rules (the knowledge base) • a control mechanism (the inference engine) Each rule is of the form IF antecedent T H E N consequent where the antecedent and consequent can be complex logical expressions (with possible side effects). The inference engine then attempts to construct a reasoning chain from the rules in the knowledge base, to determine the additional facts that are entailed by the facts in the database. In the construction of an expert system, typically the inference engine is an off-the-self component. The factual database usually exists, although its machine representation may have to be modified. The main effort in constructing the expert system is the so-called knowledge engineering to ascertain from the experts a set of rules that will allow an inference engine to simulate the reasoning of a human expert. Expert system development methodologies Methodologies for the development of expert systems generally emphasize rapid prototyping as one of the initial phases of system development. This is typically preceded by some start-up phases and followed by an extended knowledge acquisition phase 7. The rapid prototyping is essential because experience has shown that experts are often unaware of or unable to articulate the reasoning processes by which they arrive at their conclusions. What has happened typically is that through years of experience the expert has internalized a set of patterns 241 that they are able to recognize and on the basis of which they can rapidly reach conclusions without the need for always reasoning from first principles. Descriptions of methodologies for expert systems, like most other methodologies, assume a linear sequence of steps, with completion of each step before the next step is initiated, although they often allow recycling of some of the steps. A typical sequence of stages is described by Bird: • Identification stage. Identify the domain experts. Identify the type and scope of problems being solved. Define the expert system goals. • Conceptualizaton stage. Decide on the concepts and relations needed. Problem-solving strategies, subtasks, and constraints. Output of this stage is a paper knowledge base. • Formalization stage. Map the major concepts, relations, subproblems, information flow, and problem-solving ideas into a formal knowledge representation framework. • Implementation stage. Building a prototype. • Testing stage. Knowledge enhancement. Ideally, a methodology should be described as a process in which a set of activities is arranged analogous to a project planning graph. In such a representation, each activity should be described as a function of those activities on which it depends as well as some autonomous variables. To the extent that the description can be quantified--and validated--it can be optimized. Simple sequential cascade model If the sequential model is reconsidered, suppose that it consists of a sequence of two activities. If each activity has a time constant, t, to reach an adequate level of completion, the total time to complete the composite activity would be 2 x t. Clearly, this time can often be reduced by starting the second activity before the first activity has completed. The overlap of the phases can benefit from the fact that the value of the information in a partially completed activity generally exceeds the cost of delaying that information until the activity completes. Using a simple linear model, the progress of an activity can be approximated by the linear differential equation dy z x dt + y = f ( t ) where ~ is the time constant of the activity, y is the output (progress) function of the activity, and f(t) is the driving function (e.g., requirements specifications as input to the design activity). If the driving function is a constant, applied at time t --- 0, the response will be 1 - e-t/~. If it is assumed that there are two activities, for example, specification and design, that the first must be 95% complete before the second starts, and that each activity has the same time constant, the composite progress will be (1 - e-t/') 2. 242 Table 1. Progress as a functionof k = tit Time constant k Use preliminary results of first activity Wait for completion of first activity 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 5.50 0.09 0.26 0.44 0.59 0.71 0.80 0.86 0.91 0.94 0.96 0.97 0.05 0.15 0.28 0.40 0.51 0.60 0.68 0.75 0.80 0.84 0.88 On the other hand, if the second activity starts using the initial results of the first activity immediately, then the t composite response will be 1 - e -t/* - - x e -t/'. r Table 1 compares the progress of the composite activity under these two different assumptions. As can be seen from Table 1, under the assumptions of the model it takes about 50 ~o longer to reach the same level of completion in a composite task if a clean handover between phases is required. Refinement of simple cascade model The actual situation is more complicated than this simple linear cascade model suggests in at least two ways: • The preliminary information available to the second activity may be incorrect, and so the second activity will have wasted some effort that it need not have done had it waited until the first activity was completed. • The second activity may also be able to provide some feedback to the first activity. As system-building activities are often evolutionary, approaching asymptotically to some hypothetical requirement, the effect of this feedback might act to reduce the time constants for the development cycle to stabilize. Stopping conditions Expert system developments generally have no completion specification. The knowledge engineering is an activity that proceeds to raise the competence of the expert system asymptotically. If it is assumed that for constant effort expanded the incremental benefit of the system increases by smaller amounts, the cost per unit knowledge is monotonically increasing. This is a classic example of diminishing returns to scale. Here, again, an economic analysis can be used to determine when the knowledge engineering should stop. It is assumed that the knowledge content of the expert system, I, is a monotonic function of the effort, w, invested in the knowledge augmentation testing phase. Further, that the utility, U, of the information is a monotonic function of the knowledge, but that the value information and software technology of incremental knowledge decreases. For example, assume that I = 1 - e -w/w, where W is the 'effort constant' required to acquire 63 9/0 of all the knowledge that U can potentially be acquired, and that ~- = 1 - (1 - 1)2, where k is the value of a complete system. Then the utility, U, as a function of the knowledge acquisition effort is described by the equation U = k x (1 - e -2 xw/w) Ideally, the knowledge acquisition activity should cease when the marginal utility equals the marginal effort to acquire the information, that is, when dU dw - 2 x k W - - x e -2×row = 1 Solving for w w=~xln Table 2, with W = 1 and k = 10, shows how the system utility increases asymptotically with cumulative investment and how the knowledge acquired exhibits diminishing returns. Note that in this case, where the value of a system with 'complete knowledge' is 10 times the cost of building in 63 9/0 of the knowledge, the optimum amount of knowledge for the system is 80 % (where the marginal utility over marginal cost becomes less than 1 in Table 2). METAPROGRAMMING Metaprogramming is a method of programming at a higher level of abstraction and developing a translator to produce the nominal source code. In metaprogramming the programmer's effort is focused on three objectives: • Development of a high-level notation to capture the abstractions of the application domain. • Development of the application program in that higher-level notation. Table 2. Effect of cumulative cost on knowledge fraction, system utility, and marginal utility over marginal cost Cumulative cost (W) Knowledge fraction (l) System utility (U) Marginal utility over marginal cost 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 0.00 0.18 0.33 0.45 0.55 0.63 0.70 0.75 0.80 0.83 0.86 0.00 3.30 5.51 6.99 7.98 8.65 9.09 9.39 9.59 9.73 9.82 20.00 13.41 8.99 6.02 4.04 2.71 1.81 1.22 0.82 0.55 0.37 vol 31 no 5 june 1989 • Construction of generators to produce the code by translating the notation into source code. By allowing the programmer to create notations free of the syntactic and semantic constraints of a given source language, metaprogramming allows the programmer to combine a variety of notations, each of which may capture the abstractions relevant to some aspect of the application. The difficulties of representing the application domain algorithms and data within the source language are supplanted with the problem of translating application-oriented notations into a source language. Paraphrasing this, it can be said that the programming problem has been moved to the meta level: hence the term ' metaprogramming'. As the notations created in metaprogramming are suited to the application domain, the process of describing an application problem in these notations is simpler and less error-prone. Also, the encoding of the application into this notation can often be performed by specialists in the application who need not be professional programmers. The software experts can then concentrate on the problems of knowledge engineering at which they are most proficient: creating notations and translators. Thus much of the effort in metaprogramming is on building the tools to support the abstractions and notations that are developed in the process. Much of the effort in maintenance is devoted to modifying the details of an application without necessarily affecting the underlying abstractions. In those cases, the whole support structure built up in metaprogramming can be retained without change and only the toplevel application description need be modified. The concept of abstract data types and the related concept of information hiding is also intended to provide a high-level notation for program development. These concepts can be included in a metaprogramming method as their approach is somewhat orthogonal to metaprogramming. Enforcement of information hiding is a decision that is best left to a development organization and not imposed by the constraints of a programming language or environment. As an example, in c + + the developer typically can inspect the class declarations that are contained in include files. Decisions on whether a variable should be private--and inaccessible--or public--and accessible--could be made even if there was no enforcement in the language processor. (A correct c + + program cannot be made incorrect by making all private components private.) Application generators When metaprogramming s is used as a program development method, it models program development as a production process and combines software technology and managerial economics to optimize the process. In metaprogramming a high-level description of a part of an application is described in some conceptual model and the programs to realise that model are produced by program generation techniques that have evolved in compiler technology. 243 The role of conceptual models is to isolate detail and allow the programming of an application to proceed concurrently with the definition of the details. First, the details are likely to change in many applications, and a system can be stable only if it is insensitive to those perturbations. Second, the details are of interest to users of the system, but not to many programmers. The model provides a language that is concise and precise for the communication between systems analysts and programmers. There are several features of metaprogramming that are important. First, it seems unlikely that any single conceptual model can adequately capture the diverse aspects of a large application. Therefore, the assembly of a number of program components into one large program is an important technology that must be developed. Second, the rationale for metaprogramming is that it provides economies of scale in programming. While this is true for large parts of many applications, it is not necessarily true for all parts of all applications. So the economics of metaprogramming becomes an important part of the software engineering. The method starts with a rapid prototyping phase in which selected representative parts of the application are prototyped, followed by a 'tooling-up' phase, during which the metaprogramming occurs. The final phase is the production of the application programs using the software tools and techniques of the metaprogramming phase. Only the requirements needed to construct a prototype are fixed initially. The prototype has the architecture of the final system in terms of the database structure and top-level program control structure. This prototype is Brooks' throwaway system 9. Once the prototype is completed and the form of the final system is fixed, a set of tools (program generators) are built. These program generators allow the real system to be built directly from specifications that serve as input to the generators. System modification is performed by changing the input to the generators. The initial phase of the method is analogous to a feasibility study. In this phase the form of the solution is determined (its architecture) and the components needed to implement that solution are identified. During this phase the abstract form of the program is determined. (For example, a communications protocol or a lexical analyser may be modelled as a finite-state machine.) If there is concurrency in the program, the forms of communication and synchronization are established. Also, the types of input/output and database routines are fixed. • The method is not restricted to a single style of programming or a single abstract model of computation. • The initial phase will include some exploratory programming, or rapid prototyping, to establish feasibility and explore alternative models. • The use of a metaprogramming method makes it necessary to choose computational models. The tooling-up phase begins once the form of the product 244 has been determined and the software needed to produce it has been identified. If it has been determined during the initial phase that the abstract model of the software is a finite-state machine, then during the tooling-up phase a set of programs that will produce the final code from a compact finite-state specification will be developed. Once these tools have been developed and tested, it is possible to modify the details of the specification, as long as the modifications stay within the bounds of the model. For example, in the finite-state machine model, the code generator may have a limit on the number of allowable states or inputs, and the specification will only be variable within those limits. The production phase should resemble an automated assembly line. Ideally, the set of tools developed during the tooling-up phase should now be able to start with a specification file and, using that specification as the input, produce and test the deliverable software product. In the economic analysis, the decision not to automate fully the production of the software product is explained. Intuitively, the 20/80 rule seems to apply: it takes about 20 ~o of the effort to automate the generation of 80Y/o of the code, and that is the part that is worth while to do. As is usually the case with most computational models, there are aspects of the application that are not described most efficiently with the computational model. In general, the decision as to what parts of the application should be generated automatically is an economic one (see the section 'Economic justification') as the marginal returns from automation decrease as the percentage of automated code increases. This effect arises from the increasing difficulty of automating the last parts of the application. The specification file should be readable by the people responsible for the functions of the software. If the deliverable software can be generated and regression tested directly from the specifications, this will allow changes to the specification to be retrofitted to the software and will facilitate maintenance and upgrading of the product. In particular, it is highly desirable that there should be only one primary description of the function of the software and that it should be possible to guarantee that the software matches its specification. Why metaprogrammingworks There are several reasons why metaprogramming works: • It makes a program changeable within the limits of the code generator. New versions of a program can be expected to be as robust as the initial releases because no 'patches' are made to the code. It is always recompiled from the specifications. • It provides the programmer with leverage by increasing the ratio of the size of delivered program to the size of the primary program description. • It forces the programmer to think about the structure of the program and the process of software creation and thus focuses attention on productivity and quality. information and software technology • Programming at the meta-level can better use the skills of trained computer scientists as the development of the code generators is similar to the construction of other program translators. Limits of method Ideally, the method should produce a software machine whose input is a high-level specification and whose output is an optimized, tested, and documented deliverable product. This objective is probably not realisable in the current state-of-the-art. Documentation is one of the limiting factors as a specification acceptable to a program is probably unacceptable to human readers and would require post-editing. Metaprogramming depends on the choice of a suitable computational model for programming the application, the choice of an appropriate notation for expressing the computation, and the development of a code generator that can translate the notation into executable code. Applications generally cannot be represented in a single computational model and notation because the expressive power of a notation is usually limited to a part of an application. A rough estimate is that 10-15% of an application that can be metaprogrammed will have to be handled in this way. In practice, the method often falls short of even the attainable limit because, as noted above, complete automation of the software production process may not be the most economical solution. In the next section the economics of the metaprogramming method is discussed. Economic justification There are a number of criteria that may be used to evaluate quantitatively a software method. The criterion that is chosen here is to minimize the firm's software development costs over the ensemble of anticipated changes and enhancements during the lifetime of the program. The conjecture is that minimizing development costs over all anticipated changes and enhancements will reduce testing, maintenance, and other costs. Marginal cost = marginal revenue A basic principle of managerial economics is that a given activity should be continued so long as the benefit to be derived from the last unit of activity exceeds the cost of that unit of activity 1°'11. These incremental units are referred to as the marginal units. For example, a producer should continue to produce additional units of a given item so long as each additional item being produced is profitable; in other words, the marginal revenue produced from selling one additional unit exceeds the marginal cost of producing that additional unit. Using this principle, it is possible to determine the production quantity of an item by finding the production quantity where the marginal cost equals the marginal revenue. The principle of equating marginal cost and marginal revenue can be directly applied to the problem of producing software as follows. During the tooling-up phase the vol 31 no 5 june 1989 costs of producing software tools that are not deliverable software products are being incurred. By extending the tooling-up phase it would be possible to reduce the cost of the production phase in which the deliverable product itself is constructed, as tools could be produced that would further increase the productivity of programmers. How is it known when to stop the tooling up? By equating marginal cost and marginal revenue. So long as an additional month of software tool development is expected to give a gain in productivity whose value exceeds the cost of that incremental development, that additional month of tool development should be spent. Analytic model Simplified analytic models of productivity can also be used to get a qualitative estimate of the effects of investing in software productivity*. Suppose that a fixed amount of resources, n, is available to produce a program, O. Of these n resources, m may be used initially to enhance productivity, to increase productivity from f(O) to f(m). The product output, O, is then given by 0 = ( n - m) x f(m) so O is maximized by choosing m n f(m) n x f'(m) This analytical model can be solved for simple cases like linear or exponential growth of productivity. If it is assumed that f(m) = f(O) x e '×m then O is maximized by choosing re=r/m- 1 r where r has the dimensions of staff-years- 1 and 1/r is the number of staff-years to double productivity on the project divided by the natural logarithm of 2. So in the case of an exponential model almost all the time should be spent on productivity enhancement, except for the interval associated with the term 1/r when the actual software product is generated. SOFTWARE REUSE Introduction Reuse is a generic term that applies to any software design method that uses something from a previous design. A software reuse methodology must, therefore, deal with many design issues. Standish 12 presents a good * The model developed in chapters 7 8 of Levy a includes other factors such as development time and risk. 245 discussion of these issues. Software reuse can be a significant factor in increasing the productivity of software development organizations. Essential elements for achieving a high-level software reuse are reusable program components of high quality, knowledge of these components, and incentives for their production and reuse. Both the technical and economic aspects must be addressed to achieve a high degree of reuse. One of the problems reusers often find is that most modules are not engineered for reuse because: • they do not solve generic problems • they are difficult to understand and too expensive to modify • they are poorly documented Why, then, has software not been built for reuse? The authors have found at least two reasons: • Developing software for reuse is technically more difficult and costs more than otherwise. • Developers and project managers are not motivated to invest for others. To solve these problems and achieve a high level of reuse both issues must be addressed. To address the first item, reusable module development techniques must be evolved that will be economical and easier to use. To motivate more investment a reuse-supporting mechanism (infrastructure) is needed that will benefit both producers and users. In the following section, economics of reuse is studied for the free pricing and marketing situation (infrastructure). Economics Where developers cannot profit from producing reusable software, there is no incentive for them to add this value to their products. Even in the case where all development groups would be better off if each group invested in reuse, any group that does a minimax analysis of its trade-off would conclude that it was better not to invest in reuse. Consider the case of two such groups, A and B. A will reason that whether B decides to invest in reuse or not to invest in reuse, he, A, would be better offby not investing. This situation is depicted in the cost matrix in Table 3. This matrix shows costs to A and B for various reuse investment decisions where they both need modules 'a' and 'b'. The upper and lower formulas in each matrix Table 3. Cost matrix with groups A and B A does not invest in reuse A invests in reuse 246 B does not invest in reuse B invests in reuse Ca + Cb Ca + Cb Cb + K x Ca C0 Ca Co + K × Cb K x Ca K x C0 Table 4. Cost matrix for groups A and B with user of software paying X A does not invest in reuse A invests in reuse B does not invest in reuse B invests in reuse Ca + Cb Ca + Cb Co + X C a + K x Cb - X Cb + K x Ca- X Cb + X K x Co K x Cb element are costs to A and B, respectively. If the reusable module development costs more (K > 1), A and B will not produce reusable modules. But if K < 2, the organization would benefit if they did. Suppose, however, that a user of software pays X, then the cost matrix becomes that shown in Table 4. With pricing, trading becomes beneficial (to producers, consumers, and the organization where the producers and consumers belong) as long as Ca + Ca > K x Ca, that is, K < 2. In other words, trading will occur by local optimization if a price X can be charged for the reusable software. The preceding analysis is a special case of the well known phenomenon that individually optimum decisions can lead to collectively inferior solutions and is often described as the prisoners' dilemma 13. Dynamics of reuse Reusable software evolves in ways that resemble the development of standards. This is not surprising as a widely reused software package often becomes a d e f a c t o standard. The difference is that a standard is the product of a well established process of achieving a consensus, whereas a reusable software component may be the product of a single individual or organization. Once a reusable software item achieves the status of a d e f a c t o standard, however, standards organizations will become active to formalize the process. An example of such an activity is the current standards committee that is defining a Unix system standard. Entrepreneurs looking to develop new software products will seek to maximize their profits by choosing products that have the largest demand. As demand is inversely proportional to price, this suggests that those products that have small ratios of development cost to number of buyers will be prime candidates for software development and reuse. Demand will also increase with the ratio of performance to price. As price generally varies directly with performance, the ratio of performance to price may vary directly or inversely with price, but the dominant effect will probably be the ratio cost/ user and generic software with a large user base will be the first to become reusable and standard. Software that is specific to classes of applications or specialized (what has been called functional software) will only come later. information and software technology INFRASTRUCTURE Introduction The characteristics of environments where a high level of software reuse has been achieved can be summarized as the following: • The applications are in a narrow and well defined domain. • The development organization is relatively small and located in one geographical location. • The development organization has an extensive training program that emphasizes programming conventions geared to reuse. Often, organizations do not have such a reuse environment. There may be many development groups within an organization who are working autonomously at different geographical locations. Each development group is busy meeting milestones and delivering products on time and, usually, does not spend extra resources making software reusable for others. To share software among autonomous, geographically dispersed development groups, an infrastructure that supports the flow of software and related information should be established. (Our society has a monetary infrastructure that supports the exchange of goods and services.) In the following section, a number of infrastructure configurations are introduced and the economic implications of each configuration are analysed. Use of experts Structure Productivity can be increased by reusing experts (specialists). By having developers specialized in particular areas and reusing the experts (their products, application domain knowledge, and development experience) across projects, it is most likely that they will reuse in one project what they have produced in other projects, achieving high productivity and producing quality products. In addition, project organizations save by not having to train many people for the same skill and minimize potential problems that might be caused by inexperienced developers (non-experts). To be able to reuse experts, the following should be done: • Identify the areas of expertise and classify developers accordingly. • Establish an infrastructure that supports expert reuse. Two ways to establish such an infrastructure are as follows. Establish task forces Under this approach, developers are grouped logically according to their expertise. Normally, developers work on projects in their own organizations. But, on request, they are lent to other organizations to give consultations on the matters in their areas of expertise. vol 31 no 5 june 1989 Task forces can be implemented without organizational changes but require strong commitments from managements to be successful. An organization as a whole must have a cooperative attitude for task forces to succeed. Such cooperation is difficult to achieve when each development organization has its own budget and is operated independent of the others. Also, developing a consensus within an organization is time-consuming. One way to overcome this budgetary resistance is to charge for the services of experts. Organizations who provide service would be compensated--and possibly benefit from the use of their experts--while organizations who receive service would have incentives to minimize any unnecessary demands on experts. Use a matrix organization Under this approach, a company has two managerial structures: one for personnel management and another for project management. Each developer belongs to a personnel management organization based on the developer's expertise but works for the projects organizations that need that expertise. This is an ideal infrastructure for developing expertise and reusing it across projects. Each personnel organization develops state-of-the-art techniques in a specific area, develops products, including reusable modules, for the techniques, and supports project organizations by providing expertise and products. Economics The relative value of an expert can be quantified by comparing the development costs by an expert and a non-expert developing the same product. Suppose that a target system consists of N lines of code. The development costs by an expert, De, and by a non-expert, D,, can be expressed respectively as De=Ce x +K x N x Ee and D.=C. x + K x N x E. where • • • • C is the yearly salary P is the number of lines produced yearly E is the error rate K is the cost for fixing an error The subscripts e and n are used to associate each value with expert and non-expert, respectively. It has been assumed that the maintenance is done in a different organization, so that its cost does not have any subscript. In other words, the cost of fixing an expert's error is assumed to be the same as the cost of fixing a nonexpert's error. 247 An expert will be considered valuable as long as D e < D., that is Ce < Cn x ...}- K x Pe X (E, - Ee) For example, suppose that: • The average salary of a non-expert is $30 000 per year. • An expert and non-expert produce 10K and 2K lines of code, respectively. • An expert and non-expert make an error per 5K and 1K lines of code, respectively. • The cost of fixing an error is $1000. Substituting these figures into the above formula yields Ce < $158 000 The above figure defines the value of expert relative to the non-expert based on their skill level and the nonexpert's salary. As long as the expert's salary is under the limit, it is economic to use the expert instead of the nonexpert. Another way to assess the value of experts is to C De consider the ratio of ~ . Let p denote the ratio o f - . P Then a central support staff organization. This support staff studies the organization's business plan, identifies future needs of modules, and develops modules accordingly. The organization also monitors development activities, collects modules from developers, and makes them reusable for other organizations. Along with the modules, the support staff aids users by establishing a delivery system for the modules, correcting errors, enhancing features, cataloguing user experiences, and offering training courses. One of the advantages of such a central support staff is that reusable module planning becomes a part of business strategy and it is easier to target the support of the business plan. Operating a central support staff should be easier than expert reuse in organizations where developers are located over widely dispersed geographical locations. Economics The creation of a central support staff can be economically justified as long as its operational cost is less than the total development cost that would be entailed if users had to develop the modules independently. The economic justification may be expressed by the following formula operational cost < ~ ( N i x Ci) De D. Pe + K x E e p. + K × E. where or KxE I + - D~ = Pe X Pe D. p. e 1 + K -x E , P. • N~ is the number of users of module i • C i is the cost of developing module i without reuse considerations Detailed economic analysis of a central support organization may be found in Levy 8. Problems KxE The factor - is the ratio of maintenance cost to P initial cost and is typically less than 1. Thus, to a first approximation, development cost may be prorated by lines of c o d e - - a n expert who produces five times as much code is worth five times the price of the non-expert. Problems One problem with a central support staff is that return on investment takes a relatively long time. The support staff needs time to study the business plan, build expertise in the necessary areas, and develop reusable modules. Trade relationship between producers and consumers Structure One problem is that this approach may not be economic in an organization where developers are located over a wide range of geographical locations because of the extra cost of relocating experts. Another problem is that not many people want to do the same thing over a long period. The later problem may be overcome, however, by rewarding the experts for their services. The last infrastructure studied here is a trade relationship among developers. Under this configuration, modules are treated as commodities, and developers may sell or buy modules at the price determined by the free market. Central support organization The economic factors that underlie this infrastructure are as follows: Structure Another way of achieving a high level of reuse is to create 248 Economics • Developing reusable modules will cost more to the developers, but, by letting the developers sell their information and software technology products, developers may recoup the extra cost they had to invest. • By letting the developers gain profits from selling their products, developers will be more keen to their organizations needs and will try to build reusable software. • With free competition, price will be determined at the level that will benefit both developers and users. • The company will save as long as: y~ ( u , × c,) > = y~ (c, + K,) + y~ ( ( U , - 1) × L,) where o N~ is the number of users of the module i, including the developer o C~ is the cost of developing module i o K~ is the extra cost of making the module i reusable o L~ is the cost associated with learning and incorporating the module i into a system A company should promote this configuration as long as the overall savings by the users are greater than the overall extra expense by the developers. The advantage of this approach is that reuse can be stimulated in a natural way, as economics will benefit both the developers and the users. This approach will stimulate developers to become technology sensitive. Problems Some of the problems from this approach are as follows: • As this approach stimulates free competition, expertise is not centralized in an organization and a certain amount of duplication cannot be avoided. • This approach will only work if the savings from reusing and profits from selling directly benefit the user and the developer organizations. In other words, this approach may not work if each development organization has an allocated budget and savings or profits do not benefit organizations and developers directly. • To be more effective, a mechanism for advertising reusable products should be established. • A possible objection to this approach is that the developers who are in competition will not have as comprehensive a view of the market needs as a central support organization would. Consequently there will be inefficiencies because some developers may produce unneeded software. There is a possibility, however, that a central planning organization may also make incorrect judgments. In general, it seems to the authors that a free market tends to eliminate those producers who misjudge the market. The consequences of a central planning organization making an incorrect judgment would, therefore, have more serious consequences for a firm as it could put the whole firm at risk. (Another perspective on the question of a free market structure compared with a central support and development organization is developed in Levy, Chapter 98.) vol 31 no 5 june 1989 • Broadening the market may adversely affect the support of the established customer base because of the diversion of effort from direct support to more generic development. CONCLUSIONS Design consists of a sequence of choices. A design methodology is a framework for making the decisions that will allow the design process to be optimized for. criteria of interest. The thesis in this paper is that a software methodology should be analysed quantitatively to allow the tools of mathematics and economics to be brought to bear on the problems. A representative set of design methodologies has been chosen, and it has been shown--to a first approximation--how the analyses of the methodologies can be formulated as mathematical or economic models that can be studied. The authors hope that they have convinced the reader of the value of quantifying design methodologies. It is expected that further application of economic modelling techniques will lead to improved understanding of the choices that are made in developing software. The literature on software methodologies includes other methodologies such as SSADM (Structured Systems Analysis and Design Method) 14 and the Vienna Development Method 15. The authors strongly feel that the approaches presented in this paper can be and should be applied to these other methodologies, and that practitioners and researchers of software development methodologies would join in this endeavour, because methodologies without economic rationale are hard to justify or to implement in optimal ways. REFERENCES 1 Agresti, W W 'The conventional software life-cycle model: its evolution and assumptions' in Agresti, W W (ed) New paradigms for software development (IEEE Tutorial) IEEE, Los Alamitos, CA, USA (1986) 2 Balzer, R, Cheatham, T E, Jr, and Green, C 'Software technology in the 1990's: using a new paradigm' IEEE Computer Vol 16 No 11 (November 1983) pp 39-45 3 Davis, A M, Bersoff, E H and Comer, E R 'A strategy for comparing alternative software development life cycle models' IEEE Trans. Softw. Eng. Vol 14 No 10 (October 1988)pp 1453-1461 4 Meyer, B 'Reusability: the case for object oriented design' 1EEE Software Vol 4 No 2 (March 1987) pp 50-64 5 Stroustrup, B C + + Addison-Wesley, Wokingham, UK (1985) 6 Ross, D T, Goodenough, d B and Irvine, C A 'Software engineering: process, principles, and goals' IEEE Computer Vol 8 No 5 (May 1975) pp 17-27 249 7 Freiling, M, Alexander, J, Messick, S, Rehfuss, S and Shulman, S 'Starting a knowledge engineering project: a step-by-step approach' AI Magazine (Fall 1985) pp 150-164 8 Levy, L S Taming the tiger: software engineering and software economics Springer-Verlag, Berlin, FRG (1987) 9 Brooks, F P, Jr The mythical man-month AddisonWesley, Wokingham, UK (1975) 10 Truett, L J and Truett, D B Managerial economics South-Western Publishing Company (1980) 11 Gwartney, J D, Stroup, R and Clark, J R Essentials of economics Academic Press, New York, NY, USA (1982) 12 Standish, T A 'An essay on software reuse' IEEE Trans. Softw. Eng. Vol 10 No 5 (September 1984) 250 pp 494-497 13 Samuelson, P Economics McGraw Hill, Maidenhead, UK (1970) 14 Page-Jones, M The practical guide to structured systems design (2nd ed) Prentice-Hall, Englewood Cliffs, NJ, USA (1988) 15 Bjorner, D and Jones, C B (eds) The Vienna Development Method: the meta-language (Lecture Notes in Computer Science Vol 61) Springer-Verlag, Berlin, FRG (1978) BIBLIOGRAPHY Tanenbaum, A S Computer networks Prentice-Hall, Englewood Cliffs, NJ, USA (1981) information and software technology