Discussion :

[enimnez]

je suis actuellement dans un stage , et j'ai comme sujet la conception d'une CMDB, mais j'ai rencontré beaucoup de problème ,car la CMDB est une base énorme ,donc je veux savoir ou est ce que je peux trouver un modèle déjà construit pour bien m'orienter, et pour me basé sur ce modèle.

Merci d'avance.

[tikomoon]

Bonjour,

Je ne sais pas si cela va t'aider beaucoup, mais il me semble que les méthodes
classique de conception de base de donnée et d'application devraient pouvoir t'aider.

Dans un premier temps, au lieu de t'interesser à la base de donnée, recherche le besoin de l'utilisateur et au rôle de cette base de donnée.

Tu as sans doute une expression de besoin quelque part.
La CMDB est un composant d'ITIL, regarde comment est décliné ITIL dans ton entreprise (qui sont les acteurs, quel sont les objets à suivre...)

Il possible que cette expression de besoin soit insuffisante. Dans ce cas, repart sur des cessions de collecte des besoins.

Il est aussi possible que les utilisateurs n'aient pas une idée assez claire de leur besoin. Dans ce cas les cessions de collecte des besoins sera utile mais un peu plus complexe à mener.

Dans tous les cas, tu devras faire des choix...entre ce qui est important et que l'on peut faire facilement et ce qui est plus complexe et qui sera fait dans un second temps (lotissement du projet).

Projet vraiment interessant pour comprendre ITIL...


EF

[chouchou85]

Bonjour enimnez,

Moi aussi je suis en stage de fin d'études et j'ai comme sujet la mise en place d'une CMDB. En peut dire que je suis perdue dans mon sujet ; je sais pas quoi faire; la doc que je trouve sur internet est trop vague; Par exemple, on dit qu'une CMDB doit fournir les données actuelles et l'historique de chaque élément de configuration mais je sais pas comment faire, comment avoir un historique? On dit aussi que la CMDB doit contenir les attributs des CI et les relations entre eux, mais comment? Je sais pas que dois je mettre dans le Diagramme des cas d'utilisations!
Quand j'ai parlé à mon encadrant il m'a dit qu'il faut appliquer ITIL à la lettre!!!
mais je trouve ça trop vague!
Je sais pas si tu as pu dépassé le pb mais si tu es arrivé à te lancer dans le sujet n'hésite pas à me dire comment tu as procédé.

Merci d'avance!

[tikomoon]

Salut,

Par quel process souhaites tu commencer ta modélisation?
On peut essayer de travailler à deux, le sujet m'interesse également

J'ai trouvé deux liens interessant sur le sujet :

http://wiki.en.it-processmaps.com/in...ITIL_Processes
et
http://www.infra-corp.com/fr/solutions/ITIL/

j'ai aussi un certain nombre d'observation de terrain à mettre sur le tapis

En épluchant correctement les sources, on devrais bien sortir quelque chose.
Personnellement, je n'ai pas de contrainte.
Donc à toi de donner ta feuille de route si tu veux bien.

A+

[chouchou85]

Merci beaucoup tikomoon.

Je commencerai par le processus de la gestion des configuration. Je crois qu'au début je procèderai comme s'il s'agissait d'une gestion de parc informatique, ensuite j'ajouterai des fonctionnalités qui permettront d'appliquer ITIL, qu'en penses-tu?

[tikomoon]

Ok,

Le démarrage me semble pas mal!!
Effectivement, commencer par créer un référentiel des configurations me semble une bonne idée. d'autant plus que la configuration est l'élément central d'une CMDB. Par contre, je ne suis pas sur à 100% qu'une gestion de parc ne couvre entièrment le concept de config d'ITIL.

Justement j'ai trouvé des infos sur la gestion des configurations (Configuration Items CI).

Les objectifs de cette gestion :

1. Représenter fidèlement les CI et les relations entre les CI
2. Apporter des informations sur chaque config. (version, doc)
3. Apporter une base solide aux processus de gestion (incidents, problèmes, changements, mise en production)
4. Réaliser des comparaisons et des analyses d'impact lors d'évènements de gestion
5. Conserver un historique des configurations
6. Gérer les statuts des configurations

Le point 1, la difficulté vient du choix des CI de plus bas niveau. Pour une organisation, un PC+clavier+souris pourra constituer un CI unique. Pour une autre, Il faudra descendre plus bas et le PC sera un CI en relation avec une carte mère, un DD ...etc...(structure en arborecence des CI)

Pour les relations entre CI la difficulté reste la même, j'ai quand même identifié quelques relations interessantes :

• Un CI fait partie d'un autre CI (un .jar fait partie d'une application)
• Un CI est connecté à un autre (PC au réseau)
• Un CI utilise un autre CI (une appli utilise un web service)

Si j'ai bien compris, les relations à considérer sont celles qui permettent une analyse d'impact lors des changements, incidents, problèmes, mise en production.


Le point 2 nous renseigne sur les attributs qui peuvent être intéressant et nous renseigne sur un cas d'emploi (la consultation)
Le point 3 esquisse des relations avec les processus
Le point 4 nous parle encore des relations entre CI et de cas d'emploi précis de la CMDB (analyse d'impact et comparaison pour audit et mise à niveau)

J'ai d'autres éléments sur les problématiques d'historisation/actualisation et sur les cas d'emploi.

Mais il serait peut-être interessant d'approfondir la notion de CI et leurs relations afin de construire un modèle (merise ou uml). Qu'en pense-tu? Utilise-tu un outil de modélisation particulier? sinon, on peut faire pas mal de chose avec openOffice Impress ou son équivalent vindoz.

[chouchou85]

Bonjour,

pour la modélisation j'avais envisagé, avant de débuter mon stage, de travailler avec UML vu que j'ai jamais travaillé avec dans une application et que je vouldrais bien approfondir mes connaissances UML.

J'ai commencé alors par élaborer un diagramme Use Case;J'envisage par la suite de faire la description contextuelle des différents Use cases.

je fourni ici le shéma. Je sais pas si c'est correct!

[tikomoon]

Je suis plutôt d'accord sur l'ensemble de ton diagramme.
Il m'a semblé important d'ajouter :

• la gestion des structures - pour gérer les relations entre les CI
• la gestion des statuts - pour gérer l'évolution dans le temps des configurations

Je n'ai présenté que les activités opérationnelles sur ce diagramme.
A mon avis, il pourrait être intéressant de présenter certaines activités liées au référentiel.

Je pense à la création de statuts associés à certains type de CI ou structure de CI.
Par exemple : Un logiciel a un cycle de vie <> d'un serveur.

La création d'un référentiel de structures spécifiques au métier de l'utilisateur pourrait être intéressant.
L'utilisateur aurait ainsi la possibilité de créer, modifier, supprimer ses propres structures.

Est-ce qu'on avance dans la bonne direction?

[chouchou85]

Oui on avance dans la bonne direction.

Seulement, j'ai pas bien compris les notions d'activité opérationnelle et référentielle; est ce que "s'authentifier" dans mon cas est une activité référentielle? donc c'est pas la peine de le représenter?

et que veux tu dire par structure, est ce que c'est la même chose que relation(est situé à..., héberge...)?

Concernant la description textuelle, penses tu que je dois la faire pour tous les cas?

merci!

[tikomoon]

Seulement, j'ai pas bien compris les notions d'activité opérationnelle et référentielle; est ce que "s'authentifier" dans mon cas est une activité référentielle? donc c'est pas la peine de le représenter?

Oui, c'est vrai je fais une distinction entre les activités liées au référentiel et les activités opérationnelles.

Quand j'évoque le référentiel, je pense à une possibilité de paramètrage de structures type ou nomenclatures type.
Une sorte de moule pour facilité le travail opérationel, et également structurant pour l'entreprise.

Par exemple :

• Pour l'entreprise X, le PC est toujours composé d'une UC+Ecran+Souris
• Pour l'entreprise Y, le PC est toujours composé d'une carte mère+carte son+DD

Les activités liées au référentiel permettraient de créer des structures et de les adpater (création, modification, suppression).

parenthèse : le PC est un CI, les éléments qui composent la structure aussi

Et dans les activités opérationnelles je mettrais plutôt les actions menées pour instancier de nouveaux objets.
Par exemple lorsque l'entreprise acquiert de nouveaux PC, le gestionnaire des CI récupère les codes barre et créer
de nouvelles instances dans la CMDB. (opérations d'inventaire)


Le gestionnaire peut également associer les PC à une structure (le lieu de stockage par exemple).
Il peut également utiliser une structure référentielle pour être conforme au modèle de son entreprise.

est ce que "s'authentifier" dans mon cas est une activité référentielle? donc c'est pas la peine de le représenter?

Mea culpa, je n'ai pas repris "s'authentifier". Ce n'est pas à mon avis une activité référentielle.
Sur ton schéma elle est correctement positionnée.

et que veux tu dire par structure, est ce que c'est la même chose que relation(est situé à..., héberge...)?

Oui c'est bien cela - mais si les termes ne te conviennent pas n'hésite pas à les changer.
Je ne connais pas forcément les termes précis à utiliser donc c'est open.

Concernant la description textuelle, penses tu que je dois la faire pour tous les cas?

Par contre, je me demande si l'activité "gérer les statuts" n'est pas plutôt liée au changement. à creuser!!!

en bonus ce soir
Checklist Configuration Item

[tikomoon]

Pour la suite, tu utilises plutôt la V2 ou la V3.
Personnellement je préfèrerais la V3.

[chouchou85]

Bonjour,

Moi aussu je préfére la version 3 de Itil.

Pour l'activité "gérer les statuts", je pense qu'il faudrait mettre une relation d'inclusion entre elle et la relation "approuver changement" vu que la modification du statut d'un CI est un changement ou est dûe à un changement. n'est ce pas?

[tikomoon]

Une nouvelle version des uses cases

Contient trois blocs :

un bloc opérationnel
un bloc auditeur
un bloc gestionnaire du référentiel

Pour l'activité "gérer les statuts", je pense qu'il faudrait mettre une relation d'inclusion entre elle et la relation "approuver changement" vu que la modification du statut d'un CI est un changement ou est dûe à un changement. n'est ce pas?

J'ai changé le nom gérer les statuts en gérer le cycle de vie.

Oui, si l'on commence à s'interesser aux interactions avec les autres disciplines, on peut effectivement faire un lien avec la gestion des changements.

Il serait peut-être interessant de faire un diagramme d'interaction gestion des configurations avec chacune des autres disciplines.
Cela permettrait peut-être mieux visualiser les flux qu'avec un diagramme des uses cases.

[chouchou85]

Bonjour tikomoon,

Je viens de terminer ma première version de mon diagramme de classes dont je fournis ici le shéma.

Qu'en dis-tu?

Quant au diagramme de séquence, je me suis dit qu'il vaudrait mieux l'élaborer après le diagramme de classes. De plus, je pense qu'il est temps de passer à la réalisation vu le temps qui m'est imparti pour le stage.

N.B: Je dois remmettre le rapport début juin !

[enimnez]

bonjour
pardon pour le retard, mais comme je ss un nouveau membre, ça fait longtemps que j'ai pas visiter le Forum.

concernant la CMDB, j'ai divisé mon travail en 2 volets principaux:
-gestion des configuration.
-gestion des incidents.


la gestion des configuration, englobe gestion des CI et relation entre CI, gestion des mises en production,gestion des changements, car j'ai vu que chacune de ses gestions ne mérite pas etre tout un volets complet, contrairement à la gestoin des incidents.

[chouchou85]

Bonjour enimnez,

Si j'ai bien compris, ton application est conçue de telle sorte qu'elle soit utilisée par 2 types d'utilisateur: le premier est l'administrateur de l'application et c'est lui qui a le droit de gérer les CIs (ajouter, modifier,...) et créer les comptes utilisateurs et faire le reporting, et le deuxième déclare les problèmes et consulte ses données perso. c'est ça?

Et dans quel stade du projet tu es maintenant? tu as commencé le développement?
Si c'est le cas j'aimerais bien avoir ton avis sur mon diagramme de classes.

[enimnez]

Bonjour chouchou 85,

une petite rectification, c'est que dans ma conception:
Administrateur-->GESTION DES COMPTES;
Gestionnaires des configurations-->Gerer la mise en production,les changements...
Gestionnaires des incidents-->Gerer les incidents, et les inteventions.
Technicien-->Intervenant.

pour ton digramme de classe il est en mesure avec le mien à la différence que t'a pa mis la parti de gestion des incident, mais ton diagramme m'a bien prouvé que ce que j'ai compris sur la CMDB est bien juste, puisqu'on est dans la même longueur d'onde.

pour le développement, je suis dans les toutes premières étapes de développement, et travaille avec STRUTS.

[tikomoon]

Bonjour,


Une petite question qui me tarabiscotte, comment pensez-vous gérer l'historisation des configurations?

Avec ton modèle chouchou, si l'on change une configuration, on perd la configuration précédente n'est-ce pas ?

Est-ce qu'il ne faudrait pas mettre en place un numéro de version propre à la CMDB. Cela permettrait de gérer l'historique et les base lines.

Qu'en pensez-vous?

Je vais essayer de prendre un peu de temps pour vous proposer un diagramme de classe. Pas facile avec les ponts du mois de mai.

A+

[chouchou85]

Bonjour tikomoon,

Est-ce qu'il ne faudrait pas mettre en place un numéro de version propre à la CMDB. Cela permettrait de gérer l'historique et les base lines.

Qu'en pensez-vous?

Désolée, mais j'ai pas bien compris l'idée, peux tu me l'expliquer davantage?

Merci!

[chouchou85]

Bonjour,

J'ai eu une idée concernant l'historisation, il s'agit d'ajouter une classe changement qui va permettre d'enregistrer les changements, en indiquant leurs dates.

Je fourni ici le diagramme de classe modifié. Qu'en dis-tu?