Microsoft Office: La matematica della compatibilità Office
In fase di pianificazione di un aggiornamento Office, un semplice calcolo matematico consentirà di determinare lo scenario appropriato di test di compatibilità.
Chris Jackson
"I fatti sono ostinate cose; e qualunque sia la nostra volontà, le nostre inclinazioni o i dettami della nostra passione, che non può alterare lo stato dei fatti e delle prove. — John Adams
Così hai deciso di distribuire una nuova versione di Office in tutta l'organizzazione. Quanto tempo si deve aspettare di prendere tra firma sulla linea tratteggiata e quando gli utenti sono produttivi nel loro lavoro quotidiano? Per l'organizzazione di media, che può essere ovunque tra i 12 e i 18 mesi.
Gran parte di tale ritardo è dovuto gli sforzi di gestione di rischio. È necessario assicurarsi che non perturbare il business con i vostri sforzi di distribuzione. Mentre che può sembrare frustrante, non è completamente rinunciare alla gestione del rischio. Come si bilancia questi obiettivi in conflitto?
L'approccio tipico è quello di risolvere questi problemi con la tecnologia. Si utilizzano strumenti per raccogliere dati, come se l'esistenza di dati deve in qualche modo accelerare il processo. Aggiungendo ancora più dati non alleviare la naturale esperienza emotiva della paura. Ci sarà la paura che il vostro aggiornamento causerà qualche fallimento aziendale mission-critical. Si potrebbe applicare la seguente equazione: Il costo del fallimento può essere uguale a infinito.
Deve anche lottare con la paura del cambiamento e l'insistenza che nulla può essere rotto. È possibile scegliere di mantenere una copia virtuale della versione precedente di Office disponibile. Se si verifica un problema con un documento o un'applicazione, è possibile indirizzare l'utente immediatamente per sfruttare questa rete di sicurezza e ottenere di nuovo produttivo. Si potrebbe anche correggere l'applicazione al fine di ottenere nuovamente dentro l'ambiente aggiornato rapidamente come è fattibile.
Troppi pin loro speranze sull'infallibilità di un tool, il processo o il partner senza fermarsi per pensare a ciò che tutti questi significa decisioni. Essi tentano di evitare il fallimento a tutti i costi. Una volta che tu hai ridotto il costo del fallimento da "catastrofico" a "ragionevole e prudente", si dovrebbe esplorare alcuni la matematica dietro queste decisioni. Questo aiuterà a prendere decisioni migliori e valutare le richieste che gli altri stanno facendo.
Quando il costo del fallimento, moltiplicato per la probabilità di guasto è maggiore del costo del test, è consigliabile testare le applicazioni per la compatibilità.
Come con qualsiasi formula generalizzata, questo richiede qualche interpretazione. Test per la compatibilità non è da considerarsi un lusso, né è application compatibility test una tassa. Pensate a come un investimento nella gestione del rischio.
Che cosa significa questo per il resto delle tue applicazioni e documenti — quelli che non prova? Ciò non significa che si dovrebbe ignorarli. Hai semplicemente scelto di non investire in test proattivo. Invece, investire in test reattivi. Correggerli quando un utente segnala che sono rotti (e dovrebbe rendono estremamente facile per gli utenti di farlo).
Immaginate di che avere un documento che è davvero importante, ma non causa indebiti business rottura in caso di guasto. L'utente sarà chiamare l'help desk e il vostro app reattiva-compatibilità con il supporto, è possibile risolvere il problema in una media di 30 minuti. Quel tempo sarà minore se è fondamentale ed è necessario utilizzare la virtualizzazione e ottenere immediatamente produttivo ancora.
Supponendo che si sta monitorando il fallimento del documento, scoprire che voi hanno un tasso di fallimento del 5 per cento per i documenti di Office in questa particolare migrazione. Supponendo che tempo di un utente vale la pena di $250 un'ora, questo fallimento vi costerà $125 volte il 5 per cento, o $6,25. Se il costo ammortizzato del vostro processo di test proattivo supera $6,25, anche solo un centesimo, non dovrebbe preoccuparsi di testing in modo proattivo il documento a tutti.
Prima di inventario?
Il flusso del processo di inventario, razionalizzare, testare e correggere"è diffusa e radicata. Aziende di passano attraverso tutti i generi di contorsioni inseguendo un inventario accurato. La matematica veramente indicare che questo vale la pena?
La risposta, naturalmente, dipende gli ingressi che portano all'equazione. Vale la pena di fare la matematica, però, per determinare come si dovrebbe eseguire il rilevamento della applicazione. Si dovrebbe prendere un inventario completo quando medio tasso moltiplicato per il tempo a determinare la criticità è minore di documenti tasso high times tempo elenco moltiplicato per il numero di documenti.
La prima variabile è come molti documenti che generano in genere. Questo numero ha una grande deviazione standard a seconda della natura del vostro business. Allora avete bisogno di capire quali risorse possono aiutare a determinare come critico è un documento per l'organizzazione.
Razionalizzazione può essere un po ' più difficile con i documenti. Ci sono meno evidenti elementi USA e getta quello che hai con le applicazioni. Allocare quanto tempo pensi che sarà necessaria per determinare se un documento o un'applicazione è all'interno dell'ambito, a seconda della complessità di queste determinazioni nel vostro ambiente. L'alternativa è chiedere gli utenti aziendali (che lavorano ad un costo superiore) quali documenti sono critici e allocano una quantità di tempo per loro di generare questo elenco.
Si supponga che un'organizzazione con 50.000 utenti che generano una media di 500 documenti a persona memorizzato da qualche parte sulla rete, con conseguente 25 milioni di documenti. Assumere le risorse per fare lavoro di razionalizzazione per un tasso di 100 $ per un'ora e che cinque minuti viene speso studiando ogni documento.
Ecco come funziona la matematica:
25.000.000 x 100 x 0,08? 300 x 8 x 100
200,000,000 >> 240,000
Questo si rivela per essere una decisione facile. Se si dovesse prendere un inventario completo e razionalizzare esso, sarebbe costato $200 milioni. E, a questo punto, non hanno ancora determinato se qualcosa funziona ancora. L'alternativa è spendere un paio di centomila dollari in costo opportunità e sono semplicemente persone creare a mano la lista.
La legge dei grandi numeri funziona contro di voi quando si tratta di razionalizzazione di Office. Se il vostro intento è quello di utilizzare strumenti, è necessario utilizzare l'automazione più che solo un inventario. Quello che stai cercando è impatto aziendale, che è difficile per gli attrezzi a dedurre. Un surrogato di qualche uso è la data modificata su file, ma questo è un surrogato imperfetto. Un surrogato migliore sarebbe qualche misura di utilizzo effettivo dal computer client.
Nuove versioni di Office introdurrà una feature di telemetria. Questo è integrato con il prodotto (e installabile sulle versioni di livello inferiore dell'ufficio) e raccoglie i dati dai computer degli utenti sui documenti e i componenti aggiuntivi che stanno usando. Durante la generazione di un inventario di documenti, guardare in particolare documenti che finiscono in un elenco dell'utente più recente utilizzato (MRU). Questo aiuta a raffinare l'inventario da "questo rappresenta ogni documento che nessuno è mai riuscito a creare" a "rappresenta ciò che le persone sono davvero utilizzando tutto il tempo."
Utilizzando questo approccio, sarete in grado di raccogliere e analizzare i dati di telemetria che indica dove è più probabile che esiste il rischio reale. Oggi, tuttavia, non ci è spesso alcun valore migliore per ottenere il vostro inventario più semplicemente chiedendo alle persone di presentare una lista.
Dichiarazioni di sostegno Vendor
Ricerca fornitore è radicata in molti processi di app-compatibilità, particolarmente quando trasportato da una fabbrica di compatibilità delle applicazioni. La domanda di do hai bisogno questo dipende se ti necessitano di supporto del fornitore per una determinata applicazione. Molto probabilmente potrai richiedere assistenza vendor, facendo ricerca fornitore è un requisito aziendale.
Molti dei processi e gli elenchi utilizzati dai fornitori di aiutare a determinare se l'applicazione è stata sostenuta mai sulla piattaforma a cui sta eseguendo la migrazione, e se l'applicazione è attivamente supportata oggi. Questo potrebbe essere un grande indicatore se è probabile che il lavoro su quella piattaforma, perché i fornitori sostengono questo con il proprio supporto dollari.
Si noti che esso in realtà non risposta alla tua domanda di business di se l'applicazione è stata mai supportata e sareste disposti a correre. Essere sicuro di che ricevere la risposta alla domanda che hai chiesto.
La matematica viene qui per determinare se il supporto del fornitore è degno l'investimento di tempo per fare la ricerca. L'alternativa è in esecuzione il processo di valutazione compatibilità voi stessi. Tuttavia, molte persone fare matematica bad, confrontando il costo del test uno app al costo di un'applicazione di ricerca. Questo presupposto viziato postula che troverete le istruzioni per tutto, ma non è l'approccio statisticamente corretto.
Qui è un'equazione efficacia: Si dovrebbe ricerca supporto del fornitore quando il costo del test uno app volte la percentuale non trovata o critica più il costo di ricerca per un app è inferiore al costo di test una app.
Ancora una volta, mettiamo alcuni numeri a questo. Immaginare un processo di testing che finisce che costano $150 per ogni applicazione. Dire allo stesso modo, c'è un processo di ricerca del fornitore che in media $15 per ogni applicazione. L'azienda può individuare le dichiarazioni di supporto per il 12 per cento delle applicazioni, e di quelli, si intende il 10 per cento di prova comunque perché sono mission-critical.
$150 x 89,2% + $15? 150
$148.80 < $150
Sì, ha senso fare ricerca fornitore, ma non è la slam dunk che avrei pensato. Dopo tutto, ricerca venditore sembra essere un decimo del costo di applicazione test. In media, si finisce per salvare solo 1,20 dollari per ogni applicazione.
Naturalmente, salvare nulla (in particolare a scala) è buona, ma dovrebbe dare avviso che sei abbastanza vicino al punto di crossover. Il tasso di fallimento non ha bisogno di muoversi troppo prima di scoprire che sei in numeri negativi. Infatti, con questi presupposti, non appena la percentuale delle domande per le quali è individuare le dichiarazioni di sostegno scende a meno del 10 per cento, comincia a diventare più costoso per cercare le cose su un elenco. Sembra controintuitivo, ma l'opzione con il più basso costo unitario è effettivamente meno desiderabile quando il tasso di fallimento è troppo bassa.
L'enigma di conversione
Le ultime versioni di Office hanno notevolmente migliorato le capacità. Molti la nuova creazione di documenti e funzioni di editing richiedono di utilizzare i più recenti formati di file. Se si desidera sfruttare quelle nuove caratteristiche all'interno di un documento particolare, dovrebbe convertire quei file e passare da lì.
Una delle domande regolari è se si deve andare e aggiornare tutti i documenti per i nuovi formati di file. Il processo sembra facile, naturalmente, e ci sono strumenti per aiutare con questo. Tuttavia, non tutti i documenti saranno l'aggiornamento in modo pulito. Il costo di aggiornamento include la gestione del rischio di assicurare che l'aggiornamento non causa un errore di applicazione. Alcune funzionalità potrebbero essere persi (come ad esempio la funzione "versioni"), alcuni grafici potrebbero apparire diversi e collegamenti ai file utilizzando l'estensione old potrebbero finire rotto.
Naturalmente, questo costo comporta anche un beneficio. Ignorando i file è possibile aggiornare manualmente al fine di utilizzare le nuove funzionalità del prodotto, ogni file potranno beneficiare le dimensioni ridotte dei nuovi formati di file. Per rendere questa determinazione, avete ancora una volta a guardare la matematica per determinare se si dispone di un ROI positivo dall'intraprendere tale attività. Si deve alla rinfusa-convertire tutti i vostri documenti quando il costo di conversione di più il costo del test è inferiore al costo di spazio su disco.
Iniziando con la riduzione dei costi e assumendo la stessa numeri come prima (50.000 utenti con 500 documenti ogni), aggiungere una dimensione media file di 1 MB. Il potenziale di risparmio con questi parametri è il costo del salvataggio di 11TB di spazio su disco. Per mettere che in prospettiva, diciamo per calcolare il costo di quello spazio su disco. Utilizzando una formula calcolato da Matthew Komorowski e postato nel suo "una storia di archiviazione costo," troviamo che il costo equivale a 10 alla potenza di-0.2502 (anno meno 1980) + 6.304.
Questo è computato basato sul prezzo di acquisto di supporti disco da solo. Mentre questo suggerirebbe che si poteva comprare un hard disk per memorizzare i dati per circa 0,02 dollari per gigabyte nel 2012, per calibrare questo contro il totale dei costi, utilizzare i costi di storage di Windows Azure. Questi sono attualmente al prezzo di $128 per terabyte, o appena timido di 6,3 volte superiore rispetto al costo calcolato da questa formula.
Così per calibrare i risultati per tentare di prevedere il costo totale di stoccaggio, modificare la formula come segue: Costo uguale a 6,3 volte 10 alla potenza di-0.2502 (anno meno 1980) plus 6.304.
Supponendo che tu conservare i documenti per una media di 10 anni, il risparmio netto complessivo previsto da questa formula sarebbe $3,209.53. Anche se si presume semplicemente che il costo di stoccaggio su Windows Azure rimarrebbe costante, il risparmio totale sarebbe ancora $14.080.
Pertanto, se si prova i documenti per il successo di probabile conversione e convertire loro per un totale costo inferiore a $14.080 conservativamente ($3,209.53 se si assumono i costi di archiviazione continuerà a diminuire allo stesso tasso esponenziale), allora ha senso convertire.
Se vi costa più di questo sia testare ed eseguire la conversione, quindi non ha senso convertire. Si dovrebbero lasciare i documenti nel formato esistente. Office 2010 può ancora leggere bene. Convertirle manualmente quando è necessario utilizzare le nuove funzionalità.
Lo strumento giusto
Il pattern più comune quando si affronta la compatibilità su qualsiasi piattaforma è alla ricerca di uno strumento per trovare — e speriamo che Difficoltà — tutti i problemi di aggiornamento. Si potrebbe supporre uno strumento connesso con il problema di compatibilità sarà raggiungere tutto o una parte di questo obiettivo e correre ovunque. A un certo punto lungo la strada, vi renderete conto che il problema effettivamente non hanno risolto completamente.
Il problema è uno dei vincoli. Un bug di compatibilità, dopo tutto, è solo un caso speciale di un bug che succede a manifestarsi su di una piattaforma particolare. Questo non è diverso da trovare e fissare tutti i bug sulla piattaforma che hai già. A meno che non devi semplicemente un help desk perché tutti i vostri software funziona tutto il tempo, la mia ipotesi è che hai un sacco di bug di compatibilità con la piattaforma. Che non è perché esso non è capito, ma perché il problema è intrattabile.
La maggior parte di voi hanno almeno un passaggio familiarità con di Alan Turing 1937 prova che non si può costruire un programma per rilevare se un'applicazione sarà fine corsa o continuare a funzionare per sempre. Questo vincolo implementa i limiti di ampia portati che influiscono sulla ricerca ancora oggi come gli scienziati lo sguardo per costruire nuovi sistemi di verifica per assicurare la correttezza del programma. Ad esempio,
"Analisi di contesto delimitata sono un interessante approccio alla verifica dei programmi simultanei. Questo approccio sostiene analizzando tutte le esecuzioni di un programma concorrente, in cui il numero di contesti eseguiti al thread è delimitato da un dato costante k Il numero di contesti eseguiti al thread di delimitazione riduce la complessità asintotica di controllo programmi simultanei: mentre "raggiungibilità" analisi dei programmi simultanei Boolean è indecidibile, la stessa analisi sotto un context-bound è NP-completo [18, 15]. Inoltre, ci sono ampie prove empiriche che errori di sincronizzazione, ad esempio dati gare e violazioni di atomicità, si manifestano in esecuzioni simultanee con un piccolo numero di commutazioni di contesto [19, 16]. Queste due proprietà insieme fare analisi contesto delimitato un approccio efficace per trovare errori di concorrenza. Allo stesso tempo, contesto di delimitazione fornisce per un utile compromesso tra il costo e la copertura della verifica.
È necessario definire esattamente che cosa significa essere un bug. La maggior parte delle persone sono d'accordo che un arresto anomalo del programma è un bug. Ci sono altre situazioni dove determinare se il comportamento del programma è un bug dipende dal contesto. Per esempio, cambiando il colore in un grafo negativamente potrebbe cambiare significato. Potrebbe anche essere accettabile o addirittura auspicabile. Un controllo di versione, che è tecnicamente una caratteristica, perché ha richiesto agli sviluppatori di scrivere codice per introdurre il comportamento — è talvolta considerato un bug da parte della persona che rientra la conformità con le restrizioni della versione.
Sapendo che non riesci a trovare tutti i bug, o anche tutti i bug di una particolare categoria, è necessario garantire che si concentra l'automazione su aree dove l'automazione ha un senso. Risolvere il problema della terminazione, se fosse possibile, ci darebbe la possibilità di interrompere tutti i loop infiniti — un bug comune. Che avrebbe un enorme profitto.
Se si considera il concetto di tentare di trovare e correggere tutti i bug, non tutti avrebbero un payoff. Ci sono teoricamente un numero infinito di modi per scrivere una programmazione bug (se empirici o contestuali) e un numero finito di modi per individuarli tutti. Come il numero di incidenti di programmazione bug diminuisce, il payoff per l'automazione di questi controlli declina allo stesso modo. Questa unità di ciò che abbiamo scelto di automatizzare.
La matematica sono relativamente semplici. Si dovrebbe scrivere test automatizzati per trovare bug quando il costo di creazione ed esecuzione di automazione è inferiore al costo di debug moltiplicato per l'incidenza dei bug.
Questo funziona bene per problemi estremamente comune. Nelle applicazioni di Windows, ad esempio, controllo dell'Account utente fatta in esecuzione con un account utente Standard più realistica per molte organizzazioni. E ' esposto anche un problema di conformità significative con gran parte del software progettato per i tempi quando in esecuzione come amministratore è stato considerato più accettabile. Questi problemi erano così comuni e così simili che creazione di automazione per rilevare tutti li aveva significativi vantaggi rispetto alla risoluzione dei problemi individuali.
I venditori che creano strumenti di verifica per una determinata piattaforma possono ammortizzare il costo di creazione di automazione sopra molti clienti. Che investono nella realizzazione di nuova creazione di test più facile e meno costoso, così possono lavorare questa matematica a vantaggio di esecuzione di test molto di più. Allo stesso tempo, le prove che potrebbero essere più semplice (ed economico) per creare potrebbe avere un'incidenza molto bassa. Guardando per il tipo I (falso positivo) e gli errori di tipo II (falso negativo) diventa importante.
Tecnologie Verifier arrivando nelle nuove versioni di Office combattono alcune delle sfide con le versioni precedenti del tool, che erano soggette a sia di tipo I e tipo II errori. C'era anche confusione per quanto riguarda l'applicabilità a particolari scenari.
Il set di strumenti di Gestione pianificazione migrazioni di Microsoft Office, ad esempio, analizza e determina eventuali problemi potenziali. Sembra anche i problemi della conversione del documento in nuovi formati di file (che sarebbero una sfida, se si è scelto di lasciare semplicemente il documento come è). Il nuovo focus di verifica sarà su questioni di distribuzione-bloccanti, come l'utilizzo di API deprecate e crash di applicazione (in genere causata da add-ins).
Questo lavoro di valutazione, test e conversione è davvero la fase finale di un processo in tre fasi:
- Alleviare paure emotive così può pensare razionalmente.
- Raccogliere i dati di destro.
- Analizzare i dati per convertirlo da dati in informazioni a conoscenza.
E qui è la base matematica dietro alcune linee guida:
- Non dovete fare qualcosa solo perché si può.
- È consigliabile eseguire il vostro lavoro di compatibilità delle applicazioni come se si stesse scrivendo per un giornale: Iniziare con le cose più importanti e funzionare il vostro senso giù. Non tutto finisce, e si desidera terminare la roba più importante.
- Non confondere attività obbligatoria con attività facoltative, anche se sembrano correlate.
Idealmente, avventure nell'esplorare la matematica dietro come a prendere decisioni migliori su cosa includere nel tuo progetto di compatibilità Office vi spingerà a domanda tua ipotesi e migliorare l'efficienza.
.jpg)
Chris Jackson è "The App Compat Guy" di Microsoft. Egli è un consulente principale e il piombo in tutto il mondo per la compatibilità delle applicazioni enterprise. Egli è un oratore frequenti conferenze e sviluppatore e lavora con clienti e partner in tutto il mondo. La sua missione è "ripristino agilità tecnologia rimuovendo le catene di software legacy." Saperne di più da Jackson sul suo blog (appcompatguy.com) e su Twitter a twitter.com/appcompatguy.