Les « Incontournables » d’un Projet (informatique)

Slides:



Advertisements
Présentations similaires
PROJET USINE A VELOS © BERNARD L KONGS 0105.
Advertisements

LA QUALITE LOGICIELLE Plan du cours La modélisation d’activité 1 h ½
CYNOSURE Assistance à la conception du site internet et de la mise en place d’un outil CRM externalisé Proposition d’assistance à maîtrise d’ouvrage Le.
Analyse et Programmation Orientées Objets
Faculté des Sciences de la Santé
Eléments de Génie Logiciel
CONDUIRE une REUNION.
M1 MASTER GESTION Séance 3 Pilotage coûts- délais
Processus d'expression du besoin
La Gestion de la Configuration
des Structures de Santé
Module 4- Caractéristiques générales de l'évaluation
Manuel Qualité, Structure et Contenus – optionnel
EXAMEN ET GESTION DE PROJET INDUSTRIEL
LA QUALITE LOGICIELLE Plan du cours Le Plan Qualité 1 h ½
D3 : Maîtrise d’ouvrage des Systèmes d’Information
Finalités et objectif de la sous-épreuve
La politique de Sécurité
Démarche de Projet D’après la norme X50-106, un projet est une démarche spécifique qui permet de structurer méthodiquement et progressivement une réalité.
l'approche ergonomique
TD 1 ? Quels sont les avantages relatifs à la définition d’une politique de sécurité pour une organisation ? Avantage : traiter la problématique de la.
Soutenance du rapport de stage
Les Ateliers de Génie Logiciel
S.T.S. S.I.O. 1ère année La gestion de projets
La revue de projet.
La démarche pédagogique du MF1
1 5 octobre 2011 / paw Présentation du 7 octobre 2011.
PARTIE 3 : Le SYSTEME D’INFORMATION FUTUR
MIAGE MASTER 1 Cours de gestion de projet
le profil UML en temps réel MARTE
Vuibert Systèmes dinformation et management des organisations 6 e édition R. Reix – B. Fallery – M. Kalika – F. Rowe Chapitre 1 : La notion de système.
Parcours de formation SIN-7
Chapitre 2 Définition du besoin et description du besoin.
Focus : Le cahier de Charges Fonctionnel
1 Conduite du changement LA CONDUITE DU CHANGEMENT.
Développement Humanisation et Patrimoine
Présentation du projet technique / sous-épreuve U62
Des indicateurs de performance pertinents et adéquats
Ecaterina Giacomini Pacurar
Conception des Réalisé par : Nassim TIGUENITINE.
SEMINAIRE DE CONTACT novembre 2008 Outils de gestion de projet.
Projet de Master première année 2007 / 2008
Eurométhode: méthode de gestion de la relation client-fournisseur
La Gestion de Projet.
Ingénierie Système en SysML appliquée à la rédaction du cahier des charges Y. Le Gallou Séminaire académique STI2D - Calais – 1er avril 2014.
Partie A Système d ’information et organisation
ECOLE DES HAUTES ETUDES COMMERCIALES
La technologie en 3ème avec Rob’OK Au collège République Bobigny
Le management de l'IVVQ Processus techniques IVVQ
Supports de formation au SQ Unifié
Réalisé par : Mr IRZIM Hédi Mr JRAD Firas
LE PLAN QUALITE Utilité du plan qualité :
Définitions Gestion Exemple
2003 (revisé 2008)SEG Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes.
Le système informatique et le système d’information
Introduction au Génie Logiciel
Réalisé par: BOUMSISS Hassnae OUED Zahra TABIT Youssef EZZIANI Hamza
Extrait du Referentiel BTS Systèmes numériques Options : Informatique et réseaux et Électronique et communication S1 à S9 Définition des savoirs et savoir-faire.
Management de la qualité
Sites Pilotes Généralisation
TD 1 ? Quels sont les avantages relatifs à la définition d’une politique de sécurité pour une organisation ? Avantage : traiter la problématique de la.
La posture de départ Etre vigilant et poser des bonnes questions
Travaux sur « études de cas » Saintes, le 20 juin ème journée académique.
La Méthode de Résolution de Problème
Conférence 2TUP Stéphane Barthon 03/12/
Emmanuelle Lorenzi, Maître de conférences –
Document de spécification d’exigences Normes IEEE et 29148:2011
Présentation de la méthode Merise
ISO 9001:2000 Interprétation Article 7 Réalisation du produit
4 1 : A quoi sert la gestion de projet
Transcription de la présentation:

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

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 »

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

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

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.

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 »

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

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

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

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

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 »

« 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é)

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

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

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 :rigaud@irit.fr 05 61 55 83 43 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

Expression des Besoins Métier

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

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

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

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

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

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 …

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

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.

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

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

Spécification Technique (du Système)

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)

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

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

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

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 ?

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

Validation (du Système)

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

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

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

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

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