C. 1 capture des exigences
UP propose d'appréhender l'expression des besoins en se
fondant sur une bonne compréhension du domaine concerné pour le
système à développer et une modélisation des
procédures du système existant. Ainsi, UP distingue deux types de
besoins :
· les besoins fonctionnels qui conduisent à
l'élaboration des cas d'utilisation,
· les besoins non fonctionnels (techniques) qui aboutissent
à la rédaction d'une matrice des exigences.
16 P. Rocques & F. Vallée, UML 2 en action, de
l'analyse des besoins à la conception, éd. EYROLLES, 2007,
p40
11
C. 2. L'analyse et La conception
a. L'analyse
L'analyse correspondant à la phase qui répond
à la question « que fait le système », l'analyse est
l'une des étapes les plus importantes et les plus difficiles de la
modélisation. Elle permet de modéliser le domaine d'application,
d'analyser l'existant et les contraintes de réalisation. Elle s'effectue
par une abstraction et une séparation des problèmes. Elle peut
être découpée en trois phases que sont :
? La définition des besoins
? La capture des besoins
? La spécification des besoins
b. La conception
La conception met en oeuvre tout un ensemble
d'activités qui à partir d'une demande d'informatisation d'un
processus permettent la conception, l'écriture et la mise au point d'un
produit informatique (et donc de programmes informatiques) jusqu'à sa
livraison au demandeur. Elle a comme objectifs de répondre à la
question « comment faire le système ?» et de décomposer
de façon modulaire le système à mettre en place. La
conception définit l'architecture du logiciel. Elle définit par
la même occasion chaque constituant du logiciel (Informations
traitées, traitements effectués, résultats fournis,
contraintes à respecter. A la suite un modèle logique utilisable
à la phase d'implémentation est produit.17
C. 3. L'implémentation
Cette phase consiste à la mise en oeuvre des programmes
dans un langage de programmation conformément aux spécifications
définies dans les phases précédentes. Elle renferme en son
sein les phases de test et de mise au point (débogage). A la sortie il
sera produit un modèle physique (collection de modules
implémentés mais non testés, documentation de
programmation expliquant le code).
C. 4. Test
Les tests permettent de vérifier :
· la bonne implémentation de toutes les exigences
(fonctionnelles et techniques),
· le fonctionnement correct des interactions entre les
objets,
· la bonne intégration de tous les composants dans
le logiciel.
17 P. Rocques & F. Vallée, UML 2 en action, de
l'analyse des besoins à la conception, éd. EYROLLES, 2007
12
Classiquement, différents niveaux de tests sont
réalisés dans cette activité : test unitaire, test
d'intégration, test de réception, test de performance et test de
non-régression.
| 
