?

《軟件工程——面向?qū)ο蠛蛡鹘y(tǒng)的方法》復習筆記

?

第一章 軟件工程的范疇

引言

可以結(jié)合 軟件工程導論第六版 --張海藩

1.軟件工程概念：

軟件工程是一門學科，目的是生產(chǎn)出沒有錯誤的軟件，按時并且在預算內(nèi)交付，滿足用戶的需求。更進一步，當用戶的需求改變時，軟件必須易于修改。

2.軟件工程范疇：

軟件工程的范疇非常廣。軟件工程的某些方面可以歸入數(shù)學或計算機科學；其他方面可以落入經(jīng)濟學、管理學或者心理學的范疇。我們可以從歷史方面、經(jīng)濟方面、維護性方面、需求分析設(shè)計方面、小組編程方面等五個方面進行考察。

3.軟件制品：

軟件制品是軟件產(chǎn)品的組成部分，如規(guī)格說明文檔、代碼模塊或手冊，它結(jié)合了屬性和對屬性的操作。

4.回歸錯誤：

指對軟件某處進行修改時，不小心在與該處明顯沒有關(guān)聯(lián)的另一處造成新的錯誤。

1.1歷史方面

軟件危機：

顧名思義，軟件危機指軟件產(chǎn)品的質(zhì)量低的通常不能接受，并且不能滿足交付日期和預算限制。

1.2經(jīng)濟方面

2014年真題：

使用舊編碼技術(shù)CTold的軟件組織發(fā)現(xiàn)使用新的編碼技術(shù)CTnew之后，編寫代碼的時間比舊編碼技術(shù)少花1/10，因此花費也少1/10.通常大家都認為使用新技術(shù)CTnew比較恰當，對此你怎么看？

答案：實際上，雖然大家普遍認為速度快的技術(shù)應(yīng)當成為技術(shù)的首選，但是從軟件工程的經(jīng)濟觀點卻認為選擇舊編碼技術(shù)比較合適。原因如下：（1）新技術(shù)引入一個組織的花費十分高昂。使用CTnew技術(shù)后編碼速度提高了10%，這與將新技術(shù)引入開發(fā)組織中的花費相比沒有那么重要。（2）軟件工程經(jīng)濟學建議保留舊編碼技術(shù)的第二個重要原因是維護問題。從滿足用戶需求的角度來看，新舊技術(shù)的代碼質(zhì)量相當，但是信技術(shù)的使用導致代碼很難維護，從整個產(chǎn)品的周期來看，使用新技術(shù)的耗費要大一些。

1.3維護性方面

傳統(tǒng)范型的生命周期模型：

（1）需求階段。在需求分析階段，對概念進行研究和細化，提取客戶的需求。

（2）分析（規(guī)格說明）階段。分析客戶需求并以規(guī)格說明文檔的形式給出，同時階段結(jié)束時，制定出計劃，稱為軟件項目管理計劃，詳細描述期望的軟件開發(fā)。

（3）設(shè)計階段。第一步是結(jié)構(gòu)設(shè)計、將作為整體的產(chǎn)品分解成各個模塊，然后通過詳細設(shè)計

對各個模塊進行設(shè)計，最終得到兩個設(shè)計文檔。

（4）實現(xiàn)階段。對各個部分獨立地進行代碼編寫和測試（單元測試、集成測試），最后由客戶對產(chǎn)品進行驗收測試

（5）交付后維護。交付后維護包括在產(chǎn)品交付并安裝到客戶計算機中并通過驗收測試后對產(chǎn)品所做的全部改動。它可以分為糾錯性維護、增強性維護。糾錯性維護主要是去掉殘存錯誤，它不對規(guī)格說明文檔做修改；增強性維護則是在對規(guī)格說明文檔進行修改的同時，實現(xiàn)這些修改。有兩種類型的增強性維護：完善性維護、適應(yīng)性維護。

（6）退役。退役，發(fā)生在當產(chǎn)品推出服務(wù)的時候。當產(chǎn)品功能不再對客戶組織有用的時候，就不再使用該產(chǎn)品。

1.4需求、分析和設(shè)計方面

無重點

1.5小組編程方面

無重點

其他：

?

為什么沒有計劃階段？

為什么沒有測試階段？

答案：一個軟件產(chǎn)品準備好交付給客戶時才檢查它實在是太晚了。在軟件開發(fā)過程中，對產(chǎn)品進行測試伴隨著整個產(chǎn)品的開發(fā)和維護之中。如果測試看作一個獨立的階段，那么會有不將測試連續(xù)貫穿于產(chǎn)品開發(fā)和維護的每個階段的實際危險。開發(fā)人員需要不斷進行測試保證軟件產(chǎn)品盡可能在所有時候都沒有差錯。因此，不能將軟件測試劃分為一個獨立的階段。

2013年為什么沒有文檔階段？

答案：（1）確保文檔最新很重要的一個原因是軟件行業(yè)中人員的流動性比較大

（2）如果前一階段的文檔不是完整、正確和最新的，幾乎不可能執(zhí)行下一階段的步驟

（3）除非提供文檔來說明對一個軟件產(chǎn)品的期望，否則不可能測試該軟件產(chǎn)品是否正確工作 （4）如果沒有一套完整、正確的文檔精確的描述產(chǎn)品的當前版本做些什么，維護幾乎是不可能的。

因此，計劃、測試和文檔活動應(yīng)當伴隨著建造軟件產(chǎn)品的所有其他活動進行。

?

第二章 軟件生命周期模型

１.移動目標問題:　在軟件正在開發(fā)的時候，需求改變了。

２.測試驅(qū)動開發(fā)（TDD）：一個程序員首先制定出任務(wù)的測試用例

３.結(jié)對編程：兩個程序員在一臺計算機前一起工作

４.重組：在建造產(chǎn)品的過程中設(shè)計在不斷地調(diào)整

５.光盒：使用了多年的時間管理技術(shù)。為一項任務(wù)設(shè)定一段時間，小組成員在這段時間里盡可能好的做工作。

５.極限編程：

它是一些新的統(tǒng)稱為敏捷過程地范型中的一個，是在迭代——遞增模型的基礎(chǔ)上發(fā)展起來的一種頗有爭議的新的軟件開發(fā)方法，能夠快速響應(yīng)需求變化。

特性：XP小組的計算機設(shè)在一個大房間的中心，大房間中有許多彼此連接的小隔間；一個客戶代表一直與XP小組工作；沒有一個人能夠連續(xù)兩周超時工作；沒有規(guī)格說明，而是XP小組的所有成員一同完成需求、分析、設(shè)計、編碼和測試；在建造出各種構(gòu)件之前沒有概要設(shè)計步驟。

6.軟件的生命周期模型比較:-----2016

?

第三章 統(tǒng)一過程

1.軟件過程

軟件過程是生產(chǎn)軟件的方式,包括方法學,生命周期模型,技術(shù)和工具,以及所有這些因素中最重要的部分:建造這些軟件的人.

2.軟件過程的改進:

軟件過程的改進包括改進能力成熟度模型CMM,國際化組織指定的ISO9000系列標準以及ISO/IEC15504(后者是涉及40多個國家的一個國際軟件改進的創(chuàng)見性建議).還有,要考慮的是,軟件過程改進的代價和效益.

軟件改進運動非常有意思的影響是:軟件過程改進的嘗試和軟件工程的標準之間發(fā)生相互作用,這種軟件工程標準化組織和軟件改進之間的相互影響,真正促進了軟件過程的改進.

3.統(tǒng)一過程和統(tǒng)一建模語言----2015

統(tǒng)一過程,是一種自適應(yīng)的方法學,是目前最主要的面向?qū)ο箝_發(fā)方法;統(tǒng)一建模語言,是用來模擬目標軟件產(chǎn)品的模型工具,目前最常用的統(tǒng)一建模語言是UML.

4.統(tǒng)一過程核心工作流:----2016

(1)需求流:目標是讓開發(fā)組織確定客戶的需求

(2)分析流:目標是分析和提取需求

(3)設(shè)計流:細化分析流的制品,直至材料處于程序員可實現(xiàn)的形式

(4)實現(xiàn)流:目標是用選擇的實現(xiàn)語言實現(xiàn)目標軟件產(chǎn)品

(5)測試流:始終與其他工作流并發(fā)執(zhí)行,確保各階段軟件制品的正確性

?

5.統(tǒng)一過程的四個階段

(1)開始階段: 明確提出的軟件產(chǎn)品經(jīng)濟上是否可行

(2)細化階段: 細化最初的需求

(3)構(gòu)建階段: 產(chǎn)生軟件產(chǎn)品的第一個可工作版本

(4)轉(zhuǎn)換階段: 確保客戶的需求切實得到滿足

6.可追蹤性

需求制品所具有的屬性,能夠?qū)Ψ治鲋破?設(shè)計制品,實現(xiàn)制品中的每一項追蹤到需求制品,確保它們是客戶需求的真實反映.當SQA(軟件質(zhì)量保證)小組檢查需求小組成員工作時也可以簡化工作.

7.能力成熟度模型CMM -----2012

CMM,是一組用于改進軟件過程的相關(guān)策略,它不考慮實際使用的軟件生命周期模型.CMMI,能力成熟度模型集成,將5個現(xiàn)存的能力成熟度模型集成進一個模型,將來還可以加入另外的約束.

SW-CMM用于軟件的

P-CMM	用于人力資源管理的;
SE-CMM	用于系統(tǒng)工程的；
IPD－CMM	用于集成產(chǎn)品開發(fā)的；
SA-CMM	用于軟件獲取的

級別關(guān)鍵過程區(qū)措施

5.最優(yōu)級	錯誤預防\技術(shù)變更管理\過程變更管理	持續(xù)改進軟件過程
4.管理級	量化過程管理\軟件質(zhì)量管理	為每個項目設(shè)計了質(zhì)量目標和生產(chǎn)目標
3.定義級	集成軟件管理\軟件項目工程\組間協(xié)調(diào)\對等檢查	有充分的軟件生產(chǎn)文檔
2.可重復級	需求管理\軟件項目計劃\軟件項目追蹤和遺漏\軟件質(zhì)量保證\軟件配置管理	使用了基本的軟件項目管理措施
1.初始級	不可應(yīng)用	?

?

第四章 軟件小組

2012--2013--2014--2016--2017

1.民主小組

一個民主小組,是為了一個共同的事業(yè)而工作的團體,沒有單獨的領(lǐng)導,沒有程序員視圖提升到更高的職位,最重要的是小組的群體特征和相互尊重.

優(yōu)點:對查找錯誤的積極態(tài)度,錯誤能夠更快被發(fā)現(xiàn),代碼質(zhì)量更高.

2.主程序員小組

編程秘書----主程序員-----備程序員

程序員 程序員 程序員

?

主程序員: 既是一個成功的管理者,也是一個訓練有素的程序員,完成結(jié)構(gòu)化設(shè)計以及代碼中的關(guān)鍵和復雜部分.其他的小組成員在主程序員的指導下進行具體的細節(jié)設(shè)計和編寫代碼.在程序員之間沒有溝通的渠道,所有的接口問題都有主程序員解決,最后,主程序員審查其他小組成員的工作,因為主程序員個人要對每行代碼負責.

備程序員: 應(yīng)該在各方面和主程序員一樣有能力,并且需要和主程序員一樣深入了解這個項目.另外,為讓主程序員集中精力進行結(jié)構(gòu)化設(shè)計,備程序員應(yīng)該進行黑盒測試的用例規(guī)化,并承擔其他與設(shè)計過程獨立的任務(wù).

編程秘書: 不是一個兼職的辦公助手,而是主程序員小組中一個精通專業(yè),收入頗豐的核心人物.負責維護項目產(chǎn)品庫,及項目的文檔.程序員將他們的源程序交給編程秘書,有編程秘書負責將它們轉(zhuǎn)換為及其可識別的形式,編譯,鏈接,裝載,運行,執(zhí)行并測試用例.

程序員:只進行編程,其他的工作都交給編程秘書來做.

?

缺點:不僅高水平的程序員缺乏,成功的管理者同樣缺乏,找到一個主程序員的幾率不大.備程序員和編程秘書也很難找到.

3.現(xiàn)代編程小組

小組經(jīng)理 小組領(lǐng)導

程序員 程序員 程序員

小組領(lǐng)導,負責小組活動中技術(shù)方面的事務(wù);小組經(jīng)理,負責所有非技術(shù)性的管理事務(wù).

優(yōu)點:進行分散決策,但同時擁有民主小組的優(yōu)點,能夠適用于大型項目的開發(fā).

4.同步--穩(wěn)定小組

微軟公司使用的同步---穩(wěn)定小組,但是使用同步---穩(wěn)定生命周期模型和相關(guān)的小組組織極難像微軟公司這樣的成功,不具有普世作用.

5.敏捷過程小組

核心是結(jié)對編程.

6.開源編程小組

例如:linux,apache這種成功的開源項目,核心:一個出色的有號召力的關(guān)鍵人物.

一個開源項目的成功是因為目標產(chǎn)品的特性,組織者的個性以及核心小組成員的天資.一個公開源碼的小組的成功與其小組組織方式基本上沒有關(guān)系.

?

小組組織優(yōu)點缺點

民主小組	由于積極地尋找錯誤,因而代碼質(zhì)量高,特別適用于解決難的問題	有經(jīng)驗的人反感新手的評價不能從外部強加
傳統(tǒng)的主程序員小組	<<紐約時報>>項目的成功之處	不實用
修改的主程序員小組	有許多成功的范例	沒有與<<紐約時報>>項目可比擬的成功范例
現(xiàn)代程序員小組	小組經(jīng)理/小組領(lǐng)導結(jié)構(gòu)避免對主程序員需求,可擴展,必要時支持分散決策	除非明確小組領(lǐng)導和小組經(jīng)理之間的負責范圍,否則容易產(chǎn)生問題
同步--穩(wěn)定小組	鼓勵創(chuàng)造性,確保大量開發(fā)者為共同目標工作	在微軟公司之外還沒有該方案的應(yīng)用的實例
敏捷過程小組	程序員不測試自己的代碼,如果一個程序員離開不會有損失,經(jīng)驗欠缺的程序員可以向其他人學習,代碼具有小組所有權(quán)	還沒有更多的實例證實它的成功
開源小組	少數(shù)項目非常成功	應(yīng)用面窄,需由許多出色的有號召力的人領(lǐng)導,需要頂尖高手參與

?

注:實踐中,目前多數(shù)小組都采用主程序員小組形式的某種變種.

第五章 軟件過程工具

注:逐步求精\成本效益分析法:兩種貫穿于軟件生命周期的基礎(chǔ)理論性的軟件工程技術(shù)

1.逐步求精法

逐步求精,是一個解決問題的技術(shù),是許多軟件工程技術(shù)的基礎(chǔ),可定義為"盡可能將細節(jié)的定義推研到最后,以便于集中精力在重要的事項上"的一種方法.逐步求精法潛在地支撐著許多規(guī)格說明技術(shù),設(shè)計和實現(xiàn)技術(shù),甚至測試和集成技術(shù).

優(yōu)點:幫助軟件工程師集中精力于當前開發(fā)任務(wù)地相關(guān)方面,并忽略一些細節(jié),盡管這些細節(jié)在總體方案中是必要的,但是也不能考慮.

2.成本---效益分析法

成本效益分析法,對比---估計的未來收益和預測的未來成本----的一種方法.是確定客戶是否應(yīng)該進行業(yè)務(wù)計算機化的 基本技術(shù),如果確定使用計算機處理業(yè)務(wù),應(yīng)用何種方式來比較各種可選方案的成本和收益.

優(yōu)點:(1)通過假設(shè)的辦法給無形的收益確定金錢數(shù)量的一個實際辦法,假設(shè)與得到的收益估算值結(jié)合起來.

(2)在對數(shù)據(jù)進行審核時,可以根據(jù)數(shù)據(jù)中潛在的假設(shè)提出更好的假設(shè),能產(chǎn)生更好的數(shù)據(jù),無形收益可以計算的更加準確.

3.分治技術(shù)

分治技術(shù):把整個問題分解為重要程度相同的子問題.

4.關(guān)注分離

5.軟件度量

1.產(chǎn)品度量:測量產(chǎn)品本身的某個特性,例如:規(guī)模和可靠性.

2.過程度量:開發(fā)者使用這種度量推斷軟件開發(fā)過程的信息,典型例子:開發(fā)過程中檢測錯誤的有效性.

6.CASE

CASE的最簡形式是軟件工具，只在軟件生產(chǎn)的某一方面其幫助作用的軟件產(chǎn)品．

分類：數(shù)據(jù)字典;一致性檢查器;報表生成器;屏幕生成器;

7.軟件版本

１.修訂版：如果在一個制品中發(fā)現(xiàn)了錯誤之后，修復了該制品．經(jīng)過適當?shù)男薷闹?#xff0c;該制品會有兩個版本，老版本和將要替代老版本的新版本，那么新版本就稱作修訂版．

２.變種版：與專門為了替代前面版本的修訂版不同，變種版是為共存而設(shè)計的．需要變種版的一個情況是產(chǎn)品要和多種不同操作系統(tǒng)或硬件接口，可能需要為每一種操作系統(tǒng)或者硬件接口組合生產(chǎn)多個制品的不同變種版．

8.配置控制

制品的三種形式：源代碼－－－＞目標代碼－－－＞可執(zhí)行載入映像

１.配置：

某個完成的產(chǎn)品的給定版本所賴以建造的每個制品的特定版本稱為該產(chǎn)品那個版本的配置．

注：配置控制工具可以自動管理多個變種版，但配置控制的作用不局限于多個變種版．配置控制工具還能處理小組開發(fā)和維護時出現(xiàn)的問題．

２.基準：

它是產(chǎn)品中所有制品的配置（版本集）．當要尋找錯誤時，維護程序員把所需的制品復制到自己的個人工作臺中．在這個個人工作臺中，程序員可以做任何修改，對其他程序員沒有任何影響，因為修改的只是該程序員的個人副本，基準版還保持未動．

?

?

第六章 測試

1．故障:是觀察到的軟件產(chǎn)品的不正確的行為,它是差錯的結(jié)果;

　錯誤:是不正確的結(jié)果的累積;

缺陷:是一個通用詞匯,泛指差錯.故障或者錯誤.

2．軟件質(zhì)量:產(chǎn)品滿足規(guī)格說明的程度

3．軟件質(zhì)量保證(SQA)：原則是確保軟件過程的質(zhì)量，從而確保軟件產(chǎn)品的質(zhì)量．

４.走查：評審軟件的方式,進行非執(zhí)行測試:(測試軟件但不運行測試用例),比審查的步驟少且不那么正式.

走查步驟: (1)準備 ;(2)小組對文檔進行分析

5.審查的步驟:

(1)概要: 由負責文檔的人提供被審查的的文檔概要.

(2)準備: 處在準備中,參加者設(shè)法詳細理解文檔

(3)審查: 開始審查

(4)修訂: 處于修訂中,負責該文檔的個人改正審查報告中列出的所有錯誤和問題.

(5)跟蹤: 處于跟蹤狀態(tài),主持者必須確認提出的每個事項都得到滿意的解決,或者修改文檔,或者澄清被誤當成錯誤的事項.

6.測試的特性:

(1)正確性:產(chǎn)品在允許的條件下運行,能夠滿足輸出規(guī)格說明,并與使用的計算資源無關(guān)

(2)實用性:在規(guī)格說明允許的條件下使用正確的產(chǎn)品時,滿足用戶需求的程度.

(3)可靠性:對產(chǎn)品故障的出現(xiàn)頻率和嚴重性進行的測試.

---->平均故障時間:隔多久出現(xiàn)故障;

---->平均修復時間:修復故障的時間用了多久

(4)健壯性:運行條件的范圍,有效輸入帶來不可接受的結(jié)果的可能性以及產(chǎn)品的輸入無效時結(jié)果的可接受性.

(5)性能:根據(jù)時間或者空間要求,產(chǎn)品所受限制的程度.

第七章 從模塊到對象

1.模塊:

模塊是詞匯上鄰接的程序語句序列,由邊界元素限制范圍,有一個聚合標識符.

2.模塊內(nèi)聚:

模塊內(nèi)部的交互程度;

3.模塊耦合:

模塊之間的交互程度;

4.內(nèi)聚:

壞-------------------------------------------------------->好

(1)偶然內(nèi)聚:一個模塊執(zhí)行完全不相關(guān)的操作;

(2)邏輯內(nèi)聚:當一個模塊進行一系列相關(guān)的操作,每個操作由調(diào)用模塊來選擇;

(3)時間內(nèi)聚:一個模塊執(zhí)行一系列與時間有關(guān)的操作;

(4)過程內(nèi)聚:一個模塊執(zhí)行一系列與產(chǎn)品要遵循的步驟順序有關(guān)的操作;

(5)通信內(nèi)聚:一個模塊執(zhí)行一系列與產(chǎn)品要遵循的步驟順序有關(guān)的操作,并且所有操作對相同數(shù)據(jù)進行;

(6)功能內(nèi)聚:只執(zhí)行一個操作或只達到單一目標的模塊;

(7)信息內(nèi)聚:模塊進行許多操作,每個都有各自的入口點,每個操作的代碼相對獨立,而且所有操作都對相同的數(shù)據(jù)結(jié)構(gòu)完成;

第八章 可重用性和可移植性

第九章 計劃和估算

總結(jié)

以上是生活随笔為你收集整理的考研《软件工程--面向对象和传统的方法》复习笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。