| ·系统分析： | 研究用户要求以得到系统或软件要求的定义的过程。对系统或软件要求的验证 |
| ·系统设计： | 为系统定义硬件和软件结构、组成成分、模块、接口及数据，以满足规定的系统要求的过
程。 |
| ·软件： | 计算机程序和相应的数据和文档，包括固件中的程序和数据，而与其驻留的物理介质无
关。 |
| ·软件开发： | 指任务书或合同生效之日开始，到承办单位交付产品并由交办单位验收为止的整个软件
研制、生产过程。 |
| ·软件开发周期： | 从决定开发一个软件产品开始，到产品交付为止的时间间隔。这个周期典型地包括软件
需求定义、软件需求分析、软件设计、编程和测试五个阶段。 |
| ·软件生存周期： | 从设计软件产品开始，到产品不能再使用为止的时间周期。软件生存周期典型地包括系
统分析阶段、要求定义阶段、设计阶段、编程序阶段、测试阶段、安装和验收阶段，以及操作(使
用)和维护阶段。 |
| ·软件错误报告： | 当软件不符合开发基线或要求时提出的报告。 |
| ·支持软件： | 所有用于帮助和支持开发的软件。 |
| ·应用软件： | 解决属于专用领域的、非计算机本身问题的软件。 |
| ·程序： | a.适合于计算机处理的指令序列；
b.工作次序表。 |
| ·程序结构分层： | 程序结构分为程序、分程序、模块和程序单元四个层次。程序指软件中可以独立运行、执
行完整功能的指令集合；分程序指程序中的一个主要功能子集，它由一个或多个模块组成；模
块指可以单独编译的软件部分，它由一个或多个程序单元组成。 |
| ·程序(或软件)设计： | 程序(或软件)的设计工作指的是程序(或软件)划分成若干分程序和模块；将程序的功能
分配给个分程序和模块；接口设计；测试计划的制订等。 |
| ·程序编制： | 指将程序设计结果转换成代码。 |
| ·程序错误： | 程序执行期间发生的错误，包括：程序不满足指定的软件需求；程序与先前的设计不一致；
程序执行异常。 |
| ·程序中止： | 指程序执行时任-意外的停止。 |
| ·数据： | 以形式化方法，用适合于人或自动工具通信、解释或处理的形式，对事实、概念或指令进行
的一种表示。 |
| ·数据结构： | 数据项之间的次序安排和可访问性的一种形式表示，其中不涉及其实际存储排列方法。 |
| ·数据库： | 对于系统来说是基本的数据集合。 |
| ·文件： | 作为-个单位来看待的-组相关的记录。 |
| ·模块： | 它是分程序中一个能逻辑地分开的、可独立编译的部分。它可以由一个或多个单元组成。 |
| ·单元： | 单元就是程序单元，它是在设计中所规定的最小逻辑实体。单元以充分详细的方式完整
地描述某一功能，允许独立于其它单元而产生、测试其执行代码。.单元是以代码形式实现的物
理实体。 |
| ·参数： | 指在软件中一些可以给出具体数值的物理量或逻辑量，它们的值，在系统设计或代码执行
的全过程中，恒为常数，如传感器输出的限制、防御的最大范围、处理事件的最大数量、数据存
贮限制、有效设备的最大数目等，都是设计中和甩代码实现设计中的参数例子。 |
| ·流程图： | 在软件开发中，用于问题的定义和分析的图形工具。在流程图里，符号用来表示操作数
据、流程和设备等。 |
| ·降级执行方式： | 降级执行方式是系统降低性能运行的工作方式。由于设备发生故障，调整了配置，使系统
在低于原设计能力下运行。 |
| ·修补： | 对汇编或编译后的目标软件所做的修改。 |
| ·规程： | 为解决某-问题而采取的动作经过的描述。 |
| ·设计阶段： | 指软件生存周期中的一段时间，在这段时间内，产生体系结构、软件组成部分、接口和数据
的设计，为设计编制文档，并对其进行验证，以满足预定要求。 |
| ·编程阶段： | 指软件生存周期中的一段时间，在这段时间内，根据设计文档制造软件产品排除其中的错
误。 |
| ·测试阶段： | 指软件生存周期中的一段时间，在这段时间内，对软件产品的组成成分进行评价并将它们
结成整体，并评价软件产品以确定要求是否已得到满足。 |
| ·测试用例： | 它是为了特殊目的而发展起来的测试数据及与之相关的测试规程的一个特定的集合。 |
| ·软件综合测试： | 按一定的策略将程序单元逐个综合为特定的模块、分程序和程序，然后确定它们是否满足
有关功能、性能、操作要求，以及测试和维护要求。 |
| ·非正式测试： | 不符合软件综合测试要求的任何测试。 |
| ·代码逐步审查： | 由一组合格的专业人员按照确定的规程对软件设计进行的逐步和详细的审查。 |
| ·质量保证： | 为使某项目或产品符合已建立的技术要求，提供足够的置信度，而必须采取的有计划和有
系统的全部动作的模式。 |
| ·安全性： | 对计算机硬件、软件进行的保护，以防止其受到意外的或蓄意的存取、使用、修改、毁坏或
泄密。安全性也涉及对人员、数据、通信以及计算机安装的物理保护。 |
| ·完整性： | 在计算机系统中，对软件或数据所受到的未经获准的存取或修改可加以控制的程度。 |
| ·认证： | 一正式的权威机构根据可付诸实#的要求，以书面形式确定、验证和证明人员、过程、步骤
或条款为合格所采取的步骤和行动。 |
| ·验证： | 确定软件开发周期中的一个给定阶段的产品是否达到前阶段期间确立的要求的过程。 |
| ·检查： | 对程序执行情况进行人工模拟，用逐步详细检查源代码中有无逻辑或语法错误的办法，来
检查程序中的缺陷。 |
| ·审查： | 质量管理的一个阶段，在此阶段通过检查、观察或测量来确定软件产品是否符合预定的软
件要求。 |
| ·评审： | 在正式会议上，把软件开发各阶段的产品提交给交办单位、用户和有关人员，供其评审或
批准。 |
| ·文档： | 有关计算机软件的书面描述，它定义了软件的内容、组成、设计、性能、测试和使用方法。 |
| ·用户文档： | 一套文档，它为使用系统以期获得所希望结果的最终用户提供系统指令以及使用方式和
环境方面的信息。 |
| ·开发基线： | 开发基线是经交办单位同意的任务书或合同、说明书和其它～些文档，它确定了对被开发
软件开发各个阶段要求。开发基线在软件开发过程可以补充和修改，但必须经交办单位同意。 |
| ·文档编制： | 产生文档的一个过程 |
| ·任务交办单位： | 指具有下达任务书，签订合同，以及对项目有直接管理权限的政府机构或有关单位，它对
软件开发工作负有基本的责任和权限。 |
| ·任务承办单位： | 指接受交办单位下达的任务书，签订合同，完成开发(或用其它方式提供)软件全部或部分
工作的单位或个人。间接承办单位是指从承办单位接受任务或合同的单位。 |
| ·“必须”、“应当”、“要”： | 在海军软件规范的条款中出现的“必须”表示强制性的规定；“应当”表示非强制性的规定；
“要”表示希望。 |