RECONOCIMIENTO DE ROSTRO OSCAR ALEJANDRO ZAPATA ARTEAGA PROGRAMA DE INGENIERIA DE SISTEMAS Y TELECOMUNICACIÓN
FABIÁN ALBEIRO LÓPEZ CASTAÑO PROGRAMA DE INGENIERIA DE SISTEMAS Y TELECOMUNICACIÓN
2012
UNIVERSIDAD CATÓLICA DE PEREIRA COLOMBIA 21/12/2012
1
PROYECTO RECONOCIMIENTO DE ROSTRO
FABIÁN ALBEIRO LÓPEZ CASTAÑO
OSCAR ALEJANDRO ZAPATA ARTEAGA
ASESOR: JULIO CESAR CANO RAMIREZ
UNIVERSIDAD CATÓLICA DE PEREIRA
PROGRAMA DE
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA
2012
2
DEDICATORIA
Primerio damos gracias a Dios por ayudarnos a terminar nuestros objetivos,
nuestro proyecto de grado. A tener un buen conocimiento para lograr la
terminación de este proyecto.
Gracias a los administrativos por colaborarnos con la terminación de nuestro
proyecto de vida, al decano de la facultad el Ingeniero Luis Alejandro Fletscher
Bocanegra, al director del Programa, el ingeniero Juan Luís Arias Vargas.
Hay personas muy especiales que nos marcan para toda la vida, en consejos, en
valores, por la motivación constante que nos ha permitido llegar a ser personas de
bien, pero más que nada en su sabiduría y su voluntad para trasmitirla a nosotros,
y esas personas, con esas grandes cualidades son: Él Ingeniero Luis Eduardo
Peláez Valencia, que es una de las personas que influye la perspectiva de cómo
debe verse la vida y nos enseña a tener objetivos en nuestra profesión y a ser
personas de bien. La Ingeniería Paula Milena Ríos González, excelente
profesional y humana. El Licenciado Jorge Luis Muñoz Montaño, nos dio sabiduría
y ética en nuestra profesión y nuestro querido tutor que fue un guía espiritual, un
guía de sabiduría, un excelente amigo en nuestra carrera profesional, el Ingeniero
Julio César Cano Ramírez.
3
A nuestros padres porque sin ellos no tendríamos un motor de vida y estaríamos a
la deriva en nuestro proyecto de vida, sin ellos no tendríamos formación de
estudio, ya que fueron muchas las desveladas y madrugadas que debieron
realizar por nosotros para que lográramos salir adelante.
A nuestras esposas que nos ayudaron en el estudio, a tenernos paciencia en esas
desveladas o en las madrugadas a continuar estudiando.
A nuestra hermosa universidad Católica de Pereira que amamos tanto y siempre
la llevaremos en nuestros corazón, y pondremos siempre en alto el nombre de la
misma.
4
AGRADECIMIENTOS
Agradecemos a las personas que de alguna manera nos aportaron en
conocimiento, recursos técnicos o financieros y asesoría para lograr llevar este
proyecto a su buen término.
Presbítero Álvaro Eduardo Betancur Jiménez, rector de la Universidad Católica de
Pereira.
Ingeniero Luis Alejandro Fletscher Bocanegra, decano de la faculta de ciencias
básicas e Ingeniería.
Ingeniero Juan Luis Arias Vargas, director de programa de ingeniería de sistemas
y telecomunicaciones.
Ingeniero Julio César Cano Ramírez, facultad de ciencias básicas e ingeniería.
Ingeniero Luis Eduardo Peláez Valencia, facultad de ciencias básicas e ingeniería.
Ingeniería Paula Milena Ríos González, facultad de ciencias básicas e ingeniería.
Licenciado Jorge Luis Muñoz Montaño, departamento de Humanidades.
5
TABLA DE CONTENIDO
DEDICATORIA ........................................................................................................ 2
AGRADECIMIENTOS .............................................................................................. 4
TABLA DE CONTENIDO ......................................................................................... 5
TABLA DE ILUSTRACIONES ................................................................................ 10
TABLA DE CUADROS ........................................................................................... 12
TABLA DE APÉNDICES ........................................................................................ 14
TABLA DE ANEXOS .............................................................................................. 15
RESUMEN ............................................................................................................. 16
SUMMARY ......................................................................................................... 17
INTRODUCCIÓN ................................................................................................... 18
JUSTIFICACIÓN .................................................................................................... 20
1. PRESENTACIÓN DE LA ORGANIZACIÓN ...................................................... 23
1.1. RESEÑA HISTÓRICA............................................................................... 23
1.2. MISIÓN ..................................................................................................... 25
1.3. VISIÓN ...................................................................................................... 25
1.4. VALORES ................................................................................................. 26
1.5. ORGANIGRAMA UCP .............................................................................. 27
1.6. PROPÓSITO ............................................................................................ 28
1.7. PROCESOS DE LA ORGANIZACIÓN...................................................... 32
1.8. FACTORES QUE INFLUYEN EN EL ENTORNO: FACTORES ENTORNO
ECOLÓGICO, MEDIOAMBIENTAL Y DE RECURSOS NATURALES ............... 33
1.9. FACTORES ENTORNO SOCIOCULTURAL ............................................ 33
1.10. FACTORES ENTORNO LEGAL Y POLÍTICO ....................................... 34
1.11. FACTORES ENTORNO SECTORIAL ................................................... 35
6
1.12. FACTORES ENTORNO TECNOLÓGICO ............................................. 35
1.13. OBJETIVOS .......................................................................................... 36
1.13.3 Requerimientos de la Organización. .......................................................... 37
1.14. PLANTILLA DE REQUERIMIENTOS .................................................... 39
1.14.1. Formato de requerimientos 1 .......................................................... 40
1.14.2. Formato de requerimientos 2 .......................................................... 42
1.14.3. Formato de requerimientos 3 .......................................................... 44
1.14.4. Formato de requerimientos 4 .......................................................... 46
1.14.5. Formato de requerimientos 5 .......................................................... 48
1.14.6. Formato de requerimientos 6 .......................................................... 50
1.14.7. Formato de requerimientos 7 .......................................................... 52
1.14.8. Formato de requerimientos 8 .......................................................... 54
1.15. PLANTEAMIENTO DEL PROBLEMA ................................................... 56
1.16. DEFINICIÓN DEL PROBLEMA ............................................................. 56
1.17. VENTAJAS ............................................................................................ 57
1.18. DESVENTAJAS ..................................................................................... 57
1.18.1 Viabilidad del Proyecto............................................................................... 58
1.18.2 Impacto. ..................................................................................................... 58
1.19. MARCO TEORICO ................................................................................ 59
1.20. MARCO CONCEPTUAL ........................................................................ 72
1.21. EL POTENCIAL DEL SOFTWARE ........................................................ 73
1.22. EIGENFACES ....................................................................................... 74
1.23. IMAGEN DIGITAL ................................................................................. 76
1.24. IMAGEN ESTÁTICA .............................................................................. 76
1.25. IMÁGENES VECTORIALES .................................................................. 77
7
1.26. IMÁGENES BITMAPS ........................................................................... 77
1.27. IMAGEN DINÁMICA .............................................................................. 78
1.28. LA RESOLUCIÓN DE UNA IMAGEN .................................................... 78
1.29. TRANSFORMADA DE LA IMAGEN ...................................................... 79
1.30. LA TRANSFORMADA DE HOUGH ....................................................... 79
1.31. SEGMENTACIÓN DE IMÁGENES ........................................................ 79
1.32. UMBRALIZACIÓN ................................................................................. 80
1.33. RECONOCIMIENTO DE PATRONES ................................................... 80
1.34. RECONOCIMIENTO DE ROSTRO ....................................................... 80
CRONOGRAMA DE ACTIVIDADES PLANEADAS ............................................... 81
1.34.1 Metodología a desarrollar. ......................................................................... 82
1.35. PMBOK.................................................................................................. 82
1.35.1. Etapas del proceso de gestión ........................................................ 83
1.36. METODOLOGÍA SCRUM ...................................................................... 84
1.36.1. Las actividades de scrum. ............................................................... 85
1.36.2. Que es scrum. ................................................................................. 86
1.36.3. Premisas principales ....................................................................... 87
1.36.4. Ciclo de trabajo scrum. ................................................................... 88
1.36.5. Roles ............................................................................................... 88
1.37. MODELO PROTOTIPO ......................................................................... 91
1.37.1. Modelo recomendado. .................................................................... 91
1.37.2. Ventajas. ......................................................................................... 92
1.37.3. Etapas. ............................................................................................ 93
CRONOGRAMA DE ACTIVIDADES SCRUM........................................................ 94
1.38. PLANIFICACIÓNSCRUM ...................................................................... 94
8
1.38.1 Estimación del Proyecto Cocomo. ............................................................. 95
1.39. TRES MODOS DE DESARROLLO ....................................................... 95
1.39.1. Orgánico. ........................................................................................ 95
1.39.2. Semi-acoplado. ............................................................................... 96
1.39.3. Empotrado. ..................................................................................... 96
1.40. MODELOS QUE DEFINE COCOMO .................................................... 96
1.40.1. Modelo básico. ................................................................................ 96
1.40.2. Modelo intermedio. ......................................................................... 96
1.40.3. Modelo avanzado. ........................................................................... 97
1.41. FÓRMULAS ........................................................................................... 97
1.4.1.1 Definicion de Requerimientos. ................................................................ 100
1.42. TABLA DE REQUERIMIENTOS .......................................................... 101
MODELACIÓN ..................................................................................................... 102
1.43. CASOS DE USOS REALES ................................................................ 102
1.44. DIAGRAMACION DE CASOS DE USOS ACTORES .......................... 108
1.45. DIAGRAMACION DE CASOS DE USOS ............................................ 109
1.46. DIAGRAMAS DE SECUENCIAS ......................................................... 111
1.47. DIAGRAMAS DE CLASES .................................................................. 112
1.48. PROTOTIPOS ..................................................................................... 113
1.48.1. Prototipo no funcional ................................................................... 113
1.48.2. Prototipo Funcional ....................................................................... 114
1.48.3. Versión Beta ................................................................................. 115
1.48.4. Dispositivo del Hardware .............................................................. 115
1.49. REPRESENTACIÓN DE LA ARQUITECTURA ................................... 123
1.50. METAS Y RESTRICCIONES DE LA ARQUITECTURA ...................... 123
9
1.50.1. Metas. ........................................................................................... 124
1.50.2. Restricciones del Sistema. ............................................................ 124
1.50.2.1 Gestión de la documentación. .............................................................. 125
1.50.2.2 Gestión de versiones del proceso. ........................................................ 126
1.50.2.3 Gestión de incidencias. ......................................................................... 127
1.51. ALTA DE INCIDENCIA ........................................................................ 127
1.52. PROCESO DE INCIDENCIA ............................................................... 128
1.52.1 Aseguramiento de la calidad (SQA). ........................................................ 129
1.52.2 La Gestión de configuraciones del software (GCS). ................................ 131
1.53. PLAN DE LA CONFIGURACIÓN ........................................................ 131
CONCLUSIONES ................................................................................................ 134
Referencia Bibliográfica ....................................................................................... 136
APÉNDICES ........................................................................................................ 141
APÉNDICE A .................................................................................................... 142
ANEXOS .............................................................................................................. 148
ANEXO A ......................................................................................................... 149
ANEXO B ......................................................................................................... 151
10
TABLA DE ILUSTRACIONES
Ilustración 1. Organigrama UCP ............................................................................ 27
Ilustración 2. Sala sistemas UCP ........................................................................... 30
Ilustración 3. Procesos de la organización UCP .................................................... 32
Ilustración 4. Plantilla de Requerimientos .............................................................. 39
Ilustración 5. Imágenes .......................................................................................... 61
Ilustración 6. Caras ................................................................................................ 63
Ilustración 7. Software de Rostro ........................................................................... 66
Ilustración 8. Software de emociones .................................................................... 68
Ilustración 9. Cara .................................................................................................. 71
Ilustración 10. PNUD ............................................................................................. 75
Ilustración 11. Etapas Proceso Gestión ................................................................. 83
Ilustración 12. Scrum ............................................................................................. 85
Ilustración 13. Ciclo Scrum .................................................................................... 87
Ilustración 14. Roles .............................................................................................. 90
Ilustración 15. Modelo Prototipado ......................................................................... 92
Ilustración 16. Diagrama de caso de uso - 0 ........................................................ 102
Ilustración 17. Diagrama de caso de uso - 1 ........................................................ 103
Ilustración 18. Diagrama de caso de uso - 2 ........................................................ 104
Ilustración 19. Diagrama de caso de uso - 3 ........................................................ 105
Ilustración 20. Diagrama de caso de uso - 4 ........................................................ 106
Ilustración 21. Diagrama de caso de uso - 5 ........................................................ 107
11
Ilustración 22. Diagrama de Secuencia ............................................................... 111
Ilustración 23. Diagrama de Clases ..................................................................... 112
Ilustración 24. Prototipo no Funcional .................................................................. 113
Ilustración 25. Prototipo Funcional ....................................................................... 114
Ilustración 26. Versión Beta ................................................................................. 115
Ilustración 27. Dispositivo del Hardware Serial 1 ................................................. 116
Ilustración 28. Dispositivo del Hardware Serial 2 ................................................. 117
Ilustración 29. Dispositivo del Hardware Serial 3 ................................................. 118
Ilustración 30. Dispositivo del Hardware Serial 4 ................................................. 119
Ilustración 31. SCH .............................................................................................. 120
Ilustración 32. Componentes ............................................................................... 121
Ilustración 33. PCB .............................................................................................. 122
Ilustración 34. Monolítica ..................................................................................... 123
Ilustración 35. Reconocimiento Facial ................................................................. 149
Ilustración 36. Programa Keylemon ..................................................................... 151
12
TABLA DE CUADROS
Tabla 1. Requerimiento 1 ....................................................................................... 40
Tabla 2. Requerimiento 2 ....................................................................................... 42
Tabla 3. Requerimiento 3 ....................................................................................... 44
Tabla 4. Requerimiento 4 ....................................................................................... 46
Tabla 5. Requerimiento 5 ....................................................................................... 48
Tabla 6. Requerimiento 6 ....................................................................................... 50
Tabla 7. Requerimiento 7 ....................................................................................... 52
Tabla 8. Requerimiento 8 ....................................................................................... 54
Tabla 9. Actividades Planeadas ............................................................................. 81
Tabla 10. Planificación Scrum................................................................................ 94
Tabla 11. Proyecto Software .................................................................................. 97
Tabla 12. Conductores de Costo ........................................................................... 98
Tabla 13. Resumen de Tabla de Requerimientos ................................................ 101
Tabla 14. Caso de Uso Usuario ........................................................................... 108
Tabla 15. Caso de Uso Sistema .......................................................................... 108
Tabla 16. Caso de Uso Cámara WEB ................................................................. 108
Tabla 17. Tabla de Uso - 0 .................................................................................. 109
Tabla 18. Tabla de Uso - 1 .................................................................................. 109
Tabla 19. Tabla de Uso - 2 .................................................................................. 109
Tabla 20. Tabla de Uso - 3 .................................................................................. 110
Tabla 21. Tabla de Uso - 4 .................................................................................. 110
13
Tabla 22. Tabla de Uso - 5 .................................................................................. 110
Tabla 23. Gestión de la Documentación .............................................................. 125
Tabla 24. Gestión de Versiones del Proceso ....................................................... 126
Tabla 25. Alta de Incidencias ............................................................................... 127
Tabla 26. Proceso de Incidencias ........................................................................ 128
Tabla 27. Aseguramiento de la Calidad ............................................................... 130
Tabla 28. Tabla Gestión de la Configuración ....................................................... 132
Tabla 29. Tabla Gestión de Versiones ................................................................. 133
14
TABLA DE APÉNDICES
APÉNDICE A. TERMINILOGIA 142
15
TABLA DE ANEXOS
ANEXO A. RECONOCIMIENTO FACIAL 149
ANEXO B. PROGRAMA DE KEYLEMON 151
16
RESUMEN
Se propone un desarrollo de un prototipo de software para el reconocimiento de
rostro, el cual será capaz de reconocer rostros a partir de imágenes faciales
capturadas a través de una cámara web. Este desarrollo de software compara
paramétricamente la imagen adquirida con las que estén almacenadas en un
archivo plano que el mismo software crea, se alimenta con imágenes de rostros.
Se pretende desarrollar en la plataforma Microsoft conocida como .NET la cual
sirve para desarrollar software, y hacer el diseño en base al procesamiento de
imágenes “EIGENFACES” (Vision and Modeling Group, Media Laboratory, 1991)
PALABRAS CLAVES: Sistema biométrico, seguridad, control, imagines, rostro,
EIGENFACES, software, metodología. Scrum, estimación, modelos,
requerimientos, diagramas, prototipos, gestión software, incidencias.
17
SUMMARY
We propose a development of a software prototype for face recognition, which will
be able to recognize faces from facial images captured through a webcam. This
software development parametrically compare the acquired image with which they
are stored in a flat file that creates the same software, is fed with images of faces.
To develop on the Microsoft platform known as. NET which serves to develop
software, and make the design based on image processing "eigenfaces".
KEYWORDS: Biometric system, security, control, images, face, eigenfaces,
software, methodology. Scrum, estimation, models, requirements, diagrams,
prototypes, software management, incidents,
18
INTRODUCCIÓN
Los sistemas de seguridad han sido utilizados por la humanidad durante la edad
media, y sobre todo durante el renacimiento, la criptografía (Islam; Sayeed &
Samraj, 2000, p. 12) y el criptoanálisis ganaron importancia, aunque no se dieron
grandes innovaciones durante esta época.
En la década de los 70 fue cuando se publicó el primer algoritmo de cifrado
público (DES) poco después surgieron los primeros algoritmos de clave pública
(RSA).
En la actualidad los sistemas basados en reconocimiento biométrico han cobrado
gran relevancia en la seguridad en entornos que requieren la identificación de
usuarios o para dar accesos a sitios restringidos.
Por otro lado en los sistemas de verificación (o autentificación de la identidad) el
usuario indica al sistema cuál es su pretendida identidad (dice quién es) y además
aporta sus características biométricas que el sistema captura y compara
únicamente con las que tiene almacenadas de ese individuo que dice ser, para
producir un resultado de aceptación.
19
En los sistemas de reconocimiento se presenta la característica biométrica (cara,
voz, firma...) de un individuo desconocido y el sistema proporciona la identidad de
esa persona. Para ello, compara dicha característica biométrica con las de todas
las personas conocidas por el sistema.
La Universidad Católica de Pereira viendo la necesidad de seguridad en el
laboratorio del software, desea implementar un sistema de seguridad biométrico
que permita el reconocimiento de rostro; finalmente así se ha dado al desarrollo
titulado reconocimiento de rostro que intenta dar solución al problema de
seguridad planteado por la Universidad Católica de Pereira.
20
JUSTIFICACIÓN
Hoy en día surge el avance tecnológico, las personas se sienten atraídas por las
facilidades que se pueden obtener al momento de realizar diversas
investigaciones, ya que en la actualidad se cuenta con ayudas para tales casos,
especialmente Internet, por medio de la cual es posible conseguir casi cualquier
cosa que se necesite.
En las universidades, colegios y demás instituciones educativas, se cuenta con
una numerosa tecnología ejemplo computadores, Router, video beam hasta
cámaras de seguridad etc. Con los cuales se ayudan para la realización de tareas,
clase, red interna, externa vigilar etc.
Prácticamente todas las empresas utilizan este medio para determinados fines
empresariales, como la base de datos de sus clientes, la cual es de suma
importancia para el control de los mismos.
La tecnología es una herramienta que sirve para la investigación, el desarrollo,
comunicación, la seguridad etc. Desde hace mucho tiempo el ser humano ha
querido desarrollar sistemas biométricos, con los cuales se pueda llegar a
identificar a las persona.
21
El tema de la seguridad, es un tema de gran preocupación a nivel mundial. En
Colombia se ha incrementado la delincuencia informática, robos en los hogares,
en las empresas. Y debido a este fenómeno las empresas privadas, públicas y
personas naturales requieren una mayor protección a su seguridad. Con
aplicaciones de seguridad y aparatos biométricos disminuirá la delincuencia
común, la delincuencia organizada y la delincuencia informática, ya que podrán las
autoridades determinar por medio de cámaras, las identidades de los delincuentes
y sus delitos.
La tecnología de reconocimiento facial es algo cada vez más cotidiano, como
podemos comprobar en teléfonos en redes sociales en GPS donde sirve como
sistema de desbloqueo, o en el control de disturbios, pero en otros ámbitos
tampoco para de evolucionar.
El caso Disney se basan en ordenadores, cámaras de alta definición y complejos
sistemas como el que se enseña hoy. Se trata de un sistema de reconocimiento
facial realmente avanzado, ya que incluye un algoritmo capaz de identificar la
barba, transformarla en 3D y reconstruir la superficie de la piel que el pelo no deja
ver. De esta forma, la animación en tres dimensiones podría recrearse con y sin
pelo. (Reconocimiento de rostro, 2008)
Existe también un Software para medir en rating de televisión por medio de
reconocimiento de ánimo muy relacionado con el reconocimiento facial, sin
22
embargo, en esta ocasión la utilidad está enfocada para su uso con los robots
animatrónicos. La idea es capturar los movimientos de una cara humana con todo
lujo de detalles para luego traspasar todos los gestos al robot, ofreciendo así un
resultado mucho más fiel al original (prácticamente un clon) y acelerando todo el
proceso de creación, reconocimiento de siluetas utilizado para inventarios de
partes.
Este tema de reconocimiento de rostros tiene un sin número de aplicaciones en
las cuales se podrá seguir investigando por muchos años.
23
1. PRESENTACIÓN DE LA ORGANIZACIÓN
1.1. RESEÑA HISTÓRICA
La Universidad Católica de Pereira (antes Universidad Católica Popular del
Risaralda) nació gracias a la iniciativa, la capacidad emprendedora y la decisión
de un grupo de estudiantes que deseaban una alternativa académica diferente a
las existentes en la ciudad de Pereira, para su formación profesional. En medio de
grandes limitaciones financieras y académicas lograron crear un centro de
estudios que llamaron "Fundación Autónoma Popular del Risaralda", en el cual se
ofrecían los programas de Derecho y Economía Industrial.
Este grupo de estudiantes que, empleando sus propios recursos, lograron
reunir fondos para asumir el sostenimiento de la institución, enfrentando para este
fin grandes dificultades y retos en los aspectos pedagógicos y académicos. En
1973 pidieron al entonces Obispo Coadjutor de Pereira Monseñor Darío Castrillón
Hoyos que fuese el Rector de la Institución quien con gusto aceptó.
Posteriormente, en el año de 1974, los estudiantes solicitaron a los sacerdotes
Francisco Arias Salazar y Francisco Nel Jiménez Gómez que prestaran sus
servicios como docentes de la Universidad y de esta forma se estrecharon aún
más los vínculos entre la Diócesis de Pereira y la Fundación COPESA. Ese mismo
24
año, el Señor Obispo y los dos sacerdotes vinculados a la Fundación como
docentes, llevaron a cabo un examen crítico de la situación de la Institución
concluyendo que las circunstancias en las cuales se desarrollaba y las
condiciones externas que afrontaba no le permitían asegurar su viabilidad futura.
No obstante, persistían en su deseo de apoyar tan importante proyecto.
En el proceso de reflexión y discusión interna con los estudiantes integrantes
de la Fundación, se acordó por unanimidad que la dirección de la “Fundación
Autónoma Popular del Risaralda” estuviese a cargo de la Diócesis; este hecho
ratificó la vocación Católica que tendría la Institución, bajo la premisa de respeto
por la libertad de conciencia de quienes ingresaran a ella, dando vida a nuevo
nombre de “Universidad Católica Popular del Risaralda”.
Por iniciativa del entonces Señor Obispo Castrillón, se invitó a la Corporación
para el Progreso Económico y Social del Risaralda -COPESA- a figurar como
cofundadora de la Universidad, invitación que fue aceptada. Por consenso, se
decidió la continuación de Monseñor Castrillón como Rector de la nueva Alma
Mater; así mismo, como Vicerrector con funciones de Rector, el Señor Obispo
nombró al Padre Francisco Arias Salazar, quien con un equipo calificado de
colaboradores se dio la tarea de diseñar estatutos y reglamentación necesaria
para dar vida jurídica a la Institución y fue así como el 14 de febrero de 1975,
mediante Decreto N’. 865 expedido por la Diócesis de Pereira, se creó la
Universidad Católica Popular del Risaralda (Hoy Universidad Católica de Pereira).
25
1.2. MISIÓN
La Universidad Católica de Pereira es una institución de Educación Superior
inspirada en los principios de la fe católica, que asume con compromiso y decisión
su función de ser apoyo para la formación humana, ética y profesional de los
miembros de la comunidad universitaria y mediante ellos, de la sociedad en
general.
La Universidad existe para el servicio de la sociedad y de la comunidad
universitaria. El servicio a los más necesitados, es una opción fundamental de la
institución, la cual cumple formando una persona comprometida con la sociedad,
investigando los problemas de la región y comprometiéndose
interinstitucionalmente en su solución. Es así como se entiende su carácter de
Popular.
1.3. VISIÓN
La Universidad inspirada por los principios y valores cristianos será líder en los
procesos de construcción y apropiación del conocimiento y en los procesos de
formación humana, ética y profesional de sus estudiantes, de todos los miembros
de la comunidad universitaria y de la sociedad. Será un escenario permanente
para el diálogo riguroso y constructivo de la fe con la razón, en el contexto de la
evangelización de la cultura y la inculturación del Evangelio.
26
Será reconocida por su capacidad para actuar como agente dinamizador del
cambio y promover en la comunidad y en la familia sistemas armónicos de
convivencia. La Universidad tendrá un claro sentido institucional de servicio
orientado hacia sus estudiantes, profesores, personal administrativo y la
comunidad.
1.4. VALORES
Ética.
Verdad.
Dignidad Humana.
Servicios.
Calidad.
Compromiso.
27
1.5. ORGANIGRAMA UCP
Ilustración 1. Organigrama UCP
Fuente: Departamento de Planeación Organigrama de la Universidad Católica de Pereira
28
1.6. PROPÓSITO
Estas políticas tienen como propósito establecer las directrices para
administrar los pedidos de compra e instalación de software, para obtener el
mayor beneficio de este recurso y optimizar el presupuesto disponible.
1.6.1 Alcance.
Esta política es aplicable a todas las dependencias académicas y administrativas
de la UCP que requieran cualquier tipo de software.
1.6.2 Políticas.
a. Es política de la UCP prohibir el uso y la duplicación de cualquier software
del que no se posea una licencia legítima. Bajo ninguna circunstancia la UCP
tolerará la piratería de software en las dependencias académicas y
administrativas, ni en las salas de sistemas, por lo tanto no se permite realizar
copias no autorizadas de software en los computadores pertenecientes a la
institución.
b. La única dependencia autorizada para adquirir e instalar software en
las diferentes dependencias académicas, administrativas y salas de sistemas,
es el departamento de sistemas.
29
c. Los medios originales, las claves de acceso para descarga y la
documentación que acredita el licenciamiento del software, estará a cargo
únicamente del departamento de sistemas, quien tendrá la responsabilidad de
conservarlos en un lugar apropiado y de mantener actualizado el inventario.
d. El departamento de sistemas deberá llevar un registro del software
autorizado para cada dependencia y las salas de sistemas.
e. El departamento de sistemas realizará dos revisiones anuales (receso
intersemestral de mitad de año, vacaciones de final de año) del software
instalado en todos los computadores propiedad de la UCP, y procederá a la
desinstalación del software no autorizado que se encuentre. Sin embargo,
esporádicamente se harán revisiones de forma aleatoria y se procederá de
igual manera.
f. La aprobación de una solicitud de adquisición de software debe cumplir con
los siguientes requisitos:
Que vaya a ser utilizado por más de un año.
Que sea compatible y funcione adecuadamente en los equipos disponibles de
la UCP.
Que no haya algún software equivalente instalado.
30
Que no exista software de uso libre que cumpla con las mismas
funciones que el solicitado.
Que se disponga del presupuesto necesario para su adquisición.
g. El departamento de sistemas, en conjunto con las diferentes dependencias
académicas y administrativas de la UCP, determinará anualmente cuáles son
sus necesidades de software, lo cual permitirá establecer un presupuesto general
para la compra. Procedimiento para la solicitud de instalación de Software.
Ilustración 2. Sala sistemas UCP
Fuente: Sala de sistemas de la UCP
h. En salas de sistemas. El docente que requiera la instalación de software
para sus clases deberá solicitar al departamento de sistemas con mínimo una
31
semana de anticipación a la fecha de su utilización. La solicitud debe contener la
siguiente información:
Nombre del docente.
Nombre y versión del software y una breve descripción del mismo.
Clase para la que se solicita.
Tiempo estimado de uso.
i. Una vez recibida la solicitud, el departamento de sistemas hará la
respectiva verificación de disponibilidad y cantidad de las licencias para su
uso, en el caso de software libre, de la disponibilidad de la versión solicitada,
y se procederá a su instalación. Si no se cuenta con el software solicitado
por el docente, se procederá a informarle oportunamente.
j. En dependencias académicas y/o administrativas. El director de la
dependencia que requiera la instalación de software, deberá solicitar el servicio al
departamento de sistemas. La solicitud debe contener la siguiente información:
Nombre de la dependencia.
Nombre y versión del software y una breve descripción del mismo.
Proceso y/o actividad que requiere el software.
Tiempo estimado de uso.
32
k. Una vez recibida la solicitud, el departamento de sistemas hará la
respectiva verificación de disponibilidad y cantidad de las licencias para su
uso, en el caso de software libre, de la disponibilidad de la versión
solicitada, y se coordinará con el director de la dependencia solicitante su
instalación.
l. Si no se cuenta con el software solicitado por la dependencia, se
procederá a informar oportunamente y se estudiarán otras alternativas de
software.
1.7. PROCESOS DE LA ORGANIZACIÓN
Ilustración 3. Procesos de la organización UCP
Fuente: UCP
33
1.8. FACTORES QUE INFLUYEN EN EL ENTORNO: FACTORES
ENTORNO ECOLÓGICO, MEDIOAMBIENTAL Y DE RECURSOS
NATURALES
Son las condiciones de recursos naturales y físicas que pueden afectar a un
software. Por ejemplo, el clima, el terreno, el suministro de recursos naturales, las
catástrofes naturales. (Evaluar el entorno, 2009) El desarrollo del software no
afecta el entorno ecológico, como es un desarrollo intangible, sus efectos serían
mínimos, ya que para desarrollo de un software se necesita unos requisitos, como
un computador, energía, etc. O sea, que se necesita recursos naturales. Otro
punto que lo afectara ya sería cuando se implementa el sistema, de que el clima
no sea apropiado y dañe los equipos.
1.9. FACTORES ENTORNO SOCIOCULTURAL
Son las condiciones sociales y culturales en el que se va a desempeñar el
software. Por ejemplo el tamaño de la población, características por edades,
género, actividad familiar, hábitos y costumbres, nivel educativo, mercado laboral,
habilidades disponibles, organizaciones laborales o sindicatos y ética laboral de
los empleados, entre otros. (Evaluar el entorno, 2007) La tecnología tiene un
alcance muy grande en dos aspectos, aspecto negativo y positivo, el positivo se
tendrá un mejor control, hoy en día, la seguridad es un tema a nivel mundial.
34
En Colombia se ha estado viendo mucho el aumento de la delincuencia y
robos. Y debido a este fenómeno las empresas privadas, públicas y personas
naturales optan por un sistema de seguridad que sea mucho más eficaz. Hay que
promover la cultura como en estados unidos primero la seguridad, hacer entender
a las empresas que es muy importante tener un control de las personas, a nivel de
gobierno, a nivel de empresas privadas, a nivel de empresas públicas y personas
naturales. Los negativos
1.10. FACTORES ENTORNO LEGAL Y POLÍTICO
Se refieren a las instituciones políticas y legales, leyes, normas y regulaciones que
afectan a la empresa. Por ejemplo la Ley 1341 de 2009. (Ley 1341, 2009) por la
cual se definen principios y conceptos sobre la sociedad de la información y la
organización de las tecnologías de la información y las comunicaciones TIC, se
crea las agencias nacional de espectro y se dictan otras disposiciones. Ley 527
del 1999 (Ley 0527, 1999) por el medio de la cual se define y reglamenta el
acceso y uso de los mensajes de datos, del comercio electrónico y de las firmas
digitales, se establecen las entidades de certificación y se dictan otras
disposiciones. Ley 201 del 2012 por medio de la cual se implementan
compromisos adquiridos por virtud del acuerdo de promoción comercial suscrito
entre la república de Colombia y los Estados Unidos de América y su protocolo
modificatorio, en el marco de la política de comercio exterior e integración
económica.
35
1.11. FACTORES ENTORNO SECTORIAL
Se refieren a los clientes y consumidores, competidores y productos sustitutos,
facilidad o dificultad de introducirse y abandonar el sector. (Emprende, 2007) El
sistema es un producto difícil de introducir al mercado debido que las empresas
no le ven las ventajas, hay que dar a conocer más ventajas del desarrollo del
software estas son algunas empresas desarrolladoras de software biométricos en
Colombia.
Sisbiocolhttp://sistemasbiometricos.co/
Solutekhttp://www.solutekcolombia.com/sistemas_biometricos_bogota.htm
Solución biométricahttp://solucionbiometrica.wordpress.com/tag/sistemas-biometricos-en-colombia/
High class http://www.hctla.com/hct/Medellin
1.12. FACTORES ENTORNO TECNOLÓGICO
Se refieren a la tecnología disponible en el mercado que pueda facilitar los
procesos operativos y administrativos. Por ejemplo, máquinas de mejor
rendimiento, software administrativo, sistemas de control, automatización, facilidad
de adquirir y crear conocimiento, entre otros. (Emprende, 2007) En la actualidad
se puede contar con la tecnología necesaria a nivel de hardware y software para
realizar el proyecto propuesto, el mayor inconveniente es la poca y difusa
36
información que se encuentra respecto a los algoritmos para el reconocimiento de
rostros y su aplicación.
1.13. OBJETIVOS
1.13.1 Objetivo General.
Desarrollar un prototipo funcional de software que permita el reconocimiento de
rostro para la identificación del personal que ingresa al laboratorio de software de
la Universidad Católica de Pereira
1.13.2 Objetivos Específicos.
Diagnosticar el problema que presenta la organización respecto a los temas de
seguridad.
Levantar los requerimientos adecuados.
Modelar la posible solución o el prototipo.
Construir un prototipo inicial.
Hacer las pruebas de los caso de uso.
37
1.13.3 Requerimientos de la Organización.
La universidad Católica de Pereira requiere un aplicativo para el control e
identificación requerida de ingreso del personal al laboratorio del software.
Hacer un sistema para minimizar errores de identificación del personal que
ingresa al laboratorio.
Que no pida usuario ni contraseña para el ingreso.
Que la autenticación del usuario sea por medio del rostro.
Utilizar opciones alternativas por si la cámara funciona mal.
Un nivel de efectividad de un 80 por ciento en la identificación para la
plataforma Windows.
Que funcione con cualquier tipo de cámara web.
La base datos sea gratuita si se utiliza.
38
PLANTILLA DE REQUERIMIENTOS
39
1.14. PLANTILLA DE REQUERIMIENTOS
Ilustración 4. Plantilla de Requerimientos
FUENTE: UCP
40
1.14.1. Formato de requerimientos 1
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012CÓDIGO DEL FORMATO: 001
Tabla 1. Requerimiento 1
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
Hacer un sistema para minimizar errores de reconocimiento de rostro.
REQUERIMIENTOS
Nombre del Requerimiento Hacer un sistema para minimizar errores de identificación del personal que ingresa al laboratorio
Código del Requerimiento RE 1
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional X No funcional
Proceso X
Producto Negocio X
Entorno Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio
Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 80%
Descripción del Requerimiento Este requerimiento le permitirá al usuario consultar y editar la información de los subalternos de forma rápida.
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
41
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
42
1.14.2. Formato de requerimientos 2
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012CÓDIGO DEL FORMATO: 002
Tabla 2. Requerimiento 2
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
No pida usuario ni contraseña.
REQUERIMIENTOS
Nombre del Requerimiento Que no pida usuario ni contraseña para el ingreso
Código del Requerimiento RE 2
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional X No funcional
Proceso X
Producto Negocio X
Entorno Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio
Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 50%
Descripción del Requerimiento no pida usuario ni contraseña
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
43
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
44
1.14.3. Formato de requerimientos 3
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012CÓDIGO DEL FORMATO: 003
Tabla 3. Requerimiento 3
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
La autenticación del usuario sea por medio del rostro.
REQUERIMIENTOS
Nombre del Requerimiento Que La autenticación del usuario sea por medio del rostro
Código del Requerimiento RE 3
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional X No funcional
Proceso X
Producto Negocio X
Entorno Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio
Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 90%
Descripción del Requerimiento Autenticación por rostro
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
45
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
46
1.14.4. Formato de requerimientos 4
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012CÓDIGO DEL FORMATO: 004
Tabla 4. Requerimiento 4
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
Utilizar opciones alternativas por si la cámara funciona mal.
REQUERIMIENTOS
Nombre del Requerimiento utilizar opciones alternativas por si la cámara funciona mal
Código del Requerimiento RE 4
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional X No funcional
Proceso X
Producto Negocio X
Entorno Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio
Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 80%
Descripción del Requerimiento opciones alternativas
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
47
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
48
1.14.5. Formato de requerimientos 5
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012 CÓDIGO DEL FORMATO: 005
Tabla 5. Requerimiento 5
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
un nivel de efectividad de un 80 por ciento en la identificación
REQUERIMIENTOS
Nombre del Requerimiento un nivel de efectividad de un 80 por ciento en la identificación
Código del Requerimiento RE 5
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional No funcional X
Proceso X
Producto Negocio X
Entorno Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 80%
Descripción del Requerimiento nivel identificación
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
49
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
50
1.14.6. Formato de requerimientos 6
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012 CÓDIGO DEL FORMATO: 006
Tabla 6. Requerimiento 6
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
para la plataforma Windows
REQUERIMIENTOS
Nombre del Requerimiento para la plataforma Windows
Código del Requerimiento RE 6
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional No funcional
Proceso X
Producto Negocio X
EntornoX Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio
Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 90%
Descripción del Requerimiento plataforma
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
51
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
52
1.14.7. Formato de requerimientos 7
UNIVERSIDAD CATÓLICA DE PEREIRA
Fecha: Vienes, 16 de noviembre de 2012CÓDIGO DEL FORMATO: 007
Tabla 7. Requerimiento 7
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
Que funcione con cualquier tipo de cámara web.
REQUERIMIENTOS
Nombre del Requerimiento Que funcione con cualquier tipo de cámara web
Código del Requerimiento RE 7
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional No funcional X
Proceso X
Producto Negocio X
Entorno Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 60%
Descripción del Requerimiento Que funcione con cualquier tipo de cámara web
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
53
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
54
1.14.8. Formato de requerimientos 8
UNIVERSIDAD CATÓLICA DE PEREIRA Fecha: Vienes, 16 de noviembre de 2012CÓDIGO DEL FORMATO: 008
Tabla 8. Requerimiento 8
Medio por el cual fue recibido Oral X Teléfono Medio Electrónico Otro:________________
PLANTEAMIENTO PROBLEMA
La base datos sea gratuita si se utiliza
REQUERIMIENTOS
Nombre del Requerimiento base de datos sea gratuita
Código del Requerimiento RE 8
Prioridad del Requerimiento según el Cliente
Alta/Esencial X Media/Deseado Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador
Alta/Esencial X Media/Deseado Baja/ Opcional
Tipo de requerimiento
Funcional No funcional
Proceso X
Producto Negocio X
Entorno X Usuario Sistema Interfaz Interface
Estado Recibido X En Estudio
Viable No Viable En construcción En pruebas Implementado
Tiempo Estimado
Ponderación Requerimiento (%) 90%
Descripción del Requerimiento base de datos
Complemento de Requerimientos
Interfaces de Usuario:
Fácil de entrar al Desarrollar del prototipo funcional
Requerimientos de Hardware:
Las computadoras que brindarán el servicio cliente del sistema no deberán de presentar potencias menores a las brindadas por una dual Corel, con al menos 1g de RAM y 500 gb de espacio en el disco, con un Sistema Operativo Windows.
Cámara web de 12 mega pixeles
Requerimientos de Software:
Compatibilidad con cualquier Windows.
El Desarrollar del prototipo funcional, debe estar desarrollado en .NET.
Requerimientos de comunicación:
55
NOMBRES Y FIRMAS
Cliente
______________________________________________ Nombre: CC.
Analistas ______________________________________________ Nombre: Oscar Alejandro Zapata y Fabián Albeiro López CC.10030100
Control Requerimientos
N° N° Requerimiento Fecha de Recepción Tiempo Estimado Fecha Solución Estado
Solución
1 <ej. RF 10, RF 10.1, RF 10.2>
<29 Agosto 2012> <1 semana> <5 Sept 2012> <Recibido, No Viable, Aprobado, Construcción, Finalizado>
2
3
FIRMAS
Responsable Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
VB° Coordinador del Proceso:
Oscar Alejandro Zapata y Fabián Albeiro López
Personal Involucrado
Nombre Oscar Alejandro Zapata y Fabián Albeiro López
Rol
Categoría profesional Ingeniero de sistemas y telecomunicaciones
Responsabilidades Levantamiento de requerimientos, Diseño análisis y desarrollo del proyecto software
Información de contacto [email protected]
Aprobación
Relación de personas involucradas en el desarrollo del sistema, con información de contacto. Esta información es útil para que el gestor del proyecto pueda localizar a todos los participantes y recabar la información necesaria para la obtención de requisitos, validaciones de seguimiento, etc.
56
1.15. PLANTEAMIENTO DEL PROBLEMA
1.15.1 Descripción del Problema.
La Universidad católica de Pereira no cuenta con un sistema de Biometría facial
que le permita tener una mayor seguridad y control en el ingreso al laboratorio de
software.
1.16. DEFINICIÓN DEL PROBLEMA
La Universidad UCP no cuenta con una base de datos que permita almacenar la
información donde pueda contrastar de manera veraz y confiable el ingreso y
control del personal que ingresa al laboratorio del software. Una base de datos de
imágenes faciales 2D permitirá lograr plasmar las posibles variaciones (en cuanto
a pose, cambios de iluminación, expresiones faciales, etc.) entre las diferentes
imágenes de un mismo individuo y así lograr la identificación requerida del mismo.
1.16.1 Solución Propuesta.
Desarrollar un prototipo de software para el reconocimiento de rostro obteniendo
fotografías digitales almacenadas en un archivo plano. Que como resultado el
prototipo de reconocimiento alcance la identificación requerida de dicha persona si
ésta está en las fotografías almacenadas en el archivo plano.
57
1.17. VENTAJAS
No requiere contacto.
Sensores disponibles fácilmente (cámaras).
Grandes cantidades de datos existentes para permitir chequeos de
antecedentes.
Chequeo fácil por parte de los humanos para verificar resultados.
1.18. DESVENTAJAS
El rostro puede ser obstruido por el cabello, anteojos, sombreros, pañuelos,
etc.
Sensible a los cambios en la luz, la expresión y la pose.
Los rostros se modifican conforme pasa el tiempo.
Los usuarios son propensos a capturar imágenes de baja calidad aun
esperando resultados de buena precisión.
58
1.18.1 Viabilidad del Proyecto.
Teniendo en cuenta las diferentes tecnologías con las que actualmente se cuenta,
y la necesidad cada vez más apremiante de organizaciones y personas de contar
con sistemas que ofrezcan un nivel mejor de seguridad y control, este proyecto
será presentando a los directivos de la Universidad UCP para que lo evalúen y
consideren su aplicación para la solución en los problemas de control de acceso,
teniendo en cuenta que el uso del control biométrico y más el reconocimiento de
rostros ofrece un nivel muy alto de identificación, por encima del sensor de huella
o el de iris los cuales son de más fácil falsificación.
El avance tecnológico se da en nuestro país seguramente va a permitir que
este tipo de proyectos tengan una importante proyección, porque su aplicación se
puede dar en muchos sectores y campos donde se requiera el control de acceso y
mejoramiento de la seguridad.
Este sistema nos genera mayor congestión ya que después de que el sistema
este puesto a punto el reconocimiento del rostro no toma más de 5 segundos.
1.18.2 Impacto.
Es un proyecto que tiene gran impacto desde el punto de vista de la Universidad
UCP ya que el lograr tener una mayor seguridad y control en el ingreso al
59
laboratorio del software disminuirá en gran porcentaje los problemas de pérdida de
información, equipos y mal uso del mismo, pues de alguna manera el hecho de
que el personal que ingresa al laboratorio sepa que está siendo identificado,
además de otra información como fecha, hora de ingreso y salida seguramente
hará que se abstenga de cometer acciones indebidas.
Por otro lado si el uso de este tipo de tecnología y proyectos de masifica, pues
como ya se ha mencionado puede ser aplicado en muchos sectores, empresas y
medida la seguridad de los ciudadanos
Adicional el impacto puede llegar también al cuerpo estudiantil y docente, como
para el cuerpo científico, ya que es un aporte más para el proceso de investigación
y desarrollo.
1.19. MARCO TEORICO
1.19.1 Antecedentes.
El reconocimiento facial automatizado es relativamente un concepto nuevo.
Desarrollado en los años 60, el primer sistema semiautomático para
reconocimiento facial requería del administrador para localizar rasgos (como ojos,
orejas, nariz y boca) en las fotografías antes de que este calculara distancias a
60
puntos de referencia en común, los cuales eran comparados luego con datos de
referencia.
En los años 70 Goldstein, Harmon, & Lesk, (1971) usaron 21 marcadores
subjetivos específicos tales como el color del cabello y grosor de labios para
automatizar el reconocimiento facial. (pp. 748 – 760) El problema con estas
soluciones previas era que se computaban manualmente. En 1988 Kirby &
Sirobich aplicaron análisis de componentes principales, una técnica estándar del
álgebra lineal, al problema del reconocimiento facial. Esto fue considerado algo así
como un hito al mostrar que eran requeridos menos de 100 valores para cifrar
acertadamente la imagen de una cara convenientemente alineada y normalizada.
(Sirovich; Kirby, 1987, pp. 519 – 524).
En 1991 Turk & Pentland utilizando las técnicas Eigenfaces, el error residual
podía ser utilizado para detectar caras en las imágenes (Turk; Pentland, 1991, pp.
586 – 591) -un descubrimiento que permitió sistemas automatizados de
reconocimiento facial en tiempo real fidedignos. Si bien la aproximación era un
tanto forzada por factores ambientales, creó sin embargo un interés significativo
en posteriores desarrollos de éstos sistemas.
El 4 de abril del 2011. Los investigadores Juan Bekios-Calfa, José M. Buena
Posada y Luis Baumela, del ComputationalIntelligenceGroup de la Facultad de
Informática de la Universidad Politécnica de Madrid, han desarrollado
61
Un dispositivo identifica si el usuario de un ordenador es hombre o mujer.
(Sybil, 2009)
Desarrollado en la Facultad de Informática de la UPM, ha sido objeto de una
patente y tiene numerosas aplicaciones industriales. Un nuevo dispositivo,
consistente en una cámara de adquisición de imágenes digitales conectada a un
sistema de procesamiento de imágenes, permite a un ordenador identificar si el
usuario es un hombre o una mujer. El dispositivo, que ha sido objeto de concesión
de una patente, permite construir dispositivos de medición de audiencia de
televisión o videos publicitarios, entre otras aplicaciones industriales. (p. 12)
Ilustración 5. Imágenes
Fuente: FIUPM.
62
Los investigadores Juan Bekios-Calfa, José M. Buena Posada y Luis Baumela,
pertenecientes a la ComputacionalIntelligenceGroup de la Facultad de Informática
de la Universidad Politécnica de Madrid. Han creado un sistema, el cual tiene la
capacidad de analizar en tiempo real una señal de vídeo, además de calcular el
género, si es hombre o mujer. Este dispositivo, ha sido objeto de concesión de
una patente (ES 2 339 100 B2) por parte de la Oficina Española de Patentes y
Marcas a favor de la Universidad Politécnica de Madrid y de la Universidad Rey
Juan Carlos. (RDiPress, 2011)
Mediante este algoritmo se construyen dispositivos de medición de audiencia
de televisión o vídeos publicitarios, para obtener de los espectadores información
demográfica. Otra ventaja es que facilita la creación de quioscos interactivos con
un vendedor virtual, ya que consigue información sobre el usuario extraída
automáticamente, como puede ser el género de la persona, para mejorar la
interacción.
Por su parte, desde mayo del 2006 un equipo de investigación
norteamericano, (ha desarrollado una máquina que ha superado totalmente al
hombre en el reconocimiento facial. (2010) Estos algoritmos son bastante
eficaces para reconocer rostros. Este descubrimiento supone un estímulo para la
creación de nuevos programas de seguridad, tanto para el gobierno como para las
empresas.
63
Ilustración 6. Caras
Fuente: FIUPM
A partir de los hechos lamentables que ocurrieron el 11 de Septiembre de
2001, los gobiernos de prácticamente la mitad del mundo, no han cesado en su
empeño por mejorar la seguridad de sus territorios; esto se puede observar
especialmente en los Estados Unidos, quienes no han escatimados esfuerzos y
empeño por blindar el espacio aéreo a personas potencialmente peligrosas.
64
Su lucha por mantener una imagen segura, ha sido un camino tanto de aciertos
como de equivocaciones, ya que las constantes alarmas que en su mayoría
resultan falsas, se han constituido en una forma de atentar contra la intimidad de
las personas, que también desde aquel día, sienten la zozobra rondando de forma
continua sus espacios.
Todo esto ha llevado a que se busquen soluciones inmediatas para tratar de
aminorar los peligros, y entre estas soluciones se encuentra la mejora en los
software de reconocimiento facial, la cual, y de acuerdo a numerosas
investigaciones se convierte en un arma de lucha, ya que ella permitirá a los
trabajadores de los aeropuertos, por ejemplo, a saber con certeza si la persona
que tienen en frente es un terrorista o sólo un turista acobardado.
Alice O’Toole, profesora de la Escuela de Ciencias Conductuales y Cerebrales
de la Institución Norteamericana, junto con un equipo de científicos, han evaluado
la eficacia de los programas de reconocimiento facial realizando comparaciones
con los índices de éxito de diferentes software y aquellos obtenidos por medios no
tecnológicos, que en este caso corresponde a personas expertas en la evaluación
humana.
A través de los algoritmos que en sí son fórmulas que tienen la capacidad de
permitir a los ordenadores el reconocimiento de rostros. Estos algoritmos varían
65
mucho entre los distintos desarrolladores de software, y la mayoría nunca han sido
comparados entre sí.
Tanto la profesora O’Toole (Profiles) y su equipo de científicos, se encuentran
trabajando en la tarea de examinar de manera cuidadosa el punto exacto en el
cual aciertan y fallan estos algoritmos. Para tal fin examinan las similitudes en
gran cantidad de rostros capturados en una base de datos, los cuales contrastan
después con los resultados que han sido determinados por los algoritmos. “Los
seres humanos y las máquinas deciden por separado si pares de imágenes
faciales, tomadas bajo distintas condiciones de iluminación, fueron fotos hechas a
la misma persona o a sujetos diferentes”. (Higueras, 2010, p. 2)
En este mismo orden, en junio del 2008 se puede hacer referencia a un
sistema desarrollado por un estudiante (notas de mercado, 2008) de Ingeniería
Informática de la Universidad de California, el cual permite a un usuario controlar
la velocidad de reproducción de un video sin usar ningún interfaz, solamente utiliza
para tal fin las expresiones de su rostro.
Este novedoso sistema regula la velocidad de reproducción de una
videoconferencia en función de las reacciones del rostro del usuario, según sean
de aburrimiento o interés, y así optimiza el aprendizaje. El sistema tendrá
importantes aplicaciones pedagógicas, tanto en sistemas de autorización
inteligente como en el ámbito general de la enseñanza.
66
Ilustración 7. Software de Rostro
Fuente: FIUPM. Jacob Whitehill durante la demostración. Universidad de California
Según Gutiérrez, (2008)
Jacob Whitehill de la Universidad de California, realizó una demostración que
causó gran asombro, ya que sin pulsar ningún botón, sin ningún mando a distancia
ni cualquier otro tipo de instrumento de control en sus manos, la velocidad de
reproducción de un vídeo se modulaba según sus deseos en menos tiempo del
que se tarda en pronunciar la palabra PLAY gracias a las expresiones de su
rostro. Es decir, en tiempo real, ya que la respuesta del aparato tiene lugar antes
de que dichos deseos se conviertan en una orden.
67
Este sistema ha sido diseñado con el fin de reconocer las expresiones faciales
con bastante o total precisión, el cual utiliza las disciplinas de la informática, la
pedagogía además de la teoría de la evolución determinada por Darwin, cuya
importancia en el tema radica en que fue el propulsor de la similitud y la
universalidad de expresiones no verbales en individuos de culturas diferentes.
Mediante su intervención, años después los estudios sistemáticos que estaban
en relación con la expresión facial, fueron divulgados por Paul Ekman y Wallace
Friesen, quienes retomando las ideas de Darwin se dieron a la tarea de
perfeccionar sus hallazgos por medio de las Huellas.
Este sistema a través del tiempo ha ido mejorando, lo cual ha permitido una
ampliación considerable en la cantidad de huellas, todo gracias al trabajo de
Ekman (1972), cuyas contribuciones incluyen la interpretación de investigaciones
científicas acerca de los fundamentos de la compasión, el altruismo y las
relaciones humanas pacíficas.
Estas contribuciones fueron utilizadas por Whitehill quien llevó este
reconocimiento a través de la visión computarizada de varias de ellas para su
estudio, si bien el equipo informático utilizado estaba dotado también de un
“detector de sonrisa” y se sometieron además a observación y cuantificaron otras
variables gestuales como el ritmo de pestañeo. (Whitehill, 2011, p. 13)
68
En el 2005, otro gran descubrimiento informático fue realizado por los
alemanes del FraunhoferInstituteforIntegratedCircuits (IIS), el cual consiste en un
software que reconoce el estado de ánimo de las personas. Para tal fin se hizo
uso de una cámara de vídeo, el software hace una descripción exacta de los
cambios que se producen en algunas partes del rostro como ojos, cejas, entre
otros, lo cual permite reconocer el cómo se encuentra la persona en el momento
real.
Determina si la persona que se encuentra al frente a la cámara de vídeo es
hombre o una mujer, si está triste o alegre. Estas aplicaciones serán llevadas
como primer medida al mundo de la publicidad, donde conocer cómo reacciona el
consumidor ante, por ejemplo, un cartel, es determinante. (Morales, 2007)
Ilustración 8. Software de emociones
Fuente: PNUD. Software de reconocimiento de emociones.
69
Para el mundo publicitario es esencial reconocer el comportamiento de la
gente ante sus diferentes herramientas, la manera en como lo observan, si giran
tratando de reconocer sus mensajes o si no les causa ninguna impresión, todo ello
es importante ya que de las reacciones dependerá el éxito de sus campañas.
A través de este novedoso sistema informático de análisis facial, todas estas
inquietudes podrán ser resueltas, ya que es algo de gran utilidad poder determinar
el grado de humor de las personas al momento de estar al frente de una de sus
herramientas, como por ejemplo una valla o un cartel informativo.
Resulta de gran utilidad este sistema, ya que es como meterse en la cabeza de
las personas y determinar lo que están sintiendo en ese momento, qué
pensamientos llegan a sus mentes al momento de estar frente al anuncio. Es algo
que los publicitas desean con gran intensidad, ya que es la posibilidad de llevar a
la empresa a la cual representan hacia el éxito y la popularidad.
Conectarse con las emociones de los demás, lleva indiscutiblemente al
aumento en las ventas, ya que esto llevará a que todos los que estén ante el
anuncio inmediatamente se decidan a la adquisición del producto.
Hasta ahora, los publicistas lo único que podían hacer para saber si una
campaña era efectiva o no, era esperar. Este nuevo sistema les va a proporcionar
los datos que necesitan en tiempo real.
70
Mediante este sistema informático su cámara de vídeo localiza el rostro de
cualquier persona que se encuentra cerca de los anuncios publicitarios
determinando la reacción que le produce la imagen, además de reconocer su
estado real, triste, alegre, preocupado, en fin, todas aquellas emociones que el
hombre, aunque no sea de forma involuntaria, presenta ante determinada
situación.
La característica especial de este software es que opera en tiempo real, está
capacitado para localizar y analizar un gran número de caras simultáneamente. El
software está pasando un periodo de entrenamiento en el que se le presenta una
gran cantidad de datos conteniendo imágenes de rostros. En una operación
normal, el ordenador compara 30.000 características faciales con la información
que aprendió previamente. “En un ordenador normal, los cálculos se generan con
tanta rapidez que los cambios en los gestos de la cara se pueden seguir en tiempo
real”, explica Küblbeck (2010).
71
Ilustración 9. Cara
Fuente: PNUD. Software de reconocimiento de emociones
Explica Calderón (2008) que normalmente, los sistemas ideados para
reconocer rostros han sido “entrenados” mediante una base de datos que contiene
una gran colección de imágenes de caras en diferentes circunstancias de
iluminación y gestuales. Conseguir esa cantidad de imágenes para que un
ordenador pueda identificar la cara de una persona lleva mucho tiempo y es muy
caro. Aun así, los sistemas actuales tienen problemas muchas veces debido a la
mala calidad de las fotos o la variedad de ángulos o iluminaciones. Se requiere
72
entonces más investigación, nuevos proyectos y perfeccionamiento de las grandes
obras de los grandes estudiosos.
Son investigaciones que han permitido avanzar mucho en el desarrollo de
software para reconocimiento de los rostros por parte de los ordenadores.
1.20. MARCO CONCEPTUAL
1.20.1 Tendencias informáticas.
EL IIS ha terminado ya un prototipo básico (Tendencias, 2007) que es capaz de
distinguir si quien está al frente de la pantalla está triste o alegre. Por otro lado, el
índice de acierto del software respecto a saber si quien está frente a la cámara es
un hombre o una mujer es ya del 90%.
Las primeras aplicaciones del sistema, se tienen previstas para el mundo de la
publicidad, ya que se va a poder conocer de manera exacta cómo piensa la gente,
cuáles son sus reacciones frente a determinado anuncio o producto, pero se sigue
en la búsqueda de mejores aplicaciones. Por ejemplo se tiene la idea de utilizarlo
para comprobar si un programa de ordenador o un dispositivo electrónico es fácil
de usar o no. El sistema monitoriza las expresiones faciales del usuario para
determinar qué aspectos de ese programa o dispositivo le están planteando
problemas o le desagradan.
73
El software analiza los datos sólo desde bases puramente estadísticas. Es
decir, no identifica individuos ni guarda información para después usarla.
Sencillamente compila información y la proporciona después como estadística. No
se guardan patrones para después intentar identificar a cada persona que ha
pasado frente a la cámara, simplemente se trata de identificar situaciones que
sean relevantes para situaciones determinadas.
1.21. EL POTENCIAL DEL SOFTWARE
Se prevé que el primer uso que se dé a este nuevo programa sea en el mundo de
la publicidad, para saber, por ejemplo, cómo reacciona un consumidor frente a un
cartel ubicado en su calle o frente a determinado rostro en una gaseosa.
De esta forma, la efectividad de una campaña tardará menos tiempo en ser
comprobada y los datos que reciban los publicistas serán en tiempo real.
“La característica especial de nuestro software es que opera en tiempo real”
dice el doctor Christian Küblbeck, jefe del proyecto en el IIS, en un comunicado
hecho público por el Instituto Fraunhofer. Además, Küblbeck agrega que “es más,
el programa es capaz de localizar y analizar un gran número de caras
simultáneamente”.
74
Para mejorar el desempeño del producto creado en el IIS se está realizando un
periodo de entrenamiento en el que se le presenta una gran cantidad de datos
conteniendo imágenes de rostros.
1.22. EIGENFACES
Son un conjunto de vectores utilizados en el problema de la visión por ordenador
de reconocimiento de rostros humanos. (Image Processing: Principles and
Applications, 2005) El enfoque de utilizar eigenfaces para el reconocimiento fue
desarrollado por Sirovich y Kirby (1987) y utilizado por Matthew
Turk y Alex Pentland en la clasificación de la cara. Es considerado el primer
ejemplo exitoso de la tecnología de reconocimiento facial. Estos vectores se
derivan de la matriz de covarianza de la distribución de probabilidad del espacio
vectorial de alta dimensión de las caras posibles de los seres humanos.
Un conjunto de eigenfaces se puede generar mediante la realización de un
Proceso matemático llamado análisis de componentes principales (PCA) en un
Gran conjunto de imágenes que muestran diferentes rostros
humanos. Informalmente, eigenfaces puede ser considerado como un conjunto de
“ingredientes cara estandarizada”, derivado de un análisis estadístico de muchas
imágenes de rostros. Cualquier rostro humano puede ser considerado como una
combinación de estas caras estándar. Esta técnica también se utiliza para el
75
análisis de la escritura, la lectura de labios, el reconocimiento de voz, el lenguaje
de signos / mano interpretación gestos y análisis de imágenes médicas.
Ilustración 10. PNUD
Fuente: PNUD. Software de reconocimiento de emociones
76
1.23. IMAGEN DIGITAL
Imagen Digital (Esqueda; Palafox, 2005, p. 420) es una representación gráfica,
generada por computador o creada a través de algún dispositivo de captura como
cámara digital, cámara web, escáner, etc. Y que se almacena en forma binaria.
Las imágenes digitales pueden ser icónicas (tener diferentes grados de
figuración y realismo) o a icónicas (ser abstractas o esquemáticas),
bidimensionales o tridimensionales, con o sin movimiento.
1.24. IMAGEN ESTÁTICA
Es una representación de un objeto u objeto, reales o ficticios, en un instante en el
tiempo. Este tipo de imágenes se clasifican en dos categorías: imágenes
vectoriales e imágenes de mapa bit o bitmapsImágenes vectoriales.
Las imágenes vectoriales están compuestas por entidades geométricas
simples: segmentos y polígonos básicamente (de hecho, una curva se reduce a
una sucesión de segmentos). Cada una de estas entidades está definida
matemáticamente por un grupo de parámetros (coordenadas inicial y final, grosor
y color del contorno, color del relleno, etc.) Por compleja que pueda parecer una
imagen, puede reducirse a una colección de entidades geométricas simples.
77
1.25. IMÁGENES VECTORIALES
Las imágenes vectoriales están compuestas por entidades geométricas simples:
segmentos y polígonos básicamente (de hecho, una curva se reduce a una
sucesión de segmentos). Cada una de estas entidades está definida
matemáticamente por un grupo de parámetros (coordenadas inicial y final, grosor
y color del contorno, color del relleno, etc.) Por compleja que pueda parecer una
imagen, puede reducirse a una colección de entidades geométricas simples.
1.26. IMÁGENES BITMAPS
Las imágenes de mapa de bits están construidas mediante una gran cantidad de
cuadraditos, llamados pixel. Cada uno de estos cuadraditos está relleno de un
color uniforme, pero la sensación obtenida es el resultado de integrar visualmente,
en la retina, las variaciones de color y luminosidad entre píxeles vecinos.
Las imágenes de mapa de bits, también llamadas bitmaps, son la alternativa
ideal para reproducir objetos sutilmente iluminados y escenas con gran variación
tonal. De hecho, es el tipo de imagen utilizado para la fotografía y el cine.
Obviamente, la calidad de la imagen dependerá de la cantidad de píxeles
utilizados para representarla.
78
Las imágenes bitmaps no permiten el cambio de escala. Observa, en la imagen
siguiente, lo que pasa al hacer zoom sobre las flores de la imagen anterior: los
píxeles son evidentes y la representación es totalmente irreal. Este efecto, que se
conoce con el nombre de pixelado se hace más evidente en las líneas curvas y en
las zonas en las que hay cambios bruscos de luminosidad.
1.27. IMAGEN DINÁMICA
La imagen dinámica o en movimiento es en realidad un conjunto de imágenes
estáticas denominadas cuadros de video que mostrados en secuencia rápida dan
la idea de movimiento continuo.
1.28. LA RESOLUCIÓN DE UNA IMAGEN
La resolución de una imagen es la cantidad de píxeles que la componen. Suele
medirse en píxeles por pulgada (ppi) o píxeles por centímetro (pcm). Cuanto
mayor es la resolución de una imagen más calidad tendrá su presentación pero,
desgraciadamente, más espacio ocupará en el disco el archivo gráfico que la
contiene.
79
1.29. TRANSFORMADA DE LA IMAGEN
Son operaciones que convierten imágenes desde una representación hacia otra
diferente con el objetivo de hacer más evidente algún tipo de información existente
de la imagen. Generalmente luego de una transformación sigue un proceso de
umbralización para extraer las características más relevantes de la nueva
representación.
1.30. LA TRANSFORMADA DE HOUGH
La transformada de Hough es una herramienta que permite detectar curvas en una
imagen. Es una técnica muy robusta frente al ruido y a la existencia de huecos en
la frontera del objeto. A la hora de aplicar la transformada de Hough a una imagen
es necesario obtener primero una imagen binaria de los píxeles que forman parte
de la frontera del objeto.
1.31. SEGMENTACIÓN DE IMÁGENES
Es un proceso que permite extraer información de una imagen; consiste en dividir
a dicha imagen en diferentes regiones o áreas de acuerdo a un criterio que esta
dado en función de lo que se busca en la imagen, con esto se trata de separar las
regiones de interés para posteriormente someterlas a un análisis o simplemente
presentarlas.
80
1.32. UMBRALIZACIÓN
Es una técnica de segmentación de manera rápida y sencilla y conveniente de
separar las regiones de interés de las demás regiones en una imagen.
1.33. RECONOCIMIENTO DE PATRONES
Un patrón es un conjunto de descripciones o características que define a un objeto
determinado. Por lo tanto el reconocimiento de patrones es la clasificación de
éstos ya sea en base a un conocimiento a priori (clasificación supervisada) o
mediante su agrupamiento con otros patrones (clasificación no supervisada).
1.34. RECONOCIMIENTO DE ROSTRO
Es un área que forma parte del reconocimiento de patrones. En los últimos años
ha cobrado un gran interés especialmente por la amplia gama de aplicaciones que
tiene en distintos campos tales como seguridad, vigilancia tarjetas inteligentes etc.
Las metodologías para el reconocimiento de rostro han sido divididas de
acuerdo al tipo de imágenes utilizadas, así existen metodologías de
reconocimiento de rostros estáticas y metodologías para reconocimiento de rostro
mediante video.
81
CRONOGRAMA DE ACTIVIDADES PLANEADAS
Tabla 9. Actividades Planeadas
Eta DESARROLLO APLICATIVO RECONOCIMIENTO DE ROSTRO TIEMPO
1
Investigación sobre eigenfaces. Manejo de aplicativos que estén en el entorno. Desarrollo probabilidad del espacio vectorial de alta dimensión de las caras posibles. Algoritmo matemático. Diseño de base de datos. Algoritmo del aplicativo. Desarrollo del documento en esta etapa. Revisión del desarrollo de esta etapa y del documento por el asesor Julio Cesar. Correcciones del documento.
4 MESES
2
Integración .NET Diseño aplicativo. Desarrollo del documento en esta etapa. Revisión del desarrollo de esta etapa y del documento por el asesor Julio Cesar. Correcciones del documento.
3 MESES
3
Pruebas y ensayos del aplicativo. Pre – lanzamiento del aplicativo en la Universidad Católica de Pereira. Desarrollo del documento en esta etapa. Revisión del desarrollo de esta etapa y del documento por el asesor Julio Cesar. Correcciones del documento.
2 MESES
4 Entrega final del aplicativo con sus respetivos instaladores. Entrega del documento corregido por las tres etapas anteriores. Lanzamiento del aplicativo en la Universidad Católica de Pereira.
DE 1ª 2
MESES
82
1.34.1 Metodología a desarrollar.
Las metodologías para la gestión del proyecto de desarrollo de software para
reconocimiento de rostro por medio de webcam que se desena son la propuesta
por PMI (Project Management Institute) en el PMBOK (Project Management Book
of Knowledge), la metodología Scrum y modelo prototipo.
1.35. PMBOK
Significa en español guía de fundamentos de la dirección de proyectos, es una
publicación del Instituto de Dirección de Proyectos (PMI) que es una organización
sin fines de lucro de origen estadounidense y de presencia actual mundial PMBOK
[PMB2004] define proyecto como un esfuerzo temporal tomado para crear un
producto, servicio o resultado único.
Se escogió debido a que contiene prácticas que han sido copiladas y
mejoradas durante los últimos años gracias al esfuerzo de ingenieros, casi toda la
gerencia de proyectos escoge este tipo debido a que es un documento muy bien
direccionado, soportado y gestionado. Otro punto aporta todas las bases para una
gestión adecuada.
83
Para enfocar el análisis de la gestión, plantea la idea de la restricción desde
tres perspectivas:
Alcance: Describe claramente el objetivo del proyecto.
Tiempo: Enfoca el tiempo asignado al proyecto
Costo: Observa el costo involucrado
1.35.1. Etapas del proceso de gestión
Ilustración 11. Etapas Proceso Gestión
Fuente
84
Áreas de Conocimiento
Gestión de Integración del Proyecto
Gestión del Alcance del Proyecto
Gestión de Tiempos del Proyecto
Gestión de Costos del Proyecto
Gestión de la Calidad del Proyecto
Gestión de los Recursos Humanos del Proyecto
Gestión de las Comunicaciones del Proyecto
Gestión de Riesgos del Proyecto
Gestión de las Adquisiciones del Proyecto
1.36. METODOLOGÍA SCRUM
Debido a que los requerimientos del cliente son pocos y se quiere que el
desarrollo del software se ágil y que hayan varios prototipos, nos definimos por
este tipo de metodología en su defecto se llega a las siguientes ventajas para el
cliente.
85
Ilustración 12. Scrum
Fuente:http://www.proyectosagiles.org/que-es-scrum
1.36.1. Las actividades de scrum.
Planificación de la iteración (sprint planning).
Ejecución de la iteración (sprint).
Reunión diaria de sincronización del equipo (ScrumDaily Meeting).
Demostración de los requisitos completados (Sprint Review).
Retrospectiva (Sprint Retrospectiva) Mantenimiento.
Planificación del proyecto.
Cierre
86
1.36.2. Que es scrum.
Es un marco de trabajo ágil que se basa en las iteraciones y entrega
incrementales de desarrollo de un producto o servicio. Las metodologías ágiles se
centran es aspectos como la flexibilidad en la introducción de cambios y nuevos
requisitos durante el proyecto, el factor humano, el producto final, la colaboración
con el cliente y el desarrollo incremental como formas de asegurar los buenos
resultados en proyectos con requisitos muy cambiantes o cuando se exige, como
es habitual, reducir los tiempos de desarrollo manteniendo una alta calidad.
SCRUM surge a mediados de los 80 y se desarrolla originalmente en el sector
TIC, pero es aplicable en cualquier proyecto en el que exista una lista de
funcionalidades o bloques de trabajo por realizar, un entorno complejo con
requisitos cambiantes y un equipo de desarrollo asignado a dicha tarea.
(Proyectalis, 2005)
87
Ilustración 13. Ciclo Scrum
Fuente: http://www.proyectalis.com/servicios/formacion/scrum/
1.36.3. Premisas principales
A los individuos y su interacción por encima de los procesos y las herramientas.
Al software que funciona, por encima de la documentación exhaustiva.
A la colaboración con el cliente, por encima de la negociación
contractual.
A la respuesta al cambio por encima del seguimiento de un plan.
88
1.36.4. Ciclo de trabajo scrum.
Toma de requisitos al cliente. Para cada requisito principal se crea un bloque
de trabajo, llamado historia
El cliente ordena los bloques de trabajo en una pila de producto según su
prioridad de entrega.
El equipo de trabajo toma un grupo de historias, con el que trabajan durante
una iteración o sprint.
Una vez finalizado un sprint entregan al cliente el resultado del trabajo. Se
vuelve al punto 2° hasta terminar la pila de producto.
1.36.5. Roles
Cada persona que interviene en el proceso de creación de un producto o servicio
tiene un rol específico en Scrum. En el ejemplo práctico veremos el papel que
desarrolla cada uno y sus funciones. (Caso práctico, 2005)
89
a. Roles Principales
ProductOwner: representa la voz del cliente. Se asegura de que el equipo Scrum
trabaja de forma adecuada desde la perspectiva del negocio. Escribe historias de
usuario, las prioriza, y las coloca en el ProductBacklog.
ScrumMaster (o Facilitador): cuyo trabajo primario es eliminar los obstáculos
que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el
líder del equipo (porque ellos se auto-organizan), sino que actúa como una
protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster
se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster
es el que hace que las reglas se cumplan.
Equipo de desarrollo. El equipo tiene la responsabilidad de entregar el
producto. Un pequeño equipo de 2 a 9 personas con las habilidades transversales
necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas,
documentación, etc.).
b. Roles Auxiliares
Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol
formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo
deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es
90
la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados (stakeholders).
c. Stakeholders
(Clientes, Proveedores, Vendedores, etc.) Se refiere a la gente que hace posible el
proyecto y para quienes el proyecto producirán el beneficio acordado que justifica
su producción. Sólo participan directamente durante las revisiones del sprint.
Administradores (Managers) Es la gente que establece el ambiente para el
desarrollo del producto. (Slideshare, 2003)
Ilustración 14. Roles
Fuente: http://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-1516220
91
1.37. MODELO PROTOTIPO
Se implementó en la idea de ayudar a comprender los requisitos que plantea el
usuario sobre todo si este no tiene una idea acabada de lo que se desea. Además
puede utilizarse cuando el ingeniero en software tiene dudas acerca de la
viabilidad de la solución pensada.
1.37.1. Modelo recomendado.
Los requerimientos no son conocidos al principio.
Coloca énfasis en la etapa de Especificación de Requerimientos a través de la
construcción de Prototipos que aproximan al usuario a la idea final del sistema con
el propósito de poder clarificar los requerimientos.
Los usuarios lo prueban y añaden requerimientos.
Se hace una implementación parcial del sistema y se prueba.
92
Ilustración 15. Modelo Prototipado
Fuente
1.37.2. Ventajas.
Reducción de incertidumbre y del riesgo, reducción de tiempo y de costos.
Incrementos en la aceptación del nuevo sistema.
Mejoras en la administración de proyectos.
Mejoras en la comunicación entre desarrolladores y clientes.
Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
93
También ofrece un mejor enfoque cuando el responsable del desarrollo del
software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debería tomar la interacción humano-máquina
1.37.3. Etapas.
Comunicación: Ingeniero de software y el cliente definen los objetivos globales
para el software, los requisitos conocidos
Plan rápido: Del uso general del prototipo se empieza con una iteración de
construcción de prototipos.
Modelado, diseño rápido: presenta el modelado.
Construcción del Prototipo: lo evalúa el usuario.
Desarrollo, entrega y retroalimentación: satisfacer las necesidades del cliente.
94
CRONOGRAMA DE ACTIVIDADES SCRUM
1.38. PLANIFICACIÓNSCRUM
Tabla 10. Planificación Scrum
Act. DETALLES
SPRINT. 1 SPRINT. 2 SPRINT. 3 SPRINT. 4 SPRINT. 5
DESCRIPCIÓN
Planificación estrategia y compromiso para desarrollar el proyecto
El nivel de seguridad no es prioritario en la aplicación.
El sistema permitirá capturar imágenes y almacenarlas desde el prototipo funcional.
El performance de la aplicación no debe exceder los 10 segundos en el reconocimiento de rostro.
El sistema contara con dos operaciones básicas capturar y autenticar.
FECHA
(1 semana) (1 mes 08/08/2012 hasta 31/08/2012)
(1 mes 03/09/2012 hasta 29/09/2012)
(1 mes 01/10/2012 hasta
29/10/2012)
(01/11/2012 hasta
26/11/2012)
Act. 1 Planificación de la iteración (Sprint Planning)
x x x X x
Act. 2 Ejecución de la iteración (Sprint) x x x X x
Act. 3 Reunión diaria de sincronización del equipo (ScrumDaily Meeting)
x x x X x
Act. 4 Demostración de los requisitos completados (Sprint Review)
x x x X x
Act. 5 Retrospectiva (Sprint Retrospectiva)
x x x X x
Act. 6 planificación del proyecto x x x X x
Act. 7 Cierre x x x X x
95
1.38.1 Estimación del Proyecto Cocomo.
El Modelo Constructivo de Costos (COCOMO, por su acrónimo del ingleses
COnstructiveCOstMOdel) es un modelo matemático de base empírica utilizado
para estimación de costos de software. Incluye tres sub modelos, cada uno ofrece
un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el
proceso de desarrollo del software: básico, intermedio y avanzado. (Proyecto
Cocomo, 1970)
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y
comienzos de los 80, exponiéndolo detalladamente en su libro "Software
EngineeringEconomics". (1981).
1.39. TRES MODOS DE DESARROLLO
1.39.1. Orgánico.
Proyectos relativamente sencillos, menores de 50 KDLC líneas de código, en los
cuales se tiene experiencia de proyectos similares y se encuentran en entornos
estables.
96
1.39.2. Semi-acoplado.
Proyectos intermedios en complejidad y tamaño (menores de 300 KDLC), donde la
experiencia en este tipo de proyectos es variable, y las restricciones intermedias.
1.39.3. Empotrado.
Proyectos bastantes complejos, en los que apenas se tienen experiencia y se
engloban en un entorno de gran innovación técnica. Además se trabaja con unos
requisitos muy restrictivos y de gran volatilidad.
1.40. MODELOS QUE DEFINE COCOMO
1.40.1. Modelo básico.
Se basa exclusivamente en el tamaño expresado en LDC.
1.40.2. Modelo intermedio.
Además del tamaño del programa incluye un conjunto de medidas subjetivas
llamadas conductores de costes.
97
1.40.3. Modelo avanzado.
Incluye todo lo del modelo intermedio además del impacto de cada conductor de
coste en las distintas fases de desarrollo.
1.41. FÓRMULAS
E = Esfuerzo = a KLDC e * FAE (persona x mes).
T = Tiempo de duración del desarrollo = c Esfuerzo d (meses).
P= Personal = E/T (personas).
Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas de
código), donde los PF y las líneas por cada PF.
Cocomo intermedio modo semilibre.
KLDC= 5
Tabla 11. Proyecto Software
Proyecto Software a e c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32
98
Tabla 12. Conductores de Costo
Conductores de coste
VALORACIÓN
Muy bajo Bajo Nominal Alto Muy alto Extr. alto
Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 -
Tamaño de la base de datos - 0,94 1.00 1,08 1,16 -
Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65
Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66
Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56
Volatilidad de la máquina virtual - 0,87 1.00 1,15 1,30 -
Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 -
Capacidad del analista 1,46 1,19 1.00 0,86 0,71 -
Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 -
Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 -
Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - -
Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - -
Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 -
Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 -
Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -
99
- FAE=0.6295
Esfuerzo = (5.000MM) (0.6295)= 3.147MM
- Cálculo del esfuerzo del desarrollo:
E = a KLDC e * FA = 3,2 * (5)^1,12 * 0.6295= 12.21 personas/mes
- Cálculo tiempo de desarrollo:
T = c Esfuerzo d = 2,5 * (12.21) ^0,38 = 6.46 meses
- Productividad:
PR = LDC/Esfuerzo = 5000/12.21 = 409 ,50 LDC/personas mes
- Personal promedio:
P = E/T = 12.21/6.46 = 1,89 personas
100
1.4.1.1 Definicion de Requerimientos.
Para trabajar el proyecto definimos los siguientes requerimientos:
- El nivel de seguridad no es prioritario en la aplicación.
- El sistema permitirá capturar imágenes y almacenarlas desde el prototipo
funcional.
- El performance de la aplicación no debe exceder los 10 segundos en el
reconocimiento de rostro.
- El sistema contara con una operación básica de capturar.
- El sistema contara con una operación básica de autenticar.
101
1.42. TABLA DE REQUERIMIENTOS
Tabla 13. Resumen de Tabla de Requerimientos
Re
f.
REQUERIMIENTO
PRIORIDAD TIPO DE
REQUERIMIENTO
Po
nd
era
ció
n
baja
me
dia
alt
a
Fu
ncio
na
l
No
fu
nc
ion
al
Pro
ces
o
Pro
du
cto
Ne
go
cio
En
torn
o
Us
ua
rio
Sis
tem
a
Inte
rfa
z
Inte
rfa
ce
1 El nivel de seguridad no es prioritario en la aplicación.
X
X
4
2 El sistema permitirá capturar imágenes y almacenarlas desde el prototipo funcional.
X X
30
3 El performance de la aplicación no debe exceder los 10 segundos en el reconocimiento de rostro.
X X
30
4 El sistema contara con una operación básica de capturar.
X X
18
5 El sistema contara con una operación básica de autenticar
X X 18
Total de Ponderación (%) 100
102
MODELACIÓN
1.43. CASOS DE USOS REALES
Ilustración 16. Diagrama de caso de uso - 0
Fuente: imagen propia
103
Ilustración 17. Diagrama de caso de uso - 1
Fuente: imagen propia
104
Ilustración 18. Diagrama de caso de uso - 2
Fuente: imagen propia
105
Ilustración 19. Diagrama de caso de uso - 3
Fuente: imagen propia
106
Ilustración 20. Diagrama de caso de uso - 4
Fuente: imagen propia
107
Ilustración 21. Diagrama de caso de uso - 5
Fuente: imagen propia
108
1.44. DIAGRAMACION DE CASOS DE USOS ACTORES
Tabla 14. Caso de Uso Usuario
Actor Usuario
Caso de uso Ingresar al programa
descripción Representa a un usuario cualquiera
comentarios No hace falta que esté dado de alta en el sistema
Tabla 15. Caso de Uso Sistema
Actor Sistema
Caso de uso Proceso
descripción Representa el proceso del sistema para reconocer patrones
comentarios Reconocer patrones
Tabla 16. Caso de Uso Cámara WEB
Actor Cámara web
Caso de uso Dispositivo
descripción Representa el dispositivo de imágenes
comentarios Este usuario es el que da la opción para capturar imágenes
109
1.45. DIAGRAMACION DE CASOS DE USOS
Tabla 17.Tabla de Uso - 0
AUTORES: FABIÁN ALBEIRO LÓPEZ
OSCAR ALEJANDRO ZAPATA
FECHA: 27 OCTUBRE DEL 2012
ACTOR: CASO DE USO: 0
Usuario, sistema, cámara web Sistema reconocimiento de rostro
DESCRIPCIÓN:
En este punto miramos completamente el funcionamiento lógico de nuestro sistema
SECUENCIA NORMAL: SECUENCIA ALTERNA:
Se carga la foto
Se procesa la imagen
Características de la imagen
Generar reporte
Tabla 18. Tabla de Uso - 1
AUTORES: FABIÁN ALBEIRO LÓPEZ
OSCAR ALEJANDRO ZAPATA
FECHA: 27 OCTUBRE DEL 2012
ACTOR: CASO DE USO: 1
Usuario, sistema, cámara web Cargar foto
DESCRIPCIÓN:
En este punto capturamos la foto con su respectivo nombre.
SECUENCIA NORMAL: SECUENCIA ALTERNA:
Damos clic detectar rostro
Se activa la cámara
Detecta el rostro y coloca un cuadro azul
Digitamos el nombre
Damos clic en guardar
No hay imágenes capturadas
Tabla 19. Tabla de Uso - 2
AUTORES: FABIÁN ALBEIRO LÓPEZ
OSCAR ALEJANDRO ZAPATA
FECHA: 27 OCTUBRE DEL 2012
ACTOR: CASO DE USO: 2
Usuario, sistema Procesar imagen
DESCRIPCIÓN:
En este punto es un sistema lógico interno.
SECUENCIA NORMAL: SECUENCIA ALTERNA:
Pasa la imagen a colores grises
Se crea una imagen bmp
Se graba la imagen en un archivo plano
Imprime la imagen de la foto en gris
110
Tabla 20. Tabla de Uso - 3
AUTORES: FABIÁN ALBEIRO LÓPEZ
OSCAR ALEJANDRO ZAPATA
FECHA: 27 OCTUBRE DEL 2012
ACTOR: CASO DE USO: 3
Sistema Extraer características
DESCRIPCIÓN:
En este punto el actor es el sistema es un proceso interno
SECUENCIA NORMAL: SECUENCIA ALTERNA:
Cargar librería en cascada de imágenes
Hace un reconocimiento de patrones
La imagen la trasforma en bits para que el sistema
pueda procesar la imagen.
Hace una seria de reconocimientos de patrones con
fórmulas matemáticas.
Buscar la imagen en proceso de bits en el archivo
plano
Tabla 21. Tabla de Uso - 4
AUTORES: FABIÁN ALBEIRO LÓPEZ
OSCAR ALEJANDRO ZAPATA
FECHA: 27 OCTUBRE DEL 2012
ACTOR: CASO DE USO: 4
Usuario, sistema Generar reporte
DESCRIPCIÓN:
En este punto nos da un reporte de la persona que está en la cámara y numero de rostros
detectados
SECUENCIA NORMAL: SECUENCIA ALTERNA:
Nos dice el nombre
Nos da el número de rostros detectados
Tabla 22. Tabla de Uso - 5
AUTORES: FABIÁN ALBEIRO LÓPEZ
OSCAR ALEJANDRO ZAPATA
FECHA: 27 OCTUBRE DEL 2012
ACTOR: CASO DE USO: 5
Sistema Datos puerto
DESCRIPCIÓN:
En este punto nos da para mandar datos por el puerto serial
SECUENCIA NORMAL: SECUENCIA ALTERNA:
Librería IO
Abrir puerto serial
Velocidad de transmisión
Datos enviados String
111
1.46. DIAGRAMAS DE SECUENCIAS
Ilustración 22. Diagrama de Secuencia
Fuente: imagen propia
112
1.47. DIAGRAMAS DE CLASES
Ilustración 23. Diagrama de Clases
Fuente: imagen propia
113
1.48. PROTOTIPOS
1.48.1. Prototipo no funcional Ilustración 24. Prototipo no Funcional
Fuente: imagen propia
114
1.48.2. Prototipo Funcional
Ilustración 25. Prototipo Funcional
Prototipo funcional
Fuente: imagen propia
115
1.48.3. Versión Beta Ilustración 26. Versión Beta
Versión Beta
Fuente: imagen propia
1.48.4. Dispositivo del Hardware Puerto serial, datos enviados OPEN com1
116
Ilustración 27. Dispositivo del Hardware Serial 1
Fuente: imagen propia
117
Ilustración 28. Dispositivo del Hardware Serial 2
Fuente: imagen propia
118
Ilustración 29. Dispositivo del Hardware Serial 3
Fuente: imagen propia
119
Ilustración 30. Dispositivo del Hardware Serial 4
Fuente: imagen propia
120
Ilustración 31. SCH
Fuente: imagen propia
121
Ilustración 32. Componentes
Fuente: imagen propia
122
Ilustración 33. PCB
Fuente: imagen propia
123
1.49. REPRESENTACIÓN DE LA ARQUITECTURA
1.49.1 Definición de la arquitectura.
La Arquitectura a utilizar será monolítica. El cliente es la aplicación que será
implementada en el lugar donde se encuentra. Se desarrollará una sola aplicación
integrada, en la que solo se permitirá el acceso a los usuarios registrados en el
sistema.
Ilustración 34. Monolítica
FUENTE:imaganes de google
1.50. METAS Y RESTRICCIONES DE LA ARQUITECTURA
La meta principal de la arquitectura del sistema es mostrar los aspectos
principales que influirán en la etapa de desarrollo.
124
Se tomarán en cuenta las siguientes metas y restricciones para el diseño de la
arquitectura del sistema:
1.50.1. Metas.
- El Sistema Reconocimiento de rostro permitirá a los usuarios acceder al
sistema desde una camara web.
- Para poder acceder al Sistema, se requiere que el usuario válido se
identifique en la camara web
- Los requerimientos de rendimiento estipulados en el documento, deben de
ser considerados como parte de la arquitectura del sistema a implementar
1.50.2. Restricciones del Sistema.
- Las computadoras que brindarán el servicio del servidor del sistema debería
presentar una potencias de un i5 tercera generación Corel, con al menos 12 Gb de
RAM y 1000 Gb de espacio en el disco duro, con un Sistema Operativo Windows y
una aceleradora de video.
125
- El uso del sistema, debe estar desarrollado en .NET.
- Cámara web de 12 mega pixeles.
1.50.2.1 Gestión de la documentación.
Esta área de gestión describe el almacenamiento y el uso compartido tanto de
documentos electrónicos como de aquellos impresos. Cuanto más grande sea un
proyecto, más difícil se torna compartir información de manera fluida con todos los
miembros del equipo y los grupos de interés. (Tipos de gestión, 2009)
Tabla 23. Gestión de la Documentación
GESTIÓN DE LA DOCUMENTACIÓN
FUNCIONALIDAD DESCRIPCIÓN
Entregable: Formato en envío de documentos
Formato electrónico, formato escrito,
Título del documento: Proyecto reconocimiento de rostro
Resumen del documento:
Se propone un desarrollo de un prototipo de software para el reconocimiento de rostro, el cual será capaz de reconocer rostros a partir de imágenes faciales capturadas a través de una cámara web. Este desarrollo de software compara paramétricamente la imagen adquirida con las que estén almacenadas en un archivo plano que el mismo software crea, se alimenta con imágenes de rostros. Se pretende desarrollar en la plataforma Microsoft conocida como .NET la cual sirve para desarrollar software, y hacer el diseño en base al procesamiento de imágenes “EIGENFACES”.
Autor: Fabián Albeiro López Castaño y Oscar Alejandro Zapata Arteaga
Fecha del Documento: 17 de Noviembre de 2012
Lugar del Documento: Universidad Católica de Pereira – Pereira – Risaralda – Colombia
Entregables de Proyecto:
Formato electrónico, formato escrito, manuales, software prototipo funcional, prototipo no funcional, análisis, requerimientos, arquitectura del sistema, estimación, plantillas de requerimiento, descripción del problema, solución propuesta, viabilidad del proyecto, tipo de metodología y tipo de modelo.
126
1.50.2.2 Gestión de versiones del proceso.
En este punto determinamos las versiones las fechas de creación y de
actualización, en todo el proceso de desarrollo, dependiendo de la actualización se
crea el tipo de versión.
Tabla 24. Gestión de Versiones del Proceso
GESTIÓN DE VERSIONES DEL PROCESO
PROCESOS FECHA
VERSIÓN CREACIÓN ACTUALIZACIÓN
Requerimientos 12/08/2011 08/09/2012 2
Descripción del problema 08/08/2011
1
Solución propuesta 08/09/2011
1
Metodología 08/02/2012
1
Actividades de la metodología 08/08/2012
1
Estimación 15/08/2011 22/10/2012 5
Casos de usos 12/02/2012
1
Diagramas 22/02/2012
2
Prototipo no funcional 09/06/2012
1
Prototipo funcional 31/08/2012 22/11/2012 5
Arquitectura 12/03/2012
1
Documento 08/08/2011 22/11/2012 10
127
1.50.2.3 Gestión de incidencias.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como
un incidente, lo que incluye a las peticiones de servicio tales como concesión de
nuevas licencias, cambio de información de acceso, etc. Siempre que estos
servicios se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura no se
considera un servicio estándar y requiere el inicio de una Petición de Cambio
(RFC) que debe ser tratada según los principios de la Gestión de Cambios.
1.51. ALTA DE INCIDENCIA
Tabla 25. Alta de Incidencias
Cód. incidencia Fecha
Nombre Apellido
Teléfono Ext
Cargo
Área
Descripción
Imagen de erros
128
1.52. PROCESO DE INCIDENCIA
Tabla 26. Proceso de Incidencias
Cód. incidencia Fecha E-mail
Nombre Apellido Teléfono Ext Cargo
Área
Descripción
Imagen de erros
Incidencia aceptada En estudio notificado de respuesta
Fecha de recibido incidencia
Incidencia con resultado
Fecha de caso de prueba
Caso de prueba
Resultado prueba
Interfaz
Fecha de respuesta de incidencia
Respuesta
Cierre exitoso del incidente
Se logró el objetivo
Nombre del reponsable
129
1.52.1 Aseguramiento de la calidad (SQA).
Para el aseguramiento de la calidad del software se tuvieron los siguiente puntos
importantes con relación al a funcionalidad del sistema, el manejo por parte del
usuario en las consultas, la seguridad de la información, eficiencia en el
funcionamiento respecto a los requerimientos mínimos de hardware y software,
etc.
130
Tabla 27. Aseguramiento de la Calidad
PROCESO DE DESARROLLO
FACTOR DE CALIDAD
DEFINICIÓN
RE
QU
ER
IMIE
NT
OS
AR
QU
ITE
CT
UR
A
CO
NS
TR
UC
CIÓ
N
Portabilidad
Se define como la característica que posee un software para ejecutarse en diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse un nuevo código cuando el software pasa de una plataforma a otra. A mayor portabilidad menor es la dependencia del software con respecto a la plataforma.
1 1 1
Funcionalidad
Función: Pruebas fijando su atención en la validación de las funciones, métodos, servicios, caso de uso.
Seguridad: Asegurar que los datos o el sistema solamente es accedido por los actores deseados.
3 3 3
Confiabilidad
Integridad: Enfocada a la valoración exhaustiva de la robustez (resistencia a fallos). Estructura: Enfocada a la valoración a la adherencia a su diseño y formación. Este tipo de prueba es hecho a las aplicaciones Web asegurando que todos los enlaces están conectados, el contenido deseado es mostrado y no hay contenido huérfano.
3 2 3
Rendimiento
Benchmark: Es un tipo de prueba que compara el rendimiento de un elemento nuevo o desconocido a uno de carga de trabajo de referencia conocido. Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar aceptablemente la demanda de múltiples actores sobre un mismo recurso (registro de recursos, memoria).
2 3 3
Compatibilidad
Es la condición que hace que un programa y un sistema, arquitectura o aplicación logren comprenderse correctamente tanto directamente o indirectamente (mediante un algoritmo). A este algoritmo que hace que un programa logre ser comprendido por un sistema, arquitectura o aplicación se lo denomina emulador por el hecho de que es un intérprete entre el programa y el sistema, arquitectura o aplicación.
3
3
3
Usabilidad Prueba enfocada a factores humanos, estéticos, consistencia en la interfaz de usuario, ayuda sensitiva al contexto y en línea, asistente documentación de usuarios y materiales de entrenamiento.
3 3 3
NIVEL DE CALIFICACIÓN
MALO 1
REGULAR 2
BUENO 3
EXCELENTE 4
131
1.52.2 La Gestión de configuraciones del software (GCS).
Actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida.
La GCS es una actividad de garantía de calidad de software que se aplica en
todas las fases del proceso de ingeniería del software.
La GCS da respuesta a las siguientes cuestiones:
- ¿Cómo identifica y gestiona una organización las muchas versiones
existentes de un programa de forma que se puedan introducir cambios
eficientemente?
- ¿Cómo controla la organización los cambios antes y después de que
el software sea distribuido al cliente?
- ¿Cómo podemos asegurar que los cambios se han llevado a cabo
adecuadamente
1.53. PLAN DE LA CONFIGURACIÓN
Se describen las actividades de gestión de configuración de software que deben
ser llevadas a cabo durante el proceso de desarrollo del proyecto. Se definen tanto
132
los productos que se pondrán bajo control de configuración como los
procedimientos que deben ser seguidos por los integrantes del equipo de trabajo.
Tabla 28. Tabla Gestión de la Configuración
FASE ELEMENTO DE CONFIGURACIÓN
SUBELEMENTO DE CONFIGURACIÓN
SUBPRODUCTO PRODUCTO
MODELO DE REQUISITOS
Levantamiento de requerimientos
Documento
Descripción del problema
Documento
Diagrama de actores y casos de uso del sistema de Gestión
Diagrama
Documentación de los actores del Sistema
Documento
Documentación de los casos de uso del sistema
Documento
Documentación de los Modelos de Interfaces
Documento
Requerimientos
RE 1 RE 2 RE 3 RE 4 RE 5 RE 6 RE 7 RE 8
Formato Formato Formato Formato Formato Formato Formato Formato
Documento
MODELO DE ANÁLISIS
Identificación de estereotipos
Documento
Diagramas de secuencia
Documento
MODELO DE DISEÑO
Diseño de objetos
Documento
133
Tabla 29. Tabla Gestión de Versiones
identificador común para cada proyecto XXX-YYY
identificador del elemento Z
ide
ntificad
or
de
la
em
pre
sa
de
so
ftw
are
ide
ntifica
do
r d
el p
royecto
Pla
n
Esp
ecific
ació
n d
e R
equ
isito
s
Docu
me
nto
de
dis
eñ
o
Lis
tado
fue
nte
Docu
me
nta
ció
n d
e p
rue
ba
Ma
nu
al d
el u
su
ario
Gu
ía d
e in
sta
lació
n
Ma
nu
al d
e m
an
ten
imie
nto
es e
l n
ive
l d
e r
evis
ión
có
dig
o d
e a
trib
uto
(fe
ch
a)
XXX YYY P R D S T U I M RL NNN
RDR FP X 1 8/12
RDR FP X 1 9/12
RDR DP X 1 9/12
RDR DP X 2 10/12
RDR GP X 1 10/12
RDR GP X 1 11/12
134
CONCLUSIONES
Tener sistemas biométricos para control de entrada y salida o cualquier tipo de
acceso es muy necesario, se encuentran muchos sistemas biométricos como el de
huella dactilar, iris, voz, firma y geometría de las manos, pero se escogió el de
reconocimiento facial o de rostro porque es uno de los que más está
incursionando y cada que avance más su investigación será cada vez más
efectivo.
Se hizo necesaria una consulta muy ardua acerca del sistema biométrico de
reconocimiento facial o de rostro por que la información que hay en la actualidad
no está muy bien definida y no está muy bien documentada.
La metodología abordada Scrum ofreció ventajas para lograr el desarrollo más
adecuado ya que proporciona constantemente resultados los cuales se pueden ir
contrastando con los requerimientos.
No se logró desarrollar totalmente la idea inicial por la complejidad y la falta de
conocimiento del tema al plantearlo por primera vez, pero se logra desarrollar la
parte esencial que es el prototipo de software que reconoce los rostros, los verifica
y los almacena en un archivo plano y con base a éste, se deja abierta la
135
posibilidad para que se pueda desarrollar otras aplicaciones y terminar la de
control de ingreso y salida del laboratorio de software.
136
Referencia Bibliográfica
A. J., Goldstein; L. D., Harmon; A. B., Lesk. (1971). "Identification of Human
Faces". California: Proc. IEEE.
Acharya, Ajoy. (2005). Image Processing: Principles and Applications.
Consultado el 2 de septiembre de 2012. Disponible desde:
http://www.palermo.edu/ingenieria/Pdf2010/CyT9/21.pdf
Bitstream. Consultado el 15 de octubre de 2012. Disponible desde:
http://biblioteca.ucp.edu.co:8080/jspui/bitstream/10785/977/1/completo.pdf
Bradski, Gary; Kaehler, Adrian. (2008). “Learning OpenCV".O'Reilly. New York:
First.
Bucm. (2009). Consultado el 3 de septiembre de 2012. Disponible desde:
http://www.ucm.es/BUCM/biblioteca/0Libro.pdf
Caballero, Sybil. (2010). Un dispositivo identifica si el usuario de un ordenador
es hombre o mujer. España: Notitebas.
137
Calderón, Nuria; Botey, García. (2008). Dos algoritmos avanzan en el
reconocimiento facial por parte de los ordenadores. Madrid: España.
Caso Práctico. Consultado el 5 de agosto de 2012. Disponible desde:
http://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-practico-
1516220
Christian, Küblbeck. (2010). Un software determina el estado de ánimo de las
personas en tiempo real. Alemania: Instituto Fraunhofer.
Dispositivo de identificación. (2007). Consultado el 20 de octubre de 2012.
Disponible desde: http://www.tendencias21.net/Un-dispositivo-identifica-si-el-
usuario-de-un-ordenador-es-hombre-o-mujer_a6185.html
Esqueda, José Jaime; Palafox, Luis Enrique. (2005). Fundamentos para el
procesamiento de imágenes. Mexicali baja california: Universidad autónoma de
baja california.
Ekman, Paul. (1972). Guía de Estudio del Facial ActionCodingSystem (FACS).
San Francisco: CodingSystem.
Evaluación del entorno. Consultado el 20 de septiembre de 2012. Disponible
desde: http://www.bogotaemprende.com/documentos/_evaluar_el_entorno.pdf
138
Gutiérrez, César. (2008). Un nuevo sistema permite controlar un vídeo con las
expresiones del rostro. California: Accenture.
Higueras, Elena. (2010). La máquina supera al hombre en reconocimiento facial.
Perú: Crónica Viva.
Küblbeck. (2010). Consultado el 2 de noviembre de 2012. Disponible desde:
http://www.tendencias21.net/Un-software-determina-el-estado-de-animo-de-las-
personas-en-tiempo-real_a1674.html
L., Sirovich; M., Kirby. (1987). "A Low-Dimensional Procedure for the
Characterization of Human Faces," J. Optical Soc. Am. A.
La máquina supera al hombre. (2010). Consultado el 12 de octubre de 2012.
Disponible desde: http://www.tendencias21.net/La-maquina-supera-al-hombre-en-
reconocimiento-facial_a4847.html
Ley 1341 de 2009. Consultado el 12 de octubre de 2012. Disponible desde:
http://www.secretariasenado.gov.co/senado/basedoc/ley/2009/ley_1341_2009.html
Ley 0527 de 1999. Consultado el 12 de octubre de 2012. Disponible desde:
http://www.secretariasenado.gov.co/senado/basedoc/ley/1999/ley_0527_1999.html
139
Li, S.; Jain, A. (2004). "Handbook of Face Recognition". New York: Springer.
M. A. Turk, A. P. Pentland. (1991). "Face Recognition Using Eigenfaces". Proc.
IEEE.
Morales, Paul D. (2007). Un software determina el estado de ánimo de las
personas en tiempo real. Europa: Instituto Fraunhofer.
Notas de mercado. Consultado el 12 de octubre de 2012. Disponible desde:
http://www.mercado.com.ar/notas/google-organic/40697/noticias-desde-
google?id=40697; http://www.paulekman.com/
Parada, Mónica. (2012). Detección de movimiento y reconocimiento facial.
Bogotá: La República.
Proyectos. Consultado el 20 de octubre de 2012. Disponible desde:
http://www.proyectalis.com/servicios/formacion/scrum/
Rdi, Press, 2011. Consultado el 22 de mayo de 2012. Disponible desde:
http://www.fi.upm.es/?id=tablon&acciongt=consulta1&idet=799
Ruiz, Salvador. (2011). Innovador sistema de reconocimiento facial. Madrid:
Asturias.
140
Scrum. Consultado el 15 de septiembre de 2012. Disponible desde:
http://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-practico-
1516220 2003
Software, detector del estado de ánimo. Consultado el 5 de septiembre de 2012.
Disponible desde: http://www.tendencias21.net/Un-software-determina-el-estado-
de-animo-de-las-personas-en-tiempo-real_a1674.html
Tendencias. Consultado el 5 de octubre de 2012. Disponible desde:
http://www.tendencias21.net/Un-software-determina-el-estado-de-animo-de-las-
personas-en-tiempo-real_a1674.html
Vision and Modeling Group. (1991). Media Laboratory. Massachusetts: Institute
of Technology.
Whitehill, Jacob. (2011). Un nuevo sistema permite controlar un vídeo con las
expresiones del rostro. California: InShare.
141
APÉNDICES
142
APÉNDICE A
ALGORITMO: Conjunto prescrito de instrucciones o reglas bien definidas,
ordenadas y finitas que permite realizar una actividad mediante pasos sucesivos
que no generen dudas a quien deba realizar dicha actividad.
ARCHIVO PLANO: Un archivo de texto llano, texto simple, texto plano, texto
sencillo o texto pelado (en inglés plaintext) es un archivo informático compuesto
únicamente por texto sin formato, sólo caracteres, lo que lo hace también legible
por humanos.
BASE DE DATOS: Es un conjunto de datos pertenecientes a un mismo contexto
y almacenados sistemáticamente para su posterior uso.
BIOMETRÍA: Es el estudio de métodos automáticos para el reconocimiento único
de humanos basados en uno o más rasgos conductuales o rasgos físicos
intrínsecos.
CRIPTOGRAFÍA: Arte o ciencia, que alteran las representaciones lingüísticas de
mensajes, mediante técnicas de cifrado y/o codificado,
DEMOGRÁFICA: Es una teoría demográfica que pretendía explicar, inicialmente,
la relación entre los cambios demográficos y los cambios socioeconómicos que se
143
produjeron en el siglo XVIII en los países desarrollados de Europa y por tanto la
relación entre población, desarrollo y crecimiento demográfico.
EIGENFACES: Son un conjunto de vectores utilizados en el problema de la
visión por ordenador de reconocimiento de rostros humanos.
FIDEDIGNOS: Los datos fidedignos son aquellos dignos de fe, creíbles, certeros.
Comparables dos o más datos que pueden tener puntos en común.
GESTIÓN DE INCIDENCIAS: Por lo que casi cualquier llamada al Centro de
Servicios puede clasificarse como un incidente, lo que incluye a las peticiones de
servicio tales como concesión de nuevas licencias, cambio de información de
acceso, etc. Siempre que estos servicios se consideren estándar.
HITO: Acontecimiento muy importante que marca un punto de referencia.
IMÁGENES EN 2D: Imágenes ordinariamente creadas por ordenador y que no
permiten (soportan) comportamientos propios de cuerpos en el espacio.
INTERACCIÓN: Es una acción recíproca entre dos o más objetos, sustancias,
personas o agentes.
144
INTERNET: Es un conjunto descentralizado de redes de comunicación
interconectadas que utilizan la familia de protocolos TCP/IP, garantizando que las
redes físicas heterogéneas que la componen funcionen como una red lógica única,
de alcance mundial.
.NET: Es un framework de Microsoft que hace un énfasis en la transparencia
de redes, con independencia de plataforma de hardwarey que permita un rápido
desarrollo de aplicaciones. Basado en ella, la empresa intenta desarrollar una
estrategia horizontal que integre todos sus productos, desde el sistema
operativo hasta las herramientas de mercado.
NORMALIZADA: Es la redacción y aprobación de normas que se establecen
para garantizar el acoplamiento de elementos construidos independientemente,
así como garantizar el repuesto en caso de ser necesario, garantizar la calidad de
los elementos fabricados, la seguridad de funcionamiento y trabajar con
responsabilidad social.
PATENTE: Es un conjunto de derechos exclusivos concedidos por un Estado a
un inventor o a su cesionario, por un período limitado de tiempo a cambio de la
divulgación de una invención.
PROTOCOLO: De forma general, es un "sistema de entendimiento entre dos
partes"; Estos pueden ser personas, grupos de individuos (países, gobiernos),
145
equipos o máquinas (computadores, sistemas análogos o digitales), o mixto (las
personas necesitan conocer un "sistema de intercomunicación" para con cualquier
máquina que deseen manipular o controlar), se recomienda siempre tener o
realizar un manual de cualquier protocolo que se establezca en cada caso
particular.
PROTOTIPO: Es un ejemplar o primer molde en que se fabrica una figura u otra
cosa.
PROTOTIPO FUNCIONAL: Operativo en sentido estricto, se ejecuta, responde a
las entradas que le proporciona el usuario participante en tiempo real y efectúa
alguna de las operaciones que se le solicitan.
PROTOTIPO NO FUNCIONAL: Cualquier tipo de aplicación en pruebas,
diseñada para una demostración de cualquier tipo.
RECONOCIMIENTO: La acción de distinguir a una cosa, una persona o una
institución entre las demás como consecuencia de sus características y rasgos se
la designa como reconocimiento.
RED DE TELECOMUNICACIONES: Una red de computadoras, también llamada
red de ordenadores, red de comunicaciones de datos o red informática, es un
conjunto de equipos informáticos y software conectados entre sí por medio de
146
dispositivos físicos que envían y reciben impulsos eléctricos, ondas
electromagnéticas o cualquier otro medio para el transporte de datos, con la
finalidad de compartir información, recursos y ofrecer servicios.
SEGURIDAD: Cotidianamente se puede referir a la seguridad como la ausencia
de riesgo o también a la confianza en algo o alguien. Sin embargo, el término
puede tomar diversos sentidos según el área o campo a la que haga referencia.
SEMIAUTOMÁTICO: Que funciona de forma mecánica pero necesita el
accionamiento del agente
SOFTWARE: Al equipamiento lógico o soporte lógico de un sistema informático,
comprende el conjunto de los componentes lógicos necesarios que hacen posible
la realización de tareas específicas, en contraposición a los componentes físicos,
que son llamados hardware.
TECNOLOGÍA: Es el conjunto de conocimientos técnicos,
ordenados científicamente, que permiten diseñar y crear bienes y servicios que
facilitan la adaptación al medio ambiente y satisfacer tanto las necesidades
esenciales como los deseos de las personas.
TIC: Las tecnologías de la información y la comunicación (TIC o bien NTIC para
nuevas tecnologías de la información y de la comunicación) agrupan los
147
elementos y las técnicas usadas en el tratamiento y la transmisión de la
información, principalmente la informática, Internet y las telecomunicaciones.
UN CASO DE USO: Es una descripción de los pasos o las actividades que
deberán realizarse para llevar a cabo algún proceso.
148
ANEXOS
149
ANEXO A
RECONOCIMIENTO FACIAL
Ilustración 35. Reconocimiento Facial
Fuente
Se emplearán avanzadas tecnologías de reconocimiento facial para proveer de
manera automática, rápida y fiable el ingreso de todos los usuarios que utilizan el
computador, para lo cual se hará el uso de la fotografía.
Además, se incluirán opciones de seguridad como por ejemplo, guarda las
imágenes de los usuarios, de los falsos intentos, de aquellos que no se pudieron
150
llevar a cabo. Algo fundamental para la seguridad del sistema, especialmente en
planteles educativos.
151
ANEXO B
PROGRAMA KEYLEMON
Ilustración 36. Programa Keylemon
Fuente
Aplicación que permite configurarse al inicio de la sesión de Windows por
reconocimiento facial. Se requiere tener una cámara que esté instalada y
permanentemente activa en el ordenador.
152
Es una funcionalidad que aporta seguridad, ya que sólo permite el uso por quien
esté identificado, se le adaptarán además opciones como la comprobación a partir
de un determinado tiempo que quien esté usando el ordenador, sea el que se
identificó al comienzo, también su temperamento, estado de ánimo, entre otros.