Process-Family-Points

Process-Family-Points Sebastian Kiebusch 1, Bogdan Franczyk 1, and Andreas Speck 2 1 University of Leipzig, Faculty of Economics and Management, Information Systems Institute, Germany kiebusch@wifa.uni-leipzig.de, franczyk@wifa.uni-leipzig.de 2 University of Jena, Faculty of Economics and Business Administration, Commercial Inf. Systems, Germany andreas.speck@uni-jena.de Abstract. Software system families are characterized through a structured reuse of components and a high degree of automation based on a common infrastructure. It is possible to increase the efficiency of software system families by an explicit consideration of process flows in application domains which are driven by processes. Based on that fact this article briefly describes the approach of process family engineering. Afterwards the metrics of Process- Family-Points are explained in detail. These are the only framework to measure the size and estimate the effort of process families. Subsequently this paper shows the first results from a validation of the Process-Family-Points in the application domains of ebusiness and Automotive. After an evaluation of these empirical data this paper concludes with an outlook on future activities. 1 Introduction Software systems families obtain a reduction of development time and costs as well as an improvement of quality in comparison to the traditional software engineering [cf. 10]. The consideration of software internal process flows realizes an additional optimization of the approach of software system families in domains which are driven by processes. These process families (PF) allow an inexpensive software engineering based on a optimized reuse and automation. PF require an adoption of the requirements from the focused domain due to the high complexity of software internal process flows. This work has been done so far for the domains of ebusiness and Automotive [cf. 9]. Figure 1 illustrates the actual version of the domain specific approach of process family engineering. The size of the implementation and the effort of developing software products are dependant on the particular approach of software engineering. New paradigms in software engineering such as PF are characterized by reuse, automation and an explicit consideration of process flows. Therefore we need appropriate metrics to measure the size and estimate the effort for PF. Due to the novelty of process family engineering there are no methods for quantifying the economic advantages of this new software engineering approach. However the existence of software metric is a main attribute for the acceptance of PF Q. Wang et al. (Eds.): SPW/ProSim 2006, LNCS 3966, pp. 314 321, 2006. Springer-Verlag Berlin Heidelberg 2006

Process-Family-Points 315 in the future. Only a reliable measurement of economic advantages enables the practical use of process family engineering. The extensive utilization of PF will be restricted as long as there are no methods available to manage the cost, time and quality of development for PF. Fig. 1. Process family engineering [cf. 1] The following essays were analyzed in detail as related work to our approach [cf. 5]: Böckle, G., et al.: A Cost Model for Software Product Lines [2]; Lamine, S.: A Software Cost Estimation Model for Product Line Engineering [7]; Poulin, J.: The Economics of Software Product Lines [8]; Withey, J.: Investment Analysis of Software Assets for Product Lines [10]. The software metrics described in these articles measure the characteristics of software system families only from a certain and restricted viewpoint. Moreover they disregard the explicit process focus of PF and lose sight of quality influences or effort estimation. Because of these reasons the so called metrics of Process-Family-Points (PFP) were developed to realize a size measurement and effort estimation for PF. All PFP metrics are derived by goal-oriented actions according to the approved technique of the Goal Question Metric (GQM) paradigm. 2 Size Measurement The functional specification of the requirements from a new PF-product are the informational foundation of the PFP approach in compliance with figure 2. Additional

316 S. Kiebusch, B. Franczyk, and A. Speck Fig. 2. Size measurement [cf. 5] information about the specific reuse of common and variable PF-assets are necessary as well. These data are the main results of the asset scoping which is an central activity within the domain scoping of a PF according to figure 1. The determination of the type of count is the first step for a size measurement by the PFP analysis corresponding to figure 2. The type of count defines if the PF is developed from scratch or built by a modification of an existing infrastructure. A third counting type is offered to measure a single software product which is derived from the PF. The determination of these counting types is similar to the Function Point Analysis (FPA) and affects the calculation of the implementation size from a PF. Based on these types of count the results of the PFP approach and the measures of the FPA are comparable. Therefore the general acceptance of the PFP metrics will be supported by this compatibility. The following stage of the PFP analysis is called demarcation and identifies the counting scope as well as the system borders of the PF. At this point the dynamic boundaries are outlined between the common and variable assets. Hence it is possible to identify single variants of software products from the PF. The main goal of this stage is the meaningful differentiation of the assets which are to measure in the focused PF. An iterative execution of the demarcation (initial, interim and final calculation) enables the consideration of the evolution in the infrastructure of a PF as shown in figure 1. Consequently this step accesses the evolution which triggers the exchange between the common and variable assets in a PF. Furthermore the creeping scope phenomenon is considered during the development of a PF. The micro analysis in figure 2 is characterized as an accumulation of software metrics to calculate an unadjusted size measure for PF. These metrics are partitioned in two sections as a result of the domain specific PF-usage:

Process-Family-Points 317 ebusiness: The actions to measure a PF in the domain of ebusiness comprise a data oriented and a process focused perspective. Both viewpoints realize a classification of the properties from PF in categories which differ in relation to their implementation size. Subsequently to this categorization a complexity weighting of every data and process function compose the foundation for the calculation of unadjusted PFP. Automotive: The metrics to measure PF in the automotive domain comprehend the characteristics of a real time and a process viewpoint with an important influence of the implementation size. The process to calculate the size measure of unadjusted PFP is also organized into the sections of categorization, complexity weighting and transformation. Subsequently all calculated size measures were accumulated based on the preassigned type of count and attached to a project or a product. This sum of unadjusted PFP can be used as an early indicator to estimate future efforts. Furthermore this size measure is companionable to unadjusted FP and the COSMIC functional size unit (Cfsu). Consequently it is possible to compare PF with classical development approaches in the area of software engineering. 3 Effort Estimation The PFP metrics which forecast efforts in developing or modifying a PF constitute a high flexible system to evaluate external influences in software engineering. Hence these metrics quantify environmental influences in a dynamic way and can be considered as an all-purpose concept. In addition to adjusting the PFP measures the macro analysis also enables a substitution of the out-of-time weighting procedures Fig. 3. Effort estimation [cf. 5]

318 S. Kiebusch, B. Franczyk, and A. Speck from the FPA or Mark II analysis. With the flexible process model of figure 3 it is possible to take account of relevant effort influences which are up-to-date. The domain independent software metrics from figure 3 consider four common conditions of PF, each subclassified in five exemplary influences. Environmental factors like documentation, infrastructure, transition process and knowledge transfer are evaluated as exemplary parameters of the flexible architecture from the PFP macro analysis. This general part of the PFP macro analysis calculates a numerical degree of influence which is connected to the evaluated factors and quantifies their impact on the effort to develop or modify a PF. The numeral influence of every domain independent influencing factor is calculated like in table 1. Table 1. Documentation influences ID documentation value effect on effort A Is it necessary to create technical and/or yes increase 01 functional specifications? no decrease A Is it a must to documentate the usage of yes increase 02 software metrics? no decrease A yes increase Is it planned to documentate the code? 03 no decrease A yes increase Is it a must to develop a user guide? 04 no decrease A Is it planned to documentate defects and/or yes increase 05 create a test paper? no decrease numeral influence Σ increasing values After this evaluation of general influences the software metrics in figure 3 focus 30 exemplary characteristics which are domain dependent. Typical influences with a high impact on the development or modification effort for a PF in the automotive domain are for instance computing power, safety and memory volume. On the other hand influences like flexibility, marketing and legal position have an effect on the development or modification of a PF in the domain of ebusiness. At this stage a second numeral influence will be calculated for the specific domain. The consideration of 27 quality factors according to ISO/IEC 9126 is not obligatory in contrast with the preview metrics which are mandatory to execute [cf. 3]. The additional application of this optional part from the PFP macro analysis enables the computation of a third numeral influence with a quality focus. According to the process model in figure 3 the size measure of adjusted PFP is calculated by the numeral influences from the domain dependent and the domain specific software metrics. Beside the percentage of adjustment, the number of general and domain specific influences can be selected in a flexible way. Furthermore the preassigned type of count guarantees a comparability between adjusted PFP and adjusted FP. The optional size measure of quality adjusted PFP is a refinement of the adjusted PFP. An additional consideration of quality attributes realizes a high correlation between quality adjusted PFP and the effort for developing or modifying a PF. At the

Process-Family-Points 319 same time quality adjusted PFP are not compatible with alternative size measures because other metrics do not consider quality attributes on a satisfactory scale. Normally the adjusted PFP are calculated to compare the productivity between PF and traditional approaches in software engineering. On the other hand quality adjusted PFP are preferred if alternative size measures are not available for a comparison and a high precision of the effort estimation is important. The concluding estimation of effort for developing or modifying a PF is computed by usage of empirical equations. A number of functions to forecast efforts in man hours based on historical data are offered for the size measures of unadjusted, adjusted and quality adjusted PFP [figure 4, figure 5]. 4 Validation The correlation between the size measures of the PFP analysis and the effort to develop or modify a PF was investigated by scenarios of empirical validation. Within this framework it was possible to collect historical data for a derivation of domain specific equations to estimate the efforts in a PF project. Every part of the PFP analysis with a focus on the domain of ebusiness was initially validated within a project at the University of Leipzig. Additionally to the development of a PF all efforts were estimated by a parallel usage of the PFP analysis and the traditional FPA. The size measures of the latter approach were characterized by a low correlation to the recorded efforts. On the other side the results of the PFP analysis have a significant higher coherence to the required efforts for developing a PF in the domain of ebusiness. Figure 4 illustrates the PFP size measure with the highest effort correlation. Furthermore an equation to estimate man hours in dependence on quality adjusted PFP (y=3,4784x) is calculated by a linear regression. 180 160 140 y = 3.4784x R 2 = 0.9672 person hours 120 100 80 60 40 20 0 0 10 20 30 40 50 quality adjusted PFP Fig. 4. Quality adjusted PFP and man hours (ebuiness)

320 S. Kiebusch, B. Franczyk, and A. Speck A first validation of the PFP analysis to measure the size and estimate the effort for PF in the automotive domain was executed in cooperation with DaimlerChrysler Research and Technology. The potential effort to realize a theoretical PF was identified within the framework of a Delphi-Study as a multistage expert interview. Therefore it was possible to compare the identified person hours for developing a PF with the precalculated size measures of the PFP analysis and the COSMIC Cfsu. In contrast to the Cfsu all PFP size measures were characterized by a much higher correlation to the determined efforts. Figure 5 shows the coherence between quality adjusted PFP and the efforts for developing a PF in the domain of automotive by a empirical based equation (y=2,0534x). 140 person hours 120 100 80 60 40 y = 2.0534x R 2 = 0.9677 20 0 0 10 20 30 40 50 60 70 quality adjusted PFP Fig. 5. Quality adjusted PFP and person hours (automotive) The described validation is to be characterized as an laboratory study with an restricted scope. Nevertheless the PFP analysis is the only valid framework of software metrics to measure the size and forecast the effort in developing or modifying a PF. Moreover it is planned to collect additional data by usage of prototypical, domain specific implementations of the PFP software metrics. 1 Based on these measurement tools the actual equations to estimate the efforts will be calibrated and optimized during the research project Process Family Engineering in Service- Oriented Applications (PESOA). 5 Conclusion The PFP analysis which was described in this article allows the identification of different influences to a project and supports an efficient problem management in software engineering for a PF. Furthermore, the discussed metrics enable a precise 1 Downloadable at: http://www.kiebusch.de

Process-Family-Points 321 project planning and a tracking of the development progression. Based on the delivery of size measures and the estimation of future effort the PFP software metrics calculate valuable information for the economical management of PF. Despite the fact that these software metrics are the only approach to measure a PF they are first of all a scientific starting point which can be extended in different perspectives. For instance it is imaginable to match the PFP analysis with the rules of a functional size measurement according to ISO/IEC 14143 [cf. 4]. At the end it is to mention that the PFP macro analysis describes a high flexible system to access the impact of external influences which can be used also with traditional metrics like the FPA. These PFP metrics offer a model to optimize the accuracy of alternative approaches for effort estimation in the area of software engineering. References 1. Bayer, J., Buhl, W., Giese, C., Lehner, T., Ocampo, A., Puhlmann, F., Richter, E., Schnieders, A., Weiland, J.: Process Family Engineering: Modeling variant-rich processes. PESOA Report No. 18/2005, 2005. 2. Böckle, G., Clements, P., McGregor, J. D., Muthig, D., Schmid, K. A Cost Model for Software Product Lines. In: van der Linden, F. (Ed.) Software Product-Family Engineering: 5 th International Workshop, PFE 2003. Springer LNCS 3014, Berlin u. a. 2004, S. 310-316. 3. International Organization For Standardization/International Electrotechnical Commission (Ed.): Software engineering Product quality Part 1: Quality model. ISO/IEC 9126:2001, Geneva 2001. 4. International Organization For Standardization/International Electrotechnical Commission (Ed.): Information technology Software measurement Functional Size Measurement Part 1: Definition of concepts. ISO/IEC 14143-1:1998, Geneva 1998. 5. Kiebusch, S. Metriken für prozessorientierte Software-System-Familien: Umfangskalkulation sowie Aufwandsprognose im Electronic Business und Automobilbereich. Dissertation, University of Leipzig, Leipzig 2006. 6. Kiebusch, S., Franczyk, B., Speck, A.: Measurement of Embedded Software System Families. In: Proceedings of the 6 th International Workshop on Software Process Simulation and Modeling, St.-Louis 2005, pp. 48-56. 7. Lamine, S. Modèle d estimation de coûts pour le développement logiciel basé sur la réutilisation: Cas de l approche PLE. Master-Thesis, National School of Computer Science, Tunis 2004. 8. Poulin, J.: The Economics of Software Product Lines. In: International Journal of Applied Software Technology, 3 (1997) 1, pp. 20-34. 9. Process Family Engineering in Service-Oriented Applications (Ed.): PESOA Publikationen. http://www.pesoa.org/pages/publications.html, 2005-12-23. 10. Withey, J.: Investment Analysis of Software Assets for Product Lines. CMU/SEI-96- TR-010, Carnegie Mellon University, 1996.