# Simulating the Software Development Lifecycle: The Waterfall Model
## 3 Materials and Methods
### Assumptions  
Our software simulates a software development house's ability to pursue concurrent projects of small, medium, and large scales, given a fixed number of resources. Given that a simulation is a simplified version of a more complex system [54], we must establish and rely on certain assumptions. To that end, we look to the work of [PERSON] [21] and his simulation of the waterfall model. Specifically, the available resources for our software house are outlined in Table 2; the required human resources by size of project are presented in Table 3; the duration of phases in days are outlined in Table 4; and the probabilities of an error occurring are presented in Table 5. Note the supposition of clear requirements, which is implicit with the use of the waterfall model.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Phase** & **Definition** \\ \hline Requirements analysis & “The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail \\ and definition & and serve as a system specification” [48]. \\ \hline System and & “The systems design process allocates the requirements to either hardware or \\ software **design** & software systems by establishing an overall system architecture. \\ software design involves identifying and describing the fundamental \\ software system abstractions and their relationships” [48]. \\ \hline
**Implementation** and & “During this stage, the software design is realized as a set of programs or program units. Unit testing \\ unit testing & involves verifying that each unit meets its specification” [48]. \\ \hline Integration and & “The individual program units or programs are integrated and tested as a complete system to ensure \\ systems **testing** & that the software requirements have been met. \\  & After testing, the software system is delivered to the customer” [48]. \\ \hline Operation and & “Normally (although not necessarily), this is the longest life cycle phase. The system is installed and \\ maintenance & put into practical use. Maintenance involves correcting errors which were not discovered in earlier \\  & stages of the life cycle, improving \\  & the implementation of system units and enhancing the system’s services \\  & as new requirements are discovered” [48]. \\ \hline \hline \end{tabular} Note: Phase definitions as stated by [PERSON] [48].  
\end{table}
Table 1: List and definition of phases.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Category** & **Quantity** \\ \hline Analyst(s) & 5 \\ Designer(s) & 5 \\ Programmer(s) & 10 \\ Tester(s) & 20 \\ Maintenance personnel & 5 \\ \hline Values are as proposed by [PERSON] [21]. \\ \hline \hline \end{tabular}
\end{table}
Table 2: Available resources.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Role** & **Small** & **Medium** & **Large** \\ \hline Analyst(s) & 1 & 2 & 5 \\ Designer(s) & 1 & 2 & 5 \\ Programmer(s) & 2 & 4 & 10 \\ Tester(s) & 2 & 6 & 20 \\ Maintenance personnel & 1 & 2 & 5 \\ \hline \hline \end{tabular}
\end{table}
Table 3: Required human resources by scale of project.  
We introduce the projects using an exponential statistical function with a mean arrival of 35 units of time (the value of 35 inspired from the work of [PERSON] [21]) parameterized by a lambda value of 1/35. We also account for the scale of the project, using the work of [PERSON] [55] as guidance. [PERSON]'s study of information technology projects reports that 48% of the projects had a budget less than EUR 1 million, 25% between EUR 1 and 10 million, and 27% more than EUR 10 million. Accordingly, we set a 48% chance of a project being a small-scale project, a 25% chance of it being a medium-scale project, and a 27% chance of it being a large-scale project. 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.