universidad para la cooperación internacional (uci) “plan
TRANSCRIPT
I
Universidad para la Cooperación Internacional
(UCI)
“Plan de proyecto para la Implementación de una solución tipo single sign – on en el Instituto nacional de
Seguros para las plataformas os/400, WINDOWS Y AIX”
Lcda. Yorleny Retana Mejía
Proyecto Final de graduación presentando como requisito parcial para optar por el título de máster en
administración de proyectos
San José, abril, 2008
II
Universidad para la Cooperación Internacional
Este Proyecto Final de Graduación fue aprobado por la Universidad como requisito parcial para optar por el
grado de Máster en Administración de Proyectos
______________________
Lic. OSCAR ESQUIVEL BARQUERO, MAT
___________________________ ______________________________
Map. Ericka gonzaleZ map. Juan carlos navarro
__________________________
Lcda. Yorleny Retana Mejía
Sustentante
III
DEDICATORIA
A mi madre, por ser el soporte y la razón por la cual hoy cumplo una nueva meta
profesional en mi vida.
A mi abuelita Carmen, por alentarme siempre a ser mejor.
IV
RECONOCIMIENTO
A Dios, mi todo, mi razón de ser, por hacerme creer en mí misma y en los logros
que puedo alcanzar.
A mi madre, por todos los sacrificios hechos para hacer de mí una profesional.
Al INS por permitirme en 11 años, alcanzar muchas metas; esta es una más de las
que espero lograr dentro de esta noble empresa.
A los compañeros de los Departamentos de Gestión de Servicios de Tecnología y
Telecomunicaciones y Mantenimiento de Sistemas, por ser un apoyo tan
importante para la finalización de este proyecto, el cual espero se haga una
realidad.
V
INDICE DE CONTENIDO
1 INTRODUCCIÓN.......................................................................................... 1
1.1 Antecedentes................................................................................................ 1
1.1.1 Dirección de Informática .................................................................... 2
1.1.1.1 Departamento de Operación y Soporte Técnico ............................ 2
1.2 Problemática que da origen al PFG.............................................................. 2
1.3 Justificación del proyecto.............................................................................. 3
1.4 Objetivos del proyecto .................................................................................. 4
1.4.1 Objetivo General ................................................................................ 4
1.4.2 Objetivos específicos ......................................................................... 4
2 MARCO TEÓRICO....................................................................................... 6
2.1 MARCO INSTITUCIONAL ............................................................................ 6
2.1.1 Reseña Histórica del Instituto Nacional de Seguros. ......................... 6
2.1.1.1 Las Direcciones y sus funciones .................................................... 6
2.1.2 El negocio de los Seguros ................................................................. 9
2.1.3 La Dirección de Modernización e Informática .................................. 10
2.2 MARCO CONCEPTUAL............................................................................. 11
2.2.1 Conceptos básicos sobre Sistemas de Información ........................ 11
2.2.1.1 Datos............................................................................................ 11
2.2.1.2 Sistema ........................................................................................ 12
2.2.1.3 Sistemas de Información.............................................................. 12
2.2.1.4 Ciclo de Vida de un Sistema de Información................................ 13
VI
2.2.1.5 Interfaces...................................................................................... 16
2.2.1.6 Interface de Usuario ..................................................................... 17
2.2.1.7 Usuarios Expertos o Usuarios Finales ......................................... 17
2.2.2 Plataformas...................................................................................... 18
2.2.2.1 Plataforma de Software................................................................ 18
2.2.2.2 iSeries .......................................................................................... 20
2.2.2.2.1 Plataforma OS/400 ............................................................................. 21
2.2.2.3 Pseries o RS/6000 ....................................................................... 22
2.2.2.3.1 Plataforma pSeries.............................................................................. 22
2.2.3 Seguridad de los Sistemas de Información...................................... 23
2.2.3.1 Términos relacionados con la seguridad informática ................... 23
2.2.3.2 Políticas de Seguridad ................................................................. 24
2.2.3.3 Claves de Acceso......................................................................... 25
2.2.4 Métodos de autenticación de usuarios............................................. 25
2.2.4.1 Soluciones tipo Single Sign – On ................................................. 25
2.2.4.1.1 Que es el Single Sign On.................................................................... 25
2.2.4.1.2 Arquitecturas ...................................................................................... 27
2.3 Teoría de la Administración de Proyectos .................................................. 33
2.3.1 Marco Conceptual de la Administración de Proyectos..................... 33
2.3.2 Qué es un Proyecto ......................................................................... 33
2.3.3 Qué es la Dirección de Proyectos.................................................... 34
2.3.4 La Administración de Proyectos....................................................... 35
2.3.5 Ciclo de vida de los Proyectos......................................................... 35
VII
2.3.5.1 Características del Ciclo de Vida de un Proyecto......................... 36
2.3.6 Interesados en el Proyecto .............................................................. 37
2.3.7 Procesos de Dirección de proyectos para un proyecto.................... 37
2.3.7.1 Procesos de Dirección de Proyectos............................................ 39
2.3.7.2 Grupos de procesos de Dirección de Proyectos .......................... 39
2.3.7.3 Correspondencia de los procesos de dirección de Proyectos...... 40
2.3.8 Áreas de Conocimiento de la Administración de Proyectos............. 42
3 MARCO METODOLÓGICO........................................................................ 45
3.1 Descripción de la Metodología ................................................................... 45
3.1.1 Descripción del método de investigación......................................... 45
3.1.2 Tipo de investigación ....................................................................... 45
3.1.3 Fuentes de Información ................................................................... 46
3.2 Descripción de las Herramientas................................................................ 46
3.2.1 Declaración del Alcance .................................................................. 46
3.2.2 EDT (Estructura de Desglose de Trabajo) ....................................... 47
3.2.3 Diccionario de la EDT ...................................................................... 47
3.2.4 Programa del Proyecto .................................................................... 47
3.2.5 Ruta Crítica ...................................................................................... 47
3.2.6 Diagrama organizacional del Proyecto ............................................ 47
3.2.7 Matriz de Roles y Responsabilidades .............................................. 48
3.2.8 Matriz de involucrados o interesados............................................... 48
3.2.9 Matriz de comunicación ................................................................... 48
VIII
3.2.10 Informes de Seguimiento del Proyecto ............................................ 48
3.2.11 Juicio Experto .................................................................................. 48
3.2.12 Sistema de Control de Cambios ...................................................... 49
3.2.13 Reuniones........................................................................................ 49
3.2.14 Minutas ............................................................................................ 49
3.2.15 Diagrama de Gantt........................................................................... 49
3.2.16 Matriz de evaluación de Alternativas ............................................... 50
3.2.17 Lecciones Aprendidas...................................................................... 50
3.2.18 Investigación de mercado ................................................................ 50
3.2.19 Definición de Requerimientos .......................................................... 50
3.2.20 Cartel ............................................................................................... 51
3.2.21 Acta de cierre administrativo del proyecto ....................................... 51
3.2.22 Acta de cierre de entregables .......................................................... 51
3.2.23 Acta de comunicación de Cierre ...................................................... 51
3.2.24 Herramientas de Software ............................................................... 52
3.2.24.1 Microsoft Project........................................................................... 52
3.2.24.2 Microsoft WBS Chart Pro ............................................................. 52
3.2.24.3 Editor de Texto Microsoft Word .................................................... 52
3.2.24.4 Hoja de Cálculo Microsoft Excel................................................... 52
3.2.24.5 Lotus Notes .................................................................................. 52
4 DESARROLLO ........................................................................................... 53
4.1 Ciclo de Vida del Proyecto.......................................................................... 53
IX
4.1.1 Descripción de Fases del Proyecto.................................................. 53
4.2 Plan de Gestión del Alcance del Proyecto.................................................. 54
4.2.1 Planificación del Alcance ................................................................. 55
4.2.2 Definición del Alcance...................................................................... 55
4.2.2.1 Objetivo del proyecto.................................................................... 55
4.2.2.2 Alcance ........................................................................................ 56
4.2.2.2.1 Entregables ......................................................................................... 56
4.2.2.2.2 Mediciones ......................................................................................... 56
4.2.2.2.3 Exclusiones......................................................................................... 56
4.2.2.2.4 Restricciones....................................................................................... 57
4.2.2.2.5 Supuestos ............................................................................................ 57
4.2.3 Estructura de Desglose del Trabajo................................................. 57
4.3 Plan de Gestión del tiempo del Proyecto.................................................... 57
4.3.1 Definición de Actividades................................................................. 58
4.3.2 Secuencia y Dependencia de las actividades.................................. 58
4.3.3 Estimación de las duraciones de las actividades............................. 59
4.4 Plan de Gestión de Recursos Humanos..................................................... 60
4.4.1 Organización del Proyecto............................................................... 60
4.4.1.1 Estructura del equipo de Trabajo ................................................. 60
4.4.1.2 Roles y responsabilidades del equipo de proyecto ...................... 60
4.4.1.3 Matriz de Roles y Responsabilidades .......................................... 62
4.4.1.4 Responsabilidades y obligaciones ............................................... 64
4.4.1.5 Entregables del Proyecto ............................................................. 65
4.5 Plan de Comunicaciones ............................................................................ 66
X
4.5.1 Herramientas de Comunicación....................................................... 67
4.6 Gestión de las Adquisiciones...................................................................... 68
4.6.1 Planificación de la Adquisición......................................................... 68
4.6.1.1 Identificación de la Necesidad...................................................... 68
4.6.1.2 Presupuesto ................................................................................. 69
4.6.2 Planificación de la contratación........................................................ 69
4.6.2.1 Elaboración del Pliego de Condiciones ........................................ 69
4.6.2.1.1 Encabezado del Cartel ........................................................................ 69
4.6.2.1.2 Capítulo Uno de la licitación .............................................................. 70
4.6.2.1.3 Capítulo Dos de la Contratación......................................................... 75
4.7 Seguimiento y Control ................................................................................ 78
4.7.1 Herramientas de Seguimiento y Control del Proyecto ..................... 79
4.8 Lecciones Aprendidas ................................................................................ 80
4.9 Cierre del Proyecto..................................................................................... 80
5 Conclusiones .............................................................................................. 81
6 Recomendaciones...................................................................................... 83
7 BIBLIOGRAFÍA........................................................................................... 85
8 ANEXOS..................................................................................................... 87
8.1 PERFIL DE PROYECTO............................................................................ 87
8.2 WBS PROPUESTO.................................................................................... 91
8.3 CRONOGRAMA DE PROYECTO .............................................................. 92
8.4 Matriz de Comunicaciones ......................................................................... 95
8.5 Estatus Semanal ........................................................................................ 96
XI
8.6 Minutas ....................................................................................................... 97
8.7 Entradas de Reunión.................................................................................. 98
8.8 Solicitud de Cambio.................................................................................... 99
8.9 Aprobación de Criterios de Aceptación..................................................... 100
8.10 Acta de Aceptación de entregables .......................................................... 101
8.11 Acta de Cierre Administrativo ................................................................... 102
8.12 Acta de Comunicación de Cierre .............................................................. 103
8.13 Lecciones Aprendidas .............................................................................. 104
9 ENTREGABLES ....................................................................................... 110
9.1 Portada ..................................................................................................... 110
9.2 Investigación de mercado Soluciones Tipo Single Sign – On................... 111
9.2.1 Objetivo principal ........................................................................... 111
9.2.2 Soluciones Tipo Single Sign - On existentes en el Mercado Nacional 111
9.2.2.1 Empresa GBM de Costa Rica .................................................... 111
9.2.2.1.1 Producto: IBM Tivoli Access Manager for Enterprise Single Sign - On
V 5.0 (TAM E-SSO)........................................................................................... 111
9.2.2.2 Empresa CR Conectividad ......................................................... 122
9.2.2.2.1 Producto: Citrix® Password Manager.............................................. 122
9.3 Identificación de Requerimientos.............................................................. 129
9.3.1 Identificación de Sistemas por Plataforma..................................... 129
9.3.2 Esquema de Seguridad ................................................................. 131
9.3.3 Active Directory.............................................................................. 141
XII
9.3.3.1 Esquema de Autenticación del Active Directory ......................... 141
9.3.3.2 Esquema de Alta Disponibilidad del Active Directory ................. 141
9.4 Estudio de Factibilidad.............................................................................. 143
9.4.1 Estudio Técnico ............................................................................. 143
9.4.1.1 Antecedentes ............................................................................. 143
9.4.1.2 Finalidad Pública que se pretende satisfacer con el concurso... 144
9.4.1.3 Estudio costo – beneficio ........................................................... 147
9.4.1.3.1 Beneficios de adquirir una solución Single Sign On........................ 148
9.5 Cartel ........................................................................................................ 150
XIII
INDICE DE ILUSTRACIONES
Figura No 1 Organigrama del Instituto Nacional de Seguros (Dpto. Planificación del INS, 2007) ......................................................................................................... 8
Figura No 2. Organigrama Estructura Funcional Dirección de Modernización e Informática. (Manual General de Organización y Funciones, 2005)...................... 10
Figura No 3 Actividades del ciclo de vida clásico de desarrollo de sistemas (Senn, 1992) ..................................................................................................................... 16
Figura No 4 Plataforma de Software básica (Morfeo, 2007) ................................ 20
Figura No 5 Modelo iSeries IBM System iTM 595. (System Support,2007) ......... 21
Figura No 6 Servidor pSereis IBM (Redsis,2007)................................................. 23
Figura No 7. Arquitectura Password Vault ........................................................... 28
Figura No 8. Administración centralizada con almacenamiento local de credenciales .......................................................................................................... 28
Figura No 9. Administración y almacenamiento de credenciales centralizados ... 29
Figura No 10. Arquitectura SSO totalmente distribuida........................................ 30
Figura No 11. Administración y almacenamiento de credenciales centralizados con esquema de alta disponibilidad y redundancia...................................................... 31
Figura No 12 Fases del ciclo de vida de un proyecto, PMI, 2004......................... 37
Figura No 13. Estructura del equipo de Trabajo................................................... 60
Figura No 14 WBS del Proyecto........................................................................... 91
Figura No 15 Cronograma del Proyecto................................................................ 94
Figura No 16 Plantilla de Estatus Semanal………………………………………….. 96
Figura No 17 Plantilla de minuta de reunión …………………………………………97
Figura No 18 Plantilla de Entrada de Reunión ..................................................... 98
XIV
Figura No 19 Plantilla de Solicitud de Cambio ...................................................... 99
Figura No 21 Plantilla de Acta de aceptación de entregables ............................. 101
Figura No 22 Plantilla de Acta de Cierre Administrativo del Proyecto ................. 102
Figura No 23 Plantilla de Acta de comunicación de Cierre ................................ 103
Figura No 24 Diseño del Directorio Activo del INS............................................. 142
XV
INDICE DE CUADROS
Cuadro No 1 Correspondencia de los Procesos de Dirección de Proyectos a los Grupos de Proceso (PMI, 2004). Adaptación de Yorleny Retana, 2007. ............. 40
Cuadro No 2. Patrocinador del Proyecto............................................................... 61
Cuadro No 3. Gerente del Proyecto ...................................................................... 61
Cuadro No 4. Consultores Externos...................................................................... 61
Cuadro No 5. Grupo de Apoyo al Proyecto ........................................................... 62
Cuadro No 6 Matriz de Roles y Funciones del Proyecto ....................................... 63
Cuadro No 7 Desglose del Plan de Entregables ................................................. 65
Cuadro No 8 Información principal y autorización del Proyecto ............................ 87
Cuadro No 9 Declaración del Alcance del Proyecto.............................................. 89
Cuadro No 10 Matriz de Comunicaciones del Proyecto ........................................ 95
Cuadro No 11 Características, ventajas y beneficios de IBM Tivoli Access Manager............................................................................................................................ 113
Cuadro No 12. Cuadro comparativo, bondades Password Manager según licenciamiento...................................................................................................... 126
Cuadro No 13 Usuarios por Plataforma AS/400.................................................. 129
Cuadro No 14 Usuarios por Plataforma AIX........................................................ 130
Cuadro No 15 Usuarios por Plataforma Windows ............................................... 130
Cuadro No 16 Otras herramientas de uso Administrativo ................................... 131
Cuadro No 17 Versiones S.O y Esquema de autenticación Plataforma AS/400 por Aplicación............................................................................................................ 133
Cuadro No 18 Versiones S.O y Esquema de autenticación Plataforma AIX por Aplicación............................................................................................................ 135
XVI
Cuadro No 19 Versiones S.O y Esquema de autenticación Plataforma Windows por Aplicación...................................................................................................... 137
Cuadro No 20 Otras herramientas de Uso Administrativo................................... 140
XVII
INDICE DE ABREVIACIONES
ABREVIATURAS Y TÉRMINOS IMPORTANTES
PMI Instituto de Administración de Proyectos (Project Management
Institute) EDT Estructura detallada del trabajo TI Tecnología de la información Microsoft Office Herramienta de Software utilizada para crear y editar documentos. Microsoft Project Herramienta de software utilizada para controlar las actividades, costos y tiempo de los proyectos. WBS Chart Pro Herramientas de software para diseño de diagramas EDT OS/400 Plataforma de Servidores de la tecnología AS/400 UNIX Sistema operativo AIX Windows Sistema Operativo. EAI Enterprise Application Integration SSO Single Sign – On R.T Riesgos del Trabajo
.
XVIII
Resumen Ejecutivo
El Instituto Nacional de Seguros fue creado mediante la ley No 12, del 30 de Octubre de 1924, con el propósito de responder a las necesidades de protección de los costarricenses. Desde esa fecha y hasta el día de hoy, el INS ha evolucionado respecto a los productos que ofrece a sus clientes, de acuerdo al incremento poblacional y entorno ambiental, social y económico del país. Actualmente, se ofrecen una serie de pólizas para proteger al ciudadano de distintos riesgos, como pólizas de vida, Automóviles, R.T, pólizas estudiantiles, de Incendio, Robo y otras. En la década de los 90’s, el INS inicia una transformación de sus plataformas tecnológicas, adquiriendo la Plataforma OS/400 y posteriormente las Plataforma Windows y UNIX, las cuales albergan aproximadamente el 80% del negocio institucional. En los últimos 5 años, el INS ha transformado también su estructura funcional, creando Plataformas de Servicios. A través de estas, un funcionario de atención al público puede brindar a su cliente un servicio que permite, que en un solo lugar, una persona pueda adquirir distintas pólizas según sean sus necesidades de protección. A pesar de lo anterior, las pólizas son albergadas en distintos sistemas, lo que significa que un usuario maneja alrededor de 5 claves diferentes de acceso para las distintas gestiones de aseguramiento. A raíz de ello, la Dirección de Informática del INS, ha considerado la necesidad de buscar una herramienta que permita mediante un acceso único, acceder a todas las aplicaciones requeridas por los usuarios de las Plataformas, y así reducir problemas tales como administración de claves, Recurso Humano dedicado en más de un 50% a labores de administración de claves, usuarios finales ejerciendo una inadecuada administración de claves, deterioro en el servicio al cliente, además de una reducción significativa de los costos de administración de usuarios. Dentro de las herramientas que el mercado ofrece se encuentra el Single Sign - On que es un método de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación. El objetivo principal del presente documento es, servir como guía para el Departamento de Gestión de Servicios de Tecnología y Telecomunicaciones, en la planificación, ejecución y seguimiento de los proyectos gestados en dicha instancia. Para este proyecto en particular, se definió como objetivo general desarrollar un Plan de Proyecto para la Implementación de una solución tipo Single Sign – On en el Instituto Nacional de Seguros para su Plataforma Tecnológica, y como objetivos específicos, desarrollar un análisis de mercado que sirva como marco de
XIX
referencia para la evaluación de soluciones de este tipo, definir los requerimientos del INS para la eventual implementación de una solución tipo Single Sign – On, desarrollar un estudio de factibilidad a partir del análisis de mercado, que justifique la necesidad de implementar la solución en el INS y confeccionar un Cartel con los servicios requeridos para la adquisición de licencias Single Sign – On. El presente Plan de Proyecto considera el uso de 5 áreas de conocimiento: alcance, tiempo, recursos humanos, comunicaciones y adquisiciones. Esta última únicamente para las etapas de planificación de la adquisición y planificación de la contratación. Además, los procesos de iniciación, planificación, ejecución y control. No se consideró la gestión de los costos ya que éste proyecto no implica ninguna erogación adicional para el INS. Gran parte del Proyecto fue desarrollado mediante la investigación y coordinación de reuniones con los proveedores cuyas soluciones Single Sign - On fueron seleccionadas para su investigación. Dichas reuniones sirvieron para generar la documentación necesaria que definiera las bondades de los productos investigados, considerando los costos por la adquisición del producto y licenciamiento de éste. Tal documentación sirvió como marco de referencia para la definición de un estudio costo – beneficio y la generación de un cartel con los requerimientos necesarios para adquirir una solución Single Sign – On. De igual forma, este proyecto se apoyó en la información de las aplicaciones albergadas en las plataformas OS/400, AIX y Windows así como el esquema de autenticación de cada aplicación para definir los requerimientos de la Organización al momento de adquirir e implementar la solución precitada. A partir de la adjudicación del cartel propuesto, se pretende en el menor tiempo posible implementar la solución en el INS y de esta forma reducir significativamente las debilidades derivadas de la utilización de múltiples claves de acceso. Finalmente, este Plan de Proyecto servirá de apoyo al momento de realizar tal implementación para la cual se considerará la inclusión del Plan de Costos, Calidad y Riesgos. Como recomendaciones a realizar, se espera generar un Plan de Calidad y Riesgos que complementen el Proyecto y le permitan llevar la implementación de la solución a un completamiento exitoso.
1
1 INTRODUCCIÓN
1.1 Antecedentes
El Instituto Nacional de Seguros se creó mediante la Ley No.12, del 30 de octubre
de 1924 con el propósito de responder a las necesidades de protección de la
sociedad costarricense.
Inició sus operaciones como Banco de Seguros y, en 1948, cambió el nombre a
INSTITUTO NACIONAL DE SEGUROS.
El 05 de noviembre de 1925 se pone a la venta la primera póliza: el Seguro de
Vida. El 17 de febrero de 1926, se autoriza al Banco a manejar el Seguro de
Incendio y en junio de ese mismo año, asume la administración del Seguro sobre
Accidente de Trabajo, logrando ofrecer los tres primeros productos en materia de
seguros.
Hasta el día de hoy, el INS continúa evolucionando al ritmo del tiempo y de la
nueva tecnología, ofreciendo a todos los habitantes del país una amplia gama de
productos y servicios entre los que se destacan seguros de: Responsabilidad Civil,
Seguros de Vida, Seguros de Riesgos del Trabajo, Seguro Obligatorio Automotor,
Seguros de Automóviles, Seguros de Incendio, Seguro Estudiantil y otros. .
La Institución realiza su labor enmarcada dentro de un arduo e intenso proceso de
modernización en todas las estructuras, con el fuerte propósito de adecuar sus
actividades a los requerimientos del Tercer Milenio.
Con más de 80 años de existencia, el INS tiene muy clara su misión de satisfacer
las necesidades aseguradoras de sus clientes. Además de vender seguros, se
administra el Cuerpo de Bomberos y se brinda servicios de salud, por medio de
INS- Salud, un gran complejo médico, al que se le suman una red de servicios
médicos en todo el país.
2
1.1.1 Dirección de Informática
La Dirección de Informática del Instituto Nacional de Seguros es una instancia,
cuyo primordial objetivo es proveer a la organización, de tecnología de punta, con
el fin soportar las diversas plataformas con que se cuenta, permitiendo de esta
forma, administrar eficientemente cada una de las aplicaciones y datos que
conforman el negocio de los seguros.
La Dirección está conformada por los departamentos de Control y Gestión de TI,
Mantenimiento de Sistemas, Proyectos Nuevos y Operación y Soporte Técnico.
1.1.1.1 Departamento de Operación y Soporte Técnico
El Departamento de Operación y Soporte técnico es una entidad que coadyuva a
la Dirección de Informática en la investigación constante de nuevas tecnologías
que soporten el negocio de la organización de manera eficiente y óptima.
Es en esta área, donde se gestan proyectos de evaluación e implementación de
soluciones tecnológicas, de cara a la optimización de la actual plataforma
tecnológica del INS.
1.2 Problemática que da origen al PFG
Para administrar los distintos productos de su cartera, el INS cuenta con varias
aplicaciones distribuidas en diversas Plataformas entre las que se destacan
OS/400, UNIX y WINDOWS.
Actualmente, aproximadamente un 70% del negocio institucional se encuentra
residente en la Plataforma OS/400.
Entre los sistemas soportados por esta, se encuentran el Sistema de Automóviles,
el Sistema de Vida en todas sus modalidades, el Sistema de Riesgos del Trabajo y
el Sistema de Incendio.
El INS cuenta con 20 SEDES y 17 puntos de venta además de una plataforma de
servicio al intermediario y otros departamentos de producción, desde donde el
usuario final debe manejar al menos 4 claves distintas para acceder a dichas
3
aplicaciones de manera simultánea, según la cantidad y diversidad de pólizas, y
los trámites a efectuar para cada una de ellas de acuerdo a las necesidades y
requerimientos de los clientes.
Dado lo anterior, la Institución se enfrenta a varios problemas entre los que se
destacan:
1. Incurrir en altos costos por concepto de reactivación de claves de usuario.
2. Recurso Humano dedicado en más de un 50% a labores de administración
de claves.
3. Usuarios finales ejerciendo una inadecuada administración de claves desde
el punto de vista de seguridad.
4. Deterioro en el servicio al cliente debido a los tiempos requeridos para
ingresar a cada Sistema.
En promedio, un usuario puede solicitar la reactivación de una o todas sus claves,
al menos 3 veces en una semana.
Tomando en consideración que el personal tanto de los departamentos de
producción como las SEDES y puntos de venta, dedicados a la labor de inclusión
y administración de pólizas puede alcanzar los 400 funcionarios a lo largo del
territorio nacional, podrían requerir reactivarse hasta 1200 claves en una semana
además de la labor de creación de nuevas claves y desactivación de éstas cuando
el funcionario se separa de su puesto.
1.3 Justificación del proyecto
Con el fin de reducir significativamente los actuales problemas que enfrenta la
Institución a raíz de la diversidad de aplicaciones y manejo de claves para cada
una de ellas, se desea implementar una solución del tipo Single Sign – On para las
plataformas OS/400, AIX y WINDOWS permitiendo a través de ello:
• Reducir significativamente los costos en los que actualmente incurre la
organización por concepto de reactivación de claves.
4
• Agilizar considerablemente los tiempos de acceso a varias aplicaciones
según lo requiera el usuario final.
• Aprovechar el recurso humano técnico que actualmente se destina a la
labor de reactivación de claves, en proyectos de mayor envergadura para la
Institución.
• Mejorar la atención al cliente.
• Reducir considerablemente los problemas existentes actualmente, en
relación a la forma de administración de claves por parte del usuario final.
1.4 Objetivos del proyecto
Los objetivos del presente proyecto se definen de la siguiente forma:
1.4.1 Objetivo General
Diseñar un Plan de Proyecto para la implementación de una solución tipo Single
Sign - On en el Instituto Nacional de Seguros para las plataformas OS/400,
WINDOWS Y AIX considerando las áreas de conocimiento de la Administración de
Proyectos.
1.4.2 Objetivos específicos
• Desarrollar un análisis de mercado que sirva como marco de referencia
para la evaluación de soluciones de este tipo, existentes en el mercado
nacional.
• Definir los requerimientos del INS para la eventual implementación de una
solución tipo Single Sign - On.
• Desarrollar un estudio de factibilidad a partir del análisis de mercado, para
justificar la necesidad de implementar la solución en el INS.
• Confeccionar un Cartel con los servicios requeridos para la adquisición de
licencias Single Sign – On para el Instituto Nacional de Seguros.
5
• Desarrollar el Proyecto dentro de una metodología de Administración de
Proyectos que sirva como guía para durante su ejecución.
6
2 MARCO TEÓRICO
2.1 MARCO INSTITUCIONAL
2.1.1 Reseña Histórica del Instituto Nacional de Seguros.
El Banco de Seguros entró en operación el 5 de noviembre de 1925. El 28 de
noviembre de ese año se emitió la primera póliza de vida por la suma de ¢2000 y
desde ese momento su objetivo primordial ha sido brindar protección y servicio al
pueblo costarricense (INS-cr.com, 2007).
A mediados de 1926, el Banco Nacional de Seguros ya era capaz de ofrecer tres
líneas de seguros, convirtiéndose en un instrumento de cambio socioeconómico
para el país.
En 1948 deja de llamarse Banco Nacional de Seguros para convertirse en el
Instituto Nacional de Seguros. Hoy el INS, es una institución que crece y se
proyecta, evoluciona al ritmo del tiempo y de la nueva tecnología, sólida y
confiable, para satisfacer las expectativas de generaciones futuras y del nuevo
consumidor de seguros.
2.1.1.1 Las Direcciones y sus funciones
El INS se divide en las siguientes direcciones:
1. Dirección Administrativa: Encargada de atender el área de Recursos
Humanos y evaluar las políticas necesarias para el suministro de recursos
materiales e institucionales a la administración general.
2. Dirección de Planificación: Vela porque los planes, objetivos, estrategias y
políticas de la empresa se cumplan y guarden coherencia con el Plan
Estratégico Institucional, así como por la asignación y evaluación del uso
eficiente de los recursos.
3. Dirección de Reaseguros: Le corresponde proteger las fluctuaciones, en los
resultados y eventos catastróficos, estabilidad financiera y económica de la
empresa.
7
4. Dirección financiera: Satisface los requerimientos de información financiero
contable, manejo de efectivo e inversiones inmobiliarias, evaluación y
financiamiento de proyectos de inversión e intermediación bursátil.
5. Dirección de Modernización e Informática: Le corresponde coordinar y
supervisar el desarrollo de la tecnología de información en el INS, además
de velar por la suplencia de sistemas y equipos a las dependencias.
6. Dirección de Mercadeo y Ventas: Tiene como obligación, promover el
desarrollo del mercado nacional y regional de seguros, y la confección,
diseño, coordinación y ejecución del Plan de Mercadeo, Ventas y
Publicidad de los productos que el INS comercializa.
7. Dirección de Seguros Generales: Tiene como tarea, dotar a la organización
de los mejores esquemas técnicos en materia de seguros y administración
de riesgos, a las necesidades de los clientes, para cimentar la rentabilidad
de la gestión.
8. Dirección de Seguros Personales: Le corresponde dotar al INS de
productos de calidad para la protección de la vida y protección de las
personas, administrar técnicamente esta línea de seguros y fomentar el
ahorro entre los asegurados.
9. Dirección de Seguros Solidarios: Le corresponde satisfacer las
necesidades de los clientes y trabajadores asegurados en cuanto a este
tipo de seguros, con servicios de atención integral en asistencia médica,
rehabilitación y reinserción familiar, laboral y comunal.
10. Dirección de Servicios Regionales:
a. Sucursales: Administra la red de Sucursales del INS en todo el país,
brindando atención a las necesidades de los clientes y de la Fuerza
de Ventas locales en cada zona.
b. INS – Salud: Brinda atención médica a todas las personas
aseguradas con los Seguros Obligatorio Automotor, Riesgos del
Trabajo y Seguro Estudiantil, en sus instalaciones médicas ubicadas
en todo el país.
8
11. Dirección Jurídica: Se encarga de atender las necesidades de la empresa
en materia jurídica y legal, convirtiéndose además, en una unidad asesora
de las otras direcciones y dependencias.
12. Dirección de Bomberos: Es la coordinadora de todas las acciones y de la
operación general del Benemérito Cuerpo de Bomberos. Su misión es
brindar prevención, protección y mitigación de emergencias a toda la
población (Intranet INS, 2007).
La figura No 1 muestra el organigrama general del Instituto Nacional de
Seguros
Figura No 1 Organigrama del Instituto Nacional de Seguros (Dpto. Planificación del INS, 2007)
Este organigrama, permite tener un panorama general de la jerarquía institucional
actual que se gesta desde la Junta Directiva, ente patrocinador de todos los
GERENCIA
ContraloríaServicios
Subdirec. Seg.Patrimoniales
Subdirec. Seg.Automóviles
DirecciónFinanciera
Dirección SegurosPersonales
Dirección deBomberos
Dirección SegurosSolidarios
Subdirec.-Prest. Sanitar.
SubdirecciónSucursales
PRESIDENCIAEJECUTIVA
JUNTA DIRECTIVA
DirecciónJurídica
Auditoría
DirecciónReaseguros
Dir. Mercadeoy Ventas
Dirección SegurosGenerales
Dirección deInformática
Subdirec.Administrativa
Subdirec.Operaciones
Instituto Nacional de SegurosOrganigrama Estructural Funcional
Noviembre, 2005
Secretaría deActas
Dirección dePlanificación
ComunicacionInstitucional
ConsejoGerencial
Unidad organizativa formal
Linea de autoridad formal
Linea de Asesoría o
Staff
Linea de desconcentración administrativa y regional
Linea de autoridad política
"n" Estaciones de Bomberos Regionales Desconcentradas
C. DE SALUD
Casa de Salud y Albergue y "n" Dispensarios Regionales/Desconcentrados
Unidad Informal
DepartamentoInvestigaciones
Sucursales
Sucursales
DirecciónAdministrativa
Simbología
CENTROS DESALUD
SELEC.RIESGOS
VIDA
ACC.SALUD
ESTACIONES
ASEGURA-MIENTO
RECLAMOS
INCENDIOR/C
AGRIC. YPECUARIO
MAR. YDIVERSOS
RIESGOSTRABAJO
COBRANZAPROV.SOLID
G. EMP. SO
SOA
PREST..SANITAR.
PREST.SALUD
ESTACIONES
INGENIERIA
BOMB.VOLUNTAR
EDUC.PREVENC.
ACTUARIAL
TESORERIA
COBROSCREDITOS
CONTABILIDAD
PROVEEDURIA
RECURSOSMATERIALE
SERVICIOSGENERAL
RECURSOSHUMANOS
INT.COMERCIALIZAC
PROM.VENTAS
TELEINSSEGUROSESTADO
ADMINIST.VENTAS
Nivel Político Directivo
Direcciones
Subdirecciones
Departamentos
Estaciones, Dispensarios,Serv. Salud y Sucursales
Unidad SaludOcupacional
CASA SALUDY ALB TEMP.
DISP.CONSULT.MEDI. EMP.
SUCURSALES
9
proyectos ligados a las estrategias institucionales y a partir de ésta, todas la
Direcciones y Departamentos asociados.
2.1.2 El negocio de los Seguros
Según documento recopilatorio confeccionado por el Departamento de
Comunicación institucional del Instituto Nacional de Seguros (2007), el INS es uno
de los grandes oferentes universales, dada la gran variedad de pólizas de seguros
que tiene a su disposición, tanto para personas físicas como jurídicas.
Actualmente, la Institución ofrece al mercado aproximadamente, 50 productos,
agrupados en tres grandes Líneas:
1. Seguros Generales: Esta línea se enfoca en proteger los bienes
patrimoniales, así como aquellos riesgos que surgen de las actividades de
personas o empresas. De esta línea se desprenden:
a. Seguros Agropecuarios
b. Seguros Diversos y Marítimo
c. Seguros de incendio
d. Seguro Voluntario de Automóviles
2. Seguros Personales: Estos seguros se orientan a las necesidades de
aseguramiento y protección de las personas. De esta línea se desprenden:
a. Seguros de Vida
b. Seguros de Accidentes
c. Seguros para Gastos Médicos
d. Seguros para viajeros
3. Seguros Solidarios: Estos seguros amparan aquellos seguros que son
obligatorios por Ley para todos los habitantes de la República, los mismos se
dividen en dos:
a. Riesgos del Trabajo
10
b. Seguro Obligatorio Automotor
2.1.3 La Dirección de Modernización e Informática
Debido a la presencia del INS en el ámbito nacional se hace indispensable
mantener una excelente comunicación y abastecimiento de información en cada
una de sus dependencias.
Por esta razón, la Dirección de Modernización e Informática ha velado por proveer
a cada una de sus áreas comerciales herramientas óptimas para el procesamiento
y administración de datos, todo esto con el fin de aumentar la eficiencia en sus
tiempos de respuesta hacia los clientes.
La Figura No 2 muestra el organigrama de la estructura funcional de la Dirección
de Modernización e Informática del INS definida en el año 2005.
Figura No 2. Organigrama Estructura Funcional Dirección de Modernización e Informática. (Manual General de Organización y Funciones, 2005)
ORGANIGRAMA ESTRUCTURAL FUNCIONAL DIRECCIÓN DE MODERNIZACIÓN E INFORMATICA
2005 INSTITUTO NACIONAL DE SEGUROS
DIRECCIÓN DE
MODERNIZACIÓN E INFORMÁTICA
AREA DE APOYO ADMINISTRATIVO
SUBDIRECCIÓN DE INFORMÁTICA
DEPARTAMENTO
DE CONTROL Y GESTION DE TI
DEPARTAMENTO
DE NUEVOS PROYECTOS
DEPARTAMENTO
DE
MANTENIMIENTO
DEPARTAMENTO
DE OPERACIÓN Y SOPORTE TECNICO
11
2.2 MARCO CONCEPTUAL
En la actualidad para muchas organizaciones, los sistemas de información
basados en computadoras son el corazón de las actividades cotidianas y objeto de
gran consideración en la toma de decisiones. El gran volumen de transacciones
precisas, asociado con el nivel operativo de una organización y la capacidad de
los administradores para desarrollar procedimientos específicos para manejarlos,
conduce con bastante frecuencia a la implantación de un sistema de información.
El desarrollo de sistemas de información involucra tanto a los analistas
programadores como a todos aquellos que harán uso de las aplicaciones que se
desarrollen, es decir, los usuarios finales. Sin embargo, para que el lector tenga
un mayor conocimiento de los sistemas de información se detalla el siguiente
apartado.
2.2.1 Conceptos básicos sobre Sistemas de Información
Los sistemas de información basados en computadora sirven para diversas
finalidades que van desde el procesamiento de las transacciones de una empresa
hasta proveer la información necesaria para decidir sobre los asuntos que se
presentan con frecuencia, asistencia a los altos funcionarios con la formulación de
estrategias difíciles y la vinculación entre la información de las oficinas y los datos
de toda la corporación.
2.2.1.1 Datos
Senn (1992) define el elemento dato como los bloques básicos para todos los
demás datos del sistema e indica que los datos por sí mismos no conllevan
suficiente significado para ningún usuario.
Generalmente, los términos “información” y “datos” se utilizan
indiscriminadamente, sin embargo, Davis y Olson (1987) definen la información
como “aquellos datos que tienen significado o utilidad para el receptor”. Por lo
tanto, los datos elementales son la materia prima para producir la información.
12
2.2.1.2 Sistema
En informática, el concepto Sistema se utiliza en varios contextos. Una
computadora es el Sistema formado tanto por Hardware como por Software y su
Sistema Operativo. Sistema se refiere también a cualquier colección de
programas, procedimientos y datos utilizados en el procesamiento de información,
que dan como resultado Sistemas de Contabilidad, Facturación, Gestión de Base
de Datos y otros.
El concepto de sistema en general está sustentado sobre el hecho de que ningún
sistema puede existir aislado completamente y siempre tendrá factores externos
que lo rodean y pueden afectar.
Según Senn (1992) un Sistema es “un conjunto de componentes que interacciona
entre sí para lograr un objetivo común”.
Existen varios tipos de Sistemas, entre ellos:
1.) Sistemas organizacionales: Su finalidad es producir un producto que
satisfaga las demandas del mercado.
2.) Sistemas de Información: Su finalidad es a través de diversas entradas como
datos relacionados con la organización obtener salidas como reportes y
otros.
2.2.1.3 Sistemas de Información
Un Sistema de Información es un conjunto de recursos que permiten recoger,
gestionar, controlar y difundir la información de una Organización.
Un Sistema de Información está formado por los siguientes componentes:
1.) Hardware. Los requerimientos de información de los usuarios guían la
selección del hardware computacional, el medio de almacenamiento de datos
y cualquier software en paquete. La página de la Universidad Autónoma de
Ciudad Juárez (2007), define el Hardware como “todos aquellos componentes
13
físicos de una computadora, todo lo visible y tangible”. El Hardware realiza
las actividades fundamentales: entrada, procesamiento, salida y
almacenamiento secundario.
2.) Software. La página de Canalhanoi (2007), indica que el software es el
conjunto de instrucciones que las computadoras emplean para manipular
datos. Al cargar los programas en una computadora, la máquina actuará
como si recibiera a una educación instantánea; de pronto "sabe" cómo
pensar y cómo operar. La misma página define Software como un conjunto
de programas, documentos, procedimientos, y rutinas asociados con la
operación de un sistema de cómputo, distinguiéndose de los componentes
físicos llamados hardware. El software asegura que el programa o sistema
cumpla por completo con sus objetivos, opere con eficiencia, esté
adecuadamente documentado, y suficientemente sencillo de operar.
3.) El Sistema Gestor de Base de Datos (SGBD). Es un software que maneja la
organización, localización, catalogación, almacenamiento, recuperación y
mantenimiento de datos en una base de datos.
4.) Recurso Humano: El recurso humano asignado a un determinado proyecto
debe ser seleccionado por su competencia y compatibilidad, La
administración de tiempo y recursos es gestionada por el Director de
proyectos asignado. Los Analistas programadores se encargan de realizar el
análisis y desarrollo de los requerimientos definidos por el usuario y los
Usuarios finales son aquellos que definen los requerimientos y utilizan el
Sistema.
5.) Información: Conjunto de datos los cuales pueden recuperarse de acuerdo
con la necesidad del usuario.
2.2.1.4 Ciclo de Vida de un Sistema de Información
Senn (1992), define el desarrollo de sistemas como un proceso formado por
etapas de análisis y diseño que inicia cuando la administración o algunos
miembros del personal encargado de desarrollar sistemas, detectan un sistema de
14
la empresa que necesita mejoras. Esto es lo que se denomina el método del ciclo
de vida para desarrollo de sistemas (SDLC).
Al ciclo de vida de los Sistemas de Información también se le denomina Ciclo de
Vida Clásico del Desarrollo de Sistemas. El mismo autor establece las siguientes
fases: (Senn, 1992).
1.) Investigación preliminar: El desarrollo de sistemas es un proceso formado por
las etapas de análisis y diseño, comienza cuando la administración o alguno
de los miembros del personal encargado de desarrollar sistemas, detectan un
sistema de la empresa que necesitan mejoras. El analista en conjunto con
este personal identifican los problemas principales que presenta la
organización. De igual forma, el analista, identificará las oportunidades que
la organización obtendrá mediante el Sistema de Información. Esta fase
contempla a su vez, tres partes:
• Aclaración de la solicitud: Se examina la solicitud para determinar
con precisión lo que el solicitante desea. .
• Estudio de factibilidad: La cual se relaciona con factibilidad técnica
(¿Puede desarrollarse con el equipo o tecnología actual?, ¿Se
necesita nueva tecnología?, si es así: ¿Cuál es la posibilidad de
desarrollarla?), económica (¿Se obtendrán suficientes beneficios
para aceptar los costos?) y operacional (si se implanta el proyecto
¿Será utilizado el sistema?, ¿Existirá resistencia al cambio por parte
de los usuarios que provoque la disminución de los posibles
beneficios de la aplicación?).
• Aprobación de la solicitud: No todos los proyectos solicitados son
deseables o factibles. En algunos casos el desarrollo puede
comenzar inmediatamente, aunque lo común es que los miembros
del equipo de sistemas se encuentren ocupados con otros proyectos.
15
2.) Determinación de los requerimientos del sistema: En esta fase, es
imprescindible comprender todas las facetas importantes de la parte de la
empresa que se encuentra en estudio.
3.) Diseño del sistema: En esta fase, los Analistas usan la información
recolectada previamente para realizar el diseño lógico del Sistema de
Información. El diseño lógico permite diseñar la interfaz del usuario, la cual
corresponde a un programa que permite conectar al usuario con el Sistema.
4.) Desarrollo de software: En esta fase, el analista trabaja con los
programadores para determinar el lenguaje en el que será desarrollado dicho
sistema, se produce el desarrollo de la aplicación, o bien, si el software es
comprado a terceros se modifica e instala o podría darse el caso de adquirir
una aplicación a la medida, la elección depende del costo de cada alternativa,
del tiempo y disponibilidad del desarrollador.
5.) Prueba de sistemas: Antes de ser usado, el sistema de información debe ser
probado o utilizado en forma experimental con el fin de determinar si existe
algún problema de ejecución. En muchas organizaciones las pruebas son
conducidas por personas ajenas a los analistas programadores originales;
con la finalidad de asegurar que las pruebas sean completas e imparciales y
que el software sea más confiable.
6.) Implantación y evaluación: La implantación es el proceso de verificar e
instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y
construir todos lo archivos de datos necesarios para utilizarla. Una vez
instaladas, las aplicaciones se emplean durante muchos años; sin embargo,
las organizaciones y los usuarios cambian a través del tiempo. Por
consiguiente, al ser un proceso en constante evolución, se realizará una
evaluación periódica para identificar puntos débiles y fuertes.
16
Prueba del sistema Determinación de
requerimientos
Desarrollo del sistema
Diseño del sistema
Investigación preliminar
Implantación
La Figura No 3, muestra las actividades del ciclo de vida clásico de desarrollo de
sistemas definido por James Senn en su libro Análisis y Diseño de Sistemas de
Información (1992):
Figura No 3 Actividades del ciclo de vida clásico de desarrollo de sistemas (Senn, 1992)
2.2.1.5 Interfaces
Según un artículo de la Enciclopedia Encarta 2006, una Interfaz es el punto en
el que se establece una conexión entre dos elementos, que les permite trabajar
juntos. En el campo de la informática se distinguen diversos tipos de interfaces
que actúan a diversos niveles, desde las interfaces claramente visibles, que
permiten a las personas comunicarse con los programas, hasta las
imprescindibles interfaces hardware, a menudo invisibles, que conectan entre sí
los dispositivos y componentes dentro de los ordenadores o computadoras.
Las interfaces de usuario cuentan con el diseño gráfico, los comandos, mensajes
y otros elementos que permiten a un usuario comunicarse con un programa.
17
2.2.1.6 Interface de Usuario
Según el diccionario de la Real Academia, una interfase es una conexión física y
funcional entre dos aparatos o sistemas independientes. La página Galileo (2007)
menciona seis principios de interfaces de usuario:
1.) Familiaridad para usuarios: La interfaz debe usar los términos y conceptos
que son obtenidos de la experiencia de las personas que van a utilizar con
mayor frecuencia el sistema.
2.) Consistencia: La interfaz debe ser consistente, esto quiere decir que, las
operaciones comparables deben ser activadas en la misma manera.
3.) Sorpresa mínima: Los usuarios nunca deben ser sorprendidos por el sistema.
4.) Recuperabilidad: La interfaz debe incluir mecanismos para permitir a que los
usuarios puedan recuperar de los errores.
5.) Orientación de los usuarios: La interfaz debe proveer retroalimentación
significativa cuando los errores ocurren y proveer las facilidades de ayuda
sensibles al contexto.
6.) Diversidad de usuarios: La interfaz debe proveer facilidades apropiadas de
interacción para diferentes tipos de usuario del sistema.
En síntesis, una interfaz de usuario debe permitir a los diferentes usuarios
interactuar con el Sistema de manera sencilla, para esto, la interfaz debe utilizar
títulos significativos que identifiquen el propósito de la salida, debe tener
instrucciones que sean fáciles de seguir, los campos deben estar agrupados de
forma lógica, los nombres de los campos deben ser significativos y deben existir
mensajes ya sea de precaución, error o finalización satisfactoria de la transacción
que se está realizando.
2.2.1.7 Usuarios Expertos o Usuarios Finales
Los usuarios expertos o usuarios finales no son especialistas en sistemas de
información pero utilizan las computadoras para desempeñar su trabajo. Tal y
como menciona Senn (1992), existen cuatro tipos de usuarios:
18
1.) Usuarios primarios: interactúan con el sistema, alimentan el sistema con
datos o reciben salidas, quizá por medio de una terminal. Ej.: Agentes de
reservación de vuelos.
2.) Usuarios indirectos: se benefician de los resultados o reportes generados por
estos sistemas pero que no interactúan de manera directa con el hardware o
software. Ejemplo: Gerentes de Mercadotecnia.
3.) Usuarios gerentes: poseen responsabilidades administrativas en los sistemas
de aplicación. Utilizan en gran medida los sistemas de información y
supervisan la inversión en el desarrollo o uso del sistema.
4.) Usuarios directivos: toman cada vez mayor responsabilidad en el desarrollo
de las aplicaciones, incorporan los usos estratégicos y competitivos de los
sistemas de información en los planes y estrategias de la organización.
Evalúan los riesgos a los cuales se expone la organización originados por
fallas en los sistemas.
Los usuarios finales deben estar familiarizados con el software que emplean,
generalmente se espera de ellos que utilicen el equipo de cómputo.
Otra definición de Usuario Final es la que expresa González (2000), quién indica
que el usuario Final es la persona más importante de quienes tienen relación con
una base de datos. Así, es él quien determina el éxito de la base de datos, según
la utilización que haga de la misma y si realmente se adapta a sus necesidades.
2.2.2 Plataformas
En informática, una plataforma es el principio, ya sea de hardware o software,
sobre el cual un programa puede ejecutarse.
2.2.2.1 Plataforma de Software
Según la página Morfeo (2007), el concepto de Plataforma de Software ha ido
evolucionando a lo largo de la historia, proporcionando en cada momento una
abstracción cada vez mayor de las capacidades sobre las que cualquier aplicación
19
software se apoya, ya sea en el ámbito de los Sistemas de Información o en el
ámbito de los Servicios de Telecomunicaciones. Estas capacidades son:
• Capacidad de procesamiento: la plataforma proporcionará un modelo que
establezca que entidades componen una aplicación y como se gestiona su
ciclo de vida (creación, arranque/activación, ejecución,
parada/desactivación y destrucción).
• Capacidad de almacenamiento: la plataforma proporcionará un modelo que
establezca como guardar, recuperar y administrar datos que representen el
estado de las entidades de aplicación o que dichas entidades deban
manejar.
• Capacidad de conectividad: la plataforma proporcionará un modelo que
establezca tanto la forma de localizar entidades de aplicación en un entorno
distribuido, como la forma en que dichas entidades pueden comunicarse y
cooperar con el objetivo de implementar la funcionalidad de la aplicación.
• Capacidad de interacción con el usuario final: la plataforma proporcionará
un modelo que establezca canales de acceso a la funcionalidad de la
aplicación por parte del usuario a través de distintos tipos de terminales.
Aunado a lo anterior, el concepto de Plataforma Software también engloba
aquellos componentes de aplicación que puedan reutilizarse de una aplicación a
otra.
Morfeo (2007) indica, que el concepto de Plataforma de Software se encuentra en
constante evolución. Nuevos componentes se incorporan a la plataforma
ofreciendo un mayor nivel de abstracción respecto a las capacidades antes
mencionadas, apoyándose en funcionalidad de componentes ya existentes.
La plataforma software básica incluye componentes que van desde el Sistema
Operativo situado al nivel más básico, hasta componentes situados en el nivel de
aplicación (un módulo de gestión de usuarios, por ejemplo) pasando por niveles
intermedios donde se inscribirían componentes relacionados con middleware,
bases de datos, etc.
20
El objetivo último de cualquier plataforma es facilitar la construcción de
aplicaciones, minimizando plazos y costes de desarrollo, así como proporcionar un
entorno de ejecución robusto y eficiente.
La Figura No 4, muestra tecnologías y componentes que, en la actualidad, se
consideran englobados dentro del concepto de Plataforma Software Básica.
Figura No 4 Plataforma de Software básica (Morfeo, 2007)
2.2.2.2 iSeries
Según la página Ecom.chaco referente a la historia de los equipos iSeries, más
comúnmente denominados AS/400, estos son equipos que siguen la línea del
S/32,S/34, S/36.
En un cambio de filosofía, IBM saca al mercado el S/38, el padre del AS/400,
(sistema que no estuvo mucho tiempo en el mercado, al menos en el local).
Básicamente, el cambio de filosofía de funcionamiento es que el sistema operativo
esta ligado a la base de datos, donde cada Objeto de los diferentes que existen en
el AS/400 tienen sus propiedades (atributos). Es un Sistema muy dúctil y que
insumen un mínimo de mantenimiento, permitiendo con las mismas herramientas
21
(Comandos, Programas y demás) crear procesamientos para salvar un sin fin de
requerimientos que otros (también llamados sistemas operativos) no lo permiten.
Soporta la posibilidad de que las aplicaciones anteriores sigan funcionando a
pesar de que sean cambiados tanto software de base o hardware
2.2.2.2.1 Plataforma OS/400
Según la página de Internet de la empresa System Support (2007), la Plataforma
AS/400, conocida actualmente como iSeries es la plataforma más robusta en el
mundo a nivel de computadores de rango medio; actualmente iSeries utiliza
tecnología y confiabilidad que solo estaba disponible en los Mainframes, debido a
esto, su utilización se ha vuelto tan importante y creciente en las pequeñas
empresas, medianas y grandes en los diversos sectores que requieren
La figura No 5 muestra un equipo iSeries cuyo último modelo es el IBM System iTM
595
Figura No 5 Modelo iSeries IBM System iTM 595. (System Support,2007)
22
2.2.2.3 Pseries o RS/6000
La página Babilón (2007), define a IBM pSeries, anteriormente denominado
RS/6000, como una línea de ordenadores del tipo estaciones de trabajo
RISC/UNIX de IBM. Anunciado en 1990, la RS/6000 remplazó a la antigua RT-PC
y opera con el Sistema Operativo AIX.
2.2.2.3.1 Plataforma pSeries
La página Redsis (2007), especifica que la plataforma tecnológica pSeries -
RS/6000 proporciona, a los usuarios UNIX, en todos los modelos de la familia la
mejor alternativa de rapidez, flexibilidad, compatibilidad y funcionalidad de
procesos con la mas avanzada tecnología disponible.
La familia de productos pSeries está actualmente conformada por varios modelos
diferentes basados en tecnología RISC POWERPC 604e de 32 bits y POWER 3-II
y POWER 4 de 64 bits.
El Sistema Operativo AIX para pSeries esta diseñado para optimizar el
rendimiento con el hardware de un pSeries y proveer al usuario un ambiente que
soporte los estándares de los sistemas abiertos. AIX ha sido calificado a nivel
internacional como el mejor UNIX de la industria, tanto por el cumplimiento de
todos los estándares de sistemas abiertos de la industria y compatibilidad, como
por su solidez y madurez.
La figura No 6 muestra un Servidor pSeries de última tecnología, ofrecido por su
proveedor oficial IBM
23
Figura No 6 Servidor pSereis IBM (Redsis,2007)
2.2.3 Seguridad de los Sistemas de Información
Según la página Tramullas (2007), la Seguridad informática consiste
generalmente en asegurar que los recursos del Sistema de Información de una
organización sean utilizados de la manera que se decidió y que la información que
se considera importante no sea fácil de acceder por cualquier persona que no se
encuentra acreditada.
2.2.3.1 Términos relacionados con la seguridad informática
La página Tramullas (2007) define los siguientes términos relacionados con la
seguridad informática:
• Activo: recurso del sistema de información o relacionado con éste,
necesario para que la organización funcione correctamente y alcance
los objetivos propuestos.
• Amenaza: es un evento que pueden desencadenar un incidente en la
organización, produciendo daños materiales o pérdidas inmateriales en
sus activos.
24
• Impacto: consecuencia de la materialización de una amenaza.
• Riesgo: posibilidad de que se produzca un impacto determinado en un
Activo, en un Dominio o en toda la Organización.
• Vulnerabilidad: posibilidad de ocurrencia de la materialización de una
amenaza sobre un Activo.
• Ataque: evento, exitoso o no, que atenta sobre el buen funcionamiento
del sistema.
• Desastre o Contingencia: interrupción de la capacidad de acceso a
información y procesamiento de la misma a través de computadoras
necesarias para la operación normal de un negocio.
Aunque a simple vista se puede entender que un Riesgo y una Vulnerabilidad se
podrían englobar un mismo concepto, una definición más informal denota la
diferencia entre riesgo y vulnerabilidad, de modo que se debe la Vulnerabilidad
está ligada a una Amenaza y el Riesgo a un Impacto.
2.2.3.2 Políticas de Seguridad
Generalmente, se ocupa exclusivamente asegurar los derechos de acceso a los
datos y recursos con las herramientas de control y mecanismos de identificación.
Estos mecanismos permiten saber que los operadores, técnicos o usuarios finales
de los sistemas tienen sólo los permisos que se les dio y que estrictamente
requieren.
Los derechos de acceso deben ser definidos por los responsables jerárquicos y no
por los administradores informáticos, los cuales tienen que conseguir que los
recursos y derechos de acceso sean coherentes con la política de seguridad
definida. Además, como el administrador suele ser el único en conocer
perfectamente el sistema, tiene que derivar a la directiva cualquier problema e
información relevante sobre la seguridad, y eventualmente aconsejar estrategias a
poner en marcha, así como ser el punto de entrada de la comunicación a los
trabajadores sobre problemas y recomendaciones en término de seguridad.
25
2.2.3.3 Claves de Acceso
Según lo expuesto en la página Cybsec (1996), las claves de acceso son la
barrera más común en contra de accesos no autorizados a un sistema y
prácticamente hoy en día son la única barrera, por esta razón debe darse un
tratamiento de seguridad especial según las necesidades del negocio y la
aplicación a la cual están asociadas.
2.2.4 Métodos de autenticación de usuarios
2.2.4.1 Soluciones tipo Single Sign – On
2.2.4.1.1 Que es el Single Sign On
Según un estudio realizado por los especialistas Iván Caballero y Jeimy Cano,
publicado en la página criptored.upm (2006), el concepto Single Sign-On se refiere
al acceso a múltiples recursos por medio de un único acceso. Gran cantidad de las
arquitecturas implementadas en diferentes organizaciones han sido diseñadas con
el objeto de dar acceso a los usuarios a múltiples servicios Web y/o aplicaciones.
En la mayoría de los casos, cada uno de los servicios o aplicaciones cuenta con
su propio componente de seguridad, lo cual generalmente compromete la
seguridad de todo el sistema. Una de las posibles soluciones a este problema es
implementar la estrategia Single Sign-On. Esta estrategia contempla cuatro
arquitecturas que permiten implementar el SSO; Password Vault, la Administración
centralizada con almacenamiento local de credenciales, la Administración y
almacenamiento de credenciales centralizados y la Arquitectura SSO totalmente
distribuida.
El principal objetivo de una arquitectura que implemente Single Sign-On es
transferir la funcionalidad y complejidad de todos los componentes de seguridad a
un solo servicio de Single Sign-On (SSO). En una arquitectura SSO, todos los
mecanismos de seguridad se encuentran concentrados en el SSO, siendo éste el
único punto de autenticación y registro en el sistema. Otro beneficio de una
arquitectura con estas características, es que los usuarios deben hacer el proceso
26
de ingreso una sola vez, a pesar de que continúan interactuando con múltiples
componentes de seguridad en el sistema.
El concepto de Single Sign-On no necesariamente se refiere a una sincronización
de claves de acceso, ya que en ese caso todas las aplicaciones y servicios
funcionan con un mismo acceso. Aunque una sincronización de claves de acceso
le permite al usuario experimentar las ventajas del SSO, ésta no puede
considerarse una implementación real, ya que en lugar de fortalecer las
características de seguridad del sistema, éstas se estarían debilitando, pues todas
las aplicaciones o servicios utilizan un único acceso, corriéndose el riesgo de que
si un intruso logra conseguir el password de una de las aplicaciones o servicios,
inmediatamente tendrá acceso a todas ellas.
Una implementación real de SSO, debería contar con un agente SSO que se
encargue de almacenar en una base de datos o directorio protegido, los accesos
que le permiten al usuario acceder a cada una de las aplicaciones o servicios, en
el momento que lo desee, ya que el proceso de login se realiza de manera
transparente para el usuario, una vez que éste ha sido autenticado por medio de la
arquitectura SSO.
A pesar de que en una verdadera implementación existe una clave de acceso que
permite el ingreso a todas las aplicaciones o servicios, esta aparente debilidad se
soluciona sometiendo al usuario a un proceso de autenticación fuerte en el
momento de hacer el ingreso, logrando que la arquitectura SSO aumente el nivel
de seguridad del sistema completo, en lugar de disminuirlo.
Autenticación fuerte se refiere al proceso de autenticación en sistemas que
requieren múltiples factores para realizar la identificación del usuario, los cuales
utilizan tecnología avanzada como contraseñas dinámicas o certificados digitales.
27
2.2.4.1.2 Arquitecturas
Existen diferentes tipos de arquitecturas que permiten implementar SSO. Cada
una de ellas posee características que la hace más apropiada para algún tipo de
organización. La decisión de adoptar una u otra arquitectura básicamente depende
de los recursos computacionales y/o económicos disponibles, y las decisiones de
diseño establecidas por el equipo del proyecto.
Las diferentes arquitecturas SSO están compuestas por tres componentes
básicos:
1. Interface: El modo en que el SSO interactúa con una determinada
aplicación. Usualmente reside en el cliente, y es conocido como Agente
SSO.
2. Administración: El mecanismo que permite configurar, mantener y
monitorear el proceso de SSO.
3. Credenciales: Cada aplicación a la que se accede requiere información
confidencial (nombre de usuario, contraseña, etc.), que agrupada recibe
el nombre de credenciales. Las credenciales deben almacenarse de
manera protegida para que sea únicamente el agente SSO quien pueda
acceder a ellas.
2.2.4.1.2.1 Password vault
Se trata de la configuración más básica para implementar SSO utilizando
credenciales. En este caso los tres elementos de la arquitectura se encuentran
ubicados en el cliente y, por lo tanto, es justamente allí desde donde se accede a
las aplicaciones, para lo cual se deben previamente almacenar las credenciales
correspondientes, para que puedan ser suministradas a las aplicaciones cuando
sea necesario, esto se ilustra en la figura No 7.
28
Figura No 7. Arquitectura Password Vault
2.2.4.1.2.2 Administración centralizada con almacenamiento local de credenciales
Con el propósito de solucionar los principales inconvenientes que presenta la
arquitectura Password Vault, surge la Administración centralizada con
almacenamiento local de credenciales, ofreciendo un mecanismo para controlar y
supervisar el proceso de ingreso, y eliminando la necesidad de configurar el SSO
en cada uno de los clientes. Esta arquitectura se ilustra en la figura No 8.
Figura No 8. Administración centralizada con almacenamiento local de credenciales
29
2.2.4.1.2.3 Administración y almacenamiento de credenciales centralizados
La arquitectura SSO con administración y almacenamiento centralizado de
credenciales pretende solucionar los principales inconvenientes encontrados en la
arquitectura que almacena las credenciales localmente, según se muestra en la
figura No 9.
Figura No 9. Administración y almacenamiento de credenciales centralizados
2.2.4.1.2.4 Arquitectura SSO totalmente distribuida
La arquitectura SSO totalmente distribuida se caracteriza principalmente por
separar el servidor de la base de datos, lo cual la hace completamente modular.
Esta arquitectura soluciona los problemas encontrados en las arquitecturas
anteriormente presentadas y adicionalmente ofrece múltiples ventajas, según se
muestra en la figura No 10.
30
Figura No 10. Arquitectura SSO totalmente distribuida
Adicionalmente a las cuatro arquitecturas previamente establecidas, se da una
quinta arquitectura cuya mejora sobre las anteriores está definida por el esquema
de alta disponibilidad y redundancia.
2.2.4.1.2.5 Administración y almacenamiento de credenciales centralizados
garantizando alta disponibilidad y redundancia
La arquitectura SSO con administración y almacenamiento centralizado de
credenciales garantizando alta disponibilidad y redundancia es una adaptación de
la arquitectura presentada de Administración y almacenamiento de credenciales
centralizados, incorporando algunas de las ventajas de la arquitectura totalmente
distribuida, la misma se muestra en la figura No 11.
31
Figura No 11. Administración y almacenamiento de credenciales centralizados con esquema de alta disponibilidad y redundancia
El tipo de arquitectura SSO a implementar en una determinada organización
deberá determinarse con base en varios factores como son: su capacidad de
personalización y flexibilidad, la complejidad deseada en la infraestructura, los
recursos de tecnología informática disponibles y los recursos económicos
disponibles, entre otros.
Un sistema SSO correctamente diseñado debe poseer características que le
permitan realizar un mismo procedimiento de autenticación bajo todos los
ambientes. Esto significa que la organización no debería mantener infraestructuras
paralelas para el procedimiento de ingreso y administración de sus usuarios
locales y remotos bajo diferentes ambientes. Si esto ocurre, se deben definir con
claridad las condiciones de operación en contingencia del SSO que definan las
características requeridas para la autenticación y control de acceso a las
aplicaciones corporativas.
Ante el hecho de que en una arquitectura SSO, todos los recursos asociados al
perfil de una determinada identidad son accesibles mediante un solo proceso de
32
autenticación, es muy importante adoptar mecanismos de autenticación fuerte,
tales como nombre de usuario y contraseña, tarjeta inteligente, sensor biométrico
de huella digital, entre otras (preferiblemente varias de ellas).
Si bien, algunas organizaciones en el mundo, han desarrollado y adquirido
importantes mecanismos de seguridad informática que muestran un alto nivel de
cumplimiento con los fundamentos de seguridad informática como lo son: las
tarjetas token card (contraseñas dinámicas), los perfiles de control de acceso, o
una infraestructura de llaves pública y privadas – PKI, entre otros, la
implementación de una estrategia de Single Sign-On muestra nuevamente el
compromiso de las empresas con la protección y fortalecimiento de la arquitectura
de cómputo y el acceso a sus aplicaciones corporativas.
En este sentido la implementación de la estrategia de Single Sign-On sugiere
algunos beneficios adicionales para las organizaciones como son:
1. Reducción de costos de administración de la seguridad
2. Disminución de la operatividad asociada con la administración de
contraseñas.
3. Incremento en los niveles de seguridad existentes.
4. Control centralizado de autenticación para las aplicaciones corporativas.
5. Mayor comodidad y facilidad de uso de las aplicaciones corporativas para
los usuarios finales.
33
2.3 Teoría de la Administración de Proyectos
2.3.1 Marco Conceptual de la Administración de Proyectos
La administración de Proyectos pretende, mediante la organización de un conjunto
de recursos humanos con habilidades específicas, desarrollar a través de la
conjunción de procesos y áreas de conocimiento un proyecto que cumpla con las
necesidades y requerimientos del cliente en un plazo previamente establecido.
Los Fundamentos de la Dirección de Proyectos constituyen la suma de
conocimientos en la profesión de dirección de proyectos. Al igual que en otras
profesiones, como la abogacía, medicina o ciencias económicas, los
conocimientos residen en los practicantes y académicos que los aplican y los
desarrollan. Los Fundamentos de la Dirección de Proyectos completos incluyen
prácticas tradicionales comprobadas y ampliamente utilizadas, así como prácticas
innovadoras que están emergiendo en la profesión, incluyendo material publicado
y no publicado. Como consecuencia, los Fundamentos de la Dirección de
Proyectos están en constante evolución (PMI, 2004).
2.3.2 Qué es un Proyecto
Chamoun (2002) define el proyecto como un conjunto de esfuerzos temporales,
dirigidos a generar un producto o servicio único.
En este sentido, hemos de entender como temporal a un esfuerzo que tiene un
inicio y un fin definido. Este esfuerzo será único por cuanto cada proyecto cuenta
con características y funciones específicas que serán gradualmente desarrolladas
y le confieren la cualidad de único porque el producto derivado de un proyecto
nunca será igual a otro, aunque dicho producto sea del mismo tipo
Gido y Clements (2003) definen el proyecto como un esfuerzo por lograr un
objetivo específico mediante una serie especial de actividades interrelacionadas y
la utilización eficiente de los recursos.
34
Finalmente, la metodología PMI (2004) define proyecto como un esfuerzo temporal
que se lleva a cabo para crear un producto, servicio o resultado único
Si se comparan las tres definiciones podemos concluir que el proyecto es un
esfuerzo realizado a través de la asignación eficiente de los recursos y una
utilización adecuada del tiempo para obtener un bien o servicio único que cumpla
con el objetivo por el cual fue requerido.
2.3.3 Qué es la Dirección de Proyectos
Según el PMI (2004), la Dirección de Proyectos se define como la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades de un
proyecto para satisfacer los requisitos del mismo. La dirección de proyectos se
logra mediante la aplicación e integración de los procesos de dirección de
proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El
director del proyecto es la persona responsable de alcanzar los objetivos del
proyecto.
La dirección de un proyecto incluye:
• Identificar los requisitos
• Establecer unos objetivos claros y posibles de realizar
• Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costes.
• Adaptar las especificaciones, los planes y el enfoque a las diversas
inquietudes y expectativas de los diferentes interesados.
El PMI (2004) especifica que el término “dirección de proyectos” se utiliza en
ocasiones para describir un enfoque de la organización o de dirección respecto a
la gestión de los proyectos y de algunas operaciones continuas, que pueden ser
redefinidas como proyectos, denominados también “dirección por proyectos”.
35
2.3.4 La Administración de Proyectos
La administración de proyectos se aplica a todo aquello que es único, transitorio,
momentáneo, exclusivo, emprendido para realizar operaciones existentes, a través
de procesos y grupos de procesos.
Según Gido y Clements (2003), la administración de proyectos significa planear el
trabajo y después trabajar según el Plan. La Administración de proyectos incluye
primero establecer un Plan y después llevarlo a cabo, para lograr el objetivo de
proyecto.
Dichos autores consideran que el esfuerzo principal en la Administración de un
proyecto tiene que estar centrado en establecer un plan de línea base, que
proporcione un plan de ruta para indicar cómo se logrará el alcance del proyecto a
tiempo y dentro del presupuesto. Este esfuerzo de planeación incluye:
1. Definir con claridad el objetivo del proyecto.
2. Dividir y subdividir el alcance del proyecto en paquetes de trabajo.
3. Definir las actividades específicas que deben llevarse a cabo para cada
paquete de trabajo con el fin de lograr el objetivo del proyecto.
4. Presentar gráficamente las actividades a desarrollar a través de un
diagrama de red
5. Hacer un estimado del tiempo de la duración para el completamiento de
cada actividad.
6. Hacer un estimado de los costos en que se incurrirá para completar cada
actividad.
7. Calcular el programa y presupuesto del proyecto, para determinar si el
mismo puede concluirse dentro del tiempo estimado y los recursos
disponibles, y previamente establecidos para éste.
2.3.5 Ciclo de vida de los Proyectos
Según el PMI (2004), para facilitar la gestión, los directores de proyectos o la
organización pueden dividir los proyectos en fases, con los enlaces
36
correspondientes a las operaciones de la organización ejecutante. El conjunto de
estas fases se conoce como ciclo de vida del proyecto las cuales se detallan de la
siguiente forma:
2.3.5.1 Características del Ciclo de Vida de un Proyecto
El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto
con su fin. La definición del ciclo de vida del proyecto puede ayudar al director del
proyecto a determinar si deberá tratar el estudio de viabilidad como la primera fase
del proyecto o como un proyecto separado e independiente. Cuando el resultado
de dicho esfuerzo preliminar no es claramente identificable, lo más recomendable
es tratar dichos esfuerzos como un proyecto por separado.
Los ciclos de vida del proyecto generalmente definen:
• Qué trabajo técnico se debe realizar en cada fase.
• Cuándo se deben generar los productos entregables en cada fase y cómo
se revisa, verifica y valida cada producto entregable.
• Quién está involucrado en cada fase.
• Cómo controlar y aprobar cada fase.
Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy
detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir
formularios, diagramas y listas de control para proporcionar estructura y control.
37
La Figura No 12, muestra las fases del ciclo de vida de un proyecto:
Figura No 12 Fases del ciclo de vida de un proyecto, PMI, 2004
2.3.6 Interesados en el Proyecto
Según el PMI (2004), los interesados en el proyecto son personas y
organizaciones que participan de forma activa en el proyecto o cuyos intereses
pueden verse afectados como resultado de la ejecución del proyecto o de su
conclusión. De igual forma pueden influir sobre los objetivos y resultados del
proyecto.
2.3.7 Procesos de Dirección de proyectos para un proyecto
Según el PMI (2004), la dirección de proyectos es la aplicación de conocimientos,
habilidades, herramientas y técnicas a las actividades del proyecto para satisfacer
Idea Equipo de dirección de proyectos Entradas
Producto
Entrega
Acta Enunciado del Alcance
Plan Línea Base Avance
Aceptación Aprobación
INICIAL
INTERMEDIA FINAL Fase
Salidas de la Dirección de Proyectos
Producto entregable d el proyecto
38
los requisitos del mismo. La dirección de proyectos se logra mediante la ejecución
de procesos, usando conocimientos, habilidades, herramientas y técnicas de
dirección de proyectos que reciben entradas y generan salidas.
Para que un proyecto sea exitoso, el equipo del proyecto debe:
1) Seleccionar los procesos apropiados dentro de los Grupos de Procesos de
la Dirección de Proyectos (también conocidos como Grupos de Procesos)
que sean necesarios para cumplir con los objetivos del proyecto
2) Usar un enfoque definido para adaptar las especificaciones del producto y
los planes de tal forma que se puedan cumplir los requisitos del proyecto y
del producto
3) Cumplir con los requisitos para satisfacer las necesidades, deseos y
expectativas de los interesados
4) Equilibrar las demandas concurrentes de alcance, tiempo, costes, calidad,
recursos y riesgos para producir un producto de calidad.
Esta norma documenta la información necesaria para iniciar, planificar, ejecutar,
supervisar y controlar, y cerrar un proyecto individual, e identifica los procesos de
la dirección de proyectos que han sido reconocidos como buenas prácticas para la
mayoría de los proyectos, la mayor parte del tiempo. Estos procesos se aplican
globalmente y en todos los grupos industriales. Buenas prácticas significa que
existe un acuerdo general en que se ha comprobado que la aplicación de esos
procesos de dirección de proyectos aumenta las posibilidades de éxito en una
amplia variedad de proyectos.
La Dirección de Proyectos es una tarea integradora. La integración de la dirección
de proyectos exige que cada proyecto y proceso de productos esté correctamente
alineado y conectado con los otros procesos, esto con el fin de facilitar su
coordinación. Estas interacciones entre procesos a menudo requieren efectuar
concesiones entre los requisitos y los objetivos del proyecto.
39
El éxito de una dirección de proyectos incluye la gestión activa de estas
interacciones con el fin de cumplir satisfactoriamente con los requisitos del
patrocinador, el cliente y los demás interesados (PMI, 2004).
2.3.7.1 Procesos de Dirección de Proyectos
Según el PMI (2004), los procesos de dirección de proyectos se presentan como
elementos discretos con interfaces bien definidas. Los detalles específicos de un
proyecto se definen como objetivos que deben cumplirse sobre la base de la
complejidad, el riesgo, el tamaño, el plazo, la experiencia del equipo de proyecto,
el acceso a los recursos, la cantidad de información histórica, la madurez de la
organización en la dirección de proyectos, la industria y área de aplicación.
2.3.7.2 Grupos de procesos de Dirección de Proyectos
Existen cinco grupos de procesos, los cuales se ejecutan en cada proyecto. Estos
grupos de procesos tienen dependencias claras y se llevan a cabo siguiendo la
misma secuencia en cada proyecto. Un Grupo de Procesos incluye los procesos
de dirección de proyectos que están vinculados por las respectivas entradas y
salidas, es decir, el resultado o salida de un proceso se convierte en la entrada de
otro (PMI, 2004).
Los cinco Grupos de Procesos son:
• Grupo de Procesos de Iniciación: Define y autoriza el proyecto o una fase
del mismo.
• Grupo de Procesos de Planificación: Define y refina los objetivos, y planifica
el curso de acción requerido para lograr los objetivos y el alcance
pretendido del proyecto.
• Grupo de Procesos de Ejecución: Integra a personas y otros recursos para
llevar a cabo el Plan de Gestión del Proyecto para el Proyecto.
• Grupo de Procesos de Seguimiento y Control: Mide y supervisa
regularmente el avance, con el fin de identificar las variaciones respecto del
40
plan de Gestión de Proyecto, de manera tal que puedan tomarse medidas
correctivas cuando se requiera para cumplir con los objetivos del proyecto.
• Grupo de Procesos de Cierre: Formaliza la aceptación del proyecto, servicio
o resultado, y termina ordenadamente el proyecto o una fase del mismo.
2.3.7.3 Correspondencia de los procesos de dirección de Proyectos
El PMI (2004), establece la correspondencia de los 44 procesos de dirección de
proyectos en los cinco grupos de Procesos de Dirección de Proyectos y las nueve
áreas de conocimiento de la dirección de Proyectos. Cada proceso de la dirección
de proyectos se muestra en el Grupo de Procesos en el cual se lleva acabo la
mayor parte de la actividad.
Dicha correspondencia se muestra en el cuadro No 1.
Cuadro No 1 Correspondencia de los Procesos de Dirección de Proyectos a los Grupos de Proceso (PMI, 2004). Adaptación de Yorleny Retana, 2007.
Grupos de Procesos de Dirección de Proyectos Procesos de un Área de
Conocimiento
Gestión de la Integración del Proyecto
Desarrollar el Acta de constitución del Proyecto. Desarrollar el Enunciado del Alcance del Proyecto Preliminar.
Desarrollar el Plan de Gestión del Proyecto.
Dirigir y Gestionar la Ejecución del Proyecto.
Supervisar y Controlar el trabajo del Proyecto. Control Integrado de Cambios.
Cerrar el Proyecto.
Gestión del Alcance del Proyecto
Planificación del Alcance. Definición del Alcance. Crear EDT.
Verificación del Alcance. Control del Alcance.
Grupo de procesos
de iniciación
Grupo de procesos de Planificación
Grupo de procesos
de Ejecución
Grupo de procesos de Seguimiento
y control
Grupo de procesos de
Cierre
41
Gestión del Tiempo del Proyecto
Definición de las Actividades. Establecimiento de la secuencia de las actividades. Estimación de recursos de las actividades. Estimación de la duración de las Actividades. Desarrollo del cronograma.
Control del Cronograma
Gestión de los costos del Proyecto
Estimación de Costes. Preparación del presupuesto de costes.
Control de Costes
Gestión de la Calidad del Proyecto
Planificación de Calidad
Realizar aseguramiento de calidad.
Realizar Control de calidad.
Gestión de Recursos Humanos del Proyecto
Planificación de los Recursos Humanos.
Adquirir el equipo de Proyecto. Desarrollar el equipo del Proyecto.
Gestionar el equipo del proyecto
Gestión de las comunicaciones del proyecto
Planificación de las comunicaciones
Distribución de la información
Informar el rendimiento. Gestionar los Interesados.
Gestión de los Riesgos del Proyecto
Planificación de la Gestión de Riesgos. Identificación de Riesgos. Análisis cualitativo de Riesgos. Análisis cuantitativo de riesgos. Planificación de la Respuesta a los riesgos
Seguimiento y control de Riesgos.
Gestión de las Adquisiciones del Proyecto
Planificar las compras y Adquisiciones. Planificar la Contratación.
Solicitar Respuestas de vendedores. Selección de Vendedores
Administración del Contrato
Cierre del Contrato.
42
2.3.8 Áreas de Conocimiento de la Administración de Proyectos
A continuación se describe cada una de las áreas de conocimiento de la
Administración de Proyectos que servirán como herramienta principal para el
desarrollo del Proyecto.
• Gestión de la Integración del proyecto: Permite asegurar que todos los
diferentes elementos del proyecto estén coordinados de manera apropiada.
• Gestión del Alcance del Proyecto: incluye todo el trabajo necesario,
detallando qué se hace y qué no se hace, con el fin de completar en forma
exitosa el proyecto.
• Gestión del tiempo del Proyecto: Contiene todos los procesos requeridos
para garantizar que el proyecto se terminará en el tiempo fijado. Existe una
gran interacción con otras áreas de conocimiento (PMI, 2004).
• Gestión de Costos del Proyecto: Se refiere a la planificación de los
recursos, estimación de costos, asignación de presupuestos y control de
costos, de forma tal que se garantice que el proyecto se complete dentro
del presupuesto aprobado.
• Gestión de la calidad del proyecto: Descripción de los procesos requeridos
para garantizar la satisfacción de las necesidades que dieron origen al
proyecto (PMI, 2004).
• Gestión de los Recursos Humanos del Proyecto: Descripción de todos los
procesos requeridos para garantizar un uso efectivo del personal asignado
al proyecto.
• Gestión de las comunicaciones del Proyecto: Describe todos los procesos
requeridos para asegurar que la generación, recolección, distribución,
almacenamiento y destino final de la información se realice en tiempo y
forma.
• Gestión de Riesgos del Proyecto: Describe procesos de identificación,
análisis y respuesta a los riesgos del Proyecto (PMI, 2004).
43
• Gestión de las adquisiciones del Proyecto: procesos requeridos para la
adquisición de bienes y servicios que coadyuvarán al desarrollo del
proyecto.
De las áreas de conocimiento previamente definidas, las siguientes serán
desarrolladas durante el proyecto:
Gestión del alcance del Proyecto:
El alcance permitirá delimitar el proyecto; incluye los procesos necesarios para
asegurarse que el proyecto contiene todo el trabajo requerido, y sólo el trabajo
requerido, para completar el mismo. (PMI, 2004)
Gestión del Tiempo del Proyecto:
Se definirán las actividades y recursos que comprenden el proyecto, secuencia de
tales actividades y duración de cada una con el fin de ayudar a la consecución del
proyecto en el tiempo planificado, ayudado por el desarrollo y control del
cronograma.
Gestión de Comunicaciones del proyecto:
Gran parte del éxito de las organizaciones se debe al manejo de las
comunicaciones, las cuales deben ser efectivas y constantes dentro de los
miembros del equipo de proyecto y demás interesados.
Según el PMI (2004), la Gestión de las comunicaciones del Proyecto es el área de
conocimiento que incluye los procesos necesarios para asegurar la generación,
recogida, distribución, almacenamiento, recuperación y destino final de la
información del proyecto en tiempo y forma.
El presente proyecto contempla una serie de herramientas mediante las cuales se
llevará a cabo la gestión de comunicaciones a todos los involucrados del mismo.
44
Gestión de las Adquisiciones del Proyecto:
Serán todas aquellas gestiones que el equipo de proyecto deberá realizar para
adquirir los bienes o servicios necesarios para llevar a cabo el desarrollo del
proyecto.
Los puntos a desarrollar serán:
a) Planificar las compras y adquisiciones:
El proceso Planificar las Compras y Adquisiciones identifica qué necesidades del
proyecto pueden satisfacerse de mejor manera comprando o adquiriendo los
productos, servicios o resultados fuera de la organización del proyecto, y qué
necesidades del proyecto puede satisfacer el equipo del proyecto durante la
ejecución del proyecto. Este proceso implica considerar si es conveniente adquirir,
qué y cuánto adquirir, y cómo y cuándo hacerlo.
El proceso Planificar las Compras y Adquisiciones comprende la revisión de los
riesgos involucrados en cada decisión de fabricación propia o compra; también
incluye la revisión del tipo de contrato que se planea usar con respecto a mitigar
los riesgos y transferir riesgos al vendedor. (PMI, 2004)
b) Planificar la Contratación:
El proceso Planificar la contratación prepara los documentos necesarios para
respaldar el proceso Solicitar Respuestas de Vendedores y el Proceso Selección
de Vendedores (PMI, 2004)
45
3 MARCO METODOLÓGICO
3.1 Descripción de la Metodología
3.1.1 Descripción del método de investigación
Para el desarrollo del Plan de Implementación de una solución tipo Single Sign -
On en el Instituto Nacional de Seguros para las Plataformas OS/400, UNIX y
WINDOWS se utilizará principalmente la metodología PMI (2004) para la
Administración de Proyectos.
También se utilizará el Método analítico – sintético que consiste en descomponer
una unidad en sus elementos más simples, examinar cada uno de ellos por
separado, volviendo a agrupar las partes para considerarlas en conjunto. (Jurado,
2002).
3.1.2 Tipo de investigación
La investigación que se realizará será de tipo Mixta ya que consistirá en la
recopilación y tratamiento de datos derivados tanto de la investigación documental
como de la investigación de campo.
De la investigación documental se obtendrán datos existentes en Libros (teorías,
tópicos, etc.) que se utilizarán como base para el desarrollo del trabajo. Dicha
documentación se basará principalmente en los libros PMBOK (2004) y
Administración Profesional de Proyectos La Guía y la información provista por el
Departamento de Operación y Soporte Técnico del INS.
De la investigación de campo se obtendrá información relativa a la cantidad de
aplicaciones utilizadas en el INS y que son albergadas por las Plataformas
OS/400, AIX y Windows, además del esquema de seguridad aplicado a cada
aplicación.
46
3.1.3 Fuentes de Información
Las fuentes de información a utilizar en este proyecto serán:
• Fuentes Primarias: Se refiere a aquellos portadores originales de la
información que no han retransmitido o grabado en cualquier medio o
documento, la información de interés (Eyssautier, 2002). En este caso, se
acudirá a la información que proporcionen los Directores de Proyecto de los
Departamentos de Proyectos y Sistemas y Soporte Técnico, así como la que
proporcione la Jefatura del Dpto. de Gestión de Servicios de Tecnología y
Telecomunicaciones.
• Fuentes Secundarias: Se utilizará información recopilada tanto vía Internet
como la documental, provista por los distintos proveedores para la
documentación de un estudio de tres soluciones tipo Single Sign – On
existentes en el mercado.
• Fuentes documentales: Para la investigación se utilizarán textos originales de
Administración de proyectos, entre los que destacan el PMBOK (PMI, 2004) y
Administración Profesional de Proyectos La Guía (Chamoun, 2004).
3.2 Descripción de las Herramientas
A continuación se describen las herramientas que se utilizarán en esta
investigación:
3.2.1 Declaración del Alcance
En la Declaración del Alcance se pretende detallar cada uno de los entregables
del Proyecto, desglosando para ello cada una de las actividades que lo componen.
Según Chamoun (2005) la declaración del alcance es como realizar pequeños
Charter de cada entregable final, subdividiéndolos, describiéndolos y
especificando cómo deben quedar para ser aceptados por el Cliente.
47
3.2.2 EDT (Estructura de Desglose de Trabajo)
La EDT es una estructura a partir de la cual se desglosan los entregables
principales del proyecto en subtareas hasta llegar a un nivel de detalle suficiente
como para mantener un control de cada actividad asociada.
3.2.3 Diccionario de la EDT
Este diccionario se desarrolla paralelamente a la EDT. El mismo es una
descripción del alcance de cada componente, recurso responsable, fecha de
inicio, fecha de finalización, estimación de costos (si lo contempla), requisitos de
calidad y técnicos para facilitar el rendimiento del trabajo. (P.M.I, 2004).
3.2.4 Programa del Proyecto
Es una herramienta que desglosa los entregables del WBS en términos de
actividades, incluyendo la interrelación entre ellas y su secuencia a lo largo de la
duración del proyecto. Permite establecer las fechas de inicio y terminación del
proyecto, de cada fase, entregable y actividad (Chamoun, 2005).
3.2.5 Ruta Crítica
La Ruta Crítica se refiere a una serie de actividades que determinan la ruta más
larga para determinar el proyecto. Si alguna de dichas actividades se retrasa, el
proyecto total, estaría igualmente retrasado. A las actividades que componen la
Ruta Crítica se les denomina actividades críticas (Chamoun, 2005).
3.2.6 Diagrama organizacional del Proyecto
Representación gráfica que define el nivel de autoridad, dependencia
organizacional y toma de decisiones del Proyecto.
48
3.2.7 Matriz de Roles y Responsabilidades
Herramienta que sirve de apoyo para la planeación de los involucrados clave
quienes aplicarán sus conocimientos y habilidades con el fin de lograr el mejor
aprovechamiento del equipo (Chamoun, 2005).
3.2.8 Matriz de involucrados o interesados
Permite al director de Proyecto y su equipo, identificar y clasificar al recurso
humano u organizacional con intereses directos sobre la afectación del proyecto.
Los involucrados o interesados tienen niveles de responsabilidad y autoridades
variables al participar en un proyecto, y este puede variar a lo largo del mismo.
3.2.9 Matriz de comunicación
Es una herramienta cuya finalidad es mantener informados a los involucrados y
asegurar una comunicación efectiva. Facilita la toma oportuna de decisiones y la
tranquilidad de los involucrados clave (Chamoun, 2005).
3.2.10 Informes de Seguimiento del Proyecto
Es un documento que permitirá informar a los involucrados claves y al
patrocinador, los avances del proyecto, aciertos, desaciertos, atrasos y cualquier
otra consideración que afecte tanto los tiempos como el desarrollo del Proyecto
3.2.11 Juicio Experto
Una herramienta que servirá de apoyo a algunos procesos de la gestión será el
Juicio Experto de los especialistas del Área de Infraestructura. Adicionalmente, el
proyecto se apoya en la experiencia de la Jefatura del Dpto. de Gestión de
Servicios de Tecnología y Telecomunicaciones, tanto para hacer
recomendaciones como para apoyar la toma de decisiones.
49
3.2.12 Sistema de Control de Cambios
Herramienta que administra los cambios acontecidos de forma tal que: añada valor
al proyecto, se autoricen tanto los cambios como sus efectos en tiempo y alcance
y actualizar todos los documentos correspondientes.
Para efectos del proyecto, el control de cambios será administrado a través de una
plantilla donde se documente el tipo de cambio a realizar a la información
recopilada, la fecha, el solicitante, la razón de la solicitud y el impacto sobre el
proyecto en general.
3.2.13 Reuniones
Cuando el Director del Proyecto o la Jefatura del departamento lo consideren
conveniente, se realizarán reuniones con los involucrados para informar y acordar
cualquier cambio en las actividades del proyecto. Para informar y documentar
estas reuniones se utilizará un machote de minuta el cual contempla, la fecha y
hora de la reunión, participantes internos de la organización y externos a ella, así
como un desglose de todos los acuerdos tomados.
3.2.14 Minutas
Plantilla que será utilizada para documentar el resultado de cada reunión o sesión
de trabajo formal que sea realizada, tanto con personal técnico de la empresa
como con los posibles proveedores de la solución.
3.2.15 Diagrama de Gantt
Es una representación gráfica de las actividades a través del tiempo (Chamoun,
2005). A través de ella, el equipo de proyecto podrá dar seguimiento a cada
actividad que conforma un entregable, controlando los plazos de inicio y
conclusión.
50
3.2.16 Matriz de evaluación de Alternativas
Esta matriz permite seleccionar proveedores, por medio de criterios cuantitativos.
Además de sus múltiples aplicaciones, sirve para decidir cual es la mejor empresa
antes de contratar.
Para efectos de este Plan de Implementación, se propondrá la herramienta así
como potenciales criterios de evaluación que sirvan como base para la evaluación
de los proveedores seleccionados para la muestra de sus productos en la
Institución.
3.2.17 Lecciones Aprendidas
Durante el proceso de control, al presentarse los cambios y condiciones
inesperadas, surge la oportunidad de aprender de las experiencias vividas y
compartirlas con los miembros del equipo, así como otros equipos de proyecto.
Estas lecciones aprendidas servirán para fases posteriores del proyecto y para
futuros proyectos, facilitando el proceso de mejora continua (Chamoun, 2002)
3.2.18 Investigación de mercado
Según la página Web Pymes, la investigación de mercado es una técnica que
permite recopilar datos, de cualquier aspecto que se desee conocer para,
posteriormente, interpretarlos y hacer uso de ellos. Sirven a la organización para
realizar una adecuada toma de decisiones y para lograr la satisfacción de sus
clientes.
3.2.19 Definición de Requerimientos
La definición de requerimientos en general, es la recopilación de información, y
datos estadísticos, relativos a un ámbito específico a evaluar.
51
Para el caso del Instituto Nacional de Seguros, se recopilará y analizará
información de las aplicaciones, usuarios y esquema de autenticación que
componen la Plataforma tecnológica del INS.
3.2.20 Cartel
El cartel o pliego Cartelario es un conjunto de especificaciones tendiente a la adquisición de un bien o Servicio
3.2.21 Acta de cierre administrativo del proyecto
El cierre administrativo consiste en verificar y documentar los resultados del
proyecto para formalizar la aceptación de los entregables del proyecto, ya sea por
el cliente o el Patrocinador (Chamoun, 2002).
3.2.22 Acta de cierre de entregables
El Acta de cierre de Entregables es un insumo que finiquita la aprobación de cada
entregable que conforma el Producto a generar.
3.2.23 Acta de comunicación de Cierre
Mediante el acta de Cierre se comunica a todos los involucrados la finalización
oficial del Proyecto.
52
3.2.24 Herramientas de Software
Dentro de las Herramientas de Software que se utilizarán como soporte a la
ejecución del proyecto se encuentran las siguientes:
3.2.24.1 Microsoft Project
Herramienta de Software que permite desarrollar cronogramas de actividades para
el seguimiento de estas, asignación de recursos y manejo del tiempo. A través de
ésta se podrá dar seguimiento y control de todas las tareas incluidas en las
distintas etapas o entregables del proyecto
3.2.24.2 Microsoft WBS Chart Pro
Herramienta de Software que permite, a través del Cronograma desarrollado en
Microsoft Project, crear la EDT que incluye el detalle de las actividades
involucradas por entregable.
3.2.24.3 Editor de Texto Microsoft Word
Se utilizará durante todo el proyecto la herramienta Word como editor de texto
para la manipulación de toda la documentación requerida durante el proyecto.
3.2.24.4 Hoja de Cálculo Microsoft Excel
Según se requiera, para la confección de Plantillas, se utilizará Microsoft Excel
como herramienta de apoyo
3.2.24.5 Lotus Notes
Herramienta de correo electrónico, la cual será utilizada como herramienta de
comunicación entre los interesados del proyecto.
53
4 DESARROLLO 4.1 Ciclo de Vida del Proyecto
El Ciclo de vida para el Plan de Gestión de Proyecto para la Implementación de
una Solución tipo Single Sign- On en el Instituto Nacional de Seguros para las
Plataformas OS/400, AIX y WINDOWS se divide en varias etapas según los
entregables más significativos del proyecto en sí.
4.1.1 Descripción de Fases del Proyecto
Fase I – Levantamiento de requerimientos
En esta fase de documentarán los requerimientos del INS respecto a la
Implementación de dicha solución. Dentro de estos requerimientos se encuentran
la identificación y listado de todas las aplicaciones existentes en las diferentes
Plataformas tecnológicas del INS que serán consideradas para la autenticación;
documentando la cantidad de usuarios internos y externos que las utilizan,
documentación de la Infraestructura que soporta actualmente la autenticación de
los usuarios a través del Active Directory y niveles actuales de seguridad.
Finalmente, se harán algunas consideraciones respecto a la necesidad de
considerar un equipo redundante, apoyados en los esquemas contingentes que
contemplen las soluciones analizadas.
Fase II – Estudio de mercado
La segunda fase contempla un estudio de mercado para analizar de manera
general soluciones ofrecidas en el mercado, documentando las ventajas y
desventajas del producto, requerimientos de implementación en general, esquema
de seguridad, esquema contingente o de alta disponibilidad y cualquier otra
consideración que de valor agregado al producto.
Esta etapa también incluirá la documentación de propuestas de los proveedores
interesados, considerando el presupuesto por adquisición de la solución,
54
implementación de la misma, costos por licenciamiento y renovación, así como el
mantenimiento de las licencias
Fase III – Estudio de Costo
En esta etapa se desarrollará un estudio costo – beneficio a partir del cual la
Jefatura de Soporte Técnico definirá la viabilidad del proyecto.
Fase IV – Adquisiciones
En esta etapa se considerará, mediante la Gestión de las Adquisiciones, la
confección de un Cartel donde se exponga la necesidad de adquirir una Solución
tipo Single Sign On, así como la implementación de la misma en el Instituto
Nacional de Seguros.
Dentro de esta etapa se contempla la documentación de solicitud de publicación
del Cartel al Departamento de Proveeduría.
Fase V – Cierre del Proyecto
Finalmente, se documentará llevarán el cierre administrativo y técnico del
Proyecto.
4.2 Plan de Gestión del Alcance del Proyecto
Conscientes de los actuales problemas a los que se enfrenta la Dirección de
Informática al incurrir en altos costos por concepto de activación y reactivación de
claves en las aplicaciones que conforman las Plataformas OS/400, AIX y
WINDOWS, además de la necesidad de contar con una herramienta de punta que
permita la autenticación única de manera que múltiples aplicaciones requieran un
solo usuario de activación para su ingreso, el Departamento de Operación y
Soporte Técnico consideró la conveniencia de realizar un diagnóstico de la actual
plataforma, y a partir de allí, el Proyecto de Implementación de una solución tipo
Single Sign – On en el INS para las plataformas precitadas.
55
El objetivo principal de la Gestión del Alcance es definir de forma clara y concisa
las actividades requeridas para cumplir con el objetivo del Proyecto. El Acta de
constitución es la entrada principal para el desarrollo de este Plan pues es a partir
de ésta, donde se autoriza y define de forma preliminar el Proyecto, con el equipo
de Proyecto y la Jefatura del Departamento de Operación y Soporte Técnico.
Las salidas de este Plan serán: La Definición del alcance y la EDT.
4.2.1 Planificación del Alcance
Con el fin de delimitar certeramente el Alcance de este proyecto, se solicitó a un
proveedor externo, la realización de un pequeño estudio que definiera si con la
actual infraestructura de TI, el INS estaría en capacidad de adquirir e implementar
una solución tipo Single Sign – On en el INS. Basados en dicho estudio y con la
colaboración de la Jefatura de Soporte Técnico, conjuntamente con el Encargado
del Área de Infraestructura y el Área de Mantenimiento, adscritas a dicha
dependencia, se definió el correspondiente Alcance.
El Desarrollo de la EDT se realizó con la colaboración de los mismos recursos
utilizando para ello la experiencia técnica de éstos en las plataformas expuestas y
de manera general en el tipo de solución requerida por este proyecto.
4.2.2 Definición del Alcance
Para la definición del Alcance se establecieron los siguientes puntos a través de
los cuales se delimita el objetivo del Proyecto, entregables, mediciones,
exclusiones, restricciones y supuestos de éste.
4.2.2.1 Objetivo del proyecto
Diseñar un Plan de Proyecto para la implementación de una solución tipo Single
Sign-On en el Instituto Nacional de Seguros para las plataformas OS/400, AIX y
WINDOWS.
56
4.2.2.2 Alcance
4.2.2.2.1 Entregables
• Análisis de Requerimientos del INS para la implementación de una solución
tipo Single Sign – On.
• Investigación de mercado de soluciones Tipo Single Sign –On existentes en
el mercado Nacional.
• Estudio de factibilidad Técnica.
• Cartel para la adquisición e implementación de la solución.
4.2.2.2.2 Mediciones
• La etapa que va desde la investigación de opciones de mercado hasta la
confección del cartel debe ser máximo de 90 días hábiles.
• El estudio de opciones en el mercado debe contemplar al menos 2 posibles
oferentes. Esto dependerá de la cantidad de proveedores de soluciones
tipo Single Sign – On, existentes en el mercado Nacional.
• Se desarrollará un estudio de factibilidad que permita identificar la viabilidad
de una eventual implementación.
4.2.2.2.3 Exclusiones
Las exclusiones para el presente proyecto se definen de la siguiente forma:
• El Plan de Proyecto no incluye un Plan de Gestión de Riesgos ni tampoco
un Plan de Gestión de Calidad.
• El proyecto no incluirá dentro del Plan de Gestión de Adquisiciones, las
etapas de evaluación de ofertas, adjudicación, administración y cierre del
contrato.
• Se excluye del proyecto, la implementación de la solución en la Plataforma
Windows.
• Se excluyen del estudio, todas las aplicaciones cuya cantidad de usuarios
sea inferior o igual a 50.
57
4.2.2.2.4 Restricciones
Las restricciones para este proyecto se detallan a continuación:
• Los avances en la documentación del proyecto dependerán de la
colaboración de las áreas técnicas que administran parte de la información
requerida para éste, así como el tiempo que puedan brindar para atender
los requerimientos derivados de la investigación.
4.2.2.2.5 Supuestos
Los supuestos de este proyecto se definen de la siguiente manera:
• Las plataformas que conforman la actual infraestructura del INS son
compatibles con Soluciones Tipo Single Sign – On.
• El INS brindará la documentación necesaria para definir de manera precisa
los requerimiento de dicha organización para la eventual implementación de
una solución tipo Single Sign - On
4.2.3 Estructura de Desglose del Trabajo
Para la puesta en marcha del Plan de Proyecto de Implementación de una
solución tipo Single Sign – On se utilizará la estructura de división de trabajo
(WBS) expuesta en los anexos. Dicha estructura define los entregables, sub
tareas por entregable, tiempos y responsables de su ejecución.
La herramienta utilizada para graficar dicha estructura fue el WBS Chart Pro.
El WBS de este proyecto se detalla en el Anexo No 7.2.
4.3 Plan de Gestión del tiempo del Proyecto
Este Plan incluye todos los procesos necesarios para asegurar que el proyecto se
finalice en el tiempo establecido. Para obtener un cronograma y duración del
proyecto, se realizó una identificación de las actividades y sub actividades,
necesarias para completar cada entregable. De igual forma, se estimaron las
58
fechas de inicio y finalización de cada actividad utilizando para ello el juicio experto
así como la experiencia en proyectos previos de similar alcance.
Como herramienta principal para la Gestión del Tiempo, se utilizó el software MS
Project Versión 2003, la cual, mediante el diagrama de Gantt, grafica la secuencia
de actividades y tiempos.
El correspondiente Plan de Gestión del tiempo se detalla en el Anexo No 7.3.
4.3.1 Definición de Actividades
En el apartado de anexos se presenta el desglose de la actividades que
conformarán el Plan de Proyecto para la Implementación de una Solución tipo
Single Sign – On en el Instituto Nacional de Seguros para las Plataformas OS/400,
AIX y Windows.
La definición de estas actividades se hace sobre la base de una solicitud formal de
la Jefatura de Soporte Técnico por lo que el orden pre establecido se deriva de los
entregables requeridos por la Jefatura.
4.3.2 Secuencia y Dependencia de las actividades
La determinación de la secuencia e interrelación de las actividades de definió
basado en varios aspectos:
1. Solicitud formal emanada de la Jefatura de Operación y Soporte Técnico
donde se describen los entregables requeridos para posterior a un proceso
licitatorio, adquirir e implementar una solución tipo Single Sign – On para el
INS.
2. Considerando las necesidades definidas por la Jefatura de Soporte Técnico
del INS, conocida a partir de ahora como Departamento de Gestión de
Servicios tecnológicos y Telecomunicaciones, se establecieron, tanto los
entregables como las actividades requeridas para completar cada uno de
ellos.
59
3. Los entregables definidos por la Jefatura para el proceso son los siguientes:
a. Definición de requerimientos del Instituto Nacional de Seguros para
la eventual implementación de una solución tipo Single Sign – On.
b. Análisis de Mercado de Soluciones tipo Single Sign – On existentes
en el mercado.
c. Estudio de Factibilidad Técnica.
d. Confección de un cartel o pliego de condiciones.
4.3.3 Estimación de las duraciones de las actividades
La determinación de las duraciones de las actividades se hace utilizando tanto el
Juicio Experto como la experiencia en proyectos de similar envergadura donde se
analizaron otras herramientas de mercado y se desarrollaron los carteles
respectivos.
La Duración total del Proyecto es de 88 días, los cuales están desglosados de la
siguiente forma:
1. Proceso de Iniciación: 8 días.
2. Proceso de Planificación: 14 días
3. Proceso de Ejecución: 52 días
a. Investigación de mercado: 7 días
b. Definición de requerimientos de la Institución : 23 días
c. Estudio de Factibilidad Técnica: 9 días
d. Confección del Cartel: 8 días
4. Seguimiento y control: 4 días
5. Cierre del Proyecto: 4 días
6. Trámite de PFG: 6 días
Para la Definición de requerimientos del INS, se deben contemplar 5 días más,
derivados del tiempo requerido por los proveedores para presentar sus
propuestas.
60
4.4 Plan de Gestión de Recursos Humanos
4.4.1 Organización del Proyecto
4.4.1.1 Estructura del equipo de Trabajo
Para llevar a cabo el presente proyecto, la Jefatura del Departamento de Gestión
de Tecnología y telecomunicación definió la siguiente estructura
organizacional.
Figura No 13. Estructura del equipo de Trabajo.
4.4.1.2 Roles y responsabilidades del equipo de proyecto
A continuación se describen los roles y responsabilidades del equipo de proyecto:
Patrocinador del proyecto: Gestor del Proyecto. Se encarga de definir de
manera inicial los requerimientos del proyecto, dando seguimiento a éste en cada
una de sus etapas, a través de la revisión de documentación, solicitud de cambios,
verificación de estándares de calidad y veracidad de la información. De igual
forma, se encarga de aprobar cada entregable, evaluando que cada uno se ajuste
a lo requerido por el proyecto.
Dpto. Gestión de Tecnología y Telecomunicaciones
Patrocinador del Proyecto
Gerente de Proyecto
Yorleny Retana
Consultores Externos
Grupo de Apoyo
61
En el cuadro No 2, se detalla el nombre y puesto del Patrocinador del proyecto.
Cuadro No 2. Patrocinador del Proyecto
Funcionario Organización Puesto
Alexandra Chinchilla INS Jefe del Dpto. de
Gestión de Tecnología y
Telecomunicaciones
Gerente de Proyecto: Funcionario encargado de coordinar y ejecutar las labores
de investigación, análisis y documentación del Proyecto. De igual forma, se
encarga de la coordinación del proceso de identificación y evaluación de
proveedores.
En el cuadro No 3, se detalla el nombre y puesto del funcionario encargado de
gerenciar el proyecto.
Cuadro No 3. Gerente del Proyecto
Funcionario Organización Puesto
Yorleny Retana M INS Director de Proyectos II.
Consultores Externos: Especialistas de empresas oferentes del producto a
evaluar, encargadas de analizar los requerimientos del INS con el fin de ofrecer
una propuesta de adquisición e implementación.
El cuadro No 4, expone los consultores para cada empresa
Cuadro No 4. Consultores Externos
Funcionario Organización Puesto
Jackson Sotomayor GBM Ejecutivo de Cuenta
Edwin Muñoz CR Conectividad Ejecutivo de Cuenta
62
Grupo de apoyo técnico: Grupo de técnicos especialistas que servirán de apoyo
en la entrega de información para el Proyecto.
El cuadro No 5, detalla el nombre y puesto de los funcionarios que conforman el
grupo de apoyo para este proyecto.
Cuadro No 5. Grupo de Apoyo al Proyecto
Funcionario Organización Puesto
Erick Córdoba INS Encargado del Área de
Mantenimiento
Erick Monge INS Encargado Área de
Infraestructura
Ricardo Salazar INS Especialista en
Plataforma OS/400
Jenny Pereira INS Especialista del Área de
Infraestructura
Randall Vallejos INS Encargado Área de
Negocio electrónico
4.4.1.3 Matriz de Roles y Responsabilidades
A continuación, en el cuadro No 6, se presenta la matriz de roles y
responsabilidades del Proyecto donde para cada actividad contemplada en el
WBS se establece el responsable y el tipo de participación de cada uno de los
involucrados.
Esta participación será de Ejecución, Participación, Coordinación, Revisión o
Autorización según sea haya definido en la etapa de Planificación.
63
Cuadro No 6 Matriz de Roles y Funciones del Proyecto
64
4.4.1.4 Responsabilidades y obligaciones
Con el fin de delimitar las acciones que desarrollará cada involucrado durante el
proyecto, a continuación se establecen las responsabilidades y obligaciones de
cada uno de éstos:
INS:
Patrocinador del Proyecto: Para efectos de este proyecto, el patrocinador es la
Jefatura del Departamento de Gestión de Servicios Tecnológicos y
Telecomunicaciones. Dicho funcionario se encarga de dar seguimiento a los
avances del proyecto en cada uno de sus entregables. De igual forma, dará
validez a cada entregable y al proyecto final.
Gerente De Proyecto: Encargado de investigar, documentar y desarrollar cada
entregable. De igual forma, se encarga de coordinar las reuniones con los
proveedores de las soluciones a investigar.
Grupo de Apoyo: Apoya la gestión del Gerente de Proyecto, facilitando
documentación institucional relevante para la identificación de los requerimientos
del INS. Los funcionarios que conforman este grupo de apoyo no son recursos
asignados directamente al proyecto, no obstante, por el tipo de documentación
que administran y por la experiencia de cada uno, aportan recursos documentales
importantes a la gestión.
Consultores Externos:
Lo consultores externos apoyarán la labor documental realizada por el Gerente de
Proyecto del INS, remitiendo información específica de dicha soluciones.
Adicionalmente, entregarán una propuesta de adquisición considerando
licenciamiento, instalación del producto, mantenimiento del producto y soporte
para siguientes años.
65
4.4.1.5 Entregables del Proyecto
En el cuadro No 7 se desglosan los entregables que conforman el Proyecto
considerando tiempos aproximados de entrega y criterios de aceptación los cuales
delimitan la aprobación de cada entregable:
Cuadro No 7 Desglose del Plan de Entregables
PLAN DE ENTREGABLES Y CUMPLIMIENTO
Proyecto: Plan de Proyecto para la implementación de una solución tipo single Sign On en el Instituto Nacional de Seguros para las plataformas OS/400, AIX y Windows
Gerente de Proyecto: Yorleny Retana,INS
Fecha:15 de febrero del 2008
No. Entregable Descripción del Entregable
Entrega Al Día
Responsable Criterio de Aceptación
1 Análisis de Mercado
Especificación de Soluciones Tipo Single Sign On existentes en el mercado nacional
27/03/2008
Gerente de Proyecto
Aprobación por parte de la Jefatura del Dpto. de Gestión de Servicios Tecnológicos y Telecomunicaciòn
2 Identificación de requerimientos del INS
Documentación de los requerimientos del INS para la adquisición e implementación de una solución tipo Single sign On
30/04/2008
Gerente de Proyecto
Completamiento y aprobación de 1er entregable
3 Estudio de Factibilidad Técnica Estudio costo - beneficio
14/05/2008
Gerente de Proyecto
Entrega por parte de los proveedores, de una propuesta de implementaciòn. Aprobaciòn de primeros dos entregables.
4 Cartel
Pliego Cartelario para la adquisición e implementación de la solución
26/05/2008
Gerente de Proyecto
Aprobación por parte de la Jefatura del Dpto. de Gestión de Servicios Tecnológicos y Telecomunicaciòn
66
4.5 Plan de Comunicaciones
Este proceso está orientado a lograr una comunicación efectiva y fluida entre los
involucrados del Proyecto para asegurar la oportuna y apropiada generación,
recolección, distribución, archivo y disposición final de la información generada por
cada entregable del mismo (Chamoun, 2002).
Para efectos de éste Proyecto, se establecieron las siguientes herramientas como
mecanismos de comunicación:
1. Matriz de comunicación: A través de ella, se identificará el tipo de
documentación que se remitirá, la frecuencia con que será comunicada y él
o los responsables de generarla y recibirla (Ver Anexo 7.4).
2. Estatus Semanal: El estatus semanal permitirá a la Jefatura del
Departamento de Gestión de Servicios Tecnológicos y Telecomunicaciones,
definir los avances por cada entregable, considerando las prioridades,
amenazas, tiempos de entrega y cualquier otra observación de valor para el
proyecto (Ver anexo 7.5).
3. Informe de avance Quincenal: Cada 15 días, se entregará a la Jefatura un
avance documental por cada entregable. De esta forma, se procederá a
validar la documentación generada o en su defecto, solicitar los cambios
que se consideren, los cuales serán documentados en la plantilla de
solicitud de cambios.
4. Minutas de reuniones: Cuando se realicen reuniones con cada proveedor,
se remitirá tanto a la Jefatura como a cada uno de ellos, una minuta con los
acuerdos tomados en función de los temas tratados. La entrega de estas
minutas es únicamente para informar a cada involucrado, los temas
tratados, antecedentes de cada reunión y los acuerdos. De haber
incongruencias o desacuerdos respecto a lo expuestos en éstas, los
involucrados remitirán sus observaciones para actualizar la minuta y
proceder con el envío formal. (Ver Anexo 7.6).
67
5. Entradas de reunión: Se utilizará la plantilla de Entrada de reunión,
contenida en la Herramienta de Correo de Lotus, para acordar formalmente,
la fecha y hora de reunión con proveedores y/o recurso humano del grupo
de apoyo. (Ver anexo 7.7)
6. Cierre administrativo del Proyecto: Habiéndose cumplido los objetivos que
se generaron durante la ejecución del proyecto, aprobados los entregables
y realizada la entrega del producto para el cual se estableció el proyecto, se
entregará físicamente, el documento de cierre administrativo del proyecto
(Ver anexo 7.10).
La documentación generada será remitida según se considere, de forma física
como documento impreso o mediante correo electrónico en forma digital.
Según se requiera, se utilizará el teléfono como mecanismo de comunicación
inmediata, apoyado por los otros recursos.
4.5.1 Herramientas de Comunicación
Para la divulgación de toda la documentación de que se compone el proyecto se
utilizarán las siguientes herramientas de apoyo:
1. Lotus Notes: Correo Interno del INS a través del cual se solicitará o
entregará la documentación respectiva, a la Jefatura del Departamento
gestor del Proyecto, a los proveedores y al Grupo de Apoyo.
A través de esta herramienta se divulgarán las citas de reunión con
proveedores y/o grupo de Apoyo.
2. Teléfono: Según se requiera, se utilizará el Teléfono para contactar a
proveedores o acordar la entrega de alguna información.
68
4.6 Gestión de las Adquisiciones
Uno de los entregables del Proyecto es la generación de un Cartel de Licitación
para optar por una solución tipo Single Sign - On, así como el soporte del producto
por al menos 3 años.
Como etapas complementarias de la Generación de este cartel están:
1. Confección de un estudio de Factibilidad: Este estudio permitirá
establecer los gastos actuales en que incurre la Institución por concepto
de efectuar las labores de administración de claves. De igual forma, a
través de un ROI, se detallarán, los costos por adquisición de la
herramienta, licenciamiento, implementación y soporte, así como el
retorno de la inversión a tres años.
2. Definición de finalidad pública: La finalidad pública permitirá
establecer los alcances de la Contratación considerando la justificación
del bien a adquirir y a quienes se pretende beneficiar con su adquisición.
4.6.1 Planificación de la Adquisición
Para la Planificación de la Adquisición de la Solución tipo Single Sign – On se definieron los siguientes aspectos:
4.6.1.1 Identificación de la Necesidad
Para identificar la necesidad, se realizó de forma general, una evaluación de los
costos en que se incurre por concepto de administración de claves, considerando
que en las Sedes del INS se manejan aproximadamente 5 sistemas para realizar
las labores de gestión de pólizas. Además, se utiliza el Correo Interno, Internet,
otras aplicaciones vía Web; y la clave de acceso al Sistema Operativo.
Identificada dicha problemática, se consideró la posibilidad de adquirir una
herramienta de autenticación única, reduciendo con ello, los costos por atención
de incidencias a nivel de acceso, los problemas de seguridad por la mala práctica
69
del usuario final en la administración de sus claves, además de mejorar los
tiempos de atención al cliente.
4.6.1.2 Presupuesto
Una vez identificada y evaluada la necesidad de contar con la solución Single Sign
On, se solicitó de manera general a las empresas proveedoras, una factura
proforma con el desglose de los costos por Adquisición de la Herramienta,
adquisición de aproximadamente 2000 licencias, implementación y soporte del
producto. Dichas facturas permitieron hacer una proyección de los costos por los
servicios requeridos, los cuales fueron ajustados al 2009 con el fin de hacer la
gestión presupuestaria respectiva, misma que se incluyó en el PAO 2009.
Durante la primera semana de Mayo, dicho presupuesto es revisado por la Junta
Directiva del INS, quienes se encargan de dar el visto bueno para proceder con los
correspondientes procesos licitatorios según las prioridades definidas por los
Departamentos adscritos a la Dirección de Informática.
4.6.2 Planificación de la contratación
Para la etapa de Planificación de la contratación, se desarrollaron los rubros que
conforman el Pliego cartelario los cuales se desglosan en el Pliego de
Condiciones. El tipo de cartel (Licitación Pública, Contrato Directo, Licitación
restringida, etc) es establecido de previo, según las condiciones del Bien o servicio
y la cantidad de potenciales oferentes:
4.6.2.1 Elaboración del Pliego de Condiciones
El Cartel para optar por una solución tipo Single Sign On contempla de forma
general, las siguientes etapas:
4.6.2.1.1 Encabezado del Cartel
Como parte del Encabezado del Cartel, se define el nombre de la Institución
solicitante, el Departamento encargado del Trámite, el consecutivo o numeración
70
designada al proceso licitatorio así como el tipo de Licitación requerido. Así
mismo, se incluye el nombre completo de los servicios requeridos.
Adicionalmente, se incorpora la fecha y hora en que la Institución estará
recibiendo las ofertas respectivas, según se muestra a continuación:
INSTITUTO NACIONAL DE SEGUROS
DEPARTAMENTO DE PROVEEDURÍA
LICITACIÓN ABREVIADA XXXXX (2008LA-XXXXX-UL) PROV--2008
PLIEGO DE CONDICIONES
“ADQUISICIÓN DE 2500 LICENCIAS TIPO SINGLE SIGN ON PARA LA PLATAFORMA TECNOLOGICA INSTITUCIONAL”
San José, XX de XXXXX del 2008
El Instituto Nacional de Seguros recibirá ofertas por escrito, hasta las XX:00
horas del XX de xxxxx del 2008, para el servicio citado, con todo gasto pago e
impuestos incluidos, conforme a las siguientes condiciones y especificaciones:
4.6.2.1.2 Capítulo Uno de la licitación
Dentro del Capítulo Uno, del Pliego de condiciones se establecen varias etapas
donde se definen aspectos tan importantes como la descripción del requerimiento,
la evaluación, condiciones técnicas para el oferente, requisitos técnicos para el
oferente, condiciones técnicas para el adjudicatario y requisitos para el
adjudicatario.
71
4.6.2.1.2.1 Descripción del requerimiento
El objeto del Contrato contiene la especificación del Servicio o producto que se
pretende adquirir. En este apartado, deben detallarse los requerimientos del Bien
o servicio que se desea.
Para los efectos del cartel en cuestión se define el siguiente requerimiento:
RENGLON CANTIDAD DESCRIPCIÓN
Único 2500 Licencias de Software Single Sign On (Características en Anexo 1)
El detalle de dicho requerimiento se especifica al final del Cartel, en un anexo.
4.6.2.1.2.2 Evaluación
Según lo defina el Área de Contratación Administrativa de cada organización, la
evaluación puede basarse en el cumplimiento de ciertos requerimientos
específicos, tomando en cuenta aspectos adicionales a los establecidos como
mínimos en el Pliego Cartelario. Estos requerimientos deben puntuarse y
evaluarse durante la etapa de revisión de las ofertas.
Para efectos del INS, y con el fin de hacer el proceso de evaluación más ágil se
define como único rubro de evaluación el Precio.
PRECIO (PUNTAJE MAXIMO = 100)
Se asignarán 100 puntos a la oferta de menor precio. Para las restantes ofertas se
utilizará la siguiente fórmula:
P = (P1 / P2) * 100, donde:
P = Puntaje asignado P1 = Menor precio ofertado P2 = Precio de la oferta por evaluar 100 = Puntaje máximo por obtener
72
4.6.2.1.2.3 Condiciones Técnicas
Las condiciones técnica se refieren a todo aquel requerimiento definido por el INS
y que el Oferente si cumple. Para efectos de este rubro, el oferente no debe
presentar ninguna documentación específica
Dentro de las condiciones técnicas definidas para el cartel se encuentran:
• El Oferente deberá indicar si existen observaciones, anomalías o
limitaciones del producto, expresadas por otros clientes al fabricante,
para que sean tomadas en cuenta y valoradas por el Instituto. De lo
contrario, se asumirá que se ofrece un producto garantizado. De
demostrarse situaciones contrarias, el Oferente que resulte Adjudicatario
está en la obligación de realizar las correcciones que sean necesarias y
entregarlas al Instituto sin costo adicional para este.
• Será obligación del eventual adjudicatario, contemplar los costos por la
aportación de los manuales de usuario del software ofrecido. Debe
señalar el medio de presentación, sea archivo digital o impreso y los
costos para cada modalidad. Es potestad del INS decidir la modalidad
por la que optará.
4.6.2.1.2.4 Requisitos técnicos para el oferente
Este rubro se refiere a requerimientos del INS que implican entregar documentación específica que haga constar que se cumple con lo solicitado.
Dentro de los requisitos técnicos para el oferente, derivados del cartel se encuentran:
• El Oferente debe indicar el costo unitario del suministro y otros cargos,
tales como módulos opcionales, descuentos, capacitación, impuestos,
instalación, diseño, entre otros.
73
• El Oferente deberá detallar el nombre del programa producto y la oferta
en plaza, incluidos todos los impuestos y gastos que lo afecten
(indicados por separado).
• El Oferente debe indicar el costo anual por el concepto de
mantenimiento y actualización del producto de tal forma que permita a la
administración contar con el servicio de soporte y renovación del
software.
• Será obligación del Oferente, contemplar los costos por la aportación de
los manuales de usuario del software ofrecido. Debe señalar el medio de
presentación, sea archivo digital o impreso y los costos para cada
modalidad. Es potestad del INS decidir la modalidad por la que optará.
Si omite costos, se entenderá que los mismos están contemplados en el
precio de las licencias.
• El oferente deberá realizar una visita a las Oficinas Centrales del INS,
Departamento de Gestión de Servicios de Tecnología y
Telecomunicaciones para aclarar detalles de la instalación de la
Solución que se cotiza. Esta visita es requisito indispensable para
participar y deberá presentar constancia de dicha visita en su oferta.
4.6.2.1.2.5 Condiciones técnicas para el Adjudicatario
Este rubro se refiere a actividades técnicas que deberán efectuarse como parte
del completamiento de los requerimientos derivados del Cartel.
Para efectos de éste se definen las siguientes condiciones técnicas:
a. Instalación y Configuración: El Adjudicatario deberá designar un recurso
técnico que realice la instalación y configuración del producto, la cual se
hará en horas o días fuera de la jornada ordinaria salvo que las condiciones
permitan realizar dichas tareas durante la jornada ordinaria de la Institución.
b. Inducción: El Adjudicatario debe incluir una inducción que contemple:
74
1. Retroalimentación en el proceso de implementación de la Solución por
un total de 30 horas. Dicha retroalimentación deberá ser brindada por
un especialista en labores de implementación de soluciones del tipo
requerido por el presente Cartel y será brindada al menos a 2 técnicos
designados por el Departamento de Gestión de Servicios de Tecnología
y Telecomunicaciones para tales efectos.
Además, debe indicar las condiciones bajo las cuales se impartirá la
inducción (instalaciones, horario, equipo, lugar, entre otros). La misma
se debe hacer en un plazo no mayor a 15 días naturales posteriores a la
instalación y configuración del software y preferiblemente en las
instalaciones del INS.
• Deberá aportarse el nombre de al menos 2 empresas donde se haya
realizado la implementación de soluciones Single Sign - On.
4.6.2.1.2.6 Requisitos para el Adjudicatario
Los requisitos para el Adjudicatario, se refieren a las obligaciones que deberá
cumplir el oferente que resulte adjudicatario, respecto al objeto del Cartel.
Para efectos de éste, se definen los siguientes requisitos:
A. Catálogos: El Oferente debe presentar catálogos y/o literatura técnica y
manual de usuario, junto con la licencia de software. La literatura debe
aportarse en idioma español o en otro idioma, pero en este caso se
requerirá que presente la traducción bajo responsabilidad del Oferente,
conforme el Artículo Nº 62 del Reglamento a la Ley Contratación
Administrativa.
B. El Adjudicatario deberá proveer un juego de medios de instalación en disco
compacto, éstos deben ser originales y deberán estar acompañados por el
75
Key de activación del producto.
C. Al momento de la entrega, el Adjudicatario debe presentar un certificado de
licenciamiento, en el cual se indique que dichas licencias son propiedad del
INS. Adicionalmente, se debe indicar el esquema de licenciamiento
aplicable a cada uno de los productos (perpetuo/derecho de uso) y la fecha
de fin. Dicho certificado debe ser emitido por el fabricante. Capítulo Dos de
la Contratación
4.6.2.1.3 Capítulo Dos de la Contratación
Dentro del Capítulo Dos del Pliego de condiciones se establecen varias etapas
donde se definen los aspectos formales del Cartel. Los ítems relativos a dichos
aspectos son: Aspectos generales de la evaluación, condiciones generales del
oferente, requisitos que deben cumplir los oferentes, condiciones generales del
Adjudicatario y requisitos que deben cumplir los adjudicatarios.
4.6.2.1.3.1 Aspectos generales de la Evaluación
Los Aspectos generales de la evaluación contemplan todos aquellos puntos
tendientes al proceso específico de evaluación, considerando criterios de
desempate, puntaje mínimo para adjudicar, ofertas alternativas, mejoras y
descuentos.
4.6.2.1.3.2 Condiciones Generales del Oferente
Estas condiciones se refieren a aspectos meramente administrativos sobre
aspectos tales como impuestos, plazos de adjudicación, vigencia de las ofertas y
otros. Para efectos de este cartel, se define un rubro muy importante denominado
Forma de Pago.
Respecto a este punto, el cartel en cuestión establece lo siguiente:
Trámite de 10 días naturales posteriores a la presentación de la factura y recibido
el producto a satisfacción del INS. El Instituto Nacional de Seguros
76
preferentemente realiza la cancelación de bienes y servicios a través del sistema
S.I.N.P.E; por ello el Oferente debe indicar en su oferta el número de cuenta
cliente (SINPE 17 dígitos) y el nombre del banco en el que desea sean
depositados los pagos por medio de transferencia electrónica, con la sola
indicación de esa información se tomará por cierta y válida y el Oferente asumirá
la responsabilidad si la información proporcionada resulta incorrecta.
Otro punto importante, definido en este rubro es la Vigencia del Contrato. Para
efectos de este cartel, el mismo establece:
• Vigencia del contrato: Será por un año, las partes por mutuo acuerdo
podrán renovar el contrato por períodos iguales, hasta un máximo de tres
(3) renovaciones. El acuerdo de renovación deberá ser suscrito
formalmente por las partes con al menos un mes de antelación a la fecha
de vencimiento de la anualidad respectiva.
4.6.2.1.3.3 Requisitos que deben cumplir los oferentes
Este rubro define aspectos que deben cumplir los oferentes respecto a la
presentación de la oferta, plazos de entrega, declaraciones sobre estado de sus
impuestos, o si está al día con la Caja Costarricense de Seguro Social y cualquier
otra documentación que indique que los documentos tendientes a su organización
se encuentran al día.
4.6.2.1.3.4 Condiciones Generales del Adjudicatario
Las condiciones generales establecen algunas consideraciones sobre impuestos
de la renta y responsabilidades patronales del adjudicatario. Para efectos de este
cartel, se incluye en este rubro un punto muy importante denominado Multas
Todo cartel debe contemplar dentro de éste ítem específico, la fórmula
correspondiente al monto que le será castigado al Adjudicatario por
incumplimiento de los requerimientos establecidos como de cumplimiento
77
obligatorio. Debe especificarse de previo en el cartel, cuales serán tales
requerimientos.
El cartel en cuestión define para su ítem de multas, lo siguiente:
• Por cada día natural de atraso en la entrega del servicio, se cobrará un
0.1%, hasta un máximo del 25% del total atrasado. (Artículo Nº 48
RLCA).
4.6.2.1.3.5 Requisitos que deben cumplir los adjudicatarios
Finalmente, el cartel especifica algunos requisitos que deben cumplir los
adjudicatarios al momento de participar de la Licitación, tales como la Garantía de
cumplimiento.
Dentro de este rubro, se define otro punto importante del Cartel denominado Inicio
del Contrato, el mismo especifica el día o días, máximo para el inicio formal del
Contrato.
78
4.7 Seguimiento y Control
Para las labores de seguimiento, supervisión y control del Proyecto, se realizaron las siguientes actividades:
1. Estatus Semanal: Vía correo, le fue remitido a la Jefatura del Departamento
de Gestión de Servicios de Tecnología y Telecomunicaciones,
semanalmente, un estatus del proyecto.
2. Reuniones:
a. Jefatura del Departamento de Gestión de Servicios de
Tecnología y Telecomunicaciones: Quincenalmente, se realizaron
sesiones de trabajo de 30 minutos con dicha Jefatura donde se
entregaron los avances quincenales con información documental de
cada entregable.
b. Grupo de apoyo del Proyecto: Se realizaron 3 reuniones con el
grupo de apoyo. Una reunión durante la etapa de definición de
requerimientos de la Organización, una reunión para analizar de
forma general, la documentación relativa al análisis de Mercado.
Finalmente, una reunión para aportar recursos documentales y
recomendaciones para la formulación del Cartel.
c. Proveedores: Se realizaron 3 reuniones con los Proveedores de los
productos evaluados.
i. GBM: Se realizó una reunión telefónica en modalidad
conferencia para aclarar aspectos documentales del producto
ofrecido.
ii. CR Conectividad: Se realizó una reunión para definir el tipo de
documentación requerida por el INS y exponer generalidades
del producto ofrecido. Una segunda reunión sirvió para
analizar la propuesta de servicios dada por la empresa y
mostrar una demo del producto.
79
4.7.1 Herramientas de Seguimiento y Control del Proyecto
A continuación se detallan las herramientas utilizadas durante todo el proyecto como apoyo para el Seguimiento, supervisión y control del mismo.
Herramienta Como servirá durante el Control WBS A partir del WBS, se controlará la ejecución de cada una
de las actividades
Cronograma del Proyecto Mediante el cronograma se controlarán los tiempos para el completamiento de las actividades, el % de avance de cada uno y los cambios en los plazos a partir de la línea base (en caso de presentarse)
Matriz de Roles y Funciones Mediante dicha matriz, se definen para cada actividad, los responsables de su ejecución y el rol que desempeñan dentro del proyecto. De esta forma, se tendrá bien delimitado el responsable de desarrollar cada actividad.
Matriz de Comunicación Permitirá definir la distribución de la información del proyecto entre los involucrados del mismo. Esto con el fin de establecer una comunicación fluida durante toda la ejecución.
Estatus Semanal Información general del estado del proyecto en cuanto a atrasos, cambios, mejoras, observaciones y otros
Informe quincenal Cada quince días se presenta a la Jefatura del Departamento de Control y Gestión de Tecnología y Telecomunicaciones un avance del entregable en el que se está trabajando para realizar una revisión general del contenido de la documentación.
Control de Cambios De requerirse cambios en los avances presentados quincenalmente, la Jefatura Patrocinante los expondrá y serán documentados en la plantilla de control de cambios
Minutas Se utilizarán las minutas para documentar, antecedentes de cada reunión y acuerdos tomados entre las partes
80
4.8 Lecciones Aprendidas
Durante el desarrollo del proyecto se presentaron una serie de situaciones que
afectaron visiblemente los tiempos de entrega para cada producto.
Aspectos tales como retrasos en la entrega de documentación y recursos
destinados a tareas prioritarias retrasaron el completamiento de algunas tareas
que de igual forma, redefinieron la fecha de entrega del Proyecto como tal.
Dichos atrasos fueron solventados con la colaboración del equipo de trabajo,
logrando completar el 100% de las tareas.
En el anexo 7.12 se presentan las lecciones aprendidas derivadas de la ejecución
del Proyecto.
4.9 Cierre del Proyecto
El Cierre del Proyecto contempla únicamente el Cierre Administrativo el cual
incluye los siguientes documentos:
1. Informe Final del Proyecto.
2. Acta de Aceptación de Entregables.
3. Acta de Comunicación de Cierre.
En los Anexo 7.9 y 7.11 se presentan la Plantillas requeridas para proceder con la
formalización de aceptación de entregables y el acta de comunicación de Cierre
del Proyecto.
La Plantilla correspondiente al Acta de cierre administrativo del Proyecto, se
muestra en el anexo 8.10.
81
5 Conclusiones
Para el desarrollo del Plan de Proyecto como para la Implementación de una
solución tipo Single Sign On en el INS, se realizó una investigación de las 9 áreas
de conocimiento, así como los procesos de la Administración de Proyectos,
establecidos por el PMI.
De dicha investigación se aplicaron aquellas áreas que en particular, fueron
esenciales a lo largo del proyecto. Sin embargo, áreas tan importantes como
Calidad y Riesgos debieron ser excluidas por requerir recursos adicionales para su
implementación.
Considerando el alcance del Proyecto, se detallan a continuación los objetivos
alcanzados a través de la Metodología de Administración de proyectos utilizada.
1. Se desarrolló un Plan de Gestión del alcance, delimitando los entregables
del proyecto, las mediciones, supuestos, exclusiones y restricciones del
mismo. Este Plan, permitió tener una visión clara a todos los involucrados
del proyecto, respecto a los productos a entregar.
2. Mediante el desarrollo del Plan de Gestión del Tiempo, se establecieron los
plazos para la ejecución de las actividades que conformaron cada uno de
los entregables. Estos plazos fueron debidamente documentados y
controlados lo que permitió definir los atrasos y las medidas para enfrentar
éstos.
3. Mediante el desarrollo del Plan de Recursos Humanos, se definió el equipo
de trabajo, los roles y funciones de cada miembro, así como las
responsabilidades y obligaciones de los involucrados en el desarrollo de
cada entregable.
4. Mediante el desarrollo del Plan de Comunicaciones, se propició la entrega
de avances, notificación de anomalías, correcciones y otros, utilizando
mecanismos o herramientas específicos para su documentación y
divulgación. Esto permitió informar a los responsables en todos los niveles,
respecto al desarrollo del Proyecto.
82
5. Se desarrolló el Plan de Gestión de las adquisiciones considerando en éste,
las etapas de Identificación de la necesidad, el presupuesto y la
Planificación de la contratación. Mediante éste, se detalló la necesidad de
contar con una solución Single Sign On en el INS, se presupuestó en el
PAO 2009 la misma y se desarrolló el Pliego de condiciones, objeto de uno
de los entregables del Proyecto. Adicionalmente, con el apoyo de la
investigación de mercado, y la solicitud de cotizaciones a los potenciales
proveedores, se desarrolló un estudio costo – beneficio que complementara
el Cartel y que de igual manera, forma parte de los entregables del
Proyecto.
6. Se desarrollaron una serie de Plantillas que permitieron dar seguimiento y
controlar todo el proyecto, documentando cambios, reuniones, informes
semanales y otros.
7. Como parte indispensable de todo proyecto, se documentaron las lecciones
aprendidas del mismo. Si bien, dichas lecciones, hicieron ver varias
deficiencias durante las etapas de desarrollo del proyecto, las mismas
permitieron establecer las debilidades y fortalezas del proceso, que servirán
de soporte para la mejora continua en posteriores proyectos.
8. Se generó un cierre administrativo del proyecto, incluyendo dentro de éste,
la documentación correspondiente a la entrega formal de los entregables
que conformaron el proyecto, así como la comunicación formal de cierre de
éste.
El principal beneficio del desarrollo de este proyecto fue la generación de una
Metodología de Administración de Proyectos para el Departamento de Gestión de
Servicios de Tecnología y telecomunicaciones, que deberá ser depurada y
completada con las áreas que no fueron incluidas en éste proyecto.
83
6 Recomendaciones
La selección de una solución Single Sign On, cuya implementación traerá
múltiples beneficios a la Organización, debe basarse no solo en aspectos
económicos sino también en otras consideraciones como, interacción con
múltiples plataformas, fácil y rápida implementación del producto, esquema de
seguridad robusto, esquema de autenticación entre otros. De igual forma, a nivel
administrativo, la amplia trayectoria del proveedor de la solución es un aspecto
sumamente importante, además del soporte que se brinde al producto, garantía
sobre éste, etc.
Considerando éstos aspectos, se hacen las siguientes recomendaciones, cuya
aplicación servirá como apoyo para el éxito de la respectiva implementación.
1. Debe desarrollarse un Plan de Calidad que sirva para asegurar que el
proyecto satisface completamente las necesidades para las cuales se
gestó. Para este plan, se recomienda utilizar como apoyo un diagrama de
Causa – Efecto y una lista de verificación que permita identificar las
actividades necesarias para satisfacer los requerimientos de calidad
establecidos para el proyecto.
2. Debe desarrollarse un Plan de Riesgos donde se documenten los riesgos
derivados de una eventual implementación de la solución, de forma que los
mismos puedan ser cuantificados, estableciendo las amenazas que
deberán controlarse respecto a la posible activación de alguno de ellos.
3. Durante la etapa de evaluación de Ofertas, será de suma utilidad la matriz
de evaluación de alternativas, como apoyo para la valoración de cada
producto. Es importante que en esta matriz, se listen criterios cuantitativos
de selección respecto al bien que se desea adquirir y que fundamenten y
faciliten la correspondiente elección.
84
4. Durante la ejecución del contrato, deberán definirse las actividades
necesarias que permitan controlar apropiadamente el mismo, realizando
reuniones de seguimiento y documentando el proceso desde su inicio
hasta el cierre del contrato respectivo.
85
7 BIBLIOGRAFÍA
Instituto Nacional de Seguros, C.R. Historia del Instituto Nacional de Seguros. Consultado el 3 de Julio del 2007. Disponible en http://portal.ins-cr.com/Institucional/Historia/.
TELEINS. 2007. Historia del INS. San José, C.R. Consultado el 4 de Julio del
2007. Disponible en Base de Datos RECORE – Intranet INS. Dpto. Comunicación Institucional. 2007. Los Seguros del INS. San José, C.R.
Consultado el 4 de Julio del 2007. Disponible en Base de Datos RECORE – Intranet INS.
Dirección de Informática. Manual General de Organización y Funciones, 2005.
Disponible en Base de Datos RECORE – Intranet INS. SENN, J. 1992. Análisis y Diseño de Sistemas de Información. Segunda edición.
México. McGraw Hill Interamericana. México. Davis, G., Olson M, 1987. Sistemas de Información Gerencial. Segunda Edición,
Colombia. Editorial McGraw-Hill Latinoamericana. Colombia. P.M.I, (Project Management Institute). 2004. Guía de los fundamentos de la
Dirección de Proyectos. PMBOK Guide, Tercera edición 2004. Newton Square, Pennsylvania, E.U.A.
GIDO, J; CLEMENTS, J. 2003. Administración exitosa de proyectos. Segunda
edición. México. Internacional Thomson Editores S.A. CHAMOUN, Y. 2002. Administración Profesional de Proyectos. Una guía práctica
para programar el éxito de sus proyectos. McGraw Hill Interamericana. México.
EYSSAUTIER, M. 2002. Metodología de investigación. Desarrollo de la
inteligencia. Cuarta Edición. Internacional Thomson Editores. México. JURADO, Y. 2002. Técnicas de Investigación documental. Manual para la
elaboración de tesis, monografías, ensayos e informes académicos. Internacional Thomson Editores. México.
Muñoz, C. 1998. Cómo elaborar y asesorar una investigación de Tesis. Primera
Edición, México. Prentice Hall Hispanoamericana. México. Universidad Autónoma de Ciudad Juárez, 2006. Procedimiento para mantener el equipo de cómputo. Consultado el 4 de Julio del 2007. Disponible en http://www.uacj.mx/transparencia/Acervo/Documentos.
86
Canal Hanoi, 2007. Definición de Software. Consultado el 6 de Julio del 2007. Disponible en http://canalhanoi.iespana.es/informatica/software.htm
Enciclopedia Encarta Digital, 2006. Conceptos informáticos. Universidad Galileo, Guatemala. 2007, Interfaces de usuario. Consultado el 6 de Julio del 2007. Disponible en http://www.Galileo.edu/wp/display/2453/2462/wimpy Entrebits. 2006. Plataforma tecnológica. Consultado el 6 de Julio del 2007. Disponible en http://webferret.search.com/click?wf,diccionario+entrebits.com%2F,aol Tutoriales, 2007. Manejador de Base de Datos. Consultado el 6 de Julio del 2007. Disponible en http://sistemas.itlp.edu.mx/tutoriales/basedat1/tema1_9.htm Ciclo de Vida de Bases de Datos, 2003. Etapas del ciclo de vida de una aplicación de Bases de Datos. Consultada el 8 de Julio del 2007. Disponible en http://www3.uji.es/mmarques/f47/apun/node67.html Diseño y arquitectura de información, 2007. Arquitectura de información. Consultada el 8 de Julio del 2007. Disponible en http://www.tramullas.com/ai Redsis, 2007. Servidores IBM iSeries. Consultado el 10 de Julio del 2007. Disponible en http://www.redsis.com/index.php?option=displaypage&Itemid=96&op=page&SubMenu=. Expertos en firma electrónica, 2007. Single Sign – On. Consultado el 11 de Julio del 2007. Disponible en http://www.ipsca.com/es/Solutions/SSO.asp
Consideraciones para implementar una arquitectura Single Sign On, 2002. Consultado el Viernes 11 de abril del 2008. Disponible en www.criptored.upm.es/guiateoria/gt_m142j.htm
87
8 ANEXOS 8.1 PERFIL DE PROYECTO
Cuadro No 8 Información principal y autorización del Proyecto Información principal y autorización del proyecto
Fecha:
13/02/2008
Nombre del proyecto
Plan de Proyecto para la Implementación de una solución tipo Single Sign-On en el Instituto Nacional de Seguros para las plataformas OS/400, WINDOWS Y AIX
Áreas de conocimiento
Gestión del Alcance, Gestión del Tiempo o, Gestión de Costos, Gestión de las Comunicaciones, Gestión de Adquisiciones,
Área de Aplicación
Administración de Proyectos
Fecha de Inicio del proyecto:
13/02/2008
Fecha tentativa de finalización del proyecto:
13/05/2008 Objetivos del proyecto:
General:
Diseñar un Plan de Proyecto para la implementación de una solución tipo Single Sign-On en el Instituto Nacional de Seguros para las plataformas OS/400, WINDOWS Y AIX.
Específicos:
• Desarrollar un análisis de mercado que sirva como marco de referencia para la evaluación de soluciones de este tipo, existentes en el mercado nacional.
• Definir los requerimientos del INS para la eventual implementación de una solución tipo Single Sign - On.
• Desarrollar un estudio de factibilidad a partir del análisis de mercado, que justifique la necesidad de implementar la solución en el INS.
• Confeccionar un Cartel con los servicios requeridos para la adquisición e implementación de la Solución tipo single Sign – On.
• Desarrollar el Proyecto dentro de una metodología de Administración de Proyectos que sirva como guía para durante su ejecución.
Descripción del producto:
El presente proyecto contempla a partir de la identificación de los requerimientos del INS, la adquisición e implementación de una Solución Tipo Single Sign – On para la plataformas OS/400, WINDOWS Y AIX.
Este Plan incluirá la siguiente información:
1. Identificación de Requerimientos del INS para la implantación de una solución tipo Single Sign - On
88
Información principal y autorización del proyecto 2. Análisis de mercado de soluciones Tipo Single Sign -On
3. Estudio de factibilidad Técnica
4. Cartel para la adquisición de licencias Single Sign - On
Necesidad del proyecto:
El Instituto Nacional de Seguros es una empresa que actualmente maneja una diversidad de aplicaciones para el manejo y administración de los seguros en las plataformas OS/400, UNIX y WINDOWS, situación que implica el manejo de tantas claves como sistemas se deba manipular. Justificación del impacto:
La implementación de una solución tipo Single Sign – On en el INS permitirá:
• Reducir significativamente los costos en los que actualmente incurre la organización por concepto de reactivación de claves.
• Agilizar considerablemente los tiempos de acceso a varias aplicaciones.
• Aprovechar el recurso humano técnico que actualmente se destina en más de un 50% a la labor de administración de claves de acceso, en otros proyectos definidos por el Departamento de Soporte Técnico.
• Mejorar la atención al cliente.
• Reducir considerablemente los problemas de seguridad existentes actualmente debido a la forma de administrar las claves por parte del usuario final.
Restricciones:
• No se desarrollarán las etapas de evaluación de las soluciones identificadas.
• No se confeccionará el Cartel con los servicios requeridos por la Institución para la contratación del proveedor
• Las áreas de conocimiento Gestión de Riesgos y Gestión de costos no serán desarrolladas.
• Limitaciones de tiempo por parte del recurso humano interno, a cargo de desarrollar el proyecto.
Identificación de grupos de clientes:
Clientes directos:
• Usuarios Finales de los departamentos de Producción.
• Funcionarios de la Dirección de Informática: Departamento de Desarrollo de Sistemas de Información, Departamento de Control y Gestión de TI, Departamento de Mantenimiento de Sistemas, Departamento de Gestión de Servicios Tecnológicos y Telecomunicaciones, Departamento de Administración de sistemas.
• Personal de la Unidad Administrativa de la Dirección de Informática.
Clientes indirectos:
89
Información principal y autorización del proyecto • Proveedores de la herramienta Single Sign - On
Aprobado por:
Firma:
Cuadro No 9 Declaración del Alcance del Proyecto Declaración del Alcance del Proyecto
Proyecto:
Plan de Proyecto para la Implementación de una solución tipo Single Sign-On en el Instituto Nacional de Seguros para las plataformas OS/400, UNIX y WINDOWS. Fecha:13/02/2008 Planteo del problema (necesidad, oportunidad) y justificación del proyecto:
El Instituto Nacional de Seguros es una organización cuyo principal negocio es la venta de Seguros. Para administrar los distintos productos de su cartera existen varias aplicaciones distribuidas en diversas Plataformas entre las que se destacan OS/400, UNIX y WINDOWS.
Dado lo anterior, el INS se enfrenta actualmente a varios problemas entre los que se destacan :
1. Incurrir en altos costos por concepto de reactivación de claves de usuario.
2. Recurso Humano dedicado en mas de un 50% a labores de administración de claves
3. Usuarios finales ejerciendo una inadecuada administración de claves desde el punto de vista de seguridad
Con el fin de minimizar la problemática en cuanto al manejo y administración de passwords asignados a usuarios, se requiere implementar una solución tipo Single Sign – On para las plataformas OS/400, UNIX y WINDOWS permitiendo a través de ello:
1. Reducir significativamente los costos en los que actualmente incurre la organización por concepto de reactivación de claves.
2. Agilizar considerablemente los tiempos de acceso a varias aplicaciones.
3. Aprovechar el recurso humano técnico en proyectos de mayor envergadura para la Institución.
4. Mejorar la atención al cliente.
5. Reducir considerablemente los problemas de seguridad existentes actualmente en relación a la forma de administración de claves por parte del usuario final.
Objetivo(s) del proyecto:
General:
Diseñar un Plan de Proyecto para la implementación de una solución tipo Single Sign-On en el Instituto
90
Declaración del Alcance del Proyecto Nacional de Seguros para las plataformas OS/400, UNIX y WINDOWS.
Específicos:
• Desarrollar un análisis de mercado que sirva como marco de referencia para la evaluación de soluciones de este tipo, existentes en el mercado nacional.
• Identificar los requerimientos del INS para la eventual implementación de una solución tipo Single Sign - On.
• Desarrollar un estudio de factibilidad a partir del análisis de mercado, que justifique la necesidad de implementar la solución en el INS.
• Confeccionar un Cartel con los servicios requeridos para la adquisición de licencias Single Sign – On
• Desarrollar el Proyecto dentro de una metodología de Administración de Proyectos que sirva como guía para durante su ejecución.
Producto principal del proyecto: El presente proyecto contempla a partir de un análisis de mercado y la identificación de los requerimientos del INS, la confección de un Cartel para adquirir una solución Tipo Single Sign – On para la plataformas OS/400, UNIX y WINDOWS. Entregables del proyecto:
1. Análisis de Requerimientos del INS para la implantación de una solución tipo Single Sign - On
2. Análisis de mercado de soluciones Tipo Single Sign -On
3. Estudio de factibilidad Técnica
4. Cartel para la adquisición e implementación de la solución.
91
8.2
W
BS
PR
OP
UE
ST
O
F
igu
ra N
o 1
4 W
BS
de
l P
roye
cto
92
8.3
C
RO
NO
GR
AM
A D
E P
RO
YE
CT
O
93
94
Fig
ura
No
15
Cro
no
gra
ma
del
Pro
yect
o
95
8.4 Matriz de Comunicaciones
Cuadro No 10 Matriz de Comunicaciones del Proyecto
96
8.5 Estatus Semanal
Estatus Semanal
Proyecto:
Patrocinador:
Gerente de Proyecto:
Fecha: 99/99/9999
Actividades Realizadas:
1. 2. 3. 4. 5.
Actividades Pendientes:
1. 2. 3. 4. 5.
Control del Tiempo
WBS (Entregable):
Con Actividad Fecha Inicio
Fecha Fin
% Concluido
Observaciones
Figura No 16 Plantilla de Estatus Semanal
97
8.6 Minutas
MINUTA DE REUNION
REUNION Nº
Fecha REF.
PROYECTO Lugar
OBJETO
Participantes:
Nombre: Cargo: Empresa:
ACUERDOS
Nº Responsabl
e
Fecha DESCRIPCION
Figura No 17 Plantilla de Minuta de reunión
98
8.7 Entradas de Reunión
Figura No 18 Plantilla de Entrada de Reunión
99
8.8 Solicitud de Cambio
Figura No 19 Plantilla de Solicitud de Cambio
Solicitud de Cambio
Empresa:
Proyecto:
No de Solicitud: GSTT-XXXX Fecha: 99/99/9999
Persona que solicita:
Cargo:
Concepto:
Descripción:
Razón de la Solicitud:
Tiempo que requerirá el cambio:
Impacto en el proyecto: Alto Medio Bajo
Tipo de Afectación:
Recursos Materiales
Recurso Humano
Tiempo
Otros: _______________________________________________________ Nueva Fecha de Terminación: 99/99/9999 Estatus:
Visto Bueno Patrocinador:
_______________________________
Responsable:
_______________________________
Cómo se resolverá:
100
8.9 Aprobación de Criterios de Aceptación
Aprobación de Criterios de aceptación
Plantilla GSTT-XXXX-XX
Nombre del Proyecto:
Dirección Gestora:
Fecha de Entrega:
Dependencias Involucradas: Tipo de Proyecto:
_________ Tecnológico _________ Administrativo _________ Comercial _________ Construcción _________ Proyección Social _________ Otro
Nombre de Entregable:
Listado de Criterios : Cumple No cumple
1.
2.
3.
4.
Nombre y Firma Nombre y Firma
______________________________ ______________________________
Lcda. Yorleny Retana M Lcda. Alexandra Chinchilla A.
Gerente de Proyecto Patrocinadora del Proyecto
Figura No 20 Aprobación de Criterios de Aceptación
101
8.10 Acta de Aceptación de entregables
Acta de Aceptación de Entregables Plantilla GSTT-XXXX-XX
Nombre del Proyecto
Dirección Gestora:
Fecha de Entrega:
Dependencias Involucradas: Tipo de Proyecto:
_________ Tecnológico _________ Administrativo _________ Comercial _________ Construcción _________ Proyección Social _________ Otro
Documentos Adjuntos:
1. Detalle del Entregable
2. Aprobación de Criterios de Aceptación
3. Informe Final de entregables
Nombre y Firma Nombre y Firma
______________________________ ______________________________
Lcda. Yorleny Retana M Lcda. Alexandra Chinchilla A.
Gerente de Proyecto Patrocinadora del Proyecto
Figura No 21 Plantilla de Acta de aceptación de entregables
102
8.11 Acta de Cierre Administrativo
Acta de Cierre Administrativo Plantilla GSTT-XXXX-XX
Nombre del Proyecto
Dirección Gestora:
Fecha de Cierre:
Dependencias Involucradas: Tipo de Proyecto:
_________ Tecnológico _________ Administrativo _________ Comercial _________ Construcción _________ Proyección Social _________ Otro
Documentos Adjuntos:
1. Informe Final del Proyecto
2. Acta de Aceptación de los Entregables (Fechas y oficios respectivos)
3. Acta de Comunicación de Cierre
4. Fecha de Cierre de Proyecto
5. Firmas de Miembros del Equipo
Nombre y Firma Nombre y Firma
______________________________ ______________________________
Lcda. Yorleny Retana M Lcda. Alexandra Chinchilla A.
Gerente de Proyecto Patrocinadora del Proyecto
Figura No 22 Plantilla de Acta de Cierre Administrativo del Proyecto
103
8.12 Acta de Comunicación de Cierre
Acta de Comunicación de Cierre Plantilla GSTT-XXXX-XX
Nombre del Proyecto
Dirección Gestora:
Fecha de comunicación:
Dependencias Involucradas: Tipo de Proyecto:
_________ Tecnológico _________ Administrativo _________ Comercial _________ Construcción _________ Proyección Social _________ Otro
Documentos Adjuntos:
1. Oficio de comunicación de cierre respectivo
Nombre y Firma Nombre y Firma
______________________________ ______________________________
Lcda. Yorleny Retana M Lcda. Alexandra Chinchilla A.
Gerente de Proyecto Patrocinadora del Proyecto
Figura No 23 Plantilla de Acta de comunicación de Cierre
104
8.13 Lecciones Aprendidas
Etapa de Inicio del Proyecto
1. A pesar de tenerse clara la necesidad de contar con una solución de
autenticación única, no se tuvo claro el tipo de usuarios que la utilizaría
considerando que existen varios tipos de usuarios, a saber:
a. Usuario de las Plataformas de Servicios (Sede Central, Sedes con
mayor cantidad de sistemas para consultar). Existen algunas Sedes
donde el acceso a múltiples plataformas no se da. En el caso de
punto de venta, los accesos están limitados a uno o dos sistemas,
además de la autenticación de Windows y Correo Electrónico cuando
se requiere.
b. Usuarios de Áreas Técnicas: Informática (En este caso, los
funcionarios pueden acceder a varias plataformas en función de las
labores que les competen, además de otras aplicaciones de
utilización frecuente).
c. Usuarios de Áreas de Salud: INS-Salud y Dispensarios Médicos. En
este caso, el Área de Incapacidades Temporales, adscrita al
Departamento de Riesgos del Trabajo, únicamente debe acceder al
módulo de su competencia en el Sistema de Riesgos del Trabajo.
Los Dispensarios y otras áreas de INS-Salud, únicamente acceden al
Sistema Integrado Medico Administrativo (SIMA)
Lección Aprendida
Cuando se define una necesidad que involucra el accionar de muchos
usuarios, debe establecerse el alcance exacto, respecto a quienes serán los
beneficiarios directos del producto que pretende el proyecto.
Esto debe identificarse conjuntamente con la necesidad y plasmarse en el
alcance.
2. La cantidad de usuarios por Sistema no es del todo exacta, ya que un
funcionario puede tener asignado un usuario en 5 sistemas diferentes, todos
pueden estar activos, pero no necesariamente ingresa a todos ellos. Esto
105
se da cuando un funcionario es ascendido o trasladado por directrices
internas. En algunas ocasiones, no se notifica el cambio por lo que el
usuario permanece activo. A pesar de esto, los Sistemas del INS, bloquean
o desactivan un usuario, posterior a un mes de inactividad.
Lección Aprendida
Siempre que se pueda, debe contarse con información precisa que permita
establecer los costos reales en que se incurrirá al adquirir un bien o Servicio.
En el caso específico de este proyecto, las licencias necesarias para la etapa
de Implementación de la solución. En caso de que las licencias sean
insuficientes, deberán definirse prioridades según la necesidad para la cual fue
establecido el proyecto.
Etapa de Planificación del Proyecto
1. Metodología de Administración de Proyectos: El Departamento de Gestión
de Tecnología y Telecomunicaciones no cuenta con una Metodología de
Administración de Proyectos por lo que se tuvo que utilizar, en algunas
etapas, la metodología utilizada por el Departamento de Desarrollo de
sistemas y en otras, a través de apoyo bibliográfico.
Lección Aprendida
Cuando se va a iniciar un Proyecto, debe utilizarse una metodología de
Administración de Proyectos consistente y apegada a los requerimientos que el
proyecto demanda.
2. Cronograma de Actividades: Los tiempos establecidos en varias de las
actividades definidas en el cronograma debieron variarse (ampliarse en su
mayoría), esto por cuanto los Proveedores tardaron mucho en enviar
información solicitada, o en su defecto, enviaron información incompleta o
inconsistente.
106
Lección Aprendida
Debe acordarse con los Proveedores o entidades externas de quienes se
requiere información, una fecha máxima para la entrega de la misma. De ser
posible, debe asegurarse que dichas entidades están claras en el tipo de
información que se requiere para evitar atrasos por inconsistencia de la
documentación. Además, debe lograrse un compromiso real por parte de los
proveedores considerando que dicha información es relevante para la
continuidad y éxito del proyecto.
3. Recurso Humano del Proyecto: Debido a que el grupo de apoyo
seleccionado para colaborar en la entrega de información trascendental del
proyecto, no estaba asignado formalmente al mismo como tal, su
colaboración no siempre fue recibida a tiempo dadas las prioridades de
cada uno en sus funciones diarias.
Lección Aprendida
Cuando parte del contenido documental de un proyecto depende de Recurso
Humano no asignado a éste, debe solicitarse la colaboración de los superiores
de dichos recursos, considerando la posibilidad de apoyar al menos un día
completo la gestión. Debe aclararse a las Áreas colaboradoras, la importancia
del proyecto y de su colaboración para lograr el éxito de éste.
4. Planificación de las Adquisiciones: Debido a que el proyecto se centró en la
identificación y análisis de soluciones Tipo Single Sign On, brindadas por
proveedores en el país, un problema presentado durante la ejecución del
proyecto fue que no se contó con muchos proveedores de tal producto.
Aunado a ello, tampoco se tuvo evidencia de empresas que tuvieran
instalada una solución de este tipo. Esta situación afectó la evaluación de
las soluciones por no contar con parámetros tangibles para medir la
eficiencia del producto en sí.
107
Lección Aprendida
Es importante considerar, cuando se evalúa la adquisición de un producto, que
éste sea ofrecido por al menos cuatro proveedores de renombre y que el
mismo haya sido implementado por otras empresas. Esto permitirá contar con
parámetros de evaluación reales que coadyuven en el análisis e identificación
del producto que más se ajusta a las necesidades de la organización que
pretende adquirirlo.
Etapa de Ejecución
1. El proyecto en cuestión requería un recurso humano con suficiente
experiencia técnica en el análisis y evaluación de soluciones Tipo Single
Sign –On. No obstante, dicho recurso no contaba con el conocimiento
necesario en esta materia. A pesar de lo anterior, se pudo contar con un
grupo de apoyo experimentado quien aportó conocimiento al proyecto.
Lección aprendida
Cuando se identifica una necesidad y el proyecto es aprobado, debe
considerarse como imprescindible, contar con el recurso humano idóneo para
realizar las actividades propias del mismo. Si el proyecto contempla varias
etapas que requieran diferentes capacidades y experiencia, debe, mediante la
matriz de roles y funciones establecerse claramente, las actividades que
competan a cada recurso, según su experiencia y conocimiento.
2. La documentación entregada por los proveedores, se hizo insuficiente o se
presentaron cambios en la documentación del producto que generaron
confusión durante su análisis (alianza con otras empresas o documentación
obsoleta).
Lección aprendida
Debe solicitarse a los proveedores la información más actualizada y la misma
debe ser entregada por estos, aclarando cualquier punto que se pueda prestar
para confusión.
108
Cuando se utilice Internet como medio para la adquisición de información; de
igual manera debe contactarse al proveedor para identificar si la misma está
acorde a la última versión del producto o la misma está en proceso de cambio.
3. Durante el proyecto, se dio falta de comunicación, entre los proveedores y
el gerente de proyecto.
Lección aprendida
Debe aclararse a los proveedores que su participación es relevante en todas
las etapas del proyecto.
Etapa de Seguimiento y Control
1. Debido a la atención de actividades prioritarias no relacionadas con el
proyecto, no fue posible presentar todos los avances semanales. Esta
situación provocó que algunos de los cambios solicitados no fueran
ampliamente revisados.
Lección aprendida
Considerando la importancia e impacto, que una solicitud de cambio hace en
un proyecto, éste debe ser bien evaluado, considerando todos los aspectos que
afecten la entrega del producto en el tiempo establecido.
De manera general, en los proyectos, las solicitudes de cambio que impacten el
presupuesto, los recursos humanos o materiales, el alcance del proyecto o el
plazo de entrega, deben ser evaluadas y aprobadas, tanto por el patrocinador
como por el equipo de proyecto.
2. Durante algunas etapas del proyecto, el seguimiento fue escaso debido a la
limitación de tiempo para entregar o revisar los avances.
109
Lección aprendida
Considerando la importancia del proyecto que se está realizando, los avances
deben ser entregados y revisados puntualmente. Deben hacerse todas las
observaciones de mérito y revisar los cambios solicitados.
Etapa de Cierre del proyecto
1. Al momento de hacer entrega de cada entregable, el Patrocinador consideró
algunos cambios adicionales.
Lección aprendida
Esto se da porque en la etapa de Seguimiento y Control no se realizan todas
las observaciones pertinentes.
Es importante, que los documentos que se generen en dicha etapa sean
precisos y se revisen detenidamente. Una vez aceptados, deben ser
aprobados formalmente, mediante correo o minutas, conjuntamente con el acta
de aceptación correspondiente.
110
9 ENTREGABLES 9.1 Portada
DEPARTAMENTO DE GESTION DE TECNOLOGIA Y TELECOMUNICACIONES
GESTION DE ADQUISICIÓN DE UNA SOLUCION DE TIPO SINGLE SIGN ON PARA LAS PLATAFORMAS AIX, OS/400 Y WINDOWS
RESPONSABLES:
LCDA. YORLENY RETANA M.: ______________________________ GERENTE DE PROYECTO
LCDA. ALEXANDRA CHINCHILLA A.: ___________________________ PATROCINADORA DEL PROYECTO
FECHA: 99/99/9999
111
9.2 Investigación de mercado Soluciones Tipo Single Sign – On 9.2.1 Objetivo principal
El principal objetivo de esta investigación de mercado, es identificar potenciales
proveedores de Soluciones tipo Single Sign On, existentes en el mercado
nacional.
Se realizará un análisis de soluciones, considerando las características del
producto, ventajas, Beneficios, esquema de implementación, esquema de Alta
disponibilidad y esquema de seguridad.
9.2.2 Soluciones Tipo Single Sign - On existentes en el Mercado Nacional
Para efectos de esta investigación, se consideraron las Soluciones ofrecidas
por dos proveedores de amplia trayectoria en el país. A pesar de que existen
soluciones similares, ofrecidas por otros proveedores, las mismas no cumplen
en su totalidad los requerimientos necesarios para ser considerandos dentro
del estudio.
A continuación se describen los productos considerados para el análisis
respectivo.
9.2.2.1 Empresa GBM de Costa Rica
La empresa GBM cuenta dentro de sus productos con una solución tipo Single
Sign On la cual se describe de la siguiente manera:
9.2.2.1.1 Producto: IBM Tivoli Access Manager for Enterprise Single Sign - On
V 5.0 (TAM E-SSO)
9.2.2.1.1.1 Generalidades del Producto
IBM Tivoli Access Manager es una solución empresarial Single Sign – On,
basada en la tecnología Passlogix la cual ha sido proveedora desde hace más
de 10 años de soluciones de firma única. Ésta, permite un único inicio de
sesión para todas sus aplicaciones, sin esfuerzos de implementación largos y
complejos.
112
La arquitectura de TAM ESSO es de dos capas. Las credenciales pueden ser
almacenadas en una gran cantidad de repositorios, incluyendo directorios
LDAP, bases de datos o sistemas de archivos.
9.2.2.1.1.2 Funcionalidades
Dentro de las principales funcionalidades del producto se encuentran:
1. Actúa como una parte integral del Portafolio IBM de administración de
seguridad de Identidades para Microsoft Windows, Web, Java, UNIX
(Telnet), desarrollos hechos a la medida, y aplicaciones mainframe.
2. Entrega una solución empresarial de acceso único funcionando con
tecnología Passlogix la cual reconoce y responde a inicios de sesión de casi
cualquier sistema o aplicación.
3. Trabaja en congruencia tanto con IBM Tivoli Access Manager para e-
business como IBM Tivoli Identity Manager para proveer una robusta
solución que direcciona los diferentes accesos en toda la organización.
4. Soporta diferentes tipos de autenticación de clientes, desde las contraseñas
a los dispositivos de tarjeta inteligente o tecnología biométrica y puede
almacenar credenciales de usuario y sus propios valores del sistema y
políticas en cualquier directorio LDAP o una de las diferentes bases de
datos.
5. Opera desde una consola de administrador que simplifica las tareas
administrativas, reconociendo y configurando las aplicaciones para el inicio
de sesión con un mínimo de esfuerzo por parte del administrador.
6. Ofrece a los usuarios empresariales un único inicio de sesión mientras está
conectado o no a la red corporativa, mientras cambia de sistemas o si está
compartiendo un quiosco con varios usuarios.
7. Agrega datos para auditar los accesos únicos así como capacidades de
reporte para éstos.
113
8. Se obtienen beneficios rápidos y una alta recuperación de las inversiones
(ROI) con una solución sencilla y rápida de desplegar, que reduce los
costos de servicio técnico.
9. Se aumenta la productividad de los empleados, centralizando la
automatización de las credenciales de usuario para que se agilicen los
procesos manuales necesarios para crear las cuentas de usuario y sus
correspondientes credenciales.
10. Soporta los siguientes sistemas operativos: AIX, HP Unix, Linux, Sun
Solaris, Windows.
9.2.2.1.1.3 Características, ventajas y beneficios del Producto
Cuadro No 11 Características, ventajas y beneficios de IBM Tivoli Access Manager
CARACTERISTICAS VENTAJAS BENEFICIOS
Acceso único Comprobado
Los usuarios se autentican una sola vez para acceder a la mayoría de las aplicaciones
Este detecta y responde a todos los eventos de acceso.
Administración Segura
De accesos
Generación y soporte de políticas de acceso Usa la más fuerte criptografía disponible actualmente, incluyendo TripleDes y AES.
Elimina el inseguro comportamiento de acceso de usuario final
Administración de
Cumplimiento
Extiende las capacidades de auditoria y reporte mediante una solución de implementación rápida.
Elimina los costos asociados al usuario final. Ayuda a la organización a cumplir con las fuertes regulaciones de privacidad y seguridad que gobiernan sus operaciones.
114
Administración de
identidad
Integrado fuertemente con Tivoli Identity Manager y Tivoli Access manager para e-business
El acceso único integrado es un requerimiento clave para una completa solución de administración de identidad
Muy fácil
Implementación
La utilización del wizard, llevará al administrador a través de las tareas de configuración, implementación y administración.
Sin manejo de scripts, ni programación ni procesos de integración.
Rápida y alta
Recuperación de
Inversiones(ROI)
Elimina en los usuarios la necesidad de administrar accesos
Reduce los costos de soporte técnico debido a la reducción en la atención de llamadas para desbloqueo o reinicio de claves de acceso. Mejora la productividad del usuario final, eliminando la necesidad de recordar y administrar claves de usuario
9.2.2.1.1.4 Elementos que integran la plataforma
El IBM Tivoli Access manager para la plataforma empresarial de acceso único
puede extenderse con componentes adicionales tales como:
1. IBM Tivoli Access Manager for Enterprise Single Sign - On:
Provee a las compañías de una solución empresarial de acceso único que le
simplifica al usuario final la administración de dicho acceso, eliminando la
necesidad de recordar y administrar nombres de usuario y contraseñas. Tivoli
Access Manager para acceso único empresarial sirve de base para los otros
componentes.
115
2. IBM Tivoli Access Manager for Enterprise Single Sign - On Desktop Password Reset Adapter :
Permite el acceso a la cuenta de usuario de Windows cuando se pierda u
olvide la contraseña. No requiere ponerse en contacto con el servicio técnico o
el servicio de asistencia, ni esperar a que un administrador restablezca la
contraseña.
Únicamente se requiere realizar una rápida "encuesta" que verifique que el
usuario es quien dice ser, y éste podrá restablecer su contraseña por sí mismo.
El usuario creará las respuestas del cuestionario cuando se complete la
entrevista de inscripción de TAM E-SSO: Desktop Password Reset Adapter.
Una vez completada la entrevista de inscripción, se podrá realizar el
cuestionario de restablecimiento de TAM E-SSO: Desktop Password Reset
Adapter cada vez que se pierda u olvide la contraseña. Si las respuestas de la
encuesta coinciden con las respuestas proporcionadas en la entrevista de
inscripción, se podrá crear una nueva contraseña de Windows e iniciar sesión.
TAM E-SSO: Desktop Password Reset Adapter es sencillo, rápido y seguro y
permite que el servicio técnico de la organización pueda dedicarse a otras
prioridades.
3. IBM Tivoli Access Manager for Enterprise Single Sign - On Provisioning Adapter
Extiende los beneficios generados por el TAM E-SSO a través de la
automatización del proceso de distribución de credenciales de usuario. El
adaptador provisto por TAM E-SSO, trabajando con el Administrador de
Identidad Tivoli, puede pre habitar las credenciales TAM E – SSO de usuario
final almacenadas por lo que los usuarios nunca pueden tocarlas, o si quiera
conocer sus nombres de usuario.
4. IBM Tivoli Access Manager for Enterprise Single Sign - On Authentication Adapter
Es una robusta solución de administración de autenticación que permite una
flexible autenticación utilizando tokens, tarjetas inteligentes, biométricas y
116
accesos. Actuando como una capa mediadora entre los autenticadores y el
TAM E-SSO, el adaptador de autenticación TAM E-SSO permite a cualquier
autenticador trabajar con cualquier aplicación.
5. IBM Tivoli Access Manager for Enterprise Single Sign - On Kiosk Adapter
Adaptador de quioscos que permite utilizar máquinas en forma compartida.
Direcciona la amenaza de accesos individuales para compartir estaciones de
trabajo o quioscos, suministrando la terminación automatizada de sesiones
inactivas, y apagado de aplicaciones.
9.2.2.1.1.5 Esquema redundante o alta disponibilidad
El IBM Tivoli Access Manager ofrece esquemas de redundancia basados en la
implementación del repositorio, ya que no hay ningún componente de máquina
o servidor de firma única. El esquema de automatización está basado en
asistentes y parámetros, no en scripts.
A nivel del agente se encuentra toda la información de las credenciales del
usuario, de tal manera que el agente no necesita estar conectado al servidor
principal para funcionar. Si el usuario sale de la Red, o si el usuario no está
disponible, el agente funciona correctamente y permite el Single Sign - On a las
aplicaciones.
A nivel del Servidor, la solución se basa en un aplicativo instalado sobre una
base de datos. Esto proporciona un segundo enfoque de alta disponibilidad ya
que tanto la aplicación como la base de datos se pueden poner en cluster, esto
garantiza la alta disponibilidad.
9.2.2.1.1.6 Consideraciones respecto al proceso de implementación
Respecto a la implementación, la misma se hace de forma sencilla y puede
tardar alrededor de 15 días, dependiendo de algunas configuraciones
adicionales que se requieran en la Plataforma de la Organización.
117
9.2.2.1.1.7 Infraestructura de TI requerida
Según el tipo de implementación, podría requerirse un servidor con ciertas
capacidades de robustez, además de algunos adaptadores para complementar
la solución.
9.2.2.1.1.8 IBM - ENCENTUATE
Dentro de las novedades que promueve IBM se encuentra la adquisición de un
vendedor líder de soluciones Enterprise Single Sign - On (ESSO)
9.2.2.1.1.8.1 Visión y estrategia de la solución
ENCENTUATE se centra en la gestión de la identidad en los END POINTS
aprovechándolos para permitir las funciones de gestión de identidad.
La identidad de un END POINT y la arquitectura de administración de accesos
aprovecha el agente de usuarios inteligente en los END POINTS de la empresa
para administrar el Single Sign - On, el autenticador two-factor y la
automatización de los workflows. La arquitectura de END POINTS ofrece varias
ventajas sobre las arquitecturas convencionales centradas en servidores;
dentro de ellas están:
Mejora la productividad, al proveer un agente inteligente que simplifica el
acceso, provee Single Sign - On y automatiza los flujos de trabajo para
incrementar la productividad.
Simplifica la integración del agente, a nivel de capa de presentación con el
servidor de las aplicaciones. En lugar de tener una extensión por aplicación,
solo se requiere un agente en cada Enterprise END POINT. Esto provee
flexibilidad y extensibilidad con riesgos mínimos de implementación.
Para llevar a cabo esta visión, la solución de SSO se enfoca en:
1. Automatización del acceso a la información: En adición a ESSO en
plataformas heterogéneas, la solución continua reduciendo el tiempo
hacia la información con funcionalidades como:
118
a. Ir más allá de Single Sign - On, al proveer automatización de
flujos de trabajo: soporte para workflows y automatización de
políticas de seguridad. En particular, asegurarse que todas las
políticas de los workflows sean administradas de manera
centralizada.
b. Soporte de más END POINTS, al proveer soporte para PDAs (y
otros dispositivos móviles), plataformas como Macintosh y Linux,
brindando una consistente experiencia al usuario y capacidades
de auditoria.
2. Automatización del tracking de auditoria y cumplimiento: En adición al
track del END POINT que reporta todos los intentos de autenticación, la
solución es capaz a través de su framework de auditoria de:
a. Incrementar el seguimiento a los eventos: para dar seguimiento a
los eventos de cualquier END POINT y reportarlos de manera
centralizada.
b. Enforzamiento personalizado en el END POINT: a través de un
framework que permite la personalización de la seguridad y
ejecución automática de scripts, en el END POINT.
3. Permitir el aseguramiento de la identidad con actualizaciones de
seguridad incrementales.
4. Implementación de actualizaciones transparentes en las organizaciones.
9.2.2.1.1.8.2 Características adicionales que complementan el Tivoli Access
Manager
1. Seguridad Transparente
a. Permite elegir el tipo de factor de autenticación
b. Transición incremental hacia una identidad digital fuerte.
c. Identidad del END POINT personalizable y automatización de accesos.
2. Uso Conveniente
a. Generación automática de perfiles de aplicaciones para el Single Sign – On.
119
b. Administración de sesiones
c. Cobertura de los Enterprise END POINTS
d. Implementación centralizada con registro en 2 fases.
e. Auto-ayuda integrada
f. Administración centralizada y revocación de accesos a los usuarios
3. Acceso Integrado
a. Acceso unificado hacia sistemas físicos y lógicos utilizando una única credencial
b. Cobertura de todos los grupos de usuario en una única plataforma
c. Seguimiento centrado en el usuario de todos los puntos de acceso.
d. Integración con soluciones de aprovisionamiento de usuarios.
e. Facilidad de integración con la infraestructura de TI existente.
f. Framework distribuido con agentes de acceso inteligentes
9.2.2.1.1.8.3 Beneficios de ENCENTUATE
Dentro de los beneficios que ENCENTUATE brinda se encuentran:
• Mejora la productividad: Provee una solución empresarial Single Sign -
On y automatización de flujos de trabajo, lo que aumenta la
productividad y reduce la administración de múltiples contraseñas.
• Aumenta la Seguridad: Fortalecimiento del acceso a la información
desde un punto de vista de riesgo mínimo. ENCENTUATE provee una
forma de mitigar el costo de seguridad al tiempo que garantiza el acceso
apropiado y a tiempo a la información corporativa.
• Permite el cumplimiento de regulaciones: Fortalecimiento del acceso
a la información, con la implementación de logs centrados en usuarios,
la solución provee los medios para el cumplimiento con regulaciones
como: Sarbanes Oxley, the Gramm-Leach-Bliley Act, HIPAA, and the
California SB 1386.
120
• Simplifica la integración e implementación: Minimizando los cambios
en la infraestructura, ENCENTUATE no es intrusivo y puede ser
implementado en semanas.
• Permite la administración centralizada del acceso a la información:
ENCENTUATE permite la administración centralizada a través del
AccessAdmin y con la integración de soluciones de aprovisionamiento
como el Tivoli Identity Manager.
• Provee un rápido retorno de inversión (ROI): La rápida
implementación de ENCENTUATE y sus características de mejoras en
la productividad, minimizan el riesgo y permiten un rápido retorno de la
inversión.
9.2.2.1.1.8.4 Autenticación Fuerte
Con ENCENTUATE, los usuarios pueden autenticarse hacienda una
combinación de su contraseña con Tarjetas de RFID, autenticación de un
teléfono celular, dispositivos biométricos, tarjetas inteligentes USB, tarjetas de
acceso a edificios, etc. Tener una amplia gama de opciones para autenticación
fuerte permite a las empresas la flexibilidad de utilizar diferentes factores,
dependiendo del grupo a que pertenezca el usuario.
Además, permite asegurar que las necesidades de los diferentes grupos de
usuarios son satisfechas con una solución integrada y no múltiples soluciones
puntuales.
Con el soporte para tarjetas de acceso a edificios, dispositivos móviles y
objetos personales para la autenticación, ENCENTUATE es único reutilizando
“lo que usted ya tiene” como factor de autenticación fuerte. Esto no solo reduce
el costo de adquisición, el costo de aprovisionamiento, sino también el costo de
soportar la solución. Además, brinda una gran ventaja porque el usuario no
tiene que tener un dispositivo adicional al que ya utiliza.
Independientemente del Segundo factor de autenticación elegido, el
administrador puede manejar centralizadamente todas las políticas a través de
ENCENTUATE AccessAdmin.
121
9.2.2.1.1.8.5 Políticas de contraseña que soporta el producto
El administrador de TI puede especificar la longitud de la contraseña, las
combinaciones de números, letras, minúsculas, mayúsculas y el tiempo de
expiración.
ENCENTUATE recomienda que la aplicación continué con su política de
enforzamiento de contraseñas; esto permite que todas las políticas de
contraseñas de las aplicaciones son esforzadas incluso para los usuarios que
no utilizan el Single Sign - On.
Sin embargo, ENCENTUATE puede ser configurado para reconocer las
pantallas de cambio de contraseña de una aplicación. En este caso se puede
configurar para permitir al usuario que cambie su contraseña y se actualice en
el Wallet o ENCENTUATE puede ser configurado para auto-generar una nueva
contraseña y aplicar los cambios sin la intervención del usuario.
122
9.2.2.2 Empresa CR Conectividad
9.2.2.2.1 Producto: Citrix® Password Manager
Citrix Password Manager es una herramienta que aumenta la seguridad de
Aplicación para todas las aplicaciones sean ofrecidas por Presentation Server o
utilizadas en el escritorio. Las organizaciones pueden centralizar la gestión de
contraseñas con informática para un mayor control, mientras que los usuarios
experimentan los beneficios de productividad de un ingreso rápido y automático
a la Web, Windows y aplicaciones basadas en servidores anfitriones.
9.2.2.2.1.1 Generalidades del producto
Citrix Password Manager es la solución de registro único (Single Sign – On)
empresarial más segura, eficiente y fácil de implementar para el acceso a
aplicaciones Windows, Web y basadas en host, protegidas por contraseña.
Los usuarios se autentican una vez con una sola contraseña y Password
Manager automatiza los inicios de sesión, el cumplimiento de las políticas y los
cambios de contraseña, logrando que conectarse a las aplicaciones sea más
fácil, rápido y seguro. Como solución independiente o dentro de Citrix Access
Suite, Password Manager mejora la seguridad de las contraseñas, lo que
simplifica las actividades de computación y puede ayudar a reducir los costos
del soporte técnico en más de un 25%.
9.2.2.2.1.2 Password Manager 4.5
Password Manager 4.5 ofrece acceso de registro único independientemente de
cómo o cuándo los usuarios se conectan a sus aplicaciones, y permite a los
usuarios restablecer su propia contraseña de Windows o desbloquear su
cuenta a través de la Interfaz de Web Citrix. Los ingresos al sistema unificados
son posibles para todos los tipos de aplicaciones de socios de confianza
(Windows, Web, y basadas en servidores anfitriones), ofrecidas por el
Presentation Server y a las que se accede a través de la Interfaz de Web.
Esta herramienta cuenta con una mayor compatibilidad de aplicaciones y
definiciones de aplicaciones extensibles para hacer que las aplicaciones que
permiten un registro único sean más rápidas y más eficientes. La
123
administración puede ser realizada por Active Directory Group, ofreciendo más
flexibilidad y una implementación más fácil.
El proceso de cambiar contraseñas se simplifica y se proporciona una
confirmación inmediata, además, los usuarios con más de una cuenta de
Windows pueden aprovechar sus credenciales de registro único en todas sus
cuentas personales (Bancos, Yahoo, Hotmail, Messenger, etc.).
Para los compradores que se preocupan por el gobierno y la seguridad,
Password Manager se encuentra actualmente en proceso de Certificación de
Criterio Común.
9.2.2.2.1.3 Características y Beneficios
Citrix Password Manager elimina las brechas de seguridad que son comunes
cuando los usuarios tienen más contraseñas de las que pueden manejar, es
fácil de implementar y de usar y no requiere reescritura de comandos,
integración a nivel de las aplicaciones ni cambios significativos en la
infraestructura informática existente.
Dentro de sus características y beneficios se encuentran:
1. Inicio de sesión único
Requiere que los usuarios inicien sesión sólo una vez con sus credenciales de
red, y automatiza los inicios de sesión subsiguientes en las aplicaciones a
través de un explorador Web, un cliente Windows o un emulador de terminal
host para aumentar la productividad de los empleados y la satisfacción del
usuario.
2. Aplicación de políticas de contraseñas
Especifica por aplicación, las características de una contraseña fuerte como
requisitos de extensión, repetición de caracteres y cantidad de alfanuméricos.
Se aplica a los cambios de contraseña manuales y automáticos. Las políticas
de contraseña fuerte ofrecen más seguridad. En este punto, es importante
indicar que el Password Manager utilizará las políticas de seguridad a nivel de
124
accesos que utilice el Active Directory, respetando para cada aplicación
incluida dentro del proceso de logeo único, las características de cada clave de
acceso
3. Cambio de contraseña transparente
Hace transparente el proceso de cambio de contraseña, ocultando las
contraseñas a los usuarios finales. Dado que las contraseñas permanecen
ocultas para los usuarios finales, sólo es necesario desactivar el inicio de
sesión de red principal para denegar el acceso al usuario.
4. Autoservicio de restablecimiento de contraseñas
Permite que los usuarios restablezcan su contraseña de dominio desde su
equipo, lo que reduce aún más los costos de las líneas de soporte para
restablecimiento de contraseñas.
5. Hot Desktop
Permite que los usuarios que comparten estaciones de trabajo inicien y
finalicen sesiones en segundos, en lugar de utilizar un procedimiento Novell o
Windows completo que demora mucho tiempo.
El escritorio activo, denominado Hot Desktop, mejora la productividad del
usuario, ofrece un acceso sin dificultades a los recursos informáticos y elimina
las cuentas de inicio de sesión genéricas, para incrementar la responsabilidad
de los empleados.
6. Interoperabilidad con dispositivos para autenticación de factores múltiples, como tarjetas inteligentes, tokens y dispositivos de identificación biométrica.
Utiliza el subsistema de seguridad de Windows y viene listo para usar con
muchos dispositivos populares de autenticación de factores múltiples, entre
ellos los dispositivos basados en certificados y en contraseñas. No se necesita
integración adicional.
125
7. Certificación de seguridad de terceros
Tal como lo indican auditores de seguridad independientes, Password Manager
es seguro y respeta las mejores prácticas de seguridad.
9.2.2.2.1.4 Comparación por tipo de Licencia en la Versión 4.6
La nueva línea de productos de Citrix Password Manager Product consiste de 3
ediciones:
9.2.2.2.1.4.1 Citrix Password Manager 4.6 Advanced Edition
Con el Advanced Edition, los usuarios tienen capacidad completa del Single
Sign – On, incluyendo sobre la Red LAN, trabajando en estado desconectado,
vía conexión VPN, o desde una PC, kiosco o cualquier conexión de Internet.
Las credenciales de usuario único son mantenidas para todas las aplicaciones,
XenApp (Presentation Server) y aplicaciones de escritorio.
9.2.2.2.1.4.2 Citrix Password Manager 4.6 Enterprise Edition
Contiene todas las características de la Edición Avanzada, agregando Switcheo
de escritorio caliente, mientras permite a los usuarios compartir estaciones de
trabajo en sectores públicos como estaciones médicas o áreas de manufactura,
permitiendo a los usuarios mayor movilidad en su sitio de trabajo al interactuar
entre estaciones de trabajo, sin riesgo alguno de afectar la seguridad.
Las organizaciones tienen la flexibilidad de utilizar el dispositivo de
autenticación para todos los escenarios de acceso. Los usuarios pueden
accesar con una contraseña al trabajo y un token remotamente, y no
experimentarán retrasos cuando se intercambie entre los dispositivos. El
soporte avanzado de tarjetas inteligentes es provisto y los usuarios pueden
manejar sus credenciales de Single Sign – On a través de las múltiples cuentas
de Windows mediante una asociación de cuentas.
9.2.2.2.1.4.3 Citrix Password Manager 4.6 para Citrix XenApp
Es la Solución Empresarial Single Sign – On, líder en la industria para
Presentation Server y ambientes Terminal Services. Este centraliza la
126
administración de Passwords, políticas de password y autenticación de
aplicaciones en manos de Tecnología de Información (IT).
Los usuarios pueden reiniciar sus password de Windows o desbloquear o
bloquear sus cuentas remotamente a través de una interfase de Web para
Citrix XenApp, servicios federados de Active Directory (ADFS), Kerberos, y
soporte a ambiente federado que permite la federación a cualquier tipo de
aplicación, no solo aplicaciones Web.
Cuadro Comparativo
El cuadro 8 permite identificar las bondades de cada tipo de Licenciamiento.
Cuadro No 12. Cuadro comparativo, bondades Password Manager según licenciamiento
Password Manager
Advanced Edition
Password Manager
Enterprise Edition
Password Manager
para XenApp
Mejor para utilizar en. Solo Desktop o Desktop +
XenApp (Presentation Server) Solo XenApp
Single Sign - On y Administración de Password
Single Sign - On a Aplicaciones Web,
Windows, Host
Web, Windows,
Host
Web, Windows, Host
Corre en Desktops y Presentation Server
Políticas detalladas de password
Cambios transparentes de Password
Soporte de autenticación para Biométricos, Token y Proximity Badge
Integración de aprovisionamiento de usuarios (SPML)
Modelo de licenciamiento Named User
(NU) Named User
(NU) Concurrent
(CCU)
Tipo de Almacenamiento central Active
Directory, LDAP*, NTFS
Active Directory,
LDAP*, NTFS
Active Directory,
LDAP*, NTFS
Auto Servicio de usuario, Movilidad en Sitio y Seguridad Avanzada
Auto Servicio de reinicio, bloqueo o desbloqueo de cuentas de acceso
127
Password Manager
Advanced Edition
Password Manager
Enterprise Edition
Password Manager
para XenApp
Switcheo de escritorio caliente
Asociación de cuentas
Soporte a Tarjetas inteligentes,
Common Criteria Certification in process
Optimización para Citrix Presentation Server
Integración de reportes centralizado
Compatible con Aplicaciones Citrix
Auto Servicio desbloqueo/reseteo de Password a través de una interfase de Web
Switcheo de escritorio Caliente
SSO federado a cualquier aplicación utilizada en el Presentation Server
9.2.2.2.1.4.4 Esquema redundante o alta disponibilidad
El Password Manager se adapta al esquema de alta disponibilidad que
contiene el Directorio Activo de cada empresa.
9.2.2.2.1.4.5 Consideraciones respecto al proceso de implementación
Dado que no se requiere infraestructura adicional, la implementación es
sumamente sencilla y rápida. La misma puede ser efectuada en 2 o 3 días.
9.2.2.2.1.4.6 Infraestructura de TI requerida
No se requiere infraestructura adicional para efectuar una implementación del
Producto.
9.2.2.2.1.4.7 Prueba y Validación
Con el fin de probar las vulnerabilidades de la herramienta, se contrató una
empresa que probara y validara los niveles de seguridad correspondientes.
128
Los resultados demostraron que las capacidades de seguridad de Password
Manager, entre ellas la solidez del cifrado, la prevención del desborde de la
memoria intermedia, el uso adecuado del sistema operativo y los permisos de
registro, así como la presencia de técnicas contra la manipulación ilícita,
contribuyen a la solidez del marco de seguridad incorporado al producto.
Password Manager, brinda acceso de registro único (SSO) empresarial a
aplicaciones Windows, Web y basadas en host. Esta solución mejora la
velocidad y la seguridad de conectarse a aplicaciones seguras, y puede reducir
los costos de asistencia informática hasta en un 25 por ciento, al disminuir la
cantidad de llamadas a la línea de soporte relacionadas con las contraseñas.
129
9.3 Identificación de Requerimientos
Los requerimientos del INS definidos como esenciales para la eventual
implementación de una solución tipo Single Sign – On en la Plataforma
Tecnológica Institucional son:
9.3.1 Identificación de Sistemas por Plataforma
El INS contempla dentro de su Infraestructura de TI, tres plataformas
principales:
1. Plataforma AS/400
2. Plataforma AIX
3. Plataforma Windows
Cada plataforma alberga un sinnúmero de sistemas los cuales se detallan a
continuación en los cuadros 9,10, 11 y 12; indicando para cada uno de ellos, la
cantidad de usuarios a lo interno de la Institución.
Cuadro No 13 Usuarios por Plataforma AS/400
Usuarios por plataforma y por Aplicación
Plataforma AS/400
Sistema Usuarios activos
Point Life 574
Sistema Administrador de Seguros de Vida Dólares 675
Sistema de Administración de Seguros de Incendio Dólares 178
Sistema de Administración de Seguros Riesgos del Trabajo 719
Sistema de Administración Otros Seguros 534
Sistema de Pago Exámenes Médicos 150
Sistema de Administración del Seguro de Automóviles 385
Vida Tradicional 1695
Point General 1633
Sistema de Aseguramiento del Seguro INSMEDICAL 60
Sistema de Planillas de Deducción Mensual 1200
Total Usuarios por Plataforma 7803
130
Cuadro No 14 Usuarios por Plataforma AIX
Usuarios por plataforma y por Aplicación
Plataforma AIX
Sistema Usuarios activos
SICSOA Durante el periodo de Cobro del Marchamo es de 1350 (Noviembre a Enero). A partir de Febrero y hasta Octubre inclusive es de 200 usuarios
PECSOA 498
SIMA 2082
SIFA 450
Total Usuarios por Plataforma Varía entre 4380 y 3230
Cuadro No 15 Usuarios por Plataforma Windows
Usuarios por plataforma y por Aplicación
Plataforma Windows - Web
Sistema Usuarios activos
Banca Seguros (Web) 772
Sistema Preventico Empresarial 1000
Sistema Integrado de Control de Inspecciones 200
Sistema de Administración de Cartera Seguros Marítimos 100
Sistema Estadístico de Producción 50
Sistema de Administración de Cuentas Estratégicas 200
Sistema Consecutivo de Inspecciones 100
Sistema de Control y Administración de Requerimientos 90
Inspección (reportes accidentes/Citas de Valoración/Control Valijas/Asignación de Inspectores)
211
Casos 230
Liquidaciones del BackOffice 62
Sistema de Carga Masiva de Asegurados 110
Sistema de impresión de condiciones generales 1000
Sistema de impresión de condiciones generales y particulares
1000
Sistema Base Unificada de Clientes (Web) 1000
Sistema Intranet Operaciones 100
Sistema de Administración y Control. Modificaciones en Sistema Productivo
100
RIGEL (Workflow Accidentes y Salud) 60
Sistema de Comercialización de Intermediarios (Web) 745
Total Usuarios por Plataforma 7130
131
Cuadro No 16 Otras herramientas de uso Administrativo
9.3.2 Esquema de Seguridad
El esquema de Seguridad utilizado, es diferente para cada Plataforma y para
cada Sistema según se haya definido durante el proceso de Implementación,
apegándose a la normativa establecida para tales efectos.
Para la Plataforma AS/400, el esquema de seguridad ya se encuentra normado
por las reglas del ambiente. Para cualquiera de las aplicaciones albergadas en
esta plataforma, la clave de acceso debe ser de 8 caracteres como mínimo y
10 como máximo, el campo es Alfanumérico, requiriendo incluir dentro de éste
al menos una mayúscula y un dígito. Adicionalmente, tiene una vigencia de 30
días, requiriéndose al final del periodo, realizar el cambio de clave, siguiendo la
normativa correspondiente.
Para la Plataforma Unix, la normativa para la clave de acceso es diferente para
cada Sistema según el esquema definido al momento de cada desarrollo.
Para el caso del Sistema SICSOA, el campo es un alfanumérico de hasta 10
posiciones sin restricciones respecto a los valores a incluir en el campo. La
clave de acceso tiene un vencimiento de un año, no obstante, la política
respecto a la caducidad puede ser administrada a nivel de base datos
considerando un vencimiento de 30 días.
Usuarios por plataforma y por Aplicación
Otras herramientas de Uso Administrativo
Aplicación Usuarios activos
INTERNET 1500
CORREO INSTITUCIONAL 2200
Total Usuarios por Plataforma 3700
132
El Pecsoa, contempla un campo alfanumérico de entre 6 y 8 posiciones, sin
restricciones respecto a los valores a incluir. Al realizar el cambio de clave, la
misma no puede ser igual a la anterior, y tiene una vigencia de hasta 45 días.
El SIMA tiene un esquema similar al del sistema Pecsoa, tanto en la
combinación de valores en el campo, longitud y caducidad del mismo.
Para el caso del Sistema SIFA, el SAP, utiliza un formato alfanumérico para
definición del usuario que contiene las siglas de la Dependencia, definidas por
el Departamento de Control y Gestión de TI. El 0 para las licencias titulares, el
9 para las temporales y las iniciales del nombre y los apellidos, contemplando
un máximo de 10 caracteres en su esquema.
Cuando se ingresa por primera vez al ambiente, las contraseñas son dadas por
el sistema, posteriormente se personalizan contemplando un mínimo de 5 y un
máximo de 8 posiciones, sin distinción respecto al uso de minúsculas o
mayúsculas.
Actualmente, no se cuenta con políticas claramente definidas en la creación de
las claves, no obstante, se iniciará un proceso de estandarización de las
mismas con el apoyo del Dpto. de Control y Gestión de TI.
Para la Plataforma Windows, la normativa de autenticación es similar a la de la
Plataforma UNIX, pues el esquema es definido por cada desarrollador.
Actualmente, se encuentran en producción muchos desarrollos con más de 5
años de antigüedad, los cuales no contemplan esquemas de seguridad
adecuados. Para muchos de estos, la clave de acceso no contempla mínimos
o máximos, ni caducidad alguna.
A continuación, el cuadro 13 muestra, para cada aplicación, de acuerdo a la
plataforma que lo contiene, las políticas de contraseñas inherentes a cada uno.
Adicionalmente, se detallan las versiones Sistema Operativos, Base de Datos y
Sistema Operativo de Base de Datos.
13
3
Cu
adro
No
17
Ver
sio
nes
S.O
y E
squ
em
a d
e a
ute
nti
cac
ión
Pla
tafo
rma
AS
/40
0 p
or
Ap
lic
ació
n
Pla
tafo
rma
AS
/40
0
S
iste
ma
Ver
sió
n
Sis
tem
a O
per
ativ
o
Ap
licac
ión
Sis
tem
a O
per
ativ
o
Ba
se d
e D
ato
s
Ba
se d
e D
ato
s H
erra
mie
nta
de
De
sarr
ollo
T
ipo
de
Ap
licac
ión
S
oft
war
e d
e In
tera
cció
n
Po
lític
a d
e co
ntr
aseñ
a C
adu
cid
ad
Poi
nt
Life
O
S/4
00
V5R
3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
All
Adva
nta
ge 8
,0
/Syn
on
Ter
min
al
Clie
nt A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10
cara
cter
es
Entr
e 30 y
60
días
Sis
tem
a A
dm
inis
trador
de
Seg
uros
de V
ida
Dól
are
s O
S/4
00
V5R
3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
SN
AP
3.1
T
erm
inal
C
lient A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10
cara
cter
es
Entr
e 30 y
60
días
Sis
tem
a de
Adm
inis
trac
ión
de S
egur
o de
Ince
ndio
Dól
are
s
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
Co
bol 3
6, C
obol
na
tivo, R
PG
, S
NA
P,
OC
L
Ter
min
al
Clie
nt A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10
cara
cter
es
Entr
e 30 y
60
días
Sis
tem
a de
Adm
inis
trac
ión
de
Seg
uros
Rie
sgos
del
T
raba
jo
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
DB
240
0 5.
3
Sna
p, C
L, C
obol,
RP
G
Ter
min
al
Clie
nt A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10
cara
cter
es
Entr
e 30 y
60
días
Sis
tem
a de
Adm
inis
trac
ión
Otr
os
Seg
uros
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
SN
AP
3.1
T
erm
inal
C
lient A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10
cara
cter
es
Entr
e 30 y
60
días
13
4
Pla
tafo
rma
AS
/40
0
S
iste
ma
Ver
sió
n
Sis
tem
a O
per
ativ
o
Ap
licac
ión
Sis
tem
a O
per
ativ
o
Ba
se d
e D
ato
s
Ba
se d
e D
ato
s H
erra
mie
nta
de
Des
arro
llo
Tip
o d
e A
plic
ació
n
So
ftw
are
de
Inte
racc
ión
P
olít
ica
de
con
tras
eña
Cad
uci
dad
Sis
tem
a de
Pago
Exá
me
nes
Médi
cos
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
Cobol
, R
PG
T
erm
inal
C
lient A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scul
as,
min
úscu
las
y al
men
os u
n d
ígito
) -
Máxi
mo
10 c
ara
ctere
s
Entr
e 3
0 y
60
días
Sis
tem
a de
Adm
inis
trac
ión
del S
eg
uro
de A
uto
móvi
les
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
Cobol
36, C
obol
na
tivo, R
PG
, S
NA
P,
OC
L
Term
inal
C
lient A
cces
s 5.3
M
ínim
o 8
car
act
ere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10 c
ara
ctere
s
Entr
e 3
0 y
60
días
Vid
a T
radi
cion
al
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
Cobol
36, C
obo
l na
tivo, R
PG
, S
NA
P,
OC
L
Term
inal
C
lient A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scul
as,
min
úscu
las
y al
men
os u
n d
ígito
) -
Máxi
mo
10 c
ara
ctere
s
Entr
e 3
0 y
60
días
Poi
nt G
ener
al
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Arc
hivo
s P
lanos
CO
BO
L, S
NA
P,
SY
NO
N, A
LR
T
erm
inal
C
lient A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10 c
ara
ctere
s
Entr
e 3
0 y
60
días
Sis
tem
a de
Ase
gura
mie
nto
de
segur
o IN
SM
ED
ICA
L
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
DB
2
SN
AP
3.1
C
/S
Clie
nt A
cces
s 5.3
M
ínim
o 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10 c
ara
ctere
s
Entr
e 3
0 y
60
días
13
5
Pla
tafo
rma
AS
/40
0
S
iste
ma
Ver
sió
n
Sis
tem
a O
per
ativ
o
Ap
licac
ión
Sis
tem
a O
per
ativ
o
Ba
se d
e D
ato
s
Ba
se d
e D
ato
s H
erra
mie
nta
de
Des
arro
llo
Tip
o d
e A
plic
ació
n
So
ftw
are
de
Inte
racc
ión
P
olít
ica
de
con
tras
eña
Cad
uci
dad
Sis
tem
a de
Pla
nill
as d
e
De
ducc
ión
Me
nsu
al
OS
/400
V
5R3M
0 O
S/4
00
V
5R
3M0
Lotu
s D
om
ino
7.0
1
Lotu
s D
esi
gn
er 7
.01
N C
apa
s Lot
us N
ote
s
Mín
imo 8
cara
ctere
s (M
ayú
scula
s, m
inúsc
ula
s y
al
men
os u
n d
ígito
) -
Máxi
mo
10 c
ara
ctere
s
Entr
e 3
0 y
60
días
C
uad
ro N
o 1
8 V
ers
ion
es S
.O y
Esq
ue
ma
de
au
ten
tica
ció
n P
lata
form
a A
IX p
or
Ap
lic
ació
n
Pla
tafo
rma
AIX
S
iste
ma
Ver
sió
n
Sis
tem
a O
per
ativ
o
Ap
lica
ció
n
Sis
tem
a O
per
ativ
o
Ba
se d
e D
ato
s
Bas
e d
e D
ato
s H
erra
mie
nta
de
De
sarr
ollo
T
ipo
de
Ap
licac
ión
S
oft
war
e d
e In
tera
cció
n
Po
líti
ca d
e co
ntr
aseñ
a C
adu
cid
ad
SIC
SO
A
Win
dow
s 2
003
Serv
er
AIX
5.3
O
racl
e 1
0g
Ora
cle
Form
s B
uild
er
10g
N C
apas
O
racl
e F
orm
s
Cam
po A
lfanum
éric
o d
e 1
0 pos
icio
nes
(no h
ay
rest
ricc
ión
resp
ect
o a
los
valo
res
a in
cluir
en
el c
amp
o)
Cada
año
o s
egú
n se
defin
a a
niv
el d
e B
ase d
e D
atos
PE
CS
OA
W
indow
s 2
003
Serv
er
AIX
5.2
O
racl
e 1
0g
Ora
cle
Form
s B
uild
er,
Vers
ione
s 6i
y
10g
, O
racl
e
Re
port
s D
eve
loper
Ver
sione
s 6i y
10g
C/S
O
racl
e F
orm
s
Cam
po A
lfanum
éric
o d
e e
ntre
6 y
8 c
arac
tere
s (n
o ha
y re
stri
ccio
nes
resp
ecto
a
valo
res
a in
clui
r en
el c
am
po).
N
o de
be s
er
igua
l a la
cla
ve
inm
edia
tam
ente
ante
rior.
ca
da
45 d
ías
13
6
Pla
tafo
rma
AIX
S
iste
ma
Ver
sió
n
Sis
tem
a O
per
ativ
o
Ap
lica
ció
n
Sis
tem
a O
per
ativ
o
Ba
se d
e D
ato
s
Bas
e d
e D
ato
s H
erra
mie
nta
de
De
sarr
ollo
T
ipo
de
Ap
licac
ión
S
oft
war
e d
e In
tera
cció
n
Po
líti
ca d
e co
ntr
aseñ
a C
adu
cid
ad
SIM
A
Win
dow
s 2
003
Serv
er
AIX
5.2
O
racl
e 1
0g
Ora
cle
Form
s B
uild
er,
Vers
ione
s 6i
y
10g
, O
racl
e
Re
port
s D
eve
loper
Ver
sione
s 6i y
10g
N C
apas
y
C/S
O
racl
e F
orm
s
Cam
po A
lfanum
éric
o d
e e
ntr
e 6 y
8 c
arac
tere
s (n
o ha
y re
stri
ccio
nes
res
pec
to a
va
lore
s a in
clui
r en
el c
am
po).
N
o de
be s
er
igua
l a la
cla
ve
inm
edia
tam
ente
ante
rior.
ca
da
45 d
ías
SIF
A
AIX
A
IX
Ora
cle 9
i
SA
P R
/3 v
4.6c
, A
ba
p
IV
N C
apas
y
C/S
S
AP
4.6
C
Cam
po A
lfanum
éric
o d
e e
ntr
e 5 y
8 c
arac
tere
s. (
Sin
re
stri
ccio
nes
res
pec
to a
m
ayú
scula
s y
min
úsc
ula
s).
Cla
ve d
ifere
nte
a la
ante
rior
C
ada
30 d
ías
13
7
Cu
ad
ro N
o 1
9 V
ersi
on
es S
.O y
Es
qu
em
a d
e au
ten
tica
ció
n P
lata
form
a W
ind
ow
s p
or
Ap
licac
ión
Pla
tafo
rma
Win
do
ws
Sis
tem
a V
ersi
ón
Sis
tem
a O
per
ativ
o
Ap
licac
ión
Sis
tem
a O
per
ativ
o B
ase
de
Dat
os
Bas
e d
e D
ato
s H
erra
mie
nta
de
Des
arro
llo
Tip
o d
e A
pli
caci
ón
S
oft
war
e d
e In
tera
cció
n
Po
líti
ca d
e co
ntr
aseñ
a C
adu
cid
ad
Ban
ca S
eg
uros
(W
eb)
Win
dow
s 2
000
serv
er
Win
dow
s 2000
Ora
cle 9
i A
SP
N
Capas
W
eb
Ser
vice
N
o h
ay
info
rmaci
ón
----
--
Sis
tem
a pre
ventic
o E
mpr
esari
al
Win
dow
s 2
000
Win
dow
s 2000
Acc
ess
97
Vis
ual B
asi
c 6.0
E
nterp
rise
S
tand
alo
ne
N
o tie
ne
clave
de
acc
eso
--
----
Sis
tem
a In
tegr
ado
de C
ontr
ol
de I
nsp
ecci
ones
W
indow
s 2
003
Ser
ver
Win
dow
s 2003
Serv
er
Lotu
s D
om
ino
7.0
1 Lo
tus
Desi
gn
er
7.0
1 C
/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
Sis
tem
a de
Adm
inis
traci
ón
de
Cart
era
Seguro
s M
arítim
os
Win
dow
s 2
003
Ser
ver
Win
dow
s 2003
Serv
er
Lotu
s D
om
ino
7.0
1 Lo
tus
Desi
gn
er
7.0
1 C
/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Indefin
ida
Sis
tem
a E
stad
ístic
o de
P
rodu
cció
n W
indow
s 2
003
serv
er
Win
dow
s 2003
serv
er
SQ
L S
erve
r 200
0 V
isua
l Basi
c 6.0
, D
ynam
ic C
ube
2.5
, C
rist
al R
epor
t 7.0
C/S
--
----
- N
o h
ay
info
rmaci
ón
----
---
Sis
tem
a de
Adm
inis
traci
ón
de
Cu
enta
s E
stra
tégic
as
Win
dow
s 2
003
serv
er
Win
dow
s 2003
serv
er
Lotu
s D
om
ino
7.0
1 Lo
tus
Desi
gn
er
7.0
1 C
/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
Sis
tem
a C
onse
cutiv
o d
e In
specc
ione
s W
indow
s 2
003
serv
er
Win
dow
s 2003
serv
er
Lotu
s D
om
ino
7.1
Lotu
s D
esi
gn
er 6
.5
C/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
Sis
tem
a de
Contr
ol y
A
dmin
istr
ació
n de
Re
queri
mie
ntos
Win
dow
s 2
003
serv
er
Win
dow
s 2003
serv
er
Lotu
s D
om
ino
7.0
1 Lo
tus
Desi
gn
er
7.0
1 C
/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
13
8
Pla
tafo
rma
Win
do
ws
Sis
tem
a V
ersi
ón
Sis
tem
a O
per
ativ
o
Ap
licac
ión
Sis
tem
a O
per
ativ
o B
ase
de
Dat
os
Bas
e d
e D
ato
s H
erra
mie
nta
de
Des
arro
llo
Tip
o d
e A
pli
caci
ón
S
oft
war
e d
e In
tera
cció
n
Po
líti
ca d
e co
ntr
aseñ
a C
adu
cid
ad
Sis
tem
a de
pago M
asiv
o d
e R
ecl
amos
Ince
ndio
W
indow
s 2
000
Win
dow
s 2000
Acc
ess
97
Vis
ual B
asi
c 6.0
C
/S
Vis
ual B
asic
6
a 8
cara
ctere
s.
30 d
ías
Insp
ecc
ión
(R
epor
tes
Acc
iden
tes/
Cita
s de
Val
ora
ción/C
ontr
ol d
e
Val
ijas/
Asi
gnaci
ón
de
Insp
ect
ore
s.)
Win
dow
s 2
000
Ser
ver
Win
dow
s 2000
Serv
er
Ora
cle 1
0g
Vis
ual A
cces
s 20
00
C/S
A
plic
ació
n
Acc
ess
La
contr
ase
ña s
e
enc
ripta
en u
n
cam
po a
lfanum
éri
co
de
entr
e 8
y 1
5 ca
ract
eres
. D
ebe
conte
ner
una
com
bin
ació
n d
e
mayú
scul
as,
m
inús
cula
s y
núm
ero
s
Ind
efin
ida
Caso
s W
indow
s 2
000
Ser
ver
Win
dow
s 2000
Serv
er
Dbase
2.0
C
lipp
er 3
.0
C/S
C
lipper
La
contr
ase
ña s
e
def
ine e
n u
n ca
mpo
alfa
num
éri
co d
e 6
cara
cter
es. D
ebe
n in
cluirse
los
6
medi
ant
e u
na
com
bin
ació
n d
e
núm
ero
s y
letr
as
Ind
efin
ida
Liq
uid
acio
nes
del B
ack
Offic
e
Win
dow
s 2
000
Ser
ver
Win
dow
s 2000
Serv
er
SQ
L S
erve
r 200
0 A
SP
N
Capas
N
o h
ay
info
rmac
ión
No
hay
info
rmaci
ón
No
ha
y in
form
aci
ón
Sis
tem
a de
Car
ga M
asiv
a de
Ase
gura
dos
Win
dow
s 2
000
Win
dow
s 2000
SQ
L S
erve
r 200
0 V
isua
l Basi
c 6.0
E
nterp
rise
T
erm
inal
C
ampo a
lfanum
éri
co
sin
rest
ricc
ión
de
longitu
d o
tipo
de
valo
res
ind
efin
ida
Sis
tem
a de
Impre
sión
de
Co
ndic
iones
Genera
les
Win
dow
s 2
000
Win
dow
s 2000
SQ
L S
erve
r 200
0 C
# V
S .N
et
200
3,
AS
P.N
ET
N C
apas
N
o h
ay in
fo.
No
hay
info
rmaci
ón
----
----
----
-
13
9
Pla
tafo
rma
Win
do
ws
Sis
tem
a V
ersi
ón
Sis
tem
a O
per
ativ
o
Ap
licac
ión
Sis
tem
a O
per
ativ
o B
ase
de
Dat
os
Bas
e d
e D
ato
s H
erra
mie
nta
de
Des
arro
llo
Tip
o d
e A
pli
caci
ón
S
oft
war
e d
e In
tera
cció
n
Po
líti
ca d
e co
ntr
aseñ
a C
adu
cid
ad
Sis
tem
a de
Impre
sión
de
Co
ndic
iones
Genera
les
y P
artic
ula
res
Win
dow
s 2
000
Win
dow
s 2000
OD
BC
(iS
eri
es)
V
isua
l Basi
c 6.0
T
erm
inal
Sis
tem
a B
ase
Uni
fica
da d
e
Clie
nte
s W
indow
s 2
003
Ser
ver
Win
dow
s 2003
Serv
er
SQ
L S
erve
r 200
0 C
# V
S .N
et
200
5,
AS
P.N
ET
2.0
N
Capas
W
eb
Ser
vice
C
ampo a
lfan
uméri
co
de
mín
imo
8 ca
ract
eres
(Sin
re
stricc
ión d
e lo
s va
lore
s a in
clui
r en e
l ca
mpo
)
Ind
efin
ida
Sis
tem
a In
tran
et O
per
acio
nes
W
indow
s 2
003
Ser
ver
Win
dow
s 2003
Serv
er
Lotu
s D
om
ino
7.0
1 Lo
tus
Desi
gn
er
7.0
1 C
/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
Sis
tem
a de
Adm
inis
traci
ón
y C
ont
rol.
Mod
ifica
cion
es e
n
sist
ema
pro
duc
tivo
Win
dow
s 2
003
Ser
ver
Win
dow
s 2003
Serv
er
Lotu
s D
om
ino
7.0
1 Lo
tus
Desi
gn
er
7.0
1 C
/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
RIG
EL
(Wor
kflo
w A
ccid
ente
s y
salu
d)
Win
dow
s 2
003
Ser
ver
Win
dow
s 2003
Serv
er
Dom
ino
Wor
kflo
w
3.0
1 D
omin
o W
orkf
low
3.
01
C/S
Lotu
s N
ote
s Las
polít
icas
def
inid
as p
ara
la
Cla
ve d
e acc
eso
a
Lot
us N
otes
Ind
efin
ida
Sis
tem
a de
Com
erc
ializ
aci
ón
de I
nte
rmed
iari
os
Win
dow
s 2
003
serv
er
Win
dow
s 2003
serv
er
Ora
cle 1
0G
AS
P, A
SP
X C
#,
tecn
olo
gia
Dot
NE
T
2003
N C
apas
W
eb
Ser
vice
N
o h
ay
info
rmaci
ón
----
-
Sis
tem
a de
Pago M
asi
vo d
e
Recl
amos
Mar
ítim
o y
D
ivers
os
Win
dow
s 2
000
Win
dow
s 2000
Acc
ess
97
Vis
ual B
asi
c 6.0
C
/S
Vis
ual B
asic
N
o h
ay
info
rmaci
ón
No
ha
y in
form
aci
ón
14
0
Cu
adro
No
20
Otr
as
he
rra
mie
nta
s d
e U
so A
dm
inis
trat
ivo
Sis
tem
a V
ersi
ón
Sis
tem
a O
per
ativ
o A
plic
ació
n
Sis
tem
a O
per
ativ
o
Bas
e d
e D
ato
s
Bas
e d
e D
ato
s H
erra
mie
nta
d
e D
esar
rollo
T
ipo
de
Ap
lica
ció
n
So
ftw
are
de
Inte
racc
ión
P
olí
tica
de
con
tras
eña
Cad
uci
dad
Inte
rnet
Ver
sión
7.0
--
----
--
---
----
--
----
--
iexp
lore
r E
l in
gre
so
a
Inte
rnet
est
á
regul
ado
por
una
cla
ve
de
acc
eso
so
licita
da
por
el
Cis
co
Secu
re
la
cual
est
á
aso
ciada
a la
cla
ve d
efin
ida
por
el A
ctiv
e D
irect
ory
Indefin
ida,
no
obst
ante
, se
pue
de
mod
ifica
r m
edia
nte
el
C
isco
Secu
re
Cor
reo
Inst
ituci
onal
R
ele
ase
7.0
.3
----
--
----
--
----
--
----
--
Lotu
s N
ote
s La
Pol
ític
a
de
cont
rase
ñas
def
inid
a es
la q
ue p
or
defe
cto
est
abl
ece
Lo
tus
Not
es.
Act
ualm
ente
no
hay
re
stricc
ión
resp
ecto
al
tam
año
del
ca
mp
o
o
la
com
bin
ació
n d
e c
ara
ctere
s.
Indefin
ida,
no
obst
ante
, el
Lot
us
perm
ite c
ambi
ar
la
cont
rase
ña
segú
n
la n
orm
ativ
a de l
a
herr
am
ient
a.
Otr
as a
pli
caci
on
es d
e u
so In
stit
uci
on
al
141
9.3.3 Active Directory
El Active Directory del INS contempla una estructura jerárquica definida por un
dominio raíz (PlaceHolder) y tres dominios adicionales ubicados en un segundo
nivel, con la misma jerarquía. Dichos dominios son, el de GERENCIA,
SEGUROSW2K el cual contempla todo oficinas y Centrales y las distintas
SEDES a lo largo del país, y el dominio de AUDITORIA. La administración de
este último es efectuada por dicha entidad.
9.3.3.1 Esquema de Autenticación del Active Directory
El esquema de Autenticación del Active Directory se define de la siguiente
forma:
Nomenclatura de usuario
Iniciales del Departamento en el que se labora, concatenado con un dígito y
las iniciales del nombre y apellidos del funcionario.
La clave debe tener mínimo 6 caracteres, considerando la inclusión de al
menos una mayúscula, una minúscula y un número. La contraseña, caduca
cada 45 días
9.3.3.2 Esquema de Alta Disponibilidad del Active Directory
El esquema de alta disponibilidad para el Active Directory se encuentra
establecido mediante la utilización de un esquema redundante soportado por
dos servidores principales que administran los roles de infraestructura PDC y
RID del dominio SEGUROS.
A su vez se cuenta con 26 servidores adicionales, ubicados en las distintas
SEDES del INS, los cuales administran dichos roles en caso de presentarse
alguna falla.
La figura 23 muestra el diseño del directorio activo de la Institución, detallando
el total de controladores de dominio que lo contienen.
14
2
Fig
ura
No
24
Dis
eño
del
Dir
ecto
rio
Ac
tivo
de
l IN
S
143
9.4 Estudio de Factibilidad
9.4.1 Estudio Técnico
De conformidad con las disposiciones tendientes al proceso de contratación
Administrativa asociadas al tipo Licitación Pública, se procede a remitir a ese
despacho la solicitud de Publicación de Cartel para optar por la Adquisición de
2500 licencias de Single Sign On para el Instituto Nacional de Seguros.
9.4.1.1 Antecedentes
Actualmente, el INS maneja una diversidad de aplicaciones para la
administración de los seguros en las plataformas AS/400, UNIX y WINDOWS,
situación que implica el manejo de tantas claves como sistemas se deba
manipular.
Dicha situación a llevado a la Institución a enfrentrar problemas tales como:
1. Inseguridad en la administración de claves: Utilización de mecanismos
manuales para recordar las claves de acceso o utilización de la misma
clave de acceso para acceder a mùltiples aplicaciones.
2. Utilización de una misma clave entre varios funcionarios, con los
problemas de seguridad que dicha práctica conlleva.
3. Recurso Humano técnico dedicado en más de un 50% del tiempo, a
labores de administración de claves.
4. Retrasos por parte de los usuarios finales, en la atención de clientes.
Concientes de las debilidades derivadas de la deficiente administración de
claves de acceso por parte del usuario final,además de los elevados costos en
que incurre la Institución por concepto de atención de incidencias ligadas al
reinicio o reactivación de claves, se considera necesario adquirir una solución
que permita, mediante una única clave de acceso, acceder a todas las
aplicaciones con que se debe interactuar.
144
9.4.1.2 Finalidad Pública que se pretende satisfacer con el concurso
El INS cuenta con 3 plataformas principales: AS/400, UNIX y Windows, dichas
plataformas albergan alrededor del 80% de los Sistemas que administran el
negocio de la Organización, los cuales se describen a continuación:
Usuarios por plataforma y por Aplicación
Plataforma AS/400
Sistema Usuarios activos
Point Life 574
Sistema Administrador de Seguros de Vida Dólares 675
Sistema de Administración de Seguros de Incendio Dólares 178
Sistema de Administración de Seguros Riesgos del Trabajo 719
Sistema de Administración Otros Seguros 534
Sistema de Pago Exámenes Médicos 150
Sistema de Administración del Seguro de Automóviles 385
Vida Tradicional 1695
Point General 1633
Sistema de Aseguramiento del Seguro INSMEDICAL 60
Sistema de Planillas de Deducción Mensual 1200
Total Usuarios por Plataforma 7803
Usuarios por plataforma y por Aplicación
Plataforma AIX
Sistema Usuarios activos
SICSOA Durante el periodo de Cobro del Marchamo es de 1350 (Noviembre a Enero). A partir de Febrero y hasta Octubre inclusive es de 200 usuarios
PECSOA 498
SIMA 2082
SIFA 450
Total Usuarios por Plataforma Varía entre 4380 y 3230
145
Usuarios por plataforma y por Aplicación
Plataforma Windows - Web
Sistema Usuarios activos
Banca Seguros (Web) 772
Sistema Preventico Empresarial 1000
Sistema Integrado de Control de Inspecciones 200
Sistema de Administración de Cartera Seguros Marítimos 100
Sistema Estadístico de Producción 50
Sistema de Administración de Cuentas Estratégicas 200
Sistema Consecutivo de Inspecciones 100
Sistema de Control y Administración de Requerimientos 90
Inspección (reportes accidentes/Citas de Valoración/Control Valijas/Asignación de Inspectores)
211
Casos 230
Liquidaciones del BackOffice 62
Sistema de Carga Masiva de Asegurados 110
Sistema de impresión de condiciones generales 1000
Sistema de impresión de condiciones generales y particulares
1000
Sistema Base Unificada de Clientes (Web) 1000
Sistema Intranet Operaciones 100
Sistema de Administración y Control. Modificaciones en Sistema Productivo
100
RIGEL (Workflow Accidentes y Salud) 60
Sistema de Comercialización de Intermediarios (Web) 745
Total Usuarios por Plataforma 7130
Usuarios por plataforma y por Aplicación
Otras herramientas de Uso Administrativo
Aplicación Usuarios activos
INTERNET 1500
CORREO INSTITUCIONAL 2200
Total Usuarios por Plataforma 3700
De acuerdo a lo anterior, se ha identificado que, especialmente en las SEDES,
los usuarios de atención de público deben interactuar con al menos 5
aplicaciones distintas para desarrollar las actividades principales tendientes a
146
la atención de clientes, además de la utilización de otras aplicaciones de uso
empresarial como son el correo de Lotus Notes e Internet para gestionar sus
labores diarias.
El Single Sign On, es una solución que permite mediante una única clave de
acceso, acceder a todos los sistemas y aplicaciones que requieren su inclusión
para ser utilizadas.
Aunado a ello, dicha solución utiliza un esquema de auto servicio, el cual
permite que en caso de olvido de clave, el mismo usuario pueda realizar por el
mismo, ciertas actividades para reactivar su clave de acceso, reduciendo con
ello, la necesidad de un tercero para atender las incidencias derivadas del
olvido de claves.
Con el fin de minimizar la problemática en cuanto al manejo y administración de
passwords asignados a usuarios, se requiere adquirir 2.500 licencias Single
Sign – On para las plataformas AS/400, UNIX y WINDOWS permitiendo a
través de ello:
6. Reducir significativamente los costos en los que actualmente incurre
la organización por concepto de reactivación de claves.
7. Agilizar considerablemente los tiempos de acceso a varias
aplicaciones.
8. Aprovechar el recurso humano técnico en otros proyectos de mayor
impacto para la Institución.
9. Mejorar la atención al cliente.
10. Reducir considerablemente los problemas de seguridad existentes
actualmente en relación a la forma de administración de claves por
parte del usuario final.
147
9.4.1.3 Estudio costo – beneficio
Actualmente, el Instituto Nacional de Seguros, incurre en fuertes gastos por
concepto de atención de incidencias derivadas de la administración de claves
de acceso a las diferentes aplicaciones.
El INS cuenta con aproximadamente 2800 funcionarios que ingresan
diariamente a la red Institucional. De estos, aproximadamente 2500 deben
interactuar con distintas aplicaciones para desarrollar su actividades laborales.
Un amplio porcentaje de dichos funcionarios (aproximadamente un 60%),
requieren atender tanto a clientes externos como internos, mediante la
utilización de varios Sistemas y aplicativos empresariales.
A continuación se expone una evaluación de los costos derivados de la
administración actual de contraseñas en el INS:
Usuarios administrados: 2500
Cuentas promedio por usuario: 5
Costo asociado a la asistencia técnica por
Concepto de Administración de usuarios: $10 ó su equivalente en colones: ¢5.230
Total de cuentas administradas 12.500
Número de veces en promedio que un
Usuario olvida su contraseña al año: 6
Número de veces en promedio, al año, que
Un Usuario solicita reseteo de contraseña: 15
148
Costos derivados de la atención de
Incidencias (reseteo o reactivación
de claves): ¢109.830 por usuario,
Aproximadamente ¢274,575.000
9.4.1.3.1 Beneficios de adquirir una solución Single Sign On
Para la valoración de los beneficios económicos, se consideraron las
propuestas erogadas por los siguientes Proveedores:
Empresa Costos por licencias
Mantenimiento a partir del 2do año
GBM $180.000 $38.000 CR Conectividad $192.000 $40.000 Promedio de Costos $186.000 $39.000
Considerando lo anterior, los costos en que deberá incurrir el INS para el
primer año, contemplando la adquisición de 2.500 licencias y el mantenimiento
de las mismas sería de:
Resumen de Inversión(Precios de referencia) 1er Año
Solución tipo Single Sign – On – Licenciamiento (2500 licencias) $186.000,00
Mantenimiento $0.00
Inversión estimada $186.000,00
En colones al tipo de cambio ¢523.00 ¢97.278.000,00
Para el segundo y tercer año, la inversión sería de:
Resumen de Inversión(Precios de referencia 2do año 3er año
Solución tipo Single Sign – On – Licenciamiento
(2500 licencias)
$39.000,00 $39.000,00
Mantenimiento $0.00 $0.00
Inversión estimada $39.000,00 $39.000,00
En colones al tipo de cambio ¢523.00 ¢20.397.000,00 ¢20.397.000,00
149
Los costos versus el retorno de la inversión derivado de la implementación de
esta solución serían:
Resumen de Inversión(Precios de
referencia
1er año 2do año 3er año
Usuarios 2.500
Costos de TI $525.000,00 $525.000,00 $525.000,00
Costos de solución por año $186.000,00 $39.000,00 $39.000,00 Ahorro por implementación de una solución tipo Single Sign On
$339.000,00 $486.000,00 $486.000,00
Ahorro acumulativo por año $339.000,00 $825.000,00 $1.311.000,00 En colones al Tipo de cambio ¢523,00
¢177.297.000,00 $431.475.000,00 ¢685.653.000,00
El cuadro anterior lo muestra, durante el primer año, los costos en que deberá
incurrir el INS por la adquisición de las licencias serían de $186.000.
Considerando que los costos por concepto de administración de claves de
acceso alcanzan aproximadamente $525.000 por año, con la implementación,
el ahorro sería de $339.000.
Para el segundo año, el ahorro por inversión sería de $486.000, pues
únicamente se incurriría en costos por $39.000 por concepto de actualización
de licencias. El retorno de la inversión sería de aproximadamente $825.000,
considerando el ahorro acumulativo de $339.000 mas $486.000
Finalmente, para el tercer año, el retorno de la inversión sería
aproximadamente de $1.311.000, considerando el ahorro acumulativo de
$825.000 más $486.000.
150
9.5 Cartel
Departamento Proveeduría
PROV-XXX-2008
xx de junio del 2008
CONTRATO DIRECTO XXXX- (2008CD-0080xx-UC)
PLIEGO DE CONDICIONES
“ADQUISICIÓN Y MANTENIMIENTO DE LICENCIAS SOFTWARE”
El Instituto Nacional de Seguros, recibirá ofertas por escrito hasta las 00:00
horas del xxx de junio 2008, con todo gasto pagado e impuestos incluidos,
para lo siguiente:
CAPÍTULO I: ASPECTOS TÉCNICOS
I. DESCRIPCIÓN DEL REQUERIMIENTO:
RENGLON CANTIDAD DESCRIPCIÓN
Único 2500 Licencias de Software Single Sign On
(Características en Anexo 1)
II. EVALUACION
1. PRECIO (PUNTAJE MAXIMO = 100)
Se asignarán 100 puntos a la oferta de menor precio. Para las restantes ofertas se utilizará la siguiente fórmula:
151
P = (P1 / P2) * 100, donde:
P = Puntaje asignado
P1 = Menor precio ofertado
P2 = Precio de la oferta por evaluar
100 = Puntaje máximo por obtener
III. CONDICIONES TÉCNICAS PARA EL OFERENTE
A. El Oferente deberá indicar si existen observaciones, anomalías o limitaciones del producto, expresadas por otros clientes al fabricante, para que sean tomadas en cuenta y valoradas por el Instituto. De lo contrario, se asumirá que se ofrece un producto garantizado. De demostrarse situaciones contrarias, el Oferente que resulte Adjudicatario está en la obligación de realizar las correcciones que sean necesarias y entregarlas al Instituto sin costo adicional para este.
B. Será obligación del eventual adjudicatario, contemplar los costos por la aportación de los manuales de usuario del software ofrecido. Debe señalar el medio de presentación, sea archivo digital o impreso y los costos para cada modalidad. Es potestad del INS decidir la modalidad por la que optará.
IV. REQUISITOS TECNICOS PARA EL OFERENTE
A. El Oferente debe indicar el costo unitario del suministro y otros cargos, tales como módulos opcionales, descuentos, capacitación, impuestos, instalación, diseño, entre otros.
B. El Oferente deberá detallar el nombre del programa producto y la oferta en plaza, incluidos todos los impuestos y gastos que lo afecten (indicados por separado).
C. El Oferente debe indicar el costo anual por el concepto de mantenimiento y actualización del producto de tal forma que permita a la administración contar con el servicio de soporte y renovación del software.
D. Será obligación del Oferente, contemplar los costos por la aportación de los manuales de usuario del software ofrecido. Debe señalar el medio de presentación, sea archivo digital o impreso y los costos para cada modalidad. Es potestad del INS decidir la modalidad por la que optará. Si omite costos, se entenderá que los mismos están contemplados en el precio de las licencias.
152
E. El oferente deberá realizar una visita a las Oficinas Centrales del INS, Departamento de Gestión de Servicios de Tecnología y Telecomunicaciones para aclarar detalles de la instalación de la Solución que se cotiza. Esta visita es requisito indispensable para participar y deberá presentar constancia de dicha visita en su oferta.
V. CONDICIONES TECNICAS PARA EL ADJUDICATARIO
c. Instalación y Configuración: El Adjudicatario deberá designar un recurso técnico que realice la instalación y configuración del producto, la cual se hará en horas o días fuera de la jornada ordinaria salvo que las condiciones permitan realizar dichas tareas durante la jornada ordinaria de la Institución.
d. Inducción: El Adjudicatario debe incluir una inducción que contemple:
2. Retroalimentación en el proceso de implementación de la Solución por un total de 30 horas. Dicha retroalimentación deberá ser brindada por un especialista en labores de implementación de soluciones del tipo requerido por el presente Cartel y será brindada al menos a 2 técnicos designados por el Departamento de Gestión de Servicios de Tecnología y Telecomunicaciones para tales efectos. Además, debe indicar las condiciones bajo las cuales se impartirá la inducción (instalaciones, horario, equipo, lugar, entre otros). La misma se debe hacer en un plazo no mayor a 15 días naturales posteriores a la instalación y configuración del software y preferiblemente en las instalaciones del INS. Deberá aportarse el nombre de al menos 2 empresas donde se haya realizado la implementación de soluciones Single Sign - On.
e. El mantenimiento y actualización del producto inicia una vez recibidas a satisfacción las licencias.
f. El Adjudicatario deberá recomendar la configuración idónea desde el punto de vista de seguridad del Sistema Operativo donde se instalará el Single Sign – On, según lo requerido por el producto a instalar. Dicha recomendación deberá documentarse y entregarse formalmente al Área de Infraestructura del Departamento de Gestión de Tecnología y Telecomunicaciones para ser evaluado y aprobado.
153
VI. REQUISITOS PARA EL ADJUDICATARIO
D. Catálogos: El Oferente debe presentar catálogos y/o literatura técnica y manual de usuario, junto con la licencia de software. La literatura debe aportarse en idioma español o en otro idioma, pero en este caso se requerirá que presente la traducción bajo responsabilidad del Oferente, conforme el Artículo Nº 62 del Reglamento a la Ley Contratación Administrativa.
E. El Adjudicatario deberá proveer un juego de medios de instalación en disco compacto, éstos deben ser originales y deberán estar acompañados por el Key de activación del producto.
F. Al momento de la entrega, el Adjudicatario debe presentar un certificado de licenciamiento, en el cual se indique que dichas licencias son propiedad del INS. Adicionalmente, se debe indicar el esquema de licenciamiento aplicable a cada uno de los productos (perpetuo/derecho de uso) y la fecha de fin. Dicho certificado debe ser emitido por el fabricante.
G. Los servicios que debe contemplar el Adjudicatario respecto al servicio de mantenimiento son los siguientes:
• Actualización del productos con nuevas versiones:
1. El Adjudicatario deberá remitir información del producto actualizado, con mejoras de funcionalidad, versiones generales de mantenimiento, “patches”, arreglos, alternativas de solución y actualizaciones a las normas internacionales cada vez que se presenten. Los datos deben ser remitidos a los funcionarios que el Departamento de Gestión de Servicios Tecnológicos y de Telecomunicaciones designe para tales efectos.
2. Es potestad del Instituto la Selección de las actualizaciones, versiones de mantenimiento, arreglos, alternativas de solución.
3. Proveer medios de cada una de las actualizaciones en disco compacto, éstos deben ser originales y deberán venir acompañados por el “Key” de activación del producto o bien proveer acceso al sitio de Internet, desde el cual se puedan bajar las actualizaciones.
4. Si el Instituto lo considera conveniente, podrá ingresar en forma directa a los servicios de asistencia técnica interactiva o tener la opción de remitir vía correo electrónico las consultas o incidencias en torno al producto adjudicado sin necesidad de llamadas telefónicas.
5. Indicar el número de teléfono y dirección electrónica al cual podrá el Área usuaria canalizar las incidencias en caso de avería o falla del producto.
154
6. El Adjudicatario entregará los medios, actualizaciones, parches o cualquier otro componente relacionado con el mantenimiento y actualización del producto en las instalaciones del INS sin que ello represente erogaciones para el Instituto por concepto de impuestos, desalmacenaje, transporte u otros.
H. El Instituto podrá realizar copias del producto para utilizarlas durante la instalación o actualización del software y evitar que el original se dañe por el uso.
CAPITULO II: ASPECTOS FORMALES
I. ASPECTOS GENERALES DE LA EVALUACIÓN
1. Base de calificación: La calificación se realiza en base cien, lo cual implica que la máxima cantidad de puntos que puede obtener un oferente es de cien.
2. El puntaje mínimo para adjudicar: El puntaje mínimo que debe obtener un Oferente para ser posible Adjudicatario es de (100) Cien Puntos.
3. Selección del Adjudicatario: El presente concurso se adjudicará a la oferta mejor calificada.
4. Criterio de redondeo: Para los cálculos de puntaje que impliquen el manejo de decimales se utilizará el truncar en los dos primeros decimales.
5. Criterios de desempate: En caso de presentarse empate en la calificación de una oferta se utilizará como criterio para el desempate, la oferta que indique el menor plazo de entrega.
6. La Administración se reserva el derecho de distribuir la adjudicación entre varias firmas, cuando fuere técnica y legalmente divisible y hubiere razones atendibles que justifiquen tal proceder según los intereses de la Administración.
7. Ofertas Alternativas: Se evaluarán las ofertas alternativas únicamente cuando tanto la propuesta base como la alternativa cumplan con las condiciones indicadas en el presente cartel.
8. Mejoras y descuentos: Se aceptaran mejoras y descuentos (por volumen,
pronto pago, etc.) sobre los precios cotizados, en tanto no estén condicionados a la adjudicación del concurso.
155
9. Tipo de cambio a utilizar para comparación de ofertas: En caso que el Oferente cotice en divisa, para efectos de la evaluación de ofertas se utilizará el tipo de cambio de venta del dólar referencia Banco Central de Costa Rica, vigente el día de apertura de las ofertas.
II. CONDICIONES GENERALES DEL OFERENTE
A. El Oferente debe cumplir con lo que corresponda, según lo estipulado en los artículos N°25 al 36 y del Nº61 al 77 inclusive del Reglamento a la Ley de Contratación Administrativa.
B. Los contratos a ejecutar en el país, cuyas propuestas provengan de empresas extranjeras, debe incorporar una declaración de someterse a la jurisdicción y tribunales nacionales para todas las incidencias que de modo directo o indirecto puedan surgir del contrato, con renuncia a su jurisdicción. (Art. N°64 RLCA).
C. El Oferente está obligado a cotizar todo el objeto, salvo que se trate de líneas independientes entre sí, en cuyo caso podrá cotizar en las de su interés, sin que sea necesario que el cartel lo autorice. Se prohíbe la cotización parcial de una línea. (Art. N°66 RLCA).
D. Registro de Proveedores: El Oferente debe estar inscrito en el Registro de Proveedores del INS al menos un día antes de la fecha y hora de la apertura, a fin de realizar con mayor agilidad el trámite de presentación de la garantía de participación, registro de la oferta y demás gestiones del concurso. Para tal efecto, el interesado debe aportar los requisitos solicitados en el Reglamento del Registro de Proveedores, cuyo detalle puede ser obtenido gratuitamente en el Departamento Proveeduría o en el sitio de Internet www.ins-cr.com. (Artículo Nº98 RLCA).
Dicha documentación debe entregarse directamente en Área de atención al Público del Departamento Proveeduría, con la indicación que se aporta para participar en el presente concurso.
E. La Administración estudiará todas las ofertas presentadas, únicamente de aquellos proveedores invitados, quienes en caso de que no se encuentren inscritos en el Registro de Proveedores, deben lograr esa inscripción antes de la apertura de ofertas. (Artículo N°98 RLCA).
F. Vigencia de las ofertas: Se entenderán vigentes por el plazo máximo para emitir el acto de adjudicación (Artículo 67 RLCA), a partir de la apertura de ofertas, salvo indicación contraria de manera expresa en la oferta.
156
G. Modificaciones y correcciones: Toda corrección, modificación o anotación en la oferta, debe ser realizada mediante nota aparte y debe entregarse en el Departamento Proveeduría antes de la fecha y hora prevista para la apertura de ofertas. Se desestimará la oferta que contenga algún tipo de corrección, borrón, anotación o tachadura en algún aspecto relevante de la misma.
H. El Oferente podrá concurrir por sí mismo o a través de un representante de casas extranjeras, en cuyo caso, debe hacer indicación expresa de tal circunstancia en la propuesta.
I. Se presume que quien suscribe la oferta cuenta con la capacidad legal para ello. La acreditación se reserva para el Adjudicatario en una etapa posterior. (Art. 18 RLCA).
J. Impuestos: Los Oferentes deberán señalar claramente los impuestos a que está afecto el servicio e indicar si están o no incluidos en el precio. Caso contrario se aplicará lo dispuesto en el artículo Nº25 del Reglamento a la Ley de Contratación Administrativa.
K. Plazo para adjudicar: El acto de adjudicación será emitido en un plazo que no podrá ser superior al doble del plazo fijado para recibir ofertas. Para calcular este plazo el Oferente debe contemplar los días hábiles contados desde el día siguiente de la publicación o recibo de la invitación a participar, hasta la fecha de apertura (inclusive) y multiplicar esa cantidad de días hábiles por dos (2).
No obstante, el Instituto con fundamento en el artículo N°136 del Reglamento a la Ley de Contratación Administrativa, posee el derecho de prorrogar este plazo, en caso de requerirse, de lo cual dará aviso escrito a las partes.
L. El Oferente podrá cotizar precios unitarios y totales. Si la sumatoria de los precios unitarios excede el precio total, la oferta se comparará con el mayor precio. La Administración se reserva el derecho de adjudicar parcial, total o declarar desierto el presente concurso. Según lo dispuesto en el artículo N°27 del Reglamento a la Ley de Contratación Administrativa.
M. Forma de pago: trámite 10 días naturales posteriores a la presentación de la factura y recibido el producto a satisfacción del INS. El Instituto Nacional de Seguros preferentemente realiza la cancelación de bienes y servicios a través del sistema S.I.N.P.E; por ello el Oferente debe indicar en su oferta el número de cuenta cliente (SINPE 17 dígitos) y el nombre del banco en el que desea sean depositados los pagos por medio de transferencia electrónica, con la sola indicación de esa información se tomará por cierta y válida y el Oferente asumirá la responsabilidad si la información proporcionada resulta incorrecta.
157
En caso de pago por SINPE, regirá lo dispuesto en la Ley N°8204. Si no dispone de Cuenta Cliente el pago se realizará mediante trámite de cheque a 10 días naturales, posteriores a la presentación de la factura y una vez recibido el servicio a satisfacción. Según lo dispuesto en los artículos N°33 y 34 del Reglamento a la Ley de Contratación Administrativa.
Ofertas en divisas se cancelarán en colones al tipo de cambio de referencia para la venta del colón con respecto al dólar calculado por el Banco Central de Costa Rica, vigente en la fecha efectiva del pago, el cual no podrá ser superior al límite del plazo de entrega ofrecido. (Oficio DAGJ-01411-2005 –referencia 06193-, de la Contraloría General de la República).
Se tramitarán para el pago respectivo únicamente las facturas cuyos montos coincidan con el total adjudicado, por lo que cualquier atraso en el trámite de pago será responsabilidad del Adjudicatario.
N. Vigencia del contrato: Será por un año, las partes por mutuo acuerdo podrán renovar el contrato por períodos iguales, hasta un máximo de tres (3) renovaciones. El acuerdo de renovación deberá ser suscrito formalmente por las partes con al menos un mes de antelación a la fecha de vencimiento de la anualidad respectiva.
No obstante, lo anterior el Instituto se reserva el derecho de aplicar en cualquier momento lo dispuesto por los artículos N°202 al 208 del Reglamento a la Ley de Contratación Administrativa.
III. REQUISITOS QUE DEBEN CUMPLIR LOS OFERENTES
A. Presentación de la oferta: En el Área de atención al Público del Departamento Proveeduría, ubicado en el piso Nº8 del edificio de Oficinas Centrales, a más tardar a la fecha y hora señalados, para tal efecto, prevalece la hora indicada en el reloj marcador de este Departamento. La oferta debe presentarse en el idioma español, papel común, con dos copias adicionales completas del original, en sobre cerrado debidamente identificado con el número y nombre de la contratación.
B. Lugar de notificaciones: El Oferente debe indicar en su oferta un lugar cierto para recibir notificaciones del presente concurso; teléfono, facsímil, correo electrónico, dirección física. (Artículo 140 RLCA).
C. Con la sola presentación de su plica se garantiza: Calidad del servicio.
158
D. Cédula: El Oferente debe indicar en su oferta su número de cédula jurídica o personal, según sea el caso y adjuntar fotocopia de la misma.
E. Plazo de entrega: El plazo de entrega máximo será de 5 días naturales y para todos los efectos legales se tendrá por iniciado al día siguiente a la notificación de la compra o aviso de entrega.
Para efectos del plazo de entrega será considerado en días naturales, el plazo de entrega indicado como inferiores a un día, cero días o inmediato, se entenderá como un día hábil para efectos de valoración y ejecución.(Art. 68 RLCA).
F. Declaraciones:
1. El Oferente nacional debe aportar declaración jurada, que no le alcanza ninguna de las prohibiciones que prevén los artículos N°22 y 22 bis de la Ley de Contratación Administrativa.
2. El Oferente nacional debe aportar declaración jurada que se encuentra al día en el pago de los impuestos nacionales. (Art. 65 RLCA).
3. El Oferente nacional jurídico debe aportar certificación original y actualizada (a la fecha de apertura) de la personería legal y la naturaleza y propiedad de las acciones. Cuando la propiedad de las acciones esté en poder de una persona jurídica, igualmente debe indicarse la propiedad de las acciones. Si esta certificación fue aportada para su incorporación al Registro de Proveedores, debe indicarse así en la plica y señalar si se mantiene invariable. (Art. 65 RLCA).
4. El Oferente nacional en cumplimiento del Artículo Nº74 de la Ley Constitutiva de la Caja Costarricense de Seguro Social, debe presentar junto con su oferta una certificación vigente de la C.C.S.S, en la que se indique que está al día en el pago de las cuotas obrero patronales, como patrono o trabajador independiente.
En el caso que sea trabajador independiente y no esté inscrito ante la CCSS, deberá inscribirse como tal y presentar la certificación respectiva en su oferta. En caso que no aporte la certificación, el INS procederá a verificar la información por medio de la página web http://www.info.ccss.sa.cr/.
Será causal de desestimación de la oferta si el Oferente está moroso a la fecha de apertura del concurso y se verifica esta situación en la página web dicha o así conste en la certificación que aporte.
159
Los patronos y personas que realicen total o parcialmente actividades independientes o no asalariadas, deben igualmente estar al día en el pago de sus obligaciones.
En caso que el Oferente no se encuentre inscrito como patrono o trabajador independiente ante la C.C.S.S, la Administración le solicitará explicación, la que en caso de resultar insatisfactoria de acuerdo a los lineamientos establecidos por la C.C.S.S., provocará la exclusión del concurso y la denuncia ante las autoridades correspondientes de cobro de la C.C.S.S. (Art. 65 RLCA).
IV. CONDICIONES GENERALES DEL ADJUDICATARIO
A. Al Adjudicatario, se le retendrá el 2% por concepto de Impuesto sobre la Renta, sobre adjudicaciones superiores a ¢227,000.00. (doscientos veintisiete mil colones exactos).
B. Multas: Por cada día natural de atraso en la entrega del servicio, se cobrará un 0.1%, hasta un máximo del 25% del total atrasado. (Artículo Nº48 RLCA).
C. Responsabilidad patronal:
1. El Adjudicatario debe asumir todas las responsabilidades referentes a los derechos laborales de sus trabajadores, que en calidad de patrono o trabajador independiente, le corresponden, de acuerdo a lo dispuesto por el Decreto Ejecutivo Nº11430-TSS, publicado en “La Gaceta” Nº89 del 12 de mayo de 1980, razón por la cual debe ajustarse a las cláusulas: Garantía de cumplimiento, Retenciones y Responsabilidad Solidaria, a que se refiere dicho Decreto. Además debe cubrir derechos como póliza de Riesgos del Trabajo, seguro social, etc. Por tanto, queda obligado a presentar ante el INS los comprobantes respectivos durante la ejecución del contrato, los que pueden ser requeridos en cualquier momento.
2. De conformidad con el artículo N°74 de la Ley Constitutiva de la Caja Costarricense de Seguro Social N°17 del 22 de octubre de 1943, reformado por Ley N°7983 (Ley de Protección al Trabajador) del 18 de febrero de 2000, se tendrá como incumplimiento de contrato que el Adjudicatario, en caso de personas jurídicas o trabajador independiente, adeude las obligaciones con la seguridad social, con todas las consecuencias que esto conlleva.
3. El Adjudicatario debe asumir todos los daños a personas o cosas, que se produjeran con ocasión o motivo del trabajo realizado, siempre y cuando las razones sean imputables al Instituto.
160
D. Queda entendido que no existe relación laboral entre el INS y el Adjudicatario o los empleados contratados por éste.
V. REQUISITOS QUE DEBEN CUMPLIR LOS ADJUDICATARIOS:
A. Inicio del contrato: Un día hábil posterior a la formalización contractual, verificación interna (en caso de adjudicaciones menores a ¢42,300,000.00), refrendo interno por parte de la Dirección Jurídica del INS (en caso de adjudicaciones iguales o superiores a ¢42,300,000.00) o refrendo externo por parte de la Contraloría General de la República, en adjudicaciones iguales o superiores a ¢304,000,000.00, orden de compra o pedido, según corresponda. (Art. 192 RLCA).
Se tendrá por perfeccionada la relación contractual entre la Administración y el Adjudicatario cuando el acto de adjudicación o readjudicación adquiera firmeza y, en los casos que se exija la constitución de la garantía de cumplimiento, ésta sea válidamente otorgada. (Art.188-190).
B. Constancia de la C.C.S.S.: El Adjudicatario deberá aportar antes de iniciar la ejecución del contrato o al retiro de la orden compra, la certificación original emitida por la Caja Costarricense de Seguro Social, donde se indique que se encuentra al día en el pago de sus obligaciones obrero patronales con esta Institución.
C. Facturas: El Adjudicatario debe cumplir con lo dispuesto por el artículo N°18 del Reglamento de la Ley General del Impuesto sobre las Ventas.
D. Garantía de Cumplimiento: Será responsabilidad del (los) Adjudicatario (s) presentar la garantía, dentro de los cinco (5) días hábiles siguientes a la firmeza del acto adjudicado, el cual se produce según los plazos estipulados en el Reglamento a la Ley de Contratación Administrativa.
En caso de no aportar dicha garantía la Administración iniciará el proceso de readjudicación conforme a lo establecido en el artículo N°191 del Reglamento a la Ley de Contratación Administrativa.
1. Monto: 5% del monto total adjudicado.
2. Vigencia: Debe extenderse hasta por dos meses adicionales (44 días hábiles) a la fecha de la recepción definitiva del objeto contractual.
3. Forma de rendir las garantías: Debe ajustarse a lo estipulado en el artículo N°42, del Reglamento a la Ley de Contratación
161
Administrativa. Sin embargo, no se aceptarán garantías emitidas por el INS, por ser el Ente Licitante.
E. Presentación de la Garantía de Cumplimiento: La garantía de cumplimiento deber ser depositada según las siguientes posibilidades:
1. Cuando se trate de documentos de valor: garantías bancarias, bonos y/o certificados de depósito, cheques certificados o de gerencia: el Adjudicatario debe presentar, el documento directamente o en la Custodia de Valores, ubicada en el Mezanine I extremo derecho de la Sección de Cajas del Edificio de Oficinas Centrales.
2. Horario de la custodia de valores: El Adjudicatario debe considerar que para el depósito o retiro de documentos presentados como garantías de cumplimiento el horario será de lunes a viernes de 8:00 a.m. a 1:00 p.m.
3. Cuando se trate de dinero en efectivo (monedas y/o billetes): el Adjudicatario debe presentar directamente en el Departamento Proveeduría, ubicado en el Octavo piso para la confección del recibo correspondiente y luego pasar a la Sección de Cajas, en el Edificio de Oficinas Centrales.
F. Entrega de documentos: El Adjudicatario debe entregar los siguientes documentos en el Departamento Proveeduría, dentro de los cinco (5) días hábiles siguientes a la firmeza del acto adjudicado, el cual se produce según los plazos estipulados en el Reglamento a la Ley de Contratación Administrativa:
1. Copia de la garantía de cumplimiento cuando ésta sea depositada en la Custodia de Valores.
2. Certificación de personería jurídica: Las personas jurídicas que resulten adjudicatarias por montos iguales o superiores a los ¢42,300,000.00, deben presentar una certificación notarial vigente de la personería jurídica y certificación de la naturaleza de acciones.
3. Comprobantes de pago de las Cuotas Obrero Patronales (CCSS).
G. Acta de recepción: El Adjudicatario o su Representante deberá suscribir el acta de recibo de los servicios, al momento de la entrega conforme lo establece el artículo Nº195 del Reglamento a la Ley de Contratación Administrativa.
H. Puesto el suministro en: El producto de software y documentación asociada deberá ser entregado en el Departamento Soporte Técnico de la Dirección Informática del INS en el piso 10 de Oficinas Centrales ubicadas en San José, Costa Rica calle 9 avenida 7 al responsable que dicho Departamento designe para tales efectos..
162
La oferta podrá formularse en el mismo orden de numeración indicado anteriormente, señalando en cada caso el número de requisito y/o condición que se conteste.
Los aspectos no contemplados anteriormente, se regirán por lo dispuesto en la Ley de Contratación Administrativa, el Reglamento a la Ley de Contratación Administrativa y normas conexas que sean aplicables.
Atentamente,
ORIGINAL FIRMADO POR:
MAP. Elizabeth Castro Fallas
Jefe
Cc: Dirección Informática Expediente CD A080xx(2008CD-0080xx-UC) Consecutivo
**DEA**
163
Anexo 1
2500 Licencias de Software tipo Single Sign On
Se requiere adquirir 2500 licencias de Software Single Sign On, las cuales
deben tener las siguientes características:
1. Login Único de Conexión (Single Sign - On). La Solución debe permitir la
implementación de un login único para la autenticación de todos los
usuarios en las principales plataformas con que cuenta el INS (AS/400,
UNIX, WINDOWS), además del Correo Institucional y demás aplicaciones
de desarrollo a la medida. Debe integrarse con el Control de Accesos y el
Directorio Activo (LDAP).
2. Administración de Usuarios. Debe proporcionar la Administración de
Identidades basada en Roles y debe soportar todas las plataformas que
conforman la Infraestructura tecnológica del Instituto.
3. Administración de Contraseñas. Integrado con el Directorio Activo y el
Login Único de conexión debe permitir la sincronización de contraseñas y
auto servicio de reseteo de contraseñas por parte del usuario final a través
de una interfaz web de fácil utilización.
4. Administración basada en Roles y Políticas. La solución debe permitir el
uso de roles y políticas de contraseña adaptadas a las políticas de la
Organización; para la asignación de permisos de acceso a los recursos
(Ejemplo: sistemas, aplicaciones, bases de datos).
5. Auditoría de rastreo de usuarios. La Solución debe contar con auditorias
que permitan establecer, quien, y cuando se ingresó a cualquier aplicación.
6. Esquema de seguridad. La solución debe contar con un esquema de
seguridad robusto que centralice las credenciales en un repositorio único
con niveles de seguridad y acceso fuertes.
164
7. Esquema de Alta Disponibilidad. La Solución debe integrarse al
esquema de Alta Disponibilidad definido por el INS para el Active
Directory.