软件工程领域中通用的术语(二)

软件工程领域中通用的术语(二)
　2.401 可重复性 rePeatability

　　参见 2.516条。

　　2.402 招标(标书)request for proposal [tender]

　　需方使用的一份文件，用来向潜在的投标人表示它要获得某特定系统、产品或服务的意图。

　　2.403需求 requirement

　　a.用户为解决某一问题或达到某个目标所需要的条件或能力。

　　b.系统或系统部件为满足或具有的条件或能力以满足合同、标准、规格说明或其它正式的强制性文件。所有需求的集合形成了以后开发系统或系统部件的基础。参见2.404条、2.406条。2.407条。

　　2.404需求分析 requirements analvaia

　　a.研究用户要求以得到系统或软件需求的定义的过程。

　　b.对系统需求或软件需求的验证。

　　2.405需求审查 requirements InsPection

　　参见2.237条。

　　2.406需求阶段 requirements phase

　　软件生存周期中的一个阶段。在此期间对软件产品的需求(如功能和性能方面的能力)进行定义并编制出相应的文档。

　　2.407需求规格说明 requirements specification

　　陈述系统或系统部件(例如，软件配置项)的需求的规格说明，通常包括功能需求、性能需求。接口需求、设计需求以及开发标准。

　　2.408需求的规格说明语言 requirements specification language

　　具有特殊构造和验证协议的形式语言，用于规定、验证和编制需求文件。

　　2.409需求验证 requirements verifcation

　　参见2.539条。

　　2.410退役 retirement

　　操作和维护机构撤出现有的支持，全部或部分地由一个新的系统来代替或者安装一个更新的系统。

　　2.411退役阶段 retirement Phase

　　软件生存周期中的一个阶段。在此阶段内，对软件产品的支持被终止。

　　2.412可重用性，复用率 reusability

　　一个模块可在多种应用中加以利用的程度。

　　2.413评审 review

　　参见2.142条。

　　2.414健壮性 robustness

　　尽管引入了不合理的输入，软件仍能继续正常运行的程度。

　　2.415根编译程序 root compiler

　　一种编译程序。其输出是与机器无关的中间表示。当它与依赖于机器的代码生成程序组合时，就构成了完整的编译程序。

　　2.416例行程序一，例程 routine

　　a.实现特定任务的一个计算机程序段。参见 2.213条、2.346条、2.482条、2.480条。

　　b.广泛或频繁使用的程序段，或由程序调用的指令序列。

　　2.417运行态，运行方式 run mode

　　当计算机正自动地执行着存储在存储单元中的指令，从而被认为是正在履行其功能时的那种状态。

　　2.418运行时间 run time

　　a.执行一个程序时所花费时间的度量。运行时间包括中央处理机时间、外围处理时间和外围存取时间，例如：sh的运行时间。

　　b.程序开始执行的瞬间。参见 2.188条。

　　2.419可扩展性 scaliability

　　是指软件系统可以在不同规模、不同档次的硬件平台上运行的能力。

　　2.420安全性，保密性 security

　　对计算机硬件、软件进行的保护，以防止其受到意外的或蓄意的存取、使用、修改、毁坏或泄密。

　　安全性也涉及对人圆劲数据、通信以及计算机安装的物理保护。

　　2.4 21 安全核心 security kernal

　　与安全性有关的关键性语句的一个小的、自含的集合，作为操作系统的特权部分。为了使用一程序或存取某数据，必须满足核心所规定的全部准则。

　　2.422撒播 seeding

　　参见2.201条。

　　2.423程序段，存储段，分段 segment

　　a.计算机程序中的独立部分，它可在任一时间执行而无需把整个计算机程序都保持在内存 中。参见2.77条、2.301条、2.480条。

　　b.在两个相邻转移分支点之间的计算机程序语句的序列。参见2.328条。

　　c.把计算机程序和数据分为若干段。

　　2.424语义 semantics

　　a.字符或字符组与其含义之间的关系。这种关系是与它们的解释和使用的方式无关的。

　　b.符号和它们的含义之间的关系。

　　c.按照元语言表达计算机语言结构的含义的规则。 参见2.489条。

　　2.425信号量 semaphore

　　用于同步并行进程的一种共享变量。它用来指明某动作是否已完成或某事件是否已发生。

　　2.426顺序进程 sequential processes

　　以这样一种方式执行的进程，即在下一个动作开始之前本动作必须结束。与2.90条相对照。

　　2.427服务(软件) service(software)

　　与软件有关的活动、工作或义务的实施，例如软件的开发、维护和操作等。

　　2.428严重性 severity

　　参见2.116条。

　　2.429副作用 side effect

　　进行的处理或活动，或得到的结果，它们与程序、子程序、或操作的主要功能相比是处于第二位的。

　　2.430模拟 simulation

　　由另一系统来表示某实际或抽象系统中选定的行为的特征。在数字计算机系统中，模拟由软件 来做，例如，

　　(a)借助于由计算机系统执行的操作表示物理现象。

　　(b)用一计算机系统的操作表示 另一个计算机系统的操作。与2.23条相对照。

　　2.431模拟器 simulator

　　一个设备、一个数据处理系统、或一个计算机程序，它表示了某实际或抽象系统的行为的某些特征。

　　2.432规模估计 sizing

　　对一个系统或系统部件所需要的源程序的行数或计算机存储的总量的估计。

　　2.433软件 software

　　a.与计算机系统的操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。参见

　　2.25条、2.496条。

　　b.与计算机系统的操作有关的程序、规程、规则及任何与之有关的文档。与2.220条相对照。

　　2.434 软件部 sottware component

　　一个软件配置项中的一个明确的部分。

　　注：一个软部件含有软件的多个单元;也可以含有多个较低级的软部件。

　　2.435软件配置 software configuration

　　软件产品在不同时期的组合。该组合随着开发工作的进展而不断变化。

　　2.4 3 6软件配置管理 software configuration management

　　参见 2.98条。

　　2.4 3 7软件数据库 software data base

　　存放运行软件系统内部公共数据的数据定义及其当前值的文件。

　　2.4 3 8软件开发周期 software develoPment cycle

　　a.从决定开发一个软件产品开始到产品交付为止的时间间隔。这个周期通常包括需求阶段、 设计阶段、实现阶段、测试阶段，有时还包括安装和验收阶段。与2.448条相对照。

　　b.从决定开发软件产品开始到开发者不再改进产品时为止的时间周期。

　　c.有时作为软件生存周期的同义语使用。

　　2.4 3 9软件开发库 software develoPment liabrary

　　存放与软件开发工作有关的计算机可读信息和人们可读信息的软件库。

　　2.4 4 0软件开发簿 software develppment note book

　　有关给定软件模块情况材料的集合。其内容通常包括与给定软件模块有关的需求、设计、技术报 告、代码列表清单、测试计划、测试结果、问题报告、进度、注释等等。参见2.370条。

　　2.4 41软件开发计划 software develoPment plan

　　为开发某一软件产品而做的项目计划。与2.86条同义。

　　2.4 4 2软件开发过程 software develoPment process

　　把用户要求转化为软件需求，把软件需求转化为设计，用代码来实现设计，对代码进行测试，完成文档编制，并确认软件可以投入运行性使用的过程。

　　2.4 4 3软件文档 software documentation

　　以人们可读的形式出现的技术数据和信息。包括计算机列表和打印输出，它们描述或规定软件设计或细节，说明软件具备的能力，或为使用软件以便从软件系统得到所期望的结果而提供的操作指令。参见 2.157条、2.493条、2.536条。

　　2.444软件工程 software engineering

　　软件开发、运行、维护和引退的系统方法。

　　2.4 4 5软件经验数 software experience data

　　与软件的开发或使用有关的数据。这在开发软件模型、可靠性预测，或软件的其它定量描述中可能是有用的。

　　2.446软件库管理员 sofware librarian

　　负责建立、管理和维护软件库的人员。

　　2.447软件库 software library

　　软件和有关的文档说明的一个受控制的集合。目的是有助于软件开发、使用或维护。类型包括软件开发库、主库、产品库、程序库和软件储藏仓。参见2.494条。

　　2.448软件生存周期 sofware life cycle

　　从设计软件产品开始到产品不能再使用时为止的时间周期。软件生存周期通常包括需求阶段、 设计阶段、实现阶段、测试阶段、安装和验收阶段、运行和维护阶段，有时还包括引退阶段。与 2.438条相对照。

　　2.4 4 9软件维护 sofware maintenance

　　a.在一软件产品交付之后对其进行修改，以纠正故障。

　　b.在一软件产品交付之后对其进行修改，以纠正故障，改进性能和其它属性，或使产品适应改

　　变了的环境。参见2.16条、 2.109条、2.332条。

　　2.450软件监督程序 software monitor

　　和另一计算机程序并行执行的软件工具，并对那个程序的执行情况提供详细的信息。

　　2.451软件产品 software Prodnuet

　　指定交付给用户的软件实体。

　　2.452软件质量 sofwarer requality

　　a.软件产品中能满足给定需要的性质和特性的总体。例如，符合规格说明。

　　b.软件具有所期望的各种属性的组合程度。

　　c.顾客和用户觉得软件满足其综合期望的程度。

　　d.确定软件在使用中将满足顾客预期要求的程度。

　　2.453软件质量保证 software quality assurance

　　参见2.383条。

　　2.454软件可靠性 software reliability

　　a.在规定条件下，在规定的时间内软件不引起系统失效的概率。该概率是系统输入和系统使用的函数，也是软件中存在的缺陷的函数。系统输入将确定是否会遇到已存在的缺陷(如果有缺陷存在的)。

　　b.在规定的时间周期内所述条件下程序执行所要求的功能的能力。

　　2.455软件档案库 software rePOSitory

　　一个软件库。它用于存储软件和有关文档的永久性的档案。

　　2.456软件潜行分析 software sneak analysis

　　施用于软件的一种技术。用以识别潜伏的(潜行的)逻辑控制路径或条件。这些路径或条件会禁止所期望进行的操作或引起不希望有的操作出现。

　　2.457软件工具 software tool

　　一种计算机程序。用来帮助开发、测试、分析或维护另一计算机程序或它的文件。例如，自动设计工具、编译程序、测试工具、维护工具。

　　2.458软件单元 software unit

　　一段可分开编译的代码。

　　2.459源语言source language

　　a.用来书写源程序的语言。

　　b.其语句被翻译的一种语言。与2.501条相对照。

　　2.460源程序source Program

　　a.在计算机执行之前必须被编译、汇编或解释的计算机程序。

　　b.用源语言表达的计算机程序。与2.312条相对照。

　　2.461规格说明，规范 sPecification

　　a.以一种完全的、精确的、可验证的方法规定系统或系统部件的需求、设计、性能或其它特性的文件。参见2.143条、2.211条、2.218条、2.251条、2.335条、2.407条。

　　b.制定规格说明的过程。

　　c.对某产品、某种材料或进程将要满足的一组需求的扼要陈述，并在适当的时候，指明一种过程，根据该过程可确定给定需求是否得到满足。

　　2.462规格说明语言 sPecification language

　　一种语言。常常是机器可处理的自然语言和形式语言的组合。用来规定系统或系统组成成分的需求、设计、性能或其它特性。参见2.138条、2.408条。

　　2.463规格说明验证 sPecification verification

　　参见2.539条。

　　2.464稳定性 stability

　　a.在有干扰或破坏事件影响下仍能保持不变的能力。

　　b.在干扰或破坏性事件之后返回到原始状态的能力。

　　2.465栈 stack

　　按后进先出方法进行存取的一个列表。与2.385条相对照。

　　2.466标准实施器 standards enforcer

　　一种软件工具。它确定指定的开发标准是否得到遵循。标准可以包括模块大小、模块结构、注释的约定、某些语句形式的使用以及文件编制约定。

　　2.467状态图 state diagram

　　一种有向图。其中的结点对应于系统的内部状态，也对应于迁移;常常用来通过状态的改变来描述系统。参见2.337条。

　　2.468静态分析 static analysis

　　估计程序而无需执行程序的过程。参见2.146条、2.63条、2.237条、2.545条、2·164条。

　　2.4 69静态分析程序 static analyzer

　　一种软件工具。它有助于分析计算机程序而无需执行该程序，例如语法检验程序、编译程序、交叉引用表生成程序、标准实施器以及流程图。与2.165条相对照。

　　2.470静态结合 static binding

　　在程序执行之前实现的，执行期间不加改变的结合。与2.166条反义。

　　2.471统计测试模型 statistical test model

　　一种模型。它把程序故障与输入数据集(或多个数据集)联系起来。模型也给出了这些故障将引起程序失效的概率。

　　2.472逐步细化(法) stePwise refinement

　　系统开发方法学，在其中首先概括地决定数据定义和处理步骤，然后逐步增加细节。参见 2.22 2 条、2.526条、2.52条。

　　2.473串 string

　　实体。如字符或物理元素的线性序列。

　　2.474强类型 strong tyPing

　　一种程序设计语言特性。它要求对每个数据对象的数据类型都作出说明，并排除操作符施用于 不适当的数据对象上的情况。因此，防止了不相容类型的数据对象的相互作用。

　　2.475结构化设计 structured design

　　进行软件设计的一种带有约束性的方法。它遵循一组指定的规则。这些规则是建立在诸如自顶向下设计、逐步求精法和数据流分析等原则基础上的。

　　2.476结构化程序 structured Program

　　由一组基本的控制结构构造而成的程序。每一个控制结构有一个入口点和一个出口点。控制结构组典型地包括：由两条或多条指令组成的序列;两个或多个指令或指令序列的条件选择;一个指令或指令序列的重复执行。

　　2.477结构化程序设计 structured Programming

　　a.一种定义良好的软件开发技术。它采用自顶向下设计和实现方法，并严格地使用结构化程序的控制构造。

　　b.不严格地讲，指组织和编写程序的一种技术。这种技术可简化复杂性，改进明晰度，并便于排除隐错和修改。

　　2.478结构化程序设计语言 structured programming language

　　一种程序设计语言。它提供了结构化程序的构造并有利于结构化程序的开发工作。

　　2.479桩模块 stub

　　a.在较高级的模块和测试期间所使用的取代低层模块的虚程序模块。

　　b.用来代替程序单位并指明该单位是在别处定义或将在别处定义的程序语句。

　　2.480分包商 sub-contractor

　　依据合同向合同当事人的一方提供系统、产品或服务的一个机构。

　　2.481子程序 subProgram

　　可以被一个或多个其它的程序单位所调用的程序单位。例如，过程、函数、子例行程序。

　　2.482子例行程序，子例程 subroutine

　　a.一组顺序的语句。可在一个或多个计算机程序中以及在一个计算机程序内的一处或多处使用。

　　b.可以作为另一例行程序一部分的例行程序。

　　c.由调用语句所调用的子程序。它可以接受或不接受输入值，并通过参数名、程序变量或机构而不是子例行程序名自身来返回任何输出值。与2.213条相对照。参见2.346条。

　　2.483子系统 subsystem

　　一组装配件或部件，或两者的组合，以实现单一的功能。

　　2.484管理程序 suPervisor

　　参见2.485条。

　　2.485管理程序 suPervisory Program

　　一种计算机程序，通常是操作系统的一部分。它控制其它计算机程序的执行并且调节数据处理系统中的工作流程。与 2.190条、 2.484条同义。

　　2.486供方 suPPlier

　　按照所签的合同向需方提供系统、产品或服务的一个机构(是合同当事人、生产者、卖方、批发商的同义词)。 注：需方可以指定它的机构中的某一部门做为供方。

　　2.487支持软件 suPPort software

　　用于帮助和支持开发的软件。

　　2.488符号执行 symbolic execution

　　一种验证技术。在这种技术中，模拟程序的执行是使用符号而不是真实的值来代表输入数据，而程序输出则表示成包含这些符号的逻辑或数学表达式。

　　2.489语法 syntax

　　a.字符或字符组之间的关系。这种关系与它们的含义或它们的解释及使用的方法无关。

　　b.语言中表达式的结构。

　　c.管辖语言结构的规则。参见2.424条。

　　2.490系统 system

　　a.人、机器和方法的集合。用来实现一组规定的功能。

　　b.一个完整的整体。它由种类不同的、相互作用的、专门的结构和子功能部件所组成。

　　c.由某些相互作用或相互依赖关系联合起来的小组或子系统。它可执行多种职能，但是作为一个单位而发挥其作用。

　　2.491系统体系结构 system architecture

　　系统各部件之间的结构和关系。系统体系结构也可以包括系统和它的运行环境之间的界面。

　　2.492系统设计 system design

　　a.为系统定义硬件和软件结构、部件、模块、接口及数据，以满足规定的系统需求的过程。

　　b.系统设计过程的结果。

　　2.493系统文档 system documentation

　　表达系统的需求、设计思想、设计细节、能力、限制，以及其它特性的文档。与2.536条相对照。

　　2.494系统库 system library

　　驻留于系统中的受控软件的集合。可供存取和使用，或通过引用而合并到其它程序中去。例如，在需要时由连接编辑程序合并到某程序中去的一组例行程序。参见2.447条。

　　2.495系统可靠性 system reliability

　　包括全部硬件和软件子系统在内的某个系统在规定的环境中及规定的时间里正确执行所要求的任务或使命的概率。参见2.318条、2.454条。

　　2.496系统软件 system software

　　管理、使用和维护计算机系统资源的软件。例如，操作系统、编译程序、实用程序。与2.25条相对照。

　　2.497系统测试 system testing

　　测试整个硬件和软件系统的过程。以验证系统是否满足规定的需求。参见2.6条、2.381条。

　　2.498系统确认 system validation

　　参见2.538条。

　　2.499系统验证 system verification

　　参见2.539条。

　　2.500表格table

　　a.数据的一个阵列，其中每一项均可借助于一个或多个变元清楚地予以标识。

　　b.数据的一个集合，其中每一项可由标号、位置，或按某些其它方法唯一地标识。

　　2.501目标语言 target language

　　由源语句翻译成的语言。与2.459条相对照。

　　2.502目标机 target machine

　　a.打算在其上运行程序的计算机。

　　b.由另一台计算机加以模拟的计算机。与2.226条相对照。

　　2.503任务 task

　　构成活动的基本元素，由若干个任务构成一项活动。

　　2.504终止性证明 termination Proof

　　正确性证明中的一项内容，它证明在全部规定的输入条件下，程序将终止。

　　2.505测试台 test bed

　　a.测试环境。其中包括测试系统或系统部件所必须的硬件、探测工具、模拟程序，以及其它支持软件。

　　b.在测试系统或系统的部件时所必需的全部测试用例的汇集。

　　2.506测试用例 test case

　　测试数据及与之相关的测试规程的一个特定的集合。它是为了特定目的(如考察特定程序路径或验证是否符合特定的需求)而产生出来的。参见2.520条。

　　2.507测试用例生成器 test case generator

　　参见2.38条。

　　2.508测试范围 test coverage

　　一个范围，在此范围内测试程序测试系统需求能否满足。

　　2.509测试数据 test data

　　用来测试系统或系统部件的数据。参见2.506条。

　　2.510 测试数据生成器 test data generator

　　参见 2.38条。

　　2.511测试驱动程序 test driver

　　一种驱动程序。它调用被测试的对象，它还可以提供测试输入并报告测试结果。

　　2.512测试日志 test log

　　按年月日所做的测试活动的全部有关细节的记录。

　　2.513测试阶段 test phase

　　软件生存周期中的一段时间。在此期间对软件产品的部件进行评价且进行集成。并评价软件产品以确定需求是否已得到满足。

　　2.514测试计划 test plan

　　一个文件，它叙述了对于预定的测试活动将要采取的途径。典型的计划中包括：标识要测试的项 目、要完成的测试、测试进度表、人事安排要求、报告要求、评价准则，以及任何临界的要求的临 时计划。

　　2.515测试规程 test procedure

　　对给定的测试，就其建立、运行和结果估计所作的详细说明。常常把一组有关的过程组合起来形成测试过程文件。

　　2.516测试可重现性 test rePeatability

　　测试的一种属性。指明相同环境、不同时间进行的测试是否产生相同的结果。

　　2.517 测试报告 test report

　　描述对系统或系统部件进行的测试行为及结果的文件。

　　2.518测试有效性 test validity

　　完成测试规定目标的程度。

　　2.519可测试性 testablility

　　a.软件的一种性质。它表明了既便于测试准则的建立又便于就这些准则对软件进行评价的程度。

　　b.需求的定义便于对需求进行分析以建立测试准则的程度。

　　2.520测试 testing

　　由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求;或识别出期望的结果和实际结果之间有无差别。比较2.12 8条。

　　2.521吞吐量 throughput

　　对计算机系统在一段时间内实现工作总量的度量。例如，每天的作业数。

　　2.522分时 time sharing

　　a.计算机系统的一种操作技术。它提供了在一台处理机中在时间上交替进行两个或多个进程。

　　b.指在一个计算机系统上时间的交替使用，它能使两个或多个用户并发地执行计算机程序。

　　2.523计时分析程序 timing analyzer

　　一种软件工具。用于估计或度量计算机程序的执行时间或部分计算机程序的执行时间。这可通过求每条路径中指令的执行时间之和得到，或由在程序中的规定点处插入探头并度量探头之间的执行时间而得到。

　　2.524容错 toIerance

　　系统在各种异常条件下提供继续操作的能力。

　　2.525工具 tool

　　a.参见 2.457条。

　　b.用来分析软件或其性能的执行时间而得到。

　　2.526自顶向下toP-down

　　指从层次的最高级部件处开始，逐步推进到较低级的方法。例如，自顶向下设计、自顶向下程序设计、自顶向下测试。与2.52条相对照。

　　2.527自顶向下设计 toP-down design

　　由整体到局部逐级细化的设计过程，即先标出系统的主要部件，并把它们分解为较低级成分，然后重复进行直到不能(或不必)再分解为止。与 2.5 3条相对照。

　　2.528自顶向下测试 toP-down testing

　　通过对较低级部件进行模拟的办法来从顶到底逐步地检查按层次方式所构造的程序的过程。

　　2.529完全正确性 total correctness

　　在正确性证明中，指出程序的输出断言是它的输入断言和处理步骤的合乎逻辑的结果，并且在全部规定的输入条件下程序能终止。与2.326条相对照。

　　2.530踪迹，追踪 trace

　　a.计算机程序执行情况的记录;它显示指令执行的顺序。

　　b.在计算机程序执行期间出现的全部或某类指令或程序事件的记录。

　　c.产生一个踪迹。

　　2.531追踪程序 tracer

　　用于追踪的软件工具。

　　2.532翻译程序，转换程序 trandator

　　一种程序。它把。种语言的语句序列变换为另。种语言中的等价的语句序列。参见 2· 30条、 2.73条、 2.255条。

　　2.533 树 tree

　　由通过分支互相连接的结点组成的抽象的层次结构。其中：(a)每个分支把7个结点连接到一个直属的下级结点;(b)有唯一称为根的一个结点，它不附属于任何其它结点;(c)根之外的每个结点只直接从属于另一个结点。

　　2.534类型 type

　　参见2.127条。

　　2.535用户 user

　　使用可操作的系统完成。项特定的功能的个人或机构。(可以是买主或需方的同义词。)

　　2.536用户文档 user documentation

　　一套文档。它为使用系统以期获得所希望结果的最终用户提供系统指令方面的信息。例如，用户手册。与2.493条相对照。

　　2.537实用软件 utility software

　　计算机程序或例行程序。设计这种程序的目的是为其它应用软件、操作系统或系统用户提供他们所要求的某些通用支持功能。

　　2.538确认 validation

　　在软件开发过程结束时对软件进行评价，以确认它和软件需求是否相一致的过程。参见2·5” 条。

　　2.539验证 verification

　　a.确定软件开发周期中的。个给定阶段的产品是否达到前阶段确立的需求的过程。参见 2.538条。

　　b.程序正确性的形式说明。参见2.374条。

　　c.评审、审查、测试、检查、审计等活动，或对某些项、处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。

　　2.540验证系统 verification System

　　参见2.39条。

　　2.541版本 version

　　某一配置项的一个可标识的实例。 注：软件某版本的修改产生一个新的版本，但它需要配置管理活动。

　　2.542虚拟机 virtual machine

　　对计算机及其有关设备的功能模拟。

　　2.543虚拟空间 virtual sPace

　　a.计算机制图中的坐标空间，空间中的每一单元由用户定义的坐标系表示。

　　b.用户程序运行的一个逻辑地址空间。

　　2.544虚拟存储器 virtul storage

　　可以被计算机系统的用户看作可编址主存储器的存储空间。在程序运行时虚地址被映射为实地址。虚拟存储器的大小由计算机系统的编址方式及所能使用的辅助存储器的总容量确定，而不受主存储器的实际容量所限制。

　　2.545走查walk-through

　　评审过程在此过程中设计者或程序员引导开发小组中一名或多名其它成员通读已书写的设计或编码，其它成员负责提出问题并对有关技术、风格、可能的错误、是否违背开发标准的地方等进行评论。与2.237条相对照。
2.101 连接 connection
　　a. 程序的某。部分对程序另。部分的标识符（即，在另外地方发现的标识）的引用。参见2.249条。
　　b.为了传递信息而在功能部件之间建立的关系。

2.102 合同 contract
　　通过法律约束当事双方的一个协议，或是在一个机构内部为了提供服务的一个内部协议，该协议提供的服务适用于一个系统或系统一部分的供应、开发、生产、操作或维护。

2.103合同所要求的审计 contractually required audit
　　合同所要求的审核过程。一般由需方或由独立的机构主持进行。此过程对产品或服务提供一个独立的评价，以决定产品或服务是否符合它们的需求。

2.104 控制数据 control data
　　选择一程序中的操作方式或子方式，给顺序流指向，或者直接影响软件操作的数据。

2.105控制语句 control statement
　　影响操作执行顺序的程序设计语言的语句。

2.106控制结构 control structure
　　通过计算机程序决定控制流的构造。参见2.91条。

2.107转换 conversion
　　对现有软件进行修改，使之在不同环境工作时能具有等同的功能，例如，把二个程序从FOR-TRAN变换成Ad。。把在一台计算机上运行的程序变换成能在另一台计算机上运行的程序。

2.108 协同例行程序 co-routines
　　彼此能调用，但不存在上下级关系的两个或两个以上的模块。

2.109改正性维护 corrective maintenance
　　专门为克服现有故障而进行的维护。参见2.449条。

2.110正确性 correctness
　　a.软件无设计缺陷和编码缺陷的程度，即无故障。
　　b.软件符合规定的需求的程度。
　　c.软件满足用户期望的程度。

2.111正确性证明 correctness proof
　　参见 2. 374条。

2.112耦合度 coupling
　　计算机程序中模块之间相互依赖的量度。与2.67条相对照。

2. 113 临界的，关键的 critical
　　系指：
　　a. 由于设计不当，一个系统或一个软件的某些环节或部分在运行时超出了临界范围，或存在着潜在的、未检测出的错误，会导致死机、人员伤害、任务失败、数据丢失、财经上的损失或灾难性的设备损坏等严重后果。或指：
　　b.要使用的软件开发技术的成熟程度和有关的风险。

2.114 关键部分优先 critical Piece first
　　软件开发的一种途径。它首先把注意力集中在软件系统中最关键部分的实现。关键部分可以根据所提供的服务、风险程度、困难程度或其它一些准则来确定。
2.115关键段，临界段 critical section
　　将要被执行的一段代码。其执行与另一关键段的代码的执行是互斥的。如果一些代码段竞相使用一计算机资源和数据项时，就要求这些段互斥地执行。

2. 116危急程度 criticality
　　根据软件错误或故障对系统的开发和运行的影响程度所做的估价进而对这些软件错误或故障进行的分类（通常用来判定是否要对某一故障进行校正，以及何时予以校正）。

2.117交叉汇编程序 cross assembler
　　在一台计算机上为另一台不同的计算机产生目标代码的汇编程序。

2.118交叉编译程序 cross comPiler
　　在一台计算机上为另一台不同计算机产生汇编代码或目标代码的编译程序。

2.119数据 data
　　事实、概念或指令的形式化的表现形式，它适于由人或自动装置进行通信、解释或处理。参见 2.79条、2.104条、2.179条、2.395条、2.445条。

2. 120 数据抽象 data abstraction
　　通过选择特定的数据类型及其相关的功能特性的办法，仅仅保持或抽取数据的本质特性所得的结果，从而使其与细节部分的表现方式分开或把它们隐藏起来。参见2.235条。

2. 121数据库，数据基 data base
　　a. 一数据集，或一数据集的部分或全体，它至少包括足够为一给定目的或给定数据处理系统使用的一个文件。
　　b. 对一系统来说是基本的数据集合。

2. 122数据字典加 data diCtionary
　　a.软件系统中使用的所有数据项的名字及与这些数据项有关的特性（例如，数据项长度、表示等）的集合。
　　b. 分层数据流图中涉及的数据流、数据元素、文件、数据基和进程之定义的集合。

2.12 3数据流图 data flow chart
　　系统的一种图形表示，其中表示出数据源、数据汇、存储和以结点形式对数据执行的处理，以及在结点间作为连接部分的逻辑数据流。与2.124条、2.125条同义。

2.124 数据流图 data flow diagram
　　参见 2. 123条。

2.125数据流图 data flow graph
　　参见 2. 123条。

2.126数据结构 data structure
　　数据项之间的次序安排和可访问性的一种形式表示，其中不涉及其实际存储排列方法。

2.127数据类型 data type
　　一类数据。用属于该类的元素和可对之施行的操作来表征。例如，整型、实型、逻辑型。

2.128 排错，调试 debugging
　　查找、分析和纠正错误的过程。

2.129排错模型 debugging model
　　参见 2. 180条。

2.130判定表 decision table
　　a.在叙述一问题中要考虑的所有可能发生的情况及对每一组可能发生的情况将要采取的行动的一张表。
　　b.对一组情况及其相应动作以矩阵形式或列表形式所做的表示。

2.131缺陷 defect
　　参见 2. 198条。

2. 132 定义阶段deftnion phase
　　参见2.406条。

2.133交付 delivery
　　a.软件研制周期中的一个阶段。在此阶段上将产品提交给计划中的用户供其使用。
　　b.软件研制周期中的一个阶段。在此阶段上产品由其预定的用户接受。 2.134设计design
　　a.为使一软件系统满足规定的需求而确定软件体系结构、部件、模块、接口、测试途径和数据的过程。
　　b.设计过程的结果。

2. 135 设计分析design analysis
　　a.对一设计进行估计以确定其相对于预定需求的正确性、符合设计标准的程度、系统效率和是否符合其它一些准则。
　　b.对其它替代性设计途径的估计。

2.136设计分析器 desiyn analyzer
　　一种自动设计工具。它接收有关程序的设计方面的信息，并产生以下方面的输出，如模块层次图、控制和数据结构的图形表示，以及被访问的数据块的一览表等。

2.137设计审查 desisn insPection
　　参见2.237条。

2.138设计语言 design language
　　一种具有专门构造，有时还可验证的语言。用以开发、分析设计并为其书写文件。

2.139设计方法学desiyn methodology
　　进行设计的系统途径。由专门选择的工具、技术、准则的有序应用所构成。

2.140设计阶段 desisn phase
　　软件生存周期中的一段时间。在这段时间内，进行体系结构、软件组成部分、接口和数据的设计，为设计编制文件，并对其进行验证，以满足预定需求。

2.141设计需求 desisn requirement
　　影响或限制软件系统或软件系统组成部分的设计的需求：例如，功能需求、物理需求、性能需求，软件开发标准，软件质量保证标准。参见2.407条。

2.142设计评审 desisn review
　　a.在正式会议上，把系统的初步的或详细的设计提交给用户、客户或有关人士供其评审或批准。
　　b.对现有的或提出的设计所做的正式评估和审查，其目的是找出可能会影响产品，过程或服务工作的适用性和环境方面的设计缺陷并采取补救措施，以及（或者）找出在性能、安全性和经济方面的可能的改进。

2.143设计规格说明 design sPecification
　　一种描述设计要求的正式文档，按照这种文档对系统或系统组成部分（如，软件配置项）进行设计。典型内容包括系统或系统组成部分算法、控制逻辑、数据结构设定与使用（set－use）信息、输入输出格式和接口描述。参见2.407条。

2.144设计验证 design verification
　　参见2.539条。

2.145设计定查 design walk－throngh
　　参见2.545条。

2.146桌面检查 desk checking
　　对程序执行情况进行人工模拟，用逐步检查源代码中有无逻辑或语法错误的办法来检测故障。 参见2.468条。

2.147详细设计 detailed design
　　a.推敲并扩充初步设计，以获得关于处理逻辑、数据结构和数据定义的更加详尽的描述，直到设计完善到足以能实现的地步。
　　b.详细设计过程的结果。

2.148开发者 develoPer
　　在软件生存周期中执行开发活动（包括需求分析、设计直至验收）的一个机构。

2.149开发周期 development cycle
　　参见2.438条。

2. 150开发生存周期 develoPment life cycle
　　参见2.438条。

2.151开发方法学 develoPment methodology
　　编制软件的系统方法。它确定开发的各个阶段，规定每一阶段的活动、产品、验证步骤和完成准则。

2. 152开发规格说明 development specifocation
　　与2.407条同义。

2. 153诊断 diagnstic
　　a.计算机程序产生的信息。它用来指示另一系统组成部分中可能的故障。例如，由编译程序标识的语法错误。
　　b.涉及故障或失效的探测和隔离。

2.154有向图 digraph
　　参见 2. 155条。

2.155定向图 directed graph
　　一种图，其中的边均是单方向的。

2.156文档，文件 document
　　a.一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。例如，技术文件、设计文件、版本说明文件。
　　b.编制文件。

2. 157文档、文档编制，文档管理documentation
　　a.关于一给定主题的文件集合。参见2.536条、2.443条、2.493条。
　　b. 文档管理可能包括下述活动：对文档的识别、获取、处理、存储和发放。
　　c.产生一个文档的过程。
　　d.为了对活动、需求、过程或结果进行描述、定义、规定、报告或认证的任何书面或图示的信
息。

2.158文档级 documentation leVel
　　参见 2. 263条。

2.159驱动程序 driver
　　一个程序。它借助模拟较高一级的系统组成部分的办法来履行系统或系统组成部分的作用。参见 2.511条。

2.160双份编码dualcoding
　　一种开发技术。由不同的程序员或不同的程序设计小组，根据同一份规格说明书开发出功能上完全相同的程序的两个版本。所获得的源代码可以采用同一种语言，也可以采用不同的语言。双份编码的目的在于提供错误检测，提高可靠性，提供附加的文件说明，或使系统的程序设计错误或编译程序错误影响最终结果的概率降低。

2.161虚参数 dummy parameter
　　参见 2. 211条。

2.162卸出，转储 dumP
　　a.已被转储的数据。
　　b.为了某一专门目的。如允许存储器另作它用，或作为预防故障和错误的措施；或为了进行与排除错误有关的工作，将一存储器（通常是内部存储器）的全部或部分内容写到外部媒体上。

2.163动态分配 dynamic allocation
　　把可编址的存储器和其它资源分配给正在执行的程序。

2.164动态分析 dynamic analysis
　　根据程序的执行情况对程序进行估计的过程。与2.468条相对照。

2. 165动态分析器 dynamic analyzer
　　借助对程序执行情况的监督，帮助对计算机程序进行估计的软件工具。例如探测工具、软件监督器和跟踪器。与2.469相对照。
2.166动态结合，动态联编 dynamic binding
　　在程序执行期间进行的结合。与2.470相对照。
2.167动态重组 dynamic restructuring
　　a.一系统正在运行时，改变软件组成部分或结构的过程。
　　b.在程序执行期间重新组合数据库或数据结构的过程。

2.168编辑程序editor
　　可以对计算机中所存储的数据进行有选择性的修正的计算机程序。

2.16 9效率 efficiency
　　软件以最小的计算资源消耗实现其预定功能的程度。

2.170无效程序设计 egoless Programming
　　在对程序开发采用小组负责制的概念的基础上进行软件开发的一种方式。
　　其目的是防止程序员 与其产生的输出的关系过于密切，以免使客观估计受到损害。

2.171嵌入式计算机系统一bedded computer system
　　归结在一个其主要目的不是进行计算的较大系统中成为其完整不可分开的部分的计算机系统。
　　例如，在武器、航空、指挥控制、或运输系统中的计算系统。

2.172嵌入式软件 embedded software
　　嵌入式计算机系统用的软件。

2.173仿真 emulation
　　用一个计算机系统，主要是通过硬件，模仿另一个计算机系统的全部或部分功能，使进行模仿的系统接受的数据、执行的程序和实现的结果均与被模仿的系统所接受的数据，执行的程序和实现的结果相同。

2.174仿真器 emullator
　　执行仿真的硬件、软件或固件。

2.175封装 encapsulation
　　将系统功能隔离在一个模块中，并为该模块提供精确的规格说明的技术。参见 2. 2 3 5条。

2.176错误，出错，误差 error
　　a.计算、观察、测量的值或条件与实际的、规定的或理论上的值或条件不符合。
　　b.导致产生含有缺陷的软件的人为行动。例如，遗漏或误解软件说明书中的用户需求，不正确的翻译或遗漏设计规格说明书中的需求。参见2.192条、2.198条。

2.177出错分析 error analysis
　　a. 对观察到的软件故障进行调查的过程，调查的目的是跟踪那个故障以找出故障源。
　　b.对观察到的软件故障进行调查以找出以下一些信息，例如故障原因。该故障是在开发过程中哪一个阶段发生的，预防或较早地探测出软件故障的方法。
　　c.调查软件错误、失效和故障以确定定量速率和趋势的过程。

2. 178出错类别 error category
　　错误、故障或失效可能归并到其中的“组类别之二，当错误、故障或失效发生或发现后，可根据其原因、危急程度、效果、故障所属的生存周期阶段或其它特性而确定其类别。

2.179出错数据error data
　　出错数据通常（但不是精确地）用于：描述软件的问题、故障、失效及其更动，它们的特性，以及遇到或改正这些问题的条件。

2.180出错模型 error model
　　用于描述或估计一软件系统存在的故障数目、可靠性、需要的测试时间或类似特性。参见 2. 181 条。

2.181出错预测 error Prediction
　　对有关软件系统中软件问题、故障或失效的预期目的或性质所作的定量陈述。参见 2. 180条。

2.182出错预测模型 error Prediction model
　　参见2.180条。

2.183出错恢复 error recovery
　　参见2.197条。

2.184错误的撒播 error seeding
　　参见2.201条。

2.185评价 evaluation
　　决定某产品、项目、活动或服务是否符合它的规定的准则的过程。

2.186异常 excePtion
　　引起正常程序执行挂起的事件。

2.187执行 execution
　　由计算机运行计算机程序中一条或多条指令的过程。

2.188执行时间 execution time
　　a. 执行一个程序所用的实际时间或中央处理机所用的时间。
　　b.程序处于执行过程中的一段时间间隔。参见 2. 418条。

2.189执行时间理论 execution time theory
　　采用累计执行时间作为估计软件可靠性基础的一种理论。

2.190执行程序 executive program
　　参见2.485条。

2.191退出，终止，出口 exit
　　a. 计算机程序、例程或子例程中的一条指令。在执行它之后，该计算机程序、例程或子例程就不再具有控制权。
　　b.例程不再具有控制权的转折点。

2.192失效 failure
　　a.功能部件执行其功能的能力的丧失。
　　b.系统或系统部件丧失了在规定的限度内执行所要求功能的能力。当遇到故障情况时系统就可能失效。
　　c.程序操作背离了程序需求。

2.193失效类别 failur category
　　参见2.178条。

2.194失效数据 failure data
　　参见2.179条。

2.195失效率 failure rate
　　a.失效数与给定测量单位的比率；例如，每单位时间的失效次数、若干次事务处理中的失效次数，若干次计算机运行中的失效次数。
　　b.在可靠性模拟中，给定类别或具有一定严重程度的失效数与给定时间间隔之比率；例如，每秒执行时间的失效次数，每月失效次数。与2.196条同义。

2. 196失效比 failurer ratio
　　参见 2. 195条。

2.197失效恢复 failure recovery
　　系统失效后又回到可靠的运行状态。

2.198故障，缺陷 fauIt
　　a. 功能部件不能执行所要求的功能。
　　b.在软件中表示 2.176b关于错误的解释。如果遇到，它可能引起失效。与 2. 5 4条同义。
　　2.199故障类别 fault category
　　参见 2. 178条。

2.200故障插入 fauIt insertion
　　参见 2.201条。