INFORME DE AUDITORÍA - agn.gov.ar · Se analizó la gestión del ciclo de vida del nuevo proyecto...

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

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

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

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.

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:

A C O D TOTALES

CUT NO CUT CUT NO CUT

SLU 24 6 50 0 80

PROPIO 6 2 1 1 10

CONPRE 3 3 1 4 11

SIDIF OD 1 2 3

Totales 33 11 53 7 104

AC: Administración Central.

OD: Organismo Descentralizado.

CUT: Cuenta Única del Tesoro.

Fuente: Sitio Web de la Administración Financiera.

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:

Gerencia del Proyecto

Coordinación General

Comité Organos RectoresSubsecretario de PresupuestoDirectores Organos Rectores

Coordinación de la UI

Equipo MultifuncionalMiembros de los O.R.

Asistente de Documentación

n de Arquitectura Coordinación Análisis Coordinación Diseño y Desarrollo Coordinación Ingeniería Coordinación Testing

rquitectura Física

Arquitectura de Aplicación

Subcordinación Presupuesto SubcoordinaciónTE, GS, P y V, FR, EN

Grupo Lifia Ingenieros Testers

Analistas Analistas

En esta tabla se describen las responsabilidades más importantes de cada componente dela estructura:

ROL RESPONSABILIDADESComité Órganos

Rectores

Sponsorear el proyecto en los distintos nivelespolíticos que lo requieran. Delinear las políticas queguiarán el proyecto. Facilitar recursos estratégicosal proyecto. Resolver conflictos de recursos Serúltimo nivel de decisión frente aconflictos/problemas Participar en la reuniónquincenal de avance.

Gerencia del Proyecto Planificar aspectos estratégicos del proyecto enfunción de las políticas definidas. Aprobar losrecursos técnicos y humanos requeridos por elproyecto Participar/Aprobar la planificación delproyecto Participar en las reuniones quincenales deavance del proyecto. Resolver conflictosestratégicos dentro del proyecto

Coordinación General Planificar las diferentes actividades del proyecto.Identificar riesgos y planificar acciones demitigación/prevención. Hacer el seguimientoregular de las actividades. Participar y supervisarlas decisiones técnicas del proyecto. Tomaracciones correctivas en el proyecto. Coordinar losrecursos asignados al proyecto. Elaborar losinformes de avance del proyecto. Participar enreuniones de trabajo que lo requieran. Participar enla reunión quincenal de avance. Facilitar elcompromiso para el cumplimiento de las políticasde calidad. Resolver conflictos operativos y derecursos.

EquipoMultidisciplinario

Funcional

• Participar en la planificación de los talleresfuncionales.

• Proveer los recursos para los talleresfuncionales. Participar en los talleresfuncionales.

• Colaborar en la preparación de losmateriales para los talleres funcionales.

• Decidir sobre cuestiones abiertas querequieren definición.

ROL RESPONSABILIDADES• Aportar conocimiento funcional y

normativo. Participar en el control deCalidad de los artefactos resultantes de lostalleres.

• Participar en la aprobación formal de losartefactos que produce el Equipo deAnálisis.

• Participar en la prueba de aceptación delproducto.

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 06-

Coordinació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 18-

Formulació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 InternetAño Crédito Presupuestario Devengado

2005 4.638.473 1.965.064

GASTOS EN 2004 2005 Total Período

CONSULTORES 3.092.717,00 Programa 18 – FOSIP 134.760,00 190.908,00 325.668,00 Programa 26 – Actividad 06 338.662,00 338.662,00 01 463.323,00 463.323,00 07 1.965.064,00 1.965.064,00 EMPRESAS DE CONSULTORÍA 715.561,69 Programa 18 - FOSIP 162.281,69 553.280,00 715.561,69 BIENES ADQUIRIDOS 383.073,00 Programa 18 - FOSIP 3.303,00 379.770,00 383.073,00TOTALES POR PROGRAMA 18 307.344,69 1.123.958,00 1.431.302,69 26 801.985,00 1.965.064,00 2.767.049,00TOTALES GENERALES 1.102.329,69 3.089.022,00 4.191.351,69

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

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

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

• 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

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.

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

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.

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

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

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.

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.

INGENIERIA DE PROCESOS

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.

ad ARTEFACTOS

MCN

«modelo»Modelo de Diseño

«modelo»Modelo de Clases de Análisis (MCA)

«modelo»Modelo de Casos

de Uso (MCU)

«modelo»Modelo de

Procesos del Negocio (MPN)

«modelo»Modelo de Reglas de Negocio (MRN)

«modelo»Glosario del

Negocio (GLO)

«modelo»Línea Base de

Requerimientos (LBR)

«modelo»Arquitectura del

Sistema

MDR / Documentos del Dominio

«modelo»Modelo de Objetos del Dominio (MOD)

«modelo»Modelo de

Implementación (MDI)

«modelo»Modelo de Interfaz

de Usuario (MIU)

«documento»Guía de Usabilidad

«documento»Guía de Diseño

«use»

«realize»

«refine»

«refine»«trace»«realize»

«use»

«use»

insumo

«use»

«realize»

«trace»

«trace»insumo

insumo

«trace»

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

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.

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.

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.

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.

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.

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

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

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.

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.

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.

NEGOCIOS Minutas de

Requerimientos

Linea Base de

Requerimientos

Descripción

FuncionalAgenda Calidad Presentación

Administración de Bienes Bienes de Consumo O X O X O O

Bienes Inmuebles X X O O O O

Bienes Muebles y X X O O O O

Recepción Bienes y Servicios X X O X X X

Cambio de Ejercicio O X X O O O

Compras O O X O X O

Integración Sistemas ONC X X X X X O

Momentos de Compras O X X X X X

Plan Anual de O X X X X X

Contabilidad O X O O O O

Entes O O X O O O

Fondos RotatoriosGeneral Fondos Rotatorios (DF y DA) O X X O X O

Constitución FR (Creación y O X X O X O

Multimoneda X X X O X O

Gastos Deducciones O X X O X O

Operaciones O O X O X O

Regularizaciones X X X O X O

Personal O X X O X X

Gastos Figurativos O O X O O O

Impuestos y Servicios O O O O O O

Momentos del Gasto O X X O O O

Remanentes X X X X X X

Servicios de la Deuda O X X O O O

Transferencias O O O O O O

Comisiones Bancarias O X X X O X

Gestión de Compras X O X X X X

Sin Gestión de Compras X O X X X X

No Presupuestarios X O X X X X

Multifactura X O X X X X

RRHH X O X X X X

Desembolsos Externos X X X X X X

Requerimientos Generales

X O X X X X

General General Inicial X X X X X X

Centro de Costos O X X O O O

Cierre X X X O X X

MultiSAF y SubSAF O X O O O O

Unidades Organizativas O X X O O O

Pasajes y Viáticos O O O O O XPresupuesto

Comunicación de Clasificadores Presup.

O X X X X X

Anteproyectos Extra APN X X X X X X

Escenarios Sluna X X X X X X

Proyecto de Ley X X X X X X

Relación con Bapin II O X X O X X

Relación con PROA X X X X X X

Relación con SIRHU X X X X X X

Revisión de Av fisico y X X X X X X

Salida de Información – Pres. X X X X X X

Alcance de Aplicación del Sistema_Art O X X O O O

Artículo 15 Ley 24156 O X X X O X

Interfaz con Bapin II O X X O O O

SIRHU X X X X X X

Acto Administrativo X X X X X X

AIF X X X X X X

General X X X O X X

Propuesta MP X O X X X X

Facultades Delegadas X X X X X X

MP SAF X X X O X O

MP SLU ONP X O O X X O

Programación y Cierre de Cuota O X X X O X

Programación y Ejecución Física X X O X X X

Formulación Presupuestaria X X O X X X

Recursos Humanos X X X X X X

TesoreríaCesiones X O O O X X

Conciliación Bancaria X O O O X X

Cuenta Única del Tesoro X O O O X X

Cuentas a Cobrar O O X O O X

Fideicomiso X O O O X X

General O X X O O O

Medidas Afectación Patrimonial X O O O X X

Pagos X O X O X X

Pagos en Títulos O O X X O X

Programación Financiera X X O O X X

Recursos X X O O X X

Remanentes O O O O O X

Retenciones por OSIRIS X X X X X X

Retenciones y Deducciones X X O O X O

Embargos X X X X X X

Uepex_Presupuesto O X X O X X

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.

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.

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.

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.

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.

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 e-

SIDIF.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

6. LUGAR Y FECHA DE LA EMISIÓN DEL INFORME:

Buenos Aires, diciembre de 2006

FIRMA:

ANEXO

RESPUESTAS DE LA SECRETARÍA DE HACIENDA Y COMENTARIOS DE LAAGN.

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.

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.


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.


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.


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.

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

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.


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

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.

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.


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

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.


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.


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.

4.5 Objetivo de Control: Enfoque de Evaluación de Riesgos.


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

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

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

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

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

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

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.


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 07-

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

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.


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.


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.

4.6.2 Comunicaciones.


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

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.


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

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.


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

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

4.8 Objetivo de Control: Marco de Referencia para la Administración de Proyectos .


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.


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 07-

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

Cabe destacar también que el desafío que impone el cambio tecnológico ha obligado a re-

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

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.


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

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.

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

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.


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

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.


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" <[email protected]>To: "Marta Vazquez" <[email protected]>Cc: "Susana Vega" <[email protected]>; "SilvinaRey"<[email protected]>; "Ana Hurtado"<[email protected]>; "Diana Boeykens"<[email protected]>Sent: Wednesday, November 24, 2004 9:52 PMSubject: SIDIF INTERNET

> Por indicación de la Sra Directora Nacional dePresupuesto> Lic. Susana Vega

> se presta conformidad al avance a la fecha delmodelo conceptual de> e-sidif> y a las matrices de evaluación de escenarios.> Atte.> Susana Luna>

-----Mensaje original-----De: Raúl Rigo [mailto:[email protected]]Enviado el: Domingo, 07 de Noviembre de 2004 10:18 p.m.Para: [email protected]; [email protected]; Cesar Duro;Carlos Santamaría; Ricardo Bruzzi; Ester LagomarsinoCC: Marta VazquezAsunto: SIDIF INTERNET

Estimados, El pasado viernes estuve repasando con Marta el grado de avance delas actividades que acordàramos en la ùltima reuniòn de directoresvinculadas con SIDIF Internet. En ese sentido, les envìo un recordatorio que documentos a entregardurante esta semana. Encarezco respetar las fechas sugeridas porqueestamos muy ajustados con el cronograma de actividades previstashasta fin de año.

Saludos.

RR

Ejemplo nº 2:

----- Original Message -----From: Cesar DuroTo: [email protected]: Monday, November 08, 2004 6:33 PMSubject: E-sidif: Aprobación Matrices de Evaluación de Escenarios

Se adjuntan los archivos con la aprobación formal de laevaluación de los escenarios, para su consideración.

Dr. César Sergio Duro

CONTADOR GENERAL DE LA NACIÓN

Ejemplo nº 3:

A Todos:Por medio del presente informo el estado de situación respecto a larevisiónde 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:

e-SIDIF - Casos de Uso de PagosFecha:Fri, 26 Nov 2004 17:33:43 -0300

De:"Pablo Buratti" <[email protected]::"Silvia Bosco" [email protected], Javier Martínez

<[email protected]:Raúl Rigo <[email protected], "Jorge Domper"

<[email protected], "Alejandra Arriola"<[email protected], "Marta Vazquez"[email protected]

Referencias:<[email protected]

Chequeras y Cheques:Se deben incorporar las funciones de Impresión, Anulación deImpresión, yCambio de Orden de Cheque (cambio de identificación de beneficiariodelcheque)

-Lotes de Pago:Se deben incorporar la funciones de Desautorizar Lote de Pago yReversión deProcesar Respuestas del Banco Pagador.

-Notas de Pago:Se deben incorporar las funciones de Modificar Nota Ingresada (previoa laautorización), Impresión y Anulación de Impresión. Se sugiere verificarladisponibilidad de funciones de anulación en las distintas etapas delprocesamiento de las Notas de Pago (ingreso, impresión, firma),verificandoque estén contemplados los circuitos definidos en el Análisis Global dePagos por Nota de la Reingeniería del SIDIF Central.

-Pagos:Se debe incorporar la función de anulación de pagos, separada de lafunciónde desafectación.Se sugiere modificar la función "Modificar Pagador" denominándola"ModificarOP", incluyendo en dicha función la modificación de pagador, lamodificaciónde fecha de bonificación, y la confirmación de recepción de OP parapago porNota.

-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

Cautelares", incluyendo en este concepto Embargos, Concursos yQuiebras.Se debe incorporar en la función "Levantar Embargo", la función deInhibirEmbargo.Se solicita verificar el alcance de la función "Modificar Monto deEjecuciónde Embargo". En principio la misma no se considera procedente.

-Listados Gerenciales:El caso de uso presentado no es representativo en términos de lasnecesidades del Órgano Rector en materia de Listados Gerenciales. Alrespecto existen numerosas opciones de listados no contempladas enel Casode Uso que son utilizados habitualmente por los usuarios del ÓrganoRector.Se sugiere verificar los requerimientos de Consultas y Listadosdefinidos enel 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 laDistribución Diaria de Pagos por Concepto.

-Selección de Pago:En relación a este caso de uso debe analizarse cómo se resolverá lasfunciones que actualmente realiza el Órgano Rector sobre los pagosenviadospor los SAF no SLU: Recepción de selecciones de pago, recepción deautorizaciones de pago, anulación de recepción, ingreso manual deautorizaciones de pago, cambio de cuenta de cesionario.Debe analizarse cómo se resolverá el proceso de recepción de OPpapel enTGN, si se mantiene o si dicha gestión será eliminada por el uso decomprobantes con firma digital.

-Chequeras y Cheques:Debe considerarse en el módulo de Fondos Rotatorios la posibilidad de

agrupar en un único cheque varios Vales o Solicitudes de PVEA, asícomotambién la posibilidad de agrupar en un único cheque las retencionesde

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/AlgoritmoPagador debeestar acotada a nivel de los Órganos Rectores.

-Pagos:Se considera que la funciones de Desafectar Pago/RegularizarDiferencia deCambio corresponden a usuarios encargados de procesar conciliaciónbancaria,antes que a usuarios encargados de la gestión de pagos.Se considera que la función Descentralizar/Centralizar función de Pagodebeestar acotada a nivel de los Organos Rectores.

-Cesiones/Aplicación de Cesiones/Cumplimiento deCesiones/Comprobantes deCesiones:Se considera necesaria la verificación de los casos de uso por parte delequipo de Réplicas SLU.

-Sicore/Concepto de Retención/Beneficiario de Retención/Excepción aRetención/Retenciones/Concepto Impositivo/Algoritmo de Retención:Se considera necesaria la revisión de los casos de uso por parte delequipode Réplicas SLU.

Quedo a disposición por cualquier consulta relacionada con elpresente.

AtentamenteLic. Pablo Ricardo BurattiCoordinador de ProyectosTesorería General de la NaciónMinisterio de Economía y Producción

TE 4349-6490 FAX 4349-6496

Ejemplo nº 4-adjunto:

-----Mensaje original-----De: Carlos Pablo Maza [mailto:[email protected]]Enviado el: Jueves, 10 de Junio de 2004 10:09 a.m.Para: Susana LunaAsunto: 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 <[email protected]>> A: Rosa Nieva (CGN) <[email protected]>,Viviana Gomez<[email protected]>,Pablo Buratti (TGN)<[email protected]>,María del Carmen Norry (TGN)<[email protected]>,Susana Luna (ONP)<[email protected]>,Emilce Angel Torres<[email protected]>,Roberto Boccardo <[email protected]>,[email protected],[email protected]> CC: Marta Vazquez <[email protected]>>> Estimados,>> se envía la minuta del Taller de Bienes Inmuebles realizado el 27/05

> con el formato definido por la metodología.

>> Pido disculpas por la demora pero la semana pasada estuve variosdías> enferma.>> Haganme llegar las dudas, comentarios y observaciones para asipublicar> 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 [email protected]> --------------------->> ------------------------------------------------------------------------> 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 <[email protected]>PARA::María Alejandra Arriola <[email protected]>

Esta Oficina Nacional no tiene observaciones que formularAtte.Susana Luna

Ejemplo nº5:

----- Original Message -----From: CESAR DURO

To: '[email protected]'Cc: JDOMPE ; RBRUZZ ; '[email protected]' ; CARLOS SANTAMARÍA

(E-MAIL) ; '[email protected]'Sent: Monday, May 17, 2004 3:02 PMSubject: REQUERIMIENTOS DEL SIDIF INTERNET -ENTES

Por medio del presente presto conformidad en general al contenido dela minuta del taller de Entes del 23/04/04. En cuanto a los aspectos particulares que generan algún comentariodestaco los siguientes: 3. Sectores y roles que intervienen.Los entes bancos se darán de alta por la TESORERÍA GENERAL DELA 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 aobtener desde la AFIP”, esta regla corresponde al requerimiento 6: “Elsistema debe capturar de padrón de AFIP la información de los entesque dicho Org. Admin.” y no al 7 que se refiere a los datos del códigopostal.-6.3.1. 10. El sistema debe capturar de padrón de AFIP la informaciónde los entes que dicho Org. Admin."Ventajas, el segundo ítem, cambiar la palabra “llevando” del final delpárrafo por “efectuando”.

6.5. Requerimientos para procesos relacionados. Circuito de embargos: Para el circuito de embargos nunca se usabeneficiarios 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 latabla de entes, si existe entonces le asocia el numero de Ente, si noexiste igual deja cargar el embargo.De esta forma si se da de alta un Ente cuyo número de DNI figura en latabla de Embargos sin numero de Entes se puede actualizar este datoen la misma, y de esa manera se incrementa significativamente laposibilidad de cargar los embargos que hoy no se pueden cargarporque el Ente no esta cargado.Esto es de suma importancia porque los embargos informados por losjuzgados no siempre traen el CUIT. Atte. Dr. César Sergio DuroCONTADOR GENERAL DE LA NACIÓN -----Mensaje original-----De: Cesar DuroEnviado el: Viernes 14 de Mayo de 2004 09:31Para: Rosa NievaAsunto: RV: REQUERIMIENTOS DEL SIDIF INTERNET

teneme esto listo

-----Mensaje original-----De: Raúl Rigo [MAILTO:[email protected]]Enviado el: Viernes 14 de Mayo de 2004 09:25Para: [email protected]; [email protected]; Cesar Duro;Carlos SantamaríaAsunto: REQUERIMIENTOS DEL SIDIF INTERNET

Estimados,

En el desarrollo de SIDIF Internet, estamos trabajando sobre la minutade requerimientos referida a entes, que surgiò del trabajo del equipo

multidisciplinario. Dicha minuta fue remitida a los órganos rectorespara comentarios, observaciones y aprobación.

Solicito vuestras intervenciones para, luego, continuar con laelaboración de los requerimientos de base a la arquitectura delsistema.

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

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


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.

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.


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.


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

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 documentos “CGN-

SI_Taller_Bienes_Inmuebles1.doc”, “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

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.

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 MDR LBR Desc. Func ADR QA Presentación PptPresupuesto 6 4 4 7 19 19Gastos 0 0 10 0 12 10Tesorería 8 1 4 2 11 13Fondos Rotatorios 1 1 1 0 3 0Compras yContrataciones

1 1 2 0 4 2

UEPEX 1 2 2 1 1 1

General 2 2 2 1 2 2

Administración deBienes

0 0 0 0 1 1

Pasajes y Viáticos 0 0 0 0 0 1

Totales 19 11 25 11 53 49

TOTAL GENERAL 168

4.11 Objetivo de Control: Arquitectura de Información.


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

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.


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:

Característica Web / AppServer Juntos

sinsubparticiones

Web / AppServer Juntos

consubparticiones

Web / AppServer

Separados

Web Caching

Disponibilidad

TransparentFailover

No se asegura

este servicio, ya

que si bien el

load balancer

permite rutear el

pedido a un

server activo, no

se mantiene la

sesión del

usuario.

El nivel de prestación respecto a estacaracterística es bueno, ya que el load balancerdetecta la caída de los servidores y rutea lospedidos a los activos, y mediante laconfiguración de subparticiones con más de unainstancia se mantienen las sesiones de usuario.A mayor cantidad de servidores en el cluster yen las subparticiones se mejora respecto a esteaspecto.

QuickAutomatedRestarts

Esta característica depende la funcionalidad provista por el

servidor de aplicaciones, no de la configuración del cluster.

SharedCluster State

No posee Se provee mediante el mecanismo desubparticiones.

Single Pointof Failure

El load balancer El load balancer

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

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-03-

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


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

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.


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

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.


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.


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

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.


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

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.


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 Memo-

S01: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;

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.


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

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.


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 e-

Sidif (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.

4.13 Objetivo de control: Evaluación de la estrategia.

4.13.1 Convivencia.


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.


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

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

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 e-

sidif que, a nuestro entender, incrementará sinergia al proyecto.

4.13.3 Necesidades de los Usuarios de los SAF.


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

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.


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.


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

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.

INFORME DE AUDITORÍA - agn.gov.ar · Se analizó la gestión del ciclo de vida del nuevo proyecto...

Documents

Transcript of INFORME DE AUDITORÍA - agn.gov.ar · Se analizó la gestión del ciclo de vida del nuevo proyecto...