Étude GPT2X:méthodologie
Description de cette page[modifier]
Cette page présente la méthodologie DEVINSY pour l'organisation de projet.
Cette méthodologie ne se veut pas meilleure qu'une autre, elle est basée sur l'expérience d'un « travailleur du logiciel » et reprend de nombreux éléments éprouvés.
Cette méthodologie s'adresse à tous, émetteur de besoin, utilisateur, responsable projet, développeur, etc.
Le but est d'offrir un support partageable commun entre tous les acteurs d'un projet.
Particulièrement, ce support est avantageusement un lien entre les non-techniciens et les techniciens.
Organisation par phase[modifier]
Un projet peut se découper en 4 phases :
- le « Quoi faire ? » ;
- le « Comment le faire ? » ;
- le « Faire » ;
- le « Faire exister ».
Phase de consolidation de l'expression de besoin (« Quoi faire ? »)[modifier]
Même si le « client » a déjà réalisé un document d'expression de besoins (cahier des charges, requirements, etc.), il est nécessaire que le chargé de projet en refasse un :
- reformuler le besoin dans un format/langage/vocabulaire adapté ;
- vérifier que l'expression de besoin est complète et valide.
La conso
Le cahier des charges[modifier]
En tant que document, son rôle est de donner une vision globale du besoin.
Les informations sont réparties en trois groupes :
- le contexte : fixe le cadre du besoin et ses acteurs ;
- les fonctionnalités : organisées sous formes d'arbre, de la plus globale à la plus fine ;
- les contraintes : ce ne sont pas des fonctionnalités.
Principes fondamentaux du cahier des charges :
- bannir tout vocabulaire pouvant provenir des solutions qui devront lui répondre ;
- seul le vocabulaire « métier » de la problématique est requis ;
- l'objectif étant d'avoir une vision globale du projet :
- le cahier des charges contient par définition un nombre réduit de pages,
- les détails sont ignorés : ils seront développés dans un document de « spécifications détaillées » (par exemple, les champs constitutifs d'une fiche client).
Le dossier de spécifications fonctionnelles[modifier]
Si le cahier des charges donne une vision macro des fonctionnalités, il faut pouvoir exprimer dans le détail les fonctionnalités. C'est l'objet du dossier de spécifications fonctionnelles. Contrairement au cahier des charges, par nature, ce document n'est pas limité en nombre de pages.
Phase d'architecture (« Comment faire ? »)[modifier]
Étude de l'existant[modifier]
Dossier d'architecture[modifier]
À partir du cahier des charges et du dossier de spécifications fonctionnelles, analyser en profondeur toutes les problématiques du projet et expression des solutions techniques.
À l'issue de ce chantier, sera disponible un document d'architecture comprenant :
- la liste des pages web du site ;
- un graphe de navigation des pages web du site ;
- la description détaillée de l'organisation du code ;
- la description détaillée des principes techniques de la plate-forme.
