第十二课 项目质量管理案例和论文
2012-03-14 19:51阅读：
第十二课
项目质量管理案例和论文
案例分析：
质量是“使实体具备满足明确或隐含需求能力的各项特征之总和”，明确或隐含的需求是指按项目需求制定的基础性文件。在信息系统项目中，一般把《系统需求规格说明书》作为项目需求的基础性文件。
质量管理作为项目管理的一部分，具有非常重要的地位。质量管理的目的是通过执行项目质量管理过程，使用一些基本项目管理工具和技术来保证信息系统的质量。时间、成本、质量是项目管理的三大目标，如果质量不能满足要求，即使进度再快，成本再节省，项目也没有意义。
案例一：
阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题1至问题3。
案例场景
某银行信息系统工程项目，包含省级广域网工程、储蓄所终端安装工程、主机系统工程、存储系统工程、备份系统工程、银行业务软件开发工程等若干子项目。此工程项目通过公开招标方式确定承建单位，希赛信息技术有限公司(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 字内回答，若你是本项目的总工，你将怎样改进工作，以提高软件系统开发的质量，保证工程项目按期验收？
案例分析
过去，很多 IT
集成公司所承建的定制软件工程项目，当进入到验收阶段的时候，用户常常拖延，或找这样那样的借口不给承建单位验收，这是什么原因呢？针对这个问题，建设单位、承建单位都有一定责任。对于建设单位来讲，由于建设单位对信息系统建设认识上的局限性，对软件系统质量鉴定的困难性，建设单位存在着对定制软件系统的质量的担心，因此，很难果断地做出验收项目的决定。
而对于承建单位来讲，承建单位在项目质量管理方面常常做得很不到位，比如：该提交工程实施计划、工程实施计划进度跟踪记录、工程概要设计书、详细设计书、应用系统配置文件、用户手册、培训资料等若干文档的时候没有提交，而很多承建单位在项目验收时，根本看不到这些文档，或即使有文档，但也极其不规范，文档质量很低。再比如：曾有个信息系统工程项目在提交用户验收的时候，有一台防火墙散乱地摆放在机柜外面，再看机柜上面所布放的通信线缆，显得杂乱无章，承建单位也没有意识到这个问题，用户虽看在眼里却不提醒承建单位，那请问，用户会给这样的项目进行验收吗？
通过硬件所表现出来的表面质量是很容易发现的，但对于软件系统的质量的衡量却是非常困难的，特别是对于那些对软件系统认识不够深入的 IT
系统建设单位，他们面对 IT 项目的验收，常常显得很谨慎也是可以理解的。
信息应用系统项目的质量保证与承建单位的质量保证体系是密切相关的，但并不等于承建单位有质量保证体系，如通过了 ISO9000
认证，或通过了 CMM3, CMM4 等认证，就一定能够保证 IT
项目的质量。承建单位的质量保证体系是一个大纲性质的，但实施项目的是项目小组，项目小组不能很好融合到承建单位的质量保证体系中是比较常见的现象，因此，为有效保证项目的质量，项目小组应当向建设单位或监理单位提交项目的质量保证计划。质量保证计划是在承建单位质量保证体系下编制的，是针对项目特点的，涉及保证项目质量的具体措施，更易于操作。当然，一个项目的质量保证计划如果照搬到另外一个项目，却不一定适用。而建设单位、监理单位可以通过对承建单位质量保证计划的执行情况来判断其软件开发过程的质量，从而协助对定制软件产品质量的鉴定。
【问题1】
软件测试是保证软件质量的重要工作内容之一，但软件测试环节却不是软件质量的形成环节，测试只能检查软件中所存在的缺陷，发现问题。软件质量是在需求分析、设计、编码、测试、文档编制等软件生产的全过程中形成的。因此，我们要了解定制软件系统的质量，就必须了解承建单位开发软件系统的全部过程的质量。
测试计划和测试用例应当在软件的设计阶段制定。越晚进行的测试，其测试计划的编制时间就越早。如集成测试计划在概要设计阶段编制，功能确认测试计划在需求定义阶段就应当制定，整体测试计划也应当在需求分析阶段制定。
虽然我们在实践中有很多这样的情况，很多软件开发团队并不是在软件设计阶段同步制定软件测试计划和测试用例，甚至有很多软件开发中根本就没有制定规范的测试计划和测试用例。但这些并不是正统、规范的做法，这样的软件工程过程对于保证定制软件系统的质量来说是会打折扣的。
若测试计划的编制时机不能按照规范进行，那说明软件企业的过程能力成熟度还不够，还是在采用手工作坊方式生产软件，想到哪里做到哪里，没有计划或计划不科学，不能有效地控制软件生产的质量。
【问题2】
软件系统的质量，仅仅根据测试的结论来进行断言是不够的。我们在进行项目开发计划安排的时候，应当将系统的试运行也安排在计划之内。系统的试运行牵涉到工程项目的建设方和承建方，除了技术方面的因素外，还涉及组织方面的因素，人文方面的因素等。承建方要安排足够的时间与建设方协商系统的试运行问题，在双方的配合下开展系统试运行工作，系统在试运行中，通常还会发现大量的故障，承建单位也必须配合解决这些系统故障。只有通过试运行的考验，才能够基本断定系统的质量是否符合要求；通过了试运行的考验，再向用户提出工程项目的验收，一般来说，用户的接受程度会比较高。
软件系统的试运行为什么如此重要呢？这是根据不同的工程项目的特点，如公路建设就不需试运行，住宅建设也不需试入住，通过质检方式就可确定工程项目的质量。而另外一些工程项目则是必须要进行试运行的，比如铁路系统建设、水电站建设、化工厂建设等，这些类型的工程项目，不通过试运行，就不可能鉴定其质量，信息应用系统的建设也是一样。
【问题3】
另外，在向用户提出项目验收前，还得整理并提交完整的工程技术文档、系统维护文档、软件配置清单，给用户举办系统操作培训、维护培训，全面审核合同执行情况，编制项目竣工报告，等等。如果项目小组不注意这些工作，用户大多也不会来提醒你，用户只卡住验收关不让通过就可以了，当然也有部分用户可能会提醒项目小组离验收还差什么。毕竟项目的实施任务是属于承建单位的工作，承建单位理应完善自身的项目管理水平，不可能让用户来督促你、提示你，那不是用户的职责，更何况，很多用户自身也不知道
IT
项目该怎样管理，有哪些工作需要完成，但承建单位很多不规范的做法、存在的问题，让用户对质量不放心，用户却是能够觉察到的。特别要注意的是，项目经理在计划项目验收时，应当与用户的主要领导充分沟通，让客户领导了解项目的建设过程，了解项目的质量实施情况，让领导对项目的验收充满信心。
但请仔细分析本题，案例场景中通篇并没有提到关于工程文档、配置清单、培训等话题，这些内容并不是本题的关键，未提及的内容，张工可能没做到，但也可能做到，不好断言。我们只要能够抓住场景所描述的张工的主要缺陷，一是制定测试计划的时机不对，二是根据测试断定软件系统的质量不对，只要能抓住这两点就够了。其他的内容，也可以反映在答案中，但要注意语言要简练，虽不会导致扣分，但也不是得分的要点。
参考答案
【问题1】
张工安排测试计划的编制时机不对。测试计划和测试用例的编制应当与软件系统的概要设计、详细设计同步进行。
测试计划不够全面，还应当包含系统整体测试、运行测试。运行测试是对应用软件系统整体功能的全面检验，也是最能够说明软件系统质量的测试环节。
系统测试计划、确认测试计划应当在需求分析阶段制定，测试用例、测试说明应当在概要设计阶段制定。
集成测试计划应当在概要设计阶段制定，测试用例、测试说明应当在详细设计阶段制定。
单元测试计划应当在详细设计阶段制定，测试用例、测试说明应当在编码阶段制定。
【问题2】
在定制软件开发项目中，根据测试结果判定软件系统的质量是不够的，因为软件系统中的缺陷可能由于多种原因而未在测试中被发现，如测试环境与运行环境的区别、测试人员的能力问题、测试计划和测试用例的局限及缺陷。
由于软件系统质量、功能、性能具有很强隐蔽性的特点，用户往往不大可能根据项目开发小组的测试结论来进行项目的验收。最好让用户组织对项目进行试运行，以试运行的结论来作为验收的依据之一是比较有说服力的。
【问题3】
(1)在进行需求分析的时候，同步制定功能确认测试计划和测试用例，同步制定系统整体测试计划和测试用例。
(2)在进行软件系统概要设计的时候，制定集成测试计划和测试用例。
(3)在进行软件系统详细设计的时候，制定单元测试计划和测试用例。
(4)在项目计划验收日期前，提前与用户协商系统试运行计划，并给用户进行充分的培训，包括领导和一般操作人员，让系统接受实际运行的考验，在试运行过程中暴露出来的问题，及时进行解决。以软件系统实际运行所表现出来的功能、性能来说服用户对项目进行验收，这通常是更可行的方法。
案例二：
阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题 1 至问题 3。
案例场景
重庆市某行业关键应用 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 应用软件开发工程中，怎样进行项目现场与总部软件开发团队的有效配合？
案例分析
CSAI 虽然通过了 CMM3 级认证、ISO9000 认证，但 CSAI
的管理工作未必就能按照规范来开展，有不少公司只是将这些认证作为投标竞争时的砝码而已。因此，我们在建设工程项目的时候，不但要看 IT
系统集成商具不具备这些认证，还应采取有效的手段考核 IT 系统集成商的质量保证计划。
对 IT
系统集成商进行考核，简便可行的方法就是让集成商在项目开工前提交质量保证计划，并对质量保证计划进行评审，通过后要求集成商严格执行。通常，过程能力成熟度高(指实际)的
IT
企业，在实际工程与质量保证计划之间的一致性会完成得较好，而过程能力成熟度低的企业(指实际)，实际工程与质量保证计划之间的一致性会完成得相对较差。
【问题1】
我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程项目的三大目标。通常与客户接触最多的是现场项目经理，引导客户需求对项目经理就非常关键，项目经理引导得好，项目的开发就会非常顺利，反之，就会使项目组疲于奔命。优秀的项目经理是既能够让项目组成员“睡大觉”，又能保持良好的客户满意度。
CSAI
项目经理李工与用户的沟通存在问题。善于沟通的人，一言明百理；不善于沟通的人，百言不明一理。项目经理与客户的沟通，不是指项目经理善于说话，善于高谈阔论就能够解决问题，更为关键的是项目经理要具备足够的引导项目建设的能力。作为现场项目经理，不是只做一个传话筒，客户说什么就是什么，而是应当与客户进行深入交流，深入分析客户所提出的问题，合理引导客户的需求，要有主见。
李工在 CSAI
进行客户满意度考核，客户又有大量需求的前提下，显得无所适从，手忙脚乱，而做出了不合适的决定。一是客户的需求，只要我们能够合理引导客户，客户的需求变更不可能有那么频繁，有很多需求变更是可以让用户暂时放弃的，或有的需求变更可以让用户在另外的工程项目中去实现，比如建议用户建设=期工程。我曾经见到一位项目经理在一个工程项目中，客户提出了一个需求，项目经理安排组员加班三天三夜完成了，告诉客户方主任，客户主任大吃一惊，说：“我并没有要求你们实现这个需求啊，我只不过向你们咨询一下而已”。
客户与我们的项目经理交谈，并不是都谈需求，有很多时候，客户可能是谈到自己的想法、心得体会、建议等。客户方面也往往有很多员工，一位员工有一种思想，十位员工就有十种思想，要统一这十种思想，项目经理就得付出更多的努力，要与用户方面的主管人员达成一致，而且，很多时候是必须要用户的主管人员去统一他们的意见。否则，应用系统的开发就存在很大制约因素。很多项目经理面对公司客户满意度的考核，面对客户无休止的需求，常常不能采取正确的应对方法，该说的不敢说了，该讲的不敢讲了。应用软件工程在建设阶段，优秀的项目经理应当是能够引导用户思路的项目经理，而不是让用户领导项目经理的项目建设思路。项目经理应当知道，任何一个客户都更注重项目建设的结果，在项目建设的过程中，项目小组与建设单位之间可能存在着很多次交流，甚至争论，但只要我们能确保项目建设的结果让用户满意，用户是终会给予好评的。
【问题2】
二是对 CSAI
资源的利用不当，李工把本不属于现场的工作内容，让现场工程师来完成是严重的失误，现场工程师仓促上阵，没有纳入 CSAI
统一的软件开发质量管理体系。虽然能够临时快速解决问题，但也会埋下故障隐患，而故障隐患的爆发却是在工程建设的后期。这种做法只能让员工疲于奔命。在项目管理中，如果项目组成员总是处于应急、救火的状态，是不可能高质量地完成工作任务的。作为项目经理，不但要关心项目的进展，还应当关心自己的成员，要让项目小组成员在高效率、高质量的状态下工作。
三是忽略了现场应该做的重要工作，应用系统的配置管理工作对现场来说是很重要的。混乱的配置管理，也会导致系统运行中发生严重的质量问题。
即使李工非要在现场进行开发不可，那也应当自觉地将现场所开发的软件，与公司总部所开发的应用软件进行统一的管理。特别是要注意，现场开发的缺点是对需求的把握太随意，由于开发人员与用户直接接触，用户的想法可能有很多偏激的成分，也容易被现场开发人员设计到应用软件系统中，从而导致现场版本与统一版本难以融合，特别是对有些需求的满足，可能涉及到软件系统体系架构的变更，这样就更难处理了。而现场临时决定的软件开发，管理工作怎样和总部的管理工作融合到一起，项目经理是应当考虑的，要么是由总部来控制，要么是现场自觉与总部配合。
【问题3】
我们在工程现场实施的时候，对于所遇到的系统问题，有的是能够迅速解决的，也有暂时无法解决的。对于暂时无法解决的问题，我们常常采取迂回的方式绕过去，以保证工程项目的进度。但是对于应用软件系统的开发来说，现场不能只是绕过去而已，还应当及时向总部报告，应当建立一个系统故障管理平台，记录所有发现的软件故障，逐一报告研发中心进行解决，并跟踪解决情况。
为有效解决现场与总部的配合问题，可以建设一个基于 Internet
的开发管理平台，现场所遇到的问题，及时汇报到管理平台，由总部管理人员分配解决。现场也可通过管理平台主动与总部沟通软件开发问题，协调一致，避免总部统一版本更新时丢失现场所开发的功能。
配置管理也是涉及到工程质量的。我们做企业级的应用系统，都应当考虑到系统割接的平滑性，配置变更的平滑性，在进行配置规划的时候就应当考虑配置的变更怎样才能实现平滑过渡，否则，就很可能使运行的系统在进行配置变更的时候进入瘫痪状态。而良好的配置管理，又是实现配置变更平滑过渡的有力支持。
参考答案
【问题1】
现场用户的需求是不可能有尽头的，但作为项目经理要能够把握住用户的需求，特别是要合理引导用户需求，切不可让用户怎么说就怎么做。
积极响应客户需求要从多个方面着手考虑，不要只从技术上考虑问题，技术引导、合同变更、人力资源等各个方面都应当考虑。
临时的现场开发工作，大多数都不可能与公司总部的软件开发融为一体，而且管理工作常常是自上而下的，李工忽略了这点，顾此失彼，导致项目问题的发生。
造成项目问题的原因有以下几点：李工对需求把握随意；控制不严；李工与客户沟通不到位；李工没有向客户提交合理的进度计划，或没有按时提交进度报告；项目实施无计划，或计划不能得到客户认可，客户不满意。
【问题2】
团队协同开发软件时，很容易出现软件版本管理不善带来的软件系统故障。同一软件系统代码不能同时由多人进行修改。
项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障反复出现。
李工如果一定要进行现场开发，应当委托现场合适的人员，或亲自督促现场所进行的开发工作与总部所进行的开发工作在软件版本方面保持一致，处理本地过于偏激的需求要与总部协商一致的情况采取合理措施控制统一版本。
【问题3】
项目现场应明确自己的工作职责范围，要自觉与总部门形成密切的配合。
现场所做的开发，应与总部所做的开发纳入同一个软件版本管理。
当现场发现软件故障时，应当及时向总部报告。建立故障管理表，记录并跟踪软件系统故障解决情况。
建设一个软件开发交流平台，如基于 Internet 的管理平台，管理工程现场所提出的问题，调度、跟踪解决工程现场问题。
现场工程人员与总部人员应多交流，通过各种方式，如及时通信软件、电话、电子邮件等，必要时，可组织研发部给现场工程人员进行培训。
案例三：
阅读以下关于信息系统项目管理过程中项目质量管理方面问题的叙述，回答问题 1 至问题 3。
案例场景
XX信息技术有限公司(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 字内回答，如何提高这些工程活动的质量。
案例分析
这是一个开放式的案例分析题，案例中仅粗略地描述了项目背景的目标，针对如何提高项目质量进行发问，难度相对较大，需要仔细的分析。
前面一部分对项目背景和目标的描述无非是为了说明这么几个问题：
(1)这是一个系统改造的项目。
(2)原系统中存在设计缺陷，没有考虑过组织机构改革的可能性。
(3)需要大量更改原系统的程序，消除硬编码。
(4)需要更改已有的业务数据，同时增加部门变革历史的功能。
基于这些问题，案例的后半部分给出了张工的观点：设计质量是项目的关键，需要提高设计的质量。结合案例后的问题，我们不难发现，案例的前半部分是引子，后半部分才是关键，也是该案例的题眼：如何提高项目的质量，显然需要用项目质量管理的知识作答。
质量管理是项目管理中的一个知识域，但在 PMBOK
中并没有给出具体的质量管理的方法，需要结合软件开发和项目的特点给出特定的质量管理策略和方法。这也正是这个案例的用意所在，考察考生在面对实际的项目问题时需要采取哪些措施解决项目的质量问题。
我们首先从软件工程的角度考虑一下软件质量的问题。软件的质量一直是软件界近几十年致力解决的问题，针对使用软件提高软件质量提出了很多的方法和理论。首先是软件工程的理论，需要使用工程活动的方法进行软件开发，从系统定义与分析开始，经过设计、实现，最终到验证。在软件工程中，人们提出了多种软件开发模式和工程活动方法。在开发模式中，有瀑布模型、螺旋模型、迭代模型、喷泉模型等；在工程活动方法中，有自顶向下、结构化分析、面向对象分析、架构风格，等等。除此之外，还有一系列的软件验证方法，如软件复审与软件测试。纵观这些林林总总的模式与方法，人们无非是想解决两个问题：一是通过恰当的工程活动提高工作产品的质量；二是在工作产品完成后通过恰当的工程活动来保证该产品的质量。因为在软件开发过程中，还有一个很明显的特点，就是在分析、设计、实现和测试这些过程中，每一步都可能引入缺陷，且难以发现，而这些缺陷暴露得越晚，造成的后果就越严重，修改的代价就越高昂。开发活动需要尽量提前发现潜在的缺陷，验证手段必不可少。
题目中问的是如何提高设计的质量，设计是承接分析、指导开发的一个关键环节，在这个环节中很容易引入难以发现的缺陷，而这些缺陷往往又会造成严重的后果。因此提高设计的质量是每个软件项目都会遇到的问题，也是每个项目经理都会思考的问题。提高设计质量包括两个层面的工作：
在设计过程中提高设计的质量；在设计完成后对设计结果的质量检查。在答题中需要分别给出相应的策略。
设计工作在分析工作之后，因此，充分的分析是保证设计质量的前提。对于这种改造型项目，原系统的功能、设计和实现的情况直接影响了设计的结果，原系统的情况就是要解决的问题域，如果对原系统了解不足必然导致设计上的偏差。因此要想提高设计的质量，首先要充分了解原系统。
在设计时还应该选择恰当的设计方法，如有可能可以考虑复用已有的解决案例，如分析模式与设计模式等。不过在这方面，案例中给出的信息甚少，显然不是答题的重点。根据项目背景的描述，这个设计工作并不简单，需要论证的过程，设计方案的讨论也是必需的。
因此张工需要制定出相应的沟通计划，组织必要的会议进行方案讨论，若有必要还需要客户和原系统的开发者参加。在设计完成后还需要对设计结果进行质量检查，对应这类活动，我们通常采用评审和走查的方式。评审和走查可以比测试更早地找出工作产品中的缺陷，用来检查设计质量非常合适，可以避免缺陷在系统测试阶段才被发现，降低修正缺陷的成本。
除了评审和走查外，对设计过程进行迭代也可以提前暴露设计的缺陷，并将这些缺陷反馈到后续的设计过程中，从总体上减少缺陷数，提高设计的质量。例如在可以将整个项目根据系统模块进行划分，首先升级一个模块，然后把这个过程中发现的问题反馈到后续的迭代过程中。如果能够做好上述工作，设计就不会产生重大的偏差，保证设计的质量。对于第二个问题，除设计外，张工还需要特别注意哪些工程活动。在分析第一个问题是我们已经找到了一部分答案—分析。分析是设计活动的基础，在错误的分析上不可能产生正确的设计。因此充分、细致地分析原系统是保证设计质量的前提。
除此之外，对于系统改造的项目，测试的工作显得非常重要。同原系统开发相比，系统改造的总工作量相对较少，但测试的工作量却应该超过原系统开始时的测试工作量。根据案例中的描述，超过
80％的程序都存在硬编码的问题，都需要修改。这些程序在修改后首先需要满足同原系统功能一致，可以通过原系统测试用例的测试；其次还要保证与系统升级的目标一致，能够满足设计的要求，这就需要开发新的测试用例进行测试。因此，如何规划、组织、展开测试工作，也是张工需要特别注意的方面。
除了分析和测试外，其余的工程活动也是不可或缺的，不过相比之下，分析和测试工作更具特殊性，是张工必须特别注意的。
第三个问题与第二个问题是关联的。有了第二个问题的答案，第三个问题就比较容易了。
如何提高分析活动的质量呢？对于案例中的项目来说，系统要解决的是原系统中的缺陷，原系统本身就是问题域，提高分析活动的质量也就是充分地分析原系统。对原系统的分析可以包括对原有业务功能、原设计方案和原程序的分析。对原系统中业务功能的分析需要同客户一起进行，通过同客户的沟通来把握原系统所实现的业务功能。对原设计方案的分析出了参考设计文档外，最好能够同原系统的开发者进行沟通，这样的沟通往往能获取到文档之外的宝贵信息。例如，通过设计文档仅能了解设计的结果，但与原系统开发者的沟通则可以了解到设计的思路。除了这些方法外，对分析的结果进行评审也是保证分析质量的一种有效的方法。
对于测试工作，上面已经讲了很多，既需要保证修改后的代码仍然与原系统功能一致，又要保证同系统升级的目标一致。
参考答案
【问题1】
张工可以采取以下措施提高设计的质量：
(1)充分分析问题域是保证设计质量前提。
(2)组织必要的讨论来确定概要设计的方案。
(3)采用迭代的方法验证设计的正确性，提高设计的质量。
(4)对设计进行评审或走查。
【问题2】
除设计外，张工还需要特别注意以下工程活动：
(1)需要细致分析原有系统。
(2)对于这样的改造项目，测试的难度和工作量很大，需要把握测试的工作。
【问题3】
如何提高这些工程活动的质量：
(1)在分析方面
①同客户充分沟通，了解原系统的业务需求；
②阅读原系统中的文档和程序，掌握设计和实现的情况；
③如果可能，与原系统的开发者联系，在原开发者的帮助下把握原系统；
④对分析的结果进行评审。
论文部分：
范文一
论信息系统项目的质量管理
[摘要]
本文以我主持过的某大型综合性企业信息化建设系统为例，探讨了信息系统项目的质量管理，指出项目质量管理在信息系统项目实施中具有重要地位和关键作用。在该项目中，我作为用户方的项目负责人参与了项目的管理工作，我在项目质量管理中，根据项目的实际情况和特点，有针对性地强化某些方面质量管理的工作，并采取了以下针对性的措施：进行充分的用户需求分析，用户需求分析是保证项目质量的基础；加强测试工作，并形成制度；代码走查，保证项目质量；执行变更控制，防止项目范围的无效蔓延。通过这些办法，成功的控制了项目的范围，保证了项目按时交付使用，保证了项目的质量，顺利完成了这个项目。
[正文]
项目质量管理是项目管理中一个非常重要的组成部分，项目质量反映软件产品满足规定需求和潜在需求能力的特征和特征的总和。项目质量的工作流程主要有项目质量规划，执行质量保证，执行质量控制。项目质量管理是一个项目能否顺利的完成并交付使用的一项基础性的工作。
2007年，某大型综合性企业为实现信息管理，准备开发了一套企业信息系统，功能主要包含了客户关系管理，项目管理，库房管理，财务管理，消息管理，工作流管理等，其中以项目管理为核心，实现对项目整个生命周期各个环节进行有效监控，实时动态反应项目各阶段执行情况，进行成本控制和成本分析；同时对工作流程进行可配置化管理，实现任务督办，消息提醒，协同办公等功能；计划投资600万元；采用C/S结构。我作为用户方项目负责人，参与了项目的管理工作。
在该项目管理工作中，我十分重视项目质量的管理和控制，借助项目软件MS Project
2003来辅助项目质量的计划和管理。在工作中，我根据实际情况，主要从用户需求分析，代码走查，强化测试工作，进行变更控制四个方面对项目质量进行有效管理，取得了较好的效果。
该系统在2008年一次上线运行成功，目前运行情况良好。
一、进行充分的用户需求分析，用户需求分析是保障项目质量的基础
充分的用户需求分析是准确确定项目质量的基础。在信息系统的项目质量管理中，需求的获取是信息系统质量管理内容中的重中之重，为此，我们工要做了以下工作。
首先，将与系统相关的用户进行分类以明确用户需求的来源及优先级。对于像这种涉及大型综合性企业几乎所有业务的大型信息系统的开发来说，用户需求的调查对象多种多样涉及到不同的部门或人员，为了更方便的从用户处获取有效的需求，我们将用户分成不同的类，如将其分为管理人员、业务人员、最终客户等，通过这种划分明确了需求的来源，在需求分析的理解出现不一致时可以有确定用户为需求分析人员提供“决策”。
其次，采用多种方式和途径获取用户的需求。在需求分析的初期我要求系统分析人员要深入到用户的工作现场中以观察用户是如何工作的，从而正确的把握用户需求的实质。同时为了更直观的与用户沟通，我们采用了Rational
Rose创建的用例（Use
Case）来展现用户的业务处理过程，并使用用例文档对其进行简要的描述，这样用户就能够很好的理解系统能够帮助其完成的工作任务，一般通过两到三次的沟通就能够确定用户的需求，极大的提高了用户需求获取的质量与效率。
二、代码走查
软件质量在很大程度上依赖于代码质量。在实际环境中对于
同一项目而言，由于项目组成员的编程能力、习惯、风格、对需
求的理解和个性的不同，所开发的代码质量也不尽相同。再加上
一些难以预测的人为因素，由此带来的隐患将严重影响代码质
量，最终造成软件质量低下，使得用户无法正常使用并为以后的 维护带来更大的工作量和难度。
考虑到项目进度以及实际情况，要进行完整的代码评审不太现实，因此，在软件开发过程中可以根据需要引进代码走查。每周在规定的时间内，轮流让程序员讲解其所开发代码的主要部分。这项措施一方面可以从侧面促使程序员本人注意所开发代码的质量，另一方面在走查过程中可以获得他人的意见进一步改善代码效率，使开发成员共享项目实施过程中问题解决的思路和方
法，同时还可以促进项目组成员之间的交流并加深对需求的理解，关注软件开发过程中的各个环节，并进行过程改善的讨论，使得软件质量更有保障。
三、加强测试工作，并形成制度
测试就是对软件产品的检验。软件测试的目的是根据用户需
求检查系统是否符合项目合同与任务书规定的要求。项目测试分
集成测试和系统测试，主要进行功能测试、健壮性测试、性能－
效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、 安装/
反安装测试等活动。测试过程通常在模拟环境中进行。只 有通过了上述全部测试的软件，才可以称之为符合用户质量要求
的合格的软件。
测试是保证软件质量的重要手段，也是让用户直观地了解软件质量和熟悉软件操作的有效途径。我有计划地强化测试环节，让用户由始至终地参与测试工作测试活动要尽可能覆盖整改项目过程，从最初的需求到部署
阶段，都应该制订详细的计划并编制相应的文档，如测试计划、
测试用例文档、测试报告等。通过测试活动，尽可能早得发现每
个阶段中软件存在的缺陷，以方便后续阶段的实施。在这测试活
动过程中，我们应该遵守一条基本原则——按照用户需求进行测
试。我们即不能为求速度而缩短测试规模，也不能忽视用户需求
而提高测试要求。总之，一切测试应该符合用户需求。
四、执行质量变更控制，防止项目范围的无效蔓延
变更是不要避免的，关键问题是如何对变更进行有效的控制。必须有一套规范的变更管理过程，在发生变更时遵循规范的程序来管理变更。对于发生的变更，需要识别是否在既定的项目质量之内。如果是在项目质量之内，那么就需要评估变更所造成的影响，以及应对的措施，受影响的各方都应该清楚明了自己所受的影响；如果变更是在项目质量之外，那么就需要商务人员与用户方进行谈判，看是否增加费用，还是放弃变更。因此我们在项目管理体系中应该包含一套严格、实用、高效的变更程序，它对管好项目至关重要。为了防止项目质量的无效蔓延，保证项目顺利进行，我觉得最好规定对客户的质量变更请求，一律通过书面变更申请提出，并经双方项目经理审核后，视不同情况，做出相应的处理。对于不涉及整个业务流程修改的变更，一般给予满足；涉及整个业务流程修改的变更，则视变更大小考虑是否满足用户要求。
经过努力，该系统一次上线运行成功，并在10个月后通过了验收。综上所述，进行充分的用户需求分析，用户需求分析是准确确定项目质量的基础；代码走查；强化测试，形成制度；执行变更控制，防止项目范围的无效蔓延，是我在某大型综合性企业信息化建设系统项目中的质量管理中的四个主要实践，为项目的成功奠定了坚实的基础。在以后的项目质量管理工作中，我要加强测试的系统性和科学性，更充分的进行用户需求分析，深化各方的沟通，协调好开发工作各个部分及各个方面的关系，更好地完成项目。
