L’objectif de cette étape consiste à reprendre les problèmes concrets exprimés en langage naturel pour le projet pour en déterminer les solutions également exprimées en langage naturel.

Reprendre les fonctionnalités du cahier des charges pour les découper en plusieurs sous-fonctionnalités de moindre complexité.  Identifier les sous-fonctionnalités communes qui pourront être factorisées.

Faire une découpe à gros grain de votre système en plusieurs sous-systèmes de moindre complexité. Affecter les sous-fonctionnalités aux sous-systèmes. Raffiner l’architecture jusqu’à obtenir des composants élémentaires (des sous-systèmes regroupant des fonctionnalités et des données simples et indissociables).

Préciser les interactions des composants entre eux. Détailler les informations transmises, leurs sens de propagation, leurs natures, etc. Lors de ces interactions, indiquer les hypothèses faites en entrée, celles faites en retour.

Trouver des architectures logicielles et des patrons de conception connus auxquels on peut se ramener. Le cours JAVA dans lequel vous trouverez des patrons classiques comme MVC.

Décrire pour chaque composant sa raison d’être dans le système, les données qu’ils manipulent (en interne), qu’il émet ou qu’il reçoit (en externe), les services qu’il rend, les algorithmes qu’il exploite et les propriétés qu’il doit assurer.

Proposer pour chaque composant une suite de tests qui se chargera de vérifier le respect des exigences qui lui sont imposées. Établir à l’avance des mécanismes qui permettront d’inspecter l’objet et qui permettront d’assurer la conformité aux exigences.

Pour une meilleure compréhension et donc analyse du logiciel à concevoir, utiliser des outils de modélisation, des représentations textuelles ou graphiques qui permettront de se comprendre au travers de notations communes.

Affecter la responsabilité de la réalisation d’un composant à un membre de l’équipe, d’un sous-système à un ou plusieurs membres en fonction de la complexité. Pour illustrer, si la découpe du système se fait selon MVC, une équipe de 6 personnes affectera 2 personnes à la partie Modèles, 2 personnes à la partie Vue et enfin 2 personnes à la partie Contrôle.

Tenir à jour les ressources consommées (par exemple temps passé)  et les échéances fixées lors de la planification pour détecter au plus tôt les dépassements. En cas de débordements, prévoir des actions de repli.

 

Revue Spécification

L’objectif de cette étape consiste à traduire les solutions exprimées en langage naturel sous forme de solutions en langage informatique.

Traduire les éléments d’analyse en spécification de langage de programmation. Découper les sous-systèmes de manière fine en paquetages, classes, interfaces, types, méthodes, etc.

Afin de faciliter la communication au sein de l’équipe notamment lors de la spécifications d’interfaces communes entre les sous-systèmes,  adopter des styles de programmation : noms de méthodes, d’attributs privés, etc. Classiquement, reprendre les éléments d’analyse pour les retranscrire dans les commentaires présents dans la spécification. Assurer un minimum de traçabilité entre l’analyse et la spécification pour s’assurer que toute fonctionnalité prend sa source dans l’analyse qui a été faite du sous-système.

Assurer un niveau minimum mais indispensable de documentation des spécifications. En particulier, s’attacher à commenter l’ensemble des interfaces exportées vers l’extérieur que d’autres membres de l’équipe ou le client lui-même seront amenées à manipuler.

Pour concevoir les spécifications, on pourra s’appuyer sur le concept d’interface en Java. Pour plus d’explication, voir le cours JAVA.

Tenir à jour les ressources consommées (par exemple temps passé)  et les échéances fixées lors de la planification pour détecter au plus tôt les dépassements. En cas de débordements, prévoir des actions de repli.

 

Revue Implémentation

L’objectif de cette étape consiste à reprendre les solutions exprimées en langage naturel pour les implanter et vérifier que cette implantation correspond aux propriétés attendues de la solution.

Implémenter les éléments de spécification. Adopter des styles de programmation : commentaires en début de bloc d’instructions, de paquetages, de classes, de méthodes, etc.

Commenter, commenter, commenter … votre code. Lorsqu’un projet s’étale sur plusieurs semaines, ce que l’on a conçu au début et qui était complètement ne l’est plus en fin de projets. Par ailleurs, un travail d’équipe exige que les motivations pour écrire tel ou tel composant soient explicitées afin que les membres de l’équipe autres que l’auteur lui même en soient avertis.

Commenter le code aide à la préparation d’informations pour la génération automatique de la documentation.

Produire des tests unitaires dont l’objectif est de vérifier que votre composant fait effectivement ce qui est prévu mais aussi ne produit pas des comportements imprévus. Pour cela, il faut faire des tests unitaires qui portent uniquement sur un sous-système dont on a la charge et qui fonctionnent sans avoir l’intégralité des autres sous-systèmes. Cette tâche peut demander de l’ingéniosité et de la réflexion. Comme aux échecs, il s’agit d’anticiper un coup inattendu. Il requiert parfois d’implémenter des versions factices de certains sous-systèmes. Par exemple, pour se passer des entrées/sorties du sous-système d’interface graphique, on peut devoir implanter une version textuelle. Il s’agit de vérifier que l’implantation correspond à ce qui a été spécifié.

On peut organiser ces tests unitaires de manière à ce qu’ils soient effectués automatiquement. Dès lors que cette procédure est disponible, à chaque modification du composant, il devient possible de repasser automatiquement les tests unitaires afin de vérifier que les fonctionnalités précédemment implantées ne sont pas perdues. Ces tests sont alors utilisés comme tests de non-régression.

Produire des versions intermédiaires de votre logiciel. Il vous est demandé de produire un prototype ou une version simplifiée de votre projet. Mais il est également souhaitable de s’assurer au travers de versions encore plus simplifiées que vous êtes capables d’assembler vos composants et de vérifier la cohérence des résultats obtenus. Ces diverses versions simplifiées permettent de rassurer le client ainsi que les divers encadrants sur le bon déroulement du projet. Il permet de vérifier que le résultat est bien celui qui est attendu et qu’aucun obstacle non identifié au préalable ne risque de perturber le déroulement.

Tenir à jour les ressources consommées (par exemple temps passé)  et les échéances fixées lors de la planification pour détecter au plus tôt les dépassements. En cas de débordements, prévoir des actions de repli.

 

Revue Intégration

L’objectif de cette étape consiste à s’assurer que l’ensemble des implantations réalisées s’assemblent correctement pour répondre aux exigences exprimées dans le cahier des charges.

Expliciter les tests d’intégration qui porteront sur l’intégralité du système à la différence des tests unitaires qui se focalisaient sur les sous-systèmes pris un par un. Ces tests sont d’autant plus importants qu’ils peuvent être exploités lors de la livraison afin de vérifier que le logiciel se comporte comme attendu par le client dans le cahier des charges.

Préciser l’approche suivie pour produire la documentation. Notamment, prévoir les efforts à effectuer pour rendre cette documentation accessible à des personnes extérieures au développement.

Décrire la phase de production et de livraison. Détailler le processus de déploiement du logiciel auprès du client. Le développement logiciel ne s’arrête pas à la réalisation du logiciel en lui-même mais inclut la mise en place dans l’environnement de l’utilisateur. En particulier, il faut parfois qu’il soit capable de le construire, le modifier et le lancer sur une machine autre que celle de votre développement. La documentation doit notamment répondre à ce besoin.

Evaluer définitivement les ressources consommées afin de déterminer les développements qui ont été sous-estimés ce qui peut vous permettre ultérieurement de ne pas reproduire les mêmes erreurs.

 

Merci de transmettre toute erreur ou tout commentaire à Laurent Pautet (laurent(point)pautet(à)telecom(tiret)paristech(point)fr)