On Wednesday 30 November 2005 12:57, Richard Hosking wrote: Hi Richard,
> I am glad someone has said this - I have been reluctant as a newbie as > it may already have been said and done before. > I have difficulty visualizing Gnumed as a model. The Wiki does have some > stuff, but the ideal would be a visual model starting at the "context" > level diagram - ie the inputs and outputs to the system as a whole. The Personally I lack the knowledge to follow you but please elaborate. > model is developed in progressive detail, drilling down to a module level. > Lack of upfront modelling and design effort is a weak point in OSS > software as a whole. The software eventually evolves into something > useful as nothing is lost, but it might take a few million years.. :) > > I agree there is a real risk that the work so far will be lost, and that > this risk could be reduced by a phase of planning/design according to > one of the accepted methodologies in software design While I mostly seem to justify the status quo I am willing to work with you on this. Please tell me more what you would like to see. Some graphical representation of GNUmed. Do you have a specific idea ? Since I have never attended any CS classes you guys need to help me out on this. Are there any tools to do this, any language or is it just drawing boxes , circles arrows on a piece of paper ? I really have no idea. Sebastian Hilbert > > Could the students be better employed in gathering requirements and > modelling, rather than rushing to code? They can be employed in anything we offer. They will works with us not the other way around, I am afraid. I can only guess but telling them to gather and model requirement would leave them lost. Heck, I couldn't do it if I wanted. On a side note. Ask any question you want. There is no such thing as has been asked before. > > Richard > > Hilmar Berger wrote: > >On Mon, 28 Nov 2005 21:52:24 +0100 > > > >Sebastian Hilbert <[EMAIL PROTECTED]> wrote: > >>>I do not think that GNUmed sucks currently. But I'm afraid it will suck > > > >at > > > >>>one day if we continue working as we do currently because the way it is > >>>done currently does not scale for a larger project (IMHO). > >> > >>Please suggest improvements. Privately if neccessary. Thanks. > > > >What I'm missing most in GnuMed is a proper specification of what we want > > to achieve, i.e. project vision, detailed requirements for all planned > > modules, design documents (what is/should be done in which way), > > assignment of work items etc. > > > >I am aware of the fact that there is a lot of information distributed in > > the mailing list and in pieces in the wiki. Still, if I should point > > somebody (say, an informatics student going to do some work for us) to > > some place were he can find all I wouldn't know what to say. > > > >Over the last years I learned that large and complex projects without a > >final specification *before* starting to work will either have > > difficulties or fail completely. I'm quite convinced that GnuMed is > > complex enough to need a specification. I'm sure Karsten knows exactly > > how he wants to build GnuMed (as knows Ian, as knows Richard, ...), > > however, I believe we would be able to get more collaborators if we could > > only show a well-thought plan what milestones we want to achieve next. > > > >I therefore suggest that at least some energy should be spent in > > documenting and discussing our plans for the nearer future. > >The specification should probably go into the Wiki, once this is up and > >running again. > > > >>My bad, I admit. IT students, course assignments for one semester. 2 > > > >students > > > >>in each group. That's all I know and it's not even certain. > > > >My limited experience with these students is that they will need tight & > >frequent interaction with their project manager, detailed instruction on > >what exactly they should try to do and if possible strict checks if they > >conform to the design principles of the software they are coding for. > >Usually these guys don't have much experience nor in medicine neither in > >delivering quality parts for already existing software, so that's > > something you must try to enforce by some way. If not, we will end up > > with a lot of semi-functional prototypes that might need more work to fix > > than to write from scratch. > > > >Hilmar > > _______________________________________________ > Gnumed-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnumed-devel -- Sebastian Hilbert Leipzig / Germany [www.openmed.org] -> PGP welcome, HTML ->/dev/null ICQ: 86 07 67 86 -> No files, no URL's VoIP: callto://[EMAIL PROTECTED] My OS: Suse Linux. Geek by Nature, Linux by Choice _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
