Skip to main content

Introducción a la compatibilidad de aplicaciones en una implementación de Windows

Este artículo explica cómo comenzar el proceso de evaluar el impacto de la compatibilidad de aplicaciones en su proyecto de implementación. Aprenderá a realizar un inventario, clasificar las aplicaciones por orden de prioridad e identificar las aplicaciones que se incluirán en una imagen de implementación basada en roles.

En este artículo:


Introducción a la compatibilidad de aplicaciones en una implementación de Windows

Si ya ha trabajado en un proyecto de implementación de sistema operativo, tal vez recuerde la compatibilidad de aplicaciones como la fuente de la mayoría de los desafíos que tuvo que enfrentar. Puede necesitar el mayor esfuerzo, la mayor cantidad de tiempo y generar algunos de los problemas de bloque más serios. Si trabaja por primera vez en la implementación de un sistema operativo, es posible que haya escuchado historias terribles sobre la compatibilidad de aplicaciones, o tal vez nada en absoluto y el alcance del trabajo podría sorprenderle. Sea cual sea su situación y con una planeación adecuada, el proyecto se puede volver mucho más predecible y controlable.

Es importante tener en cuenta que la compatibilidad de aplicaciones es, principalmente, una actividad de administración de riesgos. Mientras más alto sea el porcentaje de aplicaciones que podrían presentar errores (según la estadística), más deberá trabajar en pruebas proactivas que le ayuden a asegurarse de que una aplicación importante no sea parte de ese porcentaje. A medida que este porcentaje disminuya, también disminuye el número de aplicaciones para las que vale la pena realizar pruebas exhaustivas. Eso significa que si está migrando desde Windows XP con usuarios que son principalmente administradores locales, no le debería extrañar que un porcentaje razonable de aplicaciones presenten un error. Debe planear según corresponda, para invertir más en administrar ese riesgo. Si ya realizó la migración a Windows 7, puede esperar que muy pocas aplicaciones presenten errores para así planear en invertir menos ya que el riesgo es menor. (Desde luego que siempre puede confiar, pero comprobar).

Sin embargo, administrar ese riesgo de aplicación parte por entender exactamente qué implica ese riesgo, lo que significa entender las aplicaciones que tiene. Todo comienza con la creación o actualización de su cartera de aplicaciones administradas. Si no cuenta con una, no se preocupe que no es el único, pero ahora es la oportunidad perfecta para crearla. En condiciones ideales, seguirá manteniendo esta lista después de que el proyecto de implementación esté completo, para mejorar la agilidad. Esta lista representa las cosas de las que se hará cargo, para ayudarle a asegurar la funcionalidad de su entorno a medida que este cambie. Emite pólizas de seguro para esas aplicaciones, así que el mejor enfoque es entender cuánto riesgo está asegurando.

Este documento le ayuda a entender los pasos que debe seguir para prepararse para la prueba y evaluación de la compatibilidad de aplicaciones durante un proyecto de implementación de Windows 8. Sin embargo, en la mayoría de los casos, los principios que se describen aquí son universales y se aplican a migraciones de cualquier plataforma. Cuando termine de leer esto tendrá una idea clara de dónde comenzar a evaluar el impacto de la compatibilidad de aplicaciones en su proyecto de implementación, así como de algunas habilidades y técnicas que necesitará para comenzar y ser más eficiente.

Volver al inicio


Descripción del desafío de compatibilidad de aplicaciones

En el núcleo del desafío de la compatibilidad de aplicaciones se encuentra la ley de los grandes números. Las organizaciones pueden tener decenas de miles o incluso cientos de miles de escritorios. Cada extremo puede tener docenas de aplicaciones instaladas y probablemente ni siquiera esté al tanto de lo que está instalado (en especial si los usuarios son administradores locales). Así que para cuando considere cada uno de estos escritorios, probablemente habrá cientos, miles o decenas de miles de aplicaciones únicas instaladas en todos los escritorios. ¡Y son solo aplicaciones de Windows! Cuando considera las aplicaciones web, tiene que hacerse cargo de cada sitio web único en el mundo, porque es posible que algunas aplicaciones web de varias ubicaciones, tanto dentro como fuera de la organización, se hayan convertido en un flujo de trabajo productivo dentro de la misma empresa. Los números realmente comienzan a estallar y si no tiene cuidado, puede acabar completamente paralizado de miedo frente a la gran cantidad de partes móviles involucradas.

Es por esta razón que debe ser pragmático. Y la razón de que lo que ofrece es una póliza de seguro. A medida que cambia el entorno y el mundo, usted garantiza que algunos de los software se seguirán ejecutando. Pero no es muy justo para usted ampliar lo que garantiza para incluir cualquier aplicación que un usuario logre instalar o cualquier sitio web que un usuario logre encontrar y navegar, independiente de su calidad o durabilidad. En vez de eso, tiene que definir algunas categorías. ¿Qué software va a asegurar inmediatamente, sin tener en cuenta los cambios? Le resulta más costoso garantizar este software, ya que tendrá que ejecutar un proceso de comprobación estructurado, lo que es necesario para las aplicaciones más importantes.

A continuación, ¿qué software va a asegurar que funciona? y si presenta errores, ¿se hará usted responsable y lo solucionará? Existe un costo cuando las cosas presentan errores, pero usted paga solo por las aplicaciones que presentan errores, en vez de pagar por todo (aun cuando es posible que la mayoría funcione). Luego están las aplicaciones que no garantiza; los usuarios tienen completa libertad para usarlas y si presentan errores, se tienen que encargar de eso ellos mismos. Finalmente, está la categoría de aplicaciones que preferiría que no usaran los usuarios y, de hecho, puede seguir algunos pasos para evitar que lo hagan.

perfil de los pasos

En cuanto comienza a aplicar este marco de trabajo, su manera de pensar también comienza a cambiar. Es posible que esté dispuesto a garantizar una versión de una aplicación, pero ¿está dispuesto a garantizar cada versión que alguien ejecute, con el contrato de nivel de servicio más alto? En la mayoría de los casos, la respuesta es no. Y esto es lo que quiere ejecutar: un proceso que determine en qué aplicaciones debe invertir más, que realice esa inversión para administrar el riesgo y que después migre a una plataforma más nueva.

El riesgo que espera administrar es la interrupción empresarial como resultado de un error de aplicación. Varias de las aplicaciones que ejecuta serán compatibles con Windows 8 (especialmente si ya está ejecutando Windows 7). Algunas podrían tener problemas y pueden presentar distintos niveles de gravedad, desde una aplicación que "no se ve bien" hasta una opción de menú que no funciona para nada o al bloqueo de una aplicación.

Así que, ¿por dónde comenzar? Nuestros clientes más exitosos usan el siguiente enfoque:

  1. Descubra las aplicaciones por las que elige preocuparse: comience con las aplicaciones que ya administra de manera central y luego agregue cualquier aplicación adicional que aún no administre centralmente.
  2. Racionalice las aplicaciones para asegurarse de que la cartera de aplicaciones administrada no haya crecido tanto como para volverse incontrolable, además de clasificar y establecer prioridades para impulsar el proyecto de compatibilidad de aplicaciones.
  3. Pruebe las aplicaciones para validar que la funcionalidad empresarial que necesita funcione correctamente en la nueva plataforma.
  4. Corrija cualquier problema que descubra, los que podrían incluir usar las características de compatibilidad integradas de la plataforma, cambiar una directiva para permitir un comportamiento defectuoso, actualizar o reemplazar una aplicación e incluso retirar una aplicación en algunas ocasiones.

Este artículo se enfoca en los dos primeros pasos: descubrimiento y racionalización. Al final de este proceso podrá generar su presupuesto y planear continuar con el proyecto, así que es muy importante ejecutar bien estos pasos.

Volver al inicio


Detección de aplicaciones

"Detección de aplicaciones" es lo que se conocía anteriormente como "inventario de aplicaciones": el cambio a "detección de aplicaciones" fue intencional. Descubrimos que la palabra "inventario" hacía creer a los clientes que debían encontrar todo lo que se ejecutaba en el entorno e incorporar esa lista al proceso de racionalización. Y ¿sabe lo que ocurre? De alguna manera podría lograr eso para las aplicaciones de Windows instaladas. (El mayor inventario de aplicaciones de Windows instaladas del que tengamos registro es de 130.000 aplicaciones. Es demasiado grande, pero no tanto como para impedir la racionalización). Sin embargo, la migración de plataforma a una nueva versión de Windows incluye, por lo general, una nueva versión de Internet Explorer. ¿De qué tamaño es la lista de URL únicas por las que todos navegan a lo largo de una organización? ¡Enorme! Varios clientes aprovechan de actualizar la versión de Microsoft Office que usan durante la migración (Chris Jackson analiza las matemáticas de hacer un inventario y racionalización completo de documentos de Office en este artículo de TechNet " Microsoft Office: las matemáticas de la compatibilidad de Office". Como puede ver, no siempre tiene sentido encontrar todo. Al mismo tiempo, definitivamente le gustaría detectar aquellos elementos que representan un verdadero riesgo empresarial durante la migración.

El proceso de detección depende de varios factores, incluido el

entorno administrado o no administrado: los entornos administrados son mucho más fáciles para realizar la detección, ya que por lo general usted controla qué aplicaciones están instaladas en los equipos administrados y, por lo tanto, sabe cuáles son. Comienza con una lista de aplicaciones compatibles y aprobadas, así como con los detalles sobre la cantidad de equipos en los que están instaladas (e incluso cuánto se usan). Un entorno sin administrar es más desafiante, ya que por lo general comienza el proyecto sin preocuparse por las aplicaciones que se usan, especialmente aquellas que instalaron (y a veces crearon) los mismos usuarios. La mayoría de las organizaciones se ubican en un punto intermedio: tienen algunas aplicaciones administradas y admitidas centralmente, además de diferentes aplicaciones que se tratan como excepciones (y varias de las cuales no están al tanto).

TI centralizada o autónoma: las organizaciones con una infraestructura de TI centralizada tienen una ventaja en la detección de aplicaciones, debido a que ya están al tanto y en contacto con todos los departamentos dentro de la organización. Las infraestructuras de TI descentralizadas ofrecen una agilidad más local, pero ejecutar la tarea de detección requiere más coordinación a medida que consolida la información y la estrategia a través de límites organizacionales, de centro de costos y geográficos.

Herramientas de inventario para activos administrados disponibles: las organizaciones que cuentan con un entorno administrado a menudo tienen una herramienta de administración de activos de software, como Asset Inventory Service de Microsoft (una herramienta disponible a través del Paquete de optimización de escritorio Microsoft para Software Assurance) o System Center Configuration Manager de Microsoft. Esta herramienta podría contener la lista de software que se administra activamente. Algunos clientes eligen mantener una lista aparte de software administrado y admitido, como Microsoft SharePoint o Microsoft Excel. A menudo, los que no están al tanto del software que se está ejecutando o quienes temen que su inventario de software administrado pueda estar incompleto, buscan herramientas adicionales para crear o complementar esa lista. Una forma directa de realizar el inventario es simplemente preguntar a las unidades de negocios, pero en algunas organizaciones, realizar diversos preparativos antes de preguntar puede aumentar en gran medida el cumplimento de las unidades de negocios. El Kit de herramientas de compatibilidad de aplicaciones de Microsoft proporciona una herramienta de recopilación de inventario para las aplicaciones de Windows instaladas (así como los complementos web) por esta misma razón.

Alcance: el número de equipos en una organización es sin duda un factor en el momento de realizar la detección de aplicaciones, pero no es el único factor. El número de roles únicos también determina la variabilidad del software que se usa y puede aumentar la cantidad de trabajo necesaria para ayudar a garantizar que todas las funcionalidades empresariales continúen funcionando después de la migración. Con usuarios altamente autónomos que son capaces de instalar su propio software, incluso puede haber variaciones importantes dentro de un rol; determinar las versiones que son esenciales para la organización, en comparación con las variaciones que apenas agregan complejidad innecesaria, puede ser un desafío.

Realización de una detección manual

En un mundo ideal, las unidades de negocios deberían acudir a usted. Después de todo, ellos son los que le piden garantizar estas aplicaciones contra errores en un entorno tecnológico que avanza con rapidez. Entonces, ¿no tiene sentido que al menos le digan lo que quieren que usted les garantice? Es posible que eso no suceda (aún), de manera que tendrá cierto trabajo por hacer.

Para organizaciones muy pequeñas, puede ser más conveniente hablar con los usuarios individualmente y tal vez pasar algún tiempo mirando sus menús de Inicio para ver lo que tienen instalados y hablar sobre las aplicaciones que son importantes y las que "solo están ahí".

Sin embargo, para la mayoría de las organizaciones no es nada práctico visitar a cada usuario. Un enfoque popular en esta situación es elegir un representante de cada departamento o rol para llevar a cabo el trabajo de informar sobre el software que se necesita para realizar ese trabajo. Este rol tiene varios nombres; por ejemplo, Coordinador técnico de departamentos, pero debe ser alguien que no solo entienda el negocio, sino también qué software lo impulsa. Puede trabajar con esta persona (o personas) para crear la lista de aplicaciones requeridas para llevar a cabo ese aspecto del negocio.

Después de hacer cualquier trabajo para completar esta lista, también debería considerar crear procesos formales para agregar, revisar y eliminar aplicaciones de esta lista maestra y crear estos procesos de manera que presenten la menor cantidad de errores posibles para motivar la participación empresarial en sus esfuerzos de administración de activos de software.

Automatización del proceso de detección

Ya que la detección de la aplicación incluye comparar el software con los valores de negocios, se trata de un proceso que, en términos generales, no se puede automatizar completamente. Sin embargo, es posible que los usuarios empresariales y los coordinadores de departamentos en muchos entornos no estén al tanto de todo lo que impulsa al negocio. Si está dando el primer paso hacia las prácticas de administración de activos de software en su organización, entonces controlar el riesgo de perder algo es un signo de una sociedad saludable entre el negocio y la tecnología.

Si tiene un entorno administrado, puede obtener una lista actualizada de las aplicaciones instaladas para la organización y para cada departamento. Esta lista puede servir como un excelente punto de partida para estas conversaciones.

Sin embargo, si su cartera de aplicaciones no está administrada de manera central, es posible que esté buscando herramientas que le ayuden a crear esta lista y facilitar esa conversación. Muchos clientes eligen usar el Kit de herramientas de compatibilidad de aplicaciones, que proporciona esta funcionalidad como una descarga gratuita de Microsoft. La herramienta de Administración de compatibilidad de aplicaciones (entre otras herramientas que son útiles para la solución de problemas y corrección de aplicaciones) puede recopilar el inventario de aplicaciones, ya sea de un subconjunto o de toda su organización.

Volver al inicio


Racionalización de aplicaciones

A medida que colabora con el negocio para determinar las aplicaciones que deberían clasificarse como aplicaciones administradas o compatibles (las aplicaciones administradas se someten específicamente a una prueba de regresión antes del cambio; las aplicaciones compatibles no se someten a esta prueba, pero ellas sí cuentan con soporte técnico en el caso de que presenten errores en el nuevo entorno), tendrá que tomar algunas decisiones difíciles para determinar las aplicaciones que pertenecen a cada lista.

La primera revisión de sus aplicaciones detectadas es bastante sencilla:

Versión de las aplicaciones: su organización tiene varias versiones de una aplicación, que incluyen versiones obsoletas y no compatibles. Si bien algunas organizaciones admitirán más de una versión bajo algunas circunstancias, administran activamente solo una, generalmente la versión más reciente o la más actual. Al seleccionar una versión estándar, también podrá ser capaz de reducir sus costos de soporte técnico.

Redundancia de aplicaciones: su organización tiene más de una aplicación que realiza la misma tarea: la mayoría de las organizaciones puede elegir admitir más de una bajo ciertas circunstancias, pero administran activamente solo una. Al seleccionar una aplicación estándar única, podrá ser capaz de reducir el costo por licencia con descuentos por volúmenes mayores, pero también podrá reducir sus costos de soporte tan solo con mantener un contrato de soporte.

Necesidad de aplicaciones: su organización tiene aplicaciones que son irrelevantes para el trabajo diario que se realiza en la organización. A menudo, esto es el resultado de cambios anteriores a la estrategia organizacional, tras los cuales estas aplicaciones nunca se retiraron. La mayoría de las organizaciones simplemente retiran estas aplicaciones y solo ocasionalmente eligen admitirlas (pero no administrarlas activamente) bajo circunstancias excepcionales

No es una aplicación: si está comenzando el proceso de racionalización desde una lista generada automáticamente, es posible que descubra que muchas de las "aplicaciones" detectadas no son aplicaciones; al menos no son aplicaciones por las que haya que preocuparse. Muchos paquetes de controladores de software dejan pruebas de la instalación en lugares donde la mayoría de las herramientas de inventario buscan, como la lista Agregar o quitar programas. Es preferible que elimine estas entradas de la lista antes de comenzar las conversaciones. Es posible que detecte aplicaciones de las que nunca tendrá que preocuparse y que no necesita mencionar en las conversaciones que sostiene con los compañeros de trabajo junto a los que lleva a cabo la racionalización. Estas pueden incluir juegos o aplicaciones de apuestas en línea que muchos clientes detectan que sus usuarios han instalado.

Con la reducción de esta lista tras eliminar a los candidatos obvios, está listo para comenzar a sostener conversaciones productivas con la empresa. Durante estas conversaciones, es preferible validar que la lista está completa y asegurar que está aplicando una cantidad suficiente de administración de riesgos a esas aplicaciones al comprender la importancia de cada aplicación. A pesar de que la terminología individual puede variar, aquí le presentamos algunos niveles de prioridad usados comúnmente que se deben tener en consideración.

Importante para la empresa: una aplicación que detiene un departamento, rol o incluso la organización completa si presenta errores. Esta es un gran obstáculo que se debe superar y solo algunas aplicaciones para cada cliente clasifican en esta categoría. Las aplicaciones críticas para la empresa tienen con frecuencia contratos de nivel de servicio (SLA) que indican que el personal de soporte técnico debe responder a un error dentro de 15 minutos o menos. Las aplicaciones críticas para la empresa siempre se clasifican en la categoría "administradas" y necesitan pasar pruebas estructuradas antes de la migración.

Alta prioridad: una aplicación que desempeña un rol fundamental en un departamento o en toda la organización. Un error en una aplicación de alta prioridad podría dejar sin actividad a un departamento o a una sola función empresarial en la organización. Si se produce un error en una aplicación de alta prioridad, la organización puede seguir operando, pero uno o más departamentos podrían verse seriamente afectados. Un SLA típico para una aplicación de alta prioridad se mide en horas. Las aplicaciones de alta prioridad casi siempre se clasifican en la categoría "administradas" y necesitan pasar pruebas estructuradas antes de la migración.

Importante: una aplicación importante que se usa frecuentemente, pero que no causará una interrupción de trabajo si se produce un error en esta. Por lo general, los SLA para aplicaciones importantes se miden en días. Generalmente, las aplicaciones importantes se clasifican en la categoría "compatibles" y dependen más de pruebas orgánicas y pilotos que de pruebas formales, excepto en casos especiales.

Opcional: una aplicación aprobada pero que tiene un uso limitado y no está directamente relacionada con una función empresarial central. Las aplicaciones en esta categoría generalmente no están cubiertas por un SLA y el soporte técnico se consideraría el “mejor esfuerzo”. Las aplicaciones opcionales se clasifican, como mucho, en la categoría "compatibles" y dependen más de pruebas orgánicas y pilotos que de pruebas formales para identificar los errores.

Asignar niveles de prioridad a las aplicaciones es, a menudo, un proceso subjetivo que como tal puede estar sujeto a una revisión periódica. Aconsejamos prácticas de administración de activos de software formales, que mantienen un equipo o comité para supervisar la cartera de aplicaciones, incluso entre implementaciones del sistema operativo.

Mejorar las competencias de administración de activos de software también le puede proporcionar otros beneficios. Por ejemplo, varios clientes creen que ellos mismos son la mejor opción para mejorar los costos de licencias y para reducir los riesgos de sanción por ejecutar un software sin licencia. También creen que pueden optimizar sus inversiones existentes y lograr hacer más con lo que ya tienen.

Identificación de aplicaciones críticas para la empresa

Algunas aplicaciones críticas para la empresa son fáciles de identificar, pero otras no. Si la organización opera a través de una presencia en Internet, las aplicaciones de procesamiento de texto, de manipulación de imágenes y de codificación de páginas se podrían considerar aplicaciones críticas para la empresa. Además, la categorización crítica para la empresa variará según el rol. Para un centro de llamadas, una aplicación que supervisa la estabilidad del servidor se podría considerar crítica, mientras que otros departamentos no le darían importancia.

Si su organización cuenta con un plan de recuperación ante desastres (DRP) o un plan de funcionamiento sin interrupciones de la empresa (BCP), las aplicaciones críticas para la empresa ya se deberían haber identificado en dichos planes.

Algunos criterios para identificar las aplicaciones críticas para la empresa incluyen:

  • La aplicación representa una función principal de la organización (como un software de procesamiento de texto o de diseño para una editorial).
  • La organización sufrirá un impacto financiero significativo si se producen errores en la aplicación.
  • Si se producen errores en la aplicación fuera del horario de trabajo, el buscapersonas de una persona empezará a sonar en pocos minutos.

Identificación de aplicaciones de alta prioridad

Es posible que sea fácil identificar las aplicaciones de alta prioridad en su propio departamento, pero es difícil identificarlas en otros. Algunas veces, puede identificar una aplicación de alta prioridad según el porcentaje de equipos en los que esté instalada, aunque esto puede ser algo engañoso. Por ejemplo, una aplicación que se desarrolló internamente para supervisar la cantidad de tóner en las impresoras láser de la empresa podría estar implementada en todos los equipos, pero es posible que muy pocas personas la usen (o la consideren importante) realmente. Si su organización tiene un DRP o un BCP, es posible que las aplicaciones de alta prioridad ya estén identificadas en esos planes.

Algunos criterios para identificar aplicaciones de alta prioridad incluyen:

  • La aplicación se usa en la mayor parte del turno de trabajo.
  • Un gran porcentaje de los usuarios de la organización usan la aplicación.
  • Sin la aplicación, sería difícil que la organización o el departamento operara normalmente.
  • Sin la aplicación, las operaciones diarias se verían afectadas y podría ocurrir un impacto financiero apreciable.

Volver al inicio


Asignación de aplicaciones a roles

El concepto de roles de usuario puede llegar a ser fundamental en el momento de determinar un plan de implementación óptimo para el sistema operativo. Los usuarios dentro de determinado rol tienden a usar mucho el mismo software, y ser capaz de comenzar la implementación luego de completar el trabajo de compatibilidad de aplicaciones es ideal para esa función, en vez de tener que esperar a completar el trabajo en todos los software de su organización, no solo levanta la moral del equipo (cuyos miembros cuentan ahora con una métrica de éxito de la que estar orgullosos), sino también impulsa un entrenamiento importante en las funciones posteriores, que de otra manera no se verían beneficiadas con la implementación.

Los equipos y funciones que se definen comúnmente incluyen:

  • Recursos humanos
  • Trabajador de la información
  • Servicio de asistencia de TI
  • Marketing
  • Desarrollador
  • Ejecutivo

Por supuesto, existen aplicaciones que son estándar en todas las funciones. Algunos ejemplos podrían incluir aplicaciones de correo electrónico y de antivirus.

Las funciones de implementación también se pueden clasificar por orden de prioridad para disminuir el esfuerzo necesario para probar la compatibilidad de aplicaciones. A las configuraciones basadas en rol para las operaciones críticas se les debe efectuar el máximo posible de pruebas y a las funciones de menor prioridad se les pueden efectuar menos pruebas, lo que impulsa el concepto de invertir de manera inteligente en la administración de riesgo, basado en el riesgo real en vez de en una tendencia hacia la perfección costosa y que no se pueda lograr.

Volver al inicio


Pasos siguientes

El proceso que se describe en este documento debe producir un catálogo de aplicaciones para la organización, que se clasifique por orden de prioridad en términos de las pruebas necesarias, de los roles de usuario específicos y de qué aplicaciones se implementarán con Windows 8. Este catálogo le brinda la información sin procesar necesaria para avanzar a los pasos siguientes del proceso. Al usar la información del catálogo de aplicaciones, los pasos siguientes deben incluir:

  • Formación del equipo: después de que comprenda el ámbito de trabajo de la organización, será necesario que forme un equipo para que trabaje en las decisiones técnicas y comerciales que se necesitan tomar. El tamaño y ámbito de este equipo depende del tamaño y del ámbito de la implementación. Es posible que usted sea el jefe de proyecto, el jefe de pruebas y el recurso que depende de expertos generales. Las organizaciones más grandes necesitarán un equipo más formal con roles bien definidos. Se puede encontrar orientación para formar un equipo en Microsoft Deployment Toolkit.
  • Creación del plan de pruebas: las aplicaciones administradas que probará de manera formal necesitarán de un plan estructurado acerca de cómo realizar esa prueba. ¿Cuánto trabajará el equipo técnico para descubrir problemas de compatibilidad? ¿Cómo administrará las pruebas de aceptación de usuario? Estos factores tienen un impacto importante en la velocidad y en el costo.
  • Creación del entorno de pruebas: las aplicaciones administradas necesitarán un entorno en el que se puedan realizar pruebas de compatibilidad de aplicaciones. Con frecuencia, este será el mismo laboratorio que se usa para efectuar pruebas en las imágenes de implementación. Considere el uso de software de virtualización como Microsoft Hyper-V como alternativa para que los equipos dedicados efectúen en bloque las pruebas de aplicaciones, esto ayudará a reducir el costo de hardware y a simplificar los restablecimientos del entorno para la próxima aplicación.
  • Correcciones: Identifique las aplicaciones que tienen problemas de compatibilidad y busque la actualización correcta. Pruebe la actualización para asegurarse de que los problemas estén realmente corregidos. El Kit de compatibilidad de aplicaciones contiene información sobre la actualización de problemas de compatibilidad en esta documentación.
  • Pilotos: Identifique los integrantes del grupo de pruebas de implementación piloto. Debe elegir a personas que representen cada rol importante dentro de su organización para que pueda obtener comentarios valiosos sobre las aplicaciones, en especial para aquellas aplicaciones compatibles (pero no administradas) y que por lo tanto no se probaron formalmente antes del piloto. Considere la participación de ejecutivos en el grupo piloto. Algunos ejecutivos que son expertos en tecnología podrían optar por dedicar un equipo a la prueba piloto.
  • Aprobación de las aplicaciones: ya que las aplicaciones administradas se validan a través de las pruebas de aceptación del usuario, grabe cada aprobación. Una vez que se certifiquen todas las aplicaciones que usa un rol pueden comenzar las implementaciones piloto, que se pueden ampliar de forma gradual hasta que se complete toda la implementación.
  • Implementación: una vez que se certifiquen todas las aplicaciones administradas, el proceso se vuelve mecánico, continúe con la implementación hasta que haya alcanzado a todos los equipos de la organización.

Es posible que también hayan otras tareas implicadas, lo que depende de las necesidades y de la cultura de la organización. Las decisiones que toma en cuanto a la prioridad de las aplicaciones y las pruebas también se podrían ver afectadas por la estructura de la organización. Por ejemplo, tal vez le gustaría incluir un paso para volver a evaluar la lista de aplicaciones que se implementará en el sistema operativo, para ver si hay aplicaciones nuevas que se deberían agregar.

Estos pasos posteriores se analizan en profundidad en otra documentación, como el Microsoft Deployment Toolkit.

Volver al inicio

Tareas principales

Acerca del autor

Fotografía de Chris JacksonChris Jackson, conocido como " El chico de la compatibilidad de aplicaciones" es consultor principal y el líder técnico del equipo de Experiencia con aplicaciones (AE) SWAT de Windows. Como experto ampliamente reconocido en el campo de la compatibilidad de aplicaciones, Chris creó la documentación técnica, el entrenamiento y las ofertas de servicios usados dentro y fuera de Microsoft, basados en años de experiencia práctica con clientes empresariales y proveedores de software independientes.

Chris es autor o coautor de varios artículos técnicos y de artículos sobre la compatibilidad de aplicaciones, además de contribuir con TechNet Magazine. También es un orador destacado en los principales congresos de la industria alrededor del mundo, inclusive TechEd, IT Forum y Microsoft Management Summit.

Recursos relacionados

Manténgase informado

Microsoft está realizando una encuesta en línea para comprender su opinión del sitio web de. Si decide participar, se le presentará la encuesta en línea cuando abandone el sitio web de.

¿Desea participar?