Download - Analyse Des Besoins
-
8/22/2019 Analyse Des Besoins
1/60
Analyse des besoins
Pascal Staccini
-
8/22/2019 Analyse Des Besoins
2/60
PARTIE 1
Dveloppement
Cycle chronologique
Facteurs de risque
Echec des projets
10 risques majeurs dun projet
Incertitude des projets
Consquences des erreurs Cot des corrections
Conclusion
-
8/22/2019 Analyse Des Besoins
3/60
Cycle chronologique
Phase de planification Dfinir le problme
Produire le calendrier du projet
Confirmer la faisabilit du projet
Doter le projet en personnel Lancer le projet
Phase danalyse Recueillir et rassembler linformation
Dfinir les caractristiques du systme
Prioriser les caractristiques / spcifications
Btir des prototypes pour la faisabilit et la dcouverte desspcifications
Produire et valuer des solutions de rechange
Examiner les recommandations avec la direction
-
8/22/2019 Analyse Des Besoins
4/60
Cycle chronologique
Phase de conception Concevoir et intgrer le rseau
Concevoir larchitecture dapplication
Concevoir les interfaces utilisateur
Concevoir les interfaces systme
Concevoir et intgrer la base de donnes Faire un prototype des dtails de la conception
Concevoir et intgrer les contrles du systme
Phase de mise en uvre Construire les composantes logicielles
Vrifier et tester
Convertir les donnes Former les utilisateur et documenter le systme
Installer le systme
Phase de support Maintenir le systme
Amliorer le systme
Soutenir les utilisateurs
-
8/22/2019 Analyse Des Besoins
5/60
Facteurs de risque
replacer dans le contexte dvolution
organisationnelle qui simpose dsormais
aux tablissements :
rduire les cots ;
cibler la qualit de la relation avec le client ;
cibler la disponibilit des nouveaux outils,
standards et plates-formes ;
amliorer lefficacit de la dlivrance des
services aux utilisateurs.
-
8/22/2019 Analyse Des Besoins
6/60
Echec des projets
objectifs du projet :
le manque daccord sur un ensemble
d'objectifs bien articuls, des projets
excessivement ambitieux sont des obstaclesinternes entranant des risques plus levs et
des niveaux de complexit qui peuvent mettre
en chec des quipes mme comptentes ;
composition de l'quipe projet :
une quipe faible ou problmatique ;
-
8/22/2019 Analyse Des Besoins
7/60
Echec des projets
gestion et contrle du projet : la mauvaise gestion du projet, le manque de systme
d'valuation pour mesurer la progression et identifier les risquespotentiels temps pour les minimiser, et le manque deleadership responsable des prises de dcision diffrentes
phases du projet peuvent conduire lchec du projet ;
comptence technique : le niveau d'expertise, d'exprience et de connaissance du
domaine d'application de l'quipe travaillant sur le projet, tousrunis, sont insuffisants pour accomplir la tche, et en particulier
le manque de connaissance sur le recueil des besoins desutilisateurs et la production de lignes directrices concernant laconduite des activits de dveloppement des nouveauxsystmes ;
-
8/22/2019 Analyse Des Besoins
8/60
Echec des projets
infrastructure technologique : l'actuelle infrastructure technologique l'intrieur de
l'organisation n'a pas t value avant d'entreprendre le projet ;
implication des seniors :
la participation active de la direction dans la surveillance de laprogression du projet et dans la prise de dcisions desmoments cls est essentielle, mais elle a t dlgue auxexperts techniciens ou diffre ;
augmentation du cot et de la dure d'achvement :
ils sont symptomatiques de problmes srieux sous-jacents etdoivent attirer l'attention des seniors.
-
8/22/2019 Analyse Des Besoins
9/60
10 risques majeurs dun projet
Risques encourus et classement Mesures prventives
Ouvrage
Risque n3Dveloppement de logiciels
impropres satisfaire les besoins
Analyse de lorganisationAnalyse des missionsRevuePrototypageRdaction anticipe des manuels utilisateurs
Risque n4Dveloppement de mauvaises
interfaces pour les utilisateurs
Analyse des tchesPrototypagePrise en compte de lutilisateur (fonction,
comportement, charge de travail)
Risque n9Dfaillance des performances en
temps rel
SimulationEssais comparatifsModlisationPrototypageInstrumentationRglages
uvre
Risque n10Blocage sur les limites
technologiques des plates-formes
Analyse techniqueVrification a priorides performancesAnalyse des cots
Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.
-
8/22/2019 Analyse Des Besoins
10/60
10 risques majeurs dun projet
Risques encourus et classement Mesures prventives
RessourcesRisque n1Inaptitude du personnel
Structuration de lquipeRedistribution des rlesRenforcement de lencadrementFormation, entraide, motivation
Planification
Risque n2Prvisions trop optimistes, sous-estimation des budgets
Recoupement de plusieurs estimations dtailles des
charges, des cots et des planningsRemise en cause des demandesDveloppement incrmentalRutilisation de logiciel
Suivi
Risque n5Perfectionnisme
Examen critique des spcificationsPrototypageCalcul des retours sur investissement
Risque n6Contrat continu de modifications
Seuil dacceptation des changementsDveloppement incrmentalReport des modifications en fin de projet
Risque n7Dfaillance des fournitures externes
Mise en concurrenceContrle des rfrences
Analyse de compatibilitInspection et recette
Risque n8Dfaillances des travaux sous-traits
Contrle des rfrencesAudit de qualificationStructuration de lquipe
Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.
-
8/22/2019 Analyse Des Besoins
11/60
Incertitude des projets
Concevoir un systme dinformation efficace
suppose une connaissance prcise des modes
organisationnels des futurs utilisateurs, de leurs
besoins dinformation et des sourcesdisponibles.
Sur tous ces points, il ne peut y avoir ni certitude
ni exhaustivit. La conception des systmes
dinformation doit donc prendre en compte lecontexte dincertitude
-
8/22/2019 Analyse Des Besoins
12/60
Incertitude des projetsFacteurs situationnels, gnrateurs dincertitude
dus au systme dinformation
final attitude hostile des utilisateursfaible comptence des utilisateursinstabilit de lenvironnementdfaut de formalisation des informationsdfaut de formalisation des processusinstabilit des informations et des processuscaractre trop spcifique du systmeincomprhension des spcificationsimportance stratgique excessivelourdeur des changements organisationnelsindisponibilit, confusion, instabilit des exigences
dus au systme informatique importance des changements technologiquesnouveaut de la technologie cible
dus la technologie du projet
innovation technique, indisponibilit techniquedus la planification nouveaut de ladaptation, dlais trop courts,
budget serr
dus la structure du projet incomptence de lquipe projetdpendance de la sous-traitancedpendance envers dautres adaptations du systme
dinformationflou du contexte client-fournisseur
-
8/22/2019 Analyse Des Besoins
13/60
Incertitude des projets
Cinq sources principales dincertitude viennent affecterlefficacit des choix des concepteurs : les caractristiques de la tche effectuer, son degr de
structuration, les prescriptions auxquelles elle est soumise, ledegr de complexit que sa ralisation suppose ;
lestimation des ressources informatiques ncessaires,lanticipation de la performance utile ;
lexprience de lquipe charge de dvelopper le systme parrapport aux tches effectuer, sa stabilit, la possibilit derecours des consultants extrieurs ;
la capacit de lentreprise prendre des dcisions, les prioritsde la direction ;
lexprience des utilisateurs par rapport la ralisation de leurtche lutilisation des systmes dinformation.
Bernier C, Rivard S. Grer lincertitude dans le dveloppement des projets de systmes dinformation. Gestion, 2000, mai, 47-54.
-
8/22/2019 Analyse Des Besoins
14/60
Incertitude des projets
Limportance et le nombre de ces incertitudes
expliquent la fois le nombre lev des
checs, de 20 50% selon les sources et
celui des insatisfactions des utilisateurs, quiest au moins de 30%.
Bernier C, Rivard S. Grer lincertitude dans le dveloppement des projets de systmes dinformation. Gestion, 2000, mai, 47-54.Earl MJ. Experiences in strategic information systems planning, MIS Quarterly, 1993, 17, 1, 1-24.
Preedy D. The theory and practical use of executive information systems. International Journal of Information Management, 1990, 10, 2, 96-104.
-
8/22/2019 Analyse Des Besoins
15/60
Consquence des erreurs
Besoins des utilisateurs (phnomnes du monde rel)
Spcifications
correctes desbesoins
Spcifications errones
des besoins
Architecturecorrecte
Code correct
Fonctionscorrectes
Architecture errone
Erreurs de code
Erreurscorrigibles
Erreurs non corrigibles Erreurs caches
Code bas sur une
architecture errone
Code bas sur des
spcifications errones
Architecture base surdes spcifications
errones
Systmes logiciels imparfaits
Conception
Implmentation
Test
Expression des besoins
-
8/22/2019 Analyse Des Besoins
16/60
Cot des corrections
Activit Processus Cot relatif de rparation
Expression des besoins 0,1 0,2
Conception 0,5
Implmentation 1
Test 2
Exploitation 5
Maintenance 20
plus une erreur est dtecte tard dans le processus de dveloppement de
systmes logiciels, plus les corrections apporter sont coteuses
Boehm BW. Software Engineering. IEEE Transactions on Computers, 1976, 25, 12, 1226-1241.
-
8/22/2019 Analyse Des Besoins
17/60
En conclusion
Les projets russis ont privilgi de faon
stratgique :
Une dfinition claire des spcifications du
systme
Une forte implication des utilisateurs
Un appui de la Direction
Des plans minutieux et dtaills du projet
Un chancier de travail et jalons ralistes
-
8/22/2019 Analyse Des Besoins
18/60
En conclusion
Finalement, cette tude dtaille des risques dchec dun projet deSI laisse une part non ngligeable aux facteurs humains : mauvaise comprhension de lorganisation par les analystes,
implication mdiocre des utilisateurs finaux,
mauvaises apprciation et formalisation des besoins des utilisateurs.
Pour un SIH, et plus spcifiquement dans sa partie clinique, lessoignants et les mdecins sont les premiers concerns.
A la complexit dune organisation telle quun hpital, tant sur leplan structurel que sur le plan fonctionnel, sajoute limbrication, pasforcment complmentaire, de leurs besoins individuels avec ceuxdes groupes de mdecins et soignants, ceux de lorganisation etceux des patients.
Tous sont des utilisateurs potentiels du systme dinformationclinique, mais ne sont pas forcment reconnus comme tels.
Savoir faire le lien entre lorganisation et les utilisateurs semble treune des conditions de russite de la mise en uvre dun systmedinformation.
-
8/22/2019 Analyse Des Besoins
19/60
Impliquer les utilisateurs
Ds la phase de conception dun SI, du point de vue dudveloppeur, les besoins de tous les utilisateurs potentiels, donc dechaque utilisateur, doivent tre satisfaits.
Pour connatre ces besoins, il est ncessaire de disposer : de mthodes pour dcrire de faon pertinente, utile et utilisable les
profils des utilisateurs ;
de mthodes pour effectuer lanalyse des tches, lanalyse du systmeet des processus, non seulement pour les individus eux-mmes maisaussi pour les organisations dindividus ;
de mthodes rapides et faciles pour rcuprer, valuer et valider lesdonnes fournies par les utilisateurs ;
de mthodes fiables pour organiser les fonctions du systme en menus
et botes de dialogues selon les donnes des utilisateurs ; dapproches permettant de connatre et de comprendre le vocabulairedes utilisateurs.
Allen CD, Ballman D, Begg V, et al. User involvement in the design process : why, when and how ? In : Conference proceedings on Human factors in computing
systems. CHI93. Boston, MA: Addison-Wesley Longman Publishing Co., Inc., 1993.- pp. 251-254.
-
8/22/2019 Analyse Des Besoins
20/60
Impliquer les utilisateurs
Il est important de faire en sorte que ltape de designsoit participative, de faon ce que les utilisateurssortent de leur simple rle dobservateurs, de rpertoires de connaissances ou de simplescomposantes du systme, pour acqurir un rle dexpert
co-designers, de copropritaires, de contributeurs etdauto-souteneurs.
Comprendre les relations entre designers et utilisateurs,cest donc savoir ce quon entend pardesign centr surlutilisateur (user centered design). Cest une forme
de design qui dfinit les utilisateurs, ou les donnesgnres par ces utilisateurs, comme les critres aveclesquels un design est valu, ou bien comme la sourcegnratrice des ides de design.
Karat J, Atwood ME, Dray SM, et al. User Centered Design: Quality or Quackery? Conference proceedings on Human factors in computing systems. CHI96.
New York, NY: ACM Press, 1996.- pp. 161-162.
-
8/22/2019 Analyse Des Besoins
21/60
Impliquer les utilisateurs
attentes et les besoins des utilisateurs doivent tre apprcies dsles premires phases de conception : cette difficult est-elle ncessaire ? est souvent la meilleure
question possible ;
la difficult peut souvent tre contourne pour atteindre simplement lersultat ;
l'environnement ou la relation avec l'environnement peut tre modifi ; une personne ayant une vision globale, un point de vue nouveau, une
exprience diffrente peut rvaluer les solutions, au contraire d'unepersonne plonge dans son problme habituel ;
une sdimentation de paperasses, programmes informatiques,procdures, rglements, peut tre remplace par une solution la foissimple et adapte l'volution des besoins ;
poser constamment la question pourquoi ? peut dmanteler unproblme. Et surtout, il est possible de reculer d'un pas, et encore d'unpas, pour repenser en amont la difficult, la recadrer.
Gallivan MJ. Changes in the management of the information systems organization: an exploratory study. In: Proceedings of the computer personnel research
conference on Reinventing IS: managing information technology in changing organizations. SIGCPR. New York, NY: ACM Press, 1994.- p. 65-77.
-
8/22/2019 Analyse Des Besoins
22/60
Impliquer les acteurs de soins
Si la rgle dimplication des utilisateurs, ds laconception dun systme dinformation, est bien tablie,son application au domaine clinique souffre encore denombreuses difficults.
Pourtant, les contraintes de temps auxquelles sontsoumis les acteurs de soins sont connues.
Ainsi, une grande partie du travail des mdecinsconsiste rassembler, trier et classer lesinformations selon leur importance.
Les estimations donnes vont de 20% 70% du temps
Un travail du National Health Service (NHS) Informationfor Health Strategy, a estim quun quart du temps desmdecins et des infirmiers tait utilis pour la collectedes donnes et la recherche dinformations.
Metzger JB, Teich JM. Designing Acceptable Patient Care Information Systems. In: Patient Care Information Systems - Successful Design and Implementation.
New-York, NY: Springer-Verlag, 1996.- pp. 84-132.Burns F. Information for Health. An Information Strategy for the Modern NHS 1998-2005. Department of Health Publications, Wetherby 1998.
Disponible sur : < http://www.doh.gov.uk/ipu/ strategy/full/imt.pdf> (consult le 15.08.2002).
-
8/22/2019 Analyse Des Besoins
23/60
Impliquer les acteurs de soins
Les barrires l'utilisation des nouvelles technologies del'information au sein des systmes de prestations de soins sont plussociologiques, culturelles et organisationnelles que technologiques.
Deux facteurs freinent l'utilisation des technologies de l'information : La structure singulire du systme de soins fait que des demandes
extrmes sont formules quant aux performances des systmes
d'information. L'assurance dune meilleure qualit des donnes, qui pourrait tre la
base de toute utilisation des technologies de l'information pouramliorer l'efficacit et le rendement du systme de prestation dessoins, est bloque par labsence d'un centrage de l'ensemble dusystme sur l'amlioration des rsultats. Ceci a pour corollaire le faitque le recueil des donnes se fasse de faon inconsistante et disjointe.
Anderson JG. Clearing the way for physician's use of clinical information systems. Communications of the ACM, 1997, 40, 8, 83-90.
Collen MF. Health Care Information Systems: A Personal Historial Review. In: B.I. Blum, K. Duncan, (Eds.). A History of Medical Informatics. New-York, NJ:
ACM Press, 1990.- pp. 290-307.Hodges MH. History of the TDS Medical Information System. In: B.I. Blum, K. Duncan, (Eds). A History of Medical Informatics. New-York, NY: ACM Press,
1990.- pp. 328-356.
-
8/22/2019 Analyse Des Besoins
24/60
Origine des difficults
Considrations comportementales Ignorance des bnfices po tenti els
Il est une croyance rpandue que les mdecins sont rticents lutilisation de loutilinformatique
Comme raison de cette crainte, les changements de pratique induits par les nouvellestechnologies.
Les facteurs qui pourraient expliquer cette position sont le conservatisme intrinsque
des soignants, lanxit gnre par lignorance de cette technologie, labsence dunevision globale de la faon de lutiliser, et labsence de confiance dans la stabilit destechnologies de linformation applique aux soins.
Limpression dchec enregistre lvocation des projets de SIH, couple au cynismedes cliniciens sur la dfinition des priorits de traitement de linformation sontconsidrs par le NHS comme la principale difficult au dveloppement et limplantation de stratgies dinformation
Les cliniciens apprcient-ils le bnfice potentiel des technologies de linformation ? Ilapparat que non, et nous devons nous assurer que cette sensibilisation fait partie
intgrante de la conception et de limplmentation dun systme centr sur le patient. Une tude europenne (Eductra) a conclu que les professionnels de soins manquaientgnralement de connaissance quant aux possibilits et aux limites des systmesinformatiques.
-
8/22/2019 Analyse Des Besoins
25/60
Origine des difficults
Considrations comportementales Crainte du partage, de la perte dautonomie et du changement
La technologie est souvent dcrite comme un outil facilitant le partage dessoins.
Le manque de confiance entre les personnes est un obstacle pour atteindrecet objectif de soins partags. Ceci peut venir du fait que la formation desprofessionnels ne met pas assez en avant le travail pluriprofessionnel.
La crainte des systmes dinformation chez les professionnels de sant estlie un sentiment de perte dautonomie.
La crainte de multiples changements sur lesquels les mdecins ont peu decontrle peut tre un facteur de rejet des systmes dinformation. Ainsi, lecomportement des cliniciens et leur rsistance limplantation dapplicationscliniques pourrait-il expliquer le manque de succs des systmes en routine.
Cependant, contrairement une croyance, il ny a pas de rponse fixe et
attendue des mdecins, et les chercheurs sintressent particulirement auxdimensions comportementales.
La modlisation des processus dentreprise peut faciliter la spcification desaspects structurels et comportementaux au sein dun hpital. Lvolution descliniciens vers la gestion coordonne des soins et la matrise des cots, peutaussi tre un facteur de progrs.
-
8/22/2019 Analyse Des Besoins
26/60
Origine des difficults
Difficults lies lanalyse des besoins Incapac it id en ti fi er et dfi n ir les beso in s
Problme majeur qui a rarement t trait avec succs.
Bien que limportance de limplication des utilisateurs soit reconnue, la collecte et laformalisation des besoins des utilisateurs finaux ne sont pas bien dcrites et souventmme ngliges dans les projets de dveloppement logiciel.
Manque dtudes sur le type de support informatique ncessaire, sur la dterminationdes fonctions, dont lautomatisation bnficiera plutt aux mdecins, et sur les raisonsde lchec court terme des systmes.
Le manque de succs des premiers systmes de saisie de prescriptions ou de retourdes rsultats auprs des cliniciens semble d au fait quils avaient dabord t conuspour rpondre des besoins de gestion financire.
Ceci a permis de mettre en lumire limportance dune conception guide par lacomprhension dtaille des processus de soins du patient, et non dune conceptionguide par lanalyse spare des tches individuelles par mtier.
Une autre raison de lchec des SI tre intgrs dans la pratique mdicale
quotidienne est quaucune analyse cible na t faite sur les besoins en informationdes mdecins.
Le dveloppement de linformatique mdicale a t domin par des considrationstechnologiques. Le personnel mdical est peu outill pour dcrire de tels besoins, alorsquil est daccord sur la manire de dlivrer les soins au patient. La tche didentificationdes besoins des utilisateurs doit tenir compte de cela.
-
8/22/2019 Analyse Des Besoins
27/60
Origine des difficults
Difficults lies lanalyse des besoins Non prise en compte de lorganisation du travail
Les systmes ne peuvent pas tre dvelopps sans prendre enconsidration lenvironnement dans lequel ils devront fonctionner.Ceci est particulirement vrai pour les systmes cliniques o la
tendance croissante est celle dun environnement de soinspartags.
Il y a une croyance de plus en plus rpandue selon laquelle lasolution au problme dune bonne informatisation de la pratiqueclinique repose plus sur des ralits politiques que technologiques.
Les rsultats dune tude pour dterminer les raisons qui font quun
SIC russit ou choue, ont rvl que lexcellence ou non dusystme technique informatique navait quune importancerelativement faible. Lensemble du SIC doit en effet intressertoutes les structures participant aux processus cliniques, et leursacteurs.
-
8/22/2019 Analyse Des Besoins
28/60
Origine des difficults
Considrations mthodologiques Incapac it fai re c orrespondre modles de t ravail et
processus c l in iques Quelles que soient les avances offertes par les systmes
dinformation cliniques, ils reprsentent encore un changementdans la faon de travailler en pratique clinique.
Aussi le systme ne doit-il pas seulement permettre une meilleuresaisie ou une meilleure recherche de donnes mais doit galementcorrespondre aux processus ou aux situations de soins en courspour un patient.
Lintgration dans les pratiques de travail reste linquitude majeuredes cliniciens.
Linformatisation des donnes mdicales doit encore progresserpour paratre encore plus naturelle aux cliniciens.
Persistance de lopposition entre la saisie contrle de donnes, quifacilite le travail informatique, et lentre de donnes en texte libre,qui correspond mieux lutilisateur.
-
8/22/2019 Analyse Des Besoins
29/60
Origine des difficults
Considrations mthodologiques Conception du systme, dmarche dimplmentation
Une dmarche de conception et dimplmentation prenant en considrationle couple clinicien / patient dtermine le succs ou lchec du projet.
le grand dfi pour la prochaine dcennie est de construire des ordinateursqui vous connaissent, qui apprennent vos besoins, qui comprennent lalangue orale et crite [Nous avons besoin dordinateurs qui] ont uneintelligence de telle faon faire quasiment disparatre linterface physique.Cest l que se trouve le secret de la conception des interfaces : les fairedisparatre (Ngroponte)
Trs peu de systmes rpondent cet idal et il peut tre opportundamliorer les dmarches de conception et dimplmentation.
Les stratgies de formation doivent tre centres sur le dveloppement long terme dune culture de linformation, et non, comme par le pass, sur la
formation court terme faite simplement pour permettre aux gens dutiliserles systmes.
nous devons concevoir des systmes autour des patients et non autour dela technologie. Nous devons parler de serveurs patients et non de clientsserveurs . (Safran)
-
8/22/2019 Analyse Des Besoins
30/60
Origine des difficults
Considrations technologiques Il existe des preuves qui soutiennent le fait que la technologie, en elle-
mme, nest pas un facteur limitant prpondrant. Cependant, certainsauteurs pensent quil existe un srieux point de divergence, en sant,entre les besoins de lorganisation et les solutions techniques qui lessupportent.
Les consquences de cet tat de fait sont que : les technologies de linformation ne sont pas le noyau oprationnel en sant les pressions organisationnelles et les pressions externes laissent latechnologie loin derrire elles ;
la refonte des processus dentreprise devient plus courante, mais ninclutpas toujours les technologies de linformation ;
les technologies de linformation en sant sont encore des cas dcole etrestent abstraites dans la pense des acheteurs et des professionnels ;
le profil des affaires ne correspond pas au profil informationnel, et ces deuxsont eux-mmes assez diffrents du profil technologique ;
le secteur industriel lui-mme est aussi lent au changement.
-
8/22/2019 Analyse Des Besoins
31/60
Reconnatre lacteur de soins
Prrequis limplmentation des systmes centrs sur les patients Propositions pour amliorer limplication des cliniciens pour arriver finalement
une perception relle et gnralise des bnfices des SI : la reconnaissance par les gestionnaires de soins de limportance dune technologie de
linformation centre sur les patient pour le futur des services de soins ;
la ncessit de ne pas mconnatre limplication des mdecins, le besoin de traiter lesproblmes de faon honnte et transparente, dautant que les cliniciens ont la rellevolont dutiliser les technologies de linformation pour la dlivrance des soins ;
le besoin de faire en sorte que les dveloppeurs comprennent les problmes cls delinformatique mdicale en travaillant troitement avec les cliniciens ;
lutilit de former les cliniciens aux avantages et aux inconvnients des techniquesinformatiques ;
le fait de traiter les problmes qui concernent les cliniciens avec eux, comme parexemple la scurit des accs aux donnes confidentielles du patient ;
limportance de reconnatre linvestissement des cliniciens participant audveloppement des projets et de mettre en avant les leaders mdicaux : leur implication
aidera promouvoir lappropriation et lengagement dans le processusdimplmentation ;
le fait daccepter que la technologie ne soit quun facteur parmi dautres. Les facteurscritiques pour le succs dun systme sont limplication des gens, le fait quelorganisation soit prte accepter le changement et la gestion de ce processus dechangement.
-
8/22/2019 Analyse Des Besoins
32/60
Reconnatre lacteur de soins
Analyse des besoins des utilisateurs du domaine de la sant Le travail dun professionnel de sant est caractris comme :
1) tant un processus dirig par le problme ;
2) impliquant la conduite de multiples tches concurrentes ;
3) ncessitant une interaction avec plusieurs sources et ciblesinformationnelles (certaines humaines, dautres informatises) ;
4) tant sujet de frquentes modifications, rsultant dactions desurveillance, de changements dobjectifs, ou de rvision de la stratgie.
La plupart des applications ont t cibles pour fournir un supportvertical des tches spcifiques, voire isoles.
Alors que ces applications ont inclus des fonctions commelinterrogation de donnes cliniques, laide la dcision, lducation et lacommunication, elles ont gnralement t ralises de faon isole,
sans tre relies les unes aux autres, pour satisfaire les situations dersolution de problme multidisciplinaires et pluriprofessionnellesrencontres dans la pratique mdicale actuelle.
-
8/22/2019 Analyse Des Besoins
33/60
Systme multi-utilisateurs
Problmes rencontrs au cours de la phase de design dun systme multi-utilisateurs sont pour lessentiel : la concurrence : plusieurs personnes ont besoin de la mme information ou
ressource (station de travail, par exemple) au mme moment ;
la dpendance temps-personne: linformation fournie une personne nestpas disponible quand elle est demande par une autre personne (de faonanalogue, une tche effectue par une personne dpend dune autre tche
effectue par une autre personne qui ne la pas encore acheve) ; la dpendance temps-lieu: linformation nest pas disponible lendroit
souhait, au moment souhait ;
la mauvaise diffrenciation des rles: dun point de vue informationnel, lesfonctions du systme sont adaptes, mais lorganisation des fonctions en termesde qui ralise des tches particulires nest pas adquate ;
lchec dans lidentification de tous les participants dune tche : le designdu systme, alors quil accommode les principaux rles dune tche, ne prendpas en compte le rle des autres personnes qui interviennent occasionnellement(gnralement pour apporter de laide) ;
le manque danalyse raisonne: aucune analyse des pratiques de travail nestralise.
-
8/22/2019 Analyse Des Besoins
34/60
Systme multi-utilisateurs
Linformation ncessaire au designdun systme collaboratif doitrpondre aux huit questions suivantes : quelle est la tche ? identifie le but du travail ;
pourquoi est-elle ralise ? permet de distinguer les pratiques detravail critiques pour accomplir lobjectif de celles qui ne le sont pas ;
qui effectue cette tche ? facilite la dtermination des rles ;
comment est-elle ralise ? spcifie le dtail du travail dunindividu ;
quand est-elle ralise ? identifie les dpendances dans le temps etles concurrences ;
avec quoi est-elle ralise ? identifie linformation et les procduresncessaires, value la concurrence des ressources ;
o est-elle ralise ? identifie les dpendances et les concurrencestemps-lieu ;
que se passe-t-il ensuite ? identifie les concurrences pour lespersonnes et linformation.
-
8/22/2019 Analyse Des Besoins
35/60
Systme multi-utilisateurs
Les dtails des pratiques de travail contenusdans les rponses aux questions prcdentespeuvent tre utiliss pour crer desreprsentations, au niveau de lorganisation, qui
se rapportent des interactions telles que : de qui ou de quoi dpend la tche ?
qui ou quoi dpend de cette tche ?
qui dautre a besoin des ressources utilises pour
cette tche, ce moment-l ? comment les pratiques de travail dcrites contribuent-
elles aux objectifs de lorganisation ?
-
8/22/2019 Analyse Des Besoins
36/60
En conclusion
Une large implication des mdecins dansla slection et limplmentation dusystme est essentielle. Les systmes
sans rel soutien de la part du personnelmdical sont promis lchec. Une desmeilleures stratgies est de sassurer delassistance de mdecins influents pour
encourager dautres membres dupersonnel mdical utiliser le systmedans leur pratique.
-
8/22/2019 Analyse Des Besoins
37/60
En conclusion
Considrer lavance la faon dont le systme
qui va tre introduit va affecter les modes de
pratique et les relations professionnelles. Il est
important didentifier les bnfices spcifiquesque le SI apporte aux individus et aux groupes
professionnels. Les mdecins utiliseront le SI sil
les aide mieux prendre en charge les patients.
Les bnfices pour lorganisation en gnral nemotiveront pas les mdecins changer leurs
habitudes de travail.
-
8/22/2019 Analyse Des Besoins
38/60
En conclusion
Les tablissements de sant doivent anticiper et grerles changements de comportements et dorganisationinduits par lintroduction dun SIC intgr. Si ceschangements, qui ont t montrs comme inhibiteurs deladoption et de lutilisation des systmes informatiss,
sont ignors, on peut sattendre un chec du systmeou des effets fortuits. Ces problmes peuvent trevits ou diminus en anticipant la faon dont lesgroupes professionnels vont percevoir un nouveau SI.La communication dans les groupes concerns parlimplmentation du systme est un moyen didentifier etde rsoudre des problmes potentiels qui, sils restentnon rsolus, peuvent contrarier lacceptation etlutilisation du systme.
-
8/22/2019 Analyse Des Besoins
39/60
Recueillir linformation
Durant la phase danalyse, collecte dune trs grandequantit dinformations auprs des personnes qui utiliseront le systme
Soit en les interviewant
Soit en les regardant travailler
en lisant les documents de planification, les procdures, lesexposs de principes, la documentation du systme existant
en regardant ce qui a t fait dans dautres entreprises pourrpondre un besoin semblable (benchmarking)
parler toutes les personnes qui se serviront dusystme ou ont utilis un systme similaire, lire tout cequi existe sur le systme actuel
-
8/22/2019 Analyse Des Besoins
40/60
Recueillir linformation
Lanalyste doit devenir un expert du domaine que lesystme supportera
Lanalyse doit aussi recueillir de linformation techniquepour comprendre le systme existant : En identifiant et en comprenant les activits de tous les
utilisateurs prsents et venir En identifiant tous les lieux actuels et futurs o le travail
seffectue
En identifiant toutes les interfaces dautres systmes lintrieur comme lextrieur de lorganisation
la question essentielle : est-ce que nous avons toutelinformation (et la connaissance) dont nous avonsbesoin pour dfinir ce que le systme doit faire ? Pourqui, pourquoi, quand et comment ?
-
8/22/2019 Analyse Des Besoins
41/60
Prioriser les spcifications
Etablir quelles sont les spcifications fonctionnelles ettechniques vitales pour le systme
Les utilisateurs proposent beaucoup de fonctionnalitssouhaitables / souhaites mais pas essentielles
Utilisateurs et analystes doivent se demander ensemblequelles sont les fonctions vitales et celles importancesmais non requises
La priorisation est ncessaire car les ressources sontlimites et un champ de spcifications qui augmente mesure que les utilisateurs font des suggestions devient
un risque dchec du projet quelles sont les choses importantes que le systme
doit faire
-
8/22/2019 Analyse Des Besoins
42/60
Pour un SIH ?
Un analyste peut-il tre tranger audispositif mtier ?
Sa connaissance ne peut-elle tre
quextrieure ? En quoi une expertise mtier est-elle
ncessaire ?
La plupart des analystes consultants desSIH sont issus des mtiers de lhpital,MAIS
-
8/22/2019 Analyse Des Besoins
43/60
Les intervenants
Dfinition : toutes les personnes qui sontconcernes par la russite du nouveausystme
Quatre catgories :
Les utilisateurs, soit ceux qui utilisent le systme tousles jours
Les clients, soit ceux qui paient pour le systme et ensont propritaires
Le personnel technique, soit les personnes qui sont
responsables du fonctionnement du systme danslenvironnement de lorganisation
Les entits extrieures, tels les clients delorganisation
-
8/22/2019 Analyse Des Besoins
44/60
Mthodes de cueillette
Distribuer les
questionnaires
Interviewer les
utilisateurs
Etudier la
documentation
existante
Observer les
procds
administratifs
Rechercher des
solutions auprs de
fournisseurs
Comprendre les
contraintes du
nouveau systme
Comprendre les
procdures du
nouveau systme
Comprendre les
fonctions du nouveausystme
Dvelopper les
spcifications et les
modles pour le
nouveau systme
-
8/22/2019 Analyse Des Besoins
45/60
Thmes de la cueillette
Thme Questions aux utilisateurs
Quels sont les oprations et les
procds administratifs
Que faites-vous ?
Comment ces oprations doivent-elles
seffectuer ?
Comment le faites-vous ?
Quelle dmarche suivez-vous ?
Quelles informations faut-il pourraliser ces oprations ?
Quelles informations utilisez-vous ?
Quels formulaires ou rapports utilisez-
vous ?
-
8/22/2019 Analyse Des Besoins
46/60
Techniques de cueillette
Examiner les rapports, formulaires et descriptions deprocdures existantes
Animer des entrevues et des discussion avec lesutilisateurs
Observer et documenter les procds administratifs Construire des prototypes
Distribuer et ramasser des questionnaires
Animer des sances de dveloppement conjoint
dapplications Etudier des solutions proposes par des fournisseurs
-
8/22/2019 Analyse Des Besoins
47/60
Expression des besoins
processus dexpression des besoins dfinit les trois activits suivantes : lactivit dacquisition des besoins : cette activit, galement appele
identification des besoins, ou analyse du problme, ou bien recueil des besoins,ou encore documentation des besoins, consiste collecter sous forme informellelensemble des besoins qui permettront datteindre une bonne comprhension dusystme. Cest lactivit durant laquelle lingnieur des besoins dcouvre, corrige,articule, et comprend les besoins.
lactivit de conceptualisation des besoins : cette activit, galement appelespcification des besoins, ou description du produit, ou bien formalisation desbesoins, ou encore expression des besoins, consiste exprimer les besoinsacquis lissue de ltape prcdente, laide dun formalisme intgrant uncertain nombre de concepts graphiques et/ou mathmatiques.
lactivit de validation des besoins : cette activit, galement appele analysedu problme et des besoins, ou analyse et validation des besoins, ou bienvalidation des besoins, ou encore discussion des besoins, consiste sassurer
que les besoins conceptualiss traduisent de manire complte et cohrente lesdsirs, les contraintes, et les volonts du client.
-
8/22/2019 Analyse Des Besoins
48/60
Problmatique
des problmes de dimensionnement, pour lesquels les exigencespeuvent concerner trop peu ou beaucoup trop dinformation : les limites du systme sont mal dfinies,
des informations non ncessaires pour la conception sont donnes.
des problmes de comprhensionaussi bien lintrieur dungroupe quentre groupes dutilisateurs ou de dveloppeurs : les utilisateurs ont une comprhension incomplte de leurs besoins, les utilisateurs ont peu de connaissance sur les possibilits et les limites
des systmes informatiques,
les analystes ont une connaissance trs faible du domaine dintrt,
utilisateurs et analystes sexpriment dans des langages diffrents,
il est facile domettre des informations videntes,
il existe des vues conflictuelles entre diffrents utilisateurs, les besoins exprims sont souvent vagues et peu vrifiables.
des problmes dinconstance et dvolution des besoins avec letemps.
-
8/22/2019 Analyse Des Besoins
49/60
Guide
Questions Objets Exemples
quels documents sont utiliss dans le systme ? document questionnaires, instructions, rapports, produits intermdiaires,
manuel de rfrences, etc.
qui / quoi reoit le document ? destinataire client, membre du personnel, dpartement de lentreprise,
organisation extrieure, etc.
qui / quoi labore le document ? crateur employs, fournisseurs, quipement comme les ordinateurs, etc.
quelles sont les ressources utilises pour laborer le
document ?
ressource argent, matire premire, documents de rfrence
quels sont les vnements lorigine de la cration du
document ?
vnement arrive du moment de la paie mensuelle, arrive dune commande
de client
Questions Caractristiques dcrites
quelles sont les diffrentes parties du document ?quels sont les lments de base de lobjet ?
attributs
que fait le crateur ou le destinataire avec les items du document ? mthodes
comment fait la ressource ou lvnement pour fournir linformation
pour crer le document ?
mthodes
que fait le destinataire pour accepter le document ? mthodes
que fait le crateur pour fournir le document ? mthodes
-
8/22/2019 Analyse Des Besoins
50/60
Jeux de rles
Gestion de son compte bancaire par
Internet
Quels intervenants ?
Quelles questions ?
Gestion de son compte sant par
Internet
Quels intervenants ?
Quelles questions ?
-
8/22/2019 Analyse Des Besoins
51/60
Question
Lun des problmes les plus ardus de
linvestigation des spcifications dun
systme est de sassurer quelles sont
compltes et dtailles. Que feriez-vouspour vous garantir dobtenir toutes les
bonnes informations lors dune entrevue ?
-
8/22/2019 Analyse Des Besoins
52/60
Rponse
Les rponses devraient inclure les points suivants : Sassurer davoir identifi tous les intervenants et de les avoir
inclus dans les activits de dfinition des spcifications.
Examiner tous les formulaires et rapports existants pour vrifierque tous les besoins dinformation sont compris.
Identifier et comprendre chaque activit de gestion. Sassurerque toutes les procdures administratives ont t discutes.
Sassurer que toutes les conditions dexception ont tidentifies et leurs champs associs dfinis.
Maintenir une liste des articles ouverts et sassurer que tous les
lments sont rsolus.
-
8/22/2019 Analyse Des Besoins
53/60
Question
Que pouvez-vous faire pour tre certain
davoir inclus tous les bons intervenants
sur votre liste de personnes interroger ?
-
8/22/2019 Analyse Des Besoins
54/60
Rponse
Une mthode consiste obtenir, ou au besoinconstruire, un organigramme de lentreprise.
Cela facilitera lidentification de tous les intervenantspotentiels. Le sous-ensemble de lorganigramme qui
contient les intervenants ncessaires peut tre cr enfonction de la porte du systme.
Il y a plusieurs faons de vrifier votre liste : (1) la revoir avec le client principal (le groupe qui assure
lapprobation et le financement du projet);
(2) la vrifier avec le comit de surveillance du projet; (3) la revoir avec le chef du groupe des systmes dinformation
ou avec toute autre personne qui matrise bien les systmes.
-
8/22/2019 Analyse Des Besoins
55/60
Question
Un des problmes communs lors duneinvestigation est le glissement de la portedu systme, cest--dire des demandes defonctions additionnelles de la part des
utilisateurs. Ce glissement survient parce quilarrive que les utilisateurs aient de nombreuxproblmes non rsolus et que cette investigationreprsente peut-tre pour eux la premireoccasion de se faire entendre. Que devez-vous
faire pour empcher que le systme grossisse etcomprenne des fonctions qui ne devraient pasen faire partie ?
-
8/22/2019 Analyse Des Besoins
56/60
Rponse
Ce problme est essentiellement une question de gestion de projet. Le chefde projet devrait tablir des lignes directrices pour le contrler.
Une mthode prventive consiste sassurer que la dfinition initiale de laporte est convenable et complte. Une dfinition incomplte exacerbera leproblme de glissement de la porte.
Si la porte du systme a t dfinie adquatement au dpart, une faon dergler le problme de glissement est de mettre sur pied un comit form demembres de lquipe de projet et dutilisateurs ou de clients qui devraapprouver tout nouvel ajout la porte du systme. Avant approbation, ilfaudra faire une valuation pour dterminer la pertinence et limportance dela demande et son effet sur le calendrier du projet. Demandez laparticipation des utilisateurs la dcision afin que celle-ci soit une dcisionconjointe et non un diktat du chef de projet.
Une autre technique consiste commencer une liste des amliorations pourla prochaine version du systme. Certaines demandes peuvent en effet trereportes une version ultrieure.
-
8/22/2019 Analyse Des Besoins
57/60
Question
Que feriez-vous si deux personnes vous
donnaient des rponses contradictoires
sur une mme procdure ? Que feriez-
vous si lune des personnes tait membredu personnel de bureau et que lautre tait
son chef de service ?
-
8/22/2019 Analyse Des Besoins
58/60
Rponse
La premire raction serait de considrer lopinion duchef de service comme tant la bonne rponse.
Toutefois, il est assez frquent quun chef de service nesoit pas au courant des derniers dtails de certaines
procdures de gestion. La meilleure solution, dans ce cas, consiste runir
deux personnes et les laisser discuter jusqu ce quellessentendent sur la bonne procdure.
Il importe que la dcision ne vienne pas de lanalyste.
Il est aussi important de ne pas essayer de rsoudre lesdivergences vous-mmes : cela incombe lutilisateur.
-
8/22/2019 Analyse Des Besoins
59/60
Question
On vous a donn la responsabilit de
rsoudre plusieurs problmes en suspens
et vous prouvez des difficults obtenir
des dcision stratgiques de la part devotre contact. Comment pouvez-vous
encourager lutilisateur finaliser ces
dcisions ?
-
8/22/2019 Analyse Des Besoins
60/60
Rponse
Une question dopinion pineuse qui offre plusieurs rponses. En rgle gnrale, les retards prendre des dcisions stratgiques
ont des effets importants sur le calendrier dun projet et il arrive quelutilisateur ne comprenne pas ces impacts.
La premire approche devrait donc tre dexpliquer leffet ngatifquune dcision donne peut avoir sur le projet.
Si cela ne fonctionne pas, il est possible de prendre des mesuresplus radicales, comme suggrer que le comit de surveillance duprojet examine la liste des questions en suspens.
De plus, si cette liste inclut une indication de la dure pendantlaquelle des lment ont t ouverts, il est possible dattribuer unepriorit (ou daugmenter la priorit) des lments qui deviennent
critiques.