Dr. Paul Dorsey

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ût5 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
• dune 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, cest
  mauvais.
• Si vous dépensez 100M et vous échouez, ceci aura
  un impact sur toute lorganisation
• Si vous dépensez 1 milliard et vous échouez,
  cest le pays qui sen ressentira.
• Si vous allez échouer, échouez à bon marché.

5
Lessence de la Gestion de Projet

• Mener des gosses en randonnée
• De temps à autre,
• grimper un arbre
• Vérifier sil y a des obstacles
• Ajuster la direction
• Lancer lappel à 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 sauto-évaluer.
• Un grand effort substantiel
• Une audit faible est pire quinutile
• Crée lillusion 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 lEquipe à la Vérification

• Directeur de Projet
• Pourquoi ne me faites-vous pas confiance?
• Perte de temps
• Développeurs
• On aime mieux coder.
• LEquipe 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 laudit 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, cest une épargne énorme.
• Validation de larchitecture du système
• Deuxième paire dyeux
• Accorde à léquipe le temps de faire le point
• Correction de trajectoire en cours de projet

10
Indépendance du Vérificateur

• Le vérificateur doit être informé quil ny aura
  aucune possibilité de travail subséquent.
• Autrement, laudit devient sujet à suspicions
• Pour appliquer lindépendance
• Aucun élément économique attaché aux résultats
• Aucune motivation à fausser les résultats
• Aucun lien avec léquipe de développement

• Durant laudit
• Limiter les contacts avec léquipe de
  développement
• Syndrome de Stockholm
• Après laudit, les auditeurs peuvent aider à
  élaborer le plan de projet.
• Lauditeur est lagent de la personne qui la
  embauché (de personne dautre)
• Seuls les rapports adressés au propriétaire de
  contrat sont objectifs.
• Il nexiste aucune norme professionnelle ou
  accréditation pour les vérificateurs TI.
• Le Contrat crée lobjectivité.

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 dune 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 dun 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é quelles apportent dautres
  bénéfices, il est clair que les vérifications
  représentent une bonne affaire.

13
Trouver le vérificateur qui convient

• Il nest pas interne
• Il nappartient 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
LEquipe 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 denvergure semblable
• Architecte dApplications
• 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 dInfrastructure
• Evaluer linfrastructure 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
Structure détaillée de la vérification

• B. Vérification dInfrastructure
• 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 dUtilisateur
• Vérification du modèle de données
• Evaluation de la base de données
• Evaluation de lArchitecture de lInterface
  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 damélioration du
  système
• C. Capacité de satisfaire les exigences
  actuelles/futures
• Analyser les exigences actuelles du sysème,
  identifer les cas dutilisation, et évaluer pour
  pertinence, notamment
• Comparer les exigences documentées et les cas
  dutilisation 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 darrêt?
• Evaluer la flexibilité du système lui permettant
  de satisfaire les nouvelles exigences.
• D. Examen financier

• A. Transfert de connaissances
• Permet aux vérificateurs de comprendre la
  totalité de larchitecture du système comme dans
  le cas dune 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 densemble du Système
• Revue générale du Modèle de Données
• Evaluer/Identifer les Cas dUtilisation de
  Transactions
• Evaluer lArchitecture du Code dInterface
  Utilisateur
• Evaluer les Exigences / lArchitecture
  dEtablissement de rapports
• Evaluer lArchitecture du système
• Evaluer le Mécanisme dinstallation/amélioration
  de Système.
• Evaluation des Contrôles Internes
• Evaluation de laccès
• Traitement de bogues/mises en évidence des
  systèmes
• Capacités multilingues
• Exigences système fondamentales
• Déroulement des opérations
• Cadre dapplication personnalisé
• Performance
• Normes

17
Transfert de Connaissances

• Chercher tout dabord à comprendre. Stephen
  Covey
• Apprendre ce quil faut pour prendre en charge le
  processus
• Architecture
• Modèle de données
• Cas dutilisation
• 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.
• Cest une tâche difficile que dempêcher à la
  Vasa de prendre la mer.

18
Vérification dInfrastructure

• 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 linterface 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 dune erreur pour faire couler la Vasa.
• Le système ne varie pas selon léchelle
• Faille de sécurité
• Conception Inflexible

19
Capacité de Satisfaire les Exigences

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

20
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

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 larchitecture COTS
• Prendre le soin danalyser dans quelle mesure
  COTS satisfait les exigences
• Les personnalisations COTS peuvent être très
  coûteuses.
• Les COTS personnalisés ne peuvent pas faire
  lobjet damé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 dargent 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 lUniversité de Harvard
• Petite portion dune 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 lInternet 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 à laise léquipe
  existante.
• Les trois principaux employés en TI ont
  démissionné.

29
Conclusions

• Les vérifications nempê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
  dessuyer léchec de plusieurs petits projets
  plutôt que dun 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.
• Lindé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 lobjet de
  vérifications.

30
Coordonnées

• Dr. Paul Dorsey paul_dorsey_at_dulcian.com
• Dulcian website - www.dulcian.com

Latest book Oracle PL/SQL for Dummies