软件项目管理案例分析20题

《软件项目管理案例分析20题》由会员分享，可在线阅读，更多相关《软件项目管理案例分析20题（11页珍藏版）》请在装配图网上搜索。

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

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

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

4、管部门发布了新的行业ERP实施规范”，属于变更的 外部因素。问题3：“A方盲目确定进度目标”、“A方的前期设计有疏漏”、“A方开发人员跳槽”，属于 A方责任。由此而增加的项目经费，由A方承担。“需求分析时，B方表达不清，A方理解 有误，双方沟通不够，A方编制的需求分析说明了书未能准确、全面地表达B方的实际需 求，而B方未能及时指正”，属于双方责任，由此而增加的项目经费，由A、B双方协商分摊。其余各条，无论B方是否负有责任，均应承担由此而增加的项目经费。问题4：对于由内部因素引起的变更请求，变更评估的重点是确定最优变更方案。而对于外部 因素引起的变更请求，变更控制委员会应重点评估变更的必要性。案

5、例分析三问题1：（1）没有清晰地了解到产品的范围，导致项目后期需求的蔓延；（2）没有澄清模糊的项目范围，在安装服务器的问题上产生异议，最终增加了未计划到 的工作；（3）没有进行变更控制，以至于变更的结果不理想，导致反复地变更。问题2：（1）变更工作没有得到确认，导致工作的结果不能够被认可；（2）变更没有得到有效地执行。尤其当同时发生多个变更的时候，如果没有有效的控制 很容易造成一些变更被忽略甚至遗漏；（3）未控制的变更造成系统的混乱。软件系统是一个复杂的系统，系统间很多部件都存 在关联，对其中某一部分进行更改可能会牵连到其他部分，造成整个系统的问题。问题3：范围控制是范围管理中重要的工作之一，

6、范围控制的主要目的是控制变更的结果；保 证所有被请求的变更都可以得到有效的处理;协调所有同变更相关的工作、资源和交付成果， 让项目始终处在被控制的状态。范围控制的意义也在于此，通过范围控制，可以减少范围变 更对项目造成的影响，降低风险，让项目处在可控制可跟踪的状态。案例分析四问题1：分解项目WBS的一般过程如下：（1）识别可交付成果及有关工作；（2）确定工作分解结构的结构与编排；（3）将工作分解结构的上层分解到下层的组成部分；（4）为工作分解结构组成部分提出并分配标识编码；（5）核实工作分解的程度是否必要且足够。问题2：创建项目WBS时需要注意以下四点：（1）分解出的工作是充分且必要的；（2）

7、工作的独立性。即工作一旦开始，就可以在不中断的条件下完成；（3）工作完成度的可判断性。即可以清楚地判断工作是否已经开始，工作完成了多少， 以及工作是否已完成。（4）工作的交付成果。即工作完成后将得到什么样的成果。问题3：（1）在“同K企业负责人沟通后明确项目的范围”中，小张进行了范围定义的工作。之 后小张又编写关于*系统第三方系统测评计划备忘录的文档，并发给企业K负 责人确认，让项目范围在各干系人中得到一致的认识。（2）在“将配合第三方机构进行测评的工作加入到项目WBS ”中，小张进行了范围控制 的工作。案例分析五案例分析六案例分析七问题1:公司负责人不应该把单纯的参数模型放在成本估计上，而要

8、根据不同的情况，采用不 同的方法，否则会使成本估计产生很大的偏差。在做成本估计时建立参数模型只是其中一种方法。建立参数模型指在数学模型中运用 项目特点（参数）来预测项目成本。建立参数模型的首要条件是建模所参考的历史数据的精 确性程度。但是实际情况是该项目由于需要改动的那个过程中有很多工作不是很清晰，而且这过 程还会对其他5个过程产生一些影响，影响的程度也没有得到明确的界定。更重要的是，改 动的流程过程占整个制造成本的36%，因此完全按照参数模型是不合适的。问题2：由于王工程师能够准确地获得其他5个没有改动过程的详细成本信息，因此工程师在 对已经明了的项目的5个过程应该采用建立参数模型法来对其进

9、行成本估计。而对那个需要改动的过程应该采用类比估算法，这是由于当对项目的详细情况了解甚 少时（例如在项目的初期阶段），往往采用这种方法估算项目的总成本。问题3：成本控制就是要保证各项工作要在它们各自的预算范围内进行。成本控制的基本方法 是规定各部门定期上报其成本报告，再由控制部门对其进行成本审核，以保证各种支出的合 法性，然后再将已经发生的成本与预算相比较，分析其是否超支，并采取相应的措施加以弥 补。有效的成本控制的关键是经常及时分析成本绩效，尽早发现成本偏差和成本执行效率， 这样就能在情况变坏之前及时有效地采取措施。成本控制包括查找正、负偏差的原因，它必须与其他控制过程紧密地结合起来。成本

10、控制实质上就是监控成本的正负偏差，分析偏差产生的原因，及时采取措施以确保项目朝着 有利的方向发展。主要方法有成本变更控制系统、绩效衡量分析、项目绩效审核、电脑化工 具、偏差管理等。案例分析八案例分析九问题1：不明确需求就进行开发，造成项目开发无法制定相应的计划。缺乏合理的项目开发计 划，就无法保证项目的质量。如果由于某种客观原因造成无法在软件项目开发之前明确这个需求，需要对这个软件 项目进行阶段划分，在每个阶段中明确部分需求，并制定相应的开发计划。问题2：该公司的张工应该尽可能早地明确整个软件项目的需求，制定相应的计划。张工可以把整个项目的开发阶段进行划分，对每个阶段的需求进行分析，制定计划，

11、 执行计划。B银行的赵工应该尽可能早地提出需求。赵工在需求确定后如果需要变更请求，则要和张工一起协商，然后才能调整需求，并 且对项目开发计划也进行相应的调整。赵工应该和张工一起分析，明确每个项目开发阶段的 需求。问题3：在项目的需求分析阶段，项目负责人和需求提出者需要仔细研究整个项目的相关业务 逻辑，了解整个项目的需求。在需求得到明确的前提下，制定相应的开发计划。在项目的实施阶段，需要对每个阶段的需求进行明确，制定相应的开发计划。保证了 每一个阶段的开发质量，就能够保证整个项目的质量。案例分析十问题1：该软件公司在明知原有系系统统已经投入使用的情况下，没有提前分析升级的风险并 告知客户，此证券

12、公司没有制定升级计划，没有和客户一起制定风险预案。该证券公司在得知此软件公司要对他们正在使用的系统进行升级的情况下，没有主动 向该软件公司了解升级可能引发的问题，没有制定必要的风险预案，以致出现问题时无法采 取合理的补救措施，造成了一些损失。问题2：现有系统由于一般已经投入使用，如果对其进行升级会有一定的风险。在进行升级以 前，应该对其可能包含的风险和可能带来的问题进行仔细分析和评估，并有针对性地制定风 险预案和升级计划。在升级失败或者出现问题影响系统使用的情况下，应该实施风险预案来 保证系统的正常使用，尽可能地减少损失。问题3：软件系统的升级和开发一样，也要制定相应的开发计划和质量保证计划。

13、如果缺少必 要的计划和质量保证措施，也会导致很大的问题。软件系统升级如果出现质量问题，带来的 损失可能比开发过程中出现问题更严重。因为如果一个正在使用的系统出现问题或无法正常 使用，可能带来一定的经济损失。因此我们必须像软件开发一样采取必要的质量保证手段来 避免或尽可能地减少经济损失。针对升级可能出现的风险，为了保险起见，需要制定一套或 多套见险预案，并且进行预演，一般在出现问题时顺利采取风险预案来尽可能减少或避免产 生经济损失。案例分析十一问题1：由于人力资源计划不合理或者客户在开发过程中的一些突发原因造成人力资源计划不 足以应付项目的正常进行，项目管理人员则需要考虑增加人力资源。在组织内部

14、因为人员紧 张已经不能提供合适的开发人员，同时公司管理层不打算增加人员经费，项目组经过研究决 定招聘一批实习生，这算是一个比较正常的解决问题的思路，但是由于是组织外的人员，所 以会增加管理难度。同时由于在项目中期引入新的开发人员，也引入了新的风险：新的开发 人员可能不能及时完成作为先决条件的任务（如培训及其他项目）；新的开发人员和项目管 理层之间关系不佳，导致决策缓慢，影响全局；由于在工资待遇方面和正式员工有较大差距， 且缺乏激励措施，士气低下，降低了生产率；新的开发人员中某些人员需要更多的时间适应 还不熟悉的软件工具和环境；因为是在项目中后期加入新的开发人员，需进行培训并逐渐与 现有成员沟通

15、，从而使现有成员的工作效率降低；由于项目成员之间发生冲突，导致沟通不 畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响 了项目组其他成员的积极性;也许在所有新开发人员中没有找到项目急需的具有特定技能的 人，等等。以上这些因素都可能对项目进度造成很坏的影响，有较大的隐患，项目管理人员 必须有效控制由此带来的人员风险。问题2：关于如何教育和引导刚加入公司的新雇员这个问题，随着公司产品的多样性和复杂性 变得越来越棘手，而且新加入公司人员可能分别从事不同的工作，如程序员，程序经理，客 户支持工程师，针对不同的角色应该制定不同的方案。越来越多的公司都试图聘用能自学业务的人

16、员，而不愿在培训项目、正规条例和流程 或详细的产品记录上的投资。还可以通过熟练员工来教育新新雇员，这些熟练员工有经长、 某些领域的专家以及正式指定的指导教师，他们除了本职工作外还要担负起教导新雇员的工 作。这种方法使得大家觉得有权学习并自己决定学什么和不学什么，使得他们在公司里的作 用灵活机动。例如对于程序经理的培训：刚开始时，新雇员的任务可能是一个单独的特性， 并且在直到完成为止的这段时间内，都会有人对你进行密切地指导。随后，当这种工作已做 得相当熟练之后，便会在更大的特性组中从事类似的工作，但指导会少得多。一段时期后， 受训者会拥有一个小项目或一个大项目的一部分。同时，程序经理还可以受到一

17、些正规的培 训，包括一个供选修的培训项目。另外，还可以不定期举行经验推介会，届时会有经验丰富 的程序经理介绍他们自已的经验。假设你是一个新进入公司的开发员，那么在头几天里，你 会与经理们以及来自其他专业部门的高级人员会面，你会听到有关开发周期的一个方向性的 简介，然后开发经理会立即派给你一个单独的任务或者让你与特性小组一起工作，你还可能 被介绍给愿意当指导教师的高级开发员。一般而言，你开始会从事相对容易的特性编码工作，这种工作需要的时间较少并且与 其它特性关联甚少，并且高级人员（特性组长、领域专家、指导教师）随即非常仔细地检查 你编写的代码。此外对开发领域人员应该有更加正规的定向的培训。例如，

18、为新开发人员提 供了几个为时几天的实习班，培训他们处理开发过程、产品、工具和其它专题。此外对于客 户支持工程师的培训也是十分重要的。这主要是因为顾客不仅仅是购买产品，他们还要享受 到优质的售后服务。所以，训练有素的客户支持工程师对于保持公司良好形象和提高为顾客 服务的能力是至关重要的。客户支持工程师不必像开发员那样有必备的职业教育，但他们必 须关于本公司产品如何工作的知识，并且实际上要在某种产品上具有专业知识。新的客户支 持工程师在上岗之前，接受一段时间的专门培训。培训从基本的软件产品开始，同时他们还 接受交际技巧，包括如何与顾客打交道等方面的一般性训练。作为定向培训的一部分，他们 还接电话，

19、与导师一道工作（每位技术员有一位导师）。在他们被分配处理客户的电话之前 负责答复客户来信。问题3：对日软件外包相对技术难度不高，但是质量要求相当苛刻，外包项目失败的例子不少。 以下就对日软件外包常见的一些问题进行简单探讨。（1）日方SE认为理所当然的地方，很多细节不会在式样书中明确写出，或者说日方SE 完全按照日本做设计的习惯写式样书，由于中日文化和思维习惯的差异，可能导致中国 软件开发人员对这些习惯问题理解有误。对策：积累经验，参照同类系统，提QA表确认。（2）在产品提交期间，对于某些BUG，可能会出现这样的争执：中方开发人员说是由 于日方的式样书没有写明确，式样书不够细致，日方设计人员说是

20、中方理解式样书不对， 有些地方不写也应该能自己理解。对策：首先确保产品质量的交货时间；加强双方交流；加强测试。（3）有的项目是日方边设计，需要中方同步开发，中方开发人员认为式样书上写多少 就做多少没有写的就不做。对策：加强项目的交流，主动提出设计思考让日方人员确认是不是这样的意思。（4）中方开发人员的日语熟练程度不够。对策：加强IT日语教育，开发人员至少达到能理解日语式样书的水平；配置专业的日语翻 译辅助。（5）对于一些中方开发人员在太在意的一些细节问题，例如：字体，颜色、对齐方式等，要求不够严谨。对策：强化质量意识，建立开发和测试规范。(6) 开发过程的规范性与开发人员的态度：日本企业的开发

21、管理，讲究中规中矩，非常 重视文档的规范化管理，力求做到“凡事必求有据”；而中国企业在文档的规范化管 理方面相对淡薄；日本企业项目管理对涉及的过程和文档，规定了极其严格的次序 和样式，要求开发人员严格执行。而中国企业在具体执行方面，开发人员往往对这 些规范和要求的遵照不够严谨。对策：完全按照客户要求执行，包括文档，如：开发进度报告、测试用例、测试报告等；加 强开发过程管理，规范开发过程，引ACMM模式；加强软件质量保证，如代码评审、文档 审核、测试。(7) 中国企业的开发人员比较喜欢技术创新，在开发过程中对于一些技术问题提出自己 的技术方案，可能会导致部分模块技术实现方式与整体要求有差异。对策

22、：完全尊重日本客户的文化和管理模式，积极提出技术建议；对于有要求遵照Sample 代码或对具体技术实现细节有严格要求的，开发人员必须严格遵循，不允许采用自已的技术 实现；加强代码审查(code review)o(8) 一些日本企业与中国企业的SE共同参与设计或交流的项目。对策：在日本的合作伙伴企业派遣SE到项目现场进行设计；派遣中国SE到日本参与设计， 设计完成后带回中国开发；日本企业短期派遣SE到中国。(9) 软件外包知识产权保护与客户保密问题。对策：严格保护日本客户商业秘密和知识产权；中国企业与日本企业签订保密协议；中国企 业与开发人员签订保密协议。(10) 日本企业对中国企业开发进度的掌

23、握。对策：按照日本企业项目管理要求报告项目进度；分阶段交付。(11) 远程协同合作开发的交流手段和方式。对策：实时消息/语音/视频交流，例如：MSN Messenger, Yahoo Mesenger、视频会议系统、 远程控制、远程协助、远程调试；Email、FTP；相互人才派遣，人才交流。案例分析十二问题1：在一个软件产品整个的生命周期中，软件产品发布之后便进入漫长的软件维护阶段， 而对于一些行业软件更是如此，后期的软件维护是非常重要的一个环节。在维护过程中通常 要涉及到开发人员在现场对代码的维护，对数据和设备的维护，还可能需要根据用户要求对 软件做相应的修改，有些可能涉及到重新开发或者发布

24、新版本。当然后期维护也可能在一段 时间内将会带来相当丰厚的收入，保持良好的客户满意度也将变得非常重要。现场开发人员 不仅仅是完成维护工作，而且更多的是需要通过和用户沟通了解用户在使用软件过程中遇到 的一些问题，帮助用户正确认识软件维护的目的，得到用户的支持和协助，使软件最大程度 地帮助用户提高其工作效率，创造经济价值，在用户中建立起良好的口碑。同时现场人员也 应该积极收集和整理用户提出的一些问题，善于总结和思考，将这些问题反馈给公司总部， 将一些用户期望的功能发布在下一个版本当中，并且完善旧有版本中的缺陷。从这个角色出 发，现场人员在一定程度上扮演了市场人员的角色，并且是接触最前线的用户，他们

25、在做维 护的同时，可以体会到用户使用软件的感受，从而得到最准确的市场信息，同时现场开发人 员又是公司形象代表，每次现场工作都代表着公司的形象，所以公司需要设置专门的培训内 容用于训练员工在外如何保持公司的良好形象同时做好宣传工作。问题2：在软件开发过程中，团队协同开发，很容易出现软件版本管理不善带来的软件系统故障。 代码经常会被新的版本替换而使某些开发人员的工作成果丢失。这样不仅会打击开发人员的 工作热情，也不利于责任的明确。在现场开发的过程中，由于缺乏监督和管理，这种情况会 更加普遍，如项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理， 甚至只是开发人员的个人意见，并没有

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

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

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

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

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

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

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

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

34、了专家们的可靠技术承诺，实现了工程设计风险的良 性转移。问题3：针对该项目的风险管理，提出以下几点建议作为参考。（1）推广项目管理理念。项目团队主动向项目干系人及周边人介绍项目管理的先 进理念和方法，处处营造项目管理的氛围。团队成员积极参加项目管理培训， 将所学用于工作和生活之中，并加以总结和升华，提升自已的竞争力。（2）有效管理项目风险。项目经理自始至终负责制定项目风险管理计划和风险应 对计划，并在每次项目例会时重点讨论项目风险，对风险发生概率和影响程 度进行评估，由定性分析到定量分析，制定有效的预防、减轻或促进风险（机 会）的应对方案。（3）多渠道沟通和谈判。保证多渠道沟通机制畅通，采用横

35、向沟通方式和纵向沟 通方式。灵活使用谈判手段和技巧，收集和掌握足够的有用信息，确保具有 主动的话语权。处理好与项目干系人的关系，相互配合，实现共赢。（4）争取高层领导支持。高层领导对于项目成败至关重要。高层领导掌握项目团 队所需的任何资源。通过邀请高层领导参加项目启动会、关键里程碑发布会、 项目完工总结会等形式，既可以使高层领导关注项目、了解项目和推动项目， 又可以提升项目及项目团队地位，有利于项目成功，有利于个人职业生涯发 展。案例分析十六问题1：对于紧急重要风险1措施如下：保障工程进度要求，确保NSS、BSS软件督导的 调测力量；及时沟通，避免因为传输原因耽搁进度；确保工程质量，督导、督察

36、人员将 对合作方施工人员进行有效的指导和对工程质量进行有效监控。项目实施日报制，项目 经理每日对省市公司网络部进行工程汇报，对于因为用户原因造成的进度耽搁明确指出 来，分清双方责任。对于紧急重要风险2措施如下：公司研发中心MSC、BSC、BTS人员现场进行信 令跟踪，对切换不成功的原因进行定位，在A公司成立专门的小组，协助现场进行问 题定位。如果是我方原因，中研相关部门进行程序修改，如果是对方原因则提供相关的 信令分析文件，由项目经理和中研人员共同向局方解释，要求爱立信修改相关程序。计 划工程的不同阶段分别举行三次移动公司、A公司、爱立信双频技术切换交流，讨论双 方参数设置，移动公司负责总体监

37、控双方的实施工作；在城市郊区话务量较小地区，开 通5个基站进行单站以及双频配合测试，为全网开通积累经验。对于紧急重要风险3措施如下：需要找到集团公司关于建设中国移动1800M双 频网的若干意见文件原件，进行仔细分析，寻求解决方法。加强省公司高层的工作， 通过客户关系工作期望给A公司工作上提供支持。对此事向公司总部反映，看看是否 通过北京分部的工作使移动集团公司有所松动或是有其他变通方法。对于紧急重要风险4措施如下：公司对城市1800M频段分地区进行测试，摸清干 扰信号频段，通过调整频率规划规避部分干扰，争取多开通基站。了解目前使用1800M 单位情况。协助移动与其进行交涉，争取占用单位能进行频

38、率调整，解决1800M干扰 问题。将此事汇报到移动公司高层，通过其与无委高层的沟通解决频占费的问题，并通 过无委清理被其他单位占用的1800M频段。问题2：该项目还存在以下几个问题：（1）A公司将竞争对手的竞争风险分析不全面。A公司仅仅是从技术上进行了风险 防范，对于其他方面A公司却没有任何措施。（2）对于1800M干扰的风险问题，A公司制定的计划太松散，没有引起足够的重视。（3）对于1800M网络的建设目的A公司理解有些偏差。调整的风险应对计划如下：（1）收集竞争对手问题，针对此提出A公司的解决方案。（2）联合市场部，加强高层项目推动，突出A公司网络设备特点，建议用户在省会 城市引入竞争，尽

39、快开始1800M工程建设。（3）加强干扰解决推动监控，加快进度，项目经理进行全程跟踪；（4）对用户进行双频网建设思路进行新的引导，列举A公司在全国的双频网应用， 列举A公司开通基站的指标数据。问题3：（1）进行调研，确定流动原因。（2）在项目开始前，把缓解这些流动原因的工作列入风险管理计划。（3）项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能 继续进行。（4）制定文档标准，并建立一种机制，保证文档及时产生。（5）对所有工作进行细致详审，使更多人能够按计划进度完成自已的工作。（6）为每个关键性技术培养后备人员。案例分析十七问题1：（1）对省内省外投标人提出了不同的资格要求。

40、公开招标应该平等地对待所有投标 人。（2）乙单位提交保证金晚于规定时间，投标保证金是投标书的组成部分，应在投标截 止日前提交。（3） 招标书发出时间为2004年12月15日，而投标截止时间为2004年12月30日， 中间时间为15日，有违招投标法所要求的20日。（4）投标截止时间与开标时间不同，招投标法规定开标应当在投标文件截止时间 的同一时间公开进行。（5）不应该是招标办主持开标会。开标会应由招标人或其代理人主持。（6）重新招标时候评委应为5人以上单数。案例分析十八问题1：企业A向第三方（监理公司C）泄露承建单位（IT公司B）的技术机密，违反合 同签订时保密约定要求，该措施不妥。问题2：项目

41、不可分割，属于一个整体，未经甲方企业A同意，此类项目不应分包。而公 司B却和公司D签订此项目的分包合同，很显然，该合同无效。问题3：企业A应该将公司B未付给公司D的所有款项（扣除保留金）付给公司D，并从 应付给公司B的任何款项中如数扣回。案例分析十九知识产权是企业宝贵的无形资产，也是企业能够持续发展的前提之一，某软件公司 A公司从事管理系统软件开发，程序员张某参加了 A公司开发管理系统软件的工作， 后辞职到另一个公司B公司任职。于是项目负责人将张某在该软件作品上的开发者署 名更改为他人。问题1：按照计算机软件保护条例的规定，自然人的软件著作权的保护期限为自然人终 生及死亡后50年.问题2：知识

42、产权一般都具有法定的保护期限，一旦保护期限届满，权利将自行终止，成为 社会公众可以自由使用的知识。商业秘密受法律保护的期限是不确定的，一旦为公众所 周知，即成为公众可以自由使用的知识。问题3：甲、乙两人同时在同一时间就同样的发明创造提交了专利申请，专利局将分别向各 申请人通报有关情况，并对两件申请都不授予专利权。这种情况是否合理？对于同一时间申请专利的情况，专利局可分别向各申请人通报有关情况，请他们自 已协商解决这一问题，如果双方协商不成的，则两件申请都不授予专利权。问题4：该项目负责人张某侵犯了开发者张某的身份权及署名权。问题5：目前，我国已形成了相对完备的知识产权保护的法律体系，对软件形成一种综合性 的法律保护，如源程序和设计文档作为软件的表现形式受中华人民共和国著作权法 保护，同时作为技术秘密又受中华人民共和国反不正当竞争法。