本文共 7693 字,大约阅读时间需要 25 分钟。
随着软件开发的规模越来越大,软件的质量问题越来越引起人们的关注。关于软件质量, IEEE729—1983 标准有以下定义:
从上述这个定义可以看到质量不是绝对的,它总是与给定的需求有关。因此,对软件质量的评价总是在将产品的实际情况与从给定的需求中推导出来的软件质量的特征和质量标准进行比较后得出来的。
尽管如此,这里给出的软件质量还是一个模糊的概念且难以衡量。所以,软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。
项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程,即 “ 总体管理功能中决定质量方针 、 目标与责任的所有活动,并通过诸如质量规划 、 质量保证 、 质量控制 、 质量改进等手段在质量体系内加以实施 ”。
软件质量管理着重于确定软件产品的质量目标 、 制订达到这些目标的计划,并监控及调整软件计划 、 软件工作产品 、 活动及质量目标以满足顾客及最终用户对高质量产品的需要及期望。
软件质量管理包括三个部分:
在正式进行软件开发前,需要制订一个软件质量计划,用于说明项目管理团队将如何实施其质量方针。用 ISO9000 的话来说,它应该说明项目质量体系,即: “ 用以实施质量管理的组织结构 、 责任 、 程序 、 过程和资源 ”。
目前国际上有许多质量标准,较常用的是 ANSI/IEEESTOL730—1984 , 983—1986 标准。质量计划可以识别哪些质量标准适用于本项目,并确定如何满足这些标准的要求。在软件质量计划阶段应该完成如下活动:
质量保证指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。质量保证应贯穿于项目的始终,在事件驱动的基础上,对软件产品的质量进行测量 、 分析,并将分析结果与既定的质量标准相比较,以提供质量改进的依据。如果属于软件外包,还需要对软件产品的定量质量目标进行合理的分工,分派给项目交付软件产品的承包商。
质量控制指监视项目的具体结果,确定其是否符合相关的质量标准,并判断如何杜绝造成不合格结果的根源。软件质量的控制不单单是一个软件测试问题,评审 、 调试和测试是保证软件质量的重要手段。质量控制指监视项目的具体结果,确定其是否符合相关的质量标准,并判断如何杜绝造成不合格结果的根源。质量控制应贯穿于项目的始终。项目结果既包括产品结果(例如可交付成果) 、 也包括项目管理结果(例如成本与进度绩效)。
质量控制通常由机构中的质量控制部或名称相似的部门实施,软件质量控制包括如下活动:
(1)软件评审
软件评审并不是在软件开发完毕后进行评审,而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误,如果这些错误不及时发现并纠正,会不断地扩大,最后可能导致开发的失败。
首先,要明确评审目标包括如下部分:
其次,评审过程应包括:召开评审会议。会议结束时必须做出以下决策之一:
① 接受该产品,不需作修改; ② 由于错误严重,拒绝接受; ③ 暂时接受该产品。评审报告与记录;所提出的问题都要进行记录,在评审会结束前产生一个评审问题表,
另外必须完成评审简要报告。还应该遵循基本的评审准则,如:
(2)测试
软件测试是软件开发的一个重要环节,同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统(或系统的构件)。
测试一般包括单元测试 、 模块测试 、 集成测试和系统测试。如果测试结果与预期结果不一致,则很可能是发现了系统中的错误,测试过程中将产生下述基本文档。
测试计划:确定测试范围 、 方法和需要的资源等。 测试过程:详细描述与每个测试方案有关的测试步骤和数据(包括测试数据及预期的结果)。 测试结果:把每次测试运行的结果归入文档,如果运行出错,则应产生问题报告,并且必须经过调试解决所发现的问题。无论是系统集成还是软件开发, IT 公司经常面临着各种项目的实施和管理,面临着如何确定项目的投资价值 、 评估利益大小 、 分析不确定因素 、 决定投资回收时间等众多问题。并且,一个 IT 项目,无论其规模大小,必然会为被实施方(用户)在管理 、 业务经营等多方面带来变革,这就使 IT 项目必然具有高风险性的特点。尤其是近年来, IT 项目的广泛实施,一方面为众多的企业带来了管理 、 经营方面的革新,而另一方面,夭折 、 中断 、 失败的项目也不在少数。因此,如何在项目实施中有效地管理风险 、 控制风险,已经成为了项目实施成功的必要条件。
实际上,项目风险的管理不仅贯穿于整个项目过程,而且在项目事件发生之前风险的分析就已经开始。
可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分:事前控制 —— 风险管理规划,事中控制 —— 风险管理方法,事后控制 —— 风险管理报告。
根据 PMBOK2000 版的定义,风险管理指对项目风险进行识别 、 分析 、 并采取应对措施的系统过程。它包括尽量扩大有利于项目目标事项发生的概率与后果,而尽量减小不利于项目目标事项发生的概率与后果。项目风险按是否有可确定性划分为:已知风险 、 可预知风险 、 不可预知风险。按风险管理的内容又可以划分为如下几种类型。
(1)内部技术风险:技术变化和创新是项目风险的重要来源之一
一般说来,项目中采用新技术或技术创新无疑是提高项目绩效的重要手段,但这样也会带来一些问题,许多新的技术未经证实或并未被充分掌握,则会影响项目的成功。还有,当人们出于竞争的需要,就会提高项目产品性能 、 质量方面的要求,而不切实际的要求也是项目风险的来源。
(2)内部非技术风险
公司的经营战略发生了变化相关的战略风险 、 涉及公司管理 / 项目管理人员管理水平等的管理风险,以及与范围变更有关的风险;没有按照要求的技术性能和质量水平完成任务的质量风险;没有在预算的时间范围内完成任务的进度风险;没有在预算的成本范围内完成任务的成本风险。
(3)外部法律风险
包括与项目相关的规章或标准的变化,如许可权 、 专利 、 合同失效 、 诉讼等。
(4)外部非法律风险
主要是指项目的政治 、 社会影响 、 经济环境的变化,组织中雇佣关系的变化,如公司并购 、 政府干预 、 货币变动 、 通货膨胀 、 税收 、 自然灾害等。这类风险对项目的影响和项目性质的关系较大。
风险管理包括对项目风险识别 、 分析和应对的过程,从而将正面事件影响扩大到最大化和将负面事件影响减少到最小化。项目风险管理的主要过程包括:
上述过程不仅彼此有交互作用,而且也同其他知识领域的过程有交互作用。一般来说,每个过程在项目中至少出现一次。
(1)风险识别
风险的识别就是识别整个项目过程中可能存在的风险事件。在项目开始 、 每个项目阶段中间 、 主要范围变更批准之前都要进行风险识别,实际上它在整个项目生命周期内都是一个连续的过程。要识别风险,首先应该了解在软件开发的各个阶段都有可能发生哪些风险(风险事件或风险来源)。下面列出软件开发各阶段可能发生的风险。
其中,初始阶段主要进行大部分需求分析 、 小部分设计(大部分业务建模和需求 、 少部分分析设计);设计阶段主要进行大部分设计 、 小部分编码(大部分分析设计,部分实施及测试,开始考虑部署);实施阶段进行大部分编码和测试,也涉及小部分设计(大部分实施及测试,部分部署);收尾阶段完成安装及维护(大部分部署)。
除了考虑项目过程之外,软件企业在人力资源管理中也存在风险,如招聘失败 、 新政策引起员工不满 、 技术骨干突然离职等,这些事件会影响公司的正常运转,甚至会对公司造成致命的打击。特别是高新技术企业,由于对人的依赖更大,所以更需要识别人力资源方面的风险。
以上只是列举了常见的风险事件,对不同项目可能发生的风险事件不同,应该对具体项目识别出真正有可能发生在该项目的风险事件。一般是根据项目的性质,从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集 、 整理项目可能的风险并充分征求各方意见就形成项目的风险列表,并对这些风险事件进行描述,如:可能性 、 可能后果范围 、 预计发生时间 、 发生频率等。风险识别的有效方法有很多,如:建立风险项目检查表 、 因果分析图、采访各种项目干系人等。
(2)风险分析
确定了项目的风险列表之后,接下来就可以进行风险分析了。风险分析的目的是确定每个风险对项目的影响大小,一般是对已经识别出来的项目风险进行量化估计,这里要注意三个概念。
风险分析就是对以上识别出来的风险事件做风险影响分析。通过对风险及风险的相互作用的估算来评价项目可能结果的范围,从成本 、 进度及性能三个方面对风险进行评价,确定哪些风险事件或来源可以避免,哪些可以忽略不考虑(包括可以承受),哪些要采取应对措施。
(3)风险应对方法
完成了风险分析后,就已经确定了项目中存在的风险及它们发生的可能性和对项目的风险冲击,并可排出风险的优先级。此后就可以根据风险性质和项目对风险的承受能力制订相应的防范计划,即风险应对。
制订风险应对策略主要考虑以下4个方面的因素:可规避性 、 可转移性 、 可缓解性 、 可接受性。风险的应对策略在某种程度上决定了采用什么样的项目开发方案。对于应 “ 规避 ” 或 “ 转嫁 ” 的风险在项目策略与计划时必须加以考虑。项目中的风险永远不能全部消除,
PMBOK2012 版提到4种应对方法:
例如,如何避免客户不满意?客户不满意有两种情况,一种情况是没有判断客户满意度的依据,即没有双方互相认可的客户验收标准,还有一种是开发方没有达到验收标准,即没有满足用户需求。不管是哪一种,开发方都有不可推卸的责任,只要做好以下环节就完全可以避免:业务建模阶段要让客户参与;需求阶段要多和客户沟通,了解客户真正的需求;目标系统的模型或 DEMO 系统要向客户演示,并得到反馈意见,如果反馈的意见和 DEMO 系统出入比较大时,一定要将修改后的 DEMO 系统再次向客户演示,直到双方都达成共识为止;要有双方认可的验收方案和验收标准;做好变更控制和配置管理等。
转移。转移风险指设法将风险的后果连同应对的责任转移到第三方身上。转移风险实际只是把风险管理责任推给另一方,而并非将其排除。该方法基本上需要向承担风险者支付风险费用。它包括利用保险 、 履约保证书 、 担保书和保证书。可以利用合同将具体风险的责任转嫁给另一方。如果项目的设计是稳定的,可以用固定总价合同把风险转嫁给卖方。虽然成本报销合同把较多的风险留给了顾客或赞助人,但如果项目中途发生变化时,它有助于降低成本。
减轻。通过降低风险事件发生的概率或得失量来减轻对项目的影响。提前采取行动以减小风险发生的概率或者减小其对项目所造成的影响,这样比在风险发生后亡羊补牢地进行补救要有效得多。减轻风险的成本应估算得当,要与风险发生的概率及其后果相称。项目预算中考虑应急储备金是另一种降低风险影响的方法。
例如,经过风险识别发现,项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。
(4)风险应对计划
针对需要采取应对措施的风险事件,开发应对计划,一旦发生风险事件,就实施应对计划。应对计划常应用于项目进行期间发生的已识别风险,事先制订应变计划可大大降低风险发生时采取行动的成本。风险触发因素,例如缺失的中间里程碑,应确定其定义,并进行跟踪。如果风险的影响甚大,或者所选用的对策不见得有效时,就应制订一套后备权变计划。该项计划可包括留出一笔应急款项 、 制定其他备用方案 、 或者改变项目范围。最常见的接受风险的应对措施是预留应急储备,或者简称储备,包括为已知风险留出时间 、 资金 、 或者资源。为所接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。
例如,在一个软件开发项目中,某开发人员有可能离职,离职后会对项目造成一定的影响,则应该对这个风险事件开发应对计划,过程参照如下:
当然该应对计划需要花费一定的成本,在考虑风险成本之后,决定是否采用上述策略。
(5)风险监控
制定了风险应对计划后,风险并非不存在,在项目推进过程中还可能会增大或者衰退。因此,在项目执行过程中,需要时刻监督风险的发展与变化情况,并确定随着某些风险的消失而带来的新的风险。
风险监控包括两个层面的工作:
其一是跟踪已识别风险的发展变化情况,包括在整个项目周期内,风险产生的条件和导致的后果变化,衡量风险减缓计划需求。 其二是根据风险的变化情况及时调整风险应对计划,并对已发生的风险及其产生的遗留风险和新增风险及时识别 、 分析,并采取适当的应对措施。对于已发生过和已解决的风险也应及时从风险监控列表调整出去。最有效的风险监控工具之一就是 “ 前 10 个风险列表 ” ,它是一种简便易行的风险监控活动,是按 “ 风险值 ” 大小将项目的前 10 个风险作为控制对象,密切监控项目的前 10 个风险。每次风险检查后,形成新的 “ 前 10 个风险列表 ” 。
转载地址:http://ofdcf.baihongyu.com/