Microsoft Office: Las matemáticas de la compatibilidad de Office.
Al planear una actualización de Office, unas matemáticas sencillas le permitirán determinar el escenario de prueba de compatibilidad.
Chris Jackson
"Los hechos son cosas difíciles; y cualquiera que sea nuestros deseos, nuestras inclinaciones o los dictados de nuestra pasión, no pueden alterar el estado de hechos y pruebas. — John Adams
Así que ha decidido implementar una nueva versión de Office en su organización. ¿Cuánto tiempo debe esperar para tomar entre firmar sobre la línea punteada y cuando los usuarios son productivos en su trabajo cotidiano? Para la organización de promedio, que puede ser entre 12 y 18 meses.
Gran parte de ese retraso es debido a los esfuerzos de la administración de riesgo. Debe asegurarse de que no perturbar el negocio con sus esfuerzos de implementación. Mientras que puede parecer frustrante, no puede renunciar completamente gestión del riesgo. ¿Cómo equilibrar estos objetivos conflictivos?
El enfoque típico es resolver estos problemas con tecnología. Utilice herramientas para recopilar datos, como si la existencia de datos de alguna manera debe acelerar su proceso. Añadir aún más datos no aliviar la experiencia emocional natural de miedo. Habrá temor que su actualización causará algún fallo de negocios de misión crítica. Se puede aplicar la siguiente ecuación: El costo de falla puede igual a infinito.
Usted debe también lidiar con el miedo del cambio y la insistencia de que nada puede romperse. Puede guardar una copia virtual de la versión heredada de Office disponible. Si experimenta un problema con un documento o aplicación, puede dirigir al usuario inmediatamente aprovechar esta red de seguridad y volver productivo. También podría remediar la aplicación con el fin de volver al entorno actualizado tan pronto como sea posible.
Demasiados prender sus esperanzas sobre la infalibilidad de una herramienta o socio sin detenerse para pensar en lo que todos de la media de estas decisiones. Intentan evitar a toda costa el fallo. Una vez que ha reducido el costo del fracaso de "catastrófico" «razonable y prudente», debe explorar algunas de las matemáticas detrás de estas decisiones. Esto le ayudará a tomar mejores decisiones y evaluar las reclamaciones de que otros están haciendo.
Debe probar la compatibilidad de las aplicaciones cuando el costo de falla multiplicado por la probabilidad de fracaso es mayor que el costo de las pruebas.
Como con cualquier fórmula generalizada, esto requiere alguna interpretación. Pruebas de compatibilidad no es considerado un lujo, ni pruebas de compatibilidad de aplicación es un impuesto. Considerar como una inversión en la gestión de riesgo.
¿Qué significa esto para el resto de las aplicaciones y documentos — los que no probar? Esto no significa que usted debe ignorarlos. Simplemente ha decidido no invertir en pruebas proactivas. En su lugar, usted invierte en pruebas reactivas. Fijarlos cuando un usuario informa que están rotos (y debería ser extremadamente fácil para los usuarios que hacer).
Imagine que tiene un documento que es importante, pero no causa la interrupción del negocio indebido en caso de fallo. El usuario llamar la atencin y con su app-compatibilidad reactiva de soporte, puede resolver el problema en un promedio de 30 minutos. Ese tiempo será menor si es crítico y necesita utilizar la virtualización e inmediatamente volver productivo.
Suponiendo que está realizando el seguimiento de fallos de documento, descubres que tiene una tasa de fracaso de 5 por ciento para documentos de Office en esta migración particular. Suponiendo que el tiempo de un usuario vale $250 la hora, este fracaso le costará $125 veces el 5 por ciento, o $6,25. Si el costo amortizado de su proceso de pruebas proactiva excede $6.25, incluso por sólo un céntimo, no debería molestar proactivamente pruebas en todo el documento.
¿Inventario primero?
El flujo del proceso de "inventario, racionalizar, probar y corregir" es omnipresente y arraigado. Las empresas llegan a través de todo tipo de acrobacias persiguiendo un inventario preciso. ¿La matemática indica realmente que esto vale la pena?
La respuesta, por supuesto, depende de las entradas que lleve a la ecuación. Vale la pena hacer las matemáticas, sin embargo, para determinar cómo debe realizar el descubrimiento de la aplicación. Usted debe tomar un inventario completo cuando multiplicado por el número de documentos por medio de tasa multiplicado por el tiempo para determinar la criticidad es menor que la tasa high times tiempo lista documentos.
La primera variable es cuántos documentos que genera normalmente. Este número tiene una gran desviación estándar según la naturaleza de su negocio. Entonces es necesario averiguar qué recursos pueden ayudar a determinar lo importante que es un documento para su organización.
Racionalización puede ser un poco más difícil con documentos. Hay menos artículos desechables obvios que tienes con aplicaciones. Asignar es cuánto tiempo cree que es necesario para determinar si un documento o aplicación en el ámbito de aplicación, dependiendo de la complejidad de hacer estas determinaciones en su entorno. La alternativa es pedirle a los usuarios de negocios (que trabajan en un mayor costo) documentos que son críticos y asignan cierta cantidad de tiempo para generar esta lista.
Supongamos que tiene una organización con 50.000 usuarios que generan un promedio de 500 documentos por persona almacenada en algún lugar de la red, resultando en 25 millones de documentos. Asumir los recursos para realizar trabajo de racionalización para una tasa de $100 una hora y cinco minutos se dedica a investigar cada documento.
Aquí está cómo funciona la matemática:
¿25,000,000 x 100 x 0,08? 300 x 8 x 100
200,000,000 >> 240,000
Esto resulta para ser una decisión fácil. Si tuviera que tomar un inventario completo y racionalizarlo, costaría $200 millones. Y, en este punto, aún no han determinado si nada funciona todavía. La alternativa es pasar un par de 100 mil dólares en el costo de oportunidad y simplemente tener gente cree la lista a mano.
La ley de grandes cifras funciona contra usted cuando se trata de racionalización de la Oficina. Si su intención es utilizar herramientas, tienes que utilizar la automatización más que simplemente un inventario. Lo que buscas es el impacto en el negocio, que es difícil para herramientas deducir. Un suplente algún uso es la fecha de modificado en el archivo, pero esto es un sustituto imperfecto. Un mejor sustituto sería alguna medida de uso real de los equipos cliente.
Nuevas versiones de Office introducirá una característica de telemetría. Esto es integrado con el producto (e instalable en versiones de nivel inferior de oficina) y recopila los datos de los equipos de los usuarios en los documentos y los complementos están utilizando. Cuando se genera un inventario de documentos, mirar específicamente de documentos que terminan en la lista de usados recientemente (MRU) de un usuario. Esto ayuda a refinar el inventario de «esto representa cada documento que nadie nunca ha conseguido crear» a «esto representa lo que la gente realmente está usando todo el tiempo.»
Con este enfoque, serás capaz de recoger y analizar datos de telemetría que indica donde es más probable que existe el riesgo real. Hoy, sin embargo, no hay a menudo mejor valor para obtener su inventario que simplemente pidiendo a la gente a presentar una lista.
Declaraciones de apoyo de proveedor
Investigación de proveedor está arraigada en muchos procesos de compatibilidad de aplicaciones, especialmente cuando entregado por una fábrica de compatibilidad de aplicaciones. La cuestión de no necesita esto depende si te requieren asistencia de proveedores para una aplicación dada. Si es muy probable que te requieren asistencia de proveedores, haciendo investigación de proveedor es un requisito de negocio.
Muchos de los procesos y las listas utilizadas por proveedores ayudan a determinar si la aplicación nunca ha sido apoyada en la plataforma que migra, y si la aplicación es apoyada activamente hoy. Este podría ser un gran indicador de si es probable que el trabajo de esa plataforma, porque los vendedores afirman esto con su propio apoyo dólares.
Cuenta que lo realmente no responde a tu pregunta de negocios de si la solicitud fue apoyada nunca estaría dispuesto a ejecutarlo. Asegúrese de que reciba la respuesta a la pregunta.
Las matemáticas entra aquí para determinar si vale la pena la inversión de tiempo para hacer esa investigación asistencia de proveedores. La alternativa está ejecutando el proceso de evaluar la compatibilidad usted mismo. Sin embargo, muchas personas no matemáticas mal, comparar el coste de una app para el costo de investigar una aplicación de prueba. Esta suposición errónea postula que encontrará instrucciones para todo, pero no es el enfoque correcto estadísticamente.
Aquí es una ecuación eficaz: Debe investigar soporte de proveedor cuando los costos de pruebas una app veces el porcentaje no encontrado o crítico además el costo de la investigación para una app es menor que el costo de las pruebas de una app.
Una vez más, vamos a poner algunos números a esto. Imaginar un proceso de pruebas que termina con un costo de $150 por aplicación. Asimismo, dicen que hay un proceso de investigación de proveedor que promedia $15 por cada aplicación. La empresa puede localizar las declaraciones de apoyo de 12 por ciento de las aplicaciones, y de esos, va a probar el 10 por ciento de todas formas porque son críticos.
¿$ 150 x 89,2% + $15? 150
$148.80 < $150
Sí, tiene sentido hacer investigación de proveedor, pero no los mates que hubiera pensado. Después de todo, investigación de proveedor parece ser una décima parte el costo de pruebas de aplicaciones. En promedio, terminas sólo ahorro $1.20 por cada aplicación.
Por supuesto, ahorrando nada (sobre todo a escala) es bueno, pero debería darle una advertencia que está muy cerca del punto de crossover. La tasa de fallos no necesita moverse mucho antes de que descubres que estás en números negativos. De hecho, con estas suposiciones, tan pronto como el porcentaje de aplicaciones para que usted localice las declaraciones de apoyo cae a menos del 10 por ciento, empieza a ser más costoso buscar cosas en la lista. Parece contrario a la intuición, pero la opción con el menor costo unitario es menos deseable cuando su tasa de fracaso es muy baja.
El acertijo de conversión
Las últimas versiones de Office han mejorado notablemente las capacidades. Muchas de la nueva creación de documentos y características de edición requieren utilizar los formatos de archivo más recientes. Si usted desea aprovechar las nuevas funciones dentro de un documento concreto, debe convertir esos archivos e irse de allí.
Una de las preguntas regulares es si debe pasar y actualizar todos los documentos a los nuevos formatos de archivo. El proceso parece fácil, por supuesto, y hay herramientas para ayudar con esto. Sin embargo, no todos los documentos se actualizarán limpiamente. El costo de actualización incluye la gestión del riesgo de garantizar que la actualización no causa una falla en la aplicación. Algunas funciones podrían perderse (como la característica de «versiones»), algunos gráficos pueden ser distintas y vincula el archivo con la extensión de archivo antiguo podría acabar rotos.
Por supuesto, este costo también incurre en un beneficio. Haciendo caso omiso de archivos puede actualizar manualmente para poder utilizar las nuevas características del producto, cada archivo se beneficiará con el tamaño de archivo reducido de los nuevos formatos de archivo. Para hacer esta determinación, una vez más tienes que mirar las matemáticas para determinar si tienes un ROI positivo de realizar dicha actividad. Usted debe a granel-convertir todos sus documentos cuando el costo de convertir más el costo de las pruebas es menor que el costo del espacio en el disco.
Comenzando con el ahorro de costes y suponiendo que el mismo números como antes (50.000 usuarios con 500 documentos cada), añadir un tamaño promedio de archivo de 1 MB. El potencial de ahorro con estos parámetros es el costo de salvar a Comisión de espacio en disco. Para poner en perspectiva, vamos a calcular el costo de ese espacio de disco. Utilizando una fórmula calculada por Matthew Komorowski y publicado en su "una historia del costo de almacenamiento de información," encontramos que el costo equivale a 10 a la potencia de-0.2502 (año menos 1980) más 6.304.
Esto se calcula basándose en el precio de compra de medios de disco solo. Mientras esto sugeriría que usted podría comprar un disco duro para almacenar datos de alrededor de $0.02 por gigabyte en 2012, para calibrar este contra los costos totales, utilizar los costos de almacenamiento de Windows Azure. Estos son actualmente un precio de $128 por terabyte, o apenas 6,3 veces mayor que el costo calculado de esta fórmula.
Así que para calibrar los resultados para intentar predecir el costo total de almacenamiento de información, modificar la fórmula siguiente: Costo equivale a 6,3 veces 10 a la potencia de-0.2502 (año menos 1980) además de 6.304.
Suponiendo que usted mantenga documentos para un promedio de 10 años, el ahorro neto total predicho por esta fórmula sería $3,209.53. Incluso si usted simplemente asumió que el costo de almacenamiento de Windows Azure seguiría siendo constante, el ahorro total sería $14.080.
Por lo tanto, si se prueba sus documentos para conversión probable éxito y convertir para un total coste de menos de $14.080 conservadoramente ($3,209.53 si usted asume los costos de almacenamiento continuará disminuyendo al mismo ritmo exponencial), entonces tiene sentido convertir.
Si te cuesta más que esta a prueba y ejecutar la conversión, entonces no tiene sentido convertir. Debe dejar sus documentos en el formato existente. Office 2010 puede aún leerlas bien. Convertirlos manualmente cuando es necesario utilizar nuevas funciones.
La herramienta adecuada
El patrón más común al abordar la compatibilidad en cualquier plataforma está buscando una herramienta para encontrar — y ojalá fijar — todos los problemas de actualización. Debe suponer una herramienta asociada con el problema de compatibilidad se lograr todos o parte de este objetivo y ejecutarlo en todas partes. En algún punto del camino, obtendrá que realmente no ha resuelto ese problema completamente.
El problema es de restricción. Un error de compatibilidad, después de todo, es sólo un caso especial de un error que sucede a manifestarse en esa plataforma en particular. Esto no es diferente de encontrar y corregir todos los errores en la plataforma que ya tiene. A menos que usted simplemente no tiene un escritorio de ayuda porque todo su software funciona todo el tiempo, Mi conjetura es que tienes mucho de los errores de compatibilidad con esa plataforma. No es porque no entendió, sino porque el problema es intratable.
La mayoría de ustedes tiene al menos un paso familiaridad con prueba de 1937 Alan Turing que no se puede construir un programa para detectar si una aplicación se termine de ejecutarse o continuar funcionando para siempre. Esta restricción aplica límites trascendentales que afectan a la investigación aún hoy como la mirada de los científicos para construir nuevos verificadores para asegurar la exactitud del programa. Por ejemplo:
"Análisis de contexto acotado es un enfoque atractivo a la verificación de programas simultáneos. Este enfoque propugna analizando todas las ejecuciones de un programa concurrente en el que el número de contextos ejecutados por hilo está rodeado de una determinada constante k El número de contextos ejecutados por hilo de límite reduce la complejidad asintótica de comprobación de programas simultáneos: mientras que el análisis de "accesibilidad" de programas simultáneos de Boolean es indecidible, el mismo análisis bajo un contexto enlazado es NP-completo [18, 15]. Además, existe amplia evidencia empírica que errores de sincronización, como carreras de datos y las violaciones de atomicidad, se manifiestan en ejecuciones simultáneas con un pequeño número de cambios de contexto [19, 16]. Estas dos propiedades juntos hacen análisis delimitadas por el contexto de un enfoque eficaz para encontrar errores de concurrencia. Al mismo tiempo, contexto delimitador proporciona para un compromiso útil entre el costo y la cobertura de verificación."
Es necesario definir precisamente lo que significa ser un bug. Mayoría de la gente acepta que un accidente de programa es un error. Hay otras situaciones donde determinar si el comportamiento del programa es un error depende de contexto. Por ejemplo, cambiar el color de un gráfico puede cambiar negativamente significado. También podría ser aceptable o incluso deseable. Una comprobación de versión — que es técnicamente una característica, porque requería el desarrollador escribir código para introducir el comportamiento — a veces se considera un error por la persona que cae fuera del cumplimiento de las restricciones de la versión.
Sabiendo que no puede encontrar todos los errores, o incluso todos los errores de una categoría en particular, debe asegurarse de que usted enfoca su automatización en áreas donde la automatización tiene sentido. Para resolver el problema de parada, si fuera posible, nos daría la posibilidad de detener todos los bucles infinitos — un error común. Tendría una recompensa enorme.
Cuando se considera el concepto de tratar de encontrar y corregir todos los errores, no todos tendrían una recompensa. Teóricamente hay un número infinito de formas de escritura, una programación de errores (ya sea empírica o contextual) y un número finito de maneras de detectar a todos ellos. Como el número de incidentes de programación bugs disminuye, la recompensa para la automatización de estas comprobaciones se declina igualmente. Esto impulsa lo que elegimos para automatizar.
Las matemáticas son relativamente simples. Usted debe escribir pruebas automatizadas para encontrar errores cuando el costo de creación y ejecución de automatización es menor que el costo de depuración multiplicado por la incidencia de errores.
Esto funciona bien para problemas muy comunes. En aplicaciones de Windows, por ejemplo, Control de cuentas de usuario hizo correr con cuentas de usuario estándar, más realista para muchas organizaciones. También expone un problema significativo cumplimiento con gran parte del software diseñado para veces cuando ejecuta como administrador fue considerado más aceptable. Estos problemas eran tan comunes y tan similares que creación de automatización para detectar todos ellos tenía ventaja significativa en comparación con la solución de problemas individuales.
Proveedores que creación herramientas de verificación para una plataforma determinada pueden amortizar el costo de crear la automatización en muchos clientes. Invierten en hacer la nueva creación de prueba más fácil y menos costoso, para que puedan trabajar esta matemáticas a la ventaja de ejecutar pruebas mucho más. Al mismo tiempo, las pruebas que podrían ser más fácil (y barato) crear podría tener una incidencia muy baja. Viendo para tipo I (falso positivo) y errores de tipo II (falsos negativos) se convierte en importante.
Tecnologías de verificador en nuevas versiones de Office combaten algunos de los desafíos con versiones anteriores de la herramienta, que fueron objeto de ambos tipo I y tipo II errores. También hubo confusión con respecto a la aplicabilidad a situaciones particulares.
El conjunto de herramientas del administrador de planificación de migración de Office, por ejemplo, analiza y determina los posibles problemas. También examina los desafíos de convertir el documento a nuevos formatos de archivo (que sería un reto si elige simplemente dejar el documento como está). El nuevo enfoque de verificación será sobre cuestiones de implementación-bloqueadores, como usando API obsoletas y bloqueos de la aplicación (normalmente causados por add-ins).
Este trabajo de evaluación, pruebas y convertir realmente es el último paso en un proceso de tres pasos:
- Aliviar temores emocionales por lo que puede pensar racionalmente.
- Recopilar los datos correctos.
- Analizar los datos para convertirlo de datos a la información al conocimiento.
Y aquí está la base matemática detrás de algunas directrices:
- No tienes que hacer algo sólo porque se puede.
- Debe ejecutar su trabajo de compatibilidad de aplicaciones como si estuvieras escribiendo para un periódico: Comience con las cosas más importantes y su camino hacia abajo. No todos los acabados, y desea terminar las cosas más importantes.
- No confunden las tareas obligatorias con tareas opcionales, incluso si parecen relacionados.
Idealmente, aventuras en explorar las matemáticas detrás de cómo tomar mejores decisiones sobre qué incluir en su proyecto de compatibilidad de Office inspirará a cuestionar sus suposiciones y mejorar la eficiencia.
.jpg)
Chris Jackson es "The App Compat Guy" de Microsoft. Él es un consultor principal y el plomo en todo el mundo para la compatibilidad de aplicaciones de empresa. Es un orador frecuente en conferencias y desarrollador y trabaja con clientes y socios en todo el mundo. Su misión es "restaurar agilidad tecnología quitando los grilletes del software heredado." Leer más de Jackson en su blog (appcompatguy.com) y en Twitter en twitter.com/appcompatguy.