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

1. Introduction

1.1 Objectif

L’objectif de ce document est d’identifier et de classer les risques pouvant intervenir sur le projet.

1.2 Portée

Ce document s’adresse aux analystes, au chef de projet et aux superviseurs du projet.

1.3 Références

Document Vision v1.1 – ISI3_BE1

Spécifications Supplémentaires v1.1 – ISI3_BE1

2. Risques

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

2.1 Remarques sur les risques :

R1 : des tests ont été effectués sur les différents environnements de l’IUP ( TX, poste Window …). Les résultats s’avèrent acceptables sur les machines du CICT, vu les temps de réponse relativement courts. Par contre SNIper est inutilisable sur machine Tgv.

R2 : écarté

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).

R3 : écarté

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.

R8 : écarté

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 …).