urbanisation-si

urbanisation-si

Gestion de projet informatique


Quelques raisons de l'échec des projets informatiques

urbanisation-si-expression-des-besoins.jpg

 

Le retard, le demi-succès/échec voir le flop total d'un projet peut être du au fait que les utilisateurs ne savent pas ce qu'ils veulent ou ne savent pas communiquer leurs besoins. C'est l'éternel problème de la communication entre la MOA et la MOE. Je veux un lave linge et on me livre un lave vaisselle.

Les exigences peuvent changer tout au long du projet. De nouvelles réglementations, lois, politiques peuvent surgir et obliger à modifier des systèmes ou à se plier à de nouvelles normes ou processus.

La concurrence de plus en plus agressive et féroce impose de s'adapter rapidement en cours de réalisation de projet ou sinon on s'expose à développer une application déjà obsolète. Il faut savoir anticiper sur la technologie et faire les  bons choix.

Très souvent, la direction générale ne s'implique pas dans le projet qui va alors s'enliser sans que rien de concret ne se réalise. Combien de projets ont accouché de milliards de tonnes de "spec" sans qu'il n'y ait une véritable application exécutable. On ne le dira jamais assez "seul compte l'exécutable".

Le manque de connaissance (attention je n'ai pas dit incompétence) sur la conduite de projet informatique est aussi un facteur de risque important. De trop nombreuse fois j'ai vu des directions avoir "les yeux plus gros que le ventre" et démarrer un projet bien trop volumineux en terme de périmètre et être obligée par la suite de retirer des blocs fonctionnels ou de les différer.

Au départ les directions disent on ne veut pas de vitrine technologique, les méthodes, la modélisation, les outils c'est trop cher, ça ne produit rien et ça ne sert à rien. Résultat rien n'est documenté, modélisé, simulé, tracé, bref le projet devient une sombre forêt marécageuse ou tout s'enlise et rien n'en sort.

Un des secrets des projets réussis (si si ça existe !), c'est de ne pas hésiter à s'entourer d'experts reconnus en gestion de projets informatiques, en architecture technique, en management, ... qui mettront en oeuvre les bonnes pratiques reconnues sur le marché et qui éviterons ainsi toutes les erreurs à ne pas faire. Ce seront des leaders qui donneront confiance et motiveront les équipes. Les projets seront découpés en lots à taille humaine, ils seront développés dans un cadre d'urbanisation du SI. Les collaborateurs penseront projet avant de penser à leur propre carrière. Les relations et la communication  avec  la MOE seront maîtrisées. Les bonnes pratiques et les meilleures technologies seront mis en oeuvre dés le départ pour avoir un avantage concurrentiel.

 

"L'effort d'unir sagesse et pouvoir aboutit rarement et seulement très brièvement.

Albert Einstein"

 

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


01/05/2015
0 Poster un commentaire

L’élaboration du Cahier de Recette

urbanisation-si-cahier-de-recette.png

 
Le Cahier de REcette (CRE) a pour but principal de fournir un plan d’action détaillé à la MOA ou MOE qui sera en charge de la réalisation des tests.
Celui-ci est composé essentiellement des dossiers de tests et des fiches de tests
Les dossiers de tests permettent de déterminer les données métiers spécifiques sur lesquelles seront basés les scénarios de tests.
  • La structure d’un dossier de tests est très proche de la structure des données définie dans le modèle conceptuel des données (compréhensible par la MOE ainsi que par la MOA) réalisé pendant les travaux de spécification fonctionnelle.
•Une fiche de test définit un processus de tests pour chaque scénario métier. On doit y définir :
  • Précisément le mode opératoire du scénario de tests sous la forme d’une séquence d’actions à effectuer
  • Le résultat attendu à l’issue de l’action pour chaque action du mode opératoire
  • La référence au dossier de tests définissant les données métier exploitées en entrée et manipulées au cours du processus
  • A chaque étape de vérification d’une fiche de tests (action / résultat attendu) correspond un cas de test identifié dans la matrice de tests. Cette matrice permet de faciliter :
    • La lisibilité de la fiche de test par la MOE car rapprochée des spécifications détaillées
    • La qualification des problèmes rencontrés au cours de la recette
    • La gestion de la recette
Les fiches de tests doivent être rédigées en s’appuyant sur les cas d’utilisation du logiciel identifiés lors de l’établissement des spécifications
Chaque processus métier devra avoir au minimum une fiche de tests afin que la recette fonctionnel puisse couvrir l’ensemble du logiciel
Le cahier de recette doit aussi indiquer
  • les configurations matérielles et logicielles de la plate-forme
  • les valeurs du paramétrage logiciel de façon exhaustive
Exemple de cahier de recette
Introduction
  • Contexte et objectif du document
  • Objet de la recette
  • Documents de référence
Description des moyens
  • Responsabilités
  • Plate-forme de recette
  • Outils de recette
Présentation du plan fonctionnel de tests
  • Présentation générale
  • Description de l’arbre de test
Fiches de test
  • Actions générales
  • Liste des fiches
Une fois le cahier de recette terminé, la matrice de tests doit être constituée avec en entrées :
  • L’ensemble des points fonctionnels (ou règles de gestion) devant faire l’objet d’une validation
  • Les différents cas d’utilisation
La matrice de tests est un document de référence qui permet de piloter la recette et de s’assurer qu’aucun point ne sera oublié
  • Elle définit le niveau de qualité fonctionnelle souhaité ainsi que le périmètre de la recette
  • Elle doit être validée par la MOA
urbanisation-si-deroulement-recette.png
 
La recette interne MOE garantit une qualité optimum du logiciel qui sera livré à la MOA
Elle débute dès que les développements sont assez avancés.
Chaque fonction doit faire l’objet d’un test unitaire
  • Les tests de déminage peuvent être établis en collaboration avec la MOA (compétence métier).
  • Ces tests permettent de confronter le logiciel très tôt aux futurs utilisateurs.
  • Les ressources de la MOA devront être avertis qu’il ne s’agit que d’une aide au développement et non d’une recette d’intégration finale
  • Lors de la recette interne, les résultats des tests effectués et les demandes de modification de la MOE sont inscrits dans le cahier de recette en temps réel. Le cahier de recette reflète ainsi l’avancement de la recette en continu
Un procès-verbal est rédigé par la MOE et présenté à la MOA en comité de pilotage en fin de recette interne.
  • Il rappelle les éléments indiqués par le cahier des charges
  • La MOA pourra accepter ou non les potentielles demandes de dérogation
  • Si la MOA accepte, la MOE pourra livrer le logiciel incomplet ou conforme partiellement aux spécifications
La recette fonctionnelle MOA
  • La pré-recette permet à la MOA si la qualité du logiciel est suffisante pour pouvoir être testé. Il faut donc que :
    • Tous les livrables convenus sont bien fournis (éléments logiciel et bordereaux de livraison, PV de recette interne, liste des restrictions éventuelles)
    • La plate-forme de recette est opérationnelle
    • Aucun problème bloquant empêchera le jeu des scénarios
  • Elle débouche sur un procès-verbal et annonce le début de la recette fonctionnelle
  • La recette provisoire (recette principale) consiste en un contrôle sur la base de l’ensemble des fiches de tests établie par la MOA et validée par la MOE
  • Chaque anomalie détectée fera l’objet d’une fiche de fait technique
L’issue de cette phase donne lieu à un procès verbal avec trois qualifications possibles :
  • Validation : aucune anomalie n’a été détectée, la recette sur site pilote peut alors débuter
  • Validation sous réserves : aucune anomalie bloquante n’a été détectée, un PV de validation sous réserve avec la liste des anomalies peut être signé. La MOE s’engage alors à corriger les anomalies avant la livraison sur le site pilote pour recette définitive
  • Refus : des anomalies bloquantes ont été détectées ou toutes les exigences. Le PV de recette fera part de ce refus et des raisons. Une fois la phase de correction terminée, la recette provisoire devra être recommencée
Les acteurs de la recette
  • Le groupe de recette est constitué des membres de la MOA ayant si possible participé à la rédaction du cahier des charges et/ou cahier de recette. Lors de la pré-recette, les membres les plus expérimentés évalueront rapidement la qualité générale du logiciel
  • Le support technique est composé de membre(s) de la MOE à plein temps. Ils permettent d’assurer la maintenance de la plate-forme et le bon fonctionnement du logiciel (correction des anomalies bloquantes immédiate)
  • Le support fonctionnel est représenté par une personne connaissant parfaitement le métier, le cahier de recette et les dossiers de spécifications fonctionnelles. Elle sera responsable de la conduite du changement tout au long de la recette
  • Le support méthodologique et organisationnel est assumé par le chef de projet MOA. Il permet d’expliquer comment une fiche de tests doit être interprétée ou bien la façon dont un fait technique doit être rédigé
Les ressources matérielles doivent être les mêmes que ce soit pour la validation interne ou la recette fonctionnelle. Elles doivent être aussi proche que possible de l’environnement d’exploitation.
La recette sur site pilote permet d’appréhender le logiciel dans un environnement le plus proche possible de la plate-forme d’exploitation.
Cette phase débouche sur l’acceptation définitive du logiciel par la MOA
La MOA est chargée de vérifier le bon fonctionnement de l’infrastructure informatique du site pilote
Elle remet à la MOE un bordereau de mise en marche de celui-ci
La première installation du sous-ensemble logiciel pourra alors se faire
La configuration du site est à la charge de la MOA en collaboration étroite avec la MOE (configuration mentionnée dans le cahier de recette)
La recette définitive peut alors débuter et doit être suivie d’un contrôle de conformité fonctionnelle et technique (Vérification du Service Régulier)
Ce contrôle doit être fait sous-ensemble par sous-ensemble du logiciel. Un procès-verbal peut alors avoir lieu :
  • Validation, mise en exploitation
  • Validation sous réserves, pas d’anomalie bloquante
  • Refus, la correction des anomalies donne lieu à la recette provisoire
Les acteurs :
  • La MOE intervient pour l’installation des sous-ensembles logiciels
  • La MOA administre la plate-forme
  • La même équipe MOA que pour la recette provisoire
La garantie du système
  • Elle fait suite à la recette définitive
  • La mise en exploitation du logiciel devrait révéler de nouvelles anomalies
  • Les anomalies remontées font l’objet d’une correction et d’une re-livraison du sous-ensemble logiciel
  • Toute modification du logiciel suite à une demande MOA pendant une phase quelconque de la recette donne lieu à un avenant entre les parties
  • Il en est de même pour toutes les demandes d’évolution intervenant après l’acceptation du dossier des spécifications logiciel
 
 
"Il faut tendre la main à ses amis sans fermer les doigts."
Diogène
 

07/11/2014
0 Poster un commentaire

Estimation – Méthode des points de cas d’utilisation

urbanisation-si-estimation-UC-2i.jpg
 
Les diagrammes de Cas d’Utilisation sont sans conteste les plus faciles à utiliser.
Les CU ainsi que les autres diagrammes UML semblent représenter une base d’évaluation plus précise et plus fiable que les Points de fonction.
En terme de précision, la méthode des points de CU est comparable avec celle de l’expertise basée sur l’expérience concrète des développeurs.
Paramètre de complexité des Acteurs :
  • Caractériser les acteurs par « poids de complexité » appliqué à leur action (1 = simple, 2 = moyen, 3 = complexe)
Le poids non ajusté ( des facteurs techniques et environnementaux ) des Acteurs ( UAW Unadjusted Actor Weight ) s’obtient en comptant le nombre d’acteurs dans chaque catégorie et en le multipliant par le paramètre de complexité. Additionner les 3 chiffres des 3 catégories.
Paramètre de complexité des CU : caractériser les CU par un paramètre de complexité :
 
urbanisation-si-estimation-points-de-use-case-1.png
 
Le poids non ajusté ( des facteurs techniques et environnementaux ) des CU ( UUCW Unadjusted Use Case Weight ) se calcule en comptant le nombre de CU dans chaque catégorie. Multiplier chaque catégorie de Cas d’Utilisation par son poids, puis additionner les produits obtenus.
Valeur non ajustée des Points de CU :
  • UUCP = UAW + UUCW 
Le compte des Points de CU est ensuite ajusté en fonction de facteurs techniques ( TCF Technical Complexity Factor ) et environnementaux ( EF Environmental ). A chacun de ces paramètres est assigné une valeur variant de 0 à 5 en fonction de son influence (I) dans le projet.
 
urbanisation-si-estimation-points-de-use-case-2.png
 
urbanisation-si-estimation-points-de-use-case-3.png
 
TCF ( Technical Complexity factor ) :
  • TCF = 0,6 + ( 0,01 * (somme(I * PTx))) 
 
 
urbanisation-si-estimation-points-de-use-case-4.png
 
EF ( Environmental Factor ) :
  • EF = 1,4 + ( -0,03 * (somme(I * EPx)))
Valeur ajustée des Points de CU (UCP Use Case Point) :
  • UCP = UUCP * TCF * EF
Si tous les facteurs = 0 =>
  • UCP = UUCP * 0,6 * 1,4 = UUCP * 0,84
Si tous les facteurs = 5 =>
  • UCP = UUCP * (0,6 + (0,01 * 5 * 14)) * (1,4 + (-0,03 * 5 * 3,5))
    UCP = UUCP * 1,3 * 0,875 = UUCP * 1,137
Remarque l’ajustement varie de -16% à ~1%
UCP est multiplié par un nombre correspondant à la productivité classique ou historique des équipes impliqués dans le projet (par exemple : 10 heures par UCP).
Le résultat du calcul est un nombre d’heures de travail requis pour réaliser le projet
Pré - requis :
  • Exhaustivité des diagrammes en termes de couverture fonctionnelle et en termes de précision dans la description des acteurs et des rôles.
  • Niveau de détail qui doit offrir une vision complète tout en évitant le  piège de « l’expansion infinie ».
  • Pas de standard actuellement pour définir formellement le niveau de détail approprié.
La manière de décrire les CU a donc une influence notable sur l’estimation :
  • Généraliser un acteur va amener à le compter 1 seule fois.
  • Relations d’inclusion, extension et généralisation entre les CU. Dans certaines estimations ces types sont comptés dans d’autres, ils sont omis. A évaluer au cas par cas.
Il est facile pour chaque organisation de définir son propre standard de granularité en analysant ses CU et en les classifiant « simple », « moyen » ou « complexe ».
L’intérêt est significatif car les CU permettent de définir le périmètre d’un projet avec beaucoup plus de précision que les Points de fonctions.
De plus les CU expriment utilement les exigences pour le développement.
Avec UML, au-delà des CU, il est possible de considérer d’autres éléments de métrique :
  • Modèle objet du domaine
  • Modèle objet d’analyse
  • Modèle objet de conception
  • Modèle objet d’implémentation
  • Modèle objet de test
Évolution et affinement possibles :
Contenu des diagrammes UML
Diagramme de classe, le nombre de :
  • Classes
  • Attributs
  • Opérations
  • Associations
Diagramme d’état, le nombre de :
  • États
  • Transitions
 
"Il vaut mieux exceller en une chose que d'être médiocre en plusieurs."
Pline le Jeune
 

05/11/2014
0 Poster un commentaire

Les (bonnes ?) relations MOA/MOE.

urbanisation-si-MOA-MOE.jpg
La démarche d'urbanisation du SI oblige à impliquer ses MOA (maîtrise d'ouvrage) et pour cela il faut se donner les moyens d'une véritable professionalisation du SI de sa MOA afin de minimiser les risques projets.

La MOA stratégique (commanditaire) donne les objectifs du futur système, les ressources financières et intervient au niveau du pilotage, des processus métiers et de la vue fonctionnelle.

Le maître d'ouvrage projet (MOA déléguée) est nommée par la MOA stratégique  pour agir par délégation afin de mener à bien le projet. Elle doit définir les objectifs stratégiques, organisationnels, fonctionnels, technologiques.

L'assistance à MOA  (AMOA) formalise les objectifs en exigences. Elle préparent les validations des solutions qui seront pilotées par la MOA et le planning de la MOE (maîtrise d'oeuvre).

La MOA doit :

  • vérifier la conformité des solutions avec les exigences
  • préparer et piloter la conduite du changement
  • adapter l'organisation aux nouveaux systèmes
  • définir les nouvelles procédures
  • sensibiliser les personnes concernées par les changements
  • communiquer vis à vis des acteurs concernés par le nouveau système
  • former les utilisateurs

Le pilotage du projet est assué par la MOA déléguée qui rapporte au comité projet, de pilotage ou directeur pour les décisions majeures.

La MOA opérationnelle est constituée d'utilisateurs, d'experts métiers qui assurent les missions :

  • d'expression de besoins
  • de conduite du changement

La MOA opérationnelle intervient sur les vues processus métier et fonctionnelles (modéles des données métiers).

L'AMOA (entité appartenant à la même entreprise ou à des sociétés externes spécialisées dans les domaines requis) est constituée de spécialistes pour :

  • formaliser le besoin des utilisateurs sous forme de cahier des charges fonctionnel
  • définir les exigences de management de projet et d'assurance qualité
  • préparer et conduire les appels d'offres et aider au dépouillement des offres
  • définir et conduire les opérations de validation vis-à-vis de la MOE

Ces missions utilisent les cartographies du plan d'urbanisme.

La MOE réalise le projet pour le compte de la MOA. Elle met en oeuvre le planning et les moyens humains et logistiques nécessaires (prestataires, ...). Les livrables (documents ou produits) de la MOE sont définis dans le contrat et leurs dates dans un planning.

La (bonne ?) relation MOA - MOE pemet de formaliser les besoins de la MOE pour réaliser le système et la vérification par la MOA que les réalisations sont conformes  aux attentes.

Cette formalisation s'appuie sur des modèles :

  • modèle des processus métiers (évènements métiers, enchaînement d'activités, acteurs...)
  • modèle des règles métiers (règles de gestion)
  • modéle des services métiers
  • modèle des objets métiers utilisés dans les processus et leur cycle de vie ainsi que les règles de gestion associées
  • modèle organisationnel 
  • modéle de document

Le plan d'urbanisme contient donc tous ces modèles qui serviront de support à la rédaction du cahier des charges fonctionnels et aux cahier des charges techniques.

 

"Ce qui est passé a fui ; ce que tu espères est absent ; mais le présent est à toi."

Proverbe arabe

 

Voir aussi :  

http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/


03/11/2014
0 Poster un commentaire

1001 manières de faire échouer un projet.

urbanisation-si-echec-des-projets.jpg
C'est un secret de polichinelle, moins de 20% des projets sont des réussites (respect des coûts, délais et exigences MOA remplies), près de 30% sont purement et simplement abandonnés et plus de 50% ont explosé les budgets (2 fois plus cher en moyenne), les délais (2 fois plus long que prévu) et n'ont répondu qu'à 60% de la couverture du besoin fonctionnel spécifié !

Le risque d'échec augmentant exponentiellement avec la taille du projet (en moyenne au delà de 2 M€ / an).

Quelles en sont les raisons ?

Le projet est trop gros, il n'y a pas eu de lotissement, de priorisation des grands domaines du projet, la direction générale a eu les yeux plus gros que le ventre, elle a voulut tout faire en même temps. Le projet s'est éternisé, les équipes ont perdu toute motivation qui est pourtant la clé de la réussite. Les langues se sont déliées, les critiques ont commencé à fuser minant le moral des troupes. Le projet a perdu sa taille humaine, l'imagination créatrice des participants a été bayonnée.

Les changements en provenance de la MOA arrivent trop souvent sans que soit mis en oeuvre un véritable processus de la gestion du changement.

Chacun , MOA, MOE, consultants, sous-traitants apportent leurs contributions sans réelle communication.

Au lieu d'encourager les synergies, le chef de projet s'est confiné dans un rôle de simple intermédiaire, sans contrôles véritables entre les différents intervenants aux intérêts divergents.

La clé du succès est le degré d'implication des acteurs ainsi qu'une définition claire et compréhensible d'objectifs réalistes. Malheureusement dans la majorité des cas les utilisateurs ne savent pas ou n'arrivent pas à exprimer leurs besoins. L'insuffisance du recueil des besoins explique dans 50% des cas l'abandon des projets.

Dans 5% à 15% des cas, l'échec est du aux technologies non maîtrisées ou qui ne correspondent pas aux métiers.

Comme nul ne sait faire du 1er coup, ni tout faire en même temps, ce n'est pas un surcoût que de faire un schéma directeur, d'utiliser des référentiels (CMMi, ITIL, COBIT) et un plan d'urbanisme, qui sont au contraire des méthodes de diminution de risque.

L'échec n'est pas du à des mauvaises solutions à de vrais problèmes mais à de bonnes solutions à de faux problémes.

Donc, si vous voulez aller plus vite et bien prenez votre temps !

 

"La jeunesse est le temps d'étudier la sagesse. La vieillesse est le temps de la pratiquer."

Jean-Jacques Rousseau

 

Voir aussi :  

http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/


02/11/2014
0 Poster un commentaire