HPITAL NUMRIQUE COMMENT RUSSIR LEXPRESSION DE MON BESOIN

« HÔPITAL NUMÉRIQUE » COMMENT RÉUSSIR L’EXPRESSION DE MON BESOIN Agence Nationale d’Appui à la Performance des établissements de santé et médico-sociaux

Objectifs de la session A l’issue de cette session, vous serez capables de : 1. Savoir poser les bases du projet d’expression des besoins 2. Maitriser le processus d’expression des besoins (transition entre les étapes, checklist, les 4 étapes : recueil, analyse, spécification et validation) 3. Appréhender l’exhaustivité d’un cahier des charges et la nécessité de le structurer 4. Savoir formuler les exigences fonctionnelles, non fonctionnelles et les contraintes 5. Comprendre les enjeux associés aux exigences non-fonctionnelles 6. Savoir établir les exigences non fonctionnelles 7. Savoir vérifier si les objectifs ont été définis, les parties prenantes identifiées et le contexte décrit. 8. Savoir établir un diagnostic sur la structure retenue par le cahier des charges, le processus retenu pour l’élaboration des éléments du cahier des charges, la correcte application des 5 C à la formulation des exigences 9. Savoir sensibiliser aux bonnes pratiques en matière de rédaction des exigences non-fonctionnelles 2

Agenda 1. Introduction 2. Les bases d’un cahier des charges 3. Les démarches d’élaboration d’un cahier des charges 4. La structure d’un cahier des charges 5. La formulation des exigences 6. Ambassadeurs, êtes-vous prêts? 7. Conclusion 3

Les bases d’un cahier des charges Objectif Périmètre Parties prenantes 4

Les enjeux d’un cahier des charges • Un net retour sur investissement en raison des coûts financier relatifs à la correction: − − − Des exigences De la conception De la réalisation Des tests De l’exploitation • De bonnes spécifications initiales permettent de motiver et d’encourager les utilisateurs − Démarche collaborative de recueil, spécification et validation des besoins − Réflexion collective sur l’impact de la mise en œuvre d’un nouveau système sur les processus actuels • L’élaboration d’un cahier des charges favorise un travail d’équipe soudé autour d’un projet commun ce qui facilite son déploiement et la conduite du changement 5

Les enjeux : estimations de chiffres • Diminution des coûts d’élaboration − Charge de travail interne diminuée de moitié − Coût de conseil externe (assistance à la maîtrise d’ouvrage) diminué de moitié (au moins !) • Diminution des délais d’élaboration − Gain estimé à 30 % en délais • Diminution drastique des risques liés à un mauvais choix de logiciel − − Appel d’offres clair et rigoureux Réponse des candidats plus claire et précise Contrat bien ficelé Risque de contentieux réduit 6

Agenda 1. Introduction 2. Les bases d’un cahier des charges 3. Les démarches d’élaboration d’un cahier des charges 4. La structure d’un cahier des charges 5. La formulation des exigences 6. Ambassadeurs, êtes-vous prêts? 7. Conclusion 7

Niveaux d’exigence Objectifs Contexte, parties prenantes Règles métier Cas d’utilisation Exigences élémentaires 8

Les étapes de l’élaboration Recueil Analyse Spécification Validation • Documentation • Interviews • Groupes de travail • Réutilisation • Priorisation • Cohérence • Formulation • Structuration • Relecture • Validation formelle 9

L’élaboration en pratique Recueil Validation Analyse Spécification 10

Le plan projet Planifier Déterminer les objectifs Cadrer Plan projet 11

Agenda 1. Introduction 2. Les bases d’un cahier des charges 3. Les démarches d’élaboration d’un cahier des charges 4. La structure d’un cahier des charges 5. La formulation des exigences 6. Ambassadeurs, êtes-vous prêts? 7. Conclusion 12

Les grandes parties d’un cahier des charges Exigences fonctionnelles Objectif Exigences sur la qualité du produit Contraintes 13

Les différents outils ANAP Guide de pilotage • Le projet global d’acquisition • Indications très générales Guide d’élaboration d’un cahier des charges • Les principes, les règles • L’élaboration pas à pas Cahiers des chargestypes • Exemple typique couvrant 90% des cas • Texte d’autodocumentation (en bleu) 14

Le cahier des charges type • Les différents cahiers des charges − − − − Le circuit du médicament La gestion des rendez-vous La planification avancée (dont brancardage) La gestion des lits Le dossier médical Le dossier de soins paramédical Les demandes et résultats d'examens • Points d’attention : − Propositions mentionnées dans ces exemples-type − Objectifs et contexte − Cas d’utilisation 15

Focus : contexte et objectifs dans le cahier des charges type Concept et objectifs Cahier des chargestype 1. Finalité du projet 2. Parties prenantes 3. Contraintes externes 4. Conventions 5. Faits et hypothèses 16

Les cas d’utilisation : quoi et comment Un cas d’utilisation − se rapporte à un objectif et un seul. − décrit un comportement utile à l’atteinte de cet objectif. − prend le point de vue d’une partie prenante. − comporte un acteur principal et un seul. − débute avec un événement déclencheur. − se poursuit jusqu’à ce que l’objectif soit atteint ou abandonné. 17

Cas d’utilisation : structure − Nom du C. U. − Acteur principal − Autres parties prenantes − Description − Préconditions − Garanties minimales − Garanties en cas de succès − Flux normal − Flux alternatif − Cas inclus − Fréquence d’utilisation 18

Les C. U. dans les cahiers des charges-types : règles à respecter • • Un cas d’utilisation est très facile à lire, mais difficile à écrire Les C. U. des cahiers des charges-types répondent à 90 % des besoins des ES Un ES peut les enrichir, les adapter, les affiner, mais l’exercice n’est pas trivial Un ES peut créer ses propres C. U. sachant que c’est un travail de professionnel • Pour chaque C. U. créé, modifié ou enrichi, respecter les règles suivantes − − − Travailler en équipe Idéalement, groupe de 3 personnes de disciplines différentes Respecter les règles d’écriture (voir « quoi et comment » ) Faire relire par une personne extérieure au groupe Faire valider par un représentant de l’acteur principal concerné • Exemple : pour modifier en profondeur le C. U. « prescrire » − Un médecin avec un pharmacien et un cadre de santé − Relu par un autre médecin, pharmacien ou cadre de santé, ou par un consultant extérieur − Validé par un troisième médecin 19

Cas d’utilisation : exemple d’un flux normal pour le CU « prescrire » • Le prescripteur sélectionne dans la liste des patients de l’unité de responsabilité médicale le patient pour lequel une prescription doit être faite. • Le prescripteur saisit un élément de prescription autant de fois que nécessaire. • [saisir un élément de prescription est un cas inclus]. • Le système contrôle les posologies et les interactions médicamenteuses en interrogeant la base médicamenteuse. • Le système contrôle les interactions physiopathologiques. • Le système signale les éventuelles interactions et signale les éventuelles anomalies. • En cas d’anomalie, le prescripteur peut modifier la prescription ou la maintenir et en indiquer les raisons. • Le système inscrit la prescription dans le plan de soins de l’infirmière avec un statut « en attente d’analyse par la pharmacie » • Le prescripteur signe la prescription. • Le prescripteur peut imprimer l’ordonnance 20

Agenda 1. Introduction 2. Les bases d’un cahier des charges 3. Les démarches d’élaboration d’un cahier des charges 4. La structure d’un cahier des charges 5. La formulation des exigences 6. Ambassadeurs, êtes-vous prêts? 7. Conclusion 21

Les principes de formulation des exigences • Élémentaire : un seul élément insécable. • Nécessaire : doit servir au moins à un utilisateur. • Mesurable, ou du moins vérifiable. Sinon, c’est un vœu pieux. • Concis : plus c’est court, plus c’est robuste. • Traçable. • Réalisable et modifiable. Sinon, c’est un vœu pieux. • Autosuffisante : compréhensible indépendamment des autres. • Indépendante de la solution 22

Les exigences fonctionnelles dans le cahier des charges-types • Un gabarit d’exigences, c’est contraignant mais c’est bien pratique… < condition > < action > Le système doit permettre à < acteur > de < action > • Exemples − Le système doit permettre à tout utilisateur habilité de saisir les données du dossier médical − Lorsqu’une donnée du dossier médical est saisie, le système doit enregistrer la date et l’heure de la saisie, ainsi que l’identifiant de l’utilisateur qui a saisi la donnée • À utiliser avec souplesse (très contraignant) … mais en sachant que ça existe ! 23

Les exigences non fonctionnelles • Les exigences fonctionnelles décrivent les fonctions, le « quoi » • Les exigences non fonctionnelles décrivent la qualité de ces fonctions • C’est là que se trouve le challenge actuellement. 24

Capacité fonctionnelle • Capacité du produit logiciel à fournir des fonctions qui répondent à des besoins exprimés et implicites lorsque le logiciel est utilisé dans des conditions spécifiées. • • • Aptitude Exactitude Interopérabilité Sécurité Conformité à la capacité fonctionnelle • En pratique… • la section exigences fonctionnelles décrira l’aptitude. • La conformité réglementaire sera définie dans la section règles de gestion. • les exigences d’interopérabilité et de sécurité, faire référence à des normes. 25

Fiabilité • Capacité du produit logiciel à maintenir un niveau de service spécifié lorsqu’il est utilisé dans des conditions précises. • Maturité • Tolérance aux fautes • Possibilité de récupération • Conformité relative à la fiabilité • En pratique… • Souvent utilisées : temps moyen entre défaillances (MTBF, mean time between failures), durée moyenne de défaillance (mean down time), temps de redémarrage. • A la limite entre exigences produit (dépendantes du matériel) et exigences de service. • La formulation est dépendante des fournitures attendues (logiciel seul, matériel et logiciel, services, etc. ). 26

Facilité d’utilisation • Capacité du produit logiciel à être compris, connu, utilisé et à plaire à l’utilisateur, dans des conditions spécifiées d’utilisation. • • • Facilité de compréhension Facilité d’apprentissage Facilité d’exploitation Pouvoir d’attraction Conformité relative à la facilité d’utilisation • En pratique… • Difficile à définir ! • Exiger la conformité à des standards, guides de style, … • Se placer au niveau utilisateur (% de satisfaits) 27

Rendement • Capacité du produit logiciel à fournir des performances appropriées en fonction de la quantité de ressources utilisée, dans des conditions données. . • Comportement vis-àvis du temps • Utilisation des ressources • Conformité relative au rendement • En pratique… • Dépendant du matériel • Se placer au niveau utilisateur (temps de réponse pour une fonction donnée) 28

Maintenabilité • Capacité du produit logiciel à fournir des performances appropriées en fonction de la quantité de ressources utilisée, dans des conditions données. . • • • Facilité d’analyse Facilité de modification Stabilité Facilité de test Conformité relative à la maintenabilité • En pratique… • Caractéristique interne, invisible de l’utilisateur • On peut spécifier des contraintes de service à l’utilisateur. • Le cahier des charges-type regroupe dans un même paragraphe les exigences de maintenabilité et de support. Il s’agit en réalité d’exigences de maintenance, plutôt que de maintenabilité. 29

Portabilité • Capacité du produit logiciel à être transféré d’un environnement à un autre. • • Facilité d’adaptation Coexistence Interchangeabilité Conformité relative à la portabilité • En pratique… • La facilité d’installation est une exigence à forte valeur ajoutée. Il faudra la spécifier dans tous les cas. . • Les autres sous-caractéristiques induisent une contrainte très forte sur l’architecture du logiciel. À n’exiger que lorsque nécessaire. 30

Les exigences non-fonctionnelles dans le cahier des charges-type • Exigences non fonctionnelles − 10. Exigences d’apparence et de style − 11. Facilité d’utilisation et facteurs humains − 12. Exigences de performance − 13. Exigences opérationnelles/relatives à l’environnement − 14. Exigences de maintenance et de support − 15. Exigences de sécurité − 16. Exigences culturelles et politiques − 17. Exigences légales 31