参考答案暂无
解析:【问题1】(12分)
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。IT项目中引起变更的因素有两个：①是来自外部的变更要求，如客户要求修改工作范围和需求等；②是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大(特别是到项目的后期)。
变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起；另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。
对于本案例所描述的信息可以看到各种变更失控的现象和造成的后果，项目经理老李主要犯了以下几个错误(包含但不限于)：
①没有明确的授权。事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接151人的好处在于：可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际项目管理经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。
②对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。例如，案例中提到的界面风格问题，可以先暂缓修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的‘‘擅自修改核心模块”造成的事故就是因为没有审核而造成的。
⑧对变更的影响没有评估。变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道承建方为变更付出的代价，对项目团队的辛苦便难以体会。案例中客户刚开始对老李加班处理变更相当满意，但只是对工作态度满意，后期当变更引发一系列问题时客户并没有感谢老李的苦劳。
④没有让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请客户～起做判断：“我可以修改，但您能接受后果吗?”案例中如果项目经理老李评估了修改界面的工作量并请客户确认，则有以下3种可能结果：A．客户预先接受延期这一后果，也就不会再质问老李了；8·如果客户认为代价太大，则老李就不必修改了；c．如果认为可以缩短延期时问，则老李至少争取到了与客户协商的机会，让客户知道为此项目组需要付出加班的代价，吃个“明亏”。
【问题2】(5分)
对于信息系统软件项目，“扩展需求”是指在软件需求基线已经确定后又要增添新的功能(或进行较大改动)的情况。通常，管理需求扩展的第一步是：将新系统的视图、范围和限制等进行文档化并作为业务需求的一部分。评估每一项建议的需求和特性，将与项目初期文档化的视图、范围、限制进行比较，以决定是否采纳此项变更。事实上，控制需求扩展时要敢于跟客户说“不”，但由于乙方的被动性，在否决客户的变更需求后要相应提出解决方法(例如，与其商议在后续项目或下一版本中满足他们的需求等)。
控制需求扩展的另一个有效技术是原型法。该方法能够给用户提供预览所有可能的实现．以帮助用户与开发者沟通从而准确地把握用户的真实需求。
需求跟踪活动的目的是建立与维护“需求一设计一编程一测试’，之间的一致性，确保所有的工作成果符合用户需求。需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。
【问题3】(8分) ·
本案例所列举的情况可能会导致以下一些后果(包含但不限于)：
(1)缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。
(2)缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。
(3)在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延；另一方面对于组织财富和经验的积累也是不利的。
(4)修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。
(5)未与项目干系人进行沟通可能会导致项目干系人的工作之问出现不一致之处，进而影响项目的整体素质。
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。IT项目中引起变更的因素有两个：①是来自外部的变更要求，如客户要求修改工作范围和需求等；②是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大(特别是到项目的后期)。
变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起；另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。另外，需求通过正式评审后应作为重要基线，从此之后即开始对需求变更进行控制。
对于本案例所描述的信息可以看到各种变更失控的现象和造成的后果，项目经理老李主要犯了以下几个错误(包含但不限于)：
①没有明确的授权。事先应该明确客户方有权提出变更申请的人员和实施方有权受理变更的人员，并要控制双方人数。这样做才可以对变更有整体的控制。绝不能进行“私下交易”，而没有人能完整地知道到底改了些什么。另外，授权双方接151人的好处在于：可以屏蔽客户内部的矛盾，如果只有一个接口人，内部尚未达成一致时变更是无法提出来的。从实际项目管理经验看，授权可以显著减少变更，特别是那些因内部看法不同而导致的反复变更。
②对变更没有进行必要的审核。并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。例如，案例中提到的界面风格问题，可以先暂缓修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题，案例中提到的‘‘擅自修改核心模块”造成的事故就是因为没有审核而造成的。
⑧对变更的影响没有评估。变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让客户了解变更的后果，并与客户一起做判断。案例中客户最后的质问正是因为没有事前告诉客户变更的影响造成的。如果客户不知道承建方为变更付出的代价，对项目团队的辛苦便难以体会。案例中客户刚开始对老李加班处理变更相当满意，但只是对工作态度满意，后期当变更引发一系列问题时客户并没有感谢老李的苦劳。
④没有让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请客户～起做判断：“我可以修改，但您能接受后果吗?”案例中如果项目经理老李评估了修改界面的工作量并请客户确认，则有以下3种可能结果：A．客户预先接受延期这一后果，也就不会再质问老李了；8·如果客户认为代价太大，则老李就不必修改了；c．如果认为可以缩短延期时问，则老李至少争取到了与客户协商的机会，让客户知道为此项目组需要付出加班的代价，吃个“明亏”。
【问题2】(5分)
对于信息系统软件项目，“扩展需求”是指在软件需求基线已经确定后又要增添新的功能(或进行较大改动)的情况。通常，管理需求扩展的第一步是：将新系统的视图、范围和限制等进行文档化并作为业务需求的一部分。评估每一项建议的需求和特性，将与项目初期文档化的视图、范围、限制进行比较，以决定是否采纳此项变更。事实上，控制需求扩展时要敢于跟客户说“不”，但由于乙方的被动性，在否决客户的变更需求后要相应提出解决方法(例如，与其商议在后续项目或下一版本中满足他们的需求等)。
控制需求扩展的另一个有效技术是原型法。该方法能够给用户提供预览所有可能的实现．以帮助用户与开发者沟通从而准确地把握用户的真实需求。
需求跟踪活动的目的是建立与维护“需求一设计一编程一测试’，之间的一致性，确保所有的工作成果符合用户需求。需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。
【问题3】(8分) ·
本案例所列举的情况可能会导致以下一些后果(包含但不限于)：
(1)缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。
(2)缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响。
(3)在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延；另一方面对于组织财富和经验的积累也是不利的。
(4)修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。
(5)未与项目干系人进行沟通可能会导致项目干系人的工作之问出现不一致之处，进而影响项目的整体素质。
你可能喜欢
