Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Proyecto Lector de Huella Digital
Proyecto Lector de Huella Digital
DGEST
Nombre de la Carrera
ING. SISTEMAS COMPUTACIONALES
Lugar y Fecha
Pinotepa Nal. Oax. a 09 de Diciembre de 2016.
3. JUSTIFICACIN
Al analizar la huella dactilar como mtodo de identificacin se puede establecer la
importancia que se ha dado dentro del sector de la seguridad, empresarial y en la correcta
administracin de justicia, evitando suplantaciones e infiltraciones que traen como
consecuencia fuga de informacin y perdida recursos tangibles e intangibles.
Los requerimientos primordiales de los sistemas informticos que desempean tareas
importantes son los mecanismos de seguridad adecuados a las dependencias que se intenta
proteger; el conjunto de tales mecanismos ha de incluir al menos un sistema que permita
identificar a las entidades (elementos activos del sistema, generalmente usuarios) que
intentan acceder a los objetos (la empresa en s), mediante un proceso de identificacin
dactilar.
Los sistemas que habitualmente utilizan los humanos para identificar a una persona,
como el aspecto fsico o la forma de hablar, son demasiado complejos para una
computadora; el objetivo de los sistemas de identificacin de usuarios no suele ser
identificar a una persona, sino autenticar que esa persona es quien dice ser realmente.
4. FUNDAMENTO TEORICO
UNIDAD 1: FUNDAMENTOS DE INGENIERA DE SOFTWARE.
1.1 Conceptos Bsicos
La ingeniera de software es una disciplina formada por un conjunto de mtodos,
herramientas y tcnicas que se utilizan en el desarrollo de los programas informticos
(software).
Esta disciplina trasciende la actividad de programacin, que es la actividad principal a la
hora de crear un software. El ingeniero de software se encarga de toda la gestin del
proyecto para que ste se pueda desarrollar en un plazo determinado y con el presupuesto
previsto.
La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin, el diseo
del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementacin del sistema.
Los Ingenieros de Software deben:
Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de
software, pero no es necesariamente la porcin ms larga. La complejidad y la duracin
de esta etapa est ntimamente ligada al o a los lenguajes de programacin utilizados.
Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificacin. Una tcnica de prueba es probar por separado cada mdulo del software, y
luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena
prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la
program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe
hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de
pruebas, la primera es que est compuesta por personal inexperto y que desconozca el
tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad,
que los procesos descritos son tan claros que cualquiera puede entenderlos y el software
hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas
conformada por programadores con experiencia, personas que saben sin mayores
indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin
en detalles que personal inexperto no considerara.
Documentacin
Todo lo concerniente a la documentacin del propio desarrollo del software y de la
gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de
usuario, manuales tcnicos, etc.; todo con el propsito de eventuales correcciones,
usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.
Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de
2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea
parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en
extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda
la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento.
1.3 Metodologas De Desarrollo De Software (Clsicas, Agiles y Otras Filosofas)
Qu es una Metodologa?
En el desarrollo de software, una metodologa hace cierto nfasis al entorno en el cul se
plantea y estructura el desarrollo de un sistema. Como lo mencion al principio, existen
una gran cantidad de metodologas de la programacin que se han utilizado desde los
tiempos atrs y que con el paso del tiempo han ido evolucionando. Esto se debe
principalmente a que no todos los sistemas de la informacin, son compatibles con todas
las metodologas, pues el ciclo de vida del software puede ser variable. Por esta razn, es
importante que dependiendo del tipo de software que se vaya a desarrollar, se identifique
la metodologa para el diseo de software idnea.
En qu consisten las Metodologas de Desarrollo de Software?
Una Metodologa de desarrollo de software, consiste principalmente en hacer uso de
diversas herramientas, tcnicas, mtodos y modelos para el desarrollo. Regularmente este
tipo de metodologa, tienen la necesidad de venir documentadas, para que los
Modelo en Espiral
El modelo en espiral, fue utilizado y diseado por primera vez por Barry Boehm en 1986.
Se trata nuevamente de una combinacin entre el modelo lineal o de cascada y el modelo
iterativo o basado en prototipos, sin embargo a este sistema lo que debemos aadirle es la
gestin de riesgos, algo que en los modelos anteriores ni siquiera se menciona.
Este modelo, consiste en ciertas fases que se van realizando en modo de espiral, utilizando
procesos de la misma forma en que se utilizan en el modelo de cascada, sin embargo aqu
estos no son obligatorios y no llevan precisamente el orden establecido. Bsicamente se
trata de un modelo evolutivo, que conforme avancen los ciclos, ir incrementando el nivel
de cdigo fuente desarrollada, un incremento en la gestin de riesgos y por supuesto un
incremento en los tiempos de ejecucin y planificacin del sistema, esto es lo que tiene el
modelo en espiral.
Para que tengas una idea ms clara, el modelo en espiral es principalmente utilizado para
el desarrollo de grandes proyectos como la creacin de un sistema operativo. Sin embargo
necesitas de ciertos requisitos, como el hecho de contar con personal completamente
capacitado para las funciones que se requieran. Mejor veamos cuales son las fases o tareas
dentro del modelo de espiral.
1. Determinar Objetivo. Es importante que siempre consideres una planeacin inicial,
esta solo se realizar unas ves. Sin embargo el proceso de determinar objetivos se har
constantemente durante cada iteracin que se vaya realizando con el modelo espiral. Esto
se debe a que poco a poco se ir incrementando ms el tamao del manual de usuario, los
requisitos, las especificaciones e incluso las restricciones. Todo esto entra en lo que es la
tarea de objetivos y con cada vuelta en el espiral entraremos a esta tarea, la cual como
todas las dems, es fundamental.
2. Anlisis de Riesgo. Una etapa donde incluso una lluvia de ideas podra ayudar, el
anlisis de riesgos. Aqu debers tener en cuenta todo aquello que pueda daar a tu
proyecto, ya sea que se trate de ciertas amenazas o de posibles daos que se puedan
ocasionar, teniendo adems un Plan B por as decirlo, para que en caso de que ocurra algo
inesperado, tener a la mano la solucin para continuar con el proyecto. En esta fase del
modelo espiral, podemos agregar lo que son la creacin de prototipos, pues siempre es
bueno tener un respaldo de nuestro cdigo, se esta forma en caso de que algo malo
suceda, volvemos a la versin anterior. As que cada vez que vayamos a ingresar a la fase
de pruebas e implementacin, ser necesario contar con un prototipo que nos respalde.
3. Desarrollar, Validar y Probar. Bsicamente en esta fase, la forma en que se estar
desarrollando el proyecto, depender del anlisis de riesgos, pues siempre se va a ir
desarrollando el proyecto enfocndose en los riesgos que podemos evitar en nuestro
software, es decir, si la situacin de riesgo ms obvia se encuentra en la interfaz del
usuario, entonces hay que trabajar con prototipos para este enfoque, creando evoluciones
proporcionales, para ir evitando ese tipo de riesgos. Esto no significa que ignoremos el
resto del proyecto o del desarrollo, sin embargo el modelo en espiral si acomoda un poco
ms las prioridades al momento, independientemente de todo lo dems. Por lo que
siempre en cada vuelta o iteracin que se le de al modelo de espiral, tu avance siempre
depender del anlisis de riesgo, hasta que este sea mnimo y el desarrollo pueda
continuar de forma normal.
4. Planificacin. Antes de proceder a realizar otra iteracin o vuelta al espiral, debemos
prestar atencin a lo que sucedi en la vuelta anterior. Debemos analizar detalladamente si
los riesgos encontrados ya tuvieron solucin, lo cual debe ser lo ideal, puesto que ahora
habra que analizar ms especificaciones y ms requisitos del sistema para continuar con
el desarrollo. Bsicamente la fase de planificacin, nos servir para determinar el avance
de nuestro proyecto e indicar hacia dnde vamos a dirigirnos en la prxima iteracin.
Cules son los Principios bsicos del modelo en Espiral?
Est claro que el modelo en espiral, es sumamente distinto a los dems. Encontramos por
fuera cuatro fases bien organizadas, las cules siempre deben llevar ese orden que se
estipula desde el principio. Una determinacin de objetivos, un anlisis de riesgos, el
desarrollo y las pruebas, junto con la planificacin, la cual depender de los resultados de
la iteracin para saber cmo se actuar en la siguiente vuelta al espiral.
Bsicamente, en el modelo de espiral, toda la atencin est enfocada hacia el anlisis de
riesgos, pues el objetivo primario ser reducir los riesgos que se vayan generando, de otra
forma el sistema no llegar a ser seguro jams.
Algo muy importante que debes ver en el modelo de espiral, es que los interesados deben
estar involucrados prcticamente en cada vuelta que se d al espiral, para crear lo que son
los requisitos antes de realizar una vuelta ms y al final en la fase de planificacin, se
determinan los logros obtenidos, el avance y lo que se esperar de una siguiente vuelta.
RAD: Desarrollo Rpido de Aplicaciones (Rapid Application Development)
A diferencia de otras metodologas para el desarrollo de software, la metodologa RAD o
desarrollo rpido de aplicaciones, no cuenta con una serie de fases ordenadas por as
decirlo. Aunque si est basada en lo que es el modelo de cascada y la creacin de
prototipos, sin embargo el proceso es muy independiente a contar con ciertas fases
estipuladas como los modelos que hemos visto anteriormente. As que vamos a ver los
principios del modelo RAD.
Cules son los principios bsicos del Modelo RAD?
De los mismos modos que modelos anteriores, el Modelo RAD, est basado en el uso de
las iteraciones y principalmente en el manejo de prototipos. Sin embargo a diferencia del
resto, la metodologa RAD hace uso de las Herramientas CASE, las cuales permitirn
acelerar el proceso considerablemente.
Del mismo modo que el modelo espiral y el de prototipos, RAD se subdivide en pequeas
secciones, las cuales se irn optimizando y de esta forma se ir avanzando mucho ms
rpido que con grandes segmentos que pueden volverse difciles dentro de un proceso
acelerado como lo est este modelo.
Una de las ventajas del RAD, es que el enfoque y las prioridades van hacia la fase de
desarrollo, a diferencia de modelos como el espiral, que se enfoca en que los riesgos al
momento sean mucho menores. Ac con el RAD, se hace lo contrario, si hay riesgos
reducimos los requerimientos para reducir los riesgos, no como en el espiral, que entre
ms riesgos, ms requisitos aportamos para que se incremente. Ac la idea es reducir
tiempos y no riesgos, o si, tal vez tambin, pero la reduccin de riesgos es totalmente
inversa al modelo espiral.
Por supuesto, como en todos los modelos, vas a requerir de ciertos factores
documentados, de preferencia todo lo que se pueda, para que en caso de que alguien ms
venga a continuar con este proyecto, tenga a la mano toda la informacin que necesita y
con unas cuentas lecturas pueda empezar a desarrollar lo que se haba quedado pendiente
en un determinado momento.
entre ellos vayan creando su propio entorno. Este proceso ayudar mucho ms a la
metodologa gil y por supuesto, la adaptacin ser un proceso fugaz.
Software funcional en lugar de demasiada documentacin. Crear documentacin, es
una de las actividades que con las metodologas tradicionales, absorban una gran
cantidad de tiempo. Si nos acercamos a analizaras las metodologas de antao,
descubriremos que en cada una de ellas, realizar la documentacin era una parte vital. Sin
embargo en las metodologas giles, esto ha cambiado, pues existe una regla que dice de
las siguientes forma: No producir documentacin, al menos que sean sumamente
necesarios al momento para tomar una decisin. Por lo que adems se extienda hacia el
enfoque de que la documentacin debe ser corta y breve, nada sumamente extenso que
requiera de una gran cantidad de tiempo de lectura.
Te preguntars y entonces, cuando un nuevo programador o desarrollador sea colocado en
un puesto dentro del proyecto, como sabr hacia donde ir y el enfoque que se est
llevando a cabo. Para lo cual el manifiesto gil nos dice que, existen dos elementos
fundamentales para que un nuevo miembro del equipo se ponga al da. El primero es el
cdigo fuente, pues suponiendo que es una persona conocedora, sabr hacia dnde va el
curso del proyecto con tan solo leer el cdigo. La segunda es que la interaccin con el
equipo de trabajo, ser el complemento ideal para que se acople al proyecto. De este
modo nos olvidamos de la extensa documentacin para un software que al final del da
debe estar totalmente funcional.
Colaboracin con el Cliente en lugar de hacer Contrato. Una de las cosas
importantes dentro de las metodologas giles. Es que cambia el modo en que se
trabajaba con el cliente anteriormente. Y es que en las metodologas de antao, el trabajo
consista en tener una reunin previa con el cliente para analizar los requerimientos del
sistema, aqu se analizaban las limitaciones del proyecto y se establecan los costos. Lo
que generaba cierta barrera de bloqueo entre las posibilidades de desarrollar algo
funcional para otras cosas o solo para el objetivo establecido en la reunin. Esto al final
poda ser desastroso y dificultar la llegada al xito por parte del proyecto.
Sin embargo, ahora en el manifiesto gil, se propone que exista una interaccin constante
entre el cliente y el equipo de desarrolladores. La idea es que el cliente vaya viendo cmo
va el sistema y analice nuevas funcionalidades o objetivos, ya que estos no tienen por qu
plantearse desde el principio, si el desarrollo nos puede llevar a una infinidad de
posibilidades. De esta forma el cliente al final queda totalmente satisfecho con el producto
final y habremos llegado al xito trabajando todos en equipo de forma simultnea.
Posibilidad de Hacer cambios de planes a medio proyecto. Suena ms o menos a lo
que vimos en el punto anterior, pues bsicamente la idea es evitar lo que es la planeacin
extensa y empezar a crear cdigo que permita expansin. Recordemos que con las
metodologas tradicionales, se acostumbraba a enlistar los requisitos del sistema y el
desarrollo iba enfocado solamente a eso, lo cual ya no permita que a medio desarrollo
hubiera cambios, pues era un cdigo poco moldeable y si se requeran nuevas cosas, en
algunas metodologas lo idea era volver a empezar.
La idea en las metodologas giles, es que durante el desarrollo del software, si el cliente
tiene la idea de incrementar sus objetivos, especificaciones o requerimientos, lo pueda
hacer sin ningn problema. Pues bsicamente el sistema debe ser flexible para todo lo que
pueda surgir en el proceso. De esta forma, no solamente llegaremos al xito, si no que el
cliente quedar totalmente satisfecho con el trabajo desarrollado, pues no tuvo que
conformarse con lo primero que se le vino a la mente, si no que se actualiz con las ideas
que en la marcha fueron surgiendo.
2.4 Diagramas
Informacin
1.
2.
3.
4.
1.
2.
3.
4.
1.
2.
3.
4.
estn muy claras las necesidades que hay que cubrir, o cuando se est creando un sistema
que habilitar un servicio nuevo para la organizacin.
ETHICS (Implementacin Efectiva de Sistemas Informticos desde los puntos de vista
Humano y Tcnico)
Constituye un mtodo bastante evolucionado para fomentar la participacin de los
usuarios en los proyectos. Creado por E. Mumford en 1979, coordina la perspectiva social
de los sistemas con su implementacin tcnica. Un sistema no tiene xito si no se ajusta a
los factores sociales y organizacionales que rigen a la empresa. Se busca la satisfaccin de
los empleados en el trabajo a travs de estudios integrales. Los requisitos tcnicos del
sistema sern los necesarios para mejorar la situacin de los empleados (y, por lo tanto, su
productividad) en funcin de dichos anlisis.
Puntos de Vista
Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo
diverso de interesados (stakeholders). Cada uno de estos puede tener intereses diferentes
en el sistema de software, y por lo tanto sus necesidades pueden generar requerimientos
que tengan conflicto entre s, o incluso se contradigan.
Los mtodos orientados a puntos de vista (viewpoints) toman en consideracin estas
perspectivas diferentes y las utilizan para estructurar y organizar tanto el proceso de
obtencin, como los requerimientos mismos. Uno de estos mtodos es el mtodo VORD
(Definicin de Requerimientos Orientado a Puntos de Vista), el cual provee un marco de
trabajo orientado para la obtencin y documentacin de requerimientos. Las etapas
principales de este mtodo son:
Identificacin de puntos de vista, que implica descubrir los que reciben los servicios del
sistema e identificar los servicios especficos que se suministran a cada punto de vista.
Estructuracin de puntos de vista, que comprende agrupar los relacionados en una
jerarqua. Los servicios comunes se ubican en los niveles altos de la jerarqua y se
heredan los puntos de vista de bajo nivel.
Documentacin de puntos de vista, que comprende refinar la descripcin de stos y los
servicios identificados.
Trazado del punto de vista del sistema, que comprende identificar los objetos en un diseo
orientado a objetos utilizando la informacin del servicio encapsulado en los puntos de
vista.
Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan
eventos especficos. Cada evento de interaccin distinto, o la seleccin de un servicio del
sistema, se documentan como un escenario de eventos distinto. Los escenarios de eventos
incluyen una descripcin del flujo de datos y las acciones del sistema, y documenta las
excepciones que puedan surgir.
Las convenciones para los diagramas utilizados en los escenarios de eventos son:
Los datos proporcionados desde un punto de vista o proporcionados a ste se representan
como elipses.
Las entradas y salidas de la informacin de control se ubican en la parte superior de cada
recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no estn encerradas,
significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, stas se encierran en un recuadro.
1.
2.
3.
4.
La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o
un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema
a entidades externas tales como usuarios humanos u otros sistemas.
La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organizacin, un conjunto de casos de uso coherente y consistente
promueven una imagen fcil de comprender del comportamiento del sistema, un
entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.
de
la
calidad
del
software
independiente
de
los
procesos
de
desarrollo
de
Visin
la
objetiva
administracin
de
del
la
calidad
proceso
Entre los factores que Determinan la Calidad existen dos tipos de factores:
Factores que pueden ser medidos directamente (errores/KLDC/unidad de tiempo).
Factores que solo pueden ser medidos indirectamente (la facilidad de uso o de
mantenimiento).
En ambos casos se puede medir la calidad, debemos comparar el software (documentos,
programas, etc.) con alguna referencia y llegar a una indicacin de calidad.
DEL
FACTOR
Mantenibilidad
Flexibilidad
Testeabilidad
TRANSICIN
PRODUCTO
DEL
Portabilidad
Reusabilidad
Interoperabilidad
OPERACIN
PRODUCTO
DEL
Correctitud
Confiabilidad
Eficiencia
Integridad
Usabilidad
CMM fue desarrollado por el Software Engineering Institute en estados unidos, sirve para
comprobar la habilidad de los procesos de las organizaciones para realizar determinados
proyectos.
3.-SPICE
SPCE es el modelo de madurez propuesto por ISO, similar a CMMI.
-Factores de calidad
Los factores de calidad sirven para descomponer el concepto genrico de calidad; para
facilitar su control y su medicin. Se clasifican en:
1)Factores operativos
Los factores operativos son aquellos que afectan al uso del software.
2)Factores de mantenimiento
Los factores de mantenimiento son aquellos que se aplican a la capacidad de modificacin
del software.
3)Factores evolutivos
Los factores evolutivos son aquellos que indican si el software se puede trasladar con
facilidad a otra mquina o a otro producto de base (SO, SGBD).
MTRICAS
Las mtricas del producto son una medida cuantitativa que permite a la gente del software
tener una visin profunda de la eficacia del proceso del software y de los proyectos que
dirigen utilizando el proceso como un marco de trabajo;son analizadas y evaluadas por los
administradores del software.
-VENTAJAS DEL USO DE METRICAS:
-Determina la calidad del producto.
-Evala la productividad de los desarrolladores.
-Se tiene conocimiento cuantitativo de las caractersticas del proceso y del producto.
-Se tiene un soporte para la estimacin y la planificacin.
Se evalan los beneficios (en cuanto a calidad y productividad) derivados del uso de
nuevos mtodos y herramientas de ingeniera del software.
-Establece una lnea base para la estimacin
CARACTERISTICAS DE LAS METRICAS:
-ExactasPrecisas: No se debe perder informacin en los redondeos ya que la informacin
se desvirta.
-Consistentes: Una medicin de un atributo debe dar el mismo valor independientemente
de la medicin.
1.
2.
3.
4.
5.
6.
7.
8.
ISO 9001-2000
ISO (International Standards Organization) en 1987 crea la norma ISO 9000, conjunto de
estndares que establecen los requerimientos para la gestin de los sistemas de calidad.
ISO 9000:2000 est formado por:
ISO 9000 Fundamentos y Vocabulario.
ISO 9001 Requisitos.
ISO 9004 Recomendaciones.
La parte de Requisitos - ISO 9001:2000, est estructurado en 8 secciones:
Alcance.
Normas para la Consulta.
Trminos y Definiciones.
Sistema de Gestin de la Calidad.
Responsabilidad de la Direccin.
Gestin de los Recursos.
Realizacin del Producto.
Medida, Anlisis y Mejora.
Aunque ISO 9001:2000 no otorga un estndar especfico para sistemas de desarrollo de
software, es decir, no abarca todos los procesos relacionados con el desarrollo de
software, muchas organizaciones de software han optado por gestionar su sistema de
calidad en base a este estndar, y obtener una certificacin reconocida de manera
internacional.
1.
2.
3.
4.
RUP
El Rational Unified Process (RUP) es un proceso de software desarrollado y
comercializado por Rational Software (ahora parte de IBM). RUP est diseado alrededor
de seis mejores prcticas para el desarrollo de software:
Desarrollar de manera iterativa.
Administrar los requerimientos.
Utilizar arquitecturas basadas en componentes.
Modelar el software visualmente.
Verificar la calidad de manera continua.
Controlar los cambios.
En s, RUP es una gua que define roles, actividades, flujos de trabajo y lineamientos para
ejecutar proyectos de software de acuerdo a estas mejores prcticas.
RUP organiza los proyectos de software en dos dimensiones: la del tiempo y la de las
actividades. En base al tiempo, los proyectos se dividen en cuatro fases secuenciales:
Concepcin Definicin de alcance, identificacin de riesgos.
Elaboracin Resolucin de riesgos, establecimiento de arquitectura.
Construccin Generacin del producto.
Transicin Disponibilidad a la comunidad de usuarios finales.
Las actividades se organizan en nueve diferentes disciplinas que son ejecutadas durante
las diferentes fases.
6.
Verificaciones
y
validaciones
explcitas.
7.
Manejo
de
situaciones
excepcionales.
8.
Productos
de
trabajo
con
caractersticas
mnimas
explcitas.
9. Indicadores y propuestas de mediciones para evaluar el cumplimiento de los procesos.
10. Guas de ajuste para adecuar los procesos.
5.
1 2 3
Septiembre
4 1
Octubre
4
Noviembre
1 2 3 4 1
1. Plan rpido
2. Modelado, diseo rpido
3. Construccin del Prototipo
4. Desarrollo, entrega y
retroalimentacin
5. Comunicacin
6. Entrega del desarrollo final
6.
Diciembre
4
9. En caso de ser igual se captura fecha y hora del sistema, se almacena en la base de
datos asociada con el nombre de la huella.
10. En caso de no ser igual se genera un mensaje de no registro.
11. En caso de contactar al administrador por no estar registrado se generara un nuevo
registro
7.
8.
9.
BIBLIOGRAFA