Mercurial > docs > diploma
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 |