第一篇：軟件工程重點(diǎn)

軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，它是包括程序，數(shù)據(jù)及其相關(guān)文檔的完整集合。注意與廣義軟件概念的區(qū)別（P1）。程序是按事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu) 文檔是與程序開發(fā)，維護(hù)和使用有關(guān)的圖文材料

軟 件的特點(diǎn).軟件是一種邏輯實(shí)體，而不是具體的物理實(shí)體。因而它具有抽象性 軟件的生產(chǎn)與硬件不同，在它的開發(fā)過程中沒有明顯的制造過程，可以復(fù)制，軟件的開發(fā)和運(yùn)行常受到計(jì)算機(jī)系統(tǒng)的限制，對(duì)計(jì)算機(jī)系統(tǒng)有著不同程度的依賴性 軟件的開發(fā)至今尚未完全擺脫手工藝的開發(fā)方式 本身復(fù)雜 且 成本昂貴。

軟件功能分：系統(tǒng)，支撐，應(yīng)用軟件。

軟件生存期的六個(gè)步驟，即制定計(jì)劃（確定要開發(fā)軟件系統(tǒng)的總目標(biāo)，給出功能、性能、可靠性以及接口等方面的要求，完成該軟件任務(wù)的可行性研究，制定出完成開發(fā)任務(wù)的實(shí)施計(jì)劃）、需求分析（對(duì)待開發(fā)軟件提出的需求進(jìn)行分析并給出詳細(xì) 的定義）、設(shè)計(jì)（把各項(xiàng)需求轉(zhuǎn)換成軟件的體系結(jié)構(gòu)，對(duì)每個(gè)模塊要完成的工作進(jìn)行具體的描述，為源程序編寫打下基礎(chǔ)）、程序編碼（把軟件設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)可 以接受的程序代碼）、測(cè)試（通過單元模塊測(cè)試和組裝測(cè)試，對(duì)各項(xiàng)需求進(jìn)行有效性測(cè)試）及運(yùn)行維護(hù)（改正性維護(hù) 適應(yīng)性維護(hù) 完善性維護(hù)）

軟件：程序和所有使程序正確運(yùn)行所需要的相關(guān)文檔和配置信息。

軟件工程：是一門工程學(xué)科，不僅涉及軟件開發(fā)，也涉及軟件項(xiàng)目管理、支持軟件生產(chǎn)的工具、方法和理論的開發(fā)等活動(dòng)。

軟件過程：指制作軟件產(chǎn)品的一組活動(dòng)及其結(jié)果。包括軟件描述（對(duì)軟件及其操作的一些約束）軟件開發(fā)（軟件設(shè)計(jì)和編程實(shí)現(xiàn)）軟件有效性驗(yàn)證（檢查保證客戶所需）軟件進(jìn)化（隨不同客戶和變化市場(chǎng)做修改）

軟件過程模型:從一特定角度提出的軟件過程的簡(jiǎn)化描述。1工作流模型（描述軟件過程中各種活動(dòng)的序列及其輸入輸出和相互依賴性）2數(shù)據(jù)流或活動(dòng)模型（軟件過程描述成一組活動(dòng)，每個(gè)活動(dòng)完成一定數(shù)據(jù)轉(zhuǎn)換）3角色/動(dòng)作模型（描述參與人員的不同角色和各自負(fù)責(zé)的活動(dòng)）

CASE是計(jì)算機(jī)輔助軟件工程的簡(jiǎn)寫。它包括很多種類的軟件工具，覆蓋面很廣，包括支持阮娟過程活動(dòng)，如需求分析、系統(tǒng)建模、調(diào)試和測(cè)試等。瀑布模型：采用一些基本過程活動(dòng)，并且使用單獨(dú)的過程階段表現(xiàn)活動(dòng)。包括：需求分析和定義（通過咨詢系統(tǒng)用戶建立系統(tǒng)的服務(wù)、約束和目標(biāo)）系統(tǒng)和軟件設(shè)計(jì)（系統(tǒng)設(shè)計(jì)區(qū)分硬件和軟件系統(tǒng)的需求，軟件設(shè)計(jì)包括識(shí)別和描述一些基本的軟件系統(tǒng)的抽象及其之間的關(guān)系）實(shí)現(xiàn)和單元測(cè)試（檢驗(yàn)每個(gè)單元是否符合描述）集成 和系統(tǒng)測(cè)試（對(duì)系統(tǒng)整體測(cè)試確保滿足需求）運(yùn)行和維護(hù)。優(yōu)勢(shì)在于每個(gè)階段生成文檔，并且與其他模型相一致，問題在于將項(xiàng)目生硬分解成這些確切的階段。委托 事項(xiàng)一定要在過程的早期階段清晰給出，意味它難以響應(yīng)用戶需求的變更。

2迭代式模型：是軟件描述、開發(fā)和有效性驗(yàn)證活動(dòng)交替進(jìn)行的開發(fā)方 法。先開發(fā)出一個(gè)原型給用戶使用，通過用戶反饋意見不斷修改系統(tǒng)直到最后成熟。基本類型（探索式開發(fā)和拋棄式原型）優(yōu)勢(shì)在于讓開發(fā)活動(dòng)都能得到快速的反饋 信息，缺點(diǎn)在于1過程不可見（管理者要經(jīng)常性交付把握進(jìn)度）2系統(tǒng)結(jié)構(gòu)通常較差（連續(xù)的變更損壞系統(tǒng)結(jié)構(gòu)）

3基于組件的軟件工程（CBSE）假定系統(tǒng)的各個(gè)組件已經(jīng)存在，開發(fā)過程焦點(diǎn)在于集成這些組件。階段：組件分析（給出需求描述，然后搜索能滿足需求的組件）需求修改（修改需求以反映可得 到的組件）使用復(fù)用的系統(tǒng)設(shè)計(jì)（開始設(shè)計(jì)系統(tǒng)的框架）開發(fā)和集成（集成開發(fā)的組件和現(xiàn)成的組件使之成為整體）優(yōu)勢(shì)在于減少需要開發(fā)的軟件數(shù)量，降低軟件開 發(fā)成本和風(fēng)險(xiǎn)。缺點(diǎn)在于需求妥協(xié)的不可避免，對(duì)系統(tǒng)進(jìn)化的控制不起作用。

Rational統(tǒng)一過程：是一個(gè)階段化了的模型，識(shí)別出軟件過程 當(dāng)中的四個(gè)階段——開端（目標(biāo)是建立系統(tǒng)的一個(gè)業(yè)務(wù)案例）細(xì)化（增進(jìn)對(duì)問題域的理解，建立系統(tǒng)的體系框架）構(gòu)造（關(guān)心系統(tǒng)設(shè)計(jì)、編程和測(cè)試）轉(zhuǎn)換（關(guān)注如 何將系統(tǒng)從開發(fā)單位轉(zhuǎn)移到用戶單位使之在真實(shí)環(huán)境工作）九個(gè)工作流——業(yè)務(wù)建模（用業(yè)務(wù)用例對(duì)業(yè)務(wù)過程建模）需求（完成對(duì)系統(tǒng)需求的建模）分析和設(shè)計(jì)（使用體系結(jié)構(gòu)模型、組件模型、對(duì)象模型和序列模型來創(chuàng)建并記錄設(shè)計(jì)模型）實(shí)現(xiàn)（實(shí)現(xiàn)系統(tǒng)中的組件并將他們合理安排在子系統(tǒng)中）測(cè)試（它的執(zhí)行與實(shí)現(xiàn)緊密 聯(lián)系）部署（創(chuàng)建和分發(fā)產(chǎn)品版本并安裝到他們的工作場(chǎng)所）配置和變更管理（支持工作流管理對(duì)系統(tǒng)的變更）項(xiàng)目管理（支持工作流管理系統(tǒng)開發(fā)）環(huán)境（用于提 供軟件開發(fā)團(tuán)隊(duì)可用的合適軟件工具）六個(gè)基本實(shí)踐（反復(fù)的開發(fā)軟件、管理需求、使用基于組件的體系結(jié)構(gòu)、可視化模型軟件、驗(yàn)證軟件質(zhì)量、控制對(duì)軟件的變 更）

軟件系統(tǒng)需求常常分為功能需求、非功能需求和領(lǐng)域需求。1功能需求——包括對(duì)系統(tǒng)應(yīng)該提供的服務(wù)、如 何對(duì)輸入作出反應(yīng)以及系統(tǒng)在特定條件下的行為的描述。應(yīng)該即、既全面（用戶所需服務(wù)都給出描述）又具有一致性（描述不能前后矛盾）2非功能需求——對(duì)系統(tǒng) 提供的服務(wù)或功能給出的約束。分類：產(chǎn)品需求（敘述產(chǎn)品行為的需求，包括可移植性和可用性需求）機(jī)構(gòu)需求（起源于客戶所在的機(jī)構(gòu)和開發(fā)者所在的機(jī)構(gòu)中的政 策和規(guī)定）外部需求（包括所有系統(tǒng)外部因素和開發(fā)過程，如操作、法律、道德需求）3領(lǐng)域需求——來自系統(tǒng)的應(yīng)用領(lǐng)域的需求，反映該領(lǐng)域的特點(diǎn)。

用 戶需求是從用戶角度來描述系統(tǒng)功能和非功能需求，以便讓不具備專業(yè)技術(shù)知識(shí)的用戶能看懂。編寫用戶需求的一些原則：1設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)的格式，保證所有的需求 定義按照該格式書寫。2使用一致的語言。定義強(qiáng)制性需求要使用“必須”；定義希望性需求時(shí)使用“應(yīng)該”。3對(duì)文本加亮來突出顯示關(guān)鍵性需求。4盡量避免用 計(jì)算機(jī)專業(yè)術(shù)語。

系統(tǒng)需求：是用戶需求的擴(kuò)展版，是軟件工程師開始系統(tǒng)設(shè)計(jì)的起點(diǎn)。僅僅描述系統(tǒng)的外部行為和對(duì)它的操作上的限制，而不包括系統(tǒng)應(yīng)該如何設(shè)計(jì)和實(shí)現(xiàn)。

信息持有者（對(duì)系統(tǒng)需求有直接或間接影響力的人）

需 求導(dǎo)入和分析：軟件開發(fā)技術(shù)人員要和客戶及系統(tǒng)最終用戶一起調(diào)查應(yīng)用領(lǐng)域。包括：需求發(fā)現(xiàn)（收集準(zhǔn)備建立的系統(tǒng)和正在使用的系統(tǒng)的信息，并從這些信息當(dāng)中 提取用戶和系統(tǒng)的需求）需求分類和組織、優(yōu)先排序和沖突解決、需求文檔編制（記錄需求并將它作為螺旋下一循環(huán)的輸入，產(chǎn)生形式化的或非形式化的需求文檔）

視點(diǎn)：需求工程的面向視點(diǎn)的方法將導(dǎo)出過程和需求本身都用視點(diǎn)來組織。1交互者視點(diǎn)（代表與系統(tǒng)直接交互的人或其他系統(tǒng)）2間接視點(diǎn)（代表那些不使用系統(tǒng)本身但是以某種方式影響需求的信息持有者）3領(lǐng)域視點(diǎn)（代表領(lǐng)域和影響系統(tǒng)需求的那些約束）

場(chǎng)景：描述人如何與一個(gè)軟件系統(tǒng)交互。

用例：是一種基于場(chǎng)景的需求導(dǎo)出技術(shù)，識(shí)別與系統(tǒng)的單個(gè)交互。

需求管理是一個(gè)對(duì)系統(tǒng)需求變更了解和控制的過程，需要跟蹤各個(gè)需求并維護(hù)他們與所依賴需求之間的關(guān)聯(lián)關(guān)系。分持久和易變的需求。

在 需求管理階段，必須決定一下內(nèi)容——需求識(shí)別、需求管理過程、可追溯策略、CASE工具支持。3類可追溯信息：1源可追溯性信息連接需求到提出需求的信息 持有者和這些需求的基本原理2需求可追溯性信息連接需求文檔中 依賴的需求3設(shè)計(jì)可追溯性信息連接需求到其實(shí)現(xiàn)的設(shè)計(jì)模塊。需求變更管理三個(gè)階段：1問題分析和變更描述階段（要對(duì)問題或變更提議進(jìn)行分析以檢查它的有效 性）2變更分析和成本計(jì)算（對(duì)被提議的變更產(chǎn)生的影響進(jìn)行評(píng)估并且估計(jì)系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)的成本）3變更實(shí)現(xiàn)。體系結(jié)構(gòu)設(shè)計(jì)是設(shè)法建立一個(gè)系統(tǒng)組成來滿足功能性和非功能性需求。所 開發(fā)的體系結(jié)構(gòu)模型會(huì)包括：靜態(tài)結(jié)構(gòu)模型（給出子系統(tǒng)或組件，將其作為一個(gè)個(gè)獨(dú)立的單元開發(fā)）動(dòng)態(tài)過程模型（給出系統(tǒng)在運(yùn)行時(shí)的過程組成）接口模型（定義 每個(gè)子系統(tǒng)從它們的公共接口能得到服務(wù)）關(guān)系模型（給出如子系統(tǒng)間的數(shù)據(jù)流這樣的關(guān)系）分布模型（給出子系統(tǒng)在多臺(tái)計(jì)算機(jī)上是如何分布的）模 塊化分解：將子系統(tǒng)分解為模塊，有兩種策略：1 面向?qū)ο蟮姆纸猓▽⑾到y(tǒng)分解為一組相互通信的對(duì)象）一個(gè)面向?qū)ο蟮南到y(tǒng)體系結(jié)構(gòu)模型是將系統(tǒng)看成一組松散的對(duì)象結(jié)合，這些對(duì)象都有良好的接口定義，對(duì)象請(qǐng) 求其他對(duì)象提供的服務(wù)。優(yōu)勢(shì)在于其對(duì)象間是松散耦合的，對(duì)對(duì)象實(shí)現(xiàn)的修改可以不影響其他對(duì)象，缺點(diǎn)在于對(duì)象必須明確地給出引用的其他對(duì)象的名字及其接口。2 面向功能的流水線操作（將系統(tǒng)分解為一些功能模塊，這些功能模塊接受輸入并轉(zhuǎn)換它們?yōu)檩敵鰯?shù)據(jù)）好處在于1支持換換的復(fù)用2直觀，能將它們的工作理解成輸 入輸出處理3可以簡(jiǎn)單的再系統(tǒng)中增加新的轉(zhuǎn)換4無論作為順序的還是并發(fā)的系統(tǒng)，其實(shí)現(xiàn)容易。其主要缺點(diǎn)是需要一種適合于所有轉(zhuǎn)換的通用格式。

數(shù)據(jù)處理系統(tǒng)是批處理系統(tǒng)，數(shù)據(jù)的輸入和輸出時(shí)成批地從文件或數(shù)據(jù)庫中取出或存入，而不是對(duì)用戶終端進(jìn)行輸入和輸出。形成輸入—處理—輸出結(jié)構(gòu)。事務(wù)處理系統(tǒng)是設(shè)計(jì)用來處理用戶對(duì)數(shù)據(jù)庫信息的查詢或者請(qǐng)求更新數(shù)據(jù)庫的。

快速軟件開發(fā)的原因：新的軟件需要快速開發(fā)來順應(yīng)新的的機(jī)遇，響應(yīng)競(jìng)爭(zhēng)壓力。事實(shí)上很多業(yè)務(wù)都寧愿犧牲一些軟件的質(zhì)量并降低某些需求來贏得快速軟件移交。還因?yàn)闃I(yè)務(wù)運(yùn)營于一個(gè)變化的環(huán)境中，因此實(shí)際上通常不可能導(dǎo)出一個(gè)完全的穩(wěn)定的軟件需求。

基本特征：1描述、設(shè)計(jì)和實(shí)現(xiàn)過程是并發(fā)的2系統(tǒng)通過一系列增量開發(fā)出來3系統(tǒng)用戶界面通常是采用交互式開發(fā)系統(tǒng)開發(fā)的。

敏 捷方法的基本原則：客戶參與（客戶應(yīng)該在開發(fā)過程中始終緊密參與其中）增量式移交（軟件以增量的方式進(jìn)行開發(fā)，客戶指定每個(gè)增量中的包含需求）人非過程（開發(fā)團(tuán)隊(duì)的技術(shù)應(yīng)該得到承認(rèn)和發(fā)揚(yáng)）接收變更（設(shè)計(jì)系統(tǒng)使之適應(yīng)這些變更）保持簡(jiǎn)單性（致力于所開發(fā)的軟件和開發(fā)過程的簡(jiǎn)單性）

極限編程 的經(jīng)驗(yàn)：增量式規(guī)劃（需求記錄在腳本上，開發(fā)者將腳本分解為開發(fā)任務(wù)）小版本（首先開發(fā)能提供業(yè)務(wù)價(jià)值的一個(gè)最小有用集合）簡(jiǎn)單設(shè)計(jì)（只進(jìn)行有限需求設(shè) 計(jì)）測(cè)試優(yōu)先開發(fā)（功能實(shí)現(xiàn)之前，采用一個(gè)自動(dòng)單元測(cè)試框架來書寫此新功能的測(cè)試）重構(gòu)（保持代碼簡(jiǎn)單和可維護(hù)性）結(jié)對(duì)編程（檢查彼此工作提供支持）集體 所有（配對(duì)的開發(fā)人員參與系統(tǒng)的所有方面，所有開發(fā)者享有全部代碼）連續(xù)集成（任務(wù)一完成，就將它集成到大系統(tǒng)中）可忍受速度（不能接受大量超時(shí)）在場(chǎng)客 戶（系統(tǒng)最終用戶的代表應(yīng)該全程滿時(shí)配合XP團(tuán)隊(duì)）

檢驗(yàn)和有效性驗(yàn)證：實(shí)現(xiàn)過程之后，必須對(duì)所開發(fā)的程序進(jìn)行驗(yàn)證，它是對(duì) 這些檢查和分析過程的總稱。檢驗(yàn)的作用是檢查軟件是否符合它的描述。應(yīng)該檢查系統(tǒng)是否滿足了需求所定義的功能的和非功能的需求。有效性驗(yàn)證卻是一個(gè)更一般的過程，其目標(biāo)是保證軟件系 統(tǒng)能滿足客戶的期待。

V&V過程中，系統(tǒng)檢查和分析有兩種互補(bǔ)的方法：1軟件審查或配對(duì)審查——審查可以輔之以某些對(duì)系統(tǒng)源文本或 者是相關(guān)文檔的自動(dòng)分析，是一種靜態(tài)的V&V技術(shù)，因?yàn)槟銦o需再計(jì)算機(jī)上運(yùn)行系統(tǒng)。2包括使用測(cè)試數(shù)據(jù)來運(yùn)行軟件的實(shí)現(xiàn)，檢驗(yàn)軟件的輸出和它的操 作行為，測(cè)試是一種動(dòng)態(tài)的V&V技術(shù)。在軟件過程的不同階段，有2中截然不同的測(cè)試類型：1有效性測(cè)試——試圖證明軟件是用戶所期望的即滿足需求 2缺陷測(cè)試——試圖使缺陷暴露出來，而不是要仿真它在實(shí)際中的使用。發(fā)現(xiàn)程序和描述的不一致。

檢驗(yàn)和有效性驗(yàn)證過程試圖確定軟件系統(tǒng)中存在缺陷，程序調(diào)試時(shí)一個(gè)對(duì)缺陷定位和修正的過程。

軟件測(cè)試的目標(biāo)：1向開發(fā)者和用戶展示軟件滿足它的需求。2為了找出軟件中的缺陷和不足，即軟件的活動(dòng)室不正確的、所不希望的或不符合它的描述的。測(cè)試過程：組件測(cè)試（單個(gè)程序組件的測(cè)試）—系統(tǒng)測(cè)試（對(duì)一組組件集成的系統(tǒng)進(jìn)行測(cè)試）

系統(tǒng)測(cè)試：兩個(gè)階段1集成測(cè)試（測(cè)試小組可以深入到系統(tǒng)源代碼）自上而下集成：首先開發(fā)系統(tǒng)的框架，然后將組件加入到框架中。自下而上集成：集成基礎(chǔ)設(shè)施組件，然后添加功能組件.2發(fā)布測(cè)試（對(duì)要發(fā)布給用戶的系統(tǒng)版本進(jìn)行測(cè)試）測(cè)試原則：是給測(cè)試團(tuán)隊(duì)提示，以幫助他們選擇將揭示系統(tǒng)中的缺陷測(cè)試。接口測(cè)試：目標(biāo)是為了檢測(cè)由于接口的錯(cuò)誤或無效的接口假設(shè)所造成的故障.接口類型1參數(shù)接口（數(shù)據(jù)從一個(gè)過程傳到另外一個(gè)過程）.2共享內(nèi)存接口（內(nèi)存塊為過程或函數(shù)所共享.）3程序接口（子系統(tǒng)封裝一組程序，這些程序?yàn)槠渌酉到y(tǒng)調(diào)用.）4消息傳遞接口（子系統(tǒng)通過傳遞消息請(qǐng)求其他子系統(tǒng)上的服務(wù)）劃分測(cè)試：由于類中成員的這些等價(jià)行為，這些類通常叫做等價(jià)劃分或者域.結(jié)構(gòu)化測(cè)試（白盒測(cè)試）：根據(jù)軟件的結(jié)構(gòu)知識(shí)和實(shí)現(xiàn)知識(shí)導(dǎo)出測(cè)試的測(cè)試用例設(shè)計(jì)方法。路徑測(cè)試：目標(biāo)是要練習(xí)組件或程序中的每一條執(zhí)行路徑。

要 點(diǎn)：測(cè)試只能證明系統(tǒng)中存在錯(cuò)誤，它不能說明系統(tǒng)中不再有缺陷.；組件測(cè)試是組件開發(fā)者的責(zé)任，獨(dú)立的測(cè)試團(tuán)隊(duì)通常執(zhí)行系統(tǒng)測(cè)試.；集成測(cè)試是最初的系統(tǒng) 測(cè)試活動(dòng)，發(fā)布測(cè)試關(guān)心的是測(cè)試客戶版本，應(yīng)該驗(yàn)證所要發(fā)布的系統(tǒng)滿足了它的需求.；在缺陷測(cè)試時(shí)，應(yīng)根據(jù)經(jīng)驗(yàn)和準(zhǔn)則來設(shè)計(jì)測(cè)試用例.；接口測(cè)試是要發(fā)現(xiàn) 組合組件的接口中的缺陷.；等價(jià)劃分是導(dǎo)出測(cè)試用例的一個(gè)方法，需要找出輸入和輸出數(shù)據(jù)集合上的劃分并用這些劃分中的數(shù)據(jù)執(zhí)行系統(tǒng).；結(jié)構(gòu)化分析依賴于分 析一個(gè)程序由此來確定路徑.；測(cè)試自動(dòng)化通過使用一系列軟件工具支持測(cè)試過程，以減少測(cè)試過程的花費(fèi).什么是黑盒測(cè)試和白盒測(cè)試？ 任何工程產(chǎn)品（注意是任何工程產(chǎn)品）都可以使用以下兩種方法之一進(jìn)行測(cè)試。黑盒測(cè)試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測(cè)試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。白盒測(cè)試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測(cè)試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。軟件的黑盒測(cè)試意味著測(cè)試要在軟件的接口處進(jìn)行。這種方法是把測(cè)試對(duì)象看做一個(gè)黑盒子，測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需 求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測(cè)試又叫功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤：

1、是否有不正確或遺漏的功能？

2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？

3、是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息（例如數(shù)據(jù)文件）訪問錯(cuò)誤？

4、性能上是否能夠滿足要求？

5、是否有初始化或終止性錯(cuò)誤？ 軟件的白盒測(cè)試是對(duì)軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測(cè)試對(duì)象看做一個(gè)打開的盒子，它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選 擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。白 盒測(cè)試主要是想對(duì)程序模塊進(jìn)行如下檢查：

1、對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測(cè)試一遍。

2、對(duì)所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測(cè)一遍。

3、在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。

4、測(cè)試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。以上事實(shí)說明，軟件測(cè)試有一個(gè)致命的缺陷，即測(cè)試的不完全、不徹底性。由于任何程序只能進(jìn)行少量（相對(duì)于窮舉的巨大數(shù)量而言）的有限的測(cè)試，在未發(fā)現(xiàn)錯(cuò)誤 時(shí)，不能說明程序中沒有錯(cuò)誤。

配置管理的重要性：涉及程序和標(biāo)準(zhǔn)的發(fā)展和應(yīng)用來管理不斷發(fā)展的軟件產(chǎn)品；配置管理有時(shí)候被看做是軟件質(zhì)量管理過程的一部分；當(dāng)進(jìn)行配置管理時(shí)，受控系統(tǒng)有時(shí)也稱為基線，因?yàn)樗鼈兪鞘芸剡M(jìn)化的一個(gè)起點(diǎn).四種主要配置管理活動(dòng)： 配置管理規(guī)劃：描述配置管理應(yīng)該使用的標(biāo)準(zhǔn)和規(guī)劃。1配置項(xiàng)識(shí)別（應(yīng)該定義文檔命名規(guī)則，以便類型相同的文檔命名也類似）2配置數(shù)據(jù)庫（用于記錄與配置有關(guān)的所有信息）

變更管理：需求不斷發(fā)生變化，系統(tǒng)也相應(yīng)作出變更。關(guān)注的是對(duì)變化保持跟蹤，并確保它們用最具成本效益的方式實(shí)施.變更請(qǐng)求表（記錄了變更的建議、變更的請(qǐng)求、變更的原因以及變更的迫切性.它還記錄了變更評(píng)估、影響分析、變更成本和建議.）

版本和發(fā)布管理：是識(shí)別和追蹤一個(gè)系統(tǒng)的各個(gè)版本和發(fā)布的過程。版本 一個(gè)系統(tǒng)版本就是一個(gè)系統(tǒng)實(shí)例，在某種程度上有別于其他系統(tǒng)實(shí)例.變體 有一些版本可能在功能上沒有什么區(qū)別，只是為了不同的硬件或軟件配置而設(shè)計(jì).發(fā)布版本： 一個(gè)系統(tǒng)的發(fā)布版本就是要分發(fā)給客戶的版本.版本管理規(guī)程應(yīng)該規(guī)定明確的標(biāo)識(shí)每個(gè)組件版本的方法.三種基本的版本標(biāo)識(shí)方法 1版本編號(hào);2基于屬性的標(biāo)識(shí);3面向變更的標(biāo)識(shí).系統(tǒng)構(gòu)建：把軟件組件編譯和連接成一個(gè)程序并在特定目標(biāo)配置上運(yùn)行的過程.CASE工具可用于支持所有的配置管理活動(dòng).支持配置管理的CASE工具可以是一些獨(dú)立的工具分別用來支持變更管理、版本管理和系統(tǒng)構(gòu)建，也可以是集成的系統(tǒng)，為所有的配置管理支持提供一個(gè)一致的接口.

第二篇：軟件工程重點(diǎn)總結(jié)

1、什么是軟件危機(jī)？

軟件危機(jī)泛指在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。

2、軟件危機(jī)的主要表現(xiàn)

（1）對(duì)軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確

（2）用戶對(duì)“已完成的”軟件系統(tǒng)不滿意現(xiàn)象經(jīng)常發(fā)生

（3）軟件產(chǎn)品質(zhì)量往往靠不住

（4）軟件往往是不可維護(hù)的（5）軟件通常沒有適當(dāng)?shù)奈臋n資料

（6）軟件成本在計(jì)算機(jī)系統(tǒng)總成本中所占的比例逐年上升

（7）軟件開發(fā)生產(chǎn)效率提高的速度，遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢(shì)

3、軟件危機(jī)產(chǎn)生的原因

(1)來自軟件自身的特點(diǎn)

是軟件系統(tǒng)的邏輯部件，缺乏可見性，管理和控制軟件開發(fā)過程相當(dāng)困難；規(guī)模龐大、復(fù)雜，修改、維護(hù)困難。

(2)軟件開發(fā)與維護(hù)的方法不當(dāng)

忽視需求分析；認(rèn)為軟件開發(fā)等于程序編寫；輕視軟件維護(hù)。

4、如何消除軟件危機(jī)？

（1）對(duì)計(jì)算機(jī)軟件有一個(gè)正確的認(rèn)識(shí)(軟件≠程序）

（2）必須充分認(rèn)識(shí)到軟件開發(fā)不是某種個(gè)體勞動(dòng)的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項(xiàng)目

（3）推廣使用在實(shí)踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法

（4）開發(fā)和使用更好的軟件工具

5、面向?qū)ο蟮娜N模型：對(duì)象模型 動(dòng)態(tài)模型 功能模型 P2166、模塊獨(dú)立性的兩個(gè)標(biāo)準(zhǔn)：耦合 內(nèi)聚 P977、軟件測(cè)試方法：黑盒測(cè)試 白盒測(cè)試 P1518、軟件調(diào)試的途徑：蠻干法 回溯法 原因排除法 P1789、可行性研究：確定問題是否有行得通的解決辦法 P3510、需求分析：準(zhǔn)確地回答“系統(tǒng)必須干什么”這個(gè)問題 P5511、軟件成分的重用級(jí)別：代碼重用 設(shè)計(jì)結(jié)果重用 分析結(jié)果重用

可被重用的軟件成分有：項(xiàng)目計(jì)劃，成本估計(jì)，體系結(jié)構(gòu)，需求模型和規(guī)格說明，設(shè)計(jì)，源代碼，用戶文檔和技術(shù)文檔，用戶界面，數(shù)據(jù)，測(cè)試用例。

12、軟件可靠性的定義：軟件在給定的時(shí)間間隔內(nèi)，按照規(guī)格說明書的規(guī)定成功地運(yùn)行的概率。

軟件可用性的定義：程序在給定的時(shí)間點(diǎn)，按照規(guī)格說明書的規(guī)定，成功地運(yùn)行的概率?？煽啃耘c可用性之間的主要差別是，可靠性意味著在0到t這段時(shí)間內(nèi)系統(tǒng)沒有失效，而可用性只意味著在時(shí)刻t，系統(tǒng)是正常運(yùn)行的。P17913、白盒測(cè)試：邏輯覆蓋 控制結(jié)構(gòu)測(cè)試 P162

黑盒測(cè)試：等價(jià)劃分 邊界值分析 調(diào)試 P171

環(huán)形復(fù)雜度的計(jì)算：復(fù)雜度=邊數(shù)-點(diǎn)數(shù)+2P13714、面向?qū)ο蟮?個(gè)子模式：對(duì)象模型 動(dòng)態(tài)模型 功能模型 P232

對(duì)象模型的5個(gè)層次：主題層 類與對(duì)象層 結(jié)構(gòu)層 屬性層 服務(wù)層 P23215、軟件定義階段干什么事：確定軟件開發(fā)工程必須完成的總目標(biāo)；確定工程的可行性；導(dǎo)

出實(shí)現(xiàn)工程目標(biāo)應(yīng)該采用的策略及系統(tǒng)必須完成的功能；估計(jì)完成該工程需要的資源和成本，并制定工程進(jìn)度表。

16、類和對(duì)象的關(guān)系：類是具有相同數(shù)據(jù)和相同操作的一組相似對(duì)象的定義，也就是說，類

是對(duì)具有相同屬性和行為的一個(gè)或多個(gè)對(duì)象的描述。類是支持繼承的抽象數(shù)據(jù)類型，而對(duì)象就是類的實(shí)例。P21117、UML有哪些圖？ P2171、用例圖：展示系統(tǒng)外部的各類執(zhí)行者與系統(tǒng)提供的各種用例之間的關(guān)系

2、類圖：展示系統(tǒng)中類的靜態(tài)結(jié)構(gòu)

3、對(duì)象圖：是類圖的一種實(shí)例化圖

4、狀態(tài)圖：描述一類對(duì)象具有的所有可能的狀態(tài)及其轉(zhuǎn)移關(guān)系

5、時(shí)序圖：展示對(duì)象之間的一種動(dòng)態(tài)協(xié)作關(guān)系

6、合作圖：從另一個(gè)角度展示對(duì)象之間的動(dòng)態(tài)協(xié)作關(guān)系

7、活動(dòng)圖：展示系統(tǒng)中各種活動(dòng)的執(zhí)行流程

8、構(gòu)件圖：展示程序代碼的物理結(jié)構(gòu)

9、配置圖：展示軟件在硬件環(huán)境中的配置關(guān)系

18、能力成熟度模型（CMM）：初始級(jí) 可重復(fù)級(jí) 已定義級(jí) 已管理級(jí) 優(yōu)化級(jí) P31119、什么是軟件生命周期模型?試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優(yōu)

缺點(diǎn)，說明每種模型的適用范圍。P33習(xí)題1.720、軟件的可維護(hù)性定義：維護(hù)人員理解、改正、改動(dòng)或改進(jìn)這個(gè)軟件的難易程度。決定可維護(hù)性的因素：可理解性 可測(cè)試性 可修改性 可移植性 可重用性。

文檔是影響可維護(hù)性的決定性因素。P19521、如何評(píng)價(jià)軟件規(guī)格說明書？

從四個(gè)方面：一致性 完整性 現(xiàn)實(shí)性 有效性 P7022、層次圖 P10223、深度：軟件結(jié)構(gòu)中控制的層數(shù) P100

寬度：軟件結(jié)構(gòu)中同一個(gè)層次上的總數(shù)的最大值

扇出：一個(gè)模塊直接控制（調(diào)用）的模塊數(shù)目

散入：一個(gè)模塊被多少個(gè)上級(jí)模塊直接調(diào)用

24、面向數(shù)據(jù)流的設(shè)計(jì)方法 P10425、類構(gòu)件的重用方式：實(shí)例重用 繼承重用 多態(tài)重用

1.什么是軟件工程？軟件工程和計(jì)算機(jī)科學(xué)有何區(qū)別？

軟件工程是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科。

計(jì)算機(jī)科學(xué)研究的是構(gòu)成計(jì)算機(jī)和軟件系統(tǒng)基礎(chǔ)的有關(guān)理論和方法，而軟件工程則是研究軟件制作中的實(shí)際問題。

2、流程圖與數(shù)據(jù)流圖有什么主要區(qū)別？

（1）數(shù)據(jù)流圖（date flow diagram , DFD），是SA方法中用于表示系統(tǒng)邏輯模型的一種工具，它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的過程，由于它只反映系統(tǒng)必須完成的邏輯功能，所以它是一種功能模型，是從數(shù)據(jù)的角度來描述一個(gè)系統(tǒng)的；而流程圖則是從對(duì)數(shù)據(jù)加工的角度來描述系統(tǒng)的；

（2）數(shù)據(jù)流圖中的箭頭是數(shù)據(jù)流，而流程圖中的箭頭則是控制流,它表達(dá)的是程序執(zhí)行的次序；

（3）數(shù)據(jù)流圖適合于宏觀地分析一個(gè)組織業(yè)務(wù)概況,而程序流程圖只適合于描述系統(tǒng)中某個(gè)加工的執(zhí)行細(xì)節(jié)。

（4）數(shù)據(jù)流程圖應(yīng)該重點(diǎn)描述了數(shù)據(jù)加工的過程，主要是模塊內(nèi)部，數(shù)據(jù)流圖則是描述模塊之間的關(guān)系。

3．軟件需求分析的任務(wù)是什么？有哪些主要步驟？

需求分析的基本任務(wù)是深入描述軟件的功能和性能、確定軟件設(shè)計(jì)的約束和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)、定義軟件的其它有效性需求，總之，需求分析的任務(wù)就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的 “做什么” 的問題。

主要步驟：

1.問題識(shí)別

(1)功能需求：明確所開發(fā)的軟件必須具備什么樣的功能。

(2)性能需求：明確待開發(fā)的軟件的技術(shù)性能指標(biāo)。

(3)環(huán)境需求：明確軟件運(yùn)行時(shí)所需要的軟、硬件的要求。

(4)用戶界面需求：明確人機(jī)交互方式、輸入輸出數(shù)據(jù)格式。

2.分析與綜合，導(dǎo)出軟件的邏輯模型

分析人員對(duì)獲取的需求，進(jìn)行一致性的分析檢查，在分析、綜合中逐步細(xì)化軟件功能，劃分成各個(gè)子功能。用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。

3.編寫文檔

(1)編寫“需求規(guī)格說明書”，把雙方共同的理解與分析結(jié)果用規(guī)范的方式描述出來，作為今后各項(xiàng)工作的基礎(chǔ)。

(2)編寫初步用戶使用手冊(cè)，著重反映被開發(fā)軟件的用戶功能界面和用戶使用的具體要求，用戶手冊(cè)能強(qiáng)制分析人員從用戶使用的觀點(diǎn)考慮軟件。

(3)編寫確認(rèn)測(cè)試計(jì)劃，作為今后確認(rèn)和驗(yàn)收的依據(jù)。

(4)修改完善軟件開發(fā)計(jì)劃。在需求分析階段對(duì)待開發(fā)的系統(tǒng)有了更進(jìn)一步的了解，所以能更準(zhǔn)確地估計(jì)開發(fā)成本、進(jìn)度及資源要求，因此對(duì)原計(jì)劃要進(jìn)行適當(dāng)修正。

4．簡(jiǎn)述結(jié)構(gòu)化分析、設(shè)計(jì)的要點(diǎn)：

結(jié)構(gòu)化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析。

其要點(diǎn)是“自頂向下” 地開發(fā)系統(tǒng),由整體到各組成部分,由表及里,由抽象到具體,逐步求精.(1)模塊化

(2)由頂向下,逐步求精.(3)上層模塊分解為下層模塊,有三種不同的結(jié)構(gòu)形式,即順序結(jié)構(gòu),選擇結(jié)構(gòu)和循環(huán)結(jié)構(gòu).5．?dāng)?shù)據(jù)字典包含哪些主要內(nèi)容？

數(shù)據(jù)字典通常包括數(shù)據(jù)項(xiàng)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)和處理過程五個(gè)部分.據(jù)字典內(nèi)容包括：

數(shù)據(jù)庫中所有模式對(duì)象的信息，如表、視圖、簇、及索引等。

分配多少空間，當(dāng)前使用了多少空間等。

列的缺省值。

約束信息的完整性。

用戶的名字。

用戶及角色被授予的權(quán)限。

用戶訪問或使用的審計(jì)信息。

其它產(chǎn)生的數(shù)據(jù)庫信息。

6．軟件測(cè)試的目標(biāo)是什么，有哪幾種主要有測(cè)試方法？

軟件測(cè)試的目標(biāo)：

(1)測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程；

(2)好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案；

(3)成功的測(cè)試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。

軟件測(cè)試的方法有黑盒測(cè)試、白盒測(cè)試。

7．白盒測(cè)試主要有哪些覆蓋？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點(diǎn)覆蓋、邊覆蓋、路徑覆蓋

8、選擇一種程序設(shè)計(jì)語言的主要有哪些依據(jù)？

為了使程序容易測(cè)試和維護(hù)以減少生命周期的總成本，選用的高級(jí)語言應(yīng)該有理想的模塊化機(jī)制，以及可讀性好的控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)；為了便于調(diào)試和提高軟件可靠性，語言特點(diǎn)應(yīng)該使編譯程序能夠盡可能多地發(fā)現(xiàn)程序中的錯(cuò)誤；為了降低軟件開發(fā)和維護(hù)的成本，選用的語言應(yīng)該有良好的獨(dú)立編譯機(jī)制。上述這些要求是選擇語言的理想標(biāo)準(zhǔn)，但是在實(shí)際選用語言時(shí)不能僅僅考慮理論上的標(biāo)準(zhǔn)，還必須同時(shí)考慮實(shí)用方面的各種限制。

(1)系統(tǒng)用戶的要求

(2)可以使用的編譯程序

(3)可以得到的軟件工具

(4)系統(tǒng)規(guī)模

(5)程序員的知識(shí)

(6)軟件可移植性要求

(7)軟件的應(yīng)用領(lǐng)域

9．軟件的維護(hù)的目標(biāo)是什么，有哪幾種維護(hù)類型？

糾正在使用過程中暴露出來的錯(cuò)誤而進(jìn)行的改進(jìn)性維護(hù)，適應(yīng)外部環(huán)境的變化而進(jìn)行的適應(yīng)性維護(hù)，改進(jìn)原有的軟件而進(jìn)行的完善性維護(hù)，以及改進(jìn)將來的可維護(hù)性和可靠性而進(jìn)行的預(yù)防性維護(hù)。

軟件維護(hù)主要?jiǎng)澐譃榧m錯(cuò)性維護(hù)、適應(yīng)性維護(hù)和完善性維護(hù)。

(1)糾錯(cuò)性維護(hù)。由于前期的測(cè)試不可能揭露軟件系統(tǒng)中所有潛在的錯(cuò)誤，用戶在使用軟件時(shí)仍將會(huì)遇到錯(cuò)誤，診斷和改正這些錯(cuò)誤的過程稱為糾錯(cuò)性維護(hù)。

(2)適應(yīng)性維護(hù)。由于新的硬件設(shè)備不斷推出，操作系統(tǒng)和編譯系統(tǒng)也不斷地升級(jí)，為了使軟件能適應(yīng)新的環(huán)境而引起的程序修改和擴(kuò)充活動(dòng)稱為適應(yīng)性維護(hù)。

(3)完善性維護(hù)。在軟件的正常使用過程中，用戶還會(huì)不斷地提出新的需求。為了滿足用戶新的需求而增加軟件功能的活動(dòng)稱為完善性維護(hù)。

10．簡(jiǎn)述提高軟件質(zhì)量的主要措施。

復(fù)審：是在軟件生命周期每個(gè)階段結(jié)束之前，都采用一定的標(biāo)準(zhǔn)對(duì)該段產(chǎn)生的軟件配置成分進(jìn)行嚴(yán)格的正式或非正式的檢測(cè)。

復(fù)查：是檢查已有的材料，以斷定在軟件生命周期某個(gè)階段的工作是否能夠開始或繼續(xù)。管理復(fù)審：是向開發(fā)組織或使用部門的管理人員提供有關(guān)項(xiàng)目的總體狀況、成本和進(jìn)度等方面的情況，以便他們從管理角度對(duì)開發(fā)工作進(jìn)行審查。

測(cè)試：包括測(cè)試計(jì)劃、測(cè)試過程和測(cè)試結(jié)果3個(gè)階段。

11．面向?qū)ο笕绾螌?shí)現(xiàn)模塊獨(dú)立性，其偶合和內(nèi)聚的含義是什么？

因?yàn)閷?duì)象是由數(shù)據(jù)及可以對(duì)這些數(shù)據(jù)施加的操作所組成的統(tǒng)一體，而且對(duì)象是以數(shù)據(jù)為中心的，操作圍繞對(duì)其數(shù)據(jù)所需做的處理來設(shè)置，沒有無關(guān)的操作。因此，對(duì)象內(nèi)部各種元素彼此結(jié)合得很緊密。內(nèi)聚性相當(dāng)強(qiáng)，由于完成對(duì)象所需要的元素（數(shù)據(jù)和方法）基本上都被封裝在對(duì)象內(nèi)部，它與外界的聯(lián)系自然就比較少。因此，對(duì)象之間的耦合通常比較松?？傊嫦?qū)ο笫褂脤?duì)象、類、繼承和消息的方法，既使用類和繼承等機(jī)制，而且對(duì)象之間僅能通過傳遞消息實(shí)現(xiàn)彼此通信來實(shí)現(xiàn)模塊的獨(dú)立性。

12．面向?qū)ο蠛兔嫦蜻^程軟件工程有哪些區(qū)別？

（1）面向過程就是分析出解決問題所需要的步驟，然后用函數(shù)把這些步驟一步一步實(shí)現(xiàn)，使用的時(shí)候一個(gè)一個(gè)依次調(diào)用就可以了。面向?qū)ο笫前褬?gòu)成問題事務(wù)分解成各個(gè)對(duì)象，建立對(duì)象的目的不是為了完成一個(gè)步驟，而是為了描敘某個(gè)事物在整個(gè)解決問題的步驟中的行為。（2）面向過程是把一件事一項(xiàng)工程分解成為一個(gè)個(gè)小的功能,用一個(gè)個(gè)函數(shù)來實(shí)現(xiàn).面向?qū)ο笫前咽虑榭闯墒且粋€(gè)個(gè)小的對(duì)象組成的,或者說一個(gè)個(gè)小部分組成的,這些對(duì)象之間的相互關(guān)系,構(gòu)成了整個(gè)項(xiàng)目.在面向?qū)ο蟮乃枷胫?，萬物皆對(duì)象。而“類”，就是對(duì)象的抽象或者說是概括。

13.簡(jiǎn)述對(duì)象、類、消息、方法的基本概念。

(1)對(duì)象是人們要進(jìn)行研究的任何事物，從最簡(jiǎn)單的整數(shù)到復(fù)雜的飛機(jī)等均可看作對(duì)象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計(jì)劃或事件。

(2)類是具有相同或相似性質(zhì)的對(duì)象的抽象。對(duì)象的抽象是類，類的具體化就是對(duì)象，也可以說類的實(shí)例是對(duì)象。類具有屬性，它是對(duì)象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性。類具有操作，它是對(duì)象的行為的抽象，用操作名和實(shí)現(xiàn)該操作的方法來描述。

(3)對(duì)象之間進(jìn)行通信的結(jié)構(gòu)叫做消息。在對(duì)象的操作中，當(dāng)一個(gè)消息發(fā)送給某個(gè)對(duì)象時(shí)，消息包含接收對(duì)象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對(duì)象名、發(fā)送給該對(duì)象的消息名（即對(duì)象名、方法名）。一般還要對(duì)參數(shù)加以說明，參數(shù)可以是認(rèn)識(shí)該消息的對(duì)象所知道的變量名，或者是所有對(duì)象都知道的全局變量名。

(4)類中操作的實(shí)現(xiàn)過程叫做方法，一個(gè)方法有方法名、參數(shù)、方法體。

14．簡(jiǎn)述面向?qū)ο蠓治鲈O(shè)計(jì)的三個(gè)模型。

答：三個(gè)模型：對(duì)象模型、動(dòng)態(tài)模型、功能模型

（1）對(duì)象模型描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，包括類和對(duì)象，它們的屬性和操作，以及它們之間的關(guān)系。構(gòu)造對(duì)象模型的目的在于找出與應(yīng)用程序密切相關(guān)的概念。對(duì)象模型用包含對(duì)象及對(duì)象的關(guān)系圖表示。

（2）動(dòng)態(tài)模型著重于系統(tǒng)的控制邏輯，考察在任何時(shí)候?qū)ο蠹捌潢P(guān)系的改變，描述這些涉及時(shí)序和改變的狀態(tài)。動(dòng)態(tài)模型包括狀態(tài)圖和事件跟蹤圖。狀態(tài)圖是一個(gè)狀態(tài)和事件的網(wǎng)絡(luò)，側(cè)重于描述每一類對(duì)象的動(dòng)態(tài)行為。事件跟蹤圖則側(cè)重于說明系統(tǒng)執(zhí)行過程中的一個(gè)特點(diǎn)“場(chǎng)景”，也叫做腳本(scenarios)，是完成系統(tǒng)某個(gè)功能的一個(gè)事件序列。腳本通常起始于一個(gè)系統(tǒng)外部的輸入事件，結(jié)束于一個(gè)系統(tǒng)外部的輸出事件。

（3）功能模型著重于系統(tǒng)內(nèi)部數(shù)據(jù)的傳送和處理。功能模型表明，通過計(jì)算，從輸出數(shù)據(jù)能得到什么樣的輸出數(shù)據(jù)，但不考慮參加計(jì)算的數(shù)據(jù)按什么時(shí)序執(zhí)行。功能模型由多個(gè)數(shù)據(jù)流圖組成，它們指明從外部輸出，通過操作和內(nèi)部存儲(chǔ)，直到外部輸出的整個(gè)數(shù)據(jù)流情況。功能模型還包括了對(duì)象模型內(nèi)部數(shù)據(jù)間的限制。功能模型中的數(shù)據(jù)流圖往往形成一個(gè)層次結(jié)構(gòu)，一個(gè)數(shù)據(jù)流圖的過程可以由下一層的數(shù)據(jù)流圖作進(jìn)一步的說明。

第三篇：軟件工程 重點(diǎn)歸納

程序：能夠完成預(yù)定功能、并滿足性能要求的可執(zhí)行的指令序列。

軟件:計(jì)算機(jī)程序以及開發(fā)、使用和維護(hù)程序所需要的所有文檔,是包括程序、數(shù)據(jù)及其相關(guān)文檔的完整集合。

軟件=知識(shí)+程序+文檔+數(shù)據(jù)

1、程序設(shè)計(jì)時(shí)期（1946～1956）軟件=程序

開發(fā)方式：個(gè)體

主要特征：計(jì)算機(jī)硬件=計(jì)算機(jī)

用途少，規(guī)模?。徊蛔鳛樯唐?；

開發(fā)者=使用者：自己開發(fā)，自己使用。

2、程序系統(tǒng)時(shí)期（1956～1968）軟件=程序+說明

開發(fā)方式：作坊式

主要特征：程序規(guī)模增大，多人分工合作。

軟件作為商品，即程序設(shè)計(jì)者≠使用者；

程序開發(fā)和使用的文檔資料已不可缺少。

3、軟件工程時(shí)期（1968～現(xiàn)在）軟件=程序+數(shù)據(jù)+文檔

開發(fā)方式：工程化

主要特征：按工程管理的方法管理整個(gè)軟件開發(fā)過程。

軟件生產(chǎn)的進(jìn)度、數(shù)量、質(zhì)量、成本與社會(huì)對(duì)軟件的需求量和希望要求甚遠(yuǎn)，開發(fā)成本和進(jìn)度難以控制，指令難以保證，與硬件發(fā)展形成強(qiáng)烈反差。這就是所謂的“軟件危機(jī)”。--現(xiàn)實(shí)與希望形成的巨大落差 產(chǎn)生軟件危機(jī)的原因 ●客觀原因：

軟件是手工勞動(dòng)，是智力產(chǎn)品----生產(chǎn)率低。

軟件是邏輯實(shí)體，出錯(cuò)容易，糾錯(cuò)困難。

軟件的復(fù)雜性使得僅靠人的智力難以駕馭?！裰饔^原因

開發(fā)方式：認(rèn)為開發(fā)軟件就是寫程序。

組織方式：作坊式的生產(chǎn)方式；開發(fā)無計(jì)劃、開發(fā)過程無規(guī)范、開發(fā)過程難控制。

用戶方面：對(duì)軟件需求描述不精確。

開發(fā)人員方面：對(duì)用戶需求的理解與用戶本來愿望有差異，相互之間的信息交流不及時(shí)、不準(zhǔn)確、有誤解。

成本、進(jìn)度和質(zhì)量

軟件工程三要素：過程、方法和工具

軟件生存周期包括三個(gè)時(shí)期：

軟件定義

問題定義、可行性研究、需求分析

? 需求規(guī)格說明書 ? 初步用戶手冊(cè) ? 軟件初步測(cè)試計(jì)劃

軟件開發(fā) 概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼及模塊測(cè)試、綜合測(cè)試

軟件使用和維護(hù) 改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)

軟件過程模型--瀑布模型

軟件過程模型—螺旋模型

數(shù)據(jù)字典的內(nèi)容：

數(shù)據(jù)流

數(shù)據(jù)元素

數(shù)據(jù)存儲(chǔ)

處理

數(shù)據(jù)結(jié)構(gòu)的定義：描述數(shù)據(jù)結(jié)構(gòu)的組成（1）定義式

數(shù)據(jù)結(jié)構(gòu)名=數(shù)據(jù)項(xiàng)1+數(shù)據(jù)項(xiàng)2+……+數(shù)據(jù)項(xiàng)n 數(shù)據(jù)定義使用的符號(hào)： = 定義為

+ 和：連接兩個(gè)分量 [ ] 選擇：表示從中選擇一項(xiàng)。{ } 重復(fù)：表示由0個(gè)或多個(gè)組成。

m{ }n 重復(fù)：表示至少出現(xiàn)m次，至多出現(xiàn)n次。

（）可選：表示其中的內(nèi)容可出現(xiàn)，也可不出現(xiàn)。

IPO（Input/process/output）圖是輸入/處理/輸出的簡(jiǎn)稱，是由IBM公司發(fā)展完善起來的一種圖形工具，能方便地描繪輸入數(shù)據(jù)、數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關(guān)系。

ER模型包括“實(shí)體”、“聯(lián)系”和“屬性”三個(gè)基本部分。

實(shí)體：是客觀世界中存在的且可以相互區(qū)分的 物。如：職工、教師、產(chǎn)品等 聯(lián)系：客觀世界中事物間的聯(lián)系。往往表示實(shí)體間發(fā)生的某種行為。屬性：是實(shí)體或聯(lián)系具有的性質(zhì)，通常一個(gè)實(shí)體由若干個(gè)性質(zhì)來刻畫。

通常用“范式”（Normal Formas）定義消除數(shù)據(jù)的冗余的程度。

總體設(shè)計(jì)過程

一、系統(tǒng)體系結(jié)構(gòu)設(shè)計(jì)

二、軟件結(jié)構(gòu)設(shè)計(jì)

三、數(shù)據(jù)庫設(shè)計(jì)

四、制定測(cè)試計(jì)劃

五、書寫文檔

六、審核和復(fù)審

軟件設(shè)計(jì)原理

? 抽象——抽出事物的本質(zhì)特征而暫不考慮它們的細(xì)節(jié)。

? 抽象和求精是一對(duì)互補(bǔ)的概念。求精則是幫助設(shè)計(jì)者逐步揭示出低層細(xì)節(jié)。這兩個(gè)概念都有助于幫助設(shè)計(jì)者在設(shè)計(jì)演化過程中構(gòu)造出完整的設(shè)計(jì)模型。

? 模塊化

? 信息隱蔽（和局部化）——信息隱蔽是模塊設(shè)計(jì)的基本原則，局部化是實(shí)現(xiàn)信息

隱蔽的重要方法。? 模塊獨(dú)立

? 模塊的獨(dú)立程度的度量標(biāo)準(zhǔn)——內(nèi)聚:衡量一個(gè)模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度；耦合:衡量不同模塊彼此間互相依賴（連接）的緊密程度。

層次圖：描述軟件的層次結(jié)構(gòu)（H圖）。

層次圖中每個(gè)矩形框代表一個(gè)模塊，矩形框之間的連線表示模塊調(diào)用關(guān)系。

層次圖適合用來描繪軟件的層次結(jié)構(gòu)。HIPO圖：層次圖+IPO圖

對(duì)H圖的每個(gè)方框，都有一張IPO圖與之對(duì)應(yīng)，來描述方框所代表的模塊的處理過程。并且對(duì)每個(gè)IPO圖都對(duì)應(yīng)H圖中方框相同的標(biāo)記和編號(hào)，便于追蹤。

面向數(shù)據(jù)流的設(shè)計(jì)方法

? 概念

? 變換流分析設(shè)計(jì) ? 事物流分析設(shè)計(jì) ? 混合流分析設(shè)計(jì) ? 設(shè)計(jì)優(yōu)化

PAD是問題分析圖（Problem Analysis Diagram）

變換流：

事務(wù)流：

概要設(shè)計(jì)小結(jié)

一、任務(wù)

1、系統(tǒng)體系結(jié)構(gòu)設(shè)計(jì)：確定系統(tǒng)的總體物理實(shí)現(xiàn)方案。

2、軟件結(jié)構(gòu)設(shè)計(jì)：確定模塊和模塊間的動(dòng)態(tài)調(diào)用管理。

3、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)（或數(shù)據(jù)庫設(shè)計(jì)）：確定系統(tǒng)中數(shù)據(jù)的總體結(jié)構(gòu)。（數(shù)據(jù)庫：邏輯設(shè)計(jì)、物理設(shè)計(jì)、安全性設(shè)計(jì)）。

4、接口設(shè)計(jì)：外部接口、人機(jī)界面設(shè)計(jì)

二、設(shè)計(jì)原理

1、模塊獨(dú)立性原理：信息隱蔽、耦合、內(nèi)聚

2、思維工具：抽象

3：?jiǎn)l(fā)式規(guī)則：改進(jìn)軟件結(jié)構(gòu)，提高系統(tǒng)質(zhì)量

三、設(shè)計(jì)工具： HIPO圖、結(jié)構(gòu)圖

四、面向數(shù)據(jù)流的設(shè)計(jì)方法----結(jié)構(gòu)化設(shè)計(jì)方法

1、從分析型的數(shù)據(jù)流圖向軟件結(jié)構(gòu)的轉(zhuǎn)換

2、從事務(wù)型的數(shù)據(jù)流圖向軟件結(jié)構(gòu)的轉(zhuǎn)換

詳細(xì)設(shè)計(jì)工具分為圖形、表格和語言三類。主要工具有： ■程序流程圖 ■盒圖（N-S圖）■PAD圖 ■判定表 ■判定樹

■過程設(shè)計(jì)語言（PDL）

McCabe方法根據(jù)程序控制流的復(fù)雜程度來定量度量程序的復(fù)雜程度，這樣度量出的結(jié)果稱為程序的環(huán)行復(fù)雜度。

用戶界面設(shè)計(jì)原則

1、置用戶于控制之下。用戶界面能夠?qū)τ脩舻牟僮髯龀銮‘?dāng)?shù)姆磻?yīng)，并幫助用戶完成需要的工作。

2、減少用戶的記憶負(fù)擔(dān)。系統(tǒng)應(yīng)該“記住”有關(guān)的信息，通過默認(rèn)項(xiàng)、快捷方式或界面視覺減少用戶的記憶負(fù)擔(dān)。

3、保持界面的一致性。用戶應(yīng)該以一致的方式展示和獲取信息。問題：

●系統(tǒng)響應(yīng)時(shí)間 ●用戶幫助設(shè)施 ●錯(cuò)誤信息處理 ●命令交互

界面設(shè)計(jì)包括：

●界面對(duì)話設(shè)計(jì)

●數(shù)據(jù)輸入界面設(shè)計(jì)

●數(shù)據(jù)輸出設(shè)計(jì)（屏幕顯示設(shè)計(jì)）。

常用的界面設(shè)計(jì)元素有：

●問題描述語言

●數(shù)據(jù)表格

●圖形與圖標(biāo)

●菜單

●對(duì)話框

●窗口

G.J.Myers關(guān)于軟件測(cè)試的觀點(diǎn):

1、測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程。

2、好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案。

3、成功的測(cè)試是發(fā)現(xiàn)了迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。

E.D.Dijkstra:程序測(cè)試能證明程序中的錯(cuò)誤，是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)。必須記?。簻y(cè)試無法說明錯(cuò)誤不存在，它只能表示軟件錯(cuò)誤已經(jīng)出現(xiàn)。

軟件測(cè)試準(zhǔn)則

1、以用戶需求為基準(zhǔn)

2、嚴(yán)格執(zhí)行測(cè)試計(jì)劃

3、測(cè)試中的群集現(xiàn)象

2-8原理：80%的錯(cuò)誤可能集中在20%的模塊中。

4、程序邏輯覆蓋程度

5、第三方獨(dú)立進(jìn)行測(cè)試

6、合理的輸入和不合理的輸入

7、預(yù)期輸出結(jié)果

步驟：

1、模塊測(cè)試

2、子系統(tǒng)測(cè)試

3、系統(tǒng)測(cè)試

4、驗(yàn)收測(cè)試

5、平行運(yùn)行

確認(rèn)測(cè)試包括：

●軟件有效性測(cè)試——運(yùn)用黑盒測(cè)試方法，驗(yàn)證軟件是否滿足需求規(guī)格說明書列出的需求。

●軟件配置復(fù)審——保證軟件配置的所有成分都齊全，質(zhì)量符合要求，文檔與程序一致，具有完成軟件維護(hù)所必須的細(xì)節(jié)，并且已經(jīng)編排好分類的目錄。、●α和β測(cè)試

●驗(yàn)收測(cè)試。

白盒測(cè)試：按照程序內(nèi)部邏輯測(cè)試程序。檢查程序中的每條通路是否都能按照預(yù)定要求正常工作。這種測(cè)試完全了解程序的結(jié)構(gòu)和處理過程。因此，白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。黑盒測(cè)試主要是為了發(fā)現(xiàn)一下幾類錯(cuò)誤： ●是否有不正確或遺漏了的功能；

●界面錯(cuò)誤：輸入能否正確地接受？能否輸出正確的結(jié)果？ ●是否有數(shù)據(jù)結(jié)構(gòu)或外部信息（如數(shù)據(jù)文件）訪問錯(cuò)誤； ●性能上是否能夠滿足要求； ●是否有初始化或終止性錯(cuò)誤。

軟件工程的主要目的就是要提高軟件的可維護(hù)性，減少軟件維護(hù)所需要的工作量,降低軟件系統(tǒng)的總成本。

軟件維護(hù)——軟件投入運(yùn)行后，解決發(fā)生的各種故障，增強(qiáng)其功能，使之適應(yīng)新的環(huán)境的活動(dòng)。

1、改正性維護(hù)

2、適應(yīng)性維護(hù)

3、完善性維護(hù)

4、預(yù)防性維護(hù)

維護(hù)工作量： M=p+k*exp(c-d)

P:生產(chǎn)性工作量：分析、評(píng)價(jià)、設(shè)計(jì)、修改和編碼。K:經(jīng)驗(yàn)系數(shù)

C:程序復(fù)雜性系數(shù)：文檔少都會(huì)引起復(fù)雜程度增加。D:維護(hù)人員對(duì)軟件的熟悉程度

維護(hù)過程

? 維護(hù)組織

? 維護(hù)報(bào)告

? 維護(hù)的事件流

? 保存維護(hù)記錄

? 評(píng)價(jià)維護(hù)活動(dòng)

為了確定軟件維護(hù)的有效程度，確定軟件產(chǎn)品的質(zhì)量，同時(shí)確定維護(hù)活動(dòng)的開銷，詳細(xì)記錄維護(hù)中進(jìn)行的工作及工作量。主要內(nèi)容包括（18項(xiàng)）

? 程序標(biāo)識(shí) ? 源程序語句數(shù)

? 機(jī)器指令條數(shù) ? 使用的程序設(shè)計(jì)語言 ? 程序安裝的日期

? 安裝以來運(yùn)行的次數(shù) ? 安裝以來的失效次數(shù) ? 程序變動(dòng)的層次和標(biāo)識(shí) ? 每個(gè)改動(dòng)耗費(fèi)的人時(shí)數(shù) ? 程序改動(dòng)的日期 ? 程序變動(dòng)增加的源語句數(shù) ? 維護(hù)人員名字

? 程序變動(dòng)而刪除的源語句數(shù) ? 維護(hù)要求表的標(biāo)識(shí)

軟件配置管理（SCM）

? 維護(hù)類型 ? 維護(hù)開始時(shí)間和完成時(shí)間 ? 累計(jì)用于維護(hù)的人時(shí)數(shù)

? 與完成的維護(hù)相聯(lián)系的純效益

軟件維護(hù)和軟件配置管理之間的區(qū)別是：維護(hù)是一組軟件工程活動(dòng)，它們發(fā)生于軟件已交付用戶并已投入運(yùn)行之后；軟件配置管理是一組跟蹤和控制活動(dòng)，它們開始于軟件開發(fā)項(xiàng)目開始之時(shí)，結(jié)束于軟件被淘汰之時(shí)。

軟件配置管理的主要目標(biāo)是使變更更容易地被適應(yīng)，并減少當(dāng)變化必須發(fā)生時(shí)所需花費(fèi)的工作量。

對(duì)維護(hù)活動(dòng)進(jìn)行度量。內(nèi)容包括：

（1）每次程序運(yùn)行平均失效次數(shù)（2）用于每一類維護(hù)活動(dòng)的總?cè)藭r(shí)數(shù)

（3）平均每個(gè)程序、每種語言、每種維護(hù)類型所作的程序變動(dòng)次數(shù)（4）維護(hù)過程中增加或刪除一個(gè)源語句平均花費(fèi)的人時(shí)數(shù)。（5）維護(hù)每種語言花費(fèi)的人時(shí)數(shù)（6）一張維護(hù)要求表的平均周轉(zhuǎn)時(shí)間（7）不同維護(hù)類型所占的百分比

第四篇：軟件工程重點(diǎn)整理

可以把軟件開發(fā)的本質(zhì)概括為：不同抽象層術(shù)語之間，以及不同抽象層處理邏輯之間的映射 需求分析產(chǎn)生的正式文檔是需求規(guī)約

在結(jié)構(gòu)化分析方法中，表示“數(shù)據(jù)的靜態(tài)結(jié)構(gòu)”的術(shù)語是數(shù)據(jù)存儲(chǔ)

對(duì)模塊的寬度影響最大的因素是模塊的扇出 下列術(shù)語，可用于抽象客觀世界中事物的是類

大學(xué)由若干專業(yè)系構(gòu)成，則大學(xué)與專業(yè)的關(guān)系是組合

下列軟件測(cè)試技術(shù)中，依據(jù)程序邏輯結(jié)構(gòu)的是白盒測(cè)試技術(shù) 單元測(cè)試期間，通?？紤]模塊的重要的執(zhí)行路徑

軟件基本過程指那些與軟件生產(chǎn)直接相關(guān)的活動(dòng)集，可分為供應(yīng)過程、開發(fā)過程、運(yùn)行過程、維護(hù)過程和獲取過程

在常見的軟件開發(fā)模型中，適用于項(xiàng)目的開發(fā)風(fēng)險(xiǎn)很大或客戶不能確定系統(tǒng)需求的模型是螺旋模型

CMMI 能力等級(jí)中的 3 級(jí)是已定義級(jí)

軟件生產(chǎn)率、軟件質(zhì)量滿足不了社會(huì)發(fā)展的需求，并成為其發(fā)展的制約因素，這一現(xiàn)象被稱為軟件危機(jī)

對(duì)于單一的一個(gè)需求，必須具有的基本性質(zhì)：必要的、無歧義的、可測(cè)試的、可跟蹤的以及可測(cè)量的。

需求規(guī)約的基本性質(zhì)包括重要性和穩(wěn)定性程度、可修改的、完整的和一致的

在結(jié)構(gòu)化分析方法中，可采用結(jié)構(gòu)化自然語言、判定表和判定樹描述加工

用于定義數(shù)據(jù)流圖包含的所有數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)，直到給出構(gòu)成以上數(shù)據(jù)的各數(shù)據(jù)項(xiàng)的基本數(shù)據(jù)類型的工具是數(shù)據(jù)字典

在 UML 中，用于描述關(guān)聯(lián)的一定“內(nèi)涵”的術(shù)語是關(guān)聯(lián)名 RUP 利用 UML 提供的術(shù)語和工具定義了需求獲取層、系統(tǒng)分析層、設(shè)計(jì)層和實(shí)現(xiàn)層，并給出了實(shí)現(xiàn)各層模型之間映射的基本活動(dòng)以及相關(guān)的指導(dǎo)

軟件測(cè)試是一個(gè)有程序的過程，包括測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行以及測(cè)試結(jié)果比較等

由于軟件錯(cuò)誤的復(fù)雜性，在軟件工程測(cè)試中，應(yīng)綜合運(yùn)用測(cè)試技

術(shù)，并且應(yīng)實(shí)施合理的測(cè)試序列：

單元測(cè)試、集成測(cè)試、有效性測(cè)試和系統(tǒng)測(cè)試

《IS0/IEC 軟件生存周期過程 12207—1995》標(biāo)準(zhǔn)按過程主體把軟件生存周期過程分為基本過程、支持過程和組織過程 針對(duì)開發(fā)的 CMMI 是一個(gè)有關(guān)產(chǎn)品和服務(wù)的過程改善的成熟度模型，集成了 3 個(gè)源模型：軟件 CMM、系統(tǒng)工程 CMM和產(chǎn)品集成開發(fā) CMM

CMMI 中，遵循一個(gè)過程可達(dá)到的預(yù)期結(jié)果的程度是指過程能力

CMMI 模型基于過程途徑思想，通過過程把軟件質(zhì)量的 3 個(gè)支撐點(diǎn)：受訓(xùn)的人員、規(guī)程和方法、工具和設(shè)備進(jìn)行集成，以開發(fā)所期望的系統(tǒng)/產(chǎn)品

請(qǐng)簡(jiǎn)述計(jì)算機(jī)軟件的概念以及提出軟件工程概念的目的

（1）計(jì)算機(jī)軟件一般是指計(jì)算機(jī)系統(tǒng)中的程序及其文檔（2）其中，程序是計(jì)算機(jī)任務(wù)的處理對(duì)象和處理規(guī)則的描述（3）文檔是為了理解程序所需的闡述性資料（4）軟件工程概念的提出，其目的是倡導(dǎo)以工程的原理、原則和方法進(jìn)行軟件開發(fā)，以解決出現(xiàn)的軟件危機(jī)。

請(qǐng)簡(jiǎn)述初始發(fā)現(xiàn)需求的常用技術(shù)（1）自悟（2）交談（3）觀察（4）小組會(huì)（5）提煉

請(qǐng)敘述信息隱藏的概念及其意義

（1）信息隱藏是指在每個(gè)模塊中所包含的信息不允許其他不需要這些信息的模塊訪問（2）它是實(shí)現(xiàn)模塊低耦合的一種有效途徑（3）但是，如果一個(gè)模塊是“絕對(duì)”信息隱藏的，那么這種模塊對(duì)系統(tǒng)而言是毫無意義的

什么是驗(yàn)證和確認(rèn)？請(qǐng)敘述它們的區(qū)別

（1）驗(yàn)證就是證實(shí)一個(gè)過程或項(xiàng)目的每一軟件工作產(chǎn)品/服務(wù)是否正確地反映了所規(guī)約的需求（2）確認(rèn)就是證實(shí)所期望使用的軟件工作產(chǎn)品是否滿足其需求（3）區(qū)別：驗(yàn)證是通過提供的客觀證據(jù)，證實(shí)規(guī)約的需求是否得以滿足；確認(rèn)是通過提供的客觀證據(jù)，證實(shí)有關(guān)特定期望的使用或應(yīng)用的需求是否得以滿足

第五篇：軟件工程重點(diǎn)總結(jié)

軟件工程復(fù)習(xí)重點(diǎn)總結(jié)

1.(P-2)

Analysis:

decompose a large problem into smaller, understandable pieces，(一個(gè)大問題分解成更小的、可以理解部分)abstraction is the key Synthesis:

build(compose)software from smaller building blocks,(生成撰寫軟件從較小的構(gòu)造塊)composition is challenging 2Software Engineering Solving Problems(continued)：(P-4)

method： refers to a formal procedure（指的是一個(gè)正式的程序）

tool：an instrument or automated system for accomplishing something in a better way procedure（過程）：a combination of tools and techniques to produce a product（工具和技術(shù)來生產(chǎn)一種產(chǎn)品的組合）

paradigm（范例）：philosophy or approach for building a product 3.(P-6)

A fault: occurs when a human makes a mistake, called an error, in performing some software activities（在執(zhí)行某些軟件活動(dòng)）;

A failure: is a departure（偏差）from the system’s required behaviour;

Error can lead to fault；fault can lead to failure。4.participates in a project：(P-15)

Customer:

the company, organization, or person who pays for the software system Developer:

the company, organization, or person who is building the software system User: the person or people who will actually use the system

5.Activities and objects(P-16)– An activity is an event initiated by a trigger（活動(dòng)是由一個(gè)觸發(fā)器的事件）– Objects or entities are the elements involved in the activities（Objects 或?qū)嶓w是要素參與活動(dòng)的）

6.Relationships and the system boundaries(P-17)– A relationship defines the interaction among entities and activities（A 關(guān)系定義實(shí)體和活動(dòng)的相互作用）

– System boundaries determine the origin of input and destinations of the output（邊界確定輸入的來源與目的地的輸出）

7.a system as a collection of things :(P-17)a set of entities(一組實(shí)體), a set of activities , a description of the relationships among entities and activities and a definition of the system.8.The development of software includes the following activities(P-24)? ? ? ? Requirements analysis and definition System design Program design Writing the programs ? Unit testing ? Integration testing ? System testing ? System delivery ? Maintenance 9.developer roles(P-26)Analyst

Designer

Programmer

Tester

Trainer 10.(P-45)A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind（一系列步驟涉及活動(dòng)，受到了限制，及資源，產(chǎn)生一預(yù)期的輸出）

A process involves a set of tools and techniques 11.(P-46)

Software life cycle:

Implementation ,delivery ,use, and maintenance（實(shí)施、發(fā)布、使用及維修）

When a process involves building a software, the process may be referred to as software life cycle – – – – – – – Requirements analysis and definition System(architecture)design Program(detailed/procedural)design Writing programs(coding/implementation)Testing: unit, integration, system System delivery(deployment)Maintenance

12．software process models：（P-48）

Waterfall model

V model Prototyping model(原型化)Operational specification model Transformational model（轉(zhuǎn)化）

Phased development（階段化開發(fā)）: increments and iterations（反復(fù)遞增）Spiral model（螺旋模型）Agile methods（敏捷方法）

13.Prototyping is useful for verification(確認(rèn))and validation（驗(yàn)證）（P-51）14.Elements of a process are viewed in terms of seven types（P-64）

Activity – Sequence – Process model 過程模型 – – – – Resource Control Policy Organization

15.Project schedule(P-83)Describes the software-development cycle for a particular project by

enumerating the phases or stages of the project(枚舉階段或項(xiàng)目的階段)

breaking each phase into discrete tasks or activities to be completed(每個(gè)階段分成離散任務(wù)或活動(dòng)，以完成)

Portrays(描繪)the interactions(相互影響)among the activities and estimates(估算)the times that each task or activity will take

16.Activity and milestone(P-83)Activity: takes place over a period of time

Milestone: completion of an activity--a particular point in time

17.Critical Path Method(CPM)(P--87)

見作業(yè)

18.Key activities requiring personnel（P-95）

requirements analysis system design program design program implementation（實(shí)現(xiàn)，執(zhí)行）testing training maintenance

quality assurance（保證）

19.risk（P—119）

is an unwanted event that has negative consequences(消極結(jié)果)

20.Risk impact(影響):（P--120）

the loss associated with the event與該事件關(guān)聯(lián)的損失

Risk probability(概率):

the likelihood that the event will occur事件發(fā)生的可能性

Risk control(控制):

the degree to which we can change the outcome我們可以更改結(jié)果的程度

Quantify(量化)the effect of risks：

Risk exposure =(risk probability)x(risk impact)

21.Risk management：（P--121）

risk assessment（評(píng)估）

risk control

22.（P--143）

A requirement：

is an expression of desired behaviour是所需行為的表達(dá)式 A requirement deals with ：

objects or entities，the states they can be in，and the functions that are performed to change states or object characteristics

23.Process for Capturing Requirements（P--144）

Elicitation（引入）

Analysis

Specification Validation（驗(yàn)證）

////構(gòu)成了software requirements specification(說明書)

24.functional requirement（P---148）

describes required behavior in terms of required activitie描述所需的活動(dòng)所需的行為s Quality requirement or nonfunctional requirement describes some quality characteristic that the software must possess(擁有)

Design constraint(約束):

a design decision such as choice of platform or interface components設(shè)計(jì)的平臺(tái)或界面組件如選擇決策 Process constraint: a restriction on the techniques or resources that can be used to build the system 對(duì)技術(shù)或可用于構(gòu)建系統(tǒng)的資源限制

25.Prioritization might separate requirements into three categories（P--152）

Essential(基本): absolutely must be met絕對(duì)需要滿足的需求

Desirable(合意): highly desirable but not necessary非常理想，但不必須的 Optional(可選): possible but could be eliminated但可能被淘汰

26.Requirements definition:（P--154）

a complete listing of everything the customer wants to achieve完整列表的客戶希望實(shí)現(xiàn)的一切

Describing the entities in the environment where the system will be installed

描述在將安裝在系統(tǒng)環(huán)境中的實(shí)體 Requirements specification:

restates（重申）the requirements as a specification of how the proposed（提出）system shall behave

27.ER diagram have three core constructs（P--158）ER 圖表有三個(gè)核心構(gòu)造

An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述為一個(gè)的矩形表示一個(gè)實(shí)際

的對(duì)象的集合 具有公共屬性和行為

A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定）the type of relationship描述為一個(gè)兩個(gè)實(shí)體之間的邊緣

An attribute: an annotation(注解)on an entity that describes data or properties associated with the entity描述數(shù)據(jù)或與該實(shí)體相關(guān)聯(lián)的屬性的實(shí)體上的注釋

28.（P--172）

A data-flow diagram(DFD)models functionality and the flow of data from one function to another數(shù)據(jù)流關(guān)系圖 DFD 模型的功能和數(shù)據(jù)到另一個(gè)函數(shù)的流

– A buble represents a process一個(gè) buble 表示一個(gè)流程 – An arrow represents data flow一個(gè)箭頭表示數(shù)據(jù)流量

– A data store: a formal repository(倉庫)or database of information –

Rectangles represent actors: entities that provide input data or receive the output result矩形表示參與者： 實(shí)體提供輸入的數(shù)據(jù)或接收輸出結(jié)果

–

29.(P--223)Design: is the creative process of transforming the problem into a solution The description of a solution is also known as design 是創(chuàng)造過程的問題轉(zhuǎn)化為解決方案的描述稱為設(shè)計(jì)

30.Design is a two-part interactive process(P—224)– Conceptual design(system design)(概念性設(shè)計(jì))– Technical design(技術(shù)性設(shè)計(jì))

–

31.(P—228)Modules or components: 組件

composite parts of design A system is modular when

– each activity of the system is performed by exactly one component活動(dòng)的系統(tǒng)由一個(gè)組件執(zhí)行

– inputs and outputs of each component are well-defined

? all inputs to it are essential to its function輸入其功能至關(guān)重要

? all outputs are produced by one of its actions輸出由其動(dòng)作之一制作

32.Architectural Styles and Strategies Three Design Levels:(P—229)

Architecture（系統(tǒng)結(jié)構(gòu)）

Code design

Executable design（執(zhí)行設(shè)計(jì)）

33.Architectural Styles and Strategies Design Styles（P—230）

Pipes and filters(管道/過濾器)Object-oriented design Implicit invocation(隱式調(diào)用)Layering（分層設(shè)計(jì)）Repositories(數(shù)據(jù)倉庫)Interpreters(解釋器)Process control(過程控制)Client-server(客戶/服務(wù)器)

34.Component independence（P--248）

Coupling(耦合度)Cohesion(內(nèi)聚度)Highly coupled when there is a great deal of dependencies Loosely coupled components have some dependency, but the interconnections among components are weak（大多數(shù)采用松散）

Uncoupled components have no interconnections at all

35.We can measure coupling along a range of dependence（P--249）

Characteristics of Good Design Coupling: Types of Coupling

Content(內(nèi)容)coupling

Common(公共)coupling Control(控制)coupling Stamp(標(biāo)記)coupling Data(數(shù)據(jù))coupling 36.Exceptions can be handled in one of three ways：（P—255）異常處理

– Retry(重試)– Correct(更正)– Report(報(bào)告)

37.program component involves at least three major aspect:(P---340)

Control structures ,algorithms,and data structure 38.making the codeefficiency(效率)may have hidden costs(代價(jià))(P--342)– cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code

39.Software Faults and Failures types of Faults(P--367)軟件故障及故障的類型的故障

Algorithmic fault算法

Computation and precision fault 計(jì)算和精度 Documentation fault Stress or overload faults Capacity or boundary faults 容量邊界 Timing or coordination faults(協(xié)調(diào))Throughput(吞吐量)or Performance faults Recovery fault 恢復(fù)故障

Hardware and system software fault Standards and procedures fault

40.Testing Organization（P—371.）

Module testing, component testing, or unit testing(單元測(cè)試)Integration testing(集成測(cè)試)The next step is ensuring that the interfaces among the components are defined and handled properly.Performance testing(性能測(cè)試)Compares the system with the remainder of these software an hardware requirements.41.Testing steps（P--372）

42.Integration Testing集成測(cè)試（P--390）具體實(shí)例見作業(yè)

Bottom-up(自底向上)

Merging components to test the larger system

Top-down(自頂向下)

Big-bang(大棒)

Sandwich testing(多層結(jié)構(gòu)測(cè)試)

Modified top-down(改性自上而下)

Modified sandwich(改性多層結(jié)構(gòu)測(cè)試)

43.Principles of System Testing Regression Testing Steps（P—425）系統(tǒng)測(cè)試回歸測(cè)試步驟的原則

? Inserting the new code ? Testing functions known to be affected by the new code ? Testing essential function of m to verify that they still work properly整體 ? Continuing function testing m + 1

44.Types of Performance Tests（P--436）性能測(cè)試

Stress tests(壓力)Volume tests(容量)Configuration tests(配置)Compatibility tests(兼容)

Regression tests(回歸)Security tests(安全)Timing tests(響應(yīng)時(shí)間)Environmental tests(環(huán)境)Quality tests(質(zhì)量)Recovery tests(恢復(fù))Maintenance tests(可維護(hù)性)Documentation tests(文檔)Human factors(usability)tests(使用)

45.Software reliability:

operating without failure under given condition for a given time interval 無故障下經(jīng)營給予指定的時(shí)間間隔內(nèi)的條件 Software availability:

operating successfully according to specification at a given point in time 成功經(jīng)營，依法規(guī)范在指定點(diǎn)的時(shí)間 Software maintainability:

for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources 為給定的使用條件，維護(hù)活動(dòng)可以內(nèi)進(jìn)行既定的時(shí)差 過程資源

注意：作業(yè)是重點(diǎn)，必考！這個(gè)翻譯（長字段的）僅供參考，要結(jié)合軟件工程的角度加以分析理解！