计算机软件文档编制规范第2稿冯修改过底版的.ppt
- 文档编号:18743925
- 上传时间:2023-10-26
- 格式:PPT
- 页数:148
- 大小:271KB
计算机软件文档编制规范第2稿冯修改过底版的.ppt
《计算机软件文档编制规范第2稿冯修改过底版的.ppt》由会员分享,可在线阅读,更多相关《计算机软件文档编制规范第2稿冯修改过底版的.ppt(148页珍藏版)》请在冰点文库上搜索。
冯惠,GB/T8567-2006计算机软件文档编制规范,一、本标准修订的背景,版是参考英国某公司的文档标准,结合当时国内软件开发的经验,而且主要是针对瀑布模型的开发方法而制定的。
该标准的发布与实施对我国上世纪八十年代、九十年代的软件开发发挥了重要作用。
但随着时间的推移,软件工程技术的发展与提高,目前来看,版已经不适应软件产业发展的需要,因此修订版势在必行。
二、GB/T8567-2006制定的依据,主要依据:
信息技术软件生存周期过程软件开发与文档编制:
信息技术软件用户文档过程,三、新老版本的主要差异,主要适用于瀑布模型开发方法给出了种文档的编制格式要求:
)可行性研究报告)项目开发计划)软件需求说明书,新老版本的主要差异,)数据要求说明书)概要设计说明书)详细设计说明书)数据库设计说明书)用户手册)操作手册)模块开发卷宗)测试计划)测试分析报告)开发进度月报)项目开发总结报告,新老版本的主要差异,6原则上适用于各种类型的开发方法6描述了文档编制过程6给出种文档的编制格式要求)可行性分析(研究)报告)软件开发计划)软件测试计划)软件安装计划,新老版本的主要差异,)软件移交计划)运行概念说明)系统子系统需求规格说明)接口需求规格说明)系统子系统设计(结构设计)说明)接口设计说明)软件需求规格说明)数据需求说明)软件(结构)设计说明,新老版本的主要差异,)数据库(顶层)设计说明)软件测试说明)软件测试报告)软件配置管理计划)软件质量保证计划)开发进度月报)项目开发总结报告,新老版本的主要差异,)软件产品规格说明)软件版本说明)软件用户手册)计算机操作手册)计算机编程手册另外给出了面向对象的种文档的编制格式要求,四、6标准结构,、范围、规范性引用文件、术语和定义、缩略语、文档(编制)过程、文档编制要求、文档编制格式附录面向对象软件的文档编制,五、文档(编制)过程5.1概述,有两种主要类型的标准:
a.产品标准,它规定产品的特征和功能需求;b.过程标准,它规定开发产品的过程。
应用程序和计算机软件的复杂性日益增加,使得给使用计算机的用户提供完整的、正确的和易懂的文档的需要更加迫切。
本标准通过规定影响软件文档的质量的活动(做什么和由谁做),提供达到这些目的的工具。
文档常常是关心在软件已经实现后做些什么。
然而,为了质量,软件文档编制应作为整个软件生产过程的一部分。
过程计划应把文档计划包括在内。
本标准也给用户和客户提供工具以保证文档过程实施。
本标准的主要活动是建立开发文档的广泛计划。
这是必须的,因为有计划,文档编制的质量会更好,过程的效率会更高。
为遵循本标准,计划必须包括风格规格说明。
本标准不规定风格规格说明的内容(即不规定具体的布局和字体),但它规定风格规格说明必须覆盖什么。
本标准也规定何种信息对于文档管理者是可用的和谁做评审和再生产文档。
5.2文档(编制)过程的关注点,文档编制计划文档开发(编制)文档评审,5.3文档计划,5.3.1概要文档管理者应准备一文档计划,此计划规定在文档创建中要执行的工作。
此文档计划应经需方正式同意,以预示它完全覆盖了需方的要求。
l文档计划通常将覆盖整个文档系列。
文档计划应正式地描述计划的文档的范围和限制,以及重要的文档分析和设计决定。
也应规定在文档开发期间实现的过程和控制。
文档计划应包括(但不限于)以下内容:
a)计划的文档的工作名称、目的、范围和限制。
b)文档的预定的读者,和使用的目的。
c)文档内容的草案表,带有估计的页数和其他媒体的等效细节。
d)交付:
打印副本数,是否提供电子副本,磁盘和文件格式(包括软件版本)和在何处交付。
e)版权的拥有者和任何其他所有权。
l这是复杂的问题,应在合同中规定。
f)适当处,包括每个文档的安全或机密级。
g)管理文档开发过程的步骤和控制,包括存储、检索、后备、处理和质量保证(若要求)。
h)所用的生产方法、工具和工具版本。
i)文档开发人员所在的队伍的结构,任选地,包括队伍选择计划。
l在文档编写和生产的不同阶段中的工作人员,需要不同的技巧。
编写人员可能要求对正在编写的系统有好的知识加上写文档的经验;编辑人员可能要求有编辑经验而对系统知识无要求;版面艺术家可能对所用的版面工具外,无任何知识要求。
j)项目依赖。
k)所要求的人时和成本。
l)项目资源需求,包括需方提供的信息和其他资源。
m)在软件开发期间,软件变更传送信息给文档管理者的方法。
n)文档的变更控制和维护的计划(任选)。
o)实现后评审的计划(任选)。
p)显示适当的里程碑的时间表,包括:
1)文档计划批准;对于文档的每一项应重复。
l文档计划宜2)每个草案的准备、评审和改正;3)可用性测试;4)打印、装订和发布。
若适当,这些活动的每一个在文档的开发开始以前准备与批准,以保证所有部门同意目标和所用的方法。
批准后,计划宜尽可能广泛地分发;分发宜包括所有文档开发人员和可能包括需方人员及子合同方。
5.3.2文档计划控制在正式同意后,文档管理者应控制文档计划和它的发布。
文档管理者应保持一份文档计划副本的分发的清单。
若以后文档计划变更了(得到文档管理者和需方的同意),文档管理者应保证所有得到文档计划副本的人员,应得到变更通知。
l因为,计划的过时的副本可能引起问题,文档管理者宜禁止计划的未控制的副本并制订计划的所有副本已经更新的审核过程。
5.4文档开发,按文档计划规定进行文档开发。
通常,在进行文档开发前,要规定文档的格式(风格)。
在软件的开发和管理过程中需要那些文档,每种文档的规范在下面说明。
5.5评审,5.5.1概述本节规定文档评审的要求和相关活动。
本节主要以用户文档的评审为例说明。
对于开发文档的评审,由供方组织和实施。
而批准由开发组织的上级技术机构实施。
更要着重经常性的、非正式的注重实效的评审。
不是要追求形式。
用户文档的评审应由需方实现,包括当需要时与文档管理者讨论。
l评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。
评审宜由合适的有资格的人员执行,这些人员被授权请求变更和批准文档的内容。
l需方宜限止评审人员数为评审功能所必需的那些。
需方在批准每个用户文档草案之前,应保证文档的安全和合法。
为评审交付的文档应包括从文档管理者来的说明书,说明评审的目的和评审员的职责。
l注1:
在需方和文档管理者之间在整个开发过程期间维持良好的通信会提高文档的质量并利于评审成功。
这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。
l注2:
在要求的变更超出了合同和文档计划的范围时,需要变更合同。
l注3:
评审过程不免除文档管理者,他们的责任是试图尽可能保证文档的精确和完整。
l注4:
从评审的结果而来的需方的评论结果宜用或是加上标记的草案或用有适当的参考的方式写评论。
需方宜保持变更的副本为了与下一草案相比较。
评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。
l注5:
对于大的、复杂的系统或正在写文档时系统仍在开发,可能需要多于两次草案和一次校样。
在这样情况下,最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。
5.5.2文档计划评审此评审的目的应保证文档计划定义的文档,当完成时,既满足开发过程的需要也满足需方在合同中规定的的文档目标。
需方同意文档计划,是同意在计划中定义的用户文档的所有可交付的特征。
l注:
需方宜放注意至在内容的草案表中展示的文档的结构、完整性和可用性。
只要适当,文档计划宜在第一个草案开始工作之前评审和批准。
5.5.3第一个草案评审第一个草案应包含如在文档计划中描述的文档主体,加上内容表,附录和词汇。
在使用自动索引工具处,生成的索引包含位置参照。
标点符号、风格和版面应如在文档计划中描述的。
文档的第一个草案的评审目的是核查文档的技术正确性和完整性,以保证草案满足文档计划的目标。
标点符号、风格和版面应如在文档计划中定义的。
在批准第一个草案中,除了要求的变更外,评审批准技术正确性、结构清楚性和文档的完整性。
l注1:
第一个草案宜在交付前编辑。
这有两个理由:
a)这保证评审者不分心于改正印刷的和版面的错误;b)保证由编辑过程引起的任何技术错误被评审者捕获。
l注2:
草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。
在带有评论的第一个草案返回前,宜确认,若草案完全改正了,将满足文档计划的要求。
5.5.4第二个草案评审第二个草案应包在第一个草案评审中同意的所有变更且应以尽可能接近最后的形式包括在文档计划中定义的可交付的内容。
此评审的目的是核查在第一个草案中的内容已经正确实现。
在第二个草案的批准中,除了草案的物理形式外,批准文档的所有方面。
草案的物理形式可能与可交付的不精确相同。
l注:
在批准第二个草案前,宜确认草案(包含评审对草案的评论)已经准备好批准。
六、文档编制要求,6.1软件生存周期与各种文档的编制,在计算机软件的生存周期中,一般地说,应该产生以下一些基本文档。
可行性分析(研究)报告;软件(或项目)开发计划;软件需求规格说明;接口需求规格说明;系统子系统设计(结构设计)说明;软件(结构)设计说明;,接口设计说明;数据库(顶层)设计说明;(软件)用户手册;操作手册;测试计划;测试报告;,软件配置管理计划;软件质量保证计划;开发进度月报;项目开发总结报告;软件产品规格说明;软件版本说明等。
本标准将给出这些文档的编制规范,同时,本标准也是这些文档的编写质量的检验准则。
一般地说,一个软件总是一个计算机系统(包括硬件,固件和软件)的组成部分。
鉴于计算机系统的多样性,本标准一般不涉及整个系统开发中的文档编制问题,本标准仅仅是软件开发过程中的文档编制指南。
对于使用文档的人员而言他们所关心的文件的种类随他们所承担的工作而异。
管理人员:
可行性分析(研究)报告,项目开发计划,软件配置管理计划,软件质量保证计划,开发进度月报,项目开发总结报告;,开发人员:
可行性分析(研究)报告,项目开发计划,软件需求规格说明,接口需求规格说明,软件(结构)设计说明,接口设计说明书,数据库(顶层)设计说明,测试计划,测试报告;,维护人员:
软件需求规格说明,接口需求规格说明,软件(结构)设计说明,测试报告,,用户:
软件产品规格说明,软件版本说明,用户手册,操作手册。
本标准规定了在软件开发过程中文档编制的要求,这些文档从使用的角度可分为用户文档和开发文档两大类。
其中,用户文档必须交给用户。
用户应该得到的文档的种类和规模由供应者与用户之间签订的合同规定。
如前所述,软件,从出现一个构思之日起,经过软件开发成功投入使用,直到最后决定停止使用并被另一项软件代替之时止,被认为是该软件的一个生存周期,一般地说这个软件生存周期可以分成以下六个阶段:
可行性与计划研究阶段;需求分析阶段;设计阶段;实现阶段;测试阶段;运行与维护阶段。
在可行性分析(研究)与计划阶段内,要确定该软件的开发目标和总的要求,要进行可行性分析、投资一收益分析、制订开发计划,并完成应编制的文档。
在需求分析阶段内,由系统分析人员对被设计的系统进行系统分析,确定对该软件的各项功能、性能需求和设计约束,确定对文档编制的要求,作为本阶段工作的结果,一般地说软件需求规格说明(也称为:
软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来。
在设计阶段内,系统设计人员和程序设计人员应该在反复理解软件需求的基础上,提出多个设计,分析每个设计能履行的功能并进行相互比较,最后确定一个设计,包括该软件的结构、模块(或CSCI)的划分、功能的分配,以及处理流程。
在被设计系统比较复杂的情况下,设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。
在一般情况下,应完成的文档包括:
结构设计说明、详细设计说明和测试计划初稿。
在实现阶段内,要完成源程序的编码、编译(或汇编)和排错调试得到无语法错的程序清单,要开始编写进度日报、周报和月报(是否要有日报或周报,取决于项目的重要性和规模),并且要完成用户手册、操作手册等面向用户的文档的编写工作,还要完成测试计划的编制。
在测试阶段:
该程序将被全面地测试,已编制的文档将被检查审阅。
一般要完成测试分析报告。
作为开发工作的结束,所生产的程序、文档以及开发工作本身将逐项被评价,最后写出项目开发总结报告。
在整个开发过程中(即前五个阶段中),开发团队要按月编写开发进度月报。
在运行和维护阶段,软件将在运行使用中不断地被维护,根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。
6.2文档编制中的考虑因素,文档编制是开发过程的有机组成部分,也是一个不断努力的工作过程。
是一个从形成最初轮廓、经反复检查和修改,直至程序和文档正式交付使用的完整过程。
其中每一步都要求工作人员做出很大努力。
要保证文档编制的质量,要体现每个开发项目的特点,也要注意不要花太多的人力。
为此编制中要考虑如下各项因素。
6.2.1文档的读者每一种文档都具有特定的读者。
这些读者包括个人或小组、软件开发单位的成员或社会上的公众、从事软件工作的技术人员、管理人员或领导干部。
他们期待着使用这些文档的内容来进行工作,例如设计、编写程序、测试、使用、维护或进行计划管理。
因此这些文档的作者必须了解自己的读者。
这些文档的编写必须注意适应自己的特定读者的水平、特点和要求。
6.2.2重复性本规范中列出的文档编制规范的内容要求中,显然存在某些重复。
较明显的重复有两类。
引言是每一种文档都要包含的内容,以向读者提供总的梗概.第二类明显的重复是各种文档中的说明部分,如对功能性能的说明;对输入、输出的描述;系统中包含的设备等。
这是为了方便每种文档各自的读者,每种文档应该自成体系,尽量避免读一种文档时又不得不去参考另一种文档。
当然,在每一种文档里,有关引言、说明等同其他文档相重复的部分,在行文上、在所用的术语上、在详细的程度上,还是应该有一些差别以适应各种文档的不同读者的需要。
6.2.3灵活性鉴于软件开发是具有创造性的脑力劳动,也鉴于不同软件在规模上和复杂程度上差别极大,本规范认为在文档编制工作中应允许一定的灵活性。
这种灵活性表现在如下各款。
a.应编制的文档种类尽管本规范认为在一般情况下,一项软件的开发过程中,应产生如上所述的各种文档,然而针对一项具体的软件开发项目,有时不必编制这么多的文档,可以把几种文档合并成一种。
一般地说,当项目的规模、复杂性和失败风险增大时,文档编制的范围,管理手续和详细程度将随之增加,反之,则可适当减少。
为了恰当地掌握这种灵活性,本规范要求贯彻分工负责的原则,这意味着:
1)一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管理能力,制定一个对文档编制要求的实施规定,主要是:
在不同的条件下,应该形成哪些文档?
这些文档的详细程度?
该开发单位的每一个项目负责人,必须认真执行这个实施规定。
2)对于一个具体的应用软件项目,项目负责人应根据上述实施规定,确定一个文档编制计划(可以包含在软件开发计划中),其中包括:
(1)应该编制哪几种文档,详细程度如何?
(2)各个文档的编制负责人和进度要求;(3)审查、批准的负责人和时间进度安排(4)在开发时间内,各文档的维护、修改和管理的负责人,以及批准手续。
每项工作必须落实到人。
这个文件编制计划是整个开发计划的重要组成部份。
3)有关的设计人员则必须严格执行这个文档编制计划。
b.文档的详细程度从同一份提纲起草的文件的篇幅大小往往不同,可以少到几页,也可以长达几百页。
对于这种差别,本规范是允许的。
此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行环境所需要的详细程度的判断。
c.文档的扩展当被开发系统的规模非常大例如源码超过一百万行时,一种文档可以分成几卷编写,可以按其中每一个系统分别编制;也可以按内容划分成多卷,例如:
项目开发计划可能包括:
质量保证计划,配置管理计划,用户培训计划,安装实施计划;,系统设计说明可分写成:
系统设计说明,子系统设计说明;程序设计说明可分写成:
程序设计说明,接口设计说明,版本说明;,操作手册可分写成:
操作手册,安装实施过程;测试计划可分写成:
测试计划,测试设计说明,测试规程,测试用例;,测试分析报告可分写成:
综合测试报告,验收测试报告;项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。
d.节的扩张与缩并在有些文档中,可以使用本规范所提供的章、条标题,有存在一系列需要分别讨论的因素。
本规范认为,所有的条都可以扩展,可以进一步细分,以适应实际需要。
反之如果章条中的有些细节并非必需,也可以根据实际情况缩并。
此时章条的编号应相应地变更。
e.程序设计的表现形式本规范对于程序的设计表现形式并未作出规定或限制,可以使用流程图的形式,判定表的形式,也可以使用其他表现形式,如程序设计语言(PDL)、问题分析图(PALb)等。
f.文档的表现形式本规范对于文档的表现形式亦未作出规定或限制。
可以使用自然语言,也可以使用形式化语言。
也可以使用各件图、表。
g.文档的其他种类当本规范中规定的文档种类尚不能满足某些应用部门的特殊需要时,他们可以建立一些特殊的文档种类要求,例如软件质量保证计划、软件配置管理计划等,这些要求可以包含在本单位的文件编制实施规定中。
七、文档编制格式,7.1软件开发计划(SDP),说明:
1.软件开发计划(SDP)描述开发者实施软件开发工作的计划,本文档中”软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其它所有的活动。
2.SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。
3.本计划的某些部分可视实际需要单独编制成册,例如,软件配置管理计划、软件质量保证计划和文档编制计划等。
1引言本章分为以下几条。
1.1标识本条应包含本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的投资方、需方、用户、开发方和支持机构;标识当前和计划的运行现场;列出其它有关的文档。
1.3文档概述本条应概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。
1.4与其它计划之间的关系(若有)本条描述本计划和其它项目管理计划的关系。
1.5基线给出编写本项目开发计划的输入基线,如软件需求规格说明。
2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期,本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3交付产品3.1程序3.2文档3.3服务3.4非移交产品3.5验收标准3.6最后交付期限列出本项目应交付的产品,包括软件产品和文档。
其中,软件产品应指明哪些是要开发的,哪些是属于维护性质的;文档是指随软件产品交付给用户的技术文档,例如用户手册、安装手册等。
4所需工作概述本章根据需要分条对后续章描述的计划作出说明,(若适用)包括以下概述:
a.对所要开发系统、软件的需求和约束;b.对项目文档编制的需求和约束;c.该项目在系统生命周期中所处的地位;d.所选用的计划/采购策略或对它们的需求和约束;e.项目进度安排及资源的需求和约束;f.其它的需求和约束,如:
项目的安全性、保密性、私密性、方法、标准、硬件开发和软件开发的相互依赖关系等。
5实施整个软件开发活动的计划本章分以下几条。
不需要的活动的条款用”不适用”注明,如果对项目中不同的开发阶段或不同的软件需要不同的计划,这些不同之处应在此条加以注解。
除以下规定的内容外,每条中还应标识可适用的风险和不确定因素,和处理它们的计划。
5.1软件开发过程本条应描述要采用的软件开发过程。
计划应覆盖论及它的所有合同条款,确定已计划的开发阶段(适用的话)、目标、和各阶段要执行的软件开发活动。
5.2软件开发总体计划本条应分以下若干条进行描述。
5.2.1软件开发方法本条应描述或引用要使用的软件开发方法,包括为支持这些方法所使用的手工、自动工具和过程的描述。
该方法应覆盖论及它的所有合同条款。
如果这些方法在它们所适用的活动范围有更好的描述,可引用本计划的其它条。
5.2.2软件产品标准本条应描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准。
标准应覆盖合同中论及它的所有条款。
如果这些标准在标准所适用的活动范围有更好的描述,可引用在本计划中的其它条。
对要使用的各种编程语言都应提供编码标准,至少应包括:
a.格式标准(如:
缩进、空格、大小写和信息的排序);b.首部注释标准,例如(要求:
代码的名称/标识符,版本标识,修改历史,用途)需求和实现的设计决策,处理的注记(例如:
使用的算法、假设、约束、限制和副作用),数据注记(输入、输出、变量和数据结构等);c.其它注释标准(例如要求的数量和预期的内容);d.变量、参数、程序包、过程和文档等的命名约定;e.(若有)编程语言构造或功能的使用限制;f.代码聚合复杂性的制约。
5.2.3可重用的软件产品本条应分以下若干条。
5.2.3.1吸纳可重用的软件产品本条应描述标识、评估和吸纳可重用软件产品要遵循的方法,包括搜寻这些产品的范围和进行评估的准则。
描述应覆盖合同中论及它的所有条款。
在制定或更新计划时对己选定的或候选的可重用的软件产品应加以标识和说明,(若适用)同时应给出与使用有关的优点、缺陷和限制。
5.2.3.2开发可重用的软件产品本条应描述如何标识、评估和报告开发可重用软件产品的机会。
描述应覆盖合同中论及它的所有条款。
5.2.4处理关键性需求本条应分以下若干条描述为处理指定关键性需求应遵循的方法。
描述应覆盖合同中论及它的所有条款。
5.2.4.1安全性保证5.2.4.2保密性保证5.2.4.3私密性保证5.2.4.4其它关键性需求保证,5.2.5计算机硬件资源利用本条应描述分配计算机硬件资源和监控其使用情况要遵循的方法。
描述应覆盖合同中论及它的所有条款。
5.2.6记录原理本条应描述记录原理所遵循的方法,该原理在支持机构对项目作出关键决策时是有用的。
应对项目的”关键决策”一词作出解释,并陈述原理记录在什么地方。
描述应覆盖合同中论及它的所有条款。
5.2.7需方评审途径本条应描述为评审软件产品和活动,让需方或授权代表访问开发方和分承制方的一些设施要遵循的方法。
描述应遵循合同中论及它的所有条款。
6实施详细软件开发活动的计划本章分条进行描述。
不需要的活动用”不适用”注明,如果项目的不同的开发阶段或不同的软件需要不同的计划,则在本条应指出这些差异。
每项活动的论述应包括应用于以下方面的途径(方法/过程/工具):
1)所涉及的分析性任务或其它技术性任务:
2)结果的记录:
3)与交付有关的准备(如果有的话)。
论述还应标识存在的风险和不确定因素,及处理它们的计划。
如果适用的方法在5.2.1处描述了的话,可引用它。
6.1项目计划和监督本条分成若干分条描述项目计划和监督中要遵循的方法。
各分条的计划应覆盖合同中论及它的所有条款。
6.1.1软件开发计划(包括对该计划的更新)6.1.2CSCI测试计划6.1.3系统测试计划6.1.4软件安装计划6.1.5软件移交计划6.1.6跟踪和更新计划,包括评审管理的时间间隔,6.2建立软件开发环境本条分成以下若干分条描述建立、控制、维护软件开发环境所遵循的方法。
各分条的计划应覆盖合同中论及它的所有条款。
6.2.1软件工程环境6.2.2软件测试环境6.2.3软件开发库6.2.4软件开发文档6.2.5非交付软件,6.3系统需求分析6.3.1用户输入分析6.3.2运行概念6.3.3系统需求6.4系统设计6.4.1系统级设计决策6.4.2系统体系结构设计,6.5软件需求分忻本条描述软件需求分析中要遵循的方法。
应覆盖合同中论及它的所有条款。
6.6软件设计本条应分成若干分条描述软件设计中所遵循的方法.各分条的计划应覆盖合同中论及它的所有条款。
6.6.1CSCI级设计决
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 计算机软件 文档 编制 规范 修改 底版
![提示](https://static.bingdoc.com/images/bang_tan.gif)