On the funding and economic evaluation of software product line practices

Software product lines Software product lines provide a means for realizing (1) reduction of development costs, (2) reduction of maintenance costs, (3) shorten time-to-market, and (4) increase the overall quality. Software product lines are defined as "a set of software-intensive ystems sharing a common, managed set offealures saticij'ing the spe4/ic needc of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. The key insight is to exploit the commonaliues between different products. These commonalities are captured by core assets. Core assets provide a certain degree of variability so that these assets can be used in different contexts. The product line scope defines which products one can derive from the core asset base, i.e. the pool of core assets. It thus specifies implicitly what variability these core assets need to provide. Core assets encompass, among others, a product line architecture, and reusable components. The product line architecture is a reference architecture applicable to all the products included in the product line scope. Each product has its own derivation of the product line architecture, designed for the specific needs of that particular product. Obviously, the products in the product line scope differ from each other also. In order to deal with variability that cannot be captured in core assets, product-specific assets need to be developed to augment the provided functionality. These product-specific assets need to be designed to fit in the software architecture of the product. The software product line processes can be categorized in three main activities, i.e. core asset development, product development, and management. Core asset development is concerned with the product line scope and with the development and evolution of the core asset base. Product development is the process of deriving products from the software product line, making use of both core assets and productspecific assets. Finally, management has to orchestrate both the aforementioned processes, including setting the roadmap for future evolution. Funding software product line activities When one institutionalizes a software reuse program, the following four cost types play a role. • C the costs that an organization makes to adopt the software product line practices • Ci, the development and maintenance costs of the core asset base • the development costs of the product-specific assets • C,,,., the costs of integrating a core asset in a product With respect to the funding model, only C. and Ce will have to be dealt with. The former is the encapsulation of all the costs related to transition the organization from a traditional approach to product development to a software product line approach to product development. The latter is the encapsulation of the costs related to the development, maintenance, and evolution of the core assets. The other two cost types, C and C,,, are both directly related to a particular product, so these costs can be accounted to the subject products. When institutionalizing a software product line approach, one has to deal with different issues. First, the initial user of a core asset needs to be compensated for the fact that he has to deal with all the childhood illnesses. Second, the business units need some incentive to adopt core assets into their product development. Third, the business units do not only need some incentive to adopt core assets, but they need some incentive to adopt the latest releases of core assets also. These two issues particularly play a role in organizations where the use of the core assets has not been proven beneficial. Finally, when the core asset development is performed solely by one business unit, this business unit forms the bottleneck with respect to development and maintenance of core assets. Therefore, other business units should be involved in the development and maintenance of these assets also. This requires an incentive also, since the development of a core asset typically requires more effort than the development of a simihar productspecific asset. The funding model proposed in this thesis is referred to as the adjustable incentive-driven funding model, further referred to as the aid modeL The aid model was derived from the fiat tax model and the reward-based model. The general idea is that all business units initially are accounted for the same amount. However, their behavior with respect to the four identified issues is taken into account also. By doing so, the required amounts per business unit can differ. Determining the funds all the business units are accounted for is done through six simple steps. The first step requires that the different types of behavior, i.e. behavior related to the aforementioned issues, are provided a certain value. For this purpose, every type of behavior makes use of a behavior constant. The higher value such a constant has, the more impact the subject issue will have on the actual amount that a business unit has to pay. The second step is concerned with quantifying the behavior of all the different business units. Each business unit has a behavior variable, i.e. a variable related to one of the four aforementioned issues. The lower value a business unit scores for these variables, the more beneficial it will be. The third step determines the score of a business unit by summing up the multiplication of all its behavior variables with the corresponding behavior constants. The fourth step then prescribes to calculate the overall score, i.e. the sum of the scores of all the individual business units. The fifth step is used to calculate the cost factor. It is obtained by dividing the projected costs with the overall score. Finally, the cost factor is multiplied by the scores of each of the individual business units to derive the funds that they will have to provide. Measuring software product line practices Institutionalizing and sustaining a software product line effort typically is a hard and bumpy road. Strong management commitment is a requirement for doing it successfully. Management has to, among other things, set goals to strive for. Maybe more importantly, the progress towards meeting these goals has to be measured. If the goals are not achieved, or progress towards doing so is stagnating, measuring properties of a software product line effort makes an organization aware that certain aspects of the software product line effort are not covered properly. With respect to the three fundamental software product line activities, the following business concerns were identified. First, the product line scope needs to be determined adequately. For instance, a too large product line strains assets beyond their ability to accommodate the required variability. Second, the future evolution of core assets needs to be accommodated through for instance documenting how this evolution can be carried through. Third, the use of core assets should be more beneficial than developing a similar product-specific asset from scratch. This obviously is necessary to justify the existence of the software product line. In addition, the use of core assets needs to be stimulated through providing proper production plans and corresponding support. The production plans prescribe how the core assets can be utilized to develop a certain product. By prescribing how this is done, the assets will be utilized in a more structured and more efficient manner. Furthermore, product developers only are concerned with developing and maintaining products as efficient and as fast as possible, as soon as possible, and with a high as possible profit margin. Finally, since management has to orchestrate the other two fundamental activities, management must be equipped with tools to provide the necessary resources, coordinate, and supervise. In order to address all the above business concerns, three levels of metrics are introduced. These metrics are categorized according to their relevance to the three typical levels of corporate strategy, i.e. operational, business-level, and corporate-leveL These strategy levels exhibit a short-term focus, a mid-term focus, and a long-term focus respectively. With respect to the operational strategies, four different metrics are proposed. The first two metrics are referred to as the absolute reuse level and the relative reuse leveL The absolute reuse level states what percentage of an asset results from existing assets. The relative reuse level states what percentage of the available and suitable assets for a given product are utilized for the development of a product. The additional reuse effort reflects how much effort is required to develop a core asset relative to the effort it requires to develop a similar product-specific asset. Additional effort is required for, among other things, incorporate variability. Integrating a core asset does not come free. It has to be tailored according to the requirements of a given product and integrated into that product. These costs, however, typically are lower than developing a product-specific asset from scratch. The integration effort reflects how much effort is required to tailor and integrate a core asset in a product context relative to the effort it requires to develop a similar product-specific asset. The second level of strategy, the business-level, comprises a cost-benefit analysis. The focus is on the costs and benefits of a particular product. For the costs, the four cost types described above can be utilized. These costs can be extracted from both the amount a business unit is required according to the institutionalized funding model and the project planning. The former provides C, and C, and the latter provides C and C,,. Two different types of benefits were identified, i.e. tangible and intangible benefits.The former can easily be calculated. The tangible benefits comprise the benefits regarding the development costs and the maintenance costs. The intangible benefits can only be estimated, since these are dependenton for instance the market in which an organization operates. To deal with intangible benefits, the use of scenarios is proposed. A scenario is composed of a worst-case and a best-case. A scenario thus contains a bandwidth. The worst-case bound represents which benefits certainly are gained and the bestcase represents an optimistic, yet realistic view on the benefits. The cost-benefit analysis as a whole also contains a bandwidth of values. The third and final metric level addresses the corporate-level strategy. It is concerned with the longterm health of the software product line, which is reflected in for instance the product line scope. Two types of scenarios are used, i.e. architectural scenarios and strategic scenarios. The architectural scenario represents what features are enabled by transforming the product line architecture and the strategic scenario represents future evolutions of the market in which the organization operates, the available technologies, and the products. Each architectural scenario has a certain value in each strategic scenario, dependent on how much value the enabled features of that architectural scenario have in a certain strategic scenario. By analyzing and making assumptions on future evolutions, the product line scope can evolve accordingly.