/[gzz]/manuscripts/UMLLink/umllink.rst
ViewVC logotype

Diff of /manuscripts/UMLLink/umllink.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.51 by benja, Tue Jan 28 16:12:07 2003 UTC revision 1.52 by humppake, Thu Jan 30 11:47:15 2003 UTC
# Line 92  Background Line 92  Background
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    
# Line 268  Rational Rose Line 304  Rational Rose
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    
# Line 325  of the architecture). Line 359  of the architecture).
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
# Line 631  Why UML-language Line 674  Why UML-language
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    

Legend:
Removed from v.1.51  
changed lines
  Added in v.1.52

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26