Last modified 5 years ago Last modified on 07/24/12 11:22:55

OdtTemplate(template_planTravail)?

  1. Plan de travail
    1. Méthodologie
    2. MILESTONE 1
      1. Maintenir en tout temps une instance de test, reproductible par l'ensemble …
      2. Intégrer l'éditeur de métadonnées d'ORI-OAI
      3. Générer un fichier de configuration d'éditeur de métadonnée d'une instance …
      4. Stockage fiche originale (OriginalRecord?) dans Fedora au moissonnage
      5. Conversion VCard => vcard-rdf
      6. Premier jet de métamodèle
      7. Représentation des identités par références
      8. Conversion LOM => Metamodèle (MetadataView)
      9. Conversion Métamodèle => HTML
      10. Moissonner Eurêka
      11. Ébauche de site d’accueil regroupant les précédentes fonctionnalités
      12. Recherche de base (Plein texte)
      13. Générer les résultats du Query Engine en Atom
    3. MILESTONE 2
      1. Implanter des heuristiques pour assurer l'unicité des identités
      2. Représentation des vocabulaires dans le système
      3. Représentation des vocabulaires par références pour les ressources
      4. Permettre de restreindre la recherche à des vocabulaires de …
      5. Interface de navigation hiérarchique
    4. MILESTONE 3
      1. Permettre de rechercher dans des champs spécifiques des fiches
      2. Permettre de restreindre la recherche à des vocabulaires de …
      3. Générer des documents de description OpenSearch pour le QueryEngine
    5. MILESTONE 4
      1. Intégrer l’édition à un workflow
    6. MILESTONE 5
      1. Édition d’une fiche LOM
      2. Conversion Métamodèle => Dublin Core Qualifié
      3. Intégrer un validateur systématique au moissonnage et à l'exportation
      4. Générer un schéma pour le validateur LOM à partir d'un document de profil …
      5. Intégrer un éditeur d’identité
    7. MILESTONE 6
      1. Trier les résultats de recherche par pertinence
      2. Permettre de restreindre la recherche aux ressources ayant une ou des …
      3. Créer une interface d'affichage d'une ressource permettant de naviguer …
    8. MILESTONE 7
      1. Implanter la résolution des identités de vocabulaires
      2. Permettre de restreindre la recherche à des vocabulaires de …
      3. Permettre de restreindre la recherche à des vocabulaires de …
      4. Interface de navigation hiérarchique rendant visible les équivalences
    9. MILESTONE 8
      1. Gestion des collections
    10. MILESTONE 9
      1. Permettre d'appliquer une action à un groupe de ressources retournées par …
      2. Implanter une première version du vrai éditeur de groupe
    11. MILESTONE 10
      1. Exposition OAI-PMH de tout le dépôt
      2. Exposition du QueryEngine en SQI
      3. Exposition du QueryEngine en SRU
      4. Intégrer les gabarits au workflow pour l’édition des fiches
    12. MILESTONE 11
      1. Obtenir un rapport des liens brisés
      2. Exposer dans l’interface les résultats de recherche et de navigation …
      3. Conversion Résultats du Query Engine et Métamodèle => OpenDocument
      4. Moissonner le CCDMD
      5. Interface pour communiquer avec un contributeur/administrateur du dépôt …
    13. MILESTONE 12
      1. Intégrer une première correction sémantique des fiches : Ajouts de termes …
      2. Intégrer une seconde correction sémantique des fiches: Gestion des …
      3. Tirer toutes les descriptions de champs dans l’éditeur de métadonnées des …
    14. User Stories non-touchés par les éléments du plan de travail plus haut

Plan de travail

Afin d'assurer une meilleure compréhension entre les dirigeants du projet et les développeurs, nous avons séparé le projet en livrables. Ces livrables sont presque des incréments du système au sens agile du terme, c'est à dire qu'ils ajoutent des fonctionnalités qui peuvent potentiellement être mises en production telles quelles, et ce même si ces incréments touchent potentiellement plusieurs User Stories, et n'en ferment possiblement aucun. Ces incréments:

  • représentent une bouchée courte et facile à comprendre pour les développeurs
  • constituent en eux-mêmes un livrable facile à définir
  • sont ordonnés dans l'ordre où, au meilleur de nos connaissances, ils sont susceptibles d'être attaqués par les développeurs.

Nous avons ensuite regroupé ces incréments en milestones, dont les livraisons constitueront en pratique les points de mise en commun avec le groupe fonctionnel.

Notes importantes:

  • Les User Stories ne sont PAS l'incrément à livrer. Le livrable peut constituer une partie du User Story, ou encore le(s) User Story constituer une partie du livrable.
  • Il ne faut pas confondre le plan de travail et les priorités. Les priorités sont, et restent, l'ordre des User Stories dans le Backlog. Le but du plan de travail est d'arriver à une liste logique chronologiquement, tant pour la familiarisation des développeurs avec les technologies, que du point de vue des dépendances.
  • Les livrables ne tiennent pas vraiment compte de la définition, implantation et amélioration des interfaces usager. Il est attendu qu'à chaque sprint il y aura de plus en plus de tâches liées à ces aspects.

Méthodologie

Au début de chaque sprint (longueur de 4 semaines suggérée, vu la disponibilité à temps partiel des développeurs).

  • Prendre les User Stories touchés au point où on était rendu dans le plan de travail.
  • Pour chaque User Story, se demander s'il ne devrait par être scindé en User Stories plus petits, dont l'un pourrait être fermé par les tâches du sprint. Le but est d'une part, d'éliminer progressivement les épiques (très grands User Stories sur lesquels il est difficile d'intervenir directement) et d'autre part, de re-prioriser plus facilement la partie non-complétée du User Story original (il est difficile d'évaluer la valeur restante d'un User Story partiellement complété pour le prioriser).
    • Il faut néanmoins éviter de couper les User Stories en morceaux trop petits; les User Stories ne sont pas des tâches, ce sont des définitions de valeur d'affaire du système. De plus, il est inévitable qu'il reste certaines épiques (ex: recherche plein-texte), ou que d'autres ne puissent être fermés dans un seul sprint à cause de facteurs externes (ex: collaboration internationale sur l'éditeur de métadonnées.
  • Définir précisément les tâches faisant partie du User Story.
  • Choisir les tâches que l'on s'engage à compléter durant le sprint.

Pendant le sprint: Garder en tête

À la fin de chaque sprint:

  • Valider que ce qui était prévu a bel et bien été fait
  • Relire les 10 premiers User Story. Pour ceux qui ne sont pas touchés prochainement dans le plan de travail, s'assurer que l'on sait toujours pourquoi ce n'est pas le cas.
  • Mettre à jour le plan de travail
  • S'interroger sur les améliorations à apporter aux méthodes de travail

MILESTONE 1

Fonctionnalités minimales du système permettant la mise en place très partielle des principaux modules:

Maintenir en tout temps une instance de test, reproductible par l'ensemble des développeurs et accessible par les partenaires.

4j + incremental

Inclut documentation/procédure d’installation

User Stories: #147

Justifications:

  • La barrière d'entrée est encore énorme pour un nouveau développeur s'il ne peut installer facilement une instance fonctionnelle complète à partir des sources, pour pouvoir ensuite se concentrer sur la partie qu'il veut modifier.
  • Sans exemple concret du système, il est extrêmement difficile de développer, puis maintenir une vue d'ensemble. Sans cette partie concrète, la situation empire, plutôt que de s'améliorer, à mesure que la documentation devient plus exhaustive.

Modules: Tous

Intégrer l'éditeur de métadonnées d'ORI-OAI

5j Frédéric B.

Une première version se limitant à l’édition simple d’un LOM ou DC. Sans validation ou contraintes liées à un profil d’application

User Stories: #57, #130

Modules: MetaDataEditor?

Générer un fichier de configuration d'éditeur de métadonnée d'une instance d'un profil d'application Dublin Core

A ESTIMER (Frédéric B.)

User Stories: #53, #73

Modules: ApplicationProfile, MetadataEditor

Justifications:

  • L'éditeur LOM est en changement rapide, le faire pour l'éditeur Dublin Core permet de valider les technologies et est plus simple.
  • Le faire en début de projet favorise la coopération efficace avec ORI-OAI

Stockage fiche originale (OriginalRecord?) dans Fedora au moissonnage

5j

Avec gestion des updates/deletes des prochaines moissons

User Stories: #50

Modules: Harvester Harvester

Conversion VCard => vcard-rdf

10j

Mise en place d’une 1ère implantation du mécanisme de transformation par service Fedora (premier SDep), 1er API.

User Stories: #30

Modules: Metadata Metadata ou Identity

Justifications: Nécessaire pour représentation des identités par référence.

Premier jet de métamodèle

10j

Analyse d’interactions Fedora-Mulgara-SPARQL Création de modèle RDF ?

User Stories: #130, #140

Modules: FedoraRepository

Représentation des identités par références

(inclus dans le point suivant)

User Stories: #32

Modules: Identity, FedoraRepository

Conversion LOM => Metamodèle (MetadataView)

15j

Initialement très limité:

  • Titre
  • Description
  • Classifications
  • Localisation
  • Auteur

User Stories: #130

Modules: Metadata

Justifications: Nécessaire pour la majeure partie des fonctionnalités, particulièrement de recherche et conversion de Vocabulaires

Conversion Métamodèle => HTML

2j

Consultation des fiches. Il devrait être trivial d'afficher l'URL REST de cette représentation directement des résultats de recherche. Service dynamique Fedora

User Stories: Prérequis de #76, #15, #4

Modules: Metadata

Justifications: Nécessaire pour afficher une fiche à l'usager

Moissonner Eurêka

Test réel à répéter

User Stories: #50, #74

Modules: Harvester

Justifications:

  • Donne un corpus significatif et de qualité syntaxique relativement homogène pour s'assurer de maintenir un performance raisonnable.
  • Donne une base de comparaison (fonctionnalités, interface, performance)

Ébauche de site d’accueil regroupant les précédentes fonctionnalités

5j

User Stories: #91

Modules: Portal

Recherche de base (Plein texte)

20j

Avec RISearch. Recherche simple. Tests indexation Lucene dans Mulgara

Question de ne pas s’empêtrer dans des questions d’interface à ce stade, utiliser quelque chose comme adapter le javascript de pyopensearch (probablement la meilleure option], OJAX ou un Google Gadget pour afficher la boîte de recherche et les résutats (le QueryEngine utilisant le standard OpenSearch).

User Stories: #42

Module: QueryEngine

Générer les résultats du Query Engine en Atom

3j

Utilise pour l’instant la représentation DC directement stockées dans Fedora, en attendant un conversion complète Métamodèle->DC

User Stories: #43

Modules: QueryEngine

Justifications: Format normal d’OpenSearch pour les résultats, faire d’Atom avec du Dublin Core inclut notre représentation “native” rendra très facile l’exposition RSS

Total: 85 j/p estimé, amène à fin novembre 2011.

MILESTONE 2

Emphase: Gestion des vocabulaires et navigation hiérarchique.

Implanter des heuristiques pour assurer l'unicité des identités

Inclut d’implanter les interfaces pour les fusionner.

User Stories: #32

Modules: Identity, FedoraRepository

Représentation des vocabulaires dans le système

Soit (VDEX (plus près d'ORI-OAI), ou OWL (plus près de RDF-MLR))

User Stories: #10

Modules: FedoraRepository

Représentation des vocabulaires par références pour les ressources

Dans le MetadataView.

User Stories: #10

Modules: FedoraRepository, Metadata

Permettre de restreindre la recherche à des vocabulaires de classifications

Tester qu'une ressource utilisant un vocabulaire de style MLR (où l'identifiant du terme n'a rien à voir avec l'étiquette), peut être trouvée en tapant l'étiquette du terme de vocabulaire dans lequel la ressource est classée. Tester qu’une ressource attachée à un terme d’un vocabulaire hiérarchique peut être trouvée en restreignant à un terme parent du terme dans lequel la ressource est classée.

User Stories: #12

Modules: QueryEngine

Justifications:

  • Cette fonctionnalité dans le QueryEngine est nécessaire dans ce milestone pour permettre la navigation hiérarchique.

Interface de navigation hiérarchique

User Stories: #12

Modules: HierarchicalNavigationUI

Total: À estimer; sous toutes réserves amène à la fin janvier 2012.

MILESTONE 3

Emphase: Amélioration à la recherche

Permettre de rechercher dans des champs spécifiques des fiches

Initialement, seulement le titre d’une fiche ou sa description.

User Stories: #106

Modules: QueryEngine

Permettre de restreindre la recherche à des vocabulaires de classifications, incluant les opérations AND, OR et surtout NOT

Inclut d'implanter un sélecteur de termes de vocabulaire efficace.

User Stories: #109

Modules: QueryEngine

Générer des documents de description OpenSearch pour le QueryEngine

User Stories: #65

Modules: QueryEngine

Total: À estimer; sous toutes réserves amène à la fin février 2012.

MILESTONE 4

Emphase: Workflow

Intégrer l’édition à un workflow

Le workflow spécifie le profil d’application, et sauve la fiche modifiée. Le but est principalement de se familiariser avec le module workflow.

User Stories: #29

Modules: Workflow

Justifications:

  • Valider l’intégration du module workflow d’ORI-OAI assez tôt pour ne pas écrire une grande quantité de code “jetable” pour l’intégration.

Total: À estimer; sous toutes réserves amène à la mi-mars 2012.

MILESTONE 5

Emphase: Édition et validation

Édition d’une fiche LOM

Sauvegarde d’une fiche dans un datastream LOM (NativeRecord)

User Stories: #57

Modules: MetadataEditor

Conversion Métamodèle => Dublin Core Qualifié

User Stories: #130

Modules: Metadata

Justifications: Nécessaire pour sauvegarder les fiches LOM créées localement dans Fedora. Il est plus simple de créer et maintenir la conversion Metamodèle -> DC, ainsi on aura "gratuitement" au moins un DC raisonnable pour tous les formats.

Intégrer un validateur systématique au moissonnage et à l'exportation

La validation peut se faire une fois sauvegardé dans Fedora plutôt qu'en pré-traitement.

User Stories: #34

Modules: MetadataValidator

Justifications:

  • Assure de trouver les bugs dans notre propre code lors du développement.
  • Nécessaire pour pouvoir prendre certaines choses pour acquises une fois le moissonnage complété.

Générer un schéma pour le validateur LOM à partir d'un document de profil d'application

La validation peut se faire une fois sauvegardé dans Fedora plutôt qu'en pré-traitement.

User Stories: #34, #53

Modules: ApplicationProfile, MetadataValidator

Intégrer un éditeur d’identité

Au moins les données de base et les photos

User Stories: #31

Modules: IdentityEditor

Total: À estimer; sous toutes réserves amène à la mi-avril 2012.

MILESTONE 6

Emphase: Améliorations à la recherche (2e)

Trier les résultats de recherche par pertinence

Rendre le score disponible.

User Stories: #42, #2 Modules: QueryEngine, TripleStore

Permettre de restreindre la recherche aux ressources ayant une ou des contributions d'identités appartenant à une organisation en particulier

Inclut d'implanter un sélecteur d'identité efficace.

Modules: QueryEngine, Identity

Créer une interface d'affichage d'une ressource permettant de naviguer vers d'autres ressources du même auteur

User Stories: #4

Modules: Metadata, QueryEngine

Total: À estimer; sous toutes réserves amène à la fin mai 2012.

MILESTONE 7

Emphase: Équivalences entre les vocabulaires

Implanter la résolution des identités de vocabulaires

Inclut d’aller chercher les vocabulaires externes....

User Stories: #10

Modules: Vocabulary

Justifications:

  • Pour permettre le téléchargement et la mise à jour automatique des vocabulaires externes

Permettre de restreindre la recherche à des vocabulaires de classifications, et exploitant les équivalences à un niveau

User Stories: #10

Modules: QueryEngine, Vocabulary

Permettre de restreindre la recherche à des vocabulaires de classifications, et exploitant les équivalences récursives à deux niveaux

User Stories: #10

Modules: QueryEngine, Vocabulary

Interface de navigation hiérarchique rendant visible les équivalences

User Stories: #11

Modules: QueryEngine, Vocabulary, HierarchicalNavigationUI

Total: À estimer, sous toutes réserves amène à la fin juin 2012.

MILESTONE 8

Emphase: Gestion des collections

Gestion des collections

Permettre d’enregistrer une requête comme collection, et y associer des métadonnées (exposition au moissonage, auteur, description, etc.)

User Stories: #12, #96, #85

Modules: QueryEngine, RegistryManager, HierarchicalNavigationUI

Total: À estimer; sous toutes réserves amène à la fin juillet 2012.

MILESTONE 9

Emphase: Édition en lot

Permettre d'appliquer une action à un groupe de ressources retournées par le QueryEngine

Une seule action pour commencer: Effacement (avec confirmation, bien sûr...)

User Stories: #6, #35

Modules: QueryEngine, Workflow (idéalement)

Implanter une première version du vrai éditeur de groupe

Implanter le Cas initial de l'éditeur de groupe, supportant seulement l'ajout de classification et le retrait de classification communes d'un groupe de ressources.

User Stories: #35

Modules: QueryEngine, MetadataEditor, MetadataGroupEditor

Total: À estimer; sous toutes réserves amène à la fin août 2012.

MILESTONE 10

Expositon du dépôt au moissonnage externe et à la recherche fédérée

Exposition OAI-PMH de tout le dépôt

5j

En format DC et LOM. Vérifier le fonctionnement des effacements.

User Stories: #65

Modules: OAI_PMHService -> oaiprovider

Exposition du QueryEngine en SQI

User Stories: #65, #46

Modules: SQIService?

Justifications: Pour Globe

Exposition du QueryEngine en SRU

User Stories: #65, #19

Modules: SRUService?

Justifications: #19 est dans le Groupe A

Intégrer les gabarits au workflow pour l’édition des fiches

User Stories: #36

Modules: Workflow

Total: À estimer; sous toutes réserves amène à la mi-septembre 2012.

MILESTONE 11

Emphase: Permettre une meilleure intégration à différents systèmes externes.

Obtenir un rapport des liens brisés

User Stories: #18

Exposer dans l’interface les résultats de recherche et de navigation hiérarchique en RSS

User Stories: #43

Modules: SearchUI, HierarchicalNavigationUI

Justifications: Pour fils RSS

Conversion Résultats du Query Engine et Métamodèle => OpenDocument

User Stories: #54

Modules: Metadata, HierarchicalNavigationUI

Justifications: Pour les tirés à part

Moissonner le CCDMD

  • Permet de tester l’araignée HTML, et surtout de valider que la généralisation du Harvester tient la route. L'univers ne parle pas OAI-PMH.

User Stories: #49

Modules: Harvester

Interface pour communiquer avec un contributeur/administrateur du dépôt d’origine à partir d’une fiche

User Stories: #68

Modules: Metadata

Total: À estimer; sous toutes réserves amène à la fin septembre 2012.

MILESTONE 12

Emphase: Corrections aux fiches

Intégrer une première correction sémantique des fiches : Ajouts de termes de classification

User Stories: #20, #129, #76

Modules: Metadata, FedoraRepository

Justifications:

  • Les petites collections ayant souvent des classifications maison qui ne sont pas disponibles informatiquement, permet de classer des fiches moissonnées autrement que par les correspondances de vocabulaires.
  • Permet de gérer efficacement les remplacements de fiches moissonnées sans perdre les classifications manuelles dans nos collections.

Intégrer une seconde correction sémantique des fiches: Gestion des commentaires

User Stories: #12

Modules: Metadata, FedoraRepository

Justifications:

  • #12 est dans le groupe A...

Tirer toutes les descriptions de champs dans l’éditeur de métadonnées des profils d’application

Le nom du champ, sa description, etc.

User Stories: #7

Modules: MetadataEditor

Total: À estimer; sous toutes réserves amène à la fin novembre 2012.

User Stories non-touchés par les éléments du plan de travail plus haut

Non traité à cette étape:

Attachments

0.9.8 © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.73027 sec.)