軟件工程領域中通用的術語(二)
軟件工程領域中通用的術語(二)
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
進行的處理或活動,或得到的結果,它們與程序、子程序、或操作的主要功能相比是處于第二位的。
由另一系統來表示某實際或抽象系統中選定的行為的特征。在數字計算機系統中,模擬由軟件 來做,例如,
(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條。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%
相關閱讀:
- [電子說] 四創電子舉行“質量月”活動 推進項目軟件工程化 2023-09-28
- [電子說] 華為開啟第八屆ICT大賽中國區報名通道并攜手伙伴預發布《示范性軟件學院聯盟 2023-09-22
- [電子說] 為什么嵌入式軟件工程師需要掌握 Linux? 2023-07-21
- [電子說] BMS有哪些崗位?BMS策略工程師/軟件工程師/硬件工程師的區別? 2023-03-16
- [電子說] 熱烈祝賀向成電子兩名工程師獲得工信部頒發的飛騰平臺系統軟件工程師認證 2022-06-27
- [電子說] 說實話!硬件工程師薪資真的太低了! 2023-05-08
- [電子說] 過來人經驗分享要如何學習單片機? 2023-03-14
- [電子說] ChatGPT對程序員的影響 半導體行業的軟件工程師們該如何應對? 2023-03-10
( 發表人:admin )