Capitaliser sur un projet de développement est une tâche ardue. Avoir quelques bonnes habitudes peut aider à faciliter cette tâche.
Le débat concerne les outils utilisables au cours de la vie d’un projet de développement mené au forfait avec les technologies JEE. Cet article balaie un éventail d’outils destinées au chef de projet jusqu’à la personne qui déploie en production, en passant par l’architecte fonctionnel, l’architecte technique, le concepteur qui sera souvent le développeur.
Cet article n’a pas pour objectif d’être exhaustif. Le choix des outils est volontairement restreint. Cependant, cet ensemble d’outils peut servir de base à la fondation d’un socle technique pérenne.
Gestion de projet
Si l’on désire monter un projet au forfait en utilisant une approche Agile, il est préférable de discuter en amont du type de contrat à mettre en place. En effet, le type de contrat va structurer la démarche projet.
Par exemple, il peut être judicieux de définir un contrat qui enclenche un PV de recette à chaque livraison de lot; en veillant à ce que chaque lot représente une fonctionnalité autonome qui peut s’inscrire dans un « Sprint » Scrum. On s’assure ainsi d’avoir un produit déployé en production et exploitable à la fin de chaque lot.
Les outils que l’on peut utiliser dans la toute première phase d’un projet sont bien sûr les produits de gestion de planning. Ces produits sont destinés aux chefs de projet et/ou directeurs de projet. Dans certains cas, le chargé d’affaire ou un architecte fonctionnel peut mettre en place le planning.
Produit | Type de Licence | URL de téléchargement |
GanttProject |
Spécifications
La phase, qui vient après la mise en place du planning, est celle de l'écriture des spécifications; réponse à la question « Quoi ? ». Les spécifications peuvent être découpées en deux catégories : générales et détaillées.
Les spécifications générales doivent se baser sur un cahier des charges provenant du client et sur un ensemble d’ateliers ou de réunions à effectuer avec lui.
Ces spécifications expriment tout le besoin du client sous une forme compréhensible par le client à l’aide d’un formalisme adapté, comme UML. Dans ces spécifications générales, on peut retrouver des diagrammes UML appelés « Use Case ». Le chef de projet ou équivalent, ou même l’architecte technique dans certains cas où le métier est simple, est responsable de l’écriture des spécifications générales.
Les spécifications détaillées, quant à elles, permettent aux concepteurs/développeurs de comprendre le besoin client et de pouvoir le traduire en des termes techniques. Dans ces spécifications détaillées, on peut retrouver des diagrammes UML de classes, de séquence, d’activité ou de composant. Elles contiennent aussi un modèle conceptuel de données. Elles peuvent être mises en place par l’architecte technique.
La gestion des exigences et leur traçabilité est une problématique essentielle de la vie d’un projet. Avec une approche de type « MDA » (« Model Driven Architecture »), il devient important d’exprimer ces exigences sous une forme indépendante de toute plateforme (« PIM », « Plateform Independent Model »), et ensuite d’en instancier le modèle pour obtenir un modèle spécifique ou « PSM » (Plateform Specific Model »).
Produit | Type de Licence | URL de téléchargement |
Papyrus basé sur Eclipse |
Il existe aussi un plugin Papyrus pour Eclipse. Mais il semble moins riche que le produit lui-même.
Architecture
Le dossier d’architecture, à rédiger par l'architecte technique, présente la solution applicative et technique, en utilisant l'approche SOA par exemple (càd en définissant les sous-systèmes de Workflow, de BPM, de Référentiels, d’Administration, de Monitoring, d’Annuaire de services, d’ESB, …).
L'architecture applicative peut s'appuyer sur un modèle en cinq couches. Les couches peuvent être les suivantes : la présentation, la coordination, le service, le domaine et la persistance.
Dans la plupart des cas, les couches présentation et coordination sont regroupées ensemble au sein d'un module applicatif et les couches service, domaine et persistance sont regroupées ensemble au sein d'un autre module applicatif.
La couche présentation repose souvent sur le modèle MVC 2 ("Model Vue Controller", où il n’y a qu’un seul « Controller »).
L'architecture applicative peut être exprimée grâce à des diagrammes UML de classes et de composants. Elle dicte également les normes et standards à utiliser, ainsi que les outils associés (frameworks, ...).
L'architecture technique, quant à elle, traite des aspects liés à l'infrastructure qui va héberger la solution applicative. Elle utilise des diagrammes où sont représentés les briques d'infrastructure réseau, les serveurs, la sécurité, les flux ainsi que les logiciels. Elle traite aussi des contrats de niveau de service associés.
Produit | Type de Licence | URL de téléchargement |
OpenOffice (Impress) | ||
Eclipse | ||
JDeveloper |
Papyrus peut également être utilisé.
Conception et Développement
La conception technique (générale et/ou détaillée), à effectuer par les concepteurs/développeurs, représente la traduction des spécifications détaillées en briques technologiques. Elle utilise souvent des diagrammes UML de séquences et de classes. Elle peut contenir les algorithmes. Elle met à profit l'architecture orientée service (SOA), en déclinant les services associés aux objets Métier ou processus Métier, identifiés dans les spécifications ou même dans l'architecture, et en portant une attention particulière à la granularité de ces services.
La réalisation ou le développement des briques technologiques représente l'implémentation. Il s'agit du codage, en respectant les normes et standards, en utilisant l'approche "Test Driven Development" (TDD) par exemple, en structurant l'architecture applicative en couches indépendantes, en implémentant un framework de ValueObject pour échanger entre 2 couches successives, en implémentant des Design Pattern adéquats (Singleton, Factory, BusinessDelegate, DAO, Template Method, ...),
Les environnements de développement et de test doivent être mis en place lors de cette phase. L'environnement d'intégration peut également être en place lors de cette phase.
Intégration Continue
L'intégration continue fait partie de la phase de conception et de développement. Elle permet de valider le code produit lors des différentes livraisons. Les tests de qualité du code ainsi que les tests unitaires sont rejoués systématiquement à chaque livraison sur la plateforme d'intégration continue. Les tests unitaires ainsi rejoués permettent de tester la non régression des développements. Par exemple, des graphiques et des tableaux sont calculés et présentent la qualité du package en cours. Des alertes sont remontées vers les développeurs, concernés par la livraison, avec une trace de log adéquate.
Une bonne intégration continue repose sur le maintien d'un dépôt unique de code source (SVN), sur l'automatisation et l'industrialisation de certaines tâches liées au projet (compilation, tests unitaires, déploiement, ...).
Produit | Type de Licence | URL de téléchargement |
Eclipse (Eclipse Modeling Tools + plugin UML) | ||
JDeveloper | ||
JUnit | ||
Mockito | MIT License http://mockito.org/ | |
jQuery (Ajax) | ||
GWT | ||
ADF | ||
Spring | ||
SVN TortoiseSVN (partie cliente) | ASF License compatible GPL http://www.apache.org/licenses/ GPL http://www.gnu.org/licenses/licenses.html#GPL | |
Bugzilla | ||
Ant | ||
Maven | ||
MySQL | ||
PostgreSQL | Open Source license http://www.postgresql.org/about/licence | |
Oracle DB Express | ||
Tomcat | ||
JBoss | ||
Oracle Application Server 10g | OTN License | |
WebLogic 11g | OTN License | |
FindBugs | ||
PMD | BSD style License http://pmd.sourceforge.net/license.html | |
JMeter | ||
soapUI | Open Source Gratuite + Version Payante | |
Selenium | ||
Oracle Application Testing Suite | OTN License | |
VMware | Produit commercial, gratuit sur une courte période http://www.vmware.com/support/product-support/server/ | |
Oracle VM Oracle VM VirtalBox | OTN License GPL http://www.virtualbox.org/ |
Intégration Continue
L'intégration continue fait partie de la phase de conception et de développement. Elle permet de valider le code produit lors des différentes livraisons. Les tests de qualité du code ainsi que les tests unitaires sont rejoués systématiquement à chaque livraison sur la plateforme d'intégration continue. Les tests unitaires ainsi rejoués permettent de tester la non régression des développements. Par exemple, des graphiques et des tableaux sont calculés et présentent la qualité du package en cours. Des alertes sont remontées vers les développeurs, concernés par la livraison, avec une trace de log adéquate.
Une bonne intégration continue repose sur le maintien d'un dépôt unique de code source (SVN), sur l'automatisation et l'industrialisation de certaines tâches liées au projet (compilation, tests unitaires, déploiement, ...).
Produit | Type de Licence | URL de téléchargement |
Hudson | ||
Sonar |
Déploiement
Le déploiement est l'une des dernières tâches techniques sur le projet. Il s'agit d'installer l'exécutable de l'applicatif sur l'environnement cible (environnement de production en générale).
Ce déploiement peut être automatisé et industrialisé avec un niveau de détail poussé. En effet, un environnement virtualisé peut être utilisé. Dans ce cas, l'environnement cible peut être configuré (installation et configuration de produits) par l'équipe projet et livré au client. Cet environnement autonome et autosuffisant peut être ensuite dupliqué à volonté sur autant de plateformes que nécessaires (développement, intégration, pré-production, ...), à un delta de fichiers de configuration prés. Toute la difficulté réside dans le retouche des fichiers de configuration (adresse IP, ...).
Le déploiement est l'une des dernières tâches techniques sur le projet. Il s'agit d'installer l'exécutable de l'applicatif sur l'environnement cible (environnement de production en générale).
Ce déploiement peut être automatisé et industrialisé avec un niveau de détail poussé. En effet, un environnement virtualisé peut être utilisé. Dans ce cas, l'environnement cible peut être configuré (installation et configuration de produits) par l'équipe projet et livré au client. Cet environnement autonome et autosuffisant peut être ensuite dupliqué à volonté sur autant de plateformes que nécessaires (développement, intégration, pré-production, ...), à un delta de fichiers de configuration prés. Toute la difficulté réside dans le retouche des fichiers de configuration (adresse IP, ...).
Les outils qui peuvent être utilisés sont ceux vus précédemment; tels que Ant, Maven, VMware et Oracle VM.
Et pour conclure
J’ai essayé de présenter dans cet article un petit aperçu des outils à utiliser lors des différentes phases d’un projet. Mais j’ai également essayé d’apporter quelques éléments de réponse quant à la manière de traiter chaque phase.
L’ensemble des outils présentés peut être vu comme une liste évolutive, où chacun pourra venir ajouter d’autres outils.
Au delà des aspects traités, le processus de « delivery » en général dans une entreprise obéit à des règles bien précises. Il existe par exemple des bonnes pratiques telles que CMMI (« Capability Maturity Model Integration ») et des certifications associées.
J’ai essayé de présenter dans cet article un petit aperçu des outils à utiliser lors des différentes phases d’un projet. Mais j’ai également essayé d’apporter quelques éléments de réponse quant à la manière de traiter chaque phase.
L’ensemble des outils présentés peut être vu comme une liste évolutive, où chacun pourra venir ajouter d’autres outils.
Au delà des aspects traités, le processus de « delivery » en général dans une entreprise obéit à des règles bien précises. Il existe par exemple des bonnes pratiques telles que CMMI (« Capability Maturity Model Integration ») et des certifications associées.
Aucun commentaire:
Enregistrer un commentaire