Tim Churces wrote: > those steps in a serial process. Of course, no matter how intelligent > and diligent the participants in the specification phase are, and no > matter what fancy analysis and data modeling techniques are used, it is > almost impossible to create a satisfactory spec in the abstract - at > soon as the system is built and deployed, the real requirements quickly > become apparent. > > Recognising these problems, most open source development proceeds along > a much more freewheeling, rapidly iterating and often parallel cycles of > partially specify/partially build/test/argue on email lists for a > while/partially respecify etc. Sometimes a "software requirements > document" is compiled along the way, more often the project > documentation (often in the form of comments in the code or in header > files) and user manuals can be seen as a type of post hoc requirements > document. > > So perhaps it is just a matter of tense. Instead of a description of > "what we are going to build", open source projects more often have > somewhat less formal descriptions of "what we built". There is still a > large job of work needed to formalise such material in manner which > would satisfy the FDA, but there is no reason why it can't be done, post > hoc, although it sounds like boring work and you may need to pay someone > to do it. <ironic tone>But funding for such final stage documentation > for otherwise functional open source software products should be easier > to come by than funding for mere twinkles in an entrepreneur's eye, > shouldn't it?</ironic tone>
I could not agree more. Traditional "waterfall" development strategies are usually suitable for closed systems (payroll, assembly line control system) but usually not for open systems (health, education, culture) where organisational structures, requirements and needs are evolving continuously. Open Source developers are in many cases not initially familiar with various development strategies and their strengths/weaknesses, but end up "falling into" rapid prototyping simply because they are resource-strapped and/or initiated to provide usable and customised solutions quickly. Our Health Information Systems Programme (HISP) here in South Africa deliberately choose a prototyping strategy, based on advice from the two Scandinavian informatics researchers involved with the project. This has worked reasonably well, and we are now working on a combination of user help systems AND technical reference materials - the latter not to satisfy FDA or any other formal body, but to provide the detailed specs necessary for new development teams surfacing in other partner countries (Mozambique, Tanzania, Malawi, India, Nigeria, Ghana, Cuba, Norway). In other words, the type of specs needed for the FDA would be a sub-set of the specs needed to open up Open Source projects for REAL. It must be significantly easier for other developers to utilise existing Open Source than to develop it again on their own - and sharing code is often not sufficient. To quote Bimbosana Soriyan from the University of Ife-Ife in Nigeria, whose team developed a Hospital Information System based on Vista: "We spent so much time and effort adapting the Vista code that we often wonder whether it would have been better to develop our own system from scratch". Regards calle ********************************************* Calle Hedberg 3 Pillans Road, 7700 Rosebank, SOUTH AFRICA Tel/fax (home): +27-21-685-6472; Cell: +27-82-853-5352 Email: [EMAIL PROTECTED] *********************************************
