Agile Processes in Software Engineering and Extreme Programming- P5

Agile Processes in Software Engineering and Extreme Programming- P5:“The Program Commitee of XP 2000 invites you to participate in this meeting ofsoftware development researchers, professionals, educators, managers, and students.The conference brings together people from industry and academia to shareexperiences and ideas and to provide an archival source for important papers onflexible process-related topics.
Nội dung trích xuất từ tài liệu:
Agile Processes in Software Engineering and Extreme Programming- P5108 R. Moser et al. Let Mi ∈ M={MCC, WMC, CBO, RFC, LCOM} be a subset of the maintainabilitymetrics listed in Table 1. We consider them at a class level and average later over allclasses of the software system. Now we assume that there exists a function fi thatreturns the value of Mi given LOC and some other – to us unknown – parameters P attime t. Since we are only interested in the dependence of Mi on LOC in order to ana-lyze the change of Mi regarding to LOC and time we do not require any additionalassumptions for fi and may write: M i (t) = f i (t,LOC,P) (1) Equation (1) simply states that the maintainability metric Mi will change duringdevelopment and this change will depend on time t, LOC and some other parametersP. Now we can express our idea in the following way: If throughout development Migrows rapidly with LOC its derivative with respect to LOC will be high (and probablygrow) and affect in a negative way maintainability of the final product. Otherwise, ifthe derivative of Mi with respect to LOC is constant or even negative the maintainabil-ity will not deteriorate too much even if the system size increases significantly. For-mally we can define a Maintainability Trend MTi for metric Mi and for a time period Tin the following way: 1 T ∂f i (t k ,LOC,P) 1 T ΔM i MTi = ∑ ∂LOC ≈ T ∑ ΔLOC (t k ), T is a time period T tk (2) tk To obtain an overall trend we average the derivative of Mi with respect to LOCover all time points (at which we compute source code metrics) in a given time periodT. This is a very simple approach since it does not consider that for different situa-tions during development such derivative could be different. More sophisticatedstrategies are subject of future investigations. We use equation (2) to differentiate between situations of “Development For Main-tainability” (DFM) and “Development Contra Maintainability” (DCM): If the MTi per iteration is approximately constant throughout development or nega-tive for several metrics i than we do DFM. If the MTi per iteration is high and grows throughout development for several met-rics i we do DCM and the system will probably die the early death of entropy. Such classification has to be taken cum grano salis, as it relies only on internalcode structure and we do not include many important (external) factors such as ex-perience of developers, development tools, testing effort or application domain. How-ever, we think that it is more reliable than threshold based techniques: It does not relyon historic data and can be used at least to analyze the growth of maintainability met-rics with respect to size and detect for example if it is excessively high. In such casesone could consider to refactor or redesign part of the system in order to improvemaintainability.2.3 Research QuestionsThe goal of this research is to determine whether XP intrinsically delivers high main-tainable code or not. To this end we state two research questions, which have to beaccepted or rejected by a statistical test. The two null hypotheses are: Does XP Deliver Quality and Maintainable Code? 109 H10: The Maintainability Trend (MTi) per iteration defined in equation (2) formaintainability metric Mi ∈ M is higher during later iterations (it shows a growingtrend throughout development). H20: The Maintainability Index MI decreases monotonically during development.In section 3 we present a case study we run in order to reject or accept the null hy-potheses stated above. If we can reject both of them –assuming that our proposedmodel (2) and the Maintainability Index are proper indicators for maintainability - wewill conclude that for the project under scrutiny XP enhances maintainability of thedeveloped software product.3 Case StudyIn this section we present a case study we conducted in a close-to industrial environmentin order to analyze the evolution of maintainability of a software product developed usingan agile, XP-like methodology [1]. The objective of the case study is to answer our re-search question posed in section 2: First we collected in a non-invasive way the basicmetrics listed in Table 1 and computed out of them the composite ones as for examplethe MI index; after we analyzed their time evolution and fed them into our proposedmodel (2) for evaluating the time evolution of maintainability. Finally, we used a statisti-cal test to determine whether or not it is possible to reject the null hypotheses.3.1 Description of the Project and Data Collection ProcessThe object under study is a commercial softwa ...