Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Background and 2.1. Related Work
2.2. The Impact of XP Practices on Software Productivity and Quality
2.3. Bayesian Network Modelling


Model Design
3.1. Model Overview
3.2. Team Velocity Model
3.3. Defected Story Points Model


Model Validation
4.1. Experiments Setup
4.2. Results and Discussion


Conclusions and References Background and 2.1. Related Work
2.2. The Impact of XP Practices on Software Productivity and Quality
2.3. Bayesian Network Modelling Background and 2.1. Related Work Background and 2.1. Related Work 2.2. The Impact of XP Practices on Software Productivity and Quality 2.2. The Impact of XP Practices on Software Productivity and Quality 2.3. Bayesian Network Modelling 2.3. Bayesian Network Modelling Model Design
3.1. Model Overview
3.2. Team Velocity Model
3.3. Defected Story Points Model Model Design Model Design 3.1. Model Overview 3.1. Model Overview 3.2. Team Velocity Model 3.2. Team Velocity Model 3.3. Defected Story Points Model 3.3. Defected Story Points Model Model Validation
4.1. Experiments Setup
4.2. Results and Discussion Model Validation Model Validation 4.1. Experiments Setup 4.1. Experiments Setup 4.2. Results and Discussion 4.2. Results and Discussion Conclusions and References Conclusions and References Conclusions and References 2.2. The Impact of XP Practices on Software Productivity and Quality A number of Studies were conducted to assess the impact of XP practices such as Pair Programming, Test Driven Development and Onsite Customer practices in the software Productivity and quality. Those contributions study the impact of such practices on the Project Velocity and the product defect rates. A number of quantitative studies conducted to assess the validity and efficiency of the Pair Programming practice. Some of these contributions study the impact of the Pair Programming practice on the Project velocity. Generally speaking, According to those studies, Pair Programming increases the Project Velocity by a factor starting from 0 (no change) to 45%. In [7], the authors conducted found that pair programming is 40-50% faster than solo programming. In addition, the pairs implement the same functionality with 20% fewer line of codes than the solo students. In [8], The results showed that there is no significant difference in the average development time between XP with pair programming and XP without Pair Programming. In [9], the authors found that the PP group spends 19% less time than individuals to complete the same project. In [10], the authors found that Pair Programming does not improve neither the quality nor the productivity. A number of quantitative studies conducted to assess efficiency of the Test Driven Development practice. Some of these contributions study the impact of this practice on the Project velocity and the product defect rate. Generally speaking, According to those studies, Test Driven Development results in increasing the project time by a factor starting from 0 (no increase) in some studies to 80% in others. On the other hand, Test Driven Development results in reducing the defect rate by a factor of 40% in some contributions. In [11], the authors reported an improvement in quality achieved by a team following test-during-coding process ranged from 38% to 267% fewer defects. Unfortunately, testduring-coding process increase the development time by a factor from 60% to 100%. In [12], the authors reported that the TDD developers took more time (16%) than those not using this practice, but produced higher code quality by a factor of 18%. A number of studies consider the impact of the Onsite Customer Practice. In [13], the authors reported a reduction in the development effort by a percentage of 5.48%. In [14] four case studies with different degrees of customer interaction were considered. The authors measured the effort spent to fixing defects in the four cases. In the very high customer involvement case, only 6 percent of the effort was spent to fixing defects. However, in the low level of customer involvement, the time spent fixing defects reached about 40 percent. Authors:
(1) Mohamed Abouelelam, Software System Engineering, University of Regina, Regina, Canada;
(2) Luigi Benedicenti, Software System Engineering, University of Regina, Regina, Canada. Authors: Authors: (1) Mohamed Abouelelam, Software System Engineering, University of Regina, Regina, Canada; (2) Luigi Benedicenti, Software System Engineering, University of Regina, Regina, Canada. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Understanding Bayesian Networks: A Graphical Model for Uncertainty

Predicting Software Development with XP: A Look at Existing Models

Bayesian Inference Explained

Too Long; Didn't Read

Make resilience your competitive advantage

The Role of Onsite Customers in Agile Software Development

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Dynamic Programming Approach to Optimizing Signaling Strategies in Multi-phase Trials:

EffConPy: Open Source Causality Discovery in Python

Predicting Software Development with XP: A Look at Existing Models

Understanding Bayesian Networks: A Graphical Model for Uncertainty

The Iterative Structure of an XP Process Model

A Dynamic Programming Approach to Optimizing Signaling Strategies in Multi-phase Trials:

EffConPy: Open Source Causality Discovery in Python

Predicting Software Development with XP: A Look at Existing Models

Understanding Bayesian Networks: A Graphical Model for Uncertainty

The Iterative Structure of an XP Process Model

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps