Sistema SIPEC Fecha: 29 de julio de 2014 Alumnos: Cristian Armijo Cristian Almonacid KICK OFF.

Presentación del tema: "Sistema SIPEC Fecha: 29 de julio de 2014 Alumnos: Cristian Armijo Cristian Almonacid KICK OFF."— Transcripción de la presentación:

1 Sistema SIPEC Fecha: 29 de julio de 2014 Alumnos: Cristian Armijo Cristian Almonacid KICK OFF

2 Se realizara una reunión de presentación y acuerdos, que permitirá a los involucrados conocer sobre el plan de ejecución inicial y se podrá dar una introducción breve sobre el modelo a implementar. Además se realizara la definición de roles y responsabilidades del grupo de trabajo.

3 KICK OFF Equipo de Trabajo Se definirán los equipos de trabajo y quienes participaran de las reuniones de levantamiento de prototipo. NombreRolNombre invitado (SAG) Rol Invitado (SAG) Cristian ArmijoLíder Proyecto, Analista, Desarrollador Jorge Tapia Líder Proyecto Cristian AlmonacidAnalista, Desarrollador VeterinariosUsuarios Claves Juan MesaWeb Master Equipo desarrolloDesarrolladores

4 Kick off Objetivo general Brindar información suficiente y oportuna que permitan el apoyo a las decisiones relacionadas a la prevención de contagios de enfermedades entre animales. Objetivos específicos OE-01Presentar información al SAG sobre la trazabilidad de DIIO en su etapa de distribución y venta a fin de promover una fabricación de calidad, reduciendo así la posibilidad de que animales pierdan su trazabilidad a causa del deterioro del dispositivo. OE-02Unificar el procedimiento que captura masivamente datos de los FMA, considerando la existencia de establecimientos pecuarios que, por distancia y aislamiento geográfico, carecen del recurso internet. Alcance del Proyecto

5 OE-03Presentar información al SAG respecto a dónde han estado y se encuentran actualmente los animales registrados en la plataforma SIPEC. OE-04Presentar información al SAG que permita visualizar los animales enfermos presentes en un determinado establecimiento pecuario, junto con la traza de localizaciones en donde ha estado cada uno de ellos. OE-05Notificar a tiempo, con fines preventivos, a los establecimientos pecuarios o recintos feriales que hayan acogido animales a los que se les hayan detectado alguna enfermedad de carácter contagioso.

6 Kick off Solución propuesta SP-01Desarrollo de un proyecto de aplicación web, paralelo a la aplicación informática SIPEC, el cual será conectado a ésta mediante el uso compartido de sesión. SP-02Definir los procedimientos de carga de datos de los FMA al sistema para que todos los establecimientos pecuarios y recintos feriales trabajen del mismo modo. SP-03Dentro de la aplicación, se propone la construcción de dos módulos, los cuales tendrán como finalidad el cumplimiento de los objetivos específicos

7 Kick off Requisitos Por medio de la definición de los objetivos específicos y gracias a la solución propuesta, los miembros de la División Pecuaria, nuestros clientes, han logrado visualizar en mayor detalle lo que desean para el presente proyecto, plasmando aquello en requisitos de sistema de alto nivel. A continuación se presentan los requisitos de sistema de alto nivel, tanto funcionales como no funcionales.

8 Requerimientos funcionales idDescripción RF-1 Se requiere que los usuarios autorizados del SAG puedan administrar las cadenas de distribución de los proveedores y distribuidores inscritos en el sistema. (OE-01) RF-2Se requiere que los usuarios autorizados del SAG puedan realizar consultas que permitan ver los DIIO autorizados a fabricar por un Proveedor, los DIIO que han sido dados de baja, y la traza histórica de distribución de éstos. (OE-01) RF-3 Se requiere que los usuarios proveedores y distribuidores puedan administrar sus propias distribuciones de DIIO. (OE-01) RF-4Se requiere que los usuarios proveedores y distribuidores puedan administrar sus propias ventas de DIIO. (OE-01) RF-5Se requiere que el sistema permita, para usuarios de establecimientos pecuarios, recintos feriales y funcionarios SAG autorizados, la carga de una planilla excel, la cual contenga todos los datos del FMA para todos los movimientos masivos de animales que haya realizado un establecimiento o recinto ferial. (OE-02) RF-6Se requiere que los usuarios, que suben la planilla al sistema, puedan editar su contenido dentro de la aplicación en caso de que su carga presente errores. (OE-02) RF-7Se requiere que funcionarios autorizados del SAG puedan realizar búsquedas de animales, las cuales indiquen en qué recinto se encuentra el animal y presenten traza de los establecimientos por los que han estado. (OE-03)

9 Kick off idDescripción RF-8 Se requiere que funcionarios autorizados del SAG puedan visualizar, mediante un mapa, los focos de enfermedad animal que sean informados en los diversos establecimientos pecuarios o recintos feriales autorizados del país. (OE-04) RF-9 Se requiere que funcionarios autorizados del SAG puedan visualizar, mediante un mapa, los lugares con posible riesgo de padecer la misma enfermedad del foco seleccionado, en base a la traza de movimiento animal que los animales enfermos relacionados al foco posean dentro de los últimos 30 días. (OE-05) RF10Se requiere que el sistema de aviso oportuno, mediante correo electrónico, a los establecimientos pecuarios o recintos feriales en caso de que estos presenten focos de riesgo de poseer alguna enfermedad de carácter contagioso en sus animales

10 Requerimiento no funcionales IDDescripción RNF 01 [Desempeño] Garantizar la confiabilidad, la seguridad y el desempeño del sistema informático a los diferentes usuarios a nivel nacional. RNF 02 [Desempeño] El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios, con tiempo de respuesta uniforme, permitiendo la navegación en la aplicación sin contratiempos. RNF 03 [Disponibilidad] El sistema deberá estar disponible mediante Internet, en un 100% o muy cercano a éste, durante todo horario. RNF 04 [Escalabilidad] El sistema, tras su desarrollo, debe estar en capacidad de permitir la incorporación de nuevas funcionalidades, modificaciones y eliminaciones de éstas. RNF 05 [Facilidad de Uso] El sistema debe ser de fácil uso y adaptación por parte de los usuarios que lo utilizarán. RNF 06 [Facilidad de Uso] El sistema debe presentar mensajes de error que permitan al usuario identificar el tipo de error y su causa para que así pueda dar solución a éste. RNF 07 [Diseño] El sistema no debe permitir el cierre de una operación hasta que todos sus procesos, subprocesos y tareas relacionadas hayan terminado satisfactoriamente.

11 Organización y planeación Se dispondrá de tres ambientes: 1.Ambiente de desarrollo: encargado de publicar a nivel interno del equipo de trabajo el aplicativo, con fines de revisión interna y diseño. 2.Ambiente de control de calidad: encargado de publicar el aplicativo en un entorno ajeno al equipo de trabajo, revisado por terceros para certificar su buen funcionamiento. 3.Ambiente de producción: ambiente final, utilizado por el cliente.

12 Se considera además el uso de un servidor de repositorio, encargado de alojar el código, permitiendo acceso múltiple y edición compartida a los programadores autorizados. Los requerimientos para los ambientes de desarrollo, control de calidad y producción deben ser exactamente los mismos. Estos pueden residir en un mismo servidor o en servidores distintos. Por fines prácticos para el presente proyecto de tesis, el ambiente de desarrollo y de control de calidad compartirán el mismo servidor. Los requerimientos para los ambientes serán establecidas bajo documentación. El servidor de repositorio debe ser independiente a los demás ambientes. El servidor que aloja el ambiente de producción debe ser independiente a los demás servidores. Los desarrolladores deben realizar su trabajo exclusivamente en el ambiente de desarrollo y en repositorio.

13 Mantenimiento Los procedimientos de actualización, instalación, configuraciones necesarias y acciones para restablecer el servicio tras una detención serán documentados. En medida de lo posible, las detenciones de servicio deben: Ser planificadas en el mediano plazo. Ser comunicadas a tiempo al equipo de desarrollo para considerarlas en su planificación. Ejecutarse fuera del horario de trabajo, para no interrumpir las operaciones diarias. Ser comunicadas al momento de inicio y finalización de la detención. Características Herramientas de desarrollo: Para realizar el desarrollo del proyecto, nuestro equipo de proyecto deberá contar en sus computadores con los siguientes softwares instalados: Windows 7 Professional Visual Studio 2013 Pro Oracle SQL Developer 4.0 Oracle Database 11g Release 2 Oracle Data Access Components (ODAC) Microsoft Office Professional Plus 2010 Bizagi Process Modeler 2.7 Administrador de Internet Information Services 7.5 Tortoise SVN. Herramientas de control de versiones: Dentro del servidor de repositorio se instalará la aplicación Subversion, herramienta de control de versiones de código abierto, basada en un repositorio, semejante a un sistema de ficheros. Los programadores podrán acceder al repositorio mediante la aplicación Tortoise SVN.

14 MITIGACIÓN DE RIESGOS En base a los puntos expuestos en los puntos anteriormente, se definirán los siguientes riesgos los cuales deben ser evaluados para definir en la reunión de kick –off las posibles alternativas para mitigar riegos. Al revisar los alcances del proyecto se encontraron los siguientes posibles riesgos  Pérdida de personal clave : Se debe documentar cada uno de los pasos realizados por los analistas, programados o lideres del proyecto.  Lentitud en una toma de decisiones : Por cada modulo o departamento se debe definir un experto en negocio para así no perder tiempo en espera de las tomas de decisiones por parte del negocio.  Cambios en las prioridades : Se definirán las prioridades para cada implementación en conjunto con el negocio, en caso de haber cambios se realizaran evaluaciones de este e impacto sobre el trabajo ya realizado.  Trabajos no programados: Se deberá evaluar el impacto de implementación en conjunto con el clientes.