<!–more–

##

  1. Résumé

##

  1. Retour d’expérience sur l’ADT dtk

Au cours de l’ADT/PFE dtk renouvelée fin 2012, l’équipe dtk a pu mettre au point non seulement des outils logiciels transverses utilisables par des EPI de domaines scientifiques très divers mais aussi un ensemble de pratiques de gestion de projet inspirées des méthodologies agiles. La démarche mise en oeuvre a permis d’obtenir des gains importants sur le plan du développement et de la conduite des projets mais elle a également mis en évidence un certain nombre de lacunes intrinsèques au mode de gestion des ADT actuelles.

2.

  1. Éléments positifs

2.1.

  1. Méta-plateforme dtk

Les gains obtenus sont d’abord liés à l’utilisation de dtk pour la conception et la réalisation des plateformes métiers. dtk est une méta-plateforme écrite en C++ et basée sur Qt. Elle est organisée autour d’un noyau qui fournit des couches logicielles servant de base à la construction d’applications métiers modulaires:

  • dtkCore permet de créer des systèmes de plugins pour l’implémentation d’interfaces de programmation
  • dtkComposer fournit un environnement complet de programmation visuelle pour la conception de dataflow simples ou complexes
  • dtkDistributed offre un panel d’outils pour la programmation d’applications distribuées (du simple multi-threading sur une machine à l’utilisation de clusters HPC)

Sous cette forme, dtk a permis d’accélérer la conception d’un grand nombre d’applications métiers (num3sis, medInria, enas, cf dtk-platforms pour plus de détails).

Outre ce noyau, dtk propose des couches logicielles thématiques qui rassemblent de manière cohérente des concepts et des outils utilisés dans la plupart de ces applications métiers. Par exemple, la couche dtk-imaging fournit des interfaces de haut niveau définissant typiquement les concepts d’image et de filtres associés (segmentation, recalage), ainsi que des implémentations performantes issues d’Inria ou bien de l’extérieur. Le développement de ces couches logicielles se fait conjointement avec les équipes de recherche concernées (définition des interfaces, choix des implémentations). Les thèmes proposés par dtk sont les suivants (voir le compte rendu du dernier comité dtk pour plus de détails):

  • géométrie discrète (mailleur, maillage)
  • algèbre linéaire dense (produit matrice-matrice, valeurs propres)
  • algèbre linéaire creuse (matrice creuse parallèle, solveurs linéaires directs, méthodes de Krylov, hybrides)
  • imagerie (/assets/img/posts/2016/images RGB, RGBA, vectorielle, addition, segmentation)
  • entrée/sortie (HDF5 parallèle)

Cette offre logicielle constitue une véritable boite à outils que chaque équipe de recherche peut soit enrichir par ses contributions soit utiliser pour fabriquer des applications métiers. D’une manière générale, cela permet aux équipes de diffuser et confronter leur savoir-faire dans des domaines différents, et de bénéficier des dernières avancées scientifiques et technologiques de leurs confrères.

2.1.

  1. Méthodologie agile pour le suivi des ingénieurs

Parallèlement à cette mise en oeuvre technique, nous avons peu à peu introduit, en accord avec les porteurs d’ADT (utilisant dtk ou non), un mode de suivi agile des ingénieurs. Le travail de ces derniers est découpé en cycles itératifs d’une durée d’un mois en général. Chaque début de cycle est l’objet d’une réunion de 1h30 réunissant le “client” (les chercheurs porteurs du projet) et l’équipe des développeurs (l’ingénieur recruté et les ingénieurs du SED). Cette réunion permet de :

  • fixer les dates des échéances et la quantité de temps développeur disponible pour le cycle
  • lister les fonctionnalités souhaitées pour ce cycle
  • évaluer la durée de chaque tâche
  • arbitrer et finaliser la liste des tâches et des fonctionnalités à réaliser

A l’issue de cette réunion, l’ingénieur propose une roadmap (emploi du temps détaillé, planning du cycle) qu’il s’efforce de suivre. Pour chaque aléas (tâche plus difficile que prévu, absence, etc), l’ingénieur sollicite le client afin d’adapter le planning en diminuant les objectifs (tâche en mode dégradée voire supprimée). Dans tous les cas, le client décide de ce qui est le plus important pour lui.

La réunion de fin de cycle d’une demi-heure maximum consiste à présenter le livrable (par une démonstration du logiciel par exemple).

À l’heure actuelle, 6 ingénieurs travaillant pour 7 ADT (Simon, Bolis/MedInria, C-Sito, BuildingSmart, Diogenes, CGALMesh for dtk) bénéficient de ce mode de suivi. Les bénéfices observés sont multiples:

  • réduction importante du temps d’apprentissage pour les ingénieurs
  • logiciel fonctionnel et enrichi à chaque cycle
  • amélioration des échanges (quantitativement et qualitativement) entre les chercheurs, l’ingénieur et le SED

Grâce à ce mode de suivi, le départ prématuré d’un ingénieur devient moins préjudiciable puisque l’ensemble des développements effectués est connu de tous et le nouvel arrivant peut se les approprier plus rapidement.

2.

  1. Lacunes observées

Malgré ces nets progrès vis à vis de la situation antérieure, un certain nombre d’écueils demeurent. Nous les détaillons dans la suite.

2.2.

  1. Travail en silo

L’utilisation conjointe de dtk et du mode de suivi agile, si elle augmente la vitesse de développement, ne suffit pas pour faire collaborer des ingénieurs qui ont des besoins techniques similaires mais qui travaillent sur des ADT différentes. Le DevCenter de Sophia qui regroupe dans un même open-space les ingénieurs du SED et les ingénieurs sous contrat facilite la collaboration entre les développeurs. Il permet notamment de mettre en oeuvre des pratiques efficaces de programmation comme l’entraide, le pair-programming, le code review, etc. Chaque ingénieur bénéficie ainsi de l’expertise de ses collègues et est informé de la nature de leur travail. Néanmoins, la conduite de chaque ADT se fait naturellement suivant les besoins de chaque équipe de recherche et il est fort rare que des besoins similaires apparaissent au même moment. Les efforts de développement sont alors répétés entrainant une forte dispersion des ressources.

2.2.

  1. Fragmentation du temps ingénieur

Le mode de suivi agile de chacune de ces ADT accapare une part importante du temps des ingénieurs SED. Ces derniers doivent également switcher très vite entre les projets pour former ou encadrer les ingénieurs, ou bien apporter leur expertise à la levée d’un verrou technique. Cette fragmentation de l’utilisation des ressources SED nuit fortement à l’efficacité des développeurs. Ces derniers éprouvent également un sentiment de frustation du fait de la sensation de ne jamais terminer le travail.

2.2.

  1. Surdimensionnement des projets

Un des effets de bord à l’augmentation de la vitesse de développement se traduit par le fait que l’ensemble des besoins initialement exprimés dans la demande ADT sont régulièrement satisfaits 3 à 6 mois avant le terme du projet. Les derniers cycles de développement se concentrent souvent sur des tâches marginales afin de donner du travail à un ingénieur qui possède alors une bien meilleure expertise qu’à son arrivée et qui pourrait être beaucoup mieux utilisé (voir 3.3 pour les pistes proposées). Là encore, l’existence du devcenter offre une solution en permettant de positionner ces ingénieurs comme des référents pour les nouveaux arrivants facilitant ainsi leur intégration dans les équipes de dev. Certains de ces ingénieurs conduisent même les réunions de début et fin de cycle d’autres projets. Mais leur expertise reste cantonnée pour une bonne part au projet auquel ils sont affectés.

2.2.

  1. Quasi absence de la composante transfert

En règle générale, les questions de diffusion et/ou de transfert ne sont abordées que très tradivement, typiquement lors des deux ou trois derniers mois soit plus de deux ans après la définition du projet. Les CPPI ne participent quasiment pas à la vie du projet et le travail effectué souffre de certains défauts qui nuisent à sa bonne diffusion:

  • faible capacité de présentation des savoir-faire aux partenaires extérieurs et industriels
  • problème de packaging pour la distribution du logiciel
  • faible prise en compte des aspects liés aux types de licence à adopter
  • absence de compte rendu de l’ADT permettant aux CPPI d’avoir une vue d’ensemble de l’offre logicielle d’Inria

##

  1. Vers une réorganisation efficace des développements

3.

  1. L’opportunité InriaHub

Le processus InriaHub lève un certain nombre de contraintes sur le montage des projets de développement et offre de nouvelles possibilités:

  • soumission de projets de grande envergure nécessitant de recruter plusieurs ingénieurs
  • durée des projets modulable
  • prise en compte du transfert et de l’impact sociétal dès les phases amonts du développement

Ces nouvelles modalités constituent, selon nous, une opportunité pour palier les lacunes précédemment évoquées en réorganisant efficacement le développement à l’échelle du centre de Sophia Antipolis.

3.

  1. Objectifs

Cette nouvelle ADT poursuit les trois objectifs suivants:

  • production de dix suites logicielles en 2 ans
  • diffusion et mutualisation de ces suites au sein d’Inria
  • réalisation de dix démonstrateurs étoffant l’offre logicielle d’Inria en vu du transfert

3.

  1. Équipe de développement multi-disciplinaire

3.3.

  1. Mutualisation des ressources ingénieurs

Du point de vue organisationnel, cette ADT vise à introduire les modifications suivantes: au lieu d’affecter plusieurs fois peu de ressource sur un projet pendant un temps long (développement extensif), nous proposons de concentrer beaucoup de ressources sur un seul projet pendant une faible durée et de réitérer cette séquence sur les projets suivants (développement intensif).

Pour ce faire, nous souhaitons constituer une équipe de développement multi-disciplinaire centrée autour de quatre ingénieurs SED et de leurs compétences, et renforcée par quatre ingénieurs CDD aux profils complémentaires.

Afin de coordonner au mieux une équipe de cette taille, la mise en oeuvre de la méthode Scrum avec des cycles de développement itératifs de 1 mois maximum sera indispensable.

En fonction des problématiques techniques rencontrées, l’équipe pourra ponctuellement être découpée en sous-équipes.

3.3.

  1. Bénéfices fonctionnels

En termes d’organisation, que ce soit pour les EPI ou pour l’équipe des développeurs, un grand nombre de bénéfices sont attendus:

  • mutualisation du recrutement et des profils des ingénieurs: là où un seul ingénieur devait être compétent sur toutes les thématiques d’une EPI, l’équipe rassemblera des profils pluri-disciplinaires ce qui permettra de s’attaquer efficacement à la production de suites logicielles dans des domaines liés à plusieurs EPI
  • amélioration de la robustesse vis à vis du changement: en cas de recrutement pas tout à fait opportun, ou lors d’un départ anticipé, ou bien encore lorsque un projet ne s’avère finalement pas assez mature, l’équipe de développement sera capable d’absorber bien mieux ces changements en réaffectant ses ressources internes et/ou en se consacrant à d’autres projets
  • enrichissement mutuel et montée en compétence des membres de l´équipe par le brassage des profils au sein même de l’équipe et grâce à l’alternance des sujets scientifiques
  • limitation des pertes de temps liées au changement de contexte et à l’encadrement: l’amortissement de la courbe d’apprentissage se fera essentiellement lors de la formation de l’équipe tandis que les changements de thématiques ne se produiront qu’au changement de projet

Ce mode d’organisation apporte également une solution pour les équipes qui ont des projets de développement courts (typiquement moins d’un an) et qui se heurtent dans ce cas à des difficultés pour recruter des ingénieurs compétents sur des périodes aussi brèves. L’équipe de développement disposera d’un panel suffisament large de compétences pour répondre aux besoins de ces équipes sans recourir à un recrutement difficile.

3.3.

  1. Bénéfices génie logiciel

Du point de vue du génie logiciel, les gains envisagés sont nombreux:

  • réduction des délais de fabrication (de 24 mois à 4 voire 2 mois)
  • amélioration de la qualité des applications (modularité, interopérabilité, intégration continue)
  • utilisation des dernières technologies (internes Inria ou externes)
  • capitalisation du logiciel au sein de dtk et du SED en général

3.3.

  1. Impacts sur la diffusion et le transfert
  • réduction des délais de production pour la constitution de communautés autour du logiciel
  • démonstrateurs fonctionnels pour chaque suite logicielle enrichissant l’offre produit d’Inria pour les partenaires et industriels
  • professionalisation des applications facilitant la mise en production

A étoffer ….

3.3.

  1. Gains comparatifs

À la création des SED, les ingénieurs étaient affectés à des missions bien disctinctes. Sur la base de 4 permanents et 4 CDD, voici le type de résultats obtenus alors:

  • 4 ingés SED + 4 ingés CDD <= 8 ADT séparées

    • qualité inégale, faible diffusion des bonnes pratiques
    • pas d’interopérabilité
    • maintenance des anciens projets presque impossible

La situation actuelle où les ingénieurs SED aggrègent les développements des ingénieurs CDD mène à:

  • 1 ingénieur SED espace immersif / démo + 3 ingénieurss SED dtk + 4 ingénieurs CDD <= 4/5 logiciels (car un CDD est parfois sur deux ADTs en même temps)

    • meilleure qualité et meilleure diffusion des bonnes pratiques
    • interopérabilité minimale
    • maintenance des anciens développement minimale
    • possibilité de faire des démos ponctuelles

Avec les mêmes ressources, la présente proposition ambitionne les résultats suivants:

  • 4 ingés SED + 4 ingés CDD <= 8/10 logiciels

    • enrichissement mutuel au sein de l’équipe
    • qualité en hausse
    • meilleure interopérabilité
    • meilleure maintenance des anciens développement
    • plus de possibilité de faire des démos et du transfert

##

  1. Mise en oeuvre

4.

  1. Suites logicielles par domaine

Le but de l’équipe de développement sera de réaliser de nouvelles applications à partir de codes existants au sein des équipes de recherche. D’expérience, nous savons que ces développements spécifiques sont l’occasion de transférer les concepts et fonctionnalités qui ne relèvent pas de l’expertise de l’équipe concernée dans des couches logicielles de plus haut niveau. Ces couches logicielles seront mises à disposition des autres équipes suivant le modèle que nous avons utilisé dans l’ADT dtk.

En outre, afin de renforcer la cohérence et la lisibilité des développements, les applications et les couches logicielles seront regroupées au sein de suites logicielles dont les thèmes suivront un certain nombre de domaines de recherche d’Inria:

  • mathématiques appliquées, calcul et simulation
  • vision, perception et interprétation multimedia
  • neurosciences et médecine numériques
  • RÉSEAU ?? à compléter

4.

  1. Applications visées

En collaboration avec la CDT locale, le comité dtk et les EPI concernées, nous avons établi une liste de logiciels à développer en priorité par l’équipe nouvellement constituée.

| Application | EPI | Durée | Description | | — | — | — | — | | ODIN | Biocore | 42HM | La plateforme ODIN a été développée dans le but de superviser des bioréacteurs en implémentant de manière simple des algorithmes avancés (contrôleurs, observateurs, diagnostic), développés au sein de BIOCORE. ODIN a été utilisé dans différents projets ANR ou dans le cadre de collaborations industrielles, et a permis d’appliquer concrètement des algorithmes développées par Biocore sur des bioprocédés réels. ODIN est notamment le produit cœur de la société BioEnTech qui commercialise des services de gestion à distance de méthaniseurs. Enfin, ODIN est utilisé par différents laboratoire, il a notamment guidé des expériences réalisées au Laboratoire d’Océanographie qui ont permis d’améliorer très significativement des souches de microalgues. ODIN est composé de divers modules, développés en C++, interagissant pas le biais du protocole CORBA. Un interpréteur Scilab prend en charge la partie calcul scientifique. Néanmoins, ODIN, dont le développement a été initié il y a 13 ans souffre maintenant d’une architecture dépassée, s’appuyant sur des technologies obsolescente. Maintenir le code est devenu de plus en plus difficile, alors que des fonctionnalités modernes devraient être ajoutées. Un refactoring de ODIN est donc nécessaire, notamment pour se débarrasser des dépendances à des librairies dépassées, remplacer CORBA par des protocoles de communication entre modules distribués plus modernes et moins lourds, intégrer la gestion de structure de données plus complexe, proposer une fluidité dans les échanges de données avec le monde extérieur, et finalement proposer une GUI plus en accord avec les standards actuels. Les différents modules qui constituent ODIN se prêtent à un réassemblage (et à une refonte pour certains d’entre eux) par le biais de la plateforme DTK. Ainsi, l’objectif serait de proposer un code ODIN+ de nouvelle génération qui conserverait les principes ayant fait le succès de ODIN, mais dans un cadre logiciel moderne et évolutif. Cette nouvelle version d’ODIN pourrait être transférée à BioEnTech dans le cadre de la méthanisation, ou à d’autres sociétés (Greensea), ou être mobilisée en interne dans le cadre des projets ANR en cours (Purple Sun, Phycover) ou à venir (ANR Infinite Leaf, ou GENESYS OPALE).
| | WindPos | Tosca | 12HM | La demande porte sur un support de développement au logiciel WindPos – solveur lagrangien pour la méca-fluide turbulente, avec une spécialisation autour des simulations de vent de fine à très fine échelle. L’algorithme au cœur du solveur se décompose actuellement en trois modules principaux : avancement particules (position/vitesses /avec divers attribues possibles suivant les applications); redistribution des masses dans les mailles de calcul (correction des positions, prise en compte de force de pression et effet de stratification); solveur de poisson (condition immergée ou terrain following); branchement de modèle turbulence atmosphérique pour l’avancement particules. Le travail a pour but de refondre l’ensemble du code pour le rendre modulaire en vu de contributions de partenaires académiques et industriels, et pour le rendre plus performant en parallélisant son exécution sur plusieurs noeuds de calcul. Les aspects input/output sont traités actuellement via une GUI spécifique développée en interne de 2014 à mi-2015 (basée sur vtk) qu’il s’agirait de faire évoluer pour répondre aux besoins des météorologues.
| | SUP MedApp | Stars | 12HM | L’objectif est de développer plusieurs applications médicales à partir de la plate-forme SUP :

  • Monitoring d’enfants ayant des Troubles du Spectre Autistique TSA avec Prof. F. Azkenazy et S. Serret de LENVAL (projet MONA)
  • Monitoring d’adolescents anorexiques avec Prof. F. Azkenazy et S. Serret de LENVAL
  • Monitoring de patients épileptiques avec Aileen McGonigal MD PhD, Praticien hospitalier en Neurologie, Service de Neurophysiologie Clinique, Hôpital de la Timone, Marseille
  • Monitoring de patients en fin de vie avec Dr Flora TREMELLAT, Médecine de la douleur – Médecine palliative, Hôpital de l’Archet 1
  • Monitoring de résidents d’Ehpad avec Renaud DAVID, MD, PhD, Centre Mémoire de Ressources et de Recherche (CMRR) EA 7276 CoBTeK “Cognition Behaviour Technology” Institut Claude Pompidou
  • Monitoring de personnes âgées au domicile ayant des troubles cognitifs avec Renaud DAVID, MD, PhD, Centre Mémoire de Ressources et de Recherche (CMRR) EA 7276 CoBTeK “Cognition Behaviour Technology” Institut Claude Pompidou
  • Monitoring de patients souffrant de la maladie d’Alzheimer lors de consultation mémoire avec Prof. Philippe Robert CMRR Centre Mémoire – CHU, CoBTeK Université de Nice Sophia Antipolis
  • Monitoring de patients s’entrainant à l’aide de Serious Games avec Prof. Philippe Robert
  • Faire un démonstrateur pour la plate-forme 27 Delvalle à Nice
       
FlowNext Acumes 6HM Acumes étudie une nouvelle approche pour la simulation aérodynamique instationnaire, basée sur des schémas Galerkin-Discontinus haute précision, incluant nativement la gestion de géométries CAO et l’analyse de sensibilités d’ordre élevé. Dans ce contexte, un prototype de code C++ est en cours de développement au sein de l’équipe. L’objectif de ce travail est d’améliorer les fonctionnalités périphériques, notamment le pré-traitement permettant de générer le domaine de calcul à partir de données CAO, et le post-traitement permettant la visualisation des résultats.
       
MGDA-Export Acumes 2HM Acumes développe depuis plusieurs années l’algorithme d’optimisation multi-critère MGDA (Multiple-Gradient Descent Algorithm), qui a été validé sur de nombreux problèmes. L’objectif de ce travail est de réaliser un package du code existant (F77) et inclure une GUI pour utilisation par la communauté et éventuelle valorisation.
       
BuildingSim Acumes 12HM Acumes développe un axe de recherche concernant la simulation, optimisation et visualisation interactive dans le domaine du bâtiment (construction durable selon des critères énergétiques et structuraux). Cet axe s’appuie d’une part sur l’ADT BuildingSmart (en cours) pour la partie visualisation et sur une thèse (en cours de montage) avec notre partenaire Arcelor-Mittal pour la partie optimisation. L’objectif de ce travail est de traiter la partie simulation (logiciel permettant de réaliser automatiquement la chaine de traitement CAO - maillage - simulations pour un ensemble de usecases précis), par wrapping d’outils existant en interne (num3sis notamment) ou open-source.
       
OpenMEEG GUI Athena 8HM OpenMEEG est un logiciel open source qui résout le problème direct EEG/MEG (électroencéphalographie/magnétoencéphalographie) afin de faire le lien entre des sources électriques situées dans le cortex et les mesures MEG et/ou EEG. Ce logiciel distribué depuis 2006 est avant tout un logiciel de calcul qui construit un matrice de transfert à partir d’un modèle géométrico-physique de la tête (tissus et leurs conductivité associée). Le but de cette demande est de créer une interface graphique pour ce logiciel. Cette interface partira du modèle de tête sous forme de maillages ou levelsets et permettra une visualisation graphique de la matrice résultat. Optionnellement, on ajoutera un module de construction du modèle géométrique à partir d’images volumiques de la tête.
       
BCI Browser Athena 12HM Le plus souvent, les techniques de BCI (Brain Computer Interface) sont développées avec de simples démonstrateurs de principe. Les quelques applications BCI développées ont fait l’objet de développements spécifiques et sont peu utilisées par la suite car elles manquent de fonctionnalités, de maintenance, etc. L’idée de cette proposition est de tester la faisabilité d’une autre approche: prendre une application réelle existante, par exemple un navigateur web écrit en C++/Qt, et la recompiler/relinker avec une librairie qui redéfinit certaines interactions de bases (clic souris, entrées clavier, …) avec des composants BCI. On pourrait piloter par BCI des applications du niveau de l’état de l’art avec un coût de maintenance minime. Ce travail s’inscrit dans le cadre de l’IPL BCI-LIFT.
       
TissueLab VirtualPlants 24HM L’objectif de cette ADT est de finaliser la développement de l’environnement logiciel pour la modélisation des tissus végétaux engagé par l’EPI Virtual Plants et Morphème dans le cadre de l’IPL Morphogenetics. Cet environnement est une extension de la plateforme OpenAleaLab et est destiné à intégrer une suite logicielle complète pour l’analyse, l’exploration et la simulation en 3D de tissus végétaux. Elle sera distribuée aux différents partenaires de l’IPL Morphogenetics librement et à l’ensemble de la communauté scientifique à l’issue de cette ADT.
       
DiG Diana 12HM Dans le cadre de ses recherches sur SDN, l’équipe DIANA évalue ses algorithmes et architectures dans des infrastructures de type data-center qui ont pour particularité d’être extrêmement large (plusieurs milliers de machines virtuelles) et consommatrices de resources de calcul. DIANA ne disposant pas d’une véritable data-center, l’équipe a mis au point un prototype d’émulation de data-center dans Grid5000 appelé DiG (Datacenters in the Grid). Le prototype actuel nécessite une préparation d’expérimentations de plusieurs semaines à cause d’un trop grand nombre d’étapes manuelles. L’objectif de ce travail est d’automatiser complètement le processus d’émulation de sorte que les chercheurs puissent déployer leurs expérimentations en quelques heures à la place de quelques semaines. L’automatisation complète de DiG repose sur les concept de graph embedding et de virtualisation que l’équipe a mis au point dans le cadre des ses recherches. DiG sera utilisé dans le cadre des recherches portant sur le routage orienté QoE, le problème de placement de chainage de fonctions virtuelles et la conception d’algorithmes de mesure et de traitement de défaillance dans les réseaux virtualisés.
       
Compass Coffee 12HM COFFEE develops since 2012 the parallel code ComPASS for the simulation of multiphase porous media flows on complex geometries using advanced finite volume methods on polyhedral meshes. A collaboration with BRGM, supported by Carnot Institute, has started in Fall 2013 in order to develop parallel numerical methods for the high performance simulation of geothermal flows in fractured or faulted reservoirs. The objective of this ADT is to improve the current code in terms of parallel scalability, and its modularity in terms of ability to simulate different physics. In order to achieve these objectives we propose to plug the ComPASS code in the dtk platform and to implement with the dtk team a set of interfaces that will be used to improve ComPASS.
       
dtk, POC, Testing SED 24HM Slot pour procéder à la maintenance, refactoring , implication de nouvelles EPI (sprint, POC) et marge de manoeuvre sur les différents projets.
       

4.

  1. Mode opératoire

  • surbooking: liste des projets faisables par l’équipe… cycle usuel d’arbitrage, cdt + DCR + InriaHUB qui décident des logiciels à développer par l’équipe. - Affectation initiale avec 6 premiers mois de projets définis puis soumissions de nouveaux projets à arbitrer tous les six mois à la CDT + DCR + demande éventualle de Go/NoGo à InriaHUb

  • alimentation des projets au fil de l’eau, le but est d’avoir une visibilité d’au minimum 6 mois pour l’équipe de dev. Le choix des projets retenus pourra se faire selon des modalités différentes, via la CDT locale et/ou via InriaHub
  • reporting auprès de la CDT via une démonstration à la fin de chaque projet
  • POC avec des EPI candidates pour les aider à dimensionner leurs projets
  • en fin de projet, split de l’équipe pour amorcer le projet suivant (= recouvrement de projet)

##

  1. Récapitulatifs des ressources demandées