On Wed, 24 Aug 2005, Greg Woodhouse wrote:
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?
In the end, the users (of the implemented architecture of a M-based
system for healthcare) are the health professional disciplines but they
may have a diffferent range of mastery in different enterprises. They need
some level of appreciation what that infrastructure will do for them. To
the extent that they have such mastery they can communicate what behavior
they want the system to have and what it will do for them. That aids the
Requirements Engineer - RE (who ever has that role).
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?
Those are elements of the intercommunication during Requirements
Refinition; each enterprise will differ in details.
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.
The dialog woulkd include both the conceptual aspects of SNOMED as well as
the technical details of the present and desired architecture that leads
to system behavior that supports the defined cognitive processing of the
end user.
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.
The various technical options that may change the end result are part of
the dialog leading to requirements.
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.
In a effective situation the RE can control the nature of the dialog but
it is the confidence in robust two way dialog that will enable economic,
effective exchange of information about the Conceptual Content needs that
msut be part of the Requirements that will enable the engineering team to
create the needed behavior. The Life Cycle Model of protoyping, or
iterative dvelopement, has been and can also be used to get convergence.
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.
The general principles for best practices in any information system
engineering project can be applied to the M environment but the way these
principlkes and practices are applied may have a different form that in
another infrastructure. Both parties need education about how to go about
this. It was done and still can be well done within the M and
VistA Community; we just need to conscipusly work at it and try to improve
it as it wont come without work.
>> 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: hardhats-members@lists.sourceforge.net
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: hardhats-members@lists.sourceforge.net
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: hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
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
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
