>I'm not scared by the process doc, although it is very rigorous. I
>agree with this kind of approach - system must be specified before it
>is coded. And I also have a suggestion here: we need an tool to ease
>the process of specification - writing all specs manually is a hard
>process. More than that, plain text specs may take too much time to be
>read and understood. I suggest writing a visual modeling tool, like
>Rational Rose, and using UML for the needs of specifying and
>documenting of a system. UML is a perfect language for this puprose -
>it is very understandable, and compact. Also it is very easy to learn,
>in case you (or anyone else) don't know this language. I've already
>started creating such tool for BeOS a few days ago, and I suppose the
>first working version to be ready in a couple of weeks (4-6). You
>don't have to wait for its completion, but I think you should be
>prepared for it.
>
>Stepan Stolyarov [stevebest@xxxxxxx]
Thoughts, guys? Personally, I don't think we need a UML tool at this
point -- most of our function specs and use cases will get pulled right
out of the BeBook. app_server is one place I might normally agree it
would be useful, but I'm inclined to pass because I think 1) I'd rather
not wait 4-6 weeks to start getting some app_server docs and 2) I'm
sceptical that the tool can be written that quickly. Or rather, a UML
tool written that quickly is not going to be feature-full enough to be
worth using. Oh, and 3) I hardly know UML myself and don't have time to
really get a grip on it right now. Anybody else is in the same boat?
Otherwise, I like Stepan's enthusiasm for the process and doing design
and architecture up front. =)
My $.02,
e
Data is not information, and information is not knowledge: knowledge is
not understanding, and understanding is not wisdom.
- Philip Adams