Manual de migración

Guía para migrar los componentes software básicos de sistemas servidor y escritorio

La reimpresión de este documento, completo o en parte, está sujeta a aprobación del titular de los derechos.


Tabla de contenidos

1. Introducción
Sobre el proyecto
Sobre esta Guía
Cómo utilizar esta guía
Información para responsables de toma de decisiones
Recomendaciones generales
Migración por continuación y por sustitución
Futuros aspectos clave
Eficiencia económica
2. Aspectos clave de la guía de migración
Definiciones importantes
código abierto, software libre
Software propietario
Software comercial Linux
Migración por sustitución (o de reemplazo)
Migración por continuación
Caminos de Migración
Microsoft como situación de partida
Panorama del sistema con la migración por reemplazo
Panorama del sistema con migración continua (o por continuación).
Dependencias internas dentro del sistema Microsoft
Distribuciones Linux
Modelo de licencias
Fuentes de información
3. Descripción técnica de las fases de migración
Introducción
Sistema de ficheros
Perspectiva general
Windows NT 4
Servicios Web
Resumen
Fundamentos
Servicios web .NET
4. Evaluación de la eficacia económica
Introducción
Principios metodológicos
Análisis económico
Análisis de las ventajas
IT-WiBe 21 (recomendaciones sobre eficacia económica en los sistemas TI)
Evaluación de la eficacia económica
Matriz del coste de migración
Costes totales de la propiedad (TCO)
Comparabilidad
Nueva introducción vs. migración de sistemas.
La dimensión monetaria (operativa)
Dimensión estratégica
Debate macroeconómico
Debate microeconómico
Conjunto de resultados de la evaluación de la eficiencia económica
Recomendaciones de migración basándose en la evaluación de la eficiencia económica
Migración completa
Conclusiones
Gastos con diferentes escenarios de migración
Asunciones generales acerca de los gastos de migración
5. Recomendaciones de la migración
Afirmaciones de tipo general
El proceso de toma de decisiones
Recomendaciones generales
Migración de tipo "sustitución total"
Modelo de arquitectura
6. Autores y contribuciones expertas
Abreviaturas
Glosario
A. Apéndice WIBe (Recomendaciones de ejecucion de eficeincia economica para sistemas IT)
Resumen de recomendación de catalogos de analisis
Catalogo General de criterios, IT-WIBe21, para escenarios de migracion
Costes de desarrollo/introducción y beneficios de desarrollo
Costes y beneficios de la operación
Criterios de urgencia
Criterios de calidad/estrategia
Notas y explicaciones
Catálogo especial de criterios, IT-WiBe21, para objetos de migración
Explicación de los criterios adicionales
Introdución costes/beneficios (1.1)
Difusión / disponibilidad de entrenamiento (4.4.3)
Difusión/disponibilidad de software (4.6)
Seguridad en TI (4.7)

Lista de figuras

XXXfigura1. Contexto de sistema - situación de partida
XXXfigura2. panorama del sistema - migración por reemplazo.
XXXfigura3. panorama del sistema - migración continua
3.1. Entorno de trabajo Microsoft .NET

Lista de tablas

A.1. Costes y beneficios de la operación:
A.2.
A.3.
A.4.
A.5.
A.6. Penetración en el mercado
A.7. Soporte independiente
A.8. Disponibilidad de certificación de software

Capítulo 1. Introducción

 

Un producto sustituye a otro si ofrece a los clientes un incentivo para el cambio que sobrepasa los costes del cambio o que supera la resistencia al cambio. Un producto sustitutivo ofrece un incentivo al cambio si, comparado con su precio, ofrece a los clientes un valor superior que el producto que era utilizado previamente.

 
--M.E. Porter 

Sobre el proyecto

Difícilmente existe una afirmación que describa mejor la esencia del extenso debate público sobre el uso de software de código abierto que esta afirmación, relativamente simple, de este profesor de la Escuela de Negocios de Harvard sobre los fundamentos de la competitividad. Linux, como insignia del código abierto tiene una larga historia como (desde el punto de vista de la teoría de la competencia) “producto sustitutivo” establecido, mientras que otros productos, como MySQL o OpenOffice, todavía están a medio camino de conseguirlo. (Puede echarse de menos la presencia del clásico de OSS, Apache, en esta enumeración, pero debe notarse que los autores de esta guía consideran a este producto como el original, en lugar del sustituto).

El sistema operativo Linux™ es, en particular, uno de los pocos productos de software que a día de hoy registra ratios de crecimiento y que ya se utiliza exitosamente en el 40% de las compañías y organizaciones[1] alemanas, y esta tendencia todavía sigue aumentando. A la vista de este desarrollo, debería ser muy fácil contestar a la pregunta relacionada con los incentivos que desencadenaron el desarrollo de software de código abierto.

De todos modos, esta suposición no es cierta; al contrario: difícilmente hay otro asunto que sea tan controvertido en las industrias de la información y las comunicaciones como los pros y contras del software de código abierto. Considerando el hecho de que sólo las ventas anuales del sistema operativo Windows™ superan los 10000 millones de USD es, por tanto, fácil ver que el debate sobre las alternativas está influenciado por poderosos intereses económicos.

Se discutirán las características técnicas de los productos y los parámetros económicos de las alternativas comparadas, adicionalmente al hecho de que el modelo de licencia es único y adicionalmente, a las preguntas frecuentemente formuladas en relación con la influencia de este modelo en la capacidad de innovación del la industria de TI. Esto nos lleva a un estudio pluridimensional y por tanto inevitablemente complejo que está abierto a interpretaciones. Es más, los competidores (i.e. código abierto vs. Microsoft™) ya no son productos de software aislados, sino una plataforma casi completa con una larga variedad de software.

Un análisis objetivo y comprensible juega un papel clave en esta situación, que se ve determinada por los intereses más variados y un alto nivel de complejidad. Ese estudio debería contemplar no sólo las propiedades técnicas del software en cuestión sino también su uso futuro, en particular, el uso especifico financiero, estructural/organizacional y el marco político de referencia en la administración alemana.

Sobre esta Guía

El titulo de esta guía ya sugiere que, inicialmente e independientemente de la decisión general de introducir software de código abierto, el ciclo de vida del software de Microsoft™ requiere varias decisiones de migración. Un buen ejemplo es la eliminación progresiva del soporte para Windows NT™ que todavía es utilizado extensamente, con su sistema operativo sucesor requiriendo un acercamiento fundamental diverso hacia el diseño de dominios.

Para distinguir entre el reemplazo de este software por los productos de OSS y un cambio a las generaciones subsecuentes de los productos de Microsoft, los términos de reemplazo y continuidad en la migración son utilizados a menudo en esta guía. La guía de la migración se centra en recomendar el grado óptimo y económicamente razonable de la solución más que en apuntar a sustituir productos ya en uso.

La guía de la migración ha sido diseñada para los responsables a cargo de la planificación e implementación de las estrategias y proyectos de TI en la administración pública.

La primera parte (Capítulo 2. Aspectos clave de la guía de migración) ocupa el inicio de la situación del software IT que condujo al desarrollo de los planes de la migración y da una descripción de la arquitectura básica del software de Microsoft y de la plataforma alternativa basados en estándares abiertos/código abierto. El supuesto mapa del entorno del sistema muestra las funciones cubiertas por productos o soluciones concretas y visualiza las correlaciones entre el producto individual y las capas del software.

La segunda parte ( Capítulo 3. Descripción técnica de las fases de migración y Capítulo 4. Evaluación de la eficacia económica) trata la aplicación sobre la migración potencial o la nueva introducción de sistemas e infraestructuras. Las áreas de aplicación individuales del software se analizan desde un punto de vista técnico y comercial. Mientras que el análisis técnico se centra la identificación y la evaluación de soluciones alternativas a los productos de Microsoft™, el análisis comercial trata la pregunta de cómo el cambio de software se puede manejar en la manera más económica posible.

La tercera parte (Capítulo 5. Recomendaciones de la migración) contiene las recomendaciones de la migración para diferentes agencias públicas así como un resumen técnico y un análisis comercial.

Estas recomendaciones incluyen las ofertas concretas para las agencias públicas pequeñas, medianas, grandes y especializadas. Los pros y los contras de diversas trayectorias de la migración también son considerados. La tercera parte muestra también los factores críticos para el éxito de los proyectos de migración. Aunque reemplazar software no es generalmente algo nuevo, la experiencia de los proyectos de la migración realizados en la administración pública confirma que la introducción de los productos de software debe ser planeada cuidadosamente y que el éxito de estos proyectos es depende en gran medida de la preparación del personal implicado en la tarea de la migración.

Durante los meses de trabajo sobre esta guía de migración, llegó a ser de nuevo evidente que este tema es un campo muy dinámico y rápidos cambios. El número de paquetes de software disponibles bajo Linux™, bajo GLP y de naturaleza comercial, se incrementó visiblemente durante la duración de este proyecto. Esto también se aplica al número de fabricantes que no solamente expresaron su adscripción a la estrategia Linux™, pero quienes también lanzaron productos concretos o por lo menos un plan del lanzamiento. Además de grandes proveedores de software, tales como SAP™, Oracle™, Sun™ o IBM™, las compañías pequeñas y medianas de software están ofreciendo cada vez más un número creciente de aplicaciones especiales y de sistemas. Éste es un desarrollo positivo para los partidarios del código abierto que contribuye hacia la madurez y aumento de las ofertas de OSS por una parte, pero también incrementa la dificultad de mantener una descripción clara de qué objetivos han sido alcanzados.

Al final, se deja a los lectores que ellos mismos identifiquen los “incentivos del cambio” que se aplican a su situación específica. Los autores esperan que la guía de la migración sea un asistente bueno y fiable para las consideraciones técnicas y comerciales.

Cómo utilizar esta guía

La siguiente sección contiene una corta introducción de cómo utilizar la estructura interna de este documento. Diseñado para proveer al lector la ayuda en la navegación, de modo que puedan fácilmente encontrar el contenido relevante, ya que este volumen resulta algo pesado. La guía se dirige a dos grupos distintos. Un grupo se compone de los responsables a cargo de la planificación e implementación de las estrategias y proyectos de las TI. El segundo grupo lo forman los Administradores TI en las agencias públicas que estarán ciertamente muy interesadas en descripciones técnicas detalladas.

Recomendamos que ambos grupos lean la información siguiente.

Este capítulo termina con una sección específicamente para los responsables.

La sección titulada “información para los responsables” contiene un resumen del contenido y de los resultados más importantes de la guía de la migración en forma concisa. Ningún lector de esta guía de la migración debe saltar las primeras cuatro secciones del Capítulo 2. Aspectos clave de la guía de migración . Estas secciones contienen definiciones terminológicas que son importantes para el resto de la guía. Además, se describen los componentes del entorno subyacente a un proyecto de migración. También se describen los apartados migración por sustitución y migración por continuación.

Además, las explicaciones individuales en el Capítulo 3. Descripción técnica de las fases de migración comienzan con un resumen de los resultados de las explicaciones técnicas referidas, de modo que los responsables puedan obtener una descripción de los resultados y las explicaciones técnicas de los diversos componentes de la migración.

El Capítulo 4. Evaluación de la eficacia económica contiene un resumen de los resultados de los análisis comerciales.

Por otra parte, el Capítulo 4. Evaluación de la eficacia económica contiene también las recomendaciones relacionadas con los efectos económicos de los diversos métodos de migración.

El análisis comercial (Capítulo 4. Evaluación de la eficacia económica) se ocupa de los aspectos financieros de los proyectos de migración y es por lo tanto particularmente relevante para los lectores que tienen que tomar las decisiones estratégicas y económicas fundamentales. Se utilizan diversos escenarios para estudiar los aspectos monetarios de los posibles proyectos de migración.

El Capítulo 5. Recomendaciones de la migración proporciona los detalles relevantes para la toma de decisiones en una administración pública. Este capítulo contiene recomendaciones de combinaciones adecuadas a distintos escenarios[2] posibles de distintas estructuras de administración [3]. Estas recomendaciones están basadas en los análisis técnicos y comerciales precedentes. Las explicaciones de la sección titulada “Migración suave”, abordan cuestiones clave como qué condiciones y factores deben considerarse para lograr una implantación exitosa del proyecto. Este es el núcleo de información esencial y relevante que necesitan las personas responsables de la toma de decisiones. No obstante, cada responsable es libre de complementar con cualquier otro contenido esta guía.

Un recorrido exhaustivo de la guía puede ser interesante para responsables de TI. La estructura está dispuesta de forma que el Capítulo 2. Aspectos clave de la guía de migración, titulado “Puntos clave de la guía de migración”, que sigue a la introducción, contiene información general importante para entender el resto de la guía. Las secciones que siguen a las primeras cuatro secciones ya mencionadas contienen información relativa a las distintas distribuciones Linux™, modelos de licencia de código abierto y, sobre todo, información relativa a los datos en que se fundamenta esta guía.

Los detalles técnicos discutidos en el Capítulo 3. Descripción técnica de las fases de migración son posiblemente la fuente más importante de información para los responsables TI que estén familiarizados con los requerimientos específicos de su administración cuando se trata de asuntos tales como:

  • ¿Qué es técnicamente viable y/o dónde se dan los problemas?

  • ¿Cómo pueden resolverse los problemas o utilizar soluciones de compromiso?

  • ¿Qué es importante desde el punto de vista técnico cuando se trata de migrar un componente?

  • ¿Qué funcionalidades pueden mantenerse después de la migración, y/o cuáles son las restricciones?

  • Y muchos más.

Dentro de cada sección, se presentan los componentes del sistema desde un punto de vista técnico. Se describe primero la situación técnica de partida y seguidamente se tratan aspectos particulares de migraciones por reemplazo y continua. Para los lectores interesados, con la adecuada capacitación técnica, se ofrece una visión general de las distintas tecnologías, con información detallada en lo concerniente a la adecuación de las distintas soluciones y productos. Las secciones que tienen que ver con migración por reemplazo, contienen una gran cantidad de información pensada para los lectores que todavía no tienen familiaridad con las tecnologías basadas en Linux™ o que sólo han tenido un contacto limitado con ellas.

El capítulo recoge los análisis técnicos y económicos de los capítulos precedentes para conformar recomendaciones concretas. Este capítulo presenta los distintos escenarios que se explican de manera distinta dependiendo del tamaño y grado de especialización de la administración pública particular. Los lectores encontrarán información concreta dependiendo de sus necesidades y la situación de partida particular.

Información para responsables de toma de decisiones

Recomendaciones generales

Como ya se ha indicado en la sección anterior, la guía de migración generalmente analiza las dos rutas, esto es, migración por continuación y por sustitución. El resultado general puede mencionarse ya aquí: el número de escenarios donde la migración por sustitución, utilizando productos de código abierto, es la aproximación más favorable para las administraciones públicas se ha incrementado. Esto es, por una parte, debido a que los resultados de la evaluación de eficiencia económica en la que los productos OSS son en general ventajosos. Por otra parte, la madurez actual, penetración y compatibilidad de los productos OSS está allanando el camino de forma especial a los proyectos de migración y, de esta forma, contribuyendo a menores costes de cambio que en el pasado. La evaluación de la eficiencia económica, en particular, confirma que se pueden alcanzar ahorros substanciales no sólo cuando se eliminan los costes de licencias, sino también - y sobre todo - como consecuencia de la creciente competencia entre sistemas operativos y productos “Office”.

Los resultados de la guía se refieren principalmente a la situación de partida que aún prevalece en muchas administraciones públicas. Estos entornos se caracterizan por utilizar Windows NT 4™ como sistema operativo y los productos relacionados de Microsoft™, tales como MS Exchange 5.5, Internet Information Server 4y MS SQL Server 7.

Migración por continuación y por sustitución

Esta configuración es la situación de partida para la migración por continuación dentro de la familia Microsoft™. Un énfasis especial se pone en la migración de los productos mencionados arriba a Windows 2000™ y las series de producto 2000 (también con la mirada puesta en Windows XP™ y Windows 2003™). El enfoque en Windows 2000™ no significa que, en el caso de administraciones que ya hayan completado su migración a este entorno, la guía no resulte de utilidad. Esta guía proporciona información útil, para estos últimos casos, en ambos aspectos: análisis técnico y recomendaciones. Las argumentaciones que se presentan y las medidas inmediatas para la reducción de la dependencia interna aseguran que estas opciones pueden mantenerse abiertas con una visión hacia futuras migraciones.

Estas recomendaciones están escritas principalmente para administraciones públicas que acaban de completar la migración a Windows 2000™ por una parte, y para administraciones que han decidido (por la razón que sea) o bien se ven forzadas a continuar utilizando la línea de productos Microsoft™ en el momento presente.

En el caso de la migración por reemplazo se concluye que los resultados y recomendaciones deben diferenciarse en vista del gran número y diversidad de soluciones. Los criterios importantes para seleccionar la solución correcta son: tamaño, intensidad de uso TI y el grado de “especialización” de las administraciones públicas que proveen servicios TI para otras administraciones. Deben identificarse correctamente los productos equivalentes y escenarios de migración. Esta guía diferencia, en este caso, entre migración selectiva, de largo alcance y completa (dependiendo del “alcance” en lo que concierne a las TI). Selectiva por reemplazo de componentes individuales del entorno de las TI,

Puesto que las funcionalidades individuales y propiedades concretas pueden ser importantes en cada caso individual, cada agencia pública debería evaluar el nivel crítico de las funcionalidades divergentes por sí misma. Las diferencias de este tipo se encuentran primeramente en el campo de las aplicaciones Office, en especial en la integración de aplicaciones especiales y Office, así como en el campo de la compatibilidad e intercambio de documentos entre Office y OpenOffice.org y/o StarOffice. Debido a problemas de compatibilidad, la edición normal de documentos con OpenOffice.org y/o StarOffice y MS Office es posible sólo hasta un nivel muy limitado, La edición normal, en principio, sólo es posible a nivel de contenidos.

Los análisis técnicos muestran que, generalmente, existen soluciones de código abierto y/o soluciones comerciales para sistemas basados en Linux adecuadas para los componentes existentes en sistemas Windows y servicios de infraestructura.

En relación con los servicios de infraestructura, Samba y OpenLDAP juegan un papel importante para la implementación de sistemas heterogéneos. CUPS es un servicio de impresión innovador y a la vez probado y comprobado que cumple los requerimientos de cualquier entorno de impresión actualizado, es eficiente económicamente y complejo. El número de soluciones software complejas está creciendo. De todos modos, los sistemas basados en Linux™ son ofrecidos también para la gestión de sistemas corriendo bajo Windows™.

Las soluciones alternativas a MS Exchange, incluyen por ejemplo productos de software libre, especialmente para el uso como servidores puros de correo. Samsung Contact es una solución de reemplazo total que permite el uso continuo del cliente de correo Outlook en entornos medios y amplios y Exchange4 Linux™ para entornos pequeños.

Hay muchos sistemas abiertos de gestión de bases de datos. Por ejemplo, SAP DB, MySQL, y PostgreSQL. Es más, algunos sistemas de bases de datos comerciales como Oracle y DB2 son soluciones probadas y comprobadas bajo Linux™ y por tanto, no requieren un análisis técnico adicional.

La lista podría continuar con casos de todas las aplicaciones y áreas de infraestructura. La guía de migración contiene secciones separadas para estos asuntos, como soluciones de alta disponibilidad o clientes “ligeros”. Se explican también las diferencias y restricciones de las alternativas consideradas

Futuros aspectos clave

Con el fin de dar al análisis la necesaria orientación hacia el futuro, se considerará el papel de los componentes que juegan un papel central en la nueva arquitectura de Microsoft™, así como una descripción y un análisis de la situación de partida. Estos son, sobre todo, el entorno de desarrollo .NET™ con sus componentes principales, i.e. servicios web y Xml, así como el portal de servicios SharePoint™.

Los resultados se pueden resumir en lo siguiente:

  • Tanto la arquitectura .NET™ y la alt ernativa Java/J2EE™ generalmente ofrecen dos posibilidades para implementar la reutilización de componentes y la interoperabilidad entre plataformas y aplicaciones

  • La reutilización que puede lograrse por medio del uso del mismo modelo de componentes (COM+ en el caso de Microsoft™ y JavaBeans en Java™) serán referidas como integración profunda debido a su dependencia del entorno de ejecución y/o los lenguajes de programación. Las aplicaciones generadas usando un modelo de componentes pueden ser utilizadas solamente dentro de la misma plataforma.

  • XML servirá como el formato de documentos y de intercambio de datos y por lo tanto forma la base para el uso de servicios web los cuales, gracias a su independencia de un entorno de ejecución concreto y gracias al uso de interfases de protocolo, pueden ser usados para integración superficial de servicios. Los servicios basados en servicios web pueden ser usados más allá de los límites de las plataformas.

  • En vista de los problemas de seguridad que están todavía sin resolver en conjunción con con el uso de aplicaciones ofrecidas por medio de servicios web, en el presente no es posible dar una recomendación general para el modelo de integración superficial entre plataformas. Esta será una tarea clave del trabajo en desarrollo.

  • Una recomendación general para el modelo de componentes ya ha sido fijada en la recomendación de estandarización de SAGA y especifica JSE/J2EE como el modelo de componentes obligatorio debido a la independencia de plataforma general. El uso de otra tecnología distinta de la tecnología de preferencia debe ser justificada (por ejemplo, por ventajas comerciales significativas) (en favor de la arquitectura .NET™, por ejemplo).

  • El uso de XML como el formato de datos que SAGA ya se especificó como el "estándar universal y primario para el intercambio de datos entre todos los sistemas de información relevantes para propósitos administrativos", así como la especificación SAGA de PDF como el formato de intercambio de documentos probablemente conducirá a una mejora sustancial (aunque ciertamente, no a la completa eliminación de todos los problemas) en conjunción con la interoperabilidad de los productos de Office con MS Office 2003 y superiores.

Eficiencia económica

La evaluación de la eficiencia económica en la guía de migración se centra en dos aspectos claves:

  • Determinar enunciados generales concernientes a la eficiencia económica de los productos de software libre

  • Describir métodos y ayudas para la determinación de evaluaciones específicas a cada agencia y cálculos de costes de migración relacionados con los proyectos

Con la matriz de costes de migración y una evaluación de la eficiencia económica amoldada a las condiciones de los proyectos de migración (WiBe 21)[4] se describen dos acercamientos metodológicos hacia el cálculo de la rentabilidad de los proyectos de migración.

Esta guía contiene modelos calculados y comentados para diferentes escenarios a fin de explicar estos métodos en mayor detalle. Para considerar las características especiales del proceso de migración, estos modelos calculados incluyen una propuesta para el criterio de análisis a ser seleccionado así como un nuevo criterio de análisis y recomendaciones para la evaluación y análisis de beneficios para la preparación de una evaluación de la eficiencia económica de acuerdo a WiBe 21. Esto significa que esta guía no solo permite la estimación de un proyecto en términos económicos sino también ayuda a determinar índices de rentabilidad o urgencia y/o importancia estratégica de estos proyectos. La matriz de costes de migración es también una forma rápida y pragmática de soporte para la evaluación de eficiencia económica.

Podemos concluir que las evaluaciones de eficiencia económica muestran particularmente que el grado de integración entre los entornos Windows™ y MS Office será un factor de decisión clave a favor o en contra de una migración de reemplazo. El número de aplicaciones Office existentes, la extensión y complejidad de las macros, scripts y plantillas utilizadas, así como el número y disponibilidad del código fuente de las aplicaciones especiales usadas que solo pueden ejecutarse bajo Windows™ determinan la eficiencia económica y viabilidad de la migración de reemplazo. Esto es por que, especialmente con respecto a este punto, algunas recomendaciones apuntan hacia reducir dependencias e incrementar la interoperabilidad.



[1] Berlecon Research, 2002.

[2] Migración por reemplazamiento completo, migración contínua completa y migración parcial.

[3] Administración pública pequeña, mediana, grande y especializada.

[4] IT-WiBe 21 - Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der Bundesverwaltung, insbesondere beim Einsatz der IT, Version 3.0 - 2001, KBSt publication series, Volumen 52, Mayo 2001.

Capítulo 2. Aspectos clave de la guía de migración

Definiciones importantes

Algunos términos utilizados a diario son entendidos de forma distinta por personas distintas. Esto afecta, por ejemplo, al software de código abierto, software libre, propietario, comercial, etc. No es sólo esto, sino que esta guía introduce también nuevos términos.

Con el fin de evitar malentendidos al leer esta guía, se definen los términos más importantes brevemente a continuación.

código abierto, software libre

Los términos “software de código abierto” y “software libre” se utilizan como sinónimos en esta guía de migración. La abreviación utilizada para ellos es OSS.

OSS permite a cada usuario leer y modificar sin coste el código fuente disponible. Esta transparencia permite a los usuarios aprender del código fuente y/o adaptarlo a sus requisitos particulares. El software está disponible sin coste, los usuarios no tienen que pagar licencia. El software modificado puede ser copiado y distribuido. La libertad del software se define y protege mediante las licencias correspondientes. El capítulo “Modelo de licencias” contiene una descripción de los modelos más importantes de licencias.

OSS no debería confundirse con aquel software que, aunque disponible sin coste, no puede ser modificado o corregido por el usuario y/o que está sujeto a licencias que prohíben el uso del software para propósitos comerciales.

Software propietario

El software propietario [5] no es OSS. Pertenece a un individuo u organización, generalmente el fabricante del software (copyright). El uso del software está sujeto a los términos de la licencia establecida por el propietario. Estos términos prohíben habitualmente la duplicación, distribución y modificación del software.

El software de este tipo se ofrece en ocasiones sin coste, con la condición de adherirse a los términos aplicables de la licencia.

Software comercial Linux

El software comercial Linux (COLS) abarca el conjunto de software propietario que puede ejecutarse bajo sistema operativo Linux. Este software sigue presentando como ventajas el uso de estándares, y la interoperabilidad resultante, así como precisión en la definición de interfaces.

Migración por sustitución (o de reemplazo)

Esta guía diferencia entre una migración de reemplazo y una migración por continuación. ¿Cuál es la diferencia entre estas formas de migración?

La migración de reemplazo significa un cambio de las aplicaciones y servicios Windows™ al igual que del sistema Windows™ a plataformas OSS o COLS. Unos ejemplos:

  • de Windows NT™ a Linux

  • de MS Office™ a OpenOffice.org™

  • de MS SQL Server™ a Oracle™

Migración por continuación

La migración por continuación significa continuar con el uso de productos de Microsoft™, por ejemplo, migrar de NT 4™ a Windows 2000™, Windows XP™ o Windows 2003™. Algunos ejemplos:

  • de Windows NT 4™ a Windows 2000™

  • de MS Office 97™ a MS Office 2003™

Caminos de Migración

Muchos organismos públicos e instituciones están actualmente afrontando cuestiones tales como cuál será el desarrollo que seguirán sus sistemas de IT en los próximos años. Las razones para esto son diversas:

  • Suministradores descontinuando el soporte para productos clave.

  • Incremento de los requerimientos técnicos.

  • Consolidación de sistemas existentes en el entorno.

  • Metas estratégicas, las cuales acrecientan las dependencias industriales e incrementan la operatividades.

Actualmente hay, por lo tanto, cuestiones para encarar las cuestiones propias de cuáles van a ser los sistemas y componentes que formarán parte de nuestras futuras estructuras tecnológicas. La guía de migración analiza y examina los siguientes pasos generales de migración:

  • Migración de reemplazo utilizando Linux y software libre (OSS).

  • Migración de reemplazo utilizando Linux/software libre y productos Linux comerciales (COLS).

  • Migración por continuación con MS Windows 2000™ y generaciones sucesoras como la relación con aplicaciones y sistemas Windows™.

Además de esto, puede considerarse la opción de una migración híbrida porque no se puede contar con una solución OSS/COLS para todos los sistemas antiguos, tanto por razones técnicas como comerciales.

Dentro del ámbito de esta guía no son posibles los análisis completamente exhaustivos. Esto último sería imposible, debido tanto a la complejidad de los entornos de TI a considerar como a los requerimientos específicos de algunas agencias públicas. En lugar de esto, la guía de migración debe entenderse más como una fuente de respuestas y ayuda para la toma de decisiones en las cuestiones clave que mayoritariamente son formuladas por las autoridades públicas.

Microsoft como situación de partida

La ilustración de la figura Figura XXXfigura1. Contexto de sistema - situación de partida muestra el contexto de sistema Microsoft™ de este modo u otros similares en muchas agencias públicas y organizaciones. La figura muestra un visión de los servicios y módulos de software que forman parte de la situación de partida considerada para los casos de migración analizados. El capítulo Capítulo 3. Descripción técnica de las fases de migración comienza para cada uno de estos componentes con una descripción técnica de la situación real en términos de funcionalidades y características especiales disponibles de cara a la migración. Esta descripción es seguida por un análisis técnico de una, o si aplican, varias soluciones adecuadas para una migración total. El tercer paso es un análisis de la migración de continuidad. El cuarto y último paso del análisis técnico es una evaluación y recomendación sobre uno u otro camino de migración.

Figura XXXfigura1. Contexto de sistema - situación de partida

Han sido necesarias algunas suposiciones en relación con las funcionalidades concretas de una infraestructura de TI en el momento de escribir esta guía. A menos que se indique explícitamente lo contrario en los análisis técnico y comercial, se han realizado las siguientes suposiciones.

Plataforma servidor

Se ha supuesto que la situación de partida en las agencias públicas está basada en una de los dos modelos de dominio de los clientes NT™.

  • Entorno con un dominio NT™ en el que se almacenan el usuario y las cuentas de usuario.

  • Entorno con un dominio NT™ de cuentas que incluye las cuentas de los usuarios y varios dominios con recursos, que mantienen las cuentas de usuario y confían en el dominio de cuentas.

Con este entorno los servicios de infraestructura, están disponibles aplicaciones y componentes de integración sobre la base de un servidor NT 4™.

En esta guía se consideraron los siguientes servicios clave de infraestructura:

  • Servicio de registro-autenticación

  • Servicios de ficheros (disco)

  • Servicios de impresión

  • Servicios de red

  • Servicios de gestión de sistemas

En relación con las aplicaciones del servidor, esta guía se concentra en las siguientes áreas por su uso extendido en las administraciones públicas:

  • Internet Information Server™ (IIS) versión 4 como el servidor web para intranet y presencia en internet

  • Exchange™ 5.5 como solución de mensajería y groupware.

  • SQL-Server™ 7 como sistema de gestión de bases de datos para muchas aplicaciones de base de datos.

Normalmente, los diferentes servicios fueron relacionados e integrados sobre la base de:

  • Component Object Model™ (COM) y

  • el correspondiente servicio COM distribuido (DCOM).

Los servicios Windows NT™ 4 pueden ofrecerse sobre dos variantes de sistema operativo:

  • Windows NT4 Server™

  • Windows NT4 Server Enterprise Edition.™

La segunda variante (Enterprise Edition) permite la implementación de los servicios sobre dos nodos (servidores) en un cluster.

Plataforma de cliente y sus aplicaciones

En el lado del usuario, cabe esperar que Windows NT 4 Workstation™ sea el sistema operativo dominante. Otras variantes de sistema operativo, como Windows™ 95 ó 98, son ignoradas en el análisis. La suite Microsoft Office™ se utiliza como la aplicación más importante en la base del sistema operativo. Las versiones 97 y 2000 son consideradas como las versiones más utilizadas en este momento. Los usuarios las utilizan en su trabajo diario. Los programas que utilizan son el procesador de textos, la hoja de cálculo y el programa de presentaciones, así como las funciones de correo electrónico y groupware.

Aparte de estos productos, también existe un conjunto de aplicaciones para tareas muy específicas que están profundamente integrados en el escritorio Windows™. Estos programas deben analizarse en detalle con un ojo puesto en la migración. Como estas aplicaciones están afectadas por la migración del sistema TI subyacente, deberán desarrollarse estrategias internas, dependiendo del número y complejidad de estas aplicaciones. Esta guía describe algunas propuestas y procedimientos recomendados.

Panorama del sistema con la migración por reemplazo

La ilustración de la figura Figura XXXfigura2. panorama del sistema - migración por reemplazo. muestra un resumen de un sistema alternativo basado en Linux. La ilustración muestra los sistemas y aplicaciones más importantes para los cuales la migración por reemplazo es posible.

En la década pasada, muchos desarrolladores de aplicaciones hicieron sus productos y servicios para Linux o los portaron a Linux. Aparte de grandes desarrolladores, como IBM™, SUN™ u Oracle™, un número amplio de compañías menores ofertaron soluciones especiales que deberían mencionarse aquí también. Dada la base de información y distribución que existe en el campo del software comercial, no es necesario examinar esos productos con la vista puesta en la viabilidad. La guía de migración se enfoca en soluciones de código abierto algo menos conocidas y en soluciones que, sólo recientemente, hacen posible la migración por reemplazo en áreas críticas.

La ilustración de la figura Figura XXXfigura2. panorama del sistema - migración por reemplazo. muestra que existe más de una alternativa para ciertas aplicaciones. Esta es la razón del por qué las soluciones de fuente abierta tradicionales se tuvieron en cuenta en el análisis técnico. En casos en los que no existan aplicaciones de fuente abierta adecuadas, se examinarán soluciones software propietarias que se puedan ejecutar en Linux y que estén basadas en estándares abiertos.

Figura XXXfigura2. panorama del sistema - migración por reemplazo.

Panorama del sistema con migración continua (o por continuación).

La migración continua está enfocada en el reemplazo de entornos Windows NT™ 4 existentes con versiones nuevas. La ilustración de la figura Figura XXXfigura3. panorama del sistema - migración continua muestra que los productos de las versiones 2000 serán las principales del análisis. Con la base de un servidor Windows 2000™ y su infraestructura de servicios, el capítulo Capítulo 3. Descripción técnica de las fases de migración debate las características técnicas y las medidas técnicas y conceptuales necesarias para la migración de cada servicio y producto en el servidor. Además, se analizarán y evaluarán las repercusiones de los cambios técnicos y las innovaciones.

Además de la parte servidora, se realizará un análisis análogo de los escritorios para la migración por reemplazo. En este caso, sin embargo, el análisis se basa en Office XP™.

El análisis se extenderá - siempre que la información disponible lo permita - hasta incluir la introducción de los productos servidores y de oficina de las versiones 2003.

Figura XXXfigura3. panorama del sistema - migración continua

Dependencias internas dentro del sistema Microsoft™

Las arquitecturas basadas principalmente en productos de Microsoft™ son objeto de dependencias internas en varios grados. Las siguientes secciones explican algunas de las dependencias internas dentro de la infraestructura establecida por Microsoft™.

Una dependencia relativamente obvia es que las aplicaciones Microsoft™ sólo pueden instalarse y utilizarse en sistemas operativos Microsoft™. Esto es aplicable tanto a las aplicaciones de servidor como de oficina (por ejemplo, MS SQL Server™, MS Exchange™, etc.) y, con algunas excepciones, (Office 98™ para MacOS™, Internet Explorer™ 4 para UNIX™), también a las aplicaciones de escritorio (p.e. Office™) a software cliente cercano al sistema (p.e., los componentes cliente de MS SQL™).

La aplicaciones de servidor suelen requerir una administración de usuarios para poder autenticar a los mismos y otorgarles acceso a los recursos. Microsoft™ ofrece variantes respecto a la base de datos a emplear. La variantes se enumeran a continuación utilizando como ejemplo MS SQL Server™:

  • Variante A. Un sistema de gestión de usuarios específico de MS SQL Server™.

  • Variante B. La base de datos local de usuarios del sistema operativo del servidor.

  • Variante C.  La base de datos de usuarios de un dominio Windows™, a condición de que el servidor sea miembro de la estructura. Desde el lanzamiento de Windows NT™, esta variante ha estado disponible para casi todos los productos de servidor de Microsoft™ y permite a los usuarios un sistema de identificación único en un entorno Microsoft™ puro.

  • Variante D. No se ofrece un sistema en el que la autentificación y la autorización las realicen instancias de otros fabricantes.

Con Windows 2000™ y sucesores, Microsoft™ ha desplazado la administración y autentificación de usuarios a servicios de directorio (ver más adelante) empleando estándares abiertos como Kerberos y LDAP, aunque sin permitir instancias no-Microsoft™.

Respecto al mundo Windows NT™ 4.0, deben mencionarse otras dependencias respecto a la administración de usuarios. Por ejemplo, no es posible implementar entornos Microsoft Exchange™ (versiones 4 a 5.5) sin la estructura de dominio Windows NT™. Otro ejemplo de dominio NT™ obligatorio es la funcionalidad de servicios en cluster. Lo mismo se puede aplicar a la arquitectura distribuida de componentes DCOM (Modelo de Objetos de Componente Distribuido - Distributed Component Object Model) creada por Microsoft™ con una infraestructura de seguridad que requiere que el cliente y el servidor pertenezcan a una estructura de dominio. Un gran número de aplicaciones cliente/servidor (de Microsoft™ y otros fabricantes) utilizan DCOM.

Con Windows 2000™, Microsoft™ desarrolló aún más el modelo de dominio NT™, que acabó en el servicio de directorio activo. Dentro del directorio activo, el modelo de dominio NT™ y sus propiedades aún se pueden ver y son necesarias para la compatibilidad hacia abajo. La introducción de Kerberos como mecanismo de autenticación, por ejemplo, no significa la eliminación del mecanismo NTLM (NT LAN Manager™). Es más, los entornos Windows 2000™ puros siguen utilizando NTLM en ciertas ocasiones (como en clusters). Al mismo tiempo, el directorio activo fue retocado añadiéndole funcionalidades tendentes a ser manejadas separadamente o que no existían en el mundo Microsoft™ anterior. Respecto a la funcionalidad de las directrices de grupo, algunas partes ya eran conocidas en Windows NT™ como directrices del sistema, Kit de Administración de Internet Explorer (IEAK - Internet Explorer Administration Kit) o Gestor de la Configuración de Seguridad (SCM - Security Configuration Manager). Las nuevas funcionalidades se introdujeron en el campo de las directrices de grupo, como la distribución del software, la dependencia en unidades organizativas, dominios o sitios o scripts de entrada y salida del sistema.

Una característica completamente nueva en el directorio activo de Windows 2000™ es la integración de tecnologías de cifrado, como IPsec o EFS (Sistema de Ficheros Cifrado - Encrypted File System). Si se van a utilizar estas tecnologías de cifrado deberá configurarse un PKI (Infraestructura de Clave Pública - Public Key Infraestructure) que se integra en el directorio activo. En este contexto, Microsoft™ también ha desarrollado el protocolo Kerberos para permitir la autentificación mediante tarjetas inteligentes (SmartCards). Otro requisito obligatorio del directorio activo de Windows 2000™ es una infraestructura DNS (Sistema de Nombres de Dominio - Domain Name System) para la resolución de nombres. El DNS se debe corresponder, al menos, con las versión 8.2.2 de BIND. Windows incluye un DNS propio.

Exchange 2000™ es el primer producto Microsoft™ que requiere el directorio activo de Windows 2000™ como funcionalidad obligatoria. Al contrario que Exchange™ 5.5, Exchange™ 2000 ya no incluye su propio servicio de directorios. Cualquier información del e-mail de los usuarios y de las listas de distribución de Windows 2000™ se localiza en el directorio activo, que debe ser preparado para su integración en Exchange™ por una modificación de esquemas. El Servicio Total de Catálogos del directorio activo juega un papel primordial en Exchange 2000™. Exhange 2000™ utiliza este servicio global de catálogos para solicitar información más allá de los límites de los dominios. Outlook 2000™, por ejemplo, utiliza también el Catálogo Global. Es más: Exchange 2000™ utiliza el directorio activo no sólo en modo lectura, sino también en modo escritura: El servicio de Actualización del Receptor de Exchange 2000™, escribe sus resultados en el directorio activo. Las herramientas para administración de usuarios de e-mail™, están completamente integradas en la consola de gestión directorio activo->usuarios y ordenadores

Estas correlaciones y dependencias entre el sistema operativo y las aplicaciones de Microsoft™ caracterizan el progresivo incremento del alcance de la integración dentro de ésta plataforma e inician muchas preguntas respecto de aspectos estratégicos en relación con el uso de alternativas potenciales de estos productos.

  • ¿Cómo puede implementarse la interrupción de cierta línea de productos o de los ciclos de actualización?

  • ¿Cómo puede minimizarse la dependencia de una línea de productos y el equipo técnico necesario?

  • ¿Qué medidas llevan a la reducción de la dependencia de un suministrador y a la diversificación del entorno de software?

  • ¿Existen suficientes alternativas para ciertos componentes del software en la forma de alternativas más económicas?

A la vista del nivel de dependencia que se ha alcanzado a día de hoy a nivel de producto, estas preguntas sólo pueden ser respondidas por una aproximación estratégica que debe ser considerada dentro del entorno de las TI de las administraciones.

Distribuciones Linux

Modelo de licencias

Fuentes de información



[5] En inglés propietary, del latín propietario.

Capítulo 3. Descripción técnica de las fases de migración

Introducción

Las descripciones técnicas hacen una aproximación más técnica a los distintos productos, soluciones y servicios descritos en el capítulo 2 en los sistemas de TI en cuestión:

Se trataron los siguientes aspectos:

  • Servicios de infraestructura

    • Servicios de ficheros

    • Servicios de impresión

    • Servicios de autenticación

    • Servicios de red

  • Componentes middleware y de integración

    • Servicios de Directorio

    • Modelo de componentes de objetos

    • Plataformas para sistemas distribuidos y servicios web

    • XML

  • Servicios en Servidores

    • Groupware y mensajería

    • Servidores de bases de datos

    • Servidores Web

    • Servicios especiales

  • Componentes middleware y de integración

  • Servicios en Servidores

  • Aplicaciones de escritorio, incluyendo el paquete Office

Las descripciones se centran en la posibilidad técnica de migrar productos individuales de Microsoft a soluciones OSS o COLS adecuadas. Se analizarán en detalle los siguientes aspectos para los componentes individuales de este escenario partiendo del escenario de sistemas IT establecido por Windows, descrito en el capítulo 2.1:

  • ¿Cual es la situación inicial?

  • ¿Qué funciones importantes están disponibles?

  • ¿Qué interfaces existen y/o a cual hay que dar servicio?

  • ¿Cuáles son las características especiales durante la operación?

  • ¿Qué alternativas están disponibles en OSS o, si aplica, en soluciones COLS?

  • ¿Cuáles son las diferencias funcionales?

  • ¿Se cumplen los requerimientos críticos?

  • ¿ Qué debe tenerse en cuenta a la hora de migrar?, ¿donde están los problemas?, ¿como pueden resolverse?

  • ¿Existen múltiples alternativas?, ¿para quien y/o con que propósito pueden utilizarse dichas alternativas?

  • ¿Cómo pueden dichas alternativas integrarse en mundos completamente heterogéneos? Si es necesario, ¿Como interaccionan entre ellas? (Especialmente con Microsoft, compatibilidad e interoperabilidad)

  • ¿Cuales son las repercusiones de la integración potencial en un futuro con la linea de productos de Microsoft?

  • ¿Que potenciales existen si el uso de la linea de productos de Microsoft continúa?

  • ¿Que funcionalidades adicionales están disponibles?

  • ¿Donde residen los mayores cambios?

  • ¿Cubren dichas innovaciones y posibles modificaciones los requerimientos críticos?

  • ¿Que debe tenerse en cuenta debido a la independencia de los sistemas?

La descripciones normalmente finalizan con una breve evaluación. Si existen múltiples alternativas, son soluciones comparables e igualmente comentadas, si existe la posibilidad de llevarse a cabo.

Sistema de ficheros

Perspectiva general

El resultado de las descripciones detalladas de los servicios que se cubren pueden ser resumidas como sigue:

En el caso de la sustitución directa de un servidor Windows NT como sistema de almacenamiento de ficheros, manteniendo fijos los clientes Windows, Samba es el sistema idóneo dentro de la comunidad de código abierto. Samba se comporta como si de un servidor Windows NT se tratase, desde el punto de vista de los clientes Windows. Samba esta en continua actualización y soporte, no solo por la comunidad sino que también esta creciendo entre proveedores de servicios IT.

Dependiendo de la envergadura de la migración Linux desde el punto de vista del cliente, NFS y AFS también son alternativas muy interesantes. NFS y AFS están ampliamente extendidos entre redes UNIX, pero debe instalarse software adicional en los clientes para poder integrar clientes Windows. Un cliente NFS se incluye, por ejemplo, en los Servicios de Microsoft Windows para UNIX (SFU 3.0). El cliente AFS está disponible libre de cargos y con su código fuente en OpenAFS.org. El uso de NFS y AFS en un entorno de clientes Windows siempre requiere un gran cambio en cuanto a conceptos en comparación con Windows NT.

El concepto de seguridad de Kerberos, que también oculta el directorio activo de Windows 2000, juega un papel importante que viene a modernizar la infraestructura IT dentro de un proyecto de migración. La posibilidad de ver OpenAFS como alternativa a Windows2000 como servidor de ficheros debería ser evaluada con más detalle si el cliente final sigue utilizando la linea de productos de Windows.

Los sistemas de ficheros más apropiados para el almacenamiento físico de datos en sistemas de discos de servidores reales son , por ejemplo, XFS y EXT3. Ambos sistemas soportan “journaling”, “quotas” y la asignación de privilegios de acceso a nivel de fichero y de directorio. Tanto XFS como EXT3 soportan atributos extendidos de ficheros como abd POSIX-ACL's para garantizar los derechos. Cuando se “mapea/traduce” de Windows-ACL a POSIX-ACL debe tenerse cuidado, puesto que la fina granularidad con la que los privilegios pueden ser definidas bajo Windows, se pierden. Como análisis final, las repercusiones que ambas restricciones tienen en dicho caso o si son aceptables, deben ser analizadas profundamente.

Windows NT 4

Requisitos funcionales

La funcionalidad general de un sistema basado en red consiste en los siguientes puntos:

  • Recibir (escribir) y entregar (leer) ficheros.

  • Crear y presentar una estructura de directorios.

  • Administrar y presentar “meta-datos” para directorios y ficheros.

  • Implementar los privilegios de acceso y restricciones en ficheros y directorios.

  • Deshabilitar accesos a ficheros en el caso de que se produzca un conflicto.

En la mayoría de los entornos, los servicios de ficheros de Windows Nt se utilizan para los siguientes propósitos:

  • Almacenamiento de ficheros específicos de cada usuario (directorios /home)

  • Almacenamiento de los perfiles basados en servidores si se requiere soporte optimizado para usuarios que interactúan con distintas máquinas.

  • Almacenamiento de ficheros de grupos, específicos de usuarios (carpetas de grupo) que serán utilizadas únicamente por un conjunto determinado de usuarios (por departamentos, por ejemplo).

  • Almacenamiento de bases de datos basadas en ficheros que serán utilizados por distintos usuarios al mismo tiempo (como la base de datos de MS Access pero con “frontent” separado).

  • Almacenamiento de programas (ficheros .exe, ficheros .dll, etc de aplicaciones) para evitar la necesidad de almacenar dichos ficheros localmente en la máquina cliente.

  • Almacenamiento de sistemas de bases de datos que permiten el almacenamiento de datos del usuario en otro servidor bajo una ruta “UNC”.

En la práctica, los usos aquí descritos normalmente varían mucho en cuanto a detalles según requisitos, que serán resaltados en las secciones que siguen.

El sistema de ficheros NTFS4

El sistema de ficheros NTFS4 es la base del almacenamiento y manejo de ficheros bajo Windows NT4.

Propiedades

Las propiedades de NTFS4 incluyen, por ejemplo, lo siguiente:

La carpeta de cada fichero tiene asignado lo que se denomina una lista de control de acceso (ACL, Access Control List), que se almacena en el mismo fichero o carpeta. La ACL contiene lo que se denomina entradas de control de acceso (ACE, Access Control Entries) que contienen el SID del grupo o usuario y la autorización correspondiente. El acceso es también controlado a través de la ACL y es posible implementar un sistema de control de acceso granular. La ACL debe ser a su vez fragmentada en listas de control de acceso al sistema (SACL, System Access Control List) y en listas de control de acceso discrecional (DACL, Discretional Access Control List): Las DACLs contienen los SID de los grupos y usuarios que están autorizados a acceder a dicho objeto o no. Las SACLs determinan el modo en que el subsistema monitoriza el acceso al objeto.

En principio, NTFS4 no soporta herencia: Sólo cuando se crea un fichero nuevo, los privilegios de la carpeta se copian en la ACL (lista de control de acceso) de dicho fichero. Cuando los privilegios de la carpeta cambian, la herencia de los privilegios de las ACL que contienen los ficheros de dicha carpeta, debe ser activada explícitamente. Debemos considerar otra característica especial: Un fichero que se almacena en la ruta UNC \\servidor\\freigabe\\ordner\\subordner puede ser leído por un usuario aunque la carpeta “ordner” prohíba su lectura, siempre que la carpeta “subordner” lo permita.

No existe limite en la longitud del nombre de la ruta. Se soportan los nombres de ficheros con más de 256 caracteres. Aparte de nuevas excepciones (como *, \), todos los caracteres del conjunto de caracteres Unicode de 16 bits pueden ser, teóricamente, utilizados. Los nombres cortos corresponden a la convención 8.3. Los genera automáticamente el sistema operativo cuando se almacene cualquier directorio o fichero. Aunque las mayúsculas y las minúsculas se omitan durante el almacenaje, no se discriminarán durante el proceso de acceso al fichero.

Cada carpeta y cada fichero tiene sus atributos almacenados en forma de “flags” (protección de escritura, archivos, sistemas, ocultos y comprimidos) al igual que la fecha en la que se crearon por primera vez, la fecha en la que se hizo el último cambio y la fecha del último acceso. El grado de compresión depende exclusivamente del contenido del fichero.

NTFS soporta la tecnología de cadenas múltiples. Su frecuencia de uso es relativamente baja. Las cadenas múltiples deben ser soportadas por la aplicación en cuestión, y/o deberá ser programada en la misma. Se habilitarán, por ejemplo, en el almacenamiento de recurso Folk de ficheros en Macintosh.

Desde el Service Pack 4, NTFS es capaz de manejar “quotas” (limites). La asignación y control de limites de uso en disco (quotas) está basada en la propiedad del propietario y cubren todo el volumen (dispositivo lógico del servidor de ficheros). Debido a restricciones técnicas, el uso de limites de espacio en disco debe ser considerada como una excepción más que como una regla existente en algunos entornos.

El tamaño máximo de un fichero en NTFS4 son 2TB (terabytes), al igual que la capacidad del dispositivo lógico. La capacidad máxima del dispositivo lógico cubre 2TB ( teóricamente 16 exabytes). La cantidad real de datos en red depende del tamaño del cluster que se utilice durante el formateo. El numero de ficheros esta limitado a 232-1.

NTFS habilita el registro de intentos y accesos satisfactorios. De este modo, es posible, por ejemplo, diagnosticar repetidamente la eliminación indeseada de ficheros .

Los volúmenes de datos con formato NTFS son defragmentados continuamente durante las operaciones. La corrección automática (autocorrección) bajo Windows NT 4 no existe. Si se desea activar esta herramienta se deberán contratar los servicios de una tercera empresa

El sistema de privilegios de NTFS

Windows reconoce un total de 13 privilegios que pueden ser asignados a un objeto dentro del sistema de ficheros (nos referiremos a directorios y ficheros como objetos, indistintamente) para cada usuario o grupo:

  • Navegar por carpeta/ ejecutar un fichero.

  • Listar carpetas / leer fichero.

  • Leer atributos.

  • Leer atributos extendidos.

  • Crear ficheros / escribir datos.

  • Crear carpetas / agregar datos.

  • Escribir atributos.

  • Escribir atributos extendidos.

  • Eliminar subcarpetas y ficheros.

  • Eliminar.

  • Leer privilegios.

  • Cambiar privilegios.

  • Transferir privilegios de propietario.

Los cambios en los privilegios de acceso se realizan a traves de la pestaña de “configuración de seguridad” del diálogo de “propiedades”. Con el fin de encubrir la complejidad de los 13 privilegios del sistema que están estrechamente relacionados, de los usuarios promedio, esta pestaña ofrece la posibilidad de preseleccionar algunos hitos, denominados “privilegios de grupo” como una combinación más apropiada de los privilegios individuales. Existen 5 privilegios de grupo para ficheros y 6 para directorios. Los 13 privilegios individuales se muestran en el dialogo de “Entrada de privilegios” que se accede a traves de los botones “extender/mostrar/editar”.

En este contexto, el punto de vista de los privilegios de grupo ofrecidos en la configuración de seguridad es extremadamente problemático porque la presentación puede sugerir fácilmente la falta de algunos privilegios, que de echo, existen. En el caso de acceso completo, por ejemplo, donde el privilegio de escritura de atributos extendidos es el único privilegio que no puede ser heredado, la presentación esquemática de la configuración de seguridad muestra un dibujo de perfiles de privilegio que habilitan únicamente lectura y ejecución. La tabla que sigue muestra que combinaciones de privilegios corresponden a que privilegios de grupo. Por favor, recuerde que la casilla de privilegios de grupo permanecerá activa aunque únicamente este activo un único privilegio.

Control de acceso

El control de acceso a ficheros y directorios a través de la red en entornos Windows NT se puede llevar a cabo mediante los dos mecanismos siguientes:

  • Abrir directorios (compartir)

  • Privilegios NTFS

Para poder acceder a ficheros a través de la red, se debe liberar o abrir uno de los directorios del nivel más alto. Esta liberación da origen a un ACL que se almacena en el registro. Los privilegios para esta operación de liberación se restringen a los siguientes niveles:

  • Lectura

  • Escritura

  • Acceso Total

Estos privilegios se aplican de forma absoluta. Esto significa que los privilegios NTFS localizados por debajo son sobreescritos por los privilegios de liberación. Ejemplo: un privilegio de lectura a nivel de liberación impide la escritura aun cuando los privilegios NTFS lo permitan.

Se debe prestar especial atención en entornos Windows NT a los privilegios (directivas para privilegios de usuario) debido a que esos privilegios pueden ser importantes para los servicios de ficheros, por ejemplo, “tomando la propiedad de ficheros y objetos” y “grabación de ficheros y directorios”.

Concepto de usuarios y grupo

ada directorio y cada fichero se asignan a un propietario que puede ser tanto un grupo como un usuario. El usuario que crea el fichero, normalmente se convierte en el propietario. Si el usuario es un miembro del grupo de administradores, este grupo se convierte en el propietario.

El control de acceso sistemático en el entorno Windows NT utiliza con preferencia la asignación de privilegios a grupos. La asignación de privilegios a cuentas de usuario individuales debería dejarse para sistemas de ficheros específicos de usuario.

En un entorno Windows NT existen los siguientes tipos de grupos:

  • Grupos globales

  • Grupos locales en servidores miembros

  • Grupos locales en controladores de dominio

Los grupos locales en los Controladores de Dominio difieren de los grupos locales en los Servidores Miembros en que, en el caso de los primeros, existen en todos ellos con el mismo SID (Identificador de Seguridad).

Los grupos locales en los Servidores Miembros pueden ser anidados (anidación de grupos) con los siguientes grupos:

  • Con los grupos globales del dominio propio

  • Con los grupos globales de los dominios en los que uno confía.

Los grupos globales sólo tienen cuentas de usuario como miembros.

En el ámbito de dominios de Windows NT existen dos principios “clásicos” de control de acceso diferentes:

  • Método U-G-L-R (Usuario-Global-Local-Recurso): El usuario es miembro de un grupo global. Este grupo global por su lado es miembro de un grupo local en un servidor de ficheros. Este grupo local es el único para el que se establecen privilegios NTFS en el recurso de ficheros. (ver fig. 4)

  • Método U-G-R (Usuario-Global-Recurso): El usuario es miembro de un grupo global. Este grupo global es el único para el que se establecen privilegios NTFS en el recurso de ficheros. (ver fig. 5)

Una asignación no ambigua de un recurso y un grupo local (o grupo global, respectivamente) es una condición para que ambos métodos funcionen sin riesgo. Esto significa que el grupo es usado por este recurso de forma exclusiva. Si el servicio de ficheros está implementado por un cluster, el método U-G-L-R tiene el inconveniente que el grupo local en el nodo servidor no puede tener el mismo SIDs. Esto puede remediarse configurando los nodos como controladores de dominio o usando el método U-G-R.

Herramientas

Windows NT ofrece una selección limitada de herramientas para la gestión de ficheros, carpetas y sus privilegios.

Con la interface gráfica de usuario:

  • Explorador NT (explorer.exe)

  • Gestor de fichero (filemanager.exe)

Y sólo en la línea de comandos:

  • calcs

  • Herramientas del Kit de Recursos: xcacls, scopy, etc.

Las herramientas ofrecidas por Windows NT a menudo ofrecen menos que la funcionalidad completa.

El explorador de NT por ejemplo es el mejor ejemplo de esto: no es posible establecer el propietario (solo aceptarlo) o copiar las ACLs (Listas de Control de Acceso).

Uno debe por lo tanto asumir que el administrador de un entorno NT utilice herramientas de terceros fabricantes o desarrolle sus propios scripts (como Perl) para facilitar la administración o para ejecutar tareas muy especiales.

Esto hace que la estructura de privilegios mostrada por un Explorador de NT difiera de los verdaderos accesos concedidos.

Servicios Web

Resumen

Los servicios web permiten la integración de diferentes plataformas y aplicaciones basada en estándares y de una manera independiente del fabricante.

Tanto el entorno de trabajo de .NET como J2EE proporcionan una plataforma integrada para el desarrollo de servicios web.

J2EE y .NET son igualmente adecuados para el desarrollo de aplicaciones de este tipo. Otras características comunes son:

  • Arquitectura de 3 capas (3-tier)

  • Orientación al componente, optimizados para arquitecturas distribuidas

  • Orientación a red

  • Internet como infraestructura central

  • El navegador de internet como principal interficie de usuario, "clientes enriquecidos" como interficie secundaria

Las diferencias entre las dos plataformas ya fueron esquematizadas junto a la presentación del Framework de .NET.

Debido a su alta flexibilidad y a su independencia tanto de fabricante como de plataforma, J2EE es el sistema a escoger. De esta forma también se siguen las recomendaciones de la SAGA [6]

Pero, ¿qué hay sobre la interoperatividad entre .NET y J2EE? En lo que a servicios web se refiere, dicha interoperatividad debería ser conseguida mediante la adopción por todas las partes implicadas de los estándares correspondientes (XML, SOAP, WSDL, UDDI). El único problema en este contexto es que SOAP, en su versión actual 1.1, todavía permite demasiada libertad, lo que puede significar la pérdida de interoperatividad en la práctica. De todas formas, la interoperatividad debe ser el objetivo de los servicios web. Este es un aspecto a mejorar, sobretodo con la versión 1.2 de SOAP.

Fundamentos

Un servicio web es un servicio el cual puede ser accedido mediante una dirección URL (Uniform Resource Alocator) por un cliente. El requerimiento crucial es que la implementación del servicio es completamente transparente para el cliente. Un web service puede ser considerado como una "caja negra" con cierta funcionalidad la cual puede ser usada de forma flexible sin tener que conocer los detalles de su implementación. Los servicios web ofrecen sus funciones al mundo exterior mediante interficies bién definidas. Dichas interficies son también denominadas Web Service Contract. Dicho contrato está descrito en un lenguaje específicamente desarrollado para ese propósito, esto es, el WebService Description Language (WSDL) (siendo éste un fichero XML). Los desarrolladores pueden usarlo como base para combinar servicios muy variados entre sí para formar una aplicación completa. Estos servicios pueden ser encontrados usando UDDI (Universal Description Discovery and Integration). UDDI es una especificación basada en estándares para describir y encontrar servicios web, esto es, un repositorio para servicios web. Las primeras implementaciones han sido lanzadas ya por IBM, Microsoft y otros fabricantes.

En contraste con las tecnologías de componentes actualmente en uso, los servicios web no utilizan un protocolo de objetos específico, como pueden ser DCOM, IIOP o RMI, porque su fácil utilización normalmente requiere una infraestructura homogénea tanto en el cliente como en el servidor. Los servicios web se basan en otra aproximación. Se fundamentan en estándares de internet y utilizan el "mínimo común denominador", esto es, HTTP y XML (ver capítulo 3.10). Un cliente envía un mensaje empaquetado en XML vía HTTP a un servidor que contesta a la petición enviando otro mensaje en XML. Esto significa que los servicios web son independientes de lenguajes de programación concretos o de plataformas particulares. Mientras los dos extremos estén de acuerdo en el formato de los mensajes y se comuniquen mediante una secuencia de llamada común, el tipo de implementación del servicio (servicio web) es de una importancia secundaria. Puede usar todas las opciones de la plataforma en la que es utilizado. SOAP es la generalización de este principio. El llamado Simple Object Access Protocol define como deben construirse los mensajes XML y como debe formarse la secuencia de llamada. Esto quiere decir que las aplicaciones más dispares funcionando en plataformas diferentes pueden ser combinadas e integradas en soluciones existentes vía internet. El único prerequisito es que las aplicaciones usen SOAP para comunicarse entre ellas. El propio SOAP puede utilizar diferentes protocolos (como HTTP, SMTP). SOAP es un simple y poco complicado mecanismo para intercambiar información tipada y estructurada entre sistemas en un entorno descentralizado y distribuido usando XML. La desventaja de SOAP es, de todas formas, que es relativamente lento. SOAP está formado por tres partes. El envoltorio SOAP define un entorno de trabajo (framework, N.T.) para cada mensaje. Informa al recipiente del contenido del mensaje, a quién va dirigido y si se trata de un mensaje obligatorio u opcional. Esto se sigue de las reglas que definen, dentro del entorno de SOAP, como son codificados los datos (por ejemplo, números). XML incluye reglas que permiten un alto grado de flexibilidad. SOAP es menos flexible debido a que tiene definido un set de reglas más limitado, aunque esto no supone ningún impedimento.

Los servicios web permiten la integración de diferentes plataformas y aplicaciones de manera independiente del fabricante basándose en estándares.

Ambos, el entorno de trabajo de .NET y J2EE proporcionan una plataforma integrada para el desarrollo de servicios web.

Servicios web .NET

El entorno de trabajo de .NET (ver capítulo 3.8.2) soporta el desarrollo de servicios web profesionales. Esto comporta una reedición de Windows DNA (Distributed interNet Architecture).

.NET incluye su propio nivel de servicio para servicios web. La ilustración siguiente muestra la interacción entre los módulos individuales en lo que respecta a servicios web.

Figura 3.1. Entorno de trabajo Microsoft .NET

Arquitectura de Apañao



[6] Standards und Architekturen fÃŒr E-Government-Anwendungen, Version 1.1, KBSt Publication Series, ISSN 0179-7263, Vol. 56, February 2003, http://www.kbst.bund.de/saga

Capítulo 4. Evaluación de la eficacia económica

Introducción

Tal y como se muestra en la discusión sobre estudios disponibles hoy en día sobre el tema del COP[7] junto con el uso de PCA y productos PLC[8], la evaluación de la eficiencia económica de los proyectos de SI es, en general, una difícil tarea la cual es casi imposible de resolver a la luz de los habitualmente modelos multidimensionales de eficiencia económica.

Un análisis de amplio espectro y sobre múltiples facetas - el cual es el caso a la hora de comparar los costes de Microsoft y las plataformas PCA/PLC - debe asegurar la comparabilidad entre los asuntos analizados y la extensión apropiada del análisis como requerimientos primordiales. Una discusión demasiado estrecha de aspectos aislados puede conllevar que el resultado no sea aplicable a la escena global. Esto, por ejemplo, se hace aparente en el estudio de IDC "Windows 2000 vs. Linux für Unternehmensanwendungen" [Windows 2000 vs. Linux para Aplicaciones Empresariales] el cual fue encargado por Microsoft. Como el estudio de restringe a si mismo al coste de los servidores para funciones de infraestructura donde la relación entre los costes de las licencias y el coste total difiere del de las aplicaciones cliente, por ejemplo, no es posible derivar afirmaciones análogas respecto a la eficiencia económica en las áreas de las aplicaciones o del escritorio.

Otro aspecto a considerar en el estudio son las estructuras de usuario. El tamaño de las organizaciones y los distintos escenarios de partida para un determinado entorno de SI son aspectos particularmente relevantes al considerar la eficiencia económica de un proyecto de migración. Una observación común es que las agencias públicas pequeñas (por ejemplo, en el sector comunal) usan infraestructuras de SI que pueden ser puestas en marcha y utilizarse con medios simples y sin un entrenamiento intensivo de los usuarios. Como contraste a esto, la utilización fiable de infraestructuras o centros de computación para agencias públicas grandes o especializadas y centros de datos con contratos de nivel de servicio requieren altos niveles de entrenamiento de los usuarios, reglas organizativas para caídas de servicio y emergencias, así como máquinas distintas en algunos casos.

Tomando este marco de referencia en consideración, se requiere un enfoque multi-dimensional para poder analizar la eficiencia económica de los sistemas de información y comunicación. Incluso antes de analizar los costes de los SI, se puede obtener un incremento sustancial de eficiencia económica en la administración pública a través de medidas adecuadas relativas al personal, organizativas y de modernización. Adicionalmente, una estrategia sobre los SI adecuadamente diseñada puede también proporcionar una importante contribución a la hora de incrementar la eficiencia económica.

La eficiencia económica global de los SI está influenciada significativamente por los siguientes parámetros.

  • El grado en que los productos estándar de bajo coste cubren la funcionalidad requerida. La calidad, flexibilidad de modificación y capacidad de desarrollo de los estándares, tecnologías y productos usados.

  • Introducción efectiva y gestión del sistema.

  • La integración consistente y suave de los componentes y sistemas en una cadena de valor orientada a proceso.

  • Una buena (interna o externa) organización de servicios así como habilidades de alta calidad.

  • Ciclos de vida económica de los productos.

  • Costes y eficacia del proceso de aprovisionamiento.

  • Competencia en el sector de los productos y servicios.

La interacción óptima de todos estos factores sobre un periodo extendido de observación es un prerrequisito para establecer y controlas la eficacia económica. Esto significa que un análisis simplificado de los costes individuales falla normalmente a la hora de reflejar el escenario total.

Mas allá de la identificación y la comparación de los costes, la evaluación de los posibles valores de utilidad es otro aspecto importante de la evaluación de la eficacia económica.

Especialmente en este área, las consideraciones estratégicas y la previsión de beneficios juegan un papel importante a la hora de permitir una evaluación integral de las situaciones de partida y en perspectiva. Ejemplo: en un contexto estratégico, costes más altos en un componente individual pueden todavía llevar a un resultado total mejor gracias a la independencia entre fabricantes y por tanto de una mejor posición a la hora de negociar el coste de las licencias.

Tanto el método como el resultado pueden servir meramente como una ayuda para determinar la eficacia económica propia de una organización y de aquí obtener el desarrollo de su propia estrategia en SI.

Principios metodológicos

Aunque, generalmente, es posible comparar elementos que difieren en funcionalidad o en términos cualitativos, esto requiere un análisis coste respecto a beneficio el cual confronta también el anticipado incremento en productividad con los costes adicionales anticipados.

Sin embargo, un análisis de productividad en la cadena de valor de los SI no es posible dentro del marco de esta guía de migración ya que no hay disponibles estudios imparciales a largo plazo, especialmente en las administraciones públicas. Sobre la base de la experiencia del día a día y especialmente teniendo en cuenta que ambas plataformas Linux/UNIX y Microsoft son productos maduros con una larga historia de desarrollo, tal análisis podría llevar muy probablemente a un resultado equilibrado. Esta es la razón por la que la evaluación de la eficacia económica en esta guía de migración se centrará en un análisis directo y simplificado monetario y en análisis de beneficios.

Análisis económico

El método del valor presente neto es usado para determinar los efectos monetarios de los proyectos. Como método dinámico que es, evalúa proyectos de inversión sobre la base de su valor presente neto, por ejemplo, describiendo de forma realista los flujos de dinero (ventas y gastos, en presupuesto y fuera de él) centrándose en una referencia de tiempo común. Las ventas y los gastos que puedan ser relacionados con el proyecto pueden ser planificados con un adelanto de cinco años. El valor actual de mercado de valores futuros se determina por descuento, usando el tipo de interés oficial determinado por el Ministerio de Hacienda.

Análisis de las ventajas

El análisis de las ventajas se aplica si se decide considerar adicionalmente otros efectos que no puedan ser medidos en términos monetarios. El análisis de las ventajas evalúa de forma individual e independiente criterios objetivo ponderados que son subsecuentemente incluidos en la evaluación final. Se usan escalas de evaluación con el fin de cuantificar los llamados errores “blandos”.

Recomendamos evaluar los resultados en dos pasos según lo siguiente.

  1. Debe darse prioridad a los resultados de la evaluación monetaria de la eficacia económica. Los costes y el ahorro resultantes del proyecto se expresan como una relación de retorno de la inversión (ROI) que se ven reflejados como un valor presente neto positivo.

  2. Los resultados del análisis de ventajas se dirigen a las relaciones de urgencia y estrategia. Dentro del marco de los proyectos de migración, deben ser tratados con una prioridad inferior.

    Este segundo paso esta diseñado principalmente para gestionar casos en los que la evaluación de la eficacia económica según aspectos monetarios es o bien generalmente insuficiente o bien no permite asegurar una clara rentabilidad. Los criterios de urgencia y/o estrategia pueden requerir siempre una alta prioridad de implementación en un proyecto con independencia de los criterios monetarios.

IT-WiBe 21 (recomendaciones sobre eficacia económica en los sistemas TI)

Las evaluaciones de eficacia económica en la administración federal están sujetos a la sección 7 del Código Presupuestario Federal (§ 7 BHO) y de las regulaciones administrativas que emanan de él, el cual, desde 1995, han considerado principalmente métodos económicos. Con el fin de adaptar esas regulaciones a los requerimientos específicos sobre tecnologías de la información, La Agencia Asesora y de Coordinación sobre Tecnologías de la Información del Gobierno Federal (KBSt) ya emitió una directiva administrativa en 1992 titulada "Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen beim Einsatz der IT in der Bundesverwaltung (IT-WiBe) (recomendaciones sobre eficacia económica para sistemas de TI)“. Una versión completamente revisada se emitió en 1997. La IT-WiBe incluye tres pasos principales como sigue.

Evaluación de la eficacia económica

  • Identificación de las variables de influencia (criterio de selección)

  • Recogida / evaluación de los datos

  • Determinación de relaciones

IT-WiBe es un método que, a diferencia del CTP, considera también los posibles ahorros más allá de los aspectos de coste.

Matriz del coste de migración

Como que el método IT-WiBe es generalmente adecuado para evaluar la eficacia económica de un proyecto dado, pero es frecuentemente demasiado complejo y (debido a la falta de las cifras de presupuesto requeridas) no viable, se adopta un método simplificado – la matriz del coste de migración – a efectos de analizar la dimensión monetaria.

Esta aproximación no requiere que los costes y el ahorro se determinen según el método de selección escogido sino que en su lugar los resume en tres categorías, por ejemplo maquinaria, programas y mano de obra. La adquisición[9] y los costes de seguimiento así como otros posibles ahorros se registran en un periodo de cinco años para cada una de las categorías. Una vista completa proporciona una visión de conjunto para todos los años y categorías. Además, un análisis del ROI proporciona, de forma similar al método WiBe21, un valor actual neto descontado a la referencia temporal.

Esto da un instrumento para una rápida valoración de los volúmenes de costes del proyecto, incluyendo la investigación de costes y ahorros, así como para valoración ROI (Recuperación de la inversión)[10].

Costes totales de la propiedad (TCO)

El principio fundamental del análisis TCO es dividir los costes de un sistema TI en dos grandes grupos, p. ej. Costes directos e indirectos. Los costes directos son todos aquellos costes que pueden ser presupuestados. Una característica común a todos los costes directos es que se pueden medir en unidades monetarias. El segundo gran grupo incluye los costes indirectos que no pueden ser presupuestados. Este grupo incluye los tiempos durante los cuales los sistemas en revisión no están disponibles para usar por razones planificadas o no. Estos tiempos se pueden medir, pero no en unidades monetarias. Esto requiere a veces una conversión controvertida vía salarios pagados “en vano” o perdidas de ganancias. Los costes indirectos también incluyen cualquier actividad de usuario “no productiva”, como el auto aprendizaje, asistencia mutua, aprendizaje formal e informal, administración y copias de seguridad de datos, juegos, surfear, etc.

Este método puede, en principio, ser válido para determinar los costes de migración de los proyectos. Dado que se consideran los aspectos de costes y debido a que un análisis ROI también tendría carencias, y además todos aspectos de costes mencionados antes pueden ser direccionados con el método WiBE 21 y la matriz de costes de migración, la aproximación TCO no se utiliza para evaluar la eficacia económica de la migración de proyectos.

Comparabilidad

La evaluación de la eficacia económica se realiza para dos escenarios de modo que se asegure la comparabilidad de las distintas evaluaciones.

  • Migración de uno o varios objetos de migración[11] (migración parcial) en el caso de productos o grupos de productos claramente definibles[12].

  • Migración completa, p. ej. migración de un entorno completo de TI – Servidores, clientes, infraestructura, aplicaciones especiales.

La migración es generalmente posible de dos modos:

  • Migración de reemplazado – p. ej. la migración a un entorno completamente nuevo basado en software de Código Abierto, utilizando software de código abierto (OSS) y/o software Linux comercial (COLS) ó

  • Migración de continuidad – p. ej. la migración de el marco de productos todavía en uso a versiones más nuevas.

Un reducido catálogo de criterios, el cuál está especialmente adaptado para los casos de migraciones parciales, se utiliza para migración de objetos de la migración. Este catálogo incluye los criterios para la introducción y operación[13].

El criterio general de evaluación del método IT-WiBe, debe ser adoptado en casos de migración completa. Debido a que a veces implica la migración de aplicaciones especiales, también será necesario un trabajo de desarrollo para estas aplicaciones específicas, además de las actividades de migración para los productos estándar.

Estas reglas se aplican generalmente a casos de migración “interna” también. Si se migran productos individuales o grupos de productos (como MS Office), nos referiremos otra vez a objetos de migración y aplicaremos el catálogo de criterios. En contraste a esto, el catálogo de criterios completo de WiBe sólo se aplica en el caso de escenarios más complejos (como productos MS de comunicación y oficina, aplicaciones especiales, etc.).

Otro aspecto a tener en cuenta es que un análisis comparativo de eficiencia económica sólo tiene sentido si las diferentes alternativas se pueden comparar en términos de tecnología y funcionalidad. Las siguientes aplicaciones de Sistema Operativo y tecnología Microsoft pueden considerarse a ser comparadas para los propósitos de esta guía de migración:

  • Servicios de infraestructura:

    • Servidor de ficheros.

    • Servidor de impresión.

    • Servidor de autenticación.

    • Redes.

  • Mensajería y sistemas de trabajo en grupo.

  • Paquetes y entornos de ofimática.

  • Servidores de aplicaciones web y bases de datos.

La seguridad IT es un aspecto que hoy en día no se considera comparable a la vista de la alta exposición de los sistemas Windows. Incluso incrementando el esfuerzo y el coste, no es posible asegurar niveles de seguridad de los sistemas comparables, por lo tanto no se hace una comparación de eficiencia económica para el área de seguridad.

Nueva introducción vs. migración de sistemas.

Una análisis de costes con vistas a introducir nuevas tecnologías debe, generalmente, diferenciar entre la nueva introducción y la migración de procesos y sistemas. Como norma general, se puede decir que una nueva introducción es normalmente más simple y barata que la migración donde diferentes, y a veces, arquitecturas históricamente en crecimiento, deben ser reemplazadas y los datos migrados sin interrumpir las operaciones durante mucho tiempo y sin perdida de datos de la aplicación anterior.

Como cualquier método de migración depende siempre de su situación de partida, raramente es posible dar un dictamen válido en general para todos los casos de su coste. Aunque la migración es posible en algunos casos sin ningún problema y casi sin coste adicional, la existencia de aplicaciones a migrar desarrolladas por los usuarios, la transferencia de los datos heredados, de estructuras especiales de usuarios y de privilegios de acceso u otras características especiales pueden generar costes de proyecto sustanciales que deben evaluarse caso a caso, también teniendo en consideración aspectos críticos de la agencia pública implicada.

La dimensión monetaria (operativa)

Dimensión estratégica

Además del análisis directo monetario de los costes totales de las diferentes alternativas, debe incluirse un anális estratégico (o dimensión en terminología WiBe).

La necesidad de un análisis estratégico se origina en las repercusiones monetarias de la “dependencia de un proveedor” como factor estratégico. Esto es relevante desde un punto de vista macroeconómico y microeconómico.

Debate macroeconómico

Aspectos relativos a la competitividad son la clave en esta discusión. Las principales ventajas en competitividad funcional son las siguientes:

  • Mejor calidad del producto

  • Menores precios del producto

  • Mayor ratio de innovación

Aunque todos los fabricantes de software presumen de asegurar la mayor calidad del producto e innovación tecnológica, esta declaración de validez general puede raras veces ser hecha en la realidad. En especial, el desarrollo del World Wide Web nos muestra que Microsoft, por ejemplo, “se durmió” durante largo tiempo ante la más importante innovación de las décadas recientes.

A pesar de la naturaleza fundamental del debate macroeconómico, los lectores de esta guía de migración no pueden influir directamente en el aspecto macroeconómico que se dejará de discutir a partir de aquí con más detalle en este documento. La Comisión Europea está actualmente debatiendo la publicación de la posición monopolística de Microsoft en el campo de los sistemas operativos. Los resultados y conclusiones, en todo caso, están por ser comunicados.

Debate microeconómico

Un análisis sobre la dependencia de una agencia de probeedores de productos y servicios es el punto importante en este contexto. Aunque esta dependencia está sustancialmente alimentada y fundamentada sobre la existencia de monopolios o cuasimonopolios, la dependencia excesiva de proveedores puede ocurrir y causar desventajas económicas incluso en un entorno de competititividad funcional. Estas desventajas pueden tomar la forma de mayores precios del producto, al igual que ciclos de vida más cortos del producto y costes adicionales de introducción en el caso de migración continuada.

Bajo condiciones extremas, esta dependencia puede dar lugar a una situación donde dejen de existir precios razonables y alternativas aceptables para la actuación. En contraste a esto, una situación basada en el equilibrio estratégico da lugar a una mejor posición negociadora con acceso a alternativas ante la aparición de problemas.

Conjunto de resultados de la evaluación de la eficiencia económica

La mayor parte de los estudios relativos a este tópico usan el acercamiento al coste total en su análisis y aceptan que una parte sustancial del coste es debida a costes de personal junto con la introducción y operación más que a los costes de las licencias. Debido a diferentes suposiciones – casi todas concernientes a las capacidades de administración de sistemas – los estudios llegan a conclusiones contradictorias en lo que respecta a los beneficios económicos de las diferentes alternativas.

Los estudios favorables a Microsoft se basan en el bajo costo de personal debido a un inferior estandar de aprendizaje y por tanto a inferiores salarios básicos del personal administrativo siendo esta la más importante (aunque no única) razón para su bajo TCO calculado para plataformas Microsoft[14]. Otra ventaja – aunque también basada en suposiciones muy cuestionables – es la vista desde el campo de la seguridad en TI que se dice es generalmente más fácil de implementar en platafomas basadas en Microsoft.

Estudios escépticos de Microsoft llegan generalmente a un resultado diferente. Aunque estos estudios también encuentran una direrencia en los salarios base, esta está más que compensada por las mejores capacidades de administración, especialmente en operaciones de centros de computadoras.

Los estudios realizados en el ámbito de esta guía de migración se referirán a tres factores importantes del análisis del TCO que son necesario considerar para la introducción de Linux/OSS:

  • Porcentaje del costo de licencias software dentro del coste total.

  • Grado de especialización de sistemas de TI e infraestructuras candidatas.

  • Grado de automatización de sistemas de TI e infraestructuras candidatas.

El coste de las licencias software dentro del coste total de sistemas y procesos de TI varía del 20% al 50%. Esto es por tanto también el rango de las potenciales alternativas directas o indirectas de OSS y COLS en términos puramente monetarios ateniéndonos a la condición de que los resultados de trabajo que puedan ser realizados sean comparables.

Además de lo concerniente a la porción del coste de licencias dentro de los costes totales de TI, otros dos factores deberían ser considerados para apreciar los verdaderos grados de libertad para los que toman decisiones sobre TI. Estos son, por un lado, el índice de costes que pueden ser directamente influenciados, y por otro lado, el análisis del presupuesto de costes relevantes.

Los tipos de coste que pueden ser directamente influenciados incluyen los siguientes:

  • Costes de adquisición de software:Menores precios de compra gracias mayormente a un cambio a productos de menos costo o gracias a la negociación.

  • Costes de mantenimiento del software: Principalmente por la consolidación de productos software (reducción de la variedad de productos) o por la omisión de los ciclos de actualización.

  • Costes de adquisición del hardware: Gracias al cambio a plataformas hardware de menor coste.

  • Costes de mantenimiento del hardware: Por la consolidación del hardware (reduciendo la variedad de productos) o por la extensión de los ciclos de vida.

A diferencia de los costes hardware o software, los costes de personal, como los gastos de TI más complejos, son, normalmente, costes que no pueden ser directamente influenciados. Esto se debe al hecho de que la introducción y operación de infraestructuras y sistemas TI está principalmente relacionados con una base que está menos determinada por los modelos de licencia individual y más por los requisitos relativos a la intensidad del servicio, la disponibilidad y la seguridad de las plataformas utilizadas. La reducción del número de personal existente o la subcontratación y consolidación no suelen ser alternativas que puedan implementarse a corto plazo.

El análisis de los costes en TI que pueden estar directamente influenciados, muestran que los costes en licencias (adquisición de software, mantenimiento, actualizaciones) conforman la mayor parte y, por ello, ofrecen mayor libertad de acción.

Recomendaciones de migración basándose en la evaluación de la eficiencia económica

Las recomendaciones de migración están relacionadas con los siguientes escenarios:

  • Migración completa (para agencias públicas grandes, medianas y pequeñas)

  • Migración continua (para agencias públicas grandes, medianas y pequeñas)

  • Migración parcial (migración selectiva y migración parcial de la parte servidora)

Los ejemplos mostrados no tienen en cuenta el aspecto hardware. Las migración de hardware moderno (no más de 2 ó 3 años) es posible sin modificar el hardware. En el caso de hardware antiguo, el reemplazo o la inversión suplementaria puede ser necesaria independientemente de la dirección de la migración (Fuente Abierta o Microsoft).

El análisis monetario está basado en una media de uso de los bienes de cinco años, típico de las agencias públicas. Sólo se espera reinversión tras este plazo. Esto es igual para la migración hacia Linux como la migración interna de Microsoft (continuidad). No se asumen los costes de mantenimiento durante los cuatro años tras la adquisición.

Los cálculos se basan en supuestos precios típicos para las agencias públicas. Los cálculos incluyen, principalmente, precios de compra. También se calculan las variantes de alquiler para los productos Windows y Office.

Una comparativa relativa a los costes de migración relacionados con los usuarios para migraciones completas o continuas muestra claras ventajas en caso de migración hacia el entorno de fuente abierta.

Tabla 43: Comparativa de costes de migración relacionados con los usuarios para migraciones completas / continuas.

Los costes para migración continua son casi dos veces mayores a los costes de migración completa.

Las ventajas en coste de la migración completa se deben, principalmente, a los ahorros en software (alrededor del 92% al 95% para las agencias públicas, desde grandes a pequeñas). La comparativa de los costes de personal, en cambio, muestra diferencias a favor de la migración continua. En las agencias públicas de tipo pequeño / mediano / grande, los costes de personal para esta variante de migración oscilan a favor un 14.0% / 6.5% / 2.2%.

Una máxima es casi idéntica para ambas variantes de migración: ¡el coste se incrementa según desciende el tamaño de la organización!

Migración completa

Los ejemplos calculados indican el dominio de los costes de personal, del orden del 90% (entre el 87% y el 93%). Los costes de migración oscilan entre los umbrales de porcentaje indicados en la tabla para los distintos tipos de agencias públicas.

Tabla 44: distribución de los costes en caso de una migración completa en las agencias públicas.

Los ahorros calculados en este modelo representan el desembolso necesario para la migración desde el entorno Windows 2000.

Tabla 45: costes totales de migración por usuario en caso de migración completa

Conclusiones

Una comparación de aspectos económicos de los distintos tipos de migración indica claras ventajas de una migración parcial en el servidor final. Si una agencia pública decide migrar de forma general sus sistemas a Código Abierto, este acercamiento es recomendable desde una perspectiva comercial. Una migración amplia en el servidor final (como variante y/o estado precursor de una migración completa) brinda un especial tributo a los intereses de una agencia pública en el cliente final y por ello conduce hacia una implementación de la nueva plataforma IT más eficiente y sostenible.

Si una agencia pública decide conservar sus sistemas orientados a Microsoft, una migración continua es el procedimiento adecuado.

Las técnicas de migración completa y selectiva son acercamientos menos que óptimos desde una perspectiva económica. En el caso de requerimientos específicos y/o decisiones en una agencia pública, esos métodos pueden, sin embarbo, convertirse en el mejor acercamiento[15].

Gastos con diferentes escenarios de migración

Asunciones generales acerca de los gastos de migración

Los gastos totales de los escenarios de migración estudiados están aquí compuestos de los siguientes componentes:

  • Costes de hardware.

  • Costes de software.

  • Costes de personal.



[7] CTP = Coste Total de la Propiedad

[8] PCA = Programas de Código Abierto, PLC = Programas Linux Comerciales

[9] Los sectores de "adquisición" y "costes de seguimiento" así como la categoría del ahorro incluyen los siguientes sub-sectores: infraestructura de servidor, aplicaciones de bases de datos, mensajería / trabajo en grupo, aplicaciones web, Ofimática / escritorio y miscelánea.

[10] Referencia al capítulo “Dimensión monetaria”, diagrama “matriz de costes de migración”

[11] Referencia a la definición de objetos en el capítulo “Aproximación”

[12] Aplicaciones de escritorio como objetos de migración con procesadores de texto, análisis de hojas de cálculo, gráficos y navegación por Internet como productos.

[13] En contraste con el catálogo general de criterios, los criterios para el desarrollo han sido quitados y reemplazados por los criterios para la introducción.

[14] Refiérase al estudio de IDC “Windows 2000 vs. Linux für Unternehmensanwendugen” [Windows 2000 versus Linux para Aplicaciones Empresariales], 2002

[15] Los casos son, por ejemplo, concebibles en cuya migración de determinadas aplicaciones especiales no es posible, forzando por ello a una agencia pública a mantener sus sistemas Microsoft. En otros casos, las condiciones de servidor y cliente podrían requerir un cambio completo.

Capítulo 5. Recomendaciones de la migración

Afirmaciones de tipo general

El proceso de toma de decisiones

Los resultados de una evaluación de eficiencia económica con una perspectiva a largo plazo son cruciales para lograr una recomendación favorable a la migración o a su desarrollo. Incluso aunque la migración completa o parcial se puede llevar a cabo sin restricciones desde el punto de vista técnico, las consideraciones económicas podrían sugerir que una migración no tiene mucho sentido dadas las condiciones actuales. A la vista de las diferentes relaciones e interacciones entre componentes independientes y sistemas de cada infraestructura con el mundo de las aplicaciones, una valoración a largo plazo siempre ha de ser parte del proceso de toma de decisiones. En este contexto, el análisis desde el punto de vista de la introducción del software de código abierto no será muy diferente de los análisis de evaluación habituales en el ámbito de las TI, por ejemplo, en cuanto a la concentración (consolidación) de hardware o software. Los siguientes aspectos suelen formar parte de las estrategias tanto de administraciones públicas como de empresas:

  • Sistemas y plataformas de aplicaciones integradas mediante especificaciones y estándares abiertos, si fuera necesario incluso con la ayuda de productos de integración dedicados.

  • Sistemas y plataformas de aplicaciones integradas mediante interfaces y especificaciones propietarias de fabricantes (no publicadas o publicadas parcialmente), si fuera necesario incluso con la ayuda de productos de integración específicos de fabricantes.

  • Uso (histórico) de soluciones independientes para métodos y aplicaciones selectivos especializados.

Dado que el software abierto suele asociarse, por su origen, con el uso de estándares abiertos, constituye otra variante en este campo:

  • Sistemas y plataforma de aplicaciones integrados en función de especificaciones y estándares abiertos utilizando código abierto (reutilizable).

Si bien una decisión a favor de la introducción selectiva de un producto de código abierto muy utilizado, como el servidor web Apache, suele conseguirse de forma muy pragmática y rápida, la decisión a favor de la introducción generalizada de software de código abierto y la sustitución de islas propietarias requiere un enfoque metódico por su repercusión a largo plazo. Los puntos clave de un enfoque semejante son los siguientes:

  • Desarrollo de una estrategia global de TI, teniendo en cuenta los objetivos financieros, organizativos, de innovación y personales.

  • Definición del futuro estratégico de la plataforma de código abierto, teniendo en cuenta los cálculos de la eficiencia económica a largo plazo, sin dejar de lado el uso de productos estándar tanto gratuitos como comerciales (consulte “ Modelo de arquitectura”, modelo de software abierto frente al modelo de software comercial para Linux).

  • Identificación en el anteproyecto de todos los estándares necesarios para garantizar la posibilidad de reutilización tanto interna como externa, así como la interoperatividad.

  • Selección de los productos que cumplan los requisitos

  • Definición del proyecto, incluido el cronograma correspondiente, la lista de actuaciones, así como la garatía de respetar el presupuesto Como se puede apreciar en la siguiente ilustración, los métodos y herramientas utilizadas ya en las administraciones públicas se pueden utilizar para las diferentes fases.

Como se puede apreciar en la siguiente ilustración, los métodos y herramientas utilizadas ya en las administraciones públicas se pueden utilizar para las diferentes fases.

Estrategia Plataforma Estándares Productos Proyectos Estrategia de TIC CTP SAGA WiBe‘21 Vd lGuía de migración Figura 77: Toma de decisiones para la introducción de software abierto

Recomendaciones generales

A la vista de las diferentes situaciones de partida (incluidas las soluciones aisladas), por lo general hacer afirmaciones válidas relativas a las ventajas económicas de las estrategias de plataforma sólo es posible en contadas ocasiones. No obstante, se puede decir en general que la eficiencia económica aumenta en función del grado de integración de los productos de una plataforma. Esto se debe a varias razones:

  • Mayor productividad en el caso de productos correctamente integrados (sin inconsistencias del sistema)

  • Mayores posibilidades de reutilización de componentes y soluciones que fueron desarrollados sobre la base de las mismas tecnologías intermedias

  • Ahorro debido a procesos estandarizados de adquisición y mantenimiento, así como acuerdos de asistencia técnica en caso de ser necesarios.

Además, un mayor nivel de estandarización sobre la base de estándares abiertos también impulsa la eficiencia económica en conjunto. Esto se debe a diversas razones que comentamos a continuación:

  • Provoca la competencia entre productos y soluciones

  • Reduce la dependencia de los fabricantes

  • Generalmente se amplían los mercados de servicios

En concreto (si bien no únicamente), la adopción de SAGA (estándares y arquitecturas para aplicaciones de e-gobierno o Standards and Architectures for e-government Applications) y de sistemas de estandarización interna en el seno de las administraciones públicas han aumentado la seguridad en la inversión para proveedores comerciales de software basado en Linux. Esto se refleja en el número creciente de proveedores de componentes básicos y métodos especializados, que han creado una situación en la que ya es posible efectuar una migración completa, algo que hasta hace poco tiempo era difícil. Partiendo de esta base, se pueden hacer las siguientes recomendaciones generales para el uso de productos de código abierto.

  • Adoptar la eficiencia económica como objetivo general de toda la estrategia de TI, teniendo en cuenta adecuadamente los factores de innovación y organización.

  • Usar el sistema operativo Linux como base de la plataforma de TI en todos los campos de aplicación siempre que los requisitos para la migración total o parcial se cumplan (consulte las secciones 5.2 y 5.4).

  • Usar estándares abiertos, que cuentan con el reconocimiento tanto de la industria de las TI como de la comunidad de código abierto, como base para la selección e integración de productos de software mediante los que evitar casos de dependencia excesiva de un fabricante.

  • Implantación de una evaluación de proyectos en función de la eficiencia económica a fin de colaborar en la toma de decisiones en el uso de productos gratuitos y comerciales basados en Linux (consulte el capítulo 4)

La migración a la plataforma de software de código abierto o a software comercial para Linux puede en general resultar lo más razonable desde el punto de vista económico (más provechoso) en comparación con una migración continua a las nuevas versiones de Microsoft. La omisión o reducción de costes por licencia puede conducir a un ahorro directo (económico), por ejemplo en los siguientes casos:

  • La migración parcial de servidores, gracias a la abundancia de conocimientos acerca de hardware y software UNIX, más los sistemas UNIX ya es posible

  • La sustitución selectiva de miembros de la antigua familia de gestión (hoy en día: .NET Enterprise Server), como Exchange o SQL Server, especialmente en casos de numerosos usuarios y, por lo tanto, licencias.

  • La migración parcial de productos de Office de MS en los clientes a menos que el uso de Office como entorno de ejecución de macros o aplicaciones impida la sustitución

En muchas otras situaciones de aplicación, la dimensión estratégica ha de tenerse en cuenta para valorar correctamente el posible ahorro. El capítulo titulado "Evaluación de eficiencia económica" trata esta dimensión estratégica en profundidad. En cualquiera de los casos ha de tenerse en cuenta el coste de formación como aspecto económico, tanto en la migración de plataformas actuales a Linux como a un nuevo nivel de Microsoft.

Dado que tales costes forman parte de un análisis realista de ambos casos, se puede considerar que este segmento del coste es prácticamente neutral en la comparación de las alternativas. Además, los costes de adaptar aplicaciones especializadas existentes también ha de tenerse en cuenta en ambos casos, esto es: para las dos alternativas[16]. Ya que las recomendaciones generales no pueden tratar los requisitos y marcos de referencia de una situación de partida concreta, se optará por hacer más recomendaciones en cuanto a las diferentes situaciones. La sección 5.2 trata el caso de una migración completa, la 5.3 examina la situación en que las diversas plataformas quedan estables, y la sección 5.4 analiza un entorno híbrido (migración parcial).

Migración de tipo "sustitución total"

La migración completa como se ha definido en esta guía consiste en introducir Linux como sistema operativo en todos los componentes de la infraestructura de TIC. Una sustitución completa de sistemas operativos también suele implicar la sustitución con productos compatibles con SAGA a nivel de integración y aplicación porque los productos necesarios, en concreto Java, aún no han alcanzado el grado de difusión esperada[17]. Dos variantes de software que suelen combinarse suelen estar, por regla general, disponibles para realizar una migración completa: SCA: software de código abierto (o so ftware libre)[18]: software de código abierto y gratuito desarrollado por la comunidad de código abierto SCOL: software comercial para Linux: software comercial, de código abierto o propietario para Linux ofrecido por desarrolladores de software. Dado que muchas áreas de la administración pública emplean de forma intensiva aplicaciones especializadas basadas en Windows y desarrolladas por las propias administraciones, así como sistemas de aplicaciones basados en ERP, es de suponer que el software de código abierto cumplirá todos los requisitos en el área de infraestructuras únicamente en un futuro próximo. A la vista de la positiva promoción de Linux gracias a la disponibilidad de grandes sistemas de aplicaciones de fabricantes como SAP y Oracle, el uso de software comercial y el creciente número de programas para Linux pueden verse como una evolución positiva para el mayor desarrollo de la plataforma de código abierto, lo que conducirá a un apogeo mayor en el avance de esta plataforma.

Las características específicas de las arquitecturas de software y de sistemas posibles y recomendadas pueden variar en función del tamaño, la intensidad de la TIC y el grado de especialización del organismo público. Las posibilidades de ampliación y disponibilidad de los componentes concretos por un lado, y la información necesaria para la introducción por el otro, desempeñan un papel decisivo en este contexto. Esta es la razón por la que los aspectos concretos se tratan por separado, por ejemplo: para organismos grandes y medianos, además de los especializados y los más pequeños. A modo de introducción, vamos a tratar un modelo general y por tanto genérico para tareas de infraestructuras.

Modelo de arquitectura

Suponiendo un uso consistente de Linux como plataforma para aplicaciones de cliente y servidor, se pueden distinguir dos tipos de arquitecturas para clientes análogas a las habituales de UNIX y Windows: clientes completos y tontos.

Figura 78: Arquitectura del sistema con un cliente completo basado en Linux

La configuración que aparece en la arquitectura de la Figura 78 con un cliente completo basado en Linux es representativa de estaciones de trabajo con capacidad multifunción en una infraestructura distribuida con equipos personales disponibles comercialmente (cliente completo). La plataforma de servidor se encarga de las funciones de infraestructura habituales, y un servidor de aplicaciones completa el equipamiento para conformar una arquitectura de 3 capas.

Los componentes seleccionados cubren diversas aplicaciones, incluidas por ejemplo las siguientes:

  • Estaciones de trabajo (personales y de oficina).

  • Programas de trabajo en grupo (servidor de correo calendarios).

  • Sistemas de bases de datos (servidor DBMS).

  • Servidor web.

  • Servidor de archivos.

  • Servidor de impresión.

  • Servicios de autenticación.

  • Servicios de red (entre ellos, pero no únicamente: servidor DNS y DHCP).

Las áreas entramadas de la Figura 78 se pueden utilizar independientemente del tamaño y nivel de especialización del organismo público. El resto de los componentes del sistema serán tratados en las siguientes secciones en el contexto de sus diferentes situaciones de aplicación, a saber:

  • Organismos públicos grandes y medianos.

  • Organismos públicos especializados con servicios de TIC.

  • Organismos públicos pequeños.



[16] El análisis de este segmento de coste no consta entre los objetivos de esta guía. Suele requerir análisis muy específicos en los diferentes organismos públicos afectados, una tarea que no puede llevarse a cabo en una guía de migración. Los aspectos correspondientes al marco de una evaluación de eficiencia económica pueden variar en cada caso si los costes de migración determinados para aplicaciones especializadas se incluyen en el análisis.

[17] En este caso, las aplicaciones web del modelo (L)AMP, que también se utilizan muy frecuentemente en Windows, no se ven afectadas por la necesidad de una migración.

Capítulo 6. Autores y contribuciones expertas

La lista en orden alfabético:

Bernd Dersch

Experto en estrategia en TI, conceptos operacionales, aplicaciones de base de datos y aplicaciones web. Ha sido Director y Autor en este proyecto.Entre otras cosas a contribuido como autor en las discusiones técnicas de la migración del escritorio.

<bernd.dersch@csar-ag.com>

Frank Gamerdinger

Experto en Open Office y StarOffice, ha contribuido en las discusiones técnicas de la migración de Office.

<rank.gamerdinger@sun.com>

Peter Ganten

Está especializado en servicios de directorio, migración de Windows basado en dominios NT a Samba y OpenLDAP bajo Linux, as well as thin clients y integración de aplicaciones Windows sobre escritorio Linux. Como autor ha estado implicado en las correspondientes secciones de esta guía de migración.

<ganten@univention.de>

Birgit Gregor

Es experta en organización, workflow y optimización de procesos. Ella escribió la parte de los factores de sucesos críticos.

<birgit.gregor@eds.com>

Roberto Herrmann

Está especializado en análisis económicos y administrando proyectos en TI. En este proyecto ha contribuido como autor, en la evaluación de la eficiencia económica.

<roberto.herrmann@csar-ag.com>

Sebastián Hetze

Ha contribuido como autor, en las secciones sobre bases de datos, archivos de sistema, redes y administración de los servicios del sistema en esta guía de migración. Está especializado en bases de datos y archivos de sistema bajo Linux así como en formatos de intercambio de datos.

<s.hetze@linux-ag.de>

Volker Lendecke

Es miembro del equipo de desarrollo del núcleo de Samba. En este aspecto ha hecho importantes contribuciones en las discusiones técnicas de los siguientes servicios de infraestructura: archivos de sistema, autentificación y servicios de impresión.

<vl@sernet.de>

Gregor Lietz

Puso su énfasis también, en el ámbito de las arquitecturas corporativas y se ocupó en particular de alinear la eficiencia en estrategias de TI para organizaciones y corporaciones. Es miembro en la comisión de expertos SAGA del Ministerio del Interior Federal Alemán y fue responsable de la redacción del manual de migración. Como autor ha participado en varias secciones, entre otras cosas en vista de economía, así como caminos de migración y recomendaciones.

<gregor.lietz@eds.com>

Michael Meskes

Está especializado en DBMS y particularmente en PostgreSQL y ha contribuido con las discusiones técnicas en estos aspectos.

<Michael.Meskes@credativ.de>

Kurt Pfeifle

Está especializado en la integración de servicios de impresión en entornos heterogéneos de redes amplias y ha contribuido como autor con las discusiones de servicios de impresión.

<kpfeifle@danka.de>

Dr. Klaus Schmidt

Es experto en infraestructura de TI y desarrollo de producto. En esta capacidad, el es, en particular, especialista en soluciones de alta disponibilidad. Ha estado implicado en las secciones correspondientes de esta guía de migración.

Holger Stautmeister

Es especialista en tecnologías web, contenido y conocimientos de administrador de sistemas. En esta conexión ha contribuido entre otras cosas como autor en los capitulos de migración de servidores web y aplicaciones para trabajo en grupo.

<holger.stautmeister@eds.com>

Sebastián Stöcker

Está especializado en infraestructuras Microsoft y arquitectura de sistemas, ha escrito partes importantes de las discusiones técnicas relacionadas con los componentes de Microsoft.

Thomas Uhl

Trabaja en integración de sistemas abiertos, especialmente en el área del Código Abierto. Escribió partes de las discusiones técnicas de apliciones para trabajo en grupo y servicios de terminal.

<thomas.uhl@to.com>

Abreviaturas

ACE

Entradas de Control de Acceso (Access Control Entries)

ACL

Lista de Control de Acceso (Access Control List)

AD

Directorio Activo (Active Directory)

ADAM

Modo de Aplicación del Directorio Activo (Active Directory Application Mode)

ADC

Conector Activo de Directorio (Active Directory Connector)

ADO

Objetos de Datos Actives (ActiveX Data Objects)

ADS

Servicio Activo de Directorio (Active Directory Service)

ADSI

Servicio de Interface de Directorio Activo (Active Directory Service Interface)

AFS

Archivos de Sistema Andrew (Andrew File System)

API

Interface de Programación de Aplicaciones (Application Programming Interface)

APOP

Protocolo Autentificado de Envio de Correo (Authenticated Post Office Protocol)

APT

Paquete de Herramientas Avanzado (Advanced Package Tool)

ASCII

Código Estandar Americano para Intercambio de Información (American Standard Code for Information Interchange)

ASF

Fundación Apache Software (Apache Software Foundation)

ASP

Servidor de Páginas Activas (Active Server Pages)

BB

Tablón de Boletines (Bulletin Boards)

BDC

Controlador de Backup de Dominio (Backup Domain Controller)

BfD

Comisión de Protección de Datos Federal (The Federal Data Protection Commissioner)

BHO

Federal Budget Code

BIND

Nombre de Dominio de Internet de Berkeley (Berkeley Internet Name Domain)

BMI

Ministerio del Interior Federal (Federal Ministry of the Interior)

BSD

Distribución de Software de Berkeley (Berkeley Software Distribution)

BSI

Oficina Federal Alemana para la Seguridad de la Información (German Federal Office for Information Security)

BVA

Bundesverwaltungsamt

CA

Autoridad de Certificación (Certification Authority)

CDO

Colaboración de Objetos de Datos (Collaboration Data Objects)

CGI

Interfaz de Entrada Común (Common Gateway Interface)

CIFS

Archivos de Sistema de Internet Comunes (Common Internet File System)

CIM

Modelo de Información Común (Common Information Model)

CIS

CIS COM Servicio de Internet (COM Internet Service)

CLR

Lenguaje Común de Activación (Common Language Runtime)

cn

Nombre Común (commonName)

CO

Crossover Office

COM

Modelos de Objetos de Componentes (Component Object Models)

COM+

Modelos de Objetos de Componentes (Component Object Models)

CORBA

Common Objects Request Broker Architecture

COLS

Software Linux Comercial (Commercial Linux Software)

CPU

Unidad Central de Proceso (Central Processing Unit)

CSS

hojas de Estilo en Cascada (Cascading Style Sheets)

CUPS

Sistema de Impresión Común UNIX (Common UNIX Printing System)

DACL

Discretionary Access Control List

DAV

Distributed Authoring and Versioning

DBMS

Sistema de Administración de Base de Datos (Database management system)

dc

Componente de Dominio (domainComponent)

DCOM

Componentes de Mdelos de Objetos Distribuidos (Distributed Component Object Models)

DDE

Intercambio de Datos Dinámico (Dynamic Data Exchange)

DDNS

DNS Dinámica (Dynamic DNS)

DFS

Archivos de Sistema Distribuidos (Distributed File System)

DHCP

Protocolo de Configuración de Host Dinámico (Dynamic Host Configuration Protocol)

DLC

Control de Enlace a Datos (Data Link Control)

DLL

Enlace a Librerias Dinámicas (Dynamic Link Libraries)

DMS

Sistema de Administración de Documentos (Document management system)

DNS

Servidor de Nombres de Dominio (Domain Name Server)

DNSSEC

Servidor de Nombres de Dominio Seguro (Domain Name System Security)

DRBD

Distributed Replicated Block Device

DS

Servicio de Directorio (Directory Service)

DSO

Objetos Dinámicos Compartidos (Dynamic Shared Objects)

DTD

Definición de Tipode Documento (Document Type Definition)

DTS

Servicios de Transformación de Datos (Data Transformation Services)

E2K

Exchange 2000

EFS

Sistema de Ficheros Encriptado (Encrypting File System)

EJB

Enterprise Java Beans

EMF

Enhanced Meta Format

ESC/P

Lenguaje de Impresoras Epson (Epson Printer Language)

EXT2

Sistema de ficheros extendido version 2 (Extendend Filesysten Version 2)

EXT3

Sistema de ficheros extendido version 3 (Extended Filesystem Version 3)

FAT

Tabla de localizacion de Ficheros (File Allocation Table)

FQDN

nombre calificado completo de dominio (Full Qualified Domain Name)

FRS

Servicio de replicacion de ficheros (File Replication Service)

FSG

Grupo de estandares libres (Free Standard Group)

FSMO

Flexible Single Master Operation

FTP

Protocolo de transferencia de ficheros (File Transfer Protocol)

GC

Catalogo Global (Global Catalog)

GDI

Dispositivo de Interface Grafica (Graphics Device Interface)

GNOME

Ambiente de modelacion de objetos de red GNU (GNU Network Object Model Environment)

GNU

GNU no es Unix (GNU's Not UNIX)

GPL

Licensia Publica General (General/Gnu Public License)

GPOs

Objetos de Politicas de grupos (Group Policy Objects)

GPS

Sistema de posicionamiento global (Global Positioning System)

GUID

Identificador unico global (Global Unique Identifier)

HACMP

Protocolo de administracion de clusters de alta disponibilidad (High Availability Cluster Management Protocol)

HD

Disco Duro (Harddisk)

HIS

Host Integration Server

HP

Hewlett-Packard

HSM

Hierarchical Storage Management

HTML

Lenguaje de etiquetas de hipertexto (Hypertext Markup Language)

HTTP

Protocolo de transferencia de hipertexto (Hypertext Transfer Protocol)

HTTPS

Protocolo seguro de transferencia de hypertexto (Hyper-Text Transfer Protocol Secure)

ICA

Independent Computing Architecture

IDE

Ambiente de desarollo integrado (Integrated Development Enviroment)

IEAK

Kit de adminstracion de Internet Explorer (Internet Explorer Administration Kit)

IETF

Fuerza de trabajo de Ingenieria de internet (Internet Engineering Task Force)

IIOP

Internet Inter-ORB Protocol

IIS

Servidor de Informacion de internet (Internet Information Server)

IMAP4

Protocolo de acceso al correo de internet version 4 (Internet Mail Access Protocol 4)

IMAPS

Protocolo Seguro de acceso al correo de internet (Internet Mail Access Protocol Secure)

IPC

Comunicacion interprocesos (Interprocess Communication)

IPP

protocolo de impresion sobre internet (Internet Printing Protocol)

Ipsec

protocolo seguro de internet (Internet Protocol Security Protocol)

IPv6

Protocolo de internet version 6 (IP Version 6)

IPX

Intercambio de paquetes entre redes (Internet Packet Exchange)

IRC

Internet Relay Chats

IS

Almacenamiento de informacion (Information Store)

ISA

Servidor de seguridad y aceleracion de internet (Internet Security and Acceleration)

ISAPI

interface de programacion para aplicaciones de servicios de internet (Internet Service Application Programming Interface)

ISC

Consorcio de software de Internet (Internet Software Consortium)

IT-WiBe

Recommendations on economic efficiency assessments for IT systems at the federal administration

J2EE

Edicion empresarial de Java2 (Java 2 Enterprise Edition)

J2SE

Edicion estandard de Java2 (Java 2 Standard Edition)

JAXP

API de java para XML (Java API for XML)

JDBC

Conector de java para base de datos (Java Database Connection)

JFS

Sistema de ficheros con journal (Journaled File System)

JIT

Justo a tiempo (Just In Time)

JMC

Servicio de mensajes Java (Java Message Service)

JNDI

Interface de nombres y directorios de Java (Java Naming and Directory Interface)

JRE

Ambiente de ejecucion de Java (Java Runtime Environment)

JRMI

invocacion a metodos remotos de java (Java Remote Methode Invocation)

JSP

Servidor de Paginas Java (Java Server Pages)

JTA

API de transacciones Java (Java Transaction API)

JVM

Maquina Virtual de Java (Java Virtual Machine)

KBSt

Agencia federal de Coordinacion y alertas patra tecnologias de la informacion de la administracion Federal (Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration)

KDC

Centro distribuidor de claves (Key Distribution Center)

KDE

Ambiente de escritorio K (K Desktop Environment)

KMS

Servidor de administracion de claves (Key Management Server)

LAMP

Linux, Apache, MySQL, PHP

LAN

Red de area local (Local Area Network)

LANANA

Autoridad de asignacion de nombres y numeros de linux (Linux Assigned Names and Numbers Authority)

LDAP

Protocolo liviano de acceso a directorio (Lightweight Directory Access Protocol)

LDIF

Formato de intercambio de informacion de datos Ldap (LDAP Data Interchange Format)

LGPL

Lesser General Public License

Li18nux

Iniciativa de internacionalizacion de linux (Linux Internationalization Initiative)

LM

Administrador de red (LAN Manager)

LMRepl

Servicio de replicacion de directorios (Directory replication service)

LPD

Demonio de impresion en linea (Line Printing Daemon)

LPI

Instituto profesional de linux (Linux Professional Institute)

LPR

Redirector de impresiones en linea (Line Printing Redirector)

LSB

Base estandard de linux (Linux Standard Base)

LTSP

Proyecto de servicios de glossterminal en Linux (Linux Terminal Server Project)

LVM

Administrador de volumenes logicos (Logical Volume Manager)

LVS

Servidor virtual de linux (Linux Virtual Server)

MAC

Control de acceso al medio (Media Access Control)

MAPI

Interface de programacion para mensajes (Messaging Application Programming Interface)

MD

hombre-dia (Man-day)

MDX

Message Digest X

MLP

Protocolo de enlaces de mensaje/Multicapas (Message/Multilayer Link Protocol)

MMC

Consola de administracion de Microsoft (Microsoft Management Console)

MMQS

Servidor de colas de mensajes de microsoft (Microsoft Message Queue Server)

MOM

Servidor de operaciones de microsoft (Microsoft Operation Manager)

MPL

Lisencia publica de mozilla (Mozilla Public License)

MRTG/RRD

graficas de trafico e mltiples rutas (Multi Router Traffic Grapher/Round Robin Database)

MS

Microsoft

MSMQ

Coola de mensajes de Microsoft (Microsoft Message Queuing)

MSPS

Estandares propietarios de microsoft (Microsoft Proprietary Standards)

MTA

Agente transmisor de mensajes (Message Transfer Agent)

MTBF

tiempo entre fallas (mean time between failure)

MTS

Servidor de transacciones de microsoft (Microsoft Transaction Server)

MTTR

tiempos de reparacion (Mean Time To Repair)

NAS

Almacenamiento adjunto a la red (Network Attached Storage)

NAT

Network Address Translation

NCSA

National Center for Supercomputing Application

NetBEUI

NetBIOS Extended User Interface

NetBIOS

Network Basic Input and Output System

NetBT

NetBIOS over TCP/IP

NFS

Network File System

NIS

Network Information Service

NNTP

Network News Transport Protocol

NPL

Netscape Public License

NTDS

NT Directory Service

NTFS

NT File System

NTFS4

NT File System 4

NTFS5

New Technology File System 5

NTLM

Windows NT LAN Manager

NTLMv2

Windows NT LAN Manager Version 2

NTP

Network Time Protocol

ODBC

Open Database Connectivity

OLAP

Online Analytical Processing

OLE

Object Linking and Embedding

OMG

Object Management Group

OOo

OpenOffice.org

OOo/SO

Open Office.org/StarOffice

OpenLDAP

Directory service

OSI

Open Systems Interconnection

OSOS

Open Standards mit Open Source

OSS

Open Source Software

OU

Organizational Unit

OWA

Outlook Web Access

PAM

Pluggable Authentication Module

PBS

Portable Batch System

PCL

Printer Control Language

PDA

Personal Digital Assistant

PDC

Primary Domain Controller

PDF

Portable Document Format

Perl

Practical Extraction and Report Language

PHP

PHP Hypertext Pre-processor

PIM

Personal Information Manager

PKI

Public Key Infrastructure

POP3

Post Office Protocol Version 3

POSIX

Portable Operating System Interface for UNIX

PPD

PostScript Printer Descriptions

RAC

Real Application Cluster

RAID

Redundant Array of Inexpensive/Independent Discs

RAM

Random Access Machine/Memory

RAS

Remote Access Service

RAW

Read After Write

RDBMS

Relational Database Management System

RDP

Remote Desktop Protocol

ReiserFS

Reiser File System

RFCs

Request for Comments

RHCE

Red Hat Certified Engineer

RID

Relative Identifier

RISC

Reduced Instruction Set Computer

RPC

Remote Procedure Calls

RPM

Red Hat Packet Management

S/MIME

Secure MIME (Multipurpose Internet Mail Extensions)

SA

System Attendant

SACL

System Access Control List

SAGA

Standards and Architectures for e-government Applications

SAM

Security Accounts Manager

SAN

Storage Area Network

SASL

Simple Authentication and Security Layer

SC

Samsung Contact

SCM

Security Configuration Manager

SCSI

Small Computer System Interface

SFU

Service for UNIX

SID

Security Identifier

SISL

Sun Industry Source License

SLAs

Service Level Agreements

SMB

Server Message Block

SMS

Short Message Service

SMS

System Management Server

SMTP

Simple Mail Transfer Protocol

SNA

Storage Network Attached

SNMP

Simple Network Management Protocol

SO

StarOffice

SOAP

Simple Object Access Protocol

SPM

Standard TCP/IP Port Monitor

SPX

Sequenced Packet Exchange

SQL

Structured Query Language

SQL-DMO

SQL Distributed Management Objects

SRS

Standard Replication Service

SSH

Secure Shell

SSL

capa de comunicaciones segurasSecure Sockets Layer

SSL/TLS

Secure Sockets Layer / Transport Layer Security

SW

Software

TB

Terabyte

TCL

Tool Command Language

TCO

Total Costs of Ownership

TCP/IP

Transmission Control Protocol / Internet Protocol

TDS

Tabular Data Stream

TGS

Ticket Granting Service

TGT

Ticket Granting Ticket

TTS

Trouble Ticket System

UDDI

Universal Description, Discovery and Integration

UDP

User Datagram Protocol

UHD

User Help Desks

UNC

Uniform Naming Convention

UNO

Universal Network Objects

URL

Uniform Resource Location

USB

Universal Serial Bus

USN

Unique Sequence Number

VBA

Visual Basic for Applications

VBS

Visual Basic Scripting Edition

VBScript

Visual Basic Script

VFS

Virtual File System

VLDB

Very Large Database

VPN

Virtual Private Network

W2K

Windows 2000

W3C

World Wide Web Consortiums

WAP

Wireless Application Protocol

WBEM

Web Based Enterprise Management

WebDAVS

creación y versionado de documentos webWeb Document Authoring And Versioning

WINS

Windows Internet Name Service

WSDL

Web-Services Description Language

WSH

anfitrión de scripts de WindowsWindows Sripting Host

WWW

World Wide Web

XFS

Extended File System

XSL

Extensible Style Sheet Language

XML

Extensible Markup Language

YaST

Yet another Setup Tool

Glosario

ADO

ADO significa Active Data Objects (Objetos de Datos Activos) y representa una interfase de alto nivel (por ejemplo de Visual Basic) para acceso general a datos desde Micorsoft™ por medio de un proveedor OLE DB (por ejemplo, para SQL Serverm ODBC, Oracle, Active Directory Service - Servicio de directorio activo, etc ). ADO incluye objetos para establecer la conexión a una fuente de datos, y para operaciones de lectura, actualización, escritura y borrado.

ACL

Una Acces Control List (Lista de Control de Accesos) es una lista con privilegios de acceso. Estas listas sirven como base para controlar el acceso a los recursos del sistema de IT, El sistema usa las ACLs para decidir que acceso tiene un usuario a un recurso, como ser un directorio.

ActiveX

Un término colectivo para una tecnología introducida por Microsoft™ que habilita contenidos (inter) activos en sitios web. El browser baja partes de programa Activex desde el servidor y las ejecuta en la PC del usuario. Activex fue desarrollado por Microsoft™ como una alternativa a los applets JAVA™.

API

Application Programming Interface - Interfase para programación de aplicaciones (un interfase de programación definida que puede ser usada para integración y expansión).

ASP

Active Server Pages - Páginas de Servidor Activas; es el concepto de Microsoft™ para generar sitios web dinámicos (consultar también “JSP”) del lado del servidor (usando, por ejemplo, JavaScript o Visual Basic Script).

C#

Un lenguaje de programación orientada a objetos desarrollado por Microsoft™ en base a C y C++.

CGI

La Interfase Común de Entrada (Common Gateway Interface) fue la primera variante de las interfases de servidores web. Practicamente todos los servidores web modernos soportan esta interfase. Las aplicaciones que usan CGI pueden ser desarrolladas en diferentes lenguajes de porgramación. Además de lenguajes interpretados, como PERL, también es posible utilizar aplicaciones compiladas que hayan sido escritas en C o C++.

COM

El Modelo de Objetos de Componentes(Component Object Model) es un estándar de software de Microsoft™ que habilita la comunicación entre procesos y programas. Para este propósito, COM define una interfase orientada a objetos que un porgrama o componente de software utiliza para hacer los servicos disponibles.

CORBA

CORBA significa Arquitectura de Inglosstermediario Común para Requisición de Objetos (Common Object Request Broker Arquitecture) y fue desarrollada con el objeto de habilitar la comunicación entre aplicaciones independientemente de la ubicación, plataforma e implementación. CORBA es un estándar abierto definido por el Object Management Group - Grupo de Gerenciamiento de Objectos (OMG).

DCOM

El Modelo de Objetos de Componentes Distribuidos (Distributed Component Object Model) es una variante del estándar COM de Microsoft™. DCOM puede usarse para la distribución de servicos de un software. DCOM utiliza RPC (Remote Procedure Calls - Llamada a Procedimientos Remotos) para la implementación con el fin de llamar procesos en una computadora remota por medio del intercambio de mensajes.

DDE

El Intercambio de Datos Dinámico (Dynamic Data Exchange) es un procedimiento bajo Windows™ que permite a los porgramas de usuario intercambiar datos. El intercambio de datos en si mismo es un proceso dinámico. Si un archivo conectado por DDE es cambiado, el cambio es automáticamente transferido a todos los archivos comunicados con el archivo involucrado.

DHCP

El Protocolo de Configuración Dinámica de Anfitrión (Dynamic Host Configuration Protocol) crea las bases para la asignación dinámica de direcciones IP. El cliente DHCP dinámicamente recibe una dirección IP desde un servidor DHCP central. Además de la dirección IP, otros parámetros de configuración pueden ser enviados al cliente.

DNS

El Sistema de Nombres de Dominio (Domain Name Server) es un sistema con una estructura jerárquica para la asignación de nombres a las computadoras conectadas a Internet/Intranet.

DTD

Las Definiciones de Tipo de Documento (Document Type Definitions) definen formalmente al estructura de un docuemnto XML. Deglossterminan la sintáxis que se aplica a un tipo de documento particular (y por lo tanto a un formato de datos particular).

Emulación

La capacidad de de un sistema o programa para simular la operación de otro sistema de computación utilizando recursos de hardware o software.

Failover

Esta es una característica específica de software o hardware, por ejemplo de una base de datos, servidor o red, que se configura en una forma que sus servicios se inician automáticamente por un sistema con funciones idénticas o similares en el caso de una falla temporal de sistema.

HTML

Lenguaje de Marcas de Hipertexto (Hypertext Markup Language) - Es el estándar abierto y el formato de archivo para la presentación de contenidos en Internet e Intranets.

HTTP

Un estándar para interacción electrónica durante la transmisión de documentos web en Internet.

IMAP

El Protocolo de Acceso a Correo de Internet (Internet Mail Access Protocol) puede ser usado para administrar casilla de e-mail. A diferencia de POP3, IMAP administra los e-mails en el servidor. Cuando el porgrama de correo comienza, solo los datos de encabezado (remitente, referencia y fecha de recepción) se carga por defecto. El receptor puede entonces seleccionar los mails a bajar en forma completa. Los correos que quedan en el servidro puedens er archivados en carpetas especiales.

IPSec

Un estándar para soluciones de seguridad en redes que es particularmente adecuada para la implementación de VPNs y para acceso remoto a redes privadas por medio de conexiones telefónicas.

Ipv6

La nueva versión 6 del Protocolo de Internet (IP) con direcciones IP de 128 bits en lugar de los 32 bits de Ipv4. Esto puede crear más opciones de direccionamiento para sitios web.

IPX

Un estándar para la transmisión de datos definido por Novell.

Java

Un lenguaje de programación desarrollado por SUN Microsystems™ que es usado especialmente en el campo de la tecnología de Internet. Un asi llamado compilador traduce el texto fuente a código inglosstermedio independiente de la plataforma. El código inglosstermedio entonces puede ser ejecutado por un interprete adecuado en cualquier computadora. Esto permite la ejecución de programas Java en cualquier plataforma de computación para la que exista el programa interprete adecuado.

Java Beans

Los Java Beans son componentes de software reusables implementados en Java.

JavaScript

Un lenguaje de script originalmente definido por Netscape para conectar código de programa a páginas HTML estáticas. El código es generalmente ejecutado en el browser del usuario.

JDBC

La Conectividad a Base de Datos Java (Java Database Conectivity) ofrece un mecanismo para comunicarse con las bases de datos existentes. Los drivers sirven como la interfase entre el porgrama Java y la base de datos.

JSP

Las Páginas de Servidor Java (JavaServer Pages) son archivos HTML con código de programa Java embebido que se convierte en servlets por un motor JSP que son luego ejecutados en el servidor web. El resultado se envia luego en formato HTML normal al cliente (consultar también "ASP").

LAMP

Un plataforma de software libre para desarrolladores web y aplicaciones web basado en Linux, Apache, MySQL y PHP y/o PERL o Python.

LDAP

El Protocolo Liviano de Acceso a Directorio(Lightweight Directory Access Protocol) (X.509) es una versión simplificada de DAP (X.500). LDAP se usa para acceder a servicios de directorio que pueden, por ejemplo, ser usados para consultar características de los usuarios.

Macro

Una combinación de instrucciones individuales y/o una secuencia de comandos y procesos que pueden ser grabados y guardados. Cuando se llama una macro, los procesos y acciones se ejecutan automáticamente en el orden correcto.

MP3

Un formato estándar para archivos de audio comprimido que fue desarrollado por el Instituto Fraunhofer dentro del marco de MPEG que se volvió particularmente popular en Internet.

MTA

Un componente de software responsable de la distribución de e-mails entre diferentes sistemas de computación. Un MTA recibe mensajes de otros MTAs y de MUAs y los pasa a los correspondientes recipientes.

MUA

El Agente de Usuario de Correo (Mail User Agent) es el programa de e-mail que permite a los usuarios acceder, mostrar, leer, editar y adminitrar mensajes electrónicos.

.NET

Una plataforma para servicios web basados en XML de Microsoft™. La plataforma se diseño para conectar información, dispositivos y usuarios de forma uniforme y personalizada.

NTP

El Protocolo de Tiempo en Red (Network Time Protocol) se emplea para sincronizar la información horaria de diferentes ordenadores usando la red. NTP permite sincronizar los ordenadores al orden de milisegundos. Esto es un aspecto particularmente importante para procesos en los que están involucrados varios ordenadores a la vez.

ODBC

Conectividad a Bases de Datos Abierta (Open DataBase Access). Es un proceso de estandarización del acceso a bases de datos. Las aplicaciones, por ejemplo, pueden usar ODBC para acceder a un gran número de bases de datos de diferentes fabricantes.

OLE

Enlazado e incrustación de objetos (Object Linking and Embedding). Es un método para la compartición de información. Esta información puede estar representada en diferentes formatos y puede haber sido generada por diferentes aplicaciones. Los datos de un documento fuente se enlazan o incrustan en un documento destino. Cuando se marcan los contenidos en el documento destino, la aplicación origen se ejecuta, por lo que los datos pueden editarse utilizando las herramientas disponibles en el entorno original. Otro término empleado es "OLE Compound Documents" (Documentos Compuestos de OLE).

OSI

Interfaz de Sistemas Abiertos (Open Systems Interface). Un estándar internacional para el intercambio de datos en redes. El estándar OSI está compuesto por siete capas, que describen los procesos individuales de la comunicación.

PDF

Formato de Documento Portable (Portable Document Format). Un formato de documento legible en varias plataformas, desarrollado por Adobe Systems™, que permite la generación y presentación de documentos formados por texto, imágenes y dibujos.

Perl

Lenguaje Práctico de Extracción e Informe (Pratical Extraction and Report Language). El lenguaje Perl está disponible de manera libre y está ampliamente utilizado en la escritura de scripts CGI. Gracias a la cantidad de opciones, especialmente en el tratamiento y procesado de cadenas de texto, los programas Perl también se emplean en tareas rutinarias de administración.

PHP

Preprocesador de Hipertexto (Hypertext Preprocessor). Lenguaje de script del lado servidor para la generación de contenido dinámico y acceso a bases de datos.

POP3

Protocolo de Oficina de Correos (Post Office Protocol). Cuando se emplea la versión 3 de este protocolo de correo electrónico, el cliente de correo descarga todos los nuevos mensajes desde el servidor de correo a la máquina local. Los clientes suelen estar configurados para eliminar los mensajes del servidor una vez se han descargado correctamente.

POSIX

Una interfaz estandarizada estilo UNIX, de acuerdo a IEEE, que está soportada por todos los derivados de UNIX.

PostScript

un lenguaje de descripción de páginas desarrollado por Adobe™ para controlar las impresoras. Las impresoras que admiten PostScript reciben los comandos de impresión desde los programas en forma de una secuencia estandarizada de instrucciones, que la impresora interpreta y traduce a un proceso de impresión.RAS: Servicio de acceso remoto (Remote Access Service). Microsoft™ utiliza este nombre para proporcionar servicios basados en llamadas de teléfono dentro del sistema operativo de Microsoft™.

RDBMS

Sistema de Gestión de Bases de Datos Relacionales (Relational DataBases Management System). Los datos de una base de datos en un RDBMS se almacena en tablas, que están relacionadas unas con otras. Esta organización se basa en un modelo relacional.

Servidor

un proceso, un programa o un ordenador que procesa peticiones de clientes o que proporciona servicios que puede ser utilizados por un cliente.

SQL

Lenguaje de Interrogación Estructurado (Structured Querying Language). El lenguaje de interrogación estándar para las base de datos relacionales.

SSH

Un protocolo y la implementación (sistemas UNIX/Linux) correspondiente al protocolo, que permite el acceso seguro a ordenadores conectados a una red. La implementación permite la transmisión segura de datos a través de conexiones de red no seguras.

SSL

Capa de Sockets Seguros (Secure Sockets Layer). Una tecnología de cifrado desarrollada por Netscape™ y un protocolo para la comunicación segura y la transmisión de documentos entre navegadores web y servidores web.

TCP/IP

protocolo de control de la transmisión/Protocolo de Internet (Transmission Control Protocol/Internet Protocol). Un conjunto de protocolos de red que se emplean sobre una red física para ofertar a los usuarios distintos servicios. TCP e IP son las bases fundamentales para la definición de paquetes de datos, así como su envío y servicio.

UNO

Objetos de Red Universales (Universal Network Objects). UNO es un modelo de componentes que permite la interoperabilidad entre diferentes lenguajes de programación, entre diferentes modelos de objetos, entre diferentes arquitecturas de máquinas y entre diferentes procesos. Esto puede ser implementado sobre una LAN o sobre Internet. UNO está siendo desarrollado por la Comunidad OpenOffice™ en cooperación con los laboratorios de desarrollo de Sun Microsystems™. La bibliotecas básicas de UNO son independientes de OpenOffice™ y StarOffice™ y pueden ser utilizadas como marco de trabajo para otras aplicaciones. UNO está disponible libremente bajo los términos de la licencia LGPL. Actualmente se soportan los lenguajes Java, C y C++ en Windows™, Linux y Solaris™ (consultar también http://udk.openoffice.org/common/man/uno.html).

URL

Localizador de Recursos Universal (Universal Resources Locator). Identifica una dirección distinta en la web, como http://www.csar-ag.com.

VBA

Visual Basic para Aplicaciones (Visual Basic for Applications).

W3C

Este consorcio (Worl Wide Web Consortium) coordina el desarrollo de la web y la estandarización de HTML, XML y sus derivados.

WebDAV

Control de versiones y Autoría Distribuida basada en la web (Web-based Distributed Authoring and Versioning). Este protocolo es una extensión del Protocolo para la Transferencia de Hipertexto (HTTP - HyperText Transfer Protocol) y ofrece un soporte estandarizado para la una creación de contenidos asíncrona y en colaboración a través de Internet o Intranet.

WINS

Un sistema de Microsoft™ para la resolución de nombres dentro de una red (nombres de red <-> Direcciones IP).

XML

Una especificación en la definición de lenguajes para formatear documentos. XML ofrece una estricta separación de contenidos y diseño.

XSLT

Un lenguaje recomendado por la W3C para la creación de plantillas de estilo que convierta estructuras-XML a otras estructuras XML en un proceso basado en reglas, por ejemplo, desde un lenguaje de descripción de página, como es HTML.

Apéndice A. Apéndice WIBe (Recomendaciones de ejecucion de eficeincia economica para sistemas IT)

Resumen de recomendación de catalogos de analisis

Catalogo General de Criterios IT-WIBe21, para escenarios de migracion por el Dr Peter Rothing Organization, Projektberatun. Empfehlung zur Durchfuhrung von Wirtschaftlich keitsbetracthtungen in der Bundesverawaltung, in sbesondere beim Einsatz der IT, Version 3.0 - 2001 publicada por KBSt, Ministerio Federal del Interior, KBSt serie de publicacion , ISSN 0179-7263. volumen 52. Mayo 2001.

Catalogo especial de Criterios, IT-WIBe21, para la actualizacion y migracion de proyectos IT., por el Dr. Peter Rothig Organisations- und Projektberatung y el Profesor Dr. Detlef Leipelt, FH des Bundes fur offentliche Verwaltung - Hinweise und Empfehlungen - zur Durchfuhrung von Wirstschaftlich keitsbetrachtungen bei IT-Update- bzw, Umstellugsvorhaben auf Grundlage der IT-WIBe-97, published bu KBSt, Ministerio Federal del Interior, KBSt , serie de publicación. ISSN 0179-7263, Vol 52, Mayo 2001.

Catalogo de criterios especiales, IT-Wibe21, para objetos de migracion, compilado y seleccionado por encargo del catalogo general de criterios durante un workshop en el Ministerio Federal del Interior en cooperacion con los miembros de BSI, BVA y C_sar en Marzo 2003

Catalogo General de criterios, IT-WIBe21, para escenarios de migracion

  • Criterio acorde a WIBE 21 para escenarios de migracion completos (color azul oscuro)

  • Criterio que puede ser omitido para los objetos de migración (color naranaja) [19]

  • Criterio que puede ser adoptado para la migracion de proyectos en adicion a aquellos de WIBe 21 (color celeste)

Las estructuras estan orientadas hacia WIBe21:

  • desarrollo/Introduccion de costos y beneficios

  • Costos operativos y beneficios operativos.

Criterio de unrgencia

  • Criterio de calidad/strategia

  • Notas y explicaciones

Costes de desarrollo/introducción y beneficios de desarrollo

Tabla A.1. Costes y beneficios de la operación:

     
1xbn Costes de desarrollo/introducción y beneficios de desarrollo
1.1xbn Costes de desarrollo/introducción para el nuevo metodo IT
1.1.1xbn Costes de planificación y introducción/desarrollo
1.1.1.1x n Costes de personal (personal propio)
1.1.1.2xb  Costes de consultores externos
1.1.1.3xb  Costes del medio de desarrollo
1.1.1.4xb  Otros costes
1.1.1.5xb  Coste de viaje (personal propio)
1.1.2xbn Costes del sistema
1.1.2.1xb ostes de hardware
1.1.2.1.1xb  Operaciones de red host/servidor
1.1.2.1.2xb  Ordenadores para estaciones de trabajo
1.1.2.2xb  Costes de software
1.1.2.2.1xb  Costes para el desarrollo y/o adquisición de software
1.1.2.2.2xb  Costes para la adaptación de software y/o interfaces
1.1.2.2.3xb  Costes para la evaluación, certificación y garantía de calidad
1.1.2.3#bn Costes de instalación
1.1.2.3.1#b  Costes de costrucción/montaje
1.1.2.3.2#b  Instalación de infraestructura tecnica
1.1.2.3.3#b  Equipos y accesorios de oficinas
1.1.2.3.4#   Costes de personal para la instalación del sistema
1.1.3xbn e introducción del sistema
1.1.3.1x n Pruebas de sistema e integración
1.1.3.2xbn Costes de instalación del sistema
1.1.3.3xb  h Inportación de los datos almacenados
1.1.3.4x n Entrenamiento inicial de usuarios y especialistas IT
1.1.3.5x n Entrenamiento inicial de usuarios y especialistas IT
1.1.3.6xbn Otros costes de migración
1.1.3.6x   Desarrollo/intrucción de beneficios por el reemplazo del método anterior
1.2xb  Ahorro de costes extras (evitar costes de mantenimiento /actualizacion del sistema antiguo)
1.2.1xb  Ingresos extras (provenientes de la venta del sistema antiguo)

Costes y beneficios de la operación

Anotaciones relativas a los costes/beneficios de la operación: Todos los items incluyen información de los tipos de costes y beficios mostrados en 2.1.1 y 2.4.4, por ejemplo. Esta informacostrada aquí por motivos de falta de espacio.

Criterios de urgencia

Tabla A.2.

     
3x   Criterios de urgencia
3.1x   Urgenica en reemplazar el sistema anterior
3.1.1x   Continuidad del soporte para el sistema anterior
3.1.2x   Estabilidad del sistema anterior
3.1.2.1x   «Bugs», errores, y tiempo muerto
3.1.2.2x   Problemas con el servicio, «cuellos de botella» para el personal
3.1.3x   Flexibilidad del sistema anterior
3.1.3.1x   Límites de la expansión/mejoramiento
3.1.3.2x   Interoperabilidad, problemas con las interfaces en el presente/futuro
3.1.3.3x   Facilidad/comodidad en el uso (« user-friendliness »)
3.2x   Cumplimiento de reglas y leyes de la administración
3.2.1x   Cumplimiento de la ley
3.2.2x   Garantía de la protección/integridad de los datos
3.2.3x   Corrección de procesos de trabajo
3.2.4x   Cumplimiento de tareas y recomendaciones

Criterios de calidad/estrategia

Tabla A.3.

     
4x   criterios de calidad/estrategia
4.1x   Prioridad del proyecto IT
4.1.1x   Relevancia dentro del concepto general IT
4.1.2x   Integración dentro del paisaje IT de la administración federal en general
4.1.3x   Efectos de seguimiento para compañeros de comunicación
4.1.4x   Carácter de proyecto piloto
4.1.5x   Independencia del manufacutrador
4.2x   Incremento en la calidad del trabajo especializado
4.2.1x   Incremento en la performance del trabajo
4.2.2x   Aceleración de los procesos y procedimientos de trabajo
4.3x   Control de la información a nivel administrativo/político
4.3.1x   Provisión de información para quienes toman decisiones y ejercen tareas de control
4.3.2x   Apoyo a procesos de toma de decisiones y liderazgo
4.4x   Efectos relativos al staff
4.4.1x   Atractivo de las condiciones de trabajo
4.4.2x   Asegurar/intensificar la calificación
4.4.3    Diseminación/disponibilidad de entrenamiento
4.5x   Efectos relacionados con la orientación ciudadana
4.5.1   Acción administrativa uniforme y estandarizada
4.5.2   Incremento en la claridad y transparencia
4.5.3   Aceleración de decisiones administrativas con repercusión en partes externas
4.5.4x   Mejoramiento de la imagen
4.6    Diseminación/disponibilidad del software
4.6.1    Penetración en el mercado
4.6.2    Soporte independiente
4.6.3    Certificación de software dispinible
4.6.4    Herramientas disponibiles de administración de software
4.7    Seguridad IT
4.7.1    Seguridad de la comunicación
4.7.2    Seguridad de las aplicaciones
4.7.3    Seguridad contra fallas
4.7.4    Seguridad en la organización
4.7.5    Seguridad en las inversiones y planeamiento

Notas y explicaciones

Notas:

  1. En esta columna, los criterios mencionados en las ´´Hinweisen und Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen bei IT-Update- und Umstellungsvorhaben´´ auf Grundlage der IT-WiBe 97 (Recomendaciones sobre consideraciones de eficiencia económica para sistemas IT en conjunción con actualización IT y proyectos de migración) están marcados sobre la base de IT-WiBe 97 como sigue: X = el criterio debe ser incluido, # el criterio es omitido.

  2. El catálogo completo de criterios es aplicable a escenarios de migración (incluyendo, por ejemplo, aplicaciones especializadas).

  3. Los ítems en azul y en celeste son aplicables mayormente a objetos de migración.

  4. Los ítems en celeste fueron agregados al catálogo para proyectos de migración en adición al catálogo general de criterios de acuerdo a WiBe21.

  5. Los ítems en naranja pueden ser omitidos en proyectos de migración, especialmente en el caso de objetos de migración o grupos de objetos de migración.

Catálogo especial de criterios, IT-WiBe21, para objetos de migración

Tabla A.4.

ítemDescripción del criterio
1Costos de desarrollo / constos de introducción y beneficios de desarrollo / beneficios de introducción
1.1Costos de desarrollo/introducción para el nuevo método IT
1.1.1Costos de planeamiento e introducción/desarrollo
1.1.1.1Costos de personal (personal propio)
1.1.1.2Costos de asesores externos
1.1.1.3Costos de desarrollo del entorno
1.1.2Costos de sistema
1.1.2.1Costos de hardware
1.1.2.1.1Operación de servidor y network
1.1.2.1.2Estaciones de trabajo
1.1.2.2Costos de software
1.1.2.2.1Costos de desarrollo y adquisición de software
1.1.2.2.2Costos de modificación de software y/o de interfaces
1.1.2.2.3Costos de evaluacioón, certificación y control de calidad
1.1.2.3Costos de instalación
1.1.2.3.4Costos de personal para instalación del sistema
1.1.3.2Costos de introducción del sistema
1.1.3.3Traslado de datos existentes
1.1.3.4Entrenamiento inicial para usuarios y especialistas IT
1.1..3.5Costos de familiarización para usuarios y especialistas IT.
2Costos y beneficios de operación
2.1Costos de operación / ahorro en costos de operación
2.1.2Costos prorrateados de servidor, hosts y network
2.1.2.1Costos de operación del proceso NEW IT
2.1.2.2Beneficios de operación por omisión de anteriores procesos IT
2.1.3Costos prorrateados por estación de trabajo
2.1.3.1Costos de operación de los procesos
2.2Costos de personal operativo / ahorros en costos de personal
2.2.2Organización y administración del sistema
2.2.2.1Costos operativos del proceso NEW IT
2.2.2.2Beneficios operativos por la omisión del proceso antiguo
2.2.3Entrenamiento y capacitación gradual
2.2.3.1Costos operativos del proceso NEW IT
2.2.3.2Beneficios operativos de la omisión del proceso antiguo
2.3Costos operativos / ahorros por mantenimiento / service del sistema
2.3.1Mantenimiento/ service del hardware
2.3.1.1Costos operativos del sistema NEW IT
2.3.1.2Beneficios operativos de la emisión del proceso antiguo
2.3.2Mantenimiento / actualización de software
2.3.2.1Costos operativos del proceso NEW IT
2.3.2.2Beneficios opertivos de la omisión de procesos antiguos
2.3.3Costos de reemplazos y suplementos
3.3.1Costos operativos de los procesos NEW IT
2.3.3.2Beneficios operativos de la omisión de procesos antiguos
2.4Otros costos y beneficios operativos
2.4.2Costos de asesores externos trabajando paralelamente
2.4.2.1Costos operativos de procesos NEW IT
2.4.2.2Beneficios operativos de la omisión de los procesos antiguos
2.4.4Otros costos y beneficios operativos
2.4.4.1Costos operativos de procesos NEW IT
2.4.4.2Beneficios operativos de la omisión de los procesos antiguos
3Criterios de urgencia
3.1Urgencia por reemplazar el viejo sistema
3.1.1Continuidad en el soporte para el sistema anterior
3.1.2Estabilidad del viejo sistema
3.1.2.1´Bugs´, errores y tiempo muerto
3.1.2.2Problemas de service, cuellos de botella del personal
3.1.3Flexibilidad del viejo sistema
3.1.3.1Límites a la expansión/ mejoramiento
3.1.3.2Interoperabilidad, problemas de interfaces presentes o futuros
3.2.3.3Facilidad de uso
3.2Cumplimiento de regulaciones y leyes administrativas
3.2.1Cumplimiento de las leyes
3.2.2Adecuación a la necesidad de protección y seguridad de datos
3.2.3Corregir procedimientos y procesos de trabajo
3.2.4Cumplimiento de requerimientos y recomendaciones
4Criterios de calidad/estrategia
4.1Prioridad del proyecto IT
4.1.1Relevancia dentro del concepto general IT
4.1.2Integración dentro del paisaje IT de la administración federal en general
4.1.3Efectos de seguimiento para compañeros de comunicación
4.1.4Carácter de proyecto piloto
4.1.5Independencia del manufacutrador
4.2Incremento en la calidad del trabajo especializado
4.2.1Incremento en la performance del trabajo
4.2.2Aceleración de los procesos y procedimientos de trabajo
4.3Control de la información a nivel administrativo/político
4.3.1Provisión de información para quienes toman decisiones y ejercen tareas de control
4.3.2Apoyo a procesos de toma de decisiones y liderazgo
4.4Efectos relativos al staff
4.4.1Atractivo de las condiciones de trabajo
4.4.2Asegurar/intensificar la calificación
4.4.3Diseminación/disponibilidad de entrenamiento
4.5Efectos relacionados con la orientación ciudadana
4.5.1Acción administrativa uniforme y estandarizada
4.5.2Incremento en la claridad y transparencia
4.5.3Aceleración de decisiones administrativas con repercusión en partes externas
4.5.4Mejoramiento de la imagen
4.6Diseminación/disponibilidad del software
 Penetración en el mercado
4.6.2Soporte independiente
4.6.3Certificación de software dispinible
4.6.4Herramientas disponibiles de administración de software
4.7Seguridad IT
4.7.1Seguridad de la comunicación
4.7.2Seguridad de las aplicaciones
4.7.3Seguridad contra fallas
4.7.4Seguridad en la organización
4.7.5Seguridad en las inversiones y planeamiento

Explicación de los criterios adicionales

Los criterios que han sido agregados para la evaluación de la eficiencia económica de los proyectos de migración en adición a los criterios originales contenidos en el contexto de WiBe 21 versión 3.0 así como los suplementos en forma de anotaciones y recomendaciones del 2000 .....anotaciones y recomendaciones del 2000 (mirar lo anterior) [20] . La sistemática es orientada para que el WiBe 21 se aproxime y este referido entre pareguiendo la descripción.

Nota

Véase WiBe 21 capítulo 1 costes de desarrollo/beneficios

Introdución costes/beneficios (1.1)

La migración de una vista completa también incluye las aplicaciones especializadas que será necesaria para nuevos desarrollos o reprogamaciones. Estas actividades deben considerarse como "costes de desarrollo". La migración de objetos típica requiere costes de introdución, pero no de desarrollo. En orden de subrayar estas circunstancias, los criterios de "costes de desarrollo" están corregidos por el periodo de "Introdución2 [21] ".

Nota

Véase WiBe 21 cápitulo 4 calidad/criterios de estrategia

Difusión / disponibilidad de entrenamiento (4.4.3)

Este criterio dirige la difusión del entrenamiento y la disponibilidad del equipo necesario. La importancia de este criterio debe ser evaluada en términos cualitativos.

Table A.5. 

0246810
Personnel having the required skills is available on the market. Training is offered on an area-wide basis.Personnel is available. Training is, however, of-fered at a few centers only.Person Training is organized mostly on an internal basis.Personnel is available to a limited extent. Training must be organized internally.Personnel is hardly avail-able. Training is possible to a limited ex-tent only.The required training is not available on the market and is not offered either.

Difusión/disponibilidad de software (4.6)

Penetración en el mercado (4.6.1)

Este aspecto se refiere al mercado compartido del software usado. La penetración en un mercado en merma u obsoleto tiene el riesgo de que el software y/o su nuevo desarrollo sea discontinuo. Además, una buena penetración en el mercado. Con lleva un alto grado de aceptación [22] y/o el uso intensivo del software que promete la continuidad en la existencia del software.

Table A.6. Penetración en el mercado

0246810
The product is offered on an area-wide basis.The product is available from selected dis-tributors only.The product is offered on a regional basis only.The product is offered on an occasional basis only.The product is offered on a case-to-case basis only.The product is not offered (any longer).

Soporte independiente

Este criterio dirige la disponibilidad de soporte por compañias independientes para el software usado. Contra el fondo de las inversiones de protección, esto garantiza la continuidad del uso regular del software si esta epresa a largo plazo no es capaz de asegurar esto.

Table A.7. Soporte independiente

0246810
Support is offered on an area-wide basis.Support is available from selected dis-tributors only.Support is offered on a regional basis only.Support is offered only seldom.Support is offered on a case-to-case basis only.Support is not offered (any longer).

Disponibilidad de certificados de software(4.6.3)

Este criterio dirige la cuestion de como el software es usado de acuerdo con estatutos y/o requerimientos especificos de l agencia o la industria o como tales consentimientos deben ser organizados por la propia organización del usuario. En este caso, el fabricante/proveedor del software asegura esta certificación, que no debe incurrir en costes adicionales. En el último caso, la organización del usuario debe asegurar la certificación de acuerdo a cubrir sus procesos de negocio. En este caso, la propia organización del usuario incurrira en costes que no pueden ser calculados en una base general.

Table A.8. Disponibilidad de certificación de software

0246810
The software is certified, and certifica-tion is re-newed on a regular basis.The software is certified, and certifica-tion is re-newed on an occasional basis.The software comes with once-off certi-fication.The software comes with partial certifi-cation.The software comes with rudimentary certification and/or rec-ommendations only.The software is not certified. Certification is not possible either.

Disponibilidad de herramientas de administración para el softwar)

La administración de los productos software a utilizar a veces no es muy amigable o incluso puede ser complicada. Este criterio es aplicable a herramientas que realizan o soportan la administración de tablas y datos maestros. Adecuadamente, herramientas inteligentes pueden incrementar la eficiencia y calidad de la administración así como optimizar el uso de los recursos.

Seguridad en TI (4.7)

Los aspectos de "seguridad" se incluyen en parte dentro de los criterios a insistir (refiérase a "tiempo de inactividad" o "protección de datos y seguridad de los datos"). En este punto, este tema se retoma de nuevo bajo los aspectos de estrategia y calidad y se discute el acercamiento a su manejo.

Seguridad en las comunicaciones (4.7.1)

Este criterio engloba la seguridad de las comunicaciones internas y sobre todo externas. ¿Como se asegura la transmisión de datos? ¿Se emplean protocolos de seguridad?. ¿Existen protección de las transmisiones, mecanismos de control de acceso, etc?

Aplicaciones de salvaguarda/seguridad (4.7.2)

¿Puede el software ser testeado en relación a la seguridad de TI? ¿Cuán susceptible puede ser el software a ataques externos, virus, etc.? ¿Dispone el software de un diseño modular (separación entre programas del sistema y aplicaciones, opciones para restringir los programas de aplicación a sus funciones necesarias)?. ¿Esisten mecanismos de control de acceso?

##OJO## lvaguarda (4.7.3)

¿Cuán seriamente se ve afectada la salvaguarda por los fallos del sistema? ¿Existen rutinas de recuperación?

Administración de la seguridad

¿Existe administración de la seguridad? ¿Existe un concepto de seguridad conocido por todos aquellos implicados en ella? ¿Existe un proceso descriptivo para comprobaciones de seguridad y su documentación asociada?

Investigación y planificación de la salvaguarda (4.7.5)

Este criterio cubre los efectos agregados de todos los criterios relevantes a la seguridad listados hasta ahora, y plantea la pregunta de si investigación y planes basados en esto continuarán existiendo en el futuro.



[19] se refiere al catalogo especial de criterios para los objetos de migración.

[20] Se refiere a "Spezieller Kriterienkatalog IT-WiBe21 fr Migrationsobjekte", preparado por el proyecto de cooperación del Ministerio federal del interior, BSI, BVA and C_sar.

[21] Se refiere a los criterios de los items 1., 1.1, y 1.1.1.

[22] La aceptación no es siempre la prioridad más importante. El tribunal de comercio ocasionalmente adopta decisiones a favor de sistemas mejores o más económicos