Pete, With the greatest respect you have been talking about this for years as you say - and are still no further forward. Doesn't this tell you something?
I offered myself to help you out about 18 months ago now but found that your overall understanding of the requirements relating to the "computer" interface and you view of the finished product was lacking to say the least. 1. You must have a good idea of how you want the finished article to look. If you haven't got this then how do you expect to convey the finished produce concepts to the developer? 2. You must define all the industry specific terms as completely as possible. You may well understand the meaning "Medical History" but it means absolutely "diddly squat" unless you give examples and more importantly where and how you use this information. 3. You need to know what you need "in to" and "out of" the system. Let the developer decide how to transform the data from one form to another. You just put your magic hat on and decide what you would like to do in a perfect world. Obviously, everything is possible but not required or practicable due to costs and time constraints. Once you have a wish list, then prioritise it in terms of desirability and time (i.e. expense). 4. Don't aim for the moon straight away as you will find that your requirements change as the project progresses. This is known as "project creep" which is not a totally bad thing as long as it doesn't mean that the goalposts of the project are moving. A static target is difficult enough to hit as it is, without it moving. 5. Get a good developer to advise you on system design and produce a systems requirement - however small and rough. Remember "Project creep" costs money so treat the project like building a house and get some good plans drawn up first. 6. Remember, what you think is the "best thing since sliced bread" and a market killer may not be the case. Take a long look at your target market and make sure you are not simply developing a product that is good for YOU and nobody else - take off those rose tinted spectacles and research the market thoroughly. 7. If you couldn't finish the product in 12 years then doesn't this tell you something? Why not try and produce a "lash up" in VFP yourself, no matter how crude as it will concentrate your mind on the problems a developer will face. Surely you know enough VFP yourself to do this. 9. Keep it simple. Better to spend a small amount of money for a little success than a large amount of money for a big disaster. 10. Presentation, presentation, Presentation followed closely by Documentation, Documentation and finally Documentation. I would certainly help with your project but I certainly wouldn't be prepared to do ALL the work myself. You need to get stuck in and produce a decent proposal and then you may well find that professional help will be at hand. At the moment you only have an idea and unfortunately it is up in your head - not an easy place to access. Finally, and please don't think me rude or insensitive to your current employment predicament, my comment would be that if you were to have spent as much time defining your requirements as you do posting trivial messages on the [OT] forum then you would probably have a finished product and become a capable VFP developer yourself. Meanwhile, let me know if I can help in any practicable way, but please don't expect everyone else to do the heavy lifting for you. Yours constructively (hopefully). Dave Crozier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Theisen Sent: 03 July 2007 17:23 To: ProFox Email List Subject: [NF] Defining purpose Hi Everybody! For the last twelve years or so I have been trying to program an application to collect research data for Traditional Chinese Medicine study in English. It hasn't helped that I don't know jack about programming, or even about computers. The only thing that has sustained my efforts is the conviction that this is needed by my fish-out-of-water profession. Recently I was told by a programmer I deeply respect that my application can't work because I haven't defined what I want it to do. Of course, this is true, I've discussed what I want, but not *defined* it. What if the application: Recorded the patient's medical history. Recorded the patient's medical condition as of the day of the interview. Compared the patient's medical condition to a set of defined "syndromes". Summarized the day's findings and proposed a starting point for treatment. Recorded whether or not the treatment was given. Recorded the charges and payments. (probably can find existing code for this) On subsequent contacts, recorded the patient's reaction to treatment. Save all this in generic tables that impersonal research can be done on. Is this defining purpose, or must a definition take another form? -- Regards, Pete http://www.pete-theisen.com/ [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
