Projet de Biométrie - air.imag.frair.imag.fr/images/d/da/Cahier_des_Charges_signature.pdf ·...

Cahier des charges

POLYTECH’GRENOBLE

Projet de Biométrie

2010-2011

Acquisition et Reconnaissance

de signatures

Biométrie - Reconnaissance de signatures

Table des révisions

Version : Auteur : Date : Contenu : 0.1 Magalie GIMENES 21-02-2011 Création du document et

établissement du plan 0.2 Giang THAI QUYNH 21-02-2011 Présentation du projet 0.3 Christopher MANTOVAN 22-02-2011 Requis non fonctionnels 0.4 Magalie GIMENES 01-03-2011 Changement du plan, Ressources

matérielles

0.5 Giang THAI QUYNH 05-03-2011 Tableau des risques

0.6 Sophie CAMUS 10-03-2011 Description de l’IHM

1.0 Magalie GIMENES 12-03-2011 Mise en forme et corrections

1.1 Sara AMEZIANE 13-03-2011 Corrections

2.0 Toute l’équipe 14-03-2011 Validation du document


Table des matières

I. Présentation ___________________________________________________________ 4

A. Le projet __________________________________________________________________ 4

B. Les ressources physiques _____________________________________________________ 4

C. Les ressources matérielles ____________________________________________________ 5

II. Organisation du projet ___________________________________________________ 6

A. Dates et durées du projet _____________________________________________________ 6

B. Diagramme de Gantt prévisionnel ______________________________________________ 7

C. Diagramme de Gantt réel _____________________________________________________ 7

D. Cycle de vie du projet ________________________________________________________ 8

III. Tableau de risques ____________________________________________________ 10

IV. Description de l’IHM __________________________________________________ 11

V. Requis non fonctionnels de développement _________________________________ 15

A. Les performances de reconnaissance __________________________________________ 15

B. Les temps de calcul _________________________________________________________ 15

C. Contraintes physiques : l’acquisition des points __________________________________ 15


I. Présentation

a. Le projet Notre projet consiste à effectuer l’acquisition de signature numérique à partir d’un

DSTouch (écran de Nintendo DS) et de faire une étude de faisabilité sur la reconnaissance de celle-ci. Pour ce faire, nous étudierons plusieurs méthodes pour comparer différentes signatures et sauvegarder ces dernières dans plusieurs fichiers (selon l’identifiant donné) pour constituer une base de données pour notre système.

L’acquisition de la signature à partir du DSTouch se fait à l’aide du logiciel Arduino: seront ainsi sauvegardées les coordonnées de points qui serviront à la comparaison.

Pour la démonstration du projet, nous réaliserons une interface simple qui affichera la signature effectuée sur le DSTouch ainsi que le résultat de comparaison de celle-ci avec les signatures enregistrées dans le système.

b. Les ressources physiques Nous sommes tous issus de la classe RICM5 de l’école Polytech’Grenoble. Nous avons séparé le projet en cinq parties:

Montage du dispositif (électronique) Récupération directe des données de l’Arduino à notre programme Construction de l’algorithme de comparaison de signature Construction de l’IHM du programme Ecriture des documents

Nous avons réparti les membres de notre groupe comme suit :

AMEZIANE Sara :

Construction de l’algorithme de comparaison de signature : o mise en place de l’algorithme d’égalisation du nombre de points entre les

signatures o calcul du tableau de vecteurs à partir des points

CAMUS Sophie :

Chef de projet Responsable du wiki et des documents Construction de l’IHM du programme

CAZAUX Jérémy

Récupération directe des données de l’Arduino à notre programme

DARAS Gautier

Montage du dispositif (électronique) Récupération directe des données de l’Arduino à notre programme (aide)

GIMENES Magalie

Chef de projet Construction de l’algorithme de comparaison de signature :

o Algorithme de comparaison de vecteurs (aide) MAGNAT Nicolas

Construction de l’algorithme de comparaison de signature : o Algorithme de comparaison de vecteurs


MANTOVAN Christopher

Construction de l’algorithme de comparaison de signature : o mise en place des parsers d’écriture et lecture à partir des fichiers de points

THAI QUYNH Giang

Construction de l’algorithme de comparaison de signature : o mise en place des parsers d’écriture et lecture à partir des fichiers de vecteurs

c. Les ressources matérielles Pour établir la communication entre le DSTouch et nos machines, nous disposions de:

Deux Arduino (un Arduino Uno et un Arduino Duellanove)

Des fils électriques

Deux DSTouch

Deux nappes de connexion pour l’écran

Trois modules de communication entre les nappes et l’Arduino

Deux surfaces de montages pour connecter plusieurs fils entre eux

Deux câbles USB

Nous remercions Polytech’Grenoble, Mr Besacier et Mr Donsez pour nous avoir fourni le

matériel nécessaire à notre projet.


II. Organisation du projet

a. Dates et durées du projet Ce projet a débuté le 24 Janvier 2011 et doit être évalué le 14 Mars 2011. Comme vous

pouvez le voir sur le diagramme prévisionnel, nous avons cru qu’il fallait finir le projet pour le

21 Février 2011 ce qui nous a permis de prévoir les retards que nous avons eu à cause de

problèmes, pour la majorité, matériels. De plus, la dernière semaine avant l’évaluation est

réservée aux examens de seconde session ce qui explique pourquoi nous n’avons pas pu

travailler durant ce temps-là.

Nos ressources n’étaient disponibles pour le projet qu’à 10% du temps à cause de cours et

autre travaux sur lesquels nous devions travailler en plus de ce projet. Par conséquent, nous

disposions de 4h par personne et par semaine de travail sur ce projet. Nous disposions aussi

de deux heures par semaine en salle réservée pour se retrouver et faire le point sur l’état

d’avancement de notre projet. Nous avons donc convenu d’utiliser ces heures pour nous

réunir afin de discuter quelques minutes sur le projet (ce qui a déjà été fait et ce qu’il reste à

faire).


b. Diagramme de Gantt prévisionnel

c. Diagramme de Gantt réel


d. Cycle de vie du projet Pour le projet, nous avons donc suivi le modèle incrémental comme suit:

Durant l’étude préliminaire, nous avons étudié quel modèle serait le plus adapté pour la

comparaison de deux signatures, le modèle image (comparaison pixel à pixel) ou le modèle

vectoriel (comparaison des vecteurs de direction).

Durant l’analyse des besoins, nous avons étudié quels composants seront nécessaires à la

finalisation de notre projet. Par exemple, nous avons choisi la forme que devra avoir à notre

IHM, comment le montage électrique sera fait ainsi que comment répartir au plus juste les

ressources physiques et matérielles.

Durant les phases standards de développement, de tests unitaires et d’intégration, nous

avons suivi plusieurs incréments définis comme suit:

Incrément 1 Développement de l’IHM

Incrément 2 Développement de l’écriture, lecture de fichiers de points

Incrément 3 Développement de l’écriture, lecture de fichiers de vecteurs

Incrément 4 Développement de la transformation d’une liste de points en liste de

vecteurs avec suppression ou ajout de point au besoin dans la cas de la comparaison

Incrément 5 Développement de l’algorithme de comparaison de deux listes de

vecteurs de tailles égales

Incrément 6 Développement de l’algorithme d’acquisition automatique des points à

partir de l’Arduino


Durant la phase de livraison, nous allons préparer la présentation orale de notre produit ainsi

que finaliser les autres livrables (cahier des charges, wiki, dossier de conception).


III. Tableau de risques

Description du risque Impacts Probabi

lité

Niveau

d'impact

Poids Actions préventives

engagées

Risques matériels

Panne de machine Le développeur dont la machine

est tombée en panne ne peut plus

travailler

1 3 3 Prévoir de mobiliser tout le

matériel disponible

(ordinateur fixe, ordinateur

potable de tierce personne,

…)

Panne/perte d’Arduino Sans le matériel clé du projet,

l’équipe ne peut pas avancer le

travail ni les tests

3 4 8 Prévoir la commande d’ un 2e

Arduino pour le projet

Problème de branchement

d’Arduino

Retard dans l’avancement du

projet

2 3 6 Affecter au moins 2

personnes sur cette partie du

projet

Risques humains

Développeur indisponible

(maladie, départ, …)

Travail ajouté pour les autres

développeurs

2 3 6 Définir à l’avance la

répartition du travail de

chacun pour que même en

étant séparés, nous puissions

travailler quand même

Personne détenant

l’Arduino étant indisponible

Le développeur qui détient

l’Arduino pour ses tests, reste

injoignable

4 2 8 Avancer le travail et envoyer

une personne chez-lui pour

récupérer l’Arduino

Risques logiciels

Echec de l’installation du

logiciel pour récupérer les

données d’Arduino

Pas de communication possible

entre l’Arduino et l’ordinateur

3 4 8 Prévoir l’installation sur

différents OS

Erreur dans la récupération

des données d’Arduino

Les données récupérées ne sont

pas toutes cohérentes

3 4 4 Mettre plus de développeurs

sur le débogage pour

comprendre l’origine des

données erronées


IV. Description de l’IHM L’IHM est basique. Elle comporte deux onglets permettant de passer du mode d’acquisition d’une

signature au mode de comparaison entre deux signatures quelconques.

Voici l’apparence du mode d’acquisition :

Le bouton « Start » permet de lancer l’acquisition physique de la signature, et de manière évidente,

le bouton « Stop » permet de stopper l’acquisition. Il est possible d’enregistrer une signature acquise

en entrant le nom qu’on souhaite lui donner et en appuyant sur le bouton « Save ». Comme nous le

montre cette capture d’écran d’acquisition, nous avons une représentation graphique de la signature

obtenue.

En ce qui concerne l’interface du mode comparaison, voici une capture :


Cet écran ci nous permet, en premier lieu de fixer le seuil d’acceptation de l’algorithme de

comparaison grâce à un slider. Ensuite, l’écran est séparé en deux. La partie de gauche correspond au

chargement d’une première signature enregistrée. Il suffit de saisir le nom de cette signature et

d’appuyer sur le bouton « Charger ». Automatiquement, la représentation de cette signature

apparaitra. La seconde partie sur la droite, permet de sélectionner une seconde signature. Celle-ci

peut provenir de la saisie immédiate sur l’Arduino en lançant une acquisition (bouton « Start ») et en

la stoppant (bouton « Stop »), ou peut aussi provenir du chargement d’un fichier signature en base

(bouton « Charger un fichier à comparer »). Une fois les deux signatures chargées (en base et à

comparer), la comparaison se lance grâce au bouton « Compare ». Il est possible de consulter le

résultat via la ligne de texte (accepté/refusé et l’erreur).

Les deux écrans possèdent un bouton « Signature ». Celui-ci permet d’afficher les deux graphiques

suivants :


Le premier graphe permet de consulter les taux FAR et FRR en fonction de la valeur seuil choisie.

Le second graphe permet de consulter le taux FAR en fonction du taux FRR.

(cf cours de Tatouage et Biométrie pour plus de détails.)


Au final, nous obtenons de cette ihm, l’arbre des taches suivant :


V. Requis non fonctionnels de développement

a. Les performances de reconnaissance Comme toute application de reconnaissance pour la sécurité, il est nécessaire de fixer une valeur seuil d’acceptation/rejet. Cette valeur doit permettre au mieux de deviner si la personne qui est en train de s’identifier est la bonne personne ou non. Cependant, son utilisation est assez compliquée, puisque si la valeur est trop basse, on aura tendance à ne jamais rejeter les bonnes personnes, mais également d’accepter les mauvaises personnes. À l’inverse, si la valeur est trop haute, on acceptera moins les mauvaises personnes, mais on aura aussi tendance à refuser les bonnes personnes, ce qui peut poser de très gros problèmes. Dans l’utilisation des signatures, nous avons considéré qu’il restait plus important que la personne soit toujours acceptée, au risque d’accepter également les mauvaises identités.

b. Les temps de calcul Le temps de décision sur une signature doit être assez court, au maximum 5 secondes. Il est

donc nécessaire de faire attention aux différents traitements que l’on doit réaliser sur les

données.

c. Contraintes physiques : l’acquisition des points

i. Les limites d’un Arduino

L’information importante d’une signature est les différents points qui la composent. De par le changement de monde entre physique et numérique, il est nécessaire de discrétiser la signature en une suite de point. Cette discrétisation pouvant entraîner une perte d’information de forme, il faut que celle-ci soit la plus petite possible, ce qui pourra permettre de décider de l’authenticité d’une signature. Cependant, cette discrétisation dépend au final du matériel utilisé, à savoir l’Arduino. Nous avons donc essayé d’avoir un temps entre chaque acquisition de point le plus petit possible. En plus de garder un maximum d’information sur la forme, cela nous permet également d’avoir un nombre de point suffisant pour caractériser une signature. Après plusieurs tests, il s’avère qu’une signature normale compte environ 50 points.

ii. Obtenir le même nombre de points pour les signatures

Il est évident que pour comparer deux signatures en considérant le format de vecteur, il est nécessaire d’avoir un nombre de points égaux entre la signature de référence et la signature testée. Il existe deux manières pour régler ce problème :

Échantillonnage des points : on prend des points suivant un pas d’échantillonnage, défini par le nombre de points de la signature de référence et de la signature testée

Interpolation : Les algorithmes pour pallier aux limites (voir plus loin)

Pour aller plus loin dans cette contrainte physique de discrétisation, il est possible de réussir à diminuer son impact sur nos algorithmes. En effet, grâce à de nombreux algorithmes, il est possible de déduire des coordonnées de points entre plusieurs points reliés. On peut ainsi penser à deux techniques :

L’interpolation linéaire de point : on considère que tous les points placés sur le segment entre deux points appartiennent à la signature. Il est ainsi simple d’augmenter le nombre de points d’une signature.


L’interpolation par des splines : l’avantage des splines est la considération non plus d’un segment mais d’une courbe, qui aura donc tendance à épouser bien mieux une signature, qui est justement une courbe et non une suite de segment

Dans la version actuelle, ces méthodes d’interpolation n’ont pas été appliquées.

Projet de Biométrie - air.imag.frair.imag.fr/images/d/da/Cahier_des_Charges_signature.pdf ·...

Documents

Transcript of Projet de Biométrie - air.imag.frair.imag.fr/images/d/da/Cahier_des_Charges_signature.pdf ·...