Quản trị rủi ro trong lập lịch dự án phần mềm sử dụng mạng bayes (risk management in software project scheduling using bayesian networks)

Our research is aimed at taking those advantages of Bayesian Networksinto software project scheduling by addressing common software project features.The research provides answers to the

MINISTRY OF EDUCATION AND TRAINING

HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY

Nguyen Ngoc Tuan

RISK MANAGEMENT IN SOFTWARE PROJECT SCHEDULING

USING BAYESIAN NETWORKS

Major: Software Engineering

Code No.: 9480103

PhD DISSERTATION ON SOFTWARE ENGINEERING

SUPERVISORS:

1 Assoc Prof Huynh Quyet Thang

2 Dr Vu Thi Huong Giang

Hanoi – 2021

Assoc Prof Huỳnh Quyết Thắng Dr Vũ Thị Hương Giang

First of all, I would like to express my sincere gratitude to my first supervisorAssociate Professor Huynh Quyet Thang for his invaluable guidance and supportthroughout my research Professor Thang has supported me all the way, all the time

It is his patience that keeps me always committed to doing this research andreaching the end of PhD student period I am also very grateful to my secondsupervisor Dr Vu Thi Huong Giang whose bright hints and expertise has beenalways helpful to me

My special thanks go to Ms Vo Thi Huong, Ms Bui Thi Quynh Nga, Mr.Tran Trung Hieu, Mr Tran The Anh, Mr Tran Bao Ngoc and Mr Cao ManhQuyen, who were master and bachelor students at School of ICT, Hanoi University

of Science and Technology and helped me with building the tools as well as testingour models

I am also indebted to Dr Nguyen Thanh Nam (former CEO of FPT andformer President of FSOFT), Mr Luu Quoc Tuan (Tinh Van Outsourcing Jsc.), Mr.Ngo Quang Vinh (Evizi), Mr Nguyen Huy Binh (FIS) who provide helpful realsoftware project data and valuable expertise judgments on the data

Finally, my greatest appreciation is to my family, especially to my wife TranThi Bich Ngoc Without their love, patience and sacrifice, this achievement wouldnever be possible

Software project management is an art and science of planning and leadingsoftware projects In software industry, project managers mostly rely on theirexperience and skills to manage their projects and lack of scientific tools to supportthem

Risk management is a crucial part of software project management that helpsprevent software disasters In this research, risks are defined as uncertain events orconditions that, if they occur, they would have a bad impact on one or moresoftware project outcomes (cost, time, quality) Identifying and dealing with risks oruncertainty in early phases of software development life cycle would lessen long-term cost and enhance the chance of the project success The most important part ofrisk management is risk analysis which assesses the risks and their impact to theoutputs of the software project To overcome subjective assessment based ondevelopment team’s experience, the team needs a quantitative risk analysis method.Software project scheduling is one part of software project planning Since inpractice, most software projects are over-budget and behind schedule, softwareproject scheduling needs to be taken into careful consideration We come up withthe following questions:

 How to schedule software projects better?

 How to better manage risks in software projects?

 How to quantitatively analyse risks?

Some researchers say that Bayesian Networks can be used to quantify uncertainfactors in (general) project scheduling and improve project risk assessment andanalysis Our research is aimed at taking those advantages of Bayesian Networksinto software project scheduling by addressing common software project features.The research provides answers to the above questions with probabilisticapproaches and tools to assess the impacts of risk factors on software projectscheduling; proposing list of common risk factors and Bayesian Network model ofthese risk factors; and proposing advanced scheduling methods based onincorporating Bayesian Networks into popular scheduling techniques such as CPM,PERT or agile iteration scheduling etc Bayesian Networks help quantify the factors,and hence help better manage them as well as enhancing the predictability of thingshappen in the project

This research first takes a literature review on (general) project planning issues,project scheduling techniques, project scheduling tools, uncertainty and riskcharacteristics in software projects, risk management processes, project risk analysis inorder to apply state-of-the-art techniques into software projects (Chapter 1).

After that, Bayesian Networks are applied in building and experimenting riskfactors in software project scheduling BRI (Bayes Risk-Impact) algorithm isproposed to assess risk factors’ impact on software scheduling (Section 2.1) Thefirst set of risk factors with 5 risk factors are examined using a probabilistic own-built tool CKDY to analyse risks in software project scheduling (Section 2.2)

The research proposes an advanced algorithm for agile iteration schedulingusing Bayesian Networks The advantages of this method are providing a scheduleand the probability of finishing agile iteration on time (Section 3.1) In addition, theauthor goes further with a more refined list of 19 risk factors in software schedulingand uses them in software scheduling methods The research also incorporatesBayesian Network with CPM and PERT scheduling techniques in traditionalsoftware projects together with the Bayesian Networks of common risk factors(Section 3.2 and Section 3.3) The list of 19 risk factors in agile softwaredevelopment is also examined in agile iteration scheduling (Section 3.4) Theexperimental results show that our models are reliable and our approaches havepractical implications, i.e we can take advantage of Bayesian Networks inmodelling and quantifying risks/uncertainty in software projects

How to read this report?

The author highly recommends that you read this report from beginning to theend However, if at any point you want to look at specific important pieces ofinformation, the following guide could be helpful:

 To get the motivation, the overview of related work, the objectives, thescope, the hypothesis and methodology of this research, please go to theIntroduction section

 To get an overview of software project scheduling and risk management in software project scheduling, please go to Sections 1.1, 1.2 and 1.3

 To get an overview of Bayesian Networks, please go to Section 1.4

 To get details on main contributions and key findings of the research, please read Chapter 2 and Chapter 3

 To get information on common risk factors in software project scheduling, you can have a look at Section 2.3

 The Chapter 2 is about building tools and doing experiments on applyingBayesian Networks into risk management in software project planning(Section 2.1) and some key risk factors (Section 2.2)

 The Chapter 3 is about incorporating Bayesian Networks and common riskfactors into software project scheduling techniques such as CPM (Section3.2), PERT (Section 3.3), Agile software development scheduling (Section3.4)

 To get to know the conclusions, the limitations as well as the further research

of the study in this PhD thesis, please read the Conclusion section

5

Acknowledgements 2

Summary 3

How to read this report? 5

List of symbols and abbreviations 10

List of tables 12

List of figures 13

Introduction 15

Motivation 15

Related work 18

Research scope 20

Research objectives 20

Scientific and realistic meaning 21

Research hypothesis and methodology 21

Expected results 21

Structure of the thesis 22

Chapter 1 Overview of software project scheduling and risk management 23

1.1 Software project management and software project scheduling 23

1.1.1 Software project management 23

1.1.2 Software project scheduling 25

1.2 Software project scheduling methods and techniques 26

1.2.1 Overview 26

1.2.2 Traditional scheduling methods and techniques 26

1.2.3 Agile software project scheduling 31

1.3 Risk management in software project scheduling 33

1.3.1 Overview of project risk management 33

1.3.2 Project risk analysis 35

1.3.3 Unknown risks 36

1.3.4 Risk aspects in software project scheduling 36

1.4 Bayesian Networks 37

1.4.1 Probabilistic approach using Bayesian Networks 37

1.4.2 Bayesian Inference 39

1.4.3 Bayesian Networks and project risk management 40

1.5 Chapter remarks 42

Chapter 2 Common risk factors and experiments on Bayesian Networks and software project scheduling 44

2.1 Application of Bayesian Networks into schedule risk management in software project 44

2.1.1 Common risk factors in software project management 45

2.1.2 Bayesian Networks of risk factors 46

2.1.3 Risk impact calculation 58

2.1.4 Bayesian Risk Impact algorithm 61

2.1.5 Tool and experiments 61

2.1.6 Conclusion and contribution 66

2.2 Experiments on common risk factors 67

2.2.1 Discovering the top ranked risk factors 68

2.2.2 Tool CKDY 71

2.2.3 Experiments and analysis 73

2.2.4 Conclusion and contribution 77

2.3 Proposed common risk factors in software project scheduling 78

2.3.1 The 19 common risk factors in traditional software project 78

2.3.2 The 19 common risk factors in agile software project 80

2.4 Chapter remarks 82

7

Chapter 3 Incorporation of Bayesian Networks into software project

scheduling techniques 83

3.1 Applying Bayesian Networks into specific software project development 83

3.1.1 Introduction 83

3.1.2 Optimized Agile iteration scheduling 84

3.1.3 Optimization model for Agile software iteration 85

3.1.4 Tool and experimental results 90

3.1.5 Conclusion and contribution 94

3.2 Incorporation of Bayesian Networks into CPM 94

3.2.1 The RBCPM Model 95

3.2.2 The RBCPM Method 98

3.2.3 Tool and experimental results 99

3.2.4 Conclusion and contribution 103

3.3 Incorporation of Bayesian Networks into PERT 104

3.3.1 Proposed model 104

3.3.2 Tool development and data collection 108

3.3.3 Experimental results and analysis 112

3.3.4 Conclusion and contribution 114

3.4 Incorporation of Bayesian Networks into Agile software development scheduling 114

3.4.1 Optimization model for Agile software iteration 115

3.4.2 Tool and experimental results 115

3.4.3 Conclusion and contribution 117

3.5 Chapter remarks 118

Conclusion 119

What has been done 119

Main contributions 119

Limitations 119

8

Further research 120

List of scientific publications 121

References 122

Index 130

List of symbols and abbreviations

22 PRM Project Risk Management

25 RAMP Risk Analysis and Management for Projects

List of tables

Table 1.1 Basic mathematical notations used for CPM calculation 27

Table 1.2 The differences between waterfall and agile projects 32

Table 2.1 Hui and Liu’s common risk factors [9] 45

Table 2.2 Risk factors in the phases 64

Table 2.3 Risk factors, consequences and impact 68

Table 2.4 Examples of risk factors and probabilities 70

Table 2.5 Probability of risk factors in the whole project with data set 1 74

Table 2.6 Probability of risk factors in the whole project with data set 2 75

Table 2.7 Probability of the experimental risk factors to compare with MSBNx 76

Table 2.8 CKDY compared with MSBNx 77

Table 2.9 List of 19 common risk factors for software project scheduling 79

Table 2.10 List of 5 risk factors for software project scheduling in Section 2.2 80

Table 2.11 List of 19 risk factors in iteration scheduling 81

Table 3.1 The first data sample 91

Table 3.2 The probability table for tasks and resources 92

Table 3.3 Risk factors analysis 96

Table 3.4 Data sample 1 100

Table 3.5 Data sample 2 101

Table 3.6 Task attributes of the first data sample 110

Table 3.7 Task attributes of the second data sample 110

Table 3.8 Task attributes of the third data sample 111

Table 3.9 The result for the first data sample 115

List of figures

Figure 1.1 Activities of project management according to PMBOK Guide 25

Figure 1.2 CPM parameters in an activity 28

Figure 1.3 An example of BN which represents a simple case 39

Figure 2.1 A sub BN for the risk factor “Staff experience shortage” 47

Figure 2.2 A sub BN for the risk factor “Reliance on few key person” 47

Figure 2.3 A sub BN for the risk factor “Schedule pressure” 48

Figure 2.4 A sub BN for the risk factor “Low productivity” 48

Figure 2.5 A sub BN for the risk factor “Lack of staff commitment” 49

Figure 2.6 A sub BN for the risk factor “Lack of client support” 49

Figure 2.7 A sub BN for the risk factor “Lack of contact person competence” 50

Figure 2.8 A sub BN for the risk factor “Lack of quantitative historical data” 50

Figure 2.9 A sub BN for the risk factor “Inaccurate cost estimating” 51

Figure 2.10 A sub BN for the risk factor “Large and complex external interface” 51 Figure 2.11 A sub BN for the risk factor “Large and complex project” 51

Figure 2.12 A sub BN for the risk factor “Unnecessary features” 52

Figure 2.13 A sub BN for the risk factor “Creeping user requirement” 52

Figure 2.14 A sub BN for the risk factor “Unreliable subproject delivery” 52

Figure 2.15 A sub BN for the risk factor “Incapable project management” 53

Figure 2.16 A sub BN for the risk factor “Lack of senior management commitment” 53

Figure 2.17 A sub BN for the risk factor “Lack of organization maturity” 54

Figure 2.18 A sub BN for risk factor “Immature technology” 54

Figure 2.19 A sub BN for the risk factor “Inadequate configuration control” 55

Figure 2.20 A sub BN for the risk factor “Excessive paperwork” 55

Figure 2.21 A sub BN for the risk factor “Inaccurate metrics” 56

Figure 2.22 A sub BN for risk factor “Excessive reliance on a single process improvement” 56

Figure 2.23 A sub BN for the risk factor “Lack of experience with project environment” 57

Figure 2.24 A sub BN for the risk factor “Lack of experience with project software” 57

Figure 2.25 The overall BN for software risk factors 58

Figure 2.26 A simple example of Bayesian inference 59

Figure 2.27 The three nodes of a simple-chain BN 60

Figure 2.28 The graphical interface of the tool 62

Figure 2.29 Result of experiment 1 63

Figure 2.30 Results of the three experiments 65

Figure 2.31 Experimental results for Software Design phase 66

Figure 2.32 Sub BN 1 69

Figure 2.33 Sub BN 2 69

Figure 2.34 The overall BN model 70

Figure 2.35 Experiment with j30 with the early start schedule 74

Figure 2.36 Activity joint in the file j301_1.rcp 75

Figure 2.37 Diagram of probabilities of finishing phase by phase 75

Figure 3.1 Home GUI of tool BAIS 90

Figure 3.2 Gantt chart for SPT strategy 92

Figure 3.3 A part of a BN for 19 risk factors 95

Figure 3.4 Task’s parameters and connection to other tasks 98

Figure 3.5 A screenshot of RBCPM 99

Figure 3.6 A result for experiment with data sample 1 102

Figure 3.7 A result for experiment with data sample 2 103

Figure 3.8 Bayesian Network for each activity 105

Figure 3.9 Risk integration network model into PERT scheduling 106

Figure 3.10 Process in improved RBPERT Model 107

Figure 3.11 The input screen of the RBPERT tool 108

Figure 3.12 The input file type of the RBPERT tool 109

Figure 3.13 A result for the network provided by the RBPERT tool for the first data sample 111

Figure 3.14 A result for RBPERT network provided by the tool for the first data sample 113

Figure 3.15 A result for experiment with the third data sample (distribution of Total Duration of activity J) 113

Figure 3.16 A screenshot of tool BAIS 115

Figure 3.17 The result of the second experiment 117

Motivation

Projects in general always involve risks and project managers’ regular worriesare concerns about risks In October 2008, the Hanoi Urban Railway Project Line2A (Cat Linh-Ha Dong) was approved to be invested with the total budget of morethan 8.700 billion VND (552 million USD) Until now, the project’s investment hadalmost doubled to 868 million USD It was scheduled to be put into service in 2013but until now the project remains incomplete [1]

Software projects also have schedule risks, and as a consequence, budget or costrisks For example, the project on the Vietnamese National Population Database wasapproved to be invested in 2015 [2] and was planned to be finished in two years(2016 and 2017) However, the system can only be put into operations in February

2021 Another similar example is the project on Vietnamese National Public ServicePortal which was planned to come public in September 2016 [3] but was onlyopened since December 2019 As a matter of fact, the majority of software projectsthe author has experienced in Vietnam are behind schedule (some of the projectswill be examined in Chapter 2 and Chapter 3)

Even in developed countries, software projects are facing ongoing problems.For example, the project Universal Credit - the welfare payment system owned bythe Central Government of the United Kingdom - started in 2013 The projectschedule has slipped, with the final delivery date now expected to be 2021, althoughthe system is gradually being introduced In 2013, only one of four planned pilotsites went live on the originally scheduled date, and the pilot was restricted toextremely simple cases [4]

Many software projects have suffered from significant budget overruns togetherwith a series of delays, which cause either temporary issues or permanent failures.For example, The Queensland Health Payroll System was launched in 2013 in whatcould be considered one of the most spectacularly over budget projects in Australianhistory, coming in at over 200 times the original budget Besides, in spite ofpromises that the new system would be fully automated, the new system required aconsiderable amount of manual operation [5] Another example for software projectpermanent failure case is the project e-Borders for an advanced passengerinformation programme which aimed to collect and store information on passengersand crew entering and leaving the United Kingdom Started in 2007, the project had

a series of delays and had to be cancelled in 2014 [6]

Some researches pointed out that most of the software projects (83.8%) are overbudget or behind schedule and 52.7% of software development projects deliversoftware with fewer features than originally specified [7, 8] Statistics also showthat 31.1% of development projects end up being cancelled or terminatedprematurely Among those completed projects, only 61% of them satisfy originallyspecified features and functions [9] In the software industry, one of the greatestchallenges that development teams constantly face with is to keep the projects undercontrol in terms of budget and schedule (development time frame) The activities of

a software project are influenced by internal and external factors (from that projectorganization) that make it uncertain whether the project will achieve its objectives.The effect that this uncertainty has on the project’s goals is called risk [10] In theother words, risk is an event or an uncertain condition that, if it occurs, will have a

positive or negative effect on at least one of the project objectives [11] In this

thesis, risks are defined as uncertain events or conditions that, if they occur, they would have a bad impact on one or more software project outcomes (cost, time, quality).

The above situation raises an important question: how projects’ risks aremanaged better in order to get rid of the temporary issues as well as preventing fromfailure?

The purpose of project management is to lead the project to success A

successful software project certainly relies on many factors (e.g followingappropriate processes and tasks, managing risks properly etc.) Since risks areinevitable in projects, risk management has become an important part of projectmanagement Although many researchers, experts and writers have proposed variety

of processes and techniques, project risk management (PRM) is still rapidlyevolving and handling risks in general projects as well as software projects remains

a challenge

Concerning PRM, an important component is risk analysis which also known orconsidered the same as risk quantification Risk analysis attempts to measure risksand their impacts on different project outcomes (i.e., time, cost, quality) Manysoftware projects fail since project managers mostly plan based on their experienceand there is a lack of scientific methods to support them To overcome subjectiveassessment based on development team’s experience, the team needs a quantitativerisk analysis method Although various researches have proposed and examined arange of processes and techniques and software project risk management iscontinuously evolving, handling uncertainty in more and more complex real-worldprojects remains a challenge

Aside from that, project scheduling (a part of project planning – an early phase

of software development life cycle) is concerned with the techniques that can beemployed to manage the activities that need to be undertaken during thedevelopment of a project There are various techniques for project scheduling, fromsimple and easily understandable ones such as Task List, Gantt Chart, ScheduleNetwork Analysis, to more complicated ones like Critical Path Method (CPM),Program Evaluation and Review Technique (PERT), Monte-Carlo Simulation(MCS) or Fuzzy Logic etc [10, 12, 13, 14]

Traditional project scheduling under risk/uncertainty has attracted moreresearch and attention in the project management community In some of the projectmanagement literature in 1990s, “risk analysis” was equivalent to “the analysis ofrisk on project plan” [15] This thesis focuses on modelling risks in software projecttime management (of course, it is indirectly related to other project outcomes whichare cost and quality) In other words, this thesis concentrates on quantitative riskanalysis in software project scheduling

The earliest studies incorporating uncertainty/risk in project scheduling were inthe late 1950’s by Malcolm et al [16] and Miller [17] Since then, a variety oftechniques have been introduced, several tools have been developed, and many ofthem are widely used throughout different industries However, they often fail tocapture uncertainty properly and/or produce inaccurate, inconsistent and unreliableresults, especially when applied to software projects which have specificallydifferent attributes to other traditional projects

Project uncertainty has several aspects of which not all can be categorized andtreated as risks Several authors such as Ward and Chapman [18] argued that projectrisk management should be focusing on managing uncertainty and its varioussources rather than emphasizing a set of possible events that might have bad impacts

on project performance (i.e., should be aware more about uncertain aspects ratherthan fixed set of defined risks) However, since this thesis is about software project,risks are considered and treated the same as uncertainty Most of quantitativetechniques and methods in the current practice of project risk management are based

on the “Probability Impact” concept, which have certain shortcomings in terms ofrisk analysis in project scheduling More sophisticated methods and techniques areneeded to address as well as managing important sources of uncertainty/ risk

In software industry, project scheduling also has to deal with the fact thatresources such as human, time, technology and money are not always pre-determined [19] There are always risks in software project scheduling as well In

17

most of the projects, the activity (from now on is considered the same as the “task”

in software projects) times are not known for certain Therefore, they may beassumed as random variables

Furthermore, Bayesian Networks (BNs) have attracted a lot of attention indifferent fields (construction, R&D etc.) as a powerful approach for decisionsupport under uncertainty A BN is a graphical and mathematical model whichoffers a powerful, general and flexible approach for modelling risk and uncertainty.Its capability of modelling causality and also conditional dependency betweenvariables make it perfectly suitable for capturing uncertainty in projects Yet, BNsare rarely applied in project risk management in general as well as in softwareproject management and software project scheduling

The author of this thesis strongly believes that if we can identify and controlrisks at early stages of software development project, we can significantly increasethe chance of success of the project Since it is not easy (or impossible) to controlall of the problems or factors, this thesis only focus on time factors which related tosoftware development schedule

Therefore, this thesis aims at introducing an advanced approach as well asfinding a better model for incorporating and managing uncertainty/risks in softwareproject scheduling The idea is to use BNs to perform the well-known schedulingtechniques such as CPM, PERT etc as well as modelling risk factors in softwareproject scheduling The proposed approach enriches the benefits of schedulingtechniques by incorporating uncertainty/risk factors and adding the strong analyticalpower of BNs

Related work

There have been various researches on applying BNs in to general projects.Khodakarami [19] applied BNs into general project scheduling with two casestudies of aircraft design and health and fitness center design and construction Ali

et al [20] combined Monte Carlo Simulation and Bayesian Networks methods topresent a structure for assessing the aggregated impact of risks on the completiontime of a construction project Lee and Shin [21] proposed an application of BNsinto risk management of ship building project and proposed 26 risks Sharma andChanda [22] developed a BN model for prediction of R&D project success whichalso assesses based on R&D project risk factors Khodakarami et al [23] alsoexamined an approach to generate project schedules that incorporates risk,uncertainty, and causality using BNs Their model empowered the traditional CPM

to handle uncertainty, and they also provided explanatory analysis to elicit,represent, and manage different sources of uncertainty in project planning Fenton

and Neil [25] introduced AgenaRisk as a probabilistic tool based on BNs; Chang,

Yu, and Cheng [26] proposed a risk-based Critical Path Scheduling Method based

on 2 risk categories and 7 risk levels which applied into construction projects

Regarding risk factors in software projects, Hui and Liu [9] selected 24 riskfactors that may cause potential impacts on (the whole) software project and appliedBNs properties in the calculation of impact in their project risk model Kumar andYadav [24] considered quantitative features and causal relationships among riskfactors in software projects They introduced a probabilistic approach to assess risks

in software projects as well as proposing a list of 27 risk factors (in softwareprojects) However, they analysed risks for the whole software projects and did notfocus on the scheduling and planning phases which would decide the success ofprojects Adjusting Kumar and Yadav’s method, this thesis proposes the list of 5most crucial risk factors as well as building the tool CKDY to examine risks insoftware scheduling (Section 2.2)

There have been some other researches on BNs and software risks’ analysis Hu

et al [27] studied causality analysis among risk factors and project outcomes forsoftware development projects For this purpose, they proposed a modellingframework based on BNs to deal with causality constraints in risk analysis Thedeveloped framework can be used for discovering new causal relationships andvalidating existing relationships among risk factors and project outcomes Anthony

et al [28] proposed a risk assessment model for decision-making in softwaremanagement which consists of processes and component of risk assessment in threegroups: operational risks, technical risks and strategic risks Rai et al [29] believedthat managing projects is managing risks and identified 43 risk indicators in AgileSoftware Development

One notable research is from Akos Szoke’s PhD dissertation in 2014 whichproposed an optimized algorithm for agile software project scheduling [30]

As can be seen from literature review, much research on software risk analysisfocuses on finding out the relationship risk factors and software outcomes, but lack

of a quantitative approach and causal relationship between risk factors [9, 24, 31,32] Some other researches pay attention to define the quantitative approach and thecausal relationship between risk factors and assess risks for the whole softwareproject [33, 34] but does not pay enough attention to model risk factors from thescheduling (in the planning) phase – the phase decides the failure or success of theproject later on

J Yong and Z Zhigang [35] proposed a PERT Bayesian Network (PERTBN)model with the modelling methodology and the conditional probability calculation

method of different kinds of procedure arrangement (single-chain, centralized,distributed) and stated that with PERTBN model, the effectiveness of the projectschedule control and optimization are ensured However, the research did notexamine more in-depth on the risk factors or other specific software features thatcan have impacts on the project schedule.

In addition, there is always a need for properly schedule control in softwareprojects to determine the instant status of the schedule, to know if the schedule haschanged, and to embrace changes when they occur In order to do that, influentialfactors that cause schedule changes need to be carefully considered

In summary, current researches related to this thesis are either on riskmanagement or assessment for the whole software project or for other project(construction, building, R&D etc.) scheduling There is a need of probabilisticmethod on risk management in software project scheduling as well as examiningdeeper the risk attributes of software project scheduling

Research scope

The research is about software projects (or software development projects),having common features and also specific features in comparison to other type ofprojects (such as construction projects, R&D projects etc.) Unfortunately, therehave been only a few good researches on applying probabilistic methods onsoftware development projects Therefore, this method first has a literature review

on common projects to look for approaches applied for them, and after that proposesthe approach applied for software projects

The scope of this research is on risk management in software projectscheduling This is quantitative risk management which concerns about risksaffecting project schedule (or project time frame) In terms of project schedulingtechniques, this thesis focuses on the most popular techniques such as CPM, PERTfor traditional software development projects, as well as Agile software projectscheduling

Research objectives

The main objectives of this research are:

1) To find out a quantitative method to better assess and analyse risks insoftware project scheduling In order to achieve this objective, the research has toanswer to following questions: what are the risks’ attributes of software projectscheduling? How to manage risks in software project scheduling better?

In other words, the research aims at analyzing and modelling risks in software project scheduling.

2) To find out a probabilistic method to improve well-known software projectscheduling techniques, including both techniques for traditional software schedulingand agile software scheduling

The proposed methods and models would enhance risk management process by

a quantitative assessment of risks impact on software project scheduling If weapply this model and method in practice, the author of this thesis expect that itwould help predict, monitor project schedule better as well as making appropriatedecisions

Scientific and realistic meaning

The proposed methods and model would enhance risk management process by aquantitative assessment of risks impact on software project scheduling

If we apply this model and method in practice, it would help predict, monitorproject schedule better as well as making appropriate decisions

Research hypothesis and methodology

The hypothesis of this thesis is that it is possible to use BNs to quantifyuncertainty in software project scheduling and improve software project riskassessment

Since there is very limited research on this topic, the research methodologycomprises a literature reviews from general project management to get the relevantideas for software project management Firstly, a literature reviews to investigatethe current state of project scheduling under uncertainty which determines the need,scope and objectives of the new approach Secondly, a literature review follows onthe background, theory and application of BNs This provides the conceptual andthe fundamental background for the new approach

The research also examines the features of software projects, both in waterfallmodel and agile software development model In order to handle risks in softwareproject scheduling, the common risk factors are also needed to be examined

Within the research, tools are built to validate the models and help softwareproject managers in assessing risks and making appropriate decisions

Expected results

Following the above methodology, the author expects to:

1) Apply Bayesian Networks to develop an algorithm and tool to assess theimpacts of risks and hence proposes common risk factors in software projectscheduling.

2) Apply Bayesian Networks to develop a probabilistic approach to enhance thecommon scheduling techniques (for both traditional software development and agilesoftware development) in terms of risk management and predictability

Structure of the thesis

An overview of the main chapters is as follows:

Chapter 1 briefly reviews software project scheduling and software project riskmanagement process and explores the currently popular techniques in projectscheduling

Chapter 2 consists of initial attempts of applying BNs into risk management insoftware project scheduling as well as experiments on common risk factors insoftware project scheduling 19 common risk factors for both traditional softwaredevelopment projects and agile software projects are proposed

Chapter 3 incorporates BNs into popular software project schedulingtechniques, namely CPM, PERT and agile software scheduling BNs are alsoapplied in examining the relationships among risk factors proposed in Chapter 2.Chapter 4 concludes the thesis and points the way forward for future research

The main contributions and results of the research: The research has

developed the algorithm BRI (Bayes Risk-Impact) and the tool CKDY to assess theimpacts of risks and hence proposes common risk factors in software projectscheduling Based on literature review and experiments, the research has come upwith 19 common risk factors in software project scheduling (for both agiledevelopment style and traditional development style)

The research also proposes advanced scheduling methods in software projectdevelopment The methods based on incorporating Bayesian Networks and commonrisk factors models into popular software scheduling techniques such as PERT,CPM, and Agile software development, with the examination of the model of 19common risk factors Tools have been built to experiment the proposed schedulingmethods and models Experimental results show that the proposed methods andmodels are reliable as well as providing practical value to software developmentteams in analyzing, monitoring and predicting risks and the chance of success of theproject

Chapter 1 Overview of software project scheduling and risk management

1.1 Software project management and software

project scheduling

1.1.1 Software project management

Software project management is an art and science of planning and monitoringsoftware projects It refers to the branch of project management dedicated to theplanning, scheduling, resource allocation, implementation, tracking and delivery ofsoftware and web projects [36, 37]

There are various types of projects (R&D projects, construction projects,information system projects, software projects etc.) which are associated withdifferent styles of management Software project management is quite distinct fromtraditional or other project management Firstly, software is developed, notmanufactured Therefore, the product (working software) is intangible and uniquelyflexible Secondly, software engineering is not recognized as an engineeringdiscipline with the same status as mechanical, electrical engineering etc Moreover,software projects have a unique lifecycle process that requires multiple rounds oftesting, updating, and customer feedback That software development process is notstandardized Lastly, most software projects are “one-off” projects Softwaredevelopment team can only use similar experience, not the same experience orrepeated process

Therefore, software project management is about the methodology to organizeall activities related to the software We always need project management sincesoftware projects always have constraints of budget and time frame

Nowadays, most IT-related projects are managed in the agile style and software

is developed in groups, in order to keep up with the increasing pace of business, anditerate based on customer and stakeholder feedback Besides being used in IT-related projects, Agile style has also been increasingly used in other projectmanagement

The project manager leads the project team and often plays the central roleamong the investors (or customers), the suppliers and the senior management of theorganization He or she makes sure the project complies with the constraints as well

as delivering the product (software) on time Software project managers may have

to do any of the following tasks: [37]

- Planning and scheduling: This means putting together the blueprint for theentire project from ideation to fruition It will define the scope, allocate necessaryresources, propose the timeline, delineate the plan for execution, lay out acommunication strategy, and indicate the steps necessary for testing andmaintenance.

- Leading: A software project manager will need to assemble and lead theproject team, which likely will consist of developers, analysts, testers, graphicdesigners, and technical writers This requires excellent communication, people andleadership skills

- Execution: The project manager will participate in and supervise thesuccessful execution of each stage of the project This includes monitoring progress,frequent team check-ins and creating status reports

- Time management: Staying on schedule is crucial to the successful completion

of any project, but it is particularly challenging when it comes to managing softwareprojects because changes to the original plan are almost certain to occur as theproject evolves Software project managers must be experts in risk management andcontingency planning to ensure forward progress when roadblocks or changesoccur

- Budget: Like traditional project managers, software project managers aretasked with creating a budget for a project, and then sticking to it as closely aspossible, moderating spend and re-allocating funds when necessary

- Maintenance: Software project management typically encourages constantproduct testing in order to discover and fix bugs early, adjust the end product to thecustomer’s needs, and keep the project on target The software project manager isresponsible for ensuring proper and consistent testing, evaluation and fixes arebeing made

Therefore, managers have diverse roles Since software project management isnormally concerned with activities involved in ensuring that software is delivered

on time, on schedule and in accordance with the requirements of the organizations

developing and procuring the software, managers most significant activities are

planning, estimating and scheduling.

According to Project Management Institute (PMI) in Project Management Body

of Knowledge (PMBOK) guide [11], project management includes five stages orprocess groups: Initiating, Planning, Executing, Monitoring and Controlling, andClosing (Figure 1.1)

In modern software project planning, the two essential tasks are project riskmanagement and project scheduling They play crucial roles to make sure theproject is effectively and efficiently organized, including resources (hardware,software, and network) allocation, task and personnel assignment and monitoring[11, 14] Software projects are quite different to other projects since softwarerequirements are continuously changing (during software development life cycle),software projects are often behind schedule and over budget Moreover, in reality,many software project managers either ignore or do not take appropriate riskmanagement This leads to project failure or customer complains on the quality, theschedule or the over budget of the project Some other project managers who areaware of risk management, but they only rely on their own team skills orexperience, even if they follow the capability maturity models CMM/CMMi(Capability Maturity Model Integration) or PMP (Project Management Professional)[38] As can be seen in Figure 1.1, risk management affects all the processes inProcess Groups In addition, project teams could adjust or update the planningprocess while they are executing, monitoring and controlling their projects.

Figure 1.1 Activities of project management according to PMBOK Guide.

1.1.2 Software project scheduling

Software project scheduling is one of the most demanding tasks for softwareproject managers It is all about resources allocation during the project life cycle Insimple words, software project scheduling is splitting the whole project into smallertasks and estimates the required time and resources to complete each task Softwaredevelopment teams normally try to organize tasks concurrently to make optimal use

of workforce as well as minimizing task dependencies to avoid delays caused by

one task waiting for another to complete In reality, software project scheduling isdependent on project managers’ intuition and experience.

In real-life software project, a schedule is represented as a set of activitydiagrams (Work Breakdown Structure, Activity Charts) which clarifies thedependencies between activities (tasks) and personnel assignment

1.2 Software project scheduling methods and techniques

1.2.1 Overview

There are many popular techniques for project scheduling, include:

 Graphical representations used to illustrate the project schedule such as

o Work Breakdown Structure: show project breakdown into tasks

o Activity Charts: show task dependencies and the critical path oGantt Charts: Bar charts show schedule against calendar time

 Critical Path Method – CPM [14, 19, 23, 39]

 Program Evaluation and Review Technique – PERT [16, 17, 19, 40]Project scheduling (especially under uncertainty) is the most widely studiedarea of risk quantification in project management Producing a reasonable andreliable project schedule is one of the crucial tasks of project managers Moreover,having a realistic schedule for the project is one of the most cited factors of projectsuccess [41] Several techniques are proposed for modelling risk and uncertainty inproject scheduling [14, 40, 42]

This section reviews some notable techniques CPM and PERT are the classicalapproaches for project scheduling Simulation-based techniques are more modernapproach that is adopted by many project management software tools and someargue the best practice available Alternative approaches are Critical Chain Methodand Fuzzy logic will be reviewed briefly Last but not least, scheduling techniqueand method for agile software development will also be discussed

1.2.2 Traditional scheduling methods and techniques

a) Critical Path Method (CPM)

Critical Path Method (CPM) is one of the most famous techniques in projectscheduling Developed in 1957 by DuPont, CPM has become the standard technique

in project management and most project management tools support CPM

calculation [39] According to Pollack-Johnson and Liberatore [43], almost 70% ofproject managers or professionals use CPM CPM calculation includes thefollowing steps:

 Specify the individual activities using a work breakdown structure

 Determine the sequence of those activities and dependency between them

 Draw a network diagram (that models the activities and their dependency)

 Estimate the completion time (duration) for each activity

 Identify the critical path (the shortest-duration path through the network)

 Update the CPM diagram as the project progresses

The basic mathematical notations used for CPM calculation is shown in theTable 1.1 In fact, the parameters D, ES, EF, LF, LS are common used in schedulingtechniques

Table 1.1 Basic mathematical notations used for CPM calculation

without = LFj – EFj

increasing theoverall projectcompletion time

A critical activity is the one with no float time (TF = 0) and should receivespecial attention, since delay in critical activity will lead to delay the whole project.Informally, the critical path is determined by performing forward and backwardpasses through the project network The forward path computes the earliest start(ES) and the earliest finish (EF) time for each activity The backward path computesthe latest start (LS) and the latest finish (LF) time for each activity The total floatfor each activity is the difference in the latest and earliest finish of each activity

[19] The connections among these parameters in an activity are described in Figure1.2.

Therefore, CPM is a deterministic model which uses a fixed time estimate foractivities Although CPM (“pure deterministic in nature” [25]) was not developed tohandle or quantify uncertainty, it does provide very useful information aboutrelations between activities, activities time and the overall project schedule (so thatproject scheduling can be controlled)

Figure 1.2 CPM parameters in an activity

b) Program Evaluation and Review Technique (PERT)

PERT was introduced in 1957 by the US Navy as one of earliest researchincorporating risk in project management [17, 19] A special feature of PERT is itsability to handle uncertainty in activity duration This means if there is a variation intime estimate of an activity; it may affect the whole project PERT methodology isdeveloped to help completing the project successfully when the time estimate is notdefinitive

In order to do that, instead of a single estimation in CPM, PERT provides a betaprobability distribution to each project activity Three time estimates (optimistic,most likely, and pessimistic time estimates) can be obtained and can be used toestimate the expected time and the standard deviation for an activity i

Optimistic time estimate is the estimate determined considering all favorableconditions; i.e in the best-case scenario or when everything goes right In otherwords, this is the shortest time in which the activity may be completed.

Most likely time estimate is the time duration where there is a high probability

of completing the activity within the given time duration In other words, it is theestimate in case of normal problems or opportunities

Pessimistic time estimate is the estimate determined when we consider allunfavourable conditions; i.e in the worst case scenario or when everything goescompletely wrong In other words, this is the longest time the activity might require

to complete

Expected time: μi = (Optimistic + 4xMost likely + Pessimistic)/6

Standard deviation: σi = (Pessimistic – Optimistic)/6

The critical path is the sequence of project activities that determines the earliesttime by which the project can be completed, and the total duration determines thecompletion date of the project PERT assumes that only one path is the critical pathand that the path does not change Therefore, managers using PERT are advised tofocus on these critical activities to ensure the project completion date remainsunchanged The expected value of a critical path is calculated by the expected value

of each activity, and the variance of the critical path is the sum of the variances ofall activities in the path Based on the calculation, the probability that the projectwill be completed by a certain date can be calculated Therefore, PERT is somehowsimilar to CPM The main difference is that each activity in a PERT network has a

variance associated with its completion time In other words, CPM is deterministic,

while PERT is somehow probabilistic.

c) Simulation-based techniques

Monte Carlo Simulation (MCS) was first proposed for project scheduling in theearly 1960s [44] However, it was not until the 1980s when sufficient computerpower became available that simulation became the dominant technique forhandling risk and uncertainty in projects [45, 46] In its simplest approach, MCSuses the project activity diagram

The duration of each activity is estimated by shortest, most likely and longestduration and also the shape of the distribution (such as Normal, Beta etc.) Thencritical path calculation is performed several times, each time using random valuesfrom the activities’ distribution function

More advanced tools like PertMaster (Oracle Primavery Risk Analysis [47]) usesimulation-based approach not only for handling uncertainty in duration and cost,but also for providing a whole risk analysis process They can link the projectschedule to the risk register and apply simulation-based techniques to carry outprobability impact analyses.

A survey by the Project Management Institute [48] showed that nearly 20% ofproject management software packages support Monte Carlo Simulation Anothersurvey by Pollack-Johnson and Liberatore in 2003 [49] found that 17% of projectmanagers used probabilistic analysis and/or simulation within project managementsoftware

However, simulation has its own drawbacks One serious methodological flaw

in traditional MCS of project networks is the assumption of statistical independencefor individual activities which share risk factors in common with other activities[43] Most available simulation packages assume that the marginal distributions ofuncertainty for individual activities in the project completely define the multivariatedistribution for project schedule It is intuitively obvious that this assumption ishighly suspect for many projects which involve multiple activities of a similar typeand/or have different activity types, which are influenced by common risk factors.van Dorp and Duffey in 1999 [50] demonstrated that failure to model such types ofrisk dependence during MCS can result in the underestimation of total uncertainty

in project schedule The most effective way to deal with dependence in a statistic isuse a causal structure to explain it MCS is not capable of modelling causalstructures

Another weakness of MCS explained by Williams [51] is the inability ofsimulation to capture the actions taken by the managers to recover any slippage inactivity/project duration MCS simply runs through a network assigning values torandom variables on each iteration It ignores the fact that in reality if an activitywas running late, management would take actions to affect the activity duration.Uncertainty in an activity is usually the result of a chain of causes (sources) and can

be affected by a chain of actions (controls)

Furthermore, MCS is only as good as the information that is fed into it If theduration distributions of the project activities are incorrect or inadequate, thesimulation results are erroneous and invalid In reality duration of most activities areestimated subjectively In order to capture all aspects of uncertainty in activity(project) duration various known and unknown sources of risk have to be addressed.Therefore, MCS will not be applied as a scheduling technique in the scope of

d) Fuzzy logic

An alternative approach that has interested several researchers in the past twodecades [52, 53] is Fuzzy project-scheduling The fuzzy set scheduling literaturerecommends the use of imprecision rather than uncertainty, fuzzy numbers ratherthan stochastic variables and membership functions rather than probabilitydistributions The output of a fuzzy scheduling will normally be a fuzzy schedule,which indicates fuzzy starting and ending times for the activities This may be asdifficult to generate as probability distributions of activity duration and also there is

no generally accepted computational approach available Therefore, the fuzzyproject-scheduling approaches have been kept in the academic sphere A summary

of most of the published research works in fuzzy project scheduling can be found inthe work of Bonnal et al in 2004 [54]

1.2.3 Agile software project scheduling

From the late 1990s several methodologies like RUP, XP, FDD, Scrum etc.began to get increasing public attention and has become mainstream softwaredevelopment methods, especially in Vietnam where most software vendors aresmall and medium enterprises These methods are representative of agile softwaredevelopment

Agile – denoting “the quality of being agile; readiness for motion; nimbleness,activity, dexterity in motion” [55] – software development methods are attempting

to offer an answer to the eager business community asking for lighter weight alongwith faster and nimbler software development processes This is especially the casewith the rapidly growing and volatile Internet software industry as well as for theemerging mobile application environment

Agile development is a way of organizing the development process,emphasizing direct and frequent communication – preferably face-to-face, frequentdeliveries of working software increments, short iterations, active customerengagement throughout the whole development life-cycle and changeresponsiveness rather than change avoidance [56] Thus, agile softwaredevelopment recognizes that software development is inherently a type of productdevelopment and therefore a learning process It is iterative, explorative anddesigned to facilitate learning as quickly and efficiently as possible Two of themost significant characteristics of agile approaches are: 1) they can handle unstablerequirements throughout the development cycle; and 2) they deliver products inshorter time-frames and under budget constraints when compared with traditionaldevelopment methods

An agile approach can be seen as a contrast to (traditional) waterfall-likeprocesses [57, 58, 59] which pay attention to thorough and detailed planning anddesign upfront and consecutive plan conformance The waterfall model is the oldestand the most mature software development model [58] In practice, the waterfalldevelopment model can be followed in a linear way, and iteration in an agilemethod can also be treated as a miniature waterfall lifecycle.

Agile approaches have been widely employed in a domain of low cost of failure

or linear incremental cost of failure [60] Examples within this domain include based applications, mobile applications [55], Internet commerce, social networking,games development, and even some areas in government, finance and bankingsoftware development

web-Table 1.2 summarizes some of the differences between waterfall and agileprojects

Table 1.2 The differences between waterfall and agile projects

Product/ An often bloated product that The best possible product accordingscope is still missing features (i.e., to customers own prioritization,

rejected change requests or de- incorporating learning from actualscoped to meet deadlines) use (revolves with the increments).Schedule/ Deadlines are usually missed, Very high probability of meetingtime and it is unlikely for a project fixed date commitments; can often

to deliver early deliver early with the highest value.Quality Defects must be tested Quality is built in, and is the key to

extensively and expensively productivity (writing tests before

writing code)

Return/ Revenue earning and value Value is generated early, as soon asvalue creation are delayed until the the minimum highest prioritizedcreation lowest priority features are features are delivered Greater

implemented and delivered return on investment

to the

customer

32

Since agile software development is organized iteratively and incrementally initerations, agile software scheduling is actually iteration scheduling Iterationscheduling aims at determining a very feasible and precise plan for the developmentthat schedules the implementation of selected features within an iteration (i.e.assigning tasks to developers) Technical tasks (or Sprint backlog items in Scrum)are the main concepts of iteration scheduling These tasks are the fundamentalworking units accomplished by one developer, and usually require some workinghour realization effort that is estimated by the team The aim of iteration scheduling

is to break down selected requirements into technical tasks and to assign them todevelopers [61] In that process, the development team also needs to care abouttasks dependencies (sequencing) and time constrains The problem of optimizedAgile iteration scheduling will be discussed in details in Section 3.1

1.3 Risk management in software project scheduling

1.3.1 Overview of project risk management

Risk management has become an important part of project management and hasattracted a wide range of research during the last two decades [15] Since 1990various Risk Management Processes (RMP) have been proposed Probably the mostpopular Project Risk Management Processes (PRMP) is Chapter 11 of the PMBOK(Project Management Body of Knowledge) guide [11], the PRAM (Project RiskAnalysis and Management) guide [62] and the RAMP (Risk Analysis andManagement for Projects) guide [63] Most organisations adopt one of these guides

or use them to develop their own process This thesis does not intend to explore thedetailed differences between different guides since, apart from fundamentaldifferences in assumptions and methodologies [64], they all aim to capture risk anduncertainty in the following three stages:

The usual output of the risk identification stage is a document called the RiskRegister Many authors have discussed risk registers in their works [65] Williams[66] stated two main roles for a risk register:

 A repository of a corpus of knowledge.

 To initiate the analysis and plans that flow from it

Chapman and Ward [18] consider a risk register as documentation of the sources

of the risks, their responses and also risk classification Ward [67] described thepurpose of a risk register “to help the project team review project risk on a regularbasis throughout the project” Patterson and Neailey [68] presented a risk registerdatabase system to aid managing project risk Risk registers can be a goodmanagement tool during the course of a project However, it is not possible toidentify all risks and capture all aspects of them There are always unknown (i.e.undiscovered, unattended or immeasurable) risks that often are more important thanthe identified risks in the risk register

The Risk Analysis stage attempts to measure the risk and its impacts on differentproject outputs (i.e cost, time, and performance) This stage is also known asquantitative risk management The likelihood that each identified risk will occur andalso its possible impact on the project is estimated The combination of the risks,probabilities and their impact create ‘probability-impact’ (PI) matrices This matrixcan be used to assign ranks to risks and then prioritise them Most of the availablequantitative tools and techniques (simulation based tools) implement the PI values

to quantify uncertainty in projects However, use of PI matrices has some importantshortcomings [15]

The Risk Response stage attempts to formulate management responses to therisk Also known as “Risk Mitigation”, it uses the results of the analysis stage inorder to improve the chance of achieving the project objectives “Risk Response” is

a decision making process A number of alternative strategies are available whenplanning risk responses, which can be described under one of the followingstrategies [69]:

 Avoid - seeking to eliminate uncertainty by reducing either the probability orthe impact to zero

 Transfer – seeking to transfer ownership and/or liability to a third party (e.g insurance)

 Mitigate – seeking to reduce the size of the risk exposure in order to make it more acceptable to the project or organization

 Accept – recognizing residual risks and responding either actively byallocating appropriate contingency, or passively doing nothing exceptmonitoring the status of the risk

There are several other publications with different perceptions of project riskmanagement processes For example, Al-Bahar and Crandall [70], the UK Ministry

of Defence [71], del Caano and de la Cruz [72], Wideman [73], British StandardInstitute (BSI) [74], NASA (Rosenberg et al 1999) [75], the U.S Department ofDefence [76], and the US Department of Transportation [77] suggest the use ofprocesses with different stages or phases Even though risk management process isadopted for managing risk/uncertainty, risk analysis always plays an important role

in the process

1.3.2 Project risk analysis

The term risk analysis in the scope of this research is the same with

quantitative risk analysis and related to risk measurement, as we focus on

quantitative issues of project risks Project risk analysis is one stage of project risk

management In some literature, risk analysis is even synonymous with riskmanagement

In fact, risk analysis is usually started out by a qualitative analysis and itsresults support the decision making process in the Risk Response stage It is acontinuous process that can be started at almost all stages in the duration of aproject However, it is the best to use risk analysis in the beginning stages ofprojects (i.e some phases like feasibility study and planning) and continuallyupdate it during the implementation phase This can be done iteratively at intervals,and this also matches with agile software development

Risk analysis is the most “formal” aspect of the project risk managementprocess [69]), often involving sophisticated techniques and usually requiringcomputer software (or tools) Such techniques may be applied with various levels ofeffort depending on the available resources for the analysis and also on the details.Risk analysis can bring in certain benefits to software project, including:

 Help to make decisions and make it possible for more effective and efficient risk management

 Help to make more feasible (realistic) plans, in terms of both duration and costs

 Help to form statistical data of historical risks This in turn would be benefits

in better planning and implementation of future projects

1.3.3 Unknown risks

One important category of uncertainty in projects is “Unknown Risks” Theseare important sources of uncertainty because their impact on a project mayoutweigh all other sources of risks

Although unknown risks are thoroughly acknowledged (perhaps with differentnames) by several authors, none of the existing approaches for project scheduling isable to model and quantify this type of risk The conventional “probability impact”approach at best is only capable of modelling “known risk” Most of the currentquantitative techniques for risk analysis are event-oriented and more concernedabout ‘risk of something happening’ They assume that a list of events (conditions)that may take place is known, the impact of each risk on activity duration is alsoknown and even the nature of the response to each risk is roughly known [19]However, unknown risks are unpredictable and immeasurable (their impacts areunknown or hard to quantify) Those risks required much effort to clarify Anexample of unknown risks is Internally Generated Risk - IGR [78] As their namesalready reveal, IGRs originated from within the project team or organization, fromrules, policies, regulations, structures, actions, behaviours or culture of theorganization IGRs have the following features:

 Common, since organizational issues such as policies, processes, culture etc are widespread in most projects of the organization

 Important, since they often have impact on more than one activity

 Not well-managed in projects, as they are unpredictable (and hardly put in documents or risk registers) and hard to quantify

1.3.4 Risk aspects in software project scheduling

In different project management processes there are different aspects ofuncertainty/risk [23] This thesis focuses on quantitative risk management whichconcerns about risks affecting project schedule (or project time frame), includingrisks affecting project scheduling (a phase or a process in project planning) As can

be deduced from the previous sections, these risks cannot be completely separatedfrom risks of other processes or phases

In project scheduling, the most obvious risk is in duration estimation for aparticular activity Difficulty in this estimation can arise from a lack of knowledge

of what is involved as well as from the uncertain consequences of potential threats

or opportunities Some sources of uncertainty:

 Level of available and required resources (including inexperienced or lack oftraining developers)

 Incomplete (or often changing) requirements

 Tradeoff between resources and time

 Possible occurrence of uncertain events (especially those cause badly impact,

 Lack of previous experience and use of subjective instead of objective data

 Incomplete or imprecise data, or lack of data

 Uncertainty about the basis of subjective estimation (i.e bias in estimation)

1.4 Bayesian Networks

1.4.1 Probabilistic approach using Bayesian Networks

Bayesian Network (BN, or also known as Bayesian Belief Network, CausalProbabilistic Networks, Probabilistic Cause-Effect Models, and ProbabilisticInfluence Diagrams) is a special type of graphs that associated together with a set ofprobability tables BN models causal relationships of a system or dataset andprovides a graphical representation of this causal structure through the use ofdirected acyclic graphs (DAGs) with nodes and edges The DAG representationprovides a framework for inference and prediction The nodes represent randomvariables with probability distributions, while edges represent weighted causalrelationships between the nodes Each node has a probability of having a certainvalue (a finite set of mutually exclusive states) A directed edge exists from a parent

to a child Each child node A has a conditional probability table P(A|B1,…,Bn)based on its parental values B1,…,Bn If the node has no parents, then the tablebecomes the unconditional probabilities P(A) (i.e prior probability)

BN is based on Bayes’ Theorem, with the well-known formula presenting the

joint probabilities:

P(R|S) = ( , )

(1.1) ( )

It follows to be expressed in the basic form of Bayes’ rule as [24]:

P(R|S) =

( )

37

The above Bayes rule is interpreted in terms of updating the belief (posteriorprobability of each possible state of a variable, that is, the state probabilities afterconsidering all the available evidence) about a hypothesis R in the light of newevidence S So, the posterior belief P(R/S) is calculated by multiplying the priorbelief P(R) by the likelihood P(S/R) that S will occur if R is true (see more aboutupdating probability in Section 1.4.2).

We can re-arrange the formula for conditional probability to get the followingformula in form of product rule:

We can extend the above product rule for three variables:

P(A,B,C) = P(A|B,C)*P(B,C) = P(A|B,C)*P(B|C)*P(C) (1.4)And it follows the generalized formula to n variables that:

P(A1,A2,…,An) = P(A1|A2, … ,An)*P(A1|A2, … ,An)*…*P(An-1|An)*P(An) (1.5)Formulas 1.4 and 1.5 are often referred to as the “Chain Rule”, which says in a

BN the full joint probability distribution is the product of all conditionalprobabilities specified in the BN These formulas are important ones considering

BN since they provide means of calculating the full joint probability distribution inBNs [9] Many of the variables Ai will be conditionally independent which meansthat the formula can be simplified as shown

BN allows an injection of probability distributions associated with individualnodes The initial probability distributions can be simply based on “expertopinions”, survey or other mathematical methods, i.e., BN approach is consisted ofexpert opinions and mathematical calculations

A BN consists of two parts: 1) qualitative part represents the relationshipsamong variables by a directed acyclic graph, and 2) quantitative part specifies theprobability distributions associated with every node of the model The Figure 1.3shows a BN representing a simple case about the relationship between sub-contract,(team) staff quality and the possibility of delay in a task [23]

In the BN in Figure 1.3, the qualitative part consists of three nodes (representuncertain variables) and two edges Each node has a set of states For example, thenode Staff Quality has two states: “Good” and “Poor” Another part of the directedgraph – the edges – represents influential relationships between variables Forinstance, an observed event on Sub-contract or/and Staff Quality may lead to Delay

in Task

For the quantitative part: there is probability table associated with each node,providing the probabilities of each state of the variable For nodes without parents(i.e., prior nodes), the associated table are not conditioned on the other variables andare called prior probabilities or prior distributions that represent prior belief Forexample, for the node Staff Quality, P(“Good”) = 0.7 and P(“Poor”) = 0.3 For anode with parents, the probability table has conditional probabilities for eachcombination of the parents’ states (for example, see the table for the node Delay inTask in the Figure 1.3).

Figure 1.3 An example of BN which represents a simple case

1.4.2 Bayesian Inference

Bayesian inference is based on a conceptually simple collection of ideas Weare uncertain about the quantity of a parameter We can quantify our uncertainties assubjective probabilities for the parameter (prior probability), and also conditionalprobabilities for observations we might make given the true value of the parameter(likelihood function) When data arrives, Bayes’ theorem tells us how to move fromour prior probabilities to the new conditional probabilities for the parameter(posterior distribution) [79] For example, in the Figure 1.3, a project manager isanalyzing the cause of delay in a particular task in a project A part of the task isdone by a sub-contractor Based on previous experience and the good reputation ofthe sub-contractor, the project manager believes that the chance of delivering thesub-contract on time is 95 percent There is an 80 percent chance of delay in the task

if the sub-contractor fails to deliver on time Even if the sub-contractor delivers ontime, there is still 10 percent chance that the task is over scheduled (as a result of