1 of 30

Dr. Paul Dorsey

Dulcian, Inc.

22 mai 2008

Utilisation des Audits Intermédiaires dans la Prévention des Echecs

Catastrophiques de Projets

2 of 30

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 of 30

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 of 30

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 of 30

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 obstaclesAjuster la directionLancer l’appel à tous ”ALLONS-Y!"

6 of 30

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 of 30

Coût de la Vérification

Retarde le projetCoûteux

5%-10% du coût du projetImportunEnervantComporte des

coûts politiques

8 of 30

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 of 30

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 of 30

Indépendance du Vérificateur

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é.

11 of 30

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 of 30

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 of 30

Trouver le vérificateur qui convient

Il n’est pas interneIl 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 of 30

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 of 30

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 of 30

Structure détaillée de la vérification

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

17 of 30

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 of 30

Vérification d’Infrastructure

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

19 of 30

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 of 30

Examen Financier

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

Date Budget $ Dépensé Jalons /

Réalisés

Notes

21 of 30

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 of 30

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 of 30

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 of 30

Etude de cas: SGIF Ethiophie

Projet de l’Université de HarvardPetite 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 of 30

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 of 30

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 of 30

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 of 30

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 of 30

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 of 30

Coordonnées

Dr. Paul Dorsey – paul_dorsey@dulcian.com Dulcian website - www.dulcian.com

Developer AdvancedForms & ReportsDeveloper AdvancedForms & Reports Designer

HandbookDesignerHandbook

Latest book:Oracle PL/SQL for Dummies

Design Using UMLObject ModelingDesign Using UMLObject Modeling