2007_136info.pdf

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