《(吐血整理)信息系统项目管理师考试答题技巧与复习重点》由会员分享，可在线阅读，更多相关《(吐血整理)信息系统项目管理师考试答题技巧与复习重点（54页珍藏版）》请在金锄头文库上搜索。
1、信息系统项目管理师考试答题技巧和复习重点一.上午的选择题技巧对于没有确定把握的题，按自己的第一选择1.概念、公式类题目，答案选最长的2.选择某一选项为其他选项合集的3.如果选项中有二选项相背，则答案位于其中4.选择提干与核心词汇一致的5.模型相关的选择题：带有循环、原型驱动等关键词的选择螺旋模型；需求确定、传统的选择瀑布原型；需求不确定、面向对象的选择迭代模型或者喷泉模型6.要掌握5类计算，如下：1）静态回收期/投资回报率2）动态回收期/投资收益率3）关键路径和活动6参数4）三点估算5）挣值分析绩效控制6）决策树二.下午案例分析1.三个基本观点 1)项目以阶段化管理，迭代开发为主线 2)以范围
2、、质量、成本、周期之间相互约束，保持平衡为主线 3)项目的结构化管理，要具备良好的请示汇报关系，保障责任唯一性2.如果你实在是不知道怎么写，还可以从案例中找出错误的地方，然后往正确方向写，估计也能得及格分3.四种答题思路一、职能/机构的作用：1）统一组织，建立良好的请示汇报关系，建立相关职能岗位的说明书。2）统一流程，制订该组织工作的制度，行为规范。3）通一绩效，制订严格的考核体系，实行奖惩制度。二、计划编制类1）识别计划目标、约束等因素。2）采用合理方法、工具等支持编制。3）做好计划的相关干系人共同参与的评审，形成计划基线。4）做好计划的跟踪控制，持续优化改进。三、控制类1）建立干系人认可的
3、计划或基线。2）识别偏差：以定期等工作方式收集相关问题。3）分析偏差：做好相关问题剖析。4）纠正偏差：制定相关问题的改正措施。5）制定新的计划：通过相关干系人协商，将问题改正措施纳入到后期计划或基线中。四、评估/评审类1）识别相关关注点或需求。2）制定反映关注点或需求的指标体系。3）根据项目特点，确定指标权重。4）制定指标的度量准则，形成评审或评估的操作规程。三.下午论文掌握一个框架：论文八段式结构 1）摘要 2）项目背景与岗位工作说明 3）在项目实施过程出现的问题，你作为什么角色，如何解决了问题 4）首先，针对某某问题，项目出现的矛盾，如何解决，解决的效果 5）其次，。 6）再次，。 7）项
4、目验收与项目干系人的满意程度 8）展望，说出对于其他项目的借鉴作用高项考试答题技巧：1）对项目管理知识结构要熟悉要做题2）还有技术部分也是3）法律法规是考前2周突击的4）组织级管理比较简单也可以做一做题，做题是帮助你建立知识结构的。5）论文一定要背44个子过程，需要写子过程的输入输出和工具方法。不要花太多时间在论文上面，参照下午辅导的5-4星级范文（281页）写2片论文提交上来，这就相当于考试时的模板套路了。案例分析需要从题干找线索，有思路就行。案例分析（形式化技巧）1）答题要编号2）答题时尽可能多用术语3）每条至少十五字4）空白之处要写满5）卷面整洁干净不出现任何涂改痕迹（形式比内容更重要）
5、千万不要用英文代替6）根据题干找答案7）问题前后是有关联的，看完题目再作答8）输入输出论文写作的建议：注意论文不能创新，必须要按照套路来写。论文写作的过程中不能有停顿，否则写作的时间就会不够，所以必须练习。看已发书的下午辅导：232页：论文框架背景+知识应用（理论联系实际）+总结379页：看B.2论文评分标准B，了解评分标准。233页：论文布局先写摘要一定要按照套路写235页正文写法：1.背景（准备800字）需要写明业务内容、工期等体现项目的真实性项目周期一般为：6-12个月，项目金额：软件项目100-1000万，硬件项目1亿左右，一定要写明自己在项目中的职务是项目经理。不要有图、表、流程图。
6、2.知识点应用（1000-1500字占正文的一半左右）每个子过程都需要单独标题分条叙述考试时不能打括号说明工具和方法需要举1-2个例子，例子一定要具体不要用XX代替。主要就是罗列输入输出方法后把实际工作经验镶嵌进去。3.项目总结可以先对前面的知识点应用回顾一遍，再指出不足。写总结时一定不能谦虚，对项目的评价都是好上加好略有不足，而且这些不足不能反映实际问题，最好是一些隔靴搔痒、可有可无的问题。附言：最新版的招标法（采购法合同法监理等）、软件工程规范的文档、综合布线、机房规范、技术部分（较难，软件占80%）、配置管理这些老师建议在考前2周看一下，这些内容都在作业系统的资料下载里面有个压缩文件夹“
7、曹老师补充上课资料（最新）”里面能够找到。这个是上课时老师讲到的我帮大家总结了一下希望能对大家有帮助。“程序流程图、数据流程图等”是结构化方法使用的主要分析设计工具，而“先开发一个简化系统，待用户认可后再开发最终系统”则是原型法的特征。安全审计属于安全管理类产品，安全审计产品主要包括主机类、网络类及数据库类和业务应用系统级的审计产品。国家电子政务总体框架的构成包括：服务与应用系统、信息资源、基础设施、法律法规与标准化体系、管理体制；推进国家电子政务建设，服务是宗旨，应用是关键，信息资源开发利用是主线，基础设施是支撑，法律法规、标准化体系、管理体制是保障。V 模型的价值在于它非常明确地标明了测试
8、过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。(1)单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。(2)集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。(3)系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行，例如在产品设置中是否能达到预期的高性能。(4)验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。在不同的开发阶段，会出现不同类型的缺陷和错误，所以需要不同的测试技术和方法来发现这些缺陷。结构化开发方法五个阶段的主要内容用结
9、构化系统开发方法开发一个系统，将整个开发过程划分为五个首尾相连接的阶段，一般称之为系统开发的生命周期，系统开发的生命周期分为系统规划、系统分析、系统设计、系统实施、系统运行和维护五个阶段。1系统规划系统规划的主要内容包括：企业目标的确定解决目标的方式的确定信息系统目标的确定信息系统主要结构的确定工程项目的确定可行性研究等2系统分析系统分析的主要内容包括：数据的收集数据的分析系统数据流程图的确定系统方案的确定等系统分析阶段是整个MIS建设的关键阶段。3系统设计系统设计的主要内容包括：系统流程图的确定程序流程图的确定编码输入、输出设计文件设计程序设计等4系统实施系统实施的主要内容包括：硬件设备的购
10、买硬件设备的安装数据准备程序的调试系统测试与转换人员培训等5系统运行与维护系统运行与维护的主要内容包括：系统投入运行后的管理及维护系统建成前后的评价发现问题并提出系统更新的请求等软件需求的具体内容计算机软件需求说明编制指南GB/T9385中定义了需求的具体内容，包括：（1功能需求：指描述软件产品的输入怎样变换成输出即软件必须完成的基本动作。对于每一类功能或者有时对于每一个功能需要具体描述其输入、加工和输出的需求。（2性能需求：从整体来说本条应具体说明软件或人与软件交互的静态或动态数值需求。静态数值需求可能包括：支持的终端数支付并行操作的用户数处理的文卷和记录数表和文卷的大小动态数值需求可包括欲
11、处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。所有这些需求都必须用可以度量的术语来叙述。例如，95%的事务必须在小于1s时间内处理完，不然操作员将不等待处理的完成。（3设计约束：设计约束受其他标准、硬件限制等方面的影响。（4属性：在软件的需求之中有若干个属性如可移植性、正确性、可维护性及安全性等。（5外部接口需求：包括用户接口、硬件接口、软件接口、通信接口。（6其他需求：根据软件和用户组织的特性等某些需求放在数据库、用户要求的常规的和特殊的操作、场合适应性需求中描述。由此可知：对特定范围内修改所需的时间不超过3秒性能需求。按照订单及原材料情况自动安排生产
12、排序功能需求。系统能够同时支持1000个独立站点的并发访问性能需求。系统可实现对多字符集的支持，包括GBK, BIG5和UTF-8等设计约束。定期生成销售分析报表功能需求系统实行同城异地双机备份，保障数据安全设计约束。软件需求的3 个层次：业务需求、用户需求和功能需求软件需求包括 3 个不同的层次业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。业务需求（ Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标
13、。使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。用户需求（ user requirement ）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求（ functional requirement ）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral
14、requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。系统需求（ system requirement ）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档
