软件工程领域中通用的术语(二)2.401可重复性rePeatability
参见2.516条。
2.403需求requirement
a.用户为解决某一问题或达到某个目标所需要的条件或能力。
a.研究用户要求以得到系统或软件需求的定义的过程。
b.对系统需求或软件需求的验证。
参见2.237条。
2.406需求阶段requirementsphase
软件生存周期中的一个阶段。在此期间对软件产品的需求(如功能和性能方面的能力)进行定义并编制出相应的文档。
2.408需求的规格说明语言requirementsspecificationlanguage
具有特殊构造和验证协议的形式语言，用于规定、验证和编制需求文件。
2.409需求验证requirementsverifcation
参见2.539条。
2.410退役retirement
操作和维护机构撤出现有的支持，全部或部分地由一个新的系统来代替或者安装一个更新的系统。
2.411退役阶段retirementPhase
软件生存周期中的一个阶段。在此阶段内，对软件产品的支持被终止。
2.412可重用性，复用率reusability
一个模块可在多种应用中加以利用的程度。
2.413评审review
参见2.142条。
2.414健壮性robustness
尽管引入了不合理的输入，软件仍能继续正常运行的程度。
一种编译程序。其输出是与机器无关的中间表示。当它与依赖于机器的代码生成程序组合时，就构成了完整的编译程序。
2.416例行程序一，例程routine
a.实现特定任务的一个计算机程序段。参见2.213条、2.346条、2.482条、2.480条。
b.广泛或频繁使用的程序段，或由程序调用的指令序列。
2.417运行态，运行方式runmode
当计算机正自动地执行着存储在存储单元中的指令，从而被认为是正在履行其功能时的那种状态。
b.程序开始执行的瞬间。参见2.188条。
2.419可扩展性scaliability
2.420安全性，保密性security
对计算机硬件、软件进行的保护，以防止其受到意外的或蓄意的存取、使用、修改、毁坏或泄密。
2.421安全核心securitykernal
2.422撒播seeding
参见2.201条。
2.423程序段，存储段，分段segment
b.在两个相邻转移分支点之间的计算机程序语句的序列。参见2.328条。
c.把计算机程序和数据分为若干段。
2.424语义semantics
a.字符或字符组与其含义之间的关系。这种关系是与它们的解释和使用的方式无关的。
b.符号和它们的含义之间的关系。
c.按照元语言表达计算机语言结构的含义的规则。参见2.489条。
用于同步并行进程的一种共享变量。它用来指明某动作是否已完成或某事件是否已发生。
2.426顺序进程sequentialprocesses
以这样一种方式执行的进程，即在下一个动作开始之前本动作必须结束。与2.90条相对照。
2.427服务(软件)service(software)
与软件有关的活动、工作或义务的实施，例如软件的开发、维护和操作等。
2.428严重性severity
参见2.116条。
2.429副作用sideeffect
进行的处理或活动，或得到的结果，它们与程序、子程序、或操作的主要功能相比是处于第二位的。
由另一系统来表示某实际或抽象系统中选定的行为的特征。在数字计算机系统中，模拟由软件来做，例如，
(a)借助于由计算机系统执行的操作表示物理现象。
(b)用一计算机系统的操作表示另一个计算机系统的操作。与2.23条相对照。
2.431模拟器simulator
一个设备、一个数据处理系统、或一个计算机程序，它表示了某实际或抽象系统的行为的某些特征。
2.432规模估计sizing
对一个系统或系统部件所需要的源程序的行数或计算机存储的总量的估计。
2.433软件software
a.与计算机系统的操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。参见
2.25条、2.496条。
b.与计算机系统的操作有关的程序、规程、规则及任何与之有关的文档。与2.220条相对照。
2.434软件部sottwarecomponent
一个软件配置项中的一个明确的部分。
注：一个软部件含有软件的多个单元;也可以含有多个较低级的软部件。
2.435软件配置softwareconfiguration
软件产品在不同时期的组合。该组合随着开发工作的进展而不断变化。
2.436软件配置管理softwareconfigurationmanagement
参见2.98条。
2.437软件数据库softwaredatabase
存放运行软件系统内部公共数据的数据定义及其当前值的文件。
2.438软件开发周期softwaredeveloPmentcycle
c.有时作为软件生存周期的同义语使用。
2.439软件开发库softwaredeveloPmentliabrary
2.440软件开发簿softwaredevelppmentnotebook
有关给定软件模块情况材料的集合。其内容通常包括与给定软件模块有关的需求、设计、技术报告、代码列表清单、测试计划、测试结果、问题报告、进度、注释等等。参见2.370条。
2.441软件开发计划softwaredeveloPmentplan
为开发某一软件产品而做的项目计划。与2.86条同义。
2.442软件开发过程softwaredeveloPmentprocess
把用户要求转化为软件需求，把软件需求转化为设计，用代码来实现设计，对代码进行测试，完成文档编制，并确认软件可以投入运行性使用的过程。
2.443软件文档softwaredocumentation
以人们可读的形式出现的技术数据和信息。包括计算机列表和打印输出，它们描述或规定软件设计或细节，说明软件具备的能力，或为使用软件以便从软件系统得到所期望的结果而提供的操作指令。参见2.157条、2.493条、2.536条。
2.444软件工程softwareengineering
软件开发、运行、维护和引退的系统方法。
2.445软件经验数softwareexperiencedata
与软件的开发或使用有关的数据。这在开发软件模型、可靠性预测，或软件的其它定量描述中可能是有用的。
2.446软件库管理员sofwarelibrarian
负责建立、管理和维护软件库的人员。
2.447软件库softwarelibrary
软件和有关的文档说明的一个受控制的集合。目的是有助于软件开发、使用或维护。类型包括软件开发库、主库、产品库、程序库和软件储藏仓。参见2.494条。
2.448软件生存周期sofwarelifecycle
2.449软件维护sofwaremaintenance
a.在一软件产品交付之后对其进行修改，以纠正故障。
b.在一软件产品交付之后对其进行修改，以纠正故障，改进性能和其它属性，或使产品适应改
变了的环境。参见2.16条、2.109条、2.332条。
2.450软件监督程序softwaremonitor
和另一计算机程序并行执行的软件工具，并对那个程序的执行情况提供详细的信息。
2.451软件产品softwareProdnuet
指定交付给用户的软件实体。
2.452软件质量sofwarerrequality
a.软件产品中能满足给定需要的性质和特性的总体。例如，符合规格说明。
b.软件具有所期望的各种属性的组合程度。
c.顾客和用户觉得软件满足其综合期望的程度。
d.确定软件在使用中将满足顾客预期要求的程度。
2.453软件质量保证softwarequalityassurance
参见2.383条。
2.454软件可靠性softwarereliability
2.455软件档案库softwarerePOSitory
一个软件库。它用于存储软件和有关文档的永久性的档案。
2.456软件潜行分析softwaresneakanalysis
施用于软件的一种技术。用以识别潜伏的(潜行的)逻辑控制路径或条件。这些路径或条件会禁止所期望进行的操作或引起不希望有的操作出现。
2.457软件工具softwaretool
一种计算机程序。用来帮助开发、测试、分析或维护另一计算机程序或它的文件。例如，自动设计工具、编译程序、测试工具、维护工具。
2.458软件单元softwareunit
一段可分开编译的代码。
2.459源语言sourcelanguage
a.用来书写源程序的语言。
b.其语句被翻译的一种语言。与2.501条相对照。
b.用源语言表达的计算机程序。与2.312条相对照。
2.461规格说明，规范sPecification
a.以一种完全的、精确的、可验证的方法规定系统或系统部件的需求、设计、性能或其它特性的文件。参见2.143条、2.211条、2.218条、2.251条、2.335条、2.407条。
b.制定规格说明的过程。
c.对某产品、某种材料或进程将要满足的一组需求的扼要陈述，并在适当的时候，指明一种过程，根据该过程可确定给定需求是否得到满足。
2.462规格说明语言sPecificationlanguage
一种语言。常常是机器可处理的自然语言和形式语言的组合。用来规定系统或系统组成成分的需求、设计、性能或其它特性。参见2.138条、2.408条。
2.463规格说明验证sPecificationverification
2.464稳定性stability
a.在有干扰或破坏事件影响下仍能保持不变的能力。
b.在干扰或破坏性事件之后返回到原始状态的能力。
按后进先出方法进行存取的一个列表。与2.385条相对照。
2.466标准实施器standardsenforcer
一种软件工具。它确定指定的开发标准是否得到遵循。标准可以包括模块大小、模块结构、注释的约定、某些语句形式的使用以及文件编制约定。
2.467状态图statediagram
一种有向图。其中的结点对应于系统的内部状态，也对应于迁移;常常用来通过状态的改变来描述系统。参见2.337条。
2.468静态分析staticanalysis
估计程序而无需执行程序的过程。参见2.146条、2.63条、2.237条、2.545条、2·164条。
2.469静态分析程序staticanalyzer
一种软件工具。它有助于分析计算机程序而无需执行该程序，例如语法检验程序、编译程序、交叉引用表生成程序、标准实施器以及流程图。与2.165条相对照。
2.470静态结合staticbinding
在程序执行之前实现的，执行期间不加改变的结合。与2.166条反义。
2.471统计测试模型statisticaltestmodel
一种模型。它把程序故障与输入数据集(或多个数据集)联系起来。模型也给出了这些故障将引起程序失效的概率。
2.472逐步细化(法)stePwiserefinement
系统开发方法学，在其中首先概括地决定数据定义和处理步骤，然后逐步增加细节。参见2.222条、2.526条、2.52条。
2.473串string
实体。如字符或物理元素的线性序列。
2.474强类型strongtyPing
一种程序设计语言特性。它要求对每个数据对象的数据类型都作出说明，并排除操作符施用于不适当的数据对象上的情况。因此，防止了不相容类型的数据对象的相互作用。
2.475结构化设计structureddesign
进行软件设计的一种带有约束性的方法。它遵循一组指定的规则。这些规则是建立在诸如自顶向下设计、逐步求精法和数据流分析等原则基础上的。
2.476结构化程序structuredProgram
由一组基本的控制结构构造而成的程序。每一个控制结构有一个入口点和一个出口点。控制结构组典型地包括：由两条或多条指令组成的序列;两个或多个指令或指令序列的条件选择;一个指令或指令序列的重复执行。
2.477结构化程序设计structuredProgramming
a.一种定义良好的软件开发技术。它采用自顶向下设计和实现方法，并严格地使用结构化程序的控制构造。
b.不严格地讲，指组织和编写程序的一种技术。这种技术可简化复杂性，改进明晰度，并便于排除隐错和修改。
2.478结构化程序设计语言structuredprogramminglanguage
一种程序设计语言。它提供了结构化程序的构造并有利于结构化程序的开发工作。
2.479桩模块stub
a.在较高级的模块和测试期间所使用的取代低层模块的虚程序模块。
b.用来代替程序单位并指明该单位是在别处定义或将在别处定义的程序语句。
依据合同向合同当事人的一方提供系统、产品或服务的一个机构。
2.481子程序subProgram
可以被一个或多个其它的程序单位所调用的程序单位。例如，过程、函数、子例行程序。
2.482子例行程序，子例程subroutine
a.一组顺序的语句。可在一个或多个计算机程序中以及在一个计算机程序内的一处或多处使用。
b.可以作为另一例行程序一部分的例行程序。
c.由调用语句所调用的子程序。它可以接受或不接受输入值，并通过参数名、程序变量或机构而不是子例行程序名自身来返回任何输出值。与2.213条相对照。参见2.346条。
2.483子系统subsystem
一组装配件或部件，或两者的组合，以实现单一的功能。
2.484管理程序suPervisor
参见2.485条。
2.485管理程序suPervisoryProgram
一种计算机程序，通常是操作系统的一部分。它控制其它计算机程序的执行并且调节数据处理系统中的工作流程。与2.190条、2.484条同义。
2.486供方suPPlier
按照所签的合同向需方提供系统、产品或服务的一个机构(是合同当事人、生产者、卖方、批发商的同义词)。注：需方可以指定它的机构中的某一部门做为供方。
2.487支持软件suPPortsoftware
用于帮助和支持开发的软件。
2.488符号执行symbolicexecution
一种验证技术。在这种技术中，模拟程序的执行是使用符号而不是真实的值来代表输入数据，而程序输出则表示成包含这些符号的逻辑或数学表达式。
2.489语法syntax
a.字符或字符组之间的关系。这种关系与它们的含义或它们的解释及使用的方法无关。
b.语言中表达式的结构。
c.管辖语言结构的规则。参见2.424条。
2.490系统system
a.人、机器和方法的集合。用来实现一组规定的功能。
b.一个完整的整体。它由种类不同的、相互作用的、专门的结构和子功能部件所组成。
c.由某些相互作用或相互依赖关系联合起来的小组或子系统。它可执行多种职能，但是作为一个单位而发挥其作用。
2.491系统体系结构systemarchitecture
系统各部件之间的结构和关系。系统体系结构也可以包括系统和它的运行环境之间的界面。
2.492系统设计systemdesign
a.为系统定义硬件和软件结构、部件、模块、接口及数据，以满足规定的系统需求的过程。
b.系统设计过程的结果。
2.493系统文档systemdocumentation
表达系统的需求、设计思想、设计细节、能力、限制，以及其它特性的文档。与2.536条相对照。
2.494系统库systemlibrary
驻留于系统中的受控软件的集合。可供存取和使用，或通过引用而合并到其它程序中去。例如，在需要时由连接编辑程序合并到某程序中去的一组例行程序。参见2.447条。
2.495系统可靠性systemreliability
2.496系统软件systemsoftware
管理、使用和维护计算机系统资源的软件。例如，操作系统、编译程序、实用程序。与2.25条相对照。
2.497系统测试systemtesting
测试整个硬件和软件系统的过程。以验证系统是否满足规定的需求。参见2.6条、2.381条。
2.498系统确认systemvalidation
参见2.538条。
2.499系统验证systemverification
2.500表格table
a.数据的一个阵列，其中每一项均可借助于一个或多个变元清楚地予以标识。
b.数据的一个集合，其中每一项可由标号、位置，或按某些其它方法唯一地标识。
2.501目标语言targetlanguage
由源语句翻译成的语言。与2.459条相对照。
2.502目标机targetmachine
a.打算在其上运行程序的计算机。
b.由另一台计算机加以模拟的计算机。与2.226条相对照。
2.503任务task
构成活动的基本元素，由若干个任务构成一项活动。
2.504终止性证明terminationProof
正确性证明中的一项内容，它证明在全部规定的输入条件下，程序将终止。
2.505测试台testbed
a.测试环境。其中包括测试系统或系统部件所必须的硬件、探测工具、模拟程序，以及其它支持软件。
b.在测试系统或系统的部件时所必需的全部测试用例的汇集。
2.506测试用例testcase
2.507测试用例生成器testcasegenerator
参见2.38条。
2.508测试范围testcoverage
一个范围，在此范围内测试程序测试系统需求能否满足。
2.509测试数据testdata
用来测试系统或系统部件的数据。参见2.506条。
2.510测试数据生成器testdatagenerator
2.511测试驱动程序testdriver
一种驱动程序。它调用被测试的对象，它还可以提供测试输入并报告测试结果。
2.512测试日志testlog
按年月日所做的测试活动的全部有关细节的记录。
2.513测试阶段testphase
2.514测试计划testplan
一个文件，它叙述了对于预定的测试活动将要采取的途径。典型的计划中包括：标识要测试的项目、要完成的测试、测试进度表、人事安排要求、报告要求、评价准则，以及任何临界的要求的临时计划。
2.515测试规程testprocedure
对给定的测试，就其建立、运行和结果估计所作的详细说明。常常把一组有关的过程组合起来形成测试过程文件。
2.516测试可重现性testrePeatability
2.517测试报告testreport
描述对系统或系统部件进行的测试行为及结果的文件。
2.518测试有效性testvalidity
完成测试规定目标的程度。
2.519可测试性testablility
a.软件的一种性质。它表明了既便于测试准则的建立又便于就这些准则对软件进行评价的程度。
b.需求的定义便于对需求进行分析以建立测试准则的程度。
2.520测试testing
由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求;或识别出期望的结果和实际结果之间有无差别。比较2.128条。
2.521吞吐量throughput
2.522分时timesharing
2.523计时分析程序timinganalyzer
2.524容错toIerance
系统在各种异常条件下提供继续操作的能力。
2.525工具tool
a.参见2.457条。
2.526自顶向下toP-down
指从层次的最高级部件处开始，逐步推进到较低级的方法。例如，自顶向下设计、自顶向下程序设计、自顶向下测试。与2.52条相对照。
2.527自顶向下设计toP-downdesign
由整体到局部逐级细化的设计过程，即先标出系统的主要部件，并把它们分解为较低级成分，然后重复进行直到不能(或不必)再分解为止。与2.53条相对照。
2.528自顶向下测试toP-downtesting
通过对较低级部件进行模拟的办法来从顶到底逐步地检查按层次方式所构造的程序的过程。
2.529完全正确性totalcorrectness
在正确性证明中，指出程序的输出断言是它的输入断言和处理步骤的合乎逻辑的结果，并且在全部规定的输入条件下程序能终止。与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用户文档userdocumentation
一套文档。它为使用系统以期获得所希望结果的最终用户提供系统指令方面的信息。例如，用户手册。与2.493条相对照。
2.537实用软件utilitysoftware
计算机程序或例行程序。设计这种程序的目的是为其它应用软件、操作系统或系统用户提供他们所要求的某些通用支持功能。
2.538确认validation
在软件开发过程结束时对软件进行评价，以确认它和软件需求是否相一致的过程。参见2·5”条。
2.539验证verification
a.确定软件开发周期中的。个给定阶段的产品是否达到前阶段确立的需求的过程。参见2.538条。
b.程序正确性的形式说明。参见2.374条。
c.评审、审查、测试、检查、审计等活动，或对某些项、处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
2.540验证系统verificationSystem
参见2.39条。
2.541版本version
某一配置项的一个可标识的实例。注：软件某版本的修改产生一个新的版本，但它需要配置管理活动。
2.542虚拟机virtualmachine
对计算机及其有关设备的功能模拟。
2.543虚拟空间virtualsPace
a.计算机制图中的坐标空间，空间中的每一单元由用户定义的坐标系表示。
b.用户程序运行的一个逻辑地址空间。
2.544虚拟存储器virtulstorage
可以被计算机系统的用户看作可编址主存储器的存储空间。在程序运行时虚地址被映射为实地址。虚拟存储器的大小由计算机系统的编址方式及所能使用的辅助存储器的总容量确定，而不受主存储器的实际容量所限制。
2.545走查walk-through
2.102合同contract通过法律约束当事双方的一个协议，或是在一个机构内部为了提供服务的一个内部协议，该协议提供的服务适用于一个系统或系统一部分的供应、开发、生产、操作或维护。
2.103合同所要求的审计contractuallyrequiredaudit合同所要求的审核过程。一般由需方或由独立的机构主持进行。此过程对产品或服务提供一个独立的评价，以决定产品或服务是否符合它们的需求。
2.104控制数据controldata选择一程序中的操作方式或子方式，给顺序流指向，或者直接影响软件操作的数据。
2.105控制语句controlstatement影响操作执行顺序的程序设计语言的语句。
2.106控制结构controlstructure通过计算机程序决定控制流的构造。参见2.91条。
2.108协同例行程序co-routines彼此能调用，但不存在上下级关系的两个或两个以上的模块。
2.109改正性维护correctivemaintenance专门为克服现有故障而进行的维护。参见2.449条。
2.110正确性correctnessa.软件无设计缺陷和编码缺陷的程度，即无故障。b.软件符合规定的需求的程度。c.软件满足用户期望的程度。
2.111正确性证明correctnessproof参见2.374条。
2.116危急程度criticality根据软件错误或故障对系统的开发和运行的影响程度所做的估价进而对这些软件错误或故障进行的分类（通常用来判定是否要对某一故障进行校正，以及何时予以校正）。
2.118交叉编译程序crosscomPiler在一台计算机上为另一台不同计算机产生汇编代码或目标代码的编译程序。
2.119数据data事实、概念或指令的形式化的表现形式，它适于由人或自动装置进行通信、解释或处理。参见2.79条、2.104条、2.179条、2.395条、2.445条。
2.121数据库，数据基databasea.一数据集，或一数据集的部分或全体，它至少包括足够为一给定目的或给定数据处理系统使用的一个文件。b.对一系统来说是基本的数据集合。
2.122数据字典加datadiCtionarya.软件系统中使用的所有数据项的名字及与这些数据项有关的特性（例如，数据项长度、表示等）的集合。b.分层数据流图中涉及的数据流、数据元素、文件、数据基和进程之定义的集合。
2.123数据流图dataflowchart系统的一种图形表示，其中表示出数据源、数据汇、存储和以结点形式对数据执行的处理，以及在结点间作为连接部分的逻辑数据流。与2.124条、2.125条同义。
2.124数据流图dataflowdiagram参见2.123条。
2.125数据流图dataflowgraph参见2.123条。
2.126数据结构datastructure数据项之间的次序安排和可访问性的一种形式表示，其中不涉及其实际存储排列方法。
2.127数据类型datatype一类数据。用属于该类的元素和可对之施行的操作来表征。例如，整型、实型、逻辑型。
2.128排错，调试debugging查找、分析和纠正错误的过程。
2.129排错模型debuggingmodel参见2.180条。
2.130判定表decisiontablea.在叙述一问题中要考虑的所有可能发生的情况及对每一组可能发生的情况将要采取的行动的一张表。b.对一组情况及其相应动作以矩阵形式或列表形式所做的表示。
2.131缺陷defect参见2.198条。
2.132定义阶段deftnionphase参见2.406条。
2.133交付deliverya.软件研制周期中的一个阶段。在此阶段上将产品提交给计划中的用户供其使用。b.软件研制周期中的一个阶段。在此阶段上产品由其预定的用户接受。2.134设计designa.为使一软件系统满足规定的需求而确定软件体系结构、部件、模块、接口、测试途径和数据的过程。b.设计过程的结果。
2.135设计分析designanalysisa.对一设计进行估计以确定其相对于预定需求的正确性、符合设计标准的程度、系统效率和是否符合其它一些准则。b.对其它替代性设计途径的估计。
2.136设计分析器desiynanalyzer一种自动设计工具。它接收有关程序的设计方面的信息，并产生以下方面的输出，如模块层次图、控制和数据结构的图形表示，以及被访问的数据块的一览表等。
2.137设计审查desisninsPection参见2.237条。
2.138设计语言designlanguage一种具有专门构造，有时还可验证的语言。用以开发、分析设计并为其书写文件。
2.139设计方法学desiynmethodology进行设计的系统途径。由专门选择的工具、技术、准则的有序应用所构成。
2.141设计需求desisnrequirement影响或限制软件系统或软件系统组成部分的设计的需求：例如，功能需求、物理需求、性能需求，软件开发标准，软件质量保证标准。参见2.407条。
2.142设计评审desisnreviewa.在正式会议上，把系统的初步的或详细的设计提交给用户、客户或有关人士供其评审或批准。b.对现有的或提出的设计所做的正式评估和审查，其目的是找出可能会影响产品，过程或服务工作的适用性和环境方面的设计缺陷并采取补救措施，以及（或者）找出在性能、安全性和经济方面的可能的改进。
2.144设计验证designverification参见2.539条。
2.145设计定查designwalk－throngh参见2.545条。
2.146桌面检查deskchecking对程序执行情况进行人工模拟，用逐步检查源代码中有无逻辑或语法错误的办法来检测故障。参见2.468条。
2.148开发者develoPer在软件生存周期中执行开发活动（包括需求分析、设计直至验收）的一个机构。
2.149开发周期developmentcycle参见2.438条。
2.150开发生存周期develoPmentlifecycle参见2.438条。
2.151开发方法学develoPmentmethodology编制软件的系统方法。它确定开发的各个阶段，规定每一阶段的活动、产品、验证步骤和完成准则。
2.152开发规格说明developmentspecifocation与2.407条同义。
2.153诊断diagnstica.计算机程序产生的信息。它用来指示另一系统组成部分中可能的故障。例如，由编译程序标识的语法错误。b.涉及故障或失效的探测和隔离。
2.154有向图digraph参见2.155条。
2.155定向图directedgraph一种图，其中的边均是单方向的。
2.156文档，文件documenta.一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。例如，技术文件、设计文件、版本说明文件。b.编制文件。
2.158文档级documentationleVel参见2.263条。
2.159驱动程序driver一个程序。它借助模拟较高一级的系统组成部分的办法来履行系统或系统组成部分的作用。参见2.511条。
2.160双份编码dualcoding一种开发技术。由不同的程序员或不同的程序设计小组，根据同一份规格说明书开发出功能上完全相同的程序的两个版本。所获得的源代码可以采用同一种语言，也可以采用不同的语言。双份编码的目的在于提供错误检测，提高可靠性，提供附加的文件说明，或使系统的程序设计错误或编译程序错误影响最终结果的概率降低。
2.162卸出，转储dumPa.已被转储的数据。b.为了某一专门目的。如允许存储器另作它用，或作为预防故障和错误的措施；或为了进行与排除错误有关的工作，将一存储器（通常是内部存储器）的全部或部分内容写到外部媒体上。
2.163动态分配dynamicallocation把可编址的存储器和其它资源分配给正在执行的程序。
2.164动态分析dynamicanalysis根据程序的执行情况对程序进行估计的过程。与2.468条相对照。
2.165动态分析器dynamicanalyzer借助对程序执行情况的监督，帮助对计算机程序进行估计的软件工具。例如探测工具、软件监督器和跟踪器。与2.469相对照。2.166动态结合，动态联编dynamicbinding在程序执行期间进行的结合。与2.470相对照。2.167动态重组dynamicrestructuringa.一系统正在运行时，改变软件组成部分或结构的过程。b.在程序执行期间重新组合数据库或数据结构的过程。
2.168编辑程序editor可以对计算机中所存储的数据进行有选择性的修正的计算机程序。
2.169效率efficiency软件以最小的计算资源消耗实现其预定功能的程度。
2.170无效程序设计egolessProgramming在对程序开发采用小组负责制的概念的基础上进行软件开发的一种方式。其目的是防止程序员与其产生的输出的关系过于密切，以免使客观估计受到损害。
2.175封装encapsulation将系统功能隔离在一个模块中，并为该模块提供精确的规格说明的技术。参见2.235条。
2.176错误，出错，误差errora.计算、观察、测量的值或条件与实际的、规定的或理论上的值或条件不符合。b.导致产生含有缺陷的软件的人为行动。例如，遗漏或误解软件说明书中的用户需求，不正确的翻译或遗漏设计规格说明书中的需求。参见2.192条、2.198条。
2.177出错分析erroranalysisa.对观察到的软件故障进行调查的过程，调查的目的是跟踪那个故障以找出故障源。b.对观察到的软件故障进行调查以找出以下一些信息，例如故障原因。该故障是在开发过程中哪一个阶段发生的，预防或较早地探测出软件故障的方法。c.调查软件错误、失效和故障以确定定量速率和趋势的过程。
2.178出错类别errorcategory错误、故障或失效可能归并到其中的“组类别之二，当错误、故障或失效发生或发现后，可根据其原因、危急程度、效果、故障所属的生存周期阶段或其它特性而确定其类别。
2.179出错数据errordata出错数据通常（但不是精确地）用于：描述软件的问题、故障、失效及其更动，它们的特性，以及遇到或改正这些问题的条件。
2.181出错预测errorPrediction对有关软件系统中软件问题、故障或失效的预期目的或性质所作的定量陈述。参见2.180条。
2.182出错预测模型errorPredictionmodel参见2.180条。
2.183出错恢复errorrecovery参见2.197条。
2.184错误的撒播errorseeding参见2.201条。
2.185评价evaluation决定某产品、项目、活动或服务是否符合它的规定的准则的过程。
2.186异常excePtion引起正常程序执行挂起的事件。
2.187执行execution由计算机运行计算机程序中一条或多条指令的过程。
2.190执行程序executiveprogram参见2.485条。
2.191退出，终止，出口exita.计算机程序、例程或子例程中的一条指令。在执行它之后，该计算机程序、例程或子例程就不再具有控制权。b.例程不再具有控制权的转折点。
2.192失效failurea.功能部件执行其功能的能力的丧失。b.系统或系统部件丧失了在规定的限度内执行所要求功能的能力。当遇到故障情况时系统就可能失效。c.程序操作背离了程序需求。
2.193失效类别failurcategory参见2.178条。
2.194失效数据failuredata参见2.179条。
2.196失效比failurerratio参见2.195条。
2.197失效恢复failurerecovery系统失效后又回到可靠的运行状态。
2.198故障，缺陷fauIta.功能部件不能执行所要求的功能。b.在软件中表示2.176b关于错误的解释。如果遇到，它可能引起失效。与2.54条同义。2.199故障类别faultcategory参见2.178条。