金融知识系列介绍

binss

（6）数据要求说明书
数据要求说明书是为了向整个开发过程提供关于被处理数据的描述和采集要求等的技术信息，以便生成和维护这些数据。主要内容应包括：引言；数据的逻辑描述及数据采集。详细内容及编写格式参见GB8567—88。
(7) 概要设计说明书
概要设计说明书也可称为“系统（或子系统）设计说明书”。其目的是说明一个软件系统的设计考虑，包括该软件系统的基本处理流程、系统的组织结构设计、接口设计、运行设计、数据结构设计和出错处理设计等。为程序的详细设计提供基础。
当一个软件系统的规模相当大时，往往划分成几个子系统。此时，应编制各子系统的概要设计说明书。
详细内容及编写格式参见GB8567—88。
（8）详细设计说明书
详细设计说明书也可称为“程序设计说明书”。其目的是说明软件系统中各个层次的每一个程序（每个模块或子程序）的设计考虑。如果一个系统比较简单，层次很少，则本文件可与概要设计说明书合并编写。主要内容应包括：引言；程序系统的组织结构及各程序模块的设计说明。编写格式参见GB8567—88。
（9） 数据库设计说明书
数据库设计说明书的目的是为设计软件系统所使用的数据库，以便具体建立这个数据库。如果该软件系统要使用的数据库不止一个，则应对每一个待建立的数据库编制一份数据库设计说明。主要内容应包括：引言；外部设计；结构设计；运用设计。编写格式参见GB8567—88。
（10）用户手册
用户手册应使用非专门术语的语言充分描述本软件系统所具有的功能及基本使用方法。使得用户（或潜在用户）能通过本手册了解本软件的用途，并能确定在什么情况下应如何使用它。主要内容应包括：引言；用途；运行环境；使用过程等。编写格式参见GB8567—88。

binss

操作手册
操作手册的作用是向操作人员提供本软件系统的每一个运行的具体过程和有关知识，包括操作方法的细节。主要内容有：引言；软件概述；安装与初始化；运行说明；非常规过程及远程操作。编写格式参见GB8567—88。
（12）模块开发卷宗
模块开发卷宗是在开发过程中逐步编写出来的。每审查完一个模块或一组密切相关的模块后编写一份。应该把所有的模块开发卷宗汇集在一起。编写本文件的目的是记录和汇总低层次开发的进度和结果，以便对整个模块开发工作进行管理和复审，并为将来的维护工作提供有用的技术信息。主要内容应包括：引言；模块开发情况表；功能说明；设计说明；源代码清单及本模块的修改历史；测试说明及复审。详细编写格式参见GB8567—88。
（13） 测试计划
为提高检测出错几率，使测试能有计划地、有条不紊地进行，必须编写测试文档标准化的测试文档就如同一种通用的参照体系，是为软件管理人员、开发人员、维护人员、质量保证人员、审计人员及用户提供的便于交流的工具和手段。测试文档主要包括：
1、        测试计划
2、        测试分析报告
测试计划文档是进行软件系统组装测试和确认测试的计划。包括每项测试活动的内容、进度和安排、设计考虑、测试数据的整理方法及评价准则等。编写格式参见GB9386—88《计算机软件测试文件编制规范》和GB8567—88。
（14）测试分析报告
测试分析报告以文件形式记载组装测试和确认测试的结果、发两年问题及其分析。内容应包括：引言；测试概要；测试结果及发现；对软件功能的结论；分析摘要及测试资源消耗。编写格式参见GB9386—88和GB8567—88。
（15） 开发进度月报
开发进度月报的目的是及时向有关管理部门汇报项目开发的进度和情况，以便及时发现和处理开发过程中的问题。开发进度月报一般以项目组为单位（当软件系统规模比较大时，则以分项目组为单位）编写。内容应包括：标题；工程进度与状态；资源耗用状态；经费开支状态；下个月的工作计划及建议。编写格式参见GB8567—88。

binss

项目开发总结报告
项目开发总结报告是为了总结本软件项目开发工作的经验与教训，说明实际取得的开发结果以及对整个开发工作各个方面的评价。主要内容应包括：引言；实际开发结果；开发工作评价；经验教训等。编写格式参见GB8567—88。
11．3．2 软件质量保证计划
11．3．2．1 软件质量保证计划的作用
软件是计算机程序、数据及其相关文档的总称。软件质量是指这些计算机程序、数据及其文档满足预定的需求说明的程度，以及它们的完备性和相互之间的一致性情况。为便于制定软件质量保证计划，表11-3-3给出了决定软件质量的质量因素及定义。

binss

表11-3-3 软件质量因素定义
质量因素        定义
功能度        是指软件执行一系列与用户所说明及同说明有关需求相一致的功能的能力
可靠性        是指在规定条件下，在规定时间内，不引起系统失效的概率
可理解性        是指软件具有使用户容易理解、掌握、使用或评价该软件的能力
时间经济性        是指在规定或隐含的条件下，软件在适当的时间范围内，完成规定功能的能力
资源经济性        是指在规定和隐含的条件下，软件能用适当的资源完成规定功能的能力
可维护性        是指对已交付的软件进行修改的方便程度
可移植性        是指从一个环境转到另一个环境运行的能力。环境包括组织环境、硬件环境与软件环境
保密性        是指软件系统内部信息，不被非授权人误用、盗用或破坏的能力
完整性        是指对软件或数据所受到的未经获准的存取或修改可加以控制的程度
可再用性        是指整个软件或软件的一部分，可以被其他软件利用的能力
可连接性        是指整个软件或软件的一部分与其他软件或其他系统进行连接的难易程度
风险        是指按预定的成本和进度把系统开发出来，并且为用户所满意的程序（概率）
健壮性        是指硬件发生故障、输入的数据无效或操作错误等意外环境下，系统都能做出适当响应的程度
可用性        是每时系统在完成预定应该完成的功能时令人满意的程度
适应性        是指修改或改进正在运行的系统需要的工作量的多少
可测试性        是指软件容易测试的程度
互运行性        是指把该系统和另一个系统结合起来需要的工作量的多少

binss

软件质量保证是采用系统工程方法评审或检查软件产品是否满足需求说明所要求的软件系统的功能和性能。主要由评审、测试和管理决策等三方面的工作组成。
要保证软件质量，就必须在软件开发/生产全过程的任何阶段全面注意、有效控制软件产品的各种性能。因此，必须制定科学的易于执行的软件质量保证计划，把确保软件产品最后质量的要求变成一步步可以控制、可以具体执行的各项工作，以便尽早发现影响产品质量的隐患，防止直到最后才发现软件产品不能满足需求而推倒重来的被动局面。
在编制软件质量保证计划中，采用下列缩写词：
（1）        DDR详细设计评审（detailed Design Review）
（2）        PDR概要设计评审 (Preliminmary Design Review)
（3）        SDS软件设计说明 (Software Design Specification)
（4）        SQA软件质量保证 (Software Quality Assurance)
（5）        SQAP软件质量保证计划 (Software Quality Assurance Plan)
（6）        SRR软件需求评审 (Software Requirements Review)
（7）        SRS软件需求说明 (Software Requirements Specification)
（8）        SVVP软件验证与确认计划 (Software Verification and Validation Plan)
（9）        SVVR软件验证与确认报告 (Software Verification and Validation Report)

binss

软件质量保证计划大纲及描述
软件质量保证计划规定项目承办单位必须准备一个包括下列各条内容的SOAP（简称计划）。以确保按项目或合同要求开发软件或以其他方式提供软件。计划中各条必须按给定的顺序排列，如有增删，应在相应的位置上附上增删的理由。
SQAP应当有一个封面，在封面上必须写明文档是“软件质量保证计划”，并写明该计划所属的软件项目的名称、计划拟定者、计批准人及批准日期。下面分别描述计划每一部分的详细需求。
（1）        引言
本条必须写明计划的总意图。
1、        目的：必须指明特定的SQAP的具体目的。
2、        范围：必须描述计划所针对的软件项目的名字和该软件的预期用途。
3、        定义和缩写词：应该列出计划中用到的、需要恰当解释的或在国家标准GB/T11457—89《软件工程术语》中尚未包含的术语和定义，必要时，还要给出它们的英文和缩写词。
4、        参考资料：必须提供SQAP中引用的所有资料的清单及这些参考资料的来源。
（2）        管理
本条必须描述SQA的机构、任务、职责和权限。
1、        机构：必须列出与SQA有关的机构的名称、组成、分工以及各部门之间的相互关系。
2、        任务：必须描述计划所涉及的软件生存周期中有关阶段的任务和这些阶段中的软件质量保证活动。
3、        职责和权限：必须指明负责每一个任务的机构，以及具体职责和权限。表11-3-4简述一个软件产品在开发过程中为保证软件产品质量的管理机制。

binss

（3）        文档
必须给出在软件的开发、验证和确认、以及使用和维护各阶段所用到的文档的定义，并描述核实这些文档适用性的办法。
1、        最小文档需求：为了确保软件的实现满足预定需求，规定至少需要下列文档：
A 软件需求说明（SRS）：SRS必须清楚、准确地按照国家标准GB9385《计算机软件需求说明编制指南》编写。
B 软件设计说明（SDS）：SDS包括概要设计和详细设计说明。SDS必须清楚、准确地按照国家标准GB8566—88和GB8567—88编写。
C 软件验证和确认计划（SVVP）：SVVP必须描述用来验证SRS中的需求已由SDS表达的设计所实现、SDS表达的设计已由编码所实现的方法。SVVP还必须描述用以确认编码的执行与SRS表达的需求相一致的方法。
D 软件验证和确认报告（SVVP）：SVVP必须描述SVVP的执行结果，包括SQAP所需要的所有评审、检查和测试结果。
E 用户手册和操作手册：必须清楚、准确地按照国家标准GB8567—88编写。
2、        其他文档。本条应列出可能包括的能够反映软件质量的其他文档。

binss

（4）        评审和检查。本条必须制定评审和检查的规程。规定评审和检查的内容、组织形式、进度安排以及评审组织和项目承办单位的职责。评审是由有关专业人员或用户通过正式会议，评价软件需求，软件设计等文档。检查是由专业人员检查程序、文档等是否符合有关的技术规程或约定。
1、        在SQAP中应制定审查基线（结束标准）。
2、        在SQAP中应确定审查小组成员。
3、        在SQAP中应至少包括下列可能的步骤；
A 计划：组织审查组，分发材料，安排日程等。
B 概貌介绍：对该软件项目的功能、性能的简介。
C 准备：评审员阅读材料取得有关项目的知识。
D 评审会：目的是发现和记录错误。
E 返工：作者修正已经发现的问题。
F 复查：判断返工是否真正解决了问题。
4、        在SQAP中应制定复查和管理复查的计划：
A 复查：检查已有的材料，以断定各阶段的工作是否能够开始或继续。
B 管理复查：向开发组织或用户的管理人员，提供有关项目的总体状况、成本和进度等方面的情况。
5、        要进行的评审和检查的最小需求是：
A 软件需求评审（SRR）。进行SRR的目的是确保在SRS中的需求的合适性。
B 概要设计评审（PDR）。进行PDR的目的是确保SDS中软件概要设计部分在技术上的合理性。
C 详细设计评审（DDR）。进行DDR的目的是确保SDS中软件详细设计部分模块功能的正确性；控制结构、数据结构和算法的合理性；以及设计的程序与需求的一致性。
     D 软件验证和确认评审。本评审是评价SVVP中定义的验证和确认方法的合适性与完备性。
     E 功能检查。确认要交付的软件已经满足在SRS中规定的所有需求。
     F 物理检查。对软件产品的各个部件的设计进行抽样的综合检查，以验证编码与设计文档的一致性、接口说明的一致性、设计实现与功能需求的一致性、以及功能需求与测试描述的一致性。
     G 综合检查。对软件产品的各个部件的设计进行抽样的综合检查，以验证编码与设计文档的一致性、接口说明的一致性、设计实现一功能需求的一致性、以及功能需求与测试描述的一致性。
     H 管理评审。定期地进行管理评审，以评价计划的执行情况。这些评审必须由独立于被评审单位的机构或授权的第三方进行。
6、        基本测试。本条必须制定要做的基本测试。测试过程中要产生如下文档：
A 测试计划
B 测试分析报告

binss

（5）        问题报告、修正活动和配置管理。本条必须制定对软件的问题和缺陷进行检测、记录和修改的规程，并说明执行规程的机构和职责。规定应当包括如下内容：
A  向有关管理部门提交问题和缺陷的报告；
B  分析问题和缺陷的影响范围及产生原因；
C  评审修改结果；
D  分析或评审修改活动对项目或合同条款的影响。
E  实施软件配置管理计划。
（6）        质量记录和质量报告。
1、        项目承办单位必须准备和维护各阶段质量评价记录，并把这些记录妥善保存。
2、        项目承办单位必须准备各种质量报告，以使能对质量评价的结果和推荐意见进行管理。质量报告是质量评价的结果和推荐意见的总结报告。应视为一种文档保存。
3、        各阶段的质量记录和质量报告是最终质量检查的依据。

binss

（7）        工具、技术和方法。本条必须描述支持特定项目的SQA的专用软件工具、技术和方法。
（8）        代码控制。本条必须定义用以维护和存储软件受控版本的方法和设施。
（9）        介质控制。本条必须指出用于保护存放计算机程序、数据及其文档的物理介质的方法和设施。
（10）        对项目承办单位的控制。如果项目承办单位用购买软件或委托子承办单位去获取软件，则本条必须列出确保软件销售单位提供的、或子承办单位获得的软件满足规定的技术需求的条款。软件销售单位或子承办单位至少必须准备一个与本规范一致的SQA计划。
（11）        记录的收集、维护和保存。本条必须指明要保留的SQA文档；必须指出用于汇总、保护和维护这些文档的方法和设施；并指明要保留的时间。
（12）        交付的准备工作。本条必须引用或制定一个规程，以确保软件产品在处理、存贮、保管、包装和运输过程中的安全和完整性。