Sistema de Información Pecuaria SIPEC. Resumen e Introducción Sobre la Institución El Servicio...

Sistema de Información PecuariaSIPEC

Resumen e Introducción

Sobre la Institución

El Servicio Agrícola y Ganadero (SAG) corresponde a un organismo oficial del Estado de Chile, encargado de apoyar el desarrollo de la agricultura, los bosques y la ganadería, a través de la protección y mejoramiento de la salud de los animales y vegetales.

Resumen e Introducción

Descripción del Negocio

Procedimientos:• de identificación animal• de traslado animal• de registro de datos de formularios de movimiento animal (FMA)• de registro de ventas y distribuciones de DIIO.

Definición del Problema

Enfoque del Proyecto

Nuestro proyecto se enfocará en dar una solución informática que facilite el cumplimiento de la certificación sanitaria de animales con fines ganaderos y preste apoyo en la prevención de posibles brotes de enfermedades en éstos.

Objetivo General

• Brindar información que permita el apoyo a las decisiones relacionadas a la prevención de contagios de enfermedades entre animales, la cual no debe tardar más de un día tras la carga total de la traza animal.


Objetivos Específicos

• OE-01 Presentar 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-02 Unificar 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.

• OE-03 Presentar información al SAG respecto a dónde han estado y se encuentran actualmente los animales registrados en la plataforma SIPEC.


Objetivos Específicos

• OE-04 Presentar 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-05 Notificar 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.

Solución T.I. Propuesta

• SP-01 Desarrollo de un proyecto de aplicación web, paralelo a la aplicación informática SIPEC, el cual será conectado a ésta mediante uso compartido de sesión.

• SP-02 Definir 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-03 Dentro 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 planteados: un módulo de comercialización DIIO y un módulo de ferias.

Solución T.I. Alternativa

Workflow

Inconvenientes:• Costos elevados en comparación a nuestra propuesta.• Requiere empresa externa especializada en el tema wokflow.• Requiere realizar concurso de licitación, lo cual incrementa los tiempos.• Los workflow son poco personalizables en su aspecto gráfico y usabilidad.• Trabaja en base a procesos y los procesos actuales no son unificados.

Alcances

• Supuestos de alcance– Integración– Entrega de información y archivos necesarios– Implementación– Migración SIPEC dentro de los plazos– Registro de información acorde a la Ley.

• Limitaciones: – Herramienta solo de apoyo.– Seguridad. Acceso con privilegios.– Usabilidad en navegadores de internet.

• Restricciones– No se consideran cambios – Confidencialidad

Estudio de Factibilidad

• Factibilidad OperativaDentro de ésta categoría, medimos la urgencia del problema, las actividades necesarias para lograr el objetivo y la aceptabilidad de la solución.

• Factibilidad TécnicaEn ésta categoría evaluamos la disponibilidad de la tecnología y medios necesarios para realizar el proyecto, así como el conocimiento de los recursos humanos necesarios para llevarlo a cabo.


• Factibilidad EconómicaEn esta categoría evaluamos la disponibilidad de los medios económicos necesarios para solventar el proyecto.

Para efectos económicos, el SAG proporciona anualmente un presupuesto al Departamento Informático el cual deberá encargarse de repartir entre los proyectos contemplados para el presente año.


• Factibilidad Económica

Tabla de gastos y resumen de presupuesto

Resumen de gastos del proyecto CantidadValor

Unitario TotalCosto total estimado del equipamiento $ 2.000.000 Equipo de trabajo i5 64bits 4 $ 500.000 $ 2.000.000Costo total mensual de recursos humanos 5 $ 5.600.000 $ 28.000.000 Jefe de Proyecto 1 $ 2.000.000 $ 2.000.000 Arquitecto de software – Analista 1 $ 1.600.000 $ 1.600.000 Desarrollador 2 $ 1.000.000 $ 2.000.000Costo total del proyecto $ 30.000.000

Resumen de presupuesto TotalPresupuesto Vigente año 2014 $ 348.084.552Presupuesto Comprometido a la fecha $ 289.161.800Costo total del proyecto $ 30.000.000Saldo disponible tras inicio del proyecto $ 28.922.752

Requisitos Requisitos Funcionales de Alto Nivel

ID Descripción

RF-01

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-02 Se 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-03 Se requiere que los usuarios proveedores y distribuidores puedan administrar sus propias distribuciones de DIIO. (OE-01)

RF-04 Se requiere que los usuarios proveedores y distribuidores puedan administrar sus propias ventas de DIIO. (OE-01)

RF-05 Se 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)

Requisitos Requisitos Funcionales de Alto Nivel

ID DescripciónRF-06 Se 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-07 Se 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)

RF-08 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-09 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)

RF-10 Se 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.

Requisitos Requisitos no Funcionales

ID DescripciónRNF-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.


ID Descripció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.

RNF-08 [Diseño] El ingreso de información al sistema debe diseñarse con transacciones que permitan el ingreso de los datos de forma parcial, a fin de conservar la estabilidad de la red durante procesos de carga masiva.

RNF-09 [Diseño] El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el proceso de validación de la información se deben de tener en cuenta aspectos tales como la obligatoriedad de campos, longitud de caracteres permitida por campo, tipo de dato ingresado y reglas de negocio.

RNF-10 [Instalación] El sistema debe ser de fácil instalación en las plataformas de hardware y software definidos en el presente documento.


ID DescripciónRNF-11 [Mantenibilidad] Todo el sistema deberá estar completamente documentado, en todas sus etapas de

proyecto.

RNF-12 [Seguridad] La seguridad del sistema debe estar regida por las políticas de seguridad informática presentes en el SAG.

RNF-13 [Seguridad] El acceso al sistema debe estar restringido por el uso de claves asociadas a cada usuario. Sólo podrán acceder al sistema las personas que se encuentren registradas, las cuales serán clasificadas mediante roles, con acceso a las opciones de trabajo definidas para cada rol.

RNF-14 [Seguridad] El sistema debe estar en capacidad de rechazar accesos o intentos de modificaciones no autorizadas a la información y de proveer los servicios requeridos a los usuarios legítimos del sistema.

Plan de Gestión del Proyecto

Para abordar la solución propuesta y presentar las actividades necesarias para su desarrollo, consideramos la gestión de un plan de proyecto, el cual incluye: • Plan de Gestión de Análisis• Plan de Gestión de Actividades• Plan de Gestión de Configuración• Plan de Gestión de Riesgos• Plan de Desarrollo• Plan de Pruebas

– Pruebas de aceptación: casos de prueba.– Pruebas de análisis de código: métricas de código (índice de mantenimiento, complejidad

ciclomática, profundidad de herencia, acoplamiento de clases, líneas de código).– Pruebas de sistema: funcionales y de rendimiento.

Plan de Gestión de Análisis

La etapa de análisis es la etapa más importante del proyecto. En ella obtenemos información sobre la problemática del cliente y el qué desea solucionar.

Definimos un plan de gestión de análisis para formalizar:• Registro de Stakeholders.• Rol de Stakeholders en el proyecto.• Clasificación de Stakeholders según influencia y poder sobre el proyecto.• Estrategia de Gestión de Stakeholders.• Medios de comunicación.• Requerimientos y/o acuerdos.• Refinamiento de requisitos.

Volver

Plan de Gestión de Análisis

Refinamiento de Requisitos

Es frecuente que un cliente defina un conjunto de objetivos generales para el software, pero que no identifique fácilmente los requerimientos detallados para las funciones y características. Debido a ello, es recomendable hacer uso de herramientas gráficas de apoyo para lograr un buen refinamiento de requisitos.

Consideramos entonces el uso de dos herramientas gráficas: un prototipo para mostrar al cliente el cómo se verán sus requerimientos plasmados en una aplicación, diagramas BPMN para que el cliente defina el funcionamiento de los procesos de negocio involucrados y finalmente un documento de especificación de requerimientos para formalizar lo solicitado, creando así un ciclo de retroalimentación entre nuestro equipo de trabajo y el cliente.

Documentos de apoyo para el refinamiento:PrototipoBPMN Proceso de Comercialización de DIIOBPMN Proceso de Ferias (entrada de animales)BPMN Proceso de Ferias (salida de animales) Especificación de Requerimientos [Módulo de Comercialización]

Volver

Plan de Gestión del Tiempo

Carta Gantt

Volver

Plan de Gestión de Configuració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.

Mantenimiento

El mantenimiento de los servidores, tanto del repositorio como de los ambientes, no se considera como parte del presente proyecto, debiendo ser responsable de éstos la Universidad y el SAG.

Volver

Plan de Gestión de Riesgos

Para lograr mitigar, en lo posible, los riesgos asociados al proyecto, ya sean globales o relacionados a requisitos no funcionales, definimos para cada uno un plan de mitigación, a fin de lograr un control sobre sus posibles amenazas que afecten el desarrollo e implementación del proyecto:

Matriz de Riesgos Globales del ProyectoMatriz de Riesgos Específicos de los Requisitos no Funcionales

Volver


Volver


Una vez detectados los riesgos, podemos notar la existencia de riesgos de desarrollo, los cuales principalmente son por causa de la poca experticia en la materia.

Podemos entonces, considerar como principal riesgo de desarrollo:

- Uso compartido de sesión entre SIPEC y nuestro proyecto (SIPEC2)

Tal como se expone en la matriz de riesgos de requerimientos no funcionales y otros requerimientos, el uso compartido de sesión estará ligado al cumplimiento de una actividad SAG. En caso de no cumplir con ella,

SIPEC2 no compartirá sesión y, por ende, dejará de existir el presente riesgo.

Volver


Plan de diseño de Prototipo, Objetivos:

Mitigar riesgos de diseño. Consideramos realizar un prototipo el cual tiene como propósito principal confirmar que es posible conectar dos aplicaciones .NET C# en framework 4.0 bajo una misma sesión de usuario.

Proporcionar información visual, necesaria para validar junto con el cliente los requerimientos funcionales del proyecto.

Volver


Plan de Gestión de Cambios

Otro tipo de riesgos detectados es la existencia de la posibilidad de cambios en los requisitos, en los que el cliente haya omitido cierta información o que, por razones de fuerza mayor, se deban modificar.

Consideramos dentro del plan de mitigación y control de éste riesgo la elaboración de una planilla de historial de cambios, en la cual se detallará el caso, indicando su prioridad e impacto, proveyendo así un registro de decisiones de cambios, de su evaluación e impacto, asegurando que éstos sean conocidos por los stakeholders.

Planilla de Registro de Cambios de RequerimientosProcedimiento de Control de Cambios de Requerimientos

Para estos casos se recomienda negociar con el cliente, obteniendo algo a cambio, por ejemplo, tiempo extra para una entrega o contratos de mantenimiento de software para desarrollar lo que pide dentro de dicha

instancia.

Volver


Historial de Cambios

Numero: Nombre:

Usuario:

Modificación de requerimiento numero: iteración asignada:

Prioridad en negocio: (alto/medio/bajo)

Puntos estimados:

Riesgo desarrollo: (alto/medio/bajo)

Puntos reales:

Descripción:

Observaciones:

Plan de Gestión de Cambios

Volver

Plan de Gestión de RiesgosPlan de Gestión de CambiosProcedimiento de Control de Cambios de Requerimientos:

Volver

Plan de Desarrollo

Modelo de Desarrollo

Para optimizar el desarrollo del proyecto dentro de su ciclo de vida, debemos basar su desarrollo en alguna metodología, la cual nos guiará durante todo el proceso. No obstante, para ello, debemos antes comprender el entorno por el cual el proyecto se verá afecto.

• Disponibilidad del cliente y stakeholders.• Estabilidad de requerimientos.• Periodicidad de entrega.• Composición del equipo de desarrollo.• Riesgos del proyecto.

Solución: Metodología Iterativa e Incremental

Plan de Desarrollo

Diseño de Alto Nivel

Vista 4 + 1 de kruchten:

Vista 4 + 1 Diagrama UMLVista Lógica Diagrama de ClasesVista Física Diagrama de Despliegue

Vista de Procesos Diagramas de ActividadVista de Desarrollo Diagrama de ComponentesVista de Escenarios Diagrama de Casos de Uso

Plan de Desarrollo

Definición de Ambientes

Se dispondrá de tres ambientes:

• Ambiente de Desarrollo: Encargado de publicar a nivel interno del equipo de trabajo el aplicativo, con fines de revisión interna y diseño.

• Ambiente de Control de Calidad (QA): Encargado de publicar el aplicativo en un entorno ajeno al equipo de trabajo, revisado por terceros para certificar su buen funcionamiento.

• Ambiente de Producción: Ambiente final, utilizado por el cliente.

Volver

Plan de Desarrollo

Definición del Patrón de Arquitectura

Para efectos del desarrollo del proyecto, el cual será desarrollado en lenguaje C#, tras evaluar los pros y contras de los patrones arquitectónicos soportados, consideramos la utilización de un patrón arquitectónico de n-capas.

Motivos de la elección del patrón arquitectónico de n-capas:• Utilizado en la Institución.• Entrega mayor orden y control en aplicaciones grandes respecto a MVC.• No requiere de capacitación para desarrolladores de la Institución.

Volver

Plan de Pruebas

El Propósito del plan de pruebas es generar una línea base de buen funcionamiento de la aplicación. Para ello consideraremos: pruebas de aceptación, de análisis de código y de sistema.

Pruebas de aceptación

Serán realizadas por el equipo de QA de la Institución. Nosotros les proveeremos a ellos un documento de casos de prueba, el cual contendrá diversas pruebas a funcionalidades del sistema, sobre una variedad de escenarios.• Ejemplo de caso de prueba: CP-VisualizarVentas.

Volver

Plan de Pruebas

Pruebas de análisis de código

Para nuestras pruebas de análisis de código, consideraremos el uso de las siguientes métricas de código:

• Índice de mantenimiento: calcula un valor de índice entre 0 y 100 que representa la facilidad relativa de mantenimiento del código. Un valor alto significa mayor facilidad de mantenimiento.

• Complejidad ciclomática: mide la complejidad estructural del código. Se crea calculando la cantidad rutas de flujo de acceso al código del programa. Recomendado que el valor no exceda de 25.

Volver

Plan de Pruebas


• Profundidad de herencia: Indica el número de definiciones de clase que se extienden desde la clase a la raíz del proyecto.

• Acoplamiento de clases: mide el acoplamiento a las clases únicas. El buen diseño de software sugiere que los tipos y métodos deben tener alta cohesión y bajo acoplamiento. Un alto acoplamiento indica un diseño difícil de reutilizar y mantener debido a sus interdependencias en otros tipos.

• Líneas de código: Indica el número aproximado de líneas de código. El recuento se basa en el código IL (Intermediate Language), por consiguiente, no representa el número exacto de líneas en el archivo de código fuente.

Volver

Plan de Pruebas


Para obtener y calcular dichos indicadores utilizaremos las herramientas que Visual Studio 2013 nos provee.

Ver Métricas de Código del avance del proyecto

Pruebas de sistema

La administración del sistema, según alcances, no es responsabilidad del presente proyecto, por tanto, éstas pruebas son de exclusiva responsabilidad del SAG.

Volver

Sistema de Información Pecuaria SIPEC. Resumen e Introducción Sobre la Institución El Servicio...

Documents

Transcript of Sistema de Información Pecuaria SIPEC. Resumen e Introducción Sobre la Institución El Servicio...