Architecture logicielle, rédaction des spécificité techniques, methodologie, définition du besoin

Que veut le client?

Cette phase du projet "cahier des charges" expression du besoin permet de bien définir ce que veut le client. "Cahier des charges" est entre guillemet car certains fanatiques de la méthode Agile banissent l'expression "cahier des charges" de leur vocabulaire et prétendent qu'il n'y a pas de cahier des charges. Mais il faut bien commencer par quelquechose!

Cycle de vie d'une application informatique. Un exemple de ce cycle apparait dans cet article de création d'une application mobile multi plates formes.

Une fois le client intérrogé sur son besoin par l'ingénieur avant vente (ou vendeur...), la synthèse du besoin est rédigée sous forme de liste. Elle répond à la question "que veut le client?".

"Le client veut une balançoire, mais spéciale, avec 3 plateaux, pour ses 3 chats!"

Ensuite ce Besoin client sera transformé comme dans cet exemple grace à la phase analyse d'étude, étude de faisabilité. Cette synthèse est généralement envoyée par email au chef de projet.

Il faut principalement répondre à la question "comment le client l'a souhaité" voir illustration humoristique

Qu’est-ce qu’on a à faire, dans quel ordre, et quand est-ce qu’on livre quoi ? Tout cela dans un mode Agile, après la phase de planification agile.

Schémas

De la définition du besoin, jusqu’à l’implémentation.

Sprint : course ou itération

Release : agrégation de plusieurs itérations.

Ensuite nous passons aux phases analyse, conception, modélisation

Diagramme de Uses Cases à découpage en user stories (US) scénario

  Diagramme de composants primaires (tuyauterie…)

Exemple : si le client veut une application qui fait portail web, l’architecte se base sur son expérience, et dit qu’il faut un serveur d’application.

Le tableau UC-Composants permet de relier les uses cases aux composants préliminaires.

Diagramme de uses cases

Diagramme de uses cases = établi par la MOA Maitrise d’ouvrage, le chef de projet applicatif/metier en collaboration avec le Product Owner. Etude des cas d’utilisations et aussi des contraintes.

 

Une question? Posez-la ici

Découpage en stories (US) Users stories , scénarios

 

Idéalement 1 scénario par user storie.

 

Découpage en stories (US) User stories : comme le capaccio de bœuf découpé en fines lamelles, les users stories sont la découpe des users cases en fines tranches.

Une question? Posez-la ici

Une User Storie est démontrable, comme une contrainte. Je garde bien à l’esprit qu’en phase de démonstration il faudra que je démontre mes Users stories. Exemple : voilà le formulaire, je rentre des données, je clique sur un bouton. MAIS, est-ce que les infos du formulaire vont dans la base de données comme prévu? Je démontre tout. Je rentre des valeurs, je clique sur le bouton pour valider le formulaire, j’utilise mes contrôles JAVASCRIPT pour valider le formulaire. Ensuite les données partent vers le serveur de bases de données via un DAO, via HIBERNATE…

 

En passant, la montée en compétence sur un produit doit être intégrée : j’ai besoin de tant de temps pour apprendre cette techno. Ensuite grâce à ce temps investi, et cette techno maitrisée, je peux implémenter plus facilement et rapidement elle ou telle user story.

 

 

Les Users Stories donnent de la valeur au produit. Généralement j’attribue une User Storie à un un développeur (Je mets son nom à coté, ainsi, je le responsabilise).

En terme de livrable, il évolue. Puisque le logiciel évolue, le livrable évolue aussi.

Je vais découper mes users stories les unes à la suite des autres.

Un UC donne une US. Je livre un extrait du diagramme de composant lié à cette user storie.

Chaque scénario doit être précis : Je saisis les données. Je poste les données vers le serveur.

Plus je découpe, plus j’ai des choses simples, plus c’est facile à implémenter ensuite.

 

Une question? Posez-la ici

Diagramme de composants préliminaire

 

Diagramme de composants préliminaire = MOE Maitrise d’œuvre, architecte logiciel, l’expert en systèmes distribués. On peut se contenter de mettre « application server ». On est capable de dire qu’il y aura un serveur d’application. Exemple : notre application dans notre WAR communiquera avec ce serveur d’application.

Tout à coup au milieu du projet, on a besoin d’une librairie graphique. J’identifie un composant que je n’avais pas identifié au début : mon diagramme de composants se précise. Je pourrai mettre les versions à mes composants qui en fonctionneront avec les autres composants. Le mode agile permet d’avancer petit à petit chaque jour. Je regarderai ce qu’il existe comme librairie graphique dans mon benchmarking. Le diagramme de composants en release R0 sera différent de la release R3

Première phase : le diagramme de composants préliminaires permet de donner un ordre de grandeur de prix.

Diagramme de déploiement préliminaire : il arrive en fonction du diagramme de composants préliminaires. On va installer par exemple tel ou tel composant sur telle machine. Ma base de donnée sur tel serveur. Mon portail sur tel serveur.

Si je travaille dans une PME, je n’ai qu’un serveur, donc je vais déployer mon portail web et ma base de donnée sur le même serveur.

Si je travaille dans une SA multinationale, je vais penser dès le départ à créer des géo clusters avec plusieurs serveurs et des VPN pour les faire communiquer. 3 instances? Une en Europe? Une en Asie? Une en Amérique? Plusieurs serveurs, plusieurs bases de données. Mais je vais étudier dans mon benchmark si ma solution peut être répliquée entre plusieurs serveurs, exemple, 2 serveurs SQL Server en cluster, ou 2 serveurs Tomcat en cluster. Référence au Vision doc, au furbs. Il peut y avoir plusieurs diagrammes de déploiements en fonction de ce que l’architecte imagine.

Je commence par une petite architecture pour monter la valeur ajoutée à mon produit. Ensuite je scale

Benchmark des solutions matérielles et logicielles. Mon serveur sera-t-il une machine physique ou une machine virtuelle ? Mon système d’exploitation serveur sera-t-il Linux ou Windows ? Mon serveur d’application sera-t-il Jboss ou Tomcat ?

 

Le prototype : en parallèle du benchmark idée de savoir si notre solution est viable. On fait une sorte de squelette de l’application pour voir si ce squelette marche. Je choisis des composants adéquat pour réaliser un prototype qui fonctionne. C’est du code qui est jetable, mais ce n’est pas du code cible. C’est la preuve que je suis capable de répondre à la définition du besoin de mon client.

C’est le POC, le proof of concept

Le code du prototype ne devient pas forcément du code cible.

A la fin de la Release 0, je livre une première version de ces documents.

Diagramme de séquences préliminaire et diagrammes de classes préliminaires

Comme j’ai identifié mes scénarios, je vais pouvoir faire mes diagrammes de séquences.

Je fais mon diagramme de classes en parallèle.

Un algorithme est un ensemble de scénarios représenté par un diagramme de séquences.

Une question? Posez-la ici

Diagramme de séquences détaillé et diagrammes de classes détaille

Il est relié au scénario.

Réfléchir à la manière dont on code. Revenir de l’implémentation à la conception en reverse-engineering.

Je garde bien à l’esprit qu’en comité de pilotage, je livre mon code, mes diagrammes, et je fais ma démonstration.

Implémentation, tests unitaires, tests d’intégration, démonstration

Quand je crée une méthode, la première chose que je fais, je la teste avec un test unitaire. Je préfère une toute petite fonctionn1lité avec une bonne conception et un bon test. Parce ce qui est fait n’est plus à faire. Je ne fais plus de main() avec une sortie console, mais je fais un test unitaire.

Boucle : Conception àimplémentation àtests unitaires à Conception…

Couverture du code. Dans mes tests, quel est le pourcentage de code testé. Parce par exemple, je ne trouve pas intéressant de faire des tests unitaires sur des getters et des setters. Donc ma couverture de code descend. En général sur un Pojo, il n’y a pas d’erreur sur un getter ou un setter. On ne fait pas de tests sur les classes de données, mais sur les classes de traitement. Je peux avoir 60% de mon code couvert mais 100% de mon code de traitement couvert.

Tests unitaires automatisés, d’intégration. Ensuite avec l’experience (5-6 ans d’experience), je peux faire du TDD, test driven development ou développement piloté par les tests.

La démonstration : je montre à mon client que tout est ok, elle est à bien préparer

Une question? Posez-la ici

Les activités de codage

Conseillé : une user stori par développeur.

Un développeur peut travailler sur plusieurs stories dans un sprint, mais travaillera sur une user story à la fois, on fait les users stories les unes après l’autre, de manière séquentielle.

J’utilise GIT comme repository de code pur travailler avec mon équipe. Je crée généralement une branche par user storie. Soit je fais une branche locale ou sur le serveur que je descend ensuite, à étudier. Comme ça, si la branche n’est pas finie, elle ne bloque pas le tronc (version principale) et ce tronc reste démontrable comme toujours.

La version tronc est toujours démontrable, tout le temps !

La priorité est donnée au tronc qui doit être tout le temps impeccable.

On doit pouvoir sortir une release n’importe quand.

Une fois que j’ai fini ma user story à 100%, je merge : mon travail arrive dans un univers démontrable. Ma user story est démontrable.

Implémentation de fonctions de supervision, logs, log4j (code cible).

Implémentation de fonctions de déploiement (code cible).

Implémentation des outils de démonstration (hors code cible)

àImplémentation des tests unitaires

Je commit sur ma branche, qui sera mergée au tronc. Le tronc est intégré dans la release. Ma branche meurt et je débute une autre branche.

Quand est-ce que je commit ? Il n’y a pas de règles précises, mais souvent, généralement 3 à 4 fois par jour. Dès que je développe, je teste unitaire, ça passe, hop je commit.

J’ajoute un méthode, je la teste avec un petit test untaire, et hop, je commit.

Ne pas attendre la fin de la journée pour commiter, sinon on ne le fait pas finalement.

Règle : je ne commit pas de code si

-il ne compile pas.

-il n’est pas testé.

Le matin, lors de ma réunion Agile (morning meeting), je synchronise le tronc avec ma branche.

Le code freeze permet de me donner un temps d’intégration : quand toutes les branches sont mergées, mais est-ce que le tronc fonctionne toujours ? Il faut prendre le temps de voir si le tronc fonctionne toujours. Il y a un toujours un collaborateur dont la tache est de déployer le code sur la plate-forme d’intégration et de tester qu’après le merge de toutes les branches, le tronc fonctionne toujours.

Pour faire du versionning et gérer les montées de version facilement, je fais les diagrammes en .SVG et mes documents en .XML

Une question?