Simulating the Software Development Lifecycle: The Waterfall Model

: This study employs a simulation-based approach, adapting the waterfall model, to provide estimates for software project and individual phase completion times. Additionally, it pin-points potential efficiency issues stemming from suboptimal resource levels. We implement our software development lifecycle simulation using SimPy, a Python discrete-event simulation framework. Our model is executed within the context of a software house on 100 projects of varying sizes examining two scenarios. The first, provides insight based on an initial set of resources, which reveals the presence of resource bottlenecks, particularly a shortage of programmers for the implementation phase. The second scenario uses a level of resources that would achieve zero-wait time, identified using a stepwise algorithm. The findings illustrate the advantage of using simulation as a safe and effective way to experiment and plan for software development projects. Such simulations allow those managing software development projects to make accurate, evidence-based projections as to phase and project completion times as well as explore the interplay with resources.


Introduction
Despite decades of study and advancements in processes and procedures, software development remains a fraught and challenging process plagued by cost overruns, missed deadlines, abandonment of final products, and outright failure.Research shows a significant probability of failure [1,2]: Bloch et al. [3] share from "a study of 5400 large IT projects exceeding $15 million found that, on average, large IT projects run 45% over budget and 7% behind schedule while delivering 56% less value than initially planned".As Wu et al. [4] pointed out, information technology (IT) projects are inherently high-risk endeavorsa sentiment echoed since the early 1980s.Charette [5] reiterates this dismal reality when remarking that "few IT projects, in other words, truly succeed", writing that "of the IT projects that are initiated, from 5 to 15 percent will be abandoned before or shortly after delivery".The author characterizes this, "as hopelessly inadequate" [5].Certainly, the reputation of the practice of software development has suffered from its inability to guarantee success.Whilst Kellner et al. [6] point out that "over the past few decades the software industry has been assailed by numerous accounts of schedule and cost overruns as well as poor product quality delivered by software development organizations in both the commercial and government sectors".
Data on the magnitude of the challenges and failures with respect to software development are traditionally sought from the Standish Group's Chaos Report.DeFranco and Vaos [7] have indicated that the Standish group has been gathering data about project outcomes (i.e., the successful or failure completion of projects) since 1994 through their CHAOS reports.Morawiec et al. [8] provide specifics from these reports, showing that in 2015, 29% of projects were successful, and 19% failed [9].By 2020, the success rate had increased slightly to 31%, while the failure rate remained at 19% [10].In other words, almost one in five IT projects will fail.However, we can find hope in the words of Charette [5], who writes that "the biggest tragedy is that software failure is for the most part predictable and avoidable".
To enhance the chances of success one could implement a software development life cycle (SDLC).This can be thought of as a recipe "for designing, building, and maintaining information" [11] systems by prescribing steps "that are essential for developers, such as planning, analysis, design, and implementation" [12].The innovation emerged in the 1960's after "the failure of several high-profile software projects" [13].To support the use of a software development lifecycle such as the waterfall model, management can rely on simulations of software process models to support decision-making and minimize the risk of failure, as proposed by Kellner et al. [6].The drive here is that "we use models in an attempt to gain understanding and insights about some aspect of the real world" [14].Certainly, the use of simulations to better understand a current scenario as well as competing ways one can work with the lifecycle is further supported by Pinho et al. [15] who stress that efficient business management depends in part on the ability to evaluate such competing scenarios.Furthermore, simulation can also be regarded as an effective way of gleaning valuable insights "when the costs, risks or logistics of manipulating the real system of interest are prohibitive" [6].Vasilecas et al. [16] note that the allocation of resources is a particular area where one can frequently encounter challenges.

Our Contribution and the Remainder of this Paper
There have been several attempts to simulate software process models (e.g., [17][18][19][20]) which include waterfall (the most cited to our knowledge being Bassil's [18], which we will attempt to align with in how we structure our simulation for uniformity).Our contribution is to demonstrate how an open-source programming language such as Python coupled with the SimPy framework [21] can be used to simulate the waterfall model in order to ascertain the optimal number of resources to minimize the possibility of bottlenecks and idle resources, the implications being that it can be more easily used in industry and education to offer valuable insight that could be used by those managing, or learning to manage, software development projects.
The remainder of this paper unfolds as follows: Section 2 delves into the background of the waterfall software development lifecycle and our motivation for its study.In Section 3, we outline the development of the proposed simulation model and the respective Python code, detailing the assumptions regarding resources and failure rates.Section 4 presents the results following sample executions of the simulation, demonstrating how it can be used to identify optimal resources in order to avoid underutilization of resources or bottlenecks.The findings from this exercise are discussed in Section 5. Finally, Section 6 concludes the paper by outlining how this work could be applied as well as the limitations which concurrently offer directions for how this work could be advanced.

Background
In this section we provide an overview of the relevant literature introducing the innovation of software development processes and the idea of a lifecycle.We then present the waterfall model, which is perceived as the first software development lifecycle, as well as our motivation for its study.

The Software Development Lifecycle
The SDLC "is also called [the] software development process model" [22], with Sarker et al. [23] equating the two terms.The term 'software development life cycle' similarly appears in the literature to be used at times interchangeably with the 'systems development life cycle'.Ruparelia [24] rationalizes this equation by pointing out that "systems development lifecycle models have drawn heavily on software and so the two terms can be used interchangeably in terms of SDLC".However, in reality, "a software development life cycle", can frequently be, "considered as a subset of [the] system development life cycle" [23].
Öztürk [25] reviews several definitions for the term SDLC and distills them to offer his own, which we will use as the basis for this work, specifically, to be "a model that defines the sequence of phases and activities that will/should take place during the software development".The SDLC "covers all stages of software from its inception with requirements definition through to fielding and maintenance".Over time a number of SDLCs have emerged "which have their own advantages/disadvantages and strengths/weakness" [25].The inception of the first such model is traced by Dawson and Dawson [26] to the pioneering work of Benington [27] who also herald its importance, writing, "since the first software process model was introduced by Benington in 1956, software engineers have continued to recognize that processes are the bedrock on which all software developments succeed".
While SLDCs are not new, they are still evolving along with advances in computing and software engineering.Existing models are being extended to include specific ex-tensions for secure software development [28], green computing [29] that considers the material and environmental impact of software systems, and impact of machine learning/deep learning both as it provides insight into the development process, and presents unique challenges to the SLDC of machine learning systems [30] where requirements are emergent from analysis of data rather than gathered from stakeholders.

The Waterfall Model
Rastogi [31] presents what is colloquially known as "the waterfall model" as "the classical model of software engineering", going on to characterize it as "one of the oldest models" [23].Balaji and Murugaiyan [12] also support this characterization of the waterfall model as "the oldest of these, and the best known".Sommerville [13] describes it as "the initial life-cycle model", "now termed the waterfall model".We should point out that the model is based on and expands on the work of Benington (which was introduced earlier).
Dennis et al. [32] classify this model under the category of "structured design" and note that this category replaced "the previous ad hoc and undisciplined approach" that was being used to develop software.Weisert [33] shares that he "can't find a rigorous definition" for the original waterfall model.Also known as the cascade model [24], the waterfall model is described as "a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases" [34].As Sommerville [13] describes it, the "model consists of a set of phases, starting with system specification, with results cascading from one stage to another".
Thus, "the waterfall metaphor was suggested by the inability of water to flow uphill" [33].The phases run individually one at a time and "all process phases (planning, design, development, testing and deployment) are performed in a sequential series of steps" [19] where the "output of each stage becomes the input for the next" [12].Cocco et al. [19] elucidate that "each phase starts only when the previous one has ended".He then goes on to add that "it is possible to step back to the previous phase, but it is not possible to go back in the process, for instance to accommodate a substantial change of requirements" [19].
There is a bit of debate as to the origins of the label 'waterfall' to describe a life cycle approach, with the first use "often attributed either to Barry Boehm or to critics of his COCOMO estimating technique" [33].However, Petersen et al. [35] point out that, traditionally, it is credited to the work of Winston Royce [36].Indeed, colloquially the development of what is referred to as the waterfall model is attributed to his article entitled "Managing the Development of Large Software Systems", which introduced the model in Figure 3 of that paper, although the word waterfall does not explicitly appear in his text.The earliest use of 'waterfall' to define Royce's [36] model that we could identify was in the work of Bell and Thayer [37] when writing "he [Royce] introduced the concept of the "waterfall" of development activities".In Royce's [36] original work the model is presented as having seven phases: "Systems Requirements", "Software Requirements", "Analysis", "Program Design", "Coding", "Testing", and "Operations".However, many adaptations can be found in the literature (for example, in Petersen et al. [35] and Paul et al. [38]).The waterfall model has received considerable criticism regarding its suitability for development.Weisert [33] points out that "the key attribute of the so-called "waterfall approach" seems to be extreme inflexibility", explaining that "once you've completed a phase, its results are frozen.You can't go back and revise anything based on changing needs or fresh insights".The author reiterates by writing, "until the results of the current phase are complete and approved, you may not start on any work that properly belongs to the next phase or any later phase" [33].

Motivation to Study the Waterfall Model
Despite other models, such as the iterative, incremental, and agile models growing in popularity, we must recognize that the waterfall model's continued relevance, and consequently, its continues need for study.Humphrey and Kellner point out that [39] "outside the research community, much software process thinking is still based on the waterfall framework".This view is echoed by Petersen et al. [35] who write that, "waterfall development is still a widely used way of working in software development companies".A study by Andrei et al. [40] in 2019 looked at usage of agile versus waterfall approaches, finding that 28.1% of software developers had reported that they used waterfall.Fagarasan et al. [41] reinforce this when they write that "although the Agile methodology started to become the standard methodology in software projects implementation, several organisations are currently employing Waterfall methodology because it simply works, and it has a proven track record".Further, although waterfall exists in hybrid forms and one of many SDLCs, because of its clear stages and easy to grasp model, it remains foundational for computing education as novice developers learn more about the software development process.
Moreover, some have questioned whether we have taken the new agile approaches too far [42], implying that there may still be some value in waterfall.This type of thinking has led to an emerging practice of taking the best of waterfall and agile approaches resulting in hybrid models.Kirpitsas and Pachidis [43] share the motivation for this drive to merge approaches, explaining that "the rise of hybrid software development methods", which "combined elements from both the waterfall and agile methodologies" do so "to increase efficiency throughout the software development lifecycle".For example, Bhavsar et al. [44] propose a hybrid framework integrating Kanban and Scrum approaches with waterfall.Another example can be seen in the work of Fagarasan et al. [41] who similarly propose a hybrid methodology that combines the best from both Agile and waterfall.Thus, the study of waterfall is appropriate.
The waterfall model may be best known for its weaknesses.Royce received considerable criticism for the model, however, it is important to recognize that he understood (perhaps only in part) the weakness of his model.He himself pointed out the problems writing "I believe in this concept, but the implementation described above is risky and invites failure" [36].Bassil [18] emphasizes that the "SDLC of software systems has always encountered problems and limitations that resulted in significant budget overruns, late or suspended deliveries, and dissatisfied clients".He goes on to explain that "the major reason for these deficiencies is that project directors are not wisely assigning the required number of workers and resources on the various activities of the SDLC".As a result, "SDLC phases with insufficient resources may be delayed; while, others with excess resources may be idled, leading to a bottleneck between the arrival and delivery of projects and to a failure in delivering an operational product on time and within budget" [18].It is these problems that we seek to address using simulation.

Materials and Methods
Software process simulation and visualization is critical for helping us understand the risks and indicators of failure in software projects.Zhang et al. [45] go on to trace its origins back to "the 1980s".Ruiz et al. [46] offer us a definition for "a simulation model", describing it as "a computational model that represents an abstraction or a simplified representation of a complex dynamic system".This follows the words of Acuna et al. [47], who tell us that at the end of the day, "a software process model is an abstract representation of the architecture, design or definition of the software process" [47], where a process is defined, according to Kellner et al. [6], as "a logical structure of people, technology and practices that are organized into work activities designed to transform information, materials and energy into specified end result(s)" [48].There are several adaptations of Royce's [36] original waterfall model.For our study, we will simulate the waterfall software development lifecycle using the model proposed by Bassil [18].An illustration of our adaptation of the waterfall model can be seen illustrated in Figure 1.It is comprised of five phases: analysis, design, implementation, testing, and maintenance, which are executed in sequence.The steps in the simulation can be seen in Figure 2.Although the titles of the phases are, for the most part, self-explanatory, their respective definitions can be seen in Table 1.

Phase Definition
Analysis Phase "Often known as Software Requirements Specification (SRS) is a complete and comprehensive description of the behavior of the software to be developed.It implicates system and business analysts to define both functional and non-functional requirements."Design Phase "It is the process of planning and problem solving for a software solution." Implementation Phase "It refers to the realization of business requirements and design specifications into a concrete executable program, database, website, or software component through programming and deployment." Testing Phase "It is also known as verification and validation which is a process for checking that a software solution meets the original requirements and specifications and that it accomplishes its intended purpose." Maintenance Phase "It is the process of modifying a software solution after delivery and deployment to refine output, correct errors, and improve performance and quality." Note: Phase definitions as stated by Bassil [18].Three main techniques are used in the simulation domain: discrete event simulation, agent-based simulation, and system dynamics.Robinson [49] perceives discrete-event simulation to be "one of the most popular modelling techniques".Cubukcuoglu et al. [50] describe discrete event simulation as "a method that mimics the operations of real and/or proposed systems as an ordered series of events".Schriber et al. write that "a discrete-event simulation is one in which the state of a model changes at only a discrete, but possibly random, set of simulated time points" [51].It is this form that we shall rely on for this work, looking to Python and the SimPy framework as the technologies to help us implement it.SimPy is "a Python framework for developing event-based models for asynchronous processes" [15].

Assumptions
Ruiz et al. [52] tell us that "a simulation model is a computational model that represents an abstraction or a simplified representation of a complex dynamic system".For this work we rely on the assumptions for our simulation are based on those originally proposed by Bassil [18].Specifically, the available resources for our software house are outlined in Table 1; the required human resources by size of project are presented in Table 2; the duration of phases in days are outlined in Table 3; and the probabilities of an error occurring are presented in Table 4.Note the supposition of clear requirements which is implicit with the use of the waterfall model.Values are as proposed by Bassil [18].Values are as proposed by Bassil [18].Values are as proposed by Bassil [18].Values are as proposed by Bassil [18].
We introduce the projects using "a triangular distribution with a lower limit of 30 days, an upper limit of 40 days, and a mode of 35 days", with there being a 70% chance of it being a small-scale project, a 25% chance of it being a medium-scale project, and a 5% chance of it being a large-scale project, following the rules presented by Bassil [18].It should be noted that the software that was developed for this experiment allows for these values to be changed according to the specific needs of the user.

Convergence
For a single configuration of the simulation to be able to generate a result the simulation needs to be run multiple times to identify a stable solution.Seri and Secchi [53] do provide some guidance on the topic (though the work focuses on agent-based social simulations).The authors [53] write that "the number of runs in a simulation is often critical for results to bear some meaning".They do caveat this by noting that "of course, this is not true for all simulations and it depends on scope, nature of the simulated phenomenon, purpose, and level of abstraction" [53].
The sensitivity resides with those simulations that have "a strong stochastic component, where emergence and complexity cause results to differ even within the same configuration of parameters".Ritter [54] "suggests that researchers should run their model until it makes stable predictions".Moreover, Schriber and Brunner [51] write that "each experiment consists of one or more replications (trials).A replication is a simulation that uses the experiment's model logic and data but a different set of random numbers, and so produces different statistical results that can then be analyzed across a set of replications".
To identify convergence, we employ an algorithm that monitors the rate of change in mean completion times between consecutive iterations of the different phases: requirements analysis, design, implementation, testing, and maintenance.Specifically, it calculates the mean completion time for each phase in each iteration, subsequently comparing the current means with the previous means and calculating the rate of change for each mean.If the rate of change falls below a predefined threshold for all means, a counter is implemented to keep track of the number of consecutive iterations without improvement.If the number of consecutive non-improvements exceeds or equals a specified threshold, the algorithm concludes that convergence has been achieved.

Optimization
Following convergence, it is also necessary to identify an optimal configuration of resources for our simulation.For guidance on this approach, we look to Riley [55] who provides an overview of existing techniques to achieve discrete-event simulation optimization.The most basic is what is known as "intuitive methods" [55].Through these "the user selects input parameters and undertakes an iterative process that involves: 1) varying the parameter levels; 2) completing a statically valid number of simulation replications and runs, and; 3) altering the input parameters and reevaluating the results" [55].They conclude by noting that "the objective of this method is to find increasingly better solutions" [55].This is also the approach that we find prescribed in other papers that have attempted to simulate a software development lifecycle (e.g., Bassil [18]).
A strategy that is more systematic in nature is what Riley refers to as "pattern search" [55] (referencing the work of Findler et al. [56]), wherein the "search moves in [the] direction of increasing improvement of the objective function by 'steps.' Step sizes vary depending on the sensitivity to change in the objective function until a user-defined convergence test or tolerance is satisfied" [55].It is this latter approach (i.e., pattern search) that we will apply to identify the optimal allocation of every resource (i.e., analysts, designers, programmers, testers, and maintenance people) during each corresponding phase of the lifecycle (i.e., requirements analysis, design, implementation, testing, or maintenance).The algorithm will attempt to optimize each resource and associated phase in the order in which they occur in our adaptation of the waterfall model.A minimum and maximum allocation for each resource, as well as the initial step size for the iterative process is provided.
The function works by continually adjusting the number of a certain resource allocated to a phase systematically, trying to minimize the mean wait time of that phase.The function achieves this by using an iterative approach that incrementally modifies the resource allocation until no further improvement can be found.Specifically, it first initializes some variables and gets the mean wait time for the current phase of the project.Then, it enters a loop where it continually adjusts the value of the resource and checks if this adjustment leads to an improvement in the mean wait time.If it doesn't find an improvement, the system reverts to the previous allocation and increments a counter.If it finds an improvement, it updates the mean wait time and resets the counter.If it can't find an improvement in either direction, it reduces the step size and continues the process.

Results
In this section we go over the results obtained from simulating our adaptation of the waterfall model.We executed the simulation in three stages: 1) pre-optimization; 2) optimization; and 3) post-optimization.During all executions, we simulated a scenario where 100 projects were started, each of varying size (i.e., small, medium, and large), using the respective probabilities presented in Section 2 and following a triangular distribution that ranged between 30 units of time (lower limit) and 40 units of time (upper limit), and reflected a mode of 35 units of time.The mean number of projects that were initiated by size can be seen in Figure 2. All initiated projects (i.e., 100) were subsequently completed successfully.The first stage served the purpose of running the simulation to investigate the initial settings, which would either mirror the current state of resources in the organization or reflect an estimation of what those initial settings should be.As mentioned in the previous section the simulation was iterated until convergence of the outputs was achieved to ensure that the results reflected a stable prediction.For the pre-optimization stage it took 10 iterations for the rate of change threshold of 0.01 and the convergence streak threshold of 3 to be satisfied.Table 6 displays the actual mean values.Figure 3 visualizes the means duration times that are generated for each phase by iteration until convergence is established.
With respect to the requirements phase, the average duration of the requirements phase remains relatively stable throughout the iterations, ranging from 3.872 to 4.107 units of time.Similarly, we see the average duration of the design phase also remains quite consistent, ranging from 7.398 to 8.005 units of time.The implementation phase has the longest average duration among all phases, ranging from 17.504 to 19.962 units of time.It shows some variation across iterations but generally remains within this range.The testing phase has an average duration ranging from 7.246 to 7.667 units of time.Like the requirements and design phases, it shows relatively stable durations across iterations.Lastly, the maintenance phase has the shortest average duration, ranging from 1.890 to 2.070 units of time.It also demonstrates consistency across the iterations.
Running the simulation in this first stage provided insight regarding the utilization of resources, specifically allowing us to identify periods where resources were idle as well as periods where there were no available resources resulting in bottlenecks.The data that were provided from the pre-optimization running of our model, can be seen summarized in Table 7.Based on the data, it is evident that the implementation phase experiences the highest number of delays for all project sizes, with a mean number of delays of 14.400.The distribution of these instances varies across project sizes: the small-sized projects had 5.800 delays, the medium-sized projects had 1.800 delays, and the large projects experienced 6.800, on average.This indicates a significant issue in the availability of the programmer resource, suggesting a potential bottleneck in the implementation phase.In terms of mean wait time, the implementation phase also has the longest duration across all resource sizes.In particular, large projects stand out with a mean wait time for programmers of 5.223 units of time.This long wait time verifies the aforementioned issues with resource availability in the implementation stage, indicating that resources, especially for large projects, are considerably strained during this phase.
Contrarily, the maintenance phase shows no delays and no wait time for resources for any of the projects irrespective of size.This suggests a state of optimum resource availability and usage during the maintenance phase.In the design phase, there are a significant number of delays, particularly with large projects (2.600 instances on average), contributing to a high total of 4.000 instances on average.This phase (i.e., maintenance) also exhibits considerable wait times, especially for large projects (0.857 units of time), highlighting a potential area for resource allocation improvement.
The requirements phase shows minimal delays and very short wait times.The delays are exclusive to medium and large projects, with no delays recorded for small projects.This suggests efficient resource usage and availability during this phase, albeit with minor room for optimization with larger projects.Lastly, the testing phase shows minimal delays (six instances) and relatively short wait times.As with the requirements phase, no delays were observed for the medium project size, but both small and large resources experienced delays, indicating possible inconsistencies in resource availability.
In summary, the data reveals significant resource allocation challenges, predominantly in the implementation and design phases.The implementation phase, in particular, shows significant delays and long wait times, suggesting a critical need for optimization.Conversely, the requirements, testing, and maintenance phases demonstrate relatively efficient resource usage and availability, although minor improvements can still be implemented, particularly for larger resources.
Resource availability and usage from the start of the simulation to the first 400 units of time can also be illustrated through line graphs.In particular, the resource utilization of the analyst, designer, programmer, tester, and maintenance person can be seen in Figures 4, 5, 6, 7, and 8, respectively.It is clearly evident that inefficiencies exist.We can see idle resources when the line is above zero, and a bottleneck when the line is at zero.
The second stage, optimization, allowed us to identify and set the resources to their optimal level in order to minimize idleness and eliminate bottlenecks.The steps were optimized in sequence.For the analysis phase, it was confirmed that the original level of five analysts was indeed optimal.Moreover, the design phase had an optimal level of designers of six, up one from the original level of five.Next, the simulation revealed that for the implementation phase, the optimal level of programmers was 11, up one from the original level of 10.The next phase to be examined was testing.We ascertained that the optimal number of testers was 21, up one from the original number of 20 testers.Lastly, the original level of five maintenance personnel for use with the maintenance phase was confirmed to be optimal.These values can be seen in Table 8.The third and final stage, post-optimization, provided insight relying on an optimized set of resources.Of the completed projects we also report the time taken to complete each with respect to size.Overall, the quickest was a small project that was completed in 31 units of time, and the longest was a large project with a completion time of 372.076 units of time.
With respect to small projects, the longest project took 132.179units of time to complete, and the average completion time was 48.098 units of time.When comparing pre-to post-optimization we find that the minimum completion time slightly increased from 30.000 to 31.000 units post-optimization.The maximum time decreased significantly, from 151.029 to 132.179 units.The mean time barely changed, going from 48.285 to 48.098 units of time.The standard deviation also dropped from 17.283 to 15.973, indicating a reduction in the variation of completion times.For medium projects, we see the fastest completion time at 32.000 units of time, the longest taking 216.000 units of time and an average completion time of 62.470.Examining pre-and post-optimization performance we find that the minimum completion time increased by one unit from 31.000 to 32.000 units post-optimization.The maximum completion time saw a considerable decrease from 289.000 units pre-optimization to 216.000 units post-optimization.Interestingly, the mean completion time increased from 57.534 to 62.4702 units.Standard deviation increased from 29.015 to 32.027, indicating increased variability in completion times.
The fastest large project took 34.000 units of time to complete.The average completion for large projects was 99.802.Comparing pre-and post-optimization performance we find that the minimum completion time decreased from 35.000 to 34.000 units post-optimization, which is a positive outcome.The maximum completion time also decreased significantly from 447.778 to 372.076 units.Despite the decrease in min and max times, the mean time increased slightly from 97.775 to 99.802 units.The standard deviation decreased from 78.768 to 74.868 units, showing less dispersion in completion times.
Overall, the minimum completion time across all sizes increased by one unit from 30 to 31.000 units post-optimization.The maximum time saw a notable decrease from 447.778 to 372.076 units, while the mean time increased slightly from 53.331 to 54.903 units.The standard deviation also increased slightly from 29.822 to 30.653 units.
In conclusion, the optimization seems to have had mixed results.It consistently reduced the maximum completion times across all project sizes, which suggests that it was successful at preventing the emergence of extremely long projects.However, the mean completion times increased for both medium and large projects, as well as for all sizes combined, which indicates that the average project may take slightly longer after optimization.The effect on minimum completion times was variable and the standard deviations also saw both increases and decreases, indicating changes in variability.The project completion times can be seen in greater detail in Table 9.To better estimate the duration of each of the different phases of our project (i.e., Analysis, Design, Implementation, Testing, and Maintenance) we can look to the descriptive statistics of completion times that were generated; stratified by the project size (i.e., small, medium, and large) and stage (i.e., pre-optimization and post-optimization).The respective data are presented in Table 10, and we also provide an overview of the key aspects.For the analysis phase, both pre-and post-optimization, all project sizes had the same minimum completion time of 3.00 units.However, the maximum completion time postoptimization increased in comparison to the pre-optimization phase.The most pronounced increase was observed in medium-sized projects, from 5.21 to 7.86 units.This implies that some projects took significantly longer post-optimization, which could suggest challenges or added complexity in the analysis phase.Mean times showed minor variations across the sizes and stages, hovering around 4.00 units.The standard deviation, a measure of dispersion, increased post-optimization indicating a wider spread of completion times around the mean.
The design phase exhibited a significant reduction in maximum completion times post-optimization, particularly for small projects, where it declined from 24.20 to 10.00 units of time.Despite such a significant decrease in the maximum value, the mean completion times remained relatively stable, which might indicate that the optimization process successfully addressed the most time-consuming outliers in the design phase.However, the standard deviation is slightly higher post-optimization, showing that the spread of the completion times around the mean is wider.This suggests that there might be more variation in completion times post-optimization.
During the implementation phase, the mean completion times generally increased post-optimization.The most marked rise was observed in large projects (from 22.60 to 22.39 units).This may indicate that the optimization process did not effectively improve the efficiency of the implementation phase for larger projects or that additional complexities were introduced.Also noteworthy is the increased standard deviation post-optimization, showing a greater range of completion times.This might suggest an increased complexity in programming tasks post-optimization.
In the testing phase, there were minimal changes in the mean completion times, both pre-and post-optimization.However, an increase in maximum completion time was observed for small and large projects post-optimization.This could mean that some postoptimization projects required additional testing time, possibly due to increased complexity or higher standards of quality assurance.However, as the mean and standard deviation remained fairly steady, these longer times might represent outlier cases rather than a general trend.
In the maintenance phase, minimum and maximum completion times were consistently 1.00 and 3.00 units, respectively, across all project sizes and stages.This suggests that the range of completion times remained stable regardless of project size or optimization stage.However, there were minor changes in the mean completion times, such as the small increase from 1.89 to 1.94 units post-optimization for large projects.This might suggest minor alterations in the typical project maintenance time after optimization, though it's worth noting that these changes are quite small.
All phases have uniform minimum completion times, with the exception of the implementation phase, indicating that a certain base level of time investment is required irrespective of project size or optimization.This could be due to fundamental tasks that need to be completed in each phase.The exception, implementation, has a considerably higher minimum time requirement (15.00 units), reflecting that even the simplest programming tasks require a considerable amount of time.
The optimization process affected completion time in various ways, depending on the phase and size of the project.Overall, across all resources and project sizes the mean number of delays fell from 19.300 to 19.000 post-optimization.Similarly, the maximum wait time for a resource fell from 29.000 to 24.927 units of time.Surprisingly though the mean wait time was only slightly affected going from 0.255 to 0.266 units of time.
Looking at project sizes, we see small projects finding their maximum wait times falling dramatically from 25.995 to 20.094 units of time and large the number of mean times that a delay occurred falling from 6.900 to 6.333.Mean wait times dropped from 0.152 to 0.141 units of time.Similarly, we see large projects being positively influenced by the optimization process.The mean number of delays went from 9.800 pre-optimization to 8.333 post-optimization.The maximum time one had to wait for a resource fell from 29.000 to 18.415 units of time.The mean wait time fell from 1.486 to 1.258 units of time.However, the effect on medium projects was not as straightforward.On the one hand the maximum wait time for a resource fell considerably from 27.877 to 24.927 units of time.On the other hand, the mean number of times a delay occurred increased from 2.600 to 4.333 and the mean wait time for resources went from 0.122 to 0.213 units of time.As to individual resources, we again get mixed results.Concerning the maximum time which a phase had to wait for a resource dropping for three of the five resources.In particular, the maximum time one had to wait for the designer resource fell from 17.201 to 8.532 units of time, the programmer resource from 29.000 to 24.927 units of time, and for the tester resource from 5.000 to 4.000 units of time.Conversely, for the analyst resource the maximum wait time increased from 2.205 to 3.857 units of time, though it should be noted that the maximum wait times were already one of the lowest across resources (save for maintenance personnel).The mean number of times a delay occurred varied across resources.For the designer and tester resources, it went down from 4.000 to 1.500 and from 0.600 to 0.500, respectively.For the analyst and programmer resources it slightly rose, from 0.300 to 0.667 and from 14.400 to 16.333, respectively.Similarly, the mean wait time went down for the designer and tester resources, from 0.131 to 0.035 units of time, and 0.012 to 0.010 units of time, respectively.Again, it rose for the analyst and programmer resources, from 0.003 to 0.015 units of time and from 1.049 to 1.169 units of time, respectively.Lastly, it should be noted that the maintenance personnel resource did not encounter any delays across all project sizes both pre-and post-optimization.This data can be seen in greater detail in Table 11.
The simulation also provided insight into the likelihood of errors occurring within different phasers of the software development life cycle.It should be noted that based on how we simulated our waterfall model, errors would first become possible during the design phase.The results indicated that in the design phase, large projects have the highest failure rate pre-optimization (i.e., 29.710%), a figure that drops to 23.529% post-optimization, indicating a reduction of around 21%. Small projects, however, show a slight increase in failure rate post-optimization, from 9.329% to 12.046%, which equates to a rise of approximately 29%.Medium-sized projects similarly display an increase from 16.935% to 18.072%, which is an approximately 7% rise.The failure rate irrespective of size, on the other hand, increases slightly from 13.391% to 14.936% post-optimization, suggesting an overall 12% increase.
The implementation phase saw large projects continue to have the highest failure rate in the implementation phase, at 31.061% pre-optimization and 30.108% post-optimization, implying a 3% reduction.Small projects display a drop from 11.314% to 9.375%, a decrease of about 17%, while projects of a medium size show an increase from 16.845% to 20.949%, roughly a 24% rise.Overall, the failure rate irrespective of size increases slightly from 14.699% to 15.035%.With the tester phase large projects again show the highest failure rates, at 32.110% pre-optimization and 34.146% post-optimization, indicating an increase of approximately 6%.Medium projects also show an increase from 17.615% to 21.030%, a rise of around 19%.By contrast, the failure rates of small projects' increase marginally from 8.914% to 10.317%-about a 16% rise.When not taking size into consideration, the failure rate increases from 13.156% to 15.751%-approximately a 20% increase.
Lastly, the maintenance phase sees the highest failure rate in large projects post-optimization at 31.481%.Medium projects see a drop from 19.079% to 17.935%-a decrease of roughly 6%.Small projects also witness a decrease from 12.422% to 8.850%-about a 29% reduction.Overall, the failure rate decreases from 14.894% to 13.043% post-optimization, indicating about a 12% decrease.When considering all phases, large projects show the highest failure rates both pre-optimization (24.545%) and post-optimization (25.067%).However, small and medium-sized projects saw a rise in overall failure rates post-optimization from 8.512% to 8.232% and 14.410% to 16.143% respectively.
In conclusion, across all project sizes and phases, large projects consistently exhibit the highest failure rates.In terms of the absolute number of failures, the design phase for small projects pre-optimization experiences the most failures (8.200), followed closely by the implementation phase pre-optimization for small projects (9.900).Post-optimization, the implementation phase for small projects still sees a high frequency of failures (8.000).This information can help guide where resources are allocated when trying to reduce project failures -the design and implementation phases in small projects may need additional support or process refinement.
Calculating the percentage decrease/increase in the failure rate from pre-to post-optimization can help identify which phases and project sizes benefit the most from optimization.For instance, in the maintenance phase, small projects see a decrease of about 29% in failure rate, indicating that optimization efforts are particularly effective for this project size and phase.On the other hand, the testing phase for large projects sees an increase of about 6% in the failure rate, suggesting optimization efforts may need to be reviewed and adjusted for this project size and phase.When comparing across phases for each project size, we can see that large projects consistently have the highest failure rates in all phases post-optimization.This suggests that there are specific challenges associated with larger projects that are not effectively addressed by the current optimization measures.Conversely, for small projects, the design and implementation phases tend to have lower failure rates post-optimization, suggesting that the current optimization measures may be more effective for these phases.When comparing across project sizes for each phase, we can see that large projects consistently have the highest failure rates, while small projects tend to have the lowest.This confirms, as would be expected, that project size itself is a significant factor in phase failure rates, with larger projects posing more challenges.
These data, which outlined the number of times a phase failed and was not completed successfully by project size, can be observed in greater detail in Table 12 and visualized in Figure 9.

Discussion
We began this paper inspired by the words of Charette [5], who argued that we could predict and avoid many software failures.In this spirit we developed and executed an event-driven simulation to augment the software development process.This simulation, coded in Python using the SimPy framework, is designed to facilitate the generation of accurate estimates of project completion times and identify an optimal allocation of resources, thereby enabling more effective project management.Moreover, it empowers one to understanding the interplay and associated tradeoffs that exist between longer projects and procuring more resources.Furthermore, having an accurate forecast of resource requirements can significantly improve financial planning for projects.For instance, exceeding anticipated project timelines can increase project costs and lead to budget overruns.Consequently, it is vital to ensure project completion within an allocated timeframe, but also within a projected budget.
The utilization of software to support the modeling of software projects is a popular exercise with millions of dollars being spent each year [57].Previous research by Ali et al. [58] emphasize the criticality of delivering high-quality software within resource and time constraints for the software industry.Additionally, Zhang et al. [59] propose simulation as a viable solution to challenges encountered in software engineering.This aligns with the ideas put forward by Pinho et al. [15], who advocates for the ability to promptly assess alternate scenarios when shifts occur in a planned task timeline in order to realize effective business management.Moreover, Ruiz et al. [46] have indicated that the escalating influence of software, coupled with challenges tied to exceeding schedules and accordingly costs, as well as the customer's perception of subpar product quality, has led to a greater emphasis towards the development of robust software development methodologies.
It should be recognized that waterfall development has been simulated in the past (for example see [18,20,60].Our main contribution was in offering for the first time an open-source solution utilizing Python and SimPy.We took a three-stage approach in the first instance by simulating the waterfall model with an initial set of proposed resource (i.e., the pre-optimization stage).This provided initial insights into our current resource utilization and the identification of bottlenecks within the software development life cycle.The analysis of completion times revealed variations across different project sizes and phases.While the smallest projects generally had the shortest completion times, larger projects took considerably longer.This highlights the impact of project size on the duration of the software development life cycle.Furthermore, the implementation phase consistently exhibited the longest completion times across all project sizes, indicating its complexity and potential for improvement.
Moreover, our analysis of the simulated data revealed that the implementation phase consistently experienced the highest number of delays across all project sizes, indicating potential resource availability issues, particularly for large projects.This suggests a need for optimizing resource allocation and ensuring sufficient availability of programmers during this phase.On the other hand, the maintenance phase exhibited optimal resource availability and usage, with no delays or wait times observed for any project size.The design phase showed significant delays, especially for large projects, pointing to potential areas for improvement in resource allocation.The requirements and testing phases demonstrated relatively efficient resource usage and availability, with minimal delays and short wait times.These findings suggest that the requirements and testing phases are well-supported by the available resources, although minor optimizations can still be implemented for larger projects to ensure consistent resource availability.
Kellner et al. [6] write that "a model is valuable to the extent that it provides useful insights, predictions and answers to the questions it is used to address".To that end, it has satisfied this requirement.Certainly, the insight provided would enable anyone managing such an information systems project valuable information to make an informed decision.On the one hand they would understand and communicate the anticipated duration and predicted completion times for the project and its phases (including any delays caused by a shortage of resources) to the stakeholders.On the other it also offers the potential to explore how changes in resources would influence completion times, but also the ability to identify an optimal set of resources that would eliminate any delays.It is this second path that we undertook, to identify an optimal set of resources, using a second stage (i.e., optimization stage).
The optimization stage was designed to identify the optimal level of resources with respect to the software development life cycle assumptions.Subsequently, we ran the simulation one final time (i.e., post-optimization stage) to ascertain the effect that the optimization process had on the software development life cycle.It should be recognized that while the algorithm led to a set of resources that improved access to resources delays were still experienced in some instances.We attribute this to the pattern search algorithm that we employed whose goal was to systematically adjust resource values until there is no more improvement in the mean wait time for that resource based on a particular threshold.Following the method presented in Basil's [18] work, we conclude that our model is accurate given its ability to properly compute the optimal number of resources needed to realize a specific software product given a respective utilization metric.
The data also offered insight on the errors that could potentially emerge within the software development life cycle.This can offer those managing information systems projects insight as to what errors could appear so that they would not be caught off guard and could adequately address such errors.We would recognize that the presence of errors in the practice of software development is widely recognized.If we were to look at the work of Brooks [61], we would find that approximately half of development time is spent on testing to identify and correct errors.Our analysis revealed that large projects consistently had the highest failure rates, both pre-optimization and post-optimization.This reflects the initial assumptions that had been set for the simulation, which were designed highlight the challenges associated with managing larger projects.

Conclusions
As a practice the development of software has been thoroughly studied and refined over the years yet despite these efforts there are many software projects that are deemed as challenged or failed.The waterfall model has been one of the staples of software development.While there is a belief that waterfall has been discarded in favor of agile approaches, an announcement of its death is premature.A small but significant number of projects still use waterfall.Moreover, there is a growing trend towards hybrid methodologies which combine the more effective aspects of waterfall with the more effective aspects of different flavors of agile.
In our work, we proposed and executed a discrete-event simulation of the waterfall software development life cycle.By proactively identifying and managing potential delays, teams can take preventive measures, better allocate resources, and maintain more predictable project timelines, leading to successful project deliveries and higher customer satisfaction.To implement the simulation, we utilized the Python programming language coupled with the SimPy framework.We executed the simulation based on a set of predefined assumptions which allowed us to estimate the time that would be required to complete various hypothetical projects of different sizes (i.e., small, medium, and large).The simulation offered insight as to project completion times, resource usage, and any connected impacts on project completion.Furthermore, the simulation assists project managers in determining an optimal number of resources required to complete a project within the given schedule and budget constraints.Thus, providing valuable insights for project managers, software development teams, and organizations seeking to refine and improve their software development processes.

Implications
There are several implications that follow from our efforts, and we would contend that they fall into two broad sets.The first of these is a response to McHaney et al.'s [57] cautioning that "a discrete event computer simulation project can be a complex and difficult undertaking".Our work offers an open-source solution to simulate a software development life cycle using a modern, widely used programming language (i.e., Python).This addresses, in part, the issues of access, cost, and complexity, given that both Python, SimPy, and our software are freely available through the internet.Furthermore, we would highlight that the Python language is frequently taught in introductory programming courses.Consequently, many programmers can use our solution without the need for any significant retraining.Thus, there are virtually no significant barriers with respect to access, cost or complexity.Moreover, with respect to complexity, our simulation by design is easily customizable and adaptable.In this way even those with a very basic understanding of the Python language should be able to use it for their needs.Accordingly, a new population (whether that be industry or academia) should now have access to a solution to simulate the waterfall software development lifecycle.
According to Kellner et al. [6], "we have clustered the many reasons for using simulations of software processes into six categories of purpose: strategic management; planning; control and operational management; process improvement and technology adoption; understanding; and training and learning".Indeed, our solution at the most basic level provides an estimate of a project's duration based on the given set of phases (i.e., analysis, design, implementation, testing, and maintenance) and resources (i.e., in our implementation, business analysts, designers, programmers, testers, and maintenance people).This system allows for better projections for project completion, given an existing collection of resources.It also identifies bottlenecks and provides insight as to the extent of delays and the resources necessary to alleviate or eliminate them.Furthermore, the simulation offers the optimal set of resources to eliminate bottlenecks and minimize idleness.Beyond this, our simulation tool pinpoints idle resources, thereby enabling organizations to effectively reassign or reduce redundant assets, thus, empowering those managing information systems projects with the ability to strategically plan the lifecycle, understand the interplay of multiple projects, and make any necessary decisions.One way the resource issue could be addressed is by identifying an optimal part-time full-time employment composition to best address the imbalances between idle resources and bottlenecks caused by a lack of resources.Keeping always in mind the words of Brooks [61], that adding resources takes time.
Not only is such a simulation valuable for the workplace but also for those being trained in managing such projects.Indeed, the use of simulations has been quite common in the training of information systems professionals [62].Through this technology learners can see the impact of their decisions and explore possibilities before working with realworld projects where mistakes may have significant and far-reaching implications for any respective stakeholders.Ruiz et al. [46] reinforces this sentiment when they write, "simulation models offer, as a main advantage, the possibility of experimenting with different management decisions".Continuing with "thus, it becomes possible to analyze the effect of those decisions in systems where the cost or risks of experimentation make it unfeasible" [46].The implication here is that future projects will have access to better-trained project managers, which will optimally result in a higher percentage of successful projects.

Limitations and Next Steps
There are four limitations of this work that should be acknowledged and articulated as they also concurrently offer direction for next steps in the future development of this applied research.The first three are directly connected to the study's narrow scope.Our first limitation arises from our focus on simulating the waterfall model.While our solution offers a promising degree of adaptability, it might be beneficial for our community to examine how other models-such as parallel, iterative, and incremental models, among others-could be implemented as event-driven simulations in Python using SimPy.The next limitation relates to the exclusive use of Python to code our program.Future efforts could potentially explore the use of other languages, such as Java, via the Java Simulation Library (JSL), to extend the reach of our work.The third limitation lies in our adoption of an event-based method of simulation.Subsequent studies could explore alternative approaches, such as agent-based simulation.Finally, our fourth limitation recognizes that any software is intrinsically bound by the human element.The current iteration of our program requires one to be comfortable working with code as it lacks a graphical user interface to facilitate user interaction.Extending the software to include such a feature should expand the user base.Furthermore, an exploration into the usability of the output and how it can be further developed would certainly be of value.
Our Python simulation system opens several avenues for further study.While the simulation identifies bottlenecks and suggests optimal resource allocation in our hypothetical projects, studying the simulation's use in the real world will allow us to determine its efficiency in helping teams deliver software projects on time and within budget.A second area of further study involves integrating the simulation into software engineering courses, to see how asking students to interact with and study the parameters and code of the simulation alters the ways in which they understand the software engineering process and SLDC.

Figure 1 .
Figure 1.Our proposed adaptation of the waterfall model.

Figure 2 .
Figure 2. Activity diagram illustrating the steps in the simulation.

Figure 2 .
Figure 2. Pie charts reflecting the mean number of projects that were initiated by size (a) pre-and (b) post-optimization across iterations.

Figure 3 .
Figure 3.This line chart displays the mean duration of each phase during the pre-optimization stage as the simulation iterates until there are enough values to establish convergence.

Figure 4 .
Figure 4. Line chart illustrating the pre-optimization utilization of the analyst resource for initial 400 units of simulation time during the first iteration.

Figure 5 .
Figure 5. Line chart illustrating the pre-optimization utilization of the designer resource for the initial 400 units of simulation time during the first iteration.

Figure 6 .
Figure 6.Line chart illustrating the pre-optimization utilization of the programmer resource for the initial 400 units of simulation time during the first iteration.

Figure 7 .
Figure 7. Line chart illustrating the pre-optimization utilization of the tester resource for the initial 400 units of simulation time during the first iteration.

Figure 8 .
Figure 8. Line chart illustrating the pre-optimization utilization of the maintenance personnel resource for the initial 400 units of simulation time during the first iteration.

Figure 9 .
Figure 9. Bar chart illustrating the proportion of phases that successfully completed vis-a-vie those which failed.

Table 1 .
List and definition of phases.

Table 3 .
Required human resources by scale of project.

Table 4 .
Duration of phases in days.

Table 5 .
Possibility of error by scale of project.

Table 6 .
Mean duration of each phase by iteration in the pre-optimization stage.
* Units represent simulated units of time.

Table 7 .
Count of the number of times that a resource is unavailable for use as well as the mean wait time to acquire that resource in the pre-optimization stage across iterations.
* Units for mean wait time represent simulated units of time.

Table 8 .
Number of original and optimized resources as well as their corresponding phases and the steps taken to reach optimization.

Table 9 .
Minimum, Maximum, and Mean completion times for projects by size of project across iterations.
* Units for completion times represent simulated units of time.

Table 10 .
Minimum, Maximum, and Mean completion times for projects by phase as well as size of project across iterations.
* Units for completion times represent simulated units of time.

Table 11 .
The mean number of times a delay occurred (Mean Count), as well as the maximum (Max Wait), mean (Mean Wait) and standard deviation (Std.Dev.) of wait times, for resources across iterations by size of project.

Table 12 .
Reports on the mean number of times a phase failed and was not completed successfully by size of project and across iterations.