软件开发管理办法

1、1 目的和范围本管理总则规定本公司软件研制管理所遵循的原则和方法，目的是通过加强开发管理达到如下结果。1) 提高软件质量和每一个项目开发过程的可控性。2) 优化开发资源结构，提高工作效率。3) 优化公司软件管理使产品尽早实现一体化，结构化。4) 通过良好的管理规范和结构使参与人员养成良好的工作素质。5) 引导和组织员工向规范化管理看齐，以使公司尽早实现国际人证。本条例适用于质量管理组织、部门经理、项目经理等管理人员、系统分析员、系统设计和程序编码人。2 引用文件和术语l GB/T11457-1995软件工程术语。l GB/T 16260-1996 信息技术、软件产品评价、质量特性及其使用指南。

2、3 定义本篇术语尽量使用标准术语（GB/T11457-1995），另外还对本公司软件管理有如下术语说明：由公司管理领导小组负责批准软件开发项目的立项。由主管总经理、部门经理、质量管理员、项目经理、及有关的技术人员依据项目管理有关规定和各自的职能，协作完成。3.3 设计层由系统工程师以及系统分析员组成。3.4实施层由软件开发技术人员组成的编码调试队伍。 全开发型一个独立的软件开发项目；例如调度命令票的开发，用户提出的调度MIS系统的开发。 增加功能型在本公司现有某软件系统的基础上新增加一个独立的功能。3.7 功能完善型将本公司软件系统的已有功能完善。如调度MIS系统中的电网计算程序中添加图形示意

3、界面，以方便用户。3.8 查错测试型对本公司的软件系统某种不正常现象进行跟踪查错，找出错误根源。 3.9 个体软件过程（psp）是一种可以用于控制、管理和改进个人工作方式的自我改善过程，是一个软件过程框架。3.10 软件的可靠性请参看DB/T 16260-1996 “信息技术 软件产品评价 质量特性及其使用指南”附录A “质量子特性”3.11 软件的安全性请参看DB/T 16260-1996 “信息技术 软件产品评价 质量特性及其使用指南”附录A “质量子特性”。4软件开发方法4.1 软件开发的基本流程及软件开发类型的分析 软件开发的基本流程1) 软件开发的立项， 确定系统需求（目的及用途、功

4、能、技术指标、开发及交付时间）；2) 软件的需求调研3) 软件的需求分析；4) 软件开发的概要设计；5) 软件开发的详细设计；6) 软件的实施（编程和单元测试）；7) 软件的组装测试、总体案例测试、性能及验收；8) 软件的交付投运；9) 软件的维护。 不同开发类型的软件开发流程1） 全开发型必须经过所述全部流程；2） 增加功能型必须经过所述全部流程；3） 功能完善型需经过所述的1)，及3)9)；4） 查错测试型需要遵循错误处理规范（见附录z） 软件开发过程的控制1) 软件开发流程的1），2），3），4），5），6）阶段都应该经过质量管理小组和开发顾问组（可以包括用户或公司聘请的有关开发专家）的

5、评审。2) 评审分内部评审和正式评审。3) 内部评审由公司质量管理小组负责实施；正式评审由外部专家及公司的质量管理小组组成的评审委员会进行。除全开发型的软件验收需要正式评审外，全开发型的软件开发的其它阶段的评审及其它类型的软件开发的各个阶段的评审均采用内部评审。4) 评审前有关人员必须准备好该阶段的技术文档资料，并填写“评审报告”（附表G-1）的有关部分，一并上交公司的质量管理小组申请评审。5) 无论内部评审或正式评审，均由公司的质量管理小组指定评审人选与评审日期，最后由公司总经理批准，同时还要递交一份评审工作安排方案要求总经理批准。6) 评审时首先由有关人员介绍被评审的内容；演示评审内容，再

6、由评审小组测试评审内容，然后由评审小组提问题，有关人员答辩（需填写“软件评审问题记录”（附表G-2）；最后由评审小组给出“通过”和“不通过”的结论；若需要修改，应该填写“软件修改报告单”（内部评审可以适当简化评审程序，免去答辩过程）。7) 软件验收评审前需要填写“评审报告”进行申请外，软件评审要由评审小组或质量管理小组填写专门的软件评审报告（附表E）。软件开发项目的确立该阶段的规范依据公司相关的项目确立和项目下达的有关规定（项目的申请和确立规范）。4.3 软件需求分析该阶段只适用于所述的全开发型及增加功能型的软件开发项目。 目的任务及实施步骤 由软件开发的部门经理与有关的设计人员进行软件的需求

7、分析； 对于大的或全开发型的软件开发项目需要根据“软件开发项目任务书”进行必要的技术调查，写出系统调研报告，调研报告的书写和实施依据公司的系统调研报告实施规范； 分析和确定软件开发、运行的环境； 确定人机界面及接口说明； 编制项目开发计划，填写“软件开发项目安排书” (附表B_3)、“软件开发项目计划书”(附表B_4)； 编写“软件需求规格说明书（附录B）”； 评审； 下达设计任务。4.3.2 方法及工具 采用面向对象的分析方法（OOA）或结构化的分析方法。 若采用面向对象的分析方法（OOA）其标识方法和说明格式应参考“标准建模语言（UML）”的书写及文档格式。 若采用结构化的分析方法，请参考

8、附录B“软件需求规格说明书书写格式”。4.3.3 评审 根据“软件开发任务书”针对软件开发计划，软件需求规格说明进行评审。评审内容：s 是否符合“软件开发任务书”的要求；s 可行性：是否能按时，按质，交付符合系统需求的软件；s 标准化：其文档资料是否符合标准；s 可靠性，安全性和可维护性：其软件需求规格说明是否规定了可靠性，安全性和可维护性的要求； 评审应该作出通过或不通过的结论。可原则通过，但需作部分修改和补充，则需待概要设计评审时对修改或补充部分进行检查评审。4.3.4 设计任务下达 “软件需求规格说明书”、“软件开发项目计划书”和“软件开发项目安排书”经过公司总工程师的批准之后，连同“软

9、件开发项目任务书” 和“个人工作任务书”作为正式任务，下达给设计层人员；4.4 概要设计4.4.1 目的和任务和实施步骤 根据“软件需求规格说明书”中规定的软件功能需求，建立软件的总体结构和功能模块之间的关系，定义各功能模块的接口，设计数据库模式和数据结构，初步编制测试计划。 概要设计是软件开发必须执行的重要阶段（因为软件分析阶段对一些类型的软件开发可以不执行）。 其步骤为：总体结构设计：将整个软件系统分解为子系统、功能模块；粗略描述子系统和功能模块之间的数据及控制关系，及接口；数据库模式及数据结构的设计；各个功能模块的功能定义，接口定义；编制概要设计说明（参看附录C）； 初步编制测试计划（参

10、看附录G）。4.4.2阶段产品 概要设计说明书 软件测试计划（初步）.3 评审和批准4.4.3.1 评审由负责该软件开发的技术人员向软件开发技术领导小组申报。申报时应该填写 “软件评审报告”（附表G-1）以及提交所列的必需具备的文档资料”。 评审的内容: 根据“软件开发任务书”及“软件需求规格说明”针对软件概要设计进行评审。是否符合“软件开发任务书” 及“软件需求规格说明”的要求。可行性：是否能按时，按质，交付符合系统需求的软件。标准化：其文档资料是否符合标准。可靠性，安全性和可维护性：其概要设计是否考虑了“软件需求规格说明”中规定的可靠性，安全性和可维护性的要求 软件开发评审小组根据软件概要

11、设计必需具备的文档资料及答辩情况进行讨论，并作出评审意见(通过或不通过)。若有重大修改及评审不通过，应再次举行评审答辩；若有小的修改，需留待详细设计阶段一并进行评审。4.2 批准软件开发技术领导小组将评审意见及全部资料提交总经理进行最后审批。总经理将审批后，由软件开发人员继续进行软件的下阶段开发。45 详细设计4.5.1 目的及内容及步骤 详细设计必须符合概要设计说明的功能需求、框架结构、数据结构、数据流程的基本设计要求。 详细设计内容及步骤：。确定准确的数据结构（必须有准确详细的文字说明）； 。进行完整的数据库的模式设计（必须有准确详细的文字说明）； 。进行主程序的结构及过程的准确的描述（可

12、使用文字及类语言进行描述）； 。进行的准确的描述（输入参数，输出参数，功能描述）； 。进行全部子程序或服务的逻辑结构准确的描述（可使用文字及类语言进行描述）；。进行全部事件（输出事件及接收事件）的描述（事件名，事件体，输出事件何时发出，接受事件的处理流程）；。完成详细设计说明书的编写（参看附录D）； 。拟定子系统及功能模块的调试方案。 在软件详细设计过程中若发现框架设计需要修改，应提出修改方案并填写修改报告单。 阶段产品及文档资料 详细设计说明书； 如有修改，需要具备修改后的概要设计说明及修改报告单； 子系统及功能模块的测试计划。 评审； 对于中所述的全开发型及增加功能型的软件开发应该进行详细

13、设计的评审, 而其它两种类型的软件开发除非概要设计有重大修改一般不进行评审。 评审过程参看.1;4.6 软件实现 任务及实施步骤 根据软件详细设计说明，进行程序编制、静态分析、自测试、互测试。 阶段产品及文档资料 软件概要设计及详细设计文档资料及相应的修改报告单； 源程序； 自测试大纲及测试结果； 软件使用说明书和维护说明书初稿。程序编制的规范 变量名：必须与其代表的意义或其用途一致，可读(决不允许无实际意义的变量名，如a、b、c、I、j、k等)。 每个源程序(包括主程序及各个例程)的行数不得超过行。 每个源程序必须有程序头说明（程序名称，功能，上一级程序名，调用的子序名，输入参数，输出参数，

14、编制人，完成日期，修改的历史记录）。 每个源程序必须有注释行（平均行源程序有一行注释）。 软件的静态分析 该分析为使用人工或自动调试工具对程序代码逐条进行检查、分析，以发现编码错误的过程。其内容为； 检查代码和详细设计的一致性； 检查代码的标准性，可读性； 检查代码逻辑代码的正确性。软件的自测试和互测试 软件的自测试是在软件项目开发组内部进行的测试，以保证被开发的软件符合系统需求(功能需求及技术要求)，检查软件的容错能力，检查软件的可靠性及安全性；为软件的正式验收测试提供依据和基础。 软件开发项目自测试首先可以在比较独立的环境，进行该开发软件的各个软件模块的功能测试。 功能测试之后，必须将被开

15、发软件与整个软件系统组装到一起，在完整的运行环境下进行测试。 自测成功后，应该由技术部经理（或相应的软件开发部门经理）安排其他与该开发项目无关的技术人员按测试大纲进行互测； 自测试及互测试必须有测试大纲、测试用例及测试记录。 必须自测试及互测试成功之后，才允许提交正式的测试和验收。 目的及内容 根据“软件开发项目任务书”中规定的用户需求以及软件开发人员提交的“软件测试大纲”在相应的系统环境（该系统当前的正式版本）下对已经开发成功的软件进行严格测试。 审查软件产品必需具备的文档资料的规范性，完整性及正确性。 审查软件产品介质的正确性，完整性及一致性。 由软件评审小组对被审查的软件给予“审查评语”

16、，合格的系统进行版本注册登记。 软件验收的执行者 执行者为软件开发技术领导小组及其委托的软件评审小组( 软件正式验收的评审) 、软件质量管理小组（软件产品审查）及版本管理小组（版本注册，复制，发行）。软件验收的步骤及验收测试小组的组成.1 软件验收的步骤 由项目负责人填写“软件开发项目正式验收申请书”（ 附表E-1），交技术部汇总，由公司质量管理部进行审查，审查内容为： 。程序编制的规范性（如变量命名，程序头，程序注释）； 。测试大纲及自测试及互测试结果的正确性； 。软件使用说明书的完整性及规范性；。若软件实现过程进行了软件概要设计或详细设计的修改,则应该审查是否具备相应的修改后的设计文档；若

17、审查不通过；需要技术部（或相应软件开发部门）进行相应的修补工作；然后再进行审查，直至通过为止； 审查通过后，由公司总经理批准，然后开始启动软件验收过程。 由软件开发人员编写测试大纲的并经评审小组评审； 由公司软件质量管理小组委托专门的技术人员建立测试环境； 由公司软件质量管理小组委托专门的技术人员建立测试小组按照测试大纲进行严格的测试； 测试中若出现重大的错误，则此次软件测试宣告失败；应修改后再进行重新全部测试； 测试中若出现一般的错误，可经修改后，进行专项补测； 测试小组应该提交软件测试报告； 由公司软件质量管理小组委托专门的技术人员建立文档资料审查小组进行文档资料的审查，并提交审查报告；

18、由公司软件质量管理小组委托专门的技术人员建立介质审查小组进行软件介质的审查，并提交审查报告； 测试结束由公司软件质量管理小组组织软件评审小组经过认真评议作出“审查评语”。.2 软件验收测试小组的组成 软件验收阶段应该组织三个测试审查小组； 软件测试小组、软件文档资料审查小组、软件介质审查小组； 三个测试审查小组的人员主要由公司工程部技术人员组成 测试审查小组由公司公司软件质量管理小组与质管部负责组织4.7.4软件测试大纲的编制及审定 软件测试大纲由负责软件开发的人员编写； 评审小组召集会议，听取大纲编写人员的介绍以及与会者的意见，经过讨论，并经大纲编写人员的修改补充，最后由软件评审小组讨论审定

19、该测试大纲。.1软件测试大纲的内容详细的格式请参看附录H4.7.5 针对不同软件开发情况的测试要求.1系统基础级的测试 系统的支撑平台的基本服务被修改或全开发型的软件开发项目属于此种类型； 必须将该软件系统全部程序（支撑平台及应用软件）进行编译链接。 对新的或经过重大修改的软件系统统（必须有数据源的仿真环境）进行所有功能的测试。.2基本系统的测试 系统的支撑平台的部分软件被修改属于此种类型； 必须对该系统的有关部分（支撑平台软件）进行编译链接。 在当前被修改的软件系统的版本（必须有数据源的仿真环境）下对开发修改的部分及其它应用软件进行测试。.3应用系统的测试 系统的应用软件进行了重大修改或开发

20、了新的应用软件属于此种类型；必须对该应用软的有关部分进行编译链接。 在当前系统的版本（必须有数据源的仿真环境）下对开发修改的应用软件及其它有关应用软件进行测试。.4一般修改的测试 系统的应用软件进行了一般修改属于此种类型； 必须对有关部分进行编译链接。 在当前系统的版本（除去开发修改的部分）下对修改的应用软件进行测试。4.7.6 软件测试的一般性合格标准 符合该开发项目的“软件需求规格说明书”中规定的用户的功能需求及性能需求。 符合测试大纲中规定的各项功能。 新开发修改的项目的可靠性标准：。人机界面调用次不故障退出，不产生core dump或死机。支撑平台的分布式管理及数据库的基本服务连续访问

21、次不出错误，不产生core dump或死机。支撑平台的分布式管理及实时数据库的基本功能（如主备机自动切换，子系统的切换，子系统及进程的退出服务和启动，双以太网的自动切换；数据库的安装更新，数据库模式的建立和修改，数据库的同步，实时数据库与关系数据库的同步及捆绑；等等）连续调用次不发生错误，不产生core dump或死机。应用系统在支撑环境下（必须有前置机的仿真环境）连续运行72小时不发生功能性错误，不产生事件堆积，不故障退出, 不产生core dump或死机。软件文档资料.1文档资料应涵盖的范围 该软件开发项目的“软件开发任务书”、“软件需求规格说明”及对上述文档的修改资料； 该软件开发项目的

22、概要设计及详细设计的全部资料； 该软件开发项目的全部源程序； 该软件开发项目的自测试和互测试记录； 该软件开发项目的用户使用手册和维护手册； 该软件开发项目的测试大纲； 资料的详细清单。.2审查文档资料的手段 审查人员检查文档资料的规范性，完整性。 可以使用专门的软件去测试源程序的规范性。软件介质的审查.1软件介质的定义软件介质指的是完整的记录软件的可运行模块及其安装说明的磁带，软盘，光盘。4.7.8.2软件介质合格的标准 介质记录了软件系统全部可运行模块及其安装说明或记录软件系统的升级模块及其安装说明；用此介质安装之后，该软件系统可以立即可靠的运行。 该介质应该与提供的用户手册完全一致。 评

23、审 软件验收阶段需要经过两次评审； 第一次评审是对验测试收大纲的评审； 第二次评审是该验收阶段的最终评审；其评审内容为： 。软件测试报告 。软件文档资料的审查报告 。软件介质的审查报告 评审结果：通过或不通过。 软件的交付方式 将经过正式验收的软件由开发部或相应的软件开发部门交付质量管理部进行注册登记； 由质管部及开发部或相应的软件开发部门共同向工程部门交付经过正式验收的软件系统，以便工程部进行系统集成及进一步测试 软件交付后的完善 软件交付工程部门进行系统集成及测试后或进行工程的工厂验收和现场验收后若出现若干不符合用户需求的问题或错误，应该由工程部门填写“软件问题报告单”（针对软件错误和不符

24、合用户需求的问题），并交部门经理汇总；若问题可以由本部门解决，则在本部门安排解决；若本部门不能解决的问题，交公司技术领导小组统一安排软件的修改完善工作。 4.9 软件的维护及完善维护请求的提出 维护请求由工程部门以” 软件问题报告单”的形式提交并交部门经理汇总；若问题可以由本部门解决，则在本部门安排解决；若本部门不能解决的问题，交公司技术领导小组，统一安排解决。维护计划的形成 对于小的软件问题可以不经过评审,直接形成软件开发项目任务书下达给技术人员. 对于较大的软件问题应经过评审形成软件开发项目任务书然后下达给技术人员( 参考”软件开发项目的确立”). 维护的过程 对于”增加功能型”的维护,实

25、际是一个较为独立的软件开发项目,应该按的阶段进行软件的开发 对于”功能完善型”及”查错调试型”的维护, 实际是一个修改软件的过程,应该按以下步骤进行：。维护人员对维护需求进行分析，修改“软件需求规格说明”或“软件概要设计说明” 或“软件详细设计说明”，评审小组对其修改进行评审，然后维护人员根据评审意见进行再修改、再评审，直到通过。维护人员根据修改的设计进行源程序的代码修改及静态分析、自测试、互测试，软件验收。原则上，凡是对现场运行的软件的修改，均应该在实验室先进行模拟修改和测试；成功后，经过项目经理或部门经理批准后，再到现场进行修改；如因为特殊原因，在未经过实验室修改和测试，而对现场运行的软件

26、进行修改，应该事先及时与项目经理或部门经理联系，说明修改的内容及理由，经过同意后，再慎重的进行修改和测试；事后必须填写软件问题报告单及软件修改报告单或工程修改报告单，并经过项目经理或部门经理审查批准；。进行维护后，都应该及时经过质管部的注册登记调整软件版本号、保存相应的软件介质，以保证软件版本的一致性。附录A 软件立项报告书写格式北京思创公司软件开发项目立项报告 项目名称: 课题名称： 起止时间： 年 月至 年 月 年 月 日1 目的和意义1. 描述与软件开发内容紧密相关的产品的实际水平和今后的发展方向；2. 阐述课题成果对该现状和技术发展的作用；3. 分析成果应用和推广的途径；4. 分析成果

27、推广后的直接和间接效益。2 国内外研究水平综述1. 与软件开发内容紧密相关的技术发展历史的简要回顾；2. 国内外研究水平的现状和发展趋势；3. 介绍国外研究机构或者公司对本课题的研究情况；4. 介绍国内其他研究单位对本课题的研究情况。3课题的理论或实践依据1. 软件开发内容的原理简述；2. 软件开发内容的理论或者实践依据；3. 软件开发的技术关键和难点。1. 软件开发内容的详细说明（可分专题或按内容序号描述）。2. 要描述具体的开发步骤，现场试验的地点和试验计划，需要建设的试验环境；3. 理论研究和试验内容与软件开发总目标的因果关系；4. 写明理论和试验研究的工作量；5. 需要多家单位共同承担

28、的课题，需要写明各家的分工、职责和提供的成果，如何组织和协调；6. 需要与国外合作，要写明与外方的合作方式、知识产权和成果分享的范围，及以前的工作联系；7. 注明本软件开发需要购买设备的型号、产地、性能及需要购买的原因；8. 外委的工作内容和工作量；5预期目标和成果形式1. 阐明软件开发预期达到的目标；2. 明确叙述软件产品成果提供的形式；要求成果提供的形式能够被其他技术人员掌握，使成果的使用权具有可转移性。6试验单位或依托工程情况1. 如需借用其他单位的试验环境，说明选定试验单位的落实情况；2. 如需结合依托工程进行试点研究，说明依托工程及其与本软件开发结合的情况。7软件开发所需的条件对课题

29、负责人的要求；对课题承担人员的专业、特长、工作水平的要求；7.3验室条件（包括硬件和软件） 说明该软件开发所需的硬件及软件的环境,并开列清单;8 课题的进度安排1. 列出分年度计划研究内容和人员、设备安排；2. 分年度提供成果的内容和形式，要具有可检查性。序号时间段内 容123456789101112报告编写人：附录B软件需求规格说明书书写格式 1任务名称2任务来源3运行环境 以文字确切的说明该软件在何种环境下运行； 硬件环境：服务器/工作站/PC机/单板机； 软件环境：何种OS，何种数据库系统，以及其它支持软件； 工作环境：调度室/维护工作机房/管理人员办公室/变电站等； 使用人员：调度员/

30、维护人员/开发人员及相应的文化程度；4功能需求 详细的以文字和图/表描述该软件应该完成的功能；5技术性能要求 说明该软件应该具备的安全性、可靠性、实时响应性、可用性等具体要求；6功能模块描述 简要说明该软件的各个功能模块的功能，及与其它模块之间的关系；7接口描述 简要说明各个外部及内部接口的功能及输入参数和输出参数；8对人机交互的要求 说明该软件是否要求人机交互，以何种方式进行交互，交互欲达到的目的；并简要说明主要人机交互的过程；附录C 概要设计说明书书写格式1 概要设计说明书的框架1 用户需求2 术语3 数据结构及事件定义4 程序的框架结构5 各个程序模块的描述6 相关的人机界面的描述2 用

31、户需求的书写规范 参看附A。3 术语的书写规范 1）。专用术语 逐个列出该概要设计中所使用的专用术语的名称及确切含义； 2）。缩写词 逐个列出该概要设计中所使用的缩写词的名称及确切含义；4 数据结构及事件定义的书写规范 1）。数据库模式的描述l 该软件所使用的已经建立的数据库及表的名称；l 该软件需要新建立的数据库的模式的概要描述（数据库用途，数据库名、表名及用途、属性名）； 2）。内部主要数据结构的描述 程序内部需要使用的数据结构的名称、用途、包含的属性； 3）。新定义的事件的描述 说明新定义事件的名称及用途；5 程序的框架结构的书写规范 1)。程序的层次机构（树状结构）的描述 以文字和图描

32、述该程序的层次机构（树状结构）；结构中包含所有的程序单元（主程序及各层子程序及各个函数）及处理事件的程序模块； 2）。各个程序模块之间的逻辑关系描述 用图形（或类PASCAL语言）描述程序的概要逻辑关系（包括事件处理的源头）； 6 程序模块描述的书写规范 1）。程序模块的功能描述 以文字描述该程序的功能； 2）。程序模块的输入及输出描述 以文字描述该程序的输入参数（变量，数组，指针，常数）及相应的输出参数（变量，数组，指针，常数）；7 类（CLASS）描述的书写规范 1）。以文字描述该类（CLASS）的功能； 2）。以文字描述该类（CLASS）的继承关系； 3）。类（CLASS）的属性描述 以

33、文字描述该类（CLASS）的各个属性及其含义； 4）。类（CLASS）的函数的描述 以文字描述该类（CLASS）的各个函数的功能及输入输出参数8 人机界面描述的书写规范 1）。以文字或图形描述各个人机界面的功能 附录D 详细设计说明书书写格式1 详细设计说明书的框架1用户需求 2术语 3数据库模式设计 4内部数据结构设计 5事件的设计 6程序的框架结构（若已有概要设计则此节可省略，否则必须书写） 7程序模块的详细设计 8人机界面的详细设计3 用户需求的书写规范参看附A。3 术语的书写规范 1）。专用术语 逐个列出该详细设计中所使用的专用术语的名称及确切含义； 2）。缩写词 逐个列出该详细设计中

34、所使用的缩写词的名称及确切含义；4 数据库模式设计的书写规范详细描述新建立的数据库模式的结构;l 数据库名称及用途l 数据库各个表的名称及用途l 各个表的属性的名称、数据类型、含义5 内部数据结构的书写规范l 数据结构的名称及用途l 数据结构的属性的名称、数据类型、含义6 程序的框架结构的书写规范 1)。程序的层次机构（树状结构）的描述 以文字和图描述该程序的层次机构（树状结构）；结构中包含所有的程序单元（主程序及各层子程序及各个函数）及处理事件的程序模块； 2）。各个程序模块之间的逻辑关系描述 用图形（或类PASCAL语言）描述程序的概要逻辑关系（包括事件处理的源头）； 7 事件的设计 1）

35、。新定义的事件的结构描述 详细描述新定义的事件的名称、用途、事件体结构、事件体每个属性的数据类型及含义、在何种条件下发出； 2）。本程序注册的事件的描述l 描述本程序注册的事件的名称、由哪个程序或BOB发出的、该事件的事件体结构；l 对该事件的处理流程的描述：以文字或“类PASCAL语言”描述该处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该描述不加任何发挥的编写出程序； 8 程序模块设计的书写规范 1）。程序模块的功能描述 以文字描述该程序的功能； 2）。程序模块的输入及输出描述 以文字描述该程序的输入参数（变量，数组，指针，常数）及相应的输出参数； 3)。程序模块逻辑流程的详细

36、描述 以文字或“类PASCAL语言”描述该程序程序模块的处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该程序模块的详细描述不加任何发挥的编写出程序；9类(CLASS)设计的书写规范 1）。以文字描述该类（CLASS）的功能； 2）。以文字描述该类（CLASS）的继承关系； 3）。类（CLASS）的属性描述 以文字描述该类（CLASS）的各个属性的类型及其含义； 4）。类（CLASS）的函数的描述 以文字描述该类（CLASS）的各个函数的功能及输入输出参数； 以文字或“类PASCAL语言”描述各个函数的处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该函数的描述不加任何发挥

37、的编写出该函数的程序；10 人机界面设计的书写规范 1）。该人机界面的名称及用途 2）。用图形将实际使用的界面全部画出来；包括全部的菜单条、图象、符号、光敏点等； 3）。列出菜单条及光敏点对应的回调函数的名称及功能； 4）。详细描述各个回调函数的输入输出参数；并以文字或“类PASCAL语言”描述各个函数的处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该函数的描述不加任何发挥的编写出该函数的程序；附录E 软件产品用户使用手册格式书写格式1 本软件产品的功能概述简述本软件提供的各个功能,及实现这些功能的用户采用的手段；2 本手册的使用范围简述本手册是为哪些人员服务的?这些人员需要具备哪

38、些基本知识?3 术语和略缩语列举本手册使用的术语和略缩语；4. 使用过程4.1 软件的安装启动过程详细准确的说明该软件的安装和启动的过程；4.2 软件提供的各个功能的操作过程详细准确的说明该软件提供的各个功能实现的每一步操作；5. 错误信息 详细准确的列举各个错误信息的含义，何时发生？如何应对？附录F 软件产品用户维护手册书写格式1 软件产品的功能概述简述本软件提供的各个功能,及实现这些功能的用户采用的手段；2 本手册的使用范围简述本手册是为哪些人员服务的?这些人员需要具备哪些基本知识?3 术语和略缩语列举本手册使用的术语和略缩语；4 正常情况的维护操作详细准确的说明正常情况的各个维护操作的步

39、骤： 正常情况的维护操作包括： 软件的启动和停止； 软件的当前状态的查询； 软件运行状况的诊断；5 异常情况的维护操作详细准确的说明异常情况的各个维护操作的步骤；附录G 测试计划编写格式1被测试的软件开发项目名称2测试对象和目的l 说明测试的对象（被测试的主程序、子程序、接口、人机界面等）；l 说明该测试的目的： 详细说明测试哪些功能； 测试哪些性能（可靠性、安全性）及应该达到的指标；3测试所需要的环境l 详细说明该测试需要的硬件和软件环境；l 说明测试所需要的仿真环境；4测试的方法l 说明测试采取的方法（黑盒测试、白盒测试）；l5测试的步骤l 详细说明测试的步骤l 附录H 测试大纲的编写格式

40、第一章 概述1 前言概述该测试的目的、任务、环境、方法； 此次测试的目的； 界定此次测试的范围； 确定测试的环境；第二章 测试环境1. 硬件测试环境描述该测试所应具备的硬件环境；2. 软件测试环境描述该测试所应具备的软件环境；第三章 测试内容和测试记录该章应该包括： 测试的详细操作步骤； 测试的各个用例； 测试的合格的标准。因此应该： 分节分段的详细的列出各个子系统、功能模块的测试步骤、测试方法及用例和应该得出的结果；并留出记录测试结果及测试产生的偏差的表格；附表A-1“软件开发各阶段管理要点”阶段主要工作完成标志管理任务质量手段立项及系统需求定义1. 分析系统要求和使用环境2. 论证软件项目

41、可行性3. 拟定研制任务书1. 软件项目任务书1. 分析风险2. 确定重要技术指标3. 拟定质量保证大纲1. 评审软件需求分析1. 确定运行环境2. 确定功能，性能和接口要求，编写需求规格说明3. 确定项目开发计划1. 软件需求规格说明书2. 软件项目开发计划书3. 软件项目安排书4. 技术调查综述（对于大型项目应有充分的试验报告）1. 组织验证与评审2. 进行进度管理1. 评审概要设计1. 建立总体结构，设计类及服务2. 定义接口形成3. 测试计划1. 概要设计说明书1. 组织验证与审定2. 组织记录并报告问题1. 审定2. 规范性详细设计1. 设计详细算法和细节2. 确定详细接口信息1.

42、详细设计说明书软件实现1. 编写源程序2. 进行调试3. 研读源程序和单元测试4. 编写测试大纲5. 编写软件使用说明1. 源程序2. 测试大纲1. 组织验证与审评2. 组织记录并报告问题1. 审定2. 规范性软件实现单元1. 执行测试大纲规定的测试2. 完成软件使用说明1. 可以正确运行的程序和数据库2. 软件使用说明1. 加强测试2. 分析隐患3. 组织审评并报告问题4. 确定是否进行下一步测试1. 审定2. 规范3. 测试技术组装1. 遍历所有功能及进行破坏性测试2. 检查源程序及文档1. 测试大纲2. 问题记录书总体性能1. 按系统测试要求（运行环境，版本，现场模拟）测试2. 详细填写

43、问题记录1. 问题记录表2. 修改报告单（如果存在问题应填写此单）1. 分析并报告问题2. 组织问题追踪验收1. 编写验收测试大纲2. 验收测试3. 准备移交工作1. 软件开发项目验收书2. 软件测试大纲3. 软件工作个人任务书及验收书1. 组织测试大纲及验收评审2. 组织记录并报告问题1. 测试大纲评审2. 验收评审交付1. 向质管部交付有关文档及交付软件介质继续软件注册登记2. 确定软件的版本号；3. 向工程部移交软件1. 软件版本注册登记表2. 软件介质制作单1. 软件注册管理2. 软件移交管理1. 软件注册2. 版本管理运行维护1使用（经常主动与用户取得联系，追踪服务）2记录运行状态与

44、问题1软件问题记录表2 软件修改报告单3. 新版全套文档1分析并报告问题2 组织问题追踪3. 进行版本统一管理1经常进行模拟现场测试2售后服务保证体系3。版本更新管理附表A-2 软件开发表格及文档一览表名称填写时间填写负责人格式和内容软件开发项目建议书软件项目立项前工程部项目负责人或公司技术领导小组或公司任何技术人员附表B-1软件开发项目立报告软件项目立项前公司技术领导小组附录A软件开发项目任务书软件立项评审后技术领导小组附表B-2软件需求规格说明书软件需求分析阶段技术领导小组附录B软件开发项目计划书软件需求分析阶段技术部负责人及项目负责人附表B-3软件开发项目安排书软件需求分析阶段技术部负责

45、人及项目负责人附表B-4软件概要设计说明书软件概要设计阶段软件设计人员附录C软件测试计划软件概要设计阶段软件设计人员附录G软件详细设计说明书软件详细设计阶段软件设计人员附录D用户使用说明书软件实现阶段软件设计人员附录E用户维护说明书软件实现阶段软件设计人员附录F软件测试大纲软件实现阶段软件设计人员附录H软件工作个人任务书及验收书 软件项目验收前软件开发人员附表B-5软件评审报告评审时项目负责人及评审小组附表G-1软件评审问题记录评审时评审小组附表G-2软件评审成员签字登记表评审时评审小组附表G-3软件开发测试大纲软件验收时技术部及项目负责人附表 C软件开发项目测试问题记录软件验收时软件测试小组

46、附表 D软件开发项目验收书软件验收评审时评审小组附表 E软件问题报告单发现问题和建议修改时工程部及技术部技术人员附表F-1软件修改报告单修改软件时工程部及技术部技术人员附表 F-2软件版本注册登记表软件正式验收通过后进行注册是软件开发部门附表 H-2软件介质制造单制作软件介质软件开发部门附表 H-1附表B_1 软件开发项目建议书ZJ040701年 月 日 编号：项目名称建议人需求概述建议根据技术要点 很难 较难 一般 简单工作量估算需要完成日期年 月 日估算工作人日技术领导小组意见 签字附表B_2软/硬件开发任务书ZJ040703年 月 日 编号：项目（或工程）名称项目负责人（或项目经理）子项目名称子项目负责人签字初步参加人员数量参加人员姓名需求概述功能简述技术要点 很难 较难 一般 简单工作量总人日工作进度开始日期年