项目执行流程管理

1、程序文件项目执行流程年 月 日起生效文件号编制审核批准版次1.0日期日期日期共6页第1页项目执行流程1 目的及适用范围1.1 为规范项目业务中项目执行过程，达到项目的成本、进度、质量的统一，特制定本程序；1.1 本程序文件适用于某公司项目业务中项目执行；1.2 本程序文件由某公司制定，其解释权及修改权属于；1.3 本程序文件从年 月日起执行；2 职责2.1 项目中心负责项目执行的总体进程，并对执行的最终结果负责；22主管副总和执委会负责在关键节点监控和协调资源；2.3 质量控制部负责对项目执行过程中的里程碑产生的相关成果和文档进行质量控 制，并将符合规范的成果放入资源中心存档；3 定期战略质询

2、流程3.1 决策委员会同意签订合同后，项目部项目经理（在项目销售流程中的准项目经理）制订项目计划书，交由执委会审批，如果未通过，项目经理重新修改项目计划书；3.2 如果审批认可，项目经理将项目计划递交给客户评审，若未通过，项目经理修改项目计划书3.3 若客户评审通过，进行项目资源安排，若所需资源在项目中心本身内，由项目总监完成资源安排，若所需资源跨项目中心外的多个部门，由执委会完成资源安排;3.4 获得所需资源后，项目经理进行需求分析，交质量控制部进行质量检验，若质检 未通过，项目经理修改需求分析；3.5 若质检通过，专家委员会对需求分析内容进行评审，若未通过，项目经理修改需 求分析内容；3.

3、6 若通过内容评审，项目经理将需求分析交给客户评审，若未通过，项目经理修改 需求分析，若通过，项目经理进行总体设计，同时将相关成果和文档放入资源中 心存档；3.7 质量控制部对总体设计进行质量检验，若未通过，项目经理修改总体设计，若通 过，专家委员会对总体设计内容进行评审，若未通过内容评审，项目经理修改总 体设计内容，3.8 若通过内容评审，项目经理将总体设计交给客户评审，若未通过客户评审，项目 经理修改总体设计，若通过客户评审，项目经理安排项目进行系统实现，同时相 关成果和文档放入资源中心存档；3.9 质量控制部对系统实现结果进行功能测试，若未通过，项目经理安排项目组成员 修改系统实现；3.

4、10 若通过功能测试，质量控制部进行质量检验，若未通过，项目经理安排项目组成 员修改系统实现；3.11 若通过质检，专家委员会对系统实现进行验收，若未通过，项目经理安排项目组 成员修改系统实现；3.12 若通过专家委员会验收， 项目经理将系统实现相关成果交给客户验收， 若未通过， 项目经理安排项目组成员修改系统实现；3.13 若通过客户验收，质量控制部将相关成果和文档放入资源中心存档，同时项目经 理安排项目组成果进行项目推广；3.14 项目经理进行项目总结，通过在质量控制部进行质检，若未通过，项目经理修改 项目总结；3.15 若通过质检，质量控制部将相关成果和文档放入资源中心存档；4 相关文件

5、4.1 项目计划书4.2 项目资源调度单4.3 方案说明书4.4 需求分析说明书4.5 质量控制需求分析说明书评审报告4.6 总体设计说明书4.7 详细设计说明书4.8 系统实现相关文档一一在系统实现流程中完成4.9 客户验收单4.10 项目总结4.11软件质量保证文档4.12资源中心验收单项目计划书项目名称项目编号项目经理项目任务描述项目总时间及关键里程碑设置项目人力资源项目费用预计审批人意见：总监：副总监：执委会:备注：抄送财务部、人力资源部时间项目资源调度单项目名称项目编号项目经理项目的跨中心（部门）资源调度缘由申请人审批人正式调用时间:起：止：备注：抄送财务、人力资源部时间软件需求分析

6、说明书1. 引言1.1目的说明编写软件需求说明书的目的，指出预期的读者。1.2背景(1) 待开发的软件系统的名称；(2) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;(3) 该软件系统同其他系统或其他机构的基本的相互来往关系。1.3参考资料列出所用的参考资料，如：(1) 本项目的经核准的计划任务书或合同、上级机关的批文；(2) 属于本项目的其他已发表的文件；(3) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。(4) 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些 文件资料的来源。1.4术语列出本文件中用到的专门术语的定义和外文首字母

7、组词的原词组。2. 项目概述本部分描述影响产品和其需求的一般因素。此处并不说明具体的需求，其描述的内容仅仅是为了更容易理解、深化需求规格，其用意是为从多方面、多角度考虑需求以提供思维参 考点。2.1 一般描述本节描述软件开发项目的意图、应用目标、作用范围以及其他应向读者说明的有关该软 件开发的背景材料，解释待开发产品和其相关的其他产品或项目的关系。如果本产品是独立的，而且自含全部内容，应在此说明。如果所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容：要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口； 指出本产品主要的外部接口(不需要详细描述，详细描述放在

8、其他章节中) 描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部 接口是非常有帮助的。【提醒注意】本节所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约 束条件提供了一个可以解释的理由。2.2功能简述对待的软件产品功能提供一个摘要。【技巧】编制功能的一种方法是制作功能表，以便客户或第一次读这个文件的人很容易理解; 用方框图来表达不同的功能和它们的关系有益于理解。【提醒注意】方框图不是产品的设计，而只是一种有效的解释方式。本节不是具体需求的陈述，只是对具体需求部分中为什

9、么要对一些需求做岀描述的铺垫。2.3用户特点本节描述产品最终用户（包括操作员、维护员和系统工作人员等）具有的受教育水平、 工作经验及技术专长等一般特点。如果系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。2.4假定和约束给出影响软件需求说明书中陈述的需求的每一个因素。这些因素不是软件的设计约束， 但是它们的改变可能影响到需求说明书中的需求。这些假定和约束条件可能包括：管理方针；运行环境，包括硬件设备和支持软件的限制;与其他应用间的接口；并行操作；实时功能；审查功能；控制功能；所需的高级语言；通信 协议；

10、应用的临界点；安全保密方面的考虑等。【提醒注意】本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将 造成影响。本节的内容不能用来陈述具体需求或强加若干特殊的设计约束，而应对具体需求部分中的某些具体需 求或设计约束的描述提供理由。3. 具体需求本章应包括软件开发者在建立设计时需要的全部细节。本章的编写应该遵循如下基本原则：遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述；在软件需求说明书前言、项目概述、附录部分的有关讨论中， 要提供对任何一个具体需求交叉引用的背景；按符合逻辑的和可读的方式组织；详细描述每一个需求，使得该需求应达到的目标能够用指定的

11、方法进行客观的验 证。【提醒注意】每一项需求的描述都应包括至少5个方面的内容：功能需求；性能需求；属性需求；外部接口需求；设计约束。3.1功能需求用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成：3.1.1引言(1)(2)描述该功能要达到的目标、所米用的方法和技术； 清楚说明功能意图的由来和背景。3.1.2输入(1)详细描述该功能的所有输入数据，如：输入源、数量、度量单位、 效输入范围（包括精度和公差）。时间设定、有(2)操作员具体的操作控制细节的需求。其中有名字、操作

12、员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整。(3)指明引用的输入接口资料。3.1.3处理描述为获得预期输出结果，对输入数据及中间参数进行的全部操作。它包括如下的说明(1)输入数据的有效性检查手段；(2)操作的顺序和处理过程，包括事件的时间设定；(3)异常情况的响应，例如：溢出、通信故障、错误处理等；(4)受操作影响的参数；(5)降级运行的要求；(6)用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）(7)输出数据的有效性检查手段。3.1.4输出（1）详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、 有效输出的范围（

13、包括精度和公差）、非法值的处理、出错信息；（2）指明引用的输出接口资料。【技巧】可以用列表的方式（例如 IPO表即输入、处理、输岀表的形式），逐项定量和定性地叙述对软件所 提岀的功能要求。【提醒注意】对着重于输入输岀行为的系统来说，需求说明书应指定所有有意义的输入、输岀对及其序列。 当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态做岀响应。这种 情况犹如有限状态机。3.2性能需求从整体来说，本节应具体说明软件、或人与软件交互的静态或动态数值需求。静态数值需求可能包括： 支持的终端数，支持并行操作的用户数， 处理的文卷和记录数， 表和文卷的大小等。动态数值需求可能包

14、括：欲处理的事务和任务的数量，以及在正常情况下和峰值工作 条件下一定时间周期中处理的数据总量等。所有这些需求都必须用可以度量的术语来叙述。例如：95%勺事务必须在小于 1s时间内处理完，不然，操作员将不等待处理的完成。精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。时间特性要求说明对于该软件的时间特性要求，如对响应时间、更新处理时间、数据的转换和传送时间、解题时间等的要求。灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限 的变化、计划的变化或改进等。对于为了提

15、供这些灵活性而进行的专门设计的部分应该加以标明。3.3软件属性需求在软件的需求之中有若干个属性，下面列举一部分。【提醒注意】下列属性决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。3.3.1 正确性3.3.2健壮性3.3.3安全保密性这里指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这 个领域的具体需求必须包括：利用可靠的密码技术， 掌握特定的记录或历史数据集，给不同的模块分配不同的功能，限定一个程序中某些区域的通信，计算临界值的检查等。3.3.4易使用性3.3.5可理解性3.3.6可维护性这里规定若干需求以确保软件是可维护的。例如：软件模块所需要的

16、特殊的耦合矩阵， 为微型装置指定特殊的数据 /程序分割要求等。3.3.7可测试性3.3.8可移植性这里规定把软件从一种环境移植到另一种环境所要求的用户程序、用户接口兼容方面的约束等。3.4外部接口需求3.4.1用户接口（1）提供用户使用软件产品时的界面需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：对屏幕格式的要求，报表或菜单的页面显示格式和 内容，用户命令的格式，输入输出的相对时间，程序功能键的可用性。(2) 列出输出错误信息的格式。342硬件接口(1) 指出软件产品与系统硬部件之间每一个接口的逻辑特点。(2) 指出硬件接口支持的设备。(3) 描述软件与硬件接口之间以及硬

17、件接口与支持设备之间的约定。3.4.3软件接口描述项目待开发软件产品与其它有关软件的接口关系，并指出这些软件的以下内容：名字、助记符、规格说明号、版本号、来源。【提醒注意】对于每一个接口，应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，这里不 必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。344通讯接口说明各种通信接口及协议，例如局部网络的协议等。3.5设计约束3.5.1其它标准的约束描述由现有的标准或规则派生的要求。例如：报表格式、数据命名、财务处理、审计追 踪等等。3.5.2硬件设备的约束描述在各种硬件约束下运行而产生的软件要求，可能的约束有硬件配置

18、的特点(接口数、指令系统等)，内存储器和辅助存储器的容量等。3.6数据需求【提醒注意】此部分内容一般在数据要求说明书中进行描述，如果项目软件产品规模较小，系统复杂程度较低,数据需求较简单，也可在此章中描述。此部分内容也可能在功能需求中予以说明3.6.1数据描述(1) 列出作为控制和引用而使用的静态数据元素(2) 列出动态输入数据元素(3) 列出动态输出数据元素4) 列出软件内部生成的数据元素3.6.2数据获取(1) 列出提供输入数据的机构2)列出数据输入介质和设备(3) 列出数据输出介质和设备3.7其它专门需求根据软件和用户组织的特性等，某些需求在这里描述，下面列举一部分。【提醒注意】下列需求

19、项决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。361数据库本项对作为项目产品的一部分进行开发的数据库规定一些需求，它们可能包括:(1)在功能需求中标识的信息类别;(2)使用的频率(3)存取能力；(4)数据兀素和文卷描述符；(5)数据兀素、记录和文卷的关系;(6)静态和动态的组织；(7)数据保存要求。【提醒注意】如果使用一个现有的数据库包，这个数据库包应在“软件接口”中命名，并在那里详细说明。362数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。3.6.3操作这里说明用户组织之中各种方式的操作。例如:（1）

20、用户初操作；（2）交互作用操作的周期和无人操作周期；（3）数据处理支持功能；4） 后援和恢复操作。【提醒注意】这里的内容有时是“用户接口”的一部分3.6.4故障处理4. 运行环境规定4.1设备列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：（1）处理器型号及内存容量；（2）外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；（3）输入及输出设备的型号和数量，联机或脱机；（4）数据通信设备的型号和数量；（5）功能键及其他专用硬件。4.2支持软件列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。4.3 接口说明该软件同其它软硬件之间的接口、数据通信协

21、议等。4.4控制说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。【提醒注意】本章中的内容有时在前面的章节中已说明。5. 支持信息支持信息指目录表、索引和附录。目录表和索引很重要，而且应按照可以接受的文件规则来编写。 对一个实际的需求说明书来说，如有必要应该编写附录。附录中可能包括：(1) 输入输出格式样本，成本分析研究的描述或用户调查结果；(2) 有助于理解需求说明书的背景信息；(3) 软件所解决问题的描述；(4) 用户历史、背景、经历和操作特点；(5) 交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善；(6) 特殊的装配指令用于编码和媒体，以满足安全、输出、初始

22、装入或其他要求。 当包括附录时，需求说明书必须明确地说明附录是不是需求要考虑的部分。总体设计说明书6. 引言1.5目的说明编写概要设计说明书的目的，指出预期的读者。1.6背景(4) 待开发的软件系统的名称；(5) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;(6) 该软件系统同其他系统或其他机构的基本的相互来往关系。1.7参考资料列出所用的参考资料，如：(5) 本项目的经核准的计划任务书或合同、上级机关的批文；(6) 属于本项目的其他已发表的文件；(7) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。(8) 列出这些文件资料的标题、文件编号、发表日期和出版单

23、位，说明能够得到这些 文件资料的来源。1.8术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。7总体设计2.2需求规定简要说明对本系统的主要的输入输出项目、处理的功能与性能等的要求。2.3运行环境简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定。2.4基本设计概念和处理流程说明本系统的基本设计概念和处理流程，尽量使用图表的形式。2.5结构用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划 分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。2.6功能需求与程序的关系用如下的矩阵图说明各项功能需求的实现同各块程序的分

24、配关系：程序1程序2程序m功能需求1V功能需求2V功能需求nVV2.7人工处理过程说明在本软件系统的工作过程中不得不包含的人工处理过程。2.8尚未解决的问题说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。8. 接口设计3.1用户接口说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。3.2外部接口本系统与各支持软件说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、之间的接口关系。3.3内部接口说明本系统之内的各个系统元素之间的接口的安排。9. 运行设计4.1运行模块组合说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每时每种运行所

25、历经的内部模块和支持软件。4.2运行控制说明每一种外界的运行控制的方式方法和操作步骤。4.3运行时间说明每种运行模块组合将占用各种资源的时间。10. 系统数据结构设计5.1逻辑结构设计要点给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、 文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。5.2物理结构设计要点给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。5.3数据结构与程序的关系说明各个数据结构与访问这些数据结构的各个程序之间的对应关系，可采用如下的矩阵图的形式：

26、程序1程序2程序m数据结构1V数据结构2V数据结构nVV11. 系统出错处理设计6.1 出错信息用一览表的方式说明每种可能的出错或故障情况出现时， 系统输出信息的形式、 含意及 处理方法。6.2 补救措施说明故障出现后可能采取的变通措施，包括：（ 1） 后备技术革新：说明准备采用的后备技术，当原始系统数据万一丢失时启用的副 本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘 媒体的一种后备技术；（ 2） 降效技术：说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得 所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人 工记录；（ 3） 恢复及再启

27、动技术：说明将使用的恢复再启动技术，使软件从故障点恢复执行或 使软件从头开始重新运行的方法。6.3 系统维护设计说明为了系统维护的方便而在程序内部设计中做出的安排， 包括在程序中专门安排用于 系统的检查与维护的检测点和专用模块。详细设计说明书12. 引言1.9 目的说明编写详细设计说明书的目的，指出预期的读者。1.10 背景7) 待开发的软件系统的名称；8) 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；9) 该软件系统同其他系统或其他机构的基本的相互来往关系。1.11 参考资料列出所用的参考资料，如：9) 本项目的经核准的计划任务书或合同、上级机关的批文；10) 属于本

28、项目的其他已发表的文件；11) 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。12) 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些 文件资料的来源。1.12 术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。13. 软件系统的结构用一系列图表列出本软件系统内的每个程序 (包括每个模块和子程序) 的名称、 标识符 和它们之间层次结构关系。14. 模块n设计说明(n是模块序号)从本章开始， 将概要设计产生的功能模块进行细化， 形成若干个可编程的程序单元， 逐 个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。 对于一个具体的模

29、块， 尤其是层次比较低的模块或在这种情子程序， 其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同， 况下，只要简单地说明这一点即可。3.1 程序描述给出对该程序的简要描述， 主要说明安排设计本程序的目的意义， 并且还要说明本程序 的特点（如是常驻内存还是非常驻内存；是否子程序；是可重入的还是不可重入的；有无覆 盖要求；是顺序处理还是并发处理；）。3.2 功能说明该程序单元应具有的功能，可采用 IPO 图（即输入输出图）的形式。3.3 性能说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。3.4 结构用图表的形式给出程序单元的结构。3.5 程序逻辑用框图或过程性描述语

30、言的形式表示各程序单元的控制流程。3.6 输入项给出对每一个输入项的特性， 包括名称、 标识、 数据的类型和格式、 数据值的有效范围、 输入的方式、数量和频度、输入媒体、输入数据的来源和安全保密条件等等。3.7 输出项给出对每时每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效 范围、输出的形式、数量和频度、 输出媒体、对输出图形及符号的说明、 安全保密条件等等。3.8 算法详细说明本程序单元所选用的算法，具体的计算公式和计算步骤。3.9 接口用图表的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式。，用图表描述数据结构与模3.10 数

31、据结构 说明与本程序相直接关联的数据结构（数据库、数据文卷） 块的关系。3.11 存储分配和数组分配确定每个模块的存储量及数组定义。3.12 单元说明说明程序单元标识、调用方式、参数说明。3.13 注释设计说明准备在本程序中安排的注释，如：（ 1） 加在模块首部的注释；（ 2） 加在各分枝点处的注释；（ 3） 对各变量的功能、范围、缺省条件等所加的注释；（ 4） 对使用的逻辑所加的注释等等。3.14 限制条件说明本程序运行中所受到的限制条件。3.15 尚未解决的问题说明在程序单元的设计中尚未解决而设计者认为在软件完成之前应解决的问题。项目总结项目编号:部门名称:目录1. 引言2. 项目开发结果

32、2.1 软件产品或软件项目2.2 主要功能和性能2.3 项目规模总结2.4 项目人员总结2.5 进度及工作量总结3. 项目评价3.1 生产效率评价3.2 技术方法评价3.3 产品质量评价3.4 出错原因分析4. 经验和教训1.引言说明实际参加人员、时间及工作划分：说明参加本项目的负责人、参加人员、起止时间及 实际工作量。按项目开发的阶段划分，细划每位开发人员在各开发阶段所用开发时间及实 际工作量。负责人：起止时间：计划工作量：项目情况阶段参加人员工作内容起止时间实际工作量需求分析A B等等 等等系统设计编码测试其它合计2. 项目开发结果2.1 软件产品或软件项目2.1.1软件产品或软件项目名称

33、：给出该软件项目或软件产品在项目任务书或开发计划评 审等文件中确定的正式的项目名称和项目编号；并给出该软件项目或软件产品正式 批准发布的版本标识。2.1.2程序量：按模块进行划分，给出该软件项目或软件产品的源程序的存贮容量。源代码用代码行来表示，可执行程序及其他程序可用字节来表示，文档可用页或字节来 表示。（源代码一定要按模块来统计）模块名称代码行（千行）字节数（KB源码模块1模块2执行程序等等注：源码不填写“字节数”，执行程序只填写“字节数”2.1.3存储介质：给出该软件项目或软件产品正式发布版本的存储介质及所需存储介质及 其数量。2.2 主要功能和性能1 ）描述该软件项目或软件产品所实现的

34、功能，根据需要说明该软件项目或软件产品的有关性能指标。2 ）与最初的需求相比较，给出功能和/或性能上的差异并说明原因。2.3 项目规模总结根据软件开发的各阶段，总结该软件项目或软件产品完成的功能模块数量与计划的 对比，给出对比图表，并对比较结果进行分析。阶段计划模块数完成模块数需求分析系统设计编码测试合计2.4 项目人员总结总结该软件项目或软件产品开发各阶段人员的变化情况与计划的对比，并对比较结果进行分析。阶段计划人数实际人数增加人数减少人数变动人数需求分析系统设计编码测试总计注：变动人数为人员更换数。匚计划人数 实际人数 变动人数2.5 进度及工作量总结总结该软件项目或软件产品实际完成所用的

35、时间及工作量与原计划的对比。用图表来表示。2.5.1从开发人员的角度进行总结：将每位开发人员开发该软件项目或软件产品起止时间 和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。开发人员计划时间实际时间是否按时计划M实际MABCD等等匸计划M口实际M2.5.2从模块的角度进行总结：将每一模块完成的起止时间和工作量与计划进行比较，给 出对比图表，并对比较结果进行分析。模块名称计划时间实际时间是否按时计划M实际M模块1模块2模块3模块4总计Tl计划M 卜实际M2.5.3从开发阶段的角度进行总结：将每一阶段完成的起止时间和工作量与计划进行比较,给出对比图表，并对比较结果进行分析阶段计划时间实

36、际时间是否按时计划M实际M需求分析系统设计编码测试总计计划M 实际M2.5.4从工作量的角度进行总结：将开发该软件项目或软件产品所用工作量与计划进行比 较，给出由于软件问题报告所增加的工作量，给出对比图表，并对比较结果进行分 析。批复工作量头际工作量计划增加小计2.5.5从完成情况进行总结：将项目的总体进度和阶段进度与计划进行比较，说明此项目 是正常完成、正常但增加工作量、延期但不增加工作量、即延期又增加工作量，并 对比较结果进行分析。计划时间实际时间批复工作量实际工作量结论注：以最后一版的开发计划中的开发进度为准， 批复工作量包括由于软件问题报告增加的工作量。3. 项目评价3.1 生产率评价

37、评价生产率可以有两种方法：代码行数与人月数比较，或修改BUG数与所用人月数的比较。我们可以采用任何一种。如果采用第一种方法，应以模块为单位进行比较； 如果采用第二种方法，应以各测试版本的 BUG数、修改的BUG数、修改BUG所用的 工作量及修改单位BUG所用的工作量进行比较，总结评价项目的开发效率及相应的 原因分析。模块名称代码行（千行）工作量代码行/工作量模块1模块2等等3.2技术方法评价总结该软件项目或软件产品开发时所采用的各项技术。3.3产品质量评价可参考以下几个方面进行产品质量的评价。1）历次测试发现的BUG数;2）同种原因产生的BUG数;3）同种类型的BUG数;4）各等级的BUG数;

38、5）同一 BUG出现的次数。3.4出错原因分析分别对以上几种情况绘制图表，进行原因的分析次数BUG数原因BUG数类型BUG数等级BUG数BUGS次数4. 经验和教训可以从以下几方面总结开发中获得的经验及纠正错误或缺陷等问题的教训1）管理人员的管理水平；2）开发人员的合理分工；3）项目软件经理PSM及开发人员的技术水平；4）开发人员的更换；5）开发人员的配合及协作；6）用户的密切配合；7）需求及设计的更改；8）开发过程中计划的合理调整等等。（项目名称）SQA计划计划编号： SQAL 日期： 版本： SQAM 日期：分册：PM/SM :日期：1. 质量目标质量目标，尽可能用测试的条款表达。2. S

39、QA 织2.1 SQA组的组成SQA的成员及资格说明（经验与培训）22 SQA职责和权力2.3 SQA组的资源需求3. SQA任 务3.1规程与标准明确项目标准和规程，作为SQA评审和审计的基础。3.2明确质量活动的责任如检查、审计和测试，配置管理和变更控制，测量和报告，缺陷控制和纠正措施。3.3阶段划分与任务列表SQA为每个开发阶段定义入口和出口条件，划分SQA的工作阶段，确定评审与审计的类型，明确作业，可依据项目特点对作业列表进行裁剪与增添。3.4测试与评估确定测试的类型，对于产品规范、计划要求、测试规范及采用的开发方法和工具的确认和验证活 动；通过详细的测试和验证活动计划，对包括资源、进

40、度和审批等方面进行评估。3.5全程的偏差跟踪根据任务列表进行全程偏差跟踪。4. SQA报告4.1文档化SQA组的活动结果软件产品评价报告软件工具评价报告项目设备评价报告过程审核报告测量报告4.2提供给软件工程组和其他相关组SQA活动反馈的方法和频率周报、月报与重要报告等提交的方式与日程（可在计划表中体现）5. 计划进度表与预算表序 号任务完成时间提交结果备注12345预算：SQA作业列表（发布日期）SQA方向任务作业项审核与检验质量目标质量策划质量目标，尽可能用测试的条款表达质量标准与规程的确立工具和设备评估丄具和设 备的管理软件工具设备配套的产品与设备软件过程评估软件产品 评审过程评审的标准

41、，依据程序文件的要求或在质 量计划与 SDP中明确评估项曰计划和监督过程项目计划的建立与监控执行评估系统需求 分析过程保证通过需求疋义和配置过程来确疋用户的 所有的需求保证需求被评审，以确疋它是切实可行的， 描述清楚的和一致的保证分配需求，工作产品和活动的变化都被 确定，评审，跟踪到结束项目参与者受到必要的培训保证分配需求的约定是同被影响的组协商有 同意的验证约定文档化，被传达，被评审和被接受保证潜在需求受到评审，被文档化，并在分 配需求中作出必要的变化验证定义，文档化和分配需求的过程被执行 和文档化确认CM过程受控和管理基准验证需求文档化，被管理，受控，和被跟踪验证同意的需求在SDP中给予记录评估系统设计 过程保证生存周期文档和可跟踪距阵准备好并是 最新的和一致的验证相关的生存周期文档是更新的并基于批 准的需求变化识别缺陷，保证已发现的缺陷被解决，和变 更控制完整性选择性的评审和审计系统设计文档确定不符合标准的项，并确定矫正措施决定需求，设计和工具符合标准和是否放弃 进一步的软件开发评审实例原型满足需求和标准保证实例符合标准和规程评审设计的里程碑状态评估软件需求 分析过程保证需求定义和分析过程及相关的需求评审 符合标准和规程保证需求分析引起的行动条款符合标准和规 程评估软件设计 过程保证软件设计过程和相关的设计评审符合标