Gestion de Projet Informatique Partie I : Introduction au cours et aux étapes de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise A good beginning makes a good ending 1 2 Sommaire Objectif du cours Objectif et organisation du cours : règle du jeu Modalité de contrôle de connaissances (MCC) Sujet du projet et membres de l équipe Les étapes d'un projet informatique Un pont vers le monde professionnel Simulation d'une expérience à l entreprise de 3 mois Gestion de projet encadrée Méthodologies pour gérer un projet informatique Clé de réussite : esprit d'équipe 3 4 Organisation du cours Conseils pour réalisation du travail PPAP = Présence, ponctualité, assiduité et participation Avancement du projet rythmique vous ne pouvez pas tout finir qu'à la fin Gardez les traces écrites (emails, documents, SVN, etc.) pour justifier la gestion du projet 5 Signalez les problèmes le plus tôt possible et prenez les responsabilités (voir les détails dans la section suivante) 6 1
Règles pour travail rendu Modalité de contrôle de connaissances Objet de votre email à l'enseignant tliu@u-cergy.fr NomEquipe Sujet Documents écrits en français Rapports, productions intermédiaires, slides Tous les programmes et Java Doc en anglais Tout ce qui est oral en français Note du module (2 parties) Note projet (CC) : 50% TD (productions liées à la gestion du projet) rendus Gestion/réalisation du projet : responsabilités assurées? Soutenance de projet Note examen : 50% Exercices sur les connaissances / compétences acquises en cours et TD Questions sur votre projet (questions ouvertes, réponses à justifier) 7 8 Modalité de contrôle de connaissances Sujet du projet Examen écrit Durée: 2 heures, tous documents autorisés sauf livres et appareils électroniques Exercices obligatoires Exercices à choisir Soutenance de projet 30 minutes par équipe dont 15 minutes de présentation avec slides 10 minutes de démonstration 5 minutes de questions/réponses 9 Base : Train Simulation Simulation de la ligne du RER A Horaires de trains prévus Incidents techniques retard / suppression Mécanisme du canton Affichage des horaires de trains en temps réel Extensions possibles Gestion de plusieurs branches sur la ligne Vue du train (info sur les arrêts, contrôle en tant que chauffeur) 10 Exigences techniques du projet Langage de programmation Java SE 6 ou plus Interface graphique : Java Swing ou de votre choix Gestion des accès aux cantons : Java multi-threading Tests de projet automatisés Junit Relations internes et externes Hiérarchie? (non, plutôt "collaboration") Equipe de projet CHEF Prof Lien direct Travail d'équipe SVN (programme + doc) Documentation Faites votre choix pour l'outil de rédaction pour l'équipe MOE Q.A. DOC Lien indirect 11 12 2
Chef de projet (CHEF) Maître d'œuvre (MOE) Profil / compétences Etre ouvert et social, expressions orales Vision globale, capacité de modélisation Etre sensible à la gestion du temps Une large connaissance sur les techniques (programmation, intégration, etc.) Responsabilités Orientation de l évolution du produit, initialisation de conception Présentation régulière (hebdomadaire) de l avancement de projet à l'enseignant (client) communications externes Gestion de l équipe, organisation des réunions communications internes En cas de problèmes, prendre la décision (après avoir discuté avec ses collègues) Profil / compétences Etre très bon en programmation, connaissances techniques approfondies S'adapter facilement aux nouvelles technologies Gestion globale du développement Etre capable de simplifier les problèmes complexes Convention de codage et esprit de programmation orientée objet Responsabilités Architecture et conception du logiciel, organisation du code source et de la structure du projet Aider aux autres membres de l'équipe à configurer leur environnement de travail, pour assurer le bon déroulement du développement Evaluation des compétences/efficacités de développement des membres de l'équipe décisions 13 14 Responsable d'assurance qualité (QA) Responsable de documentation (DOC) Profil / compétences Etre très rigoureux sur les tests effectués Etre très bon en outils de développement et de tests Etre bon en communication interne Responsabilités Assurer la qualité du produit fabriqué (du point de vue des utilisateurs et des développeurs) Couverture des fonctionnalités par rapport au cahier des charges Assurer les tests d'intégration, tests de performance ainsi que les tests fonctionnels Construction du plan de tests Mise à jour des tests avec l'avancement des tâches 15 Profil / compétences Etre très bon en rédaction Etre capable de bien structurer les documents Etre très bon en outils de rédaction (schéma, mise en pages, etc.) Responsabilités Responsable (mais pas toujours rédacteur) de tous les documents du projet Validation des documents écrits par d'autres collègues Mise en place de l'environnement de travail de rédaction pour toute l'équipe 16 Charges de travail (Dev + Doc) Attention Développement : projet en 2 parties Moteur de la simulation : MOE + QA Interface graphique : CHEF + DOC Documentation 70 % du travail doc est assuré par DOC 30 % par les autres membres Répartition de tâches de documentation proposée par DOC mais validée par l'enseignant (à traiter plus tard en cours) La partie suivante étant une partie d'introduction générale, à choisir / adapter dans votre projet du cours 17 18 3
Définitions des termes de base Les étapes générales d un projet Un projet informatique Un ensemble d activités prises en charges Dans un délai donné Dans les limites de ressources imparties Par des personnes y sont affectées Dans le but d atteindre des objectifs définis Une étape de projet Une thématique regroupant un ensemble d actions à entreprendre Répondre à un besoin défini dans les délais fixés L avant-projet Conception et réalisation Validation Recette et réception Livraison Bilan de fin de projet 19 20 L avant-projet L avant-projet Etudes d'opportunité Elaboration du cahier des charges Etude d opportunité Etudier la demande de projet: concept viable? Valider la demande des utilisateurs Périmètre du projet: contexte Utilisateurs finaux: qui utiliseront le produit? Etudes de faisabilité Conseils En raison d efficacité, associez les utilisateurs à la réflexion globale Réunion N hésitez pas trop sur les points faibles! 21 22 L avant-projet L avant-projet Etude de faisabilité 3 dimensions: économique, organisationnelle et technique Présentation des solutions Aspect fonctionnel, technique et impact Avantages et inconvénients de la solution Conditions de mise en œuvre: moyens humains et matériels, documentations, etc. Conseil Restez clair et synthétique, sans trop détailler! Cahier des charges : objectifs Garantir que les livrables seront conformes à ce qui est écrit Tout doit être défini dès le début? cas idéal mais pas réaliste! projet agile Un document de référence: un outil de dialogue modifiable en cours de projet 23 24 4
L avant-projet L avant-projet Cahier des charges : contenu général Présentation du projet Contexte du projet Objet : Brève définition Organisation : équipe de projet rôle de chacun Environnement : existants fonctionnels et techniques Objectif: description de la future solution Points clés sur les besoins fonctionnels Limites du projet: licences, budget, etc. Description détaillée de l ensemble des fonctionnalités attendues : scénarios d'utilisation Cahier des charges : contenu (suite) Livraison attendue (liste non exhaustive) Date à laquelle le projet devra impérativement être terminé Programmes code source Documents à remettre Base de données Conseil : Attention au vocabulaire!! Projets échoués manque de communication, de culture et de vocabulaire commun 25 26 Conception et réalisation Conception et réalisation Conception Période primordiale approchée avec attention! Conseil: Un document central Analyse conceptuelle mais aussi fonctionnelle Niveau conceptuel: MCD (Modèle Conceptuel de Données) et MCT (Modèle Conceptuel de Traitements) Niveau organisationnel: MLD (Modèle Logique de Données) et MLT (Modèle Logique de Traitements) Niveau physique: MPD (Modèle Physique de Données) et MOT (Modèle Opérationnel des Traitements) Conception (points clés) Concevoir du plus général au plus précis Pièce par pièce mais aussi ensemble! Ne pas hésiter à recommencer On peut très bien se tromper! Concevoir avec rigueur Eviter de grands risques en réalisation Savoir mettre fin à la conception Trouver le juste équilibre entre conception et temps de développement 27 28 Conception et réalisation Conception et réalisation Réalisation Phase de développement (codage) Nécessité d une très bonne planification Comment découper le projet? Ce qui doit être fait (tâches) Par qui (ressources) Comment les résultats (livrables) doivent être présentés Comment les valider et à quelle étape cycle de vie et intégration continue 29 Comment ordonner les tâches? En séquence ou en parallèle? Planning Date au plus tôt et au plus tard pour chaque tâche Importance du chemin critique et des marges Estimation des charges des tâches * * détaillé plus tard dans la suite du cours 30 5
Validation Validation Assurer que le produit réalisé répond bien au cahier des charges Tests unitaires Fonctionnement correct d une partie ou d un module Réalisés majoritairement par les développeurs Tests d intégration Bon fonctionnement de l ensemble du projet Réalisés et rassurés par QA Attention: au fur et à mesure de l'avancement du projet Tests fonctionnels Fonctionnalités d une application sans se soucier des détails d implémentation Attention: Ce ne sont pas des tests d intégration! Assurés par QA dès le début : intégration continue Test de performance Problèmes de performance? Plan de test Périmètre dans lequel s effectueront les tests Différents scénarios et jeux d essais nécessaires Bilan des tests, observation, etc. 31 32 Recette et réception Recette et réception Les choses à faire pour la recette Prévoir l installation du produit Explication de l IHM Prévoir les interfaces avec d autres applications / systèmes Présentation de la performance du produit Mesures de sécurité Robustesse (support mémoire, erreurs internes, changement de mode) Aspect réseaux Exploitation (sauvegarde, restauration ) Document de réception Objectifs de la réception : conformité fonctionnelle du produit réalisé Présentation des livrables à réceptionner Limites connues Vocabulaire ou abréviations Responsabilité droits informatiques Procédure de réception Ajournement de la réception (optionnel) 33 34 Livraison Bilan de fin de projet Mise à disposition Sites pilotes Présentation du produit, forum pour identifier les bugs Mises à jour du produit achevées, en cours ou dans le futur Formations possibles pour mieux se servir du produit Une entraide Une assistance (téléphonique, en ligne, etc.) Une maintenance Suivi de la livraison Feedbacks des clients Mises à jour correctives ou évolutives Constituer une base de connaissances, d expériences et de pratiques Un enrichissement pour les futurs projets! Les rubriques d un bilan de projet Bilan de la charge et du coût des achats Bilan de l organisation Bilan technique Anomalies et évolutions Bilan qualité et méthodes Estimation des coûts d obtention de la qualité Appréciation globale Enquête de satisfaction 35 36 6
Constitution de l'équipe 1/2 Activités de la séance Mettez-vous en équipe de 4 personnes Vous êtes 22 personnes, ainsi : 3 équipes de 4 2 équipes de 5 Les CMI, mettez-vous en 4, SVP Attention : ne vous précipitez pas de définir les rôles au sein de l'équipe slide suivante 37 38 Constitution de l'équipe 2/2 SVN et maîtrise du sujet Revenez vers les compétences demandées pour chaque rôle et évitez : Je fais ça pour m'entraîner car c'est mon point faible Oui, tu t'entraînes et toute l'équipe se plantera Contrôle de connaissances Objectif : vos capacités de modélisation et votre vue globale Cela vous permet de mieux choisir des rôles L'enseignant vous créera des projets SVN Vérification de la connexion via site Web Création du projet SVN dans Eclipse (Rappel GLP) Chaque membre aura le même environnement de travail Maîtrise du sujet de projet Discussion en équipe pour être sûr d'avoir la même vision du projet Début de la rédaction du cahier des charges 39 40 Gestion de Projet Informatique Partie 2 : Gestion des ressources humaines CV et entretien d'embauche Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise "All are ready, if our mind be so." William - Shakespeare 41 42 7
Sommaire Chef de projet en RH Gestion des RH dans un projet informatique Rédiger un bon CV attractif Assurer un entretien d'embauche Activité de la séance : suspense!! Le rôle du chef de projet dans la gestion des ressources humaines: Constituer son équipe en fonction de la nature du projet Définir les profils Associer les compétences aux profils Mobiliser son équipe tout au long du projet Eviter des périodes de démotivation entraînant une baisse de productivité 44 43 Les comités d'un projet 1/3 Les comités d'un projet 2/3 Comité de direction Décision du lancement des phases du projet Valider les principaux livrables Effectuer le suivi global du projet Réunion au début et à la fin de chaque phase du projet En cas de problème, prendre des décisions 45 Comité de pilotage Contrôler les ressources du projet (humaines, matérielles) Suivre l avancement : tâches effectuées par rapport au prévisionnel Décider des sujets à remonter en comité de direction Réunion toutes les semaines (ou toutes les deux semaines) Réunions exceptionnelles en cas bloquant 46 Les comités d'un projet 3/3 Les utilisateurs Comité utilisateurs Valider les livrables du projet Organiser la mise en œuvre : recette, migration, déploiement Décider des sujets à remonter en comité de direction Réunion toutes les semaines (ou toutes les deux semaines) Réunions exceptionnelles pour régler un point fonctionnel ou organisationnel 47 Trois types d utilisateurs Les responsables des services à l origine du projet Participent au lancement et au suivi du projet Les représentants des utilisateurs Aident à la conception du projet Les utilisateurs du système existant Grâce à leur expérience du terrain, mettent en évidence les avantages et les inconvénients de l existant Appréhender l analyse des besoins pour la future application 48 8
L équipe projet L équipe projet S il manque certaines compétences Recrutement Non seulement un investissement financier mais aussi par rapport au facteur temps Intégration dans les meilleures conditions et le plus rapidement possible Sous-traitance Fait appel à des prestataires externes NE PAS dépasser 30% de la totalité du projet! Reprise de travail et de données impossible en cas de départ des compétences externes! 49 Les principaux métiers hormis le chef de projet (liste non exhaustive) Analyste Analyste-programmeur Equipe d exploitation Administrateur de base de données Responsable qualité Chargé de la documentation Chargé de la formation Chargé de la recette Certaines fonctions sont occupées simultanément par une même personne dans un contexte de petits projets 50 L équipe projet L équipe projet Analyste Elaboration de l architecture fonctionnelle Analyser le projet à deux niveaux: Niveau des données Niveau des traitements Création des modèles conceptuels et physiques Bonne connaissance des langages, des bases de données et du système d exploitation, ainsi que des outils de génie logiciel Le chef de projet? Non, pas tout à fait. 51 Analyste-programmeur Transformer les spécifications fonctionnelles en programmes Prendre soin de respecter l architecture technique et les normes de réalisation Mener les tests unitaires Connaissances informatiques en bases de données, langages de programmation, et algorithmiques. 52 L équipe projet L équipe projet Equipe d exploitation Fournir et gérer les environnements nécessaires pour les différentes phases du projet Suivre les performances des différents modules de l application Déceler d éventuels débordements en termes de montée en charge, d utilisation de mémoire ou de processeur Administrateur de bases de données (DBA) Gérer et maintenir les bases de données du projet Bonne connaissance en BD Techniques de modélisation Guider éventuellement les équipes de développement dans la phase de modélisation 53 54 9
L équipe projet Pilotage (Chef) Responsable qualité Mettre en place le plan d assurance qualité Suivre la conception et les développements Mettre en place des tests d intégration tout au long du projet 55 Planification des ressources Découpage du projet et des tâches en plusieurs phases Contraintes prévisibles de chacun Les disponibilités Calendrier «Miletones» Réunions Organisation 56 Pilotage (Chef) CV : Les questions à poser avant tout Motiver les personnes L intérêt du travail L autonomie dans le travail La qualité des relations avec les personnes Les évolutions de carrière La sécurité de l emploi Chef: soyez attentif à l écoute des vos collaborateurs! Bon conseil: les hommes ne se mobilisent que s ils comprennent le sens de leur action Epauler, soutenir et motiver lors des périodes plus difficiles 57 Quelle est votre vision stratégique à long terme? Travailler dans un domaine plutôt qu un autre Devenir expert en.. Être ingénieur de logiciel pour quel type de projet Quel est votre marché et comment est il segmenté? domaines d activité, types d entreprises Quels sont les besoins et les motivations de ces «clients» 58 Préparer la rédaction du CV Importance de CV Anticiper les questions du recruteur Préparer la suite (entretien) en dévoilant une partie de vos talents dans le CV afin de donner envie de vous rencontrer Se mettre à la place du recruteur Si candidature spontanée, rechercher les coordonnées exactes de la personne qui va recevoir votre courrier (preuve de votre intérêt) 59 DRH : Celui qui sélectionne les CV avec une grande vitesse! Très peu de temps à la lecture (entre 30 et 60 secondes par CV) A vous de l aider dans son travail En résumé un CV doit Refléter fidèlement qui vous êtes Être adapté (au poste et à l entreprise) Se limiter à l essentiel tout en donnant envie au lecteur d en savoir plus Et cela passera par un entretien! 60 10
CV : la forme Le CV : la forme En général : une page Des paragraphes traditionnels Formations (anté-chronologique) Expériences/stages/projets Domaines de compétences Divers Attention, fluidité nécessaire, pas trop de paragraphes (4, maximum 5) Attention à la présentation! 61 Utilisation à bon escient des caractères gras (lisibilité «à bout de bras») Une utilisation parcimonieuse de la couleur Police pas trop exotique Évidemment pas de fautes d orthographe!! Enregistrer en format PDF pour être lu par tous. Enregistrer sous un nom explicite (CV- VotreNom) pour éviter d être noyé dans l anonymat des dossiers de votre interlocuteur. 62 CV : le fond CV : le fond Le fond : Expériences et contexte à valoriser Les savoirs = connaissances Les savoirs-faires = compétences Les savoirs-être = plaisir, goût, motivation, points forts, qualités Vos domaines de compétences sont, non seulement ce que vous maîtrisez le mieux, mais également ce que vous voulez faire! La mise en valeur des expériences (projets, stages, jobs, responsabilités) est essentielle et encore plus importante s il s agit d un CV à destination des pays anglo-saxons. 63 Les informations nécessaires pour décrire vos expériences : Dates (durée en heures si projet d étudiant) Responsabilités ou métier exercé et quelques détails sur les tâches effectuées et les résultats obtenus Nom de l entreprise ou du projet Localisation Quantifier dès que cela est possible ; Exemples : Volume horaire : 500 h, CA réalisé : 15 000 Responsabilité d encadrement de xx personnes 64 Avant entretien Avant entretien Dédramatiser l entretien pour arriver décontracté L enjeu est aussi important pour vous que pour le recruteur Le but de la rencontre est d apprendre à se connaître Se préparer oui, mais pas de «répétition» Gagnez en assurance avec la visualisation positive 65 Les erreurs à éviter en entretien d embauche Les plus grosses erreurs: Etre arrogant ou désintéressé Parler en termes négatifs de son employeur précédent Les erreurs courantes: Ne pas donner suffisamment d exemples de réalisations concrètes Ne pas s habiller correctement Ne pas poser les bonnes questions Trop cool ou trop stressé 66 11
Avant entretien Le jour de l entretien Adapter votre apparence L habit fait le moine?! Non Mais 80% de la communication est non verbale: Choix vestimentaires Coiffure, maquillage Position du corps Gestuelle Etre à l aise Arrivez à l heure! Sans être essoufflé ou en sueur devant le recruteur Allez en repérage quelques jours avant pour identifier le lieu du rendez-vous si nécessaire Revoyez avant de partir vos éléments de l information sur l entreprise Connaissez votre CV par cœur 67 68 Le jour de l entretien Le jour de l entretien Dans le hall d accueil Si vous fumez, évitez de «griller» une dernière cigarette avant d entrer dans les locaux de l entreprise Odeur de tabac Soyez calme et souriez quand vous vous présentez à l hôtesse Premier contact très important Allez vous asseoir en respirant calmement Coupez votre portable 69 Dans le bureau du recruteur Saluez le recruteur par un simple bonjour et surtout, souriez Remerciez-le de vous recevoir et attendez qu il vous invite à vous asseoir Otez votre manteau, posez votre sac à vos pieds et installez-vous confortablement Demandez la permission avant de prendre des notes Essayez de vous détendre : un entretien sert à mieux vous connaître, pas à vous piéger 70 Le jour de l entretien Après entretien Dans le bureau du recruteur Regardez votre interlocuteur dans les yeux sans toutefois le fixer avec excès Evitez de monopoliser ou de couper la parole Présentez vos expériences professionnelles sans avoir le nez collé sur votre CV Posez des questions au recruteur sur l entreprise, les missions liées au poste, les projets à venir Remerciez-le en souriant en fin de l entretien Pensez à saluer l hôtesse qui vous a accueilli 71 Lettre de château Un mot de remerciement Remerciez sincèrement pour l accueil reçu et pour l échange d informations Indiquez que vous tenez à la disposition de l entreprise pour un prochain rendez vous Inutile de rappeler des éléments du CV N oubliez pas la formule de politesse! Demandez des explications par email en cas de candidature refusée, sans polémique! 72 12
Activités de la séance Concours : Simulation d'entretien Pour chaque équipe Choisissez un poste parmi MOE, QA et DOC à recruter Le membre y correspondant joue le candidat Les 3 / 4 autres membres font l'équipe de recruteur Chaque recruteur pose une question liée au poste et au projet et le candidat y répond Ne posez pas la question Pourriez-vous vous présenter? 73 74 Cahier des charges Revenez sur le cahier des charges du projet Soumettez une première version Avant le jeudi 23 janvier 23H30 Cette version ne contient que 4 pages max. (sans comptez page de garde et sommaire) 2 pages pour la description détaillée des fonctionnalités 2 pages pour d'autres aspects Références à la première séance Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 75 76 The earliest moment is when you think it is late. Sommaire Objectif et définitions des termes utilisés Les modèles séquentiels: Cascade, V Les modèles agiles : ASD, DSDM, FDD, Crystal Bonne pratique : PRINCE2 78 77 13
Objectif d un cycle de vie 1/2 Objectif d un cycle de vie 2/2 Définir la démarche à appliquer à un projet Attention : on parle ici des cycles de développement de projet, pas de notions marketing Choix : 4 facteurs majeurs à prendre en compte: Minimiser les évolutions fonctionnelles en cours de projet Soutenir la démarche d assurance qualité (QA) Maîtriser les coûts et les risques Garantir sa conformité aux règles contractuelles et juridiques 79 D autres éléments pouvant avoir une influence sur le choix de cycle de vie La culture de l entreprise Les équipes de projet Le niveau de connaissance des utilisateurs Le contexte du projet Les acteurs intervenant Le type du projet 80 Définitions des termes Prototype L embryon du produit initial : "Je saurai ce que je veux quand je le verrai" Viser à livrer rapidement une maquette de la solution à développer avec un minimum de fonctions viables Clarifier les besoins afin d y arriver à une meilleure définition des spécifications fonctionnelles et techniques Eviter l écart entre les besoins réels, ceux exprimés et ceux interprétés 81 Définitions des termes Effet tunnel Point de départ : connu Point d arrivée : inconnu Rester dans le tunnel noir Pour les clients Pendant très longtemps, pas de communication avec les membres de l équipe de projet Grand risque d avoir un résultat non satisfaisant! Pour les développeurs De grandes phases de refactoring du code 82 Modèle en cascade Modèle en cascade Expression des besoins validé? Spécifications validé? retour validé? retour Conception Développement validé? retour validé? Test retour retour Maintenance 83 Principe Une suite de phases dans un déroulement linéaire Validé avancer, non validé retourner Avantages et inconvénients Bonne réduction de risques en minimisant l impact des incertitudes Bonne solution pour les projets peu complexes Problèmes non découverts avant les tests Pas de prise en compte des évolutions Difficulté d amélioration des performances Durée du projet inférieure à un an 84 14
Expression des besoins Spécifications Conception globale Modèle en V Conception détaillée Développement Tests unitaires Qualification Tests d'intégration Validation des besoins 85 Modèle en V Principe Modèle orienté tests Décomposition et recomposition Avantages et inconvénients Proposer au fur et à mesure une démarche de réduction des risques, en minimisant progressivement l impact des incertitudes Exclusion de l utilisateur dès la phase de conception car trop technique Contrôle qualité significatif seulement en fin de projet Dans un contexte compétitif, risque éventuel de ne pas respecter les délais 86 Modèle agile : ASD Adaptive Software Development Spéculer Collaborer Apprendre Planification Planification Planification Boucle d'apprentissage Initialisation Développement Planification Planification Planification des composants Planification Planification Contrôle Planification qualité Réunion finale 87 Modèle agile : ASD Spéculation Initialisation (cahier des charges) : Objectifs, contraintes, intervenants, dates, estimation des charges, risques critiques Détermination du nombre optimal d'itérations et de leurs contenus (composants) Un tableau de bord Collaboration Collaboration optimale entre les membres de l'équipe Assurer l'efficacité de la production Apprentissage Vue de la maîtrise d'ouvrage (clients) Vue de l'équipe : points positifs et négatifs Vue de progression du projet 88 Où en est-il par rapport à ce qui était prévu? Modèle Agile : ASD Caractéristiques S'adapte particulièrement aux projets e-business Réalisation en des temps très courts Support de nombreux changements et incertitudes Focalisation : viser les résultats plutôt que les tâches Itération : évolution en fonction des retours d'utilisateurs Changement : capacité à supporter un changement fonctionnel ou technique en cours de développement Avantages / Inconvénients Grande souplesse dans le changement Rapidité, respect des délais Implication du client Gestion des risques : absence totale de stabilité! 89 Modèle agile : DSDM Dynamic System Development Method Modèle fonctionnel itératif Etude de faisabilité Etude du business Conception et développements itératifs Mise en œuvre 90 15
Modèle agile : DSDM Modèle agile : DSDM Description des phases Etudes de faisabilité Définir les problèmes à résoudre faisabilité : plans techniques, méthodologique et budgétaire Etude du business Analyse des processus métier hiérarchiser les besoins plan global de prototypage Modèle fonctionnel itératif Définir une série de modules logiciels Conception et développements itératifs Fournir un système intégrant toutes les fonctionnalités Mise en œuvre Phrase de livraison éviter les tests finaux susceptibles de présenter des dysfonctionnements pouvant s'avérer désastreux pour le projet 91 Principe Besoin d'un expert technique bien expérimenté Gestion de temps (time-boxing) : caractéristique principale sensible au temps Itération avec des délais stricts Avantages / Inconvénients Gestion de projet très efficace et rapide Permettre d'améliorer la performance de développement Pas de règles de conduite strictes adaptation nécessaire à chaque projet 92 Où trouver cet expert?! Modèle agile : FDD Feature Driven Development Définition d'un modèle global Linéaire Inventaire des features Planification à partir des features Développement d'une feature Itération Conception d'une feature Mise à disposition d'une feature 93 Modèle agile : FDD Feature Client-valued fonctionality Description des phases Développer un modèle global Etablir une liste détaillée de features classées par priorité (inventaires de feautures) Planifier à partir des features Concevoir à partir des feature Construire (développement) à partir des features Mise à disposition des features 94 Modèle agile : FDD Modèle agile : Crystal Principe Mise en places des itérations très courtes Chaque itération produit un livrable fonctionnel Bases : caractéristiques de l'application (features) Avantages / Inconvénients Motiver les développeurs : livrable utilisable Sécuriser le chef de projet : état de l'avancement visible au gré des itérations Satisfaire les clients : livrables concrets, planning clair Maintenance de l'ensemble des composants peut parfois se muer en challenge quotidien programmation par binôme (pair-programming) 95 Conception détaillée Spécification Conception Planification Dernière itération Mise en production Plan d'action Tests fonctionnels Développement Tests unitaires et d'intégration Présentation Manuel utilisateur 96 16
Modèle agile : Crystal Description des phases Spécification : classer et prioriser les besoins Conception : choix des technologies et de l'architecture Planification des fonctionnalités à réaliser Itération de développement Conception détaillée plan d'action Présentations périodiques Eviter toute dérive et assurer la conformité avec les exigences des utilisateurs Documentation régulière avant le lancement de chaque itération 97 Modèle agile : Crystal Principe Communication, promiscuité des développeurs et les rencontres avec les utilisateurs améliorer la qualité des échanges Livraisons périodiques fonctionnalités mises à disposition des utilisateurs Peu de normes, voire quasi inexistantes mais beaucoup de documents! Avantages / Inconvénients Adapté aux petits projets (moins de six personnes) Flexibilité, rapidité, livraisons fréquentes Inadéquation pour des projets plus importants 98 Les modèles de cycle de vie Bonne pratique : PRINCE2 Modèles séquentiels Cascade, Intégration, En V Modèles itératifs Incrémental, Spiral de Boehm Modèles agiles ASD, DSDM, FDD, Crystal, Scrum, XP, Lean D'autres modèles RAD, UP 99 Principe Tenir compte des facteurs changeants de l'environnement du projet susceptibles d'influencer son succès Un langage commun aux participants d'un projet Fait l'objet de deux certifications Fondamental : l'examen qui vérifie qu'un collaborateur dispose des connaissances nécessaires pour participer à un projet géré selon la méthode PRINCE2 Praticien : suite à l'examen fondamental, donne la garantie d'une maîtrise parfaite de la méthode pour gérer un projet 100 Bonne pratique : PRINCE2 Conclusion Elaborer le projet Lancer le projet Diriger le projet Contrôler une étape Gestion de la livraison du produit Planification Gestion de la livraison du produit Clôture 101 La production d'un projet informatique est : choisir un cycle de vie ne pas rester figé dans un modèle (changer, adapter) planifier (découpage, contrôles qualité, revues) autoriser une certaine souplesse prévoir : ce qui n'est pas fait aujourd'hui risque d'être oublié demain assurer une forte communication entre tous les intervenants adhérer à la méthodologie utilisée faire preuve de bon sens 102 17
Activités de la séance Du cahier des charges aux releases Vous avez deux releases à réaliser Le travail de CHEF et DOC Rappel : première release (13 mars) Quelles sont les fonctionnalités à réaliser dans cette première release? Quel cycle de vie choisissez-vous pour y arriver? Mise en œuvre pour l'équipe? Contraintes? Faisabilité? Production : plan de releases logique 103 104 Technologies multi-threading Etude du programme de démonstration Le travail de MOE (1-2 personnes) et QA Comprendre le mécanisme de synchronized méthodes wait(), notify(), notiflyall() coordination entre plusieurs threads Remise à niveau technique + entraînement A deux ou trois, pouvez-vous ajouter des gares dans le programme, où un seul train peut (doit) stationner pendant quelques instants à un moment donné? Gestion de Projet Informatique Partie 4 : Les réunions Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 105 106 The meeting of different personalities is like the contact of different chemical substances : if there is any reaction, all are transformed. Sommaire Objectif et problématique d une réunion Comprendre et préparer une réunion Déroulement d une réunion Animer Activités en équipe (sous-équipes) Défi! 108 107 18
Réunion : Objectif Définition Une réunion rassemble des personnes en un même lieu pour participer à une activité commune ou collective. Réunion : Problème et résolution Réunion non gérée = Chronophage Répartition du temps consacré Finalités d une réunion pour le projet Réunir les différents acteurs du projet Faire le point sur l avancée du projet (réalisé, en cours, restant à faire) Faire le point sur le planning (avance et retard) 109 Prendre des décisions Préparation Réunion Compte rendu! 110 Les types de réunion Préparation une réunion Réunion d information Diffusion de l information pas de décision! Réunion d échange Favoriser le dialogue et recueillir les points de vue Réunion de décision (important) 1. Exposé de la situation 2. Identification des alternatives par le groupe 3. Analyse de chacune des alternatives 4. Choix d une alternative et validation de la décision (groupe) 111 Les questions à se poser Quels sont les thèmes à aborder : de quoi parle-ton? Et avec qui? Quels sont les objectifs : où veut-on arriver en fin de réunion? Quand et où organiser la réunion? Quel est le plan d actions pour y arriver? 112 Réunion : rôles Un animateur qui Diriger vers la production Réguler en facilitant les échanges Organiser les interactions Eviter les conflits Créer les conditions de la réalisation de l objectif Un secrétaire : informatiser et envoyer Des participants Badauds, spectateurs, conviés 113 Réunion : Déroulement Ouverture (lancement) de la réunion Rappelez le sujet, la durée de la réunion et des temps impartis pour chaque point Il faut créer un climat de confiance. Préparez-vous! Cœur de la réunion Cette partie est interactive et participative Il faut une très bonne gestion du temps Conclusion de la réunion Synthèses partielles Synthèse globale Plan d actions pour la suite?! 114 19
Le temps contre-productifs Gérer les diverses réactions Le retrait des participants Qu est-ce que je mangerai ce soir? Les rituels sociaux On fait une petite pause (40 minutes)? Je présente la situation (30 minutes écoulées ) Les procès d intention Tribune ou champ clos de la colère, du mal-être ou du règlement de compte Les conversations privées «Qu en penses-tu?» «C est du grand n importe quoi!» Les passe-temps Enfin, une occasion pour nous détendre! 115 Les «bavards» Reformulez la partie pertinente de leurs interventions Rappelez les contraintes des horaires Les «timides» Invitez-les à s exprimer, valoriser leurs propos Utilisez la forme questions/réponses Les «opposants» Demandez-leur de donner des exemples illustrant leur prise de position Précisez-leur que leur opinion n est qu un point de vue 116 possible, mais pas le seul Activités de la séance 117 Conception et parallélisme Conception IHM CHEF et DOC : trouvez un outil approprié avec lequel vous décrivez votre conception de l'interface graphique du projet Conception Moteur MOE et QA : concevez le moteur (la simulation) de votre projet, décrivez votre conception de façon générale indépendamment du langage de programmation utilisé pas de diagramme de classes dans ce document SVP 118 Réunions de l'équipe observées Une première réunion de type mixte Réunion d information et d échange Très courte, pour bien démarrer le travail en parallèle en éliminant les grands obstacles Travail en parallèle entre les deux réunions Une deuxième réunion de décision IHM + Moteur validation de la solution «Jointure» entre les deux? Remise de la production avant 16H par MOE Gestion de Projet Informatique Partie 5 : Estimation des charges et gestion de qualité Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 119 120 20
Sommaire Principes de l estimation des charges Right tool for the right job. Méthode d estimation «point de fonction» Qualité de projet avec le modèle Mc Call Activités de la séance 122 121 Objectif d estimation des charges Problématique Une phase incontournable Planification Définir l ensemble des tâches à réaliser Quantifier la charge associée à ces tâches Résultats Fixer une date de fin de projet (cas général) Justifier des besoins en ressources humaines Prioriser la mise en place de fonctionnalités Organiser le travail de l équipe 123 Les projets sont souvent sous-estimés! Les dépassements d échéances proviennent plus souvent d une mauvaise estimation que d une mauvaise réalisation Pourquoi sous-estime-t-on? L expérience limitée des acteurs Le manque de capitalisation sur les expériences L irrégularité du suivi des projets L incapacité à estimer les impacts de modifications La volonté de donner une bonne image (plaire, besoin de gagner, optimisme, etc.) 124 Une estimation adaptée Méthode «points de fonction» Au fur et à mesure de l avancée du projet, l estimation pourra (devra) être revue nouvelles facteurs identifiées Facteurs susceptibles d affecter l exactitude des estimations Toutes les données utilisées pour estimer L exactitude de tous les calculs L expérience de l équipe sur les technologies utilisées Le cycle de vie utilisé dans le cadre du projet Le contexte (rigueur de planification, conduite et suivi) de mangement du futur projet Les incidents majeurs susceptibles d apparaître en cours de projet 125 Principe Une description des fonctions du projet 3 niveaux de complexité et 5 classifications Estimation de point de fonction brut (PFB) Composant fonctionnel Niveau de complexité Faible Moyen Elevé Entrées 3 4 6 Interrogations 3 4 6 Sorties 4 5 7 Interface 5 7 10 Données logiques 7 10 15 126 21
Méthode «points de fonction» Méthode «points de fonction» Choisir une parmi les trois Entrées : Introduction de données dans le système Interrogation : uniquement des consultations de données Sorties : Restitution de données calculées aux utilisateurs Les parties à prendre en compte Interface : échange de données en import ou en export avec d'autres systèmes externes Données logiques : Entités participants créées, utilisées ou gérées par le système architecture N-tiers (N >= 2) 127 Démarche pour chaque tâche Identification et dénombrement des composants du projet Déterminer du niveau de complexité de chaque composant Valorisation des composants Totalisation des points de fonction bruts (PFB) Calcul PFA (Points de fonction ajustés) PFA = PFB FTA Charge = PFA Effort unitaire Voir l explication de FTA et Effort unitaire plus loin 128 Méthode «points de fonction» Méthode «points de fonction» Effort unitaire Phase projet Contexte d utilisation Effort unitaire Expression des besoins Petit projet 2 unités de temps Moyen projet Grand projet 3 unités de temps 4 unités de temps Conception détaillée Cas général 1,5 unités de temps Réalisation avec un L3G ou L4G par point de fonction 0,1 unité de temps FTA : Facteurs d ajustement Communication des données Distribution des données ou des traitements Performance requise Intensité d utilisation de la configuration matérielle Taux de transition Taux de transaction Saisie interactive Convivialité d'exécution 129 130 Méthode «points de fonction» Méthode «points de fonction» FTA (suite) Mise à jour en temps réel Complexité des traitements Réutilisation du code Facilité d installation Facilité d exploitation Portabilité Facilité d adaptations 131 Pondération des FTA Notation de chaque facteur de 0 à 5 selon son influence sur le projet 0 Nulle (facteur non présent) 1 Très faible (insignifiante) 2 Faible ou modérée 3 Moyenne 4 Forte (significative) 5 Très forte (essentielle) TFAP (Total des Facteurs d Ajustement Pondérés) FTA = 0,65 + (TFAP/100) 132 22
Bons conseils Esprit de qualité de projet Capitalisez par analogie sur les projets déjà réalisés dans votre organisme Utilisez les estimations proposées par les développeurs Utilisez plusieurs estimateurs différents pour trouver les points de convergence Ré-estimez plusieurs fois au cours de son cycle de vie Une garantie de la part des experts qui ont acquis des expériences au fil des ans 133 Principe de base On dit ce que l'on fait et on fait ce que l'on a dit. Une tâche parfois difficile dans un projet On est souvent réticent à la mise en place d'une politique de qualité Contrôles parfois perçus comme une surveillance du travail des membres de l'équipe Solution envisagée La qualité est bien l'affaire de tous et toute l'équipe doit être impliquée 134 Assurance de qualité : démarche Modèle Mc Call : Exploitation PLAN : écrivez ce que vous faites (définissez qui, quoi, où, quand, comment assurer la qualité) DO : faites ce que vous avez écrit CHECK : vérifiez ce que vous avez fait est conforme à ce que vous avez écrit ACT : validez Conformité par rapport aux besoins (l application répondelle aux besoins des utilisateurs?) Fiabilité (l application fonctionne-t-elle correctement dans tous les cas?) Efficacité (utilisation minimum des ressources, c est-à-dire temps, mémoire ) Intégrité (l application est-elle bien protégée, le niveau de sécurité est-il suffisant?) Facilité d emploi (mise en œuvre, prise en main) 135 136 Modèle Mc Call : Evolution et Adaptabilité Maintenabilité (est-il facile de localiser et de corriger les erreurs?) Souplesse (facilité de modification et d évolution) Testabilité (quels efforts à fournir pour tester le système?) Portabilité (le système est-il utilisable sur une autre machine?) Réutilisabilité (peut-on reprendre certaines parties du projet et les intégrer dans un autre logiciel?) Interopérabilité (peut-on interfacer l application avec un autre système?) Activités de la séance 137 138 23
Etat actuel et charges (CHEF + MOE) Gestion de qualité (QA + DOC) Vous faites un point sur les tâches à réaliser pour la première release Définir d'abord un ordre logique de tâches Pour chaque tâche, estimer sa charge Restez réalistes : Réfléchir au temps que vous pouvez consacrer sur le projet jusqu'à la date de release La taille d'une unité de temps seront donc relative à la charge globale (temps dispo / nbr total des FFA) Est-ce réaliste? Basez-vous sur le modèle Mc Call Réfléchir aux critères (facteurs) de qualité Est-il pertinent pour notre projet? Si oui, quelle métrique pourra être utilisée? Quel est votre plan d'assurance de qualité Comment la gestion de qualité s'intègre-t-elle dans le développement du projet? 5W + 1H questions/réponses 139 140 Présentation du travail Présentez quelque chose de réaliste Chaque groupe a 5 minutes d'exposé Support de l'exposé : slides On attend une vision synthétique des deux parties Ordre de passage (bureau A485, 15H30 16H) Gestion de Projet Informatique Partie 6 : Intégration continue Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 141 142 Every large system that works started as a small system that worked. -- Continuous Integration The following is based on a True Story In memory to those days and nights on CI 143 144 24
Sommaire Principes fondamentaux de l'intégration continue Environnement de travail de CI Les tests suites et le cycle quotidien de CI Activités de la séance 145 Principes fondamentaux de CI Cycle de vie Extreme Programming (XP) TDD (Test Driven Development) Réduire le risque d'intégration Détecter les problèmes d'intégration le plus tôt possible Le test immédiat des modifications Avoir toujours une version stable et viable 146 Environnement de travail de CI Un dépôt de source partagée Logiciel de gestion de version : SVN, Git Tout le monde travaille sur la branche principale (trunk) Intégration des modifications Chaque développeur fait des commits régulièrement (au moins une fois par jour). Des builds et des tests automatisés Serveur de CI (ex. Hudson) : compilation et lancement des tests automatiques (à chaque commit) 147 Environnement de travail de CI Logiciel de gestion des tâches Une tâche = un cas (case) Avant que la tâche soit finie, des tests automatisés correspondant sont déjà écrits par le Q.A. Tâches finie par le développeur tests activités dans la test suite Compétence du Q.A. Prédéfinir les tests n'est pas toujours une travail facile : techniques de mock, complétude 148 Pour faire un commit Les conditions strictes Il faut que le code compile Il faut que tous les tests qui passaient avant passent encore maintenant Commit pour une tâche Lancer manuellement les tests correspondants Qualité de code Nettoyer les petits bricolages Cohérence, convention de codage, design patterns 149 Pour faire un commit 9H 10H 10H 11H30 11H30-12H 12H-13h30 13H30-14H Test suite failed Test suite failed Bavardé Pause café prise Mangé Fnac fait Quoi maintenant? 150 25
Integration Test Suite Submit Test Suite L'ensemble de tous les tests Une couverture entière Des tests unitaires + des tests d'intégration entre les modules architecturaux Des milliers de tests automatisés Dont l'exécution nécessite des heures! Bien que idéal, il est impossible de lancer cette test suite avant chaque commit 151 Un sous-ensemble de Integration Test Suite Le Q.A. choisit soigneusement des tests significatifs et sensibles pour y mettre dans Submit Test Suite. Normalement, ceci doit couvrir >95% des cas. Son exécution doit être de quelques minutes Il n'y aura plus bavard, pause café, fnac 152 A l'entreprise : Jour J du projet Build de la nuit et régression Q A Qui a cassé la submit test suite?!! AH Ô mais ça passait chez moi Vu le dashboard, c'est lui! 153 Serveur CI Lancement de Integration Test Suite Tests échoués (cas) régression Priorité N 1 Ben, je suis sur la tâche X, comme prévu. T'es sur quoi là? Ah, je n'ai pas vérifié mes emails Pourquoi tu ne résous pas le cas de régression?! 154 Activités de la séance Programmez Et testez 155 156 26
Gestion de Projet Informatique Partie 7 : Tests de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise Product testers do not make products; they only make them better. 157 158 Sommaire Problème des systèmes mal testés Principes fondamentaux des tests Différents types de tests de projet Warning : the following images can be shocking! Mini activité de la séance 159 160 Cas 1 : Sonde Mariner 1 1962 Cas 2 : Therac-25-1985 Une erreur de trait d'union désastreuse! Erreur informatique : bug logiciel 130 millions dollars 5 morts! 161 162 27
Cas 3 : Ariane 5 Vol 501-1996 Explosion à cause d'un dépassement d'entier dans les registres mémoire 370 millions dollars Question drôle: Alors, on a besoin d'avoir 20/20 partout pour travailler dans les secteurs sensibles? 163 164 Coûts des bugs Définition du test 1000 900 800 700 600 500 400 300 200 100 0 Coût bug Le test est l'exécution ou l'évaluation d'un système ou d'un composant, par des moyens automatiques ou manuels, pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus Proverbe connu : Tester peut révéler la présence d'erreurs mais jamais leur absence. Implémentation Intégration Recette Utilisation 165 166 Les notions de base Test : méthodologies Objectif de test comportement du système envisagé Données de test données en entrée au système de manière à déclencher l'objectif de test Résultat de test conséquence ou sortie de l'exécution du test Case de test (test case) Objectif + données + résultat de test Test boîte noire Spécification (CdC) tester Sans connaître l'implémentation technique Test pouvant être prédéfini Test boîte blanche Tester en se basant sur le code source Tester pour du code déjà écrit 167 168 28
Les types de tests Test unitaire Tester une unité de programme de façon isolée Sans appel à d'autres fonctions Test d'intégration Tester le fonctionnement d'un ensemble de modules (via leur interface) Test de système D'un point de vue d'utilisateur Conformité du produit fini Les types de tests Test de robustesse Support (tolérance) des utilisations imprévues Sans appel à d'autres fonctions Test de sécurité Le système est-il vulnérable aux attaques? Test de performance Avoir un temps de réponse satisfaisant? Simuler différents niveaux de charges d'utilisateurs 169 170 Etes-vous un bon testeur? Une mini activité de la séance Les cas normaux VS les cas anormaux Une couverture complète Explosion combinatoire des entrées Les combinaisons peuvent être très nombreuses voire infinies Croisement des catégories Les catégories des cas ne sont pas toujours isolées. 171 172 Gestion de Projet Informatique Partie 8 : Project documentation (English version) Do not document the program, program the document! Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 173 174 29
Plan Introduction Introduction Process documentation All IT projects A large amount of associated documents Producing documentation costly work Product documentation Document quality 175 Why documentation work is so important? A communication medium team members Information repository maintenance engineers Crucial for project management Tell users how to use and administer the system 176 Introduction Process Documentation 1/3 Who should act? Computer engineers Professional technical writers When do we need to act? Before development During development After development What to do? Two types of documentation Process and Product documents 177 Objectives Record the process of project development, management and maintenance. Visibility of process management Project development involves similar cognitive tasks Only way of the visibility : Use of process documentation Plans, estimates and schedules To predict and to control the development process Reports 178 How resources were used during the development process Process Documentation 2/3 Process Documentation 3/3 Standards Set out how the process is to be implemented Organizational, national or international standards Working papers Ideas and thoughts of the engineers Interim versions of product documentation Implementation strategies Identified problems Rationale for design decisions Memos and emails Daily communications 179 Major characteristics Most of it becomes often outdated Ex. Draw up a plan on a weekly, fortnightly or monthly basis No longer be used after the system has been delivered Some useful exceptions Test schedules : re-planning the validation of system changes Working papers which explain the reasons behind design decisions (design rationale) 180 30
Product Documentation 1/6 Product Documentation 2/6 Objectives Describe the delivered project product Have a relatively long life Must evolve in step with the product that it described 2 types of documentation User documentation Tell users how to use the software product System documentation For maintenance engineers 181 Functional description Outline the system requirements and describe briefly the services provided Overview of the system Users read the document and decide if the system is what they need System installation document Provide details of how to install the system in a particular environment Description of files making up the system Minimal hardware configuration required Automated installers System administrator guide How to interact with other systems, hardware etc. 182 Product Documentation 3/6 Introductory manual Describe how to get started Should be liberally illustrated by examples How to recover from mistakes System reference manual Describe the system facilities and their usage Provide a complete listing of error messages How to recover from detected errors Don t be pedantic and turgid but ensure completeness 183 Product Documentation 4/6 User documentation categories System evaluators Functional description Description of services provided System administrators Installation document How to install the system System Administration guide How to operate and maintain the system Novice users Introductory manual Getting started with the system Experienced users Reference manual Details of all system facilities 184 Product Documentation 5/6 System documentation All of the documents describing the system itself From the requirements specification (scope statement) to the final acceptance test plan. Design, implementation Different types of tests Attention This documentation must be well structured TOO Un overview is needed, that ca lead the reader into more formal and detailed descriptions of each aspect of the system 185 Product Documentation 6/6 System documentation content Requirements document and an associated rationale Description of system architecture Description of program organization Description of each component in the system : functionality and interfaces Code documentation? ideally self-documenting A system maintenance guide Known problems Hardware and software dependency How evolution of the system has been taken into account in its design extensibility 186 31
Document Quality Document Quality Problem Too much computer system documentation is badly written, difficult to understand, out-of-date or incomplete. We need well written technical prose. Objectives Document quality is as important as program quality. Many software engineers find it more difficult than producing good quality programs 187 Document structure Definition : The document structure is the way in which the material in the document is organized into chapters, and within these chapters, into sections and sub-sections. Each part of the document independent Allow each part to be read as a single item and reduced problems of cross-referencing when changes have to be made Allow readers to find information more easily 188 Document Quality Document Quality Document structure : good practices All documents, however short, should have a cover page Chapters, sections, subsections An index needed if a lot of detailed, reference information used. For different readers, different vocabularies A glossary needed for defining technical terms and acronyms used in the document 189 Document structure : An example of cover page Project : Your project name Document ID : -ProjectName-SD11 Support for System Design Detailed Activities Version : 1.2 Date : February 1st 2013 Author : Your name Inspected : Inspector s name Submitted to CM : No Distribution : Project list Confidentiality : Commercial Approved : Approver's name CM ID : N/A Keywords : System design, UML class diagrams 190 Document Quality Documentation standards Objectives : To have a consistent appearance, structure and quality For your project, the appropriate standards are chosen and modified to suit your particular case. Standard categories Process standards Produce standards Interchange standards This is NOT related to process documentation and product documentation! Document Quality Process standards Define the approach to be taken in producing documents. Software tools used for document production Stage 1 : Creation Create initial draft Stage 2 : Polishing Proofread text Stage 3: Production Review draft Produce final draft Incorporate review comments Re-draft document Check final draft 191 Layout text Review layout Print copies 192 32
Document Quality Document Quality Stages of document preparation Document creation Initial input of the information in the document Supported by word processors and text formatters, table and equation processors, drawing and art packages Document polishing Improve the writing and presentation of the document Make it more understandable and readable Supported by on-line dictionaries, spelling checkers, etc. Document production Prepare the document for professional printing Supported by desktop-publishing packages, artwork packages and type styling programs 193 Product standards Apply to all documents produced in the course of the project development. Good practice Document identification standards Document structure standards Document presentation standards Document update standards Attention User documentation should be presented in a form appropriate to the user rather than the project! 194 Document Quality Document Quality IEEE standards for user documentation (1/2) Identification data Table of contents List of illustrations Introduction : purpose, summary of the contents Information for use of the document Concept of operations : explanation of the conceptual background to the use of the software Procedures Directions on how to use the software to complete the tasks designed to support Information on software commands 195 IEEE standards for user documentation (2/2) Information on software commands Error messages and problem resolution Glossary Related information sources Navigational features : allow readers to find their current location and move around the document Index : a list of key terms and the pages where these terms are referenced Search capability : for electronic documentation 196 Document Quality Document Quality Writing style Standards and quality assessment are essential However, it depends much on writer s ability Objectives : construct clear and concise technical prose Principles Written work must be written, read, criticized and then rewritten until a satisfactory document is produced Technical writing is a craft rather than a science 197 Writing style : good practices 1/2 Use active rather than passive tenses Use grammatically correct constructs and correct spelling Avoid long sentences which present several different facts Ex. You can find on our intranet Web site a PDF file that mentions an important issue that we discussed at the staff meeting earlier this month which should be taken into account by all of you as soon as possible in your daily development work, because if not it will reduce our team productivity. Keep paragraph short (max. 7 sentences) Do not be verbose : quality is more important than quantity 198 33
Document Quality Writing style : good practices 2/2 Be precise and define the terms that you use If a description is complex, repeat yourself Make use of headings and sub-headings Itemize facts wherever possible Do not refer to information by reference number alone Document Quality Interchange standards Electronic format or paper format Common usage : Adobe Portable Document Format (PDF) Microsoft Word can be used when draft modification needed Word processor Text formatting commands Finished document 199 Text editor Text formatter 200 Presentation to do by Doc (In English) Today's activities A planning for documentation work What documents to write? Who will write them, when to write? Who will inspect and approve? What's the status at this moment? Documents already written Improvement What to do till project delivery 202 201 Gestion de Projet Informatique Partie 9 : Performance review (English version) Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise Human can be ambitious, self-motivated and exercise self-control. It is believed that people enjoy their mental and physical work duties. According to them, work is as natural as play. They possess the ability for creative problem solving, but their talents are underused in most organizations. 203 204 34
Plan Academy to industry rating Academy to industry evaluation Job skills review Job approach review Academic results Intellectual ability Creativity Original thought Written expression Initiative Today's activity Working ability Oral expression 205 206 Academy to industry rating Job skills review What's the most important? Intellectual promise Ease in abstract reasoning Motivation Relative maturity Potential Capacity for growth A clear future plan of career 207 Technical skills Level of job related skills. Awareness of best practices and methodologies. Familiarity with development tools and languages. Job knowledge Knowledge of related technologies, familiarity with products and features. Awareness to emerging technologies and customer needs. Innovation Generates ideas for new features' development, methods to improve development process and existing code base. Problem complexity Solves highly complex and logical problems. Uses scientific method rather 208 than "let's just do it and then fix what doesn't work" approach Job skills review Job skills review Impact Individual decisions, designs, code have a unique and significant positive influence on the capabilities and acceptance of the product. Skills development Keeps abreast of industry and emerging technologies, hones software engineering skills, shows interest in assignments that requires new skills and new challenges. Quality of work Design and implementations are correct and seldom need to be re-worked, thinks a problem through before jumping to implementation, keep unit testing, actively seeks critique on code. Productivity Completes assignments on or ahead of schedule, maintains a high workload, 209 accomplishes tasks without too much difficulty. Planning & organization Organizes his/her tasks effectively in order to be productive. Creates effective work breakdowns and accurate schedules. Manages competing priorities effectively. Judgment Make decisions based on sufficient data, requirements & knowledge, ask for help before it's too late, decisions can be trusted : there will be no unpleasant surprises. Leadership Takes responsibility to guide other colleagues, guide team through a structured process of analysis, design and implementation, identifies issues and helps solve them, drives process to make timely, accurate and consistent decisions. 210 35
Job approach review Job approach review Attitude Optimistic, positive, can do, even tempered, does not crack under pressure. Team members enjoy working with this individual? Dependability Dedicated and can be depended on to get the job done. Does what is asked and more. A critical player during crisis or crunch time. Teamwork Selfless team member, the go-to person, goes beyond his/her own responsibility to increase the team's productivity. Communication Communicates effectively in meetings, via email and through well written documents. Good listening skills. Helps to keep team communication constructive and effective. 211 Cross organization Has excellent working relationship with peers in other departments and communicates effectively across the organization. May also include communication with outside groups. Initiative Always asking for more work, keeps abreast of industry, hones software engineering skills, wants to take on more responsibility. Flexibility Open mind to new assignments, likes challenges of new areas and platforms, understands and accepts the inevitable changes to strategy. Customer satisfaction Works hard to satisfy customers internal and external to the organization. Listens to requirements and does his/her best to be attentive 212 to customer needs. Performance review and seft-evaluation Today's activities Project manager Fill the performance review form for each team member, but not the self-evaluation An interview may be expected by the "boss" Team members Fill your self-evaluation form Make your answers clear An interview may be expected by the "boss" 214 213 Gestion de Projet Informatique Partie 10 : Droits et coûts financiers d'un projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise All over the world, copyright holders are trying to limite consumers' rights. 215 216 36
Sommaire Le droit de la propriété intellectuelle Le droit de la propriété intellectuelle Droit d auteur et les outils (logiciels, bases de données et noms de domaine) L état de concepts : licences et droits des brevets et innovations Les valeurs informatiques et libertés Les données nominatives et droit à l image Techniques d'évaluation financière Quatre formules : ROI, DR, TRC et VAN 217 Droits d'auteur Code de la propriété intellectuelle (CPI) Cession des droits d'auteur : (exemple de détails) Droit d'adaptation (modification, intégration) Droits de reproduction Droits de représentation Droits de distribution Destination, lieu et durée Tout ce qui n'est pas mentionné à l'avantage de l'auteur Cas «sensible» : employeur et employé En réalité : très peu usités par les employés 218 Le droit de la propriété intellectuelle Le droit de la propriété intellectuelle Les logiciels Les logiciels œuvres d esprit protégés par le droit d auteur Seule la forme est protégée Pas les idées, les fonctionnalités et les algorithmes Un droit moral : ex. le nom du logiciel Un droit d exploitation Autorisation ou non de la reproduction, l adaptation, la divulgation et la mise au marché. 219 Les bases de données (BD) Attention : ce ne sont pas les SGBD! «Tout recueil d œuvres, de données ou d autres éléments indépendants, disposés de manière systématique ou méthodique et individuellement accessibles par des moyens électroniques ou par tout autre moyen» Protégées par le droit d auteur La forme est protégée Une BD réalisée collectivement ou commanditée par une personne morale ne peut bénéficier de ce droit exception! Protégées par le droit sui generis 220 Cela protège le contenu informationnel de la BD Le droit de la propriété intellectuelle Le droit de la propriété intellectuelle Les noms de domaine Une double fonction : Accès à un espace d adressage sur Internet (DNS) et Identification AFNIC (Association française pour le nommage Internet en coopération) https://www.afnic.fr/ Dépôt des noms de domaine «.fr» et «.re» Depuis 2006, «.fr» ouvert aux particuliers La gestion des extensions Internet françaises «.fr», «.re», «.mq», «.gp», «.gf», «.wf», «.pm» 221 Licences L'acquisition d'une licence donne des droits : d'adaptation et de correction de réalisation d'une seule copie de sauvegarde de décompilation Droits des brevets et innovations Les logiciels sont brevetables? Discussion en cours Conditions possibles d'un brevet Effet technique Résolution d'un problème technique Présence de considérations techniques Contribution à l'état de la technique 222 37
Les valeurs informatiques et libertés Les valeurs informatiques et libertés CNIL (Commission Nationale de l'information et des Libertés) Données nominatives et droit à l image Citation de la règle générale «L'informatique doit être au service de chaque citoyen. Elle ne doit porter atteinte ni à l'identité humaine, ni aux droits de l'homme, ni à la vie privée, ni aux libertés individuelles ou publiques.» 223 Les données nominatives Définition Une donnée à caractère personnel, information relative à une personne physique pouvant être identifiée (par référence) Traitement automatisé d'information nominatives Tout ensemble d'opérations portant sur de telles données Activité : phase de «poule» Besoin d une déclaration Informer les personnes concernées Garantir la sécurité des informations Mettre à jour les informations dès la prise de connaissance 224 Les valeurs informatiques et libertés Droit à l'image Explication à écouter Activité : phase finale Qui sera le/la champion/championne? Techniques d'évaluation financière Retour sur Investissement (ROI) Délais de récupération (DR) Taux de rendement comptable (TRC) Valeur actuelle nette (VAN) 225 226 Techniques d'évaluation financière Retour sur Investissement (ROI) Efficacité d'un investissement en terme de rentabilité cycle de vie du projet en dépend Formule : BAA CAA ROI CP BAA : Bénéfices annuels actualisés CAA : Coûts annuels actualisés CP : Coût du projet 227 Techniques d'évaluation financière Délais de récupération (DR) Durée nécessaire pour récupérer la mise de fond initial Formule : I0 DR FFA I 0 : montant de l'investissement initial FFA : flux financier annuel du projet Hypothèse : FFA est identique chaque année. 228 38