1.项目生命周期的阶段之间可能相互交叉，而产品生命周期的阶段通常不相互交叉；
 
项目生命周期：项目初始->项目计划->项目执行控制->项目结束；
 
产品生命周期：投入期->成长期->饱和期->衰退期；
 
2.项目生命周期的终点与产品生命周期的终点不同；
 
项目结束的最后一个过程是项目总结；
 
产品结束的最后是产品死亡；
 
3.项目生命周期可以包括在多个产品生命周期中；
 
一个产品生命周期中可包括多个项目生命周期，产品生命周期长于项目生命周期。
  

 
项目生命周期、开发生命周期与产品生命周期的区别
 
项目生命周期
开发生命周期
产品生命周期

 
项目生命周期
 
项目生命周期是指项目从启动到完成开始到结束所经历的一系列阶段。
 项目生命周期的类别：预测型和适应型。
 
开发生命周期
 
开发生命周期是指在项目生命周期内与服务或产品的开发有关的一个或多个阶段。
 开发生命周期的类别：预测型、迭代型、增量型、适应型、混合型。
 1、预测型生命周期，也称为瀑布型生命周期，在生命周期的早期阶段确定项目范围、时间和成本。
 2、迭代型生命周期，项目范围通常在项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。
 3、增量型生命周期，通过在预定的时间区内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能视为完整。
 4、适应型生命周期，也被称为敏捷或变更驱动型生命周期，属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。
 5、混合型生命周期是预测型生命周期和适应型生命周期的组合。
 
产品生命周期
 
产品生命周期是指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

  接受项目管理培训至今已经有三年时间了，一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头，从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验，希望可以帮助到从事项目管理的人！
 
  在前面的博文项目管理 之一 软件开发生命周期（软件开发过程、瀑布模型、敏捷开发等） 中我们说过 软件开发生命周期 ≠ 项目的开发周期。接下来就再进一步，站在整个项目的角度来了解一下软件项目管理。
 
注意：
 
这部分仅仅是自己学习记录的一些总结，所以内容大多数都是来自互联网或者各种书籍。如果您发现对您构成了侵权，请随时联系我进行处理。
这部分内容都是一些理论，实际项目中往往与理论有所不同。例如，阶段划分更加详细，项目活动可裁剪等
 
项目管理
 
  项目这个概念非常的广泛，项目管理同样是个范围很大的概念。项目管理是管理学的一个分支学科 ，对项目管理的定义是：指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。所谓管理包含领导、组织、用人、计划及控制等五项主要工作。
 
 
 
项目（Project）是为完成某一独特的产品、服务或成果所做的临时性工作。临时性是指计划有确定的开始日期和结束日期。独特意味着项目的最终结果不重复。
 
 
  作为一门学科，项目管理从土木施工、工程、重型国防等多个应用领域发展而来。20 世纪 50 年代项目管理被公认为具有工程模式的管理学科所产生的一门独特的学科。1969 年，项目管理研究所（PMI）在美国成立。PMI 于 1996 年出版了第一版《项目知识管理机构指南》（PMBOK 指南）。这本书是必看的！本文的有些内容就是来自这本指南。
 
 
 
PMBOK 每 4 年会更新一次，目前中国使用的官方教材为第六版
全球项目管理业界定义的最重要的价值观是责任、尊重、公正和诚实
PMBOK 指南为项目经理提供了指导方针和最佳实践，定义了从项目生命周期到项目管理策略和概念的一切内容。项目管理知识体系指南详细描述了在整个项目生命周期中相互作用和重叠的各种项目管理过程。
 
 
  项目管理方法可应用于任何类型的项目。它通常根据项目规模、性质、行业或部门为特定类型的项目量身定做。例如，以建筑、道路和桥梁等工程的交付为重点的建筑行业已经发展了自己的专业项目管理形式，称为建筑项目管理；我们软件行业则有我们的软件项目管理。
 
接下来，我们来区分一下三个比较容易混淆的概念：项目生命周期、项目管理生命周期、产品生命周期
 
 
项目生命周期
 
  项目的生命周期是描述项目从开始到结束所经历的各个阶段。通常由 启动阶段、组织与准备阶段（规划阶段）、实施阶段、结束阶段 这四阶段个组成。每个阶段确定了开始和结束点，每个阶段都有质量保证 QA / 质量测试 QC 人员对阶段的里程碑点进行检查并进行相应的阶段评审。
 
   项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。 阶段通常有先后的顺序（如瀑布型），也可以有阶段的交叠。不同行业，不同规模的项目，项目生命周期可以不同。
 
 
 
项目活动 是确认和描述项目的特定活动，它把项目的组成要素加以细分为可管理的更小部分，以便更好地管理和控制。
 
 
  项目规划阶段的目的是为了管控的需要，每一个阶段都可以当成是一个子项目，每一个阶段中都可以执行项目管理生命周期定义的五大过程组。阶段结束时要进行阶段评审。由于项目有特定的目标，在产品生命周期中，一般产品完成后通过验收则项目生命周期即结束。
 
  项目阶段并没有严格的划分标准。这里所说的 4 个阶段仅仅是指的一般情况。一个具体的项目可以根据项目所属专业领域的特殊性和项目的工作内容等因素划分成不同的项目阶段。
 
启动阶段
 
  启动阶段是整个项目生命周期的第一阶段。这一阶段的目标是确定项目，并获得批准。在此期间，通常有以下项目活动需要项目经理来处理：
 
需求调研
进行可行性研究
创建项目章程
确定关键利益相关者
选择合适的项目管理方法
选择项目管理工具
 
通常，从项目启动会议开始，项目经理向所有相关利益相关者概述项目目标。在会议召开之前，项目经理必须执行以下工作：
 
建立目标和可交付成果
识别团队成员并分配任务
制定项目计划草案
定义用于衡量项目成功的指标
识别和准备潜在的路障
建立团队沟通的物流和时间表
选择首选的项目管理方法
确保您的团队能够访问相关工具并了解相关工具
安排会议
设置议程并准备幻灯片
 
启动会议议程可能如下所示：
 
简介：谁是谁？
项目背景：您为什么要进行这个项目？ 目标是什么？
项目范围：涉及哪种工作？
项目计划：路线图是什么样的？
角色：谁负责项目的哪些元素？
交流：将使用哪种交流渠道？ 您的团队应该期望什么样的会议或状态报告？
工具：将使用哪些工具来完成项目，以及如何使用它们？
后续步骤：需要完成哪些立即行动项目？
问答（Q&A）：现场答疑
 
到此阶段结束时，项目经理应对项目的目的、目标、要求和风险有更深入的了解。
 
规划阶段
 
  规划阶段对于创建整个团队可以遵循的项目路线图至关重要。为了满足组织提出的要求，所有的细节和目标都在这里列出。在此阶段，通常有以下项目活动需要项目经理来处理：
 
创建项目计划
制定资源计划
评估项目预算
定义目标和绩效衡量指标
向团队成员传达角色和责任
构建工作流
预测风险并制定应急计划
制定沟通交流计划（可能是会议、交流工具）
 
执行阶段
 
  这个阶段是项目投入时间最多的阶段。可交付品的构建是为了确保项目符合要求。这也是大多数时间、金钱和人被投入的阶段。
 
  在执行阶段必须时刻对项目进行控制和监测（严格来说，项目的每个阶段都可以控制和监测）。随着项目的推进，项目经理必须确保所有活动的部分都朝着正确的方向无缝地进行。如果由于不可预见的情况或方向的改变而需要对项目计划进行调整，则可能会在这里进行调整。在控制和监测中，项目经理（有可能是公司中专门的 QA 人员）可能需要做以下工作：
 
管理资源
监控项目性能
风险管理
质量管理
成本管理
变更管理（更新项目计划、修改项目计划）
执行状态会议和报告
协作、沟通
 
项目关闭
 
  结束阶段是项目生命周期的关键一步。它标志着项目的正式结束，并为反思、总结和组织材料提供了一段时间。通常有以下项目活动需要项目经理来处理：
 
盘点所有可交付成果
处理好任何零碎的事情
将项目移交给客户或负责项目日常运营的团队
进行事后分析，讨论并记录从项目中学到的任何东西
集中组织所有项目文件
与利益相关者和主管沟通项目的成功
庆祝项目完成并感谢团队成员
 
阶段关口
 
阶段关口在项目阶段结束时进行，将项目的绩效和进度与项目和业务文件比较，这些文件包括 （但不限于）：
 
项目商业论证
项目章程
项目管理计划
效益管理计划
 
根据比较结果做出决定（例如继续/终止的决定），以便：
 
进入下个阶段；
整改后进入下个阶段；
结束项目；
停留在当前阶段；
重复阶段或某个要素。
 
在不同的组织、行业或工作类型中，阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。
 
项目管理生命周期
 
  项目管理生命周期是对项目目标的实现进行管理的过程。项目生命周期每个阶段都是通过一系列项目管理活动进行的。这些管理活动被称为项目管理过程。 每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。
 
 
 
项目生命周期的每个阶段都要执行项目管理生命周期
 项目管理的输出一般都是些项目标准文档
 
 
  项目管理过程组指对项目管理过程进行逻辑分组，以达成项目的特定目标。过程组不同于项目阶段。项目管理过程可分为以下五个项目管理过程组：
 
启动过程组： 定义一个新项目或现有项目的一个新阶段，授权开始该项目或阶段的一组过程。
规划过程组： 明确项目范围，优化目标，为实现目标制定行动方案的一组过程。
执行过程组： 完成项目管理计划中确定的工作，以满足项目要求的一组过程。
监控过程组： 跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更的一 组过程。
收尾过程组： 正式完成或结束项目、阶段或合同所执行的过程。
 
  但是，需要注意 阶段 ≠ 过程组。不同行业，不同规模项目的项目管理生命周期大致相同。项目管理生命周期的过程是 PMP（Project Management Professional​） 考试的主要考试范围。
 
除了过程组，过程还可以按知识领域进行分类，分为 10 个知识领域（其中始终关注的是范围、进度、成本和质量）：
 
项目整合管理： 包括为识别、定义、组合、统一和协调各项目管理过程组的各个过程和活动而开展的过程与活动。
项目范围管理： 包括确保项目做且只做所需的全部工作以成功完成项目的各个过程。
项目进度管理： 包括为管理项目按时完成所需的各个过程。
项目成本管理： 包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程
项目质量管理： 包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求，以满足相关方的期望的各个过程。
项目资源管理： 包括识别、获取和管理所需资源以成功完成项目的各个过程。
项目沟通管理： 包括为确保项目信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程。
项目风险管理： 包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。
项目采购管理： 包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。
项目相关方管理： 包括用于开展下列工作的各个过程：识别影响或受项目影响的人员、团队或组织，分析相关方对项目的期望和影响，制定合适的管理策略来有效调动相关方参与项目决策和执行。
 
下图显示了管理过程朱与知识领域的对应关系以及在过程中需要的工作：
 
 
裁剪
 
  由于每个项目都是独特的，所以有必要对项目管理过程进行裁剪；并非每个项目都需要《PMBOK® 指南》所确定的每个过程、工具、技术、输入或输出。裁剪应处理关于范围、进度、成本、资源、质量和风险的相互竞争的制约因素。各个制约因素对不同项目的重要性不一样，项目经理应根据项目环境、组织文化、相关方需求和其他变量裁剪管理这些制约因素的方法。
 
产品生命周期
 
  产品生命周期管理的是产品，包括一系列产品阶段：市场调研、产品研发、试产、量产、运营、维护和退市。产品生命周期通常包含顺序排列且不互相交叉的一系列产品阶段。
 
 
 
产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。
 
 
  产品生命周期由一个或多个项目生命周期组成，也可能分为多个迭代周期来实现。 而项目生命周期也可开发一个或多个产品。一个项目生命周期通常只包含在一个产品生命周期中。在项目生命周期结束即项目完成后，而产品生命周期还需进行产品的运营、维护和退市等阶段。
 
  与产品生命周期相对应的成本概念是全生命周期成本，包括一次性的项目软硬件投入（一次性成本），以及 3 - 5 年运营或运维成本（持续成本）。
 
三重关系
 
  三重约束，又称项目管理三角，是指适用于每个项目的时间、质量和成本界限。负责控制这些限制的项目管理流程包括进度管理、成本管理和质量管理。下图显示了软件项目的三个限制的关系。
 
 
我在学习中发现，有部分文章中，质量 被替换为 范围，即：时间、范围和成本。
 
软件项目管理
 
  到目前为止，仍然有很多人有疑问：软件开发项目到底能不能称为项目？这与对于软件工程能不能算是工程的疑问类似。在某些人的认识中，项目或者说工程更多的是指工业建筑中的专有名词。
 
  自 20 世纪 60 年代以来，软件制造商自行开发了几种专有的软件项目管理方法。今天，软件项目管理方法仍在不断发展，但是当前的趋势已从瀑布模型转移到了模仿软件开发过程的更具周期性的项目交付模型。
 
  软件项目管理（Software Project Management）就是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。通常，可以将软件开发项目可以分为两大类：
 
软件项目： 运行于已有通用硬件上的软件系统。例如，PC 上运行的软件，服务器上运行的网站。
系统项目： 运行于特定硬件上的软件系统，除了要开发软件，还要开发对应的硬件。例如各种嵌入式设备。
 
如果没有特殊说明，后文我们所说的软件项目管理均指这两种类型的统称。
 
  软件工程项目管理不同于传统的项目管理，因为软件项目具有独特的生命周期过程，需要多轮测试、更新和客户反馈。目前，大多数 IT 相关项目都以敏捷的风格进行管理，以跟上业务增长的步伐，并根据客户和利益相关者的反馈进行重复。
 
过程方法
 
2017 年的一项研究显示，任何项目的成功取决于四个关键方面，这些方面被称为 4P ：
 
计划（Plan）：指所有涉及规划和预测的活动。在这个阶段，项目或项目的要素尚未实现；
过程（Processes）：项目管理知识体（PMBOK, Project Management Body of Knowledge）指南中记述，项目主要由一系列预定和结构良好的过程所组成；
人员（People）：人员是项目动态的重要组成部分，一些研究表明，人员是某些项目特有问题的核心。所谓“可怕的结合”，特别是指规划不善和不适当人员的构成；
权责（Power）：描述当局所有的权力与责任、决策者、组织图，执行政策和喜好。
 
  组织与完成项目活动有许多方法，包括：分阶段、精益、迭代和增量等；也有一些对项目规划的几个扩展，例如，针对结果（基于产品）或活动（基于流程）。不论采行何种方法论，必须精心缜密地考虑项目总体的目标，时程和成本，以及所有参与者和利害关系人的作用和责任。
 
  对于软件开发项目，在博文 项目管理 之一 软件开发生命周期（软件开发过程、瀑布模型、敏捷开发等） 中介绍的各种过程模型，基本就是指导我们软件开发的方法。但是，由于项目具有独特性，因此标准的生命周期模型往往难以满足项目的特殊需要。通常项目在定义生命周期时，可首先选择一种标准的生命周期模型作为基础，然后指定出适合自己的方法。
 
传统的顺序方法
 
瀑布式管理方法
 
  规划项目的最常见方法是对导致最终交付的任务进行排序，并按顺序进行工作。这个过程也被称为瀑布方法——管理项目的传统方法，也是最容易理解的方法。
 
  这种方法的强大之处在于，每一步都是预先计划好的，并按照适当的顺序安排好。虽然这可能是最简单的最初实现方法，但涉众需求或优先级的任何更改都会破坏一系列任务，使其很难管理。这种方法在可预见性方面很出色，但缺乏灵活性。
 
关键路径方法（CPM）
 
  关键路径方法（Critical Path Method）是在 20 世纪 50 年代开发的，其基础是，有些任务在完成上一个任务之前无法启动。当您从头到尾将这些依赖任务串在一起时，您会绘制出关键路径。
 
  确定并关注这一关键路径后，项目经理就可以确定优先级并分配资源，以完成最重要的工作，并重新安排可能会阻塞团队的所有低优先级任务。 这样，如果您需要更改项目进度表，则可以在不延迟结果的情况下优化团队的工作流程。
 
关键链项目管理（CCPM）
 
  关键链项目管理（Critical Chain Project Management）将关键路径方法更进一步。CCPM 是一种方法，它侧重于通过在关键路径中增加资源可用性来完成项目任务所需的资源。它还在项目计划中围绕这些任务建立时间缓冲，确保项目满足其最后期限。
 
敏捷家族
 
  由于竞争激烈的商业环境和不断创新，敏捷的项目管理方法越来越受欢迎。一般来说，敏捷方法优先考虑更短的迭期周期和灵活性。
 
Scrum
 
  Scrum 是最受欢迎的敏捷发展框架，因为它的实现相对简单。它还解决了软件开发人员过去遇到的许多问题，例如复杂的开发周期、不灵活的项目计划以及更改生产计划。
 
详细介绍见 项目管理 之二 敏捷开发方法 Scrum 最全指导 .
 
看板
 
  看板是基于团队能力实施敏捷的另一个框架。它起源于 20 世纪 40 年代的丰田工厂。各部门使用可视化的卡片系统（“看板”）来表示他们的团队已经为更多的原材料做好准备，并拥有更多的生产能力。
 
极限编程 （XP）
 
  极限编程 （Extreme Programming） 是敏捷的另一个分支。XP 是一种旨在提高软件质量（和简单性）和开发团队适应客户需求的能力的方法。与原始的敏捷开发非常类似，XP 具有工作冲刺短、迭代频繁以及与利益相关者不断协作的特点。变化可能发生在冲刺阶段。如果特定功能的工作尚未开始，则可以将其更换为类似任务。
 
自适应项目框架（APF）
 
  自适应项目框架（Adaptive Project Framework）源于由于不确定和不断变化的需求而难以使用传统项目管理方法来管理大多数 IT 项目的情况。
 
  APF从需求分解结构（RBS）开始，以根据产品需求，功能，子功能和功能定义战略项目目标。 该项目分阶段进行，在每个步骤的最后，团队都会评估以前的结果以改善性能和实践。
 
变更管理方法
 
有些方法论用于管理项目，但更侧重于变更管理，尤其是风险规划和在变更发生时进行控制。
 
事件链方法（ECM）
 
  事件链方法（Event Chain Methodology）背后的基本理念是，潜在风险往往不在项目范围之外。必须做好应对这些风险的准备，并计划您的应对措施，因为意外事件会影响您的项目的进度、交付成果以及潜在的成功。
 
极限项目管理（XPM）
 
  极限项目管理 （Extreme Project Management） 与瀑布正好相反。它为您提供了一种管理大规模变革的方法，并且仍然朝着项目完成的方向前进。在 XPM 中，无论项目进展有多远，您都可以更改项目计划、预算，甚至最终交付，以满足不断变化的需求。
 
基于过程的方法
 
其中每种方法都侧重于将工作作为流程的集合。
 
精 益
 
  精益（Lean）是一种专注于精简和减少浪费的方法（精益求精）。第一步是创建工作流程分解，以识别和消除瓶颈和延迟。目标是用更少的人力、更少的钱和更少的时间为客户提供价值。
 
Six sigma
 
  Six Sigma 于20 世纪 80 年代中期由摩托罗拉的工程师介绍，通过识别项目中不起作用的内容来提高质量。
 
  Six Sigma 是一种基于统计的方法，旨在通过测量存在的缺陷并消除尽可能多的缺陷来提高过程质量。 如果 99.99966％ 的最终产品（您的项目可交付成果）没有缺陷，则该过程可以达到 Six Sigma 等级。
 
其他方法
 
PRINCE2
 
  PRINCE2 代表受控环境中的项目。 这是一种用于管理英国政府使用的项目的方法，其特点是基于产品的计划方法。 在 PRINCE2 中，结构化的项目委员会负责高层活动，例如确定业务理由和资源分配。 项目经理负责日程安排等较低级别的日常活动。 这种方法使团队可以更好地控制资源并有效降低风险。
 
PRiSM
 
  PRiSM 代表“集成可持续方法的项目”，旨在在将环境可持续性纳入其流程的同时管理变更。 PRiSM的目标是完成任务，同时减少公司对环境和社会的负面影响。 从字面上看，它是绿色项目管理。
 
项目管理的角色
 
项目经理
 
  项目经理密切监视开发过程，准备并执行各种计划，安排必要和充足的资源，保持所有团队成员之间的沟通，以解决成本，预算，资源，时间，质量和客户满意度方面的问题。
 
  正式的项目经理通常通过美国 PMI 或英国 PRINCE2 之类的机构进行认证。认证后，他们需要通过接受额外的培训来收集目标数量的 PDU（Professional Development Units）来维持其认证。
 
 
 
PDU 代表专业发展单元，是 一种衡量正在进行的专业发展的方法。 为了保持作为项目管理专业人员（PMP）的认证，您将需要维护特定数量的 PDU，这些 PDU 可以通过参加活动或完成课程来获得。
美国项目管理协会（PMI）举办的项目管理专业人员（PMP）认证考试在全球180多个国家和地区推广，是目前项目管理领域含金量最高的认证。被全球项目管理界人士所认可！
 
 
  在实际的工作中，认证并不总是一个要求，它可以是在以后的职业生涯中获得的东西。大多数项目经理通常从工商管理学位开始，但实际中并非总是这样。经验往往比学位更响亮。
 
  通常，项目经理需要熟练使用 PERT 来对项目进行管理。
 
 
 
Rrogram (or Project) Evaluation and Review Technique (PERT) 程序（或项目）评估和审查技术是用于项目管理的统计工具，旨在分析和表示完成给定项目所涉及的任务。它最初由美国海军于1958年开发，通常与1957年推出的临界路径方法（CPM）一起使用。
 
 
软件项目经理
 
  软件项目经理是负责执行软件项目的人员，通常是 PMI 认证的项目管理专业人员 （PMP）。 软件项目经理完全了解软件将经历的 SDLC 的所有阶段。项目经理可能永远不会直接参与最终产品的生产，但他会控制和管理生产中涉及的活动。
 
项目成员
 
他们是负责完成项目一的人员。 团队成员是熟练的专业人员，他们致力于为项目目标做出贡献。
 
客户
 
项目产品的交付者。可能来自内部，也可能来自外部。
 
利益相关者
 
这是在项目中有既得利益的人或团体。它可能是一个组织的内部团体或机构，也可能是公共工程项目的公众。
 
风险管理
 
  风险管理是对风险（在 ISO 31000 中定义为不确定性对目标的影响）的识别，评估和优先级划分，然后协调，经济地使用资源以最小化，监视和控制不幸事件的可能性或影响或最大化机会的实现。风险管理包括与识别、分析和为项目中的可预测和不可预测风险做准备相关的所有活动。
 
风险评估
 
  软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。
 
  项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面。
 
成本预算
 
自上而下的预算方法（经验估计技术）
 
  自上而下的预算方法主要是依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员，在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计，然后继续向下一层传递他们的成本估计，直到传递到最低一层。
 
该技术使用经验导出的公式进行估算。这些公式基于 LOC 或 FP。
 
 
Putnam 模型： 该模型由Lawrence H. Putnam制作，该模型基于Norden的频率分布（瑞利曲线）。 Putnam模型映射了软件大小所需的时间和精力。
 
  
 
   
关于 Putnam 模型，详见 https://wiki.mbalib.com/zh-cn/Putnam%E6%A8%A1%E5%9E%8B
 
  
 
 
COCOMO： COCOMO 是由 Barry W. Boehm 开发的建设性成本模型（COnstructive COst MOdel）的缩写。它将软件产品分为三类:有机软件、半分离软件和嵌入式软件。
 
 
自下而上的预算方法（分解技术）
 
  自下而上方法要求运用 WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源（团队成员的工作时间、硬件的配置）进行的，项目经理在此之上再加上适当的间接费用（如培训费用、管理费用、不可预见费等）以及项目要达到的利润目标就形成了项目的总预算。
 
主要有两种模式：
 
代码行： 依据软件产品中的代码行数进行估计。
功能点： 依据软件产品中功能点的数量进行估算。
 
  自下而上的预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在 5% ~ 10% 之间。
 
质量管理
 
  质量管理确保组织、产品或服务是一致的。它包括四个主要组成部分：质量规划、质量保证、质量控制和质量改进。 质量管理不仅注重产品和服务质量，而且注重实现质量的手段。因此，质量管理利用对工艺和产品的质量保证和控制来实现更一致的质量。
 
软件质量保证
 
  软件质量保证（SQA，Software Quality Insurance）是在软件过程中的每一步都进行的“保护性活动”。SQA 主要有基于非执行的测试（也称为评审）、基于执行的测试（即通常所说的测试）和程序正确性证明。
 
  软件评审是最为重要的 SQA 活动之一。它的作用是，在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。
 
配置管理
 
  配置管理是根据产品的需求，设计，功能和开发来跟踪和控制软件更改的过程。IEEE 将其定义为：the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items。
 
  配置管理是组织管理的一门学科，它负责处理阶段性基础化后发生的任何变化（流程、要求、技术、战略等）。CM 会不断检查软件中所做的任何更改。
 
软件配置管理
 
  软件配置管理（SCM，Software Configuration Management）是应用于整个软件过程中的保护性活动，它是在软件整个生命周期内管理变化的一组活动。是配置管理这个更大的跨学科领域的一部分。
 
  软件配置管理包括版本控制和基线的建立。如果出现问题，SCM 可以确定更改了什么以及是谁更改了它。如果配置工作良好，SCM 可以决定如何在许多主机上复现它。
 
  软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。一旦一个配置对象已被开发出来并且通过了评审，它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。
 
 
 
软件配置管理系统
   库是软件配置管理系统的根本。库是集中控制的文件库，并提供对库中所存储文件的版本控制。任何库中的文件都被视为在确定的软件配置管理之下。
   在项目实际工作中，可以用 SVN、Git 等工具来建立配置库。
 
 
基线
 
  在配置管理中，基线是在某个时间点对产品属性达成的一致描述，可作为定义更改的基础。更改是从此基准状态到下一个状态的移动。 识别基线状态的重大变化是基线识别的主要目的。
 
  如果 SDLC 的一个阶段已经建立了基线，那么就假定它已经完成了，例如，基线是定义一个阶段完整性的度量。当与阶段有关的所有活动都已完成并得到良好的文档记录时，阶段就被确立为基线。如果它不是最后阶段，它的输出将用于下一个直接阶段。
 
版本控制
 
  在软件工程中，版本控制（也称为修订控制，源代码控制或源代码管理）是一类负责管理对计算机程序，文档，大型网站或其他信息集合的更改的系统。 版本控制是软件配置管理的组成部分。
 
  在软件开发中，版本控制系统的使用是必不可少的。详细见博文 版本控制系统 之一 概念、分类、常见版本控制系统（CVS、SVN、BitKeeper、Git 等） 。
 
变更管理
 
  变更管理（Change management）是对所有支持和帮助个人或团队进行组织变更的方法的集合术语。变更的驱动因素可能包括技术的不断演变、流程的内部审查、危机应对、客户需求变化、竞争压力、收购和兼并以及组织重组。 它包括重定向或重新定义资源使用、业务流程、预算分配或其他显著改变公司或组织运营模式的方法。
 
变更控制
 
  变更控制（Change Control）是质量管理系统（QMS）和信息技术（IT）系统中的一个过程，用来确保以受控和协调的方式引入产品或系统的变更。它减少了在没有预先考虑的情况下对系统进行不必要的更改、在系统中引入错误或撤销其他软件用户所做的更改的可能性。变更控制过程的目标通常包括最小化对服务的干扰，减少回退活动，以及对实现变更所涉及的资源的低成本利用。
 
不要与版本控制相混淆。
 
项目管理工具
 
见独立博文
 
参考
 
https://wiki.mbalib.com/wiki/%E8%BD%AF%E4%BB%B6%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86
http://learnfuture.com/PMP/902
https://www.cnblogs.com/leslies2/archive/2012/06/29/2569765.html
https://www.tutorialspoint.com/software_engineering/software_project_management.htm
https://www.wrike.com/project-management-guide/project-lifecycle/
https://www.wrike.com/project-management-guide/methodologies/
https://en.wikipedia.org/wiki/Software_project_management
https://www.projectmanager.com/project-management

       就职于软件行业的人，无论是销售、售前、技术还是财务一定都会接触到关于项目运作相关的工作，不同职位的员工对于项目的关注点也大不相同，财务人员关注项目的收款节点；销售人员关注项目的商务关系及前期引导；实施人员关注项目的实施过程等等。
 
       这就造成各个职位的员工对于涉及职责之外的事情一无所知或了解甚少的情况，虽然这样不会对项目的成功验收造成很大的影响，但是在涉及到一些环节的沟通和配合上多少会有一些吃力。所以今天在这里与大家分享一下我对软件集成项目全生命周期的理解和认知，希望能对大家有所帮助。
 
1. 项目概念
 
1.1 定义分析
 
       项目：是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。
 
       软件项目：是指为企业开发或者部署实施一套专用的系统，或在特定的行业领域做一些系统之间的集成，在进入项目之前必须与用户进行具体需求分析和讨论，明确用户心目中的产品或项目预期是什么样子，然后立项、招投标、签订合同、实施交付。
 
       项目生命周期：是描述项目从开始到结束所经历的各个阶段，一般划分为前期咨询、项目立项、招投标、项目实施、项目运维、项目终结/二期六个阶段，随着时间的推移以及发展，为满足当前发展的需求项目通常会重新定义开发、更新迭代。在项目生命周期运行过程中的不同阶段里，项目双方会派出不同的组织和人员进行项目的工作交互。 
 
 
1.2 项目形态
 
 
 2. 阶段构成
 
       根据不同的项目形态，一般项目运作的周期也不大相同，下述以笔者所在公司数通畅联SOA集成项目的生命周期为例进行阐述，在步骤上与传统项目生命周期存在细微差别。
 
2.1 IT咨询
 
2.1.1 具体内容
 
       此类项目一般为销售通过商机转交、客户介绍、信息搜索等形式探求到甲方有类似需求，之后通过拜访得到客户大致需求信息，后续与售前人员一同前去确认需求及介绍方案。
 
       IT咨询也称为信息化咨询，一般出现在信息化建设前期或信息化整合期，对企业的整体业务、流程、信息化各方面内容进行全面的规划，包括：企业管理模式设计、业务流程、信息化解决方案设计、管理软件系统的实施/应用/整合，具体情况如下：
 
       1. 乙方通过向甲方调研、访谈、接触具体业务等形式根据企业实际的战略、目标、愿景及任务，设定策略性的业务规划，进行企业IT架构的规划，并对应的设计出IT执行计划；
 
       2. 甲方无保留的为乙方提供计划中所需的资料及相关业务流程、数据联系等资料；
 
       3. 计划设计之后，对企业现有/在建的IT应用进行梳理及优化，注重现有管理系统与管理目标、后续需求与发展趋势是否对应，并针对性的进行需求评估与分析，从而制定新的IT建设策略；
 
       4. 在业务及信息化建设部分梳理完毕之后，就需要规划如何实现，包括协助项目选型、项目实施管理（范围、时间、成本、质量、人力、资源、沟通、采购、风险等）；
 
       5. 乙方对成果进行汇报，甲方对乙方规划成果进行审核，有异议则沟通继续修改，无异议则确认验收。
 
2.1.2 参与人员
 
       甲方：高层领导、信息中心管理者
 
       乙方：销售人员、售前人员
 
2.1.3 输出资料
 
       XX企业IT调研报告、XX企业IT建议规划书
 
       资料内容：
 
 1、XX企业IT调研报告
 
 
公司概况：公司的基本情况、股权结构、人员构成、董事会组成及决策机制；管理制度建设情况、技术团队、企业历史沿革、财务状况、企业经营目标、销售目标计划。
 
 
项目意义：产业政策、公司的痛点或需求、项目建设带来的意义。
 
 
产品/服务与技术：产品概述（服务描述、内容描述、报价、核心技术优势）、国内外研发情况、核心竞争力（公司核心竞争力、业务核心竞争力、产品核心竞争力）。
 
 
资金投入情况：总体投资、投资估算表、知识产权情况。
 
 
行业和市场：行业分析、市场分析、目标用户、业务经营范围、竞争分析。
 
 
市场营销：营销分析、渠道策略、分销商/代理商的选择、产品/服务价格。
 
 
现有系统情况。
 
  2、XX企业IT建议规划书
 
 
总体设计：设计依据、方法论、设计思路、技术路线、标准规范体系设计、顶层设计总体架构、安全设计、系统级权限设计、公用编码设计、系统过渡和迁移方案、系统扩展方案。
 
 
软件设计方案：开发方法、内部应用平台软件设计（应用系统架构设计、业务应用系统、综合管理系统、知识管理系统、通信系统、移动办公系统、SOA集成系统）、性能设计。
 
 
硬件设计方案：网络升级改造设计、服务器升级改造设计、存储系统升级改造建设、云调度系统建设、安全系统升级改造建设、容灾备份系统建设、监控运维系统建设、机柜及数据库系统升级改造建设、技术指标设计。
 
 
总集成方案设计：集成方法论、集成要求、集成接口设计。
 
 
项目实施管理方案：项目管理框架、人员控制、范围控制、需求管理、沟通管理、计划管理、进度监控、配置管理、成本管理等。
 
 
项目实施计划：总体计划、软件开发实施计划、软件集成实施计划、硬件集成实施计划。
 
 
项目质量保障方案：质量保障体系、质量管理办法、质量保障措施（人员管理、问题管理、过程管理、系统交付管理）、质量计划。
 
 
项目测试方案：软件测试、硬件测试、验收测试。
 
 
项目培训方案：培训目的、对象、人数、课时、地点、方式、资料、计划、费用。
 
 
项目验收方案：单项验收、试运行、项目终验。
 
 
项目服务方案：服务标准、流程、内容、方式、质保期等。
 
2.2 项目立项
 
2.2.1 具体内容
 
       在确定项目的初期，特别是大中型项目，在经过建议规划之后，高层领导对项目的大致结果是有一定概念的，在立项阶段一方面是将企业现状、项目初步方案、技术来源等情况进行梳理阐明，便于高层掌握项目情况；另一方面是通过立项向企业的上级单位或董事会报备项目情况，发起审批流程，申请拨款启动项目。
 
       具体内容如下：
 
       1. 乙方（多个乙方）为甲方信息中心管理者CTO、高层领导CEO等相关汇报人员提供立项申请指导、建议和规划资料。
 
       2. 信息中心管理者CTO、高层领导CEO申请项目立项，并向董事会汇报项目具体情况、内容、预算，申请审批。
 
       3. 董事会根据汇报情况进行考虑，同意之后通知高层领导CEO，再由高层领导CEO通知信息中心管理者CTO。
 
       4. 审批通过，项目宣布立项，进行后续开展事宜。
 
2.2.2 参与人员
 
       甲方：信息中心管理者CTO、高层领导CEO、董事会
 
       乙方：多个乙方
 
2.2.3 输出资料
 
       XX项目立项报告
 
       资料内容：
 
 1、董事审批意见
 
  2、XX项目立项报告
 
 
项目背景，企业概况、信息化建设背景
 
 
项目建设必要性
 
 
项目的可行性
 
 
项目目标
 
 
项目需求
 
 
项目实施原则和策略
 
 
项目主要建设内容
 
 
项目实施计划
 
 
项目组织机构
 
 
项目投资预算与工作量
 
 
收益/风险分析与控制
 
2.3 招/投标
 
2.3.1 具体内容
 
       这里分为两个步骤，一个是客户方的招标，另一个是实施方的投标。
 
 
招标
 
       项目立项后，企业会针对建设需求，进入公开招标阶段，由企业发出招标公告或投标邀请书，说明招标的项目、产品、服务的范围、标段（标包）划分、数量、投标人的资格要求等，邀请特定或不特定的投标人在规定的时间、地点按照一定的程序进行投标，具体步骤为：
 
     1. 甲方编制招标文件，发布招标公告；有意向乙方查看招标公告；
 
     2. 甲方出售招标文件，对潜在投标人资格预审；乙方购买标书，并提交投标保证金；
 
     3. 甲方接受投标人标书，并按照规定的时间、地点公开开标；乙方根据时间地点进行应标；
 
     4. 甲方根据参与乙方讲标情况由评标委员对投标文件评标，依据原则及程序确定中标人；
 
     5. 甲方通知乙方中标人中标，明确具体细节之后与中标人签订项目合同，履行合同。
 
 
投标
 
       投标是与招标相对应的，投标人（项目实施方）认真分析招标文件后，根据自身产品及解决方案优势编制投标书，在编写投标书中需要注意，标书中的解决方案一定要应标，明确的对应招标需求，另外在撰写投标书上投标单位都是十分仔细的，因为一旦投标，在有效期内不得撤回标书或对标书中的报价、内容做实质性的修改，在投标中，投标单位通常是需要交付投标保证金的，具体步骤如下：
 
       1. 根据甲方招标内容编制投标文件，按照期限交付投标书及投标保证金；
 
       2. 乙方按照规定的时间、地点进行讲标；甲方评标委员对乙方投标文件评标；
 
       3. 等待结果通知，中标后，明确具体细节之后与客户方签订项目合同，履行合同。
 
2.3.2 参与人员
 
       招标：运营人员、信息中心人员、评标委员
 
       投标：售前人员、销售人员
 
2.2.3 输出资料
 
       招标方：招标文件
 
       投标方：投标文件、相关资质证明等
 
       资料内容：
 
  1、招标方—招标文件
 
 
投标须知：项目基本情况、投标方资格要求（基本要求、专项要求）
 
 
项目总体概述：集团概况、业务现状、建设目标
 
 
项目范围及建设内容：项目范围、项目整体要求、详细功能要求、技术实现要求（软件要求、系统安全要求、产品要求、硬件及网络环境要求）
 
 
术语解释
 
 
项目实施服务要求：实施步骤要求、项目实施要求、技术培训要求、项目服务要求
 
 
测试与验收：系统测试、验收条件、验收过程、验收标准
 
 
评分标准：商务部分、技术部分、报价部分
 
  2、投标方—投标文件
 
 
项目定义说明：名称约定、主要术语
 
 
项目背景及现状分析：当前信息化背景、企业发展概况、信息化瓶颈
 
 
项目需求理解与分析：项目需求描述、项目需求理解与分析（企业管控理解和分析、业务维度分析、系统维度分析、系统功能分解、系统特性分解、系统架构分解）
 
 
项目目标和关注重点：项目目标定义、项目目标分析、实现目标前提条件
 
 
项目指导思想和原则：投标方特有的指导思想和原则
 
 
架构体系、规划、方法论：企业架构、IT规划体系、IT规划方法论
 
 
项目总体规划：整体规划、建设阶段
 
 
项目平台架构：总体架构、业务架构、技术架构、功能架构、集成架构、安全架构、产品架构、部署架构
 
 
标准与规范组：平台及产品的标准规范
 
 
项目产品介绍：项目中使用到的产品介绍
 
 
项目部署方案：软硬件配置搭建
 
 
项目实施方案：实施总体方法、实施成功的关键要素分析、实施进度计划
 
 
项目实施团队：团队构建原则、项目实施组织架构、项目实施团队、实施过程和安全保密管理
 
 
项目验收方案：项目初验、终验
 
 
项目培训方案：培训目的、培训策略、培训调研、培训方式、培训课程与内容、培训组织与要求、培训对象
 
 
项目质量及风险管理：项目生命周期管理、项目常见风险分析、项目初步风险分析与策略
 
 
项目服务方案：服务原则、服务承诺、服务体系和流程、常见服务方式和内容、服务响应时间、服务监督机制
 
 
相关案例介绍
 
 
投标公司介绍
 
 
相关资质证明：软著权、企业资质等
 
2.4 项目实施
 
2.4.1 项目启动
 
2.4.1.1 具体内容
 
      本阶段意味着项目正式启动，要成立项目组并确定PMO成员，具体步骤如下：
 
      1. 成立项目组：根据项目情况及人员综合能力组建并整合管理团队的关键成员，并对团队职位进行任命。另一方面项目管理办公室成员一同介入项目，负责对项目前期跟进及后续节点把控；甲方同样组建项目组成员及确认本项目最终负责的领导，通常为信息中心人员；
 
       2. 明确双方项目组成员、成员工作责任和权限；
 
       3. 召开项目启动大会，甲方、乙方项目团队进场，介绍项目目标、范围及工作方法，宣布项目正式启动。
 
2.4.1.2 参与人员
 
       甲方：对应项目组成员、相应负责领导 
 
       乙方：对应PMO管理办公室成员、项目实施团队
 
2.4.1.3 输出资料
 
    项目启动报告
 
    资料内容：
 
 
项目名称
 
 
项目信息
 
 
项目组成员（双方）
 
 
项目启动时间和预计结束时间
 
 
系统环境
 
 
项目范围
 
 
项目进度
 
 
项目分工信息
 
2.4.2 项目蓝图
 
2.4.2.1 具体内容
 
       虽然在投标阶段已经对企业信息化状况有一定了解，但信息采集、需求调研仍是非常重要的一个环节，不可省去。在调研过程中不仅可以明确项目具体需求还可以帮客户梳理出那些存在却没有被发现的需求，只有充分了解、明确这些需求，才能为后续完整制定实施计划打下基础。具体过程如下：
 
       1. 通过现场调研，充分了解和获取客户相关方面的现状和用户对系统的具体需求及期望，经过需求汇总、整理、评审，最终与客户确认项目需求，中间需要甲方客户配合进行调研；
 
       2. 在明确企业业务现状、信息化现状后，分析各业务模块之间的业务衔接环节，进行问题梳理及标准制定，根据业务需求完成功能详细设计和开发方案；
 
       3. 以上准备完毕后，启动蓝图确认会，进行蓝图汇报，双方项目团队均到场，之后让甲方签署蓝图确认单，一切就绪后，宣布正式进入项目实施阶段。
 
       4. 蓝图确认单签署后，项目正式进入实施阶段。
 
2.4.2.2 参与人员
 
       甲方：对应项目组成员、相应负责领导
 
        乙方：对应PMO管理办公室成员、项目实施团队
 
2.4.2.3 输出资料
 
       需求规格说明书，概要设计（设计规格说明书）、集成标准规范文档、细化至人天的工作安排/计划、蓝图确认单
 
       资料内容:
 
   1. 需求规格说明书
 
 
项目概况：公司情况、信息化现状
 
 
项目总体需求：整体需求、集成系统、功能需求、系统环境等
 
 
具体功能需求：业务描述、功能描述、权限设置、功能约束
 
 
非功能需求：扩展性、稳定性、安全性、主题风格、用户操作、可移植性
 
    2. 设计规格说明书
 
 
总体设计：技术架构、功能集成、部署架构
 
 
功能平台：系统架构、功能架构、公共设计、角色设计
 
 
具体功能设计：功能需求、开发思路、集成设计、技术要点、权限设计
 
 
编码设计
 
   3. 集成标准规范
 
 
身份认证规范
 
 
数据集成规范
 
 
应用集成规范
 
 
集成测试规范
 
 
扩展开发规范
 
  4. 工作安排计划
 
 
将工作步骤细分解，细化至人天
 
  5. 项目蓝图确认
 
 
项目总体情况：实施目标、系统架构、工作内容、总体计划、已完成工作、后续工作重点
 
 
项目蓝图确认
 
2.4.3 实施开发
 
2.4.3.1 具体内容
 
       在项目实施阶段，主要由项目实施团队负责对项目需求进行实施实现，对于项目实施，每个公司都有一套方法论，这里以数通畅联方法论为例，具体步骤如下：
 
 
内部日报、成员周报：通过日报及周报管理制度，对项目人员人天/周工作内容及计划进行审查追溯，可及时发现项目中已知或未知的问题，并加以解决防控。
 
 
项目周报、项目追踪：对于项目周报采取双周滚动制，每周为客户发送本周项目工作总结、下周工作计划、后续工作安排，便于客户精准掌握项目进度；项目追踪对项目投入人天情况、功能完成进度进行严格汇报把控，有效控制项目进度，防止项目偏离拖期。
 
 
客户参与、培训协作：在项目中注重与客户的沟通，定期向客户汇报当前项目的进展情况（项目周报，项目会议），让客户能够实时的掌握项目的进展情况，加强对项目的认知度与参与度；同时在项目进行中针对客户方技术人员进行一些产品及功能原理、使用方面的培训，使客户能更快速的掌握产品。
 
 
重点突破、局部上线：遵循敏捷机制，在项目开展2个月左右，部分功能即可上线供客户使用，在保证系统稳定的情况下，对其它功能进行重点攻克，之后进行灰度升级。
 
 
步步为营、逐步推进：在项目中注重对每一个里程碑的掌控，并根据里程碑逐步推进项目进度，最终保障项目的顺利验收。
 
 
全面测试、消缺完善：对项目中完成的每个功能都会进行全面的测试，包括：自测、功能单元测试、小组之间互相测试、项目内部功能联测、用户真实测试等，在测试过程中会对功能问题进行不断的完善。
 
2.4.3.2 参与人员
 
    项目团队及客户方团队成员或负责人
 
2.4.3.3 输出资料
 
       每周项目工作总结、对应的下周工作计划及后续工作安排
 
       资料内容：
 
       采取双周滚动制的工作汇报，即汇报本周具体计划的同时，规划出下周工作计划和后续工作计划安排，依次类推滚动。
 
2.4.4 项目验收
 
2.4.4.1 具体内容
 
        验收阶段主要工作是对项目整体实施工作的回顾和总结，对实施工作的认可，也是对双方高层领导的一个工作汇报，验收合格后，转入系统维护期，具体步骤如下：
 
       1. 对项目情况进行汇总及文档整理；
 
       2. 召开项目验收会议，对项目实施过程、业务内容、工作程序和结果进行汇报及演示；
 
       3. 将项目中所有文档交接于客户； 
 
       4. 专派技术人员现场驻守，保证稳定运行后撤离，后期与运维人员进行工作交接。
 
2.4.4.2 参与人员
 
        双方高层领导、双方项目团队
 
2.4.4.3 输出资料
 
       需求规格说明书、开发规范与集成标准、系统设计规格说明书、所有项目管理过程文档（周报、会议纪要、需求变更等）、测试手册、使用手册、维护手册；项目源码、测试环境、正式环境、项目验收报告、项目验收单
 
       资料内容：
 
       需求规格说明书、开发规范与集成标准、系统设计规格说明书、所有项目管理过程文档（周报、会议纪要、需求变更等）与上述资料相同。
 
   1. 测试手册
 
 
测试方法、被测试对象、目的
 
 
测试环境/配置、测试条件
 
 
测试内容：并发量、负载量、功能使用等
 
 
测试结果分析
 
 
测试改进方案
 
    2. 使用手册
 
 
编写目的：主要对产品功能的使用方式进行撰写，便于系统管理员对信息进行维护和使用人员快速掌握熟悉系统
 
 
功能使用方法介绍（图文）：环境搭建、安装部署、具体使用
 
    3. 维护手册
 
 
编写目的
 
 
系统说明：用途、安全、程序说明
 
 
维护说明：约束条件、验证过程、出错及纠正方法、维护过程
 
    4. 项目验收单
 
    项目名称、启动时间、结束时间、建设内容、完成情况、双方签字确认
 
2.5 项目运维
 
2.5.1 具体内容
 
       项目运维阶段主要任务是系统后期的运维工作，将根据质保维护条款对系统进行持续维护，截止到运维期满后，项目正式结束，具体步骤如下：
 
       1. 在项目验收后，技术人员驻守阶段，运维人员进场；
 
       2. 与项目实施人员进行工作交接，明确项目具体内容、测试结果、部署情况、注意事项等事宜；
 
       3. 与客户方人员进行工作交接，明确相关负责人姓名、职位、联系方式、权限等事宜；
 
       4. 1-2周后，运维人员离场，并进行后续远程支持，直到运维期满为止。
 
2.5.2 参与人员
 
        项目实施人员、运维人员、运维涉及的客户方人员
 
2.5.3 输出资料
 
       项目运维报告、项目运维手册；
 
       资料内容：
 
   1. 项目运维报告
 
 
运维项目背景
 
 
运维目标
 
 
运维人员分配
 
 
运维工作总结（时间段、运维内容、流程规范）
 
    2. 项目运维报告
 
 
运维目的
 
 
适用范围
 
 
服务器及数据库说明
 
 
系统程序详细说明
 
 
系统维护说明（日常维护、备份策略、注意事项等）
 
2.6 项目终结/二期
 
2.6.1 具体内容
 
        项目终结主要为当前交付的应用系统在运行一段时间之后，不再能满足业务的发展需求，重构升级的成本代价大于新系统建设的成本代价，通常情况下企业会对现有的系统进行终结、停用或废弃，之后找新的乙方经历新的项目生命周期，建设适合于业务发展的信息化系统，然而这种终结不是全部系统终结后再进行新系统建设，而是新老系统并行一段时间后，在终结老系统。
 
        项目二期主要是对一期项目的延续，具体表现在甲方对乙方一期项目实施的效果比较满意、在一期建设后又产生了新的信息化需求、需要对一期建设结果进行系统升级、在项目规划时已经做好二期规划等，在以上情况下通常会联系一期项目团队进行项目二期的开展。
 
2.6.2 参与人员
 
 
项目终结：甲方：对应项目组成员、相应负责领导；乙方：新的项目实施团队
 
 
项目二期：甲方：原项目对应项目组成员、相应负责领导；乙方：原项目实施团队（双方离职人员除外）
 
2.6.3 输出资料
 
 
项目终结：甲方向新乙方提供已终结项目的实施方交付的有关项目文件，包括：需求规格说明书、开发规范与集成标准、系统设计规格说明书、项目管理过程文档、测试手册、使用手册、维护手册、运维手册、项目验收报告等。
 
 
项目二期：根据一期项目所提供的文档、源码、环境等，进行新的需求扩展或升级，在新需求方面同样会产生需求规格说明书、需求设计说明书等一系列文档（参考一期）。
 
3. 总结说明
 
3.1 周期分析
 
       本文在项目形态部分为大家介绍了常见的几种项目形态，在阶段构成部分为大家介绍了数通畅联SOA集成项目的全生命周期，无论项目最终结果如何，正常来说，软件项目生命周期从开始到结束一定是一个不断更新迭代的过程，而实施方的产品、解决方案、项目管理方法与被实施方对信息化的管理和重视程度决定着软件项目最终的使用生命周期，如图所示：
 
 
      1. 传统软件项目生命周期
 
       时间：5年，建设2年，使用2年后慢慢终结
 
       原因：建设之前无统一规划；业务越多系统越多，IT逐渐僵硬；企业无信息中心或维护效果差；项目使用产品不够敏捷、扩展、复用性差。
 
       2. 当前软件项目生命周期
 
       时间：6-8年，建设1-2年，使用4-7年后慢慢终结
 
       原因：分析过企业当前现状，有计划目的的建设；对项目实施方产品、方案严格选型；信息中心重视项目成果，后期有专人维护；重视系统后续升级；与时俱进，有计划的开展项目二期。
 
       3. 理想软件项目生命周期
 
       时间：10年以上，建设2年，后续可持续灵活升级支撑企业业务
 
       原因：企业信息化意识到位，项目前期先做咨询规划，重视信息化可持续发展；具有专业开发团队，重视项目过程，项目中主导开发或参与开发，项目结束后有一定的维护、管控能力；建设初期引入平台类产品，先搭框架，再谈建设；对项目实施方产品、技术、方案敏捷性、扩展、稳定等性能严格考量；根据业务发展，技术需求，新旧系统平稳过度式更新；项目实施方知识传递到位。
 
3.2 最佳实践
 
       上述为大家分析了软件项目最终为企业服务的时长，相信所有的企业都希望建设成果可以持续、有效的为企业业务带来支撑，企业想达到以上效果除了具有强烈信息化意识和专业管理团队之外，还需要引入具有专业敏捷的产品与丰富实施经验的实施方。
 
        而数通畅联作为提供开放、敏捷产品和解决方案的集成中间件厂商，将从项目初期为企业提供专业的架构规划、需求分析、技术攻关、风险预测，并根据企业信息化现状制定适合企业后续业务发展的专业技术解决方案，同时提供完备的产品培训，使甲方可以掌握产品常见的应用场景，具体项目场景如下：