lucic71
/
bachelors-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Review discussions

This commit is contained in:
Lucian Popescu 2022-06-18 15:16:14 +03:00
parent d733d56af1
commit ee2ad6292e
1 changed files with 24 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
src/discussions.tex
View File

@ -1,9 +1,5 @@
\chapter{Discussions on Porting Costs} \label{sec:discussion}
\lm{You need to briefly summarize the chapter here, even if you don't say much.}
\lm{This chapter is structured a bit weirdly: you have a chapter named ``Discussions on Porting Costs'', whose first section is ``Discussions'' (almost the same name as the chapter) and the second section is ``General difficulties''. I'm not saying this is necessarily wrong, it's just not very clear why it's structured this way.}
% What I want to say in this section:
% - I want to reflect on imporving the porting process we did. Tanaka proposes
% the following seven ways of raising porting efficiency:
@ -34,7 +30,14 @@
% any porting whatsoever (this discussion is in ../src -> background section if
% i remember correctly)
\section{Discussions}
In this chapter we discuss some conclusions of our porting work including the
limitations of the porting model we used and factors for these limitations,
namely the dependency between porting tasks. We also compare our results with
the results of the first paper that published a porting model to understand what
were the differences between our and their results and conclusions. Finally, we
also present general difficulties that we extracted from our porting.
\section{Conclusions of our porting}
In this section we present observations about the porting process and the
porting costs, focusing on the limitations of the porting model we used and on a
@ -42,8 +45,7 @@ comparison between our results and the results of Tanaka et al.
\subsection{Limitations of the porting model}
Let us start by discussing the limitations of the porting model we proposed in
section~\ref{sec:background}.~\lm{You can leave out this first sentence and just begin with: ``The model in sec:background assumes that [...]''.} The model assumes that the tasks are executed in
The model assumes that the tasks are executed in
sequential order, which is not true. The tasks are rather executed in a
non-linear fashion. For example while building for the target environment,
installing the binaries in this environment and testing the ported application,
@ -103,6 +105,7 @@ conversion there must be time considerents: how much time did we spent on this
bullet? and how do we divide this time between porting tasks?
\lm{If I understand correctly, the problem here is one of taxonomy: a given task could fall into more than one category, or rather, the time allocated to that task could be broken between multiple categories. I'm wondering, then: do the ``porting task categories'' themselves represent the porting process? Or is there some better way to break down porting processes (in general)?}
\lp{I don't know how to answer that question}
\subsection{Dependencies between porting tasks}
@ -130,12 +133,12 @@ as \textit{Discussions} would reduce or increase the needed time for other
subtasks, otherwise if other tasks are not affected by this modification, there
should be no interest in allocating more time for discussing.
\subsection{Comparison between our results and the results of Tanaka et al.}
\section{Comparison between our results and the results of Tanaka et al.}
At this moment we discussed the limitations and open problems that appear in the
model of porting we used. Next, we make a comparison between our results for
porting costs and the results that appeared in the first paper that presented a
basis for our porting model~\cite{b1}~\lm{There is a missing reference here.}. The results can be found in Table 6 of
basis for our porting model~\cite{tanaka}. The results can be found in Table 6 of
the paper we referenced. We will compare the subtotals per tasks and discuss the
reasons of the differences between the two. In terms of \textit{Advance
preparations} we spend a total of 14.35\% of our total time while Tanaka et al.
@ -168,7 +171,7 @@ a larger ecosystem into a target environment, their project was focused on
porting a whole application from one environment to another.
For \textit{Testing} we assume that they spent $\textit{Linked test on target} /
2 + \textit{Workstation testing} = 10.5 + 11.4 = 21.9\%$. We dived~\lm{divided?} the linked
2 + \textit{Workstation testing} = 10.5 + 11.4 = 21.9\%$. We divided the linked
test on target because we assumed that half of this time was allocated to
development and half of it was allocated to testing. Their time for
\textit{General duties} is of 27.4\%. These two times are very similar with our
@ -178,10 +181,9 @@ evaluating the costs in advance, special attention must be payed to these tasks.
\section{General difficulties}
After describing the impediments we faced during our porting~\lm{Not sure this applies anymore. I think you should make this section self-contained, without references such as this.} we decided
to understand them and create a list with general difficulties along with a
short description of each difficulty. This list helps the reader understand what
were the major technical impediments that affected the course of our porting.
This section presentes the general impediments we faced during our porting. The
difficulties were extracted from the parcitular technical difficulties we faced
during the porting process.
\subsection{Lacking documentation}
Lacking written documentation about how the system works means
@ -192,15 +194,18 @@ slower than documentation through written text.
\subsection{Inconsistencies between environments}
This difficulty corresponds to the degree of which the application is
portable~\cite{mooney2004developing}. If the degree of portability is too low
(this depends entirely on the application) then the developer will be faced with
many inconsistencies between the source and target environments that will be
reflected in the cost of porting (i.e., man-hours).~\lm{Don't these inconsistencies also depend on the environments themselves, though?}
portable~\cite{mooney2004developing} between two given environments. If the
degree of portability is too low (this depends entirely on the application) then
the developer will be faced with many inconsistencies between the source and
target environments that will be reflected in the cost of porting (i.e.,
man-hours).
\subsection{Use of tools}
Using inadequate development and testing tools introduces additional
overhead in the porting process. This happens when the used tools are either
outdated or too hard to use~\lm{I'm still not bought on the ``outdated'' aspect; developers shouldn't suffer just because a maintainer decides to break compatibility with an older version of a tool.} for the purpose of the process.
outdated or too hard to use~\lm{I'm still not bought on the ``outdated'' aspect; developers shouldn't suffer just because a maintainer decides to break compatibility with an older version of a tool.}
\lp{is there something we can do regarding this?}
for the purpose of the process.
\subsection{Understanding the system}
Software complexity is a multi-dimensional problem, it includes: structural,