[om-list] process outline

Tue Sep 12 08:12:49 EDT 2000

Luke

    Yes, I was very silly when I thought that my OO class was the only way
the unified process could be used.  In the class, we were stuck to the
"Rational Rose" product, and had to use the development process *and* their
OO paradigm, (which I think Rational likes to use at just about every step
in the process), and I began to equate the two.

    Thanks for the outline.

    I'll still try to find one of those books, when I find the time.

tomp

----- Original Message -----
From: Luke Call <lacall at onemodel.org>
To: <om-list at onemodel.org>
Sent: Monday, September 11, 2000 7:27 AM
Subject: [om-list] process outline

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.