Etapes d'un dveloppement logiciel

Jalon 1-Etablir un cahier des charges Initial

Un document qui permet de dcider 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".

Livrable1 : Valider le lancement du dveloppement, pour cela le responsable doit

valider un certain nombre d'lments, la description des validations et des

documents permettant cette validation.

Validation du cahier des charges initial

1. Validation Marketing 2. Validation opportunit 3. Validation de faisabilit 4. Validation d'expertise 5. Identification des Intervenants

Jalon 2-Etablir un cahier des charges Fonctionnel

Le cahier des charges fonctionnels doit permettre de comprendre d'un point de vu

utilisateur ce que l'on peut faire avec le produit vis.

Ce document doit dcrire toutes les utilisations du produit, et le niveau de qualit

vis pour chaque utilisation.

Le cahier des charges fonctionnel doit contenir une version plus dtaill des

objectifs du projet et expliciter comment le cahier des charges fonctionnel va

rpondre aux objectifs du projet.

Pour cela plusieurs types de document doivent tre intgrs dans le cahier des

charges fonctionnel:

1. Une description du logiciel 2. La listes des Acteurs et les descriptions de leurs Rles (+ Diagramme

dacteurs) 3. La liste des Use case et leurs objectifs (+ Diagramme des cas d'utilisation) 4. Le tableau FQM (Fonctions / Qualits / Mesures) 5. Modle Conceptuel initial (un Diagramme d'objet spcifique) 6. Glossaire (reprendre le glossaire du cahier des charges initial sil existe)

Livrable 2 : Faite par le client qui valide l'adquation des descriptions avec les

besoins.

1. Vrifier qu'aucun acteur n'a t oubli 2. Vrifier qu'aucun use case n'a t oubli 3. FQM: Vrifier l'exhaustivit et la compltude

Jalon 3 - Etablir une Interface Utilisateur Initiale

Cration des diffrentes fentres utilisateurs. Description des modes d'interaction

(en conjonction avec les cas d'utilisation).

Livrable3: Faite par le client qui valide l'adquation 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 frquence d'utilisation/ temps de mise en uvre

Jalon 4- Etablir un cahier des charges Technique

Un des objectifs de ce cahiers des charges techniques et de construire l'Architecture

systmique et de dfinir l'organisation gnral des sources (organisation en

package en java).

Pour chaque cas d'utilisation il faut faire la liste des besoins d'ordre informatique ou

matriel.

IL est ncessaire ici de faire une premire tude des responsabilits ncessaire (+

Diagrammes de squence initiaux).

IL faut donc prciser pour le logiciel tous les points suivants:

Machines, priphriques

Rseaux, protocoles

Langage de programmation

Logiciels annexe permettant de raliser une partie des objectifs

Librairies

Design patterns mise en uvre Difficults techniques identifies

Livrable 4 : Faite par un architecte logiciel

l'objectif est de mesurer la crdibilit de la faisabilit

La recette fourni une hirarchisation des cas d'utilisation, et une distribution des cas

d'utilisation sur plusieurs itrations

Jalon 5 -Construction

Pour le groupe de cas d'utilisation affects l'itration courante, il faut :

Ecrire le test du cas d'utilisation (forme interactive et forme "bas niveau")

Dessiner les diagrammes de squence et crer l'interface de classes utilises

Homogniser les classes

Pour chaque classe crire la documentation technique

Puis pour chaque classe crire le test unitaire de la classe

Ecrire les classes (mthodes)

Pendant tout le travail d'criture des classes, les tests unitaires sont fait et ainsi que

les tests de cas d'utilisation. L'criture de ces test ne doit pas handicaper le

dveloppeur, ils doivent donc uniquement dtecter les dfauts sans rien dire quand

cela ne vas pas. Un bon test de cas d'utilisation affiche la liste des taches a faire,

pour raliser le cas d'utilisation, en prcisant celle qui sont dj finie.

A la fin de chaque itration une recette doit tre faite qui prcise les objectifs

atteints les ceux qui doivent encore tre atteints, simplement prciser l'tat

d'avancement du logiciel.

Beta

Une itration est identifie comme la bta, cette itration permet de tester auprs

des utilisateurs l'absence de dfauts majeurs du logiciel, tant dans son interface que

dans le droulement des cas d'utilisation. Le logiciel n'est pas complet et il faut que

la documentation d'accompagnement le prcise bien :). La bta doit expliciter tout

ce qui sera fait dans le logiciel.

Permet de tester petite chelle les problmes de dploiement, la documentation

utilisateur, La robustesse du logiciel, d'identifier des dfauts de fonctionnement

(bugs).

Livrable 5 de nombreux interlocuteurs : utilisateurs, maitre d'ouvrage, testeurs. Les

retours permettent d'identifier des problmes fonctionnels et oprationnels.

Alpha

Version finie du logiciel. Cette version permet de tester de faon complte le bon

fonctionnement du logiciel. Si par miracle tout est parfait cette Alpha devient la

Finale. On valide sur une partie adquate (suffisamment de cas reprsentatifs) les

modalits de dploiement.

Finale

Livrable 6 : Mise en production.

** FQM (Fonctions Qualits mesures)

L'objectif de la recette du FQM est d'en vrifier l'exhaustivit et la compltude.

L'exhaustivit

Il faut s'assurer qu'aucune fonction ralis par le logiciel ne manque au FQM. Deux

types de fonctions celle qui sont ncessaire a l'objectif d'un acteur. Celle qui est

ncessaire au logiciel pour fonctionner (n'ignorer pas des fonctions comme "le

logiciel s'initialise").

La compltude

IL faut s'assurer que pour chaque fonction, les qualits importante on t lists et

que pour chaqu'une une mesure a t dfinie, indiquer quand la mesure est tricte

d'ou vient l'obligation d'une tel exigence (cahier des charges initial, estimation de

frquence/dbit du cas d'utilisation, simplification pour atteindre une autre mesure).