Solved grammar errors using aspell(1)

scss/abstract.tex

@@ -2,11 +2,11 @@
 
 Software porting is costly and time consuming. As developers prefer to reuse
 code instead of rewriting it, it is important to understand the framework for
-quantifing the costs so that the process can be optimized based on these exact
+quantifying the costs so that the process can be optimized based on these exact
 costs. In this paper we port the Ixia network testing infrastructure on ARM
 boards, such as Raspberry Pi, and extract the porting costs associated with this
 process. By doing this we create a revised model of porting based on which we
-extract the costs for our project. Furhtermore we present the factors that
+extract the costs for our project. Furthermore we present the factors that
 affect the costs and their direct correspondence with the porting model and
 costs. Finally, we discuss the limitations of our porting model and make a
 comparison with the old porting model.

scss/background.tex

@@ -18,7 +18,7 @@ interact with the system. This includes, but it is not restricted to: operating
 system, communication methods, configuration files and system variables,
 hardware architecture or human interaction. 
 
-Mooney~\cite{b7} presents two components of the porting process: transporation
+Mooney~\cite{b7} presents two components of the porting process: transportation
 and adaptation. The first is described as the act of moving the system (code or
 binary executable) to a new environment and the latter is described as the act
 of modifying the system in order to be compatible with the new environment.
@@ -31,8 +31,8 @@ environment.
 
 Mooney's model is very simplistic regarding the tasks that can occur during
 a porting process. From his model, and from the work of Hakuta and Ohminami~
-\cite{b2}, and Tanaka et al.~\cite{b1} a more accureate model can be created that
-reflects better the components invloved in porting an application. We also added
+\cite{b2}, and Tanaka et al.~\cite{b1} a more accurate model can be created that
+reflects better the components involved in porting an application. We also added
 our input in this model based on the needs of our project. Finally, the
 improvised model of porting has the following structure:
 \begin{itemize}
@@ -85,7 +85,7 @@ deliver the ported application that operates in the target environment.
 Testing is of two types in this model. The application can either be tested in a
 simulated environment for convenience (e.g., hardware is not available at the
 moment of testing) or can be tested directly in the target environment.
-Furthermore this tasks includes implictly the time allocated for setting up the
+Furthermore this tasks includes implicitly the time allocated for setting up the
 testing environment.
 
 The last task, that is \textit{General duties}, encompasses subtask related to
@@ -96,7 +96,7 @@ aspects with regards to difficulties encountered during the process.
 
 \subsection{Porting costs}
 
-Now that we have defined what tha porting process is and what are the relevant
+Now that we have defined what the porting process is and what are the relevant
 porting tasks, let us describe the porting costs associated with the process.
 
 Porting costs are measured in man-hours~\cite{b1, b2}. While the costs are

scss/conclusions-and-further-work.tex

@@ -9,7 +9,7 @@ continuing the project or integrating it in other projects inside the company,
 we provided the necessary environment for deploying it.
 
 We have extracted the porting costs for porting IxOS infrastructure on ARM
-boards. Thus we understood what the weaknesses and the strenghts of our project
+boards. Thus we understood what the weaknesses and the strengths of our project
 were. The lack of understanding of the project structure and project use cases
 proved itself to be an important factor during the process of porting. Because
 of this reason we had to spend additional time on testing the system and
@@ -37,7 +37,7 @@ infrastructure on other architectures so that we can achieve a better
 performance of the system). To achieve this goal we will compare our solution in
 the target environment with the same solution in the source environment. We
 expect to see better results in the new environment for some network testing
-suites than in the old enviroment. Furthermore, we plan to compare our solution
+suites than in the old environment. Furthermore, we plan to compare our solution
 with other open-source network testing tools.
 
 To complete the analysis of the factors that affected the porting costs we plan
@@ -49,5 +49,5 @@ between source and target environment}).
 
 Finally, we want to analyze the porting improvements guidelines presented
 in~\cite{b1} and map them on our porting process. However, we do not plan to
-restart the porting processs while mapping these guidelines, instead we want to
+restart the porting process while mapping these guidelines, instead we want to
 have a discussion and draw conclusions based on them.

scss/discussions.tex

@@ -62,13 +62,13 @@ time spent in this first task.
 
 Next we compare the \textit{Building for target environment} in our model with
 \textit{Target testing} from Tanaka et al. There are significant differences in
-the subtasks from the two models but we are interested in a comparation of
+the subtasks from the two models but we are interested in a comparison of
 development time (i.e., actual work focused on solving errors and
 inconsistencies, building binaries, etc.). It seems that Tanaka et al. put the
 time spent on solving errors and the time spent on testing in the same category.
 This makes the comparison difficult as we do not know how to divide this time.
 However our time spent in this stage is 32.71\% while Tanaka et al. spend
-27.8\%. The most time consmuing task for us was to work with the build system,
+27.8\%. The most time consuming task for us was to work with the build system,
 which is not the case for them. This shows the major difference between our
 project and theirs. While our porting was focused on extracting components from
 a larger ecosystem into a target environment, their project was focused on

scss/evaluation.tex

@@ -62,7 +62,7 @@ Porting task & Subtasks & \multirowline{Man\\-hours} & \multirowline{Subtotals\\
                                         \cline{2-4}
                                         & Initial source code modifications                   & 0    & 0    &                         \\
 \hline
-\multirow{5}{5em}{Building for target environment} & \multirowline{Build system triggering and \\ modifcation}                          & 67.56 & 18.76 & \multirow{5}{5em}{32.71} \\
+\multirow{5}{5em}{Building for target environment} & \multirowline{Build system triggering and \\ modification}                          & 67.56 & 18.76 & \multirow{5}{5em}{32.71} \\
                                                    \cline{2-4}
                                                    & \multirowline{Installation on remote \\ environment}                               & 15.26 & 4.23  &                          \\
                                                    \cline{2-4}
@@ -103,11 +103,11 @@ There was no time allocated on making initial source code modifications because
 the system was unfamiliar and hard to understand from the start. Finally, we
 spent more time on \textit{General Duties} than on \textit{Testing}. This shows
 that there was a substantial effort put in trying to make use of discussions
-to clarrify the system.
+to clarify the system.
 
 \subsection{Factors of porting costs}
 
-While porting costs, in our case man-hours, are determined dirctly by program
+While porting costs, in our case man-hours, are determined directly by program
 size and content, other factors and impediments as human experience and
 environment disparities must be taken into consideration.
 
@@ -131,7 +131,7 @@ portability impediments:
     \item Difference in operating system interface (S12)
 \end{itemize}
 
-It can be noted that we added an additional impediment inexistent in Hakuta and
+It can be noted that we added an additional impediment nonexistent in Hakuta and
 Ohminami's list~\cite{b2}, namely S12, which can be placed in the "OS disparity"
 category. This impediment is reflected in the usage of dmidecode(8) on Raspberry
 Pi Linux versus on x86 Linux. On Raspberry Pi we were not allowed to access
@@ -180,8 +180,8 @@ This score is very close the worst possible score:
 \end{tikzpicture}
 
 Indeed the human factors played an important role in our porting. The knowledge
-about the program to be poerted functions and use cases was low. We had a good
-understanding of the target OS and hardware. The experience in the area os
+about the program to be ported functions and use cases was low. We had a good
+understanding of the target OS and hardware. The experience in the area of
 software porting tasks and tools was missing up to this project and previous
 experience on working with large scale system was also missing.
 
@@ -210,7 +210,7 @@ achieve our goals. The score is also described below:
     \draw (0,0.2) -- + (0,-0.4) node[below] {BEST=-6};
     \draw (6,0.2) -- + (0,-0.4) node[below] {WORST=6};
     \draw[thick] (0,0) -- node[below=2mm] {} + (6,0);
-    \node[dot,label={EFI=-1}] at (2,0) {};
+    \node[dot,label={$\alpha_e$=-1}] at (2,0) {};
 \end{tikzpicture}
 
 After we evaluated the costs and discovered their correlation with the porting

scss/porting-ixos.tex

@@ -36,7 +36,7 @@ protocols for the testing suites.
 
 The device device under test is the consumer of the network traffic produced by
 the cards. Usually it is connected between two \textbf{Ports} that will monitor the
-behaviour of the DUT while receiving traffic.
+behavior of the DUT while receiving traffic.
 
 \begin{figure}
     \centering
@@ -81,7 +81,7 @@ environment was simply a task of finding the right tools for building the
 binaries and solving unknown inconsistencies.
 
 InterfaceManager had already a high degree of portability as it was written
-in C++ using an object oriented paradigm. The architecture dependant code was
+in C++ using an object oriented paradigm. The architecture dependent code was
 separated using constructs as ifdefs and the coding style was compiler agnostic,
 meaning that we were able at any time to plug another compiler and generate the
 correct binaries.
@@ -142,7 +142,7 @@ This proved to be a great advantage for us because the testing environment
 worked better on hardware than in the emulator. After we built all our
 components, we started to focus on the inconsistencies between the source
 environment and the target environment. For that we had to modify some parts of
-the program that were source environment dependant. However the porting did not
+the program that were source environment dependent. However the porting did not
 run as smoothly as we expected. We had to investigate multiples paths to
 understand the problems we faced, namely the problems regarding the
 initialization of our Card.
@@ -199,7 +199,7 @@ connected to the computer that ran VirtualBox. To connect the two we had to make
 a bridge between the Virtual Box network and the host network. This did not work
 as expected because this configuration broke the IxServer machine.
 
-When we succedded in putting the Raspberry Pi in the same network as IxServer,
+When we succeeded in putting the Raspberry Pi in the same network as IxServer,
 we faced problems with the Linux operating system running on Card (i.e.,
 Raspberry Pi OS). dmidecode(8) did not work on this system because the operating
 system did not allow us to access /dev/kmem. Another problem we faced featured
@@ -220,15 +220,15 @@ wrong when IxServer was communicating with Card. We had no reference
 communication so we had to rely on trial and error methods to find out what went
 wrong.
 
-Firstly, we tried to investagate if the problem was with Card stats. We assumed
+Firstly, we tried to investigate if the problem was with Card stats. We assumed
 that the Card did not initialize correctly when communicating with IxServer
 because it did not send periodical statistics. However this proved to be false,
-but it came with a rather huge cost. We spent approximatively three days trying
+but it came with a rather huge cost. We spent approximately three days trying
 to see if the problem was the statistics.
 
 Secondly, we focused on the code in IxServer, leaving behind the Card. The code
 is written in C++, using an object oriented paradigm. The coding style helped us
 to surf faster through the code and filter unimportant code zones. However the
 difficulty here was the code size. We had to read multiple thousand-lines files
-in order to find the communication problem. Because of time considerents we only
+in order to find the communication problem. Because of time reasons we only
 patched the code in IxServer side, without modifying the Card.