Les « Incontournables » d’un Projet (informatique)

Présentation au sujet: "Les « Incontournables » d’un Projet (informatique)"— Transcription de la présentation:

1 Les « Incontournables » d’un Projet (informatique)
« industriel »

2 Buts du chapitre Mettre en évidence la problématique des projets en général, et celle des projets informatiques en particulier Présenter les différents acteurs Présenter les points « incontournables » d’une démarche « industrielle »

3 Qu’est ce qu’un programme (informatique)?

4 Que pensez vous faire comme activité bientôt et + tard ?
Écrire de nouveaux programmes ?

5 Qu’est ce qu’un Projet ? Du temps passé… De l’argent dépensé…
Une équipe… Un cahier des charges… Des ressources, des moyens… Un planning… Un logiciel… Un site web… Des documents… Des utilisateurs… Des exploitants… Un client… Un objectif… Des sous-traitants, des appels d’offres et des contrats etc.

6 Proposition de structuration : un projet =
Un Produit personnes ressources logiciel / matériel Une Démarche personnes ressources logiciel / matériel De nombreuses facettes, de nombreux aspects l’échec d’un seul peut provoquer l’échec du projet il convient de les aborder avec une vue globale, dans le cadre d’une approche « système »

7 Le Produit En prenant comme exemple un produit « concret », davantage « palpable » qu’un produit logiciel, et récemment élaboré, acquis ou loué : téléphone portable moyen de locomotion notre amphi etc. Quel degré de satisfaction en avez-vous ? Quels problèmes avez-vous rencontrés ou rencontrez-vous ? Dans les deux cas, expliquez pourquoi

8 Les clefs d’un « bon » Produit
Exprimer de manière suffisamment « complète » et « compréhensible » ce que l’on en attend ( « le besoin » ) pour pouvoir définir les caractéristiques du produit correspondant (ou pour que quelqu’un puisse le faire) pour décider (ou faire prendre la décision) de le faire, de le faire faire, de l’acheter… ou d’en différer l’acquisition, d’en rejeter l’idée pour pouvoir valider la conformité du produit élaboré ou acquis lors de la réception (« recette ») après une utilisation « suffisante » Faire un bilan et en tirer les conséquences

9 La Démarche , le « Processus »
En prenant comme exemple une démarche faisant intervenir des éléments « concrets », davantage « palpables  », que ceux qui interviennent lors du développement, de l’acquisition d’un logiciel, et récemment suivie : trajet pour partir en vacances, pour aller à la fac location d’un appartement, acquisition d’un véhicule votre parcours universitaire l’apprentissage d’un sport (tennis, foot, golf…) Etc. Quel degré de satisfaction en avez-vous ? Quels problèmes avez-vous rencontrés ou rencontrez-vous ? Dans les deux cas, expliquez pourquoi

10 Les clefs d’une « bonne » Démarche
Définir de manière raisonnable, suffisamment « complète » et « compréhensible » les différentes étapes, le rôle des différents intervenants (= le plan) pour que chacun travaille « efficacement » (pas forcément « vite » !!!) pour que chacun sache exactement ce qu’il attend (peut, ou est en droit d’attendre) des autres pour avoir pendant le déroulement de la démarche et à tout moment le « bon niveau » de visibilité, afin de savoir à tout moment où l’on en est par rapport aux prévisions prendre (ou faire prendre) la « bonne décision » anticiper au mieux les situations néfastes (« maîtriser les risques ») Faire un bilan et en tirer les conséquences

11 Succès d’un Projet = Respect des Exigences
Succès du Produit : le produit final satisfait les besoins des utilisateurs (besoins réels) a le niveau de qualité requis est évolutif est réutilisable (tout ou partie) Succès de la Démarche : la démarche permet de terminer en respectant les délais en respectant le budget les participants sont satisfaits Dans le cadre d’une approche « tout le monde gagnant »

12 « Challenge » d’un Projet informatique
Maîtriser le passage « en douceur » Du Besoin …Via une démarche appropriée Au Produit (utile, utilisable et utilisé)

13 Les points clefs d’une démarche « industrielle »
Expression des besoins métier, « Cahier des Charges » Spécification Technique Réalisation / Acquisition (Location) Validation / Recette Revues de Projet, réunions avec le client

14 Les intervenants d’un projet
Le Maître d’Ouvrage (MOA), le « Client » Le Directeur de Projet, le Chef de Projet Système d’Information Le Maître d’Œuvre (MOE), le « Fournisseur » Le Chef de Projet Informatique L’équipe de Développement Les Utilisateurs Le Comité de Pilotage Les Exploitants

15 Rajout…. Plan du cours Sujets Projet = produit + processus
Incontournables d’un projet EBM / ST / Validation Cycles de vie Qualité + Plan qualité (TD) Tests (H Massie) Sujets Jean Marie Rigaud Réalisation d'un objet pédagogique visant à illustrer de manière  graphique le fonctionnement d’un moniteur de Hoare Conception et réalisation d'une plate-forme d'auto évaluation  déclarative générique sur internet Louis Watrin : info.ups.tlse.free.fr Bertrand Boisvert (minfg7) Mon sujet : rdv

16 Expression des Besoins Métier

17 Les Exigences des Utilisateurs
Elles sont de deux natures Besoin nécessité ou désir éprouvé par l’utilisateur dans le cadre de son métier, pour résoudre un problème ou atteindre un objectif peut être exprimé ou implicite Contrainte restriction de toute nature sur la manière de satisfaire les besoins

18 Les Besoins Ils décrivent ce que les utilisateurs cherchent à faire au travers du système L’expression d’un besoin définit une opération ou une suite d’opérations Exemple : indicateur d’itinéraire embarqué dans une automobile Les opérations doivent décrire l’ensemble du « processus métier » à informatiser S’il y a plus de 6 opérations, elles doivent être groupées, chaque groupe étant alors décliné ensuite séparément

19 Besoins de l’indicateur d’itinéraires
Connaître l’itinéraire pour aller à un endroit Connaître l’itinéraire le plus court Connaître l’itinéraire le plus rapide actuellement (compte tenu de la circulation courante) Connaître l’itinéraire le moins cher Connaître l’itinéraire passant par tel lieu (monument historique, restaurant, etc.) Etre guidé pour aller à un endroit

20 Besoin implicite de l’indicateur d’itinéraires
désigner l’endroit où l’on est !!!

21 Les Contraintes Elles doivent relever uniquement du métier. Par exemple capacité rapidité exactitude confidentialité durée de vie (porte avion Clémenceau lancé en 1957 / études démarrées en ?) etc. D’autres contraintes pourront en être dérivées (portabilité, adaptabilité, etc.) être déterminées à partir des caractéristiques de l’environnement (protocole de communication à utiliser, etc.) être des directives préconisées par l ’entreprise être des contraintes réglementaires (directives européennes, législation, etc.) Ces contraintes sont liées aux caractéristiques d’une solution ; elles doivent figurer dans le DST

22 Contraintes de l’indicateur d’itinéraires
Fournir des informations en temps réel Fournir des informations correspondant à l’état courant (nouvelles routes, routes coupées, accidents…) Ne pas gêner le conducteur (sécurité) Volume faible Coût …

23 Formulation des exigences
Les exigences formulées doivent être : précises (quantitatives plutôt que qualitatives) non ambiguës (nécessité de s’adapter au vocabulaire des utilisateurs : « miles », « carotte », « pinouille ») cohérentes non redondantes claires et compréhensibles (utilisateurs, Chef de Projet, Maître d’Ouvrage) vérifiables testables justifiées

24 Evaluation de l’opportunité
Le Directeur de Projet doit comprendre les exigences des utilisateurs, et s’assurer qu’elles sont pertinentes : problème réel de l’entreprise adéquates : pas d’inconvénient majeur du produit (charges ou coûts d’exploitation, organisation, procédures, etc.) Exemples de questions à poser aux utilisateurs : que vont-ils faire de ces données ? quand et comment vont-ils les exploiter ? toutes les données sont-elles vraiment nécessaires ? pourquoi veulent-ils faire tel recoupement ? à quoi va leur servir telle statistique ? etc. De telles questions peuvent permettre d’éliminer ou de différer des exigences à prendre en compte, de définir des priorités, d’ identifier des exigences plus pertinentes, etc.

25 Optimisation et classification
Les exigences doivent être analysées, en particulier selon un point de vue économique (aspects coûts / efficacité) Ne retenir que des exigences cohérentes avec les contraintes techniques et économiques. S’il y a lieu, négocier (Maître d’Ouvrage, utilisateurs) des compromis exigences / points durs / coûts / délais Pour aider à identifier la solution optimale, distinguer exigence principale : incontournable, essentielle exigence secondaire : service rendu facilité ou amélioré exigence qui peut être satisfaite ultérieurement

26 Eléments UML ? Diagramme de classe (objets métier)
Diagrammes d’activité (processus métier)

27 Spécification Technique
(du Système)

28 Spécification Technique
Objectif rechercher la solution la plus pertinente spécifier cette solution de façon à permettre la réalisation ou des propositions de réalisation (au forfait) affiner les estimations (constituer le ou les Dossiers d’Appel d’Offres) Pré-requis EBM validé Principales fournitures DST Plan de Gestion du Projet (Dossier (s) d’Appel d’Offres)

29 ST: sous-phase recherche d’une solution
Proposition, au comité de pilotage, de la solution fonctionnelle organisationnelle et technique la plus appropriée pour satisfaire les exigences (EBM), compte tenu des budgets et délais Activités à mener Rechercher et étudier une solution (plans technique, organisation, déroulement de projet) Evaluer une solution Comparer les solutions Faire valider

30 SS: sous-phase spécification de la solution
Compléter, détailler les travaux de la sous-phase précédente, de façon à permettre une estimation des coûts de réalisation Activités à mener Spécifier les interfaces externes (contexte) Modéliser les objets Spécifier les services attendus Quantifier Définir les dispositions qualité Tracer Evaluer la charge de développement Faire valider les modèles Rédiger le DST Vérifier le DST Faire valider (Lancer le ou les appels d’offres) Autre activité possible : spécifier les modalités de reprise de l’existant

31 Cas de l’indicateur d’itinéraire
Interfaces externes : dispositif de saisie (texte, pointage, voix…) de la destination moyen d’identification de la position courante connexion avec les services de surveillance de trafic, sécurité lecteur de cartes routières synthèse vocale (pour le guidage) etc. Services attendus (du système) Besoin « Connaître l’itinéraire le plus court pour aller à un endroit » Services : saisir destination identifier position courante calculer tous les itinéraires retenir le plus court afficher le plus court faire clignoter position courante

32 Différences Expression des Besoins Métier / Spécification du Système
Les concepts introduits dans l’EBM permettent de spécifier les exigences, au niveau de détail recherché : celui qui permet de définir la solution, donc les éléments du DST Point de vue l’EBM est réalisée avec le point de vue de l’utilisateur ce que veut faire l’utilisateur à l’aide du système le DST est réalisé avec le point de vue du système ce que propose le système pour répondre aux besoins de l’utilisateur = quoi ? avec quoi / sur quoi ? quand ?

33 Eléments UML ? Cas d’utilisation (textuel, graphique) aspects fonctionnels Diagrammes d’état, diagramme de séquence système, diagramme de séquence détaillé aspects dynamiques Glossaire, diagramme de classe détaillé (attributs, classes…) aspects informationnels

34 Validation (du Système)

35 Validation Objectifs Pré-requis Principale fourniture
vérifier que le produit est conforme aux exigences formulées dans le DST (pas dans l’EBM) Pré-requis Système et documents d’accompagnement livrés Plan et Dossier de Validation validés Principale fourniture compte rendu de validation Responsable réalisation Chef de Projet Principaux acteurs Chef de Projet, Directeur de Projet

36 Définitions Validation : analyse de la conformité d'un produit par référence à sa définition (spécification + demandes de modifications acceptées) et aux autres exigences applicables spécifiées (Plan d ’Assurance Qualité par exemple) Recette : acte contractuel par lequel un produit est reconnu conforme à sa spécification. La recette une fois prononcée, le produit change de propriétaire, et une période de garantie est ouverte, couvrant la correction des anomalies résiduelles (mais pas les évolutions, etc.)

37 Déroulement de la validation
Deux étapes préparation réalisation le Dossier de Validation (DDV) comprend deux parties Plan de Validation Document de Validation

38 Plan de Validation Contenu Date de production
activités à réaliser, périodes de déroulement des activités lieux : site, locaux moyens : postes de travail, périphériques, conditions de charge, etc. (si possible environnement d'exploitation ou similaire) responsabilités : qui élabore le dossier de validation, qui installe l'environnement, qui installe le produit, qui effectue les tests, qui fournit l'assistance, qui valide les résultats, qui prononce la validation principes et dispositions à appliquer (établissement et transmission des rapports de validation, procédure de résolution des anomalies, règles d'acceptation -classification des anomalies-, etc.) Date de production souhaitable : pendant la spécification technique (soumis à acceptation du Maître d ’Ouvrage) au plus tard : en fin de développement (toujours soumis à....)

39 Document de Validation
Contenu le programme de test : les différentes « campagnes » de tests et leur but la description des campagnes de test ; pour chacune situation de départ : contenu des fichiers, SGBD, etc. scénario : actions à réaliser (IHM) et ordonnancement résultat attendu : après chaque action ou à la fin du cycle les résultats des tests ; pour chaque session conditions de déroulement résultats obtenus compte rendu de validation : nombre d'anomalies, décision prise (acceptation sans réserve, avec réserves, refus) Date de production souhaitable : pendant la spécification technique (soumis à acceptation du Maître d ’Ouvrage) pour les parties programme et description des tests au plus tard : en fin de développement (toujours soumis à...)