Archive

Archives pour la catégorie ‘Référentiels’

CobiT

19/07/2010 Comments off

Le CobiT (Control Objectives for Information and related Technology – Contrôle de l’Information et des Technologies Associées) est un outil fédérateur qui permet d’instaurer un langage commun pour parler de la Gouvernance des systèmes d’information tout en tentant d’intégrer d’autres référentiels tels que ISO 9000, ITIL…

La gouvernance des Systèmes d’Information (SI) (Information Technology (IT) Governance) s’est introduite au sein des entreprises dans un contexte où d’une part, l’automatisation des fonctions de l’entreprise est devenue une composante essentielle au sein de l’entreprise et d’autre part, où les dirigeants ne voient pas comment les SI peuvent apporter de la valeur et de la performance dans l’organisation. Ainsi, on peut parler de gouvernance des SI et donc de normes, certifications permettant cette dernière. C’est également dans un souci de transparence des informations que les SI se sont développés et que leur contrôle est devenu incontournable. Le référentiel principal de gouvernance et d’audit des SI est le CobiT. En résumé le CobiT est un cadre de référence pour maitriser la gouvernance des SI dans le temps. Il est fondé sur ensemble de « meilleures pratiques » collectées auprès d’experts du SI.

Lire la suite…

ITIL : Le référentiel

18/05/2007 Comments off

1. Introduction

L’objectif d’un référentiel comme ITIL est d’améliorer l’efficacité des services informatiques. L’utilisation d’un référentiel de bonnes pratiques permet :
- La réduction des coûts
- Le contrôle des coûts
- La prise en compte de l’attente client
- La qualité de service
- La réponse aux besoins

En France, les bonnes pratiques (bests practices) d’ITIL s’imposent comme méthode de gestion des systèmes d’information par les processus.

Les meilleurs pratiques d’ITIL permettent de rationnaliser la gestion des incidents, des changements et des mises en production, d’éradiquer les pannes les plus fréquentes à leur source et d’éliminer les gestions de crise en mode « pompier ».

ITIL a permis à l’informatique Voyageurs (Socrate) de la SNCF d’améliorer la qualité et les performances globales du système, la fusion de la production et des équipes informatiques du Crédit Agricole et LCL s’est reposée sur les processus ITIL.

Renault a mis en œuvre des processus transversaux avec ses prestataires de services : HP pour la gestion des postes de travail, CSC pour l’infrastructure technique et Atos Origin pour le parc applicatif. ITIL a permis un alignement de toutes les parties prenantes sur un langage normé.

Le même constat est fait chez Accenture (cabinet de conseil) : ITIL permet un dialogue entre différentes organisations en instaurant un « langage commun et normé ». ITIL permet de passer d’une culture « orale » à une culture « écrite », chez Prisma Presse, depuis la mise en place d’ITIL, l’installation d’un serveur ou d’un poste de travail ne nécessite plus l’intervention d’une personne en particulier, la documentation permet à chacun d’installer et de configurer le matériel.

La rigueur des procédures d’ITIL empêche les changements et mises en production « sauvages » qui sont facteurs de fortes perturbations dans le SI. Renault constate une baisse des coûts des interventions et que le système d’information est arrêté moins longtemps.

Les utilisateurs d’ITIL sont convaincus que cette méthode leur permet de « faire plus avec les mêmes moyens », la capacité de production de la SNCF a pratiquement doublé en trois ans, Altaïr (groupe Natexis), traite des événements complexes avec une forte réactivité et une marge d’erreur réduite.

2. Historique

ITIL a été lancé à la fin des années 80 et est devenu un standard de fait dans la gestion des services de l’information. ITIL a été développé et conçu sur l’initiative du gouvernement britannique, il s’agit d’un ensemble de bonnes pratiques destinées a améliorer l’efficacité des services informatiques. Le CCTA (Central Computer & Telecommunication Agency) fut à l’origine de la création d’ITIL puis a été ensuite repris par l’OGC (Office of Government Commerce).

3. Présentation

ITIL & BS15000 (Norme britannique élaborée par l’office de normalisation britannique). La norme ISO associée à la qualité de service, l’exigence de fiabilité et de continuité de services est l’ISO 20000-1. Elle adopte les principes de management de l’ISO-9001 et les processus recensés dans ITIL. ITIL (Information Technology Infrastructure Library) est une bibliothèque d’infrastructure des technologies de l’information. Il s’agit d’un ensemble de livres dans lesquels sont référencés des pratiques, procédures et méthodes permettant de gérer les systèmes d’information. ITIL est dans le domaine public, son utilisation est libre. Seuls les livres sont vendus. ITIL est basé sur trois grands principes que sont l’orientation client, l’industrialisation des services et l’optimisation des ressources. ITIL permet de guider et d’orienter la transformation des Directions Informatique sur les plans organisationnels et techniques afin qu’elles puissent fournir des services dont la qualité, la productivité et la maîtrise des coûts soient conformes aux objectifs de l’entreprise. ITIL définit un langage commun à tous les utilisateurs du système d’information (utilisateurs et équipes techniques). La mise en place d’un projet ITIL passe par la création d’une base de données unique des configurations (CMDB) qui sera le socle commun à tous les processus de production. Cet inventaire débouche sur la rédaction de contrats de services (SLA – Service Level Agreement), un plan d’assurance qualité et un système de refacturation.

3.1. Les concepts ITIL repose sur cinq concepts fondamentaux :
- La prise en compte de l’attente du client ITIL est basé sur l’importance de la qualité de service et l’alignement de ces services aux besoins de l’entreprise. La prise en compte des besoins du client et de son métier doit être la préoccupation d’un service informatique.
- Les cycles de vie des projets informatiques ITIL propose la mise en place de processus dès le lancement d’un projet de façon à prendre en considération tous les aspects liés à un nouveau projet. ITIL préconise la prise en compte de la gestion des services dès les phases d’études et de définition des besoins d’un projet informatique.
- La mise en place des processus ITIL La qualité de service, dans le cadre d’ITIL, est basée sur des processus interdépendants. Ces processus sont constitués d’activités : contrôles, actions, … .
- La qualité de service La qualité de service est basée, et perçue par les utilisateurs, sur l’efficacité de la réponse face à la demande. Elle nécessite un dialogue permanent avec le client afin de prendre en compte les évolutions de ses besoins.
- La communication ITIL définit un langage commun aux utilisateurs et aux membres des services informatiques. Ce langage définit les termes utilisés dans les rapports et contrats de service (SLA), de la sorte, chacun parle le même langage (utilisateurs et services informatiques).

La qualité de service est basée sur une structuration des activités en processus interdépendants. Un processus (ou procédure) peut être évalué (niveau de qualité ou de maturité). Un processus est un ensemble d’activités liées entre elles.

3.2. Les organismes et certifications Plusieurs organismes contribuent au support d’ITIL, on trouve :
- OGC L’OGC est l’organisme propriétaire d’ITIL
- EXIN,ISEB Ces deux organismes, l’un britannique et l’autre néerlandais assument le rôle de coordinateur des certifications ITIL.
- ITSMF itSMF est une association internationale dédiée à la promotion d’ITIL et est représentée dans chaque pays
- Les centres de formation Les certifications sont au nombre de trois :
- Niveau de base, les fondations (Foundation Certificate in IT Service Management)
- Niveau praticien expert (Practitioner Certificate in IT Service Management)
- Niveau responsable/gestionnaire (Service Delivery Certificate & Service Support Certificate)

4. Le modèle de maturité

Le modèle de maturité d’ITIL permet d’évaluer le positionnement d’une organisation informatique. Le modèle propose d’évaluer chaque processus et de les situer sur un des niveaux de maturité. Le modèle de maturité d’ITIL est de type « escalier », chaque marche représentant un niveau de maturité d’un processus. ITIL dénombre cinq niveaux de maturité :
- Niveau 1 : Initial (ou inexistant) Le processus n’est pas géré et ne dispose d’aucune ressource. Il s’agit du point de départ du processus pour la mise en place d’un projet ITIL.
- Niveau 2 : Répétable Des moyens ont été alloués pour la gestion du processus. Les activités liées au processus ne sont pas coordonnées mais permettent d’atteindre un résultat.
- Niveau 3 : Défini Le processus possède des objectifs, un propriétaire, des ressources lui sont allouées. Des rapports et des résultats sont disponibles et mis à disposition pour consultation.
- Niveau 4 : Géré Le processus dispose d’objectifs basés sur les besoins de l’entreprise, il est géré et proactif. Le processus et ses liens avec les autres processus sont documentés.
- Niveau 5 : Optimisé Le processus est totalement intégré à l’entreprise, ses objectifs sont alignés aux besoins de l’entreprise.

5. La structure d’ITIL

La librairie ITIL est architecturée autour de cinq éléments fondamentaux interdépendants (habituellement présentés sous forme de puzzle). Ces cinq éléments sont :
- L’approche métier,
- Gestion des applications,
- Fourniture des services aux TI,
- Soutien des services aux TI,
- Gestion des infrastructures des TI

ITIL est composé de huit livres :
- L’approche métier,
- Planification de la mise en œuvre de la gestion des services
- La fourniture des services,
- Le soutien des services,
- Gestion des infrastructures TIC
- Gestion des applications
- Gestion des actifs logiciels
- Gestion de la sécurité Les deux principaux livres, ceux qui ont contribué au succès d’ITIL, étant la fourniture et le support des services aux TIC.

6. L’approche métier (The Business Perspective)

Principes et besoins des organisations métier et communication avec le service informatique :
- Plans de continuité métiers (Business Continuity Management)
- Externalisations et partenariats (Surviving Change)
- Transformation des pratiques métiers au travers de changements radicaux (Transformation of Business Practice through radical change) L’approche de la fourniture des services informatiques selon la perspective métier est basée sur les besoins de l’entreprise. Cette approche permet d’assurer la fourniture des services au plus près des de la demande. L’objectif de cette approche est l’alignement de l’informatique avec les besoins de l’entreprise.

7. Le soutien des services aux TI (Service Support)

Le soutien des services aux TI est composé d’une fonction, le centre de services, et de cinq processus :
- La gestion des configurations
- La gestion des incidents,
- La gestion des problèmes,
- La gestion des changements,
- La gestion des mises en production,

7.1. Le centre de services (Service Desk) Le rôle du centre de service est de prendre en charge les incidents qui surviennent au sein du système d’information afin d’en assurer un traitement rapide et de rétablir le service le plus rapidement possible. Le centre de services est le déclencheur de changements sur le SLA (Service Level Agreement).

7.2. La gestion des configurations (Configuration Management) La gestion des configurations est un processus de documentation indispensable, son but est de fournir une représentation la plus fidèle possible du système d’information en identifiant les versions de tous les composants de l’infrastructure (Configuration Item ou CI). Ce processus sert à constituer la base de données des configurations (Configuration Management Database : CMDB). Cette CMDB doit au moins contenir les informations suivantes :
- Fournisseur
- Coût
- Date d’achat
- Date de renouvellement de licence et de maintenance
- Historique du CI : versions, incidents, problèmes et changements La constitution d’une bibliothèque logicielle de versions définitives (Definitive Software Library : DSL) permet de stocker les versions définitives et validées de tous les composants logiciels du système d’information.

7.3. La gestion des incidents (Incident Management) Un incident est un événement ne faisant pas partie du fonctionnement normal d’un service ou d’un équipement et qui cause ou peut causer une interruption de service. Le but principal de la gestion des incidents est de rétablir le fonctionnement normal du service et d’en minimiser l’impact pour l’entreprise. La gestion des incidents traite les conséquences et non les causes.

7.4. La gestion des problèmes (Problem Management) L’objectif de la gestion des problèmes est de minimiser les conséquences des dysfonctionnements du système d’information en identifiant les causes afin d’éviter qu’ils ne se reproduisent. La gestion des incidents agit pour résoudre au plus vite ou trouver un palliatif, la gestion des problèmes doit identifier les causes des dysfonctionnements et proposer les changements éventuels qui permettent de les corriger. La gestion des problèmes permet de trouver des solutions aux problèmes issus d’incidents signalés au centre de service.

7.5. La gestion des changements (Change Management) Les systèmes d’information sont soumis à des événements extérieurs et intérieurs. Les événements intérieurs peuvent être issus d’incidents, de problèmes ou d’évolutions du SI. Les événements extérieurs peuvent être des évolutions réglementaires, légales ou simplement des évolutions du marché. L’objectif de la gestion des changements est de maintenir un niveau de fonctionnement du système d’information conforme aux engagements de niveau de service (SLA : Service Level Agreement). Le but est d’éviter une régression suite à la mise en place de changements.

7.6. La gestion des mises en production (Release Management) La gestion de la mise en production permet de s’assurer que seules les versions autorisées et testées des logiciels et matériels sont mises en production. Ce processus permet aussi de s’assurer que tous les aspects d’une mise en production, aussi bien techniques que non techniques sont pris en considération, et permet également la traçabilité des changements. Ce processus intervient après la gestion des changements et la gestion des configurations.

8. La fourniture des services aux TI (Service Delivery)

Le module de fourniture des services correspond à l’interface entre les clients et l’informatique, il couvre les aspects prévisionnels de fourniture des services et correspond aux processus :
- Gestion des niveaux de service (SLM – Service Level Management),
- Gestion financière des services,
- Gestion de la capacité,
- Gestion de la continuité de service,
- Gestion de la disponibilité.

8.1. La gestion des niveaux de service (Service Level Management) La gestion des niveaux de service permet de valider les besoins et les exigences des clients (SLR – Service Level Requirement). Le maintien et l’amélioration de la qualité des services seront assurer par des accords (contractuels) de niveaux de service (SLA – Service Level Agreement)

8.2. La gestion de la capacité (Capacity Management) La gestion de la capacité est le processus permettant d’assurer que l’infrastructure du système d’information est en mesure de répondre aux besoins de l’entreprise. Les capacités de l’infrastructure du système d’information sont :
- les performances des traitements,
- les volumes de stockage,
- le débit des liens de communication,
-

8.3. La gestion de la disponibilité (Availability Management) Ce processus doit assurer un niveau de disponibilité compatible avec les contrats de service (SLA). Pour atteindre cet objectif, il est indispensable de déterminer précisément les besoins métier et les fonctions vitales de l’entreprise (identifiés dans le SLA). A chacun de ces besoins doit correspondre une réponse technique et organisationnelle.

8.4. La gestion de la continuité des services aux TI (IT Continuity Management) Ce processus doit permettre d’assurer un niveau de service « convenu » en cas d’événement grave. La gestion de la continuité de service s’appuie sur des mesures d’analyses de risques, la mise en place de systèmes redondants, un plans de sauvegarde, plans de reprise d’activité (PRA), … .

8.5. La gestion financière des services aux TI (Financial Management for IT Services) La gestion financière des services remplit les rôles suivants :
- Elle établit les budgets annuels de fonctionnement et d’investissement,
- Elle suit et contrôle les dépenses des services,
- Elle aide à concevoir une stratégie d’investissement,
- Elle prend des décisions en fonction des investissements passés et de leurs conséquences sur le système d’information

9. Planification pour la mise en œuvre des services

Ce module concerne le projet d’implantation et d’amélioration de processus ITIL dans une entreprise. Elle est composée de six étapes :
- Définition des objectifs,
- Evaluation de la situation actuelle de l’organisation informatique (audit, benchmarking, …), niveau de maturité,
- Définition des rôles et caractéristiques de la nouvelle organisation,
- Elaboration du plan du projet d’implantation ou d’amélioration,
- Evaluation des progrès,
- Evaluation des améliorations à apporter, puis retour à l’étape 1.

Cycle des activités d’implantation :

10. Gestion de la sécurité

La gestion de la sécurité informatique est le processus permettant de gérer un niveau défini de sécurité des services informatiques, de l’infrastructure et de l’information qui y transite. La gestion de la sécurité concerne l’ensemble des processus de la gestion des services. Cet aspect est particulièrement important en France car le dirigeant de l’entreprise est pénalement responsable des problèmes de sécurité de l’entreprise.

11. Gestion des infrastructures des TIC

Gestion des composants techniques de l’infrastructure informatique :
- Gestion des réseaux (Network Service Management),
- Gestion des opérations (Operations Management),
- Gestion des serveurs distants,
- Installation et validation des serveurs,
- Gestion des systèmes

12. La gestion des actifs logiciels

La gestion des actifs logiciels prend en charge les questions liées à l’utilisation des logiciels dans l’entreprise :
- Logistique : – Evaluation, – Achat, – Déploiement, – Désinstallation,
- Contrôle : – Audit, – Licences,
- Sécurité
- Liaisons : – Contrats, – Fournisseurs, – Développements externes

13. Gestion des applications

La gestion des applications permet de gérer le cycle de développement d’une application :
- Définition des besoins, demandes,
- Conception
- Développement, fabrication,
- Déploiement,
- Mise en production,
- Mise au point, optimisation,

14. Les relations entre les processus

Les processus ITIL sont tous interdépendants.

• Gestion des configurations La gestion des configurations fait partie de tous les autres processus de la gestion des services, elle fournit un ensemble d’informations sur tous les composants de l’infrastructure (matériels, logiciels, procédures, …)

• Centre de services Ce processus est le point de contact entre les utilisateurs et les fournisseurs de services. Toutes les demandes utilisateurs passent par le centre de services.

• Gestion des incidents Ce processus est lié à la gestion des problèmes afin d’identifier les causes, à la gestion des changements pour la mise en place de modifications.

• Gestion des problèmes Ce processus est lié à la gestion des incidents et à la gestion de la disponibilité.

• Gestion des changements Ce processus dépend des données de configuration afin de s’assurer de l’impact d’un changement sur l’infrastructure. • Gestion des mises en production Gestion des changements et gestion des configurations Gestion des incidents et des problèmes pour l’évaluation des régressions. • Gestion des niveaux de service (SLM) La gestion des niveaux de service est la charnière entre le soutien des services et la fourniture des services. • Gestion de la capacité Ce processus est sollicité par la gestion des incidents et des problèmes et est en relation avec la gestion des changements et de la mise en production lors de demandes d’évolution. • Gestion financière des services informatiques Ce processus est lié avec la gestion de la capacité pour identifier les investissements, la gestion de la configuration pour les amortissements matériels et la gestion des niveaux de service pour les dépenses de service. • Gestion de la disponibilité Un lien avec la gestion des incidents ainsi que la gestion des problèmes est nécessaire afin de comprendre les défaillances et d’évaluer les temps de reprise de service. • Gestion de la continuité de service La gestion de la continuité de service dépend de la gestion des configurations pour prévenir et planifier les procédures de sauvegarde et les plans de reprise d’activité. • Gestion de la sécurité La gestion de la sécurité est impliquée dans tous les processus, évaluation d’un changement sur la sécurité de l’infrastructure, … . • Gestion de l’infrastructure TIC Lien avec la majorité des processus pour lesquels des questions techniques se présentent : gestion de la capacité, gestion de la disponibilité, soutien des services, fourniture des services.

15. Acronymes

ACD Automatic Call Distribution
BSI British Standards Institution
CAB Change Advisory Board
CAB/EC Change Advisory Board/Emergency Committee CASE Computer-Aided Systems Engineering CCTA Central Computer and Telecommunications Agency CI Configuration Item CMDB Configuration Management Database COP Code of Practice CTI Computer Telephony Integration DHS Definitive Hardware Store DSL Definitive Software Library EDI Electronic Data Interchange EFQM European Foundation for Quality Management FSC Forward Schedule of Change GUI Graphical User Interface ICAM Integrated Computer-Aided Manufacturing ICT Information and Communications Technology IDEF ICAM Definition IP Internet Protocol IR Incident Report ISO International Standards Organisation IT Information Technology IVR Interactive Voice Response KER Known Error Record KPI Key Performance Indicator KSF Key Success Factors LAN Local Area Network MBNQA Malcolm Baldridge National Quality Award MTBF Mean Time Between Failures OLA Operational Level Agreement PC Personal Computer PIR Post-implementation Review PR Problem Record PRINCE Projects IN Controlled Environments PSA Projected Service Availability RFC Request for Change SCI Software Configuration Item SCM Software Configuration Management SIP Service Improvement Program SLA Service Level Agreement SLM Service Level Management TOR Terms of Reference TP Transaction Processing VOIP Voice Over Internet Protocol WAN Wide Area Network WIP Work in Progress WFD Work flow diagram

CMMi

16/05/2007 Comments off

1. Présentation

CMMi, Capability Maturity Model Integration (Modèle intégré du niveau de maturité), est une extension de la spécification CMM, créée pour le ministère de la Défense américain en 1989 afin de déterminer si un projet interne ou tiers serait terminé dans les temps, selon le budget et les spécifications prévus. Ce dispositif contribue à l’amélioration des processus et à l’évaluation du niveau de maturité de l’entreprise, c’est-à-dire son aptitude à maîtriser le développement et la maintenance de produits. CMMi intègre les spécifications SW, SE, IPPD et SS établies pour pallier les manques de CMM :
- SW (Software) couvre le développement de logiciels,
- SE (System Engineering) couvre le développement de systèmes (incluant ou non une partie logicielle), l’objectif est de couvrir les demandes clients en terme de produits et de support,
- IPPD (Integrated Product and Process Development) couvre la gestion des processus, la gestion de projets et le support,
- SS (Supplier Sourcing) couvre l’appel à des fournisseurs pour la réalisation de fonctions

CMMi est une approche d’ingénierie des systèmes couvrant les compétences et processus techniques et managériaux permettant de transformer des besoins utilisateurs en un produit technique. C’est un modèle de développement et de maintenance des systèmes et des applications informatiques. Il a été conçu à partir des meilleures pratiques du logiciel, par le SEI (Software Engineering Institute) et des représentants de l’industrie du logiciel.

CMMI est un référentiel d’évaluation de la capacité à gérer et terminer un projet (ou un produit) correctement (dans les temps et dans les budgets définis), proposant nombre de bonnes pratiques liées à la gestion, au développement et à la maintenance d’applications et de systèmes. Ces bonnes pratiques sont regroupées en 24 processus, eux-mêmes regroupés en 4 types (Process Management, Project Management, Engineering et Support) et 5 niveaux de maturité.

2. Les organismes et certifications

Les évaluateurs sont accrédités par le SEI (Software Engineering Institut). Il n’y a pas de certificat délivré par un organisme, mais des évaluations conduites par un « lead assessor », qui délivre une attestation indiquant le niveau de maturité atteint.

3. Les composants de CMMi

Cette section décrit les différents types d’informations rencontrés dans le modèle CMMi ainsi que leur importance. 3.1. Les domaines de processus L’élément fondamental de CMMi est le « domaine de processus », CMMi regroupe un ensemble de processus (ou procédures) regroupés dans des domaines. Un processus a :
- un but : gérer un projet, définir des besoins clients, …
- Des objectifs qui décrivent le résultat à atteindre,
- Des pratiques qui permettent d’atteindre ce résultat,
-

3.2. Classification Un modèle d’amélioration des processus doit inclure une échelle de valeur permettant de donner une importance à chaque élément. Dans le modèle CMMi, les termes « required », « expected » et « informative » permettent de définir l’importance d’un élément.

3.3. Les pré requis Le principal composant pré requis dans CMMi est l’objectif, le but à atteindre. Le but représente un état final, il indique qu’un projet et que des processus ont atteint un certain niveau. Chaque processus CMMi a entre un et quatre objectifs spécifiques, le modèle CMMi possède 55 objectifs spécifiques.

3.4. Informative materials

3.5. Les documents

4. Les représentations de CMMi

Un modèle est une représentation simplifiée de la réalité ; un modèle de maturité CMM® (Capability Maturity Model®) contient les éléments essentiels des processus opérationnels pour un ou plusieurs corpus de compétence. Comme les autres modèles CMM, les modèles CMMi (Capability Maturity Model Integration®) proposent un guide de développement des processus. Les modèles CMMi ne sont ni des processus, ni des représentations de processus. Les processus effectifs exécutés dans une organisation dépendent de multiples facteurs – domaine(s) applicatif(s), caractéristiques de structure et taille de l’entreprise, etc. Pour sélectionner un modèle adapté à l’entreprise, il faut choisir une représentation, qui sera dite « continue » ou « étagée », et déterminer les corpus de compétences qui y seront intégrés. Plusieurs raisons peuvent conduire au choix d’une représentation ou de l’autre ; les avantages et désavantages respectifs des deux approches sont synthétisés ci-dessous. Cependant, qu’il s’agisse d’évaluation ou d’amélioration des processus, les deux représentations offrent des résultats sensiblement équivalents. Chaque représentation est composée de niveaux correspondants à des objectifs à atteindre, pour chacun de ces objectifs, CMMi propose des pratiques générales (« generic pratices » ou GPs) ainsi que des pratiques spécifiques (« specific practices » ou SPs). Les pratiques générales s’appliquent à tous les processus tandis que les pratiques spécifiques sont particulières à un processus.

4.1. La représentation étagée La représentation étagée définit un plan d’évolution et permet de réaliser les opérations suivantes :
- Fournir une séquence d’améliorations, débutant par des pratiques de management élémentaires et progressant à travers un cheminement éprouvé de passages d’un niveau à l’autre.
- Favoriser les comparaisons internes et externes à travers les niveaux de maturité.
- Fournir une notation unique synthétisant les résultats d’évaluation et permettant des comparaisons. Ce plan d’évolution est décrit à l’aide d’une série d’étapes appelées « Niveaux de maturité » (MLs). A chaque niveau de maturité correspond un ensemble de processus indiquant des objectifs à atteindre pour améliorer l’organisation. La représentation est faite par le niveau de maturité de l’entreprise et composée de cinq niveaux :
- ML1 : Initial Les projets ne sont pas gérés, les processus sont chaotiques, ce niveau est souvent appelé « niveau héroïque ». Les budgets et plannings de réalisation sont souvent dépassés, on parle souvent de mode « pompier ».
- ML2 : Géré Des procédures sont mises en place pour chaque projet.
- ML3 : Défini Les processus sont définis et documentés au niveau de l’organisation.
- ML4 : Maitrisé L’organisation se fixe des objectifs quantitatifs et qualitatifs et se dote de moyens pour contrôler qu’ils sont atteints. Niveau 5 – En optimisation Les processus sont en conti
- ML5 : En optimisation Les processus sont en continuelle amélioration.

Les niveaux de maturité sont représentés dans le schéma suivant :

Regroupement des processus dans la représentation étagée : Regroupement étagé Acronymes Domaines de Processus Niveau de maturité 2 REQM Requirements Management (Gestion des exigences) PP Project Planning (Planification du projet) PMC Project Monitoring and Control (Conduite et maitrise du projet) SAM Supplier Agreement Management (Gestion des achats) MA Measurement and Analysis (Production et analyse les indicateurs) PPQA Process and Product Quality Assurance (Assurance qualité des processus et des produits) CM Configuration Management (Gestion de configuration) Niveau de maturité 3 RD Requirements Development (Expression des besoins) TS Technical Solution (Solution technique) PI Product Integration (Intégration du produit) VER Verification (Recette technique) VAL Validation (Recette fonctionnelle) OPF Organizational Process Focus (Gestion de l’organisation des processus) OPD Organizational Process Definition (Définition de l’organisation) OT Organizational Training (Formation à l’organisation) IPM Integrated Project Management (Gestion multidisiplinaire de projet) RSKM Risk Management (Gestion des risques) IT Integrated Teaming (Gestion d’une équipe intégrée) ISM Integrated Supplier Management (Intégration de la gestion des achats) DAR Decision Analysis and Resolution (Méthode de prise de décision) OEI Organizational Environment for Integration (Organisation de l’intégration) Niveau de maturité 4 OPP Organizational Process Performance (Performance des processus) QPM Quantitative Project Management (Gestion quantitative du projet) Niveau de maturité 5 OID Organizational Innovation and Deployment (Innovation organisationnelle) CAR Causal Analysis and Resolution (Analyse causale et solution des problèmes)

La représentation continue comprend 12 pratiques générales (Generic practices) réparties dans les 5 niveaux de maturité (CLs). Ces pratiques (GP) représentent les objectifs à atteindre pour obtenir un niveau de maturité.

4.2. La représentation continue La représentation continue permet de réaliser les opérations suivantes :
- Sélectionner l’ordre d’amélioration le plus adapté aux objectifs de l’entreprise et limiter les zones de risque.
- Permettre les comparaisons internes et externes sur un domaine de processus ou par comparaison des résultats (équivalence étagée).
- Simplifier la migration de EIA/IS 731 (Electronic Industries Alliance/Interim Standard) vers CMMi.
- Simplifier la comparaison de l’amélioration des processus avec le standard ISO/IEC 15504 (issue de SPiCE) – en raison de l’organisation similaire des domaines de processus.

La représentation continue regroupe les processus en quatre grandes catégories : Gestion de processus, gestion de projets, ingénierie et support. L’évaluation suivant le modèle continu s’effectue par processus. Les pratiques sont regroupées en « Niveaux de capacité » (CLs). Le modèle continu de CMMi dénombre six niveaux de capacité :
- CL0 : Incomplet Ce niveau ne contient aucun objectif, il s’agit du niveau initial d’un processus.
- CL1 : Réalisé Les objectifs sont atteints, mais cette réussite repose essentiellement sur les individus.
- CL2 : Géré Les objectifs sont remplis en suivant des plans pré-établi.
- CL3 : Défini Une politique de normalisation des processus est mise en place au niveau de l’organisation.
- CL4 : Maitrisé Des mesures sont effectuées pour contrôler les processus et agir en cas de déviation par rapport aux objectifs de l’organisation.
- CL5 : En optimisation Les processus sont sans cesse remis en question afin d’être toujours en adéquation avec les objectifs de l’organisation.

Il s’agit d’une représentation par amélioration des processus.

Regroupement des processus dans la représentation continue : Regroupement continu Acronymes Domaines de Processus Gestion des processus OPF Organizational Process Focus OPD Organizational Process Definition OT Organizational Training OPP Organizational Process Performance OID Organizational Innovation and Deployment Gestion de projet PP Project Planning PMC Project Monitoring and Control SAM Supplier Agreement Management IPM Integrated Project Management RSKM Risk Management IT Integrated Teaming ISM Integrated Supplier Management QPM Quantitative Project Management Engineering REQM Requirements Management RD Requirements Development TS Technical solution PI Product Integration VER Verification VAL Validation Support CM Configuration Management PPQA Process and Product Quality Assurance MA Measurement and Analysis DAR Decision Analysis and Resolution Niveau de maturité 5 OEI Organizational Environment for Integration CAR Causal Analysis and Resolution

La représentation continue comprend 17 pratiques générales (Generic practices) réparties dans les 5 niveaux de capacité (CLs). Ces pratiques (GP) représentent les objectifs à atteindre pour obtenir un niveau de capacité.

5. Les processus CMMi

Un processus atteint un niveau lorsqu’il répond à tous les objectifs prédéfinis à un niveau donné. Pour chaque processus et chaque niveau, un document CMMi (contrat) est établit, ce document contient :
- Un but (objet du processus)
- Une note d’introduction décrivant les objectifs à atteindre
- Des références à d’autres documents d’autres processus
- Les pratiques et buts associés à atteindre (Liste des Generic practices & Specific practices)

5.1. Le domaine gestion des processus Le domaine gestion des processus contient les pratiques relatives à la définition, la planification, le déploiement, l’implémentation, le contrôle et l’amélioration des processus. Les cinq processus qui le compose sont :
- Organizational Process Definition (OPD),
- Organizational Process Focus (OPF),
- Organizational Process Performance (OPP),
- Organizational Innovation and Deployment (OID),
- Organizational Training (OT).

5.1.1. Définition de l’organisation (Organizational Process Definition) Le but de ce processus est de définir et de maintenir l’ensemble des objectifs financiers des processus. Il s’agit d’établir une description du cycle de vie du projet, des critères de mise en production. Les buts sont :
- Définition du cycle de vie de chaque projet
- Etablissement des processus standards de l’organisation,
- Budget des procédures utilisées par les projets

5.1.2. Gestion de l’organisation des processus (Organizational Process Focus) L’objectif est de planifier et d’implémenter des processus d’amélioration de l’organisation. Les buts sont :
- Etablissement des besoins,
- Planification et mise en place des activités d’amélioration des processus

5.1.3. Performance des processus (Organizational Process Performance) Il s’agit d’établir et de maintenir un niveau de performance des processus standards de l’organisation. Les buts sont :
- Gestion de la qualité et de la performance des processus,
- Fourniture de données sur la performance

5.1.4. Innovation organisationnelle (Organizational Innovation and Deployment) L’objectif de ce processus est de sélectionner et de déployer des améliorations qui augmentent le niveau des processus de l’organisation. Les améliorations doivent respecter le niveau de qualité fixé par les objectifs métiers de l’entreprise.

5.1.5. Formation à l’organisation (Organizational Training) L’objectif de ce processus est de former et développer le niveau de connaissance des intervenants du SI afin qu’ils puissent remplir leur rôle efficacement.

5.2. Le domaine gestion des projets Le domaine gestion des projets couvre les activités de planification, et suivi du projet. Le modèle CMMi comprend six domaines de processus de gestion de projet :
- Project Planning (PP),
- Project Monitoring and Control (PMC),
- Integrated Project Management (IPM),
- Quantitative Project Management (QPM),
- Supplier Agreement Management (SAM),
- Risk Management (RSKM),

5.2.1. Planification de projet (Project Planning) Il s’agit de définir les variables qui permettent de mesurer l’avancement du projet, après avoir éventuellement découpé celui-ci en phases, et d’estimer chemin faisant les coûts et délais restants prévisibles. L’accent est mis sur le caractère rationnel des évaluations (elles doivent être quantitatives, on doit pouvoir les justifier et les expliquer). Un plan de projet permettra de suivre la consommation du budget et le calendrier de réalisation. Les risques, les ressources et les connaissances nécessaires doivent être gérés. Les parties prenantes doivent être impliquées et informées, notamment les responsables de ceux des autres projets avec lesquels le projet considéré est en relation.

5.2.2. Conduit et maîtrise de projet (Project Monitoring and Control) Il s’agit de suivre l’évolution du projet selon le schéma construit lors de sa planification. Les décisions prises en cours de route (corrective actions) sont définies et gérées. C’est là un point important : il arrive trop souvent, dans l’entreprise, que des décisions soient ignorées ou indéfiniment remises en cause.

5.2.3. Gestion de projet (Integrated Project Management) Le but de ce processus est d’établir et de gérer un projet

5.2.4. Gestion quantitative d’un projet (Quantitative Project Management) L’objectif est de quantifier la gestion des processus définis dans un projet afin d’évaluer les objectifs de qualité et de performance du projet.

5.2.5. Gestion des achats (Supplier Agreement Management) Les fournisseurs sont choisis à partir d’une évaluation de leurs aptitudes (en s’appuyant sur SCAMPI – Evaluation). Un contrat est passé avec chaque fournisseur, précisant les engagements mutuels entre le client et lui. Enfin, le produit du fournisseur doit être intégré dans l’architecture du système d’information et les équipes de l’entreprise doivent être formées aux techniques particulières le concernant.

5.2.6. Gestion des risques (Risk Management) L’objectif de la gestion des risques est d’évaluer les problèmes potentiels avant qu’ils surviennent, la gestion des risques doit être planifiée et utilisée tout au long de la vie d’un projet.

5.3. Le domaine Engineering Le domaine engineering couvre le développement ou la réalisation d’un produit ou d’un service. Le processus Engineering est compose de six domaines de processus :
- Requirements Management (REQM),
- Requirements Development (RD),
- Technical Solution (TS),
- Product Integration (PI),
- Verification (VER),
- Validation (VAL)

5.3.1. Gestion des exigences (Requirements Management) L’objectif de la gestion des exigences est d’analyser la Par « gestion des exigences », CMMI entend la gestion de la cohérence entre les exigences et les produits de sortie du projet, le fait que les exigences soient bien comprises par les parties prenantes et que celles-ci s’engagent à les satisfaire, enfin la gestion des modifications apportées aux exigences en cours de projet.

5.3.2. Expression des besoins (Requirements Development) L’objectif de ce processus est d’analyser les besoins du client, le projet (ou produit) ainsi que les composants nécessaires à sa production.

5.3.3. Solution technique (Technical solution) L’objectif de ce processus est d’étudier et de réaliser les solutions techniques répondant aux besoins. Les solutions techniques englobent les processus, produits, composants et cycles de vie.

5.3.4. Intégration de produit (Product Integration) L’objectif de ce processus est de préparer et d’assembler les différents composants d’un projet afin d’obtenir un produit fini, de s’assurer que le produit fini est opérationnel et d’en assurer la livraison.

5.3.5. Vérification (Verification) L’objectif du processus de vérification est de s’assurer que le travail réalisé pour la réalisation du projet correspond aux besoins spécifiés (attentes client). Ce processus ne s’intéresse pas au projet ou au produit fini mais aux moyens mis en œuvre pour sa réalisation.

5.3.6. Validation (Validation) Le processus de validation assure que le produit ou le composant remplit toutes les fonctions attendues lorsqu’il est placé dans son environnement de fonctionnement.

5.4. Le domaine Support Le domaine support fournit des processus utilisés par les autres domaines de CMMi. Le domaine Support comprend cinq processus :
- Configuration Management (CM),
- Process and Product Quality Assurance (PPQA),
- Measurement and Analysis (MA),
- Decision Analysis and Resolution (DAR),
- Causal Analysis and Resolution (CAR)

5.4.1. Gestion des configurations (Configuration Management) Ce processus consiste à identifier et décrire les produits que le projet doit fournir : il faut donc en construire le référentiel (définition des identifiants et des attributs), puis alimenter et tenir à jour la description des produits – et le référentiel lui-même, en cas de changement.

5.4.2. Assurance qualité des processus et des produits (Process and Product Quality Assurance) Ce processus évalue et compare les processus, le travail réalisé et les services par rapport aux objectifs prédéfinis.

5.4.3. Production et analyse des indicateurs (Measurement and Analysis) Les indicateurs dont il s’agit sont ceux relatifs à l’avancement du projet et non au fonctionnement du produit une fois qu’il aura été mis entre les mains des utilisateurs (ce fonctionnement n’est pas pris en compte par CMMI).

5.5. Méthode de prise de décision (Decision Analysis and Resolution) Ce processus analyse des décisions possibles en utilisant une évaluation des différentes alternatives par rapport à des critères établis. Les buts sont :
- Etablissement des critères d’évaluation des alternatives,
- Identification des solutions alternatives,
- Sélection de méthodes d’évaluation des alternatives,
- Evaluation des solutions alternatives en utilisant les méthodes et critères précédemment définis,
- Sélection des solutions en fonction des critères d’évaluation

5.6. Analyse causale et solution des problèmes (Causal Analysis and Resolution) L’objectif est d’identifier les causes de défauts et de tout problème rencontré et d’éviter qu’ils se reproduisent. Les buts sont :
- Déterminer la cause initiale d’un défaut,
- Implémentation d’une action,
- Evaluation des effets de l’implémentation de l’action sur les performances des processus

6. Evaluations avec CMMi (SCAMPI)

La méthode d’évaluation proposée par CMMi est SCAMPI (Standard CMMi Appraisal Method for Process Improvement).