\section{Development Plan \& Evaluation}
\subsection{Development Plan}
The development plan is written following the spiral software development model
in which all requirements are divided into small iterations. Each of the
iterations will have an implementation phase, a testing phase, an analysis
phase, and a design phase. Furthermore, each of the iterations will have goals
and results. The iterations and their deliverables are listed in
\autoref{tab:devit}. The schedule for finishing iterations are listed in
\autoref{tab:deadli}. On the 6th of January the must-have should be finished
and if they are we try to complete as many iterations as possible.
\begin{table}[H]
	\centering
	\begin{tabu} to \linewidth{llX}
		\toprule
		Deadline & Iterations\\
		\midrule
		9 Dec 2015 & 1--2\\
		16 Dec 2015 & 3--5\\
		23 Dec 2015 & 6--9\\
		6 Jan 2015 & 10--11\\
		13 Jan 2015 & Demo\\
		\bottomrule
	\end{tabu}
	\caption{Deadlines}\label{tab:deadli}
\end{table}
\begin{table}[H]
	\centering
	\begin{tabu} to \linewidth{rlXX}
		\toprule
		It. & Req. & Description & Deliverables\\
		\midrule
		1 & NR1 & Create a DSL for MarsRover's missions to use available
			sensors and actuators. & \texttt{TaskDSL.xtext}\\
		2 & ER3 & Implement diagnostic functions that print on the \emph{LCD}.
			& A \emph{LCD} class that prints to the \emph{LCD} screen.\\
		3 & -- & Implement functions in the code generation for basic motor the
			motor actions: forward, backward, measure rock, measure lake and
			wait. & Code
			generation for motors\\
		4 & -- & Implement functions in the code generation for communicating
			the sensors from the slave to the master. & Functions in the master
			program to read the slave's sensors.\\
		5 & -- & Create functionality for sensor values and determine the
			treshholds manually. & Code generation for sensors and threshhold
			constants.\\
		6 & CR1 & Create functionality to keep the MarsRover in the planet. &
			A generatable behaviour to stay on the planet.\\
		7 & MR3 & Create functionality for not bumping into rocks. & A
			generatable behaviour to not bump into rocks.\\
		8 & MR1 & Create functionality to find lakes. & A generatable mission
			to find lakes.\\
		9 & MR6 & Create functionality to perform missions in sequence. & A
			generatable main program that performs missions.\\
		10 & MR2, MR4& Create functionality to find rocks. & A generatable
			mission to find rocks.\\
		11 & MR5 & Create functionality to push rocks and detect when the
			robots is pushing. & A generatable behaviour for pushing.\\
		12 & MR7 & Create functionality to find the parking space. & A
			generatable behaviour that can find the parking space.\\
		13 & MR8, ER1 & Create functionality to map the environment and to
			localize. & A generatable behaviour that can map while
			performing.\\
		14 & ER2 & Create functionality to play sounds. & Add a generatable
			function for playing sounds.\\
		15 & NR3, NR4 & Create functionality to calibrate the sensor
			treshholds. & A generatable function to calibrate the sensors.\\
		16 & NR5 & Create functionality that when the robot encounters bugs it
			can restart itself. & Functionality in the main program to do so.\\
		17 & -- & Speed up the behaviour of the robot within safety limits.\\
		\bottomrule
	\end{tabu}
	\caption{Spiral model iterations}\label{tab:devit}
\end{table}

\subsection{Evaluation}
\subsubsection{Realisation}
%implemented features and mission range
The final implementation satisfies all the \emph{must have} requirements.
Besides all the most important requirements it also supports all \emph{should
have} requirements except \emph{MR8} in which the robot must be able to
remember the locations of the lakes. This is because we encountered some
problems during the development phase that lead to a shortage of time. Because
of that mapping and localization was not implemented. In the end of the process
we had some time left which we used to implement \emph{ER2} since it was
relatively simple.

The range of missions the robot can support is a lot bigger then reflected by
the met functional requirements. All actions specifiable in a behaviour consist
of atomic operations that take very little time leading to the action being
interruptible at all times. Together with the rudimentary variable storage we
can make missions very complex. Possible combinations of behaviour can perform
actions such as: counting, following moving objects and grouping objects.

In the beginning of the running program, the user need to press any button to start 
the program in the robot. This is because both bricks need to start the bluetooth 
communication pairing at the same time. If we were given more time we would make 
the bluetooth pairing automatically run from the beginning of the program without 
waiting button press in order to limit the user involvement in the robot.

The DSL can accomodate the improvement in the case of adding new sensors or actuators.
For instance, if we want to add a new sensor, then it is easy to add new \emph{StoppingExpression}
in the DSL. In addition, if we want to add a new actuator to the robot, we can just add
a new action defined in the DSL and implement the use of the action in the program.

\subsubsection{Discussion}
%development process, use of dsl/technologies, general lessons
From our experience, the most important think in the development process was to 
start working from a small functionality and to test it. As soon as we knew 
something wrong with the program we can fix and test it again in order to ensure 
the functionality worked. This would be good for the development of the next 
functionality. The difficulty in the development was in the testing phase. The 
reason was sometimes we got an error when running the program in the robot (for 
example: sensor exception) and it took so much time for loading all sensors to be 
ready for testing. Moreover, there was a time when the robot was crashed and needed 
to be restarted which took some time from the development time.