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

[Mark <jamess1 wwnet com>]

Andrew Sutton wrote:
> 
> Mark wrote:
> >
> > Andrew Sutton wrote:
> > >
> > > with all due respect, i don't know if you're entirely sure what you're
> > > should be working towards. it doesn't make sense to me to come out and
> > > say that we're building this complicated system to perform all these
> > > tasks without really defining what those tasks are. you need to define
> > > the context in which these components operate - in this case it should
> > > be a development process.
> >
> > Maybe you could go into a bit more detail on this.
> >
> > The way I develop software is to start with a bit of design, maybe some
> > diagrams, some drawings, all very abstract stuff, mostly on paper but
> > some times with a tool like Dia. Then I start with the implementation,
> > note that the implementation for me sort of evolves, nothing is set in
> > stone. Also I don't do %100 design and then %100 implementation, I go
> > back and forth a bit. When a problem is a bit difficult, I might write
> > up a short paper on the problem to help clear my thoughts.
> >
> > I think my process is not so concrete mainly because I come from a CS
> > background, I suspect you may come from a software engineering
> > background? Maybe you could enlighten me as to what kind of tools
> > software engineers use, and your process. I don't see any reason why
> > both processes can not be supported, as Dave said "This means having an
> > environment that the
> > user can tailor to his or her needs, and that fits in with the
> > developer's way of working.".
> >
> 
> actually, i come from a cs background too. i don't think i _ever_ saw an
> object model in college. but i got hired by a software engineering
> company that puts the process first. it's their effort to make large
> projects managable and workable by small teams of developers.
> 
> if you really want to know, i'm going through the process for our next
> product...
> 
> 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.

Ok, that helps a lot. I don't see myself using this exact process, but
maybe this makes sense for very large projects, managing many people. 

> 
> 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...

So you mean the development environment would dictate the steps to take?
I'm not sure that would work for me :) Perhaps a process mode could be
turned on and off in the development environment. Anyway this is more
related to an IDE, where your process management tool would control the
flow of interaction with components. I think it would be better to first
define the components used by the process tool, and make sure they fit
into the larger framework. Or at least have a good idea of what is
required of the development framework for the components to be
integrated. I would go for the latter, because the tools you describe
would take a monumental effort to design and implement, and I don't
think this should hold up development in other areas.

Mark