(项目管理)项目执行流程

项目执行流程

1 目的及适用范围

1.1 为规范项目业务中项目执行过程，达到项目的成本、进度、质量的统一，特制定本程序；

1.1 本程序文件适用于某公司项目业务中项目执行；

1.2 本程序文件由某公司 制定，其解释权及修改权属于 ；

1.3 本程序文件从 年 月 日起执行；

2 职责

2.1 项目中心负责项目执行的总体进程，并对执行的最终结果负责；

2.2 主管副总和执委会负责在关键节点监控和协调资源；

2.3 质量控制部负责对项目执行过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；

3 定期战略质询流程

3.1 决策委员会同意签订合同后，项目部项目经理（在项目销售流程中的准项目经理）制订《项目计划书》，交由执委会审批，如果未通过，项目经理重新修改《项目计划书》；

3.2 如果审批认可，项目经理将项目计划递交给客户评审，若未通过，项目程序文件 项目执行流程 年 月 日起生效 文件号

编制 审核 批准 版 次 1.0

日期 日期 日期 共6页 第1页

经理修改《项目计划书》

3.3 若客户评审通过，进行项目资源安排，若所需资源在项目中心本身内，由项目总监完成资源安排，若所需资源跨项目中心外的多个部门，由执委会完成资源安排；

3.4 获得所需资源后，项目经理进行需求分析，交质量控制部进行质量检验，若质检未通过，项目经理修改需求分析；

3.5 若质检通过，专家委员会对需求分析内容进行评审，若未通过，项目经理修改需求分析内容；

3.6 若通过内容评审，项目经理将需求分析交给客户评审，若未通过，项目经理修改需求分析，若通过，项目经理进行总体设计，同时将相关成果和文档放入资源中心存档；

3.7 质量控制部对总体设计进行质量检验，若未通过，项目经理修改总体设计，若通过，专家委员会对总体设计内容进行评审，若未通过内容评审，项目经理修改总体设计内容，

3.8 若通过内容评审，项目经理将总体设计交给客户评审，若未通过客户评审，项目经理修改总体设计，若通过客户评审，项目经理安排项目进行系统实现，同时相关成果和文档放入资源中心存档；

3.9 质量控制部对系统实现结果进行功能测试，若未通过，项目经理安排项目组成员修改系统实现；

3.10 若通过功能测试，质量控制部进行质量检验，若未通过，项目经理安排项目组成员修改系统实现；

3.11 若通过质检，专家委员会对系统实现进行验收，若未通过，项目经理安排项目组成员修改系统实现；

3.12 若通过专家委员会验收，项目经理将系统实现相关成果交给客户验收，若未通过，项目经理安排项目组成员修改系统实现；

3.13 若通过客户验收，质量控制部将相关成果和文档放入资源中心存档，同时项目经理安排项目组成果进行项目推广；

3.14 项目经理进行项目总结，通过在质量控制部进行质检，若未通过，项目经理修改项目总结；

3.15 若通过质检，质量控制部将相关成果和文档放入资源中心存档；

4 相关文件

4.1 《项目计划书》

4.2 《项目资源调度单》

4.3 《方案说明书》

4.4 《需求分析说明书》

4.5 《质量控制需求分析说明书评审报告》

4.6 《总体设计说明书》

4.7 《详细设计说明书》

4.8 系统实现相关文档——在系统实现流程中完成

4.9 《客户验收单》

4.10 《项目总结》

4.11 《软件质量保证文档》

4.12 《资源中心验收单》

项目计划书

项目名称 项目编号

项目经理

项目任务描述

项目总时间及关键里程碑设置

项目人力资源

项目费用预计

审批人意见：

总监： 副总监： 执委会：

备注：抄送财务部、人力资源部

时间

项目资源调度单

项目名称 项目编号 项目经理

项目的跨中心（部门）资源调度缘由

申请人

审批人

正式调用时间：

起：

止：

备注：抄送财务、人力资源部

时间

软件需求分析说明书

1. 引言

1.1 目的

说明编写软件需求说明书的目的，指出预期的读者。

1.2 背景

（1） 待开发的软件系统的名称；

（2） 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

（3） 该软件系统同其他系统或其他机构的基本的相互来往关系。

1.3 参考资料

列出所用的参考资料，如：

（1） 本项目的经核准的计划任务书或合同、上级机关的批文；

（2） 属于本项目的其他已发表的文件；

（3） 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。

（4） 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

1.4 术语

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

2. 项目概述

本部分描述影响产品和其需求的一般因素。此处并不说明具体的需求，其描述的内容仅仅是为了更容易理解、深化需求规格，其用意是为从多方面、多角度

考虑需求以提供思维参考点。

2.1 一般描述

本节描述软件开发项目的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料，解释待开发产品和其相关的其他产品或项目的关系。

 如果本产品是独立的，而且自含全部内容，应在此说明。

 如果所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容：

 要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口；

 指出本产品主要的外部接口（不需要详细描述，详细描述放在其他章节中）；

 描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。

【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。

【提醒注意】本节所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约束条件提供了一个可以解释的理由。

2.2

功能简述

对待的软件产品功能提供一个摘要。

【技巧】

 编制功能的一种方法是制作功能表，以便客户或第一次读这个文件的人很容易理解；

 用方框图来表达不同的功能和它们的关系有益于理解。

【提醒注意】

 方框图不是产品的设计，而只是一种有效的解释方式。

 本节不是具体需求的陈述，只是对具体需求部分中为什么要对一些需求做出描述的铺垫。

2.3 用户特点

本节描述产品最终用户（包括操作员、维护员和系统工作人员等）具有的受教育水平、工作经验及技术专长等一般特点。

如果系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。

2.4 假定和约束

给出影响软件需求说明书中陈述的需求的每一个因素。这些因素不是软件的设计约束，但是它们的改变可能影响到需求说明书中的需求。

这些假定和约束条件可能包括：管理方针；运行环境，包括硬件设备和支持软件的限制；与其他应用间的接口；并行操作；实时功能；审查功能；控制功能；所需的高级语言；通信协议；应用的临界点；安全保密方面的考虑等。

【提醒注意】

 本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。

 本节的内容不能用来陈述具体需求或强加若干特殊的设计约束，而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。

3. 具体需求

本章应包括软件开发者在建立设计时需要的全部细节。

本章的编写应该遵循如下基本原则：

 遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述；

 在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景；

 按符合逻辑的和可读的方式组织；

 详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。

【提醒注意】每一项需求的描述都应包括至少5个方面的内容：功能需求；性能需求；属性需求；外部接口需求；设计约束。

3.1 功能需求

用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成：

3.1.1 引言

（1） 描述该功能要达到的目标、所采用的方法和技术；

（2） 清楚说明功能意图的由来和背景。

3.1.2 输入

（1） 详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）。

（2） 操作员具体的操作控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整。

（3） 指明引用的输入接口资料。

3.1.3 处理

描述为获得预期输出结果，对输入数据及中间参数进行的全部操作。它包括如下的说明：

（1） 输入数据的有效性检查手段；

（2） 操作的顺序和处理过程，包括事件的时间设定；

（3） 异常情况的响应，例如：溢出、通信故障、错误处理等；

（4） 受操作影响的参数；

（5） 降级运行的要求；

（6） 用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）。

（7） 输出数据的有效性检查手段。

3.1.4 输出