1、树立年度目标、制定政策、激励员工和配置资源，以便使制定的战略得以贯彻执行。 战略评价：重新审视外部与内部因素；度量业绩；采取纠偏措施。 对于典型的项目型企业，一般在企业的战略实施过程中，将企业的战略转化为一系列的项目来实施企业的战略，按多项目或项目群来管理各个项目，达到企业的战略目标。 一个优秀的项目经理应该了解企业的商业战略目标，与企业高层管理者紧密合作。 信息系统项目的特点 特点： 目标不明确 需求变化频繁 智力密集型 设计队伍庞大 设计人员高度专业化 涉及的承包商多 各级承包商分布在各地，相互联系复杂 系统集成项目中需研制开发大量的软硬件系统 项目生命周期通常较短 通常要采用大量的新技术
2、 使用与维护的要求非常复杂、 项目管理定义 项目管理就是把各种知识、技能、手段和技术应用于项目活动之中，已达到项目的要求。 项目管理是通过应用和综合路启动、计划、实施、监控和收尾等项目管理过程来进行的。 项目知识体系构成 软技能 软技能包括人际关系管理。软技能包含以下内容。 有效的沟通：信息交流。 影响一个组织：“让事情办成”的能力。 领导能力：形成一个前景和战略并组织人员达到它。 激励：激励人员达到高水平的生产率并克服变革的阻力。 谈判和冲突管理：与其他人谈判或达成协议。 问题解决：问题定义和做出决策的结合。 IPMP/PMP PMNCE2 PRINCE2 定义与结构 PRINCE2 提供最
3、佳的项目管理方法论，更加接近项目的实施，更加重视项目的实际收益和回报。是一种基于流程的结构化项目管理方法。 PRINCE2旨在以一种适于广泛项目环境的方式组织安排和着重介绍项目管理知识。假设了解和采用该方法的用户具有一定的经验，能够自行填补其省略的细节。 PRINCE2包括 4 个被称为要素的主要部分。这4 个要素包括原则、流程、主题以及项目环境。 PRINCE2原则 PRINCE2方法具有七个原则 持续业务验证一一以“商业论证主题”为例证，确保项目始终符合业务目标、实现战略与收益。 吸取经验教训在整个项目生命周期中总结、记录经验教训，并以此为鉴。 明确定义的角色和职责确保合理用人，令所有人明
4、确自己的任务要求。 按阶段管理由于计划必须具有可管理性和预见性，因此需要分阶段计划、监督和控制项目，并在整个项目的重要间隔设置控制点。 例外管理PRINCE2 项目对时间、成本和范围这三个绩效目标（典型的“三元约束”）为各个层级的项目管理团队设置了明确的权力限制与质量、风险和收益一起，提供了更加真实、全面的项目成功因素。 关注产品由于成功的项目是以产出（而非活动）为导向，因此 PMNCE2 项目特别强调交付物（PMNCE2 称之为产品）的定义、生产和审批，从而实现同意的预期目标。 根据项目环境剪裁一-认识到项目管理没有严格（精确）的公式，流程和主题必须进行调整使之能够反映每个项目的独特状况（避
5、免“机械式”项目管理） PRINCE2的4个要素 组织结构对项目的影响 组织结构 职能型组织 优点 强大的技术支持，便于知识、技能和经验的交流。 清晰的职业生涯晋升路线。 直线沟通、交流简单、责任和权限很清晰。 有利于重复性工作为主的过程管理。 缺点： 职能利益优先于项目，具有狭隘性 组织横向之间的联系薄弱、部门间沟通、协调难度大 项目经理极少或缺少权利、权威 项目管理发展方向不明，缺少项目基准等 项目型组织 优点。 结构单一，责权分明，利于统一指挥。 目标明确单一。 沟通简洁、方便。 决策快。 缺点 管理成本过高，如项目的工作量不足则资源配置效率低 项目环境比较封闭，不利于沟通、技术知识等共
6、享 员工缺乏事业上的连续型和保障等 矩阵型组织 项目经理负责制、有明确的项目目标。 改善了项目经理对整体资源的控制。 及时响应。 获得职能组织更多的支持。 最大限度地利用公司的稀缺资源。 降低了跨职能部门间的协调合作难度。 使质量、成本、时间等制约因素得到更好的平衡。 团队成员有归属感，士气高，问题少。 出现的冲突较少，且易处理解决。 管理成本增加。 多头领导；难以监测和控制。 资源分配与项目优先的问题产生冲突。 权利难以保持平衡等。 PMO在组织结构中的作用 根据需要，可以为一个项目设立一个 PMO,可以为一个部门设立-个 PMO，也可以为一个企业设立一个PMO。这三级 PMO 可以在一个组
7、织内可以同时存在。 以下列出 PMO 的一些关键特征，但不限于此。 在所有 PMO 管理的项目之间共享和协调资源。 明确和制定项目管理方法、最佳实践和标准。 负责制订项目方针、流程、模板和其他共享资料。 为所有项目进行集中的配置管理。 对所有项目的集中的共同风险和独特风险存储库加以管理。 项目工具（如企业级项目管理软件）的实施和管理中心。 项目之间的沟通管理协调中心。 对项目经理进行指导的平台。 通常对所有 PMO 管理的项目的时间基线和预算进行集中监控。 在项目经理和任何内部或外部的质量人员或标准化组织之间协调整体项目的质量标准。 信息系统项目的生命周期 项目生命周期的特征 通用项目生命周期
8、结构中典型的成本与人力投入水平 通用的生命周期结构具有以下特征： 成本与人力投入在开始时较低，在工作执行期间达到最高，并在项目快要结束时迅速回落。 风险与不确定性在项目开始时最大，并在项目的整个生命周期中随着决策的制定与可交付成果的验收而逐步降低17、 随项目时间变化的变量影响 项目干系人影响也随着风险降低而减小 项目阶段 阶段与阶段的关系有两种基本类型： 顺序关系。 在顺序关系中，一个阶段只能在前一阶段完成后开始。 项目的多个阶段完全按顺序排列。 其按部就班的特点减少了项目的不确定性，但也排除了缩短项目总工期的可能性。 交叠关系。 在交叠关系中，一个阶段在前一阶段完成前就开始。 这有时可作为
9、进度压缩的一种技术，被称为“快速跟进”。 阶段交叠可能需要增加额外的资源来并行开展工作，可能增加风险，也可能因尚未获得前一阶段的准确信息就开始后续工作而造成返工。 信息系统项目典型生命周期模型 瀑布模型 瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段 瀑布模型特点 从上一项开发活动接受该项活动的工作对象作为输入。 利用这一输入，实施该项活动应完成的工作内容。 给出该项活动的工作成果，作为输出传给下一项开发活动。 对该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行
10、下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件 总结也称生命周期法，是结构化方法中最常用的开发模型，本质是“一次通过”，最后得到软件产品。 流程：该模型给出了固定的顺序，开发模型是线性的，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 适用：需求明确或很少变更的项目，如二次开发或升级型的项目，有利于大型软件开发人员的组织与管理；开发团队比较弱或缺乏经验。各个阶段的划分完全固定，
11、阶段之间产生大量的文档，极大地增加了工作量；由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 螺旋模型 螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。 开发过程具有周期性重复的螺旋线状。 四个象限分别标志每个周期所划分的四阶段：制订计划、风险分析、实施工程和客户评估。 螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析沿着螺线进行若干次迭代，每旋转一圈都
12、要经过制定计划、风险分析、实施工程及客户评价等活动。第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。特别适合于大型复杂的系统，风险大的项目。螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的， 这种模型往往适应于内部的大规模软件开发。 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。 迭代式开发模型 迭代式开发模型，水平方向为时间维，从组织管理
13、的角度描述整个软件开发生命周期，分四个阶段：初始、细化、构造、移交，可进一步描述为周期（Cycle）、阶段（Phase）、迭代（Iteration）;核心工作流从技术角度描述迭代模型的静态组成部分，包括：业务建模、需求获取、分析与设计、实现、测试、部署。图中的阴影部分描述了不同的工作流，在不同的时间段内工作量的不同，几乎所有的工作流在所有的时间段内均有工作量，只是大小不同而已。各阶段的主要任务如下。 初始阶段：系统地阐述项目的范围，选择可行的系统构架，计划和准备业务案例。 细化阶段：细化构想，细化过程和基础设施，细化构架并选择构件。 构造阶段：资源管理、控制和过程最优化，完成构件的开发并依评价
14、标准进行测试，依构想的验收标准评估产品的发布。 移交阶段：同步并使并发的构造增量集成到一致的实施基线中，与实施有关的工程活动（商业包装和生产、人员培训等），根据完整的构想和需求集的验收标准评估实施基线。是 RUP 推荐的周期模型。包括产生产品发布的全部开发活动和要使用该发布必须的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。RUP 认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。 项目实现不能完整定义产品的所有需求、计划多期开发的软件开发； 在项目开发早期需求可能有所
15、变化； 分析设计人员对应用领域很熟悉； 高风险项目； 用户可不同程度地参与整个项目的开发过程； 使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）； 使用 CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如 Rose； 具有高素质的项目管理者和软件研发团队。 V 模型 V 模型从整体上看起来，就是一个 V 字型的结构，由左右两边组成。 左边的下画线分别代表了需求分析、概要设计、详细设计、编码。 右边的上画线代表了单元测试、集成测试、系统测试与验收测试。 V 模型的特点如下：注意区分 单元测试
16、的主要目的是针对编码过程中可能存在的各种错误； 集成测试的主要目的是针对详细设计中可能存在的问题； 系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行； 验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。 V 模型用于需求明确和需求变更不频繁的情形。 V模型的总结 以测试为中心的开发模型，宣称测试并不是一个事后弥补行为，二是一个同开发过程同样重要的过程。 左边下降的是开发过程的各个阶段，与此相对应的是右边上升的部分，即测试过程的各个阶段。非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。仅仅把测试过程作为
17、在需求分析、系统设计及编码之后的一个阶段；忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。 原型化模型 原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。 原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下。 实际可行 具有最终系统的基本特征 构造方便、快速，造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。 可以将原型分类如下。 抛弃型原型,此类原型在系统真正实现以后就放
18、弃不用了。 进化型原型,此类原型的构造从目标系统的一个或几个基本需求出发，通过修改和追加功能的过程逐渐丰富，演化成最终系统。 原型化模型总结快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。 第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么； 第二步则在第一步的基础上开发客户满意的软件产品。 优缺点： 优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。所选用的
19、开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。 与瀑布模型对比： 传统的瀑布模型很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程，缺乏灵活性，不适合实际的开发过程。 而快速原型模型的提出，可以较好的解决瀑布模型的局限性，通过建立原型，可以更好的和客户进行沟通，解决对一些模糊需求的澄清，并且对需求的变化有较强的适应能力。 原型模型可以减少技术、应用的风险，缩短开发时间
20、，减少费用，提高生产率，通过实际运行原型，提供了用户直接评价系统的方法，促使用户主动参与开发活动，加强了信息的反馈，促进了各类人员的协调交流，减少误解，能够适应需求的变化，最终有效提高软件系统的质量 敏捷开发 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。 Scram 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。 敏捷开发总结轻量、高效、低风险
21、、柔性、可预测、科学且充满乐趣的软件开发方式。在一个敏捷项目中，需要假定我们并不能事先确定系统的需求。因此在项目的初期有一个详细设计阶段的想法是不现实的。系统的设计必须随着软件的变化而进化。小型或中型软件开发团队，并且客户的需求模糊或者多变。 统一过程（RUP）基于构件，由 UML 方法和工具支持。3 个显著特点，即用例驱动、以基本架构为中心、迭代和增量。提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经达到。（3）适用：一
22、个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同性能水平和不同的项目规模。 喷泉模型为软件复用和生存周期中多项开发活动的集成提供了支持，“喷泉”体现了迭代和无间隙特性。与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人
23、员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。 增量模型又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。融合了瀑布模型的基本成分（复用的应用）和原型实现的迭代特征。在增量模型中，每一个线性序列产生软件的一个可发布的增量。第一个增量往往是核心的产品，也就是说，第一个增量实现了基本的需求，但很多的补充特征还没有发布。增量模型在各个阶段交付满足客户需求的一个子集的可运行产品。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可
24、以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 在开发过程中，需求的变化是不可避免的。 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 案例：使用增量模型开发字处理软件。可以考虑， 第一个增量发布基本的文件管理、编辑和文档生成功能。 第二个增量发布更加完善的编辑和文档生成功能。 第三个增量实现拼写和文法检查功能。 第四个增量完成高级的页面布局功能。 单个项目的管理过程 项目管理过程组 按项目管理过程在项目管理中的职能可以将组成项目的各个过程归纳为 5 组，叫作项目管理过程组：启动过程组；计划过程组；执行过程组；监督与控制过程组；收尾过程组。（掌握） 过程组极少是孤立或只执行一次的事件，它们是在整个项目生命期内自始至终都以不同的程度互相重叠的活动。若将项目划分为阶段，则过程组不但在阶段内，而且也可能跨越阶段相互影响和相互作用。 项目管理过程与项目管理知识领域间的映射
