软件项目开发的文档编写标准化

软件项目开发的文档编写标准化

　　在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 
　　◇ 可行性分析 告：说明该软件开发项目的实现在技术上、经济上和 会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 
　　◇ 项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 
　　◇ 软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 
　　◇ 概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 
　　◇ 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 
　　◇ 用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 
　　◇ 测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 
　　◇ 测试分析 告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 
　　◇ 开发进度月 ：该月 系软件人员按月向管理部门提交的项目进展情况 告， 告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 
　　◇ 项目开发总结 告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 
　　◇ 软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 
　　◇ 软件问题 告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 
　　◇ 软件修改 告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。

可行性分析 告

● 在规定的期限内，开发能否完成5 所建议系统经济可行性分析5.1 支出5.2 效益5.3 收益/投资比5.4 投资回收周期5.5 敏感性分析：指一些关键性因素，如： 
　　● 系统生存周期长短 
　　● 系统工作负荷量 
　　● 处理速度要求 
　　● 设备和软件配置变化对支出和效益的影响等的分析6 会因素可行性分析6.1 法律因素：如 
　　● 合同责任 
　　● 侵犯专利权 
　　● 侵犯版权6.2 用户使用可行性：如 
　　● 用户单位的行政管理 
　　● 工作制度 
　　● 人员素质等能否满足要求7 其他可供选择的方案 
　　逐个阐明其它可供选择的方案，并重点说明未被推荐的理由。

8 结论意见 
　　● 可着手组织开发 
　　● 需等待若干条件具备后才能开发 
　　● 需对开发目标进行某些修改 
　　● 不能进行或不必进行 
　　● 其它

项目开发计划

软件需求说明书

概要设计说明书

7 物理结构设计8 数据结构与程序的关系9 运行设计9.1 运行模块的组合9.2 运行控制9.3 运行时间10 出错处理设计10.1 出错输出信息10.2 出错处理对策：如设置后备、性能降级、恢复及再启动等。11 安全保密设计12 维护设计 
　　说明为方便维护工作的设施，如维护模块等。

详细设计说明书

1 引言1.1 编写目的：阐

用户操作手册

7 操作命令一览表 
　　按字母顺序逐个列出全部操作命令的格式、功能及参数说明。

8 程序文件（或命令文件）和数据文件一览表 
　　按文件名字母顺序或按功能与模块分类顺序逐个列出文件名称、标识符及说明。

9 用户操作举例

测试计划

2 任务概述2.1 目标2.2 运行环境2.3 需求概述2.4 条件与限制3 计划3.1 测试方案：说明测试方法和选取测试用例的原则。3.2 测试项目：列出组装测试和确认测试中每一项测试的内容、名称、目的和进度。3.3 测试准备3.4 测试机构及人员：测试机构名称、负责人和职责。4 测试项目说明4.1 按顺序逐个对测试项目做出说明4.1.1 测试项目名称及测试内容4.1.2 测试用例4.1.3 输入：输入的数据和输入命令。4.1.4 输出：预期的

输出数据。4.2 步骤及操作4.3 允许偏差：给出实测结果与预期结果之间允许偏差的范围。4.4 进度4.5 条件：给出项测试对资源的特殊要求，如设备、软件、人员等。4.6 测试资料：说明项测试所需的资料。5 评价5.1 范围：说明所完成的各项测试说明问题的范围及其局限性。5.2 准则：说明评论测试结果的准则。

测试分析 告

4 评价4.1 软件能力：经过测试所表明的软件能力。4.2 缺陷和限制：说明测试所揭露的软件缺陷和不足，以及可能给软件运行带来的影响。4.3 建议：提出为弥补上述缺陷的建议。4.4 测试结论：说明能否通过。

开发进度月

1 告时间及所处的开发阶段2 工程进度2.1 本月内的主要活动2.2 实际进展与计划比较3 所用工时 
　　按不同层次人员分别计时。

4 所用机时 
　　按所用计算机机型分别计时。

5 经费支出 
　　分类列出本月经费支出项目，给出支出总额，并与计划比较。

6 工作遇到的问题及采取的对策7 本月完成的成果8 下月的工作计划9 特殊问题

项目开发总结 告

软件维护手册

括它们的名称和版本 。3.3 数据库：说明每个数据库的性质和内容，包括安全考虑。3.3.1总体特征：如标识符、使用这些数据库的程序、静态数据、动态数据；数据库的存储媒体；程序使用数据库的限制。3.3.2结构及详细说明 
　　● 说明该数据库的结构，包括其中的记录和项。 
　　● 说明记录的组成，包括首部或控制段、记录体。 
　　● 说明每个记录结构的字段，包括：标记或标 、字段的字符长度和位数、该字段的允许值范围。 
　　● 扩充：说明为记录追加字段的规定。4 维护过程4.1 约定：列出该软件系统设计中所使用全部规则和约定，包括：程序、分程序、记录、字段和存储区的标识或标 助记符的使用规则；图表的处理标准、卡片的连接顺序、语句和记 中使用的缩写、出现在图表中的符 名；使用的软件技术标准；标准化的数据元素及其特征。4.2 验证过程：说明一个程序段修改后，对其进行验证的要求和过程（包括测试程序和数据）及程序周期性验证的过程。4.3 出错及纠正方法：列出出错状态及其纠正方法。4.4 专门维护过程：说明文档其他地方没有提到的专门维护过程。如：维护该软件系统的输入输出部分（如数据库）的要求、过程和验证方法；运行程序库维护系统所必需的要求、过程和验证方法；对闰年、世纪变更的所需要的临时性修改等。4.5 专用维护程序：列出维护软件系统使用的后备技术和专用程序（如文件恢复程序、淘汰过时文件的程序等）的目录，并加以说明，内容包括：维护作业的输入输出要求；输入的详细过程及在硬设备上建立、运行并完成维护作业的操作步骤。4.6 程序清单和流程图：引用或提供附录给出程序清单和流程图。

软件问题 告

1 登记  
　　由软件配置管理部门为该 告规定一个唯一的、顺序的编 。

2 登记日期 
　　软件配置管理部门登记该 告的日期。

3 问题发现日期 
　　发现该问题的日期和时间。

4 活动 
　　在哪个阶段发现的问题，分为单元测试、组装测试、确认测试和运行维护。

5 状态 
　　在软件配置记录中维护的动态指示，状态表示有：正在复查”软件问题 告”，以确定将采取什么行动；”软件问题 告”已由指定的人去进行处理；修改已完成，并经过测试，正准备交给主程序库；主程序库已经更新，主程序库修改的重新测试沿未完成；做了重新测试，问题再现；做了重新测试，所做的修改无故障，”软件问题 告”被关闭；留待以后关闭。6 告人 
　　填写”软件问题 告”人员的姓名、地址、电话。7 问题属于什么方面 
　　区分是程序的问题，还是模块的问题，或是数据库的问题，文件的问题。也可能是它们的某种组合。

8 模块/子系统 
　　出现的模块名。如果不知是哪个模块，可标出子系统名，尽量给出细节。

9 修订版本  
　　出现问题的模块版本。

10 磁带 
　　包含有问题的模块的主程序库的磁带的标识符。

11 数据库 
　　当发现问题时所使用数据库的标识符。

12 文件  
　　有错误的文件的编 。

13 测试用例 
　　发现错误时所使用测试用例的标识符。

14 硬件 
　　发现错误时所使用的计算机系统的标识。

15 问题描述/影响 
　　问题症兆的详细描述。如果可能，则写明实际问题所在。也要给出该问题对将来测试、接口软件和文件等的影响。

16 附注 
　　记载补充信息。

软件修改 告

1 登记  
　　由软件配置管理部门为该 告规定的编 。

5 子系统名 
　　受修改影响的子系统名。

6 模块名 
　　被修改的模块名。

7 “软件问题 告”的编  
　　被”软件修改 告”处理或部分处理的”软件问题 告”的编 。如果某”软件问题 告”的问题只是部分被处理，则在编 后附以p，如1234p。8 修改 
　　包括程序修改、文件更新、数据库修改或它们的组合。

9 修改描述 
　　修改的详细描述。如果是文件更新或数据库修改，还要列出文件更新通知或数据库修改申请的标识符。

10 批准人 
　　批准人签字，正式批准进行修改。

11 语句类型 
　　程序修改中涉及到的语句类型，包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存取语句类）。12 程序名 
　　被修改的程序、文件或数据库的名字。

13 老修订版 
　　当前的版本/修订本标识。14 新修订版 
　　修改后的版本/修订本标识。15 数据库 
　　如果申请数据库修改，则给出数据库的标识符。

16 数据库修改 告 
　　数据库修改申请 。

17 文件 
　　如果要求对文件进行修改，则给出文件的名字。

18 文件更新 
　　文件更新通知单的编 。

19 修改是否已测试 
　　指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否。

20 “软件问题 告”是否给

出问题的准确描述 
　　回答’是’或’否’。21 问题注释 
　　准确地叙述要维护的问题。

22 问题源 
　　指明问题来自于哪里，如软件需求说明书、设计说明书、数据库、源程序等。

23 资源 
　　完成修改所需资源的估计，即总的人时数和计算机时间的开销。