[om-list] process outline

Mon Sep 11 09:27:59 EDT 2000

Maybe this will help communication. It might also help me "reduce & 
simplify" my process thoughts and not get bogged down. Here's the 
software process I've had in mind (summarized from
"The Rational Unified Process" short book):

There are four main phases, to be repeated as necessary. We are in the
first phase:

1. Inception.   Essential activites include: Capturing the more
important requirements so we can determine if the product (and the
design) meets them [done, I believe]; creating a use-case model [nearly 
done, I think]; creating a domain model [next--shouldn't take long?];
and creating a candidate architecture, evaluating
trade-offs in design [the really fun part, next to coding]. The 
inception phase is done when the above things
are created. They are used as guidelines for the elaboration phase.

2. Elaboration.   This phase ensures that
architecture, requirements, and plans are stable enough to proceed with
development. During this phase an executable prototype is built in one
or more iterations (mini-"construction" phases), which addresses the
critical use cases and exposes major technical risks. We choose a tools, 
such as programming language(s), source code management strategy,
division of responsibility among classes and components, component
communication strategy, etc. We define the division of
responsibility among components, key interfaces between components, and
component communication strategy.
Architecture and tool choices are evaluated
by exercising the prototype executable against the critical use case
scenarios, and then by reconsidering how well the architecture will
support key requirements.

3. Construction (i.e., more coding): This is now like a manufacturing
process where components are built to the above designs.
Simultaneous coding works well because the plan is already there. The 
class structure will be refined during
development, with changes being highly coordinated among developers. We
seek to achieve useful versions as rapidly as possible, in each brief
development iteration of a few to several weeks. Cool.

4. Transition. This is where the software changes from a "program" used
by developers to a "product" others can use. We can see how best to
approach this when the time comes. I'm not sure if or how this phase 
applies to an free software project like ours, like it does to to a 
commercial project.

I think we can do great things because of the people we have together. I 
appreciate the freedom of communication we have. If anyone doesn't think 
this is the best approach for us please holler.