文件2《IT项目管理办法》

1、IT项目管理办法信息管理部2004.461 / 61文档可自由编辑目录前言4一、术语定义5二、IT项目生存期72.1应用开发项目生存期72.2应用部署项目生存期82.3生存期模型裁减102.3.1内部项目102.3.2外包项目112.3.3合作项目122.3.4采购项目122.3.5混合型项目13三、IT项目过程143.1启动143.2项目分解与计划143.3项目实施153.4项目结束163.5项目过程总结16四、IT项目计划174.1项目规模估算过程184.2项目规划过程194.3项目责任分配过程194.4项目采购计划20五、IT项目监控225.1项目定期评审过程235.2项目事件评审过程2

2、45.3偏离纠正过程245.4计划修订过程255.5项目采购监控26六、IT项目审核286.1审核计划过程296.2审核执行过程29七、IT项目需求开发与管理317.1需求开发的步骤317.2需求管理的步骤34八、IT项目工作产品及验收368.1交付件368.2质量记录378.3工作产品模板378.3.1任务书模板388.3.2计划书模板388.3.3评审报告模板398.3.4需求归纳表模板398.4项目验收408.4.1可交付物验收408.4.2技术验收408.4.3功能验收418.4.4验收计划41九、项目经理的职责和素质429.1项目经理的职责429.2项目经理的素质459.3项目经理的

3、技能47前言中外运对IT的投资是通过各种类型的IT项目来实现的，通过实施IT项目体现对IT投资的效果，因此有必要对IT项目制定相关的流程和规范。IT项目分为两个阶段：立项阶段和项目执行阶段。本文只涉及项目执行阶段的管理办法，项目立项阶段的流程按照IT项目立项流程执行。本管理办法的适用范围为股份公司总部。中外运股份有限公司信息化组织（以下简称ITO）是中外运股份有限公司专门致力于信息化建设的组织，负责企业信息系统应用的支持、业务信息化的帮助以及基于信息技术的业务开拓。这些责任将使得ITO逐渐成为企业核心竞争力的一个组成部分，与此同时，也要求ITO持续地改善其IT项目管理和运行能力。为了将这些项目

4、管理过程得到有效的落实，特制订以下IT项目管理办法。ITO组织内所有人员需严格执行，保证ITO内的项目管理和系统运行逐渐提高到业界较高水准，满足企业业务高速发展的需要。一、术语定义1. 项目：在规定的时间和预算内完成的某种具有特定质量性能要求的一次性、多任务的工作。2. 项目的特征：l 目标确定性l 时限性l 一次性l 独特性3. 项目生存期：一个项目从立项到项目执行结束的过程。4. 项目生存期模型：是对项目生存期的抽象，其中包括项目阶段的划分、各个阶段的进入条件、输入和输出等生存期公共属性。5. 关键过程域：是项目管理和项目执行所要关注的重要过程域，包括项目管理、项目实施、项目支持等多方面的

5、过程。这些过程域是根据业务需要和资源情况逐步开发定义的。6. 验证：是对系统的评价过程，以确定一个项目执行阶段的产品是否满足在此阶段开始时所给定的条件。7. 确认：是在项目执行过程中或项目结束时评价系统，以确定它是否满足特定的需求。8. 审核：是用于验证或确认的手段。审核是一种正式的评审活动，即需要计划并按计划执行。9. 客户需求（Customers needs）：是客户的需要与期待，这些要求和期待直接相关于用户的业务过程和业务任务需求。10. 系统需求（Requirements for System）：通过对客户需求的分析，确定系统应实现的规格。这些规格描述了系统的行为、特性和属性。系统需求

6、也称为系统规格。11. 功能性需求（Functional Requirements）：支持业务功能的系统需求，如数据检索、交易执行、报告打印等。12. 非功能性需求（Non-functional Requirements）：系统执行的行为特征，如可靠性、安全性、性能指标等。13. IT（Information Technology）：信息技术。14. ITO（Information Technology Organization）：信息技术组织。15. SOW（Statement Of Work）：任务书。16. PP（Project Planning）：项目计划。17. PR（Peer Re

7、view）：同行评审或对等评审。二、IT项目生存期2.1应用开发项目生存期应用开发项目生存期是中外运ITO管辖的所有IT开发项目的生存期模型，该模型可通过剪裁应用到不同类型的开发中。应用开发项目生存期模型定义图示如下：项目立项（略）项目执行：用户需求获取SOW系统概念确定系统定义设计实现验证定义过程实施过程l 项目立项结束，进入项目执行阶段。l SOW是项目执行阶段启动的文件。l 用户需求获取阶段是析取用户对IT系统的需要（Needs），其中包括系统目的、范围、目标、业务需求、限制条件等方面。l 系统概念确定阶段的目的是提出如何满足用户需要的总体策略，即确定满足需求的系统基本实现模式，如体系、

8、架构、获取（Acquisition）方式等内容。l 系统定义阶段是对用户的需求进一步进行开发以得到系统实现的规格定义（Specification）。l 设计阶段包括了系统层面的设计（高层设计）和实现层面的设计（详细设计）。l 实现阶段包括了具体开发、集成、工程测试。l 验证阶段是基于用户的角度对系统的功能进行接收/验证测试。l 项目结束。2.2应用部署项目生存期应用部署项目生存期的执行阶段是将经过验证的应用系统部署到相关业务部门中并投入使用的过程。由于中外运规模较大，且地域分布很广，一个大型IT应用的部署会涉及到多个部门、多个场所和不同的内部和外包资源，因此应用部署往往会作为一个独立的项目进行

9、。应用部署项目生存期模型就是用于此目的而建立的，该模型图示如下：项目立项（略）项目执行：应用部署规划SOW试点发布实施计划制定特殊需求处理切换准备切换l 项目立项结束，进入项目执行阶段。l SOW是项目执行阶段启动的文件。l 应用部署阶段是一个准备阶段，主要目的是进行实施策略、实施方法、相关人员、时间以及试点等方面的总体规划和所需资源的准备。l 试点发布阶段是实施策略和实施方法的测试阶段，主要目的是确认实施策略和实施方法的可行性并获取用于全面部署的经验。在应用部署规划时，如果确认试点发布无必要（例如，曾有过类似产品的发布），则可忽略此阶段。l 实施计划制定阶段是应用部署的详细计划阶段，目的是确

10、定具体的应用部署活动步骤。如果应用部署涉及到多个部门，该阶段也包括每个部门的行动计划。l 特殊需求处理阶段包括识别和解决一些部署点的特殊的要求，目的是保证部署活动不会因为这些特殊要求而受到阻碍。l 切换准备阶段是资源落实和最后测试的阶段，目的是确认切换所有的条件已就绪。l 切换阶段将应用投入实际运行的阶段，其中也包括切换结束的总结（无论成功或失败）。l 项目结束。2.3生存期模型裁减生存期模型并不意味着中外运公司的所有IT项目执行周期一成不变地覆盖整个生存期。不同类型的项目在生存期模型上的启动点和终止点不完全一样，需要根据项目的特征选择项目生存期并根据具体情况对项目生存期进行剪裁。2.3.1内

11、部项目内部项目的特征是项目的管理和资源的控制均在ITO内部，因此可由ITO的一个项目经理负责整个项目生存期的过程和工作产品。实际上，这就是基本项目生存期的应用，具体如下：项目立项（略）项目执行：SOW用户需求获取系统概念确定系统定义设计实现验证应用交付项目执行阶段由一个SOW启动，项目经理根据该SOW制订项目初步计划，计划可在各个阶段里程碑结束后进行调整。2.3.2外包项目外包项目的特征是项目的管理和资源的控制均在ITO外部，ITO代表中外运公司向外包公司发出需求并定义完成条件。ITO项目经理的责任是负责提供合理的公司业务对IT系统的要求并负责确认项目输出的有效性，具体如下：验证项目立项（略）

12、项目执行：SOW用户需求获取系统概念确定ITO- 标书- 合同企业采购部门系统定义设计实现应用交付外包部门 项目执行阶段由一个SOW启动，待完成了初步需求分析并形成了系统概念后，将用户初步需求和系统概念设计反应到标书中来选择外包商，反应到合同中来启动外包项目。此外，项目生存期中验证阶段回到ITO来执行。一般的应用交付涉及到用户的参与，但该阶段的管理仍以外包商负责，或双方协调后共同负责。如果外包的范围与上述不同，可对上述剪裁模式进行调整，关键是合同和验证两个控制点。例如仅将设计部分外包时，标书和合同涉及的也将仅仅是设计阶段，验收也是对设计的验收。需要注意的是验证部分参与的内部人员和企业内部用户与

13、实现部分参与的人员不同。2.3.3合作项目合作项目是ITO与合作方资源统一管理的工作模式。若是以ITO为主，可参照2.3.1节描述的剪裁模型；如果是以外方为主，则可参照2.3.2节描述的剪裁模型。2.3.4采购项目外包项目和合作项目本质上也是采购项目，是IT服务的采购。因此IT服务采购项目的生存期参照上面2.3.2节和2.3.3节。本节描述的是IT设备（包括软件）的采购项目，具体如下：项目立项（略）项目执行：验证应用交付SOW用户需求获取系统概念确定ITO供货程序- 采购标书- 采购合同企业采购部门 供应商同样，内部以SOW启动来确定设备采购的需求以及采购原则与策略（系统概念确定）。这些内容确

14、定后形成采购标书，进而形成采购合同。供应商按其自己的供货程序工作。如果必要，可在他们的供货程序中插入质量检验的审核点。2.3.5混合型项目当一个IT项目较复杂时可能包括了自行开发、合作部分、外包部分以及采购部分。在这种情况下可将项目分解成若干子项目，每个项目参照上面适用的生存期分别进行管理。三、IT项目过程下述模型是个简化的IT项目执行过程模型，该模型包括了最基本的控制环节、分解原则和实施过程等要素。项目执行过程模型图示如下：项目立项（略）项目执行：项目分解与计划启动结束项目执行3.1启动IT项目在执行阶段必须有一个正式的启动文件SOW。正式的含义包括：l 来自于可下达任务的授权机构l 具有明

15、确的主管人（发起人）l 指定了项目经理l 清晰的任务陈述（SOW）SOW定义了项目执行阶段的开始。3.2项目分解与计划当项目经理接到任务书后，假设对任务书没有任何疑义，那么项目经理需要执行的第一个过程是进行项目计划，这样才能保证项目有序的执行。由于直接面向任务书中SOW进行计划会很难，特别是其中描述的任务规模很大时更是如此。一个有效的方法是将项目执行分为若干阶段，然后按阶段进行规划。例如将项目执行分为如下的三个阶段：项目执行：SOW实现设计需求定义当然，如果上述阶段划分太粗，还可以进一步细化，例如将“设计”分为“系统设计”和“单元设计”，将实现分为“编码”、“测试”和“集成”。如果有必要，还可

16、以增加一些阶段，如在“需求定义”和“设计”之间增加一个“技术选择”的阶段来专门分析采用什么技术对系统开发最有效。3.3项目实施项目实施是项目计划的执行。为了能够知道项目进展是否符合项目计划，需要对实施过程进行监控。监控的方法是每隔一个固定的时间对项目状态进行一次检查，然后与计划进行比较。如发生了偏离，则进行纠正。仅仅按固定的时间间隔检查项目状态有时也不能及时处理项目的问题，例如在间隔之间发生了重大影响项目计划的事件，如一项关键技术无法应用。因此要增加基于事件的检查。偏离纠正包括两个方面，一个方面是对项目工程活动和工作产品发生的偏离进行纠正，另一方面是对计划进行修订。这些工作必须加以控制，按严格

17、的规范执行，否则不仅仅偏离未能解决，还会引起新的问题。在项目实施过程中，虽然是按项目计划进行的，但项目计划仅仅是定义了在什么时间由谁完成什么任务，没有规定如何完成这些任务。如何完成有两种方式，一种是凭执行者的经验决策，另一种是定义好完成任务的过程和模板，然后按照过程和模板进行工作。当然，这两种方式会结合起来。3.4项目结束项目计划的所有任务完成了，项目就可以结束。项目计划确定的生存期中定义了项目的结束阶段和结束应该进行的工作。项目结束不仅仅将项目交付件交给客户就算完成了，还有一些其它总结性的工作，如项目数据汇集等。项目数据可为其它项目执行提供依据和参照。3.5项目过程总结一个基本的项目管理体系

18、应管理项目的启动、项目划分和计划、项目的执行管理以及项目的结束。一个更完善的项目管理体系还应包括如何完成工程任务以及其它任务的过程。此外，还应包括需求开发和需求管理。四、IT项目计划项目计划的目的是为项目的执行和管理提供一个合理计划。项目计划过程域中的过程包括估计项目规模、定义项目生存期、确定项目目标、制订人员、时间和投入计划。项目计划过程域与IT项目生存期的一个示例关系如下：用户需求获取系统概念确定系统定义设计实现验证应用交付计划修订点计划修订点计划修订点计划修订点计划修订点计划点计划点 箭头所指示的是项目计划在生存期的一个应用场景。前两个阶段是由ITO和业务部门共同进行初步需求分析和系统概

19、念确定，ITO在项目初始制订了计划，并在第一个阶段完成后对计划进行调整，然后实施第二个阶段。第二个阶段完成后，交给一个ITO内的项目开发组织，开发组织在他们承接项目的第一个阶段（生存期模型第三个阶段）制订项目计划，并在每个阶段完成后，调整或修改计划。计划的调整或修订并不是必需的，只有当发现计划与实际不符时才进行。项目计划过程的目的是为执行软件工程活动和管理软件项目建立一个合理的项目计划。项目计划过程涉及的主要方面包括软件项目规模评估、计划责任的协商与确立以及软件项目计划的制定。项目计划的目标为：l 项目规模估算并文档化，以保证在项目规划和跟踪中可用。l 规划项目活动和责任并文档化。l 项目相关

20、组和人员同意所分配的责任。根据这些目标，在ITO项目计划过程域中定义了三个过程：l 项目规模估算过程l 项目规划过程l 项目责任分配过程4.1项目规模估算过程过程名项目规模估算过程标识PP-01目标软件规模估算并文档化，以保证在项目规划和跟踪中可用。进入条件SOW（任务书）下达，并详细描述了任务范围。参与角色1. 项目经理(由SOW确定)2. 项目人员(由SOW或项目经理确定，包括项目经理)3. 相关评审人员(由项目经理确定)4. 项目主管(高层项目主管经理，由SOW确定)输入SOW过程步骤输出序号描述项目经理根据SOW确定项目工作分解 (WBS: Work Breakdown Structu

21、re) 的策略和估算准则，其中包括估算单位、估算方法、估算争议处理等。- WBS策略- 估算准则项目经理向项目人员分配项目分解任务。(如果项目规模不大，可由项目经理本人独立进行项目分解和任务规模估算工作。)项目人员根据WBS策略和估算准则对项目进行分解估算，分别建立各自管辖任务的WBS和相应的任务规模估算。项目经理负责进行汇总。- 项目任务分解(WBS)项目经理组织有关人员对WBS进行评审并根据评审结果对WBS以及估算进行修订。评审的目地是保证分解没有遗漏、重叠等问题；规模估算有依据。- 修订的项目WBS和任务规模估算项目主管对WBS和估算结果进行审核。审核的目的是保证项目范围理解正确、分解策

22、略正确、估算结果合理。- 审核通过的项目WBS和任务规模估算项目经理负责整理上述步骤的输出，形成项目规模估算文件。- 项目规模估算文件完成标志1. 项目WBS和任务规模估算通过项目主管审核。2. 形成项目规模估算文件(过程提交产品)。4.2项目规划过程过程名项目规划过程过程标识PP-02目标规划项目活动和责任并文档化。进入条件项目规模估算完成。参与角色1. 项目经理(由SOW确定)2. 相关评审人员(由项目经理确定)3. 项目主管(高层项目主管经理，由SOW确定)输入1. SOW2. 项目规模估算文件过程步骤输出序号描述项目经理根据SOW确定项目具体目标和项目交付件。- 项目目标描述- 项目交

23、付件清单确定项目策略，其中包括项目组织结构。- 项目组织图等项目经理根据SOW确定项目生存期模型。- 选择的生存期模型项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资源，包括人力资源。- 项目资源投入表项目经理根据SOW、项目生存期模型和规模估算文件确定项目时间安排。- 项目时间计划表项目经理根据SOW、项目生存期模型和规模估算文件确定投入的资金。- 项目资金计划表项目经理对项目可能的风险进行分析并对高风险给出控制策略。风险分析是基于项目目标和项目计划的，即影响项目目标和计划可能发生的事件。- 项目风险控制表项目经理基于上面的输出，产生项目计划草案。- 项目计划草案项目主管召集有关

24、人员对项目计划进行评审。项目经理根据评审意见对项目计划进行修订，形成正式项目计划文档，并由项目主管根据项目确认。- 项目计划评审报告- 项目正式计划文档完成标志1. 项目计划经过评审。2. 正式项目计划文档产生。4.3项目责任分配过程过程名项目责任分配过程过程标识PP-03目标项目相关组和人员同意所分配的责任。进入条件项目正式计划形成。参与角色1. 项目经理(由SOW确定)2. 项目组成员(由项目计划确定)3. 项目主管(高层项目主管经理，由SOW确定)输入项目计划过程步骤输出序号描述项目经理根据项目成员和时间计划生成每个人的任务时间计划并发放给各个项目成员。- 个人项目任务时间计划各个相关人

25、员确认所分配的责任，其中包括：l 分配的任务和时间是合理的。l 可满足完成任务所需要的业务要求。l 可满足完成任务所需要的时间要求。若不能确认上述一项或若干项条件，则将情况反馈给项目经理。- 个人项目任务时间计划确认结果项目经理根据反馈情况对计划进行调整，并对变化的人员责任重复上一步骤。若有影响较大的调整，如关键人员的调整需得到项目主管的批准。若无调整，则跳过此步骤。- 调整的项目计划项目经理发布项目计划，发布对象包括：l 项目主管l 项目组成员其他项目相关组织或人员(如文档管理部门)完成标志1. 计划经过所有项目相关责任人员的确认。2. 对无法承担项目责任进行调整并反映到计划中。3. 调整的

26、计划向所有有关人员发布。4.4项目采购计划采购规划是确定哪些项目需求可以通过从项目组织之外采购产品、服务或成果，从而最好地满足某些项目需求，是项目团队在项目实施过程中可以自行满足的过程。它涉及是否需要采购、如何采购、采购什么、采购多少，以及何时采购等。当项目从实施组织之外取得项目履行所需的产品、服务和成果时，每项产品或者服务都必须经历从采购规划到合同收尾的各个过程。采购规划过程包括对每项外购决策涉及的风险，及就风险缓解或风险转移进行审核。中国外运信息化建设中的IT采购工作分成项目采购和日常采购，日常采购包括但不限于个人电脑及配件的采购。日常采购在每年年底制订采购计划，并通过项目采购方式选定合格

27、经销商和购买产品种类，有效期1年。日常采购均从选定的合格经销商中选择。日常采购由具体采购人在合格经销商中采取两人（含）以上询价的方式进行，部门负责人负责监控是否按流程进行，并抽查报价。主管（副）总经理可以确认部门负责人的签字，也可以再次抽查。项目采购需成立采购项目组，项目组应根据情况，在符合法律相关规定的前提下，以公开招标、邀请招标或者内部议标的方式选择设备供应商。五、IT项目监控项目执行监控的目的是关注项目进展情况并对发生的偏差及时进行纠正。项目执行监控的依据是项目计划，凡是计划了的内容，都需要进行监控，例如投入和时间安排。项目计划过程域与IT项目生存期的关系如下图所示：用户需求获取系统概念

28、确定系统定义设计实现验证应用交付监控点监控点监控点监控点监控点监控点监控点监控点监控点监控点监控点监控点项目计划箭头所示是项目执行监控的一个应用场景。一般项目监控采用定期评审，例如按周的定期评审。在每次定期评审中，检查项目是否偏离了计划。若发生了偏离，则立即采取纠正措施。此外，项目执行监控也可能是事件驱动的，一旦在定期评审之间发生了重要的项目管理事件，如发生了某种风险，则进行基于事件的评审，并根据评审结果采取相应措施。每次评审的内容和结果要向所有相关人员通报，相关人员包括项目人员、用户和企业相关主管。通报通常采用定期项目简报的形式。项目监控过程的目标为：l 按照计划跟踪项目的实际结果和执行性能

29、。l 当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。l 保证相关人员和组织同意所改变的责任。根据上述目标，项目监控过程域包括四个过程：l 项目定期评审过程l 基于事件的评审过程l 偏离纠正过程l 计划修订过程项目评审过程分为定期评审和基于事件评审。定期评审是正常的周期性评审，基于事件的评审是当发生了严重影响项目进展事件时进行的评审。基于事件的评审由项目经理根据具体情况决定。偏离纠正过程用于控制管理项目进程中发现的问题和问题的处理。计划修改过程用于控制和实施计划的变更，保证变更后的计划仍然具有合理性。5.1项目定期评审过程过程名项目定期评审过程过程标识OM-01目标按照计划跟踪项

30、目的实际结果和执行性能。进入条件到达项目评审时间参与角色1. 项目经理(由SOW确定)2. 项目组成员(由项目计划确定)输入项目计划过程步骤输出序号描述项目经理根据项目计划本阶段要求完成的内容，收集各个项目成员的任务完成状态。- 项目进展状态项目经理将各个项目成员任务完成的状态与计划进行比较。若项目经理认为出现与计划的重要偏离，则与相关项目人员分析偏离原因，提出纠正措施，纠正措施包括对偏离的纠正或对计划的修改。对不是重要的偏离，则不提出纠正措施，而是列入到下次评审关注对象。偏离程度的判断由项目经理负责。- 偏离纠正措施项目经理审查以前定期评审确定关注的偏离问题(如存在的话)，并确定是否采取偏离

31、纠正措施。- 偏离纠正措施(若存在需纠正的偏离)项目经理审查目前阶段正在执行的偏离纠正措施，若发现问题则给出问题解决建议。- 偏离纠正措施执行建议项目经理将上述评审结果形成项目定期评审报告，并发布给相关人员，发放范围依据项目计划。- 项目定期评审报告完成标志1. 项目计划本阶段内所有要求的完成内容与实际完成状态进行了比较。2. 对需要纠正的偏离，向相关项目人员发出了纠正措施或纠正措施执行建议。3. 项目定期评审报告完成并向相关人员发布。5.2项目事件评审过程过程名项目事件评审过程过程标识OM-02目标按照计划跟踪项目的实际结果和执行性能。进入条件项目经理得到项目成员的事件报告并决定进行评审。参

32、与角色1. 项目经理(由SOW确定)2. 项目组相关成员(事件报告者和其他相关人员)输入1. 事件报告2. 项目计划过程步骤输出序号描述项目经理与相关人员分析事件对计划的影响，其中包括：l 计划进度的影响l 计划成本的影响l 计划资源的影响l 质量的影响等- 事件影响分析项目经理与相关人员确定事件处理措施，处理措施包括事件的解决、计划的调整等方面。- 事件处理措施项目经理落实事件处理的资源保证，如人力的保证。项目经理将上述评审结果形成项目事件评审报告，并发布给相关人员，发放范围包括评审会人员、主管人员以及其他相关人员。- 项目事件评审报告完成标志1. 确定了项目事件处理措施并落实了相关事件处理

33、的资源。2. 项目事件评审报告完成并向相关人员发布。5.3偏离纠正过程过程名计划偏离纠正过程过程标识OM-03目标当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。进入条件1. 项目定期评审会发出偏离纠正措施，或2. 项目事件评审会发出事件处理措施参与角色1. 偏离纠正人员，或2. 事件处理人员、3. 项目经理输入1. 偏离纠正措施，或2. 事件处理措施过程步骤输出序号描述偏离纠正人员/事件处理人员根据偏离纠正措施/事件处理措施制订纠正/处理步骤。- 偏离纠正/事件处理步骤偏离纠正人员/事件处理人员执行制订的偏离纠正/事件处理步骤，直至结束。- 偏离纠正/事件处理结果项目经理审核偏

34、离纠正/事件处理结果，若存在问题，则确定相应措施，再重复1-2两个步骤。偏离纠正人员/事件处理人员将偏离纠正/事件处理结果形成报告。- 偏离纠正/事件处理结果报告项目经理审核偏离纠正/事件处理结果报告，并发布给有关人员。完成标志1. 项目经理审核通过偏离纠正/事件处理结果。2. 偏离纠正/事件处理结果报告完成并向相关人员发布。5.4计划修订过程过程名计划修订过程过程标识OM-04目标1. 当实际结果和执行性能偏离计划时，要采取纠正措施并对其进行管理。2. 保证相关人员和组织同意所改变的责任。进入条件1. 项目定期评审会发出偏离纠正措施，该措施包括计划的修订，或2. 项目事件评审会发出事件处理措

35、施，该措施包括计划的修订。参与角色1. 项目经理2. 项目主管输入1. 偏离纠正措施，或2. 事件处理措施过程步骤输出序号描述项目经理根据偏离纠正措施/事件处理措施确定计划修订的范围和内容。- 计划修订范围和内容项目经理根据确定的修订范围和内容修订计划。- 修订的计划若修订的计划涉及到人员责任的变化，则项目经理与相关人员确认变化的责任是否可接受。若不可接受，则需进一步调整。- 修订的计划项目主管审核修订的计划，若存在问题确定重新修订的范围和内容，再次执行步骤2-3。- 重新修订的范围和内容，或- 审核通过的计划项目经理发布经项目主管的审核计划，发布范围同原计划发布的范围。完成标志1. 项目主管

36、审核通过修订的计划。2. 审核通过的修订计划向相关人员发布。5.5项目采购监控在进行项目采购的决策过程中，应考虑项目预算等制约因素。实施组织的长远战略也是在采购监控中应考虑的内容。如果决定外购，则反映了实施组织的长远规划和项目的当前需要。例如，决定购置某种开发平台或数据库，不是临时使用，而是希望获得长期支持。从项目经济效益上看可能合算，也可能不合算。但是如果实施组织需要长期使用该开发平台或数据库，则分摊到项目上的那部分购置费用就有可能低于临时使用的费用。在进行项目采购时，应成立采购项目组，并对项目采购的过程进行监控。采购项目组包括业务部门和信息管理部的主管领导及相关负责人员和经办人员，必要时请

37、企划部、财务部等部门参加。根据中国外运股份有限公司投资管理规定，超过三百万的项目采购，还要上报股份公司，经批准后方可执行。项目采购流程如下：1. 起草立项报告项目组根据项目需求描述决定何时采购何物，制定相应的采购计划并起草立项报告，通过内请流程上报公司审批。审批通过后，成立IT采购项目组，并确定项目组成员。2. 确定采购方式经IT采购项目组讨论通过后，决定采购方式，主要包括三种方式：公开招标、邀请招标、询价采购。3. 供应商的选择和询报价IT采购项目组应根据备选供方的报价单进行评定，即进行供应商的选择。4. 确定供应商和价格IT采购项目组经过讨论，最终确定供应商和采购产品的价格。5. 签订合同

38、IT采购项目组和产品供应商谈判后签署采购合同。6. 合同执行产品供应商按合同规定履约，IT采购项目组成员负责产品验收。7. 价款结算IT采购项目组负责办理和产品供应商的价款结算。8. 填写IT采购申请/处理单IT采购项目组负责填写IT采购申请/处理单。六、IT项目审核IT项目审核过程是一种正式的评审，需要较高的资源投入，因此并不意味着所有IT项目交付件都要进行正式的审核。审核对象的确定由项目经理在项目计划时根据质量风险来确定。IT项目审核包括三个部分：审核计划、审核执行、审核问题纠正，这三个部分描述如下：审核计划审核计划是基于项目计划确定的审核对象和标准的审核过程来定义审核目标、资源计划和时间

39、计划。在项目计划中，需要确定审核对象和相应的审核主持人，与此同时在计划中分配审核主持人审核计划和审核执行任务。在一个项目中不同阶段会对不同的交付件进行审核，这些审核的主持人可以是不同的。一个主要的原则是审核主持人不能是交付件的责任人。审核执行审核执行包括审核准备、召开审核会和建立审核记录。审核准备包括审核对象资料准备、审核人员熟悉所负责的审核内容。审核会一般不超过两个小时，否则效率会大大降低。审核会的目的是审核交付件是否满足相应的准则，而不是审核人的能力和具体采用的开发方法、技术的正确与否。审核记录要记录审核过程发现的缺陷，缺陷属性，例如严重程度、来源（本阶段产生的，还是前面阶段遗留下来的）等

40、。审核问题纠正审核问题纠正是解决审核中发现的缺陷。审核问题的纠正要加以跟踪，直到全面完成。6.1审核计划过程过程名审核计划过程过程标识PR-01目标对审核活动进行计划。进入条件到达项目计划的审核计划时间。参与角色1. 审核主持人(由项目经理在计划中指定)2. 审核人3. 交付件开发责任人输入1. 审核对象定义(根据项目计划)2. 审核过程过程步骤输出序号描述1审核主持人根据审核对象定义确定审核目标。- 审核目标2审核人与交付件开发责任人讨论确认审核目标。- 交付件开发责任人确认的审核目标3审核主持人根据审核对象和审核目标确定主审人和审核人以及它们的责任，并得到这些人员参加审核的确认和对审核目标

41、的确认。- 审核人名单- 确认的审核目标4审核主持人与交付件开发责任人确认审核材料提交的时间和发放的对象。- 审核材料提交时间、清单和发放对象5审核主持人确定审核时间和地点并得到审核人员和交付件开发责任人的确认。- 审核时间6审核主持人形成书面审核计划并送达交付件开发责任人、所有审核人员和项目经理。- 审核计划完成标志审核计划送达所有相关人员。6.2审核执行过程过程名审核过程执行过程过程标识PR-02目标按照计划执行审核。进入条件1. 到达审核计划确定的审核任务时间2. 审核对象材料发放参与角色1. 审核主持人(由项目计划确定)2. 审核人员(由审核计划确定，包括主审人)3. 交付件开发责任人

42、输入1. 审核计划2. 审核对象材料过程步骤输出序号描述1所有审核人通过审核对象材料了解与其责任相关的审核内容。审核主持人对此进行确认。无2审核主持人按计划召集审核会。无3主审人报告全面审核的结果。- 主审人审核结果4各个审核人报告各自责任范围内的审核的结果。- 审核人审核结果5审核人讨论交付件可能的缺陷。- 候选缺陷6交付件开发责任人对审核人提出的问题应答。无7审核人确认交付件的缺陷和缺陷属性，其中包括严重程度(高、中、低)和来源(本阶段产生，前面阶段遗留)。- 缺陷清单8审核主持人形成审核报告，并得到与会人员的认可。- 审核报告确认的缺陷清单作为该报告的附件。10审核主持人向项目经理、质量

43、保证经理、配置管理经理和与会人员提交审核报告。- 无完成标志审核报告完成并向相关人员发布。七、IT项目需求开发与管理7.1需求开发的步骤系统需求是通过一系列步骤逐步转化得到的。这些步骤可能执行一次，就可得到开发人员所要的系统规格定义，但更多的是重复地执行多次来确定系统规格定义。需求开发的基本步骤如下：l 确定项目范围l 获取客户需求l 分析客户需求l 制订系统规格l 验证系统规格l 系统规格受控确定项目范围项目范围本身往往在项目开始时也不是很容易确定。客户是一个群体，不同层面的人员因处于不同的地位会对项目含义有不同的认识。有时在同一范围概念下，也会有不同内容的理解。这个阶段的目的是建立一个统一

44、的项目视图并在这个视图的基础上对项目范围取得共同的认识。项目视图需要采用客户容易理解的图示来表达，例如系统环境关联图，系统功能层次图、系统在业务价值链中的位置等。利用这些图示来进一步刻画和描述系统范围要素，如支持的用户类别、系统特征、基于的环境和支持目标等。项目范围实质上是客户需求的一个部分并且是一个重要的部分。项目范围为项目任务圈定了一个问题考虑范围。随着需求分析的进展，项目范围会发生变化，这些变化应及时反映到相关的文档中，并及时知会相关的人员。获取客户需求项目范围定义是项目宏观的需求析取，为了能够真正开发一个应用系统，必须全面了解客户对系统的要求。由于客户不是系统分析人员，因此这个阶段的目

45、的是确定有效的方法，然后利用所确定的方法从相对分散的需求源，系统化地获取客户需求。获取客户需求方法的基本原则是系统地定义需求类别、建立统一的需求表达、识别和规划需求获取的渠道。系统地建立需求类别可以将一个大的问题分解为若干小的问题，同时可帮助客户需求获取人员完备地收集客户需求。建立统一的客户需求表达可一致化和规范化得到的需求，为后面的工作提供一个良好的基础。识别和规划需求渠道可有效地配备资源。需求获取渠道不仅仅是按确定用户类别的访谈，也包括业务资料的分析等其它方面。分析客户需求获取的客户需求难以直接转化为系统规格定义，因为这些需求往往是概要性的、一般情况下不会完备、相互之间可能存在不一致。因此

46、这个阶段的目的是对获取的需求系统地加以分析，建立一个相对完整的系统概念模型，如系统交互模型。通过系统概念模型的建立来细化、补充需求、消除需求中的不一致性。这个阶段会继续执行上个阶段的工作，以解决已经获取需求中的问题并补充分析客户需求所需要的进一步信息。这个继续工作不是简单的重复需求获取的工作，而是针对客户需求分析中发现的问题。客户需求分析技术包括许多类型，如非常形式化的建模计划和简单的业务场景分析技术。具体技术的采用取决于客户需求的复杂程度、客户的背景以及分析人员对技术的掌握等诸多因素。此外，分析技术的采用也取决于是否有有效的工具支持，特别是基于图形的分析技术。制订系统规格系统分析人员必须给系

47、统设计人员提供完整、清晰、明确的系统设计要求。因此这个阶段的目的是基于客户需求和对客户需求的分析结果建立书面的系统规格定义。这个规格定义不仅仅作为设计人员的设计依据，也将作为系统验证的依据。同客户需求分析一样，系统规格定义也包括许多类型的方法和技术，如形式化的定义方法和自然语言的描述。一个理想的情况是分析模型和定义模型采用相同的技术。这样不仅仅可以平滑地联结分析客户需求和制订系统规格这两个阶段，同时也可大大提高工作效率，因为分析模型的结果可被重用到规格定义中。同样，具体技术的采用也与客户需求阶段相同。验证系统规格系统规格定义一旦确定，将作为开发依据贯穿在整个项目开发活动中。因此如果规格定义存在

48、缺陷，将会产生很高代价的质量成本。此外，系统规格是通过客户需求的分析和转换产生的，因此这个分析和转换可能会存在偏差。这个阶段的目的就是来验证是否定义的系统能够真正满足客户的需求。系统规格验证包括用户评审、内部评审、走察（Walk-through）或更为严格的同行审核（Peer Review, Inspection）。如果需要让客户对系统实现后的式样有充分地了解，还可以建立系统原型（Prototype）供客户评审。系统验证技术和方法的采用是风险和成本的平衡。例如原型技术会很大程度降低实现的系统背离用户需求的风险，但需要较高的投入。不过由于系统规格是保证系统成功的关键，因此采用多种验证形式其中包括

49、较严格的验证形式是十分必要的。系统规格受控正如上面多次指出的，系统规格将在整个项目生存期中作为系统实现的依据，其中包括设计的依据、系统测试的依据、验收的依据等。因此如果系统规格随意变更，则会引起整个开发的混乱。这个阶段的目的是将系统规格纳入到一种受控的状态下。系统规格的受控包括两个环节，一个环节是批准，另一个环节是“冻结”。当系统规格经过完整的开发过程产生出来后并由各方审计无误后，则由项目权威机构正式批准。第二个环节是将批准的系统规格“冻结”，即不能随意地对其更改。这之后的任何更改要通过严格变更控制程序。这两个环节是将系统规格“基线化”。基线化是配置管理的任务。实际上，系统规格受控通常都是配置

50、管理中的一个环节。7.2需求管理的步骤需求管理的目的是保证系统需求作为基线加以管理，即系统需求定义的建立、使用和修改均加以控制，以保证系统需求可用性和其它项目活动与系统需求的一致性。需求管理与配置管理密切相关。实际上，需求是作为配置项纳入到配置管理中的。需求管理的基本步骤如下：l 建立系统需求基线l 发布系统需求基线l 系统需求基线跟踪报告l 处理系统需求基线修改请求建立系统需求基线建立系统需求基线是将开发的系统需求置为基线状态。如果实施了正式的需求管理和配置管理，可将系统规格纳入到需求管理和配置管理中。例如，一个具体的做法可以是将开发完成的系统规格提交给配置管理，由配置管理员对规格进行配置标

51、识，然后入配置管理库。发布系统需求基线由于系统需求基线是整个项目生存期项目活动的依据，因此应将正式建立的基线及时加以发布，以确保所有相关的人员了解基线的状态。特别当基线修改后基线的及时发布对正在进行的项目活动至关重要。系统需求基线跟踪报告为了保证系统需求基线被有效的实现，需要对需求基线的实施进行跟踪，并将跟踪的结果进行报告。例如跟踪系统设计是否覆盖了所有的需求基线。处理系统需求基线修改请求这是需求基线管理的最核心也是最复杂的一个步骤。这个步骤包括了一系列子步骤如下：l 对需要更新的基线部分提出更改请求。l 分析、审核更改请求，其中包括确认更改理由的充要性、分析更改的波及范围、估算更改的投入等方面。l 如果同意更改，则制订更改计划。l 实施更改计划。l 审核更改结果。l 批准更改。l 更新需求基线。由于需求基线修改涉及到多方面人员，因此对需求基线的修改（也包括对其它基线的修改）的批准要征得相关人员的同意。一般在配置管理体系下，由相关人员代表成立一个配置管理委员会来处理基线管理事项。八、IT项目工作产品及验收IT项目工作产品是IT项目过程的输出。这些输出包括两类，一类是通过开发产生的交付件，这些交付件是软件产品的一部分，有些会最终提供给客户使用，有些仅仅是中间产品（如系统设计）或管理文件（如项目计划）。另一类