Nous utiliserons comme base d'enseignements un projet.

Voir ici

Intervenants : IBM, Mireille

• Utilisation de la forge Mireille
• Quels rôles sur le DV (1h)
• De la ligne de code au CD envoyé au client (1h)
• 4 heures de c
  • en fonction des métiers (avionique, télécom, …)
• Gestion de configurations Cours et TD (SVN, Clearcase) (1 cours ; 1h de TD)
• Intégration continue
  • Build (Bamboo, nexus, Ant, Maven, …) (2h)
  • Tests (Introduction, Junit, Robots, Intégration, White box testing…) (4h)
    • Cours sur l'integration (2h)
• Packaging/Installer (2h)
  • Gestion des patchs
  • Comment livrer les différents versions?
  • Comment garde-t-il les anciennes configurations
  • Compatibilité ascendante
• Programmation par aspects 2h
  • Notation en java
• Bug tracking (2h
  • Bugzilla…
• Redmine éventuellement
• Qualité de code, du processus,
  • refactoring…
  • Métrics
  • Ne jamais régresser..

• Tests unitaires et outils - Séances de travail en TDD
• Mock en Java - Séance de travail pour l'intégration
• Gestion du système & des dépendances (?Ant/Maven?) (Mosser?)
• Intégration Continue IBM? ?Jenkins? ou Bamboo
• Qualité du logiciel Mireille (Si cela fait du sens.. à vérifier avec les outils dont Sonar qui est déjà installé)
• De UML aux codes si pas traité par Lise (travailler sur la production et le reverse sur des codes) Mireille prendre des codes de projet de l'an dernier par exemple.
• ?? construire des plugiin eclipse?
• Spring et injection de codes?
• Nexus (http://www.insideit.fr/post/2008/09/10/Nexus-rend-la-gestion-de-depot-Maven-plus-facile) IBM
• Programmation par aspects

http://books.google.fr/books?id=AyiK6sbgbjsC&pg=PA12&dq=gestion+de+projets+informatiques&ei=U-gCUM3oFpPkzQSJis2OCQ&hl=fr&cd=2&redir_esc=y#v=onepage&q=gestion%20de%20projets%20informatiques&f=false

• Moyens techniques
  • POstes

http://www.agileworker.fr/lecture-ship-it-a-practical-guide-to-successf

• Outils et infrastructure

“L'illustration de début de chapitre est très parlante, et je me permets d'en donner une traduction grossière ici : prenons deux constructeurs de maison. Le premier, Mike, commence par acheter des nouveaux outils et prend du temps pour apprendre à les utiliser. Le second, Joe, utilise les outils qu'il possède déjà et se met au travail. Bien sûr, la maison de Joe avance plus vite. Mais une fois l'apprentissage de Mike terminé, il rattrape très vite son retard et finit par dépasser Joe ! De plus, la prochaine maison de Mike sera construite encore plus vite. Le but est bien évidemment de montrer qu'avec les bons outils on progresse au final plus vite, même si on a l'impression de passer trop de temps à apprendre comment les utiliser alors qu'on pourrait commencer à coder. La clé est de voir sur le long terme et pas seulement pour les quelques mois (années ?) que vont durer le premier projet.”

• Principe du bac à sable : développer dans un environnement isolé. Le but est de ne pas impacter le travail de ses collègues avec son propre code (et ses bugs…), et encore moins l'environnement de production.
• Gestion des ressources : pouvoir partager son code de manière instantanée avec le reste de l'équipe et l'historique de chaque fichier. C'est ce but que permettent d'attendre les logiciels de contrôle de version (CSV, SVN, Git, etc.) plutôt que la bonne vieille méthode du disque réseau (ou pire, de la clé USB). Pourquoi ? En vrac et de manière non exhaustive, pour pouvoir à tout moment revenir sur une ancienne version (si il y a un bug très important sur la production, il suffit de quelques secondes pour revenir à la dernière version stable connue !), gérer les conflits entre l'édition d'un même fichier par plusieurs personnes ou encore voir l'historiques des modification d'un fichier par date et auteur, etc.
• Compilation par script : plutôt que d'utiliser son éditeur de code pour compiler (qui de toutes façons ne sera pas partagé par tout le monde, et encore moins par le serveur de prod), prendre le temps de faire des scripts propres pour compiler chaque jour une version du code et lancer des tests dessus de manière automatique.
• Gérer les bugs, évolutions, etc. : on peut certes utiliser Excel (ce qui reste mieux que des Post-It) pour savoir quelles sont les tâches sur lesquelles l'équipe doit travailler, les bugs importants ou encore les demandes d'évolution, mais le mieux est de donner l'accès à tout l'équipe à une même interface qui permettra de consulter ces informations (ainsi que de les modifier et en ajouter). Ces logiciels permettent de suivre l'évolution du projet, de gérer les listes des tâches, les priorités ou encore de permettre à des non-développeurs (par exemple le support) de voir toutes ces informations.
• Automatisation des tests : le problème des tests, c'est que d'une part on pense peu souvent à en faire (même si aucune personne au monde ne peut prouver qu'ils ne sont pas utiles…), mais que même si on en a ils ne sont jamais lancés. Il est donc important d'avoir des tests (par exemple des tests unitaires sur la logique métier du code, mais de manière plus générale de multiplier leur nature : fonctionnels, de performance, charge, intégration, etc.), de les maintenir et enfin d'automatiser leur exécution pour éviter de reproduire des problèmes déjà corrigés et s'assurer de la bonne santé de l'intégralité du projet. L'automatisation permet d'éviter le stress des tests lancés une fois de temps en temps et du temps perdu à quelques heures du rendu final…

Autres

• Togaf

• xxx : 12h (volume extensif jusqu'à 24h si vraiment nécessaire)

En se basant sur un projet, faire du développement en agilité sur une semaine par exemple avec suivi le matin et les laisser se débrouiller l'après-midi.

Peut-être liés à un projet tutoré

Idée de Clémentine : * Préparer une composition de Si, avec overlapping fonctionnels et plein de flux de mise à jour et cie, et des BD dans tous les sens * Comment organiser la refonte ? * Modéliser un palier de refonte, puis un second. * Faire un travail en binôme… et demander une fusion ?

Enfin, on peut associer avec Cécile Belleudy pour développer une application de supervision des capteurs ambiants pour le Pôle Santé de proximité. Son cours (24h y compris un rappel de C et C++) + d'un atelier de développement de 18h. On peut également mobiliser les heures de projet tuteuré.

Ou bien on en traite une autre partie mais corrélée par exemple la gestion d'une base des données extraites des capteurs.. ce qui aurait l'avantage de les faire travailler avec d'autres technos. Ainsi on pourrait construire un SI par composition de plusieurs.. : suivis des personnes (bilan, historique, alarmes) ; croisement de données (analyse de données à des fins de statistiques; ..) Je manque d'idées pour l'instant.

Une maison de la santé regroupant plusieurs corps de métiers est en construction sur Biot. Le consortium vous demande d'imaginer un système de diffusion d'informations qui réponde au cahier des charges simplifié ci-après. Vous pourrez être amené à l'étendre après la rencontre avec les spécialistes du domaine et/ou votre propre analyse du sujet. Une attention particulière devra être portée sur les cas d'erreur et les propriétés non fonctionnelles associées à chaque fonctionnalité.

Attention le vocabulaire et la suite du texte présentent des incohérences ou des incomplétutes qu'il convient de lever.

Une maison de la santé est une composition de cabinets et structures médicaux. Un ensemble d'assistante médicale gère l'accueil pour les cabinets. Chaque cabinet est dirigé par un ou plusieurs médecins. Un médecin a une ou plusieurs spécialités (généraliste, dentiste, homéopathe, nutritionniste, kiné, …). Les structures médicales sont des cabinets d'infirmiers, une pharmacie, …

1. Supporter l'enregistrement d'un patient par lui-même et par une assistante
   • Les informations à prendre en compte sont entre autre son nom et son numéro de sécurité sociale
   • Pour gérer certains cas d'anonymat, un patient pourra choisir un pseudo lui permettant de se reconnaître.
   • Un patient ne peut s'enregistrer lui-même que s'il est reconnu par sa carte vitale.
   • Un patient peut modifier certaines informations le concernant après avoir présenté sa carte vitale.
2. Identifier un patient
   • A partir de la lecture de la carte vitale, d'une caméra, de la reconnaissance du téléphone, … le patient sera identifié relativement à l'enregistrement qui a été fait précédemment
   • Si une personne passe le seuil et ne s'identifie pas au bout d'un temps fixé, un signal doit être émis
3. Mémoriser la liste des personnes qui se sont présentées pour permettre des consultations ultérieure par un médecin autorisé
   • Cette liste permettra d'établir des statistiques telles que : les temps d'attente, le “débit” moyen par cabinet, visualiser les parcours des malades au sein de la maison de la santé, …
   • Ces statistiques seront établis après avoir anonymisé les données. Il conviendra de déterminer les justes algorithmes.
4. Gérer les personnes présentes pour l'assistante médicale ou le patient
   • Lorsqu'un patient a été identifié, rechercher le rendez-vous qui lui est éventuellement associé, puis faire apparaître la personne avec sa photo et son pseudo sur l'écran de l'assistante médicale ainsi que le rendez-vous.
   • Si le patient a donné son numéro de téléphone, un SMS lui dit dans quelle salle d'attente se rendre, sinon son pseudo s'affiche pendant 3 mn sur un grand écran avec sa salle d'attente et la durée prévue de l'attente.
   • Si un signal de non identification d'une personne a été levée, l'assistante peut noter qu'il s'agit d'une visite et la préciser éventuellement par le commentaire. Un signal de non-identification disparaît s'il n'a pas été “validé” au bout de 5mn, et passe en mode “non identifié”.
   • Le temps maximal…
   • Le format des rendez-vous pourra s'appuyer sur des formats standardisés tels que ical ou des standards du monde médical s'il en existe. Il ne s'agit pas d'inventer un nouveau modèle de données.
5. Signaler les temps d'attentes aux patients
   • En
6. Gerer les urgences
   1. Supporter la saisie de données médicales par le patient
      • Certains patients sont invités à se rendre dans un box pour préparer leur visite chez le médecin en opérant certains relevés par eux-même : température, rythme cardiaque, poids, … et en répondant à des questionnaires lié à la raison du rendez-vous (Chez un nutritioniste, il pourra s'agir de saisir les repas pris, … Cette liste aura pu être saisie précemment).
   2. Occuper les patients en attente
      • En fonction du profil du patient, vous pourrez proposer des quizz, des jeux, … (table surface?)
   3. Saisir les avis des patients
      • Il s'agit de permettre à un patient de commenter la maison de la santé par : un j'aime lié à facebook, autoriser un commentaire, …
      • Le caractère anonyme ou non des commentaires …
      • La saisie des avis pourra se faire soit via facebook, soit via un boîtier dédié….
   4. Gérer les parcours des patients

Propriétés non fonctionnelles attendues

1. Respect du caractère privé des données (ce point devra être démontré)
2. Un bon référencement du site web de la maison de la santé
3. Respect des normes d'accessibilité W3C pour tous les sites wab entre autre.

• Faciliter la diffusion d'informations telles que “journées de dépistage”, “arrivée d'un nouveau practicien”, des annonces de cours de gym, yoga, …
• Occuper les patients en attente,
• Avoir des statistiques sur par exemple, les pathologies traitées, les parcours des patients au sein de la maison,
• Favoriser les échanges entre praticiens,
• Personnaliser les informations en fonction des personnes,
• Répondre aux questions des patients (horaires d'ouverture, pharmacie de garde, …)

Attention, certaines données sont privées tels que les contenus des dossiers patients et doivent être protégées.

Vous devez proposer une solution globale qui peut mettre en jeu de nouveaux supports tels que de grands écrans, des tablettes tactiles, téléphone, … Il convient de tenir compte des lieux et des personnes, pour les matériels proposés.

Le maître d'ouvrage : L'identification précise des besoins se fera en interrogeant des médecins, des patients et/ou par des recherches sur Internet. Attention, cependant à bien vous limiter à la diffusion d'informations et à prendre en compte les premiers besoins ci-dessus.

Le maître d'ouvrage: Il doit proposer des fonctionnalités en réponse aux besoins évoqués et faire les propositions en terme de matériels ou guider le maître d'ouvrage si celui-ci a fait des propositions.

http://www.sante.gouv.fr/IMG/pdf/rapport_maison_de_sante.pdf