Re: [Gnumed-devel] further testing / bugs

[Hilmar Berger]

On Tue, 9 Aug 2005 20:47:11 +0200
Karsten Hilbert <address@hidden> wrote:


> > 1. Requirements (module-wise or even unordered list).
> > These should not contain any tech-speak, just plain english
> > descriptions of what a medical doctor wants to see/do.
> Those already exist on the web.
There exist some requirements, however, these must be reviewed, finalized and 
agreed upon so that design work can start. 
 
 
> I have three day jobs. And I have a life, too.
I wasn't trying to say that you did a bad job. In contrary, we all know that 
without your effort Gnumed wouldn't be here at all. I actually don't know how 
you manage to work so much for Gnumed given that one day has only 24h. 

> > (BTW, Scott Berkun's "The art of project management" is a sometime 
> > enlightening book)
> I wish I had time to read it or even apply it. Notice how I
> have previously asked on the list for help with precisely
> such matters.
I am reading it right now and will try to share what I learned. 
My hope is that by implementing an more organized development process, it will 
be easier for everyone to a) understand what we are aiming for and b) 
participate (non-coders can work on requirements, GUI-Designers on feature 
design and implementation, programmers will know what to implement). So instead 
of reading the whole mailing list archive and source code, one look in the 
specs should provide everyone with an good idea what we (the Gnumed community) 
wants to achieve.

> > So what I'm missing is something like that:
> > ...
> Sounds all good and fair. How about we start putting
> together such a thing for 0.2 right now ?
That was the idea. I strongly believe that we shouldn't start coding *without* 
having proper specifications ready at least for the modules we want to work on.

At the beginning we should bring up a list of topics (past/current history, 
prescription, lab etc.) and create pages for those in the wiki. Then we should 
try to fill these pages with requierements (task for non-coders). These should 
be discussed until we have a model the majority can agree on (with must-have 
and nice-to-have requirements). Then we can try translate these in a design 
(UI, backend). Here Richard would be of great value. These design documents 
should be discussed and agreed upon again (finalized). Then actual coders can 
start there work (of course they will help earlier in creating prototypes). 

Hilmar

--