Utilisation des Audits Interm édiaires dans la Prévention des Echecs Catastrophiques de Projets

1. Utilisation des Audits Intermédiaires dans la Prévention des Echecs Catastrophiques de Projets Dr. Paul Dorsey Dulcian, Inc. 22 mai 2008

2. La Vasa • Début du 17ème siècle (1628) • “Le plus grand navire de tous les temps • Construit en 3 ans • 2 ponts de canon munis de 64 canons • Le roi Gustavus Adolphus de Suède a établi les mesures. • 1000 arbres employés • Parois de chêne triple-laminé(18in/46cm d’épaisseur) • Mât = 190 ft/57m • Longueur = 201 ft/61m • Coût=5% du PIB de Suède

3. Voyage Inaugural • A mis les voiles par une belle journée d’été • 10 août 1628 • Est passé devant le palais royal de Stockholm • A fièrement salué de ses canons • A navigué 1,280 mètres • Un coup de vent est passé • Le navire a fait naufrage en moins d’une minute

4. Quelle est la pertinence de la Vasa? • Ce qui a fait échouer la Vasa fait échouer les projets SIGF. • Nous construisons encore des Vasas. • Nous ne pouvons pas empêcher les mauvaises décisions. • Nous POUVONS cesser de les ignorer. • Si vous dépensez $1M et vous échouez, c’est mauvais. • Si vous dépensez $100M et vous échouez, ceci aura un impact sur toute l’organisation • Si vous dépensez $1 milliard et vous échouez, c’est le pays qui s’en ressentira. • Si vous allez échouer, échouez à bon marché.

5. L’essence de la Gestion de Projet • Mener des gosses en randonnée • De temps à autre, grimper un arbre • Vérifier s’il y a des obstacles • Ajuster la direction • Lancer l’appel à tous • ”ALLONS-Y!"

6. Vérifications Intermédiaires • Un facteur critique de succès pour la prévention d’échec • Doit être externe • Les développeurs ne peuvent pas s’auto-évaluer. • Un grand effort substantiel • Une audit faible est pire qu’inutile • Crée l’illusion de sécurité

7. Coût de la Vérification • Retarde le projet • Coûteux • 5%-10% du coût du projet • Importun • Enervant • Comporte des coûts politiques

8. Réaction de l’Equipe à la Vérification • Directeur de Projet • “Pourquoi ne me faites-vous pas confiance?” • “Perte de temps” • Développeurs • “On aime mieux coder.” • L’Equipe risque de se sentir menacée… • Si l’équipe se sent menacée, elle a peut-être raison de l’être. • Si l’équipe accueille l’audit avec une attitude positive…. • Signe de maturité professionnelle

9. Bénéfices de la Vérification • Détection précoce d’échec • Si un projet de $30 millions échoue après $20 millions, c’est une épargne énorme. • Validation de l’architecture du système • Deuxième paire d’yeux • Accorde à l’équipe le temps de faire le point • Correction de trajectoire en cours de projet

10. Le vérificateur doit être informé qu’il n’y aura aucune possibilité de travail subséquent. Autrement, l’audit devient sujet à suspicions Pour appliquer l’indépendance: Aucun élément économique attaché aux résultats Aucune motivation à fausser les résultats Aucun lien avec l’équipe de développement Durant l’audit : Limiter les contacts avec l’équipe de développement “Syndrome de Stockholm” Après l’audit, les auditeurs peuvent aider àélaborer le plan de projet. L’auditeur est l’agent de la personne qui l’a embauché (de personne d’autre) Seuls les rapports adressés au propriétaire de contrat sont objectifs. Il n’existe aucune norme professionnelle ou accréditation pour les vérificateurs TI. Le Contrat crée l’objectivité. Indépendance du Vérificateur

11. Les vérifications ne sont jamais objectives à 100% • Les vérificateurs amènent leurs propres partis pris. • Il y a des “religions” des TI. • .Net vs. Java • "Thick database" vs. logique de moyen niveau • Architecture Orientée Service (AOS) • Développement se basant sur le Référentiel • Règles administratives • Agile • Un professionnel prônant une perspective différente est quand même capable de détecter une “Vasa.”

12. Justification du coût d’une vérification • Une vérification approfondie absorbe environ 10% du coût du projet. • Pour le secteur, le taux d’échec de projets est ~ 60%. • Exemple: Vérification à mi-chemin d’un projet de $1 million • Coût: (50% x 1,000,000) x 10% = $50,000 • Bénéfice: (50%) x 1,000,00) x 60% = $300,000 • Etant donné les taux d’échec très élevés, les vérifications représentent une assurance à très bon marché. • Etant donné qu’elles apportent d’autres bénéfices, il est clair que les vérifications représentent une bonne affaire.

13. Trouver le vérificateur qui convient • Il n’est pas interne • Il n’appartient pas à la même société que les développeurs • Ce ne sont pas des vérificateurs spécialisés • Il faut que ce soient de vrais développeurs, des ABD, des architectes • Doivent avoir construit des systèmes de portée semblable et dans le même domaine

14. L’Equipe de Vérification • Directeur de Projet • Expérience en le même domaine, avec des projets de portée similaire • Administrateur de Base de Données (ABD) • Expérience en la même plateforme et en une base de données d’envergure semblable • Architecte d’Applications • Connaissances en le même domaine (Java, .Net, Oracle, etc.) • Spécialiste en sécurité • Expérience en matière de système militaire, système financier, ou en soins de santé

15. Structure de la Vérification • Transfert de connaissances • Connaissance profonde • Equivaut à une prise en charge du projet par le vérificateur • A acquis une compréhension du système avant de l’évaluer • Vérification d’Infrastructure • Evaluer l’infrastructure existante pour appuyer le système • Tous les domaines doivent être évalués. • Capacité de satisfaire les exigences actuelles et futures des utilisateurs • Le vérificateur doit comprendre les exigences • Examen financier

16. A. Transfert de connaissances Permet aux vérificateurs de comprendre la totalité de l’architecture du système comme dans le cas d’une prise en charge du développement du système. Les domaines suivants doivent être évalués pour la portion transfert de connaissances de la vérification: Vue d’ensemble du Système Revue générale du Modèle de Données Evaluer/Identifer les Cas d’Utilisation de Transactions Evaluer l’Architecture du Code d’Interface Utilisateur Evaluer les Exigences / l’Architecture d’Etablissement de rapports Evaluer l’Architecture du système Evaluer le Mécanisme d’installation/amélioration de Système. Evaluation des Contrôles Internes Evaluation de l’accès Traitement de bogues/mises en évidence des systèmes Capacités multilingues Exigences système fondamentales Déroulement des opérations Cadre d’application personnalisé Performance Normes Formation B. Vérification d’Infrastructure Evaluer du point de vue de la valeur technique. Comparer aux meilleures pratiques actuellement appliquées dans le secteur; documenter toute divergence. Documentation de Système et d’Utilisateur Vérification du modèle de données Evaluation de la base de données Evaluation de l’Architecture de l’Interface Utilisateur Vérification du Système Réparti/ETL(Extraction, Transformation, Chargement) Vérification du Système de Sécurité Evaluation Matériel/Logiciel/Maillage Procédures de Secours / Récupération Caractère adapté du mécanisme d’amélioration du système C. Capacité de satisfaire les exigences actuelles/futures Analyser les exigences actuelles du sysème, identifer les cas d’utilisation, et évaluer pour pertinence, notamment: Comparer les exigences documentées et les cas d’utilisation existants aussi bien que la manière dont ils sont traités. Evaluer la satisfaction des utilisateurs par rapport au système actuel. Les procédures de secours/récupération suffisent-elles pour satisfaire les exigences maximales de temps d’arrêt? Evaluer la flexibilité du système lui permettant de satisfaire les nouvelles exigences. D. Examen financier Analyser l’utilisation des ressources sur la durée de vie du projet, y compris les dépenses inscrites au budget vs. les dépenses effectives Structure détaillée de la vérification

17. Transfert de Connaissances • “Chercher tout d’abord à comprendre.” Stephen Covey • Apprendre ce qu’il faut pour prendre en charge le processus: • Architecture • Modèle de données • Cas d’utilisation • Vérification des rapports • Gestion de la Configuration • Contrôles internes • Documentation • Formation • Le sytème sera peut-être si mauvais que ceci ne sera pas possible. • Faites-le quand même. • C’est une tâche difficile que d’empêcher à la Vasa de prendre la mer.

18. Comparer leçons tirées du transfert de connaissances et meilleures pratiques Chacun des domaines doit être évalué: Documentation Modèle de données Conception de la base de données Architecture de l’interface utilisateur Sécurité Secours et Récupération Gestion de la Configuration Contrôles Internes Identifier les faiblesses de chacun des domaines: Mesures correctives Exposition Contrôles nécessaires Il suffit d’une erreur pour faire couler la Vasa. Le système ne varie pas selon l’échelle Faille de sécurité Conception Inflexible Vérification d’Infrastructure

19. Capacité de Satisfaire les Exigences • Exige une documentation soignée des cas d’utilisation • Evaluer la satisfaction des utilisateurs • Prendre le temps de discuter avec les utilisateurs • Effectuer des enquêtes • La file des demandes n’est pas une mesure fiable. Si un système marche mal, les utilisateurs laissent tomber. • Evaluer chacun des cas d’utilisation • Exigences fonctionnelles • Performance • Temps d’arrêt • Exigences futures • Flexibilité • Déploiement

20. Vérification de Gérance Si les exigences changent, le prix risque de gonfler. Ceci est-il logique? Les coûts irrecupérables sont “quelque peu” pertinents Mesure le niveau de qualité des décisions Antécédents Financiers Examen Financier

21. Vérification de Projets COTS (Composants sur Etagère) • Ne diffèrent pas trop des projets personnalisés • Les projets COTS échouent avec autant de fréquence. • Evaluer l’architecture COTS • Prendre le soin d’analyser dans quelle mesure COTS satisfait les exigences: • Les personnalisations COTS peuvent être très coûteuses. • Les COTS personnalisés ne peuvent pas faire l’objet d’amélioration de logiciel.

22. Rapport sur la Vérification • Sommaire de gestion de 2-5 pages • Allons-nous bien? • Rapport de DPI de 10-15 pages • Allons-nous bien? Pourquoi? • Rapport détaillé de 100 pages • Ce que nous avons fait • Ce que nous avons trouvé • Ce qui doit être réparé • Etapes suivantes

23. Prendre des mesures sur la base du rapport de vérification • Si le rapport conclut “Vasa….” • Obtenir une contre-expertise • Laisser réagir l’équipe de développement • Les coûts irrécupérables sont les coûts irrécupérables. • La somme d’argent prévue au budget pour le projet est sans importance. • “Amélioration” est une manière de changer de direction sans concéder d’échec.

24. Etude de cas: SGIF Ethiophie • Projet de l’Université de Harvard • Petite portion d’une grande réforme financière • $38 millions USD sur 12 ans • $3 millions USD sur 3 ans consacrés à la TI (très frugal) • Harvard mettait fin au projet et voulait évaluer la qualité du système. • Projet de développement personnalisé • Dulcian a été engagé pour effectuer la vérification.

25. Portée de la Vérification • Vérification de standard • Telle que décrite dans cet exposé • Transfert total de connaissances et sauvegarde à 100% de l’équipe • Soutien pour tous les scénarios “Et si…?” • Sauvegarde à 100% du système

26. Résultat de la Vérificaton • Une très bonne conception • Excellente documentation • Très bon codage des développeurs • Les exigences actuelles sont soutenues • Certains éléments architecturaux demandaient d’être modifiés. • Problèmes de conception de la base de données • Pas de clés étrangères • Conception étrange (héritée de l’équipe précédente) • Mauvais rendement pour certains éléments du système • Problèmes de variabilité d’échelle • Ne marchait pas sur l’Internet en Ethiopie en raison de connexions lentes/peu fiables

27. Recommandations de la Vérification • Maintenir le système actuel • Améliorer le fonctionnement interne du système • Approche des règles administratives • SGBD Oracle • Architecture Web Ultra-légère

28. Résultats de la Vérification • Le gouvernement et Harvard ont accepté les recommandations. • Maintien/évolution du système actuel $1.5 million USD • Nouvelle conception architecturale $1.5 million USD • La double nature de la vérification (vérification + transfert) rendait très mal à l’aise l’équipe existante. • Les trois principaux employés en TI ont démissionné.

29. Conclusions • Les vérifications n’empêchent pas l’échec; simplement, elles les détectent plus tôt dans la durée du processus. • Les vérifications ne remplacent pas une bonne conception. • La vérification peut seulement permettre d’essuyer l’échec de plusieurs petits projets plutôt que d’un seul grand projet. • Les vérifications demandent une forte utilisation de ressources, elles sont coûteuses, énervantes et sensibles du point de vue politique. • Mais à la longue, elles coûtent moins cher que de ne pas les faire. • L’indépendance des vérificateurs doit être protégée. • Aucun travail subséquent • Les projets COTS et les projets personnalisés doivent tous les deux faire l’objet de vérifications.

30. Coordonnées Dr. Paul Dorsey – paul_dorsey@dulcian.com Dulcian website - www.dulcian.com Design Using UML Object Modeling Designer Handbook Developer Advanced Forms & Reports Latest book: Oracle PL/SQL for Dummies