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



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.

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

Andrew Sutton
asutton21 home com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]