Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Etapes d'un développement logiciel Etablir un cahier des charges Initial Un doc

Etapes d'un développement logiciel Etablir un cahier des charges Initial Un document qui permet de décider si l'on se lance ou pas dans le projet et dans quel projet. Les Objectifs du projet, Objectifs du logiciel, Objectifs de la nouvelle version. C'est un document "Politique". Voire par exemple La description produit de OOO ou l' "Implementation Road Map" de PlanView ou cherchez sur google road map project ou pour un exemple en français Les objectifs du Projet NetBSD. Première recette : Valider le lancement du développement, pour cella le responsable doit valider un certains nombre d'éléments, voire l'inception ou la description des validations et des documents permettant cette validation est décrit plus en détails. Inception : Validation du cahier des charges initial 1. Validation Marketing 2. Validation opportunité 3. Validation de faisabilité 4. Validation d'expertise 5. Identification des Intervenants Etablir un cahier des charges Fonctionnel Le cahier des charges fonctionnel doit permettre de comprendre d'un point de vu utilisateur ce que l'on peut faire avec le produit visé. Ce document doit décrire toutes les utilisations du produit, et le niveau de qualité visé pour chaque utilisation. Le cahier des charges Fonctionnel doit contenir une version plus détaillé des objectifs du projet et expliciter comment le cahier des charges fonctionnel va répondre aux objectifs du projet. Pour cela plusieurs types de document doivent êtres intégrés dans le cahier des charges fonctionnel: 1. Une description du logiciel 2. La listes des Acteurs et la description de leurs Rôles (+ Diagramme d’acteurs) 3. La liste des Use case et leurs objectifs (+ Diagramme des cas d'utilisation) 4. Le tableau FQM (Fonctions / Qualités / Mesures) 5. Modèle Conceptuel initial (un Diagramme d'objet spécifique) 6. Glossaire (reprendre le glossaire du cahier des charges initial s’il existe) Recette : Faite par le client qui valide l'adéquation des descriptions avec les besoins. 1. Vérifier qu'aucun acteur n'a été oublié 2. Vérifier qu'aucun use case n'a été oublié 3. FQM: Vérifier l'exhaustivité et la complétude FQM : Fonctions Qualités mesures L'objectif de la recette du FQM est d'en vérifier l'exaustivité et la completude. L'exhaustivité Il faut s'assurer qu'aucune fonction réalisé par le logiciel ne manque au FQM. Deux types de fonctions celle qui sont nécessaire a l'objectif d'un acteur. Celle qui sont necessaire au logiciel pour fonctionner (n'ignorer pas des fonctions comme "le logiciel s'initialise"). La completude IL faut s'assurer que pour chaque fonction, les qualités importante on été listés et que pour chaqu'une une mesure a été définie, indiquer quand la mesure est tricte d'ou vient l'obligation d'une tel exigence (cahier des charges initial, estimation de fréquence/debit du cas d'utilisation, simplification pour atteindre une autre mesure). Etablir une Interface Utilisateur Initiale Création des différentes fenêtres utilisateurs. Description des modes d'interaction (en conjonction avec les cas d'utilisation). Recette : Faite par le client qui valide l'adéquation des descriptions avec les besoins. 1. Validation de la possibilité d'atteindre l'objectif du Use case avec l'interface (pour chaque use case) 2. Validation du rapport fréquence d'utilisation/ temps de mise en œuvre Etablir un cahier des charges Technique Un des objectifs de ce cahiers des charges techniques et de construire l'Architecture systémique et de définir l'organisation général des sources (organisation en package en java). Pour chaque cas d'utilisation il faut faire la liste des besoins d'ordre informatique ou matériel. IL est nécessaire ici de faire une première étude des responsabilités nécessaire (+ Diagrammes de séquence initiaux). IL faut donc préciser pour le logiciel tous les points suivants:  Machines, périphériques  Réseaux, protocoles  Langage de programmation  Logiciels annexe permettant de reliser une partie des objectifs  Librairies  Design patterns mise en œuvre  Difficultés techniques identifiées Recette : Faite par un architect logiciel l'objectif est de mesurer la crédibilité de la faisabilité La recette fourni une hérarchisation des cas d'utilisation, et une distribution des cas d'utilisation sur plusieurs itérations Construction Pour le groupe de cas d'utilisation affectés a l'itération courrante, il faut :  Ecrire le test du cas d'utilisation (forme interactive et forme "bas niveau")  Désiner les diagrammes de sequence et créer l'interface des classes utilisés  Homogénéiser les classes  Pour chaque classe écrire la documentation technique  Puis pour chaque classe ecrire le test unitaire de la classe  Ecrire les classes (méthodes ) Pendant tout le travail d'écriture des classes, les test unitaires sont fait et ainsi que les test de cas d'utilisation. L'écriture de ces test ne doit pas handicaper le développeur, il doivent donc uniquement détecter les défaut sans rien dire quand cela ne vas pas. Un bon test de cas d'utilisation affiche la liste des taches a faire, pour réaliser le cas d'utilisation, en précisant celle qui sont déjà finie. A la fin de chaque itération une recette doit être faite qui précise les objectifs ateints les ceux qui doivent encore être atteints, simplement préciser l'état d'avancement du logiciel. Beta Une itération est identifiée comme la béta, cette itération permet de tester au près des utilisateur l'absence de défauts mageurs du logiciel, tant dans son interface que dans le déroulement des cas d'utilisation. Le logiciel n'est pas complet et il faut que la documentation d'acompagnement le précise bien :). La béta doit expliciter tout ce qui sera fait dans le logiciel. Permet de tester a petite échelle les problèmes de déployement, la documentation utilisateur, La robustesse du logiciel, d'identifier des défaut de fonctionnement (bugs). Recette de nombreux interlocuteurs : utilisateurs, maitre d'ouvrage, testeurs. Les retours permette d'identifier des problemes fonctionel et opérationels. Alpha Version finie du logiciel. Cette version permet de tester de façon complete le bon fonctionement du logiciel. Si par miracle tout est parfait cette Alpha devient la Finale. On valide sur une partie adéquate (suffisement de cas représentatifs) les modalités de déployement. Finale Ouf ! Recette : Faite par un chèque uploads/Management/ etapes-d-x27-un-developpement-logiciel.pdf