Re: [Gnumed-devel] GNUmed alternative development model

[Daniel Minahim]

Hi again guys,

It seems I've brought an old discussion back! That's good, but as a certified 
shrink I would recommend to keep tempers down :)

Anyway, please take a look at the 2 modeling tools I've mentioned:

1) Umbrello (for KDE)
2) ArgoUML (Java)
(3) Dia)

Those are free, I'd suggest Umbrello which has a ready Python generation 
module. ArgoUML is more complete though and can show design faults in 3 
different levels. Both can work with .xmi files which we can post on the 
list. Dia is still very weak for us, but you can play with the UML 
components. 

Why not create a design team? I'd gladly work on it. Those who want to stick 
with me:

1) Learn UML (for those who don't there are thousands of tutorials on the net, 
the official one is at www.omg.org)

2) Get a tool

3) Make an USE-CASE diagram based on the lists wishlist 

4) Evaluate the UC diagram 

5) Generate a OO-ER diagram from the SQL (in UML is class diagram), I think 
this will have to be done manually since postgres autodoc is very faulty.

6) Evaluate the class diagram and work here for a while :)

7) Pass it on to the coding team (which I may join also)

8) Evaluate again and go back to 3


See ya
Daniel


Em Sáb 17 Dez 2005 09:12, Sebastian Hilbert escreveu:
> On Saturday 17 December 2005 08:11, Richard Hosking wrote:
> > The Gnumed project development cycle could be likened to one of the
> > modern "agile" software development methodologies
> > A "prototype" is developed (which may or may not be a working program -
> > it could be a paper protoype) which is then evaluated and changes
> > proposed to improve the current design, and the cycle begins again.
> > This stuff is not just theoretical - it is widely used by commercial
> > software developers to speed the development cycle.
> > I dont have the skills of many in the forum, though they are slowly
> > improving.
>
> looking at myself I have to wonder what skills you mean. Before GNUmed I
> could take apart computers but noch much more. So this is a learning
> process.
>
> > I find the code in Gnumed almost totally impenetrable (which doesnt mean
> > it is badly constructed - it is just me) , and I doubt I could add much
> > of value to the coding without fairly intensive direction.
>
> You get any direction you want. This model implies you are not afraid to
> ask. I encourage you to ask me.
>
> > I would not see Gnumed as a viable alternative in Australia in it's
> > current form - it needs accounting, a front desk module and prescribing.
>
> Too bad for Australia :-)
>
> > As it is, it is of academic interest only to Australian Drs.
>
> This seems to be a common perceptive in AU and I am not going to argue.
>
> > It appears
> > that the work required to achieve these other components may be
> > insurmountable.
>
> Have you ever read Momo ? There is a long street to clean.
>
> > It will be difficult to produce the functionality of alternatives, so it
> > will have to offer something new to compete - I see cost and freedom
> > from Windows with all it's licensing issues as the big drawcards.
> > A proper robust database design and internet/network scalability are
> > other (major!) pluses, but most Drs would not necessarily see this as a
> > great advantage.
>
> I take this as your vision.
>
> > I think perhaps coding should stop and the "evaluation" part of the
> > cycle should be looked at - what do we (and other users) want? Does the
> > current software achieve this? If not, what are the priorities and who
> > will do the work?
>
> Excellent question. I see only one problem for German GNUmed users. The
> only coder here cannot stop because he wants to code for 0.2.
>
> But I very much encourage you guys to follow up on this.
> Ok. Here is my idea.
>
> ###################################################
> I take it there are quite some talented people her on this list. Some of
> which even have good CS skills. I propose you guys for a strong team and
> plan and build GNUmed next generation.
>
> This team consists of
> Richard who has a product already and know what all other doctors need. He
> should be workflow and GUI leader
>
> Then there is Hilmar who can code plus has a pretty good idea of how things
> should go.
>
> Then you need a project leader. Richard knows people for this job.
>
> Then there is one or two people who actually *know* how to use the
> available planning and modeling tools.
>
> Plus for AU you have that one organisation Richard knows about which could
> serve as client for your development process.
>
> There is a company here in Germany that follows the same model you seem to.
> I guess they would be happy to work with you.
> ################################################
>
> > By "management" of the project I would think we mean tracking this
> > process, and to certain extent directing (and assisting if necessary)
> > those interested to do certain tasks in a coordinated way
>
> See above. Richard knows people that are quite experienced.
>
> I any of you guys fears that the GNUmed brand is misused by me or the
> "German" objective rest assured that once you initiate a class A project
> structure Karsten and I will retreat from public appearance to leave the
> GNUmed brand to the better project.
>
> You guys have potential. I mean it. For the sake of medicine form a strong
> team and *prove* Karsten and me wrong. You have the obligation to do so.
>
> I for myself would be happy to market your work commercially here in
> Germany. So please hurry up with your product so I can start selling.
>
> Sebastian
> - who has never been GNUmed manager