Sensitivity Analysis for Search-Based
Software Project Management
Francisco de Jose
King’s College London
MSc Computing And Internet Systems 2007/2008
School of Physical Sciences and Engineering
Computer Science Deparment
Supervised by Mark Harman
August 2008
“Live as if your were to die tomorrow. Learn as if you were to live forever”
Gandhi
Abstract
This paper introduces a new perspective in the field of Software Engineering in pur-
suance of a feasible alternative to the classical techniques of Software Project Man-
agement through the use of Genetic Algorithms (GAs) in Sensitivity Analysis (SA). A
beneficial solution is important from the point of view of the manager as a result of
the increasing complexity of the software projects. The use of GAs in SA can provide
new means to improve the initial schedule of a project and thereby tackle the classi-
cal Project Scheduling Problem (PSP). The proposed implementation will develop an
answer to the managers in their necessity to identify the most sensitive tasks as well
as new ways to optimize their project in terms of duration. This paper describes the
application of GAs in a process of resource allocation. Moreover, it analyses the impact
of breaking dependencies within the definition of a project. The alternative detailed in
this paper indicates the suitable direction of future work to achieve a proper results for
an implementation of SA through the use of GAs to all the parameters of a project. In
so doing that, the biggest negative impact due to the smallest alteration in one of the
parameters can provide the most sensitive factors of the entire project.
Key words: search-based, software engineering, genetic algorithms, sensitivity analysis,
project management.
Acknowledgements
First I wish to convey my sincere gratitude to my supervisor, Prof. Mark Harman
who offered invaluable assistance, support and guidance. Without whose knowledge and
counsel this study would not have been successful. I appreciate his direction, technical
support and supervision at all levels of the research project.
I must also acknowledge special thanks to my colleges from the University of Malaga
Juan Jose Durillo and Gabriel Luque for their suggestions and advise which have been
inestimable help in the development of this project.
The author would like to recognise to Simon Poulding from the University of York for
proving valuable advice and assistance in the statistical analysis of this dissertation, for
which I am really grateful.
Most of all I would like to express my deepest love to my family, my parents Francisco
and Maria Del Carmen and my sister Irene. Their endless support, motivation and
encouragement through this Master and my life has contributed notably to this project,
I owe them my eternal gratitude.
ii
Contents
Abstract i
Acknowledgements ii
List of Figures iv
List of Tables v
Abbreviations vi
Symbols vii
1 Introduction 11.1 Simple Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Problem Statement 52.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Task Precedence Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Task Precedence Graph (TPG) . . . . . . . . . . . . . . . . . . . . 62.2.2 Critical Path Method (CPM) . . . . . . . . . . . . . . . . . . . . . 72.2.3 Project Evaluation and Review Technique (PERT) . . . . . . . . . 8
3 Literature Survey 93.1 Search-based Software Engineering . . . . . . . . . . . . . . . . . . . . . . 93.2 Search-Based Software Project Management . . . . . . . . . . . . . . . . . 11
3.2.1 Genetic Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Validation of the work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 The Model Introduced by this Thesis 214.1 Specific Details of the Model . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Evaluation (Fitness Function) . . . . . . . . . . . . . . . . . . . . . 244.1.3 Recombination (Operator) . . . . . . . . . . . . . . . . . . . . . . . 25
iii
Contents iv
5 Resource Allocation 265.1 Non-Classical GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.2 First Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.2.1 Individuals and Populations . . . . . . . . . . . . . . . . 285.1.2.2 Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . 285.1.2.3 Method of Selection . . . . . . . . . . . . . . . . . . . . . 295.1.2.4 Recombination . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2.5 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.2.6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.3 Second Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.3.1 Method of Selection . . . . . . . . . . . . . . . . . . . . . 325.1.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Classical GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.1 First Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.1.2 Individuals and Populations . . . . . . . . . . . . . . . . 365.2.1.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.1.4 Method of Selection . . . . . . . . . . . . . . . . . . . . . 375.2.1.5 Recombination . . . . . . . . . . . . . . . . . . . . . . . . 375.2.1.6 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.1.7 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.2 Second Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.2.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.2.2 Individuals and Populations . . . . . . . . . . . . . . . . 415.2.2.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.2.4 Method of Selection . . . . . . . . . . . . . . . . . . . . . 415.2.2.5 Recombination . . . . . . . . . . . . . . . . . . . . . . . . 415.2.2.6 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.2.7 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.3 Third Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.4 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.5.1 New Parent population . . . . . . . . . . . . . . . . . . . 455.2.5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 SensitivityAnalysis 486.1 Methodology to adapt data . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Project defintions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1 Project 1: CutOver . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.2 Project 2: Database . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.3 Project 3: QuotesToOrder . . . . . . . . . . . . . . . . . . . . . . . 516.2.4 Project 4: SmartPrice . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Sensitivity Analysis Methodology . . . . . . . . . . . . . . . . . . . . . . . 526.4 Sensitivity Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4.1 Results Project 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
iv
Contents v
6.4.2 Results Project 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.4.3 Results Project 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.4.4 Results Project 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5 Statistical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.5.1 Statistical Techniques and Methodology . . . . . . . . . . . . . . . 686.5.2 Statistical Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.5.3 Statistical Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5.3.1 Statistical Results Project 1 . . . . . . . . . . . . . . . . 706.5.3.2 Statistical Results Project 2 . . . . . . . . . . . . . . . . 716.5.3.3 Statistical Results Project 3 . . . . . . . . . . . . . . . . 716.5.3.4 Statistical Results Project 4 . . . . . . . . . . . . . . . . 72
6.6 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Conclusions 76
8 Future Work 78
A Appendix 80
B Appendix 97
Bibliography 118
v
List of Figures
1.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 TPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 CPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 GA’s methodology. Evolutionary Testing. . . . . . . . . . . . . . . . . . . 13
4.1 Two-point crossover operator method . . . . . . . . . . . . . . . . . . . . 25
5.1 TPG Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Sony Results Non-Classical GA V1 . . . . . . . . . . . . . . . . . . . . . . 325.3 Comparison Non-classical GA V1 and V2 with 1000 evaluations . . . . . . 345.4 Comparison Non-classical GA V1 and V2 with 10000 evaluations . . . . . 345.5 Comparison Non-classical GA V1 and V2 with 100000 evaluations . . . . 355.6 Average comparison Non-classical GA V1 and V2 . . . . . . . . . . . . . . 355.7 Comparison Non-classical GA V1 and V2 and Classical GA V1 . . . . . . 385.8 Comparison Average Non-classical GA V1 and V2 and Classical GA V1 . 405.9 Comparison Average Non-classical GA V1 and V2 and Classical GA V1
and V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.10 Comparison Average Non-classical GA V1 and V2 and Classical GA V1,
V2, and V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1 Projec 1. Normalisation Test 1. . . . . . . . . . . . . . . . . . . . . . . . . 546.2 Projec 1. Normalisation Test 2. . . . . . . . . . . . . . . . . . . . . . . . . 546.3 Projec 1. Normalisation Test 3. . . . . . . . . . . . . . . . . . . . . . . . . 556.4 Projec 1. Normalisation Test 4. . . . . . . . . . . . . . . . . . . . . . . . . 556.5 Projec 2. Normalisation Test 1. . . . . . . . . . . . . . . . . . . . . . . . . 576.6 Projec 2. Normalisation Test 2. . . . . . . . . . . . . . . . . . . . . . . . . 576.7 Projec 2. Normalisation Test 3. . . . . . . . . . . . . . . . . . . . . . . . . 586.8 Projec 2. Normalisation Test 4. . . . . . . . . . . . . . . . . . . . . . . . . 586.9 Projec 3. Normalisation Test 1. . . . . . . . . . . . . . . . . . . . . . . . . 616.10 Projec 3. Normalisation Test 2. . . . . . . . . . . . . . . . . . . . . . . . . 616.11 Projec 3. Normalisation Test 3. . . . . . . . . . . . . . . . . . . . . . . . . 626.12 Projec 3. Normalisation Test 4. . . . . . . . . . . . . . . . . . . . . . . . . 626.13 Projec 4. Normalisation Test 1. . . . . . . . . . . . . . . . . . . . . . . . . 656.14 Projec 4. Normalisation Test 2. . . . . . . . . . . . . . . . . . . . . . . . . 656.15 Projec 4. Normalisation Test 3. . . . . . . . . . . . . . . . . . . . . . . . . 66
vi
List of Figures vii
6.16 Projec 4. Normalisation Test 4. . . . . . . . . . . . . . . . . . . . . . . . . 66
vii
List of Tables
5.1 TPG representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Duration representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 Resource representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.4 Resource allocation representation . . . . . . . . . . . . . . . . . . . . . . 285.5 Sony project resource allocation . . . . . . . . . . . . . . . . . . . . . . . . 305.6 Sony project results for Non-classical GA V1 . . . . . . . . . . . . . . . . 315.7 Sony Average Results Non-Classical GA V1 . . . . . . . . . . . . . . . . . 315.8 Sony project results for Non-classical GA V2 . . . . . . . . . . . . . . . . 335.9 Average comparison Non-classical GA V1 and V2 . . . . . . . . . . . . . . 345.10 Sony project resource allocation . . . . . . . . . . . . . . . . . . . . . . . . 385.11 Sony project results for Classical GA V1 . . . . . . . . . . . . . . . . . . . 395.12 Average Non-classical GA V1 and V2 and Classical GA V1 . . . . . . . . 395.13 Resource allocation representation Classical GA V2 . . . . . . . . . . . . . 405.14 Sony project results for Classical GA V2 . . . . . . . . . . . . . . . . . . . 435.15 Average Non-classical GA V1 and V2 and Classical GA V1 and V2 . . . . 435.16 TPG Representation Second Version . . . . . . . . . . . . . . . . . . . . . 445.17 Sony project results for Classical GA V3 . . . . . . . . . . . . . . . . . . . 465.18 Average Non-classical GA V1 and V2 and Classical GA V1, V2, and V3 . 46
6.1 Original project definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Transformation project definition table . . . . . . . . . . . . . . . . . . . . 506.3 Adapted project definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4 Final project definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.5 Projects definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.6 Top 10 dependencies Project 2 . . . . . . . . . . . . . . . . . . . . . . . . 596.7 Top 10 dependencies Project 3 . . . . . . . . . . . . . . . . . . . . . . . . 636.8 Top 10 dependencies Project 4 . . . . . . . . . . . . . . . . . . . . . . . . 676.9 Top 10 dependencies Project 1 . . . . . . . . . . . . . . . . . . . . . . . . 706.10 P-value Rank Sum test Top 10 dependencies Project 1 . . . . . . . . . . . 706.11 P-value Rank Sum test Top 10 dependencies Project 2 . . . . . . . . . . . 716.12 P-value Rank Sum test Top 10 dependencies Project 3 . . . . . . . . . . . 726.13 P-value Rank Sum test Top 10 dependencies Project 4 . . . . . . . . . . . 72
A.1 Top 10 Results Project 1 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . 81A.2 Top 10 Results Project 1 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . 82A.3 Top 10 Results Project 1 Test 3 . . . . . . . . . . . . . . . . . . . . . . . . 83A.4 Top 10 Results Project 1 Test 4 . . . . . . . . . . . . . . . . . . . . . . . . 84A.5 Top 10 Results Project 2 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . 85
viii
List of Tables ix
A.6 Top 10 Results Project 2 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . 86A.7 Top 10 Results Project 2 Test 3 . . . . . . . . . . . . . . . . . . . . . . . . 87A.8 Top 10 Results Project 2 Test 4 . . . . . . . . . . . . . . . . . . . . . . . . 88A.9 Top 10 Results Project 3 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . 89A.10 Top 10 Results Project 3 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . 90A.11 Top 10 Results Project 3 Test 3 . . . . . . . . . . . . . . . . . . . . . . . . 91A.12 Top 10 Results Project 3 Test 4 . . . . . . . . . . . . . . . . . . . . . . . . 92A.13 Top 10 Results Project 4 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . 93A.14 Top 10 Results Project 4 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . 94A.15 Top 10 Results Project 4 Test 3 . . . . . . . . . . . . . . . . . . . . . . . . 95A.16 Top 10 Results Project 4 Test 4 . . . . . . . . . . . . . . . . . . . . . . . . 96
ix
Abbreviations
AEC Architecture, Engineering and Construction
BRSA Broad Range Sensitivity Analysis
CPD Critical Path Diagram
CPM Critical Path Method
DOE Design of Experiments
FAST Fourier Amplitude Sensitivity Test
GA Genetic Algorithm
PERT Project Evaluation Review Technique
PSP Project Scheduling Problem
SA Sensitivity Analysis
SD System Dynamic
TPG Task Precedence Graph
x
Symbols
RAND MAX number 32767 interger
xi
To my family
xii
Chapter 1
Introduction
The main goal of this project is the development of an implementation able to provide
an improvement over the original schedule in software project management by the use
of search-based software engineering techniques. The first phase aims to the deployment
of a solution for the process of resource allocation in the definition of the project by
the application of genetic algorithms (GAs). At the same time, this work supplements
this first goal by a second aspect of improving planning in software project management
by breaking dependencies and performing sensitivity analysis (SA). Software project
management is a significant up to date area with increasing complexity and demand
from almost every sector in the industry and not only in the field of New Technologies.
Nowadays, projects in every engineer or industrial sector such as architecture, energy,
aeronautic, aerospace, and much more involve the use of specific software and therefore
the Project Scheduling Problem (PSP) is more present than ever. As a result, the de-
mand for new tools and techniques by companies and their managers to improve the cost
and duration, variables which define the PSP, of software projects is a visible concern.
Hence, the idea highlighted of contributing with new means to advance, enhance, and
improve the solutions in software project management is significant enough to justify
this paper.
The remainder of the paper is organised as follows. The next section starts setting out
the problem covered in this research in general terms. Thereafter, it is mentioned the
previous related work and the main background material, analyzing the ideas proposed
in that material and the main differences regarding the focus of this research. Then this
paper introduces a section with the main foundations which support it and present the
base of the model developed. The next section explains the work that was performed
during this research, specifying the main techniques used during its approach as well as
the methodology adopted. In this sense, this section concretely states the implications
1
Introduction
in software project management of this paper. Likewise, the first subsection describes
an accurate specification of the technical details. Straight afterwards, the following
section details the two different algorithms developed and the results obtained in the
application of those GAs to diverse scenarios constructed from data of real projects.
Next, a complete section explains the process of SA performed as well as the process of
breaking dependencies in addition to the results obtained. The following section fully
details the conclusions obtained after analysing the results. The last section of this
paper details which could be the next steps and the future work in the development of
this research.
1.1 Simple Example
The idea behind this paper is exemplified in Figure 1.1, Figure 1.2, and Figure 1.3. The
first figure represents the task precedence graph of a simple project definition. In this
project definition there are five tasks with their duration as well as the dependencies
between those tasks. For this simple example it is assumed that the resource allocation
for those tasks has been made producing the duration indicated in the number inside
the octagons, which represent the tasks. In addition, it is also assumed that every task
can be at any time due to the resource allocation. This part would correspond to the
first phase of this research.
Taking into consideration all the premises detailed in the previous paragraph and ac-
cording to the information revealed in Figure 1.1, the optimal completion time for this
project definition would be 26 units of time.
Figure 1.1: TPG + Duration. Example 1.
The second phase of this research rests in the process of breaking dependencies and
performing sensitivity analysis to evaluate whether it is possible to optimise the overall
completion time for the project definition. If this idea is applied to this particular
2
Introduction
example, it is feasible to reduce considerable the schedule. As it can be observed in
Figure 1.2, if the dependence between the task 2 and the task 3 is removed the scenario
represented in Figure 1.3 would allow new completion times. In this case, the new
optimal completion time would be 16 units of time. Hence, it would be possible to
decrease the original schedule by ten units of time which is a significant improvement.
Figure 1.2: TPG + Duration. Example 1. Breaking dependencies.
Figure 1.3: TPG + Duration. Example 1. Resulting TPG after breaking dependen-cies.
Furthermore, it is necessary to indicate that by removing dependencies the process of
resource allocation it would be performed again and therefore, the number of possible
combinations is considerable yet not always desirable.
The process explained and illustrated in the previous figures is a simplification of the
model developed. The purpose of this example is to provide a general idea of the main
goal aimed in this research.
3
Introduction
1.2 Roadmap
The project first developed an algorithm able to cover the considered parameters of
the PSP in order to provide an accurate benchmark for the resource allocation in the
project definition. This algorithm worked on different combinations, understanding by
combinations the different possibilities of the assignment between the resources available
and the tasks defined. This part corresponds to the first phase the research, and as
it shows the section 5 of this paper various alternatives were considered and several
scenarios were tested.
The second phase of the project carried out the process of breaking dependencies and
re-running the algorithm developed in the first part in order to evaluate whether it
is possible to produce improvements by reducing the benchmark or original optimal
completion time. In order to produce trustworthy results, the model developed was
applied to different scenarios based on real data projects. Thus, the input data set
which fed the model produced valuable output since the possible spectrum of scenarios is
infinite whereas the real framework might be limited. The results obtained are evaluated
performing sensitivity analysis over the solutions provided by the model. This procedure
measures the relative impact of every modification introduced in the original scenario.
The data analysed is the effect produced on the original completion time by removing
dependencies and altering the resources available. This method tries to identify whether
the dependencies which produce improvement are always the same and how they behave
in the different scenarios.
In addition, based on the results collected in the sensitivity analysis statistics analysis
was performed to add reliability to the data produced by the model developed.
4
Chapter 2
Problem Statement
2.1 Problem Definition
In the discipline of software project management the main objective is to successfully
achieve the project goals within the classical constraints of time and budget utilizing the
available resources. In order to be able to accomplish this aim in the best way, companies
and managers desire to optimize the allocation of the resources in the tasks, which define
the project, to meet the objectives. Based on this distribution, tasks have a specific start
and completion time, and the whole set defines the schedule of the project. This plan
is classically illustrated using Gantt charts, which is the most common technique for
representing the phases of a project.
Nevertheless, this assignment is not straightforward since the group of tasks might have
dependencies between them. Therefore, it might be necessary to first finish one or more
tasks to be able to start a next one. The Task Precedence Graph is the main technique
used to represent the tasks of the project and their dependencies.
This method of representing for a project should not be mistaken with the other two
main techniques, the Project Evaluation and Review Technique (PERT) and the Critical
Path Method (CPM), used to analyse and represent the schedule of the set of activities
which composes the definition of the project. This difference is explained in detail in
the section 2.2 of this paper.
The scope of this research is clearly defined within the context of developing new tech-
niques in software project management to improve the optimal solutions of the PSP. In
pursuance of this aim, this research focuses on resource allocation and breaking depen-
dencies between tasks to find a new schedule which improves the completion time of the
original optimal one. In the interest of this objective, the main technique fully detailed
5
Problem Statement
in the section 3.2.1 of this paper is GAs with the use of SA. In consequence, the idea
highlighted of optimizing completion times, probably the most complicated concern in
software project management as PSP, reasonably validates this paper.
2.2 Task Precedence Graph
This section establishes the differences between the the Task Precedence Graph (TPG),
which is a method of representation, and the Project Evaluation and Review Technique
(PERT) and the Critical Path method (CPM), which are techniques or methods for
project management. The main reason in so doing that is that the similarity in terms
of concepts and patterns used to represent in schemas these procedures could lead to
confusion.
Usually, specifying the tasks and identifying dependencies between them is the first step
in definition of a project, and the TPG is the best approach to depict this early stage.
After this point, it is common in the management of a plan to decide the time that it
is necessary to spend in every task in order to complete it. Here, it lays the key point
which distinguishes the TPG from the PERT and CPM.
2.2.1 Task Precedence Graph (TPG)
The TPG is just a method of illustrating the definition of a project by representing two
different features:
1. Tasks
2. Dependencies
Figure 2.1: Example of Task Precedence Graph.
This methodology only represents the two features mentioned and it does not take into
consideration measures about the duration of each task and therefore, cannot establish
6
Problem Statement
the known Critical Path Diagram (CPD) neither the minimum time required to complete
the whole project. Hence, the exercise of determining the time necessary to finalised
a task is a complete different activity. This fact allows establishing a separate list of
durations for the tasks calculated in terms of ”unit of time / person” or other kind
of measure. As a result the completion time of every task can vary depending on the
resources assigned to it.
2.2.2 Critical Path Method (CPM)
The CPM is a mathematical method to schedule the definition of a project which is
able to calculate the completion time. Although the management of a project involves
the consideration of many factors which can be added enhancing the CPM, the basic
representation entails the three main features:
1. Tasks
2. Dependencies
3. Duration
Figure 2.2: Example of Critical Path Method
In this sense, it is understood that the CPM shows a representation where the duration
of the task is fixed due to different reasons such as that the resources which perform the
tasks have been already assigned or the estimation in terms of duration do not depends
on the allocation of resources. The CPM is able to demarcate which tasks are critical
and which not regarding the finalisation of the project, and as a result, construct the
Critical Path Diagram in addition to the best completion time using the information
of the duration of the tasks and their dependencies. Furthermore, this methodology
determines the earliest and latest time in which every task can start and finish.
7
Problem Statement
New developed versions and tools of the CPM allow introducing the concepts of resources
producing variation in the schedule of the project, this fact can lead to misunderstanding
between CPM and TPG.
2.2.3 Project Evaluation and Review Technique (PERT)
The PERT is second technique used for analysing and scheduling the definition of a
project. This method has common similarities in its approach to the CPM, but it is also
a technique used in project management for planning the completion time and not just
for representing tasks and dependencies as the TPG. The features considered and the
means used to displays the information is almost analogue to the CPM; nevertheless,
this technique has some differences with respect to. PERT is considered a probabilistic
methodology due to its technique of estimating the duration of each task, whereas CPM
is considered a deterministic technique.
8
Chapter 3
Literature Survey
This chapter introduces the theoretical foundation for the implementations developed,
which tries to provide an improvement in the process of planning software project man-
agement in a first stage, and a further evolution of breaking dependencies through the
use of genetic algorithms (GAs) in sensitivity analysis (SA). Therefore, the aim of this
section is to settle the theoretical base of the main techniques and methodologies used in
the development of this paper. In so doing that, definitions are given for the key concepts
necessaries in the different approaches followed throughout the implementations.
In addition, the aim of this chapter is a comprehensive identification of the most relevant
literature whose information has direct impact on supporting the background area over
this paper is built on. In so doing that, we meet one basic requirement for deploying a
remarkable thesis.
3.1 Search-based Software Engineering
Search-based software engineering is a field inside software engineering whose approach
is based on the utilization and application of metaheuristic search techniques such ge-
netic algorithms, hill climbing algorithm, tabu search, and simulated annealing. These
techniques aim to produce exact or approximate solutions to optimization and search
problems within software engineering. Its application has been successfully accomplished
in different areas of software engineering which were reviewed in the literature survey
section.
Search-based software engineering and its metaheuristic techniques are mainly repre-
sented and based on mathematical data and representation. This fact, as a result,
9
Literature Survey
requires the reformulation of the software engineering problem as a search problem by
means of three main stages [1]:
• Problem’s representation
• Fitness Function
• Operators
However, it has to be taken into consideration that particular search-based techniques
may need specific necessities due to their intrinsic theoretical definition.
The representation of the problem allows the application of the features of the search-
based technique. Furthermore, it usually entails the description of the framework by
expressing the parameters, which are involved in the definition of the software engineer-
ing problem and the search-based technique applied, in a numerical or mathematical
system. In addition, this manner allows an exhaustive statistical analysis of the results.
Fitness function is a characterization in terms of the problem’s representation of an ob-
jective function or formula able to measure, quantify, and evaluates the solution domain
provided by the search-based technique.
Operators define the method of reproduction to create candidate solutions. A consider-
able variety of operators can be applied depending of the search-based technique chosen,
and the way in which it is applied is subject to the features of that technique.
The scheme divided in the three key stages proposed by Harman and Jones in [1] is the
main base of the model developed in this thesis. Therefore, the main contribution of this
paper is the supply of the basic structure necessary in the application of search-based
techniques to the problem stated in the section 2.1 of this paper. However, the model
developed differs from this work offering its own implementation of a GA as well as the
application of SA to tackle the problem.
The recent development in search-based software engineering and its different techniques
as well as its successful application in different areas has been exhibited in a significant
variety of papers. It is important highlighting certain articles such as [2] which states
the benefits of the techniques of this particular area of software engineering and provides
an overview of the requirements for their application. Moreover, it denotes a set of eight
software engineering application domains and their results. The relevance of these tech-
niques is demonstrated by their application in a wide variety of areas with encouraging
results [3][4][5][6][7].
10
Literature Survey
[2] stated that search-based optimization techniques have been applied widely to a large
range of software activities. The list mentioned covers different areas of the life-cycle
such as service-oriented software engineering, project planning and cost estimation, com-
piler optimization, requirements engineering, automated maintenance, and quality as-
sessment.
Furthermore, [2] offered a broad spectrum of optimization and search techniques for this
purpose such as genetic algorithms and genetic programming. In addition to the allusion
to GAs the same paper also remarked one key point that is directly related to interest
of this research. It cited the crucial importance of the fitness function as the main
difference between obtaining good or poor solutions no matter the search technique.
Harman in [2] analysed different optimization techniques by dividing them into two
main groups: classical techniques such as linear programming; and metaheuristic search
such as Hill Climbing, Simulated Annealing, and GAs. Moreover, Harman [2] showed a
special concern about the role of sensitivity analysis in search-based software engineering.
It turned the focus of the approach of the software engineering problems from global
optimum to the impact of the input values in different questions such as the shape of
the landscape and the location of the search space peaks.
This thesis is influenced by the work done by Harman in [2] because it also states
motivation for metaheuristics techniques, particularly GA. However, this work developed
an implementation of that particular technique to cope with the PSP. In addition, it
performs an SA which is enhanced by the use of statistical tests. Therefore, this thesis
does not raise SA as a future work, but it produces it as an essential part of the model.
3.2 Search-Based Software Project Management
Currently, software project management is a major concern software engineering. This
fact is proof by the considerable amount of techniques that are being applied in this
field. One of the areas that is making a special effort is search-based software engineer-
ing. Within this area, diverse authors use techniques such as hill climbing, GAs, and
simulated annealing. The main technique used in this thesis is GAs. As a result, despite
successful application of other techniques in search-based software engineering problems
such as hill climbing, the literature survey of this thesis is mainly based on GAs. There is
considerable amount of information related to the field of software project management
and more recently in the application of new techniques such as GAs [3][4][5][6][7][8][9][10].
The use of SA in project management is relatively new in terms of application. Hence,
the literature survey mentions not only papers with the basic notions of SA, but also
11
Literature Survey
different works where this technique was applied with interesting results in areas not
related to software project management. The main reason is to show the capacity of this
technique particularly measuring input factors of a model. This contributed significantly
to the idea of establishing which dependencies produce a bigger impact and therefore
reduce the completion time in a greater proportion when they are removed.
3.2.1 Genetic Algorithms
Genetic algorithms are a stochastic search-based technique and a particular class of
evolutionary algorithms which performs an iterative optimization method based on the
processes of natural genetics to resolve or approximate a solution. The foundation of GAs
is to extrapolate the Charles Darwin’s evolution theory to an algorithm which is able to
evolve possible candidate solutions in a process of optimization in the pursuance of the
solution of a problem. It is generally agreed that genetic algorithms have application in
a significant variety of areas such engineering, computer science, mathematics, physics
and so on.
In the development of the GAs it can be distinguished three main points:
• Definition of the process. Evolutionary testing is going to be used as a technique.
Which procedure is shown in Figure 3.1.
• Definition of the Fitness Function. The Fitness Function is the objective function
used in the process of evaluation of the candidate solution or individuals.
• Definition of the genetic operator. The election of the operator will define the way
in which a population of chromosomes or individuals is recombined to generate a
new individual.
The methodology of GAs consists in a sequence of actions explained following and il-
lustrated in Figure 3.1. In the first one, a population of individuals also known as
chromosomes is generated randomly. Each of those individuals represents a candidate
solution and therefore the initial search space of the algorithm. The next step consists in
the evaluation of every possible candidate solution through the use of the fitness function
and verifying whether the problem has been resolved or not. The fitness function has
been previously defined for the particular problem and it is able to assess the genetic
representation of the individual. The third action in the algorithm specifies a sequence
of steps included within a loop looking for an evolution in the candidate solutions or
individuals by recombining and mutating them. The sequence continuously performs a
selection whose main purpose is to choose the individuals to generate a new population.
12
Literature Survey
Figure 3.1: GA’s methodology. Evolutionary Testing.
Individuals with better fitness function evaluation are likely to be elected, although not
in an exclusively way, since this fact would incur in a problem of non-diversity within
the population. There is a considerable diversity of methods of selection. A case in
point, used in the implementation of this paper, is the tournament selection [11]. The
next step is the process of recombination of the individuals previously selected by the
methodology defined by the genetic operator agreed. In the same way that with the
method of selection, there is a considerable variety of genetic operators, a good and rel-
evant example deployed in the implementation of this paper in the two point crossover
operator [12]. The intention of this action is to combine different candidate solutions
in order to generate the new individuals of the regenerated population. After that, the
sequence performs the step of mutation whose main purpose is to try to introduce ge-
netic diversity by randomly mutating the individuals. In so doing that, the algorithm
attempts to keep the process of evolution. The last two steps of the loop consist in
evaluating the new candidate solutions generated by the algorithm and reinserting them
into the new population.
In the use of GAs this research is significantly inspired by the work done by Massimiliano
Di Penta, Mark Harman, and Giuliano Antoniol [3][5] about software project manage-
ment in a search-based approach. In addition, [4] reinforce the application of GAs in
Search-based technique for optimizing the project resource allocation. Likewise, the
work of this research is encouraged by the concerned shown by Shin Yoo in his work [10]
13
Literature Survey
about data sensitivity in the application of a Novel Semi-Exhaustive Search Algorithm.
In [3][5], based on previous work [4], is declared the application of GAs, which obtains
significant better results than random search, to implement the search-based approach.
This methodology provides empirical evidences of the variance in the completion time
and the allocation of the resources by the overhead communication produced in the
Brook’s law. Moreover, this approach is able to evaluate the impact of Brook’s law in
the completion time of the project providing a prudent technique to improve software
project management scheduling.
The work done by Antoniol et al in [3][4][5] contributed to this thesis in the idea of using
search-based approach to face the resource allocation in the project management and
the scheduling. However, those papers are orientated in complete different direction.
[3] was particularly interested in attempting to evaluate the effect of communication
overhead on software maintenance project staffing. It analysed the impact of different
factors such as the dependencies between tasks on project completion time, which is also
related to this thesis, and on staff distribution. The base of this work is to disclose the
influence or effect of Brook’s law on the two goals previously mentioned. The empirical
study presented an evaluation of the relation between the tasks and the effort (person-
s/month). Whereas the main focus of this paper is to apply search-based techniques to
decrease the completion time by removing dependencies and performing SA.
The paper [4] primary compares different search-bases techniques, using queuing simu-
lation in the fitness function evaluation. This similarity can be also appreciated in [3]
, where the use of GAs and a queuing system is part of the model. The use of GAs
to analyse the resource allocation is common in the approach of this thesis and [4][3],
yet its use is different. The GA implemented in this thesis does not use this queuing
system and it was developed to cover the parameters considered for the duration aim of
the PSP in order to allow the process of altering the TPG and study its impact over the
project completion time.
In the case of [5], it contributed to this thesis in its demonstration of the capacity of the
GAs to tackle resource allocation. This is essential part of the model generated in this
work. However, the main effort of [5] is concentrated on a search-based approach over
undesirable but frequent situations in project management, such as rework or abandon-
ment of the tasks, uncertain estimations, and errors. The idea behind this thesis also
implies resource allocation, yet it focuses on offering alternatives to the project manager
by approaching the PSP in a new way, breaking dependencies. Hence, the robustness of
the initial scheduling offered and the possible setbacks or issues arisen during the project
are not considered.
14
Literature Survey
The second main source of previous related work in GAs, which is considered as signifi-
cant valuable background, is the material of Enrique Alba and Francisco Chicano [8][9]
in the application of GAs to software project management. In this work, the application
of GAs to different scenarios to resolve the PSP provides significant results in terms of
the sensitivity of the classical variables: number and duration of tasks, skills, available
resources, dedication, and cost. These results are obtained through the use of an instance
generator developed specifically by this purpose, which automatically creates different
project scenarios based on the customize file configured. As it is always done in the
exercise of GAs, a fitness function calculates the achievement of a successful result. This
work states interesting details of the fitness function, the different considerations within
the algorithm developed, and the behaviour the of the instance generator which are fully
detailed in [8]. Yet, the most remarkable attainments are the results obtained and de-
scribed in the section 6 about the experimental study. This study could be considered a
sensitivity analysis of the different parameters, accurately represented in various tables
and an absolutely complete set of figures. Moreover, the study concludes the variable
importance the parameters. A case in point is the number of tasks, which considerably
increases the difficulty to obtain a solution in the application of the GAs.
This work done in [8] exhibited the ability of the genetic algorithms to face the Project
Scheduling problem. Nevertheless, this work also evidences certain level of incapacity
to offer solutions when the number of possible combinations is increased by the rise of
the input values which feed the model. The algorithm developed follow the classical
convention for the GAs as can be appreciated in Algorithm 1.
Algorithm 1 GA Pseudocode. Adopted from [8]InitalizeEvalutewhile do
SelectRecombineMutateEvaluateReplace
end while
The model produced by Alba and Chicano in [8] has one primary strength and one main
weakness. The major positive point of this work is its competence to deal with the
parameters of the two goals in conflict that define the PSP the cost and the duration
of the project. This work takes into consideration tasks, duration and dependences be-
tween those tasks, resources, skills of those resources, effort between tasks and resources,
salaries, and dedication of the resources to the tasks. However, the method of repre-
sentation for the dedication within the algorithm could generate non-feasible solutions.
15
Literature Survey
This important fact is the main disadvantage of the model. By non-feasible solution it is
understood those where one resource has overwork and therefore the dedication assigned
to multiple resources is impossible to be reproduce in the real work environment. In ad-
dition, the model could generate non-feasible solutions in two more situations. First, if
one of the tasks has no resource assigned. The last one, when the resource assigned does
not have the necessary skils to perform the tasks. As a result, the authors of the paper
introduced a fitness function able to discern the viability of the solutions by adding a
variable of penalty. Forming the fitness function 3.1, adapted from [8]. The term (q)
measures the quality of the solutions generated and the second term (p) calculates the
penalty.
f(x) =
{1/q iffeasiblesolution
1/(q + p) otherwise(3.1)
Alba and Chicano in [9] demonstrated the capacity of the search-based technique to
approach the Project Scheduling Problem. This paper exhibited the ability of the meta-
heuristics techniques and the genetic algorithms in particular to manage optimally the
time and the cost in the project management. Alba and Chicano perform an incredible
realistic work by considering the most classical parameters in the PSP. This fact and the
different scenarios processed allow them to exercise a precise analysis of the influence of
the attributes in the solutions of the problem. Both authors mentioned the difference
between the application of GAs in software engineering and other fields such as bioin-
formatics, mathematics, telecommunications, and so on. This metaheuristics technique
is not so intensively used in software project management. Nevertheless, their results
and conclusion proved the capacity and accuracy of the genetic algorithms to help the
managers addressing the project management.
The work done by Alba and Chicano in [8][9] significantly inspired the model developed
in this thesis contributing with the idea of using GAs to face the resource allocation
in the PSP. Nevertheless, the focus between those papers and this work is completely
different. In [8][9] Alba and Chicano studied the behaviour of the model developed in
order to produce an optimal resource allocation in diverse scenarios facing both goals of
the PSP, cost and duration. For this purpose, they took into consideration parameters
which affect both aspects such as skills of the resources, for instance. Whereas the main
aim of this thesis is to provide new means and methods to improve the overall completion
time of a project by removing dependencies and performing sensitivity analysis in this
action. All the efforts done in this work is only focus on the improving only one of the
goals of the PSP, duration. Therefore, despite both works attempt to help managers
16
Literature Survey
in software project management by the use of GAs the ultimate targets are completely
different.
3.2.2 Sensitivity Analysis
This section briefly and concisely defines sensitivity analysis and the main concepts
surrounding its study. In addition, it analyses the main previous related work in the
field of sensitivity analysis and in the area of software project management in particular.
Sensitivity analysis (SA) is the study of the impact in the output model value due to
variation in the input model source parameters. Therefore, sensitivity analysis is mainly
used in the study of the sensitivity of a model or a system in changing the input value
parameters which define that model or system [13]. This kind of analysis is generally
known as parameter sensitivity. Despite other authors also mention structure sensitivity,
that study is not matter of interest to the main purpose of this paper. Consequently,
sensitivity is the statistical measure of the effect in the outcome in comparison with the
modification in the parameters that determine it. Ergo, the greater in the variation of
the result per unit the greater the sensitivity is.
A key point in this research is a comprehensive, complete and thorough related back-
ground documentation of SA, which is necessary as a base. The general introduction
done by Lucia Breierova and Mark Choudhari for the MIT [13], as well as the definition
of Global Sensitivity Analysis proposed by Andrea Saltelli [14] provide a good support
for the understanding of the topic, giving premises and hints to carry out this method-
ology. As it is mentioned in the introduction of this paper project management and
software development are present in all the engineering areas, and the application of SA
has already been experimented in fields such as planning process in architecture, engi-
neering and construction (AEC) [15] and detecting and elimination errors in software
development [16].
The research done by Breierova and Choudhari in [13] and the one done by Saltelly in
[14] guided this thesis towards the concept of parameters sensitivity. Within sensitivity
analysis, it is the action of analysing, evaluation and measuring the impact of variations
in the input of the model to examine the behaviour responds of it. These two sources
mentioned, helped to understand the force of this theory providing a consistent base,
precise definitions and relevant examples. However, this thesis uses all this established
knowledge in the specific application of software project management, evaluating the
impact of removing in turns all the dependencies that compose the TPG in the PSP.
17
Literature Survey
[15] does not have a significant similarity with the work developed in this thesis. How-
ever, the work done by Lhr and Bletzinger was beneficial to exemplify the capacity and
the application of sensitivity analysis in different areas. Furthermore, the idea of eval-
uating the impact of diverse factors on the development of the planning process and
therefore, on the goal of time for optimal planning join the focus of this thesis in a
certain level. Since, it also performed sensitivity analysis to factors which have direct
impact in the duration of the PSP for software project management.
The work produced by Wagner in [16] coincided with the area of this thesis. It proposed
a model able to evaluate the quality costs in software development by deploying an an-
alytical model and performing sensitivity analysis. This work is also partially based on
the concept of global sensitivity analysis arisen by Saltelly in [14]. Therefore, Wagner
contributed notably to the idea of applying SA to software project management. Nev-
ertheless, this thesis differs from this work since the scenario and the factors which feed
the model and the model indeed are completely different. In general terms, the research
of Wagner focused on costs whereas this thesis tackled the other main goal of the PSP,
the duration. In addition, in [16] faced defect-detection techniques and its quality cost
associated. Thus, it did not approach the PSP directly.
Sensitivity analysis helps to identify the critical parameters which have more reper-
cussion or influence in the output of the model or system. The current relevance of
performing SA in the development of model or system is stated by Saltelli in [17] where
it is supported by the allegation of the adequate advance of its theoretical methods.
A good example of its application and its positive results collecting information of the
impact of the input parameters is [18]. Furthermore, SA can alleviate the problem of
uncertainty in input parameters [19].
The papers [17] [18] [19] assisted significantly in the generation of this thesis, although
there are substantial differences. The work of Saltelli in [17] did not contribute to the
model developed in this thesis to a particular specific part. Yet, it was considerably
helpful to understand the concept behind the sensitivity analysis. Furthermore, it con-
tributed to comprehend the importance of the factors which determine a model in order
to reveal information in the context of model-based analysis.
In the case of [18], despite the work was a clear sensitivity analysis within the context
of project management, its focus lay in analysing uncertainty and risk to justify or not
investment in projects. By contrast, in this thesis, sensitivity analysis is performed to
offer the manager different options to approach the PSP. In conclusion, both models
the one developed by Jovanovi in [18] and the one developed in this thesis work over
parameters which usually are involved in project management. Nevertheless, the final
aim of this analysis is completely different.
18
Literature Survey
Johnson and Brockman in [19] demonstrated the capacity of sensitivity analysis to iden-
tify and reveal the mechanisms that have the greatest impact on design time in design
process. Thus, the idea behind this paper is not related at all with the PSP in project
management. However, it added the concept of using sensitivity analysis to measure im-
provements in completion time when this is an essential factor of the model or problem
that wants to be faced.
In addition, it exists the application of SA in project management with different ap-
proaches such as Hybrid Models over Design of Experiments [20], MonteCarlo method
[21], and Fourier Amplitude Sensitivity Test (FAST) [16][22]. The main contribution of
these papers was its extensive use of SA to different aspects of software project man-
agement or software engineering. However, there are relevant differences with the main
focus of this thesis. All these paper used specialised techniques of SA to their particu-
lar issues. Whereas, the study done this thesis, produced a detailed evaluation of the
behaviour of the model in the different tests performed in common SA. Furthermore,
the scenario of application for this thesis, which is the classical PSP, was tackle in none
the papers mentioned. Particularly, the action of removing dependencies and measuring
its impact in the completion time of the project entailed a complete new are of survey.
Consequently, despite there is a common field of research between theses works, their
kernel of experiment is entire different.
First, Hybrid Model over Design of Experiments (DOE) [20], which is based on previous
models: System Dynamic (SD) Models, to obtain the dynamic behaviour of the project
elements and their relations; State Based Models, which reproduces process activities
and represents the dynamic processes all over the state transitions initiated by events;
and Discrete Models, to reproduce the development process. This hybrid model consists
in associating the discrete model and a process of continuous simulation able to reproduce
tasks which are affected by the constant changes of the parameters, and using the state
based model to express the changes of the states. Thus, Hybrid Models are able to
analyse the impact of changes in a dynamic project environment. Furthermore, the most
interesting affirmed aspect of this paper [20] is the possibility to show non-linearities not
discovered by the common sensitivity analysis using DOE in combination with Broad
Range Sensitivity Analysis (BRSA).
The second main approach in the use of SA is Montecarlo method and its software
covered in the research of Young Hoon Kwak and Lisa Ingall [21]. This paper applies
software based in MonteCarlo method to plan the project by the analysis, identification
and assessment of the possible problems and their circumstances within the context of the
development. This methodology has not been totally accepted in project management
for a real use although it has been used in several areas which have connections to
19
Literature Survey
modelling systems in biological research, engineering, geophysics, meteorology, computer
applications, public health studies, and finance.
The last approach is mentioned by Stefan Wagner [16] in his research of defect-detection
techniques in SA. The pillars of this work are the use of Fourier Amplitude Sensitivity
Test (FAST) based on the performance of Fourier functions and Simlab software. Ac-
cording to Wagner this method is able to provide a quantification and qualification of
the influence of the parameters. Again, although the Simlab and its capacity due to its
features seem to be very interesting, the FAST method may be not as appropriate as
BRSA for the purpose of this research.
3.3 Validation of the work
There is a considerable amount of material where a visible concerned about project
management is exposed. Furthermore, the use of techniques such as GAs and SA is
widely accepted and used in tackling a significant variety of issues as it has been described
in among this section of the paper. Nonetheless, there are significant differences from
existing work related and the main objective of this research. Next, it is made a brief, yet
clear and explicit comparison with the closest previous related work that undoubtedly
distinguishes this research.
[3][4][5] attempt to improve the completion time based on the application of search-
based over different formulations of Brook’s law. Which means, increasing the number
of employees, whereas the main focus of this paper is breaking dependencies between
tasks. The second main related source is [8][9], where the kernel is the analysis of the
differences of applying GAs taking into consideration the mentioned parameters of a
project in the pursuance of the optimal solution for the plan. The focus of this paper,
on the other hand, is to improve the optimal solution breaking the dependencies of the
TPG.
Thus, it is possible to state that although this research is thoroughly based on differ-
ent works already done in this field such as software project management with GAs [8]
and search-based approach on software maintenance project [3][4][5], as well as, plan-
ning process in architecture, engineering and construction (AEC) [15] and Detecting
and Elimination Errors in Software Development [21]. Indeed, it does not comprise an
extension or validation of earlier work. The framework of this research is defined within
the scope of relevant researchers in this field, yet it deploys an area in the pursuance of
a new solution with the application of GAs and sensitivity analysis.
20
Chapter 4
The Model Introduced by this
Thesis
The main aim of this chapter is to describe the technical specification that is going to
be adopted for the purpose of this work. This means the methodology as well as base
over which is going to be built on. Hence, taking into consideration all the information
described in the introduction of this paper as well as the detailed previous related work,
the context of this research is defined within the classical PSP and the use of GAs in
the scope of SA.
In this empirical study the principal goal is to obtain a better completion time based
on the optimal schedule for a particular project. In order to fulfil this purpose, the key
point proposed is the action of breaking dependencies of the TPG and evaluating the
completion time with the parameters of the PSP through the use of GAs. The ambi-
tion of this research is to offer the manager a range of alternatives with the maximum
improvement over the initial optimal schedule with the minimum modification. The
individual in this role will be then in a position to estimate whether the choice proposed
by the run of the model can be carry out or not.
In the furtherance of a successful culmination of this work, the first step necessary to
perform is the definition of the scenario, premises, variables, and constraints that are
going to be considered. The proposed scenario will be one able to enclose the model of the
PSP described in the introduction of this paper. As a result, the scenario will cover a task
precedence graph that will represent the dependencies between the tasks that compound
the project. In addition to this representation, the scenario will be defined by: number
and size of resources which perform the tasks; duration of every task; and assignment
or allocation between resources and tasks. Note that the information related to the cost
is not going to be considered, since the main objective of this research is to improve
21
The Model Introduced by this Thesis
the completion time. Therefore, variables of the cost of every resource are beyond the
scope of the work proposed. Nevertheless, if a positive result is obtained in a fully
implementation of the problem presented, the opportunity of enhancing it considering
the parameters related to the cost would allow to have a complete improvement to
the PSP. Since, cost and duration of the project are the two principal factors which
define the solution to the PSP. The constraints of this work are mainly imposed by the
parameters considered and developed in the implementation, as a consequence of the
impossibility of adapting the model to all particular features of every single project.
However, it is generally agreed that the set of parameters already listed are powerful
enough to represent the main aspects of a project and at the same time provide a
complete solution.
The next step in the approach of this research is the definition to the methodology
that is going to be used. In the methodology adopted for the implementation of this
research the first main technique used is GAs. The election of this search technique is
due to the fact that it outperformed other techniques such as random search in finding or
approximating a solution in an optimization or search problem. This fact is corroborated
for example in [3] where it is stated a considerable improvement regarding the use of
Hill Climbing.
The second and most relevant method within this research is the use of sensitivity anal-
ysis, mainly focus on parameter sensitivity. The essential idea is to perform a series of
tests using the developed GA and evaluate the impact on the project completion time
response. In this sense, the principal aim is to break the dependencies between tasks in
a minimum way to obtain the biggest impact and therefore the greatest improvement in
the completion time of the schedule’s project. Nevertheless, this basic approach can be
enhanced with the application of more sophisticated techniques of sensitivity analysis.
These techniques were mentioned in the section 3 of this paper as Broad Range Sensitiv-
ity Analysis (BSRA) combined with Hybrid Models over Design of Experiments (DOE),
MonteCarlo method and Fourier Amplitude Sensitivity Test (FAST). Yet, these tech-
niques have an intrinsic complexity and their effectiveness is more difficult to measure.
According to the documentation researched and mentioned in the section 3, probably
BSRA is the one which best link with the direction of this research.
The last step in the methodology is the evaluation of the model, its implementation,
and the results collected. The aim was clearly defined as the greatest reduction in the
completion time, which can be easily measure using a unit of time such as days. How-
ever, the establishment of the minimum variation in the initial schedule regarding the
action of breaking dependencies is more difficult to measure. Likewise, it is significantly
complicated to endow a benchmark in the measurement. The first logical consideration
22
The Model Introduced by this Thesis
is that if fewer dependencies are broken the impact is minor, yet this way does not face
the fact that the importance or weight of the dependencies within the project can be
dissimilar. Ergo, the ideal scenario would be taken into consideration both aspects in a
unique formula.
Consequently, the process of the model developed within this project has five different
phases clearly differenced:
1. Definition of the initial scenario. In this phase of the model, the parameters already
detailed which define a project within a PSP are taken into consideration to expose
the start point.
2. Best schedule algorithm. The second phase consists in the execution of the GA to
provide the best resource allocation for the initial scenario considering the variables
entertained in the previous phase.
3. Establishment of the optimal resource allocation. This best optimal solution pro-
duced in the preceding phase is settled as benchmark for comparing the results
obtained in the next stage of the model.
4. Process of breaking dependencies. The aim of this phase is producing results
using the same GA developed for the second phase of this model but feed it with a
different project definition. The new project definition will be the same TPG but
omitting in turn every of the dependencies which conform it.
5. Sensitivity Analysis. In this last stage of the process in the model, sensitivity
analysis is performed to obtain a list with the most potential sensitive dependencies
as well as the possible explanation of the impact produced.
In spite of the fact that time and the scope of this research does not allow to extent the
sensitivity analysis further. It would be extremely interesting to consider the possibility
of a section to identify the most critical parameters in combination with tasks using the
same concept of GAs and sensitivity analysis. Developing an algorithm able to measure
the maximum variance in the optimal schedule produced as a result of a minimum
variance in one of the parameters which define the tasks and the project.
23
The Model Introduced by this Thesis
4.1 Specific Details of the Model
4.1.1 Scenario
In the pursuance of this goal all the algorithms and implementations tried so far are
based on scenarios which are defined by the following features:
• TPG
• Duration (unit: days)
• Resources (teams: people)
The TPG was defined in the section 2.2.1 of this paper and is considered as the basic
definition of the project. This basic definition presents exclusively the list of tasks which
conforms the project as well as the dependencies between those tasks. Therefore, there
is absolutely no mention about the duration of those tasks neither minimum completion
time for the project nor critical path diagram.
The next step in the definition of the scenario is the establishment of the duration of each
tasks measured in ”unit of time / unit of resource” which is specified as ”day / person”.
This action and the precedent one of defining the TPG demarcated this framework for
a specific project.
Lastly, it is necessary to delimit the amount of resources available to perform the project.
The definition of this parameter is subject to the way in which the duration of the tasks
where set. As a result, it is possible to characterize a project depending on the resources,
expressed in terms of teams composed by different number of people, and its assignment
to the tasks. This fact leads to different specific durations for each task.
Throughout the diverse implementations developed different scenarios with different
compositions have been tested and are fully detailed and explained in the sections 5.1
and 5.2 of this paper.
4.1.2 Evaluation (Fitness Function)
The fitness function of this model evaluates the completion time of the project definition.
This consists on calculating the duration of the project based on the TPG and the
duration of each tasks plus the resource allocation generated by the GA. Thus, the
fitness function obtains the start time for each of the tasks, by assigning the latest
end time of all the tasks which depends on and the latest end time of all the possible
24
The Model Introduced by this Thesis
previous assignments of the same resource to other tasks in a slot time which could
overlap. Finally, it obtains the end time by diving the duration of the task -measured in
”day / person”- by the composition of the resources -measured in number of people- and
adding to the start time. Hence, the latest time of all the tasks will be the completion
time of the project.
It has to be taken into consideration that this fitness function in addition to the struc-
tures of representation of the model, later describe in the section 5 of this paper, as well
as the methodology of the GAs and evolutionary testing explained in the section 3.2.1 do
not always produce the real unique and absolute solution. This fitness function always
evaluates the individuals in the same order from 1 to the number of tasks. Therefore,
two tasks which are not dependant between themselves are always performed in the
same order. A better possible solution could be achieved if the order is swapped, since
they can have different duration releasing a resource in a different time as a result.
The number of possible alternatives to this problem is considerable, it could be estab-
lished a queue to store the order in which the tasks are performed, for example. However,
they main focus of this research is the sensitivity analysis process by breaking dependen-
cies. Thus, the method of evaluation developed satisfied the necessities of this research.
Moreover, it rational and legitimate to use and consider this fitness function, because
the solutions provided by the model implemented using this methodology of evaluation,
ensures computing the solutions in the same way when the sensitivity analysis is per-
formed. As a result, the complete process of removing dependencies and measuring their
impact in the overall completion time of the project has not been compromised.
4.1.3 Recombination (Operator)
The operator for the recombination process of this implementation is the two-point
crossover. The method implemented is common to all the different versions the algorithm
developed. An example of this mode of recombination is displayed in Figure 4.1.
Figure 4.1: Two-point crossover operator method.
The methodology consists in choosing randomly two points of the individuals that are
going to be recombined and swap the composition of those candidate solutions in both
sides of each point.
25
Chapter 5
Resource Allocation
The main aim of this chapter is to explain the process performed in order to obtain the
most appropriate GA to provide the resource allocation between teams and tasks. In
so doing that, it was possible to establish a benchmark to compare the results in the
procedure of sensitivity analysis and breaking dependencies.
The number of possible combinations in this process of resource allocation is consider-
able, overall when the number of tasks and dependencies exceed 40 in each case. As
a result, the following section details the effort done in developing different versions of
GAs with different techniques to obtain the best approximation. By the best approxi-
mation it was considered that version of the GA that after 30 runs is able to produce
the shortest completion time for the project definition in average of all these executions.
This average was used as the benchmark to compare with the results obtained in the
process of breaking dependencies.
All the features of the GA, the method of representation as well as the project definitions
which compose the complete scenario tested are thoroughly described in the following
sections of the paper.
5.1 Non-Classical GA
This section explains the features and the results obtained using a non-classical genetic
algorithm developed. The main characteristic which lead to this non-classical denom-
ination is that instead of having a new population generated in every iteration of the
loop of the GA, there is only one in which two new individuals are added. Thus, the
process of selection is always performed over one only population which increases in size
in every iteration of the loop.
26
Resource Allocation with GAs
5.1.1 Features
This subsection describes the method of representation for the main structures of the
implementation used, which are common to the different scenarios, as well as other
relevant features of non-classical GA’s implementation. The first part cited in the section
4.1.1 of this paper was the task precedence graph. For the representation of the TPG a
simple binary matrix is used, where the pair between the column and the row represents
the dependency between the tasks named by those indexes. An example is illustrated
in Figure 5.1 and Table 5.1.
Figure 5.1: TPG Example.
T1 T2 T3 T4T1 0 0 0 0T2 1 0 0 0T3 1 0 0 0T4 0 1 1 0
Table 5.1: TPG Representation.
For the second part which defines a scenario the structure used is an array that contains
the duration of every task as it is shown in Table 5.2.
T1 10T2 7T3 15T4 12
Table 5.2: Duration representation.
The last part that is necessary to represent in a scenario according the section 4.1.1
of this paper is the resources which are going to perform the tasks. The structure of
representation implemented is an array that indicates the size of the resource in terms of
number of members which conform the team. An example can be appreciates in Table
5.3.
In addition to the structures necessaries for the representation of the scenario it is also
needed one more to express the resource allocation. For this version of the non-classical
genetic algorithm the structure used is a binary matrix where rows describe tasks and
columns resources. Therefore, a 1 in the row 2 and column 3 indicates that the task 2 in
27
Resource Allocation with GAs
R1 3R2 4R3 5
Table 5.3: Resource representation.
assigned to be performed by the resource 3. An illustrative example is shown in Table
5.4.
R1 R2 R3T1 0 1 0T2 1 0 0T3 1 0 0T4 0 1 0
Table 5.4: Resource allocation representation.
In the development of this implementation has been considered that only one resource
can be assigned to one task at the same time. Thus, the population of the genetic
algorithm will be composed by individuals or candidate solutions with this architecture
of representation.
The last relevant structure to complete the configuration necessary to develop the com-
plete implementation is the representation of the population. This population is an
array of individuals and therefore, and array of binary matrixes.
5.1.2 First Version
5.1.2.1 Individuals and Populations
In this first version of the non-classical genetic algorithm the implementation generates
one only population which is initialised with 100 individuals generated randomly. As a
result, there is no parent and children population. In the iterations of the evolutionary
testing process of the algorithm, two individuals of the population are chosen to generate
two new ones. This action increases in each step the size of the population without
discarding individuals generated previously. This leads to immortal individuals and it
is the key point in which this algorithm differs from the classical implementations of the
GAs.
5.1.2.2 Evaluations
Taking into consideration the previous section 5.1.2.1 the number of evaluations cor-
responds to the number of individuals generated inside the population. Therefore, the
28
Resource Allocation with GAs
algorithm works all the time over only one population until it reaches the number of eval-
uations previously indicated in a variable. The method of evaluation is the application
of the fitness function specified in the section 4.1.2 to the different individuals.
5.1.2.3 Method of Selection
The method of selection implemented in this first version of the non-classical algorithm
is a non-orthodox one. This method always takes the two individuals with the best FF
in order to generate the next two individuals.
5.1.2.4 Recombination
The method of recombination used is the two point crossover operator detailed in the
section 4.1.3 of this paper. Although the representation of the individuals of the pop-
ulation is a matrix as it is explained in the section 5.1.1, in terms of programming is
treated as an array linking one after other all the different rows that compounds the
matrix.
5.1.2.5 Mutation
The process of mutation developed in this version of the algorithm does not follow the
classical standards of the GAs. First, random number of mutation between zero and
the number of tasks is generated. After that, for every of this mutation a position of
the binary matrix, which represents the candidate solution for the resource allocation
or individual of the population, is generated randomly. The mutation of the position
consists in producing a random number between 0 and 1. If the position mutates from
0 to 1 a check modify the previous resource assigned to perform that task to 0. In case
the mutation is from 1 to 0, another resource is randomly assigned to that task.
5.1.2.6 Results
The results of this section shows the solutions obtained in the application of this version
of the non-classical genetic algorithm. In a first approach the algorithm was applied to
an example project with only 7 tasks and 3 resources with different composition with
satisfactory results. The optimal resource allocation obeying the dependencies could be
calculated by hand.
29
Resource Allocation with GAs
In order to test the strength and capacity of the algorithm a much more complicated
project definition was used. For this purpose a real data project that it will be denom-
inated Sony was used, although the information related to the duration of tasks was
incomplete. As a result, the information not provided was completed manually. The
definition of the project is:
• Number of tasks: 139
• Number of dependencies: 1257
• Resources: Table 5.5
Resource MembersTeam1 3Team2 4Team3 5
Table 5.5: Resource composition of the Sony project.
The Table 5.6 shows the results of the application of the algorithm with a different
number of evaluations. The first column named as Run indicates the number of the
execution. After that, the first group displays information of 1000 evaluations in the
column FF Evaluation Series 1. The middle group represents 10000 evaluations in the
column FF Evaluation Series 2, and the last group 100000 evaluations in the column FF
Evaluation Series 3.
As it can be observed from Table 5.6 there is not a significant decrease in the completion
time of the project, even if the number of evaluations is increased from 10000 to 100000
times. This fact is clearly depicted in Figure 5.2 which is the graphic representation of
Table 5.6.
Series 1 corresponds to the results obtained after 1000 evaluations, series 2 after 10000,
and series 3 after 100000. Although there is a slight decrease from series 1 to series
2, there is no appreciable difference between series 2 and series 3. This data is also
corroborated by Table 5.7 which shows the average of the 30 executions of the algorithm.
At this stage of the implementation, it remains unclear the main reason for this lack of
success in achieving a positive result despite the considerable increase in the number of
iterations and therefore evaluations of the algorithm. The intrinsic special features of this
non-classical genetic algorithm may be partly responsible for these results. Nevertheless,
it also can be attributed to the non-orthodox method of selection or the process of
mutation of the individuals.
30
Resource Allocation with GAs
Run FF Evaluation Series 1 FF Evaluation Series 2 FF Evaluation Series 3(1000 evaluations) (10000 evaluations) (100000 evaluations)
1 586.500 574.867 560.6002 574.083 563.183 562.9333 584.217 563.367 561.5674 569.333 561.200 561.1675 572.500 562.467 562.5836 580.567 571.867 565.4677 569.867 561.267 561.3338 574.167 567.083 561.1179 576.717 562.017 562.08310 571.250 563.667 560.08311 576.267 563.333 561.71712 577.400 562.433 561.75013 572.367 562.517 561.25014 581.017 571.783 561.66715 575.050 563.517 553.00016 583.100 566.400 565.66717 571.550 563.133 561.96718 578.800 563.067 562.26719 568.917 560.967 562.06720 579.133 561.567 563.91721 578.917 562.617 561.66722 581.967 563.000 561.50023 566.417 561.833 562.26724 567.800 563.533 568.31725 570.176 562.767 562.46726 575.167 564.467 561.96727 586.467 562.767 561.31728 567.000 574.333 561.43329 575.667 571.483 560.86730 579.467 570.717 533.950
Table 5.6: Sony project results for Non-classical GA V1.
Series 1 Series 2 Series 3(1000 evaluations) (10000 evaluations) (100000 evaluations)
575.728 564.907 560.998
Table 5.7: Sony Average Results Non-Classical GA V1.
31
Resource Allocation with GAs
Figure 5.2: Sony Results Non-Classical GA V1. Note: there is no significance in theorder of elements in the x axis.
5.1.3 Second Version
The following subsection details certain modifications done over the first version of the
non-classical genetic algorithm due to the unsatisfactory results obtained in the first
version. Apart from minor improvements and changes, the main difference regarding
the previous version is the change in the method of selection of the individuals.
5.1.3.1 Method of Selection
The new method of selection implemented is the binary tournament. This method
selects two random individuals of the complete population and chooses the best in terms
of fitness function. This operation is repeated in order to obtain the second individual
necessary for the process of recombination. The reason for the election of this method
of selection is its wide acceptance in the development of GAs.
5.1.3.2 Results
The main analysis of the results in this stage of the development is trying to improve
the non-classical GA. Therefore, this new version of the algorithm is applied to the same
scenario the Sony project. See section 5.1.2.6 for the definition of the project. Thus,
we are aiming for an improvement in the completion time obtained with the different
resource allocations or candidate solutions. For this purpose, the same process of test is
done with the following data collected in Table 5.8.
32
Resource Allocation with GAs
Run FF Evaluation Series 1 FF Evaluation Series 2 FF Evaluation Series 3(1000 evaluations) (10000 evaluations) (100000 evaluations)
1 656.833 611.750 609.5002 624.267 612.400 599.5833 626.767 607.317 584.0674 639.333 583.033 586.5005 654.833 611.867 593.9676 600.500 615.650 591.0337 652.700 625.250 594.9678 655.833 606.367 585.7339 619.167 625.267 589.73310 624.900 602.700 590.76711 651.417 619.367 600.53312 647.500 609.333 589.33313 650.150 613.900 596.30014 667.600 614.250 596.71715 658.000 607.083 596.36716 658.833 608.433 600.75017 645.167 604.583 589.50018 647.833 615.200 598.90019 663.300 616.467 603.16720 654.483 617.467 596.70021 621.583 609.250 598.66722 643.250 601.483 597.43323 630.550 602.467 599.86724 631.567 605.967 592.90025 653.583 621.167 592.08326 647.250 608.667 590.16727 615.000 605.033 588.31728 661.000 608.333 599.90029 629.833 608.917 598.16730 680.677 612.367 595.000
Table 5.8: Sony project results for Non-classical GA V2.
This table gather the same kind of information as Table 5.6. The first column enumer-
ates the execution of the algorithm, and the three following groups correspond to the
application to 1000, 10000, and 100000 evaluations in this order.
The first point observed in this second version of the algorithm is a similar pattern
of behaviour. As the number of evaluation increases the solutions achieved improve
regarding the fitness function.
However, this new modification has resulted in no apparent improvement over the re-
sults of the previous version. On the contrary, the results are becoming worse. If it
is compared the results of this new version with the previous one, it is obtained the
following sequence of graphs: Figure 5.3, Figure 5.4, and Figure 5.5.
33
Resource Allocation with GAs
Figure 5.3: Comparison Non-classical GA V1 and V2 with 1000 evaluations. Note:there is no significance in the order of elements in the x axis.
Figure 5.4: Comparison Non-classical GA V1 and V2 with 10000 evaluations. Note:there is no significance in the order of elements in the x axis.
Series 1 Series 2 Series 3(1000 evaluations) (10000 evaluations) (100000 evaluations)
1st Version 575.728 564.907 560.9982nd Version 643.790 610.378 594.887
Table 5.9: Average comparison Non-classical GA V1 and V2.
34
Resource Allocation with GAs
Figure 5.5: Comparison Non-classical GA V1 and V2 with 100000 evaluations. Note:there is no significance in the order of elements in the x axis.
Figure 5.6: Average comparison Non-classical GA V1 and V2.
This fact can also be observed if it is compared the average Table 5.9 and Figure 5.6.
In both Table 5.9 and Figure 5.6, series 1 correspond to the results over 1000 evaluations,
series 2 over 10000 evaluations, and series 3 over 100000 evaluations.Although the results
obtained without doubt show no improvement in this second version of the genetic
algorithm, the Figure 5.6 displays a trend of convergence to similar results as the number
of evaluations increases. The difference is greater in Series 1 than in Series 2, and the
smallest difference correspond to Series 3.
35
Resource Allocation with GAs
At this stage of the implementation and according to the adverse results produced not
only with the first version of the Non-classical GA but also with the second version, it
was decided to develop a classical implementation of a GA based on the same premises
to compared the results in the application to the same scenario.
5.2 Classical GA
This section details the features and results of the new algorithm developed following the
classical premises of the genetic algorithms. Therefore, the principal difference regarding
the algorithm of the section 5.1 of this paper is the fact that this new one creates different
populations in each iteration. Hence, the individuals of the children population are based
on the individuals of the parent population.
The implementation of this classical genetic algorithm is based on the code of the non-
classical genetic algorithm with the necessary modifications. Furthermore, minor mod-
ifications were done to keep the performance of this new algorithm due to the new
features.
5.2.1 First Version
5.2.1.1 Features
The main features in terms of structures and method of representation for the project
definition and candidate solutions or individuals are exactly the same as the ones of the
non-classical genetic algorithm detailed in the section 5.1.1 of this paper.
5.2.1.2 Individuals and Populations
The methodology used for the individuals and populations in this new GA is totally
different from the previous one and works on the premises of the GAs. For this purpose,
the algorithm generates a new population of individuals in every iteration. Thus, this
new process discards certain candidate solutions, but not all of them, and creates new
ones. It keeps the best fitness function top individuals of the parent population to the
children population. After that, it applies the process of selection, recombination and
mutation to generate the new candidate solutions of the children population with the
rest of the non-top individuals.
36
Resource Allocation with GAs
5.2.1.3 Evaluation
The process of evaluation is the same as the one used in the previous algorithm already
defined. Nevertheless, in this classical GA the number of evaluation performed in each
iteration is equal to the size of the population minus the top individuals already evaluated
in the previous iteration.
5.2.1.4 Method of Selection
The method of selection of this new algorithm is again binary tournament. However,
this algorithm chooses the candidate solutions within the parent population of that
iteration. As a result, the diversity of the individuals to intervene in the process could
be considerably smaller depending on the configuration. Moreover, a number of top
individuals are always kept from one iteration to another. By top individuals it is
understood those which have better fitness function. As a result, those top individuals
are directly copied from the parent population to the children population. Therefore,
the following steps of recombination, mutation and evaluation are only performed over
the really new individuals. By new it is understood those which are truly generated in
every iteration.
5.2.1.5 Recombination
The process of recombination is based on the two point crossover operator explained in
the section 5.1.2.4 of this paper.
5.2.1.6 Mutation
The method elected to mutate the candidate solutions is exactly the same as the one
used in the previous algorithm and detailed in the section 5.1.2.5 of this paper.
5.2.1.7 Results
In this section the results obtained in the application of this first version of the classical
genetic algorithm are analysed. For this aim, the solutions achieved are evaluated and
compared to the ones produced by the two versions of the non-classical genetic algorithm.
Table 5.11 shows the results in the application of this GA to the Sony project defined
in the section 5.1.2.6 of this paper.
37
Resource Allocation with GAs
• Number of TOP individuals: 10
• Number of tasks: 139
• Number of dependencies: 1257
• Resources: Table 5.10
Resource MembersTeam1 3Team2 4Team3 5
Table 5.10: Resource composition of the Sony project.
The first column Run is the number of the execution. The next one FF Evaluation sym-
bolises the best completion time or fitness function obtained in that particular execution
of the algorithm.
In order to be able to compared both algorithm the number of iterations and the size of
the population produce the same number of evaluations, 100000, as the Series 3 or last
group of results of the previous algorithm.
Figure 5.7: Comparison Non-classical GA V1 and V2 and Classical GA V1. 100000evaluations. Note: there is no significance in the order of elements in the x axis.
The comparison of 100000 evaluation between the first version of the Non-classical GA,
the second version of the Non-classical GA, and the first version of the Classical GA has
resulted in extremely surprising results. The Classical GA produces considerably worse
results than the different version of the Non-classical GA.
38
Resource Allocation with GAs
Run FF Evaluation(100000 evaluations)
1 635.1672 632.6673 615.0504 612.8835 634.0336 633.2347 618.9178 615.8009 618.58310 611.91711 608.65012 647.40013 639.58314 628.83315 632.40016 593.16717 633.83318 626.91719 618.83320 610.63321 630.16722 624.50023 632.83324 620.83325 624.83326 631.83327 627.31728 618.31729 625.96730 627.733
Table 5.11: Sony project results for Classical GA V1. 100000 evaluations.
This fact is also corroborated by the average results illustrated in Table 5.12 and Figure
5.8. In addition, the average shows a worsening greater than the results generated by
the second version of the non-classical genetic algorithm.
Non-Classical GA V1 Non-Classical V2 Classical GA V1(100000 evaluations) (100000 evaluations) (100000 evaluations)
575.728 594.887 624.428
Table 5.12: Average Non-classical GA V1 and V2 and Classical GA V1. 100000evaluations.
39
Resource Allocation with GAs
Figure 5.8: Comparison Average Non-classical GA V1 and V2 and Classical GA V1.100000 evaluations.
5.2.2 Second Version
In this second version of the Classical GA important changes were made in the pursuance
of increasing the performance of the algorithm. The main reason for this action, was
trying to aim to the next step of sensitivity analysis in the model of this paper, section
4. Furthermore, this new version of the algorithm also contains modifications in a new
attempt to improve the accuracy of this classical GA.
5.2.2.1 Features
This subsection describes the modifications in the method of representation for the
main structures of the implementation regarding previous versions of the algorithm. In
addition, it explains the changes that were made to improve the performance and which
are directly related to the programming code.
The new structure to represent the resource allocation was turned from a binary matrix
to an array of integers. In this array each position represents a task and the integer rep-
resents the resource assigned to perform that task. An illustrative example it displayed
in Table 5.13.
T1 T2 T3 T41 3 2 1
Table 5.13: Resource allocation representation Classical GA V2.
40
Resource Allocation with GAs
In so doing this, it was no longer necessary to process a matrix which involves a consid-
erable number of positions. This fact was aggravated by the different loops implemented
in the distinct parts of the algorithm that produced an exponential increase of the op-
erations performed. This modification resulted in necessary changes in the stages which
define the algorithm of the evolutionary testing that was developed.
5.2.2.2 Individuals and Populations
The only significant change regarding the individuals and the populations is the data
that they contain and the way they are fed. Now the population is formed by as many
individuals as it is chosen and those individuals are formed by an array of integers of
size equal to the number of tasks.
Therefore, it was necessary to change the method to feed the initial population. In this
new version every position or tasks of each individual was assigned randomly a number
between 0 and the number of resources available.
5.2.2.3 Evaluation
The method of evaluation and the fitness function were modified to be able to process the
new structure that represents individuals. However, the methodology used to evaluate
those individuals is exactly the same as the one explained in the section 4.1.2 of this
paper.
5.2.2.4 Method of Selection
The method of selection as well as the process of evaluation was modified only to be able
to cope with this new method of representation of the individuals. Again, the binary
tournament is used to select the individuals which are going to be recombined in the
next step.
5.2.2.5 Recombination
The process of recombination by two point cross-over operator was only modified in the
strict necessary parts to allow the new structure of the individuals.
41
Resource Allocation with GAs
5.2.2.6 Mutation
In the process of mutation important changes were made apart for those essential for
the new method of representation of the resource allocation. A new methodology of
mutating the individuals was implemented since the previous one was not completely
appropriate for a GA. This new approach established a probability of mutation based
on the number of tasks or size of the individual of each population. This probability is
equal to 1 divided by the number of tasks. The process of mutation consist in a loop
which traverse the all the positions of the candidate solution and generated a random
number which is divided by RAND MAX. If the number generated is smaller than the
probability of mutation, the position is mutated to a new resource. This action is done
by generating randomly a new resource between 1 and the total number of them.
5.2.2.7 Results
Figure 5.9: Comparison Average Non-classical GA V1 and V2 and Classical GA V1and V2. 100000 evaluations.
In order to be able to compare the results of this new version of the algorithm, it was
used the same project as the previous ones.
The Table 5.14 shows the results in the application of this GA to the Sony project
defined in the section 5.1.2.6 of this paper. The number of top individuals selected for
this test was 10 the same as the one done in the previous version of the algorithm in the
section 5.2.1.7.
It can be observed in table 5.14 that this new version of the algorithm improves consid-
erably the results obtained. In general terms this second version the Classical GA is able
42
Resource Allocation with GAs
Run FF Evaluation(100000 evaluations)
1 563,4672 573,2333 564,6674 553,4675 563,9176 566,6677 564,2838 562,5009 575,50010 562,86711 566,91712 566,76713 567,70014 569,05015 576,66716 566,55017 572,25018 567,66719 560,98320 565,66721 575,76722 564,08323 565,33324 562,33325 570,50026 565,00027 565,41728 563,75029 571,00030 563,633
Table 5.14: Sony project results for Classical GA V2. 100000 evaluations.
Non-Classical GA V1 Non-Classical V2 Classical GA V1 Classical GA V2(100000 evaluations) (100000 evaluations) (100000 evaluations) (100000 evaluations)
575.728 594.887 624.428 566.587
Table 5.15: Average Non-classical GA V1 and V2 and Classical GA V1 and V2.100000 evaluations.
43
Resource Allocation with GAs
to produce better solutions considering the average of 30 runs. This fact is illustrated
in Table 5.15 and Figure 5.9.
The most reasonable explanation for this improvement is the changes made in the process
of mutation and the rest of the changes already mentioned in the pursuance of a more
accurate GA.
5.2.3 Third Version
The third version of the Classical GA contains two relevant modifications. The first
one is related to the method of representation of the TPG which has direct impact in
the performance of the evaluation process. And the other one entails changes in the
generation of the parent population of each iteration, in the pursuance of better results
in the evaluation of the fitness function. Both modifications are detailed in the following
sections.
5.2.4 Features
The idea of changing the method of representation for the TPG lies in the study done
over the performance of the code. In that analysis it was found that the majority of the
time spent running the genetic algorithm was consume by the process of evaluation of
the fitness function and particularly in the section of checking the dependencies. The
previous structure and methodology consisted in a binary matrix of size number of tasks
square, where the index of the matrix represented the number of the tasks which are
dependents, as it was illustrated in Table 5.1 and Figure 5.1. In the fitness function
evaluation the complete matrix was traversed to check all the possible dependencies.
Nevertheless, based on the same structure a new method of storing the data was intro-
duced in this version. Instead of a binary matrix, the first position of every column now
contains the number of dependencies of the task associated to the index of that column,
and in the following rows the index of the task involved in the dependency. Based on
the same example Figure 5.1, the new representation is displayed in Table 5.16.
T1 T2 T3 T40 1 1 20 1 1 20 0 0 30 0 0 0
Table 5.16: TPG Representation Second Version.
44
Resource Allocation with GAs
5.2.5 Evaluation
As a result of the modification in the method of representing the TPG the new version
of the GA increased its performance considerably. The main reason for this fact is that
now every time that was necessary to check the dependencies of the project definition
the number of position consulted is exactly the number of dependencies plus the number
of tasks, which represents the positions where it is stored the number of dependencies
for every task. Whereas, in the previous version it was necessary to evaluated the whole
matrix in order to obtain the same information.
5.2.5.1 New Parent population
In this new version of the GA the parent population generated in every iteration of
the algorithm is composed in the following way. First using the method of selection of
binary tournament and the two-point crossover operator individuals of the old parent
population are selected to create the children population. After that, those individuals
are mutated and in this point there are two complete populations: old parent population
and children population. The top 10 individuals, those which have better fitness function
evaluation are copied directly to the new parent population. Then binary tournament is
again performed between the non-top ten individuals of the old parent population and
the non-top ten individuals of the children population until the new parent population
is completed.
5.2.5.2 Results
The scenario used in this version to analyse the results is again the Sony project. This
allowed to compared the results and decide which of all the algorithms and its different
versions is better obtaining a shortest completion time.
Table 5.17 shows very similar results regarding the completion times obtained in the
second version of the Classical GA and showed in Table 5.14. In order to have a clear
idea it can be observed in Table 5 that the average results in this version is better than
in the rest tested so far.
This new version of the Classical GA as all the table and figures of this sections illustrated
achieved the best results.
45
Resource Allocation with GAs
Run FF Evaluation(100000 evaluations)
1 563.4672 563.3333 565.0834 558.8175 564.4176 567.0677 553.1178 552.7509 562.86710 566.58311 562.41712 563.26713 565.73314 560.21715 563.41716 563.33317 572.25018 563.16719 557.00020 567.66721 563.26722 562.93323 563.53324 565.26725 560.75026 562.66727 563.00028 563.00029 563.26730 558.467
Table 5.17: Sony project results for Classical GA V3. 100000 evaluations.
Non-Classical GA V1 Non-Classical V2 Classical GA V1 Classical GA V2 Classical GA V3(100000 evaluations) (100000 evaluations) (100000 evaluations) (100000 evaluations) (100000 evaluations)
575.728 594.887 624.428 566.587 562.737
Table 5.18: Average Non-classical GA V1 and V2 and Classical GA V1, V2, and V3.100000 Evaluations
46
Resource Allocation with GAs
Figure 5.10: Comparison Average Non-classical GA V1 and V2 and Classical GA V1,V2, and V3. 100000 evaluations.
5.3 Conclusion
The results collected in the development of this chapter can be essentially divided in to
two main groups. First, the data obtained in the application of the Non-classical GA
and second, the information gathered in the application of the Classical GA.
The initial results of the first version of the Non-classical GA were better than the ones
obtained in the second version according to all the tables and figures of the section 5
of this paper. Therefore, it did not make sense to keep developing this non-classical
algorithm.
In spite of the fact that the data collected in the first version of the Classical GA was
notably discouraging, the changes made in the third version allowed to generate the
best solutions of all the algorithms in all the different versions. This certainty is clearly
reflected in the Figure 5.10.
In conclusion, despite the last version of the classical GA shows encouraging results it
has to be taken into consideration that in none of the different GAs and scenarios it was
possible to obtain a unique best solution to the different problems or projects posed.
Hence, it was decided to use the possibility of establishing an average for the benchmark
of the optimal resource allocation. This corresponds to the third stage of the model
produced in the section 4 of this paper.
47
Chapter 6
SensitivityAnalysis
This chapter of the paper explains and details the study of sensitivity analysis performed
in the process of breaking dependencies. Therefore, it describes the method carried out
to break the dependencies, which are defined by the TPG, in the definition of a project.
For this purpose, four projects based on real data were used as a source of information.
Nevertheless, the data provided in those project in terms of duration and dependencies
was a adapted by a process described in the section 6.1 of this paper.
The process of sensitivity analysis performed basically consisted in removing one by one
all the possible dependencies and run the GA developed in the section 5.2.3 of this paper.
After that, the results of both executions are compared in order to try to establish a list
of the most sensitive dependencies as well as other information which could be relevant
in the management of the scheduling of the project. A case in point is how affect the
variation in the availability of resources at the same time that dependencies are broken.
This could lead to corroborate a list of most sensitive dependencies in a project definition
without being affected by the other parameters considered. In addition, it might give
access to information of the intrinsic behaviour of the project such specific impact of
one particular group of dependencies over the completion time of the entire project.
The implementation developed basically traverse the TPG suppressing each dependency
and then run thirty times the third version of the GA detailed in the section 5.2.3 of
this paper. The average of these thirty executions is taken into consideration as the
completion time for the project definition without that particular dependency. The
results obtained are analysed by comparing them with the average of thirty executions
of the same GA using the original TPG with all the dependencies.
48
Sensitivity Analysis
6.1 Methodology to adapt data
In order to adapt the original data provided in MS Project format, to be clearly repre-
sented in the structures of the implementation developed, it was necessary to generate
a methodology of transformation.
This process of transforming the source data can be divided in two main parts. The
first part consisted in removing the ids which represented a set of tasks and not a task.
The second part was focused on reducing the number of dependencies by removing those
which are redundant.
In the first stage of this approach of removing dependencies all the ids which identify
a group of tasks are eliminated. This operation produces a new list of ids for all the
tasks which really have duration, but at the same time involves the redefinition of the
dependencies. A complete process example is explained in the tables 6.1, 6.2, 6.3, and
6.4. Where Table 6.1, shows the original data. As it can be appreciated there is a
column named Task (Id) which contains the id of the tasks that compounds the group
denominated Group (Id). As a result, the group need to be removed and the id of
the task are restated from 1, naming only real tasks that are going to be assigned to
resources. At the same time, if following tasks are dependant in this group id, which
is composed by various task ids, the new dependency is represented by the id of the
tasks that form that group. This process is reflected in Table 6.2. The final definition
for a project will be the composed by the columns which store the new id and new
dependencies as illustrated in Table 6.3. It has to be taken into consideration that
this process was performed trough different levels since a group can be constituted by
subgroups and those by subsubgroups until tasks are reached.
Group (Id) Task (Id) Dependencies1 - -- 2 -- 3 24 - -- 5 1
Table 6.1: Original project definition.
The second stage of this process of adapting the data resides in regrouping and removing
non-necessary dependencies. This procedure has to be performed in combination with
the first stage in certain situations when project definition is adapted. By non-necessary
dependencies it is considered those which are already defined indirectly by other. An
example is displayed in the table 6.3, where the task 3 due to this process of removing
group depends now on task 1 and task 2. However the dependency between task 3 and
49
Sensitivity Analysis
Old Id New Id Composition (Old Id) Old dependencies New dependencies1 - 2,3 - -2 1 - - -3 2 - 2 14 - 5 - -5 3 - 1 1,2
Table 6.2: Transformation project definition table.
Id Dependencies1 -2 13 1,2
Table 6.3: Adapted project definition.
task 1 is redundant since task 3 depends on task 2 which in turn depends on task 1.
Thus, the final project definition would have only two dependencies as shown in Table
6.4.
Id Dependencies1 -2 13 2
Table 6.4: Final project definition.
It is considerably important to highlight that these process of adapting the data and
the following process of removing indiscriminately dependencies could lead to work in
non-logical scenarios or even non-possible solutions. For example in the previous exam-
ple illustrated which final project definition was Table 6.4, if the process of removing
dependencies eliminates the dependency between task 3 and task 2 it also entails loosing
the dependency between the task 3 and the task 1.
6.2 Project defintions
This section of the paper describes the specification of the four projects that are going to
be used in the process of sensitivity analysis. The source of this data is four real projects
and therefore, the information used in these implementations gain special importance,
since utilising real data add considerable value to the results collected and analysed.
A brief explanation of the origin of the projects as well as a concise description of them
is given in order to understand the context of the subjects used in this process of testing
the impact of removing dependencies for the sensitivity analysis. Moreover, for each
50
Sensitivity Analysis
of these projects it is going to be specified the number of tasks and the number of
dependencies before and after the process of adaptation.
Before adaptation After adaptationTasks Dependencies Tasks Dependencies
Project 1 148 81 107 83Project 2 140 103 106 103Project 3 95 66 78 168Project 4 129 94 92 93
Table 6.5: Projects definition.
6.2.1 Project 1: CutOver
There was not possible to provide a description of the project.
6.2.2 Project 2: Database
The project purpose was database upgrade procedure. It consisted in a migration from
the Oracle version 9g to 10g. In addition, the upgrade affected 70% of the internal
applications, since a considerable number of them relied on Oracle Forms. There were
different layers of the organisation involved including DBAs, BSAs, developers and users.
Furthermore, the project also included the training of the stuff for the new features of
the system.
6.2.3 Project 3: QuotesToOrder
The aim of this project was an enhancement of the internal structure of the company.
The main parts affected on many different levels were the website, most internal applica-
tions and their integration. In addition, as part of the project there were tasks involving
the training of the future users of the new parts of the system.
6.2.4 Project 4: SmartPrice
This project consisted in a supply chain enhancement of medium size affecting mostly
the website as well as a few internal applications.
51
Sensitivity Analysis
6.3 Sensitivity Analysis Methodology
The procedure used in this process is known as sampling-based. This approach lies on
executing the model repeatedly with all the possible combinations. In this case, the
main aim is removing in turns all the dependencies which define the TPG of the project.
The model developed considers three different parameters: tasks, dependencies, and
resources. The first one, duration of the tasks is fixed and we study the impact of mod-
ifying the second one, dependencies. Therefore, there is a third input factor, resources,
which feeds the model that can be altered to analyse whether by varying it the behaviour
of the model describe a certain pattern. In this sense, with this practice the observation
of the results collected can add more reliability of the sensitivity of particular depen-
dencies. In so doing that, it was evaluated if the list of most relevant tasks were always
the same with a different resource allocation.
For all the different experiments it was decided to run the GA in a loop of 1000 iterations
generating a population of 100 individuals in each of the iterations. In addition, the
number of top individuals kept for not loosing best fitness function evaluations were
10% of the size of the population.
The procedure keep a simple but concise methodology detailed following:
1. Calculate the average of running 30 times the original TPG.
2. Establish this average as benchmark to compare and therefore, it was considered
the 100 % completion time.
3. In turns, remove one by one all the dependencies which define a project and cal-
culate the average of running 30 times the algorithm with the TPG without that
particular dependency.
4. Compare the results regarding the benchmark previously established.
6.4 Sensitivity Analysis Results
This section displays the results obtained in the process of removing dependencies in
the four real projects detailed in the section 6.2 of this paper. The main purpose of this
action is to perform an analysis to assess the impact of the most sensitive task in terms
of reducing the overall completion time of the project.
52
Sensitivity Analysis
For each of the projects previously detailed a series of four different tests were performed.
The difference between the tests lies on the composition and number of resources avail-
able to be assigned to tasks. From now and on in this paper the set of experiments run
will be referred as Test 1, Test 2, Test 3, and Test 4. The composition and number of
those tests are as follows:
• Test 1: 3 teams and 12 people
– Team 1: 3 people
– Team 2: 4 people
– Team 3: 5 people
• Test 2: 10 teams and 10 people (1 person per team)
• Test 3: 6 teams and 6 people (1 person per team)
• Test 4: 3 teams and 3 people (1person per team)
In each of this test one graph is shown. The information represented corresponds to the
normalisation of the average completion time of running 30 times the Classical GA in
its third version, section 5.2.3.
The graph illustrates the normalisation of the data collected. For this purpose, the
benchmark or original TPG of the first graph is establishes as 100% of the completion
time. This graph represents the difference of the completion time of removing in turns
all the dependencies regarding the benchmark. The results obtained are ordered in
increasing order of completion time.
6.4.1 Results Project 1
The configuarion of the original TPG for Project 1 is:
• Number of tasks: 107
• Number of dependencies: 83
The results obtained for Project 1 and the set of test are displayed in the following
figures:
• Test 1 (3 teams with 3, 4 and 5 people): Figure 6.1
53
Sensitivity Analysis
• Test 2 (10 teams with 1 person each): Figure 6.2
• Test 3 (6 teams with 1 person each): Figure 6.3
• Test 4 (3 teams with 1 person each): Figure 6.4
Figure 6.1: Project 1. Normalisation Test 1 (3 teams with 3, 4 and 5 people).
Figure 6.2: Project 1. Normalisation Test 2 (10 teams with 1 person each).
As it can be appreciated it in the graphs of the four different tests, although the model
was able to decrease the completion time by removing certain dependencies it also
achieved an increase. In spite of the fact that theoretically this solution is impossible, it
is not unreasonable within the context of our development. Logically if one dependency
54
Sensitivity Analysis
Figure 6.3: Project 1. Normalisation Test 3 (6 teams with 1 person each).
Figure 6.4: Project 1. Normalisation Test 4 (3 teams with 1 person each).
is removed the overall completion time should not be greater than the one obtained af-
ter processing the original TPG. Nevertheless, the genetic algorithm developed and used
for this implementation is not always able to obtain a unique optimal solution for the
resource allocation. As a result, this GA produces near optimal solutions in a process of
approximation. Therefore, it is possible that removing one particular dependency there
is not improvement at all in the completion time for the project analysed. This increase
can be attributed to the fact that removing one particular dependency modifies the
landscape that the GA is working on. Furthermore, withdrawing certain dependencies
could result in the algorithm converging to a local optima, even getting stuck to it. Since
55
Sensitivity Analysis
with the GA developed it is not possible to ensure a global optima solution in all the
scenarios. Thus, that changing the landscape can lead to more difficulty at searching
and finding better solutions rather than the stochastic variance of the GA.
It is remarkable to mention that for Test 1 illustrated in Figure 6.1 nearly half of the
total dependencies produced an increase in the completion time. Similar behaviour was
obtained for Test 3 depicted in Figure 6.3. The results got worse running the experiments
for Test 4, Figure 6.4. This situation was aggravated when the results for the Test 2
were collected. As it can be observed in Figure 6.2 approximately three quarters of
the dependencies removed incurred in an increment. Hence, from this project no clear
assumption can be made regarding the impact of playing with the resources available,
which is the third parameter that defines the scenario for the model.
As a last observation in the results analysed for the four different tests in this project,
it can be stated that the decrease in the completion time in the best situation is always
greater than the increase in the worst case. In all the tests performed the greater decrease
varies from slightly more than 4% to nearly 5%. Whereas, in all the tests completed the
greater increase never exceed the 3%, Figure 6.1, Figure 6.2, Figure 6.3, and Figure 6.4.
It was decided to perform a series of statistical analysis in order to clarify whether
these results can be considered reliable due to the facts described at the beginning of
this section and taking into consideration the similarity in the results collected. All
the techniques used, a briefly description of them and the conclusion deduced from the
results are fully detailed and explained in the section 6.5 of this paper.
6.4.2 Results Project 2
The configuarion of the original TPG for Project 2 is:
• Number of tasks: 92
• Number of dependencies: 93
The results obtained for Project 2 and the set of test are displayed in the following
figures:
• Test 1 (3 teams with 3, 4 and 5 people): Figure 6.5
• Test 2 (10 teams with 1 person each): Figure 6.6
• Test 3 (6 teams with 1 person each): Figure 6.7
56
Sensitivity Analysis
Figure 6.5: Project 2. Normalisation Test 1 (3 teams with 3, 4 and 5 people).
Figure 6.6: Project 2. Normalisation Test 2 (10 teams with 1 person each).
• Test 4 (3 teams with 1 person each): Figure 6.8
The results obtained in this new project revealed interesting information. Performing
Test 1 and Test 4 we can appreciated as well as in Project 1 that there is an increase as
well as an decrease. However, for Test 2 and Test 3 only there is only reduction in the
completion time when the dependencies are removed. The availability of resources may
be partly responsible for this behaviour. Since both tests allows the model to dispose
of a large number of teams 6 and 10 respectively. As a result, it might be possible
that there is always one team available to perform a task. This phenomenon can be
57
Sensitivity Analysis
Figure 6.7: Project 2. Normalisation Test 3 (6 teams with 1 person each).
Figure 6.8: Project 2. Normalisation Test 4 (3 teams with 1 person each).
corroborated by the fact that in both cases Test 2 and Test 3 the completion time is
exactly the same 201 days. Thus, the availability of teams could have an essential effect
on the completion time.
The intrinsic nature of the project definition and the TPG can be an important cause
in the ability of the GA to obtain a global optima solution. It seems that for this par-
ticular project the best solution processing the original TPG is 201 with this particular
availability of resources. As a result, during the process of removing dependencies it is
always obtained this value or a smaller one.
58
Sensitivity Analysis
In addition, there is one a new conduct in the completion times for the results of this
project in Test 1 and Test 4 which are illustrated by Figure 6.5, and Figure 6.8. In
spite of the fact that there is a similar percentage of increase in the completion time,
regarding the results of Project 1, when certain dependencies are omitted from the TPG,
the decrease in notably superior. As shows Figure 6.5 the decrease can achieve nearly
20% of reduction, whereas the increase never reaches 5%. In the case of the Test 4 the
reduction of the completion time exceed 20% and the increase again never reaches 5%,
6.8.
The situation previously described probably indicates that those dependencies which
produce a minor increase do not have real impact of the completion time of the project,
whilst the ones which produce that significant improvement could be considered ex-
tremely sensitive. To ensure that it was compared if all the top ten dependencies where
are able to reduce the completion time in the greatest proportion were the same for all
the tests. In order to establish that comparison those top ten dependencies were ordered
in increasing level of completion time and represented in Table 6.6. The cells contain
the index of the tasks which are dependant. The table displays a considerable similarity
with slight differences between the tests. For example the dependency between the task
96 and the task 97 appears as Top 1 dependency in the tests 2, 3, and 4 and as Top 3
in the test 1. In the case of Test 2 and Test 3 the top 10 most sensitive dependencies
are exactly the same and its importance measured by the impact that they produce is
also the same. Every dependency obtains the same order in the top 10 in both tests
as it is shown in the table. Therefore, the behaviour that those tests produced in the
model seems to have the same pattern. They have the same global optima solution in
201 days, they never produced increase by removing dependencies, they achieve similar
reduction in the completion time, and they have exactly the same top 10 most sensitive
dependencies. In the rest of the cases there is a significant number of coincides in the
most sensitive tasks as well as the importance of their impacts with a little variation
in the results for Test 1. Furthermore, it is plausible to believe that the differences are
affected by the composition of the teams or configuration of the third parameter of the
model. Nevertheless, this could emphasize the consideration that even modifying the
resource allocation the importance of the certain set of dependencies remains.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 90-91 98-99 97-98 99-100 102-103 89-90 100-101 101-102 91-97 85-86Test 2 97-98 98-99 91-97 90-91 89-90 88-90 99-100 87-88 86-87 85-86Test 3 97-98 98-99 91-97 90-91 89-90 88-90 99-100 87-88 86-87 85-86Test 4 97-98 89-90 90-91 91-97 98-99 99-100 88-89 87-88 101-102 85-86
Table 6.6: Top 10 dependencies Project 2. The content represents the indexes betweenthe two tasks which compose the dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
59
Sensitivity Analysis
This fact could lead to the idea of having accomplished certain level of success, pos-
itive and encouraging results measuring the sensitivity of the dependencies. It is not
unreasonable to think that valid and demonstrable solutions would be achievable if it
is possible to developed GA with enough power and capacity to cover the complete
landscape of the scenarios of a project definition.
Nonetheless, there is also a possible explanation about the enormous decrease in the
completion. As it can be detected in Figure 6.5, Figure 6.6, Figure 6.7, 6.8 the reduction
reach almost 20%, 50%, 40%, and 20% respectively. It might be possible that breaking
these particular dependencies other important are also lost due to the process of adapting
the data and the issue described in the section 6.1 of this paper. Nevertheless, this fact
does not necessarily involve a lack of validity of the results obtained. In the case that
a set dependencies was removed and lost during the methodology it could entail that a
dependency which is referred to a group of tasks is sensitive. Hence, it would require
to study more deeply the impact of that group of tasks. Consequently, it still indicates
that a dependency or set of dependencies associated to a task or a particular group of
tasks might reduce the overall completion time of the project if they are removed.
This statement is the main focus of this research, since every project has a complete
different nature. Then the project manager would be in a position to decide whether
that dependency or set of dependencies can be broken in the real world. Therefore,
the supervision of the project manager or the person responsible of the management of
the project is absolutely necessary to apply the data and results collected in the real
development of the project.
Nevertheless, it has to be taken into consideration that the rest of the factors which
classically define the PSP, detailed in the section 2 of this paper and that they have
been discarded, could modify the results. Yet, as it has been mentioned previously
and according to the results obtained overall in Test 2 and Test 3 despite varying the
third parameter of resources the top 10 most sensitive tasks remains exactly the same.
These promising results encourage thinking about positive future if a deeper research
is performed. As a result, it would be extremely interesting to develop a model able to
cope with all these parameters such as skills, cost, effort, and so on.
6.4.3 Results Project 3
The configuarion of the original TPG for Project 3 is:
• Number of tasks: 78
• Number of dependencies: 168
60
Sensitivity Analysis
The results obtained for Project 3 and the set of test are displayed in the following
figures:
• Test 1 (3 teams with 3, 4 and 5 people): Figure 6.9
• Test 2 (10 teams with 1 person each): Figure 6.10
• Test 3 (6 teams with 1 person each): Figure 6.11
• Test 4 (3 teams with 1 person each): Figure 6.12
Figure 6.9: Project 3. Normalisation Test 1 (3 teams with 3, 4 and 5 people).
Figure 6.10: Project 3. Normalisation Test 2 (10 teams with 1 person each).
61
Sensitivity Analysis
Figure 6.11: Project 3. Normalisation Test 3 (6 teams with 1 person each).
Figure 6.12: Project 3. Normalisation Test 4 (3 teams with 1 person each).
The results collected and represented in the Figure 6.9, and Figure 6.12 show a pattern
of behaviour which could be situated between the results of Project 1 and Project 2.
There were increases in all the tests performed to a greater or lesser extent. Yet, as it
happened in previous results the increments in the completion time are always consid-
erably smaller than the reductions produced by breaking certain dependencies. In this
particular project the increases never reach 6% of the original completion. Although,
this number entails an increase of almost 1% regarding the two previous projects as the
previous test it might be produced by the nature of the GA. In spite of the fact that
62
Sensitivity Analysis
this statement cannot be undoubtedly validated, it might be possible to considere that
this effect is produced as a result of the limited capacity of the GA already mentioned
in the section 6.4.1. As it is mentioned in that section, there is likely to be a problem
with respect to the average produced after thirty runs of the algorithm.
The availability of resources one more time seems to be partly responsible in those
increments. When the availability of the resources is the greatest, running Test 2 Figure
6.10 there is null increase for every dependency broken. And the greater number of
increments corresponds to the tests with smaller availability of resources Figure 6.9 and
Figure 6.12.
It was constructed again the table with the top 10 more sensitive dependencies in order
to verify if the sensitivity of the dependencies were affected by the composition of the
teams. This fact could decreases the validity of the results obtained in Project 2. Despite
the results obtained and illustrated in Table 6.7 showed more variance in terms of which
dependencies are more sensitive in every test, it still remains relative similar between
the tests. For instance, the dependency between the task 5 and the task 6 remains as
top 1 dependency in Test 2, Test 3, and Test 4. Another example is the dependency
between the task 6 and the task 8 that appears in all the test performed.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 8-9 66-67 15-56 74-75 24-54 5-6 9-12 6-8 75-76 17-56Test 2 5-6 3-5 2-3 1-2 6-8 8-9 65-71 9-65Test 3 5-6 6-7 73-74 3-5 59-60 8-9 6-8 48-66 34-35 36-37Test 4 5-6 6-8 8-65 8-9 6-7 74-75 75-76 7-10 10-12 24-28
Table 6.7: Top 10 dependencies Project 3. The content represents the indexes betweenthe two tasks which compose the dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
The second test only displays 8 dependencies because there was not found other de-
pendencies able to reduce the completion time. Therefore, the variability in the third
factor that defines the model could have a greater importance over the sensitivity of
the dependencies than it was mentioned in the results remarked in Project 2, section
6.4.2. Yet, this fact does not entail that it is not possible to present a list of sensitive
dependencies that by removing could produce a considerable reduction in the overall
completion time of the project. Moreover, it would be possible to feed the model with
the desired configuration for a particular project to evaluate the dependencies and their
impact.
In this project the decrease and increase indicated in Figure 6.9 and Figure 6.12 for Test 1
and Test 4 seem to show almost identical results regarding the original overall completion
time of the project establish as 100% benchmark. Hence, it can be understood that
63
Sensitivity Analysis
under specific circumstances the resources are always busy and removing one particular
dependency make no difference at all. Yet, this phenomenon does not involve that
the impact of that particular dependency could not lead to a significant reduction in
the completion time with other resource configuration. In other words, the completion
time of a project is limited by the resources available but the importance in terms of
sensitivity of one or more dependencies could be used in the adequate scenarios.
The reduction in the completion time achieved in Test 2 and Test 3 depicted in Fig-
ure 6.10 and Figure 6.11 for the first dependency broken obtained approximately 31%
and 20%. It can be appreciated that the same dependency produced this effect if this
information is combined with the one provided in Table 6.7. In the case of the Test
4 illustrated in Figure 6.12 the percentage of decrease for this particular dependency
exceed 4%. Nevertheless, the same graph displays a considerable number of increments
in the completion time.
In conclusion, even though the results analysed do not show as strong evidences as the
ones evaluated in the section 6.4.2 of this paper for Project 2, it is still possible to
recognise certain similarities in the patterns of behaviour. Moreover, when the data do
not corroborate thoroughly the impact of the most sensitive dependencies there still is
enough reasonable proof to justify the conduct of the response of the model. Thus, it
rational and sensible to believe that the implementation developed is reviling interesting
results in the direction of the focus of this research.
6.4.4 Results Project 4
The configuarion of the original TPG for Project 4 is:
• Number of tasks: 92
• Number of dependencies: 93
The results obtained for Project 4 and the set of test are displayed in the following
figures:
• Test 1 (3 teams with 3, 4 and 5 people): Figure 6.13
• Test 2 (10 teams with 1 person each): Figure 6.14
• Test 3 (6 teams with 1 person each): Figure 6.15
• Test 4 (3 teams with 1 person each): Figure 6.16
64
Sensitivity Analysis
Figure 6.13: Project 4. Normalisation Test 1 (3 teams with 3, 4 and 5 people).
Figure 6.14: Project 4. Normalisation Test 2 (10 teams with 1 person each).
The results obtained in all the tests performed over the Project 4 reinforce the ability of
the model to suggest and probably identify the most sensitive dependencies. In addition,
in this case the solutions which produce an increase over the original completion time
are considerably few.
The reductions in the completion time for all the tests always exceed 10% and in the case
of the Test 2 and Test 3 the 20%. This statement is illustrated in Figure 6.13, Figure 6.14,
Figure 6.15, and Figure 6.16. Therefore, the model was able to decrease significantly
the establish benchmark in different percentage with all the different configurations of
65
Sensitivity Analysis
Figure 6.15: Project 4. Normalisation Test 3 (6 teams with 1 person each).
Figure 6.16: Project 4. Normalisation Test 4 (3 teams with 1 person each).
the resources. This phenomenon is only produced in this scenario and would represent
the ideal behaviour that this research is trying to identify. As a result, it is reasonable
to think that a deeper analysis of the parameters that compose the model could lead to
reveal not only the increments produce in certain dependencies, but also the validity of
model and its focus.
It is interesting to emphasize that if the results are observed in a particular order by
looking at the results displayed in performing Test 2, Test3, Test4, and Test 1 seems to
appear a unique pattern of behaviour. As the number of teams decreases the reduction
66
Sensitivity Analysis
times tend to level off to the benchmark. Furthermore, there seems to be specific set of
dependencies which produce exactly the same reduction in the completion time, Figure
6.14 and Figure 6.15. This situation was not encountered in the previous projects and
might be caused by the critical position of certain tasks and its surrounding depen-
dencies. Hence, removing one of those dependencies could have a direct effect on the
sensitivity of that task over the completion time of the project.
The top 10 dependencies of the tests were studied in order to clarify partly the results
previously mentioned. For this purpose the top 10 dependencies were illustrated in
Table 6.8. The conclusion achieved is that despite the position varies the most sensitive
dependencies for all the tests are almost exactly the same. Thus, it is sensible to believe
that the configuration of the resources does not have direct impact over the sensitivity
of the dependencies, yet it can affect the reduction in the completion time of the project
removing dependencies. This assumption is absolutely logical since the lack of resources
as unconditional factor of the PSP can affect the completion time of the project in the
original TPG.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 52-53 51-52 21-46 50-51 20-21 48-49 46-48 49-50 55-56 9-10Test 2 20-21 21-46 46-48 48-49 49-50 50-51 51-52 52-53 10-20 9-10Test 3 49-50 50-51 51-52 52-53 20-21 48-49 46-48 21-46 10-20 9-10Test 4 52-53 51-52 50-51 21-46 48-49 20-21 49-50 46-48 10-20 55-56
Table 6.8: Top 10 dependencies Project 4. The content represents the indexes betweenthe two tasks which compose the dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
Nevertheless, it is also true in this project it was obtained the greatest increments of
all the tests. As it can be appreciated in Figure 6.13 the majority of the dependencies
removes do not produce an increase but the last three ones resulted in an increment of
6%, 8% and 14%. According to the rest of the outputs and the limitations of the model
implemented and previously detailed this phenomenon could be attributed to reasonable
explanations.
To summarize, in spite of the fact of there were found significant increments, they can be
attributed as in previous cases to the circumscription of the GA and the model developed.
On the other hand, the positive reductions accomplished in all the tests as well as the high
level of parallelism between the top 10 dependencies in them demonstrated relatively
positive attainment in the direction of this research.
67
Sensitivity Analysis
6.5 Statistical Analysis
The results obtained in part of the test in the sensitivity analysis as well as the limitations
of the implementation could express certain reservations about the validity of the model
developed.
The responsibility for the increments obtained in the previous section were partly at-
tributed to the possibility not having real difference between the distributions of the
thirty executions and the same could be truth for the reductions in the completion. As
a result, it was decided to use statistics to add more reliability to the results collected.
For this purpose this section evaluates the distribution of the thirty runs of the top 10
dependencies of each test regarding the distribution of the thirty runs of the benchmark.
In so doing that, it would be adding certain level of validity by comparing whether the
distribution of both cases is genuinely different or not.
The idea behind this procedure is to clarify those situations where the reduction of the
completion time is not enough clear because there are also increments in similar pro-
portion but where the tables of the most sensitive dependencies have shown similarities.
Hence, the statistical analysis tries to validate the specific situations where the decrease
in the completion time could have been attributed to random results produce by the
model in that particular set of execution for the genetic algorithm. This fact is also
known as the stochastic variance of an algorithm. Nevertheless, the repetition of par-
ticular dependencies in the top ten list produced by the different tests for a concrete
project might reveal relative level of sensitivity in those dependencies.
The techniques used in these tests as well as the tools employed are detailed in the
following sections.
6.5.1 Statistical Techniques and Methodology
The rank sum test is the main technique used in this paper to compared the results of
the top 10 dependencies with the ones obtained using the original TPG. The rank sum
test is a non-parametric technique for assessing whether two sets of observations have its
origin in the same distribution. This test compares the two samples in order to test the
hypothesis that the sets of observations are not different. Every set corresponds to the
group of thirty executions of the algorithm. In this case, the difference between the sets
is the effect of removing a dependency, while the variance is the due to the stochastic
nature of the GA.
68
Sensitivity Analysis
The methodology to interpret the results of the rank sum test will be based on the level
of certainty of the output parameters produce. Rank sum test outputs a p-value that
indicates how likely the null hypothesis is to be true. The null hypothesis is that the set
of observations are from the same probability distribution. Therefore, a smaller p-value
indicates a larger degree of confidence that the hypothesis is incorrect. It is generally
believed that a threshold of 5% can be chosen to indicate a statistically significant
difference between sets of data, so that a p-value less than 5%. If the p-value is less than
5% for the rank sum test, then it can be assumed that removing the dependency makes
a statistically significant difference to the completion time found by the GA. In other
words, it is possible to state that the data before and after removing one dependency
are positively different with a 95% level of confidence. If the p-value is still under 10%
it could still claimed a moderately significant result.
6.5.2 Statistical Tools
R is the statistical software package that was used to perform all the statistical test
of this paper. This software for statistical computing and graphics is free and widely
accepted by the scientific community as a powerful tool to perform a broad range of
classical statistical test, linear and non-linear modelling, time-series analysis, and so on.
The rank sum test within R package is executed under the command wilcox.text{stats}.
6.5.3 Statistical Results
The statistical results of this research are analysed and divided in different sections
according to the different projects evaluated in the sensitivity analysis. In addition, in
every project the results are processed considering the information collected through the
four test performed.
The statistical results are represented using a table similar to the one used to indicated
the top ten most sensitive dependencies. Nevertheless, this time the table contains the
p-value returned by R after performing the rank sum test. In so doing that, it is possible
to add enough level of confidence in the result if there is a particular dependency which
appears several times in different tests but which percentage of reduction is relatively
small.
The data necessary to perform the statistical analysis for each project is completely
detailed in tables annexed in the section Appendix B of this paper. Furthermore, these
tables provide important information to understand the output of the rank sum test.
69
Sensitivity Analysis
Additional presumptions regarding the behaviour of the model can be made from the
information revealed in these tables.
6.5.3.1 Statistical Results Project 1
This project obtained the worst and more complicated results in the sensitivity analysis
of breaking dependencies according to the section 6.4.1.By worst and complicated results
it is understood the ones which produced the smallest reduction in the completion time
as well as increase in more cases than the rest of the projects
If the top ten dependencies represented in Table 6.9 are studied it is possible to appreciate
that despite it shows less number of coincidences between the test regarding the tables
of the other projects, it still has repetitions. For instance, the dependency between the
task 50 and the task 51 appears in all the tests. In addition, the dependency between
the tasks 49 and 50 occurred in three of the four tests. There are also other dependencies
that exist in at least two of the test such the pairs 101-107, 66-100, and 102-103.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 66-100 101-102 29-97 59-49 61-62 62-49 53-101 101-105 50-51 62-54Test 2 23-24 64-88 49-50 27-28 53-101 102-103 79-80 26-27 14-13 50-51Test 3 101-107 50-51 2-4 53-106 49-50 29-86 66-100 102-103 48-49 65-66Test 4 21-22 32-33 43-44 47-49 63-64 71-73 101-107 49-50 50-51 96-97
Table 6.9: Top 10 dependencies Project 1. The content represents the indexes betweenthe two tasks which compose the dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
It can be observed that when the completion time is reduced by more than 2% according
to Figure 6.1, Figure 6.2, Figure 6.3, and Figure 6.4 the top ten dependencies have
different distributions, even if the dependencies are coincident in more than one test or
not. Hence, it could be argued than in the cases when the impact of the dependency
broken is 2% or more of decrease in the completion the solution offered by the model is
reliable.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 1.14E-07 0.00003 0.00904 0.02260 0.00858 0.04664 0.03690 0.03565 0.05250 0.02550Test 2 2.362e-05 0.00763 0.02220 0.15920 0.15790 0.51610 0.43200 0.55210 0.55590 0.67320Test 3 3.875e-06 0.00011 0.00208 0.00910 0.02033 0.04225 0.04382 0.12520 0.10490 0.09356Test 4 0.03329 0.02589 0.07240 0.03882 0.02565 0.01425 0.00317 0.10750 0.18730 0.23160
Table 6.10: P-Value Rank sum test Top 10 dependencies Project 1. P-value returnedcomparing the distribution of running 30 times the GA with the original TPG andwith the TPG without the Top X dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
70
Sensitivity Analysis
Nevertheless, it still remains unclear the absolute validity of this information since the
dependencies do not always produce the same impact and differs between the tests. This
fact corroborated the data produced in Figure 6.1, Figure 6.2, Figure 6.3, and Figure
6.4.
To conclude, despite there seems to be certain threads of supposition there are not
enough evidences in the solutions provided by the model for this project to establish a
pattern of behaviour or statement over the ability to find the most sensitive tasks with
an absolute level of certainty.
6.5.3.2 Statistical Results Project 2
The statistical results for Project 2 and displayed in Table 6.11 show absolute confidence
in all the top ten dependencies in all the tests. Thus, it is possible to state that the
distribution of the thirty runs in the process of breaking dependencies performed during
the sensitivity analysis is absolutely different from the execution of the model with the
original TPG. As a result, it can be claimed that the differences in the average completion
times, at least for these top ten dependencies, is not a matter of casualty.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 3.33E-11 3.01E-11 3.33E-11 3.69E-11 6.06E-11 6.06E-11 1.61E-10 9.91E-11 9.90E-11 9.75E-10Test 2 9.77E-13 1.59E-13 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14Test 3 1.15E-12 1.16E-12 1.10E-12 9.07E-13 1.17E-12 8.82E-13 1.06E-12 9.38E-13 8.73E-14 1.06E-12Test 4 2.94E-11 2.90E-11 2.95E-11 2.95E-11 2.93E-11 2.91E-11 2.95E-11 2.93E-11 2.93E-11 2.95E-11
Table 6.11: P-Value Rank sum test Top 10 dependencies Project 2. P-value returnedcomparing the distribution of running 30 times the GA with the original TPG andwith the TPG without the Top X dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
The information collected through the rank sum test is not suppressing since the reduc-
tions of the completion time in this project proportion are greater than in the rest of
them. This information can be observed in the figures of the section 6.4.2 of this paper.
In summary, the results of the sensitivity analysis of the section 6.4.2 in addition to the
statistical ones acquire in this section positively shows integrity of the model and the
focus of this research in the process of measuring the sensitivity of the dependencies
beyond doubt for this particular project scenario.
6.5.3.3 Statistical Results Project 3
Except the top 8, top 9, and top 10 dependencies of the Test 1 the rest show absolutely
no doubt about the difference between the distribution. Therefore, the statistical results
71
Sensitivity Analysis
for Project 3 add more reliability to idea of a successful beginning in the pursuance of
identifying the most sensitive dependencies trough the use of GAs.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 0.001893 1.83E-03 1.19E-02 9.03E-03 8.25E-03 6.88E-02 1.35E-02 2.17E-01 1.07E-01 1.31E-01Test 2 2.01E-13 1.69E-14 1.69E-14 1.69E-14 1.47E-09 1.83E-08 2.85E-04 4.18E-02Test 3 1.52E-11 1.33E-10 3.33E-08 3.84E-04 2.00E-07 2.85E-05 2.65E-05 6.80E-04 9.67E-04 2.71E-03Test 4 5.29E-06 1.84E-05 4.37E-03 3.04E-03 1.09E-02 3.89E-02 2.87E-02 2.34E-02 2.20E-02 6.14E-02
Table 6.12: P-Value Rank sum test Top 10 dependencies Project 3. P-value returnedcomparing the distribution of running 30 times the GA with the original TPG andwith the TPG without the Top X dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
The output of the rank sum test for this project illustrated in Table 6.12 describe positive
achievement even when the reduction of the completion time is smaller than 2%. This
statement can be observed by the combination of the data of Table 6.12 and Figure 6.9.
In this case, for Test 1 only the top 1 dependency was able to accomplish a decrease
greater than 2%, yet from the top 2 to the top 7 all the dependencies have a different
distribution with a level of confidence of 95% regarding the original TPG.
To summarise, in spite of the fact that the results of the first project were not very concise
and the limitations of the model represented by certain increments in this project as well
as in Project 2, the results in both of them in the sensitivity analysis and the statistical
corroboration encourage believing a breakthrough.
6.5.3.4 Statistical Results Project 4
The results for the statistical tests performed for this project and displayed in Table
6.13 show the expected output taking into consideration the reduction completion time
achieved by the model. The statistics evidenced absolute level of confidence for all the
dependencies in all the tests as it occurred in Project 2.
Top 1 Top 2 Top 3 Top 4 Top 5 Top 6 Top 7 Top 8 Top 9 Top 10Test 1 2.99E-11 2.99E-11 3.00E-11 2.99E-11 2.99E-11 2.99E-11 3.66E-11 2.99E-11 2.99E-11 2.97E-11Test 2 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14 1.69E-14Test 3 1.69E-14 1.69E-14 1.69E-14 1.69E-14 2.71E-14 2.71E-14 4.15E-14 1.19E-13 1.69E-14 1.69E-14Test 4 7.30E-13 9.30E-13 9.43E-13 9.49E-13 8.38E-13 8.62E-13 8.54E-13 8.76E-13 9.24E-13 9.88E-13
Table 6.13: P-Value Rank sum test Top 10 dependencies Project 4. P-value returnedcomparing the distribution of running 30 times the GA with the original TPG andwith the TPG without the Top X dependency. Test 1 resource composition: 3 teams(3,4,5 people). Test 2 resource composition: 10 teams (1 person). Test 3 resource
composition: 6 teams (1 person). Test 4 resource composition: 3 teams (1 person).
The statement previously mentioned in addition to the results and the statistics of
Project 2 and Project 3 demonstrate that the model developed is able to find in the
majority of the cases the sensitive tasks.
72
Sensitivity Analysis
To conclude, the model revealed almost perfect behaviour processing the scenario of this
project. There were extremely few cases that produced increase in the completion time,
and the cases that produce reduction exhibited a considerable level of similarity as well
as complete confidence in the statistical outputs.
6.6 Threats to Validity
The use of search-based software engineering and particularly the development of GAs
to perform sensitivity analysis involves risk points. Following, this section details the
main key points which could lead to threat the validity of this research:
• The model developed is limited finding solutions when the scenario proposed entails
a considerable number of tasks and dependencies. In those cases, it is only possible
to approximate solutions, yet it provides significant candidate individuals. In
addition, the model only covers three parameters whereas the classical PSP is
defined taking into consideration a greater number of them. Therefore, the results
collected could be affected by the introduction of those parameters. Furthermore,
the fitness function evaluated is not perfect as it is detailed in the section 4.1.2 of
this paper. Hence, the implementation of an ideal fitness function could be very
complicated.
• The process of adapting the data could mask possible dependencies as it is ex-
plained in the section 6.1 of this paper. Yet, the process has been designed logically
to allow identifying dependencies which could lead to the most sensitive tasks or
group of tasks.
• The lack of certainty in the explanation over the results collected for Project 1
in the sensitivity analysis as well as in the statistical test adds certain level of
reticence to the model developed. However, it is possible to believe a reasonable
explanation through the limitation of the model in addition to the composition of
the resources for the test and the duration of the tasks.
• The use of genetic algorithms to tackle the classical PSP does not guarantee find-
ing a solution for the resource allocation. Particularly if the scenario raised tries
to cover all the possible parameters involved the project management. The com-
plexity in that situation increases the difficulty not only to generate solutions or
candidate individuals due to the different factor and constraints that should be
taken into consideration, but also the computational cost as well as the high prob-
ability of being only able to approximate solutions. The fact of the algorithm
73
Sensitivity Analysis
converging to a local optima is likely to happen, yet it still can reveal hints and
could lead to identify the most sensitive dependencies. The computational cost it
is an engineering problem that might be resolved by the use of different techniques,
or programming languages, or similar approach or might not be.
In spite of the fact that the approach introduced in this paper and the techniques used
as well as the model proposed present relative level of weakness, the literature survey
and the results collected encourage to believe that those barriers can be overcome.
6.7 Discussion
This section emphasis the most important points that should be discussed regarding
the results collected in the application of the model developed to the different scenarios
raised.
The results obtained showed that the idea behind this paper could be in the right
direction towards a complete process of improving the PSP for the managers. In spite
of the fact that the solutions produced by the model in the different test for the first
project reveal certain level of failure, the information analysed for the rest of the projects
and the corroboration of the statistical results probably mean relative degree of success.
It is also necessary to analyse in a general way what the results obtained in the section
6.4 and the section 6.5 tell us about the projects. The results collected in Project 1
showed lack of certainty identifying the most sensitive dependencies. In spite of the
fact, that there were coincidences between the Top 10 dependencies for the different test
illustrated in Table 6.9, the truth is that they hardly fit. Furthermore, the statistical
analysis cannot corroborate part of these cases. In conclusion, it is very unlikely to
ensure for this project which are the most sensitive dependencies.
However, the outcomes obtained in the application of the model developed for Project 2
and Project 4 resulted in exactly the main goal of this project. Not only the process of
removing dependencies almost never reached increments and on the contrary was able
to generate considerable reductions in the completion time. Also, the analysis of the
top ten dependencies for both projects had a high level of similarity and an absolute
verification statistically. Therefore, the model in these projects exhibited undeniable
capacity. In conclusion, it would be possible to state that in these particular projects it
is possible to indentify certain sensitive dependencies.
The results gathered for Project 3 are not as positive as the ones for Project 2 and Project
5, but they still presented relative level of success. Analysing the top ten dependencies,
74
Sensitivity Analysis
at least 3 of them appeared in all the tests. Nevertheless, it is also truth that in one of
the cases cannot be corroborated by the statistical test performed. In general, it could
be claimed that for this particular project it is possible to identify few dependencies that
are sensitive in almost every scenario. At the same time and as well as in Project 2 and
Project 4, there are dependencies which can be identified that could generate a massive
reduction in the completion time.
In addition, despite the results collected for Project 1 it is possible to establish certain
level of coincidence in the results gathered for Project 2, Project 3, and Project 4.
Thus, the similarities in these three projects allow identifying patterns of behaviour
in the different test performed. Since, the top ten dependencies in the different test
showed considerable degree of coincidence. However, it still remains unclear why there
are various differences between the tests. This fact can be partly attributed to the
diverse configuration of the resources available, although it cannot be completely assure
to this factor.
The next point to take into consideration is if the manager can use and trust the in-
formation provided by this model. Regarding the first point, it is undoubtedly that the
information about the most sensitive tasks could be used by the project manager. Al-
though, this does not necessarily means that can be applied. Since, the model developed
does not understand the complexity of every project and the importance of each depen-
dency. Therefore, the list of most sensitive tasks can be also the list of the most critical
or crucial tasks, and as a result they cannot be removed. The second aspect about
trusting the solutions produced by the model is more delicated to deal with. There is
not manner to provide 100% confidence to the model developed. Nevertheless, the fact
that the model has been applied to real project in addition to the statistical analysis
performed as well as the strong foundations on which is based on allow to consider the
results reliable, feasible, and solid.
Moreover, it is also truth that there is an emergent necessity to improve and enhance
the model. In so doing that, it would be possible to cover the rest of the parameters
and aspects of the PSP not considered. Furthermore, this fact would add more relia-
bility to the results provided endowing managers with more accurate information about
sensitivity of tasks and dependencies as well as other factors of the project.
75
Chapter 7
Conclusions
This section of the paper summarizes the main conclusions obtained in the application
of the model developed on the scenario proposed.
The model developed was fully detailed in the section 4, were five steps were described.
In addition, the implementation used was the third version of the classical genetic algo-
rithm, the process of breaking dependencies and the following sensitivity analysis, and
a last part the statistical analysis of the results.
The scenario used was composed by the four real projects detailed in the section 6.2 of
this paper and adapted by the methodology described in the section 6.1. The importance
of the data processed increases the relevance of the results collected since despite the
application of search-based techniques to software project management could cover all
the possible scope imaginable, the panoramic of the projects of the real world might be
limited to a specific ambit.
The results obtained in the sensitivity analysis for the process of breaking dependencies
reveal the possibility to identify with a considerable level of accuracy the list of most
sensitive dependencies in the definition of a project. This statement was clearly observed
in at least three of the four project analysed, which correspond to Project 2, Project 3,
and Project 4.
Moreover, the use of statistical analysis clarified the difference between the distributions
of the set of observations of running thirty times the GA without the most sensitive
dependencies. In so doing that, it was corroborated the validity of the output which
could have been attributed to the stochastic variance of the GA.
Nonetheless, it still remains unclear the main reason for the despair results obtained
in Project 1. Although, the statistic results for this project exhibited certain level of
76
Conclusions
confidence, the fact that there is not a clear list of most sensitive tasks trough all the
tests and the minor decrease produced in the completion time inspire hesitation.
In addition, in spite of the fact that the limitation of the model developed, particularly
the GA, and the resource availability have been name as partly responsible for the
increments obtained breaking dependencies, this fact seems absolutely illogical within
the project management.
In conclusion, the idea behind this paper as well as the relative encouraging results
accomplished in the application of the model developed to real data can settle a plausi-
ble and moderate as well as legitimate based for the use of search-based technique and
sensitivity analysis for software project management. Nevertheless, it is also truth that
deeper development and analysis are necessary to establish an absolute level of confi-
dence in the use of this approach. The application and utilisation of techniques such
genetic algorithms and sensitivity analysis involves therefore more exhaustive progress
and evaluation.
The main contributions of this paper are:
• Genetic algorithm able to provide reasonable and competent resource allocation
for different project scenarios.
• Success identifying the most sensitive dependencies in the TPG of the project
definition.
• Introduction of the statistical techniques to corroborate the results collected and
evaluated.
• The model implemented could guide project managers through important infor-
mation regarding the dependencies that could decrease the overall completion time
of the project considerably.
• This paper settles a new base for a use of search-based techniques in the software
project management and it entails a breakthrough in the process of approaching
the PSP.
• Beyond the insights on the research question this paper deploys a new area sur-
vey. It opens a new perspective in the means and method to improve the PSP.
The means used to reduce the completion time was breaking dependencies. The
techniques used were genetic algorithms and sensitivity analysis.
77
Chapter 8
Future Work
This section of the paper elaborates the next steps in the development of this research
and introduces the first notions of what could be the future work to enlarge the dimension
of it.
In order to achieve as far as possible in the aims established at the beginning of this
paper, and according to the last results obtained in the third version of the classical
genetic algorithm, it seems reasonable to keep working in this flank of developing a
reliable GA for the second part of the model proposed in the section 5 of this paper,
which main focus is breaking dependencies and sensitivity analysis. Consequently, there
are different alternatives in this sense. Probably the most relevant one might be to
develop a new fitness function able to overcome the limitations of the current one. In
addition, it is also reasonable the use of new operators to recombine the candidate
solutions to generate the new parent population. There is an extensive list of options in
this question. Therefore, it makes sense to improve the accuracy of the genetic algorithm
or until it was able to approximate solutions much more precisely.
Moreover, it would be interesting to enhance the scope of this research one step further
in a natural evolution from the point of view of providing new methods to improve
project management. A desirable progression is the possibility of being able to cover
the application of SA not only to the dependencies between tasks, but also to every
parameter inside the PSP. In the typical project management the range of most common
parameters are: resources, in terms of teams, sub teams, and employees; skills, in terms
of abilities and capacities of the employees and requirements of the tasks; cost, in terms of
the salary of every employee according to the role fulfilled inside the project; dedication,
in terms of hours per day/month of an employee to the project and/or task; duration,
in terms of month/person necessary to conclude a task; and the already mentioned
78
Future Work
dependencies. The considered parameters can be extended, yet these are the most
suitable ones.
In the application of SA to this list of factors the main purpose is to find the parameter
or parameters that produce the biggest negative impact in the original schedule with
the smallest variation in their initial estimation. In such a way that, the manager
is able to identify the most critical elements in the project and to ensure that they
are accurately performed according to the initial schedule. Moreover, this fact may
reveal to the manager non-considered dependencies inside the project. For instance, the
application of SA could show that an alteration of a minor percentage in the primitive
estimation of a parameter associated to a particular task can delay the tasks which
depend on the first one. In turn, these delays could be reflected in the appearance of
new dependencies, and a result of all this facts a significant global delay would affect
the original schedule of the project.
79
Appendix A
Appendix
80
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
66-1
0010
1-10
229
-97
59-4
961
-62
62-4
953
-101
101-
105
50-5
162
-54
Exe
cuti
on1
15.0
000
14.4
500
15.1
833
14.4
000
14.3
500
15.1
000
15.7
333
15.0
833
15.3
167
15.3
000
15.3
833
Exe
cuti
on2
15.9
000
14.6
833
14.1
333
14.4
500
14.5
333
15.1
333
15.1
000
15.8
667
15.1
167
15.7
667
15.8
667
Exe
cuti
on3
15.2
000
14.6
667
15.0
500
15.2
500
14.5
333
15.5
500
16.2
000
14.7
000
15.4
000
15.2
000
15.2
000
Exe
cuti
on4
14.8
667
14.6
667
15.0
000
16.2
167
15.0
000
15.2
167
14.8
833
14.7
833
16.3
000
15.1
167
16.0
000
Exe
cuti
on5
15.2
500
14.6
500
15.1
333
14.2
667
15.1
667
15.3
333
14.9
667
15.6
000
16.2
667
16.5
000
14.5
833
Exe
cuti
on6
15.6
667
14.7
833
15.0
000
14.9
667
15.0
333
15.5
167
15.4
500
15.8
500
14.6
500
14.8
167
15.0
500
Exe
cuti
on7
15.3
333
14.8
500
14.7
500
15.4
833
15.6
667
14.6
667
14.9
333
16.0
667
14.8
500
15.7
500
15.1
000
Exe
cuti
on8
15.9
000
14.9
000
15.7
500
14.8
500
15.4
000
15.2
833
15.8
500
14.6
667
14.9
333
14.7
000
14.9
333
Exe
cuti
on9
15.5
333
14.8
500
14.6
833
15.3
333
15.6
667
15.0
000
15.5
000
14.6
000
15.4
000
15.5
000
16.6
667
Exe
cuti
on10
15.8
333
14.4
833
15.1
833
14.6
167
14.7
333
14.7
500
14.9
500
15.5
500
15.2
500
15.3
167
15.3
667
Exe
cuti
on11
15.5
833
15.4
833
14.2
000
15.3
500
15.2
500
15.1
500
15.0
667
15.3
667
15.5
167
15.6
667
15.8
667
Exe
cuti
on12
16.5
833
14.4
833
14.5
833
15.6
333
15.0
000
15.0
000
16.0
000
15.0
000
14.5
667
14.8
500
15.4
000
Exe
cuti
on13
15.0
000
14.5
833
14.4
167
14.7
500
14.6
000
15.2
000
14.3
000
16.2
333
14.4
667
14.7
500
15.5
167
Exe
cuti
on14
16.1
500
15.4
333
14.7
500
15.2
667
14.9
000
15.0
667
15.6
500
15.4
000
15.2
000
13.8
000
15.0
167
Exe
cuti
on15
15.0
500
15.0
500
14.3
500
15.2
667
14.9
500
15.4
000
15.7
000
15.5
000
14.6
333
15.3
333
15.0
000
Exe
cuti
on16
15.5
000
14.8
167
14.2
000
15.7
500
14.3
667
15.0
000
15.5
500
14.7
833
15.5
500
15.0
000
15.4
667
Exe
cuti
on17
15.4
000
15.6
000
15.8
000
14.5
333
15.0
000
15.4
500
14.5
333
16.0
000
14.6
500
15.2
000
15.0
333
Exe
cuti
on18
15.0
000
15.2
500
16.1
167
15.5
833
16.1
333
15.3
833
15.2
000
14.7
167
15.7
833
15.1
000
15.0
667
Exe
cuti
on19
15.8
500
14.5
500
14.7
333
15.1
167
14.5
000
15.8
500
15.8
333
15.7
500
14.9
333
15.9
833
15.3
000
Exe
cuti
on20
15.0
000
15.3
333
15.9
167
14.6
000
15.3
500
15.3
333
14.3
500
15.2
000
15.9
833
15.8
833
15.0
833
Exe
cuti
on21
15.3
167
14.8
333
15.0
000
15.5
333
15.6
667
15.0
000
15.3
833
15.0
000
15.5
833
15.4
667
15.2
500
Exe
cuti
on22
15.5
833
14.9
000
14.4
833
15.6
167
15.5
000
14.6
833
15.5
000
14.7
000
14.6
667
15.0
000
14.6
167
Exe
cuti
on23
15.4
000
15.1
833
15.0
000
14.8
500
15.1
500
15.4
000
14.9
333
15.2
500
15.8
167
15.1
833
15.3
500
Exe
cuti
on24
15.7
333
14.3
333
14.9
000
15.3
333
15.8
000
15.6
500
15.5
000
14.7
167
15.4
833
15.0
000
14.9
833
Exe
cuti
on25
15.7
833
15.1
667
14.7
667
14.8
833
15.9
333
15.8
667
14.7
167
15.0
000
15.4
000
15.6
667
15.6
000
Exe
cuti
on26
16.0
667
14.9
500
14.5
000
14.4
667
15.4
000
15.5
000
15.4
167
15.2
333
14.9
167
15.7
500
15.2
000
Exe
cuti
on27
16.0
000
14.7
000
15.5
333
14.6
000
15.0
833
15.0
833
13.9
833
15.3
500
15.5
000
14.6
667
14.8
333
Exe
cuti
on28
15.2
000
14.6
667
14.6
667
16.0
833
15.6
000
14.6
000
15.5
833
14.7
000
15.3
333
14.6
833
15.1
333
Exe
cuti
on29
14.9
500
14.6
667
15.3
333
15.9
167
16.1
333
14.5
000
15.3
000
14.6
000
15.1
333
15.8
000
15.2
167
Exe
cuti
on30
15.6
667
13.9
833
14.6
000
15.3
500
15.4
000
15.2
000
14.4
000
15.9
333
15.2
000
15.1
167
14.8
000
Ave
rage
15.5
1000
14.8
3166
14.9
2388
15.1
4389
15.1
9333
15.1
9555
15.2
1555
15.2
4000
15.2
6000
15.2
6223
15.2
6278
Table
A.1
:T
op10
Res
ults
Pro
ject
1T
est
1.
81
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
23-2
464
-88
49-5
027
-28
53-1
0110
2-10
379
-80
26-2
714
-13
50-5
1E
xecu
tion
130
3029
3028
2831
2831
3330
Exe
cuti
on2
3130
3129
2831
2830
3030
32E
xecu
tion
331
2928
3228
2830
2931
3028
Exe
cuti
on4
3329
2831
2928
3130
2829
30E
xecu
tion
530
2928
3230
2831
3028
3030
Exe
cuti
on6
3129
3130
3030
3031
2929
31E
xecu
tion
730
2928
2829
3131
3233
2932
Exe
cuti
on8
3129
2929
2928
2830
3029
30E
xecu
tion
930
2930
3029
2931
3131
3130
Exe
cuti
on10
2829
2929
3132
3028
2930
30E
xecu
tion
1130
3029
3029
3029
2929
3029
Exe
cuti
on12
3028
3029
3029
2930
3030
29E
xecu
tion
1329
3030
2830
3231
2931
3231
Exe
cuti
on14
3128
2929
3032
3129
3129
30E
xecu
tion
1531
2928
3131
2931
3129
3128
Exe
cuti
on16
3129
2729
2832
2829
3231
28E
xecu
tion
1730
2831
2731
2830
3131
2933
Exe
cuti
on18
3029
3130
3128
3030
3031
29E
xecu
tion
1929
2929
2730
3130
3231
2831
Exe
cuti
on20
2829
2730
2829
2732
3133
30E
xecu
tion
2129
2828
2731
2931
2929
3232
Exe
cuti
on22
3030
3029
3128
3029
3330
31E
xecu
tion
2330
2928
3128
3028
2829
2929
Exe
cuti
on24
3028
3030
3032
3029
3028
29E
xecu
tion
2529
2928
2930
3130
3029
2930
Exe
cuti
on26
2929
3129
3228
2931
3030
30E
xecu
tion
2731
2928
2830
2930
3329
3131
Exe
cuti
on28
2828
2930
3132
3129
2929
29E
xecu
tion
2931
2931
2929
2930
2928
2930
Exe
cuti
on30
3327
3029
2828
2830
2830
29
Ave
rage
30.1
3333
28.9
0000
29.1
6667
29.3
6667
29.6
3333
29.6
3333
29.8
0000
29.9
3333
29.9
6667
30.0
3333
30.0
3333
Table
A.2
:T
op10
Res
ults
Pro
ject
1T
est
2.
82
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
101-
107
50-5
12-
453
-106
49-5
029
-86
66-1
0010
2-10
348
-49
65-6
6E
xecu
tion
138
3637
4039
4139
3941
3738
Exe
cuti
on2
4337
3841
3838
3839
3638
40E
xecu
tion
341
3537
3837
4140
4139
4039
Exe
cuti
on4
4138
4238
4039
4037
4040
41E
xecu
tion
540
4040
3841
3938
3940
3939
Exe
cuti
on6
3938
3838
3940
4039
3642
38E
xecu
tion
740
3638
3937
3939
4040
3840
Exe
cuti
on8
4039
3740
3839
3640
3939
37E
xecu
tion
938
3639
3939
3839
3738
4040
Exe
cuti
on10
4339
3739
4039
4138
3940
41E
xecu
tion
1140
3737
4038
3942
4039
3940
Exe
cuti
on12
4039
3840
4039
3741
4040
40E
xecu
tion
1340
3737
3938
3938
4139
4140
Exe
cuti
on14
4138
3835
4039
3940
4039
38E
xecu
tion
1540
3839
3940
3937
3841
3739
Exe
cuti
on16
4137
3740
4140
4240
3740
39E
xecu
tion
1738
3839
4040
3940
4039
4138
Exe
cuti
on18
4137
3939
4139
3939
3941
39E
xecu
tion
1940
3841
3939
4139
4040
4040
Exe
cuti
on20
4138
4139
3939
4039
3840
38E
xecu
tion
2138
3837
3840
4139
3839
3939
Exe
cuti
on22
3938
3939
3838
4040
4138
39E
xecu
tion
2341
3840
3839
3738
3940
3841
Exe
cuti
on24
3839
3940
3940
4039
3742
41E
xecu
tion
2539
4039
3940
3941
4042
4040
Exe
cuti
on26
3939
4039
3937
4040
4138
41E
xecu
tion
2740
3938
3839
3841
4040
3940
Exe
cuti
on28
4039
3838
3941
3838
3839
39E
xecu
tion
2940
4038
3938
3938
3941
3839
Exe
cuti
on30
4041
3840
3740
3839
4040
39
Ave
rage
39.9
6667
38.0
6667
38.5
0000
38.9
3333
39.0
6667
39.2
0000
39.2
0000
39.3
0000
39.3
0000
39.4
0000
39.4
0000
Table
A.3
:T
op10
Res
ults
Pro
ject
1T
est
3.
83
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
21-2
232
-33
43-4
447
-49
63-6
471
-73
101-
107
49-5
050
-51
96-9
7E
xecu
tion
160
5861
6257
6160
6161
6164
Exe
cuti
on2
5960
6159
6461
6359
5857
61E
xecu
tion
358
6262
5963
5761
5960
6158
Exe
cuti
on4
6361
6162
6260
6361
6260
59E
xecu
tion
561
6259
5861
5960
6163
6160
Exe
cuti
on6
6663
6360
6158
6161
6265
60E
xecu
tion
764
6262
6263
5862
6062
5959
Exe
cuti
on8
6259
6064
6161
6260
6260
57E
xecu
tion
961
6162
6160
6060
5966
6262
Exe
cuti
on10
6359
6263
5964
6460
6162
59E
xecu
tion
1164
6262
6360
6164
6363
6364
Exe
cuti
on12
6362
6465
6259
6161
6259
60E
xecu
tion
1364
6360
6158
6059
6160
5862
Exe
cuti
on14
6361
6363
6459
6160
6260
67E
xecu
tion
1563
6559
6464
6059
6558
6462
Exe
cuti
on16
6360
6060
6360
6361
6463
62E
xecu
tion
1762
6159
6060
6059
6259
6162
Exe
cuti
on18
5962
5962
6363
6063
6063
64E
xecu
tion
1960
5963
6659
6162
6162
6362
Exe
cuti
on20
6662
6160
6463
6162
5864
60E
xecu
tion
2164
6059
6059
6262
6264
5862
Exe
cuti
on22
6263
6161
6263
6064
6164
61E
xecu
tion
2363
6062
5760
6162
5962
6063
Exe
cuti
on24
6265
6161
6361
6258
6263
64E
xecu
tion
2560
6061
6158
6160
6059
6461
Exe
cuti
on26
6358
6261
6164
6062
6462
65E
xecu
tion
2761
6261
6259
6259
6162
6260
Exe
cuti
on28
6461
6461
6164
6160
6762
67E
xecu
tion
2963
6363
6059
6361
5960
6262
Exe
cuti
on30
6162
6063
6265
6260
5962
62
Ave
rage
62.2
3333
61.2
6667
61.2
3333
61.3
6667
61.0
6667
61.0
3333
61.1
3333
60.8
3333
61.5
0000
61.5
0000
61.7
0000
Table
A.4
:T
op10
Res
ults
Pro
ject
1T
est
4.
84
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
90-9
198
-99
97-9
899
-100
102-
103
89-9
010
0-10
110
1-10
291
-97
85-8
6E
xecu
tion
147
.000
041
.166
743
.033
341
.966
742
.966
747
.433
342
.533
346
.866
745
.416
741
.600
042
.950
0E
xecu
tion
245
.933
341
.883
341
.883
341
.700
042
.466
742
.433
344
.183
342
.033
348
.333
342
.600
046
.250
0E
xecu
tion
351
.833
342
.333
342
.483
344
.550
042
.533
342
.500
046
.283
344
.066
742
.683
346
.400
047
.333
3E
xecu
tion
453
.033
343
.033
343
.300
042
.466
744
.966
744
.866
740
.333
346
.400
044
.883
343
.766
743
.850
0E
xecu
tion
551
.400
042
.383
341
.200
043
.800
045
.133
346
.916
743
.500
043
.333
341
.150
041
.883
348
.366
7E
xecu
tion
652
.383
342
.000
042
.416
740
.216
742
.800
044
.100
045
.100
042
.100
043
.600
045
.216
748
.150
0E
xecu
tion
751
.216
744
.616
742
.466
742
.350
044
.483
343
.466
744
.900
047
.066
746
.883
346
.433
341
.666
7E
xecu
tion
851
.583
342
.100
043
.400
044
.516
745
.000
046
.600
045
.366
744
.950
044
.766
742
.633
346
.066
7E
xecu
tion
951
.816
741
.300
044
.683
341
.766
741
.250
043
.000
042
.066
746
.066
745
.783
344
.383
344
.200
0E
xecu
tion
1048
.100
040
.983
341
.283
344
.700
043
.666
743
.133
342
.300
041
.183
342
.833
343
.416
743
.233
3E
xecu
tion
1148
.916
740
.966
741
.650
043
.733
341
.866
742
.066
747
.133
345
.750
045
.200
041
.300
045
.450
0E
xecu
tion
1249
.433
341
.350
044
.800
044
.633
345
.866
743
.366
744
.783
342
.216
742
.783
346
.333
345
.216
7E
xecu
tion
1349
.466
741
.600
043
.700
043
.016
742
.866
745
.600
042
.883
345
.400
045
.966
744
.533
348
.700
0E
xecu
tion
1452
.316
741
.200
044
.000
043
.316
745
.833
343
.916
744
.433
345
.433
344
.966
743
.916
743
.850
0E
xecu
tion
1548
.666
742
.233
341
.500
043
.350
042
.533
342
.833
346
.083
341
.900
046
.233
344
.216
742
.100
0E
xecu
tion
1650
.733
341
.250
045
.866
743
.433
344
.666
745
.633
344
.083
340
.516
745
.483
345
.116
746
.200
0E
xecu
tion
1751
.250
040
.950
043
.750
042
.350
044
.466
742
.450
044
.666
743
.650
042
.916
746
.566
740
.983
3E
xecu
tion
1854
.750
043
.416
742
.700
042
.666
744
.366
744
.216
745
.816
744
.200
041
.333
346
.433
342
.400
0E
xecu
tion
1953
.300
038
.183
342
.783
341
.966
741
.616
744
.583
345
.783
346
.416
742
.300
046
.900
048
.650
0E
xecu
tion
2051
.300
044
.583
342
.750
043
.200
046
.350
041
.166
745
.833
343
.550
045
.366
745
.483
342
.083
3E
xecu
tion
2147
.583
341
.783
341
.816
743
.600
040
.300
045
.166
741
.866
747
.533
345
.633
346
.983
347
.533
3E
xecu
tion
2250
.550
040
.716
743
.033
344
.733
342
.300
046
.016
745
.283
347
.316
745
.516
745
.383
342
.383
3E
xecu
tion
2348
.450
044
.333
343
.600
044
.150
043
.716
742
.116
744
.466
742
.116
745
.433
345
.233
348
.866
7E
xecu
tion
2450
.416
746
.766
742
.616
746
.516
742
.700
046
.566
744
.783
343
.083
347
.366
744
.133
347
.266
7E
xecu
tion
2549
.133
343
.183
342
.016
741
.600
042
.833
343
.266
741
.516
747
.466
745
.950
047
.016
740
.916
7E
xecu
tion
2651
.816
744
.583
341
.500
043
.183
346
.650
043
.866
744
.566
742
.166
742
.016
744
.866
746
.900
0E
xecu
tion
2750
.966
742
.833
343
.400
044
.200
043
.533
345
.766
744
.150
047
.816
745
.900
042
.550
044
.400
0E
xecu
tion
2850
.433
343
.000
042
.350
042
.550
045
.516
745
.983
345
.583
343
.600
047
.166
747
.266
743
.116
7E
xecu
tion
2950
.350
040
.883
342
.233
342
.883
343
.883
345
.450
046
.666
747
.516
742
.933
344
.650
046
.416
7E
xecu
tion
3052
.283
343
.683
344
.083
342
.333
343
.900
041
.183
347
.333
344
.233
342
.166
746
.900
043
.400
0
Ave
rage
50.5
4722
42.3
0999
42.8
7666
43.1
8167
43.7
0112
44.1
8890
44.4
7610
44.5
3167
44.6
3222
44.8
0389
44.9
6334
Table
A.5
:T
op10
Res
ults
Pro
ject
2T
est
1.
85
Appendix
Ori
gina
lT
OP
1T
OP
2T
OP
3T
OP
4T
OP
5T
OP
6T
OP
7T
OP
8T
OP
9T
OP
10D
epen
deny
brok
en97
-98
98-9
991
-97
90-9
189
-90
88-9
099
-100
87-8
886
-87
85-8
6E
xecu
tion
120
110
711
112
012
512
712
913
113
413
914
4E
xecu
tion
220
110
911
112
012
512
712
913
113
413
914
4E
xecu
tion
320
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
420
110
111
212
012
512
712
913
113
413
914
4E
xecu
tion
520
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
620
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
720
110
211
112
012
512
712
913
113
413
914
4E
xecu
tion
820
110
711
412
012
512
712
913
113
413
914
4E
xecu
tion
920
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
1020
110
211
112
012
512
712
913
113
413
914
4E
xecu
tion
1120
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
1220
110
211
112
012
512
712
913
113
413
914
4E
xecu
tion
1320
110
211
112
012
512
712
913
113
413
914
4E
xecu
tion
1420
110
411
112
012
512
712
913
113
413
914
4E
xecu
tion
1520
110
811
112
012
512
712
913
113
413
914
4E
xecu
tion
1620
110
311
112
012
512
712
913
113
413
914
4E
xecu
tion
1720
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
1820
111
111
412
012
512
712
913
113
413
914
4E
xecu
tion
1920
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
2020
110
511
112
012
512
712
913
113
413
914
4E
xecu
tion
2120
110
411
112
012
512
712
913
113
413
914
4E
xecu
tion
2220
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
2320
110
711
112
012
512
712
913
113
413
914
4E
xecu
tion
2420
110
711
412
012
512
712
913
113
413
914
4E
xecu
tion
2520
110
111
112
012
512
712
913
113
413
914
4E
xecu
tion
2620
110
711
112
012
512
712
913
113
413
914
4E
xecu
tion
2720
110
711
212
012
512
712
913
113
413
914
4E
xecu
tion
2820
110
711
312
012
512
712
913
113
413
914
4E
xecu
tion
2920
110
811
112
012
512
712
913
113
413
914
4E
xecu
tion
3020
110
711
112
012
512
712
913
113
413
914
4
Ave
rage
201.
0000
010
4.20
000
111.
4333
312
0.00
000
125.
0000
012
7.00
000
129.
0000
013
1.00
000
134.
0000
013
9.00
000
144.
0000
0
Table
A.6
:T
op10
Res
ults
Pro
ject
2T
est
2.
86
Appendix
Ori
gina
lT
OP
1T
OP
2T
OP
3T
OP
4T
OP
5T
OP
6T
OP
7T
OP
8T
OP
9T
OP
10D
epen
deny
brok
en97
-98
98-9
991
-97
90-9
189
-90
88-9
099
-100
87-8
886
-87
85-8
6E
xecu
tion
120
112
712
412
012
513
312
913
313
413
914
4E
xecu
tion
220
112
612
312
012
613
313
113
113
413
914
4E
xecu
tion
320
112
412
012
612
512
913
813
213
413
914
5E
xecu
tion
420
112
012
112
612
513
113
813
113
913
914
4E
xecu
tion
520
111
411
813
113
612
913
713
514
013
914
4E
xecu
tion
620
112
812
213
112
513
212
913
213
513
914
6E
xecu
tion
720
112
012
213
312
514
112
913
314
314
014
9E
xecu
tion
820
112
611
712
512
512
713
213
313
414
514
5E
xecu
tion
920
111
811
812
512
712
812
913
413
413
914
6E
xecu
tion
1020
111
812
212
713
012
913
013
213
913
915
0E
xecu
tion
1120
112
211
812
712
612
712
913
914
013
914
4E
xecu
tion
1220
112
012
712
412
712
913
513
113
713
914
9E
xecu
tion
1320
112
611
812
312
514
113
813
413
713
914
4E
xecu
tion
1420
112
411
812
412
513
912
913
714
413
915
4E
xecu
tion
1520
112
511
912
512
513
812
913
113
513
914
6E
xecu
tion
1620
111
112
612
112
713
112
913
114
213
915
2E
xecu
tion
1720
110
812
812
712
613
913
513
213
813
914
5E
xecu
tion
1820
112
411
712
313
913
713
313
813
413
914
4E
xecu
tion
1920
111
711
712
013
013
313
113
113
513
914
4E
xecu
tion
2020
111
812
412
513
613
513
413
313
413
914
9E
xecu
tion
2120
112
612
212
512
912
713
513
313
613
915
4E
xecu
tion
2220
111
411
912
613
312
713
713
213
413
914
5E
xecu
tion
2320
111
412
412
512
613
612
913
213
613
915
0E
xecu
tion
2420
112
312
312
412
513
513
013
113
413
914
5E
xecu
tion
2520
112
412
112
512
612
813
013
413
514
514
7E
xecu
tion
2620
112
412
512
412
513
212
913
213
414
115
1E
xecu
tion
2720
111
812
212
513
013
712
913
413
513
915
0E
xecu
tion
2820
113
011
512
112
612
712
913
314
313
914
4E
xecu
tion
2920
112
411
712
412
513
212
913
513
413
915
0E
xecu
tion
3020
112
112
812
912
612
813
513
413
413
915
1
Ave
rage
201.
0000
012
1.13
333
121.
1666
712
5.03
333
127.
5333
313
2.33
333
131.
8666
713
3.10
000
136.
5666
713
9.50
000
147.
1666
7
Table
A.7
:T
op10
Res
ults
Pro
ject
2T
est
3.
87
Appendix
Ori
gina
lT
OP
1T
OP
2T
OP
3T
OP
4T
OP
5T
OP
6T
OP
7T
OP
8T
OP
9T
OP
10D
epen
deny
brok
en97
-98
89-9
090
-91
91-9
798
-99
99-1
0088
-89
87-8
810
1-10
285
-86
Exe
cuti
on1
219
172
166
166
181
179
175
189
168
192
192
Exe
cuti
on2
220
158
176
171
164
175
182
168
178
184
196
Exe
cuti
on3
221
179
172
161
186
180
183
194
199
180
179
Exe
cuti
on4
228
172
180
174
176
181
171
189
180
183
193
Exe
cuti
on5
217
170
172
173
175
175
188
183
184
182
196
Exe
cuti
on6
215
184
172
169
171
178
182
176
185
200
166
Exe
cuti
on7
215
170
175
175
165
177
181
186
173
184
194
Exe
cuti
on8
234
171
179
190
166
183
180
184
188
193
193
Exe
cuti
on9
218
173
163
174
184
178
180
185
167
182
179
Exe
cuti
on10
219
168
181
170
185
170
184
178
181
181
197
Exe
cuti
on11
222
188
164
168
180
166
178
171
172
175
183
Exe
cuti
on12
213
183
164
168
172
170
173
165
179
184
176
Exe
cuti
on13
219
178
171
182
167
169
187
182
184
173
183
Exe
cuti
on14
221
170
163
160
172
178
169
177
179
201
169
Exe
cuti
on15
210
169
176
170
178
176
191
187
200
191
185
Exe
cuti
on16
220
160
185
177
166
186
177
167
187
176
185
Exe
cuti
on17
213
168
173
188
161
172
184
194
195
181
194
Exe
cuti
on18
212
170
176
193
190
186
180
160
202
181
188
Exe
cuti
on19
233
169
177
184
174
172
175
175
186
188
177
Exe
cuti
on20
221
179
172
184
182
161
183
199
181
187
172
Exe
cuti
on21
216
164
184
185
173
187
187
192
179
183
178
Exe
cuti
on22
215
185
176
172
173
177
182
169
186
185
176
Exe
cuti
on23
229
176
163
175
179
185
180
183
170
182
180
Exe
cuti
on24
216
171
179
175
184
178
174
190
166
179
181
Exe
cuti
on25
222
184
183
178
172
184
170
181
193
187
178
Exe
cuti
on26
216
182
184
172
183
176
190
186
189
183
205
Exe
cuti
on27
206
177
168
176
179
182
187
185
186
190
189
Exe
cuti
on28
211
166
172
171
189
173
178
181
183
172
188
Exe
cuti
on29
220
176
187
161
183
177
180
167
184
202
188
Exe
cuti
on30
219
167
178
173
180
183
177
182
186
182
195
Ave
rage
218.
6666
717
3.30
000
174.
3666
717
4.50
000
176.
3333
317
7.13
333
180.
2666
718
0.83
333
183.
0000
018
4.76
667
185.
1666
7
Table
A.8
:T
op10
Res
ults
Pro
ject
2T
est
4.
88
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
8-9
66-6
715
-56
74-7
524
-54
5-6
9-12
6-8
75-7
617
-56
Exe
cuti
on1
9.45
000
9.80
000
9.90
000
9.90
000
9.28
333
9.76
667
8.91
667
9.30
000
9.20
000
9.45
000
9.31
667
Exe
cuti
on2
9.16
667
9.36
667
9.25
000
9.26
667
9.13
333
9.21
667
9.48
333
8.96
667
9.51
667
8.75
000
8.65
000
Exe
cuti
on3
9.40
000
9.30
000
9.43
333
9.35
000
9.38
333
9.48
333
9.55
000
9.48
333
8.60
000
9.45
000
9.11
667
Exe
cuti
on4
9.78
333
9.63
333
8.85
000
8.95
000
9.26
667
9.40
000
9.13
333
9.76
667
9.61
667
9.56
667
9.95
000
Exe
cuti
on5
9.48
333
9.46
667
9.40
000
9.55
000
9.38
333
9.28
333
9.11
667
9.20
000
10.2
1670
9.51
667
9.50
000
Exe
cuti
on6
9.40
000
9.58
333
9.45
000
9.55
000
9.53
333
9.35
000
9.11
667
9.65
000
8.96
667
9.28
333
8.70
000
Exe
cuti
on7
9.66
667
9.71
667
9.11
667
10.1
0000
9.86
667
9.31
667
9.41
667
9.61
667
9.68
333
9.65
000
9.65
000
Exe
cuti
on8
9.55
000
9.38
333
9.20
000
9.15
000
9.40
000
9.46
667
9.11
666
9.25
000
9.48
333
9.51
667
9.18
333
Exe
cuti
on9
9.65
000
9.63
333
9.45
000
9.76
667
9.55
000
9.40
000
9.53
333
9.15
000
8.71
667
9.23
333
9.25
000
Exe
cuti
on10
10.1
0000
9.23
333
9.75
000
9.36
667
9.30
000
9.55
000
9.45
000
9.43
333
9.83
333
9.35
000
9.06
667
Exe
cuti
on11
9.50
000
9.36
667
9.53
333
9.40
000
9.35
000
9.31
667
9.90
000
9.15
000
9.90
000
9.63
333
9.40
000
Exe
cuti
on12
9.30
000
9.28
333
9.11
667
9.20
000
9.70
000
9.61
667
9.73
333
9.35
000
9.11
667
9.86
667
9.23
333
Exe
cuti
on13
9.53
333
9.31
667
9.30
000
9.76
667
9.38
333
9.10
000
9.71
667
9.20
000
9.36
667
9.28
333
9.38
333
Exe
cuti
on14
9.80
000
9.30
000
9.51
667
9.75
000
9.21
667
9.23
333
9.56
667
9.25
000
9.46
667
9.65
000
9.15
000
Exe
cuti
on15
9.45
000
9.38
333
9.40
000
9.25
000
9.26
667
9.26
667
10.0
1670
9.51
667
10.0
0000
9.30
000
9.51
667
Exe
cuti
on16
9.90
000
9.20
000
9.01
667
9.60
000
8.98
333
9.20
000
9.03
333
9.58
333
10.0
8330
9.36
667
9.75
000
Exe
cuti
on17
9.55
000
8.91
667
9.43
333
9.50
000
9.10
000
9.70
000
9.38
333
9.40
000
9.38
333
9.85
000
9.66
667
Exe
cuti
on18
9.56
667
9.26
667
9.30
000
9.20
000
8.96
667
9.53
333
9.05
000
9.05
000
8.91
667
9.86
667
9.53
333
Exe
cuti
on19
9.55
000
8.81
667
9.88
333
9.11
667
9.23
333
9.31
667
9.76
667
9.45
000
9.70
000
9.53
333
9.70
000
Exe
cuti
on20
9.60
000
9.16
667
9.45
000
8.86
667
9.30
000
9.68
333
9.35
000
9.25
000
9.31
666
9.15
000
9.26
667
Exe
cuti
on21
9.46
667
9.23
333
9.31
667
9.50
000
9.65
000
9.45
000
9.60
000
9.26
667
9.68
333
9.36
667
9.76
667
Exe
cuti
on22
9.45
000
9.51
667
9.76
667
9.10
000
9.65
000
9.35
000
9.53
333
10.2
3330
9.90
000
9.26
667
9.50
000
Exe
cuti
on23
9.68
333
9.63
333
9.30
000
9.45
000
9.75
000
9.40
000
9.90
000
9.15
000
9.43
333
9.45
000
10.1
3330
Exe
cuti
on24
9.56
667
9.53
333
9.25
000
9.05
000
9.46
667
9.70
000
9.21
667
9.10
000
9.15
000
9.46
667
9.60
000
Exe
cuti
on25
9.43
333
9.41
667
9.63
333
8.98
333
9.11
667
9.65
000
9.21
667
9.23
333
8.85
000
9.08
333
10.3
1670
Exe
cuti
on26
9.85
000
9.55
000
9.11
666
9.86
667
9.20
000
9.55
000
8.78
333
9.48
333
9.33
333
9.81
667
9.65
000
Exe
cuti
on27
9.31
667
9.26
667
9.53
333
9.20
000
9.93
333
9.26
667
9.71
666
9.45
000
9.08
333
8.73
333
9.15
000
Exe
cuti
on28
9.23
333
9.20
000
9.40
000
9.35
000
9.95
000
9.53
333
9.65
000
10.0
5000
9.18
333
9.85
000
9.38
333
Exe
cuti
on29
9.61
667
9.53
333
9.40
000
9.10
000
9.10
000
9.26
667
9.33
333
9.90
000
9.66
667
9.45
000
9.45
000
Exe
cuti
on30
9.96
667
8.95
000
9.20
000
9.55
000
9.70
000
8.90
000
9.40
000
9.96
667
9.78
333
9.60
000
9.60
000
Ave
rage
9.56
611
9.36
556
9.38
889
9.39
167
9.40
389
9.40
889
9.42
333
9.42
833
9.43
833
9.44
500
9.45
111
Table
A.9
:T
op10
Res
ults
Pro
ject
3T
est
1.
89
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
Dep
ende
nybr
oken
5-6
3-5
2-3
1-2
6-8
8-9
65-7
19-
65E
xecu
tion
129
1826
2728
2828
2929
Exe
cuti
on2
2920
2627
2828
2929
29E
xecu
tion
329
2026
2728
2928
2929
Exe
cuti
on4
2920
2627
2829
2828
29E
xecu
tion
529
2126
2728
2828
2929
Exe
cuti
on6
2920
2627
2828
2929
29E
xecu
tion
729
2026
2728
2828
2928
Exe
cuti
on8
2920
2627
2829
2829
29E
xecu
tion
929
2126
2728
2828
2929
Exe
cuti
on10
2920
2627
2828
2929
29E
xecu
tion
1129
2026
2728
2829
2829
Exe
cuti
on12
2920
2627
2828
2828
28E
xecu
tion
1329
2026
2728
2828
2829
Exe
cuti
on14
2920
2627
2829
2928
29E
xecu
tion
1529
2026
2728
2929
2828
Exe
cuti
on16
2920
2627
2828
2829
29E
xecu
tion
1729
2026
2728
2928
2829
Exe
cuti
on18
2920
2627
2828
2929
29E
xecu
tion
1929
2026
2728
2828
2929
Exe
cuti
on20
2920
2627
2828
2829
29E
xecu
tion
2129
2026
2728
2828
2929
Exe
cuti
on22
2921
2627
2829
2929
29E
xecu
tion
2329
2126
2728
2828
2929
Exe
cuti
on24
2920
2627
2828
2829
29E
xecu
tion
2529
2026
2728
2829
2828
Exe
cuti
on26
2920
2627
2828
2828
29E
xecu
tion
2729
2126
2728
2828
2929
Exe
cuti
on28
2920
2627
2828
2829
29E
xecu
tion
2929
2126
2728
2828
2829
Exe
cuti
on30
2920
2627
2828
2828
29
Ave
rage
29.0
0000
20.1
3333
26.0
0000
27.0
0000
28.0
0000
28.2
3333
28.3
0000
28.6
3333
28.8
6667
Table
A.1
0:
Top
10R
esul
tsP
roje
ct3
Tes
t2.
90
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
5-6
6-7
73-7
43-
559
-60
8-9
6-8
48-6
634
-35
36-3
7E
xecu
tion
130
2629
2928
2929
2930
2930
Exe
cuti
on2
3026
2929
3029
2930
2930
30E
xecu
tion
331
2529
3030
2929
2929
3230
Exe
cuti
on4
3025
2929
2729
2929
2929
30E
xecu
tion
531
2529
2930
2930
3031
2930
Exe
cuti
on6
3225
2929
2930
2929
2930
29E
xecu
tion
733
2229
2928
2930
2929
3031
Exe
cuti
on8
3025
2929
3029
2930
2930
30E
xecu
tion
930
2529
2932
2930
3031
3129
Exe
cuti
on10
3125
2929
2829
2930
3329
31E
xecu
tion
1129
2429
2930
2929
3030
2931
Exe
cuti
on12
2926
2929
3129
2930
3029
29E
xecu
tion
1330
2529
2927
2930
3029
3031
Exe
cuti
on14
3326
2929
2929
2829
2929
29E
xecu
tion
1531
2329
2930
2929
3030
2929
Exe
cuti
on16
3026
2929
3129
3029
3030
29E
xecu
tion
1733
2429
2929
3030
2930
2929
Exe
cuti
on18
3027
2929
2829
2930
2929
30E
xecu
tion
1930
2429
2930
3130
2932
3031
Exe
cuti
on20
3026
2929
2830
2930
2932
29E
xecu
tion
2129
2529
2930
2929
2931
2930
Exe
cuti
on22
3025
2929
2729
3030
2932
30E
xecu
tion
2333
2529
3030
2929
3030
3030
Exe
cuti
on24
3024
2930
3029
3129
3030
29E
xecu
tion
2530
2329
2930
2930
3029
3029
Exe
cuti
on26
3025
2929
2629
2929
2929
30E
xecu
tion
2733
025
2929
3029
3029
2929
29E
xecu
tion
2833
2429
3130
2929
2929
2930
Exe
cuti
on29
2926
2929
2831
3029
2929
29E
xecu
tion
3033
2529
2930
2930
2929
3029
Ave
rage
30.7
6667
24.9
0000
29.0
0000
29.1
6667
29.2
0000
29.2
3333
29.4
3333
29.4
6667
29.7
0000
29.7
3333
29.7
3333
Table
A.1
1:
Top
10R
esul
tsP
roje
ct3
Tes
t3.
91
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
5-6
6-8
8-65
8-9
6-7
74-7
575
-76
7-10
10-1
224
-28
Exe
cuti
on1
4141
4038
3838
4142
3938
40E
xecu
tion
240
3738
4139
3938
4140
4040
Exe
cuti
on3
4137
3841
4040
4140
3940
39E
xecu
tion
440
3638
3941
3739
4141
3937
Exe
cuti
on5
4240
3941
4040
4340
4040
40E
xecu
tion
641
3840
3942
4141
3940
4040
Exe
cuti
on7
4138
3941
3940
3839
3838
39E
xecu
tion
839
3740
3839
3941
4138
4141
Exe
cuti
on9
4140
3739
3939
3940
4038
40E
xecu
tion
1042
4039
4241
4239
3940
4439
Exe
cuti
on11
4140
4138
3939
4138
4239
41E
xecu
tion
1240
3939
3838
3940
3938
4243
Exe
cuti
on13
4239
3841
3740
4138
3939
43E
xecu
tion
1439
4039
3841
4141
3941
4041
Exe
cuti
on15
4041
3940
3940
3742
3937
38E
xecu
tion
1641
3640
4139
4038
4341
4041
Exe
cuti
on17
4139
3938
3942
3940
4239
39E
xecu
tion
1839
3937
3840
4140
3840
4141
Exe
cuti
on19
4138
4139
3840
4140
4040
39E
xecu
tion
2041
3741
4038
4039
3939
4037
Exe
cuti
on21
4240
3938
4139
3939
4144
41E
xecu
tion
2241
3939
3840
3938
3939
4239
Exe
cuti
on23
4239
3941
4041
4138
3940
41E
xecu
tion
2438
3740
3942
3940
4042
4042
Exe
cuti
on25
3740
4039
4039
4141
4141
40E
xecu
tion
2640
4039
4138
4139
4040
3938
Exe
cuti
on27
4140
3837
3941
4042
4040
39E
xecu
tion
2841
3840
4042
3940
3940
3940
Exe
cuti
on29
4039
3841
3940
4041
4040
39E
xecu
tion
3040
3839
4039
3941
3939
3741
Ave
rage
40.5
0000
38.7
3333
39.1
0000
39.4
6667
39.5
3333
39.8
0000
39.8
6667
39.8
6667
39.9
0000
39.9
0000
39.9
3333
Table
A.1
2:
Top
10R
esul
tsP
roje
ct3
Tes
t4.
92
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
52-5
351
-52
21-4
650
-51
20-2
148
-49
46-4
849
-50
55-5
69-
10E
xecu
tion
116
.266
713
.983
314
.850
014
.133
314
.966
714
.683
314
.316
715
.733
314
.400
015
.033
315
.166
7E
xecu
tion
216
.416
714
.433
314
.283
314
.233
314
.433
314
.933
314
.616
714
.516
714
.750
015
.366
715
.350
0E
xecu
tion
316
.216
714
.316
714
.183
314
.666
714
.366
714
.583
314
.666
714
.883
314
.883
314
.650
014
.950
0E
xecu
tion
415
.666
714
.533
314
.416
713
.783
314
.683
314
.616
715
.266
714
.666
714
.216
715
.433
314
.883
3E
xecu
tion
516
.050
014
.000
014
.033
314
.050
014
.383
314
.800
014
.233
315
.366
714
.700
014
.666
714
.950
0E
xecu
tion
616
.266
714
.283
314
.400
014
.950
014
.800
014
.716
714
.550
014
.550
014
.516
715
.366
714
.833
3E
xecu
tion
716
.150
014
.533
314
.600
014
.366
714
.216
714
.083
314
.250
014
.850
014
.800
014
.900
015
.350
0E
xecu
tion
816
.300
014
.550
014
.250
014
.250
014
.733
314
.283
314
.983
314
.833
315
.416
714
.883
315
.200
0E
xecu
tion
916
.583
314
.733
315
.066
714
.350
014
.600
014
.250
015
.183
314
.966
714
.533
315
.366
714
.500
0E
xecu
tion
1016
.050
014
.433
314
.366
714
.583
314
.500
014
.500
014
.283
314
.416
714
.383
315
.150
015
.350
0E
xecu
tion
1116
.383
314
.150
014
.183
314
.566
714
.033
314
.833
314
.183
314
.183
314
.083
314
.783
315
.316
7E
xecu
tion
1215
.933
314
.416
714
.366
714
.733
314
.316
714
.366
714
.450
014
.600
015
.216
715
.300
014
.866
7E
xecu
tion
1316
.233
314
.116
714
.866
714
.600
014
.316
714
.500
014
.266
714
.566
714
.700
015
.266
715
.366
7E
xecu
tion
1416
.550
014
.066
714
.416
714
.133
314
.250
014
.400
014
.683
314
.200
015
.216
715
.600
015
.200
0E
xecu
tion
1516
.366
714
.033
314
.433
314
.200
014
.033
314
.500
014
.516
714
.233
314
.666
714
.983
315
.100
0E
xecu
tion
1616
.383
314
.616
714
.383
314
.283
314
.733
314
.550
014
.350
014
.100
014
.550
015
.333
314
.950
0E
xecu
tion
1716
.150
014
.516
714
.916
714
.250
014
.700
014
.416
715
.000
014
.266
714
.100
014
.933
315
.633
3E
xecu
tion
1815
.700
014
.166
713
.933
314
.766
714
.750
014
.866
714
.616
714
.000
014
.650
014
.533
315
.116
7E
xecu
tion
1916
.300
014
.000
014
.333
313
.700
014
.716
714
.300
014
.550
014
.700
015
.183
314
.766
714
.650
0E
xecu
tion
2016
.516
714
.616
714
.250
014
.683
314
.083
313
.983
314
.716
714
.550
015
.300
015
.000
015
.116
7E
xecu
tion
2116
.333
313
.883
314
.250
014
.516
714
.116
714
.266
714
.250
014
.666
714
.883
314
.850
014
.583
3E
xecu
tion
2215
.800
014
.083
313
.933
314
.466
714
.200
014
.533
314
.650
015
.350
014
.433
315
.000
014
.950
0E
xecu
tion
2316
.016
714
.150
013
.733
314
.733
314
.716
714
.366
714
.766
715
.516
714
.883
314
.966
714
.716
7E
xecu
tion
2416
.283
314
.266
714
.666
714
.533
314
.983
315
.133
315
.016
715
.200
015
.000
014
.766
714
.916
7E
xecu
tion
2516
.366
714
.133
314
.266
714
.850
014
.166
714
.600
014
.033
314
.950
014
.083
315
.616
715
.233
3E
xecu
tion
2616
.066
714
.316
714
.633
314
.633
314
.433
314
.100
014
.533
314
.733
314
.683
314
.650
015
.250
0E
xecu
tion
2715
.883
314
.266
714
.233
314
.333
314
.433
314
.433
315
.216
714
.583
314
.766
715
.233
314
.916
7E
xecu
tion
2816
.283
314
.583
314
.516
714
.550
014
.350
014
.800
014
.516
714
.100
014
.133
314
.916
714
.766
7E
xecu
tion
2916
.550
014
.566
714
.750
014
.450
014
.533
315
.233
314
.716
715
.000
014
.616
715
.050
015
.016
7E
xecu
tion
3016
.066
714
.033
313
.916
713
.933
314
.900
014
.783
314
.616
714
.650
015
.500
014
.550
015
.116
7
Ave
rage
16.2
0445
14.2
9278
14.3
8111
14.4
0944
14.4
8166
14.5
4722
14.6
0001
14.6
9778
14.7
0833
15.0
3056
15.0
4390
Table
A.1
3:
Top
10R
esul
tsP
roje
ct4
Tes
t1.
93
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
20-2
121
-46
46-4
848
-49
49-5
050
-51
51-5
252
-53
10-2
09-
10E
xecu
tion
172
5454
5454
5454
5454
5657
Exe
cuti
on2
7254
5454
5454
5454
5456
57E
xecu
tion
372
5454
5454
5454
5454
5657
Exe
cuti
on4
7254
5454
5454
5454
5456
57E
xecu
tion
572
5454
5454
5454
5454
5657
Exe
cuti
on6
7254
5454
5454
5454
5456
57E
xecu
tion
772
5454
5454
5454
5454
5657
Exe
cuti
on8
7254
5454
5454
5454
5456
57E
xecu
tion
972
5454
5454
5454
5454
5657
Exe
cuti
on10
7254
5454
5454
5454
5456
57E
xecu
tion
1172
5454
5454
5454
5454
5657
Exe
cuti
on12
7254
5454
5454
5454
5456
57E
xecu
tion
1372
5454
5454
5454
5454
5657
Exe
cuti
on14
7254
5454
5454
5454
5456
57E
xecu
tion
1572
5454
5454
5454
5454
5657
Exe
cuti
on16
7254
5454
5454
5454
5456
57E
xecu
tion
1772
5454
5454
5454
5454
5657
Exe
cuti
on18
7254
5454
5454
5454
5456
57E
xecu
tion
1972
5454
5454
5454
5454
5657
Exe
cuti
on20
7254
5454
5454
5454
5456
57E
xecu
tion
2172
5454
5454
5454
5454
5657
Exe
cuti
on22
7254
5454
5454
5454
5456
57E
xecu
tion
2372
5454
5454
5454
5454
5657
Exe
cuti
on24
7254
5454
5454
5454
5456
57E
xecu
tion
2572
5454
5454
5454
5454
5657
Exe
cuti
on26
7254
5454
5454
5454
5456
57E
xecu
tion
2772
5454
5454
5454
5454
5657
Exe
cuti
on28
7254
5454
5454
5454
5456
57E
xecu
tion
2972
5454
5454
5454
5454
5657
Exe
cuti
on30
7254
5454
5454
5454
5456
57
Ave
rage
7254
5454
5454
5454
5456
57
Table
A.1
4:
Top
10R
esul
tsP
roje
ct4
Tes
t2.
94
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
49-5
050
-51
51-5
252
-53
20-2
148
-49
46-4
821
-46
10-2
09-
10E
xecu
tion
172
5454
5454
5454
5455
5657
Exe
cuti
on2
7254
5454
5454
5454
5456
57E
xecu
tion
372
5454
5454
5454
5454
5657
Exe
cuti
on4
7254
5454
5454
5454
5456
57E
xecu
tion
572
5454
5454
5454
5554
5657
Exe
cuti
on6
7254
5454
5454
5454
5456
57E
xecu
tion
772
5454
5454
5554
5454
5657
Exe
cuti
on8
7254
5454
5454
5454
5456
57E
xecu
tion
972
5454
5454
5455
5554
5657
Exe
cuti
on10
7254
5454
5454
5454
5456
57E
xecu
tion
1172
5454
5454
5454
5454
5657
Exe
cuti
on12
7254
5454
5454
5454
5656
57E
xecu
tion
1372
5454
5454
5454
5454
5657
Exe
cuti
on14
7254
5454
5454
5454
5456
57E
xecu
tion
1572
5454
5454
5454
5454
5657
Exe
cuti
on16
7254
5454
5454
5454
5456
57E
xecu
tion
1772
5454
5454
5454
5455
5657
Exe
cuti
on18
7254
5454
5454
5454
5456
57E
xecu
tion
1972
5454
5454
5454
5454
5657
Exe
cuti
on20
7254
5454
5454
5454
5556
57E
xecu
tion
2172
5454
5454
5454
5454
5657
Exe
cuti
on22
7254
5454
5454
5454
5456
57E
xecu
tion
2372
5454
5454
5454
5454
5657
Exe
cuti
on24
7254
5454
5454
5454
5556
57E
xecu
tion
2572
5454
5454
5454
5454
5657
Exe
cuti
on26
7254
5454
5454
5454
5456
57E
xecu
tion
2772
5454
5454
5454
5454
5657
Exe
cuti
on28
7254
5454
5454
5454
5456
57E
xecu
tion
2972
5454
5454
5454
5454
5657
Exe
cuti
on30
7254
5454
5454
5454
5456
57
Ave
rage
72.0
0000
54.0
0000
54.0
0000
54.0
0000
54.0
0000
54.0
3333
54.0
3333
54.0
6667
54.2
0000
56.0
0000
57.0
0000
Table
A.1
5:
Top
10R
esul
tsP
roje
ct4
Tes
t3.
95
AppendixO
rigi
nal
TO
P1
TO
P2
TO
P3
TO
P4
TO
P5
TO
P6
TO
P7
TO
P8
TO
P9
TO
P10
Dep
ende
nybr
oken
52-5
351
-52
50-5
121
-46
48-4
920
-21
49-5
046
-48
10-2
055
-56
Exe
cuti
on1
7260
6160
6062
6263
6463
64E
xecu
tion
272
6262
6262
6062
6465
6564
Exe
cuti
on3
7262
6063
6463
6164
6364
63E
xecu
tion
472
6163
6264
6062
6364
6466
Exe
cuti
on5
7261
6263
6264
6463
6264
64E
xecu
tion
672
6461
6162
6262
6262
6365
Exe
cuti
on7
7262
6260
6162
6263
6463
63E
xecu
tion
872
6262
6162
6263
6362
6463
Exe
cuti
on9
7261
6261
6063
6261
6364
66E
xecu
tion
1072
6361
6061
6165
6262
6463
Exe
cuti
on11
7261
6162
6463
6065
6166
66E
xecu
tion
1272
6062
6159
6264
6365
6466
Exe
cuti
on13
7261
6264
6063
6163
6367
65E
xecu
tion
1472
6161
6362
6160
6162
6562
Exe
cuti
on15
7261
6260
6364
6161
6063
65E
xecu
tion
1672
6062
6162
6262
6362
6464
Exe
cuti
on17
7261
6263
6162
6263
6465
62E
xecu
tion
1872
6061
6161
6260
6363
6464
Exe
cuti
on19
7261
6461
6161
6262
6165
62E
xecu
tion
2072
6358
6162
6163
6262
6465
Exe
cuti
on21
7361
6163
6361
6062
6263
64E
xecu
tion
2272
6361
6262
6362
6364
6566
Exe
cuti
on23
7261
6163
6161
6463
6465
64E
xecu
tion
2472
5960
6261
6262
6062
6564
Exe
cuti
on25
7261
6061
6062
6261
6265
65E
xecu
tion
2672
6160
6162
6063
6362
6265
Exe
cuti
on27
7260
6062
6562
6064
6464
65E
xecu
tion
2872
6159
6262
6263
5964
6264
Exe
cuti
on29
7260
6362
6262
6262
6267
63E
xecu
tion
3072
6160
6064
6163
6163
6265
Ave
rage
72.0
3333
61.1
6667
61.2
0000
61.6
0000
61.8
3333
61.8
6667
62.0
3333
62.4
0000
62.7
6667
64.1
6667
64.2
3333
Table
A.1
6:
Top
10R
esul
tsP
roje
ct4
Tes
t4.
96
Appendix B
Appendix
MAIN PROGRAM
#include <cstdlib >
#include <iostream >
#include <stdio.h>
#include <math.h>
#include <fstream >
#include <exception >
#include <ctime >
#include "Functions.h"
#include "Teams.h"
#include "Sony.h"
#include "QuotesOrder.h"
#include "Example.h"
#include "SmartPrice.h"
#include "CutOver.h"
#include "DataBase.h"
#include "SoftChoice.h"
#include "GA.h"
using namespace std;
using namespace std;
int main(int argc , char *argv []){
// //////////////////////////////////////////////////////////////////////////////
// ////////////////////////// VARIABLES & CONST /////////////////////////////////
// //////////////////////////////////////////////////////////////////////////////
// CONSTANTS
int num_iterations (1000); // Number of populations generated
int num_individuals (100); // Size of the population
97
Appendix B, Code
int top (10); // Number of best individuals to keep in the binary tournament
// VARAIBLES
// Timing
clock_t start ,finish;
double time;
// Num of executions of the GA
int exe(0);
// Resources
int num_teams (0); // Number of teams
// Composition Teams
int teams [10]; // Array to store the composition in member of every team
// Tasks
int num_tasks (0); // Number of task
int Project (0); // Variable to know which Project has been choosen
cout << " 0.- Example Project (7 Tasks; 10 Dependencies)" << endl;
cout << " 1.- Sony Project (139 Tasks; 1257 Dependencies)" << endl;
cout << " 2.- QuotesOrder Project (78 Tasks; 168 Dependencies)" << endl
;
cout << " 3.- SmartPrice Project (92 Tasks; 93 Dependencies)" << endl;
cout << " 4.- CutOver Project (107 Tasks; 83 Dependencies)" << endl;
cout << " 5.- DataBase Project (106 Tasks; 103 Dependencies)" << endl;
// cout << " 6.- SoftChoice Project (328 Tasks; ??? Dependencies )" <<
endl;
do{
cout << "Choose Project (default 0):";
cin >> Project;
}
while (( Project < 0) || (Project > 5));
switch (Project) {
case 0:
num_tasks = 7;
break;
case 1:
num_tasks = 139;
break;
case 2:
num_tasks = 78;
break;
case 3:
num_tasks = 92;
break;
case 4:
num_tasks = 107;
break;
98
Appendix B, Code
case 5:
num_tasks = 106;
break;
// case 6:
// num_tasks = 328;
// break;
}
float dur_tasks[num_tasks ]; // Array to store the duration of each task in
person/month
do{
cout << endl << "Enter number of iterations between 100 and 100 ,000: ";
cin >> num_iterations;
}
while (( num_iterations < 100) || (num_iterations > 100000));
do{
cout << endl << "Enter size of the populations between 10 and 10 ,000: ";
cin >> num_individuals;
}
while (( num_individuals < 10) || (num_individuals > 10000));
do{
cout << endl << "Enter number of TOP individuals between 2 and population ’s
size , must be even:";
cin >> top;
}
while ((top < 2) || (top > num_individuals) || ((top%2) !=0) );
do{
cout << endl << "Enter number of Teams between 2 and 10: ";
cin >> num_teams;
}
while (( num_teams < 2) || (num_teams >10));
do{
cout << endl << "Enter of executions of the GA between 1 and 30: ";
cin >> exe;
}
while ((exe < 1) || (exe >30));
// TPG
int mtpg[num_tasks*num_tasks ];
int * tpg = mtpg;
// Assigment of the Task Precedence Graph
for (int i = 0; i < num_tasks; i++)
for (int j = 0; j < num_tasks; j++)
tpg[i*num_tasks+j]=0;
// Fitness Functions
float dpff[num_individuals ]; // Fitness Function of the individuals of the
parent population
99
Appendix B, Code
for (int i = 0; i < num_individuals; i++) // Initialise fittness function
of the indivuals of the current population
dpff[i] = 0;
float * pff = dpff;
float dcff[num_individuals ]; // Fitness Function of the individuals of the
children population
for (int i = 0; i < num_individuals; i++) // Initialise fittness function
of the indivuals of the current population
dcff[i] = 0;
float * cff = dcff;
float dnff[num_individuals ]; // Fitness Function of the individuals of the new
parent population
for (int i = 0; i < num_individuals; i++) // Initialise fittness function
of the indivuals of the current population
dnff[i] = 0;
float * nff = dnff;
float iteFF[num_iterations ]; // Best Fitness Function of each of the
populations
for (int i = 0; i < num_iterations; i++) // Initialise fittness function
of the populations
iteFF[i] = 0;
float BFF(0); // Best Fitness Function
int Bite (0); // Iteration of the best fitness funtion
float averageFF (0); // Average of the best ff of all the exectuions of the GA
// Population
int mppopulation[num_individuals*num_tasks ];
int * ppopulation = mppopulation;
// Children population
int mcpopulation[num_individuals*num_tasks ];
int * cpopulation = mcpopulation;
// New Parent population
int mnpopulation[num_individuals*num_tasks ];
int * npopulation = mnpopulation;
// Probability of mutation
float n(num_tasks);
float mut_pro (1/n);
// Variables for ordering by quicksort
int inf(0);
int sup(num_individuals -1);
// //////////////////////////////////////////////////////////////////////////////
100
Appendix B, Code
// //////////////////////////////// CODE ////////////////////////////////////////
// //////////////////////////////////////////////////////////////////////////////
// system (" PAUSE ");
// Files
ofstream file;
file.open("results.txt");
// CODE
file << "Number of Iterations: " << num_iterations << endl;
file << "Size of each population: " << num_individuals << endl;
file << "Number of TOP individuals: " << top << endl;
// Teams
InitilisationTeams(num_teams ,teams ,file);
// Duration of each task in the future can be sustituted
switch (Project) {
case 0:
file << "EXAMPLE " << endl;
InitialisationExample(dur_tasks ,num_tasks ,tpg ,file);
break;
case 1:
file << "SONY PROJECT " << endl;
InitialisationSony(dur_tasks ,num_tasks ,tpg ,file);
break;
case 2:
file << "QUOTES ORDER PROJECT " << endl;
InitialisationQuotes(dur_tasks ,num_tasks ,tpg ,file);
break;
case 3:
file << "SMARTPRICE PROJECT " << endl;
InitialisationSmartPrice(dur_tasks ,num_tasks ,tpg ,file);
break;
case 4:
file << "CUTOVER PROJECT " << endl;
InitialisationCutOver(dur_tasks ,num_tasks ,tpg ,file);
break;
case 5:
file << "DATABASE PROJECT " << endl;
InitialisationDataBase(dur_tasks ,num_tasks ,tpg ,file);
break;
// case 6:
// file << " SOFTCHOICE PROJECT " << endl;
// InitialisationSoftChoice (dur_tasks ,num_tasks ,tpg ,file);
// break;
}
// --------------- VARIABLES (for breaking dependencies )
101
Appendix B, Code
int num_dep (0); // Number of dependencies of that tasks
int dep_rem (0); // Dependency removed
// --------------- PROCESS
for (int k = 0; k < num_tasks; k++){ // Process of breaking dependencies for
every task
num_dep = tpg[k*num_tasks +0]; // Number of dependencies of the task k
if ( num_dep > 0){ // There are dependencies
file << endl << "Task " << k << " has " << num_dep << " dependencies" <<
endl;
tpg[k*num_tasks +0] = num_dep - 1; // Decrease the number of dependencies
by 1. The one which is going to be removed
if (num_dep == 1){ //if there is only 1 dependency , there is no
need to reconstruct new length "0", then the program do not enter in this TPG
section
dep_rem = tpg[k*num_tasks +1];
file << "Remove dependency number 1 from task " << dep_rem << " to
task " << k << endl;
averageFF = 0;
GA(ppopulation ,cpopulation ,npopulation ,pff ,cff ,nff ,iteFF ,BFF ,Bite ,
averageFF ,exe ,tpg ,dur_tasks ,num_tasks ,num_teams ,teams ,num_individuals ,
num_iterations ,top ,inf ,sup ,mut_pro ,start ,finish ,time ,file);
file << "Remove dependency number 1 from task " << dep_rem << " to
task " << k << "with average FF: " << averageFF << endl;
}
else{
for (int h = 1; h <= num_dep; h++){ // Loop to process every dependency
dep_rem = tpg[k*num_tasks+h];
file << "Remove dependency number " << h << " from task " << dep_rem
<< " to task " << k << endl;
// TPG is reconstructed removing the dependecy
for (int l = h; l < num_dep; l++) // all dependencies are moved to
one position backwards to remove the dependency broken
tpg[k*num_tasks+l] = tpg[k*num_tasks+l+1];
tpg[k*num_tasks+num_dep] = 0; // Now there are one dependency less so
the last one is removed
averageFF = 0;
102
Appendix B, Code
GA(ppopulation ,cpopulation ,npopulation ,pff ,cff ,nff ,iteFF ,BFF ,Bite ,
averageFF ,exe ,tpg ,dur_tasks ,num_tasks ,num_teams ,teams ,num_individuals ,
num_iterations ,top ,inf ,sup ,mut_pro ,start ,finish ,time ,file);
file << "Remove dependency number " << h << " from task " << dep_rem
<< " to task " << k << " with average FF: " << averageFF << endl;
// TPG is reconstructed to the original one
for (int l = num_dep; l > h; l--) // all dependencies are moved to
one position afterwards to re -introduce the dependency broken
tpg[k*num_tasks+l] = tpg[k*num_tasks+l-1];
tpg[k*num_tasks+h] = dep_rem; // Dependency removed in restored
}
}
tpg[k*num_tasks +0] = num_dep + 1;
}
}
// Close the file with the results
file.close();
// system (" PAUSE ");
return EXIT_SUCCESS;
}
FUNCTIONS
#include <iostream >
using namespace std;
// //////////////////////////////////////////////////////////////////////////////
// //////////////////////////////// FUNTIONS ////////////////////////////////////
// //////////////////////////////////////////////////////////////////////////////
// *** Reset the completion times of each taks ***//
void Reset_completion_times(float start_time [], float end_time[], int num_tasks){
for (int i = 0; i < num_tasks ; i++){
start_time[i] = 0;
end_time[i] = 0;
}
}
// *** Print individual ***//
void PrintIndividual(int * population , int individual , int num_tasks , ofstream &
file){
file << "Individual"<< individual << ":" << endl;
for (int i = 0 ; i < num_tasks ; i ++)
file << "Task " << i << ": " << population[individual*num_tasks+i]
<< " ";
103
Appendix B, Code
file << endl;
}
// *** Finish Tasks ***//
void Finish_task(int * population ,int individual ,int task , int * tpg , float
dur_tasks[], int num_tasks , float start_time [], float end_time[],int
num_teams , int teams[], ofstream & file){
// VARIABLE
float latest_time (0); // Lastest time of the precedents tasks
float dur_task (0); // Duration of the tasks according to the team assigned
float start_time_tmp (0); // Temporary start time of the task
float end_time_tmp (0); // Temporarry end time of the task
int team;
int num_dep (0); // Number of dependencies of the tasks that it’s being checked
int pre_task (0); // Precedent task that need to be finished
// CODE
// team = population .get(individual ,i);
team = population[individual*num_tasks+task];
num_dep = tpg[task*num_tasks +0]; // Number of dependencies of task i
if ( num_dep > 0 )
for (int j = 1; j <= num_dep; j++){ // Check precedent tasks have been
finished
pre_task = tpg[task*num_tasks+j];
if ( end_time[pre_task] == 0)
Finish_task(population ,individual ,pre_task ,tpg ,dur_tasks ,num_tasks ,
start_time ,end_time ,num_teams ,teams ,file); // Complete task
if ( latest_time < end_time[pre_task] )
latest_time = end_time[pre_task ];
}
// Completion time
dur_task = 0;
dur_task = ( dur_tasks[task] / teams[team] );
104
Appendix B, Code
start_time_tmp = 0;
start_time_tmp = latest_time;
end_time_tmp = 0;
end_time_tmp = start_time_tmp + dur_task;
// Verify Overlap
// Check all the tasks performed by the team which is performing this tasks and
see
// whether there is enough gap to do the tasks , otherwise perform at the end of
the lastest task
// Traverse all the tasks finished in order to determine whether there is
overlap or not
for (int i = 0; i < num_tasks; i++){
if ( (population[individual*num_tasks+i] == team) && ( i != task ) && (
end_time[i] != 0) ){
if ( ( ( end_time_tmp < end_time[i]) && ( end_time_tmp >= start_time[i]
) ) ||
( ( start_time_tmp >= start_time[i]) && ( start_time_tmp < end_time
[i] ) ) ){
start_time_tmp = end_time[i];
end_time_tmp = start_time_tmp + dur_task;
}
}
}
// Completion times
end_time[task] = end_time_tmp;
start_time[task] = start_time_tmp;
}
// *** Fitness Function ***//
float FitnessFunction(int * population ,int individual , int * tpg , float dur_tasks
[], int num_tasks , float start_time [], float end_time[],int num_teams , int
teams[], ofstream & file ){
// VARIABLE
float latest_time (0); // Lastest time of the precedents tasks
float dur_task; // Duration of the tasks according to the team assigned
float start_time_tmp; // Temporary start time of the task
float end_time_tmp; // Temporarry end time of the task
105
Appendix B, Code
int team;
int num_dep (0); // Number of dependencies of the tasks that it’s being checked
int pre_task (0); // Precedent task that need to be finished
// CODE
// Calculate the completion time of each tasks
for (int i = 0; i < num_tasks; i++){
latest_time = 0;
start_time_tmp = 0;
end_time_tmp = 0;
team = population[individual * num_tasks + i]; // Team which perform tasks i
if ( end_time[i] == 0 ) { // Check the tasks has not been completed yet
num_dep = tpg[i*num_tasks +0]; // Number of dependencies of task i
if ( num_dep > 0 )
for (int j = 1; j <= num_dep; j++){ // Check precedent tasks have been
finished
pre_task = tpg[i*num_tasks+j];
if (end_time[pre_task] == 0) // Precedent tasks has not been finished
Finish_task(population ,individual ,pre_task ,tpg ,dur_tasks ,
num_tasks ,start_time ,end_time ,num_teams ,teams ,file); // Complete task
if ( latest_time < end_time[pre_task] )
latest_time = end_time[pre_task ];
}
// Completion times
dur_task = 0;
dur_task = ( dur_tasks[i] / teams[team] );
start_time_tmp = 0;
start_time_tmp = latest_time;
end_time_tmp = 0;
end_time_tmp = start_time_tmp + dur_task;
// Verify Overlap
// Check all the tasks performed by the team which is performing this
tasks and see
// whether there is enough gap to do the tasks , otherwise perform at the
end of the lastest task
106
Appendix B, Code
// Traverse all the tasks finished in order to determine whether there is
overlap or not
for (int k = 0; k < num_tasks; k++){
if ( ( population[individual*num_tasks+k] == team ) && ( i != k ) && (
end_time[k] != 0) ){
if ( ( ( end_time_tmp < end_time[k]) && ( end_time_tmp >= start_time
[k] ) ) ||
( ( start_time_tmp >= start_time[k]) && ( start_time_tmp <
end_time[k] ) ) ){
start_time_tmp = end_time[k];
end_time_tmp = start_time_tmp + dur_task;
}
}
}
// Final completion times
end_time[i] = end_time_tmp;
start_time[i] = start_time_tmp;
}
}
// Return the completion time
float ff(0);
for (int i = 0; i < num_tasks; i++)
if ( end_time[i] > ff )
ff = end_time[i];
return(ff);
}
// *** Initialize the populations ***//
void Fill_initial_individuals(int * population , float * ff, int * tpg , float
dur_tasks[], int num_tasks , int num_teams , int teams[], int num_individuals ,
ofstream & file ){
// Variables
bool one(false); //To indicate whether the tasks has already been assigned to
one team
int rd; //To store the random number to create the initial populations
float s_time[num_tasks ]; // Start completion time for each task
float e_time[num_tasks ]; // End completion time for each task
107
Appendix B, Code
for (int i = 0; i < num_tasks; i++){
s_time[i] = 0;
e_time[i] = 0;
}
// Code
srand(( unsigned)time (0)); //to ensure real random
// fill ramdomly the populations of the assigment between tasks and teams
// Obtain the fittness function or completion time of each population
for (int i = 0 ; i < num_individuals ; i++){
for (int j = 0 ; j < num_tasks ; j ++)
population[i * num_tasks + j] = rand()%num_teams;
ff[i] = FitnessFunction(population ,i,tpg ,dur_tasks ,num_tasks ,s_time ,e_time ,
num_teams ,teams ,file);
Reset_completion_times(s_time ,e_time ,num_tasks);
}
}
// *** Crossover1 ***//
void Crossover1(int * population , int * cpopulation ,int newindividual , int
individual1 ,int individual2 , int num_tasks , int point1 , int point2 , ofstream
& file ){
for (int i = 0; i < point1 ; i ++)
cpopulation[newindividual*num_tasks+i] = population[individual1*num_tasks+i
];
for (int i = point1; i < point2; i++)
cpopulation[newindividual*num_tasks+i] = population[individual2*num_tasks+i
];
for (int i = point2; i < num_tasks; i++)
cpopulation[newindividual*num_tasks+i] = population[individual1*num_tasks+i
];
}
// *** Crossover2 ***//
void Crossover2(int * population , int * cpopulation ,int newindividual , int
individual1 ,int individual2 , int num_tasks , int point1 , int point2 , ofstream
& file ){
for (int i = 0; i < point1 ; i ++)
cpopulation[newindividual*num_tasks+i] = population[individual2*num_tasks+i
];
for (int i = point1; i < point2; i++)
108
Appendix B, Code
cpopulation[newindividual*num_tasks+i] = population[individual1*num_tasks+i
];
for (int i = point2; i < num_tasks; i++)
cpopulation[newindividual*num_tasks+i] = population[individual2*num_tasks+i
];
}
// *** Copy Indidual ***//
void CopyIndividual(int * population1 , int * population2 , int num_tasks , int
individual , ofstream & file ){
// VARIALBES
int value;
// CODE
for (int i = 0; i < num_tasks; i++)
population2[individual*num_tasks+i] = population1[individual*num_tasks+i
];
}
// *** Copy Indidual2 ***//
void CopyIndividual2(int * population1 , int * population2 , int num_tasks , int
individual , int pos , ofstream & file ){
// VARIALBES
int value;
// CODE
for (int i = 0; i < num_tasks; i++)
population2[pos*num_tasks+i] = population1[individual*num_tasks+i];
}
// *** Swap ***//
void Swap(int * population ,float * ff , int num_tasks , int a, int b, ofstream &
file ){
// Variables
float tmp_ff;
int tmp[num_tasks ];
// Code
if (a != b)
{
tmp_ff = ff[a];
ff[a] = ff[b];
ff[b] = tmp_ff;
for (int i = 0; i < num_tasks; i++)
tmp[i] = population[a * num_tasks + i];
109
Appendix B, Code
for (int i = 0; i < num_tasks; i++){
population[a * num_tasks + i] = population[b * num_tasks + i];
population[b * num_tasks + i] = tmp[i];
}
}
}
// *** Pivot ***/
/* Implementaci n no c l s i c a de la f u n c i n Pivote. En lugar de recorrer el vector
simult neamente desde ambos extremos hasta el cruce de ndices , se recorre
desde el comienzo hasta el final */
int Partition(int * population ,float * ff , int num_tasks , int inf , int sup , int
pivotIndex , ofstream & file )
{
// Variables
float pivotValue (0);
int index (0);
// Code
pivotValue = ff[pivotIndex ];
// Mueve el pivote a la l t i m a p o s i c i n del vector
Swap(population ,ff,num_tasks ,pivotIndex ,sup ,file);
index = inf;
/* Recorre el vector moviendo los elementos menores o iguales que el pivote al
comienzo del mismo */
for (int i = inf; i < sup; i++){
if (ff[i] <= pivotValue){
Swap(population ,ff,num_tasks ,i,index ,file);
index ++;
}
}
// Mueve el pivote a la p o s i c i n que le corresponde
Swap(population ,ff,num_tasks ,index ,sup ,file);
return index;
}
// *** QuickSort for ordering a population ***//
void OrderPopulationQuickSort(int * population , float * ff, int num_tasks , int
inf , int sup , ofstream & file ){
// Variables
int pivot (0); // pivot
int pivotNew (0); // pivot new
110
Appendix B, Code
// Code
if (inf < sup){
/* Selecciona un elemento del vector y coloca los menores que l a su
izquierda y los mayores a su derecha */
pivot = sup;
pivotNew = Partition(population ,ff ,num_tasks ,inf ,sup ,pivot ,file);
/* Repite el proceso para cada una de las particiones generadas en el paso
anterior */
OrderPopulationQuickSort(population ,ff,num_tasks ,inf ,pivotNew -1,file);
OrderPopulationQuickSort(population ,ff,num_tasks ,pivotNew+1,sup ,file);
}
}
// *** Recombination of the GA ***//
void Recombination(int * population ,int * cpopulation , float * ff , int
num_individuals , int num_teams , int num_tasks , ofstream & file ){
// Variables
int inf (0);
int sup(num_individuals -1);
int point1 (0), point2 (0); // Two points to use as part of the operator
int tmp_ind1 (0), tmp_ind2 (0); // Temporary individuals for the binary tournament
int ind1 (0), ind2 (0); // Individual 1 and Individual 2 to recombine
int tmp;
// CODE
// Generate children population based of the non -top individuals
for (int i = 0; i < num_individuals; i++){
// Calculate two random point to Recombinate the population
point1 = rand() % num_tasks;
do
point2 = rand() % num_tasks;
while (point2 == point1);
// Order both points
if (point1 > point2){
tmp = point1;
point1 = point2;
point2 = tmp;
}
// Calculate First individual to recombine by binary tournament
tmp_ind1 = rand() % num_individuals;
do
tmp_ind2 = rand() % num_individuals;
111
Appendix B, Code
while (tmp_ind1 == tmp_ind2);
// Choose the one with the best FF
if (ff[tmp_ind1] < ff[tmp_ind2 ])
ind1 = tmp_ind1;
else
ind1 = tmp_ind2;
// Calculate Second individual to recombine by binary tournament
do
tmp_ind1 = rand() % num_individuals;
while (tmp_ind1 == ind1);
do
tmp_ind2 = rand() % num_individuals;
while (( tmp_ind1 == tmp_ind2) || (tmp_ind2 == ind1));
// Choose the one with the best FF
if (ff[tmp_ind1] < ff[tmp_ind2 ])
ind2 = tmp_ind1;
else
ind2 = tmp_ind2;
Crossover1(population ,cpopulation ,i,ind1 ,ind2 ,num_tasks ,point1 ,point2 ,file);
Crossover2(population ,cpopulation ,++i,ind1 ,ind2 ,num_tasks ,point1 ,point2 ,file);
}
}
// *** Mutation and evaluation of the GA ***//
void Mutation(int * population , int num_individuals , float dur_tasks[], int
num_tasks , int num_teams , int teams[], float mut_pro , ofstream & file ){
// VARIABLE
float rd;
float pro_mut (0); // Probablity of mutation for a tasks
int old_team (0), new_team (0);
// CODE
for (int i = 0; i < num_individuals; i++)
for (int j = 0; j < num_tasks; j++){
rd = rand();
pro_mut = rd / RAND_MAX;
if ( pro_mut < mut_pro ){ //if the probability calculated for that tasks is
minor that the total probability then mutated
old_team = population[i*num_tasks+j];
do
new_team = rand() % num_teams;
while (old_team = new_team);
112
Appendix B, Code
population[i*num_tasks+j] = new_team;
}
}
}
// *** Evaluation ***//
void Evaluation(int * population , int * tpg , float * ff , int num_tasks , float
dur_tasks[], int num_teams , int teams[], int num_individuals , ofstream & file
){
// Variables
float start_time[num_tasks ]; // Start completion time for each task
float end_time[num_tasks ]; // End completion time for each task
for (int i = 0; i < num_tasks; i++){
start_time[i] = 0;
end_time[i] = 0;
}
// Code
for (int i = 0; i < num_individuals; i++){
Reset_completion_times(start_time ,end_time ,num_tasks);
ff[i] = FitnessFunction(population ,i,tpg ,dur_tasks ,num_tasks ,start_time ,
end_time ,num_teams ,teams ,file);
}
}
// *** New Parent Population ***//
void GenerateNewPopulation(int * ppopulation , int * cpopulation , int *
npopulation , float * pff , float * cff , float * nff , int num_individuals , int
top , int num_tasks , int num_teams , ofstream & file){
// VARIABLES
int index1 (0), index2 (0);
int inf (0);
int sup(num_individuals -1);
int index_children (0);
int index_parent (0);
// CODE
// Ordering the parent population using quick sort
OrderPopulationQuickSort(cpopulation ,cff ,num_tasks ,inf ,sup ,file);
113
Appendix B, Code
// TOP INDIVIDUALS
// Copy Best Top Individuals from the parent and children population to New
Parent population
for (int i = 0; i < top; i++){
if ( pff[index_parent] < cff[index_children] ) {
CopyIndividual2(ppopulation ,npopulation ,num_tasks ,index_parent ,i,file);
nff[i] = pff[index_parent ];
index_parent ++;
}
else{
CopyIndividual2(cpopulation ,npopulation ,num_tasks ,index_children ,i,file);
nff[i] = cff[index_children ];
index_children ++;
}
}
//NON -TOP INDIVIDUALS
// Generate children population based of the non -top individuals
for (int i = top; i < num_individuals; i++){
// Calculate First individual to add by binary tournament
do
index1 = rand() % num_individuals *2;
while (( index1 < top) || (( index1 >= num_individuals) && (index1 <
num_individuals+top)));
// Calculate Second individual to add by binary tournament
do
index2 = rand() % num_individuals *2;
while (( index1 == index2) || (index2 < top) || (( index2 >= num_individuals)
&& (index2 < num_individuals+top)));
// Choose the one with the best FF
// Individuals from "index >= top" to "index < num_individuals " correspond to
the non -top parent population
// Individuals from "index > num_individuals + top" to "index <
num_indiciduals * 2" correspond to the non -top children population
if ( (index1 >= top) && (index1 < num_individuals) ) // index 1 in parent
population
if ( (index2 >= top) && (index2 < num_individuals) ) // index 2 in parent
population
if (pff[index1] < pff[index2 ]){
CopyIndividual2(ppopulation ,npopulation ,num_tasks ,index1 ,i,file);
nff[i] = pff[index1 ];
}
else{
CopyIndividual2(ppopulation ,npopulation ,num_tasks ,index2 ,i,file);
nff[i] = pff[index2 ];
114
Appendix B, Code
}
else // index 2 in children
population
if (pff[index1] < cff[index2 ]){
CopyIndividual2(ppopulation ,npopulation ,num_tasks ,index1 ,i,file);
nff[i] = pff[index1 ];
}
else{
CopyIndividual2(cpopulation ,npopulation ,num_tasks ,index2 ,i,file);
nff[i] = cff[index2 ];
}
else // index 1 in children
population
if ( (index2 >= top) && (index2 < num_individuals) ) // index 2 in parent
population
if (cff[index1] < pff[index2 ]){
CopyIndividual2(cpopulation ,npopulation ,num_tasks ,index1 ,i,file);
nff[i] = cff[index1 ];
}
else{
CopyIndividual2(ppopulation ,npopulation ,num_tasks ,index2 ,i,file);
nff[i] = pff[index2 ];
}
else // index 2 in children
population
if (cff[index1] < cff[index2 ]){
CopyIndividual2(cpopulation ,npopulation ,num_tasks ,index1 ,i,file);
nff[i] = cff[index1 ];
}
else{
CopyIndividual2(cpopulation ,npopulation ,num_tasks ,index2 ,i,file);
nff[i] = cff[index2 ];
}
}
}
// *** Reset ***//
void Reset(int * population , int * cpopulation , int * npopulation , float * pff ,
float * cff , float * nff , float iteFF[], int num_tasks , int num_teams , int
num_individuals , int num_iterations , ofstream & file){
for (int i = 0 ; i < num_individuals ; i++){
pff[i] = 0;
cff[i] = 0;
nff[i] = 0;
115
Appendix B, Code
for (int j = 0 ; j < num_tasks ; j ++){
population[i*num_tasks+j] = 0;
cpopulation[i*num_tasks+j] = 0;
npopulation[i*num_tasks+j] = 0;
}
}
for (int i = 0; i < num_iterations; i++)
iteFF[i] = 0;
}
GENETIC ALGORITHM
void GA(int * ppopulation ,int * cpopulation ,int * npopulation ,float * pff ,float *
cff ,float * nff ,float * iteFF , float BFF , int Bite , float & averageFF , int
exe , int * tpg ,float dur_tasks [],int num_tasks ,int num_teams ,int teams[],int
num_individuals , int num_iterations , int top ,int inf ,int sup ,float mut_pro ,
float start ,float finish ,float time ,ofstream & file){
for (int i = 0; i < exe; i++){
start = clock ();
// Fill initial individuals with data
Fill_initial_individuals(ppopulation ,pff ,tpg ,dur_tasks ,num_tasks ,num_teams ,
teams ,num_individuals ,file);
// Ordering the parent population using quick sort
OrderPopulationQuickSort(ppopulation ,pff ,num_tasks ,inf ,sup ,file);
// Genetic Algorithm
for (int iterations = 1; iterations < num_iterations; iterations ++) {
Recombination(ppopulation ,cpopulation ,pff ,num_individuals ,num_teams ,
num_tasks ,file);// Recombination (Operator)
Mutation(cpopulation ,num_individuals ,dur_tasks ,num_tasks ,num_teams ,
teams ,mut_pro ,file);// Mutation(Random change)
Evaluation(cpopulation ,tpg ,cff ,num_tasks ,dur_tasks ,num_teams ,teams ,
num_individuals ,file);
GenerateNewPopulation(ppopulation ,cpopulation ,npopulation ,pff ,cff ,nff ,
num_individuals ,top ,num_tasks ,num_teams ,file);
if ((BFF == 0) || (nff[0] < BFF)){
BFF = nff [0];
Bite = iterations;
}
// New parent become parent
ppopulation = npopulation;
pff = nff;
116
Appendix B, Code
}
// Finish time
finish = clock();
time = (double(finish)-double(start))/CLOCKS_PER_SEC;
averageFF = averageFF + BFF;
file << endl;
file << " " << BFF; // << " " << Bite << " " << time;
BFF = 0;
Bite = 0;
time = 0;
Reset(ppopulation ,cpopulation ,npopulation ,pff ,cff ,nff ,iteFF ,num_tasks ,
num_teams ,num_individuals ,num_iterations ,file);
}
averageFF = averageFF / exe;
file << endl;
}
117
Bibliography
[1] M. Harman and B. F. Jones. Search-based Software Engineering. Information and
Software Technology, 43(14):833–839, 2001.
[2] M. Harman. The Current State and Future of Search Based Software Engineering.
In FOSE 2007: 2007 Future of Software Engineering, pages 342–357, Washington,
DC, USA, 2007. IEEE Computer Society.
[3] G. Antoniol, M. Di Penta, M. Harman, and F. Qureshi. The Effect of Communica-
tion Overhead on Software Maintenance Project Staffing: a Search-Based Approach.
In ICSM 2007: Proceedings of the 23rd IEEE International Conference on Software
Maintenance, pages 315–324, Paris, France, October 2007. IEEE Computer Society.
[4] G. Antoniol, M. Di Penta, and M. Harman. Search-Based Techniques Applied to
Optimization of Project Planning for a Massive Maintenance Project. In ICSM
2005: Proceedings of the 21st IEEE International Conference on Software Mainte-
nance, pages 240–249, Washington, DC, USA, 2005. IEEE Computer Society.
[5] G. Antoniol, M. Di Penta, and M. Harman. A Robust Search-Based Approach to
Project Management in the Presence of Abandonment, Rework, Error and Uncer-
tainty. In METRICS 2004: Proceedings of the Software Metrics, 10th International
Symposium, pages 172–183, Washington, DC, USA, 2004. IEEE Computer Society.
[6] P. McMinn. Search-Based Software Test Data Generation: a Survey. Software
Testing, Verification and Reliability, 14(2):105–156, 2004.
[7] J.A. Clark and J.L. Jacob. Protocols Are Programs Too: the Meta-heuristic Search
for Security Protocols. Information and Software Technology, 43:891–904(14), 15
December 2001.
[8] E. Alba and J. F. Chicano. Software Project Management with GAs. Information
Sciences, 177(11):2380–2401, 2007.
[9] E. Alba and J. F. Chicano. Management of Software Projects with GAs. In MIC
2005: Proceedings of the 6th Metaheuristics International Conference, pages 13–18,
Viena, Austria, August 2005.
118
Bibliography Appendix B, Code
[10] S. Yoo. The Use of a Novel Semi-Exhaustive Search Algorithm for the Analysis
of Data Sensitivity in a Feature Subset Selection Problem. Master’s thesis, King’s
College London, London, UK, September 2006.
[11] B. L. Miller and D. E. Goldberg. Genetic Algorithms, Tournament Selection, and
the Effects of Noise. Complex Systems, 9:193–212, 1995.
[12] T. Tian. The Nature of Crossover Operator in Genetic Algorithms. In RSCTC
2000: Revised Papers from the Second International Conference on Rough Sets and
Current Trends in Computing, pages 619–623, London, UK, 2001. Springer-Verlag.
[13] L. Breierova and M. Choudhari. An Introduction to Sensitivity Analysis. MIT
System Dynamics in Education Project, Massachusetts, USA, 2001. URL http:
//sysdyn.clexchange.org.
[14] Kenneth M. Hanson and Franois M. Hemez, editors. Global Sensitivity Analysis:
An Introduction, Joint Research Centre of Ispra, Italy, 2005. Los Alamos National
Laboratory. URL http://library.lanl.gov.
[15] A. Lhr and K. Bletzinger. Application of Sensitivity Analysis to a Planning Process
in Architecture, Engineering and Construction (AEC). In WCSMO 2005: Proceed-
ings of the 6th World Congress on Structural and Multidisciplinary Optimization,
Rio de Janerio, Brazil, 2005.
[16] S. Wagner. A Model and Sensitivity Analysis of the Quality Economics of Defect-
detection Techniques. In ISSTA 2006: Proceedings of the 2006 International Sym-
posium on Software Testing and Analysis, pages 73–84, New York, NY, USA, 2006.
ACM.
[17] A. Saltelli. Sensitivity Analysis for Importance Assessment. Risk Analysis, 22(3):
579–590, 2002.
[18] P. Jovanovic. Application of Sensitivity Analysis in Investment Project Evaluation
under Uncertainty and Risk. International Journal of Project Management, 17:
217–222, 1999.
[19] E. W. Johnson and J. B. Brockman. Sensitivity Analysis of Iterative Design Pro-
cesses. In ICCAD 1996: Proceedings of the 1996 IEEE/ACM International Con-
ference on Computer-aided Design, pages 142–145, Washington, DC, USA, 1996.
IEEE Computer Society.
[20] W. H. Wakeland, R. Martin, and D. Raffo. Using Design of Experiments, Sensitivity
Analysis, and Hybrid Simulation to Evaluate Changes to a Software Development
119
Bibliography Appendix B, Code
Process: a Case Study. In John Wiley and Ltd Sons, editors, ProSim 2003: Pro-
ceedings of the 4th International Workshop on Software Process Simulation and
Modeling, pages 107–119, Portland, Oregon, USA, November 2004. Wiley Inter-
Science.
[21] Y. Hoon Kwak and L. Ingall. Exploring Monte Carlo Simulation Applications for
Project Management. Risk Management, 9(1):44–57, 2007.
[22] S. Wagner. Global Sensitivity Analysis of Predictor Models in Software Engineering.
In PROMISE 2007: Proceedings of the Third International Workshop on Predic-
tor Models in Software Engineering, page 3, Washington, DC, USA, 2007. IEEE
Computer Society.
120
