Review discussions
This commit is contained in:
parent
d733d56af1
commit
ee2ad6292e
|
@ -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,
|
||||
|
|
Loading…
Reference in New Issue