DSI - Pôle Services - TMA EVA · Web viewDSI - Pôle Services - TMA EVA SUJET ( Cahier des charges référence ( CCTP-EVA00109V01V.doc version ( 01 statut ( V créé le ( 1906/2008

DSI - Pôle Services - TMA EVA

Département du Système d’Information


Cahier des charges

CONTEXTE

(


SUJET

(

Cahier des charges

référence

(

CCTP-EVA00109V01V.doc

version

(

01

statut

(

V

créé le

(

1906/2008

par

(

Frédéric Aoussou et Sophie Brouard

mis à jour le

(

par

(

validé le

(

15/07/2008

par

(

Mireille Yamajako (Responsable du Pôle Services)

diffusé le

(

à

(

Péremption, archivage et restriction de diffusion

Nature de la restriction : confidentiel, diffusion restreinte, diffusion interne, restriction annulée

(

TMA EVA

Cahier des Clauses TechniquesParticulières

(CCTP)

SOMMAIRE

51- Contexte, enjeux et objectifs

51.1Contexte général

51.2Contexte organisationnel

61.3Enjeux et objectifs

72Objet du marché

72.1Objet

72.2Prestations demandées

83- Description de l’existant

83.1Présentation synthétique de l’application EVA

93.2Architecture logicielle

103.3Composants techniques de l’application

114Prestations attendues

114.1Prestation forfaitaire

114.1.1Maintenance corrective

114.1.1.1Objectif

114.1.1.2Prestations attendues

124.1.1.3Délais

124.1.1.4Livrables

124.1.1.5Validation

124.2Prestations à bons de commande

124.2.1Initialisation de la TMA

124.2.1.1Objectifs


134.2.1.3Délais

134.2.1.4Livrables

134.2.1.5Validation

134.2.2Maintenance évolutive

134.2.2.1Objet


144.2.2.3Délais

144.2.2.4Livrables

144.2.2.5Validation

144.2.3Maintenance adaptative

144.2.3.1Objet


154.2.3.3Délais

154.2.3.4Livrables

154.2.3.5Validation

154.2.4Conseil et expertise

154.2.4.1Objet et prestations attendues

154.2.4.2Délais

154.2.4.3Livrables

154.2.4.4Validation

164.2.5Réversibilité

164.2.5.1Objet


164.2.5.3Livrables

164.2.5.4Délais

175Modalités de validation des livrables

186Recette et garantie

186.1VABF

186.2VSR

186.3Garantie

197Annexe

197.1Fiche événement

207.2Fiche de livraison

217.3PV de vérification

227.4Délais de traitement des anomalies

247.5Informations pratiques sur la réalisation de la maintenance

1 - Contexte, enjeux et objectifs

1.1 Contexte général

Dans le cadre de la responsabilité des applications informatiques qu’il gère, le département du système d’information (DSI) de l’Institut National de la Santé et de la Recherche Médicale (Inserm), souhaite mettre en place un marché à bons de commande, permettant d’assurer des prestations de maintenance de l’application EVA. Compte tenu du contexte organisationnel et du fait que l’Inserm met en place parallèlement un accord cadre de TMA transverse multi-applications, ce marché de TMA EVA est un marché d’attente qui permet de répondre à un besoin immédiat.

1.2 Contexte organisationnel

Le Département du Système d'Information (DSI) de l’Inserm est organisé de la manière suivante :

· Le pôle Infrastructures garantit la continuité technique du service des applications nationales et de l'administration des réseaux, fournit une expertise technique et assure le bon fonctionnement des infrastructures via la coordination de quatre équipes distinctes :

· Equipe réseau,

· Equipe DBA,

· Equipe exploitation système (assurée généralement par une infogérance),

· Equipe sécurité opérationnelle

· Le pôle Services assure la gestion de la couche applicative du SI via les projets SI et la maintenance applicative. Les missions principales du pôle SI sont les suivantes :

· Assurer le front-office du DSI : assurer l'interface entre les clients et les différentes structures du DSI

· Prendre en charge la conception et la réalisation des applications du SI, soit en mode projet, soit en mode maintenance (généralement via une TMA)

· Assurer la coordination et la planification des projets. Gérer le déploiement des applications

· La Mission de Management des Données est dédié essentiellement au DataMining à partir des informations du SI : collecte des informations et élaboration de restitutions statistiques ;

· Les Délégations Régionales du Système d’Information (DRSI) assurent la mise en œuvre de la politique SI nationale, garantissent la continuité des services au niveau régional et représentent le DSI dans les régions ;

· La Coordination du SI en régions anime le réseau des DRSI, assure la prise en compte des préconisations DSI en régions et le rôle d’interface entre les DRSI et chacune des entités du DSI ;

· Les fonctions Support assurent le support des activités du Directeur du Système d'Information, en interne comme vis-à-vis des clients et garantit un niveau de qualité adéquat pour tous les processus de gestion propres au Directeur du Système d'Information ;

· La Mission Sécurité du Système d’Information supervise la politique de sécurité, émet des préconisations, assure une assistance et vérifie régulièrement l'application des prescriptions de sécurité par audit.

Le pôle Services qui joue un rôle essentiel dans le cadre de l'exécution du présent marché TMA, a fait récemment l'objet d'une réorganisation dont les objectifs sont les suivants :

· Améliorer la perception de la qualité de service en :

· Renforçant la communication avec les départements métiers :

· Mise en place d'un comité de pilotage qui réunit les représentants des départements métiers et le responsable du pôle Services

· Nomination d'un responsable de la relation avec les départements métiers : il interviendra notamment en assistance aux clients (AMOA) dans le cadre de la formalisation des expressions de besoin

· Développant l'expertise technique des équipes

· Renforçant la synergie avec les autres services du DSI

· Garantissant la continuité de service :

· Constitution de binômes (délégation en cas d'absence) et banalisation des applications (polyvalence des personnels)

· Renforcement du service d'assistance aux utilisateurs et aux clients

· Améliorer la cohérence du SI (poursuite des activités d'urbanisation)

· Poursuivre la démarche qualité engagée précédemment pour une certification ISO

Le pôle Services est constitué de 3 bureaux :

· Le Bureau d'Etudes et d'Ingénierie (BIMOA) qui assure l'urbanisation stratégique et tactique du SI (dans ce cadre il analyse l'opportunité des évolutions et adaptations applicatives) ;

· Le Bureau des projets qui gère conçoit et réalise les solutions applicatives soit en mode projet soit en mode maintenance : la maintenance est assurée actuellement pour partie par des tiers (TMA) mais aussi pour partie en interne. La TMA du parc applicatif du DSI est assurée actuellement par un nombre élevé de prestataires (certains prestataires ne prenant en charge qu'une seule application ou un nombre limité d'applications) ;

· Le Bureau de la recette, du déploiement et de l'assistance aux utilisateurs qui assure la recette et le déploiement en transverse des projets et qui gère le centre de services (guichet unique pour les incidents et les demandes. Ce bureau est de fait le principal interlocuteur du titulaire du marché de la TMA EVA.

L’application EVA qui a été conçu sur la base du progiciel « Livelink » de la société « Open Text » est en production de manière continue depuis décembre 2001. Le groupe « Atos Origin » qui est intervenu comme intégrateur de la solution progiciel, a assuré pendant deux ans la maintenance (corrective, adaptative et évolutive) de l’application EVA. Depuis le retrait de l’intégrateur, les travaux de maintenance sont assurés par une ressource interne du DSI.

1.3 Enjeux et objectifs

Les enjeux et les objectifs majeurs associés à ce marché sont les suivants :

· pouvoir assurer la continuité de service au niveau de prestations de maintenance,

· recentrer les activités de la ressource du DSI (en charge de la maintenance), et son savoir faire sur les projets en les dégageant des tâches de maintenance à faible valeur ajoutée,

· mettre en place les conditions optimales de l’intégration de l’application dans la future TMA transverse multi-application.

2 Objet du marché

2.1 Objet

L’objet du présent marché est la tierce maintenance applicative de l’application EVA de l’Inserm.

2.2 Prestations demandées

Les prestations suivantes sont à effectuer par le titulaire du marché du marché au titre de la TMA :

· maintenance corrective,

· initialisation,

· maintenance évolutive,

· maintenance adaptative,

· conseil et expertise,

· réversibilité.

3 - Description de l’existant

3.1 Présentation synthétique de l’application EVA

Contexte fonctionnel

· Rôle majeur : L’application EVA a pour objectif de dématérialiser tout ou partie des processus de :

· Recrutement et suivi (évaluation) des chercheurs

· Création et suivi (évaluation) de l’activité des unités de recherche

· Attribution de bourses, de poste d’accueil et de subvention de programme de recherches.

Les processus élémentaires couverts sont :

· La gestion des concours

· La titularisation

· La création de formations

· L'évaluation quadriennale de l'activité des formations

· L'évaluation des chercheurs

· L'attribution des bourses

· L'attribution des postes d'accueil

· L'attribution de financement de programmes de recherche

· La gestion de la mobilité (chercheur et équipe)

· Client : DES, DRH

· Année de mise en production : 2001

· Utilisateurs :

· Candidats aux concours et appels d'offre

· Gestionnaires

· Evaluateurs

· Unités de recherche

· Périodes d'utilisation et criticité métier :

· De Janvier à Février : 1500 utilisateurs (candidats aux concours et appels d'offre) – criticité élevée

· En Mars : 400 utilisateurs (gestionnaires & évaluateurs) – criticité moyenne

· De Avril à Mai : 3000 utilisateurs (chercheurs) – criticité élevée

· De Juin à Juillet : 400 utilisateurs (gestionnaires & évaluateurs) – criticité moyenne

· En Août : criticité faible

· De Septembre à Octobre : 500 utilisateurs (unités de recherche) – criticité élevée

· En Novembre : 400 utilisateurs (gestionnaires & évaluateurs) – criticité moyenne

· En Décembre : criticité faible

· Concepts majeurs :

· Appels d'offre : contrats d'avenir, contrats d'interface, contrats d'accueil, CTRS, formations de recherche, concours chercheurs INSERM

· Chercheurs : statutaires INSERM, directeurs d'unité, universitaires au profil d'une unité INSERM, hospitalo-universitaire au profil d'une unité INSERM, hospitalier au profil d'une unité INSERM, chercheurs externes (étrangers, employés du privé…)

· Commissions scientifiques : CSS, CS

· Documents à évaluer : fiche administrative, rapport de stage, fiche annuelle, rapport d'activité, fiche financière…

· Documents d'évaluation : bibliométrie par exemple

· Résultats d'évaluation

· Sensibilité des données : sensibilité haute : données personnelles et sur les recherches de l'Inserm (cœur de métier de l'Inserm)

Contexte technique

· Applications liées (interfaces) : SIRENE, SVE, BIR

· Architecture : WEB 3 tiers

· Mode de développement : progiciel de gestion documentaire (Livelink de OpenText) + développement spécifique

· Langages de développement & technologies : JAVA (JSP/Servlets) pour les développements spécifiques

· Progiciels : Livelink v9.0 et 9.6 (OpenText)

· SGBD : ORACLE 8i et ORACLE 10g

· Mode d'administration : administration fonctionnelle par web (de plus en plus) administration technique par ssh

Documentation

· Niveau de la documentation fonctionnelle : moyen (dernières mises effectuées en 2007)

· Niveau de la documentation technique : faible (pas de mise à jour depuis l’intégration du progiciel en 2001)

Charges de maintenance annuelle

· Charge de maintenance corrective : 12 j/h en 2007

· Charge de maintenance évolutive : 100 j/h prévu pour 2008

· Charge de maintenance adaptative : 5 j/h prévu pour 2008

3.2 Architecture logicielle

3.3 Composants techniques de l’application

Catégorie

Sous-Catégorie

Dénomination

Valeur

Mode de développement

degré de paramétrage du progiciel

importance du paramétrage effectué

moyen

Gestion des données

SGBD

nombre de SGBD

1

tables

nombre de tables

256

vues

nombre de vues

233

fichiers plats

nombre de fichiers

1

procédures stockées

nombre de procédures stockées

0

moniteur transactionnel

nombre de moniteurs transactionnels

0

Règles de gestion

volumétrie

nombre de règles de gestion

50

Lignes de code

(KLOC)

Nombre de lignes de codes sans commentaires (java)

273 000

Nombre de ligne de commentaire

46 000

IHM

écrans

nombre d'écrans

247

richesse des écrans

nombre moyen d'objets par écran

70

Etats et rapports

mode de développement

développement spécifique (pas de générateur)

oui

volumétrie

nombre d'états et rapports

20

Interfaces d'échange

flux entrants

nombre de flux entrants

2

flux sortants

nombre de flux sortants

3

4 Prestations attendues

Dans le cadre du présent marché et conformément aux documents le régissant, le titulaire assure les missions suivantes :

· initialisation des prestations,

· maintenance de l’application,

· conseil et expertise,

· réversibilité.

4.1 Prestation forfaitaire

4.1.1 Maintenance corrective

4.1.1.1 Objectif

Le titulaire est chargé de réaliser la maintenance corrective qui consiste à :

· réaliser la correction des anomalies de fonctionnement et la reconstitution des données éventuellement endommagées suite à ces anomalies

· assurer le support de niveau 2.

Les anomalies de fonctionnement sont classées en trois catégories en fonction de leur niveau de gravité :

· bloquant : incident de fonctionnement bloquant le déroulement d’une ou plusieurs fonctionnalités et affectant l’intégralité des données,

· grave : incident autorisant le fonctionnement partiel d’une ou plusieurs procédures de gestion et qui peut être contourné par l’utilisateur, mais avec des performances dégradées,

· mineur : tout incident par défaut

Le support de deuxième niveau permet de recourir aux compétences de l’équipe de TMA du titulaire afin de réaliser pour un gestionnaire, un utilisateur d’EVA ou un administrateur de l’application, des prestations d’assistance concernant :

des expertises techniques ou fonctionnelles,

des conseils d’utilisation,

des diagnostics et analyses d’anomalies ou de résultats,

des compléments ponctuels de formation sur EVA.

Le délai d’exécution d’une prestation de support de niveau 2 ne doit excéder 1 jour ouvré. Au-delà, l’Inserm doit recourir à l’utilisation d’unités d’œuvre de la prestation de Conseil et Expertise.

L’Inserm laisse libre aux candidats de proposer les plages horaires du support de deuxième niveau.

4.1.1.2 Prestations attendues

Seuls les membres de l’équipe projet d’EVA sont habilités à déclarer des anomalies dans le cadre de cette prestation de maintenance corrective. Les anomalies seront gérées dans un outil qui sera déterminé par les deux parties pendant la phase d’initialisation.

Il est attendu du titulaire les actions suivantes :

Correction des anomalies

· reproduire le problème en environnement de développement/test,

· corriger la cause du problème en environnement de développement/test,

· effectuer les tests unitaires, tests d’intégration adéquats,

· livrer à l’INSERM une version du patch produit

· fournir le mode opératoire adéquat nécessaire à la mise en place du patch,

· produire des documents et compléments documentaires techniques décrivant les corrections ou modifications effectuées.

Support de niveau 2

· analyser la demande décrite dans une fiche de demande de travaux

4.1.1.3 Délais

Correction d’anomalies

Le titulaire s’engage dès réception de la fiche d’anomalie, à livrer le(s) patch(s) correctif(s) dans les délais indiqués au paragraphe 7.4.

Plusieurs livraisons peuvent être planifiées et regroupées dans un même pack.

Support de niveau 2

Maximum 1 jour ouvré

4.1.1.4 Livrables

Le titulaire remet à l’Inserm les produits suivants :

Correction d’anomalies

· les composants de la nouvelle version corrigée (notamment les programmes sources, liste des fichiers, des tables),

· le compte rendu de correction par dysfonctionnement relevé, en précisant les actions entreprises pour les éliminer,

· la documentation technique mise à jour

Support de niveau 2

· Partie de la fiche demande de travaux réservée au titulaire, remplie.

4.1.1.5 Validation

· La validation est effectuée par l’Inserm selon les délais indiqués dans au paragraphe 7.4

4.2 Prestations à bons de commande

4.2.1 Initialisation de la TMA

4.2.1.1 Objectifs

Cette prestation est à bons de commande et donc modulable car elle dépend du niveau de connaissance de l’application du titulaire (titulaire ou non du précédent marché de réalisation et/ou de la TMA).

Selon le bordereau des prix du marché, trois niveaux de complexité sont définis :

· niveau simple,

· niveau moyen,

· niveau complexe.

Les objectifs assignés au titulaire lors de la phase d’initialisation de la TMA sont définis en fonction de ces trois niveaux :

· niveau simple,

· rédiger le Plan Qualité (PQ).

· niveau moyen,

· rédiger le Plan Qualité (PQ).

· mettre en place toutes les conditions techniques et humaines qui sont nécessaires à la bonne réalisation des prestations ;

· niveau complexe,

· mettre en place toutes les conditions techniques et humaines qui sont nécessaires à la bonne réalisation des prestations ;

· assurer, la prise de connaissance technique et fonctionnelle du système GAIA afin d’être complètement opérationnel par la suite dans la conduite de la TMA ;

· rédiger le Plan Qualité (PQ) qui a été remis lors de l’appel d’offres.

· Mettre à jour la documentation de l’application


Les prestations attendues en fonction des niveaux de complexité sont les suivantes :

· préparation,

· prise de connaissance de l’existant,

· mise en place du cadre de fonctionnement,

· rédaction du Plan Qualité

· bilan.

4.2.1.3 Délais

La durée de la phase d’initialisation ne peut excéder 20 jours ouvrés, à compter de la date de notification du marché.

L’initialisation a lieu principalement dans les locaux du titulaire.

4.2.1.4 Livrables

Le titulaire remettra à l’Inserm les livrables suivants :

Livrable 1 : Plan Qualité, au plus tard 15 jours ouvrés après la date de notification du marché,

Livrable 2 : Bilan de la phase, au plus tard 25 jours ouvrés après la date de notification du marché.

Pour que cette prestation se déroule dans les meilleures conditions, l’Inserm mettra à la disposition du titulaire tous les documents nécessaires notamment les documents techniques de l’application et la documentation sur la gestion documentaire.

4.2.1.5 Validation

La validation des travaux de la phase d’initialisation doit être réalisée rapidement par l’Inserm. La procédure de validation peut se résumer dans le tableau suivant :

Nature des livrables

Délais maximum de livraison

Nature du document de validation

Délai de validation

Délai de correction éventuelle du titulaire

Livrable 1

15 jours ouvrés

Procès verbal de vérification

3 jours ouvrés

1 jour ouvré

Livrable 2

25 jours ouvrés

Procès verbal de vérification

3 jours ouvrés

1 jour ouvré

4.2.2 Maintenance évolutive

4.2.2.1 Objet

Au cours de l’exécution du marché de TMA, le titulaire pourra être sollicité par l’Inserm pour faire évoluer le système d’information EVA.

Grâce aux connaissances acquises sur l’application dont il a la charge, le titulaire devra être capable de répondre aux besoins exprimés par l’Inserm. Ces besoins peuvent en effet résulter d’une évolution réglementaire ou organisationnelle dans le domaine de l’évaluation scientifique..


Les actions attendues par le titulaire sont :

· élaborer le dossier de spécifications générales (SG)

· élaborer les dossiers de spécifications détaillées ; fonctionnelles (SFD) et techniques (STD),

· réaliser le développement des programmes assortis des tests de qualification (unitaires, intégration et non-régression)

· apporter les correctifs nécessaires pendant les phases de recette : VABF et VSR.

· rédiger les supports de formation au module ou à l’application développée,

· former les différents groupes utilisateurs du nouvel applicatif,

· assurer la maintenance des développements pendant une phase de garantie de 6 mois

4.2.2.3 Délais

Les délais de réalisation de cette prestation correspondent à ceux définis dans le planning élaboré conjointement entre les deux parties au moment de la commande de la prestation.

4.2.2.4 Livrables

Le titulaire remet à l’Inserm les livrables suivants :

· le planning détaillé de la prestation,

· le dossier de spécifications générales (SG),

· le dossier de spécifications fonctionnelles détaillées (SFD),

· le dossier de spécifications techniques détaillées (STD), notamment la JAVADOC (pour les programmes développés en JAVA),

· le dossier de réalisation et de paramétrage,

· le dossier d’installation,

· le dossier d’administration fonctionnelle,

· le dossier de maintenance de l’application (incluant l’administration technique),

· le cahier de tests (tests du titulaire),

· les programmes développés.

4.2.2.5 Validation

Les modalités de validation des différents livrables d’une prestation de maintenance évolutive, sont identiques à celles décrites dans le paragraphe § 3.1.1.1.

4.2.3 Maintenance adaptative

4.2.3.1 Objet

Le titulaire devra assurer une veille technologique minimale à intervalle régulier et proposer une étude d’impact susceptible d’intéresser l’Inserm. La prestation de maintenance adaptative est évaluée en fonction de la complexité des adaptations souhaitées définie comme suit :

· adaptation simple : adaptation de l’application à des évolutions sur le matériel, le système d’exploitation, les logiciels intégrés, le réseau et la sécurité.

· Adaptation moyenne.

· adaptation complexe : portage de l’application suite au changement décrit ci-dessus.


Le titulaire met en œuvre les prestations de maintenance adaptative selon la procédure suivante :

· Phase 1 : suivi de l’évolution technologique ou étude d’impact du changement technologique sur l’application

· Phase 2 : mise en œuvre des travaux d’adaptation et livraison de la nouvelle version de l’application.

Le titulaire prend à sa charge l’acquisition de toutes les compétences nécessaires à la migration technologique des composants logiciels de l’application.

4.2.3.3 Délais

La prestation de maintenance adaptative débute à la réception et validation du bon de commande par le titulaire. Elle respectera le planning de réalisation proposé par le titulaire lors du suivi de l’évolution ou de l’étude d’impact d’un changement technologique. La durée de la prestation ne devra pas excéder 20 jours ouvrés

4.2.3.4 Livrables

Le titulaire remet les livrables suivants :

· Le plan de migration,

· les composants de la nouvelle version,

· la documentation technique mise à jour (installation, paramétrage, administration fonctionnelle et technique)

4.2.3.5 Validation

Les modalités de validation des travaux de cette prestation sont identiques à celles de la prestation de maintenance évolutive.

4.2.4 Conseil et expertise

4.2.4.1 Objet et prestations attendues

A la demande de l’Inserm, le titulaire peut être chargé de réaliser une expertise technique ou fonctionnelle sur l’application.

La nature des travaux susceptibles d’être commandés par l’Inserm, est précisée dans les unités d’œuvre du bordereau des prix.

4.2.4.2 Délais

La durée de la prestation ne devra pas excédée 20 jours ouvrés à compter de la validation du bon de commande par le titulaire

4.2.4.3 Livrables

Le titulaire remettra à l’issue de la prestation, un rapport d’expertise qui comportera les points suivants :

· description de la démarche méthodologique,

· plan d’action pour mettre en œuvre les modifications à apporter et identifiées à l’issue de la prestation:

· planning

· coût humain et financier

· garantie de non-régression des performances de l’application

· procédures

4.2.4.4 Validation

La validation de la prestation de conseil et expertise devra est achevée au plus tard 10 jours ouvrés après la réception du livrable par l’Inserm.

4.2.5 Réversibilité

4.2.5.1 Objet

Le titulaire organise le transfert de compétences vers l’Inserm ou vers toute personne habilitée par ce dernier, afin de lui permettre de poursuivre la maintenance de l’application au même niveau de qualité. Il assure également une assistance technique permettant d’intervenir rapidement sur les produits en cas d’anomalies bloquantes.


Cette prestation de réversibilité comprend au minimum les phases détaillées ci-après :

· l’organisation de sessions de travail sur les domaines suivants :

· l’architecture applicative,

· l’architecture technique,

· l’ensemble des outils développés autour de l'application,

· tous les environnements,

· la description de l’organisation de la documentation de référence,

· l’assistance technique pendant une période permettant la prise en charge de la maintenance applicative par l’Inserm ou par une personne désignée par l’institut.

4.2.5.3 Livrables

Le titulaire remet à l’Inserm les livrables suivants :

· La liste des composants des versions successives de l’application,

· les comptes-rendus des réunions de transfert de compétences faisant apparaître le contenu, la méthode pédagogique, la méthode et les résultats d’évaluation, les intervenants et les participants, la documentation support,

· le compte-rendu de la réunion de bilan précisant la liste des intervenants et celle des participants,

· le suivi de l’activité d’assistance technique ainsi que la documentation support.

· Tout document que le titulaire jugera utile de remettre à l’Inserm.

4.2.5.4 Délais

La prestation de réversibilité débute par la réception du bon de commande émis par l’Inserm. Elle s’exécute conformément au planning établi dans un délai ne devant pas excéder 20 jours ouvrés à compter de la validation du bon de commande par le titulaire.

5 Modalités de validation des livrables

Chaque document remis par l’une ou l’autre des parties fera l’objet d’une validation.

Dans le cadre de la phase de spécification de la maintenance évolutive, l’Inserm au cours de son analyse du document, devra consigner ses remarques et observations dans une fiche de relecture dont un modèle figure en annexe.

Les délais des validations des documents sont variables en fonction de la nature de la prestation et de la phase en cause. Le tableau ci-dessous présente les différents délais à respecter

Documentation

Valideur

Délai

(j ouvrés)

Initialisation

Plan Qualité

Inserm

3

Bilan de la phase

Inserm

3

Maintenance corrective

Fiche d’anomalie

Titulaire

0,5

Fiche de demande de travaux (support de 2ème niveau)

Titulaire

1

Documentation d’installation / paramétrage

Inserm

3

Maintenance évolutive et adaptative

Cahiers des charges

Titulaire

5

Analyse d’impact - Devis

Inserm

3

Bon de commande

Titulaire

1

Dossier de spécifications fonctionnelles générales (SFG)

Fiche de relecture

Titulaire

1

Versions de travail

Inserm

3

Version finale du dossier

Inserm

5

Dossier de spécifications fonctionnelles détaillées (SFD)

Fiche de relecture

Titulaire

1

Versions de travail

Inserm

3


Inserm

5

Dossier de spécifications techniques détaillées (STD)

Fiche de relecture

Titulaire / Inserm

1

Versions de travail

Inserm

3


Inserm

5

Dossier d’installation /paramétrage

Inserm

3

Réversibilité

Liste des composants applicatifs et de toute de la documentation technique

Inserm

3

Compte rendu de la réunion bilan

Inserm

3

Tâches connexes

Comptes rendus de réunions

Inserm

3

Fiches événements

Inserm

5

A l’issue d’une phase de validation, l’Inserm ou le titulaire émet un PV de vérification dont le modèle standard est placé en annexe.

Le processus de signature de ce PV en vigueur à l’Inserm prévoit que le document est d’abord paraphé par le titulaire et secondairement par l’Inserm.

Les PV de vérification des prestations ouvrant droit à un paiement de facture doivent impérativement être visés par le directeur de projet ou fonction équivalente du côté du titulaire, et par le directeur du département du système d’information ou toute personne dudit département disposant d’une délégation de signature.

6 Recette et garantie

La recette se rapporte aux prestations de maintenance corrective (VABF uniquement), de maintenance évolutive et de maintenance adaptative. Quant à la garantie, elle ne s’applique qu’aux maintenances évolutive et adaptative.

La recette se décline en deux parties :

· la Vérification d’Aptitude au Bon Fonctionnement (VABF) ou recette provisoire,

· la Vérification en Service Régulier (VSR) ou recette définitive.

6.1 VABF

La Vérification de l'Aptitude au Bon Fonctionnement (VABF) est réalisée par l’INSERM après la livraison par le titulaire de la TMA d’un lot de corrections ou d’évolutions. La mise en œuvre consiste à réaliser les tests de validation décrits dans le Plan Qualité sur la base d’un cahier de recette.

Pour le suivi des dysfonctionnements (anomalies) constatés au cours de la VABF, l’Inserm propose un outil développé en interne : « OLGA ». Le principe de fonctionnement d’OLGA est décrit dans le Plan Qualité. Le titulaire est libre de proposer un outil similaire dans son offre.

La durée de la VABF est définie dans le planning proposé par le titulaire et soumis à la validation de l’Inserm. Cette durée ne pourra toutefois pas excéder 60 jours ouvrés.

6.2 VSR

La VSR est déclenchée dès la validation de la mise en production d’un lot de corrections ou d’évolutions. Pendant cette phase, l’Inserm s’assure du bon fonctionnement de l’application dans les conditions réelles et de l’absence de non-régression de l’ensemble du système

Pour le suivi des dysfonctionnements (AVP) constatés au cours de la VSR, l’Inserm propose un outil développé en interne : « DIONE ». Le principe de fonctionnement de DIONE est décrit dans le Plan Qualité. Le titulaire est libre de proposer un outil similaire dans son offre.

La durée de la VSR est définie dans le planning proposé par le titulaire et soumis à la validation de l’Inserm. Cette durée ne pourra toutefois pas excéder 40 jours ouvrés.

6.3 Garantie

Les développements réalisés dans le cadre des maintenances évolutive ou adaptative font l’objet d’une phase de garantie déclenchée dès la validation de la phase de VSR.

La durée de la garantie est fixée à 6 mois. A l’issue de cette période de garantie, les composants logiciels développés sont pris en charge par la maintenance corrective forfaitaire.

Les modalités de gestion des avis de problèmes déclarés par l’Inserm pendant cette phase sont décrites dans le Plan Qualité.

7 Annexe

7.1 Fiche événement

N° d’enregistrement :

TMA EVA

FICHE EVENEMENT

Partie 1 réservée à la déclaration

Nom du site :

INSERM

Date / heure de l’envoi :

xx/xx/xx

Identification

nom :

prénom :

tél. :

fax :

du

déclarant

rattachement :

Type d’événement:

Information

FORMCHECKBOX

Incident

FORMCHECKBOX

Réclamation

FORMCHECKBOX

Non conformité

FORMCHECKBOX

Demande d’évolution

FORMCHECKBOX

Nature de l’événement:

Matériel

FORMCHECKBOX

Logiciel

FORMCHECKBOX

Documentation

FORMCHECKBOX

Exploitation

FORMCHECKBOX

Méthode

FORMCHECKBOX

Outil

FORMCHECKBOX

Personnel

FORMCHECKBOX

Autre

Logistique

FORMCHECKBOX

Partie 2 réservée à la description

Description de l’événement :

Partie 3 réservée au traitement curatif

Analyse du problème (moyens curatifs possibles, impact sur les charges, les délais, le personnel) :

Plan d’actions curatives (actions, acteurs et plannings) :

Partie 4 réservée à l’acceptation (nom, date et visa)

Pour le titulaire

Pour l’Inserm

7.2 Fiche de livraison

La fiche de livraison accompagne la livraison de chaque document ou de chaque version logicielle.


TMA EVA

FICHE DE LIVRAISON

Partie 1 à remplir par le fournisseur

Site :

Date de l’envoi :

Numéro de version logicielle :

Support de livraison :

Cd-rom

Erreur! Signet non défini.

Disquette


Mail


Courrier


Documentation livrée :

Destinataire :

Logiciel livré :

Destinataire :

Autres éléments livrés :

Destinataire :

Partie 2 à remplir par le destinataire

Date de réception :

Nom(s) et signature(s) du (des) destinataire(s) :

7.3 PV de vérification


TMA EVA

PROCES VERBAL DE …

Les soussignés :

Représentant l’Inserm :

Représentant du titulaire:

Le Directeur du …

Déclarent que l’opération de :

Livraison (*) / Vérification (*) / Admission(*) / Vérification d’Aptitude au Bon Fonctionnement (**) / Vérification de Service Régulier (**)

* : préciser les éléments objets de la vérification, ** : préciser l’objet de la VABF ou de la VSR

Concernant :

référence / description de l’objet du P.V. :

libellé du marché :

référence du marché :

A été réalisée à partir du :

La date contractuelle correspondante étant le :

Que l’opération s’est terminée le :

Le délai contractuel étant de :

Résultat observé (rejet de l'objet livré ou à vérifier / acceptation avec réserves / acceptation sans réserves) :

Ce procès verbal est établi sous réserve des points suivants :

La livraison de ces éléments devant intervenir avant le :

Leur vérification devant intervenir avant le :

Fait à Paris en trois exemplaires le :

Représentant l’Inserm :

Représentant du titulaire :

Le Directeur du DSI

Le .....................

Le présent procès-verbal ouvre droit à paiement d’une facture

Oui Non

7.4 Délais de traitement des anomalies

7.5 Informations pratiques sur la réalisation de la maintenance

AnnéeNombre d'avis de problème*Durée totale de traitement

Durée moyenne de traitement

d'un avis de problème

Nombre de demande de travaux **

(évolutions + administration)

Durée totale de traitement

Durée moyenne de

traitement

d'une demande de travaux

20072913 heures27 minutes57340 heures6 heures

2008 (6 mois)3518 heures33 minutes83167 heures2 heures

* Avis de problème : dysfonctionnement constaté par un tilisateur sur l'application en production

** Demande de travaux : demande d'intervention émise par un utilisateur : développement d'une nouvelle fonction simple, modification de paramétrage, édition d'états spécifiques, etc.

Html/Java

Java + Livelink simple*

Java + Livelink complexe**

* Livelink simple : utilisation des fonctions standards de Livelink : création/modification d'utilisateurs et groupes, création modification d'objets (LiveReports, Dossiers, Formulaires), gestion des droits.

** Livelink complexe : maîtrise de l'utilisation de l'API Java Livelink (SDK)

Concours chercheurs

Mobilité individuelle

Mobilité équipe

Administration/Gestion globale

13%

7%

2%

20%

Activité/Promotion/Titularisation16%

18%Appels d'Offres

Typologie des demandes de travaux et avis de problèmes

Création/Evaluation de structures22%

Répartition des demandes de travaux et avis de problèmes par processus fonctionnel

30%

56%

14%

� La maintenance corrective comporte à la fois la correction des bugs déclarés lors de VABF que ceux déclarés sur l’application en production

avertissement

Afin de prévenir toute utilisation non intentionnelle de documents périmés, le lecteur est invité à vérifier que l'édition papier du document en sa possession constitue la dernière version en vigueur.

Cette vérification peut être effectuée soit en consultant la zone documentaire adéquate du serveur de fichiers, soit en interrogeant l'auteur du document, soit, lorsqu'il existe, l'administrateur du système documentaire.

La reprographie ou la rediffusion de ce document, par quelque moyen que ce soit, est strictement déconseillée sans information et autorisation préalable de son auteur ou, lorsqu'il existe, de l'administrateur du système documentaire.

29

Référence : CCTP-EVA00109V01T.docPage 29 sur 24

_1278921833.xls

page de garde

Département du Système d’Information

CONTEXTElEVA - Maintenance

SUJETlStatistiques de maintenance

référencelvoir pied de page gauche

versionlvoir pied de page gauche

statutlvoir pied de page gauche

avertissement

créé lel7/30/08

parlSophie BROUARDAfin de prévenir toute utilisation non intentionnelle de documents périmés, le lecteur est invité à vérifier que l'édition papier du document en sa possession constitue la dernière version en vigueur.

mis à jour lel

parl

Cette vérification peut être effectuée soit en consultant la zone documentaire adéquate du serveur de fichiers, soit en interrogeant l'auteur du document, soit, lorsqu'il existe, l'administrateur du système documentaire.

validé lel

parl

Péremption, archivage etrestrictions de diffusion

Nature de la restriction : confidentiel,diffusion restreinte, diffusion interne,restriction annuléelLa reprographie ou la rediffusion de ce document, par quelque moyen que ce soit, est strictement déconseillée sans information et autorisation préalable de son auteur ou, lorsqu'il existe, de l'administrateur du système documentaire.

&L&8&F - &A&C&8&D &T&R&8page &P/&N

présentation

1.Objet et domaine d'application

Indiquer ici à quoi doit servir le document et à qui il est destiné.

Il est très important que chaque document soit ciblé, à la fois en terme de contenu et en terme de lectorat. De cette manière, on augmente les chances du document d'être lu par ceux à qui il est destiné.

2.Autres informations

Vous pouvez également, si cela vous paraît nécessaire, fournir à vos lecteurs des informations complémentaires sur le contenu du document, telles que par exemple :

2.1 - méthode de constitution du fichier EXCEL

Indiquez, par exemple, d'où proviennent les données et comment le fichier a été constitué.

2.2 - etc.

Précisez autant que nécessaire, mais pas plus : trop d'information tue l'information.

2.Conseils pratiques

Ce document comprend trois feuilles :

- une première feuille constituant la page de garde, et comprenant toutes les informations d'identification du document ;

- une seconde feuille (celle-ci), destinée à vous permettre de fournir des informations utiles à vos lecteurs ;

- une troisième feuille, qui peut être dupliquée autant que nécessaire selon votre besoin.

Si vous avez besoin de feuilles supplémentaires, ne créez pas de feuilles vierges avec la fonction standard EXCEL, mais dupliquez la feuille standard.

En procédant de cette manière, vous conservez la mise en forme normalisée (en-tête et pied de page) sans être obligé de la recréer.

Contrairement à ce qui est possible avec WORD, il n'est pas possible avec EXCEL d'insérer des champs prédéterminés (nom de fichier, dates, auteur, etc.) ailleurs que dans les en-têtes et les pieds de page.

C'est pourquoi la zone "référence" de la page de garde renvoie au pied de page pour vous éviter d'avoir à saisir manuellement le nom du fichier.

&L&8&F - &A&C&8&D &T&R&8page &P/&N

feuille

AnnéeNombre d'avis de problème*Durée totale de traitementDurée moyenne de traitementd'un avis de problèmeNombre de demande de travaux **(évolutions + administration)Durée totale de traitementDurée moyenne de traitementd'une demande de travaux

20072913 heures27 minutes57340 heures6 heures

2008 (6 mois)3518 heures33 minutes83167 heures2 heures

* Avis de problème : dysfonctionnement constaté par un tilisateur sur l'application en production

** Demande de travaux : demande d'intervention émise par un utilisateur : développement d'une nouvelle fonction simple, modification de paramétrage, édition d'états spécifiques, etc.

Typologie des demandes de travaux et avis de problèmes

Html/Java30%

Java + Livelink simple*56%

Java + Livelink complexe**14%

* Livelink simple : utilisation des fonctions standards de Livelink : création/modification d'utilisateurs et groupes, création modification d'objets (LiveReports, Dossiers, Formulaires), gestion des droits.

** Livelink complexe : maîtrise de l'utilisation de l'API Java Livelink (SDK)

Répartition des demandes de travaux et avis de problèmes par processus fonctionnel

Création/Evaluation de structures22%

Activité/Promotion/Titularisation16%

Appels d'Offres18%

Concours chercheurs13%

Mobilité individuelle7%

Mobilité équipe2%

Administration/Gestion globale20%

Site web2%

&L&8&F - &A&C&8&D &T&R&8page &P/&N

MBD0029D72C.doc