DSI Démarche projet NTIC.

Présentation au sujet: "DSI Démarche projet NTIC."— Transcription de la présentation:

1 DSI Démarche projet NTIC

2 Définition d’un Projet
Ensemble de tâches et activités devant être menées par différents acteurs appartenant au groupement des mousquetaires en vue d’atteindre les objectifs désignés dans le cadre des besoins exprimés.

3 Un projet avec cycle de vie en cascade
Que se passe-t-il lorsqu’on découvre à ce stade des changements par rapport aux exigences ? 2 mois Now is the time for men in the ranks to stay in the ranks. 1 mois Et à ce stade ? 4 mois Et à celui-ci ? Recueillir les exigences Analyser 12 mois 2 mois Concevoir Cycle en cascade type : Définir la plupart des exigences Concevoir l’architecture de base Concevoir les parties essentielles du système (c’est-à-dire : les diagrammes et documents décrivant la conception) Modéliser avec soin la couche du domaine, jusqu’à ce que le développement soit satisfaisant et robuste Procéder à l’implémentation à partir de la conception Effectuer l’intégration, les tests et le contrôle qualité Coder Pour mieux comprendre les éventuels désagréments causés par ce type de conduite de projet, lire le scénario de construction d’un pavillon. Intégrer, tester & effectuer le contrôle qualité

4 Difficultés liées au cycle de vie en cascade
Suppose que l’on puisse définir toutes les exigences, ou au moins la plupart, dès le début. Les fonctionnalités (exigences) doivent être clarifiées avant de débuter la conception ou l’implémentation. Refuse tout changement pour «tout bien faire dès le début». La formalisation exacte des exigences doit précéder la conception, qui doit elle-même être finalisée avant de passer à l’implémentation. Retarde la résolution des facteurs de risque. Par exemple, intégration tardive dans le cycle de vie Entraîne des relations conflictuelles avec les parties prenantes en raison : Du manque de clarté de la définition des exigences. D’engagements importants dans un contexte de profonde incertitude. D’un désir inévitable de procéder à des changements.

5 Le processus « idéal » pour le développement de logiciel
Il doit permettre de : Bien comprendre les demandes des utilisateurs finaux. Tenir compte des changements du cahier des charges. Empêcher la découverte tardive de défauts sérieux dans le projet. Traiter au plus tôt tous les points critiques du projet. Bien communiquer avec le client. Bien maîtriser la complexité. Favoriser la réutilisation. Définir une architecture robuste. Faciliter le travail en équipe. ...

6 Activités du processus (UP)
Criblage Organisation selon le temps Aspect statique Principaux enchaînements du processus V1 Inception Élaboration Construction Transition Modélisation métier Gestion des exigences Analyse et conception Organisation selon le contenu Implémentation Tests Déploiement Principaux enchaînements de soutien Gestion de la config. & des changements Direction de projet Environnement Itération(s) Itér. #1 Itér. #2 Itér. n Itér. n+1 Itér. n+2 Itér. m Aspect dynamique Répartition typique de l’effort 10% 30% 50% 10% Processus à 2 dimensions

7 Qu'est-ce qu’un processus itératif ?
C’est planifier et gérer. C’est prévoir. C’est adapter les modifications des besoins en douceur. C’est piloté par le risque. C’est basé sur des prototypes évolutifs qui fonctionnent, pas de la documentation. Ça implique le client et l’utilisateur pendant tout le processus.

8 La réduction du risque pilote les itérations
Risques Projet Initiaux Portée Initiale du Projet Réviser Plan Global Projet Coût Planning Portée/Contenu Planifier Itération N Fixer Itération N Risques Éliminés Réviser Risques Projet Réordonner Priorités Développer Itération N Collecter coût et métriques de qualité Définition de scénarios Risques supérieurs Itération N Chaque itération a pour résultat une version exécutable Itératif …

9 3 caractéristiques importantes de l’approche itérative
Attaque du risque avec une progression quantifiable. La progression est mesurée sur le produit, pas sur de la documentation ou sur des estimations. Intégration continuelle. Pas testée en une seule fois la veille de rendre le projet ! Publications fréquentes d’exécutables. Certains en interne, certains fournis au client. Itératif …

10 Exemple d’une itération : Mobilité ALIZÉ
Phase 1 Répartition du travail par ressources Analyse : 1 ressource pour le module service PDA. Développement : 1 ressource pour l’IHM du PDA. Chef de projet : 1 ressource pour le planning et la coordination. Tâches identifiées : Définition des services et méthodes, ex : chargement du cadencier dans le PDA. Activation du scan PDA. Cryptage du mot de passe. Phase 2 Définition des exigences PDA en mode déconnecté. Reconnaissance du PDA en HTTPS. Temps de chargement du cadencier. Recherche de l’algorithme de cryptage . Phase 3 Analyse et conception des tâches Définition du processus Chargement cadencier. Choix de la méthode de cryptage. Choix de l’API fournisseur pour le scan du PDA. Début de l’implémentation Définition des cas d’utilisation et des scénarios de montée en charge. Phase 4 Implémentation avec tests et intégration dans l’application TIGRe et l’environnement étude : Chargement cadencier : implémentation de la partie PDA et des flux d’E/S avec l’application TIGRe. Cryptage du mot de passe : implémentation du module de selon l’algorithme choisi. Scan PDA : implémentation du module d’activation. Phase 5 Implémentation Préparation et démo de l’application Mobilité Alizé  Identifier les améliorations et les nouvelles tâches pour l’itération suivante Planifier l’itération suivante Mise à jour du planning projet Si une démonstration doit avoir lieu, elle est programmée le Vendredi (sem 2). Phase 6 Réévalution, par l’équipe, des tests à effectuer. Bilan de la Démo : prise en compte des remarques et des nouvelles exigences ex : demande de la DO Amont de tester en environnement production la montée en charge avec LoadRunner Itératif …

11 Bénéfices d’un processus itératif
La publication de versions intermédiaires force l’équipe de développement à finir quelque chose à intervalles réguliers. On ne peut pas tomber dans le piège du “fini à 90% avec 90% restant à faire”. Les problèmes et les modifications peuvent être traités dans des itérations futures, plutôt que de devoir casser la production en cours. Les acteurs qui supportent le projet (testeurs, support hotline, …) peuvent organiser leur travail de manière plus efficace  intervention plus en amont Itératif …

12 10 bonnes pratiques 10 bonnes pratiques permettent de définir un plan projet efficace et cohérent : Vision Risques Cas d’utilisation métier (use cases) Résultats (livrables) Estimation (R.O.I.) Architecture Produit Evaluation Gestion des changements Support utilisateur

13 1. Faire partager la vision du projet
La vision, c’est communiquer à travers une analyse pertinente de la problématique du projet et de la compréhension des besoins utilisateurs, la définition du système et la gestion des exigences surtout quand elles changent. La vision du projet doit permettre de répondre aux questions suivantes : Quels sont les termes clés ? Quel problème essayons-nous de résoudre ? Qui sont les sponsors ? Qui sont les utilisateurs ? Quels sont leurs besoins ? Quelles sont les caractéristiques du produit ? Quelles sont les exigences fonctionnelles (cas d’utilisation) ? Quelles sont les exigences non fonctionnelles ? Quelles sont les contraintes de conception ?

14 2. Identifier et réduire les risques
Manager un projet par les risques, dès sa phase de lancement, permet : D’identifier les risques perçus comme frein ou non succès du projet. De les classer par ordre de priorité afin de bien identifier ceux qui auront un impact négatif pour le bon avancement du projet, De rassembler l’ensemble des acteurs sur l’anticipation nécessaire à chaque phase du projet. De mieux définir les itérations nécessaires pour réduire les risques majeurs. De mettre en œuvre des solutions de tout ordre pour résoudre les risques les plus forts dès le début du projet.

15 3. Identifier les livrables et les jalons
Cette étape, somme toute classique, est nécessaire dès l’étude de cadrage pour : Clarifier la communication avec des données objectives en terme de résultats attendus pour quelles échéances. Lotir intelligemment le projet pour produire des résultats (tous les livrables ne sont pas forcément des exécutables) régulièrement. Identifier clairement les responsabilités à chaque phase du projet. Définir une enveloppe budgétaire.

16 4. Définir les principaux cas d’utilisation
Cette étape se doit d’être brève afin que tous les acteurs la comprennent et la partagent. Il s’agit de : Synthétiser les process métiers mis en œuvre pour décider si le projet est viable en terme d’investissement. Ces principaux cas d’utilisation devront être réexaminés à chaque fin de phase projet afin de vérifier que le retour sur investissement est toujours prouvé, et que donc le projet peut continuer. Il s’agit aussi à travers les cas d’utilisation d’identifier les principaux composants applicatifs.

17 5. Identifier le ROI du projet
Cette étape marque la fin de la phase d’inception. Tous les éléments du dossier de criblage doivent être à ce stade complets. Le dossier doit ensuite obtenir la validation budgétaire en comité de gouvernance projets. Les étapes suivantes ne sont bien entendu déclinées que si le projet a obtenu le feu vert de démarrage.

18 6. Concevoir une architecture à base de composants
Base des enchaînements d’activités d’analyse et de conception : bonne pratique qui consiste à définir et affiner les architectures candidates et concevoir les composants systèmes. Identification et conception des composants essentiels, définition de leurs interfaces, couplage entre composants. Ces éléments peuvent être référencés dans un document d’architecture logicielle qui servira de lien entre le(s) architecte(s) et les autres participants au projet permettant d’apporter une aide à la décision.

19 7. Construire et tester l’application de façon itérative et incrémentale
Base des enchaînements d’activités d’implémentation et de test consistant à coder, construire, tester et intégrer les composants systèmes de façon itérative et incrémentale. Bonne pratique caractérisée par l’élaboration d’un prototype architectural et d’un prototype applicatif suivant les besoins. Dans les itérations suivantes, les composants seront intégrés et testés sous forme de livrables qui évolueront progressivement vers l’application finale.

20 8. Evaluer régulièrement les itérations et livrables
L’évaluation des livrables, et plus spécifiquement des itérations, permet de valider si les critères définis lors de l’itération précédente étaient les bons. Elle permet de tirer des enseignements et de définir les « à changer » ou « à faire évoluer » dans le but d’améliorer la prochaine itération. L’artefact d’évaluation d’itération ou livrable sera un simple document ou un ensemble de documents et de revues de tests suivant la taille du projet et le niveau d’importance de l’itération

21 9. Gérer et contrôler les changements
Base des activités de configuration et gestion du changement qui consistent à maintenir l’objectif du projet tout en gérant et contrôlant les changements et en garantissant et étendant (si besoin) les exigences utilisateurs. La gestion des demandes de changement permet d’historiser et référencer les décisions, ce qui permet à l’ensemble des participants du projet d’appréhender, voire comprendre, les éventuels changements.

22 10. Fournir une assistance à l’utilisateur
Base de l’enchaînement d’activité de déploiement qui consiste à préparer et livrer non seulement l’application finale mais aussi tous les artefacts et éléments permettant à l’utilisateur d’apprendre, utiliser et maintenir le produit. Au minimum une documentation utilisateur sera fournie, mais suivant l’importance et la complexité du produit il y aura peut être une aide en ligne complémentaire, un guide d’installation, un fichier lisezmoi.txt, etc