软考-系统集成项目管理中级--案例分析专题

菜鸟学识

于 2024-04-29 16:43:49 发布

阅读量922

点赞数 28

分类专栏：系统集成项目管理工程师中级文章标签：软件工程

本文链接：https://blog.csdn.net/suruoxun/article/details/138225572

版权

系统集成项目管理工程师中级专栏收录该内容

22 篇文章 17 订阅

订阅专栏

1、各领域可能错误的地方

大家请认真看看，考试的时候需要具体结合背景选择性的采用

立项管理

(1)立项申请应由甲方的上级主管单位，而非甲方总经理批准

(2)未做详细可行性研究就生成可行性研究报告
(3)可行性研究报告未经评审
(4)仅根据项目符合国家政策就判断项目肯定要上马，判断依据过于单一

(5)投标由软件工程师负责不合适，缺少相关经验
(6)仅从技术角度分析项目可行不全面，需要综合考虑经济、技术、社会等因素。

(7)投标文件不能单独完成，需要比较有经验的各领域专家共同参与编写
(8)未编写项目建议书
(9)未进行项目评估
(10)没有进行系统的可行性分析，没有进行多方案比较。
(11)调研不充分，没有调研大规模应用的案例。
(12)没有调研国家政策是否允许。
(13)未进行项目论证

整体管理

(1)没编写、发布项目章程
(2)没编写项目管理计划
(3)执行过于随意，没按计划进行
(4)没进行项目监控
(5)没走变更控制程序
(6)没做好收尾工作
(7)项目章程是项目经理发布的
(8)一个人编写项目管理计划

(9)计划没经过评审
(10)项目章程内容不全
(11)计划内容不全
(12)项目已经变更，计划未更新
(13)没做好各子计划的统一协调，可能导致项目计划不符合项目实际情况
(14)缺乏项目整体管理的思想
(15)项目计划缺少相关分计划，如质量计划、沟通计划等。
(16)项目管理计划制定比较简单，不足以支持整个项目对所需过程的指导和管理
(17)公司缺乏对项目的指导和监控。
(18)选择的软件开发生命周期模型不适合项目
(19)缺乏阶段性的评审，从而未能及时发现问题
(20)启动工作未按照公司管理流程执行。
(21)项目管理办公室对项目监督不力，没有及时发现项目中存在的问题并予以指导。

范围管理

(1)没做规划范围管理
(2)没做需求收集工作
(3)没进行范围定义
(4)没进行创建 WBS
(5)没做范围确认
(6)没做好范围控制
(7)范围管理计划、需求管理计划是1个人编写的
(8)没召开需求评审会，没确认需求
(9)范围说明书内容不全
(10)没有与各干系人对需求进行详细分析，只是在对客户需求的初步了解后就开始实施。

(11)不能只参照类似项目的范围说明书，需要根据本项目情况进行编写
(12)范围说明书没经过评审
(13)不能单独一人对项目进行分解，而要让项目组成员也参与进来。

(14)范围管理没做好，导致范围出现蔓延
(15)一个人编写了范围说明书不对
(16)WBS 没有经过相关干系人的确认
(17)范围确认存在问题，导致 WBS 中定义的功能没有开发
(18)闭门造车式地开展需求调研与项目范围说明书的编写工作，没让相关千系人参与进来

(19)没有编制 WBS 和 WBS 词典，以形成权威的范围基准。
(20)没有进行范围管理计划的评审
(21)WBS 最好可以分解到3-6层
(22)存在镀金行为
(23)对需求估计不准确，资源估算不足

(24)需求评审没有客户参与，可能导致最终对需求不能达成一致，设计文件没有经过正式评审，可能导致设计文件有较多的错误。
(25)缺乏项目范围管理的思想
(26)一个工作只能由1个人负责
(27)工作包的大小应该介于8/80之间。
(28)没包含外包出去的模块
(29)没包含项目管理工作
(30)一个下层属于多个上层了，有交叉从属

进度管理

(1)没进行规划进度管理
(2)没进行活动定义
(3)没进行活动排序
(4)没进行资源估算
(5)没进行历时估算
(6)没制定进度计划
(7)没做进度控制
(8)加班会增加成本，影响质量
(9)并行工作会增加风险
(10)增加资源有时可能压缩工期有限
(11)制定进度计划的方法不合理，没有预留一定的缓冲时间。
(12)项目进度计划不合理
(13)计划未经过评审就付诸实施:

(14)不能一人来制定进度计划，并且没有从项目实际出发来制定进度计划，而根据合同规定的时间来制定的进度计划可能不符合项目实际情况。
(15)控制进度的工作做得不好
(16)缺乏进度管理的思想
(17)制定工作计划时，没考虑资源日历，导致有冲突
(18)在压缩工期的情况下，没有考虑新增加开发人员的可用性

(19)未经过评估情况下随意将原来系统开发时间压缩

(20)关键里程碑点没有获得相关干系人的签字确认

成本管理

(1)没进行成本规划
(2)没进行成本估算
(3)没进行成本预算
(4)没进行成本控制
(5)1个人编写了成本管理计划

(6)成本管理计划没经过评审
(7)成本估算不准确
(8)成本预算不准确
(9)没采用相关工具进行成本控制
(10)赶工导致成本超支了

质量管理

(1)没有制定可行的质量管理计划并积极实施
(2)没做质量保证
(3)没做质量控制
(4)没有全面的质量管理进展情况报告
(5)质量保证过程中缺乏 QA 的参与
(6)质量控制环节缺失，例如评审和测试
(7)测试方法不当或不充分
(8)测试控制的流程不对，或未进行质量控制就进行了范围确认。
(9)项目经理用人错误，小李没有质量保证经验。
(10)应加强项目过程中的质量控制或检查，不能等到工作产品完成后才检查

(11)QA发现问题应与当事人协商，如果无法达成一致要向项目经理或更高级别的领导汇报，而不能自作主张。
(12)在质量管理中，没有与合适的技术手段相结合，
(13)对程序员在质量意识和质量管理的培训不足
(14)没有严格执行公司完善的质量管理体系;
(15)质量职责分配不合理
(16)质量管理计划内容不全
(17)在规划质量管理的时候应该同步制订过程改进计划，质量测量指标、质量核对单，并同
步更新项日文件。
(18)项目经理认为质量管理中他是配合的角色，认识错误。
(19)公司高层对质量管理认识不足，不重视质量管理
(20)没有指定专门的质量管理人员

(21)缺少质量标准和质量规范
(22)没有建立质量保证体系
(23)质量控制做得不到位。
(24)未审计质量要求和质量控制测量结果
(25)质量管理计划不应由小张一个人制定。
(26)质量管理计划应经过评审
(27)质量管理计划的制定没有考虑项目实际情况。
(28)质量管理的工具利用比较单一。
(29)存在走过场问题，没有深入地评审，

(30)测试工作中在测试用例、测试方法、测试人员及测试环境等方面存在问题。

(31)项目经理在项目质量管理方面的经验欠缺
(32)测试过程的阶段安排不合理，软件系统的测试时间不足
(33)体系建设应全员参与，不应由质量部门单独负责体系文件编制
(34)体系应结合企业自身特点设计，不能照搬其它公司的文件或经验
(35)质量部门应全程参与项目的质量管理和体系运行，不能只检查结果

(36)代码被修改后没有及时进行回归测试并请干系人确认
(37)没有按公司的质量管理体系要求来进行项目的质量管理，团队成员没有质量意识:
(38)没有安排专职的项目质量管理人员;
(39)没有建立质量保证体系，没有QA或QA不独立于项目组织或经验不足

(40)只是凭经验进行检查工作，而没有按质量的标准进行检查
(41)在质量检查中发现问题后没有及时解决，没有达到质量检查的效果

(42)质量控制做的不到位，检查工作颗粒度不一
(43)缺少对项目质量管理工作和监督指导
(44)对团队成员质量意识和质量管理方面的培训不足

(45)测试人员应该纳入项目团队管理，不应该请办公室职员代劳，

人力资源管理

(1)没规划人力资源管理
(2)没进行团队组建
(3)没做团队建设
(4)没做团队管理
(5)团队的组成人员尽管富有才干，但是却很难合作
(6)项目团队的职责分配不清楚，没有建立RAM 责任矩阵
(7)团队的气氛不积极，造成项目团队成员的士气低落
(8)人员流动过于频繁
(9)兼职过多，精力和时间不够用，顾此失彼
(10)没有进入管理角色，定位错误，疏于对项目的管理
(11)新人缺乏培训和全程的跟踪和监控
(12)没有进行良好的冲突管理。
(13)项目团队成员能力不足
(14)招聘人员时的考核指标不应该仅仅是设备维修经验，还应该注重能力的考查。

(15)团队成员应该有冗余，防止因事假、病假造成其它成员的超负荷工作。
(16)项目经理应该给予必要的帮助和辅导，加快团队成员的成长。

(17)项目经理要注重团队绩效和个人绩效的考核，要加强过程的监督和控制。

(18)项目经理认为团队管理的核心是团队凝聚力强，不发生冲突是错误的，冲突是不可避免的，关键在于如何处理冲突。
(19)人员任命方面存在问题，任命的项目经理虽然研发能力强，但项目管理经验不足。

(20)组建项目团队不合理
(21)绩效管理方面存在问题，没有及时对加班成员进行激励。
(22)成员水平参差不齐，项目团队组建的人员是从各个组别中找出空闲的人员，需要根据实际情况组建团队。
(23)团队成员没有明确的考核和评价标准，考核规则不明确，需要明确标准

(24)没有协同工作，工位分散导致没有良好的沟通，需要加强协调工作

(25)质量工程师编写项目人力资源管理计划是不对的;
(26)人力资源管理计划应该各干系人参与，而且还需要经过评审

(27)缺乏合理且有激励性的考核方案;
(28)绩效奖金分配不合理
(29)没做好激励，导致员工士气低落和离职。
(30)组建、建设团队可能不合理，考虑不充分，导致需要远程办公
(31)奖励政策没有得到领导的同意;
(32)Y型的管理风格没有与切实可行的规章制度相结合;
(33)钱某的管理风格没有与直接领导的管理风格相协调
(34)用人不当，不应选新毕业生做质量保证。
(35)缺乏团队领导经验，事必躬亲的做法不对。
(36)王某对新员工的工作能力和团队合作素质没有进行考察。
(37)王某对于冲突的处理方式过于简单。
(38)项目团队在一定程度上缺乏技术实力;

沟通、干系人管理

(1)没进行规划沟通管理
(2)没做管理沟通
(3)没做控制沟通
(4)没进行干系人识别
(5)没进行规划干系人管理
(6)没做管理干系人
(7)没做控制干系人
(8)没有或极少与客户进行直接沟通，合作氛围不够
(9)没有对团队成员的沟通需求和沟通风格进行分析
(10)沟通方式单一
(11)项目执行过程中未能进行及时有效的沟通(或建立有效的沟通机制)
(12)沟通管理计划不能一人制订
(13)干系人识别不全，遗漏了重要干系人
(14)没有对沟通情况进行记录
(15)控制沟通工作做得不好，没有对存在的沟通问题及时进行解决
(16)沟通管理存在问题，导致客户对项目很不满并投诉，并且没有将相关项目绩效数据发送给项目管理办公室

(17)与客户发生了争执，沟通管理有问题。
(18)独自编制干系人清单不妥
(19)干系人沟通方式单一，只采用电子邮件方式:
(20)管理沟通不力，对于员工的诉求，应私下解决问题，不应在大会上公开说:

(21)控制沟通不力，采取强迫手段中止员工的诉求，导致后续的冲突升级

(22)与高层沟通不力，未得到高层领导的认同。
(23)周报内容不全
(24)月度例会粒度太粗
(25)甲方没有对各部门的需求进行统一的组织和管理
(26)缺乏与客户清晰的、统一的接口，与客户沟通不是很有效
(27)公司其他职能部门支持或协作不够
(28)缺乏良好的沟通能力和沟通技巧
(29)对项目干系人的需求了解不细致
(30)项目缺乏阶段沟通与阶段评审。

风险管理

(1)没进行规划风险管理
(2)没做风险识别
(3)没做定性风险分析
(4)没做定量风险分析
(5)没做风险应对
(6)没做风险控制
(7)对项目的风险认识不足
(8)自己负责各项应对措施不妥，各风险应对措施的实施应责任分配到人

(9)没有处理好外部因素(天气)和内部因素(团队)带来的风险，缺乏有效的应对措施

(10)风险管理计划编制存在问题，独自一人完成而没有邀请项目组其他成员参与。

(11)不能仅凭个人的经验进行风险识别，而要与项目组成员一起参与。

(12)风险识别不够详细，只识别出了主要风险，没有识别出所有风险。

(13)风险监控做的不好，导致风险没有及时发现。
(14)风险应对措施制订不合理。
(15)没有进行风险再识别。
(16)识别不全面，风险识别过程应该是反复的过程

(17)仅仅参照以前的项目模板编制风险管理计划
(18)不仅凭个人的经验进行风险的识别

(19)风险管理计划没有经过项目组讨论直接签字下发实施，缺乏沟通，也导致项目中的实际问题与计划的偏差较大。
(20)风险控制和应对措施都是各成员按各自理解进行安排。应该在充分沟通的前提下统一进行风险应对和管控。
(21)员工缺乏风险意识
(22)依据自己经验制定应对计划不妥，应依据定性风险分析的风险值开展定量风险分析排序后，制定风险应对计划;

采购管理

(21)中标公示结果少于3天。
(22)投标截止时间存在问题，依法必须进行招标的项目，自招标文件开始发出之日起至投标
人提交投标文件截止之日止，最短不得少于二十日。

(23)招标代理机构拒绝投标人投标文件修改存在问题，投标人在招标文件要求提交投标文件的截至时间前，可以补充、修改或者撤回已提交的投标文件，并书面通知招标人。

(24)接受迟到的C公司投标文件存在问题，在招标文件要求提交投标文件的截止时间后送达的投标文件，招标人应当拒收。
(25)没有对中标候选人进行排名
(26)A公司直接决定D公司中标存在问题，招标人应当确定排名第一的中标候选人为中标人

(27)A公司公布中标结果，并向D公司发出了中标通知书存在问题，中标人确定后，招标人应当向中标人发出中标通知书，并同时将中标结果通知所有未中标的投标人。

(28)B公司向招标代理机构询问中标结果，招标代理机构以保密为由拒绝告知，需要将中标结果通知所有未中标的投标人。
(29)A公司与D公司签署了商务合同存在问题，招标人和中标人应当自中标通知书发出之日起三十日内，按照招标文件和中标人的投标文件订立书面合同

(30)D公司将项目的某重要工作分包给了另一家公司存在问题，只能将非关键、非主体工作进行分包
(31)D公司直接分包项目存在问题，中标人需按照合同约定或者经招标人同意。

变更配置管理

合同管理

2、案例分析万金油

3、历年中、高级案例分析背景中的明显错误

(27)小方根据在学校学习的项目管理知识，制定并发布了项目章程。因工期紧，小方仅确定了项目负责人、组织结构、概要的里程碑计划和大致的预算，便组织相关人员开始各个网站的开发工作。

(28)项目经理召开项目组内部会议将任务口头布置给了小组成员。会后，主要由编码人员按照会议备忘录的要求对已完成的模块编码进行修改，而未完成的模块按照会议备忘录的要求进行编写。

(29)需求分析完成后，项目组编写了《需求分析报告》。项目经理小赵召集部分骨干人员召开评审会，对需求文件进行了评审。为了尽快进入下一阶段工作，评审会从早上9点一直开到晚上9点，终于把全部文件都审完了。评审组找到了几处小问题，并当场进行了修改，项目经理宣布可以进入设计阶段了。

设计人员根据需求文件编写了《设计说明书》,并提交给小赵。小赵对设计文件仔细审阅后,便安排程序员开始编程。

79)项目启动时，乙公司领导安排王工担任此项目的项目经理，王工自己按照公司项目章程模板撰写项目章程，进入了下一个过程，新撰写的项目章程内容包括:质量控制人员、项目组织结构、项目基本需求、项目完工日期。
同时为了保证项目质量，王工亲自撰写了初步的项目范围说明书。王工依照以前公司的经验撰写的初步的项目范围说明书内容包括:项目概述、产品要求、项目完工日期、项目约定条件、初始风险。初步的项目范围说明书撰写完成后，王工通知了项目组成员，按照初步的项目范围说明书开始工作，项目组成员有人认为初步范围说明书内容太过简单，跟以往项目范围说明书差别太大，但担心项目经理不高兴，也没有直接说。

(83)某信息系统开发公司承担了某企业的ERP 系统开发项目,由项目经理老杨带领着一支6 人的技术团队负责开发。由于工期短、任务重，老杨向公司申请增加人员，公司招聘了2名应届大学毕业生小陈和小王补充到该团队中。老杨安排编程能力强的小陈与技术骨干老张共同开发某些程序模块，而安排编程技术弱的小王负责版本控制工作。在项目开发初期，小陈由于不熟悉企业的业务需求，需要经常更改他和老张共同编写的源代码文件，但是他不知道哪个是最新版本，也不知道老张最近改动了哪些地方。一次由于小王的计算机中了病毒，造成部分程序和文档丢失，项目组不得不连续一周加班进行重新返工。此后，老杨吸取教训，要求小王每天下班前把所有最新版本程序和文档备份到2台不同的服务器上。一段时间后，项目组在模块联调时发现一个基础功能模块存在重大 BUG，需要调取之前的备份进行重新开发。可是小王发现，这样一来，这个备份版本之后的所有备份版本要么失去意义，要么就必须全部进行相应的修改。项目工期过半，团队中的小李突然离职，老杨在他走后发现找不到小李所负责模块的最新版本源代码了，只好安排其他人员对该模块进行重新开发。

(92)在某系统集成项目收尾的时候，项目经理小张和他的团队完成了以下工作:

        工作一:系统测试。项目组准备了详尽的测试用例，会同业主其同进行系统测试。测试过程中为了节约时间，小张指派项目开发人员小李从测试用例中挑选了部分数据进行测试，保证系统正常运行。
        工作二:试运行。项目组将业主的数据和设置加载到系统中进行正常操作，完成了试运行工作。
        工作三:文档移交。小张准备了项目最终报告、项目介绍、说明手册、维护手册、软硬件说明书、质量保证书等文档资料直接发送给业主。
        工作四:项目验收。经过业主验收后，小张派小李撰写了项目验收报告，并发送给双方工作主管。
        工作五:准备总结会。小张总结了项目过程文档以及项目组各技术人员的经验，并列出了项目执行过程中的若干优点。
        工作六:召开总结会。小张召集参与项目的一些人员参加了总结会，并就相关内容进行了讨论，形成了总结报告。