92 |
Software development processes |
Software development processes |
93 |
------------------------------ |
------------------------------ |
94 |
|
|
95 |
- our development process seems to be closing Boehm's spiral model |
In their article "A rational design process: how and why to fake it" [#]_ |
96 |
[boehm-spiral-model] of software development(, though our spiral is |
Parnas and Clements argue that rational software design process is not |
97 |
endless and we have probably several of them running simultaneously) |
generally possible, but acceptable results could be achieved by faking |
98 |
|
"the ideal process". Their ideal software design process contains the |
99 |
- architectural documents are important parts of design, |
following steps{#]_: |
100 |
redesign and maintenance phases of the design process |
|
101 |
|
A) establish and document requirements |
102 |
+ faking a rational design process |
B) design and document the module structure |
103 |
[parnas-clements-rational, pp.252-255]: |
C) design and document the module interfaces |
104 |
|
D) design and document the uses hierarchy |
105 |
A) establish and document requirements |
E) design and document the module internal structures |
106 |
B) design and document the module structure |
F) write programs |
107 |
C) design and document the module interfaces |
G) maintain (redesign and redevelopment, keeping documentation |
108 |
D) design and document the uses hierarchy |
up-to-date). |
109 |
E) design and document the module internal structures |
|
110 |
F) write programs |
.. [#] parnas-clements-rational |
111 |
G) maintain (redesign and redevelopment, keeping documentation |
|
112 |
up-to-date). |
.. [#] parnas-clements-rational, pp.252-255 |
113 |
|
|
114 |
+ creating UML diagrams should be natural part our of design |
It should be clear that documentation plays major role in the ideal |
115 |
(pegboard) and documenting (architecture docs) processes |
software design process. Steps listed above should produce documentation, |
116 |
|
which records requirements or design decisions and could be used |
117 |
+ as a small group we have too small budget for |
as reference manuals throughout the building of the software [#]_. In a |
118 |
large tools like Rational Rose (also ideological reasons |
theory in an open software project new programmers are always free to |
119 |
to use open source, though open code is always extensible) |
participate independently. In practice a new programmer could need a lot |
120 |
|
of mentoring by other group members, before one could be productive for |
121 |
+ the point of good and documentation is to reduce the |
the project. Sometimes sufficient mentoring could not even be possible, |
122 |
Mythical Man of Month effect [brooks-mythical-man-month]; |
because members open software projects could be geographically widely |
123 |
lowering threshold for new people; help intercommunication |
decentralized. This results the Mythical Man Month effect[#]_: adding a |
124 |
within the group |
new member into software design process could rather delay than speed up |
125 |
|
the project: |
126 |
- [p. 16] "Men and months are interchangeable commodities only |
|
127 |
when a task can be partitioned among many workers with no |
"Men and months are interchangeable commodities only when a task can be |
128 |
communication." |
partitioned among many workers with no communication."[#]_ |
129 |
- [p. 17] "In tasks that can be partitioned but which require |
|
130 |
communication among subtasks, the effort of communication |
"The added burden of communication is made up of two |
131 |
must be added to the amount of work to be done." |
parts, training and intercommunication. Each worker must be trained |
132 |
- [p. 18] "The added burden of communication is made up of two |
in the technology, the goal of the effort, the overall strategy, and |
133 |
parts, training and intercommunication. Each worker must be trained |
the plan of work.-- --Intercommunication is worse."[#]_ |
134 |
in the technology, the goasl of the effort, the overall strategy, and |
|
135 |
the plan of work." "Intercommunication is worse." |
.. [#] brooks-mythical-man-month |
136 |
|
|
137 |
- our group's working culture - flexible work times and and |
.. [#] brooks-mythical-man-month p.16 |
138 |
decentralized working places - is especially vulnerable to |
|
139 |
intercommunication problems |
.. [#] brooks-mythical-man-month p.18 |
140 |
|
|
141 |
|
Eventually, the greater is the amount of programmers or higher turnover within |
142 |
|
them, the more important is to have a good documentation. When new programmers |
143 |
|
join the project they shouldn't have to depend completely on the old staff for |
144 |
|
they information. An up-to-date and rational set of documents available for |
145 |
|
them could ameliorate the Mythical Man Month effect[#]_. |
146 |
|
|
147 |
|
.. [#] parnas-clements-rational p.255 |
148 |
|
|
149 |
|
Because our group is doing experimental research, we need a flexible |
150 |
|
model for software development process. From the classical software |
151 |
|
decelopment process models, our one reminds most Boehm's spiral model |
152 |
|
of software development and enhancement [#]_. The spiral model |
153 |
|
is a cyclic and repeative model, where every cycle has the following |
154 |
|
phases [#]_: |
155 |
|
|
156 |
|
* determining objectives, alternatives, constraints |
157 |
|
* evaluating alternatives, identifying and resolving risks |
158 |
|
* developing, verifying |
159 |
|
* planning next phase |
160 |
|
|
161 |
|
.. [#] boehm-spiral-model |
162 |
|
|
163 |
|
.. [#] boehm-spiral-model p.64 |
164 |
|
|
165 |
|
The nature of our software development process affects also strongly to |
166 |
|
our documentation needs. As we proceed by prototyping and enhancing our |
167 |
|
software step by step, also our documentation should be updated in every |
168 |
|
cycle. Because the detailed implementation is in continual change, we prefer |
169 |
|
to weight our documentation to more constant and general architectural |
170 |
|
documentation. Of course more detailed up-to-date documentation could be |
171 |
|
generated from the current source for those members, who are working with |
172 |
|
particular details. Though, in general documentation rapidly changing details |
173 |
|
would be irrelevant and confusing. Since currently the main purpose for our |
174 |
|
documentation is help intercommunication within our group, we believe manually |
175 |
|
made human abstracted documentation serving purposes best. |
176 |
|
|
177 |
Javadoc |
Javadoc |
178 |
------- |
------- |
179 |
|
|
304 |
|
|
305 |
Dia (drawing, generating code templates) |
Dia (drawing, generating code templates) |
306 |
|
|
307 |
- Dia [#]_ a free software (licensed under GPL) diagram creating program |
- Dia [#]_ is a free software (licensed under GPL) diagram |
308 |
with direct manipulation user interface. |
creating program with direct manipulation user interface. |
309 |
- more a drawing than a design tool |
- more a drawing than a design tool |
|
- could be used instead of metapost, but |
|
|
direct manipulation problem again |
|
310 |
|
|
311 |
.. [#] http://www.lysator.liu.se/~alla/dia/ |
.. [#] http://www.lysator.liu.se/~alla/dia/ |
312 |
|
|
359 |
- Include PEGs: possibly not-yet accepted or not-yet implemented proposals |
- Include PEGs: possibly not-yet accepted or not-yet implemented proposals |
360 |
for architectural changes. |
for architectural changes. |
361 |
|
|
362 |
|
|
363 |
|
+ creating UML diagrams should be natural part our of design |
364 |
|
(pegboard) and documenting (architecture docs) processes |
365 |
|
|
366 |
|
+ as a small group we have too small budget for |
367 |
|
large tools like Rational Rose (also ideological reasons |
368 |
|
to use open source, though open code is always extensible) |
369 |
|
|
370 |
|
|
371 |
Javadoc, on the other hand, is |
Javadoc, on the other hand, is |
372 |
|
|
373 |
- fully generated documentation from javadoc comments |
- fully generated documentation from javadoc comments |
674 |
- placement: currently metapost; looking at ways to make |
- placement: currently metapost; looking at ways to make |
675 |
interactively editable. |
interactively editable. |
676 |
|
|
677 |
|
- Dia could be used instead of metapost, but |
678 |
|
direct manipulation problem again |
679 |
|
|
680 |
|
|
681 |
Practical use |
Practical use |
682 |
============= |
============= |
683 |
|
|