

\subsection{Simulation Requirements and Assumptions}

In POM, a requirement is represented as a structure containing a
cost and a value. The properties of a  base set of requirements is generated by assigning
uniform random values for the cost and value of the tasks.
After each iteration requirements volatility is handled by updating
each task's value with a normal distributed random value and
a Poisson number of new requirements \cite{pom1} (for details on this process, see the discussion below
on {\em Dynamism}).


Certain significant assumptions for the simulation are listed below \cite{pom1}.

{\it End development time is unknown:} High uncertainty and business circumstances frequently do not allow projects to complete their development efforts. 

{\it Requirement volatility} has two independent factors: discovering new tasks and changing tasks.
\begin{itemize}
\item Requirements are assumed to change either by adding or removing a requirement or
\item The value of a requirement is changed.
\ei
The change in value due to volatility is normally distributed. There is no evidence to support that value changes are biased either on favor of higher or lower valuations as development progresses. 
If a requirement has a value less than or equal to zero, the value of that requirement is set to zero and will never increase in value. 
New requirements arrive at each iteration. The number of new requirements added zero or more, and comes from a Poisson distribution.

{\it Single option for implementation}. There are many different ways each requirement could be implemented, increasing or decreasing the cost or value. For this simulator, it is assumed that the optimal implementation, or the implementation with the greatest $\frac{value}{cost}$ ratio, will be chosen. 
\subsection{Simulation prioritization strategies}
At each iteration, teams copy some unfinished tasks from the heap
to their plan.  The teams may also reflect over the relative cost/value
of the tasks in their plan and (possibly) reorder their tasks using a
``planning policy.''  POM experiments with four policies - three of
which are variants of agile, while the forth emulates traditional
non-agile software development:
\begin{enumerate}
\item Plan Based (PB) : Plan-based policies are different from the other 
  three methods.  This policy models a non-agile development method
  where the order of tasks are sorted once at the start of development
  using the \(\frac{value}{cost}\) numbers assumed at the start 
  of the project.
  While the other policies sort at every iteration, the plan-based
  policy only adjusts task values at every iteration, ``but does not
  resort them.''  \cite{pom1}
\item Agile (AG) : Agile policies sort tasks (every iteration) only 
  using value. According to Cao08 \cite{lCao_bRamesh}
  this is the standard method advocated by the agile community.
\item Agile2 (AG2) : The same as AG, but sorts on value/cost. This is another standard standard method used throughout the agile
  community.
\item Hybrid (HY) : This method works in two passes.  In pass one,
  all unfinished tasks in the heap are sorted by \(\frac{value}{cost}\) 
  (like AG2).
  The median value within this sorted set becomes the \textit{threshold}
  value.  The hybrid policy only completes tasks whose 
  \(\frac{value}{cost}\) is 
  greater than this \textit{threshold} (all other tasks are deferred to
  the next iteration).  Under the simulation conditions presented in \cite{pom1}
  hybrid performs better than other policies (in most cases).
\end{enumerate}

\subsection{Simulation results}
%\begin{figure}
%\begin{center}
%FIND SOME GOOD TITLE FOR THIS
%\begin{tabular}{| c | c | c | c |}
%\hline
%HIGH & AG2 & AG2 & HY, AG \\
%\(\lambda = 20\) & & & \\
%\hline
%MED & HY & HY & HY \\
%\(\lambda = 1.4\) & & & \\
%\hline
%LOW & PB & HY & HY \\
%\(\lambda = 0\) & & & \\
%\hline
% & LOW & MED & HIGH \\
% & \(\sigma = 0.00\) & \(\sigma = 0.15\) & \(\sigma = 2.00\) \\
%\hline
%\end{tabular}
%\end{center}
%\caption{POM Simulator Results}
%\label{table:results}
%\end{figure}
Figure \ref{table:results} shows that the agile based methods out performed the plan based method in most combinations of $\lambda$ and $\sigma$. These results were generated with 1000 separate trials of the POM simulator.

%\begin{figure}
%\includegraphics{jprice/Low-Dynamism-Single-Run.pdf}
%\caption{Low Dynamism}
%\label{figure:POM1-low-dynamism}
%\end{figure}
%\begin{figure}
%\includegraphics{jprice/High-Dynamism-Single-Run.pdf}
%\caption{High Dynamism}
%\label{figure:POM1-high-dynamism}
%\end{figure}
Figures \ref{figure:POM1-low-dynamism} and \ref{figure:POM1-high-dynamism} confirm the "home-ground" results of POM1 based on the Boehm-Turner model that a plan-based approach prefers low dynamism while agile approaches prefer high dynamism.
