Etapes D'un Développement Logiciel

Etapes d'un dveloppement logiciel
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".
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
franais Les objectifs du Projet NetBSD.
Premire recette : Valider le lancement du dveloppement, pour cella le
responsable doit valider un certains nombre d'lments, voire l'inception ou la
description des validations et des documents permettant cette validation est dcrit
plus en dtails.
Inception :
Validation du cahier des charges initial

1.
2.
3.
4.
5.
Validation Marketing
Validation opportunit
Validation de faisabilit
Validation d'expertise
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 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 tres intgrs dans le cahier des
charges fonctionnel:
1. Une description du logiciel

2. La listes des Acteurs et la description 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)
Recette : 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
FQM :
Fonctions Qualits mesures
L'objectif de la recette du FQM est d'en vrifier l'exaustivit et la completude.
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 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 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/debit du cas d'utilisation, simplification pour atteindre une autre mesure).
Etablir une Interface Utilisateur Initiale

Cration des diffrentes fentres utilisateurs. Description des modes d'interaction
(en conjonction avec les cas d'utilisation).
Recette : 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
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 reliser une partie des objectifs
Librairies
Design patterns mise en uvre
Difficults techniques identifies
Recette : Faite par un architect logiciel
l'objectif est de mesurer la crdibilit de la faisabilit
La recette fourni une hrarchisation des cas d'utilisation, et une distribution des cas
d'utilisation sur plusieurs itrations
Construction
Pour le groupe de cas d'utilisation affects a l'itration courrante, il faut :
Ecrire le test du cas d'utilisation (forme interactive et forme "bas niveau")
Dsiner les diagrammes de sequence et crer l'interface des classes utiliss
Homogniser les classes
Pour chaque classe crire la documentation technique
Puis pour chaque classe ecrire le test unitaire de la classe
Ecrire les classes (mthodes )
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
dveloppeur, il doivent donc uniquement dtecter les dfaut 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 ateints
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 au prs
des utilisateur l'absence de dfauts mageurs 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'acompagnement le prcise bien :). La bta doit expliciter tout ce
qui sera fait dans le logiciel.
Permet de tester a petite chelle les problmes de dployement, la documentation
utilisateur, La robustesse du logiciel, d'identifier des dfaut de fonctionnement
(bugs).
Recette de nombreux interlocuteurs : utilisateurs, maitre d'ouvrage, testeurs. Les
retours permette d'identifier des problemes fonctionel et oprationels.
Alpha
Version finie du logiciel. Cette version permet de tester de faon complete le bon
fonctionement du logiciel. Si par miracle tout est parfait cette Alpha devient la
Finale. On valide sur une partie adquate (suffisement de cas reprsentatifs) les
modalits de dployement.
Finale
Ouf !
Recette : Faite par un chque

Etapes D'un Développement Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Etapes D'un Développement Logiciel

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Etapes D'un Développement Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Etapes d'un dveloppement logiciel

Etablir un cahier des charges Initial

Validation du cahier des charges initial

Etablir un cahier des charges Fonctionnel

1. Une description du logiciel

Etablir une Interface Utilisateur Initiale

Etablir un cahier des charges Technique

Vous aimerez peut-être aussi