Vous êtes ici : Accueil / TECHNICAL PAGES / Archives / description_woda

description woda

Gestion des Problem-Reports, Actions et Documents pour T4


Ce document décrit les phases et opérations permettant de stocker des problem-reports, actions et documents dans les trois bases de données dédiées à cet effet.




Pour tester l'équivalent exact du problem-report, allez à l'URL:

http://obswww.unige.ch/woda/cgi/woda/TEST_problem_report

Vos demandes seront traitées par t4 d'une manière adéquate.
Mais pas considérées comme vrais problèmes.
Donc testez!




Les URLs des Home Pages sont:

Sur le site de Genève:
Problem-reports
 http://obswww.unige.ch/woda/cgi/woda/t4_problem_report
Documentations
 http://obswww.unige.ch/woda/cgi/woda/t4_doc
Actions
 http://obswww.unige.ch/woda/cgi/woda/t4_action
avec l'équivalent sur le site de La Silla
Problem-reports
 http://ouranos/woda/cgi/woda/t4_problem_report
Documentations
 http://ouranos/woda/cgi/woda/t4_doc
Actions
 http://ouranos/woda/cgi/woda/t4_action

Un mot à propos des bases de données

Les bases de données sont de type woda.

La Home Page de chaque base offre les possibilités de recherche et d'affichage suivantes:
  1. Recherche selon mot clé. On trouve ainsi immédiatement une documention si un des champs de la base contient ce mot clé.
  2. Recherche avancée selon mot clé. On peut spécifier quels champs doivent ou ne doivent pas contenir certains mots clé.
  3. Recherche des documents récents.
  4. Recherche selon un No d'enregistrement.
  5. Recherche selon combinaison. Ex: tous les "manuels de référence" pour "coralie".
  6. Affichage de toutes les entrées de la base.
  7. Affichage des entrées selectionnées selon des valeurs prédéfinies pour certains champs de la base. Ex: tous les "manuels de référence"
  8. Idem mais en cumulant plusieurs champs. Ex: tous les "manuel de référence" et tout ce qui concerne "coralie".
Les problem-reports sont géré sous la forme de documents mis graduellement à jour.
  1. Une phase de description (déclaration du problème)
  2. Une phase de prise en charge (par une personne du support)
  3. Une phase de résolution du problème (par cette même personne)
Comme la base de données woda permet d'envoyer des mails lors de chaque modification d'un document de la base. Ce sytème a été retenu pour la gestion des problem-reportsqui sont dès lors comparables à d'autres types de documents.

Remarque: posséder 3 bases permet:
  1. faciliter la gestion des bases
  2. simplifier l'apprentissage du fonctionnement des bases (déjà en usage pour Giraffe et Harps)

Un mot à propos du Miroring

Le site WEB de La Silla est un miroir de celui de Genève. Chaque jour ou sur demande le site de La Silla est comparé à celui de Genève.
  • Les fichiers du site de Genève sont copié à La Silla s'il sont nouveaux ou plus récents.
  • Les fichiers présents sur le site de La Silla et absents sur le site de Genève sont supprimés à La Silla.

Après un miroring des sites, les 2 sites sont strictement identiques (contenus et dates des fichiers)

Le but de cette opération est de permettre un acces local rapide sur le Site de La Silla.

Les inconvénients sont:
  1. Les mises à jour ne peuvent se faire que sur le site de Genève
  2. Les mises à jour ne sont visibles qu'après un miroring (delai maximum 24h)

WWW Genève

WWW La Silla





Un mot à propos des documentations

Le miroring du site de Genève sur celui de La Silla permet un acces rapide et sûr de la documentation même si le réseau entre La Silla et le reste du monde est mort.

Le miroring ne suit pas les liens et c'est pour cette raison que les documentations doivent être placées dans l'espace qui est miroré (miroiré?).

L'emplacement est:

/net/dejanire/export/diskA/WWW/Public/La_Silla/BDD_documentation

Ce directory est libre d'acces. À vous de créer votre directory afin que vos documentations restent votre propriété.

La documentation qui sera mis de la base de données des documentations doit d'abord être déposée dans cet espace.

Si vous créez un document à La Silla, vous devez le rapatrier sur Genève avant de l'introduire dans la base de données.

Quelques exemples de copie:
  •  cp ~albert/check_cdrom.txt /net/dejanire/export/diskA/WWW/Public/La_Silla/BDD_documentation/albert/
  •  scp -C ~albert/check_cdrom.txt dejanire:/export/diskA/WWW/Public/La_Silla/BDD_documentation/albert/
  •  cpdir ~albert/rsbselect/ /net/dejanire/export/diskA/WWW/Public/La_Silla/BDD_documentation/albert/doc_pour_uifs/

Dernier mot à propos des entrées dans une base de données

Du au miroring des sites, chaque nouvelle entrée doit être faite sur le site de Genève.

Les pages permettant l'entrée de données dans une des bases de données commutent automatiquement sur le site de Genève si une tentative d'introduction est faite sur le site de La Silla.

Il faut donc être attentif au fait qu'après une introduction dans une base de données, vous êtes sur le site de Genève. A vous de retourner sur le site de La Silla si vous désirer consulter des documents par exemple.


Fin du préambule... Passage aux actes



1) PROBLEM-REPORTS


Ce chapître décrit les étapes successives de la gestion d'un problème.

Les acteurs typiques apparraissant dans les lignes suivantes sont:
  1. L'observateur (qui n'est pas nécessairement observateur!). C'est lui qui subit les effets d'un problème, d'un bug, etc... Il ne peut résoudre ce problème et donc rédige un "problem-report".
  2. Le groupe t4-support. C'est le groupe des personnes chargées du dévelopement et de la maintenance de la station. Ce groupe est accessible par Email à l'adresse t4-support@obs.unige.ch
  3. Le responsable. C'est un des membres du groupe t4-support qui prend personellement en charge le suivit et la résolution du problème. C'est lui qui rédigera une solution lorsque le problème sera résolu,
Description d'une cas typique:



Apparition d'un problème

...

Détection par l'observateur

WEB

http://obswww.unige.ch/woda/cgi/woda/t4_problem_report.cgi/Add

L'observateur rédige le problem-report et fournit les indications suivantes:

  • Description courte
  • Date
  • Environnement ("non significatif", "coralie", "camera", "grb")
  • Description
  • Attachements facultatifs (1 fichier texte, 2 fichiers image)
  • Email


Le status du problem-report est posé à "New" automatiquement

Click!
Mail automatique à:
  • observateur
  • t4-support

Le mail contient la description courte et longue et l'url du rapport.
Il donne les infos au groupe support pour la suite des évênements et indique à l'expéditeur que son rapport a été envoyé.

...

Accusé de reception par le responsable


Un des membres du groupe t4-support se reconnait comme responsable pour ce problème.

Il entame les actions suivantes le plus rapidement possible.
De cette façon les autres membres du groupe t4-support sont "libérés" de cette tâche.

WEB

http://obswww.unige.ch/woda/cgi/woda/t4_problem_report.cgi/Edit...

 (Rem: l'url exact est fournit dans le mail original)
Il édite le rapport original en fournissant les informations suivantes:

  • Change le status de "New" à "Working on"
  • Donne son Email (Email support)

Click!
Mail automatique à:
  • observateur
  • t4_support

Le mail informe l'expéditeur et le groupe t4-support que la gestion du problème est prise en charge par la personne qui a fournit son Email.

...

Résolution du problème par le responsable

Le problème est résolu. Les action à suivre sont les suivantes:

WEB

http://obswww.unige.ch/woda/cgi/woda/t4_problem_report.cgi/Edit...

 (Rem: l'url exact est fournit dans le mail original)
Les responsable édite le rapport original en fournissant les informations suivantes:

  • Change le status de "Working on" à "Solved"
  • Contexte (Hardware, Observation Software, Network, ...)
  • Solution
  • Attachement de type image facultatif
  • URL si la solution est décrite dans un document WEB

Click!
Mail automatique à:
  • observateur
  • t4_support

Le mail informe l'expéditeur et le groupe t4-support que le problème est résolu. Il donne l'url du rapport final qui contient la description originale et la solution avec tout les attachements.






2) ACTIONS


Ce chapître décrit une solution de gestion des actions prévues ou demandées.

Elle joue le rôle d'un "pense-bête" pour la personne chargée de faire l'action.

Il faut remarquer que la personne qui demande une action (le demandeur) n'est pas forcément celle qui doit la faire (l'exécuteur).

Les actions ne sont visibles que par un acces volontaire de la base.
Il n'y a aucune notion d'agenda ni de mail automatique.

Description d'un cas typique:



Une action doit être faite

WEB

http://obswww.unige.ch/woda/cgi/woda/t4_action.cgi/Add

Le demandeur donne les informations adéquates:
  • Description courte
  • Status ("A faire", "Commencé", "Terminé")
  • Email de la personne chargée de l'action (l'exécuteur)
  • Email de la personne qui demande l'action (le demandeur)
  • Un sujet
  • Un niveau de préparation ("doit être préparé à Genève", "doit être finalisé à La Silla", ...)
  • date limite de préparation
  • date limite de finalisation
  • description
  • Attachements facultatifs (1 fichier texte, 2 fichiers image)

Click!
Mail automatique au:
  • Demandeur
  • Exécuteur

Le mail contient la description courte et informe les deux parties qu'une action est demandée



L'action est faite

WEB

http://obswww.unige.ch/woda/cgi/woda/t4_action.cgi/Edit...

L'exécuteur passe le status de cette action à "terminé"

Click!
Mail automatique au:
  • Demandeur
  • Exécuteur

Le mail informe que l'action a été faite
Remarque: L'action peut être supprimée de la base







3) DOCUMENTATIONS


Ce chapître décrit la manière d'introduire une documentation.

Les documentations peuvent être de plusieurs types:
  1. Document simple local (il tient en seul fichier)
  2. Document composé local (il est fait de plusieurs attachements)
  3. Mémo (il n'y a pas de document, le texte est tapé directement dans la base de donnée)
  4. Acces à un ensemble de documents local (on donne l'URL d'un directory, exemple pour les messages d'erreurs)
  5. Document externe (on donne un URL)


Description d'un cas typique:



On entre un document dans la base de données

WEB

http://obswww.unige.ch/woda/cgi/woda/t4_doc.cgi/Add

La personne qui rentre un document fournit un url ou tape directement un mémo (il peut contenir des ordres HTML).
Il est important de donner des mots clés précis dans la description courte car c'est eux qui permettront une recherche efficace du document.

Click!























Luc Weber - Observatoire de Genève - 28 janvier 2004