軟件工程簡答題

1、1第一章軟件的定義軟件是： (1)指令的集合(計算機(jī)程序)，通過執(zhí)行這些指令來滿足預(yù)期的特征、功能和性能需求； (2)數(shù)據(jù)結(jié)構(gòu)，使得程序可以合理的利用信息； (3)文檔描述，用來描述程序操作和使用。2軟件的特性n軟件是設(shè)計開發(fā)的，而不是傳統(tǒng)意義上生產(chǎn)制造的。 -硬件可能會引入質(zhì)量問題，但軟件不會（或易于糾正） -人員和工作成果之間的對應(yīng)關(guān)系完全不同 -構(gòu)建方法不同，軟件產(chǎn)品成本主要在于開發(fā)設(shè)計軟件的特性(續(xù)1）n軟件不會“磨損”。 -硬件的失效率稱為“浴缸曲線”。 早期具有相對較高的失效率（來自設(shè)計或生產(chǎn)缺陷）， 缺陷被逐個糾正后，失效率隨之降低并在一段時間內(nèi)保持平穩(wěn)， 因灰塵、震動、不當(dāng)使用

2、、溫度超限等問題所造成的硬件組件損耗累積的效果而再次升高。 These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3軟件的特性(續(xù)3）n雖然整個工業(yè)向著基于構(gòu)件的構(gòu)造模式發(fā)展，然而大多數(shù)軟件仍是根據(jù)實際的顧客需求定制的。 -交互式用戶界面使用可復(fù)用構(gòu)件構(gòu)造圖形窗口、下拉菜單和各種交互機(jī)制。These slides are designed to a

3、ccompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 45遺留軟件n軟件必須進(jìn)行適應(yīng)性調(diào)整，以滿足新的計算環(huán)境和技術(shù)的需求。n軟件必須升級以實現(xiàn)新的商業(yè)需求。n軟件必須擴(kuò)展使之具有與更多現(xiàn)代系統(tǒng)和數(shù)據(jù)庫的互操作能力。n軟件必須進(jìn)行改建使之能適應(yīng)多樣化的網(wǎng)絡(luò)環(huán)境。為什么一定要變更為什么一定要變更? ?6軟件工程n若干事實:n在制定解決方案之前要理解問題n設(shè)計是一項關(guān)鍵的軟件工程活動n軟件必須保證高質(zhì)量n軟件需

4、具備可維護(hù)性n種子定義（Fritz Bauer)：n（軟件工程是）建立和使用一套合理的工程原則，以便經(jīng)濟(jì)地獲得可靠的、可以在實際機(jī)器上高效運行的軟件。 -未提及軟件質(zhì)量，直接談到用戶滿意度或按時交付產(chǎn)品的要求、忽略了測量和度量的重要性和有效的軟件過程的重要性。7軟件工程nIEEE 定義：n軟件工程是：（1）將系統(tǒng)化的、規(guī)范的、可量化的方法應(yīng)用于軟件的開發(fā)、運行和維護(hù)，即將工程化方法應(yīng)用于軟件。（2）在(1)中所述方法的研究。-需要規(guī)范，也需要可適應(yīng)性和靈活性8一種過程框架工作任務(wù)(task)工作產(chǎn)品里程碑和可交付成果QA 檢查點9框架包含的活動n溝通n策劃n建模n需求分析n設(shè)計n構(gòu)建n代碼生成

5、n測試n部署10普適性活動n軟件項目跟蹤和控制n風(fēng)險管理n軟件質(zhì)量保證n技術(shù)評審n測量n軟件配置管理n可復(fù)用管理n工作產(chǎn)品的準(zhǔn)備和生產(chǎn)11實踐的精髓nPolya 的建議：1.理解問題（溝通和分析）。2.計劃解決方案（建模和軟件設(shè)計）。3.實施計劃 （代碼生成）。4.檢查結(jié)果的準(zhǔn)確性（測試和質(zhì)量保證）。12Hooker的一般原則n1: 存在價值n2: 保持簡潔n3: 保持愿景n4:關(guān)注使用者n5: 面向未來n6: 計劃復(fù)用n7: 認(rèn)真思考13第二章 通用過程模型軟件過程過程框架普適性活動軟件工程活動#1.1框架活動#1工作任務(wù) 工作產(chǎn)品質(zhì)量保證點項目里程碑工作任務(wù) 工作產(chǎn)品質(zhì)量保證點項目里程碑框

6、架活動#n軟件工程活動#n.1軟件工程動作#n.m任務(wù)集任務(wù)集任務(wù)集任務(wù)集軟降工程動作#1.k工作任務(wù) 工作產(chǎn)品質(zhì)量保證點項目里程碑工作任務(wù) 工作產(chǎn)品質(zhì)量保證點項目里程碑14過程流溝通策劃建模(a)線性過程流構(gòu)建部署部署構(gòu)建建模策劃溝通(b)迭代過程流建模構(gòu)建(c)演化過程流部署策劃溝通增量交付溝通策劃建模時間構(gòu)建部署(c)并行過程流小型項目的獲取需求任務(wù)集1.制定項目的利益相關(guān)者列表2.邀請所有的利益相關(guān)者參加一個非正式會議。3.征詢每一個人對于軟件特征和功能的需求。4.討論需求，并確定最終的需求列表。5.劃定需求優(yōu)先級。6.標(biāo)出不確定領(lǐng)域。These slides are designed

7、 to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.15大型項目的獲取需求任務(wù)集1.制定項目的利益相關(guān)者列表2.和利益相關(guān)者的每一個成員分別單獨討論，獲取所有的要求。3.基于任務(wù)集2中的調(diào)查，建立初步的功能和特征列表。4.安排一系列促進(jìn)需求獲取的會議。5.組織會議。6.在每次會議上建立非正式的用戶場景。7.根據(jù)利益相關(guān)者的反饋，進(jìn)一步細(xì)化用戶場景。8.建立一個修正的需求列表。9.使用質(zhì)量功能部署

8、技術(shù)，劃分需求優(yōu)先級。10.將需求打包以便軟件可以增量交付。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.16大型項目的獲取需求任務(wù)集（續(xù)）11.標(biāo)注系統(tǒng)的約束和限制。12.討論系統(tǒng)驗證方法。These slides are designed to accompany Software Engineering: A Practitioner

9、s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1718過程模式類型n步驟模式定義了與過程的框架活動相關(guān)的問題。 例如“建立溝通”，它可能包括需求獲取等任務(wù)模式n任務(wù)模式定義了與軟件工程動作或是工作任務(wù)相關(guān)、關(guān)系軟件工程實踐成敗的問題。 例如“需求獲取” n階段模式定義在過程中發(fā)生的框架活動序列，即使 這些活動流本質(zhì)上是迭代的。 例如“螺旋模型”和“原型開發(fā)” 19瀑布模型C Co om m m m u un ni i c ca at ti i o on n P Pl la an nn n

10、i in ng g M M o od de el l i i n ng gC Co on ns st tr ru uc ct ti i o on nD De ep pl l o oy ym m e en nt t anal ysi s desi gncode testp pr ro oj j e ec ct t i i n ni i t ti i a at ti i o on n r re eq qu ui i r re em m e en nt t g ga at th he er ri i n ng ge es st ti im ma at ti in ng g s sc ch he ed

11、 du ul li in ng g t tr ra ac ck ki in ng gd de el l i i v ve er ry y s su up pp po or rt t f fe ee ed db ba ac ck k溝通項目啟動需求獲取策劃項目估算進(jìn)度計劃項目跟蹤建模分析設(shè)計構(gòu)建編碼測試部署交付支持反饋20V模型需求建模體系結(jié)構(gòu)設(shè)計構(gòu)件設(shè)計代碼生成單元測試集成測試系統(tǒng)測試驗收測試可執(zhí)行軟件使用中遇到的問題n實際的項目很少遵守瀑布模型提出的順序。n客戶通常難以清楚地描述所有的需求。n客戶必須要有耐心。These slides are designed to accompany So

12、ftware Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.21適用情形n當(dāng)需求確定、工作采用線性方式完成時。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.2223增量模型C C

13、o o m m m m u u n n i ic c a a t t i io o n nP P l la a n n n n i in n g gM M o o d d e e l li in n g gC C o o n n s s t t r ru u c c t t i io o n nD D e e p p l lo o y y m m e e n n t t d d e e l li iv v e e r ry y f fe e e e d d b b a a c c k kanal ysi s desi gncode testi ncrem ent # 1i ncrem ent

14、# 2del i very of 1st i ncrem entdel i very of 2nd i ncrem entdel i very of nth i ncrem enti ncrem ent # nproj ect cal endar ti m eC C o o m m m m u u n n i ic c a a t t i io o n nP P l la a n n n n i in n g gM M o o d d e e l li in n g gC C o o n n s s t t r ru u c c t t i io o n nD D e e p p l lo o

15、 y y m m e e n n t t d d e e l li iv v e e r ry y f fe e e e d d b b a a c c k kanal ysi s desi gncode testC C o o m m m m u u n n i ic c a a t t i io o n nP P l la a n n n n i in n g gM M o o d d e e l li in n g gC C o o n n s s t t r ru u c c t t i io o n nD D e e p p l lo o y y m m e e n n t t d

16、d e e l li iv v e e r ry y f fe e e e d d b b a a c c k kanal ysi s desi gncode test第1個增量第2個增量第n個增量交付第2個增量交付第3個增量交付第1個增量軟件功能和特征項目時間溝通策劃建模分析設(shè)計構(gòu)件編碼測試部署交付反饋溝通溝通策劃策劃建模分析設(shè)計建模分析設(shè)計構(gòu)件編碼測試構(gòu)件編碼測試部署交付反饋部署交付反饋適用情形n初始的軟件需求明確，但是整個開發(fā)過程卻不宜單純運用線性模型。同時，可能迫切需要為用戶迅速提供一套功能有限的軟件產(chǎn)品，然后在后續(xù)版本中再進(jìn)行細(xì)化和擴(kuò)展功能。 例如第一個增量往往是核心產(chǎn)品，附加功能進(jìn)

17、入下個增量計劃。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.24特點n綜合了線性過程流和并行過程流的特征。n每個增量都提交一個可以運行的產(chǎn)品。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-

18、Hill, 2009). Slides copyright 2009 by Roger Pressman.2526演化模型:原型開發(fā)Constructionof prototypeC C o o m m m m u u n n i ic ca at ti io o n nQ Q u u i ic ck k p p l la an nC C o o n n s st tr ru u c ct ti io o n n o o f f p p r ro o t to o t ty yp p e eM M o o d d e e l li in n g g Q Q u u i ic ck k d d

19、e e s si ig g n nD D e e l li iv ve e r ry y & & F Fe e e e d d b b a ac ck kD epl oym entcommunicationQuickplanModelingQuick designConstructionof prototypeDeploymentdelivery &feedback溝通快速策劃快速建模設(shè)計構(gòu)建原型部署交付及反饋適用情形n客戶提出了一些基本功能，但沒有詳細(xì)定義功能和特性需求n開發(fā)人員可能對算法的效率、操作系統(tǒng)的兼容性和人機(jī)交互的形式等情況并不確定These slides

20、are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.27特點n很少是好用的，可能太慢太大，難以使用。n一般作為被丟棄的系統(tǒng)。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyri

21、ght 2009 by Roger Pressman.2829演化模型：螺旋communicationplanning modelingconstructiondeployment delivery feedbackstartanalysis designcode testestimation scheduling risk analysis策劃項目估算制定進(jìn)度計劃風(fēng)險分析建模分析設(shè)計構(gòu)建編碼測試部署交付反饋溝通開始特點n采用循環(huán)的方式逐步加深系統(tǒng)定義和實現(xiàn)的深度，同時降低風(fēng)險。n確定一系列里程碑，確保利益相關(guān)者都支持可行的和令人滿意的系統(tǒng)解決方案。These slides are desig

22、ned to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.3031演化模型：協(xié)同Under r evi ewBasel i nedDoneUnderr evi si onAwai ti ngchangesUnderdevel opm entnoneModel i ng acti vi tyrepresents the stateof a software engi neeri ngacti vi

23、 ty or task建?；顒臃腔顒訝顟B(tài)表示阮籍工程活動或任務(wù)的某一狀態(tài)完成狀態(tài)已建立基線正在評審狀態(tài)正在開發(fā)狀態(tài)等待變更請求正在修改狀態(tài)特點(以建?；顒訛槔﹏在某一特定時間，建?；顒涌赡芴幱趫D中所示的任何一種狀態(tài)中。其他活動、動作或任務(wù)，可以用類似的方式表示。n所有的軟件工程活動同時存在并處于不同的狀態(tài)。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pr

24、essman.3233其他過程模型n基于構(gòu)件的開發(fā)這個過程模型能夠使軟件復(fù)用，是一個發(fā)展目標(biāo)n形式化方法強(qiáng)調(diào)需求的數(shù)學(xué)規(guī)范說明 一個變型是凈室（ cleanroom)軟件工程。n面向方面的軟件開發(fā)（AOSD）為定義、說明、設(shè)計和構(gòu)建方面提供過程和方法 如果某個關(guān)注點涉及系統(tǒng)多個方面的功能、特性和信息，可稱為橫切關(guān)注點，由方面性需求來定義。n統(tǒng)一過程一種“用例驅(qū)動，以架構(gòu)為核心，迭代并且增量”的軟件過程與統(tǒng)一建模語言的緊密結(jié)合34統(tǒng)一過程(UP)sof twar e i ncr em entRel easeI I n nc ce ep pt ti i o on nE El l a ab bo o

25、r ra at ti i o on nc co on ns st tr ru uc ct ti i o on nt tr ra an ns si i t ti i o on np pr ro od du uc ct ti i o on ninceptionelaboration起始細(xì)化策劃溝通部署轉(zhuǎn)換構(gòu)建構(gòu)建建模生產(chǎn)發(fā)布軟件增量35UP 階段I ncepti onEl aborati onConstructi onTransi ti onProducti onU UP P P Ph ha as se es sW Wo or rk kf fl lo ow ws sRequirementsAnal

26、ysisDesignImplementationTestIterations#1#2#n-1#nSupportUP階段需求工作流分析設(shè)計實現(xiàn)測試支持迭代起始細(xì)化構(gòu)建轉(zhuǎn)換生產(chǎn)36UP工作產(chǎn)品I ncepti on phaseEl aborati on phaseConstructi on phaseTransi ti on phaseVi si on docum ent I ni ti al use-case m odel I ni ti al proj ect gl ossaryI ni ti al busi ness case I ni ti al ri sk assessm ent. Pr

27、oj ect pl an, phases and i terati ons. Busi ness m odel , i f necessary. One or m ore prototypes I In nc ce ep pt ti io o n nUse-case m odelSuppl em entary requi rem ents i ncl udi ng non-functi onal Anal ysi s m odel Software archi tecture Descri pti on. Executabl e archi tectural prototype. Prel i

28、 m i nary desi gn m odel Revi sed ri sk l i stProj ect pl an i ncl udi ng i terati on pl an adapted workfl ows m i l estones techni cal work products Prel i m i nary user m anualDesi gn m odelSoftware com ponents I ntegrated software i ncrem ent Test pl an and procedure Test cases Support docum enta

29、ti on user m anual s i nstal l ati on m anual s descri pti on of current i ncrem ent Del i vered software i ncrem ent Beta test reports General user feedback起始階段愿景文檔初始用例模型初始項目術(shù)語初始商業(yè)案例初始風(fēng)險評估項目計劃，階段和迭代。商業(yè)模型，如果必要一個或更多的原型開發(fā)細(xì)化階段構(gòu)建階段轉(zhuǎn)換階段用例模型包括非功能性的補(bǔ)充需求分析模型軟件體系結(jié)構(gòu)描述可執(zhí)行體系結(jié)構(gòu)原型初步設(shè)計模型修訂風(fēng)險列表包含迭代計劃的項目策劃調(diào)整工作流里程碑技術(shù)

30、工作產(chǎn)品初步用戶手冊設(shè)計模型軟件構(gòu)件集成軟件增量測試計劃和步驟測試用例支持文檔用戶手冊安裝手冊當(dāng)前增量說明交付軟件增量Beta測試報告一般用戶反饋37第四章 質(zhì)量功能部署（QFD)(Quality Function Deployment, QFD)-將客戶要求轉(zhuǎn)化成軟件技術(shù)需求的質(zhì)量管理技術(shù)n3類需求：正常需求、期望需求和令人興奮的需求n功能部署決定系統(tǒng)所需的每一個功能的“價值”（由客戶感知）n信息部署確定數(shù)據(jù)對象和事件n任務(wù)部署檢查系統(tǒng)行為n價值分析決定需求的相對優(yōu)先權(quán)n用戶場景識別將要構(gòu)建系統(tǒng)的使用線索n產(chǎn)生需求表38第七章 設(shè)計nMitch Kapor，Lotus 1-2-3的創(chuàng)始人,在

31、 Dr. Dobbs雜志上發(fā)表了“軟件設(shè)計宣言”，他說：n良好的軟件設(shè)計應(yīng)該展示：n堅固：程序應(yīng)該不含任何妨礙其功能的缺陷。n適用：程序應(yīng)該符合開發(fā)的目標(biāo)。 n愉悅：使用程序的體驗應(yīng)是愉快的。實現(xiàn)設(shè)計目標(biāo)的途徑n先實現(xiàn)多樣化（獲取所有方案和設(shè)計的原始資料，包括目錄、教科書和頭腦中的構(gòu)件、構(gòu)件方案和知識），然后再進(jìn)行聚合。n匯聚信息后，挑選合適的元素，考慮取舍候選方案，然后聚合，使之成為“構(gòu)件的某種特定的配置，從而創(chuàng)建最終的產(chǎn)品。These slides are designed to accompany Software Engineering: A Practitioners Approac

32、h, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3940設(shè)計模型n數(shù)據(jù)設(shè)計n信息模型 軟件數(shù)據(jù)結(jié)構(gòu)n體系結(jié)構(gòu)設(shè)計n定義軟件部件間的關(guān)系n接口設(shè)計n軟件內(nèi)部、外部及與人之間的通信n構(gòu)件級（過程）設(shè)計n軟件組件的過程性描述41分析模型- 設(shè)計模型Anal ysi s M odeluse- cases - t ext use- case di agr am s act i vi t y di agr am s swi m l ane di agr am sdat a f l ow di agr am s cont

33、 r ol - f l ow di agr am s pr ocessi ng nar r at i vesf fl lo ow w - -o or ri ie en nt te ed d e el le em m e en nt ts sb be eh ha av vi io or ra al le el le em m e en nt ts sc cl la as ss s- -b ba as se ed de el le em m e en nt ts ss sc ce en na ar ri io o- -b ba as se ed de el le em m e en nt ts s

34、cl ass di agr am s anal ysi s packages CRC m odel s col l abor at i on di agr am s st at e di agr am s sequence di agr am sD D a at ta a/ /C Cl la as ss s D D e es si ig gn nA A r rc ch hi it te ec ct tu ur ra al l D D e es si ig gn nI In nt te er rf fa ac ce e D D e es si ig gn nC Co om m p po on n

35、e en nt t- - L Le ev ve el l D D e es si ig gn nDesi gn Model基于場景的元素用例文本用例圖活動圖泳道圖基于類的元素類圖分析包CRC模型協(xié)作圖行為元素狀態(tài)圖順序圖面向流的元素數(shù)據(jù)流圖控制流圖處理敘述設(shè)計模型數(shù)據(jù)/類設(shè)計體系結(jié)構(gòu)設(shè)計接口設(shè)計構(gòu)件級設(shè)計分析模型42質(zhì)量指導(dǎo)原則n設(shè)計應(yīng)展示出這樣一種結(jié)構(gòu)：（a）已經(jīng)使用可識別的體系結(jié)構(gòu)風(fēng)格或模式創(chuàng)建；（b）由展示出良好設(shè)計特征的構(gòu)件構(gòu)成；（c）能夠以演化的方式實現(xiàn)，從而便于實現(xiàn)和測試。n對于更小的系統(tǒng)，設(shè)計有時可以線性開發(fā)。n設(shè)計應(yīng)該模塊化；也就是說，應(yīng)將軟件邏輯地劃分為元素或子系統(tǒng)。n設(shè)計應(yīng)

36、該包含數(shù)據(jù)、體系結(jié)構(gòu)、接口和構(gòu)件的清晰表示。n設(shè)計應(yīng)導(dǎo)出數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)適用于要實現(xiàn)的類，并從可識別的數(shù)據(jù)模式提取。n設(shè)計應(yīng)導(dǎo)出顯示獨立功能特征的構(gòu)件。n設(shè)計應(yīng)導(dǎo)出接口，這些接口降低了構(gòu)件之間以及與外部環(huán)境連接的復(fù)雜性。n設(shè)計的導(dǎo)出應(yīng)根據(jù)軟件需求分析過程中獲取的信息采用可重復(fù)的方法進(jìn)行。n應(yīng)使用能夠有效傳達(dá)其意義的表示法來表達(dá)設(shè)計。43設(shè)計原則n設(shè)計過程中不要有“井蛙之見”。n設(shè)計應(yīng)起源于分析模型。n設(shè)計不要白費力氣做重復(fù)工作。n在軟件和真實世界的問題之間，設(shè)計應(yīng)能“最小化知識距離” DAV95 。n設(shè)計應(yīng)表現(xiàn)出一致性和集成性。n設(shè)計結(jié)構(gòu)應(yīng)適應(yīng)變化。n即使遇到數(shù)據(jù)、事件或操作條件異常時，

37、設(shè)計結(jié)構(gòu)應(yīng)能溫和處理。n設(shè)計不是編碼，編碼不是設(shè)計。n創(chuàng)建設(shè)計時就應(yīng)對其質(zhì)量進(jìn)行評估，而不是創(chuàng)建之后。n評審設(shè)計以最小化概念上的（語義的）錯誤。來自來自 Davis DAV9544為什么要信息隱藏？n減少“負(fù)效應(yīng)”的可能性n限制全局影響局部的設(shè)計決策n強(qiáng)調(diào)通過控制接口通信n不提倡使用全局?jǐn)?shù)據(jù)n導(dǎo)致封裝高質(zhì)量設(shè)計的屬性n導(dǎo)致高質(zhì)量軟件45功能獨立n通過開發(fā)具有“專一”功能和“避免”與其他模塊過多的交互的模塊，可以實現(xiàn)功能獨立。模塊的獨立性有兩條定性標(biāo)準(zhǔn)進(jìn)行評估：n內(nèi)聚性顯示了某個模塊相關(guān)功能的強(qiáng)度。n一個內(nèi)聚的模塊執(zhí)行一個獨立的任務(wù)，與程序的其他部分構(gòu)件只需要很少的交互。簡單地說，一個內(nèi)聚的模塊

38、應(yīng)該（理想情況下）只完成一件事情。n耦合性顯示了模塊間的相互依賴性。n耦合性依賴于模塊之間的接口復(fù)雜性、引用或進(jìn)入模塊所在的點以及什么數(shù)據(jù)通過接口進(jìn)行傳遞。模塊的獨立性高 n塊內(nèi)聯(lián)系強(qiáng) n塊間聯(lián)系弱 46七種內(nèi)聚n偶然內(nèi)聚偶然內(nèi)聚模塊內(nèi)各元素間無實質(zhì)性聯(lián)系，功能無關(guān)；如：“讀A”和“寫B(tài)”等操作，就是被整合在一個模塊中，供其他模塊調(diào)用。n邏輯內(nèi)聚邏輯內(nèi)聚模塊內(nèi)各元素在邏輯上相似功能；如：兩個邏輯上相似的兩個功能放在同一個模塊中，可以省去其中重復(fù)的部分。n時間內(nèi)聚時間內(nèi)聚模塊內(nèi)各元素在同一時間段內(nèi)執(zhí)行；如：變量初始化等，在同一時間內(nèi)執(zhí)行47七種內(nèi)聚n過程內(nèi)聚過程內(nèi)聚模塊內(nèi)元素必須以特定次序執(zhí)行；

39、n通信內(nèi)聚通信內(nèi)聚模塊內(nèi)所有元素使用同一輸入，產(chǎn)生同一輸出；n順序內(nèi)聚順序內(nèi)聚模塊內(nèi)元素必須以特定次序執(zhí)行，前者輸出為后者輸入；n功能內(nèi)聚功能內(nèi)聚模塊內(nèi)元素組成不可分的整體，完成特定功能。48七種耦合n非直接耦合非直接耦合兩模塊間沒有直接聯(lián)系n數(shù)據(jù)耦合數(shù)據(jù)耦合通過數(shù)據(jù)參數(shù)訪問另一模塊n特征耦合特征耦合通過數(shù)據(jù)結(jié)構(gòu)傳遞記錄信息n控制耦合控制耦合通過控制參數(shù)或開關(guān)量來訪問另一模塊n外部耦合外部耦合一組模塊訪問同一全局簡單變量n公共耦合公共耦合一組模塊訪問同一公共數(shù)據(jù)結(jié)構(gòu)n內(nèi)容耦合內(nèi)容耦合一個模塊直接轉(zhuǎn)入另一模塊內(nèi)49第八章 體系結(jié)構(gòu)風(fēng)格一組構(gòu)件一組連接件約束語義模型50體系結(jié)構(gòu)風(fēng)格n以數(shù)據(jù)為中心的

40、體系結(jié)構(gòu)n數(shù)據(jù)流體系結(jié)構(gòu)n調(diào)用和返回體系結(jié)構(gòu)n面向?qū)ο篌w系結(jié)構(gòu)n層次體系結(jié)構(gòu)51第九章 基本設(shè)計原則n開閉原則(OCP)?！澳K構(gòu)件應(yīng)該對外延具有開放性，對修改具有封閉性”。nLiskov 替換原則(LSP)?！白宇惪梢蕴鎿Q它們的基類”。n依賴倒置原則(DIP)?！耙蕾囉诔橄?，而非具體實現(xiàn)”。n接口分離原則(ISP)?！岸鄠€客戶專用接口比一個通用接口要好”。n發(fā)布復(fù)用等價性原則(REP)。“復(fù)用的粒度就是發(fā)布的粒度”。n共同封裝原則(CCP)?！耙煌兏念悜?yīng)該合在一起”。n共同復(fù)用原則(CRP).?！安荒芤黄饛?fù)用的類不能被分到一組”。52第十章 黃金規(guī)則n用戶操縱控制n減少用戶的記憶負(fù)擔(dān)n保

41、持界面一致53用戶操作控制54減輕用戶記憶負(fù)擔(dān)55保持界面一致第十四章 軟件質(zhì)量保證n延伸前述的質(zhì)量定義，軟件質(zhì)量保證就是為了保證軟件高質(zhì)量而必需的“有計劃、系統(tǒng)化的行動模式”。n軟件質(zhì)量保證（質(zhì)量管理）是適用于整個軟件過程的一種普適性活動，而不僅僅是在編碼完成之后才開始進(jìn)行。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 56軟件質(zhì)量保證n

42、軟件質(zhì)量保證是由兩個不同人群相聯(lián)系的多種任務(wù)組成分別是做技術(shù)工作的軟件工程師和負(fù)有質(zhì)量策劃、監(jiān)督、記錄、分析和報告責(zé)任的軟件質(zhì)量保證組。n其中，軟件工程師通過采用可靠的技術(shù)方法和措施，進(jìn)行技術(shù)評審，并進(jìn)行周密計劃的軟件測試來獲得質(zhì)量。n可見，軟件測試是軟件質(zhì)量保證活動中的一部分。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5758軟件測試

43、測試是在交付產(chǎn)品給最終用戶之前，帶測試是在交付產(chǎn)品給最終用戶之前，帶著特定的目的在運行程序的過程中發(fā)現(xiàn)著特定的目的在運行程序的過程中發(fā)現(xiàn)錯誤。錯誤。測試的目的是為了發(fā)現(xiàn)測試對象的問題測試的目的是為了發(fā)現(xiàn)測試對象的問題，而不是證明測試對象沒有問題。，而不是證明測試對象沒有問題。59驗證與確認(rèn) 書為主n軟件測試是通常所講的更為廣泛的主題驗證與確認(rèn)的一部分。n驗證是指確保軟件正確地實現(xiàn)某一特定功能的一系列活動。 n確認(rèn)指的是確保開發(fā)的軟件可追溯到客戶需求的另外一系列活動。Boehm Boe81 用另一種方式說明了這兩者的區(qū)別：n驗證：我們在正確地構(gòu)造產(chǎn)品嗎？n確認(rèn)：我們在構(gòu)造正確的產(chǎn)品嗎？單元測試n

44、單元測試是對軟件的基本組成單元進(jìn)行測試。n單元可以是：函數(shù)、子過程函數(shù)、子過程 類或類的方法類或類的方法 獨立的過程和函數(shù)獨立的過程和函數(shù) 一個菜單或顯示界面一個菜單或顯示界面These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 60單元測試的主要任務(wù)These slides are designed to accompany Software E

45、ngineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 61模模塊塊模模塊塊接口接口局部數(shù)據(jù)局部數(shù)據(jù)結(jié)結(jié)構(gòu)構(gòu)獨立路徑獨立路徑測試測試出出錯處錯處理理邊邊界條件界條件增量式測試增量式測試的集成是逐步實現(xiàn)的： 逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實施次序，增量式集成測試又可以分為三種不同的方法： （1）自頂向下增量式測試 （

46、2）自底向上增量式測試 （3）三明治測試混合增量測試These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 62自頂向下增量式測試n自頂向下增量式測試表示逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進(jìn)行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)

47、中去。n深度優(yōu)先方式的集成： 首先集成在結(jié)構(gòu)中的一個主控路徑下的所有模塊，。 n廣度優(yōu)先方式的集成： 首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6364自頂向下集成自底向上增量式測試n自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進(jìn)行的，即從程序

48、模塊結(jié)構(gòu)的最底層模塊開始集成和測試。n由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進(jìn)行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6566自底向上集成67三明治測試混合增量式測試是把

49、自頂向下測試和自底向上測試這兩種方式結(jié)合起來進(jìn)行集成和測試。這樣可以兼具兩者的優(yōu)點，而摒棄其缺點。68回歸測試n回歸測試重新執(zhí)行已測試過的某些子集，以確保變更沒有傳播不期望的副作用。n無論什么時候修正軟件，軟件配置的某些方面（程序、文檔或支持?jǐn)?shù)據(jù)）也發(fā)生變更。n回歸測試有助于保證變更（由于測試或其他原因）不引入無意識行為或額外的錯誤。n回歸測試可以手工進(jìn)行，方法是重新執(zhí)行所有測試用例的子集，或者利用捕捉/回放工具自動進(jìn)行。69冒煙測試n為生產(chǎn)軟件創(chuàng)建“每日構(gòu)建”的一種常見方法n冒煙測試步驟：n將已經(jīng)轉(zhuǎn)換為代碼的軟件構(gòu)件集成到“構(gòu)建”中去。 一個構(gòu)建包括所有的數(shù)據(jù)文件、庫、可復(fù)用的模塊以及實現(xiàn)一

50、個或多個產(chǎn)品功能所需的工程化構(gòu)件。n設(shè)計一系列測試以暴露影響構(gòu)建正確地完成其功能的錯誤。 其目的是為了發(fā)現(xiàn)極有可能造成項目延遲的“業(yè)務(wù)阻塞”錯誤。n每天將該構(gòu)建與其他構(gòu)建及整個軟件產(chǎn)品（以其當(dāng)前的形式）集成起來進(jìn)行冒煙測試。 這種集成方法可以是自頂向下，也可以自底向上。70測試CRC模型71高階測試n確認(rèn)測試n關(guān)注點是軟件需求 確認(rèn)測試也稱為合格性測試，是檢驗所開發(fā)的軟件是否能按用戶提出的要求進(jìn)行。軟件確認(rèn)要通過一系列證明軟件功能和要求一致的黑盒測試來完成，傳統(tǒng)軟件、面向?qū)ο筌浖癢ebApp之間的差別已經(jīng)消失。n系統(tǒng)測試n關(guān)注點是系統(tǒng)集成 由于軟件只是計算機(jī)系統(tǒng)中的一個組成部分，軟件開發(fā)完成

51、之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運行。這些測試已經(jīng)超出軟件過程范圍，而且不僅僅由軟件工程師執(zhí)行。n/測試n關(guān)注點是客戶使用 測試是由有代表性的最終用戶在開發(fā)者的現(xiàn)場進(jìn)行的，開發(fā)者在后面觀看，并記錄錯誤和使用問題。 測試是在一個或者多個最終用戶場所進(jìn)行。開發(fā)者通常不在場。高階測試n恢復(fù)測試n通過各種方式強(qiáng)制地使軟件發(fā)生故障，并驗證其能適當(dāng)恢復(fù)。n安全測試n驗證建立在系統(tǒng)內(nèi)的保護(hù)機(jī)制是否能夠?qū)嶋H保護(hù)系統(tǒng)不受非法入侵。n壓力測試n 以非正常的數(shù)量、頻率或容量的方式執(zhí)行系統(tǒng)。測試是想要破壞程序。 n舉例： 如果正常的中斷頻率為每秒5次，強(qiáng)度測試設(shè)計為每秒50次中斷

52、。 把輸入數(shù)據(jù)的量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)。 若某系統(tǒng)正常運行可支持200個終端并行工作，強(qiáng)度測試則檢驗1000個終端并行工作的情況。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 72高階測試n性能測試n用來測試軟件在集成環(huán)境中的運行性能，特別是針對實時系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。

53、n性能測試可以在測試過程的任意階段進(jìn)行，但只有當(dāng)整個系統(tǒng)的所有成分都集成在一起后，才能檢查一個系統(tǒng)的真正性能。n性能測試常常和強(qiáng)度（壓力）測試結(jié)合起來進(jìn)行，而且常常需要硬件和軟件測試設(shè)備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7374第十五章 可測試性n軟件工程師在設(shè)計與實現(xiàn)基于計算機(jī)的系統(tǒng)或產(chǎn)品時，應(yīng)該想著可測試性。n軟件的可測試性是能夠被測試的容易程度?？蓽y試的軟件應(yīng)該具有下述特征：n可操作性有效地操作n可觀察性每個測試用例的結(jié)果都是易觀察的n可控制性測試