在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。

        在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。

  ◇ 可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。

  ◇ 项目开发计划:为软件项目实施方案制订出具体计划应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。

  ◇ 软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。 
  ◇ 概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。

  ◇ 详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。

  ◇ 用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。

  ◇ 测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

  ◇ 测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。

  ◇ 开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

  ◇ 项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。

  ◇ 软件维护手册:主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明,便于软件的维护。

  ◇ 软件问题报告:指出软件问题的登记情况,如日期、发现人、状态、问题所属模块等,为软件修改提供准备文档。

  ◇ 软件修改报告:软件产品投入运行以后,发现了需对其进行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影响作出详细的描述,提交审批。

可行性分析报告

1 引言 
1.1 编写目的:阐明编写可行性研究报告的目的,提出读者对象。 
1.2 项目背景:应包括 
  ● 所建议开发软件的名称 
  ● 项目的任务提出者、开发者、用户及实现软件的单位 
  ● 项目与其他软件或其他系统的关系。 
1.3 定义:列出文档中用到的专门术语的定义和缩写词的原文。 
1.4 参考资料:列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括 
  ● 项目经核准的计划任务书、合同或上级机关的批文 
  ● 与项目有关的已发表的资料 
  ● 文档中所引用的资料,所采用的软件标准或规范 
2 可行性研究的前提 
2.1 要求:列出并说明建议开发软件的的基本要求,如 
  ● 功能 
  ● 性能 
  ● 输入/输出 
  ● 基本的数据流程和处理流程 
  ● 安全与保密要求 
  ● 与软件相关的其他系统 
  ● 完成日期 
2.2 目标:可包括 
  ● 人力与设备费用的节省 
  ● 处理速度的提高 
  ● 控制精度或生产力的提高 
  ● 管理信息服务的改进 
  ● 决策系统的改进 
  ● 人员工作效率的提高 
2.3 条件、假定和限制:可包括 
  ● 建议开发软件运行的最短寿命 
  ● 进行显然方案选择比较的期限 
  ● 经费来源和使用限制 
  ● 法律和政策方面的限制 
  ● 硬件、软件、运行环境和开发环境的条件和限制 
  ● 可利用的信息和资源 
  ● 建议开发软件投入使用的最迟时间 
2.4 可行性研究方法 
2.5 决定可行性的主要因素 
3 对现有系统的分析 
3.1 处理流程和数据流程 
3.2 工作负荷 
3.3 费用支出:如人力、设备、空间、支持性服务、材料等项开支 
3.4 人员:列出所需人员的专业技术类别和数量 
3.5 设备 
3.6 局限性:说明现有系统存在的问题以及为什么需要开发新的系统 
4 所建议技术可行性分析 
4.1 对系统的简要描述 
4.2 与现有系统比较的优越性 
4.3 处理流程和数据流程 
4.4 采用建议系统可能带来的影响 
  ● 对设备的影响 
  ● 对现有软件的影响 
  ● 对用户的影响 
  ● 对系统运行的影响 
  ● 对开发环境的影响 
  ● 对经费支出的影响 
4.5 技术可行性评价:包括 
  ● 在限制条件下,功能目的是否达到 
  ● 利用现有技术,功能目的是否达到 
  ● 对开发人员数量和质量的要求,并说明能否满足 
  ● 在规定的期限内,开发能否完成 
5 所建议系统经济可行性分析 
5.1 支出 
5.2 效益 
5.3 收益/投资比 
5.4 投资回收周期 
5.5 敏感性分析:指一些关键性因素,如: 
  ● 系统生存周期长短 
  ● 系统工作负荷量 
  ● 处理速度要求 
  ● 设备和软件配置变化对支出和效益的影响等的分析 
6 社会因素可行性分析 
6.1 法律因素:如 
  ● 合同责任 
  ● 侵犯专利权 
  ● 侵犯版权 
6.2 用户使用可行性:如 
  ● 用户单位的行政管理 
  ● 工作制度 
  ● 人员素质等能否满足要求 
7 其他可供选择的方案 
  逐个阐明其它可供选择的方案,并重点说明未被推荐的理由。 
8 结论意见 
  ● 可着手组织开发 
  ● 需等待若干条件具备后才能开发 
  ● 需对开发目标进行某些修改 
  ● 不能进行或不必进行 
  ● 其它

项目开发计划

1 引言 
1.1 编写目的:阐明编写可行性研究报告的目的,提出读者对象 
1.2 项目背景:应包括 
  ● 项目的委托单位、开发单位和主管部门; 
  ● 该软件系统与其他系统的关系。 
1.3 定义:列出文档中用到的专门术语的定义和缩写词的原文 
1.4 参考资料:可包括: 
  ● 项目经核准的计划任务书、合同或上级机关的批文 
  ● 文档所引用的资料、规范等 
  ● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源; 
2 项目概述 
2.1 工作内容:简要说明项目的各项主要工作,介绍所开发软件的功能、性能等;若不编写可行性研究报告;则应在本节给出较详细的介绍; 
2.2 条件与限制: 阐明为完成项目应具备的条件、开发单位已具备的条件以及尚需创造的条件。必要时还应说明用户及分合同承担的工作、完成期限及其他条件与限制。 
2.3 产品 
2.3.1程序:列出应交付的程序名称、使用的语言及存储形式。 
2.3.2文档:列出应交付的文档。 
2.4 运行环境:应包括硬件环境、软件环境。 
2.5 服务:阐明开发单位可向用户提供的服务。如人员培训、安装、保修、维护和其他运行支持。 
2.6 验收标准 
3 实施计划 
3.1 任务分解:任务的划分及各项任务的负责人。 
3.2 进度:按阶段完成的项目,用图表说明开始时间、完成时间。 
3.3 预算 
3.4 关键问题:说明可能影响项目的关键问题,如设备条件、技术难点或其他风险因素,并说明对策。 
4 人员组织及分工 
5 交付期限 
6 专题计划要点 
  如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。

软件需求说明书

1 引言 
1.1 编写目的:阐明编写需求说明书的目的,指明读者对象。 
1.2 项目背景:应包括 
  ● 项目的委托单位、开心单位和主管部门; 
  ● 该软件系统与其他系统的关系。 
1.3 定义:列出文档中所用到的专门术语的定义和缩写词的愿文。 
1.4 参考资料:可包括 
  ● 项目经核准的计划任务书、合同或上级机关的批文 
  ● 文档所引用的资料、规范等 
  ● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源 
2 任务概述 
2.1 目标 
2.2 运行环境 
2.3 条件与限制 
3 数据描述 
3.1 表态数据 
3.2 动态数据:包括输入数据和输出数据。 
3.3 数据库描述:给出使用数据库的名称和类型。 
3.4 数据词典 
3.5 数据采集 
4 功能需求 
4.1功能划分 
4.2功能描述 
5 性能需求 
5.1 数据精确度 
5.2 时间特性:如响应时间、更新处理时间、数据转换与传输时间、运行时间等。 
5.3 适应性:在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时,应具有的适应能力。 
6 运行需求 
6.1 用户界面:如屏幕格式、报表格式、菜单格式、输入输出时间等。 
6.2 硬件接口 
6.3 软件接口 
6.4 故障处理 
7 其他需求 
  如可使用性、安全保密、可维护性、可移植性等。

概要设计说明书

1 引言 
1.1 写目的:阐明编写概要设计说明书的目的,指明读者对象。 
1.2 项目背景:应包括 
  ● 项目的委托单位、开发单位和主管部门 
  ● 该软件系统与其他系统的关系。 
1.3 定义:列出本文档中所用到的专门术语的定义和缩写词的愿意。 
1.4 参考资料: 
  ● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源 
  ●项目经核准的计划任务书、合同或上级机关的批文;项目开发计划;需求规格说明书;测试计划(初稿);用户操作手册 
  ● 文档所引用的资料、采用的标准或规范。 
2 任务概述 
2.1 目标 
2.2 需求概述 
2.3 条件与限制 
3 总体设计 
3.2 总体结构和模块外部设计 
3.3 功能分配:表明各项功能与程序结构的关系。 
4 接口设计 
4.1 外部接口:包括用户界面、软件接口与硬件接口。 
4.2 内部接口:模块之间的接口。 
5 数据结构设计 
6 逻辑结构设计 
  所有文档的统一封面格式如下页所示。 
7 物理结构设计 
8 数据结构与程序的关系 
9 运行设计 
9.1 运行模块的组合 
9.2 运行控制 
9.3 运行时间 
10 出错处理设计 
10.1 出错输出信息 
10.2 出错处理对策:如设置后备、性能降级、恢复及再启动等。 
11 安全保密设计 
12 维护设计 
  说明为方便维护工作的设施,如维护模块等。

详细设计说明书

1 引言 
1.1 编写目的:阐明编写详细设计说明书的目的,指明读者对象。 
1.2 项目背景:应包括项目的来源和主管部门等。 
1.3 定义:列出本文档中所用到的专门术语的定义和缩写词的愿意。 
1.4 参考资料: 
  ● 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源 
  ●项目经核准的计划任务书、合同或上级机关的批文;项目开发计划;需求规格说明书;概要设计说明书;测试计划(初稿);用户操作手册 
  ● 文档所引用的资料、软件开发的标准或规范。 
2 总体设计 
2.1 需求概述 
2.2 软件结构:如给出软件系统的结构图。 
3 程序描述 
3.1 逐个模块给出以下说明: 
  ● 功能 
  ● 性能 
  ● 输入项目 
  ● 输出项目 
3.2 算法:模块所选用的算法。 
3.3 程序逻辑:详细描述模块实现的算法,可采用:标准流程图;PDL语言;N-S图;判定表等描述算法的图表。 
3.4 接口 
  ● 存储分配 
  ● 限制条件 
3.5测试要点:给出测试模块的主要测试要求。

用户操作手册

1 引言 
1.1 编写目的:阐明编写手册的目的,指明读者对象。 
1.2 项目背景:说明项目的来源、委托单位、开发单位及和主管部门。 
1.3 定义:列出手册中使用的专门术语的定义和缩写词的愿意。 
1.4 参考资料: 
  ● 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源 
  ● 项目经核准的计划任务书、合同或上级机关的批文;项目开发计划;需求规格说明书;概要设计说明书;详细设计说明书;测试计划 
  ● 文档中所引用的其他资料、采用的软件工程标准或软件工程规范。 
2 软件概述 
2.1 目标 
2.2 功能 
2.3 性能 
2.4 数据精确度:包括输入、输出及处理数据的精度。 
2.5 时间特性:如响应时间、处理时间、数据传输时间等。 
2.6 灵活性:在操作方式、运行环境需做某些变更时软件的适应能力。 
3 运行环境 
3.1 硬件 
  ● 列出软件系统运行时所需的硬件最小配置,如计算机型号、主存容量 
  ● 外存储器、媒体、记录格式、设备型号及数量 
  ● 输入、输出设备 
  ● 数据传输设备及数据转换设备的型号及数量。 
3.2 支持软件 
  ● 操作系统名称及版本号 
  ● 语言编译系统或汇编系统的名称及版本号 
  ● 数据库管理系统的名称及版本号 
  ● 其他必要的支持软件 
4 使用说明 
4.1 安装和初始化:给出程序的存储形式、操作命令、反馈信息及其做含意、表明安装完成的测试实例以及安装所需的软件工具等。 
4.2 输入:给出输入数据或参数的要求。 
  ● 数据背景:说明数据来源、存储媒体、出现频度、限制和质量管理等。 
  ● 数据格式:如长度、格式基准、标号、顺序、分隔符、词汇表、省略和重复、控制。 
  ● 输入举例。 
4.3 输出:给出每项输出数据的说明。 
  ● 数据背景:说明输出数据的去向、使用频度、存放媒体及质量管理等。 
  ● 数据格式:详细阐明每一输出数据的格式,如首部、主体和尾部的具体形式。 
  ● 举例 
4.4 出错和恢复:给出出错信息及其含意;用户应采取的措施,如修改、恢复、再启动。 
4.5 求助查询:说明如何操作。 
5 运行说明 
5.1 运行表:列出每种可能的运行情况,说明其运行目的。 
5.2 运行步骤:按顺序说明每和运行的步骤,应包括: 
5.3 运行控制 
5.4 操作信息:运行目的、运行目的、操作要求、启动方法、预计运行时间、操作命令格式及说明、其他事项; 
5.5输入/输出文件:给出建立或更新文件的有关信息,如:文件的名称及编号;记录媒体;存留的目录;文件的支配:说明确定保留文件或废弃文件的准则,分发文件的对象,战胜硬件的优先级及保密控制等。 
5.6 启动或恢复过程 
6 非常规过程 
  提供应急戒非常规操作的必要信息及操作步骤,如出错处理操作、向后备系统切换操作及维护人员须知的操作和注意事项。 
7 操作命令一览表 
  按字母顺序逐个列出全部操作命令的格式、功能及参数说明。 
8 程序文件(或命令文件)和数据文件一览表 
  按文件名字母顺序或按功能与模块分类顺序逐个列出文件名称、标识符及说明。 
9 用户操作举例

测试计划

1 引言 
1.1 编写目的:阐明编写测试计划的目的并指明读者对象。 
1.2 项目背景:说明项目的来源、委托单位及主管部门。 
1.3 定义:列出测试 计划中所用到的专门术语的定义和缩写词的原意。 
1.4参考资料:列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:项目的计划任务书、合同或批文;项目开发计划;需求规格说明书;概要设计说明书;详细设计说明书;用户操作手册;本测试计划中引用的其他资料、采用 
的软件开发标准或规范。 
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 准则:说明评论测试结果的准则。

测试分析报告

1 引言 
1.1 编写目的:阐明编写测试分析报告的目的并指明读者对象。 
1.2 项目背景:说明项目的来源、委托单位及主管部门。 
1.3定义:列出测试分析报告中所用到的专门术语的定义和缩写词的原意。 
1.4参考资料:列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:项目的计划任务书、合同或批文;项目开发计划;需求规格说明书;概要设计说明书;详细设计说明书;用户操作手册;测试计划;测试分析报告所引用的其他资料、采用的软件工程标准或工程规范。 
2 测试计划招待情况 
2.1 机构和人员:给出测试机构名称、负责人和参与测试人员名单。 
2.2 测试结果:按顺序给出每一测试项目的:实测结果数据;与预期结果数据的偏差;该项测试表明的事实;该项测试发现的问题。 
3 软件需求测试结论 
  按顺序给出每一项需求测试的结论。包括:证实的软件能力;局限性(即项需求未得到充分测试的情况及原因。 
4 评价 
4.1 软件能力:经过测试所表明的软件能力。 
4.2 缺陷和限制:说明测试所揭露的软件缺陷和不足,以及可能给软件运行带来的影响。 
4.3 建议:提出为弥补上述缺陷的建议。 
4.4 测试结论:说明能否通过。

开发进度月报

1 报告时间及所处的开发阶段 
2 工程进度 
2.1 本月内的主要活动 
2.2 实际进展与计划比较 
3 所用工时 
  按不同层次人员分别计时。 
4 所用机时 
  按所用计算机机型分别计时。 
5 经费支出 
  分类列出本月经费支出项目,给出支出总额,并与计划比较。 
6 工作遇到的问题及采取的对策 
7 本月完成的成果 
8 下月的工作计划 
9 特殊问题

项目开发总结报告

1 引言 
1.1 编写目的:阐明编写总结报告的目的并指明读者对象。 
1.2 项目背景:说明项目的来源、委托单位、开发单位及主管部门。 
1.3 定义:列出报告中所用到的专门术语的定义和缩写词的原意。 
1.4参考资料:列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:项目的计划任务书、合同或批文;项目开发计划;需求规格说明书;概要设计说明书;详细设计说明书;用户操作手册;测试计划;测试分析报告;本报告引用的其他资料、采用的开发标准或开发规范。 
2 开发结果 
2.1 产品:可包括列出各部分的程序名称、源程序行数(包括注释行)或目标程序字节数及程序总计数量、存储形式;产品文档名称等。 
2.2 主要功能及性能 
2.3 所用工时:按人员的不同层次分别计时。 
2.4 所用机时:按所用计算机机型分别计时。 
2.5 进度:给出计划进度与实际进度的对比。 
2.6 费用 
3 评价 
3.1 生产率评价:如平均每人每月生产的源程序行数、文档的字数等。 
3.2 技术方案评价 
3.3 产品质量评价 
4 经验与教训

软件维护手册

1 引言 
1.1 编写目的:阐明编写手册的目的并指明读者对象。 
1.2 项目背景:说明项目的提出者、开发者、用户和使用场所。 
1.3 定义:列出报告中所用到的专门术语的定义和缩写词的原意。 
1.4 参考资料:列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,及保密级别,可包括:用户操作手册;与本项目有关的其他文档。 
2 系统说明 
2.1 系统用途:说明系统具备的功能,输入和输出。 
2.2 安全保密:说明系统安全保密方面的考虑。 
2.3 总体说明:说明系统的总体功能,对系统、子系统和作业做出综合性的介绍,并用图表的方式给出系统主要部分的内部关系。 
2.4 程序说明:说明系统中每一程序、分程序的细节和特性。 
2.4.1 程序1的说明 
  ● 功能:说明程序的功能。 
  ● 方法:说明实现方法。 
  ● 输入:说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。 
  ● 处理:处理特点和目的,如:用图表说明程序的运行的逻辑流程;程序主要转移条件;对程序的约束条件;程序结束时的出口要求;与下一个程序的通信与联结(运行、控制);由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元;程序运行存储量、类型及存储位置等。 
  ● 输出:程序的输出。 
  ● 接口:本程序与本系统其他部分的接口。 
  ●表格:说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括:表的标识符;使用目的;使用此表的其他程序;逻辑划分,如块或部,不包括表项;表的基本结构;设计安排,包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示。 
  ● 特有的运行性质:说明在用户操作手册中没有提到的运行性质。 
2.4.2程序2的说明 
  与程序1的说明相同。以后的其他各程序的说明相同。 
3 操作环境 
3.1 设备:逐项说明系统的设备配置及其特性。 
3.2 支持软件:列出系统使用的支持软件,包括它们的名称和版本号。 
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 登记号 
  由软件配置管理部门为该报告规定的编号。 
2 登记日期 
  软件配置管理部门登记"软件修改报告"的日期。 
3 时间 
  准备好"软件修改报告"的日期。 
4 报告人 
  填写该报告的作者。 
5 子系统名 
  受修改影响的子系统名。 
6 模块名 
  被修改的模块名。 
7 "软件问题报告"的编号 
  被"软件修改报告"处理或部分处理的"软件问题报告"的编号。如果某"软件问题报告"的问题只是部分被处理,则在编号后附以p,如1234p。 
8 修改 
  包括程序修改、文件更新、数据库修改或它们的组合。 
9 修改描述 
  修改的详细描述。如果是文件更新或数据库修改,还要列出文件更新通知或数据库修改申请的标识符。 
10 批准人 
  批准人签字,正式批准进行修改。 
11 语句类型 
  程序修改中涉及到的语句类型,包括:输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类(如数据传送、存取语句类)。 
12 程序名 
  被修改的程序、文件或数据库的名字。 
13 老修订版 
  当前的版本/修订本标识。 
14 新修订版 
  修改后的版本/修订本标识。 
15 数据库 
  如果申请数据库修改,则给出数据库的标识符。 
16 数据库修改报告 
  数据库修改申请号。 
17 文件 
  如果要求对文件进行修改,则给出文件的名字。 
18 文件更新 
  文件更新通知单的编号。 
19 修改是否已测试 
  指出已对修改做了哪些测试,如单元、子系统、组装、确认和运行测试等,并注明测试成功与否。 
20 "软件问题报告"是否给出问题的准确描述 
  回答‘是‘或‘否‘。 
21 问题注释 
  准确地叙述要维护的问题。 
22 问题源 
  指明问题来自于哪里,如软件需求说明书、设计说明书、数据库、源程序等。 
23 资源 
  完成修改所需资源的估计,即总的人时数和计算机时间的开销

时间: 2024-10-07 21:05:02

在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。的相关文章

浅谈软件项目开发过程中的主要项目风险及对策

软件项目成果的需求分析方和软件项目的承担者都十分关心这样的一个问题:什么样的因素会导致软件项目的失败?与项目有关的因素的改变将对按时.按经费预算交付符合预定质量要求的软件成果产生什么样的影响?这些都属于软件项目开发过程中考虑的风险问题. 软件项目的风险是指在软件开发过程中可能出现的不确定因而造成损失或者影响,如资金短缺.项目进度延误.人员变更以及预算和进度等方面的问题.风险关注未来的事情,这意味着,软件风险涉及选择及选择本身包含的不确定性,软件开发过程及软件产品都要面临各种决策的选择.风险是介于

iOS项目开发过程中的目录结构(转)

iOS项目开发过程中的目录结构 我在这个目录结构方面真是吃了不少苦,开始总是觉得快点写快点写,后来发现只有快是不行的,在没有给整个项目的结构有一个清楚的认识和了解之前就匆匆动笔(敲代码啦)是非常冒失的, 好在在后来修改的过程中慢慢琢磨出来一套目录结构,现在发出来给大家参考一下. 项目主目录结构如图: 1.Network主要用于进行网络请求,以及请求完成后对数据进行处理使用, 2.Category:类目,这个文件夹放在这里我觉得是不太准确的,但是具体应该放在哪里我一直无法确实下来 3.Contro

使用Gitbook来编写你的Api文档

使用Gitbook来编写你的Api文档 Published on: November 18, 2014 Gitbook是一个很优秀的社区,上面有很多优秀的作者自出版自己的著作,就好像Leanpub,可能很多人喜欢Leanpub,但是我还是喜欢Gitbook,这种类似于Github的原创社区.同时Gitbook还提供一个开源的配套的工具.也许看到此文章的很多人很早就知道Gitbook,但是也许你没有使用过,现在Gitbook已经比较成熟了,功能也比较完善.下面我们首先来介绍下Gitbook的使用.

程序员如何编写好开发技术文档 如何编写优质的API文档工作

编写技术文档,是令众多开发者望而生畏的任务之一.它本身是一件费时费力才能做好的工作.可是大多数时候,人们却总是想抄抄捷径,这样做的结果往往非常令人遗憾的,因为优质的技术文档是决定你的项目是否引人关注的重要因素.无论开源产品或面向开发者的产品,均是如此. 实际上,我想说明的是:对于面向开发者的产品来说,其用户体验中最重要的一环并不是什么主页设计.登录过程.或者SDK下载.真正最重要的是产品的API文档!如果没人知道你的产品如何使用,纵使它巧夺天工,又有何用? 如果你是一个专门从事面向开发者产品设计

年度巨献-WPF项目开发过程中WPF小知识点汇总(原创+摘抄)

WPF中Style的使用 Styel在英文中解释为”样式“,在Web开发中,css为层叠样式表,自从.net3.0推出WPF以来,WPF也有样式一说,通过设置样式,使其WPF控件外观更加美化同时减少了大量的复杂属性的设置. 在WPF中,设置外观样式我们有很多种方式,比如通过设置控件的属性来控制控件的外观样式:或者通过在每一个控件中分别设置Style:或者通过在整个Window.Resource中设置Style,又或者在App.xaml的Application.Resource设置Style. 在

项目开发过程中,一些常用的方法

以下一些在开发过程中封装的常用方法,供参考由于一些方法是很久之前写下来的,语法上比较旧,再使用的时候再进行修改//获取当前时刻的时间 // type = 1年月日,type=2时分秒,fommatter="-"表示年月日用-隔开,否则用"/"隔开 export function curTimeFun(type,fommatter) { const myDate = new Date(); const year = myDate.getFullYear()>9?

从数据库中取出数据,使用freemarker生成word文档

这个星期做数据字典功能,有一项任务就是将数据库中的每个表的字段导出,生成word文档,在综合比较网上各种技术之后,参照csdn上骆豪的博客完成了任务. 骆昊的链接:http://blog.csdn.net/jackfrued/article/details/39449021 首先打开word文档,建立自己所需要的模板,然后将word保存为XML的格式,这里可能出现的一个问题就是需要填入的内容放上${}占位符的时候可能会出现字符分离的情况,所以建议先将需要用${}占位符的地方用中文写在word里然

当xml中存在命名空间,dom4j解析以及写入xml文档时的乱码问题

最近公司项目开发中需要通过前台用户界面进行客户业务系统的部署(提供界面化操作,减少运维工作的难度),通过修改web.xml进行设置各个项目不同的信息配置. 开发过程中遇到2种问题,同时将解决方案备注上,以方便日后查看. 问题一:当xml中存在命名空间,三种处理办法(dom4j) 问题二:文件保存之后总是提示中文乱码问题 针对上面2个问题的解决方案进行汇总,解决方法主要还是来自于其他网络同行的博客. 第一个 问题主要参照 博客http://blog.sina.com.cn/s/blog_5cef6

3.Spring Boot中使用Swagger2构建强大的RESTful API文档

原文:http://www.jianshu.com/p/8033ef83a8ed 由于Spring Boot能够快速开发.便捷部署等特性,相信有很大一部分Spring Boot的用户会用来构建RESTful API.而我们构建RESTful API的目的通常都是由于多终端的原因,这些终端会共用很多底层业务逻辑,因此我们会抽象出这样一层来同时服务于多个移动端或者Web前端. 这样一来,我们的RESTful API就有可能要面对多个开发人员或多个开发团队:IOS开发.Android开发或是Web开发