信息系统项目管理师高级考试知识点汇总已编辑.docx
- 文档编号:5024587
- 上传时间:2022-12-12
- 格式:DOCX
- 页数:58
- 大小:156.99KB
信息系统项目管理师高级考试知识点汇总已编辑.docx
《信息系统项目管理师高级考试知识点汇总已编辑.docx》由会员分享,可在线阅读,更多相关《信息系统项目管理师高级考试知识点汇总已编辑.docx(58页珍藏版)》请在冰豆网上搜索。
信息系统项目管理师高级考试知识点汇总已编辑
信息系统工程项目中的硬件设备监理
我们知道三类信息系统工程项目--信息网络系统、信息资源系统与信息应用系统都需要硬件来支撑。
硬件监理在系统集成项目中占有很大比重。
简单谈谈我对几个项目中和硬件有关的几点监理体会,想到哪点就写写哪点吧,总不能让人看了直接来抢了我饭碗。
1、到货计划的审查要点。
重点最晚供货的设备到货时间和设备供货的时间优先级别,深入了解各设备是否需要从国外进口。
通常从国外进口货物在供货时间上更难把握,应预留足够的时间提前量。
必要时需要提供相关订单号和查询电话(或者网址)进行跟踪。
2、到货验收的审查要点。
检查货物存放场地的空间和安全保卫措施;检查货物外观包装情况,并用DV或者相机逐一取证。
重点检查装箱单与实物的一致性、设备的序列号。
3、设备的验证,关注出厂日期和保修条款,如果发现出厂日期与到货日期相关太远(每家产品会有差异),有可能是存货甚至是返修产品,应责成集成商提供足够理由和佐证材料。
大部分厂商的设备目前都可以在官方网站是查询,通过查询可以确认原厂部件。
特别要验证原厂服务是否与合同要求吻合。
4、设备的安装监理,着重安装人员及设备的安全措施,电源插座检查、电压检查。
安装过程是否规范,理线规范性和标签标识情况。
5、设备的配置与联调,要求先确定调试配置参数及相应的图纸,配置策略等。
先确认的呢单一设备的工作状态,再系统联调。
6、设备的测试与预验收。
先确定测试方案包括技术方案和测试计划,再按此方案中的步骤检查,确保一个同等知识要求的运维人员可以按此方案完成测试操作。
验证测试结果与预期的一致性。
7、设备的试运行跟踪,使用跟踪情况表,特别是问题产生原因和解决途径,要求这些内容写入运维手册的QA项.
8、使用与管理培训,先出培训教材和培训计划,最后要有培训效果检查表确认每个受训对象合格通过,培训演员对教师和环境等培训过程的反馈表。
9、正式验收。
。
。
。
重要是移交材料的完备性,明确售后服务详细流程。
。
。
。
。
小技巧:
网页自动转向代码
自动转向,也叫自动重定向。
自动跳转,指当访问用户登陆到某网站时,自动将用户转向其它网页地址的一种技术。
转向的网页地址可以是网站内的其它网页,也可以是其它网站。
通常情况下,浏览器会收到一个网页,该页面含有自动加载一其它网页的代码。
该页面有可能在服务器端被转换,这样的话,浏览器只收到一个页面,而自动转向往往意味着浏览器收到的页面具有自动将访问用户送至其它页面的功能。
对自动转向技术的合理应用包括:
将用户转向到指定浏览器的网页版本;当网站的域名变更或删除后将人们转向到新域名下,等等。
但现在这种技术却往往被搜索引擎优化人士用来作为提高网站的搜索引擎排名的一种手段。
例如,先专门针对搜索引擎做一个高度优化的网页,也就是我们通常所说的“桥页”,然后把这个网页提交给搜索引擎来获得好的排名。
但是,当搜索用户通过搜索引擎的搜索结果列表点击该网页列表进入后,将被自动转向到一个用户本来无意去访问的网站地址。
搜索引擎常常认为自动转向的网页是对读者的误导,所以它会对这种网页或网站施以惩戒,不过对一些自动转向方法它目前还无法自动检测出来。
MetaRefreshTag自动转向法
由于搜索引擎能够读取HTML,而Meta tags也是HTML,所以对于这种自动转向法,搜索引擎能够自动检测出来。
因而无论网站的转向出于什么目的,都很容易被搜索引擎视做对读者的误导而受到惩罚。
不过,如果跳转延迟时间设置合适,搜索引擎就不会视之为作弊。
页面定时刷新元标识(MetaRefreshTag)只能放在HTML代码的
区里。如下所示:
代码
以下是代码片段:
其中的“5”是告诉浏览器在页面加载5秒钟后自动跳转到page.htm这个页面。 这种方法常可以在论坛中见到。 如果在论坛上发信息,先会看到一个确认页面,几秒后会自动重新跳转回当前的论坛页面中。 从搜索引擎优化的角度出发,一般不希望自动转向有延迟。 不过,如果是用MetaRefresh标识进行转向,一定要注意把延迟时间设定成至少10秒以上。 “javascript”自动转向法 由于不能解析javascript,所以搜索引擎无法察觉(自动检测到)用javascript脚本进行的自动转向。 javascript自动重定向脚本可以放在网页的任何位置上,如果要求立即跳转,则可以将其放入网页源码的
用javascript实现跳转的范例如下:
方案1:
以下是代码片段:
--
window.location="http:
//solidot.org";
//-->
方案2:
以下是代码片段:
--
location.replace("");
-->
其中的“http:
//solidot.org"和"http:
//www.zz-"指特定的重定向目标地址,用相对/绝对URL地址均可。
用javascript实现自动重定向的好处在于:
用户所访问的目标URL不会保留在用户浏览器的历史记录中,如果用户按返回按钮返回,则将回到跳转前的网页,而不是包含javascript自动重定向脚本的跳转页面,所以不会出现当用户点击返回按钮后返回至重定向页,然后该页自动跳转到用户本来想离开的那个页面的尴尬情形。
如果需要,可以把javascript自动重定向脚本存在一个外部文件中,并通过下面的命令行来加载,其中“filename.js”是该外部文件的路径和文件名:
代码
注意:
若需实现即刻转向,或不希望人们看到转向前的那个页面,一般常用javascript脚本实现。
在这种情况下应将javascript脚本放入HTML源码的
区中。表单(FORM)自动转向法
搜索引擎的“爬行”程序是不会填写表单的,所以它们也不会注意到提交表单,因而可以利用表单来实现自动转向(重定向)而不让搜索引擎察觉。
对于表单,人们往往很少意识到:
表单的Action参数中包含的URL地址其实正是浏览器向服务器所请求的URL。
浏览器将会通过向请求的URL地址增加一些格式为name=value的参数给予它以特殊的对待。
在什么都没有的情况下,浏览器仍旧会为该URL安排请求至服务器。
用javascript脚本可让页面开始加载时即提交表单。
下面是一个用javascript实现表单自动提交,以及提交表单的范例:
以下是代码片段:
--document.myform.submit() //--> 其中“myform”可以是任意名称,“”用相对/绝对URL地址均可。 小结 如果访问用户最终看到的是他们想看到的,那么在搜索引擎优化中使用自动转向技术并没有什么不对,也并不是什么不道德的行为。 但有些人往往会在利用“自动跳转”技术,利用“桥页”吸引访问者,然后把他们送到他们无意浏览的页面或网站,这种做法只会引起访问用户的反感,又怎么能够期望访问流量可以有效转化为最终客户呢? 项目经理如何学会管理自己的领导 好像所有的人都会赞同沟通能力最重要,可是什么是沟通能力的内涵呢? 我觉得是: 清楚地表达、传递,并引导人们的表现朝你的期望发展。 这里的“人们”包括你的领导。 在一个项目开始前和进行中,跟你的领导始终沟通无碍,是项目成功的最大保障。 怎么才能和领导沟通好呢? 管理你的领导 有朋友说PM有权利调配资源,不够就去要。 现实中,基本上我们的项目最大的限制除了钱就是资源,资源很多情况都被领导掌握,PM哪有随便调资源的权利? 但是领导们都常常觉得,够了啊,总之你给我搞定。 PM要学会说“不”,制定计划的时候就要否定老大们不切实际的想法,但绝对不是上去就狂喊,而是说法上要有技巧,说“目标——步骤——难点——计划——资源”,领导们会容易接受一些。 就是说: 我们的目标,是要达到什么效果,还有范围是什么;步骤是1、2、3、4,先做什么再做什么;难点是什么,哪个地方容易出错,不管是技术难点还是管理难点,PM都要考虑在内。 比如技术上大家都没有做过,就是难点,比如管理上没有某个规则等等。 因为有了这些难点和目标,我们觉得时间计划是什么(保留适当的储备)——因为要实现这个计划,我们需要什么资源。 领导们听到最后,嗯,很有道理,他就要权衡了,给你资源么,不给? 不给重新讨价还价,目标要不要改? 时间要不要延长? 范围要不要缩小? 给,给当然好了,PM要到自己的东西了。 无论是制定目标还是过程中,你需要资源的时候都可以尝试用这种方法。 虽然很多时候资源是被领导掌握,但是身为PM要记着,领导也是我们的资源,你用他的思维方式,引导他去思考。 你要学会管理你的领导。 向领导暴露问题 就算这些资源都要到手了,我们就是承诺项目没问题吗? 当然不是啦。 领导们还是聪明而有经验的,他们都知道项目一定会有问题,他们不期望不出问题(他们基本都认为,不出问题的项目一定是有虚假信息,项目不可能不出问题),他们只是希望可控(问题可以被解决,知道对现有质量、进度、资源、预算的影响)。 所以PM千万不要心虚说,因为前面我要了这个那个,后面我就不可以出问题了,有问题就隐瞒。 恰恰相反,PM就是要在过程中暴露问题。 你说出来了,领导就是再不开心也知道解决问题最重要,所以他就会帮你解决问题,你就多了一个强有力的资源了。 暴露问题是要说: 问题是什么——为什么会出——如果不解决,对目标、范围、进度、质量、客户满意度、预算影响是什么——你觉得解决方案是什么? ——各自对上面6个维度的影响是什么,各自都有什么局限和好处? ——领导决策。 如果你也没解决方案(这样不算好的PM,但是没辙的时候也是会有的),你就做前面两步好了。 问老板,怎么办啊? 但无论是谁给的解决方案,也无论这个方案是什么,你最后都要向你的领导(当然包括你的所有利益相关者)说清楚,这样一个变更对目标、范围、进度、质量、客户满意度、预算的影响是什么。 让你的领导感觉,虽然会出问题,但是你至少让问题的影响可控了。 他在下一个问题出来前可以睡觉了。 什么时候汇报? 虽然我认为很少有PM会犯这个错误,但觉得还是说一说比较好。 周报是干嘛的? 其实很多时候虽然是一份常规的记录资料或文档,但最大的作用,我认为是保持所有人对项目的关注度。 让一些更大的老板、边缘的团队成员、边缘的利益相关者保持对项目的关注度;让核心团队成员有成就感: 我们做了那么多,还报告领导了。 我认为,周报或者叫周期性报告不是解决问题的,只是陈述性、总结性的。 一旦有了问题要马上汇报! 当然还要考虑上级领导的风格(他是事无巨细关注型还是抓大放小型)和PM的权利(什么样的问题有决策权)。 但一旦有了PM搞不定的问题,要马上汇报。 出了问题要随时解决、即时解决。 你想周期性报告一周一次? 一月一次? 那时候黄花菜都凉了。 所以马上汇报。 不要怕你的领导,因为耽误了时间更可怕。 项目经理如何处理好与不同类型客户之间的关系 作为项目经理,如何处理好与客户之间的关系非常重要。 但是究竟如何处理客户关系呢? 客户的人员都有哪些类型? 不同类型的客户的应对是否都一样呢? 下面我们来看看在日常工作中经常遇到的客户类型,应该如何处理跟他的关系。 权威决策型: 这类客户往往具有权威的技术、业务和管理能力,对于事情本身具有决策权。 应对策略: 正面应对,以技术服人。 典型决策者: 具有商务上的决策权,但是不是业务和技术的专家。 应对策略: 用通俗的语言表达技术和业务,尽量减缓正式的冲突,下面处理协调,效果会更好。 技术专家型: 只关心技术实现、细节和技术可行性。 应对策略: 直接正面应对,解释技术上的可行性和解决方案。 糊涂管理型: 是甲方的管理者,具有一定的决策权和影响力,但是对项目管理不懂装懂,不时干预项目的事情,有时是麻烦的制造者。 应对策略: 客气地拒绝,一定掌握主动权,一旦他掌握主动权,他会引导你项目的失败。 和稀泥型: 不承担责任,但也不得罪任何一方,不解决问题,但也不制造麻烦,属于老好人型。 应对策略: 别指望解决你的问题,可以利用大事化小,保持和气。 虚伪专家型: 技术和业务有一定了解但是都不是很深;多为新提拨的业务和技术骨干或多年被“埋没”的人才,喜欢卖弄点技术能力,缺少大局观。 应对策略: 或者成为利用的对象,或者让其远离你的项目,敬而远之。 从大局考虑,使其空,从技术的纵深考虑,使其服。 小人型: 阴奉阳维,表面一套背后一套,报复。 得志小人更是难缠。 应对策略: 不让其染指项目是最好的办法。 项目经理人与项目成员的实战指南 在一个团队中,作为一名团队领导,将: 1)避免团队目标向政治问题妥协 2)向团队目标显示个人承诺 3)不用太多优先级的事物冲淡团队的工作 4)公正、公平的对待团队成员 5)愿意面对和解决与团队成员不良表现有关的问题 6)对来自员工的新思维和新信息采取开放的态度 作为团队成员,要将: 1)展示对个人角色和责任的真正理解 2)展示目标和以事实为基础的判断 3)和其他团队成员有效地合作 4)使团队目标优先个人目标 5)展示投身于任何项目成功所需的努力的愿望 6)愿意分享信息、感受和产生适当的反馈 7)当其他成员需要时给予适当的帮助 8)展示对自己的高标准要求 9)支持团队决策 10)以为团队的成功而奋斗的方式体现带头作用 11)对别人的反馈做出积极的反应 项目接近尾声时不能忽视的10件事 对于你的组织规模,你可以把项目管理视为一项偶尔的实践或者可以拥有一个复杂的PMO。 不论那种情况,你可能通过典型的项目初始、精化和构建过程。 但是到了项目终结的时候,很多项目经理只讨论短期的终点线。 最后的步骤处理不好会给行动增加混乱并且可能导致客户不满、员工不悦,并把项目拖得比所需时间更长。 这里是一些你需要在达到你下一个项目的终点时要考虑的事情。 其中有些项目是纯管理的,但其中很多能帮助你进一步保证你的项目能够成功。 一、最终测试 测试会耗费人员,而我们很多人都不愿意去做——特别是做过几轮之后。 我见过大量的四到六个月的项目有一两天的计划去测试。 没有安排适当数量测试的项目通常在实施的最初几周内因问题而结束。 这里不要走捷径和将测试的重要性减至最小;否则,你会为痛苦的进展过程而承担额外的风险。 二、最终培训 用户? 谁关心用户? 好了,很多项目都为了他们的利益而做,所以确信把你所有的测试资料完成并移交。 这个不做好最有可能体现在发怒的客户半夜三更打来的愤怒的电话上。 三、确认交付物 你检查了所有的箱子并清理了收件箱,而且你想真地结束了。 但你的客户怎么想? 安排时间和你的客户检查所有的交付物并且确认他们已经得到满足了。 有些情况下,可能有一些特殊问题到你计划终止日期时尚未解决。 在你项目的早些时候,应该有一份协议来决定如果发生这样的情况会如何影响你的结束日期。 四、获得项目签字 当你获得所有交付物都已满足的认可以后,请求在项目文档上做一个正式的签字。 这样做帮助确保所有人都认可项目状态。 因为这个签字通常标志着项目的正式结束,注意不要让你的客户感觉签字的压力。 如果他们在不明所以的情况下做了,你可能会在日后出现问题的时候最终得到一个不满意的客户。 五、解散团队 现在项目完成了,你的团队何去何从? 基于你的组织,他们可能被送回一个开发池或者去做业务。 或者他们需要在企业内部为自己发起一些工作。 不管是什么,你要保证花点时间和他们在一起,并且设置一个明确的不再需要他们的服务的最后日期。 同时不要忘了你可能需要完成一些需要加入他们档案的业绩审核文档。 六、分析实际与计划的对比 资源——你是否真正摆脱了10周只有一个开发者/测试员,或者你需要去争夺并得到更多的人员? 你为你的商业伙伴安排的时间量怎么样? 明白你有多接近这些目标能帮助你为下一个项目更好地分配资源,并且在下一个项目来临时为它设定更切实的预期。 预算——项目要花费多少? 你是达到预算、未达到预算、超出预算? 坐下来弄明白这些基本问题的答案会给你一些对任何项目临界区域的洞察力。 七、存档文档 任何项目期间,好像我们都创建大量的文档。 其范围可能从范围文档和项目计划到合同和会议纪要。 不管是什么,在你结束时根据企业的保留策略应该有地方保存它们。 当两年后你的电话铃响起来并且有人要你解释项目期间你所做的一个决定的背后原理时,你将会很高兴。 八、确保合同终止 一个项目不常有自己的预算。 你可能还有硬件、软件或专业服务的合同。 在你完成以后,确认检查合同的所有项目都满足了,向供应商索要发票并把它们提交给AP,并且关闭任何相关的财务帐目,如果需要的话。 九、举行一个验尸会议 什么类型的风险你识别并减轻了? 你想用以确保下次再做的什么真的变好了? 和所有的项目利益相关者和有关参与者开个会,向他们提供了一个论坛来表述所学到的教训。 十、执行一个自我评估 终于结束了。 在所有的艰苦工作都完成以后,你已经确认所有的i都被加了点而且所有的t都加了横。 现在做什么? 从和你在项目中互动的人员那里得到一些关于你绩效的反馈是重要的。 如果你有机会发一份360度反馈调查给尽可能多的个人,我建议你这样去做。 这会帮助你评估你进步了多少并且能给你一些极大地提示来决定你该着眼于哪些个人成长的机会。 这个清单并不是对每个人都一样,并且根据你的组织和它如何部署项目会有不同。 但如果你能够去做,它会永远使到下一个项目的过渡更顺畅。 项目核心体制的角色和任务. 软件项目在开发过程中,拥有一个稳定的核心人员体制是非常重要的,这个核心体制中至少应该包含管理者、技术专家、业务专家三种角色。 当然如果条件允许,再配以配置管理员、品质管理员就更加完善了。 做为核心体制中的管理者,通常情况需要肩负以下责任: 1、做为窗口,与客户进行沟通交流,既要保证把项目的状况及时地反映给客户,也要把客户的需要及时准确的反映给开发团队; 2、决策。 对于项目中的一些重大事项进行决策,如开发平台和技术的选型、任务的分配以及人员的安排调度等; 3、服务。 做为项目的管理者,不能深入到项目的每一个开发细节中,但是一定要做好服务者,及时的了解和掌握项目进行过程中的各种需求,并适当给与解决和满足; 4、监控。 全面掌握项目的状况,保证作业过程中各种品质活动的必要性的完整性; 5、协调。 合理分配任务,协调各种作业间依赖关系,保证作业过程合理有序。 业务专家的核心任务是根据项目面向的应用领域,构建业务模型,业务模型中应该包含以下内容: 1、系统应用场景(这里用场景而不用环境,主要想与系统的运行环境进行区别)。 应用场景中应该包含系统所面向用户和用户数量、系统用户的工作环境和地点分布以及系统应用时间和频率等; 2、业务流程模型。 面向用户,构建完整的能够反映用户工作实际情况的工作流程,对于项目是否能够正常如期的交付并正确的放映客户的需求非常重要。 业务流程中对于不同环节中的依赖和约束一定要有清晰完整的描述; 3、业务数据模型。 数据做为软件系统的生产对象和消费对象,它会在系统中的不同功能模块间,甚至是不同系统间流动,在数据流动的过程中必须保证它的完整性、一致性和唯一性。 因此我们在构建数据流程时要充分考虑这些要素; 4、UI接口模型。 UI接口是用户使用系统的第一门户,因此一定要让这些接口尽早反映给客户,通过给客户演示或试用,收集用户的操作习惯,视觉反映等信息,不断的完善UI接口设计。 技术专家需要依赖业务专家的作业成果完成以下任务。 1、项目技术实现方案的设计。 这里包括开发平台、部署环境、开发技术的选择等等,做为技术责任者不但要了解系统的应用场景,还要了解开发团队的技术特点; 2、系统整体功能结构的设计。 我们需要根据业务流程,完成业务处理过程向计算机环境的合理转化,使系统的功能特点能够有效的反映业务流程的要求; 3、数据存储的设计。 我们需要根据业务数据模型,完成物力业务数据向逻辑存储结构的转化,保证数据能够在相关功能处理中正常的流动和存储。 4、功能接口规范的设计和制定。 功能接口是各相关功能模块间进行交互的门户,同时也是屏蔽模块内部细节门户。 接口规范不但能够保证模块间协调工作,同时还为各模块的并行开发提供出口和入口约束。 良好的接口规范应该具有清晰、简洁、易学、易用等特点; 4、作业任务分解。 在设计方案确认后,需要对方案中的各项作业内容进行合理有效分解,这样便于选择合适的团队或个人来完成对应的作业,以便降低作业难度和作业人员能力不匹配的风险; 5、基础核心模块的开发和审查。 条件允许的情况下,基础核心模块一定要由核心的团队或个人来开发完成,这样便于保证上层功能能够顺利实现,降低共通内容的重复开发,减少功能间的重叠。 项目管理新解: 项目管理图形学 在各种项目管理知识体系中,将项目管理进行了诸多的知识领域划分,总让人有种“雾里看花”的感觉。 长期从事某种项目管理知识体系的研究人员或许能够对知识领域、管理过程细细数落,但是对于非研究人员来说,比如项目管理工程实践的老手、项目管理的新手来说,如何快速上手、结合实践工程运用只怕比记忆一个知识管理体系要现实得多。 管理的精髓就是“把复杂的事简单化了”。 那么能否用图形化的方式来表达项目管理的方方面面呢? 就象软件需求建模用UML图形一样,如果项目管理的某个方面能用一两张图形来描述,稍作解说,那将特别有利于项目组内外人员的一致沟通。 笔者(编者注: CSAI顾问团高级顾问邓子云)将研究如何用图形化的方式来描述项目管理的领域称为项目管理图形学。 一谈到图形描述的问题,让人马上联想到什么样的图元表示什么样的含义,能不能有所扩展,分为哪些图形种类。 目前,在各种工程领域应用的图形种类已非常之多,有流程图、网络图、IDEF图等,不一而足,有的应用于特定的行业领域,有的有严格的约束。 项目管理需要体现很强的实践特性,用一两种图形似乎难以描述,也很难有严格的语义定义所需要表达的内容,项目管理工作的复杂性和多变性用工程技术领域中的图形描述又似乎不太合适。 不过,简单的总是好的,甚至会对项目管理工作带来极大的帮助,这就够了。 毕竟实用是这里坚持的首要原则。 下面概括出项目管理图形学研究的几个前提性的原则: (1)实用性原则。 偏向于项目管理实践工作应用,而不能偏向于学术研究。 主要用于使用图形可以方便地应用起来。 (2)易读性原则。 不追求严格的图元元素表述及语义要求,但要求图形容易被人所理解和沟通。 主要用于客户交流与优化阶段。 (3)简单化原则。 尽量用图来表达,而且少用文字,图形又要尽量简化。 主要用于简化图形阶
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息系统 项目 管理 高级 考试 知识点 汇总 编辑
![提示](https://static.bdocx.com/images/bang_tan.gif)