Conduite de projet
Quelques raisons de l'échec des projets informatiques
Le retard, le demi-succès/échec voir le flop total d'un projet peut être du au fait que les utilisateurs ne savent pas ce qu'ils veulent ou ne savent pas communiquer leurs besoins. C'est l'éternel problème de la communication entre la MOA et la MOE. Je veux un lave linge et on me livre un lave vaisselle.
Les exigences peuvent changer tout au long du projet. De nouvelles réglementations, lois, politiques peuvent surgir et obliger à modifier des systèmes ou à se plier à de nouvelles normes ou processus.
La concurrence de plus en plus agressive et féroce impose de s'adapter rapidement en cours de réalisation de projet ou sinon on s'expose à développer une application déjà obsolète. Il faut savoir anticiper sur la technologie et faire les bons choix.
Très souvent, la direction générale ne s'implique pas dans le projet qui va alors s'enliser sans que rien de concret ne se réalise. Combien de projets ont accouché de milliards de tonnes de "spec" sans qu'il n'y ait une véritable application exécutable. On ne le dira jamais assez "seul compte l'exécutable".
Le manque de connaissance (attention je n'ai pas dit incompétence) sur la conduite de projet informatique est aussi un facteur de risque important. De trop nombreuse fois j'ai vu des directions avoir "les yeux plus gros que le ventre" et démarrer un projet bien trop volumineux en terme de périmètre et être obligée par la suite de retirer des blocs fonctionnels ou de les différer.
Au départ les directions disent on ne veut pas de vitrine technologique, les méthodes, la modélisation, les outils c'est trop cher, ça ne produit rien et ça ne sert à rien. Résultat rien n'est documenté, modélisé, simulé, tracé, bref le projet devient une sombre forêt marécageuse ou tout s'enlise et rien n'en sort.
Un des secrets des projets réussis (si si ça existe !), c'est de ne pas hésiter à s'entourer d'experts reconnus en gestion de projets informatiques, en architecture technique, en management, ... qui mettront en oeuvre les bonnes pratiques reconnues sur le marché et qui éviterons ainsi toutes les erreurs à ne pas faire. Ce seront des leaders qui donneront confiance et motiveront les équipes. Les projets seront découpés en lots à taille humaine, ils seront développés dans un cadre d'urbanisation du SI. Les collaborateurs penseront projet avant de penser à leur propre carrière. Les relations et la communication avec la MOE seront maîtrisées. Les bonnes pratiques et les meilleures technologies seront mis en oeuvre dés le départ pour avoir un avantage concurrentiel.
"L'effort d'unir sagesse et pouvoir aboutit rarement et seulement très brièvement.
Albert Einstein"
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Les (bonnes ?) relations MOA/MOE.
La démarche d'urbanisation du SI oblige à impliquer ses MOA (maîtrise d'ouvrage) et pour cela il faut se donner les moyens d'une véritable professionalisation du SI de sa MOA afin de minimiser les risques projets.
La MOA stratégique (commanditaire) donne les objectifs du futur système, les ressources financières et intervient au niveau du pilotage, des processus métiers et de la vue fonctionnelle.
Le maître d'ouvrage projet (MOA déléguée) est nommée par la MOA stratégique pour agir par délégation afin de mener à bien le projet. Elle doit définir les objectifs stratégiques, organisationnels, fonctionnels, technologiques.
L'assistance à MOA (AMOA) formalise les objectifs en exigences. Elle préparent les validations des solutions qui seront pilotées par la MOA et le planning de la MOE (maîtrise d'oeuvre).
La MOA doit :
- vérifier la conformité des solutions avec les exigences
- préparer et piloter la conduite du changement
- adapter l'organisation aux nouveaux systèmes
- définir les nouvelles procédures
- sensibiliser les personnes concernées par les changements
- communiquer vis à vis des acteurs concernés par le nouveau système
- former les utilisateurs
Le pilotage du projet est assué par la MOA déléguée qui rapporte au comité projet, de pilotage ou directeur pour les décisions majeures.
La MOA opérationnelle est constituée d'utilisateurs, d'experts métiers qui assurent les missions :
- d'expression de besoins
- de conduite du changement
La MOA opérationnelle intervient sur les vues processus métier et fonctionnelles (modéles des données métiers).
L'AMOA (entité appartenant à la même entreprise ou à des sociétés externes spécialisées dans les domaines requis) est constituée de spécialistes pour :
- formaliser le besoin des utilisateurs sous forme de cahier des charges fonctionnel
- définir les exigences de management de projet et d'assurance qualité
- préparer et conduire les appels d'offres et aider au dépouillement des offres
- définir et conduire les opérations de validation vis-à-vis de la MOE
Ces missions utilisent les cartographies du plan d'urbanisme.
La MOE réalise le projet pour le compte de la MOA. Elle met en oeuvre le planning et les moyens humains et logistiques nécessaires (prestataires, ...). Les livrables (documents ou produits) de la MOE sont définis dans le contrat et leurs dates dans un planning.
La (bonne ?) relation MOA - MOE pemet de formaliser les besoins de la MOE pour réaliser le système et la vérification par la MOA que les réalisations sont conformes aux attentes.
Cette formalisation s'appuie sur des modèles :
- modèle des processus métiers (évènements métiers, enchaînement d'activités, acteurs...)
- modèle des règles métiers (règles de gestion)
- modéle des services métiers
- modèle des objets métiers utilisés dans les processus et leur cycle de vie ainsi que les règles de gestion associées
- modèle organisationnel
- modéle de document
Le plan d'urbanisme contient donc tous ces modèles qui serviront de support à la rédaction du cahier des charges fonctionnels et aux cahier des charges techniques.
"Ce qui est passé a fui ; ce que tu espères est absent ; mais le présent est à toi."
Proverbe arabe
Voir aussi :
http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
1001 manières de faire échouer un projet.
C'est un secret de polichinelle, moins de 20% des projets sont des réussites (respect des coûts, délais et exigences MOA remplies), près de 30% sont purement et simplement abandonnés et plus de 50% ont explosé les budgets (2 fois plus cher en moyenne), les délais (2 fois plus long que prévu) et n'ont répondu qu'à 60% de la couverture du besoin fonctionnel spécifié !
Le risque d'échec augmentant exponentiellement avec la taille du projet (en moyenne au delà de 2 M€ / an).
Quelles en sont les raisons ?
Le projet est trop gros, il n'y a pas eu de lotissement, de priorisation des grands domaines du projet, la direction générale a eu les yeux plus gros que le ventre, elle a voulut tout faire en même temps. Le projet s'est éternisé, les équipes ont perdu toute motivation qui est pourtant la clé de la réussite. Les langues se sont déliées, les critiques ont commencé à fuser minant le moral des troupes. Le projet a perdu sa taille humaine, l'imagination créatrice des participants a été bayonnée.
Les changements en provenance de la MOA arrivent trop souvent sans que soit mis en oeuvre un véritable processus de la gestion du changement.
Chacun , MOA, MOE, consultants, sous-traitants apportent leurs contributions sans réelle communication.
Au lieu d'encourager les synergies, le chef de projet s'est confiné dans un rôle de simple intermédiaire, sans contrôles véritables entre les différents intervenants aux intérêts divergents.
La clé du succès est le degré d'implication des acteurs ainsi qu'une définition claire et compréhensible d'objectifs réalistes. Malheureusement dans la majorité des cas les utilisateurs ne savent pas ou n'arrivent pas à exprimer leurs besoins. L'insuffisance du recueil des besoins explique dans 50% des cas l'abandon des projets.
Dans 5% à 15% des cas, l'échec est du aux technologies non maîtrisées ou qui ne correspondent pas aux métiers.
Comme nul ne sait faire du 1er coup, ni tout faire en même temps, ce n'est pas un surcoût que de faire un schéma directeur, d'utiliser des référentiels (CMMi, ITIL, COBIT) et un plan d'urbanisme, qui sont au contraire des méthodes de diminution de risque.
L'échec n'est pas du à des mauvaises solutions à de vrais problèmes mais à de bonnes solutions à de faux problémes.
Donc, si vous voulez aller plus vite et bien prenez votre temps !
"La jeunesse est le temps d'étudier la sagesse. La vieillesse est le temps de la pratiquer."
Jean-Jacques Rousseau
Voir aussi :
http://urbanisation-si.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
http://urbanisation-si.eklablog.com/
9/11 Projet informatique, passer du moyen âge à l'ère industrielle. Comment vérifier que les développeurs n'ont pas mijoté un plat de spaghetti ? (qualité du code, audit, style, ...)
La méthodologie de gestion d'un projet informatique doit inclure les aspects normes et stratégie de codage. Sinon l'arnarchie va régner, chaque développeur aura sa propre manière d'indenter son code, de nommer les classes, les attributs, les méthodes (anglais, français, ...), les paramétres, les variables locales, ...
Chacun aura ses patterns de code, utiliser une boucle "for"(C, C++, Java, C#, ...) infinie et tester une condition à l'intérieure pour en sortir plutôt qu'un "for" classIque. Les développeurs c'est comme les écrivains, chacun a son style propre et on peut reconnaître son auteur sans regarder la signature. L'erreur chronophage et quasi systématique c'est la duplication de code. Tout développeur qui se respecte sait qu'il ne doit pas faire du copier/coller pour des problèmes évidents de maintenance, de lisibilité, d'impacts en cas de modifications, ... Les conceptions génériques coûtent toujours un peu plus chéres au départ mais on y gagne énormément en évolutivité, réutilisabilité et maintenabilité. Vous aurez beau dire qu'il ne faut pas le faire, il se peut que dans une situation d'urgence, pris par le stress, le développeur le fasse quand même en se disant qu'il modifiera à l'itération suivante, ce qui ne sera bien sur jamais fait car dans un projet les "TODO" s'accumulent vite et les impondérables aussi. Des alertes sur du code complexe peuvent être mises en œuvre. Le paramétrage de métriques concernant la taille des classes et des méthodes permet de déceler les parties de codes qui doivent être refactorées. Les outils peuvent aussi détecter de manière statique les mauvaises pratiques de codage, le code "mort", les expressions sous optimisées. Le chef de projet doit demander à l'architecte technique de mettre en place des outils d'audit comme Checkstyle ou PMD facilement intégrables et configurables dans les IDE comme Eclipse. Un autre concept, est d'analyser le byte code généré par le compilateur. C'est la philosophie choisie par FindBugs. Ce puissant outil permet de trouver des bogues potentiels, des problèmes de performances, ou des mauvaises habitudes de codage. FindBugs est le résultat d’une recherche menée par Bill Pugh à l’université du Maryland, et qui étudie les modèles de byte code venant de bogues dans de réels grands projets, comme les JDKs, Eclipse, ou le code source d’applications Google. FindBugs peut détecter des problèmes assez importants tels que des exceptions de pointeurs nuls, des boucles infinies, et un accès non intentionnel de l’état interne d’un objet.
Pour la qualité, la lisibilté, l'évolutivité, la réutilisabilité, la maintenabilité et les performances du code source il est vivement conseillé d'activer ces outils sans attendre les premiers développements. Si on se base sur la méthode UP (Unified Process) l'installation des outils et leurs paramétrages relévent de la discipline Environnement au début de la phase Élaboration.
Mieux vaut donc anticiper l'audit de code à moins que les plats de spaghettis soient votre spécialité.
Voir aussi le site :
http://bonnes-pratiques-si.eklablog.com/
8/11 Projet informatique, passer du moyen âge à l'ère industrielle. Les nominés pour le meilleur Environnement de Développement Intégré open source sont ...
Dans la méthodologie de gestion de projet UP (Unified Process) et les xUP (RUP Rational Unified Process, 2TUP 2 Tracks Unified Process, EUP Enterprise UP ...), l'environnement (tous les outils pour mener à bien le projet) est une discipline à part entière parmi les 9 de la composante statique de la méthode. L'IDE (Integrated Development Environment) est le cœur de toute la partie technique voir de l'ensemble du projet si on y ajoute des plugins. Alors comment choisir ?
Quel serait l'IDE idéal ? Quel est l'outil qui s'en rapproche le plus ?
Rappelons d'abord les fondamentaux.
L'éditeur doit avoir toutes les fonctionnalités modernes d'aide à la production de sources, citons en quelques unes parmi les plus utiles :
- outils de migration permettant par exemple de passer d'anciennes versions de Java vers la dernière Java 8,
- support des nouvelles versions des langages comme par exemple Java 8 avec les constructions lambdas, fonctionnels et les références de méthodes,
- la coloration syntaxique,
- la complétion automatique du code,
- les aides, la documentation,
- les templates de code,
- la détection au fil de l'eau d'erreurs de syntaxe,
- les avertissements concernant des variables non initialisées,
- les fuites de mémoire,
- la couverture de code,
- la génération de code,
- l'inclusion de bibliothèques de patterns de conception (GoF Gang or Four, ...),
- la personnalisation des raccourcis clavier,
- fusion, différences de code.
- couverture de code,
- un Profiler pour analyser et comprendre pourquoi telles ou telles parties de code prennent beaucoup de temps d'exécution
Une attention toute particulière pour la navigation dans le code. On doit pouvoir connaître tous les appelants et les appelés d'une méthode. À quel endroit est instanciée une classe.
Le refactoring c'est à dire par exemple le renommage de la classe, des méthodes, attributs, package, ... , doit être facilement accessible. Les erreurs de compilation doivent être détaillées et l'IDE doit proposé des solutions de corrections.
Le débogueur doit permettre la mise au point conditionnelle c'est à dire d'exécuter telle ou telle partie de codes si des conditions sont vérifiées. On doit pouvoir suivre l'exécution pas à pas dans les applications JEE à travers les serveurs d'application comme jBoss, Glassfish, Tomcat, …
Tous les langages et techniques utilisés dans votre application doivent être inclus,, par exemple pour une application JEE :
- Java, JEE
- XML, XSD, DTD
- web services : SOAP, WSDL
De nombreux assistants graphiques et conviviaux permettent de concevoir et mettre au point des documents XML, XSD, des web services. Ces outils s'interfacent avec les standards du marché comme les frameworks CXF, AXIS, JWS, ...
Dans mon IDE idéal, l'architecture SOA est pleinement intégrée avec des concepteurs grahiques de modélisation de processus métier à la norme BPMN 2. Des moteurs de règles open source comme DROOLS, Activity, … peuvent compléter la panoplie BPM/BRMS. Des ESB open sources sont intégrés en standard.
Bien sur tous les framework open source de tests unitaires (xUnit) et d'intégration doivent être présent en standard.
L'IDE idéal supporte tous les SGBD standards du marché (Oracle, MS SQL Server, DB2, MySQL, PostGRES, …) avec des éditeurs de conception et de requêtages.
Le déploiement et débogage avec tous les serveurs d'application du marché : jBoss, Tomcat, Glassfish, Oracle Server, IBM WebSphere, … doivent faire partie de la base commune de l'IDE.
Des aides à la configuration des frameworks d'architecture standard ( JEE 7, Spring, Hibernate, OSGI , EJB, JPA, CDI (Contexts and Dependency Injection) ) … permettent au développeur d'éviter les tâches répétitives. Les gestionnaires de projet Java comme Maven sont supportés.
La conception d'écrans de type client lourd (Swing, …) ou léger (HTML5, CSS, JavaScript, Ajax, Applets, Servlets, JSP, JSF, GWT, …) peut être réalisée par des concepteurs graphiques WYSIWYG. Ils doivent être bidirectionnels c'est-à-dire que toute modification manuelle de code doit se retrouver visuellement dans l'outil.
L'intégration et interface utilisateur commune à tous les systèmes de gestion de version (Git, Subversion ,CVS, ClearCase, Mercurial, …) est obligatoire.
Et n'oublions pas les outils de modélisation UML 2 qui doivent faire partie du lot, tout comme les générateurs de codes (MDA, QVT, OCL, …), d'écrans et de rapport (BIRT)..
De plus en plus d'applications d'entreprise s'accompagnent pour la partie frontal avec des clients d'applications mobiles (iOS, Android, WinPhone, …), le développeur doit avoir accès à un environnement complet pour les périphériques mobiles
L'IDE idéal disposent d'une très large bibliothèque de plugins complémentaires couvrant tout le spectre d'un projet depuis les processus métier, les règles métier, les exigences, la gestion de proget, les rapports de bogues (Issuezilla ou Bugzilla).
Une communauté importante d'utilisateurs participent aux développement de nouveaux plugins. Les logiciels commerciaux standards ont des versions s'intégrant complètement dans l'IDE (AGL, Enterprise Architect, …). Ils supportent de nombreux langages (C++, C#, .NET, scala, PHP, …).
Les nominés pour le meilleur IDE open source sont ...
- IntelliJ IDEA 13.1
- Eclipse Luna
- NetBeans IDE 8.0
Le premier prix est décerné à NetBeans IDE 8.0 pour sa convivialité, ses concepteurs graphiques et ses nombreux tutoriaux intégrés. Le deuxième prix revient à Eclipse Luna pour ses innombrables plugins. De toutes les manières il faudra imposer dans vos projets un IDE configuré avec toute une série de plugins dument éprouvés. Ce serait une très mauvaise idée de laisser les développeurs choisir ce qu'ils veulent à moins d'assumer les plantages du à des plugins obsolètes ou bogués.
Voir aussi le site :
Mais où est la documentation de l'application ?
Contraint par l'ouverture des marchés, la déréglementation et la concurrence de plus en plus d'organisations fusionnent ou se rapprochent afin de faire des économies d'échelle.
Parmi les applications existantes, on choisit celles qui seront intégrées dans le SI cible et qui contiendront toutes les nouvelles fonctionnalités. Pour faire évoluer, réutiliser et maintenir une application encore faut il savoir ce qu'il y a à l'intérieure. Quels sont les services et le modèle de données métier ? Normalement on doit avoir la documentation avec les exigences, les SFG, SFD (Spécifications Fonctionnelles Générales et Détaillée), STD (Spécifications Techniques Détaillée), dossier d'architecture technique, fonctionnel, les modèles de processus métier (BPMN Business Process Management Notation), les diagrammes UML (Unified Modeling Language), les cartographies d'urbanisation existantes et cibles. La documentation est trop souvent perçue comme une contrainte, peu utile, consommatrice de ressources et quand les échéances arrivent; elle est reléguée en toute dernière priorité.
Et pourtant elle est vitale. il existe encore d'anciennes applications (mainframe/COBOL) ou la culture de documenter n'existait pas et celui qui avait la connaissance ne voulait pas la diffuser pour ne pas perdre son pouvoir.
Ces applications sont figées pour l'éternité. Il est peine perdue de vouloir analyser les milliards de lignes COBOL avec des GOTO partout (quand elles n'ont pas été générées par un quelconque générateur qui nomme les variables incrémentalement !).
Pour pérénniser ses investissements, on doit mettre en oeuvre toutes les techniques facilitant la documentation. En effet il est stratégique pour les organisations de ne pas perdre leurs connaiisances, leurs processus métier, leur savoir faire.
Par exemple le savoir d'un expert métier constitué de règles peut être formalisé dans un moteur de règles.
C'est une étape difficile car les connaisances d'un expert sont exprimées en langage naturel avec toute sa complexité et ses ambiguités. Il faut comme toujours pour gérer la complexité diviser en niveaux de plus en plus fins. On part donc de macros règles composées de macros règles plus fines et ainsi de suite jusqu'à arriver à des règles élémentaires. Un moteur de règles possède des outils permettant aux experts métier de concevoir leurs règles directement et de les stocker dans le référentiel. Ainsi les règles sont identifiées, documentées, versionnées, sauvegardées, compilées, avec une véritable gestion de leur cycle de vie (créée, activée, archivée, compilée; ...), et un contrôle de qui peut y avoir accès et comment).
Le point remarquable c'est que l'ensemble de ces règles sont compilées à partir de leur conception en langage presque naturel (nécessitant bien sûr une préparation de la part des techniciens) et sont directement intégrées dans l'application ce qui a pour énorme avantage de raccourcir considérablement le développement.
On a donc un moyen technique permettant de structurer, de documenter, de pérénniser et d'implémenter directement les connaissances stratégiques d'une organisation.
Il ne faut pas hésiter à fournir cet effort supplémentaire au début pour s'approprier des techniques sophistiquées comme les moteurs de règles mais qui par la suite se révèlent être des atouts différenciants majeures face à la concurrence en permettant de mettre plus rapidement une fonctionnalité sur la marché (time to market) et sauvegardant pour le futur les connaissances dument acquises d'une organisation.
Voir aussi le site :