hyc.bjufida.com 小编要给大家介绍怎么管理软件项目质量评价，以及软件项目质量如何评估对应的相关知识，希望对各位用友ERP软件使用的朋友有所帮助，详细内容可参阅目录。
微信号：186791106581.2 软件质量特征
按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：
a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
e.可维护特征：与进行指定的修改所需的努力有关的一组属性。
f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。
其中每一个质量特征都分别与若干子特征相对应。
2 评估指标的选取原则选择合适的指标体系并使其量化是软件测试与评估的关键。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。
在选取评估指标时，应该把握如下原则：
a.针对性即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。
b.可测性即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。
c.简明性即易于被各方理解和接受。
d.完备性即选择的指标应覆盖分析目标所涉及的范围。
e.客观性即客观反映软件本质特征，不能因人而异。
应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。
3 软件质量评估指标体系通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。
3.1 功能性指标功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。目前对软件的功能性评价主要采用定性评价方法。
a.完备性完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。
b.正确性正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。
对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。
目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。
软件项目中的质量管理
软件的质量是软件开发各个阶段质量的综合反映。软件项目的建设包括项目计划、需求分析、软件开发和系统维护等阶段，质量管理工作会始终贯彻在项目建设的各个阶段，下面是我分享的一些相关资料，供大家参考。
1. 项目计划的质量管理
科学合理地制定项目开发计划，是项目成功的关键，在制定项目计划时，以下三个方面需要特别注意。
首先，项目计划必须群策群力。项目计划的制定不仅需要对项目任务进行工作分解(WBS)和对资源估算以制定项目计划，更需要在项目计划中结合历史项目的实践经验和相关领域的行业经验，科学地评估项目各阶段所需要的时间并预留风险缓冲时间。通常可先由项目承建方制订项目计划草案，项目计划草案注明项目各阶段的产生物和里程碑时间，再由业主、监理、承建方的主要负责领导和技术骨干对项目计划草案进行讨论，并根据各方意见进行修订和完善，最终形成各方认可的项目计划。
其次，项目计划要因变而变。在“金保”工程建设中，软件项目开发往往涉及劳动保障多个部门的工作，因而项目计划在实施过程往往受到多种因素的影响。项目计划要跟上项目的实际变化，通过动态调整投入项目的资源，合理地调节项目进度以及阶段性的里程碑，使得项目计划反映项目的实际进度，从而确保项目质量保证的实施。
最后，建立项目沟通制度。每周召开业主方、承建方、监理方参加的项目例会，共同协商项目建设中所遇到的问题，明确责任分工，确定下一步工作计划，并根据实际情况及时调整，确保项目按计划进行。
2. 需求分析的质量管理
把握正确的业务需求是项目成功的关键。需求分析是软件开发人员掌握业务流程，最终确定软件需要做什么和如何做的定义过程。由于对业务的需求分析是个迭代的过程，只有通过持续地与业务人员进行交流确认，才能最终掌握业务的实际需求。
在“金保”工程建设中，为了减少需求分析阶段可能发生的各种风险，劳动保障部门信息中心的技术人员利用自己既掌握劳动保障的业务政策，又懂得软件开发技术和方法的优势，积极参与到软件项目中，做业务人员和软件开发人员联系的桥梁和纽带，既引导业务人员提出业务的需求，也帮助软件开发人员掌握业务规则。由于很多业务流程非常复杂，而且不可视，为了更好地获得业务需求，要求承建方制作软件原型，软件开发人员通过原型与业务人员进行进一步的沟通，最终获得与业务流程相一致的软件模型。需求分析结束后，编写成《用户需求说明书》、《需求规格说明书》，由业主、监理、承建方三方签字认可，作为验收方案和验收标准，并做好变更控制和配置管理。
3. 软件开发的质量管理
软件开发是软件实现的重要阶段，需要通过运行多种质量管理方法做好软件开发过程的质量控制。这个时期的`质量管理的方法包括了日常检查、阶段评审、方案检验和质量原因分析等。
日常检查贯彻于软件开发的全过程，通过对业务调研、系统设计和系统实现等过程进行监督，及时识别和发现缺陷。阶段评审主要对各阶段的产出物进行评审，尤其是需要加强对需求阶段的《用户需求说明书》、《需求规格说明书》、系统设计阶段的《设计说明书》，以及测试阶段的《确认测试用例》、《集成测试用例》的评审工作，通过评审发现阶段性问题，通过及时修改和完善，尽可能减少带入下一阶段的缺陷数目。
方案检验是对在软件的设计方案进行模拟测试，通过对存储数据量、并发用户数、网络环境等多方面的综合验证测试，以保证系统设计方案的正确性。质量原因分析报告用鱼刺图来展现影响软件质量的各种直接和间接的原因以及构成这些因素，以总结经验、吸取教训，避免类似的质量缺陷重复发生。
4. 系统维护的质量管理
软件项目开发完成交付使用后，随着时间的推移，承建方的开发人员会逐渐转移到其他项目，从而在技术服务和技术响应上得不到有效的支持，而软件随着推广使用的进一步扩大，对软件的可靠性、稳定性等方面提出了更高的要求，最终出现承建方的维护不及时、业主方维护工作繁重的局面。
为解决系统维护阶段的问题，首先在项目建设初期劳动保障信息中心的技术人员应该参与软件的设计和开发，通过掌握软件的核心技术和运行方法，使得软件在运行和维护期间不需要过分依赖于承建方，只要不是大的改动都能应付，特别要熟练掌握软硬件环境的安装、维护、调优和备份等工作。其次，完备的文档为程序的维护、更新、扩展提供良好的帮助，承建方应该提供完整的文档，包括软件安装手册、软件操作手册、在线帮助、系统管理手册等，为以后的维护工作提供方便。
在“金保”工程建设中，要提高软件项目质量管理的方法有很多，例如在软件企业实施CMM规范或者引入RUP过程等，但对于参与“金保”工程建设的大多数中小型软件企业而言很不现实。首先，这需要企业投入大量的资金和人力物力，这不是企业所能承受的; 其次，CMM和RUP太大、太广，要求具有不同专业背景的技术人员，并且在企业内部建立起层次分明和分工清晰管理体系，而这些恰恰又是中小型软件企业所缺乏的。在“金保”工程的建设实践中，我们深切体会到，针对软件质量管理的薄弱环节实施质量管理改进，不用投入太多人力物力，就能较大程度地提高软件的质量。
;
加强软件产品的质量管理,先有三种标准设置：
1.以最终使用者的方便度为标准。
2.以客户满意度和获得利润为标准。
3.以技术观点为标准。
再依以上的加权比例进行加强软件产品的质量管理。
在实际的项目质量管理中，质量管理总是围绕着质量保证(Quality?Assurance)过程和质量控制(Quality?Control)过程两方面。这两个过程相互作用，在实际应用中还可能会发生交叉。正如引言所述，关于软件的质量，很难下一个非常明确的定义。本文主要针对软件工程中的质量管理来进行讨论。
1、做软件“大餐”的工序
软件质量保证（Software?Quality?Assurance，以下简称SQA）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。软件质量保证过程一般包含以下几项活动：
首先是建立SQA组；其次是选择和确定SQA活动，即选择SQA组所要进行的质量保证活动，这些SQA活动将作为SQA计划的输入；然后是制定和维护SQA计划，这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系；还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。
独立的SQA组是衡量软件开发活动优劣与否的尺度之一。SQA组的这一独立性，使其享有一项关键权利――“越级上报”。当SQA组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。
如何做好项目的质量管理
项目的时间、成本及质量的三大要素是缺一不可。这三方面的符合程度直接决定了项目的成败与否。那么如何做好项目的质量管理呢？一起来学习学习！
1、分析阶段
项目的开始阶段，也是质量控制的开始。在这个阶段中，主要的工作是从客户方获得足够多的项目需求，并准确地记录在案，而且要使得项目组的成员对于需求足够得了解。先说说这个项目的基本情况：一个信息管理系统，而且是在原来的版本上进行的功能增加。项目组的成员，除了我以前参加了前一个版本的开发，其它的人员都不了解这个项目。就是这样的一个项目，在开始阶段，我先是安排了组员对以前版本的需求文档进行了阅读，并安装使用了软件。随后对新的需求进行了研究，分析了它们对于原有系统的影响。由于是在旧有系统的文档进行增加，所以加入的新内容并不是很多，需求文档很快就完成了。所谓的分析阶段的里程碑也就结束了。
在需求阶段"顺利"结束的同时，问题也随之留下来，并对后面的阶段起到了"乘数效应"――影响变得越来越大：
A. 对旧系统的理解不足
由于开发人员没有参与过上一个版本的开发工作，他们对于旧系统并不了解.虽然在阅读了以前的需求文档以及使用了软件之后，大概对系统的功能有了一个初步的认识.但是对于系统中出现的各种逻辑关系并没有深入了解下去.作为项目经理，在这项工作中，失误之处在于任务的结果(即输出)没有事先定义清楚，从而也就导致无法确认目标是否已经达到，再加上需求文档描述的也不是十分清晰.最后，只是在开发人员觉得已经理解该系统的基本上，进行了下一步的工作.没有进行进一步的确认工作，不知道组员进行旧系统已经了解到了什么样的程度。这个问题的结果，就是直接导致了后期的开发过程中，由于对于原先系统的逻辑关系不是很清楚。对于旧代码理解和新代码编写进行地不是很顺利。
B. 对新需求的分析不够
这还是个老问题，但又不是一个问题.说它是个老问题，因为分析需求要求考虑细致全面，并且能引导客户，启发客户提供更有价值的信息。事实上，需求分析我们做的算是很尽力了，同时客户把需求一条条的列出来给我们，相对来说需求已经很清楚了。我们在接到这些需求后，不仅研究了新功能，还把他们对于旧系统的影响都做了分析。但还是有些问题没有能在需求文档中反映出来，后面的影响也是可想而知的了。我以前的文章中才曾提到过相关的问题，在这里就不再重复了。不过，从另一个角度来看，它又不是一个问题。为什么这么说呢，因为需求实在不是能够在分析阶段就能完全理解透彻的，甚至有的需求客户也模模糊糊，直到交付以后才提出了改动的要求。软件开发经过这么多年的发展，大家已经认识到了一点：需求是变化的。要达到能够拥抱变化的要求，我们要对开发方法进行改进，相关的问题我在后面也会提到。
需求分析阶段出现的问题，解决的可操作性不是很大，更多的是从思想或经验上解决，而后面几个阶段出现的问题都相对具体一些。
2、设计阶段
设计阶段的问题相对比较明显――结构设计不合理，或者说还不够。一个传统的C/S结构的系统，基本结构我们采用了经典的三层模型来划分系统。由于是在旧有系统上的改进，我们在尽量不改变原有系统的基础上添加新的功能。
主要的问题可能就是体现在没有对旧系统进行改进。旧系统本身有一些复杂的功能，逻辑关系也比较复杂，耦合度非常高。所以，在新需求来临的时候，我们的第一反应就是尽量不去动原来的设计与代码，保证原有系统功能不会发生变化。这一点就暴露出了我们没有去拥抱变化的决心与胆量。虽然旧系统很复杂，但是我们不能去故意回避它。对于旧系统中设计的'不合理的地方，应该主动大胆的去进行重构。其实重构的作用就是对不合理结构的进行改进，设计模式更是在设计结构的变化改进中才能体现它的价值。而这些东西，在我们的项目中都没有应用.这可能跟我们的保守心理有关：只要不出问题，我们就不去动它，哪怕结构是多么的错综复杂。这种消极的观念在当今的充满变化的世界中是不太有前途的。项目经理要有足够的决心去做，同时，也不要担心去变化。当然，可能有人会说，时间紧怎么办，其实这种付出对于项目的整体是只有好处没有坏处的，因为结构合理会让开发人员会更少的时间去理解代码，减少代码开发的复杂度，提高代码编写的质量。唯一需要考虑的就是如果改动的话，如何来保证这种变化对原有系统的功能不产生影响。这就需要有更多的测试，最好是单元测试来保证，这就是下面会谈到的问题。
3、编码阶段
编码主要还是受了设计的限制，我们的主要工作就只是在原有的结构上添加一些类与方法，以及对原有的代码进行修改。前面也提到了，我们采用了比较保守的作法，没有对代码进行重构，放任这种高耦合的代码存在，导致我们在编码过程中花费了不少精力和时间去理解它们，并在其中加上一两条更加加深耦合度的代码。其实到了编码阶段，很多问题都纠缠到了一起，已经分不清因果了。比较说单元测试，首先我需要承认的一点就是没有足够的决心去做充分的单元测试，思想上也没有做好充分的准备。除去主观的因素之外，还有一点就是设计的结构不合理，很多的逻辑被处理在表示层中，数据处理则被加到了逻辑层中。没有划分出更多的接口供单元测试来验证。但反过来说，没有单元测试用例的支持，也降低了我们想要进行重构的决心。除了上述的问题之外，还有一些细节的地方，如硬编码，命名规则等都在一定程度上对代码的质量产生了影响。
改进的办法，一是从主观上接受变化的现实，主动的对代码进行改动。单元测试一定要进行，最好结合统计覆盖率的工具一并进行，这样对于每个接口，都保证有充分多的测试用例来跑完尽可能多的路径。在项目的质量管理上面，要求还需要更加严格一些，一定要按照规范来进行编码。
4、测试阶段
代码完成之后，测试的工作也随之展开。但是由于成本的原因，我们并没有再加入专业的测试人员来进行，而只是用开发人员自己来进行系统测试，让开发人员互相测试别人实现的功能。由于开发人员与测试人员所需的专注点不同，造成了开发人员很多问题在测试中没有被发现，缺乏测试的经验。从另一个方面说，是开发人员不能够及时的转换自己的角色，而是还把自己定位在开发人员上面，更加关注的问题出在什么地方并立刻去解决它,而不是设法去发现隐藏的Bug。当然，还有一些细节的地方，比如说测试都应该是开发人员发布一个安装包，然后单独进行测试，但有的时候为了图省事，有的功能在调试状态下发现通过了，在安装包中就没有再验证，有时也会出现意想不到的情况发生。
;
1 质量计划
对于软件项目质量管理而言，必须先制定出一套较为完善的质量计划，才能够以较大的概率完成软件项目质量管理的目标。制定软件项目质量所依据的应该是企业对与项目质量所制定的的战略目标。我国企业采取的等级结构一般都是典型的金字塔型结构，管理者特别是高层管理者的理念与意识对于企业的各项工作能够产生非常大的影响。从这个意义上讲，质量计划应该是电信企业与软件企业高管层的`责任，而软件项目的质量就应该是由企业高管层所规定的关于项目质量的战略规划以及工作的方向。
软件项目质量计划的目的是确保软件项目的质量，因此就涉及到了衡量软件质量的问题，即判断质量计划中的项目质量是否已经达到较高的标准。对于这一问题，软件开发企业通常所采用的做法通常是与行业内项目质量的均值作比较，以此判断本项目的质量能否达到行业内的平均标准。
2 质量保证
质量保证的一般含义是为了证明项目能够达到有质量的标准而在质量体系中所进行的工作。因此，质量保证工作必须确保项目涵盖了能够达到质量要求的所有工作。若质量保证工作确定项目已经满足要求，则可以继续进行下一个环节的工作，即质量控制，反之，则要先完善项目质量计划工作。
对于软件项目而言，质量保证的具体内容包括几个方面:(1)具有清晰的软件需求分析。需求分析是软件达到客户要求的基本评价标准，也是软件项目质量评价的基本依据，因此，必须确保软件项目具有清晰、可行的需求分析。(2)具有科学的软件项目质量体系与质量标准。需求分析是判断软件质量的标准，而根据前文所述，软件质量是否达标只是评价软件项目质量的基本标准。因此，但仍然有必要从多个维度建立、健全软件项目的质量体系以及质量标准。特别是对于电信企业而言，所面对的市场具有很大的不确定性，有鉴于此，电信企业软件的项目质量更需要建立、健全质量评价体系，制定完善的评价标准。(3)具有完成项目所必需的各种资源。电信企业的基础设施建设需要耗费大量的成本，电信企业的软件项目也同样需要大量的人、财、物等资源。因此，在质量保证工作当中需要确定企业具有达到项目质量标准所必需的各种资源，以保证软件项目能够达到其预定的标准。
3 质量控制
质量控制工作是指评价项目成果是否符合相关的质量标准，并且当项目成果未达到标准时，对其原因进行分析并找到解决的方法。当项目的成果达到质量标准时，相关产品就可以交付使用了，反之，则需要对质量计划与质量保证两项工作进行改进，以保证项目成果能够符合相关规定。
具体到软件项目，质量控制包括两项具体的工作:(1)判断所开发的软件是否达到客户所指定的标准，若已经达到，则可以继续开发，反之，则要对产品进行改进，保证产品能够满足客户需要。(2)判断项目的成本与进度执行是否达到质量计划中的标准，若已经达到，则项目可以继续进行;反之，就要判断，是质量计划制定得过高，抑或是具体的执行工作还有待改进以及怎样改进。
上述这两项工作实际上都是反馈控制(即事中控制)，即在软件开发项目的执行过程当中对开发工作的绩效进行判断。电信行业的市场特征使得电信行业的软件项目具有较大的不确定性，采用事前控制的策略是较为困难的，而事后控制策略对于当前正在进行的项目并没有太大的实际价值，若当前的软件项目在执行过程中已经产生成本浪费，使用事后控制策略不能及时发现问题进而采取措施。因此，在质量控制工作当中应该采用反馈控制策略对各项工作进行合理的规划。
hyc.bjufida.com 在上述内容中已对怎么管理软件项目质量评价和软件项目质量如何评估的内容作出了详细的解答，内容对于您解决ERP软件相关问题一定有帮助。
