本文共 7693 字，大约阅读时间需要 25 分钟。

1 软件的质量

随着软件开发的规模越来越大，软件的质量问题越来越引起人们的关注。关于软件质量， IEEE729—1983 标准有以下定义：

1. 软件产品满足给定需求的特性及特征的总体的能力；
2. 软件拥有所期望的各种属性组合的程度；
3. 顾客或用户认为软件满足他们综合期望的程度；
4. 软件组合特性在使用中，满足用户预期需求的程度；

从上述这个定义可以看到质量不是绝对的，它总是与给定的需求有关。因此，对软件质量的评价总是在将产品的实际情况与从给定的需求中推导出来的软件质量的特征和质量标准进行比较后得出来的。

尽管如此，这里给出的软件质量还是一个模糊的概念且难以衡量。所以，软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。

项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程，即 “ 总体管理功能中决定质量方针 、 目标与责任的所有活动，并通过诸如质量规划 、 质量保证 、 质量控制 、 质量改进等手段在质量体系内加以实施 ”。

软件质量管理着重于确定软件产品的质量目标 、 制订达到这些目标的计划，并监控及调整软件计划 、 软件工作产品 、 活动及质量目标以满足顾客及最终用户对高质量产品的需要及期望。

软件质量管理包括三个部分：

1. 质量计划 —— 判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准；
2. 质量保证 —— 定期评估项目总体绩效，建立项目能达到相关质量标准的信心；
3. 质量控制 —— 监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。

1.1 软件质量计划

在正式进行软件开发前，需要制订一个软件质量计划，用于说明项目管理团队将如何实施其质量方针。用 ISO9000 的话来说，它应该说明项目质量体系，即： “ 用以实施质量管理的组织结构 、 责任 、 程序 、 过程和资源 ”。

目前国际上有许多质量标准，较常用的是 ANSI/IEEESTOL730—1984 ， 983—1986 标准。质量计划可以识别哪些质量标准适用于本项目，并确定如何满足这些标准的要求。在软件质量计划阶段应该完成如下活动：

1. 对项目的软件质量活动做出计划；
2. 对软件产品质量的可测量的目标及其优先级进行定义；
3. 确定软件产品质量目标的实现过程是可量化和可管理的；
4. 为管理软件产品的质量提供适当的资源和资金；
5. 对实施和支持软件质量管理的人员进行实施和支持过程中所要求的培训；
6. 对软件开发项目组和其他与软件项目有关的人员进行软件质量管理方面的培训；
7. 按照已文档化的规程制订和维护项目的软件质量计划；
8. 项目的软件质量管理活动要以项目的软件质量计划为基础；
9. 在整个软件生命周期，要确定、监控和更新软件产品的质量目标；

1.2 软件质量保证

质量保证指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。质量保证应贯穿于项目的始终，在事件驱动的基础上，对软件产品的质量进行测量 、 分析，并将分析结果与既定的质量标准相比较，以提供质量改进的依据。如果属于软件外包，还需要对软件产品的定量质量目标进行合理的分工，分派给项目交付软件产品的承包商。

1.3 软件质量控制

质量控制指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。软件质量的控制不单单是一个软件测试问题，评审 、 调试和测试是保证软件质量的重要手段。质量控制指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。质量控制应贯穿于项目的始终。项目结果既包括产品结果（例如可交付成果） 、 也包括项目管理结果（例如成本与进度绩效）。

质量控制通常由机构中的质量控制部或名称相似的部门实施，软件质量控制包括如下活动：

1. 对软件产品进行测试，并将测试结果用于软件质量管理活动的状态；
2. 高级管理者定期参与评审软件质量管理的活动；
3. 软件项目负责人定期参与评审软件质量管理的活动；
4. 软件质量保证评审小组负责评审软件的质量管理活动和工作产品，并填写相关报告；

（1）软件评审

软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开发的失败。

首先，要明确评审目标包括如下部分：

1. 发现任何形式表现的软件功能 、 逻辑或实现方面的错误；
2. 通过评审验证软件的需求；
3. 保证软件按预先定义的标准表示；
4. 已获得的软件是以统一的形式开发的；
5. 使项目更容易管理。

其次，评审过程应包括：召开评审会议。会议结束时必须做出以下决策之一：

① 接受该产品，不需作修改； ② 由于错误严重，拒绝接受； ③ 暂时接受该产品。评审报告与记录；

所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，

另外必须完成评审简要报告。还应该遵循基本的评审准则，如：

1. 对每个正式技术评审分配资源和时间进度表；
2. 评审产品，而不是评审设计者，不能使设计者有任何压力；
3. 会议不能脱离主题，应建立议事日程并维持它；
4. 评审会不是为了解决问题，而是为了发现问题，限制争论与反驳；
5. 对每个被评审的产品建立评审清单，以帮助评审人员思考；

（2）测试

软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统（或系统的构件）。

测试一般包括单元测试 、 模块测试 、 集成测试和系统测试。如果测试结果与预期结果不一致，则很可能是发现了系统中的错误，测试过程中将产生下述基本文档。

测试计划：确定测试范围 、 方法和需要的资源等。 测试过程：详细描述与每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）。 测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。

2 项目风险管理

无论是系统集成还是软件开发， IT 公司经常面临着各种项目的实施和管理，面临着如何确定项目的投资价值 、 评估利益大小 、 分析不确定因素 、 决定投资回收时间等众多问题。并且，一个 IT 项目，无论其规模大小，必然会为被实施方（用户）在管理 、 业务经营等多方面带来变革，这就使 IT 项目必然具有高风险性的特点。尤其是近年来， IT 项目的广泛实施，一方面为众多的企业带来了管理 、 经营方面的革新，而另一方面，夭折 、 中断 、 失败的项目也不在少数。因此，如何在项目实施中有效地管理风险 、 控制风险，已经成为了项目实施成功的必要条件。

实际上，项目风险的管理不仅贯穿于整个项目过程，而且在项目事件发生之前风险的分析就已经开始。

可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分：事前控制 —— 风险管理规划，事中控制 —— 风险管理方法，事后控制 —— 风险管理报告。

2.1 项目风险管理的概念

根据 PMBOK2000 版的定义，风险管理指对项目风险进行识别 、 分析 、 并采取应对措施的系统过程。它包括尽量扩大有利于项目目标事项发生的概率与后果，而尽量减小不利于项目目标事项发生的概率与后果。项目风险按是否有可确定性划分为：已知风险 、 可预知风险 、 不可预知风险。按风险管理的内容又可以划分为如下几种类型。

（1）内部技术风险：技术变化和创新是项目风险的重要来源之一

一般说来，项目中采用新技术或技术创新无疑是提高项目绩效的重要手段，但这样也会带来一些问题，许多新的技术未经证实或并未被充分掌握，则会影响项目的成功。还有，当人们出于竞争的需要，就会提高项目产品性能 、 质量方面的要求，而不切实际的要求也是项目风险的来源。

（2）内部非技术风险

公司的经营战略发生了变化相关的战略风险 、 涉及公司管理 / 项目管理人员管理水平等的管理风险，以及与范围变更有关的风险；没有按照要求的技术性能和质量水平完成任务的质量风险；没有在预算的时间范围内完成任务的进度风险；没有在预算的成本范围内完成任务的成本风险。

（3）外部法律风险

包括与项目相关的规章或标准的变化，如许可权 、 专利 、 合同失效 、 诉讼等。

（4）外部非法律风险

主要是指项目的政治 、 社会影响 、 经济环境的变化，组织中雇佣关系的变化，如公司并购 、 政府干预 、 货币变动 、 通货膨胀 、 税收 、 自然灾害等。这类风险对项目的影响和项目性质的关系较大。

2.2 风险管理的过程

风险管理包括对项目风险识别 、 分析和应对的过程，从而将正面事件影响扩大到最大化和将负面事件影响减少到最小化。项目风险管理的主要过程包括：

1. 风险管理规划，决定如何指导和规划项目的风险管理活动；
2. 项目风险识别，找到哪些风险可能影响项目，并记录其特征；
3. 定性风险分析，完成风险和环境的定性分析，并按其对项目目标的影响进行排序；
4. 定性风险 分析是决定具体风险的重要性并指导做出相关反应的一种方法；
5. 与风险相关的动作的时间相 关性可能使风险的重要性加大；
6. 定量风险分析，度量风险的可能性和后果，估量其对项目目标的潜在影响；
7. 风险应对计划，创建过程和技术来为项目目标增进机会和减小威胁；
8. 风险监督与控制，在项目生命周期中监视现存的风险、识别新的风险、执行缓解风险计划及评估其效果；

上述过程不仅彼此有交互作用，而且也同其他知识领域的过程有交互作用。一般来说，每个过程在项目中至少出现一次。

（1）风险识别

风险的识别就是识别整个项目过程中可能存在的风险事件。在项目开始 、 每个项目阶段中间 、 主要范围变更批准之前都要进行风险识别，实际上它在整个项目生命周期内都是一个连续的过程。要识别风险，首先应该了解在软件开发的各个阶段都有可能发生哪些风险（风险事件或风险来源）。下面列出软件开发各阶段可能发生的风险。

1. 初始阶段：项目目标不清；项目范围不明确；用户参与少或和用户沟通少；对业务了解不够；对需求了解；没有进行可行性研究。
2. 设计阶段：项目队伍缺乏经验，如缺乏有经验的系统分析员；没有变更控制计划，以至于变更没有依据，该变更的不变，不该变更的改变，这样得来的设计势必会失败或者偏离用户需求；仓促计划，可能带来进度方面的风险；漏项，由于设计人员的疏忽某个功能没有考虑进去。
3. 实施阶段：开发环境没有具备好；设计错误带来的实施困难；程序员开发能力差，或程序员对开发工具不熟；项目范围改变 ( 突然要增加或修改一些功能，需要重新考虑设计 ) ；项目进度改变 ( 要求提前完成任务等 ) ；人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大；开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差；没有有效的备份方案；没有切实可行的测试计划；测试人员经验不足。
4. 收尾阶段：质量差；客户不满意；设备没有按时到货；资金不能回收。

其中，初始阶段主要进行大部分需求分析 、 小部分设计（大部分业务建模和需求 、 少部分分析设计）；设计阶段主要进行大部分设计 、 小部分编码（大部分分析设计，部分实施及测试，开始考虑部署）；实施阶段进行大部分编码和测试，也涉及小部分设计（大部分实施及测试，部分部署）；收尾阶段完成安装及维护（大部分部署）。

除了考虑项目过程之外，软件企业在人力资源管理中也存在风险，如招聘失败 、 新政策引起员工不满 、 技术骨干突然离职等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。特别是高新技术企业，由于对人的依赖更大，所以更需要识别人力资源方面的风险。

以上只是列举了常见的风险事件，对不同项目可能发生的风险事件不同，应该对具体项目识别出真正有可能发生在该项目的风险事件。一般是根据项目的性质，从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集 、 整理项目可能的风险并充分征求各方意见就形成项目的风险列表，并对这些风险事件进行描述，如：可能性 、 可能后果范围 、 预计发生时间 、 发生频率等。风险识别的有效方法有很多，如：建立风险项目检查表 、 因果分析图、采访各种项目干系人等。

（2）风险分析

确定了项目的风险列表之后，接下来就可以进行风险分析了。风险分析的目的是确定每个风险对项目的影响大小，一般是对已经识别出来的项目风险进行量化估计，这里要注意三个概念。

1. 风险得失值：它是指一旦风险发生可能对项目造成的影响大小，说明可能造成的损失。如果损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险得失值可用相对数值表示，建议将损失大小折算成对计划影响的时间表示。
2. 风险概率：它是风险发生可能性的百分比表示，是一种主观判断。
3. 风险值：风险值又风险曝光度或风险暴露，它是评估风险的重要参数， “ 风险值 ” “ 风险概率 ” “ 风险影响 ” 。 如：某一风险概率是 25% ，一旦发生会导致项目计划延长4周，因而，风险值= 25% * 4周=1周。

风险分析就是对以上识别出来的风险事件做风险影响分析。通过对风险及风险的相互作用的估算来评价项目可能结果的范围，从成本 、 进度及性能三个方面对风险进行评价，确定哪些风险事件或来源可以避免，哪些可以忽略不考虑（包括可以承受），哪些要采取应对措施。

（3）风险应对方法

完成了风险分析后，就已经确定了项目中存在的风险及它们发生的可能性和对项目的风险冲击，并可排出风险的优先级。此后就可以根据风险性质和项目对风险的承受能力制订相应的防范计划，即风险应对。

制订风险应对策略主要考虑以下4个方面的因素：可规避性 、 可转移性 、 可缓解性 、 可接受性。风险的应对策略在某种程度上决定了采用什么样的项目开发方案。对于应 “ 规避 ” 或 “ 转嫁 ” 的风险在项目策略与计划时必须加以考虑。项目中的风险永远不能全部消除，

PMBOK2012 版提到4种应对方法：

1. 规避。规避风险指改变项目计划，以排除风险或条件，或者保护项目目标，使其不受影响。虽然项目永远不可能排除所有的风险事件，但某些具体风险则是可以规避的。出现于项目早期的某些风险事件可以通过澄清要求 、 取得信息 、 改善沟通，或获取技术专长而获得解决。通过分析找出发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。

例如，如何避免客户不满意？客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节就完全可以避免：业务建模阶段要让客户参与；需求阶段要多和客户沟通，了解客户真正的需求；目标系统的模型或 DEMO 系统要向客户演示，并得到反馈意见，如果反馈的意见和 DEMO 系统出入比较大时，一定要将修改后的 DEMO 系统再次向客户演示，直到双方都达成共识为止；要有双方认可的验收方案和验收标准；做好变更控制和配置管理等。

2. 转移。转移风险指设法将风险的后果连同应对的责任转移到第三方身上。转移风险实际只是把风险管理责任推给另一方，而并非将其排除。该方法基本上需要向承担风险者支付风险费用。它包括利用保险 、 履约保证书 、 担保书和保证书。可以利用合同将具体风险的责任转嫁给另一方。如果项目的设计是稳定的，可以用固定总价合同把风险转嫁给卖方。虽然成本报销合同把较多的风险留给了顾客或赞助人，但如果项目中途发生变化时，它有助于降低成本。

3. 减轻。通过降低风险事件发生的概率或得失量来减轻对项目的影响。提前采取行动以减小风险发生的概率或者减小其对项目所造成的影响，这样比在风险发生后亡羊补牢地进行补救要有效得多。减轻风险的成本应估算得当，要与风险发生的概率及其后果相称。项目预算中考虑应急储备金是另一种降低风险影响的方法。

例如，经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。

4. 接受。接受风险造成的后果。采取此项技术表明项目团队已经决定不为处置某项风险而改变项目计划，或者表明他们无法找到任何其他应对良策。主动地接受风险包括制定一套万一发生风险时所准备实施的应变计划。例如，为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。确定风险的应对策略后，就可编制风险应对计划，它主要包括：已识别的风险及其描述 、 风险发生的概率 、 风险应对的责任人 、 风险对应策略及行动计划 、 应急计划等。

（4）风险应对计划

针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。应对计划常应用于项目进行期间发生的已识别风险，事先制订应变计划可大大降低风险发生时采取行动的成本。风险触发因素，例如缺失的中间里程碑，应确定其定义，并进行跟踪。如果风险的影响甚大，或者所选用的对策不见得有效时，就应制订一套后备权变计划。该项计划可包括留出一笔应急款项 、 制定其他备用方案 、 或者改变项目范围。最常见的接受风险的应对措施是预留应急储备，或者简称储备，包括为已知风险留出时间 、 资金 、 或者资源。为所接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。

例如，在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程参照如下：

1. 进行调研，确定流动原因；
2. 在项目开始前，把缓解这些流动原因的工作列入风险管理计划；
3. 项目开始时，作好一旦人员离开时便可执行的计划，以确保人员离开后项目仍能继续进行；
4. 制定文档标准，并建立一种机制，保证文档及时产生；
5. 对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作；
6. 对每个关键性技术人员培养后备人员。

当然该应对计划需要花费一定的成本，在考虑风险成本之后，决定是否采用上述策略。

（5）风险监控

制定了风险应对计划后，风险并非不存在，在项目推进过程中还可能会增大或者衰退。因此，在项目执行过程中，需要时刻监督风险的发展与变化情况，并确定随着某些风险的消失而带来的新的风险。

风险监控包括两个层面的工作：

其一是跟踪已识别风险的发展变化情况，包括在整个项目周期内，风险产生的条件和导致的后果变化，衡量风险减缓计划需求。 其二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别 、 分析，并采取适当的应对措施。

对于已发生过和已解决的风险也应及时从风险监控列表调整出去。最有效的风险监控工具之一就是 “ 前 10 个风险列表 ” ，它是一种简便易行的风险监控活动，是按 “ 风险值 ” 大小将项目的前 10 个风险作为控制对象，密切监控项目的前 10 个风险。每次风险检查后，形成新的 “ 前 10 个风险列表 ” 。

---

转载地址：https://deniro.blog.csdn.net/article/details/108166187 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！