软考案例分析题万金油汇总

这篇具有很好参考价值的文章主要介绍了软考案例分析题万金油汇总。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

二、范围管理存在的问题

三、变更管理可能存在的问题

四、招标问题

五、风险管理可能存在的问题

六、采购管理中存在的问题

七、配置管理可能出现的问题

八、配置管理混乱和配置管理相关案例回答

九、项目收尾可能存在的问题

十、人力资源管理存在的问题

十一、项目整体管理可能存在的问题

十二、沟通管理和干系人管理

十三、质量管理中存在的问题

十四、写在最后


一、通用万金油

1、项目经理管理经验不足。

2、项目管理计划没有全员参与。

3、管理计划没有经过审批。

4、没有规范的变更控制流程。

5、没有成立变更控制委员会CCB。

6、没有形成变更记录。

7、需求未经过评审,分析。

8、哪方面做得不好,就说哪方面意识不强。

9、没有做好人员沟通管理。

10、做案例要围绕四大约束目标,一起看是否有缺失。(进度、范围、成本、质量。)

软考案例分析题万金油汇总,软考知识,产品经理,产品运营,软件需求,软件工程

二、范围管理存在的问题

11、没有制定范围管理计划。

12、没有制定需求管理计划。

13、没有做好需求收集、分析、调研等工作。

14、没有做好需求跟踪工作。

15、没有全面的收集需求,不能直接根据经验制定需求。

16、不能仅依据过去经验来编写现在项目的范围说明书等工作。

17、项目范围说明书内容不全面,或者项目范围定义不充分。

18、项目范围说明书不应由项目经理一人来编写。

19、WBS及范围基准应让项目团队和所有关键干系人一起来创建,而不是项目经理创建,导致工作遗漏。

20、或写WBS应由全体项目团队成员,用户和项目干系人共同完成和一致确认。(出现主要、部分,都是有问题的。)

21、项目范围基准未经评审和审批。

22、缺少范围确认等环节,项目成果等没有得到用户的正式确认和接受。

23、范围变更没有规范的变更控制流程。

24、项目变更实施前没有及时变更合同。

25、变更结果没有得到客户的签字确认。

26、为做好范围控制工作,对范围管理中的偏差和问题进行及时纠正。

27、需求未经过评审,没有输出需求文件和确认。

28、定义范围没有经过反复确认。

29、确认范围一般在阶段末尾进行。由外部干系人(客户或发起人)对项目可交付成果进行检查验收。

30、确认范围应贯穿项目始终,并以书面形式把完成情况记录下来。

软考案例分析题万金油汇总,软考知识,产品经理,产品运营,软件需求,软件工程

三、变更管理可能存在的问题

31、没有制定变更管理计划。

32、需求变更时没有走申请变更控制流程。

33、没有成立变更控制委员会,没有形成变更记录。

34、工程师不能直接进行修改并更新版本,这是不对的应该由CCB审批和批准。

35、没有制定项目文件更新。

36、客户需求没有经过评审。

37、项目经理监控不到位,管理项目经验不足。

38、没有将变更可能造成的影响告诉相关干系人。

39、缺少变更确认环节。

40、变更不能由项目经理一人决定。

41、变更结果没有进行正式验证,未得到客户的确认。

42、未做好配置管理和版本管理。

43、未对变更造成的影响进行充分的分析和评估。

44、缺少对变更执行有效监控。

45、影响不大的变更也要走变更流程,再由CCB决定是否变更。

46、项目经理没有与成员做好沟通管理,导致冲突或争吵。

四、招标问题

47、招标方发布招标公告,需提前20天以上。

48、招标方提前15天以上可以修改招标内容。

49、招标方可以自由选择招标代理机构,也可以不用招标代理机构,不得强制。

50、招标截止时间等于开标时间,不可推迟。

51、招标人截止时间前可修改投标文件。

52、招标截止时间后,无论任何原因都拒收投标文件。

53、资格预审文件或招标文件的发售期不得少于5日,3家以上通过资格预审的投标人才能开标。

54、招标方主持开标,而非招标代理机构。

55、投标方检查密封性,而非招标代理机构或招标方、主持人。

56、评委本单位人员不得超过1/3,技术经济类专家不得少于2/3,5人以上单数。

57、评委推荐不超过3家中标候选人并排名。

58、收到评标报告之日起3日内公示中标候选人。3日公示期。有异议3日内答复。

59、3日内发出中标通知书。

60、中标方发中标通知书,非结果;非中标方必须通知结果。

61、中标通知书发出30日内签订合同。

62、关键工作不能分包,非关键性可分包,标书和合同内应声明,并经招标方同意,分包方要求具备相应资质。不得二次分包。

软考案例分析题万金油汇总,软考知识,产品经理,产品运营,软件需求,软件工程

五、风险管理可能存在的问题

63、没有制定风险管理计划。

64、编制计划应相关干系人制定。

65、风险管理计划要经过评审后才能实施。

66、没有对风险进行全面的识别,风险识别应贯穿整个项目。

67、定性风险要从概率和影响进行分析排序。

68、没有做好定量风险分析。

69、没有做好风险应对措施,导致问题不断发生。

70、没有做好充分评估,没有预留储备。

71、风险管理过程没有进行跟踪检查和更新,没有及时记录归档。

72、项目没有结束,不能结束风险管理。

73、为结合本项目的实际情况编制计划。

74、编制风险管理计划不应由项目经理一个人来编制,应由项目团队和相关干系人共同参与,并经过充分沟通和评审后才能发布实施。

75、缺乏风险识别过程,没有对风险进行全面识别,以做好后续风险管理。

76、没有做好风险控制工作,对风险做再识别和评估工作。未进行风险审计及偏差趋势分析等,缺乏有效风险监控的工具技术。

77、在项目执行过程中与客户缺乏沟通,这会产生很多不必要的项目风险和隐患。

六、采购管理中存在的问题

78、没有做好规划采购工作。

79、未制定合理的采购管理计划,供方选择标准等。

80、没有编写采购工作说明书。没有审核供应商资质。

81、未提前列明采购货物的质量等级、标准要求等。

82、在实施采购过程中,仅凭价格低就选择卖方。未综合评价卖方综合情况,采购流程制度不规范。

83、在实施采购过程中不能以价格选择卖方,应综合评价卖方的综合情况,价格,质量、服务。

84、采购过程项目经理未重视采购管理,未说明采购备件的要求和参与采购的过程监管。

85、未将项目的进度与采购货物的时间进行综合考虑。

86、库存规划不合理或库存管理混乱。

87、未及时做好货物验收工作。

88、为做好控制采购工作。应及时监控卖方绩效。有问题要及时纠偏。而不是等到货物临近交货或交货时才发现问题。

89、未记录好采购过程中的相关采购文档和往来凭证,出问题难以找证据。

90、没有将项目的进行和采购货物的时间进行综合考虑。

91、没有与卖方签订好合同,重视采购管理。

92、未在合同中规定交付时间交付的验收标准,质量标准或规定不合理,导致各种争议。

93、合同中未规定索赔和违约条款,无法进行有效合同管理。

94、沟通存在的问题,应充分做好会前准备工作,做好会议引导。

95、采购流程制度不规范。

96、有问题要及时纠正。

七、配置管理可能出现的问题

97、未建立配置管理系统和机制,配置管理混乱,未设置专门的配置管理员对配置进行综合管理。

98、没有建立基线,导致需求设计编码无法对应,没有做好配置变更控制。

99、配置管理人员经验不足。

100、对配置管理工具没有进行有效评估。

101、未进行配置工具使用及配置管理的培训。

102、未制定配置管理计划,为建立配置管理机制及权限管理,配置管理较乱。

103、没有进行配置审计。

104、没有做好整体版本和发布管理。

105、成立配置管理委员会CCB。

106、未任命配置管理员。

107、未做好配置管理系统。

八、配置管理混乱和配置管理相关案例回答

108、对用户的要求未进行记录。

109、对变更请求没有进行足够的分析,也没有获得批准。

110、在修改过程中没有注意进行版本管理。

111、修改完后未进行验证。

112、修改的内容为和项目干系人进行沟通。

九、项目收尾可能存在的问题

113、未制定规范的项目收尾规程。

114、没有做好验收前的准备工作软件还存在缺陷,未经修复和确认并进入正式验收环节。

115、在验收过程中未根据变更控制流程,对软件进行修改,导致文档与软件不一致。

116、软件更新后没有对文档进行变更,便交付给客户。

117、项目产品未经正式验收和确认,未签署验收报告,就进行了项目总结。

118、项目收尾时应提交的必要文件没有准备好,并经客户签收验证。

119、催收剩余款项没有正式和必要的依据。

120、项目收尾时与建设方的沟通工作没有做好。

121、项目在产品和项目工作上都还不满足收尾条件。

122、项目总结报告未能反映项目的实际情况。

123、未经过正式规范的收尾就提前报告项目结束进行人员转移,给项目带来诸多风险。

124、项目总结会议没有让全部项目人员参与。

十、人力资源管理存在的问题

125、缺乏足够的项目管理能力和经验。

126、人员职责分配不合理,角色定位错误。

127、身兼多职,精力和时间都不够用,项目经理没有进入管理角色,定位错误。

128、新人缺乏培训和全程的跟踪监控。

129、没有进行良好的冲突管理。

130、未做好人员沟通管理。

131、没有进行绩效考核,没有建立对应的激励机制。

132、组建团队出现问题。

133、没有采取有效的团队建设措施。

134、没有清楚的分配工作职责到个人或人力单元。

135、团队管理存在问题主要没有及时发现冲突并分析原因采取有效的冲突管理。

136、招募不到合适的项目成员。

137、团队的气氛不积极,造成项目团队成员的士气低落。

138、项目团队的任务和职责分配不清楚。

139、人员流动过于频繁。

140、未制定公认并应遵守的团队规则。

十一、项目整体管理可能存在的问题

141、未制定项目章程或章程未得到审批。

142、项目章程是由组织外部签发的文件。

143、项目经理未能得到授权,未能确定项目高层的范围目标,没有制定整体项目管理计划或计划不周全。

144、项目管理计划可能不止得到高层的批准,还需要得到其他主要干系人的批准。

145、是否自下而上项目全体组员共同完成,是否渐进明细经相关主要干系人确认。

146、没有制定项目整体管理计划。

147、项目管理计划应由项目干系人共同制定,不能由项目经理一个人制定。

148、项目管理计划没有经评审和批准。

149、项目工作执行不到位。

150、没有做好项目监控工作,未能及时对比分析计划和实际执行情况。

151、对问题未能及时监控和分析,未能及时提出纠正、预防、缺陷补救等措施。

152、没有制定合理的整体变更流程,没有严格进行变更控制流程。

153、项目已经更新计划后基准未更新。

154、未能做好项目收尾工作,未能总结经验教训。

155、资金计划没有经过评审。

156、项目管理计划不够完善,不足以支撑对项目的指导和管理。

157、公司缺乏对项目的指导和监控。

158、进度管理存在问题,导致进度严重滞后。

159、监控工作应贯穿项目工作的始终。

160、没有建立变更控制委员会CCB。

161、没有形成书面记录。

十二、沟通管理和干系人管理

162、项目经理没有完全的识别出所有干系人、制定干系人管理计划。

163、项目经理只注重项目的进展程度,缺少与干系人的沟通。

164、项目经理没有建立合适的沟通渠道,信息发布不及时,导致高层领导和客户对项目进度情况了解不清晰。

165、项目经理作为一个整合者,没有解决好干系人之间的冲突。

166、不注重沟通技巧,没有建立融洽的合作氛围。

167、没有对干系人进行分类管理。

168、没有建立一个高效的简洁的沟通方式。

十三、质量管理中存在的问题

169、没有制定质量管理计划。

170、质量职责分配不合理。

171、质量保证活动做得不到位(或未实施质量保证。)

172、质量控制缺少必要的环节。

173、评审或者测试没做好。

174、未做好质量审计工作导致问题反复出现。

175、项目经理的质量管理方面经验不足或质量保证,人员经验不足。

176、没有建立质量的保证体系,标准规范。

177、没有设置专门的质量管理人员。

178、在质量管理中没有采用合适的工具技术和方法。

179、测试过程中配置管理工作未到位。

180、项目在重大里程碑处没有设置阶段成果评审,无法确保结果和预期目标一致。

181、技术评审会没有达到预期的目标。

182、设计文件没有经过正式的评审,可能没有发现设计文件的错误。

183、需求评审没有客户参与或没做好,可能导致最终对需求不能达成一致。

184、与客户沟通的存在问题方式单一,导致用户不满意。

185、项目成员缺乏质量意识,没有进行质量培训工作。

十四、写在最后

        如果你正在备战软考或计划备战软考,需要资料的可以私我或留言,纸质资料已经给别人了,还剩很多最新的电子资料,有课程视频、课件、资料、考试要点、论文写作、论文集等。绿泡泡:stypanda

更多软考上岸经验分享和资料,关注公众号:

软考案例分析题万金油汇总,软考知识,产品经理,产品运营,软件需求,软件工程文章来源地址https://www.toymoban.com/news/detail-820676.html

到了这里,关于软考案例分析题万金油汇总的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【软考】软考系统架构师案例分析知识点整理

    系统规划:包括系统项目的提出预可行性分析;系统方案的制定、评价和改进;新旧系统的分析和比较;现有软件、硬件和数据资源的有效利用; 软件架构设计:XML技术;基于架构的软件开发过程;软件的质量属性;架构(模型)风格;特定领域软件架构;基于架构的软件开

    2024年02月06日
    浏览(42)
  • No.046<软考>《(高项)备考大全》【专项2】《案例分析 - 计算题(中)》

    案例分析 - 计算题(上) 案例分析 - 计算题(下) 3.1.1 概念 名词 全程 理解 说明 PV Planned Value 计划值 应该完成多少工作, (按照计划截止目前应该花费的预算) AC Actual Cost 实际成本 完成工作的实际成本是多少 (截止目前实际的花费) EV Earned Value 挣值 完成了多少预算的工

    2024年02月03日
    浏览(34)
  • No.046<软考>《(高项)备考大全》【专项2】《案例分析 - 计算题(上)》

    类型 序号 题目 说明 进度管理 1 关键路径法 CMP 2 完工概率 - (计划评审技术 PERT) 三点估算 计划评审技术,PERT,又叫三点估算【乐观时间(OT)最可能时间(MT)悲观时间(PT)】 3 活动排序网络图 4 衡量项目规模 用 LOC (Line of Code )衡量项目规模。 5 类比估算 软件项目中用

    2024年02月09日
    浏览(44)
  • C++软件分析工具案例分析集锦汇总

    本文是 C++常用软件分析工具从入门到精通案例集锦 专栏的导航贴( 点击链接,跳转到专栏主页,欢迎订阅,持续更新… )。 专栏介绍 :根据近几年C++软件异常排查的项目实践,详细地讲述如何使用PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clum

    2024年02月11日
    浏览(52)
  • C++常用软件分析工具案例分析集锦汇总

    本文是 C++常用软件分析工具从入门到精通案例集锦 专栏的导航贴( 点击链接,跳转到专栏主页,欢迎订阅,持续更新… )。 专栏介绍 :根据近几年C++软件异常排查的项目实践,详细地讲述如何使用PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clum

    2024年02月11日
    浏览(43)
  • C++常用软件分析工具从入门到精通案例集锦汇总

    本文是 C++常用软件分析工具从入门到精通案例集锦 专栏的导航贴( 点击链接,跳转到专栏主页,欢迎订阅,持续更新… )。 专栏介绍 :根据近几年C++软件异常排查的项目实践,详细地讲述如何使用PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clum

    2024年02月14日
    浏览(49)
  • spark案例分析-搜索引擎日志分析案例

    1.业务分析 2.数据截图 3.代码实现:         main.py:         defs.py:

    2024年02月08日
    浏览(46)
  • 对应分析介绍及SPSS案例分析

    在开展统计分析的过程中,分类变量(定序和定类变量)是我们研究的一个重点。通常我们分析分类变量间关系时,最常用的分析方法是卡方检验,其次是逻辑回归和对数线性模型等。 如果类别变量的分类较少,我们可以通过卡方检验判断行变量和列变量间是否相互独立,同

    2024年02月13日
    浏览(48)
  • python案例讲解视频,python简单案例分析

    大家好,给大家分享一下python案例讲解视频,很多人还不知道这一点。下面详细解释一下。现在让我们来看看!   前言 Python 是一种面向对象、解释型、弱类型的脚本语言,它也是一种功能强大而完善的通用型语言。 相比其他编程语言(比如 Java),Python 代码非常简单,上手

    2024年04月11日
    浏览(45)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包