214 |
ideal software design process. Steps listed above should produce |
ideal software design process. Steps listed above should produce |
215 |
documentation, which records requirements or design decisions and |
documentation, which records requirements or design decisions and |
216 |
could be used as reference manuals throughout the building of the |
could be used as reference manuals throughout the building of the |
217 |
software [brooks75mythical-man-month]_. In theory in an open Free |
software [brooks75mythical-man-month]_. In theory, in a Free |
218 |
Software [fsf02categories]_ project new programmers are always free to |
Software [fsf02categories]_ project new programmers are always free to |
219 |
participate independently. In practice a new programmer could need a |
participate independently. In practice a new programmer could need a |
220 |
lot of mentoring by other group members, before one could be |
lot of mentoring by other group members, before one could be |
243 |
ameliorate the Mythical Man Month effect |
ameliorate the Mythical Man Month effect |
244 |
[parnas-clements86rational]_(pp255). |
[parnas-clements86rational]_(pp255). |
245 |
|
|
246 |
Because our group is doing experimental research, we need a flexible |
Because our group is doing experimental research with a rather small |
247 |
model for software development process. From the classical software |
group and as an open Free Software project, we need a flexible model |
248 |
|
for software development process. From the classical software |
249 |
development process models, ours reminds most of Boehm's Spiral Model |
development process models, ours reminds most of Boehm's Spiral Model |
250 |
of software development and enhancement [boehm88spiral-model]_. From |
of software development and enhancement [boehm88spiral-model]_. From |
251 |
the modern models our development process is influenced by Extreme |
the modern models our development process is influenced by Extreme |
264 |
process.a single development cycle is even shorter than in the spriral |
process.a single development cycle is even shorter than in the spriral |
265 |
model. Though, the development process in Extreme Programming is |
model. Though, the development process in Extreme Programming is |
266 |
splitted into even smaller cycles and the analysis of the design |
splitted into even smaller cycles and the analysis of the design |
267 |
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 |
objects continues throughout the design process. [beck99xp]_ The |
268 |
|
Spiral Model emphasizes a lot documenting the changes before |
269 |
.. [#] beck99xp |
implementing them [boehm88spiral-model]_. The Extreme Programming |
270 |
|
don't speak out much about documentation, but relies on unit tests |
271 |
The nature of our software development process affects also strongly |
keeping the software coherent and working [beck99xp]_. |
272 |
our documentation needs. As we proceed by prototyping and enhancing our |
|
273 |
software step by step, also our documentation should be updated in every |
The nature of our software development process affects strongly our |
274 |
cycle. Because the detailed implementation is in continual change, we prefer |
documentation needs. As we proceed by prototyping and enhancing our |
275 |
to emphasis the more constant and general architectural |
software step by step, also our documentation should be updated in |
276 |
documentation. Of course, more detailed up-to-date documentation could be |
every cycle. Athough, the detailed implementation is in continual |
277 |
generated from the current source for those members who are working with |
change, and we prefer to emphasis the more constant and general design |
278 |
particular details. Though, in general documentation rapidly changing details |
documentation. Of course, more detailed up-to-date documentation could |
279 |
would be irrelevant and confusing. Since currently the main purpose for our |
be generated from the current source for those members who are working |
280 |
documentation is to help intercommunication within our group, we believe manually |
with particular details. Though, in more general design documentation |
281 |
made human abstracted documentation serves our purposes best. |
rapidly changing details would be irrelevant and confusing. Since |
282 |
|
currently the main purpose for our documentation is to help |
283 |
|
intercommunication within our group, we believe manually made human |
284 |
|
abstracted documentation serves our purposes best. |
285 |
|
|
286 |
Implementation |
Implementation |
287 |
============== |
============== |
288 |
|
|
289 |
Eventually, we found no Free Software [fsf02categories]_ tools which |
Eventually, we found no Free Software tools which |
290 |
would fulfill our needs. Therefore, we decided to proceed with our own |
would fulfill our needs. Therefore, we decided to proceed with our own |
291 |
implementation. In addition to the previously discussed goals of the |
implementation. In addition to the previously discussed goals of the |
292 |
documentation as whole, there were also several implementation related |
documentation as whole, there were also several implementation related |