Analyse Des Besoins

8/22/2019 Analyse Des Besoins

1/60

Analyse des besoins

Pascal Staccini


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


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


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


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.


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 ;


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/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.


9/60


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.


10/60


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.


11/60


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


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


13/60


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.


14/60


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.


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


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.


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


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.


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.


20/60


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.


21/60


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.


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).


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.


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.


25/60


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.


26/60


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.


27/60


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.


28/60


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.


29/60


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)


30/60


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.


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.


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.


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.


34/60


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.


35/60


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 ?


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.


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.


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.


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


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 ?


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


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


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


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


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 ?


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


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.


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.


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


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 ?


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 ?


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.


53/60

Question

Que pouvez-vous faire pour tre certain

davoir inclus tous les bons intervenants

sur votre liste de personnes interroger ?


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.


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 ?


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.


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 ?


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.


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 ?


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.

Analyse Des Besoins

Documents

Transcript of Analyse Des Besoins