信息系统项目管理师高级学习杂乱知识大全

上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 如何判断您的企业是否需要 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上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 管理工具是 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亿元范围内、在特定细分行业或者区域内有独到之处的核心能力，看起来能够迅速发展的企业。小企业的信息化矛盾体上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 在经济发达的地区，这样的小企业很多，造就了众多的亿万富翁。同时，这样的企业在发展上则是上上下下、起起伏伏，绝大多数无法持续发展成为更大的规模化现代企业。企业成功的独特优势受到挑战，与通用成熟的现代企业管理方法有严重的甚至根本的冲突，规模和区域扩展后外部环境的压力和复杂度超出想像和承受能力。在这种情况下，信息化到底能够为小企业提供什么价值?这个问题是一直困扰着信息经理或者信息总监或者 CIO 的一个事情。我们知道，信息化是以系统化的体系和工具规范企业的运营方法和流程，让企业在一定的战略方向上持续稳定经营。从管理不成熟的角度看，小企业确实不是做信息化的最好时期;但是，从企业发展的角度看，信息化又是小企业做强做大必不可少的工具。这样的矛盾状态，使得小企业的信息化成为考验 IT 人残酷的熔炉。小企业信息化“四核心”“尊重环境，量力而行，保障基础，突出优势”似乎是小企业信息化的核心要义。“尊重环境”是要根据企业文化、企业的管理风格、管理体系这个大环境，选择信息系统中能够有效体现这些特征的流程进行实施，在总体保证整体连续的业务流程的情况下，突出具有共识的重点环节，舍弃有争议的环节，在流程的基本面上保持“信息系统风格就是企业文化的反映” 。“量力而行”的重点不是投资上的量力而行。通常情况下企业如果效益良好，投资不是问题。这个“力”是指企业的“管理能力”或者是“管理成熟度” ，以及企业的学习速度或者对系统化、规范化操作的学习能力。一般情况下，企业通常高估自己的学习能力，低估过去的习惯势力，或者对信息系统给予太高的期望。在实施信息系统的时候要么过低地估计使用系统对业务的改变，要么过高地估计自己的适应或者学习能力，或者相反。这样会形成众多的冲突，截然相反的评估或者意见经常同时出现。所以，对“能力”要做好充分的评估。“保障基础”则是要保持信息系统的流程完整性，特别是供应链、资金链的流程，重点要放在使整个链条通畅，不必有太多花哨的功能。开始是基本的核心流程，再在使用的过程中逐步优化、细化每步操作。这样可以达到“麻雀虽小五脏俱全” ，符合小企业使用大系统的基本规律，对未来的发展具备良好的扩充和支持能力，也为未来规范的组织发展奠定系统基础。“突出优势”是小企业信息化的特征价值。由于小企业一般会具备某些特殊或者特有的管理方法、业务流程让企业引以为豪，那就要特别关注这些特征，在信息系统中重点突出这些优势，固化在系统中继承下去。这样的信息系统也才能够充分体现企业的文化和管理特征，得到广泛的认可。总体来讲，由于小企业的管理尚未成熟，运营体系尚未职业化、标准化和系统化，企业发展速度和组织变动速度快，进行小企业信息化的时候要充分考虑这些因素。无论是选择重型的 ERP 系统还是轻量级的专用系统，都需要在企业特征优势方面具有传承的作用，在规模化和规范化方面具有充分的空间，在流程上要注重核心流程的重点环节和保留未来优化的弹性空间，这样实现的信息系统就会十分切合小企业多方面的需求，也能够体现信上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 息化在推动企业发展上的价值。制作网页需要学习哪些技术HTML 4.01HTML 是 Web 的语言，每一个 Web 开发者都需要对它拥有基本的了解。HTML 4.01 是重要的 Web 标准，它与 HTML 3.2 的差异非常之大。当类似 font 的标签和 color 属性被添加到 HTML 3.2 后，它就逐渐成为开发人员们的一场噩梦。开发那些必须把字体信息加入每个单独页面的网站，其过程成为了一种漫长而昂贵的折磨。通过 HTML 4.01，所有的格式化信息可以被移出 HTML 文档，转而放入一个独立的样式表中。HTML 4.01 之所以重要，另外一个原因是由于 XHTML 1.0，这个最新的 HTML 标准是作为一种 XML 应用被重新表达的 HTML 4.01。在您的页面中使用 HTML 4.01 可以确保在未来将 HTML 轻松升级到 XHTML。请确保您使用了最新的 HTML 4.01 标准。层叠样式表(Cascading Style Sheets - CSS)样式可定义 HTML 元素如何被显示，类似 font 标签在 HTML 3.2 中所起到的作用。样式通常被保存在 HTML 文档之外的文件中。外部样式表使您有能力仅仅通过编辑一个简单的CSS 文档来改变网站内所有页面的外观和布局。如果您曾经尝试过进行某些改变，比如同时改变站内所有网页标题的字体或颜色，您就会明白 CSS 如何能够达到事半功倍的效果。XHTML - HTML 的未来XHTML 指可扩展超文本标记语言(Extensible HyperText Markup Language)。XHTML 1.0 是源自 W3C 的最新的 HTML 标准。它于 2000 年 1 月 26 日成为正式的推荐标准(Recommendation)。W3C Recommendation 意味着其规范的稳定性，同时其规范目前已成为一种 Web 标准。XHTML 是一种使用 XML 进行重构的 HTML 4.01，并可以通过遵循一些简单的指导方针立即在现有的浏览器中投入使用。XML - 用于描述数据的工具扩展标记语言(XML)并不是 HTML 的替代品。在未来的 web 开发中，XML 会被用来描述和存储数据，而 HTML 会被用来显示数据。我们对 XML 最合适的描述是，一个跨平台的、独立与软硬件的，信息存储和传输工具。我们相信 XML 的重要性不亚于 HTML 对于 web 的基础性地位，并且 XML 将会成为最重要的数据处理和传输工具。上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html XSLT - 用户转换数据的工具XSLT(可扩展的样式表语言转换，Extensible Stylesheet Language Transformations)，是用于转换 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，并把结果返回到浏览器上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 为不同的用户定制页面，提高页面的可用性对不同的网页提供安全和访问控制为不同类型的浏览器设计不同的输出最小化网络流量使用 SQL 管理数据结构化查询语言(SQL)是对诸如下列数据库进行访问的通用标准：SQL Server、Oracle、Sybase 以及 Access。对于那些希望从数据库存储和提取数据的人们来说，有关 SQL 的知识是极具价值的。任何 web 管理员都应当明白，SQL 对于 web 上的数据库来说，是一种真正切合的引擎。站在别人的肩上:项目管理的规则美国著名软件工程专家勃姆（B.W.Boehm）在总结软件工程准则和信条的基础上，于1983 年提出软件工程的 7 条基本原则，也是软件项目管理应该遵循原则。勃姆认为，这 7条原则是确保软件产品质量和开发效率的原理的最小集合，相互独立但结合得相当完备。1.用分阶段的生命周期计划严格管理。统计表明，不成功的软件项目中约有一半左右源自计划不周。本原则意味着，应该把软件生命周期划分成若干阶段，相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。勃姆认为，在软件的整个生命周期中应该制定并严格执行 6 类计划，即项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。不同层次的管理人员必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受顾客或上级人员的影响而擅自背离预定计划。2.坚持进行阶段评审。软件的质量保证工作不能等到编码阶段结束之后再加以实施，其理由为：第一，大部分错误始于编码之前；第二，错误的发现与修改时间越晚，需要付出的代价就越高。因此，本原则意味着，在软件开发的每个阶段应该进行严格的评审，以便尽早发现软件开发过程中的错误。3.实行严格的产品控制。软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价；但是软件开发过程中改变需求又在所难免，基于外部环境的变化而出现改变用户需求的情况是一种客观需要，而且迅速应对客户的需求变更是顾客本位的内涵之一。在这种情况下，只能依靠科学的产品控制技术来顺应这种要求。当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码） 。基准配置管理也称为变更控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 施修改。避免开发人员对软件随意进行修改。4.采用现代程序设计技术。从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。从 60 年代末提出的结构程序设计技术到最近的面向对象技术，人们不断创造先进的程序设计技术。实践表明，采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。5.结果应能清楚地审查。与其他有形产品不同，软件是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难以评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。6.开发小组的人员应该少而精。该原则意味着，软件开发项目的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件。此外，随着开发小组人员数目的增加，因为交流问题而造成的沟通成本也急剧增加。因此，构建和维持少而精的开发团队甚至标杆团队是软件工程的一条基本原理。7.承认不断改进软件工程实践的必要性。遵循上述 6 条基本原则，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅遵循上述 6 条原则并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，勃姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原则。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。威格的成功软件项目管理秘诀过程影响（Process Impact）公司的首席咨询顾问卡尔。威格（Karl E.Wiegers）在其成功项目管理秘诀 （Secrets of Successful ProjectManagement）一文中总结了成功项目管理的 20 条秘诀：构筑基础1.定义项目成功标准；2.识别项目的驱动、约束和自由度；3.定义产品发布标准；4.协商承诺。规划工作5.制作计划书；6.将任务分解成较小的里程碑；7.为共通的大任务开发计划工作表；8.计划在质量控制活动后实施修改；9.为过程改进安排时间；10.管理项目的风险。上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 估算项目11.根据工作量而不是日历估算；12.不要为项目人员安排超过其 80的时间；13.将培训时间纳入计划中；14.记录估算以及如何达致估算；15.利用估算工具；16.尊重学习曲线；17.考虑意外事件的缓冲。追踪进展18.记录实绩与估算；19.只有当任务百分之百完成时，才认为该任务结束；20.公开而诚实地跟踪项目状态。麦克康奈尔的成功软件项目十大要决史蒂夫。麦克康奈尔（SteveMcConnell）在成功软件项目的十大要决 （10 Keys to Successful SoftwareProjects）中阐述了成功软件项目的十大要决：1.清晰的愿景；2.稳定的、完整的、书面的需求；3.详细的用户界面原型；4.有效的项目管理；5.精确的估算；6.两阶段预算；7.注重质量；8.听取技术专家的意见；9.积极的风险管理；10.记住：软件来源于人。在组织间跨项目组加强推广学习优秀经验以往对项目总结的认识不够，很多时候也就是写写 PPT 或者开个会，很多经验没有能被辨识出来成为案例，也就不能给大家分享。特别是很多教训，人性的问题，没有被说出来，毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。前段时间进行 2008 年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依赖于项目经理个人的能力。我想我们不是要让每个人都没有自己的风格，项目经理当然有能力水平的高低，当然有不同的价值体现。业主其实就是在说我们的项目实践必须积累。上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 在之前的博文业主的改进意识让我惊讶，我们应该更加积极地看待和推进 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 了解新系统的新业务逻辑，对接口交互表进行逻辑检查后，提取数据转换到新的系统。采用两阶段的迁移，由熟悉旧系统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！我在旁边插了话，其实如果旧系统是其他公司承建的，可能同事们就能想到两阶段迁移的接口交互表方式，可是我们两个系统由于是同一个部门承建，我们把部门边界和系统边界给混淆了，反而欲速而不达。 上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 在网页中用 JS 函数控制 Flash 动画播放一、介绍与 Flash 动画控制有关的 javascript 函数：函数名 使用 作用play() wgzc.play() 播放 Flash 动画stopplay() wgzc.stopplay() 停止播放 Flash 动画rewind() wgzc.rewind() 停止播放 Flash 动画并返回第一帧totalframes() wgzc.totalframes() 返回 Flash 动画总帧数 gotoframe(int num) wgzc.gotoframe(int num) 转到指定帧二、程序代码：function init() document.changeframe.totalfrm.value=document.wgzc.totalframes 控制 Flash 动画Flash 动画帧数:输入第帧,再点击“指定帧“。播放停止 停止返回第一帧上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 指定帧 以 WBS 为主线的集成项目管理任何流程或业务在我们学习的过程中始终都有一个主线，比如说知识管理的基础或主线是知识库和知识地图，ERP 的数据基础是 ITEM 和 BOM，主线是需求订单-MRP-生产计划和采购计划。对于产品数据管理 PDM 的主线是产品结构，对于 CRM 客户关系管理的主线是营销-市场策划-销售计划-预测-项目-合同。而对于项目管理其基础是 WBS 工作结构分解，其主线是项目结构-项目-WBS-工作包-活动-任务。上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 这条主线涉及到 PMBOK 里面的范围管理和进度管理两方面的内容。对于范围管理最终的输出就是范围说明书和 WBS，而对于进度管理则输入是 WBS，需要进行活动定义分解和排序，最终得到的进度表。在项目的执行过程中我们是按照具体的活动任务在执行，在执行的过程中会产生使用资源，消耗成本，产生文档和各种输出，进行设计开发，集成，评审和质量控制。我们活动分解的单位是到了具体的任务，但是我们产品的最终集成，我们的成本核算和挣值管理是不能到活动任务的。因此 WBS 在整个项目管理中就起到了重要作用，其作用不仅仅在前期确定项目范围和制定项目的进度计划，更多的是后期的挣值管理和更高层次的项目监控。如果没有完善的 WBS 分解，我们就很难做到这一步，我们的整个项目管理执行过程中的产出就是凌乱的，没有一个主线串起来。感兴趣的可以再去翻看下 PMBOK 各个过程域中各个过程组的 IPPO，可以发现很多过程的输入都有 WBS，足以见 WBS 在整个项目管理中的基础和核心作用。在这个图中还强调了下在 CMMI 三级中我们强调的生命周期模型定义过程裁剪，在组织级我们可以根据项目的不同特点将项目进行分类制定不同的项目生命周期模板，这样在有实际的项目来的时候，只需要根据项目的特点对模板内容进行自定义和裁剪，输入具体的需求项，即可以自动产生相应的 WBS。(该点后续单独在发文阐述)，这样自动生成的 WBS不仅仅实现了后续的主线跟踪，还实现了我们在 CMMI 二级中需要的需求追踪。一流软件领导的 10 个特征特征一：敢于设想他们是在不确定性上发展起来的技术空想家。软件领导者们必须生活于剃刀边缘。1987 年，在驱车沿法兰克福到沃尔多夫从一家 IBM 代理商那儿回家时，SAP 的创立者上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 普拉特纳、霍普和特奇拉决定为他们最畅销 SAP R2 企业解决方案软件创造一个新版本。新的 R/3 将利用一个可塑性强得多的设计。但是新产品应该运行于哪些系统之上呢？当时，许多大学刚刚开始使用 Unix，这是一个新的操作系统，允许在不同厂家的计算机之间构建网络，从而有可能创造一个新的系统结构: 客户/服务器模型。虽然有这些优点，它却相当不稳定，没有达到企业解决方案应用所需的表现水平。因此，尽管它提供了许多超过大型计算机的专业优势，许多从业者认为它永远不会取代那时的大型机。但普拉特纳不同意。他鼓吹为新的 R3 系统采用 Unix，从而指出了一种当时看上去高度投机和冒险的方向。他立刻在自己公司内陷入阻力之中。但是他相信他的远见于是运用他作为一个大股东的影响力，得到了董事会的同意。4 年之后，1991 年，SAP 向全世界推出了 R3，安装在一个小的 HP Unix 工作站。人们被震惊了。 “它几乎是可笑的， ”普拉特纳回忆道， “他们在说：这个小机器，带着一些存储器就是伟大的 SAP？ ”但是，这个小机器为SAP 在 ERP 市场的主导地位奠定了基础。基于 Unix 的 R3 向大群的 Windows PC 用户开放了 SAP，用一个“漂亮的前端吹走了“绿色显示屏之争” ，正如理查森波士顿的高等制造业研究公司的一位顾问所描述的。此外，基于 Unix 的 R3 的表现要比基于大型机的 R2 更好。R3 在全球 EPR 市场成了一个王牌产品。从 1992 年到 1998 年，单在美国，SAP 的收入就从 4500 万美元上升到 20 亿美元。是普拉特纳深入技术内部的洞察和他对未来发展的预见，使这一设想成为可能，也说明了软件领导者必须生活于剃刀边缘。软件业已经产生了许多其他的幻想家，他们在全球范围内改变了这个行业，从库比（他在很久以前就相信软件可以与硬件分开销售）和基恩（他于 1965 年在一家汽车轮胎铺里创立了他的软件服务公司） ，一直到比尔盖茨、埃里森和其他人。特征二：敢于冒险他们承受巨大的风险并希望有高额的回报。在梦想成真的路上，软件领导者们必须能够面对无数次风险。麦肯锡的调查显示，成功软件产品公司的领导者做出重要战略决定所花的时间平均要少 25，其原因并不主要是他们有更好的信息或市场研究，更多的来自他们的冒险精神。以莱曼特为例，他从学校退学，并在 1989 年建立了以得克萨斯州奥斯汀为所在地的Trilogy 软件公司，一家专门从事前台办公室销售和营销软件的公司。对莱曼特来说，决定冒险是很自然的。他告诉我们: “我想我不得不退学以抓住市场机遇。 ”没有一个风险资本家想资助他，所以莱曼特靠赊欠度日。不过创立 Trilogy 两年后，莱曼特从他冒险的愿望中得到了回报。他终于做成了与惠普的一笔 350 万美元的合同。其他有名的客户，像波音和朗讯也接踵而来。到 1996 年，莱曼特进入了福布斯 400 名富豪榜并成了其中最年轻的自力更生者，拥有估计 5 亿美元的净资产。在 1998 年，他有 850 名员上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 工，销售额超过 1 亿美元。莱曼特及其公司并非孤立的个案。安德烈森在他合作创立网景并开发因特网浏览器软件时只有 22 岁。比尔盖茨、巴尔默或 SAP 的普拉特纳同样都是冒险家，而且他们全都通过冒险而成了亿万富翁。特征三：多样选择他们在多个选择上押注，来为所有不确定性做准备。微软并不单单押注于它的 Windows PC 操作系统的成功，而是与 IBM 一起共同开发一个与之竞争的操作系统 OS2。SAP 是另一个例子。它没有去“塑造”这个行业，而是宁愿适应领先者的标准，同时在几个标准上花钱。作为 SAP 的总裁和 CEO，卡格曼评述说， SAP 可以从第二排看到表演不断发展。专业软件公司的领导人同样通过选择权处理不确定性。西姆斯是剑桥技术伙伴公司的 CEO，该公司是波士顿一家 6 亿美元的软件服务公司。他确保剑桥连续投资几个新兴公司，它们可能会开发出一个新的技术标准。 “我们与新技术一直保持接触， ”西姆斯说， “我们希望资助的这些公司之一有一天会成功。 ”但是，在通往成功的路上，软件领导者们必须接受不时的失败。事实上，失败并非是例外，而是惯例即使在成功的软件领导者之中。特征四：敢于尝试他们宁愿“迅速失败”而不是避免错误。“宁可做 6 个正确决定和 4 个错的，而不要等得太久， ”SAP 的霍普评述道。“Platinum 技术公司的 CTO 波佩克同意这个说法。 “快速移动是很重要的， ”他说， “这常常会导致错误，但错误是可以改正的。 ”看看陈丕宏在他创立了 BroadVision 之后是如何反应的。尽管这名企业家在电子商务解决方案上押对了赌注，他却在选择交互式电视（它看起来像是“未来的潮流” ）作为其产品的平台上犯了错误。事实上，当陈丕宏第一次看见因特网的时候，他的电视产品几乎已经完成了。特征五：强调速度陈丕宏几乎一夜之间就将 BroadVision 转变成了一家因特网公司。“对我来说非常清楚，我们错了，而且如果我们不迅速改弦易辙的话，我们就会失去一切。 ”陈丕宏回忆道。陈丕宏没有做长时间的讨论，而是几乎一夜之间就将公司转变成了一家因特网公司不顾他的经理们的反对。 “我几乎不得不解雇整个高层管理队伍，因为他们对变革没有信心。 ”他说。他的敏捷行动获得了结果，到 1998 年底，BroadVision 的市值超过了 7 亿美元。特征六：目标远大软件领导者们同样设定了非常高的期望。当菲利波夫斯基于 1987 年创立 Platinum 时，他决定在 10 年之内将其建成一个 10上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 亿美元收入的公司。菲利波夫斯基觉得他不得不动作迅速，因为他看到软件业正在迅速转向成熟。他同样明白在软件产品行业，只有领先者才能真正成功。 “对我来说，迅速壮大是件生死攸关的事。 ”他解释道。菲利波夫斯基并没有完全实现他的想法， “这花了我们 11 年，而不是 10 年。 ”他有些不好意思的承认。但是他的窘迫是可以忍受的，比尔盖茨花了 15 年才使微软达到 10亿美元，英特尔、Oracle 和 SAP 达到这个目标全都花了 10 年以上。只有思科的莫格里奇和钱伯斯击败了菲利波夫斯基，他们在 10 年里做到了这点。在麦肯锡的全球性调查中，发现高期望水平与公司的成功之间有非常强的相关性。在成功企业之中，93都有一个清晰、明确的远见，而在不成功企业中只有 25%有这样的雄心壮志。特征七：敢于变革他们是高度动态的组织的建立者。1995 年 12 月 7 日，比尔盖茨在微软的会议上宣布了一个突然的变革。他回顾历史，引用了日本海军上将山本五十六在日本进攻美国时所做的评论：“我担心我们惊醒了一个沉睡的巨人。 ”在这儿，这个巨人就是盖茨的公司，而进攻者是网景和因特网时代。盖茨清楚地看到进攻者们正在来临。在其存在的 20 个月里，网景已经将其 Navigator万维网浏览器推到了全世界的领先位置。该公司也进行了一次最为成功的公开上市。同一时间在微软， “我们确实有些错过了因特网航船， ”微软德国公司总经理罗伊这样承认。特征八：反应迅速他们都是看准趋势迅速行动的人。“这就是要改变的。 ”站在几百名程序分析员和记者面前，盖茨宣布他将重新调整每个项目和每个产品以迎接因特网的挑战。确实，整个微软的管理人员仓促地停止了几个数百万美元的项目并在数小时内启动了因特网项目。这些经理之一的路德维希走进一间满是程序员的屋子，命令道：“清除你们机器里的源代码，今天起就开始用 Java 工作。 ”为因特网浏览器工作的程序员的数目迅速从 8 人增长到 800 人。9 个月后，在 1996 年 8 月 13 日，微软的 IE30，新的具有竞争力的浏览器发布了。它在每个方面都赶上网景的 Navigator。在第一个星期，超过 100 万用户下载了这个免费软件。尽管两个公司之间的战斗 1998 年仍在进行，有一点已经十分清楚：微软已经在 6 个月略多一点的时间内成功地改变了一个庞大的有 2 万名员工的组织。要做到这点，需要从高层领导者那儿来的对巨大变革的极强的信心以及清晰、可交流的信息。让整个组织对这种剧烈变动做好准备是一项长期的任务。英特尔的格罗夫在谈到高技术公司中的管理时说：“你需要像一个救火部门那样做计划：它不能预计下一场火出现在哪儿，所以它不得不塑造一支富有活力和有效率的队伍，能像处理普通事务一样对突发事件做出反应。 ”特征九：善于管理他们建立十分平坦的、以团队为基础的组织。SAP 在 1996 年拥有 2 万名员工和 50 亿美元收入，它有一个 3 个层次的平坦的组织形态。在公司位于德国沃尔多夫的总部，咖啡机旁的墙上挂着总裁霍普讲演中的一段话。他上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 说：“对所有公司的新员工来说，在 SAP 这儿，我们是没有官僚主义并鼓励主动性的。 ”他还说：“这要求每个人有时得为往往不在正常工作任务之中的事情负责。 ”在专业软件服务中，构建以团队为基础的组织也是一个关键的领导任务。 “在专业服务中，获胜的是团队， ”基恩解释说， “但正因为如此，领导者也就成了专业服务里的关键。在产品行业，产品在整个公司范围内被聚合起来，而领导者们创造并代表它。在服务业，领导者得和谐安排和构建一支经过授权的队伍。 ”微软的首席营运官赫伯德，过去曾是消费品行业巨人宝洁的营销主管，在财经时代的一次采访中说，软件业的团队结构和平坦的等级制度是他对这个行业印象最深的。 “在宝洁，大多数的交流是手写的。它只能上下一个层次，与这个行业相比，它是相对迟缓的。所以你可能要花 4 个轮次的交流才能明白自己实际上弄乱了什么事情。在微软，我们以直接接触主题而自豪。 ”其他行业的管理者们也同意这一说法。 “像 Oracle 和 Sun 这样的软件公司都非常重视以团队为基础，我们喜欢仿效它们， ”Texaco 的石油勘探显示中心经理蔡特林说， “中层管理人员有权做决定。他们可以自行其是。这种文化感染了我。 ”特征十：创造文化他们创造了一种文化，它吸引和留住人才。当我们在芝加哥郊区访问 Platinum 公司时，我们问各个管理人员他们的公司给他们印象最深的是什么。从公司数据中心经理韦伯、营销执行副总裁马修斯和开发人员德莫特那儿，我们得到了同一个答案：菲利。他们说，CEO 菲利波夫斯基那与众不同的风格产生了巨大的影响。甚至菲利波夫斯基的办公室也与众不同，有数百个印度玩偶排列在墙上，一架大电视从天花板上吊下来，不停地播出因特网新闻服务。在另一个角落，供应的软饮料有 6 英尺高。 “初次来访的人总是感到惊讶。菲利确实是个十分特别的人， ”一名经理助理说。在她向我们展示菲利波夫斯基的办公室时，她的脸上闪过一丝微笑。她并非惟一一个：几乎每一个我们与之交谈的人在解释他们为什么进入这家公司和为什么喜欢在这儿工作时，都提到 Platinum 的这位领导者和他创造的文化。创造一种吸引人才的文化对软件领导者们是必不可少的，而且实际上，是他们最重要的挑战之一。需求管理的必要性及控制需求渐变的方法本文介绍了需求管理的必要性，并介绍了控制需求渐变的一些方法。软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：上学吧 上学吧为您提供信息系统项目管理师（高级）考试资料下载：h/share/e26.html 需求的描述问题一个已经进入了编码后期阶段的项目，该项目已经换过 2 次项目经理了，这是第 3 次更换项目经理，用户方的 IT 部经理找抱怨：“我已经是第 3 次来给你们讲补货申请的处理规则了!“。我只能表示抱歉，因为我无法找到原来的需求描述，这是一个变更的需求，前任的项目经理讲他只是将当时与用户交流的需求记到 2 页草稿纸上，不幸的是，那 2 页珍贵的手稿现在已经找不到了!更不幸的是，该 IT 部经理是在转述业务部门的需求，当软件开发完毕后，业务部门讲“这不是我们最初给 IT 部反映的需求，我们说的不是这样的!“。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。曾经有多个项目经理抱怨，在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户(用户)关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。需求的完备程度问题需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。需求开发的工期问题在需求上花费了大量的时间(而不是人*工时，因为需求阶段人多了也没有作用)，客户、软件公司是否能够忍受?为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。需求的细致程度问题需求到底描述到多细，才算可以结束了?仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家(客户、用户、需求分析人员、设计人员