Embed Size (px)
DESCRIPTION
Avec la taille croissante des équipes de développement, un nouvel aspect du métier de développeur PHP apparaît : rassurer les clients et managers en produisant des rapports. Ils portent les noms de document de conception, convention de code, référentiel de sécurité, planning de travail, diagrammes de classes, plan d'urbanisme.Nous passerons en revue ces documents, leur type et leur structuration. Nous verrons aussi les outils qui permettent de relier ces documents avec le code, pour avoir simultanément une vue d'ensemble, un suivi des évolutions et moins de travail d'implémentation.
Citation preview
Décrire un projet PHP dans des rapportsConfoo 2011, Montréal, Québec, Canada
9 mars 2011
mercredi 9 mars 2011
Agenda
Pourquoi il faut tout rapporter?
Sujets et contenus
Outils et méthodes
mercredi 9 mars 2011
Qui parle?
Damien Seguy
Consultant chez Alter Way ConsultingAlter Way Group
Industrialisation des développements PHP
mercredi 9 mars 2011
Yes, we take questionsmercredi 9 mars 2011
mercredi 9 mars 2011
Pourquoi ?J’ai juste à me lever pour poser la question
C’est pénible à écrire
Personne ne le lit
On est plus productif à coder
C’est obsolète dès que c’est écrit
On a pas le temps de le faire
Ca ralentit le rythme de travail
mercredi 9 mars 2011
Exemples
Conventions de code
Référentiel de sécurité
Plan d’urbanisme
Planning de travail
La conception
mercredi 9 mars 2011
Conventions de code
Objectif : coder de manière uniforme
Contenu : liste de règles à appliquer
mercredi 9 mars 2011
Sommaire
Liste de toutes les règles
Détails de chaque règle
Conventions de références
PEAR, Symfony, ZF, ...
mercredi 9 mars 2011
Section
Nom de la règle
Description littérale
Exemples et non-exemples
Obligatoire, recommandation, bonne pratique
mercredi 9 mars 2011
Outils
PHP_CodeSniffer
+ développement spécifique
Séances de corrections du code
mercredi 9 mars 2011
Récapitulatif
Procéder par liste
Procéder par exemple
Donnez des noms
Intégrez le document dans le quotidien
mercredi 9 mars 2011
Référentiel de sécurité
Objectif : maîtriser la sécurité
Contenu : montrer qu’on sait préparer l’application à affronter les menaces de sécurité
mercredi 9 mars 2011
Sommaire
Rappel métier et objectifs de sécurité
Le référentiel : OWASP, PCI, HIPAA, Basel II
Liste des menaces identifiées
Détails des protections pour chaque menace
Cahier de recette
mercredi 9 mars 2011
Détails des protections
Nom de la règle
Description de la menace et conséquence
Explication du mécanisme de protection
Exemples et illustration des mauvaises pratiques
Méthode de validation
mercredi 9 mars 2011
Récapitulatif
Exploitez les référentiels
Ou un gourou / expert
Capitalisez par l’exemple
mercredi 9 mars 2011
Plan d’urbanisme
Dossier d’exploitation, architecture serveurs...
Objectif : décrire les machines de production
Contenu : décrire la plate-forme d’hébergement de l’application
mercredi 9 mars 2011
SommaireSchéma du réseau
Liste des services de chaque serveur
Flux de données entre les serveurs, par service
Déploiement
Procédés d’administration
Installation, déploiement, redémarrage après crash
mercredi 9 mars 2011
Outils
Schéma
Visio, Dia, Omnigraffle, Xmind
Tableaux
mercredi 9 mars 2011
Récapitulatif
Document commun : doit être partagé, évolutif
Utiliser des schémas
mercredi 9 mars 2011
Planning de travail
Objectif : organiser l’action dans le temps
Contenu : liste des points clés du projet
mercredi 9 mars 2011
Structure
Planning du projet
Liste de tâches et réunions
Liste des cycles de travail
Découpage hebdomadaire
mercredi 9 mars 2011
Réunions
Point projet
Réunion technique
Daily scrum
Revue de cycle
mercredi 9 mars 2011
Taches
Audits croisés
Tests
Relecture de code
Validation avant commit du jour
Mise en Production
mercredi 9 mars 2011
Détails des activitésNom de l’activité
Fréquence
Durée : % et durée effective
Acteurs
Sujets abordés
Résultats attendus
mercredi 9 mars 2011
Occupation
50 %
20 %
10 %
10 %
10 %
Dev Tests Rapports Qualité MeP
mercredi 9 mars 2011
Outils
Calendrier
Diagrammes de Gantt
mercredi 9 mars 2011
Document de conception
Objectif : rassembler tout ce qui contribue à la progression du projet
Structure : dictionnaire des concepts
mercredi 9 mars 2011
Sommaire
Objectifs de l’application
Glossaire
Procédés particuliers
Liste de noms
mercredi 9 mars 2011
Objectifs de l’application
Rappel des objectifs métier
Donne une vision d’ensemble
Liste les cas d’utilisation
mercredi 9 mars 2011
Glossaire
Dictionnaire des termes utilisés
Sigles
Termes métier
Synonymes
Donner des illustrations
mercredi 9 mars 2011
Procédés particuliers
Explications des algorithmes
Schéma rapide du fonctionnement
Exemples d’application
mercredi 9 mars 2011
Listes de noms
Tout ce qui est nommé doit être listé
Classes, méthodes, propriétés, constantes, fonctions, sessions
URL, vues, contrôleurs, cookies, modules
Nom des tables, bases de données, serveurs, configurations
Formats de noms, de fichiers
mercredi 9 mars 2011
Listes de noms
Classes : diagrammes de classes, de paquets
Tables : MCD
Le reste : des tableaux en traitement de texte
mercredi 9 mars 2011
OutilsDiagrammes de classes
ArgoUML, StarUML
MCD
Mysql Workbench, Power Architect
Traitement de texte
Format extractible, vérifiable
mercredi 9 mars 2011
Récapitulatif
Savoir vérifier l’application de la conception
Savoir faire évoluer la conception au besoin
Beaucoup d’outils
Faites un choix
mercredi 9 mars 2011
Parce que!Je suis autonome
Je participe à sa rédaction
Je l’utilise régulièrement
Je me pose moins de questions
Je peux le tester facilement
Je le fait depuis le début
mercredi 9 mars 2011
L’impact est croissant
mercredi 9 mars 2011
mercredi 9 mars 2011
Outils
Détecteurs automatiques
Auditeurs statiques
Revue manuelle
Audits croisés
Ajouter une fiche de recette
mercredi 9 mars 2011
Tout le monde aime ça
Graphiques, camemberts, courbes...
Tableaux
Prévisions, constatations
mercredi 9 mars 2011
Pour qui?
Projet
Chef de projet
Développeurs
Administrateurs
Clients / utilisateurs
mercredi 9 mars 2011
Personne n’aime les écrire
Documentations cul-de-sac
Temps perdu
Jamais lu
Tout le monde se plaint de ne jamais en avoir
mercredi 9 mars 2011
Une activité complète
Prendre les informations
Les rédiger
Les relire
Les valider
Les faire comprendre
mercredi 9 mars 2011
Pilotage à vue
Est-ce que c’est fait?
Est-ce que c’est en retard?
Qu’est-ce qu’il y a dedans
On vire une partie, on en garde une autre
On recommence
mercredi 9 mars 2011
Les développeurs
Les clients et utilisateurs
Le chef de projet
Les administrateurs
mercredi 9 mars 2011
Comment documenter?
Établir un document texte, tableur
Le partager entre les intervenants
En lecture seule pour les autres
Automatiser la vérification du document
mercredi 9 mars 2011
Dans le doute?
Forcez sur les exemples
Arrangez-vous pour que le document soit éditable
Dégagez explicitement du temps pour lire des documents, les écrire, les relire, les appliquer.
mercredi 9 mars 2011
Spécifications et tests
Si personne ne les écrits, vous êtes dans la merde
Principe de la loi de Murphy : on oublie tout ce qui va, et on ne fait le bilan que de ce qui ne va pas.
Le temps de l’écrire, vous le comprenez, et vous temporisez face au client. Apaisement du cycle de développement
mercredi 9 mars 2011
Spécifications
Evitez le futur (utilisez le présent)
Fuyez les listes non terminées (privilégiez les listes finies, quitte à reporter en annexe des ajouts finaux, tbd)
Donnez des noms à tout, et mettez en glossaire
Explicitez ce qui ne l’est pas
Faites des tableaux dès que possible
mercredi 9 mars 2011
Urbanisation des serveurs
Les machines qui supportent l’application
Les services et les flux de données
Les accès et/ou les responsables
Les procédures à appliquer
deploiement, installation, restauration, crash, sécurité, sauvegarde
mercredi 9 mars 2011
mercredi 9 mars 2011
Evitez les réducteurs
Peut, pourrais
petit, léger, rapide, simple, light
beta, version x.xx.01
mercredi 9 mars 2011
