Projets de Diplôme Bachelor (PDB) HEIG-VD Kick-off Février 2011, v 1.6 christian.buchs@heig-vd.ch 1 Contenu 1. Gestion de projet 2. Bilans hebdomadaires 3. Le rapport 4. Activités de test 5. Évaluation du PDB 6. Suite... Février 2011, v 1.6 christian.buchs@heig-vd.ch 2 1
1. Gestion de projet niveau de détail Spécific. Conception Validation Déploiement Exploitation maintenance surveillance Réalisation installation, configuration enchaînement lien de validation En principe : développement itératif incrémental, avec utilisation des principes du modèle dit "en V" dans chaque phase. Réf. \\eint20.heig-vd.ch\profs\cbs\pdb\cycle-de-vie.pdf (chapitre 5 en particulier) ou d'autres sources... Dans tous les cas : utilisation de phases / itérations avec séparations claires, et pour chacune, résultats attendus, délivrables, dépendances et délais. Février 2011, v 1.6 christian.buchs@heig-vd.ch 3 temps 2. Bilans hebdomadaires A chaque fin de semaine (dimanche soir au + tard, vendredi ok aussi... ), m'envoyer un bilan hebdomadaire, plus précisément un email (ou wiki...) contenant (reprendre cette structure) : 1. Synthèse de la semaine : a) Bilan d'avancement du projet : Planification respecté? Dépassement / avance de combien de jours? Éventuelles mesures proposées pour pallier à ce dépassement / avance? b) Problèmes importants rencontrés? c) Questions? (réponse de ma part dans les 1 à 3 jours...) 2. Attachement : le fichier Excel (gestion de projet) avec le suivi et le journal de travail, tous les deux mis à jour. En plus : si phase de spécifications terminée, le document détaillant ces spécs et le plan de tests de validation; si conception terminée, document détaillant la conception. Avant de passer à la réalisation, vous êtes responsables de faire valider ces 3 documents (par moi + év. mandant). Février 2011, v 1.6 christian.buchs@heig-vd.ch 4 2
3. Le rapport Ce qu'on vous demande Cahier des charges Copier/coller de votre cahier des charges... Quoi exactement Comment le réaliser tirée de tirée de tirées de Spécifications / Analyse Conception... Réalisation... Fonctionnalités, diagramme UML des cas d'utilisation, exigences non fonctionnelles, etc. Logique détaillée, technologies, syntaxes, diagrammes UML : d'états et transitions, d'activité et de classe, etc. Février 2011, v 1.6 christian.buchs@heig-vd.ch 5 Structure du rapport suit généralement les phases / itérations du projet (cahier des charges, spécifications, conception, cf. pyramide). Réalisation : contient uniquement des informations pratiques comme l'infrastructure, outils de développement utilisés, problèmes avec l'hébergement sur un serveur, problèmes avec librairies insuffisantes, etc. En plus dans le rapport : détails sur tests unitaires et de validation. Indication pour le niveau de détail des spécifications : plus ou moins similaire à ce qui se trouve dans les RFCs. Important (cf. p. ex. partenariat PolCant VD HEIG) : La complétude de vos spécifications, conception et tests doivent être tels qu'un(e) informaticien(ne) absolument pas impliqué(e) dans le projet devrait pouvoir, sans autre explication ou aide : Développer votre application (réalisation) uniquement à l'aide de vos documents de spécifications et de conception. Exécuter les tests uniquement à l'aide du plan de test. Février 2011, v 1.6 christian.buchs@heig-vd.ch 6 3
Conduire le lecteur ("par la main") tout au long de votre texte : fil "rouge" conducteur continu, transitions... Formes passive / impersonnelle : Éviter : "je", "nous", "mon", "mes", etc. (sauf conclusion) Être précis : éviter "on", "il" (minimiser), etc. Rapport en français ou en anglais : éviter le franglais. Correcteur orthographique! Et relecture. Systématiquement. Notation cohérente (définitions à inclure au début du rapport). P. ex. : Termes anglophones : italique. Code, chemin, noms de fichiers, commandes : courrier gras. Respect des directives du département TIC, en plus des miennes qui seront ajoutées au cahier des charges (et ces transparents). Signature, date et lieu à la fin du rapport (après la conclusion). CD/DVD comme annexe du rapport (pochette), pas à part : voir directives dans le cahier des charges... A prévoir dès le début. Février 2011, v 1.6 christian.buchs@heig-vd.ch 7 4. Activités de test But : trouver des erreurs afin d'obtenir un système, après corrections, qui correspond aux exigences du mandant, de qualité (ce qui contribue à la sécurité), avec le niveau de sécurité désiré. Les tests bien menés permettent de minimiser les coûts de maintenance, de reprise du projet, et les incidents de sécurité. Les types et environnements de tests (avant la phase d'exploitation) : unitaires : tests isolés des éléments du système. Effectués par l'ingénieur(e) qui a réalisé le système. d'intégration : vérifier le système dans son ensemble (bouts de code, environnement). Préparés (phase conception) et effectués par un(e) ingénieur(e) différent(e), et/ou le/la responsable des tests. de validation : vérifier que le système est conforme aux spécs. Préparés (phase spécification) et effectués par un utilisateur et/ou responsable des tests. Avant de passer en "prod"... Février 2011, v 1.6 christian.buchs@heig-vd.ch 8 4
Les types de test de validation de "surveillance" niveau de détail Spécific. Conception Validation Déploiement Exploitation maintenance surveillance unitaires Réalisation installation, configuration enchaînement lien de validation d'intégration temps Février 2011, v 1.6 christian.buchs@heig-vd.ch 9 Étapes de tests (à effectuer dans chaque type de test) 1. Préparation (document : plan de test) Concevoir les cas-tests (procédures de test et résultats attendus). Planifier l'effort de test (RH, matériel). Préparer les outils de test. Préparer les données de test (ex. liste mots de passe). 2. Exécution (dossier de test) 3. Évaluation (document : rapport de test) Analyse et synthèse des résultats. 4. Corrections et tests de non régression Correction des erreurs d'implémentation, de la documentation. Prévoir environ le tiers du coût de la réalisation du système pour la correction des erreurs. Retester les corrections. Tester ensuite que les corrections n'ont pas provoqué d'autres erreurs : tests de non régression ( tests des corrections...). Février 2011, v 1.6 christian.buchs@heig-vd.ch 10 5
Pour concevoir les cas-tests (CT), l'idéal est d'établir une matrice de couverture (références croisées CTs / spécifications) : Identifier les caractéristiques des spécifications (SPs) à tester. Pour chaque caractéristique, élaborer un ou plusieurs CTs. Un cas-test peut "couvrir" plusieurs SPs et une SP peut nécessiter plusieurs CTs... Exemple : caractéristique numéro 9 : les logins doivent être enregistrés en spécifiant le nom d'utilisateur, la date, l'heure, l'action,... CT Sp Procédure Résultat attendu OK KO............ 26 9 Démarrer l'applic. selon le mode d'emploi prévu. Se loguer avec le compte utilisateur Jean. Ouvrir le fichier des logs situé dans 27 9 Démarrer l'application selon le mode d'emploi prévu. Se loguer avec le compte root. Ouvrir le fichier des logs situé dans... Le login avec le nom d'utilisateur de Jean, la date, l'heure du login, l'action,... sont enregistrés sur une ligne sous la forme fichier des logs situé dans... une ligne sous la forme... Le login avec le nom d'utilisateur root, la date, l'heure du login, l'action,... sont enregistrés sur une ligne sous la forme............... Février 2011, v 1.6 christian.buchs@heig-vd.ch 11 5. Évaluation du PDB Critères d'évaluation Pondération Professeur-e Expert-e Moyenne Evaluation intermédiaire 1. Qualité de la pré-étude et du rapport intermédiaire (analyse, recherche documentaire, décomposition, évaluation comparative des solutions, spécifications détaillées, planification) 2. Qualité du travail (gestion du temps et des imprévus, indépendance, initiative, assiduité) 30% 0.0 Evaluation finale 10% 0.0 3. Qualité du rapport final et de la documentation (exhaustivité des informations, clarté de rédaction et de présentation, synthèse) 4. Qualité du développement, de la réalisation et de la validation (respect du cahier des charges et de la planification, pertinence technique et scientifique de la démarche, innovation et créativité, tests) 10% 0.0 (1/2) (1/2) 40% 0.0 (1/2) (1/2) 5. Qualité de la défense (connaissance du sujet et du domaine concerné, clarté, qualité du support visuel, 10% 0.0 capacité de vulgarisation) (1/2) (1/2) Moyenne globale (calcul automatique) 0.0 Evaluation finale Février 2011, v 1.6 christian.buchs@heig-vd.ch 12 6
La qualité du rapport n'a "qu'une" pondération de 30% + 10%... Mais : c'est majoritairement en se basant sur le rapport que la qualité du travail (40%) sera évaluée par l'expert et le professeur... Donc impact important (~70-80%?) du rapport sur la note finale... Le rapport intermédiaire n'est pas un "brouillon" : il sera de qualité (voir section 3 et directives) et il doit contenir le travail effectué jusqu'à la fin du semestre. Un seul document pour tout : page de couverture, cahier des charges, table des matières, résumé, introduction, spécs phase 1, conception phase 1, etc., annexes... Février 2011, v 1.6 christian.buchs@heig-vd.ch 13 6. Suite... Pour le vendredi 27 mars 2011, pour validation par le mandant et le professeur : Cahier des charges Planification de la suite de votre PDB (jusqu'à midi le 29.07.11) et mise en place du suivi Interactions avec moi (pas forcément régulières...) : demande d'entretien suite à bilan hebdomadaire, feedback sur rapports intermédiaire et final, revues de phase (à fixer par l'étudiant(e)). Vous pouvez en tout temps me contacter par e-mail (questions courtes), mobile (questions urgentes), solliciter un entretien non planifié (questions plus complexes)... Vous devez solliciter un entretien avec moi en cas de problème important. Pour la fin de cette semaine : bilan hebdo (sans planification et suivi). Questions?... A votre disposition... Février 2011, v 1.6 christian.buchs@heig-vd.ch 14 7