La Gestion De Projet Informatique by Grare Stéphane - HTML preview

Compte-rendu de réunions (document de recueil,…)

x

1.2 Document de recensement des besoins fonctionnels:

x

x

x

Plans types

x

Spécification des axes et mesures

x

x

x

x

Spécification des tableaux de bord

x

x

x

x

Identification des données et règles de gestion

x

x

x

x

Grilles d'entretiens

1.3 Dossier d'analyse de l'existant:

x

x

x

Méthodologie de

x

cartographie

Cartographie applicative

x

x

x

x

Cartographie des données

x

x

x

x

Cartographie des flux

x

x

x

x

Restitutions existantes

x

x

x

x

Plan type

1.4 Etude de dimensionnement

x

x

x

x

Best practices issues

d'expériences de cadrage

Plan type

1.5 Dossier fonctionnel et technique du SID:

x

x

x

Best practices issues

x

d'expériences de cadrage

Identification de l'origine et de la disponibilité des données

x

x

x

Schéma des flux

x

x

x

Macro- modèle

x

x

x

Architecture cible applicative et technique

x

x

x

Plan de réalisation

x

x

x

Dossier fonctionnel détaillé de la première itération

x

x

x

Plan type

1.6

Dossier fonctionnel détaillé de la première itération

x

x

Best practices issues

x

d'expériences de cadrage

Livrables proposés en compléments du dossier de consultation

GUIDE D’ENTRETIENS

Les objectifs de ce questionnaire sont les suivants :

· Appréhender le métier et l’organisation

· Collecter les éléments permettant d’effectuer l’analyse du SID existant

· Rassembler les informations majeures pour l’élaboration du modèle du SID cibles

Objectif : Faire un état des lieux du SI existant (vision technique)

THEMES

Généralités

Nom de l’interlocuteur

Position et rôle

Relation avec les différentes maîtrises d’ouvrages et/ou d’œuvres

…

Description de

Domaines métiers

l’architecture métier

Couverture fonctionnelle

Description de

Nom de ou des applications

l’architecture

Technologies

applicative

Nombre d’utilisateurs potentiels

Volume de données traitées

Flux entrants...

Description de

Technologie (éditeurs...)

l’architecture

technique

Description des

Nombre de rapports

rapports (identifier le

Fréquence de « diffusion »

nombre de rapports

Niveau de complexité « de lecture »

par application)

Interface utilisateur (c/s, web, etc..)…

Données – Référentiels Technologie

(identifier les sources

Type de stockage (fichier plat, relationnel, multidimensionnel)

de données pour les

Volume traité

rapports listés ci-

Performance ? (satisfaisante, insatisfaisante)

dessus)

Niveau de qualité actuel (satisfaisant, insatisfaisant)

Quels sont les projets

en cours ?

Selon vous quels sont

les risques sur un tel

projet ?

Prés requis

De quel type d’information les personnes des domaines métier

fonctionnels

cibles ont-elles besoin ?

Quels rapports veulent-elles ?

Quels rapports sont les plus importants et quels sont ceux les

moins importants ?

Quel type de requêtes les utilisateurs pourront-ils lancer ?

Qui administrera les données, les univers, etc.?

Existe-t-il au sein du Système d’information des requêtes déjà

similaires ?

Pré requis pour les

Quelles données métier les utilisateurs veulent-ils ?

données

Où trouvent-ils ces données aujourd’hui?

Comment les données sont-elles « nettoyées » aujourd’hui, et

comment doivent-elles être dans le futur ?

Quelles données sont considérées comme les plus importantes

pour les domaines métiers?

Les données peuvent-elles être agrégées, si oui, quelles sont les

dimensions ?

Les utilisateurs doivent-ils pouvoir « descendre » dans le détail, si

oui, avec quelle granularité ?

Existe-t-il des utilisateurs pouvant valider les données, si oui

quand sont-ils disponibles ?

Quels sont les délais en termes de restitution des données ?

Pré requis en termes

Quelle est la durée de stockage souhaitée ?

d’historique

Existe-t-il un historique des données à disposition ?

Pré requis sécurité

Quelle est la sécurité qui doit être appliquée ?

Quelle typologie de sécurité existe-t-il aujourd’hui ?

La sécurité doit-elle être la même pour toute la population cible ?

Qui aura accès aux données ?

Pré requis en termes

Quel est le délai maximum que les utilisateurs sont-ils prêts à

de performance

accepter ?

Quels sont les rapports qui peuvent être lancés de nuit ?

Combien de fois dans la journée les utilisateurs sont-ils

susceptibles de lancer un rapport ?

Données sources

Sait-on où sont stockées les données sources ? Est-il possible

d’avoir plusieurs sources pour une même donnée ?

Les données font-elles déjà partie intégrante d’une base de

données dans un modèle relationnel, etc. ?

Connaît-on les utilisateurs/propriétaires des données sources ?

Existe-t-il une norme d’échange d’information au sein de la

Poste ?

Qualité des données :

Connaît-on le niveau de qualité des données sources ?

Quel est le niveau de qualité attendu en rapport avec les besoins

métier ?

Qui « détient » les règles métier pour valider les données ?

Nettoyage des

Existe-t-il de la documentation sur des opérations passées de

données

nettoyage ou bien de gestion des rejets ?

Existe-t-il des tables de références ou de transcodage d’un

système à un autre ?

Qui connaît les erreurs les plus courantes survenues ?

Objectif : Faire un état des lieux du SI existant (vision fonctionnelle)

En conséquence, ce questionnaire est organisé en plusieurs parties :

· Une partie dédiée à la présentation de l’interlocuteur et de son département, service, équipe

· Une partie consacrée au modèle existant du SID

· Une partie dédiée à l’identification des axes d’améliorations alimentant la définition de la

cible

THEMES

Généralités

Nom de l’interlocuteur

Relation avec les différentes maîtrises d’ouvrages et/ou d’œuvres

Présentation du

Fonction et organisation du département, service, équipe

département, service,

Intégration au sein de l’organigramme du GMSIH

équipe

Analyse de l’existant

Description succincte l’activité actuelle (fonctionnalités)

Quels sont vos objectifs stratégiques ? (Augmenter mes

ventes…..)

Comment se structure votre activité (identification du

processus) ?

Quelles sont les informations, indicateurs que vous suivez ?

(Périodicité, fiabilité…) ?

Avez-vous des documents (référentiels, rapports type...)

décrivant ou faisant référence votre utilisation?

Quels sont les différents outils (SI, applications…) et les

différentes bases de données que vous utilisez ?

Quelles données vous remplissez dans l’application ?

Quelles données vous consultez dans l’application ?

De façon opérationnelle est-ce que l’outil décisionnel correspond à

la réalité aujourd’hui ? (par rapport à votre mode de

fonctionnement, par rapport à son positionnement comme outil

de pilotage, par rapport aux indicateurs de performance)

Pistes de réflexion

Quels sont vos besoins en termes de restitutions (que souhaitez-

pour la cible

vous suivre avec quels types de restitutions)?

Vos besoins sont-ils aujourd’hui couverts?

À quoi attribuer le fait que tous vos besoins ne sont pas

couverts (systèmes, type du modèle…) ?

Quels sont les projets en cours qui peuvent avoir une incidence

sur vos besoins de restitutions? (citez tous vos projets en cours)

Avec l’objectif de suivre vos processus, quels sont les indicateurs

qui vous voudront être capables de suivre ?

CMMI (CAPABILITY MATURITY MODEL INTEGRATION)

CMMI, sigle de Capability Maturity Model + Integration, est un modèle de référence, un

ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les

activités des entreprises d'ingénierie.

CMMI a été développé par le Software Engineering Institute de l'université Carnegie Mellon,

initialement pour appréhender et mesurer la qualité des services rendus par les fournisseurs

de logiciels informatiques du Département de la Défense US (DoD). Il est maintenant

largement employé par les entreprises d'ingénierie informatique, les Directeurs des systèmes

informatiques et les industriels pour évaluer et améliorer leurs propres développements de

produits.

LE MODELE CMMI

Le modèle CMMI définit une échelle de mesure de la maturité à 5 niveaux, ainsi que les

indicateurs nécessaires pour évaluer les activités menées par une équipe par rapport à cette

échelle - l'équipe peut être un groupe de travail, un ou plusieurs projets, une société voire

une institution d'État.

CMMI est un cadre générique de processus qui se décline en 3 modèles (appelés

constellations) :

• CMMI-DEV pour le développement de systèmes (logiciel ou autre, modèle publié en août

2006)

• CMMI-ACQ pour la maîtrise des activités d'achat (modèle publié en novembre 2007)

• CMMI-SVC pour la fourniture de services (modèle publié en février 2009)

La particularité de ces 3 modèles de processus est qu'ils ont une partie commune (le noyau

ou "core" en anglais) qui représente environ 60% des pratiques. D'un modèle à l'autre, les

différences portent essentiellement sur la catégorie « Ingénierie » dont les pratiques varient

selon l'activité concernée.

Le modèle CMMI est majoritairement utilisé dans des sociétés d'informatique, toutefois les

principes de CMMI s'appliquent à n'importe quelle activité d'ingénierie : Architecture,

mécanique, électronique...

MATURITE

D'après la définition donnée dans le CMMI, la maturité d'une organisation est le degré auquel

celle-ci a déployé explicitement et de façon cohérente des processus qui sont documentés,

gérés, mesurés, contrôlés et continuellement améliorés.

Un niveau de maturité (Maturity Level) correspond à l'atteinte d'un niveau de capabilité

uniforme pour un groupe de processus. Un niveau de capabilité (Capability Level) mesure

l'atteinte des objectifs d'un processus pour le niveau donné.

HISTORIQUE

Dans les années 1980, le Département de la Défense des États-Unis (DoD) a demandé

l'élaboration d'un référentiel de critères lui permettant d'évaluer ses fournisseurs de logiciels.

Après une lente maturation, le SEI (Software Engineering Institute) financé par le DoD a

présenté en 1991 le Capability Maturity Model (CMM). Ce modèle de référence ne concerne

que les bonnes pratiques du génie logiciel. Après un fort engouement pour ce modèle,

d'autres modèles similaires ont vu le jour, tels que :

• SE-CMM (pour System Engineering) ;

• SA-CMM (pour Software Acquisition) ;

• IPD-CMM (pour Integrated Product Development) ;

• People CMM pour le management des ressources humaines ;

• SS-CMM pour Supplier Sourcing.

Tant et si bien qu’il fallut rebaptiser le CMM « initial » en SW-CMM (pour Software). En 2001,

le SEI a proposé une nouvelle version de son modèle, le CMMI (Capability Maturity Model

Integration) qui englobe les bonnes pratiques des autres modèles, sauf la gestion des

ressources humaines qui n'est pas encore considérée (version 1.1). La version actuelle du

modèle a été réactualisée en 2006 (version 1.2). Cette dernière version du CMMI tend à

simplifier le modèle et améliore la prise en compte des composants de type matériel.

Le CMMI-DEV est un modèle de processus (référentiel de bonnes pratiques) pour la

réalisation de tout type de produit (ou système). C'est cependant dans le développement et la

maintenance de logiciel qu'il est le plus utilisé. Sa portée utile s'étendant de l'apparition d'un

besoin jusqu'à la livraison du produit correspondant, il y a d'autres modèles utiles pour

d'autres domaines du logiciel, par exemple pour les infrastructures et opérations ITIL.

DESCRIPTIF DU MODELE

Dans l'approche étagée (il existe une approche dite "continue"), les bonnes pratiques

préconisées par le modèle (version 1.2) sont rassemblées en 22 domaines de processus eux-

mêmes regroupés en 5 niveaux de maturité. Les domaines de processus rattachés à un

niveau de maturité M ne peuvent être stabilisés et efficaces que si les domaines de processus

des niveaux inférieurs (< M) sont déjà stabilisés et efficaces (principe d'empilement). Les 5

niveaux sont :

• Initial (niveau de maturité 1) : Il n'y a pas de grand pilier directionnel, aucune façon de

faire ou standard ne sont établis (ou bien ils sont documentés, mais ne sont pas utilisés), tout

doit être fait. Il n'y a pas de surveillance (monitoring), aucune évaluation de performance et

la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont

pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux

incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les

solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les

compétences et les ressources propres de cet individu sont la raison du succès ou de l'échec

du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n'y a pas de

description du niveau de maturité 1 dans le modèle.

• « managed », soit discipliné en français (niveau de maturité 2) : Une discipline est établie

pour chaque projet et se matérialise essentiellement par des plans de projet (plan de

développement, d'assurance qualité, de gestion de configuration ...). Le chef de projet a une

forte responsabilité dans le niveau 2 : Il doit définir, documenter, appliquer et maintenir à

jour ses plans. D'un projet à l'autre, il capitalise et améliore ses pratiques de gestion de projet

et d'ingénierie.

• « Defined », sois ajusté en français (niveau de maturité 3) : ce niveau est caractérisé par

une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur

les mesures réalisées dans les projets) et une maîtrise du référentiel interne (ou Système

Qualité). Il existe des lignes directrices, un plan stratégique et une planification de

l'amélioration de processus pour le futur, en ligne avec les objectifs d'affaire de l'organisation.

Les employés sont formés et conscients de leurs responsabilités ainsi que de leurs devoirs.

• « Quantitatively managed », soit géré quantitativement en français (niveau de maturité

4) : les projets sont pilotés sur la base d'objectifs quantitatifs de qualité produit et processus.

La capacité des activités (ou sous-processus) critiques est déterminée par l'organisation, ainsi

que les modèles de performance et de prévision associés. L'expression de la qualité

demandée par le client est prise en compte pour quantifier les objectifs du projet et établir

des plans selon la capacité des processus de l'organisation.

• « Optimizing », soit en optimisation en français (niveau de maturité 5) : Les processus qui

sont gérés quantitativement pour le pilotage de projet (niveau de maturité 4) sont en

optimisation constante afin d'anticiper les évolutions prévues (besoins clients, nouvelles

technologies...).

LE NIVEAU 1

Le niveau 1 initial est le niveau où le résultat final est imprévisible. À ce niveau l'effort

individuel prévaut à l'effort collectif dirigé vers un but établi. L’atteinte des résultats repose

plus sur les hommes, sur leur engagement et bonne volonté, que sur l’application disciplinée

de bonnes pratiques. La réussite d'un projet repose en général sur le talent d'un individu,

c'est pourquoi on surnomme ironiquement ce niveau l'ère des héros. Mais une réussite

éventuelle ne sera pas nécessairement reproductible. L'évaluation de l'efficacité et des

performances est absente. La direction n'établit pas de plan ou de vision qui sont liés