La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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.

Présentations similaires


Présentation au sujet: "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."— Transcription de la présentation:

1 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 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 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 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 dune minute

4 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 5 of 30 Lessence 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 lappel à tous ALLONS-Y!"

6 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 sauto- é valuer. Un grand effort substantiel Une audit faible est pire quinutile Cr é e l illusion de s é curit é

7 7 of 30 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 8 of 30 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 l audit avec une attitude positive…. Signe de maturit é professionnelle

9 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 larchitecture 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 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, 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 l audit, les auditeurs peuvent aider à é laborer le plan de projet. Lauditeur est lagent de la personne qui la embauch é (de personne d autre) 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 l objectivit é.

11 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 12 of 30 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 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 dautres b é n é fices, il est clair que les v é rifications repr é sentent une bonne affaire.

13 13 of 30 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 14 of 30 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 d envergure 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 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 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 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 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 d installation/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 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 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 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 lutilisation des ressources sur la dur é e de vie du projet, y compris les d é penses inscrites au budget vs. les d é penses effectives

17 17 of 30 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 d empêcher à la Vasa de prendre la mer.

18 18 of 30 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 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 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 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 DateBudget$ D é pens é Jalons / R é alis é s Notes

21 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 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 l objet d am é lioration de logiciel.

22 22 of 30 Rapport sur la Vérification Sommaire de gestion de 2-5 pages Allons-nous bien? Rapport de DPI de 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 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 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 24 of 30 Etude de cas: SGIF Ethiophie Projet de lUniversit é 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 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 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 lInternet en Ethiopie en raison de connexions lentes/peu fiables

27 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 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 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. 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 l objet de v é rifications.

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


Télécharger ppt "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."

Présentations similaires


Annonces Google