Différences

Ci-dessous, les différences entre deux révisions de la page.

--- certif:procedure:develop:gestionprojeqtor [2026/06/02 16:22] – [Qualification des tickets] nicolas
+++ certif:procedure:develop:gestionprojeqtor [2026/09/30 15:36] (Version actuelle) – [Étapes de traitement] nicolas
@@ Ligne 1: / Ligne 1: @@
 |{{:undo-2.svg?30|}} [[certif:do#procedures|Retour au Dossier Organisationnel]]||
-|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\  [[:certif:procedure:develop:gestionversion]]\\ [[:certif:procedure:develop:gestionsvn]]\\ [[:certif:procedure:develop:gestionsdepotgit]] \\ [[:certif:procedure:develop:proceduremiseaucoffredescodes]]|
+|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[:certif:procedure:develop:gestionversion]]\\ [[:certif:procedure:develop:chainequalificationlivraison]]|
-====== Gestion des tickets ======
+====== Proc#8 - Gestion des tickets ======
 ===== Informations qualité =====
-|**Suivi des modifications majeures** |juin 2026 - Nicolas Marchand - Refonte complète\\ 5 mars 2015 - Nicolas Marchand - Création du document \\ 27 novembre 2015 - Nicolas Marchand - Evolution vocabulaire, non-gestion du temps dans projeQtOr \\ 27 novembre 2015 - Valentin Barrere - Correction orthographique \\ 02 aout 2017 - Nicolas Marchand - Portage sur DoKuWiKi & Evolutions ajout "A tester"|
-|**Suivi des approbations** | ce fait sur la plateforme de cartographie fonctionnelle|
-|**Objet** |L'objet de ce document est d'indiquer la procédure à suivre lors de la vie d'un ticket|
-|**Destinataires** |**- Validation des modifications : ** Gérant \\  **- Approbation du document** : Equipe dev & Equipe Ass|
-===== Qualification des tickets =====
+^Suivi des modifications majeures^^^
-==== Types de tickets ====
+^Date^Auteur^Modifications^
+|5 mars 2015|Nicolas MARCHAND|Création du document|
+|27 novembre 2015|Nicolas MARCHAND|Évolution du vocabulaire, non-gestion du temps dans ProjeQtOr|
+|27 novembre 2015|Valentin BARRÈRE|Correction orthographique|
+|2 août 2017|Nicolas MARCHAND|Portage sur DokuWiki et évolutions : ajout de « À tester »|
+|Juin 2026|Nicolas MARCHAND|Refonte complète|
-=== Bug ===
+|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=8|Cartographie fonctionnelle – fiche de la procédure]]|
+|**Objet** |Définir comment qualifier un ticket (type et niveau de gravité) et les étapes de son traitement.|
+|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement et équipe assistance|
+|**Origine** |Ce document correspond à l'ancien élément ProjeQtOr Document #04 « Procédure de prise en charge d'un ticket ».|
-**Un comportement incorrect ou inattendu du logiciel. Quelque chose qui devrait fonctionner ne fonctionne plus ou fonctionne mal.**
+\\
-== Quand utiliser ce type ? ==
+===== Qualification des tickets =====
-^ Situations ^
+==== Types de tickets ====
-| Le logiciel produit un résultat incorrect |
-| Une action déclenche une erreur ou un plantage |
-| Un affichage ne correspond pas à la réalité |
-| Une donnée est perdue, dupliquée ou corrompue |
-| Un comportement a changé sans raison apparente (régression) |
-== Critères de classification ==
+^ Type ^ Quand l'utiliser ? ^ Info clé à fournir ^ Priorité ^ Traitement ^ En savoir plus ^
+| **Bug** | Le logiciel produit un résultat incorrect ou inattendu | Étapes de reproduction + résultat observé et résultat attendu | Bloquant → Majeur → Mineur | Investigation immédiate si bloquant |{{ :certif:procedure:develop:types_tickets_bug.pdf |}}\\ {{ :certif:procedure:develop:types_tickets_bug.odt |}} |
+| **Évolution** | La fonctionnalité demandée n'existe pas encore | Besoin métier + cas d'usage + critères d'acceptation | Selon impact métier et charge estimée | Planification sprint / roadmap | {{ :certif:procedure:develop:types_tickets_evolution.pdf |}}\\ {{ :certif:procedure:develop:types_tickets_evolution.odt |}}|
+| **Amélioration** | La fonction existe mais pourrait être mieux conçue | Usage concerné + problème concret + gain estimé | Faible à moyenne selon contexte | Backlog, trié par valeur |{{ :certif:procedure:develop:types_tickets_amelioration.pdf |}}\\ {{ :certif:procedure:develop:types_tickets_amelioration.odt |}} |
+| **Question / Assistance** | L'utilisateur cherche à comprendre comment faire | Ce qu'il essaie de faire + ce qu'il a tenté | Non applicable | Réponse par l'assistance, pas par les développeurs | {{ :certif:procedure:develop:types_tickets_question-assistance.pdf |}}\\ {{ :certif:procedure:develop:types_tickets_question-assistance.odt |}} |
-^ Critère ^ Valide ? ^
+=== Arbre de décision ===
-| Reproductible de façon fiable | ✓ obligatoire |
-| Résultat observé ≠ résultat attendu | ✓ obligatoire |
-| Lié à un comportement existant du logiciel | ✓ obligatoire |
-| Pas une demande de nouvelle fonctionnalité | ✓ obligatoire |
-== Informations indispensables à fournir ==
-^ Information ^ Description ^
-| Étapes de reproduction | Séquentielles : 1, 2, 3… |
-| Résultat observé | Ce qui se passe réellement |
-| Résultat attendu | Ce qui devrait se passer |
-| Environnement | Navigateur, version logiciel, env (prod/test) |
-| ID ou données de test | Identifiant adhérent, exercice, etc. |
-| Capture d'écran ou message d'erreur | Si disponible |
-== Pièges fréquents ==
-^ Piège ^
-| "Ça marche pas" sans décrire le comportement |
-| Confondre avec une évolution non encore développée |
-| Signaler un bug sur une fonctionnalité jamais définie |
-| Mélanger plusieurs bugs dans un seul ticket |
-| Omettre les données de test nécessaires à la reproduction |
-== Exemples ==
-^ ✗ À éviter ^ ✓ Bon exemple ^
-| **Objet :** Bug adhérents \\ //Dans les adhérents ya un truc bizarre. Des fois ça marche des fois pas. C'est urgent.// | **Objet :** Filtre statut non réinitialisé après navigation — liste adhérents \\ //Filtre "statut actif" reste appliqué après retour liste. Résultat : 247 affichés au lieu de 183. Reproduction : Adhérents > filtrer actif > ouvrir fiche #1042 > retour liste. Firefox 124, prod v2.4.1.// |
-== Confusion fréquente ==
-<note warning>
-Si la fonctionnalité n'a jamais existé, ce n'est **pas un bug** — c'est une **évolution** à développer.\\
-**À distinguer de :** Évolution (fonctionnalité absente), Amélioration (fonctionne mais mal conçue)
-</note>
-----
-=== Évolution ===
-**Une demande de nouvelle fonctionnalité absente du logiciel. Le logiciel fonctionne comme prévu — l'utilisateur veut quelque chose de plus.**
-== Quand utiliser ce type ? ==
-^ Situations ^
-| La fonctionnalité demandée n'existe pas encore |
-| Un nouveau besoin métier émerge |
-| Un processus manuel pourrait être automatisé |
-| Une intégration avec un autre outil est souhaitée |
-| Un nouveau type de données doit être géré |
-== Critères de classification ==
-^ Critère ^ Valide ? ^
-| La fonctionnalité n'existe nulle part dans le logiciel | ✓ obligatoire |
-| Exprime un besoin métier nouveau ou non couvert | ✓ obligatoire |
-| Implique un développement significatif | ✓ obligatoire |
-| Doit être priorisé et planifié | ✓ obligatoire |
-== Informations indispensables à fournir ==
-^ Information ^ Description ^
-| Besoin métier | Le pourquoi — pas seulement le quoi |
-| Cas d'usage concret | Qui fait quoi, quand, dans quel contexte |
-| Critères d'acceptation | Mesurables : oui/non, valeur, comportement |
-| Périmètre fonctionnel | Ce qui est inclus ET ce qui est exclu |
-| Impact si non réalisé | Temps perdu, risque, coût |
-== Pièges fréquents ==
-^ Piège ^
-| "Refaire entièrement" le module : trop vague |
-| Mélanger 5 demandes dans un seul ticket |
-| "Améliorer" sans dire en quoi concrètement |
-| Omettre le contexte métier (le pourquoi) |
-| Ne pas préciser les critères de succès |
-== Exemples ==
-^ ✗ À éviter ^ ✓ Bon exemple ^
-| **Objet :** Amélioration événements \\ //Il faudrait améliorer la gestion des événements, c'est vraiment pas pratique pour nos bénévoles.// | **Objet :** Export CSV des inscrits depuis la fiche événement \\ //Pouvoir exporter la liste des inscrits à un événement en CSV depuis la fiche événement, pour alimenter notre outil de relance. Actuellement : export manuel copier-coller. Impact : 2h/mois perdues par la secrétaire.// |
-== Confusion fréquente ==
-<note warning>
-Si la fonctionnalité existe mais est mal conçue, c'est une **amélioration**. Si elle n'a jamais existé, c'est une **évolution**.\\
-**À distinguer de :** Amélioration (existe déjà mais perfectible), Bug (fonctionne de façon incorrecte)
-</note>
-----
-=== Amélioration ===
-**Une fonctionnalité existante qui fonctionne correctement, mais qui pourrait être plus fluide, plus ergonomique ou plus efficace. Le besoin est couvert — l'expérience peut être optimisée.**
-== Quand utiliser ce type ? ==
-^ Situations ^
-| La fonction existe et fonctionne, mais est lente à utiliser |
-| Le nombre de clics ou d'étapes est trop élevé |
-| L'interface est source d'erreurs fréquentes |
-| La terminologie ou l'organisation est confuse |
-| Un usage récurrent mériterait d'être simplifié |
-== Critères de classification ==
-^ Critère ^ Valide ? ^
-| La fonctionnalité concernée existe déjà | ✓ obligatoire |
-| Elle fonctionne correctement (pas de bug) | ✓ obligatoire |
-| L'objectif est de gagner en efficacité ou clarté | ✓ obligatoire |
-| Peut porter sur l'ergonomie ou la performance | ✓ obligatoire |
-== Informations indispensables à fournir ==
-^ Information ^ Description ^
-| Fonctionnalité existante identifiée | Module, écran, action précise |
-| Problème d'usage concret | Ce qui est pénible, source d'erreur |
-| Proposition ou direction souhaitée | Ce qu'on voudrait à la place |
-| Fréquence d'usage | Combien de fois par jour/semaine/mois |
-| Gain estimé si amélioré | Temps, erreurs, clics économisés |
-== Pièges fréquents ==
-^ Piège ^
-| "C'est moche" ou "C'est lent" sans données concrètes |
-| Ne pas quantifier le gain potentiel |
-| Confondre avec un bug si le comportement est incorrect |
-| Demander une refonte complète sans périmètre défini |
-| Oublier de préciser la fréquence d'utilisation |
-== Exemples ==
-^ ✗ À éviter ^ ✓ Bon exemple ^
-| **Objet :** Interface pas très belle \\ //L'interface est pas très belle et c'est lent des fois. Vous pourriez améliorer ça ?// | **Objet :** Réduction du nombre de clics — saisie adhérent \\ //La création d'un adhérent requiert 12 clics sur 4 écrans. Regrouper les champs obligatoires sur un seul écran réduirait à 4 clics. Constat sur 3 secrétaires : ~15 min/jour perdues. Risque d'erreur de saisie élevé.// |
-== Confusion fréquente ==
-<note warning>
-Si la fonctionnalité fonctionne de façon incorrecte, c'est un **bug**. Si elle n'existe pas encore, c'est une **évolution**.\\
-**À distinguer de :** Bug (comportement incorrect), Évolution (fonctionnalité absente)
-</note>
-----
-=== Question / Assistance ===
-**L'utilisateur ne sait pas comment utiliser une fonctionnalité existante, ou croit à tort que c'est un bug. Ce n'est ni un bug ni une demande — c'est un besoin d'accompagnement.**
-== Quand utiliser ce type ? ==
-^ Situations ^
-| L'utilisateur ne trouve pas comment faire quelque chose |
-| Il pense que le logiciel bug mais ce n'est pas le cas |
-| Il cherche à confirmer un comportement normal |
-| Il a besoin d'une explication ou d'un tutoriel |
-| La documentation ne couvre pas son cas |
-== Critères de classification ==
-^ Critère ^ Valide ? ^
-| Le logiciel fonctionne correctement | ✓ obligatoire |
-| L'utilisateur ne maîtrise pas la fonctionnalité | ✓ obligatoire |
-| Résolu par de l'aide, pas du développement | ✓ obligatoire |
-| Peut révéler un manque de documentation ou d'UX | à vérifier |
-== Informations indispensables à fournir ==
-^ Information ^ Description ^
-| Ce que l'utilisateur essaie de faire | L'objectif, pas le problème technique |
-| Ce qu'il a déjà tenté | Les actions déjà réalisées |
-| L'écran ou module concerné | Contexte de navigation |
-| Son niveau de connaissance | Novice, intermédiaire, expert |
-== Pièges fréquents ==
-^ Piège ^
-| Traiter comme un bug alors que ça fonctionne |
-| Transmettre aux devs sans qualification préalable |
-| Ne pas détecter le bug réel derrière la question |
-| Ignorer que la question révèle un problème d'UX |
-== Exemples ==
-^ ✗ À éviter ^ ✓ Bon exemple ^
-| **Objet :** Ça marche pas les cotisations \\ //Ça marche pas pour les cotisations, je comprends pas. Pouvez-vous regarder ?// | **Objet :** Bouton Générer grisé — appel de cotisations 2025 \\ //Comment générer l'appel de cotisations pour l'exercice 2025 ? Menu Cotisations > Appels > bouton Générer grisé. Exercice 2025 créé et validé. Tentative : clic sur Générer sans résultat.// |
-== Confusion fréquente ==
-<note warning>
-Une question peut cacher un vrai **bug** ou révéler un besoin d'amélioration de l'**ergonomie**. Toujours investiguer avant de classifier.\\
-**À distinguer de :** Bug (si le comportement est vraiment incorrect), Amélioration (si l'UX est systématiquement confuse)
-</note>
-----
-=== Synthèse — Les 4 types de tickets ===
-== Tableau comparatif ==
-^ Type ^ Quand l'utiliser ? ^ Info clé à fournir ^ Priorité ^ Traitement ^
-| **Bug** | Le logiciel produit un résultat incorrect ou inattendu | Étapes de repro + résultat observé vs attendu | Bloquant → Majeur → Mineur | Investigation immédiate si bloquant |
-| **Évolution** | La fonctionnalité demandée n'existe pas encore | Besoin métier + cas d'usage + critères d'acceptation | Selon impact métier et charge estimée | Planification sprint / roadmap |
-| **Amélioration** | La fonction existe mais pourrait être mieux conçue | Usage concerné + problème concret + gain estimé | Faible à moyenne selon contexte | Backlog, trié par valeur |
-| **Question / Assistance** | L'utilisateur cherche à comprendre comment faire | Ce qu'il essaie de faire + ce qu'il a tenté | Non applicable | Réponse assistance, pas devs |
-== Arbre de décision ==
   - Le logiciel produit un résultat **incorrect ou inattendu** ? → **Bug**
@@ Ligne 240: / Ligne 37: @@
   - L'utilisateur **cherche à comprendre** comment utiliser le logiciel ? → **Question / Assistance**
-<note tip>
+==== Niveaux de gravité ====
-Si aucune condition n'est remplie → demander des précisions à l'utilisateur avant de classifier.
-</note>
-==== Les éléments nécessaires ====
+^ Niveau ^ Situation ^ Contournement ^ Délai cible ^ Traitement ^ En savoir plus ^
+| **Bloquant** | Travail totalement à l'arrêt, aucun contournement | Aucun | < quelques heures | Investigation immédiate, escalade |{{ :certif:procedure:develop:fiche_bloquant.pdf |}}\\ {{ :certif:procedure:develop:fiche_bloquant.odt |}}|
+| **Majeur** | Fonctionnalité dégradée, contournement pénible | Pénible ou risqué | < quelques jours | Priorité haute |{{ :certif:procedure:develop:fiche_majeur.pdf |}}\\ {{ :certif:procedure:develop:fiche_majeur.odt |}}|
+| **Mineur** | Bug limité, contournement simple | Simple et sans risque | Prochain sprint | Planification normale |{{ :certif:procedure:develop:fiche_mineur.pdf |}}\\ {{ :certif:procedure:develop:fiche_mineur.odt |}}|
+| **Amélioration / Évolution** | Pas de bug, confort ou nouvelle capacité | Non applicable | Selon roadmap | Backlog, par valeur |{{ :certif:procedure:develop:fiche_amelio_evol.pdf |}}\\ {{ :certif:procedure:develop:fiche_amelio_evol.odt |}}|
-===== Etapes de traitement =====
+=== La règle du contournement ===
-{{:certif:procedure:develop:doc_00_etapes_projeqtor.jpg|}}
-^  ^Responsable^Type de ticket^Urgence^
+^ Contournement disponible ? ^ Niveau ^
-|**Niveau 1 (plus urgent)**|Nicolas|Problème sur base Client|Bloquant|
+| Aucun contournement possible | **Bloquant** |
-|**Niveau 2**|Nicolas|Problème sur base Client|Urgent|
+| Contournement pénible, lent ou risqué | **Majeur** |
-|**Niveau 3**|Nicolas|Problème sur base Client|Non Urgent|
+| Contournement simple et sans risque | **Mineur** |
-|**Niveau 4**|Nicolas|Dysfonctionnement|Bloquant|
+| Pas de bug : le logiciel fonctionne | **Amélioration / Évolution** |
-|**Niveau 5**|Nicolas|Dysfonctionnement|Urgent|
-|**Niveau 6**|Nicolas|Dysfonctionnement|Non Urgent|
-==== Etape 1 : Référencement d'une demande ====
+=== Arbre de décision ===
-=== Procédure vis-à-vis du client ===
+  - Est-ce que personne (ou presque) ne peut travailler normalement ? → **Bloquant**
+  - Y a-t-il un contournement simple et sans risque ? → Non = **Majeur**
+  - L'impact est limité et le contournement facile ? → **Mineur**
+  - Le logiciel fonctionne correctement mais pourrait être mieux ? → **Amélioration / Évolution**
-La première action à faire vis-à-vis du client est d'identifier sur quelle version du logiciel il travaille. S'il n 'est pas sur la dernière version disponible, il lui est demandé de bien vouloir le mettre à jour, puis de vérifier si le problème persiste.
+<note tip>
+En cas de doute entre deux niveaux, choisir le plus élevé et laisser l'assistance ajuster après investigation.
+</note>
-AUCUNE assistance sur les fonctionnalités n'est faite sur les versions antérieures du logiciel à partir du moment où une mise à jour est publiée. Seules l'assistance à l'évolution de la version et/ou l'aide à la correction conséquente à un problème dû à une version antérieure seront prises en compte.
+=== Le piège le plus courant ===
-Chaque cas sera étudié et une réponse sera émise au client dans tous les cas. Celle-ci sera obligatoirement tracée au travers de la procédure d'assistance
+<note warning>
+**« Urgent » n'est pas un niveau de gravité.** C'est une émotion. Le niveau se fonde sur l'impact métier réel et sur l'existence d'un contournement, pas sur la pression ressentie par l'utilisateur.
+</note>
-=== Cas où une correction est nécessaire ===
+===== Étapes de traitement =====
-Si lors d'une demande d'assistance, d'une formation ou de test, un problème nécessitant une action sur le code ou les fichiers annexes est repéré, la procédure est la suivante :
+{{ :certif:procedure:develop:proc8_traitement_ticket.svg |Étapes de traitement d'un ticket}}
-== Cas 1 : Problème impliquant uniquement une correction du code ==
+Les numéros sont ceux du schéma.
-  - Lancer une session  [[https://projet.logeas.fr/view/main.php|Projeqtor]]
+^ N° ^ Étape ^ Qui ^ Ce qui se passe ^ Suite ^
-      * Sélectionner le Projet et la sous-version correspondant à la prochaine version [[certif:procedure:develop:gestionversion|[PROC-Nflog-5 : gestion des versions]]]
+| 1 | Saisie du ticket | Utilisateur | L'utilisateur décrit sa demande ou son problème. | 2 |
-      * Dans "Travail\Bugs", créer un nouveau Ticket et le remplir comme indiqué plus loin en tenant compte des spécificités listées ci-dessous :
+| 2 | Qualification | Assistance | L'assistance détermine le type du ticket et son niveau de gravité (voir « Qualification des tickets »). | 3 |
-        * __**Projet**  = **Prochaine sous-version**__  (par défaut si le projet est sélectionné)
+| 3 | Infos suffisantes ? | Assistance | L'assistance vérifie que le ticket contient les informations nécessaires. | Oui : 5 \\ Non : 4 |
-        * __**Type de ticket = "Anomalie / Bug issue - origine client" ou "Anomalie / Bug issue - origine autre"**__
+| 4 | Demande d'informations | Utilisateur | L'utilisateur reçoit une demande de précisions et complète son ticket. | 1 |
-        * __**Référence externe = Numéro de ticket OTRS s'il existe. **Exemple ://Ticket#2015022310000059//__
+| 5 | Type de ticket ? | Assistance | Le ticket est orienté selon son type. | Question / Assistance : 6 \\ Bug : 11 \\ Amélioration / Évolution : 10 |
-        * __**Responsable = vide**__
+| 6 | Escalade si nécessaire | Assistance | L'assistance traite la question et la transmet au niveau supérieur si besoin. | 7 |
-      * NB : Dans le cas où la demande est un doublon par rapport à une demande existante, on se contentera de compléter le ticket existant en ajoutant la référence à la demande du client.
+| 7 | Réponse de l'assistance | Utilisateur | L'utilisateur reçoit la réponse. | 8 |
-  - Revenir sur le ticket OTRS
+| 8 | Résolu ? | Utilisateur | L'utilisateur indique si la réponse règle sa demande. | Oui : 9 \\ Non : 1 |
-      * Envoyer une réponse à l'utilisateur
+| 9 | Clôture | Utilisateur | Le ticket est clos comme résolu. | fin |
-      * Faire une note en indiquant en titre "PROJEQTOR –BUGS#XX" et le texte de votre choix
+| 10 | Analyse et planification | Équipe | L'équipe analyse la demande d'amélioration ou d'évolution et la planifie. | 13 |
+| 11 | Analyse et qualification | Développeur | Le développeur analyse le bug. | 12 |
-== Cas 2 : Problème impliquant uniquement une décision du groupe de travail EPUdF-Logeas ==
+| 12 | Infos suffisantes ? | Développeur | Le développeur vérifie qu'il a de quoi reproduire et corriger. | Oui : 13 \\ Non : 7 |
+| 13 | Développement | Développeur | Correction ou réalisation. | 14 |
-  - Lancer une session Projeqtor
+| 14 | Tests de recette | Équipe | Tests des fonctions concernées et de non-régression. | 15 |
-      * Sélectionner le Projet et la sous-version correspondant à la prochaine version [certif:procedure:develop:gestionversion|PROC-Nflog-5 : gestion des versions]
+| 15 | Tests passés ? | Équipe | Décision à l'issue des tests. | Oui : 16 \\ Non : 13 |
-      * Dans "Journaux des revues\Questions", créer un nouveau Ticket et le remplir comme indiqué plus loin en tenant compte des spécificités listées ci-dessous :
+| 16 | Déploiement en production | Développeur | La version corrigée est mise en production. | 17 |
-        * __**Projet = Prochaine sous-version**__  (par défaut si le projet est sélectionné)
+| 17 | Notification et clôture | Utilisateur | L'utilisateur est informé, le ticket est clos. | fin |
-        * **Type de ticket = "Assistance - demande d'explication ''EPUdF''" ou "Assistance - demande de correction ''EPUdF''"**
-        * **Référence externe = Numéro de ticket OTRS s'il existe. **Exemple ://Ticket#2015022310000059//
-        * **Responsable = "Jean-Marc DEGON & Michel HAFFNER"**
-      * NB : Dans le cas où la demande est un doublon par rapport à une demande existante on se contentera de compléter le ticket existant en ajoutant la référence à la demande du client.
-  - Revenir sur le ticket OTRS
-      * Envoyer une réponse à l'utilisateur
-      * Faire une note en indiquant en titre "PROJEQTOR – TICKET #XX" et le texte de votre choix (obligatoire, mais sans intérêt ..)
-== Cas 3 : Demande d'évolution du logiciel ==
-  - Lancer une session  [[https://projet.logeas.fr/view/main.php|Projeqtor]]
-      * Sélectionner le Projet et la sous-version correspondant à la prochaine version [[certif:procedure:develop:gestionversion|[PROC-Nflog-5 : gestion des versions]]]
-      * Dans "Travail\Evolutions", créer un nouveau Ticket et le remplir comme indiqué plus loin en tenant compte des spécificités listées ci-dessous :
-        * __**Projet = Prochaine sous-version**__  (par défaut si le projet est sélectionné)
-        * **Type de ticket = "Assistance - demande d'évolution ''**
-        * **Référence externe = Numéro de ticket OTRS s'il existe. **Exemple ://Ticket#2015022310000059//
-        * **Responsable = vide**
-      * NB : Dans le cas où la demande est un doublon par rapport à une demande existante, on se contentera de compléter le ticket existant en ajoutant la référence à la demande du client.
-  - Revenir sur le ticket OTRS
-      * Envoyer une réponse à l'utilisateur
-      * Faire une note en indiquant en titre "PROJEQTOR – TICKET #XX" et le texte de votre choix
-=== Information générique sur la saisie d'un ticket ===
-|Description|Projet|Selon le cas|
-|Description|Type de ticket|Selon le cas|
-|Description|Nom|**Donner un titre compréhensible** |
-|Description|Référence externe|Selon le cas|
-|Description|Urgence|Non utilisé|
-|Description|Date de création|Automatique|
-|Description|Émetteur|Automatique, nom de l'utilisateur connecté \\ NB : Chaque utilisateur doit avoir une session distincte|
-|Description|Demandeur|Non utilisé|
-|Description|Origine|Non utilisé|
-|Description|Ticket en doublon|Utilisation postérieure|
-|Description|Contexte|A remplir si connu|
-|Description|Produit|Indiquez le produit|
-|Description|Version d'origine|Indiquer la version du produit où a été constaté le problème, si connue|
-|Description|Description|Indiquer le détail du problème|
-|Traitement|Activité de planning|Ne pas utiliser|
-|Traitement|Etat|Mettre "Assigné"|
-|Traitement|Responsable|Assigner le ticket à la personne qui doit s'en occuper, ce qui envoie un mail à la personne|
-|Traitement|Criticité|Selon le cas|
-|Traitement|Priorité|Selon le cas|
-|Traitement|Échéance initiale,; actuelle|Non utilisé|
-|Traitement|Travail estimé, restant|Non utilisé|
-|Traitement|Pris en charge, Fait, Clos|Automatique|
-|Traitement|Version cible|Non utilisé|
-|Avancement|   |Sans objet|
-|Élément prédécesseur / Successeur|   |Généralement Sans Objet|
-|Élément liés|   |Ne pas utiliser|
-|Fichiers attachés|   |Ajouter les documents, bases … qui permettent de mettre en lumière le problème et de tester la solution|
-|Notes|   |Permet d'ajouter des éléments textuels|
-\\
-===== Etape 2 : Prise en charge par le dev d'une demande =====
-Lancer une session [[https://projet.logeas.fr/view/main.php|Projeqtor]]
-  - Sélectionner le ticket correspondant
-  - Le basculer en "En cours"
-  - Initialiser le **Traitement\****R****esponsable**  s'il ne l'est pas
-===== Etape 2bis : Prise en charge par le dev d'une demande (Echec) =====
-Lancer une session [[https://projet.logeas.fr/view/main.php|Projeqtor]]
-  - Sélectionner le ticket correspondant : **"Travail\****Bugs****"**
-      * Compléter le ticket dans la partie "**Traitement**":
-        * Initialiser le **Traitement\Responsable**  s'il ne l'est pas
-|Activité de planning|Initialisé à la création du ticket|
-|**Etat** |**Mettre "Assigné"** |
-|**Responsable** |**Changer le responsable pour l'assigner à quelqu'un d'autre** |
-|Criticité|Non utilisé|
-|Priorité|Non utilisé|
-|Échéance initiale,; actuelle|Non utilisé|
-|Travail estimé, restant|Non utilisé|
-|Pris en charge, Fait, Clos|Automatique|
-|Version cible|Non utilisé|
-|Résultat|vide|
-  * Enregistrer
-  * Lier les documents, si il y a lieu (base de test, copie …)
-  * Mettre une note si il y a lieu
-===== Etape 3 : Prise en charge par le dev d'une demande (Succès) =====
-Au niveau développement :
-  - Effectuer la correction, la tester
-  - Publier le code sur SVN, en indiquant dans le commentaire le tag du ticket (id=#20)
-==== Au niveau ProjeQtOr ====
-Lancer une session [[https://projet.logeas.fr/view/main.php|Projeqtor]]
-  - Sélectionner le ticket correspondant : **"Travail\****Bug****"**
-      * Compléter le ticket dans la partie "**Traitement**":
-        * Initialiser le Traitement\Responsable s'il ne l'est pas
-|Activité de planning|Initialisé à la création du ticket|
-|**Etat** |**Mettre "FAIT"** |
-|**Responsable** |**ne pas changer** |
-|Criticité|Non utilisé|
-|Priorité|Non utilisé|
-|Échéance initiale,; actuelle|Non utilisé|
-|Travail estimé, restant|Non utilisé|
-|Pris en charge, Fait, Clos|Automatique|
-|Version cible|Non utilisé|
-|Résultat|vide|
-  * Enregistrer
-  * Lier les documents, si il y a lieu (base de test, copie …)
-  * Mettre une note si il y a lieu
-===== Etape 4 : Mise en place d'une version de test (alpha ou beta) =====
-  - Lancer une session [[https://projet.logeas.fr/view/main.php|Projeqtor]]
-  - Dans les tickets sur le projet concerné, cliquer sur le bouton à droite "Mise à jour multiple"
-  - Sélectionner le(s) ticket(s)/activité(s) correspondant à un état "FAIT"
-  - Initialiser le Traitement\Responsable au créateur du ticket
-  - Les basculer en "A TESTER"
-\\
+Pour LoGeAs Web, les étapes 14 à 16 (tests de recette, décision, déploiement) suivent [[:certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]].

Outils

menus et recherche rapide

recherche rapide

statut du site

Outils de la page

meta données pour cette page

Différences