第5章   项目质量管理案例

质量是“使实体具备满足明确或隐含需求能力的各项特征之总和”，明确或隐含的需求是指按项目需求制定的基础性文件。在信息系统项目中，一般把《系统需求规格说明书》作为项目需求的基础性文件。

质量管理作为项目管理的一部分，具有非常重要的地位。质量管理的目的是通过执行项目质量管理过程，使用一些基本项目管理工具和技术来保证信息系统的质量。时间、成本、质量是项目管理的三大目标，如果质量不能满足要求，即使进度再快，成本再节省，项目也没有意义。

5．1 案例一：计划及跟踪

阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题1至问题3。

5.1.1 案例场景

某银行信息系统工程项目，包含省级广域网工程、储蓄所终端安装工程、主机系统工程、存储系统工程、备份系统工程、银行业务软件开发工程等若干子项目。此工程项目通过公开招标方式确定承建单位，希赛信息技术有限公司(CSAI)经过激烈竞标争夺，赢得工程合同。合同约定，工程项目的开发周期预算为 36 周。

由于银行对于应用软件质量要求很高，CSAI 也非常重视工程质量，安排有资深资历的高级工程师张工全面负责项目实施。在工程正式开工之前，张工对工程项目进行了分解，根据工程分析，张工认为此工程项目质量、进度的关键在于银行业务定制应用软件的开发。除工程整体的开发计划外，张工还针对应用软件开发制定了详细的开发计划，定制应用软件的开发周期为 36 周。网络工程、终端安装工程、主机系统工程、存储系统工程、备份系统工程等与应用软件开发并行实施。

张工对工程项目在需求分析、概要设计、详细设计、编码、单元测试、集成测试等各个环节要求均非常严格。根据张工安排，需求分析、概要设计均安排有多年工作经验的高级软件工程师担任，各个阶段的阶段成果均组织了严格的评审，以保证各个阶段成果的质量。

在软件编码及单元测试工作完成之后，张工安排软件测试组的工程师编制了详细软件测试计划、测试用例，包括集成测试、功能测试、性能测试、安全性测试，等等。

张工在安排软件测试任务的时候，在动员软件开发小组时宣讲： 软件测试环节是软件系统质量形成的主要环节，各开发小组，特别是测试小组，应重视软件系统测试工作”。因此，张工安排给测试组进行测试的时间非常充足，测试周期占整个软件系统开发周期的 40%,约 14.5 周。在软件系统测试的过程中，张工安排了详细的测试跟踪计划，统计每周所发现软件系统故障数量，以及所解决的软件故障。根据每周测试的结果分析，软件系统故障随时间的推移呈明显的下降趋势，第 1 周发现约 100 个故障，第 2 周发现约 90 个故障，第 3 周发现 50 个故障，……，第 10 周发现 2 个故障，第11 周发现 1 个故障，第 12 周发现 I 个故障。于是张总工断言软件系统可以在完成第 14 周测试之后

顺利交付给用户，并进行项目验收。

【问题1】请以 300 字内回答，张工的软件开发计划中是否存在问题？为什么？

【问题2】请以 200 字内回答，张工根据对定制软件系统测试的跟踪统计分析结论，得出项目可于计划的测试期限结束后达到验收交付的要求，你认为可行吗，为什么？

【问题3】请以 300 字内回答，若你是本项目的总工，你将怎样改进工作，以提高软件系统开发的质量，保证工程项目按期验收？

5.1.2 案例分析

过去，很多 IT 集成公司所承建的定制软件工程项目，当进入到验收阶段的时候，用户常常拖延，或找这样那样的借口不给承建单位验收，这是什么原因呢？针对这个问题，建设单位、承建单位都有一定责任。对于建设单位来讲，由于建设单位对信息系统建设认识上的局限性，对软件系统质量鉴定的困难性，建设单位存在着对定制软件系统的质量的担心，因此，很难果断地做出验收项目的决定。

而对于承建单位来讲，承建单位在项目质量管理方面常常做得很不到位，比如：该提交工程实施计划、工程实施计划进度跟踪记录、工程概要设计书、详细设计书、应用系统配置文件、用户手册、培训资料等若干文档的时候没有提交，而很多承建单位在项目验收时，根本看不到这些文档，或即使有文档，但也极其不规范，文档质量很低。再比如：曾有个信息系统工程项目在提交用户验收的时候，有一台防火墙散乱地摆放在机柜外面，再看机柜上面所布放的通信线缆，显得杂乱无章，承建单位也没有意识到这个问题，用户虽看在眼里却不提醒承建单位，那请问，用户会给这样的项目进行验收吗？

通过硬件所表现出来的表面质量是很容易发现的，但对于软件系统的质量的衡量却是非常困难的，特别是对于那些对软件系统认识不够深入的 IT 系统建设单位，他们面对 IT 项目的验收，常常显得很谨慎也是可以理解的。

信息应用系统项目的质量保证与承建单位的质量保证体系是密切相关的，但并不等于承建单位有质量保证体系，如通过了 ISO9000 认证，或通过了 CMM3, CMM4 等认证，就一定能够保证 IT 项目的质量。承建单位的质量保证体系是一个大纲性质的，但实施项目的是项目小组，项目小组不能很好融合到承建单位的质量保证体系中是比较常见的现象，因此，为有效保证项目的质量，项目小组应当向建设单位或监理单位提交项目的质量保证计划。质量保证计划是在承建单位质量保证体系下编制的，是针对项目特点的，涉及保证项目质量的具体措施，更易于操作。当然，一个项目的质量保证计划如果照搬到另外一个项目，却不一定适用。而建设单位、监理单位可以通过对承建单位质量保证计划的执行情况来判断其软件开发过程的质量，从而协助对定制软件产品质量的鉴定。

【问题1】

软件测试是保证软件质量的重要工作内容之一，但软件测试环节却不是软件质量的形成环节，测试只能检查软件中所存在的缺陷，发现问题。软件质量是在需求分析、设计、编码、测试、文档编制等软件生产的全过程中形成的。因此，我们要了解定制软件系统的质量，就必须了解承建单位开发软件系统的全部过程的质量。

测试计划和测试用例应当在软件的设计阶段制定。越晚进行的测试，其测试计划的编制时间就越早。如集成测试计划在概要设计阶段编制，功能确认测试计划在需求定义阶段就应当制定，整体测试计划也应当在需求分析阶段制定。

虽然我们在实践中有很多这样的情况，很多软件开发团队并不是在软件设计阶段同步制定软件测试计划和测试用例，甚至有很多软件开发中根本就没有制定规范的测试计划和测试用例。但这些并不是正统、规范的做法，这样的软件工程过程对于保证定制软件系统的质量来说是会打折扣的。

若测试计划的编制时机不能按照规范进行，那说明软件企业的过程能力成熟度还不够，还是在采用手工作坊方式生产软件，想到哪里做到哪里，没有计划或计划不科学，不能有效地控制软件生产的质量。

【问题2】

软件系统的质量，仅仅根据测试的结论来进行断言是不够的。我们在进行项目开发计划安排的时候，应当将系统的试运行也安排在计划之内。系统的试运行牵涉到工程项目的建设方和承建方，除了技术方面的因素外，还涉及组织方面的因素，人文方面的因素等。承建方要安排足够的时间与建设方协商系统的试运行问题，在双方的配合下开展系统试运行工作，系统在试运行中，通常还会发现大量的故障，承建单位也必须配合解决这些系统故障。只有通过试运行的考验，才能够基本断定系统的质量是否符合要求；通过了试运行的考验，再向用户提出工程项目的验收，一般来说，用户的接受程度会比较高。

软件系统的试运行为什么如此重要呢？这是根据不同的工程项目的特点，如公路建设就不需试运行，住宅建设也不需试入住，通过质检方式就可确定工程项目的质量。而另外一些工程项目则是必须要进行试运行的，比如铁路系统建设、水电站建设、化工厂建设等，这些类型的工程项目，不通过试运行，就不可能鉴定其质量，信息应用系统的建设也是一样。

【问题3】

另外，在向用户提出项目验收前，还得整理并提交完整的工程技术文档、系统维护文档、软件配置清单，给用户举办系统操作培训、维护培训，全面审核合同执行情况，编制项目竣工报告，等等。如果项目小组不注意这些工作，用户大多也不会来提醒你，用户只卡住验收关不让通过就可以了，当然也有部分用户可能会提醒项目小组离验收还差什么。毕竟项目的实施任务是属于承建单位的工作，承建单位理应完善自身的项目管理水平，不可能让用户来督促你、提示你，那不是用户的职责，更何况，很多用户自身也不知道 IT 项目该怎样管理，有哪些工作需要完成，但承建单位很多不规范的做法、存在的问题，让用户对质量不放心，用户却是能够觉察到的。特别要注意的是，项目经理在计划项目验收时，应当与用户的主要领导充分沟通，让客户领导了解项目的建设过程，了解项目的质量实施情况，让领导对项目的验收充满信心。

但请仔细分析本题，案例场景中通篇并没有提到关于工程文档、配置清单、培训等话题，这些内容并不是本题的关键，未提及的内容，张工可能没做到，但也可能做到，不好断言。我们只要能够抓住场景所描述的张工的主要缺陷，一是制定测试计划的时机不对，二是根据测试断定软件系统的质量不对，只要能抓住这两点就够了。其他的内容，也可以反映在答案中，但要注意语言要简练，虽不会导致扣分，但也不是得分的要点。

5.1.3 参考答案

【问题1】

张工安排测试计划的编制时机不对。测试计划和测试用例的编制应当与软件系统的概要设计、详细设计同步进行。

测试计划不够全面，还应当包含系统整体测试、运行测试。运行测试是对应用软件系统整体功能的全面检验，也是最能够说明软件系统质量的测试环节。

系统测试计划、确认测试计划应当在需求分析阶段制定，测试用例、测试说明应当在概要设计阶段制定。

集成测试计划应当在概要设计阶段制定，测试用例、测试说明应当在详细设计阶段制定。

单元测试计划应当在详细设计阶段制定，测试用例、测试说明应当在编码阶段制定。

【问题2】

在定制软件开发项目中，根据测试结果判定软件系统的质量是不够的，因为软件系统中的缺陷可能由于多种原因而未在测试中被发现，如测试环境与运行环境的区别、测试人员的能力问题、测试计划和测试用例的局限及缺陷。

由于软件系统质量、功能、性能具有很强隐蔽性的特点，用户往往不大可能根据项目开发小组的测试结论来进行项目的验收。最好让用户组织对项目进行试运行，以试运行的结论来作为验收的依据之一是比较有说服力的。

【问题3】

 (1)在进行需求分析的时候，同步制定功能确认测试计划和测试用例，同步制定系统整体测试计划和测试用例。

(2)在进行软件系统概要设计的时候，制定集成测试计划和测试用例。

(3)在进行软件系统详细设计的时候，制定单元测试计划和测试用例。

(4)在项目计划验收日期前，提前与用户协商系统试运行计划，并给用户进行充分的培训，包括领导和一般操作人员，让系统接受实际运行的考验，在试运行过程中暴露出来的问题，及时进行解决。以软件系统实际运行所表现出来的功能、性能来说服用户对项目进行验收，这通常是更可行的方法。

5.2案例二：团队协作

     阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题 1 至问题 3。

5.2.1 案例场景

重庆市某行业关键应用 IT 系统(A 系统)的建设工程由希赛信息技术有限公司(CSAI )中标，CSAI是国内一家大型 IT 系统集成商，企业通过了 ISO9000 质量体系认证和 CMM3 级认证，对信息系统工程建设有着比较成熟丰富的经验。

CSAI 总部设在长沙，有软件研发中心。CSAI 为 A 系统建设所组建的项目小组由两个部分组成：一是总部长沙负责进行软件开发工作；二是重庆现场负责进行信息系统的本地化实施，本地化实施的内容包括网络系统建设、主机系统安装调试、应用软件的运行环境建设、现场测试、客户需求跟踪、客户关系协调等。其中，应用软件开发的管理工作由长沙软件中心负责，A 系统的配置管理工作由现场负责。

CSAI 对 A 系统应用软件开发的控制非常严格，可是，由于 A 系统在实施的过程中，用户不断地提出新的需求，催促要 CSAI 满足，而且，A 单位的领导对进度非常关心，经常突袭检查，要求CSAI 演示所建设的应用系统的功能。CSAI 现场项目经理李工也试图通过与用户进行沟通，以求解决需求的频繁变更问题，解决用户对进度的要求等。

CSAI 对现场项目经理有关于维护良好客户关系的绩效考核指标，因此，李工不敢怠慢客户所提出的要求，但为了达到 A 用户所提出的需求变更、进度变更，李工想方设法让长沙研究所满足客户的需求变更，这样，长沙研究所的软件开发工作量就大大增加，而且，常常赶不上客户对项目进度的要求。

在寄托于总部无望的情况下，李工为了在工程进度方面满足用户的愿望，于是决定将部分应用软件系统代码在现场进行开发。现场开发的目的主要是加快了软件开发的进度，李工的决定也确实很奏效，大大加快了应用软件开发的进度。但是，当应用软件系统投入运行后，系统故障的发生频率却非常高，经过对故障的分析，李工发现，这些故障当中，由现场所开发的软件与长沙总部所开发的软件在协同工作中所暴露的问题尤为普遍，比如，现场所修改的软件代码，在长沙总部下发统一版本软件的时候常常被替换而丢失功能，A 应用系统的本地化功能太多太偏而很难与统一版本融合。

另外，由于现场抽调人员参与应用软件开发，现场本应做的配置管理工作也被耽搁了，如网络系统的配置(设备访问权限、路由、IP 规划等)、主机访问权限规划、应用系统访问权限规划、应用环境参数规划等，这些现场运行环境参数，按照 B 公司的管理制度，是应当编制文件存档的，但李工却没有安排人员来做这些工作。

由于网络系统庞大，中心机房设备繁多，参与工程建设的人员按照各自的习惯进行系统的配置，这样，在工程投入运行后，由于各部分配置的不规范，常常引起局部配置的变更给系统运行带来严重事故。曾经在一次配置变更过程中，由于应用系统密码的修改，导致系统停止业务半天，给用户造成了严重的损失和不良影响。

【问题1】请以 300 字内回答，李工对所遇到的问题的处理方法是否恰当。李工所做出的决定的主要缺陷是什么？造成问题的原因主要是什么？

【问题2】请以 300 字内回答，团队协同工作时，在软件版本方面会造成哪些问题，应当采取什么措施以避免问题的出现？

【问题3】请以 300 字内回答，在 IT 应用软件开发工程中，怎样进行项目现场与总部软件开发团队的有效配合？

5.2.2 案例分析

CSAI 虽然通过了 CMM3 级认证、ISO9000 认证，但 CSAI 的管理工作未必就能按照规范来开展，有不少公司只是将这些认证作为投标竞争时的砝码而已。因此，我们在建设工程项目的时候，不但要看 IT 系统集成商具不具备这些认证，还应采取有效的手段考核 IT 系统集成商的质量保证计划。

对 IT 系统集成商进行考核，简便可行的方法就是让集成商在项目开工前提交质量保证计划，并对质量保证计划进行评审，通过后要求集成商严格执行。通常，过程能力成熟度高(指实际)的 IT 企业，在实际工程与质量保证计划之间的一致性会完成得较好，而过程能力成熟度低的企业(指实际)，实际工程与质量保证计划之间的一致性会完成得相对较差。

【问题1】

我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程项目的三大目标。通常与客户接触最多的是现场项目经理，引导客户需求对项目经理就非常关键，项目经理引导得好，项目的开发就会非常顺利，反之，就会使项目组疲于奔命。优秀的项目经理是既能够让项目组成员“睡大觉”，又能保持良好的客户满意度。

CSAI 项目经理李工与用户的沟通存在问题。善于沟通的人，一言明百理；不善于沟通的人，百言不明一理。项目经理与客户的沟通，不是指项目经理善于说话，善于高谈阔论就能够解决问题，更为关键的是项目经理要具备足够的引导项目建设的能力。作为现场项目经理，不是只做一个传话筒，客户说什么就是什么，而是应当与客户进行深入交流，深入分析客户所提出的问题，合理引导客户的需求，要有主见。

李工在 CSAI 进行客户满意度考核，客户又有大量需求的前提下，显得无所适从，手忙脚乱，而做出了不合适的决定。一是客户的需求，只要我们能够合理引导客户，客户的需求变更不可能有那么频繁，有很多需求变更是可以让用户暂时放弃的，或有的需求变更可以让用户在另外的工程项目中去实现，比如建议用户建设=期工程。我曾经见到一位项目经理在一个工程项目中，客户提出了一个需求，项目经理安排组员加班三天三夜完成了，告诉客户方主任，客户主任大吃一惊，说：“我并没有要求你们实现这个需求啊，我只不过向你们咨询一下而已”。

客户与我们的项目经理交谈，并不是都谈需求，有很多时候，客户可能是谈到自己的想法、心得体会、建议等。客户方面也往往有很多员工，一位员工有一种思想，十位员工就有十种思想，要统一这十种思想，项目经理就得付出更多的努力，要与用户方面的主管人员达成一致，而且，很多时候是必须要用户的主管人员去统一他们的意见。否则，应用系统的开发就存在很大制约因素。很多项目经理面对公司客户满意度的考核，面对客户无休止的需求，常常不能采取正确的应对方法，该说的不敢说了，该讲的不敢讲了。应用软件工程在建设阶段，优秀的项目经理应当是能够引导用户思路的项目经理，而不是让用户领导项目经理的项目建设思路。项目经理应当知道，任何一个客户都更注重项目建设的结果，在项目建设的过程中，项目小组与建设单位之间可能存在着很多次交流，甚至争论，但只要我们能确保项目建设的结果让用户满意，用户是终会给予好评的。

【问题2】

二是对 CSAI 资源的利用不当，李工把本不属于现场的工作内容，让现场工程师来完成是严重的失误，现场工程师仓促上阵，没有纳入 CSAI 统一的软件开发质量管理体系。虽然能够临时快速解决问题，但也会埋下故障隐患，而故障隐患的爆发却是在工程建设的后期。这种做法只能让员工疲于奔命。在项目管理中，如果项目组成员总是处于应急、救火的状态，是不可能高质量地完成工作任务的。作为项目经理，不但要关心项目的进展，还应当关心自己的成员，要让项目小组成员在高效率、高质量的状态下工作。

三是忽略了现场应该做的重要工作，应用系统的配置管理工作对现场来说是很重要的。混乱的配置管理，也会导致系统运行中发生严重的质量问题。

即使李工非要在现场进行开发不可，那也应当自觉地将现场所开发的软件，与公司总部所开发的应用软件进行统一的管理。特别是要注意，现场开发的缺点是对需求的把握太随意，由于开发人员与用户直接接触，用户的想法可能有很多偏激的成分，也容易被现场开发人员设计到应用软件系统中，从而导致现场版本与统一版本难以融合，特别是对有些需求的满足，可能涉及到软件系统体系架构的变更，这样就更难处理了。而现场临时决定的软件开发，管理工作怎样和总部的管理工作融合到一起，项目经理是应当考虑的，要么是由总部来控制，要么是现场自觉与总部配合。

【问题3】

我们在工程现场实施的时候，对于所遇到的系统问题，有的是能够迅速解决的，也有暂时无法解决的。对于暂时无法解决的问题，我们常常采取迂回的方式绕过去，以保证工程项目的进度。但是对于应用软件系统的开发来说，现场不能只是绕过去而已，还应当及时向总部报告，应当建立一个系统故障管理平台，记录所有发现的软件故障，逐一报告研发中心进行解决，并跟踪解决情况。

为有效解决现场与总部的配合问题，可以建设一个基于 Internet 的开发管理平台，现场所遇到的问题，及时汇报到管理平台，由总部管理人员分配解决。现场也可通过管理平台主动与总部沟通软件开发问题，协调一致，避免总部统一版本更新时丢失现场所开发的功能。

配置管理也是涉及到工程质量的。我们做企业级的应用系统，都应当考虑到系统割接的平滑性，配置变更的平滑性，在进行配置规划的时候就应当考虑配置的变更怎样才能实现平滑过渡，否则，就很可能使运行的系统在进行配置变更的时候进入瘫痪状态。而良好的配置管理，又是实现配置变更平滑过渡的有力支持。

5.2.3 参考答案

【问题1】

现场用户的需求是不可能有尽头的，但作为项目经理要能够把握住用户的需求，特别是要合理引导用户需求，切不可让用户怎么说就怎么做。

积极响应客户需求要从多个方面着手考虑，不要只从技术上考虑问题，技术引导、合同变更、人力资源等各个方面都应当考虑。

临时的现场开发工作，大多数都不可能与公司总部的软件开发融为一体，而且管理工作常常是自上而下的，李工忽略了这点，顾此失彼，导致项目问题的发生。

造成项目问题的原因有以下几点：李工对需求把握随意；控制不严；李工与客户沟通不到位；李工没有向客户提交合理的进度计划，或没有按时提交进度报告；项目实施无计划，或计划不能得到客户认可，客户不满意。

【问题2】

团队协同开发软件时，很容易出现软件版本管理不善带来的软件系统故障。同一软件系统代码不能同时由多人进行修改。

项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障反复出现。

李工如果一定要进行现场开发，应当委托现场合适的人员，或亲自督促现场所进行的开发工作与总部所进行的开发工作在软件版本方面保持一致，处理本地过于偏激的需求要与总部协商一致的情况采取合理措施控制统一版本。

【问题3】

项目现场应明确自己的工作职责范围，要自觉与总部门形成密切的配合。

现场所做的开发，应与总部所做的开发纳入同一个软件版本管理。

当现场发现软件故障时，应当及时向总部报告。建立故障管理表，记录并跟踪软件系统故障解决情况。

建设一个软件开发交流平台，如基于 Internet 的管理平台，管理工程现场所提出的问题，调度、跟踪解决工程现场问题。

现场工程人员与总部人员应多交流，通过各种方式，如及时通信软件、电话、电子邮件等，必要时，可组织研发部给现场工程人员进行培训。

5.3案例三：质量与成本

 阅读以下关于信息系统项目管理过程中工程质量问题方面的叙述，回答问题 1 至问题 3。

5.3.1 案例场景

某行业省公司(A 单位)信息应用系统工程项目(A 项目)通过招标方式选择承建单位，希赛信息技术有限公司(CSAI 以 1800 万元的标底获得 A 项目工程合同。A 项目包含 1000 万元设备采购安装和800 万元软件开发费用。其中设备采购安装预计有 150 万元利润，CSAI 渴望通过 A 项目的建设能够获得 600 万元纯利润。

为了能够最大限度地获取利润空间，CSAI 在组建项目小组，制定工程费用预算的时候，尽力压缩工程费用预算。CSAI 安排刘工担任 A 项目的项目经理，刘工在对项目进行工作分解的基础上，制订了工程实施资源计划，编制了项目实施预算经费。根据刘工的预算，项目实施经费预算(人员工资、差旅费、会议费、行政管理费等)为 220 万元，其中人员工资占了很大比例，为 150 万元，CSAI领导在审核经费预算的时候，认为人员工资所占份额太大，CSAI 要求刘工将人员工资预算减少为120 万元，．并列入对刘工的绩效考核指标。

由于人员工资预算的减少，刘工面临两种选择，要么将招聘软件工程师的能力等级降低，要么减少项目组成员数量。李工在权衡利弊后认为，项目组员工工资高，容易引起公司其他部门的忌妒，工作不好开展，于是，刘工只能采取降低项目组成员工资的方法。为此李工所组建的项目小组有 8人没有达到李工预期的技术资质等级。

A 项目经过 18 个月(延期 3 个月)的建设周期，项目建设完成并交付用户使用。CSAI 也如愿以偿地获得了预期的利润，项目实施经费 190 万元，预提项目维护经费 60 万元(两年免费维护)，商务费用 50 万元，超期 3 月赔偿 A 单位 15 万元，CSAI 认为实现的利润 635 万元，已经达到了计划的目标。

项目验收交付使用后，CSAI 为项目维护配备 2 位工程师，每位工程师工资加管理成本共计 10万元/人年，其他辅助设备购置 10 万元/年。但是，A 项目的运行维护并不像 CSAI 想像的那样好，由于 A 项目定制软件的质量存在很多隐患、缺陷，如软件代码质量差，导致系统运行效率低；技术文件缺乏或文件与实际情况不相符，或技术文件纵向及横向对相应内容的描述不一致；这些问题使得 A 项目的维护工作难以高质量地开展，经常给 A 单位的业务开展带来不良的影响。A 单位要求CSAI 必须得保证系统运行，不能影响 A 单位业务的开展，否则 CSAI 将被追究法律责任。这样，CSAI 的两位维护人员长时间处于救火式工作方式，疲于奔命，仍然维护不好 A 系统，在 A 单位多次严厉追问后，CSAI 不得不增加一位熟练的软件工程师来配合 A 系统的运行维护。这样，CSAI 在两年的系统维护中，因增加一位工程师而多支出了 25 万元维护费用。

CSAI 在维护 A 系统的过程中，曾有一次，由于自己员工的失误，当然，A 应用软件系统中隐藏的缺陷也是导致问题发生的原因之一，使得 A 系统的运行瘫痪了。由于要应急修复 A 应用系统，A 单位付出了约 10 万元应急费用，CSAI 也付出了 8 万元应急费用。而且，由于系统的瘫痪，使 A单位的业务停止了一整天，给 A 单位造成了严重损失和不良影响，A 单位按照合同约定，向 CSAI提出了 50 万元索赔要求。

A 单位认为 CSAI 的软件工程过程能力存在问题，决定在新的工程项目的建设中，不再将 CSAI作为候选合作伙伴。

【问题1】请以 200 字内回答，CSAI 压缩项目的工资支出是否合理？压缩工资支出直接带来什么问题？

【问题2】请以 200 字左右回答，CSAI 所承建的 A 项目由于质量问题将直接或间接引起哪些方面的项目成本损失？

【问题3】请以 300 字内回答，如果你是此项目经理，你将怎样进行项目管理，以减少不良质量所带来的成本损失，你的决策又会遇到什么问题？

5.3.2 案例分析

近年来，6σ管理在 IT 工程中的应用讨论越来越多。在传统工业产品制造中，采用 6σ管理是很直观的，提高产品的质量合格率，降低废品成本。

在 6σ管理中常常用到这样的术语：“不良质量成本损失 COPQ(Cost of Poor Quality)”。它是指由于质量不良而造成的成本损失，或者说是由于我们没有“第一次就把事情做对、做好”而额外付出的成本。由于质量不良而造成的成本损失是十分惊人的，遗憾的是这部分成本往往不为人们所知。

COPQ 可以分为直观的和隐含的两大类，就像冰山一样，露在外面的是我们通常统计的那些由于产品或服务不良而造成的成本损失。比如：报废、返工返修、保修费用等，也就是质量成本统计中通常作为内部与外部失效成本所统计的部分。

但冰山还有隐藏在海面下的部分，这是我们通常不去统计或不为人们重视但又实实在在地存在于企业中的成本损失，它常常是由于我们工作上的错误或缺陷而造成的。隐含的 COPQ 包括：未准时交付的罚金、错误的发货单引起的额外成本费用、由于设计生产周期延长而增加的成本、库存积压、紧急订货而多付的费用、工程更改不到位引起的报废返工费用，等等。正像冰山一样，这些隐含的成本损失要比露出的部分大得多。

6σ管理关注的主题不只局限在降低生产过程的缺陷，不仅要消除产品与服务的不良质量，还要消除工作过程的缺陷，提高工作过程的质量和效益。要通过工作过程的改进和优化，降低这些直观的和隐含的成本损失，把“冰山”变为“金山”，使“更高的质量、更低的成本、更短的开发与生产周期，更好地满足顾客的要求”变为现实。

那么，在 IT 工程项目中，6σ是否有着管理上的指导意义呢？

【问题1】

要提高工程项目的质量，通常意味着承建单位得多投入项目资金，也同时意味着承建单位所得到的利润会减少。要承建单位拿出资金来提供工程项目的质量，绝大多数承建单位都不太愿意。但是承建单位如此“节约”，也在为“节约”付出沉重的代价。

在建筑工程中，偷工减料会直接导致工程的质量的降低。信息应用系统开发是以软件工程师智力劳动成果为主的，承建单位削减了工程工资总额，降低了项目小组成员的平均技能水平，也就相当于建筑工程中的偷工减料，绝大多知清况都会给工程埋下严重的质量隐患。定制应用软件是一种智力密集型产品，主要由软件工程师的智力劳动构成，因此，软件工程师平均技术能力的降低，实际上就已经降低了工程项目的质量。另外，信息应用系统工程的质量的隐蔽性是很强的，在工程建设过程中，在进行项目验收的时候，这些质量隐患不一定检测得出来，但在系统在运行的过程中，

这些质量隐患必然是要爆发出来。

压缩平均技能水平，将使软件项目开发的质量降低，工期延长，并且由于质量缺陷直接导致系统在维护阶段的维护费用急剧升高。如果压缩项目小组人员数量，确保项目小组平均技能水平，则由于在规定工期内完不成项目工作量，也将导致工期延长。

【问题 2】

在应用软件开发中，由于工程质量问题所带来的 COPQ,也表现在直接的损失和间接的损失两个方面，直接的损失容易理解，而间接的损失常常被大家忽略。

在 IT 应用软件项目开发的过程中应用 66，虽然当前暂时还没有找到定量的软件质量评价方法，但 6σ的定性管理思路是一致的。当然，我们在强调提高项目质量的时候，也不是片面地一味追求无限高的质量，片面地追求质量，只能是在成本、工期等方面的投入将非常高，从而导致承建单位和建设单位都无法接受的局面。我们所强调的提高工程项目的质量，降低 COPQ 那么，我们核算在项目建设中增加的投入和在系统运行维护的过程中所节约的成本，比较这两个成本谁轻谁重，综合权衡，以便进行高效的投资决策。

绝大多数项目的建设，当质量与工期，质量与成本产生矛盾而不能三者兼得时，一般都是采取保证质量，而牺牲工期和成本。假如我们为保证成本和工期而牺牲质量，那么所做出来的项目很可能是个废品，这样，给项目造成的损失就更大，那我们所节约的成本和抢回来的工期又有什么实际意义呢。在监理介入 IT 工程项目建设的情况下，监理如果发现工程项目建设质量存在问题，监理可以勒令承建单位停工整顿，其目的就是为了保证工程项目的建设质量。

现在的信息系统的建设，系统维护通常都是交给承建单位代理维护的，因此，承建单位所埋下的质量隐患，也必然要由承建单位承担一定的损失。

承建单位应转变观念，适当投入，提高应用软件系统的质量，降低系统隐蔽缺陷所导致的故障发生率。如果在项目开发阶段多投入，提高工程项目的质量，那么，项目投入运行以后，在运行中能够表现出更高的性能、稳定性、安全性、可靠性，进而，承建单位所投入到系统运行维护中的人力资源就可以大大节约，而且，承建单位表现给建设单位的形象、信誉也更好，建设单位在建设新项目的时候，就更倾向于选择这样有成熟过程能力、能够保证高质量建设工程项目的 IT 系统集成商作为继续合作的伙伴，这样的承建单位发展道路将越来越光明。

【问题3】

过去，我们也看到很多这样的 IT 系统集成商，在工程项目投标的时候，能够拿出一大堆认证出来，什么 ISO9000 认证，CMM 认证，各种工程师认证等。但是，过去有很多公司只是将这些认证作为投标竞争的砝码，而并没有实实在在地去改进企业的质量保障体系，没有认真去完善提高公司的过程能力，有的公司保留了一些工程师的认证，虽然证书还在公司手上，但工程师已经不在公司工作了。那么，请大家想想，如果我们只考察这些本本，而不考察其实力，又怎么样保证工程项目的建设质量呢？

在过去，由于我们国家在 IT 工程项目的建设管理方面制度不够完善，出现了一些问题，但信息产业部也在迅速完善我们国家的 IT 工程建设管理，监理制度的执行，必将为规范 IT 工程建设管理做出贡献。随着监理制度的推广，IT 承建单位也必然受到监理的约束。因此，IT 承建单位应当自觉提高公司的质量保障能力，提高应用软件开发过程能力成熟度，以保证高质量地进行信息系统工程项目的建设。

作为项目经理，应当据理力争，但要注意方法，因为这样也是有风险的，切不可因为项目建设而损害了与公司的关系。

5.3.3 参考答案

【问题1】

CSAI 压缩项目工资支出不合理。压缩工资支出必然导致压缩项目小组的整体能力或平均技能水平。如果压缩平均技能水平，将使软件项目开发的质量降低，工期延长，并且由于质量缺陷直接导致系统在维护阶段的维护费用急剧升高。如果压缩项目小组人员数量，确保项目小组平均技能水平，则由于在规定工期内完不成项目工作量，也将导致工期延长。

由于 B 公司不能按合同执行项目工期，将导致 A 单位(甲方)的工期索赔。

【问题2】

直接地，系统维护费用支出、项目延期的人员工资支出、重新设计编写测试代码的费用的升高，部分功能模块提前报废的损失增大。

间接地，未准时交付项目向 A 单位支付的罚金、维护阶段的应急维护成本、客户信誉丧失、隐蔽缺陷的对系统运行所构成的威胁、设计生产周期延长带来的费用增加、投产期推迟使 A 单位减少收入、时间耽误，等等。

【问题3】

据理力争，但请注意方法，保证工程项目资金到位。在项目正式实施之前，就应当与领导多沟通，求得领导的支持，从多个方面讲清楚怎样实现项目目标，应当实现什么样的目标，公司领导往往不是项目管理人员，对项目管理细节了解不多，因此，领导做出不合理的决定，项目经理也有一定责任。

在压缩工资总额的情况下，宁愿压缩人员数量，而不是降低平均技能水平。降低平均技能水平不能保证工期，还不能保证质量；而压缩人员数量虽无法保证工期，但质量还能得到较好保证。可是要面对公司舆论压力，高素质人员高工资，要与领导多沟通，获得领导支持。

5.4 案例四：项目外包

阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题 1 至问题 3。

5.4.1 案例场景

希赛信息技术有限公司(CSAI 得到国家创新计划资助，决定开发基于 Web 全国范围内的生态信息检索系统，项目由张工负责，时间 1 年。

项目开始实施后，张工发现该系统内容多，并且具有地域性，以 CSAI 的实力无法单独完成，所以张工把该系统按照地区分成若干子系统，由各地相关科研机构外包完成。外包时间 10 个月，开工预付款 20%，外包合同签订时项目已经开展 1 个月。在外包合同中，系统功能已明确说明，但是系统界面、风格、字体等细节没有具体说明。

外包子合同签订以后，张工由于工作繁忙等原因没有及时监督外包完成情况，只是上级在计划中期检查汇报时从外包单位抽取一些文档、代码和执行界面。

10 个月后，外包任务完成，提交到 CSAI 时，张工发现子系统的界面、风格、字体等内容不统一，所以希望这些外包单位按照统一风格修改子系统。但是外包单位认为合同中没有具体说明这些内容，只说明应该实现的功能，为此双方产生争执，半个月未果。张工只付 40％的外包费用，所以部分外包单位在子系统中加入时间锁，但没有通知张工，此时距离项目交工只有半个月时间。张工又重新组织人员进行系统集成，期间没有发现时间锁问题，最后草草完工。

投入使用后时间锁生效，系统出现故障。张工被上级领导批评，于是张工与相关外包单位交涉。最后张工交付 40％外包费用，时间锁解除，系统正常运转。

【问题1】请用 300 字之内，对 CSAI、张工、外包单位在这个项目开发中的行为进行点评。

【问题2】如果想提高软件产品的质量，从项目质量管理的角度，用 350 字内阐述张工应该采取什么措施。

【问题3】试结合自己的项目经验，讲述项目外包中如何避免风险，使得收益最大化。

5.4.2 案例分析

【问题1】

行为点评题一般是跟踪案例场景过程，弄清楚题目中各个对象在项目实施中所扮演的角色，然后将该角色应该具有的职能和案例中该对象的表现相比较，从中发现该对象的肯定之处和不足之处，从而进行点评。

本案例中，很明显，CSAI 是项目承办方，张工是项目经理，外包单位是项目外包方，可以据此结合案例进行点评。

在项目立项之前，CSAI 的可行性分析有误，高估自己的能力，承接一个无法单独完成、必须全部外包的任务，给项目实施带来极大风险；CSAI 用人不当，选择了一个不负责的项目经理张工，给后续事件发生埋下隐患，所以 CSAI 的人力资源管理制度存在风险，应该在人力资源管理各个环节，如招聘、考评、薪金管理、员工培训、员工管理等识别、规避和控制；CSAI 的管理机制不全，把张工任命为项目经理后，没有对项目进行及时监控，加上产品外包，风险比较大，所以项目质量不能得到保障，应该建立项目管理部(PMD)，制定项目整体质量管理章程和管理计划，定期监督项目的执行情况。

很明显，张工不是一个合格的项目经理，专业知识不够，没有及时识别项目中存在的风险，项目开展一个月，才发现不能完成，签订外包合同；阅历经验不足，通过外包规避风险是一个不错的方法．，但是签合同时没有明确系统一致性，使自己处于被动状态，对系统的一致性应该专门说明，因为一致性可以提高系统的质量，减少最后集成的工作量；职业道德水平差，系统分解后全部外包，已经使风险最大化，而自己在签订外包合同后很少过问，只是应付了事；沟通协调能力不够，自己的工作繁忙，无暇顾及项目的外包进展，应该给上级领导及时说清，这样可以使自己投入该系统中的时间多一些，更有利于保证系统质量。

外包单位没有得到全部款项，私自在系统中加入时间锁，使得系统最后出现故障，破坏软件完整性和安全性。外包单位通过设置时间锁来保护自己的利益的做法可以理解，但是这种做法属于严重违反软件行业职业道德的恶劣行为?，甚至还涉嫌违法犯罪；而且这种方式给科研机构 A 单位留下不好的印象，减少以后 A 单位和这些单位继续合作的可能性，因为企业寻找外包单位一般都是找有过成功合作历史的单位。

【问题2】

本题考查考生对项目质量管理流程的掌握。要想回答好该题，考生需要了解项目质量管理整体流程，尤其是质量计划、质量保证、质量控制三者的相互区别和关系。

项目质量管理过程包括执行组织关于确定质量方针、目标和职责的所有活动，使得项目可以满足其需求。它通过质量计划编制、质量保证、质量控制程序和过程，以及连续的过程改进活动实施来实现质量管理系统。

首先，应该编制质量计划，识别与该项目相关的质量标准并确定如何满足这些标准，因为决定软件质量的是计划和设计，而不是检查。为了实现该目标，需要进行成本/效益分析、基准分析、试验设计等。

其次，为了确保实际交付高质量的产品和服务，还应该联合相关质量部门执行质量保证。质量保证是一项管理职能，包括所有有计划、系统地为保证项目能够满足相关质量标准而建立的活动，如请求变更、组织过程资产更新、项目管理计划更新等，该活动应该贯穿整个项目的生命周期。从本质上讲，质量保证是对质量计划编制和质量控制过程的质量度量，项目经理和相关质量部门做好该工作，对提高项目质量非常重要。为了实现该目标，需要进行质量审计、过程分析、基准分析等。

最后，为了确定项目实施结果是否符合相关质量标准，还应该联合项目组和相关质量部门执行质量控制。通过质量控制，可以监督项目的具体实施结果，判断它们是否符合制定的项目质量标准，并确立消除产生不良结果的途径，该活动应该贯穿项目执行的全过程。从本质上讲，质量控制是确保项目质量得以圆满实现的过程，该过程包括项目产品的质量控制和项目过程结果的质量控制两部分，前者由相关质量部门控制，后者由项目组成员控制。为了实现该目标，需要进行检查、控制图管理、排列图管理、统计抽样、趋势分析等。

【问题3】

本题考查考生综合运用外包管理和风险管理知识的能力。要想回答好该题，考生需要了解项目外包本质和实施流程，外包中注意事项、常见风险及应对措施。

外包是企业利用外部专业资源为已服务，从而达到降低成本、提高效率，充分发挥自身核心竞争力，乃至增强自身应变能力的一种管理模式，同时也是现代社会非常重要的一种商业模式。但外包也有一定风险：外包质量不易保证，外包管理需花费更多资源，企业信息泄露，系统灵活性降低等。由于外包商本能地趋向于控制成本以提高自身的利润，所以需要委托方和承包方对外包管理规范达成共识，才可能有效地管理整个外包过程，使得双方共同获益，在这种情况下才有可能使得收益最大化。

在立项阶段，产品负责人应当进行"Make or Buy 决策”，确定待开发产品的哪些部分应当“采购”、“外包开发”或者“自主研发”。非核心业务尽量外包，核心业务自己做，因为核心业务决定产品质量，并且具有一定保密性，外包风险较大。

选择外包商时，并不能单以服务价格来做最终决定，企业应根据自身对软件质量的要求来决定服务的代价。对外包商应从其技术能力、领域知识深度、企业文化、以前是否开发过相类似系统、开发平台和环境等方面评估，评估时还必须提供对外包中所可能产生风险的警觉，以及有效管理风险的办法。

外包分两种：部分外包和整体外包。前者管理方法和企业内部软件开发管理方法差不多，风险也比较小；后者企业需要了解自身是否可以提供优质的规格说明，是否能够提供外包商所需的质量标准和测试数据，外包商是否有类似企业本身的开发平台和环境，以及外包商的技术资源水平是否与企业内部开发时所需的技术指数相符等，风险比较大。确定适合自己企业的外包业务模式，是避免风险，实施项目外包的先决条件。

选择外包时，企业要充分了解自己的项目，其中包括项目需求、实现方法和预期经济利益来源。

选择外包商时，采用分而治之的办法，把一个大的外包项目分给若干厂商，而不是一个厂商来完成。这样每个厂商就可以发挥自己的特长，承接适合自己的外包项目，减少风险。同时，多个厂商分而治之的方法也可以造成各个厂商之间相互制衡，避免外包项目拖延。

签订外包合同时，企业应该提供完整的软件系统规格说明，建立好质量指标和测试流程，争取建立良好的合作模式，能否建立这种合作模式往往决商件开发外包的成败。在合同签订和项目启动前，双方应就项目的工作范围达到明确的一致意见，否则项目实施时会有很多不清楚的地方，验收时将会出现由于项目范围理解不一致而带来的很多麻烦。合同签订时外包中各个里程碑的确认评审时间应该有一定的柔性，否则经过几个延期的确认评审，项目实际进度已经和原来合同规定的要求大相径庭。

项目外包期间，应该建立风险管理机制，包括制定风险管理计划，识别可能发现的风险，分析风险产生的原因并制定相应的应对措施，制定完善的风险监督和控制机制，从而降低风险的副作用，化风险为机会，争取收益最大化。

项目外包期间，还应该建立合同管理小组。供应商的合同和服务经理，以及本企业的合同经理都应该参与其中，形成一个拱形的控制团队。该部门具有一定独立性，监督项目是否按照合同要求实施，提出项目实施中的缺陷和改正方案。该小组可以作为企业和外包商的沟通桥梁，消除理解的不一致性。

5.4.3 参考答案

【问题1】

在项目立项之前，CSAI 可行性分析有误，给项目实施带来极大风险；CSAI 用人不当，选择了一个不负责的项目经理张工，给后续事件发生埋下隐患；CSAI 管理机制不全，没有对项目进行及时监控。

张工专业知识不够，没有及时识别项目中存在的风险；阅历经验不足，签署外包合同时对系统一致性应该专门说明；职业道德水平差，自己在签订外包合同后很少过问，只是应付了事；沟通协调能力不够，自己无暇顾及项目的外包进展，应该给上级领导及时说清，这样可以使自己投入该系统中的时间多一些，更有利于保证系统质量。

外包单位私自在系统中加入时间锁，破坏软件完整性和安全性。外包单位的做法在情理上是可以理解，但是严重违反软件行业职业道德，甚至还涉嫌违法犯罪，而且这种方式减少以后 CSAI 和这些单位继续合作的可能性。

【问题2】

在项目质量管理方面，张工应执行好质量计划、质量保证和质量控制这三个过程。

首先，张工应编制质量计划，识别与该项目相关的质量标准，以及确定如何满足这些标准。为了实现该目标，需要进行成本/效益分析、基准分析、试验设计等。

其次，为了确保实际交付高质量的产品和服务，张工还应联合相关质量部门执行质量保证，有计划且系统地执行为保证项目能够满足相关质量标准而建立的活动。为了实现该目标，需要进行质量审计、过程分析、基准分析等。

最后，为了确定项目实施结果是否符合相关质量标准，张工还应联合项目组和相关质量部门执行质量控制。该过程包括项目产品的质量控制和项目过程结果的质量控制两部分，前者由相关质量部门控制，后者由项目组成员控制。

为了实现该目标，需要进行检查、控制图管理、排列图管理、统计抽样、趋势分析等。

【问题3】

在立项阶段，产品负责人应当确定待开发产品的哪些部分要“采购”、“外包开发”或者“自主研发”。

选择外包商时，并不能单以服务价格来做最终决定；对于外包商应从多个方面评估；评估时必须注意外包中的风险。

确定自己的企业适合部分外包还是整体外包。

选择外包时，企业要充分了解自己的项目，其中包括项目需求、实现方法和预期经济利益来源。

选择外包商时，采用分而治之的办法，把一个大的外包项目分给若干厂商、而不是一个厂商来完成。

签订外包合同时，企业争取建立良好的合作模式；合同签订时外包中各个里程碑的确认评审时问应该有一定的柔性。

项目外包期间，建立风险管理机制，降低风险副作用，争取收益最大化。

项目外包期间，和外包商一起建立合同管理小组，监督项目实施；该小组可以作为企业和外包商的沟通桥梁，消除理解不一致性。

5.5案例五：设计的质量

 阅读以下关于信息系统项目管理过程中项目质量管理方面问题的叙述，回答问题 1 至问题 3。

5.5.1 案例场景

希赛信息技术有限公司(CSAI )曾经为 K 公司开发过一套信息系统，该系统涉及了 K 公司的所有主要业务。该系统中关于组织机构的业务规则如下：

(1)组织机构树通过部门编码体现层级和隶属关系。即部门 0001 的下属部门包括 00010001、00010002,依次类推，根据代码中包含的层级关系确定某个部门在组织机构树中的确切位置，该编码由公司统一制定。

(2)任意一条业务数据隶属于某个特定的部门。

(3)部门之间存在友好和互斥的关系。关系为友好的部门可以共享业务数据，关系为互斥的部门互相不能访问对方的业务数据。

后来，K 公司需要调整部门的组织结构，因此对系统提出了升级的要求：

(1)系统中的部门编码需要更新为最新的企业标准。

(2)组织机构根据最新的企业标准重新生成。

(3)组织结构调整是不能丢失业务数据。、

(4)系统中可以保留组织机构调整的痕迹，业务数据可以追踪除原属于哪个部门，机构调整后属于哪个部门。

(5)部门间友好和互斥的关系可能会被重新定义。

(6)升级后的系统需要能够适应再次的组织机构调整而不需要再次升级。

项目经理张工接受了这个项目，经过细致的调研和分析，发现原系统存在如下缺陷：

(1)原系统中将企业对部门的标准编码设计为部门主键，修改起来难度很大，容易发生数据不一致的问题。

(2)新的企业标准没有考虑到原有企业标准，同是一个部门张工在原标准中为 00010001，在新标准中为 00010005,部门的层次也可能发生变化。

(3)业务数据中保存了隶属部门编码，系统已经使用近两年，保存了大量的历史业务数据。

(4)原系统在设计时将部门间的友好与互斥关系硬编码在系统代码中，且涉及面很广，原系统中80％以上的程序存在这样的硬编码。

(5)不少业务逻辑和工作流程是根据特定的部门编码进行判断的，部门编码的变化会造成业务混乱。

(6)原系统在设计时没有考虑到组织机构调整的可能，也没有对保留部门变革历史的功能进行设计。

张工认为，需求已经非常明确，对于这个项目的关键是设计的质量，其中包括解决方案的设计和业务系统的改造两部分。一旦设计出现偏差，返工的工作量会非常巨大，反之，整个项目还是容易控制的。但张工在如何提高设计质量方面却犯了愁。

【问题1】试以 300 字内回答，张工可以采取哪些措施提高设计的质量？

【问题2】试以 300 字内回答，除设计外，张工还需要特别注意哪些工程活动。

【问题3】试以 300 字内回答，如何提高这些工程活动的质量。

5.5.2 案例分析

这是一个开放式的案例分析题，案例中仅粗略地描述了项目背景的目标，针对如何提高项目质量进行发问，难度相对较大，需要仔细的分析。

前面一部分对项目背景和目标的描述无非是为了说明这么几个问题：

(1)这是一个系统改造的项目。

(2)原系统中存在设计缺陷，没有考虑过组织机构改革的可能性。

(3)需要大量更改原系统的程序，消除硬编码。

(4)需要更改已有的业务数据，同时增加部门变革历史的功能。

基于这些问题，案例的后半部分给出了张工的观点：设计质量是项目的关键，需要提高设计的质量。结合案例后的问题，我们不难发现，案例的前半部分是引子，后半部分才是关键，也是该案例的题眼：如何提高项目的质量，显然需要用项目质量管理的知识作答。

质量管理是项目管理中的一个知识域，但在 PMBOK 中并没有给出具体的质量管理的方法，需要结合软件开发和项目的特点给出特定的质量管理策略和方法。这也正是这个案例的用意所在，考察考生在面对实际的项目问题时需要采取哪些措施解决项目的质量问题。

我们首先从软件工程的角度考虑一下软件质量的问题。软件的质量一直是软件界近几十年致力解决的问题，针对使用软件提高软件质量提出了很多的方法和理论。首先是软件工程的理论，需要使用工程活动的方法进行软件开发，从系统定义与分析开始，经过设计、实现，最终到验证。在软件工程中，人们提出了多种软件开发模式和工程活动方法。在开发模式中，有瀑布模型、螺旋模型、迭代模型、喷泉模型等；在工程活动方法中，有自顶向下、结构化分析、面向对象分析、架构风格，等等。除此之外，还有一系列的软件验证方法，如软件复审与软件测试。纵观这些林林总总的模式与方法，人们无非是想解决两个问题：一是通过恰当的工程活动提高工作产品的质量；二是在工作产品完成后通过恰当的工程活动来保证该产品的质量。因为在软件开发过程中，还有一个很明显的特点，就是在分析、设计、实现和测试这些过程中，每一步都可能引入缺陷，且难以发现，而这些缺陷暴露得越晚，造成的后果就越严重，修改的代价就越高昂。开发活动需要尽量提前发现潜在的缺陷，验证手段必不可少。

题目中问的是如何提高设计的质量，设计是承接分析、指导开发的一个关键环节，在这个环节中很容易引入难以发现的缺陷，而这些缺陷往往又会造成严重的后果。因此提高设计的质量是每个软件项目都会遇到的问题，也是每个项目经理都会思考的问题。提高设计质量包括两个层面的工作：

在设计过程中提高设计的质量；在设计完成后对设计结果的质量检查。在答题中需要分别给出相应的策略。

设计工作在分析工作之后，因此，充分的分析是保证设计质量的前提。对于这种改造型项目，原系统的功能、设计和实现的情况直接影响了设计的结果，原系统的情况就是要解决的问题域，如果对原系统了解不足必然导致设计上的偏差。因此要想提高设计的质量，首先要充分了解原系统。

在设计时还应该选择恰当的设计方法，如有可能可以考虑复用已有的解决案例，如分析模式与设计模式等。不过在这方面，案例中给出的信息甚少，显然不是答题的重点。

根据项目背景的描述，这个设计工作并不简单，需要论证的过程，设计方案的讨论也是必需的。

因此张工需要制定出相应的沟通计划，组织必要的会议进行方案讨论，若有必要还需要客户和原系统的开发者参加。在设计完成后还需要对设计结果进行质量检查，对应这类活动，我们通常采用评审和走查的方式。评审和走查可以比测试更早地找出工作产品中的缺陷，用来检查设计质量非常合适，可以避免缺陷在系统测试阶段才被发现，降低修正缺陷的成本。

除了评审和走查外，对设计过程进行迭代也可以提前暴露设计的缺陷，并将这些缺陷反馈到后续的设计过程中，从总体上减少缺陷数，提高设计的质量。例如在可以将整个项目根据系统模块进行划分，首先升级一个模块，然后把这个过程中发现的问题反馈到后续的迭代过程中。

如果能够做好上述工作，设计就不会产生重大的偏差，保证设计的质量。

对于第二个问题，除设计外，张工还需要特别注意哪些工程活动。

在分析第一个问题是我们已经找到了一部分答案—分析。分析是设计活动的基础，在错误的分析上不可能产生正确的设计。因此充分、细致地分析原系统是保证设计质量的前提。

除此之外，对于系统改造的项目，测试的工作显得非常重要。同原系统开发相比，系统改造的总工作量相对较少，但测试的工作量却应该超过原系统开始时的测试工作量。根据案例中的描述，超过 80％的程序都存在硬编码的问题，都需要修改。这些程序在修改后首先需要满足同原系统功能一致，可以通过原系统测试用例的测试；其次还要保证与系统升级的目标一致，能够满足设计的要求，这就需要开发新的测试用例进行测试。因此，如何规划、组织、展开测试工作，也是张工需要特别注意的方面。

除了分析和测试外，其余的工程活动也是不可或缺的，不过相比之下，分析和测试工作更具特殊性，是张工必须特别注意的。

第三个问题与第二个问题是关联的。有了第二个问题的答案，第三个问题就比较容易了。

如何提高分析活动的质量呢？对于案例中的项目来说，系统要解决的是原系统中的缺陷，原系统本身就是问题域，提高分析活动的质量也就是充分地分析原系统。对原系统的分析可以包括对原有业务功能、原设计方案和原程序的分析。对原系统中业务功能的分析需要同客户一起进行，通过同客户的沟通来把握原系统所实现的业务功能。对原设计方案的分析出了参考设计文档外，最好能够同原系统的开发者进行沟通，这样的沟通往往能获取到文档之外的宝贵信息。例如，通过设计文档仅能了解设计的结果，但与原系统开发者的沟通则可以了解到设计的思路。除了这些方法外，对

分析的结果进行评审也是保证分析质量的一种有效的方法。

对于测试工作，上面已经讲了很多，既需要保证修改后的代码仍然与原系统功能一致，又要保证同系统升级的目标一致。

5.5.3 参考答案

【问题1】

张工可以采取以下措施提高设计的质量：

(1)充分分析问题域是保证设计质量前提。

(2)组织必要的讨论来确定概要设计的方案。

(3)采用迭代的方法验证设计的正确性，提高设计的质量。

(4)对设计进行评审或走查。

【问题2】

除设计外，张工还需要特别注意以下工程活动：

(1)需要细致分析原有系统。

(2)对于这样的改造项目，测试的难度和工作量很大，需要把握测试的工作。

【问题3】

如何提高这些工程活动的质量：

(1)在分析方面

①同客户充分沟通，了解原系统的业务需求；

②阅读原系统中的文档和程序，掌握设计和实现的情况；

③如果可能，与原系统的开发者联系，在原开发者的帮助下把握原系统；

④对分析的结果进行评审。

(2)在测试方面

①使用原系统开发过程中的测试用例进行回归测试；

②针对改造后的系统开发新的测试用例进行测试。

5．6 案例六：软件测试

阅读以下关于信息系统项目管理过程中项目质量管理方面问题的叙述，回答问题 1 至问题 2。

5.6.1 案例场景

张工在希赛信息技术有限公司(CSAI )工作，被委派到了一个新的项目担任项目经理，为客户 K公司开发用于支撑业务的信息系统。这是一个规模较小，复杂度较低的系统。由于市场竞争的原因，合同额很少。出于成本的考虑，公司分派给张工的人员并不多。为解决人力资源不足的问题，张工考虑，系统复杂度不高，可以一定程度上简化测试工作。于是张工在项目中做了如下安排：

(1)不进行单元测试和集成测试，仅进行系统测试。

(2)不安排专门的资源开发系统测试用例。因为程序员熟悉自己开发模块的业务，由程序员对自己开发的程序进行黑盒测试，对测试中发现的缺陷进行记录并跟踪，且立即修改。

(3)在测试过程中，每三天定义为一个测试周期，统计每个测试周期每个模块发现的缺陷数量。若连续两个测试周期没有发现的缺陷少于总缺陷的 5%且发现缺陷的趋势基本平稳，则认为测试工作基本完成。

张工的理由如下：首先，随着系统中缺陷的减少，程序员会有越来越多的时间进行测试，以发现系统缺陷。其次，当系统中的缺陷数量很少时，程序员发现的缺陷会变得越来越困难，总缺陷数几乎不再增加，这时发现缺陷的趋势变得很平稳，且发现的数量很少。

在测试阶段，张工统计到的数据如表 5-1 所示。张工认为测试工作基本完成，决定进入系统发布阶段。

【问题1】请以 300 字内，逐一点评张工对测试工作进行的三点安排。

【问题2】在人力资源有限的情况下，张工不可能找到专门的测试人员全程进行测试，那么张工应做哪些改进来提高测试工作的质量，试以 300 字内回答。

5.6.2 案例分析

该案例中描述的场景是很多软件公司中常见的场景，由于市场的恶性竞争或是其他原因，开发的费用被一再压缩。为了满足成本的约束，项目经理忽视测试的工作，项目组成员在项目中身兼多职，从需求一直做到测试。系统缺乏完整的测试，甚至没有测试就提交给客户。虽然案例中没有写明，但结果已经可以想像，客户为充满问题的系统而恼火，即使项目谈不上失败也绝对谈不上成功。

人们常说：“再穷不能穷教育”，对于软件项目而言就是“再省不能省测试”。软件系统的技术复杂度相对较高，结果抽象，可以模式化的东西很少，开发过程也是一种探索的过程，在每一个步骤都会制造缺陷，这已经在无数的软件系统开发中得到了验证。成功的系统总是正视这种客观情况，通过各种各样的方法来提高质量，尽可能早地检出系统中潜在的缺陷；失败的项目则是回避，总是假设不会出现缺陷或缺陷很少，．任由错误扩大，最终肯定是缺陷的大爆发，开发人员疲于修正缺陷，同时再引入新的缺陷。

在案例中，张工在人力资源不足和项目质量上进行了折中，进行角色复用，把开发和测试安排到一起，根据缺陷发现的趋势来判断测试是否可以结束，于是问题就出现了。

对于软件开发中的角色复用，专门的论述并不多见。我们在这里引用 MSF 中关于开发角色和角色合并的内容进行讲解与分析。在微软的项目管理框架一 MSF 中定义了软件项目中的 6 种角色：

(1)产品管理，负责产品的定义，如客户代表、产品负责人、需求人员。

(2)程序管理，按项目的约束进行交付，如项目经理、开发主管。

(3)开发，根据规格说明书(需求规格说明书、设计说明书等)进行系统的构建，如系统设计人员、编码人员。

(4)测试，确定并找到系统中的质量问题，如测试人员。

(5)用户体验，负责把握用户在使用系统时的感受，例如，需求人员、界面设计人员、系统培训

人员。用户体验不同于产品管理，用户体验着重从用户处获得需求与反馈信息，而产品管理则注重于产品的定义，其定义的依据既包括用户需求也包括产品路线图等内容。

(6)发布管理，负责系统的部署的稳定的运行，例如项目经理、系统管理员。

在 MSF 中给出了角色间合并的建议，如表 5-2 所示。

根据表 5-2 可以看出，开发人员虽然是程序的创造者，但不推荐和其他任一种角色合并。MSF是微软总结了其多年的开发经验整理出来的项目管理框架。也就是说，即使是在微软这样的公司，虽然每个人都有足够的能力，但开发人员仍需要独立出来，不能够与测试混为一谈。

这一点也不难理解。首先开发人员与测试人员的技能侧重点不同，开发人员侧重于技术的细节，关注于系统实现所采用的技术和方法，更需要把握如何应用技术手段构建满足规格说明书的系统；测试人员侧重于技术的结果，关注于系统实现后的表现和效果，更需要把握实现的系统是否满足规格说明书的要求。其次，开发人员与测试人员的目标不同，开发人员希望能够构建出完全符合要求的系统；测试人员则需要在看似完全符合要求的系统中寻找缺陷和漏洞。

因此，开发人员同测试人员的视角不同，开发人员总是倾向于构建后的系统是完美的，而测试人员则倾向于构建后的系统是有缺陷的。这种种不同，造成开发人员很难发现自己构建的系统中的缺陷，存在盲点，而测试人员更容易发现系统中的问题。

再回到这个案例，不难发现，张工正是在这一点上犯了错误，把开发和测试结合到了一起，让程序员测试自己开发的程序。

在问题 1 中，要求对张工进行的测试安排进行点评，上面我们已经谈到，第二点是肯定有问题，那么其余两点呢？

对于第一点来说，是完全可以的。虽然在严格的软件开发模型中定义了单元测试、集成测试和系统测试，但在实际项目中完全可以根据项目情况进行裁减。如果系统复杂度不高，系统规模又比较小，我们可以考虑仅仅进行系统测试。不过在裁减过程中应该注意，单元测试相对集成测试更重要。集成测试可能会同系统测试部分重合，但单元测试相对独立，可以发现一些极端情况下的问题和程序上的低级错误。在案例中，即使是程序员自己测试自己的程序，前三个测试周期中仍发现了不少缺陷，就是由缺少单元测试造成的，系统中还存在不少低级错误。

对于第三点来说，根据缺陷发生的趋势来判断测试工作是否完成，是一种可行的方法。如果测试过程公正客观，发现的缺陷具有代表性，以此为依据进行判断是有效的。但反之，若测试过程不充分、不客观，这种方法毫无意义，因此在案例中这种方法加剧了开发人员与测试人员合并的恶果。

第二个问题也是项目中的常见问题。当人力资源有限时，我们应该如何在保证项目质量的前提下压缩团队规模。

我们根据 MSF 中的角色合并建议来回答这个问题，见表 5-2.表 5-2 中列出可以和测试角色合并的角色包括：产品管理、?用户体验和发布管理，在某些情况下，测试可以和程序管理相合并。

除了角色合并外，还有一些方法，可以以较少的人力投入换取更高的项目质量。其中包括：

(1)程序员间进行交叉测试，最好可以同其他项目组的程序员互换，让程序员在互换中变更自己的角色。

(2)在程序员自己发现的缺陷区域平稳后再提交给测试人员进行测试。这样可以避免测试人员陷入低级错误中，减少其工作量。

5.6.3 参考答案

【问题1】

(1)不进行单元测试和集成测试，仅进行系统测试。在低复杂度的小规模项目中，这种做法尚可，通过系统测试可以发现大多数系统中的缺陷。

(2)不安排专门的资源开发系统测试用例，由程序员对自己开发的程序进行黑盒测试，并对测试中发现的缺陷进行记录并跟踪，由发现者立即修改。

这种做法问题会造成很严重的问题。程序员是程序的创造者，是无法进行黑盒测试的。这种所谓的黑盒测试会造成测试的盲点，一些缺陷始终无法发现。

(3)在测试过程中，每三天定义为一个测试周期，统计每个测试周期每个模块发现的缺陷数量。若连续两个测试周期没有发现的缺陷少于总缺陷的 5％，且发现缺陷的趋势基本平稳，则认为测试工作基本完成。

若有专门的测试人员，公平客观地进行测试工作，这种判断测试工作是否完成的方法是有道理的，可以保证绝大多数的缺陷都在测试中发现。

【问题2】

在人力资源有限的情况下，张工应做如下方面改进来提高测试工作的质量：

(1)根据项目实际情况，由项目经理、需求人员或客户业务代表进行测试。

(2)采取程序员交叉测试的方法。

(3)若情况允许，可以在程序员自己发现缺陷趋于平稳后，再提交给专门测试人员进行测试。