GUI Modeler -
SNIper
Liste des Risques
Version 1.3
Historique des révisions
Date |
Version |
Description |
Auteur |
19/10/2001 |
1.0 |
Création |
ISI3_BE1 |
13/11/2001 |
1.1 |
Réévaluation des
risques existants et prise en compte de nouveaux risques |
ISI3_BE1 |
16/01/2002 |
1.2 |
-
Nouveaux risques
R7 et R8 -
Prise en compte
des risques écartés |
ISI3_BE1 |
19/02/2002 |
1.3 |
Réévaluation des
risques – en fonction du temps restant et du travail effectué jusqu’à présent
et des problèmes non résolus |
ISI3_BE1 |
Sommaire
1. Introduction 4
1.1 Objectif 4
1.2 Portée 4
1.3 Références 4
2. Risques 4
2.1 Remarques sur les risques : 6
Liste des risques
L’objectif de ce document est d’identifier et de classer les risques
pouvant intervenir sur le projet.
Ce document s’adresse aux analystes, au chef de projet et aux superviseurs
du projet.
Document Vision v1.1 – ISI3_BE1
Spécifications Supplémentaires v1.1 – ISI3_BE1
La magnitude d’un risque concerne l’importance de l’impact et non la
probabilité qu’il arrive.
Echelle de risque :
·
1 : négligeable
= aucun impact sur le projet ou le processus de développement
·
2 : marginal =
l’impact est significatif mais n’empêche pas le déroulement du projet
·
3 : important =
le risque ne peut être ignoré et doit être écarté au plus vite
·
4 : critique =
le projet a de fortes chances d’échouer si le risque n’est pas absolument
écarté en priorité
Magnitude du Risque |
Proba. |
Identifiant du risque ou numéro |
Description |
Impacts |
Indicateurs |
Stratégie de Réduction du risque |
3 |
forte |
R1 : Performances de l’application |
Mauvaises performances du logiciel sur les machines de l’Université due à
la technologie Java |
Problème de lenteur et utilisation très difficile voire impossible du
logiciel : l’application ne sera pas utilisée |
Test de performances sur les machines de l’UPS (celles du CICT, comme
celles du CRIE) |
Quoiqu’il arrive, SNIper sera utilisable sous Windows, et inutilisable
sur le serveur Tgv. Dès lors, les prochaines versions de SNIper (IT2 et IT3)
seront testées sur les machines Unix du CICT (Salines, Telline ou Ondine). |
|
écarté |
R2 : Manque de Connaissances Générales en Java |
Manque de connaissances techniques de l’équipe développement en Java |
Difficultés et retards dans la phase de codage, voire impossibilité
d’implémenter certaines fonctionnalités |
L’équipe de développement pense ne pas avoir assez de connaissances |
Ce risque a été écarté |
|
écarté |
R3 : Mauvais format pour les fichiers de diagramme |
Le format « interne » choisi pour représenter les diagrammes
n’est pas adapté et n’est pas utilisable par les prochains modules (l’éditeur
de SEF et le visualiseur d’Interface) |
Repenser la conception en amont, c’est à dire l’architecture de l’éditeur
SNI |
|
Ce risque a été écarté |
|
écarté |
R4 : Compréhension de la méthode SNI/SEF |
Mauvaise compréhension de la méthode SNI/SEF |
Erreurs de conception, erreurs d’IHM, mauvaise ergonomie |
|
Ce risque a été écarté |
3 |
très forte |
R5 : Dépassement des charges |
Ralentissements ou problèmes rencontrés dans certaines phases, ou
problème de réservation de ressources matérielles et logicielles |
Retard à la livraison, et déficit dans les autres modules de
l’enseignement de l’IUP |
Les dates clé ne peuvent pas être respectées, Le projet se fait sur le temps alloué aux autres modules de
l’enseignement de l’IUP |
Réévaluation des objectifs de des itérations IT2 et IT3(deux itérations
de la phase de construction) : l’IT2 a pris beaucoup plus de temps que prévu
pour moins de résultats que prévus. Essayer d’évaluer ce qui pourra être fait dans les semaines restantes et
modifier les objectifs en fonction (cf R6) |
4 |
faible |
R6 : Echec du projet |
Dépassement trop important des délais |
Pas de livraison et échec du projet |
Non-respect des plannings |
- Revoir les objectifs à la baisse pour l’IT2 (ne pas trop tarder à faire
la revue), et de l’IT3 pour ne pas repousser la date de remise de la version
finale - livrer une partie incomplète mais fonctionnelle du projet plutôt que
d’essayer de livrer un produit fini à tout prix |
4 |
forte |
R7 : Manque de connaissances techniques spécifiques => Problème de l’impression papier des diagrammes SNI |
Manque d’expertise sur la gestion de l’impression sous Java, rendant les
sorties papier inexploitables voire impossibles. |
Le logiciel risque de ne sera pas utilisé |
|
Que ce soit durant l’IT1 ou l’IT2, aucune solution acceptable n’a été
trouvée au problème de l’impression, malgré la consultation de documentation. Il faut écarter ce risque très rapidement lors de l’IT3, en prospectant
sur les forums spécialisés, et en pratiquant des tests. |
2 |
moyenne |
R8 : Mauvaise réutilisabilité du code |
Le code du prototype a été écrit de façon à être générique : ainsi
l’ajout de nouveaux éléments ne nécessite pas en théorie de toucher à
l’existant. Mais il pourrait en être différent dans la pratique … |
Perte de temps et surcharge de travail |
|
Dès qu’un nouveau type d’UD est prêt à être intégré à l’application, il
faut procéder à des tests avec le code existant |
le manque éventuel de connaissances techniques de
l’équipe développement en Java a été comblé par l’enseignement dispensé par
l’IUP (cours de M. Sanchez).
afin de produire le format interne de fichier le
plus adapté au prochain module (l’éditeur de SEF et le visualiseur
d’Interface), SNIper génère des fichiers XML. Ces derniers, de par leur format
même, sont facilement exploitables par d’autres applications, et seront donc
utilisés par le futur éditeur de diagramme SEF.
afin de permettre une meilleure réutilisabilité du code, celui-ci a été développé en suivant un guide de codage, ce qui assure une homogénéité des différentes classes. De plus, un effort a été produit, afin de rendre les classes ayant un impact fort sur l’architecture les plus génériques possible. Cela a été possible grâce à un certain nombre de techniques propres à Java (interface, classes abstraites, tableaux d’objet en paramètre, introspection …).