软件工程-风险管理

客户有不同的需要。一些人知道他们需要什么；而另一些人知道他们不需要什么。一些客户希望进行详细讨论，而另一些客户则满足于模糊的承诺。

客户有不同的个性。一些人喜欢享受客户的身份——紧张、谈判、一个好产品带来的心理满足；而另一些人则根本不喜欢作为客户。一些人会高兴地接受几乎任何交付的产品，并能充分利用一个不好的产品；而另一些人则会对质量差的产品猛烈抨击。一些人会对质量好的产品表示他们的赞赏；而另一些人则不管怎样都会抱怨不休。

客户和他们的供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商；而另一些人则可能素未谋面，仅仅通过信件往来和几个匆忙的电话与生产厂商沟通。

客户常常是矛盾的。他们希望昨天的一切工作都是免费的。生产厂商经常陷入客户自己的矛盾之中。

一个“不好的”客户可能会对一个软件项目组能否在预算内按时完成项目产生很大的影响。对于项目管理者而言，不好的客户是对项目计划的巨大威胁和实际的风险。下面的风险检查表中的条目标识了与客户特征相关的常见风险：

·你以前是否曾与这个客户合作过？

·该客户是否很清楚需要什么？他能否花时间把需求写出来？

·该客户是否同意花时间召开正式的需求收集会议（第11章），以确定项目范围？ ·该客户是否愿意建立与开发者之间的快速通信渠道？ ·该客户是否愿意参加复审工作？ ·该客户是否具有该产品领域的技术素养？

·该客户是否愿意让你的人来做他们的工作，即，当你的人在做具体的技术工作时，该客户是否会坚持在旁边监视？

·该客户是否了解软件过程？

如果对于这些问题中的任何一个的答案是否定的，则需要进行进一步的调研，以评估潜在的风险。

1.3.4 过程风险

如果软件过程（第2章）定义得不清楚；如果分析、设计、及测试以无序的方式进行；如果质量是每个人都认为很重要的概念，但没有人切实地采取行动来保证它，那么，这个项目就处于风险之中。以下问题摘自一次由R.S.Pressman ＆ Associates，Inc.［PRE95］建立的对软件工程实践活动进行评估的研讨会。这些问题已经在软件工程研究所（SEI）的过程评估调查表中进行了改编。

过程问题

·你的高级管理层是否支持一份已经写好的政策综述，该综述中强调了软件开发标准过程的重要性吗？

·你的组织是否已经建立了一份已经成文的、用于本项目的软件过程的说明？ ·开发人员是否“签约”同意按照文档所写的软件过程进行开发工作，并自愿使用它？

·该软件过程是否可以用于其他项目？

·你的组织是否已经为管理者及技术人员开设了一系列的软件工程培训课程？·是否为每一个软件开发者和管理者都提供了印好的软件工程标准？

·是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？ ·是否定期地对需求规约、设计和编码进行正式的技术复审？ ·是否定期地对测试过程和测试情况进行复审？

·是否对每一次正式技术复审的结果要建立了文档，其中包括发现的错误及使用的资源？

·是否有什么机制来保证软件工程标准确认的方案指导的工作开展正常？·是否使用配置管理来维护系统/软件需求、设计、编码及测试用例之间的一致性？

·是否使用一个机制来控制用户需求的变化及其对软件的影响？

·对于每一个承包出去的子合同，是否有一份文档化的工作说明、一份软件需求规约及一份软件开发计划？

·是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作？ 技术问题

·是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信？ ·是否使用特定的方法进行软件分析？

·是否使用特定的方法进行数据和体系结构的设计？ ·是否百分之90以上的代码都是采用高级语言编写的？ ·是否定义及使用特定的规则进行代码编写？ ·是否使用特定的方法进行测试用例设计？ ·是否使用软件工具来支持计划和跟踪活动？

·是否使用配置管理软件工具来控制和跟踪软件过程中的变化活动？ ·是否使用软件工具来支持软件分析和设计过程？ ·是否使用工具来创建软件原型？ ·是否使用软件工具来支持测试过程？ ·是否使用软件工具来支持文档的生成和管理？ ·是否收集所有软件项目的质量度量值？

·是否收集所有软件项目的生产率度量值？

如果对于上述问题中大多数的答案是否定的，则软件过程是薄弱的，且风险很高。 1.3.5 技术风险

突破技术的限制是极具挑战性且令人兴奋的，这是几乎每一个技术人员的梦想，因为这迫使开发人员使出他的或她的浑身解数，但这也是很有风险的。Murphy定律似乎对开发工作中的这一部分有了控制，使得我们难以预测风险，更不用说对它们进行计划了。下面的风险检查表中的条目标识了与建造的技术相关的常见风险：

·该技术对于你的组织而言是新的吗？

·客户的需求是否需要创建新的算法或输入、输出技术？ ·软件是否需要使用新的或未经证实的硬件接口？

·待开发软件是否需要与开发商提供的未经证实的软件产品接口？

·待开发软件是否需要与其功能及性能均未在本领域中得到证实的数据库系统接口？ ·产品的需求中是否要求采用特定的用户界面？

·产品的需求中是否要求开发某些程序构件，这些构件与你的组织以前所开发过的构件完全不同？

·需求中是否要求使用新的分析、设计、或测试方法？

·需求中是否要求使用非传统的软件开发方法，如形式化方法、基于AI的方法、以及人工神经网络？

·需求中是否有过份的对产品的性能约束？ ·客户能确定所要求的功能是“可行的”吗？

如果对于这些问题中的任何一个的回答是肯定的，则需要进行进一步的调研，来评估潜在的风险。

1.3.1 开发环境风险

如果一个木匠被要求用弯曲的、钝的手锯制作一件好家具，则最终产品的质量肯定是令人怀疑的。即使是熟练的开发者，不适当的或没有效率的工具也会阻碍工作的进行。软件工程环境支持项目组、过程及产品。但是，如果环境有缺陷，它就可能成为重要的风险源。下面的风险检查表中的条目标识了与开发环境相关的常见风险（第29章讨论了本检查表中所列的工具种类）：

·是否有可用的软件项目管理工具？ ·是否有可用的软件过程管理工具？ ·是否有可用的分析及设计工具？

·分析及设计工具是否支持适用于待建造产品的方法？ ·是否有可用的编译器或代码生成器，且适用于待建造产品？ ·是否有可用的测试工具，且适用于待建造产品？ ·是否有可用的软件配置管理工具？ ·环境是否利用了数据库或仓库？ ·是否所有软件工具都是彼此集成的？

·项目组的成员是否已经接受过关干每个工具的培训？ ·是否有相关的专家能够回答关于工具的问题？ ·工具的联机帮助及文档是否适当？

如果对于上述问题中大多数的回答是否定的，则软件开发环境是薄弱的，且风险很高。 1.3.7 与人员数目及经验相关的风险

Boehm［BOE89］建议了以下问题可用于评估与人员数目及经验相关的风险：