Différences entre les versions de « Étude GPT2X:méthodologie »

De April MediaWiki
Aller à la navigationAller à la recherche
(Page créée avec « Catégorie:Candidats Page mère __TOC__ == Description de cette page == Cette page présente la méthodologie DEVINSY pour l'organisation de projet. ... »)
 
Ligne 6 : Ligne 6 :
 
Cette page présente la méthodologie DEVINSY pour l'organisation de projet.
 
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.
+
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 ==
 
== Organisation par phase ==

Version du 26 juillet 2013 à 14:35

Page mère

Description de cette page

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

Un projet peut se découper en 4 phases :

  1. le « Quoi faire ? » ;
  2. le « Comment le faire ? » ;
  3. le « Faire » ;
  4. le « Faire exister ».

Phase de consolidation de l'expression de besoin (« Quoi faire ? »)

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

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

Phase d'architecture (« Comment faire ? »)

Étude de l'existant

Dossier d'architecture

Phase de réalisation (« Faire »)

Phase d'exploitation (« Faire exister »)