（项目管理）项目管理师案例
分析
项目管理师案例分析
第 1章项目整体管理案例...............................................................5
1．1案例一：项目计划编制 ........................................................5
案例场景 ...............................................................5
1．1．2案例分析 .............................................................5
1．1．3参考答案 .............................................................7
1．2案例二：项目启动与项目经理角色 ..............................................7
案例场景 ...............................................................7
案例分析 ...............................................................8
参考答案 ...............................................................9
1．3案例三：项目管理部门职能 ...................................................10
案例场景 ..............................................................10
案例分析 ..............................................................11
参考答案 ..................................................................13
1．4案例四：可行性研究问题 .....................................................14
案例场景 ..............................................................14
案例分析 ..............................................................14
参考答案 ..............................................................16
第 2章项目范围管理案例..............................................................17
2．1案例一：范围定义 ...........................................................17
案例场景 ..............................................................17
案例分析 ..............................................................18
参考答案 ..............................................................19
2．2案例二：工作要点 ...........................................................19
案例场景 ..............................................................19
案例分析 ..............................................................20
参考答案 ..............................................................21
案例三：范围确认...........................................................21
案例场景 ..............................................................21
案例分析.............................................................22
参考答案 ..............................................................23
第 3章项目时间管理案例..............................................................23
3．1案例一：时间管理 ...........................................................23
案例场景 ..............................................................23
案例分析 ..............................................................24
参考答案 ..............................................................26
案例二：关键路径...........................................................26
案例场景 ..............................................................26
案例分析 ..............................................................27
参考答案 ..............................................................28
案例三：进度计划...........................................................28
案例场景 ..............................................................28
案例分析 ..............................................................28
参考答案 ..............................................................30
案例四：进度估计...........................................................30
案例场景 ..............................................................30
案例分析 ..............................................................30
参考答案 ..............................................................31
第 4章项目成本管理案例..............................................................32
案例一：成本估算...........................................................32
案例场景 ..............................................................32
参考答案 ..............................................................35
案例二：成本估算...........................................................35
案例场景 ..............................................................35
案例分析 ..............................................................36
参考答案 ..............................................................37
案例三：挣值管理...........................................................37
案例场景 ..............................................................37
案例分析 ..............................................................37
参考答案 ..............................................................39
案例四：成本控制............................................................39
案例场景 ..............................................................39
案例分析 ..............................................................40
参考答案 ..............................................................41
4．5案例五：投资决策 ...........................................................42
案例场景 ..............................................................42
案例分析 ..............................................................42
参考答案 ..............................................................43
第 5章项目质量管理案例..............................................................44
5．1案例一：计划及跟踪 .........................................................44
案例场景 ..............................................................44
案例分析 ..............................................................45
参考答案 ..............................................................46
案例二：团队协作...........................................................47
案例场景 ..............................................................47
案例分析 ..............................................................48
参考答案 ..............................................................49
案例三：质量与成本.........................................................49
案例场景 ..............................................................49
案例分析 ..............................................................50
参考答案 ..............................................................52
案例四：项目外包............................................................52
案例场景 ..............................................................52
案例分析 ..............................................................53
参考答案 ..............................................................54
案例五：设计的质量.........................................................55
案例场景 ..............................................................55
案例分析 ..............................................................56
参考答案 ..............................................................57
5．6案例六：软件测试 ...........................................................57
案例场景 ..............................................................58
案例分析 ..............................................................58
参考答案 ..............................................................59
第 6章项目人力资源管理案例..........................................................60
案例一：团队建设...........................................................60
案例场景 ..............................................................60
案例分析 ..............................................................60
参考答案 ..............................................................62
6．2案例二：项目团队 ...........................................................63
案例分析 ..............................................................63
参考答案 ..............................................................65
案例三：人性观点...........................................................66
案例场景 ..............................................................66
案例分析 ..............................................................66
参考答案 ..............................................................67
案例四：领导风格...........................................................68
案例场景 ..............................................................68
案例分析 ..............................................................68
参考答案 ..............................................................71
案例五：激励理论............................................................71
案例场景 ..............................................................71
案例分析 ..............................................................72
参考答案 ..............................................................74
第 7章项目沟通管理案例..............................................................74
7．1案例一：客户关系管理 .......................................................74
7．1．1案例场景 ............................................................74
案例分析 ..............................................................75
参考答案 ..............................................................77
案例二：沟通渠道............................................................77
案例场景 ..............................................................78
案例分析 ..............................................................78
参考答案 ..............................................................80
案例三：变更控制............................................................81
案例分析 ..............................................................82
参考答案 ..............................................................83
案例四：有效沟通............................................................84
案例场景 ..............................................................84
参考答案 ..............................................................86
案例五：项目经理...........................................................87
案例场景 ..............................................................87
第 8章项目风险管理案例..............................................................90
8．1案例一：风险分类 ...........................................................90
案例场景 ..............................................................90
案例分析 ..............................................................90
参考答案 ..............................................................92
8．2案例二：蒙特卡罗分析 .......................................................93
案例场景 ..............................................................93
案例分析 ..............................................................93
参考答案 ..............................................................94
案例三：电子政务项目风险....................................................95
案例场景 ..............................................................95
案例分析 ..............................................................95
参考答案 ..............................................................97
8．4案例四：风险管理方案 .......................................................98
案例场景 ..............................................................98
案例分析 ..............................................................98
参考答案 .............................................................100
案例五：合作项目的风险.....................................................100
案例场景 .............................................................100
案例分析 .............................................................101
第 9章项目采购管理案例.............................................................104
投标人资格.................................................................104
案例场景 .............................................................104
案例分析 .............................................................105
参考答案 .............................................................106
9．2案例二：评标标准 ..........................................................107
案例场景 .............................................................107
案例分析 .............................................................107
参考答案 .............................................................109
9．3案例三：技术采购 ..........................................................109
案例场景 .............................................................109
案例分析 .............................................................110
参考答案 .............................................................111
9．4案例四：非招标采购 ........................................................111
案例场景 .............................................................111
案例分析 .............................................................112
参考答案 .............................................................113
9．5案例五：合同履行 ..........................................................114
案例场景 .............................................................114
案例分析............................................................114
参考答案 .............................................................115
第 10章综合案例....................................................................116
案例一：投资收益分析 ......................................................116
案例场景一 ..........................................................116
案例分析 ............................................................117
案例二：可行性分析 ........................................................118
案例场景 ............................................................118
案例分析 ............................................................119
参考答案 .............................................................120
第 1章项目整体管理案例
项目整体管理是指在项目的整个生命周期内，汇集项目管理的知识领域，对所有项目计划，进
行整合执行及控制，以保证项目各要素相互协调的全部工作和活动过程。项目整体管理是从全局的、
整体的观点出发通过有机的协调项目各个要素(进度、成本、质量和资源等)，在相互影响的项目各
项具体目标与方案中权衡和选择，尽可能地消除项目各单项管理的局限性，从而实现最大限度地满
足项目干系人的需求和希望的目的。
1．1案例一：项目计划编制
阅读以下关于在信息系统项目管理过程中项目计划编制等综合管理问题的叙述，回答问题 1至
问题 4。
案例场景
某市电子政务信息系统工程，总投资额约 500万元，主要包括网络平台建设和业务办公应用系
统开发，通过公开招标，确定工程的承建单位是 A公司，按照《合同法》的要求与 A公司签订了工
程建设合同，并在合同中规定 A公司可以将机房工程这样的非主体、非关键性子工程分包给具备相
关资质的专业公司 B，B公司将子工程转手给了 C公司。
在随后的应用系统建设过程中，监理工程师发现 A公司提交的需求规格说明书质量较差，要求 A
公司进行整改。此外，机房工程装修不符合要求，要求 A公司进行整改。
项目经理小丁在接到监理工程师的通知后，对于第二个问题拒绝了监理工程师的要求，理由是
机房工程由 B公司承建，且 B公司经过了建设方的认可，要求追究 B公司的责任，而不是自己公司
的责任。对于第一个问题，小丁把任务分派给程序员老张进行修改，此时，系统设计工作已经在进
行中，程序员老张独自修改了已进入基线的程序，小丁默许了他的操作。老张在修改了需求规格说
明书以后采用邮件通知了系统设计人员。
合同生效后，小丁开始进行项目计划的编制，开始启动项目。由于工期紧张，甲方要求提前完
工，总经理比较关心该项目，询问项目的一些进展情况，在项目汇报会议上，小丁给总经理递交了
进度计划，公司总经理在阅读进度计划以后，对项目经理小丁指出任务之间的关联不是很清晰，要
求小丁重新处理一下。
新的计划出来了，在计划实施过程中，由于甲方的特殊要求，需要项目提前 2周完工，小丁更
改了项目进度计划，项目最终按时完工。
【问题 1】(6分)
请用 400字以内的文字，描述小丁在合同生效后进行的项目计划编制的工作。
【问题 2】(6分)
请用 400字以内的文字，描述小丁在处理监理工程师提出的问题是否正确？如果你作为项目经
理，该如何处理？
【问题 3】(6分)
在项目执行过程中，由于程序员老张独自修改了已进入基线的程序，小丁默许了他的操作。请
用 200字以内文字评论，小丁的处理方式是否正确，如果你是项目经理，你将如何处理上述的事情。
【问题 4】(7分)
假设你被任命为本项目的项目经理，请问你对本项目的管理有何想法，本项目有哪些地方需要
改进？
1．1．2案例分析
【问题 1】
项目计划是项目管理的基础，项目管理中最重要的就是项目计划的工作，项目计划是一个综合
概念，凡是为实现项目目标而进行的活动都应该纳入到计划之中。
项目计划的制订是贯穿这个项目生命周期的持续不断的工作，是利用其他计划编制过程的结果，
监理一份连贯性、一致性的文档，以指导项目实施和项目控制。项目计划过程是一个反复的过程。
一个详细的项目计划过程包括：
(1)项目计划的定义，确定项目的工作范围。
(2)确定为执行项目而需要的工作范围内的特定活动，明确每项活动的职责。
(3)确定这些活动的逻辑关系和完成顺序。
(4)估算每项活动的历时时间和资源。
(5)制订项目计划及其辅助计划。
一般而言，项目计划可以包含如下要素。
(1)项目范围计划：阐述进行这个项目的原因或意义，形成项目的基本框架，使项目所有者或项
目管理者能够系统、逻辑地分析项目关键问题及项目形成中的相互作用要素，使项目干系人在项目
开始实施前或项目相关文档编写以前，能够就项目的基本内容和结构达成一致；项目范围说明应当
形成项目成果核对清单，作为项目评估的依据，在项目终止以后或项目最终报告完成以前进行评估，
以此作为评价项目成败的依据；范围说明还可以作为项目整个生命周期监控和考核项目实施情况的
基础和项目其他相关计划的基础。
(2)项目进度计划：进度计划是说明项目中各项工作的开展顺序、开始时间、完成时间及相互依
赖衔接关系的计划。通过进度计划的编制，使项目实施形成一个有机的整体。进度计划是进度控制
和管理的依据，可以分为项目进度控制计划和项目状态报告计划。
(3)项目质量计划：质量计划针对具体待定的项目，安排质量监控人员及相关资源、规定使用那
些制度、规范、程序、标准。项目质量计划应当包括和保证与控制项目质量有关的所有活动。
(4)项目资源计划：决定在项目中的每一项工作中用什么样的资源(人、材料、设备、信息、资
金等)，在各个阶段使用多少资源。项目费用计划包括资源计划、费用估算、费用预算。
(5)项目沟通计划：沟通计划就是制定项目过程中项目干系人之间信息交流的内容、人员范围、
沟通方式、沟通时间或频率等沟通要求的约定。
(6)风险计划：风险计划是为了降低项目风险的损害而分析风险、制定风险应对策略方案的过程，
包括识别风险、量化风险、编制风险应对策略方案等过程。
(7)项目采购计划：项目采购计划过程就是识别哪些项目需求应通过从本企业外部采购产品或设
备来得到满足。
(8)变更控制、配置管理计划：由于项目计划无法保证一开始就预测得非常准确，在项目进行过
程中也不能保证准确有力的控制，导致项目计划与项目实际情况不符的情况经常发生，所以必须有
效处理项目的变更。变更控制计划主要是规定变更的步骤、程序，配置管理计划就是确定项目的配
置项和基线，控制配置项的变更，维护基线的完整性，向项目干系人提供配置项的准确状态和当前
配置数据。
【问题 2】
根据《中华人民共和国招投标法》第 48条：中标人应当按照合同约定履行义务，完成中标项目。
中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。
中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给
他人完成。接受分包的人应当具备相应的资格条件，并不得再次分包。
中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。
本案例中，A公司将子项工程分包给 B，B又将其分包给 C，显然违背了招投标法的这一条款。
根据条款中的内容，“中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责
任。”A公司显然要承担责任，同时 B公司也承担连带责任。
作为项目经理，不仅仅要做好项目的进度、质量、成本的控制管理，而且要注意避免陷入法律
陷阱中，因此，对《合同法》、《招投标法》都要有一定的了解。
【问题 3】
软件配置管理是贯穿软件开发过程始终的一项工作。对于一个软件项目来说，软件配置管理规
范至少包括以下的内容：
(1)配置项及其命名规则。
(2)配置库文件目录结构。
(3)角色和权限定义。
(4)配置项变更流程。
(5)配置项发布。
(6)基线定义和基线变更。
项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线(对工作产
品而言)，一般来说都要避免变更基线。对这两种不同的基线，其影响的范围不同，确立和变更方式
也不一样。
项目的基线变更控制委员会由客户代表、产品经理、项目经理和技术经理组成，对发布的里程
碑类基线的变更必须由变更控制委员会确认并由 QA进行变更记录，所有被变更影响的配置项都需要
重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改
并在 QA进行记录即可。
【问题 4】
作为项目经理，可以考虑首先从项目管理的 9大知识点出发简单阐述对本项目的一般性理解。
此外，从本案例中，你可以发现项目中的合同与招投标管理、配置与变更管理方面均发生了问题。
因此，可从本项目管理较弱的部分进行重点的阐述，如对法律法规的理解(招投标管理)，项目进度
管理、项目变更的控制。配置管理，以及进度计划的变更将导致质量和成本的变化，此外，还可从
进度、质量、成本三要素之间关系进行阐述。因为，基线的变更往往会带来成本、进度方面的变更。
1．1．3参考答案
【问题 1】(6分)
小丁在接到任务后开始项目计划的编制工作，编制的计划应包括：
(l)项目总计划(包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、
费用估算、进度计划以及费用计划)。
(2)项目辅助计划(质量计划、沟通计划、人力资源计划、风险计划、采购计划等)。
【问题 2】(6分)
根据《中华人民共和国招投标法》第 48条：中标人应当按照合同约定履行义务，完成中标项目。
中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。
中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给
他人完成。接受分包的人应当具备相应的资格条件，并不得再次分包。
中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。
本案例中，A公司将子项工程分包给 B，B又将其分包给 C，显然违背了招投标法的这一条款。
根据条款中的内容：“中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责
任。”A公司显然要承担责任，同时 B公司也负连带责任。
【问题 3】(6分)
本题中，在项目执行过程中，项目发生的变更，程序员老张擅自修改了已进入基线的程序，作
为项目经理的小丁不应该默许他的操作，且修改后的东西没有经过评审。
项目中缺乏变更控制的体系，需要建立变更控制流程，确保项目中所做的 变更保持一致，并
将产品的状态、对其所做的变更，以及这些变更对成本和时间表的影响通知给有关的项目干系人，
以便于资源的协调。同时，项目团队所有成员要清楚变更程序的步骤和要求。
提出以下建议：
(1)建立配置管理体系。
(2)建立变更请求流程。
(3)组建变更控制委员会。
【问题 4】(7分)
(1)从项目管理 9大知识点出发简单阐述本项目。
(2)从本项目管理较弱的部分进行重点的阐述，如对法律法规的理解(招投标管理)、项目进度管
理、项目变更的控制。配置管理及进度计划的变更将导致质量和成本的变化，描述进度、质量、成
本三要素之间的关系。
1．2案例二：项目启动与项目经理角色
阅读以下关于信息系统项目管理过程中项目启动与项目经理角色方面问题的叙述，回答问题 1
至问题 3。
案例场景
A公司是一家经营纸产品的企业，近几年业务得到了成倍的发展，原来采用手工处理业务的方
式已经越来越显得力不从心，因此，经过公司董事会研究决定，在公司推行一套管理软件，用管理
软件替代原有的手工作业的方式，同时，请公司副总经理负责此项目的启动。
副总经理在接到任务后，即开始了项目的启动工作。项目经过前期的一些工作后，副总经理任
命小丁为该项目的项目经理，小丁组建了项目团队，并根据项目前期的情况，开始进行项目的计划，
表 1一 1所示为初步项目进度计划表。
项目进行了一半，由于公司业务发展的需要，公司副总经理要求小丁提前完工，作为项目经理，
小丁对项目进行了调整，保证了项自的提前完工。
【问题 1】(7分)
请用 400字以内的文字描述你作为项目前期的负责人，在接到任务后将如何启动项目？
【问题 2】(9分)
作为项目经理，你项目的进度控制中的重点是什么？请描述你在项目进度控制中的甘特图，以
及双代号网络图，并比较甘特图与网络图的区别。
【问题 3】(9分)
假设公司总经理要求提前完工，作为项目经理将如何处理，请用 400字以内的文字描述你应该
如何处理？
案例分析
【问题 1】
项目的启动包括了以下几个主要活动：
1．识别需求
从投资方角度，识别需求是项目启动过程和整个项目生命周期的最初活动，在这个过程中，为
项目的目标确定，以及可行性分析和项目立项提供直接、有效的依据，为需求建议书的撰写提供基
础。
一旦确定了相关问题和需求，并证实了项目将得到益处，投资方就可以开始准备需求建议书。
从承建方的角度而言，识别需求就是得到客户的需求建议书，或得到客户初步需求意向后，项
目团队从技术实现、应用和项目实施角度识别客户的实际存在的问题、基本意图和真实想法，从而
达到与客户有效的沟通，准确分析需求和问题，为制定可行、正确的技术及实施解决方案提供依据。
承建方可以提交一份清晰的需求分析说明书，请客户予以确定，形成需求共识。
2.解决方案的确定
解决方案类似于向投资方(客户)提交的项目建议书。承建方在研究、分析投资方客户的需求建
议书后，结合当前情况，与客户交流，分析、制订实施解决方案。解决方案通常包含三个部分：
(1)技术方案部分：该部分应使投资方认识到，承建方理解需求或问题，并且能够提供风险最
低且受益最大的解决方案。
(2)管理部分：该部分应使投资方相信，承建方有能力做好项目所提出的工作，组织好项目的实
施。
(3)项目费用部分：该部分应使投资方相信，承建方项目建议书所提出的项目费用是符合实际的。
根据客户需求不同，对项目成本费用表述有所不同，部分项目要求提供总价或明细。
3．项目可行性分析
可行性分析的目的就是给决策者提供判断项目是否可行和投资决策的依据。
4.项目立项
经过项目可行性分析后，投资方确立具体的可投资项目或承建方确立可承接的项目的过程。
5.项目章程的确定
项目立项完成后，项目章程的制定和发布将是项目启动的一个结束标志。项目章程是企业内部
正式确认项目存在的企业文件。
本题中，项目前期的负责人实际是公司副总经理，在项目章程中确定项目经理的人选。
【问题 2】
(1)甘特图法
甘特图(Gantt Chart)也叫横道图或条形图，主要应用于项目计划和项目进度的安排。它把工程
项目中的各项作业，在标有日期的图表上用横线表示出其起止的时间。
甘特图把计划和进度安排两种职能结合在一起，纵向列出项目活动，横向列出事件跨度。项目
活动在左侧列出，时间在图表顶部列出，图中的横道线显示了每项活动的开始时间和结束时间，横
道线的长度等于活动的工期，甘特图顶部的时间段决定着项目计划的详略程度。
由于甘特图把项目计划和项目进度安排两种职能组合在一起，因此在绘制甘特图时，必须清楚
各项活动之间的关系，即哪些活动必须在其他活动开始之前完成，哪些活动可以同时进行。
甘特图直观、简单、容易制作，便于理解，一般适用比较简单的小型项目，可用于 WBS的任何
层次、进度控制、资源优化、编制资源和费用计划。但是不能系统地表达一个项目所包含的各项工
作之间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。
(2)网络计划技术
网络计划技术的原理是：从需要管理的任务总进度出发，以任务中各项作业的所需要的工时为
时间因素，绘制出网络图，明确而直接地反映出该项任务的全貌，各项作业的进度安排、先后顺序
和相互关系。
在选择计划方法编制项目进度计划
时应考虑以下因素：
①项目的规模和复杂程度；
②对项目细节的掌握程度；
③项目的时限性；
④项目总进度是否由少数几项关键
作业所决定。
对于问题 2，把项目进度计划表(表
1-1)进行转换，得到表 1-2.
根据表 1-2，绘制出甘特图如图 1一 1所示。
甘特图能够从时间上整体把握进度，很清晰地标识出直到每一项任务的起始与结束时间，但任
务之间的关系不能有效识别。
采用网络图进行进度控制，能够清晰地展现现在和将来完成的工程内容、各工作单元间的关系，
并且可以预先确定各任务的时差。了解关键作业或某一环节的进度的变化对后续工程和总工期的影
响度，便于及时采取措施或对进度进行调整。
【问题 3】
该问题主要考查项目管理中工期、成本、质量之间的关系。
作为项目经理要靠项目工期与成本的平衡，项目工期的缩短会使项目成本上升。譬如，缩短项
目工期就需要项目团队加班，加班就要支付加班工资和各种各样的赶工费用，同样，项目成本的降
低会使得项目组织资源占用的能力下降，从而也影响项目工期。
项目工期的缩短也可能使质．量下降，为了赶进度，导致质量问题的出现，而一旦出现质量问
题，就必须返工，这样又拖延了项目的工期。
项目成本的降低也直接影响质量问题，如出现偷工减料的情况。
作为项目经理，要统一考虑项目进度、资源配置、成本与质量之间的平衡。任何一个要素的变
动，都会引起其他要素的变动。
本题中，假设公司总经理要求提前完工，项目经理将如何处理。首先从网络图中我们可以发现
设计阶段与开发阶段存在 3天时间的空缺，因此，可把任务 D, E, F, G提前三天完成，此外，D,
E, F, G属于并行任务，还可以抽调任务 D,
E, F, G的部分人员到任务 H。
参考答案
【问题 1】 (7分)
本题中，项目前期的负责人实际是公司
副总经理，在项目章程中确定项目经理的人
选。作为项目前期的负责人，在接到项目的
任务后将开始项目的启动工作。项目的启动包括了以下几个主要活动：
(1)识别项目的需求。
(2)解决方案的确定。
(3)对项目进行可行性分析。
(4)项目立项。
(5)项目章程的确定。
【问题 2】(9分)
项目时间管理中的重点是把握好关键路径上的任务，项目甘特图绘制如图 1-1所示。
项目双代号网络图绘制如图 1一 2所示。
甘特图与网络图的区别：
甘特图直观、简单、容易制作，便于理解，一般适用比较简单的小型项目，可用于 WBS的任何
层次、进度控制、资源优化、编制资源和费用计划。但是不能系统地表达一个项目所包含的各项工
作之间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。
采用网络图进行进度控制，能够清晰地展现现在和将来完成的工程内容、各工作单元间的关系，
并且可以预先确定各任务的时差。了解关键作业或某一环节的进度的变化对后续工程和总工期的影
响度，．便于及时地采取措施或对进度进行调整。
【问题 3】(9分)
项目的质量、进度、成本相关联，因此，在进度控制和成本管理上考虑：
(1)在进度管理上，可以采用加班等方式进行。
(2)投入更多的人力、物力。
(3)把握关键路径上的任务。
在实际处理的过程中，因为新投入人力到项目，而且新的人力对项目的熟悉程度不一，新员工
需要经过一段时间的培训才能适应项目，所以，最佳的方式应该是采用加班方式来提前完成项目，
同时，项目经理应该调整进度计划，在关键路径上加班，缩短关键路径的长度。
1．3案例三：项目管理部门职能
阅读以下关于信息系统项目管理过程中项目管理部门职能问题的叙述，回答问题 1至问题 3。
案例场景
小王参加希赛网的 CMM培训以后，被公司任命为项目管理部经理。项目管理部是公司新设的部
门，主要任务是监督和管理各个项目组，对项目总监和公司总经理负责。
在日常工作中，小王发现，很多项目组成员并不重视自己领导的项目管理部。他们只听从项目
经理、项目总监和公司总经理的话，对项目管理部门提出的合理化建议置之不理，项目管理部门要
求他们定期提交的报告和材料也往往拖延，定期组织的汇报会也往往缺席。
项目管理部门由于得不到足够有效的数据和材料，所以无法及时知道各个项目组的实际情况，
无法做出正确的统计结果和决策，也无法正确指导各个项目组的实际工作。鉴于此，项目管理部对
各个项目组提出的建议往往与他们的意愿相左，一项目管理部向上级提交的材料和各个项目组向上
级提交的材料往往有些不符，这种情况使项目管理部遭到项目组和主管上级两方面的反感，处境极
其被动。
为此小王要求项目管理部门人员深入项目组，一方面培养感情、化解矛盾，另一方面获得各个
项目组的实际资料。但在策略实施过程中，项目组成员把项目管理部的成员视为上级的“耳目”和“监
工”，工作上不予配合。他们认为项目管理部成员挑错是故意找事，在错误是否应该修改这个问题上
和项目管理部成员争执十分激烈，有时差点要大打出手。
小王把这些情况反映给上级领导后，上级领导认为项目管理部没有存在的价值，决定要撤销这
个部门。小王有些想不通，通过 CMM项目过程管理，可以提高软件产品的质量，这是个不容置疑的
事实，可是到了这里怎么行不通了呢？
【问题 1】(8分)
在软件企业中，项目管理部门究竟有没有存在的价值，试说明原因，以 300字以内回答。
【问题 2】(8分)
如果想使公司项目管理部门继续存在，发挥其应有的作用，请 250字以内讲述小王应该怎么做。
【问题 3】(9分)
项目管理部门在项目开发中的质量管理主要包括哪些内容，以 500字左右回答。
案例分析
【问题 1】
本题考查考生整体把握组织级项目质量管理的能力。要想回答好该题，考生需要了解项目管理
部门在组织级项目质量管理中的作用。
企业设立项目管理部门极其重要，具有十分重要的存在价值。
从提高软件质量角度而言，企业设立项目管理部门的目的是以独立审查方式，从第三方的角度
监控软件开发任务的执行，就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层
提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组取得高质量的软件
产品。主要工作包括以下四个方面：
(1)通过监控软件开发过程来保证产品质量。
(2)保证开发出来的软件和软件开发过程符合相应标准与规程。
(3)保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。
(4)确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。
除此之外，该部门还要收集项目中好的实施方法和发现实施不利的原因，为修改企业内部软件
开发整体规范提供依据，为其他项目组的开发过程实施提供先进方法和样例。
从提高软件企业项目管理能力的角度而言，在当代企业中，项目的成败直接影响到组织战略目
标的实现，组织内部项目管理与执行能力直接影响到企业实现其战略目标的能力。虽然从项目目标
和执行层面上看，这些项目好像是孤立的、无关联的，但实际上，这些项目之间在组织内部存在着
以下共有的特性：
(1)这些项目的最终目标都是支撑企业既定战略的实现，为企业创造利润。
(2)这些项目共享组织的资源，资源的调配会在项目之间产生影响。
(3)共享项目的最佳实践将会提高整个组织实施项目的能力。
由此可以意识到，这些看似孤立的项目需要在组织层面上以某种方式进行统筹和管理，从而提
高整个组织的项目管理能力，有力地支撑组织战略目标实现。在企业内部，这些职能由项目管理部
门实现。
所以，项目管理部门是跨接在组织战略和项目之间的一座桥梁，可以帮助企业在组织层面上对
那些孤立的、无关联的项目进行统筹和管理，确保组织在项目选择、计划、实施，以及在处理项目
间冲突和问题时，以企业战略目标为导向，从而保证组织内部活动大方向一致性，进而提高整个组
织的项目管理能力，有力地支撑组织战略目标的实现，最终整体提升软件产品质量。
由此可知，管理部门通过科学管理，可以提高软件质量，提升企业的组织级项目管理能力，对
企业长期发展大有裨益。现阶段，由于广大企业没有意识项目管理的重要性，很多软件企业中还没
有与之相对应的人员和工作方法，整套关注软件开发过程的软件质量保证体系还没有建立起来，加
之管理部门人员经验不足、方法不当，实施过程明显带有试验性，所以效果还不是太明显，有时甚
至会产生冲突，这些都是难免的。但是建立项目管理部门是项目管理由人治到法治的必经阶段，是
进行软件过程改进不可缺少的部分。过了开始的不稳定阶段，当广大员工树立项目管理意识后，企
业才会发现设立该部门所带来的效益。
【问题 2】
本题考查考生在组织级项目质量管理中解决常见问题，进而提高项目管理部门权威的能力。要
想回答好该题，考生需要熟悉项目管理部门开展日常工作的特点、常用手段和技巧。
如果想使公司项目管理部门继续存在，发挥其应有的作用，小王应该采取下述措施：
(1)找一个失控的项目进行管理，使其回到正常的轨道并顺利地完成，使得领导意识到项目管理
部的作用，提升威信。
(2)因为新规范的执行需要一个适应过程，所以项目管理规范材料要应该结合公司现状逐步推行，
这样效果逐步显现，公司员工逐步接受，最终全面接受。千万不可操之过急，否则员工接受不了，
引起抵触情绪，效果不仅无法显现，反而会影响日常工作效率，而被认为没有价值、束之高阁。
(3)对公司员工进行项目管理培训，尽可能提高他们的项目管理意识。只有他们从思想上接受项
目管理，行动上才能采用项目管理标准严格要求自己，而不是应付了事。
(4)与公司高层沟通，尽可能获得高层支持，向高层要权，因为责权不对等也是项目管理中一个
常见问题。在本案例中，各个项目管理组的成员只听从项目经理、项目总监和公司总经理的话，而
项目管理部只有监督权，没有执行权，但是案例中项目管理部的工作开展需要一定的执行权，所以
需要按照责权对等的原则，请求高层领导给予一定的权利，便于工作开展。如果高层领导无法给予
所需的权利，那么只能退而求其次，扮演项目支持办公室的角色，任务是收集项目实施信息，提供
决策需要的支持信息，而不需要做出决定。
(5)项目管理部门的职责一般是监控项目实施，主要是发现项目中存在问题并督促项目组解决。
对于项目组内部存在的问题，除非十分有把握，一般不要轻易去管，那样极易使问题越搞越乱，从
而招致项目组反感。
(6)项目管理部在职能和行政上独立项目组，成为项目组的严师，有错必纠，但不要有错就上报，
以保障自身的独立性和评价的客观性；而在业务和工作上融入项目组，做他们的朋友，了解他们的
语言、思想和行为，更真实、更深入地评价他们与既定规范之间的偏差，并逐步引导他们走向正轨。
【问题 3】
本题考查考生进行组织级项目质量管理的能力。要想回答好该题，考生需要熟悉项目管理部门
在项目开发中的质量管理内容。
企业项目管理部门在项目开发中的质量管理内容包括以下四部分：
(1)决策阶段的质量管理
主要内容是在广泛搜集资料、调查研究的基础上研究、分析、比较，决定项目的可行性和最佳
方案。
(2)项目实施前的质量管理
①对项目组的能力重新审查，包括各个成员资质的审查。如果发现实际情况有所变化，必须采
取有效措施予以纠正。
②对所有的合同和技术文件、报告进行详细的审阅。如图纸是否完备，有无错漏空缺，各个设
计文件之间有无矛盾之处，技术标准是否齐全，等等。
③审阅进度计划和实施方案。
④对项目实施中将要采取的新技术、新软件进行审核，核查鉴定书和分析报告。
⑤对项目实施所需材料和设备的采购进行检查，检查采购是否符合规定的要求。
⑥协助完善质量保证体系。
⑦对各项目组负责人和主要人员进行进一步的审核。
⑧根据项目计划制定与其对应的质量管理计划。
⑨组织质量管理计划的评审，并形成评审报告。
⑩准备好项目人员简历、质量管理表格。
⑩准备好担保和保险工作。
⑩签发动员预付款支付证书。
⑩全面检查开工条件。
(3)项目实施中的质量管理
①参与项目的阶段性评审。该评审从保证评审过程有效性方面入手，如参与评审的人是否具备
一定资格，是否规定的人员都参与了评审，是否对评审对象每个部分都进行了评审，是否给出了明
确的结论等。
②参与项目阶段产品的审计。该审计通常是检查其阶段产品是否按计划、按规程输出并且内容
完整，这里的规程包括企业内部统一的规程，也包括项目组内自己定义的规程。
③对项目日常活动与规程的符合性进行检查。在两个阶段点之间设置若干小的跟踪点，来监督
项月的进行情况，以便能及时反映出项目组中存在的问题，并对其进行追踪。
④对配置管理一工作的检查和审计。主要监督项目过程中的配置管理工作是否按照项目最初制
定的配置管理计划实施。
⑤跟踪问题的解决情况。在项目组内一可以解决的问题就在项目组内部解决，对于在项目组内
部无法解决的一问题，或是在项目组中催多次也没有得到解决的问题，可以利用其独立汇报的渠道
报告给高层经理。
⑥收集新方法，提供过程改进的依据，便于下一步对规程进行修改和完善。
(4)项目完成后的质量管理
①监督检查项目测试情况。
②协助项目组完成项目验收。
③监督检查系统安装、试运行。
④进行项目实施后审计。
⑤总结项目实施的经验和教训。
参考答案
【问题 1】(8分)
从提高软件质量角度而言，企业设立项目管理部门的目的是以独立审查方式，从第三方的角度
监控软件开发任务的执行，同时辅助软件工程组取得高质量的软件产品。
从提高软件企业项目管理能力角度而言，项目管理部门可以帮助企业在组织层面上对那些孤立
的、无关联的项目进行统筹和管理，从而提高整个组织的项目管理能力，有力地支撑组织战略目标
的实现。
由此可知，项目管理部门具有十分重要的存在价值。现阶段，项目管理没有发挥出应有作用，
主要由于广大企业认识不够，经验不足，体系不健全。但这只是暂时现象，过了这段不稳定期，该
部门的存在价值就会发挥出来。
【问题 2】(8分)
(1)找一个失控的项目进行管理，使其回到正常的轨道并顺利地完成，使
得领导意识到项目管理部的作用，提升威信。
(2)项目管理规范材料要逐步推行，不可操之过急。
(3)对公司员工进行项目管理培训，尽可能提高他们的项目管理意识。
(4)与公司高层沟通，尽可能获得高层支持，向高层要权。
(5)项目管理部门的职责一般是监控项目实施，主要是发现项目中存在问题并督促项目组解决，
而不是解决项目组的问题，那样会招致项目组反感。
(6)项目管理部在职能和行政上独立项目组，而在业务和工作上融入项目组。
【问题 3】(9分)
企业项目管理部门在项目开发中的质量管理内容包括以下四部分：
(1)决策阶段
在广泛搜集资料、调查研究的基础上研究、分析、‘比较，决定项目的可行性和最佳方案。
(2)项目实施前
①对项目组的能力重新审查，如果发现实际情况有所变化，必须采取有效措施予以纠正。
②对所有的合同和技术文件、报告进行详细的审阅。
③审阅进度计划和实施方案。
④对项目实施中将要采取的新技术、新软件进行审查。
⑤对项目实施所需材料和设备的采购进行检查。
⑥协助完善质量保证体系。
⑦对各项目组负责人和主要人员进行进一步的审核。
⑧根据项目计划制定与其对应的质量管理计划。
⑨组织质量管理计划的评审，并形成评审报告。
⑩准备好项目人员简历、质量管理表格。
⑩准备好担保和保险工作。
⑩签发动员预付款支付证书。
⑩全面检查开工条件。
(3)项目实施中
①参与项目的阶段性评审。
②参与项目阶段产品的审计。
③对项目日常活动与规程的符合性进行检查。
④对配置管理工作的检查和审计。
⑤跟踪问题的解决情况。
⑥收集新方法，提供过程改进的依据。
(4)项目完成后
①监督检查项目测试情况。
②协助项目组完成项目验收。
③监督检查系统安装、试运行。
④进行项目实施后审计。
⑤总结项目实施的经验和教训。
1．4案例四：可行性研究问题
阅读以下关于信息系统项目管理过程中可行性研究问题的叙述，回答问题 1至问题 3。
案例场景
在项目计划和选择的过程中，需要完成的首要工作是对项目进行估算。项目估算的范围涉及方方
面面，例如项目或产品开发的范围、投入和回报、项目风险、作用和意义等。在传统信息系统工程
方法中，是以可行性研究的方式来组织对项目的主要估算内容的。在企业实际的业务过程中，可行
性研究通常作为一个重要的环节，被包含在整个项目立项，或项目选择和确认的过程中。
可行性研究的范围可能覆盖很广泛的技术、经济、执行、环境等各种需要评估的因素，但它并
不是最后的精细计划(例如：项目的时间进度及人员安排)。通常在进行可行性研究的阶段，甚至项
目的目标或产品的最终方向也是高度易变化的。但可行性研究的意义在于，虽然可行性研究不能指
出项目最终的精细计划和方向，但可行性研究可以在项目定义阶段用较小的代价识别出错误构思的
系统，从而规避未来更多的资源投入的损失(时间、资金、人力、机会)，或者因遭遇到无法逾越的
技术障碍或环境障碍导致的不可避免的失败。
对于那些可行性研究表明可执行的软件项目来说，可行性研究的结果也不承诺系统的收益一定
很巨大，或技术风险和资源投入就一定很低，但可行性研究的结果设立了一个“底线”，即：“如果
实施什么，则风险和收益是什么”这样的控制范围。这些评估结果给了未来的项目评估、项目风险
控制，甚至在资源剧烈变化的情况下有计划有重点地削减功能、重定义项目开发范围，或者选
择项目实施的方式提供了非常有价值的方向性指引。
【问题 1】 (7分)
可行性研究的步骤是什么？请使用列举的形式，不超过 100字回答。
【问题 2】(8分)
可行性研究报告是可行性研究的成果体现，请使用列举的形式，不超过 150字回答，可行性研
究报告主要包含什么内容？
【问题 3】(10分)
在可行性研究的基础上，还需要请第三方根据国家颁布的政策、法律法规等，从项目、国民经
济、社会角度出发，对拟建项目进行各方面的评估。请用不超过 50字的文字回答，项目评估报告主
要包含什么内容？
案例分析
【问题 1】
信息系统项目可行性研究的目的，就是用最小的代价在尽可能短的时间内确定以下问题：项目有
无必要？能否完成？是否值得去做？
(1)项目的必要性分析首先应确定信息系统项目的目标，即本项目想解决哪些问题。在信息系统
目标明确之后，如果目前已经有一个(或几个)信息系统正在被人使用，就需要认真分析现有的信息
系统。显然，如果现有的信息系统是完美无缺的，完全可以实现新系统的目标要求，谁都不会提出
开发新系统的要求。在通常情况下，现有系统必然存在某些缺陷，无法完全实现新系统的目标要求。
但这一点并不能成为开发新系统的理由，我们还应仔细分析现有系统对于新系统目标的实现的程度
如何，不能实现某个具体目标的原因是什么，经过改进性维护能否实现这些目标。
如果现有的信息系统经过简单的改进性维护就可以实现新的系统目标，就没必要重新开发一个
新系统。但在以下情况下，有必要开发新的信息系统。
①原有系统开发不规范，缺少必要的技术文档，原开发人员跳槽，新接手的开发人员很难维护
原有系统，维护成本可能会接近甚至超过新开发的成本。
②原系统采用落后的设计技术或因设计人员的水平所限，系统架构设计不合理，难以扩充和修
改。
③原系统设计虽然合理，也考虑到了日后的扩充，或因业务发展太快，远远超过原来的设想，
量变引起质变。
④原系统开发工具已过时，用落后的开发工具继续维护还不如用新的开发工具重新开发。
⑤原系统所基于的硬件或软件平台已过时，在原有平台继续维护已无必要，需要开发基于当前
流行平台的新系统。
在分析新系统项目开发的必要性时，一定要注意识别是真的“必要”还是假的“必要”。某些开
发单位，由于重开发、轻维护，新系统开发人员的地位和待遇远远高于现有系统的维护人员，维护
人员考虑到开发新项目的高待遇和成就感，为尽快转入新项目的开发，极力夸大原有系统维护的技
术难度和工作量，主张开发新系统，他们所提出的对比分析(维护 VS新开发)结果往往带有倾向性。
因此，应选择那些与项目本身无利害关系的技术专家进行项目必要性分析。当然，更重要的是，缩
小现有系统维护人员和新系统开发人员的收入差距。
另外，某些信息系统开发商往往利用客户(用户)“喜新厌旧”的心理，出于宣传和经营的需要，
每隔几年，即使没有太大的功能性和技术性突破，也要策划开发新的系统。有时当竞争对手推出或
即将推出新系统时，为保住自己的市场份额，即使条件不具备，也要迅速推出新的系统。这些问题，
应属于市场运营策略的范畴，在此不再赘述。
(2)项目的可能性分析
项目的可能性分析主要研究能否利用现有的或可能拥有的技术能力、资金、人力资源和物资等
方面的条件来实现信息系统的目标、功能、性能和其他指标，能否在规定的时间期限内完成整个项
目。由于项目的可能性分析以技术分析为主，因此也称为技术可行性分析。
项目可能性分析的主要内容如下：
①企业能力分析；
②项目技术来源分析；
③与项目相关的专利分析；
④项目负责人及技术骨干的资质分析；
⑤项目总体技术方案分析；
⑥项目创新点分析；
⑦项目技术可行性分析；
⑧项目技术成熟性分析；
⑨项目产品化分析等。
(3)项目投资及效益分析
明确了项目的必要性和可能性后，还要从投入产出的角度分析项目值不值得去做。项目投资及
效益分析，也称为经济可行性分析，主要对整个项目的投资及产生的经济项目进行分析。
该过程一般包括：
①项目投资预算分析；
②项目投资来源分析；
③市场需求与产品销售额分析；
④产品成本、利润与盈亏平衡点分析；
⑤投资回收期、投资收益率分析；
⑥社会效益分析。
可行性研究的步骤包括：
①确定项目规模和目标；
②研究正在运行的系统；
③建立新系统的逻辑模型；
④导出和评价各种方案；
⑤推荐可行性方案；
⑥编写可行性研究报告；
⑦递交可行性研究报告。
【问题 2】
可行性研究报告的编写目的是：说明该信息系统开发项目的实现在技术、经济和社会条件方面
的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。可以
参考国家标准《GBIT 8567-1988计算机软件产品开发文件编制指南》。
可行性研究报告的编写内容要求如下。
(1)引言：编写目的；背景；定义；参考资料。
(2)可行性研究的前提：要求；目标；条件、假定和限制；进行可行性研究的方法；评价尺度。
(3)对现有系统的分析：处理流程和数据流程；工作负荷；费用开支；人员；设备；局限性。
(4)所建议的系统：对所建议系统的说明；处理流程和数据流程；改进之处；影响；局限性；技
术条件方面的可行性。
(5)可选择的其他系统方案：可选择的系统方案。
(6)投资及效益分析：支出；收益；收益/投资比；投资回收周期；敏感性分析。
(7)社会因素方面的可行性：法律方面的可行性；使用方面的可行性。
(8)结论。
在进行可行性分析报告的编制时，必须有一个分析结论。结论可以是：
(1)项目可以立即开始实施。
(2)需要推迟到某些条件(例如资金、人力、设备等)落实之后才能开始实施。
(3)需要对开发目标进行某些修改之后才能开始实施。
(4)不能实施或不必实施(例如技术不成熟、经济上不合算等)。
【问题 3】
项目论证与评估是项目立项前的最后一关，“先论证，后决策”是现代项目管理的一项基本原则。
项目论证是指对拟实施项目技术上的先进性、成熟性、适用性，经济上的合理性、赢利性，实
施上的可能性、风险性进行全面科学的综合分析，为项目决策提供客观依据的一种技术经济研究活
动。根据论证执行主体的不同，项目论证可分为内部论证和外部论证。
项目论证与评估可以分步进行，也可以合并进行。实际上，项目论证与评估的内容、程序和依
据都是大同小异的，只是侧重点稍有不同，论证的对象可以是未完成的或未选定的方案，而评估的
对象一般需要正式的“提交”；论证时着重于听取各方专家意见，评估时更强调要得出权威的结论。
与项目可行性研究类似，项目论证与评估也要从必要性、可能性和投资效益等几个方面对项目
进行综合分析。但项目可行性研究一般是项目承担单位的主观性分析，往往是“不识庐山真面目，
只缘身在此山中”，而项目论证与评估则是第三方的客观性分析，可以从“横”、“竖”、“远”、“近”、
“高”、“低”等各种角度对项目的可行性进行评价。
项目论证与评估完成之后，应编写正式的项目评估报告。项目评估报告一般应包括以下内容：
(1)项目概况。
(2)评估目标。
(3)评估依据。
(4)评估内容。
(5)评估机构与评估专家。
(6)评估过程。
(7)详细评估意见。
(8)存在或遗漏的重大问题。
(9)潜在的风险。
(10)评估结论。
(11)进一步的建议。
因评估机构并无决策权，评估结论一般以建议的方式给出，如“建立立项”“建议不立项”“建
议补充材料，重新评估”等。
参考答案
【问题 1】(7分)
可行性研究的步骤包括：①确定项目规模和目标；②研究正在运行的系统；③建立新系统的逻
辑模型；④导出和评价各种方案；⑤推荐可行性方案；⑥编写可行性研究报告；⑦递交可行性研究
报告。
【问题 2】(8分)
可行性研究报告的编写内容包括：
(1)引言。
(2)可行性研究的前提。
(3)对现有系统的分析。
(4)所建议的系统。
(5)可选择的其他系统方案。
(6)投资及效益分析。
(7)社会因素方面的可行性。
(8)结论。
【问题 3】(10分)
项目评估报告一般应包括以下内容：
(1)项目概况。
(2)评估目标。
(3)评估依据。
(4)评估内容。
(5)评估机构与评估专家。
(6)评估过程。
(7)详细评估意见。
(8)存在或遗漏的重大问题。
(9)潜在的风险。
(10)评估结论。
(11)进一步的建议。
第 2章项目范围管理案例
项目的范围管理影响到信息系统项目的成功。在实践中，“需求蔓延”是信息系统失败最常见的
原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，无论是客户
的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目范围的失控，从而使得信息系
统项目无论在时间、资源和质量上都受到严重影响。
2．1案例一：范围定义
阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题 1至问题 3。
案例场景
希赛信息技术有限公司(CSAI原本是一家专注于企业信息化的公司，在电子政务如火如茶的时候，
开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于
电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着
全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要
求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网
的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。
张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，
有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模
型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目
交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符
合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻
辑层紧密耦合，导致 70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重
写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项
目工期也超出原计划的 100％。
【问题 1】(10分)
请不超过 300字，对张工的行为进行点评？
【问题 2】(9分)
请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超过 200字回答。
【问题 3】(6分)
请结合你本人实际项目经验，指出应如何避免类似问题？不超过 200字回答。
案例分析
这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。但项目管理中的任何
差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误
的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
张工对项目范围有一定的把握。在范围定义中，张工发现了不同行业间具有不同的特点，电子
政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该
行业一致的标准，这与企业信息化是完全不同的。张工捕获到该需求，并对这个需求进行了清晰的
定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用
户对保密性的要求。在这一点上，张工是成功的。如果在范围定义时忽略了行业标准，项目肯定会
招致更大的失败。
但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样，我们通常
称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。
对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很
强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大，大多数
访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之
一。很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。
对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。张工仅
仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。
对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。这些系统的最
终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目
组。但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出了更高的要求。
除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。当系统第
一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面
风格和操作风格，并设法进行确认。如果采取了恰当的措施，第二次的变更是完全可以避免的。
在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点都是项
目范围的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。
因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。因此在案例中，张工也没
有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。
对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑，这必
然增加变更的代价，从而导致大部分代码重写。若在项目初期意识到界面变更的风险，随之采用良
好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。
综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风险管理
和质量管理上也都存在缺陷。
有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义，
并最终满足了用户的要求；但不充分的范围定义和范围 确认招致了项目的失败，而采用了抗风险
能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期 100%.
因此第一题答案的要点就很明确了：
(1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
(2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交
付的重大变更。
(3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较
差的瀑布模型组织开发。
(5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
对于第二题，是在第一题的基础上考察对范围管理的理解，因此可以忽略在其他领域的问题。
在范围管理中主要包括如下内容：
(1)范围管理计划。
(2)范围定义。
(3)工作分解。
(4)范围确认。
(5)范围控制。
在本案例中，没有专门设计到范围管理计划和工作分解的内容。从表面上看，范围定义存在明
显的缺陷。但案例中提到系统又发生了第二次变更，由此可见，张工在范围确认和范围控制上也存
在不足。若在问题第一次出现时就进行有效的范围确认和范围控制，则完全可以避免第二次的变更。
因此，第二题的答案要点如下：
(1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。
项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任何疏忽
都可能招致严重的后果，造成项目的失败。而软件项目的复杂性又决定了项目中的工作环环相扣，
问题也总是相互关联的。在发现问题后，也需要采取多种手段才能彻底解决问题。这对信息系统的
项目经理来说是重大的挑战。
参考答案
【问题 1】(10分)
(1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2
分)
(2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交
付时的重大变更。(2分)
(3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。(2分)
(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较
差的瀑布模型组织开发。(2分)
(5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
(2分)
【问题 2】(9分)
(1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。(3分)
(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。(3分)
(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。(3分)
【问题 3】(6分)
有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。对于
本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助需求的
定义，避免范围定义不清晰的问题。
在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚
决避免需求的再次变更。
2．2案例二：工作要点
阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题 1至问题 2。
案例场景
M集团是希赛信息技术有限公司(CSAI )多年的客户，CSAI已经为其开发了多个信息系统。最近，
M又和 CSAI签订了新的开发合同，以扩充整个企业的信息化应用范围，张工担任该项目的项目经理。
张工组织相关人员对该项目的工作进行了分解，并参考了公司同 M曾经合作的项目，评估得到项目，
总工作量 60人月，计划工期 6个月。项目刚刚开始不久，张工的高层经理 S找到张工。S表示，由
于公司运作的问题，需要在 4个月内完成项目，考虑到压缩工期的现实，可以为该项目在增派两名
开发人员。张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史
上与 K企业合作的项目度量数据，该工作量是客观真实的。目前项目已经开始，增派的人手还需要
一定的时间熟悉项目情况，因此即使增派两人也很难在四个月内完成。如果强行要求项目组成员通
过加班等方式追逐 4个月完成的目标，肯定会降低项目的质量，造成用户不满意。因此，张工提出
将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制
定出两部分的验收标准，这样不增派开发人员也可以完成。高层经理认为该方案可以满足
公司的运作要求，用户也同意按照这种方案进行实施。六个月以后，项目在没有增加人员的前提下
顺利地完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，客户对最终交付的系
统也非常满意，项目组的成员也没有感受到很大的压力。
【问题 1】(10分)
请不超过 500字，指出张工是如何保证项目成功的？
【问题 2】(15分)
请不超过 500字，试结合案例指出项目范围管理的工作要点？
案例分析
这是一个成功的项目管理案例，项’目经理张工有效的运用范围管理，在不同的项目干系人中
达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。
作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于进行信
息系统开发项目而言，范围管理是其中最重要的技能之一。
软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制
的。软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对于相同的用户
价值可以定义出不同的系统需求。举一个简单的例子，用户的需求是“解决口渴的问题”，那么最简
单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水，更复杂的是递上一杯经过多层
过滤的纯净水，当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井茶。
用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目范围肯定会导致项目失败。
聪明的软件项目经理总是从范围管理开始，先界定系统的边界，然后再在明确的范围内进行时间、
成本、风险等的管理。
在项目中，时间、成本和范围构成了一个稳固的三角形，如图 2-1所示。
对于该三角形来说，任何一边都不可能孤立地改变。换句话说，我们不可能固定其中两边而试
图缩短第三边。其实这也是很容易理解的问题，如果项目需要做的东西已经确定(项目范围固定)，
项目的人员也已经确定(项目成本固定)，那么项目需要的时间就也是固定的。同理，已经固定的项
目投入和项目时间也只能做出固定的工作。对于这个三角形而言，非但不可能孤立地改变某一边的
长短，就是三边的变化比例不一致也不可能。不成比例的变化与孤立的改变某一边是一样的，都将
破坏三角形的结构，违反项目的客观规律，最终招致失败。因此有效的范围管理更像一门艺术，可
以帮助项目经理在已经确定的时间和成本下完成项目目标。
在本案例中，高层经理 S就提出了试图打破这个三角形的要求。他要求，项目组可以增加部分
资源，但要提前两个月完成。初一看，并没有在不增加投入的情况下要求项目提前完成，似乎合情
合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想，增加的资源和提前的时间还是不
成比例。项目经理张工深知此中奥妙，因此在听到高层经理的要求后，马上意识到这是一个不可能
完成的任务。
那么该如何解决这个矛盾呢？还是要从这个三角形入手。既然时间和资源的变化已经打破了项
目规律，那么不妨根据新的时间和资源来重新划定合理的项目范围，保证项目的正常运作。于是，
张工将这个项目拆分为两部分，重新定义这两部分的项目范围，使每一部分的范围都可以与已经确
定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规律，最终取得了成功。
在案例中，还有一些细节需要考生注意。张工最初估算整个项目需要花费 60人月的总工作量，
但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素，超出原计划
半个月是正常的。计划在 6个月内完成。在把项目拆分后，实际是用了 6个半月的时间，也就是花
费了 65人月完成了项目。对于上面介绍的时间、成本和范围的关系而言，仅是在理想情况下成立，
即项目成员始终能以固定的成本完成固定的工作。而在实际情况下，项目的工期、复杂度等因素都
会对项目造成影响。在案例中，虽然看似两部分工作的总和等于没有拆分前的项目，但这仅对于最
终目标而言，拆分后的项目增加了若干中间成果，项目的范围实际上还是扩大了。
因为软件项目的范围直接与需求相关，所以，很多人误认为控制项目范围就是控制需求，而控
制的方法就是减少需求的内容。这种理解是完全错误的。
范围控制体现在软件开发的各个阶段，很多范围控制并非是针对客户的要求而进行的。例如，
本案例中，范围控制就是针对高层经理的要求进行的。再比如，在设计中，我们既可以设计刚刚够
用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以对系统进行充分良好
的设计，甚至可能是过度设计。采取哪一种设计策略也是软件项目范围管理的一部分。项目经理可
以根据目前的项目的目标与环境出发，综合考虑质量和成本的约束，制定明确的项目范围，保证项
目的成功。根据笔者的经验，即时需求已经确定，通过有效的范围管理仍能给项目带来很大的收益，
可以在不牺牲软件质量的前提下通过范围管理来降低项目成本，缩短项目工期。
上面主要针对张工在范围控制方面进行了分析，实际在整个案例中，张工还进行了其他的范围
管理工作。
首先，在项目刚刚开始，张工就对项目范围进行了定义，进而划分了 WBS并对项目进行了估算
和计划。在 S提出需要缩短工期的要求后，张工首先进行了项目范围的控制，缩小了第一步需要完
成的项目范围。紧接着张工又对两阶段需要完成的项目范围进行了重新定义，制定了验收标准。最
后，张工对重新定义的范围进行了确认，与客户和高层经理达成一致。
对于项目而言，仅仅管理范围仍不能保证项目的成功。在这个案例中，张工也运用了其他的管
理手段。其中包括，张工对项目进行了估算，这属于项目时间管理的范畴；张工协调了多个项目干
系人之间的矛盾，这属于沟通管理的范畴。
有了上面的分析，这道考题的答案也就很清晰了。
参考答案
【问题 1】(10分)
(1)张工首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，制定了
WBS。
(2)张工对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。(2分)
(3)在出现新的项目目标后，张工对项目进行了范围控制，缩小了第一阶段实现的范围。(2分)
(4)张工对重新定义的项目范围进行了确认，与高层经理和客户达成一致。(2分)
(5)张工对项目进行了沟通管理，协调了多个项目干系人之间的矛盾。(2分)
【问题 2】(15分)
项目范围管理的要点：
(1)范围管理计划。(2分)
(2)范围定义。(2分)
(3)工作分解。(2分)
(4)范围确认。(2分)
(5)范围控制。(2分)
在本案例中，张工首先进行了范围定义和工作分解，得到了清晰的项目范围；在出现新的项目
目标后，张工进行了范围控制，重新定义了两个阶段的项目范围；最后，张工将重新定义的范围与
项目干系人进行了确认。(5分)
案例三：范围确认
阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题 1至问题 3.
案例场景
希赛信息技术有限公司(CSAI )刚刚和 M签订了一份新的合同，合同的主要内容是处理公司以前
为 M公司开发的信息系统的升级工作。升级后的系统可以满足 M公司新的业务流程和范围。由于是
一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研
负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。由于 M公司的业务非
常繁忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。张工认为，
双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此
定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。
进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定义，项
目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李
工的离职手续。
在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很
多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经不在项目组，没有人能
够清晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过 50%, M的业务代表也因为系
统的延期表示了强烈的不满。
【问题 1】(8分)
请以 400字对张工在项目管理工作中的行为进行点评。
【问题 2】(9分)
请从项目范围管理的角度找出该项目实施过程中的问题，以 500字内回答。
【问题 3】(8分)
请结合你本人项目经验，谈谈应如何避免类似的问题，以 500字内回答。
案例分析
这是一个失败的软件项目，与很多失败的软件项目一样，在系统需求上栽了跟头。开发与定义
软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建设的项目经理都
清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项目的失败。案例中的项
目经理张工就是既重视需求又没有控制好需求的一个例子。·
在案例中，张工接手了一个系统升级的软件项目。对于这样的项目，首先需要熟悉原有的系统，
然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新系统的需求问题。
这无疑是一个很好的办法，可以快速准确地把握新系统的需求。从这一点上来说，张工是成功的，
找到了合适的资源进行需求的开发与定义。李工也没有让张工失望，很快就整理出了新系统的需求，
并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽在张工的掌握之中。这是一
个阳光灿烂的开端，如果一切顺利的话，项目的成功也就是早晚的事情。就如同大多数经典的悲剧
故事一样，故事的序幕是美好的。
晴朗的天空飘来一块乌云，李工要移民加拿大。不过仅仅是一片乌云而已，并没有下起雨来。
开发出的需求都已经过设计，一些编码工作也已经开始，李工的工作已近圆满完成，毕竟，一些细
枝末节的问题还可以同客户直接沟通。
经过项目组努力，项目终于完成开发，准备发布了。这时，乌云开始下雨，问题爆发了。客户
不认可项目组的工作，认为很多需求没有实现，实现的功能也与需求不符。
谁是这个项目组的罪人呢？李工？还是张工？换一个思路考虑一下，如果李工没有离开项目组，
结果又会是什么样呢？客户会因为李工还在项目组就认可这个系统吗？很显然，不会。至多可以在
双发的协商下少一些变更，项目延期不是 50%,而是 30％而已。如果非要区分 50％和 30％的区别，
也不过是五十步笑百步而已。
从项目管理的角度来说，项目范围直接决定了工作量和工作目标，所以项目经理必须管理项目
的范围。在范围管理中，范围定义、范围确认和范围控制又是最核心的三项活动，缺一不可。范围
定义是基础的活动，不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义
的范围，是范围控制的依据。范围控制的作用在于减少变更，保持项目范围的稳定性。在案例中，
由于张工没有进行范围确认，最后的范围控制也就变成了无本之木，控制过程肯定变成了讨价还价，
失去本身的意义。
在软件系统的开发中，系统需求就是项目的范围。从软件诞生至今的几十年中，人们探索出了
很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定义出完美无误
的需求，需求中的缺陷必然存在，无法完全避免。因此需求确认或者说是范围确认就显得更为重要。
有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软件行业
的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要进行范围确认，
而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审、详
细记录最原始的调研材料，让客户确认调研报告、采用迭代开发逐步确认系统需求，都是可以采用
的方法。这些方法虽然没有直接确认需求分析报告，但至少可以让现有需求在项目组和客户之间达
成一致，提供范围控制的基准，一样可以达到范围确认的目的。
再回到这个案例，项目经理张工乐观认为李工开发的需求没有什么问题，也误认为双方已经有
良好的合作，在不紧逼要求客户代表签字显得不近人情，于是就抱着侥幸信息进入了开发。然而最
终的结果是，项目延期严重，业务代表反而更不满意，张工也要承担项目延期造成的成本增加的责
任。
有了上面的分析，后面问题的答案就不难得出。首先看第一个问题，对张工的行为进行点评。
前面已经提到，张工注意到了需求的问题，专门找到了原系统需求负责人李工进行需求开发，这是
对项目有利的一面。但由于缺少需求评审和确认的过程，造成需求中的缺陷没有被及时发现，系统
需求没有与客户确认，造成缺少需求控制的基准，最终导致需求的重大变更。
对于第二题，联系范围管理的知识，我们不难发现张工在范围确认和范围控制中都有重大的缺
陷，在范围定义中也由于缺乏评审造成需求的质量问题。
在完成第二题后，第三题就水到渠成了，第三题的要点见参考答案，此处不再赘述。
参考答案
【问题 1】(8分)
(1)张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定义的效
率和质量。(2分)
(2)张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发现。
(3)张工没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差。(2分)
(4)张工对需求的不能进行缺乏有效控制，最终造成项目延期 50%.(2分)
【问题 2】(9分)
该项目实施过程中的主要问题包括：
(1)在范围定义中，张工没有对李工定义的需求进行评审，造成需求中的质量缺陷没有被及时发
现。(3分)
(2)在范围确认中，张工没有主动地要求用户对需求进行确认。(3分)
(3)在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需
求变更。(3分)
【问题 3】(8分)
对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求中的问
题。对已经定义的需求需要与用户进行确认，保证双方理解的一致。在发生需求变更时，也应该采
取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围。
第 3章项目时间管理案例
项目管理的首要任务是制定一个构思良好的项目计划，以确定项目的范围、进度和费用。在给
定的时间完成项目是项目的重要约束性目标，能否按进度交付是衡量项目是否成功的重要标志。因
此，进度控制是项目控制的首要内容，是项目的灵魂。同时，由于项目管理是一个带有创造性的过
程，项目不确定性很大，项目的进度控制是项目管理中的最大难点。
3．1案例一：时间管理
阅读以下关于信息系统项目管理过程中时间管理问题的叙述，回答问题 1至问题 4。
案例场景
小张为希赛信息技术有限公司(CSAI) IT主管，最近接到公司总裁的命令，负责开发一个电子
商务平台。小张粗略地估算该项目在正常速度下需花费的时间和成本。由于公司业务发展需要，公
司总裁急于启动电子商务平台项目，因此，要求小张准备一份关于尽快启动电子商务平台项目的时
间和成本的估算报告。
在第一次项目团队会议上，项目团队确定出了与项目相关的任务如下：
第一项任务是比较现有电子商务平台，按照正常速度估算完成这项任务需要花 10天，成本为
15000元。但是，如果使用允许的最多加班工作量，则可在 7天、18750元的条件下完成。
一旦完成比较任务，就需要向最高层管理层提交项目计划和项目定义文件，以便获得批准。项
目团队估算完成这项任务按正常速度为 5天，成本 3750元，如果赶工为 3天，成本为 4500元。
当项目团队获得高层批准后，各项工作就可以开始了。项目团队估计需求分析为 15天，成本
45000元，如加班则为 10天，成本 58500元。
设计完成后，有 3项任务必须同时进行：①开发电子商务平台数据库； ②开发和编写实际网页
代码；③开发和编写电子商务平台表格码。估计数据库的开发在不加班的时候为 10天和 9000元，
加班时可以在 7天和 11250元的情况下完成。同样，项目团队估算在不加班的情况下，开发和编写
网页代码需要 10天和 17500元，加班则可以减少两天，成本为 19500元。开发表格工作分包给别的
公司，需要 7天、成本 8400元。开发表格的公司并没有提供赶工多收费的方案。
最后，一旦数据库开发出来，网页和表格编码完毕，整个电子商务平台就需要进行测试、修改，
项目团队估算需要 3天，成本 4500元。如果加班的话，则可以减少一天，成本为 6750元。
【问题 1】(6分)
如果不加班，完成此项目的成本是多少？完成这一项目要花多长时间？
【问题 2】(6分)
项目可以完成的最短时间量是多少？在最短时间内完成项目的成本是多少？
【问题 3】(6分)
假定比较其他电子商务平台的任务执行需要 13天而不是原来估算的 10天。小张将采取什么行
动保持项目按常规速度进行？
【问题 4】(7分)
假定总裁想在 35天内启动项目，小张将采取什么行动来达到这一期限？在 35天完成项目将花
费多少？
案例分析
本案例主要考查项目的时间管理。时间管理是项目管理的一项关键内容，其目的就是合理的分
配项目资源、保证项目能够按照进度计划按时完成。时间管理的主要工作包括了项目活动的定义、
对任务、活动进行排序、对每项活动的工期估算、制订项目的进度计划、资源共享分配、监控项目
进度等内容。
1．项目活动定义
项目活动定义的目的是将项目工作分解为更小、更易管理的工作包也叫活动或任务，这些小的
活动应该是能够保障完成交付产品的可实施的详细任务。将所有活动列成一个明确的活动清单，并
且让项目团队的每一个成员能够清楚有多少工作需要处理。
在该案例中，已经完成了对活动的定义，总共定义了 7项任务：
(1)比较现有电子商务平台。
(2)向最高层管理层提交项目计划和项目定义文件。
(3)电子商务平台设计需求。
(4)开发电子商务平台数据库。
(5)开发和编写实际网页代码。
(6)开发和编写电子商务平台表格码。
(7)测试，修改。
2．活动排序
在产品描述、活动清单的基础上，要找出项目活动之间的依赖关系和特殊领域的依赖关系、工
作顺序。
设立项目里程碑是排序工作中很重要的一部分。里程碑是项目中关键的事件及关键的目标时间，
是项目成功的重要因素。里程碑事件是确保完成项目需求的活动序列中不可或缺的一部分。比如在
开发项目中可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。
在进行项目活动排序时一般采用优先图示法、箭线图示法、条件图示法、网络模板这 4种方法，
最终形成一套项目网络图。
3．项目活动工期估算
项目活动工期估算是根据项目范围、资源状况计划列出项目活动所需要的工期。在估算工期时
要充分考虑活动清单、合理的资源需求、人员的能力因素，以及环境因素对项目工期的影响。在对
每项活动的工期估算中应充分考虑风险因素对工期的影响。
一般说来，工期估算可采取以下几种方式：
(1)专家评审。专家的判断主要依赖于历时的经验和信息。
(2)类比估算。使用以前类似的活动的完成事件作为当前活动工期的估算基础，计算评估工期。
(3)基于数量的历时。由工程/设计所确定的每一特定类型工作所需完成的工作量，乘以生产率，
所得结果用于估算活动历时。
(4)保留时间。工期估算中预留一定比例作为冗余时间，以应付项目风险。
4.安排进度表
项目的进度计划意味着明确定义项目活动的开始和结束日期。进度表的确定应根据项目网络图、
估算的活动工期、资源需求、资源共享情况、项目执行的工作日历、进度限制、最早和最晚时间、
风险管理计划、活动特征等统一考虑。
5．进度控制
进度控制主要是监督进度的执行状况，及时发现和纠正偏差、错误。在控制中要考虑影响项目
进度变化的因素，项目进度变更对其他部分的影响因素，以及进度表变更时应采取的实际措施。
根据本题的场景描述，共有 7项主要任务。首先对任务编号并进行任务的排序，编号及排序如
表 3-1所示。
第二步：根据题目信息
比较正常的时间和赶工的时
间，以及正常费用和赶工费
用，同时计算出赶工费用率，
如表 3-2所示。
第三步：根据活动编号
画出该项目的双代号网络图，
如图 3-1所示。
【问题 1】
对于该问题，需要进行关键路径的计算，关键路径法(CPM)的工作原理是：为每个最小任务单位
计算工期、定义最早开始和结束日期、最迟开始和结束日期、按照活动的关系形成顺序的网络逻辑
图，找出必需的最长的路径，即为关键路径。
一般可以通过两个原则来确认关键路径：
(1)总持续时间最长的线路称为关键线路。
(2)总时差最小的工作组成的线路为关键线路。
由此判断，关键路径为：①②③④⑥⑧⑨。
累加关键路径上的时间即为完成这一项目所要
花费的时间。
【问题 2】
显然在赶工情况下项目完成时间最短，因此，
累加关键路径上赶工的时间即可得出项目完成最短
工作量，累加赶工成本即可得出在最短时间内完成项目的成本是多少。
容易产生的失误地方就是在关键路径的选择上，被题干中所描述的“最短时间量”所迷惑，在④
-⑤开发电子商务平台数据库、④-⑥开发和编写实际网页代码、④-⑦开发和编写电子商务平台表格码
这三项任务上选择④-⑤或④-⑥，导致时间量和项目成本计算全部出错。
【问题 3］
假定比较其他电子商务
平台的任务执行需要 13天而
不是原来估算的 10天。那么，
由于①-②比较其他电子商务
平台位于关键路径上，因此，
将导致整个工期延长 3天，为
此，小张必须考虑赶工来保证
项目按进度完成。赶工原则是“采用
优先考虑赶工费用率最低的工作”。根据
表 3-3推导出表 3-4.
根据表 3-4的信息，为保证项目
完成，要求在关键路径上赶工 3天，
赶工费用率最低的是②-③，但②-③进行赶工 2天后，还差 1天。此时，可以在关键路径④-⑥上赶工 1
天，使得④-⑥的完成时间变为 9天，但此时④-⑥的赶工导致④-⑤也必须赶工 1天。由此，计算出
赶工的费用。本题容易产生错误的地方为：只考虑了④-⑥赶工的费率，而没有考虑④-⑤相应的变
化。
【问题 4】
与问题 3类似，同样，必须采用赶工的方式，也必须考虑关键路径上活动的变化导致了其他
非关键路径的变化的情况。由于，原有关键路径上的工期为 10+5+15+10+3=43，现要求 35天完成，
因此，必须赶工 8天时间。
首先，我们列出并行的 3个任务④-⑤、④-⑥．、④-⑦的赶工费用率，如表 3-5所示。
④-⑦是不可调整的，④一⑥赶工时间为 8，因此，最多可赶工 2天，如表 3-6所示。
赶工的优先顺序如表 3-7所示。
因此，赶工费用为 103150+750+3750+3500+2250=113400.
参考答案
【问题 1】(6分)
本题的关键是确定关键路径，完成这一项目要花 43天。如果不加班，完成此项目的成本是 103150
元。
【问题 2】(6分)
项目可以完成的最短时间量是 30天，在最短时间内完成项目的成本是 127 650元。
【问题 3】(6分)
在关键路径②一③“向最高管理层提交项目计划和项目定义文件”进行赶工 2天后，在关键路
径④-⑥“开发和编写实际网页代码”上赶工 1天，同时，在④-⑤“开发电子商务平台数据库”也
必须赶工 1天。
【问题 4】(7分)
总共需要赶工 8天，在②-③“向最高管理层提交项目计划和项目定义文件”上赶工 2天，在①
-②“比较现有电子商务平台”上赶工 3天，在④-⑤“开发
电子商务平台数据库”，④-⑥“开发和编写实际网页代码”上赶工 2天，在⑧-⑨“测试，修改”
上赶工 1天。
在 35天内完成项目将花费为 113400元。
案例二：关键路径
阅读以下关于信息系统项目管理过程中时间管理问题的叙述，回答问题 1至问题 3。
案例场景
希赛信息技术有限公司(CSAI)是一家从事制造行业信息系统集成的公司，最近，公司承接一家企
业的信息系统集成的业务。经过公司董事会的讨论，决定任命你作为新的系统集成项目的项目经理，
在你接到任命后，开始制订进度表，这样项目才可以依照进度表继续下去。
在与项目团队成员探讨后，假设已经确认了 12项基本活动。所有这些活动的名称、完成每项活
动所需的时间，以及与其他活动之间的约束关系如表 3-8所示。
【问题 1】(8分)
为了便于对项目进度进行分析，可以采用箭线图法和前导图法来描述项目进度，请画出项目进
度计划中箭线图和前导图。
【问题 2】(8分)
本题中的关键路径有几条，并给出关键路径？
【问题 3】(9分)
你要花多长时间来计划这项工作？如
果在任务 B上迟滞了 10天，对项目进度有
何影响？作为项目经理，你将如何处理这
个问题？
案例分析
【问题 1】
活动排序通常采用的工具为网络图，
包括前导图法和箭线图法 2种。
1．前导图法
前导图法，也称单代号网络图法，是
一种利用方框代表活动，并利用表示依赖
关系的箭线将节点联系起来的网络图的方
法。每个节点活动会有如下几个时间点：最
早开始时间(ES),最迟开始时间(LS),最早结束时间(EF),最迟结束时间(LF)。这几个时间点通常作为
每个节点的组成部分。
2．箭线图法
箭线图法是一种利用箭线代表活动，而在节点处将活动连接起来表示依赖关系的编制项目网络
图的方法。这种方法也叫做双代号网络法。
在箭线图表示法中，给每个事件指定一个惟一的号码。活动的开始事件叫做该活动的紧前事件，
活动的结束事件叫做活动的紧随事件。
箭线图法和前导图法存在以下的区别：
(1)双代号网络图中的每一项工作都由两个对应的代号来表示；而单代号网络图中的每一项工作
则由一个独立的代号来表示，每一个节点都表示一项工作。
(2)在双代号网络图中，工作间的逻辑关系可借助于虚工作(虚箭号)来表示，而在单代号网络图
中，工作间的逻辑关系则用箭号来表示，因此单代号网络图中不会出现虚箭号。在一幅单代号网络
图中，只会出现两个虚设的工作节点，那就是表示计划开始的虚工作节点和表示计划结束的虚工作
节点。
【问题 2】
问题 2是时间管理的计算试题，考察应试人员对关键线路的掌握程度。为每个最小任务单位计
算工期，定义最早开始和结束日期、最迟开始和结束日期，按照活动的关系形成顺序的网络逻辑图，
找出必需的最长的路径，即为关键路径。
在项目管理中，关键路径是指网络终端元素的元素序列，该序列具有最长的总工期并决定了整
个项目的最短完成时间。绘制其项目网络图如图 3-2所示。
一个项目可以有多个并行的关键路径。另一个总工期比关键路径的总工期略少的一条并行路径
被称为次关键路径。
关键路径的工期决定了整个项目的工期。任
何关键路径上的终端元素的延迟将直接影响项目
的预期完成时间本题解题方法有多种，如转换成
单代号网络进行计算。在每个任务上标识出最早
开始时间和最早完成时间。
整个项目工期为18,根据图3-2可以判断出，
工作的关键点为 C、E、I、J。
关键路径为①总持续时间最长的线路称为关键线路；②总时差最小的工作组成的线路为关键线
路。由此判断，关键路径为：ACFIL、ACFJL、ACEGIL、ACEGJL。
【问题 3】
对于问题 3，由于 B推后了 10天，导致关键路径发生改变，其单代号网络图变换如图 3-3所示。
所以，整个项目工期为 27天，对比于原来的 18天，整个进度延迟了 9天。
参考答案
【问题 1】(8分)
(1)箭线图法。如图 3-4所示。
(2)前导图法。如图 3-5所示。
【问题 2】(8分)
关键路径共有 4条，分别为：ACFIL、ACFJL、ACEGIL、ACEGJL
【问题 3】(9分)
作为项目经理，要花费 18天时间完成项目。如果
在任务 B上迟滞了 10天，则整个项目进度将推后 9天。
案例三：进度计划
阅读以下关于信息系统项目管理过程中时间管理问题的叙述，回答问题 1至问题 4。
案例场景
项目时间管理由一系列过程组成，其中，活动排序过程包括确认且编制活动间的相关性。活动
被正确地加以排序，以便今后制订易实现、可行的进度计划。排序可由计算机执行(利用计算机软件)
或用手工排序。
希赛信息技术有限公司(CSAI)承担一项信息网络工程项目的实施，公司员工小丁担任该项目的
项目经理，在接到任务后，小丁分析了项目的任务，开始进行活动手工排序。
其中完成任务 A所需时间为 5天，完成任务 B所需时间为 6天，完成任务 C所需时间为 5天，
完成任务 D所需时间为 4天，任务 C, D必须在任务 A完成后才能开工，完成任务 E所需时间为 5天，
在任务 B、C完成后开工，任务 F在任务 E之后才能开始，所需完成时间为 8天，当任务 B、C, D完
成后，才能开始任务 G,任务 H，所需时间分别为 12天、6天。任务 F、H完成后才能开始任务 I, K,
所需完成时间分别为 2天、5天。任务 J所需时间为 4天，只有当任务 G和 I完成后才能进行。
项目经理据此画出了如图 3-6所示的工程施工进度网络图。
【问题 1】(6分)
该项目经理在制订进度计划中有哪些错误？同时，请计算相关任务时间的六个基本参数？
【问题 2】(6分)
项目经理于第 12天检查时，任务 D完成一
半的工作任务，E完成 2天的工作，以最早时间
参数为准判断 D、E的进度是否正常？
【问题 3】(6分)
由于 D, E, I使用同一台设备施工，以最
早时间参数为准，计算设备在现场的闲置时间。
【问题 4】(7分)
H工作由于工程师的变更指令，持续时间
延长为 14天，计算工期延迟天数。
案例分析
【问题 1】
根据案例描述对任务进行定义，工作分解结构如表 3-9所示。
据此，画出进度计划的网络图，如图 3-7所示。
而本案例中，并没有表现出来任务 G的进行的前提条件是任务 B, C, D的完成。相关任务时间的
六个基本参数可分为两组。
第一组参数为以下三个：
(1)最早开始时间 ES。
(2)最早完成时间 EF 。
(3)自由时差 FF。
第一组参数的基本计算原则如下：
(1)从网络图左侧向右侧计算。
(2)将起始节点设定为 0点坐标。
(3)某项工作有多项紧前工作时，
其最早开始时间取多项紧前工作最早完
成时间的最大值。
第二组参数为以下三个：
(1)最迟开始时间 FS。
(2)最迟完成时间 FF。
(3)总时差 TF 。
第二组参数的基本计算原则如下：
(1)从网络图右侧向左侧计算。
(2)保持工期不变的倒计时排序。
(3)某项工作有多项紧后工作时，其最迟完成时间取多项紧后工作最迟开始时间的最小值。
关于时间间隔的计算，紧后工作的最早开始时间减去本项工作最早完成时间就是本工作与紧后
工作之间的时间间隔。
自由时差，是指在不影响所有紧后工作最早开始时间的情况下，某项工作可以利用的机动时间。
某项工作有几个紧后工作，对应的就有几个时间间隔，但是自由时差只有一个，即所有时间间隔的
最小值。
可以采用以下方法之一求得 TF总时差：
(1)本工作的最迟完成时间一本工作的最早完成时间
(2)本工作的最迟开始时间一本工作的最早开始时间
总时差的一个简单算法是计算
工期减去从网络图的起始节点至终
点节点经过本项工作最长的时间。
根据以上规则，计算最早开始
时间和最早完成时间。如表 3-10所示。
根据表 3-10,得出完成任务的时间为 29。根据网络图，从后往前推可以得到最迟开始时间和最
迟完成时间，如表 3一 11所示。
【问题 2】
可根据问题 1中的表得出，任务 D最早完成时间应为 9，任务 E最早完成时间应为 15，所以，
任务 D已经延期，此时任务 D已经完成一半，即 2天，所以，还需 2天时间才能完成任务，即 12+2=14
天。
【问题 3】
D,E,I的任务跨度如表 3-12所示(以最早时间参数为准，根据表 3-10得出)：
由于 D,E,I使用同一台设备施工，所以，完成任务时间为三个任务时间累加，为 4+5+2=11。而
三个任务最早开始于 5(任务 D)，最早完成为 25(任务 I)，任务时间跨度为 20,因此，设备空闲时间
为 20-11=9天。
【问题 4】
根据表 3-10得出表 3-13。、
H任务原定时间为 6天，现延长至 14天，则 H的最早完成时间为 24(表 14)。
与其相关的任务作调
整，如表 3-15所示。
参考答案
【问题 1】(6分)
①并没有表现出任务 G的进行的前提条件是任务 B、C、D的完成。
②6个基本参数的计算：
s1-2=0 EFl-2=0+5＝5
ESl-3＝0 EFl-3=0+6=6
ES2-3＝5 EF2-3＝5＋5＝10
ES2-4=5 EF2-4 = 5+4＝9
ES3-5＝10 EF3-5＝10+5＝15 FFl-2＝min|0, 0|＝0
ES6-8＝23 EF6-8＝23+5 =28
ES7-8＝25 EF7-8＝25+4＝29
计算最迟完成时间、最迟开始时间、总时差，其计算顺序是从后往前计算的。
LF7-8＝29 LS7-8＝29一 4＝25
LF6-8＝29 LS6-8＝29一 5＝24 TF6-8＝29一 28 =1
LF6-7=25 LS6-7=25一 2＝23 TF6-7=25一 25 =0
LF4-6= 23 LS4-6=23一 6=17
【问题 2】(6分)
D：计算进度第 9天完成。实际第(12+4-2)＝14天完成，拖期 5天。E:计算进度第 15天。实际
第(12+3)=15天完成，说明进度正常。
【问题 3】(6分)
D工作最早完成时间为第 9天，E工作最早开始时间为第 10天，设备闲置 1天； E工作为第 15
天，I工作为第 23天开始，设备闲置 8天；故设备总共闲置 8+1=9天。
【问题 4】(7分)
原计划工期 TC=29，时间发生后 TC=30。因此，延迟的工期天数为 1天。
案例四：进度估计
阅读以下关于信息系统项目管理过程中项目进度估计问题的叙述，回答问题 1至问题 2。
案例场景
A公司计划把现有的骨干系统改建成新的系统，该项目中是一个大型项目。
王总对该项目的进度估计如表 3-16所示。
用项目网络图表示对进度的估计，如图 3-8所示。
【问题 1】(10分)
用进度估计表中的字母代号把未写进项目网络图中的工作写进项目网络图中去。
【问题 2】(15分)
由于市场发生变化，A公司想把此项目的进度缩短两个月。在此假定前提下，系统的规模不能缩
小，移交计划和工作，以及部件测试以后的工作不能缩短。此时应该采取什么措施，并简述其理由。
案例分析
项目网络图是项目所有活动，以及它
们之间逻辑关系(相关性)的一个图解表示。
图 3-9,图 3-10表示的是同一项目网络图
的两种不同画法。网络图可手工编制，也可用计算机实现。网络图应伴有一个简洁说明，以描述基本
排序方法。但对不平常排序应充分地加以叙述。
(1)前导图法(PDM )是编制项目网络图的一种方法，利用节点代表活动而用节点间箭头表示活动
的相关性。图 3-9表示一个用 PDM法编制的简单网络图，这种方法也叫活动在节点法(AON)是大多数
项目管理软件包所采用的方法。PDM法可用手算也可用计算机实现。
有四种相关的前驱关系。
①结束一开始：某活动必须结束，然后另一活动才能开始。
②结束一结束：某活动结束前，另一活动必须结束。
③开始一开始：某活动必须在另一活动开始前开始。
④开始一结束：某活动结束前另一活动必须开始。
在 PDM法，结束一开始是最常见逻辑关系，开始一结束关系极少使用。(也许只有职业进度计划
工程师使用)对管理软件，如果用开始一开始、结束一结束或开始一结束关系会产生混乱的结果，因
为很多管理软件编制时并没有对这三种类型的相关性加以考虑。
(2)箭头图方法(ADM)是项目网络图的另一种方法，箭线表示活动，用节点连接箭线，以示相关
性。图 3-10表示用 ADM法制作的一个简单项目网络图。这种技巧也叫箭线代表活动(AOA)，虽比 PDM
法较少使用，但在某些应用领域仍是一种可供选择的技巧。ADM仅利用结束一开始关系以及用虚工
作线表示活动间逻辑关系。ADM法可手算也可在计算机上实现。
项目网络图经常不正确地被称为 PERT图 (计划评审技术) 。实际上，PERT图是一类特殊类型
的项目网络图，今日这种图很少应用了。
【问题 1】
不管怎样，首先要完成项目网络图，由于这是常
画的图，总能够正确地画出来。画好的项目网络图如图
3-11所示。英文字母后面的数字是所需时间(月数)。
【问题 2】
图 3-11的关键路径是 A3-B3-C5-P8-Q10-H4-R2(用
粗线表示)。所需时间是 35个月。但是，与移交有关的
工作和单元测试以后的工作不能缩短，也就是说
P8-Q10-H4-R2不能缩短，能够缩短的只有A3-B3-C5。
此时必须注意以下两点：
(1)缩短设计工作的时间，往往会在以后发生重大问题。
(2)新的系统是在“现有的骨干系统”的基础上改建的。这就是总量的关键所在，也是这个题目
不像看上去那么容易的原因所在。可供考虑的措施，只有把 P8提前到 B3之后(④)开始，而不是在 C5
之后。我们需要找出能够这样做的理由。
根据上述内容，我们可以这样说：
①应该移交的内容在概要设计完成后就已经清楚了。
②即使需要做一些小的调整，在 C5完成之后也来得及。
那么这样做之后是否能够缩短两个月呢？从④到⑩，修改前需要 23个月。修改后，关键路径变
成 C5-D5-E4-F3-G4，需要有 21个，正好缩短了两个月。
还应该注意的是，P-Q路径以前限制在 18个月内完
成，现在可以放宽到 21个月了。因此，可以断定上述措
施是切实可行的。
参考答案
【问题 1】(10分)(图 3-13)
【问题 2】(15分)
措施：在概要设计 B完成后即开始制定移交计划 P。
理由：
a．原有计划的关键路径是，只有设法缩短这条路径才行。
b.不能缩短，而缩短设计工作的时间又会产生不良的后果。
c.根据新系统的特性，在概要设计完成后就完全可以着手制定移交计划。
这样做可以允许多用 3个月的时间把移交计划和移交工作做得更好。
第 4章项目成本管理案例
项目的成本是项目的全过程所耗用的各种费用的总和。项目的成本管理对于组织来说非常重要，成
本管理并不只是把项目的成本进行监控和记录，而是需要对成本数据进行分析，以发现项目的成本
隐患和问题，在项目遭受可能的损失之前采取必要的行动。
项目成本管理希望节约项目的费用，但并不意味着要一味减少成本。例如：在信息系统项目中，
减少测试无疑能够减少项目的费用，但没有测试，如同许多曾经进行过的信息系统一样，把用户当
做测试者，可能对项目造成灾难性的后果，最终，或者使得项目的成本大为提高，或者让项目走向
失败的边缘。
案例一：成本估算
阅读以下关于信息系统项目管理过程中成本估算方面问题的叙述，回答问题 1至问题 3。
案例场景
希赛信息技术有限公司(CSAI主要致力于为国内教育提供信息化服务，成立业内一流的研发中
心，不断研究和推出深受用户欢迎的软件产品，客户遍布中国每个省/市/自治区。公司创立 8年来，
通过不断加强和改进技术管理来完善产品和提升服务品质，已成为中国教育软件研发领域首家通过
CMM3评估项目的公司。
张工是 CSAI的项目经理，1个月前刚接手某高校学生管理系统研发项目。完成项目需求调研后，
张工开始制定详细的进度和成本计划。表 4-1和表 4-2
分别是张工用两种方法做的项目成本估算，估算货币单位为(元)。
【问题 1】(8分)
请用 200字以内说明信息系统项目管理过程进行成本估算的基本方法。
【问题 2】(8分)
表 4-1和表 4一 2分别采用了什么估算
方法，表中估算成本 A, B各为多少？
【问题 3】(9分)
请结合你本人的实际项目经验，用 300字以内文字分析信息系统项目成本估算过程中的主要困
难和应该避免的常见错误。
案例分析
【问题 1】
信息系统开发项目中常用的成本估算方法包括自顶向下估算法、自下而上 估算法、参
数估算法、专家估算法和猜测估算法等，其中自顶向下估算法也称为类比估算法。
(1)自顶向下估算方法
自顶向下估算法是从项目的整体出发，进行类推，即估算人员根据以往完成类似项目所消耗的
总成本或工作量，来推算将要开发的信息系统的总成本或工作量。然后，按比例将它分配到各个开
发任务单元中，是一种自上而下的估算形式，通常在项目的初期或信息不足时进行。例如，在合同
期和市场招标时等。不是非常精确的时候或在高层对任务的总的评估的时候采用这种方法。该
方法的特点是简单易行和花费少，但具有一定的局限性，准确性差，可能导致项目出现困难。
(2)自下而上估算方法
自下而上估算法是利用工作分解结构图，对各个具体工作包进行详细的成本估算，然后将结果
累加起来得出项目总成本。用这种方法估算的准确度较好，通常是在项目开始以后，或者 WBS已经
确定的开发阶段等，需要进行准确估算的时候采用。它的特点是这种方法最为准确。它的准确度来
源于每个任务的估算情况，非常费时费力。估算本身也需要成本支持，而且可能发生虚报现象。
(3)参数估算方法
参数估算法是一种使用项目特性参数建立数据模型来估算成本的方法，是一种统计技术，如回
归分析和学习曲线。数学模型可以简单也可以复杂。有的是简单的线性关系模型，有的模型就比较
复杂。一般参考历史信息，重要参数必须量化处理，根据实际情况，对参数模型按适当比例调整。
每个任务必须至少有一个统一的规模单位。例如，平方米(m2)，米(m)，台，KLOC，FP，人/天，人/
月，人/年等。其中的参数如 xx 元/m2, xx 元/m, xx元/台，xx 元/KLOC, xx元/FP, xx元/人/天。
一般说存在成熟的项目估算模型和具有良好的数据库数据为基础时可以采用。它的特点比较简单，
而且也比较准确，是常用的估算方法。但是，如果模型选择不当或者数据不难，也会导致偏差。
通常有两类模型用于估算成本，即成本模型和约束模型。
成本模型是提供工作量或规模的直接估计，常常有一个主要的成本因素，例如规模，还有很多
的次要调节因素或成本驱动因素。典型的成本模型是通过历史项目数据，进行回归分析得出的基于
回归分析的模型。
约束模型显示出两个或多个工作量参数，持续时间参数或人员参数之间时间变化的关系。例如，
PRICE-S和 Putman模型。
(4)专家估算法
专家估算法是由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，
取得多个估算值，最后得出综合的估算值。其中最著名的是 Delphi方法，该方法的基本步骤如下：
①组织者发给每位专家一份信息系统的规格说明和一张记录估算值的表格，请他们估算。
②专家详细研究软件规格说明后，对该信息系统提出 3个规模的估算值。
．最小值 ai；
．最可能值 mi
．最大值 bi。
③组织者对专家表格中的答复进行整理，计算每位专家的平均值 Ei=(ai+4mi+bi)/6然后计算出
期望值：E=El+E2+…En/n 。
④综合结果后，再组织专家无记名填表格，比较估算偏差，并查找原因。
⑤上述过程重复多次，最终可以获得一个多数专家共识的软件规模。
(5)猜测法
猜测法是一种经验估算法，进行估算的人有专门的知识和丰富的经验，据此提出一个近似的数
据，是一种原始的方法，只适用于要求很快拿出项目大概数字的情况，对于要求详细估算的项目是
不适合的。
在实际软件项目中，进行软件规模成本估算时常常考虑三种模型：自顶向下估算法、自下而上
估算法、参数估算法。自下而上法费时费力，参数法比较简单，自下而上法与参数法的估计精度相
似。但是各种方法不是孤立的，应该注意相互结合使用。类比法通常用来验证参数法和自下而上法
的结果。
最后，介绍一下目前企业软件开发过程中常用的软件成本估算方式，它是一种自下而上和参数
法的结合模型，步骤如下。
(1)对任务进行分解。
(2)估算每个任务的最大值 max,最小值 min,平均值 avg。
(3)计算每个任务的估算值 Ei=(max+4avg+min)/6。
(4)计算直接成本=El+E2+…+Ei … +En。
(5)计算估算成本=直接成本＋间接成本。
(6)计算总成本＝估算成本＋风险基金＋税。
其中
风险基金＝估算成本×a％(一般情况：a为 10-20左右)
税=估算成本× b%(一般情况为 5左右)
间接成本是指直接成本之外的成本。如安装、培训、预防性维护、备份与恢复的费用，以及与
运行系统相关的劳务和材料费、管理费、相关补助费用及其他等。
【问题 2】
表 4-1采用了自下而上的成本估算方法，表 4-2采用了参数法成本估算方法。
项目经理的成本是 30元/小时，项目经理张工参与项目的时间是 500小时，而分析人员的成本
参数是 20元/小时，2个分析人员，每人参与项目时间是 500小时，编程人员的成本参数是 13元/
小时，2个编程人员，每人参与项目时间是 1000小时，由于参数模型是简单的线性模型，所以，很
方便计算出人力成本是 61000元；其间接成本包括一般管理费和额外费用，一般管理费是人力成本
的 35%，额外费用是人力成本和管理成本的 20％；这样合计为 98820元；还有设备费用及其间接费
用 13000元，项目成本总计 111820元，详见表 4-3.
对于表 4-1，估计分解之后每个任务的规模，然后总计项目的总规模成本。
采用自下而上的估算方法，用的模型是：
估算总值＝估算值＋风险基金＋税
其中
估算值=直接估算值＋间接估算值
间接估算值=直接估算值× 15%
风险基金=估算值× 20%
税=估算值×5%
要求估算的误差应该保持在－5%～+5%
按照这个算法并根据表 4-3的 WBS的分析结果图示，估算过程如下：
直接成本＝202000元
间接成本＝202 000 × ＝3030元
估算值＝202 000+3 030＝23230元
总成本＝23 230+23 230 × 20%+23 230 × 5 %＝元
经过计算，两表中 A为 202000元，B为 111820元。
【问题 3】
综合起来，信息系统的项目成本估算的困难主要包括以下方面：
(1)需求信息的复杂性。与其他有些传统项目不同，信息系统要满足的是人的主观需要。由于人
的复杂性，给信息系统带来了无数的难以确定的因素。对信息系统的估算自然是个复杂的工作，而
现实中往往不允许在项目的初期投入太多的资源，对项目的成本进行估算。而且，随着项目的进展，
许多具体情况的明确，项目的成本估算也会相应地有所变化。
(2)开发技术与工具的不断变化。开发工具软件的不断升级，技术方案的不断更新，这些技术的
进步让信息系统项目可以提供功能越来越强、使用越来越方便的产品或者服务，但是都给信息系统
项目的成本估算带来困难。
(3)缺乏类似的项目估算数据可供参考。有效的项目成本估算是建立在大量的同类项目的成本结
算的基础上的。没有大量的同类项目的经验，信息系统项目的成本估算也就非常困难。许多组织并
不注意整理和收集本组织内部的信息项目的成本数据，更不要说去收集整理其他组织的成本数据了。
(4)缺乏专业和富有经验的人才。可以根据同类项目的历史成本来估算当前项目的成本，历史项
目和当前项目的不同点和相同点是估算过程中需要判断的重要问题，这种判断需要估算人员有丰富
的经验和专业知识。
(5)信息系统研发人员技术能力的差异。在信息系统建设的成本中，有很大一部分是人力资源的
成本，而不同人员的不同的态度、经验和能力都会造成不同人员的截然不同的效率，这也给信息系
统的成本估算带来极大的困难。
(6)管理层的压力与误解。管理层会要求对项目成本进行估算，但是他们所需要的往往是期待一
个比他们所预计的要小的值，以便能够赢得合同或者投资。
在对项目进行成本估算时，应该避免以下的常见错误。
(1)草率的成本估算。由于市场和管理层的压力，项目组成员或者管理者被迫在没有进行真正准
备的情况下做出成本估算。如何面对管理层的压力，向管理层的压力，向管理层解释如何才能得到
较为准确的项目成本估算也是对项目管理者的沟通能力的考验。
(2)在项目范围尚未确定时就进行成本估算。在信息系统中也非常常见，往往是项目组对该做什
么，不该做什么还只有一个粗略的概念时就要进行成本估算。
(3)过于乐观或者保守的估算。过于乐观的估算会给项目组的项目实施带来很大的压力。而过于
保守的估算也会由于 Parkinson定律(时间充裕时，工作随之膨胀，收入增加时，花销随之增长)也
会对项目造成不利影响，甚至可能让组织放弃本来可能是有利可图的项目。
参考答案
【问题 1】(8分)
信息系统项目进行成木估算的基术方法包括：
(1)自顶向下估算法或类比估算法。
(2)自下而上估算法。
(3)参数估算法。
(4)专家估算法。
(5)猜测估算法等。
【问题 2】(8分)
表 4-1采用了自下而上的成本估算方法，表 4-2采用了参数法成本估算方法。经过计算，两表
中估算值 A为 202000元，B为 111820元。
【问题 3】(9分)
综合起来，信息系统的项目成本估算的困难主要包括以下方面：
(1)需求信息的复杂性。
(2)开发技术与工具的不断变化。
(3)缺乏类似的项目估算数据可供参考。
(4)缺乏专业和富有经验的人才。
(5)信息系统研发人员技术能
力的差异。
(6)管理层的压力与误解。
在对项目进行成本估算时，应
该避免以下的常见错误：
(1)草率的成本估算。
(2)在项目范围尚未确定时就
进行成本估算。
(3)过于乐观或者保守的估算。
案例二：成本估算
阅读以下关于信息系统项目管
理过程中成本估算问题的叙述，回
答问题 1至问题 4。
案例场景
希赛信息技术有限公司(CSAI )凭借丰富的行业经验和精湛的技术优势，坚持沿着产品技术专业
化道路，为银行、证券、保险等领域提供完整全面的解决方案。李工是 CSAI证券事业部的高级项目
经理，目前正负责国内 B银行信贷业务系统的开发项目。作为项目经理，李工必须制定高质量的项
目管理计划，以有效实现范围、进度、成本和质量等项目管理目标。
项目正式立项后，李工制定了一份初步的项目成本计划。李工估计出了每项工作的工期及所需
要的工作量，如表 4-4所示。此外，表 4-4也给出了每项工作除人力资源费用外的其他固定费用(如
硬件设备和网络设备等)。
【问题 1】(6分)
请计算表 4-4中每项工作所需安排的人力资源数量(按每天 8小时工作制计算)。
【问题 2】(6分)
假设每种人力资源的小时成本如下：测试员 30元/小时，程序员 40元/小时，软件设计师 60元
/小时，系统分析师 100元/小时。请计算每项工作所需的总费用(每周按照 5个工作日计算)。
【问题 3】(6分)
计算每项工作每周的平均费用(每周按照 5个工作日计算)。
【问题 4】(7分)
假设该项目计划的甘特图如图 4-1所示，请绘制该项目的费
用预算曲线图(时间单位为周，每周按照 5个工作日计算)。
案例分析
甘特图(Gantt chart)是在 20世纪初由亨利·甘特开发的。
它基本上是一种线条图，横轴表示时间，纵轴表示要安排的活
动，线条表示在整个期间上计划的和实际的活动完成情况。甘
特图直观地表明任务计划在什么时候进行，以及实际进展与计划要求的对比。图 4-2是一个手工绘
制的图书出版项目甘特图。
一般的项目管理软件如 Primavera公司的 p3和 Microsoft公司的 Project等都提供甘特图自动
生成工具。
时间以月为单位表示在图的下方，主要活动从上到下列在图的左边。计划需要确定书的出版包
括哪些活动，这些活动的顺序，以及每项活动持续的时间。时间框里的线条表示计划的活动顺序，
空白的现况表示活动的实际进度。甘特图作为一种控制工具，帮助管理者发现实际进度偏离计划的
情况。在本案例中，除了打印长条校样以外，其他活动都是按计划完成的。在费用预算方面，如按
时间坐标来分析，有两种表现方式：一是费用预算曲线图，二是费用预算累计曲线图。图 4-3和图
4-4为 Project 2000绘制的费用预算曲线图和费用预
算累计成本曲线图。
人力资源数=工作量÷8÷工期，如方案设计阶段系
统分析师人数=160÷8÷10=2,其他阶段计算类似；
总费用=固定费＋工作量×成本，如详细设计阶段
总费用=6 400+160×60=16000, 其他阶段总费用计算
类似。各阶段总费用累加得到项目总费用为 493000.
平均每周费用＝总费用÷(工期÷5),如主界面设计
阶段平均每周费用=73000÷(50÷5)=7300。
参考答案
【问题 1】(6分) 【问题 2】(6分)【问题 3】(6分)
参考答案见表 4-5。
【问题 4】(7分)
根据图 4-1和表 4-5计算每周费用总和，如图 4-5所
示。
案例三：挣值管理
阅读以下关于信息系统项目管理过程中挣值管理和项目成本管理方面问题的叙述，回答问题 1-
问题 4。
案例场景
财政基本建设管理信息系统是一套能够为财政服务，提供财政基本建设资金管理，财务监督、
审核，为财政的基建科、预算科和国库科等相关部门提供数据互享的工程项目管理的应用系统。系
统充分地体现财政部门对基本建设项目的管理，对国家预算安排的基本建设资金的使用的管理，反
映财政部门对基本建设项目的管理，更好地实现财政的管理监督的职能作用。
张工是大型电子政务系统集成商希赛信息技术有限公司(CSAI )的项目经理，目前正作为项目经
理负责 CSAI与某地财政局开发的基本建设管理信息系统项目，项目组成员包括项目经理 1人、系统
分析师 1人、高级程序员 3人、程序员 3人、软件界面美工 1人、测试人员 2人、客户方技术人员 2
人。由于财政年度等因素，项目的计划工期为 40周，预算成本为 50万元。根据该项目的需求和进
度等要求，项目具有工期紧、技术要求高、业务复杂等特点。为顺利实现项目进度和质量等目标，CSAI
项目管理部门和高层领导对该项目格外重视，要求项目组每周汇报进度状态。
在项目的实施过程中，第 19周时张工向公司经理报告项目的进展状态，在状态报告中经理列出
了第 18周(包含第 18周)的项目状态数据，详细情况如下：
(1)截至项目状态日期，项目实际已完成的工作量为 50%.
(2)截至项目状态日期，项目已完成工作量的实际成本(AC)为 28万元。
(3)截至项目状态日期，项目的计划成本(PV)为 26万元。
【问题 1】(6分)
试确定项目截止到项目状态日期已完成工作量的挣值 EV 。
【问题 2】(6分)
预测项目结束时的总成本 EAC 。
【问题 3】(6分)
请对该项目在费用控制方面的执行状况进行分析。
【问题 4】(7分)
项目经理在检查经费超支时发现，有一项任务 F还没有开始实施，但为 F任务购买设备的支票
已经支付，其费用为 4万元。另外，还有一张已经支付的支票，其费用为 3万元，是作为整个 H任
务的硬件费用，但 H任务在状态日期完成的工作量为 40%.根据这一信息再预测项目结束时的总成本。
案例分析
挣值管理(Earned Value Management)，是一种综合了范围、进度计划、资源和项目绩效度量的
方法，它通过对计划完成的工作、实际挣得的收益、实际花费的成本进行比较，以确定成本与进度
是否按计划进行，提供分析、决策依据，从而选取不同的应对措施，以保证最终完成项目目标。
根据图 4-6在测量时间点上，有必要先了解 14个重要的概念，如表 4-6所示。
(1)应完成多大工作量？
计划成本 PV(Planned Value)，也称为计划工作的预
算成本(BCWS)。
在图 4-6中，PV＝1000元。
(2)“已完成”工作的成本是多少？
实际成本 AC(Actual Cost)，也称为已完成工作的实
际成本(ACWP)。
在图 4-6中，AC＝1100元。
(3)已完成多大工作量？
挣值 EV(Earned Value)，也称为已完成工作的预算成本(BCWP)。
对 EV的解释：有一项任务预定在测量时间点上完工，其计划成本为 1000元。但只完成这项任
务的 95%0这样，就完成了 950元的工作量，这就是挣值(EV)。
(4)成本偏差 CV(Cost Variance)： CV＝EV-AC
CV是项目任务的挣值与实际成本之间的差异，已完成了 950元的工作量(EV)，但为完成这一工
作实际花费了 1100元(AC)。完成这项工作比原先预想的多花了 150元(CV)。
(5)进度偏差 SV(Schedule Variance)
SV＝EV-PV
SV是项目或项目任务的挣值与预算值之间的差异。对于一项工作，原先预计到测量时间点为止
会完成 1000元的工作量(PV)。而实际上完成了 950元的工作量(EV)。这样，就比原计划少完成了 50
元的工作量(SV)。
(6)成本绩效指数 CPI(Cost Performance Index)： CPI＝EV÷AC
CPI是总挣值除以总成本。仍以图 4一 6为例，已完成了 950元的工作量(EV)，而为完成这项
工作花了 1100元(AC)。实际花一元完成了 元的工作量(成本与绩效之比)。
(7)进度绩效指数 SPI(Schedule Performance Index)： SPI＝EV÷PV
SPI是总挣值除以总预算成本。在图 4一 6中，已完成了 950元的工作量(EV,)，而计划工作的
价值是 1000元(PV)。这样，计划完成一元工作量，实际完成了 元的工作量(进度绩效之比)。
(8)全部工作假定价值，即完工预算 BAC (Budget At Completion)或称“总预算”。
BAC=完成时的预算一项目预计总成本的基线
在图 4-6中，BAC＝2000元。
(9)尚未完工部分的估算 ETC(Estimate To Completion)价值，即从开始到完成项目将还需要花
费多少成本。ETC＝EAC-AC
在图 4一 6中，ETC为：ETC＝2315-1100＝1215(元)
(l0)完工估算 EAC (Estimate At Completion),反映了根据项目的进展总成本是多少，如表 4-6
所示。
最常用的两个公式是 EAC=BAC÷CPI和 EAC=AC+ETC 。在计算过程中，优先使用第一个公式，如
果有明确的理由说明第一个公式不可用，则采用第二个公式。在图4-6中，EAC＝2000÷＝2315(元)
(11)完工偏差 VAC(Variance At Completion)，即全部工作预算价值(BAC)与全部工作概算价值
(EAC)之差。 VAC＝BAC-EAC
正值是项目组追求的目标，表明成本比预计情况要好。
在图 4-6中，有： VAC＝2000-2315＝-315(元)
(12)绩效指数 TCPI(To Complete Performance Index)： TCPI＝(BAC-EV) ÷(BAC-AC)
在图 4-6中，有：TCPI＝(2000-950) ÷(2000-1100)＝
从这一点出发，必须取得效益，即每花费一元要完成 元的价值，以便用预计剩下的资金完
成余下的工作。
(13)任务完成百分比 PC(Percent Complete)，即已完成的工作占总工作量的比例。PC＝EV ÷BAC
在图 4-6中，有：PC＝950 ÷2000＝％
(14)成本消耗百分比 PS (Percent Spent)是指已经消耗的成本占项目总预算的比例。在图 4-6
中，有： PS＝1100÷2000＝55％
所有的价值，无论是计划的还是实际的，都用货币值表示偏差。这会使大家认为挣值与货币有
关，但它反映的是项目绩效(Project Performance).因此，挣值是沟通管理的一个重要工具，也是
项目绩效度量的一个非常有帮助的工具。
进度偏差和成本偏差对项目的影响如表 4-7所示。
参考答案
【问题 1】(6分)
截至项目状态日期已经完成工作量的预算成本，即挣值 EV：EV=50×50%=25万元。
【问题 2】(6分)
项目结束时的总成本：EAC=28÷50%=56万元。
【问题 3】(6分)
由于 AC>PV>EV,说明项目实际费用支出超前，与实际完成工作量相比费用超支，项目实际完成
工作量与计划工作量相比出现拖期。
【问题 4】(7分)
重新预计的项目完工总成本：EAC=(28-4-3×(1-40%))÷50%=万元。
案例四：成本控制
阅读以下关于信息系统项目管理过程中成本控制方面问题的叙述，回答问题 1一问题 3。
案例场景
某 A单位的电力信息应用系统(简称 A系统)，系统建设总投资是 1100万元，其中主机采购、存
储系统采购、网络设备采购、配件采购等花费 500万元，应用软件开发 600万元。2005年 4月工程
双方签订项目开发合同，由 B公司负责承建。项目总工期为 25周，计划从 2005年 5月 1甲启动至 2005
年 10月 22日全部完工。
B公司是一家民营高科技信息系统集成企业，有高级工程师 2人，软件、硬件、网络工程师共 36
人。B公司安排高工李工负责 A系统的建设工作。B公司的绩效考核制度是非常严格的，对项目负责
人的考核，项目开工前要制订项目实施计划，项目完工后要对项目计划的执行情况进行考核，项目
的进度、质量、成本三大目标都要求控制在计划的范围内。
李工于项目正式启动之前两
周开始进行项目建设的准备工
作，对工程项目进行了工作分
解，在工作分解的基础上，编制
了项目资源计划、人员计划、项
目质量保障计划、进度计划、项
目成本预算和成本控制计划等。
李工编制完项目资源计划后，报
告公司审批，包括项目小组组建
的计划在内的项目资源计划顺利
地通过了公司审批。于 2005年 5月 1日项目正式启动时，项目小组也组建完成。李工所组建的项目小组
为 12人，包括软件设计、编码工程师 8人，软件测试工程师 4人。
由于软件项目开发的主要成本为人力资源成本，为此，李工制定了详细的人力资源成本控制计
划，人力资源计划成本=12人×25周×平均人周成本(1500元) =450 000元。为了将软件开发人力资
源费用控制在 45万元内，李工制定了详细的工程成本管理计划。
李工所进行的项目工作分解，得到共 24个系统功能模块，分别编号为 M01、M02、……、M24，
并分别为每个功能模块制定了工期和成本预算。如表 4-8所示。
在项目开发的过程中，李工随时跟踪统计项目的开支情况。李工要求每位软件工程师每周报告
一次工作进度，如某某模块完成工作量 30％，李工据此来估算项目的进度和成本绩效。如表 4-9所
示。李工根据表 4-9的统计数据计算累积完工的工程价值，计算公式为：
。
【问题 1】(6分)
请以 200字左右回答，李工的成本预算存在哪些问题？李工所采取的成本跟踪管理的方法是什
么方法？应用软件系统开发项目中，使用此方法应注意什么特点？
【问题 2】(10分)
请以 200字左右回答，衡量软件开发实际累积人力资源成本的计算公式是什么？怎样改进上述
方法才能控制好人力资源成本？怎样得到软件企业实际消耗的人力资源成本？
【问题 3】(9分)
请以 300字内回答，李工采用此方法的具体措施是否存在不足之处？如存在，请指出不足并说
明理由，请给出你的改进意见。
案例分析
【问题 1】
挣值管理方法是应用非常广泛的项目成本管理方法。但是，IT应用系统开发工程项目有其特殊
的特点，挣值管理方法的应用必须结合 IT工程项目的特点进行，才能够收到理想的效果。另外，IT
应用系统工程项目的成本预算也是比较困难的课题，我们往往很难像其他工程项目(如建筑工程项目)
那样，将 IT应用系统工程项目的成本预算做得准确。
在过去的应用软件工程项目中，很少采用挣值管理来控制项目进度款支付。但随着 IT项目管理
水平的提高，随着我国 IT工程监理制度的推广，将来采用挣值管理控制工程进度款支付也是可期待
的。项目经理应当熟练掌握挣值管理方法。
软件项目的合同价格不等于软件项目开发的实际成本，合同价格除了承建单位的软件开发成本
外，还包括销售成本、行政费用、税金、利润等，但我们在这里探讨的主要是项目开发成本，即工
程成本。
在李工的成本估算中，缺少了对工程量的估算，因此，对人力资源成本的估算也就缺少了依据。
对工作量的估算，如 M0l模块需要 16“人周”，M02模块需要 6“人周”，或以“人月”、“人年”为
单位来估算工作量，各模块的工作量合起来，就可得到整个项目的工作量。当然，如果要把预算做
得更准确，还需要估算各模块的代码量，以历史经验得到每个成员的工作效率来计算各模块所需的
工作量，但这种做法目前在我国还没有多少成功的案例，很多 IT公司均是靠经验来进行估算的。
【问题 2】
对于大多数应用软件开发项目来说，工程成本的主要构成要素是人力资源使用成本。而为了合
理有效地控制人力资源使用成本，在组建项目小组的时候，可以根据工程项目的进度情况，分阶段
投入人力资源，要做好与其他工程项目协调使用人力资源。我们也可用人力资源成本来计算挣值，
人力资源使用成本的实际值可向财务查询所支付的成本，挣值可以这样计算：
累积人力资源成本(挣值)=模块工作量 i×完成率 i×平均人力周成本
这种计算是在承建单位内部的成本控制。
本题的主要考点在于怎样在软件开发项目中合理、有效地进行挣值管理。要合理使用挣值管理
方法，必须同时考虑到软件工程项目的特点。软件工程项目与建筑工程项目有很大的区别。软件工
程项目更加类似于科研项目。如表 4-10所
示。
在建筑工程项目中，工程进度与成本之
间的线性比例关系较好，而且进度容易测
量。因此，挣值管理方法也使用得比较好。
但在软件工程项目中，要合理、合适地
采用挣值分析方法是比较困难的。软件工程
项目的成本控制的困难有以下原因。
(1)需求的不确定性：软件项目的范围、
需求难以准确地定义，导致项目开发过程中
存在大量的变更，从而影响进度和成本。
(2)规模和工作量的不确定性：软件项目的工作量预算难以估计准确。
(3)质量鉴定的不确定性：开发完成并投入运行的软件模块的质量难以鉴定，特别如某个模块完
成了 30％或 80％的工作量，我们无法去鉴定，或用于鉴定的成本可能很高而使开发单位难以接受或
不愿意去做这样的鉴定。
(4)把握需求的不确定性：已经编写完成的软件代码，可能隐藏着对需求理解的严重偏差，可能
是废品，得全部返工。
(5)难易程度的不确定性：已经编写完成的软件代码可能是很简单的，未完成的可能很难，或反
之。
(6)人员的不确定性：如果编写软件代码的人员不稳定，熟练员工中途流失将给项目进度、质量
管理带来严重影响。新人中途接手未全面完成的、风格不良的软件代码，是一件很困难的工作。员
工的敬业精神也难以衡量。
由于以上这些因素的影响，使得在软件工程项目中对工程进度和工程质量的测量变得很困难，
因而，我们就不可能像在建筑项目中那样使用挣值管理方法了。
【问题 3】
在软件项目的开发管理中采用挣值分析时，可以考察各模块的完成状态，全部完成并且集成测
试成功，能够投入初步运行，这样，可以算本模块的工作量完成，可以获得本模块的全部挣值，否
则，本模块的挣值计 0。考虑到工程整体的集成还需要一定成本，因此，在计算各模块挣值时，还
应当扣除一定比例的挣值，作为工程整体集成的工作量的挣值。
但我们在实际工作中，也有很多时候采用估算某模块完成百分之几的做法，但这种做法是粗放
式的，项目管理人员可以将这信息作为对项目成本累积的参考，作为粗略估计项目进度的参考，但
不是成本核算的依据，也不能作为申请工程进度款支付的依据，需知这种信息的可信度和可控性均
较差。
参考答案
【问题 1】(6分)
应当先估算各模块的工程量，再以工程量来估算所需要的人力资源，如总工程量“××人周”或“××
人月”或“××人年”等。李工的项目小组的建设应分阶段进行人力资源投入，如设计阶段所用人力
应较少，而详细设计完成后，编码阶段进入，则人力投入是高峰期。
人力资源成本的预算也应当核算一定比例的浮动成本。李工所采用的是挣值管理方法。此方法
应用到软件工程项目中，应注意软件开发挣值与投入的非线性比例关系特点。
【问题 2】(10分)
软件开发人力资源成本挣值统计是能够做到比较准确的，衡量软件开发人力资源成本的计算公
式： 累积人力资源成本=模块工作量 i×完成率 i×平均人力周成本
李工所采取的方法应增加各模块工程量的估算，就能够进行人力资源成本控制。如表 4-11所示。
实际消耗的人力资源成本可通过财务发放的工资统计得到。
【问题 3】(9分)
李工根据各工程师的进度报告(进度百分比)来计算挣值，在软件开发中是不可行的。
在软件开发中，各模块的进度百分比通常很难测量准确，而各工程师的汇报往往是很粗略的估
计，这种估计只能提供给项目经理控制进度时做参考，但不能作为成本核算或申请工程进度款支付
的依据。建议李工以各模块全面完工来进行计算，即各模块要么计算 0％，要么计算 100%完工，但
在进行工作分解的时候，分解的深度和各模块的粒度要合适，便于进行控制。
另外，在核算的时候，要扣除一定的比例，如 20%～30%作为各模块集成所需要的工程量，待工
程全面完工后进行核算。
4．5案例五：投资决策
阅读以下关于信息系统项目管理过程中投资决策方面问题的叙述，回答问题 1一问题 3。
案例场景
刘工是某希赛软件研究所(CSAI )新产品开发部的总工程师，负责为公司调研新的产品预研方向，
编制项目开发报告。
2005年5-8月，刘工经过近3个月的时间，
对××行业的 YY业务系统收集了大量资料，并进
行了深入分析，向公司提供了一个项目开发计划，
项目开发计划的摘要如下：
××行业的 YY业务系统现状描述：(略)。
项目开发 A方案的技术经济描述：A方案为一期项目包含 6个子系统的建设，项目开发周期为 2
年，第一年初投资 600万元，第二年初投资 600 万元。项目建成后运行周期为 4年，每年年末产生
的净现金流入量见表 4-12。方案 A投资收益如表 4-12所示。
项目开发 B方案的技术经济描述：B方案分两期建设，两个合同。一期包含 3个子系统，开发
周期为 1年，第一年初投资为 600万元，项目建成后即投入运行，第一运行年度末产生的净现金流
入量为 160万元。第二期项目投资于第一期项目建成后启动，包含 3个子系统，开发周期为 1年，
投资 700万元。第二期项目的建设必须有第一期项目的支持，建成后与第一期项目一起运行，每年
年末的净现金流入量见表 4-13。方案 B投资收益如表 4-13所示。
以上计算，设资金的贴现率为 8%。
A、B两方案的技术经济比较：通过对 A, B两方案的技术经济比较分析， B方案的净现值和净
现值指数均优于 A方案，因此，刘工得到的结论是 B方案优于 A方案。
【问题 1】(6分)
请以 200字内回答，刘工对 A, B两方案的技术经济分析是否全面？请你给出合理的补充。
【问题 2】(9分)
请以 300字内回答，B方案比 A方案的投资多 100万元，即使折算到第一年年初的净现值，B方
案也比 A方案多投入 万元。为什么 B方案还是比 A方案的经济性优越呢？为什么 A, B方案建
设同样多的功能模块，B方案的投资却比 A方案多？请列出可能的影响因素。
【问题 3】(10分)
请以 300字左右，对 A,，B两方案的技术经济性进行点评。
案例分析
【问题 1】
开发一套信息应用系统，都是要期待信息系统能够为我们带来经济价值，即使是公益性项目也
不例外。信息系统给我们带来的经济价值有高有低，好的建设方案应当带来更大的经济价值。为了
选择更好的项目建设方案，就需要通过对项目的技术经济分析进行投资决策。在进行投资决策时所
用到的财务评价指标，根据是否考虑了资金的时间价值，有静态评价指标和动态评价指标。
静态评价指标对于技术经济数据不完备、不准确的方案进行初选，或者对于全寿命周期比较短
的项目来说，是适合的。常用的静态评价指标有：投资利润率、静态投资回收期(Pt),借款偿还期
(Pd),利息备付率、偿债备付率等。
充分地考虑资金时间价值的动态评价指标比较适合于方案最后决策前的详细可行性研究阶段，
以及对于寿命周期较长的方案进行评价。常用动态评价指标有：净现值(NPV),净现值指数(NPVR ),
内含报酬率(IIT )、动态投资回收期((Pt)等。
另外，不同的投资方式，投资资金的风险也不一样，如一次性投资资金的风险一般比分期投资
资金的风险要大。建设单位建设资金不充足的情况下，一般采用分期投资的可能性更大些。
【问题 2】
现在的应用软件系统开发，我们通常采用螺旋模型开发方式，螺旋模型开发方式的优点是初期
投资少，系统建设周期短，建设完成后可以迅速投入应用，给我们带来良好的经济价值。而传统的
瀑布模型开发方式，由于开发周期长，一次性投资大，投资收益见效迟缓等缺点，往往在市场竞争
的初期会处于不利地位。
软件开发模型对比如表 4-14所示。
采用螺旋开发模型，我们可以在较短
时间内迅速建设一个应用系统，让系统尽
快投入生产，产生经济效益。
但我们同时也应看到，采用螺旋模型
开发软件系统也是有缺陷的，采用螺旋模
型开发软件，由于在系统建设的初期，我
们只考虑一小部分系统功能，很多软件架
构设计人员容易忽略将来应用软件对架构的变更要求。由于软件架构的制约，早期建设的系统在应
用的过程中，在满足新需求方面，常常遇到很多问题，有时甚至不得不考虑完全废弃以前的架构，
重新设计新架构的情况，重新设计就必然导致部分工作的重复、返工，增加工作量，增加投资。
从经济价值方面来考虑，螺旋模型当然是首选，因为其建设周期短，见效快。从系统质量方面
来考虑，瀑布模型又具有一定的优势。采用螺旋模型开发应用软件，必然在时间上存在多次功能模
块的迭代。而目前在 IT行业，人员的流动性非常强，熟练员工的流失常常也带走成熟的技术，而新
招聘的员工对应用软件系统开发的规范性、统一的软件架构、质量保证计划、公司的可复用资产的
理解是会大大打折扣的，因此，新员工所开发的软件功能模块，在对旧软件功能模块进行迭代的时
候，就会存在很多问题，时常引起软件系统故障，即系统质量问题。
螺旋模型在对付需求变更方面，往往能取得良好的效果，但是，IT系统集成公司或项目小组又
容易陷入另外一种误区，即不重视需求分析，不重视对系统开发的全局考虑，这样，必然造成需求
分析中存在着很多不足，导致频繁的变更，泛滥的变更，影响质量，影响成本。
也不乏这样的情况出现，由于信息系统工程质量的隐蔽性特点(功能方面也存在很强的隐蔽性)，
建设单位在建设信息系统工程项目的时候，由于主管领导换届，前任已经开发完成的功能，但可能
应用部门长期没有使用，新领导由于不知情而重新进行项目建设。这也是螺旋模型开发中，项目管
理工作做得不够完善所引发的重复投资问题。
而从系统质量方面来考虑，当然是一次规划，一次性开发更好，因为这种开发模式的统筹性工
作将比较螺旋模型会做得更好。传统的瀑布模型需要我们花费大量的精力来做需求分析，要求需求
分析做得深入、彻底，以减少软件系统的变更。但由于传统瀑布模型的开发周期长，一次性投资大，
投资风险也大，建设单位往往很难接受，软件产品开发商也很难接受，这就导致传统的瀑布模型在
市场竞争方面输于螺旋模型。
频繁的变更使得系统质量受到影响，也必然使得应用软件系统的成本投入的增加。
我们建设应用软件系统的投资，除了考虑技术经济性、风险等因素外，还应考虑到非合同因素。
工程的甲乙双方在签订项目建设合同的时候，一个大合同通常比若干小合同更合算。用个简单的比
喻，好比批发与零售的区别。但分散的小合同风险小，大合同风险大。因此，这方面的因素也应当
综合权衡。
因此，当我们在进行软件开发方案决策，选择应用系统开发模型的时候，应当全面考虑以上这
些问题。
【问题 3】
实际上 A, B两方案均是可行的方案，但 B方案比 A方案风险小，且 B方案建设周期短，见效快。
如果采用 B方案，那么，应当注意系统建设的统筹规划。如果采用 A方案，也可以实现一次规划，
一个合同，分期建设，这样，效益就会更好。
参考答案
【问题 1】(6分)
刘工的分析不全面。全面的经济分析还应考虑“成本回收期”、“追加成本净现值”、“追加成本
内部收益率”、“内含报酬率”、“敏感性分析”等。还应当增加投资风险分析，本案例方案 B的投资
风险比方案 A的投资风险小。
【问题 2】(9分)
B方案分两期建设，两期投入建设资金。由于 B方案的一期系统建设在一年建设完成后就投入
运行，产生了经济效益。因此，通过净现值指数分析，B方案净现值指数高于 A方案，B方案的经济
性比 A方案优越。
B方案分两期投入，项目风险将会得到一定程度的降低。
B方案所投入的资金多于 A方案，一般有以下原因：
两个分立的合同，在甲乙商务方面将有一定区别，分立合同的单价往往会做得高一点。
．由于分期建设，在应用系统的体系架构方面，可能有一定程度的重复开发。
．由于分期建设，硬件及采购设备方面可能有部分会被淘汰、升级，从而影响采购投资方面的
增加。
．由于分期建设，IT项目市场环境、技术、政策等因素的影响，也会导致投资总额差别。
【问题 3】(10分)
从技术经济性上讲，A、B两方案均是可行的。但 B方案更好。
B方案比 A方案风险小，且 B方案建设周期短，见效快。
采用 B方案，应注意应用系统开发的统筹规划就更好了，可以采取一次规划，分期建设，在一
期工程建设的时候，对=期工程的建设做比较全面的分析，使一期工程在技术上能够较好地支持=期
工程。
如果采用 A方案，也可以实现部分功能模块提前投入运行，产生经济效益。甲乙双方只签一个
合同，在投资不变的情况下，提前实现收益，使收益增加，提高项目的经济效益。
第 5章项目质量管理案例
质量是“使实体具备满足明确或隐含需求能力的各项特征之总和”，明确或隐含的需求是指按项
目需求制定的基础性文件。在信息系统项目中，一般把《系统需求规格说明书》作为项目需求的基
础性文件。
质量管理作为项目管理的一部分，具有非常重要的地位。质量管理的目的是通过执行项目质量
管理过程，使用一些基本项目管理工具和技术来保证信息系统的质量。时间、成本、质量是项目管
理的三大目标，如果质量不能满足要求，即使进度再快，成本再节省，项目也没有意义。
5．1案例一：计划及跟踪
阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题 1至问题 3。
案例场景
某银行信息系统工程项目，包含省级广域网工程、储蓄所终端安装工程、主机系统工程、存储
系统工程、备份系统工程、银行业务软件开发工程等若干子项目。此工程项目通过公开招标方式确
定承建单位，希赛信息技术有限公司(CSAI)经过激烈竞标争夺，赢得工程合同。合同约定，工程项
目的开发周期预算为 36周。
由于银行对于应用软件质量要求很高，CSAI也非常重视工程质量，安排有资深资历的高级工程
师张工全面负责项目实施。在工程正式开工之前，张工对工程项目进行了分解，根据工程分析，张
工认为此工程项目质量、进度的关键在于银行业务定制应用软件的开发。除工程整体的开发计划外，
张工还针对应用软件开发制定了详细的开发计划，定制应用软件的开发周期为 36周。网络工程、终
端安装工程、主机系统工程、存储系统工程、备份系统工程等与应用软件开发并行实施。
张工对工程项目在需求分析、概要设计、详细设计、编码、单元测试、集成测试等各个环节要
求均非常严格。根据张工安排，需求分析、概要设计均安排有多年工作经验的高级软件工程师担任，
各个阶段的阶段成果均组织了严格的评审，以保证各个阶段成果的质量。
在软件编码及单元测试工作完成之后，张工安排软件测试组的工程师编制了详细软件测试计划、
测试用例，包括集成测试、功能测试、性能测试、安全性测试，等等。
张工在安排软件测试任务的时候，在动员软件开发小组时宣讲：“软件测试环节是软件系统质
量形成的主要环节，各开发小组，特别是测试小组，应重视软件系统测试工作”。因此，张工安排给
测试组进行测试的时间非常充足，测试周期占整个软件系统开发周期的 40%,约 周。在软件系
统测试的过程中，张工安排了详细的测试跟踪计划，统计每周所发现软件系统故障数量，以及所解
决的软件故障。根据每周测试的结果分析，软件系统故障随时间的推移呈明显的下降趋势，第 1周
发现约 100个故障，第 2周发现约 90个故障，第 3周发现 50个故障，……，第 10周发现 2个故障，
第 11周发现 1个故障，第 12周发现 I个故障。于是张总工断言软件系统可以在完成第 14周测试之
后顺利交付给用户，并进行项目验收。
【问题 1】 (7分)
请以 300字内回答，张工的软件开发计划中是否存在问题？为什么？
【问题 2】(8分)
请以 200字内回答，张工根据对定制软件系统测试的跟踪统计分析结论，得出项目可于计划的
测试期限结束后达到验收交付的要求，你认为可行吗，为什么？
【问题 3】(10分)
请以 300字内回答，若你是本项目的总工，你将怎样改进工作，以提高软件系统开发的质量，
保证工程项目按期验收？
案例分析
过去，很多 IT集成公司所承建的定制软件工程项目，当进入到验收阶段的时候，用户常常拖延，
或找这样那样的借口不给承建单位验收，这是什么原因呢？针对这个问题，建设单位、承建单位都
有一定责任。对于建设单位来讲，由于建设单位对信息系统建设认识上的局限性，对软件系统质量
鉴定的困难性，建设单位存在着对定制软件系统的质量的担心，因此，很难果断地做出验收项目的
决定。
而对于承建单位来讲，承建单位在项目质量管理方面常常做得很不到位，比如：该提交工程实
施计划、工程实施计划进度跟踪记录、工程概要设计书、详细设计书、应用系统配置文件、用户手
册、培训资料等若干文档的时候没有提交，而很多承建单位在项目验收时，根本看不到这些文档，
或即使有文档，但也极其不规范，文档质量很低。再比如：曾有个信息系统工程项目在提交用户验
收的时候，有一台防火墙散乱地摆放在机柜外面，再看机柜上面所布放的通信线缆，显得杂乱无章，
承建单位也没有意识到这个问题，用户虽看在眼里却不提醒承建单位，那请问，用户会给这样的项
目进行验收吗？
通过硬件所表现出来的表面质量是很容易发现的，但对于软件系统的质量的衡量却是非常困难
的，特别是对于那些对软件系统认识不够深入的 IT系统建设单位，他们面对 IT项目的验收，常常
显得很谨慎也是可以理解的。
信息应用系统项目的质量保证与承建单位的质量保证体系是密切相关的，但并不等于承建单位有质
量保证体系，如通过了 ISO9000认证，或通过了 CMM3, CMM4等认证，就一定能够保证 IT项目的质
量。承建单位的质量保证体系是一个大纲性质的，但实施项目的是项目小组，项目小组不能很好融
合到承建单位的质量保证体系中是比较常见的现象，因此，为有效保证项目的质量，项目小组应当
向建设单位或监理单位提交项目的质量保证计划。质量保证计划是在承建单位质量保证体系下编制
的，是针对项目特点的，涉及保证项目质量的具体措施，更易于操作。当然，一个项目的质量保证
计划如果照搬到另外一个项目，却不一定适用。而建设单位、监理单位可以通过对承建单位质量
保证计划的执行情况来判断其软件开发过程的质量，从而协助对定制软件产品质量的鉴定。
【问题 1】
软件测试是保证软件质量的重要工作内容之一，但软件测试环节却不是软件质量的形成环节，
测试只能检查软件中所存在的缺陷，发现问题。软件质量是在需求分析、设计、编码、测试、文档
编制等软件生产的全过程中形成的。因此，我们要了解定制软件系统的质量，就必须了解承建单位
开发软件系统的全部过程的质量。
测试计划和测试用例应当在软件的设计阶段制定。越晚进行的测试，其测试计划的编制时间就
越早。如集成测试计划在概要设计阶段编制，功能确认测试计划在需求定义阶段就应当制定，整体
测试计划也应当在需求分析阶段制定。
虽然我们在实践中有很多这样的情况，很多软件开发团队并不是在软件设计阶段同步制定软件
测试计划和测试用例，甚至有很多软件开发中根本就没有制定规范的测试计划和测试用例。但这些
并不是正统、规范的做法，这样的软件工程过程对于保证定制软件系统的质量来说是会打折扣的。
若测试计划的编制时机不能按照规范进行，那说明软件企业的过程能力成熟度还不够，还是在采用
手工作坊方式生产软件，想到哪里做到哪里，没有计划或计划不科学，不能有效地控制软件生产的
质量。
【问题 2】
软件系统的质量，仅仅根据测试的结论来进行断言是不够的。我们在进行项目开发计划安排的
时候，应当将系统的试运行也安排在计划之内。系统的试运行牵涉到工程项目的建设方和承建方，
除了技术方面的因素外，还涉及组织方面的因素，人文方面的因素等。承建方要安排足够的时间与
建设方协商系统的试运行问题，在双方的配合下开展系统试运行工作，系统在试运行中，通常还会
发现大量的故障，承建单位也必须配合解决这些系统故障。只有通过试运行的考验，才能够基本断
定系统的质量是否符合要求；通过了试运行的考验，再向用户提出工程项目的验收，一般来说，用
户的接受程度会比较高。
软件系统的试运行为什么如此重要呢？这是根据不同的工程项目的特点，如公路建设就不需试
运行，住宅建设也不需试入住，通过质检方式就可确定工程项目的质量。而另外一些工程项目则是
必须要进行试运行的，比如铁路系统
建设、水电站建设、化工厂建设等，这些类型的工程项目，不通过试运行，就不可能鉴定其
质量，信息应用系统的建设也是一样。
【问题 3】
另外，在向用户提出项目验收前，还得整理并提交完整的工程技术文档、系统维护文档、软件
配置清单，给用户举办系统操作培训、维护培训，全面审核合同执行情况，编制项目竣工报告，等
等。如果项目小组不注意这些工作，用户大多也不会来提醒你，用户只卡住验收关不让通过就可以
了，当然也有部分用户可能会提醒项目小组离验收还差什么。毕竟项目的实施任务是属于承建
单位的工作，承建单位理应完善自身的项目管理水平，不可能让用户来督促你、提示你，那不是用
户的职责，更何况，很多用户自身也不知道 IT项目该怎样管理，有哪些工作需要完成，但承建单位
很多不规范的做法、存在的问题，让用户对质量不放心，用户却是能够觉察到的。特别要注意的是，
项目经理在计划项目验收时，应当与用户的主要领导充分沟通，让客户领导了解项目的建设过程，
了解项目的质量实施情况，让领导对项目的验收充满信心。
但请仔细分析本题，案例场景中通篇并没有提到关于工程文档、配置清单、培训等话题，这些
内容并不是本题的关键，未提及的内容，张工可能没做到，但也可能做到，不好断言。我们只要能
够抓住场景所描述的张工的主要缺陷，一是制定测试计划的时机不对，二是根据测试断定软件系统
的质量不对，只要能抓住这两点就够了。其他的内容，也可以反映在答案中，但要注意语言要简
练，虽不会导致扣分，但也不是得分的要点。
参考答案
【问题 1】(7分)
张工安排测试计划的编制时机不对。测试计划和测试用例的编制应当与软件系统的概要设计、
详细设计同步进行。
测试计划不够全面，还应当包含系统整体测试、运行测试。运行测试是对应用软件系统整体功
能的全面检验，也是最能够说明软件系统质量的测试环节。
系统测试计划、确认测试计划应当在需求分析阶段制定，测试用例、测试说明应当在概要设计
阶段制定。
集成测试计划应当在概要设计阶段制定，测试用例、测试说明应当在详细设计阶段制定。
单元测试计划应当在详细设计阶段制定，测试用例、测试说明应当在编码阶段制定。
【问题 2】(8分)
在定制软件开发项目中，根据测试结果判定软件系统的质量是不够的，因为软件系统中的缺陷
可能由于多种原因而未在测试中被发现，如测试环境与运行环境的区别、测试人员的能力问题、测
试计划和测试用例的局限及缺陷。
由于软件系统质量、功能、性能具有很强隐蔽性的特点，用户往往不大可能根据项目开发小组
的测试结论来进行项目的验收。最好让用户组织对项目进行试运行，以试运行的结论来作为验收的
依据之一是比较有说服力的。
【问题 3】(10分)
(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】(8分)
请以 300字内回答，李工对所遇到的问题的处理方法是否恰当。李工所做出的决定的主要缺陷
是什么？造成问题的原因主要是什么？
【问题 2】(8分)
请以 300字内回答，团队协同工作时，在软件版本方面会造成哪些问题，应当采取什么措施以
避免问题的出现？
【问题 3】(9分)
请以 300字内回答，在 IT应用软件开发工程中，怎样进行项目现场与总部软件开发团队的有效
配合？
案例分析
CSAI虽然通过了 CMM3级认证、ISO9000认证，但 CSAI的管理工作未必就能按照规范来开展，
有不少公司只是将这些认证作为投标竞争时的砝码而已。因此，我们在建设工程项目的时候，不但
要看 IT系统集成商具不具备这些认证，还应采取有效的手段考核 IT系统集成商的质量保证计划。
对 IT系统集成商进行考核，简便可行的方法就是让集成商在项目开工前提交质量保证计划，并对质
量保证计划进行评审，通过后要求集成商严格执行。通常，过程能力成熟度高(指实际)的 IT企业，
在实际工程与质量保证计划之间的一致性会完成得较好，而过程能力成熟度低的企业(指实际)，实
际工程与质量保证计划之间的一致性会完成得相对较差。
【问题 1】
我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程项目的三大目
标。通常与客户接触最多的是现场项目经理，引导客户需求对项目经理就非常关键，项目经理引导
得好，项目的开发就会非常顺利，反之，就会使项目组疲于奔命。优秀的项目经理是既能够让项目
组成员“睡大觉”，又能保持良好的客户满意度。
CSAI项目经理李工与用户的沟通存在问题。善于沟通的人，一言明百理；不善于沟通的人，百
言不明一理。项目经理与客户的沟通，不是指项目经理善于说话，善于高谈阔论就能够解决问题，
更为关键的是项目经理要具备足够的引导项目建设的能力。作为现场项目经理，不是只做一个传话
筒，客户说什么就是什么，而是应当与客户进行深入交流，深入分析客户所提出的问题，合理引导
客户的需求，要有主见。
李工在 CSAI进行客户满意度考核，客户又有大量需求的前提下，显得无所适从，手忙脚乱，而
做出了不合适的决定。
一是客户的需求，只要我们能够合理引导客户，客户的需求变更不可能有那么频繁，有很多需
求变更是可以让用户暂时放弃的，或有的需求变更可以让用户在另外的工程项目中去实现，比如建
议用户建设=期工程。我曾经见到一位项目经理在一个工程项目中，客户提出了一个需求，项目经理
安排组员加班三天三夜完成了，告诉客户方主任，客户主任大吃一惊，说：“我并没有要求你们实
现这个需求啊，我只不过向你们咨询一下而已”。
客户与我们的项目经理交谈，并不是都谈需求，有很多时候，客户可能是谈到自己的想法、心
得体会、建议等。客户方面也往往有很多员工，一位员工有一种思想，十位员工就有十种思想，要
统一这十种思想，项目经理就得付出更多的努力，要与用户方面的主管人员达成一致，而且，很多
时候是必须要用户的主管人员去统一他们的意见。否则，应用系统的开发就存在很大制约因素。很
多项目经理面对公司客户满意度的考核，面对客户无休止的需求，常常不能采取正确的应对方法，
该说的不敢说了，该讲的不敢讲了。应用软件工程在建设阶段，优秀的项目经理应当是能够引导用
户思路的项目经理，而不是让用户领导项目经理的项目建设思路。项目经理应当知道，任何一个客
户都更注重项目建设的结果，在项目建设的过程中，项目小组与建设单位之间可能存在着很多次交
流，甚至争论，但只要我们能确保项目建设的结果让用户满意，用户是终会给予好评的。
【问题 2】
二是对 CSAI资源的利用不当，李工把本不属于现场的工作内容，让现场工程师来完成是严重的
失误，现场工程师仓促上阵，没有纳入 CSAI统一的软件开发质量管理体系。虽然能够临时快速解决
问题，但也会埋下故障隐患，而故障隐患的爆发却是在工程建设的后期。这种做法只能让员工疲于
奔命。在项目管理中，如果项目组成员总是处于应急、救火的状态，是不可能高质量地完成工作任
务的。作为项目经理，不但要关心项目的进展，还应当关心自己的成员，要让项目小组成员在高效
率、高质量的状态下工作。
三是忽略了现场应该做的重要工作，应用系统的配置管理工作对现场来说是很重要的。混乱
的配置管理，也会导致系统运行中发生严重的质量问题。
即使李工非要在现场进行开发不可，那也应当自觉地将现场所开发的软件，与公司总部所开发
的应用软件进行统一的管理。特别是要注意，现场开发的缺点是对需求的把握太随意，由于开发人
员与用户直接接触，用户的想法可能有很多偏激的成分，也容易被现场开发人员设计到应用软件系
统中，从而导致现场版本与统一版本难以融合，特别是对有些需求的满足，可能涉及到软件系统体
系架构的变更，这样就更难处理了。而现场临时决定的软件开发，管理工作怎样和总部的管理工作
融合到一起，项目经理是应当考虑的，要么是由总部来控制，要么是现场自觉与总部配合。
【问题 3】
我们在工程现场实施的时候，对于所遇到的系统问题，有的是能够迅速解决的，也有暂时无法
解决的。对于暂时无法解决的问题，我们常常采取迂回的方式绕过去，以保证工程项目的进度。但
是对于应用软件系统的开发来说，现场不能只是绕过去而已，还应当及时向总部报告，应当建立一
个系统故障管理平台，记录所有发现的软件故障，逐一报告研发中心进行解决，并跟踪解决情况。
为有效解决现场与总部的配合问题，可以建设一个基于 Internet的开发管理平台，现场所遇到
的问题，及时汇报到管理平台，由总部管理人员分配解决。现场也可通过管理平台主动与总部沟通
软件开发问题，协调一致，避免总部统一版本更新时丢失现场所开发的功能。
配置管理也是涉及到工程质量的。我们做企业级的应用系统，都应当考虑到系统割接的平滑性，
配置变更的平滑性，在进行配置规划的时候就应当考虑配置的变更怎样才能实现平滑过渡，否则，
就很可能使运行的系统在进行配置变更的时候进入瘫痪状态。而良好的配置管理，又是实现配置变
更平滑过渡的有力支持。
参考答案
【问题 1】(8分)
现场用户的需求是不可能有尽头的，但作为项目经理要能够把握住用户的需求，特别是要合理
引导用户需求，切不可让用户怎么说就怎么做。
积极响应客户需求要从多个方面着手考虑，不要只从技术上考虑问题，技术引导、合同变更、
人力资源等各个方面都应当考虑。
临时的现场开发工作，大多数都不可能与公司总部的软件开发融为一体，而且管理工作常常是
自上而下的，李工忽略了这点，顾此失彼，导致项目问题的发生。
造成项目问题的原因有以下几点：李工对需求把握随意；控制不严；李工与客户沟通不到位；
李工没有向客户提交合理的进度计划，或没有按时提交进度报告；项目实施无计划，或计划不能得
到客户认可，客户不满意。
【问题 2】(8分)
团队协同开发软件时，很容易出现软件版本管理不善带来的软件系统故障。同一软件系统代码
不能同时由多人进行修改。
项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，很容易造成总
部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障反复出现。
李工如果一定要进行现场开发，应当委托现场合适的人员，或亲自督促现场所进行的开发工作
与总部所进行的开发工作在软件版本方面保持一致，处理本地过于偏激的需求要与总部协商一致的
情况采取合理措施控制统一版本。
【问题 3】(9分)
项目现场应明确自己的工作职责范围，要自觉与总部门形成密切的配合。
现场所做的开发，应与总部所做的开发纳入同一个软件版本管理。
当现场发现软件故障时，应当及时向总部报告。建立故障管理表，记录并跟踪软件系统故障解
决情况。
建设一个软件开发交流平台，如基于 Internet的管理平台，管理工程现场所提出的问题，调度、
跟踪解决工程现场问题。
现场工程人员与总部人员应多交流，通过各种方式，如及时通信软件、电话、电子邮件等，必
要时，可组织研发部给现场工程人员进行培训。
案例三：质量与成本
阅读以下关于信息系统项目管理过程中工程质量问题方面的叙述，回答问题 1至问题 3。
案例场景
某行业省公司(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】(8分)
请以 200字内回答，CSAI压缩项目的工资支出是否合理？压缩工资支出直接带来什么问题？
【问题 2】(8分)
请以 200字左右回答，CSAI所承建的 A项目由于质量问题将直接或间接引起哪些方面的项目成
本损失？
【问题 3】(9分)
请以 300字内回答，如果你是此项目经理，你将怎样进行项目管理，以减少不良质量所带来的
成本损失，你的决策又会遇到什么问题？
案例分析
近年来，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承建单位应当自觉
提高公司的质量保障能力，提高应用软件开发过程能力成熟度，以保证高质量地进行信息系统
工程项目的建设。
作为项目经理，应当据理力争，但要注意方法，因为这样也是有风险的，切不可因为项目建设
而损害了与公司的关系。
参考答案
【问题 1】(8分)
CSAI压缩项目工资支出不合理。压缩工资支出必然导致压缩项目小组的整体能力或平均技能水
平。如果压缩平均技能水平，将使软件项目开发的质量降低，工期延长，并且由于质量缺陷直接导
致系统在维护阶段的维护费用急剧升高。如果压缩项目小组人员数量，确保项目小组平均技能水平，
则由于在规定工期内完不成项目工作量，也将导致工期延长。
由于 B公司不能按合同执行项目工期，将导致 A单位(甲方)的工期索赔。
【问题 2】(8分)
直接地，系统维护费用支出、项目延期的人员工资支出、重新设计编写测试代码的费用的升高，
部分功能模块提前报废的损失增大。
间接地，未准时交付项目向 A单位支付的罚金、维护阶段的应急维护成本、客户信誉丧失、隐
蔽缺陷的对系统运行所构成的威胁、设计生产周期延长带来的费用增加、投产期推迟使 A单位减少
收入、时间耽误，等等。
【问题 3】(9分)
据理力争，但请注意方法，保证工程项目资金到位。在项目正式实施之前，就应当与领导多沟
通，求得领导的支持，从多个方面讲清楚怎样实现项目目标，应当实现什么样的目标，公司领导往
往不是项目管理人员，对项目管理细节了解不多，因此，领导做出不合理的决定，项目经理也有一
定责任。
在压缩工资总额的情况下，宁愿压缩人员数量，而不是降低平均技能水平。降低平均技能水平
不能保证工期，还不能保证质量；而压缩人员数量虽无法保证工期，但质量还能得到较好保证。可
是要面对公司舆论压力，高素质人员高工资，要与领导多沟通，获得领导支持。
案例四：项目外包
阅读以下关于信息系统项目管理过程中质量管理方面问题的叙述，回答问题 1至问题 3。
案例场景
希赛信息技术有限公司(CSAI得到国家创新计划资助，决定开发基于 Web全国范围内的生态信
息检索系统，项目由张工负责，时间 1年。
项目开始实施后，张工发现该系统内容多，并且具有地域性，以 CSAI的实力无法单独完成，所
以张工把该系统按照地区分成若干子系统，由各地相关科研机构外包完成。外包时间 10个月，开工
预付款 20%，外包合同签订时项目已经开展 1个月。在外包合同中，系统功能已明确说明，但是系
统界面、风格、字体等细节没有具体说明。
外包子合同签订以后，张工由于工作繁忙等原因没有及时监督外包完成情况，只是上级在计划
中期检查汇报时从外包单位抽取一些文档、代码和执行界面。
10个月后，外包任务完成，提交到 CSAI时，张工发现子系统的界面、风格、字体等内容不统
一，所以希望这些外包单位按照统一风格修改子系统。但是外包单位认为合同中没有具体说明这些
内容，只说明应该实现的功能，为此双方产生争执，半个月未果。张工只付 40％的外包费用，所以
部分外包单位在子系统中加入时间锁，但没有通知张工，此时距离项目交工只有半个月时间。张工
又重新组织人员进行系统集成，期间没有发现时间锁问题，最后草草完工。
投入使用后时间锁生效，系统出现故障。张工被上级领导批评，于是张工与相关外包单位交涉。
最后张工交付 40％外包费用，时间锁解除，系统正常运转。
【问题 1】(8分)
请用 300字之内，对 CSAI、张工、外包单位在这个项目开发中的行为进行点评。
【问题 2】(8分)
如果想提高软件产品的质量，从项目质量管理的角度，用 350字内阐述张工应该采取什么措施。
【问题 3】(9分)
试结合自己的项目经验，讲述项目外包中如何避免风险，使得收益最大化。
案例分析
【问题 1】
行为点评题一般是跟踪案例场景过程，弄清楚题目中各个对象在项目实施中所扮演的角色，然
后将该角色应该具有的职能和案例中该对象的表现相比较，从中发现该对象的肯定之处和不足之处，
从而进行点评。
本案例中，很明显，CSAI是项目承办方，张工是项目经理，外包单位是项目外包方，可以据此
结合案例进行点评。
在项目立项之前，CSAI的可行性分析有误，高估自己的能力，承接一个无法单独完成、必须全
部外包的任务，给项目实施带来极大风险；CSAI用人不当，选择了一个不负责的项目经理张工，给
后续事件发生埋下隐患，所以 CSAI的人力资源管理制度存在风险，应该在人力资源管理各个环节，
如招聘、考评、薪金管理、员工培训、员工管理等识别、规避和控制；CSAI的管理机制不全，把张
工任命为项目经理后，没有对项目进行及时监控，加上产品外包，风险比较大，所以项目质量不能
得到保障，应该建立项目管理部(PMD)，制定项目整体质量管理章程和管理计划，定期监督项目的执
行情况。
很明显，张工不是一个合格的项目经理，专业知识不够，没有及时识别项目中存在的风险，项
目开展一个月，才发现不能完成，签订外包合同；阅历经验不足，通过外包规避风险是一个不错的
方法．，但是签合同时没有明确系统一致性，使自己处于被动状态，对系统的一致性应该专门说明，
因为一致性可以提高系统的质量，减少最后集成的工作量；职业道德水平差，系统分解后全部外包，
已经使风险最大化，而自己在签订外包合同后很少过问，只是应付了事；沟通协调能力不够，自己
的工作繁忙，无暇顾及项目的外包进展，应该给上级领导及时说清，这样可以使自己投入该系统中
的时间多一些，更有利于保证系统质量。
‘外包单位没有得到全部款项，私自在系统中加入时间锁，使得系统最后出现故障，破坏软件
完整性和安全性。外包单位通过设置时间锁来保护自己的利益的做法可以理解，但是这种做法属于
严重违反软件行业职业道德的恶劣行为·，甚至还涉嫌违法犯罪；而且这种方式给科研机构 A单位留
下不好的印象，减少以后 A单位和这些单位继续合作的可能性，因为企业寻找外包单位一般都是找
有过成功合作历史的单位。
【问题 2】
本题考查考生对项目质量管理流程的掌握。要想回答好该题，考生需要了解项目质量管理整体
流程，尤其是质量计划、质量保证、质量控制三者的相互区别和关系。
项目质量管理过程包括执行组织关于确定质量方针、目标和职责的所有活 动，使得项目可
以满足其需求。它通过质量计划编制、质量保证、质量控制程序和过程，以及连续的过程改进活动
实施来实现质量管理系统。
首先，应该编制质量计划，识别与该项目相关的质量标准并确定如何满足这些标准，因为决定
软件质量的是计划和设计，而不是检查。为了实现该目标，需要进行成本/效益分析、基准分析、试
验设计等。
其次，为了确保实际交付高质量的产品和服务，还应该联合相关质量部门执行质量保证。质量
保证是一项管理职能，包括所有有计划、系统地为保证项 目能够满足相关质量标准而建立的活动，
如请求变更、组织过程资产更新、项目管理计划更新等，该活动应该贯穿整个项目的生命周期。从
本质上讲，质量保证是对质量计划编制和质量控制过程的质量度量，项目经理和相关质量部门做好
该工作，对提高项目质量非常重要。为了实现该目标，需要进行质量审计、过程分析、基准分析等。
最后，为了确定项目实施结果是否符合相关质量标准，还应该联合项目组和相关质量部门执行
质量控制。通过质量控制，可以监督项目的具体实施结果，判断它们是否符合制定的项目质量标准，
并确立消除产生不良结果的途径，该活动应该贯穿项目执行的全过程。从本质上讲，质量控制是确
保项目质量得以圆满实现的过程，该过程包括项目产品的质量控制和项目过程结果的质量控制两部
分，前者由相关质量部门控制，后者由项目组成员控制。为了实现该目标，需要进行检查、控制图
管理、排列图管理、统计抽样、趋势分析等。
【问题 3】
本题考查考生综合运用外包管理和风险管理知识的能力。要想回答好该题，考生需要了解项目
外包本质和实施流程，外包中注意事项、常见风险及应对措施。
外包是企业利用外部专业资源为已服务，从而达到降低成本、提高效率，充分发挥自身核心竞
争力，乃至增强自身应变能力的一种管理模式，同时也是现代社会非常重要的一种商业模式。但外
包也有一定风险：外包质量不易保证，外包管理需花费更多资源，企业信息泄露，系统灵活性降低
等。由于外包商本能地趋向于控制成本以提高自身的利润，所以需要委托方和承包方对外包管理规
范达成共识，才可能有效地管理整个外包过程，使得双方共同获益，在这种情况下才有可能使得收
益最大化。
在立项阶段，产品负责人应当进行"Make or Buy决策”，确定待开发产品的哪些部分应当“采
购”、“外包开发”或者“自主研发”。非核心业务尽量外包，核心业务自己做，因为核心业务决定产
品质量，并且具有一定保密性，外包风险较大。
选择外包商时，并不能单以服务价格来做最终决定，企业应根据自身对软件质量的要求来决定
服务的代价。对外包商应从其技术能力、领域知识深度、企业文化、以前是否开发过相类似系统、
开发平台和环境等方面评估，评估时还必须提供对外包中所可能产生风险的警觉，以及有效管理风
险的办法。
外包分两种：部分外包和整体外包。前者管理方法和企业内部软件开发管理方法差不多，风险
也比较小；后者企业需要了解自身是否可以提供优质的规格说明，是否能够提供外包商所需的质量
标准和测试数据，外包商是否有类似企业本身的开发平台和环境，以及外包商的技术资源水平是否
与企业内部开发时所需的技术指数相符等，风险比较大。确定适合自己企业的外包业务模式，是避
免风险，实施项目外包的先决条件。
选择外包时，企业要充分了解自己的项目，其中包括项目需求、实现方法和预期经济利益来源。
选择外包商时，采用分而治之的办法，把一个大的外包项目分给若干厂商，而不是一个厂商来
完成。这样每个厂商就可以发挥自己的特长，承接适合自己的外包项目，减少风险。同时，多个厂
商分而治之的方法也可以造成各个厂商之间相互制衡，避免外包项目拖延。
签订外包合同时，企业应该提供完整的软件系统规格说明，建立好质量指标和测试流程，争取
建立良好的合作模式，能否建立这种合作模式往往决商件开发外包的成败。在合同签订和项目启动
前，双方应就项目的工作范围达到明确的一致意见，否则项目实施时会有很多不清楚的地方，验收
时将会出现由于项目范围理解不一致而带来的很多麻烦。合同签订时外包中各个里程碑的确认评审
时间应该有一定的柔性，否则经过几个延期的确认评审，项目实际进度已经和原来合同规定的要求
大相径庭。
项目外包期间，应该建立风险管理机制，包括制定风险管理计划，识别可能发现的风险，分析
风险产生的原因并制定相应的应对措施，制定完善的风险监督和控制机制，从而降低风险的副作用，
化风险为机会，争取收益最大化。
项目外包期间，还应该建立合同管理小组。供应商的合同和服务经理，以及本企业的合同经理
都应该参与其中，形成一个拱形的控制团队。该部门具有一定独立性，监督项目是否按照合同要求
实施，提出项目实施中的缺陷和改正方案。该小组可以作为企业和外包商的沟通桥梁，消除理解的
不一致性。
参考答案
【问题 1】(8分)
在项目立项之前，CSAI可行性分析有误，给项目实施带来极大风险；CSAI用人不当，选择了一
个不负责的项目经理张工，给后续事件发生埋下隐患；CSAI管理机制不全，没有对项目进行及时监
控。
张工专业知识不够，没有及时识别项目中存在的风险；阅历经验不足，签署外包合同时对系统
一致性应该专门说明；职业道德水平差，自己在签订外包合同后很少过问，只是应付了事；沟通协
调能力不够，自己无暇顾及项目的外包进展，应该给上级领导及时说清，这样可以使自己投入该系
统中的时间多一些，更有利于保证系统质量。
外包单位私自在系统中加入时间锁，破坏软件完整性和安全性。外包单位的做法在情理上是可
以理解，但是严重违反软件行业职业道德，甚至还涉嫌违法犯罪，而且这种方式减少以后 CSAI和这
些单位继续合作的可能性。
【问题 2】(8分)
在项目质量管理方面，张工应执行好质量计划、质量保证和质量控制这三个过程。
首先，张工应编制质量计划，识别与该项目相关的质量标准，以及确定如何满足这些标准。为
了实现该目标，需要进行成本/效益分析、基准分析、试验设计等。
其次，为了确保实际交付高质量的产品和服务，张工还应联合相关质量部门执行质量保证，有
计划且系统地执行为保证项目能够满足相关质量标准而建立的活动。为了实现该目标，需要进行质
量审计、过程分析、基准分析等。
最后，为了确定项目实施结果是否符合相关质量标准，张工还应联合项目组和相关质量部门执
行质量控制。该过程包括项目产品的质量控制和项目过程结果的质量控制两部分，前者由相关质量
部门控制，后者由项目组成员控制。
为了实现该目标，需要进行检查、控制图管理、排列图管理、统计抽样、趋势分析等。
【问题 3】 (9分)
在立项阶段，产品负责人应当确定待开发产品的哪些部分要“采购”、“外包开发”或者“自主
研发”。
选择外包商时，并不能单以服务价格来做最终决定；对于外包商应从多个方面评估；评估时必
须注意外包中的风险。
确定自己的企业适合部分外包还是整体外包。
选择外包时，企业要充分了解自己的项目，其中包括项目需求、实现方法和预期经济利益来源。
选择外包商时，采用分而治之的办法，把一个大的外包项目分给若干厂商、而不是一个厂商来
完成。
签订外包合同时，企业争取建立良好的合作模式；合同签订时外包中各个里程碑的确认评审时
问应该有一定的柔性。
项目外包期间，建立风险管理机制，降低风险副作用，争取收益最大化。
项目外包期间，和外包商一起建立合同管理小组，监督项目实施；该小组可以作为企业和外包
商的沟通桥梁，消除理解不一致性。
案例五：设计的质量
阅读以下关于信息系统项目管理过程中项目质量管理方面问题的叙述，回答问题 1至问题 3。
案例场景
希赛信息技术有限公司(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】(8分)
试以 300字内回答，张工可以采取哪些措施提高设计的质量？
【问题 2】(9分)
试以 300字内回答，除设计外，张工还需要特别注意哪些工程活动。
【问题 3】 (8分)
试以 300字内回答，如何提高这些工程活动的质量。
案例分析
这是一个开放式的案例分析题，案例中仅粗略地描述了项目背景的目标，针对如何提高项目质
量进行发问，难度相对较大，需要仔细的分析。
前面一部分对项目背景和目标的描述无非是为了说明这么几个问题：
(1)这是一个系统改造的项目。
(2)原系统中存在设计缺陷，没有考虑过组织机构改革的可能性。
(3)需要大量更改原系统的程序，消除硬编码。
(4)需要更改已有的业务数据，同时增加部门变革历史的功能。
基于这些问题，案例的后半部分给出了张工的观点：设计质量是项目的关键，需要提高设计的
质量。结合案例后的问题，我们不难发现，案例的前半部分是引子，后半部分才是关键，也是该案
例的题眼：如何提高项目的质量，显然需要用项目质量管理的知识作答。
质量管理是项目管理中的一个知识域，但在 PMBOK中并没有给出具体的质量管理的方法，需要
结合软件开发和项目的特点给出特定的质量管理策略和方法。这也正是这个案例的用意所在，考察
考生在面对实际的项目问题时需要采取哪些措施解决项目的质量问题。
我们首先从软件工程的角度考虑一下软件质量的问题。软件的质量一直是软件界近几十年致力
解决的问题，针对使用软件提高软件质量提出了很多的方法和理论。首先是软件工程的理论，需要
使用工程活动的方法进行软件开发，从系统定义与分析开始，经过设计、实现，最终到验证。在软
件工程中，人们提出了多种软件开发模式和工程活动方法。在开发模式中，有瀑布模型、螺旋模型、
迭代模型、喷泉模型等；在工程活动方法中，有自顶向下、结构化分析、面向对象分析、架构风格，
等等。除此之外，还有一系列的软件验证方法，如软件复审与软件测试。纵观这些林林总总的模式
与方法，人们无非是想解决两个问题：一是通过恰当的工程活动提高工作产品的质量；二是在工作
产品完成后通过恰当的工程活动来保证该产品的质量。因为在软件开发过程中，还有一个很明显的
特点，就是在分析、设计、实现和测试这些过程中，每一步都可能引入缺陷，且难以发现，而这些
缺陷暴露得越晚，造成的后果就越严重，修改的代价就越高昂。开发活动需要尽量提前发现潜在的
缺陷，验证手段必不可少。
题目中问的是如何提高设计的质量，设计是承接分析、指导开发的一个关键环节，在这个环节
中很容易引入难以发现的缺陷，而这些缺陷往往又会造成严重的后果。因此提高设计的质量是每个
软件项目都会遇到的问题，也是每个项目经理都会思考的问题。提高设计质量包括两个层面的工作：
在设计过程中提高设计的质量；在设计完成后对设计结果的质量检查。在答题中需要分别给出相应
的策略。
设计工作在分析工作之后，因此，充分的分析是保证设计质量的前提。对于这种改造型项目，
原系统的功能、设计和实现的情况直接影响了设计的结果，原系统的情况就是要解决的问题域，’如
果对原系统了解不足必然导致设计上的偏差。因此要想提高设计的质量，首先要充分了解原系统。
在设计时还应该选择恰当的设计方法，如有可能可以考虑复用已有的解决案例，如分析模式与
设计模式等。不过在这方面，案例中给出的信息甚少，显然不是答题的重点。
根据项目背景的描述，这个设计工作并不简单，需要论证的过程，设计方案的讨论也是必需的。
因此张工需要制定出相应的沟通计划，组织必要的会议进行方案讨论，若有必要还需要客户和原系
统的开发者参加。
在设计完成后还需要对设计结果进行质量检查，对应这类活动，我们通常采用评审和走查的方
式。评审和走查可以比测试更早地找出工作产品中的缺陷，用来检查设计质量非常合适，可以避免
缺陷在系统测试阶段才被发现，降低修正缺陷的成本。
除了评审和走查外，对设计过程进行迭代也可以提前暴露设计的缺陷，并将这些缺陷反馈到后
续的设计过程中，从总体上减少缺陷数，提高设计的质量。例如在可以将整个项目根据系统模块进
行划分，首先升级一个模块，然后把这个过程中发现的问题反馈到后续的迭代过程中。
如果能够做好上述工作，设计就不会产生重大的偏差，保证设计的质量。
对于第二个问题，除设计外，张工还需要特别注意哪些工程活动。
在分析第一个问题是我们已经找到了一部分答案—分析。分析是设计活动的基础，在错误的分
析上不可能产生正确的设计。因此充分、细致地分析原系统是保证设计质量的前提。
除此之外，对于系统改造的项目，测试的工作显得非常重要。同原系统开发相比，系统改造的
总工作量相对较少，但测试的工作量却应该超过原系统开始时的测试工作量。根据案例中的描述，
超过 80％的程序都存在硬编码的问题，都需要修改。这些程序在修改后首先需要满足同原系统功能
一致，可以通过原系统测试用例的测试；其次还要保证与系统升级的目标一致，能够满足设计的
要求，这就需要开发新的测试用例进行测试。因此，如何规划、组织、展开测试工作，也是张工需
要特别注意的方面。
除了分析和测试外，其余的工程活动也是不可或缺的，不过相比之下，分析和测试工作更具特
殊性，是张工必须特别注意的。
第三个问题与第二个问题是关联的。有了第二个问题的答案，第三个问题就比较容易了。
如何提高分析活动的质量呢？对于案例中的项目来说，系统要解决的是原系统中的缺陷，原系
统本身就是问题域，提高分析活动的质量也就是充分地分析原系统。对原系统的分析可以包括对原
有业务功能、原设计方案和原程序的分析。对原系统中业务功能的分析需要同客户一起进行，通过
同客户的沟通来把握原系统所实现的业务功能。对原设计方案的分析出了参考设计文档外，最好能
够同原系统的开发者进行沟通，这样的沟通往往能获取到文档之外的宝贵信息。例如，通过设计文
档仅能了解设计的结果，但与原系统开发者的沟通则可以了解到设计的思路。除了这些方法外，对
分析的结果进行评审也是保证分析质量的一种有效的方法。
对于测试工作，上面已经讲了很多，既需要保证修改后的代码仍然与原系统功能一致，又要保证
同系统升级的目标一致。
参考答案
【问题 1】(8分)
张工可以采取以下措施提高设计的质量：
(1)充分分析问题域是保证设计质量前提。(2分)
(2)组织必要的讨论来确定概要设计的方案。(2分)
(3)采用迭代的方法验证设计的正确性，提高设计的质量。(2分)
(4)对设计进行评审或走查。(2分)
【问题 2】(9分)
除设计外，张工还需要特别注意以下工程活动：
(1)需要细致分析原有系统。(4分)
(2)对于这样的改造项目，测试的难度和工作量很大，需要把握测试的工作。(5分)
【问题 3】(8分)
如何提高这些工程活动的质量：
(1)在分析方面(4分)
①同客户充分沟通，了解原系统的业务需求；
②阅读原系统中的文档和程序，掌握设计和实现的情况；
③如果可能，与原系统的开发者联系，在原开发者的帮助下把握原系统；
④对分析的结果进行评审。
(2)在测试方面(4分)
①使用原系统开发过程中的测试用例进行回归测试；
②针对改造后的系统开发新的测试用例进行测试。
5．6案例六：软件测试
阅读以下关于信息系统项目管理过程中项目质量管理方面问题的叙述，回答问题 1至问题 2。
案例场景
张工在希赛信息技术有限公司(CSAI )工作，被委派到了一个新的项目担任项目经理，为客户 K
公司开发用于支撑业务的信息系统。这是一个规模较小，复杂度较低的系统。由于市场竞争的原因，
合同额很少。出于成本的考虑，公司分派给张工的人员并不多。为解决人力资源不足的问题，张工
考虑，系统复杂度不高，可以一定程度上简化测试工作。于是张工在项目中做了如下安排：
(1)不进行单元测试和集成测试，仅进行系统测试。
(2)不安排专门的资源开发系统测试用例。因为程序员熟悉自己开发模块的业务，由程序员对自
己开发的程序进行黑盒测试，对测试中发现的缺陷进行记录并跟踪，且立即修改。
(3)在测试过程中，每三天定义为一个测试周期，统计每个测试周期每个模块发现的缺陷数量。
若连续两个测试周期没有发现的缺陷少于总缺陷的 5%且发现缺陷的趋势基本平稳，则认为测试工作
基本完成。
张工的理由如下：首先，随着系统中缺陷的减少，程序员会有越来越多的时间进行测试，以发
现系统缺陷。其次，当系统中的缺陷数量很少时，程序员发现的缺陷会变得越来越困难，总缺陷数
几乎不再增加，这时发现缺陷的趋势变得很平稳，且发现的数量很少。
在测试阶段，张工统计到的数据如表 5-1所示。
张工认为测试工作基本完成，决定进入系统发布阶段。
【问题 1】(12分)
请以 300字内，逐一点评张工对测试工作进行的三点安排。
【问题 2】(13分)
在人力资源有限的情况下，张工不可能找到专门的测试人员全程进行测试，那么张工应做哪些
改进来提高测试工作的质量，试以 300字内回答。
案例分析
该案例中描述的场景是很多软件公司中常见的场景，由于市场的恶性竞争或是其他原因，开发
的费用被一再压缩。为了满足成本的约束，项目经理忽视测试的工作，项目组成员在项目中身兼多
职，从需求一直做到测试。系统缺乏完整的测试，甚至没有测试就提交给客户。虽然案例中没有写
明，但结果已经可以想像，客户为充满问题的系统而恼火，即使项目谈不上失败也绝对谈不上成功。
人们常说：“再穷不能穷教育”，对于软件项目而言就是“再省不能省测试”。软件系统的技术
复杂度相对较高，结果抽象，可以模式化的东西很少，开发过程也是一种探索的过程，在每一个步
骤都会制造缺陷，这已经在无数的软件系统开发中得到了验证。成功的系统总是正视这种客观情况，
通过各种各样的方法来提高质量，尽可能早地检出系统中潜在的缺陷；失败的项目则是回避，总是
假设不会出现缺陷或缺陷很少，．任由错误扩大，最终肯定是缺陷的大爆发，开发人员疲于修正缺陷，
同时再引入新的缺陷。
在案例中，张工在人力资源不足和项目质量上进行了折中，进行角色复用，把开发和测试安排
到一起，根据缺陷发现的趋势来判断测试是否可以结束，于是问题就出现了。
对于软件开发中的角色复用，专门的论述并不多见。我们在这里引用 MSF中关于开发角色和角
色合并的内容进行讲解与分析。在微软的项目管理框架一 MSF中定义了软件项目中的 6种角色：
(1)产品管理，负责产品的定义，如客户代表、产品负责人、需求人员。
(2)程序管理，按项目的约束进行交付，如项目经理、开发主管。
(3)开发，根据规格说明书(需求规格说明书、设计说明书等)进行系统的构建，如系统设计人员、
编码人员。
(4)测试，确定并找到系统中的质量问题，如测试人员。
(5)用户体验，负责把握用户在使用系统时的感受，例如，需求人员、界面设计人员、系统培训
人员。用户体验不同于产品管理，用户体验着重从用户处获得需求与反馈信息，而产品管理则注重
于产品的定义，其定义的依据既包括用户需求也包括产品路线图等内容。
(6)发布管理，负责系统的部署的稳定的运行，例如项目经理、系统管理员。
在 MSF中给出了角色间合并的建议，如表 5-2所示。
根据表 5-2可以看出，开发人员虽然是程序的创造者，但不推荐和其他任一种角色合并。MSF
是微软总结了其多年的开发经验整理出来的项目管理框架。也就是说，即使是在微软这样的公司，
虽然每个人都有足够的能力，但开发人员仍需要独立出来，不能够与测试混为一谈。
这一点也不难理解。首先开发人员与测试
人员的技能侧重点不同，开发人员侧重于技术
的细节，关注于系统实现所采用的技术和方法，
更需要把握如何应用技术手段构建满足规格
说明书的系统；测试人员侧重于技术的结果，
关注于系统实现后的表现和效果，更需要把
握实现的系统是否满足规格说明书的要求。其次，开发人员与测试人员的目标不同，开发人员希望
能够构建出完全符合要求的系统；测试人员则需要在看似完全符合要求的系统中寻找缺陷和漏洞。
因此，开发人员同测试人员的视角不同，开发人员总是倾向于构建后的系统是完美的，而测试人员
则倾向于构建后的系统是有缺陷的。这种种不同，造成开发人员很难发现自己构建的系统中的缺
陷，存在盲点，而测试人员更容易发现系统中的问题。
再回到这个案例，不难发现，张工正是在这一点上犯了错误，把开发和测试结合到了一起，让
程序员测试自己开发的程序。
在问题 1中，要求对张工进行的测试安排进行点评，上面我们已经谈到，第二点是肯定有问题，
那么其余两点呢？
对于第一点来说，是完全可以的。虽然在严格的软件开发模型中定义了单元测试、集成测试和
系统测试，但在实际项目中完全可以根据项目情况进行裁减。如果系统复杂度不高，系统规模又比
较小，我们可以考虑
