Etapes d'un développement logiciel

Etablir un cahier des charges Initial

Un docment 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 francais 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 validation et des documents permettant cette validation est décrit plus en détails.

Etablir un cahier des charges Fonctionel

Le cahier des charges fonctionel 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 Fonctionel doit contenir une version plus détaillé des objectifs du projet et expliciter comment le cahier des charges fonctionel va répondre aux objectifs du projet.

Pour cela plusieurs type de document doivent êtres intégrés dans le cahier des charges fonctionel:

  1. Une description du logiciel
  2. La listes des Acteurs et la descriptions 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 si 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'exaustivité et la completude


Etablir une Interface Utilisateur Initiale

Création des différentes fenetres 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 posibilité 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 oeuvre


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é nécessaire (+ Diagrammes de séquence initiaux ).

IL faut donc préciser pour le logiciel tous les points suivants:

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 :

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