[Gzz-commits] manuscripts/UMLLink article.rst

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Asko Soukka <address@hidden>    03/02/13 08:37:31

Modified files:
        UMLLink        : article.rst 

Log message:
        background

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/UMLLink/article.rst.diff?tr1=1.15&tr2=1.16&r1=text&r2=text

Patches:
Index: manuscripts/UMLLink/article.rst
diff -u manuscripts/UMLLink/article.rst:1.15 
manuscripts/UMLLink/article.rst:1.16
--- manuscripts/UMLLink/article.rst:1.15        Thu Feb 13 08:27:58 2003
+++ manuscripts/UMLLink/article.rst     Thu Feb 13 08:37:30 2003
@@ -5,7 +5,7 @@
 .. Alternative title: "Free Software toolchain for bidirectional 
    linking between UML diagrams and Javadoc"
 
-.. :Stamp: $Id: article.rst,v 1.15 2003/02/13 13:27:58 humppake Exp $
+.. :Stamp: $Id: article.rst,v 1.16 2003/02/13 13:37:30 humppake Exp $
 
 .. Points for HT people
    ====================
@@ -214,7 +214,7 @@
 ideal software design process. Steps listed above should produce
 documentation, which records requirements or design decisions and
 could be used as reference manuals throughout the building of the
-software [brooks75mythical-man-month]_. In theory in an open Free
+software [brooks75mythical-man-month]_. In theory, in a Free
 Software [fsf02categories]_ project new programmers are always free to
 participate independently. In practice a new programmer could need a
 lot of mentoring by other group members, before one could be
@@ -243,8 +243,9 @@
 ameliorate the Mythical Man Month effect
 [parnas-clements86rational]_(pp255).
 
-Because our group is doing experimental research, we need a flexible
-model for software development process. From the classical software
+Because our group is doing experimental research with a rather small
+group and as an open Free Software project, we need a flexible model
+for software development process. From the classical software
 development process models, ours reminds most of Boehm's Spiral Model
 of software development and enhancement [boehm88spiral-model]_. From
 the modern models our development process is influenced by Extreme
@@ -263,27 +264,29 @@
 process.a single development cycle is even shorter than in the spriral
 model. Though, the development process in Extreme Programming is
 splitted into even smaller cycles and the analysis of the design
-objects continues throughout the design process. [beck99xp]_ The Spiral Model 
emphasizes documenting the changes before implamenting them 
[boehm88spiral-model]_, the Extreme programming don't say much about progr
-       
-.. [#] beck99xp
-
-The nature of our software development process affects also strongly
-our documentation needs. As we proceed by prototyping and enhancing our
-software step by step, also our documentation should be updated in every
-cycle. Because the detailed implementation is in continual change, we prefer
-to emphasis the more constant and general architectural
-documentation. Of course, more detailed up-to-date documentation could be
-generated from the current source for those members who are working with
-particular details. Though, in general documentation rapidly changing details
-would be irrelevant and confusing. Since currently the main purpose for our
-documentation is to help intercommunication within our group, we believe 
manually
-made human abstracted documentation serves our purposes best.
-
+objects continues throughout the design process. [beck99xp]_ The
+Spiral Model emphasizes a lot documenting the changes before
+implementing them [boehm88spiral-model]_. The Extreme Programming
+don't speak out much about documentation, but relies on unit tests
+keeping the software coherent and working [beck99xp]_.
+
+The nature of our software development process affects strongly our
+documentation needs. As we proceed by prototyping and enhancing our
+software step by step, also our documentation should be updated in
+every cycle. Athough, the detailed implementation is in continual
+change, and we prefer to emphasis the more constant and general design
+documentation. Of course, more detailed up-to-date documentation could
+be generated from the current source for those members who are working
+with particular details. Though, in more general design documentation
+rapidly changing details would be irrelevant and confusing. Since
+currently the main purpose for our documentation is to help
+intercommunication within our group, we believe manually made human
+abstracted documentation serves our purposes best.
 
 Implementation
 ==============
 
-Eventually, we found no Free Software [fsf02categories]_ tools which
+Eventually, we found no Free Software tools which
 would fulfill our needs. Therefore, we decided to proceed with our own
 implementation. In addition to the previously discussed goals of the
 documentation as whole, there were also several implementation related