2023年软件项目管理案例分析题.doc

软件项目管理案例分析
案例分析一
问题1：
本项目申请国家技术创新基金100万元，但国家实际批准基金额度很也许会低于100万元，“项目投资来源”中应当说明：当国家实际批准基金低于申请额度时，如何补足两者之间的差额以及由此所引起的地方匹配基金的差额。
应重新召开股东大会并讨论以下议题：当国家实际批准基金低于申请额度时，公司是否乐意补足两者之间的差额以及由此引起的地方匹配基金的差额。
假如可以通过，应在“项目投资来源”中加注：当国家实际批准基金低于申请额度时，公司承诺补足两者之间的差额以及由此引起的地方匹配基金的差额（附新的公司股东大会决议）。
问题2：
A， B双方以B方现有技术成果为基础进一步合作开发，应明确以下几个重要问题：
（1） B方是以现有技术成果折价入股，还是将现有技术成果转让给A方；
（2） 假如是“技术转让”，应明确是“专利权转让”、“专利实行许可”、还是“技术秘密转让”？
（3） 双方是否已就合作开发的新技术成果的所有权、使用权以及利益提成问题达成一致意见？
双方是否已正式签订“合作开发协议”或“技术转让协议”？
问题3：
应重要从以下几方面分析项目技术的成熟性：
（1） 关键技术成熟性分析（涉及采用的现有成熟关键技术、已攻克的关键技术、待研究的关键技术等）；
（2） 项目采用的关键技术是否获得国家、部门或地方科技计划的支持（已获得、尚未获得）及计划的名称、获得支持的时间；
（3） 项目采用的关键技术是否通过技术鉴定（已鉴定、尚未鉴定）及鉴定单位、鉴定意见、鉴定期间。
案例分析二
问题1：
由项目执行偏差导致项目计划变更的各种诱发因素称为项目变更的内部因素。由项目目的变化导致项目计划变更的各种诱发因素称为项目变更的外部因素。
问题2：
“B方首付资金未能准时交付”、“A方盲目拟定进度目的”、“A方的前期设计有疏漏”、“A方编制的需求分析说明书未能准确、全面地表达B方的实际需求”、“B方自行负责的机房装修误期”、“A方开发人员跳槽”，属于项目变更的内部因素。
“证监会规定上市公司执行新的会计制度”、“B方因机构重组改变了业务流程”、“B方提出增长协议审计功能”、“B方行业主管部门发布了新的行业ERP实行规范”，属于变更的外部因素。
问题3：
“A方盲目拟定进度目的”、“A方的前期设计有疏漏”、 “A方开发人员跳槽”，属于A方责任。由此而增长的项目经费，由A方承担。“需求分析时，B方表达不清，A方理解有误，双方沟通不够，A方编制的需求分析说明了书未能准确、全面地表达B方的实际需求，而B方未能及时指正”，属于双方责任，由此而增长的项目经费，由A、B双方协商分摊。
其余各条，无论B方是否负有责任，均应承担由此而增长的项目经费。
问题4：
对于由内部因素引起的变更请求，变更评估的重点是拟定最优变更方案。而对于外部因素引起的变更请求，变更控制委员会应重点评估变更的必要性。
案例分析三
问题1：
（1） 没有清楚地了解到产品的范围，导致项目后期需求的蔓延；
（2） 没有澄清模糊的项目范围，在安装服务器的问题上产生异议，最终增长了未计划到的工作；
（3） 没有进行变更控制，以至于变更的结果不抱负，导致反复地变更。
问题2：
（1） 变更工作没有得到确认，导致工作的结果不可以被认可；
（2） 变更没有得到有效地执行。特别当同时发生多个变更的时候，假如没有有效的控制很容易导致一些变更被忽略甚至漏掉；
（3） 未控制的变更导致系统的混乱。软件系统是一个复杂的系统，系统间很多部件都存在关联，对其中某一部分进行更改也许会牵连到其他部分，导致整个系统的问题。
问题3：
范围控制是范围管理中重要的工作之一，范围控制的重要目的是控制变更的结果；保证所有被请求的变更都可以得到有效的解决；协调所有同变更相关的工作、资源和交付成果，让项目始终处在被控制的状态。范围控制的意义也在于此，通过范围控制，可以减少范围变更对项目导致的影响，减少风险，让项目处在可控制可跟踪的状态。
案例分析四
问题1：
分解项目WBS的一般过程如下：
（1） 辨认可交付成果及有关工作；
（2） 拟定工作分解结构的结构与编排；
（3） 将工作分解结构的上层分解到下层的组成部分；
（4） 为工作分解结构组成部分提出并分派标记编码；
（5） 核算工作分解的限度是否必要且足够。
问题2：
创建项目WBS时需要注意以下四点：
（1） 分解出的工作是充足且必要的；
（2） 工作的独立性。即工作一旦开始，就可以在不中断的条件下完毕；
（3） 工作完毕度的可判断性。即可以清楚地判断工作是否已经开始，工作完毕了多少，以及工作是否已完毕。
（4） 工作的交付成果。即工作完毕后将得到什么样的成果。
问题3：
（1） 在“同K公司负责人沟通后明确项目的范围”中，小张进行了范围定义的工作。之后小张又编写《关于***系统第三方系统测评计划备忘录》的文档，并发给公司K 负责人确认，让项目范围在各干系人中得到一致的结识。
（2） 在“将配合第三方机构进行测评的工作加入到项目WBS”中，小张进行了范围控制的工作。
案例分析五
案例分析六

案例分析七
问题1：
公司负责人不应当把单纯的参数模型放在成本估计上，而要根据不同的情况，采用不同的方法，否则会使成本估计产生很大的偏差。
在做成本估计时建立参数模型只是其中一种方法。建立参数模型指在数学模型中运用项目特点（参数）来预测项目成本。建立参数模型的首要条件是建模所参考的历史数据的精确性限度。
但是实际情况是该项目由于需要改动的那个过程中有很多工作不是很清楚，并且这过程还会对其他5个过程产生一些影响，影响的限度也没有得到明确的界定。更重要的是，改动的流程过程占整个制导致本的36%,因此完全按照参数模型是不合适的。
问题2：
由于王工程师可以准确地获得其他5个没有改动过程的具体成本信息，因此工程师在对已经明了的项目的5个过程应当采用建立参数模型法来对其进行成本估计。
而对那个需要改动的过程应当采用类比估算法，这是由于当对项目的具体情况了解甚少时（例如在项目的初期阶段），往往采用这种方法估算项目的总成本。
问题3：
成本控制就是要保证各项工作要在它们各自的预算范围内进行。成本控制的基本方法是规定各部门定期上报其成本报告，再由控制部门对其进行成本审核，以保证各种支出的合法性，然后再将已经发生的成本与预算相比较，分析其是否超支，并采用相应的措施加以填补。有效的成本控制的关键是经常及时分析成本绩效，尽早发现成本偏差和成本执行效率，这样就能在情况变坏之前及时有效地采用措施。
成本控制涉及查找正、负偏差的因素，它必须与其他控制过程紧密地结合起来。成本控制实质上就是监控成本的正负偏差，分析偏差产生的因素，及时采用措施以保证项目朝着有利的方向发展。重要方法有成本变更控制系统、绩效衡量分析、项目绩效审核、电脑化工具、偏差管理等。
案例分析八

案例分析九
问题1：
不明确需求就进行开发，导致项目开发无法制定相应的计划。缺少合理的项目开发计划，就无法保证项目的质量。
假如由于某种客观因素导致无法在软件项目开发之前明确这个需求，需要对这个软件项目进行阶段划分，在每个阶段中明确部分需求，并制定相应的开发计划。
问题2：
该公司的张工应当尽也许早地明确整个软件项目的需求，制定相应的计划。
张工可以把整个项目的开发阶段进行划分，对每个阶段的需求进行分析，制定计划，执行计划。
B银行的赵工应当尽也许早地提出需求。
赵工在需求拟定后假如需要变更请求，则要和张工一起协商，然后才干调整需求，并且对项目开发计划也进行相应的调整。赵工应当和张工一起分析，明确每个项目开发阶段的需求。
问题3：
在项目的需求分析阶段，项目负责人和需求提出者需要仔细研究整个项目的相关业务逻辑，了解整个项目的需求。在需求得到明确的前提下，制定相应的开发计划。
在项目的实行阶段，需要对每个阶段的需求进行明确，制定相应的开发计划。保证了每一个阶段的开发质量，就可以保证整个项目的质量。
案例分析十
问题1：
该软件公司在明知原有系系统统已经投入使用的情况下，没有提前分析升级的风险并告知客户，此证券公司没有制定升级计划，没有和客户一起制定风险预案。
该证券公司在得知此软件公司要对他们正在使用的系统进行升级的情况下，没有积极向该软件公司了解升级也许引发的问题，没有制定必要的风险预案，以致出现问题时无法采用合理的补救措施，导致了一些损失。
问题2：
现有系统由于一般已经投入使用，假如对其进行升级会有一定的风险。在进行升级以前，应当对其也许包含的风险和也许带来的问题进行仔细分析和评估，并有针对性地制定风险预案和升级计划。在升级失败或者出现问题影响系统使用的情况下，应当实行风险预案来保证系统的正常使用，尽也许地减少损失。
问题3：
软件系统的升级和开发同样，也要制定相应的开发计划和质量保证计划。假如缺少必要的计划和质量保证措施，也会导致很大的问题。软件系统升级假如出现质量问题，带来的损失也许比开发过程中出现问题更严重。由于假如一个正在使用的系统出现问题或无法正常使用，也许带来一定的经济损失。因此我们必须像软件开发同样采用必要的质量保证手段来避免或尽也许地减少经济损失。针对升级也许出现的风险，为了保险起见，需要制定一套或多套见险预案，并且进行预演，一般在出现问题时顺利采用风险预案来尽也许减少或避免产生经济损失。
案例分析十一
问题1：
由于人力资源计划不合理或者客户在开发过程中的一些突发因素导致人力资源计划局限性以应付项目的正常进行，项目管理人员则需要考虑增长人力资源。在组织内部由于人员紧张已经不能提供合适的开发人员，同时公司管理层不打算增长人员经费，项目组通过研究决定招聘一批实习生，这算是一个比较正常的解决问题的思绪，但是由于是组织外的人员，所以会增长管理难度。同时由于在项目中期引入新的开发人员，也引入了新的风险：新的开发人员也许不能及时完毕作为先决条件的任务（如培训及其他项目）；新的开发人员和项目管理层之间关系不佳，导致决策缓慢，影响全局；由于在工资待遇方面和正式员工有较大差距，且缺少激励措施，士气低下，减少了生产率；新的开发人员中某些人员需要更多的时间适应还不熟悉的软件工具和环境；由于是在项目中后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率减少；由于项目成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的反复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；也许在所有新开发人员中没有找到项目急需的具有特定技能的人，等等。以上这些因素都也许对项目进度导致很坏的影响，有较大的隐患，项目管理人员必须有效控制由此带来的人员风险。
问题2：
关于如何教育和引导刚加入公司的新雇员这个问题，随着公司产品的多样性和复杂性变得越来越棘手，并且新加入公司人员也许分别从事不同的工作，如程序员，程序经理，客户支持工程师，针对不同的角色应当制定不同的方案。
越来越多的公司都试图聘用能自学业务的人员，而不愿在培训项目、正规条例和流程或具体的产品记录上的投资。还可以通过纯熟员工来教育新新雇员，这些纯熟员工有经长、某些领域的专家以及正式指定的指导教师，他们除了本职工作外还要担负起教导新雇员的工作。这种方法使得大家觉得有权学习并自己决定学什么和不学什么，使得他们在公司里的作用灵活机动。例如对于程序经理的培训：刚开始时，新雇员的任务也许是一个单独的特性，并且在直到完毕为止的这段时间内，都会有人对你进行密切地指导。随后，当这种工作已做得相称纯熟之后，便会在更大的特性组中从事类似的工作，但指导会少得多。一段时期后，受训者会拥有一个小项目或一个大项目的一部分。同时，程序经理还可以受到一些正规的培训，涉及一个供选修的培训项目。此外，还可以不定期举行经验推介会，届时会有经验丰富的程序经理介绍他们自已的经验。假设你是一个新进入公司的开发员，那么在头几天里，你会与经理们以及来自其他专业部门的高级人员会面，你会听到有关开发周期的一个方向性的简介，然后开发经理睬立即派给你一个单独的任务或者让你与特性小组一起工作，你还也许被介绍给乐意当指导教师的高级开发员。
一般而言，你开始会从事相对容易的特性编码工作，这种工作需要的时间较少并且与其它特性关联甚少，并且高级人员（特性组长、领域专家、指导教师）随即非常仔细地检查你编写的代码。此外对开发领域人员应当有更加正规的定向的培训。例如，为新开发人员提供了几个为时几天的实习班，培训他们解决开发过程、产品、工具和其它专题。此外对于客户支持工程师的培训也是十分重要的。这重要是由于顾客不仅仅是购买产品，他们还要享受到优质的售后服务。所以，训练有素的客户支持工程师对于保持公司良好形象和提高为顾客服务的能力是至关重要的。客户支持工程师不必像开发员那样有必备的职业教育，但他们必须关于本公司产品如何工作的知识，并且事实上要在某种产品上具有专业知识。新的客户支持工程师在上岗之前，接受一段时间的专门培训。培训从基本的软件产品开始，同时他们还接受交际技巧，涉及如何与顾客打交道等方面的一般性训练。作为定向培训的一部分，他们还接电话，与导师一道工作（每位技术员有一位导师）。在他们被分派解决客户的电话之前负责答复客户来信。
问题3：
对日软件外包相对技术难度不高，但是质量规定相称苛刻，外包项目失败的例子不少。以下就对日软件外包常见的一些问题进行简朴探讨。
（1） 日方SE认为理所当然的地方，很多细节不会在式样书中明确写出，或者说日方SE完全按照日本做设计的习惯写式样书，由于中日文化和思维习惯的差异，也许导致中国软件开发人员对这些习惯问题理解有误。
对策：积累经验，参照同类系统，提QA表确认。
（2） 在产品提交期间，对于某些BUG，也许会出现这样的争执：中方开发人员说是由于日方的式样书没有写明确，式样书不够细致，日方设计人员说是中方理解式样书不对，有些地方不写也应当能自己理解。
对策：一方面保证产品质量的交货时间；加强双方交流；加强测试。
（3） 有的项目是日方边设计，需要中方同步开发，中方开发人员认为式样书上写多少就做多少没有写的就不做。
对策：加强项目的交流，积极提出设计思考让日方人员确认是不是这样的意思。
（4） 中方开发人员的日语纯熟限度不够。
对策：加强IT日语教育，开发人员至少达成能理解日语式样书的水平；配置专业的日语翻译辅助。
（5） 对于一些中方开发人员在太在意的一些细节问题，例如：字体，颜色、对齐方式等，规定不够严谨。
对策：强化质量意识，建立开发和测试规范。
（6） 开发过程的规范性与开发人员的态度：日本公司的开发管理，讲究中规中矩，非常重视文档的规范化管理，力求做到“凡事必求有据”；而中国公司在文档的规范化管理方面相对淡薄；日本公司项目管理对涉及的过程和文档，规定了极其严格的顺序和样式，规定开发人员严格执行。而中国公司在具体执行方面，开发人员往往对这些规范和规定的遵照不够严谨。
对策：完全按照客户规定执行，涉及文档，如：开发进度报告、测试用例、测试报告等；加强开发过程管理，规范开发过程，引入CMM模式；加强软件质量保证，如代码评审、文档审核、测试。
（7） 中国公司的开发人员比较喜欢技术创新，在开发过程中对于一些技术问题提出自己的技术方案，也许会导致部分模块技术实现方式与整体规定有差异。
对策：完全尊重日本客户的文化和管理模式，积极提出技术建议；对于有规定遵照Sample代码或对具体技术实现细节有严格规定的，开发人员必须严格遵循，不允许采用自已的技术实现；加强代码审查（code review）。
（8） 一些日本公司与中国公司的SE共同参与设计或交流的项目。
对策：在日本的合作伙伴公司派遣SE到项目现场进行设计；派遣中国SE到日本参与设计，设计完毕后带回中国开发；日本公司短期派遣SE到中国。
（9） 软件外包知识产权保护与客户保密问题。
对策：严格保护日本客户商业秘密和知识产权；中国公司与日本公司签订保密协议；中国公司与开发人员签订保密协议。
（10） 日本公司对中国公司开发进度的掌握。
对策：按照日本公司项目管理规定报告项目进度；分阶段交付。
（11） 远程协同合作开发的交流手段和方式。
对策：实时消息/语音/视频交流，例如：MSN Messenger, Yahoo Mesenger、视频会议系统、远程控制、远程协助、远程调试；Email、FTP；互相人才派遣，人才交流。
案例分析十二
问题1：
在一个软件产品整个的生命周期中，软件产品发布之后便进入漫长的软件维护阶段，而对于一些行业软件更是如此，后期的软件维护是非常重要的一个环节。在维护过程中通常要涉及到开发人员在现场对代码的维护，对数据和设备的维护，还也许需要根据用户规定对软件做相应的修改，有些也许涉及到重新开发或者发布新版本。当然后期维护也也许在一段时间内将会带来相称丰厚的收入，保持良好的客户满意度也将变得非常重要。现场开发人员不仅仅是完毕维护工作，并且更多的是需要通过和用户沟通了解用户在使用软件过程中碰到的一些问题，帮助用户对的结识软件维护的目的，得到用户的支持和协助，使软件最大限度地帮助用户提高其工作效率，发明经济价值，在用户中建立起良好的口碑。同时现场人员也应当积极收集和整理用户提出的一些问题，善于总结和思考，将这些问题反馈给公司总部，将一些用户盼望的功能发布在下一个版本当中，并且完善旧有版本中的缺陷。从这个角色出发，现场人员在一定限度上扮演了市场人员的角色，并且是接触最前线的用户，他们在做维护的同时，可以体会到用户使用软件的感受，从而得到最准确的市场信息，同时现场开发人员又是公司形象代表，每次现场工作都代表着公司的形象，所以公司需要设立专门的培训内容用于训练员工在外如何保持公司的良好形象同时做好宣传工作。
问题2：
在软件开发过程中，团队协同开发，很容易出现软件版本管理不善带来的软件系统故障。代码经常会被新的版本替换而使某些开发人员的工作成果丢失。这样不仅会打击开发人员的工作热情，也不利于责任的明确。在现场开发的过程中，由于缺少监督和管理，这种情况会更加普遍，如项目现场为应急而擅自更改软件代码，而经常没有将更改纳入统一的版本管理，甚至只是开发人员的个人意见，并没有通过项目管理层的批准，这种解决方法就很容易导致总部发行新版本软件时，替换软件而丢失了现场合进行更新的代码，从而导致系统故障的反复出现。此外，由于现场维护一般都会涉及到大量用户数据，程序的修改不仅会影响到软件功能，更也许产生很多垃圾数据，这些都是用户所不希望看到的，所以对现场代码的更改要严格控制，并且及时和总部版本保持一致，如微软公司出品的版本管理工具VSS就可以做到WEB访问，通过有效配置可以有效控制现场版本。
案例分析十三
问题1：
作为为项目经理面对项目问题应从更深层次上思考，要遵循项目管理原理，而不是浮于事务自身。项目经理张强在项目开始时就应制定具体的项目管理计划，应先考虑好也许要进行的项目沟通并加以执行，而不是在出现问题时才去填补。沟通不完整的项目过程，大多数会顾此失彼，进一步导致项目问题的发生。一言纳之，张强的问题关键是没有计划，假如按软件过程能力成熟度模型CMM评价，该项目组织只能是初始级。
导致项目问题的因素有以下几点：
（1） 沟通管理计划没有或不够具体；
（2） 没有重视部门间横向沟通；
（3） 与客户沟通不到位，客户需求未能准确把握。
问题2：
要实行高效的会议，一方面是在会议前要有计划，通常会议计划来源于项目沟通管理计划，准备阶段通常按如下顺序实行：
（1） 决定会议的宗旨和类型；
（2） 分析会议的因果：本次会议同本部门目的的关系？本次会议同上、下次会议的关系？什么事也许会影响对本次会议的爱好？
（3） 明确涉及的、受影响的人和事；
（4） 制定会议成果说明；
（5） 决定要讨论的主题；
（6） 决定会议角色分派；
（7） 决定会场布置；
（8） 计划会议议程表：非正式议程表、正式议程表（5W和1H）。
在会议过程中，有效地主持或参与会议则要注意按会议环节逐项讨论议程，总结决定。在会议中应鼓励与会者积极参与，制止悲观行为和不良意见。陈述信息要自信，态度要直接、坦率。对整个会议要注意掌握时间，记录重要备忘事项和决定。
会议跟踪也是一项重要工作。应自上而下逐级向必要的非与会者传达会议信息,制定行动计划完毕分派的工作,拟定计划以跟踪会上决定的工作进度。制定下次会议议程。
问题3：
项目经理应明确自已的工作职责范围，对项目相关资源的安排在制定沟通管理计划时应有具体的描述。对项目进度、项目成果应及时与公司高层领导或干系人沟通。项目组织应建有基于Internet的软件开发交流平台，从而能调度、跟踪解决项目现场问题。
项目经理和项目人员应通过各种方式与客户多作交流，如QQ，MSN、电话、电子邮件等。合适的组合是项目团队中至少一人是客户方的代表，项目初始时团队成员应与客户方的软件使用人员经常地进行业务方面的交流。
案例分析十四
问题1：
项目经理刘克勤的项目沟通管理是成功的。对于项目管理，除了掌握必备的项目基本方法和管理工具（如计划制定、预算编制等），对项目背景和目的有清楚的理解和结识外，最重要的一点就是与人交往的技巧。成功项目经理和失败项目经理的最大差别，也许就在于如何跟人打交道，如何跟客户打交道，如何跟公司领导打交道，如何跟项目成员打交道。
问题2：
项目经理刘克勤在项目过程中，团队建设相称成功。他为团队成员间建立纽带，并通过各种行为加强信任和消除团队合作的障碍。其中最值的借鉴是尊重团队成员、采用多种方法沟通、进行深度对话。
案例分析十五
问题1：
我们都知道，信息应用系统的变更特别频繁，而频繁的变更必然影响到信息工程项目的三大目的。通常与客户接触最多的是市场部项目经理，引导客户需求对项目经理就非常关键，项目经理引导得好，项目的开发就会非常顺利，反之，就会使项目组疲于奔命。
该项目中，市场部李工不断地提出新的需求时，张工“来者不拒”、疲于奔命、不断地更新项目计划，导致项目范围无法拟定，工期和成本不可控制，团队成员工作目的也不明确。
风险应对策略一般分为四种：回避、转嫁、减轻、接受。回避风险指改变项目计划，以排除风险或条件，或者保护项目目的，使其不受影响。转嫁风险指设法将风险的后果连同应对的责任转移到第三方身上。减轻风险指设法把不利的风险事件的概率或后果减少至一个可接受的临界值。采用此项技术表白项目班子已经决定不打算为处置某项风险而改变项目计划，或者表白他们无法找到任何其他应对良策。该项目已经发生了严重的需求风险，张工采用补救措施应当涉及减轻和接受。减轻风险的应对措施应能设法减轻风险的影响，其着眼点应放在影响限度最大的连接点上，张工应当与李工积极地沟通和谈判，使他们明白本期工程的重要意义，并承诺本期工程不是交钥匙项目，可为系统升级和扩容留有扩展接口，将来新的需求可以通过后续工程逐步开发实现,李工批准本期工程只实现大家最为关注的功能指标和性能指标;最常见的接受风险的应对措施为预留应急储备,或者简称储备,涉及为已知风险留出时间、资金或资源。为接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。张工应当申请启动项目风险储备金，通过增长资源成本、付出额外劳动使得项目回到正轨。
问题2：
在设计系统架构时，项目管理经验局限性、关键技术不明确、系统扩展性不佳、产品兼容性有问题、软件版本管理混乱等，均也许是影响系统正常运营的潜在隐患。在本期工程的机房设备平面设计中，张工团队起初大部分机架式的小型机集中摆放在一片较社区域内，从表面上看，提高了机房平面空间的使用率，但是由于未充足考虑到设备散热因素，导致了该区域的机房专用空调负荷过重而多次宕机。
后来，张工聘请了具有通信设计资质的专家负责工程设计，从机房空调、电源、布线、承重、消防等各个方面进行了详尽的勘察和设计。透过专家编制的工程设计，张工团队可以细致地了解有关机房设计的技术内涵和外延，并通过工程设计评审机制，一方面确立了工程设计的权威或指导作用，另一方面获得了专家们的可靠技术承诺，实现了工程设计风险的良性转移。
问题3：
针对该项目的风险管理，提出以下几点建议作为参考。
（1） 推广项目管理理念。项目团队积极向项目干系人及周边人介绍项目管理的先进理念和方法，处处营造项目管理的氛围。团队成员积极参与项目管理培训，将所学用于工作和生活之中，并加以总结和升华，提高自已的竞争力。
（2） 有效管理项目风险。项目经理自始至终负责制定项目风险管理计划和风险应对计划，并在每次项目例会时重点讨论项目风险，对风险发生概率和影响限度进行评估，由定性分析到定量分析，制定有效的防止、减轻或促进风险（机会）的应对方案。
（3） 多渠道沟通和谈判。保证多渠道沟通机制畅通，采用横向沟通方式和纵向沟通方式。灵活使用谈判手段和技巧，收集和掌握足够的有用信息，保证具有积极的话语权。解决好与项目干系人的关系，互相配合，实现共赢。
（4） 争取高层领导支持。高层领导对于项目成败至关重要。高层领导掌握项目团队所需的任何资源。通过邀请高层领导参与项目启动会、关键里程碑发布会、项目竣工总结会等形式，既可以使高层领导关注项目、了解项目和推动项目，又可以提高项目及项目团队地位，有助于项目成功，有助于个人职业生涯发展。
案例分析十六
问题1：
对于紧急重要风险1措施如下：保障工程进度规定，保证NSS、BSS软件督导的调测力量；及时沟通，避免由于传输因素耽搁进度；保证工程质量，督导、督察人员将对合作方施工人员进行有效的指导和对工程质量进行有效监控。项目实行日报制，项目经理每日对省市公司网络部进行工程报告，对于由于用户因素导致的进度耽搁明确指出来，分清双方责任。
对于紧急重要风险2措施如下：公司研发中心MSC、BSC、BTS人员现场进行信令跟踪，对切换不成功的因素进行定位，在A公司成立专门的小组，协助现场进行问题定位。假如是我方因素，中研相关部门进行程序修改，假如是对方因素则提供相关的信令分析文献，由项目经理和中研人员共同向局方解释，规定爱立信修改相关程序。计划工程的不同阶段分别举行三次移动公司、A公司、爱立信双频技术切换交流，讨论双方参数设立，移动公司负责总体监控双方的实行工作；在城市郊区话务量较小地区，开通5个基站进行单站以及双频配合测试，为全网开通积累经验。
对于紧急重要风险3措施如下：需要找到集团公司《关于建设中国移动1800M双频网的若干意见》文献原件，进行仔细分析，寻求解决方法。加强省公司高层的工作，通过客户关系工作盼望给A公司工作上提供支持。对此事向公司总部反映，看看是否通过北京分部的工作使移动集团公司有所松动或是有其他变通方法。
对于紧急重要风险4措施如下：公司对城市1800M频段分地区进行测试，摸清干扰信号频段，通过调整频率规划规避部分干扰，争取多开通基站。了解目前使用1800M单位情况。协助移动与其进行交涉，争取占用单位能进行频率调整，解决1800M干扰问题。将此事报告到移动公司高层，通过其与无委高层的沟通解决频占费的问题，并通过无委清理被其他单位占用的1800M频段。
问题2：
该项目还存在以下几个问题：
（1） A公司将竞争对手的竞争风险分析不全面。A公司仅仅是从技术上进行了风险防范，对于其他方面A公司却没有任何措施。
（2） 对于1800M干扰的风险问题，A公司制定的计划太松散，没有引起足够的重视。
（3） 对于1800M网络的建设目的A公司理解有些偏差。
调整的风险应对计划如下：
（1） 收集竞争对手问题，针对此提出A公司的解决方案。
（2） 联合市场部，加强高层项目推动，突出A公司网络设备特点，建议用户在省会城市引入竞争，尽快开始1800M工程建设。
（3） 加强干扰解决推动监控，加快进度，项目经理进行全程跟踪；
（4） 对用户进行双频网建设思绪进行新的引导，列举A公司在全国的双频网应用，列举A公司开通基站的指标数据。
问题3：
（1） 进行调研，拟定流动因素。
（2） 在项目开始前，把缓解这些流动因素的工作列入风险管理计划。
（3） 项目开始时，做好计划一旦人员离开时便可执行，以保证人员离开后项目仍能继续进行。
（4） 制定文档标准，并建立一种机制，保证文档及时产生。
（5） 对所有工作进行细致详审，使更多人可以按计划进度完毕自已的工作。
（6） 为每个关键性技术培养后备人员。
案例分析十七
问题1：
（1） 对省内省外投标人提出了不同的资格规定。公开招标应当平等地对待所有投标人。
（2） 乙单位提交保证金晚于规定期间,投标保证金是投标书的组成部分,应在投标截止日前提交。
（3） 招标书发出时间为2023年12月15日，而投标截止时间为2023年12月30日，中间时间为15日，有违招投标法所规定的20日。
（4） 投标截止时间与开标时间不同，《招投标法》规定开标应当在投标文献截止时间的同一时间公开进行。
（5） 不应当是招标办主持开标会。开标会应由招标人或其代理人主持。
（6） 重新招标时候评委应为5人以上单数。
案例分析十八
问题1：
公司A向第三方（监理公司C）泄露承建单位（IT公司B）的技术机密，违反协议签订时保密约定规定，该措施不妥。
问题2：
项目不可分割，属于一个整体，未经甲方公司A批准，此类项目不应分包。而公司B却和公司D签订此项目的分包协议，很显然，该协议无效。
问题3：
公司A应当将公司B未付给公司D的所有款项（扣除保存金）付给公司D，并从应付给公司B的任何款项中如数扣回。
案例分析十九
知识产权是公司宝贵的无形资产，也是公司可以连续发展的前提之一，某软件公司A公司从事管理系统软件开发，程序员张某参与了A公司开发管理系统软件的工作，后辞职到另一个公司B公司任职。于是项目负责人将张某在该软件作品上的开发者署名更改为别人。
问题1：
按照《计算机软件保护条例》的规定，自然人的软件著作权的保护期限为自然人终生及死亡后50年.
问题2：
知识产权一般都具有法定的保护期限，一旦保护期限届满，权利将自行终止，成为社会公众可以自由使用的知识。商业秘密受法律保护的期限是不拟定的，一旦为公众所周知，即成为公众可以自由使用的知识。
问题3：
甲、乙两人同时在同一时间就同样的发明发明提交了专利申请,专利局将分别向各申请人通报有关情况,并对两件申请都不授予专利权。这种情况是否合理？
对于同一时间申请专利的情况，专利局可分别向各申请人通报有关情况，请他们自已协商解决这一问题，假如双方协商不成的，则两件申请都不授予专利权。
问题4：
该项目负责人张某侵犯了开发者张某的身份权及署名权。
问题5：
目前，我国已形成了相对完备的知识产权保护的法律体系，对软件形成一种综合性的法律保护，如源程序和设计文档作为软件的表现形式受《中华人民共和国著作权法》保护，同时作为技术秘密又受《中华人民共和国反不合法竞争法》。死忆机下要