Microsoft Office：Office 兼容性的数学原理
规划 Office 升级时，简单的数学原理可以帮助您确定恰当的兼容性测试场景。
Chris Jackson
"事实是顽固的事情 ； 和任何可能是我们的愿望，我们倾向或我们的激情的规定，他们不能改变的事实和证据的状态。— — 约翰 · 亚当斯
所以你决定要部署的办公室在整个组织的新版本。 你多长时间应该期望它采取之间签署在虚线上和您的用户是其日常工作富有成效？ 平均的组织，可任意位置 12 至 18 个月。
很多这种延迟是由于风险管理工作。 你必须确保你不要扰乱业务与您的部署工作。 虽然这看起来可能令人沮丧，你不能完全放弃风险管理。 您如何平衡这些互相冲突的目标呢？
典型的方法是要解决这些问题的技术。 您使用工具来收集数据，就像生死存亡的数据必须以某种方式加快您的流程。 仍添加更多的数据并不能减轻恐惧的自然的情感体验。 将您的升级将导致某些任务关键型业务失败的恐惧。 您可以应用以下公式：失败的成本可以等于无穷大。
您还必须应付变化，什么也不能被打破，坚持的恐惧。 您可以选择要保留旧版本的 Office 可用的虚拟拷贝。 如果您遇到一个文档或应用程序的问题，您可以指示用户可以立即利用这个安全网，并再次获得生产。 你也可以补救应用中，以尽快是可行回进入升级后的环境。
太多把希望寄托在工具、 进程或合作伙伴的仅仅不停去想什么所有的这些决定意味着。 他们企图不惜一切代价避免失败。 一旦"合理和审慎"，已经从"灾难性的"减少失败的成本，您应该探索一些这些决策背后的数学。 这将有助于您做出更好的决策和评估其他正在进行的索赔。
当失败的故障概率乘以的成本大于测试的成本时，您应该测试您的应用程序的兼容性。
作为与任何广义的公式，这需要一些解释。 兼容性测试并不是被视为一种奢侈，也不应用程序兼容性测试一种税。 把它作为一种投资风险管理。
这意味着您的文档和应用程序的其余部分什么 — — 你并没有测试的那些？ 这并不意味着你应该忽略他们。 您只需选择不投资于主动测试。 相反，你投资无功测试中。 您修复这些用户报告时他们破碎 （和你应该非常便于用户这样做）。
想象一下你有一个文档，固然重要，但不会导致出现故障时的过高的业务中断。 用户将呼叫帮助台，与你无功的应用程序兼容性支持，您可以解决该问题的平均为 30 分钟。 如果它是关键，您需要使用虚拟化，会立即得到生产再次，那时候将会减少。
假设您正在跟踪文档失败，你会发现你在这个特定的迁移的 5%的失败率为 Office 文档。 假定用户的时间值得每小时 250 美元，这一失败将花费你 $125 倍 5%或 6.25 元。 如果您积极主动的测试过程的分摊的成本超过 $6.25，甚至只是一分钱，你不应该去打扰主动在所有测试文档。
第一次的库存吗？
"库存、 合理化、 测试和补救"的过程流是普遍而根深蒂固。 公司经过各种各样的扭曲追逐了准确的库存。 数学计算是否真的表示这是物有所值呢？
答案当然取决于你带的方程的投入。 它是值得做数学题，不过，以确定如何，您应执行应用程序发现。 当文档数乘以乘以的时间来确定临界小于率超高倍时间列表文件的速率介质，您应采取一份完整的清单。
多少个文档通常生成第一个变量。 这一数字已根据您的业务的性质的大型标准偏差。 然后您需要弄清楚哪些资源可以帮助您确定如何关键文档是对您的组织。
合理化可以有点难度的文档。 有较少明显的一次性项目比你的应用程序。 分配多少时间，你认为它将需要以确定是否有一个文档或应用程序是在范围内，取决于您的环境中使这些决定的复杂性。 另一种是询问业务用户 （工作在更高的成本） 的文档非常关键，和分配时间，如果要生成此列表的。
假定您有一个人平均每人在网络上，存储在地方造成 2500 万的文档中的 500 文档生成的 50000 个用户的组织。 假设一个小时和那五分钟花了调查的每个文档的 100 美元的费率合理化工作的资源。
这里是数学计算的工作方式：
25,000,000 x 100 x 0.08 吗？ 300 x 8 x 100
200,000,000 >> 240,000
这就是一个轻松的决定。 如果你是一份完整的清单，并使 it 合理化，它将花费 $2 亿。 而且，在这一点上，你甚至还没决定是否什么作品尚未。 另一种选择是要花一对夫妇 10 万美金的机会成本，只是大家都用手工创建的列表。
大数定律的工作对你不利，办公室合理化的时候。 如果你的意图是要使用的工具，您必须使用更多自动化比只是一份清单。 你在寻找什么是对业务的影响，是很难推断出的工具。 一个代理项一些使用已修改日期是在该文件，但这是一个不完美的代理项。 为更好的代理项将从客户端计算机的实际使用情况的一些测量。
新版本的 Office 将介绍一种遥测功能。 这是集成的产品 （和对较低级别版本的 Office 安装），并从用户的计算机上的文件和加载它们使用收集的数据。 当生成文档清单，专门看最终用户最近使用的文档 (MRU) 列表中的文件。 这有助于优化库存从"这代表有人已曾设法创建的每个文档"到"这代表什么人们真的使用所有的时间"。
使用这种方法，你会能够收集并分析表示更有可能存在的真正风险是的遥测数据。 今天，然而，常没有更好值用于获取您库存比只要求提交一份名单的人。
供应商支持声明
供应商研究进许多应用程序兼容性流程，根深蒂固，特别是当应用程序兼容性工厂所作中。 您需要做的问题这取决于您是否会需要给定的应用程序供应商支持。 如果您很可能会要求供应商支持，做供应商研究是业务的需求。
很多的流程和使用的供应商的列表可以帮助确定是否永远支持应用程序在您正在迁移，以及是否该应用程序积极今天支持的平台上。 这可能是最重要的标志是否可能工作在这个平台上，因为供应商声称这与自己支持美元。
注意它实际上不会回答是否申请过受支持您的业务问题，你会愿意运行它。 请确保您收到你问的问题的答案。
数学来这里要确定供应商支持是否值得投资的时间来做这项研究。 另一种方法运行过程的评估自己的兼容性。 不过，很多人做数学不好，比较测试成本的研究一个应用程序中的一个应用程序的成本。 这种有缺陷的假设断言你就会发现语句的所有的东西，但它不是统计学上正确的做法。
下面是一个有效的公式：当测试一个应用程序的成本倍 %未找到或关键加研究一个应用程序的成本小于测试一个应用程序的成本时，您应研究供应商支持。
再说一遍，这让一些数字。 想象一下测试的进程，最终导致成本 $150 每个应用程序。 同样地，说是有一个平均 15 美元，每个应用程序的供应商研究过程。 公司可以找到支持声明的 12%的应用程序，和您打算的那些，反正测试 10%，因为他们是关键任务。
$150 x 89.2%+ 15 元呢？ 150
$148.80 < $150
是的它不会做有意义供应商的研究，但它不是你会想的灌篮。 毕竟，供应商研究似乎是应用程序测试成本的十分之一。 平均而言，你最终仅保存每个应用程序 1.20 美元。
当然，保存 （尤其是在规模) 什么是好的但它应该给你你很近的交叉点处的警告。 故障率并不需要移动太多，你会发现，你在负数。 事实上，这些假设，尽快为其找到支持的语句的应用程序的百分比下降到低于 10%，它开始变得更昂贵，在列表中查找的东西。 它似乎违反直觉的但以较低的单位成本选项实际上是更可取时少其故障率是太低。
转换难题
最新版本的 Office，大大提高了能力。 许多新的文档创建和编辑功能需要您使用最新的文件格式。 如果您想要利用这些新功能在特定的文档内，您应将这些文件转换并从那里去。
一个普通的问题是是否应该经过和更新的所有文档到新的文件格式。 过程似乎很容易，当然，还有的工具来帮助这个。 然而，并不是所有的文档将干净地升级。 升级的成本包括确保升级不会导致应用程序失败的风险管理。 某些功能可能会丢失 （例如，"版本"功能）、 某些图表看起来可能会不同和到使用旧的文件扩展名的文件的链接，最终可能会中断。
当然，这种成本也会带来好处。 通过忽略文件您可以手动更新为使用该产品的新功能，每个文件将受益于新的文件格式的减少的文件大小。 若要使这种决心，再一次不得不看数学来确定您是否有好的投资回报，从事此类活动。 你应该大容量-转换您所有的文档时的转换成本加测试的成本小于成本的驱动器空间。
开头的成本节约，并假设相同之前 （50000 个用户与 500 文档），作为数字添加平均文件大小为 1 MB。 这些参数与节省成本的潜力是成本的节省磁盘空间的 11TB。 要把这放在角度来看，让我们计算的磁盘空间的成本。 使用公式计算的马修 · 科莫罗斯基和张贴在他 "历史的存储成本，"我们发现成本等于 10 的权力的-0.2502 （减去 1980 年） 再加上 6.304。
这被计算基于磁盘介质单独购买价格。 这就意味着你可以买一个硬盘驱动器在 2012 年左右 0.02 美元每 gb 的存储数据，同时要校准这对总成本，使用 Windows Azure 的存储成本。 这些都是目前售价 128 元每 tb，或只是害羞的从这一公式计算成本的 6.3 倍。
所以要校准的结果，试图预测总存储成本，修改公式，如下所示：成本等于 6.3 倍 10-0.2502 （减去 1980 年） 再加上 6.304 的权力。
假设你保持 10 年的平均文档，此公式预测的总净储蓄将 $3,209.53。 即使你只是假设 Windows Azure 的存储成本将保持不变，你总储蓄仍将 $14,080。
因此，如果您测试您的文档可能转换成功，将其转换为它们总成本小于 $14,080 的保守 ($3,209.53 如果你假设存储成本将继续下降指数率相同），然后，转换有意义。
如果它的成本比这要测试和运行转换，然后它没有任何意义，要转换。 您应保留现有的格式为您的文档。 Office 2010 仍可以读取它们就好。 将它们转换手动当您需要使用新的功能。
合适的工具
最常见的模式解决在任何平台上的兼容性时正在寻找一种工具来查找 — — 并希望修复 — — 所有升级问题。 您可能会假定一个关联的兼容性问题的工具将实现这一目标的全部或部分，并运行它到处。 有些马路的时候，你会意识到其实还没有完全解决这一问题。
问题是约束之一。 一个兼容性 bug，毕竟是 bug 的只是 bug 的一个特例，碰巧清单本身在该特定的平台上。 这是查找并修复 bug 的所有已有的平台上没有什么不同。 因为您的所有作品全部的时间，只是软件的不要有一个服务台，除非我的猜测是软件的你有足够的与该平台的兼容性错误。 这是不是因为它不理解，但因为是棘手的问题。
你们中的大多数都有至少传递熟悉阿兰 · 图灵 1937年证明你不能建立一个程序来检测是否有应用程序将完成运行，或者继续永远运行。 此约束实现深远的限制，即使在今天的研究作为科学家们看，生成新的验证，以确保程序正确性的影响。 例如，
"背景下界分析是的并发程序的验证有吸引力的方法。 这种方法提倡分析的并行程序的上下文执行每个线程的数目为给定的恒定 K.界所有处决 定界框的上下文执行每个线程数量减少了渐近检查并发程序的复杂性：undecidable 的并发布尔程序"可访问性"分析时，根据上下文绑定同样的分析是 NP 完成 [18、 15]。 此外，有足够的实证证据，同步错误，例如数据争用与原子性侵犯，体现在并发处决，少量的上下文切换 [19、 16]。 这两个属性一起作背景下界的分析寻找并发错误的有效途径。 同时，上下文边界提供的有用权衡成本与核查的覆盖范围。
您需要定义正是它的意思是一个 bug。 大多数人都同意程序崩溃是一个 bug。 还有其他一些情况，其中确定程序行为是否一个 bug 取决于上下文。 例如，图形中的颜色可能产生负面改变意义。 它也可能可以接受或甚至有益。 版本检查 — — 这是从技术上讲是一种功能，因为它要求开发人员编写代码来介绍行为 — — 有时被认为是一个 bug 的版本限制遵守自然脱落的人。
知道你找不到所有的错误或甚至所有 bug 的某一类别，您需要确保您关注您的自动化领域自动化道理。 解决停机的问题，有可能，会给我们停止所有无限循环的能力 — — 一个常见的错误。 这将会有很巨大的回报。
当您考虑尝试查找并修复所有错误的概念时，并不是所有会有回报。 从理论上讲有无限的编程错误 （无论经验或上下文），写方式和有限数量的检测到它们所有的方法。 由于编程的事件数 bug 跌幅、 自动执行这些检查回报同样下降。 此驱动器我们选择以自动化。
数学是相对比较简单。 您应编写自动化的测试，以找到 bug 时的创建和运行自动化调试的成本小于成本乘以错误的发生率。
这在极常见的问题非常适合。 在 Windows 应用程序中，例如，用户帐户控制作标准用户帐户运行对于许多组织来说更现实。 它还暴露出很多软件的时间作为管理员运行时被认为更容易接受的重要法规遵从性问题。 这些问题是如此普遍和如此相似创建自动化检测所有人都有显著回报时相比，个别进行故障排除。
供应商创建给定平台验证工具可以摊还创造了很多顾客的自动化的成本。 他们投资制作新测试创建更轻松、 更便宜，这样他们就可以工作这种数学优势的运行更多的测试。 同时，可能是最简单的 （和最便宜的） 的测试要创建可能具有发病率很低。 我 (假阳性) 和第二类 (假阴性) 错误类型看着变得重要。
在新版本的 Office 中来验证技术打击的一些与早期版本的工具，我和第二类错误并受这两种类型的挑战。 此外还有关于在特定情况下的适用性的混乱。
办公室迁移规划管理器的工具集，例如，扫描，并确定任何潜在的挑战。 它还看将文档转换为新的文件格式 （这不会是一项挑战，如果您选择了只是离开原样的文档） 的挑战。 新的核查重点将部署阻滞剂的问题，例如使用过时的 Api 和 （通常由加载项引起） 的应用程序崩溃。
这项工作评估、 测试和转换真的是三步过程的最后一步：
- 所以你可以合理地认为，纾缓情绪的恐惧。
- 收集正确的数据。
- 分析这些数据，将其从数据转换为信息与知识。
而且这里是几个准则背后的数学基础：
- 你不必做某事，只是因为你可以。
- 就像你写的一份报纸，您应该运行您的应用程序兼容性工作：最重要的事物开始，和你的工作方式下。 不是每个人都完成后，并且您想要完成的最重要的东西。
- 不要混为一谈带有可选任务，强制性任务，即使他们似乎相关。
理想情况下，在探索如何更好地决定如何在 Office 兼容性项目中包含的背后的数学的冒险经历会激发你怀疑你的假设和提高效率。
.jpg)
Chris Jackson 是"应用程序兼容家伙"在微软。 他是一个主要的咨询顾问和企业应用程序兼容性的全球领先。 他是频繁的扬声器，它和开发人员会议，与客户和合作伙伴全球范围内的工作。 他的使命"还原技术的灵活性通过删除旧版软件的枷锁"。阅读更多从杰克逊在他的博客 (appcompatguy.com) 和在 Twitter 上 twitter.com/appcompatguy。