Overview of software project scheduling and risk management
Software project management and software project scheduling
Software project management combines the art and science of effectively planning and overseeing software projects This specialized area of project management focuses on essential tasks such as planning, scheduling, resource allocation, implementation, tracking, and the successful delivery of software and web-based projects.
Software project management differs significantly from traditional project management due to the unique nature of software development Unlike manufactured goods, software is an intangible product that offers exceptional flexibility Additionally, software engineering lacks the formal recognition of other engineering disciplines, such as mechanical or electrical engineering The lifecycle of software projects involves multiple iterations of testing, updates, and customer feedback, and there is no standardized development process Furthermore, most software projects are unique endeavors, meaning that development teams rely on similar past experiences rather than a repeatable process.
Software project management involves the methodologies used to organize all activities associated with software development Effective project management is essential, as software projects often face constraints related to budget and time.
In today's fast-paced business environment, agile project management has become the preferred approach for IT projects, enabling teams to develop software collaboratively and adapt quickly based on feedback from customers and stakeholders Moreover, the principles of agile are now being applied beyond the IT sector, gaining traction in various other fields of project management.
The project manager is pivotal in guiding the project team and serves as the main liaison among investors, suppliers, and senior management They ensure the project adheres to established constraints while delivering software products on schedule Key responsibilities of software project managers include overseeing timelines, coordinating resources, and maintaining communication across stakeholders.
Effective planning and scheduling are essential for project success, as they create a comprehensive blueprint that guides the entire process from ideation to completion This involves defining the project scope, allocating resources, proposing a realistic timeline, and outlining an execution plan Additionally, a solid communication strategy is crucial, along with clear steps for testing and maintenance to ensure the project's long-term viability.
A software project manager must effectively assemble and lead a diverse project team, including developers, analysts, testers, graphic designers, and technical writers This role demands exceptional communication, interpersonal, and leadership skills to ensure successful collaboration and project outcomes.
The project manager plays a crucial role in overseeing 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, which often face inevitable changes to the original plan Software project managers must excel in risk management and contingency planning to navigate roadblocks and maintain progress throughout the project lifecycle.
Software project managers, much like their traditional counterparts, are responsible for developing a project budget and adhering to it closely, while also managing expenditures and reallocating funds as needed.
Effective software project management emphasizes continuous 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 to ensure project success.
Managers play diverse roles in software project management, focusing on ensuring timely delivery and adherence to organizational requirements Their key activities include planning, estimating, and scheduling to meet project goals effectively.
Project management, as outlined by the Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK) guide, consists of five essential stages: Initiating, Planning, Executing, Monitoring and Controlling, and Closing.
In contemporary software project planning, effective project risk management and scheduling are vital for ensuring efficient organization These tasks are key to the optimal allocation of resources, including hardware, software, and network components, as well as the assignment and monitoring of tasks and personnel.
Software projects differ significantly from other types of projects due to the constantly evolving requirements throughout the software 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 Capability Maturity Model Integration (CMM/CMMi) or Project Management Professional (PMP) As illustrated in Figure 1.1, risk management influences all processes within the Process Groups, and project teams should be prepared to adjust or update their planning as they execute, monitor, and control 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 highlight task dependencies and identify the critical path, while Gantt Charts visually display the project schedule against a calendar timeline.
Program Evaluation and Review Technique – PERT [16, 17, 19, 40]
Project scheduling, particularly in uncertain conditions, is a key focus in risk quantification within project management Creating a reliable 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 explores key project scheduling techniques, highlighting classical methods such as CPM and PERT, alongside modern simulation-based approaches favored by many project management software tools Additionally, it briefly examines alternative methods like the Critical Chain Method and Fuzzy Logic, and discusses scheduling techniques specifically tailored for agile software development.
1.2.2 Traditional scheduling methods and techniques a) Critical Path Method (CPM)
The Critical Path Method (CPM) is a widely recognized project scheduling technique that was developed by DuPont in 1957 It has since become the standard 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
A critical activity, characterized by zero float time (TF = 0), requires special attention as any delay in this activity will impact the entire project's 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 activities While it is not designed to address 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 project management methodologies that incorporates risk assessment A key feature of PERT is its capability to manage uncertainty in activity durations, recognizing that variations in time estimates can impact the overall project timeline 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 instead of relying on a single CPM estimation This method involves three time estimates—optimistic, most likely, and pessimistic—which are essential for calculating the expected time and standard deviation for each activity.
An optimistic time estimate refers to the projected duration for completing a task under ideal conditions, representing the best-case scenario where everything proceeds smoothly Essentially, it indicates the minimum time required to finish the activity successfully.
The most likely time estimate refers to the duration in which there is a strong likelihood of successfully completing a task within a specified timeframe, representing the expected duration under typical circumstances.
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 a task, highlighting the longest possible duration for its completion.
Expected time: μi = (Optimistic + 4xMost likely + Pessimistic)/6
The critical path is essential for determining the earliest completion time of a project, with its total duration setting the final deadline PERT emphasizes a single, unchanging critical path, advising managers to concentrate on these key activities to maintain the project's timeline The expected value of the critical path is derived from the expected values of individual activities, while its variance is the sum of all activities' variances, 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 in the 1980s with advancements in computer technology, making it a key method for managing risk and uncertainty in projects The fundamental approach of MCS involves utilizing the project activity diagram.
The estimated duration of each activity is determined using the shortest, most likely, and longest durations, alongside the distribution shape, such as Normal or Beta Following this, critical path calculations are conducted multiple times, utilizing random values derived from the activities' distribution functions.
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 are capable of linking project schedules to risk registers and employing simulation techniques to perform probability impact analyses effectively.
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 attention over the past two decades Since 1990, various Risk Management Processes (RMP) have emerged, with prominent frameworks including Chapter 11 of the PMBOK guide, the PRAM guide, and the RAMP guide Many organizations adopt these guidelines or customize them to create their own processes While this thesis does not delve into the specific differences among these guides, it acknowledges that, despite varying assumptions and methodologies, they all share a 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 in a project This process employs various data-gathering techniques, such as interviews, brainstorming sessions, the Delphi technique, and checklists, to identify potential risks that could impact the project's success, involving all stakeholders in the process.
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 is a crucial documentation tool that outlines the sources of risks, their classifications, and corresponding responses, as noted by Chapman and Ward Its primary purpose is to facilitate regular reviews of project risks by the project team, according to Ward Patterson and Neailey introduced a risk register database system designed to enhance project risk management While risk registers are effective management tools, they cannot encompass all risks, as there will always be unknown risks—those that are undiscovered, unattended, or immeasurable—that may hold greater significance than those identified in the register.
The Risk Analysis stage, also referred to as quantitative risk management, focuses on evaluating the potential risks and their effects on project outputs such as cost, time, and performance During this phase, the likelihood of each identified risk occurring, along with its potential impact on the project, is assessed This assessment leads to the creation of 'probability-impact' (PI) matrices, which help in ranking and prioritizing risks Many quantitative tools and techniques, particularly simulation-based tools, are utilized in this process.
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 phase utilizes insights gained from the analysis stage to enhance the likelihood of meeting project objectives As a crucial decision-making process, it offers various alternative strategies for planning effective 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 insights from 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 US Department of Transportation These sources advocate for the implementation of processes characterized by distinct 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 critical phase within project risk management, and in some literature, it is considered synonymous with risk management itself.
Risk analysis typically begins with qualitative analysis, 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 in the early phases, such as feasibility studies and planning Regular updates during the implementation phase, aligned with agile software development practices, further enhance its effectiveness.
Risk analysis represents the formal aspect of project risk management, often utilizing advanced techniques and specialized software tools The application of these techniques varies in complexity based on available resources and project specifics Implementing risk analysis can provide significant advantages to software projects, enhancing their overall success and efficiency.
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
Current project scheduling methods fail to effectively model and quantify unknown risks, which are recognized by various authors under different terminologies Traditional approaches, primarily focused on the "probability impact" model, can only address known risks Most existing quantitative risk analysis techniques are event-oriented, concentrating on the likelihood of specific events occurring, and they operate under the assumption that potential risks and their impacts on activity duration are already identified and understood.
Unknown risks are unpredictable and difficult to measure, making their impacts challenging to assess Clarifying these risks demands significant effort, exemplified by Internally Generated Risk (IGR), which arises from within the project team or organization IGRs stem from various internal factors, including rules, policies, regulations, organizational structures, actions, behaviors, and the overall culture of the organization.
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 phases and processes, underscoring the complexity of managing uncertainties in project planning.
In project scheduling, one of the primary risks lies in accurately estimating the duration of specific activities Challenges in this estimation often stem from insufficient knowledge of 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 Probabilistic Cause-Effect Model, is a specialized graphical model that combines directed acyclic graphs (DAGs) with probability tables to illustrate causal relationships within a dataset In this framework, nodes represent random variables with associated probability distributions, while directed edges indicate weighted causal connections between these variables Each node possesses a conditional probability table that defines its likelihood based on its parent nodes, and if a node lacks parents, it is characterized by unconditional probabilities This structure facilitates inference and prediction, making Bayesian Networks a powerful tool for understanding complex systems.
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 utilized to update the belief, or posterior probability, regarding 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) enable the calculation of the complete joint probability distribution Many variables, denoted as Ai, exhibit conditional independence, allowing for simplification of the probability formula.
Bayesian Networks (BN) enable the integration of probability distributions linked to individual nodes, utilizing initial distributions derived from expert opinions, surveys, or various mathematical techniques This approach combines both expert insights and quantitative analysis to inform decision-making processes.
A Bayesian Network (BN) comprises two main components: the qualitative aspect, which illustrates the relationships between variables through a directed acyclic graph, and the quantitative aspect, which defines the probability distributions linked to each node in the model For instance, Figure 1.3 depicts a BN that outlines the correlation between subcontractor quality, team staff quality, and the likelihood of task delays.
In the Bayesian Network (BN) illustrated in Figure 1.3, the qualitative component comprises three nodes that signify uncertain variables and two edges indicating relationships between these variables Each node, such as Staff Quality, is defined by distinct states, including "Good" and "Poor." The directed graph's edges depict how changes in one variable, like Sub-contract or Staff Quality, can influence outcomes, such as Delay in Task.
In the quantitative analysis, each node is linked to a probability table that outlines the likelihood of each state of the variable Prior nodes, which lack parents, feature tables that are independent of other variables and are referred to as prior probabilities or prior distributions, reflecting initial beliefs For instance, the Staff Quality node shows P("Good") = 0.7 and P("Poor") = 0.3 Conversely, nodes with parents include probability tables that present conditional probabilities for every possible combination of the states of their parent nodes, 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 provides a framework for quantifying uncertainty about parameters through subjective probabilities (prior probabilities) and conditional probabilities (likelihood functions) When new data is available, Bayes’ theorem facilitates the transition from prior probabilities to updated conditional probabilities, known as the posterior distribution For instance, a project manager evaluating delays in a task assigned to a sub-contractor estimates a 95% probability of timely delivery based on the sub-contractor's 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 on-time 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 complex with multiple variables and intricate conditional dependencies To address this challenge, Bayesian Networks (BNs) are constructed.
1.4.3 Bayesian Networks and project risk management
Bayesian Networks (BNs) provide a structured approach to modeling uncertainty and causality, making them valuable for risk assessment in fields like medicine, finance, and critical systems Their rigorous methodology positions BNs as an ideal tool for project risk analysis, offering significant advantages in understanding and managing potential risks.
Bayesian Networks (BNs) offer a structured approach to effectively utilize subjective information, presenting a clear visual and formal framework for analyzing and validating subjective probabilities This capability is especially beneficial in project risk analysis, where subjective judgments often represent the most viable option for decision-making.
- 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 for refining beliefs about unknown factors that are challenging to measure and were previously evaluated subjectively.
Bayesian Networks (BNs) enable comprehensive sensitivity analysis by allowing reasoning from effects to causes and vice versa This capability facilitates the exploration of various 'what-if?' scenarios, providing insights when multiple variables change at once.
Bayesian Networks (BNs) offer a powerful method for making predictions with incomplete data, particularly in project risk analysis, yet their application remains limited Initial implementations by McCabe and Nasir et al focused on modeling the interplay between key risk variables impacting construction project durations They identified ten specific risk categories, including environmental, geotechnical, and labor-related factors, and pinpointed 70 detailed risk variables within these categories Additionally, eight activity groups were established to encompass all construction activities, such as mobilization and demolition Through extensive 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 output of the BN model, which provided upper and lower duration limits, was then integrated into a Monte Carlo Simulation (MCS) model to assess the overall impact of risks on project schedules.
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 bounds 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, focusing on software project scheduling and risk management It also introduces a probabilistic approach utilizing Bayesian Networks (BNs), covering Bayesian inference and the methodology for constructing BNs.
Despite the growing importance of risk management in software project scheduling, research on the application of Bayesian Networks (BNs) in this area remains limited This thesis aims to bridge that gap by reviewing existing literature on project management, scheduling, and risk management, while also identifying specific risk factors that influence software project scheduling.
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 emphasizes the significance of understanding these risk factors and their impacts on successful project scheduling.
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 relationships between risk factors introduced in Chapter 2.
Common risk factors and experiments on Bayesian
Application of Bayesian Networks into schedule risk management in software
This section presents a mathematical model and algorithm, known as BRI, designed to evaluate critical project values by assessing 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 calculate risks, as well as their influence on project success.
2.1.1 Common risk factors in software project management
In 2000, Arizona State University at Tempe developed a model to evaluate the potential impacts of software risk factors on development projects, identifying 24 common risk factors that can affect 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 involving 29 IT specialists with 5 to 25 years of experience in the industry, who provided insights to refine the model by adjusting probabilities and weights The research culminated in a list of the 24 risk factors along with their associated occurrence probabilities, as detailed in Table 2.1.
Table 2.1 highlights 24 risk factors that, while applicable to software projects in general, significantly influence project duration and schedules This list serves as a foundational tool 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 have developed sub Bayesian Networks (BNs) for each of the 24 software risk factors identified in Section 2.1.1, as illustrated in Figures 2.1 to 2.24 Additionally, an overall BN for risk modeling in software projects is presented in Figure 2.25 These BNs depict the risk factors along with their impacts categorized into three weight levels: + for level ONE, ++ for level TWO, and +++ for level THREE, with + being the lightest and +++ the heaviest, as further detailed in the calculations in Section 2.1.3.
The risk factor "Staff experience shortage" significantly influences both "staff training" and "untrained staff," with each carrying an impact weight of one Additionally, "staff training" affects the "project schedule," which is also impacted by the risk factors "Low productivity" and "Lack of senior management commitment."
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.
Figure 2.9 illustrates a sub Bayesian Network (BN) that identifies risk factors impacting software project schedules, specifically focusing on risk factor number 16, which highlights the "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”
In the context of organizational maturity, risk factors such as "Inaccurate cost estimating" and "Schedule pressure" significantly impact project outcomes These risks are interconnected with "Inaccurate metrics" and "Excessive reliance on a single process," highlighting the importance of accurate data and diverse methodologies in effective project management.
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-branch of the risk factor "Incapable project management," which is recognized in literature as having a significant impact on project schedules This thesis will validate this finding through experiments This risk factor is closely related to "Lack of senior management commitment"—a common issue across all examined risk lists—and "Creeping user requirements." Hui and Liu [9] indicate that these three risk factors have a high likelihood of affecting 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
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 probabilities derived from expert opinions, surveys, or mathematical methods These probabilities can be refined using Bayes' rule, chain rules, and Bayesian inference, as discussed in previous sections.
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
Understanding the propagation of evidence is crucial in probability theory For instance, if the likelihood of event z occurring is P(z) = 0.9, and the conditional probability of event y occurring given z is P(y|z) = 0.7, then the probability of event x occurring given both y and z is P(x|y,z) = 0.6 This illustrates how the occurrence of one event influences the likelihood of subsequent events.
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 evaluation of risks in software projects by enabling managers to assess their impact based on known probabilities of occurrence Developed using C# and the MS.NET Framework 4.5, this software aids in ensuring successful project completion by effectively analyzing potential risks.
* Input: Risk factors and probability (Table 2.1)
The impact of risk factors on the success of a software project is quantified through a vector of numerical values, where a higher value indicates a greater potential impact 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 introduce uncertainty due to factors such as hardware, software, technology, personnel, costs, and processes Traditional scheduling methods often operate under the unrealistic assumption that tasks will proceed exactly as planned, a scenario rarely seen in practice Recent studies in risk management highlight the connection between uncertainty and project outcomes This article 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 implement the four-step method proposed by Kumar and Yadav to enhance software project scheduling The steps include identifying the highest-ranked risk factors, establishing causal relationships among these factors, creating a node probability table (NPT) for each factor, and calculating the probability values for the software risk factors relevant to the project Each step involves selecting appropriate solutions for the development of the CKDY tool, with a detailed description of the chosen options provided.
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 risk prediction and assessment models have been developed that utilize these software risk factors, though not all factors are applicable to every project type Comprehensive assessment of all risk factors can lead to challenges, including high computational complexity and increased costs Therefore, prioritizing the most critical software risk factors for each project phase can enhance the accuracy of risk predictions and assessments.
In our analysis, we synthesized various published risk factors, including the SEI risk classification, NASA NPD2820 risk classification, and research findings from Hui and Liu, alongside Kumar and Yadav's selection of 27 risk factors This process led us to identify 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 among nodes 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 ultimate 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 constructing a Bayesian Network (BN) in project management Each node's NPT relies on project data, and expert evaluation is essential for effective model building and NPT construction For this purpose, we utilized the PSPLIB (Project Scheduling Problem Library) dataset to develop the NPTs An example of the probability of risk factors is provided in Table 2.4 below.
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 to assess the probability of each node, we can ultimately determine the likelihood of project success To facilitate these calculations, we utilize the HuginExpert support library This approach not only forecasts the potential failure of risk management in project scheduling but also proposes a risk management sequence This sequence enables managers to identify problem areas within the project, prioritize issues for resolution, and allocate resources effectively The core of this risk management sequence involves continuous monitoring of the project schedule throughout each phase, 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 Its key features include calculating and predicting project risk probabilities, alerting managers at the end of each phase, ranking risk factors, and presenting visual graphs that illustrate probability variations over time.
The IEEE Standard 1540 (2001) outlines a comprehensive risk management process that includes planning and implementing risk management strategies, managing the project's risk profile, conducting risk analysis, monitoring risks, treating identified 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 "Incomplete Mission," "Wasted Resources," and "Reliability" is essential for project success The duration of this monitoring will vary based on project resources and the specific timeframe determined 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 for resource efficiency, nodes can be easily ranked based on their operational costs In cases where such data is lacking, the BN model will be utilized 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 introduces common risk factors that influence software project scheduling Specifically, Section 2.3.1 discusses risk factors prevalent in traditional software projects, while Section 2.3.2 focuses on those associated with agile software projects.
2.3.1 The 19 common risk factors in traditional software project
Wallace et al identified 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 of the thesis, the author analyzes 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 identified 43 risk factors in Agile software projects, 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 risk factors, which are prevalent across various project activities, primarily stem from the development environment, process-related issues, team size and experience, as well as scheduling challenges.
To effectively identify risk factors in the planning phase of software development, three lists of risk factors are compared and combined based on their descriptions, even if they are not worded identically For instance, the risk factor "Continually changing system" aligns with "Frequent changes in customer requirements," demonstrating the importance of recognizing synonymous risks in project management.
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 outlines 19 common risk factors that directly or indirectly affect the likelihood of schedule success, derived from three previously mentioned lists These relationships are established based on existing literature and expert insights For instance, risk factor (1) highlights a key aspect influencing project timelines.
Large-scale offshore projects often encounter 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 numbers, 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 identified 43 risk factors in Agile software projects, categorized into Development Environment Risks, Process Issue Risks, Staff Size and Experience, Technical Issue Risks, Technology Risks, and Schedule Risks This section focuses specifically on the risk factors that impact iteration scheduling and planning, which primarily stem from development environment, process issues, staff size and experience, and schedule risks, as supported by the author's experience and expert opinions.
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, focusing on Agile software project characteristics, 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 previous studies These factors are modeled to analyze their interrelationships using Bayesian Networks (BNs), with each risk 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)
In software project development, the primary risk factors related to iteration scheduling include a notable distinction in communication issues, as outlined in the comparison of Table 2.11 and Table 2.9 Specifically, the ninth risk factor highlights the difference between ineffective communication and 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 enhances the Bayesian Network (BN) model for analyzing these risks, while CKDY focuses on assessing the effects of risks using a probabilistic approach, including BNs Both innovations demonstrate the applicability of Bayes Theorem and BNs in modeling and quantitatively analyzing risks within 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 schedules The authors emphasize the significance of identifying common risk factors that influence software project scheduling, which is crucial for effectively managing and monitoring software timelines Proposed common risk factors in software project scheduling are also discussed.
This chapter introduces a quantitative approach to enhance the assessment and analysis of risks in software project scheduling By identifying the attributes of these risks and employing probabilistic methods, project managers can effectively manage risks rather than solely relying on their experience This shift towards scientific methods enables a more reliable tracking of risks in software project scheduling.
Chapter 3 will explore enhancements in the application of probabilistic approaches, specifically focusing on the use of Bayesian Networks (BNs) in scheduling techniques and analyzing the relationships among various risk factors.
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 explores the author's efforts to develop a probabilistic method aimed at enhancing established software project scheduling techniques, focusing on both traditional and agile scheduling approaches.
This chapter explores the integration of Bayesian Networks (BNs) into software project scheduling methodologies to improve the prediction of project schedule success Specifically, Section 3.1 discusses the application of BNs in agile software scheduling to optimize iteration planning Furthermore, Sections 3.2 to 3.4 delve into the use of BNs for various scheduling techniques and analyze 19 prevalent risk factors in software scheduling, as identified 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 widespread adoption in the software industry, effectively reducing project risks However, optimizing software project scheduling remains a significant challenge due to the complexity and dynamism of industrial software development There is a pressing need for a probabilistic approach that accurately models and predicts uncertainties in software projects This article introduces an enhanced method and algorithm that integrates optimized agile iteration scheduling with the risk management capabilities of Bayesian Networks in resource-constrained environments A software tool has been developed based on this method to assist managers in controlling project schedules and offers a reliable set of strategies for sequencing tasks 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 prioritize adaptability throughout the development process, enabling teams to respond swiftly to changing circumstances Unlike traditional approaches that outline all planned features from the outset, adaptive teams embrace flexibility, adjusting to project changes as they arise This responsive approach allows them to effectively navigate the evolving landscape of project requirements.
Agile methods decompose deliverables into small iterations, reducing the overall risk associated with software feature realization These iterations, lasting from one to four weeks, encompass a complete software development cycle that includes planning, requirements analysis, design, coding, unit testing, and acceptance testing By demonstrating working software to users and customers at the end of each iteration, Agile minimizes risks and 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 critical to its effectiveness.
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, as highlighted by Fox & Spence and Pollack-Johnson A novel iteration scheduling method for agile software projects was introduced by Akos Szoke Additionally, Khorakadami et al proposed an enhanced approach that integrates uncertainty into project scheduling through Bayesian Networks (BNs).
Scheduling problems are a key aspect of combinatorial optimization, focusing on the efficient allocation of limited resources to various tasks over time The primary aim is to optimize multiple objectives within the decision-making process In software project scheduling, challenges arise due to the unpredictable nature of resources, including human capital, time, technology, and budget Additionally, software projects are often fraught with risks—uncertain events that can lead to negative impacts on project outcomes.
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 requiring estimated working hours Essentially, iteration scheduling seeks to create a detailed and practical plan for development, scheduling the implementation of selected features within a specific iteration.
The Optimized (Agile) iteration scheduling problem involves selecting the most extreme-valued schedule from a set of feasible alternatives This optimization challenge focuses on resource allocation by assigning specific time intervals for executing activities, known as realization tasks It must consider both temporal constraints, such as task precedence, and resource constraints, including resource availability, while aiming to minimize 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: w j - 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 = {S 0 , S 1 , … , S n+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′ ≥ P j ′ ,j illustrates the relationship between the start times of tasks j and j', where S j denotes the start time for task j, S j′ represents the start time for task j', and d j′ indicates the duration of task j' Additionally, P j ′ ,j signifies the precedence of tasks, while A encompasses the set of tasks that must be completed during the iteration.
In an Agile iteration, the set of resource capacities \( R_i \in \mathbb{N} \) is assigned to the project, with effort estimation determining 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 \) 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 all \( i \in R \).
Thus, optimization problem for iteration scheduling can be formulated as follows:
S n+1 ≤ l I with l I is the length of the iteration (3.3) a) Solving the optimization problem for iteration scheduling
In the iteration, the vector r represents the available resources, specifically developers Each w j denotes the planned effort or duration for technical tasks j, encompassing both development and defect correction The elements of vector a j reference resource indices (a j ⋲ {1 |r|}), indicating which resources are pre-assigned to task j, while a j 0 signifies that task j is not pre-assigned.
The algorithm efficiently identifies optimal resources for task execution by utilizing a precedence matrix, where P j,j′ = 1 indicates that task j precedes task j′, while P j,j′ = 0 otherwise This structure, along with the conditions P j,j = 0 (to avoid loops) and P being a directed acyclic graph (DAG), ensures that temporal constraints are satisfiable The iteration time-box, defined by variable l I, acts as an upper limit for resource allocation, preventing overload The output of the algorithm is a schedule matrix S, where rows correspond to resources and columns reflect the order of task execution; specifically, S i,p = j indicates that task j is assigned to resource i at position p Additionally, the ensure section stipulates that every task j must be assigned to exactly one resource i.
Szoke proposed an algorithm for iteration scheduling, which serves as the foundation for an enhanced algorithm that integrates Bayesian Networks (BNs) The subsequent section will delve into the incorporation of the optimization problem with BNs.
The algorithm's inputs include resources, planned task durations, task precedence, and iteration lengths, assuming tasks will be completed as scheduled given the available resources However, real projects face risks related to personnel and technology, creating uncertainties that are difficult to predict This highlights the necessity for a probability model to quantify these uncertainties and address critical concerns Bayesian Networks (BNs) are recognized as an effective probabilistic method for modeling project uncertainties and assisting project managers in decision-making Additionally, BNs can enhance Agile iteration scheduling by providing a structured approach to manage uncertainties.
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 significant challenges in creating project schedules due to the inherent uncertainty in planning Traditional project scheduling techniques often assume that projects will proceed as planned, which is rarely the case This article explores the use of Bayesian Networks (BNs) to model uncertainty and integrates them with the Critical Path Method, a widely used approach for monitoring project schedules It also identifies 19 common risk factors that impact project scheduling and presents a validated model through experimental tools.
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 outline a single task, with each activity parameter detailed in Section 1.2.2 represented as a node within the BN.
Figure 3.4 illustrates a schematic model of a partial Bayesian Network (BN) linked to a specific task, highlighting the relationships between task parameters and their connections to other tasks This model is based on the Critical Path Method (CPM) algorithm and integrates Bayesian Networks for enhanced task analysis.
Figure 3.3 A part of a BN for 19 risk factors
To establish the comprehensive CPM network, where each task serves as a node and a variable in the Bayesian Network (BN), we define the relationships among dependent variables A predecessor node, denoted as i, is linked to its successor node, j, through these defined connections.
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
A new Bayesian Network (BN) has been established, focusing on 19 common risk factors along with a general risk This analysis is grounded in a thorough literature review and insights from project managers' experiences, highlighting the interconnectedness of these risk factors.
Table 3.3 illustrates the correlation between 19 distinct risk factors and overall risk, with each factor depicted as a node that may connect to one or more parent 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), which is informed by the expertise of project teams or managers In our study, these experts contributed values to the NPTs based on 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 also 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 planned completion time of 80 days, as detailed in Table 3.4, while the second project featured 24 tasks and an expected finish in 112 days.
In Bayesian Networks (BNs), the nodes represent risks or uncertainties associated with each project task To assess the Network Probability Tables (NPTs) and the interrelationships of these risks, project managers and key stakeholders were consulted based on their project experience They supplied initial input values for the parent variables of the nodes, along with the corresponding NPTs for each variable represented.
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 initial experiment revealed a 67.56% likelihood of completing the project within the planned 80 days (Figure 3.6) However, the actual completion time extended to 95 days, while the tool estimated an 88.34% probability of timely completion.
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%, as illustrated in Figure 3.7 However, the actual completion time extended to 132 days, despite the tool indicating a probability of over 90% for timely completion.
Figure 3.6 A result for experiment with data sample 1
The model and tool demonstrate reliability through appropriate calculations for real-life projects, yet their effectiveness hinges on the Bayesian Network (BN), which includes 19 common risk factors, their interrelations, and their Non-Probabilistic Terms (NPTs) Consequently, expert and project manager feedback is essential for validating the results, a consideration that applies to all systems 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
Recent research has enhanced CPM-based scheduling by integrating Bayesian Networks (BNs), enabling software teams to analyze schedules more effectively and predict their likelihood of success while fully addressing uncertainty.
This approach enables the identification of various risk sources to analyze software project scheduling effectively It also quantifies the uncertainty in task durations and overall project timelines through comprehensive probability distributions.
Incorporation of Bayesian Networks into PERT
This section discusses the application of Bayesian Networks (BNs) in modeling and assessing uncertainty within software project scheduling, particularly using 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 Additionally, the research adapts risk categories and levels from construction projects for use in 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 outlined 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 utilizing an adapted risk categorization and levels specific to construction projects Common risk factors are also examined within this framework.
This section analyzes 19 common risk factors, as outlined in Table 2.9, that can directly or indirectly affect the likelihood of achieving schedule success, paralleling the examination conducted in Section 3.2.
To effectively model risk factors using Bayesian Networks (BNs), each risk factor is depicted as a network node, representing an event with a specific probability of occurrence These nodes can have parent and/or children nodes, illustrating their interconnections For instance, risk factor node 3 has a parent node 19 and children nodes 4, 8, and 9 A general risk factor serves as a representative measure 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 relationships among the 20 nodes, which include 19 individual risk factor nodes and one general risk node.
Each risk factor is linked to a node probability table (NPT), where project teams or managers contribute their expertise to determine values based on prior experience with project characteristics This approach is part of the proposed Risk Bayesian PERT method, which integrates expert insights to enhance risk assessment accuracy.
To create the comprehensive PERT network, where each activity represents a node and a variable in the Bayesian Network (BN), we establish the relationships between dependent variables This involves connecting predecessor node i to 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 specific risks The Bayesian PERT network illustrates the time nodes for each activity and their interrelations As discussed in Section 3.1, risk factors invariably impact each activity, necessitating their integration into the model The Bayesian PERT model demonstrates the connections between the total duration node (t(i)), the early finish (tEF) of each activity, and the early start (tES) of subsequent activities Consequently, if the total duration (t(i)) is affected by risks, it indirectly influences the tES and tEF nodes of the activities This approach significantly streamlines calculations while effectively accounting for the impact of risks on all time nodes.
A new Bayesian Network (BN) has been developed to model 19 common risk factors alongside general risk, as outlined in Section 3.1 This BN effectively illustrates the influence of various risks on each activity node, facilitating a straightforward integration of risk impacts For a visual representation of the model, refer to Figure 3.9.
The "total duration" node, as illustrated in Figure 3.9, reflects the execution time of the activity node influenced by risk factors Additionally, the "total risk" node encapsulates the entire risk model The estimated duration, denoted as t(i), represents 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 encompass five key subcategories: people, machine, materials, methods, and money In the context of software development projects, the machine category is interpreted as technological risks, while the materials category refers to support tools These factors highlight the importance of having skilled labor, necessary equipment, essential materials, effective methods, and adequate financial resources to successfully execute an activity.
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 input screen of the tool, 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 outlines the tasks involved in the software project, as illustrated in Figure 3.12 Each task is characterized by attributes such as its ID, PERT time estimates (including optimistic, most likely, and pessimistic durations), the IDs of any predecessor tasks, and an optional task name if available.
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 initiating the task, determine the parameters including the earliest start time (tES), earliest finish time (tEF), latest start time (tLS), and 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 at a major software company in Vietnam, and they published the sample data along with the source code of the RBPERT tool 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 presents the use of Bayesian Networks to effectively model risk factors in Agile software projects and manage risks related to iteration scheduling It identifies 19 common risk factors that can impact scheduling decisions Additionally, a software tool has been developed to assist managers in monitoring their project schedules by evaluating the likelihood of various scheduling scenarios.
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 enhance 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 for each resource to assess their likelihood of completing 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 method This project involved a sprint lasting 460 working hours and utilized seven resources to complete 43 tasks Among these tasks, five had specific precedence requirements: 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 begin.
Table 3.9 The result for the first data sample
Table 3.13 presents the results from the initial data sample, revealing a completion possibility of 59.85% for the assigned tasks When the sprint duration is adjusted to 450 hours, this completion possibility rises to 60%, reflecting a reliable estimation in line with the project's real conditions In a subsequent experiment involving a more complex software project in the education sector, 17 developers are tasked with completing 85 tasks over 9 Scrum sprints The first sprint comprises 54 tasks over 10 working days, while the final sprint includes 35 tasks, also over 10 working days The calculations from the BAIS tool, illustrated in Figure 3.17, provide further insights into these dynamics.
The first sprint has an overall probability of 67.12%, with only 35 out of 54 tasks completed as scheduled, resulting in a completion rate of 64.82% This reflects 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 outcomes of the second case highlight the project's complexity, characterized by numerous tasks and constraints that 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 unique context of the project and feedback from users or customers 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 timeline.
This section introduces an innovative algorithm for Agile iteration scheduling that integrates Bayesian Networks (BNs) to assist software teams in analyzing their schedules and predicting 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 while effectively minimizing 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, additional real-life data sets and case studies are essential The 19 common risk factors identified in Agile iteration scheduling should be thoroughly reviewed and refined through literature analysis and practical case studies.
This section, despite its limitations, represents a significant advancement towards a conceptual model for Agile iteration planning and scheduling The research offers valuable insights into resource-constrained project scheduling issues, potentially leading to the identification of a new optimization problem in Agile iteration scheduling.
The BAIS tool can be enhanced to include Bayesian Networks (BNs) for effectively representing and analyzing causal models that involve uncertainty This upgraded 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 across various software projects.
Chapter remarks
This chapter focuses on enhancing software project scheduling by integrating scheduling techniques with common risks It proposes an improved scheduling method that combines Bayesian Networks (BNs) with risk factors, utilizing PERT, CPM, and Agile methodologies Experimental results indicate that the proposed model effectively manages 19 common risk factors, demonstrating strong performance with both CPM and PERT under high uncertainty conditions This achievement fulfills 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 By utilizing a probabilistic approach through Bayesian Networks, the models support software project managers in effectively tracking their schedules The research applies to both traditional waterfall and agile software development methodologies, enhancing the understanding of risk management in diverse project environments.
- Validating proposed models by building tools and carrying out experiments with data from the real world
The thesis has successfully met its two main objectives, with findings disseminated through six published conference and journal papers, as detailed in the List of Scientific Publications section.
The study introduces the BRI (Bayes Risk-Impact) algorithm and 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 new scheduling approaches, and experimental findings demonstrate their reliability and practical benefits for software development teams in risk analysis, monitoring, and predicting project success.
The thesis focuses on addressing various aspects of software project development and the associated risk factors to enhance risk management strategies.
The thesis addresses the challenge of inconsistent data sets across different software project scheduling experiments, as each piece utilizes a unique data set Despite efforts to obtain real-time software project data from reputable Vietnamese companies, these approaches have not been integrated into ongoing projects Consequently, all experiments were conducted using completed projects, relying on insights and evaluations from project personnel, particularly project managers.
The thesis faces limitations due to the lack of empirical evaluation criteria, as there is insufficient data from real software projects to serve as a foundation for assessment Currently, the evaluation of experimental results relies on information provided by the 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 algorithm By utilizing probabilistic approaches, it aims to improve current methods in the field.
The experimental results demonstrate that the proposed approach serves as a valuable decision support tool for software scheduling and planning To validate these findings, it is essential to gather more representative real-life data sets and conduct case studies on ongoing software projects The author plans to develop consistent data sets for both traditional and agile software project development, which could also benefit the research community.
Further 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 to improve its accuracy and relevance.
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 paper spans pages 300-308 and is published under 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 bài viết “Hướng tới mô hình mạng Bayes để đánh giá rủi ro trong lập lịch dự án phần mềm” tại 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) diễn ra tại Đà Nẵng vào ngày 17-18 tháng 8 năm 2017, trang 275-282, ISBN: 978-604-913-614-6 Bài viết tập trung vào việc áp dụng mô hình mạng Bayes để cải thiện quy trình đánh giá rủi ro trong lập lịch dự án phần mềm, góp phần nâng cao hiệu quả quản lý dự án.
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 sử dụng mạng Bayes để đánh giá rủi ro trong lập lịch dự án phần mềm là một nghiên cứu quan trọng Bài viết được đăng trong Chuyên san Công nghệ thông tin và Truyền thông, Tạp chí Khoa học và Kỹ thuật của Học viện KTQS, số 184 vào tháng 6 năm 2017, trang 45-61 Nghiên cứu này cung cấp cái nhìn sâu sắc về cách áp dụng mạng Bayes trong việc quản lý rủi ro, góp phần nâng cao hiệu quả lập lịch dự án phần mềm.
In their 2018 paper, "Risk Management in Agile Software Project Iteration Scheduling Using Bayesian Networks," Nguyen Ngoc Tuan and Huynh Quyet Thang explore innovative methodologies for managing risks in agile software development Published in the journal New Trends in Intelligent Software Methodologies, Tools and Techniques, this work is featured in Volume 303, pages 596-606, and is indexed in SCOPUS The authors utilize Bayesian Networks to enhance the scheduling of project iterations, providing valuable insights for improving risk management strategies in agile environments The paper is accessible through DOI: 10.3233/978-1-61499-900-3-596.
PUB5: Ngoc-Tuan Nguyen, Quyet-Thang Huynh, Thi-Huong-Giang Vu (2018), “A
Bayesian Critical Path Method for Managing Common Risks in Software Project Scheduling”, SoICT 2018 Proceedings of the 9 th International Symposium on Information and Communication Technology, Danang City, Viet Nam - December
PUB6: Quyet-Thang Huynh, Ngoc-Tuan Nguyen (2020), “Probabilistic Method for
Managing Common Risks in Software Project Scheduling Based on Program Evaluation Review Technique”, International Journal of Information Technology
Project Management, Volume 11(3), pp 77-94, ISSN: 1938-0232, DOI: 10.4018/IJITPM.2020070105
[1] VnExpress (2019), “Ministry of Transport admits the mistakes on the Cat Linh-
Ha Dong urban railway project”, available online since 27 September 2019
[2] Vietnamese Prime Minister (2015), “Decision regarding the approval of investment policy for the project on the National population database”,
Government of Vietnam, 2083/QĐ-TTg (26 November 2015)
[3] Vietnamese Prime Minister (2015), “Resolutions on e-Government”,
Government of Vietnam, 36a/NQ-CP (14 October 2015)
[4] Wikipedia.org (2019), “List of failed and over-budget custom software projects”, Retrieved 20 September 2019, available online
[5] Moore T (2018),“Worst failure of public administration in this nation: payroll system”, The Sydney Morning Herald, Retrieved 24 July 2018, available online.
[6] Glick B (2014), “Government finally scraps e-Borders programme”,
ComputerWeekly.com, Retrieved 24 July 2018, available online.
[7] Boehm B.W (1991), “Software Risk Management: Principles and Practices”,
[8] Dedolph M (2003), “The Neglected Management Activity: Software Risk Management”, Bell Labs Technical Journal, 8(3), pp 91–95
[9] Hui A.K.T and Liu D.B (2004), “A Bayesian Belief Network model and tool to evaluate risk and impact in software development projects”, Reliability and
Maintainability, 2004 Annual Symposium – RAMS, pp 297-301
[10] Karollay G O V., Carlos E S S., Sandra M N (2020), “Risk Management in
Software Development Projects: Systematic Review of the State of the Art Literature”, International Journal of Open Source Software and Processes (IJOSSP)
[11] PMI (2017), “A Guide to the Project Management Body of Knowledge (PMBOK Guide)”, 6 th Edition, Project Management Institute
[12] Rao B.H., Gandhy A & Rathod R.R (2013) “A Brief View of Project Scheduling Techniques”, International Journal of Engineering Research &
[13] Jun-yan J (2012), “Schedule Uncertainty Control: A Literature review”,
[14] Kaur R et al (2013), “A review of various software project scheduling techniques”, International Journal of Computer Science & Engineering Technology,
[15] Williams T (1995), “A Classified Bibliography of Recent Research Relating to
Project Risk Management”, European Journal of Operational Resarch, 85(1), pp 18-38
[16] Malcolm et al (1959), “Application of a Technique for Research and Development Program Evaluation”, Operations Research, 7(5), pp 646-669
[17] Miller R.W (1962), “How to plan and control with PERT”, Harvard Business Review, pp 93-104
[18] Ward S and Chapman C (2003), “Transforming project risk management into project uncertainty management”, International Journal of Project Management, 21, pp 97-105
[19] Khodakarami V (2009), “Applying Bayesian Networks to model uncertainty in project scheduling”, PhD dissertation, Queen Mary, University of London
[20] Ali N., Siamak H Y., Vahidreza Y and Jolanta T (2019), “Combining Monte
Carlo Simulation and Bayesian Networks Methods for Assessing Completion Time of Projects under Risk”, International Journal of Environmental Research and
[21] Lee, Y P and Shin J G (2009), “Large Engineering Project Risk Management Using a Bayesian Belief Network”, Expert Systems with Applications, vol 36(3), pp 5880–5887
[22] Sharma S.K and Chanda U (2017), “Developing a Bayesian Belief Network model for prediction of R&D project success”, Journal of Management Analytics, vol 4 (2), pp.1-24
[23] Khodakarami V., Fenton N and Neil M (2007), “Project Scheduling: Improved Approach to Incoporate Uncertainty using Bayesian Networks”, Project
[24] Kumar, C & Yadav, D.K (2015), “A Probabilistic Software Risk Assessment and Estimation Model for Software Projects”, Procedia Computer Science, 54, pp
[25] Fenton N.E and Neil M (2014), “Decision support software for probabilistic risk assessment using Bayesian Networks”, IEEE Software, 31(2), pp 21-26
[26] Chang H.K, Yu W.D and Cheng S.T (2017), “A Risk-based Critical Path Scheduling Method (I): Model and Prototype Application System”, Proceedings of
34 th International Symposium on Automation and Robotics in Construction ISARC
[27] Hu Y et al (2013), “Software Project Risk Analysis Using Bayesian Networks with Causality Constraints”, Decision Support Systems, vol 56, pp 439–449
[28] Anthony B.J et al (2016), “A Proposed Risk Assessment Model for Decision
Making in Software Management”, Journal of Soft Computing and Decision
[29] Rai A K., Agrawal S and Khaliq M (2017), “Identification of Agile Software
Risk Indicators and Evaluation of Agile Software Development Project Risk Occurrence Probability”, Proceedings of 7th International Conference on
Engineering Technology, Science and Management Innovation (ICETSMI-2017), pp 489-494
[30] Szoke A (2014), “Models and Algorithms for Integrated Agile Software Planning and Scheduling”, PhD Dissertation
[31] Wallace L., Keil M and Rai A (2004), “How software project risk affects project performance: an investigation of the dimensions of risk and an exploratory model”, Decision Sciences, 35(2), pp 289-321
[32] J Menezes Jr., Gusmao C and Moura H (2013), “Defining Indicators for Risk
Assessment in Software Development Projects”, CLEI Electronic Journal, 16(1)
[33] Sadiq M and Shahid M (2013), “A Systematic Approach for the Estimation of
Software Risk and Cost using EsrcTool”, CSIT, vol 1(3): 243–252
[34] Kumar C and Yadav D K (2015), “A Bayesian Approach of Software Risk Assessment”, International Journal of Applied Engineering Research (IJAER), 10, pp 2366-2371
[35] Yong J & Zhigang Z (2011), “The Project Schedule Management Model Based on the Program Evaluation and Review Technique and Bayesian Network”,
Proceedings of the IEEE International Conference on Automation and Logistics, Chongqing, China, pp 379-383
[36] Wikipedia.org (2019), “Software Project Management”, Retrieved 3 September 2019, available online
[37] Wrike blog (2019), “What Is Software Project Management?”, Retrieved 3
[38] PCWorld Vietnam (2009), “Risk management in software projects”, Retrieved
[39] Kelley J.E (1961), “Critical Path Planning and Scheduling: Mathematical Basis”, Operations Research 9, pp 290-320
[40] Moder J (1988), “Network Techniques in Project Management”, Project Management Handbook, New York, Van Nostrand Reinhold
[41] Fortune J and White D (2006), "Framing of Project Critical Success Factors by a Systems Model", International Journal of Project Management, 24(1), pp 53-
[42] Fenton N and Neil M (2013), “Risk Assessment and Decision Analysis with
Bayesian Networks”, Reading book, CRC Press
[43] Pollack-Johnson B and Liberatore M.J (2005), “Project Planning under Uncertainty Using Scenario Analysis”, Project Management Journal, 36(1), pp 15-
[44] Van Slyke R.M (1963), “Monte Carlo Methods and the Pert Problem”,
[45] Fishman G.S (1986) A Monte Carlo Sampling Plan for Estimating Network Reliability Operations Research, 34(4), pp 581-594
[46] Ragsdale C (1989), “The current state of network simulation in project management theory and practice”, Omaga, 17(1), pp 21-25
[47] Oracle (2018), “Oracle Primavery Risk Analysis (Pertmaster®)”, Emerald Associates, available online
[48] PMI (1999), “Project Management Software Survey”, Newtown Square, PA: Project Management Institute
[49] Pollack-Johnson B and Liberatore M.J (2003), "Analytical Techniques in Project Planning and Control: Current Practice and Future Research Directions",
[50] Van Dorp J R., Duffey M R (1999), “Modelling statistical dependence in risk analysis for project networks”, International Journal of Production Economics,
[51] Williams T (2004), “Why Monte Carlo Simulations of Project Networks Can Mislead”, Project Management Journal, 35(3), pp 53-61
[52] Liberatore M.J (2002), “Project Schedule Uncertainty Analysis Using Fuzzy Logic”, Project Management Journal, 33(4), pp 15-22
[53] Kuchta D (2001), “Use of Fuzzy Numbers in Project Risk Assessment”,
International Journal of Project Management, 19(5), pp 305-310
[54] Bonnal P et al (2004), “Where do we stand with Fuzzy project scheduling?”, Journal of Construction Engineering & Management, 130(1), pp 114-123
[55] Abrahamsson P et al (2002), “Agile Software Development methods: Review and Analysis”, VTT Publications 478, pp 3-107
[56] Stalhane T and Hanssen G K (2008), “The application of ISO 9001 to Agile
[57] Schwaber K (1995), “The Scrum development process”, In OOPSLA ’95
Workshop on Business Object Design and Implementation, Austin, Texas, USA, October 1995 ACM Press
[58] Huo M., Verner J., Zhu L., Babar M.A (2004), “Software quality and Agile methods”, Proceedings of COMPSAC’04, pp 520-525
[59] Wailgum T (2007), “From Here to Agility”, CIO.com, Retrieved June 2018, available online
[60] Glazer H., Dalton J., Anderson D., Konrad M., Shrum S (2008), “CMMI or Agile: Why not embrace both!”, Technical Note CMU/SEI-2008-TN-003, Software
Engineering Institute, Carnegie Mellon University
[61] Cohn M (2005), “Agile Estimating and Planning”, NJ, USA: Prentice Hall
[62] PRAM (2004), “Project Risk Analysis and Management Guide”, High Wycomb, Association for Project Management (APM)
[63] RAMP (2005), “Risk Analysis and Management for Projects”, London Institute of Civil Engineering and the Faculty and Institute of Actuaries, Thomas Telford
[64] Chapman C (2006), “Key Point of Contention in Framing Assumptions for Risk and Uncertainty Management”, International Journal of Project Management,
[65] Barry, J B (1995), “Assessing Risk Systematically”, Risk Management, 42, pp 12-15
[66] Williams T M (1994), “Using a Risk Register to Integrate Risk Management in Project Definition”, International Journal of Project Management, 12(1), pp 17-
[67] Ward S.C (1999), “Assessing and Managing Important Risks”, International
Journal of Project Management, 17(6), pp 331-336
[68] Patterson F.D and Neailey K (2002), “A Risk Register Database System to Aid the Management of Project Risk”, International Journal of Project Management,
[69] Hillson D (1999), “Developing Effective Risk Responses”, Proceedings of the
30 th Annual Project Management Institute Seminars and Symposium, Philadelphia USA
[70] Al-Bahar J and Crandall K.C (1990), “Systematic Risk Management Approach for Construction Projects”, Journal of Construction Engineering and
[71] UK Ministry of Defence(1991), “Risk Management in Defence Procurement”, Ministry of Defence, Whitehall, London
[72] del Caano A and de la Cruz M.P (2002), “Integrated Methodology for Project
Risk Management”, Journal of Construction Engineering and Management, 128(6), pp 473-485
[73] Wideman R.M (1992), “Project and Program Risk Management”, Newtown Square, PA, USA, Project Management Institute
[74] BSI (1999), “Guide to Project Management”, London, British Standard
[75] Rosenberg L.H et al (1999), “Continuous Risk Management at NASA”,
[76] Defense Systems Management College (2000), “Risk Management Guide for
Dod Acquisition”, USA, Department of Defense
[77] US Department of Transportation (2000), “Project Management in the Department of Transportation”
[78] Baber R.B (2005), “Understanding Internally Generated Risks in Projects”,
International Journal of Project Management, 23(8): 584-590.
[79] Goldstein M (2006), “Subjective Bayesian analysis: Principle and practice”, Bayesian Analysis, 1(3), pp 403-420
[80] Joshua H., Martin N., Norman E F (2020), “Product risk assessment: a Bayesian network approach”, Proceedings of the 2020 ACM Southeast Conference,
[81] McCabe B (1998), “Belief Networks in Construction Simulation”,
Proceedings of the 30 th Conference on Winter simulation, IEEE Computer Society Press
[82] Nasir D., McCabe B et al (2003), "Evaluating Risk in Construction-Schedule
Model (Eric-S): Construction Schedule Risk Model", Journal of Construction
[83] Houston D (2000), “Survey on potential effects of major development risk factors”, Arizona State University Research Project
[84] Cortellessa V et al (2005), “Model-Based Performance Risk Analysis”, IEEE Transactions on Software Engineering, 31(1): 3–20
[85] Islam S (2012), “Software Development Risk Management Model - A Goal- Driven Approach”, Technical Report
[86] Alberts C.J and Dorofee A.J (2010), “Risk management framework”, SEI
[87] NASA Policy Detective (2005), NPD 2820.1A NASA Software Policies
[88] PSPLIB http://www.om-db.wi.tum.de/psplib/
[89] HuginExpert http://www.hugin.com/
[90] CKDY tool and data samples: http://bit.ly/2r4MsWb
[91] IEEE Computer Society (2001), “IEEE Standard for Software Life Cycle Processes - Risk Management”
[92] RESCON http://feb.kuleuven.be/rescon/
[93] MSBNx https://msbnx.azurewebsites.net/
[94] Tore D and Torgeir D (2008), “Empirical studies of agile software development: A systematic review”, Information and Software Technology 50.9-10, pp 833–859
[95] Augustine S (2005), “Managing Agile Projects”, Upper Saddle River, NJ,
[96] Tsun Chow and Dac-Buu Cao (2008), “A survey study of critical success factors in agile software projects”, Journal of System and Software 81(6), pp 961–
[97] Schwaber K and Beedle M (2001), “Agile Software Development with Scrum”
[98] Martin R.C (2002), “Agile Software Development, Principles, Patterns and Practices”
[99] Miller A (2008), “Distributed Agile Development at Microsoft patterns and practices”
[100] Agile Alliance, “Manifesto for agile software development”, [Online]
Retrieved 14 May 2017 Available at: http://agilemanifesto.org
[101] Nguyen N.T and Huynh Q.T (2013), “Combining Maturity and Agility –
Lessons Learnt From A Case Study”, Proceedings of the 4 th International Symposium on ICT SoICT 2013, pp 267-274
[102] VersionOne, 7th Annual Survey (2013), “The State of Agile Development”, Full Data Report
[103] Fox T L and Spence J W (1998), “Tools of the trade: a survey of project management tools”, Project Management Journal, 29, pp 20-28
[104] Pollack-Johnson B (1998), “Project management software usage patterns and suggested research directions for future development”, Project Management
[105] RBPERT (2019) The RBPERT source code and sample data Available at https://github.com/tuanmasu/RBPERT/