Exportar (0) Imprimir
Expandir todo

Analizar los datos de compatibilidad de aplicaciones

Para poder pasar de la fase de inventario a la prueba de las aplicaciones propiamente dicha, deberá tomar algunas decisiones difíciles relativas a la prioridad de las aplicaciones, y acerca de las aplicaciones y versiones que se admitirán oficialmente una vez que finalice la implementación.

La primera revisión del inventario completo es bastante sencilla:

Redundancia de aplicaciones- hay más de una aplicación en la organización a cargo de las mismas tareas.

Relevancia de las aplicaciones- hay varias versiones de una aplicación en la organización, entre las que se incluyen versiones obsoletas y no admitidas. En función de la aplicación y la infraestructura, tal vez sea conveniente comprobar las dependencias de aplicación a aplicación antes de pasar a una versión totalmente nueva de una aplicación determinada.

Necesidad de aplicaciones- hay aplicaciones en la organización que son irrelevantes para el trabajo diario que se realiza en la organización.

Es posible usar el inventario de aplicaciones para reducir la redundancia de aplicaciones. Por ejemplo, la organización puede tener varias aplicaciones destinadas a la creación de gráficos. Mediante la selección de una sola aplicación, y de una sola versión de dicha aplicación como estándar, la organización puede ahorrar parte del dinero que invierte en soporte. Si se identifica una versión de la aplicación requerida que resulte compatible con la versión del sistema operativo Windows que se está implementando, también es posible reducir las pruebas de implementación mediante el enfoque en esta sola aplicación y versión.

El siguiente paso consiste en clasificar las aplicaciones en grupos a partir de la importancia relativa de dicha aplicación dentro de la organización. Para comprender este requisito, deberá trabajar junto con los propietarios comerciales de cada aplicación. Algunas aplicaciones se consideran críticas para la empresa, de forma que el funcionamiento de la empresa se ve interrumpido si la aplicación presenta errores o no está disponible. Otras aplicaciones son muy importantes, pero hay formas de mantener parte de la actividad de la empresa si éstas presentan errores. Aunque la terminología individual puede variar, a continuación figuran algunos niveles de prioridad habituales que se deben tener en cuenta:

Crítica para la empresa- una aplicación que detiene la organización por completo si no se ejecuta correctamente. Si tiene dudas sobre si una aplicación pertenece a esta categoría, considere si la organización puede producir algo de dinero mientras la aplicación no está disponible, y si el personal puede continuar realizando algunas tareas sin esta aplicación. Si esta aplicación dejara de funcionar a mitad de la noche, ¿cuánto tiempo tardaría su buscapersonas en apagarse? A menudo, las aplicaciones críticas para la empresa tienen contratos de nivel de servicio (SLA) que estipulan que el personal de soporte debe responder a un error en un plazo de 15 minutos o menos.

Prioridad alta- las aplicaciones que tienen un rol fundamental en un departamento o a lo largo de una organización. Un error en una aplicación de prioridad alta puede deshabilitar un departamento o una sola función empresarial de la organización. Si una aplicación de prioridad alta presenta errores, la organización puede seguir en actividad, pero el funcionamiento de uno o más departamentos puede verse gravemente obstaculizado. Un SLA típico para una aplicación de prioridad alta se mediría en horas.

Importante- una aplicación importante que se usa con frecuencia, pero que no obliga a detener el trabajo en caso de presentar errores. Un ejemplo sería una aplicación de hoja de cálculo o procesador de textos ampliamente usada, pero que no está relacionada con una función empresarial fundamental. Los SLA de las aplicaciones importantes se pueden medir en días.

Opcional- aplicaciones aprobadas que se usan de forma limitada y que no están directamente relacionadas con una función empresarial. Una aplicación de esta categoría no suele estar cubierta por un SLA, y el soporte se consideraría como del “mejor esfuerzo”.

La asignación de niveles de prioridad a las aplicaciones suele ser un proceso subjetivo, y puede estar sujeto a revisiones periódicas. Éste es un motivo válido para disponer que un equipo o comité supervise la cartera de aplicaciones incluso entre implementaciones del sistema operativo.

Una vez que haya establecido la prioridad del inventario de aplicaciones, también deberá dedicar algo de tiempo a identificar las aplicaciones que se pueden eliminar. Quitar las versiones anteriores de las aplicaciones puede reducir en gran medida la cantidad de pruebas de aplicaciones que se deben realizar para implementar un nuevo sistema operativo. Considere si las versiones anteriores aún pueden ser admitidas por el fabricante. Recopilar un inventario de aplicaciones es una buena oportunidad para comprobar si el uso de la licencia es correcto, como en los casos en los que la aplicación se instala en demasiados equipos.

Identificar aplicaciones críticas para la empresa

Algunas aplicaciones críticas para la empresa son fáciles de identificar, mientras que otras no lo son. Si la organización opera a través de una presencia en Internet, es posible que las aplicaciones de procesamiento de textos, manipulación de imágenes y codificación de páginas se consideren críticas para la empresa. La categorización crítica de la empresa también varía según la función. Para un centro de llamadas, es posible que una aplicación que supervisa la estabilidad del servidor resulte crítica, aunque otros departamentos no la consideren valiosa en absoluto.

Si la organización cuenta con un plan de recuperación ante desastres (DRP) o un plan de continuidad empresarial (BCP), las aplicaciones críticas para la empresa ya deberían estar identificadas en dichos planes.

Algunos criterios de identificación de aplicaciones críticas para la empresa incluyen:

  • La aplicación representa una función principal de la organización, tal como un software de procesador de textos o diseño de páginas para una compañía editorial.

  • Por tanto, la organización sufrirá un impacto financiero significativo si esta aplicación presenta errores.

  • Si esta aplicación deja de funcionar durante las horas de menos actividad, el buscapersonas de alguien se apagará en cuestión de minutos.

Identificar aplicaciones de prioridad alta

Las aplicaciones de prioridad alta pueden ser fáciles de identificar en el propio departamento, pero difíciles de identificar en otros departamentos. En ocasiones, es posible identificar una aplicación de prioridad alta si se tiene en cuenta el porcentaje de equipos en los que está instalada, aunque esto puede ser dudoso. Una aplicación que se desarrolló internamente para supervisar la cantidad de tóner en las impresoras láser de la compañía se podría implementar en todos los equipos, aunque muy pocas personas la usen realmente. Si la organización cuenta con un plan de recuperación ante desastres (DRP) o un plan de continuidad empresarial (BCP), puede que las aplicaciones de prioridad alta ya estén identificadas en dichos planes.

Algunos criterios de identificación de aplicaciones de prioridad alta incluyen:

  • La aplicación se usa durante la mayor parte del turno de trabajo.

  • Un gran porcentaje de usuarios dentro de la organización usan la aplicación.

  • Sin la aplicación, sería difícil para la organización o departamento operar de forma normal.

  • Sin la aplicación, las operaciones diarias se verían afectadas y podría producirse un impacto financiero significativo.

Identificar aplicaciones para roles específicos

El concepto de roles de usuario puede ser útil para determinar los componentes de las imágenes del sistema operativo específicas para su implementación. Si se separa el conjunto de usuarios en roles específicos, esto facilita la definición de las aplicaciones que se van a agregar a la imagen del sistema operativo. Por ejemplo, si se define un rol de usuario de contabilidad, se puede especificar que, además del sistema operativo, los usuarios de este rol recibirán Microsoft® Office y el software de contabilidad estándar de la organización. Algunos roles posibles incluyen:

  • Recursos humanos

  • Trabajador de la información

  • Servicio de soporte de TI

  • Marketing

  • Desarrollador

  • Ejecutivo

Por supuesto que también hay aplicaciones que son estándar en todas las imágenes del sistema operativo. Algunos ejemplos podrían incluir las aplicaciones de correo electrónico y antivirus. Estas aplicaciones formarán parte de una imagen básica, por lo que deberían probarse detenidamente en cuanto a compatibilidad y estabilidad con Windows 7®. Las imágenes de implementación de los otros roles se basan en la imagen básica, a la vez que agregan otras aplicaciones usadas por el rol.

También se puede establecer la prioridad de los roles de implementación para reducir los esfuerzos necesarios para probar la compatibilidad de aplicaciones. Las configuraciones basadas en roles para las operaciones críticas deben ser las más probadas, mientras que las imágenes de prioridad más baja pueden someterse a menos pruebas. Las configuraciones de roles que únicamente presentan pequeñas diferencias con respecto a la imagen básica pueden someterse a pruebas mínimas. Este orden de prioridad también se puede trasladar a la implementación real. Los roles que contienen aplicaciones sin problemas de compatibilidad se pueden implementar antes, y aquellos con problemas se pueden implementar después de que se hayan realizado las pruebas y correcciones correspondientes.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft