信息系统项目管理师高级学习资料大全.docx
《信息系统项目管理师高级学习资料大全.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师高级学习资料大全.docx（115页珍藏版）》请在冰豆网上搜索。
信息系统项目管理师高级学习资料大全
如何判断您的企业是否需要SOA管理
SOA管理是我经常谈论的一个话题，得到的反馈也是好坏参半，这是因为对愿意以及方式缺乏了解。
不管你的组织开始SOA多长时间，SOA管理都是需要多加注意的。
我将首先解释一下SOA管理需要注意的原因，而后再谈一下需要注意的方面。
但在我开始之前，我首先要澄清SOA管理与SOA治理的区别。
对于我来说，SOA管理是SOA治理的一部分。
SOA治理是由流程、标准以及政策来治理SOA实施的。
一个完整的SOA治理解决方案设计注册表、存储、管理变革、服务控制、服务质量、安全等等。
在此我将只谈SOA管理，对于多数厂商来说是服务控制、安全、业务流程可见度以及异常事件处理。
首先，让我们看看传统的智慧。
组织通常认为他们不需要SOA管理的原因在于没有足够的业务动力。
或者说：
“在我们的SOA架构还没建立起来的时候就需要SOA管理呢？
”这种想法正确吗？
你可以在读完这篇文章之后做出自己的决定。
我早前曾经提到过SOA实施像一场旅行，你的组织要达到一定的SOA成熟度是需要时间的。
在SOA实施的某一个时间点，SOA管理就会牵涉进来，原因有两点：
1.你的SOA架构将单个的应用程序和筒仓型业务功能变成了分布式服务。
随着灵活性和灵敏度的增加，安全和访问控制的复杂性也随之提高。
这就需要管理工具上的新想法。
2.即使是在基础的SOA环境中，你的组织也将需要SOA架构的可见度。
可见度的要求包括业务流程、服务使用、性能瓶颈等等。
随着你的环境变得越来越分散，使用原有的管理工具就会逐渐丧失可见度。
因此，当SOA促进你的业务时，你需要SOA促进你的管理环境去超越传统系统管理。
这是SOA发展的适当时机吗？
那么，什么时候才是考虑SOA管理的适当时机呢？
这个时间应该早于还是晚于你的SOA部署期呢？
决定因素有以下几点：
1访问权控制和安全是SOA管理提出的关键问题。
因此，SOA管理应该是你的SOA基础架构整体中不可分割的一部分，而不是随后加入。
从实际出发，你需要在SOA项目早期考虑安全和控制。
2有了妥善的规划，SOA管理将降低SOA项目的成本实施时间。
人们普遍认识到项目周期早期发生的改变/修复相较于晚期来说影响更小。
换句话说，你越晚决定对SOA管理提出的问题进行解决，对你之前所做决策的影响就会越大，而代价往往是巨大的。
3组织往往只有在出现问题的时候才会想到管理。
我们很难去量化由于基础架构中累赘服务或安全破坏所造成的干扰带来的成本。
你要做的不是去寻找救火措施，而是利用SOA管理工具主动的控制和监控业务。
4业务流程管理（BPM）是亚洲企业中的一大主题。
SOA实施则是另外一个主题。
SOA管理工具是BPM很好的补足解决方案。
在使用BPM的时候，多数企业都想如何利用BPM工具建立并管控其业务流程。
但是，我需要提出以下几个问题以供考虑：
1是不是所有的业务流程都能用BPM解决方案来定义？
2如果不是，那么你要如何处理那些没有被BPM工具定义的业务流程？
3这些业务流程是遵循最初设计构想来运作的吗？
换句话说，你要如何发现你的业务流程正导致一些始料未及的后果？
我认为大多数企业都无法通过BPM解决方案为所有的业务流程建模。
如果你的业务存在已久，那么就可能会比你想象中还要多的未定义业务流程。
一些SOA管理工具，带有自动发现功能，能弥补这一空白。
这些工具能够“看到”并告知你基础架构中正在发生的问题。
所以不要以你认为有效的方式模拟业务流程，而让你的SOA管理工具来告诉你真正发生的问题。
这不仅仅有利于IT针对应用和瓶颈下功夫，还有利于分析师看到实时的业务流程。
目前，我们已经讨论了进行SOA管理的原因，如果你认为你真正需要SOA管理，以下几点是在挑选解决方案时需要注意的：
注意事项：
1性能：
所有的管理和监控工具会带来一些开销，你需要确定你的系统性能不会受到太大的影响。
2标准支持：
你的业务是在异构的应用程序、服务和标准中运行的，你的管理解决方案也需要如此。
如果你需要改变基础架构投资以服务SOA管理，那么你有可能在寻找错误的解决方案。
3跨功能支持。
你的SOA基础架构可以跨越多个功能或应用解决问题，同样，你的SOA管理方案也是如此。
千万确保你所制定出的解决方案能够真正的满足IT部门的需要，同时也能满足业务分析人员，甚至可能会是保安人员的需要。
就如同整个企业架构体系中的其他资产一样，如果你能确切的知道SOA管理解决方案存在的意义以及如何使用将会让你获得更加明显的竞争优势。
那么，你是否真的需要SOA管理？
这个决定是由你选择的。
中小企业信息化：
资金与需求该如何权衡
小企业信息化考验IT人的能力
什么是小企业?
在我看来，小企业是特指那些已经度过了生存期、销售额在1亿到10亿元范围内、在特定细分行业或者区域内有独到之处的核心能力，看起来能够迅速发展的企业。
小企业的信息化矛盾体
在经济发达的地区，这样的小企业很多，造就了众多的亿万富翁。
同时，这样的企业在发展上则是上上下下、起起伏伏，绝大多数无法持续发展成为更大的规模化现代企业。
企业成功的独特优势受到挑战，与通用成熟的现代企业管理方法有严重的甚至根本的冲突，规模和区域扩展后外部环境的压力和复杂度超出想像和承受能力。
在这种情况下，信息化到底能够为小企业提供什么价值?
这个问题是一直困扰着信息经理或者信息总监或者CIO的一个事情。
我们知道，信息化是以系统化的体系和工具规范企业的运营方法和流程，让企业在一定的战略方向上持续稳定经营。
从管理不成熟的角度看，小企业确实不是做信息化的最好时期;但是，从企业发展的角度看，信息化又是小企业做强做大必不可少的工具。
这样的矛盾状态，使得小企业的信息化成为考验IT人残酷的熔炉。
小企业信息化“四核心”
“尊重环境，量力而行，保障基础，突出优势”似乎是小企业信息化的核心要义。
“尊重环境”是要根据企业文化、企业的管理风格、管理体系这个大环境，选择信息系统中能够有效体现这些特征的流程进行实施，在总体保证整体连续的业务流程的情况下，突出具有共识的重点环节，舍弃有争议的环节，在流程的基本面上保持“信息系统风格就是企业文化的反映”。
“量力而行”的重点不是投资上的量力而行。
通常情况下企业如果效益良好，投资不是问题。
这个“力”是指企业的“管理能力”或者是“管理成熟度”，以及企业的学习速度或者对系统化、规范化操作的学习能力。
一般情况下，企业通常高估自己的学习能力，低估过去的习惯势力，或者对信息系统给予太高的期望。
在实施信息系统的时候要么过低地估计使用系统对业务的改变，要么过高地估计自己的适应或者学习能力，或者相反。
这样会形成众多的冲突，截然相反的评估或者意见经常同时出现。
所以，对“能力”要做好充分的评估。
“保障基础”则是要保持信息系统的流程完整性，特别是供应链、资金链的流程，重点要放在使整个链条通畅，不必有太多花哨的功能。
开始是基本的核心流程，再在使用的过程中逐步优化、细化每步操作。
这样可以达到“麻雀虽小五脏俱全”，符合小企业使用大系统的基本规律，对未来的发展具备良好的扩充和支持能力，也为未来规范的组织发展奠定系统基础。
“突出优势”是小企业信息化的特征价值。
由于小企业一般会具备某些特殊或者特有的管理方法、业务流程让企业引以为豪，那就要特别关注这些特征，在信息系统中重点突出这些优势，固化在系统中继承下去。
这样的信息系统也才能够充分体现企业的文化和管理特征，得到广泛的认可。
总体来讲，由于小企业的管理尚未成熟，运营体系尚未职业化、标准化和系统化，企业发展速度和组织变动速度快，进行小企业信息化的时候要充分考虑这些因素。
无论是选择重型的ERP系统还是轻量级的专用系统，都需要在企业特征优势方面具有传承的作用，在规模化和规范化方面具有充分的空间，在流程上要注重核心流程的重点环节和保留未来优化的弹性空间，这样实现的信息系统就会十分切合小企业多方面的需求，也能够体现信息化在推动企业发展上的价值。
制作网页需要学习哪些技术
HTML4.01
HTML是Web的语言，每一个Web开发者都需要对它拥有基本的了解。
HTML4.01是重要的Web标准，它与HTML3.2的差异非常之大。
当类似font的标签和color属性被添加到HTML3.2后，它就逐渐成为开发人员们的一场噩梦。
开发那些必须把字体信息加入每个单独页面的网站，其过程成为了一种漫长而昂贵的折磨。
通过HTML4.01，所有的格式化信息可以被移出HTML文档，转而放入一个独立的样式表中。
HTML4.01之所以重要，另外一个原因是由于XHTML1.0，这个最新的HTML标准是作为一种XML应用被重新表达的HTML4.01。
在您的页面中使用HTML4.01可以确保在未来将HTML轻松升级到XHTML。
请确保您使用了最新的HTML4.01标准。
层叠样式表（CascadingStyleSheets-CSS）
样式可定义HTML元素如何被显示，类似font标签在HTML3.2中所起到的作用。
样式通常被保存在HTML文档之外的文件中。
外部样式表使您有能力仅仅通过编辑一个简单的CSS文档来改变网站内所有页面的外观和布局。
如果您曾经尝试过进行某些改变，比如同时改变站内所有网页标题的字体或颜色，您就会明白CSS如何能够达到事半功倍的效果。
XHTML-HTML的未来
XHTML指可扩展超文本标记语言（ExtensibleHyperTextMarkupLanguage）。
XHTML1.0是源自W3C的最新的HTML标准。
它于2000年1月26日成为正式的推荐标准（Recommendation）。
W3CRecommendation意味着其规范的稳定性，同时其规范目前已成为一种Web标准。
XHTML是一种使用XML进行重构的HTML4.01，并可以通过遵循一些简单的指导方针立即在现有的浏览器中投入使用。
XML-用于描述数据的工具
扩展标记语言（XML）并不是HTML的替代品。
在未来的web开发中，XML会被用来描述和存储数据，而HTML会被用来显示数据。
我们对XML最合适的描述是，一个跨平台的、独立与软硬件的，信息存储和传输工具。
我们相信XML的重要性不亚于HTML对于web的基础性地位，并且XML将会成为最重要的数据处理和传输工具。
XSLT-用户转换数据的工具
XSLT（可扩展的样式表语言转换，ExtensibleStylesheetLanguageTransformations），是用于转换XML的语言。
未来的网站将不得不向不同的浏览器并向其他web服务器以不同的格式传递数据。
而XSLT则是一种将XML数据转换为不同格式的新的W3C标准。
XSLT可以把XML文件转换为浏览器可识别的格式，比如HTML，或者WML-一种用于许多手持设备的标记语言。
XSLT还可以添加元素，并对元素进行删除、重新排列及排序，测试并确定显示哪些元素，等等。
客户端脚本
客户端脚本脚本是一种有关因特网浏览器行为的编程。
您应该学习JavaScript，这样才能有能力传递更多的动态网站内容：
JavaScript是为HTML设计者提供的一种的编程工具
HTML的创作者通常都不是程序员，但是JavaScript是一种语法非常简单的脚本语言!
几乎任何人都能够把某些JavaScript的代码片断放入他们的HTML页面中。
JavaScript可以在HTML页面中放入动态的文本
像这样的一条JavaScript语言可以在HTML页面中写入可变的文本：
document.write（"h1"+name+"/h1"）
JavaScript能够对事件进行反应
可以把JavaScript设置为在某事件执行时发生，比如当页面加载完毕或当用户点击某个HTML元素时。
JavaScript可读取并修改HTML元素
JavaScript能够读取并修改HTML元素的内容
JavaScript可被用来验证数据
可使用JavaScript在表单被提交到服务器前对表单数据进行验证，这样可确保服务器进行正确的数据处理。
服务器端脚本
服务器端脚本和因特网服务器编程有关。
您应该学习服务器端脚本，这样才能有能力传递更多的动态网站内容。
通过服务器端的编程，你可以：
动态地编辑、修改或添加网页内容
对用户从HTML提交的查询或数据进行响应
访问数据或数据库，并把结果返回浏览器
访问文件或XML数据，并把结果返回浏览器
把XML转换为HTML，并把结果返回到浏览器
为不同的用户定制页面，提高页面的可用性
对不同的网页提供安全和访问控制
为不同类型的浏览器设计不同的输出
最小化网络流量
使用SQL管理数据
结构化查询语言（SQL）是对诸如下列数据库进行访问的通用标准：
SQLServer、Oracle、Sybase以及Access。
对于那些希望从数据库存储和提取数据的人们来说，有关SQL的知识是极具价值的。
任何web管理员都应当明白，SQL对于web上的数据库来说，是一种真正切合的引擎。
站在别人的肩上:
项目管理的规则
美国著名软件工程专家勃姆（B.W.Boehm）在总结软件工程准则和信条的基础上，于1983年提出软件工程的7条基本原则，也是软件项目管理应该遵循原则。
勃姆认为，这7条原则是确保软件产品质量和开发效率的原理的最小集合，相互独立但结合得相当完备。
1.用分阶段的生命周期计划严格管理。
统计表明，不成功的软件项目中约有一半左右源自计划不周。
本原则意味着，应该把软件生命周期划分成若干阶段，相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。
勃姆认为，在软件的整个生命周期中应该制定并严格执行6类计划，即项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。
不同层次的管理人员必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受顾客或上级人员的影响而擅自背离预定计划。
2.坚持进行阶段评审。
软件的质量保证工作不能等到编码阶段结束之后再加以实施，其理由为：
第一，大部分错误始于编码之前；第二，错误的发现与修改时间越晚，需要付出的代价就越高。
因此，本原则意味着，在软件开发的每个阶段应该进行严格的评审，以便尽早发现软件开发过程中的错误。
3.实行严格的产品控制。
软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价；但是软件开发过程中改变需求又在所难免，基于外部环境的变化而出现改变用户需求的情况是一种客观需要，而且迅速应对客户的需求变更是顾客本位的内涵之一。
在这种情况下，只能依靠科学的产品控制技术来顺应这种要求。
当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。
所谓基准配置又称基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。
基准配置管理也称为变更控制：
一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。
避免开发人员对软件随意进行修改。
4.采用现代程序设计技术。
从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。
从60年代末提出的结构程序设计技术到最近的面向对象技术，人们不断创造先进的程序设计技术。
实践表明，采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。
5.结果应能清楚地审查。
与其他有形产品不同，软件是看不见摸不着的逻辑产品。
软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难以评价和管理。
为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
6.开发小组的人员应该少而精。
该原则意味着，软件开发项目的组成人员的素质应该好，而人数则不宜过多。
开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。
素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件。
此外，随着开发小组人员数目的增加，因为交流问题而造成的沟通成本也急剧增加。
因此，构建和维持少而精的开发团队甚至标杆团队是软件工程的一条基本原理。
7.承认不断改进软件工程实践的必要性。
遵循上述6条基本原则，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅遵循上述6条原则并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。
因此，勃姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原则。
按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。
威格的成功软件项目管理秘诀
过程影响（ProcessImpact）公司的首席咨询顾问卡尔。
威格（KarlE.Wiegers）在其《成功项目管理秘诀》（SecretsofSuccessfulProjectManagement）一文中总结了成功项目管理的20条秘诀：
构筑基础
1.定义项目成功标准；
2.识别项目的驱动、约束和自由度；
3.定义产品发布标准；
4.协商承诺。
规划工作
5.制作计划书；
6.将任务分解成较小的里程碑；
7.为共通的大任务开发计划工作表；
8.计划在质量控制活动后实施修改；
9.为过程改进安排时间；
10.管理项目的风险。
估算项目
11.根据工作量而不是日历估算；
12.不要为项目人员安排超过其80％的时间；
13.将培训时间纳入计划中；
14.记录估算以及如何达致估算；
15.利用估算工具；
16.尊重学习曲线；
17.考虑意外事件的缓冲。
追踪进展
18.记录实绩与估算；
19.只有当任务百分之百完成时，才认为该任务结束；
20.公开而诚实地跟踪项目状态。
麦克康奈尔的成功软件项目十大要决
史蒂夫。
麦克康奈尔（SteveMcConnell）在《成功软件项目的十大要决》（10KeystoSuccessfulSoftwareProjects）中阐述了成功软件项目的十大要决：
1.清晰的愿景；
2.稳定的、完整的、书面的需求；
3.详细的用户界面原型；
4.有效的项目管理；
5.精确的估算；
6.两阶段预算；
7.注重质量；
8.听取技术专家的意见；
9.积极的风险管理；
10.记住：
软件来源于人。
在组织间跨项目组加强推广学习优秀经验
以往对项目总结的认识不够，很多时候也就是写写PPT或者开个会，很多经验没有能被辨识出来成为案例，也就不能给大家分享。
特别是很多教训，人性的问题，没有被说出来，毕竟说出自己的不是不是每个人都能做到。
导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。
前段时间进行2008年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依赖于项目经理个人的能力。
我想我们不是要让每个人都没有自己的风格，项目经理当然有能力水平的高低，当然有不同的价值体现。
业主其实就是在说我们的项目实践必须积累。
在之前的博文《业主的改进意识让我惊讶，我们应该更加积极地看待和推进CMMi的改进！
》中讲到，一个业主的项目经理对口我们几个项目经理，A项目经理做得好的，业主方项目经理肯定会将A做得好的地方来要求公司的另一个项目经理B。
如果我们自己不传授这种经验，那才是傻子。
使用即将推行的CMMi的规程，重新Review一下2008年的各个项目，从中去分析各个项目组的强处以及弱项，从规程中扫漏洞，审视项目组的那些活动执行的力度和弱项之间的关系，对于来年指导项目建设是非常有帮助的。
今天在内审会议总结上，同事WN说得好，我们现在的项目经理花了很多时间在做事，其实缺少了时间思考如何去做事！
管理不仅是规范、监督，还有教练一职。
故事一则：
在组织间跨项目组加强推广学习优秀经验，除了会议交流、专题培训，还可以去现场实地体验加强感性认识（呵呵，共产党宣传的那一套都要学习用上）。
上次说到项目O和项目C整合上线，整个上线持续了近三天时间，有很多地方值得总结。
今天刚好有项目T正在组织部署上线，项目T的技术经理CC做为培训讲师以往培训过两次有关部署的工作，项目C的经理C当时也听过CC的课程，在没有和CC打招呼的前提，带上项目O和项目C的两位同事L和C到现场去抽查观摩，能够更加有感触其他同事的优秀实践。
到了现场，才知道项目T晚上6点才开始部署，因此安排两个项目的项目经理/技术经理进行现场的交流。
在简单介绍了此行的目的后，CC首先发言，询问C上次部署的过程中计划和实际工作最大的出入在那些地方？
通过近一个小时的访谈，同事C和L认识他们有不少改进的问题，这里讲最重点一点：
项目组C和项目组O在系统的正式部署前，缺少完整的演练。
虽然有部分的演练，但是没有通过演练将可能的问题辨识出来。
也因为如此，吃亏最多的迁移方案中的校验问题，没有能够提前暴露。
涉及到新旧两个系统的迁移，数据需要从系统O迁移到系统C，采用的方案是C直接访问O的数据方式，表面看这种方式最简单最直接，但是编写迁移和校验程序的同事都必须必须清晰了解C系统和系统O的业务逻辑，而实际由于逻辑覆盖不全面，导致校验的工作不完整，只使用抽样的方式即花了大量的人力（校验一个抽样数据，需要花20分钟人力），也导致有大量的迁移漏洞需要补救。
同事CC告诉C，应该采用接口交互表的方式，约定好规格，系统O的同事熟悉O的业务逻辑，负责将数据迁移到接口表，再由他们进行业务逻辑的检查，因为他们熟悉旧系统的逻辑啊！
检查完毕后，才由C负责从接口交互表中提取数据，C了解新系统的新业务逻辑，对接口交互表进行逻辑检查后，提取数据转换到新的系统。
采用两阶段的迁移，由熟悉旧系统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！
我在旁边插了话，其实如果旧系统是其他公司承建的，可能同事们就能想到两阶段迁移的接口交互表方式，可是我们两个系统由于是同一个部门承建，我们把部门边界和系统边界给混淆了，反而欲速而不达。
在网页中用JS函数控制Flash动画播放
一、介绍与Flash动画控制有关的javascript函数：
函数名
使用
作用
play（）
wgzc.play（）
播放Flash动画
stopplay（）
wgzc.stopplay（）
停止播放Flash动画
rewind（）
wgzc.rewind（）
停止播放Flash动画并返回第一帧
totalframes（）
wgzc.totalframes（）
返回Flash动画总帧数
gotoframe（intnum）
wgzc.gotoframe（intnum）
转到指定帧
二、程序代码：
functioninit（）
{
升级会员 