8、在 V 模型和 W 模型中都存在一定的局限性，它们都把软件的开发过程视为需求、设计、编
码等一系列串行的活动，但实际上，这些串行活动之间存在着相互牵制的关系，并且在大部分
时间内，他们是可以交叉进行的。（掌握）
9、H 模型将测试活动完全独立出来，形成一个完全独立的流程（掌握）
10、H 模型图仅仅演示了在整个生存周期中某个层次上的一次“测试循环”。图中的其他流程可
以是任意开发流程，如设计流程和编码流程。也可以是其他非开发流程，如SQA 流程，甚至是
测试流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行
了（掌握）
11、H 模型揭示了一个原理：软件测试模型是一个独立的流程，贯穿于整个软件产品的周期，
与其他流程并发地进行。（掌握）
152
153
12、对V模型的最主要批评是V模型无法引导项目的全部过程。X模型也是对V模型的改进，X
模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合
成为可执行的程序。（掌握）
13、X模型的左边描述的是针对单独程序片段进行的相互分离的编码和测试（掌握）
14、X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试（掌握）
15、前置测试模型将测试和开发紧密结合，提供了一种轻松的方式，可以使你的项目加快速度。
（掌握）
16、前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之
间的关键行为。（掌握）
17、前置测试将测试执行和开发结合在一起，并在开发阶段以“编码一测试一编码一测试”的
方式来体现。当程序片段一旦编写完成，就会立即进行测试。一般情况下，先进行的测试是单
元测试，因为开发人员认为通过测试来发现错误是最经济的方式。（掌握）
18、与V模型不同的是，前置测试模型认识到验收测试中所包含的3个要素：基于测试的需求、
验收标准和验收测试计划，其中基于测试的需求和验收标准都与业务需求定义相联系，但是，
验收测试计划则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行
的一些明确操作定义所组成。（掌握）
19、前置测试模型用较低的成本来及早发现错误，并且充分强调了测试对确保系统的高质量的
重要意义。在整个开发过程中，反复使用了各种测试技术以使开发人员、经理和用户节省其时
间，简化其工作。（掌握）
20、按照不同的划分方式，软件测试分为不同的类型。当按照开发阶段划分时，软件测试类型
分为单元测试、集成测试、系统测试和验收测试。当按照测试实施组织划分时，软件测试类型
分为开发方测试、用户测试、第三方测试。当按照测试技术划分时，软件测试类型分为黑盒测
试、白盒测试和灰盒测试。当按照测试执行方式划分时，软件测试类型分为静态测试和动态测
试。当按照测试对象类型划分时，软件测试类型分为功能测试、界面测试、流程测试、接口测
试、安装测试、文档测试、源代码测试、数据库测试、网络测试和性能测试。当按照质量属性
划分时；软件测试类型分为容错性测试、兼容性测试、安全性测试、可靠性测试、维护性测试、
可移植性测试和易用性测试。当按照测试地域划分时,软件测试类型分为本地化测试和国际化测
试。（掌握）
21、按开发阶段划分，如图（掌握）
154
22、单元测试又称模块测试，是针对软件设计的最小单元（即程序模块）进行正确性检验的工
作。
23、集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基
础上，将所有模块按照设计要求（如根据结构图）组装成子系统或系统进行的测试活动。（掌握）
24、系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等
是否满足其规约所指定的要求。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要
包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。系统测试的目的
是在真实系统工作环境下通过与系统的需求定义作比铰，检验完整的软件配置项能否和系统正
确连接，发现软件与系统设计文档或软件开发合同规定不符合或与之矛盾的地方（掌握）
25、验收测试：验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行
的软件测试活动，它是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试。
按照测试执行者的不同，对不同项目的验收测试的称呼也不同。当测试的执行者是测试内部人
员，且待测系统为公司内部产品时，我们称为发布测试或确认测试。当测试的执行者是客户或
用户，且待测系统为交付客户的项目时，我们称为验收测试或交付测试。
27、开发方测试通常也叫“验证测试”或“α测试”。Alpha 测试是由一个用户在开发环境下进
行的测试，不能由程序员或测试员(有的地方又说可以让测试人员进行)完成。测试发现的错误，
可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。（掌握）
28、用户测试是在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符
合自己预期的要求。通常情况下用户测试不是指用户的“验收测试”，而是指用户的使用性测试。
Beta 测试（即β测试）通过被看成是一种“用户测试”。
29、α、β、γ常用来表示软件测试过程中的三个阶段：α是第一阶段，一般只供内部测试使
用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，
一般只提供给特定的用户群来测试使用；γ是第三个阶段，此时产品已经相当成熟，只需在个
别地方再做进一步的优化处理即可上市发行。（掌握）
155
30、第三方测试也称为独立测试，是介于软件开发方和用户方之间的测试组织的测试。（掌握）
一般情况下是在模拟用户真实应用环境下，进行软件确认测试。第三方测试有别于开发人员或
用户进行的测试，其目的是为了保证测试工作的客观性。从国外的经验来看，测试逐渐由专业
的第三方承担。同时第三方测试还可适当兼顾初级监理的功能，第三方测试以合同的形式制约
了测试方，使得它与开发方存在某种“对立”的关系，所以它不会刻意维护开发方的利益，保
证了测试工作在一开始就具有客观性。
31、按照测试技术划分（掌握）
32、黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。黑盒测试着眼
于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是
以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。从理论上讲，黑盒测试只
有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判
定表法、正交试验设计法、功能图法、场景分析法等。（掌握）
33、白盒测试又称结构测试其目的是通过检查软件内部的逻辑结构，对软件中逻辑路径进行覆
盖的测试，可以覆盖全部代码、分支、路径和条件。（掌握）
35、灰盒测试是介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性，
同时也关注内部表现，但这种关注不像白盒测试详细、完整，只是通过一些表征的现象、事件、
标志来判断内部的运行状态。灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑
结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。（了解）
36、按测试执行方式划分（了解）
156
37、静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；静态测试技术又称为
静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码、用户手
册等进行非运行的检查。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由
人工进行，也可以借助软件工具自动进行。（掌握）
38、动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部
表现。动态方法指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率结果
与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：编写测试用例，
执行程序，分析程序的输出结果。
40、功能测试：对软件功能进行的测试，主要检查软件功能是否实现了软件功能说明书（软件
需求）上的功能要求。（了解）
41、界面测试：对软件的用户界面进行的测试，主要检查用户界面的美观度、统一性、易用性
等方面的内容（了解）
42、流程测试：按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程，其目的是检
查软件在按流程操作时是否能够正确处理。（了解）
43、接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间
以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，
以及系统间的相互逻辑依赖关系等。（了解）
44、安装测试包括测试安装代码以及安装手册,安装手册提供如何进行安装，安装代码提供安装
一些程序能够运行的基础数据。（了解）
46、源代码测试：通过本类型的测评发现应用程序、源代码中包括 OWASP 十大 Web 漏洞在内
的安全漏洞，识别、定位存在的安全漏洞，并分析漏洞风险，提出整改建议，提高系统的安全
性。（了解）
47、数据库测试的主要因素有：数据完整性、数据有效性和数据操作和更新。（了解）
48、网络测试主要是验证以下几个方面：链路连接情况、错包率、连通性、网络质量、路由策
略、备份路由、网管等（了解）
49、性能测试（了解）
157
（1）负载测试，又叫强度测试，是通过逐步增加系统负载，测试系统性能的变化，并最终确定
在满足性能指标的情况下，系统所能承受的最大负载量的测试。负载测试的目标是确定并确保
系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，
响应时间、事务处理速率和其他与时间相关的方面。
（2）压力测试：对系统逐渐增加压力的测试，来获得系统能提供的最大的服务级别的测试或者
不能接收用户请求的性能点。通俗地讲，压力测试是为了发现在什么条件下应用程序的性能会
变得不可接受。压力测试包括并发测试和大数据量测试。
①并发测试：主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问
题，如内存泄漏、线程锁、资源争用等问题，几乎所有的性能测试都会涉及并发测试。并发测
试目的不是为了获得性能指标，而是为了发现并发引起的问题。
②大数据量测试。大数据量测试包括独立的数据量测试和综合数据量测试两类。独立的数据量
测试指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试。综合数据量测试指
和压力性能测试、负载性能测试、稳定性性能测试相结合的综合测试。
（3）稳定性测试。也叫疲劳强度测试。通常是采用系统稳定运行情况下的并发用户数，或者日
常运行用户数，持续运行较长一段时间，保证达到系统疲劳强度需求的业务量，通过综合分析
交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程。
稳定性测试是概率性的测试，也就是说即使稳定性测试通过，也不能保证系统实际运行的时候
不出问题。所以要尽可能提高测试的可靠性。可以通过多次测试，延长测试时间，增大测试压
力来提高测试的可靠性。
51、容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施
或者某种灾难性恢复的手段。（了解）
52、兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平
台上、不同的网络等环境中是否能够很友好的运行的测试。（了解）
53、安全测试是在IT 软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进
行检验以验证产品符合安全需求定义和产品质量标准的过程。（了解）
54、软件可靠性测试是指在预期的使用环境中，为检测出软件缺陷，验证和评估是否达到用户
对软件可靠性需求而组织实施的一种软件测试。（了解）
55、可用性测试，是评估（测试）设计方案或者产品的可用性水平。（了解）
56、维护性测试，可维护性是衡量对已经完成的软件进行调整需要多大的努力。（了解）
57、可移植性测试：可移植性指未经修改或修改部分源代码后，应用程序或系统从一种环境移
植到另一种环境中还能正常工作的难易程度。根据可移植性测试类型与指标体系结构的对应关
系，可移植性测试类型包括代码变更测试、安装测试、用户界面测试和功能测试。（了解）
58、易用性测试主要考察评定软件的易学易用性、各个功能是否易于完成、软件界面是否友好
等（了解）
60、本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软
件本地化质量。（了解）
61、软件国际化的测试就是验证软件产品是否支持一些特性，包括多字节字符集的支持、区域
设置、时区设置、界面定制性、内嵌字符串编码和字符串扩展等。设计评审和代码审查是国际
158
化测试中最有效的方法（了解）
62、软件测试技术主要包括白盒测试技术和黑盒测试技术，然而随着近些年测试技术的不断应
用及实践，功能自动化测试技术、接口测试技术、性能测试技术以及探索式测试技术都被人们
越来越重视（掌握）
63、黑盒测试主要检查程序外部结构，不考虑内部逻辑结构。（掌握）
66、黑盒测试的测试用例设计方法主要有：测试区域确定法、数据覆盖法、逻辑推断法、业务
路径覆盖法等等。（掌握）
67、测试区域确定法分为等价类划分法和边界值分析法（掌握）
69、。长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发
生在输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多的错误。（掌握）
71、组合覆盖是设计尽可能少的测试用例；使各个被测元素的中的各类测试数据组合都被至少
执行一次。组合覆盖是覆盖率很高的覆盖法。组合覆盖测试技术是一种设计测试用例的方法，
它利用组合产生能够覆盖规定组合的测试用例。根据覆盖程度的不同，可以分为全组合覆盖、
成对组合覆盖、正交实验设计法、数据覆盖法等。这种方法力求用尽可能少的测试用例，覆盖
尽可能多的影响因素（掌握）
72、逻辑推断法包括因果图法、判定表法和大纲法等（掌握）
73、业务路径覆盖法包括场景分析法和功能图法（掌握）
74、场景主要包括4 种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景,假定
推测的场景。（掌握）
75、白盒测试又称为结构测试或逻辑驱动测试。
77、静态白盒测试是在不执行的条件下，有条理地仔细审查软件设计、体系结构和代码从而找
出软件缺陷的过程。静态白盒测试的优点：（掌握）
（1）尽早发现软件缺陷。
（2）为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路。
78、动态白盒测试又称结构测试，因为软件测试员可以查看并使用代码的内部结构，从而设计
和执行测试。（掌握）
79、测试管理是为了实现测试工作预期目标，以测试人员为中心，对测试生命周期及其所涉及
的相应资源进行有效的计划、组织、领导和控制的协调活动。（了解）
80、测试管理的主要因素包括测试策略的制定、测试项目进度跟进、项目风险的评估、测试文
档的评审、测试内部和外部的协调沟通、测试人员的培养等。（了解）
81、测试管理的内容按照管理范围和对象，一般可分为测试部门管理和测试项目管理两种。测
试部门管理包含部门日常事务、部门人员、部门下属项目、部门资产等的跟賒及管理工作。测
试项目管理包含测试人员管理、测试计划及测试策略的编写、测试评审的组织、测试过程的跟
进、测试内部和外部的沟通协调、缺陷跟踪等。（了解）
82、测试监控的目的是为测试活动提供反馈信息和可视性。测试监控的内容如下。（了解）
（1）测试用例执行的进度（2）缺陷的存活时间（3）缺陷的趋势分析（4）缺陷分布密度（5）
缺陷修改质量。18 年 5 月第 62 考题
83、测试过程中的配置管理不仅包括搭建满足要求的测试环境，还包括获取正确的测试、发布
159
版本。（了解）
84、在测试工作中，主要的风险表现为以下几个方面：（1）需求风险（2）测试用例风险（3）
缺陷风险（4）代码质量风险（5）测试环境风险（6）测试技术风险（7）回归测试风险（8）
沟通协调风险（9）其他不可预计风险。18 年 11 月第 63 考题
第三十四章 项目管理成熟度模型
2、项目管理成熟度模型的要素包括改进的内容和改进的步骤，使用该模型用户需要知道自己现
在所处的状态,还必须知道实现改进的路线图。项目管理成熟度模型有以不三个基本组成部分
（掌握）
3、Kerzner提出的项目成熟度模型分为5个梯级（1）通用术语（2）通用过程（3）单一方法（4）
基准比较（5）持续改进（掌握）
4、组织级项目管理OPM致力于集成如下内容。（掌握）
（1）知识（项目组合、项目集和项目过程的知识)。
（2）组织战略（使命、愿景、目的和目标）。
（ 3 ）人（有胜任能力的资源）。
（ 4 ）过程（过程改进各个阶段的应用）。
5、项目组合管理通过选择正确的项目集或项目，对工作进行优先排序，以及提供所需资源，来
与组织战略保持一致。项目集管理对项目集所包含的项目和其他组成部分进行协调，对它们之
间的依赖关系进行控制，从而实现既定收益。项目管理通过制订和实施计划来完成既定的项目
范围，为所在项目集或项目组合的目标服务，并最终为组织战略服务。（掌握）
6、OPM 是人员、知识和过程的集成，它基于目标市场价值战略，以贯穿所有层次域的工具做
160
161
支撑（掌握）
7、组织级项目管理由三个层次域组成：项目组合、项目集和项目。（掌握）
8、过程改进的步骤：标准化、度量、控制、改进（掌握）
9、0PM3运作周期的管理改进步骤。（掌握）
（1）获取知识：准备评估。在此步骤中，组织为一次组织级项目管理评估而做准备
（2）实施评估。在此步骤中，组织的能力和OPM模型的能力进行比较
（3）管理改进：制订改进计划。
（4）管理改进：实施改进。
（5）管理改进：重复此过程。在完成改进周期的基础上，组织评估针对所选组织能力的改进是
否对业务成果产生影响。如果需要更多的改进，组织可以定期地重复OPM3运作周期来获得期
望的结果
10、0PM3 架构描述了 0PM3 组件和它们之间的关系。这些组件包括层次域、过程改进阶段、
最佳实践、能力和成果。（掌握）
11、最佳实践指的是目前公认的在一个特定的行业或学科实现一个目标或目的的最佳方法。（掌
握）
12、组织运行潜能是架构、文化、技术和人力资源实践，它们能成为支持和持续实施项目组合、
项目集和项目中最佳实践的杠杆。（掌握）
13、CMMI过程域可以分为4类，包括项目管理、过程管理、工程和支持等4个类别。18年11
月第56考题
14、CMMI 支持两种使用级别的改进路径。一条路径使组织能够逐步改进其选定的单个过程域
（或一组过程域）所对应的过程。另一条路径使组织能够以增量方式应对层次相继的过程域集
162
合来改进相关的过程集。这两种改进路径与两种类型的级别相关联：能力等级与成熟度级别。
这些等级或级别对应至两种过程改进方法，称作“表示法”。这两种表示法被称为“连续式”与
“阶段式”。使用连续式表示法使你能够达成“能力等级”。使用阶段式表示法使你能够达成“成
熟度级别”。（掌握）18 年 11 月第 9 考题
15、CMMI 具有连续式表示法与阶段式表示法两种结构。阶段式表示法相对于模型整体，使用
成熟度级别来描述组织过程总体状态的特征；而连续式表示法则相对于单个过程域，使用能力
等级来描述组织过程状态的特征。（掌握）
16、能力等级适用于组织在单个过程域的过程改进达成情况。（掌握）
17、成熟度级别适用于组织内横跨多个过程域的过程改进达成情况。（掌握）
18、两种对比（掌握）
1）成熟度级别1级：初始级
处于成熟度级别1级时，过程通常是随意且混乱的
2）成熟度级别2级:已管理级
处于成熟度级别2级时，项目确保其过程按照方针得到计划与执行；项目雇用有技能的人，具
备充分的资源以产生受控的输出；使相关干系人参与其中；得到监督、控制与评审；并且对其
过程描述的遵守程度得到评价。
3）成熟度级别3级：已定义级
处于成熟度级别3级时，过程得到清晰的说明与理解，并以标准、规程、工具与方法的形式进
行描述。
4）成熟度级别4级：已量化管理级18年5月第8考题
在成熟度级别4级，组织与项目建立了质量与过程性能的量化目标并将其用作管理项目的准则。
量化目标基于客户、最终用户、组织、过程实施人员的需要。质量与过程性能以统计术语的形
式得到理解，并在项目的整个生命期内得到管理。
5）成熟度级别5级：优化级
处于成熟度级别5级时，组织基于对其业务目标与绩效需要的量化理解，不断改进其过程。组
织使用量化的方法来理解过程中固有的偏差与过程结果的原因。
第三十五章 量化的项目管理
1、量化项目管理（QPM）的目的在于量化地管理项目，以达成项目己建立的质量与过程性能
目标。（掌握）
3、量化项目管理的目的在于量化地管理项目,以达成项目已建立的质量与过程性能目标。这个
过程域包括两个具体目标:（1）准备量化管理项目（2）量化地管理项目。（掌握）
4、准备量化管理主要工作是进行量化管理的准备工作。准备活动包括建立项目的量化目标,组
成有助于达成那些目标的项目已定义过程,选择对理解性能及达成目标起关键作用的子过程与
属性，并选择支持量化管理的度量项与分析技术。（掌握）
（1）建立项目的目标：主要工作是建立并维护项目的质量与过程性能目标。
（2）组成已定义的过程：主要工作是使用统计与其他量化技术，组成使项目能够达成其质量与
过程性能目标的已定义过程。
（3）选择子过程与属性：主要工作是选择对评价性能起关键作用，并有助于达成项目质量与过
程性能目标的子过程与属性。
（4）选择度量项与分析技术：主要工作是选择将用于量化管理的度量项与分析技术。
5、量化的管理项目主要工作是使项目得到量化管理。量化管理项目涉及使用统计与其他量化技
术执行以下活动。（掌握）
（1）使用统计与其他的量化技术监督所选子过程。
（2）确定项目的质量与过程性能目标是否正在得到满足。
（3）对所选问题执行根本原因分析以解决不足。
6、作为 IT 企业，在开始选择度量时，可以从少数的度量值入手，这样才能更便捷、准确和一
致地收集到数据。下面给出一个适合起步阶段的度量方案。（ 1 ）生产率（2）质量（3）规模成
本（4）时间（掌握）
10、度量收集的工具：在收集度量数据的时候，应该利用现有的数据收集形式或者体系，避免
重复和馄乱，尽可能利用自动化的工具帮助度量数据的收集和分析（掌握）
11、可以将度量分为过程度量、项目度量、技术度量。过程度量是量化了用于软件开发的环境
或者过程的特征，过程度量具有战略性目的有助于进行连续的过程改进。项目度量量化了被开
发软件项目的特征，项目度量具有战术性目的，辅助估算、质量控制、生产率评估、项目控制
等。技术度量是评估技术工作产品的质量，在项目中进行决策，比如：项目的复杂性，偶合性
等。对于项目管理者，感兴趣的是项目度量和过程度量。（掌握）
12、其中GQM 和 PSM 是两种重要的度量方法或者技术。（掌握）
13、度量过程模型是通过计划，实施，检查，行动的管理顺序构造的，包括四个基本活动：计
划度量、执行度量、评价度量、建立和维持承诺。（掌握）
14、量化项目管理要以数据为基础。（掌握）
163
164
第三十六章 知识产权与法规、标准规范
1、当事人釆用合同书形式订立合同的，自双方当事人签字或者盖章时合同成立。当事人采用信
件、数据电文等形式订立合同的，可以在合同成立之前要求签订确认书。签订确认书时合同成
立。（掌握）
采用格式条款订立合同的，提供格式条款的一方应当遵循公平原则确定当事人之间的权利和义
务，并采取合理的方式提请对方注意免除或者限制其责任的条款，按照对方的要求，对该条款
予以说明。格式条款是当事人为了重复使用而预先拟定，并在订立合同时未与对方协商的条款。
对格式条款的理解发生争议的，应当按照通常理解予以解释。对格式条款有两种以上解释的，
应当作出不利于提供格式条款一方的解释。格式条款和非格式条款不一致的，应当采用非格式
条款。（掌握）
2、合同中的下列免责条款无效：（掌握）
（1）造成对方人身伤害的。
（2）因故意或者重大过失造成对方财产损失的。
3、债权人转让权利的，应当通知债务人。（掌握）
4、债务人将合同的义务全部或者部分转移给第三人的，应当经债权人同意。（掌握）
5、当事人可以依照《中华人民共和国担保法》约定，一方向对方给付定金作为债权的担保。债
务人履行债务后，定金应当抵作价款或者收回。给付定金的一方不履行约定的债务的，无权要
求返还定金；收受定金的一方不履行约定的债务的，应当双倍返还定金。当事人既约定违约金，
又约定定金的，一方违约时，对方可以选择适用违约金或者定金条款。（掌握）
6、当事人一方违约后，对方应当采取适当措施防止损失的扩大；没有采取适当措施致使损失扩
大的，不得就扩大的损失要求赔偿。当事人因防止损失扩大而支出的合理费用，由违约方承担。
当事人双方都违反合同的，应当各自承担相应的责任。（掌握）
第四十章 项目收尾管理
ü 1、项目的收尾管理包含合同收尾和管理收尾 2 个方面。合同收尾主要是履行合同条款，
关闭合同；管理收尾也叫做行政收尾，主要是进行项目的后评价，总结经验教训，更新组
织过程资产等活动。
ü 2、项目收尾阶段是收获项目成果的阶段，这个阶段的结束，标志着整个项目管理过程的最
终结束。项目收尾阶段也需要以某种正式的活动作为结束标志：主要是完成项目交付成果
的检验，由承建方将完成的成果交与用户方，业主（用户）确认成果符合合同规定。项目
收尾工作的另一重要内容是从项目中获得相关经验，以便指导和改善未来项目的运作和实
施。
ü 3、项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。
165
ü 4、项目的正式验收包括验收项目产品、文档及已经完成的交付成果。验收需要正式的验收
报告。对于系统集成项目，一般来讲，需要正式的验收测试工作。验收测试工作可以由业
主和承建单位共同进行，也可以由第三方公司进行，但无论哪种方式都需要双方认可的正
式文档为依据进行验收测试。如果验收测试未获通过，则应立即查找原因，一般会转向变
更环节进行修改和补救。如果项目验收测试正式通过，则标志着项目验收的完成。（掌握）
ü 5、系统集成项目的验收工作包括如下步骤：
（1）系统测试（2）系统的试运行（3）系统的文档验收（4）项目的最终验收报告
对于系统集成项目，所涉及的文档应该包含如下部分：
（1）系统集成项目介绍（2）系统集成项目最终报告（3）信息系统说明手册（4）信息系
统维护手册（5）软硬件产品说明书、质量保证书等
ü 6、最终验收报告就是业主方认可承建方的项目工作的最主要文件之一，这是确认项目工作
结束的重要标志性工作。对于信息系统而言，最终验收标志着项目的结束和售后服务的开
始。（掌握）
ü 7、项目总结的主要意义如下。（掌握）
（1）了解项目全过程的工作情况及相关的团队或成员的绩效状况。
（2）了解出现的问题并进行改进措施总结。
（3）了解项目全过程中出现的值得吸取的经验并进行总结。
（4）对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。
ü 8、一般的项目总结会应讨论如下内容：项目绩效、技术绩效、成本绩效、进度计划绩效、
项目的沟通、识别问题和解决问题、意见和建议。（了解）
第四十一章 常见案例答题要点
ü 1、看到有技术人员出身做项目经理就要回答在信息系统工程中，开发和管理是两条不同的
主线，开发人员所需要的技能与管理人员所需要的技能很不一样。角色定位可能不好、没
有站在项目经理的角度管理项目，所以需要给他培训。
ü 2、看到身兼数职就要回答可能没有多少时间去学习管理知识，去从事管理工作。一人承担
两个角色的工作，导致工作负荷过载，身心疲惫，其后果可能给全局带来不利影响。
ü 3、看到新技术，就要想到风险，接着就是应该对大家进行培训、学习，然后监控技术风险，
或者找合适的人选从事这项工作，最后实在不行就外包。
ü 4、看到有人对项目不满意就要回答可能没有建立有效的沟通机制和方式、方法，缺乏有效
的项目绩效管理机制，需要加强沟通。
ü 5、看到变更的方面就一定是变更的三个要素：书面申请、审批和确认、跟踪变更过程。这
三个方面缺一不可。
ü 6、看到由客户验收不通过，往往需要说明验收标准没有得到认可或确认，没有验收测试规
范和方法等。
ü 7、只要是与人有关的问题,均可以找到沟通方面的答案。
ü 8、看到过了一段时间才发现问题就说明监控不力。
ü 9、看到里程碑或一些时间安排的很紧张，就说明没有考虑到冗余的思想
ü 10、看到因为外部的因素导致项目的延工等就要想到可能影响变更的原因
ü 11、看到有争执就可以想到沟通问题，或者计划做的不够周到
ü 12、看到多头汇报的问题，就要想到项目经理权限的问题以及沟通、冲突等问题。
1、可研、整体管理
ü 可行性研究的内容：
①技术可行性分析；②经济可行性分析；③运行环境可行性分析；④其他方面的可行性分
析（法律可行性、社会可行性）。
ü 可 行 性研 究报 告内容：
①引言；②可行性研究的前提；③对现有系统的分析；④所建议的系统；⑤可选择的其他
系统方案；⑥投资及效益分析；⑦社会因素方面的可行性；⑧结论。
ü 项目章程内容：
①项目需求，反应干系人的要求与期望；②项目必须实现的商业需求、项目概述或产品需
求；③项目的目的或论证的结果；④任命项目经理并授权；⑤里程碑进度计划；⑥干系人的影
响；⑦组织职能；⑧组织的、环境的和外部的假设；⑨组织的、环境的和外部的约束；⑩论证
项目业务预算，包括投资回报率；⑾概要预算。
ü 项目收尾和整体管理问题补救措施
项目收尾包括合同收尾和管理收尾。合同收尾就是按照合同约定，项目组和业主一项项的
合规，检查是否完成了合同所有的要求，是否可以把项目结束掉，也就是我们通常所讲的项目
验收；管理收尾是对于内部来说的，把做好的项目文档等归档，对外宣称项目已结束，转入维
护期，把相关的产品说明书转到维护组，同时进行经验教训总结。
项目整体管理计划的内容，项目整体管理中存在的问题及补救措施？如何做好整体管理应
该从下面着手，大家考试的时候可以根据案例中主人公的做法和题目要求选择几点进行回答：
①建立企业级的项目管理体系和工作规范，管理上不乱
②明确可交付物
③培训学习项目管理知识，提高管理能力
④做好经验的总结，做好各项计划
⑤做好整体管理，项目过程
⑥加强变更管理与控制，建立变更流程与体系
⑦要有项目启动－可行性分析
⑧要制定项目章程
ü 制定计划过程中常见问题总结：
1、计划应有项目组参与制定
2、计划内容不周全或不充分或缺少计划
166
167
3、没有评审和审批就执行
4、项目已经变更，计划未更新
5、没有处理好内部依赖关系和制约因素，对计划产生影响
6、执行方法不合理
ü 计划的编制原则：
1、目标的统一管理
2、方案的统一管理
3、过程的统一管理
4、技术工作与管理工作的统一协调
5、计划的统一管理
6、人力资源的统一管理
7、各干系人的参与
8、逐步求精
ü 项目整体管理计划中应包含哪些内容？
（1）所使用的项目管理过程。
（2）每个特定项目管理过程的实施程度。
（3）完成这些项目的工具和技术的描述。
（4）选择的项目的生命周期和相关的项目阶段。
（5）如何用选定的过程来管理具体的项目。包括过程之间的依赖与交互关系和基本的输入输
出等。
（6）如何执行工作来完成项目目标。
（7）如何监督和控制变更。
（8）如何实施配置管理。
（9）如何维护项目绩效基线的完整性。
（10）与项目干系人进行沟通的要求和技术。
（11）为项目选择的生命周期模型。对于多阶段项目，要包括所定义阶段是如何划分的。
（12）为了解决某些遗留问题和未定的决策，对于其内容、严重程度和紧迫程度进行的关键
管理评审。
ü 项目管理计划编制工作流程
（1）明确项目目标和阶段目标
（2）成立初步的项目团队
（3）工作准备与信息收集
（4）依据标准、模版等编写初步的概要的项目计划
（5）编写范围管理、质量管理、进度、预算等分计划
（6）将上述分计划纳入项目计划，然后对项目计划进行综合平衡、优化
（7）项目经理负责组织编写项目计划
（8）评审与批准项目计划
（9）项目获批，形成了项目的基准计划
2、范围管理
从历年考试情况来看，项目的范围管理属于下午案例分析的重点，希望大家能够引起重视。
ü 范围管理可能问题：
（1）没有挖掘到全部隐性需求，缺乏精确的范围定义；（2）没有有效的范围管理，造成二
次变更；（3）对范围控制不足；（4）没有和客户进行需求确认（5）没有制定范围管理计划或项
目管理计划（6）变更结果没有得到客户的确认。
ü 范围管理应对措施：
①对项目范围进行清晰定义，并根据定义对工作进行分解，制定WBS；②对项目进行合理
估算，对工作量有量化的把握；③对项目范围进行有效控制；④重新定义项目范围必须得到高
层和客户的确认；⑤进行沟通管理，协调多个项目干系人之间的矛盾。
ü 可能案例模式：
引用书上的原话：从10大知识领域对项目成功产生影响的轻重程度上来看，项目范围管理
是最为重要的。
（1）提到范围管理这里面常见的案例模式，需求管理对范围管理的影响。往往是在叙述一
段案例情景中，描述了前期的需求不明确即开工，而导致项目失败，或者其他因需求得不到满
足，而项目失败。
答题要点：
①在开发合同中没有明确系统的需求，没有进行范围确认。（万金油）
②对需求变更没有规范管理，变更没有依据。（ 万金油 ）
（ 2 ）因为 范围 不明确即开工，变更混乱，导致甲乙双方丧失信心，项目失败。简单来说游
戏规则没定好，就开始游戏。
答题要点：（以下5点也是范围管理的基本内容，不要跟过程组弄混了）
①确定项目的需求
②定义规划项目的范围
③范围管理的实施
④范围的变更控制管理
⑤范围核实
补充：
范围管理就是根据客户提出的目标形成系统功能，并经客户确认的过程。范围管理保证项
目包含了所有要做的工作而且只包含要做的工作，他主要涉及定义并控制哪些是项目范畴内的，
哪些不是。
（3）提到范围就不得不说WBS，WBS的案例也会可能出现，出现方式往往是考察你对WBS
的理解，另外让你画一下树形结构的WBS（这个不用怕，往往题目已经给你画好了一部分，按
照格式往上写就行了，属于送分题）
补充：WBS的主要作用：
①防止应该做的工作被遗漏掉，也防止镀金
168
②方便与项目团队的沟通，项目成员很容易找到自己负责部分在整个项目中的位置
③防止不必要的变更
④提供一个基本的资源（人员和成本）估算依据
⑤帮助获取团队认同和创建团队
创建WBS的原则---这个需要记住
①在各层次上保持项目的完整性，避免遗漏必要的组成部分
②一个工作单元只能从属于某个上层单元，避免交叉从属
③相同层次的工作单元应用相同性质
④工作单元应能分开不同责任者和不同工作内容
⑤便于满足项目管理计划、控制的管理需要。
⑥最低层工作应该具有可比性、是可管理的，可定量检查的。
⑦应包括项目管理工作（因为是项目具体工作的一部分）， 包括 分包 出去的工作。（这点往
往被忽视）
⑧遵守8/80原则。
（4）还有一种情况，说项目搞的很成功，特别是范围管理，然后问你理论题。
ü 项目范围变化将导致哪些类型的项目变更？10大管理都可以写上
1.成本变更 2.进度变更 3.质量标准变更 4.合同变更 5.整体变更 6.质量变更 7.人力
资源等等等
ü 项目范围说明书包含什么内容？ （另外，考试中，可能直接问包含什么？也可能会根据案
例里描述的，要你写还缺什么？）
(1)项目的目标 (2)产品范围描述(3)项目的可交付物(4)项目边界(5)产品验收标准(6)项
目的约束条件(7)项目的假定(8)更新的项目文档
ü 范围变更控制的要点有哪些？
① 确定范围变更是否已经发生；
② 对造成范围变更的因素施加影响，以确保这些变更得到一致的认可；
③ 当范围变更发生时，对实际的变更进行管理。
3、进度管理
从历年考试情况来看，项目的进度管理属于下午案例分析的重点考查内容，涉及到的计算
题建议千万别丢分。
ü 可以采取以下措施，保证项目能满足进度要求：
①进度计划的贯彻；②调度工作；③抓关键活动的进度；④保证资源的及时供应；⑤加强
组织管理工作；⑥加强进度控制工作。
ü 加快进度、压缩工期方法：
①赶工；②快速跟进；③增加优质资源；④提高资源利用率；⑤外包和缩小项目范围。在
工期压缩过程中要注意加强与项目干系人的沟通。与客户进行沟通确定能否缩小范围和外包，
以应对强制性日期的交付；与项目成员沟通，制定好的绩效考核办法，提高每个成员的绩效；
169
170
与职能经理及高层领导沟通，申请增加优质资源等。
ü 补充一点进度万金油：
项目经理经验不足，进度估算不准确（出现几率100%,其他管理也可以套用）
项目资源配置不足或者配置不合理（或人力，或物）
注：记忆方式是人才（材）有技术但缺钱发展是社会环境造成的。
进度管理可能出现的问题以及可以采用的办法，其中还要注意可能会和成本一起考！
（1）团队成员没有及早参与，需求分析耗时长，要早期参与进项目
（2）经验不足，进度计划制定不准，采取有效的历时估算方法和网络计划技术，制定进度
计划
（3）考虑项目期间特定时期会对进度产生影响
（4）增加人手，聘请更有经验的人员，或找兼职人员
（5）加班
（6）并行
（7）重新估算后面的工期
（8）加强沟通，减少变更
（9）加强控制，避免返工
（10）外包
（11）加强沟通，先完成关键需求
（12）增加资源有时可能压缩工期有限
（13）关注关键路径，在关键路径上加资源，有效果
（14）关注里程碑
（15）加强进度与成本、风险、质量等知识点的协调
解决方案:
(1)向公司申请增加资源，或使用经验丰富的员工
(2)优化网络图，重排活动之间的顺序，压缩关键路径
(3)临时加班（赶工），尽可能补救耽误的时间或提高资源利用率
（4）将部分阶段的工作改为并行，并进行内部流程的优化
（5）变更原来的进度计划。根据上一阶段的绩效，对后续工作重新评估，修订计划，并征
得项目干系人的同意
（6)加强同项目干系人的沟通
（7)加强对交付物、项目阶段工作的及时检查和控制，避免后期出现返工
（8）尽可能调配非关键路径上的资源用于关键路径上的任务
（9）优化外包，采购等环节，并全程监控。
4、成本管理
ü 可能案例模式：
成本的案例大多都是计算题，特别是挣值。做这方面的题目切忌不要自以为是，看看例题
都明白，感觉也明白的透彻，真正做起来眼高手低，不是忘记这个就是忘记那个。
另外， 这一块和进度结合起来考的挣值分析，那是考试的重中之重！！！
这一块占的分值极其大，考的概率也极其大。相信大家通过计算题知识的学习，计算应该
不是问题了，然后根据项目目前的状态，需要给出解决方案，这在前面计算题里也有讲过。另
外，对于如下的图要会看， 会画。
ü 成本控制的主要工作内容？
（1）对造成成本基准变更的因素施加影响
（2）确保变更请求获得同意
（3）当变更发生时，管理这些实际的变更
（4）保证潜在的成本超支不超过授权的项目阶段资金和总体资金
（5）监督成本执行，找出与成本基准的偏差
（6）准确记录所有的与成本基准的偏差
（7）防止错误的，不恰当的或未获批准的变更纳入成本或资源使用报告中
（8）就审定的变更，通知项目干系人
（9）采取措施，将预期的成本超支控制在可接受的范围内
5、质量管理
从历年考试情况来看，项目的质量管理属于下午案例分析的重点考查内容，而且上午、论
文也是，希望大家能够引起相当的重视。
ü 项目质量管理可能问题：
（1）有制定可行的质量管理计划并积极实施；（2）没有全面的质量管理进展情况报告；（3）
沟通方式单一或不全面，容易误导用户，致用户不必要的担心（4）质量保证过程中缺乏QA的
参与（5）质量控制环节缺失，例如评审和测试（6）测试方法不当或不充分（7）测试控制的流
程不对，或未进行质量控制就进行了范围确认。
ü 应该怎么解决？
1、严格执行公司的质量管理体系规范工作流程；
2、制定质量管理计划；
171
3、执行质量保证计划；
4、调配相关资源（如：人、财、物等）加强后续质量保证工作；
5、加强后期的质量控制和测试；
6、提前加强产品交付后的客户服务和维护工作；
7、加强沟通；
8、建议必要时修改质量基准争取以最小的代价获得用户认可。
ü 提高信息系统项目质量措施：（重点，比如如何提高信息系统项目质量的方法？）
①强有力领导，②建立组织级项目管理体系，③建立组织级质量管理体系，④建立项目级
激励制度，⑤理解质量成本，⑥提高项目文档质量，⑦发展和遵从成熟度模型。
ü 可能案例模式：
质量的案例是考察重点，往往是直接告诉你项目经理在质量管理做了哪些工作，然后问你
是否做的正确或者完善？然后配合一些概念题目（比如区分或者单独识别质量控制跟质量保证、
质量管理计划的内容、文档的作用等）来考察考生，还可以考一些最基本的工具和技术、过程
步骤等内容。另外质量管理方面也往往跟监理混合起来一起考察。
ü 补充知识点：
质量管理管理计划一般会包括以下几个方面的内容：
（1）质量政策 由项目干系方得决策部门提出的关于质量的期望及方针
（2）质量目标 项目管理质量和项目交付成果应达到的各种指标
（3）质量管理活动 项目重要的质量管理活动，如质量管理工作流程等。
质量控制跟质量保证的区别：质量保证主要是按照既定的质量计划来对过程进行追踪，并
且还包含质量改进；而质量控制则监控项目的具体结果，确定其是否符合项目的质量标准，并
进行不合格情况的追踪。（ 简 单 记忆：质量保证看得是整个项目，控制是关注各阶段具体可交付
成果，另外质量保证工具有质量审计跟过程分析，从这两点上区分控制跟保证。此题也可以结
合输入工具输出来作答）
质量保证包括两方面的内容：一是使用户对项目质量建立信任的外部质量保证；二是对承
建方内部中高层领导保证有对目前各工作的信任。另外质量保证还具有质量改进的作用，通过
对质量控制数据的对比和分析，得出质量改进的方法和建议。
ü 如何进行质量保证？质量保证活动的基本内容？（补充）
（1）制定质量标准；（2）制定质量控制流程；（3）提出质量保证所采用的方法和技术；（4）
建立质量保障体系。
实施质量保证的方法：①首先执行项目的质量管理计划；②采用质量保证的工具和技术；
③提出相应质量整改措施，如建议的纠正措施、对项目计划可能的更新、对组织资产可能的更
新、变更请求。
ü 救火队的原因（项目质量常常遇到的问题）：
①项目交付成果本身有缺陷，例如不稳定或功能不完美；②项目交付成果没有实现预定的
功能需求；③项目在需求分析阶段对用户的需求分析提炼精度不够，没有挖掘到部分重要的需
求；④随着时间和环境的变化，客户产生了新的需求；⑤由于文档的不完备，一方面导致用户
不能解决一些使用问题，另一方面还使得维护工作的效率提不高。
172
ü 质量保证人员，在整个项目中应该完成哪些工作?
（1）计划阶段制定质量管理计划和相应的质量标准
（2）按计划实施质量检查，是否按标准过程实施项目工作。注意项目过程中的质量检查，
每次进行检查之前准备检查清单（checklist）， 并将 质 量管 理相关情况予以记录
（3）依据检查的情况和记录，分析问题，发现问题，与当事人协商进行解决。问题解决后
要进行验证；如果无法与当事人达成一致，应报告项目经理或更高层领导，直至问题解决
（4）定期给项目干系人发质量报告
（5）为项目组成员提供质量管理要求方面的培训或指导
ü 质量控制的工作应做好以下几方面内容：
①对维护工作进行质量控制，做好相关文档工作；②在有条件情况下，开始对已交付系统
进行文档建设，尤其是用户手册的建设工作；③建立组织级的质量管理体系和相关的标准及规
范，取得高层领导的支持和信任，开展整体质量控制观念的培养，在以后工作中实施严格的质
量控制工作。
ü 质量控制的流程或步骤？
（1） 选择控制对象；
（2） 为控制对象确定标准或目标；
（3） 制定实施计划，确定保证措施；
（4） 按计划执行；
（5） 对项目实施情况进行跟踪监测、检查，并将监测的结果与计划或标准相比较；
（6） 发现并分析偏差；
（7） 根据偏差采取相应对策。
6、人力资源管理
从历年考试情况来看，项目的人力资源管理也属于下午案例分析的重点考查内容，希望大
家能够引起重视，因为把人力管理好，项目就成功了一半。
ü 人力资源可能问题：
①缺乏足够的项目管理能力和经验；②兼职过多，精力和时间不够用，顾此失彼；③没有
进入管理角色，定位错误，疏于对项目的管理；④新人缺乏培训和全程的跟踪和监控；⑤没有
进行良好的冲突管理。
ü 应对措施：
①事先制定岗位的要求、职责和选人的标准，并选择合适的人选；②对工作进行全面估算，
如果有人负荷过重，需要找人代替，解决负载平衡问题；③事前沟通并对相应人员明确要求，
明确角色的轻重缓急，促使尽快转换角色；④上级应该注意平时对人员的培养和监控；⑤对项
目团队进行有效的冲突管理。
ü 团队组建常见问题：
①招募不到合适的项目成员；②团队的组成人员尽管富有才干，但却很难合作；③团队气
173
174
氛不积极，造成项目团队成员的士气低落；④项目团队的任务和职责分配不清楚；⑤人员流动
过于频繁。
ü 产生原因：
①没有能够建立人力资源获取和培养的稳定机制；②没有完整识别项目所需的人力资源种
类、数量和相关任职条件；③没有建立一个能充分、有效发挥能力的团队；④没有清楚地分配
工作职责到个人或人力单元。
ü 应对措施：
①建立稳定的人力资源获取和培养机制；②在项目早期，进行项目的整体人力资源规划，
明确岗位设置、工作职责和协作关系；③进行项目团队建设，加强团队沟通，建立合作氛围；
④根据项目团队成员的工作职责和目标，跟踪工作绩效，及时予以调整和改进，提升项目整体
绩效。
ü 可能案例模式：
（1）某某为高级编程人员，因人员紧张，临时提拔为子项目经理并兼任原工作，最终导致
子项目失败。
答题要点：
存在问题：
①身兼多职，精力和时间不够用，顾此失彼②缺乏项目管理能力和经验③没有进入管理角色，
专注编程而忽视管理工作④缺乏事先培训和全程跟踪与监控。
解决办法：
①事先制定岗位要求、职责和人员选用标准，挑选合适的人员。
②避免负荷过重，解决好负载平衡问题。例如：找人接替编程工作，协助其完成角色转换。
③上级注重对相关人员进行培训和培养，对项目、人员工作进行监控。
（2）某某为业务骨干，因无法找到合适项目经理，提拔为子项目经理，随着项目进展，团
队士气降低，返工增加，团队成员间互不信任互相推诿责任。正常例会，人员不齐，包括某某
有时也不参加，某某只专注自己的技术业务，忽视团队建设，团队成员汇报的项目实际进度、
成本言过其实，直到某某进行接口调试时，才发现这些问题。（考察项目经理的选拔和培养，建
设项目管理团队，传授项目管理经验，以及提高整个项目管理团的管理水平和领导水平）
答题要点：
存在问题：（可结合上题进一步细分）
①缺乏项目经理所需的项目管理能力和经验
②对项目经理的培养不重视，选拔任命不规范，缺乏相关技能的培训
③对项目经理的工作缺少指导和监督
④没有有效解决冲突和建立沟通机制
⑤缺乏有效的项目绩效管理机制
解决办法：
（1）明确工作职责，协助其完成角色转换
（2）参加某某例会，发现问题并指导某某的管理工作
（3）加强项目经理的培训或指导
（4）加强项目的日常监督，要求项目经理以身作则
（5）对项目出现的问题，及时提出纠正和预防措施
ü 补充：冲突产生的原因：项目的高压环境、责任模糊、多个上级的存在、新科技的流行。
解决冲突：问题解决或者求存同异妥协解决。
ü 如何组建团队成员？
①事先分派；②谈判；③采购；④虚拟团队。
ü 如何激励团队？
①一般管理技能（如沟通、交流）；②培训；③团队建设活动（如周例会、共同解决问题、
拓展训练）；④共同的行为准则（如基本准则、规章制度）；⑤尽量集中办公（如同地办公、封
闭开发）；⑥认可和奖励（恰当的奖励与表彰措施）。
ü 如何对待项目中出现的冲突？
①运用冲突解决办法正确解决双方冲突；
②提高自己的技术能力，行使专家权力说服冲突双方，获得双方信任；
③对消极怠工员工行使强制力让其努力工作；
④和团队成员增强沟通和交流，获得团队成员的信任；
⑤跟踪个人和团队的执行情况，及时反馈和协调变更；
⑥实行奖励制度以激励团队。
ü 团队成员之间的冲突导致项目失败，包括人员流失。
答题要点：
①项目角色职责是否制定合理；
②要与项目组成员有良好的沟通，要听取各方面意见和建议。
③冲突发生后要及时解决，如果处理失败要及时上报，不能加入一方打击另一方。
④因冲突发生，导致消极怠工，要行使强制力。
⑤要行使专家权利说服争执双方。
⑥如果造成人员流失，要做好弥补工作，提前预防人员流失。
⑦因冲突导致士气低落等，可通过团队建设活动，认可奖励等制度活动来激励团队。
7、沟通管理
从历年考试情况来看，项目的沟通管理也属于下午案例分析的重点考查内容，项目经理80%
的时间用在沟通里。
常用的沟通方式的优缺点或特点介绍如下
（1）书面与口头、听与说
书面的沟通方式优点是清晰，二义性少以及可以作为备忘录，也可作为双方沟通的证据。
而缺点是缺乏人性化，如某些用语较为生硬的话，容易使双方的关系出现矛盾。
口头的沟通方式较为人性化，也容易使双方充分了解和沟通。但口头的沟通也容易产生问
题，例如缺乏沟通的有效证据，当一方的理解和另一方不同时，容易产生较强的分歧。
175
176
（2）对内与对外
项目经理通常采用不同的方式进行对内（项目团队内）和对外（对顾客、媒体和公众等）
的沟通。对内沟通讲求的是效率和准确度，对外沟通强调的是信息的充分和准确。
对内的沟通可以以非正式的方式出现，而对外的沟通要求项目经理以正式的方式进行。
（3）正式与非正式
通常情况下，正式（如报告、情况介绍会等）的沟通是在项目会议时进行的，而非正式（如
备忘录、即兴谈话等）的项目沟通属于大多数场合的方式。
（4）垂直与水平
垂直方向（从下到上或者从上到下）沟通的特点是：沟通倍息传播速度快，准确程度高。水
平方向沟通的特点是：复杂程度高，往往不受当事人的控制。
ü 项目干系人包括：
①项目经理，②顾客/客户，③执行组织，④项目团队成员，⑤项目管理团队，⑥出资人，
⑦有影响的人，⑧项目管理办公室。
ü 如何进行项目干系人分析：
①进行项目干系人识别；②分析项目干系人的重要程度；③进行项目干系人的支持度分析；
④针对不同项目干系人，特别是重要的项目干系人，给出管理项目干系人的建议，并予以实施。
ü 如何改进项目沟通：
①使用项目管理信息系统；②建立沟通基础设施；③使用项目沟通模版；④把握项目沟通
基本原则；⑤发展更好的沟通技能；⑥把握人际沟通风格；⑦进行良好的冲突管理。
ü 如何召开高效会议：
①事先制订一个例会制度；②放弃可开可不开的会议；③明确会议的目的和期望结果；④
发布会议通知；⑤在会议之前将会议资料发给参会人员；⑥可以借助视频设备；⑦明确会议规
则；⑧会议后要总结、提炼结论；⑨会议要有纪要；⑩做好会议的后勤保障。
ü 沟通管理可能问题：
①内部管理有问题，监管不力
②没有或极少与客户进行直接沟通
③现场管理制度执行不力
④总包与分包责任不清
⑤客户获取的信息失真，总包推卸责任
⑥客户自己本身的问题，包括资金、管理水平等
⑦可能监理工作没到位
ü 沟通管理应对措施
①做好干系人分析
②发挥总包的牵头和监理的协调作用
③对共用资源可用性进行分析，引入资源日历
④解决冲突
⑤建立健全项目管理制度并监管其执行
⑥采用项目管理信息系统
177
ü 可能问题和应对措施的补充
（1）缺乏沟通，合作氛围不够
（2）及时信息分发，加强沟通，让客户了解项目具体情况
（3）注重沟通技巧，建立融洽的合作气氛
（4）没有对团队成员的沟通需求和沟通风格进行分析
（5）没有开一个高效的会
（6）沟通方式单一
（7）没有冲突管理
（8）开高效会议的做法
（9）分析成员的沟通风格，从而采用相应的沟通方式
（10）多种沟通方式
（11）采用一些沟通模板
（12）加强冲突管理
（13）采用一些沟通模板
（14）加强冲突管理
（15）多供应商的沟通
（16）解决冲突，包括干系人对项目期望之间的冲突、资源冲突等。
（17）做好干系人分析，调研各集成商的沟通需求。
（18）周期性的沟通。
（19）突发事件的协调。
8、合同管理
从历年考试情况来看，项目的合同管理不属于下午案例分析的重点考查内容，但是鉴于最
近信息系统项目管理师的考试偏向于中级的趋势，建议还是重点学习。
ü 合同签订管理可能的问题
1. 没有做好签订合同之前的调查工作，合同签订过于草率
2. 合同没有制定好，缺乏明确清晰的工作说明或更细化的合同条款
3. 没有采取措施，确保合同签约双方对合同条款的一致理解
4. 合同中缺乏相应的纠纷处理条款
5. 对于签订总价合同的风险认识不足
ü 合同管理里可能会出现的问题
①合同没订好，没有就具体完成的工作形成明确清晰的条款
②甲方没有对需求及其变更进行统一的组织和管理
③缺乏变更的接收/拒绝准则
④项目干系人及其关系分析不到位，范围定义不全面、不准确
⑤甲乙双方对项目范围没有达成一致认可或承诺
⑥缺乏项目全生命周期的范围控制
⑦缺乏客户/用户参与
⑧甲方无法进行跨部门协调
ü 遇到合同管理的问题的答题要点：
遇到的问题：实施范围不清楚、验收标准不清楚、项目沟通有问题、客户不验收或拖延验
收、签字、客户有情绪、不付款、客户对项目质量信心不足、售后没有承诺等。
ü 在合同各阶段进行范围管理（应对措施）
（1）合同谈判阶段：
①取得明确的工作说明书或更细化的合同条款
②在合同中明确双方的权利和义务，尤其是变更
③采取措施，确保合同签约双方对合同的理解是一致的
（2）计划阶段
①编制项目范围说明书
②创建项目的工作分解结构
③制定项目的范围管理计划
（3）执行阶段
①在项目执行过程中加强对已分解的各项任务的跟踪记录
②建立与项目干系人进行沟通的统一渠道
③建立整体变更控制的规程并执行
④加强对项目阶段性成果的评审和确认
⑤项目全生命期范围变更管理
ü 索赔流程：
1、 提出索赔要求
2、 提交索赔资料
3、 索赔答复
4、 索赔认可
5、 提交索赔报告
或者：4、索赔分歧；5、提请仲裁（或者提起诉讼）
ü 如果甲方向乙方公司提出索赔要求，乙方应该如何处理？
1.公司在接到甲方的索赔要求及索赔材料后，应根据公司与甲方签订的合同，进行认真分
析和评估，给出索赔答复；
2. 在双方对索赔认可达成一致的基础上，向甲方进行赔付；如双方不能协商一致，按照合
同约定进行仲裁或诉讼；
3. 同时公司依据与其他相关公司（下游供应商或分包商）签订的合同，向其他公司提出索
赔要求，按索赔流程处理。
ü “公平合理”是合同变更的处理原则，变更合同价款按以下方法进行：
（1）先确定合同变更量清单，然后确定变更价款；
（2）合同中已有适用于项目变更的价格，按合同已有的价格变更合同价款：
178
179
（3）合同中只有类似于项目变更的价格，可以参照类似价格变更合同价款；
（4）合同中没有适用或类似项目变更的价格，由承包人提出适当的变更价格，经监理工程
师和业主确认后执行。
9、采购管理
ü 工作说明书与项目范围说明书的区别：
工作说明书（SOW）是项目对所要提供的产品、成果或服务的描述。SOW 与范围说明书的
区别在于：工作说明书是对项目所要提供的产品或服务的叙述性的描述，项目范围说明书则通
过明确项目应完成的工作而确定了项目的范围。
采购工作说明书应相当详细地规定采购项目，以便潜在的卖方确定他们是否有能力提供这
些项目。项目范围说明书描述了项目的可交付物和产生这些可交付物所必须进行的项目工作，
项目范围说明书在所有项目干系人之间建立了一个对项目范围的共识，描述了项目的主要目标。
10、风险管理
从历年考试情况来看，项目的风险管理也属于下午案例分析的重点考查内容，望大家重视。
ü 主要风险来源：
①需求风险；②技术风险；③团队风险；④关键人员风险；⑤预算风险；⑥范围风险。
风险项 产生原因 应对措施
没有正确理解业务问题
项目干系人对业务问题的
认识不足、计算起来过于复
杂、不合理的业务压力、不
现实的期限
用户培训、系统所有者
和用户的承诺与参与、
使用高水平的系统分析
师
用户不能恰当的使用系统
信息系统没有与组合战略
相结合、对用户没有做足够
的解释、帮助手册编写的不
好、用户培训工作做的不够
用户的定期参与、项目
的阶段交付、加强用户
培训、完善信息系统文
档
拒绝需求变更
固定的预算、固定的期限、
决策者对市场和技术缺乏
正确的理解
变更管理、应急措施
对工作的分析和评估不足 缺乏项目管理经验、工作压力过大、对项目工作不满意
采用标准技术、使用具
有丰富经验的项目管理
师
人员流动
不现实的工作条件、较差的
工作关系、缺乏对职员的长
远期望、行业发展不规范、
保持好的职员条件、确
保人与工作匹配、保持
候补、外聘、行业规范
180
企业规模较小
缺乏合适的开发工具
技术经验不足、缺乏技术管
理准则、技术人员的市场调
研或对市场理解有误、研究
预算不足、组织实力不够
预先测试、教育培训、
选择替代工具、增强组
织实力
缺乏合适的开发与实施人员
对组织架构缺乏认识、缺乏
中长期的人力资源计划、组
织不重视技术人才的技术
工作、行业人才紧缺
外聘、招募、培训
缺乏适合的开发平台
缺乏远见、没有市场和技术
研究、团队庞大陈旧难以转
型、缺乏预算
全面评估、推迟决策
使用了过时的技术 缺乏技术前瞻人才、轻视技术、缺乏预算 延迟项目、标准检测、前期研究、培训
11、文档和配置管理
从历年考试情况来看，项目的配置管理属于下午案例分析的重点考查内容，希望大家能够
引起重视。
ü 配置库可以分为动态库（开发库、程序员库、工作库）、受控库（主库）、静态库（软件仓
库）3种类型。
（1）动态库。也称为开发库、程序员库或工作库，用于保存开发人员当前正在开发的配置
实体。动态库通常包括新模块、文档、数据元素或进行修改的已有元素。动态库是软件工程师
的工作区，由工程师控制。
（2）受控库。也称为主库或系统库，是用于管理当前基线和控制对基线的变更。受控库包
括配置单元和被提升并集成到配置项中的组件。软件工程师和其他人员可以自由地复制受控库
中的单元或组件。然而，必须有适当的权限授权变更。受控库中的单元或组件用于创建集成、
系统和验收测试或对用户发布的构建
（3）静态库。也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基线。静态
库用于控制、保存和检索主媒介。
12、变更管理
ü 变更的常见原因：
（1）产品范围（成果）定义的过失或者疏忽。
（2）项目范围（工作）定义的过失或者疏忽。
181
（3）增值变更。
（4）应对风险的紧急计划或回避计划。
（5）项目执行过程与项目基准要求不一致带来的被动调整。
（6）外部事件。
ü 变更的程序：
（1）提出与接受变更申请。
变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在
评估前应以书面形式提出。
（2）对变更的初审
变更初审的目的如下：
①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。
②格式校验，完整性较验，确保评估所需信息准备充分。
③在干系人间就提出供评估的变更信息达成共识。
④变更初审的常见方式为变更申请文档的审核流转。
（3）变更方案论证
变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更
请求由技术要求转化为资源需求，以供 CCB 决策。常见的方案内容包括技术评估和经济评估，
前者评估需求如何转化为成果，后者评估价值和风险。
（4）项目变更控制委员会审查
（5）发出变更通知并开始实施
（6）变更实施的监控
（7）变更效果的评估
变更评估可以从以下几个方面进行。
①首要的评估依据，是项目基准。
②还需结合变更的初衷来看，变更所要达到的目的是否已达成。
③评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决。
（8）判断发生变更后的项目是否已纳入正常轨道
有可能的问题
①对用户的要求未进行记录
②对变更的请求未进行足够的分析，也没有获得批准
③在修改的过程中没有注意进行版本管理
④修改完成后未进行验证
⑤修改的内容未和项目干系人进行沟通
导致的后果
①缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的
整体变化情况失去把握
②缺乏对变更请求的分析可能会导致后期的变更工作失误
③在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原；另一方
面，对于组织财富和经验的积累也是不利的
④修改完成后不进行验证则难以确证变更是否正确实现
⑤未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处。
ü 可能案例：
（1）需求不明确的情况下就签订合同，开发过程中开发人员对于变更随便答应。随着项目
进行，变更越来越混乱，导致项目失败。
答题要点：这类题目是变更管理里面的典型题目，总结了一下基本需要答以下几点
①在项目功能和标准不明确的时候就签订了合同，为后来的项目变更埋下了隐患
②没有建立项目变更管理制度(例如：开发人员随口答应，不上报给项目经理)
③作为上点的衍生品，还可以回答，变更请求没有经过评估，没有评估产生的费用和技术
要求，也没有签字确认。
④变更实施时没有考虑对系统其他功能的影响，也没有考虑能否实现。
⑤变更后没有进行验证
⑥没有对变更后的内容进行存档，也没有通知给相关的项目干系人。
13、收尾管理
从历年考试情况来看，收尾管理不是下午考试的重点，但是我还是希望大家能够尽量的认
真掌握如下知识，就比如2013年5月考试的题目，坑了不少的人，哈哈！
ü 通常，系统集成项目的验收工作包括：
（1）系统测试
（2）系统的试运行
（3）系统的文档验收
（4）项目的最终验收报告
ü 项目总结
项目总结属于项目收尾的管理收尾。而管理收尾有时又被称为行政收尾，就是检查项目团
队成员及相关干系人是否按规定履行了所有责任。实施行政结尾过程还包括收集项目记录、分
析项目成败、收集应吸取的教训，以及将项目信息存档供本组织将来使用等活动统一为一个整
体。
ü 项目总结会的内容
总结的内容应包括：项目绩效、技术绩效、成本绩效、进度计划、绩效识别问题和解决问
题意见和建议。
ü 项目总结内容和意义
（1）了解项目全过程的工作情况及相关的团队或成员的绩效状况。
（2）了解出现的问题并进行改进措施总结。
（3）了解项目全过程中出现的值得吸取的经验并进行总结。
（4）对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。
182
183
ü 甲方不验收，一般可以怎么做？
1、请求公司的管理层出面去与甲方协调
2、重新确认需求并获得各方认可
3、和甲方明确合同、以及双方确认的补充协议等，包括修改后的范围、进度和质量方面的
文件等，作为验收标准
4、准备好相应的项目结项文档，向甲方提交
ü 对于系统集成项目，所涉及的文档应该包含如下部分：
（1）系统集成项目介绍（2）系统集成项目最终报告（3）信息系统说明手册（4）信息系
统维护手册（5）软硬件产品说明书、质量保证书等
14、历年中、高级案例分析背景中的明显错误
以下内容是 根据历年中、高级案例分析考题，所摘录的一些明显的错误，以下是一些常
见的问题，有重复的问题，也有少部分问题没有摘录出来（经常重复的没有拿出来，需要通过
大篇幅内容才能体现错误的没有拿出来），希望大家可以认真学习。
（1）因人手比较紧张，M 从正在从事编程工作的高手中选择了小张作为负责软件子项目的
项目经理，小张同时兼任模块的编程工作
（2）该开发人员就直接对系统软件进行了修改
（3）在验收过程中，老刘提出了一些小问题。项目经理张斌带领团队很快妥善解决了这些
问题。但是随着时间的推移，客户的问题似乎不断。时间已超过系统试用期，但是客户仍然提
出一些小问题，而有些问题都是客户方曾经提出过，并实际上已经解决了的问题。
（4）项目经理小丁做过5年的系统分析和设计工作，但这是他第一次担任项目经理。小丁
兼任系统分析工作
（5）因此他要求项目组成员无论如何每周都必须按时参加例会并发言，但对例会具体应如
何进行，老张却不知如何规定。很快项目组成员就开始抱怨例会目的不明，时间太长，效率太
低，缺乏效果等等，而且由于在例会上意见相左，很多组员开始相互争吵，甚至影响到了人际
关系的融洽
（6）在该项目合同中，简单地列出了几条项目承建方应完成的工作，据此小李自己制订了
项目的范围说明书。
（7）合同的相应条款作为依据，而这些条款要么太粗、不够明确
（8）以往项目销售经理的过度承诺给后继的实施工作带来了很大困难
（9）期间项目经理田某因故离职，其工作由系统集成商B的另一位高级项目经理鲍某接替
（10）项目承建单位的一名副总裁承揽了一个新项目，他把程序员、测试工程师从该项目上
调走，去执行他新承揽的项目。
（11）尚存在一些问题，主要有：方案遗漏一项基本需求，有多项无效需求，没有书面的需
求调研报告；在项目的工期、系统功能和售后服务等方面，存在过度承诺现象。
（12）章某建议从在公司工作2年以上业务骨干中选拔项目经理。结果李某被章某选中负责
该项目的软件开发子项目。
（13）他领导的团队因经常返工而效率低下、团队成员对发生的错误互相推诿、开会时人员
从来没有到齐过，甚至李某因忙于自己负责的模块开会时都迟到过。大家向李某汇报项目的实
际进度、成本时往往言过其实，直到李某对自己负责的模块进行接口调试时才发现这些问题。
（14）这次和以往不同的是强某还同时管理着另外两个项目，而这个人口管理系统项目的工
期要求紧、他能调用的人手少。
（15）张工认为此项目质量管理的关键在于系统地进行测试。
（16）新毕业的大学生小吕负责项目的质量保证
（17）而WBS则由小刘自己依据以往的经验进行分解
（18）因为项目的验收日期是合同里规定的，人员是公司配备的，所以进度里程碑计划是从
验收日期倒推到启动日期分阶段制定的。在该项目计划的评审会上，大家是第一次看到该计划，
在改了若干错别字后，就匆忙通过了该计划。该项目计划交到负责质量保证的小吕那里，小吕
看到计划的内容，该填的都填了，格式也符合要求，就签了字。
（19）在需求分析时，他们制作的需求分析报告的内容比合同的技术规格要求更为具体和细
致。小刘把需求文档提交给了甲方联系人审阅，该联系人也没提什么意见。
（20）甚至有关技术指标不符合国家电表标准等等，而此时S公司因内部原因退出中国大陆
市场
（21）由于此客户为 A 公司的重要客户，为维护客户关系，A 公司同意了建设单位的要求。
为了完成项目建设任务，A公司将应用软件分成了多个子系统，并分别组织开发团队突击开发，
为提高效率，尽量采用并行的工作方式，在没有全面完成初步设计的情况下，有些开发组同时
开始详细设计与部分编码工作；同时新招聘了6名应届毕业生加入开发团队。
（22）然后参考项目管理教材和国外一些大型项目管理经验制定了一系列相关规定以及奖惩
措施，针对正在开发的项目分别指定了技术骨干作为项目的项目经理。
（23）认为“公司规模小没有必要进行项目管理”，与其花费了大量时间开会、写文档，不
如几个人碰碰头说说就可以了。实际开发工作中总是以开发任务重等原因不按照规定履行项目
管理程序。
（24）因此决定从公司工作3年以上的业务骨干中选拔一批项目经理。张某原是公司的一名
技术骨干，编程水平很高，在同事中有一定威信，因此被选中直接担当了某系统集成项目的项
目经理。
（25）他领导的小组有 2个新招聘的高校毕业生，技术和经验十分欠缺，一遇到技术难题，
就请张某进行技术指导。有时张某干脆亲自动手编码来解决问题，因为教这些新手如何解决问
题反而更费时间。由于有些组员是张某之前的老同事，在他们没能按计划完成工作时，张某为
了维护同事关系，不好意思当面指出，只好亲自将他们未做完的工作做完或将不合格的地方修
184
改好。该项目的客户方是某政府行政管理部门，客户代表是该部门的主任，和公司老总的关系
很好。因此对于客户方提出的各种要求，张某和组内的技术人员基本全盘接受，生怕得罪了客
户，进而影响公司老总对自己能力的看法。张某在项目中遇到的各种问题和困惑，也感觉无处
倾诉。项目的进度已经严重滞后，而客户的新需求不断增加，各种问题纷至沓来，张某觉得项
目上的各种压力都集中在他一个人身上，而项目组的其他成员没有一个人能帮上忙。
（26）王某认为这是正常的项目团队磨合过程，没有过多干预。同时，批评新加入成员效率
低下，认为项目团队原成员更有经验，要求新加入成员要多向原成员虚心请教。项目实施两个
月后，王某发现大家汇报项目的进度言过其实，进度没有达到计划目标。
（27）小方根据在学校学习的项目管理知识，制定并发布了项目章程。因工期紧，小方仅确
定了项目负责人、组织结构、概要的里程碑计划和大致的预算，便组织相关人员开始各个网站
的开发工作。
（28）项目经理召开项目组内部会议将任务口头布置给了小组成员。会后，主要由编码人员
按照会议备忘录的要求对已完成的模块编码进行修改，而未完成的模块按照会议备忘录的要求
进行编写。
（29）需求分析完成后，项目组编写了《需求分析报告》。项目经理小赵召集部分骨干人员
召开评审会，对需求文件进行了评审。为了尽快进入下一阶段工作，评审会从早上 9点一直开
到晚上 9 点，终于把全部文件都审完了。评审组找到了几处小问题，并当场进行了修改，项目
经理宣布可以进入设计阶段了。
设计人员根据需求文件编写了《设计说明书》，并提交给小赵。小赵对设计文件仔细审阅后，
便安排程序员开始编程。
（30）由于该高校是公司重要的客户，A公司领导口头答应了客户的要求。
（31）李某凭借自己项目管理的经验，认为这些变更在约定的工期内可以完成，因此直接答
应了对方的变更要求，随后，李某找到负责变更模块的项目组成员，要求其完成对业务流程变
更的修改。
（32）临近外包交工时，对方提出人力资源紧张，要求延长合同期限，如果延长外包期限，
将导致无线抄表系统项目进度无法完成，公司将承受很大的损失。
（33）小王在初步了解了这个项目的基本情况之后，就按照公司的模板与项目组的几个核心
成员共同制订了项目管理计划。
（34）考虑到刘某第一次管理这种商业性项目，因此对很多管理细节都进行了细化，并将计
划重点集中在项目执行计划的制订方面，配置管理计划做得比较简单
（35）项目经理经过与项目组及项目管理部协商，决定去掉详细设计这个环节，直接进入产
品的编码阶段，安排开发工程师根据总体设计负责各自模块的开发工作。
（36）5名开发工程师组成的开发小组进入非常忙碌的编码阶段后，经常加班加点。开发过
程中，由于原来制定的计划已完全被打乱，SQA 无法再根据原来的质量保证计划进行跟踪，项
目组其他人员也已无法发挥作用。
185
186
（37）这时已有2名开发人员因为信心问题而离职，项目经理除了要考虑项目进度外，还要
考虑项目资源，由于此时其他项目任务也很重，公司资源很紧张，他不得不重新招聘开发人员。
（38）小赵被任命为某软件开发项目的专职质量管理人员，他此前只有过三个月的软件开发
经历。
（39）项目经理李工决定调整计划，不划分测试阶段，将所有模块一次集成后统一开始测试。
（40）由于模块由不同人员开发，需要不同的人来修改，常常是已修复的BUG，在修复其他
的BUG之后又再次出现，开发人员不停修改
（41）质量部便借鉴了其它公司的体系文件，对其简单修改后形成了A公司的质量管理体系
文件。
（42）鉴于项目已经完成了试运行，李工就组织大家召开了项目总结会。在总结会上李工表
示了对大家的感谢，然后就宣布项目已经结束，项目团队成员可以各自按照原先的人力资源计
划进入新的项目。
（43）项目小组在 2009 年 1 月 20 日前完成任务，1 月 21 日至 28 日各模块联调，1 月 29
日至31日机动。
（44）小李随后在原道路监控项目解决方案的基础上组织制定了智能交通管理系统项目的技
术方案。
（45）为了赶工期项目组省掉了一些环节和工作，虽然最后通过验收，但却给后续的售后服
务带来很大的麻烦：为了解决项目网络出现的问题，售后服务部的技术人员要到现场逐个环节
查遍网络，绘出网络的实际连接图才能找到问题的所在。售后服务部感到对系统进行支持有帮
助的资料就只有政府网站的网页HTML文档及其内嵌代码。
（46）H公司同甲方关系比较密切，但也正因为如此，合同签的较为简单，项目执行较为随
意。
（47）小赵是一位优秀的软件设计师，负责过多项系统集成项目的应用开发，现在公司因人
手紧张，让他作为项目经理独自管理一个类似的项目
（48）李工按照4个月的工期重新制定了项目计划，向公司申请尽量多增派开发人员，并要
求所有的开发人员加班加点工作以便向前赶进度。由于公司有多个项目并行实施，给李工增派
的开发人员都是刚招进公司的新人。为节省时间，李工还决定项目组取消每日例会，改为每周
例会。同时，李工还允许需求调研和方案设计部分重叠进行，允许需求未经确认即可进行方案
设计。
（49）张工在担任此新项目的项目经理同时，所负责的原项目尚处在收尾阶段。张工在进行
了认真分析后，认为新项目刚刚开始，处于需求分析阶段，而原项目尚有某些重要工作需要完
成，因此张工将新项目需求分析阶段的质量控制工作全权委托给了软件质量保证（SQA）人员李
工。李工制定了本项目的质量计划，包括收集资料、编制分质量计划、并通过相应的工具和技
术，形成了项目质量计划书，并按照质量计划书开展相关需求调研和分析阶段的质量控制工作。
（50）某网络建设项目在商务谈判阶段，建设方和承建方鉴于以前有过合作经历,并且在合
同谈判阶段双方都认为理解了对方的意图，因此签订的合同只简单规定了项目建设内容、项目
金额、付款方式和交工时间。
（51）王某是某管理平台开发项目的项目经理。王某在项目启动阶段确定了项目组的成员，
并任命程序员李工兼任质量保证人员。李工认为项目工期较长，因此将项目的质量检查时间定
为每月1次。
（52）李工对这个开发人员开具了不符合项报告，但开发人员认为并不是自己的问题，而且
修改代码会影响项目进度，双方一直未达成一致，因此代码也没有修改。
（53）老陆是某系统集成公司资深项目经理，在项目建设初期带领项目团队确定了项目范围。
后因工作安排太忙，无瑕顾及本项目，于是他要求：
①本项目各小组组长分别制定组成项目管理计划的子计划；
②本项目各小组组长各自监督其团队成员在整个项目建设过程中子计划的执行情况；
③项目组成员坚决执行子计划，且原则上不允许修改。
（54）在编码阶段，赵工发现需求文件还在不断修改，形成了多个版本，设计文件不知道该
与哪一版本的需求文件对应，而代码更不知道对应哪一版本的需求和设计文件。同时，客户仍
在不断提出新的需求，有些很细微的修改，开发人员随手就改掉了。
（55）小刘经过详细的需求调研，开始着手制定项目计划，在此过程中，他仔细考虑了项目
中可能遇到的风险，整理出一张风险列表。
（56）项目管理计划制定完成后，小刘通知了项目组成员，召开了第一次项目会议，将任务
布置给大家。随后，大家按分配给自己的任务开展了工作。
（57）某公司的质量管理体系中的配置管理程序文件中有如下规定：
①由变更控制委员会（CCB）制定项目的配置管理计划；
②由配置管理员（CMO）创建配置管理环境；
③由CCB审核变更计划；
④项目中配置基线的变更经过变更申请、变更评估、变更实施后便可发布；
⑤CCB组成人员不少于一人，主席由项目经理担任。
（58）为了节约时间，小陈根据自己在沟通会议上记录的结果，当晚组织相关人员撰写了软
件需求规格说明。次日便要求设计人员开始进行系统设计，并指出项目组成员必须严格按照进
度计划执行，以不辜负领导的期望与嘱托。
（59）项目进行到2月底时，校方主管此业务的新领导到任，并提出了新的信息化管理要求。
小陈进行变更代价分析，认为成本超支严重，于是小陈准备不进行范围变更，并将结果通知客
户，引起客户不满。
（60）近期，该公司承担了某自然灾害预警系统项目，由于项目时间紧张，上线任务迫切，
经过管理层讨论，决定临时简化流程，在开发阶段集中对质量进行把关。由于以前做过类似的
项目，为了节约时间，项目经理带领团队套用原有成功项目的需求和设计思路，对历史项目的
相关文档进行修改后，立即进入编码阶段。编码完成后，为争取系统提前交付，匆忙进行测试，
187
并上线试运行。
（61）项目组准备了详尽的测试用例，会同业主共同进行系统测试，测试过程中为了节约时
间，小张指派项目开发人员小李从测试用例中挑选了部分合理、有效的数据进行测试，保证系
统正常运行。
（62）项目组将业主的数据和设置加载到系统中进行正常操作，完成了试运行工作。
（63）经初步调研，杨某发现该项目进度紧、任务重、用户需求模糊，可能存在较大风险。
但B 公司领导认为应该先签下该项目，其他问题在项目实施中再想办法结局。A、B双方很快签
订了一份总价合同。在合同中，根据赵某提供的初步需求说明，简单列出了系统应完成的各项
功能和性能指标。杨某根据合同制定了项目的范围说明书。
（64）杨某将上述情况汇报给了B 公司主管领导，主管领导认为A单位为公司客户，非常重
要，要求杨某利用合同条款的模糊性，简化部分模块的功能实现，以保持成本和进度不变。
（65）小李为项目制定了整体进度计划，将项目分为需求、设计、实施和上线试运行四个阶
段，项目开始后，张工凭借其丰富的经验使开发过程得到了很好的质量保证，需求和设计顺利
通过了张工的把关。
（66）A公司同时进行的信息系统开发项目比较多，李工在完成生产过程管理信息系统的需
求说明书后，转到了另外的项目开发组。在赵工带领开发小组进行设计与编码的过程中，客户
经常提出一些小的改动，赵工认为满足客户的需求是很重要的，所以，能改的就改了，没有与
A公司的其他人进行协商。
（67）由于技术人员有限，为保证各个项目的进展，人员在项目间的兼职与交叉很严重。一
个技术开发人员在M项目上工作2天后，很可能转入Y项目工作，过了3 天，再转回 M项目工
作。项目的文档一般采用各自的命名方式进行管理，客户提出的修改也各自负责，在技术开发
人员的本地机上进行了开发。
（68）接到任务后，项目经理小王开始着手编制项目管理计划，根据招标文件，小王列出了
一个初步的进度计划，进度计划中的各里程碑点正好是甲方招标文件中规定的各时间节点。随
后，小王估计了项目的各项开销，确定了项目预算。
（69）为了赶工，就对项目开发人员再发工，将试运行的系统版本作为原始版本，在些基础
上开始并行为其他委办局定制开发各自的政务信息资源整合系统。试运行的版本在运行中根据
用户的要求，产生了一些功能的变动，开发人员改动代码，这些改动后的代码有的适合其他委
办局，有的不适合；而在为其他委办局开发中，也在根据用户的要求进行各自代码的修改。项
目进展得很顺利，期间，主要开发人员小王和小李因故提出辞职，刘经理向公司申请补充开发
人员接替小王和小李的工作，然而由于之前的变更没有相关文档的记录，开发版本与设计和需
求的版本对应不上。
（70）鉴于项目规模较小，而且已经获得了总经理的支持，因此项目经理李某觉得没有必要
进行项目的可行性研究，只是组织业内的几个专家，根据他自己对项目的描述做了简单的评审，
专家也没有对该项目提出太多的异议。但是在项目的实施阶段，问题却层出不穷。首先是，项
188
目团队发现有新的、更简单易行的技术方案可以实现项目的目标；其次是与销售部门会议后，
销售部门的人反映目前开发的产品不是他们需要的产品；更麻烦的是，相关政府部门出台政策，
为了稳定市场秩序，限制了该类产品的市场销售。
（71）S公司是某市一家从事电子政务应用系统研发的系统集成公司，公司总经理原为该市
市政府信息中心总工程师。S 公司最近承接了该市政府 X 部门的一个软件项目，而 X 部门一直
是 S 公司的老客户。因为当时公司总经量急于出差，所以在系统范围界定和验收标准并不十分
明确的情况下，就和客户签订了合同，并任命李工为该项目的项目经理。
（72）随着项目的逐步开展，客户方不断提出一些变更要求，项目组起初严格按照变更管理
流程进行处理，但是由于S公司与X部门比较熟悉，且胡某强调这些变更都是必需的业务要求，
因此几乎所有变更都被批准和接受。
（73）李工要求项目组天天加班以保证进度，但需求变更似乎没完没了。为了节省时间，客
户的业务人员不再正式提交变更申请，而是直接和程序员商量，程序员也往往直接修改代码而
来不及做相关文档记录。对此李工也很无奈。
（74）此时有一个项目A的项目经理告知小张，发现基线库中有一个重要的功能缺陷要修改,
项目经理组织配置控制委员会进行了分析讨论后，同意修改，并指派了程序员小王进行修改，
于是小张按照项目经理的要求在受控库中增加了小王的修改权，以便小王可以在受控库中直接
修改该功能。
（75）项目经理认为，公司的控制系统软件是比较成熟的产品，虽然需要按项目需要进行二
次开发，但应该能够提前完成，但列车控制设备需要协调外包生产，比原计划提前 2个月没有
把握，公司领导认为，从铁路行业的项目特点来考虑，提前开始铁路是必须完成的任务，因此
客户的要求不能拒绝。于是他要求项目经理无论如何也要想办法满足客户提出的提前交付的需
求。
（76）该企业已按照 ISO9001 的要求建立了一套质量管理体系，对于项目管理、软件开发等
的流程均有明确的书面规定。但公司中很多人认为这套管理体系的要求对于项目来说是多余的，
条条框框的约束太多，大部分项目经理都是在项目结项前才把质量体系要求的文档补齐以便能
通过结项审批。公司的质量管理员也习以为常，只要在项目结束前能把文档补齐，就不会干涉
项目建设。
（77）老李组织了技术骨干对客户的需求进行了调研，通过对用户需求的分析和整理，项目
组直接制定了一个总体的技术方案，然后老李制定了一个较粗略的项目计划：
（78）在软件与采集设备的联调过程中，老李请环保局的客户代表来检查工作。客户代表发
现由于项目组不了解环保领域的一些参数指标，完成的系统达不到客户方的要求。由于项目从
一开始就没有完整的项目文档，老张为了避免再出现重大问题，只好重新进行需求调研。客户
方很不满意，既担心项目不能按时上线又担心项目质量无法保证。
（78）张工按照项目内容，将项目分成子项目 1、子项目 2 和子项目 3，分别任命李工、王
工和廖工负责。三个项目在张工的领导及协调下进展顺利。在整个项目进行到 80%时，出资人
189
提出子项目 1 由于政策原因需要终止，子项目 2、子项目 3 继续按照原计划进行。因此张工通
知李工将子项目 1 资料归档并提交给公司管理资产的人员。随后为了保证子项目 2、子项目 3
的顺利进行，张工将子项目1的项目团队解散，有关员工加入到子项目2、子项目3中。
子项目2、子项目3在张工引入新的资源后，进展顺利，因此张工觉得不需要再加强阶段审
查，等项目全部完成后再统一进行验收。
在项目结束后，张工组织客户对子项目2、子项目3分别进行验收，结果客户对子项目2的
成果很不满意。因子项目3 需要的一个关键部件是子项目2 提供的，最后影响了二者的总体验
收，项目因此没有按时交工。
（79）项目启动时，乙公司领导安排王工担任此项目的项目经理，王工自己按照公司项目章
程模板撰写项目章程，进入了下一个过程，新撰写的项目章程内容包括：质量控制人员、项目
组织结构、项目基本需求、项目完工日期。
同时为了保证项目质量，王工亲自撰写了初步的项目范围说明书。王工依照以前公司的经验
撰写的初步的项目范围说明书内容包括：项目概述、产品要求、项目完工日期、项目约定条件、
初始风险。初步的项目范围说明书撰写完成后，王工通知了项目组成员，按照初步的项目范围
说明书开始工作，项目组成员有人认为初步范围说明书内容太过简单，跟以往项目范围说明书
差别太大，但担心项目经理不高兴，也没有直接说。
（80）刚进入项目规划阶段，发生的几个事件让王工觉得非常棘手：
①项目组成员就系统是否包含数据库导出、备份功能产生了分歧，查看初步的项目范围说明
书发现也没有相应描述。②有项目组成员认为初步的项目范围说明书中给出的系统安全等级过
高，实现难度非常大，还可能导致项目成本大幅度增加③项目组成员不确定项目验收时是否要
给客户交付《产品使用手册》，有成员建议既然不确定就不要做了，这样可以节约成本。④在初
步的项目范围说明书中没有涉及到项目的质量管理要求，乙公司内部的质量技术部因此没有安
排专门的人员配合王工工作。⑤一些项目组成员经常抱怨王工大包大揽，项目启动阶段的工作
不严格遵照公司管理流程执行，也未征求其他项目组成员的意见和建议。
（81）甲公司是一家通信技术运营公司。经公司战略规划部开会讨论，决定开发新一代通信
管理支持系统，以提升现有系统综合性能，满足未来几年通信业务高速发展需要。战略规划部
按照以下步骤启动该项目：
①起草立项申请，报公司总经理批准。
②总经理批准后，战略规划部开展了初步的项目可行性研究工作，主要从国家政策导向、市
场现状、成本估算等方面进行了粗略的调研。
③战略规划部依据初步的项目可行性研究报告，认为该项目符合国家政策导向，肯定要上马。
公司立即成立了建设方项目工作小组，计划以公开招标的方式选择承建方。
（82）乙公司成立时间不足两年，研发队伍能力较强，也有为其它通信技术公司开发过软件
产品的经验。乙公司得知甲公司的招标信息后，马上组织人员开始投标工作。该项目的投标工
作由软件研发部的郑工负责。郑工是公司的软件工程师，具有丰富的软件代码编写经验。郑工
190
从技术角度分析认为项目可行，独立编制完成了投标文件。
（83）某信息系统开发公司承担了某企业的ERP系统开发项目，由项目经理老杨带领着一支
6 人的技术团队负责开发。由于工期短、任务重，老杨向公司申请增加人员，公司招聘了 2 名
应届大学毕业生小陈和小王补充到该团队中。老杨安排编程能力强的小陈与技术骨干老张共同
开发某些程序模块，而安排编程技术弱的小王负责版本控制工作。在项目开发初期，小陈由于
不熟悉企业的业务需求，需要经常更改他和老张共同编写的源代码文件，但是他不知道哪个是
最新版本，也不知道老张最近改动了哪些地方。一次由于小王的计算机中了病毒，造成部分程
序和文档丢失，项目组不得不连续一周加班进行重新返工。此后，老杨吸取教训，要求小王每
天下班前把所有最新版本程序和文档备份到 2 台不同的服务器上。一段时间后，项目组在模块
联调时发现一个基础功能模块存在重大 BUG，需要调取之前的备份进行重新开发。可是小王发
现，这样一来，这个备份版本之后的所有备份版本要么失去意义，要么就必须全部进行相应的
修改。项目工期过半，团队中的小李突然离职，老杨在他走后发现找不到小李所负责模块的最
新版本源代码了．只好安排其他人员对该模块进行重新开发。
(84) 项目进入编码阶段后，承办单位为了扩大影响力，要求在项目中增加全国服装模特海
选的宣传、选拔、评奖与管理。因此，建设方代表直接找到小曹提出增加项目内容，并答应会
支付相应的费用，但要确保项目工期不能拖延。
（1）小曹见到其领导时转述了建设方的要求;
（2）领导考虑了一会儿，对小曹说“答应客户要求”，
（ 3 ）小曹通知商务人员与建设方签订补充协议，
（4）因建设单位要求工期不能拖延，故小曹决定项目进度计划不变;
（5）小曹找来设计工程师小廖，把新增部分全权委托给了他，让他加班加点确保进度。
交付期至时，项目集成测试中发现的问题还未得到及时解决。
(85) 信息系统集成公司 A（以下简称 A 公司）于 2012 年 5 月承接了某市级银行的计费
数据库系统开发项目，约定在该银行十三个本地网点计费系统建设中提供硬件平台及相应软件
产品，并由 A 公司负责系统总集成，以及后期相关的运维工作。由于感觉技术比较单一，因此
签订了总价合同，合同中只是简单规定了技术总体要求，并约定依据项目的大致进展进行付款。
（86）1、张经理认为做好运维的核心是运维人员的维修水平。由于运维合同价格偏低，在
招聘人员时主要考虑人员是否有相关设备维修经验，并指派本公司有系统集成实施经验的若干
名人员加入运维团队，要求团队成员满负荷工作，项目组人员不能有冗余。
2、在运维项目实施期间，遇到值班人员有事或生病，只能由项目经理代班，遇到客户报修
的设备问题，维修人员常常以我不懂该专业，让客户第二天再报。运维人员遇到无法解决的技
术问题向项目经理汇报时，项目经理回答“你们招进来就是解决设备问题的，我无法提供帮助，
你们自己解决”相关运维人员经常超过规定时间，也未能使设备恢复运行。
3、项目经理认为团队管理的核心是团队凝聚力强，不发生冲突。项目经理利用工作和业务
时间进行了大量的沟通和协调工作。确保在运维实施期间，成员关系比较融治。但在季末法院
191
信息中心进行的服务满意度调查时，综合满意度只有 70%,设施综合可用性指标只达到98%。
（87）某石化行业的信息化项目是一个大型项目，前期投标竞争非常激烈，甲公司最终中标。
合同谈判过程也比较紧张，客户提出的一些要求，如工期和某些增加的功能，虽然在公司内部
讨论时，认为并没有把握按要求完成，但是为了赢得这个项目，甲公司在谈合同时未提出异议。
由于项目工期紧张，甲公司选择了项目经理老李负责该项目。原因是老李在甲公司多年一直
从事石化行业的项目咨询、设计、开发，对行业非常熟悉，技术水平高。而近一年来，他正努
力转型做项目经理，管理并负责完成了2个较小规模的项目。
老李带领项目组根据客户要求的工期制定了项目计划，但项目执行到第一阶段，就未按计划
进度完成。由于项目刚开始，老李怕客户有意见终止合同，因此决定不把实际情况告知客户，
打算在后面的工作中加班加点把进度追回来。
接下来，项目组在解决客户谈判过程中增加的功能需求的时候，遇到了一个技术问题，老李
带领项目组加班进行技术攻关，耗费了几周的时间，终于解决了技术问题。但此时项目进度延
误得更多了。
甲公司已建立项目管理体系，该项目的 QA 本应该执照甲公司要求对项目过程进行检查，但
老李认为过程的检查会影响到项目组的工期，要求QA在项目阶段未再进行检查。
时间已经超过工期的一半，客户到甲公司检查项目工作，发现项目进度严重滞后，并且已经
完成的部分也未能达到质量要求。
（88）项目前期，A公司请王副总经理负责此项目的启动工作。王副总经理简单了解项目的
概要情况后制定并发布了项目章程，任命小丁为项目经理。项目团队根据分工制定了相应的项
目管理子计划。据此，项目经理小丁把各个子计划归并为项目管理计划。
（89）为了保证项目按客户要求尽快完成，小丁基于自身的行业经验和对客户需求的初步了
解，即安排项目团队开始进行项目实施，在系统开发过程中，建设方提出的建设需求不断变化，
小丁本着客户至上的原则，总是安排项目组进行修改，从而导致开发工作多次反复。而因为项
目计划的多次变化，导致项目团队的成员也经历过多次调整，实际进度与里程碑计划存在严重
偏离，实际进度与里程碑计划存在严重偏离，并且项目的质量指标也经常也暴露出问题。
(90) 在某市的政府采购中，系统集成公司甲中标了市政府部门乙的信息化项目。经过合同
谈判，双方签订了建设合同，合同总金额为1150万元，建设内容包括：搭建政府办公网络平台，
改造中心机房，并采购所需的软硬件设备。
甲公司为了更好地履行合同要求，将中心机房的电力改造工程分包给专业施工单位丙公司，
并与其签订分包合同。
在项目实施了 2 个星期后，由于政府部门乙提出了新的业务需求，决定将一个机房分拆为
两个，因此需要增加部分网络交换设备。乙参照原合同，委托甲公司采购相同型号的网络交换
设备，金额为127万元，双方签订了补充协议。
(91) 张工首先仔细阅读了项目招标文件、报标书及相应的合同文件，然后指派了王工为需
求管理人员负责进行需求梳理、需求分析并编写需求说明书。王工为此制定了详细的需求调研
192
计划，其中调研对象包含甲方的医生、护士、信息科主任。在充分调研后，王工编写了需求说
明书提交给了张工，张工组织项目组成员进行了需求评审，评审通过后，项目依据项目计划开
始实施并顺利进行到了2014 年6月份。此时，王工收到甲方的通知，由于政策变动，医保接口
需要修改，否则无法进行医保结算。张工重新更新了项目计划，将研发完成时间调整到 2015
年1月中旬进行试运行
同时王工重新修改了需求规格说明书。项目按照新计划及需求继续进行到 2014年底，公司
考核项目完成情况时发现项目未能按计划时间完成，所以扣除了张工的项目奖。
(92) 在某系统集成项目收尾的时候，项目经理小张和他的团队完成了以下工作：
工作一：系统测试。项目组准备了详尽的测试用例，会同业主其同进行系统测试。测试过
程中为了节约时间，小张指派项目开发人员小李从测试用例中挑选了部分数据进行测试，保证
系统正常运行。
工作二：试运行。项目组将业主的数据和设置加载到系统中进行正常操作，完成了试运行
工作。
工作三：文档移交。小张准备了项目最终报告、项目介绍、说明手册、维护手册、软硬件
说明书、质量保证书等文档资料直接发送结业主。
工作四：项目验收。经过业主验收后，小张派小李撰写了项目验收报告，并发送给双方工
作主管。
工作五：准备总结会。小张总结了项目过程文档以及项目组各技术人员的经验，并列出了
项目执行过程中的若干优点。
工作六：召开总结会。小张召集参与项目的一些人员参加了总结会，并就相关内容进行了
讨论，形成了总结报告。
(93)某信息系统集成公司决定采用项目管理办公室这样的组织形式来管理公司的所有项目，
并任命了公司办公室主任王某来兼任项目管理办公室主任这一职务。鉴于目前公司项目管理制
度混乱。各项目经理都是依照自己的经验来制定项目管理计划，存在计划制定不科学、不统一
等情况，王某决定从培训入手来统一和改善公司项目管理计划的制定过程，并责成项目管理办
公室的小张具体负责相关培训内容的组织。
小张接到任务后，仔细学习了项目管理的相关知识，并请教了专业人士。小张觉得项目管
理体系结构中，主要由输入、工具和技术、以及输出组成。于是也按照项目管理编制计划的输
入、项目管理编制计划的工具和技术，以及项目管理计划的输出内容三个方面来组织项目管理
计划培训的相关课程内容。
但是在准备进一步的内容时，小张觉得目前公司的项目五花八门，有研发项目、系统集成
项目、运维项目和纯粹的软件开发项目，还有部分弱电工程项目，既有规模大的项目，也有一
些小项目，是不是能够用统一的标准来要求所有的项目管理计划规范制定过程？小张觉得很怀
疑。
(94) 某公司2014年初承接了一个周期为一年的OA信息系统项目，并指派项目经理小张负
193
责。该项目属于定制型项目，涉及的用户方较多，小张根据自己的经验预测到项目可能会涉及
频繁的需求变更，因此小张在将项目组分成了业务组、实施组、开发组后，定义了如下需求管
理及控制流程：
（1）指派专门的业务组进行需求分析，分析完成后马上与用户进行需求确认，确认后填写
需求状态表（包括需求提交日期、需求状态、是否属于变更等）；
（2）实施组获得需求分析文档后，一周内进行技术方案设计；
（3）技术方案完成后，业务组视情况与用户进行二次沟通确认，确认后填写需求状态表（包
括需求技术方案提交日期、需求技术方案状态）；
（4）需求分析、技术方案完成后，开发组每周对已确定需求进行工作量评估，形成月度开
发计划；
（5）开发组根据开发计划进行定制开发工作；
（6）每周开发组根据需求状态库的需求、方案进行工作量重新评估，更新开发计划
(95)某信息系统集成企业承担了甲方的信息系统集成项目，在项目的采购过程中，某项采
购合同是在甲方的授意下签订的，然而在项目进展过程中，项目经理发现该采购产品高于市场
价格，而且有些性能指标也没有能够完全满足合同规定要求。当项目经理发现此类问题进行调
查时，发现该供应商的资质和声誉都存在问题，并且就在不久前已经被其他公司并购，最麻烦
的是合同的付款条件是提前支付相关款项，合同的大部分采购款已经支付。
(96)在项目的中期验收中，甲方发现了部分采购产品存在的问题，并要求项目组进行返工
和更换相关产品。项目经理则以采购供应商是由甲方推荐为由，拒绝进行返工和更换。而甲方
则认为，项目合同里面并没有规定由甲方承担采购责任，甲方只是为项目组推荐了部分供应商，
而供应商以被收购，原先的公司已经不存在，原先的责任人已经离职为由，拒绝根据合同相关
条款更换产品，项目经理对此束手无策。
(97)项目经理小王目前正在负责一个小型的软件开发项目。—开始他觉得项目比较小，变
更应该不多，流程也不需要太复杂，因此就没有制定项目变更管理计划，而是强调团队成员间
的及时沟通来保证项目按照计划进行。根据项目经理小王的理解，所谓变更管理的主要目标就
是保证项目能够按照计划进行，如果能够保证不发生超越项目进度计划、成本计划等控制范围
外的偏差，就可以不用指定项目变更管理计划，以减少项目的工作量。而项目执行过程中对计
划的微调根本不需要记录和管理，也不需要走项目变更管理流程。而且他认为如果所有项目变
更都必简要向相关领导请示汇报，过程太复杂和麻烦，还不如由执行人员提出变更的方案，彼
此讨论一致后来的更方便和快捷。
(98)但是在项目进入集成测试阶段的时候，突然多了很多莫名其妙的问题出现。如在调试
过程中。由于相关设计和记录的简化和不规范，造成了调试的困难，很难定位各个问题模块的
错误；由于项目执行过程中。人员的调配替换，造成了文档记录的不—敢，导致后期人员阅读
和理解方面的障碍。并且由于缺乏对开发过程的配置管理和控制，导致版本混乱，很难形成有
效支持各模块集成的文档。另外，面目中很多细小的改动由于没有准确的记录，或者是根本没
194
有记录．导致集成测试发现问题时，根本没有办法更改。
(99)李工被临时任命为该项目的项目经理，直接归公司负责营销的王总领导。王总让公司
人力资源部门准备了项目章程，通知财务部、人力资源部和销售部的相关人员一起召开了项目
启动会，并在会议上正式发布了项目章程和对项目经理的任命。项目章程中包括了项目团队成
员、项目的历时、项目经理的权限、项目的预算等内容。
(100)李工在项目执行过程中，发现项目章程中没有任何对于项目风险和开发模型的说明与
规定，所以李工就根据自身经验采用了瀑布模型来安排项目工作。当项目进展到2015年 12月
时，发现4G的普及率没有达70%，公司决定暂缓此项目。但是到此时为止，项目已经进展到了
差不多一半，而且项目也不能够分阶段进行开发，否则将前功尽弃。当公司质量管理部门追究
相关环节的错误时，李工觉得这样的风险不属于项目层面风险管理的内容，作为项目经理只要
按照项目章程的规定执行项目就是尽责了。
(101)小周曾担任过多个应用软件开发项目的项目经理，但没有负责过硬件集成项目。
(102)小周组织召开了项目启动会，将项目进行了分解，并给项目组成员分配了任务。接下
来，安排负责技术的小组长先编写项目技术方案，同时小周根据合同中规定的时间编制了项目
的进度计划并发送给项目组成员。进度计划中确定了几个里程碑点：完成技术方案、设备到货、
安装调试完成、应用系统迁移完成。由于该项目需要采购多种硬件设备，小周将进度计划也发
给了采购部经理，并与采购部经理进行了电话沟通。
技术方案完成后通过了项目组的内部评审，随后项目组按照技术方案开始进行设备调试前
的准备工作。
(103)乙公司派出项目经理小李带领项目组进驻甲单位现场，小李首先与客户沟通了需求，
确定了大致的需求要点，形成了一份需求文件，经过客户确认后，小李就安排项目组成员开始
进行开发工作，为了更好的把握需求的实现，小李在每天工作结束后，都将工作进度和成果汇
报给甲方的客户代表，由客户提出意见，并形成一份备忘录。客户对软件的修改意见不断提出，
小李也仔细地将修改意见记录在每天的备忘录中，并在第二天与项目组讨论之后，安排开发人
员尽量实现，随着软件的逐渐成型，小李发现此时客户提出了一些需求实际上跟某些已实现的
需求是矛盾的，对于有些新的需求，实现难度也越来越大，此时软件的实际功能与最初确定的
需求文件中确定的功能已经相差很远，眼看时间越来越接近年底，小李不知道该怎么办才好。
(104)某公司承接了某银行的信息系统集成项目，并任命王工为项目经理。这也是王工第一
次担任项目经理，王工带领近20人的人团队，历经近 11 个月的时间，终于完成了系统建设工
作，并通过了试运行测试，王工在与甲方项目负责人简单地对接了项目交付清单之后，就报告
公司项已经结束，部分项目人员可以进行转移。王工组织剩下的项目团队成员召开了项目总结
会议。随后公司的财务要求王工根据合同催甲方支付剩余30%的项目款。
当王工打电话催促甲方支付项目尾款时。甲方的项目经理告诉他项目还没有结束，甲方还
没有在验收报告上签字确认，项目的很多常规性文件还没有提交，而且需要在试运行的基础上，
进一步修改程序和功能设置，现在根本没有达到项目收尾的条件。
195
(105)某大型国有企业 A计划建立一套生产自动控制系统，改变目前的半自动化生产状态。
A 企业内部设立有信息中心，具有自主开发能力，但采购部门经理老李认为自主开发耗时长，
还是决定从外部选择一家具有相关成熟产品和实施经验的集成商实施外包。
老李组织编写了采购计划，确定该项目要对外进行招标，由于招标代理机构B 已经与 A企
业合作多次，并列入了A企业的供应商名录，因此A企业直接委托B机构开始招标工作。
招标代理机构B 协助A 企业拟制了招标文件，并在互联网上发布了招标公告。招标文件中
要求，潜在供方应具有信息系统集成二级（及其以上）资质。集成商 C 公司想参加投标，但只
具有信息系统集成三级资质，C 公司联合了有信息系统集成二级资质的集成商 D 公司共同参加
投标。在投标截止时间前一周。A 企业发现招标文件中有一处错误，他们对招标文件进行了修
改并在网上进行了公告，还电话通知了每一个已知的投标人。
代理机构B接收了多份标书，与A 企业共同对标书中涉及的技术方案、报价、资质证明材
料等文件进行了评审，最终选择了一家报价最低的集成商E公司。
接下来，A 企业与集成商 E 公司签订了合同。在项目需求阶段，双方对于需求的理解产生
了不一致。为消除需求的歧义，双方召开了多次会议进行沟通。同时，在项目实施过程中，由
于集成商E公司没有此类软件开发的经验，部分开发模块需要外购，因此导致项目的进度延后。
(106)鉴于配置管理在信息系统集成和 IT 运维项目中的重要作用，某企业计划在企业层面
统一建立配置库，以规范公司的配置管理，并责成公司的商务经理杨工兼任公司的配置经理，
全面组织和协调公司的配置管理事项。杨工接到任务后，按照公司目前系统集成和运维的架构，
将配置库分为系统集成项目配置库和运维项目配置库，不过这种配置库管理只是从名称方面进
行了区分，实际上只有一个配置库。由于公司大部分运维项目来自于公司的系统集成部，所以
底层数据是共享的，没有分割开来，运维人员和系统集成人员经常针对同一个配置项进行修改。
在配置库运行4个月之后，公司组织了一次对配置库的审计，发现配置库存在大量的问题，
杨工面对这样的局面，对自己在配置管理中的角色也感到非常迷茫。他收集了目前公司配置库
管理方面存在的问题，这些问题比较突出地体系在以下几个方面：
（1）有的项目组将配置项细化到了软件产品的模块，而有的项目组以项目简单为由，根本
没有进行配置管理，并且各项目组内部对配置管理的需求也不统一，随时间变化波动较大。
（2）很多开发人员和运维人员不知道在不同的库里应该放置什么内容，而且各种配置项的
配置格式也不同意，导致配置库难以达到预期的效果。
（3）配置库增删比较混乱，很多配置项还找不到最后的版本，而且很多配置内容也放置混
乱，各种库的分割管理起不到预期的效果。
(107)A公司属于创业型公司，随着公司业务规模的扩大，公司领导决定成立专门的质量管
理部门，全面负责公司所有项目的质量，并降低产品的缺陷率。公司还聘任了具有多年质量管
理经验的张工担任公司质量管理部门的经理。
张经理上任后，从每个项目组中抽调了一名 QA，QA隶属于公司质量部，工作地点在各个项
目所在地点，与项目组一起工作，负责所在项目的质量管理。小王是X项目的QA，当前X项目
196
正在研发阶段。张经理要求小王按照项目进度提交一份项目质量管理计划，并提供了常规质量
管理计划的模板，主要包括质量检查点、检查人、检查内容、检查时间、检查方式等。小王于
是按照张经理的要求编写并提交了《项目质量管理计划-X项目》。
过了 2 个月，张经理根据质量管理计划的某一个时间点，询问小王某一个设计评审的会议
情况时，小王没有找到有关的会议记录。张经理又电话询问 X 项目的项目经理有关质量管理的
情况，该项目经理认为质量管理是由小王根据质量管理部门的要求进行的，自己会大力配合。
（108）小李制定了项目整体进度计划，将项目分为需求分析、设计、编码、试运行和验收
五个阶段。为保证项目质量，小李请有着多年的编码、测试工作经历的测试组组长张工兼任项
目的质量保证人员。
在项目启动会上，小李对张工进行了口头授权，并要求张工在项目的重要阶段（如完成需
求分析、完成总体设计、完成单元编码和测试等）必须对项目交付物进行质量检查。在检查时，
张工可以根据自己的经验提出要求，对于不满足要求的工作，必须立即进行返工。
在项目组完成编码与单元测试工作，准备进行系统集成前，张工按照项目经理小李的要求进
行了质量检查。在检查过程中，张工凭借多年开发经验，认为某位开发人员负责的一个模块代
码存在响应时间长的问题，并对其开具了不符合项报告。但这位开发人员认为自己是严格按照
公司编码规范编写的，响应时间长不是自己的问题。经过争吵，张工未能说服该开发人员，同
时考虑到该模块对整体项目影响不大，张工没有再追究此事，该代码也没有修改。
（109）在编写概要设计和详细设计说明书的过程中，客户方提供了几处需求的修改要求。
由于其工作量不大，小李直接安排系统分析师按客户的要求进行了修改。在编码阶段后期，由
于客户的投资方发生了变化，新的投资方采用了新的运营模式，导致需求发生较大变化，由于
前期甲方已经强调过项目需求特点和要求，小李只能接受客户新的变更要求。在执行变更的过
程中，项目组发现新的需求将导致系统架构的更改，经过评估该变更将使项目延期。
（110）某公司长期从事系统集成项目，但是并不具备文档管理系统的开发经验。在参与此
项目的招投标时，虽然认为项目风险较大，但为了企业的业务发展，还是觉得投标，并最终中
标。
张某被任命为该项目的项目经理。考虑到该公司对此类项目尚无成熟案例，他认为做好项目
风险管理很重要，就参照以前的项目模板，编制了一个项目风险管理计划，经公司领导签字后
就下发各小组实施。但随着项目的进行，各成员发现项目中面临的问题与风险管理计划缺乏相
关性，就按照各自理解对实际风险控制和应对措施进行了安排，致使验收一拖再拖，项目款项
也迟迟不能收回。
（111）A 公司选择了一家长期合作的，资质良好的招标代理机构，并协助其编写了详细的
招标文件， 在 6月 1日，招标代理机构在其官网发布了招标公告。招标公告规定，投标人必须
在 6 月 25 日如 10:00 前提交投标文件，开标时间定为 6 月 25 日 14:00。6 月 25 日 14:00，开
标工作准时开始，由招标代理机构主持，并要求了所有投标方参加。开标时，招标代理机构工
作人员检查了投标文件的密封情况。经确认无误后，当众拆封，宣读投标人名称、投标价格和
197
198
投标文件的其他内容。
为保证投标工作的公平。公证，A公司邀请了7名来自本公司内部各部门（法律、财务、时
差、IT、商务等）的专家或领导组成了评标委员会。评标委员会按照招标文件确定的评标标准
和方法，对投标文件进行了评审和比较。
（112）公司中标一个城市的智能交通建设项目。在项目管理计划发布之后，柳工作为本项
目的项目经理，领导项目团队按照计划与任务分工开始实施。
在项目初期，项目团队在确定了项目范围后，项目经理制定了项目变更流程：
1提出变更申请； 2、针对影响不大的变更，可以直接修改； 3、针对影响较大的变更，必
须上报项目经理，由项目经理审批之后才能修改；4、修改后由项目经理确认，确认无误后更新
配置库，完成变更。
在一次项目进度协调会上，项目经理柳工与项目成员李工发生了争执，原因如下：李工对于
客户提出的需求，无论大小都给予解决，客户对此非常满意。但是，项目组其他成员并不知晓
李工修改的内容，导致开发任务多次返工。
（113）A 公司是为保险行业提供全面的信息系统集成解决方案的系统集成企业。齐工是 A
公司的项目经理，目前正在负责某保险公司 P 公司的客户管理系统开发项目，当前该项目己经
通过验收。
齐工将项目所涉及的文档都移交给了 P 公司，认为项目收尾工作已经基本完成， 所以解散
了项目团队，并组织剩下的项目团队成员召开了项目总结会议。项目组成员小王提出：项目组
有人没有参加总结会议，是否要求所有人员都要参加？"，齐工解释说：项目总结会议不需要全
体人员参加，没有实质性的工作内容。
（114）A 公司中标某客户数据中心建设项目，该项目涉及数据中心基础设施、网络、硬件、
软件、信息安全建设等方面工作。经高层批准，任命小李担任项目经理。小李从 相应的技术服
务部门（网络服务部、硬件服务部、软件服务部、信息安全服务部）分别抽调了技术人员加入
该项目。这些技术人员大部分时间投入本项目，小部分时间参与公司的其它项目。由于公司没
有基础设施方面的技术能力，因此将本项目的基础设施建设工作外包给了 B 公司。
小李认为，该项目工作内容复杂，涉及人员较多，人员沟通很关键，作为项目经理，自己应
投入较大精力在人员沟通管理上。
首先，小李经过分析，建立了干系人名册，主要人员包括客户方的 4 名技术人员、3 名中
层管理人员、 2 名高管和项目团队人员以及 A 公司的 2 名高管。
接着，小李制定了沟通管理计划。在选择沟通渠道时，考虑到干系人较多，召开会议不方便，
小李决定采用电子邮件方式：在沟通频率方面，为了让干系人能及时、 全面地了解项目进展，
小李决定采用项目日报的方式每日沟通：在沟通内容方面，小李制作了项目日报的模板，主要
内容包括三部分 一是项目成员每日主要工作内容汇总：二是项目的进度、成本、质量等方面的
情况、汇总：三是每日发现的主要问题、工作建议等。
项目实施过程中，项目成员严格按照要求，每天下班前发送日报给小李。第二天上午 9 点
前，小李汇总所有成员的日报内容，发送给所有干系人。
随着项目的实施，小李发现 B 公司的技术人员的工作质量经常不能满足要求，工作进度也
有所延迟，当问及 B 公司的相关负责人时，他们表示对此并不知情。同时， A公司各技术服务
部门的负责人也抱怨说，他们抽调了大量技术人员参与该项目，但却无法掌控他们的工作安排，
也不知道他们的工作绩效。另外，A 公司高层领导也向小李表示，客户管理层对该项目也有些
不满，他们认为每天浪费了大量时间看了一些无用的信息，他们希望小李能当面汇报。
（115）A公司承接了一个为某政府客户开发ERP软件的项目，任命小张担任项目经理。由
于该客户与 A 公司每年有上千万元的项目合作，A 公司管理层对客户非常重视，并一再嘱咐小
张要保证项目的客户满意度。为此，小张从各部门抽调了经验丰富的工程师组建了项目团队。
在项目初期，小张制定了变更和配置管理规则：客户需求发生变化时，应首先由工程师对需
求变化造成的影响做评估，如果影响不大，工程师可以直接进行修改并更新版本，不需要上报
项目经理；当工程师不能判断需求变化对项目的影响时，应上报给项目经理，由项目经理作出
评估，并安排相关人员进行修改。
在项目实施过程中，用户针对软件的功能模块提出一些修改需求，工程师针对需求做了评估，
发现修改工作量不大，对项目进度没有影响，因此，出于对客户满意度的考虑，工程师直接接
受了客户的要求，对软件进行修改。在软件测试联调阶段，测试人员发现部分功能模块与原先
设计不符，造成很多接口问题。经调查发现，主要原因是客户针对这些功能模块提出过修改要
求，项目经理要求查验，没有发现相关变更文件。
（116）甲公司中标一个城市轨道交通监控系统开发项目，公司领导决定启用新的技术骨干
作为项目经理，任命研发部软件开发骨干小王为该项目的项目经理。
小王技术能力强，自己承担了该项目核心模块开发任务，自从项目管理计划发布以后，一直
投身于自己的研发任务当中。除了项目阶段验收会之外，没有召开过任何项目例会，只是在项
目出现问题时才召开项目临时会议。经过项目团队共同努力，该项目进展到系统测试阶段。
在系统测试前，发现该项目有一个指示灯显示模块开发进度严重滞后，小王立刻会同该模块
负责人小李一起熬夜加班赶工，完成了该模块。
小王在项目绩效考核时，认为小李的工作态度不认真，给予较差评价并在项目团队内公布考
核结果。小李认为自己连续熬夜加班，任务也已完成，觉得考核结果不公平，两人就此问题发
生了严重冲突，小李因此消极怠工，甚至影响到了项目验收。
（117）项目启动初期，张伟任命项目成员李明担任项目的质量管理员，专职负责质量管理，
考虑到李明是团队中最资深的工程师，有丰富的实践经验，张伟给予李明充分授权，让他全权
负责项目的质量管理。
得到授权后，李明制定了质量管理计划，内容包括每月进行质量抽查、每月进行质量指标分
析、每半年进行一次内部审核等工作。
2017 年 7 月份，在向客户进行半年度工作汇报时，客户表示对项目的不满，一是项目进度
比预期滞后:二是项目的阶段交付物不能满足合同中的质量要求。
199
由于质量管理工作由李明全权负责，张伟并不清楚究竟发生了什么问题，因此，他找李明进
行了沟通，得到两点反馈:
1.在每月进行质量检查时，李明总能发现些不符合项。每次都口头通知了当事人，但当事人
并没有当回事，同样的错误不断重复出现：
2.李明认为质量管理工作太得罪人，自己不想继续负责这项工作。
接着，张伟与项目组其他成员也进行了沟通，也得到两点反馈:
1.李明月度检查工作的颗粒度不一致。针对他熟悉的领域，会检查得很仔细：针对不熟悉的
领域，则一带而过；
2.项目组成员普遍认为:在项目重要里程碑节点进行检查即可，没必要每月进行检查。
（118）项目经理范工承接了一个开发鲜花配送 APP 的项目，项目需求非常明确， 此前 A
公司承接过一个类似的项目，做得很成功，项目结束后人员已经分派到其他项目组。经过认真
考虑反复论证后范工决定采用虚拟团队方式搭建项目组，项目架构师由一位脚踝骨折正在家修
养的资深工程师担任，开发团队依据项目模块的技术特点分别选择了西安和南京的两个有经验
的项目小组，测试交给了美国旧金山分部的印度籍测试员Lisa，其他成员均在北京总部的公司
内部选拔。项目经理范工编制了人力资源管理计划并下发给每个成员以便他们了解自己的工作
任务和进度安排。
项目刚进入设计阶段，开发团队在APP 的测试部署方式和时间上与 Lisa发生了争执，南京
开发团队没有跟项目经理范工沟通就直接将问题汇报给了当地的执行总经理王总。王总批评了
范工，范工虽然觉得非常委屈，但还是立即召集了包括架构师在内的相关人员召开紧急电话会
议。会上多方言辞激烈，终于确定了一套开发团队和测试团队都觉得可行的部署方案。
（119）信息系统集成公司承接了一项信息系统集成项目，任命小王为项目经理。
项目之初，根据合同中的相关条款，小王在计划阶段简单地描绘了项目的大致范围，列出了
项目应当完成的工作。甲方的项目经理是该公司的信息中心主任，但该信息中心对其他部门的
影响较弱。由于此项目涉及到甲方公司的很多业务部门，因此在项目的实施过程中，甲方的销
售部门、人力资源部门、财务部门等都直接向小王提出了很多新的要求，而且很多要求彼此都
存在一定的矛盾。
小王尝试地做了大量的解释工作，但是甲方的相关部门总是能够在合同的相关条款中找到变
更的依据。小王明白是由于合同条款不明确导致了现在的困境，但他也不知道该怎样解决当前
所面临的问题。
（120）系统集成商甲公司承接了一项信息管理系统建设项目，甲公司任命具有多年类似项
目研发经验的张工为项目经理。
张工上任后，立刻组建了项目团队，人员确定后，张工综合了工作任务、团队人员的经验和
喜好，将项目组划分为三个小组，每个小组负责一个工作任务。团队进入了开发阶段，张工发
现，项目管理原来没有研发编程那么简单；其中 1 个项目小组的重要开发人员因病请假，导致
该小组任务比其他两个小组滞后 2周。另外，每个小组内部工作总出现相互推诿情况，而且小
200
201
组和小组成员矛盾也接连不断，项目任务一度停滞不前。
此时，正赶上人事部推出新的项目绩效考核方案，经过对项目进度和质量方面的考评结果，
项目绩效成绩较低，直接影响了每个项目团队成员的绩效奖金。项目组成员负面情绪较重，有
的成员在加班劳累和无法获得绩效奖金的双重压力下准备辞职，张工得知后，与项目组成员私
下进行了逐一面谈。
（121）系统集成公司B承建了A公司的办公自动化系统建设项目，任命张伟担任项目经理。
该项目所使用的硬件设备(服务器、存储、网络等)和基础软件(操作系统、数据库、中间件等)
均从外部厂商采购，办公自动化应用软件采用公司自主研发的软件产品。采购的设备安装、部
署、调试工作分别由公司硬件服务部、软件服务部、网络服务部完成。由于该项目工期紧，系
统相对比较复杂，且涉及实施人员较多，张伟认为自己应投入较大精力在风险管理上。
首先，张伟凭借自身的项目管理经验，对项目可能存在的风险进行了分析，并对风险发生的
可能性进行了排序。排名前三的风险是:
(1)硬件到货延迟；
(2)客户人员不配合；
(3)公司办公自动化软件可能存在较多bug。
针对上述三项主要风险，张伟制定了相应的应对措施，并且计划每月底对这些措施的实施情
况进行回顾。
项目开始2个月后，张伟对项目进度进行回顾时，发现项目进度延迟，主要原因有两点:
(1)购买的数据库软件与操作系统的版本出现兼容性问题，团队成员由于技术技能不足无法
解决，后通过协调厂商工程师得以解决，造成项目周期比计划延误一周。
(2)服务器工程师、网络工程师被自己所在的部门经理临时调走支持其他项目，造成项目周
期延误一周。
客户对于项目进度的延误很不满意。
（122）项目组接到任务后，各成员根据各自分工制定了相应项目管理子计划，小王将收集
到的各子计划合并为项目管理计划并直接发布。
为了保证项目按照客户要求尽快完成，小王基于自身的行业经验和对客户需求的初步了解后，
立即安排项目团队开始实施项目。在项目实施过程中，客户不断调整需求，小王本着客户至上
的原则，对客户的需求均安排项目组进行了修改，导致某些工作内容多次重复。项目进行到了
后期，小王才发现项目进度严重滞后，客户对项目进度很不满意并提出了投诉。
接到客户投诉后，李总要求项目管理办公室给出说明。项目管理办公室对该项目情况也不了
解，因此组织相关人员对项目进行审查，发现了很多问题。
（123）由于项目金额巨大，A 公司决定委托当地某知名招标代理机构，通过公开招标方式
选择系统集成商。
6月20日，招标代理机构在网站上发布了该项目的招标公告，招标公告要求招标人必须在6
月30日上午10:00前提交投标文件，地点为黄河大厦5层第一会议室。
|
|
