《2023年计算机软件开发文档标准.docx》由会员分享,可在线阅读,更多相关《2023年计算机软件开发文档标准.docx(29页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、 2023年计算机-软件开发文档标准(完整) 软件开发文档标准 一、计算机软件产品开发文件编制指南 ?错误 !未定义书签。 二、可行性讨论报告 ?错误 ! 未定义书签。 三、工程开发规划 . 错误 ! 未定义书签。 四、软件需求说明书 . 错误 ! 未定义书签。 五、数据要求说明书 . 错误 ! 未定义书签。 六、概要设计说明书 七、具体设计说明书 ?错误 ! 未定义书签。 . 错误 ! 未定义书签。 八、数据库设计说明书 ?错误 ! 未定义书签。 九、用户手册 ?错误 !未定义书签。 十、操作手册 . 错误 ! 未定义书签。 十一、模块开发卷宗 . 错误 ! 未定义书签。 十二、测试规划 ?
2、错误 !未定义书签。 十三、测试分析报告 . 错误 ! 未定义书签。 十四、开发进度月报 ?错误 ! 未定义书签。 十五、工程开发总结报告 ?错误 !未定义书签。 一、计算机软件产品开发文件编制指南 目得 一项计算机软件得筹划、研制及实现 , 构成一个软件开发工程。一个软件开发工程得进展,一般 需要 在人力与自动化资源等方面作重大得投资。为了保证工程开发得胜利,最经济地花费这些投 资,并且便 于运行与维护,在开发工作得每一阶段,都需要编制二定得文件。这些文件连同计算 机程序及数据一起, 构成为计算机软件。文件就是计算机软件中不行缺少得组成局部,它得作用 就是 : 、作为开发人员在肯定阶段内得工
3、作成果与完毕标志; b 、向治理人员供应软件开发过程中得进展与状况 , 把软件开发过程中得一些 “不行见得 quot; 事物转 换成 “可见 quot;得文字资料, 以便治理人员在各个阶段检查开发规划得实施进展 ,使之能够推断原定目标 就是否已到达,还将连续耗用资源得种类与数量; 、记录开发过程中得技术信息,便于协调以后得软件开发、使用与修改; d 、供应对软件得有关运行、维护与培训得信息,便于治理人员、开发人员、操作人员与用户之 间相互了解彼此得工作 ; e、向潜在用户报导软件得功能与性能,使她们能判定该软件能否效劳于自己得需要 . 换言之,本指南认为 : 文件得编制必需适应计算机软件整个生
4、存周期得需要。 计算机软件所包含得文件有两类: 一类就是开发过程中填写得各种图表, 可称之为工作表格; 另 一类 则就是应编制得技术资料或技术治理资料, 可称之为文件。 本指南规定软件文件得编制形式, 并供应对这 些规定得解释。 本指南得目得就是使得所编制得软件文件的确能够起到软件文件应当 发挥得作用 . 2 范围 本指南就是一份指导性文件。本指南建议,在一项计算机软件得开发过程中 ,一般地说,应当 产生十四种文件。这十四种文件就是: 可行性讨论报告; 工程开发规划; 软件需求说明书; 数据要求说明书 ; 概要设计说明书; 具体设计说明书; 数据库设计说明书 ; 用户手册; 操作手册 ; 模块
5、开发卷宗; 测试规划; 测试分析报告;开发进度月报; 本指南将给出开发过程中建议产生得这十四种文件得编制指导 ,同时 ,本指南也就是这十四种文件 得编写质量得检验准则。但就是 ,本指南并未涉及软件开发过程中如何填写工作表格得问题。 一般地说,一个软件总就是一个计算机系统(包括硬件、固件与软件 )得组成局部。鉴于计算 机系统得多样性, 本指南一般不涉及整个系统开发中得文件编制问题, 本指南仅仅就是软件开发过 程中得文件编制指南。 3 文件得使用者 对于使用文件得人员而言,她们所关怀得文件得种类 ,随她们所担当得工作而异。 治理人员:可行性讨论报告,工程开发规划,模块开发卷宗,开发进度月报 ,工程
6、开发总结报 告 ; 开发人员 :可行性讨论报告 ,工程开发规划,软件需求说明书 ,数据要求说明书, 概要设计说明 书,具体设计说明书,数据库设计说明书,测试规划 , 测试分析报告 ; 维护人员:设计说明书 ,测试分析报告,模块开发卷宗; 用户 : 用户手册 , 操作手册。 尽管本指南提出了在软件开发中文件编制得要求, 但并不意味着这些文件都必需交给用户。 一 项软件得用户应当得到得文件得种类由供给者与用户之间签订得合同规定 . 软件生存周期与各种文件得编制 一项计算机软件,从消失一个构思之日起,经过这项软件开发胜利投入使用, 直到最终打算停 止使 用,并被另一一项软件代替之时止 ,被认为就是该
7、软件得一个生存周期。一般地说这个软件生 存周期可以分成以下六个阶段: 可行性与计算机讨论阶段 需求分析阶段 设计阶段 实现阶段 测试阶段 运行与维护阶段 在可行性讨论与规划阶段内,要确定该软件得开发目标与总得要求,要进展可行性分析、投资 一收益分析、制订开发规划 ,并完成应编制得文件。 在需求分析阶段内, 由系统分析人员对被设计得系统进展系统分析 ,确定对该软件得各项功能、 性能需求与设计约束,确定对文件编制得要求 ,作为本阶段工作得结果,一般地说,软件需求说明 书、数据要求说明书与初步得用户手册应当编写出来。 在设计阶段内, 系统设计人员与程序设计人员应当在反复理解软件需求得根底上, 提出多
8、个设 计 ,分析每个设计能履行得功能并进展相互比拟,最终确定一个设计,包括该软件得构造、模块得 划分、功能得安排以及处理流程。在被设计系统比拟简单得状况下 ,设计阶段应分解成概要设计阶 段与具体设计阶段两个步骤。在一般状况下 ,应完成得文件包括 : 概要设计说明书、具体设计说明书 与测试规划初稿。 在实现阶段内 , 要完成源程序得编码、 编译(或汇编) 与排错调试得到无语法错得程序清单 ,要开 始编写模块开发卷宗 ,并且要完成用户手册、操作手册等面对用户得文件得编写工作,还要完成测试规划得编制。 在测试阶段,该程序将被全面地测试 , 已编制得文件将被检查批阅 . 一般要完成模块开发卷宗与测 试
9、分析报告 , 作为开发工作得完毕,所生产得程序、文件以及开发工作本身将逐项被评价,最终写出工程开发总结报告。 在整个开发过程中(即前五个阶段中),开发集体要按月编写开发进度月报。 在运行与维护阶段,软件将在运行使用中不断地被维护,依据新提出得需求进展必要而且可能 得扩大与删改 . 对于一项软件而言, 其生存周期各阶段与各种文件编写工作得关系可见表 ,其中有些文件得编写 工作可能要在若干个阶段中连续进展 . 5 文件编制中得考虑因素 文件编制就是一个不断努力得工作过程。就是一个从形成最初轮廓 , 经反复检查与修改 ,直到程序 与文件正式交付使用得完整过程 .其中每一步都要求工作人员做出很大努力。
10、要保证文件编制得质 量 ,要表达每个开发工程得特点,也要留意不要花太多得人力 .为此 ,编制中要考虑如下各项因素。 5、 1 文件得读者 第一种文件都具有特定得读者。 这些读者包括个人或小组、 软件开发单位得成员或社会上得公 众、从事软件工作得技术人员、治理人员或领导干部 . 她们期盼着使用这些文件得内容来进展工作 , 例如设计、编写程序、测试、使用、维护或进展规划治理。因此,这些文件得必需了解自己得 读者,这些文件得编写必需留意适应自己得特定读者得水平、特点与要求 . 、 2 重复性 本指南其次篇中将列出得这十四种文件得内容要求中,明显存在某些重复 . 较明显得重复有两 类。引言就是第一种文
11、件都要包含得内容,以向读者供应总得梗概 .其次类明显得重复就是各种文 件中得说明局部,如对功能性能得说明、对输入与输出得描述、系统中包含得设备等。这就是为了 便利每种文件各得意读者,每种产品文件应当自成体系 ,尽量避开读一种文件时又不得不去参考另 一种文件 . 固然 ,在每一种文件里,有关引言、说明等同其她文件相重复得局部,在行文上、在所用 得术语上、在具体得程度上 ,还就是应当有一些差异,以适应各种文件得不同读者得需要。 、 3 敏捷性 鉴于软件开发就是具有制造性得脑力劳动,也鉴于不同软件在规模上与简单程序上差异极大,本指南认为在文件编制工作中应允许肯定得敏捷性。这种敏捷性表现在如下各款。
12、5 3。 应编制得文件种类 尽管本指南认为在一般状况下, 一项软件得开发过程中 ,应产生得文件有十四种 , 然而针对一项具 体得软件开发工程,有时不必编制这么多得文件 ,可以把几种文件合并成一种。一般地说,当工程 得规模、简单性与成败风险增大时,文件编制得范围、治理手续与具体程度将随之增加。反之 ,则 可适当削减。为了恰当地把握这种敏捷性,本指南要求贯彻分工负责得原则,这意味着: a、一个软件开发单位得领导机构应当依据单位经营承包得应用软件得专业领域与本单位得治理 力量,制定一个对文件编制要求得实施规定 ,主要就是 : 在不同得条件下,应当形成哪些文件?这些 文件得具体程序 ?该开发单位得每一
13、个工程负责人,必需仔细执行这个实施规定。这种规定得两个例子可瞧本指南得附录; b 、于一个详细得应用软件工程,工程负责人应依据上述实施规定 , 确定一个文件编制规划, 主要包括 : ( 1)应当编制哪几种文件,具体程序如何 ( 2)各个文件得编制负责人与进度要求 ; ( 3) 审查、批准得负责人与时间进度安排 (4 )在开发时期内,各文件得维护、修改与治理得负责人,以及批准手续。 每项工作必需落实到人。 这个文件编制规划就是整个开发规划得重要组成局部 ; 、有关得设计人员则必需严格执行这个文件编制规划。 5. 2 文件得具体程序 从同一份提纲起草得文件得篇幅大小往往不同 ,可以少到几页,也可以
14、长达几百页。对于这种 差异本指南就是允许得。 此具体程序取决于任务得规模、 简单性与工程负责人对该软件得开发过程 及运行环与所需要得具体程度得推断。 .3。 3 文件得扩展 当被开发系统得规模特别大 (例如源码超过一百万行)时 ,一种文件可以分成几卷编写 ,可以按其。 每一个系统分别编制,也可以按内容划分成多卷,例如: 工程开发规划可能包括:质量保证规划,配置治理规划 ,用户培训规划,安装实施规划; 系统设计说明书可分写成:系统设计说明书 ,子系统设计说明书; 程序设计说明书可分写成:程序设计说明书,接口设计说明书,版本说明; 操作手册可分写成:操作手册,安装实施过程 ; 测试规划可分写成:测
15、试规划,测试设计说明,测试规程,测试用例; 测试分析报告可分写成 : 综合测试报告,验收测试报告 ; 工程开发总结报告亦可分写成工程开发总结报告与资源环境统计 . 5。 3 节得扩张与缩并 在有些文件中 , 可以使用本指南所供应得章、条标题,但在条内又存在一系列需要分别争论得因 素 本指南认为,全部得条都可以扩展 , 可以进一步细分,以适应实际需要。反之 ,假如章条中得有 些细节 ; 非必需,也可以依据实际状况缩并。此时章条得编号应相应地转变。 。 3 5 程序设计得表现形式 本指南对于程序得设计表现形式并未作出规定或限制, 可以使用流程图得形式、 判定表得形式, 可以使用其她表现形式,如程序
16、设计语言 (P )、问题分析图( D) 等。 5.3 。 文件得表现形式 本指南对于文件得表现形式亦未作出规定或限制 ,可以使用自然语言 ,也可以使用形式化语言 . 5。 3. 文件得其她种类 当本指南中规定得文件种类尚不能满意某些应用部门得特别需要时 ,她们可以建立一些特别得文 件种类要求 , 例如软件质量保证规划、软件配置治理规划等,这些要求可以包含在本单位得文件编 制实施规定中。 6 文件编制得治理工作 文件编制工作必需有治理工作得协作, 才能使所编制得文件真正发挥它得作用 . 文件得编制工作 实际上贯穿于一项软件得整个开发过程 , 因此 ,对文件得治理必需贯穿于整个开发过程 .在开发过
17、程 中必需进展得治理工作就是以下四条。 、 1 文件得形成 开发集体中得每个成员 ,尤其就是工程负责人 ,应当熟悉到 :文件就是软件产品得必不行少得组成 局部; 在软件开发过程得各个阶段中,必需根据规定准时地完成各种产品文件得编写工作 ;必需把 在一个开发步骤中作出得打算与取得得结果准时地定文件; 开发集体必需准时地对这些文件进展严 格得评审 ; 这些文件得形成就是各个阶段开发工作正式完成得标志。这些文件上必需有编写者、评 审者与批准者得签字,必需有编写、评审完成得日期与批准得日期 . 6、 2 文件得分类与标识 在软件开发得过程中 ,产生得文件就是许多得, 为了便于保存、 查找、 使用与修改
18、 , 应当对文件按 层次地加以分类组织。 一个软件开发单位应当建立一个对本单位文件得标识方法, 使文件得每一页 都具有明确得标识。例如可以按如下四个层次对文件加以分类与标识。 a、文件所属得工程得标识 ; b、文件种类得标识; c、同一种文件得不同版本号 ; d、页号 此外,对每种文件还应依据工程得性质 , 划定它们各得意保密级别 , 确定她们各得意发行范围。 6、 3 文件得掌握 在一项软件得开发过程中,随着程序得逐步形成与逐步修改,各种文件亦在不断地产生、不断地修改或补充 .因此,必需加以周密得掌握 ,以保持文件与程序产品得全都性 ,保持各种文件之间得全都性与文件得安全性。这种掌握表现为
19、: 、就从事一项软件开发工作得开发集体而言,应设置一位专职得文件治理人员 ( 接口治理工程 师或文件治理员) ; 在开发集体中,应当集中保管本工程现有全部文件得主文本两套 , 由该文件治理 人员负责保管; b 、每一份提交给文件治理人员得文件都必需具有编写人、审核人与批准人得签字 ; c、这两套主文本得内容必需完全全都 ;其中有一套就是可供出借得,另一套就是肯定不能出借 得 ,以免发生万一 ; 可出借得主文本在出借时必需办理出借手续,归还时办理注销出借手续; d 、开发集体中得工作人员可以依据工作得需要 ,在本工程得开发过程中持有一些文件,即所谓 个人文件,包括为使她完成她担当得任务所需要得文
20、件,以及她在完成任务过程中所编制得文件 ; 但这种个人文件必需就是主文本得复制品,必需同主文本完全全都,若要修改 ,必需首先修改主文 本; e、不同开发人员所拥有得个人文件通常就是主文本得各种子集; 所谓子集就是指把主文本得各个局部依据担当不同任务得人员或部门得工作需要加以复制、 组装而成得若干个文件得集合; 文件治理人员 . 应当列出一份不同子集得分发对象得清单,根据清单准时把文件分发给有关人员或部门; f、一份文件假如已经被另一份新得文件所代替,则原文件应当被注销 ; 文件治理人中要随时整 理主文本,准时反映出文件得变化与增加状况,准时分发文件; 、当一个工程得开发工作接近完毕时,文件治理
21、人员应逐个收回开发集体内每个成员得个人 文 件 ,并检查这些个人文件得内容 ; 阅历说明,这些个人文件往往可能比主文本更具体 ,或同主文本 得内容 有所不同 , 必需仔细监视有关人员进展修改,使主文本能真正反映实际得开发结果 . 6、 4 文件得修改治理 在一个工程得开发过程中得任何时刻,开发集体内得全部成员都可能对开发工作得已有成果 - 文件,提出进展修改得要求 .提出修改要求得理由可能就是各种各样得,进展修改而引起得影响可 能很小 , 也可能会牵涉到本工程得许多方面。 因此 , 修改活动得进展必需慎重, 必需对修改活动得进 行加以治理, 必需执行修改活动得规程,使整个修改活动有掌握地进展。
22、 修改活动可分如下五个步骤进展 : a、提议开发集体中得任何一个成员都可以向工程负责人提出修改建议, 为此应当填写一份修 改 建议表 , 说明修改得内容、所修改得文件与部位、以及修改理由 ; b 、评议由工程负责人或工程负责人指定得人员对该修改建议进展评议 ,包括审查该项修改得必 要、确定这一修改得影响范围、讨论进展修改得方法、步骤与实施规划; c、审核一般由工程负责人进展审核 ,包括核实修改得目得与要求、核实修改活动将带来得影响、 审核修改活动规划就是否可行; d 、批准在一般状况下 , 批准权属于该开发单位得部门负责人 ;在批准时,主要就是决断修改工作 中各项活动得先后挨次及各得意完成日期
23、,以保证整个开发工作按原定规划日期完成; e、实施由工程负责人根据已批准得修改活动规划,安排各项修改活动得负责人员进展修改 , 建立修改记录、 产生新得文件以取代原有文件、最终把文件交文件治理人员归档, 并分发给有关得 持有者 . 二、可行性讨论报告 可行性讨论报告得编写目得就是 : 说明该软件开发工程得实现在技术、经济与社会条件方面得 可行性; 评述为了合理地到达开发目标而可能选择得各种方案;说明并论证所选定得方案 . 可行性讨论报告得编写内容要求如下 : 1 引言 1、 编写目得 说明编写本可行性讨论报告得目得 , 指出预期得读者。 1、 背景说明: a、所建议开发得软件系统得名称; b、
24、本工程得任务提出者、开发者、用户及实现该软件得计算中心或计算机网络; c、该软件系统同其她系统或其她机构得根本得相互来往关系。 1、 3 定义 列出本文件中用到得特地术语得定义与外文首字母组词得原词组。 1、 4 参考资料 列出用得着得参考资料,如 : a、本工程得经核准得规划任务书或合同、上级机关得批文; 、属于本工程得其她已发表得文件 ; 、本文件中各处引用得文件、资料 , 包括所需用到得软件开发标准。 列出这些文件资料得标题、 文件编号、发表日期与出版单位 , 说明能够得到这些文件资料得来源 . 2 可行性讨论得前提 说明对所建议得开发工程进展可行性讨论得前提,如要求、目标、假定、限制等
25、。 2、 要求 说明对所建议开发得软件得根本要求,如: a、功能 ; 、性能; c、输出如报告、文件或数据,对每项输出要说明其特征 , 如用途、产生频度、接口以及分发对 象; d 、输入说明系统得输入 , 包括数据得来源、类型、数量、数据得组织以及供应得频度; e 、处理流程与数据流程用图表得方式表示出最根本得数据流程与处理流程,并辅之以表达; f 、在安全与保密方面得要求 ; g、同本系统相连接得其她系统 ; h、完成期限 . 2、 2 目标 说明所建议系统得主要开发目标 , 如: a 、人力与设备费用得削减; b、处理速度得提高; c、掌握精度或生产力量得提高; d、治理信息效劳得改良; e 、自动决策系统得改良; f 、人员利用率得改良 . 2、 3 条件、假定与限制 说明对这项开发中给出得条件、假定与所受到得限制,如 : a. 所建议系统得运行寿命得最小值 ; b 进展系统方案选择比拟得时间 ; c. 经费、投资方面得来源与限制; d法律与政策方面得限制; . 硬件、软件、运行环境与开发环境方面得条件与限制; . 可利用得信息与资源 ; g 、系统投入使用得最晚时间 . 2、 4 进展可行性讨论得方法 说明这项可行性讨论将就是如何进展得, 所建议得系统将就是如何评价得 .
限制150内