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 3.1. Model Overview Figure 3 shows the based components of the proposed model. The model comprises eight input parameters, two estimated output parameters, and two internal models. According to the input parameters values, with the aid of the two internal models, the values of the output parameters (Estimated Release Time and Estimated defected User Stories) can be predicted. In addition, the model considers three XP basic activities: Release Planning, Development Session and Acceptance Test Activities (shown in the elliptical shape). For simplicity, the model assumes the following assumptions: Defects are only found at the acceptance test phase.


The defects are modelled as story points to be treated in the next release.


The number of defects is affected by Test Driven Development and On site customer Practices.


The developer velocity increases as the project goes on.


The estimated release time is calculated as the time of the development session activity only ignoring the release plan and acceptance test times.


The team velocity is affected by the team size, team experience, Pair Programming Practice, and Test Driven Development Practice. Defects are only found at the acceptance test phase. Defects are only found at the acceptance test phase. The defects are modelled as story points to be treated in the next release. The defects are modelled as story points to be treated in the next release. The number of defects is affected by Test Driven Development and On site customer Practices. The number of defects is affected by Test Driven Development and On site customer Practices. Test Driven Development On site customer Practices. The developer velocity increases as the project goes on. The developer velocity increases as the project goes on. The estimated release time is calculated as the time of the development session activity only ignoring the release plan and acceptance test times. The estimated release time is calculated as the time of the development session activity only ignoring the release plan and acceptance test times. The team velocity is affected by the team size, team experience, Pair Programming Practice, and Test Driven Development Practice. The team velocity is affected by the team size, team experience, Pair Programming Practice, and Test Driven Development Practice. Pair Programming Practice Test Driven Development Practice. Model Input Parameters Model Input Parameters Eight parameters were considered as input parameters to the release model: Planned User Stories: The number of user stories to be developed in this release. This number should be available before the beginning of the release.


Added User Stories: The number of user stories to be added from the previous release due to the defects in the previous release.


Average number of Story Points per User Story: This number is an estimate number. It can be calculated as an average of the previous releases and similar projects.


Team Size: The number of developers in the development team.


Project Working Days: The summation of the estimated release days over all previous releases.


Pair Programming usage: a scale of 5 levels describing at what extend the team adopts the Pair programming practice is used for measuring. A mapping for the scale to a percentage is done according to table 1.


Test Driven Development usage: The same five levels scale is used to describe at what extend the team adopt the Test Driven Development practice.


On Site Customer usage: The same five levels scale is used to describe at what extend the team adopt the Onsite Customer practice. Planned User Stories: The number of user stories to be developed in this release. This number should be available before the beginning of the release. Planned User Stories: The number of user stories to be developed in this release. This number should be available before the beginning of the release. Planned User Stories: Added User Stories: The number of user stories to be added from the previous release due to the defects in the previous release. Added User Stories: The number of user stories to be added from the previous release due to the defects in the previous release. Added User Stories: Average number of Story Points per User Story: This number is an estimate number. It can be calculated as an average of the previous releases and similar projects. Average number of Story Points per User Story: This number is an estimate number. It can be calculated as an average of the previous releases and similar projects. Average number of Story Points per User Story: Team Size: The number of developers in the development team. Team Size: The number of developers in the development team. Team Size: Project Working Days: The summation of the estimated release days over all previous releases. Project Working Days: The summation of the estimated release days over all previous releases. Project Working Days: Pair Programming usage: a scale of 5 levels describing at what extend the team adopts the Pair programming practice is used for measuring. A mapping for the scale to a percentage is done according to table 1. Pair Programming usage: a scale of 5 levels describing at what extend the team adopts the Pair programming practice is used for measuring. A mapping for the scale to a percentage is done according to table 1. Pair Programming usage: Test Driven Development usage: The same five levels scale is used to describe at what extend the team adopt the Test Driven Development practice. Test Driven Development usage: The same five levels scale is used to describe at what extend the team adopt the Test Driven Development practice. Test Driven Development usage: On Site Customer usage: The same five levels scale is used to describe at what extend the team adopt the Onsite Customer practice. On Site Customer usage: The same five levels scale is used to describe at what extend the team adopt the Onsite Customer practice. On Site Customer usage: According to the input parameters values, with the aid of team Velocity and defected story points Models, the values of the output parameters (Estimated Release Time and Estimated defected User Stories) can be predicted. Those values are feed as an input to the next release. The details of the team Velocity and defected story points Models will be provided in the next section. team Velocity defected story points team Velocity defected story points The three basic activities of XP release: Release Planning, Development Session and Acceptance Test are shown in the elliptical shape. In the Release Planning phase, the user stories are sorted according to the importance and the release user stories are selected among them. The development session includes the basic development activities: simple design, coding and unit testing activities. Finally, the release testing activity is done in the Acceptance Test phase. 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.

The Core Components of an Extreme Programming Process Model

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

The Role of Onsite Customers in Agile Software Development

Understanding Bayesian Networks: A Graphical Model for Uncertainty

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

The Role of Onsite Customers in Agile Software Development

Understanding Bayesian Networks: A Graphical Model for Uncertainty

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps