The research provides answers to the above questions with probabilistic approaches and tools to assess the impacts of risk factors on software project scheduling; proposing list of commo
Overview of software project scheduling and risk management
Software project management and software project scheduling
Software project management combines both art and science to effectively plan and oversee software projects It focuses on the essential aspects of project management, including planning, scheduling, resource allocation, implementation, tracking, and the successful delivery of software and web projects.
Software project management differs significantly from traditional project management due to the unique nature of software development Unlike manufactured products, software is intangible and highly flexible, which presents distinct challenges Additionally, software engineering lacks the formal recognition of other engineering disciplines, such as mechanical or electrical engineering The lifecycle of software projects involves multiple testing phases, updates, and customer feedback, making the development process non-standardized Furthermore, most software projects are considered "one-off" endeavors, meaning that development teams rely on similar past experiences rather than a repeatable process.
Software project management involves the systematic organization of all activities associated with software development It is essential due to the inherent constraints of budget and time that software projects face.
In today's fast-paced business environment, agile project management has become the standard for IT-related projects, enabling teams to develop software collaboratively and adapt quickly based on feedback from customers and stakeholders Additionally, the agile methodology is gaining traction in various other fields of project management.
The project manager is pivotal in guiding the project team and serves as the key liaison among investors, suppliers, and senior management They ensure that the project adheres to established constraints while delivering the software product on schedule Software project managers are responsible for a variety of tasks essential to project success.
Effective planning and scheduling are crucial for project success, as they create a comprehensive blueprint that guides the project from ideation to completion This process involves defining the project scope, allocating essential resources, proposing a timeline, and outlining the execution plan Additionally, it establishes a communication strategy and details the necessary steps for testing and maintenance.
A software project manager is responsible for assembling and leading a diverse project team, which typically includes developers, analysts, testers, graphic designers, and technical writers This role demands strong communication, interpersonal, and leadership skills to effectively guide the team towards successful project completion.
The project manager will oversee and ensure the successful execution of each project stage by monitoring progress, conducting regular team check-ins, and generating status reports.
Effective time management is essential for the successful completion of software projects, where deviations from the original plan are likely Software project managers must excel in risk management and contingency planning to navigate roadblocks and adapt to changes, ensuring continuous progress throughout the project lifecycle.
Software project managers, similar to traditional project managers, are responsible for developing a project budget and adhering to it as closely as possible They must monitor expenditures and reallocate funds when necessary to ensure financial efficiency throughout the project.
Effective software project management emphasizes ongoing product testing to identify and resolve bugs early, align the final product with customer requirements, and maintain project timelines The software project manager plays a crucial role in overseeing consistent testing, evaluation, and necessary adjustments.
Managers play various roles in software project management, which focuses on delivering software on time, within budget, and according to organizational requirements The key activities for managers in this context include planning, estimating, and scheduling.
Project management, as outlined by the Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK) guide, consists of five key stages: Initiating, Planning, Executing, Monitoring and Controlling, and Closing.
In contemporary software project planning, effective project risk management and scheduling are vital for ensuring the efficient organization of resources, including hardware, software, and network allocation, as well as the assignment and monitoring of tasks and personnel.
Software projects are unique due to the continuous changes in requirements throughout the development life cycle, often resulting in delays and budget overruns Many project managers neglect effective risk management, leading to project failures and customer dissatisfaction regarding quality, timelines, and costs Even those who recognize the importance of risk management may overly depend on their team's skills or experience, despite adhering to frameworks like CMM/CMMi or PMP As illustrated in Figure 1.1, risk management is integral to all processes within the Process Groups, allowing project teams to adjust and update their planning while executing, monitoring, and controlling their projects.
Figure 1.1 Activities of project management according to PMBOK Guide
Software project scheduling methods and techniques
There are many popular techniques for project scheduling, include:
Graphical representations play a crucial role in illustrating project schedules, including the Work Breakdown Structure, which breaks down the project into manageable tasks Activity Charts are essential for displaying task dependencies and identifying the critical path, while Gantt Charts provide a visual timeline of the schedule against calendar time.
Program Evaluation and Review Technique – PERT [16, 17, 19, 40]
Project scheduling, particularly in the context of uncertainty, is a key focus in risk quantification within project management Creating a dependable project schedule is essential for project managers, as a realistic timeline is frequently identified as a critical factor for project success Various techniques have been developed to model risk and uncertainty in project scheduling.
This section highlights key project scheduling techniques, including the classical approaches of CPM and PERT Modern simulation-based methods, widely used in project management software, are often considered best practices Additionally, we will briefly review alternative approaches such as the Critical Chain Method and Fuzzy Logic Finally, we will discuss scheduling techniques and methods specifically tailored for agile software development.
1.2.2 Traditional scheduling methods and techniques a) Critical Path Method (CPM)
The Critical Path Method (CPM), developed by DuPont in 1957, is a widely recognized technique for project scheduling It has established itself as the standard approach in project management, with most project management tools offering support for CPM.
27 calculation [39] According to Pollack-Johnson and Liberatore [43], almost 70% of project managers or professionals use CPM CPM calculation includes the following 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 the Table 1.1 In fact, the parameters D, ES, EF, LF, LS are common used in scheduling techniques
Table 1.1 Basic mathematical notations used for CPM calculation
No Notation Description Formula Note
3 ES Earliest start of aj
Di] i is one of the predecessor activities
4 EF Earliest finish of aj
5 LF Latest finish of aj
– Dk] k is one of the successor activities
6 LS Latest start of aj LSj = LFj – Dj
Total float of aj - the time that the activity’s duration can be increased without increasing the overall project completion time
Critical activities, characterized by zero float time (TF = 0), require special attention as any delays in these activities will impact the entire project timeline The critical path is identified through forward and backward passes in the project network The forward pass calculates the earliest start (ES) and earliest finish (EF) times for each activity, while the backward pass determines the latest start (LS) and latest finish (LF) times The total float for each activity is derived from the difference between the latest and earliest finish times.
[19] The connections among these parameters in an activity are described in Figure 1.2
CPM, or Critical Path Method, is a deterministic model that relies on fixed time estimates for project activities While it was not designed to address or measure uncertainty, CPM offers valuable insights into the relationships between activities, their durations, and the overall project timeline, enabling effective project scheduling control.
Figure 1.2 CPM parameters in an activity b) Program Evaluation and Review Technique (PERT)
Introduced by the US Navy in 1957, PERT (Program Evaluation and Review Technique) is one of the earliest methodologies to incorporate risk into project management A key feature of PERT is its capacity to manage uncertainty in activity durations, recognizing that variations in time estimates can impact the entire project This methodology is designed to facilitate successful project completion even when time estimates are not definitive.
PERT utilizes a beta probability distribution for each project activity, moving beyond a single CPM estimation It incorporates three time estimates—optimistic, most likely, and pessimistic—to calculate the expected time and standard deviation for each activity.
An optimistic time estimate refers to the timeframe calculated under ideal conditions, representing the best-case scenario where everything proceeds smoothly Essentially, it signifies the minimum duration required to complete a given activity.
The most likely time estimate refers to the duration in which there is a strong likelihood of successfully completing a task This estimate is applicable in scenarios involving typical challenges or opportunities.
A pessimistic time estimate refers to the duration projected under the worst-case scenario, taking into account all unfavorable conditions This estimate represents the maximum time required to complete an activity when everything goes wrong.
Expected time: μi = (Optimistic + 4xMost likely + Pessimistic)/6
The critical path is the sequence of project activities that dictates the earliest possible completion time and overall project duration PERT assumes a single, unchanging critical path, prompting managers to concentrate on these key activities to maintain the project timeline The expected value of the critical path is derived from the expected values of individual activities, while its variance is the cumulative sum of the variances of all activities along the path, allowing for the calculation of the probability of meeting specific deadlines Although PERT shares similarities with CPM, the key distinction lies in PERT's incorporation of variance in activity completion times, making it a probabilistic approach compared to the deterministic nature of CPM.
Monte Carlo Simulation (MCS) was introduced for project scheduling in the early 1960s, but it gained prominence as a method for managing risk and uncertainty in projects during the 1980s, thanks to advancements in computer power At its core, MCS employs the project activity diagram to facilitate its analysis.
The duration of each activity is assessed using the shortest, most likely, and longest estimates, along with the distribution shape (e.g., Normal, Beta) Subsequently, the critical path calculation is executed multiple times, utilizing random values derived from the activities' distribution function.
Advanced tools such as PertMaster (Oracle Primavera Risk Analysis) utilize a simulation-based approach to manage uncertainties in both duration and cost, while also facilitating a comprehensive risk analysis process These tools can connect the project schedule to the risk register and employ simulation techniques to perform probability impact analyses.
Risk management in software project scheduling
1.3.1 Overview of project risk management
Risk management has become a crucial aspect of project management, garnering significant research interest over the past two decades Since 1990, various Risk Management Processes (RMP) have been introduced, with the PMBOK guide, PRAM guide, and RAMP guide being among the most widely adopted Organizations typically choose one of these frameworks or adapt them to create their own processes This thesis will not delve into the specific differences among these guides, as they all share the common goal of addressing risk and uncertainty through three key stages.
The Risk Identification stage, also referred to as qualitative risk management, focuses on uncovering the primary sources of risk This process involves employing various data gathering techniques, such as interviews, brainstorming sessions, the Delphi technique, and checklists, to identify potential risks that could impact the project, engaging all parties involved.
The usual output of the risk identification stage is a document called the Risk Register 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
A risk register serves as a crucial documentation tool that outlines the sources of risks, their responses, and classifications, as noted by Chapman and Ward According to Ward, its primary purpose is to facilitate regular reviews of project risks by the project team throughout the project's duration Patterson and Neailey introduced a risk register database system designed to enhance project risk management While risk registers are valuable management tools, they cannot encompass all risks, as there are always unknown risks—those that are undiscovered, unattended, or immeasurable—that may hold greater significance than the identified risks within the register.
The Risk Analysis stage, also referred to as quantitative risk management, focuses on assessing the risks and their potential impacts on project outputs such as cost, time, and performance This process involves estimating the likelihood of each identified risk occurring and its possible effects on the project By combining risks, probabilities, and impacts, 'probability-impact' (PI) matrices are created, which help in ranking and prioritizing risks Most quantitative tools and techniques, particularly simulation-based tools, are utilized in this analysis.
PI values to quantify uncertainty in projects However, use of PI matrices has some important shortcomings [15]
The Risk Response stage, also referred to as "Risk Mitigation," focuses on developing management strategies to address identified risks This stage leverages insights gained from the analysis phase to enhance the likelihood of meeting project objectives Effective "Risk Response" involves a decision-making process that considers various alternative strategies for planning risk responses.
Avoid - seeking to eliminate uncertainty by reducing either the probability or the 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 by allocating appropriate contingency, or passively doing nothing except monitoring the status of the risk
Various publications present diverse perspectives on project risk management processes, including works by Al-Bahar and Crandall, the UK Ministry of Defence, del Caano and de la Cruz, Wideman, the British Standard Institute (BSI), NASA, the U.S Department of Defence, and the U.S Department of Transportation These sources advocate for the implementation of processes that encompass different stages or phases While the risk management process is essential for addressing risk and uncertainty, risk analysis remains a critical component throughout the process.
In this research, risk analysis refers specifically to quantitative risk analysis, emphasizing the measurement of project risks It represents a crucial phase within the broader context of project risk management In certain literature, the terms risk analysis and risk management are used interchangeably.
Risk analysis typically begins with a qualitative assessment, which aids decision-making during the Risk Response phase This ongoing process can be initiated at various stages throughout a project's lifecycle, but it is most effective when conducted during the early phases, such as feasibility studies and planning Continuous updates during the implementation phase are essential, allowing for iterative assessments that align well with agile software development practices.
Risk analysis is a critical component of project risk management, often utilizing advanced techniques and specialized software The level of effort required for risk analysis can vary based on available resources and project specifics Implementing risk analysis in software projects can yield significant benefits.
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
One important category of uncertainty in projects is “Unknown Risks” These are important sources of uncertainty because their impact on a project may outweigh all other sources of risks
Despite the recognition of unknown risks by various authors, current project scheduling methods fail to effectively model and quantify these risks The traditional "probability impact" approach is limited to addressing only "known risks." Most quantitative risk analysis techniques focus on specific events and are primarily concerned with the likelihood of occurrences, assuming that a comprehensive list of potential events, their impacts on activity duration, and appropriate responses are already established.
Unknown risks are unpredictable and difficult to measure, making their impacts hard to quantify Clarifying these risks requires significant effort A prime example of unknown risks is Internally Generated Risk (IGR), which arises from within the project team or organization IGRs stem from the organization's rules, policies, regulations, structures, actions, behaviors, or culture.
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
This thesis emphasizes quantitative risk management within project management, specifically addressing risks that impact project schedules and timelines It highlights that these scheduling risks are interconnected with risks from other project phases and processes, underscoring the complexity of managing uncertainties in project planning.
In project scheduling, a significant risk lies in accurately estimating the duration of specific activities This challenge often stems from insufficient knowledge about the tasks involved and the unpredictable outcomes of potential threats or opportunities Various sources contribute to this uncertainty.
Level of available and required resources (including inexperienced or lack of training developers)
Incomplete (or often changing) requirements
Tradeoff between resources and time
Possible occurrence of uncertain events (especially those cause badly impact, or risks)
Challenges from technology (incompatible technology, built-in API without sufficient documentation, insufficient architecture etc.)
Causal factors and interdependencies including common causal factors that affect more than one activity (such as organizational issues)
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).
Bayesian Networks
1.4.1 Probabilistic approach using Bayesian Networks
A Bayesian Network (BN), also known as a Bayesian Belief Network or Causal Probabilistic Network, is a specialized graph that combines a set of probability tables to model causal relationships within a system or dataset It utilizes directed acyclic graphs (DAGs) to visually represent this causal structure, where nodes signify random variables with associated probability distributions, and edges denote weighted causal relationships Each node possesses a probability of assuming a specific value from a finite set of mutually exclusive states Directed edges connect parent nodes to child nodes, with each child node A having a conditional probability table P(A|B1,…,Bn) that depends on its parent values B1,…,Bn In cases where a node lacks parents, the table reflects unconditional probabilities P(A), also known as prior probabilities.
BN is based on Bayes’ Theorem, with the well-known formula presenting the joint probabilities:
It follows to be expressed in the basic form of Bayes’ rule as [24]:
Bayes' rule is used to update the posterior probability of a hypothesis R based on new evidence S The posterior belief P(R/S) is determined by multiplying the prior belief P(R) with the likelihood P(S/R), which represents the probability of S occurring if R is true For further details on updating probabilities, refer to Section 1.4.2.
We can re-arrange the formula for conditional probability to get the following formula 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 conditional probabilities specified in the BN These formulas are important ones considering
Bayesian Networks (BNs) are essential for calculating the complete joint probability distribution Many variables, denoted as \(A_i\), exhibit conditional independence, allowing for simplification of the probability formula.
Bayesian Networks (BN) enable the integration of probability distributions linked to individual nodes These initial probability distributions can be derived from expert opinions, surveys, or various mathematical methods, highlighting that the BN approach combines both expert insights and quantitative analysis.
A Bayesian Network (BN) comprises two key components: the qualitative aspect, which illustrates the relationships among variables through a directed acyclic graph, and the quantitative aspect, which defines the probability distributions linked to each node in the model Figure 1.3 depicts a BN that illustrates the relationship between subcontracting, team staff quality, and the likelihood of task delays.
The Bayesian Network (BN) illustrated in Figure 1.3 features three nodes representing uncertain variables and two edges indicating influential relationships Each node, such as Staff Quality, has distinct states, including "Good" and "Poor." The directed edges demonstrate how observed events, like changes in Sub-contract or Staff Quality, can lead to delays in task completion.
In the quantitative analysis, each node is linked to a probability table that outlines the likelihood of each variable state Nodes without parents, known as prior nodes, feature tables that are not influenced by other variables, representing prior probabilities or distributions that reflect initial beliefs For instance, the node for Staff Quality has probabilities of P("Good") = 0.7 and P("Poor") = 0.3 Conversely, nodes with parents include conditional probability tables that account for every possible combination of their parents' states, as illustrated by the Delay in Task node in Figure 1.3.
Figure 1.3 An example of BN which represents a simple case
Bayesian inference is a straightforward concept that quantifies uncertainty about a parameter using subjective probabilities, known as prior probabilities, and conditional probabilities for potential observations, referred to as the likelihood function Upon receiving new data, Bayes’ theorem facilitates the transition from prior probabilities to updated conditional probabilities, resulting in the posterior distribution For instance, a project manager assessing delays in a task involving a sub-contractor estimates a 95% probability of timely delivery based on the sub-contractor's strong reputation However, if the sub-contractor fails to deliver on time, there is an 80% likelihood of a delay in the task, and even with timely delivery, a 10% chance exists that the task is over-scheduled.
40 other internal reasons) If the task is actually late, what is the probability that the sub-contractor had failed to deliver on time?
Before knowing about this particular task, subjective estimation (e.g sub- contractor’s reputation) reflects the prior probability of having the sub-contract delivered on time (SC):
The likelihood function is the conditional probability of delay in task in the task given the actual state of sub-contract delivery:
P(Delay|SC) = 0.1 hence P(Delay̅̅̅̅̅̅̅|SC) = 0.9
P(Delay|SC̅̅̅) = 0.8 and hence P(Delay̅̅̅̅̅̅̅|SC̅̅̅) = 0.2
Using Bayes’ rule (Formula 1.2) to update the probability, the posterior probability, or the chance of sub-contract being delivered on time given the task is late, is:
P(SC|Delay) = P(Delay|SC)∗P(SC)
P(P(Delay|SC)∗P(SC) +P(Delay|SC ̅̅̅̅)∗P(SC ̅̅̅̅) = 0.1∗0.95
So the prior probability of 95 percent is revised to 70 percent as a result of the evidence of a delay in the task
Bayesian inference is effective with just two variables, but it becomes significantly more complicated when multiple variables with various states and intricate conditional dependencies are present To address this complexity, Bayesian Networks (BNs) are constructed.
1.4.3 Bayesian Networks and project risk management
Bayesian Networks (BNs) provide a robust framework for modeling uncertainty and causality, making them valuable for risk assessment in fields like medicine, finance, and critical systems Their application in project risk analysis is particularly advantageous due to several key benefits.
Bayesian Networks (BNs) offer a structured approach to effectively utilize subjective information, serving as a visual and formal tool for analyzing and validating subjective probabilities This capability is especially beneficial in project risk analysis, where subjective judgments are often the only viable option.
- BNs explicitly quantify uncertainty Their causal framework provides a useful and unambiguous approach for analyzing risk This is in stark contrast with the
41 probability impact approach (as discussed in Section 1.4.1) where none of the concepts has a clear unambiguous interpretation
Parameter learning in Bayesian Networks (BNs) enhances probabilistic inference by updating the posterior probability distribution based on observed evidence This process provides a systematic approach to refining beliefs about unknown factors that are challenging to measure and were previously evaluated subjectively.
Bayesian Networks (BNs) excel in complex sensitivity analysis by enabling reasoning from both effects to causes and vice versa This capability allows them to address a variety of 'what-if?' scenarios and provide insights when multiple variables change at the same time.
Bayesian Networks (BNs) offer a robust method for modeling uncertainty in project risk analysis, yet their application remains limited Early implementations by McCabe and Nasir et al focused on constructing a BN to illustrate the interplay between key risk factors influencing activity durations in construction projects They identified ten specific risk categories, including environmental, geotechnical, and labor-related risks, along with 70 detailed risk variables Additionally, eight activity groups were established to encompass all construction activities, such as mobilization and commissioning Through literature review and expert surveys, the relationships between various risks and activity types were quantified, allowing for the calculation of optimistic and pessimistic duration estimates based on a known most likely duration The BN model's output, representing upper and lower duration limits, was then integrated into a Monte Carlo Simulation (MCS) model to assess the impact of risks on project scheduling.
The BN model provided a very flexible modelling environment It was validated with historical data from 17 case studies with very good results However, the model had the following limitations:
- The model was specific to building construction projects; therefore, it cannot be applied to other industries and different type of projects
The BN model estimates the upper and lower limits of activity duration as a percentage of the most likely duration, which is assumed to be known and serves as an input for the model.
Chapter remarks
This chapter provides a comprehensive overview of essential concepts in software project management, including project scheduling and risk management It also introduces a probabilistic approach utilizing Bayesian Networks (BNs), covering Bayesian inference and the construction of BNs.
Current research on the application of Bayesian Networks (BNs) in risk management for software project scheduling is limited This thesis aims to address this gap by reviewing literature on project management, project scheduling, and risk management, while also considering specific risk factors as attributes unique to software projects.
Those backgrounds will be used for proposed approaches and experiments in Chapter 2 and Chapter 3 Chapter 2 will consist of initial attempts of applying BNs
This article explores risk management in software project scheduling, highlighting 19 common risk factors that affect both traditional and agile software development projects It also discusses the impact of these risk factors on project scheduling, providing insights into effective risk management strategies.
Chapter 3 will integrate Bayesian Networks (BNs) into widely used software project scheduling methods, including CPM, PERT, and agile scheduling, to improve schedule predictability Additionally, BNs will be utilized to analyze the interconnections among risk factors discussed in Chapter 2.
Common risk factors and experiments on Bayesian
Application of Bayesian Networks into schedule risk management in software
This section presents the mathematical model and algorithm (BRI) introduced in publication 2 [PUB2], aimed at evaluating critical project values by calculating associated risks and their probabilities, each weighted to determine their impact Experiments demonstrate that software development teams can depend on this model and algorithm to effectively predict and assess risks, as well as their effects on project success.
2.1.1 Common risk factors in software project management
In 2000, Arizona State University at Tempe conducted research to create a model for evaluating the potential impacts of software risk factors on software development projects This model identified 24 common risk factors associated with software projects.
Hui and Liu developed software to assess the influence of 24 risk factors on the success of software projects They conducted a survey with 29 IT specialists, each possessing 5 to 25 years of experience in the industry, to refine the model by adjusting probabilities and weights The findings led to the identification of these 24 risk factors along with their associated probabilities, as detailed in Table 2.1.
Table 2.1 highlights that the 24 risk factors relevant to software projects significantly influence project duration and schedules Consequently, this list serves as a foundational resource for evaluating risk factors in software project scheduling.
Table 2.1 Hui and Liu’s common risk factors [9]
No Group of Issues Risk factor Probability
2 Resources Reliance on few key person 0.75
5 Personnel Lack of staff commitment 0.20
6 Customer Lack of client support 0.35
7 Customer Lack of contact person competence 0.15
8 Research data Lack of quantitative historical data 0.50
9 Research data Inaccurate cost estimating 0.50
10 System Large and complex external interface 0.40
11 System Large and complex project 0.45
No Group of Issues Risk factor Probability
16 Management Lack of senior management commitment 0.50
17 Management Lack of organization maturity 0.25
22 Technology Excessive reliance on a single process 0.5
23 Experience Lack of experience with project environment 0.625
24 Experience Lack of experience with project software 0.42
2.1.2 Bayesian Networks of risk factors
We developed sub Bayesian Networks (BNs) for the 24 software risk factors identified in Section 2.1.1, as illustrated in Figures 2.1 to 2.24, along with an overall BN for risk modeling in software projects shown in Figure 2.25 These BNs depict the risk factors along with their impacts categorized into three weight levels: level ONE (+), level TWO (++), and level THREE (+++), with each level indicating increasing severity, as further detailed in the calculations in Section 2.1.3.
In Figure 2.1, the risk factor "Staff experience shortage" impacts both "staff_training" and "untrained_staff" with a weight of one level each, while "staff_training" also affects the "project_schedule." Additionally, the "project_schedule" is influenced by the risk factors "Low productivity" (Figure 2.4) and "Lack of senior management commitment" (Figure 2.16).
47 factor “Inadequate configuration control” (Figure 2.19) Of course, this is also related to the risk factor “Schedule pressure”
The risk factor "Lack of client support" is interconnected with "Creeping user requirements," which can significantly affect the schedule of software projects, as illustrated in Figure 2.6.
Figure 2.9 illustrates a sub Bayesian Network (BN) that highlights the risk factors impacting the software project schedule, specifically focusing on risk factor number 16, which addresses the issue of "Lack of reliance on a few individuals."
+decision_make_delay staff_experience_shortage
Figure 2.1 A sub BN for the risk factor “Staff experience shortage”
Figure 2.2 A sub BN for the risk factor “Reliance on few key person”
Risk factor number 9, "Inaccurate cost estimating," along with risk factor 3, "Schedule pressure," are highlighted in Table 2.1 as significant contributors to organizational maturity These factors are interconnected with "Inaccurate metrics" (Figure 2.21) and "Excessive reliance on a single process" (Figure 2.22), indicating a complex relationship that impacts project outcomes.
Figure 2.3 A sub BN for the risk factor “Schedule pressure”
Figure 2.4 A sub BN for the risk factor “Low productivity”
Figure 2.5 A sub BN for the risk factor “Lack of staff commitment” lack_of_client_support
++lack_of_client_input +defect_rate
Figure 2.6 A sub BN for the risk factor “Lack of client support”
50 lack_of_contact_person_ competence
Figure 2.7 A sub BN for the risk factor “Lack of contact person competence” lack_of_quantitative_historical_data
Figure 2.8 A sub BN for the risk factor “Lack of quantitative historical data”
Figure 2.9 A sub BN for the risk factor “Inaccurate cost estimating” large_and_complex_external_interface
Figure 2.10 A sub BN for the risk factor “Large and complex external interface” large_and_complex_project
Figure 2.11 A sub BN for the risk factor “Large and complex project”
Figure 2.15 illustrates the sub-BN of the risk factor "Incapable project management," which is recognized in the literature as having a significant impact on project schedules This thesis will further validate this assertion The risk factor is associated with "Lack of senior management commitment," a common risk factor identified across all lists examined in this thesis, and "Creeping user requirements." According to Hui and Liu [9], these three risk factors are highly likely to affect software projects.
Figure 2.12 A sub BN for the risk factor “Unnecessary features” creeping_user_requirement
Figure 2.13 A sub BN for the risk factor “Creeping user requirement” unreliable_subproject_delivery
Figure 2.14 A sub BN for the risk factor “Unreliable subproject delivery”
Figure 2.15 A sub BN for the risk factor “Incapable project management” lack_of_senior_managem ent_commitment
+low_moral +staff_experience_ shortage
Figure 2.16 A sub BN for the risk factor “Lack of senior management commitment”
++incurate_cost_estimating ++inadequate_process_method
Figure 2.17 A sub BN for the risk factor “Lack of organization maturity”
Figure 2.18 A sub BN for risk factor “Immature technology” immature_technology
Figure 2.19 A sub BN for the risk factor “Inadequate configuration control”
Figure 2.20 A sub BN for the risk factor “Excessive paperwork” excessive_paper_work
Figure 2.21 A sub BN for the risk factor “Inaccurate metrics”
Figure 2.22 A sub BN for risk factor “Excessive reliance on a single process improvement” excessive_reliance_on_a_sing le_process_improvement
++inaccurate_reporting ++inaccurate_cost_ estimating+schedule_pressure
57 Figure 2.25 shows the BN of overall model in software projects lack_of_experience_with_project_software
Figure 2.24 A sub BN for the risk factor “Lack of experience with project software”
Figure 2.23 A sub BN for the risk factor “Lack of experience with project environment” lack_of_experience_with_ project_environment
Figure 2.25 The overall BN for software risk factors
Bayesian Networks (BNs) enable the association of probability distributions with individual nodes, utilizing initial distributions derived from expert opinions, surveys, or mathematical methods The probabilities can be computed using Bayes' rule, chain rules, and Bayesian inference.
We apply the following characteristics of BNs to calculate the impacts of risks in software projects [42]:
- Expression of expert opinions, experiences or beliefs about the dependencies between different factors
- Consistent propagation of the impact of uncertain evidence on the probabilities of outcomes
- Calculation and revised calculation of probability when the evidence is known
Figure 2.26 illustrates how the above characteristics are applied The Figure shows that the events x, y, and z are dependent of each other, x is independent of z with the condition y
Figure 2.26 A simple example of Bayesian inference
- Expert opinions, experiences, beliefs: z impacts y, and y impacts x
The propagation of evidence impact reveals that if the probability of event z occurring is \$P(z) = 0.9\$, then the conditional probability of event y given that z has occurred is \$P(y|z) = 0.7\$ Furthermore, the conditional probability of event x occurring given that both y and z have happened is \$P(x|y,z) = 0.6\$.
Then by applying the chain rule, we can calculate that the probability P(x)
Given Figure 2.26, the formula to calculate p(x|z):
Bayes Theorem has a very important property that we can calculate revised parent probability when we know that the child is true Recall formula 1.2 that:
+ Revised probability of y being true:
+ Revised probability of z being true:
We developed an algorithm that assesses the impact of risk factors, enabling project managers to make informed decisions for team development and ensuring timely completion of software projects.
Figure 2.27 The three nodes of a simple-chain BN
y: the risk directly generated from the examined risk;
z: the risk generated in the condition that the two previous risks occurred
P(y|x), P(z|xy): possibilities of risks when the conditions are true (in three weight levels: + (low) (p=0.3), ++ (medium) (p=0.6), +++(high) (p=0.9))
We propose the algorithm BRI (Bayes Risk-Impact) to assess the impact of risk factors
2.1.5 Tool and experiments a) Building tool
The tool is designed to enhance the specified model and algorithm, enabling managers to evaluate the impact of known risks on the successful completion of software projects Developed using the C# programming language and the MS.NET Framework 4.5, this software provides valuable insights into risk assessment.
* Input: Risk factors and probability (Table 2.1)
The impact of risk factors on the success of a software project can be quantified using a vector of numerical values, where higher values indicate a greater influence on project fulfillment.
*The BRI algorithm assesses the impact of risk factors:
Step 1 Based on known probabilities, for example P(X|~parent(X)) = 0.4, calculate the possibilities of child nodes in each sub BN
Step 2 With each child node, recursively find ImpactWeight(child_node)
Find Bayesian networks started by the examined child node in the original BN Calculated ImpactWeight(child_node) with the probability calculated in Step 1
If not found, ImpactWeight(child_node) = P(child_node)
Step 3 ImpactWeight(examined_risk) = ∑ImpactWeight(child_node)
Step 4 Sum up together ImpactWeight(examined_risk) into impact vector Step 5 Repeat to examine next risk
62 library and the integrated developer environment (IDE) is Visual Studio 2012 The graphical interface of the software is shown in Figure 2.28
Figure 2.28 The graphical interface of the tool
Experiments on common risk factors
This section is the work whose results were represented in publication 3 [PUB3]
The software development life cycle (SDLC) encompasses various phases that inherently involve uncertainty due to factors like hardware, software, technology, personnel, costs, and processes Current scheduling techniques often assume that tasks and activities will proceed exactly as planned, a scenario that rarely occurs in practice Recent studies in risk management emphasize the connection between uncertainty and project outcomes This section explores a model and the probabilistic tool CKDY, which utilizes Bayesian Belief Networks to assess risk factors in software project scheduling.
2.2.1 Discovering the top ranked risk factors
We utilize the method established by Kumar and Yadav, which consists of four key steps: first, we identify the top-ranked risk factors in software project scheduling; second, we establish causal relationships among these risk factors; third, we create a node probability table (NPT) for each factor in the model; and finally, we calculate the probability values of the software risk factors relevant to the project Throughout each step, we carefully select the appropriate solutions to aid in the development of the CKDY tool.
Effective software project scheduling is influenced by various risk factors, including project size, budget, and human resources Identifying these risk factors can be aided by sources such as historical data, expert interviews, and lessons learned from previous projects Numerous models for software risk prediction and assessment have been developed, yet many evaluate factors that may not be relevant to all project types Comprehensive assessment of all risk factors can lead to challenges, including high computational complexity and increased costs Therefore, focusing on the most critical risk factors for each project phase can enhance the accuracy of risk predictions and assessments.
We have synthesized various published risk factors, including SEI risk classification, NASA NPD2820 risk classification, and research findings from Hui and Liu, along with the 27 risk factors identified by Kumar and Yadav This synthesis led to the selection of a set of five top-ranked risk factors in software project scheduling, as detailed in Table 2.2 These critical risk factors significantly impact software projects and can ultimately result in project overscheduling.
Table 2.3 Risk factors, consequences and impact
Risk Factors Poor management skills and experience
Pressure on the schedule Frequent changes in customer requirements Inappropriate process
Impact Over scheduled b) Constructing causal relationships among the software risk factors
Causal relationships in a Bayesian Network (BN) can be established using historical data, experimental observations, and insights from domain experts This process involves modeling the causal connections between risk factors, their consequences, and the overall impact, leveraging the expertise of specialists in the field.
Sub BNs of risk factors and consequences are illustrated in Figure 2.32 and Figure 2.33, and the overall BN model is shown in Figure 2.34
70 c) Constructing the node probability table (NPT) for each node of the model
Designing the Node Probability Table (NPT) is crucial for Bayesian Networks (BN) in project management Constructing the NPT for each model node relies on project data, with expert evaluation and judgment being essential for project managers to effectively build the model and NPTs We utilized the PSPLIB (Project Scheduling Problem Library) data set to create the NPTs for our model, as illustrated in Table 2.4, which presents an example of the probability of risk factors.
Figure 2.34 The overall BN model
Table 2.4 Examples of risk factors and probabilities
Risk factor Probability (if it happens)
Probability (if it does not happen)
Poor management skills and experience 0.575 0.425
Frequent changes in customer requirements
71 d) Calculating the probability value of software risk factors for the project
By applying Bayes' formulas, we can calculate the probability of each node and ultimately determine the project's success probability To facilitate these calculations, we utilize the HuginExpert support library This approach not only predicts the likelihood of failure in risk management during project scheduling but also recommends a risk management sequence This sequence enables managers to identify project issues clearly, prioritize which problems to address first, and allocate resources effectively The core of this risk management sequence involves monitoring the project schedule at each phase and providing timely alerts to project managers when risk factors or consequences exceed acceptable thresholds, thereby impacting the overall schedule.
The CKDY tool is designed to leverage Hugin classes, functions, and APIs, offering Bayes analysis and prediction solutions specifically for Java programming Key functionalities include calculating and predicting project risk probabilities, issuing warnings to managers after each project phase, ranking risk factors, and providing visual graphs that illustrate probability variations over time.
The IEEE Standard 1540 (2001) outlines a comprehensive risk management process that includes several key activities: planning and implementing risk management, managing the project risk profile, conducting risk analysis, monitoring risks, treating risks, and evaluating the overall risk management process.
The author outlines a four-step process for managing risks in software projects using Bayesian Networks (BNs), which is integrated into the CKDY tool.
Step 1 - Initialize the BNs (for carrying out “Plan and implement risk management”): Based on the common BN model, suitable specific risk factors to each project are put in In this step, we identify nodes needed to be monitored and make assumptions on the status of each node
Step 2 - Calculate and make predictions from the BNs (for “Manage the project risk profile”): When the project is started, it also starts a loop to monitor the status of nodes Whenever new data is updated they are added to the BNs to calculate and update the probabilities and estimations The data history of each week of the project schedule is archived for easily referencing later
Step 3 - Monitor and analyse risks, adjust resources (for “Perform risk analysis”,
Step 3.1 - Monitoring and analyzing risks: In the general BN model, we have related nodes and directly affect the success of project scheduling such as
Monitoring key factors such as "Incomplete mission," "Wasted Resources," and "Reliability" will be conducted over a specified duration, determined by project resources and the accuracy requirements set by the project manager.
If the probability that these nodes occur or their children nodes occur above the threshold, the tool allows the Tracing function to be called to determine the cause
Step 3.2 - Adjust project resources: As we all know software activities/tasks always have a saturation point The more resources we spend on tasks, the more cost it will take, but the quality will not improve significantly or the performance will decrease Therefore, the Saturation function is called periodically (weekly or longer depending on the decision of the project manager) to check whether the monitored nodes have reached the saturation point or not from which appropriate decisions are made
The Ranking function is also called in cycles to sort the efficiency of the nodes:
When quantitative data is available, resource efficiency can be ranked based on the operational cost for each node In the absence of such data, the Bayesian Network (BN) model will be employed for evaluating efficiency.
When a node is ranked higher, we will reallocate resources to increase the effectiveness of the project
Step 4 - Perform risk treatment: Based on the analysis as well as data on project risks, the project manager will choose appropriate measures to handle risks. b) The input structure
Proposed common risk factors in software project scheduling
Selecting key software risk factors can enhance the accuracy of software risk assessment and estimation This section presents a compilation of common risk factors that influence software project scheduling Specifically, Section 2.3.1 addresses risk factors prevalent in traditional software projects, while Section 2.3.2 focuses on those found in agile software projects.
2.3.1 The 19 common risk factors in traditional software project
Wallace et al [31] conducted a comprehensive review of prior research, identifying 27 software risks categorized into six distinct groups: Organizational Environment Risk (4 risks), User Risk (5 risks), Requirement Risk (4 risks), Project Complexity Risk (4 risks), Planning and Control Risk (7 risks), and Team Risk (3 risks).
In Section 2.2, the thesis explores a straightforward model of schedule risks in software project development, identifying five key risk factors outlined in Table 2.2 These factors are associated with user risks, requirement risks, team risks, and planning and control risks, as defined by Wallace et al [31].
Rai et al [29] identified 43 risk factors in Agile software projects, which are categorized into six key areas: Development Environment Risks, Process Issue Risks, Staff Size and Experience, Technical Issue Risks, Technology Risks, and Schedule Risks.
Our research focuses on the common risk factors shared by Agile and traditional software development that impact software scheduling and planning These specific risks, prevalent across various project activities, primarily stem from the development environment, process-related issues, staff size, experience, and scheduling challenges.
To identify the relevant risk factors in the planning phase of software development, three lists of risk factors are compared and combined This process involves analyzing the descriptions of the risk factors, even if they are not expressed in identical terms For instance, the risk factor "Continually changing system" from one list can be equated to "Frequent changes in customer requirements" found in another list.
79 and related to Customer not certain that the functionality requested is "do-able" (in
43 risk factors [29]), or Poor management skills and experience (in 5 risk factors in Section 2.2) is considered the same with Lack of management experience (in 43 risk factors [29])
Table 2.9 identifies 19 common risk factors that directly or indirectly affect the likelihood of schedule success, derived from three previously mentioned lists The relationships among these factors are established based on existing literature and expert opinions For instance, risk factor (1) highlights
Large-scale offshore projects often face significant risk factors, including insufficient training and a lack of management experience These challenges arise from the project's size—measured by modules, function points, staff count, or duration—and its inherent complexity, as highlighted by insights from project experts.
Table 2.9 List of 19 common risk factors for software project scheduling
1 Large-scale, offshore and distributed
6 The best people not available for self-organizing team
7 The skill level of people (team/developer)
8 Staff is not committed for entire duration of the project
10 Staff does not receive necessary training
11 Lack of tools and methods
12 Software tools are not used to support software planning and tracking activities
13 Configuration management software tools are not used to control and track change activity throughout the software process
2.3.2 The 19 common risk factors in agile software project
Rai et al [29] identified 43 risk factors in Agile software projects, which are categorized into six key areas: Development Environment Risks, Process Issue Risks, Staff Size and Experience, Technical Issue Risks, and Technology Risks.
Schedule risks primarily encompass factors that influence iteration scheduling and planning Drawing from the author's experience and expert insights, these risks largely stem from the development environment, process-related challenges, team size, staff experience, and overall scheduling uncertainties.
Table 2.10 List of 5 risk factors for software project scheduling in Section 2.2
1 Poor management skills and experience
3 Frequent changes in customer requirements
In addition, Section 2.2 also examines a simple model of schedule risks in general software project development with five risk factors extracted in Table 2.9
This section compares and integrates two lists of risk factors, taking into account the characteristics of Agile software projects, similar to the approach in Section 2.3.1 Table 2.11 presents 19 risk factors that directly or indirectly affect the likelihood of iteration success, derived from the two previous studies These risk factors are modeled to analyze their interrelationships using Bayesian Networks (BNs), with each factor represented as a node accompanied by a node probability table (NPT) In this research, project teams or managers serve as experts in the evaluation process.
17 Customer not certain that the functionality requested is "do-able"
18 Lack of commitment of superior management
81 provide the values in the NPTs (based on his/her previous experience on the project features and the team)
The primary risk factors in software project development include a comparison of two lists: the 19 risk factors in iteration scheduling, as shown in Table 2.11, and those in Section 2.3.1, detailed in Table 2.9 The key distinction between these lists lies in risk factor 9, which addresses ineffective communication compared to the issue of staff not attending daily meetings.
Table 2.11 List of 19 risk factors in iteration scheduling
1 Large-scale, offshore and distributed
6 The best people not available for self-organizing team
7 The skill level of people (team/developer)
8 Staff is not committed for entire duration of the project
9 Staff doesn’t attend to daily meeting
10 Staff does not receive necessary training
11 Lack of tools and methods
12 Software tools are not used to support software planning and tracking activities
13 Configuration management software tools are not used to control and track change activity throughout the software process
17 Customer not certain that the functionality requested is "do-able"
Chapter remarks
This chapter introduces the BRI algorithm and CKDY tool, designed to evaluate the impact of risk factors in software project scheduling The BRI algorithm advances the Bayesian Network (BN) model for risk analysis, while CKDY focuses on assessing the impacts of these risks using a probabilistic approach that incorporates BNs Both the algorithm and the tool demonstrate the applicability of Bayes Theorem and BNs in modeling and quantitatively analyzing risks in software projects.
The development of the algorithm BRI and the tool CKDY using the probabilistic approach confirm that with BNs we always need expert’s opinions or judgment, together with mathematical calculation
This chapter explores the application of Bayesian Networks (BNs) to model the interconnections between risk factors and employs Bayes Theorem to assess the impact of these risks on software project timelines The authors emphasize the significance of identifying common risk factors that influence software project scheduling to enhance schedule management A list of prevalent risk factors affecting software project timelines is presented.
This chapter introduces a quantitative approach to effectively assess and analyze risks in software project scheduling It focuses on identifying the attributes of these risks and employing probabilistic methods for improved risk management Project managers now have access to scientific methods for tracking risks in software project scheduling, moving beyond reliance on personal experience.
Improvements can be made in utilizing the probabilistic approach, particularly in applying Bayesian Networks (BNs) for scheduling techniques and analyzing the relationships among risk factors This topic will be explored in Chapter 3.
18 Lack of commitment of superior management
Chapter 3 Incorporation of Bayesian Networks into software project scheduling techniques
Chapter 2 was initial attempts of applying BNs into risk management in software project scheduling as well as experiments on common risk factors and their impacts in software project scheduling 19 common risk factors for both traditional software development projects and agile software projects are proposed
Chapter 3 focuses on the author's efforts to develop a probabilistic method aimed at enhancing established software project scheduling techniques, encompassing both traditional and agile scheduling approaches, as outlined in the Introduction.
This chapter explores the integration of Bayesian Networks (BNs) into software project scheduling methods to improve the likelihood of successful project timelines Section 3.1 discusses the application of BNs in agile software scheduling to optimize iteration planning Sections 3.2 to 3.4 further examine the use of BNs in various scheduling techniques and analyze 19 prevalent risk factors in software scheduling, as introduced in section 2.3.
Applying Bayesian Networks into specific software project development
This section is the work represented in publication 1 [PUB1]
Agile software development methods have gained significant traction in the software industry, offering a means to mitigate project risks However, optimizing software project scheduling remains a considerable challenge due to the complexity and dynamism of industrial software development There is a pressing need for probabilistic methods that effectively model and predict uncertainties in software projects This article introduces an enhanced method and algorithm that integrates optimized agile iteration scheduling with the risk prediction and management capabilities of Bayesian Networks A software tool has been developed to assist managers in controlling project schedules, providing a reliable set of strategies for task sequencing in agile iteration scheduling.
Traditional software development methods, as discussed in Section 1.2, are typically predictive in nature, emphasizing detailed visioning and planning for the future A predictive development team clearly outlines the specific features that are intended for implementation.
Agile methods are characterized by their adaptability throughout the development process, making it challenging for teams to outline all planned features in advance Instead, these teams prioritize quickly responding to changing circumstances and effectively adjusting to project modifications as they arise.
Agile methods decompose deliverables into small iterations, significantly reducing the overall risk associated with software feature realization These iterations, or time boxes, usually span one to four weeks and encompass a complete software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing This approach not only minimizes risks but also facilitates rapid adaptation to changes.
Adopting Agile practices offers organizations benefits like faster return on investment, improved product quality, and enhanced customer satisfaction However, Agile methodologies often lack robust planning support compared to traditional plan-based approaches A survey by VersionOne identified 26 key factors influencing Agile success, with iteration planning ranking as the second most important Additionally, the survey revealed that three of the top five concerns in Agile implementation are related to planning.
13 most commonly cited greatest ones) about adopting agile within companies are
1) the loss of management control (36%), 2) the lack of upfront planning (33%) and
Project managers utilize various tools and techniques for effective project scheduling (Fox & Spence, 2023; Pollack-Johnson, 2023) A novel approach for iteration scheduling in agile software projects was introduced by Akos Szoke (2023) Additionally, Khorakadami et al (2023) proposed an enhanced method to integrate uncertainty into general project scheduling using Bayesian Networks (BNs).
Scheduling problems are a crucial aspect of combinatorial optimization, focusing on the allocation of limited resources to tasks over time The primary objective is to optimize one or more goals within a decision-making framework In software project scheduling, challenges arise due to the unpredictability of resources like personnel, time, technology, and finances Additionally, software projects are often subject to risks, which are uncertain events that can lead to negative consequences.
Iteration scheduling focuses on organizing technical tasks, which are essential units of work performed by developers Its primary goal is to decompose chosen requirements into manageable technical tasks and allocate them to developers, often involving an estimated effort in working hours Essentially, iteration scheduling seeks to create a practical, detailed plan for development that outlines the implementation of selected features within a specific iteration.
The optimized (Agile) iteration scheduling problem involves selecting the best schedule from various feasible options This optimization challenge focuses on allocating time intervals for executing activities while considering both temporal constraints, such as task precedence, and resource constraints, including resource availability, all aimed at minimizing execution time.
Although Agile software development represents a major approach to software engineering, there is no well-established conceptual definition and sound methodological support of Agile iteration scheduling
3.1.3 Optimization model for Agile software iteration
Let R be the set of resources and the following typical properties for scheduling be interpreted on technical tasks to schedule them:
Effort: wj - time estimation (in hours) is associated with each task It is calculated by simple expert estimation (e.g 2, 4, or 8 working hour (Wh))
Pre-assignment: a j - in some cases resource pre-assignment is applied before scheduling It is used by the scheduler algorithm during resource allocation
Let the vector S = {S0, S1, … , Sn+1} be start times for tasks’ realizations - where
S j ≥ 0: j ⋲ A and S 0 = 0 The vector S is called a schedule of development In this definition, the 0 and n + 1 are auxiliary elements to represent iteration beginning and termination, respectively
Dependencies between tasks j and j’ can be defined as:
The equation \( S_j - S_{j'} + d_{j'} \geq P_{j',j} \) describes the relationship between the start times of tasks \( j \) and \( j' \), where \( S_j \) is the start time for task \( j \), \( S_{j'} \) is the start time for task \( j' \), and \( d_{j'} \) represents the duration of task \( j' \) Additionally, \( P_{j',j} \) indicates the precedence between tasks, while \( A \) denotes the set of tasks that must be completed during the iteration.
In an Agile iteration, let \( R_i \in \mathbb{N} \) represent the set of resource capacities assigned to the project The effort estimation determines the resource requirements \( r_{(j,i)} \in \mathbb{Z} \) for each task \( j \) and resource \( i \) Given a schedule \( S \) and a specific time \( t \), the active set of tasks in progress is defined as \( A^*(S, t) = \{ j \in A | S_j \leq t \leq S_j + w_j \} \) The resource requirement for resource \( i \in R \) at time \( t \) is calculated as \( r_i(S, t) = \sum_{j \in A^*(S,t)} r_{j,i} \) Consequently, the resource constraints can be expressed as \( r_i(S, t) \leq R_i \) for \( i \in R \).
Thus, optimization problem for iteration scheduling can be formulated as follows:
Sn+1 ≤ l I with l I is the length of the iteration (3.3) a) Solving the optimization problem for iteration scheduling
The vector \( \mathbf{r} \) represents the available resources, specifically developers, during the iteration Each \( w_j \) denotes the planned effort or duration for technical task \( j \), encompassing both development and defect correction The elements of vector \( \mathbf{a}_j \) reference resource indices \( (a_j \in \{1, \ldots, |\mathbf{r}|\}) \), indicating which resources are pre-assigned to task \( j \) Notably, \( a_j^0 \) signifies that task \( j \) is not pre-assigned.
The algorithm identifies the optimal resource for task execution, utilizing a precedence matrix to represent task dependencies, where \( P_{j,j'} = 1 \) indicates that task \( j \) precedes task \( j' \), and \( P_{j,j'} = 0 \) otherwise The conditions \( P_{j,j} = 0 \) (to avoid loops) and the requirement for \( P \) to be a directed acyclic graph (DAG) ensure that temporal constraints are satisfiable An iteration time-box, denoted by variable \( l_I \), serves as an upper limit for resource allocation, preventing overload The algorithm produces a schedule matrix \( S \), where rows correspond to resources and columns indicate the order of task execution, with \( S_{i,p} = j \) signifying that task \( j \) is assigned to resource \( i \) at position \( p \) The ensure section mandates that each task \( j \) must be assigned to exactly one resource \( i \).
Szoke [30] proposed an algorithm for iteration scheduling, which serves as the foundation for an enhanced algorithm that integrates Bayesian Networks (BNs) The following section will discuss the incorporation of the optimization problem with BNs.
The algorithm's input includes resources, planned task durations, task precedence, and iteration length, with the assumption that tasks will be completed within the planned timeframe However, real projects face risks related to personnel and technology, leading to uncertainties that are difficult to predict This necessitates a probability model to quantify these uncertainties and address key concerns Bayesian Networks (BNs) are considered an effective probabilistic approach for modeling project uncertainties and assisting project managers in decision-making Additionally, BNs can enhance Agile iteration scheduling.
The authors propose the following factors added to the algorithm proposed by Szoke [30]: a) A matrix which represents the relationship between each task duration and assigned resources:
Incorporation of Bayesian Networks into CPM
This section is the work represented in publication 5 [PUB5]
Project managers face challenges in creating project schedules due to the inherent uncertainty in planning While various tools and techniques exist for developing and monitoring schedules, many rely on the assumption that projects will proceed as planned, which is often not the case This article explores the use of Bayesian Networks (BNs) to model uncertainty within the Critical Path Method, a widely used approach for project scheduling It also identifies 19 common risk factors that can impact project schedules and presents a model to address these risks Additionally, a tool was developed, and experiments were conducted to validate the proposed model.
In this section, the idea is to use BNs to perform the well-known CPM calculation In other words, CPM is incorporated with BNs
As described in Section 1.2.2, the main components of CPM calculation are activities Since this research is on software project, the term “task” is used as
“activity” Tasks are linked together to represent dependencies
To integrate a CPM network into a Bayesian Network (BN), it is essential to first map a single task, where each activity parameter outlined in Section 1.2.2 is represented as a node within the BN.
Figure 3.4 illustrates a schematic model of a partial Bayesian Network (BN) related to a specific task, highlighting the interrelationships among task parameters and their connections to other tasks, utilizing the Critical Path Method (CPM) algorithm in conjunction with BNs.
Figure 3.3 A part of a BN for 19 risk factors
To establish the comprehensive CPM network, where each task represents a node and a variable in the Bayesian Network (BN), we define the relationships between dependent variables Specifically, a predecessor node \(i\) is linked to its successor node \(j\).
Connecting EF of i with ES of j;
Connecting LS of j with LF of i
In the directed graph CPM, each task is associated with parameters D, LS, LF,
ES, and EF In our model, each task is also affected by a general risk which represents the set of 19 risks
Another BN formed is the BN for 19 common risk factors and a general risk
(Figure 3.3) As mentioned above, their relationship is also analysed based on literature review and project managers’ experience
Table 3.3 illustrates the connection between 19 risk factors and overall risk, with each risk factor depicted as a node that may have one or more parent and/or child nodes For instance, risk factor 3 is linked to parent node 19 and has child nodes 4, 8, and 9.
No Risk factors Parents Children
1 Large-scale, offshore and distributed
The best people not available for self- organizing team
7 The skill level of people
Staff is not committed for entire duration of the project
10 Staff does not receive necessary training
11 Lack of tools and methods 7,10,12,13
Software tools are not used to support software planning and tracking activities
Each risk factor or node is linked to a node probability table (NPT) In our study, project teams or managers acted as experts to supply the NPT values, drawing from their prior experiences with project characteristics and team dynamics.
Since there might be impacts of risks on each task, the estimated time for the task (ED - Estimate D) is no longer a value, but a range of values
Each task probability is calculated based on NPTs of D and ES From NPTs of
D and ES we will have the NPT of EF as well as the NPT of ES of the successor task
In the beginning (t = 0), P(ES) is initiated 1 (100%) Let Pi(m) be the probability of finishing task i in m days If m differs from ED - 1, ED, ED + 1 then
Configuration management software tools are not used to control and track change activity throughout the software process
Customer not certain that the functionality requested is "do-able"
18 Lack of commitment of superior management
Figure 3.4 Task’s parameters and connection to other tasks.
The CPM calculation can now be adapted to the RBCPM (Risk Bayesian CPM) procedure for software project with the following steps:
Step 1 Specify the individual tasks using a work breakdown structure
Step 2 Specify the common risk factors (in our research, they are 19 risk factors)
Step 3 Determine the sequence of those tasks and dependency between them
Step 4 Determine the relationship between the common risk factors on the project basis (i.e., context based)
Step 5 Form the BN for each task (that models the task parameters D, LS, LF,
Step 6 Form the CPM diagram in form of BN for all the tasks (that models the tasks and their dependency)
Step 7 Calculate the general risk affecting each task and estimate the completion time (duration) for each task
Step 8 Identify the critical path (the longest-duration path through the network) Step 9 Update the CPM diagram as the project progresses
3.2.3 Tool and experimental results a) The tool RBCPM
The RBCPM (Risk Analysis based on Bayesian CPM) tool, developed in Java, is designed to test the RBCPM model and its associated procedures while providing support to project managers.
The tool has the following main functions:
Model and calculate a project schedule (in form of CPM algorithm described in sections 1.2.2 and 3.2.1)
Alert project managers about tasks could be over-scheduled (so that they can have impacts on the whole project)
Calculate the possibility of the schedule (that is, chance that the project will be finished on time)
Calculate the possibility of each task (i.e., probability of finishing on time)
Model the network of risks (in form of BNs visualization) that have impacts on each task
Figure 3.5 is a screenshot of the tool which shows task information and its possibility of finishing on time
Figure 3.5 A screenshot of RBCPM b) Experimental results and analysis
Data samples used in the experiments can be categorized as:
Data samples used for CPM algorithm: sets of tasks with start time, duration and precedence constraints
Data samples used for BNs: NPTs of nodes, which often provided by the project manager or some project expert
Data samples for CPM algorithm: two samples from real-life projects as shown in Table 3.4 and Table 3.5
The first data sample included 13 tasks with a project timeline of 80 days, as detailed in Table 3.4, while the second data sample featured 24 tasks and a planned completion time of 112 days.
In Bayesian Networks (BNs), nodes represent risks or uncertainties associated with each project task The authors consulted project managers and key stakeholders to evaluate the Conditional Probability Tables (CPTs) and the interrelationships of these risks based on their project experiences They supplied an initial set of values for the parent variables of each node, along with the corresponding CPTs for the variables represented by the nodes.
7 sets of NPTs provided by the project managers for the authors’ BNs of 19 common risks Each task is impacted by one of these 7 sets of BNs
The first experiment indicates a 67.56% likelihood of completing the project within the planned 80 days (see Figure 3.6) However, the actual completion time was 95 days, with the tool estimating an 88.34% probability of finishing on time.
Figure 3.6 and Figure 3.7 are graphical illustrations from the tool BAIS to help users see the possibility of finishing the software project in certain point of time
In the second experiment, the likelihood of completing the project within the planned 112 days is 69.11% (see Figure 3.7) However, the actual completion time extended to 132 days, despite the tool estimating a probability of over 90% for timely completion.
Figure 3.6 A result for experiment with data sample 1
The findings demonstrate the model's and tool's reliability, as the calculations align well with real-life project scenarios However, the model's dependability hinges on the Bayesian Network (BN), which includes 19 common risk factors, their interrelations, and their Normal Probability Tables (NPTs) Consequently, expert and project manager feedback is essential for accurate results, a consideration that applies to any system utilizing BNs.
Results on RBCPM algorithm also confirm that tasks on the critical path have important impacts overall project Therefore, project managers need to take care of these tasks
Figure 3.7 A result for experiment with data sample 2
The research enhances CPM-based scheduling by integrating Bayesian Networks (BNs), enabling software teams to analyze schedules and predict their success rates while effectively addressing uncertainty.
This approach enables the identification of various risk sources, facilitating the analysis of software project scheduling It also quantifies the uncertainty in task durations and the overall project timeline through comprehensive probability distributions.
This method effectively addresses uncertainties that traditional approaches struggle with, particularly those arising from the interrelationships between activities and risk factors By incorporating all key planning elements, such as dependencies and capacities, into a mathematical model, it enhances the quality of software development scheduling and reduces lower-level risks.
Incorporation of Bayesian Networks into PERT
This section, based on publication 6 [PUB6], explores the use of Bayesian Networks (BNs) for modeling and assessing uncertainty in software project scheduling, particularly through the Program Evaluation and Review Technique (PERT) under high uncertainty conditions It examines common risk factors in project scheduling and validates a model of 19 identified risk factors and their causal relationships as proposed in Section 2.3.1 Additionally, the research adapts risk categories and levels from construction projects to the context of software projects and introduces a custom-built tool to experiment with and validate the proposed model.
This research introduces a model akin to the one presented in Section 3.2, with two key distinctions: it employs the PERT scheduling technique in place of CPM and conducts a more in-depth analysis of risk factors by utilizing an adapted risk categorization and levels specific to construction projects Additionally, it identifies common risk factors associated with these projects.
This section analyzes 19 common risk factors, as detailed in Table 2.9, that directly or indirectly affect the likelihood of schedule success, following the approach outlined in Section 3.2.
In Bayesian Networks (BNs), each risk factor is depicted as a network node, representing an event with a specific probability of occurrence Nodes can have parent and/or child nodes, illustrating their relationships For instance, risk factor node 3 has parent node 19 and children nodes 4, 8, and 9 A general risk factor serves as a representative of the cumulative impact of common risk factors on an activity at a given time Table 3.3 provides an analysis of each risk factor node and the interconnections among the 20 nodes, which include 19 risk factor nodes and one general risk node.
Each risk factor or node is linked to a node probability table (NPT) In our study, project teams or managers acted as experts to supply values for the NPTs, drawing from their prior experiences with project characteristics and team dynamics We propose a Risk Bayesian PERT method to enhance this process.
To create the complete PERT network, where each activity represents a node and a variable in the Bayesian Network (BN), we establish the relationships between dependent variables Specifically, the predecessor node \(i\) is linked to the successor node \(j\).
Connecting tEF of i with tES of j;
Connecting tLS of j with tLF of i
In the Bayesian PERT network, each activity is associated with parameters t (total duration), tLS, tLF, tES, and tEF as shown in Figure 3.8
Figure 3.8 Bayesian Network for each activity
In the authors' model, each activity is influenced by a total risk encompassing 19 distinct risks The Bayesian PERT network illustrates the time nodes for each activity and their interrelationships As highlighted in Section 3.1, risk factors consistently impact each activity, necessitating their inclusion in the model The Bayesian PERT model demonstrates the connections between the total duration node \( t(i) \) and the early finish (tEF) of each activity, as well as the relationship between the tEF of a predecessor and the early start (tES) of the subsequent activity Consequently, if the total duration node \( t(i) \) is impacted by risks, this will indirectly influence the tES and tEF nodes of the activity This approach significantly streamlines calculations while acknowledging the effects of risks on all time nodes.
A new Bayesian Network (BN) has been developed to represent 19 common risk factors and overall risk, as outlined in Section 3.1 This BN effectively captures the influence of all risks on each activity node, facilitating straightforward integration of risk impacts For a visual representation of the model, refer to Figure 3.9.
The "total duration" node in Figure 3.9 illustrates the execution time of the activity node influenced by risk factors Additionally, the "total risk" node encapsulates the entire risk model, while the estimated duration \( t(i) \) signifies the projected execution time of the activity.
106 activity in the scheduling process The above model is the Risk Bayesian PERT (RBPERT) Model
Figure 3.9 Risk integration network model into PERT scheduling c) The improved RBPERT Model
Chang et al [23] categorized construction project risks into 2 categories and 7 levels Risks are divided into 2 categories:
Risks due to the physical environment
Resource risks can be categorized into five key subcategories: people, which refers to the availability of skilled or unskilled laborers; machines, concerning the availability of necessary equipment; materials, focusing on the availability of essential materials; methods, related to the availability of suitable techniques; and money, which pertains to the availability of financial resources needed to carry out an activity.
Adapted to software development project, in this research the machine category is considered as technological risks, and materials category is considered as support tools
Considering all the above risk factors, seven risk levels are classified for estimating the duration of an activity:
Level 1: There is a risk of physical environment
Level 2: There is a risk of physical environment + 1 of 5 resource risks Level 3: There is a risk of physical environment + 2 of 5 resource risks Level 4: There is a risk of physical environment + 3 of 5 resource risks Level 5: There is a risk of physical environment + 4 of 5 resource risks
Level 6: There is a risk of physical environment + all 5 resource risks
The process of scheduling and risk management improvement is as following 8 steps and also shown in the Figure 3.10
Figure 3.10 Process in improved RBPERT Model
Step 1: Project creation (initialize the basic information of the project)
Step 2: Activity definition (determine the activities needed to be done in the project and estimate the activity durations)
Step 3: Relationship connection (draw relationships between activities using BNs)
Step 4: Risk item breakdown (analyse possible risk factors in the project and estimate their impacts on the activities)
Step 5: Risk allocation (allocate risk factors to the activities)
Step 6: Information check (check the accuracy of relationships between activities, and risk factors information)
Step 7: Duration calculation (calculate the total duration of each activity node by applying the 7-risk-level method)
Step 8: PERT calculation (calculate the overall project duration and critical path for the 7 risk levels, with PERT technique).
3.3.2 Tool development and data collection a) The tool RBPERT
The tool RBPERT was built in Java programming language which includes the following main functions [105]:
Calculates the start and end time of each task (activity) with PERT scheduling technique and calculation
Calculates and provides a distribution chart that accumulates the probability of project completion time
Provides the RBPERT model of the project
Figure 3.11 displays the tool's input screen, which facilitates the selection of an input file and generates a schedule using the PERT technique, along with the corresponding PERT Bayesian Network linked to the schedule.
Figure 3.11 The input screen of the RBPERT tool
The tool utilizes an XLS input file that lists tasks for the software project, including attributes such as task ID, PERT time estimates (optimistic, most likely, and pessimistic), predecessor task IDs, and optionally, task names.
Figure 3.12 The input file type of the RBPERT tool
The tool processes input data based on the following flow:
Firstly, read data from the input file to create a tasks sequence and to build a predecessor relationship between tasks Calculate the Duration node and Total Duration node of each task
After initializing the task, calculate the parameters: the earliest starting time (tES), the earliest finish time (tEF), the latest starting time (tLS), and the latest finish time (tLF) for each task.
Initialize BNs of each task and between tasks as described in Section 3.2
Calculate of probability accumulation of the earliest starting point tES, the earliest finish time tEF of each task
After the calculation, the tool provides the chart of cumulative probability of the project completion time and the RBPERT network of the project (Figure 3.13) b) Data collection
The authors gathered data from three real-world projects conducted by a major software company in Vietnam This sample data, along with the source code for the RBPERT tool, has been made available on GitHub.
The first software project had 10 tasks (Table 3.8) and was planned to finish in
79 days However, in fact, it was done in 88 days
Table 3.6 Task attributes of the first data sample
No id Optimistic Most likely Pessimistic Predecessor
The second software project consisted of 9 tasks (Table 3.9) and was expected to finish in 95 days In reality, the project was done in 104 days
Table 3.7 Task attributes of the second data sample
No id Optimistic Most likely Pessimistic Predecessor
Incorporation of Bayesian Networks into Agile software development scheduling 114 1 Optimization model for Agile software iteration
This section discusses the use of Bayesian Networks to model risk factors in Agile software projects and manage risks in Agile iteration scheduling It identifies 19 common risk factors that impact iteration scheduling Additionally, a software tool was developed to assist managers in controlling project schedules by evaluating the likelihood of each schedule's success.
3.4.1 Optimization model for Agile software iteration
3.4.2 Tool and experimental results a) Building tool
We developed the BAIS (Bayesian Agile Iteration Scheduling) tool using Java to implement our proposed model and algorithm This tool enables users to input various parameters, including the number of developers, tasks, iteration lengths, task precedencies, pre-assignments, and task durations Additionally, it requires a probability table indicating the likelihood of each resource completing their assigned tasks on time.
The tool has the following main functions:
Providing an iteration schedule based on the input data
Providing the possibilities for each task, resource and the whole iteration
Displaying BNs for resources There are also options for adjusting the nodes’ NPTs so that project managers can examine the projects in different scenarios
Figure 3.16 shows a screenshot of the tool in which the pop-up message shows an example of the possibility (69.95%) for finishing a schedule
Figure 3.16 A screenshot of tool BAIS b) Experimental results and analysis
The authors conducted two experiments utilizing real data samples, with the first sample focusing on an e-commerce project that employed the Scrum methodology This project featured a sprint consisting of 7 resources and a total working time of 460 hours Within this sprint, there were 43 tasks, including five precedence tasks: P[1] = 3, P[2] = 3, P[3] = 4, P[5] = 6, and P[6] = 7, indicating that certain tasks must be completed before others can commence.
Table 3.9 The result for the first data sample
Table 3.13 presents the results from the initial data sample, indicating an overall completion possibility of 59.85% for the assigned tasks When the sprint duration is adjusted to 450 hours, this completion possibility increases to 60%, reflecting a reliable assessment of the project's real situation In the second experiment, a more complex software project in the education sector was analyzed, involving 17 developers tasked with completing 85 tasks across 9 Scrum sprints The first sprint consists of 54 tasks over 10 working days, while the final sprint includes 35 tasks, also within a 10-day timeframe The calculations from the BAIS tool, illustrated in Figure 3.17, provide further insights into the project's progress.
The overall probability for the first sprint stands at 67.12%, with only 35 out of 54 tasks completed as scheduled, resulting in a completion rate of 64.82% This indicates a 2.3% discrepancy between the tool's calculations and the actual performance.
The overall probability for the last sprint is 73.31% Infact, the sprint has 9 tasks over-scheduled meaning 74.29% which is almost the same as calculated by the tool (0.98% difference)
The complexity of the project in the second case is evident due to the numerous tasks and constraints involved, which can result in over-scheduled sprints.
Figure 3.17 The result of the second experiment
The experiments demonstrate that the tool effectively aids decision-making in Agile software development planning by customizing plans based on the specific project context and user or customer feedback Additionally, project managers can utilize the tool to forecast upcoming phases or iterations, gaining insights into how failures in one phase may affect the overall project.
This section presents an algorithm for Agile iteration scheduling that integrates Bayesian Networks (BNs) to assist software teams in analyzing schedules and predicting their success rates By incorporating key planning factors such as dependencies and capacities into a mathematical optimization model, this method enhances the quality of Agile software development planning and reduces lower-level risks.
The results of experiments on the available data sets indicate that the approach can provide practical value as a decision support tool for Agile iteration planning
To strengthen the findings, it is essential to gather more representative real-life data sets and conduct case studies Additionally, the 19 common risk factors identified in Agile iteration scheduling should be further analyzed and refined through literature reviews and case studies.
This section, despite its limitations, represents a significant advancement towards developing a conceptual model for Agile iteration planning and scheduling The research enhances our understanding of resource-constrained project scheduling issues, potentially leading to the formulation of a new optimization problem specifically focused on Agile iteration scheduling.
The upgraded BAIS tool will integrate Bayesian Networks (BNs) to effectively represent and analyze causal models under uncertainty This new version will offer a comprehensive suite of tools for developing probabilistic inference and decision support systems based on BNs, aiding software project managers in making informed decisions regarding scheduling and planning for various software projects.
Chapter remarks
This chapter focuses on developing an enhanced model for managing uncertainty and risks in software project scheduling by integrating scheduling techniques with common risk factors It proposes an improved scheduling method that combines Bayesian Networks (BNs) with established techniques such as PERT, CPM, and Agile software development Experimental results demonstrate that the proposed model effectively addresses 19 common risk factors, performing well with both CPM and PERT under high uncertainty conditions These findings successfully fulfill the second objective outlined in the Introduction.
The research has done the following tasks:
- Carrying out literature review on project scheduling techniques, software project scheduling techniques, and on risk factors in software project scheduling
This article proposes scientific models for risk management in software project scheduling, focusing on common risk factors and their impacts on project timelines It aims to assist software project managers in effectively tracking their schedules The models utilize a probabilistic approach through Bayesian Networks and are applicable to both traditional waterfall and agile software development methodologies.
- Validating proposed models by building tools and carrying out experiments with data from the real world
The thesis has successfully met its two objectives, with the findings disseminated through six published conference and journal papers, as detailed in the List of Scientific Publications section.
The research introduces the BRI (Bayes Risk-Impact) algorithm and the CKDY tool to evaluate risk impacts, identifying 19 common risk factors in software project scheduling applicable to both agile and traditional development methodologies.
The research introduces innovative scheduling methods for software project development by integrating Bayesian Networks and common risk factor models with established techniques like PERT, CPM, and Agile Tools have been developed to test these proposed methods, and experimental results demonstrate their reliability and practical value for software development teams in analyzing, monitoring, and predicting project risks and success probabilities.
The thesis addresses various aspects of risk management in software project development by tackling distinct components and identifying key risk factors.
The thesis presents 120 software project scheduling cases, each utilizing a distinct data set, leading to a lack of consistency across the data in Chapters 2 and 3 Despite efforts to obtain real software project data from reputable Vietnamese companies, these approaches have not been implemented in ongoing projects Consequently, all experiments were conducted using completed projects, relying on insights from project personnel, particularly project managers.
The empirical evaluation criteria present a limitation in the thesis due to insufficient data from real software projects, which hinders a robust evaluation Currently, the assessment of experimental results relies on information from project teams, who also serve as experts in validating these results.
The research focuses on optimizing software project scheduling through the enhancement of existing algorithms rather than introducing a new one It primarily utilizes probabilistic approaches to improve current methods.
The proposed approach in this research demonstrates practical value as a decision support tool for software scheduling and planning, as evidenced by experiments on existing data sets To strengthen these findings, it is essential to utilize more representative real-life data sets and conduct case studies on ongoing software projects The author aims to develop consistent data sets for both traditional and agile software project development, which could also benefit the research community.
Future research should focus on integrating additional sources of uncertainty into the model and addressing common causal risks that impact multiple tasks Additionally, the existing list of 19 common risk factors in software scheduling can be enhanced through case studies or surveys.
The research would also go further with finding out a software scheduling optimization algorithm using Bayesian Networks
Nguyễn Ngọc Tuấn and Huỳnh Quyết Thắng (2017) presented a study on "Iteration scheduling using Bayesian networks in Agile Software Development" at the 10th National Conference on Fundamental Research and Application of Information Technology (FAIR’10) held in Da Nang on August 17-18, 2017 The findings are documented in the conference proceedings, pages 300-308, with the ISBN 978-604-913-614-6.
Nguyễn Ngọc Tuấn, Võ Thị Hường và Huỳnh Quyết Thắng (2017) đã trình bày nghiên cứu về mô hình mạng Bayes trong việc đánh giá rủi ro khi lập lịch dự án phần mềm Bài viết được công bố trong Kỷ yếu Hội nghị Quốc gia lần thứ X về Nghiên cứu cơ bản và ứng dụng Công nghệ thông tin (FAIR’10) tại Đà Nẵng, diễn ra vào ngày 17-18 tháng 8 năm 2017, với các trang 275-282 và mã ISBN: 978-604-913-614-6.
PUB3: Nguyễn Ngọc Tuấn, Trần Trung Hiếu, Huỳnh Quyết Thắng (2017),
Phương pháp xác suất cải tiến với mạng Bayes được áp dụng để đánh giá rủi ro trong lập lịch dự án phần mềm Nghiên cứu này được công bố trong chuyên san Công nghệ thông tin và Truyền thông, thuộc Tạp chí Khoa học và Kỹ thuật của Học viện KTQS, số 184, phát hành tháng 6 năm 2017, trang 45-61, với mã ISSN: 1859-.
Nguyen Ngoc Tuan and Huynh Quyet Thang (2018) explore risk management in Agile software project iteration scheduling through the application of Bayesian Networks Their research is published in "New Trends in Intelligent Software Methodologies, Tools and Techniques," Volume 303, spanning pages 596 to 606 This work is part of the SOMET 2018 conference proceedings and is indexed in SCOPUS, with the DOI 10.3233/978-1-61499-900-3-596.