Analyse de risque
description
Transcript of Analyse de risque
1
Analyse de risque
07 /
03 /
2011
Risque date facteur Plan d’action
Problèmeslors du
développement des services
24/01/2011
1. Utilisation de nouveaux logiciels.2. Les membres de l’équipe n’ont pas de connaissances sur le développement des web services3. Les membres de l’équipe n’ont pas de connaissance sur le web sémantique et les standards qui vont avec (ex : RDF)4. Absence de connaissances sur les procédures de test des web services
1. Intervention des formateurs externes.2. Partage des connaissances acquises lors de la phase de recherche
08/02/2011
1. L’ensemble de l’équipe a encore des points flous par rapport aux technologies
utilisées.
1. Effectuer des recherches sur internet2. Consulter la javadoc de Weblab 3. Ne pas hésiter à poser des questions sur le forum de Weblab ou à contacter un des formateurs EADS.
15/02/2011
1. Des membres de l’équipe travaillent sur les versions suivantes et un binôme continue à corriger les bugs et les problèmes de déploiement des webservices
23/02/2011
1. Même plan
02/03/2011
1. Un tutorial est mis à disposition de toutes les équipes pour partager les connaissances sur la génération du war.
2
07 /
03 /
2011
Groupe Vert
Risque date facteur Plan d’action
Retard dans les livraisons
24/01/2011
1. Mauvaise synchronisation entre les développeurs. 2. Prévisions trop optimistes. 3. Un des développeurs est indisponible pour une longue durée. 4. Excès de confiance..
1. Respecter le planning de développement et avertir en cas de difficultés.2. Baliser le processus de développement à l’aide de jalons.3. Travailler en binôme. 4. Faire des stands up meeting 2 fois par jour.
08/02/2011 1. Même plan d’action2. Envoi de mail quotidien à la chef d’equipe 3.un fichier de versionning pour chaque service.
15/02/2011 1. Même plan d’action
23/02/2011 1. Même plan d’action
02/03/2011
1. Retard dans les tests SOAPUI causé par le réseau et la connexion internet peu fiables
1. Continuer à faire des tests en local en cas de panne de réseau ou d’internet.
3
07 /
03 /
2011
Groupe Vert
Risque date Facteur Plan d’action
Tâche de travail
supplémentaire
24/01/2011 1. L'avancement dans le projet met en évidence des tâches inévitables non prises en comptes jusqu'à l’heure pour la bonne réalisation des modules2. Le client ajoute du contenu supplémentaire
1. Respecter le planning pour garder une marge de sécurité en temps pour le travail supplémentaire. 2. Évaluer le travail supplémentaire et donner une réponse positive ou négative sur la faisabilité de ce travail.
08/02/2011
Même facteurs de risqueArchitecture changeante
1. Même plan d’action2. Dès qu’un problème technique apparait, en parler directement à l’architecte qui devra le partager avec le responsable des architectes
15/02/2011Même facteurs de risques Développement des services clients pour tester les web services
1. Même plan d’action 2. Contact quotidien avec les formateurs EADS et réorganisation du travail :- un binôme travail sur le développement des services clients- un binôme travail sur la 2eme version.
23/02/2011Architecture changeante
- Un binôme travaille sur la version 3-Un binôme change l’architecture des web service pour correspondre au modèle weblab
02/03/20111. Besoin d'intégrateur par l'équipe de la MOE et mobilisation d'au moins un membre de l'équipe
Négocier avec la MOE pour avoir du temps supplémentaire sur le travail demandé (livraison des documents)
4
07 /
03 /
2011
Groupe Vert
Risque date Facteur Plan d’action
Incohérence entre les
web service
08/02/2011
1. Le développement des web services ne suit pas l’ordre de la chaine de traitement
1. Définir clairement les tâches effectuées dans chaque service (surtout au niveau des annotations RDF)
15/02/2011
23/02/2011
02/03/2011
5
07 /
03 /
2011
Groupe Vert
Risque date Facteur Plan d’action
Problèmes lors de la communication des web services
23/02/2011
1. Changement d’architecture.1. Les tests SOAPUI ne suffisaient pas pour détecter les problèmes du WSDL puisque le logiciel allait chercher les données en local
Finir les Web services en avance et se consacrer à la correction des bugsSe faire aider avec les intervenants pour générer un bon WSDL dès le début
02/03/2011
Problème de réseau Ingérable
6
07 /
03 /
2011
Groupe Vert
Risque date Facteur Plan d’action
Anomalies restantes sur le
logiciel final02/03/2011
L'intégration pouvant générer de nouvelles anomalies, intervient trop tard dans la phase du projet.
1. Corriger les bugs au fur et à mesure qu’on test pour ne laisser que des bugs mineurs et les
signaler à la MOE/MOA.