DISEÑO y DESARROLLO MODULO DE CONVENIOS DIRECCION GENERAL DE PLANIFICACION MINISTERIO DE MEDIO AMBIENTE Y AGUA

Transcripción

1 Programa de Apoyo a la Conservación Sostenible de la Biodiversidad - PACSBio DISEÑO y DESARROLLO MODULO DE CONVENIOS DIRECCION GENERAL DE PLANIFICACION MINISTERIO DE MEDIO AMBIENTE Y AGUA La Paz, enero 2014 Bolivia Este proyecto está financiado por la Unión Europea Este proyecto está ejecutado por el Consorcio EPTISA AGRECO

2 Agosto 2009 Agosto 2009 Expertos: Gonzalo Murillo Las opiniones expresadas en este documento son responsabilidad de los consultores y en ningún momento expresan la opinión de la Unión Europea o de la contraparte del Gobierno de Bolivia

3 DISEÑO y DESARROLLO MODULO DE CONVENIOS "INFORME FINAL" DIRECCION GENERAL DE PLANIFICACION MINISTERIO DE MEDIO AMBIENTE Y AGUA ENERO 2014 LA PAZ - BOLIVIA version 1.0 1

4 Contenido DISEÑO Y DESARROLLO DEL MODULO DE CONVENIOS... 3 DIRECCION GENERAL DE PLANIFICACION... 3 MINISTERIO DE MEDIO AMBIENTE Y AGUA... 3 INTRODUCCION... 3 PROBLEMA IDENTIFICADO... 3 VISION DEL SISTEMA... 3 ALCANCE DEL SISTEMA... 3 CICLO DE VIDA DE UN CONVENIO... 4 Inicio... 4 Negociación... 4 Efectivización... 6 Ejecución... 6 Cierre... 7 INGENIERIA DE REQUERIMIENTOS (IR)... 8 Perfiles del Sistema: Módulos y Funciones del Sistema REQUISITOS FUNCIONALES.- Definen Qué hace el sistema (funciones del sistema) REQUISITOS NO FUNCIONALES.- definen los atributos que indican al sistema como realizar su trabajo (eficiencia, hardware, software, interface, usabilidad, etc.) DISEÑO DE SOFTWARE Diagrama de Contexto General (por perfiles) Diagrama de Contexto Detallado Diagrama de Actividades Diagrama de Casos de Uso Diagrama de Clases Arquitectura del software (Modelo Vista Controlador - MVC) Desarrollo ScriptCase Manuales y Documentación Entregada Conclusiones

5 DISEÑO Y DESARROLLO DEL MODULO DE CONVENIOS DIRECCION GENERAL DE PLANIFICACION MINISTERIO DE MEDIO AMBIENTE Y AGUA INTRODUCCION El presente documento muestra el diseño y desarrollo del Modulo de Convenios del Ministerio de Medio Ambiente y Agua considerando las necesidades actuales de manejo de información y con el objetivo de proporcionar una herramienta de gestión capaz de brindar información exacta, oportuna y confiable de los Convenios a lo largo de su ciclo de vida en la Institución. PROBLEMA IDENTIFICADO "Limitado tratamiento de información de Convenios en el Ministerio de Medio Ambiente y Agua" VISION DEL SISTEMA El Modulo de Convenios permite gestionar oportuna y correctamente todos los Convenios que el Ministerio de Medio Ambiente y Agua administra para la ejecución de sus Programas y Proyectos. Este Modulo permite conocer los avances físicos y financieros a nivel de Convenios, contar con la información oportuna e inmediata de los montos (saldos) disponibles de tal manera de poder disponer de estos recursos. Además, permite determinar la ubicación física y el responsable de un determinado convenio. ALCANCE DEL SISTEMA Los Convenios gestionados por este sistema abarcan los Viceministerios de Agua Potable y Alcantarillado Básico, Riego y Medio Ambiente desde la etapa de negociación, registro de convenios marco, convenios subsidiarios, convenios interinstitucionales (CIF), cartas acuerdo, custodia, monitoreo (Plan de Monitoreo de Convenios), seguimiento hasta su cierre y archivo (Todo el ciclo del Convenio). 3

6 CICLO DE VIDA DE UN CONVENIO Según el VIPFE tenemos: En el MMAyA, el Proceso de Negociación va por dos rutas claramente identificadas; la primera es el Organismo Financiador (Cooperación) y la segunda son las instancias nacionales(vipfe, Ministerios) y subnacionales (Municipios, Gobernaciones) que paralelamente a las negociaciones con Cooperantes y Agencias, debe ir asumiendo responsabilidades que en un determinado momento van a ser requisitos de la rúbrica de los Convenios que el MMAyA establece para la ejecución de Programas y Proyectos. El ciclo de vida de un Convenio en el MMAyA es el siguiente: Inicio Generación de la demanda Proyectos Identificación de Financiadores acorde a los ámbitos de los proyectos Selección de Cartera Negociación La negociación puede dar o no origen a un Convenio. Es muy dinámica. Existen muchos borradores (solo documentos informales). Actas, el hito final es el convenio, antes de esta etapa solo hay borradores. Resulta importante contar con estos archivos que son MUY útiles posteriormente Depende mucho de cada financiador. Kfw trabaja con ayudas memorias que se suscriben de las misiones que evalúan después de negociación intergubernamental donde aprueban asignaciones. Con el Banco Mundial (BM) también se manejan misiones y un documento de ayuda memoria que 4

7 da la línea al Programa o Proyecto en gestación. "ESOS DOCUMENTOS SE DEBERIAN ALMACENAR". El coordinador de una UCP no tiene posibilidad de negociar, solo la parte técnica previa delegación de Viceministros o Ministro (que cuentan con estos atributos por normativa vigente). Se negocia con financiador y con instancias nacionales (VIPFE) y Subnacionales (Municipios) Hay reuniones con todas las partes y con cada una de ellas de manera independiente. Se usan los reglamentos de convenios del VIPFE para la parte nacional (cumplir la norma nacional). Si ya se tienen asignados los recursos (primera etapa negociación), se procede a la elaboración del programa o proyecto para la presentación al VIPFE y su evaluación. Es paralela la negociación con los cooperantes y el VIPFE. Un documento que demuestra lo que se va a hacer. Existen Programas cerrados, Programas con carteras abiertas y/o proyectos. Si es proyecto ya debería haber estudio o pre inversión si es el caso. La negociación concluye con la suscripción de un contrato o convenio La presentación al VIPFE se hizo subsanando observaciones hasta lograr la versión final En el VMA no tienen Programas de Inversión, no son de gasto corriente programas como el PNCC porque no hay obras civiles, el producto son solo documentos. Los convenios Marco los ve la DGP Los convenios interinstitucionales (CIF) los ven los viceministerios Es necesario monitorear Programas. Monitoreo de Convenios está orientado más al cumplimiento de clausulas contractuales. Las Unidades Coordinadoras de Programas (UCPs) se pierden en los proyectos (porque esa es su misión) pero pierden la perspectiva de control del Programa. Relacionar POA -> PEI -> Programas Sectoriales (Ojo: el sistema POA hace esto) Ya se conceptualizaron las variables y sus indicadores de todo el MMAyA. Estas variables serán controladas desde el módulo de Cuadro de Mando del Sistema SIAM. Parte de Cumplimiento de un Convenio son los informes ejecución proyectos, logro de resultados, cumplimiento de objetivos. En negociación dependiendo del Cooperante resulta necesario ir guardando las actas, porque son claves, se vuelve siempre al primer documento aprobado. El documento del programa, del proyecto, una vez suscrito se elaboran documentos operativos o reglamentos. Por lo que los primeros acuerdos son CLAVES (documentos iniciales). Especialmente aquellos documentos suscritos. También es necesario ir negociando con los niveles subnacionales (municipios), otras instancias subnacionales. Al menos acuerdos y ayudas memorias, tratando de firmar algunos compromisos para que se tenga alguna formalidad (todo esto es previo a la suscripción del Convenio). Si es crédito suscrito se valida con la Asamblea Plurinacional. Se debería tener un resumen de todo lo que se hizo hasta ahí. Se defiende el crédito ante la asamblea y es necesario un resumen ejecutivo que explique lo que se quiere. 5

8 Estos documentos de negociación deben ir junto a los archivos del Convenio (cuando este se haga realidad) La negociación puede partir de arriba o abajo (de TESA a buscar financiamiento o tener financiamiento y luego buscar proyectos). El ciclo del VIPFE es tener proyecto y recién buscar financiamiento. El MMAyA negocia primero el financiamiento y luego busca proyectos Efectivización - Para que se efectivice, hay q preparar reglamento operativo, manuales o otros documentos solicitados por el financiador. Los reglamentos operativos deben ser elaborados. Hay cooperantes que contratan sus especialistas para la elaboración de estos reglamentos operativos. En el Reglamento Operativo, Convenio y Negociación se define la Norma con la que se va a ejecutar el Programa (Ej.- Norma Nacional, Norma BID, etc) Acá los financiadores establecen ciertas condiciones de pago que a veces pueden llegar a ser perjudiciales o peligrosas (hay que tener mucho cuidado). Deben existir alertas de las clausulas que tengan estas características. Cuando se tienen todos los documentos y se tiene el primer desembolso concluye la etapa de Efectivización. Se inscribe el presupuesto (con Convenio suscrito)hitos: Convenio de financiamiento(primer hito), CIF. El financiador solicita esto previo a primer desembolso. El hito de inicio de ejecución es la inscripción de presupuesto. Hasta acá se debió hacer la apertura de cuentas, resoluciones administrativas, UCP conformada, etc. Ejecución - Si se trata de programas de inversión es muy importante capturar observaciones de auditorías y como fueron solucionadas (normalmente el financiador define el alcance ej.- auditoría financiera o en algunos casos auditorías de contratación) - Hay observaciones de auditorías, pero no se hace seguimiento a estas observaciones. Normalmente porque los coordinadores son muy técnicos y dejan este trabajo a los Administrativos (justamente las observaciones van relacionadas a este ámbito de todo Programa). - Las misiones de evaluación también emiten recomendaciones que deben ser resueltas. A veces dan origen a las enmiendas. - En las adendas hay de todo, ampliaciones de plazo, asignaciones (como premios del financiador que dan origen a nuevos convenios). Las cartas acuerdo se hacen para simplificar estos cambios. Existen además castigos en desembolsos cuando hay incumplimientos. 6

9 - Es necesario ir registrando los montos desembolsados por el financiador y cuando/cuanto están siendo ejecutados estos recursos. Existen programaciones anuales de desembolsos controladas también por los cooperantes. Cierre Existe el Cierre Financiero y Técnico No deben existir pendientes considerando el Convenio Se tienen que haber subsanado las observaciones de auditoria. Si no se concluyó un proyecto, se debe tener un informe que indique que no hay pendientes con Empresas, con la Cooperación, Entes Ejecutores. Justificar (pudo haber demandas), fuerza mayor. Para concluir, la libreta Bancaria se debe cerrar con la Cuenta La siguiente gráfica muestra este ciclo. 7

10 INGENIERIA DE REQUERIMIENTOS (IR) El Objetivo de aplicar Ingeniería de Requerimientos es el de hacer uso de "buenas prácticas" en la definición del Problema y responder correctamente a la pregunta: Qué se debe construir?, siendo para ello imprescindible un estrecho trabajo entre los usuarios que conocen las necesidades existentes y tienen una visión de lo que se podría construir para obtener una solución informática. Para el presente diseño, se utilizaron los documentos generados en la Dirección General de Planificación, y se plasmaron los requerimientos solicitados por el Jefe de Convenios y Consultores de esta Dirección. La Ingeniería de requerimientos pone en práctica las siguientes actividades: i) Extracción de Información, ii) Análisis de la información extraída, iii) Documentación de esta información y iv) validación de la información obtenida. Las herramientas de la IR son: Para el presente análisis y diseño, se utilizaron las siguientes herramientas: Entrevistas y Cuestionario, Grabaciones de Audio, Arqueología de Documentos, Aprendiz, Observación, Modelo Conceptual, Lista de Requerimientos. 8

11 Una vez identificados claramente los requerimientos (funcionales y no funcionales), es posible iniciar la etapa de modelado haciendo uso del lenguaje unificado de modelamiento (UML). Para concluir, la Ingeniería de Requerimientos logra generar "ESPECIFICACIONES CLARAS" que servirán como fuente principal de información para desarrolladores que se encargarán de realizar las tareas de implantación y creación del código fuente y las estructuras de las Bases de Datos que darán vida al Sistema de Información. Proceso de Ingeniería de Requerimientos En el presente documento se presentarán las Especificaciones obtenidas del proceso de Ingeniería de Requerimientos. Las especificaciones reflejarán finalmente los requerimientos funcionales, el análisis y el modelamiento elaborado a través de Diagramas en UML. 9

12 Perfiles del Sistema: Después de analizar la información obtenida en la etapa de relevamiento de requerimientos, se pudo determinar la necesidad de contar con los siguientes Perfiles (tipos de usuario): 0. Administrador.- (DGP o Sistemas).- Administra tablas principales, usuarios, etc. 1. Catalogo DGP (Dirección General de Planificación).- Su función principal es la de registrar, digitalizar y derivar para custodia los Convenios del MMAyA. 2. Responsable de Archivo y Custodia (Dirección General de Asuntos Jurídicos).- Sus funciones son las de recepcionar y catalogar Convenios "Originales" (Marco, Subsidiarios e Interinstitucionales) derivados de la DGP para su custodia, además, debe recepcionar y catalogar adendas, enmiendas, carta acuerdo, por otro lado, emitir copias legalizadas y registrar en el Sistema los datos referidos a estas solicitudes. 3. Gestor de Convenios (Dirección General de Planificación).- Entre sus funciones tenemos la derivación y recepción de Convenios (a nivel de responsabilidad), actualización del estado de los convenios, asignación de responsables de monitoreo y aprobación o rechazo de los Planes de Monitoreo de Convenios. Por otro lado, y previo a la existencia de un Convenio, debe poder ir capturando información de Negociación. (se debe apropiar esta información a un convenio cuando este exista) 4. Monitor de Convenios (Dirección General de Planificación).- Derivar y recepcionar, Crear, Modificar y Solicitar aprobación de un PMC del Convenio, además de asignar la responsabilidad del Componente a un Subsector (gestor subsectorial) del MMAyA 5. Gestor Subsectorial de Convenios (Viceministerios - Direcciones).- Derivar y Recepcionar, asignar, modificar responsable de seguimiento del Componente del Convenio asignado 6. Responsable de Seguimiento (Viceministerios - Direcciones).- Derivar y Recepcionar, llenar los datos obtenidos de avance de cada componente de cada Convenio definidos en el PMC. (llenar el avance en el PMC) 7. Consultas (Despacho Ministro).- Posibilidad de elaborar consultas dinámicas que permitan obtener datos para la toma de decisiones. 10

13 Módulos y Funciones del Sistema 1. Registro de Convenios (RC) 2. Gestor de Convenios (GC) 3. Monitor de Convenios (MC) 4. Gestor Subsectorial de Convenios (GSC) 5. Seguimiento de Convenios (SC) 6. Negociación de Convenios (NC) 7. Consultas de Convenios (CC) Las funciones de los módulos podrán ser detectadas en el listado de Requisitos Funcionales a desarrollarse a continuación. 11

14 REQUISITOS FUNCIONALES.- Definen Qué hace el sistema (funciones del sistema) Código Requisito Observación/Comentario RF-001 Recepción y Catalogación de Convenios Marco, Convenios Subsidiarios y Convenios Interinstitucionales. Control de ubicación del Documento Físico Original para custodia y posterior Consulta a cargo de un Responsable de Archivo y Custodia Perfil: Catalogo (DGP) y Responsable de Archivo y Custodia (DGAJ) RF-002 RF-003 Digitalización y Upload del Documento de Convenio Digitalizado en uno o más archivos (acorde al tamaño). Series documentales de 2MB c/u Registro de Convenios con la captura de todos los datos relevantes (fechas, montos, organismos, entidades). Generación del RUC (Registro Unico de Convenios) Datos Básicos Registro Convenios Marco 1) Nombre Convenio 2) RUC (se genera al grabarse los datos capturados) 2.1) Código del Cooperante (Normalmente el cooperante proporciona un código propio ej.- BID-2199/10) 3) Entidades Intervinientes y responsables (rol) (destacar quienes firman) 4) Fecha suscripción(ojo), Fecha Inicio Fin 5) Antecedentes 6) Descripción 7) Objetivos 8) Componentes (Nombre, descripción, resultados, plazo ejecución, Unidad Responsable) 8.1) Subcomponentes (Nombre, Unidad Responsable) 9) Estructura Financiamiento por Componente y subcomponente (componente, subcomponente, Fuente, Organismo, Moneda, Monto) Datos Básicos Registro Convenios Subsidiarios 1) Primero se debe vincular estar convenio a un Convenio Marco. En caso de no existir registrado el convenio Marco entonces no se registra el Subsidiario Datos Básicos Registro Convenios Interinstitucionales 1) Primero se debe vincular estar convenio a un Convenio Marco. En caso de no existir registrado el convenio Marco entonces no se registra el Interinstitucional 12 Se debe considerar que los archivos de los convenios NO deben ser muy pesados debido a su constante consulta Perfil: catalogo en la DGP Perfil: catalogo en la DGP

15 RF-004 Derivación /Recepción del documento físico Perfil: TODOS LOS PERFILES RF-005 Derivación/Recepción digital (Asignación de responsabilidad) Establece la responsabilidad (en el sistema) de un usuario sobre un determinado convenio Perfil: RF-006 RF-007 Notificación a través de alertas. Todos los usuarios deben contar con una rejilla de lectura de alertas (al estilo inbox de un cliente de correo). Tres colores: ROJO para alertas temporales(de tiempo, de cumplimiento de fechas), VERDE para alertas temporales leídas y NEGRO para el resto (acceso, nuevo convenio registrado, nuevas adendas, nuevas enmiendas, nueva versión de un PMC) Tipos de Alertas: - Cuando se registra un Convenio (Marco, Subsidiario o Interinstitucional)(se envía mensaje con datos relevantes y enlace para descarga/visualización del convenio digitalizado) - Cuando se registra una adenda (se envía mensaje con datos relevantes y enlace para descarga/visualización de la adenda digitalizada) - Cuando se registra una enmienda (se envía mensaje con datos relevantes y enlace para descarga/visualización de la enmienda digitalizada) - Cuando se registra una Carta acuerdo (se envía mensaje con datos relevantes y enlace para descarga/visualización de la carta acuerdo digitalizada) Destinatarios: - Acorde al estado del Convenio podrán ser: - Catalogo DGP (a sí mismo) - Responsable de Archivo y Custodia - Gestor de Convenios - Monitor de Convenio (si está definido) - Gestor Subsectorial de Convenio (si está definido) - Responsable Seguimiento (si está definido) Notificación a través de correos electrónicos. Todos los usuarios en todos los perfiles deben tener correo electrónico "obligatorio" Destinatarios: - Acorde al estado del Convenio podrán ser: - Catalogo DGP (a sí mismo) - Responsable de Archivo y Custodia - Gestor de Convenios - Monitor de Convenio (si está definido) - Gestor Subsectorial de Convenio (si está definido) 13 TODOS LOS PERFILES Perfil: TODOS LOS PERFILES Ej.- La derivación de un convenio, el registro de una adenda, enmienda NO SON TEMPORALES. Por otro lado, el cumplimiento de un plazo es una alerta temporal y debe ir en rojo Perfil: TODOS LOS PERFILES

16 - Responsable Seguimiento (si está definido) RF-008 Buscador de Convenios y descarga del Convenio Digitalizado. También adendas, enmiendas y/o cartas acuerdo Perfil: TODOS LOS PERFILES pero solamente los convenios en los que se encuentran involucrados (control por usuarios) RF-009 Registro de Adendas, Enmiendas y Carta Acuerdo Perfil: catalogo en la DGP RF-010 Buscador de funcionarios de la DGP para asignación de Monitor de Convenio Perfil: Gestor de Convenios RF-011 Actualización del Estado de Un Convenio. Los estados Perfil: Gestor de RF-012 RF-013 RF-014 pueden ser: En ejecución, No vigente, En cierre, Cerrado Aprobación y Desaprobación del Plan de Monitoreo de Convenios. Ni bien se realiza la acción, el Plan de Monitoreo de Convenios (PMC) cambia de estado y puede ser utilizado. Se envían alertas y correos electrónicos a los usuarios involucrados Captura de Datos de Negociación (Bitácora de Negociación) Aplicación para Tablets en la que se tenga una bitácora de negociaciones con los COOPERANTES con objetivos, puntos tratados, estructura financiera, participantes y acuerdos pendientes, compromisos, problemas. Con posibilidad de tener archivos de apoyo y centralizar al sistema. Considerar que las negociaciones se llevan a cabo en dos ámbitos: 1) Con los Cooperantes y 2) Con entidades nacionales (VIPFE, Ministerios) y subnacionales (Municipios, Gobernaciones). Esta bitácora debe distinguir brindar una herramienta que facilite al usuario el uso de esta información Creación y Modificación de un Plan de Monitoreo de Convenios (PMC). Los PMC deben ser versionados y no pueden estar habilitados hasta que sean aprobados por el Gestor de Convenios Deben permitir: - Definir Condiciones Previas a la ejecución (No. clausula, Actividad, Entidad Responsable, Condicionamiento, Fecha inicio, fecha cumplimiento y fecha de verificación, Reporte Preventivo con texto a definirse, reporte de incumplimiento) 1 Convenios Perfil: Gestor de Convenios Perfil: Gestor de Convenios Proporcionar una herramienta de información para las reuniones de negociación de Convenios, además de documentar los acuerdos logrados en cada reunión y los compromisos asumidos. Perfil: Monitor de Convenios 1 CUADRO No.1: Cumplimiento de Clausulas Contractuales del Convenio 14

17 - Agregar Componentes por cada Convenio - Definir Hitos de ejecución para cada componente - Definir la Unidad Responsable para cada componente - Definición de alertas (fechas límites de cumplimiento de un hito, numero de alertas previas al cumplimiento, textos a ser enviados, texto de incumplimiento[cuando un hito NO SE CUMPLIO y el plazo ha caducado] - Registro de Clausulas contractuales (deben ser las que van en el Convenio o adendas y/o enmiendas) - Indicadores para cada subcomponente Cuando se define la unidad responsable de ejecución del componente (se envia una alerta al Gestor Subsectorial de Convenios para que nombre un Responsable de Seguimiento). En el mail y la alerta, se muestran las clausulas que deben ser cumplidas para el componente. Por último: - Registro de Observaciones de Auditoría (Normalmente son anuales. Estas observaciones deben figurar como pendientes hasta que el Responsable de seguimiento las haya levantado/subsanado con un documento de respaldo solicitado al ejecutor -Registro de Desembolsos con la fecha, el monto y moneda y destino (No.Cuenta), además, el responsable de seguimiento podrá capturar subir archivos de respaldo de estos desembolsos. RF-014 Solicitar Aprobación del PMC Perfil: Monitor de Convenios RF-015 Asignación Gestor Subsectorial y notificación Perfil: Monitor de Convenios RF-016 RF-017 Asignación de un Responsable de Seguimiento (Subsectorial) Cargado de Información de Seguimiento acorde al PMC. Consulta a Sistema de POA para identificar la programación y ejecución de los convenios Consultar a la interface del sistema de Presupuestos para identificar la programación y ejecución presupuestaria. - Registro de observaciones de Auditoría (anuales) poniéndolas como pendientes hasta que se las "levante" justificando con un documento de respaldo. - Registro de desembolsos con Montos, Monedas, fecha y destino (No.Cuenta). Subir respaldos de archivos Perfil: Gestor Subsectorial de Convenios Perfil: Responsable de Seguimiento 15

18 digitalizados de los desembolsos realizados RF-018 Subir archivos reportados por ejecutores (Informe Técnico, Informe Administrativo, Informe Legal y Actas Perfil: Responsable de Seguimiento de Conformidad) RF-019 Batería de Reportes a definirse por cada perfil Perfil: Todos los perfiles REQUISITOS NO FUNCIONALES.- definen los atributos que indican al sistema como realizar su trabajo (eficiencia, hardware, software, interface, usabilidad, etc.) Codigo Requisito Observación/Comentario RNF-001 El Módulo debe ser desarrollado en entorno web con compatibilidad en TODOS los navegadores existentes en el mercado (Mozilla Firefox, Google Chrome, Opera, IE 10 y sup). Amigable Resulta imprescindible la compatibilidad con exploradores debido a que se trabajará remotamente con el RNF-002 RNF-003 RNF-004 Todos los días en horarios a definir se deben ejecutar procesos de envío de correos electrónicos a todos los involucrados en cada convenio El modulo debe ser auditable, permitiendo la trazabilidad de los datos registrados con fechas y horas de las acciones realizadas por los usuarios El módulo debe contar con niveles de seguridad a nivel de red, aplicación y base de datos modulo El módulo deberá contar con la definición de parámetros en los que se defina la cuenta de correo y clave, el servidor SMTP de envío de correos automáticos El administrador podrá emitir reportes de trazabilidad de los datos del sistema En la actualidad resulta de suma importancia contar con niveles de seguridad a fin de prevenir 16

19 DISEÑO DE SOFTWARE Transformamos los requerimientos funcionales en diagramas UML para su correcta interpretación, creando un modelo lo más cercano a lo deseado y que sirva de marco de referencia entre usuarios y desarrolladores. Diagrama de Contexto Diagrama de Actividades Diagrama de Casos de Uso Especificaciones de Caso de Uso (*) Diagrama de Clases Mockups de la aplicación Con todos estos diagramas, y especificaciones claras de los Casos de Uso, el desarrollo de la aplicación puede iniciarse con la seguridad de obtener un producto de calidad y utilidad que servirá al MMAyA para la Gestión de los Convenios, cumpliendo así el objetivo planteado inicialmente. 17

20 Diagrama de Contexto General (por perfiles) 18

21 Diagrama de Contexto Detallado 19

22 Diagrama de Actividades 20

23 Diagrama de Casos de Uso 21

24 22

25 23

26 24

27 25

28 Diagrama de Clases 26

29 27

30 28

31 Arquitectura del software (Modelo Vista Controlador - MVC) 29

32 Desarrollo Con el propósito de agilizar el desarrollo de aplicaciones en el Ministerio de Medio Ambiente y Agua, el Área de Sistemas vio por conveniente adquirir cinco (5) licencias perpetuas del producto "ScriptCase"; se trata de una herramienta RAD (Rapid Application Development) que genera código PHP de fuente abierta con posibilidad de ser modificada. ScriptCase El ScriptCase es una potente herramienta que aumenta la productividad de desarrollo Web, se ejecuta directamente en el navegador (Internet Explorer, Chrome, Firefox, etc), permite el desarrollo colaborativo en red local o remota. ScriptCase proporciona soporte para bases de datos líder del mercado, la creación de código flexible e independiente de la base de datos utilizada y el sistema operativo (Windows, Linux, MAC, etc.) Cuenta con un excelente soporte para PostGreSQL, SqLite, InterBase, Firebird, Access, Oracle, MS SQLServer, DB2 e SyBase. Pantalla de Acceso al Scriptcase instalado en el Servidor de Desarrollo utilizado para la creación de este Sistema. 30

33 Panel Principal de Creación de Programas de manera ágil. Durante el presente desarrollo se desarrollaron 298 aplicaciones para representar la funcionalidad solicitada por los usuarios del MMAyA Con el propósito de acelerar el proceso de aprendizaje de esta herramienta se utilizaron videos descargados de youtube que permitieron conocer un poco más a detalle el funcionamiento de este RAD. 31

34 En uno de los videos se muestra la posibilidad de establecer propiedades a un grid Pantalla de Ingreso a la aplicación 32

35 Buscador de Convenios Registrados en el Sistema. Interface con el Sistema SISGP del MMAyA Generación de gráficas dinámicas 33

36 Ejecución Financiera de Proyectos vinculados a un Convenio CIF Fichas de Convenios y de Programas Para concluir, la herramienta ScriptCase resulto de suma utilidad agilizando el desarrollo de aplicaciones. La curva de aprendizaje (como en todo software) fue dificultoso al inicio, sin embargo, al irse familiarizando, las aplicaciones pueden ser creadas en cuestión de minutos sin problema. Se incorporaron funciones a través de macros y de código PHP dentro de ScriptCase, sin encontrar grandes dificultades. 34

37 Ministerio de Medio Ambiente y Agua Ing. Gonzalo E. Murillo M. Manuales y Documentación Entregada Como producto final de la presente consultoría se hizo la entrega de la siguiente documentación en formato Digital (DVD), misma que se adjunta al presente informe. Respaldo de la Base de Datos Diccionario de Datos Diagrama Entidad Relación Programas Fuentes del Modulo Manuales de Usuario Manual Técnico Mapa de la Aplicación Respaldo de todos los documentos generados en el servidor compartido de archivos (nube) Presentaciones elaboradas en las distintas etapas Respaldo de los programas en la herramienta de desarrollo utilizada (scriptcase) Conclusiones El desarrollo rollo del Modulo de Convenios cumplió con los requerimientos definidos por la Dirección General de Planificación. La mayor complejidad encontrada en este desarrollo fue la creación de los Planes de Monitoreo de Convenios (PMCs) que van a constituirse en una herramienta de trabajo imprescindible para el seguimiento a los Convenios en el MMAyA. Las funciones con las que cuenta actualmente el sistema se muestran en la imagen. En cuanto a las dificultades encontradas se debe mencionar que en el MMAyA no existe información actualizada del avance físico - financiero de los proyectos, hecho que dificultó la generación de mayo cantidad de reportes, sin embargo, el Area de Sistemas se encargará de hacer adecuaciones en el Modulo de Proyectos desarrollado por la ATI. Por otro lado, la interface con el Sistema POA del MMAyA no fue desarrollada debido a la inexistencia de contraparte técnica para el manejo del Sistema. 35