INFORME DE AUDITORÍA Al Sr. Secretario de Hacienda del Ministerio de Economía Lic. Carlos Alberto Mosse En uso de las facultades conferidas por el artículo 118 de la Ley Nº 24.156, la AUDITORÍA GENERAL DE LA NACIÓN (AGN) procedió a efectuar un examen en el ámbito de la SECRETARÍA DE HACIENDA (SH), con el objeto que se detalla en el apartado 1. 1. OBJETO DE LA AUDITORÍA Evaluación de los controles en el desarrollo del proyecto del SIDIF (Sistema Integrado de Información Financiera) Internet o e-SIDIF, para la mejora de las prestaciones en el Sistema de Información Financiera del gobierno nacional. 2. ALCANCE DEL EXAMEN El examen fue realizado de conformidad con normas de auditoría externa de la AUDITORÍA GENERAL DE LA NACIÓN, aprobadas por la Resolución Nº 145/93, dictadas en virtud de las facultades conferidas por el artículo 119, inciso d) de la Ley Nº 24.156. Para la evaluación se tomaron como referencia los estándares internacionales de auditoría, en particular, COBIT (Control Objectives for Information and Related Technology), referido a los controles en la tecnología de la información (TI). Se analizó la gestión del ciclo de vida del nuevo proyecto del Sistema de Información Financiera o e-sidif, desde los estudios preliminares iniciados a mediados de 2003 hasta la Página 1 consolidación de la arquitectura alcanzada en diciembre de 2005. Esta última etapa es previa al inicio del desarrollo de las aplicaciones. Dado el número de nuevas prácticas empleadas en el proyecto, el análisis redujo su nivel de detalle en aspectos técnicos y no comprendió controles sobre las contrataciones realizadas en el período auditado. Se requirieron informes a la Oficina Nacional de Tecnologías de la Información (ONTI), dependiente de la Subsecretaría de Gestión Pública, órgano que regula la supervisión del diseño e implementación de los sistemas informáticos para el proceso electrónico de datos y desarrollo de sistemas de información de jurisdicción –Decreto Nº 889 de 2001 y modificatorios–, para que informara sobre su actuación en este proyecto. Las tareas de campo se realizaron en el ámbito del Ministerio de Economía, donde reside la Unidad Informática, entre el 29 de mayo y el 8 de setiembre de 2006. 2.1 Relevamiento La documentación del e-SIDIF está incluida en la biblioteca digital de la Unidad Informática, a la cual esta auditoría tuvo acceso. Ante el requerimiento de información solicitado por la AGN, se recibieron notas de la Subsecretaría de Presupuesto, Contaduría General de la Nación, Coordinación Técnica del FOSIP –Fortalecimiento del Sistema de Inversión Pública–, la Unidad de Auditoría Interna del Ministerio de Economía y la ONTI (Oficina Nacional de Tecnologías de la Información). Otro medio de comunicación utilizado fue el correo electrónico. Para ello se asignaron a esta auditoría cuentas del Ministerio de Economía. 2.2 Entrevistas realizadas Dentro de la estructura del proyecto • Gerente del Proyecto Página 2 • Coordinadora General • Responsable de la Coordinación de Análisis • Responsable de la Coordinación Diseño y Desarrollo • Responsable de la Coordinación de Testing • Responsable de la Coordinación Ingeniería • Responsable de Arquitectura de Aplicación • Responsable de Arquitectura Física Otras áreas Coordinador de la Unidad Informática • Subcoordinadora de la Unidad Informática • Dirección de Auditoría de Sistemas (DAS) de la Contaduría General de la Nación • Coordinación de FOSIP (Secretaría de Política Económica) • Coordinadora de Sistemas Operativos (Oficina Nacional de Presupuesto -ONP-) 2.3 Evidencias Se obtuvieron a partir de entrevistas y procedimientos realizados para evaluar el control interno. Se recolectaron evidencias en formato digital y documental. Se obtuvo información adicional mediante notas y correos electrónicos oficiales a funcionarios con responsabilidad en el proyecto. Página 3 3. ACLARACIONES PREVIAS 3.1 Órgano Rector La Subsecretaría de Presupuesto remitió a la ONTI los expedientes S01: 0290 785/04 de contratación de los servicios de consultoría para el desarrollo del prototipo y S01: 0355 314/04 para el servicio de consultoría para el desarrollo del SIDIF. Ambos expedientes se encontraban en ese organismo, sin respuesta, desde el 11 de noviembre de 2004 y 12 de enero de 2005 respectivamente hasta la finalización de las tareas de campo. 3.2 El SIDIF 3.2.1 SIDIF Central En el marco de la Reforma Administrativa y Financiera del Sector Público (Ley Nº 24.156, del 29 de octubre de 1992) y con el financiamiento del Banco Mundial (préstamo 3362-AR) y el Banco Interamericano de Desarrollo (préstamo 826/OC-AR), se diseñó, desarrolló e implementó a partir de 1993 el SIDIF (Sistema Integrado de Información Financiera), un sistema a medida que permitió la formulación del presupuesto nacional y sus modificaciones, la programación de la ejecución presupuestaria, la ejecución presupuestaria de gastos y recursos y la contabilidad general a nivel transaccional, movimientos de fondos, órdenes de pago y deuda exigible, conciliación bancaria, transferencia electrónica de pagos, embargos y cesiones, entre otros. De esta manera, la administración financiera integró el presupuesto con la contabilidad y la tesorería agregando funcionalidades como la obtención de balance conforme al método de la partida doble y la programación financiera. Este producto se desarrolló en consonancia con la emisión de normas que regulan el crédito público, una organización para la administración financiera, capacitación del personal e incorporación de recursos informáticos. Página 4 3.2.2 SIDIF Locales Para su gestión presupuestaria y contable, los Servicios Administrativo-Financieros (SAF) de las distintas jurisdicciones de la Administración Central han contado, en su gran mayoría, con sistemas locales provistos por la UI como CONPRE (Consolidación Presupuestaria), SIDIF OD –organismos descentralizados–, SIGRAC –específico para la administración central y recientemente dado de baja–, y a partir de 2001 el SLU (SIDIF Local Unificado). Otros organismos adoptaron soluciones diferentes, como sistemas comprados a terceros o desarrollos propios. Funcionalmente, los sistemas mencionados son distintos e independientes, pero cada uno de ellos permite realizar transacciones en conexión con el SIDIF Central utilizando para ello un sistema de transferencia de datos denominado TRANSAF. El siguiente cuadro muestra la situación a julio de 2006: AC CUT SLU OD NO CUT CUT TOTALES NO CUT 24 6 50 0 80 PROPIO 6 2 1 1 10 CONPRE 3 3 1 4 11 1 2 3 53 7 104 SIDIF OD Totales 33 11 AC: Administración Central. OD: Organismo Descentralizado. CUT: Cuenta Única del Tesoro. Fuente: Sitio Web de la Administración Financiera. Página 5 3.2.3 Organización del SIDIF Internet La Subsecretaría de Presupuesto ha definido una organización –informal– para el diseño, desarrollo, implementación y distribución del SIDIF Internet, que ilustra el siguiente gráfico: Página 6 Gerencia del Proyecto Comité Organos Rectores Subsecretario de Presupuesto Directores Organos Rectores Coordinación de la UI Equipo Multifuncional Miembros de los O.R. Coordinación General Asistente de Documentación e Arquitectura Coordinación Análisis Coordinación Diseño y Desarrollo Coordinación Ingeniería Coordinación Testing Grupo Lifia Ingenieros Testers quitectura Física Subcordinación Presupuesto Subcoordinación TE, GS, P y V, FR, EN quitectura de Aplicación Analistas Analistas Página 7 En esta tabla se describen las responsabilidades más importantes de cada componente de la estructura: ROL Comité Órganos Rectores Gerencia del Proyecto Coordinación General Equipo Multidisciplinario Funcional RESPONSABILIDADES Sponsorear el proyecto en los distintos niveles políticos que lo requieran. Delinear las políticas que guiarán el proyecto. Facilitar recursos estratégicos al proyecto. Resolver conflictos de recursos Ser último nivel de decisión frente a conflictos/problemas Participar en la reunión quincenal de avance. Planificar aspectos estratégicos del proyecto en función de las políticas definidas. Aprobar los recursos técnicos y humanos requeridos por el proyecto Participar/Aprobar la planificación del proyecto Participar en las reuniones quincenales de avance del proyecto. Resolver conflictos estratégicos dentro del proyecto Planificar las diferentes actividades del proyecto. Identificar riesgos y planificar acciones de mitigación/prevención. Hacer el seguimiento regular de las actividades. Participar y supervisar las decisiones técnicas del proyecto. Tomar acciones correctivas en el proyecto. Coordinar los recursos asignados al proyecto. Elaborar los informes de avance del proyecto. Participar en reuniones de trabajo que lo requieran. Participar en la reunión quincenal de avance. Facilitar el compromiso para el cumplimiento de las políticas de calidad. Resolver conflictos operativos y de recursos. • Participar en la planificación de los talleres funcionales. • Proveer los recursos para los talleres funcionales. Participar en los talleres funcionales. • Colaborar en la preparación de los materiales para los talleres funcionales. • Decidir sobre cuestiones abiertas que requieren definición. Página 8 ROL • • • RESPONSABILIDADES Aportar conocimiento funcional y normativo. Participar en el control de Calidad de los artefactos resultantes de los talleres. Participar en la aprobación formal de los artefactos que produce el Equipo de Análisis. Participar en la prueba de aceptación del producto. 3.2.4 Presupuesto y Gasto Desde 2005 el proyecto SIDIF Internet cuenta con fondos específicos del presupuesto nacional a través del programa 26 de Administración Financiera en la actividad 07- SIDIF Internet. La Unidad Ejecutora de este programa es la Subsecretaría de Presupuesto. Durante 2004, el proyecto fue financiado, dentro de ese programa, con recursos provenientes de la actividad 01-Conducción del Sistema de Administración Financiera y la actividad 06Coordinación Informática de la Administración Financiera. SIDIF Internet también cuenta, desde 2004, con recursos provistos por la Unidad Ejecutora del Préstamo BIRF 3958/AR a través de la actividad 06-Inversión Pública del programa 18Formulación y Ejecución de Políticas Económicas, que administra el proyecto FOSIP – (Fortalecimiento del Sistema de Inversión Pública). El siguiente cuadro muestra los gastos y el origen de los fondos para el período 2004-2005: Actividad 07-SIDIF Internet Año Crédito Presupuestario 2005 4.638.473 Devengado 1.965.064 Página 9 GASTOS EN CONSULTORES Programa 18 – FOSIP Programa 26 – Actividad 06 01 07 EMPRESAS DE CONSULTORÍA Programa 18 - FOSIP BIENES ADQUIRIDOS Programa 18 - FOSIP TOTALES POR PROGRAMA 18 26 TOTALES GENERALES 2004 134.760,00 338.662,00 463.323,00 2005 Total Período 3.092.717,00 325.668,00 338.662,00 463.323,00 1.965.064,00 715.561,69 715.561,69 383.073,00 383.073,00 1.431.302,69 2.767.049,00 4.191.351,69 190.908,00 1.965.064,00 162.281,69 553.280,00 3.303,00 379.770,00 307.344,69 1.123.958,00 801.985,00 1.965.064,00 1.102.329,69 3.089.022,00 Valores expresados en pesos. Fuente: Datos proporcionados por la Subsecretaría de Presupuesto y la Coordinación Técnica del FOSIP. 3.2.5 El SIDIF Internet El informe final (junio de 2005) del proyecto FOSIP describe los orígenes del nuevo sistema: “En el marco del Componente E del Proyecto FOSIP, Fortalecimiento del Sistema de Administración Financiera Gubernamental (AFG), a fines de 2002 se comenzó a trabajar con dos ejes problemáticos: • Unificación de los sistemas vigentes a esa fecha • Identificación de cursos de acción para el fortalecimiento de la AFG.” “En Noviembre del año 2003 la Subsecretaría de Presupuesto comenzó a estudiar la factibilidad de desarrollar la actualización tecnológica del SIDIF, aprovechando los avances en materia de comunicaciones y nuevas tecnologías de entorno Web. El objetivo planteado fue generar un nuevo producto –el SIDIF Internet– que cubriera la funcionalidad de la Página 10 administración financiera del Estado tanto para el nivel central como para los organismos, acorde con los requerimientos de la Ley de Administración Financiera y Sistema de Control. La etapa inicial de los trabajos consistió en la definición de las características centrales del nuevo producto: • La definición de los aspectos funcionales generales del producto y los aspectos técnicos a través de los talleres de trabajo con las áreas de la Subsecretaría. • La definición de las características técnicas del producto, a través de la captura de los requerimientos generales y específicos, de manera de consolidar el nuevo modelo funcional.” Además define, en otro párrafo: “Características del producto Como resultado de los talleres realizados con funcionarios de la Subsecretaría en 2003, se obtuvieron las características centrales del producto a desarrollar: • El producto tendrá como marco las normas establecidas por el Ministerio de Economía y Producción de la Nación para el desarrollo de nuevos sistemas. En tal sentido el producto se desarrollará como un sistema orientado a objetos (OO) y se documentará utilizando el lenguaje de modelado UML. La arquitectura J2EE (Java 2 Enterprise Edition) regirá el diseño y construcción de la aplicación. Notas a este punto: 1) El sistema orientado a objetos hace referencia a que su desarrollo estará basado en programación orientado a objetos el cual es un modelo para escribir software para computadoras. Objetos son cajas negras que envían y reciben “mensajes”. Con este enfoque se pretende mejorar el mantenimiento y la reusabilidad del software. 2) La arquitectura JEE implica un modelo de aplicaciones distribuidas en diversas capas o niveles (tier). Página 11 • El proyecto se centra en tres ejes fundamentales : 1. La gestión por resultados, que persigue los siguientes objetivos • Profundizar la descentralización operativa. • Revalorizar el sistema actual de presupuesto por programas como herramienta para la gestión de resultados. • Desarrollar instrumentos para impulsar: • La vinculación entre las asignaciones financieras y el logro de metas. • La evaluación (autoevaluación) de las políticas públicas. 2. La ampliación del alcance, incorpora funcionalidades hoy no contempladas en los sistemas existentes: • Administración de bienes. • Recepción de bienes y servicios. • Funcionalidad UEPEX integrada en cada uno de los negocios sin necesidad de contar con un sistema ad hoc. • Cuentas a cobrar. • Organismos no incluidos actualmente en la Administración Nacional tales como fondos fiduciarios y organismos descentralizados no incorporados – Ley 25.917 Federal de Responsabilidad Fiscal. Nota: UEPEX es el sistema de gestión para las Unidades Ejecutoras de Préstamos Externos. 3. La actualización tecnológica proveerá importantes beneficios en lo relativo a: • Accesibilidad del sistema. • Reducción en el costo de software por la adopción de herramientas de uso libre. Página 12 • Reducción del costo de hardware por la concentración de bases y aplicaciones en un sitio central; • Mayor capacidad de interoperabilidad con otros organismos que ya usan este tipo de tecnología. • Menor requerimiento de capacitación de usuarios por la amplia difusión del entorno Internet. • Descentralización operativa. • Navegación de toda la documentación de una transacción en la base de datos del sistema. • Distintas visiones de la información. • Flexibilidad en la gestión de comprobantes. • Facilidad en la toma de decisiones” 3.2.5.1 Etapas del Proyecto Las fases que se consideran más adelante se organizaron para su mejor comprensión y no se encuentran en estricto orden cronológico. A) Visión Compartida Las autoridades de los Órganos Rectores (OR) realizaron un taller el 28 de octubre de 2003 para tratar los siguientes temas de la Agenda Estratégica confeccionada en junio de ese mismo año por la Subsecretaría de Presupuesto (SSP): • Revalorización de Instrumentos. • Promover el Gobierno Electrónico en todas sus dimensiones. • Simplificar el marco normativo. • Establecer lineamientos generales para desarrollos informáticos futuros. Se logran definiciones sobre 1) El Alcance de Aplicación 2) Consideraciones sobre el sistema Página 13 3) Principales aspectos del Modelo Conceptual 4) Aspectos Funcionales Particulares a considerar. B) Caso de Negocio Las organizaciones desarrollan esta práctica para responder temas claves cuando se planea migrar a un enfoque de línea de producto para implementar sistemas de software, como: v Qué cambios en la organización deben producirse para realizar la transición. v Qué beneficios traerá el realizar el cambio. v Cuáles son los costos y los riesgos. v Cómo se medirá el éxito. Software por línea de producto: es un conjunto de sistemas de software intensivo que comparten ciertas características al satisfacer necesidades de una misión o segmento de mercado y que se desarrollan sobre la base de un conjunto de recursos y de manera preestablecida. En el sitio del SEI -Software Engineering Institute- se encontrará más información al respecto. El documento Caso de Negocios – Proyecto SIDIF-I (24/ 06/2004) realiza una presentación del caso estableciendo como objetivos: • Unificar los productos de Administración Financiera. • Disponer de un producto adaptable a diferentes entornos y tamaños de organizaciones. • Migrar a una tecnología orientada a entornos Internet y de software libre. • Producto con menos defectos y mayor nivel de funcionalidad. Algunos Beneficios Esperados • Aumento de productividad. Página 14 • Reducción de defectos. • Reducción de la rotación de personal por trabajo más motivador. • Mayor eficiencia operativa por mejor/mayor funcionalidad. Algunos Riesgos • Falta de apoyo por cambios políticos. • Selección equivocada de herramientas de desarrollo. • Desvíos importantes en las fechas debido al impacto de la nueva tecnología. Otras alternativas consideradas • Reingeniería (se desecha pues sería similar al nuevo desarrollo). • Mantener el actual sistema aumentando el personal para compensar la carga creciente de trabajo. • Adquirir productos estandarizados y hacer las adaptaciones necesarias. Algunos valores estimados del proyecto • Tamaño del producto: 11.000 puntos funcionales. • Pico máximo de recursos: 38 personas. • Tiempo calendario esperado: 38 meses. • Costo de Desarrollo: $7.400.000. C) Modelo Conceptual Los lineamientos del nuevo producto establecidos en la “Visión Compartida” definieron el marco del modelo conceptual. Con la participación de funcionarios de los OR, analistas de la Unidad Informática (UI) y representantes del equipo de réplicas (SLU). se realizaron talleres de creación de los modelos que representarían el modelo conceptual para cada uno de los negocios definidos en el alcance del producto. Página 15 D) Marco de la Arquitectura En base al Modelo Conceptual y el conocimiento del equipo de la UI sobre las aplicaciones actuales, se definió la línea de base de arquitectura J2EE del nuevo producto. Para ello se contrató a una firma especializada. E) Desarrollo y Prueba del Prototipo Se desarrolló un prototipo del producto –en base a un circuito de pagos y gastos para comprobar, en escala reducida, las decisiones de arquitectura y diseño en relación con las funcionalidades previstas. Para ello se contrató a otra firma especializada. F) Priorización y Definición de Requerimientos detallados del Negocio Presupuesto Antes de que se definieran los requerimientos del negocio Presupuesto, personal del proyecto, con la participación de los OR, evaluó escenarios de desarrollo, realizaron estimaciones de tamaño y de esfuerzo que concluyeron en la definición de prioridades u orden de los negocios a implementar así como la conformación de los grupos de implementación. G) Consolidación de la Arquitectura Esta etapa toma como insumo el marco de arquitectura. G1) Arquitectura lógica Comprende el desarrollo de los “componentes estructurales” del sistema e-SIDIF, que son aplicaciones genéricas utilizadas para el desarrollo de una aplicación mayor, por ejemplo, un proceso de búsquedas que sirva a varias funcionalidades del sistema. Para diseñar la arquitectura lógica, se contrató a una empresa especializada, que desarrolló, entre otros componentes: información histórica, seguridad, simulación de escenarios, administración de procesos batch y cliente Web. Página 16 Con una adicional contratación se obtuvo una “Extensión del Desarrollo de Componentes Básicos”: mensajes, alertas, copias heterogéneas, componente de copias con transformación, seguridad aplicativa y escenarios de simulación -. G2) Arquitectura Física Para dimensionar el equipamiento y el software de base necesario para soportar al nuevo sistema, el responsable de la Arquitectura Física y el Área de Tecnología de la UI han realizado periódicamente actividades conjuntas, como, por ejemplo, recomendaciones al proyecto y una evaluación del hardware de PC de los SAF. G3) Documentación Está compuesta de cuatro partes o secciones: 1) Los principales elementos estructurales que definen en grandes rasgos todo el sistema. 2) La estrategia de implementación para cada uno de los elementos definidos en la primera sección. Aquí se seleccionan las tecnologías a aplicar en cada una de las capas (presentación, negocio, integración, etc.). Se describen también los aspectos de seguridad requeridos a nivel de aplicación y se tratan todos los temas de seguridad que deben tenerse en cuenta en el desarrollo. 3) Los lineamientos de diseño y la descripción de todos los problemas comunes identificados, la solución genérica propuesta para cada uno de ellos y la definición de cada uno de los componentes de arquitectura implementados. 4) La descripción de la arquitectura física relativa al software de base (sobre el cual se montará la aplicación), la arquitectura de servidores (con un análisis de las distintas configuraciones de servidores posibles –tanto de aplicación como de base de datos– para cumplir con los requerimientos no funcionales), la seguridad de la infraestructura (análisis de los distintos aspectos de seguridad que deben tenerse en cuenta con respecto a los canales de comunicación y los servidores) y la arquitectura física definida (balanceando todo lo Página 17 analizado en las tres secciones anteriores se define cuál es la arquitectura física que se tendrá en el e-SIDIF en producción). H) Inicio de Construcción del Producto Con la definición de requerimientos funcionales del negocio Presupuesto se inicia, a partir de agosto de 2005, el diseño y construcción de los subnegocios EB (Entidades Básicas), CLA (Clasificadores Presupuestarios) y FOP (Formulación Presupuestaria), éste último se programa para fines de ese mismo año. 3.2.5.2 Convivencia La estrategia de implementación se ha definido como gradual y por lo tanto de coexistencia con los actuales sistemas SIDIF (Central y Locales). A tal fin se ha desarrollado un componente “Estrategia de Convivencia”, cuyo objetivo es la formulación de una estrategia de convivencia entre las aplicaciones actuales (SLU y SIDIF central) y la nueva aplicación (e-SIDIF), y la realización de una implementación de prueba para demostrar la factibilidad de la estrategia formulada. Con ese marco, por cada subnegocio ha sido necesario definir las modalidades de su convivencia. Ello implica –además de evaluar impactos–, analizar, desarrollar y testear esta funcionalidad. Estas tareas las realizan de manera conjunta quienes desarrollan en el proyecto y especialistas de la UI que conocen el SC y/o SLU. 3.2.5.3 Metodología de Trabajo El sistema se desarrolla en el marco de las normas establecidas por el Ministerio de Economía y Producción para el desarrollo de nuevos sistemas (Resolución 433/2003). El producto se desarrollará como un sistema orientado a objetos y se documentará utilizando el lenguaje de modelado UML (Unified Modeling Language). Se ha adoptado el Proceso Página 18 Unificado de Rational (RUP –Rational Unified Process–) como marco genérico para el desarrollo del sistema. RUP - FASES, ITERACIONES Y DISCIPLINAS El equipo de Ingeniería del Proyecto ha desarrollado a lo largo de todo el proceso la adaptación de los modelos propuestos por el RUP al desarrollo de e-SIDIF. El diseño de los controles de calidad (QA) ha sido parte de esta tarea. Para cada actividad se han elaborado los elementos de soporte: ü Templates ü Guías de Buenas Prácticas ü Guía del autor ü Guía del lector ü Listas de comprobación ü Herramientas de soporte y se ha capacitado al personal que los usa. Se adoptó el Use Case Point –UCP– o puntos de caso de uso, como método de estimación de tamaño y esfuerzo para el desarrollo del e-SIDIF. Página 19 Nota: Un Use Case representa una unidad discreta de interacción entre un usuario (persona o máquina) y el sistema. Más precisamente, un “caso de uso”: • Es una unidad de trabajo significativo como ser un “login” al sistema, el registrarse al sistema o crear una factura. • Tiene una descripción de la funcionalidad que será construida en el sistema. • Puede “incluir” o “ampliar” la funcionalidad de otro caso de uso sin afectar su propio comportamiento. 3.2.5.4 Herramientas Para la creación de aplicaciones en lenguaje Java se dispone de una plataforma de desarrollo basada en software de código abierto con integración a una herramienta de control de versiones. Para el modelado gráfico UML se emplea un producto licenciado. Permite la creación de los artefactos para la modelización, documentación, construcción y mantenimiento del sistema OO. El cuadro que se muestra a continuación describe los modelos y artefactos* adoptados de RUP. • La administración de la configuración es la disciplina que evalúa, coordina, aprueba o desaprueba e implementa cambios en artefactos que son usados para construir y mantener sistemas de software. Para la terminología utilizada en este proyecto, el término “artefacto”, proviene del inglés “artifact”, es utilizado para indicar ítems que pueden ser de hardware, software, documentación, e incluso roles de las personas que trabajan en desarrollo. En lo sucesivo, para este documento, se utilizará el término en ese sentido. Página 20 INGENIERIA DE PROCESOS ad ARTEFACTOS «refine» «modelo» Modelo de Implementación (MDI) insumo insumo «modelo» Modelo de Interfaz de Usuario (MIU) «documento» Guía de Usabilidad «trace» «modelo» Modelo de Diseño «use» insumo «documento» Guía de Diseño «modelo» Arquitectura del Sistema «realize» «use» «modelo» Modelo de Clases de Análisis (MCA) «modelo» Modelo de Casos de Uso (MCU) MCN «trace» «realize» «modelo» Modelo de Procesos del Negocio (MPN) «realize» «modelo» Línea Base de Requerimientos (LBR) «refine» «modelo» Modelo de Objetos «use» del Dominio (MOD) «modelo» Modelo de Reglas de Negocio (MRN) «trace» «use» «modelo» Glosario del Negocio (GLO) «trace» MDR / Documentos del Dominio 3.2.5.5 Centro de Cómputos La Unidad Informática cuenta con locales dedicados al procesamiento del SIDIF en sede de la SH y de AFIP (Administración Federal de Ingresos Públicos). El proyecto e-SIDIF ocupa un local de procesamiento para las tareas de desarrollo y testing. Página 21 4. COMENTARIOS Y OBSERVACIONES A cada objetivo de control que se describe corresponden una o varias observaciones y los efectos que se derivan de ellas. Ambiente de Control 4.1 Objetivo de Control: Participación Proactiva de Auditoría El proyecto e-SIDIF deberá obtener un análisis independiente, buscando que una auditoría evalúe cada solución de tecnología de información desarrollada, antes de su instalación. 4.1.1 Auditoría independiente En el marco del FOSIP (préstamo BIRF 3958 – AR), se tuvo conocimiento de informes hasta Noviembre de 2004- de seguimiento de avance del proyecto por parte del Banco. No se obtuvo evidencia de que en el período 2004-2005 la Dirección de Auditoría de Sistemas (DAS) o la Unidad de Auditoría Interna del Ministerio de Economía, ambas con competencias en la materia, hubieran practicado alguna forma de auditoría al proyecto. Tampoco que en ese período la DAS hubiera participado o planificado una auditoría al proyecto. Efectos Se corre el riesgo de evaluar los controles internos de manera incompleta. 4.2 Objetivo de Control: Cambios al Plan Estratégico La Unidad Informática deberá asegurar que se establezca un proceso para adaptar oportunamente y con precisión el plan a largo plazo de tecnología de información al plan a largo plazo de la organización y a los cambios en las condiciones de la tecnología de información. 4.2.1 E-SIDIF El Plan Estratégico de la UI 2002-2007 v. 3.1, vigente en el período auditado, no incluye el proyecto e-SIDIF. Como “adendum” al mismo, en agosto de 2005, el área de tecnología de la Página 22 UI elaboró un Plan 2005-2007 que prevé las adquisiciones en materia de infraestructura del hardware del nuevo producto. Los planes mencionados no se encontraban formalmente aprobados. 4.2.2 Calidad El Plan de Calidad de la UI contempla la adopción de CMMI (Capability Maturity Model of Integration) como modelo para la mejora de procesos. El proyecto ha adoptado RUP – Rational Unified Process–, un proceso de ingeniería de software integrado a un conjunto de herramientas de desarrollo. Efectos Sugiere una falta de unidad en la visión estratégica de los proyectos y en las metodologías de desarrollo. 4.3 Objetivo de Control: Organización del Proyecto Al ubicar el proyecto en la estructura organizacional general, la alta gerencia deberá asegurar que el departamento usuario tenga autoridad, actitud crítica e independencia en un grado tal que garantice soluciones de tecnología de información efectivas y progreso suficiente al implementarlas, así como establecer una relación de sociedad para incrementar la capacidad de previsión, la comprensión y las habilidades para identificar y resolver los problemas que puedan presentarse. 4.3.1 Separación de Funciones El Gerente del proyecto cumple también funciones como responsable máximo de las áreas usuarias del sistema. Efectos Al ser parte del proyecto, restringe la independencia necesaria entre usuarios y quienes deben desarrollar el sistema. 4.3.2 Aprobación El documento SI_ING_Organizacion Proyecto sobre la organización se encuentra en estado de elaboración y no ha sido aprobado formalmente. Página 23 Efectos Podrían (no están obligados) no asumir plenamente las responsabilidades descriptas. 4.4 Objetivo de Control: Comité de Dirección La alta gerencia de la organización deberá designar un Comité de planeamiento o dirección para vigilar el proyecto y sus actividades, con representantes de la alta gerencia, de la gerencia usuaria y de los servicios de información. Deberá reunirse regularmente y reportar a la alta gerencia. 4.4.1 Responsabilidad y Actas De acuerdo al documento de organización del proyecto, el Comité de Órganos Rectores, creado como dirección del SLU (SIDIF Local Unificado), tendría atribuciones con relación al e-SIDIF pero no formalmente. Sólo en una de las actas de las reuniones del Comité en el período auditado, se registra haber tratado cuestiones relativas al proyecto. Las actas entregadas a esta AGN no llevan firma de los participantes. Efectos El rol cumplido por el Comité, que se estima relevante para el proyecto, no está claramente definido. Los integrantes del Comité podrían (no están obligados) no asumir, con relación al e-SIDIF, las responsabilidades descriptas. 4.5 Objetivo de Control: Enfoque de Evaluación de Riesgos La Gerencia deberá establecer un enfoque general que defina el alcance, los límites y la metodología de la evaluación de riesgos, así como las responsabilidades y las habilidades requeridas. La calidad de la evaluación de riesgos deberá estar asegurada por un método estructurado y por asesores expertos en la materia. 4.5.1 Evaluación de riesgos El documento “Presentación reunión general 07-2005.ppt” y el caso de negocio identifican riesgos del proyecto en Tecnología, Contrataciones, la definición de los requerimientos y las acciones para mitigarlos. Página 24 No se hallaron procedimientos para la evaluación sistemática de los riesgos, en las etapas siguientes del desarrollo del proyecto. Por ejemplo: • No se realizaron contrataciones con la intervención de SIGEN y ONTI dentro del presupuesto asignado –programa 26–. Si bien se han mitigado a través del programa 18-FOSIP y la firma de convenios con Universidades para la contratación de personal informático, no se ha evaluado para este caso el riesgo residual. • No hubo una definición formal de los plazos de entrega del producto y no se evaluó la pérdida de credibilidad que puede generar. • No se tuvo en cuenta que coexistían bases y aplicativos del SIDIF Internet con las versiones del SIDIF central, SLU, OD y CONPRE. Efectos La falta de evaluación impide conocer las consecuencias que pudiesen presentarse. 4.5.2 Mediciones No se encontraron medidas cualitativas o cuantitativas de los riesgos. Efectos No se pueden asignar recursos en el orden correcto para mitigar los riesgos. 4.6 Objetivo de Control: Relaciones La Gerencia del Proyecto deberá llevar a cabo las acciones necesarias para establecer y mantener una coordinación, una comunicación y un enlace con los demás elementos interesados dentro y fuera del proyecto (usuarios, proveedores, oficiales de seguridad, gerentes). 4.6.1 Intervención de la ONTI La Subsecretaría de Presupuesto, entre noviembre de 2004 y enero de 2005, solicitó la que la ONTI emitiera opinión sobre dos contrataciones vinculadas al e-SIDIF. No se obtuvo respuesta y no se efectuaron reclamos. Página 25 No se tuvo evidencia de que la ONTI haya tenido otra intervención relativa a la supervisión del desarrollo del proyecto –una de sus funciones– durante el período 2004-2005. Efectos El órgano rector en materia informática no provee soporte oportuno al emprendimiento de alta complejidad encarado en el ámbito de su jurisdicción. 4.6.2 Comunicaciones Se detectó la carencia de un plan para el manejo de las comunicaciones internas y externas relativas al proyecto. El conocimiento del avance (los detalles) del proyecto se encuentra restringido a los niveles decisorios y la participación de los organismos es limitada aunque deberán decidir sobre la adopción del nuevo sistema. Efectos Falta de credibilidad del proyecto. El no comunicar adecuadamente los desafíos que se están asumiendo en materias tecnológica las áreas de la organización no se comprometen con el proyecto que se desarrolla y tampoco dan ideas o sugerencias. 4.7 Objetivo de Control: Presupuesto y Monitoreo La alta gerencia deberá implementar un proceso de definición para asegurar un presupuesto operativo anual para el proyecto. La Gerencia del Proyecto deberá establecer un proceso de monitoreo de costos que compare los costos reales y los presupuestados, incluyendo los posibles beneficios derivados de la actividad de tecnología de información que deberán ser identificados y reportados. En cuanto al monitoreo de costos, la fuente de las cifras deberá tomar como base el sistema de contabilidad de la organización y se deberá registrar, procesar y reportar rutinariamente los costos asociados con las actividades de la función de servicios de información. En cuanto al monitoreo de beneficios, se deberán definir indicadores de medición de desempeño de alto nivel y ser reportados y revisados regularmente. Página 26 4.7.1 Presupuesto y Contrataciones 1) Se detectó la carencia de un sistema para planificar y controlar todos los gastos que insume el proyecto. 2) Durante 2004 y parte de 2003, no hubo una partida específica a nivel de actividad dentro del presupuesto nacional para las contrataciones informáticas de consultores y consultorías. Por otra parte, la ONTI no ha tenido intervención en estas contrataciones. Efectos 1) No hay certeza sobre la inversión que demandará el nuevo producto. 2) No se ha facilitado la identificación de los gastos atribuibles al e-SIDIF. Sin la intervención de la ONTI se pierde soporte al proyecto. 4.8 Objetivo de Control: Marco de Referencia para la Administración de Proyectos La Gerencia deberá establecer un marco de referencia general para su administración que defina el alcance y los límites del Proyecto, así como la metodología de administración a ser adoptada y aplicada para cada proyecto emprendido. La metodología deberá cubrir, como mínimo, la asignación de responsabilidades, la determinación de tareas, la realización de presupuestos de tiempo y recursos, los avances, los puntos de revisión y las aprobaciones. 4.8.1 Cronograma 1) Se detectó la carencia de un cronograma vigente, formalmente aprobado, para todo el proyecto. 2) Finalización del Proyecto. No hay compromiso en cuanto a la fecha de terminación. Se tuvo acceso a dos documentos que lo sugieren, esto es: • El documento “Presentación reunión general 07-2005.ppt” (no formalizado) estima la finalización del desarrollo y testing de todas las aplicaciones previstas el 31/12/2007. No incluye los tiempos que demandará de las aplicaciones en los organismos. Al momento de la realización de esta auditoría los plazos estimados se encontraban superados. Página 27 • El próximo proyecto AR Governance 21 – Public Stregthening II del BIRF (FOSIP II) – que prevé financiar al SIDIF Internet– estima que el SLU será reemplazado por el nuevo sistema de administración financiera Web en 2010. 3) Se detectó carencias –no existen revisiones– para mejorar la metodología de estimación de tiempos en el marco de RUP y los recursos calificados disponibles en el proyecto. 4) Se tuvo conocimiento de la existencia de programación y seguimiento de tareas de muy corto plazo en las etapas de análisis, diseño y desarrollo y testing con un software de administración de proyectos, pero éste no los integra. 5) Se encontraron actividades, como las interfases, con otros sistemas sin planificación y organización. Los talleres funcionales disponen de una programación limitada a tres meses. En la evaluación de la convivencia con los SIDIF existentes hay actividades de detalle no planificadas. Efectos 1) No permite hacer previsiones a mediano ni a largo plazo. 2) No se dispone de un punto de control crucial para el proyecto. 3) Ello impide estimar con mejor precisión, detectar los puntos críticos y controlar el avance del proyecto. 4) No permite unir las planificaciones parciales como parte de la planificación general. 5) Las tareas no planificadas causan incertidumbre. Para el caso de las interfases externas, los tiempos de negociación con los organismos no son de fácil estimación. Ciclo de Vida del Sistema 4.9 Objetivo de Control: Estudio de Factibilidad La metodología del ciclo de vida de desarrollo de sistemas de la organización debe establecer por cada proyecto, implementación y modificación de sistemas de información propuesto un examen de la factibilidad tecnológica de cada alternativa para satisfacer los requerimientos del negocio y generar el análisis de los costos y beneficios asociados con cada una de ellas. Página 28 4.9.1 Caso de Negocio 1) De acuerdo a la documentación obrante, el caso de negocio se habría realizado con posterioridad a la decisión de contratar la definición del marco de arquitectura. Es decir, la decisión de iniciar el proyecto no habría sido consecuencia de la razonabilidad expresada por el caso. 2) Se detectó la ausencia del caso definitivo de negocio, previsto al cierre de los talleres que definirían el Modelo Conceptual. 3) Se enuncian los objetivos del proyecto pero no se obtuvo evidencia de que hayan sido evaluados contra alternativas de cambio y adoptados por su conveniencia técnica y económica. 4) Los beneficios esperados no están cuantificados. 5) Los costos estimados están basados en los puntos de función del sistema Local Unificado (SLU), cuya configuración es distinta del sistema en desarrollo. Se estiman tiempo y esfuerzo del desarrollo de software, es decir el costo de personal de desarrollo, pero no se incluyen los gastos de hardware e instalaciones, ni licencias de software y/o soporte del mismo. 6) No se establecen los criterios para evaluar el grado de éxito del sistema. Hay una referencia general en el documento “Visión Compartida”, como “la mejor manera para medir el resultado de la gestión significa el cumplimiento de las tres ‘e’: eficiencia, eficacia y economía en la gestión”. 7) El “Caso de negocio” no tuvo aprobación formal. Efectos El desarrollo de caso de negocio no aporta todo su potencial, que hubiera permitido una planificación más ajustada. 4.10 Objetivo de Control: Definición de Requerimientos de Información Los requerimientos del negocio ya satisfechos por el sistema actual y a ser satisfechos por el sistema nuevo propuesto o modificado (software, datos e infraestructura) deben estar Página 29 claramente definidos antes de aprobarse cualquier proyecto de desarrollo, implementación o modificación. La metodología del ciclo de vida de desarrollo de sistemas deberá exigir que los requerimientos de las soluciones funcionales y operacionales sean especificados, incluyendo desempeño, protección, confiabilidad, compatibilidad, seguridad y legislación. 4.10.1 Modelo Conceptual Resume la visión compartida de los principales miembros de los órganos rectores y personal de proyecto y de la UI. En su expresión práctica, el modelo conceptual establece los objetivos, características y aspectos técnicos del nuevo sistema. De su revisión resulta: 1) El modelo no establece restricciones o limitaciones. 2) El documento “Visión compartida del Modelo Conceptual” –noviembre de 2004– no contiene la aprobación formal de los participantes citados en el mismo (todos miembros de la Subsecretaría de Presupuesto). 3) El modelo conceptual actualizado en el documento “SI_VIS_Modelo conceptual” – noviembre de 2005– no ha sido aprobado formalmente y no se menciona a los participantes de esta nueva versión. 4) No se asignaron responsabilidades vinculadas a los usuarios funcionales para controlar, mediante un seguimiento, la coherencia entre el desarrollo del sistema y los requerimientos del modelo conceptual. 5) No se encontraron precisiones sobre el sistema en cuanto a la vida útil proyectada, el calendario de lanzamiento y su integración con los sistemas existentes. Efectos 1) El sistema no termina de definirse. 2) No representa una responsabilidad a asumir. 3) Junto con el punto anterior, indicaría que el Modelo continúa abierto a discusión, lo que podría afectar el ciclo de producción y la previsibilidad del proyecto. 4) Sin la debida aprobación, podrían alterarse los contenidos del documento. 5) Al no haber seguimiento, podrían dejarse de lado o postergarse objetivos especificados en el Modelo. Página 30 4.10.2 Marco de Arquitectura 1) Se habría sometido a control de calidad (QA) las entregas de la empresa contratada para la definición del marco. No se obtuvo evidencia de que las observaciones solicitadas por los revisores se hubieran realizado. 2) Los documentos QA no disponen de aprobación formal y aceptación final. Efectos El procedimiento de control de calidad no asegura una aprobación técnica final. 4.10.3 Desarrollo del Prototipo No hay registros de que se hayan sometidas a un proceso de control de calidad (QA) las entregas de la empresa contratada para su desarrollo. Efectos Pérdida de evidencia y control de que los cambios requeridos hayan sido realizados. 4.10.4 Talleres funcionales Los talleres se conformaron con personal de las áreas funcionales a los fines de capturar los requerimientos que corresponden a la fase Modelado del Negocio de la metodología RUP. Estos talleres se emplearon también para la definición del modelo conceptual. A la fecha del relevamiento se habían realizado 78 talleres correspondientes a los distintos negocios y subnegocios definidos. La actividad desarrollada por los talleres debe generar distintos productos, también denominados “artefactos”: Minutas de Requerimientos (MR), Línea de Base de Requerimientos (LBR), Descripción Funcional, Agenda, Calidad y Presentación. De nuestra revisión (21 de julio de 2006; ver cuadro en la siguiente página), la documentación desarrollada para definir el modelo de negocio presentaba una línea de producción no uniforme, lo que estaría mostrando cierta debilidad en su control. Página 31 Efectos La falta de cumplimíento de los estándares establecidos debilita al proyecto. Referencias del cuadro : X – Carece de la documentación. O – Contiene la documentación. Página 32 NEGOCIOS Minutas de Linea Base de Requerimient Requerimient os os Descripción Agenda Calidad Presentación Funcional Administración de Bienes Bienes de Consumo Bienes Inmuebles Bienes Muebles y Recepción Bienes y Servicios O X X X O O X O O O O X X X X X O X X X X O O O O O X X X X X O X X O O X O O X X X O O O O O X O X X X X O O O O O X O O O X X O O O O X X X X X X X O O O X X X O O O Deducciones Operaciones Regularizaciones Personal Gastos Figurativos Impuestos y Servicios Momentos del Gasto Remanentes Servicios de la Deuda Transferencias Comisiones Bancarias Gestión de Compras Sin Gestión de Compras O O X O O O O X O O O X X X O X X O O X X X O X O O X X X X X O X X X O X X X O O O O O O O X O O X X X X X X X O O O X O O O X X O O O X O O O X O O X X X No Presupuestarios Multifactura RRHH Desembolsos Externos Requerimientos X X X X X O O O X O X X X X X X X X X X X X X X X X X X X X X O X O O X X X X X X X X O X X O O O O X O X O O X O X O O Pasajes y Viáticos Presupuesto O O O O O X Comunicación de Clasificadores Presup. Anteproyectos Extra APN Escenarios Sluna Proyecto de Ley Relación con Bapin II Relación con PROA Relación con SIRHU Revisión de Av fisico y Salida de Información – Pres. Alcance de Aplicación del Sistema_Art Artículo 15 Ley 24156 Interfaz con Bapin II SIRHU Acto Administrativo AIF General Propuesta MP Facultades Delegadas MP SAF MP SLU ONP Programación y Cierre de Cuota Programación y Ejecución Física Formulación Presupuestaria O X X X O X X X X O O O X X X X X X X X O X X X X X X X X X X X X X X X X X X X O X X O X X X X X X X X X X X X X X X X X X X X X X X O X O O X X X X X O X X X X O X O X X X O X X O X X X X X X X X X X X X X X O O O X X X X X X X X O X X X X X X X X X X X X O X O X X X X X X O O X X X X X X X O X O X X O X X O X X X O O O O O O X O O O X X O X X X X O O O X O X O X X O O O X O X X O O O O O O O O X O O O X O X O X X X O X O X X O X X O X X X X X X X X X O X X X X X X X O X X Cambio de Ejercicio Compras Integración Sistemas ONC Momentos de Compras Plan Anual de Contabilidad Entes Fondos Rotatorios General Fondos Rotatorios (DF y DA) Constitución FR (Creación y Multimoneda Gastos Generales General General Inicial Centro de Costos Cierre MultiSAF y SubSAF Unidades Organizativas Recursos Humanos Tesorería Cesiones Conciliación Bancaria Cuenta Única del Tesoro Cuentas a Cobrar Fideicomiso General Medidas Afectación Patrimonial Pagos Pagos en Títulos Programación Financiera Recursos Remanentes Retenciones por OSIRIS Retenciones y Deducciones Embargos Uepex_Presupuesto Página 33 4.11 Objetivo de Control: Arquitectura de Información La Gerencia del Proyecto deberá asegurar que se tome en consideración el modelo de datos de la empresa al definir las soluciones y analizar su factibilidad. A) Arquitectura Lógica 4.11.1 Evaluación de la arquitectura Se detectó carencia de evaluación de la manera en que las decisiones vinculadas a la arquitectura permitirán alcanzar los objetivos de calidad del sistema (performance, disponibilidad, seguridad entre otros). Efectos No hay certeza sobre la manera en que la arquitectura diseñada mejorará los parámetros de calidad. Podrían producirse diseños inadecuados para los fines propuestos. A1) Componentes Básicos 4.11. 2 Guías y Especificaciones Las guías de especificación de la interfaz al usuario, no mencionan el cumplimiento de las recomendaciones de la W3C (World Wide Web Consortium) en materia de accesibilidad y las pautas para el diseño de los sitios Web gubernamentales (Resolución 97/97 Subsecretaría de Gestión Pública). Efectos Se podrían ver afectados el acceso y la facilidad de navegación. Podría limitar a los usuarios al exigir tecnologías de las que tal vez no disponen, o impedir la navegación de personas con limitaciones físicas. 4.11. 3 Documentación Se encontraron las siguientes debilidades de control: 1) Se detectó la inexistencia de la documentación de la componente de arquitectura Matrices y Criterios de impacto. Página 34 2) Se encontraron documentos de especificación de componentes que no cumplen con la norma respectiva (como Componente Rico, Convivencia. y otros). 3) Se detectó ausencia, para el período auditado, de controles del estado de situación de la documentación de arquitectura. 4) Quienes generan las normas de documentación –Ingeniería– controlan también su cumplimiento. Efectos 1) La documentación no queda registrada, de manera que no se encontraría disponible para su análisis, lo que puede afectar el normal desarrollo del proyecto. 2) No se cumple con la especificación preparada por el área Ingeniería del proyecto. 3) Se pierden registros para el seguimiento en forma cronológica de la documentación del sistema y de su control. 4) Falta de separación de funciones entre quienes desarrollan normas y el órgano de cumplimiento. 4.11.4 Pruebas (Testing) sobre Componentes La herramienta “Ítem”, que permite gestionar las entregas de testing y mejoras de componentes, dispone de información posterior al 31/12/05, según lo consignado a esta AGN. Con posterioridad a esa fecha, hubo 65 errores pendientes de corrección, 42 de los cuales correspondían al componente de seguridad. Efectos No se resolvieron los errores en el período previsto y por ende, algunos componentes no se encontraban totalmente operativos, lo que produjo desvíos en el cronograma. B) Arquitectura Física 4.11.6 Equipamiento en los SAF Se obtuvo evidencia de la existencia de un relevamiento de equipamiento realizado en los SAF que muestra el grado de desactualización del parque de PC. Página 35 Se detectó inexistencia de un estudio que estableciera los requerimientos mínimos de hardware y software requeridos por los SAF para operar el SIDIF Internet junto con las otras versiones (SLU, OD) durante el período de convivencia. Efectos Podría generar demoras en la implementación del sistema. 4.11.7 Performance 1) El proceso de análisis de la performance –especificación técnica y ejecución de las pruebas se inicia durante el desarrollo del primer módulo del e-SIDIF, formulación presupuestaria. 2) Se tuvo conocimiento de la conformación de un Comité de Performance pero no se habrían designado a sus integrantes. 3) Las planillas de resultado de las pruebas no especifican las características técnicas del entorno de prueba: tipo de computadora, tipo de conexión, entorno de compilación y las herramientas utilizadas. Efectos 1) Se realizan con posterioridad al desarrollo del prototipo y la elección de los distintos “framework” que configuran la arquitectura. Las posibilidades de mal desempeño son altas. 2) No se tienen registros de la actividad del Comité mencionado. 3) No generan un reporte completo que permita hacer una mejor evaluación de conjunto. 4.11.8 Disponibilidad del servicio 1) De acuerdo con el esquema actual, el tráfico de la red interna y externa del MECON, SIDIF incluido, se encuentra a cargo del área Proyecto Informático. No se tuvo conocimiento de acuerdos para asegurar un nivel de las prestaciones –o calidad de las comunicaciones– en el contexto que tendrá que operar el e-SIDIF. 2) Se detectó carencia de estudios de evaluación del ancho de banda u otro tipo de conexión que requerirá el nuevo SIDIF. Página 36 Efectos Al no estar planificados, pueden producirse problemas de disponibilidad ante la falta o pobre comunicación y, cuando menos, demoras en el despliegue del sistema. 4.11.9 Seguridad de la aplicación Web 1) Se detectó carencia de estudios sobre la definición y configuración de los “browsers” (visualizadores) que emplearía el cliente –SAF–. Por lo tanto, no se evaluaron sus vulnerabilidades, facilidades ni mecanismos de protección necesarios. 2) No se encontraron definiciones en la configuración del software de los equipos clientes para conectarse con el e-SIDIF. Efectos Debilidad en la planificación. Puede provocar demoras al proyecto. 4.12 Objetivo de control: Definición de interfases La metodología del ciclo de vida de desarrollo de sistemas de la organización debe estipular que se especifiquen, diseñen y documenten apropiadamente todas las interfaces internas y externas . 4.12.1 Integración 1) Se detectó inexistencia de una estrategia común para el manejo de todas las interfaces con otros sistemas y organismos. 2) No se encontraron las definiciones técnicas en la mayoría de las interfaces y los modos de comunicación requeridos por el nuevo sistema. Efectos Dado el número de las interfaces actuales –cerca de 13– y dado que muchas de ellas carecen de automaticidad y de seguridad (disquetes, planillas excel), se podría afectar la prestación del sistema. Página 37 Estrategia de Desarrollo 4.13 Objetivo de control: Evaluación de la estrategia Deberán establecerse procedimientos para evaluar el impacto de nuevo hardware y software sobre el rendimiento del sistema en general. 4.13.1 Convivencia Se detectó carencia de evaluación del impacto de la componente “Convivencia”. Se ha previsto un período de convivencia entre el SLU y el SIDIF Internet superior a los dos años. A los organismos que mantengan aún otras versiones como Conpre, SIDIF OD o desarrollos propios, también se les deberá proveer el mismo servicio. La complejidad de la convivencia presenta serios riesgos que exigirán un gran esfuerzo de mantenimiento. Algunos de los riesgos: • La nueva información que se produzca con el e-SIDIF no estará disponible para aquellos organismos que aún mantengan versiones anteriores y por lo tanto no se podrá contar con la agregación a nivel nacional. • Los usuarios enfrentarán dificultades al tener que operar dos sistemas con menús diferentes. • El costo de mantenimiento aumentará de manera significativa pues debe mantenerse una doble infraestructura de hardware, software y comunicaciones. • Se tuvo conocimiento de una metodología para calcular los riesgos de convivencia por cada módulo a implantar, aunque no se obtuvo evidencia de que se hayan evaluado esos riesgos a los fines de minimizarlos. Efectos Las tareas de convivencia podrían insumir una cantidad de tareas de gran detalle. Los recursos dedicados a esta tarea no están cuantificados, lo que impide controlarlos. Página 38 4.13.2 Escenarios 1) Se realizó una evaluación de escenarios candidatos con el fin de determinar un conjunto de funcionalidades a desarrollar e implantar como primera versión operativa del sistema eSIDIF. Para determinar el alcance de cada escenario, se parte de la premisa de que la funcionalidad a desarrollar sea igual o superior a la de los actuales sistemas. No debe admitirse que las funcionalidades en promedio sean iguales a la actual, pues los usuarios no comprenderán que se haya realizado un enorme esfuerzo sólo para producir lo mismo de que disponían antes. 2) El estudio concluye que el subnegocio Programación y Ejecución Física –del negocio Presupuesto– es el escenario que obtuvo mejor evaluación desde el aspecto funcional, menos riesgos de convivencia y menor complejidad en su arquitectura. No obstante, la elección de escenario dio prioridad al subnegocio Formulación Presupuestaria. 3) La evaluación ha considerado criterios técnicos como la facilidad del despliegue y la convivencia con las versiones existentes del SIDIF. Se detectó que las necesidades funcionales y de oportunidad de la Administración Financiera o de los Órganos Rectores no se fijaron como hitos para la elección de la primera versión o el desarrollo del sistema. Efectos 1) La credibilidad del proyecto no se refuerza. 2) Los cambios de estrategia se presentan como arbitrarios si no quedan registros de sus motivos. 3) Al no vincularse el desarrollo del sistema al calendario de la Administración Financiera, no se produce una buena integración (sinergia) entre la dinámica del proyecto y los resultados del “negocio” AFG (Administración Financiera Gubernamental). Página 39 4.13.3 Necesidades de los Usuarios de los SAF El e-SIDIF ha sido definido por los órganos rectores que son sus usuarios. Sin embargo, no prevé las necesidades de los SAF. como la mayor desagregación de sus registros y obtención de resultados orientados a su gestión. Los usuarios del SAF no habrían tenido una participación significativa en las etapas de modelado conceptual y la captura de requerimientos. El Comité de Usuarios SLU habría tenido, con relación al e-SIDIF, una actividad informativa. Efectos No contribuye a definir los límites del e-SIDIF y los sistemas de los SAF. La gestión de los sistemas del organismo no se puede integrar al nuevo entorno del SIDIF. 4.13.4 Metodologías El desarrollo se ajusta a la metodología RUP y disposiciones en la materia del MECON pero no asegura tener en consideración las normas ETAPS y la Resolución 97/97 emitidas por la ONTI, particularmente en cuanto a desarrollo de software y pautas para sitios y portales Web. Efectos Podrían estar comprometidas la accesibilidad y la normativa obligatoria para los sitios Web del Estado nacional. 4.13.5 Integración de las herramientas de desarrollo Se han incorporado herramientas para el desarrollo de software que mejoran la generación de los distintos artefactos de construcción del producto. La herramienta de software que gestiona el seguimiento de las entregas de análisis, diseño, desarrollo y testing, no garantiza que los artefactos de análisis y diseño desarrollados se encuentren en las condiciones señaladas por ella y por lo tanto deben estar sujetos a verificación. Tanto la “minuta de requerimientos” como el “prototipo de interfaz de usuario” se desarrollan en ambientes diferentes a la herramienta UML para el análisis y diseño. Efectos Las herramientas no integradas no proveen certeza de la veracidad de sus registros en la medida en que requieren de instancias manuales (por ejemplo, ingresar a otra aplicación). Página 40 5. ANÁLISIS DE LA VISTA Por Nota Nº 21/07-A5 de fecha 19 de marzo de 2007 se remitió en vista al Organismo copia del presente informe. Por expediente S01:0118089/2007 del 11 de Abril de 2007 la Subsecretaría de Presupuesto solicita una prórroga para realizar el descargo. La Auditoría General de la Nación, la concede mediante Nota N° 36/07-A05 del 23 de abril de 2007. La Secretaría de Hacienda realiza el descargo en su Nota SH Nº 232-07 del 6 de junio de 2007. Con el análisis del descargo se ha producido una modificación en el ítem de la observación 4.10.1. punto 4. El detalle de las respuestas del organismo y comentarios de la AGN se encuentran en el Anexo adjunto. Página 41 6. RECOMENDACIONES Ambiente de Control 6.1 Objetivo de Control: Participación Proactiva de Auditoría 6.1.1 Auditoría independiente Requerir control y asistencia técnica externa al proyecto que ayude a detectar tempranamente el nivel de riesgo de los temas, particularmente de aquellos no previstos, críticos o aquellos que se salgan de control. Dada la complejidad del proyecto, se sugiere incorporar auditorias que verifiquen el diseño de controles internos en el sistema (la DAS dispondría del “ expertise”) y emitan opinión sobre la gestión del proyecto. 6.2 Objetivo de Control: Cambios al Plan Estratégico 6.2.1 E-SIDIF 1) Elaborar un Plan estratégico previamente aceptado por los principales responsables del proyecto y de la UI. 2) Aprobar formalmente el Plan. 6.2.2 Calidad Definir en el plan de calidad el modo en que las dos visiones se integran y aprobarlo formalmente. 6.3 Objetivo de Control: Organización del proyecto 6.3.1 Separación de Funciones Se sugiere incorporar un responsable en la Gerencia de Proyecto con dedicación exclusiva y con importante experiencia en los aspectos funcional y sistémico. A los fines de incrementar el compromiso, se sugiere evaluar la conveniencia de: 1) Designar al Comité de Dirección para el proyecto como el órgano de máximo nivel. Página 42 2) Incluir en la estructura del proyecto a los responsables operativos (funcional y de sistemas) de los talleres. 6.3.2 Aprobación Aprobar formalmente las funciones y responsabilidades de la organización que se definan para el proyecto. 6.4 Objetivo de Control: Comité de Dirección 6.4.1 Responsabilidad y Actas Designar formalmente al Comité de Dirección y establecer los procedimientos para su funcionamiento. 6.5 Objetivo de Control: Enfoque de Evaluación de Riesgos 6.5.1 Identificación de riesgos Establecer un marco para la evaluación sistemática, la metodología y cuantificación de los riesgos del proyecto así como designar los responsables de llevarlos a cabo. 6.5.2 Mediciones Ver 6.5.1. 6.6 Objetivo de Control: Relaciones 6.6.1 Intervención de la ONTI Se sugiere elaborar una estrategia para obtener un aporte significativo del órgano rector en materia informática. 6.6.2 Comunicaciones Para proveer mayor transparencia y credibilidad al proyecto se estima conveniente desarrollar un plan que: • Estratifique las audiencias –incluso público en general y proveedores–. • Elabore los canales de comunicación adecuados. Página 43 • Evalúe la conveniencia de crear un sitio específico para mantener adecuadamente informada a toda la audiencia. . 6.7 Objetivo de Control: Presupuesto y Monitoreo 6.7.1 Presupuesto y Contrataciones 1) Definir procedimientos para la previsión, ejecución y control –monitoreo– de los gastos del proyecto. 2) Se sugiere dar participación (no vinculante) a la ONTI en las contrataciones del proyecto provenientes de partidas con fuente de financiamiento externa. 6.8 Objetivo de Control: Marco de Referencia para la Administración de Proyectos 6.8.1 Cronograma 1 y 4) Establecer un marco para la administración del proyecto y, dentro de él, definir, ejecutar y controlar los cronogramas detallados en los distintos niveles y áreas del mismo y su integración en el cronograma general. 2) Proveer una visión única del avance, cumplimiento de las metas propuestas y su fecha de finalización del proyecto. 3) Desarrollar procedimientos para la disciplina de Administración de Proyectos de RUP, en particular para mejorar la estimación de tiempos. 5) A los fines de ponerlos bajo control, programar y organizar asignando responsabilidades, de manera compatible con el programa general. Ciclo de Vida del Sistema 6.9 Objetivo de Control: Estudio de Factibilidad 6.9.1 Caso de Negocio 1) a 5) Para nuevos proyectos, se considera conveniente generar guías y especificaciones para el desarrollo de aplicaciones que permitan una planificación más certera. Página 44 6) Definir los parámetros necesarios para medir si el sistema alcanzó sus objetivos. 7) Aprobar formalmente lo producido en 1). 6.10 Objetivo de Control: Definición de Requerimientos de Información 6.10.1 Modelo Conceptual 1) a 4) Es importante definir las restricciones del sistema, por lo menos, hasta su puesta en producción. Aprobar formalmente el modelo adoptado y designar un responsable que coordine la verificación del cumplimiento de los requerimientos. 5) Proveer precisiones macro del nuevo sistema: vida útil proyectada, calendario de lanzamiento, integración con los sistemas nacionales y de los organismos. 6.10.2 Marco de Arquitectura 1) y 2) En los estándares de calidad (QA), establecer de qué modo se formalizan los documentos y cómo se cierra el ciclo de aprobación. 6.10.3 Desarrollo del Prototipo No hay recomendación. 6.10.4 Talleres funcionales Reforzar el control para lograr una producción homogénea del conjunto de los artefactos de software. 6.11 Objetivo de Control: Arquitectura de Información A) Arquitectura Lógica 611.1 Evaluación de la arquitectura Tomar como referencia el método ATAM desarrollado por el SEI (Software Engineering Institute). A1) Componentes Básicos 6.11.2 Guías y Especificaciones Incorporar a la guía de especificación del usuario el cumplimiento de la normativa Web de la ONTI y las recomendaciones de la W3C. Página 45 6.11.3 Documentación Establecer un procedimiento de control que permita conocer periódicamente el estado de documentación. Generar una instancia de control independiente del creador del documento. 6.11.4 Pruebas (Testing) sobre Componentes Minimizar los errores en las etapas de pruebas. B) Arquitectura Física 6.11.6 Equipamiento en los SAF Planificar la definición de las características del HW y SW de los SAF, necesarios para operar el e-sidif. Emitir una especificación técnica al respecto y comunicarle a cada SAF. 6.11.7 Performance Asegurar una correcta calibración (“tuning”) del Sistema Operativo Linux. Medición de tiempos por cada caso de uso y/o proceso. Documentar el entorno técnico de la prueba. Analizar/evaluar técnicamente el ancho de banda y el tráfico de la red con el Área Proyecto Informático y cada SAF. Ver ETAP-3 V.12/2005 modelo 7 (contratación servicio full Internet de la ONTI-SGP). Tener en cuenta que una aplicación Web se ve afectada por varios factores para el acceso a la base de datos, como ser: enlace utilizado, seguridad, capacidad de procesamiento de los servidores, sistemas operativos utilizados y tiempo de respuesta de cada transacción. 6.11.8 Disponibilidad del servicio 1) Lograr la participación formal del área Proyecto Informático en las reuniones sobre los temas que le competen y alcanzar acuerdos formales en cuanto a las prestaciones a brindar. 2) Incorporar en la planificación la realización de los estudios sobre la banda ancha necesaria. 6.11.9 Seguridad de la aplicación Web Tomar medidas preventivas con la evaluación. Página 46 6.12 Objetivo de control: Definición de interfases 6.12.1 Integración Definir una estrategia técnica, y políticas que sustenten la integración del e-SIDIF con otros sistemas de la Administración Pública. Designar un coordinador con dependencia del Gerente de Proyecto –dada la relación con otros organismos– para el manejo de las interfaces. Estrategia de Desarrollo 6.13 Objetivo de control: Evaluación de la estrategia 6.13.1 Convivencia Evaluar, con mayor detalle, los problemas funcionales e informáticos que se pudieran derivar de una convivencia que se prevé prolongada. Evaluar alternativas para reducir ese lapso. 6.13.2 Escenarios 1) Proveer mayor explicación de la prestación que brindará el nuevo sistema, incluyendo las funcionalidades. 2) Proveer explicación de los cambios adoptados, dejando adecuado registro y responsabilidad de ellos. 3) Vincular la dinámica y los tiempos de la AFG a los logros a alcanzar por el sistema. Página 47 6.13.3 Necesidades de los Usuarios de los SAF Proveer definiciones para las vinculaciones de los sistemas de los SAF con e-SIDIF. 6.13.4 Metodologías Incorporar a los planes de diseño la normativa de las ETAP para desarrollo de portales y resolución 97/97 de la Subsecretaría de Gestión Pública. 6.13.5 Integración de las herramientas de desarrollo Planificar, previa evaluación de su factibilidad y conveniencia, la integración de las herramientas para el análisis, diseño y desarrollo, testing y versionado. Página 48 CONCLUSIONES Los estudios para desarrollar el e-SIDIF comenzaron a mediados de 2003, y a fines de 2005 (período auditado) se encontraba en la fase de diseño del primer módulo Formulación Presupuestaria. En ese lapso, el proyecto produjo principalmente la nueva arquitectura que soportará la aplicación en un entorno que le permitirá realizar transacciones vía Internet. Los gastos de desarrollo durante 2004 y 2005 ascendieron a 4.191.351,69 pesos. El proyecto introduce cambios sustanciales en el modo de concebir el sistema, desde el concepto de la arquitectura como un activo de largo plazo al empleo de nuevas prácticas metodológicas como el caso de negocio, el marco de desarrollo RUP (Rational Unified Process) para la generación de estándares y guías, control de calidad en los procesos, herramientas de software para producir los “artefactos” que requiere la aplicación durante el ciclo de vida, un empleo extensivo de software de código abierto con el aporte de centros especializados en TI de universidades nacionales. En el mercado argentino no hay experiencia madura en algunas de estas prácticas. El proyecto ha dedicado esfuerzo y tiempo en adquirirlas recurriendo en la primera etapa al expertise de consultoras privadas. En este período el proyecto no ha contado con la participación de la ONTI, órgano rector, ni con la intervención formal de la Dirección de Auditoría de Sistemas con competencia en el control interno del SIDIF. Nuestro análisis ha encontrado debilidades que no colaboran a disponer de un mejor control del proyecto: en primer término, la ausencia tanto de un cronograma general que lo guíe como de un sistema para la planificación y control de todos los gastos. Ello genera interrogantes respecto del costo final, la duración y el nivel de avance del e-SIDIF. En lo concerniente a la arquitectura, la introducción de un método para su evaluación permitirá monitorear su eficacia y diseño en relación con objetivos de calidad –como performance, disponibilidad y seguridad– que actualmente no es posible garantizar. Página 49 En cuanto al sistema, se considera necesario: a) definir una metodología que permita establecer y medir su grado de éxito; b) encarar la definición de sus límites sobre, entre otros, la integración con los sistemas de los SAF, el ciclo abierto de iteraciones sobre los requerimientos funcionales y la programación de las tareas relativas a las 13 interfaces con sistemas externos. Con el objetivo de asegurar el éxito del e-SIDIF, se sugiere mejorar el proyecto en cuanto al control de los temas mencionados en este informe y en el logro de mayor respaldo, en este caso, procurando fluidez en la relación con los organismos con los que interactuará –para intercambiar experiencias o bien para tomar decisiones– y con los órganos de control de competencia del Ministerio de Economía –particularmente en la identificación de riesgos y el diseño de controles–. El nuevo paradigma que se plantea con el software de código abierto requerirá una organización adecuada para realizar las adaptaciones que se requieran y solucionar las vulnerabilidades que se presenten. Es necesario capitalizar la experiencia adquirida en este proyecto en materia de arquitectura para beneficio de la Administración Pública en general. Ello requerirá de una participación activa de la ONTI y políticas del proyecto al respecto. Página 50 6. LUGAR Y FECHA DE LA EMISIÓN DEL INFORME: Buenos Aires, diciembre de 2006 FIRMA: Página 51 ANEXO RESPUESTAS DE LA SECRETARÍA DE HACIENDA Y COMENTARIOS DE LA AGN. Se incorporan los señalamientos expresados por la Secretaría de Hacienda a través de la coordinación del Proyecto e-Sidif, en respuesta a las observaciones planteadas por esta AGN en el punto 4 del presente informe. 4.1 Objetivo de Control: Participación Proactiva de Auditoría. Respuesta de la Secretaría de Hacienda: Se solicita que el proyecto cuente con un análisis independiente, de una auditoría, que evalúe cada solución tecnológica desarrollada, antes de su implementación. Las decisiones tecnológicas estructurales ya se han tomado: con la empresa externa “Idea Factory” generamos el Marco de Arquitectura, y con “Cubika” se ajustó dicho marco, se construyó un prototipo, y se realizó una prueba de carga, lográndose como producto una arquitectura candidata, tal como es mencionada por la metodología RUP. Luego la consultora “Hexacta” continuó con el desarrollo de otros componentes estructurales. Hemos contado, desde enero de 2005, con el soporte de expertos del “Lifia” quienes nos han guiado en la evaluación de las decisiones tecnológicas estructurales propuestas, y específicamente en este momento del proyecto las decisiones son solo extensiones a dichos componentes estructurales. No obstante, tendremos en cuenta la recomendación en el caso que surgieran componentes estructurales necesarias para futuras etapas, como por ejemplo la de ‘workflow’, para convocar consultores externos a fin de contar con el análisis independiente sugerido. Página 52 4.1.1 Auditoría independiente. Se tendrá en cuenta la recomendación. Comentario de AGN: La referencia a las empresas mencionadas no configura, en sentido estricto, una evaluación independiente de las soluciones elegidas pues participaron en el diseño de la arquitectura. 4.2 Objetivo de Control: Cambios al Plan Estratégico. Respuesta de la Secretaría de Hacienda: Las autoridades integrantes del Comité de Sistemas han solicitado a la Unidad Informática de Hacienda la confección de un Plan de Infraestructura que incluya los requerimientos del Proyecto e-Sidif. Se ha elaborado la información pertinente como insumo a la elaboración de dicho plan. 4.2.1 E-SIDIF. Respuesta de la Secretaría de Hacienda: El informe enviado oficialmente al BAPIN en el año 2005 contó con la aprobación formal de las autoridades. No obstante, tomaremos en cuenta la recomendación de obtener la aprobación expresa de los planes integrales. 4.2.2 Calidad. Respuesta de la Secretaría de Hacienda: En relación con este comentario, queremos destacar que, de acuerdo con nuestro entendimiento, no hay de ninguna manera una falta de unidad en la visión estratégica, ya que se trata de dos modelos de características diferentes que pueden usarse de manera complementaria. Página 53 CMMI es un modelo que ayuda a las organizaciones a mejorar sus procesos de desarrollo, poniendo el foco en la madurez de esos procesos (el grado en que están documentados, que son medibles y que son efectivamente usados). CMMI no es un modelo que indique qué metodologías, notaciones, herramientas o técnicas deban utilizarse, sino que plantea requerimientos que deben cumplir los procesos para considerarse maduros, y así mejorar la capacidad de los procesos de la organización (su rango de resultados esperados). Una organización que aplique CMMI puede usar RUP, metodologías estructuradas, métodos formales o cualquier otra metodología / técnica sin que esto represente un problema. RUP es un framework metodológico, es decir un marco que permite determinar la forma en la que se va a ejecutar un proceso de desarrollo, incluyendo en este caso recomendaciones específicas sobre técnicas y modelos a usar, como por ejemplo el UML como estándar de modelado y diferentes templates para la documentación del proyecto. El proveedor IBM, a través de su adquirida Rational Software, provee herramientas integradas con RUP; sin embargo, la implementación de RUP en una organización puede hacerse sin problemas con herramientas alternativas, en la medida en que se respeten sus recomendaciones sobre técnicas de modelado a utilizar y otros componentes. La adopción de RUP, como lo indican múltiples reportes, implica un cumplimiento de varias de las prácticas de CMMI. Esto significa que usar RUP implica cumplir con CMMI, representando esto la característica complementaria de los modelos. Por ejemplo, esto puede verse en el reporte que puede encontrarse en: http://www128.IBM.COM/DEVELOPERWORKS/RATIONAL/LIBRARY/5318.THML. Este reporte de IBM, titulado "Enhancing RUP for CMMI compliance: A methodological approach" ó “Aumentando RUP para cumplir con CMMI: una aproximación metodológica", dice lo siguiente en su introducción: "IBM Rational Unified Process®, or RUP®, provides an outstanding foundation that allows Unisys to achieve a higher level of process capabilities in many different CMMI process areas", es decir que RUP provee el basamento que permite a Página 54 una organización alcanzar niveles más altos de capacidad de procesos en varias áreas de proceso de CMMI. El propio sitio del Software Engineering Institute (SEI), organismo responsable por el CMMI, tiene un reporte sobre el tema, que puede encontrarse en: WWW.SEI.CMU.EDU/CMMI/ADOPTION/PDF/RUP.PDF. Este extenso reporte tiene una conclusión contundente en su parte final, donde puede leerse: "RUP y CMMI se complementan para alcanzar una organización de desarrollo de software madura" En consecuencia, podemos ver que tanto los autores del CMMI como los responsables del RUP coinciden en que los modelos son complementarios y pueden usarse de manera combinada. Comentario de AGN: (relativos a 4.2.1 Y 4.2.2) Se ha observado que definiciones de envergadura como el proyecto Sidif Internet así como la adopción de RUP no han sido previstos en los planes estratégico y de calidad vigentes. Ello podría deberse, entre otros motivos, a la falta de acuerdo entre diferentes concepciones estratégicas o desactualización de los planes. Cualquier proceso de calidad seguramente coincidirá, en parte, con CMMI y con mayor énfasis, RUP hasta un cercano nivel 2 cuando se utiliza todas las funcionalidades de la herramienta “Enterprise Architect”. Lo que se está sugiriendo es planificarlo primero como parte del Plan de Calidad y luego establecer cómo se arribará al nivel 3 inicialmente previsto. 4.3 Objetivo de Control: Organización del Proyecto. 4.3.1 Separación de Funciones. Respuesta de la Secretaría de Hacienda: 1) Entendemos que no aplica esta observación dado que la metodología empleada ha sido, y es, llevar a cabo talleres con las áreas usuarias para definir los requerimientos. Esta Página 55 metodología asegura su participación, y la atención de sus requerimientos. No se considera que carezcan de independencia como para poder sostener sus pedidos en relación al sistema en desarrollo. El Comité de Sistemas, como máximo responsable, actúa como patrocinador del proyecto delineando las políticas que lo guían, y facilitando los recursos estratégicos como para cumplir con los objetivos propuestos. Cada miembro de dicho Comité, por su función y rango, tiene a su cargo responsabilidades y obligaciones ineludibles, relacionadas con la Ley de Administración Financiera, y recursos como para cumplirlos. Si así no sucediere serían pasibles de las observaciones y medidas que la organización tenga previstas para quienes no cumplan con sus responsabilidades asignadas. De todas maneras cabe destacar que los funcionarios convocados para integrar dicho Comité lo han sido por su cargo, y no por las funciones que llevan a cabo. Para el caso de los integrantes específicos del proyecto, del área informática, se hallan definidos Términos de Referencia en los cuales se detallan las obligaciones que deben cumplir, y es por eso que mediante sus respectivos contratos quedan formalmente obligados a cumplir con las responsabilidades asignadas. La recomendación (1) mencionada en el punto 6.3.1, de página 41, correspondiente a este punto 4.3.1. sugiere incorporar un responsable en la Gerencia del Proyecto con dedicación exclusiva y experiencia en los aspectos funcional y sistémico: esa es justamente la tarea del actual rol de Coordinación General, dependiente del Gerente del Proyecto. Respecto a la recomendación (2), de la inclusión de los responsables operativos (funcional y de sistemas) de los talleres, en estas reuniones de Comité, cabe aclarar que ya participan: es el caso de los coordinadores –referentes principales asignados en cada Organo Rector– que asisten junto con sus directores. Tomamos además las sugerencias expresadas en el punto 6.3.2. de formalizar las responsabilidades mencionadas del Comité, y las restantes del proyecto. Página 56 Comentario de AGN: 1er párrafo. Los talleres constituyen un nivel operativo esencial pero se consideran solo como insumo. Lo que se está sugiriendo con la observación y recomendación es, 1) proveer a las áreas usuarias de mayor incidencia en el control del proyecto pues la dependencia de las mismas al Gerente del Proyecto actual la inhibe. 2) que funciones como la gestión de los objetivos generales, las relaciones con los usuarios así como la programación y el presupuesto sean asumidas por la Gerencia aliviando así a la Coordinación Técnica para que se concentre en el producto. 3) que la mediación de conflictos se pueda dirimir en una instancia superior, como ser la Subsecretaría de Presupuesto. 2do párrafo se considera respuesta al punto 4.3.2 y 4.3.4 3er párrafo se considera respuesta al punto 4.3.2 4.3.2 Aprobación. Respuesta de la Secretaría de Hacienda: El documento mencionado, “SI_ING_Organización Proyecto.doc”, fue presentado al Gerente de Proyecto y al Comité de Sistemas para su aprobación. Tomamos entonces la recomendación de formalizar dicha aprobación, pero no compartimos los efectos mencionados respecto a al cumplimiento de las responsabilidades descriptas. Consideramos que las responsabilidades asignadas, tanto de funcionarios como de contratados, están claramente definidas, tal como hemos mencionado en el punto anterior punto 4.3.1. Comentario de AGN: Durante el período del relevamiento esta auditoría solicitó una entrevista con el Secretario del Comité, éste se excuso pues limitó su responsabilidad a SLU lo que confirmaría lo indicado en los “efectos”. Página 57 Los términos de referencia representan las obligaciones del personal contratado y logros puntuales dentro del período, no resultan suficientes para determinar las misiones, funciones y responsabilidades del proyecto. 4.4 Objetivo de Control: Comité de Dirección. Respuesta de la Secretaría de Hacienda: Estas son funciones asignadas al Comité de Sistemas, el cual se reúne regularmente los días lunes. Tal como se menciona en el punto “3.2.5.1 Etapas del Proyecto”, las autoridades de los Organos Rectores realizaron un taller en Octubre de 2003 para tratar los temas estratégicos del proyecto, y pugnar por el logro de una visión compartida. En esa reunión se trató específicamente cual sería la estructura del proyecto, su seguimiento, roles y responsabilidades, incluso la lógica de la organización de los talleres con plena participación de los usuarios referentes de cada área involucrada. 4.4.1 Responsabilidad y Actas. Respuesta de la Secretaría de Hacienda: En carpetas compartidas accesibles por todos los integrantes del proyecto, técnicos y de áreas usuarias, incluyendo el Comité de Sistemas, se dispone toda la información del mismo, incluidas las minutas de las reuniones de avance, cronogramas, acuerdos, entre otros documentos. Aún cuando pueda no contarse con las firmas expresamente realizadas sobre los informes de avance, las responsabilidades están claramente asumidas. No obstante, tomamos nota de la sugerencia y procuraremos el conforme expreso y manifiesto de quienes corresponda. Comentario de AGN: No se tiene evidencia suficiente sobre la participación del Comité en el desarrollo de e-sidif y aplica al caso lo indicado en el comentario 4.3.2. Página 58 4.5 Objetivo de Control: Enfoque de Evaluación de Riesgos. Respuesta de la Secretaría de Hacienda: Tal como consta en el documento al que se hace referencia en el punto “4.5.1. Evaluación de riesgos”, se identificaron los riesgos agrupándose en: Tecnología, Contrataciones y Definición de Requerimientos, habiéndose llevado a cabo las acciones que los mitigaron. Esto se ha presentado en reuniones generales de proyecto en Julio de 2005. Con posterioridad a la presentación mencionada se continuó con el monitoreo de dichos riesgos en cada decisión del avance del proyecto que los incluyera, y revisando las acciones correspondiente para mitigarlos. Dicho monitoreo aplica tanto para las decisiones al alcance del equipo de proyecto, como a los integrantes del Comité que se reúne los días lunes a) A julio de 2005, estos han sido los riesgos y sus acciones de mitigación: Tecnología ü Capacitación del personal ü Mentoring para el desarrollo de las tareas ü Desarrollo de un “piloto” para cada actividad nueva que se encara ü Escalonamiento progresivo de la internalización de la tecnología ü Intercambio de experiencias con otros organismos que tienen experiencia en la arquitectura seleccionada ü Seguimiento de las pautas metodológicas recomendadas por las buenas prácticas ü Evaluación temprana del escalamiento de la arquitectura Gestión de las contrataciones ü Frente a este riesgo las acciones que se pueden tomar son limitadas dado que el trámite circula por distintos ámbitos: ONTI, SIGEN y áreas administrativas Página 59 del Ministerios ü Se planea acciones pro-activas respecto a los organismos que intervienen solicitando anticipadamente reuniones para promover el análisis de los pliegos. ü Compras relacionadas con la instalación de los nuevos puestos de trabajo del 8° piso Definición de los requerimientos ü Estos riesgos se minimizan a través del compromiso de participación de los Órganos Rectores y una adecuada administración de los requerimientos soportada por herramientas de documentación y seguimiento ü Las herramientas para el seguimiento ya han sido seleccionadas ü El compromiso de los Órganos Rectores es responsabilidad del Comité del Proyecto (Comité de Sistemas) Con el avance del proyecto hemos ido tomando acciones antes descriptas, tal como es el caso de los siguientes ejemplos: Tecnología: • Capacitación del personal. Según puede verse en el documento referido,“SI_AgendaCapacitaciónDic2006.doc”, hemos realizado capacitación para todo el plantel, en forma regular; • Escalonamiento progresivo de la internalización de la tecnología. Por disciplina y grupos de trabajo hemos ido avanzando en, por ejemplo, la implementación de las disciplinas de la metodología RUP; • Intercambio de experiencias con otros organismos que tienen experiencia en la arquitectura seleccionada. Es el caso de la AFIP, dado que ellos, al igual que nosotros, están trabajando Página 60 con una arquitectura J2EE; • Seguimiento de las pautas metodológicas recomendadas por las buenas prácticas. Luego de cada hito significativo, por ejemplo un pasaje a producción que presenta inconvenientes, se realizan talleres de Lecciones Aprendidas para revisar los detalles de lo actuado, y capitalizar experiencia para futuras situaciones; • Evaluación temprana del escalamiento de la arquitectura. Con las ‘Pruebas de Carga’ que realizamos antes de cada implementación de nuevas funcionalidades, realizamos estas pruebas para prevenir problemas productivos, y gestionar todos los cambios tecnológicos y de arquitectura que resulten necesarios. Gestión de las contrataciones ü Frente a este riesgo las acciones que se pueden tomar son limitadas dado que el trámite circula por distintos ámbitos: ONTI, SIGEN y áreas administrativas del Ministerios La Subsecretaría de Presupuesto se ha ocupado de contactar a los responsables de estas áreas a fin de consensuar mejoras posibles a los circuitos involucrados; ü Se planea acciones pro activas respecto a los organismos que intervienen solicitando anticipadamente reuniones para promover el análisis de los pliegos. Idem anterior ü Compras relacionadas con la instalación de los nuevos puestos de trabajo del 8° piso. Ídem anteriores, y como ejemplos tenemos la obtención de espacios para los Página 61 equipos de Sistemas como el 8º Piso, el 4º y recientemente el 3º; Definición de los requerimientos ü Estos riesgos se minimizan a través del compromiso de participación de los Órganos Rectores y una adecuada administración de los requerimientos, soportada por herramientas de documentación y seguimiento ü Las herramientas para el seguimiento ya han sido seleccionadas ü El compromiso de los OR es responsabilidad del Comité del Proyecto (Comité de Sistemas) En estos tres casos, dado que hubo demoras por bajo nivel de implicación en el proyecto por parte de los OR’s, y en particular por lo referente a la definición de los requerimientos, se intensificaron las medidas de sensibilización de los mismos por parte de los funcionarios del citado Comité. Este período de inconvenientes ha sido el comprendido entre Agosto y Octubre de 2005. b) En el documento de Octubre del 2005 presentado al Comité, se incluyó la estrategia para el año 2006, y en ella se presentan los riesgos enfocados en cuatro puntos de vista, agregándose riesgos del personal. Del mismo modo se expresa en dicho documento que es objetivo de la Subsecretaría implementar el negocio de Presupuesto, y se menciona que tareas críticas del usuario impiden la participación comprometida. Ante esto se vuelve a convocar su participación, compromiso y esfuerzo al presentar los UCP’s (Use Case Points: método de estimación por ‘Puntos de Casos de Uso’), estimados por subnegocio (Formulación Presupuestaria y Modificación Presupuestaria): “El esfuerzo de todos los que intervienen en el proyecto es proporcional a los UCP”, ó “Todos los participantes deben comprometerse con el cronograma que se acuerde para lograr el objetivo”. Página 62 Los riesgos, en esta reunión de Octubre de 2005, se presentan de este modo: • Enfocados en: El negocio: FOP • FOP es crítico para la ONP • El usuario está muy familiarizado con el sistema actual • Las re-planificaciones provocan fechas de entrega del producto muy ajustadas que requieren fuerte participación del usuario MP • Se puede implementar en cualquier momento del año • Reemplaza un módulo del Sidif carácter • Enfocados en: El usuario: • Que las tareas propias del OR impidan la participación requerida en la definición de los requerimientos detallados y las pruebas de aceptación El equipo del proyecto: • Alta demanda en el mercado de perfiles de la tecnología utilizada – J2EE • Riesgo de pérdida de recursos críticos •Enfocados en: El equipo de Mantenimiento SC/SLU • Disponibilidad para participar en la definición y desarrollo de la convivencia de sistemas vigentes y e-SIDIF • Internalización de la nueva tecnología para incorporarse al mantenimiento del Página 63 nuevo producto El área técnica • Alta demanda en el mercado de perfiles técnicos: DBA, especialistas en comunicaciones, administradores en servidores de aplicación, etc., • Riesgo de pérdida de recursos críticos También se incorpora mención a riesgos relacionados con la Convivencia, la cual debe enfocarse de manera que: • Minimice el tiempo total del proyecto • Contemple el concepto de “usabilidad” – facilidad y transparencia para el usuario • Con esas premisas deben trabajar los equipos informáticos • El equipo del proyecto presentará el plan de trabajo para el desarrollo de la convivencia a los equipos de Mantenimiento SC/SLU y área técnica Si bien hemos mencionado el riesgo ‘Definición de los requerimientos’, y su estado a julio y octubre de 2005, nos parece pertinente destacar algo más en relación con las tareas realizadas por los Órganos Rectores (OR’s): • Incrementar la asignación de recursos humanos a las tareas de definición funcional; • Conformar un equipo multidisciplinario con participación de cada OR, para coordinar el proceso de definición de requerimientos; • Realizar una reunión de monitoreo los días viernes. En estas reuniones los integrantes del equipo multidisciplinario junto con los responsables de la planificación de actividades revisan los cronogramas de talleres funcionales, se informan los avances producidos en la semana, se destacan los pendientes a resolver y se genera la agenda de actividades para la semana siguiente. Finalmente, y no obstante todo lo expresado, tomamos la recomendación y analizaremos de Página 64 que modo podría ayudarnos un asesor externo, en estos aspectos de identificación y seguimiento de riesgos. 4.5.1 Evaluación de riesgos. Respuesta de la Secretaría de Hacienda: No se realizaron contrataciones en las que la ONTI diera su opinión técnica, pero tal como tiene constancia esa Auditoria, se elevó mediante el expediente EXP-S01:055314/2004, del 22/12/2004, la solicitud de un concurso para desarrollo de módulos funcionales, y no hemos tenido respuesta formal hasta diciembre de 2006, habiéndose obtenido la no objeción en marzo de 2007. Cabe destacar que se hicieron contrataciones a través de PNUD, que se rige por las normas de Naciones Unidas. La evaluación de riesgos a lo largo del proyecto se ha mantenido dentro de la clasificación expuesta en la presentación a la que se hace referencia (“Presentación reunión general 072005.ppt”). La evaluación de riesgos requiere su inclusión permanente en el desarrollo del proyecto, y esa inclusión corresponde precisamente al gerenciamiento del proyecto, y desde esa actividad se han llevado a cabo las acciones de mitigación que se han propuesto, detalladas en el punto 4.5. Se menciona en el informe que no se tuvo en cuenta la coexistencia con bases y aplicativos del Sidif Central, SLU, y otros aplicativos. Cumplimos en destacar que de eso se ocupa el grupo de Convivencia específicamente definido desde los inicios mismos del proyecto para que analice e implemente dichas estrategias. 4.5.2 Mediciones. Se tendrá en cuenta la observación de contar con mediciones cuantitativas. Comentario de AGN: No se aporta evidencia sobre evaluaciones periódicas de riesgos. Se sugiere incorporar 1) al cuadro de evaluaciones, los riesgos señalados en la observación. Página 65 2) una evaluación de riesgo residual al caso de contrataciones sin intervención de la ONTI. Aclaración: Se tuvo conocimiento del grupo convivencia pero no de evaluación de riesgos de convivencia. 4.6 Objetivo de Control: Relaciones. Respuesta de la Secretaría de Hacienda: Por todas las relaciones mencionadas en el documento tenemos reuniones habituales de seguimiento con usuarios (SAF’s por Modificación Presupuestaria, de sensibilización con personal de la ONP, por ejemplo, mediante reuniones generales con todas las áreas), y de coordinación (con el Comité de Sistemas los lunes, y semanal de avance con proveedores, entre otras). Participa activamente también el grupo de réplicas, quienes nos traen requerimientos de los SAF’s. Como producto de todos esos encuentros hemos logrado que la información de avance del proyecto, así como la pronta y oportuna gestión de los obstáculos que podrían impactarle, sean tratados en tiempo y forma. 4.6.1 Intervención de la ONTI. Respuesta de la Secretaría de Hacienda: Ante la falta de respuesta de este organismo, se efectuaron los reclamos correspondientes a través de la Subsecretaría de Presupuesto. En relación con el efecto entendemos que no es de nuestra competencia opinar sobre dicho punto. Comentario de AGN: Se sugiere continuar con los reclamos a los efectos de lograr una respuesta satisfactoria. Página 66 4.6.2 Comunicaciones. Respuesta de la Secretaría de Hacienda: Se han realizado presentaciones desde la Subsecretaría de Presupuesto, para todos sus integrantes, y mediante la participación en talleres los usuarios han tenido plena participación (definiendo sus requerimientos), y conocimiento de los avances y prioridades del proyecto. En dichos talleres también participó personal del grupo de Réplicas, siendo ellos quienes tienen también trato directo con los usuarios, aportando valioso conocimiento operativo y funcional relevado en las áreas usuarias. Además colaboran asiduamente en presentaciones, pruebas, y cerrando el circuito acompañando a los usuarios en los pasajes a producción. Asimismo, cabe destacar que desde los OR, también se han generado acciones tendientes a la comunicación de los avances del proyecto, o a la obtención de información necesaria para el proceso de definición de requerimientos, tales como: 1. En el caso de la TGN: presentación del modelo conceptual general de los módulos definidos para el e-SIDIF, y de los modelos conceptuales de Medidas de Afectación Patrimonial (Embargos, Concursos y Quiebras) y de Gestión de Pagos, en el ámbito de las Jornadas de Tesorerías Jurisdiccionales; 2. En el caso de la CGN: la presentación del modelo en los Cursos Interamericano Intensivo de Capacitación sobre Administración Financiera y Control del Sector Publico Nacional, que se dictan en forma semestral en el centro de Capacitación y Estudios de la Secretaría de Hacienda. Creemos interesante destacar que en dichos cursos no sólo se presenta el modelo conceptual del sistema de Contabilidad sino también del de Tesorería , Presupuesto y del proyecto en su conjunto. También se han realizado reuniones con algunos SAF’s con motivo de relevar las necesidades de información respecto de la gestión del módulo de Fondo Rotatorio y de Pasajes y Viáticos, asi como ahora se están relevando Página 67 gestiones en los circuitos de gastos; 3. Y en general: se han realizado relevamientos de información y consultas a organismos sobre gestiones en proceso de definición de requerimientos, a fin de asegurar que la funcionalidad a definir contempla las necesidades de gestión y registro de información. Es por lo expresado entonces que consideramos que el efecto mencionado no se producirá. Comentario de AGN: Se aporta información de acciones realizadas sin un plan de comunicaciones internas y externas que acompañe de forma orgánica el desarrollo del e-sidif. Se sugiere estructurar un plan con el objeto de crear una imagen que colabore en la credibilidad del proyecto tomando en consideración nuestra recomendación. 4.7 Objetivo de Control: Presupuesto y Monitoreo. Respuesta de la Secretaría de Hacienda: Actualmente el Proyecto elabora anualmente un Anteproyecto de Presupuesto que se envía para la formulación presupuestaria a la ONP, conforme la normativa en vigor. Las asignaciones presupuestarias establecidas en la respectiva Ley de Presupuesto se ejecutan conforme las normas generales de ejecución y, en tal sentido, están sujetas a todos los controles y monitoreos previstos en la normativa vigente. Respecto a lo tecnológico, lo siguiente es lo que se transmitió en la presentación del Modelo Conceptual definido por las áreas usuarias, en octubre de 2004, mediante el documento “Presentación modelo_conceptual.ppt”; y en los talleres funcionales que se definieron luego de acordar los supuestos principales en los talleres de Visión Compartida, de octubre de 2003. En este documento del 2004, además del Modelo Conceptual, se presentaron los objetivos Página 68 para el resto del año 2004, y para el año 2005. Los beneficios mencionados, por la actualización tecnológica, son entonces: • Implementar, a través de este desarrollo, nuevas tecnologías orientadas a entornos Internet y uso de software libre; • Disponer de un producto adaptable a diferentes entornos y tamaños de organizaciones; • Disponer en un único repositorio central de toda la información de gestión y de registro; • Menor costo de mantenimiento; • Menor costo de adaptación a los cambios; • Simplificación del aspecto técnico de las réplicas; • Reducción en el costo de hardware y software; • Mayor facilidad de administración de: 1. Versiones de la aplicación 2. Bases de datos 3. Software de base En cuanto a los beneficios tecnológicos y sus indicadores de medición, tomamos la recomendación de analizar posibles modos de medir la evolución de estos beneficios. 4.7.1 Presupuesto y Contrataciones. Respuesta de la Secretaría de Hacienda: 1) tendremos en cuenta la sugerencia de elaboración de un procedimiento de control al efecto, no obstante cabe aclarar que los gastos están sujetos a los controles generales del Sidif, que se realizan a la actividad ’07- Desarrollo del Sistema Único de Información de Administración Financiera’, del programa ’26-Administración Financiera’, de la jurisdicción Página 69 ’50- Economía’. En cuanto a la observación de que no contamos con información de lo que demandará el nuevo producto, mencionamos que estamos trabajando en la planificación general, y un ejemplo de ello es el ‘Plan de Infraestructura General’ que se está preparando en la Unidad Informática, incluyendo en él lo requerido por el proyecto ‘e-Sidif’, y respecto a las funcionalidades a desarrollar seguimos trabajando utilizando el método de estimación de UCP (Use Case Point), siendo el mismo un estándar del mercado; y tal como la Auditoria misma relevara según expresara en el punto ‘3.2.5.3. Metodología de Trabajo’. 2) en esta primera etapa del proyecto, las gestiones de recursos se hicieron a través del FOSIP, ente que se rige por las normas de Naciones Unidas. Luego, a partir del 2004 que comienzan a imputarse partidas, como por ejemplo la contratación de la empresa “Idea Factory” para definir el Marco de Arquitectura. Ya en 2005, se habilitó la Actividad ’07 – Desarrollo del Sistema Único de Información de Adm. Financiera’. Ejemplo de la disponibilidad de información económica del proyecto entendemos que es el cuadro de la página 9 (folio 10), donde se detallan gastos abiertos por programa y actividad, que le fueran suministrados a esa Auditoria. Comentario de AGN: 1) Sin comentarios. 2) No resultó posible a esta auditoría verificar los datos de gastos proporcionados por la Subsecretaría de Presupuesto a partir de los programas desde donde se asignaron recursos. Los gastos del equipamiento e instalaciones no fueron incluidos en la información provista por la Subsecretaría. Se sugiere diseñar un sistema de control sobre todos los gastos que afectan al proyecto. Página 70 4.8 Objetivo de Control: Marco de Referencia para la Administración de Proyectos . Respuesta de la Secretaría de Hacienda: El alcance y los límites del proyecto se detalla en el documento adjunto, “SI_Requerimientos grales e-sidif.doc”, llamado también “Primera Versión Operativa”. Los cronogramas de asignación de tiempos y recursos están disponibles, así como las responsabilidades de los participantes las cuales se hallan definidas en los Términos de Referencia que cada uno de los miembros del proyecto ha firmado. 4.8.1 Cronograma. Respuesta de la Secretaría de Hacienda: 1) Si bien se presentan en el Comité y allí se da su aprobación, tomaremos en cuenta la observación para obtener aprobaciones formales expresas. 2) Al momento de realizarse este trabajo de campo al cual respondemos, existían efectivamente dos planificaciones: una para los procesos de desarrollo, y otro para los procesos de réplicas (implementaciones). Se estimaba entonces realizar réplicas del SLU hasta fines del año 2007, inclusive. La planificación a la que hace referencia el documento “Presentación reunión general 072005.ppt” efectivamente ha sido elaborada con supuestos muy optimistas, lo cual no se concretó en la realidad,. Es por el planteo estratégico mismo, y uno de los objetivos denominados “Gestión por Resultados”, que se decidió que fueran los OR’s los responsables directos de la definición de los requerimientos, y poder así capitalizar madurez y conocimiento directo con el propio personal. Lógicamente esto ha demandado capacitación y reorganización de las tareas propias de su gestión para involucrarse en el proyecto. Sin duda ha implicado tiempos mayores a los previstos pero la Secretaría de Hacienda lo ha considerado como una inversión que necesariamente debe transitarse, y cuyos costos son justificados. Página 71 Cabe destacar también que el desafío que impone el cambio tecnológico ha obligado a replanificaciones al equipo informático que tuvo su propia curva de aprendizaje. Actualmente estamos elaborando un Plan General el cual será presentado durante los meses de Mayo y Junio de 2007, y para este propósito hemos estado realizando re-estimaciones, acorde al nivel de avance que se ha ido logrando en el Proyecto, tal como la misma metodología RUP lo indica. Hemos incluso focalizado los esfuerzos de planificación considerando los cuatro proyectos internos al proyecto macro: (a) Desarrollo, (b) Mantenimiento, (c) Convivencia, (d) Migración de datos. 3) Actualmente estamos trabajando en un ciclo de mejoras del proceso de estimación acorde a lo propuesto por la metodología RUP. Al inicio del proceso comenzamos utilizando el método de estimación por UCP (puntos de casos de uso), pero luego, dados los avances del proceso y por contar ya con más experiencia, hemos estado ajustando la técnica generando más guías de trabajo y capacitando a personas relacionadas con esta tarea, por ejemplo a los analistas responsables de cada negocio (ver documentos “SI_EA_UCP.doc” y “SI_ING_Estimacion_UCP.doc”). 4) La integración la hacemos manualmente, hasta tanto tengamos disponible una herramienta integradora, la que en estos momentos estamos desarrollando. 5) En las interfaces externas se contemplarán los estándares definidos por la ONTI, lo que significa que los tiempos deberían reducirse. Tenemos un importante avance con AFIP y BNA. Comentario de AGN: 1) Sin comentario. 2) Se considera auspicioso la elaboración de la planificación general que proveerá mayor control al proyecto si el mismo se encuentra vinculado a las programaciones operativas (requerimientos, diseño, desarrollo y testing). Página 72 3) En el marco de ciclo de mejoras de estimación iniciado se recomienda evaluar la integración con otros temas no contemplados por RUP como la administración de personal, contratos y presupuesto. 4) La herramienta utilizada (project managment) brinda la posibilidad de integrar automáticamente subproyectos. 5) Se sugiere que las actividades mencionadas se evalúen e incorporen a la planificación general mencionada. 4.9 Objetivo de Control: Estudio de Factibilidad. 4.9.1 Caso de Negocio. Respuesta de la Secretaría de Hacienda: 1) Tenemos un primer antecedente de la justificación de este proyecto en las misiones del Banco Mundial, tanto del año 2003 como del 2002 inclusive. En la visita de octubre del 2002 se apoyó la expansión del SLU hasta llegar a 42 SAF, pero se propuso no continuar desarrollando nuevas funcionalidades, sino dedicar recursos a implementar un nuevo modelo que tenga en cuenta el cambio tecnológico, y en la misión del 2003 se propuso continuar con el proceso de cambio, proponiendo la organización de talleres para elaborar el modelo conceptual y funcional, para ser discutido, ajustado y aprobado por la Subsecretaría de Presupuesto durante el segundo semestre de 2003. En agosto del 2003 se realizan presentaciones generales del proyecto justificando su necesidad y beneficios, así como una breve reseña de la metodología a utilizar. En el resto del año 2003 se llevan a cabo reuniones y talleres con el objetivo de definir y acordar los objetivos estratégicos y el alcance funcional del aplicativo, ampliando lo que del caso de negocio ya se presentara en las primeras presentaciones de agosto’ 03. Paralelamente, en diciembre de 2003 se contrata a la firma “Idea Factory” para que comience a trabajar en la definición del Marco de Arquitectura’, al tiempo que se avanza en Página 73 los talleres y así ir definiendo los alcances funcionales para la primera versión. En enero de 2004 nuevamente se presenta la estructura del proyecto, detallando incluso las actividades realizadas hasta ese momento, y las planificadas, por etapas (ver documento “Presentación 22-01-2004.ppt”). En Octubre del 2004 se presenta el Modelo Conceptual (ver documento “Presentación modelo_conceptual.ppt”). Entre diciembre’ 04 y marzo’ 05 la firma “Cubika” desarrolló un prototipo incluyendo como cierre de dicha tarea la realización de una prueba de carga con dicho prototipo. Por lo expuesto se deduce entonces que existían ya definiciones del caso de negocio como para que se pudiera comenzar a trabajar en las definiciones del marco de arquitectura, e inclusive se presentó también el Modelo Conceptual en octubre de 2004. Poco después, se presentaron y aprobaron los alcances del proyecto el 22 de enero ante el Comité. Luego esta empresa siguió con sus tareas, finalizando en julio’ 04. 2) El Caso de Negocio considerado definitivo se presentó en junio de 2004 (ver documento “SIDIF-I Caso de Negocios v02.doc”), y el Modelo Conceptual se presentó en Octubre de 2004. 3) El proyecto fue aprobado por el Comité dados los objetivos estratégicos de: 1. Gestión por Resultados, 2. Actualización Tecnológica; 3. Ampliación del alcance funcional de los aplicativos SLU y SidifCentral En las presentaciones del Caso de Negocio se incluyeron valoraciones económicas (ver documento “SIDIF-I Caso de Negocios v02.doc”). 4) Los beneficios esperados se mencionan también en el documento mencionado en el punto anterior (ver documento “SIDIF-I Caso de Negocios v02.doc”). 5) Es como se menciona. Expresamente no se incluyeron porque no se estaba en condiciones de estimarlos a ese momento del proyecto. Página 74 6) Es como se menciona. Se acepta la recomendación de generar indicadores para medir el éxito del proyecto. 7) Se presentó y aprobó en las reuniones de Comité mencionadas, pero no contamos con una firma de todos los participantes. Tomamos en cuenta la recomendación para futuras oportunidades. Respecto al efecto señalado, referido a que el caso de negocio no aporta todo su potencial y por eso no hemos logrado una planificación más ajustada, dado que no lo compartimos, creemos conveniente expresar algunos comentarios respecto a las estimaciones. Durante el ciclo de vida del proyecto se deben considerar distintos momentos de estimación que “cuentan” la información disponible aplicando las técnicas de estimación adecuadas. En etapas tempranas del proyecto, durante la Fase de Concepción, el tamaño del producto se estima por “Analogía” con otros productos similares desarrollados en proyectos previos. Más adelante, durante la fase de Elaboración cuando ya se dispone de más información sobre la funcionalidad a construir –en nuestro caso una lista de los Casos de Uso Candidatos por Negocio– ya es posible aplicar técnicas analíticas estándar que permiten estimar el tamaño del producto con un mayor grado de certeza. Existen múltiples técnicas –Puntos de Función Orientados a Objetos, Puntos de Objetos Predictivos, Puntos de Caso de Uso (UCP) – y todas deben ser calibradas teniendo en cuenta las características particulares de la organización y los modelos disponibles al momento de la estimación. En nuestro caso, la técnica de estimación seleccionada ha sido “Puntos de Caso de Uso”. Cada entrega, que produce un equipo de trabajo, es acompañada de su correspondiente estimación: Análisis à Diseño/Testing Diseño à Implementación Página 75 Cada equipo que recibe una entrega ajusta la estimación recibida teniendo en cuenta el “reuso” de soluciones ya disponibles, por ejemplo: componentes y otros elementos de solución ya provistos por la arquitectura. Comentario de AGN: 1) Sin comentarios. 2) Precisamente el documento mencionado en su introducción párrafo 3 dice “De todas maneras cabe aclarar que el caso definitivo será elaborado una vez que se hayan completado los talleres para la obtención del modelo conceptual y se hayan hecho las validaciones y pruebas de concepto de la arquitectura candidata.” 3) El Caso de negocio menciona otras opciones (Reingeniería, aumentar personal, adquisición de producto estándar) haciendo apreciaciones para desecharlas sin evaluarla la conveniencia técnica-económica. 4) Se mencionan los beneficios pero no se cuantifican. 5) Se sugiere asegurar decisiones estratégicas al inicio del proyecto pues son claves en el éxito. 6) Sin comentarios. 7) Sin comentarios. 4.10 Objetivo de Control: Definición de Requerimientos de Información. Respuesta de la Secretaría de Hacienda: Debe tenerse en cuenta que el nuevo sistema propuesto, la versión ‘Sidif’ bajo tecnología Internet, no sólo incluye la actualización tecnológica del mismo, sino también las definiciones estratégicas de la llamada ‘Gestión por Resultados’, y si además consideramos que la funcionalidad se ampliará respecto al actual SLU-SidifCentral, no se trata entonces de un reemplazo por un ‘sistema nuevo propuesto o modificado’, simplemente. Es tan estratégico como radical su cambio, y es bajo esta lógica que una metodología de desarrollo de software Página 76 como RUP, con su lógica iterativa e incremental, permitirá ir implementando negocios en forma progresiva, definiendo y aprobándose cada uno de ellos conforme al Plan General. A su vez sus definiciones son acordes a los requerimientos de la Ley de Administración Financiera, la nº 24.156. 4.10.1 Modelo Conceptual. Respuesta de la Secretaría de Hacienda: 1) La definición del alcance define implícitamente sus límites, y eso es ya una restricción. (ver definiciones del Modelo Conceptual, en documento “Presentación modelo_conceptual.ppt”) 2) Si bien en algunos casos hemos obtenido aprobación formal del Modelo Conceptual, por mail, tal los ejemplos siguientes, aceptamos la recomendación de obtener la aprobación expresa de todos los usuarios responsables afectados por las funcionalidades a implementar. Si bien hemos formalizado algunos hitos, reconocemos que nos faltan otros y agregar acuerdos aunque existan minutas de las reuniones de definiciones y sus revisiones. Ejemplos de aprobación: Ejemplo nº 1: ----- Original Message ----From: "Susana Luna" <sluna@mecon.gov.ar> To: "Marta Vazquez" <msvazq@mecon.gov.ar> Cc: "Susana Vega" <suvega@mecon.gov.ar>; "Silvina Rey" <clarey@mecon.gov.ar>; "Ana Hurtado" <ahurta@mecon.gov.ar>; "Diana Boeykens" <dboeyk@mecon.gov.ar> Sent: Wednesday, November 24, 2004 9:52 PM Subject: SIDIF INTERNET > Por indicación de la Sra Directora Nacional de Presupuesto > Lic. Susana Vega Página 77 > se presta conformidad al avance a la fecha del modelo conceptual de > e-sidif > y a las matrices de evaluación de escenarios. > Atte. > Susana Luna > -----Mensaje original----De: Raúl Rigo [mailto:rarigo@mecon.gov.ar] Enviado el: Domingo, 07 de Noviembre de 2004 10:18 p.m. Para: suvega@mecon.gov.ar; jdompe@mecon.gov.ar; Cesar Duro; Carlos Santamaría; Ricardo Bruzzi; Ester Lagomarsino CC: Marta Vazquez Asunto: SIDIF INTERNET Estimados, El pasado viernes estuve repasando con Marta el grado de avance de las actividades que acordàramos en la ùltima reuniòn de directores vinculadas con SIDIF Internet. En ese sentido, les envìo un recordatorio que documentos a entregar durante esta semana. Encarezco respetar las fechas sugeridas porque estamos muy ajustados con el cronograma de actividades previstas hasta fin de año. Saludos. RR Ejemplo nº 2: ----- Original Message ----From: Cesar Duro To: MSVAZQ@MECON.GOV.AR Sent: Monday, November 08, 2004 6:33 PM Subject: E-sidif: Aprobación Matrices de Evaluación de Escenarios Se adjuntan los archivos con la aprobación formal de la evaluación de los escenarios, para su consideración. Página 78 Dr. César Sergio Duro CONTADOR GENERAL DE LA NACIÓN Ejemplo nº 3: e-SIDIF - Casos de Uso de Pagos Fecha:Fri, 26 Nov 2004 17:33:43 -0300 De:"Pablo Buratti" <PBURAT@MECON.GOV.AR PARA::"Silvia Bosco" SBOSCO@MECON.GOV.AR, Javier Martínez <JMARTI@MECON.GOV.AR CC:Raúl Rigo <RARITO@MECON.GOV.AR, "Jorge Domper" <JDOMPE@MECON.GOV.AR, "Alejandra Arriola" <MAARRI@MECON.GOV.AR, "Marta Vazquez" MSVAZQ@MECON.GOV.AR Referencias:<41780F01.9040204@MECON.GOV.AR A Todos: Por medio del presente informo el estado de situación respecto a la revisión de los Casos de Uso del módulo de Pagos. 1) Casos de Uso aprobados sin Cambios: -Escenarios de Pago. -Selección de Pago. -Medios de Pago. -Algoritmo Pagador. -Aplicación de Cesiones. -Cumplimiento de Cesiones. -Comprobantes de Cesiones. -Oficios Judiciales. -Reglas de Aplicación de Embargos. -Sicore. -Concepto de Retención. -Beneficiario de Retención. -Excepción a Retención. -Retenciones. -Concepto Impositivo. -Algoritmo de Retención. 2) Casos de Uso aprobados con Observaciones: Página 79 -Chequeras y Cheques: Se deben incorporar las funciones de Impresión, Anulación de Impresión, y Cambio de Orden de Cheque (cambio de identificación de beneficiario del cheque) -Lotes de Pago: Se deben incorporar la funciones de Desautorizar Lote de Pago y Reversión de Procesar Respuestas del Banco Pagador. -Notas de Pago: Se deben incorporar las funciones de Modificar Nota Ingresada (previo a la autorización), Impresión y Anulación de Impresión. Se sugiere verificar la disponibilidad de funciones de anulación en las distintas etapas del procesamiento de las Notas de Pago (ingreso, impresión, firma), verificando que estén contemplados los circuitos definidos en el Análisis Global de Pagos por Nota de la Reingeniería del SIDIF Central. -Pagos: Se debe incorporar la función de anulación de pagos, separada de la función de desafectación. Se sugiere modificar la función "Modificar Pagador" denominándola "Modificar OP", incluyendo en dicha función la modificación de pagador, la modificación de fecha de bonificación, y la confirmación de recepción de OP para pago por Nota. -Cesiones: Se debe incorporar la función de Desasociar Comprobante a Cesión. -Embargos y Ejecuciones: Se sugiere renombrar el caso de Uso, identificándolo como "Medidas Página 80 Cautelares", incluyendo en este concepto Embargos, Concursos y Quiebras. Se debe incorporar en la función "Levantar Embargo", la función de Inhibir Embargo. Se solicita verificar el alcance de la función "Modificar Monto de Ejecución de Embargo". En principio la misma no se considera procedente. -Listados Gerenciales: El caso de uso presentado no es representativo en términos de las necesidades del Órgano Rector en materia de Listados Gerenciales. Al respecto existen numerosas opciones de listados no contempladas en el Caso de Uso que son utilizados habitualmente por los usuarios del Órgano Rector. Se sugiere verificar los requerimientos de Consultas y Listados definidos en el Análisis Global de la Reingeniería de Pagos del SIDIF Central. Se debe incorporar la función de Listar Auditor de Pagos Confirmados. 3) Consideraciones adicionales sobre los Casos de Uso revisados: -Escenarios de Pago: El caso de uso debe satisfacer el requerimiento de generación de la Distribución Diaria de Pagos por Concepto. -Selección de Pago: En relación a este caso de uso debe analizarse cómo se resolverá las funciones que actualmente realiza el Órgano Rector sobre los pagos enviados por los SAF no SLU: Recepción de selecciones de pago, recepción de autorizaciones de pago, anulación de recepción, ingreso manual de autorizaciones de pago, cambio de cuenta de cesionario. Debe analizarse cómo se resolverá el proceso de recepción de OP papel en TGN, si se mantiene o si dicha gestión será eliminada por el uso de comprobantes con firma digital. -Chequeras y Cheques: Debe considerarse en el módulo de Fondos Rotatorios la posibilidad de Página 81 agrupar en un único cheque varios Vales o Solicitudes de PVEA, así como también la posibilidad de agrupar en un único cheque las retenciones de distintos Fondos Rotatorios que operan con una misma cuenta. -Medios de Pago/Algoritmo Pagador: Se considera que la función de Anular Medios de Pago/Algoritmo Pagador debe estar acotada a nivel de los Órganos Rectores. -Pagos: Se considera que la funciones de Desafectar Pago/Regularizar Diferencia de Cambio corresponden a usuarios encargados de procesar conciliación bancaria, antes que a usuarios encargados de la gestión de pagos. Se considera que la función Descentralizar/Centralizar función de Pago debe estar acotada a nivel de los Organos Rectores. -Cesiones/Aplicación de Cesiones/Cumplimiento de Cesiones/Comprobantes de Cesiones: Se considera necesaria la verificación de los casos de uso por parte del equipo de Réplicas SLU. -Sicore/Concepto de Retención/Beneficiario de Retención/Excepción a Retención/Retenciones/Concepto Impositivo/Algoritmo de Retención: Se considera necesaria la revisión de los casos de uso por parte del equipo de Réplicas SLU. Quedo a disposición por cualquier consulta relacionada con el presente. Atentamente Lic. Pablo Ricardo Buratti Coordinador de Proyectos Tesorería General de la Nación Ministerio de Economía y Producción Página 82 TE 4349-6490 FAX 4349-6496 Ejemplo nº 4-adjunto: -----Mensaje original----De: Carlos Pablo Maza [mailto:cpmaza@mecon.gov.ar] Enviado el: Jueves, 10 de Junio de 2004 10:09 a.m. Para: Susana Luna Asunto: Re: [Fwd: Minuta Taller Bienes Inmuebles] No hay observaciones de mi parte. Saludos. Susana Luna escribió: > Estimados > Ver si la presente minuta merece observaciones. > Les avisaré la fecha del próximo taller > muchas gracias > > -----------------------------------------------------------------------> > Asunto: Minuta Taller Bienes Inmuebles > Fecha: Mon, 07 Jun 2004 12:40:16 -0300 > De: María Alejandra Arriola <maarri@mecon.gov.ar> > A: Rosa Nieva (CGN) <rnieva@mecon.gov.ar>,Viviana Gomez <vgomez@mecon.gov.ar>,Pablo Buratti (TGN) <pburat@mecon.gov.ar>,María del Carmen Norry (TGN) <mnorry@mecon.gov.ar>,Susana Luna (ONP) <sluna@mecon.gov.ar>,Emilce Angel Torres <eangel@mecon.gov.ar>,Roberto Boccardo <rboccardo@sgp.gov.ar>, ypiney@mecon.gov.ar,jotero@mecon.gov.ar > CC: Marta Vazquez <msvazq@mecon.gov.ar> > > Estimados, > > se envía la minuta del Taller de Bienes Inmuebles realizado el 27/05 > con el formato definido por la metodología. Página 83 > > Pido disculpas por la demora pero la semana pasada estuve varios días > enferma. > > Haganme llegar las dudas, comentarios y observaciones para asi publicar > la minuta definitiva. > > Saludos, > > Alejandra. > > -> --------------------> Lic. María Alejandra Arriola > Desarrollo de Sistemas > Ministerio de Economía > Secretaría de Hacienda - Unidad Informática > TE: 4349-6134 > e-mail maarri@mecon.gov.ar > --------------------> > -----------------------------------------------------------------------> Name: SI_Taller_Bienes_Inmuebles.doc > SI_Taller_Bienes_Inmuebles.doc Type: Winword Archivo (application/msword) > Encoding: base64 > Estado Recibir: No se ha recibido con el mensaje Ejemplo nº 4: Asunto: [Fwd: [Fwd: Minuta Taller Bienes Inmuebles]] Fecha: Tue, 15 Jun 2004 17:28:54 -0300 De: Susana Luna <SLUNA@MECON.GOV.AR> PARA:: María Alejandra Arriola <MAARRI @MECON.GOV.AR> Página 84 Esta Oficina Nacional no tiene observaciones que formular Atte. Susana Luna Ejemplo nº5: ----- Original Message ----From: CESAR DURO To: 'MSVAZQ @MECON.GOV.AR' Cc: JDOMPE ; RBRUZZ ; 'SUVEGA@MECON.GOV.AR' ; CARLOS SANTAMARÍA (E-MAIL) ; 'RARIGO@MECON.GOV.AR' Sent: Monday, May 17, 2004 3:02 PM Subject: REQUERIMIENTOS DEL SIDIF INTERNET -ENTES Por medio del presente presto conformidad en general al contenido de la minuta del taller de Entes del 23/04/04. En cuanto a los aspectos particulares que generan algún comentario destaco los siguientes: 3. Sectores y roles que intervienen. Los entes bancos se darán de alta por la TESORERÍA GENERAL DE LA NACIÓN. 6.3. Nuevos requerimientos. Requerimiento 2: No está la descripción del mismo y aparece como una regla de negocio, sin indicar a que requerimiento se refiere esa regla. Requerimiento 7.2: Aparece una regla de negocio “Grupo de datos a obtener desde la AFIP”, esta regla corresponde al requerimiento 6: “El sistema debe capturar de padrón de AFIP la información de los entes que dicho Org. Admin.” y no al 7 que se refiere a los datos del código postal.6.3.1. 10. El sistema debe capturar de padrón de AFIP la información de los entes que dicho Org. Admin." Ventajas, el segundo ítem, cambiar la palabra “llevando” del final del párrafo por “efectuando”. Página 85 6.5. Requerimientos para procesos relacionados. Circuito de embargos: Para el circuito de embargos nunca se usa beneficiarios CUIT CGN porque no habría forma de aplicar el embargo. La idea es cargar el embargo con el DNI y este dato cruzarlo con la tabla de entes, si existe entonces le asocia el numero de Ente, si no existe igual deja cargar el embargo. De esta forma si se da de alta un Ente cuyo número de DNI figura en la tabla de Embargos sin numero de Entes se puede actualizar este dato en la misma, y de esa manera se incrementa significativamente la posibilidad de cargar los embargos que hoy no se pueden cargar porque el Ente no esta cargado. Esto es de suma importancia porque los embargos informados por los juzgados no siempre traen el CUIT. Atte. Dr. César Sergio Duro CONTADOR GENERAL DE LA NACIÓN -----Mensaje original----De: Cesar Duro Enviado el: Viernes 14 de Mayo de 2004 09:31 Para: Rosa Nieva Asunto: RV: REQUERIMIENTOS DEL SIDIF INTERNET teneme esto listo -----Mensaje original----De: Raúl Rigo [MAILTO: RARIGO@MECON.GOV.AR] Enviado el: Viernes 14 de Mayo de 2004 09:25 Para: SUVEGA@MECON.GOV.AR; JDOMPE@MECON.GOV.AR; Cesar Duro; Carlos Santamaría Asunto: REQUERIMIENTOS DEL SIDIF INTERNET Estimados, En el desarrollo de SIDIF Internet, estamos trabajando sobre la minuta de requerimientos referida a entes, que surgiò del trabajo del equipo Página 86 multidisciplinario. Dicha minuta fue remitida a los órganos rectores para comentarios, observaciones y aprobación. Solicito vuestras intervenciones para, luego, continuar con la elaboración de los requerimientos de base a la arquitectura del sistema. Gracias Raùl Rigo --Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (HTTP://WWW .GRISOFT.COM). Versión: 6.0.681 / Virus Database: 443 - Release Date: 10/05/04 FIN EJEMPLOS 3) Aunque no hayamos recibido formalmente todos los conformes, el documento se encontraba cerrado, y no por ello significa que el modelo está abierto a discusión. (ver documento “SI_VIS_modelo conceptual.doc”). El objetivo de este documento era definir el alcance completo del proyecto, por lo que incluía todos los negocios. Durante 2005 se logran acuerdos para priorizar algunos negocios (Presupuesto, Gastos, Pagos, Fondos Rotatorios, Pasajes y Viáticos), hasta que durante el año 2006 se logra definir un subconjunto de requerimientos, los cuales conforman la llamada “Primera Versión Operativa”, antes mencionada en 4.8. Esta versión ha sido aprobada por el Comité de Sistemas, y por ello es base para definir las prioridades de trabajo del proyecto; 4) El usuario participa en los talleres funcionales y detallados, en los cuales se producen documentos desde el equipo técnico/funcional del proyecto, que son luego aprobados por dichos usuarios, vía e-mails. , los cuales se archivan en las carpetas compartidas del servidor de documentación, desde 2006-2007 Estos documentos son: MDR (Minutas de Requerimientos), LBR (Línea Base de Requerimientos), DF (Diagrama Funcional), MCN Página 87 (Modelo Conceptual del negocio), DA (Diagrama de Actividad), PIU (Prototipo Interfaz de Usuario), Grilla de Datos, Reglas de negocio, Matriz de Impacto. Según el tema a tratar en el taller puede suceder que alguno de estos documentos no sea objetivo del mismo. 5) Al momento de este trabajo de campo esta información se encontraba en elaboración. Comentario de AGN: 1) Una buena práctica es complementar al alcance con la definición de lo que no hará el sistema (restricciones) como ser actividades vinculadas a procesos que dado su nivel de incertidumbre no se ejecutarán en una primera etapa. 2) Sin comentarios. 3) Se remarca la inexistencia de un sistema de control de versiones del artefacto “Modelo Conceptual”. 4) Se elimina este punto de la observación. 5) Sin comentarios. 4.10.2 Marco de Arquitectura. Respuesta de la Secretaría de Hacienda: Se cuenta con los documentos detallados de la realización del QA por cada entrega del proveedor, y en cada caso se les notificaron las mejoras o cambios a realizar. Para un mejor logro de dicho objetivo se mantuvieron reuniones con la Srta. Claudia Sánchez, representante de QA de “Idea Factory”. Por el hecho de haberse avanzado y logrado el objetivo que los convocara, y pudiendo avanzar hacia las siguientes etapas de desarrollo de prototipo y prueba de carga del mismo, ello da cuenta del marco de arquitectura cerrado. No obstante, recibimos la observación de que no se cuenta con la evidencia escrita de la aceptación de esta empresa, y de la respuesta expresa a nuestros requerimientos de cambios y ajustes. Página 88 Comentario de AGN: La sugerencia se realiza para que cierre el círculo de calidad. Se recomienda incorporar al procedimiento actual lo señalado en el punto 6.10.1. 4.10.3 Desarrollo del Prototipo. Respuesta de la Secretaría de Hacienda: No se hizo control de calidad del código del prototipo dado que él no era un objetivo en sí mismo, sino un medio para llevar a cabo la prueba de carga, la cual sí era objetivo ya que de ella dependía la aprobación de la arquitectura inicialmente planteada. Si se hizo control de calidad de los documentos que usaba la metodología. Comentario de AGN: Se hace hincapié que no se encontró evidencia de QA sobre las entregas del producto y no solamente del código. 4.10.4 Talleres funcionales. Respuesta de la Secretaría de Hacienda: Si bien en el punto “2. Alcance del Examen” se menciona que se analizó la gestión del ciclo de vida del proyecto desde sus inicios hasta la consolidación de la arquitectura alcanzada en diciembre del 2005, lo referido a talleres se analizó hasta octubre del 2004, para lo cual incluso les proporcionamos la planilla “SI_ANA_Productos_MCN.xls” que nos solicitaran en oportunidad de la visita de campo. Los talleres generales comenzaron a fines de 2003, entre noviembre y diciembre (ver documento “presentación_tallergeneral y presupuesto.doc”). Notamos que el cuadro presentado en el informe, en su página 32, no coincide con la planilla que anteriormente mencionamos, y como ejemplo presentamos los siguientes casos: a) Negocio ‘Administración de Bienes / Bienes Inmuebles”. Minutas de Página 89 Requerimientos (MDR). En cuadro de página 32 se menciona que se carece de ‘Minutas de Requerimientos’ pero las mismas estaban disponibles, así como el control de calidad (ver SI_Taller_Bienes_Inmuebles1.doc”, documentos “CGN- “SI_Taller_Bienes_Inmuebles v1.1.0.doc”, “SI_QA_MDR_BI_Taller_Bienes_Inmuebles.doc”, todos del 2004 en su carpeta origen, del servidor al que la Auditoria tuvo acceso ). b) Negocio ‘Administración de Bienes / Bienes Inmuebles”. Línea Base de Requerimientos (LBR). En el mismo cuadro se menciona que se carece de ella, cuando en realidad estaban disponibles, así como su control de calidad (ver documentos “LBR_Bienes_V1.1.0.rtf”, “SI_LBR_AB_00_Administración de Bienes.rtf”, “SI_QA_LBR_AB_BI_Bienes_eva.rtf”, también del 2004 en su carpeta origen del servidor antes mencionado). c) Negocio ‘Entes’. Descripción Funcional. Se menciona que se carece de ella pero los archivos correspondientes se encuentran en las carpetas compartidas del servidor mencionado, con fecha abril del 2004. (ver documentos “Entes v1.doc”, “Entes v2.doc”, “Entes V2(Situación futura).doc”). Respecto a los artefactos incluidos en el cuadro de esta página 32, nos parece importante destacar algunos aspectos: 1. no es necesario que todos los talleres incluyan una ‘Presentación’. Ello depende del tipo de audiencia, número de integrantes, incluso del tema a tratar; 4. no en todos los casos tendremos ‘Descripción Funcional’ dado que puede tratarse de talleres de carácter general, y que no traten una funcionalidad en particular; 5. el control de calidad, QA, se hace por muestreo y no para todos los artefactos, de modo que puede haber dentro de un negocio alguna funcionalidad a la que no se le haya aplicado esta revisión. Lo importante es que en todos los negocios se haya Página 90 aplicado revisiones; 6. tampoco en todos los casos se han realizado agendas de reuniones. Hubo casos en los que en reuniones con los Órganos Rectores se definieron objetivos para cerrar determinados puntos, y dependía del grupo de trabajo definir los encuentros, con su periodicidad y documentación asociada. Luego, el producto de ese trabajo es el que ha sido conformado por los participantes; Finalmente, en relación a la expresión “... la documentación desarrollada para definir el modelo de negocio presentaba una línea de producción no uniforme, lo que estaría mostrando cierta debilidad de control”, entendemos que la misma no aplica dados los comentarios ya detallados, a los cuales adicionaríamos los siguientes: - el cuadro identifica negocios que durante el período auditado no existían como módulos del sistema, tales como Medidas de Afectación Patrimonial, Fideicomisos, Retenciones por OSIRIS. Algunos módulos se definieron a posteriori como consecuencia de la ampliación del alcance inicial definido. (Ej: Medidas de Afectación Patrimonial, reemplaza a Embargos e incorpora Concursos y Quiebras); - también se señala que para algunos módulos tales como Programación Financiera, Recursos, Conciliación Bancaria, Cuentas a Cobrar, Embargos, Cesiones no había MDR, lo cual es incorrecto. Si bien algunos módulos de Tesorería fueron inicialmente definidos en una única MDR, y luego las LBR se hicieron por cada módulo, la mayoría de los negocios de Tesorería tuvieron documentación durante el período auditado. Comentario de AGN: Efectivamente el cuadro “SI_ANA_Productos_MCN.xls” no pudo ser corroborado por esta auditoría en base a la información disponible en la biblioteca digital SIDIFI. Página 91 Pero aun considerando válida la información del cuadro mencionado, la cantidad de artefactos faltantes alcanza a 168, como demuestra la siguiente tabla: NEGOCIO Presupuesto Gastos Tesorería Fondos Rotatorios Compras y Contrataciones UEPEX General Administración Bienes de Pasajes y Viáticos Totales MDR LBR Desc. Func 6 0 8 1 1 4 0 1 1 1 4 10 4 1 2 7 0 2 0 0 19 12 11 3 4 Presentación Ppt 19 10 13 0 2 1 2 2 1 1 1 2 2 2 1 2 2 0 0 0 0 1 1 0 0 0 0 0 1 19 11 25 11 53 49 TOTAL GENERAL ADR QA 168 4.11 Objetivo de Control: Arquitectura de Información. Respuesta de la Secretaría de Hacienda: Esto se ha realizado en tanto se incluyó en el equipo de proyecto al personal de la Unidad Informática, quienes conocían el modelo de datos del SLU y Sidif Central, garantizándose que sus funciones principales a mantenerse estuvieran consideradas en el nuevo aplicativo. En relación al prototipo, estimamos conveniente adjuntar algunos documentos que dan cuenta de las tareas realizadas para lograr dicho producto, comenzando por el pliego de la Licitación (ver documento “CONCURSO DE PRECIOS Nº 013-2004.doc”), y acompañado de parte de sus anexos los cuales consideramos relevantes para la observación de referencia (ver documentos: “Anexo 01 – Especificación del Marco de arquitectura del sistema.doc”, “Anexo 03 – Descripción Funcional del Prototipo.doc”, “Anexo 04 – Documentación de Página 92 Diseño del Prototipo.doc”). Todos documentos generados en agosto del 2004, y disponibles en las carpetas compartidas del servidor de documentación del proyecto. Dicho prototipo ha sido concebido tomando un subconjunto de las operaciones típicas del negocio, lo cual se detalla en los documentos mencionados, y que han sido elaborados con plena participación de los expertos en la funcionalidad existente. 4.11.1 Evaluación de la arquitectura. Respuesta de la Secretaría de Hacienda: Como producto del análisis y definiciones para la generación del Marco de Arquitectura, contamos con el documento "SI_EDA_Documento de Arquitectura_indice.doc", y “... parteI.doc “... parte II.doc”, “... parteIII.doc”, y “... parte IV.doc”). Tomando los comentarios punto por punto, respecto al ítem de performance puede verse detalle de las pruebas realizadas, con métricas, resultados conclusiones e incluso recomendaciones a aplicar, en el documento “MEC100 – Conclusiones y Recomendaciones.doc”. Es para ello que también se hicieron pruebas de carga, tanto la realizada luego del desarrollo del prototipo, cuando se definió el marco de arquitectura, en Febrero-Marzo del 2005, como también antes de implementar nuevos negocios. El objetivo era poner a prueba la factibilidad de la arquitectura y realizar los ajustes que resulten necesarios. Respecto al ítem disponibilidad, en uno de los documentos mencionados (“... parte IV.doc”), bajo el ítem 3.2.1.5. Cuadro comparativo de las configuraciones propuestas, se detalla el siguiente cuadro: Página 93 Característica Web / App Web / App Web / App Server Juntos Server Juntos Server sin con Separados subparticiones subparticiones Web Caching Disponibilidad Transparent No se asegura El nivel de prestación respecto a esta Failover característica es bueno, ya que el load balancer este servicio, ya detecta la caída de los servidores y rutea los que si bien elpedidos a los activos, y mediante la configuración de subparticiones con más de una load balancer instancia se mantienen las sesiones de usuario. permite rutear elA mayor cantidad de servidores en el cluster y en las subparticiones se mejora respecto a este pedido a un aspecto. server activo, no se mantiene la sesión del usuario. Quick Automated Restarts Shared Cluster State Single Point of Failure Esta característica depende la funcionalidad provista por el servidor de aplicaciones, no de la configuración del cluster. Se provee mediante el mecanismo de subparticiones. El load balancer El load balancer No posee y el web caching (si sólo se provee uno) Por el ítem seguridad, se detallan definiciones bajo el punto 2.1.11, en otro de los documentos mencionados (“... parte II.doc”), y en uno de sus párrafos, en 2.1.11.2.2, remite incluso a más detalle aún: “La explicación del mismo se encuentra en la documentación del componente de arquitectura denominado ‘Seguridad’. En dicha locación tenemos tres Página 94 documentos: “SI_CABA_Seguridad_Guia de uso.doc”, “..._Requerimientos.doc”, “... _Solucion.doc”, y en ellos pueden verse todas las consideraciones técnicas, de la solución propuesta y su utilización, de modo que sea acorde a los fines perseguidos. Nos parece importante asimismo agregar que estas definiciones de Arquitectura han sido compartidas, desde nuestra experiencia, con quienes están actualmente impulsando un proyecto de similares características, “MinPlan”. Como ejemplo, podemos citar como según nota nº 125 del 29/08/06, nº 127 del 27/03/07, y nº 128 del 22/03/07, les hemos entregado información referente a modelos, templates, guías, y funcionales como el Caso de Negocio y Modelo Conceptual (ver notas adjuntas “Nota 125 – 2-03-2007.doc”, “Nota 127 – 07-032007.doc”,y “Nota 128 – 22-03-2007.doc”). Comentario de AGN: Los documentos de evaluación mencionados y otros analizados durante el relevamiento, no revelan la existencia de una metodología que analice la adherencia de la arquitectura a requerimientos de calidad en los siguientes términos: que sistemáticamente, por cada atributo de calidad (performance, disponibilidad, modificabilidad y otros) se obtenga la respuesta del mismo en términos medibles u observables cuando la decisión de arquitectura adoptada componentes, conectores entre otros- ha sido sometida a eventos externos -que obligan a la arquitectura a responder o cambiar-. Se sugiere considerar la recomendación. 4.11.2 Guías y Especificaciones. Respuesta de la Secretaría de Hacienda: No se menciona el cumplimiento de recomendaciones de la W3C (World Wide Web Consortium), porque la estrategia que hemos elegido para implementar la capa de presentación es que el usuario utilice una aplicación de escritorio, y no un browser para ejecutar el sistema. Más detalles acerca de este análisis pueden tomarse del documento “SI_Arq_Justificación capa de presentacion.doc”). Página 95 En cuanto al efecto no aplica ya que este aplicativo es para uso interno de los Órganos Rectores y Organismos, y no público en general. Comentario de AGN: El documento SI_ARQ_justificación_capa_de_presentación propone como estrategia a seleccionar ambas arquitecturas tecnológicas (cliente web y rico). No obstante, el alcance de las recomendaciones de la W3C es aplicable también y de manera especifica a la capa de presentación cliente rico y se estima que puede contribuir a mejorar la relación usuario_saf / aplicación. Ver http://www.w3.org/TR/backplane/ 4.11.3 Documentación. Respuesta de la Secretaría de Hacienda: 1) No es aplicable la observación. Puede verse que al momento de realizarse el trabajo de campo que originó este informe el documento ya existía, y se estaban analizando los requerimientos para esta componente (ver documento “SI_CABA_Matriz_De_Impacto Requerimientos.doc”). 2) Los templates que el análisis y desarrollo iban determinando como necesarios hacía que ellos fueran generando y actualizándose conforme al curso del mismo, y ante eso puede que hayamos tenido desactualizaciones en algunos documentos, tales como los mencionados. 3) Sí se realizaban controles sobre el estado de los documentos. 4) No acordamos con el efecto mencionado. Cada equipo elabora, según los lineamientos del proceso definido, un conjunto de artefactos como producto de su trabajo. Estos artefactos conforman una entrega, y cada entrega es previamente revisada internamente dentro del equipo (“revisión por pares”) antes de su entrega formal al Control de Calidad. Durante el control de Calidad participan revisores de cada uno de los equipos o perfiles que consumirán la entrega, cada uno aportando su punto de vista. Ingeniería participa con el objetivo de asegurar el cumplimiento de las pautas de modelado definidas para cada una de las disciplinas del proceso de desarrollo, y además es el encargado de supervisar el ciclo de Página 96 control de calidad asegurando que las observaciones detectadas hayan sido incorporadas a los artefactos revisados. Comentario de AGN: 1) El documento mencionado correspondería a una fecha posterior al periodo evaluado. Se evaluara en la eventualidad de una auditoria de seguimiento. 2) Sin comentarios. 3) Esta auditoría no encontró en Sidifi informes sobre el estado de documentación de la arquitectura correspondiente al período auditado. 4) La respuesta confirma la observación. Se sugiere evaluar esta recomendación. 4.11.4 Pruebas (Testing) sobre Componentes. Respuesta de la Secretaría de Hacienda: En el aplicativo “IteM” se dan de alta bugs, nuevos requerimientos, cambios de pedidos de mejoras, observaciones de usabilidad, étc. Ello refleja todo lo pedido, lo cual necesariamente no implica que se le va a dar curso, lo cual depende de si criticidad. No acordamos con el efecto mencionado dado que ningún otro componente o caso de uso del sistema depende en forma directa de seguridad, por lo cual no atrasa el desarrollo de otra funcionalidad. Comentario de AGN: En algún punto del proyecto, entendemos que los incumplimientos en esa componente producirán desvíos en el cronograma del proyecto. 4.11.6 Equipamiento en los SAF. Respuesta de la Secretaría de Hacienda: En realidad sí hemos implementado acciones que tengan en cuenta el equipamiento de los SAF’s, antes de las implementaciones, y por ello hemos tomado las siguientes decisiones: • en septiembre de 2005 se realizó un relevamiento general del parque de PC’s en los Página 97 Organismos y ONP; • se realizó una prueba de carga, la cual definió los puestos, y sus características (memoria, disco), que eran necesarios para la ejecución de la aplicación; • como producto del relevamiento mencionado se determinó que era necesario actualizar las PC’s de personal de la ONP antes de la implementación de FOP (Formulación Presupuestaria), en Mayo del 2006, lo cual se realizó en tiempo y forma, y se decidió por la publicación de la aplicación de ‘Cliente Rico’ en forma local, en cada PC para esta primer implementación; • se realizó un análisis conjunto entre personal del área técnica de la UI, y del grupo de proyecto ‘e-Sidif’, para elegir la mejor estrategia de publicación de ‘Cliente Rico’ necesaria para implementar en organismos acorde a la estrategia definida, documento que se presentara al Comité el 23/04/07 y que propone una estructura de publicación centralizada, o sea no en las PC’s en forma local, sino utilizando servidores de emulación gráfica. Comentario de AGN: La información aportada corresponde al año 2006. En la eventualidad de una auditoría de seguimiento se analizará la misma. 4.11.7 Performance. Respuesta de la Secretaría de Hacienda: 1) El Comité de Performance mencionado efectivamente se generó ante la necesidad de analizar la situación a ese momento, debido a inconvenientes en el rendimiento de la aplicación luego de la implementación de Formulación Presupuestaria, en mayo de 2006. Efectivamente fue posterior al prototipo, pero anteriormente y luego de definir el marco de arquitectura, se realizaron pruebas de carga (en febrero-marzo de 2005). 2) Dicho Comité se constituyó ante la necesidad del momento, y no producto de una Página 98 definición metodológica de modo que dicho equipo fuera ya parte de una estructura estable de roles dentro del proyecto. Estuvo formado por todos los coordinadores de los grupos de trabajo, y se tomaron decisiones en ese grupo que han ido luego transformándose en acciones de mejora, las cuales se aplicaron. Todo eso se trató además en las reuniones generales de coordinación, internas al grupo de proyecto, que se realizan desde el inicio del mismo, todos los miércoles. 3) Las problemáticas de performance fueron evaluadas en el ámbito de dicho Comité, y con plena participación del equipo de Testing. Este equipo realiza pruebas funcionales y de performance, incluso con participación del equipo de réplicas, y mismo de usuarios que aprueban el paquete a pasar a producción. Y ha sido en este mismo ámbito que se han evaluado las mejoras propuestas por el Comité para luego aplicarlas en producción, de modo que con la misma metodología que se tratan las implementaciones de rutina, así se han tratado estas mejoras, excepto claro, con el acrecentamiento que la urgencia en producción demandaba. Comentario de AGN: Se sugiere transparentar las acciones desarrolladas sobre la performance. 4.11.8 Disponibilidad del servicio. Respuesta de la Secretaría de Hacienda: No compartimos el efecto mencionado, al menos en cuanto a su mención de no haber sido planificado todo lo referente a disponibilidad del servicio, por el uso de las redes y vínculos de comunicación. 1) Según Memo-S01:0050017/2006, y su referencia a otro anterior MemoS01:0096849/2005, puede verse que existen análisis y propuestas de revisión de la estructura actual, en relación a la conectividad y ancho de banda, proponiendo una revisión de la estrategia de contratación de los posibles proveedores y una solicitud de información a los responsables informáticos en relación a sus aplicaciones; Página 99 2) Por los requerimientos del nuevo SIDIF se han mantenido reuniones con los responsables técnicos de la UI, con el objeto de tener en cuenta dichos requerimientos en las ampliaciones planteadas para el Ministerio de Economía por el Proyecto Informático. Al respecto la UI a hecho pruebas y mediciones en forma conjunta con el PI. Para más detalles de las acciones sobre el tema se solicita remitir la consulta al PI. Comentario de AGN: Puntos 1) y 2). Se considera necesario establecer un acuerdo de servicio con el Proyecto Informático a los fines de garantizar un nivel adecuado en las comunicaciones del e-Sidif. 4.11.9 Seguridad de la aplicación Web. Respuesta de la Secretaría de Hacienda: Los efectos no aplican: 1) No existe tal carencia ya que en la implementación de cliente el usuario utiliza una aplicación de escritorio, y no un browser para ejecutar el sistema (ver punto 4.11.2). 2) Tal como se detalló en el punto 4.11.6, al tratar el equipamiento en los SAF’s, este análisis se realizó al analizar la estrategia de publicación de Cliente Rico. Las primeras implementaciones en la ONP, del negocio Presupuesto, se llevaron a cabo sobre la lógica de Cliente Rico instalado en las PC (esquema descentralizado), habiendo entonces quedado pendiente el análisis para cuando sea necesario implementar en el resto de los organismos. Al respecto, la decisión resultante ha sido la publicación centralizada (similar a la del SLU actual). Comentario de AGN: 1) Para la aplicación mencionada cabe los mismos términos de la observación relativos a la seguridad del lado SAF (cliente). Página 100 2) Las acciones mencionadas corresponden a un período posterior al evaluado. En la eventualidad de una auditoría de seguimiento se analizaran. 4.12 Objetivo de control: Definición de interfases. Respuesta de la Secretaría de Hacienda: Dado el avance y prioridades del Proyecto vigente al momento de realizarse el trabajo de campo de esta Auditoría aún no se había priorizado esta tarea de análisis y desarrollo de todas las interfaces, internas y externas. No obstante lo antes expresado, se contaba con un documento (ver “SI_CABA_Especificación_Integración de Sistemas Externos.doc”), creado en noviembre del 2004, en el cual puede verse el análisis realizado por lo referente a las interfaces internas, por ejemplo la comunicación entre los SLU’s, el SidifCentral y lo a implementarse en el eSidif (ver punto 2.2.1.2 del documento antes mencionado), como así también lo referido a interfases externas no existentes, y se cita el caso de la AFIP (ver punto 2.2.2). En el caso particular de la AFIP desde el 13/12/06 estamos interactuando con ellos, con el objetivo de adherir a los estándares que ellos utilizan respecto al acceso por ‘Web Services’ para consumir los servicios requeridos desde las aplicaciones mutuas. Y es éste el primer componente en que estamos trabajando para la integración con aplicativos externos. Adicionalmente, mencionamos que Gustavo Merino (Coordinador del Equipo de Diseño y Desarrollo), asistió a todas las presentaciones de la ONTI relacionadas con estos temas desde el inicio del proyecto. Comerntario de AGN: Sin comentarios. Página 101 4.13 Objetivo de control: Evaluación de la estrategia. 4.13.1 Convivencia. Respuesta de la Secretaría de Hacienda: Acerca de los riesgos mencionados consideramos conveniente considerar lo siguiente: • Se asegura el servicio sobre el SidifCentral; • Es inevitable que tengan dos menús mientras dure la transición; • Las réplicas serán modulares, lo cual acelera el proceso de reemplazo de los módulos del sistema anterior. Una vez replicado se mantiene solamente el nuevo producto; Para la implementación de FOP se minimizó el riesgo. Los usuarios dispusieron de la información en ambos entornos, por convivencia: en e-Sidif y en SidifCentral. Emitían los listados de control en ambos sistemas. Comentario de AGN: Sin comentarios. 4.13.2 Escenarios. Respuesta de la Secretaría de Hacienda: 1) Los objetivos del proyecto son tres. Uno de ellos, la actualización tecnológica en la industria del hardware y software, es inevitable, pues de lo contrario se cae en el riesgo de no disponer de soporte. Esto debe ser materia de comunicación a los usuarios, para que comprendan que el esfuerzo es inevitable. 2) Los escenarios analizados fueron seleccionados por los usuarios en función de sus preferencias y necesidades. Si bien no resultó en primera instancia el escenario elegido se acordó comenzar por FOP porque se minimizan los riesgos de convivencia Es además con él que se inicia el ciclo natural de la formulación presupuestaria. Se ejecuta en un solo Página 102 momento y deja como resultado los clasificadores presupuestarios del ejercicio, y las partidas presupuestarias con el crédito asignado. No tiene convivencia “on-line” una vez iniciado el ejercicio. 3) No acordamos con este efecto. La sinergia es un concepto que hemos priorizado al planificar la metodología del proyecto, y para ello la estructura de los talleres es una valiosa herramienta, a la vez que sus avances y logros se monitorean cada semana en las reuniones de Comité. Dados la referencia a la implementación de funcionalidad superior a la versión actual, nos parece pertinente incluir un resumen de dicha ampliación en el alcance, sobre todo dado que ello da cuenta de uno de los tres objetivos del proyecto ‘e-Sidifi’ (Ampliación del Alcance Funcional). 1. Se contempla la posibilidad de aumentar en un futuro la extensión de los códigos de algunas clasificaciones. La complejidad de las hipótesis de formulación presupuestaria se considerará en el manejo de versiones de clasificación. Algunas clasificaciones además de estar asociadas a un ejercicio presupuestario su vigencia ocurre recién con la firma de actos administrativos (Institucional, Entidades, Servicio Administrativo Financiero, Aperturas Programáticas). La necesidad de identificar mejor las iniciativas de gobierno hace necesario alargar la extensión de algunas descripciones. Se procurará que la ortografía responda al lenguaje español. La integración del presupuesto y su ejecución vigente con los escenarios de formulación presupuestaria (característica del modelo de administración financiera argentino) se expresa en las facilidades de actualizar las clasificaciones presupuestarias entre ambos subsistemas. 7. Manejo de etapas particulares para paralelizar el trabajo de los analistas presupuestarios. 8. Se contempla la participación del Servicio Administrativo Financiero en la formulación presupuestaria de los organismos dependientes de la jurisdicción y la Página 103 descentralización de la presupuestación cuando se realiza una gestión por programa. Para el caso de gestiones más descentralizadas se contempla la carga externa desde archivos de planilla de cálculo; 9. Auditorías y controles internos; 10. Listado variable del componente físico de programas y financiero proyectos; 11. Listado de Transferencias a Provincias y Municipios; 12. Listado Articulo 15; 13. Facilidades para Carga externa desde Planilla de Cálculo: próximo a implementarse; 14. Integración de la Programación y Ejecución Física con la Formulación Presupuestaria: próximo a implementarse. Comentario de AGN: 1). Es opinión de la AGN que las funcionalidades a desarrollar deben ser solo superiores a las existentes. Se sugiere 2) ajustar la metodología de evaluación de escenarios o formalizar los cambios a los resultados. 3) evaluar la incorporación de la agenda de la AF en el calendario de implementación de esidif que, a nuestro entender, incrementará sinergia al proyecto. 4.13.3 Necesidades de los Usuarios de los SAF. Respuesta de la Secretaría de Hacienda: Se han tenido en consideración desde el momento que se incluye la participación del grupo de Réplicas, quienes traen las inquietudes y necesidades de los organismos a las reuniones en las que participan. Es este grupo el que consulta específicamente a los organismos. Además, en el plan de implementación de Presupuesto en Organismos, por ejemplo, se decidió comenzar por SAF’s pilotos de Economía (MinPlan y Mecon). Página 104 Comentario de AGN: Lo que se observa es la necesidad de una participación formal de los SAF, principales operadores del sistema. 4.13.4 Metodologías. Respuesta de la Secretaría de Hacienda: Entendemos que no aplica esta observación dado que la aplicación no es un sitio Web que se accede mediante un browser, sino que es una aplicación de escritorio, que tiene a ‘Cliente Rico’ como la lógica de su capa de presentación. Comentario de AGN: Las ETAP's (Estándares Tecnológicos para la Administración Pública) pueden colaborar en el desarrollo de la arquitectura y contrataciones específicas. Con respecto a la Resolución 97/97 nos remitimos a los mismos comentarios realizados en el punto 4.11.2. 4.13.5 Integración de las herramientas de desarrollo. Respuesta de la Secretaría de Hacienda: El artefacto MDR, “Minuta de Requerimientos”, es un documento que formaliza el resultado de las actividades de captura de requerimientos. Si bien la MDR consolida información vinculada con requerimientos, reglas, términos del glosario, actividades, etc., este artefacto no constituye un modelo en sí mismo sino un insumo para el modelado posterior de requerimientos en UML. Con respecto al PIU, “Prototipo de Interfaz del Usuario”, si bien el EA (Enterprise Architect) ofrece funcionalidad que permite su diagramación, fue decisión del proyecto elaborarlos con el soporte de la herramienta ‘Power Point’, y un conjunto de templates “prearmados” por ser esta última una alternativa que permite representar la interfaz del Página 105 usuario de manera más real y elaborarla con una mayor productividad. Comentario de AGN: Se sugiere mejorar la integración -automática- entre las herramientas empleadas tanto para el diseño como la programación de las tareas pues ello obliga a estandarizar la producción de diseño (en el caso del MDR y PIU) y mejorar el control de la marcha del proyecto. Página 106