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

《软件项目管理案例分析题.docx》由会员分享，可在线阅读，更多相关《软件项目管理案例分析题.docx（33页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件项目管理案例分析题软件工程管理案例分析案例分析一问题1：本工程申请国家技术创新基金100万元，但国家实际批准基金额度很可能会低于100万元，“工程投资来源中应当讲明：当国家实际批准基金低于申请额度时，怎样补足二者之间的差额以及由此所引起的地方匹配基金的差额。应重新召开股东大会并讨论下面议题：当国家实际批准基金低于申请额度时，公司能否愿意补足二者之间的差额以及由此引起的地方匹配基金的差额。假如能够通过，应在“工程投资来源中加注：当国家实际批准基金低于申请额度时，公司承诺补足二者之间的差额以及由此引起的地方匹配基金的差额附新的公司股东大会决议。问题2：A，B双方以B方现有技术成果为基础进一步合

2、作开发，应明确下面几个主要问题：1B方是以现有技术成果折价入股，还是将现有技术成果转让给A方；2假如是“技术转让，应明确是“专利权转让、“专利施行许可、还是“技术机密转让？3双方能否已就合作开发的新技术成果的所有权、使用权以及利益分成问题达成一致意见？双方能否已正式签订“合作开发合同或“技术转让合同？问题3：应主要从下面几方面分析工程技术的成熟性：1关键技术成熟性分析包括采用的现有成熟关键技术、已攻克的关键技术、待研究的关键技术等；2工程采用的关键技术能否获得国家、部门或地方科技计划的支持已获得、尚未获得及计划的名称、获得支持的时间；3工程采用的关键技术能否通过技术鉴定已鉴定、尚未鉴定及鉴定单

3、位、鉴定意见、鉴定时间。案例分析二问题1：由工程执行偏差导致工程计划变更的各种诱发因素称为工程变更的内部因素。由工程目的变化导致工程计划变更的各种诱发因素称为工程变更的外部因素。问题2：“B方首付资金未能按时交付、“A方盲目确定进度目的、“A方的前期设计有疏漏、“A方编制的需求分析讲明书未能准确、全面地表达B方的实际需求、“B方自行负责的机房装修误期、“A方开发人员跳槽，属于工程变更的内部因素。“证监会要求上市公司执行新的会计制度、“B方因机构重组改变了业务流程、“B方提出增加合同审计功能、“B方行业主管部门发布了新的行业ERP施行规范，属于变更的外部因素。问题3：“A方盲目确定进度目的、“A

4、方的前期设计有疏漏、“A方开发人员跳槽，属于A方责任。由此而增加的工程经费，由A方承当。“需求分析时，B方表达不清，A方理解有误，双方沟通不够，A方编制的需求分析讲明了书未能准确、全面地表达B方的实际需求，而B方未能及时指正，属于双方责任，由此而增加的工程经费，由A、B双方协商分摊。其余各条，无论B方能否负有责任，均应承当由此而增加的工程经费。问题4：对于由内部因素引起的变更请求，变更评估的重点是确定最优变更方案。而对于外部因素引起的变更请求，变更控制委员会应重点评估变更的必要性。案例分析三问题1：1没有明晰地了解到产品的范围，导致工程后期需求的蔓延；2没有澄清模糊的工程范围，在安装服务器的问

5、题上产生异议，最终增加了未计划到的工作；3没有进行变更控制，以致于变更的结果不理想，导致反复地变更。问题2：1变更工作没有得到确认，导致工作的结果不能够被认可；2变更没有得到有效地执行。尤其当同时发生多个变更的时候，假如没有有效的控制很容易造成一些变更被忽略甚至遗漏；3未控制的变更造成系统的混乱。软件系统是一个复杂的系统，系统间很多部件都存在关联，对其中某一部分进行更改可能会牵连到其他部分，造成整个系统的问题。问题3：范围控制是范围管理中重要的工作之一，范围控制的主要目的是控制变更的结果；保证所有被请求的变更都能够得到有效的处理；协调所有同变更相关的工作、资源和交付成果，让工程始终处在被控制的

6、状态。范围控制的意义也在于此，通过范围控制，能够减少范围变更对工程造成的影响，降低风险，让工程处在可控制可跟踪的状态。案例分析四问题1：分解工程WBS的一般经过如下：1识别可交付成果及有关工作；2确定工作分解构造的构造与编排；3将工作分解构造的上层分解到下层的组成部分；4为工作分解构造组成部分提出并分配标识编码；5核实工作分解的程度能否必要且足够。问题2：创立工程WBS时需要注意下面四点：1分解出的工作是充分且必要的；2工作的独立性。即工作一旦开场，就能够在不中断的条件下完成；3工作完成度的可判定性。即能够清楚地判定工作能否已经开场，工作完成了多少，以及工作能否已完成。4工作的交付成果。即工作

7、完成后将得到什么样的成果。问题3：1在“同K企业负责人沟通后明确工程的范围中，小张进行了范围定义的工作。之后小张又编写（关于*系统第三方系统测评计划备忘录）的文档，并发给企业K负责人确认，让工程范围在各干系人中得到一致的认识。2在“将配合第三方机构进行测评的工作参加到工程WBS中，小张进行了范围控制的工作。案例分析五案例分析六案例分析七问题1：公司负责人不应该把单纯的参数模型放在成本估计上，而要根据不同的情况，采用不同的方法，否则会使成本估计产生很大的偏差。在做成本估计时建立参数模型只是其中一种方法。建立参数模型指在数学模型中运用工程特点参数来预测工程成本。建立参数模型的首要条件是建模所参考的

8、历史数据的准确性程度。但是实际情况是该工程由于需要改动的那个经过中有很多工作不是很明晰，而且这经过还会对其他5个经过产生一些影响，影响的程度也没有得到明确的界定。更重要的是，改动的流程经过占整个制造成本的36%,因而完全根据参数模型是不适宜的。问题2：由于王工程师能够准确地获得其他5个没有改动经过的具体成本信息，因而工程师在对已经明了的工程的5个经过应该采用建立参数模型法来对其进行成本估计。而对那个需要改动的经过应该采用类比估算法，这是由于当对工程的具体情况了解甚少时例如在工程的初期阶段，往往采用这种方法估算工程的总成本。问题3：成本控制就是要保证各项工作要在它们各自的预算范围内进行。成本控制

9、的基本方法是规定各部门定期上报其成本报告，再由控制部门对其进行成本审核，以保证各种支出的合法性，然后再将已经发生的成本与预算相比拟，分析其能否超支，并采取相应的措施加以弥补。有效的成本控制的关键是经常及时分析成本绩效，尽早发现成本偏差和成本执行效率，这样就能在情况变坏之前及时有效地采取措施。成本控制包括查找正、负偏差的原因，它必须与其他控制经过严密地结合起来。成本控制本质上就是监控成本的正负偏差，分析偏差产生的原因，及时采取措施以确保工程朝着有利的方向发展。主要方法有成本变更控制系统、绩效衡量分析、工程绩效审核、电脑化工具、偏差管理等。案例分析八案例分析九问题1：不明确需求就进行开发，造成工程

10、开发无法制定相应的计划。缺乏合理的工程开发计划，就无法保证工程的质量。假如由于某种客观原因造成无法在软件工程开发之前明确这个需求，需要对这个软件工程进行阶段划分，在每个阶段中明确部分需求，并制定相应的开发计划。问题2：该公司的张工应该尽可能早地明确整个软件工程的需求，制定相应的计划。张工能够把整个工程的开发阶段进行划分，对每个阶段的需求进行分析，制定计划，执行计划。B银行的赵工应该尽可能早地提出需求。赵工在需求确定后假如需要变更请求，则要和张工一起协商，然后才能调整需求，并且对工程开发计划也进行相应的调整。赵工应该和张工一起分析，明确每个工程开发阶段的需求。问题3：在工程的需求分析阶段，工程负

11、责人和需求提出者需要仔细研究整个工程的相关业务逻辑，了解整个工程的需求。在需求得到明确的前提下，制定相应的开发计划。在工程的施行阶段，需要对每个阶段的需求进行明确，制定相应的开发计划。保证了每一个阶段的开发质量，就能够保证整个工程的质量。案例分析十问题1：该软件公司在明知原有系系通通已经投入使用的情况下，没有提早分析升级的风险并告知客户，此证券公司没有制定升级计划，没有和客户一起制定风险预案。该证券公司在得知此软件公司要对他们正在使用的系统进行升级的情况下，没有主动向该软件公司了解升级可能引发的问题，没有制定必要的风险预案，以致出现问题时无法采取合理的弥补措施，造成了一些损失。问题2：现有系统

12、由于一般已经投入使用，假如对其进行升级会有一定的风险。在进行升级以前，应该对其可能包含的风险和可能带来的问题进行仔细分析和评估，并有针对性地制定风险预案和升级计划。在升级失败或者出现问题影响系统使用的情况下，应该施行风险预案来保证系统的正常使用，尽可能地减少损失。问题3：软件系统的升级和开发一样，也要制定相应的开发计划和质量保证计划。假如缺少必要的计划和质量保证措施，也会导致很大的问题。软件系统升级假如出现质量问题，带来的损失可能比开发经过中出现问题更严重。由于假如一个正在使用的系统出现问题或无法正常使用，可能带来一定的经济损失。因而我们必须像软件开发一样采取必要的质量保证手段来避免或尽可能地

13、减少经济损失。针对升级可能出现的风险，为了保险起见，需要制定一套或多套见险预案，并且进行预演，一般在出现问题时顺利采取风险预案来尽可能减少或避免产生经济损失。案例分析十一问题1：由于人力资源计划不合理或者客户在开发经过中的一些突发原因造成人力资源计划缺乏以应付工程的正常进行，工程管理人员则需要考虑增加人力资源。在组织内部由于人员紧张已经不能提供适宜的开发人员，同时公司管理层不打算增加人员经费，工程组经过研究决定招聘一批实习生，这算是一个比拟正常的解决问题的思路，但是由于是组织外的人员，所以会增加管理难度。同时由于在工程中期引入新的开发人员，也引入了新的风险：新的开发人员可能不能及时完成作为先决

14、条件的任务如培训及其他工程；新的开发人员和工程管理层之间关系不佳，导致决策缓慢，影响全局；由于在工资待遇方面和正式员工有较大差距，且缺乏鼓励措施，士气低下，降低了生产率；新的开发人员中某些人员需要更多的时间适应还不熟悉的软件工具和环境；由于是在工程中后期参加新的开发人员，需进行培训并逐步与现有成员沟通，进而使现有成员的工作效率降低；由于工程成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离工程组，影响了工程组其他成员的积极性；也许在所有新开发人员中没有找到工程急需的具有特定技能的人，等等。以上这些因素都可能对工程进度造成很坏的影响，有较大的隐患，工

15、程管理人员必须有效控制由此带来的人员风险。问题2：关于怎样教育和引导刚参加公司的新雇员这个问题，随着公司产品的多样性和复杂性变得越来越棘手，而且新参加公司人员可能分别从事不同的工作，如程序员，程序经理，客户支持工程师，针对不同的角色应该制定不同的方案。越来越多的公司都试图聘用能自学业务的人员，而不愿在培训工程、正规条例和流程或具体的产品记录上的投资。还能够通过熟练员工来教育新新雇员，这些熟练员工有经长、某些领域的专家以及正式指定的指导老师，他们除了本职工作外还要担负起教诲新雇员的工作。这种方法使得大家觉得有权学习并本人决定学什么和不学什么，使得他们在公司里的作用灵敏机动。例如对于程序经理的培训

16、：刚开场时，新雇员的任务可能是一个单独的特性，并且在直到完成为止的这段时间内，都会有人对你进行密切地指导。随后，当这种工作已做得相当熟练之后，便会在更大的特性组中从事类似的工作，但指导会少得多。一段时期后，受训者会拥有一个小工程或一个大工程的一部分。同时，程序经理还能够遭到一些正规的培训，包括一个供选修的培训工程。另外，还能够不定期举行经历推介会，届时会有经历丰富的程序经理介绍他们自已的经历。假设你是一个新进入公司的开发员，那么在头几天里，你会与经理们以及来自其他专业部门的高级人员会面，你会听到有关开发周期的一个方向性的简介，然后开发经理睬立即派给你一个单独的任务或者让你与特性小组一起工作，你

17、还可能被介绍给愿意当指导老师的高级开发员。一般而言，你开场会从事相对容易的特性编码工作，这种工作需要的时间较少并且与其它特性关联甚少，并且高级人员特性组长、领域专家、指导老师随即非常仔细地检查你编写的代码。此外对开发领域人员应该有愈加正规的定向的培训。例如，为新开发人员提供了几个为时几天的实习班，培训他们处理开发经过、产品、工具和其它专题。此外对于客户支持工程师的培训也是特别重要的。这主要是由于顾客不仅仅是购买产品，他们还要享遭到优质的售后服务。所以，训练有素的客户支持工程师对于保持公司良好形象和提高为顾客服务的能力是至关重要的。客户支持工程师不必像开发员那样有必备的职业教育，但他们必须关于本

18、公司产品怎样工作的知识，并且实际上要在某种产品上具有专业知识。新的客户支持工程师在上岗之前，接受一段时间的专门培训。培训从基本的软件产品开场，同时他们还接受交际技巧，包括怎样与顾客打交道等方面的一般性训练。作为定向培训的一部分，他们还接电话，与导师一道工作每位技术员有一位导师。在他们被分配处理客户的电话之前负责答复客户来信。问题3：对日软件外包相对技术难度不高，但是质量要求相当苛刻，外包工程失败的例子不少。下面就对日软件外包常见的一些问题进行简单讨论。1日方SE以为天经地义的地方，很多细节不会在式样书中明确写出，或者讲日方SE完全根据日本做设计的习惯写式样书，由于中日文化和思维习惯的差异，可能

19、导致中国软件开发人员对这些习惯问题理解有误。对策：积累经历，参照同类系统，提QA表确认。2在产品提交期间，对于某些BUG，可能会出现这样的争论：中方开发人员讲是由于日方的式样书没有写明确，式样书不够细致，日方设计人员讲是中方理解式样书不对，有些地方不写也应该能本人理解。对策：首先确保产品质量的交货时间；加强双方沟通；加强测试。3有的工程是日方边设计，需要中方同步开发，中方开发人员以为式样书上写多少就做多少没有写的就不做。对策：加强工程的沟通，主动提出设计考虑让日方人员确认是不是这样的意思。4中方开发人员的日语熟练程度不够。对策：加强IT日语教育，开发人员至少到达能理解日语式样书的水平；配置专业

20、的日语翻译辅助。5对于一些中方开发人员在太在意的一些细节问题，例如：字体，颜色、对齐方式等，要求不够严谨。对策：强化质量意识，建立开发和测试规范。6开发经过的规范性与开发人员的态度：日本企业的开发管理，讲究中规中矩，非常重视文档的规范化管理，力求做到“凡事必求有据；而中国企业在文档的规范化管理方面相对淡薄；日本企业工程管理对涉及的经过和文档，规定了极其严格的次序和样式，要求开发人员严格执行。而中国企业在详细执行方面，开发人员往往对这些规范和要求的遵照不够严谨。对策：完全根据客户要求执行，包括文档，如：开发进度报告、测试用例、测试报告等；加强开发经过管理，规范开发经过，引入CMM形式；加强软件质

21、量保证，如代码评审、文档审核、测试。7中国企业的开发人员比拟喜欢技术创新，在开发经过中对于一些技术问题提出本人的技术方案，可能会导致部分模块技术实现方式与整体要求有差异。对策：完全尊重日本客户的文化和管理形式，积极提出技术建议；对于有要求遵照Sample代码或对详细技术实现细节有严格要求的，开发人员必须严格遵循，不允许采用自已的技术实现；加强代码审查codereview。8一些日本企业与中国企业的SE共同介入设计或沟通的工程。对策：在日本的合作伙伴企业派遣SE到工程现场进行设计；派遣中国SE到日本介入设计，设计完成后带回中国开发；日本企业短期派遣SE到中国。9软件外包知识产权保护与客户保密问题

22、。对策：严格保护日本客户商业机密和知识产权；中国企业与日本企业签订保密协议；中国企业与开发人员签订保密协议。10日本企业对中国企业开发进度的把握。对策：根据日本企业工程管理要求报告工程进度；分阶段交付。11远程协同合作开发的沟通手段和方式。对策：实时消息/语音/视频沟通，例如：MSNMessenger,YahooMesenger、视频会议系统、远程控制、远程协助、远程调试；Email、FTP；互相人才派遣，人才沟通。案例分析十二问题1：在一个软件产品整个的生命周期中，软件产品发布之后便进入漫长的软件维护阶段，而对于一些行业软件更是如此，后期的软件维护是非常重要的一个环节。在维护经过中通常要涉及

23、到开发人员在现场对代码的维护，对数据和设备的维护，还可能需要根据用户要求对软件做相应的修改，有些可能涉及到重新开发或者发布新版本。当然后期维护可以能在一段时间内将会带来相当丰厚的收入，保持良好的客户满意度也将变得非常重要。现场开发人员不仅仅是完成维护工作，而且更多的是需要通过和用户沟通了解用户在使用软件经过中碰到的一些问题，帮助用户正确认识软件维护的目的，得到用户的支持和协助，使软件最大程度地帮助用户提高其工作效率，创造经济价值，在用户中建立起良好的口碑。同时现场人员也应该积极采集和整理用户提出的一些问题，擅长总结和考虑，将这些问题反应给公司总部，将一些用户期望的功能发布在下一个版本当中，并且

24、完善旧有版本中的缺陷。从这个角色出发，现场人员在一定程度上扮演了市场人员的角色，并且是接触最前线的用户，他们在做维护的同时，能够体会到用户使用软件的感受，进而得到最准确的市场信息，同时现场开发人员又是公司形象代表，每次现场工作都代表着公司的形象，所以公司需要设置专门的培训内容用于训练员工在外怎样保持公司的良好形象同时做好宣传工作。问题2：在软件开发经过中，团队协同开发，很容易出现软件版本管理不善带来的软件系统故障。代码经常会被新的版本替换而使某些开发人员的工作成果丢失。这样不仅会打击开发人员的工作热情，也不利于责任的明确。在现场开发的经过中，由于缺乏监督和管理，这种情况会愈加普遍，如工程现场为

25、应急而擅自更改软件代码，而经常没有将更改纳入统一的版本管理，甚至只是开发人员的个人意见，并没有通过工程管理层的同意，这种处理方法就很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，进而造成系统故障的反复出现。此外，由于现场维护一般都会涉及到大量用户数据，程序的修改不仅会影响到软件功能，更可能产生很多垃圾数据，这些都是用户所不希望看到的，所以对现场代码的更改要严格控制，并且及时和总部版本保持一致，如微软公司出品的版本管理工具VSS就能够做到WEB访问，通过有效配置能够有效控制现场版本。案例分析十三问题1：作为为工程经理面对工程问题应从更深层次上考虑，要遵循工程管理原理，而不是

26、浮于事务本身。工程经理张强在工程开场时就应制定具体的工程管理计划，应先考虑好可能要进行的工程沟通并加以执行，而不是在出现问题时才去弥补。沟通不完好的工程经过，大多数会顾此失彼，进一步导致工程问题的发生。一言纳之，张强的问题关键是没有计划，假如按软件经过能力成熟度模型CMM评价，该工程组织只能是初始级。造成工程问题的原因有下面几点：1沟通管理计划没有或不够具体；2没有重视部门间横向沟通；3与客户沟通不到位，客户需求未能准确把握。问题2：要施行高效的会议，首先是在会议前要有计划，通常会议计划来源于工程沟通管理计划，准备阶段通常按如下顺序施行：1决定会议的宗旨和类型；2分析会议的因果：本次会议同本部

27、门目的的关系？本次会议同上、下次会议的关系？什么事可能会影响对本次会议的兴趣？3明确涉及的、受影响的人和事；4制定会议成果讲明；5决定要讨论的主题；6决定会议角色分配；7决定会场布置；8计划会议议程表：非正式议程表、正式议程表5W和1H。在会议经过中，有效地主持或介入会议则要注意按会议步骤逐项讨论议程，总结决定。在会议中应鼓励与会者积极介入，制止消极行为和不良意见。陈述信息要自信，态度要直接、坦率。对整个会议要注意把握时间，记录重要备忘事项和决定。会议跟踪也是一项重要工作。应自上而下逐级向必要的非与会者传达会议信息,制定行动计划完成分派的工作,确定计划以跟踪会上决定的工作进度。制定下次会议议程

28、。问题3：工程经理应明确自已的工作职责范围，对工程相关资源的安排在制定沟通管理计划时应有具体的描绘。对工程进度、工程成果应及时与公司高层领导或干系人沟通。工程组织应建有基于Internet的软件开发沟通平台，进而能调度、跟踪解决工程现场问题。工程经理和工程人员应通过各种方式与客户多作沟通，如QQ，MSN、电话、电子邮件等。适宜的组合是工程团队中至少一人是客户方的代表，工程初始时团队成员应与客户方的软件使用人员经常地进行业务方面的沟通。案例分析十四问题1：工程经理刘克勤的工程沟通管理是成功的。对于工程管理，除了把握必备的工程基本方法和管理工具如计划制定、预算编制等，对工程背景和目的有清楚的理解和

29、认识外，最重要的一点就是与人交往的技巧。成功工程经理和失败工程经理的最大差异，可能就在于怎样跟人打交道，怎样跟客户打交道，怎样跟公司领导打交道，怎样跟工程成员打交道。问题2：工程经理刘克勤在工程经过中，团队建设相当成功。他为团队成员间建立纽带，并通过各种行为加强信任和消除团队合作的障碍。其中最值的借鉴是尊重团队成员、采用多种方法沟通、进行深度对话。案例分析十五问题1：我们都知道，信息应用系统的变更尤其频繁，而频繁的变更必然影响到信息工程工程的三大目的。通常与客户接触最多的是市场部工程经理，引导客户需求对工程经理就非常关键，工程经理引导得好，工程的开发就会非常顺利，反之，就会使工程组疲于奔命。该

30、工程中，市场部李工不断地提出新的需求时，张工“来者不拒、疲于奔命、不停地更新工程计划，导致工程范围无法确定，工期和成本不可控制，团队成员工作目的也不明确。风险应对策略一般分为四种：回避、转嫁、减轻、接受。回避风险指改变工程计划，以排除风险或条件，或者保护工程目的，使其不受影响。转嫁风险指设法将风险的后果连同应对的责任转移到第三方身上。减微风险指设法把不利的风险事件的概率或后果降低至一个可接受的临界值。采取此项技术表明工程班子已经决定不打算为处置某项风险而改变工程计划，或者表明他们无法找到任何其他应对良策。该工程已经发生了严重的需求风险，张工采取弥补措施应该包括减轻和接受。减微风险的应对措施应能

31、设法减微风险的影响，其着眼点应放在影响程度最大的连接点上，张工应该与李工积极地沟通和会谈，使他们明白本期工程的重要意义，并承诺本期工程不是交钥匙工程，可为系统升级和扩容留有扩展接口，将来新的需求能够通过后续工程逐步开发实现,李工同意本期工程只实现大家最为关注的功能指标和性能指标。最常见的接受风险的应对措施为预留应急储备,或者简称储备,包括为已知风险留出时间、资金或资源。为接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。张工应该申请启动工程风险储备金，通过增加资源成本、付出额外劳动使得工程回到正轨。问题2：在设计系统架构时，工程管理经历缺乏、关键技术不明确、系统扩展性不佳、产品兼

32、容性有问题、软件版本管理混乱等，均可能是影响系统正常运行的潜在隐患。在本期工程的机房设备平面设计中，张工团队起初大部分机架式的小型机集中摆放在一片较小区域内，从外表上看，提高了机房平面空间的使用率，但是由于未充分考虑到设备散热因素，造成了该区域的机房专用空调负荷过重而屡次宕机。后来，张工聘请了具备通信设计资质的专家负责工程设计，从机房空调、电源、布线、承重、消防等各个方面进行了详尽的勘察和设计。透过专家编制的工程设计，张工团队能够细致地了解有关机房设计的技术内涵和外延，并通过工程设计评审机制，一方面确立了工程设计的权威或指导作用，另一方面获得了专家们的可靠技术承诺，实现了工程设计风险的良性转移

33、。问题3：针对该工程的风险管理，提出下面几点建议作为参考。1推广工程管理理念。工程团队主动向工程干系人及周边人介绍工程管理的先进理念和方法，处处营造工程管理的气氛。团队成员积极参加工程管理培训，将所学用于工作和生活之中，并加以总结和升华，提升自已的竞争力。2有效管理工程风险。工程经理自始至终负责制定工程风险管理计划和风险应对计划，并在每次工程例会时重点讨论工程风险，对风险发生概率和影响程度进行评估，由定性分析到定量分析，制定有效的预防、减轻或促进风险时机的应对方案。3多渠道沟通和会谈。保证多渠道沟通机制畅通，采用横向沟通方式和纵向沟通方式。灵敏使用会谈手段和技巧，采集和把握足够的有用信息，确保

34、具有主动的话语权。处理好与工程干系人的关系，互相配合，实现共赢。4争取高层领导支持。高层领导对于工程成败至关重要。高层领导把握工程团队所需的任何资源。通过邀请高层领导参加工程启动会、关键里程碑发布会、工程完工总结会等形式，既能够使高层领导关注工程、了解工程和推动工程，又能够提升工程及工程团队地位，有利于工程成功，有利于个人职业生涯发展。案例分析十六问题1：对于紧急重要风险1措施如下：保障工程进度要求，确保NSS、BSS软件督导的调测气力；及时沟通，避免由于传输原因耽误进度；确保工程质量，督导、督察人员将对合作方施工人员进行有效的指导和对工程质量进行有效监控。工程施行日报制，工程经理每日对省市公

35、司网络部进行工程汇报，对于由于用户原因造成的进度耽误明确指出来，分清双方责任。对于紧急重要风险2措施如下：公司研发中心MSC、BSC、BTS人员现场进行信令跟踪，对切换不成功的原因进行定位，在A公司成立专门的小组，协助现场进行问题定位。假如是我方原因，中研相关部门进行程序修改，假如是对方原因则提供相关的信令分析文件，由工程经理和中研人员共同向局方解释，要求爱立信修改相关程序。计划工程的不同阶段分别举行三次移动公司、A公司、爱立信双频技术切换沟通，讨论双方参数设置，移动公司负责总体监控双方的施行工作；在城市郊区话务量较小地区，开通5个基站进行单站以及双频配合测试，为全网开通积累经历。对于紧急重要

36、风险3措施如下：需要找到集团公司（关于建设中国移动1800M双频网的若干意见）文件原件，进行仔细分析，寻求解决方法。加强省公司高层的工作，通过客户关系工作期望给A公司工作上提供支持。对此事向公司总部反映，看看能否通过北京分部的工作使移动集团公司有所松动或是有其他变通方法。对于紧急重要风险4措施如下：公司对城市1800M频段分地区进行测试，摸清干扰信号频段，通过调整频率规划躲避部分干扰，争取多开通基站。了解目前使用1800M单位情况。协助移动与其进行交涉，争取占用单位能进行频率调整，解决1800M干扰问题。将此事汇报到移动公司高层，通过其与无委高层的沟通解决频占费的问题，并通过无委清理被其他单位

37、占用的1800M频段。问题2：该工程还存在下面几个问题：1A公司将竞争对手的竞争风险分析不全面。A公司仅仅是从技术上进行了风险防备，对于其他方面A公司却没有任何措施。2对于1800M干扰的风险问题，A公司制定的计划太松懈，没有引起足够的重视。3对于1800M网络的建设目的A公司理解有些偏差。调整的风险应对计划如下：1采集竞争对手问题，针对此提出A公司的解决方案。2联合市场部，加强高层工程推动，突出A公司网络设备特点，建议用户在省会城市引入竞争，尽快开场1800M工程建设。3加强干扰解决推动监控，加快进度，工程经理进行全程跟踪；4对用户进行双频网建设思路进行新的引导，列举A公司在全国的双频网应用

38、，列举A公司开通基站的指标数据。问题3：1进行调研，确定流动原因。2在工程开场前，把缓解这些流动原因的工作列入风险管理计划。3工程开场时，做好计划一旦人员离开时便可执行，以确保人员离开后工程仍能继续进行。4制定文档标准，并建立一种机制，保证文档及时产生。5对所有工作进行细致详审，使更多人能够按计划进度完成自已的工作。6为每个关键性技术培养后备人员。案例分析十七问题1：1对省内省外投标人提出了不同的资格要求。公开招标应该平等地对待所有投标人。2乙单位提交保证金晚于规定时间,投标保证金是投标书的组成部分,应在投标截止日前提交。3招标书发出时间为2004年12月15日，而投标截止时间为2004年12

39、月30日，中间时间为15日，有违招投标法所要求的20日。4投标截止时间与开标时间不同，（招投标法）规定开标应当在投标文件截止时间的同一时间公开进行。5不应该是招标办主持开标会。开标会应由招标人或其代理人主持。6重新招标时候评委应为5人以上单数。案例分析十八问题1：企业A向第三方监理公司C泄露承建单位IT公司B的技术机密，违背合同签订时保密约定要求，该措施不妥。问题2：工程不可分割，属于一个整体，未经甲方企业A同意，此类工程不应分包。而公司B却和公司D签订此工程的分包合同，很显然，该合同无效。问题3：企业A应该将公司B未付给公司D的所有款项扣除保留金付给公司D，并从应付给公司B的任何款项中如数扣

40、回。案例分析十九知识产权是企业珍贵的无形资产，也是企业能够持续发展的前提之一，某软件公司A公司从事管理系统软件开发，程序员张某参加了A公司开发管理系统软件的工作，后辞职到另一个公司B公司任职。于是工程负责人将张某在该软件作品上的开发者署名更改为别人。问题1：根据（计算机软件保护条例）的规定，自然人的软件著作权的保护期限为自然人终生及死亡后50年.问题2：知识产权一般都具有法定的保护期限，一旦保护期限届满，权利将自行终止，成为社会公众能够自由使用的知识。商业机密受法律保护的期限是不确定的，一旦为公众所周知，即成为公众能够自由使用的知识。问题3：甲、乙两人同时在同一时间就同样的发明创造提交了专利申请,专利局将分别向各申请人通报有关情况,并对两件申请都不授予专利权。这种情况能否合理？对于同一时间申请专利的情况，专利局可分别向各申请人通报有关情况，请他们自已协商解决这一问题，假如双方协商不成的，则两件申请都不授予专利权。问题4：该工程负责人张某侵犯了开发者张某的身份权及署名权。问题5：目前，我国已构成了相对完备的知识产权保护的法律体系，对软件构成一种综合性的法律保护，如源程序和设计文档作为软件的表现形式受（中华人民共和国著作权法）保护，同时作为技术机密又受（中华人民共和国反不正当竞争法）。