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

Ingeniería en Informática Trabajo Final: SysCam

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 CHAÑI ALARCON, MARTIN HORACIO

2

Ingeniería en Informática Trabajo Final: SysCam

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

CHAÑI ALARCON, MARTIN HORACIO

3

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

4

Ingeniería en Informática Trabajo Final: SysCam

 

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

CHAÑI ALARCON, MARTIN HORACIO

5

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

6

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

7

Ingeniería en Informática Trabajo Final: SysCam

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:

CHAÑI ALARCON, MARTIN HORACIO

8

Ingeniería en Informática Trabajo Final: SysCam



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.

CHAÑI ALARCON, MARTIN HORACIO

9

Ingeniería en Informática Trabajo Final: SysCam





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:

CHAÑI ALARCON, MARTIN HORACIO

10

Ingeniería en Informática Trabajo Final: SysCam

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

Abrir la conexión Ejecutar los comandos 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

CHAÑI ALARCON, MARTIN HORACIO

11

Ingeniería en Informática Trabajo Final: SysCam

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:

CHAÑI ALARCON, MARTIN HORACIO

12

Ingeniería en Informática Trabajo Final: SysCam

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 Fuente: Angel (2012)

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)

CHAÑI ALARCON, MARTIN HORACIO

13

Ingeniería en Informática Trabajo Final: SysCam

Ilustración 7 - Diseño Formulario Fuente: Angel (2012)

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 Fuente: Angel (2012)

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

CHAÑI ALARCON, MARTIN HORACIO

14

Ingeniería en Informática Trabajo Final: SysCam

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)

CHAÑI ALARCON, MARTIN HORACIO

15

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

16

Ingeniería en Informática Trabajo Final: SysCam

 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.

CHAÑI ALARCON, MARTIN HORACIO

17

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

18

Ingeniería en Informática Trabajo Final: SysCam

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:

CHAÑI ALARCON, MARTIN HORACIO

19

Ingeniería en Informática Trabajo Final: SysCam



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 CHAÑI ALARCON, MARTIN HORACIO

20

Ingeniería en Informática Trabajo Final: SysCam

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”).

CHAÑI ALARCON, MARTIN HORACIO

21

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

22

Ingeniería en Informática Trabajo Final: SysCam



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

Alta

3

Media

2

Baja

1

CHAÑI ALARCON, MARTIN HORACIO

Descripción Está definida para aquellos requerimientos necesarios para 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í 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 de interfaz, normas de calidad adicionales, pruebas adicionales, etc.

23

Ingeniería en Informática Trabajo Final: SysCam

-

-

-

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.

CHAÑI ALARCON, MARTIN HORACIO

24

Ingeniería en Informática Trabajo Final: SysCam

-

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

CHAÑI ALARCON, MARTIN HORACIO

25

Ingeniería en Informática Trabajo Final: SysCam

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:

CHAÑI ALARCON, MARTIN HORACIO

26

Ingeniería en Informática Trabajo Final: SysCam

 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. 2. 3. 4. 

Diseño de pantallas para la versión de prueba correspondiente. Pruebas de integración probadas y superadas. Prueba de aceptación. 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.

CHAÑI ALARCON, MARTIN HORACIO

27

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

28

Ingeniería en Informática Trabajo Final: SysCam

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 HU1 HU2 HU3 HU4 HU5 HU6 HU7 HU8

Descripción Logueo Gestión usuarios Grabación de video Detección de movimiento Envió de Alertas Reproducción de grabaciones Definición dirección almacenamiento Modificar número de envió de alerta

CHAÑI ALARCON, MARTIN HORACIO

Responsable MC MC MC MC MC MC MC MC

29

Ingeniería en Informática Trabajo Final: SysCam

6.1.5 – Diagrama de Clase del Prototipo class Clase

Usuarios

Ruta + + +

Prototipo

Direccion: Char Id_Ruta: Integer 1

BuscarRuta() : Integer InsertarRuta() : void ModificarRuta() : void 1 1

-

TipoNivel: int

+ + +

BuscarNivelUsuario() : void ControlarAcceso() : void HabilitarOpciones() : void

1

1

1

1

1

Id_Nivel: int UserName: char UserPass: char

+ + + +

AgregarUsuarios() : void BuscarUsuarios() : void EliminarUsuarios() : void ModificarUsuarios() : void *

1

1

Reproduccion + + +

1

-

1

Alarma

BuscarRuta() : void CargarGrabaciones() : void SeleccionarGrabacion() : void 1

Niv el

-

Id: int Telefono: int

+ +

InsertarNumero() : void ModificarNumero() : void

-

Id_Nivel: int Tipo: int

+

MostrarNiveles() : void

Deteccion Mov imiento -

Deteccion: char

+ + +

DetenerDeteccion() : void EnviarSeñal() : void IniciarDeteccion() : void

Grabacion 1

1

+ + + +

AlmacenarGrabacion() : void DetenerGrabacion() : 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 𝑗𝑜𝑟𝑛𝑎𝑑𝑎 𝑑𝑒 𝑡𝑟𝑎𝑏𝑎𝑗𝑜 𝑑𝑒 𝑢𝑛 𝑚𝑖𝑒𝑚𝑏𝑟𝑜 𝑑𝑒𝑙 𝑒𝑞𝑢𝑖𝑝𝑜 𝑒𝑛 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖𝑜𝑛 𝑒𝑥𝑐𝑙𝑢𝑠𝑖𝑣𝑎

DIA

HORAS

PUNTOS DE 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.

CHAÑI ALARCON, MARTIN HORACIO

30

Ingeniería en Informática Trabajo Final: SysCam

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. Número: 5 Usuario: Administrador/Invitado 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. Número: 6 Usuario: Administrador/Invitado 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.

CHAÑI ALARCON, MARTIN HORACIO

31

Ingeniería en Informática Trabajo Final: SysCam

Número: 7 Usuario: Administrador 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. Número: 8 Usuario: Administrador 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

Alta

3

Media

2

Baja

1

Descripción Está definida para aquellos requerimientos necesarios para 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í 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 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:

CHAÑI ALARCON, MARTIN HORACIO

32

Ingeniería en Informática Trabajo Final: SysCam

Prioridad 3 3 3 2 2 1 1 1

ID HU4 HU5 HU3 HU1 HU2 HU7 HU6 HU8

Descripción Responsable Detección de movimiento MC Envío de Alertas MC Grabación de video MC Logueo MC Gestión usuarios MC Definición dirección almacenamiento MC MC Reproducción de grabaciones MC Modificar número de envío de alerta

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.

CHAÑI ALARCON, MARTIN HORACIO

33

Ingeniería en Informática Trabajo Final: SysCam

 



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

pesimista

Estimada

13

Optimo

Puntos Estimados

10

10 7

5

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: ID Prioridad HU4 3 1 HU5 3 HU3 3 HU1 2 2 HU2 2 HU7 1 3 HU6 1 HU8 1 Total Puntos estimados Versiones

Descripción Detección de movimiento Envió de Alerta Grabación de video Logueo Gestión usuarios Definición dirección almacenamiento Reproducción de grabaciones Modificar número de envió de alerta

Estimación 5 3 2 4 3 3 5 2 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 7 10 14 20 21 30 28 40

CHAÑI ALARCON, MARTIN HORACIO

Optimista 13 26 39 52

34

Ingeniería en Informática Trabajo Final: SysCam

Estimación de la cantidad de días para cada versión: Cantidad de Días Versiones Total Estimación 10 1 7 2 10 3 Total Días

Pesimista 20 12 20 52

Estimada 14 6 14 34

Optimista 11 5 13 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 Versión 1 2 3

05/03/2018 Fecha entrega Pesimista Estimada 02/04/2018 20/03/2018 18/04/2018 28/03/2018 17/05/2018 11/04/2018

Optimista 19/03/2018 26/03/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 HU4 HU5 HU3

Descripción Detección de movimiento Envío de Alertas Grabación de video

Responsable MC MC MC

Estimación 5 3 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.

CHAÑI ALARCON, MARTIN HORACIO

35

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

36

Ingeniería en Informática Trabajo Final: SysCam

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 HU4: Detección de movimiento

ID: 1 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

CHAÑI ALARCON, MARTIN HORACIO

37

Ingeniería en Informática Trabajo Final: SysCam

Prueba de Aceptación 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. Resultados esperados:  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.

CHAÑI ALARCON, MARTIN HORACIO

38

Ingeniería en Informática Trabajo Final: SysCam

Historias de Usuario que se abordarán: ID HU3 HU1

Descripción Responsable Estimación Grabación de video MC 2 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:

6.5.2 - Burn Down del 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

CHAÑI ALARCON, MARTIN HORACIO

39

Ingeniería en Informática Trabajo Final: SysCam

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. Historias de Usuarios completadas: HU3: Grabación de video

Prueba de Aceptación 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. Resultados esperados:  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.

CHAÑI ALARCON, MARTIN HORACIO

40

Ingeniería en Informática Trabajo Final: SysCam

HU1: Logueo

Prueba de Aceptación 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. Resultados esperados:  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. Liberación del entregable del Sprint 2: Sprint 2: Requerimientos SI NO ¿Todas las historias de usuario seleccionadas fueron desarrolladas? X ¿Todas las pruebas de aceptación fueron aprobadas? X 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:

CHAÑI ALARCON, MARTIN HORACIO

41

Ingeniería en Informática Trabajo Final: SysCam

ID Descripción HU2 Gestión usuarios HU7 Definición dirección almacenamiento

Responsable Estimación MC 3 MC 3

6.6.1 - Pila del Sprint 3:

6.6.2 - Burn Down del Sprint 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.

6.6.3 - Retrospectiva Sprint 3: 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.

6.6.4 - Revisión del Sprint 3: Como podemos apreciar todas las Historias de Usuarios abordadas en este Sprint 3 también pudieron ser terminadas exitosamente en el mismo.

CHAÑI ALARCON, MARTIN HORACIO

42

Ingeniería en Informática Trabajo Final: SysCam

Historias de Usuarios completadas: HU2: Gestión usuarios

Imagen c

Imagen d

Imagen e

CHAÑI ALARCON, MARTIN HORACIO

43

Ingeniería en Informática Trabajo Final: SysCam

Imagen f Prueba de Aceptación HU2: Gestión usuarios

ID: 1 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. Resultados esperados:  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

CHAÑI ALARCON, MARTIN HORACIO

44

Ingeniería en Informática Trabajo Final: SysCam

Prueba de Aceptación ID: 2 HU7: Definición dirección almacenamiento Estado: Aceptada Descripción: a través de esta interfaz se podrá:  Visualizar el lugar donde se almacenan las grabaciones. Resultados esperados:  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). Liberación del entregable del Sprint 3: Sprint 3: Requerimientos SI NO ¿Todas las historias de usuario seleccionadas fueron desarrolladas? X ¿Todas las pruebas de aceptación fueron aprobadas? X 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: ID Descripción HU6 Reproducción de grabaciones HU8 Modificar número de envío de alerta

Responsable Estimación MC 5 MC 2

6.7.1 - Pila del Sprint 4:

CHAÑI ALARCON, MARTIN HORACIO

45

Ingeniería en Informática Trabajo Final: SysCam

6.7.2 - Burn Down del Sprint 4

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.

6.7.3 - Retrospectiva Sprint 4: 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.

6.7.4 - Revisión del Sprint 4: Como podemos apreciar todas las Historias de Usuarios abordadas en este Sprint 4 se completaron exitosamente. Historias de Usuarios completadas: HU6: Reproducción de grabaciones

Imagen i

CHAÑI ALARCON, MARTIN HORACIO

46

Ingeniería en Informática Trabajo Final: SysCam

Prueba de Aceptación ID: 1 HU6: Reproducción de grabaciones Estado: Aceptada Descripción: a través de esta interfaz se podrá:  Visualizar y seleccionar la grabación deseada. La cual es producida por la detección de movimiento si es que la hubiera. Resultados esperados:  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 Prueba de Aceptación HU8: Modificar número de envió de alerta

ID: 2 Estado: Aceptada Descripción: a través de esta interfaz se podrá:  Visualizar el número ingresado para él envío de la alerta en forma de SMS. Resultados esperados:  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). Liberación del entregable del Sprint 4: Sprint 4: Requerimientos ¿Todas las Historias de Usuario seleccionadas fueron desarrolladas? ¿Todas las pruebas de aceptación fueron aprobadas?

SI X X

NO

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.

CHAÑI ALARCON, MARTIN HORACIO

47

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

48

Ingeniería en Informática Trabajo Final: SysCam

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. Resultados esperados: No permitir el acceso al prototipo. Post Condiciones:  Negar el ingreso al sistema.  Mostrar un mensaje informando que se ingresó mal el usuario y/o contraseña (Imagen 2) Estado: Terminado – ok

CHAÑI ALARCON, MARTIN HORACIO

49

Ingeniería en Informática Trabajo Final: SysCam

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. Resultados esperados: No permitir el acceso al prototipo. Post Condiciones:  Negar el ingreso al sistema.  Mostrar iconos que indiquen que se debe ingresar usuario y contraseña para poder ingresar al prototipo (Imagen 3). Estado: Terminado – ok

Imagen 3

CHAÑI ALARCON, MARTIN HORACIO

50

Ingeniería en Informática Trabajo Final: SysCam

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). Estado: Terminado - ok

Imagen 1

CHAÑI ALARCON, MARTIN HORACIO

51

Ingeniería en Informática Trabajo Final: SysCam

ID Prueba: 2 HU: Gestión usuario Descripción: no permitir ingresar un nombre de usuario ya registrado. Datos Requeridos:  Ingreso de nombre de usuario nuevo.  Ingreso contraseña para el usuario.  Selección del nivel. 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). Estado: Terminado - ok

Imagen 2 ID Prueba: 3 HU: Gestión usuario Descripción: controlar que el correcto ingreso de la clave Datos Requeridos:  Ingreso de nombre de usuario nuevo.  Ingreso contraseña para el usuario.  Selección del nivel. 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). Estado: Terminado - ok

CHAÑI ALARCON, MARTIN HORACIO

52

Ingeniería en Informática Trabajo Final: SysCam

Imagen 3 ID Prueba: 4 HU: Gestión usuario Descripción: permitir modificar la clave y/o nivel de usuario registrados en el prototipo. Datos Requeridos:  Ingreso nueva contraseña para el usuario.  Selección del nivel. 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). Estado: Terminado - ok

Imagen 4 ID Prueba: 5 HU: Gestión usuario Descripción: permitir eliminar un usuario registrado en el prototipo. Datos Requeridos:  Selección de un usuario. Pre Condiciones: usuario registrado en el prototipo.

CHAÑI ALARCON, MARTIN HORACIO

53

Ingeniería en Informática Trabajo Final: SysCam

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). Estado: Terminado – ok

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). Estado: Terminado - ok

CHAÑI ALARCON, MARTIN HORACIO

54

Ingeniería en Informática Trabajo Final: SysCam

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: Estado: Terminado - ok

CHAÑI ALARCON, MARTIN HORACIO

55

Ingeniería en Informática Trabajo Final: SysCam

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. Estado: Terminado - ok

Imagen 11

CHAÑI ALARCON, MARTIN HORACIO

56

Ingeniería en Informática Trabajo Final: SysCam

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. Estado: Terminado - ok

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: Estado: Terminado – ok

CHAÑI ALARCON, MARTIN HORACIO

57

Ingeniería en Informática Trabajo Final: SysCam

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). Estado: Terminado – ok

Imagen 14

CHAÑI ALARCON, MARTIN HORACIO

58

Ingeniería en Informática Trabajo Final: SysCam

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). Estado: Terminado – ok

Imagen 16

CHAÑI ALARCON, MARTIN HORACIO

59

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

60

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

61

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

62

Ingeniería en Informática Trabajo Final: SysCam

ID Prueba: 2 HU: Definición dirección almacenamiento 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:  Informar si la operación tuvo éxito. 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.

CHAÑI ALARCON, MARTIN HORACIO

63

Ingeniería en Informática Trabajo Final: SysCam

Al ejecutar otra prueba, tratando de insertar nuevamente el lugar para el almacenamiento: La prueba arroja lo siguiente:

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 HU: Definición dirección almacenamiento 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:  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 ActualizarRuta

CHAÑI ALARCON, MARTIN HORACIO

64

Ingeniería en Informática Trabajo Final: SysCam

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:  Informar si la operación tuvo éxito. 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

CHAÑI ALARCON, MARTIN HORACIO

65

Ingeniería en Informática Trabajo Final: SysCam

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.

Podemos decir que a partir de esta prueba se pudo probar el correcto funcionamiento del método OperacionTelefono, los cuales arrojaron resultados correctos al actualizar el número de teléfono. ID Prueba: 5 HU: Modificar número de envió de alerta 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:

CHAÑI ALARCON, MARTIN HORACIO

66

Ingeniería en Informática Trabajo Final: SysCam

 Informar si la operación tuvo éxito. 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 arroja lo siguiente:

CHAÑI ALARCON, MARTIN HORACIO

67

Ingeniería en Informática Trabajo Final: SysCam

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:  Informar si la operación tuvo éxito. 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

CHAÑI ALARCON, MARTIN HORACIO

68

Ingeniería en Informática Trabajo Final: SysCam

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 arroja lo siguiente:

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.

CHAÑI ALARCON, MARTIN HORACIO

69

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

70

Ingeniería en Informática Trabajo Final: SysCam

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.

Podemos decir que a partir de esta prueba se pudo probar el correcto funcionamiento del método AlertaMensaje, los cuales arrojaron resultados correctos al enviar la alerta de SMS. ID Prueba: 9 HU: Gestión Usuario Descripción: permitir modificar la clave y/o nivel de los usuarios. Datos Requeridos:  ingresar nueva contraseña.  Seleccionar nivel. Pre Condiciones:  Usuario registrado en el prototipo. Resultados esperados: guardar los cambios para el usuario. Post Condiciones:  Informar si la operación tuvo éxito. Estado: Terminado.

CHAÑI ALARCON, MARTIN HORACIO

71

Ingeniería en Informática Trabajo Final: SysCam

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 HU: Gestión Usuario Descripción: permitir eliminar un usuario. Datos Requeridos:  Seleccionar un usuario. Pre Condiciones:  Usuario registrado en el prototipo. Resultados esperados: eliminación de 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_DelUsuarios de prueba.

CHAÑI ALARCON, MARTIN HORACIO

72

Ingeniería en Informática Trabajo Final: SysCam

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 HU: Gestión Usuario 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:  Informar si la operación tuvo éxito. Estado: Terminado. Para la realización de la prueba se definió el siguiente método TestMethod_Niveles de prueba.

CHAÑI ALARCON, MARTIN HORACIO

73

Ingeniería en Informática Trabajo Final: SysCam

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 HU: Modificar número de envió de alerta Descripción: controlar el correcto ingreso del número para el envió de la alerta. Datos Requeridos:  Ingreso de número para la alerta. CHAÑI ALARCON, MARTIN HORACIO

74

Ingeniería en Informática Trabajo Final: SysCam

Pre Condiciones:  Número para el envió de la alerta registrado. Resultados esperados: almacenar el número. 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_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.

CHAÑI ALARCON, MARTIN HORACIO

75

Ingeniería en Informática Trabajo Final: SysCam

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:  Usuario registrado en el prototipo. Resultados esperados: actualizar la clave. 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_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

CHAÑI ALARCON, MARTIN HORACIO

76

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

77

Ingeniería en Informática Trabajo Final: SysCam

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

CHAÑI ALARCON, MARTIN HORACIO

78

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

79

Ingeniería en Informática Trabajo Final: SysCam

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

Tiempo 1705 1870 1322 1550 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).

CHAÑI ALARCON, MARTIN HORACIO

80

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

81

Ingeniería en Informática Trabajo Final: SysCam

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.

CHAÑI ALARCON, MARTIN HORACIO

82

Ingeniería en Informática Trabajo Final: SysCam

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-restque-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-paracctv/ Framework, A. (2013). AForge.Vision.Motion Namespace. Obtenido de http://www.aforgenet.com/aforge/framework/docs/html/40a6b51f-9f55-0569-ce0b3c1efeeec056.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.

CHAÑI ALARCON, MARTIN HORACIO

83

Ingeniería en Informática Trabajo Final: SysCam

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/scrumy-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-portema/todas-las-secciones/todos-los-temas/todos-los-articulos/conceptos-basicosdirectshow Loyo, A. (s.f.). Visión Computacional. Obtenido de https://sg.com.mx/revista/55/visi-ncomputacional 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/eses/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-paraqu%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.

CHAÑI ALARCON, MARTIN HORACIO

84

Ingeniería en Informática Trabajo Final: SysCam

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://tecnologiainformatica.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-NETObjeto-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

CHAÑI ALARCON, MARTIN HORACIO

85

Ingeniería en Informática Trabajo Final: SysCam

Anexo Diseño de la Base de datos

Esquema de datos Tabla USUARIOS USUARIOS Nombre del Campo Tipo USERNAME Texto Corto USERPASS Texto Corto ID_NIVEL Número Indices USERNAME ID_NIVEL

Descripción Nombre de usuario unico distinto de vacío para acceder al prototipo Clave correspondiente al usuario distinto de vacío Nivel para el usuario, indica los permisos que tendra. Distinto de vacío

Primary Key Foreign Key de la Tabla Nivel

Tabla NIVEL NIVEL Nombre del Campo Tipo ID_NIVEL Numero TIPO Texto largo Indices ID_NIVEL

Descripción Clave unico para el nivel distinto de vacío Descripción del nivel

Primary Key

Tabla RUTA

RUTA Nombre del Campo Tipo Descripción 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

CHAÑI ALARCON, MARTIN HORACIO

86

Ingeniería en Informática Trabajo Final: SysCam

Tabla ALERTA

ALERTA Nombre del Campo Tipo ID Número TELEFONO Número Indices ID_RUTA

Descripción Clave unica de la alerta distinto de vacío Número de celular para mandar la alerta

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.

CHAÑI ALARCON, MARTIN HORACIO

87