1 of 30 dr. paul dorsey dulcian, inc. 22 mai 2008 utilisation des audits intermédiaires dans la...
TRANSCRIPT
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 – [email protected] 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