comparison thesis/tex/4-MasqmailsFuture.tex @ 277:8a25b6262497

minor changes; added todos
author meillo@marmaro.de
date Thu, 15 Jan 2009 15:44:31 +0100
parents c80b6b6fb798
children bf23572f3e8d
comparison
equal deleted inserted replaced
276:ce4d5b39e554 277:8a25b6262497
51 51
52 \begin{figure} 52 \begin{figure}
53 \begin{center} 53 \begin{center}
54 \includegraphics[scale=0.75]{img/mta-channels.eps} 54 \includegraphics[scale=0.75]{img/mta-channels.eps}
55 \end{center} 55 \end{center}
56 \caption{Incoming and outgoing channels required} 56 \caption{Required incoming and outgoing channels}
57 \label{fig:mta-channels} 57 \label{fig:mta-channels}
58 \end{figure} 58 \end{figure}
59 59
60 An overview on in and outgoing channels required for an \MTA, gives figure \ref{fig:mta-channels}. 60 An overview on in and outgoing channels required for an \MTA, gives figure \ref{fig:mta-channels}.
61 61
157 \paragraph{\RF10: Archiving} 157 \paragraph{\RF10: Archiving}
158 Mail archiving and auditability become more important as email establishes as technology for serious business communication. The ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve. 158 Mail archiving and auditability become more important as email establishes as technology for serious business communication. The ability to archive verbatim copies of every mail coming into and every mail going out of the system, with relation between them, appears to be a goal to achieve.
159 159
160 \postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every outgoing mail to a definable recipient. At least this functionality should be given, although a more complete approach is preferable. 160 \postfix\ for example has a \texttt{always\_bcc} feature, to send a copy of every outgoing mail to a definable recipient. At least this functionality should be given, although a more complete approach is preferable.
161 161
162 << refer to SOX >> %fixme
162 163
163 164
164 165
165 166
166 \subsection{Non-functional requirements} 167 \subsection{Non-functional requirements}
254 255
255 Modularity is no direct requirement, but a goal that has positive influence on important requirements like security, testability, extendability, maintainability, and not least simplicity. These quality properties then, on their part, make achieving the functional requirements easier. 256 Modularity is no direct requirement, but a goal that has positive influence on important requirements like security, testability, extendability, maintainability, and not least simplicity. These quality properties then, on their part, make achieving the functional requirements easier.
256 257
257 Hence, aspiration for modularity, by compartmentalization, improves the overall quality and function of the software. It can be seen as an architectural requirement for a secure and modern \MTA. 258 Hence, aspiration for modularity, by compartmentalization, improves the overall quality and function of the software. It can be seen as an architectural requirement for a secure and modern \MTA.
258 259
260 %fixme: explain: why are compartments and interfaces so good?
259 261
260 262
261 263
262 \section{Fulfilled requirements} 264 \section{Fulfilled requirements}
263 \label{sec:fulfilled-requirements} 265 \label{sec:fulfilled-requirements}
462 464
463 However, a redesign and rewrite of software from scratch is hard. It takes time to design a new architecture, which then must prove it is secure and reliable. As well is much time and work needed to implement the design, test it, fix bugs, and so on. If flaws in the design appear during prototype implementation, it is necessary to start again. Thus the gain of a new design must overweight the effort needed. 465 However, a redesign and rewrite of software from scratch is hard. It takes time to design a new architecture, which then must prove it is secure and reliable. As well is much time and work needed to implement the design, test it, fix bugs, and so on. If flaws in the design appear during prototype implementation, it is necessary to start again. Thus the gain of a new design must overweight the effort needed.
464 466
465 \person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code): 467 \person{Wheeler}'s program \name{sloccount} calculates following estimations for \masqmail's code base as of version 0.2.21 (excluding library code):
466 468
467 \begin{quote} 469 \codeinput{input/masqmail-sloccount.txt}
468 {\footnotesize
469 \begin{verbatim}
470 Total Physical Source Lines of Code (SLOC) = 9,041
471 Development Effort Estimate, Person-Years (Person-Months) = 2.02 (24.22)
472 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
473 Schedule Estimate, Years (Months) = 0.70 (8.39)
474 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
475 Estimated Average Number of Developers (Effort/Schedule) = 2.89
476 Total Estimated Cost to Develop = $ 272,690
477 (average salary = $56,286/year, overhead = 2.40).
478 SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
479 \end{verbatim}
480 }
481 \end{quote}
482 470
483 The development cost is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years, in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer, not as employee with eight work-hours per day. 471 The development cost is not relevant for a \freesw\ project with volunteer developers, but the development time is. About 24 man-months are estimated. The current code base was written almost completely by \person{Oliver Kurth} within four years, in his spare time. This means he needed around twice as much time. Of course, he programmed as a volunteer developer, not as employee with eight work-hours per day.
484 472
485 Given the assumptions that (1) an equal amount of code needs to be produced for a new \masqmail, (2) a third of existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s. Then it would take between two and three years to have a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs. 473 Given the assumptions that (1) an equal amount of code needs to be produced for a new \masqmail, (2) a third of existing code can be reused plus concepts and knowledge, and (3) development speed is like \person{Kurth}'s. Then it would take between two and three years to have a redesigned new \masqmail\ with the same features that \masqmail\ now has. Less time would be needed if a simpler architecture allows faster development, better testing, and less bugs.
486 474