项目范围管理案例

-z.第2章工程围管理案例工程的围管理影响到信息系统工程的成功。在实践中，需求蔓延〞是信息系统失败最常见的原因之一，信息系统工程往往在工程启动、方案、执行、甚至收尾时不断参加新功能，无论是客户的要求还是工程实现人员对新技术的试验，都可能导致信息系统工程围的失控，从而使得信息系统工程无论在时间、资源和质量上都受到重影响。2．1案例一：围定义阅读以下关于信息系统工程管理过程中围管理面问题的表达，答复下列问题1至问题3。2.1.1案例场景希赛信息技术(CSAI原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开场进军电子政务行业。在电子政务的市场中，接到的第一个工程是开发一套工商审批系统。由于电子政务要求，该系统涉及到两个互不联通的子网：政务网和政务外网。政务网中储存着全部信息，其中包括局部信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务网系统。工是该工程的工程经理，在捕获到这个需求后认为电子政务建立与企业信息化有很大的不同，有其自身的特殊性，假设照搬企业信息化原有的经历和案必定会遭到惨败。因此采用了格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决案，在经过格评审后实施。在工程交付时，虽然系统完全满足了性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层严密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的局部代码才通过验收。由于系统的反复变更，工程组成员产生了强烈的挫折感，士气低落，工程工期也超出原方案的100％。【问题1】请不超过300字，对工的行为进展点评？【问题2】请从工程围管理的角度找出该工程实施过程中的主要管理问题？不超过200字答复。【问题3】请结合你本人实际工程经历，指出应如防止类似问题？不超过200字答复。2.1.2案例分析这是一个失败的工程，工在工程管理中既有闪光点，也有失败的地。但工程管理中的任过失都会影响工程的结果，而围管理的失误对工程的影响更为明显。模糊的工程围定义、错误的工作分解、缺失的围确认和无力的围控制都将重影响工程的结果。工对工程围有一定的把握。在围定义中，工发现了不同行业间具有不同的特点，电子政务行业对系统运行环境有着特殊的要求。根据对电子政务的要求，政务网与政务外网是该行业一致的标准，这与企业信息化是完全不同的。工捕获到该需求，并对这个需求进展了清晰的定义，根据瀑布模型的要求，对设计和实现都进展了格的控制，因此在系统交付时完全满足了用户对性的要求。在这一点上，工是成功的。如果在围定义时忽略了行业标准，工程肯定会招致更大的失败。但用户界面的风格和操作的便捷性也属于系统围的一局部。与系统运行环境一样，我们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的围所约束。对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很强的个性化，但一致的界面风格可以表达出政务的肃性。考虑到全体民众层次差异较大，大多数访问系统的用户一般都没有承受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求工没有充分考虑，从而导致一而再，再而三的变更。对于软件工程，所有的需求都必须经过清晰的定义，这些需求都是工程围的一局部。工仅仅注意了其中的一局部，而忽略了用户界面，最终导致工程的失败。对于电子政务信息系统，尤其是面向公众开放的信息系统，围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到工程组。但最终用户的意见对工程的结果会有巨大的影响，这是就对围管理提出了更高的要求。除了在围定义面的问题外，工在围确认和围控制面也存在不小的失误。当系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面风格和操作风格，并设法进展确认。如果采取了恰当的措施，第二次的变更是完全可以防止的。在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点都是工程围的风险。面对这些风险，即使再细致的调研也无法完全防止，也不能完整定义系统的围。因此可以考虑采取原型法等式来提前暴露风险，减少风险带来的损失。因此在案例中，工也没有进展充分的风险管理，采用格的瀑布模型增加了风险发生后带来的损失。对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑，这必然增加变更的代价，从而导致大局部代码重写。假设在工程初期意识到界面变更的风险，随之采用良好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。综上所述，工程经理工在整个案例中，针对围管理做了一些工作，但不全面，在风险管理和质量管理上也都存在缺陷。有了上面的分析，这道题就很容易作答。工程的闪光点在于对系统运行环境进展了清晰的定义，并最终满足了用户的要求；但不充分的围定义和围确认招致了工程的失败，而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致工程延期100%.因此第一题答案的要点就很明确了：(1)工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2)工忽略了系统用户的潜在要求，在用户界面和操作的风格上围定义不清晰，造成系统交付的重大变更。(3)工在第一次问题发生后仍没有对围进展有效的管理，造成了系统第二次的变更。(4)工没有对用户界面是否能够满足要求的风险进展有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。(5)工没有对设计质量进展有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。对于第二题，是在第一题的根底上考察对围管理的理解，因此可以忽略在其他领域的问题。在围管理中主要包括如下容：(1)围管理方案。(2)围定义。(3)工作分解。(4)围确认。(5)围控制。在本案例中，没有专门设计到围管理方案和工作分解的容。从外表上看，围定义存在明显的缺陷。但案例中提到系统又发生了第二次变更，由此可见，工在围确认和围控制上也存在缺乏。假设在问题第一次出现时就进展有效的围确认和围控制，则完全可以防止第二次的变更。因此，第二题的答案要点如下：(1)工没有挖掘到系统的全部隐性需求，缺乏准确的围定义。(2)在发生第一次变更时，工仍没有有效的围管理，从而造成系统的二次变更。(3)重复的系统变更说明工对系统围控制缺乏，导致一而再再而三的反复。在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。工程管理是一个系统工程，没有哪种单一的手段可以有效地改善工程，反之管理中的任疏忽都可能招致重的后果，造成工程的失败。而软件工程的复杂性又决定了工程中的工作环环相扣，问题也总是相互关联的。在发现问题后，也需要采取多种手段才能彻底解决问题。这对信息系统的工程经理来说是重大的挑战。2.1.3参考答案【问题1】(1)工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2)工忽略了系统用户的潜在要求，在用户界面和操作的风格上围定义不清晰，造成系统交付时的重大变更。(3)工在第一次问题发生后仍没有对围进展有效的管理，造成了系统第二次的变更。(4)工没有对用户界面是否能够满足要求的风险进展有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。(5)工没有对设计质量进展有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。【问题2】(1)工没有挖掘到系统的全部隐性需求，缺乏准确的围定义。(2)在发生第一次变更时，工仍没有有效的围管理，从而造成系统的二次变更。(3)重复的系统变更说明工对系统围控制缺乏，导致一而再再而三的反复。【问题3】有效的围管理包括了从围定义到围控制等多面的工作，每一项工作都是重要的。对于本案例，要结合行业特点进展需求分析，挖掘系统潜在的需求，同时通过原型等法来辅助需求的定义，防止围定义不清晰的问题。在发生需求变更时需要进展有效的需求控制，尽量在满足用户需求的前提下缩小需求围，坚决防止需求的再次变更。2．2案例二：工作要点阅读以下关于信息系统工程管理过程中工程围管理面问题的表达，答复下列问题1至问题2。2.2.1案例场景M集团是希赛信息技术(CSAI)多年的客户，CSAI已经为其开发了多个信息系统。最近，M又和CSAI签订了新的开发合同，以扩大整个企业的信息化应用围，工担任该工程的工程经理。工组织相关人员对该工程的工作进展了分解，并参考了公司同M曾经合作的工程，评估得到工程，总工作量60人月，方案工期6个月。工程刚刚开场不久，工的高层经理S找到工。S表示，由于公司运作的问题，需要在4个月完成工程，考虑到压缩工期的现实，可以为该工程在增派两名开发人员。工认为，整个工程的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史上与K企业合作的工程度量数据，该工作量是客观真实的。目前工程已经开场，增派的人手还需要一定的时间熟悉工程情况，因此即使增派两人也很难在四个月完成。如果强行要求工程组成员通过加班等式追逐4个月完成的目标，肯定会降低工程的质量，造成用户不满意。因此，工提出将整个工程分为两局部实现，第一局部使用三个半月的时间，第二局部使用三个月的时间，分别制定出两局部的验收标准，这样不增派开发人员也可以完成。高层经理认为该案可以满足公司的运作要求，用户也同意按照这种案进展实施。六个月以后，工程在没有增加人员的前提下顺利地完成，虽然比最初方案延长了半个月的工期，但既到达了公司的要求，客户对最终交付的系统也非常满意，工程组的成员也没有感受到很大的压力。【问题1】请不超过500字，指出工是如保证工程成功的？【问题2】请不超过500字，试结合案例指出工程围管理的工作要点？2.2.2案例分析这是一个成功的工程管理案例，工程经理工有效的运用围管理，在不同的工程干系人中达成一致，使工程的结果同时满足了高层经理、客户和工程组成员的要求。作为一个工程管理者，必须熟练掌握和应用工程管理九大领域涵盖的知识与技能，对于进展信息系统开发工程而言，围管理是其中最重要的技能之一。软件工程的围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的。软件系统的需求来源于用户需求，在软件工程目标是满足用户需求的情况下，对于一样的用户价值可以定义出不同的系统需求。举一个简单的例子，用户的需“解决口渴的问题〞，则最简单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水，更复杂的是递上一杯经过多层过滤的纯洁水，当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井茶。用户当然希望用买矿泉水的换一杯正宗的龙井茶，但这样的工程围肯定会导致工程失败。聪明的软件工程经理总是从围管理开场，先界定系统的边界，然后再在明确的围进展时间、本钱、风险等的管理。在工程中，时间、本钱和围构成了一个稳固的三角形，如图2-1所示。对于该三角形来说，任一边都不可能孤立地改变。换句话说，我们不可能固定其中两边而试图缩短第三边。其实这也是很容易理解的问题，如果工程需要做的东西已经确定(工程围固定)，工程的人员也已经确定(工程本钱固定)，则工程需要的时间就也是固定的。同理，已经固定的工程投入和工程时间也只能做出固定的工作。对于这个三角形而言，非但不可能孤立地改变*一边的长短，就是三边的变化比例不一致也不可能。不成比例的变化与孤立的改变*一边是一样的，都将破坏三角形的构造，违反工程的客观规律，最终招致失败。因此有效的围管理更像一门艺术，可以帮助工程经理在已经确定的时间和本钱下完成工程目标。在本案例中，高层经理S就提出了试图打破这个三角形的要求。他要求，工程组可以增加局部资源，但要提前两个月完成。初一看，并没有在不增加投入的情况下要求工程提前完成，似乎合情合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想，增加的资源和提前的时间还是不成比例。工程经理工深知此中微妙，因此在听到高层经理的要求后，马上意识到这是一个不可能完成的任务。则该如解决这个矛盾呢？还是要从这个三角形入手。既然时间和资源的变化已经打破了工程规律，则不妨根据新的时间和资源来重新划定合理的工程围，保证工程的正常运作。于是，工将这个工程拆分为两局部，重新定义这两局部的工程围，使每一局部的围都可以与已经确定的资源和时间匹配起来，让工程的运作又重新满足了工程的客观规律，最终取得了成功。在案例中，还有一些细节需要考生注意。工最初估算整个工程需要花费60人月的总工作量，但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素，超出原方案半个月是正常的。方案在6个月完成。在把工程拆分后，实际是用了6个半月的时间，也就是花费了65人月完成了工程。对于上面介绍的时间、本钱和围的关系而言，仅是在理想情况下成立，即工程成员始终能以固定的本钱完成固定的工作。而在实际情况下，工程的工期、复杂度等因素都会对工程造成影响。在案例中，虽然看似两局部工作的总和等于没有拆分前的工程，但这仅对于最终目标而言，拆分后的工程增加了假设干中间成果，工程的围实际上还是扩大了。因为软件工程的围直接与需求相关，所以，很多人误认为控制工程围就是控制需求，而控制的法就是减少需求的容。这种理解是完全错误的。围控制表达在软件开发的各个阶段，很多围控制并非是针对客户的要求而进展的。例如，本案例中，围控制就是针对高层经理的要求进展的。再比方，在设计中，我们既可以设计刚刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等面来简化设计，也可以对系统进展充分良好的设计，甚至可能是过度设计。采取哪一种设计谋略也是软件工程围管理的一局部。工程经理可以根据目前的工程的目标与环境出发，综合考虑质量和本钱的约束，制定明确的工程围，保证工程的成功。根据笔者的经历，即时需求已经确定，通过有效的围管理仍能给工程带来很大的收益，可以在不牺牲软件质量的前提下通过围管理来降低工程本钱，缩短工程工期。上面主要针对工在围控制面进展了分析，实际在整个案例中，工还进展了其他的围管理工作。首先，在工程刚刚开场，工就对工程围进展了定义，进而划分了WBS并对工程进展了估算和方案。在S提出需要缩短工期的要求后，工首先进展了工程围的控制，缩小了第一步需要完成的工程围。紧接着工又对两阶段需要完成的工程围进展了重新定义，制定了验收标准。最后，工对重新定义的围进展了确认，与客户和高层经理达成一致。对于工程而言，仅仅管理围仍不能保证工程的成功。在这个案例中，工也运用了其他的管理手段。其中包括，工对工程进展了估算，这属于工程时间管理的畴；工协调了多个工程干系人之间的矛盾，这属于沟通管理的畴。有了上面的分析，这道考题的答案也就很清晰了。2.2.3参考答案【问题1】(1)工首先对最初的工程围进展了清晰的定义，并根据定义对工作进展了分解，制定了WBS。(2)工对工程进展了估算，且估算结果真实可信，对工程工作量有量化的把握。(3)在出现新的工程目标后，工对工程进展了围控制，缩小了第一阶段实现的围。(4)工对重新定义的工程围进展了确认，与高层经理和客户达成一致。(5)工对工程进展了沟通管理，协调了多个工程干系人之间的矛盾。【问题2】工程围管理的要点：(1)围管理方案。(2)围定义。(3)工作分解。(4)围确认。(5)围控制。在本案例中，工首先进展了围定义和工作分解，得到了清晰的工程围；在出现新的工程目标后，工进展了围控制，重新定义了两个阶段的工程围；最后，工将重新定义的围与工程干系人进展了确认。2.3案例三：围确认阅读以下关于信息系统工程管理过程中工程围管理面问题的表达，答复下列问题1至问题3.2.3.1案例场景希赛信息技术(CSAI)刚刚和M签订了一份新的合同，合同的主要容是处理公司以前为M公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和围。由于是一个现有系统的升级，工程经理工特意请来了原系统的需求调研人员工担任该工程的需求调研负责人。在工的帮助下，很快地完成了需求开发的工作并进入设计与编码。由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到工程中，确认需求的工作一拖再拖。工认为，双已经建立了密切的合作关系，工也参加了原系统的需求开发，对业务的系统比拟熟悉，因此定义的需清晰的。故工并没有催促业务代表在需求说明书中签字。进入编码阶段后，工因故移民加拿大，需要离开工程组。工考虑到系统需求已经定义，工程已经进入编码期，工的离职虽然会对工程造成一定的影响，但影响较小，因此很快办理好了工的离职手续。在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时工已经不在工程组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，工程延期超过50%,M的业务代表也因为系统的延期表示了强烈的不满。【问题1】请以400字对工在工程管理工作中的行为进展点评。【问题2】请从工程围管理的角度找出该工程实施过程中的问题，以500字答复。【问题3】请结合你本人工程经历，谈谈应如防止类似的问题，以500字答复。2.3.2案例分析这是一个失败的软件工程，与很多失败的软件工程一样，在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建立的工程经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致工程的失败。案例中的工程经理工就是既重视需求又没有控制好需求的一个例子。在案例中，工接手了一个系统升级的软件工程。对于这样的工程，首先需要熟悉原有的系统，然后才能谈升级的问题。因此工专门找到了原系统的需求调研人员工来解决新系统的需求问题。这无疑是一个很好的方法，可以快速准确地把握新系统的需求。从这一点上来说，工是成功的，找到了适宜的资源进展需求的开发与定义。工也没有让工失望，很快就整理出了新系统的需求，并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽在工的掌握之中。这是一个灿烂的开端，如果一切顺利的话，工程的成功也就是早晚的事情。就如同大多数经典的悲剧故事一样，故事的序幕是美好的。晴朗的天空飘来一块乌云，工要移民加拿大。不过仅仅是一片乌云而已，并没有下起雨来。开发出的需求都已经过设计，一些编码工作也已经开场，工的工作已近圆满完成，毕竟，一些细枝末节的问题还可以同客户直接沟通。经过工程组努力，工程终于完成开发，准备发布了。这时，乌云开场下雨，问题爆发了。客户不认可工程组的工作，认为很多需求没有实现，实现的功能也与需求不符。谁是这个工程组的罪人呢？工？还是工？换一个思路考虑一下，如果工没有离开工程组，结果又会是什么样呢？客户会因为工还在工程组就认可这个系统吗？很显然，不会。至多可以在双发的协商下少一些变更，工程延期不是50%,而是30％而已。如果非要区分50％和30％的区别，也不过是五十步笑百步而已。从工程管理的角度来说，工程围直接决定了工作量和工作目标，所以工程经理必须管理工程的围。在围管理中，围定义、围确认和围控制又是最核心的三项活动，缺一不可。围定义是根底的活动，不进展围定义就不能进展围确认和围控制。围确认则是基线化已定义的围，是围控制的依据。围控制的作用在于减少变更，保持工程围的稳定性。在案例中，由于工没有进展围确认，最后的围控制也就变成了无本之木，控制过程肯定变成了讨价还价，失去本身的意义。在软件系统的开发中，系统需求就是工程的围。从软件诞生至今的几十年中，人们探索出了很多获取系统需求的法，但是熟悉软件开发的人都知道，无论哪种法都不可能定义出完美无误的需求，需求中的缺陷必然存在，无法完全防止。因此需求确认或者说是围确认就显得更为重要。有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软件行业的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要进展围确认，而且围确认的法