大型组织中的软件审批流程

Pau*_*ell 8 installation

许多大型组织的 IT 部门将桌面锁定为标准配置或 SOE。最终用户通常无权安装自己的软件,即使安装了,组织也往往只允许安装“经过批准的”软件。

即使对于免费/开源软件,最终用户通常也必须提交某种请求表才能对软件进行验证和批准。遵循该过程并安装软件后,升级可能会很麻烦 - 许多组织往往会坚持使用旧版本的软件(Windows XP、Office 2003 等),以免出现未知问题。

软件开发人员可以做些什么来加快审批流程?

如果您参与此类审批流程:

  1. 您在评估软件时会寻找什么?例如:
    • 您更喜欢 MSI 还是支持 xcopy 的软件?
    • 如果软件需要框架(Java、.NET),那么它或多或少可能会出现问题?
  2. 如果软件支持自动更新,您通常允许吗?
  3. 一般需要多长时间?
  4. 您更喜欢哪种许可模式(可转让、每个席位、每个 CPU、站点范围)?
  5. ISV 还能做些什么来提高他们的软件获得批准的机会?

GAT*_*awn 12

我是一家跨国公司 Software Approvals Group 的成员,我绝对赞同 Adam 上面所说的一切。

我还要提出以下几点,首先总是支付你所有的“发展税”. 这意味着确保您的应用程序在您可能永远不会使用的各种环境中正常运行,但很可能会成为大公司的交易破坏者,例如确保您的应用程序在漫游用户配置文件中运行良好以及重定向的用户文件夹(总是使用 Windows API 来查找用户和配置文件文件夹,永远不要假设它们位于标准位置,甚至在本地驱动器上),确保它在远程桌面服务器上运行良好(那里可能有一个在网络连接速度较慢或电池电量不足的笔记本电脑上同时运行 100 个应用程序副本,其中一些使用非常慢的连接)。例如,我们最近拒绝了一家非常大的公司(以“A”开头,以图形闻名)的多个软件的新版本,因为他们的应用程序突然不

即使对于免费/开源软件,最终用户通常也必须提交某种请求表才能对软件进行验证和批准。

从您评论的语气来看,您似乎认为审批流程与成本有关?从我们的角度来看,应用程序的单位成本根本不是我们在审批过程中考虑的事情。应用程序的财务理由将得到解决,软件批准都是从技术和支持能力的角度完成的。与专有商业应用程序相比,免费和开源软件通常在我们的流程中遇到更多麻烦。通常这只是由于缺乏问责制。当应用程序出现问题并且您需要支持时,您会去找谁,他们的 SLA 是什么?当您需要了解该应用程序是否适用于新版本的 OtherApp vX 时,您会问谁,他们是否真的为您提供了人们真正在努力的实际答案,或者这是一个模糊的“

遵循该过程并安装软件后,升级可能会很麻烦 - 许多组织往往会坚持使用旧版本的软件(Windows XP、Office 2003 等),以免出现未知问题。

软件升级必须经过与全新软件相同的过程。他们唯一的优势是我们已经知道了一些问题的答案,因为我们已经为软件提供了支持(这可能对软件不利,支持团队根据经验否决了升级公司)。

您更喜欢 MSI 还是支持 xcopy 的软件?

只要它们被正确打包,这两种部署方法中的任何一种都可以是好的。否则,我们很可能会删除您的安装程序并重新打包软件以供自己部署。

  • 无论您使用什么安装程序,您都必须确保尊重其所有静默、无人值守的安装模式。如果您的应用程序需要手动安装,这是一个即时交易破坏者,那么在 5 大洲的机器上根本没有可行的方法来从中央办公室获得所有非硬件支持。
  • 鉴于选择,我更喜欢做得好的 MSI 安装,而不是做得好的 xcopy 安装。大多数支持 Xcopy 的软件的问题在于它们在首次运行时尝试设置和注册自己。我很少找到可以正确执行此操作并且不会在漫游用户/热桌面环境中引起问题的应用程序。MSI 安装程序(如果您坚持使用标准 API)不会出错。
  • 确保您的静默安装能够进行手动安装中可以进行的所有配置更改。如果您正在使用 MSI 并坚持使用 API,那么这很好,我们可以进行 MST 转换并且没有问题。如果您使用不同的第三方安装程序,请确保它允许诸如“应答”文件或 INI 文件或类似文件。测试静默安装并确保所有选项都有效,我遇到过兴高采烈地宣布静默安装选项的产品,但他们从未真正测试过所有选项是否有效。
  • 最好在静默安装中给我们额外的选项,让我们设置许多用户通常会在“选项”面板中更改的设置。这可能是通过打开 setup.exe 的开关,可能是通过为设置记录 INI 文件,通过记录必要的注册表更改,或以上所有方式。不管怎样,我们希望确保我们的用户可以启动并运行该软件而无需自己进行任何配置,这里重要的是文件的默认位置、默认服务器名称、代理设置(如果您的应用程序运行通过网络)等。

如果软件需要框架(Java、.NET),那么它或多或少可能会出现问题?

肯定问题更大。大多数框架中的版本控制和向后/向前兼容性非常糟糕。特别是使用 Java,许多应用程序(和网站)需要安装特定的主要和次要 Java 版本,并且不能与其他任何东西一起使用。如果您需要将三个不同的应用程序放在一台机器上,它们都需要不同的 Java 版本,并且他们对将一个 Java 版本伪装成另一个版本的标准方法不满意,那么就会出现问题。.Net 在版本控制方面有其自身的问题,但很乐意让您同时安装该框架的所有主要版本,从而解决了很多问题。

如果软件支持自动更新,您通常允许吗?

绝不。有太多的版本控制和互操作性问题让应用程序在没有任何警告的情况下自我更新。应用升级需要测试和规划。此外,具有普通用户权限的用户无论如何都无法应用更新。如果您使用允许打补丁的部署方法(例如使用带有 MSP 补丁的 MSI),那么这可以使应用程序的安全补丁等事情变得不那么令人头疼,而且我们可以使用我们的部署工具(WSUS 和 SMS)自行管理自动更新)。此外,我们的安全团队非常怀疑任何“与基地对话”的应用程序,他们想确切地知道它正在发送什么信息,以及为什么需要通过互联网向未知服务器发送任何信息。

一般需要多长时间?

一些简单的应用程序,版本升级只要6个人在Outlook中点击一个“批准”投票按钮就可以决定。更复杂或有争议的可能每两周等待我们的小组会议。由于团队将有关应用程序的问题带走并进行研究/测试,因此可能会在不止一次会议上讨论某些应用程序。

您更喜欢哪种许可模式(可转让、每个席位、每个 CPU、站点范围)?

完全取决于应用程序的使用方式以及使用人数。最重要的是你的许可是明确定义的。我们必须让我们的员工参加(尽管是免费的)课程以了解 Microsoft 许可。我们不会为 ISV 费心这样做。

在许可方面,请考虑我们的静默自动安装需求。如果您的许可证需要激活,我们不希望每次在 PC 上重新安装应用程序时都必须给您打电话/发电子邮件。如果应用程序的每个副本都需要输入一个单独的、不同的许可证密钥,那么我们无法自动部署它,而如果我们可以购买可以保存在静默安装,那么我们很高兴。如果我们能在一年后与您联系并协商扩大我们的许可证数量,而无需更改输入到软件中的密钥,那就更好了。

ISV 还能做些什么来提高他们的软件获得批准的机会?

我们还将研究与您的应用程序目前的情况不严格相关的事情。请记住,如果您的应用程序成为我们某个领域的标准工作流程的一部分,它可能会使用 10 年或更长时间,那么您的产品路线图是什么样的?如果您还不支持最新的全新或开发中的 Windows 版本,您是否有计划何时支持?看起来你坚持这些路线图吗?看起来您是否计划对您的应用程序进行重大更改,无论是它的工作方式还是它使用的技术/框架?您的应用程序是否插入任何其他应用程序,例如 MS Office 或 IE,如果是这样,它对旧版本或新版本的容忍度如何?


小智 6

我们是一个相当小的组织,但转移到标准桌面和批准的软件以减少我们的管理麻烦。

您更喜欢 MSI 还是支持 xcopy 的软件?

任何可以执行“静默”安装的东西。MSI 在这里通常运行良好,但许多安装程序软件也很好。如果我们必须以某种方式配置它,那么也可以通过 xcopy-ing 文件或注册表合并来编写脚本。

如果软件需要框架(Java、.NET),那么它或多或少可能会出现问题?

由于版本要求不同,这可能会出现问题。如果您需要 .NET 3.5 而我们使用的是 3.0,那么我们必须管理该升级并确保它不会破坏其他任何东西。

如果软件支持自动更新,您通常允许吗?

不。新版本导致问题的风险太大。此外,用户没有管理员权限,因此更新通常不起作用。

一般需要多长时间?

如果有紧迫的业务需求,请尽快 - 只需几个小时。对于更笨拙的软件,可能需要一周或更长时间。

您更喜欢哪种许可模式(可转让、每个席位、每个 CPU、站点范围)?

越便宜越好!我们可以处理最合理的选项,但如果软件进行任何类型的自动检查或需要激活,就会变得困难。这些通常不能很好地处理死机、激活失败等问题,并且通常会为我们带来额外的工作。

ISV 还能做些什么来提高他们的软件获得批准的机会?

有两件事浮现在脑海:

  • 存储设置时,请考虑机器(程序文件或 HKLM)和用户配置文件(或 HKCU)之间的差异。如果你做得对,那么我就不必为此感到抱歉。
  • 在您的网站或软件文档中清楚地记录安装、设置和许可的详细信息。遵循“部署指南”比尝试自己解决要容易得多。

当然,您首先必须使软件值得使用——如果用户真的喜欢它,他们会大声喊叫以获得批准!