bernard cherbonneau / m1 master informatique / module ter 2008 les incontournables dun projet...

Bernard Cherbonneau / M1 Master Informatique / Module TER 2008 Les incontournables d’un projet industriel 1 / 39

Les « Incontournables » d’un Projet (informatique)

« industriel »


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 »

Buts du chapitre


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


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 lecadre 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 »


Du Besoin

Au Produit (utile, utilisable et utilisé)

…Via une démarche appropriée

Maîtriser le passage « en douceur »

« Challenge » d’un Projet informatique


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

– Projet = produit + processus – Incontournables d’un projet– EBM / ST / Validation– Cycles de vie– Qualité + Plan qualité (TD)– Tests (H Massie)

Sujets– Jean Marie Rigaud :[email protected] 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 desBesoins Métier


Les Exigences des UtilisateursElles 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


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)

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

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


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

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

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

bernard cherbonneau / m1 master informatique / module ter 2008 les incontournables dun projet...

Documents