[问题1]
   ①没有明确的授权。建议：事先明确建议方有权提出变更申请的人员和实施方有权受理变更的人员，并有效地控制双方人数。
   ②对变更没有进行必要的审核。建议：并不是所有的变更都要修改，也不是所有变更都要立刻修改。审核的目的是为了决定是否需要修改和什么时候修改。例如，对于界面风格问题，可以先规划一下修改的时间待到以后进行优化；对于核心模块的修改，则应严格审核把关，否则会引起全局问题。
   ③对变更的影响没有评估。建议：应该事先评估一下变更的代价及其对项目的影响，并让客户了解变更的后果，与客户一起做出相应的决策。
   ④没有让客户确认是否接受变更的代价。建议：在评估代价并且与客户讨论的过程中，请客户一起作判断决策。

[解析]
[问题1]
   变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。IT项目中引起变更的因素有两个：①是来自外部的变更要求，如客户要求修改工作范围和需求等；②是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大(特别是到项目的后期)。
   变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起；另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。
   对于本案例所描述的信息可以看到各种变更失控的现象和造成的后果，项目经理老李主要犯了以下几个错误(包含但不限于)：
   ①没有明确的授权。事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接口人的好处在于：可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际项目管理经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。
   ②对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。例如，案例中提到的界面风格问题，可以先暂缓修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的“擅自修改核心模块”造成的事故就是因为没有审核而造成的。
   ③对变更的影响没有评估。变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起作判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道承建方为变更付出的代价，对项目团队的辛苦便难以体会。案例中客户刚开始对老李加班处理变更相当满意，但只是对工作态度满意，后期当变更引发一系列问题时客户并没有感谢老李的苦劳。
   ④没有让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请客户一起作判断：“我可以修改，但您能接受后果吗?”案例中如果项目经理老李评估了修改界面的工作量并请客户确认，则有以下3种可能结果：A．客户预先接受延期这一后果，也就不会再质问老李了：B．如果客户认为代价太大，则老李就不必修改了；C．如果认为可以缩短延期时间，则老李至少争取到了与客户协商的机会，让客户知道为此项目组需要付出加班的代价，吃个“明亏”。

[问题2]
   (1)需求基线
   (2)文档化
   (3)项目初期文档化的视图、范围、限制
   (4)原型法
   (5)需求跟踪

[解析]
[问题2]
   对于信息系统软件项目，“扩展需求”是指在软件需求基线已经确定后又要增添新的功能(或进行较大改动)的情况。通常，管理需求扩展的第一步是：将新系统的视图、范围和限制等进行文档化并作为业务需求的一部分。评估每一项建议的需求和特性，将与项目初期文档化的视图、范围、限制进行比较，以决定是否采纳此项变更。事实上，控制需求扩展时要敢于跟客户说“不”，但由于乙方的被动性，在否决客户的变更需求后要相应提出解决方法(例如，与其商议在后续项目或下一版本中满足他们的需求等)。
   控制需求扩展的另一个有效的技术是原型法。该方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确地把握用户的真实需求。
   需求跟踪活动的目的是建立与维护“需求—设计—编程—测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。

[问题3]
   ①缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。
   ②缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。
   ③在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延；另一方面，对于组织财富和经验的积累也是不利的。
   ④修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。
   ⑤未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量

[解析]
[问题3]
   本案例所列举的情况可能会导致以下一些后果(包含但不限于)：
   (1)缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。
   (2)缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。
   (3)在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延；另一方面对于组织财富和经验的积累也是不利的。
   (4)修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。
   (5)未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量。

[问题1]
   (1)5    (2)6
   (3)6    (4)5
   (5)1    (6)13

[解析]
[问题1]
   在图7-11项目计划网络图中，根据表7-13所给定的各项工作持续时间，顺着箭线方向可以逐项计算出各项工作的最早开始时间和最早完成时问。对于“编程测试”工作其紧前工作有两项(即“需求调研”工作和“系统分析”工作)，该工作的最早开始时间等于各个紧前工作的最早完成时间的最大值，即“需求调研”工作的最早完成时间(5个月)；或者是该工作的最早开始时间等于本工作的最早完成时间减去工作持续时间(即12-7=5个月)。
   某工作的总时差等于该工作最迟完成时间与最早完成时间之差，或该工作最迟开始时间与最早开始时间之差。例如，在图7-11中，“编程测试”工作总时差为6-5=1个月。
   在图7-11项目计划网络图中，从网络计划的终止节点，逆着箭线方向可以逐项计算出各项工作的最迟开始时间和最迟完成时间。某工作的最迟完成时间等于该工作的最早完成时间加上其总时差之和。例如，在图7-11中，“编程测试”工作最迟完成时间为12+1=13个月。
   某工作的最迟开始时间等于该工作的最早开始时间加上其总时差之和。例如，在图7-11中，“硬件方案”工作最迟开始时间为0+6=6个月。
   对于有紧后工作的工作，其自由时差等于该工作的紧后工作最早开始时间减去本工作最早完成时间所得之差的最小值。例如，在图7-11中，“硬件方案”工作的紧后工作仅有“集成与试运行”工作，其自由时差为13-7=6个月。

[问题2]
   见图7-13

[解析]
   根据图7-11中各项工作的最早开始时间及其持续时间，可以画出如图7-13所示的该项目甘特图。在图7-13所示的甘特图中，横轴表示时间，纵轴表示要安排的活动，线条表示在该图生命周期中计划的(或实际的)活动完成情况。该甘特图直观地表明了任务计划在什么时间开始和什么时间结束。
   

[问题3]
   (7)17    (8)13
   (9)10    (10)5
   (11)3    (12)9
   (13)7
   (14)12

[解析]
   根据图7-13所示的甘特图中各项工作的最早开始时间，结合表7-14每项任务每月人员需求数量，可以得到如表7-16所示的每月人员需求数量。

表7-16 每月人员需求数量计算表
ID	任务名称	2011年												2012年
		1	2	3	4	5	6	7	8	9	10	11	12	1	2	3	4	5	6	7	8	9	10
1	需求调研	8	8	8	8	8
2	系统分析	4	4	4
3	系统设计						3	3	3	3	3	3	3	3
4	编程与测试						2	2	2	2	2	2	2
5	硬件方案及 配置	5	5	5	5	5	5	5
6	集成与试运 行														9	9	9	9
7	培训与验收																		7	7	7	7	7
每月人工需求量 小计		17	17	17	13	13	10	10	5	5	5	5	5	3	9	9	9	9	7	7	7	7	7

在图7-11项目计划网络图中关键路径为：开始→需求调研→系统设计→集成与试运行→培训与验收。为了考查该项目每月所需的最少人数，可以先安排关键路径上各项工作的人数，再优化调整具有自由时差的工作的启动时间。关键路径上各项工作的启动时间及人数的安排是确定的，在保证关键路径上作业及其紧前作业按时完成的情况下，“系统分析”、“编程与测试”、“硬件方案及配置”3个工作启动时间的安排就需要综合考虑平衡每个月所需的人数。表7-17给出了该项目每月人员需求数量优化配置的一种方案。该方案综合考虑到“硬件方案及配置”工作具有6个月的自由时差，将其安排在第7个月初开始，第13个月末结束。当然，在保证关键路径上作业及其紧前作业按时完成的情况下，表7-17“系统分析”、“编程与测试”、“硬件方案及配置”3个工作启动时间的安排还可以有多种组合排列方式，但是不管何种组合排列方式，该项目工作优化配置后每个月所需的最多人员数量至少为12人。

表7-17 该项目每月人员需求数量优化配置方案之一
ID	任务名称	2011年												2012年
		1	2	3	4	5	6	7	8	9	10	11	12	1	2	3	4	5	6	7	8	9	10
1	需求调研	8	8	8	8	8
2	系统分析	4	4	4
3	系统设计						3	3	3	3	3	3	3	3
4	编程与测试						2	2	2	2	2	2	2
5	硬件方案及 配置							5	5	5	5	5	5	5
6	集成与试运 行														9	9	9	9
7	培训与验收																		7	7	7	7	7
每月人工需求量 小计		12	12	12	8	8	5	10	10	10	10	10	10	8	9	9	9	9	7	7	7	7	7

[问题4]
   ①特点：近别的工作计划得较详细，远期的工作计划得较粗略
   ②依据：根据项目的规模、复杂度及项目生命周期的长短来确定
   ③滚动周期：1周、2周，或1～2周的时间周

[解析]
   滚动波浪式计划是项目渐进明细的一种表现形式，其特点是近期的工作计划得细一些，远期的工作计划得相对粗略一些。换言之，近期要完成的工作为工作分解结构(WBS)的最下层详细计划，而计划在远期完成的工作为工作分解结构的较高层计划。最近一两个报告期要进行的工作应在本期接近完成前更为详细地规划。
   滚动波浪式计划中的滚动周期应根据项目的规模、复杂度及项目生命周期的长短来确定。项目生命周期中有3个与时间相关的重要概念，即检查点(Checkpoint)、里程碑(Milestone)和基线(Baseline)。它们一起描述了在什么时候对项目进行什么样的控制。其中，检查点是指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个固定间隔的“采样”时间点，而时间间隔根据项目周期长短的不同而不同。若频度太小会失去意义，而频度过大会增加管理成本。常见的间隔是每周一次，项目经理需要召开周例会并上交周报告。
   在本案例中，该信息系统项目是针对一个大型超市、涉及软硬件集成工作的较大型及复杂的项目，滚动波浪式计划中的滚动周期可确定为1周(或2周，或1～2周的时间周期)。

[问题1]
   ①该项目没有严格执行公司已有的、完善的质量管理体系(或已有的、完善的质量管理体系落实不到位或形同虚设)
   ②CX公司的整个项目管理过程不能得到很好的落实，各项目之间资源平衡机制不完善；
   ③CX公司的单个项目管理制度不规范；
   ④团队成员身兼数职，顾此失彼；
   ⑤所编制的项目质量计划存在缺陷，且未经过评审，在具体实施中没有发挥应有的效用；
   ⑥该项目的质量控制形同虚设(或未落到实处)

[解析]
[问题1]
   成功的项目管理是在约定的时间和范围、预算的成本及要求的质量下，达到项目干系人的期望。项目质量管理包括为确保项目能够满足所要执行的需求的过程，以及质量管理职能的所有活动，这些活动确定质量策略、目标和责任，并在质量体系中凭借质量计划编制、质量控制和质量保证等措施，决定了对质量政策的执行、对质量目标的完成，以及对质量责任的履行。项目质量管理过程包括执行组织关于确定质量方针、目标和职责的所有活动，使得项目可以满足其需求。它通过质量计划编制、质量保证、质量控制程序和过程及连续的过程改进活动实施来实现质量管理系统。
   对于本案例，CX公司在项目管理过程中的不妥之处表现在(包含但不限于)：
   ①由题干“系统集成商CX公司两年前通过了ISO9000认证。……由于项目时间紧张，上线任务迫切，经过管理层讨论，决定临时简化流程，在开发阶段集中对质量进行把关”等关键信息可知，该项目没有严格执行公司已有的、完善的质量管理体系。虽然CX公司通过了IS09000认证，但是有可能没有按照要求持续改进，不断提高质量管理水平。
   ②由题干第2段信息可知，CX公司的整个项目管理过程不能得到很好的落实，各项目之间资源平衡机制不完善。
   ③单个项目管理制度不规范。例如，作为项目经理应该对项目质量负有全责，而老王随意下放权限，全权委托新项目需求分析阶段的质量控制工作，这种做法是不对的；项目经理老王的多项目管理能力有限。
   ④团队成员身兼数职，老王兼任多个项目，质量保证人员小郭兼任质量保证、质量控制、编制项目质量计划等工作。
   ⑤所编制的项目质量计划书存在缺陷，且未经过评审，在具体实施中没有发挥应有的效用。
   ⑥该项目的质量控制形同虚设(或未落到实处)。

[问题2]
   (1)B、C、G、H
   (2)交付产品(包括阶段性产品)前的质量把关
   (3)致力于增强满足质量要求的能力
   (4)致力于满足质量要求
   (5)管理职能
   (6)检查职能

[解析]
[问题2]
   (1)在评审需求规格说明书中，评审专家组成员通常包括建设单位代表、用户单位代表、行业专家、信息化领域专家。一般情况下，由于被评审的文档是承建单位完成的，而文档形成过程是监理单位监理的，因此项目经理、承建单位代表、监理单位代表3个角色不宜作为专家组成员。同时，目前工作仅为需求分析阶段，还未涉及测试验收阶段，因此不需要第三方测试机构代表的参与。通常，需求分析阶段的工作未涉及招标投标环节、合同谈判及签订环节等，因此需求评审会议时也不需要公证机构代表的参与。
   (2)项目质量控制与质量保证之间的关系是：①质量保证的焦点在于过程，而质量控制的焦点在于交付产品(包括阶段性产品)前的质量把关。②质量保证是一种通过采取组织、程序、方法和资源等各种手段的保证来得到高质量软件的过程，属于管理职能；质量控制是直接对项目工作结果的质量进行把关的过程，属于检查职能。③质量保证的关键点是确保正确地做；质量控制的关键点是检查做得是否正确。④质量保证和质量控制有共同的目标，有一组既可用于质量保证，又可用于质量控制的方法、技术和工具。

[问题3]
   (1)①效益/成本分析；②基准比较；③流程图；④实验设计；⑤质量成本分析；⑥质量功能展开；⑦过程决策程序图法
   (2)①研究落实专家评审意见；
   ②完善用户业务需求分析工作；
   ③修改和完善该项目的需求规格说明书；
   ④请监理单位审核修改后的需求规格说明书(若有)；
   ⑤提出重新组织需求评审会的申请，并提交完善及审核后的需求规格说明书

[解析]
[问题3]
   (1)质量计划编制包括识别与该项目相关的质量标准，以及确定如何满足这些标准。首先由识别相关的质量标准开始，通过参照或者依据实施项目组织的质量策略、项目的范围说明书、产品说明书等作为质量计划编制的依据，识别出项目相关的所有质量标准，从而达到或者超过项目的客户及其他项目干系人的期望和要求。制定项目质量计划通常采用效益/成本分析、基准比较、流程图、实验设计、质量成本分析等方法和技术，以及采用质量功能展开(QFD)、过程决策程序图法(PDPC)等工具。
   (2)在需求评审未通过的情况下，项目经理老王应根据专家组的评审意见，研究如何落实专家意见，然后依据专家意见开展相关的完善工作(例如获取那一部分尚未覆盖的业务需求，梳理与实际存在较大偏差的需求并重新进入获取环节等)，并进一步完善需求规格说明书等文档；若该项目有监理单位，则请其审核完善后的需求规格说明书；向建设单位提出重新组织需求评审会的申请，并提交完善、审核后的需求规格说明书。