Re: A call to action / Guidelines



I agree with your comments...I have a few questions, tho:

> Off-the-top would be during the beginning of the project only and as
> time would permit, we'd lessen the additions to the feature list to
> quickly close.  I.e. we'd be working two to three steps ahead of the
> programmers in designs and documents so that the programmers would
> have less to worry about and quicker execution.

What's to keep programmers from (perhaps ignorantly, perhaps out of
convenience or lameness) building things without looking at these nice
designs?  This is the biggest problem I've had in my very limited
experience.  The solution is attainable, but it's one of social
convention.

> Have you heard of UML? I would think that that would benefit us greatly
> in documenting our efforts. UML is VERY process driven and it would help
> if we all used it.  DIA for Linux has a UML function.  We should look at
> it.
> 
> This is where I excel, documenting the process and I've already begun
> this with the LDP folks.  Both documents should be aligned so that it's
> easy to move from one to the other and traceability is VERY important
> from a QA perspective. I'll at least start something in the next few
> days, like an outline.

I'm not familiar with any of these TLAs; could you explain?  8)

-B.

===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS)   -   MIT Athena User Interface Project              
                   http://www.votenader.org                   
===============================================================




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