Documentacion Trabajo Final SysCam - Chañi Alarcon Martin PDF

SysCam
PROTOTIPO DE SISTEMA DE VIGILANCIA DOMESTICO CON AVISO

DE INTRUSOS A TRAVES DE SMS.
Alumno: CHAÑI ALARCON, MARTIN HORACIO
Tutor: ING. GLADIS BENITEZ
________________________
Firma Tutor
Dedicatoria
A mi madre Liduvina, quien me brindó su apoyo incondicional a lo largo de

mi vida y por su esfuerzo en concederme la oportunidad de estudiar.
Agradecimiento
A mi tutora la Ing. Gladis Benítez por su paciencia y toda la ayuda que me
brindo para concluir este trabajo.
Ingeniería en Informática
Trabajo Final: SysCam
Contenido
1 - Título del proyecto y descripción del problema ...................................................................... 4
Título: Prototipo de sistema de vigilancia doméstico con aviso de intrusos a través de
SMS. ....................................................................................................................................... 4
2 - Objetivos y metas. .................................................................................................................... 4
2.1 - Objetivo general: ........................................................................................................... 4
2.2 - Objetivos específicos:.................................................................................................... 4
2.3 - Alcance del prototipo .................................................................................................... 4
3 - Antecedentes ........................................................................................................................... 5
3.1 - Circuito cerrado de televisión: ...................................................................................... 5
3.2 - Cámaras IP:.................................................................................................................... 6
3.3 - Empresas de seguridad privada: ................................................................................... 7
4 - Justificación .............................................................................................................................. 7
5 - Marco Teórico .......................................................................................................................... 7
5.1 - Aplicación de escritorio ......................................................................................................... 7
5.2 - Computadora ........................................................................................................................ 7
5.3 - Cámara Web .......................................................................................................................... 8
5.4 - Sistema operativo: ................................................................................................................ 8
5.4.1 - Tipos de Sistemas Operativos ........................................................................................ 9
5.5 - Herramientas de desarrollo .................................................................................................. 9
5.6 - Programación por capas ....................................................................................................... 9
5.7 - Servicio de mensajes simples (SMS) ................................................................................... 10
5.8 - Ado.Net ............................................................................................................................... 10
5.9 - Access .................................................................................................................................. 12
5.10 - Librerías ............................................................................................................................. 14
5.10.1 - AForge.NET:................................................................................................................ 14
5.11 - Pruebas de Aceptación...................................................................................................... 19
5.12 - Metodologías Ágiles ...................................................................................................... 19
5.13 - Gateway SMS .................................................................................................................... 28
6 - Metodología ........................................................................................................................... 28
6.1 - SPRINT 0: ......................................................................................................................... 29
6.1.1 - Definición de los roles: ............................................................................................. 29
6.1.2 - Tipo de Usuario: ....................................................................................................... 29
6.1.3 - Definición de la pila del producto: ........................................................................... 29
6.1.4 - Historias de usuario: ................................................................................................ 29
6.1.5 – Diagrama de Clase del Prototipo ............................................................................. 30
CHAÑI ALARCON, MARTIN HORACIO 1

6.1.6 - Estimación de las Historias de Usuario para su medida. ......................................... 30

6.1.7 - Descripción de Historias de Usuario: ....................................................................... 30
6.1.8 - Priorización de las Historias de usuario ................................................................... 32
6.1.9 - Reuniones de revisión .............................................................................................. 33
6.1.10 - Herramientas ......................................................................................................... 33
6.1.11- Velocidad estimada de un Sprint ............................................................................ 33
6.1.12 - Estimación del tiempo para la construcción del producto. ................................... 33
6.2 - Planificación del Sprint 1: ................................................................................................ 35
6.2.1 - Pila del Sprint. .............................................................................................................. 35
6.2.2 - Burn Down del Sprint 1 ................................................................................................ 36
6.2.3-Retrospectiva Sprint 1:................................................................................................... 36
6.2.4-Revisión del Sprint 1: ..................................................................................................... 36
6.3 - Cálculo del nuevo valor del Factor de dedicación a partir del sprint anterior................ 38
6.4 - Cálculo de la nueva velocidad estimada. ........................................................................ 38
6.5 - Sprint 2 ............................................................................................................................ 38
6.5.1 - Pila del Sprint 2: ........................................................................................................... 39
6.5.2 - Burn Down del Sprint 2 ................................................................................................ 39
6.5.3 - Retrospectiva Sprint 2: ................................................................................................. 39
6.5.4 - Revisión del Sprint 2:.................................................................................................... 40
6.6 - Sprint 3 ............................................................................................................................ 41
6.6.1 - Pila del Sprint 3: ....................................................................................................... 42
6.6.2 - Burn Down del Sprint 3 ............................................................................................ 42
6.6.3 - Retrospectiva Sprint 3: ............................................................................................. 42
6.6.4 - Revisión del Sprint 3: ................................................................................................ 42
6.7 - Sprint 4 ............................................................................................................................ 45
6.7.1 - Pila del Sprint 4: ....................................................................................................... 45
6.7.2 - Burn Down del Sprint 4 ............................................................................................ 46
6.7.3 - Retrospectiva Sprint 4: ............................................................................................. 46
6.7.4 - Revisión del Sprint 4: ................................................................................................ 46
6.7 - Conclusión: ...................................................................................................................... 47
7 - Pruebas................................................................................................................................... 48
7.1 - Prueba de validación ....................................................................................................... 48
7.2 – Prueba unitaria ................................................................................................................... 60
7.3 – Prueba de Tiempo de Respuesta........................................................................................ 78
8 - Cronograma............................................................................................................................ 81
9 - Conclusión: ............................................................................................................................. 81

Bibliografía .................................................................................................................................. 83
Anexo .......................................................................................................................................... 86
Diseño de la Base de datos ..................................................................................................... 86
Otras librerías existentes para la detección de Movimiento .................................................. 87
AccessDatabaseEngine ............................................................................................................ 87

1 - Título del proyecto y descripción del problema

Título: Prototipo de sistema de vigilancia doméstico con aviso de intrusos a través de
SMS.
El problema que se presenta hoy en día es la inseguridad que se vive cuando las personas se
ausentan de sus hogares ya sea para ir a trabajar, a vacacionar, a visitar a un familiar, etc. En la
mayoría de los casos los hogares quedan completamente desprotegidos, a merced de cualquier
persona que desee ingresar de manera ilegal a las mismas. Lo mismo les ocurre a los dueños de
los comercios y a cualquier persona que tenga una propiedad dedicada a alguna actividad
administrativa, educativa, religiosa u otra.
En la mayoría de los casos, las personas sienten inseguridad e incertidumbre cuando dejan solos
sus hogares, ya que no tienen ninguna forma de saber si fue objeto de un robo, un asalto, o un
ingreso no autorizado que signifique un atentado a la seguridad de las personas y a sus bienes.
Existe una gran variedad sistemas de seguridad, algunos de ellos están compuestos por cámaras
de vigilancia o simplemente por una alarma, los que al detectar la presencia de intrusos accionan
la alarma ya sea sonora, un mensaje o llamadas, para dar conocimiento a las personas que
correspondan. Si bien, cualquiera de estos sistemas de seguridad alerta sobre cualquier
ocurrencia que suceda en las propiedades, estos tienen en la actualidad un “costo elevado”, ya
que el servicio es brindado por las empresas de seguridad privada.
Lo que se pretende con la realización del presente trabajo, es desarrollar un prototipo de

sistema de seguridad doméstico con aviso de intrusos y de bajo costo, que mediante la detección
de movimiento y utilizando capturas simultaneas de imágenes a gran velocidad, permite
compararlas y en caso de variación emite una alerta en forma de mensaje de texto y graba de
manera automática las imágenes en el formato video, etc. De tal manera que cualquier persona
pueda utilizarlo en su hogar y/o negocio si lo desea.
Con la utilización del prototipo se pretende generar confianza y seguridad cuando las personas
dejan sus hogares o negocios para realizar sus actividades cotidianas.
2 - Objetivos y metas.
2.1 - Objetivo general:
Desarrollar un prototipo de sistema de vigilancia doméstico con aviso de intrusos.
2.2 - Objetivos específicos:

 Detectar intrusos, por medio de la detección de movimiento.
 Grabación en video al detectar movimiento.
 Alertar a los propietarios por medio de envió de SMS sobre la presencia de intrusos.
2.3 - Alcance del prototipo

En el presente prototipo será una aplicación de escritorio, que permite la detección de
movimiento con la utilización de una cámara web y una computadora.
En el prototipo se contemplaron las siguientes funciones:
 Se pondrá énfasis en la detección de movimiento por medio de una cámara web,

empleando la librería correspondiente.
 Loguin de usuario.
 Interfaz de conexión entre la cámara web y la computadora.

 Interfaz con las funcionalidades básicas para la interacción del usuario con el prototipo.
 Grabación de video al detectar movimiento a través de la cámara web.
Limitaciones:
 No se contempla el diseño de la interfaz del usuario en su totalidad.

 El prototipo de aplicación funcionará en una computadora con un S.O. Windows.
 No se contempla la encriptación de las grabaciones de video.
 No se contempla la seguridad total del loguin del usuario.
 No se realiza modificaciones sobre la librería utilizada.
3 - Antecedentes
Existen diversos sistemas de seguridad como ser:
3.1 - Circuito cerrado de televisión:

En esencia, el CCTV es un sistema de vídeo diseñado para ser visto sólo por usuarios particulares;
la imagen no es transmitida, sino grabada o vista en un monitor específico. Originalmente, el
CCTV fue diseñado para su uso en los bancos y casinos. La señal grabada por las cámaras se
transmite en forma codificada hacia un receptor que lo descodifica. (Aarons, 2018). Su principal
característica es el de ser cerrado, es decir las imágenes se almacenan en un dispositivo de
almacenamiento para poder ser visualizadas más tarde (así como para poder ser usadas como
prueba en caso de un robo, asesinato, etc.).
Hoy en día se utiliza un CCTV denominado DVR (grabador de vídeo digital). (SeguridadSOS, s.f.).
Un DVR es un equipo especializado diseñado para trabajar con cámaras de seguridad, su función
es capturar lo que la cámara ve y enviarla al disco duro del dvr en formato digital, la compresión
de los equipos dvr pueden ser muchas, pero hoy en día la más utilizada en H.264. El dvr puede
ser configurado para que grabe por sensor de movimiento, grabación por semanas, por días,
grabación 24 horas. (PCLite, s.f.)
Una bondad de los sistemas DVR actuales es la posibilidad de poder visualizar de manera remota
todas las cámaras. Para poder lograr esto es necesario realizar una sencilla configuración tanto
en el DVR como en el enrutador de la casa u oficina.
Tipos de DVR según EMOPA (2015) son:
 DVR Analógico: suele disponer de 4, 8, 16 ó 32 canales. Se utiliza para conectar cámaras

estándar con resolución de entre 450 y 1000 líneas. La señal de video analógico de las
cámaras entra al DVR y es esté el que se encarga de digitalizar la señal y almacenarla en
el Disco Duro. Para este tipo de instalaciones lo habitual es utilizar un tipo de cable
coaxial (RG59) o en su defecto cable de red UTP al que se le conectan en ambos
extremos unos Transceptores de Video para adaptar la impedancia.
 DVR TVI/CVI/SDI: estos DVR soportan las cámaras tradicionales comentadas en el punto
anterior, así como las cámaras que dan nombre a este epígrafe (TVI/CVI/SDI) cuyo
aspecto exterior es similar a las analógicas, pero con resoluciones que pueden llegar
hasta los 2,4 Megapíxel (1080p o superior), aprovechando así todo el cableado existente
de instalaciones antiguas, en definitiva, haciendo posible realizar instalaciones de alta
definición con un coste muy inferior a sus equivalentes en IP.
 DVR IP Puro: Es un DVR orientado únicamente a la conexión de cámaras IP de alta
resolución, uniendo en un único sistema las ventajas de los sistemas analógicos con las

ventajas de las redes de comunicación IP (siempre se utiliza cableado UTP para

conectarlas). Las cámaras IP ya envían la señal codificada al DVR y al manejarse mayores
resoluciones, estos DVR deben soportar elevadas tasas de compresión para evitar altos
consumos de ancho de banda y espacio de almacenamiento. El rendimiento de este tipo
de DVR se mide en Mbps y debemos prestar especial atención a su capacidad de
procesamiento, tanto local como remotamente. Este tipo de DVR requiere la instalación
de un Switch de red para conectar todas las cámaras del sistema de videovigilancia o en
su defecto adquirir un DVR IP con Switch integrado.
 DVR Híbridos o Tribridos: Son los DVR más completos en lo que a tipos de cámaras
admitidas se refiere. Un DVR Trihíbrido se define como aquel equipo que ofrece soporte
a 3 tecnologías diferentes (normalmente son Analógica, HDCVI e IP).
Cuando se habla de NVR y NDVR, se debe aclarar: un NVR no es más que un DVR IP, y llamamos
NDVR a los DVR Híbridos que combinan varias tecnologías.
3.2 - Cámaras IP:

“Una cámara IP es un dispositivo que envía las imágenes directamente a internet sin necesidad
de una computadora con lo que nos brinda la posibilidad de ver lo que está pasando en cualquier
lugar donde me encuentre.
Algo muy importante es que, a diferencia de cualquier otro tipo de cámara, las cámaras ip no
necesitan estar conectadas a una computadora ni dependen de ella, son totalmente
independientes y autoadministrables, lo cual incrementa aún más su funcionalidad” (Ipcamaras,
s.f.).
Las cámaras IP se pueden instalar en cualquier sitio que disponga de conexión a Internet
mediante, o computador en caso que usted quiera ver o grabar en el lugar de la instalación.
Las partes de una cámara IP según MODERNA (s.f.) son:
Ilustración 1- Partes de una Cámara IP

Fuente: MODERNA (s.f.)
1.- Panel trasero: suministra la energía eléctrica al dispositivo y cuenta con un puerto RJ45
para conectividad por medio de cable UTP.
3.- Base giratoria horizontal: lo integran los modelos que permiten movimiento remoto de
la cámara.
4.- Brazo giratorio vertical: lo integran los modelos que permiten movimiento remoto de la
cámara.
5.- Visor digital: se encarga de captar las imágenes a transmitir, la mayor parte de las
cámaras IP ya cuentan con visión nocturna por medio de tecnología LED Infrarrojo.
6. - LED Ir: permiten visualizar en la oscuridad con luz infrarroja.
7. - Micrófono: se encarga de grabar el audio.

3.3 - Empresas de seguridad privada:

Estas empresas brindan servicios de seguridad por medio de la instalación de cámaras de
seguridad analógicas y/o IP fijas y Domos 360 x 180 (PTZ), externas e internas, video localización,
grabación local y/o remota. (BOXER, 2018)
4 - Justificación
Debido a la inseguridad que se registra hoy en día, podemos decir, de acuerdo a datos
estadísticos que se presentan 1066 casos de delitos contra las propiedades cada 100.000
habitantes. (Nación, 2016). La intrusión y robos a las propiedades siguen representando más de
la mitad de los delitos.
Lo que se busca es contribuir mediante una herramienta, la disminución de los delitos contra la
propiedad, desarrollando un prototipo de sistema de seguridad doméstico con aviso de intrusos
al detectar movimiento dentro de un determinado ángulo de visión, que esté monitoreado por
una cámara web. Además se pretende contribuir con una alternativa mucho más eficaz y más
confiable, para que las personas se sientan respaldadas con una herramienta de seguridad que
los alerte sobre estos eventos, enviando notificaciones en forma de SMS. Al detectar
movimiento se iniciará la captura automática de imágenes en forma de grabación de video. Este
será de bajo costo, de fácil acceso y de tal manera que con una cámara web existente en el
mercado se pueda tener un sistema de seguridad propio. Con este prototipo se trata de
conseguir que los dueños de las propiedades puedan estar informados en el caso de que ocurra
una intrusión en las mismas.
5 - Marco Teórico
Este proyecto tiene por objeto desarrollar un prototipo de una aplicación de escritorio de un
sistema de seguridad con detección de movimiento.
5.1 - Aplicación de escritorio

Aplicación de escritorio: es un programa encargado de realizar la funcionalidad del software
implementado que se instalará en la computadora.
 Ventaja de este programa será la rapidez de uso ya que podremos incorporar todos los
controles de escritorio y todos los eventos asociados a ellos.
 Desventaja es la portabilidad ya que, si lo implementamos para un entorno de
computadora, solo en equipos de ese tipo funcionará y no podremos usarla en una
Tablet o un teléfono.
5.2 - Computadora
Para que la aplicación pueda funcionar se necesita una computadora, la cual es según
Informática&Tecnología (2018):
Computadora: Una computadora es un dispositivo electrónico utilizado para el procesamiento

de datos. La misma posee dispositivos de entrada y salida (E/S) que permiten a los usuarios
interactuar con esta información.

5.3 - Cámara Web

Y una cámara web para la detección del movimiento.
Cámara Web: es un dispositivo que se conecta al puerto USB de la computadora, y así permite
captar video y tomar fotos digitales. Las posibilidades que brinda este dispositivo hacen que la
webcam sea ampliamente utilizada por todo tipo de usuarios y para diferentes propósitos.
(YSALIDA, 2017).
Las partes de una camara web según INFORMATICAMODERNA (s.f.) son:
Ilustración 2 - Partes de la Cámara Web

Fuente: MODERNA (s.f.)
1.- Visor digital: se encarga de captar las imágenes a transmitir y grabar.

2.- Grabador de audio (opcional): capta el sonido a transmitir.
3.- Base giratoria (opcional): permite colocar la cámara en la posición que el usuario decida.
4.- Cable de datos: transmite los datos de la cámara hacia la computadora.
5.- Cubierta: protege los circuitos internos y le da estética a la cámara Web.
Funcionamiento interno de la cámara según INFORMATICAMODERNA (s.f.) es:
Ilustración 3 - Funcionamiento Interno de la Cámara Web

Fuente: INFORMATICAMODERNA (s.f.)
La luz de la imagen pasa por la lente, esta se refleja en un filtro RGB (Red-Green-Blue), el cuál
descompone la luz en tres colores básicos: rojo, verde y azul.
Esta división de rayos se concentra en un chip sensible a la luz denominado CCD ("Charged
Coupled Device"), el cuál asigna valores binarios a cada píxel y envía los datos digitales para su
codificación en video y posterior almacenamiento o transmisión.
5.4 - Sistema operativo:

Para que la aplicación funcione correctamente se necesita tener en la computadora un sistema
operativo Windows XP o superior:

 Sistema operativo: Un sistema operativo puede ser definido como un conjunto de

programas especialmente hechos para la ejecución de varias tareas, en las que sirve de
intermediario entre el usuario y la computadora (TECNOLOGIA&INFORMATICA, 2018).
Este conjunto de programas maneja el hardware de una computadora u otro dispositivo
electrónico. Provee de rutinas básicas para controlar los distintos dispositivos del equipo
y permite administrar, escalar y realizar interacción de tareas.
5.4.1 - Tipos de Sistemas Operativos

Existen distintos sistemas operativos a continuación se nombran los más relevantes:
 Windows: Windows es un sistema operativo producido por Microsoft Corporation. Está

diseñado para uso en PC, incluyendo equipos de escritorio en hogares y oficinas, equipos
portátiles y notebooks.
 Mac OS: Mac OS (del inglés Macintosh Operating System, en español Sistema Operativo
de Macintosh) es el nombre del sistema operativo creado por Apple para su línea de
computadoras Macintosh. Es conocido por haber sido uno de los primeros sistemas
dirigidos al gran público en contar con una interfaz gráfica compuesta por la interacción
del mouse con ventanas, iconos y menús. (Gino, s.f.)
 Linux: un sistema operativo consiste en varios programas fundamentales que necesita
el ordenador para poder comunicar y recibir instrucciones de los usuarios (Debian,
2018). El código de este sistema es abierto, distribuido y desarrollado libremente. Se
focaliza más en los beneficios prácticos (acceso al código fuente) que en cuestiones
éticas o de libertad que tanto se destacan en el software libre.
5.5 - Herramientas de desarrollo

Para el desarrollo del prototipo de la aplicación se incorporará un conjunto de herramientas:
 Visual Studio .NET: es un conjunto completo de herramientas de desarrollo para la

construcción de aplicaciones Web ASP, servicios Web XML, aplicaciones para escritorio
y aplicaciones móviles. Visual Basic .NET, Visual C++ .NET, Visual C# .NET y Visual J# .NET
utilizan el mismo entorno de desarrollo integrado (IDE), que les permite compartir
herramientas y facilita la creación de soluciones en varios lenguajes. Asimismo, dichos
lenguajes aprovechan las funciones de .NET Framework, que ofrece acceso a tecnologías
clave para simplificar el desarrollo de aplicaciones Web ASP y servicios Web XML. (msn,
2018)
5.6 - Programación por capas

La programación por capas se refiere a un estilo de programación que tiene como objetivo
separar responsabilidades de la tal manera que cada capa cumpla una función específica y
diferente a las demás. (Perpiñan, 2017). Una de las ventajas que podemos destacar sobre este
estilo es que el desarrollo del software se puede llevar a cabo en varios tipos de niveles, así,
cuando suceda algún cambio solo nos iremos sobre el nivel requerido. (Elecristy, 2014)
Existen muchos enfoques posibles para este estilo, pero el más común es la programación de 3
capas. Según Gutiérrez (2014) las 3 capas se definen como:
 Capa de presentación: Es todo lo visible al usuario, le muestra y captura toda la

información la necesaria con un mínimo de procesos. Ésta capa se comunica únicamente
con la capa de negocios, también se conoce como interfaz gráfica y tiene como
característica principal, el ser “amigable” con el usuario.

 Capa de negocios: Es donde se reciben las peticiones del usuario (capa de presentación)
y se envían las respuestas tras el proceso. Recibe este nombre o también lógica de
negocios, porque aquí se establecen todas las reglas que se deben cumplir. Se comunica
con la capa de presentación para recibir solicitudes y presentar resultados y con la capa
de datos para almacenar o solicitar datos.
 Capa de datos: Es la encargada del almacenado de los datos y la recuperación de los
mismos. Está compuesta por uno o más gestores de bases de datos. Se comunica
únicamente con la capa de negocios para recibir las peticiones de almacenaje o
recuperación de datos.
5.7 - Servicio de mensajes simples (SMS)

Más conocido como SMS (por las siglas del inglés Short Message Service), es un servicio
disponible en los teléfonos móviles que permite el envío de mensajes cortos, conocidos como
mensajes de texto entre teléfonos móviles.
SMS es una cadena alfanumérica de hasta 140 caracteres o de 1603 caracteres de 7 bits, y cuyo
encapsulado incluye una serie de parámetros. En principio, se emplean para enviar y recibir
mensajes de texto normal, pero existen extensiones del protocolo básico que permiten incluir
otros tipos de contenido, dar formato a los mensajes o encadenar varios mensajes de texto para
permitir mayor longitud.
5.8 - Ado.Net
ADO .NET es un conjunto de clases que pueden ser usados para interactuar con orígenes de
datos, como por ejemplo una base de datos, archivos XML, archivos Excel, etc.
ADO .NET es una tecnología de acceso a datos del marco de trabajo Microsoft .NET que
proporciona comunicación entre sistemas relacionales y no relacionales por medio de un
conjunto común de componentes.
ADO .NET es un conjunto de componentes de software de computadora que los programadores

usan para acceder datos y servicios de datos de una base de datos. Es parte de la librería de
clases que está incluida con el marco de trabajo Microsoft .NET. Es comúnmente utilizada por
los programadores para acceder y modificar datos almacenados en sistemas de bases de datos
relacionales, pero también pueden acceder datos en orígenes de datos no relacionales.
ADO .NET a veces es considerado una evolución de la tecnología ActiveX Data Objects (ADO),
pero en realidad es un producto completamente nuevo. ADO .NET puede ser usado en
aplicaciones web, en aplicaciones para escritorio y en aplicaciones de consola. (Velásquez, s.f.)
Acceso los datos con ADO.NET:

Sin importar la operación que se desee realizar los pasos son:
o Abrir la conexión
o Ejecutar los comandos
o Cerrar la conexión
Ilustración 4 - Objetos comunes de ADO.NET

Fuente: Rafael (s.f.)
ADO.NET proporciona un modelo de objetos común para proveedores de datos de .NET. A

continuación, se describe los principales objetos ADO.NET que utilizaremos en un escenario
desconectado. (Rafael, s.f.)
 Provider: un proveedor de datos ADO.NET es un componente de software que interactúa

con una fuente de datos. Los proveedores de datos ADO.NET son análogos a los
controladores ODBC, los controladores JDBC y los proveedores OLE DB.
Los proveedores de ADO.NET se pueden crear para acceder a almacenes de datos
simples como archivos de texto y hojas de cálculo, a bases de datos tan complejas como
Oracle Database, Microsoft SQL Server, MySQL, PostgreSQL, SQLite, IBM DB2, Sybase
ASE y muchos otros. También pueden proporcionar acceso a almacenes de datos
jerárquicos, como los sistemas de correo electrónico.
 Connection: Establece y gestiona una conexión a una fuente de datos específica. Por
ejemplo, la clase OleDbConnection se conecta a fuentes de datos OLE DB.
 Command: ejecuta un comando en una fuente de datos. Por ejemplo, la clase
OleDbCommand puede ejecutar instrucciones SQL en una fuente de datos OLE DB.
 DataSet Diseñado para acceder a datos con independencia de la fuente de datos. En
consecuencia, podemos utilizarlo con varias y diferentes fuentes de datos, con datos XML,
o para gestionar datos locales a la aplicación. El objeto DataSet contiene una colección de
uno o más objetos DataTable formados por filas y columnas de datos, además de clave
principal, clave foránea, restricciones e información de la relación sobre los datos en los
objetos DataTable.
 DataReader: proporciona un flujo de datos eficaz, sólo-reenvío y de sólo-lectura desde una
fuente de datos.
 DataAdapter: utiliza los objetos Connection, Command y DataReader implícitamente para
poblar un objeto DataSet y para actualizar la fuente de datos central con los cambios
efectuados en el DataSet. Por ejemplo, OleDbDataAdapter puede gestionar la interacción
entre un DataSet y una a base de datos Access. DataAdapter es una parte del proveedor
de datos ADO.NET. DataAdapter proporciona la comunicación entre el Dataset y el

Datasource, funciona como un puente entre una fuente de datos y una clase de datos
desconectada, como un DataSet.
El modo de funcionamiento típico de ADO.NET es el siguiente en un entorno desconectado:
 Se crean un objeto Connection especificando la cadena de conexión.

 Se crea un DataAdapter.
 Se crea un objeto Command asociado al DataAdapter, con la conexión adecuada y la
sentencia SQL que haya de ejecutarse.
 Se crea un DataSet donde almacenar los datos.
 Se abre la conexión.
 Se rellena el DataSet con datos a través del DataAdapter.
 Se cierra la conexión.
 Se trabaja con los datos almacenados en el DataSet.
5.9 - Access
Microsoft Access es una de las aplicaciones que vienen incluidas en la suite ofimática Microsoft
Office en su versión profesional. Y es una de esas aplicaciones que por desconocimiento la
mayoría de las veces nunca abrimos.
Es un sistema manejador de base de datos. Una base de datos permite manipular información
organizada y optimizada para reducir el espacio que ocupan los datos y permiten la consulta ágil
y eficiente de la información. En el caso de Access, es un manejador de bases de datos relacional.
La información se organiza en tablas. Entre las tablas se establecen relaciones que permiten unir
tablas. Es posible crear consultas sencillas o complejas para ver información. Con Microsoft
Access puede crear una base de datos, modificar su estructura, actualizar la información
presente. Además, puede hacer consultas muy eficientes que le permiten accesar a la
información que cumple con determinadas condiciones.
Con Microsoft Access también puede tener acceso a información almacenada en fuentes de
datos externas, por ejemplo, bases de datos creadas en otros manejadores de bases de datos o
información almacenada en Microsoft Excel. La información almacenada en una base de datos
de Access también puede ser accedida por otras aplicaciones o programas.
Los usuarios de Microsoft Access tienen a disposición el lenguaje SQL (Structured Query
Languaje), el cual brinda comandos que permiten acceder a la información de múltiples formas.
Fácilmente puede ver la información organizada por diferentes criterios. Puede adicionar
registros o eliminar registros. (MisApuntesSistemas, 2012)
Herramientas que ofrece Access más relevantes:

Tablas
Es la forma más simple, en ellas almacenamos los datos de forma estructurada. (Angel, 2012)
Ilustración 5 – Tabla
Fuente: Angel (2012)
Consultas
De las tablas, si queremos, podemos extraer información filtrada según nuestras necesidades,
actualizar datos concretos, o eliminar ciertos registros que cumplan una determinada condición.
Para todo y mucho más se usan las consultas. (Angel, 2012)
Ilustración 6 – Consulta
Formularios
Esta es la parte más amigable de nuestra base de datos. Usamos los formularios para trabajar
con la base de datos, estos están vinculados a las tablas y nos ofrecen una forma más práctica y
estética, según el gusto y el empeño que le ponga el usuario, para trabajar con la información.
(Angel, 2012)

Ilustración 7 - Diseño Formulario

Microsoft Access nos proporciona herramientas suficientes para incluir textos, botones,
imágenes y muchas más cosas, además de ofrecernos plantillas y temas que nos cambian todos
los colores y tipos de letras de nuestros formularios con apenas unos clics. (Angel, 2012)
Informes
Como máximo exponente tenemos los informes que podemos configurar a nuestro gusto y
antojo, con los datos que nos apetezca, colores, gráficas y posición de los mismos según nos
plazca. (Angel, 2012)
Ilustración 8 – Reporte
5.10 - Librerías
Existen varias librerías para la detección de movimiento, para la realización de este prototipo se
utilizará:
5.10.1 - AForge.NET:
El autor de esta librería es Andrew Kirillov, esta librería nos permite realizar toda clase de
operaciones, desde un sencillo cambio de color a blanco y negro a una imagen. “Es un framework
de código abierto de C# diseñado para desarrolladores e investigadores en los campos de Visión

por Computador, procesamiento de imágenes, aprendizaje automático, robótica, entre otros”.

(Aforge, 2018).
Está compuesto por el conjunto de bibliotecas y aplicaciones de muestra, que demuestran sus
características, según Aforge (2018) esta son:
 AForge.Imaging: biblioteca con rutinas y filtros de procesamiento de imágenes.

 AForge.Vision: biblioteca de visión por computadora.
 AForge.Video: conjunto de bibliotecas para procesamiento de video.
 AForge.Neuro: biblioteca de computación de redes neuronales.
 AForge.Genetic: biblioteca de programación de evolución.
 AForge.Fuzzy: biblioteca de computación difusa.
 AForge.Robotics: biblioteca que proporciona soporte de algunos kits de robótica.
 AForge.MachineLearning: biblioteca de aprendizaje automático.
Visión Computacional:
La visión computacional trata de emular en las computadoras la capacidad que tienen nuestros
ojos. Es decir, trata de interpretar las imágenes recibidas por dispositivos como cámaras y
reconocer los objetos, ambiente y posición en el espacio. (Loyo, s.f.)
Un área muy ligada a la de visión computacional es la de procesamiento de imágenes. Ahora

bien, debemos considerar que la visión computacional y el procesamiento de imágenes son
cuestiones diferentes. El procesamiento de imagen trata sobre cómo mejorar una imagen para
su interpretación por una persona mientras que la visión computacional trata de interpretar las
imágenes por la computadora (Sucar, s.f.).
Para la realización del prototipo se utilizará los siguientes componentes de la librería:
 Detección de movimiento con Aforge.net
AForge.NET framework proporciona un conjunto de clases que implementan diferentes

algoritmos de detección de movimiento y procesamiento de movimiento. Los algoritmos de
detección de movimiento están destinados únicamente a detectar el movimiento en cuadros de
video (Imagen Dinámica) continuos que proporcionan la cantidad de movimiento detectado y el
cuadro de movimiento: imagen binaria (Imágenes Bitmaps), que muestra todas las regiones
donde se detecta movimiento. Los algoritmos de procesamiento de movimiento están
destinados a realizar el procesamiento posterior del movimiento detectado: resaltar regiones
de movimiento, contar objetos en movimiento, rastrearlos, etc. (Aforge, s.f.)
 AForge.Vision
Según Aforge (2018) es una bbiblioteca para el desarrollo de visión computacional, utilizando
la detección de movimiento y el procesamiento de secuencias de fotogramas de video.
AForge.Vision.Motion
Contiene interfaces y clases utilizadas para la detección y el procesamiento de movimiento en

transmisiones de video. (Framework, 2013)

Conceptos generales
Debido a que este prototipo se utilizara en el campo de la visión computacional, es necesario
introducir algunos de los elementos básicos el procesamiento de imágenes. Quispe Aduviri
(2013) afirma que estos conceptos son:
 Imágenes Bitmaps
Las imágenes en mapa de bits se las suele definir por su altura y anchura (en píxeles) y por su
profundidad de color (en bits por píxel), creando una gran cantidad de cuadritos rellenos de un
color uniforme, dando una sensación visual de integración en la retina, por la luminosidad entre
pixeles vecinos. Las imágenes bitmaps no permiten el cambio de escala.
 Imagen Estática
Es una representación de un objeto, real o ficticio, en un instante en el tiempo.
 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. El problema de la visión dinámica es que se compone de una secuencia de frames o
fotogramas interrelacionados, donde cada fotograma representa la escena en un determinado
instante de tiempo t.
Ilustración 9 - Fotogramas de una secuencia de imágenes a través del tiempo.

Fuente: Quispe Aduviri (2013).
Debemos entender un sistema de visión dinámica como un conjunto de coordenadas espaciales

(x,y) dentro de cada fotograma y además añadir un tercer parámetro como sería el tiempo t,
permitiéndonos su combinación la descripción de la entrada de un sistema de visión dinámica
como una función F(x,y,t). La entrada en juego del parámetro t es fácil de entender si se tiene
en cuenta los posibles cambios que pueden darse en la escena, ya sea debido al movimiento de
la escena en sí misma, de la cámara o de ambos. En el trabajo que se trata, ese movimiento de
cámara no va a producirse, debido a que las secuencias de imágenes serán captadas mediante
una cámara estática. Para procesar información dinámica se podrán aplicar técnicas estáticas a
cada fotograma por separado o analizar una secuencia de forma continúa.
 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.

 FPS de video
Las FPS también conocido como cuadros por segundo, son frames por segundo, ósea las
imágenes que captura la cámara en cada segundo. Si grabas a 60fps el vídeo está compuesto
por 60 "fotos" por unidad de tiempo. En cambio, si grabas a 30, sólo son 30 fotos.
El término se aplica por igual a películas y cámaras de vídeo, gráficos por computadora y
sistemas de captura de movimiento.
 Algoritmos de detección de movimiento
 Detector de movimiento de diferencia de dos cuadros.
Es el detector más simple y rápido. Se basa en encontrar la diferencia entre dos fotogramas
consecutivos. Cuanto mayor es la diferencia, mayor es el nivel de movimiento (Aforge, s.f.). Este
detector no es recomendado para resaltar objetos en movimiento, pero sí cuando solo se
necesita detectar si sólo hay movimiento o no. En la imagen se puede apreciarse en rojo, la
diferencia que se produce entre dos fotogramas consecutivos con una persona desplazándose
de izquierda a derecha.
Ilustración 10 - Detector de movimiento de diferencia de dos cuadros

Fuente: Aforge (s.f)
 Detector de movimiento de modelado de fondo simple
Según Aforge (s.f.): a diferencia del detector de movimiento mencionado anteriormente, este
detector de movimiento se basa en encontrar la diferencia entre el cuadro de video actual y un
cuadro que representa el fondo. Este detector de movimiento intenta usar técnicas simples para
modelar el fondo de la escena y actualizarlo a lo largo del tiempo para tener en cuenta los
cambios de la escena. La función de modelado de fondo de este detector de movimiento brinda
la capacidad de resaltar de manera más precisa las regiones de movimiento.

Ilustración 11 - Detector de movimiento de modelado de fondo simple

Fuente: Aforge (s.f.)
 AForge.Video
Según Aforgenet (2018) la biblioteca AForge.Video contiene diferentes clases, que proporcionan
acceso a datos de video. Es bueno tener en cuenta la cantidad de material de procesamiento de
imágenes en el marco.
Proporciona clases para acceder a cámaras web USB y archivos de video utilizando DirectShow
API. Dado que todas las clases implementan una interfaz común, acceder a la cámara USB es tan
fácil como acceder a archivos de video o flujos JPEG / MJPEG.
Esta librería permite:
 Acceso a las transmisiones JPEG y MJPEG, que permite el acceso a cámaras IP;
 Acceso a cámaras web USB, dispositivos de captura y archivos de video a través de la
interfaz DirectShow.
DirectShow:
Es un conjunto de interfaces que proporcionan un API genérico con el que se puede capturar y
reproducir audio y vídeo sin importar la marca o modelo de cámara que utilicemos. También
permite la grabación y reproducción de archivos en cualquier formato. (Kusztrich, 2016)
DirectShow está diseñado para C++. Microsoft no proporciona una API administrada para
DirectShow. (Microsoft, 2018)
 Lectura/escritura de archivos AVI usando la interfaz Audio para Windows.

 Lectura/escritura de archivos de video usando la biblioteca FFmpeg.
FFmpeg:
Según Gutl (2014) es una colección de software libre que puede grabar, convertir
(transcodificar) y hacer streaming de audio y vídeo. Incluye libavcodec, una biblioteca
de códecs. FFmpeg está desarrollado en GNU/Linux, pero puede ser compilado en la mayoría de
los sistemas operativos, incluyendo Windows.
 Soporte del sensor de Microsoft Kinect.

 Soporte de cámaras XIMEA.
 Contenedor de fuente de video asincrónico.

5.11 - Pruebas de Aceptación

Cuando se construye software a medida para un cliente, se realiza una serie de pruebas de
aceptación a fin de permitir al cliente validar todos los requerimientos. Realizada por el usuario
final en lugar de por los ingenieros de software, una prueba de aceptación puede variar desde
una “prueba de conducción” informal hasta una serie de pruebas planificadas y ejecutadas
sistemáticamente.
De hecho, la prueba de aceptación puede realizarse durante un periodo de semanas o meses, y

mediante ella descubrir errores acumulados que con el tiempo puedan degradar el sistema.
Si el software se desarrolla como un producto que va a ser usado por muchos clientes, no es
práctico realizar pruebas de aceptación formales con cada uno de ellos. La mayoría de los
constructores de productos de software usan un proceso llamado prueba alfa y prueba beta
para descubrir errores que al parecer sólo el usuario final es capaz de encontrar.
La prueba alfa se lleva a cabo en el sitio del desarrollador por un grupo representativo de
usuarios finales. El software se usa en un escenario natural con el desarrollador “mirando sobre
el hombro” de los usuarios y registrando los errores y problemas de uso. Las pruebas alfa se
realizan en un ambiente controlado.
La prueba beta se realiza en uno o más sitios del usuario final. A diferencia de la prueba alfa, por
lo general el desarrollador no está presente. Por tanto, la prueba beta es una aplicación “en
vivo” del software en un ambiente que no puede controlar el desarrollador. El cliente registra
todos los problemas (reales o imaginarios) que se encuentran durante la prueba beta y los
reporta al desarrollador periódicamente. Como resultado de los problemas reportados durante
las pruebas beta, es posible hacer modificaciones y luego preparar la liberación del producto de
software a toda la base de clientes.
En ocasiones se realiza una variación de la prueba beta, llamada prueba de aceptación del
cliente, cuando el software se entrega a un cliente bajo contrato. El cliente realiza una serie de
pruebas específicas con la intención de descubrir errores antes de aceptar el software del
desarrollador.
En algunos casos (por ejemplo, un gran corporativo o sistema gubernamental) la prueba de

aceptación puede ser muy formal y abarcar muchos días o incluso semanas de prueba.
(Pressman, 2010, pág. 400)
5.12 - Metodologías Ágiles

Las metodologías ágiles son un conjunto de técnicas, métodos y herramientas para gestionar y
desarrollar proyectos de software donde los requisitos evolucionan para adaptarse a las
necesidades del proyecto. Son muy útiles para visualizar y organizar las tareas a realizar y para
mejorar el rendimiento y el trabajo en equipo. (Wingu, 2016). Lo que se buscar es obtener
rápidamente resultados (incrementos) para satisfacer a las necesidades de los clientes.
Si bien existen otras metodologías llamadas clásicas o tradicionales (como ser cascada, RUP,
Espiral). Estas tienen ciertas desventajas con respecto a las metodologías agiles, como la
resistencia a ciertos cambios repentinos, proceso mucho más controlado con numerosas
políticas/normas, gran cantidad de documentación, entre otros. Debido a esto es que para el
desarrollo del prototipo se optó por una metodología ágil
A continuación, se describirán dos metodologías agiles:

 Programación Extrema XP
Según Yolanda (2013): XP es una metodología ágil para el desarrollo de software y consiste
básicamente en ajustarse estrictamente a una serie de reglas que se centran en las necesidades
del cliente para lograr un producto de buena calidad en poco tiempo, centrada en potenciar las
relaciones interpersonales como clave para el éxito del desarrollo de software.
La filosofía de XP es satisfacer al completo las necesidades del cliente, por eso lo integra como
una parte más del equipo de desarrollo.
Roles en XP
 Programador El programador escribe las pruebas unitarias y produce el código del

sistema. Debe existir una comunicación y coordinación adecuada entre los
programadores y otros miembros del equipo.
 Cliente: escribe las historias de usuario y las pruebas funcionales para validar su
implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles
se implementan en cada iteración centrándose en aportar mayor valor al negocio. El
cliente es sólo uno dentro del proyecto, pero puede corresponder a un interlocutor que
está representando a varias personas que se verán afectadas por el sistema.
 Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las
pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el
equipo y es responsable de las herramientas de soporte para pruebas.
 Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona
realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de
acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los
resultados para mejorar futuras estimaciones. También realiza el seguimiento del
progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones
de tiempo y recursos presentes. Determina cuándo es necesario realizar algún cambio
para lograr los objetivos de cada iteración.
 Entrenador (Coach) Es responsable del proceso global. Es necesario que conozca a
fondo el proceso XP para proveer guías a los miembros del equipo de forma que se
apliquen las prácticas XP y se siga el proceso correctamente.
 Consultor Es un miembro externo del equipo con un conocimiento específico en algún
tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
 Gestor (Big boss) Es el vínculo entre clientes y programadores, ayuda a que el equipo
trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinación.
Presenta las siguientes fases:
 Exploración
 Planificación de la Entrega (Release)
 Iteraciones
 Producción
 Mantenimiento
 Muerte del Proyecto.
Fase I: Exploración
En esta fase, los clientes plantean a grandes rasgos las Historias de Uuario que son de interés
para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza

con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la

tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un
prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del
tamaño y familiaridad que tengan los programadores con la tecnología.
Fase II: Planificación de la Entrega

En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimación del esfuerzo necesario de
cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina
un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres
meses. Esta fase dura unos pocos días. Las estimaciones de esfuerzo asociado a la
implementación de las historias la establecen los programadores utilizando como medida el
punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente
valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la
“velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la
suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última
iteración. La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad
del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una
fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar
por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto,
determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema,
se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del
proyecto, obteniendo el número de iteraciones necesarias para su implementación. El resultado
de esta fase es un Plan de Entregas, o “Release Plan”
Fase III: Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega
está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede
intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del
proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin
embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se
implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última
iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse
en cuenta durante la elaboración del Plan de la Iteración son: Historias de Usuario no abordadas,
velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no
terminadas en la iteración anterior.
Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es
asignada a un programador como responsable, pero llevadas a cabo por parejas de
programadores.
Fase IV: Producción

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que
el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones
sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta
fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas
que han sido propuestas y las sugerencias son documentadas para su posterior implementación
(por ejemplo, durante la fase de mantenimiento). En esta fase no se realizan más desarrollos
funcionales, pero pueden ser necesarias tareas de ajuste (“fine tuning”).

Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el
sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar
esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo
puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede
requerir nuevo personal dentro del equipo y cambios en su estructura.
Fase VI: Muerte del Proyecto

Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se
satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del
sistema. Se genera la documentación final del sistema y no se realizan más cambios en la
arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios
esperados por el cliente o cuando no hay presupuesto para mantenerlo.
 Scrum
SCRUM es un proceso de desarrollo de software “iterativo e incremental utilizado comúnmente

en entornos de desarrollo ágiles de software” (KABEL, 2012). SCRUM ayuda a que trabajen todos
juntos, en la misma dirección, con un objetivo claro. Permite además seguir de forma clara el
avance de las tareas a realizar, de forma que los " Scrum Master " puedan ver día a día cómo
progresa el trabajo.
SCRUM posee los siguientes aspectos:
1. Desarrollo iterativo e incremental, con el objetivo de obtener un producto de software.

2. Ágil: La división del trabajo en pequeñas unidades funcionales (SPRINTS: es un evento con
un tiempo acotado (de hasta un mes) en el que se debe entregar “un entregable terminado
y funcional”.) permite mantener una política de entregas frecuentes de software que
ofrecen una visión clara del estado del proceso y permite la introducción de
modificaciones.
3. Simple: Se centra especialmente en facilitar el desarrollo rápido, por lo que su complejidad
(por ejemplo, desde el punto de vista de la documentación a generar o de la organización
de equipos) se ha tratado de reducir al máximo.
4. Flexible: Todo el desarrollo se contempla como un ciclo de iteraciones continuas de
desarrollo, lo que facilita la introducción de modificaciones “sobre la marcha”, mejorando
continuamente el proceso.
5. Colaborativa: El planteamiento, desde el punto de vista de la organización del equipo,
resulta bastante horizontal (en contraposición a una organización jerárquica férrea),
otorgando a los miembros del equipo de desarrollo un elevado grado de autonomía y
autoorganización de su trabajo.
SCRUM propone las siguientes fases:
 Fase de Planificación:
 Planeación: se define el equipo, herramientas, el sistema de desarrollo y se crea el
product backlog con la lista de requerimientos conocidos junto con sus prioridades y se
estima el esfuerzo necesario para llevarlo a cabo.
 Diseño Arquitectónico: se define la arquitectura del producto que permita implementar
los requerimientos.
 Fase de Desarrollo: es la parte ágil, donde el sistema se desarrolla en Sprints.

 Fase de Finalización: incluye integración, pruebas (testing) y documentación. Indica la

implementación de todos los requerimientos, quedando el product backlog vacío.
El Scrum está formado por los siguientes elementos:
 Roles en el proyecto:
- Scrum Master: es el responsable que se cumplan las practicas del Scrum y que la velocidad
del equipo no se vea frenada por problemas en el proceso ágil y de que los problemas,
obstáculos, impedimentos se resuelvan. Ayuda a los miembros del equipo a tomar
decisiones responsables y los asesora en todas las maneras posibles para que alcancen sus
objetivos.
- Equipo de Desarrollo (Team): grupo o grupos que desarrollan el trabajo (son los que
desarrollan el software, poseen las capacidades técnicas para fabricar el producto).
- Propietario del producto (Product Owner): El propietario del producto (product owner)
es quien toma las decisiones del cliente. Su responsabilidad es el valor del producto.
(Manager, 2016)
 Artefactos:
- Pila del producto (product backlog): Listado de requerimientos priorizados, público a todo
el equipo del proyecto e interesados y frecuentemente actualizado. Cada funcionalidad de
la pila del producto se refiere a funcionalidades entregables, no a trabajos internos del
tipo, por ejemplo: “diseño de la base de datos”.
Priorización
La prioridad de la pila del producto está dada por las funcionalidades más urgentes que debe
contener la versión requerida por el propietario del producto, refinadas por el Scrum Team. La
escala de prioridad se realizará de la siguiente manera:
ID Descripción
Está definida para aquellos requerimientos
necesarios para obtener las principales
Alta 3 funcionalidades del sistema esbozadas por los
requerimientos del usuario
Son los requerimientos que le otorgan ciertas

características adicionales al sistema pero que
no interfieren con sus funciones principales,
Media 2 pero aun así contribuyen a obtener un
prototipo en mayor medida seguro, con alta
disponibilidad, mayor rendimiento, y con
facilidad de uso.
Son aquellos que pueden estar o no y que no
interfieren en el sistema, como ser el diseño
Baja 1 de interfaz, normas de calidad adicionales,
pruebas adicionales, etc.

- Pila del sprint (sprint backlog): “lista de los trabajos que debe realizar el equipo durante
el sprint para generar el incremento previsto (una parte completa y operativa del
producto)” (Manager, 2016).
- Incremento: “resultado de cada sprint” (Manager, 2016) (Puede decirse que es una parte
del producto realizada en un sprint, y potencialmente entregable: TERMINADA Y
PROBADA). (Manager, Scrum Manager I , 2015)
- Sprint: es una iteración de desarrollo.” Es el núcleo central que genera el pulso de avance
por tiempos prefijados (time boxing)” (Manager, 2016).
Según Manager (2015) en el siguiente esquema se ve la interacción entre Pila del producto,
pila del sprint, incremento y el sprint:
Ilustración 12 - Interacción Entre Pila del Producto, Pila del Sprint, Incremento y el Sprint
Fuente: Manager (2015)
Los dos primeros forman los requisitos del sistema (Pila del producto y Pila del sprint), y el
tercero (Incremento) es valor que se le entrega al cliente al final de cada sprint. Cada incremento
es una parte del producto completamente terminada y operativa. No se debe considerar como
incrementos: prototipos, módulos o subrutinas pendientes de pruebas o de integración.
 Eventos
- Reunión de planificación del sprint: “es la reunión de trabajo previa al inicio de cada sprint
en la que se determina cual va a ser el objetivo del sprint y las tareas para llegar al objetivo”
(Manager, 2016) (Es decir se seleccionan actividades prioritarias y relacionadas y con la
restricción del tiempo existente, para que estas formen parte de la siguiente iteración).
- Reunión Scrum diario: “es una breve reunión diaria del equipo” (Manager, 2014), en la
que cada miembro responde a tres preguntas:
 El trabajo realizado el día anterior
 El que tiene previsto realizar
 Cosas que puede necesitar o impedimentos que deben eliminarse para poder realizar el
trabajo.
Esta actividad se lleva a cabo todos los días y debe durar quince minutos o menos.
- Retrospectiva del sprint: es la revisión de lo sucedido durante el sprint. Reunión en la que

el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras
para en el próximo sprint. Y se proveen técnicas para reducir los errores, como pruebas de
testing, ayuda de logística. Esto empodera al equipo para que sea exitoso, permitiendo
que mejoren en el siguiente Sprint.

- Reunión de revisión del sprint: se realiza un análisis e inspección del incremento generado
y adaptación de la pila del producto si resulta necesario (es decir al final del sprint se
muestra a los clientes y al Dueño del Producto lo que ha terminado el equipo).
 Historias de Usuario
Las historias de usuario son utilizadas en las metodologías ágiles para la especificación de
requisitos, son una descripción breve de una funcionalidad software tal y como la percibe el
usuario (Mike Cohn, 2004). Describen lo que el cliente o el usuario quiere que se implemente y
se escriben con una o dos frases utilizando el lenguaje común del usuario. Cada historia de
usuario debe ser limitada, esta debería poderse memorizar fácilmente y escribir sobre una
tarjeta o post-it. Poco antes de ser implementadas, estas van acompañadas de conversaciones
con los usuarios y la definición de las pruebas de validación asociadas. Como los cambios son
bienvenidos en agilidad, no vale la pena profundizar antes, ya que en el momento de la
implementación estas pueden haber cambiado desde que fueron escritas. Las pruebas permiten
al equipo, y luego al cliente o usuario, verificar que la historia ha sido completada.
Las historias de usuario se aplican en la mayoría de las metodologías ágiles, siendo así una
herramienta muy importante también en Scrum.
Las Historias de usuario se definen sobre el siguiente modelo:
Número: Usuario: -
Nombre Historia de Usuario: -
Prioridad: -
Estimación: -
Responsable: -
Descripción: -
Los campos que se consideran más necesarios para describir de una manera adecuada las
historias de usuario son:
- Número (ID): identificador de la historia de usuario, único para la funcionalidad o trabajo.

- Descripción: descripción sintetizada de la historia de usuario. El estilo puede ser libre,
según mejor nos funcione, debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se
quiere? y ¿Cuál es el beneficio?
- Prioridad: sistema de priorización que nos permite determinar el orden en el que las
historias de usuario deben de ser implementadas.
- Estimación: estimación del esfuerzo necesario en tiempo ideal de implementación de la
historia de usuario. Según convenga al equipo también se puede utilizar unidades de
desarrollo, conocidas como puntos de historia (estas unidades representan el tiempo
teórico de desarrollo/persona que se estipule al comienzo del proyecto).
- Responsable (Persona asignada): en casos en que queramos sugerir la persona que pueda
implementar la historia de usuario. Recordar que en Scrum es en último término el equipo
autogestionado quién distribuye y por tanto asigna las tareas.
 Priorización de historias de usuario
Aunque todas las historias de usuario puedan ser importantes, para poder focalizarnos en el
trabajo de forma eficiente, es necesario destacar aquellas que den mayor valor al sistema, por
tanto, las historias de usuario deben de estar priorizadas. Estas deben de tener asignadas un

valor que intervenga en el sistema de priorización, un valor asignado por el propietario del
producto.
 Velocidad
Velocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de

tiempo (Manager, 2015).
 Tiempo
El avance a través de incrementos iterativos mantiene el ritmo apoyándose en pulsos de sprints.

Por esta razón emplea normalmente el sprint como unidad de tiempo, y expresa la velocidad
como trabajo o tareas realizadas en un sprint.
 Diferencia entre tiempo “real” y tiempo “ideal”
Tiempo real, es el tiempo de trabajo. Equivale a la jornada laboral.
Tiempo ideal se refiere sin embargo al tiempo de trabajo en condiciones ideales, esto es,
eliminando todo lo que no es estrictamente “trabajo”, suponiendo que no hay ninguna pausa
por interrupción o atención de cuestiones ajenas a la tarea y que la persona se encuentra en
buenas condiciones de concentración y disponibilidad.
 Unidades de trabajo
Según Manager (2015) la gestión ágil se suele emplear “puntos” como unidad de trabajo,
empleando denominaciones como “puntos de historia” o simplemente “puntos”.
1 𝑝𝑢𝑛𝑡𝑜 𝑑𝑒 ℎ𝑖𝑠𝑡𝑜𝑟𝑖𝑎
=
1 𝑗𝑜𝑟𝑛𝑎𝑑𝑎 𝑑𝑒 𝑡𝑟𝑎𝑏𝑎𝑗𝑜 𝑑𝑒 𝑢𝑛 𝑚𝑖𝑒𝑚𝑏𝑟𝑜 𝑑𝑒𝑙 𝑒𝑞𝑢𝑖𝑝𝑜 𝑒𝑛 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖𝑜𝑛 𝑒𝑥𝑐𝑙𝑢𝑠𝑖𝑣𝑎
Puede definir un punto como
 Como tamaño relativo de tareas conocidas que normalmente emplea. Ej: El equipo de
un sistema de venta por internet, podría determinar que un “punto” representara el
tamaño que tiene un “listado de las facturas de un usuario”.
 En base al tiempo ideal necesario para realizar el trabajo. Ej: Un equipo puede
determinar que un “punto” es el trabajo realizado en 4 horas ideales.
 Gráfico de producto
Según Manager (2015) también se suele llamar a este gráfico con su nombre inglés: burn-down.
Lo actualiza el equipo en el scrum diario, para comprobar el ritmo de avance, y detectar desde
el primer momento si es el previsto, o por el contrario se puede ver comprometida o adelantada
la entrega prevista al final de sprint.
La estrategia ágil para el seguimiento del proyecto se basa en:
 Medir el trabajo que falta, no el realizado.

 Seguimiento cercano del avance (diario de ser posible).
Y este gráfico trabaja con ambos principios:

 Registra en el eje Y el trabajo pendiente.

 Se actualiza a diario.
Ilustración 13 - Burn-down
Fuente: Manager (2015)
 Definición de hecho (DOD)
Se describe la Definición de Hecho (DoD) como una herramienta para aportar transparencia al
trabajo que el equipo Scrum está realizando. Se relaciona más con la calidad de un producto, en
lugar de su funcionalidad. El DoD es por lo general una lista clara y concisa de los requisitos que
un incremento de software debe adherir para que el equipo lo considere completo. Cuando esta
lista se satisface se produce recién un incremento (Schwaber, 2009). El equipo de trabajo
durante la planificación del sprint desarrolla o vuelve a confirmar su DoD. Además, un DoD
común ayuda a:
 El progreso de referencia sobre los elementos de trabajo.

 Habilitar transparencia dentro del Equipo Scrum.
 Exponer los elementos de trabajo que necesitan atención.
 Determinar cuándo un incremento está listo para el lanzamiento.
 La Definición de Hecho no se cambia durante un sprint, pero debe cambiar
periódicamente entre sprint para reflejar las mejoras que el equipo de desarrollo ha
hecho en sus procesos y capacidades para entregar software.
 Definición de hecho en el proyecto
Debido a la necesidad de agregar calidad a nuestro proyecto de grado definimos esta breve lista
para el cierre de cada sprint. Cada historia de usuario hecha debe cumplir lo siguiente:
1. Diseño de pantallas para la versión de prueba correspondiente.

2. Pruebas de integración probadas y superadas.
3. Prueba de aceptación.
4. Realización de prueba de aceptación.
 Estimación
 Estimación de Planning Poker
Según Scrum Manager (s.f.) es una práctica ágil, para conducir las reuniones en las que se estima
el esfuerzo y la duración de tareas. James Grenning ideó este juego de planificación para evitar
discusiones dilatadas que no terminan de dar conclusiones concretas. El modelo inicial de
Grenning consta de 8 cartas, con los números representados en siguiente figura.

Ilustración 14 - Número utilizado en Planning Poker

Fuente: Scrum Manager (s.f.)
El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la

estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo
estimado.
Cuando se considera que éste es mayor de x horas ideales (el tamaño máximo considerado por
el equipo para una historia), se levanta la carta “”. Las tareas que exceden el tamaño máximo
deben descomponerse en subtareas de menor tamaño. Cada equipo u organización puede
utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que
trabajan, y el tamaño máximo de tarea o historia que se va a estimar.
5.13 - Gateway SMS

Una pasarela SMS o puerta de enlace por SMS (del inglés SMS Gateway) es un medio de envío o
recibo de mensajes de texto (SMS) usando una red de telecomunicaciones. Esta puerta de enlace
es usada por entidades y organizaciones para enviar notificaciones masivas a teléfonos móviles
que no están conectados a Internet a través de un software. De otro modo, los servicios web
envían los mensajes de confirmación para autenticación en dos pasos en los servidores antes de
enviarlos.
Muchos operadores móviles se prestan como intermediarios fijos para enviar SMS. Estos están
basados en estándares acordes al European Telecommunications Standards Institute y el
sistema global para las comunicaciones móviles (GSM) para conceder el envío de mensajes en
cualquier dispositivo fijo y móvil. Estos utilizan la modulación por desplazamiento de frecuencia
para transferir el mensaje entre el terminal y el Central de Servicio de Mensajes Cortos (SMSC:
es un elemento de la red de telefonía móvil cuya función es de enviar/recibir mensajes de texto).
Dichos terminales utilizan su identificación por número telefónico basados en Digital Enhanced
Cordless Telecommunications.
También existe la posibilidad de enviar mensajes a partir de clientes de correo electrónico como
Microsoft Outlook o de forma manual. No obstante, los servicios pueden ser usados con fines
de phishing usando enlaces web.
6 - Metodología
Para el presente trabajo se seleccionó Scrum (el cual fue descripto en detalle 5.11 del Marco
Teórico). Por los siguientes aspectos que proporciona:
1. Desarrollo incremental, ya que con cada iteración se obtendrá un entregable funcional
para presentarle al usuario.

2. Ágil: La división del trabajo en pequeñas unidades funcionales (permite mantener una
política de entregas frecuentes de software que ofrecen una visión clara del estado del
proceso y permite la introducción de modificaciones.
3. Simple: facilita un desarrollo rápido, por lo que su complejidad (por ejemplo, desde el
punto de vista de la documentación a generar o de la organización de equipos) se reduce
al máximo.
4. Flexible: ya que permite introducir modificaciones para adaptar el prototipo conforme se
va descubriendo cosas que no se habían entendido bien o que no estaban bien definidas.
6.1 - SPRINT 0:
El sprint 0 es un sprint especial diferente a los demás donde se considera necesario definir en
el:
6.1.1 - Definición de los roles:

- Scrum master: Ing. Benitez, identificado como el tutor, quien realiza revisiones periódicas
con el fin de verificar los avances y contribuir como facilitador para evitar bloqueos o
inconvenientes en el equipo de trabajo.
- Equipo de Desarrollo (Team): Martin Chañi Alarcón
- Propietario del producto (Product Owner): Ing. Benitez.
6.1.2 - Tipo de Usuario:

Se pensó en dos tipos de usuario para el prototipo los cuales son:
 Administrador: el cual tendrá control total del prototipo.

 Invitado: solo podrá activar el prototipo para la detección de movimiento y detener la
grabación en curso.
6.1.3 - Definición de la pila del producto:

Es una lista de requisitos del usuario que se origina con la visión inicial del producto y va
creciendo y evolucionando durante su desarrollo, está formada por la historia de usuario, las
cuales representan las funciones que debe realizar el prototipo.
6.1.4 - Historias de usuario:

ID Descripción Responsable
HU1 Logueo MC
HU2 Gestión usuarios MC
HU3 Grabación de video MC
HU4 Detección de movimiento MC
HU5 Envió de Alertas MC
Reproducción de
HU6 MC
grabaciones
Definición dirección
HU7 MC
almacenamiento
Modificar número de envió
HU8 MC
de alerta

6.1.5 – Diagrama de Clase del Prototipo

class Clase
Ruta Usuarios
Prototipo - Id_Nivel: int
- Direccion: Char
- Id_Ruta: Integer - UserName: char
- TipoNivel: int
- UserPass: char
1 1
+ BuscarRuta() : Integer + BuscarNivelUsuario() : void 1 1
+ InsertarRuta() : void + AgregarUsuarios() : void
+ ControlarAcceso() : void
+ ModificarRuta() : void + BuscarUsuarios() : void
+ HabilitarOpciones() : void
+ EliminarUsuarios() : void
1 1 + ModificarUsuarios() : void
1 1
*
1 1 1
1
Reproduccion Alarma
Niv el
+ BuscarRuta() : void - Id: int
+ CargarGrabaciones() : void - Telefono: int - Id_Nivel: int
- Tipo: int
+ SeleccionarGrabacion() : void
+ InsertarNumero() : void
1 + MostrarNiveles() : void
+ ModificarNumero() : void
Deteccion Mov imiento
- Deteccion: char
Grabacion
+ DetenerDeteccion() : void 1 1
+ AlmacenarGrabacion() : void
+ EnviarSeñal() : void
+ DetenerGrabacion() : void
+ IniciarDeteccion() : void
+ EnviarAlarma() : void
+ GrabacionAutomatica() : void
6.1.6 - Estimación de las Historias de Usuario para su medida.

Se utilizará como unidad de medida para las Historias de Usuario, los Puntos de Historia.
Definimos un Punto de Historia como:
1 𝑝𝑢𝑛𝑡𝑜 𝑑𝑒 ℎ𝑖𝑠𝑡𝑜𝑟𝑖𝑎
=
1 𝑗𝑜𝑟𝑛𝑎𝑑𝑎 𝑑𝑒 𝑡𝑟𝑎𝑏𝑎𝑗𝑜 𝑑𝑒 𝑢𝑛 𝑚𝑖𝑒𝑚𝑏𝑟𝑜 𝑑𝑒𝑙 𝑒𝑞𝑢𝑖𝑝𝑜 𝑒𝑛 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖𝑜𝑛 𝑒𝑥𝑐𝑙𝑢𝑠𝑖𝑣𝑎
PUNTOS DE
DIA HORAS
HISTORIA
1 8 1
Nota: esta estimación se basa en la premisa de que no hay interrupciones y no contempla la

paralización o colaboración en el trabajo. Para solucionar este inconveniente, más adelante se
realizará el Cálculo de la Velocidad estimada.
6.1.7 - Descripción de Historias de Usuario:
Número: 1 Usuario: Administrador/Usuarios

Nombre Historia de Usuario: Logueo
Prioridad: 2
Estimación: 4
Responsable: MC
Descripción: permitir ingresar al prototipo utilizando un usuario y contraseña. Alertando en
el caso que se ingresen datos erróneos al tratar de ingresar al mismo.

Número: 2 Usuario: Administrador

Nombre Historia de Usuario: Gestión usuario
Prioridad: 2
Estimación: 3
Responsable: MC
Descripción: permitir a los administradores agregar nuevos usuarios para iniciar sesión en el
prototipo, asignando permisos (administrador o invitado), los administradores tendrán
control total, mientras que los usuarios invitados estarán limitados en las opciones.
Número: 3 Usuario: Administrador/ Usuarios

Nombre Historia de Usuario: Grabación de video
Prioridad: 3
Estimación: 2
Responsable: MC
Descripción: permitir la grabación de video después del envió de la alerta de intrusos,
producto de la detección movimiento a través de la cámara web.
Número: 4 Usuario: Administrador/Invitado

Nombre Historia de Usuario: Detección de movimiento
Prioridad: 3
Estimación: 5
Responsable: MC
Descripción: permitir detectar el movimiento a través de la cámara web, para luego enviar la
alerta de intrusos e iniciar la grabación de video.

Nombre Historia de Usuario: Envío de alertas
Prioridad: 3
Estimación: 3
Responsable: MC
Descripción: permitir enviar una alerta en forma de SMS al detectar movimiento por la
cámara web.

Nombre Historia de Usuario: Reproducción de grabaciones
Prioridad: 1
Estimación: 5
Responsable: MC
Descripción: permitir visualizar las grabaciones almacenadas producto de la detección de
movimiento por la cámara web.


Nombre Historia de Usuario: Definición dirección almacenamiento
Prioridad: 1
Estimación: 3
Responsable: MC
Descripción: permitir elegir el lugar donde se desee guardar las grabaciones cuando se
detecte movimiento por la cámara web. La elección del lugar de almacenamiento se le pedirá
cuando se use el prototipo por primera vez, pero también se podrá modificar dicho lugar
cuando se desee.

Nombre Historia de Usuario: Modificar número de envío de alerta
Prioridad: 1
Estimación: 2
Responsable: MC
Descripción: permitir modificar el número ingresado para el envío de la alerta en forma de
SMS.
6.1.8 - Priorización de las Historias de usuario

La prioridad de la pila del producto está dada por las funcionalidades más urgentes que debe
contener la versión requerida por el propietario del producto.
La priorización de las historias de usuario se realizará de la siguiente manera:
ID Descripción
Está definida para aquellos
requerimientos necesarios para
Alta 3 obtener las principales funcionalidades
del sistema esbozadas por los
requerimientos del usuario.
Son los requerimientos que le otorgan
ciertas características adicionales al
sistema pero que no interfieren con
sus funciones principales, pero aun así
Media 2
contribuyen a obtener un prototipo en
mayor medida seguro, con alta
disponibilidad, mayor rendimiento, y
con facilidad de uso.
Son aquellos que pueden estar o no y
que no interfieren en el sistema, como
Baja 1 ser el diseño de interfaz, normas de
calidad adicionales, pruebas
adicionales, etc.
A partir del cuadro anterior las historias de usuario quedan ordenadas por prioridad de la
siguiente manera:

Prioridad ID Descripción Responsable

3 HU4 Detección de movimiento MC
3 HU5 Envío de Alertas MC
3 HU3 Grabación de video MC
2 HU1 Logueo MC
2 HU2 Gestión usuarios MC
1 HU7 Definición dirección almacenamiento MC
1 HU6 Reproducción de grabaciones MC
1 HU8 Modificar número de envío de alerta MC
6.1.9 - Reuniones de revisión

Se estableció reunirse una vez por semana para llevar un control del avance del desarrollo del
prototipo, en cual se tratará de resolver todas las dificultades que puedan surgir.
6.1.10 - Herramientas
Para el desarrollo y el funcionamiento del prototipo se utilizarán las siguientes herramientas:
 Lenguaje de programación: Visual Basic .Net
 Base de datos: Access 2010 o AccessDatabaseEngine en el caso de no contar con access
2010 instalado.
 Framework 3.5.
 Plataforma: Windows (como mínimo Windows XP).
 Requisitos de Hardware:
o PC Pentium 4 o Superior, 512 mínimo de RAM.
o Cámara web.
6.1.11- Velocidad estimada de un Sprint

Para calcular la velocidad estimada se utilizará el factor de dedicación, ya que no se tiene ningún
Sprint anterior para poder tomar como referencia su velocidad (Técnica llamada tiempo que
hizo ayer).
𝐷𝑖𝑎𝑠 − 𝐻𝑜𝑚𝑏𝑟𝑒 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝐷𝑒𝑑𝑖𝑐𝑎𝑐𝑖𝑜𝑛 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑎

 Se considera que el factor de dedicación será del 70%, es decir que se dedicará un 70% de
la jornada laboral exclusivamente a tareas del prototipo (5 horas y media
aproximadamente) y el 30% restante a tareas no planificadas (2 horas y media
aproximadamente).
 Cada sprint tendrá una duración de 14 días, siendo el jornal de trabajo de 8 horas cada día.
14 ∗ 0.7 = 9.8 ≈ 10 => 𝑃𝑢𝑛𝑡𝑜𝑠 𝑝𝑜𝑟 𝑠𝑝𝑟𝑖𝑛𝑡

La velocidad estimada es de 10 puntos aproximadamente, esto significa que se tomarán historias
de usuario que sumen aproximadamente 10 puntos.
6.1.12 - Estimación del tiempo para la construcción del producto.

Las convenciones utilizadas en el proyecto son:
 Unidad para estimar el trabajo: puntos de historia.

 Está previsto trabajar con Sprint de duración fija, los cuales serán de 14 días laborables.

 El equipo está formado por 1 persona y desarrollará a una velocidad media de 10

puntos por sprint.
 Se considerará un avance pesimista, un estimado y un optimista. Para el caso pesimista
la velocidad del equipo será de 7 puntos por sprint, para la velocidad estimada será de
10 puntos por sprint y para la optimista será de 13 puntos por sprint.
 Para el desarrollo del trabajo se presupone que se dedicará 8 horas días de trabajo
para la realización del prototipo.
Gráfico del producto
Velocidad de Trabajo
15 13
pesimista Estimada Optimo
10
Puntos Estimados
10
7
0
1 2 3 4 5 6 7 Dias 8 9 10 11 12 13 14
En el gráfico podemos ver los puntos de historias que se realizarán para las estimaciones:
pesimista, estimada y optimista.
A continuación, se definirá las historias de usuario que abarcará cada versión:
Versiones ID Prioridad Descripción Estimación

HU4 3 Detección de movimiento 5
1 HU5 3 Envió de Alerta 3
HU3 3 Grabación de video 2
HU1 2 Logueo 4
2
HU2 2 Gestión usuarios 3
HU7 1 Definición dirección almacenamiento 3
3 HU6 1 Reproducción de grabaciones 5
HU8 1 Modificar número de envió de alerta 2
Total Puntos estimados 27
Al estimar la cantidad de iteraciones para completar todas las versiones, para las velocidades: la
pesimista, estimada y la optimista, como mínimo para completar todas versiones se necesitarán
3 iteraciones.
Cantidad de Puntos por Velocidad

Pesimista Estimada Optimista
7 10 13
14 20 26
21 30 39
28 40 52

Estimación de la cantidad de días para cada versión:
Cantidad de Días
Versiones Total Estimación Pesimista Estimada Optimista
1 10 20 14 11
2 7 12 6 5
3 10 20 14 13
Total Días 52 34 29
En el siguiente cuadro se presentan las fechas estimadas de entrega del producto para cada
versión. Con las cuales se podrá comparar más adelante las fechas de finalización reales de cada
versión. El cuadro contiene fechas de finalización de las velocidades pesimista, estimada y
optimista. Se iniciará el prototipo el día 05 de marzo de 2018.
Fecha
Inicio 05/03/2018
Versión Fecha entrega
Pesimista Estimada Optimista
1 02/04/2018 20/03/2018 19/03/2018
2 18/04/2018 28/03/2018 26/03/2018
3 17/05/2018 11/04/2018 08/04/2018
Esta grilla permite tener una estimación de las fechas de los entregables, por lo tanto, más
adelante se comparará estas fechas con las fechas de entrega reales.
6.2 - Planificación del Sprint 1:

De acuerdo a la velocidad estimada y calculada anteriormente que es de 10 puntos
aproximadamente, el Sprint 1 podrá abordar como máximo historias de usuario que sumen 10
puntos aproximadamente.
En este Sprint se abordarán las historias de usuario HU3, HU4 y HU5, ya que son las de mayor
prioridad. En estas tres historias de usuario si bien tienen la misma prioridad, se abordará
primero a HU4 ya que las restantes tienen dependencia de esta. Luego HU5 y por último HU3.
ID Descripción Responsable Estimación

HU4 Detección de movimiento MC 5
HU5 Envío de Alertas MC 3
HU3 Grabación de video MC 2
6.2.1 - Pila del Sprint.

En el siguiente gráfico se observa el conjunto de tareas correspondiente a cada una las historias
de usuario que se llevará a cabo en este Sprint. A este conjunto de tareas se lo conoce como Pila
del Sprint.

6.2.2 - Burn Down del Sprint 1
En este gráfico se puede apreciar que al principio del Sprint las tareas se fueron desarrollando
de manera normal ya que las tareas de las historias de usuario de HU5 y HU4 se completaron en
su totalidad, mientras las tareas de HU3 no se llevaron a cabo ninguno de ellas.
Se puede ver que algunas tareas consumieron más tiempo de lo esperado, como se puede
apreciar en el gráfico.
6.2.3-Retrospectiva Sprint 1:
La principal dificultad que se presentó en este sprint 1, fue a la hora de utilizar una nueva librería
e integrarla para trabajar en conjunto con el lenguaje de programación. A la hora de la
codificación para la detección de movimiento se presentaron ciertos inconvenientes, ya que la
librería detectaba movimiento a través de la cámara web cuando no había movimiento, sin
embargo, este problema se logró solucionar.
6.2.4-Revisión del Sprint 1:

Al revisar el Sprint 1 las tareas de las historias de usuario HU5 y H4 se completaron en su
totalidad, mientras que las tareas de la HU3 no se llevaron a cabo ninguna, debido a que las
tareas de las HU5 y HU4 se desarrollaron en más tiempo del estimado.

Historias de Usuarios completadas:
HU4: Detección de movimiento
Imagen a Imagen b
En la Imagen a podemos observar que no existe movimiento (imagen estática). Al detectar
movimiento en la Imagen a, se presentan líneas en color rojo indicando la detección de
movimiento (Imagen b).
Prueba de Aceptación
ID: 1 HU4: Detección de movimiento
Estado: Aceptada
Descripción: mediante la siguiente interfaz se trata de indicar si se detectó movimiento por
la cámara web en un ángulo que monitorea, cuando el usuario activa el sistema.
Resultados esperados:
 Cuando no se detecte ningún movimiento hacia donde apunta la cámara solo se
visualizará la imagen estática.
 Cuando se detecte movimiento en la imagen se presentarán unas líneas color rojo
indicando que se detectó movimiento.
 Al detectar movimiento se enviará una notificación de SMS.
HU5: Envío de Alertas

ID: 2 HU5: Envío de Alertas
Estado: Aceptada
Descripción: al recibir la señal de la detección de movimiento se enviará una alerta en forma
de SMS.
 Enviar SMS alertando la detección de movimiento.
Liberación del entregable del Sprint 1:
Sprint 1:
Requerimientos SI NO
¿Todas las historias de usuario seleccionadas fueron desarrolladas? X
¿Todas las pruebas de aceptación fueron aprobadas? X
Observaciones: No todas HU se pudieron llevar a cabo debido a que se
presentaron dificultades a la hora de llevar a cabo las HU4 y HU5. La HU que
no se pudo realizar se desarrollará en el siguiente Sprint.
 Los resultados revisados satisfacen los requerimientos y son aceptados por el
propietario.
6.3 - Cálculo del nuevo valor del Factor de dedicación a partir del sprint anterior.
Al haberse completado únicamente las primeras dos historias de usuario la velocidad real del
sprint 1 es de 8 puntos, por lo cual se calculará el nuevo factor de dedicación:
𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖ó𝑛 = (𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝑅𝑒𝑎𝑙)/ (𝐷𝑖𝑎𝑠 − 𝐻𝑜𝑚𝑏𝑟𝑒 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒)

𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖ó𝑛 = 8/14
𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖ó𝑛 = 0.57
Según este valor de las 8 horas laborales, se dedicarán aproximadamente 5 horas a tareas
específicas del prototipo, mientras que 3 horas se dedicará a tareas no programadas.
6.4 - Cálculo de la nueva velocidad estimada.

Al tomar la velocidad real el nuevo valor del factor de dedicación es de 0.57, se calculará la
velocidad estimada para el siguiente sprint:
𝐷𝑖𝑎𝑠 − 𝐻𝑜𝑚𝑏𝑟𝑒 𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝑑𝑒 𝐷𝑒𝑑𝑖𝑐𝑎𝑐𝑖𝑜𝑛 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑎

14 ∗ 0.57 = 7.98 ≈ 8 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑎
La velocidad estimada es de 8 puntos aproximadamente, esto significa que se tomarán historias
de usuario que sumen alrededor de 8 puntos.
6.5 - Sprint 2
Debido a que no se pudieron cumplir todas las Historias de Usuarios a ser realizadas en el Sprint
1, en este Sprint 2 se tomarán todas las Historias de Usuarios que quedaron pendiente del Sprint
anterior.
En este nuevo Sprint se tomará el nuevo valor de la Velocidad Estimada el cuál es de 8 puntos
aproximadamente, esto quiere decir que se tomarán Historias de Usuario que sumen alrededor
de los 8 puntos.

Historias de Usuario que se abordarán:

HU3 Grabación de video MC 2
HU1 Logueo MC 4
6.5.1 - Pila del Sprint 2:

En el siguiente gráfico se observa el conjunto de tareas correspondiente a cada una las Historias
de Usuario que se llevara a cabo en el Sprint 2:
Podemos observar que gracias a la experiencia adquirida en el sprint anterior, todas las tareas
de las Historias de Usuario se fueron desarrollando de manera constante.
6.5.3 - Retrospectiva Sprint 2:

A la hora de llevar a cabo las tareas se detectaron ciertas dificultades.
Una de las dificultades fue al trabajar con la base de datos Access junto al lenguaje de
programación para realizar transacciones.
Otro inconveniente que se presentó fue al trabajar con la librería al momento de almacenar las
grabaciones de video automáticamente, ya que si bien se trabajó anteriormente con esta librería

se desconocía el funcionamiento de las clases o métodos que proporciona la librería para la

grabación.
Además surgieron otras dificultades en este sprint y pudieron ser resueltas gracias a la
experiencia adquirida.
6.5.4 - Revisión del Sprint 2:

Como podemos apreciar todas las Historias de Usuario abordadas en este Sprint 2 pudieron ser
terminadas. Esto se debe a los conocimientos que se obtuvo previamente. Si bien se presentaron
dificultades en el mismo a la hora de llevar a cabo las tareas, estas dificultades fueron en menor
medida.

HU3: Grabación de video
ID: 1 HU3: Grabación de video
Estado: Aceptada
Descripción: grabación automática de video después del envío de la alerta del SMS.
 Comenzar a grabar automáticamente después del envío del SMS.
 Se activará un botón “Detener Sistema” para detener el sistema cuando se desee.
 Se activará el botón “Detener Grabación” en color rojo para indicar que está en curso la
grabación.

HU1: Logueo
ID: 2 HU1: Logueo
Estado: Aceptada
Descripción: a través de esta interfaz se permitirá o negará iniciar sesión en el prototipo:
 Ingresando usuario y contraseña válidos
 Ingresando usuario y/o contraseña inválidos.
 Si se ingresó correctamente un usuario y su contraseña se permitirá el acceso.
 Si se ingresó un usuario y/o contraseña inválidos se negará el ingreso al prototipo
mostrando un mensaje que se ingresaron datos erróneos.
 Si no se ingresa un usuario ni contraseña se debe mostrar unos iconos indicando que se
necesitan dichos datos para iniciar sesión.
Sprint 2:
Observaciones: se completaron exitosamente todas las HU abordadas en este Sprint.
 Los resultados revisados satisfacen los requerimientos y son aceptados por el
propietario.
6.6 - Sprint 3
Ya que en el sprint 2 se completaron todas las Historias de Usuarios abordadas en él, la velocidad
para el Sprint 3 también será de aproximadamente 8 puntos. Se abordará las Historias de
Usuarios HU2 y HU7:
Historias de Usuario que se abordaran:


HU2 Gestión usuarios MC 3
HU7 Definición dirección almacenamiento MC 3
Podemos observar en el gráfico que todas las tareas se llevaron a cabo de manera constante
gracias a lo aprendido en los Sprint anteriores.

En este Sprint se presentaron dificultades a la hora de trabajar con la base de datos Access al
tratar de realizar nuevas transacciones, sin embargo, dichas dificultades fueron menores gracias
al conocimiento adquirido en los Sprint anteriores.

Como podemos apreciar todas las Historias de Usuarios abordadas en este Sprint 3 también
pudieron ser terminadas exitosamente en el mismo.

HU2: Gestión usuarios
Imagen c
Imagen d
Imagen e

Imagen f
ID: 1 HU2: Gestión usuarios
Estado: Aceptada
Descripción: a través de esta interfaz se podrá:
 Ingresar nuevos usuarios para usar el prototipo.
 Se podrá modificar datos de los usuarios registrados.
 Se podrá eliminar usuarios registrados en el prototipo.
 Al tratar de dar de alta un usuario nuevo se debe verificar si el nombre de usuario que
se esté tratando de ingresar no esté registrado. Si el nombre de usuario está registrado
se mostrará un mensaje de usuario registrado. Si el usuario se almacena correctamente
mostrará un mensaje de confirmación (Imagen d).
 Se podrá modificar el nivel y/o la clave de los usuarios registrados (Imagen e).
 Al tratar de eliminar un usuario se debe pedir confirmación para la eliminación del
usuario seleccionado (Imagen f).
HU7: Definición dirección almacenamiento
Imagen g
Imagen h

ID: 2 HU7: Definición dirección almacenamiento
Estado: Aceptada
 Visualizar el lugar donde se almacenan las grabaciones.
 Permitir visualizar el directorio donde se almacenan las grabaciones al detectar el
movimiento por la cámara web (Imagen g).
 Permitir cambiar el lugar del almacenamiento de las grabaciones, mostrando un
mensaje confirmando la modificación del lugar para guardar las grabaciones (Imagen
h).
Sprint 3:
Observaciones: se completaron exitosamente todas las HU abordadas en este Sprint.
 Los resultados finales satisfacen los requerimientos y son aceptados por el propietario.
6.7 - Sprint 4
Ya que en el sprint 3 se completaron todas las Historias de Usuarios abordadas en él, se
trabajarán las restantes Historias de Usuarios HU6 y HU8:

HU6 Reproducción de grabaciones MC 5
HU8 Modificar número de envío de alerta MC 2

Como podemos ver el ritmo de avance al comienzo del sprint fue constante, luego se
presentaron ciertas irregularidades, debido a algunos inconvenientes. De igual manera se logró
completar todas las tareas.

En este sprint surgieron dificultades, debido a que se desconocía la utilización de herramientas
para la reproducción multimedia de videos. Sin embargo, las dificultades pudieron ser superadas
por el conocimiento de los Sprint anteriores.

Como podemos apreciar todas las Historias de Usuarios abordadas en este Sprint 4 se
completaron exitosamente.

HU6: Reproducción de grabaciones
Imagen i

ID: 1 HU6: Reproducción de grabaciones
Estado: Aceptada
 Visualizar y seleccionar la grabación deseada. La cual es producida por la detección de
movimiento si es que la hubiera.
 Permitir seleccionar la grabación que se desee visualizar y poder pausarla o detenerla
(Imagen i).
HU8: Modificar número de envío de alerta
Imagen j
Imagen k
ID: 2 HU8: Modificar número de envió de alerta
Estado: Aceptada
 Visualizar el número ingresado para él envío de la alerta en forma de SMS.
 Permitir modificar el número registrado para el envío de alerta en forma de SMS
(Imagen j).
 Mostrar mensaje con el formato para ingresar el número de teléfono (Imagen k).
Sprint 4:
¿Todas las Historias de Usuario seleccionadas fueron desarrolladas? X
6.7 - Conclusión:
Como podemos apreciar que todas las Historias de Usuario definidas para el prototipo se
completaron exitosamente. Para el desarrollo del mismo se necesitó de 4 Sprint de 14 días de
duración cada uno.

Se completaron todas las Historias de Usuario con un factor de dedicación del 57% y se llevaron
a cabo todos los Sprints a una velocidad de 8 puntos aproximadamente.
Se estimaron fechas de finalización del mismo las cuales eran pesimista, estimada y optimista.
Al comparar la fecha real de finalización del prototipo con las fechas de finalización que se
estimaron, se puede decir que la fecha de finalización real se aproxima a la fecha pesimista. La
fecha de finalización pesimista fue para el día 17/05/2018 y la fecha de finalización real fue del
24/05/2018, por lo que se pasó en 8 días la finalización real respecto de la pesimista.
7 - Pruebas
Este capítulo de pruebas tiene por objetivo, ejecutar el prototipo para la aplicación de técnicas
y herramientas para el testing del prototipo presentado en el proyecto y con el fin de encontrar
errores en el mismo. Se probarán las interfaces, ingresando datos al prototipo a través de las
mismas y verificando los resultados obtenidos con los datos de entrada.
7.1 - Prueba de validación

A través de estas pruebas se buscará comprobar el correcto funcionamiento de la Historia de
Usuario Login, para cumplir con las necesidades del cliente.
Las pruebas de validación en la Ingeniería de Software es el proceso de revisión que la HU Login

cumpla con las especificaciones y su cometido. La validación es el proceso de comprobar que lo
que se ha especificado es lo que el usuario realmente quería.
Dichas pruebas se llevarán a cabo en la historia de usuario “Login”.
Para la realización de la prueba se estableció los siguientes casos de prueba:
ID Prueba: 1
HU: Login
Descripción: permitir el acceso al prototipo al ingresar usuario y contraseña validos
Datos Requeridos:
 Ingreso de Usuario válido.
 Ingreso Contraseña válida.
Pre Condiciones: Usuario debe estar registrado en la base de datos del prototipo.
Resultados esperados: Permitir el acceso al prototipo.

Post Condiciones: Permite el ingreso al sistema (Imagen 1).

Estado: Terminado - ok
Imagen 1
ID Prueba: 2
HU: Login
Descripción: No permitir el acceso al prototipo al ingresar un usuario valido pero la contraseña
invalida.
Datos Requeridos:
 Ingreso de Usuario válido.
 Ingreso de contraseña inválida.
Pre Condiciones: Usuario registrado en la base de datos del prototipo.
Resultados esperados: No permitir el acceso al prototipo.
Post Condiciones:
 Negar el ingreso al sistema.
 Mostrar un mensaje informando que ingresó mal el usuario y/o contraseña (Imagen 1).
Estado: Terminado – ok
ID Prueba: 3
HU: Login
Descripción: No permitir el acceso al prototipo al ingresar un usuario inválido, pero la contraseña
válida.
Datos Requeridos:
 Ingreso de Usuario inválido.
 Ingreso de contraseña válida.
Pre Condiciones: Usuario debe estar registrado en la base de datos del prototipo.
Post Condiciones:
 Mostrar un mensaje informando que se ingresó mal el usuario y/o contraseña (Imagen 2)

Imagen 2
ID Prueba: 4
HU: Login
Descripción: no permitir el acceso al prototipo al no ingresar ningún usuario ni contraseña.
Datos Requeridos:
 Ingresar usuario vacío.
 Ingresar contraseña vacía.
Pre Condiciones: se ingresa el usuario y la clave en blanco.
Post Condiciones:
 Mostrar iconos que indiquen que se debe ingresar usuario y contraseña para poder
ingresar al prototipo (Imagen 3).
Imagen 3

Gestión usuario
ID Prueba: 1
HU: Gestión usuario
Descripción: permitir agregar un nuevo usuario para que pueda usar el prototipo.
Datos Requeridos:
 Ingreso de nombre de usuario nuevo.
 Ingreso contraseña para el usuario.
 Selección del nivel.
Pre Condiciones: El nombre de usuario no debe estar registrado en el prototipo.
Resultados esperados: guardar el nuevo usuario.
Post Condiciones: mostrar un mensaje con la confirmación del nuevo usuario fue guardado
correctamente (Imagen 1).
Imagen 1

ID Prueba: 2
Descripción: no permitir ingresar un nombre de usuario ya registrado.
Datos Requeridos:
Pre Condiciones: nombre de usuario ya registrado en el prototipo.
Resultados esperados: no guardar el usuario.
Post Condiciones: mostrar un mensaje informando que el nombre de usuario ya se encuentra
registrado (Imagen 2).
Imagen 2
ID Prueba: 3
Descripción: controlar que el correcto ingreso de la clave
Datos Requeridos:
Pre Condiciones: nombre de usuario no registrado en el prototipo.
Resultados esperados: no almacenar el nuevo usuario.
Post Condiciones: mostrar un mensaje informando que las claves ingresadas no coinciden
(Imagen 3).

Imagen 3
ID Prueba: 4
Descripción: permitir modificar la clave y/o nivel de usuario registrados en el prototipo.
Datos Requeridos:
 Ingreso nueva contraseña para el usuario.
Pre Condiciones: usuario registrado en el prototipo.
Resultados esperados: almacenar la nueva clave y/o nivel.
Post Condiciones: mostrar un mensaje confirmando el almacenamiento de la modificación de los
datos (Imagen 4).
Imagen 4
ID Prueba: 5
Descripción: permitir eliminar un usuario registrado en el prototipo.
Datos Requeridos:
 Selección de un usuario.
Pre Condiciones: usuario registrado en el prototipo.

Resultados esperados: eliminación de un usuario.

Post Condiciones:
 mostrar un mensaje pidiendo la confirmación para la eliminación del usuario (Imagen 5).
 Mostrar mensaje confirmando la eliminación (Imagen 6).
Imagen 5
Imagen 6
Definición dirección almacenamiento
ID Prueba: 1
HU: Definición dirección almacenamiento
Descripción: permitir cambiar el lugar para almacenar las grabaciones.
Datos Requeridos:
 Ruta almacenada en el prototipo.
Pre Condiciones: selección del lugar deseado (Imagen 7).
Resultados esperados: almacenamiento del cambio de la ruta.
Post Condiciones: mostrar un cartel confirmando la modificación de la ruta (Imagen 8).

Imagen 7
Imagen 8
Reproducción de grabaciones
ID Prueba: 1
HU: Reproducción de grabaciones.
Descripción: permitir visualizar las grabaciones.
Datos Requeridos:
 Ruta registrada.
 Grabaciones existentes
Pre Condiciones: seleccionar la grabación deseada a visualizar (Imagen 10).
Resultados esperados: visualización de la grabación.
Post Condiciones: -

Imagen 10
Detección de movimiento
ID Prueba: 1
HU: Detección de movimiento
Descripción: detectar movimiento al iniciar el prototipo.
Datos Requeridos:
 Cámara web.
Pre Condiciones: -.
Resultados esperados: detección de movimiento (Imagen 11).
Post Condiciones: envió señal para el envió de la alerta.
Imagen 11

Envió de Alerta
ID Prueba: 1
HU: Envió de Alerta
Descripción: envió de alerta sobre la detección de intrusos.
Datos Requeridos:
 Detección de movimiento por la cámara web.
Pre Condiciones: detección de movimiento.
Resultados esperados: envió de alerta (Imagen 12).
Post Condiciones: comenzar la grabación automática de video.
Imagen 12
Grabación de video
ID Prueba: 1
HU: Grabación de video
Descripción: grabación automática de video después de detectar movimiento.
Datos Requeridos:
 Recepción de la señal para iniciar la grabación.
Pre Condiciones: envió alerta.
Resultados esperados: grabación de video (Imagen 13).
Post Condiciones: -

Imagen 13
Modificar número de envió de alerta
ID Prueba: 1
HU: Modificar número de envió de alerta.
Descripción: permite modifica el número almacenado para el envió de la alerta.
Datos Requeridos:
 Ingreso nuevo número para el envió de la alerta.
Pre Condiciones:
 número de la alerta registrado.
 Indicar el formato para ingresar el nuevo número (Imagen 14).
Resultados esperados: almacenamiento del nuevo número de celular.
Post Condiciones: mostrar un cartel informando el almacenamiento del cambio de número
(Imagen 15).
Imagen 14

Imagen 15
ID Prueba: 1
HU: Modificar número de envió de alerta.
Descripción: no permitir el ingreso de caracteres al ingresar el nuevo número para alerta.
Datos Requeridos:
 Ingreso nuevo número de celular.
Pre Condiciones:
 número celular de la alerta registrado.
 Indicar el formato para ingresar el nuevo número (Imagen 14).
Resultados esperados: permitir solo ingreso de número.
Post Condiciones: mostrar alerta que se ingresó un valor distinto a un número (Imagen 16).
Imagen 16

7.2 – Prueba unitaria

La prueba de unidad enfoca los esfuerzos de verificación en el componente o módulo de
software. Se evalúan las rutas de control importantes, se prueban para descubrir errores dentro
del módulo. Las pruebas de unidad se enfocan en la lógica de procesamiento interno y de las
estructuras de datos dentro de las fronteras de un componente.
Una prueba unitaria, o “unit test”, es un método que prueba una unidad estructural de código.
Para este caso de prueba unitaria, se realiza la prueba sobre el Método: InsertNuevoUsuario de
la Historia de Usuario Gestión de Usuarios.
Para la realización de la prueba se utilizará las herramientas de prueba unitaria que proporciona
el visual studio, llamadas Unit Test Project
Se definirá el siguiente caso de prueba para:
ID Prueba: 1
HU: Gestión Usuario
Descripción: insertar un nuevo usuario para que pueda acceder al prototipo.
Datos Requeridos:
 Ingresar un nombre de usuario no registrado en el sistema.
 Ingresar la clave para el usuario.
 Seleccionar nivel.
Pre Condiciones: usuario no debe estar registrado en el sistema.
Resultados esperados: guardar el nuevo usuario.
Post Condiciones:
 Informar si la operación tuvo éxito.
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod de prueba.

El cual se aplicará al método InsertNuevoUsuario
Donde para la realización de la prueba, utilizamos DatosPrueba que es una instancia de la clase
usuarios, a la cual se le asigna los siguientes valores para iniciar la prueba:
DatosPrueba.NUsser1= ”PRUEBA”
DatosPrueba.NPass1= ”PRUEBA”
DatosPrueba.NNivel1= 1
Al ejecutar la prueba el usuario se insertó correctamente ya que no existe otro usuario con el
nombre de usuario PRUEBA, y el resultado es PRUEBA SUPERADA.

Al ejecutar otra prueba con los mismos datos:
DatosPrueba.NUsser1=”PRUEBA”
DatosPrueba.NPass1=”PRUEBA”
DatosPrueba.NNivel1=1
La prueba arroja lo siguiente:
La prueba no fue superada debido a que el nombre de usuario ya se encuentra registrado, y

genera una excepción.
Podemos decir que a partir de estas dos pruebas se pudo probar el funcionamiento del método
InsertNuevoUsuario, los cuales arrojaron resultados correctos al intentar almacenar datos
nuevos y no permitir la inserción de nombres de usuarios repetidos.

ID Prueba: 2
Descripción: permitir almacenar el lugar para guardar las grabaciones.
Datos Requeridos:
 No debe estar registrado el lugar para almacenar las grabaciones.
Pre Condiciones:
 ingresar el lugar para almacenar las grabaciones.
Resultados esperados: inserción de la ruta.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_InsertRuta de

prueba:
Donde para la realización de la prueba, utilizamos oRuta que es una instancia de la clase Ruta, a
la cual se le asigna los siguientes valores para iniciar la prueba:
oRuta.DIRECCION1=” Nueva Dirección”.

La prueba se aplicará al método InsertRuta
Al ejecutar la prueba, la ruta se almacena correctamente ya que no había una ruta almacenada,
y el resultado es PRUEBA SUPERADA.

Al ejecutar otra prueba, tratando de insertar nuevamente el lugar para el almacenamiento:
La prueba no fue superada debido a que ya se encuentra registrada la Ruta, generando una
excepción.
Podemos decir que a partir de estas dos pruebas se pudo probar el funcionamiento del método
InsertRuta, los cuales arrojaron resultados correctos al intentar almacenar la Ruta y no permitir
la inserción de otra Ruta.
ID Prueba: 3
Descripción: actualizar el lugar del almacenamiento de las grabaciones.
Datos Requeridos:
 Selección de un nuevo lugar para almacenar las grabaciones.
Pre Condiciones: -
Resultados esperados: actualización de la ruta.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod de prueba.
El cual se aplicará al método ActualizarRuta

Donde para la realización de la prueba, utilizamos oRuta que es una instancia de la clase Ruta, a
la cual se le asigna los siguientes valores para iniciar la prueba:
oRuta.DIRECCION1=” Nueva Dirección”.
Al ejecutar la prueba la nueva ruta se actualizo correctamente, y el resultado es PRUEBA

SUPERADA.
Podemos decir que a partir de esta prueba se pudo probar el correcto funcionamiento del
método ActualizarRuta, los cuales arrojaron resultados correctos al intentar actualizar la Ruta.
ID Prueba: 4
HU: Modificar número de envió de alerta
Descripción: actualizar el número para el envío de la alerta.
Datos Requeridos:
 Número para el envió de la alerta debe estar registrado.
Pre Condiciones: Numero registrado.
Resultados esperados: actualización del número.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_OperTelefono de

prueba.
Donde se utilizará la variable “operación” para indicar la operación a realizar (actualización del
teléfono cuando operación sea igual a 2 y la inserción del teléfono cuando operación sea igual
1).
Para la actualización se utilizará los siguientes parámetros:
Operación=2

oTel.Telefono=”388XXXXXXX” (oTel es una instancia de la clase Teléfono).
El cual se aplicará al método OperacionTelefono
Al ejecutar la prueba el nuevo número de teléfono se actualizo correctamente, y el resultado es

PRUEBA SUPERADA.
método OperacionTelefono, los cuales arrojaron resultados correctos al actualizar el número de
teléfono.
ID Prueba: 5
Descripción: permitir insertar el número de teléfono
Datos Requeridos:
 Número de teléfono no debe estar registrado.
Pre Condiciones: Numero no registrado.
Resultados esperados: almacenamiento del número.
Post Condiciones:


Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_OperTelefono de

prueba.
Para la inserción se utilizará los siguientes parámetros:
Operación=1
oTel.Telefono=”388XXXXXXX” (es una instancia de la clase Teléfono).
El cual se aplicará al método OperacionTelefono
Al no encontrarse registrado ningún teléfono para el envío de la alerta, y luego ejecutar la

prueba para el almacenamiento del teléfono, el resultado es PRUEBA SUPERADA.
Al ejecutar otra prueba con los mismos datos:
Operación=1
oTel.Telefono=”388XXXXXXX”

La prueba no fue superada debido a que ya se encuentra registrado un teléfono para el envío
de la alerta.
Podemos decir que a partir de estas dos pruebas se pudo probar el correcto funcionamiento del
método OperacionTelefono, los cuales arrojaron resultados correctos al intentar almacenar el
insertar el teléfono y no permitir la inserción de otro.
ID Prueba: 6
HU: Logueo
Descripción: permitir iniciar sesión en el prototipo.
Datos Requeridos:
 Usuario registrado en el prototipo.
Pre Condiciones:
 Ingresar usuario registrado.
 Ingresar clave del usuario.
Resultados esperados: permitir el acceso al prototipo
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_Login de prueba.

Para la prueba se utilizó los siguientes parámetros:
oUser.NUsser1=” ADMIN”
oUser.NPass1=”123”
El cual se aplicará al método BuscarUser

Al encontrar que los datos ingresados son correctos, el resultado es PRUEBA SUPERADA.
Al ejecutar otra prueba con datos no válidos:
oUser.NUsser1=” admin”
oUser.NPass1=”1232”
La prueba no fue superada debido a que no se encuentra registrado un usuario con los datos
ingresados.
Podemos decir que a partir de estas dos pruebas se pudo probar el correcto funcionamiento del
método BuscarUser, los cuales arrojaron resultados correctos al intentar iniciar sesión con datos
correctos y no permitir el acceso al prototipo al ingresar datos erróneos.

ID Prueba: 7
HU: Detección de movimiento
Descripción: detecta movimiento por la cámara web
Datos Requeridos:
 Iniciar la detección de movimiento.
Pre Condiciones: -
Resultados esperados: detectar movimiento.
Post Condiciones:
 Informar si se detectó movimiento
Estado: Terminado.
Para la realización de la prueba se utilizó el siguiente método de prueba.

La prueba se realizará sobre el siguiente método:
Se utiliza la variable “contador” como un temporizador para un chequeo de la cámara para

empezar la detección, sin ese fragmento de código la cámara detecta movimiento cuando no
hay movimiento.
Para poder indicar que se detectó movimiento por la cámara se utiliza el siguiente método:
Con lo cual se puede decir que el resultado de la prueba es PRUEBA SUPERADA.
A partir de esta prueba se pudo probar el funcionamiento del método Timer1_Tick los cuales
arrojaron resultados correctos al detectar movimiento y mostrando el nivel de movimiento
detectado.
ID Prueba: 8
HU: Envío de Alertas
Descripción: envío de alerta a través de SMS.
Datos Requeridos:
 Detección de movimiento por la cámara web.
Pre Condiciones: Detección de movimiento.
Resultados esperados: Envió del SMS.
Post Condiciones:
 Informar si se detectó movimiento
Estado: Terminado.

Para la realización de la prueba se definió el siguiente método TestMethod_Alerta de prueba.
El cual se aplicará al método AlertaMensaje:
Al ejecutar la prueba para el envío de la alerta, el resultado es PRUEBA SUPERADA.
método AlertaMensaje, los cuales arrojaron resultados correctos al enviar la alerta de SMS.
ID Prueba: 9
Descripción: permitir modificar la clave y/o nivel de los usuarios.
Datos Requeridos:
 ingresar nueva contraseña.
 Seleccionar nivel.
Pre Condiciones:
Resultados esperados: guardar los cambios para el usuario.
Post Condiciones:
Estado: Terminado.

Para la realización de la prueba se definió el siguiente método TestMethod_UpUsuarios de

prueba.
El cual se aplicará al método UpdateUsuario
Al ejecutar la prueba los datos del usuario fueron modificados correctamente, y el resultado es
PRUEBA SUPERADA.
Podemos decir que a partir de esta prueba se pudo probar el funcionamiento del método
UpdateUsuario, los cuales arrojaron resultados correctos al actualizar los datos del usuario ya
sea la clave y/o el nivel.
ID Prueba: 10
Descripción: permitir eliminar un usuario.
Datos Requeridos:
 Seleccionar un usuario.
Pre Condiciones:
Resultados esperados: eliminación de usuario.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_DelUsuarios de

prueba.

El cual se aplicará al método EliminarUsuario
Al ejecutar la prueba el usuario seleccionado fue eliminado correctamente, y el resultado es

PRUEBA SUPERADA.
Podemos decir que a partir de esta prueba se puedo probar el funcionamiento del método
EliminarUsuario, los cuales arrojaron resultados correctos al tratar de eliminar un usuario
registrado.
ID Prueba: 11
Descripción: mostrar todos los niveles que pueden ser asignados a los usuarios.
Datos Requeridos:
 -
Pre Condiciones:
 Niveles registrados en el prototipo.
Resultados esperados: mostrar los niveles disponibles.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_Niveles de prueba.

El cual se aplicará al método TraerNiveles
Al ejecutar la prueba se pudieron visualizar todos los niveles disponibles que pueden ser
seleccionados, y el resultado es PRUEBA SUPERADA.
Podemos decir que a partir de esta prueba se pudo probar el funcionamiento del método
TraerNiveles, los cuales arrojaron resultados correctos al buscar los niveles disponibles, ya sea
cuando se quiere dar de alta un usuario o modificar su nivel.
ID Prueba: 12
Descripción: controlar el correcto ingreso del número para el envió de la alerta.
Datos Requeridos:
 Ingreso de número para la alerta.

Pre Condiciones:
 Número para el envió de la alerta registrado.
Resultados esperados: almacenar el número.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_ControlTelefono de

prueba.
El cual se aplicará al método NTel
Para la realización de la prueba se utilizará la variable “tel”, a la que se le asignó el número

ingresado para verificar si fue ingresado correctamente. Al asignarle a tel un formato correcto
de teléfono permitido, por ejemplo: tel:”3885XXXXXX”. Al ejecutar la prueba el resultado fue
PRUEBA SUPERADA.
Al ejecutar otra prueba, pero asignándole un formato incorrecto a tel, por ejemplo, tel:
”03885XXXXX”, el resultado de la prueba fue PRUEBA NO SUPERADA.

Podemos decir que a partir de esta prueba se pudo probar el funcionamiento del método NTel,
los cuales arrojaron resultados correctos intentar insertar o actualizar un número de teléfono
con un formato correcto, y al intentar insertar o actualizar un teléfono con formato incorrecto
no se permite dichas operaciones.
ID Prueba: 13
HU: Gestión usuarios
Descripción: permitir a los usuarios que tienen un nivel de INVITADO cambiar su clave.
Datos Requeridos:
 Ingreso de clave actual
 Ingreso de nueva clave
Pre Condiciones:
Resultados esperados: actualizar la clave.
Post Condiciones:
Estado: Terminado.
Para la realización de la prueba se definió el siguiente método TestMethod_PassInvitado de

prueba.
Donde
npass1 y npass2: son la nueva clave introducida por el usuario.
user: el usuario que desea cambiar la clave con nivel de invitado.
actualPass: la clave actual que tiene registrada el usuario invitado.
El cual se aplicará al método ControlCambioPass

Al asignar le valores a las variables correctos:

npass1= ”321”
npass2= ”321”
user=” INVITADO”
actualPass=”123”
Al ejecutar la prueba con estos valores se actualizo la clave del usuario, y el resultado es PRUEBA
SUPERADA.
Al ejecutar otra prueba con otros valores, donde la clave actual se ingresa incorrectamente:
npass1= ”123”
npass2= ”123”
user=” INVITADO”
actualPass=”123”
El resultado de la prueba fue, PRUEBA NO SUPERADA.
Podemos decir que a partir de estas pruebas se pudo probar el funcionamiento del método
ControlCambioPass, los cuales arrojaron resultados correctos al cambiar la clave del usuario de
nivel invitado, y al intentar cambiar la clave, pero se ingresa de manera incorrecta la clave actual
o las claves nuevas ingresadas no son iguales no se permite el cambio de clave al usuario.

7.3 – Prueba de Tiempo de Respuesta

En esta prueba se medirá el tiempo de respuesta, es decir cuánto tarda el prototipo en enviar el
SMS desde que se detecta el movimiento por la cámara web para avisar la detección del mismo.
Para este caso de prueba se utilizará la herramienta POSTMAN.
POSTMAN nos permite realizar peticiones HTTP (GET, POST, DELETE, UPDATE…) a una dirección
de nuestro interés. Esto es de gran utilidad a la hora de interactuar con APIs Web e, incluso, para
testear nuestros propios desarrollos. (Luis, 2017).
Esta herramienta nos permite construir y gestionar de una forma cómoda nuestras peticiones a
servicios REST HTTP (GET, POST, DELETE, UPDATE, entre otros) a una dirección de nuestro
interés. Su manejo es realmente intuitivo ya que simplemente tenemos que definir la petición
que queremos realizar.
 Servicios REST: es cualquier interfaz entre sistemas que use HTTP para obtener datos o
generar operaciones sobre esos datos en todos los formatos posibles, como XML y JSON.
(BBVAOPEN4U, 2016).
Uno de los puntos más potentes de Postman, es la posibilidad de definir todas las variables que
se necesite y clasificarlas por entornos de trabajo. Esto es muy útil cuando se tiene diferentes
proyectos o cuando se necesita configurar múltiples entornos para un mismo proyecto (por
ejemplo, diferentes cabeceras, URLs de cada uno de los entornos de trabajo – local,
preproducción o incluso producción, etc.). (Luis, 2017).
Para la realización de la prueba se planteó el siguiente caso:
Imagen de la herramienta POSTMAN para la realización de la prueba

Se utilizará las siguientes opciones:
POST: para la realización de la prueba se utilizará la solicitud POST la que es un método que se
usa cuando necesitamos enviar una petición al servidor. Al enviar la solicitud POST,
pretendemos realizar algunas modificaciones en el servidor (como la actualización, la
eliminación o la adición), para este caso sería él envío del sms a un destinatario.
Params: Los parámetros de solicitud son parte de la URL que se utiliza para enviar datos al
servidor.
Podemos apreciar en la siguiente figura se cargo la URL y los parametros necesarios para el envio
de la solicitud al servidor:
Parámetros utilizados:
apiKey: se la utiliza como medio de identificación con el servidor, para el envío de la solicitud.
numbers: es el número al que se desea enviar el SMS.
message: es el mensaje a enviar.
send: identificación de quien envía el sms.
Al presionar el botón Send se envía la solicitud al servidor. El servidor al recibir la petición para
el envío del SMS, envía el SMS al celular solicitado en un tiempo de 1705 ms.

Luego del envío de 5 solicitudes, los tiempos para mismo fueron entre 1300 ms y 1900 ms.
N.º Solicitud Tiempo

1 1705
2 1870
3 1322
4 1550
5 1380
Al analizar los tiempos de respuesta, los cuales se podría decir que tienen un máximo de 2
segundos (2000ms), podemos considerar el tiempo aceptable para él envió del SMS (aviso de la
detección de movimiento).

8 - Cronograma
Cabe aclarar que en los Sprint figura la pila del Sprint correspondiente a cada uno de ellos.
9 - Conclusión:
Podemos decir que se ha logrado cumplir con los objetivos específicos de este trabajo, que ha
cumplido con el alcance definido para el prototipo de aviso de intrusos al detectar movimiento
mediante cámara web. Con este prototipo se brinda una herramienta alternativa para reducir la
incertidumbre de los dueños de propiedades a la hora de dejarlas solas.
Dicho prototipo proporciona una herramienta que comunicará a quien corresponda cuando
detecte movimientos en la propiedad, buscando de esta manera reducir los robos o daños a las
mismas, ya que con una simple alerta a los dueños se evita cualquier inconveniente.
Este prototipo se diseñó para que sea accesible a cualquier persona, ya que puede ser utilizado
con una simple cámara web existente en el mercado y proporcionará el beneficio de informar a
los propietarios ante la ocurrencia de un evento de intrusión o daño.
Además, este prototipo realizará la grabación automática de videos después del envío del aviso
de intrusos y permitirá también la visualización de las grabaciones que se producen al detectar
movimientos en un determinado ángulo de visión de la cámara.
También permite controlar quien podrá tener acceso al prototipo, permitiendo gestionar los
usuarios y de este modo se podrá agregar, modificar y/o eliminar usuarios.
De esta manera podemos afirmar que se logró el cumplimiento del objetivo específico, que
motivó la necesidad de realizar este trabajo final.

A futuro se pensó en que se podría adicionar al prototipo otras alternativas, ya que el mismo ha
sido desarrollado con una gran flexibilidad de expansión. Entre ellas podemos mencionar:
 Grabación de video en intervalos de tiempo definidos cuando detecta el movimiento,

enviando notificaciones de detección de movimiento.
 Al detectar movimiento envió masivo de alerta en forma de SMS.
 Transmisión de video online (streaming de video) permitiendo visualizar lo que está
sucediendo en tiempo real.
 Activación de una alarma sonora al detectar movimiento por la cámara web, alertando
de la intrusión en la propiedad.
 Permitir agregar más de una cámara web al prototipo para monitorear en diferentes
lugares dentro de las propiedades.

Bibliografía
Aarons, A. (2018). Cuál es la función de las camaras de circuito cerrado. Obtenido de
https://techlandia.com/funcion-camaras-circuito-cerrado-hechos_430699/
Aforge. (2018). AForge.NET. Obtenido de http://www.aforgenet.com/framework/
Aforge. (s.f.). Detección de movimiento. Obtenido de

http://www.aforgenet.com/framework/features/motion_detection_2.0.html
Aforgenet. (2018). Obtenido de

http://www.aforgenet.com/framework/features/index.html#video
Aforgenet. (2018). http://www.aforgenet.com/framework/features/index.html#video.
Angel. (30 de diciembre de 2012). Qué es y para qué sirve Microsoft Access. Obtenido de
http://www.accessyexcel.com/que-es-y-para-que-sirve-microsoft-access/
BBVAOPEN4U. (23 de Marzo de 2016). API REST: qué es y cuáles son sus ventajas en el
desarrollo de proyectos. Obtenido de https://bbvaopen4u.com/es/actualidad/api-rest-
que-es-y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos
BOXER. (2018). Productos y servicios. Obtenido de

http://www.boxerseguridad.com.ar/productos-y-servicios.html
Debian. (2018). ¿Qué es GNU/Linux? Obtenido de

https://www.debian.org/releases/etch/hppa/ch01s02.html.es
Elecristy. (28 de Enero de 2014). La programación por capas. Obtenido de

https://www.codejobs.com/es/blog/2014/01/28/la-programacion-por-capas
EMOPA. (2015). Tipos de DVR o Video Grabadores para CCTV. Obtenido de

https://www.emopa.com/blog/grupo-emopa/tipos-de-dvr-o-video-grabadores-para-
cctv/
Framework, A. (2013). AForge.Vision.Motion Namespace. Obtenido de

http://www.aforgenet.com/aforge/framework/docs/html/40a6b51f-9f55-0569-ce0b-
3c1efeeec056.htm
Gino, F. (s.f.). MAC OS. Obtenido de http://sistemasoperativoutp.weebly.com/macintosh.html
Gutiérrez, A. (24 de Febrero de 2014). Programación en capas. Obtenido de

http://pixelg.org/software/item/44-programacion-en-capas.html
Gutl. (13 de Febrero de 2014). Introducción. Obtenido de

https://gutl.jovenclub.cu/wiki/doku.php?id=tutoriales:convertir_videos_consola_ffmp
eg_memcoder
Informática&Tecnología. (2018). Las funciones de la computadora. Obtenido de

https://tecnologia-informatica.com/funciones-de-la-computadora/
InformaticaModerna. (s.f.). Camara Web/WebCam. Obtenido de

http://www.informaticamoderna.com/Camara_web.htm
informaticamoderna. (s.f.). http://www.informaticamoderna.com/Camara_web.htm.

Ipcamaras. (s.f.). Como funciona una camara IP. Obtenido de

http://www.ipcamaras.com.uy/funcionamiento.php
KABEL. (2012). Scrum y Extreme Programming (XP). Obtenido de https://www.kabel.es/scrum-

y-extreme-programming-xp/
Kusztrich, M. D. (30 de Abril de 2016). Captura y reproducción de video con DirectShow.

Conceptos básicos. Obtenido de http://software-tecnico-libre.es/es/articulo-por-
tema/todas-las-secciones/todos-los-temas/todos-los-articulos/conceptos-basicos-
directshow
Loyo, A. (s.f.). Visión Computacional. Obtenido de https://sg.com.mx/revista/55/visi-n-

computacional
Luis, L. (2 de Octubre de 2017). POSTMAN, REALIZA PETICIONES HTTP Y PRUEBA TUS API REST.
Obtenido de https://www.luisllamas.es/realizar-peticiones-http-con-postman/
Manager, S. (27 de Abril de 2014). Scrum diario. Obtenido de

http://www.scrummanager.net/bok/index.php?title=Scrum_diario
Manager, S. (2015). Scrum Manager I . Scrum Manager .
Manager, S. (16 de octubre de 2016). Artefactos. Obtenido de

https://www.scrummanager.net/bok/index.php?title=Artefactos
Manager, S. (16 de octubre de 2016). Eventos. Obtenido de

http://www.scrummanager.net/bok/index.php?title=Eventos
Manager, S. (8 de Diciembre de 2016). Propietario del producto. Obtenido de

https://www.scrummanager.net/bok/index.php?title=Propietario_del_producto
Microsoft. (2018). Introducción a DirectShow. Obtenido de https://docs.microsoft.com/es-

es/windows/desktop/DirectShow/introduction-to-directshow
MisApuntesSistemas. (Enero de 2012). Para qué sirve Microsoft Access. Obtenido de

http://misapuntes.info/MisDocumentosWindows/Para_que_sirve_Microsoft_Access.p
df
MODERNA, I. (s.f.). La Camara IP/POE. Obtenido de

http://www.informaticamoderna.com/Camara_IP.htm
msn. (2018). ¿Qué es y para qué sirve Visual Studio 2017? Obtenido de
https://www.msn.com/es-cl/noticias/microsoftstore/%C2%BFqu%C3%A9-es-y-para-
qu%C3%A9-sirve-visual-studio-2017/ar-AAnLZL9
Nación, M. d. (Junio de 2016). Estadísticas Criminales en la República Argentina – Año 2016.

Obtenido de
https://estadisticascriminales.minseg.gob.ar/reports/Informe%20estadisticas%20crimi
nales%20Republica%20Argentina%202016.pdf
PCLite. (s.f.). ¿QUE ES UN DVR? Obtenido de https://pclite.cl/dvr.php
Perpiñan, N. S. (2017). Desarrollo de Software en 3 Capas. SENA Comunica, 13.
Pressman, R. S. (2010). Ingeniería del software: un enfoque práctico.

Quispe Aduviri, M. (2013). Reconocimiento de Gestos para la Inteneraccion por Computador,

con Realidad Aumentada. Obtenido de RECONOCIMIENTO DE GESTOS PARA LA
INTERACCIÓN POR COMPUTADOR, CON REALIDAD AUMENTADA
Rafael, S. (s.f.). Obtenido de

http://www.rafaelsantos.es/web/agora/apuntesado/Acceso%20a%20datos%20en%20
Visual%20Basic%20.NET%20con%20ADO.NET.pdf
scrummanager. (s.f.). http://www.scrummanager.net. Obtenido de

http://www.scrummanager.net/bok/index.php?title=Estimaci%C3%B3n_de_p%C3%B3
quer
SeguridadSOS. (s.f.). DVR. Obtenido de http://www.seguridadsos.com.ar/dvr/
Sucar, L. E. (s.f.). Visión Computacional. Obtenido de

https://ccc.inaoep.mx/~esucar/Libros/vision-sucar-gomez.pdf
TECNOLOGIA&INFORMATICA. (2018). El sistema operativo. Obtenido de https://tecnologia-

informatica.com/el-sistema-operativo/
Velásquez, I. R. (s.f.). Acceso a datos con ADO -NET - Objeto Connection. Obtenido de
https://www.coursehero.com/file/27055462/21-Acceso-a-datos-con-ADO-NET-
Objeto-Connectionpdf/
Wingu. (1 de Agosto de 2016). Manual de Metodologías Ágiles. Obtenido de

https://www.winguweb.org/system/files/biblioteca/manual_de_metologias_agiles_fin
al.pdf
Yolanda, B. L. (2013). Metodología Ágil de Desarrollo de Software – XP .
YSALIDA, D. D. (26 de Marzo de 2017). Web Dispositivos de Entrada. Obtenido de

http://tareadeinformaticacreaciondeunblog.blogspot.com/2017/03/articulo-2.html

Anexo
Diseño de la Base de datos
Esquema de datos
Tabla USUARIOS
USUARIOS
Nombre del Campo Tipo Descripción
USERNAME Texto Corto Nombre de usuario unico distinto de vacío para acceder al prototipo
USERPASS Texto Corto Clave correspondiente al usuario distinto de vacío
ID_NIVEL Número Nivel para el usuario, indica los permisos que tendra. Distinto de vacío
Indices
USERNAME Primary Key
ID_NIVEL Foreign Key de la Tabla Nivel
Tabla NIVEL
NIVEL
ID_NIVEL Numero Clave unico para el nivel distinto de vacío
TIPO Texto largo Descripción del nivel
Indices
ID_NIVEL Primary Key
Tabla RUTA
RUTA
ID_RUTA Numero Clave unica de la ruta distinto de vacío
DIRECCION Texto largo Lugar donde se almacenaran las grabaciones
Indices
ID_RUTA Primary Key

Tabla ALERTA
ALERTA
ID Número Clave unica de la alerta distinto de vacío
TELEFONO Número Número de celular para mandar la alerta
Indices
ID_RUTA Primary Key
Otras librerías existentes para la detección de Movimiento
 OpenCV
OpenCV (Open Source Computer Vision Library) es una biblioteca de software de visión abierta
y software de aprendizaje automático. OpenCV fue construido para proporcionar una
infraestructura común para aplicaciones de visión por computadora y para acelerar el uso de la
percepción de la máquina en los productos comerciales. Al ser un producto con licencia de BSD,
OpenCV facilita a las empresas utilizar y modificar el código.
 Emgu CV
Es un contenedor .Net de plataforma cruzada para la biblioteca de procesamiento de imágenes

OpenCV. Permitir que las funciones de OpenCV se invoquen desde lenguajes compatibles con
.NET, como C #, VB, VC ++, IronPython, etc. Visual Studio, Xamarin Studio y Unity pueden
compilar el envoltorio, que puede ejecutarse en Windows, Linux, Mac OS X, iOS, Android y
Windows Phone.
AccessDatabaseEngine
Conjunto de driver que permiten la conexión con las bases de datos Access sin la necesidad de
tener instalado el paquete office, este es distribuido por Microsoft de manera gratuita. Es decir,
permite realizar operación sobre la base de datos desde un lenguaje de programación aun
cuando no se tiene instalado el paquete office.

Documentacion Trabajo Final SysCam - Chañi Alarcon Martin PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Documentacion Trabajo Final SysCam - Chañi Alarcon Martin PDF

Загружено:

Авторское право:

Доступные форматы

SysCam

PROTOTIPO DE SISTEMA DE VIGILANCIA DOMESTICO CON AVISO

Alumno: CHAÑI ALARCON, MARTIN HORACIO

Tutor: ING. GLADIS BENITEZ

A mi madre Liduvina, quien me brindó su apoyo incondicional a lo largo de

CHAÑI ALARCON, MARTIN HORACIO 1

6.1.6 - Estimación de las Historias de Usuario para su medida. ......................................... 30

CHAÑI ALARCON, MARTIN HORACIO 2

CHAÑI ALARCON, MARTIN HORACIO 3

1 - Título del proyecto y descripción del problema

Lo que se pretende con la realización del presente trabajo, es desarrollar un prototipo de

2.2 - Objetivos específicos:

2.3 - Alcance del prototipo

En el prototipo se contemplaron las siguientes funciones:

 Se pondrá énfasis en la detección de movimiento por medio de una cámara web,

CHAÑI ALARCON, MARTIN HORACIO 4

 No se contempla el diseño de la interfaz del usuario en su totalidad.

3.1 - Circuito cerrado de televisión:

Tipos de DVR según EMOPA (2015) son:

 DVR Analógico: suele disponer de 4, 8, 16 ó 32 canales. Se utiliza para conectar cámaras

CHAÑI ALARCON, MARTIN HORACIO 5

ventajas de las redes de comunicación IP (siempre se utiliza cableado UTP para

3.2 - Cámaras IP:

Las partes de una cámara IP según MODERNA (s.f.) son:

Ilustración 1- Partes de una Cámara IP

CHAÑI ALARCON, MARTIN HORACIO 6

3.3 - Empresas de seguridad privada:

5.1 - Aplicación de escritorio

Computadora: Una computadora es un dispositivo electrónico utilizado para el procesamiento

CHAÑI ALARCON, MARTIN HORACIO 7

5.3 - Cámara Web

Las partes de una camara web según INFORMATICAMODERNA (s.f.) son:

Ilustración 2 - Partes de la Cámara Web

1.- Visor digital: se encarga de captar las imágenes a transmitir y grabar.

Funcionamiento interno de la cámara según INFORMATICAMODERNA (s.f.) es:

Ilustración 3 - Funcionamiento Interno de la Cámara Web

5.4 - Sistema operativo:

CHAÑI ALARCON, MARTIN HORACIO 8

 Sistema operativo: Un sistema operativo puede ser definido como un conjunto de

5.4.1 - Tipos de Sistemas Operativos

 Windows: Windows es un sistema operativo producido por Microsoft Corporation. Está

5.5 - Herramientas de desarrollo

 Visual Studio .NET: es un conjunto completo de herramientas de desarrollo para la

5.6 - Programación por capas

 Capa de presentación: Es todo lo visible al usuario, le muestra y captura toda la

CHAÑI ALARCON, MARTIN HORACIO 9

5.7 - Servicio de mensajes simples (SMS)

ADO .NET es un conjunto de componentes de software de computadora que los programadores

Acceso los datos con ADO.NET:

CHAÑI ALARCON, MARTIN HORACIO 10

Sin importar la operación que se desee realizar los pasos son:

Ilustración 4 - Objetos comunes de ADO.NET

ADO.NET proporciona un modelo de objetos común para proveedores de datos de .NET. A

 Provider: un proveedor de datos ADO.NET es un componente de software que interactúa

CHAÑI ALARCON, MARTIN HORACIO 11

El modo de funcionamiento típico de ADO.NET es el siguiente en un entorno desconectado:

 Se crean un objeto Connection especificando la cadena de conexión.

Herramientas que ofrece Access más relevantes:

CHAÑI ALARCON, MARTIN HORACIO 12

CHAÑI ALARCON, MARTIN HORACIO 13

Ilustración 7 - Diseño Formulario

CHAÑI ALARCON, MARTIN HORACIO 14

por Computador, procesamiento de imágenes, aprendizaje automático, robótica, entre otros”.