信息系统项目管理师高级学习大全.pdf

《信息系统项目管理师高级学习大全.pdf》由会员分享，可在线阅读，更多相关《信息系统项目管理师高级学习大全.pdf（50页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、如何判断您的企业是否需要SOA管理SOA 管理是我经常谈论的一个话题，得到的反馈也是好坏参半，这是因为对愿意以及方式缺乏了解。 不管你的组织开始SOA 多长时间， SOA管理都是需要多加注意的。我将首先解释一下SOA管理需要注意的原因，而后再谈一下需要注意的方面。但在我开始之前， 我首先要澄清SOA管理与 SOA 治理的区别。 对于我来说， SOA管理是 SOA治理的一部分。 SOA治理是由流程、标准以及政策来治理SOA 实施的。一个完整的SOA治理解决方案设计注册表、存储、管理变革、服务控制、服务质量、安全等等。在此我将只谈SOA管理，对于多数厂商来说是服务控制、安全、业务流程可见度以及异常

2、事件处理。首先，让我们看看传统的智慧。组织通常认为他们不需要SOA 管理的原因在于没有足够的业务动力。 或者说： “在我们的 SOA 架构还没建立起来的时候就需要SOA管理呢”这种想法正确吗你可以在读完这篇文章之后做出自己的决定。我早前曾经提到过SOA实施像一场旅行， 你的组织要达到一定的SOA成熟度是需要时间的。在SOA实施的某一个时间点，SOA管理就会牵涉进来，原因有两点：1. 你的 SOA架构将单个的应用程序和筒仓型业务功能变成了分布式服务。随着灵活性和灵敏度的增加，安全和访问控制的复杂性也随之提高。这就需要管理工具上的新想法。2. 即使是在基础的SOA环境中，你的组织也将需要SOA架构

3、的可见度。可见度的要求包括业务流程、服务使用、性能瓶颈等等。随着你的环境变得越来越分散，使用原有的管理工具就会逐渐丧失可见度。因此，当SOA促进你的业务时，你需要 SOA促进你的管理环境去超越传统系统管理。这是 SOA发展的适当时机吗那么，什么时候才是考虑SOA管理的适当时机呢这个时间应该早于还是晚于你的 SOA 部署期呢决定因素有以下几点：1 访问权控制和安全是SOA 管理提出的关键问题。 因此，SOA 管理应该是你的SOA基础架构整体中不可分割的一部分，而不是随后加入。 从实际出发， 你需要在SOA项目早期考虑安全和控制。2 有了妥善的规划， SOA管理将降低 SOA项目的成本实施时间。人

4、们普遍认识到项目周期早期发生的改变/ 修复相较于晚期来说影响更小。换句话说，你越晚决定对 SOA管理提出的问题进行解决，对你之前所做决策的影响就会越大，而代价往往是巨大的。3 组织往往只有在出现问题的时候才会想到管理。我们很难去量化由于基础架构中累赘服务或安全破坏所造成的干扰带来的成本。你要做的不是去寻找救火措施，而是利用SOA管理工具主动的控制和监控业务。4 业务流程管理（ BPM ）是亚洲企业中的一大主题。SOA实施则是另外一个主题。 SOA管理工具是 BPM 很好的补足解决方案。在使用 BPM 的时候， 多数企业都想如何利用BPM 工具建立并管控其业务流程。但是，我需要提出以下几个问题以

5、供考虑：1 是不是所有的业务流程都能用BPM 解决方案来定义2 如果不是，那么你要如何处理那些没有被BPM工具定义的业务流程3 这些业务流程是遵循最初设计构想来运作的吗换句话说，你要如何发现你的业务流程正导致一些始料未及的后果我认为大多数企业都无法通过BPM 解决方案为所有的业务流程建模。如果你的业务存在已久，那么就可能会比你想象中还要多的未定义业务流程。一些SOA管理工具，带有自动发现功能，能弥补这一空白。这些工具能够“看到”并告知你基础架构中正在发生的问题。所以不要以你认为有效的方式模拟业务流程，而让你的 SOA管理工具来告诉你真正发生的问题。这不仅仅有利于IT 针对应用和瓶颈下功夫，还有

6、利于分析师看到实时的业务流程。目前，我们已经讨论了进行SOA管理的原因，如果你认为你真正需要SOA管理，以下几点是在挑选解决方案时需要注意的：注意事项：1 性能：所有的管理和监控工具会带来一些开销，你需要确定你的系统性能不会受到太大的影响。2 标准支持：你的业务是在异构的应用程序、服务和标准中运行的，你的管理解决方案也需要如此。如果你需要改变基础架构投资以服务SOA管理，那么你有可能在寻找错误的解决方案。3 跨功能支持。你的SOA基础架构可以跨越多个功能或应用解决问题，同样，你的 SOA管理方案也是如此。千万确保你所制定出的解决方案能够真正的满足IT部门的需要，同时也能满足业务分析人员，甚至可

7、能会是保安人员的需要。就如同整个企业架构体系中的其他资产一样，如果你能确切的知道SOA管理解决方案存在的意义以及如何使用将会让你获得更加明显的竞争优势。那么，你是否真的需要SOA管理这个决定是由你选择的。中小企业信息化：资金与需求该如何权衡小企业信息化考验IT 人的能力什么是小企业在我看来，小企业是特指那些已经度过了生存期、销售额在 1 亿到 10 亿元范围内、在特定细分行业或者区域内有独到之处的核心能力，看起来能够迅速发展的企业。小企业的信息化矛盾体在经济发达的地区，这样的小企业很多，造就了众多的亿万富翁。同时，这样的企业在发展上则是上上下下、起起伏伏，绝大多数无法持续发展成为更大的规模化现

8、代企业。企业成功的独特优势受到挑战，与通用成熟的现代企业管理方法有严重的甚至根本的冲突，规模和区域扩展后外部环境的压力和复杂度超出想像和承受能力。在这种情况下，信息化到底能够为小企业提供什么价值这个问题是一直困扰着信息经理或者信息总监或者CIO的一个事情。我们知道， 信息化是以系统化的体系和工具规范企业的运营方法和流程，让企业在一定的战略方向上持续稳定经营。从管理不成熟的角度看，小企业确实不是做信息化的最好时期; 但是，从企业发展的角度看，信息化又是小企业做强做大必不可少的工具。 这样的矛盾状态， 使得小企业的信息化成为考验IT 人残酷的熔炉。小企业信息化“四核心”“尊重环境，量力而行，保障基

9、础，突出优势”似乎是小企业信息化的核心要义。“尊重环境”是要根据企业文化、企业的管理风格、管理体系这个大环境，选择信息系统中能够有效体现这些特征的流程进行实施，在总体保证整体连续的业务流程的情况下，突出具有共识的重点环节，舍弃有争议的环节，在流程的基本面上保持“信息系统风格就是企业文化的反映”。“量力而行”的重点不是投资上的量力而行。通常情况下企业如果效益良好，投资不是问题。这个“力”是指企业的“管理能力”或者是“管理成熟度”，以及企业的学习速度或者对系统化、规范化操作的学习能力。一般情况下，企业通常高估自己的学习能力，低估过去的习惯势力，或者对信息系统给予太高的期望。在实施信息系统的时候要么

10、过低地估计使用系统对业务的改变，要么过高地估计自己的适应或者学习能力，或者相反。这样会形成众多的冲突，截然相反的评估或者意见经常同时出现。所以，对“能力”要做好充分的评估。“保障基础”则是要保持信息系统的流程完整性，特别是供应链、资金链的流程，重点要放在使整个链条通畅，不必有太多花哨的功能。开始是基本的核心流程，再在使用的过程中逐步优化、细化每步操作。这样可以达到“麻雀虽小五脏俱全” ，符合小企业使用大系统的基本规律，对未来的发展具备良好的扩充和支持能力，也为未来规范的组织发展奠定系统基础。“突出优势” 是小企业信息化的特征价值。由于小企业一般会具备某些特殊或者特有的管理方法、业务流程让企业引

11、以为豪，那就要特别关注这些特征，在信息系统中重点突出这些优势，固化在系统中继承下去。这样的信息系统也才能够充分体现企业的文化和管理特征，得到广泛的认可。总体来讲，由于小企业的管理尚未成熟，运营体系尚未职业化、标准化和系统化，企业发展速度和组织变动速度快，进行小企业信息化的时候要充分考虑这些因素。无论是选择重型的ERP系统还是轻量级的专用系统，都需要在企业特征优势方面具有传承的作用，在规模化和规范化方面具有充分的空间，在流程上要注重核心流程的重点环节和保留未来优化的弹性空间，这样实现的信息系统就会十分切合小企业多方面的需求，也能够体现信息化在推动企业发展上的价值。制作网页需要学习哪些技术HTML

12、 HTML 是 Web的语言，每一个Web开发者都需要对它拥有基本的了解。HTML 是重要的 Web标准，它与 HTML 的差异非常之大。当类似 font的标签和 color属性被添加到HTML 后，它就逐渐成为开发人员们的一场噩梦。开发那些必须把字体信息加入每个单独页面的网站，其过程成为了一种漫长而昂贵的折磨。通过 HTML ，所有的格式化信息可以被移出HTML 文档，转而放入一个独立的样式表中。HTML 之所以重要，另外一个原因是由于XHTML ，这个最新的HTML标准是作为一种 XML应用被重新表达的HTML 。在您的页面中使用HTML 可以确保在未来将HTML 轻松升级到 XHTML

13、。请确保您使用了最新的HTML 标准。层叠样式表 (Cascading Style Sheets - CSS) 样式可定义 HTML 元素如何被显示，类似font标签在 HTML 中所起到的作用。样式通常被保存在HTML 文档之外的文件中。 外部样式表使您有能力仅仅通过编辑一个简单的CSS文档来改变网站内所有页面的外观和布局。如果您曾经尝试过进行某些改变，比如同时改变站内所有网页标题的字体或颜色，您就会明白CSS如何能够达到事半功倍的效果。XHTML - HTML的未来XHTML 指可扩展超文本标记语言(Extensible HyperText Markup Language)。XHTML 是

14、源自 W3C 的最新的 HTML 标准。它于2000 年 1 月 26 日成为正式的推荐标准 (Recommendation) 。W3C Recommendation意味着其规范的稳定性，同时其规范目前已成为一种Web标准。XHTML 是一种使用 XML进行重构的 HTML ，并可以通过遵循一些简单的指导方针立即在现有的浏览器中投入使用。XML - 用于描述数据的工具扩展标记语言 (XML)并不是 HTML 的替代品。在未来的web开发中， XML会被用来描述和存储数据，而HTML 会被用来显示数据。我们对 XML最合适的描述是，一个跨平台的、独立与软硬件的，信息存储和传输工具。我们相信 XM

15、L的重要性不亚于HTML对于 web的基础性地位，并且XML将会成为最重要的数据处理和传输工具。XSLT - 用户转换数据的工具XSLT(可 扩 展 的 样 式 表 语 言 转 换 ， Extensible Stylesheet Language Transformations)，是用于转换XML的语言。未来的网站将不得不向不同的浏览器并向其他web 服务器以不同的格式传递数据。而 XSLT则是一种将 XML数据转换为不同格式的新的W3C 标准。XSLT可以把 XML文件转换为浏览器可识别的格式，比如HTML ，或者 WML - 一种用于许多手持设备的标记语言。XSLT还可以添加元素，并对元素

16、进行删除、重新排列及排序，测试并确定显示哪些元素，等等。客户端脚本客 户 端 脚 本 脚 本 是 一 种 有 关 因 特 网 浏 览 器 行 为 的 编 程 。 您 应 该 学 习JavaScript，这样才能有能力传递更多的动态网站内容：JavaScript是为 HTML 设计者提供的一种的编程工具HTML 的创作者通常都不是程序员，但是JavaScript是一种语法非常简单的脚本语言 ! 几乎任何人都能够把某些JavaScript的代码片断放入他们的HTML 页面中。JavaScript可以在 HTML 页面中放入动态的文本像这样的一条JavaScript语言可以在HTML 页面中写入可变

17、的文本：(h1 + name + /h1) JavaScript能够对事件进行反应可以把 JavaScript设置为在某事件执行时发生，比如当页面加载完毕或当用户点击某个HTML 元素时。JavaScript可读取并修改HTML 元素JavaScript能够读取并修改HTML 元素的内容JavaScript可被用来验证数据可使用 JavaScript在表单被提交到服务器前对表单数据进行验证，这样可确保服务器进行正确的数据处理。服务器端脚本服务器端脚本和因特网服务器编程有关。您应该学习服务器端脚本，这样才能有能力传递更多的动态网站内容。通过服务器端的编程，你可以：动态地编辑、修改或添加网页内容对

18、用户从 HTML提交的查询或数据进行响应访问数据或数据库，并把结果返回浏览器访问文件或 XML数据，并把结果返回浏览器把 XML转换为 HTML ，并把结果返回到浏览器为不同的用户定制页面，提高页面的可用性对不同的网页提供安全和访问控制为不同类型的浏览器设计不同的输出最小化网络流量使用 SQL管理数据结构化查询语言 (SQL)是对诸如下列数据库进行访问的通用标准：SQL Server 、Oracle 、Sybase 以及 Access。对于那些希望从数据库存储和提取数据的人们来说，有关SQL的知识是极具价值的。任何 web管理员都应当明白， SQL对于 web上的数据库来说， 是一种真正切合的

19、引擎。站在别人的肩上 : 项目管理的规则1. 用分阶段的生命周期计划严格管理。统计表明，不成功的软件项目中约有一半左右源自计划不周。本原则意味着，应该把软件生命周期划分成若干阶段，相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。勃姆认为，在软件的整个生命周期中应该制定并严格执行6 类计划，即项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。不同层次的管理人员必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受顾客或上级人员的影响而擅自背离预定计划。2. 坚持进行阶段评审。软件的质量保证工作不能等到编码阶段结束之后再加以实施，其理由为

20、：第一，大部分错误始于编码之前；第二，错误的发现与修改时间越晚，需要付出的代价就越高。因此，本原则意味着，在软件开发的每个阶段应该进行严格的评审，以便尽早发现软件开发过程中的错误。3. 实行严格的产品控制。软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价；但是软件开发过程中改变需求又在所难免，基于外部环境的变化而出现改变用户需求的情况是一种客观需要，而且迅速应对客户的需求变更是顾客本位的内涵之一。在这种情况下，只能依靠科学的产品控制技术来顺应这种要求。当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称基线配

21、置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。基准配置管理也称为变更控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。避免开发人员对软件随意进行修改。4. 采用现代程序设计技术。从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。从 60 年代末提出的结构程序设计技术到最近的面向对象技术，人们不断创造先进的程序设计技术。实践表明，采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。5. 结果应能清楚地审查。与其他有形产品不同，软件是看不见摸不着的逻辑产品。软件开发人员

22、的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难以评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。6. 开发小组的人员应该少而精。该原则意味着，软件开发项目的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件。此外，随着开发小组人员数目的增加，因为交流问题

23、而造成的沟通成本也急剧增加。因此，构建和维持少而精的开发团队甚至标杆团队是软件工程的一条基本原理。7. 承认不断改进软件工程实践的必要性。遵循上述6 条基本原则，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅遵循上述6 条原则并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，勃姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原则。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。威格的成功软件项目管理秘诀过程影响（ Process Impact ）公司的首席咨询顾问卡尔。威格（Karl ）在其成功项目管理秘诀

24、（Secrets of Successful ProjectManagement）一文中总结了成功项目管理的20 条秘诀：构筑基础1. 定义项目成功标准；2. 识别项目的驱动、约束和自由度；3. 定义产品发布标准；4. 协商承诺。规划工作5. 制作计划书；6. 将任务分解成较小的里程碑；7. 为共通的大任务开发计划工作表；8. 计划在质量控制活动后实施修改；9. 为过程改进安排时间；10. 管理项目的风险。估算项目11. 根据工作量而不是日历估算；12. 不要为项目人员安排超过其80的时间；13. 将培训时间纳入计划中；14. 记录估算以及如何达致估算；15. 利用估算工具；16. 尊重学习曲

25、线；17. 考虑意外事件的缓冲。追踪进展18. 记录实绩与估算；19. 只有当任务百分之百完成时，才认为该任务结束；20. 公开而诚实地跟踪项目状态。麦克康奈尔的成功软件项目十大要决史蒂夫。麦克康奈尔（SteveMcConnell ）在成功软件项目的十大要决（10 Keys to Successful SoftwareProjects）中阐述了成功软件项目的十大要决：1. 清晰的愿景；2. 稳定的、完整的、书面的需求；3. 详细的用户界面原型；4. 有效的项目管理；5. 精确的估算；6. 两阶段预算；7. 注重质量；8. 听取技术专家的意见；9. 积极的风险管理；10. 记住：软件来源于人。在

26、组织间跨项目组加强推广学习优秀经验以往对项目总结的认识不够，很多时候也就是写写PPT或者开个会， 很多经验没有能被辨识出来成为案例，也就不能给大家分享。特别是很多教训，人性的问题，没有被说出来，毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。前段时间进行2008 年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依赖于项目经理个人的能力。我想我们不是要让每个人都没有自己的风格，项目经理当然有能力水平的高低，当然有不同的价值体现。业主其实就是在说我们的项目实践必须积累。在之前的博文 业主的改进意识让我

27、惊讶，我们应该更加积极地看待和推进 CMMi的改进！中讲到， 一个业主的项目经理对口我们几个项目经理，A项目经理做得好的，业主方项目经理肯定会将A 做得好的地方来要求公司的另一个项目经理 B。如果我们自己不传授这种经验，那才是傻子。使用即将推行的CMMi的规程，重新Review 一下 2008 年的各个项目，从中去分析各个项目组的强处以及弱项，从规程中扫漏洞，审视项目组的那些活动执行的力度和弱项之间的关系，对于来年指导项目建设是非常有帮助的。今天在内审会议总结上，同事WN 说得好，我们现在的项目经理花了很多时间在做事，其实缺少了时间思考如何去做事！管理不仅是规范、监督，还有教练一职。故事一则：

28、在组织间跨项目组加强推广学习优秀经验，除了会议交流、专题培训，还可以去现场实地体验加强感性认识（呵呵，共产党宣传的那一套都要学习用上）。上次说到项目O和项目 C整合上线，整个上线持续了近三天时间，有很多地方值得总结。今天刚好有项目T正在组织部署上线，项目T 的技术经理 CC做为培训讲师以往培训过两次有关部署的工作，项目C的经理 C当时也听过 CC的课程，在没有和 CC打招呼的前提，带上项目 O和项目 C的两位同事L 和 C到现场去抽查观摩，能够更加有感触其他同事的优秀实践。到了现场， 才知道项目 T 晚上 6 点才开始部署， 因此安排两个项目的项目经理 / 技术经理进行现场的交流。在简单介绍了

29、此行的目的后，CC首先发言， 询问C 上次部署的过程中计划和实际工作最大的出入在那些地方通过近一个小时的访谈，同事 C 和 L 认识他们有不少改进的问题，这里讲最重点一点：项目组C 和项目组 O 在系统的正式部署前，缺少完整的演练。虽然有部分的演练，但是没有通过演练将可能的问题辨识出来。也因为如此，吃亏最多的迁移方案中的校验问题，没有能够提前暴露。涉及到新旧两个系统的迁移，数据需要从系统O迁移到系统 C，采用的方案是 C 直接访问 O的数据方式，表面看这种方式最简单最直接，但是编写迁移和校验程序的同事都必须必须清晰了解C 系统和系统O的业务逻辑，而实际由于逻辑覆盖不全面， 导致校验的工作不完整

30、，只使用抽样的方式即花了大量的人力（校验一个抽样数据，需要花20 分钟人力），也导致有大量的迁移漏洞需要补救。同事 CC告诉 C，应该采用接口交互表的方式，约定好规格，系统O的同事熟悉 O的业务逻辑，负责将数据迁移到接口表，再由他们进行业务逻辑的检查，因为他们熟悉旧系统的逻辑啊！检查完毕后，才由C 负责从接口交互表中提取数据，C了解新系统的新业务逻辑，对接口交互表进行逻辑检查后，提取数据转换到新的系统。采用两阶段的迁移，由熟悉旧系统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！我在旁边插了话， 其实如果旧系统是其他公司承建的，可能同事们就能想到两阶段迁移的接口交互

31、表方式，可是我们两个系统由于是同一个部门承建，我们把部门边界和系统边界给混淆了，反而欲速而不达。在网页中用 JS 函数控制 Flash 动画播放一、介绍与 Flash 动画控制有关的javascript函数：函数名使用作用play() () 播放 Flash 动画stopplay() () 停止播放 Flash 动画rewind() () 停止播放 Flash 动画并返回第一帧totalframes() () 返回 Flash 动画总帧数gotoframe(int num) (int num) 转到指定帧二、程序代码： ？ function init()？ ？ 控制 Flash 动画 Flas

32、h动画帧数 : 输入第帧, 再点击 指定帧 。 ？ ？ ？ ？ ？ ID=wgzc WIDTH=500 HEIGHT=100 ？ ？ WIDTH=500 HEIGHT=100 TYPE=application/x-shockwave-flash？ 以 WBS 为主线的集成项目管理任何流程或业务在我们学习的过程中始终都有一个主线，比如说知识管理的基础或主线是知识库和知识地图，ERP的数据基础是ITEM和 BOM ，主线是需求订单-MRP- 生产计划和采购计划。 对于产品数据管理PDM 的主线是产品结构， 对于 CRM客户关系管理的主线是营销- 市场策划 -销售计划 -预测 - 项目- 合同。而对

33、于项目管理其基础是WBS 工作结构分解， 其主线是项目结构-项目 -WBS- 工作包 -活动 -任务。这条主线涉及到PMBOK 里面的范围管理和进度管理两方面的内容。对于范围管理最终的输出就是范围说明书和WBS ，而对于进度管理则输入是WBS ，需要进行活动定义分解和排序，最终得到的进度表。在项目的执行过程中我们是按照具体的活动任务在执行，在执行的过程中会产生使用资源，消耗成本，产生文档和各种输出，进行设计开发，集成，评审和质量控制。我们活动分解的单位是到了具体的任务，但是我们产品的最终集成，我们的成本核算和挣值管理是不能到活动任务的。因此WBS在整个项目管理中就起到了重要作用，其作用不仅仅在

34、前期确定项目范围和制定项目的进度计划，更多的是后期的挣值管理和更高层次的项目监控。如果没有完善的WBS分解，我们就很难做到这一步，我们的整个项目管理执行过程中的产出就是凌乱的，没有一个主线串起来。感兴趣的可以再去翻看下PMBOK 各个过程域中各个过程组的IPPO，可以发现很多过程的输入都有WBS ，足以见WBS在整个项目管理中的基础和核心作用。在这个图中还强调了下在CMMI三级中我们强调的生命周期模型定义过程裁剪，在组织级我们可以根据项目的不同特点将项目进行分类制定不同的项目生命周期模板，这样在有实际的项目来的时候，只需要根据项目的特点对模板内容进行自定义和裁剪，输入具体的需求项，即可以自动产

35、生相应的WBS 。(该点后续单独在发文阐述)，这样自动生成的WBS 不仅仅实现了后续的主线跟踪，还实现了我们在 CMMI二级中需要的需求追踪。一流软件领导的10 个特征特征一：敢于设想他们是在不确定性上发展起来的技术空想家。软件领导者们必须生活于剃刀边缘。1987年，在驱车沿法兰克福到沃尔多夫从一家IBM代理商那儿回家时， SAP的创立者普拉特纳、霍普和特奇拉决定为他们最畅销SAP R2 企业解决方案软件创造一个新版本。新的R/3 将利用一个可塑性强得多的设计。但是新产品应该运行于哪些系统之上呢当时，许多大学刚刚开始使用Unix ，这是一个新的操作系统，允许在不同厂家的计算机之间构建网络，从而

36、有可能创造一个新的系统结构: 客户 / 服务器模型。虽然有这些优点，它却相当不稳定，没有达到企业解决方案应用所需的表现水平。因此，尽管它提供了许多超过大型计算机的专业优势，许多从业者认为它永远不会取代那时的大型机。但普拉特纳不同意。 他鼓吹为新的R3 系统采用 Unix ，从而指出了一种当时看上去高度投机和冒险的方向。他立刻在自己公司内陷入阻力之中。但是他相信他的远见于是运用他作为一个大股东的影响力，得到了董事会的同意。4 年之后， 1991 年，SAP向全世界推出了 R3，安装在一个小的HP Unix 工作站。人们被震惊了。 “它几乎是可笑的， ”普拉特纳回忆道， “他们在说： 这个小机器，

37、带着一些存储器就是伟大的SAP ”但是，这个小机器为SAP在 ERP市场的主导地位奠定了基础。基于Unix 的R3 向大群的 Windows PC用户开放了 SAP ，用一个“漂亮的前端吹走了“绿色显示屏之争” ，正如理查森波士顿的高等制造业研究公司的一位顾问所描述的。此外，基于Unix 的 R 3 的表现要比基于大型机的R2 更好。R3 在全球 EPR市场成了一个王牌产品。从1992 年到 1998 年，单在美国，SAP的收入就从 4500万美元上升到20 亿美元。是普拉特纳深入技术内部的洞察和他对未来发展的预见，使这一设想成为可能，也说明了软件领导者必须生活于剃刀边缘。软件业已经产生了许多

38、其他的幻想家，他们在全球范围内改变了这个行业，从库比（他在很久以前就相信软件可以与硬件分开销售）和基恩（他于1965 年在一家汽车轮胎铺里创立了他的软件服务公司），一直到比尔 盖茨、埃里森和其他人。特征二：敢于冒险他们承受巨大的风险并希望有高额的回报。在梦想成真的路上， 软件领导者们必须能够面对无数次风险。麦肯锡的调查显示，成功软件产品公司的领导者做出重要战略决定所花的时间平均要少25，其原因并不主要是他们有更好的信息或市场研究，更多的来自他们的冒险精神。以莱曼特为例，他从学校退学，并在1989 年建立了以得克萨斯州奥斯汀为所在地的 Trilogy软件公司，一家专门从事前台办公室销售和营销软件

39、的公司。对莱曼特来说，决定冒险是很自然的。他告诉我们: “我想我不得不退学以抓住市场机遇。”没有一个风险资本家想资助他，所以莱曼特靠赊欠度日。不过创立 Trilogy两年后，莱曼特从他冒险的愿望中得到了回报。他终于做成了与惠普的一笔350 万美元的合同。其他有名的客户，像波音和朗讯也接踵而来。到1996 年，莱曼特进入了福布斯400 名富豪榜并成了其中最年轻的自力更生者，拥有估计5 亿美元的净资产。在 1998 年，他有 850 名员工，销售额超过1 亿美元。莱曼特及其公司并非孤立的个案。安德烈森在他合作创立网景并开发因特网浏览器软件时只有22 岁。比尔盖茨、巴尔默或SAP的普拉特纳同样都是冒

40、险家，而且他们全都通过冒险而成了亿万富翁。特征三：多样选择他们在多个选择上押注，来为所有不确定性做准备。微软并不单单押注于它的 Windows PC 操作系统的成功，而是与IBM一起共同开发一个与之竞争的操作系统OS 2。SAP是另一个例子。它没有去“塑造”这个行业，而是宁愿适应领先者的标准，同时在几个标准上花钱。作为SAP的总裁和CEO ，卡格曼评述说， SAP可以从第二排看到表演不断发展。专业软件公司的领导人同样通过选择权处理不确定性。西姆斯是剑桥技术伙伴公司的 CEO，该公司是波士顿一家6 亿美元的软件服务公司。他确保剑桥连续投资几个新兴公司，它们可能会开发出一个新的技术标准。“我们与新

41、技术一直保持接触， ”西姆斯说，“我们希望资助的这些公司之一有一天会成功。”但是，在通往成功的路上，软件领导者们必须接受不时的失败。事实上，失败并非是例外，而是惯例即使在成功的软件领导者之中。？特征四：敢于尝试他们宁愿“迅速失败”而不是避免错误。“宁可做6 个正确决定和4 个错的，而不要等得太久， ”SAP的霍普评述道。“Platinum 技术公司的 CTO波佩克同意这个说法。 “快速移动是很重要的， ”他说，“这常常会导致错误，但错误是可以改正的。”看看陈丕宏在他创立了BroadVision之后是如何反应的。 尽管这名企业家在电子商务解决方案上押对了赌注，他却在选择交互式电视（它看起来像是“

42、未来的潮流” ）作为其产品的平台上犯了错误。事实上，当陈丕宏第一次看见因特网的时候，他的电视产品几乎已经完成了。特征五：强调速度陈丕宏几乎一夜之间就将BroadVision转变成了一家因特网公司。“对我来说非常清楚，我们错了，而且如果我们不迅速改弦易辙的话，我们就会失去一切。”陈丕宏回忆道。陈丕宏没有做长时间的讨论，而是几乎一夜之间就将公司转变成了一家因特网公司不顾他的经理们的反对。“我几乎不得不解雇整个高层管理队伍， 因为他们对变革没有信心。 ”他说。他的敏捷行动获得了结果，到 1998 年底， BroadVision的市值超过了7 亿美元。特征六：目标远大软件领导者们同样设定了非常高的期望

43、。当菲利波夫斯基于1987年创立 Platinum时，他决定在10 年之内将其建成一个 10 亿美元收入的公司。菲利波夫斯基觉得他不得不动作迅速，因为他看到软件业正在迅速转向成熟。他同样明白在软件产品行业，只有领先者才能真正成功。 “对我来说，迅速壮大是件生死攸关的事。”他解释道。菲利波夫斯基并没有完全实现他的想法， “这花了我们11 年，而不是 10 年。 ”他有些不好意思的承认。但是他的窘迫是可以忍受的，比尔盖茨花了15 年才使微软达到 10 亿美元，英特尔、 Oracle 和 SAP达到这个目标全都花了10 年以上。只有思科的莫格里奇和钱伯斯击败了菲利波夫斯基，他们在 10 年里做到了这

44、点。在麦肯锡的全球性调查中，发现高期望水平与公司的成功之间有非常强的相关性。在成功企业之中，93都有一个清晰、明确的远见，而在不成功企业中只有25% 有这样的雄心壮志。特征七：敢于变革他们是高度动态的组织的建立者。1995 年 12 月 7 日，比尔盖茨在微软的会议上宣布了一个突然的变革。他回顾历史，引用了日本海军上将山本五十六在日本进攻美国时所做的评论：“我担心我们惊醒了一个沉睡的巨人。 ”在这儿，这个巨人就是盖茨的公司，而进攻者是网景和因特网时代。盖茨清楚地看到进攻者们正在来临。在其存在的20 个月里，网景已经将其Navigator万维网浏览器推到了全世界的领先位置。该公司也进行了一次最为

45、成功的公开上市。同一时间在微软，“我们确实有些错过了因特网航船，”微软德国公司总经理罗伊这样承认。特征八：反应迅速他们都是看准趋势迅速行动的人。“这就是要改变的。 ”站在几百名程序分析员和记者面前，盖茨宣布他将重新调整每个项目和每个产品以迎接因特网的挑战。确实，整个微软的管理人员仓促地停止了几个数百万美元的项目并在数小时内启动了因特网项目。这些经理之一的路德维希走进一间满是程序员的屋子，命令道： “清除你们机器里的源代码，今天起就开始用 Java 工作。 ”为因特网浏览器工作的程序员的数目迅速从8 人增长到 800 人。9 个月后，在 1996 年 8 月 13 日，微软的 IE30，新的具有

46、竞争力的浏览器发布了。它在每个方面都赶上网景的Navigator 。在第一个星期， 超过 100 万用户下载了这个免费软件。尽管两个公司之间的战斗1998 年仍在进行，有一点已经十分清楚：微软已经在6 个月略多一点的时间内成功地改变了一个庞大的有2 万名员工的组织。要做到这点，需要从高层领导者那儿来的对巨大变革的极强的信心以及清晰、可交流的信息。让整个组织对这种剧烈变动做好准备是一项长期的任务。英特尔的格罗夫在谈到高技术公司中的管理时说：“你需要像一个救火部门那样做计划：它不能预计下一场火出现在哪儿，所以它不得不塑造一支富有活力和有效率的队伍，能像处理普通事务一样对突发事件做出反应。”特征九：

47、善于管理他们建立十分平坦的、以团队为基础的组织。SAP在 1996 年拥有 2 万名员工和 50 亿美元收入，它有一个3 个层次的平坦的组织形态。在公司位于德国沃尔多夫的总部，咖啡机旁的墙上挂着总裁霍普讲演中的一段话。他说： “对所有公司的新员工来说，在SAP这儿，我们是没有官僚主义并鼓励主动性的。 ”他还说：“这要求每个人有时得为往往不在正常工作任务之中的事情负责。 ”在专业软件服务中，构建以团队为基础的组织也是一个关键的领导任务。“在专业服务中，获胜的是团队，”基恩解释说， “但正因为如此，领导者也就成了专业服务里的关键。在产品行业，产品在整个公司范围内被聚合起来，而领导者们创造并代表它。

48、在服务业，领导者得和谐安排和构建一支经过授权的队伍。”微软的首席营运官赫伯德，过去曾是消费品行业巨人宝洁的营销主管，在财经时代的一次采访中说，软件业的团队结构和平坦的等级制度是他对这个行业印象最深的。“在宝洁，大多数的交流是手写的。它只能上下一个层次，与这个行业相比，它是相对迟缓的。所以你可能要花4 个轮次的交流才能明白自己实际上弄乱了什么事情。在微软，我们以直接接触主题而自豪。”其他行业的管理者们也同意这一说法。 “像 Oracle 和 Sun 这样的软件公司都非常重视以团队为基础，我们喜欢仿效它们， ”Texaco 的石油勘探显示中心经理蔡特林说，“中层管理人员有权做决定。他们可以自行其是

49、。这种文化感染了我。”特征十：创造文化他们创造了一种文化，它吸引和留住人才。当我们在芝加哥郊区访问Platinum公司时，我们问各个管理人员他们的公司给他们印象最深的是什么。从公司数据中心经理韦伯、营销执行副总裁马修斯和开发人员德莫特那儿，我们得到了同一个答案：菲利。他们说，CEO 菲利波夫斯基那与众不同的风格产生了巨大的影响。甚至菲利波夫斯基的办公室也与众不同，有数百个印度玩偶排列在墙上，一架大电视从天花板上吊下来，不停地播出因特网新闻服务。在另一个角落，供应的软饮料有6 英尺高。 “初次来访的人总是感到惊讶。菲利确实是个十分特别的人， ”一名经理助理说。在她向我们展示菲利波夫斯基的办公室时

50、，她的脸上闪过一丝微笑。她并非惟一一个：几乎每一个我们与之交谈的人在解释他们为什么进入这家公司和为什么喜欢在这儿工作时，都提到 Platinum 的这位领导者和他创造的文化。创造一种吸引人才的文化对软件领导者们是必不可少的，而且实际上， 是他们最重要的挑战之一。需求管理的必要性及控制需求渐变的方法本文介绍了需求管理的必要性，并介绍了控制需求渐变的一些方法。软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在