会计软件缺陷

会计软件缺陷（共7篇）

会计软件缺陷 篇1

1 会计行为缺陷的涵义

1.1 “会计行为”的内涵

会计行为是会计行为主体 (会计行为个体和会计行为群体) 在会计目标的驱动下, 应用现代会计理论和方法作用于会计行为客体 (对象) , 生产、分配和利用会计信息及其他相关信息参与企业经营决策与管理, 对内在因素和外在环境影响作出反应的一种有目的、有意识的能动的会计实践活动。

1.2 软件公司A “会计行为”缺陷的表现

软件公司A在过去曾经有一段时间非常红火, 市场发展迅速, 销售情况良好, 但是该公司现在却业绩大幅下滑, 令人担忧。该公司本身不在北京, 但其光盘代理生产厂家却在北京, 该公司却将母盘留在北京, 更为让人不解的是, 该公司与光盘生产厂家没有一个严密协定, 没有任何书面上的合同, 没有一套严密的规章制度, 公司内任何一个业务员只要一个电话就可以让厂家生产光盘。

由于没有一套规范的票务管理制度, 不久该公司便相继出现许多严重的问题。症结何在?窥一斑而知全豹, 从下面两件事中可以看出当时该公司的问题之严重。

事件一:该公司会计接到光盘代理生产厂家电话:贵公司有人到我们公司压盘, 请你们将生产费用寄过来?会计说:没有啊, 我们没压过盘啊!光盘厂家说:怎么会没有啊, 谁谁谁什么时候就到这里来压过盘, 欠多少钱。会计自然觉得很奇怪, 但一查还真是这么一回事:公司某个业务员压了没给钱。

事件二:就是货款转账的问题, 照正常的操作程序, 公司都应要业务员将货款转到指定的账户上。据说当时一位老总说:还是将账回到公司的账上吧, 这样能好管理一些!但另外一个老总说:算了, 转来转去也是个麻烦, 反正也不会出什么大事儿。

后来该公司有一个业务员在公司完全不知情的情况下跳槽到另一家公司, 走的时候带走了公司存在他账上的一笔货款。当时一个老总对商家说:你们进我们的货怎么现在还不给我们回款呢?商家说:我们已经给了啊, 某月某日汇到某某业务员的账上了。

但是业务员已经离开了该公司, 根本无法追究。此事既对公司的利益造成了损失, 又败坏了企业员工的风气。一笔货款再怎么也是几十万上百万, 这对公司来说可能不算啥, 但对个人来说, 那就不是一个小数了, 诱惑极大。

最后使得搞开发的科研人员再也无心搞开发, 觉得还不如看书去找一个挣钱的捷径。业务员也会觉得这样辛苦地站柜台没什么意思, 何必这么老老实实的呢, 还不如也学某某, 发得多快, 别人现在也没有什么损失, 在另外一个公司做业务员做得好好的, 说不定在另外一个公司照样发。

1.3 软件公司A“会计行为”缺陷产生的原因

(1) 会计行为目标与会计目标相背离。

会计行为目标是会计行为主体对自己行为结果的一种主观愿望, 它受会计行为动机的直接影响, 是会计行为主体的一种自我激励和自我要求;会计目标是会计系统外部的其他契约人对会计信息系统期望和要求这种期望要遵循会计系统本身的性质特点, 但外部期望决定了它必须是“公允、普遍认可的”。在现实生活中, 会计行为主体由于利益的驱动, 会计行为目标常背离会计目标, 这就导致了会计不良行为的产生。

(2) 会计行为缺陷产生是现代企业制度双元控制的产物。

所有权与经营权相分离是现代企业制度的核心, 但由此又引发了所有者与经营者之间的权益冲突。企业所有者与经营者处于不同的控制地位, 控制目标也不同, 尤其是在信息需要方面存在“不对称性”和“外部性”。作为“内部人”的企业经营者处于主动地位, 受各种利益驱动, 容易采取不良的会计行为而企业的所有者作为“外部人”, 对企业的监督成本相对较高, 不能有效地制止会计行为缺陷。

(3) 缺乏有效地会计行为约束机制和激励机制。

会计行为结果实际上是为政府、市场和企业服务的。而在我国现阶段, 这三方面的服务对会计行为都缺乏有效的约束机制, 表现在:以相应法律法规体系为后盾的政府约束由于会计行为规范的不完整而显得薄弱……这些都导致会计行为约束机制缺乏。

2 治理会计行为缺陷的理论依据——强化内部会计控制

2.1 规范会计行为是内部会计控制产生与发展的根本原因

(1) 应提高对会计行为主体理性行为的认识。

(2) 重视会计行为主体理性行为, 更应重视企业经营者理性行为。

(3) 规范单位会计行为, 保证会计资料的真实、完整。

(4) 堵塞漏洞, 消除隐患, 防止并及时发现纠正错误及舞弊行为, 保证单位资产的安全完整。

(5) 确保国家有关法律和内部规章制度的贯彻执行。

2.2 完善内部会计控制是治理会计行为缺陷的有效措施

(1) 内部会计控制的目标与会计行为是一致的。

首先, 从宏观来看, 综观各国会计目标, 总体上都是为了如实客观地反映受托责任和提供决策有用的信息。内部控制通过规范会计行为, 使会计目标与会计行为目标趋于一致, 以保证会计目标的实现;其次, 从微观来看, 企业内部会计控制目标与会计目标一致, 会计控制是控制主体意志的表现, 控制者都希望成为控制主体以实现其控制目标。

(2) 有效的内部会计控制能降低交易成本。

科学的交易成本理论认为, 各种制度的存在交易费用的结果。当企业内部的运行费用低于市场交易费用时, 企业制度产生了。当企业内部运行成本高于市场运作成本时, 资源配置就在市场价格机制中进行, 这一理论指出, 降低交易费用是经营行为的原动力。

完善内部会计控制使企业内部行为优化, 引导企业以较低成本取得较好的行为结果, 有利于降低企业内部交易费用, 可以提高企业会计信息质量, 降低市场交易费用, 因此, 完善的内部会计控制仍利于提高整个社会资源配置效率。

(3) 内部控制制度完善了会计行为规范体系, 会计行为规范是约束和限制会计行为的标准和典范, 会计行为的过程实际上是一系列会计制度共同约束的结果, 但是我国会计行为规范和标准基本上偏向于外部控制。

宏观控制和技术规范, 主要针对会计行为为对象即经济业务事项进行规范。对如何促使会计行为主体按照既定制度运作未进行严格规范, 会计行为规范体系更完整, 不仅可以弥补会计信息生成过程中现有的不足, 而且还可以加强会计行为规范的实践指导作用。

3 治理该软件公司会计行为缺陷的内控措施

3.1 就A公司而言存在的问题

(1) 该公司不在北京, 光盘代理生产厂家却在北京, 在此情况下, 不应将母盘留在北京。如果要留在北京, 也应与厂家有一个严密协定, 不能没有相应合同和一套票务管理制度。

(2) 内部票务管理制度不健全, 任何人一个电话就可以在该代理厂家生产光盘。光盘出厂价与市场价格相差极大, 这中间有很大的利润空间, 我们不难想象, 一定有压了盘只给了压盘费, 凭发票入库而没到会计那儿去报账的业务员。如此一来, 公司前期的开发成本很高, 但公司的收入被业务员截流, 这于公司是很大的损失。

(3) 就是货款转账的问题, 没有正常的操作程序和票务管理, 公司不要求业务员将货款转到指定的账户上, 对业务员的货款没有监控。人脑的记忆是有限的, 东西一多, 时间一长, 任何人都有可能记不清甚至忘记, 这样就给投机的人提供了机会。

(4) 老总不懂票据管理的重要性。这主要体现在下面五个方面:

①该公司没有严格的票据管理。付款没有单据, 业务员付款给印盘厂没有票据, 提货付款, 也没有票据, 这样使得公司的营销情况连会计都不知道, 甚至连查都没地方查。

②对库管的认识不够。货款归库房的时候得签入库单, 得找库管签字, 库管得找库房主管签字, 然后得到会计那儿去挂账, 入库单和会计的单据联号。而该公司凭发票就可以入库, 这样既打乱了票据管理的规范, 也使得即有的票据成为一种没有实际用处的摆设。

③跟光盘厂没有书面合同, 与光盘代理生产厂家得有一套健全的票据管理制度, 而不能仅凭一个电话就生产光盘, 对于一个懂管理的老板这简直不可理喻。

④不懂发票的作用和意义, 凭发票入库或提货。我国现在的税收制度还不够健全, 很多公司和个人凭关系就能开出发票, 显然不能做为凭证。

⑤不懂内部会计控制的重要性, 用100元请了一个只会加减乘除的人来做会计。如果是一个懂票据管理的老板, 他一定不会出如此下策。

3.2 对于A公司来说, 解决的方法

(1) 不能将母盘留在北京。即使是为了生产方便必须将母盘留在北京, 也得与该公司与生产厂家有一个严密的协定, 制定一套约束彼此的规章制度, 有一套相应的票据管理章程。

(2) 货款转账按正常的操作程序, 公司应要求业务员将货款转到指定的账户上, 货款的进出都应以票据为证。业务员付款给印盘厂得有票据, 与商家发贷付款, 同时得有票据。货款归库房的时候应签入库单, 应找库管签字, 库管应找库房主管签字, 然后应到会计那儿去挂账, 由于单据是联号的这样, 付没付款都有依据, 同时便于会计盘存和查账。不能凭发票就提货, 而应有更规范的程序、更规范的票据管理。

(3) 跟光盘厂应有书面合同, 生产光盘应有票据为证, 不能仅凭一个电话就生产光盘。

(4) 就老板个人来说, 管理素质有待提高, 要更加严格的要求自身, 抽出时间学习财务管理、票务管理方面的知识, 建立董事制, 对总经理进行考察, 业务水平提高, 业绩进步则可继续担任此职, 如果做不到则另请高明。这样做有两个好处:①比如业务员印了100张盘, 报200张盘, 这就不可能入库, 因为库管在那儿管着。②即使销售跟库管通合谋, 那么还有会计, 因为单据联号的, 每个月都要盘存, 容易发现问题。

(5) 建立规范化的市场操作体系和信息流通体制, 一套业务员评价体系。任何一个业务其行为都作为存档资料, 即使你走出本公司, 那么另外一个公司也可能获知你的所做所为。

摘要：以某软件公司为例从分析会计行为缺陷产生的原因入手, 探讨治理会计行为缺陷的有效方法———完善企业内部控制。指出内部控制制度的实施是关键所在, 以求加大外部监督和再监督的力度, 以保证会计行为得以有效地治理。

关键词：内部会计控制,会计行为,缺陷,治理

参考文献

[1]潘秀丽.对内部控制若干问题的研究[J].会计研究, 2000, (1) .

[2]朱荣恩等.美国财务报告内部控制评价的发展及对我国的启示[J].会计研究, 2002, (3) .

[3]窦力鸣, 王锦萍.萨班斯-奥克斯利法案下公司内部控制的思考[J].保险研究, 2005, (3) .

软件缺陷度量与软件过程管理 篇2

软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。

软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。

2 问题描述

缺陷度量的技术的一个重要的指标和重要的作用就是对于软件系统中存在的问题的显示, 也就是对具体问题的描述。一般情况下, 软件的缺陷会分为大致的几种常见类型, 我们也可以根据这些类型, 做出不同的缺陷显示方法。正交分类方法ODC (Orthogonal Defects Classification) 作为一种常见的问题显示方法, 能够准确的显示问题, 一直被业内广泛的使用, 但是它也存在着技术上的缺陷, 就是解读方式比较复杂。另一种常见的方式是Thayer, 有点是比上一种方式的结果更精确, 但是解读起来也更加复杂。这两种方式的共同点在于都忽略了对于软件的过程的监控和分析, 这是一个非常严重的技术问题, 因为软件的研发过程才是质量问题的形成的重要阶段, 要控制质量问题, 就必须控制软件的研发过程, 所以, 我们想要找出新的监管和缺陷度量方法, 就要从控制过程的角度来分析。现在市场上的已经开发了几种缺陷管理系统工具, 例如Mercury公司的Quality Center, IBM公司的Rational系列管理工具, 微软公司的VSTS等。上述的几种技术都没有解决缺陷的分类问题, 导致了在软件过程的管理中的缺陷分类的薄弱。也直接导致了现有的缺陷管理工具在实用性和综合性方面的不完善, 上述的两种管理工具只是提供一些缺陷属性数量的简单统计结果, 要想得到一些更精确和更综合全面的分析结果, 用户不得不借助其他的统计方式。基于该目前市面上的工具的这样一种缺陷, 和软件过程管理的实际需要的不协调, 笔者制定了一种新的管理模型, 如图1。该模型可根据需要设计缺陷属性度量分类标准。在软件开发过程中通过缺陷管理系统采集缺陷数据, 运用缺陷分析方法实施缺陷分析, 把握缺陷发展趋势, 对软件项目开发过程进行综合评价。实施缺陷预防方案, 提高软件产品的开发质量。通过缺陷分析结果的反馈, 改进缺陷度量分类标准和分析目标, 提高缺陷分析结果的准确性。本文重点研究了缺陷分类方法和缺陷数据的分析方法, 并结合某项目中的缺陷数据实例进行了分析。

3 缺陷分类方法研究

3.1 缺陷分类的目的和原则

将软件的缺陷问题分类, 可以更好的管理和击破软件的缺陷问题。并且有益于分析缺陷产生的原因, 可以早到有计划的预防。缺陷分类方法应满足以下要求:准确地对发现的缺陷类型进行分类;缺陷分类类型之间应无重叠, 并尽可能多的覆盖开发过程中出现的分类;分类要与软件生命周期有机结合, 从软件过程的角度对软件缺陷进行分类。

3.2 缺陷度量属性分类

实施度量分析的最终目的是为了服务软件的研发和试验的各个阶段的顺利进行, 一旦发现问题可以及时纠正, 以免影响软件的研发和生产。在引言中曾提到, 软件缺陷的范围很广, 它贯穿于整个软件研发和生产试验的各个阶段, 是一种伴随着软件的整个过程的始终的应用, 所以它的重要程度也可想而知。一个缺陷需要记录许多相关的度量属性, 如何划分这些度量属性也是缺陷分类研究领域的一个热点。传统的分类方法主要目标是消除软件缺陷, 而不是对缺陷出现的原因进行一个正确的评估和解决方案的分析, 这样的分类方法是不利于软件的完善和发展的。所以, 一个全方位多角度的缺陷度量方式就应运而生。下面本文中将从缺陷度量属性设计的三个方面, 即描述属性、统计属性和控制属性来进行具体阐述。a.缺陷描述属性。缺陷描述属性是指:缺陷信息描述, 对于缺陷的各个方面和各个角度的描述, 既包括缺陷的时间, 产生原因也包括具体的解决方案的策划。b.缺陷统计属性。缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。c.缺陷控制属性缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。

4 缺陷度量过程管理

4.1 处理缺陷的角色

在软件开发过程中处理缺陷的四个负责人和所负责的任务的具体情况:报告人:将发现的缺陷登录到缺陷管理系统, 描述缺陷的表现形式和再现方法, 对缺陷进行简单分类, 由项目经理、组长对缺陷进行再分配, 缺陷修正完成后, 对其进行回归测试审核。负责人:负责缺陷的调查和修正工作, 分析缺陷引入的原因。组长:分配缺陷到负责人, 并对负责人已修正缺陷进行复查, 确保不会因为修正而引入新的缺陷产生, 分析缺陷流出原因。项目经理:分配缺陷到项目组, 定期总结缺陷分析报告, 把握缺陷发展趋势, 采取应对措施保证项目的进度及开发质量, 根据缺陷分析结果改进缺陷度量属性分类。

4.2 缺陷生命周期

缺陷生命周期是指缺陷从被报出之后, 到开始修正, 再测试直到该缺陷被完全消除的时间段。缺陷生命周期是影响软件研发的一个重要的指标和因素, 定期对缺陷各种状态信息的变化趋势进行总结, 是项目经理计划开发周期, 调整开发进度的重要依据。

4.3 缺陷分配管理流程

整个的缺陷的周期主要是指从发现到完全消灭的时间, 在这个时间内, 缺陷的分配管理流程主要包括:a.报告人登陆缺陷;b.管理人员分配缺陷给相关责任人;c.责任人调查并修正缺陷, 分析缺陷引入的原因;d.管理人员对修正结果进行复查, 分析缺陷流出的原因;e.报告人验证缺陷是否被正确。

结束语

软件的研发是一项非常复杂和严谨的工程, 所以在这个阶段要对软件的质量作出各个方面的监测和试验, 这样才能最大程度上减少软件的质量问题的发生概率, 而软件缺陷度量作为软件质量监测的一个重要方式, 应该引起我们有关的工程人员的足够重视, 不断在缺陷度量的技术上提升, 这样才更好的服务于我们的软件研发工作。

参考文献

[1]何荣勤.CRM原理.设计.实践[M].北京:电子工业出版社, 2006.

会计软件缺陷 篇3

在软件产品生产过程中出现软件缺陷是必然的, 如何采取合适的对策尽早发现和消除已经产生的缺陷, 提高软件产品的开发质量和成功率, 以及研究如何减少软件缺陷所产生的代价和成本是很有现实意义的。软件缺陷管理作为软件开发管理的重要组成部分, 已经被越来越多的软件开发人员所重视。

1 软件缺陷管理概述

缺陷管理/软件缺陷管理 (Defect Management) 是在软件生命周期中获取、管理、沟通任何变更请求的过程 (从变更的建议到变更的解决) 。可以确保你的问题如需求或者缺陷被跟踪管理而不丢失。软件缺陷管理通过适当的缺陷管理工具就可以成功对缺陷进行记录、跟踪和管理。

2 软件缺陷管理的目标

软件测试过程简单说就是围绕缺陷进行的, 对缺陷的跟踪管理一般而言需要达到以下的目标:

(1) 确保每个被发现的缺陷都能够被解决;

(2) 这里解决的意思不一定是被修正, 也可能是其他处理方式 (例如, 在下一个版本中修正或是不修正) , 总之, 对每个被发现的BUG的处理方式必须能够在开发组织中达到一致;

(3) 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段;决定测试过程是否结束有很多种方式, 通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式;

(4) 收集缺陷数据并在其上进行数据分析, 作为组织的过程财富。

3 软件缺陷管理的流程

不同的软件组织缺陷管理的流程会不尽相同, 根据对国内外著名软件公司缺陷管理流程的研究, 有如下两种常见的管理流程:

第一种缺陷管理流程包含七种缺陷状态:New、Open、Fixed、Reopen、Deferred、Cancel和Closed态, 其管理过程描述如下:

1) 测试小组向项目经理提交新发现的缺陷, 此时将缺陷状态设为“New” (新建) 。2) 项目经理根据Bug的详细情况, 确定处理方案, 进行以下操作:将事务状态设为“Open” (公开) , 并指派具体修复缺陷的人员;将事务状态设为“Cancel” (取消) , 并分配给测试小组;将事务状态设为“Deferred” (延后) , 并分配给测试小组。3) 被指派修复缺陷的人员接到“Open” (公开) 的事务后, 根据处理方案处理事务, 处理完毕后, 将状态设为“Fixed” (已解决) , 并提交给测试小组进行验证。一般情况下, 每个项目都有相对固定的测试人员, 如果不清楚应该提交给谁测试时, 可提交给测试组长, 由测试组长转给其他测试人员验证。4) 测试小组在验证时, 应按处理方案进行测试, 严格控制测试的质量。在测试时, 进行以下操作:如果验证通过, 将事务状态设为“Closed” (已关闭) , 结束事务;如果验证没有通过, 将事务状态设为“Reopen” (重打开) ;并提交给该缺陷的原负责修复人员重新处理。5) 缺陷修复人员接到“Reopen” (重打开) 的事务后, 需及时查明原因, 重新处理该事务。6) 测试小组接到项目经理提交的“Cancel” (取消) 的事务时, 应根据该事务的严重性及对相关系统的影响, 判断该事务是否可以取消, 进行以下操作:如果确定可以取消时, 将状态设为“Closed” (已关闭) , 结束事务;如果确定不可以取消时, 将状态设为“Reopen” (重打开) , 提交给项目经理进行重新缺陷的解决。7) 测试小组接到项目经理提交的“Deferred” (延后) 的事务时, 须在必要时设置缺陷的状态为“Open” (公开) , 并再次提交给项目经理进行处理。8) 如果“Closed” (已关闭) 的Bug再次出现时, 则作为一个新发现的缺陷提交。缺陷管理流程如图1所示:

第二种缺陷管理流程精简了缺陷管理的状态, 仅由Open、Fixed和Closed三种状态组成。

(1) 测试小组向项目经理提交新发现的缺陷, 此时缺陷的状态设为“Open” (公开) , 责任人指定为项目经理。

(2) 项目经理根据Bug的详细情况, 确定处理方案, 进行以下操作:确认测试小组提交的缺陷, 指派具体修复人员进行修复。驳回测试小组提交的缺陷, 将事务状态设为“Fixed” (已解决) , 并注明驳回的理由, 同时分配给测试小组;对延期修复的缺陷, 保持其状态为“Open” (公开) , 并注明延期的理由, 同时分配给测试小组。

(3) 被指派修复缺陷的人员接到“Open” (公开) 的事务后, 根据处理方案处理事务, 处理完毕后, 将状态设为“Fixed” (已解决) , 并提交给测试小组进行验证。

(4) 测试小组在验证时, 应按处理方案进行测试, 严格控制测试的质量。在验证时, 进行以下操作:如果测试通过, 将事务状态设为“Closed” (已关闭) , 结束事务。如果测试没有通过, 将事务状态重新设为“Open” (公开) , 并提交给该缺陷的原负责修复人员重新处理。

(5) 测试小组对于项目经理返回的带有驳回信息的“Fixed” (已解决) 的事务时, 应根据该事务的严重性及对相关系统的影响, 判断该事务是否可以取消, 进行以下操作:如果确定可以取消时, 将状态设为“Closed” (已关闭) , 结束事务。如果确定不可以取消时, 将状态重新设为“Open” (公开) , 并提交给项目经理进行重新缺陷的解决。

(6) 测试小组接到项目经理返回的带有延期信息的“Open” (公开) 的事务时, 须在必要时重新提交给项目经理进行缺陷的处理。

(7) 如果“Closed” (已关闭) 的Bug再次出现时, 则作为一个新发现的缺陷提交。其缺陷管理流程如图2所示:

4 基于缺陷度量属性的分类方法

缺陷分类的目的是通过实施软件缺陷管理, 采集完整的缺陷数据信息。通过缺陷数据分析软件缺陷产生的原因, 改进软件过程, 预防软件缺陷, 提高软件质量, 改善组织的软件能力成熟度。传统的软件缺陷分类方法主要目标是消除软件缺陷, 评价软件的性能和可靠性, 不能满足改进软件过程的需要。本文中将缺陷度量属性设计为描述属性、统计属性和控制属性三类。

4.1 基于缺陷描述属性的分类

缺陷描述属性是指:缺陷信息描述, 缺陷处理时间, 缺陷引入/流出原因分析, 缺陷处理结果描述, 缺陷调查分析相关的辅助文件路径等由处理分析缺陷的相关责任人进行记录的属性, 其属性值没有固定的取值范围。缺陷文字属性按照表1进行分类。

4.2 基于缺陷统计属性的分类

缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。缺陷统计属性按照表2进行分类。

4.3 基于缺陷控制属性的分类

缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。缺陷控制属性按表3进行分类。

5 软件缺陷管理典型工具介绍

缺陷管理作为软件质量管理的重要组成部分, 正在成为软件开发管理过程中的又一亮点。目前在国内软件组织中, 大家比较熟知的缺陷管理工具主要有Mercury Interactive公司的Test Director、IBM Rational公司的Clear Quest、上海微创公司的BMS系统以及开源软件Bugzilla。

5.1 TestDirector

Test Director是业界第一个基于Web的测试管理系统, 它可以为企业组织进行全球范围内测试的协调。通过在一个整体的应用系统中提供并且集成了测试需求管理、测试计划、测试日程控制, 以及测试执行和错误跟踪等功能, 极大地加速了测试过程。

5.2 ClearQuest

Clear Quest提供基于活动的变更和缺陷跟踪。以灵活的工作流管理所有类型的变更要求, 包括缺陷、改进、问题和文档变更。能够方便地定制缺陷和变更请求的字段、流程、用户界面、查询、图表和报告。开箱即用特性提供了预定义的配置和自动电子邮件通知和提交。与Rational Clear Case一起提供完整的SCM解决方案。拥有“设计一次, 到处部署”的能力, 从而可以自动改变任何客户端界面 (Windows、Linux、UNIX和Web) 。

5.3 BMS3.6.4 Bugzilla

Bugzilla是开源项目中有关软件缺陷管理的最为知名的软件之一, 其特点是基于Web方式, 安装简单、运行方便快捷、管理安全。提供全面详尽的报告输入项, 产生标准化的Bug报告。提供大量的分析选项和强大的查询匹配能力, 能根据各种条件组合进行Bug统计。系统灵活, 具有强大的配置能力。能够根据设定的不同责任人, 自动发送最新的动态信息, 有效的帮助测试人员和开发人员进行沟通。

6 测试管理数据分析

6.1 基于需求的测试覆盖

(1) 计划的测试覆盖程度:Coverage＿Plan= (TP/Rf T)

其中Coverage_Plan表示计划测试需求的覆盖率;TP表示测试计划确定的测试用例的数量, Rf T表示测试需求的总数。

(2) 已实施的测试覆盖度:Coverage＿Done= (TD/TP)

其中Coverage_Done表示已实施测试的覆盖率;TD表示到目前为止已完成的测试用例的数量, TP表示测试计划确定的测试用例的数量。

(3) 基于成功的测试覆盖程度成功的测试:Coverage＿Suc-cess= (TS/TP)

其中Coverage_Success表示已成功测试的覆盖率;TS表示到目前为止已成功完成测试的测试用例数量, TP表示测试计划确定的测试用例的数量是指测试过程中没有发现软件缺陷, 表示测试通过, 或者即使测试员发现了软件缺陷, 但是程序员进行了修改并重新测试通过。

6.2 从测试成本角度分析

不同缺陷需要的测试工时是不尽相同的。设计与代码审查过程是有效的发现与排除缺陷过程。设审查组的第i次审查为准备设计与代码检查, 所用的工时数为Ti1, 实际审查所用的工时数为Ti2, Si代表第i次审查中查出的主要 (非轻微) 缺陷数。I为迄今为止的总审查次数。则某阶段审查出每个缺陷的工时数M为:

对新开发程序而言, M一般有一个稳定范围, 例如3-5。如果M显著低于这个规范, 说明缺陷密度可能太高———因为准备工作不充分或实际测试过程不充分, 产品开发可能存在问题, 应对开发过程仔细审查;如果显著高于这个范围, 说明审查过程可能有缺点。M的不断度量使质量可靠性部门及时对开发及审查过程的质量进行一定的监控。

6.3 开发人员熟练程度度量分析

首先计算开发人员的缺陷率DBR (neveloperBugRatio)

DBR=该阶段缺陷总数/某人该阶段开发代码行数L, 这里用某一时期某一开发人员缺陷总个数与该阶段代码行数的比值来表示该开发人员的缺陷率。这只是一个粗略的计算, 不能充分反映开发人员的熟练程度, 为了充分反映开发人员的熟练程度, 我们对不同开发人员的缺陷级别 (Bug level) 进行评估:

定义1:缺陷类型权值向量W, 其中各元素WX代表缺陷类型X对应的权值:

在向量W中, 作为最后一个缺陷类型E, 虽然它不是产生于程序员本身, 而是由于系统在前期设计的不足或者存在错误导致, 但这些缺陷如果在程序开发的后期才被发现, 那么修改的成本将会很高, 因此将它的权值设为最高。

定义2:缺陷数量向量N, 代表某一编码人员被检查出的所有类型缺陷数量, 按照缺陷类型依次排列, 其中每个元素的值NX对应发现该类型X缺陷的个数, 值为0表示未发现该类型的缺陷。N= (na1, na2…, na9, na10…, nb1, nc1…, nc5, nd1…nd6, ne1, ne2)

定义3:缺陷数量加权值, 代表某一编码人员被检查出的所有类型缺陷数量的加权值。

PersonA_BL=[N, w], 向量N与W的内积表示该测试人员测试出的不同类型缺陷数 (N中元素值) 与对应权值 (W中元素值) 的乘积之和, 这是从质量的角度去衡量该人员的编码质量, 可以作为该开发人员熟练程度的标志。

6.4 测试人员的熟练程度度量分析

我们以测试人员的测试效率TE作为测试人员的熟练程度的标志。例如, 某一测试人员被检查出的缺陷数量向量是:N= (5, 3, 二, 3, 6, …, 3, 6, …, 4, 2, …, 3, 1, 0)

PersonBJE=[N, w]/T=246.5/2=73.4, 向量N与W的内积表示该测试人员测试出的不同缺陷类型数 (N中元素值) 与对应权值 (W中元素值) 的乘积之和, 再除以本次测试的周期, 作为测试人员的熟练程度。这里抛开单纯从缺陷个数的角度去衡量测试人员熟练程度的不足, 而从测试效率的角度来进行分析。影响测试人员熟练程度的因素有两个:a.测试出不同类型缺陷中权值大的缺陷数所占比重;b.本次测试所经历周期的长短, 最终的结果与a呈正比, 与b呈反比。显然如果测试出的缺陷中权值大的部分占的比重大, 同时经历的周期比原来的短, 则最终PersonB_E的值会增大, 反之将会减小。从而可以准确的反映该测试人员的熟练程度 (值越大, 该测试人员的熟练程度越高) 。

6.5 缺陷密度度量分析

软件缺陷密度是指单位代码量所引入的软件缺陷个数。代码量通常以千行为单位, 软件缺陷密度的计算公式如下:

其中, Defect_Density是缺陷密度, D是软件缺陷总数, T是指被测试软件的代码行或功能点数量。

6.6 缺陷分布分析

(1) 可以通过饼图的方式对软件缺陷的严重性进行总结, 让我们一目了然的知道软件缺陷当前的严重程度, 修复的优先级。

(2) 我们可以统计软件缺陷主要发生在哪些功能区, 从而为软件缺陷的改进指明方向。

6.7对软件缺陷的趋势进行统计

(1) 对每天发现的软件缺陷数量进行统计, 形成软件缺陷趋势图, 从而评估当前软件是否可以发布。

(2) 对软件缺陷的累计趋势进行统计, 我们不仅需要对每天打开的软件缺陷进行统计, 还需要对累计的软件缺陷进行统计。

(3) 统计软件缺陷修复情况, 将软件缺陷三种状态:打开, 解决和关闭进行比较, 从而指导当前软件测试和开发的工作。

7 结束语

目前对于缺陷管理的研究, 是一个很具有发展前途的研究课题。本文首先通过对已有缺陷属性分类方法, 缺陷分析, 缺陷管理流程的分析与总结, 设计研究一种易于实施的缺陷管理方案, 提出了基于软件度量的缺陷管理方法, 使缺陷管理从传统的模式中解脱出来, 通过对整个缺陷管理过程的度量来量化项目开发阶段的管理。从而达到了更好的监控项目进展的作用, 以及对项目相关问题的分析。

摘要：介绍了软件缺陷的分类与特性, 进一步研究基于缺陷特性的缺陷管理流程, 以及分析几种常用管理工具, 并且详细阐述了量化分析软件缺陷管理数据的方法。

关键词：软件缺陷分类,软件缺陷管理流程,软件缺陷量化分析,数据分析,缺陷管理工具

参考文献

[1]陈文海.软件测试管理工具的研究与实现[D].北京:中国科学院软件研究所, 2003.

[2]Rex Black.测试流程管理[M].北京:北京大学出版社.2001.

[3]啄木鸟部落.测试工具的选择和使用[J].程序员, 2003, (9) .

[4]李轩.基于struts的缺陷度量和管理系统的研究与实现[D].西北大学硕士论文, 2007.

[5]赖涵.软件缺陷管理的研究与辅助工具实现[D].吉林大学硕士论文, 2004.

软件缺陷管理方案分析 篇4

软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误, 或者隐藏的功能缺陷。软件缺陷管理是在软件生命周期中获取、管理、沟通任何变更请求的过程, 可以确保问题或缺陷被跟踪管理而不丢失。目前缺陷管理类的软件工具比较多, 主要功能比较一致, 但在一些细节, 如缺陷管理的流程, 与其它软件工程管理软件的集成, 甚至涉及到软件测试流程和软件质量管理的理念上, 都存在差异[1]。本文结合作者的软件开发和测试工作经历, 给出一套软件缺陷管理方案。

2. 软件缺陷的产生

软件测试从需求分析阶段就与软件开发同步进行, 软件缺陷在软件测试的各个阶段都会产生。图1是软件缺陷的产生示意图。

测试人员和开发人员首先根据测试需求创建各个测试用例, 测试需求与测试用例是一对多的关系;各个测试用例在运行后会产生相应的测试结果, 在一次测试过程中, 一个测试用例只会有一个测试结果, 但从整个软件测试流程中, 一个测试用例会产生多个测试结果, 比如在针对不同版本进行的回归测试, 从测试用例到测试结果一般测试人员和开发人员都会参与;最后, 如果测试结果完全满足对应的测试需求的要求, 即测试成功, 可以认为该测试用例测试通过, 若不满足, 即测试失败, 根据测试结果创建相应的缺陷, 测试结果与软件缺陷是一对多的关系[2]。

3. 软件缺陷管理方案

3.1 管理内容

从管理功能的角度, 软件缺陷管理会记录缺陷时间、严重度、异常的程序表现以及如何重现软件缺陷的细节;另外还有报告程序缺陷的人员身份和可能修正此缺陷的程序员信息。为了追踪与软件缺陷相关的测试用例和测试结果, 应该对测试用例和测试结果进行分类管理, 同时关联好测试用例、测试结果和软件缺陷三者的关系[3,4]。

从管理权限的角度, 软件缺陷管理过程中, 除了需要分配相关的人员对测试用例、测试结果和软件缺陷进行维护外, 还需要不断跟踪软件缺陷及与之相关的测试用例、测试结果在其生命周期中被分配的状态指数。在跟踪过程中应当允许管理员设定基于状态的权限, 可以结合软件缺陷的管理流程, 通过权限管理来维护在测试用例、测试结果和软件缺陷生命周期中的状态, 包括缺陷的确认、缺陷任务的分配等等。同时对各类状态进行定义和维护[3,4]。

下面首先分析软件缺陷的具体内容及生命周期中的状态关系, 然后定义相关的权限和角色, 并赋予角色对应的权限。

3.2 软件缺陷管理

一条测试用例的多次执行会产生多个测试结果, 当测试结果与预期结果不一致时, 可以通过该测试结果产生一个或多个软件缺陷, 当发现软件缺陷后, 需要设法找到引起这个缺陷的原因, 对软件缺陷进行分类, 分析对产品质量的影响, 然后确定软件缺陷的严重性和处理这个缺陷的优先级。一个完整的软件缺陷包括如下表所示的字段信息:

软件缺陷在其生命周期中的状态关系图如图2所示:

如图所示, 软件缺陷共有四个状态, 缺陷创建时为Active状态, 表明该缺陷激活, 需经过管理员的确认, 管理员确认通过后, 此时将该缺陷设置为Reviewed状态, 表明缺陷得到确认, 再将该缺陷分配给软件修复者 (通常为开发人员) 进行处理;软件修复者得到任务后对缺陷进行修复, 修复完成后, 将该缺陷设置为Resolved, 表明该缺陷已得到解决;当修复者处理好缺陷后, 创建者需要判断该缺陷是否得到了处理, 如果并未得到处理, 则将缺陷重新设置为Active状态, 表明该缺陷没有能正常解决, 然后交给管理员再进行确认;若创建者判断修复者已经完成了对缺陷的处理, 则由管理员进行确认, 确认通过后缺陷状态仍然为Resolved;当管理员认为该缺陷已经解决, 同时在后续开发过程中也无须跟踪该缺陷, 则可以将缺陷状态设置为Closed, 表明该缺陷为关闭状态, 后续测试和开发无须考虑该缺陷;对新创建和重新激活的缺陷, 管理员在进行确认过程中, 如果认为创建的缺陷无须修复, 直接可以设置为关闭状态, 或者对于创建者重新激活的缺陷, 管理员若认定该缺陷已经解决, 管理员可以将缺陷再次设置为Resolved状态;同样对于已经为Closed状态的缺陷, 在后续测试过程中重现, 可以重新激活, 设置为Active状态[3,5]。

设置为Resolved状态的软件缺陷, 并不表明该软件缺陷得到了修复, 仅仅表示该软件缺陷得到了处理, 有的情况下有些软件缺陷是不需要修复的, 比如无法复现的问题, 或者暂时不能解决的软件缺陷, 也有的情况下软件缺陷发现得比较晚, 当前的处理结果是在下一个版本进行修复;这里将Resolved状态的缺陷分为两大类:无效缺陷和有效缺陷, 该两大类将已解决的缺陷再分成如下的解决分类[5], 如表2所示:

3.3 软件缺陷权限管理

由前面分析可以看到, 在软件缺陷管理过程中, 所涉及到的角色较多, 因此必须要设置相应的角色和对应的权限。首先将权限分为软件产品管理、用户管理、测试用例管理、测试结果管理和软件缺陷管理五个方面, 将角色分为系统管理员、项目管理员、测试管理员、测试审核员、测试人员和开发人员六个方面, 各角色的具体权限分配如表3和表4所示:

4. 结语

本文给出了一套软件缺陷管理方案, 该方案从生命周期和管理内容两个方面详细分析了软件缺陷的管理方法, 并给出了软件缺陷权利管理中权限和角色分配方法。该方案更多的是结合本人在软件开发和测试工作中的经验总结而成, 在软件缺陷的状态关系中, 强调了审核和确认的机制, 管理方案略显繁琐, 在软件开发和测试的实际运行中比该方案相对简单;另外方案在团队工作和项目管理方面, 尤其是质量控制和质量保证方面, 考虑得不够全面, 在今后的工作过程应重点融入这部分内容。

摘要：基于作者软件开发和软件测试的工作经历, 给出了一套软件缺陷管理方案, 该方案对软件缺陷的管理内容和生命周期进行重点分析, 定义了软件缺陷在其生命周期中的各个状态, 以及状态之间的转换过程, 然后在软件缺陷权利管理中给出了权限和角色分配方法, 最后对方案提出了一些不足和改进。

关键词：软件缺陷管理,测试用例,测试结果,生命周期,权限管理

参考文献

[1]百度百科.缺陷跟踪管理系统[EB/OL].http://baike.baidu.com/view/107502.htm, 2013.

[2]张创基.软件缺陷管理系统的分析与设计[J].教育教学论坛, 2012.8.

[3]林璐.对软件测试中的缺陷管理的研究和实践[D].上海:复旦大学, 2011.

[4]闫振兴, 郑骏.软件缺陷度量与软件过程管理方法研究[J].计算机与数字工程, 2010.8.

会计软件缺陷 篇5

众所周知,软件故障对软件可靠性具有重要影响。软件错误是一种人为错误,一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时,便产生一个软件故障。软件故障如果没有得到有效、及时的处理,便不可避免地导致软件失效。因此,分析不同软件故障对软件可靠性的影响,是软件可靠性研究的重要内容之一。

由于软件错误和缺陷是软件失效的源头,人们对此进行了大量的研究工作,提出了多种软件缺陷分类法。由于观察问题的角度不同,其分类也各有不同,下面是几种有代表性的软件缺陷分类[1,2]:

(1) Putnam等人从软件生存周期的角度提出的分类方法,将软件缺陷分为六类:需求缺陷、设计缺陷、文档缺陷、算法缺陷、界面缺陷和性能缺陷。

(2) Thayer软件错误分类方法[3]按错误性质分类,它利用测试人员在软件测试过程填写的问题报告和用户使用软件过程反馈的问题报告作为错误分类的信息,包括16大类,164个子类。这16个大类分别是计算错误、逻辑错误、I/O错误、数据加工错误、操作系统和支持软件错误、配置错误、接口错误、用户需求改变(指用户在使用软件后提出软件无法满足的新要求产生的错误)、预置数据库错误、全局变量错误、重复的错误、文档错误、需求实现错误(指软件偏离了需求说明产生的错误)、不明性质错误、人员操作错误、问题(指软件问题报告中提出的需要答复的问题)。该分类方法特别适用于指导开发人员的缺陷消除和软件改进工作。通过对错误进行分类统计,可以了解错误分布状况,对错误集中的位置重点加以改进。该方法分类详细,适用面广,当然分类也较为复杂。该分类方法没有考虑造成缺陷的过程原因,不适用于软件过程改进活动。

(3) 电气和电子工程师学会制定的软件异常分类标准(IEEE Standard Classification for Anomalies 1044-1993)对软件异常进行了全面的分类,该标准描述了软件生命周期各个阶段发现的软件异常的处理过程。分类过程由识别、调查、行动计划和实施处理四个步骤组成,每一步骤包括三项活动:记录、分类和确定影响。异常的描述数据称为支持数据项,分类编码由两个字母和三个数字组成,如果需要进一步的分类可以添加小数。其中调查步骤将异常类型分为逻辑问题、计算问题、接口/时序问题、数据处理问题、数据问题、文档问题、文档质量问题和强化问题,共八个大类,每一个大类又分为数量不等的小类。分类细致深入,准确说明了异常的类型。

(4) 正交缺陷分类ODC[4](Orthogonal Defects Classification)是IBM公司提出的缺陷分类方法。缺陷类型被分为七大类:赋值、检查、算法、时序、接口、功能、关联。该分类方法提供一个从缺陷中提取关键信息的测量范例,用于评价软件开发过程,提出正确的过程改进方案。该分类方法分类细致,适用于缺陷的定位、排除、原因分析和预防活动。缺陷特征提供的丰富信息为缺陷的消除、预防和软件过程的改进创造了条件。它的缺点在于分类复杂,难以把握分类标准,缺陷分析人员的主观意见会影响属性的确定。

(5) 马里兰大学/NASA软件工程实验室缺陷分类法。它从缺陷的最初来源,缺陷修复时间,缺陷发现方法,缺陷发现的模块这四个因素入手开展缺陷分析。该分类法仅从缺陷产生的原因分析,没有从缺陷发生的角度分析,仅是ODC方法实现的一部分。

(6) 优利系统公司错误分类方案。1984年优利系统公司实行的错误分类方案通过填写软件变更报告,搜集软件变更原因、问题适合的发现和隔离方式、软件开发人员最初编写的代码是否正在被修补、隔离和修改花费的时间、修改的模块等客观问题,以及问题原因判断、理由两个主观问题的答案。这些问题的回答帮助将缺陷从“错误主要分类”、“错误类型”、“限定”、“用途”四个方面分类。该分类从软件开发过程中多个角度实现了有价值的分析,但分类不够清晰。

(7) IBM的缺陷预防方案。1990年IBM研究中心的R.G.Mays等人提出的缺陷预防方案是采用因果分析方法对缺陷进行分析,包括三个步骤:1)将缺陷归类于疏忽、教育、交流不当、文字错误等问题;2)分析缺陷起因及引入的时间,并讨论如何防止类似缺陷再次出现;3)查找剩余残留缺陷,并消除所有存在的缺陷并改进开发过程。该方法和根源分析法类似,人为执行因果分析时容易受到过多主观因素的影响,分析结果不客观。

以上是当前有代表性的几种软件缺陷分类方式,但这些分类法都是宏观地考虑整个软件开发过程,并没有从代码的角度对软件缺陷进行分类。

1 面向程序代码的缺陷分类

使用程序变异方法注入故障,首先必须从程序代码的角度对软件缺陷进行分类。在分析、研究了已有的各种分类方法的基础上,针对C++语言,我们提出了面向程序代码的软件缺陷分类法。该方法将软件缺陷分为以下五类:

(1) 赋值缺陷 主要指由变量未赋值和赋值不正确引起的故障。这类软件故障主要包括:变量未初始化就使用错误;数组变量的越界错误;数组元素使用错误;指针变量使用错误;指针越界;数据类型不匹配的错误;算术表达式优先级错误;非法算术运算错误(除数0,负数开方);整数和浮点数的上溢下溢错误;非法类型转换错误;引用赋值与内容赋值使用错误等。这类故障常发生于函数的开头部分。

(2) 分支缺陷 主要发生在分支的判断体及分支结构部分。这类软件缺陷主要包括:等于运算符使用错误;边界值被忽略;逻辑运算符与位运算符的误用;逻辑运算符使用错误;if-else匹配错误;缺少默认情况;逻辑表达式优先级错误;引用比较与内容比较使用错误等。

(3) 循环缺陷 主要发生在循环条件及循环结构部分。这类软件缺陷主要包括:边界值错误;等于运算符使用错误;循环变量使用错误;多循环嵌套时,因大括号位置错误引起的循环体不完整;break语句与continue语句使用错误;永不循环错误等。

(4) 接口缺陷 主要指用户、构件、函数之间的信息交换错误。这里所说的接口表现为函数调用、参数传递、函数返回值及共享的全局变量。这类软件缺陷主要包括:函数调用参数传递错误;多出口函数中某个return语句的丢失错误;return语句返回值错误;函数调用错误;函数调用丢失;响应延迟;响应丢失类故障;发送/接受错误消息;多用户冲突引起的系统异常;同步异常等。其中,响应延迟、响应丢失类故障、发送/接受错误消息、多用户冲突引起的系统异常和同步异常主要发生在分布式软件中。

(5) 类缺陷 主要指与面向对象特征相关的错误。这类软件缺陷主要包括:访问控制错误;状态可见性异常;状态定义不一致;状态定义异常;异常处理错误;构造函数行为异常;构造函数不完整;类型使用不一致;重载函数实现错误;重载函数使用错误等。

2 程序变异及其分类

程序变异作为一种软件实现的故障注入方法,最早在20世纪70年代末期由DeMillo等人提出。它能够系统地模拟软件中存在的各种缺陷,并构造较为完备的测试用例集。虽然该技术具有较强的排错能力,但它对资源的消耗也是不容忽视的。

程序变异是指根据软件缺陷定义一系列的变异算子,并将变异算子作用于程序代码,从而改变程序句法以达到故障注入的目的。程序变异理论基于两个基本假设:一是程序员的能力假设,即假设程序不存在功能型错误,只存在一些代码编写的失误;二是组合效应假设,即复杂错误是简单错误的组合。

程序变异常用于软件测试阶段,它的基本原理是使用变异算子每次对被测试程序做一处微小的合乎语法的改动,从而产生大量的新程序,我们称之为变异体,然后根据已有的测试数据运行变异体,比较变异体和原程序的运行结果,如果两者不同,就称测试数据将该变异体杀死[5]。这样做的目的是不断提高测试数据集的测试充分度。变异测试是一种行之有效的测试方法,具有排错能力强、灵活性好、自动化程度高等优点。但它也存在一些缺点,如需要大量的计算机资源来产生、存储、运行变异体,并且需要大量的人工操作。

在程序变异中,变异算子的设计一直是人们研究的重点。针对不同类型的软件缺陷,研究人员设计出不同类型的变异算子。按照模拟软件缺陷的类型不同,可将程序变异分为以下四种:

(1) 传统变异 在早期程序变异的研究中,变异算子的设计主要集中在对操作数和运算符的变异上。有代表性的研究成果是Mothra测试工具集[6]。它针对Fortran语言定义了22种变异算子,这些变异算子源自程序员的错误。

(2) 接口变异 它模拟集成错误,在模块的接口处作用变异算子产生变异体。变异算子的设计主要针对函数调用、参数传递、函数返回值、共享的全局变量。文献[7]针对C语言设计了分别作用于被调用函数内部和调用函数内部的两组接口变异算子。文献[8]的实验结果表明接口变异不仅产生较少的变异体,消耗较少的资源,而且揭错率也维持在较高的水平。

(3) 类变异 是传统变异测试的一个延伸,它针对面向对象软件的特殊性质,模拟类、对象、继承、封装、信息隐蔽、多态、动态绑定等方面的软件缺陷。

文献[9]针对Java语言定义类变异算子,通过类变异算子植入与Java面向对象特征相关的错误。这些变异算子包括:更改访问控制符;删除隐藏变量;插入隐藏变量;删除覆盖方法;改变覆盖方法调用位置;重名命覆盖方法;删除super关键词;删除父类构造函数的显式调用;将子类型对象的声明替换为父类型;子类对象替换参数中的父类对象;兼容类型对象的赋值替换;改变重载方法的内容;删除重载方法;删除异常处理;修改异常处理;引用赋值和内容赋值之间的替换;引用比较和内容比较之间的替换。

(4) 合约变异 它是针对功能规约的变异测试,发现由于规约被错误理解或实现所导致的程序中的错误。与传统变异测试相比,合约的规模小于程序,其产生的变异体数目较小。此外,还可以通过定义有效的变异算子来减少合约变异体的数量,从而降低变异测试的计算代价[10]。

3 变异算子的设计

我们用变异算子模拟软件中将会出现的各类软件缺陷,通过程序变异的方法将软件故障注入到代码中。程序变异的同时,在变异体中插入故障检测代码,实现对故障的自动检测。按照第1节的软件缺陷分类,为每一类软件缺陷设计了一些变异算子来进行模拟。在设计变异算子时,我们遵循变异算子的两个设计原则:第一,程序的改动必须是微小的;第二,改动必须是符合语法规则的,也就是编译时不报错,程序能够正常执行。表1是为这五类软件缺陷所设计的变异算子。

3.1 赋值缺陷

为了模拟赋值故障,设计了五种变异算子。当被赋值的变量与原变量的值不一致时,认为故障发生。

(1) 删除变量初始化(DVI)

通过删除局部变量的第一次赋值,模拟变量未初始化就使用错误。

(2) 随机数替换整形值(RIR)

通过用随机数赋值给当前整形变量,模拟整形变量的赋值错误。在变量的使用过程中,整形变量的使用是最为频繁的,因此我们单独设计变异算子来模拟整形变量的赋值错误。

(3) 数组长度代替数组下标(LRS)

通过用数组长度的值代替当前数组元素的下标,模拟数组越界错误。

(4) 数组元素替换(AAR)

通过随机选择数组中的元素替换当前元素,模拟数组元素使用错误。与RIR算子相同,使用C语言的库函数rand()产生一个随机数,再通过求余运算,即可得到数组长度范围内的随机数。

(5) 将float型转换为int型(FCI)

通过float型变量强制转换为int型,模拟非法类型转换错误。

3.2 分支缺陷

为了模拟分支故障,设计了三种变异算子。当变异体的执行路径与原程序的执行路径不一致时,认为故障发生。

(1) 分支结构中赋值运算符替换等于关系运算符(ACB)

在分支结构的判断条件处,经常会发生“==”与“=”的误用,这类错误主要由于程序员的疏忽所致。

(2) 分支结构中逻辑运算符替换(LRB)

通过在分支结构的判断条件中,用“&&”替换“‖”,或者用“‖”替换“&&”,模拟分支结构中逻辑运算符使用错误。

(3) 删除括号(DPB)

通过删除嵌套的if语句中的括号,模拟if-else的匹配错误。

3.3 循环缺陷

为了模拟循环故障,设计了以下三种变异算子。当变异体的循环判断条件的真假值与原程序的不一致时,认为故障发生。

(1) 循环结构中赋值运算符替换等于关系运算符(ACL)通过将循环条件中“==”替换为“=”的方法,模拟循环结构中的等于运算符使用错误。

(2) 循环结构中逻辑运算符替换(LRL) 通过在循环条件中,用“&&”替换“‖”,或者用“‖”替换“&&”,模拟循环结构中逻辑运算符使用错误。

(3) 改变循环变量(CVL) 通过用相同类型的变量替换循环变量,模拟循环变量使用错误。这种变异也常会伴随引入变量未初始化就使用错误。

3.4 接口缺陷

为了模拟接口故障,设计了以下四种变异算子:

(1) 改变调用参数顺序(POC) 通过改变函数调用中兼容类型参数的顺序,模拟函数参数传递错误。这种类型的错误通常由于程序员的疏忽所致。

(2) 兼容型变量替换参数(VPR) 通过用兼容型的变量替换被调用函数参数,同样可模拟函数参数传递错误。另外,此变异若发生在Socket中的Send函数时,可模拟发送错误消息。

(3) 删除调用语句(FCD) 通过删除一个不在赋值语句中的函数调用,模拟函数调用丢失。

(4) 删除return语句(RSD) 在有多个出口的函数中,通过删除其中一个出口的return语句,模拟return语句丢失。

3.5 类缺陷

为了模拟类故障,设计了以下五种变异算子:

(1) 改变访问控制符(AMC) 通过改变成员变量的访问控制符模拟访问控制错误。该类故障依赖于软件特性,一般不易发生。此变异一般作用于类的头文件。

(2) 删除隐藏变量(IHD) 通过删除派生类中与基类同名同类型的变量,模拟因隐藏变量引起的状态定义不一致错误。此变异一般作用于类的头文件。

(3) 声明基类成员变量(MDB) 通过用基类声明一个派生类的对象,模拟类型使用不一致错误。

(4) 删除派生类覆盖函数(OMD) 通过删除派生类中的覆盖函数,模拟因覆盖引起的状态定义异常。

(5) 改变被覆盖函数的调用位置(OCC) 有些情况下派生类的覆盖函数需要调用基类的函数,通过改变被调用的基类函数的位置,模拟状态可见性异常。

4 软件缺陷对软件可靠性影响的分析

4.1 实验内容及步骤

选取经过充分测试后的软件作为实验对象,其缺陷数为0,软件可靠性为1。用程序变异的方法将上述变异算子分别作用于该实验对象,估计软件的可靠性,分析比较这些故障对可靠性的影响。实验的具体步骤如下:

(1) 从实验对象中选取待注入故障的构件。因为在C++语言中程序代码以CPP格式的文件存放,所以我们选择待注入故障的构件所在的CPP文件。

(2) 从上一节选择变异算子,将其作用于步骤(1)中所选的CPP文件,生成多个变异体。变异体的命名采用“原文件名+变异算子+流水号”。例如“CImageView_DVI_5.cpp”表示DVI变异算子作用于CImageView.cpp文件后所产生的第五个变异体。

(3) 选择一个步骤(2)中产生的变异体替换原文件,达到故障注入的目的。此时的实验对象中已包含了产生该变异体的变异算子所模拟的故障。

(4) 使用改进后的Cheung模型估计上一步得到的含有故障的软件的可靠性,具体步骤如下:

① 根据分布式软件在实际使用中各功能与数据的出现频率,建立操作剖面。频率必须从大样本中获取,以确保统计数据的有效性。

② 为分布式软件划分构件,确定构件间的连接件。将每台主机上的通信模块定义为一个连接件,该主机的其余模块定义为一个构件。根据各构件之间的调用关系,建立分布式软件体系结构及转移概率矩阵。

③ 根据耦合性最小的原则,并为每个构件划分子构件。根据子构件之间的调用关系,建立该构件的转移概率矩阵。

④ 从操作剖面中选择一个操作序列,通过执行分布式软件,收集失效数据。

⑤ 取一个构件,根据步骤④得到的失效数据,计算其中每个子构件的可靠性。

⑥ 根据步骤③中所得到的该构件的转移概率矩阵与步骤⑤中得到的子构件的可靠性,计算当前构件的可靠性。

⑦ 从步骤⑤开始重复执行,直到所有构件的可靠性都已计算完成。

⑧ 根据步骤④得到的失效数据,计算每个连接件的可靠性。

⑨ 根据步骤②、⑥、⑧所得到的分布式软件转移概率矩阵、构件可靠性、连接件可靠性,修正分布式软件的转移概率矩阵,计算当前操作序列下的软件可靠性。

⑩ 从步骤④开始重复执行,直到所有操作序列下的软件可靠性均计算完成。根据步骤①、⑨得到的操作剖面与各操作序列下的软件可靠性,计算最终的分布式软件可靠性。

(5) 重复执行步骤(3)、(4),记录所有的软件可靠性的值,分析比较实验结果,得出结论。

按照设计好的实验步骤,漫游系统实验选取文献[11]中提到的立方体全景图虚拟场景漫游系统(简称漫游系统)作为实验对象。该系统是在VC++ 6.0集成环境下,基于文档视图结构开发的可以在单机上运行的软件,属于集中式软件。它包含2017行代码,提供了水平、垂直方向的360度旋转漫游及场景的缩放功能。

4.2 实验数据分析及结论

选择第3节中的变异算子作用于漫游系统的CImageView.cpp文件,估计软件可靠性,我们用图形来表示注入各故障后漫游系统的可靠性,其中横轴表示各变异体,纵轴表示含有该变异体的软件可靠性。图1-图5分别表示五种类型故障对漫游系统可靠性的影响程度。

根据上述数据可以得到注入各类故障后系统可靠性的分布区间和平均值,如表2所示。

从表2中我们可以看到,含有赋值故障的软件可靠性的平均值最小,并且其分布较为集中,故认为赋值故障对该软件可靠性影响最大;含有类故障的软件可靠性的平均值最大,并且其分布区间也相对集中,所以我们可以得出类故障对软件可靠性的影响最小;除类故障外,含有接口故障的软件可靠性的平均值较大,其次是含有循环故障的软件和含有分支故障的软件。

总体来看,可以得出这五类故障对漫游系统可靠性的影响由大到小依次为赋值故障、分支故障、接口故障、类故障。由于含有循环故障的软件可靠性分布区间较宽,且较散乱,因此其平均值并不能说明该类故障对软件可靠性的影响程度,但我们可以得出该类故障会因变异体的个体差异而对软件可靠性造成不同的影响。

赋值故障一般发生在程序中函数的开头部分,后续的语句会直接或间接的使用到这些变量,故障的扩散性较强,因此该类故障对软件可靠性的影响较大。分支故障仅会发生在分支型结构的某个分支上,当程序在分支结构中的执行路径发生变化时故障才会发生,因此该类型故障发生的概率要比其他类型故障发生的概率要小,对软件的影响也较小。由于分支结构与循环结构在程序中占有很大的比例,而接口故障经常会发生在分支结构与循环结构中,因此故障发生的次数较少,所以该类故障对软件可靠性的影响较小。另外,在含有循环故障的软件中,由于循环次数的不确定性,导致故障发生次数的不确定,因此故障的个体差异使其对软件可靠性的影响不同。

类故障对不同的软件影响程度不同。第一,类故障与面向对象特性使用的多少有关,如覆盖、继承、重载等。当这些技术在软件中的应用较多时,出错的概率也较大,对软件可靠性的影响也较大。第二,类故障与软件的规模有关。类故障发生的条件较严格,在软件的一次运行中失效次数较少。当软件规模较大时,构件的执行次数较多,因此构件的可靠性较高,软件的可靠性也较高。

通过进一步的实验发现,软件可靠性值的分布与软件规模有关。表3给出了二个实验软件的测试数据。可以看到,软件规模较大时,可靠性的值的分布也较广,下限低,上限高;软件规模较小时,可靠性的值分布较窄,下限高,上限低。表中C/S系统的软件规模指的是客户端的代码行数。当软件规模较大时,构件的执行次数会增多,构件的失效次数也会增多。当执行次数增长速度大于失效次数增长速度时,构件可靠性提高,同时软件可靠性也提高;反之,构件可靠性和软件可靠性均降低。因此当软件规模较大时,可靠性波动也较大,各类故障对软件影响的差异性也较大。

5 结束语

软件缺陷是引起各类软件失效的根本原因,是影响软件可靠性的重要因素。研究人员从不同的角度出发,对软件缺陷进行了分类。然而这些分类方法均没有从程序代码的角度对软件缺陷进行分类。本文提出了一种面向程序代码的缺陷分类方法。根据这一分类法,设计了模拟各类软件故障的变异算子;采用程序变异方法,通过实验获得了各类软件故障对软件可靠性影响的相关数据,得出了各类软件故障对软件可靠性的影响程度,对软件的开发和使用都具有实际意义。

参考文献

[1]聂林波,刘孟仁.软件缺陷分类的研究[J].计算机应用研究,2004(6):8486.

[2]戚馨文.ODC和OPC方法在软件质量管理中的应用[D].浙江大学,2006.

[3]黄锡滋.软件可靠性、安全性与质量保证[M].北京:电子工业出版社,2002.

[4]Ram Chillarege,et al.Orthogonal Defect Classification:A Concept forIn-process Measurements[J].IEEE Transactions on Software Engineer-ing,1992,18(11):94395.

[5]单锦辉,李炳斌,孙萍.变异测试——一种面向缺陷的软件测试方法[J].半导体技术,2007,32(增刊):8085.

[6]King K N.A Fortran Language System for Mutation-Based SoftwareTesting[C]//ACMSIGPLAN Symposium on Interpreters and Interpre-tive Techniques,St.Paul MN,1987,7.

[7]Delamaro ME,Maldonado J C,Mathur A P.Interface mutation:an ap-proach for integration testing[J].IEEE Transactions on Software Engi-neering,2001,27(3):228247.

[8]Delamaro M E,Maldonado J C,Mathur A P.Integration Testing UsingInterface Mutation[C]//Proc.VII Int'l Symp.Software Reliability En-gineering(ISSRE'96).1996,11:112121.

[9]Ma Y S,Kwon Y R,Offutt A J.Inter-class mutation operators for Java[C]//Proceedings of the 13thInternational Symposium on SoftwareReliability Engineering(ISSRE 2002).Annapolis,MA,USA,2002:352363.

[10]姜瑛,辛国茂,单锦辉,等.一种Web服务的测试数据自动生成方法[J].计算机学报,2005,28(4):568577.

会计软件缺陷 篇6

印度软件业发展过程中存在的缺陷

1.软件产业极度依赖出口, 在迅速开拓国际市场的同时, 国内市场发展缓慢。根据印度全国软件服务协会 (NASSCOM) 的统计, 印度现阶段软件业出口额占软件产业总额的80%以上, 软件产业出口额占据全国出口总额的约20%, 可见出口对于印度软件产业甚至印度经济的重要性。印度软件业对出口和国际市场的极度依赖是由多方面的原因造成的, 也为印度软件业的长远发展埋下了很大的隐患。一方面, 印度软件业在国际市场上大行其道, 另一方面, 在印度的国内市场上, 软件业的产值很低, 为软件业的发展贡献的利润和市场份额都很有限。印度软件产业极度依赖国际市场的缺陷使得软件企业的发展对印度经济的贡献仅仅是数量上的, 而不是结构上的。软件产业作为一门现代化的科技产业, 其在印度的发展得到了政府部门的大力扶持, 因而其对印度经济和社会发展所起到的效应不仅仅应是增加出口额和外汇收入, 还应体现在推动整个印度国内经济和社会的发展上。

2.出口市场集中, 过度依赖美国和欧洲市场, 加大了市场风险。根据印度全国软件服务协会 (NASSCOM) 的统计, 美国市场占据了印度软件业出口份额的60%以上, 欧洲市场占据了印度软件业出口份额的30%以上。出口市场结构的单一加剧了软件业出口的市场风险, 也使得印度软件业的发展面临着极大的不稳定性和不确定性。2007年, 金融危机的爆发使得美国软件发包商大受打击, 美国市场对软件外包服务的需求因此直线下降, 沉重打击了印度的软件外包业。印度软件业三巨头英佛赛斯 (Infosys) 、维普罗 (Wipro) 和萨蒂扬 (Satyam) 在2007年的收入及净利润均大幅下降, 并拖累了整个印度经济, 印度孟买证券交易所Sensex指数在金融危机爆发后的一年内累计下跌了近50%。

3.印度软件业的发展实际上是对外大量输出劳务, 而不是发展具有核心竞争力的高科技信息技术, 这也是印度软件业发展过程中存在的最大缺陷。印度软件产业的主要盈利模式为软件外包, 其中相当大一部分产品或服务属于劳动密集型的低附加值产品。这些低附加值的软件产品通常都没有自己的品牌, 并且并不拥有产品的核心知识产权, 处在软件产业价值链的最低端。据相关统计, 目前印度软件产业低附加值产品占据了印度软件产业产品的90%以上。核心知识产权的缺乏必将使得印度软件业缺乏核心竞争力, 无法获得持续、稳定、高效的长远发展。

另外, 创新不足也严重制约了印度软件产业的进步与升级。目前, 印度整个软件产业的发展缺乏一套有效的创新机制, 政府采取了诸多措施鼓励和扶持软件业的创新, 但效果都不甚明显。虽然在印度软件业的心脏地带班加罗尔有许多的软件研发机构, 但大多数都是由跨国公司设立的, 所创造出来的知识产权自然也属于跨国公司, 而不是印度软件产业自身的创新。

印度软件业的缺陷对我国软件业发展的启示

1.国内市场和国际市场并举, 在发展国内市场的同时, 大力开拓国际市场, 同时加强创新体系的建设, 在软件产业发展的问题上不能急功近利, 要脚踏实地的走出一条开放创新与自力更生相结合的拥有自主核心知识产权的高效发展道路。我国软件业发展的国情明显不同于印度, 软件业发展的国内环境比印度优越很多。印度软件业国内市场的萎靡在很大程度上是由于其国内的经济较为落后, 尤其是电子信息硬件制造业的落后, 使得其本国市场对软件产品的需求较低, 制约了国内软件市场的开拓。我国则明显不同。近年来我国经济持续高速发展, 各行各业对软件产品的需求急剧增加, 可以说软件产业在我国国内的发展前景一片大好;另外, 我国号称“世界工厂”, 国内的电子信息硬件制造业也较为发达, 为软件产业的发展打下了坚实的根基, 提供了良好的发展环境。

在当前环境下, 应充分发挥政府政策的导向性作用, 利用我国国内市场硬件产业基础雄厚的优势, 出台相应的扶持和鼓励政策, 对软件企业提供财政、税收和行政方面的优惠和便利, 鼓励软件企业进行技术创新并积极开拓国际市场, 同时积极建设软件科技园区和出口基地, 增强我国软件出口企业的国际竞争力, 力求扩大我国国内软件产业的规模, 培育出类似印度的英佛赛斯 (Infosys) 和维普罗 (Wipro) 之类的软件龙头企业, 并以软件龙头企业为核心, 积极吸纳和借鉴世界软件产业先进的技术和经验, 以提升我国软件企业的核心竞争力和我国软件业的综合素质。

软件缺陷的评估方法分析与研究 篇7

软件质量可以通过一系列度量因素来描述。对软件质量, 我们大致可以总结出5个关键度量维度, 即客户满意度、产品价值、关键属性、缺陷率和开发过程质量。高质量的软件, 应具备外部属性和内部属性, 其中外部属性包括产品的正确性和精确性、可用性、运行效率、可靠性、健壮性和适应性;内部属性包括可维护性、易扩展性、平台灵活性、可复用性、易测试性、代码可读性和整体理解性。软件质量重点强调软件需求、具体标准和隐含需求。

目前, 人们对软件质量保证体系的研究已比较成熟。世界上关于软件质量保证体系存在CMM/PSP/TSP、ISO 9000系列和ISO/IEC 15504 (SPICE) 三个流派, 其中, 以美国国防部支持的CMM/PSP/TSP流派研究得最为深入, 使用得最为广泛。

在软件缺陷分析和预测研究方面, 人们进行了大量的研究, 开发出一些软件缺陷预测模型。这些模型大致分为两类:一类是在软件开发的测试阶段, 根据历史数据预测软件缺陷;另一类是在软件开发之前, 通过对以往项目的缺陷数据进行分析, 预测在软件开发中会出现的缺陷数, 这些模型大多可以用于软件开发过程中的质量控制。

软件缺陷风险识别框架

软件生命周期是软件项目开发的重要阶段划分, 风险管理的实践通常都是与其结合进行的。本文按软件项目生命周期进行分阶段风险因素识别, 通过文献总结和软件项目从业人员的经验总结获取有价值的风险因素。

为了更好地了解基于软件项目风险分类的风险因素识别方法, 下面来看看软件开发项目风险结构图 (如图1所示) 。该分类从三个方面分析:软件项目生命周期过程、项目内部环境和项目外部环境。事实上, 在软件项目进展的过程中, 项目的内外部环境中的风险因素始终威胁着项目, 这些内外部因素随着软件项目的进展在不断演化, 不断影响着项目的产出结果。软件项目的管理技术将项目团队置于项目环境之中, 正是项目的环境、项目的管理技术和项目团队影响着整个项目的进展。项目的环境就是项目特性, 它包含了项目的本身需求因素、项目的内外部因素等;项目管理包含了项目的管理思想和管理技术;项目团队包括了项目的技术人员和项目的管理人员。

项目特性、项目管理和项目团队三者之间, 其实是互相影响的关系。当然, 项目管理是其他两者的重要纽带, 是三者关系的重要推力。紧密结合的三者又在项目的进展中不断改变各自的影响力, 互相均衡自己的影响力来推动项目的进展。

在一个软件项目当中, 项目管理人员和项目技术人员是可以在建设阶段中熟知一部分风险的, 只是从项目组织上无法通过沟通合作对风险形成一致的认识以实现共同抵御风险;在项目建设过程中, 持续的风险评估对于风险管理有着重要意义, 这就要求风险评估应当跟随项目进展, 应当经历项目建设的每一个阶段, 并对项目建设过程中变化的环境因素进行持续的风险评估;为了更有效地进行持续的风险评估, 就需要一个结构化的风险评估方法, 而且应将风险评估工作放置在一个开放的环境之中;最后, 在项目团队中要形成一种认识, 为了取得项目建设的成功并非需要控制所有的风险。

软件缺陷风险评估模型

项目管理者依靠有效的项目管理方法, 组织项目团队在相应的项目环境下去解决一定的项目需求, 而项目环境和项目需求是这个项目最典型的特性。在整个项目阶段进展过程中, 项目团队、项目管理和项目特性始终影响各阶段的递进, 就好像一条纽带把它们紧紧联系起来。

软件缺陷的评估, 可以放在需求阶段、设计编码阶段和测试阶段进行, 软件开发在不同阶段都会有项目团队的参与, 项目团队的工作能力和效率将直接影响着各个阶段的项目产出。

风险模型构造。软件缺陷的风险识别, 是按照软件生命周期的阶段分类进行的, 若将各阶段的风险因素置于同一个网络模型中, 那么, 这个模型无论它的复杂度还是数据存储空间都会制约着风险模型的评估效率。因此, 将风险模型按照软件生命周期各阶段进行分类, 每类之间按照阶段递进方式进行参数传递, 这种分阶段评估模型可以提高风险评估的效率。

需求阶段产生的需求错误和需求变更, 经过需求检测和新需求匹配性审核进入下一个阶段;设计编码阶段接受检测后的需求错误、需求分析文档和新需求匹配性审核, 输出编码错误和设计文档进入测试阶段;测试阶段接受设计编码阶段的输出和用户方试用的效果共同影响项目的缺陷率。项目团队工作能力的评估是贯穿三个阶段进行的, 它的输出进度压力、管理者工作能力和技术人员工作能力, 这些都作为三个阶段的评估输入。从图2可以看到, 各阶段风险模型的输入和输出、模型之间的联系因素等。分阶段模型一旦建立, 就可以在软件开发过程中的关键时刻设立预测点, 从而对整个开发过程进行有效的管理。

团队工作能力评估。团队工作能力评估主要根据管理者和技术人员之间的沟通以及项目管理的计划和分工水平来进行, 具体来说就是项目客户代表的工作能力、项目经理的资质、项目成员的技术水准、员工之间的沟通机制、项目管理人员的计划分工能力和项目团队的人才管理能力。

图3描述团队工作能力的风险模型。图中给出了设计阶段的设计质量目标的影响图, 包括设计质量受到阶段进度、开发人员工作能力、采用的技术、管理者工作能力, 并且软件开发其他阶段质量目标都有类似的影响结构图, 并进一步细化项目管理人员工作能力的评估、项目技术人员工作能力的评估和整个项目进度的评估。

软件缺陷评估工具

评估工具的应用, 能够让项目经理了解到项目目前的管理水平和风险威胁, 并根据提前的评估通过有效的管理控制措施来提高项目的成功率, 在项目和项目管理者之间架立桥梁。评估工具的核心就是图4中的四个风险模型, 四个风险模型分别描述了项目不同阶段风险因素之间的影响关系。

评估工具总体结构。项目经理可以通过评估工具的风险简要表, 向评估系统提供项目的目前基本信息, 经过项目团队工作能力的评估之后, 可以分别进入不同阶段的风险评估。当然, 不同的阶段评估将需要管理者提供不同的当前项目基本信息。

评估工具目前可以提供三类评估:一类是全程预测, 即软件开发需求分析前期, 对开发质量的整体评估, 按照图4中首先进行团队工作能力的评估, 接着进行需求阶段的评估, 然后是设计编码阶段评估, 最后是测试阶段评估, 整个评估路线就是 (1) (4) (5) ;第二类是需求后阶段评估, 即需求分析阶段之后的设计编码和测试阶段评估, 在这一类评估之前, 必须要了解项目在需求阶段的产出, 包括需求阶段引入的缺陷和需求变更的评估, 按照图4中首先进行团队工作能力的评估, 接着进入设计编码阶段的评估, 最后进行测试阶段评估, 整个评估路线就是 (2) (5) ;第三类是测试阶段评估, 在这类评估之前, 必须要了解项目在需求阶段和设计编码阶段的产出, 包括需求分析质量、设计文档质量和编码阶段引入的缺陷的评估, 按照图4中首先进行团队工作能力的评估, 接着直接进入测试阶段评估, 整个评估路线就是图中的 (3) 号路线。

数据流图。评估流程说明了评估工具应用的场合, 而评估工具的数据流图可以进一步解释评估工具的输入和输出, 为具体应用提供更明确的数据操作。

在评估工具的数据流图中, 项目经理首先需要选择软件开发的评估阶段, 接着进入评估工具的输入状态, 完成相应的风险因素的评估, 进入评估工具的整个评估路线, 最后得到软件缺陷的风险状态和其他风险的状态值, 这些状态信息可以作为项目经理进行风险管理的可靠依据。

软件缺陷数目是软件可靠性的重要度量指标, 而软件可靠性是衡量软件质量的最重要因素。如何为进行项目管理提高重要的风险信息, 对软件缺陷进行合理、正确的评估, 已经成为项目管理的首要任务。这样, 软件项目的风险管理成为软件项目管理的重要工作, 能否很好地解决这些问题将直接影响到软件项目风险管理的有效性, 同时也影响到软件开发的质量和软件项目的完成。

参考文献

[1]朱鸿, 金凌紫.软件质量保障与测试.北京:科学出版社, 1997.

[2]李文静.软件缺陷与软件测试.计算机与网络, 2001, (21) :31-32.

[3]黄国青, 田英.改善软件开发质量的全面质量管理办法.西北工业大学学报 (社会科学版) , 2001, 21 (3) :20-22.

[4]叶俊勇, 汪同庆, 杨波, 彭健.软件开发的质量保证体系.计算机与现代化, 2002, (6) :1-4.

[5]郑翠芳, 吴志杰, 夏涛, 张伟燕.基于BBNs的软件残留缺陷预测模型.微计算机信息, 2006, (3) :269-271.