軟件工程復習提綱

第1章軟件工程簡介..........................................................3

軟件是什么...............................................................3

第2章過程綜述..........................................................4

軟件工程定義.............................................................4

層次化...................................................................4

通用過程框架.............................................................4

第3章過程模型..............................................................6

多種過程模型.............................................................6

第4章敏捷視角下的過程......................................................8

敏捷宣言.................................................................8

第5章系統工程.............................................................10

第6章需求工程.............................................................11

質量功能布署(QFD)........................................................11

分析模型的元素..........................................................14

第7章構建分析模型.........................................................14

第8章設計工程.............................................................15

第9章進行體系構造設計.....................................................16

體系構造風格的分類......................................................16

第1()章構件級設計建模......................................................17

第11章完畢顧客界面設計....................................................17

黃金規則.................................................................17

第12章軟件測試方略........................................................18

軟件測試需要計劃和執行一系列日勺測試環節.................................18

第13章測試技術............................................................19

兩個不同樣日勺測試用例設計技術............................................19

第14章產品度量............................................................20

第1章軟件工程筒介

軟件是什么

軟件是形成配置的一組術語或對象，包括：

程序(計算機程序)：指令的集合,通過執行這些指令可以滿足預期的特性、功能和性能需求

數據構造:它使得程序可以充足運用信息

文檔:描述程序操作和使用的文檔(圖文資料)

1.舉例闡明“意外效應法則”(lawofunintendedconsequences)在計算機軟件方面的I

應用。

某些新科技的發明發明會給其他某些看似無關的技術領域、商業企業、公眾甚至整個

社會文化帶來深遠而出人意料的影響和作用。

如：

2.用自己的語言描述保證通曉規律(TheLawofConservationofFamiliarity)、質量衰

減規律(TheLawofDecliningQuality)以及組織穩定性守恒規律(TheLawof

ConservationofOrganizationalStability)。

保證通曉性規律(1980):伴隨E類型系統的演化，所有有關人員(如開發人員、銷售

人員和顧客)都必須清晰地理解演化的內容和過程，以便抵達滿意的演化效果。

質量衰減規律(1996):假如沒有嚴格的維護和適應性調整使之適應運行環境的變化，

E類型系統口勺質量有衰減的趨勢。

組織穩定性守恒規律(1980):一種不停演化的E類型系統，其組織在全球范圍內的

平均有效活動率在產品的生命周期中是保持不變的。

3.在交付最終顧客之前，或者第1個版本投入使用之后，許多應用程序都會有頻繁的

變更。為防止變更引起軟件失效，請提出某些有效的處理措施。

首先從心態上承認變化是必然的，我們可以通過在軟件公布之前進行alpha,beta測

試，運用迭代模式，在吸取測試過程中的經驗之后，立即改善軟件。

同步保持和顧客日勺良好溝通，在提交顧客時進行合適培訓，讓顧客按照開發思緒進行

試用，可以見減少因使用措施不妥引起的變化。

第2章過程綜述

軟件工程定義

軟件工程是：

（1）將系統化、規范日勺、可量化的措施應用于軟件日勺開發、運行和維護，即將工程化措施應

用于軟件。

（2）在（1）中所述日勺措施的研究。

層次化

工具

方法

過程模型

質玨關注點

軟件工程層次圖

通用過程框架

1.溝通(Communication)

2.籌劃(Planning)

3.建模(Modeling)

a)需求分析(Analysisoflequirements)

h)設計(Design)

4.構建(Construction)

a)代碼生成(Codegeneration)

b)測試(Testing)

5.布署(Deployment)

重點：

1.Baetjer說過“軟件過程為顧客和設計者之間、顧客和開發工具之間以及設計者和開

發工具之間提供交互的途徑［技術］。”設計下面問題“⑴設計者應當問顧客歐I;⑵

顧客應當問設計者日勺；⑶顧客對將要構建的軟件日勺自問；⑷設計者對于軟件產

品和建造該產品采用的軟件過程時自問。(怎樣獲取需求)

2.為溝通活動設計一種任務集

1.識別重要客戶和其他共利益者

2.與客戶會談環境無關的話題

3.寫一頁項目范圍

4.評審范圍闡明

5.討論項目大體的階段

6.約定各個部門的代表，并使他們互相認識

7.為計劃活動做準備

3.用自己H勺話描述過程框架。當我們談到框架活動合用于所有日勺項目時，與否意味著

對于不同樣規模和復雜度的I項目，可應用相似的工作任務？請解釋。

過程框架定義了若干小時框架活動，為完整日勺軟件開發過程建立的基礎，這些框架活

動可以廣泛用于所有的軟件開發項目，無論這些項目日勺復雜性和規模怎樣，此外，還包括

某些合用于各個軟件過程的普適性活動。

雖然過程框架是普適性的，不過對于不同樣規模和復雜度日勺項目不能應用相似日勺工作

任務。

首先在軟件開發日勺不同樣階段，工作任務不同樣。另首先不同樣的軟件項目有不同樣

日勺需求，有特殊日勺背景，找不到一種通用的工作任務。

4.圖2-1中，基于“質量關注點”指明了軟件工程三個層次。這意味著在整個開發組織

內采用質量管理活動，如“全面質量管理”。仔細研究，并列出全面質量管理活動

中關鍵原則的大綱。

第3章過程模型

多種過程模型

通例軟件過程模型

力圖給軟件開發帶來秩序和構造。盡管每一老式過程模型都提議了一種不同樣口勺過程流，但

均實現了同樣的一組通用框架活動：溝通、計劃、建模、構建利布署。

瀑布模型

提議線性流程的框架活動，與軟件世界里現代軟件開發實際（持續的變更、演化的系統、緊

迫的開發時間）不符；但瀑布模型確實合用于需求定義清晰且穩定的軟件開發；

增量軟件過程模型

通過一系列的增量公布產生軟件。

RAD模型

迅速應用程序開發，是為大型且必須在嚴格的時間內提交口勺項目而設計的；

演化過程模型

認識到大多數軟件工程項目的送代特性，其設計的目日勺是為了適應變更演化模型（如原型模

型、螺旋模型），其迅速產生增量的工作產品（或是軟件日勺工作版本），這些模型可以應用

于所有的軟件工程活動一一從概念開發到長期日勺軟件維護。

基于構建的模型

強調構件復用及組裝。

形式化措施模型

倡導采用數學日勺措施進行軟件開發和驗證。

面向方面的模型

目的I是處理跨整個軟件體系構造的橫切關注點；

統一過程模型

是一種“用例驅動、以體系構造為關鍵、迭代及增量”的軟件過程框架，由UML措施和工

具支持。統一過程是一種增量模型，定義了五個階段：

起始階段：包括顧客溝通和計劃活動兩個方面，強調定義和細化用例，并將其作為重要模型;

細化階段：包括顧客溝通和建模活動，重點是創立分析和設計模型，強調類的定義和體系構

造的體現；

構建階段：細化設計模型，并將設計模型轉化為軟件構建實現；

轉化階段：將軟件從開發人員傳遞給最終顧客，并由顧客完畢Beta測試和驗收測試；

生產階段：持續地監捽軟件叼運行,并提供技術支持.

重點：

1.開發質量“足夠好”的軟件，其長處和缺陷是什么？當我們追求開發速度勝過產品

質量的時候，會產生什么后果？

我們總在質量和開發速度之間做取舍，開發質量“足夠好”的軟件，明顯弼調質量，

長處是使軟件符合或超過客戶的預期，在性能上，交互上力圖做到盡善盡美。缺陷是忽視

了開發成本，很輕易導致開發時間延期，影響軟件工程后幾種階段日勺工作，對全局導致不

利影響。

2.當沿著螺旋過程流發展日勺時候，你對正在開發或者維護日勺軟件的見解是什么？

在螺旋模式下，開發過程是迭代式日勺，采用循環的方式逐漸加深系統定義和實現的深

度，同步減少風險。

當軟件交付使用后，螺旋模式沒有停止，它將永遠保持可操作性，每一圈完畢后都會

計算成本，可以更好日勺維護軟件。

3.可以合用幾種過程模型嗎？假如可以，舉例闡明。

可以。

幾種過程模型，都是互相兼容可以互相擴展日勺，如螺旋模型結合了原型H勺迭代性質和

瀑模型日勺系統性和可控性的特點。

在詳細項目實行中，對于某一部分用以合用幾科過程模型，例如形式語言與自動機演

示軟件在算法開發過程，就需要使用形式化措施模型，用嚴格歐I數學符號定義形式語言和

自動機。

尚有某些桌面應用程序日勺前臺UI部分，可以單獨使用RAD模型，例如用delphi語言

開發桌面窗體就是一種RAD實現.而其他部分可以使用其他如瀑布式模型等措施.

第4章敏捷視角下的過程

敏捷宣言

?個體和交互勝過過程和工具(Individualsandinteractionsoverprocessesandtools)

?可工作軟件勝過寬泛『、J文檔(Workingsoftwareovercomprehensivedocumentation)

?客戶合作勝過協議談判(Customercollaborationovercontractnegotiation)

?響應變化勝過遵照計劃(Respondingtochangeoverfollowingaplan)

重點：

1.與否每一種敏捷過程都可以用第2章所提及日勺通用框架性活動來描述？建一張表，

將通用活動和每個敏捷過程所定義日勺活動對應起來。

2.用自己日勺語言描述(用于軟件項目日勺)敏捷性？

普遍存在的變化是敏捷的基本動力，敏捷需要有效的響應變化，它鼓勵在共利益者之

間進行更便利的溝通和協作，強調可運行軟件時迅速交付。

敏捷容許項目團體調整并合理安排任務，理解易變性并制定計劃。精簡并維持最基本

日勺工作產品，強調增量交付，迅速提供可運行軟件。

3.許多敏捷過程模型推薦面對面交流，實際上，目前軟件開發團體組員及其客戶在地

理上是分散的。你與否認為這意味著這種地理上的分散應當防止？能否想出一種措

施克服這個問題。

我認為這種地理上的分散是現實，是無法防止的。我認為可以分為客戶和開發人員日勺

分散，開發人員內部分散兩種狀況。

對于第一種：產品經理需要同客戶建立一條良好日勺通信信道，如通過email,即時聊天

工具進行定期溝通。

對于第二種：開發人員需定期組織交流，通過webgroup消除地理上的分散。

4.為何需求變化這樣大，人們究竟無法確定他們想要什么嗎？

我認為是這樣的。

其實需求是客戶對他們心目中軟件的一種描述，由于軟件還沒有實現，這種描述便是

不確定日勺，模糊日勺。同步當今世界處在高速變化之中，人們H勺需求會伴隨環境的變化而變

化。

因此敏捷開發承認變化，認為普遍存在的變化是敏捷日勺基本動力。

第5章系統工程

在寫下每行代碼之前

?理解所要處理的問題（詳見溝通與建模）

?理解基本的設計原則和概念

?選擇一種可以滿足軟件構建以及運行環境規定的編程語言

?選擇一種能提供工具以簡化工作日勺編程環境

?構件級編碼完畢后進行單元測試

系統工程層次圖

重點：

1.對你熟悉的系統、產品或服務，建立它們的層次系統。層次應當向下擴展到簡樸系

統要素（硬件、軟件等），至少得到層次樹H勺一種分支。

即時聊天系統

2.系統工程師由3種來源：系統開發人員、顧客或某些外部組織。討論一下每種來源

的利與弊。描述一種理想的系統工程師。

3.研究文獻并寫出一篇簡短文章描述建模和模擬工具是怎樣工作的I。或者是搜集兩個

或更多日勺商用建模或模擬工具的文獻，并且比較它們的相似處與不同樣處。

第6章需求工程

質量功能布署（QFD）

是一種將客戶規定轉化成軟件技術需求的技術。QFD“目日勺是最大程度地讓客戶從軟件工程

過程中感到滿意"，并強調"什么是對客戶有價值日勺”。確認三類需求：

?正常需求：反應了在和客戶開會時確定歐I針對某產品或系統的目日勺。假如實現了這些需

求，將滿足客戶（例如：所規定日勺圖形顯示類型、特定的I系統功能以及己定義的性能級

別）。

?期望需求：隱含在產品或系統中，并且也許是非常基礎的以至于客戶沒有顯式地闡明，

但缺乏這些將導致客戶明顯不滿（例如：易交互性、可操作性、可靠性、易安裝等）。

?令人興奮的需求：反應了客戶期望之外的特點，但假如實現了這些特點，將會使客戶非

常滿意。

重點：

1.為如下活動之一開發一種完整的用例：

＞在ATM提款；

＞在餐廳使用信用卡付費;

＞使用一種在線經紀人賬戶購置股票:

＞使用在線書店搜索書（某個指定主題）；

ATM用例圖

“ATM取款”用例規約

用例名稱：ATM取款

簡述：客戶持銀行卡（本行或其他行）從ATM提取現金

actors:客戶和銀行主機

基本流：1.客戶插入銀行卡。

2.ATM從銀行卡讀入卡號（含銀行標識和賬號），驗證卡

的有效性。

3.客戶輸入密碼。

4.ATM驗證帳號和密碼。

5.ATM顯示包括取款在內的服務功能，客戶選擇“取款”。

6.輸入取款額：客戶輸入數量為50元的倍數的取款額。

7.ATM向銀行主機告知卡號、密碼、賬號和取款額，獲得

具有最新余額的取款成功確認信息。

8.ATM打印并吐出憑條。

9.ATM清點并吐出現金，記錄取款成功。

10.ATM問詢客戶與否繼續服務。

11.客戶選擇否，ATM吐出銀行卡，結束用例，否則回到環

節5。

［用例結束］

備選流：3-7,10a.客戶取消服務:

ATM記錄服務取消，打印憑條，吐出憑條和銀行卡，［用

例失敗］

3,6,11a.客戶未及時輸入超過30秒：

ATM吞卡，［用例失敗］

2a.K無效：

ATM吞卡，［用例失敗］

2b.讀卡器或卡被損壞：

ATM吞卡，［用例失敗］

4a.密碼錯:

4al.客戶重新輸入密碼

a.合計3次密碼錯誤：

ATM吞卡，［用例失敗］

4b.無此帳號：

ATM吞卡，［用例失敗1

5a.ATM無現金：

ATM不顯示“取款”功能，客戶可選擇其他服務，［用

例失敗1

6a.取款額超過ATM現金余額；

ATM規定客戶重新輸入取款額。

7a.帳戶余額局限性：

ATM規定客戶重新輸入取款額。

7b.取款額超過當日最高限額：

ATM規定客戶重新輸入取款額。

7c.網絡或銀行主機失效、通訊超時：

ATM記錄服務取消，打印憑條，吐出憑條和銀行卡，［用

例失敗］

8a.憑條打印失敗，紙用完或卡紙：

8al.ATM告知銀行主機取消取款

8a2.ATM記錄服務取消，吐出銀行卡，［用例失敗］

9a.吐現金失敗：

9al.ATM告知銀行主機取消取款

9a2.ATM記錄服務取消，吐出銀行卡，［用例失敗］

11a.客戶未及時取走卡：

ATM吞卡，［用例失敗］

業務規則：7b單日取款不得超過5000元

6c每次取款不得超過2023元

2.為何大量的軟件開發人員沒有足夠重視需求工程？此前有無什么狀況讓你可以跳過

需求工程？

首先軟件開發人員認為客戶已經把需求說清晰了，不過大多數狀況初步H勺需求都是模

糊跖

另首先工程日勺進度規定很緊迫，軟件開發人員迫切但愿投入到代碼編寫階段。

最終和客戶溝通比較困難，使得大多數軟件開發人員不重視需求工程。

又一次，項目時間很短，規定一種月完畢，我們只是大體上對需求有一種認識，就跳

過需求工程開始動手編碼，成果當然失敗了。

3.簡短地討論一種分析模型的每個元素，指出每個元素對模型日勺奉獻，每個元素為何

是唯一日勺以及每個元素所示日勺概要信息。

分析模型的元素

基于場景的元素（用例圖）：使用基丁場景日勺措施可以從顧客的視角描述系統。例如基本日勺

用例和基于模板日勺用例。一般的分析模型的第一步，作為創立其他模型歐I輸入。

基于類的元素（類圖）：每個使用場景都暗示著當一種參與者與系統交互時所操做的I一組

對象，這些對象被提成類一一具有相似屬性和共同行為的I事務集合。

行為元素（狀態圖）：狀態指明了在某個特殊事件后采用什么動作。

面向信息流的模式：描述信息的轉換。

第7章構建分析模型

重點:

1.簡樸用幾句話嘗試闡明構造化分析和面向對象分析的重要差異？

構造化分析考慮數據和處理，其中數據作為獨立的實體轉換，數據對象建模定義了對

象歐I屬性和關系，操作對象的處理建模應當表明數據對象在系統內流動時處理怎樣轉換數

據。

面向對象分析關注于定義類和影響客戶需求日勺類之間日勺協作方式。

2.有無也許在分析模型創立后立即開始編碼？解釋你日勺答案，然后說服反方。

第8章設計工程

從分析根空到設計鎮名的找化

重點:

1.假如軟件設計不是程序（它確定不是），那么它是什么？

是一套結實、合用和賞心悅目的模型或設計體現。它包括數據、類設計，體系構造設計、

接口設計、構件設計。

2.當你“編寫”程序時你設計軟件嗎？軟件設計和編碼有什么不同樣嗎？

設計。

軟件設計是逐漸細化一種可以工作的模型，而編碼是在牛成一種可執行的程序。軟件設計

重要關注與否實現了顧客需求，必須從實現的角度闡明數據域、功能域和行為域，是編碼

工作的指導。

3.用你自己的話闡明軟件體系構造。

系統構造是程序構件（模塊）日勺構造或組織，這些構件交互日勺形式以及這些構件因此數據

日勺構造。構件可以被推廣，用于代表重要的系統元素及其交互。

第9章進行體系構造設計

體系構造風格的分類

以數據為中心日勺體系構造

數據流體系構造：

當輸入數據通過一系列的計算和操作構件日勺變換形成輸出數據時，可以應用這種體系構

造。

信息流被描述為單個數據項，被稱為事務，他可以沿多條途徑中日勺一條觸發其他數據流。

調用和返回體系構造

面向對象體系構造

層次體系構造

重點：

1.使用數據流程圖和處理論述，描述一種具有明顯數據流特性和一種具有明顯事務流

特性的I計算機系統。

數據流特性：opengl管線

事務流特性：銀行轉賬

以房子或建筑H勺體系構造作比方，與軟件體系構造進行對比。老式H勺建筑體系構造學科和軟

件體系構造有何相似之處？有何不同樣之處？

第10章構件級設計建模

構件：系統中某一定型化日勺、可配置日勺和可替代的部件，該部件封裝并暴露了某些列接口。

內聚性：內聚性cohesion意味著構件或者類只封裝那些互有關聯親密，以及與構件或類自身

有親密關系的屬性和操作。

耦合性：類之間彼此聯絡程度日勺一種定性度量

第11章完畢顧客界面設計

黃金規則

置顧客于控制之下；

以不強迫顧客進入不必要的或不僅愿H勺動作H勺方式來定義交互模式。

提供靈活度的交互。

容許顧客交互被中斷和撤銷。

當技能級別增長時可以使交互流線化并容許定制交互。

使顧客與內部技術細節隔離開來。

設計容許顧客與出目前屏幕上日勺對象直接交互。

減少顧客的記憶承擔；

減少對短期記憶的規定。

建立故意義的缺省。

定義直觀日勺快捷方式。

界面日勺視覺布局應當基于真實世界的象征。

以不停進展的方式揭示信息。

保持界面一致性。

容許顧客將目前任務放入故意義日勺環境中。

在應用系統家族內保持一致性。

假如過去口勺交互模型已經建立起了顧客期望，除非有不得已的理由，否則不要變化它。

重點：

1.試給出兩個附加的“減少顧客記憶承擔”、“保持界面一致性”的設計原則。

2.假設你被邀請開發一種基于WEB的家庭銀行系統。請給出顧客模型、設計模型、心

理模型和實現模型。