Gestion de projet informatique
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/
L’élaboration du Cahier de Recette
- La structure d’un dossier de tests est très proche de la structure des données définie dans le modèle conceptuel des données (compréhensible par la MOE ainsi que par la MOA) réalisé pendant les travaux de spécification fonctionnelle.
- Précisément le mode opératoire du scénario de tests sous la forme d’une séquence d’actions à effectuer
- Le résultat attendu à l’issue de l’action pour chaque action du mode opératoire
- La référence au dossier de tests définissant les données métier exploitées en entrée et manipulées au cours du processus
- A chaque étape de vérification d’une fiche de tests (action / résultat attendu) correspond un cas de test identifié dans la matrice de tests. Cette matrice permet de faciliter :
- La lisibilité de la fiche de test par la MOE car rapprochée des spécifications détaillées
- La qualification des problèmes rencontrés au cours de la recette
- La gestion de la recette
- les configurations matérielles et logicielles de la plate-forme
- les valeurs du paramétrage logiciel de façon exhaustive
- Contexte et objectif du document
- Objet de la recette
- Documents de référence
- Responsabilités
- Plate-forme de recette
- Outils de recette
- Présentation générale
- Description de l’arbre de test
- Actions générales
- Liste des fiches
- L’ensemble des points fonctionnels (ou règles de gestion) devant faire l’objet d’une validation
- Les différents cas d’utilisation
- Elle définit le niveau de qualité fonctionnelle souhaité ainsi que le périmètre de la recette
- Elle doit être validée par la MOA
- Les tests de déminage peuvent être établis en collaboration avec la MOA (compétence métier).
- Ces tests permettent de confronter le logiciel très tôt aux futurs utilisateurs.
- Les ressources de la MOA devront être avertis qu’il ne s’agit que d’une aide au développement et non d’une recette d’intégration finale
- Lors de la recette interne, les résultats des tests effectués et les demandes de modification de la MOE sont inscrits dans le cahier de recette en temps réel. Le cahier de recette reflète ainsi l’avancement de la recette en continu
- Il rappelle les éléments indiqués par le cahier des charges
- La MOA pourra accepter ou non les potentielles demandes de dérogation
- Si la MOA accepte, la MOE pourra livrer le logiciel incomplet ou conforme partiellement aux spécifications
- La pré-recette permet à la MOA si la qualité du logiciel est suffisante pour pouvoir être testé. Il faut donc que :
- Tous les livrables convenus sont bien fournis (éléments logiciel et bordereaux de livraison, PV de recette interne, liste des restrictions éventuelles)
- La plate-forme de recette est opérationnelle
- Aucun problème bloquant empêchera le jeu des scénarios
- Elle débouche sur un procès-verbal et annonce le début de la recette fonctionnelle
- La recette provisoire (recette principale) consiste en un contrôle sur la base de l’ensemble des fiches de tests établie par la MOA et validée par la MOE
- Chaque anomalie détectée fera l’objet d’une fiche de fait technique
- Validation : aucune anomalie n’a été détectée, la recette sur site pilote peut alors débuter
- Validation sous réserves : aucune anomalie bloquante n’a été détectée, un PV de validation sous réserve avec la liste des anomalies peut être signé. La MOE s’engage alors à corriger les anomalies avant la livraison sur le site pilote pour recette définitive
- Refus : des anomalies bloquantes ont été détectées ou toutes les exigences. Le PV de recette fera part de ce refus et des raisons. Une fois la phase de correction terminée, la recette provisoire devra être recommencée
- Le groupe de recette est constitué des membres de la MOA ayant si possible participé à la rédaction du cahier des charges et/ou cahier de recette. Lors de la pré-recette, les membres les plus expérimentés évalueront rapidement la qualité générale du logiciel
- Le support technique est composé de membre(s) de la MOE à plein temps. Ils permettent d’assurer la maintenance de la plate-forme et le bon fonctionnement du logiciel (correction des anomalies bloquantes immédiate)
- Le support fonctionnel est représenté par une personne connaissant parfaitement le métier, le cahier de recette et les dossiers de spécifications fonctionnelles. Elle sera responsable de la conduite du changement tout au long de la recette
- Le support méthodologique et organisationnel est assumé par le chef de projet MOA. Il permet d’expliquer comment une fiche de tests doit être interprétée ou bien la façon dont un fait technique doit être rédigé
- Validation, mise en exploitation
- Validation sous réserves, pas d’anomalie bloquante
- Refus, la correction des anomalies donne lieu à la recette provisoire
- La MOE intervient pour l’installation des sous-ensembles logiciels
- La MOA administre la plate-forme
- La même équipe MOA que pour la recette provisoire
- Elle fait suite à la recette définitive
- La mise en exploitation du logiciel devrait révéler de nouvelles anomalies
- Les anomalies remontées font l’objet d’une correction et d’une re-livraison du sous-ensemble logiciel
- Toute modification du logiciel suite à une demande MOA pendant une phase quelconque de la recette donne lieu à un avenant entre les parties
- Il en est de même pour toutes les demandes d’évolution intervenant après l’acceptation du dossier des spécifications logiciel
Estimation – Méthode des points de cas d’utilisation
- Caractériser les acteurs par « poids de complexité » appliqué à leur action (1 = simple, 2 = moyen, 3 = complexe)
- UUCP = UAW + UUCW
- TCF = 0,6 + ( 0,01 * (somme(I * PTx)))
- EF = 1,4 + ( -0,03 * (somme(I * EPx)))
- UCP = UUCP * TCF * EF
- UCP = UUCP * 0,6 * 1,4 = UUCP * 0,84
- UCP = UUCP * (0,6 + (0,01 * 5 * 14)) * (1,4 + (-0,03 * 5 * 3,5))
UCP = UUCP * 1,3 * 0,875 = UUCP * 1,137
- Exhaustivité des diagrammes en termes de couverture fonctionnelle et en termes de précision dans la description des acteurs et des rôles.
- Niveau de détail qui doit offrir une vision complète tout en évitant le piège de « l’expansion infinie ».
- Pas de standard actuellement pour définir formellement le niveau de détail approprié.
- Généraliser un acteur va amener à le compter 1 seule fois.
- Relations d’inclusion, extension et généralisation entre les CU. Dans certaines estimations ces types sont comptés dans d’autres, ils sont omis. A évaluer au cas par cas.
- Modèle objet du domaine
- Modèle objet d’analyse
- Modèle objet de conception
- Modèle objet d’implémentation
- Modèle objet de test
- Classes
- Attributs
- Opérations
- Associations
- États
- Transitions
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/
La réutilisabilité un atout à ne pas oublier pour faire baisser les chiffrages !
Une MOA doit se faire aider d'experts en architecture technique et en méthodologie de gestion de projet informatique pour analyser les réponses aux appels d'offres. Pour différentes raisons, l'entreprise peut avoir décidé à l'avance quelle prestataire elle allait prendre. Souvent des consultants sont déjà en place ou bien les décideurs connaissent les soumissionnaires. L'exemple type à ne pas suivre, c'est ce projet de refonte d'une application dans le domaine des assurances. Des développeurs et un chef de projet étaient dans la place pour concevoir un socle technique dans le but de concevoir toutes les briques de base d'une sur couche d'abstraction dans le but de la réutilisabilité et de l'évolutivité. Malheureusement leurs livrables ne furent pas expertisés comme il se doit. Les documents furent livrés et c'est tout, personne coté MOA pour contrôler leur travail. Quand il a fallu lancer les appels d'offres, bien qu'ils n'avaient pas le droit de communiquer avec leurs hiérarchies, ils ne s'en privèrent pas, donnant un très net avantage à leur société. Au niveau de la méthode de chiffrages, on trouvait les fameux abaques permettant d'estimer les charges. Un ensemble de critères comme le nombre de boutons, de règles, d'entités métiers, de composants graphiques, ..., déterminaient le type de complexité d'un écran (simple, moyen, complexe, très complexe, hors norme) avec le nombre de jours correspondant (1, 3, 5, 8). Un expert en gestion de projet informatique avec l'aide de techniciens auraient détecté qu'à aucun moment il n'était fait mention de la réutilisabilité permettant de mutualiser et faire baisser les charges. Sans contre expertise coté MOA, le contrat fut signé. Aussi on se retrouva vite dans l'impasse car la MOE appliqua à juste titre systématiquement ses abaques telles que spécifiés dans le contrat signé et obtint des charges exorbitantes. Un écran qui aurait été qualifié de simple par tout le monde se transforma en complexe du fait notamment de l'absence de la mutualisation et de la prise en compte du socle technique déjà conçu auparavant et qui n'avait jamais été validé par les commanditaires.
Une bonne pratique de gestion de projet, pour diminuer les risques dans un domaine qu'on ne connaît pas, qu'on ne maîtrise pas ou qu'on ne comprend pas, consiste à s'entourer d'experts dans les domaines concernés (par exemple architecture technique, méthode de gestion de projet informatique, estimations, aide à la dépouille et à l'analyse des réponses aux appels d'offres, …), le surcoût sera bien vite rentabilisé car on aura évité de tomber dans les pièges.
"Grand est celui qui n'a pas perdu son coeur d'enfant."
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 :
Comment préparer une bonne recette ?
La recette d'une application est l'étape finale de la réalisation d'un projet informatique mais pour qu'elle soit un succès il faut la préparer dés le début.
Cela commence par la mise au point de la stratégie de precette. Que recetter et comment ? Il s'agit des tests unitaires, de non régressions, d'intégrations, fonctionnels et utilisateurs.
Les tests fonctionnels sont les cas de tests permettant de vérifier les cas utilisateurs (Use Case en UML). Une bonne pratique est de concevoir ces cas en même temps que l'on rédige les cas d'utilisation. En effet il y a très peu d'efforts à fournir puisque les cas d'utilisation décrivent déjà les pré-conditions (état du système avant le déclenchement du cas), les étapes, les règles et les exigances mise en oeuvre et les post-conditions (état du système après l'exécution du cas). Il suffit alors dans le cas de test de copier/coller le cas d'utilisation et de valoriser les données en entrèe, de spécifier les données attendues. L'exécution du cas de test se chargera de comparer les valeurs réellement calculées avec celles attendues. Les experts métier doivent contribuer ou valider les cas de tests.
L'architecture technique doit spécifier les outils pour les tests unitaires (xUnit). Très souvent toutes les entités métiers ne sont pas réalisées, on doit donc bouchonner pour pouvoir simuler les scénarios fonctionnels comme si elles existaient pour de vrai. On parle souvent dans la littérature des "mock" objet. L'architecte identifie les frameworks les plus appropriés, les configure, forme les développeurs.
Le chef de projet met en place une organisation et une politique pour s'assurer que tous les tests unitaires sont bien effectués car très souvent ils sont ressentis comme une lourde contrainte de la part des développeurs.
Le "testeur" technique utilise des outils (Sélénium, QC, ...) pour les tests d'intégration et de non récession. Les cas de tests définis (scénarios métier stratégiques, simulation d'interactions utilisateur avec des écrans, ordonnancement de batchs) sont enregistrés et rejouer à la demande comme par exemple avant la livraison d'une itération ou d'un sprint.(dans la méthode Scrum). Le rapport de livraison contient la liste et les résultats de tous les tests intégration/non régression qui ont été effectués.
Les outils doivent exécuter les étapes en injectant les données en entrée et comparer les résultats obtenus avec les données attendues.
Sinon, des tickets d'anomalies sont créés (Mantis) et on recommence tous le cycle de développement et de tests.
Si toutes les étapes de tests ont été consciencieusement effectuées et si la MOA est restée impliquer à toutes les étapes des itérations, le déroulement des tests d'acceptation par les experts métier devraient être un succè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 :