软件项目管理案例分析题Word格式.docx

软件项目管理案例分析题Word格式.docx

《软件项目管理案例分析题Word格式.docx》由会员分享，可在线阅读，更多相关《软件项目管理案例分析题Word格式.docx（14页珍藏版）》请在冰豆网上搜索。

由此而增加的工程经费，由A方承担。

“需求分析时，B方表达不清，A方理解有误，双方沟通不够，A方编制的需求分析说明了书未能准确、全面地表达B方的

实际需求，而B方未能及时指正”，属于双方责任，由此而增加的工程经费，由A、B双

方协商分摊。

其余各条，无论B方是否负有责任，均应承担由此而增加的工程经费。

问题4：

对于由内部因素引起的变更请求，变更评估的重点是确定最优变更方案。

而对于外部因素引起的变更请求，变更控制委员会应重点评估变更的必要性。

案例分析三问题1：

（1）没有清晰地了解到产品的范围，导致工程后期需求的蔓延；

（2）没有澄清模糊的工程范围，在安装服务器的问题上产生异议，最终增加了未计划到

的工作；

（3）没有进行变更控制，以至于变更的结果不理想，导致反复地变更。

（1）变更工作没有得到确认，导致工作的结果不能够被认可；

（2）变更没有得到有效地执行。

尤其当同时发生多个变更的时候，如果没有有效的控制很容易造成一些变更被忽略甚至遗漏；

（3）未控制的变更造成系统的混乱。

软件系统是一个复杂的系统，系统间很多部件都存在关联，对其中某一部分进行更改可能会牵连到其他部分，造成整个系统的问题。

问题3：

范围控制是范围管理中重要的工作之一，范围控制的主要目的是控制变更的结果；

保证所有被请求的变更都可以得到有效的处理；

协调所有同变更相关的工作、资源和交付成果，让工程始终处在被控制的状态。

范围控制的意义也在于此，通过范围控制，可以减少范围变更对工程造成的影响，降低风险，让工程处在可控制可跟踪的状态。

案例分析四

分解工程WBS的一般过程如下：

（1）识别可交付成果及有关工作；

（2）确定工作分解结构的结构与编排；

（3）将工作分解结构的上层分解到下层的组成部分；

（4）为工作分解结构组成部分提出并分配标识编码；

（5）核实工作分解的程度是否必要且足够。

创建工程WBS时需要注意以下四点：

（1）分解出的工作是充分且必要的；

（2）工作的独立性。

即工作一旦开始，就可以在不中断的条件下完成；

（3）工作完成度的可判断性。

即可以清楚地判断工作是否已经开始，工作完成了多少，

以及工作是否已完成。

（4）工作的交付成果。

即工作完成后将得到什么样的成果。

（1）在“同K企业负责人沟通后明确工程的范围”中，小张进行了范围定义的工作。

之后小张又编写《关于***系统第三方系统测评计划备忘录》的文档，并发给企业K负责人确认，让工程范围在各干系人中得到一致的认识。

（2）在“将配合第三方机构进行测评的工作加入到工程WBS”中，小张进行了范围控制的工作。

案例分析五

案例分析六

案例分析七

公司负责人不应该把单纯的参数模型放在成本估计上，而要根据不同的情况，采用不同的方法，否则会使成本估计产生很大的偏差。

在做成本估计时建立参数模型只是其中一种方法。

建立参数模型指在数学模型中运用工程特点（参数）来预测工程成本。

建立参数模型的首要条件是建模所参考的历史数据的精确性程度。

但是实际情况是该工程由于需要改动的那个过程中有很多工作不是很清晰，而且这过程还会对其他5个过程产生一些影响，影响的程度也没有得到明确的界定。

更重要的是，改动的流程过程占整个制造成本的36%,因此完全按照参数模型是不合适的。

由于王工程师能够准确地获得其他5个没有改动过程的详细成本信息，因此工程师在

对已经明了的工程的5个过程应该采用建立参数模型法来对其进行成本估计。

而对那个需要改动的过程应该采用类比估算法，这是由于当对工程的详细情况了解甚

少时（例如在工程的初期阶段），往往采用这种方法估算工程的总成本。

成本控制就是要保证各项工作要在它们各自的预算范围内进行。

成本控制的基本方法是规定各部门定期上报其成本报告，再由控制部门对其进行成本审核，以保证各种支出的合法性，然后再将已经发生的成本与预算相比较，分析其是否超支，并采取相应的措施加以弥补。

有效的成本控制的关键是经常及时分析成本绩效，尽早发现成本偏差和成本执行效率，这样就能在情况变坏之前及时有效地采取措施。

成本控制包括查找正、负偏差的原因，它必须与其他控制过程紧密地结合起来。

成本控制实质上就是监控成本的正负偏差，分析偏差产生的原因，及时采取措施以确保工程朝着有利的方向发展。

主要方法有成本变更控制系统、绩效衡量分析、工程绩效审核、电脑化工具、偏差管理等。

案例分析八

案例分析九

不明确需求就进行开发，造成工程开发无法制定相应的计划。

缺乏合理的工程开发计划，就无法保证工程的质量。

如果由于某种客观原因造成无法在软件工程开发之前明确这个需求，需要对这个软件工程进行阶段划分，在每个阶段中明确部分需求，并制定相应的开发计划。

该公司的张工应该尽可能早地明确整个软件工程的需求，制定相应的计划。

张工可以把整个工程的开发阶段进行划分，对每个阶段的需求进行分析，制定计划，执行计划。

B银行的赵工应该尽可能早地提出需求。

赵工在需求确定后如果需要变更请求，则要和张工一起协商，然后才能调整需求，并且对工程开发计划也进行相应的调整。

赵工应该和张工一起分析，明确每个工程开发阶段

的需求。

在工程的需求分析阶段，工程负责人和需求提出者需要仔细研究整个工程的相关业务逻辑，了解整个工程的需求。

在需求得到明确的前提下，制定相应的开发计划。

在工程的实施阶段，需要对每个阶段的需求进行明确，制定相应的开发计划。

保证了每一个阶段的开发质量，就能够保证整个工程的质量。

案例分析十

该软件公司在明知原有系系统统已经投入使用的情况下，没有提前分析升级的风险并告知客户，此证券公司没有制定升级计划，没有和客户一起制定风险预案。

该证券公司在得知此软件公司要对他们正在使用的系统进行升级的情况下，没有主动向该软件公司了解升级可能引发的问题，没有制定必要的风险预案，以致出现问题时无法采取合理的补救措施，造成了一些损失。

现有系统由于一般已经投入使用，如果对其进行升级会有一定的风险。

在进行升级以前，应该对其可能包含的风险和可能带来的问题进行仔细分析和评估，并有针对性地制定风险预案和升级计划。

在升级失败或者出现问题影响系统使用的情况下，应该实施风险预案来保证系统的正常使用，尽可能地减少损失。

软件系统的升级和开发一样，也要制定相应的开发计划和质量保证计划。

如果缺少必要的计划和质量保证措施，也会导致很大的问题。

软件系统升级如果出现质量问题，带来的损失可能比开发过程中出现问题更严重。

因为如果一个正在使用的系统出现问题或无法正常使用，可能带来一定的经济损失。

因此我们必须像软件开发一样采取必要的质量保证手段来避免或尽可能地减少经济损失。

针对升级可能出现的风险，为了保险起见，需要制定一套或多套见险预案，并且进行预演，一般在出现问题时顺利采取风险预案来尽可能减少或避免产生经济损失。

案例分析十一

由于人力资源计划不合理或者客户在开发过程中的一些突发原因造成人力资源计划不足以应付工程的正常进行，工程管理人员则需要考虑增加人力资源。

在组织内部因为人员紧张已经不能提供合适的开发人员，同时公司管理层不打算增加人员经费，工程组经过研究决定招聘一批实习生，这算是一个比较正常的解决问题的思路，但是由于是组织外的人员，所以会增加管理难度。

同时由于在工程中期引入新的开发人员，也引入了新的风险：

新的开发人员可能不能及时完成作为先决条件的任务（如培训及其他工程）；

新的开发人员和工程管理层之间关系不佳，导致决策缓慢，影响全局；

由于在工资待遇方面和正式员工有较大差距，且缺乏激励措施，士气低下，降低了生产率；

新的开发人员中某些人员需要更多的时间适应还不熟悉的软件工具和环境；

因为是在工程中后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；

由于工程成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；

不适应工作的成员没有调离工程组，影响了工程组其他成员的积极性；

也许在所有新开发人员中没有找到工程急需的具有特定技能的人，等等。

以上这些因素都可能对工程进度造成很坏的影响，有较大的隐患，工程管理人员必须有效控制由此带来的人员风险。

关于如何教育和引导刚加入公司的新雇员这个问题，随着公司产品的多样性和复杂性变得越来越棘手，而且新加入公司人员可能分别从事不同的工作，如程序员，程序经理，客户支持工程师，针对不同的角色应该制定不同的方案。

越来越多的公司都试图聘用能自学业务的人员，而不愿在培训工程、正规条例和流程或详细的产品记录上的投资。

还可以通过熟练员工来教育新新雇员，这些熟练员工有经长、某些领域的专家以及正式指定的指导教师，他们除了本职工作外还要担负起教导新雇员的工作。

这种方法使得大家觉得有权学习并自己决定学什么和不学什么，使得他们在公司里的作用灵活机动。

例如对于程序经理的培训：

刚开始时，新雇员的任务可能是一个单独的特性，并且在直到完成为止的这段时间内，都会有人对你进行密切地指导。

随后，当这种工作已做得相当熟练之后，便会在更大的特性组中从事类似的工作，但指导会少得多。

一段时期后，受训者会拥有一个小工程或一个大工程的一部分。

同时，程序经理还可以受到一些正规的培训，包括一个供选修的培训工程。

另外，还可以不定期举行经验推介会，届时会有经验丰富的程序经理介绍他们自已的经验。

假设你是一个新进入公司的开发员，那么在头几天里，你会与经理们以及来自其他专业部门的高级人员会面，你会听到有关开发周期的一个方向性的简介，然后开发经理会立即派给你一个单独的任务或者让你与特性小组一起工作，你还可能被介绍给愿意当指导教师的高级开发员。

一般而言，你开始会从事相对容易的特性编码工作，这种工作需要的时间较少并且与其它特性关联甚少，并且高级人员（特性组长、领域专家、指导教师）随即非常仔细地检查你编写的代码。

此外对开发领域人员应该有更加正规的定向的培训。

例如，为新开发人员提供了几个为时几天的实习班，培训他们处理开发过程、产品、工具和其它专题。

此外对于客户支持工程师的培训也是十分重要的。

这主要是因为顾客不仅仅是购买产品，他们还要享受到优质的售后服务。

所以，训练有素的客户支持工程师对于保持公司良好形象和提高为顾客服务的能力是至关重要的。

客户支持工程师不必像开发员那样有必备的职业教育，但他们必须关于本公司产品如何工作的知识，并且实际上要在某种产品上具有专业知识。

新的客户支持工程师在上岗之前，接受一段时间的专门培训。

培训从基本的软件产品开始，同时他们还接受交际技巧，包括如何与顾客打交道等方面的一般性训练。

作为定向培训的一部分，他们还接电话，与导师一道工作（每位技术员有一位导师）。

在他们被分配处理客户的电话之前负责答复客户来信。

对日软件外包相对技术难度不高，但是质量要求相当苛刻，外包工程失败的例子不少。

以下就对日软件外包常见的一些问题进行简单探讨。

SE

（1）日方SE认为理所当然的地方，很多细节不会在式样书中明确写出，或者说日方完全按照日本做设计的习惯写式样书，由于中日文化和思维习惯的差异，可能导致中国软件开发人员对这些习惯问题理解有误。

对策：

积累经验，参照同类系统，提QA表确认。

（2）在产品提交期间，对于某些BUG，可能会出现这样的争执：

中方开发人员说是由

于日方的式样书没有写明确，式样书不够细致，日方设计人员说是中方理解式样书不对，有些地方不写也应该能自己理解。

首先确保产品质量的交货时间；

加强双方交流；

加强测试。

（3）有的工程是日方边设计，需要中方同步开发，中方开发人员认为式样书上写多

少就做多少没有写的就不做。

加强工程的交流，主动提出设计思考让日方人员确认是不是这样的意思。

（4）中方开发人员的日语熟练程度不够。

加强IT日语教育，开发人员至少达到能理解日语式样书的水平；

配置专业的日语翻译辅助。

（5）对于一些中方开发人员在太在意的一些细节问题，例如：

字体，颜色、对齐方式等，要求不够严谨。

强化质量意识，建立开发和测试规范。

（6）开发过程的规范性与开发人员的态度：

日本企业的开发管理，讲究中规中矩，非常重视文档的规范化管理，力求做到“凡事必求有据”；

而中国企业在文档的规范化管理方面相对淡薄；

日本企业工程管理对涉及的过程和文档，规定了极其严格的次序和样式，要求开发人员严格执行。

而中国企业在具体执行方面，开发人员往往对这些规范和要求的遵照不够严谨。

完全按照客户要求执行，包括文档，如：

开发进度报告、测试用例、测试报告等；

加强开发过程管理，规范开发过程，引入CMM模式；

加强软件质量保证，如代码评审、文档审核、测试。

（7）中国企业的开发人员比较喜欢技术创新，在开发过程中对于一些技术问题提出自己的技术方案，可能会导致部分模块技术实现方式与整体要求有差异。

完全尊重日本客户的文化和管理模式，积极提出技术建议；

对于有要求遵照Sample代码或对具体技术实现细节有严格要求的，开发人员必须严格遵循，不允许采用自已的技术实现；

加强代码审查（codereview）。

（8）一些日本企业与中国企业的SE共同参与设计或交流的工程。

对策：

在日本的合作伙伴企业派遣SE到工程现场进行设计；

派遣中国SE到日本参与设计，设计完成后带回中国开发；

日本企业短期派遣SE到中国。

（9）软件外包知识产权保护与客户保密问题。

严格保护日本客户商业秘密和知识产权；

中国企业与日本企业签订保密协议；

中国企业与开发人员签订保密协议。

（10）日本企业对中国企业开发进度的掌握。

按照日本企业工程管理要求报告工程进度；

分阶段交付。

（11）远程协同合作开发的交流手段和方式。

实时消息/语音/视频交流，例如：

MSNMessenger,YahooMesenger、视频会议系统、远程控制、远程协助、远程调试；

Email、FTP;

相互人才派遣，人才交流。

案例分析十二

在一个软件产品整个的生命周期中，软件产品发布之后便进入漫长的软件维护阶段，而对于一些行业软件更是如此，后期的软件维护是非常重要的一个环节。

在维护过程中通常要涉及到开发人员在现场对代码的维护，对数据和设备的维护，还可能需要根据用户要求对软件做相应的修改，有些可能涉及到重新开发或者发布新版本。

当然后期维护也可能在一段时间内将会带来相当丰厚的收入，保持良好的客户满意度也将变得非常重要。

现场开发人员不仅仅是完成维护工作，而且更多的是需要通过和用户沟通了解用户在使用软件过程中遇到的一些问题，帮助用户正确认识软件维护的目的，得到用户的支持和协助，使软件最大程度地帮助用户提高其工作效率，创造经济价值，在用户中建立起良好的口碑。

同时现场人员也应该积极收集和整理用户提出的一些问题，善于总结和思考，将这些问题反馈给公司总部，将一些用户期望的功能发布在下一个版本当中，并且完善旧有版本中的缺陷。

从这个角色出发，现场人员在一定程度上扮演了市场人员的角色，并且是接触最前线的用户，他们在做维护的同时，可以体会到用户使用软件的感受，从而得到最准确的市场信息，同时现场开发人员又是公司形象代表，每次现场工作都代表着公司的形象，所以公司需要设置专门的培训内容用于训练员工在外如何保持公司的良好形象同时做好宣传工作。

在软件开发过程中，团队协同开发，很容易出现软件版本管理不善带来的软件系统故障。

代码经常会被新的版本替换而使某些开发人员的工作成果丢失。

这样不仅会打击开发人员的工作热情，也不利于责任的明确。

在现场开发的过程中，由于缺乏监督和管理，这种情况会更加普遍，如工程现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，甚至只是开发人员的个人意见，并没有通过工程管理层的同意，这种处理方法就很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障的反复出现。

此外，由于现场维护一般都会涉及到大量用户数据，程序的修改不仅会影响到软件功能，更可能产生很多垃圾数据，这些都是用户所不希望看到的，所以对现场代码的更改要严格控制，并且及时和总部版本保持一致，如微软公司出品的版本管理工具VSS就能够做到WEB访问，通过有效配置能够有效控制现场版本。

案例分析十三问题1：

作为为工程经理面对工程问题应从更深层次上思考，要遵循工程管理原理，而不是浮于事务本身。

工程经理张强在工程开始时就应制定详细的工程管理计划，应先考虑好可能要进行的工程沟通并加以执行，而不是在出现问题时才去弥补。

沟通不完整的工程过程，大多数会顾此失彼，进一步导致工程问题的发生。

一言纳之，张强的问题关键是没有计划，如果按软件过程能力成熟度模型CMM评价，该工程组织只能是初始级。

造成工程问题的原因有以下几点：

（1）沟通管理计划没有或不够详细；

（2）没有重视部门间横向沟通；

（3）与客户沟通不到位，客户需求未能准确把握。

要实施高效的会议，首先是在会议前要有计划，通常会议计划来源于工程沟通管理计划，准备阶段通常按如下顺序实施：

1）

决定会议的宗旨和类型；

2）

分析会议的因果：

本次会议同本部门目标的关系？

本次会议同上、下次会议的

关系？

什么事可能会影响对本次会议的兴趣？

3）

明确涉及的、受影响的人和事；

4）

制定会议成果说明；

5）

决定要讨论的主题；

6）

决定会议角色分配；

7）

决定会场布置；

8）

计划会议议程表：

非正式议程表、正式议程表（

5W和1H）。

在会议过程中，有效地主持或参与会议则要注意按会议步骤逐项讨论议程，总结决定。

在会议中应鼓励与会者积极参与，制止消极行为和不良意见。

陈述信息要自信，态度要直接、坦率。

对整个会议要注意掌握时间，记录重要备忘事项和决定。

会议跟踪也是一项重要工作。

应自上而下逐级向必要的非与会者传达会议信息,制定行动

计划完成分派的工作,确定计划以跟踪会上决定的工作进度。

制定下次会议议程。

工程经理应明确自已的工作职责范围，对工程相关资源的安排在制定沟通管理计划时应有详细的描述。

对工程进度、工程成果应及时与公司高层领导或干系人沟通。

工程组织应建有基于Internet的软件开发交流平台，从而能调度、跟踪解决工程现场问题。

工程经理和工程人员应通过各种方式与客户多作交流，如QQ，MSN、电话、电子邮件等。

合适的组合是工程团队中至少一人是客户方的代表，工程初始时团队成员应与客户方的软件使用人员经常地进行业务方面的交流。

案例分析十四

工程经理刘克勤的工程沟通管理是成功的。

对于工程管理，除了掌握必备的工程基本方法和管理工具（如计划制定、预算编制等），对工程背景和目标有清楚的理解和认识外，最重要的一点就是与人交往的技巧。

成功工程经理和失败工程经理的最大差别，可能就在于如何跟人打交道，如何跟客户打交道，如何跟公司领导打交道，如何跟工程成员打交道。

工程经理刘克勤在工程过程中，团队建设相当成功。

他为团队成员间建立纽带，并通过各种行为加强信任和消除团队合作的障碍。

其中最值的借鉴是尊重团队成员、采用多种方法沟通、进行深度对话。

案例分析十五

我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程工程的三大目标。

通常与客户接触最多的是市场部工程经理，引导客户需求对工程经理就非常关键，工程经理引导得好，工程的开发就会非常顺利，反之，就会使工程组疲于奔命。

该工程中，市场部李工不断地提出新的需求时，张工“来者不拒”、疲于奔命、不停地更新工程计划，导致工程范围无法确定，工期和成本不可控制，团队成员工作目的也不明确。

风险应对策略一般分为四种：

回避、转嫁、减轻、接受。

回避风险指改变工程计划，以排除风险或条件，或者保护工程目标，使其不受影响。

转嫁风险指设法将风险的后果连同应对的责任转移到第三方身上。

减轻风险指设法把不利的风险事件的概率或后果降低至一个可接受的临界值。

采取此项技术表明工程班子已经决定不打算为处置某项风险而改变工程计划，或者表明他们无法找到任何其他应对良策。

该工程已经发生了严重的需求风险，张工采取补救措施应该包括减轻和接受。

减轻风险的应对措施应能设法减轻风险的影响，其着眼点应放在影响程度最大的连接点上，张工应该与李工积极地沟通和谈判，使他们明白本期工程的重要意义，并承诺本期工程不是交钥匙工程，可为系统升级和扩容留有扩展接口，将来新的需求能够通过后续工程逐步开发实现,李工同意本期工程只实现大家最

为关注的功能指标和性能指标。

最常