项目执行流程程序文件.doc

《项目执行流程程序文件.doc》由会员分享，可在线阅读，更多相关《项目执行流程程序文件.doc（52页珍藏版）》请在三一办公上搜索。

1、1 目的及适用范围1.1 为规范项目业务中项目执行过程，达到项目的成本、进度、质量的统一，特制定本程序；1.1 本程序文件适用于侏罗纪公司项目业务中项目执行；1.2 本程序文件由侏罗纪公司 制定，其解释权及修改权属于 ；1.3 本程序文件从2003年 月 日起执行；2 】职责2.1 项目中心负责项目执行的总体进程，并对执行的最终结果负责；2.2 项目中心（副）总监和执委会负责在关键节点监控和协调资源；2.3 质量控制部负责对项目执行过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；3 定期战略质询流程3.1 决策委员会同意签订合同后，项目部项目经理（在项目销售

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

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

4、组成员修改系统实现；3.11 若通过功能测试，质量控制部进行质量检验，若未通过，项目经理安排项目组成员修改系统实现；3.12 若通过质检，专家委员会对系统实现进行验收，若未通过，项目经理安排项目组成员修改系统实现；3.13 若通过专家委员会验收，项目经理将系统实现相关成果交给客户验收，若未通过，项目经理安排项目组成员修改系统实现；3.14 若通过客户验收，质量控制部将相关成果和文档放入资源中心存档，同时项目经理安排项目组成果进行项目推广；3.15 项目经理进行项目总结，交给专家委员会进行评审，若未通过，项目经理修改项目总结；3.16 若通过评审，质量控制部将相关成果和文档放入资源中心存档；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 质量控制系统设计报告评审记录4.13 系统实现相关文档（略）4.14 系统测试总结报告4.15 软件缺陷报告4.16 评审规程4.17 客户验收单4.18 项目总结 项目计划书项目名称项目编号项目经理项目任务描述项目总时间及关键里程碑设置项目人力资源项目费用

6、预计审批人意见：总监： 副总监： 执委会：备注：抄送财务部、人力资源部时间项目启动计划评审记录记录编号： 时间： 年 月 日项目编号：项目名称：项目启动计划编号：开发部门：PM：评审地点：参加评审人员:评审内容(评审中审议通过的内容在“”中划“”否则划“”)：1) 项目的目的是否明确？ 2) 对项目的规模是否进行估算？ 3) 是否进行项目启动的预算？ 4) 阶段输出结果是否明确？ 5) 其它方面评审意见：评审结论：填表：审批：1. 项目启动计划评审由项目管理部门组织评审。2. 评审完成后由开发体系决策层SMG批准。3. 本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附

7、页。第 页/共 页开发计划评审记录记录编号： 时间： 年 月 日项目编号：项目名称：项目计划编号：开发部门：PSM：评审地点：参加评审人员:评审内容：评审意见：评审结论：填表：审批：1. 开发计划评审由项目管理部门组织评审。2. 评审完成后由开发体系决策层SMG批准。3. 本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。第 页/共 页开发计划检查表（开发计划评审附页）软件问题报告记录编号： - 时间： 年 月 日项目编号：项目名称：软件项编号：软件项名称：版本号：问题描述：报告人签字/日期:修改描述（主要是修改后与修改前的对比，如所用资源的变化、提交时间的变化、功

8、能的变化等）：修改人签字/日期：填写：审批：1.问题描述栏中可以填写问题现象及其产生原因，如果有用户的书面说明，则可以直接引用。2.修改描述一栏描述问题的确切原因、修改办法以及修改后的效果。3.本页不足记述时，可以有附页，格式自定。总页数包括本页与所有附页。综合评审记录（公司）评审对象（项目名称及编号）评审项类（如合同、投标方案等）评审人时间业务板块(产品中心、项目中心、服务中心、营销中心)评审意见财务部评审意见质量控制部评审意见技术委员会评审意见专家委员会评审意见最终意见：通过修改修改内容时间项目资源调度单项目名称项目编号项目经理项目的跨中心（部门）资源调度缘由申请人审批人正式调用时间：起：

9、止：备注：抄送财务、人力资源部时间软件需求分析说明书1. 引言1.1 目的说明编写软件需求说明书的目的，指出预期的读者。1.2 背景（1） 待开发的软件系统的名称；（2） 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；（3） 该软件系统同其他系统或其他机构的基本的相互来往关系。1.3 参考资料列出所用的参考资料，如：（1） 本项目的经核准的计划任务书或合同、上级机关的批文；（2） 属于本项目的其他已发表的文件；（3） 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。（4） 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。1.

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

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

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

13、间的接口；并行操作；实时功能；审查功能；控制功能；所需的高级语言；通信协议；应用的临界点；安全保密方面的考虑等。【提醒注意】u 本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。u 本节的内容不能用来陈述具体需求或强加若干特殊的设计约束，而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。3. 具体需求本章应包括软件开发者在建立设计时需要的全部细节。本章的编写应该遵循如下基本原则：l 遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述；l 在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景

14、；l 按符合逻辑的和可读的方式组织；l 详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。【提醒注意】每一项需求的描述都应包括至少5个方面的内容：功能需求；性能需求；属性需求；外部接口需求；设计约束。3.1 功能需求用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成：3.1.1 引言（1） 描述该功能要达到的目标、所采用的方法和技术；（2） 清楚说明功能意图的由来和背景。3.1.2 输入（1） 详细描述该功能的所有输入数据，如：输入源、数量、度量单

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

16、效性检查手段。3.1.4 输出（1） 详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；（2） 指明引用的输出接口资料。【技巧】可以用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求。【提醒注意】对着重于输入输出行为的系统来说，需求说明书应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态做出响应。这种情况犹如有限状态机。3.2 性能需求从整体来说，本节应具体说明软件、或人与软件交互的静态或动态数值需求

17、。静态数值需求可能包括：支持的终端数，支持并行操作的用户数，处理的文卷和记录数，表和文卷的大小等。动态数值需求可能包括：欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量等。所有这些需求都必须用可以度量的术语来叙述。例如：95%的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。u 精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。u 时间特性要求说明对于该软件的时间特性要求，如对响应时间、更新处理时间、数据的转换和传送时间、解题时间等的要求。u 灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适

18、应能力，如：操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、计划的变化或改进等。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3.3 软件属性需求在软件的需求之中有若干个属性，下面列举一部分。【提醒注意】下列属性决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。3.3.1 正确性3.3.2 健壮性3.3.3 安全保密性这里指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括：利用可靠的密码技术，掌握特定的记录或历史数据集，给不同的模块分配不同的功能，限定一个程序中某些区域的通信，计算临界

19、值的检查等。3.3.4 易使用性3.3.5 可理解性3.3.6 可维护性这里规定若干需求以确保软件是可维护的。例如：软件模块所需要的特殊的耦合矩阵，为微型装置指定特殊的数据/程序分割要求等。3.3.7 可测试性3.3.8 可移植性这里规定把软件从一种环境移植到另一种环境所要求的用户程序、用户接口兼容方面的约束等。3.4 外部接口需求3.4.1 用户接口（1） 提供用户使用软件产品时的界面需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：对屏幕格式的要求，报表或菜单的页面显示格式和内容，用户命令的格式，输入输出的相对时间，程序功能键的可用性。（2） 列出输出错误信息的格式。3.

20、4.2 硬件接口（1） 指出软件产品与系统硬部件之间每一个接口的逻辑特点。（2） 指出硬件接口支持的设备。（3） 描述软件与硬件接口之间以及硬件接口与支持设备之间的约定。3.4.3 软件接口描述项目待开发软件产品与其它有关软件的接口关系，并指出这些软件的以下内容：名字、助记符、规格说明号、版本号、来源。【提醒注意】对于每一个接口，应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，这里不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。3.4.4 通讯接口说明各种通信接口及协议，例如局部网络的协议等。3.5 设计约束3.5.1 其它标准的约束描述由现有的标准或规

21、则派生的要求。例如：报表格式、数据命名、财务处理、审计追踪等等。3.5.2 硬件设备的约束描述在各种硬件约束下运行而产生的软件要求，可能的约束有硬件配置的特点（接口数、指令系统等），内存储器和辅助存储器的容量等。3.6 数据需求【提醒注意】u 此部分内容一般在数据要求说明书中进行描述，如果项目软件产品规模较小，系统复杂程度较低，数据需求较简单，也可在此章中描述。u 此部分内容也可能在功能需求中予以说明。3.6.1 数据描述（1） 列出作为控制和引用而使用的静态数据元素（2） 列出动态输入数据元素（3） 列出动态输出数据元素（4） 列出软件内部生成的数据元素3.6.2 数据获取（1） 列出提供输

22、入数据的机构（2） 列出数据输入介质和设备（3） 列出数据输出介质和设备3.7 其它专门需求根据软件和用户组织的特性等，某些需求在这里描述，下面列举一部分。【提醒注意】下列需求项决不能理解为是一个标准的或完整的清单，而应根据项目实际情况予以列举。3.6.1 数据库本项对作为项目产品的一部分进行开发的数据库规定一些需求，它们可能包括：（1） 在功能需求中标识的信息类别；（2） 使用的频率（3） 存取能力；（4） 数据元素和文卷描述符；（5） 数据元素、记录和文卷的关系；（6） 静态和动态的组织；（7） 数据保存要求。【提醒注意】如果使用一个现有的数据库包，这个数据库包应在“软件接口”中命名，并在

23、那里详细说明。3.6.2 数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。3.6.3 操作这里说明用户组织之中各种方式的操作。例如：（1） 用户初操作；（2） 交互作用操作的周期和无人操作周期；（3） 数据处理支持功能；（4） 后援和恢复操作。【提醒注意】这里的内容有时是“用户接口”的一部分。3.6.4 故障处理4. 运行环境规定4.1 设备列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：（1） 处理器型号及内存容量；（2） 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；（3） 输入及输出设备的型

24、号和数量，联机或脱机； （4） 数据通信设备的型号和数量；（5） 功能键及其他专用硬件。4.2 支持软件列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。4.3 接口说明该软件同其它软硬件之间的接口、数据通信协议等。4.4 控制说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。【提醒注意】本章中的内容有时在前面的章节中已说明。5. 支持信息支持信息指目录表、索引和附录。l 目录表和索引很重要，而且应按照可以接受的文件规则来编写。l 对一个实际的需求说明书来说，如有必要应该编写附录。附录中可能包括：(1) 输入输出格式样本，成本分析研究的描述或用户调查结果；(

25、2) 有助于理解需求说明书的背景信息；(3) 软件所解决问题的描述；(4) 用户历史、背景、经历和操作特点；(5) 交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善；(6) 特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。当包括附录时，需求说明书必须明确地说明附录是不是需求要考虑的部分。总体设计说明书6. 引言1.5 目的说明编写概要设计说明书的目的，指出预期的读者。1.6 背景（4） 待开发的软件系统的名称；（5） 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；（6） 该软件系统同其他系统或其他机构的基本的相互来往关系。1.7 参考资料

26、列出所用的参考资料，如：（5） 本项目的经核准的计划任务书或合同、上级机关的批文；（6） 属于本项目的其他已发表的文件；（7） 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。（8） 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。1.8 术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。7. 总体设计2.2 需求规定简要说明对本系统的主要的输入输出项目、处理的功能与性能等的要求。2.3 运行环境简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定。2.4 基本设计概念和处理流程说明本系统的基本设计概念和处理流程，尽量使用图表

27、的形式。2.5 结构用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。2.6 功能需求与程序的关系用如下的矩阵图说明各项功能需求的实现同各块程序的分配关系： 程序1 程序2 程序m 功能需求1 功能需求2 功能需求n 2.7 人工处理过程说明在本软件系统的工作过程中不得不包含的人工处理过程。2.8 尚未解决的问题说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。8. 接口设计3.1 用户接口说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。3.2 外部接

28、口说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。3.3 内部接口说明本系统之内的各个系统元素之间的接口的安排。9. 运行设计4.1 运行模块组合说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每时每种运行所历经的内部模块和支持软件。4.2 运行控制说明每一种外界的运行控制的方式方法和操作步骤。4.3 运行时间说明每种运行模块组合将占用各种资源的时间。10. 系统数据结构设计5.1 逻辑结构设计要点给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互

29、关系。5.2 物理结构设计要点给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。5.3 数据结构与程序的关系说明各个数据结构与访问这些数据结构的各个程序之间的对应关系，可采用如下的矩阵图的形式： 程序1 程序2 程序m 数据结构1 数据结构2 数据结构n 11. 系统出错处理设计6.1 出错信息用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。6.2 补救措施说明故障出现后可能采取的变通措施，包括：（1） 后备技术革新：说明准备采用的后备技术，当原始系统数据万一丢失时启用

30、的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；（2） 降效技术：说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；（3） 恢复及再启动技术：说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。6.3 系统维护设计说明为了系统维护的方便而在程序内部设计中做出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。详细设计说明书12. 引言1.9 目的说明编写详细设计说明书的目的，指出预期的读者。1.10 背景（7） 待开

31、发的软件系统的名称；（8） 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；（9） 该软件系统同其他系统或其他机构的基本的相互来往关系。1.11 参考资料列出所用的参考资料，如：（9） 本项目的经核准的计划任务书或合同、上级机关的批文；（10） 属于本项目的其他已发表的文件；（11） 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。（12） 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。1.12 术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。13. 软件系统的结构用一系列图表列出本软件系统内的每个程序（包括每

32、个模块和子程序）的名称、标识符和它们之间层次结构关系。14. 模块n设计说明（n是模块序号）从本章开始，将概要设计产生的功能模块进行细化，形成若干个可编程的程序单元，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。3.1 程序描述给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且还要说明本程序的特点（如是常驻内存还是非常驻内存；是否子程序；是可重入的还是不可重入的；有无覆盖要求；是顺序处理还是并发处理；

33、）。3.2 功能说明该程序单元应具有的功能，可采用IPO图（即输入输出图）的形式。3.3 性能 说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。3.4 结构用图表的形式给出程序单元的结构。3.5 程序逻辑用框图或过程性描述语言的形式表示各程序单元的控制流程。3.6 输入项给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式、数量和频度、输入媒体、输入数据的来源和安全保密条件等等。3.7 输出项给出对每时每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围、输出的形式、数量和频度、输出媒体、对输出图形及符号的说明、安全保密条件

34、等等。3.8 算法详细说明本程序单元所选用的算法，具体的计算公式和计算步骤。3.9 接口用图表的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式。3.10 数据结构说明与本程序相直接关联的数据结构（数据库、数据文卷），用图表描述数据结构与模块的关系。3.11 存储分配和数组分配确定每个模块的存储量及数组定义。3.12 单元说明说明程序单元标识、调用方式、参数说明。3.13 注释设计说明准备在本程序中安排的注释，如：（1） 加在模块首部的注释；（2） 加在各分枝点处的注释；（3） 对各变量的功能、范围、缺省条件等所加的注释；（4） 对使用的逻辑所加的注释

35、等等。3.14 限制条件说明本程序运行中所受到的限制条件。3.15 尚未解决的问题说明在程序单元的设计中尚未解决而设计者认为在软件完成之前应解决的问题。项目总结项目编号： 项目类项：产品研发/项目/数据服务/组件开发/等 部门名称： 目录1. 引言 2. 项目开发结果 2.1软件产品或软件项目 2.2主要功能和性能2.3项目规模总结2.4项目人员总结2.5进度及工作量总结3. 项目评价3.1生产效率评价3.2技术方法评价3.3产品质量评价3.4出错原因分析4. 经验和教训1. 引言说明实际参加人员、时间及工作划分：说明参加本项目的负责人、参加人员、起止时间及实际工作量。按项目开发的阶段划分，细

36、划每位开发人员在各开发阶段所用开发时间及实际工作量。负责人：起止时间：计划工作量：项目情况阶段参加人员工作内容起止时间实际工作量需求分析A、B等等系统设计编码测试其它合计2. 项目开发结果2.1 软件产品或软件项目2.1.1软件产品或软件项目名称：给出该软件项目或软件产品在项目任务书或开发计划评审等文件中确定的正式的项目名称和项目编号；并给出该软件项目或软件产品正式批准发布的版本标识。2.1.2 程序量：按模块进行划分，给出该软件项目或软件产品的源程序的存贮容量。源代码用代码行来表示，可执行程序及其他程序可用字节来表示，文档可用页或字节来表示。（源代码一定要按模块来统计） 模块名称代码行（千行

37、）字节数（KB）源码模块1模块2执行程序等等 注：源码不填写“字节数”，执行程序只填写“字节数”。2.1.3 存储介质：给出该软件项目或软件产品正式发布版本的存储介质及所需存储介质及 其数量。2.2 主要功能和性能 1）描述该软件项目或软件产品所实现的功能，根据需要说明该软件项目或软件产品的有关性能指标。 2）与最初的需求相比较，给出功能和/或性能上的差异并说明原因。2.3 项目规模总结根据软件开发的各阶段，总结该软件项目或软件产品完成的功能模块数量与计划的对比，给出对比图表，并对比较结果进行分析。阶段计划模块数完成模块数需求分析系统设计编码测试合计2.4 项目人员总结总结该软件项目或软件产品

38、开发各阶段人员的变化情况与计划的对比，并对比较结果进行分析。阶段计划人数实际人数增加人数减少人数变动人数需求分析系统设计编码测试总计注：变动人数为人员更换数。2.5 进度及工作量总结 总结该软件项目或软件产品实际完成所用的时间及工作量与原计划的对比。用图表来表示。 2.5.1 从开发人员的角度进行总结：将每位开发人员开发该软件项目或软件产品起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。 开发人员计划时间实际时间是否按时计划M实际MABCD等等2.5.2 从模块的角度进行总结：将每一模块完成的起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。模块名称计划时

39、间实际时间是否按时计划M实际M模块1模块2模块3模块4总计2.5.3 从开发阶段的角度进行总结：将每一阶段完成的起止时间和工作量与计划进行比较，给出对比图表，并对比较结果进行分析。阶段计划时间实际时间是否按时计划M实际M需求分析系统设计编码测试总计2.5.4 从工作量的角度进行总结：将开发该软件项目或软件产品所用工作量与计划进行比较，给出由于软件问题报告所增加的工作量，给出对比图表，并对比较结果进行分析。批复工作量实际工作量计划增加小计2.5.5 从完成情况进行总结：将项目的总体进度和阶段进度与计划进行比较，说明此项目是正常完成、正常但增加工作量、延期但不增加工作量、即延期又增加工作量，并对比

40、较结果进行分析。计划时间实际时间批复工作量实际工作量结论 注：以最后一版的开发计划中的开发进度为准，批复工作量包括由于软件问题报告增加的工作量。3. 项目评价3.1 生产率评价 评价生产率可以有两种方法：代码行数与人月数比较，或修改BUG数与所用人月数的比较。我们可以采用任何一种。如果采用第一种方法，应以模块为单位进行比较；如果采用第二种方法，应以各测试版本的BUG数、修改的BUG数、修改BUG所用的工作量及修改单位BUG所用的工作量进行比较，总结评价项目的开发效率及相应的原因分析。模块名称代码行（千行）工作量代码行/工作量模块1模块2等等3.2 技术方法评价 总结该软件项目或软件产品开发时所采用的各项技术。3.3 产品质量评价可参考以下几个方面进行产品质量的评价。1） 历次测试发现的BUG数；2） 同种原因产生的BUG数；3） 同种类型的BUG数；4） 各等级的BUG数；5） 同一BUG出现的次数。3.4 出错原因分析分别对以上几种情况绘制图表，进行原因的分析。次数BUG数原因BUG数类型BUG数等级BUG数BUG名次数4. 经验和教训可以从以下几方面总结开发中获得的经验及纠正错误或缺陷等问题的