Groupe de projet : PLOVIER STEPHANE SCHOUTEETEN KEVIN MATHIEU REMY Matire : MC3 SI Date : 25 fvrier 2008

DOSSIER DE RECETTE PROJET : TICKET-MANAGER HELPDESK

HISTORIQUE DES EVOLUTIONS

Version 1.0 Date 25/02/2008 Auteurs PLOVIER STEPHANE Pour Groupe de Projet Pages/Parties Tout Description Dossier de recettes : liste les fonctionnalits ralises ou non, testes ou no

PREAMBULE
On appelle recette (ou essais de rception) la vrification de la conformit de l'ouvrage la demande formule dans le dossier valid de conception gnrale. Nous allons donc reprendre la liste des besoins, dfinie dans le cahier des charges dtaill et commenter ce qui a t ralis ou non.

SOMMAIRE
1. Rappels sur le contexte 2. Objectifs 2.1 Besoins 2.2 Contraintes et risques 2.3 Rappel sur l'architecture 2.4 Terminologie utilise 2.5 Notion de livrable 3. Organisation des tests 3.1 Objectifs qualit atteindre 3.2 Dmarche 3.3 Documents de rfrence 4. Les phases de test 4.1 Les tests informatiques (unitaires, assemblage,...) pour chaque fonctionnalit attendue 4.2 Le contrle de fabrication et de conformit (par unit de traitement) 4.3 L'homologation technique & mtier 5. Rles des intervenants lors des tests 5.1 Les intervenants et leur rle 5.2 Rpartition des tches entre les intervenants

1) Rappels sur le contexte Ce cahier de recette liste les fonctionnalits ralises et/ou non ralises de l'application Ticket Manager (PHP + Oracle) que nous avons ralis tout au long du semestre. Ce dossier s'appuie sur le dossier de tests, ce dernier regroupe l'ensemble des tests effectus sur l'application --> Ce qui fonctionne contre ce qui est revoir. 2) Objectifs 2.1 Besoins Dvelopper une application nomme Helpdesk (baptis Ticket Manager pour nous), logiciel servant grer les problmes logiciels et matriels dun parc informatique. La liste des besoins a t cite dans le dossier de spcifications logicielles de manire plus dtaille, nous ne mettons ici qu'un rsum de chaque fonctionnalit. (Voir dossier nomm : Dossier-Spec-Projet-MC3-Groupe-Plovier-Mathieu.doc) Ticket-Manager aura les fonctionnalits suivantes : COTE DEMANDEUR 1) Saisie Ticket 2) Consultation des tickets Affichage dun ticket expdi 3) Modification des Tickets 4) Systme daffichage des tickets du Demandeur COTE OPERATEUR 5) Systme daffichage des tickets en arrive pour loprateur 6) Traitement des tickets 7) Commenter un ticket 8) Systme de transfert dun ticket 9) Systme de validation de ticket 10) Crer un module de recherche multicritres COTE RESPONSABLE DE SERVICE 11) Module de gestion des configurations de lapplication Modification / Ajout / Suppression 12) Module de statistiques 13) Gestion des oprateurs Modification / Ajout / Suppression Gestion des comptences logicielles / matrielles 14) Gestion des types de problmes 15) Systme daffichage des tickets en arrive (de loprateur) pour le Responsable de service (Voir suite page suivante ...)

AUTRES FONCTIONNALITES 16) Module de connexion la base de donnes 17) Module de gestion des utilisateurs pour lapplication 18) Module de vision densemble des statistiques, cration de Diagrammes 19) Design Attirant de lapplication + navigation simple et intuitive 20) Gestion des erreurs sous forme de messages explicites 21) Oprateur : Fonction de recherche 2.2 Contraintes et risques Le futur logiciel aura un aspect type site Web pour la navigation et sera reli une base de donnes Oracle ; dans un premier temps nous effectuerons nos essais sur une base de donnes MySQL. Cette base de donnes servira au stockage et la gestion des donnes de notre application. CONTRAINTES au niveau du projet en soi : _ Groupe de projet de 3 personnes _ Date limite de dlivrance du projet (papiers + application) -> 19 mars CONTRAINTES de dveloppement : _ Utiliser Oracle pour la base de donnes _ Utiliser PHP5 pour les classes de connexion et PHP4/5 pour le reste du dveloppement de l'application _ Crer 3 profils utilisateurs diffrents _ Grer l'aspect scurit pour viter les piratages _ Ticket Manager doit tre compatible Linux / Windows / Mac Os RISQUES : _ Risque dans les dlais de travail (attention au Diagramme de Gantt) _ Risques dans la rpartition des tches au sein du groupe _ Risques lis la programmation objet 2.3 Rappel sur l'architecture utilise pour le dveloppement de l'application Lapplication Ticket Manager sera dveloppe sous Linux avec Apache2 / PHP5 / MySQL. Une fonctionnalit de notre code permettra de switcher facilement de moteur de base de donnes (entre MySQL et Oracle). Lapplication sera ensuite teste sur les ordinateurs de lIUT (sous Windows XP) avec la base de donnes sous Oracle (Oracle Client 10g). 2.4 Terminologie utilise La terminologie est lensemble de mots techniques appartenant une science, une activit professionnelle, ou un groupe social. Voici les abrviations que nous sommes susceptibles dutiliser :

Projet Nom utilis englobant tous les livrables dfinir et effectuer pendant les 2 mois (Dossiers divers, application) Application Notre futur Logiciel de Gestion de Tickets = Ticket Manager

Groupe de Projet Nous-mmes, les tudiants ralisant le projet

Tche projet

une action raliser durant le

2.5 Notion de livrable Livrable : Tout composant matrialisant le rsultat de la prestation de ralisation (production ou TMA) la DSI, cest dire toute production mise ... Nos livrables [PAPIER] sont, pour le Projet Ticket Manager : _ Le CDC dtaill [valid par le professeur] _ Le dossier de spcifications logicielles [valid par le professeur] _ Les Nombreux Diagrammes UML et Merise (MCD, MLD, CreateTable, Use-Case, etc.) [Valid par le professeur] _ Le prsent dossier de Recette (incluant les Tests) Nos livrables [AUTRES] sont, pour le Projet Ticket Manager : _ Notre Application PHP5/Oracle 3) Organisation des tests Nous avons dvid de lier ici dossier de recette et dossier de tests, ces deux dossiers tant troitement lis de par la notion de Livrable Final Ticket Manager RC1

3.1 Objectifs qualit atteindre Notre application Ticket Manager devra rpondre aux besoins prcdemment noncs ciavant (voir partie 2.1). Pour lapplication, il sera ncessaire davoir une gestion des erreurs, un affichage correct sous tous navigateurs. Pour complter ces critres de qualit, un jeu de tests pour toutes les fonctionnalits de notre application (le prsent dossier) ainsi quun manuel utilisateur et un manuel technique. Le principal critre de qualit passe dj par tous ces points, mais aussi, pour quun tel projet soit abouti, il faut galement un suivi approfondi de celui-ci, en passant par des diagrammes de Gantt Prcis (prvisionnel et dfinitif) on peut ajouter un organigramme des tches pour un rsultat satisfaisant. 3.2 Dmarche Pour cette phase du projet, nous allons tester toutes les fonctionnalits dveloppes au sein de notre application Ticket Manager, une par une et rpondre de son bon fonctionnement ou non (ou erreurs grer par exemple). Nous allons donc dcrire ce qui a t produit et ce qui ne la pas t, ce qui fonctionne bien et ce qui a besoin de rvisions . Nous allons, pour ce faire, reprendre chaque fonctionnalit de notre application, la nommer et lui ajouter un tableau possdant plusieurs caractristiques. Exemple : ----------------------------------------------------------------------------------------------------------------Nom fonctionnalit : Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif] -----------------------------------------------------------------------------------------------------------------

3.3 Documents de rfrence Deux grands documents de rfrence pour le moment : Cahier des Charges [CDC-Projet-MC3-SI.doc] Dossier de Spc. Logicielle [Dossier-Spec-Projet-MC3-SI-Groupe-Plovier-Mathieu.doc] Et bien sur merci Google pour nos recherches multiples lors de ce projet. 4) Les phases de test Ici commence les phases de tests pour les fonctionnalits de notre Application Ticket Manager, nous allons bien videmment traiter chaque aspect sous chaque navigateur 4.1 Les tests informatiques (unitaires, assemblage,...) pour chaque fonctionnalit attendue Cot Demandeur Nom fonctionnalit : 1 ) Saisie Ticket Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 2 ) Consultation des tickets Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Affichage dun ticket expdi

Nom fonctionnalit : 3 ) Modification des Tickets Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 4 ) Systme daffichage des tickets du Demandeur Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Cot Oprateur Nom fonctionnalit : 5 ) Systme daffichage des tickets en arrive pour loprateur Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 6 ) Traitement des tickets Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 7 ) Commenter un ticket Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 8 ) Systme de transfert dun ticket Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 9 ) Systme de validation de ticket Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 10 ) Module de recherche multicritres Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Cot Responsable de Service Nom fonctionnalit : 11 ) Module de gestion des configurations de lappl ication Modification / Ajout / Suppression Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 12 ) Module de statistiques Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 13 ) Gestion des oprateurs Modification / Ajout / Suppression Gestion des comptences logicielles / matrielles Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 14 ) Gestion des types de problmes Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif] Nom fonctionnalit : 15 ) Systme daffichage des tickets en arrive (de loprateur) pour le Responsable de service Teste [Oui/Non] :

Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Autres Fonctionnalits Nom fonctionnalit : 16 ) Module de connexion la base de donnes Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 17 ) Module de gestion des utilisateurs pour lapplic ation Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 18 ) Module de vision densemble des statistiques, cration de Diagrammes Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 19 ) Design Attirant de lapplication + navigation simple et Intuitive Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

Nom fonctionnalit : 20 ) Gestion des erreurs sous forme de messages exp licites Teste [Oui/Non] : Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif] Nom fonctionnalit : 21 ) Oprateur : Fonction de recherche Teste [Oui/Non] :

Problme daffichage [Oui/Non] Problme Algorithmique [Oui/Non] Gestion des erreurs [OK/AR (=A Revoir)] Rponds-t-elle aux critres attendus ? [Oui/Non] Commentaire ? [Facultatif]

4.2 Le contrle de fabrication et de conformit (par unit de traitement) Cette tape est fondamentale. Par cette dernire, le client vrifie la conformit du logiciel aux spcifications qu'il a approuves. D'abord, on contrle la conformit sur tests avec la recette provisoire . On procde des jeux d'essais qui permettent le contrle des fonctions du logiciel et de dtecter les erreurs de programmation. De l, peut dcouler un cahier de recette qui expose les modalits de correction en cas de rserves du client. Les parties ont donc, la possibilit de dresser un procs-verbal de rception provisoire qui pourra tre impos par le contrat. LA PHASE DE TESTS CI DESSUS ENTRE EN CONSIDRATION DANS CE PARAGRAPHE. |_| Voir la liste des bugs complte |_| Avons nous respect la liste des besoins ? --> Oui Avons nous atteint les objectifs principaux ? --> Oui Avons nous respect les cots prvus initialement ? --> Oui car pas d'argent circulant ... Le client est-il satisfait ? (ici Mr Mger) --> ? 4.3 L'homologation technique & mtier Notre application Ticket Manager devra tre homologue par les 2 cts du projet : Homologation au niveau du code, au niveau des fonctionnalits dveloppes. Cette tape est valide si les deux tapes prcdentes sont valides galement.

5) Rles des intervenants lors des tests 5.1 Les intervenants et leur rle _ Rmy, dveloppeur de l'application vrifie si son travail est conforme ... _ Stphane et Kevin, testeurs rciproquement de 'application sous MySQL et sous Oracle ... _ Mr Mger, supervise le tout et rceptionnera le projet final. 5.2 Rpartition des tches entre les intervenants Stphane notifie des erreurs en les notant ... Rmy les corrige au sein du code ... Kevin vrifie les contraintes d'intgrit de la base de donne ainsi que sa bonne conformit ... Mr Mger regarde avec attention le tout ...