Methodology for Maintainability-Based Risk Assessment

Transcription

1 Methodology for Maintainability-Based Risk Assessent Walid M. Abdeloez, West Virginia Uniersity Katerina Gosea-Popstojanoa, Ph. D., West Virginia Uniersity Hany H. Aar, Ph. D., West Virginia Uniersity Key Words: Maintainability-based risk, software aintenance, software architectures, change propagation probability. SUMMARY & CONCLUSIONS A software product spends ore than 65% of its lifecycle in aintenance. Software systes with good aintainability can be easily odified to fix faults or to adapt to changing enironent. We define aintainability-based risk as a product of two factors: the probability of perforing aintenance tasks and the ipact of perforing these tasks. In this paper, we present a ethodology for assessing aintainability-based risk to account for changes in the syste requireents. The proposed ethodology depends on the architectural artifacts and their eolution through the life cycle of the syste. We illustrate the ethodology on a case study using UML odels. 1. INTRODUCTION The cost of software aintenance accounts for 60% - 80% of the oerall software syste cost [1]. Software aintenance is categorized as correctie, dealing with error corrections, perfectie, trying to iproe the quality of the syste, and adaptie aintenance concerned with syste changes as requireents and enironent change. Software aintainers usually are not inoled in the original software deelopent cycle. They ust learn how a progra functions before they can change it. They often interact with coplex and difficult to coprehend systes. The status of syste docuentation, prograer skill, and experience and the attributes of the syste itself are soe of the ariables that affect the aintenance process. Good aintainability of the syste facilitates easy odifications when adapting to changes in the enironent. Maintainability-based risk assessent should guide the anageent during the software aintenance process. In this paper, we address the proble of aintainability risk assessent using architecture etrics. In accordance with NASA-STD-8719 standard [2], we define aintainabilitybased risk assessent of a coponent as the product of the probability of changing the coponent and the aintenance ipact of changing the coponent [3]. Maintainability-based risk can be used to achiee the following: o Iproe the aintainability of the syste architecture. o Identify risky coponents in ters of aintainability and assign the to the ost experienced aintainers. o Use aintainability risk to anage syste aintenance process. Many types of risk are ushered when software systes undergo aintenance. They are siilar to those we face when deeloping new software systes, but with different leel of risk. These types of risk are [4]: o Project risk Maintenance project cannot be carried out within the budget or on tie due to ineffectie aintenance process or lack of personnel and aintenance capabilities. o Usability risk Systes will cause probles and failures after the aintenance is conducted. Usability risk includes functionality, perforance, financial and software failure risk. o Maintainability risk It will be difficult to aintain the syste in the future because of the way we conducted this aintenance. In this paper, we propose a ethodology for estiating the aintainability-based risk of syste coponents due to changes in syste requireents. This study is a part of a wider effort that considers other architectural leel risks such as reliability-based risk [5] and perforance-based risk [6]. The paper is organized as follows. In Section 2, we briefly discuss the literature background of our study. In Section 3, we present the estiation ethodology for aintainabilitybased risk due to changes in requireents. In Section 4, we illustrate how to estiate aintainability-based risk on a case study. 2. BACKGROUND Seeral studies addressed the quantification of hardware aintainability but only few attepted to quantify software aintainability. One of the faous studies [7] introduced the Maintainability Index (MI) easure. The MI is calculated using a polynoial of widely used code leel easures such as Halstead easures and McCabe s cycloatic coplexity. In [8], Muthanna et al. conducted a siilar study, which used design leel etrics to statistically estiate the aintainability of software systes. They constructed a linear odel based on a inial set of design leel software etrics to predict Software Maintainability Index. The estiation procedure of aintainability-based risk presented in this paper builds on our preious work on change propagation probabilities [9] and size of change. To estiate these etrics, we first analyze the architecture of the syste under inestigation using a structural diagra or a class /06/$20.00 (C) 2006 IEEE

2 diagra. Fro these artifacts, we identify the coponents and the connectors of the coponent-based syste architecture. Then, we need to analyze essage protocols between eery pair of coponents in the syste to identify essages exchanged between coponents C i and C j. With the help of case tools, we get essage sets for any pair of coponents in the syste. This inforation can also be obtained fro static analysis tools of the source code. In the following, we briefly present the fundaentals of estiating the change propagation probabilities. Let us consider a software architecture odeled by coponents and connectors. We are interested in the aintainability of the products instantiated fro it. Each eleent of the Change propagation probability CP= [cp ] for an architecture is the conditional probability that a change originating in coponent C i requires changes to be ade to coponent C j [9]. An architecture can be seen as a collection of coponents C i, i=1,,n. With eery coponent C i, we associate the set V i of the interface eleents of the proided functions of C i. We deterine the usage coefficient alue π for eery interface eleent ν V i and eery other coponent C j, j i. They take binary alues: π =1, if the interface eleent ν proided by C i is required by C j. This eans that any signature change in coponent C i associated with interface eleent ν will propagate to coponent C j. π =0, otherwise. For eery pair of coponents C i and C j, i j, the change propagation probability cp can be estiated based on the alues of the usage coefficients π by [9]: 1 cp = π Vi (1) ν Vi where V i is the cardinality of interface eleents set proided by C i. 3. THE PROPOSED METHODOLOGY Our ethodology for estiating aintainability-based risk depends on architectural artifacts such as syste requireents and syste design and their eolution through the life cycle of the syste, as shown in Figure 1. First, we estiate the requireent aturity and ap it into coponents stability. Then, we estiate initial change probabilities of the coponents. Using the initial change probabilities of the coponents and change propagation probabilities between the, we get the unconditional probability of change of the coponents of the syste. To get the ipact of the aintenance tasks, we use the size of change between the coponents of the syste. Finally, the aintainability-based coponent risk factor is the product of unconditional change probability and the aintenance ipact. We present the detailed steps of the proposed ethodology in the following subsections using UML odels [10]. 3.1 Estiating requireents aturity index We estiate the requireents aturity by analyzing their eolution across the releases of the syste. A software syste is deeloped according to a set of requireents RQ = {rq 1, rq 2,,rq p } (2) where rq i is a functional requireent. In UML, requireents are apped into a set of use cases : RQ(UML) = {uc 1, uc 2,, uc p } (3) Use cases describe the functional behaior of the syste. Each use case is realized through one or ore sequence diagras. Sequence diagras describe the interactions aong coponents to fulfill certain requireents. Since it is not possible to account for all possible Figure 1 Maintainability-based risk estiation ethodology 338

3 aintenance tasks, we only consider a aintenance profile MP [11] which consists of likely change scenarios MP = {cs 1, cs 2,, cs s } (4) A change scenario is defined by a set of requireent changes cs i = {rq 1c, rq 2c,, rq tc } (5) where rq ic is an addition, deletion or odification of use case uc i.. The IEEE 982 standard [12] suggests Software Maturity Index to quantify properties of requireents eolution. In [13], the Software Maturity Index is adapted to Requireents Maturity Index (RMI) to easure the requireents stability. We adapt the etric to Use Case Maturity Index (UCMI) and use function points as a size easure for the use cases [14]. Thus, the UCMI of the use case uc i is gien by UT UC UCMI = (6) UT where U T is the function point size of the use case uc i in the current release; U C is the function point size of the change in the use case uc i in the next release fro the current due to requireent change rq ic of change scenario cs. 3.2 Estiating coponents initial change probabilities In order estiate the probability of change due to a aintenance task, we use the sequence diagras to identify the set of coponents that contribute to each use case. Then, we ap the use case stability into coponents stability, which reflects the likelihood of aking changes to coponents due to changes in the requireents. Consequently, we estiate Initial Change Probabilities ICP of the syste coponents. For coponents that are part of ultiple scenarios, we consider the axiu ICP, that is, we accounts for the worst-case scenario. 3.3 Estiating unconditional change probabilities To account for the dependency aong the coponents of the syste, we ultiply the initial change probabilities ector ICP of the coponents by the conditional change propagation probabilities atrix CP obtained fro the syste architecture. Hence, we calculate the unconditional probability UPC of change of each coponent of the syste: UCP = ICP * CP (7) 3.4 Estiating size of change To get the ipact of the aintenance task, we estiate the size of change SC between pairs of the coponents of the syste based on the architecture artifacts. Each eleent of the Size of Change SC=[sc ] atrix is defined as the ratio between the nuber of affected ethods of the receiing coponent caused by the changes in the interface eleents of the proiding coponents and the total nuber of ethods in the receiing coponent. For eery coponent C j, we associate the set M j of the ethods of coponent C j. We deterine the effect coefficient alue µ for eery ethod in coponent C j, j i. They take binary alues: µ =1, if the ethod is affected by any interface eleent ν V i proided by C i µ =0, otherwise. The size of change sc can be estiated: 1 sc = µ M (8) j M j where M j is the cardinality of the ethods set of coponent C j. Thus, the Maintenance Ipact MI= [i i ] is estiated by: i = sc. (9) i j where i i is the aintenance ipact of coponent C i on the rest of the coponents of the syste. 3.5 Estiating coponents aintainability-based risk Finally, the coponents aintainability-based risk MR is gien by MR= [r i ] =[ upc i. i i.] (10) where r i is aintainability-based risk of a coponent C i due to requireent changes. Hence, the ethodology proides the aintainer with an estiate of the aintainability-based risk of the coponents for different change scenarios of the aintenance profile. Therefore, the aintainer can identify the risky coponents and the risky change scenarios. Furtherore, the aintainer can anage the aintenance process by aking a trade of between the risk associated with aintenance tasks estiated by the ethodology and the added alue anticipated fro the planned requireents changes. 4. CASE STUDY The aintainability-based risk assessent ethodology is illustrated on CM1 case study fro the Metrics Data Progra [15]. CM1 is a software coponent of a data processing unit used in an instruent, which exploits data to probe the early unierse. A UML-RT odel for CM1 is constructed fro the artifacts proided. The functional requireents of CM1 are captured in the use case odel, as shown in Figure2. Fro the use case odel, we identify the set of functional requireent RQ as: RQ(CM1) = {Transfer, RecCd, ChBound, CalcOrbitDrift, HeartBeat, HouseKeeping, TieSync} (11) We estiate the requireent aturity by analyzing their eolution across the releases of the syste. As, it is not possible to account for all possible aintenance tasks we only consider a aintenance profile MP. For siplicity, we consider a aintenance profile that has only one change scenario: MP = {cs 1 } (12) Assue that the change scenario that consists of adding a new transfer sequence, shown in Figure3, to the Transfer use case: 339

4 Figure 2 Use case diagra for CM1 cs 1 = { Transfer c } (13) We easure the function point size of the Transfer use case in the current release, and the function point size of the changes in the use case Transfer in the next release fro the current due to Transfer c of change scenario cs 1. We follow the rules presented in [14] to estiate the function point size of the Transfer use case and the change in it. Then, we estiate the use case aturity index, according to equation (8). We find UCMI(Transfer)= We ap the use case aturity index into coponents stability using the sequence diagra Transfer c. We deterine how the stability of each coponent is affected according to the aount of contribution in the added sequence diagra Transfer c. As coponent s stability and probability of change are inersely proportional, we ake an estiate of initial change probabilities of the coponents, as shown in Figure 4. The structure diagra of CM1 is shown in Figure 5. Using the software architecture artifacts of CM1, we estiate the change propagation probabilities and size of change, as shown in Figure 6 and Figure 7. Substituting initial change probabilities of the coponents and change propagation probabilities between the in equation (8), we estiate the unconditional probability of change of the CM1 coponents. Then, we use the size of change between the coponents to account for the aintenance ipact, based on equation (9). Using equation (10), the aintainability-based coponent risk factor for each CM1 coponent is estiated. The results are shown in Figure 8. The ost risky coponent is CCM een though it is not in the set of coponents of the initial change. This is due to the fact that CCM is coupled to all of the coponents of the initial change set, so it is likely to be affected by the changes introduced in these coponents. Furtherore, CMM has a high aintenance ipact on the rest of CM1 coponents. As it is coupled to other coponents in the syste other than the coponents of the initial change set, the change is likely to propagate further. On the other hand, coponent DPA has the highest initial change probability alue, but it is coupled to a liited nuber of coponents in Figure 3 Sequence diagra Transfer c of added to transfer use case Figure 4 Initial change probabilities resulted fro Transfer c for CM1 coponents Figure 5 Structure diagra for CM1 CM1. Therefore, it has a liited aintenance ipact and it is less risky in ters of aintainability. Aong our enues of future research, we consider 340

5 through a grant fro the NASA Office of Safety and Mission Assurance (OSMA) Software Assurance Research Progra (SARP) anaged through the NASA Independent Verification and Validation (IV&V) Facility, Fairont, West Virginia. REFERENCES Figure 6 Change propagation probabilities for CM1 Figure 7 Size of change for CM1 Figure 8 Coponents aintainability- based risk resulted fro Transfer c for CM1 coponents autoating the steps of the aintainability-based risk ethodology by extending Software Architectures Change Propagation Tool (SACPT) [16]. We also plan to apply the ethodology on other case studies and copare the estiated risk with actual aintenance records. ACKNOWLGEMENT This work is supported by the National Science Foundation through ITR progra grant No CCR , and by NASA 1. T.M. Pigoski, Practical Software Maintenance: Best Practices for Managing Your Software Inestent, John Wiley & Sons, NASA-STD A, Software Safety NASA Technical Standard, W. AbdelMoez, I. Shaik, R. Gunnalan, M. Shereshesky, K. Gosea-Popstojanoa, H.H. Aar, A. Mili, C. Fuhran, Architectural Leel Maintainability Based Risk Assessent, IEEE International Conference on Software Maintenance poster proceedings (ICSM 2005), Septeber 25-30,2005, Budapest, Hungray. 4. Sherer S., Using Risk Analysis to Manage Software Maintenance, Software Maintenance: Research and Practice, Vol. 9, , K Gosea-Popstojanoa., A. Hassan, A. Guede, W. Abdeloez, D. Nassar, H. Aar, A. Mili, Architectural-Leel Risk Analysis using UML, IEEE transaction on software engineering, Vol.29, No.10, October 2003, pp V. Cortellessa, K. Gosea-Popstojanoa, K. Appukkutty, A. Guede, A. Hassan, R. Elnaggar, W. Abdeloez, and H. Aar, Model-Based Perforance Risk Analysis, IEEE Transaction on Software Engineering, Vol.31, No.1, January 2005, pp P. Oan, J. Hageeister, "Constructing and Testing of Polynoials Predicting Software Maintainability", Journal of Systes and Software 24, 3 (March 1994), pp S. Muthanna, K. Ponnabala, K. Kontogiannis and B. Stacey, A Maintainability Model for Industrial Software Systes Using Design Leel Metrics, Seenth Working Conference on Reerse Engineering (WCRE'00), Brisbane, Australia, Noeber 23-25, W. AbdelMoez, M. Shereshesky, R. Gunnalan, H.H. Aar, Bo Yu, S. Bogazzi, M. Korkaz, A. Mili, Quantifying Software Architectures: An Analysis of Change Propagation Probabilties, ACS/IEEE International Conference on Coputer Systes and Applications (AICCSA 05), Cairo, Egypt, January 3-6, Unified Modeling Language OMG Resource Page J. Bosch and P. Bengtsson, Assessing Optial Software Architecture Maintainability, Proc. of fifth European Conference on Software Maintenance and Reengineering, Lisbon, Portugal, March IEEE Std IEEE Standard Dictionary of Measures to Produce Reliable Software. 13. S. Anderson, M. Felici, Quantitatie Aspects of Requireents Eolution. In Proceedings of the 26th Annual International Conference on Coputer Software 341

6 and Applications Conference, COMPSAC 2002, Oxford, England, 26-29th August 2002, IEEE Coputer Society, pp G. Cantone, D. Pace, G. Calaaro, Applying Function Point to Unified Modeling Language: Conersion Model and Pilot Study, Proc. of 10th International Syposiu on (METRICS'04), Septeber 11-17, 2004,Chicago, Illinois, pp Metrics Data Progra, NASA IV&V Facility W. Abdeloez, R. Gunnalan, M. Shereshesky, H.H. Aar, Bo Yu, M. Korkaz, A. Mili, Software Architectures Change Propagation Tool (SACPT), Proc. 20th IEEE International Conference on Software Maintenance (ICSM 2004), Chicago, IL, Septeber BIOGRAPHIES Walid M. Abdeloez Lane Dept of Coputer Science and Electrical Engineering West Virginia Uniersity Morgantown, WV USA Walid Abdeloez receied the BSc degree in electrical engineering at Alexandria Uniersity, Egypt in 1995 and the MSc degree in electrical engineering at Arab Acadey for Science and Technology, Alexandria, Egypt, in He is a PhD student in coputer engineering progra at West Virginia Uniersity and a graduate research assistant in the LDCSEE. His research interests are software etrics and software risk assessent. He is student eber of the IEEE. Katerina Gosea-Popstojanoa, PhD Lane Dept of Coputer Science and Electrical Engineering West Virginia Uniersity Morgantown, WV USA katerina@csee.wu.edu Katerina Gosea-Popstojanoa is an assistant professor in the Lane Departent of Coputer Science and Electrical Engineering at West Virginia Uniersity, Morgantown. Prior to joining West Virginia Uniersity, she was a postdoctoral research associate in the Departent of Electrical and Coputer Engineering at Duke Uniersity, Durha, North Carolina. Her research interests include software reliability engineering, dependability, perforance and perforability assessent of software and systes, and coputer security and suriability. She has published ore than 50 journal and conference articles on these topics. Dr. Gosea-Popstojanoa is a principal inestigator on seeral projects funded by the NASA Office of Safety and Mission Assurance (OSMA), Software Assurance Research Progra (SARP) anaged through the NASA IV&V Facility in Fairont, WV. She is also a recipient of the National Science Foundation CAREER award. She sered and is currently sering on progra and organizing coittees of seeral prestigious conferences in her research areas. She is a senior eber of the IEEE and eber of the ACM. Hany H. Aar, PhD Lane Dept of Coputer Science and Electrical Engineering West Virginia Uniersity Morgantown, WV USA aar@csee.wu.edu Hany H. Aar is a professor of coputer engineering in the Departent of Coputer Science and Electrical Engineering at West Virginia Uniersity. His research interests are in software engineering, software architectures, software etrics, and identification technology. He is the director of the Software Architectures and High Perforance Coputing Lab at WVU. He is leading seeral projects funded by the US National Science Foundation under the Digital Goernent and ITR progras and NASA Office of Safety and Mission Assurance (OSMA) Software Assurance Research Progra (SARP) anaged through the NASA Independent Verification and Validation (IV&V) Facility, Fairont, West Virginia. He has published ore than 100 articles in prestigious journals and conference proceedings. He sered and is currently sering in the progra and steering coittees of seeral professional conferences and workshops. Dr. Aar is a eber of the IEEE Coputer Society and the ACM. 342