[…]Prenez ce dont vous avez besoin, puis adaptez-le. Laissez ce dont vous ne pouvez tirez profit pour votre projet. N'oubliez jamais que la conduite de projet n'est pas une fin en soi, mais a pour objectif de permettre l'aboutissement du projet. Voilà en quoi elle est indispensable. La méthode est un cadre, un guide, un garde-fou, où s'inscrivent la démarche et les actions de conduite de projet. Elle est garante de la cohérence d'ensemble, mais ne doit pas devenir un carcan empêchant toute adaptation et créativité.[…]
Extrait tiré de la préface de Manager un projet informatique, Englender&Fernandes
Gestion de projet
Qu'entend-on par projet?
Les ingrédients
Un besoin défini
dans un contexte comportant ses propres contraintes,
la volonté et des ressources pour satisfaire ce besoin
Différents types de contraintes
temps
ressources (hommes, matériels...argent)
Gestion de projet
Difficultés inhérentes d'un projet
Multiplicité des acteurs
complémentarité/antagonisme des rôles - les acteurs en relation jouent des rôles complémentaires (demande/offre) jusqu'à ce qu'un imprévu surgisse…
communication - nécessité de l'emploi d'un vocabulaire commun et compris par tous, besoin d'une forme pour chaque type d'échange définie à l'avance (rapport, réunion, notes, documentation…)
relations humaines - il a une drôle de tête ce type là…
Expression claire du besoin
une cible mobile - le besoin est mal défini au départ et/ou évolue en cours de route...
définition de jalons marquant la progression dans la réalisation - comment juger/justifier de l'avancement dans la réalisation
Gestion de projet
Nécessité d'une méthode de conduite de projet
L'adoption d'une méthodologie est nécessaire pour organiser et optimiser cette activité humaine. Quelques exemples de méthodes de gestion de projet pour le découpage du projet :
Jalonnement - consiste en la décompostion du projet en terme de jalons marquant des étapes dans l'avancement du projet, ces étapes étant validées par le client systématiquement
Découpage en phases/tâches - présentée plus loin, cette approche est la plus classique
Découpage en tâches - cette approche, qui est souvent incluse dans la méthode précédente, revient à décomposer le projet en tâches pour lesquelles les ressources nécessaires et les produits résultats sont identifiés
Découpage en activités WBS (Work Breakdown Structure) - revient à découper le projet en activité, chacune étant placée sous la responsabilité d'une personne
La méthodologie permet de fixer des règles clairement exprimées pour
la coordonnation des acteurs et des tâches de façon optimale,
définir la forme des échanges,
les procédés de validation des livrables…
Gestion de projet
Les acteurs
L'organisation humaine est beaucoup plus classique : maîtrise d'ouvrage/maîtrise d'œuvre.
Rôles de la maîtrise d'ouvrage
définit l'objectif, le calendrier, le budget
exprime les besoins dans une forme fonctionnelle
pilote le projet à l'aide d'un comité de pilotage et d'une équipe projet qui sera en contact avec la maîtrise d'œuvre.
Rôles de la maîtrise d'œuvre
définit les choix techniques en adéquation avec les choix fonctionnels et les contraintes
désigne un chef de projet chargé du bon déroulement de la réalisation
Gestion de projet
(Découpage en) phases du projet
Phase 1 : Avant projet
étude d'opportunité,
de faisabilité,
développement et rédaction du dossier de conception, technique
et rédaction d'un cachier des charges techniques.
Phase 2 : Réalisation
préparation (découpage en tâches, planification, éventuel choix d'une démarche qualité),
réalisation,
documentation
et tests unitaires.
Phase 3 : Mise en œuvre
recette,
qualification,
mise en production sur sites pilotes puis globale,
maintenance...
Gestion de projet
Qualité
Le principe fondateur d'une démarche qualité est souvent résumé par : je dis(écris) ce que vais faire et je fais ce que j'ai dit(écrit)
Définitions
d'après la norme ISO 8402-94
Ensemble des caractéristiques d'une entité qui lui confèrent l'aptitude à satisfaire des besoins exprimés et implicites.
d'après la norme ISO 9000:2000
Aptitude d'un ensemble de caractéristiques intrinsèques à satisfaire des exigences.
De façon plus générale
Qualité externe
→ satisfation des clients
Qualité interne
→ amélioration du processus de rendu de service
Quel niveau de qualité rechercher dans le service rendu?
un service parfait revient trop cher;
la non-qualité a un coût en raison des engagements pris...
→ un niveau permettant de se positionner par rapport à la concurrence!
Gestion de projet
Certification d'une démarche qualité
Différentes normes existent dans le domaine de la qualité. Une norme répond en général aux attentes d'un secteur d'activité particulier :
Secteur des services : ISO 9001, EFQM
secteur de la sécurité : ISO 17799
secteur des technologies de l'information : ITIL, COBIT
secteur du développement informatique : CMMI
L'adoption d'une démarche qualité doit correspondre au cadre d'activité
Une certification ou accréditation est une reconnaissance par un tiers indépendant de la conformité d'un service à une norme, ce qui assure les éventuels clients d'un certain niveau de qualité.
Gestion de projet
Cahier des charges
Document contractuel décrivant ce qui est attendu par la maîtrise d'ouvrage de la maîtrise d'œuvre
décline les éléments suivants :
contexte - positionnement stratégique et politique du projet par rapport à l'entreprise
objectifs
vocabulaire - définition d'un vocabulaire commun
périmètre - nombre de personnes directement concernées par la mise en place du projet
calendrier - date de fin, mais idéalement dates pour différents jalons ou livrables
Clauses juridiques
Gestion de projet
Outils de planification et de suivi de projet
Planification des tâches/ressources - elle repose sur des outils classiques permettant de prévoir une organisation optimisée pour finir au plus tôt en fonction des contraintes d'antériorité existant entre tâches et de leurs durées estimées;
Diagramme de Gantt
Méthode Pert, méthode des potentiels métra (dite mpm) → lien
Les outils modernes permettent
une gestion des ajustements induits par le non-respect des durées,
une vision en terme de ressources
et une vision instantanée de l'état d'avancement de la réalisation.
C'est l'ensemble des méthodes, des techniques et des outils concourant à la production et au suivi d'un logiciel, au delà du seul aspect de programmation.
Différentes qualités sont attendues du logiciel à produire :
fiabilité
adéquation aux besoins
ergonomie
efficacité
maintenabilité
Nous retrouvons là des aspects de gestion de projet adaptés au contexte particulier de production de logiciel, dont la recherche de la satisfaction de besoins clairement énoncés et le respect de contraintes liées au contexte du projet.
Génie logiciel
Généralités - Objectif
Choix d'une démarche permettant de satisfaire les objectifs suivants
favoriser l'expression anticipée des besoins afin de minimiser les évolutions fonctionnelles en cours de projet
assurer la «qualité» selon le sens adopté
maîtriser les coûts, les risques
assurer la conformité du travail aux attentes
et tenant compte des éléments suivants
la «culture projet» de l'entreprise
l'équipe projet
le niveau de connaissance des utilisateurs
le contexte (actualité sociale, économique et politique de l'entreprise)
les acteurs du projet
le type de projet
…
Génie logiciel
Modèles séquentiels
Modèle en cascade
Principe : une étape doit être terminée ET validée avant d'aborder l'étape suivante
La fin de chaque étape est marquée par un livrable.
Des retours en arrière sont possibles
Avantages
réduction des risques par un processus de validation continu
Inconvénients
Tests tardifs
Pas de prise en compte des évolutions
Modèle d'intégration
Principe : prise en compte des effets d'une externalisation pour une partie du projet - les aspects relatifs à l'intégration de la solution (considérée comme une boîte noire) au système existant sont primordiaux, et en particulier la description des interfaces avec lesquelles la «boîte noire» s'adapte.
Avantages
Meilleure maîtrise des budgets
Meilleure maîtrise des délais
Inconvénients
Non prise en compte des évolutions
Problème de sécurité (accès d'un tiers au cœur de l'entreprise)
Relations avec un tiers…
Génie logiciel
Modèles séquentiels
Modèle en «V»
Principe : formalisation des tests à chaque étape permettant de tester ce qui en découle
Avantages
Les tests forcent au détail, favorisant l'expression des besoins et réduisant les évolutions futures, ces dernières ayant été anticipées
Inconvénients
Processus lourd car l'expression de tests est fastidieuse à faire et à documenter
Cette lourdeur peut peser sur les délais
La participation de l'utilisateur est délicate car les aspects techniques apparaissent rapidement
Modèle RAD (Rapid Application Development)
Principe : utilisation de prototype permettant la participation active des utilisateurs (avec tous les autres) pour une expression fine des besoins dans un temps donné
Avantages
Favorise la communication entre les acteurs
Allège la formalisation
Maintient une pression constante
Modéle adapté aux langages objets
Inconvénients
Génie logiciel
Modèles itératifs
Modèle incrémental
Principe : utilisation de prototypes pour favoriser l'expression des besoins et conduire à la spécification de sous-ensembles fonctionnels (et aux spécifications techniques).
Chaque composant fonctionnel peut être l'objet d'une livraison
Chaque livraison peut conduire à une évolution, une correction des fonctionnalités (y compris celles déjà livrées)
Avantages :
Permet la correction des erreurs de développement
…, de spécification
…et de conception
Inconvénients
Vigilance sur une trop grande remise en question des fonctionnalités
Génie logiciel
Modèles itératifs
Modèle UP (Unified Process)
Repose sur huit piliers
Définition de cas d'utilisation pour l'expression des besoins
Recours à UML pour la modélisation des architectures fonctionnelle, logique et matérielle
Démarche itérative et incrémentale
Gestion des priorités pour les besoins/fonctions exprimés
Approche modulaire permettant la réutilisation
Modélisation visuelle (UML, prototypes)
Automatisation des tests
Identification, priorisation et traitement des risques
Modèle généraliste, décliné en fonction de besoins particuliers par divers modèles (Catalysis, Extreme System Analysis, RUP, EUP, 2TUP…)
Génie logiciel
Méthodes «agiles»
Généralités
La méthode RAD porte les germes de nombreuses méthodes modernes :
[…]Une remise en question permet de rester au plus près des besoins des utilisateurs.[…]
L'accent est mis sur la satisfaction du client (au détriment du contrat initial et de la démarche qualité) :
itérations courtes pour favoriser les échanges avec le client
usage intensif des tests
La frontière entre méthodes agiles et incrémentales est floue, de nombreux principes étant communs!
XP et DSMD sont des méthodes agiles éprouvées, tandis que FFD, Crystal, Scrum et ASD sont plus jeunes…
Méthode DSDM (Dynamic Sofware Development Method)
basée sur des itérations courtes, des tests fréquents et beaucoup de mises en commun entre développeurs et utilisateurs
gestion forte des délais maintenant une pression pour une convergence rapide vers la solution finale
Génie logiciel
Méthodes «agiles»
Modèle FDD (Feature Driven Development)
Les caractéristiques de l'application doit permettre un découpage fonctionnel
Les itérations sont très courtes et conduisent toutes à un livrable fonctionnel
Les fonctionnalités sont développées par de petits groupes de développeurs (2 ou 3), ce qui assure une qualité du code, des tests et de l'intégration
Avantages
la progression visible du projet est motivante pour les développeurs
le suivi s'en trouve facilité pour les chefs de projet
le client a une vision claire de l'avancement
Modèle Crystal
Adapté pour une petite équipe projet (6 personnes) sur un projet peu complexe
Repose sur une grande proximité entre développeurs et utilisateurs
Comporte 4 étapes
spécification des besoins par l'observation des utilisateurs, puis classement de ces besoins
conception - choix de technologies
planning des fonctionnalités
itérations : lors d'une itération, développement d'une fonctionnalité par 2 ou 3 développeurs, puis présentation aux utilisateurs pour validation ou recadrage
Génie logiciel
Méthodes «agiles»
Modèle Scrum
Repose sur un développement isolé pour limiter le risque d'éparpillement
La gestion des évolutions émanant de la maîtrise d'ouvrage doit être définie avant le début des itérations - faut-il arrêter une itération ou non?
Comporte 3 étapes
Initialisation: identification des fonctionnalités, tâches et échéances
Sprint :
traitement des tâches par priorité décroissante
point hebdomadaire (30 min):
qu'est ce qui a été fait?
qu'est ce qui reste à faire?
comment gérer les obstacles?
développement isolé et par petit groupe
présentation à la maîtrise d'ouvrage
Clôture ou nouvelle itération
Génie logiciel
Méthodes «agiles»
Modèle XP (Extreme programming)
Adapté pour une petite équipe projet dans un contexte changeant
Repose sur 4 principes
Communication directe entre développeurs et utilisateurs
Simplicité dans le choix des solutions en accord avec la MOA
Retour d'expérience : participation des utilisateurs, réactions rapides pour la validation (ou l'invalidation) du travail fourni, éventuelle reformulation des attentes
Livraison au plus tôt, selon le planning
Organisation
définition de l'architecture et analyse des performances
planification des itérations et calendrier associé (4 à 6 semaines par itérations)
itérations
itérations de tests pour ajuster la solution aux performances attendues
mise en production
maintenance
Génie logiciel
Méthodes «agiles»
Méthodes BDD (RSpec, cucumber)
BDD pour Behavior Driven Development
Donnent suite à l'approche TDD (Test Driven Development) - la pratique revèle que le TDD met l'accent sur la production de code satisfaisant des tests, mais pouvant être éloigné des attentes des utilisateurs. Pourquoi?
Les tests reposent souvent sur la structure des objets mis en jeu et en sont rendu fragiles de ce fait, car la structure, qui n'est pas l'enjeu, devient une lourdeur…
L'expression de comportement attendus des objets permet de préciser les tenants et aboutissants de l'application, i.e. en se positionnant à un niveau d'abstraction assez élevé! C'est l'objectif de RSpec et Cucumber. Ils permettent d'exprimer en fonction d'un contexte et d'un événement ce qui est attendu d'une entité - RSpec est plutôt utilisé pour se placer au niveau des objets et Cucumber au niveau des applications. Chacun permet un mode d'expression lisible par toutes les parties (codeurs, testeurs et usagers finaux).
Génie logiciel
Ce qu'il faut retenir?
[…]Vous aurez des contraintes de délais à respecter, un cahier des charges imprécis et ambigu, une phase de développement souvent baclée et peu documentée, des tests unitaires rares et des tests d'intégration de non-régression non réalisés. La seule étape incontournable est l'épreuve de qualification par les utilisateurs, qui arrive malheureusement trop tard pour constater les écarts avec leurs besoins réels.[…]
Pb : Quelle méthode choisir pour ne pas tomber dans un tel scénario?
Sol : Au lieu de chercher une méthode spécifique dont l'adéquation ne sera pas parfaite, appliquer les principes qui semblent bons à être employés dans un contexte particulieri.
Des différentes approches présentées, nous pouvons retenir les principes suivants:
modélisation;
itérations;
incréments;
automatisation des tests;
travail par petits groupes;
échanges réguliers avec les utilisateurs finaux pour valider et prolonger le travail réalisé.
Modélisation
Mini-plan
UML
Unified Modeling Language - Généralités
Diagrammes - types
Diagrammes - les incontournables
Exemple de mise en pratique
Outils
BDD - Cucumber
Design Patterns
Design Patterns?
Quelques lectures introductives
Critiques
Frameworks
Modélisation - UML
Unified Modeling Language - Généralités
Langage de modélisation basé sur des diagrammes permettant de construire un modèle abstrait du système.
Mis au point dans le cadre de la modélisation logicielle, il sort largement de ce cadre.
Permet la représentation de trois points de vue pour la description d'un système :
la partie fonctionnelle (fonctions du point de vue de l'utilisateur)
la partie structurelle (objets, attributs, méthodes)
la partie dynamique (interactions internes, externes)
Unifié car :
il resulte de l'harmonisation des méthodes de modélisation jusqu'alors les plus adoptées;
il n'est attaché à aucun langage de programmation ni aucune méthode de conception;
il permet une modélisation adaptée à toutes les phases de la vie d'un logiciel;
bien que général, il dispose de concepts propres à de nombreux terrains d'application spécifiques : temps réel, architecture distribuée, calcul intensif…
Pourquoi modéliser?
le modèle est le support de son propre développement;
définir une abstraction simple permet une communication entre étrangers (utilisateurs/développeurs)
établir une comparaison claire entre différentes possibilités;
estimer divers paramètres liés au modèle (classes, concepts, temps de développement, obstacles…);
explorer différentes solutions de façon économique.
UML 2.0 propose 13 types de diagrammes, ces types pouvant être ventilés en 3 catégories : les diagrammes de structures, de comportement et d'interaction.
Les diagrammes structurels ou statiques - pour représenter ce qui est dans le système :
Diagramme de classes
Diagramme d'objets
Diagramme de composants
Diagramme de déploiement
Diagramme des paquetages
Diagramme de structure composite
Les diagrammes comportementaux - pour représenter ce qui se passe dans le système modélisé :
Diagramme des cas d'utilisation
Diagramme états-transitions
Diagramme d'activité
Les diagrammes d'interaction ou dynamiques - pour représenter les échanges d'informations dans et avec le système :
Diagramme de séquence
Diagramme de communication
Diagramme global d'interaction
Diagramme de temps
Modélisation - UML
Diagrammes - les incontournables
Pour nos besoins, nous nous limiterons aux types de diagrammes suivants :
diagrammes de cas d'utilisation et d'activité
diagramme de séquence
diagramme de classes
Les diagrammes de cas d'utilisation
Représentent le système, ses fonctionnalités associées aux rôles particuliers des utilisateurs externes et les systèmes secondaires s'il en existe
Chaque fonctionnalité du système est représentée par un «cas d'utilisation» - ellipse
Chaque rôle qu'une entité extérieure au système peut jouer est représenté par un acteur
Ce diagramme ne peut résumer toute l'information : chaque cas d'utilisation doit être assorti d'une description textuelle aussi détaillée que possible :
Références - titre, résumé, version…
Scénario principal, alternatives, erreurs - ces éléments étant extrêmement structurés
La description textuelle d'un cas d'utilisation débouche sur d'autres types de diagrammes : séquence et activité.
Les diagrammes d'activité
Représentent sous forme d'organigramme un cas d'utilisation
La trame principale ainsi que tous les branchements conditionnels, les boucles et les erreurs figurent sur ce diagramme.
Seules les actions et les transitions apparaissent
Les diagrammes de séquence illustrent l'aspect dynamique mais d'un point de vue différent.
Les diagrammes de séquence
Représentent les séquences d'interactions pour un cas d'utilisation entre l'acteur à l'origine de l'interaction, le système et les autres membres interagissant
Possible de faire figurer les alternatives et les erreurs au prix d'une surcharge du diagramme (en faisant figurer des références à la description textuelle)
Les diagrammes de classes
Représentent la structure des objets manipulés par les utilisateurs mais également ceux intervenant dans le fonctionnement interne du système.
Une classe est décrite par ces attributs et ces méthodes.
Les relations entre les différentes classes sont également représentées. Il peut s'agir de relation d'association, de composition et d'agregation, de généralisation ou spécialisation…
Des classes peuvent être regroupées en package lorsqu'elles forment une entité cohérente et indépendante sur le plan sémantique et fonctionnel (dans une moindre mesure).
Ce type de diagramme est important pour les méthodes orientées objet car il est possible de générer automatiquement du code à partir de ce diagramme
Modélisation - UML
Exemple de mise en pratique
Dans un contexte particulier, comment échaffauder les différents diagrammes? Dans quel ordre?
Cf. support papier
En synthèse, le processus de modélisation comporte les étapes suivantes, les premières constituant la phase d'analyse, la conception débutant lors des itérations
Modélisation métier - on cherche à modéliser le processus complètement
Description structurée du processus que le système doit permettre
Diagramme de cas d'utilisation illustrant les acteurs impliqués et un cas d'utilisation illustrant "globalement" le processus
Diagramme d'activité associé au processus reprenant la description détaillée du processus
Définition des besoins du système informatique - certaines parties du processus peuvent sortir du cadre du système informatique à concevoir. Ici, on souhaite identifier celles qui seront prises en charge par le système et les détailler, sans entrer dans le détail de son fonctionnement.
Identification des actions propres au système informatique en vue de la description des cas d'utilisation
Description succincte des cas d'utilisation et diagramme de cas d'utilisation
Description détaillée des cas d'utilisation :
Sommaire d'identification - Titre, résumé, auteur, version, date de création et de mise à jour...
Description des enchainements - Préconditions, postconditions, scénario nominal, séquences alternatives
Diagrammes de séquence pour chaque cas d'utilisation - à partir des scenarii des descriptions détaillée
Retour sur les diagrammes de cas d'utilisation - les relations liant les cas, les acteurs sont-elles assez précises? (importance pour quoi?); les cas relèvent-ils tous des mêmes problématiques (peut-on former des packages distincts avec des groupes de cas?)?
Si des problèmes de concurrence existent, définir les contraintes via un diagramme de contexte statique
Analyse du domaine (partie statique) - identifier les concepts du domaine qui, pour une partie, se traduiront par des classes - identifier les relations existant entre ces concepts (association, généralisation, composition, agrégation, ainsi que les multiplicités) - identification d'attributs - rassemblement des classes en packages…
Analyse du domaine (partie dynamique) - cette analyse vise à exploiter les aspects dynamiques formulés par les cas d'utilisation pour identifier les changements d'état, les informations échangées et les opérations par lesquelles ces changements ont lieu afin d'affiner la modélisation de classes et en particulier les attributs et les opérations liés à ces aspects, leur nature publique ou privée…
Définition des itérations - la définition des itérations devrait se baser sur les cas d'utilisation en tenant compte des dépendances entre packages s'il en existe afin d'avancer dans le contexte le plus simple (celui dépourvu de dépendances a priori) pour débuter, puis enrichir peu à peu le système.
Définition de l'architecture système - où l'on se questionne sur l'opportunité de l'usage de patrons adaptés à la modélisation de l'architecture du système (modèle en couche, utilisation de contrôleur, MVC...)
Définition des opérations système(itération #1) - identifier les opérations du système correspondant aux cas d'utilisation de la première itération. formaliser les contrats d'opération afin de décrire le résultat de l'exécution d'une opération : un contrat d'opération permet de décrire le système avant et après l'opération. Ceci permet de décrire les changements d'état sans préciser comment ce changement est fait. Cette étape est la dernière relative à l'analyse : on passe ensuite côté conception!
Diagrammes d'interaction (itération #1) -
Diagrammes de classes de conception (itération #1) -
Définition des opérations système, Contrats d'opérations, Diagrammes d'interaction, Diagrammes de classes de conception (itérations suivantes) -
Retour sur l'architecture -
Passage au code objet -
Déploiement de l'application -
Modélisation - UML
Outils
xfig : logiciel de dessin vectoriel pour plateformes Linux comportant quelques éléments pour la création de diagrammes UML.
Des logiciels spécifiques existent : Rational Rose permet la création de diagramme et la génération de code partant de ces diagramme…! Plus d'informations ici. Umbrello le permet également dans un cadre plus open-source (uml.sourceforge.net) et peut exporter les diagrammes sous forme d'images (divers formats).
Modélisation - BDD
Rappels
Méthodes agiles: travail par petits incréments et itérations pour converger vers ce qui est attendu des utilisateurs…
…mais la direction initiale est très importante pour ne pas se perdre sur de mauvaises pistes!
XP: automatisation des tests d'«acceptance» (différents des tests unitaires), i.e. validant les attentes des utilisateurs.
Les tests d'acceptance doivent être écrits par les développeurs AVEC les utilisateurs:
sous forme d'exemples (scénarios) aidant au développement de la réflexion
aide à développer un langage commun et compris de tous
Cucumber
Cucumber est un outil permettant
de décrire en langage courant des fonctionnalités (features) et des scénarios (scenarios) illustrant ces fonctionnalités dans différents contextes;
de faire le lien entre ces scénarios et le code de l'application à développer;
à automatiser le contrôle de l'application par rapport aux différents scénarios écrits.
Il permet de faire le lien avec de nombreux langage de programmation. Le langage Gherkin permet de structurer les descriptions en langage courant. Ces descriptions sont associés à des étapes de définitions (step définitions) dont le rôle est de faire le lien avec le langage de développement de l'application.
Modélisation - Design Patterns
Design patterns?
defs
principes
exemple : Modèle-Vue-Controleur
Modélisation - Design Patterns
Quelques lectures introductives
Le chapitre 2 de «Design Patterns» écrit par Gamma, Helm, Johnson et Vlissides.
Le chapitre 27 de «Le guide du développeur Java 2» écrit par Saumont et Mirecourt, accessible en ligne chez l'éditeur ou ici.
Ces deux lectures permettent de :
mettre en avant les objectifs sous-jacents des patrons de conception, les grands principes;
présenter quelques patrons ultra-classiques ET utiles pour nos préoccupations.
Critiques et perspectives
Les critiques sont en général assez bonnes au sujet de l'ouvrage de référence relatif aux patrons de conception, alors…
les design patterns sont au cœur de nombreux frameworks…
Modélisation - Frameworks
Framework?
Application framework : …consists of a software framework used by software developers to implement the standard structure of an application for a specific development environment…
Software framework : …special case of software libraries in that they are reusable abstractions of code wrapped in a well-defined Application programming interface (API), yet they contain some key distinguishing features that separate them from normal libraries …
inversion of control : le framework met en place des mécanismes permettant la gestion des échanges, des évènements…
default behavior
extensibility : il est possible d'étendre les abstractions proposées par un framework
non-modifiable framework code : le code source n'est pas modifiable
Quelques exemples
Java 2 Standard Edition - framework de développement d'application pour poste de travail
Java Enterprise Edition - extension de J2SE pour la programmation d'applications serveur, distribuées, intégrant des applications tierces…
Netbeans - pour le développement d'application pour poste de travail visant à simplifier la programmation de swing
JavaFX - pour le dévelopement d'applications web «riches»
Quel framework choisir pour nos besoins?
Java n'est pas suffisant? Je sais programmer!
Besoins: application graphique standard, construction de graphiques d'analyses de données, affichage de documents web…
Choix? Swing, JavaFX, Qt…?
Modélisation
Ce qu'il faut retenir?
La modélisation est une démarche utile à la construction de la réflexion. Divers outils permettent d'aider à la formalisation dans cette construction :
UML: les principaux types de diagrammes UML(classes, séquences et cas d'utilisation) sont très répandus. Il est important de s'approprier les notations qui les définissent.
les approches BDD (e.g. Cucmumber).
Une des retombées d'un travail de modélisation est de faire émerger les problématiques et ceci peut permettre l'identification de design patterns adaptés pour la construction des solutions. Le choix d'un framework peut également être ainsi guidé.
Bonnes pratiques de programmation
Mini-plan
Tests
Tester?
Tests unitaires
Tests fonctionnels
Outils
Versionning
Outils de partage
Bonnes pratiques de programmation - Tests
Tester?
Pour vérifier la validité du code et la conformité de l'application aux attentes, il faut tester!
Tester peut devenir une activité très fastidieuse : il est naturel d'écrire des scripts de tests pour automatiser ce travail.
Lors de l'extension d'un code valide, l'ajout de code peut conduire à un dysfonctionnement des parties déjà écrites : cela constitue une regression.
L'écriture des tests en parallèle du codage et leur compilation permet de déceler les bogues et autres régressions.
L'écriture de tests est bénéfique à divers égards :
force à prendre du recul sur le code, sa cohérence, sa conception
diviserait le nombre de bogues par cinq
alimente le processus de documentation du code
Principaux obstacles à l'écriture des tests
un travail en plus, une nouvelle habitude…perçue comme une perte de temps.
la sous-estimation du temps consacré au débogage d'un code associée à l'absence de quantification immédiate de la valeur ajoutée par la pratique des tests.
A quel moment écrire les tests?
Avant : pour cadrer davantage le codage - c'est l'idéal
Après : c'est malheureusement souvent le cas
Jamais : la pratique des tests est une pratique assez nouvelle
Bonnes pratiques de programmation - Tests
Tests unitaires
Testent de façon isolée les fonctionnements d'un code en se basant sur des cas d'utilisation, sans se soucier du reste de l'application.
Si un fonctionnement non-souhaité est découvert, un nouveau cas d'utilisation doit être formalisé et ajouté aux tests, et le cas échéant, le code corrigé pour satisfaire l'ensemble des tests.
L'accumulation des tests assure la non-régression du code lors de son évolution : tout nouveau code doit validé tous les tests.
Les cas d'utilisation peuvent être complétés par des scénarii d'utilisation plus complexes.
Qualité des tests
Se limiter aux cas d'utilisation spécifiés - ne pas en ajouter artificiellement
Tests et codage doivent être alternés régulièrement
La qualité des tests vient avec l'expérience…
Bonnes pratiques de programmation - Tests
Tests fonctionnels
Testent de façon globale les fonctionnalités attendues de l'application en imitant l'utilisateur.
Utilisés par/avec le client pour contrôler la qualité de l'application.
Utilisés par les développeurs pour tester l'interface :
pour les interfaces via la ligne de commande, ces tests reposent sur les outils classiques;
pour les interfaces graphiques, le recours à des outils permettant de reconstruire les interactions de l'utilisateur via le clavier, la souris et autres dispositifs peut s'avérer nécessaire.
Utilisés par les développeurs pour tester l'ergonomie :
afin d'éliminer des enchaînements d'écrans lourds,
de raccourcir des séquences trop complexes
d'équilibrer des parties trop pauvres ou trop riches de l'interface
Bonnes pratiques de programmation - Tests
Outils
Comment mettre en œuvre des tests avec mon langage de programmation? La réponse dépend du langage de programmation et des outils utilisés pour le développement :
pour les développeurs Java, il existe JUnit - www.junit.org pour mettre en place des tests unitaires;
le chapitre 6 de «Eclipse et JBoss» écrit par Djaafar, accessible en ligne chez l'éditeur ou ici.
Bonnes pratiques de programmation - Versionning
Les VCS (Version Control Systems) sont des outils permettant de suivre dans le temps un ensemble de fichiers. Ils sont construits autour de programmes simples dont l'objet est la gestion des différences entre versions d'un fichier. Tout est parti de diff…
Problème général : comment conserver les différentes versions d'un fichier? Plusieurs solutions :
Conserver chaque fichier dans toutes ses versions;
Conserver chaque ligne apparaissant dans une des versions et connaitre pour chaque version les lignes la constituant;
Conserver uniquement une liste d'opérations permettant de transformer la version précédente en la version suivante. Il est possible de rechercher la plus longue chaîne commune entre deux items et en déduire les parties à retirer de (ajouter à) la version antérieure pour obtenir la dernière version - ce que fait diff
Potentialité de diff = intérêt a priori (économie de place) + contexte (unix i.e. lien avec d'autres commandes…)
Formats : exemples, et colordiff
Ce-dessous, deux versions d'un même fichier:
<html>
<body>
<h1>Page de Bob</h1>
<p>Ceci est un pararagraphe.</p>
<br/>
<p>Ceci est un pararagraphe</p>
</body>
</html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.../...dtd">
<html>
<head>
<title>Page de Bob</title>
</head>
<body>
<h1>Page de Bob</h1>
<p>Ceci est un pararagraphe.</p>
<br/>
<p>Ceci est un pararagraphe.</p>
</body>
</html>
La commande diff indique les opérations à réaliser (avec une syntaxe proche de celle de ed) pour passer du fichier indiqué en premier argument au fichier passé en second argument:
bob@minisfa:~ > diff F1 F2
0a1
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
1a3,5
> <head>
> <title>Page de Bob</title>
> </head>
6c10
< <p>Ceci est un pararagraphe</p>
---
> <p>Ceci est un pararagraphe.</p>
La sortie précédente se limite au strict nécessaire. Il est possible d'insérer des lignes supplémentaires permettant de replacer des lignes modifiées dans leur contexte. Notez les utilisations de la commande colordiff.
bob@minisfa:~ > diff -u F1 F2 | colordiff ... ou ... bob@minisafa:~ > colordiff F1 F2
--- F1 2010-11-11 21:12:48.000000000 +0100+++ F2 2010-11-11 21:13:16.000000000 +0100@@ -1,8 +1,12 @@+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
+ <head>+ <title>Page de Bob</title>+ </head>
<body>
<h1>Page de Bob</h1>
<p>Ceci est un pararagraphe.</p>
<br/>
- <p>Ceci est un pararagraphe</p>+ <p>Ceci est un pararagraphe.</p>
</body>
</html>
Les lignes supplémentaires font gagner en lisibilité, mais laissent également une chance d'appliquer les opérations alors que de petites modifications ont été introduites entre les deux versions qui ont servi à construire le diff. Le «contexte» fourni par les lignes supplémentaires peut s'avérer précieux!
Lien avec d'autres commandes
diff sait produire des scripts pour ed
bob@minisfa:~ > diff -e F1 F2
6c
<p>Ceci est un pararagraphe.</p>
.
1a
<head>
<title>Page de Bob</title>
</head>
.
0a
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
.
bob@minisfa:~ > { diff -e F1 F2 echo w;} | ed - F1
bob@minisfa:~ > diff -e F1 F2
patch permet d'appliquer le patch...
bob@minisfa:~ > diff -u F1 F2 > LePatch
bob@minisfa:~ > patch < LePatch
patching file F1
bob@minisfa:~ > diff F1 F2
bob@minisfa:~ > patch -R < LePatch
patching file F1
bob@minisfa:~ > diff F1 F2
0a1
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
1a3,5
> <head>
> <title>Page de Bob</title>
> </head>
6c10
< <p>Ceci est un pararagraphe</p>
---
> <p>Ceci est un pararagraphe.</p>
…et de le retirer! Il sait également tirer profit du «contexte» quand cela est encore possible. patch permet beaucoup, mais ce n'est pas l'objet ici (par ici les curieux. ou Cf. le manuel).
Extensions
Traitements récursifs de répertoires
Traitement de fichers binaires (bsdiff et bspatch)
bzdiff, zdiff pour travailler sur du texte compressé
lien avec les VCS
Il est possible de composer des patchs : en appliquant au fichier initial F1 le diff obtenu à partir de F1 et F2 et en appliquant au résultat le diff obtenu à partir de F2 et F3, F3 est reconstitué.
Ceci pose le mécanisme au cœur d'une grande partie des VCS (d'abord SCCS, puis RCS, CVS, Git), autour duquel des améliorations ont été construites au fil du temps.
Parfois, c'est la dernière version qui est conservée et les diff sont faits pour passer d'une version à la précédente…car la dernière version est en général celle sur laquelle le travail porte.
Bonnes pratiques de programmation - Versionning
Les outils diff et patch ne suffisent pas en général pas à gérer toute la descendance d'un fichier, car assez naturellement, une descendance prend souvent une forme d'arborescence:
Une équipe peut être amenée à corriger les bugs rencontrés par des tiers dans une version particulière d'un fichier (ce fichier pouvant être une application, un contrat…) alors que dans le même temps, plusieurs pistes de développement, éventuellement instables ou expérimentales, sont poursuivies et qu'une version stable (au moins une) est également maintenue.
Les VCS (Version Control Systems) permettent de réaliser ce saut, en introduisant notamment la possibilité d'introduire des branchements dans l'évolution suivie par un fichier. Au fil du temps, la reflexion sous-tendant les VCS a absorbé diverses considérations dérivant de l'extension du suivi d'un fichier au contexte de la gestion de projet (plusieurs fichiers, plusieurs acteurs…):
Le suivi devrait se situer au niveau macro (i.e. à l'ensemble des fichiers correspondant à l'état d'un projet, du développement d'une application). Une vue micro (au niveau du fichier) peut être rapidement limitée.
Un VCS devrait définir un mécanisme de protection des fichiers réservés au suivi des fichiers afin d'éviter des utilisateurs maladroits ou malicieux de «casser» le suivi.
Il est important de pouvoir associer des méta-données à l'arborescence, afin de permettre l'ajout de commentaires et encore de connaitre les auteurs des modifications commises.
Deux modèles existent pour l'accès aux versions des fichiers via les opérations d'un VCS:
un modèle centralisé dans lequel les versions sont accessibles sur un dépôt centralisé (accessible via le réseau); les utilisateurs peuvent récuperer une version particulière, mettre à jour la dernière version d'une branche à partir de leur copie de travail…mais tous les opérations se font en général (et en particulier celles faisant intervenir différentes versions) sur le serveur.
un modèle décentralisé dans lequel chaque utilisateur dispose d'une copie du dépot, i.e. de tout l'historique de l'ensemble des fichiers. Les échanges entre utilisateurs passent par le stockage d'un dépot de référence sur un serveur : celui-ci peut être mis à jour par les utilisateurs.
Dans les modèles présentés, le problème des accès concurents se pose, ainsi que le pb des accès proches :
si deux utilisateurs veulent mettre à jour le même fichier (ou ensemble de fichiers) au même moment, sans mécanisme garantissant la cohérence des opérations, l'issue est complétement arbitraire. Deux solutions existent pour ces accès concurrentiels:
le verrouillage des fichiers : un seul utilisateur à la fois peut obtenir la permission de modifier un fichier…la cohérence est assurée, mais il y a possibilité de blocage des autres utilisateurs aussi!
Les VCS, pour la plupart, forcent la sérialisation des «commit» (opérations de mise à jour) et n'opérent une mise à jour que si elle conduit le dépôt à un état cohérent. En particulier, un commit intérrompu n'affectera pas le dépôt.
Il est possible qu'au moins deux utilisateurs souhaitent apporter leurs contributions respectives : le premier sera satisfait, mais il reste une chance au second que la mise à jour qu'il propose soit acceptée en l'état grâce à la fusion des modifications : les modifications apportées par deux utilisateurs peuvent ne pas interferer, e.g. si les modifications ne portent pas sur les mêmes parties d'un fichier… ainsi, il est possible que deux jeux de modifications puissent être fusionnés. Si tel n'est pas le cas, le second sera appelé par le VCS à tenir compte de la nouvelle version pour y incorporer ses propres ajouts.
Bonnes pratiques de programmation - Versionning
Outils
Les VCS sont nombreux et variés (e.g. ici). Parmi les plus répandus, CVS, Subversion et GIT.
La maîtrise d'un VCS passe par la compréhension des concepts qu'il manipule (et en particulier des liens avec les fichiers sous-jacents) et des opérations afférentes. Beaucoup de concepts se retrouvent d'un VCS à l'autre sous le même langage technique (repository, working copy, commit, check-out, update…). Il y a différents profils d'utilisation d'un VCS, et un utilisateur peut se limiter aux opérations du niveau qui l'intéressent :
utilisateur isolé;
utilisateur participant à un travail partagé par un groupe d'utilisateur;
utilisateur participant à l'intégration des versions au dépôt;
utilisateur participant à la gestion, l'administration du dépôt.
Commit - opération permettant de faire mémoriser l'état des fichiers
Ajout d'un tag (V01) - permet de donner un nom à l'état du dépot
Création d'une branche "ImportPlaquette" pour réaliser des expérimentations et partant de l'état actuel des fichiers
Déplacement vers la nouvelle branche
Modif des fichiers
Commit - crée un nouvel état sur la branche "Import..."
…
Création d'une nouvelle branche "ReseauxSociaux" partant de l'état actuel des fichiers
Déplacement vers la nouvelle branche
Modif des fichiers
Commit - crée un nouvel état sur la branche "Reseaux..."
Déplacement vers la branche "Import..."
Modif des fichiers
Commit de toutes les modifs
Déplacement vers la branche principale (master) et intégration (fusion) de toutes les modifs de la branche "Import..." pour définir une nouvelle version stable - associé à un nom (V02)
Création d'une nouvelle branche "Scriptaculous" et déplacement vers cette branche
Modif & Commit
Il est possible de restaurer les fichiers tels qu'ils étaient lors d'un commit particulier - il suffit d'identifier le commit
Il est possible d'afficher les différences d'un fichier entre différents commits
Il est possible de produire un "patch" permettant de décrire les différences entre un commit et l'état des fichiers d'une version de travail - ce patch pourra être intégré afin d'introduire les modifs d'une participant
Bonnes pratiques de programmation - Outils de partage
Quelques solutions pratiques pour un usage personnel ou non
GitHub - dépot GIT sur le web
DropBox - répertoire dans les nuages;
EverNote - outils de prises de notes personnelles et partageables (cloud également);
Tomboy - outils de prises de notes personnelles.
Systèmes de gestion de contenu (CMS en anglais)
spip
drupal
joomla
ou beaucoup plus simplement google groups, blog… mais ce ne sont plus des CMS!
Projet
Mini-plan
Tour d'horizon des solutions logicielles d'analyses statistiques
