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

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 :

 

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