Re: [Gnome-devtools] What we're doing.

[Chris Phelps <chicane reninet com>]

   The problem with this "process" is that is is moderatly rigid and
established. Let's not forget why posix based systems are
cool...stability is number one for me, and flexibility comes in a very
close second. If a tool isn't flexible, I don't use it.
   Yes, it would be possible to implement a flexible framework to manage
an infinite amount of different development processes (via some XML
definition or something), but that would just be a big freakin waste of
our time. We have limited developers and time, so we need to focus on
the most important stuff.
   Now, I may be biased as a psychotic-follow-no-particular-order type,
but that is just how I do things...it's probably genetic. Maybe I'm just
odd, but I never finish projects when I try and start out with a well
defined scheme as to how things are going to go. I end up spending a
month working out all the ideas that come to me, and I never get
anything done. My point is, some people follow 1 process, others follor
another, and still others dont follow anything at all.
   I think that if an IDE were to define anything that tried to control
the way that software evolves (even just a little bit), then very few
people are going to want to use it, and that's not why I'm part of this
development team. I'm here to provide the most flexible environment
possible, that is usable by the largest group of developers.

If dave gets $0.02, then I deserve at least a nickel :-)

Later,
Chicane

> 1. vision statement - define the conceptual vision for the software.
> usually accompanied by some system drawings and use cases (for how
> people may use the system).
> 
> 2. system specification - describe the capabilities of the system in
> relation to users and other systems (external interfaces). 
> 
> 3. software requirements - describe specific requirements of the
> software and the external interfaces. uses an object model for the
> problem domain and use cases for more fine grained examples of system
> use.
> 
> 4. design - after analyzing requirements to establish a particular
> design. this should include an object model for the solution domain and
> message trace diagrams for specific scenarios. also, lay out
> classes/module attributes and methods, etc.. you're typical design
> document.
> 
> 5. testing - lots of testing. component (unit) testing, verification
> testing, system verification. ugh it's alot. usually done by describing
> test philosphies (test plans) and methodolgies (test procedures).
> 
> 6. deployment - distribution/delivery/activation - whatever.
> 
> 7. maintenence - hopefully we wrote well enough to not ever do.
> 
> that's the process at a real high level. it's your standard engineering
> waterfall model. of course, as dave camp will point out (hehe) this
> isn't applicable for every project. i'm starting to throw together some
> ideas for a really flexible process. then developers can pick and choose
> the development steps. it's just taking me along time cause it's sooo
> boring to write...