论软件项目的质量管理

一、基于对软件质量管理的认识与分析

　我认为，影响软件质量的因素有很多，通常有：人的因素、软件需求、质量问题可能出现在开发过程的各个环节上、测试的局限性、质量管理的困难、质量管理未能给予足够的重视、软件人员的传统习惯、开发规范、开发工具的支持不够等。对于象石化加油卡工程的核心软件之类的大型软件，涉及平台多，开发环境多，开发人员庞大，在全国尚无大规模的同行业省级应用模式可以参考。因此，我认为软件要能够恰合需求是最为首要的质量因素；其次，对于庞大的开发人员，对他们培养和树立软件质量意识，按软件工程标准规范开发流程，因此，质量管理和开发过程控制也十分重要；再次，该核心软件庞大、复杂、功能多、子系统多、接口多，我认为，要在软件开发生命周期内重视软件测试也至为关键。

目前，在业界影响较深的McCALL质量模型、ISO软件质量评价模型以及SSC软件质量度量模型，都比较共同地列举了软件的质量特性，如正确性、可靠性、完整性、优化与效率、可维护性、可测试性、容错性、文档完备性、复用性、健壮性等等，要想使提交的软件在各项指标方面具有较高的性能和度量指标，在软件开发过程中，须采用切实可行和有针对性的措施方可达到要求。以下结合我工作中针对提高石化加油卡核心软件质量谈谈具体的管理策略、思维和做法。

二、具体实施的管理策略及做法

1、质量管理策略的展开与实施

首先，我向公司的决策层强调了软件质量的重要性，并提交了具体的实施办法。从组织上，我公司成立了软件质理管理领导小组，下设办公室，有2名专职质量管理人员，我作为办公室主任。最主要开展了公司的集成资质认证和ISO9001软件开发质量认证的取证工作，并最终获得成功，同时开展了全体开发人员的软件质量意识教育，对开发人员进行了系统的软件工程软件工程开发规范和相关标准教育。这些工作都是全员行动，涉及到的每个部门、每个开发小组以及个人，都要按照质量管理规范要求开展各自的工作，这也是开发工作的基础准备工作。

2、高素质软件人才战略

我始终认识到软件行业中人才的重要性以及人才在软件质量的重要作用，通过各种渠道，我们招聘了大量高素质人员，但要使其发挥工作积极性，激发其工作热情和责任感，通过我的努力和建议，人事部门制定了比较公平、公正、有效率的薪金激励体系，例如建立了将开发人员分为系统分析员、高级程序员、程序员等五档次十个级差的工资体系，人员可达月薪25000元/月，最底为2600元/月，同时给予人员以晋升和发展的空间，由于软件开发行业的特殊性，我们还十分重视人员素质提高与技术学习和交流，积极提倡和鼓励人员参与中软考和各类认证考试以及职称评审，这样在公司内形成了十分良好的积极进取向上的科研与学习气氛。

3、系统分析方法与模型选择、开发平台的选择以及中间件开发平台的引入

对于石油销售行业，需求并不经常变动，只是各地的需求和销售策略有所不用，我认为宜采用传统的结构化分析方法为主，结合面向对象的分析方法，在需求分析前期，以结构化分析方法，摸清系统的原有业务流程以及数据流，在设计阶段，在充分理解需求规格说明书的基础上，应采用面向对象的分析与设计方法，这样方可提高软件的可靠性、复用性、可维护性等，也就提高了软件的质量。在开发平台的选择上，由于加油卡清费数据量巨大，首先是基本大型关系数据库的应用，我们选择了SYbase，开发工具采用了DELPHI　6、cylix分别用于WINDOWS平台和LINUX平台的开发，由于整个系统是采用集中式基于网络的应用，充值发卡为联机交易而加油站加油卡数据是在油站产生通过拨号上传的。为了保证操作事务的完整性，解决异构和跨平台的困难，采用了现今流行的中间件(BEA TUXEDO)开发技术，利用交易中间件实现联机交易，利用通讯中间件解决加油站数据上传，通过中间件中的两阶段提交技术，合理地利用了网络带宽，不至于与联机交易相冲突，也保证了网络不易拥塞而使数据不能上传。

另外，我们还采用了各类CASE工具，用于软件的建模、文档管理、版本管理、方案演示等。

4、收集需求的多种做法

在软件从分析到编码设计以及测试的全过程，我们反复采用了"请进来、走下去"的做法，即分析和开发人员一定要亲临业务现场，切身体会其中的业务操作，我们甚至要求与他们与业务人员打成一片，我们称之为走下去，目的就是为了更准确地把握需求。在开发时系统有了初步的软件原型后，我们又将各地石油分公司的专业人员、业务人员请过来，请他们谈谈对新原型的看法和意见，并按照他们的意见再次对开发工作进行修正，我们称之?quot;请进来"，目的是使确保软件提交后能尽快地获得用户方满意。这个过程，是循环反复，螺旋演进的，通过这个过程，我们的软件逐步达到了功能丰富、操作简便易用、运行效率高、速度快的高质量要求。据我们不完全统计，我们采用的"请进来，走下去"的做法涉及到数百个人次，参与分析与开发的人员不但结交了很多朋友，而且也切身体会到这种做法对保证软件质量的重要之处。

5、基于"应用微内核"模块的可扩展开发模式和思维的全面贯彻

虽然系统庞大，我们认为软件中最为基础的是加油IC卡的核心支付模块，是整个系统核心的核心，我称之为大系统的"应用微内核"，是其他系统的数据源，其他模块如清算结算子系统、油站零售管理与数据分析子系统，都是基于其上的扩展开发。因此，我要求，在核心级应用内核采用最为严格的软件工程开发规范，并在其中留有足够的数据库的表中的数据元（字段），以便应付多需求情况以及将来需求的可变性，这样，可使应用内微具有较大的灵活性。例如，加油站累计消费优惠，在各市公司采用不用的优惠措施，有的是累计积分奖励礼品，有的是累计现金，各地分公司由于经营上的需要，还执行了不同的油品价格政策，利用应用内核中的扩展字段很方便即可解决这个各地不同需求问题。应用微内核的采用还为其他系统提供了清晰的接口，例如，石化系统目前是正在作ERP软件的试点，该软件作为ERP底层数据源，十分方便地溶入了ERP系统中。微内核还提高了系统的运行效率，微内核代码经过了系统中最为严格的测试，有的模块和代码段一般都经历了四版以上才定稿，有的甚至在经历了十次以上的版本。我们还在开发前开展了较为有趣的编程优化大赛，谁的程序效率高、算法优、速度快，就选其中的人员参与到微内核开发组，并在薪水和奖金给予这些人员适当的上浮。

6、加强测试

为了提高软件质量，我们还十分重视软件的测试工作，成立了专业的测试小组，用于测试开发的软件和厂商提交的加油机卡机联动样机、消费POS、充值POS等，由于为全行业工程，中国石化统一了加油IC卡卡规范、重新修订了加油机通讯协议，这些都需要进行测试，方可准予厂商进场作业，为此开发部门还编制了相关的测试软件，通过测试后，方可发证与厂商。对核心软件，除了我们内部进行单元测试和集成测试和初步系统α测试外，我们还委托中国计算机软件测评中心这样的专业测评机构进行最终确认测试。在试用版投入试点过程中，我们还与各地石油分司共同建立了测试维护制度与维护操作办法，落实了具体人员，收集了大量测试数据，全面地进行了β版测试，此举也从运行现场发现了很多开发环境下所没有发现的问题，对提高软件质量起到了重要的作用。

三、完成的效果与评价

加强软件质量管理的做法还有很多，对其中的一些细节本文也不再讨论。如上所述，其做法基本上源于我参与多年的软件开发项目和项目管理的经验所得，当然在这个项目中我们也有所创新，如"应用微内核"的开发思想和思维的实施。这些做法从总体上保证了软件的高质量。当然，质量管理的内容与做法也要与时俱进。

但由于自己不是公司的决策层，仅负责软件技术方面的工作，对部分骨干人员的出走以及因项目各方利益的关系，从而影响了软件的开发和进度也无能为力。从这个项目来看，软件的开发仍然是整个工程推进的瓶颈，其开发进度与提交对整体加油卡工程进度影响很大，传统的软件开发问题在这个项目中也依然遇到。近些年来，软件行业的CMM认证较为流行，可使公司软件过程能力成熟度得到较大提高，我想这也是将来在软件质量方面的努力之处。总之，对于软件项目开发，人的作用和质量管理的作用都十分的重要，我也期待着在将来能不断提高自已的技术与管理水平，也能够希望更多的专业人员投入到软件质量管理的研究中来，为提高我国软件产业的软件质量而奋斗。

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以限度的减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。

　在项目风险管理中，存在多种风险管理方法与工具，软件项目管理只有找出最适合自己的方法与工具并应用到风险管理中，才能尽量减少软件项目风险，促进项目的成功。

　项目风险管理

　项目风险管理是指为了的达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险管理的目标是使潜在机会或回报化，使潜在风险最小化。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控，如图1所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生命周期内，风险识别是一个连续的过程。

　（1）风险识别：风险识别包括确定风险的来源，风险产生的条件，描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次就可以完成的事，应当在项目的自始至终定期进行。

　（2）风险量化：涉及对风险及风险的相互作用的评估，是衡量风险概率和风险对项目目标影响程度的过程。风险量化的基本内容是确定那些事件需要制定应对措施。。

　（3）风险应对计划制定：针对风险量化的结果，为降低项目风险的负面效应制定风险应对策略和技术手段的过程。风险应对计划依据风险管理计划、风险排序、风险认知等依据，得出风险应对计划、剩余风险、次要风险以及为其它过程提供得依据。

　（4）风险监控：涉及整个项目管理过程中的风险进行应对。该过程的输出包括应对风险的纠正措施以及风险管理计划的更新。

　每个步骤所使用的工具和方法详见表1：

　表1 风险管理过程中所使用的工具、方法

　软件项目中的风险管理

　1、软件项目中的风险

　软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IT项目开发中常见的风险有如下几类：

　（1）需求风险

　①需求已经成为项目基准，但需求还在继续变化；

　②需求定义欠佳，而进一步的定义会扩展项目范畴；

　③添加额外的需求；

　④产品定义含混的部分比预期需要更多的时间；

　⑤在做需求中客户参与不够；

　⑥缺少有效的需求变化管理过程。

　（2）计划编制风险

　①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；

　②计划是优化的，是"状态"，但计划不现实，只能算是"期望状态"；

　③计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；

　④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；

　⑤完成目标日期提前，但没有相应地调整产品范围或可用资源；

　⑥涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

　（3）组织和管理风险

　①仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；

　②低效的项目组结构降低生产率；

　③管理层审查 决策的周期比预期的时间长；

　④预算削减，打乱项目计划；

　⑤管理层作出了打击项目组织积极性的决定；

　⑥缺乏必要的规范，导致工作失误与重复工作；

　⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

　（4）人员风险

　①作为先决条件的任务(如培训及其他项目)不能按时完成；

　②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；

　③缺乏激励措施，士气低下，降低了生产能力；

　④某些人员需要更多的时间适应还不熟悉的软件工具和环境；

　⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；

　⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；

　⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；

　⑧没有找到项目急需的具有特定技能的人。

　（5）开发环境风险

　①设施未及时到位；

　②设施虽到位，但不配套，如没有电话、网线、办公用品等；

　③设施拥挤、杂乱或者破损；

　④开发工具未及时到位；

　⑤开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；

　⑥新的开发工具的学习期比预期的长，内容繁多。

　（6）客户风险

　①客户对于最后交付的产品不满意，要求重新设计和重做；

　②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；

　③客户对规划、原型和规格的审核 决策周期比预期的要长；

　④客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；

　⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；

　⑥客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

　（7）产品风险

　①矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；

　②开发额外的不需要的功能(镀金)，延长了计划进度；

　③严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；

　④要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；

　⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；

　⑥开发一种全新的模块将比预期花费更长的时间；

　⑦依赖正在开发中的技术将延长计划进度。

　（8）设计和实现风险

　①设计质量低下，导致重复设计；

　②一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；

　③代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；

　④过高估计了增强型工具对计划进度的节省量；

　⑤分别开发的模块无法有效集成，需要重新设计或制作。

　（9）过程风险

　①大量的纸面工作导致进程比预期的慢；

　②前期的质量保证行为不真实，导致后期的重复工作；

　③太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；

　④过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；

　⑤向管理层撰写进程报告占用开发人员的时间比预期的多；

　⑥风险管理粗心，导致未能发现重大的项目风险。

　2、软件项目风险管理模型

　针对软件项目中的风险管理问题，不少专家、组织提出了自己的风险管理模型。主要的风险管理模型有：Boehm模型，CRM模型和SERIM模型。

　2.1 Barry Boehm模型

　模型：RE=P (UO)*L (UO)

　其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。Boehm思想的核心是10大风险因素列表。针对每个风险因素，都给出了一系列的风险管理策略。在实际操作时，Boehm以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此类推。考试大收集

　2.2 SEI的CRM(Continuous Risk Management)模型

　SEI CRM模型的风险管理原则是：不断地评估可能造成恶劣后果的因素；决定最迫切需要处理的风险；实现控制风险的策略；评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和管理，它将风险管理划分为五个步骤：风险识别、分析、计划、跟踪、控制。

　2.3 SERIM(Software Engineering Risk Model)模型

　SERIM从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。它还提供了一些指标和模型来估量和预测风险，由于这些数据来源于大量的实际经验，因此具有很强的说服力。

　结束语

　软件项目管理从某种意义上讲，就是风险管理。我们尽量去定义明确不变的需求，以便进行计划并高效管理，但商业环境总是快速变化的，甚至是无序的变化。所以，软件企业在进行项目管理的过程中，必须采用适合自己的风险管理方法进行风险管理，以确保软件项目在规定的预算和期限内完成项目。