软件开发规范Word文件下载.docx
- 文档编号:21439536
- 上传时间:2023-01-30
- 格式:DOCX
- 页数:60
- 大小:46.34KB
软件开发规范Word文件下载.docx
《软件开发规范Word文件下载.docx》由会员分享,可在线阅读,更多相关《软件开发规范Word文件下载.docx(60页珍藏版)》请在冰豆网上搜索。
计算机程序中模块之间相互依赖的量度。
2.7
标识和确定系统中配制项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配
置项的状态和更动要求,验证配置项的完全和正确性。
2.8MODULARDEVELOPMENTFOLDER
模块开发卷宗是在模块开发过程中逐步编写出来的。
每完成一个模块或一组密切相
关模块的复审时编写一份。
在实现阶段结束时,应把所有的模块开发卷宗汇集在一起,
以便于对整个模块开发工作进行管理和复审,为将来的维护工作提供有用的技术信息。
3.
本规范将软件生存周期划分以下几个阶段:
可行性研究与计划
需求分析
概要设计
详细设计
实现
组装测试
确认测试
使用和维护
4.
约定:
甲方:
软件使用部分
乙方:
软件开发部门
4.1
乙方有责任保证软件设计完全满足可行性研究报告中规定的所有技术要求,未经甲方同意不得修改
要求,设计功能的复杂性和功能模块相互间的相关性必须降低到最低限度。
4.2
应避免在设计沿未完成的情况下就急于编码的错误倾向。
实现时应采用符合国家标准或国际标准的
程度设计语言。
应尽量采用结构化方法,使开发的软件具有良好的、清晰的结构。
4.3
乙方必须全面完成所规定的测试(包括单元测试、组装测试、确认测试),向甲方提供准确和完整
的测试结果报告。
必要时,甲方可委托第三方进行确认测试。
4.4
甲、乙双方都必须把软件质量保证放在重要地位并制定软件质量保证计划,以确保完全遵守需求说
明中规定的所有的软件要求。
为保证软件质量,乙方必须采用审查、文件评审、设计评审、审计、测试
等具体手段。
4.5
2
GB
确认测试必须按双方协议执行,确认测试通常在实际或模拟环境中实施,测试结果报告所说明的情
形与软件要求不完全一致的偏差程度,必须限于正式批准认可的范围内。
4.6
乙方必须制订并执行配置管理规程,以便说明要管理的软件成分、定义及其修改的状态,同时要保
证程序与其他文件完全一致。
当乙方提出和修改影响到甲方的其他软件时必须取得甲方同意。
4.7
乙方必须设置或指定软件开发管理组织,实施对软件开发过程与资源的管理,并要制订执行一些规
程,用来控制软件开发的整个过程,必须定期向有关部门和甲方提供工作进展情况。
4.8
文件编制应以乙方为主,在编制过程中应充分听取甲方意见,使用的语言应通俗,无歧义,文件格
式应按照GB8567-88进行书写,在开发过程中可根据系统的规模对文件的内容进行增删。
5.
5.1
5.1.1任务
了解客户的要求及现实环境,从技术、经济和社会因素等三个方面研究并论证本软件项目的可行性,
编写可行性研究报告,制定初步项目开发计划。
5.1.2实施步骤
5.1.2.1软件开发部门的分析人员对客户要求及现实环境进行调查。
5.1.2.2在调查研究的基础上编写有关客户提出的问题的书面材料。
5.1.2.3依据书面材料及其有关资料对待开发的系统从经济、技术及社会因素等方面进行可行性研究,
写出可行性报告。
5.1.2.4评审和审批,决定项目是取消还是继续。
5.1.2.5若项目可行,则制订初步的项目开发计划,并根据需要签署合同。
5.1.3实施要求
5.1.3.1经济可行性应是优先考虑的问题,它包括成本/效益分析、长期的经营策略等。
5.1.3.2估计成本/效益应有确切的数据和估算方法,避免主观臆断。
5.1.4完成标志
5.1.4.1成本/效益分析应提供几种可供选择的解答。
5.1.4.2项目开发计划中应具有明确的、可检查的标志。
5.1.4.3所指定的文件要齐全,可验证。
应交付的文件有:
a.可行性研究报告;
b.初步的项目开发计划。
5.2
5.2.1任务
确定被开发软件的运行环境、功能和性能要求,编写用户手册概要和确认测试准则,为概要设计提
供需求说明书。
5.2.2实施步骤
5.2.2.1调查被开发软件的环境。
5.2.2.2进一步明确客户和用户需求。
5.2.2.3确定入机界面。
5.2.2.4修改初步的项目开发计划。
5.2.2.5制订确认测试计划。
3
5.2.2.6编写用户手册概要。
5.2.2.7评审。
5.2.3实施要求
5.2.3.1必须以运行环境为基础。
5.2.3.2应该要有客户所指定的人员参加。
5.2.3.3需求说明书必须明确,并经过客户确认。
5.2.4完成标志
所指定的文件要齐全,并经过评审。
a.软件需求说明书;
b.修改后的项目开发计划;
c.用户手册概要;
d.确认测试计划;
e.数据要求说明书。
5.3
5.3.1任务
根据软件需求说明,建立目标系统的总体结构和模块间的关系,定义各功能模块的接口、控制接口。
设计全局数据库/数据结构,规定设计限制,制订组装测试计划。
5.3.2实施步骤
5.3.2.1建立目标系统的总体结构:
a.对于大型系统,可按主要的软件需求牙分成子系统,然后为每个子系统定义功能模块及各功能模
块间的关系。
b.对于一般系统,可按软件需求直接定义目标系统的功能模块及各功能模块间的关系。
5.3.2.2给出每个功能模块的功能描述,数据接口描述,外部文件及全局数据定义。
5.3.2.3设计数据库或数据结构。
5.3.2.4制订组装测试计划。
5.3.2.5评审。
5.3.3实施要求
5.3.3.1在设计目标系统的整体结构时,应力争使其具有好的形态,各功能模块间应满足低耦合度,而
各功能模块内应满足高内聚度。
功能模块的作用范围应在其控制范围之内。
5.3.3.2在设计目标系统的总体结构时,应降低模块接口的复杂性,提高目标系统的可移植性。
5.3.4完成标志
5.3.4.1所有已定义的软件需示均被所设计的系统覆盖。
5.3.4.2建立了系统的结构,明确指出系统各模块的功能、模块间的层次关系及接口控制征。
5.3.4.3所指定的文件要齐全,可验证。
应交附的文件有:
a.概要设计说明书;
b.数据库/数据结构设计说明书;
c.组装测试计划。
5.4
5.4.1任务
对概要设计中产生的功能模块进行过程描述,设计功能模块的内部细节,包括算法和数据结构,为
编写源代码提供必要的说明,建立“模块开发卷宗”。
5.4.2实施步骤
5.4.2.1将概要设计产生的构成软件系统的各个功能模块逐步细化,形成若干个程序模块(可编程模块)。
4
8566-88GB
5.4.2.2采用某种详细设计表示方法对各个程序模块进行过程描述。
5.4.2.3确定各程序模块之间的详细接口信息。
5.4.2.4建立“模块开发卷宗”。
5.4.2.5拟定模块测试方案。
5.4.2.6评审。
5.4.3实施要求
5.4.3.1确定程序模块内的数据流或控制流,对每个程序模块必须确定所有输入、输出和处理功能。
5.4.3.2规定符号的使用,确定命名规则。
5.4.3.3尽可能按结构化程序设计原则进行设计。
5.4.4完成标志
5.4.4.1详细地规定了各程序模块之间的接口,包括参数的形式和传送方式、上下层的调用关系等。
5.4.4.2确定了模块内的算法及数据结构。
5.4.4.3所指定的文件要齐全,可验证。
a.详细设计说明书;
b.模块开发卷宗。
5.5
5.5.1任务
将详细设计说明转化为所要求的程序设计语言或数据库语言书写的源程序。
并对编写好的源程序进
行程序单元测试,验证程序模块接口与详细设计说明的一致性。
5.5.2实施步骤
5.5.2.1对每个程序模块用所选定的程序设计语言进行编码。
5.5.2.2按照测试方案产生测试数据。
5.5.2.3按照测试方案中规定的方法进行程序单元测试。
5.5.2.4书写“模块开发卷宗”中相应于该阶段的内容。
5.5.2.5编写操作手册和用户手册。
5.5.2.6评审。
5.5.3实施要求
5.5.3.1尽可能使用符合国家标准或国际标准的程序设计语言。
5.5.3.2为了提高程序的可理解性。
应在源程序中加入适当的注解。
5.5.3.3尽量采用增加程序可读性的排版格式。
5.5.3.4不仅要考虑对合法的输入产生测试用例,而且要对非法的、非预期的输入产生测试用例。
既要对
正常的处理路径进行测试,预期结果及测试结果应存档保留。
5.5.4完成标志
所指定的文件要齐全,可验证。
a.模块开发卷宗
5.6
5.6.1任务
根据概要设计中各功能模块的说明及制定的组装测试计划,将经过单元测试的模块逐步进行组装和
测试。
5.6.2实施步骤
5.6.2.1执行测试计划中所有要求做的组装测试。
5.6.2.2分析测试结果,找出产生错误的原因。
5.6.2.3提交组装测试分析报告,以便尽快修改错误。
5
5.6.2.4评审
5.6.3实施要求
5.6.3.1组装测试应保证模块间无错误的连接。
5.6.3.2应对软件系统或子系统的输入/输出处理进行测试,使其达到设计要求。
5.6.3.3应测试软件系统或子系统正确处理能力和经受错误的能力。
5.6.4完成标志
所指定的文件要齐全,测试结果符合要求,并通过评审。
a.可运行的软件系统源程序清单;
b.组装测试分析报告。
5.7
5.7.1任务
根据软件需求说明书中定义的全部功能和性能要求及确认测试计划整个软件系统是否达到了要求。
并提交最终的用户手册和操作手册。
5.7.2实施步骤
5.7.2.1在模拟的环境中进行强度测试,即在事先规定的一个时期内进行软件的所有功能,以证明该软
件无严重错误。
5.7.2.2执行测试计划中提出的所有确认测试。
5.7.2.3使用用户手册和操作手册,以进一步证实其衫性和有有效性,并改正其中的错误。
5.7.2.4分析测试结果,找出产生错误的原因。
5.7.2.5书写确认测试分析报告。
5.7.2.6确认测试结束后,书写整个项目的开发总结报告。
5.7.2.7对所有文件进行整理。
5.7.2.8评审。
5.7.3实施要求
5.7.3.1必须邀请客户一起参加确认测试。
5.7.3.2全部系统存储量、输入及输出通道,以及处理时间必须有足够的余量。
5.7.3.3对于一次操作时间长于24h的系统来说强度测试的最少时间须是25h,对于一次操作时间短于24h
的系统来说,则最少测试时间是完成该任务所需时间与完成本标准的测试要求的时间之较长者。
5.7.3.4全部预期结果、测试结果及测试数据应存档保留。
5.7.3.5建立独立的测试小组进行确认测试。
5.7.4完成标志
a.确认测试分析报告;
b.最终的用户手册和操作手册;
c.项目开发总结报告。
5.8
5.8.1任务
对投入运行后的软件系统进行修改,以改正在开发阶段产生、在测试阶段又未发现的错误,使软件
系统能适应外界环境的改变,并实现软件系统的功能扩充和性能改善。
5.8.2实施步骤
5.8.2.1软件系统的用户或维护人员根据软件系统出现的错误、产生的问题或情况的变化向维护管理人
员提交“软件修改报告”。
5.8.2.2由维护管理人员对“软件修改报告”进行评审,并赋予优先级。
6
5.8.2.3维护人员分析维护需求。
对解决该修改所需的时间与资源进行估计。
5.8.2.4按照一定的步骤对程度进行修改或扩充。
5.8.2.5重新测试被修改过的程序。
5.8.2.6修改所有有关的文件。
5.8.2.7通知用户修改已完成,并将修改以后的版本提交给用户。
5.8.2.8评审。
5.8.3实施要求
5.8.3.1软件维护必须在严格的管理控制下进行。
避免错上加错的情况出现。
5.8.3.2尽量避免出现修改的副作用,在修改前应权衡利弊,全面考虑。
5.8.3.3在有效的控制管理下,有步骤地进行修改,修改后的软件须通过测试,填写“软件修改报告”(包
括错误类型、修改策略、修改状态和修改情况)。
5.8.4交付文件
a.软件问题报告(见附录A)。
b.软件修改报告(见附录B)。
(补充件)
7
登记号:
A
B登记日期:
软件问题报告
C时间:
单元组装确认运行7123456状态ED
测试测试测试维护
姓名报告人F电话地址
程序数据库文件G问题:
HIJ子程序/子系统:
修订版本号:
磁带:
LK数据库:
文件:
MN测试用例:
硬件:
问题描述/影响:
O
附注:
P
“软件问题报告”中和项含义解释:
A.
由软件配置控制部门为该报告规定一个唯一的、顺序的编号。
B.
软件配置控制部门登记该报告的日期。
C.
发现该问题的日期的时间。
D.
在哪个阶段发现的问题,分为单元测试、组装测试、确认测试和运行维护四个阶段。
E.
这是在软件配置记录中维护的动态指示。
它在“软件问题报告”中的作用是为了让开发者和测试者
追溯和向软件配置控制部门报告最新的状态。
状态表示如下:
1——“软件问题报告”正被复查,以确定采用什么行动。
2——“软件问题报告”已由指定的开发人员去进行处理。
8
GB8566-88
3——修改已做完,测试好,正准备交给主程序库。
4——主程序库已经更新,主程序库修改的重新测试尚未完成。
5——测试重做,所做的修改无故障,“软件问题报告”被关闭。
6——留待以后关闭,因问题不是可重产生的,或者是属于产品改善方面的,或者只具有很低的优
先级等等。
F.
“软件问题报告”填写者的姓名、地址、电话。
G.
区分是程序的问题还是子程序的问题,或是数据库的问题,文件的问题,文件的问题。
也可能是它
们的某种组合。
H./
出现问题的子程序的名字。
如果不知是哪个子程序,可标出子系统名,总之,尽可能给出细节。
I.
出现问题的子程序版本。
J.
包含有问题的子程序的主程序库磁带的标识符。
K.
当发现问题时所使用的数据库标识符。
L.
有错误的文件编号。
M.
出现错误的主要测试用例的标识符。
N.
发现问题时所使用的计算机系统的标识。
O./
问题征兆的详细描述,如果可能则写明实际问题所在。
也要给出该问题对将来测试、接口软件和文
件等的影响。
P.
记载补充信息。
9
软件修改报告
DE报告人:
F子系统名:
子程序名:
响应哪些“软件问题报告”G
文件解释H程序数据库修改:
I修改描述:
J批准人
修改:
K语句类型:
I/O计算逻辑数据处理
LMN程序名:
老版本号:
新版本号:
OPQR数据库:
数据库修改报告文件夹:
文件更新:
修改已测试否?
成功否?
单元子系统组装确认运行S
T“软件问题报告”的问题叙述准确否:
是否
U附注:
V问题来自软件需求说明书设计说明书数据库程序
W资源估计:
人时数:
计算机时间:
“软件问题报告”中各项含义解释:
它是软件配置控制部门在收到“软件修改报告”时指定的“软件修改报告”的编号。
软件配置控制部门登记“软件修改报告”的日期。
准备好“软件修改报告”的时间。
填写该报告的作者。
10
受修改影响的子系统。
被修改的子程序名字。
G.
被“软件修改报告”处理或部分处理的“软件问题报告”的编号。
如果某“软件问题报告”的问题只是部分解决,则在编号后附以字母P,如1234(P)。
H.
包括程序修改、文件更新、数据库修改或它们的组合。
如果该“软件修改报告”对“软件问题报告”
的处理只需解释性工作,这里将指出。
解释多半是针对用户文件的缺陷,但这也将导致用户文件更新。
修改的详细描述。
如果是文件更新或数据库修改,还要列出文件更新通知或数据库修改申请的标识
号。
批准人签字,正式批准进行修改。
K.
程序修改中涉及到的语句类型,包括:
输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类(如数据传送、存放语句)。
被修改的程序、文件或数据库的名字。
如果只要求“软件修改报告”做解释性工作,则是重复“软
件问题报告”中给出的名字。
当前的版本/修订本标识。
修改后的新版本/修订本标识。
O.
如果申请数据库修改,这里给出数据库的标识符。
P.
数据库修改申请号。
Q.
如果也要求文件修改,这是给出它的名字。
R.
文件更新通知单编号。
S.
指出已对修改做了哪些测试,如单元、子系统、组装、确认和运行测试等,并注明测试成功与否。
T.U.
准确地重新叙述要维护的问题。
V.
指明问题来自于哪里,如软件需求说明书、设计说明书、数据库、源程序等。
W.
完成修改所需的资源估计,即总的人时数和计算机时间的开销。
11
12
一项计算机软件的筹划、研制及实现,构成一个软件开发项目。
一个软件开发项目的进行,一般需
要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功,最经济地花费这些投资,并且
便于运行和维护,在开发工作的每一阶段,都需要编制一定的文件。
这些文件连同计算机程序及数据一
起,构成为计算机软件。
文件是计算机软件中不可缺少的组成部分,它的作用是:
a.作为开发人员在一定阶段内的工作成果和结束标志;
b.向管理人员提供软件开发过程中的进展和情况,把软件开发过程中的一些“不可见的”事物转
换成“可见的”文字资料。
以便管理人员在各个阶段检查开发计划的实施进展,使之能够判断原定目标
是否已达到,还将继续耗用资源的种类和数量;
c.记录开发过程中的技术信息,便于协调以后的软件开发、使用和修改;
d.提供对软件的有关运行、维护和培训的信息,但于管理人员、开发人员、操作人员和用户之间
相互了解彼此的工作;
e.向潜在用户报导软件的功能和性能,使他们能判定该软件能否服务于自己的需要。
换言之,本指南认为:
文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类:
一类是开发过程中填写的各种图表,可称之为工作表格;
另一类
则是应编制的技术资料或技术管理资料,可称之为文件。
本指南规定软件文件编制形式,并提供对这些
规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2.
本指南是一份指导性文件。
本指南建议,在一项计算机软件的开发过程中,一般地说,应该产生十
四种文件。
这十四种文件是:
可行性研究报告;
项目开发计划;
软件需求说明书;
数据要求说明书;
概要设计说明书;
详细设计说明书;
数据库设计说明书;
用户手册;
操作手册;
模块开发卷宗;
测试计划;
测试分析报告;
13
8567-88
开发进度月报;
项目开发总结报告。
本指南将给出开发过程中建议产生的这十四种文件的编制指导,同时,本指南也是这十四种文件的
编写质量的检验准则。
但是,本指南并未涉及软件开发过程中如何填写工作表格的问题。
一般地说,一个软件总是一个计算机系统(包括硬件、固件和软件)的组成部分。
鉴于计算机系统
的多样性,本指南一般不涉及整个系统开发中的文件编制问题,本指南仅仅是软件开发过程中的文件编
制指南。
对于使用文件的人员而言,他们所关心的文件的种类,随他们
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 规范
![提示](https://static.bdocx.com/images/bang_tan.gif)