This is where I don't quite follow you. See below --- "A. Forrey" <[EMAIL PROTECTED]> wrote:
> This was exactly my point in the earlier exchanges about the role of > the > MDC and maintenance of the technical platform and infrastructure upon > > which VistA sits. > The users are the health professional disciplines Are they? The users of a language are those who design and implement software in that language. Health professionals, on the other hand, are users of the applications being developed. Nevertheless, the two are not completely independent: the choice of platform (including language) for a product is likely based in part on the application requirements. Does it require high performance? portability? distributed implementation? data sharing? real time behavior? a high level of security? > and > they need to know how the technical infrastructure is maintained > conformant to Common conventions. Yes, but WHAT needs to conform to these conventions? If a product requires SNOMED, but SNOMED isn't a supported vocabulary, then there is a problem. But this issue is rather different from whether the application is developed using MUMPS, Java or C, or even whether an RDBMS like MySQL is used to store the code set, or whether Fileman is used, instead. It's not that these choices are inconsequential, simply that they belong at a different level of abstraction. > They then can convey the Conceptual > > Content in the form of "Requirements" that are part of the Life Cycel > > Principles in ways that acknowledge the roles of the engineering > disciplines in the other processes of the Life Cycle. The MDC/MTA > forums > provided that mode of communication earlier; reactivation of a more > current environment will help each enterprise how this all works. > That > will benefit the future VistA Community. I agree with you here, though I'm not entirely certain I follow the rationale. Requirments are not monolithic, nor can layers of abstraction be treated in isolation. It is part of the job of analysts and developers to work through these issues. Neverthless, an error that I've seen repeated over and over is to confuse design issues with functional requirements. Users may say they need such and such a design, but that design may be ill-suited to their needs. More to the point, though, the use of a particular database product (or type of cabling) is simply not a functional issue. Saying that 80% of queries must be satisfied within 2 seconds and 99% of queries must be satisfied within 10 seconds is quite a different matter. Confusing the two often leads to poor design, and products that either cost more than anticipated, do not perform as anticipated, or both. > > On Wed, 24 Aug 2005, Aylesworth Marc A Ctr AFRL/IFSE wrote: > > > Yes, that is my point it needs input from people on both ends of > the > > process!!! Both the people it is being made for and the people that > are > > making it must have the same vision or expectations or what is > being created > > will not work. The users make a wish list and the engineer keeps it > > realistic. > > > > Thanks > > > > Marc Aylesworth > > > > C3I Associates > > > > AFRL/IFSE > > > > Joint Battlespace Infosphere Team > > > > 525 Brooks Rd > > > > Rome, NY 13441-4505 > > > > Tel:315.330.2422 > > > > Fax:315.330.7009 > > > > Email: [EMAIL PROTECTED] > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > Greg > > Woodhouse > > Sent: Wednesday, August 24, 2005 11:16 AM > > To: [email protected] > > Subject: RE: [Hardhats-members] MUMPS and VistA ( more M read > questions) > > > > My experience has been that users generally do not have a very > clear > > idea of what they want. What they DO know is what doesn't work for > them > > in what they have now. The users will often have some (maybe even > > mutually contradictory) ideas about what they do not, but when you > sit > > down with the users to look at this all systematically more issues > will > > arise, and they may even conclude that what they initially > requested > > isn't quite what they want, after all. Establishing functional > > requirements is usually a process, requiring significant input from > > both users and engineers. > > > > --- Aylesworth Marc A Ctr AFRL/IFSE <[EMAIL PROTECTED]> > wrote: > > > >> You should not get programming specs from a customer but should > get > >> general > >> functionality that is desired. The customer should say I want to > have > >> remote > >> clients that can do the same thing as local clients, or that I can > >> enter all > >> the information for a patient from a remote station, then we the > >> programmers > >> turn those general statements into specifications that are > realistic > >> in > >> terms of what they want in the time frame that it is desired. > Usually > >> doing > >> this in small increments makes both the customer and the > programmer > >> happy. > >> > >> Thanks > >> > >> Marc Aylesworth > >> > >> C3I Associates > >> > >> AFRL/IFSE > >> > >> Joint Battlespace Infosphere Team > >> > >> 525 Brooks Rd > >> > >> Rome, NY 13441-4505 > >> > >> Tel:315.330.2422 > >> > >> Fax:315.330.7009 > >> > >> Email: [EMAIL PROTECTED] > >> > >> > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> Ruben > >> Safir > >> Sent: Wednesday, August 24, 2005 9:36 AM > >> To: [email protected] > >> Subject: RE: [Hardhats-members] MUMPS and VistA ( more M read > >> questions) > >> > >> On Wed, 2005-08-24 at 09:12, Aylesworth Marc A Ctr AFRL/IFSE > wrote: > >>> I believe that what he means is that we actually talk to someone > >> who is > >>> going to use Vista, get the wish list then decide what is > feasible > >> in the > >>> given time and then do the work. > >> > >> I understand that, and that is exactly what is not a good idea. > >> > >> > >>> I believe that we need user involvement to > >>> ensure that we have something that actually does what is needed > and > >> to > >>> foster the feeling that users have a say in what a product does. > A > >> well > >>> thought out program is useless if it does not do what the user > >> wants. > >>> > >> > >> Have you ever tried to get a programming spec from a customer. > They > >> have no idea what they want, no idea what they need and no idea > what > >> can > >> be done (which is usually more than they ever imagined). > >> > >> What they are, however, is completely confused and snowed over by > >> cheap > >> marketing jargon from vendors playing word games to skew the > market > >> under the disguise of computer science and technological advances. > >> > >> That's why it is absolutely critical for a design team to vet user > >> input. > >> > >> Ruben > >> > >>> Thanks > >>> > >>> Marc Aylesworth > >>> > >>> C3I Associates > >>> > >>> AFRL/IFSE > >>> > >>> Joint Battlespace Infosphere Team > >>> > >>> 525 Brooks Rd > >>> > >>> Rome, NY 13441-4505 > >>> > >>> Tel:315.330.2422 > >>> > >>> Fax:315.330.7009 > >>> > >>> Email: [EMAIL PROTECTED] > >>> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On Behalf > Of > >> Ruben > >>> Safir > >>> Sent: Tuesday, August 23, 2005 2:24 PM > >>> To: [email protected] > >>> Subject: Re: [Hardhats-members] MUMPS and VistA ( more M read > >> questions) > >>> > >>> On Tue, 2005-08-23 at 09:55 -0700, A. Forrey wrote: > >>>> If the VistA Community is going to reach the rest of > >>>> the world it needs to tell them how it will deal with this > >> problem > >>>> and > >>>> then get on with it. > >>> > >>> Free Software projects just adapt to needs as developers precieve > >> them, > >>> which is frankly, a better idea than having development driven by > >>> healthcare providers who are working under many misconceptions > >> about the > >>> limitations and capabilities of software. > >>> > >>> It is important to have a map. It is important to have a group > and > >> a > >>> leader to vet out reasonable requests from the user community. > >>> Ultimately, the satisfaction of healthcare providers based on the > >>> performance of the WorldViSTA and Mumps products will be what > >> swings > >>> things. But letting the providers create the software map, that > >> might > >>> not be the best idea. > >>> > >>> Ruben > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> SF.Net email is Sponsored by the Better Software Conference & > EXPO > >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices > >>> Agile & Plan-Driven Development * Managing Projects & Teams * > >> Testing & QA > >>> Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >>> _______________________________________________ > >>> Hardhats-members mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/hardhats-members > >>> > >>> > >>> ------------------------------------------------------- > >>> SF.Net email is Sponsored by the Better Software Conference & > EXPO > >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices > >>> Agile & Plan-Driven Development * Managing Projects & Teams * > >> Testing & QA > >>> Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >>> _______________________________________________ > >>> Hardhats-members mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/hardhats-members > >> > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is Sponsored by the Better Software Conference & EXPO > >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices > >> Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > >> & QA > >> Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >> _______________________________________________ > >> Hardhats-members mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/hardhats-members > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is Sponsored by the Better Software Conference & EXPO > >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices > >> Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > >> & QA > >> Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >> _______________________________________________ > >> Hardhats-members mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/hardhats-members > >> > > > > > > > > === > > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Design quality doesn't ensure success, but design failure can > ensure > > failure." > > > > --Kent Beck > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
