第一篇：軟件工程考點總結(jié)

關(guān)類組成一個層次結(jié)構(gòu)的系統(tǒng)；

4、對象彼此間只能通過發(fā)送消息相互聯(lián)系。

面向?qū)ο罅硪粋€優(yōu)點是軟件可重用。（6）：軟件生命周期？

1、問題定義

2、可行性研究

3、需求分析

4、總體設(shè)計

5、詳細(xì)設(shè)計

6、編碼和單元測試

7、綜合測試

8、軟件維護

（7）：幾個模型優(yōu)缺點

1、瀑布模型

優(yōu)點：可強迫開發(fā)人員采用規(guī)范的方法；嚴(yán)格地規(guī)定了每個階段必須提交的文檔；要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗證。

缺點：瀑布模型是由文檔驅(qū)動的這個事實也是它的一個主要缺點。由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需求。

2、快速原型模型

優(yōu)點：是不帶反饋環(huán)的，軟件產(chǎn)品開發(fā)基本上是線性順序進行的。缺點：快速原型的本質(zhì)是“快速”，開發(fā)人員應(yīng)盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本，原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。

3、增量模型

優(yōu)點：能在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，是增量模型的一個優(yōu)點，另一個優(yōu)點是逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。

缺點：把每個新的增量構(gòu)件集成到現(xiàn)有的軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設(shè)計的便于按這種方式進行擴充，軟件體系結(jié)構(gòu)必須是開放的。

4、螺旋模型

優(yōu)點：對可選方案和約束條件的強調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標(biāo)；減少了過多測試或測試不足所帶來的風(fēng)險；更重要的是，在螺旋模型中維護只是模型的另一個周期，在維護和開發(fā)之間并沒有本質(zhì)區(qū)別。

缺點：是風(fēng)險驅(qū)動的。軟件開發(fā)人員具有豐富的風(fēng)險評估經(jīng)驗和這方面專門的知識，否則項目實際上正在走向災(zāi)難時，開發(fā)人員可能還認(rèn)為一切正常。

5、噴泉模型

優(yōu)點：體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特征。缺點：開發(fā)軟件是會產(chǎn)生無序現(xiàn)象。

目的：就是用最小的代價在盡可能短的時間內(nèi)確定問題是否能夠解決。任務(wù)：在較高層次上以較抽象的方式進行的系統(tǒng)分析和設(shè)計的過程。以便于對以后的行動方針提出建議。

過程：

1、復(fù)查系統(tǒng)規(guī)模和目標(biāo)

2、研究目前正在使用的系統(tǒng)

3、到處新系統(tǒng)的高層次邏輯模型

4、進一步定義問題

5、導(dǎo)出和評價供選擇的解法

6、推薦行動方針

7、草擬開發(fā)計劃

8、書寫文檔提交審查

（2）：數(shù)據(jù)字典4類元素

1、數(shù)據(jù)流

2、數(shù)據(jù)流分量

3、數(shù)據(jù)存儲

4、、處理

（3）：成本估計技術(shù)

1、代碼行技術(shù)

2、任務(wù)分解技術(shù)

3、自動估計成本技術(shù)

（4）：成本效益分析方法，考慮方面？

1、貨幣的時間價值

2、投資回收期

3、純收入

4、投資回收率

（1）：設(shè)計過程的9個步驟

1、設(shè)想供選擇的方案

2、選取合理的方案

3、推薦最佳的方案

4、功能分解

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

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

7、制定測試計劃

8、書寫文檔

9、審查和復(fù)審（2）：軟件設(shè)計的原理

1、模塊化

2、抽象

3、逐步求精

4、信息隱藏和局部化

5、模塊獨立（3）：啟發(fā)規(guī)則

1、改進軟件結(jié)構(gòu)提高模塊獨立性

2、模塊規(guī)模應(yīng)該適中

3、深度、寬度、扇出和扇入都應(yīng)適當(dāng)

4、模塊的作用域應(yīng)該在控制域之內(nèi)

5、力爭降低模塊接口的復(fù)雜程度

6、設(shè)計單入口單出口的模塊

7、模塊功能應(yīng)該可以預(yù)測

（4）：面向數(shù)據(jù)流的設(shè)計方法把信息流映射成軟件結(jié)構(gòu)，信息流的類型決定了映射的方法，信息流有變換流和事務(wù)流兩種類型。

（1）：程序設(shè)計語言的標(biāo)準(zhǔn)

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

2、可以使用的編譯程序

3、可以得到的軟件工具

4、工程規(guī)模

5、程序員的知識

6、軟件可移植性要求

7、軟件的應(yīng)用領(lǐng)域（2）：編碼遵循的規(guī)則

1、程序內(nèi)部的文檔

2、數(shù)據(jù)說明

3、語句構(gòu)造

4、輸入輸出

5、效率

（3）：軟件測試的準(zhǔn)則

1、所有測試都應(yīng)該能追溯到用戶需求。

2、應(yīng)該遠(yuǎn)在測試開始之前就制定出測試計劃。

3、把Pareto原理應(yīng)用到軟件測試中。

4、應(yīng)該從”小規(guī)?！皽y試開始，并逐步進行”大規(guī)?！皽y試。

5、窮舉測試是不可能的。

6、為了達(dá)到最佳的測試效果，應(yīng)該由獨立的

第二篇：軟件工程考點總結(jié)

第一章

1.軟件是程序和所使程序正確運行所需的相關(guān)文檔和配置信息.軟件工程是一門工程學(xué)科，涉及軟件生產(chǎn)的各個方面.軟件過程是指制作軟件產(chǎn)品的一組活動及其結(jié)果。

2.軟件過程的4項基本活動有:軟件描述：客戶和工程師定義所要生產(chǎn)的軟件以及對其操作的一些約束軟件開發(fā)軟件得以設(shè)計和編程實現(xiàn)軟件有效性驗證軟件經(jīng)過檢查以保證它就是客戶所需要的軟件進化軟件隨不同的客戶和變化的市場需求而修改.3.軟件工程人員的工作不僅僅是技術(shù)的應(yīng)用，還要承擔(dān)很多責(zé)任.保密：工程人員必須嚴(yán)格保守雇主或客戶的機密，而不管是否簽署了保密協(xié)議.工作能力 工程人員應(yīng)實事求是地表述自己的工作能力，不應(yīng)有意接受超出了自己能力的工作.知識產(chǎn)權(quán)工程人員應(yīng)當(dāng)知曉控制專利權(quán)、著作權(quán)等知識產(chǎn)權(quán)使用的地方法律，必須謹(jǐn)慎行事，確保雇主和客戶的知識產(chǎn)權(quán)受到保護.計算機濫用 軟件工程人員不應(yīng)該用自己的技能濫用他人的計算機，濫用計算機有時對他人影響不大（如在雇主的計算機上玩游戲），但有時后果非常嚴(yán)重（傳播病毒）.第二章

1軟件工程模型瀑布模型軟件描述和開發(fā)，分成獨立和不同的階段.增量式開發(fā)描述、開發(fā)和有效性驗證交錯進行.面向復(fù)用的軟件工程基于已存在的很多可復(fù)用的組件.2.瀑布模型：1需求分析和定義，通過咨詢系統(tǒng)用戶建立系統(tǒng)的服務(wù)、約束和目標(biāo)。2系統(tǒng)和軟件設(shè)計系統(tǒng)設(shè)計過程通過建立系統(tǒng)的總體體系結(jié)構(gòu)將需求分為硬件需求和軟件需求。3實現(xiàn)和單元測試將軟件設(shè)計實現(xiàn)為一組程序或程序單元，單元測試是檢驗每個單元是否符合其描述。4集成和系統(tǒng)測試集成單個的程序單元或一組程序，并對系統(tǒng)整體進行測試以確保其滿足了軟件需求。5運行和維護

3瀑布模型的問題1將項目分成不同階段，難以應(yīng)付不斷變化的客戶需求.2當(dāng)需求十分明確，軟件開發(fā)中只做有限修改時才適合使用該模型.3很少有業(yè)務(wù)系統(tǒng)有穩(wěn)定的需求。瀑布模型主要是用于大型系統(tǒng)工程項目，且軟件項目是大型工程項目的一部分時尤為適用.4增量式開發(fā)優(yōu)點：

1、降低了適應(yīng)用戶需求變更的成本

2、容易得到用戶及時的反饋

3、為及時交付用于的系統(tǒng)提供了可能問題1過程不可見;2系統(tǒng)結(jié)構(gòu)通常較差;3需要專業(yè)技能(如快速原型語言等).5過程活動包括：軟件描述、軟件設(shè)計和實現(xiàn)、軟件有效性驗證及軟件進化.6軟件描述（需求工程）軟件描述或需求工程主要是理解并定義系統(tǒng)需要哪些服務(wù)以及找出開發(fā)和運行期間受到哪些約束.可行性研究：指明現(xiàn)有的軟件硬件及能否實現(xiàn)用戶對新系統(tǒng)的要求需求導(dǎo)出和分析：通過對現(xiàn)有系統(tǒng)分析、與潛在用戶和購買者討論、進行任務(wù)分析等導(dǎo)出系統(tǒng)需求的過程需求描述：把在分析活動中收集的信息以文檔的形式確定下來。需求有效性驗證：檢查需求的現(xiàn)實性、一致性和完備性。

7軟件設(shè)計和實現(xiàn)把系統(tǒng)描述轉(zhuǎn)化為一個可運行的系統(tǒng)的過程。軟件設(shè)計，實現(xiàn)軟件的結(jié)構(gòu)、系統(tǒng)的數(shù)據(jù)等描述。實現(xiàn)，把軟件結(jié)構(gòu)轉(zhuǎn)化為可執(zhí)行的程序。體系結(jié)構(gòu)設(shè)計識別系統(tǒng)總體結(jié)構(gòu)、基本組件、它們之間的關(guān)系以及它們是怎樣分布。接口設(shè)計定義系統(tǒng)結(jié)構(gòu)的借口組件設(shè)計針對每個系統(tǒng)組件設(shè)計它的運行方式數(shù)據(jù)庫設(shè)計設(shè)計系統(tǒng)數(shù)據(jù)結(jié)構(gòu)，以及如何在數(shù)據(jù)庫中表示這些數(shù)據(jù)結(jié)構(gòu)

8軟件有效性驗證也稱檢查和有效性驗證，是為了表明系統(tǒng)符合其描述，滿足了客戶的需求.包括檢查和審查過程，還有系統(tǒng)測試.組件或單元測試由開發(fā)系統(tǒng)的人員對組成系統(tǒng)的組件進行測試系統(tǒng)測試集成組件形成完整的系統(tǒng)。并測試是否滿足需求。接收測試系統(tǒng)在接受并運行之前的最后階段測試

9軟件進化軟件本質(zhì)是靈活的，可以改變的.由于業(yè)務(wù)環(huán)境的不斷變化，客戶需求也隨之發(fā)生變化，該軟件支持的業(yè)務(wù)也必須不斷更新和修改.10.Rational統(tǒng)一過程來自于UML上的工作和相關(guān)的軟件開發(fā)過程.開端建立一個業(yè)務(wù)案例細(xì)化增進對問題域的理解，建立系統(tǒng)的體系框架，給出項目計劃、風(fēng)險構(gòu)造系統(tǒng)設(shè)計、編程和測試轉(zhuǎn)換在其操作環(huán)境部署這一系統(tǒng).過程工作流：業(yè)務(wù)建模；需求；分析和設(shè)計；實現(xiàn)；測試；部署；支持工作流：配置和變更管理；項目管理；環(huán)境RUP 好的實踐：反復(fù)地開發(fā)軟件；對管理需求；使用基于組件的體系結(jié)構(gòu)；可視化模型軟件；驗證軟件質(zhì)量；控制對軟件的變更

第三章

1.XP和敏捷方法的原則1增量式開發(fā)是通過系統(tǒng)的小的頻繁開發(fā)的版本來支持的；2客戶的參與是通過全時雇傭到開發(fā)團隊的方式；3人（而不是過程）是通過結(jié)對編程、集體對系統(tǒng)代碼的所有權(quán)、可以忍受的開發(fā)過程而無需超額的工作小時來運作的；4變更是通過經(jīng)常性的系統(tǒng)版本來支持的；5通過持續(xù)的再分解來維護系統(tǒng)的簡潔性。

2問題：1很難將興趣保持在參與到開發(fā)的客戶身上。2團隊成員個人可能從性格上不太適應(yīng)激烈的投入，這是敏捷方法的典型特征。3對變更做出優(yōu)先級排序可能是極困難的，尤其是對那些有很多參與者的系統(tǒng)。4維護簡潔性需要額外的工作。5許多機構(gòu)很難向另一種工作模型轉(zhuǎn)換。6隨著其他迭代方法的發(fā)展，合同可能也是極限方法的一個問題。優(yōu)點1極限編程將增量式開發(fā)推向極致。2極限編程將軟件進行再分解（refactoring），使得當(dāng)新情節(jié)實現(xiàn)的時候軟件總是容易理解和改變的。3.在創(chuàng)建程序特征之前開發(fā)自動測試。

3結(jié)對編程優(yōu)點：1它支持共同擁有軟件和共同對系統(tǒng)負(fù)責(zé)2它擔(dān)當(dāng)了非正式的復(fù)查過程3有助于支持重構(gòu)

第四章

1需求工程過程包括可行性研究、需求導(dǎo)出和分析、需求描述、需求有效性驗證及需求管理。2功能需求對系統(tǒng)應(yīng)該提供的服務(wù)、如何對輸入做出反應(yīng)以及系統(tǒng)在特定條件下的行為的描述。非功能需求對系統(tǒng)提供的服務(wù)或功能給出的約束。時間約束、開發(fā)過程的約束、標(biāo)準(zhǔn)等。3功能需求描述系統(tǒng)所預(yù)期提供的功能或服務(wù)。取決于開發(fā)的軟件類型、軟件未來的用戶以及開發(fā)的系統(tǒng)類型。理論上，系統(tǒng)的功能需求應(yīng)該既全面又具有一致性。全面用戶所需的所有服務(wù)都應(yīng)該給出描述；一致性在對系統(tǒng)功能需求進行描述時，不能前后矛盾。在實際過程中，對大型而又復(fù)雜的系統(tǒng)而言，要做到需求描述既全面又一致幾乎是不可能的。

4非功能需求它們定義系統(tǒng)的屬性和約束。非功能性需求比功能性需求更關(guān)鍵。產(chǎn)品需求這些需求定義或約束軟件的行為。機構(gòu)需求很廣泛的系統(tǒng)需求，起源于客戶所在的機構(gòu)和開發(fā)者所在的機構(gòu)中的政策和規(guī)定。外部需求包括所有來自于系統(tǒng)外部因素和開發(fā)過程的需求。非功能性需求可能是很難精確描述的，并且不精確的需求可能也難以得到檢驗。系統(tǒng)目標(biāo)用戶的一般的要求，比如系統(tǒng)的易用性?？蓹z驗的非功能需求應(yīng)用某些度量進行描述，它們可以客觀的得到驗證。

5需求導(dǎo)出和分析（4個活動）：1需求發(fā)現(xiàn)這是一個與系統(tǒng)的信息持有者交流從而收集他們的需求的過程。來自信息持有者和文檔的領(lǐng)域需求是在這個活動中得以發(fā)現(xiàn)的。2需求分類與組織所收集的需求是無序的，需要對其重新組織和整理，將其分為相關(guān)的幾個組。3需求優(yōu)先排序和協(xié)商對需求進行優(yōu)先權(quán)排序，并通過協(xié)商發(fā)現(xiàn)且解決這些沖突。4需求描述記錄需求并將它作為螺旋下一個循環(huán)的輸入，產(chǎn)生形式化和非形式化的需求文檔。系統(tǒng)需求導(dǎo)出和分析是困難的：1信息持有者表述泛泛2需求工程師沒有領(lǐng)域知識3不同的信息持有者需求不同4政治上的因素影響系統(tǒng)需求5經(jīng)濟和業(yè)務(wù)環(huán)境是動態(tài)的6需求發(fā)現(xiàn)是一個收集準(zhǔn)備建立的系統(tǒng)和正在使用的系統(tǒng)的信息，并從這些信息當(dāng)中提取用戶和系統(tǒng)需求的過程。信息源包括已有文件、系統(tǒng)信息持有者以及類似系統(tǒng)的相關(guān)內(nèi)容。7腳本（場景）是對交互實例片段的描述。一個場景可能包擴以下內(nèi)容：1在場景的開始部分有一個系統(tǒng)狀態(tài)描述；2一個關(guān)于標(biāo)準(zhǔn)事件流的描述；3一個關(guān)于哪兒會出錯以及如何處

理錯誤的描述；4有關(guān)其他可能在同一時間進行的活動的信息；5在場景完成后系統(tǒng)狀態(tài)的描述。

第五章

活動圖，表示一個過程或數(shù)據(jù)處理中所涉及的活動用例圖，表示一個系統(tǒng)和它所處的環(huán)境之間的交互。時序圖，表示參與者系統(tǒng)之間以及系統(tǒng)各部分之間的交互類圖，表示系統(tǒng)中對象類以及這些類之間的聯(lián)系狀態(tài)圖，表示系統(tǒng)是如何響應(yīng)內(nèi)外部事件的。

第六章

1明確設(shè)計和文檔化軟件體系結(jié)構(gòu)好處：1信息持有者之間的溝通體系結(jié)構(gòu)可以作為不同的項目相關(guān)人員之間討論的焦點2系統(tǒng)分析系統(tǒng)分析對體系結(jié)構(gòu)的設(shè)計決策，對系統(tǒng)能否滿足非功能需求具有很大的影響3大規(guī)模復(fù)用體系結(jié)構(gòu)能在相似需求的系統(tǒng)之間互用，以支持大規(guī)模的軟件復(fù)用。

2分層體系結(jié)構(gòu)分層模型用來把系統(tǒng)組織成一系列的層次，每一層提供一組服務(wù)。

3容器體系結(jié)構(gòu)系統(tǒng)所有數(shù)據(jù)在一個中央容器中管理，該容器可被所有系統(tǒng)組件訪問組件通過容器交互。優(yōu)點它是共享大量數(shù)據(jù)的一個高效方法；子系統(tǒng)不必關(guān)心數(shù)據(jù)是如何集中進行的這些活動；共享模型能通過容器模式而看得見。缺點子系統(tǒng)一定要與容器數(shù)據(jù)模型一致，不可避免地，每個專用的工具之間要做出妥協(xié)；數(shù)據(jù)進化變得很困難和昂貴；容器模型迫使所有的子系統(tǒng)使用相同的策略；很難將容器有效的分配到多臺機器上。4客戶機/服務(wù)器體系結(jié):優(yōu)點數(shù)據(jù)的分布式最直接的;可以更有效地使用網(wǎng)絡(luò)系統(tǒng)，從而降低了對硬件的要求；很容易就添加一臺新的服務(wù)器或更新現(xiàn)有的服務(wù)器。缺點沒有共享數(shù)據(jù)模型，子系統(tǒng)以不同的方式組織它們的數(shù)據(jù)。數(shù)據(jù)交換效率就可能很低；每個服務(wù)器上出現(xiàn)冗余數(shù)據(jù)管理；沒有中央寄存器的名字和服務(wù)，這可能很難找出哪個服務(wù)器和哪些服務(wù)可用。5管道和過濾體系結(jié)優(yōu)點：易于理解并支持變換的復(fù)用。缺點：通信變換間所傳輸?shù)臄?shù)據(jù)格式必須協(xié)商好。

第七章

1復(fù)用 1抽象層:不直接復(fù)用，運用軟件設(shè)計中的成功抽象。2對象層：直接復(fù)用庫中對象，代替自己編寫代碼3組件層：通常需要添加自己的代碼對組件進行調(diào)成和擴展 4系統(tǒng)層：復(fù)用整個系統(tǒng)

2配置管理管理變更中軟件系統(tǒng)的一般過程1版本管理對軟件不同版本的追蹤提供支持2系統(tǒng)集成提供支持幫助開發(fā)人員定義在創(chuàng)建每個系統(tǒng)版本時所用的組件版本 3問題追蹤提供支持允許用戶報告缺陷及其他問題，并允許開發(fā)人員誰在修復(fù)這些問題，以及何時完成修復(fù)。

第八章

1檢驗: “我們是否在正確地構(gòu)造一個產(chǎn)品”。軟件應(yīng)該符合設(shè)計規(guī)格。有效性驗證: "我們是否在構(gòu)造一個正確的產(chǎn)品”。軟件應(yīng)該滿足用戶所需要的。

2商業(yè)軟件測試3階段：1開發(fā)測試2發(fā)布測試3用戶測試

3開發(fā)測試：1.單元測試，對單獨的程序單元活對象類進行測試（功能）。2組件測試，多個程序單元整合創(chuàng)建一個合成的組件（接口）3系統(tǒng)測試，一些或所有組件作為整體（交互）。4選擇單元測試案例：1劃分測試，識別具有共同特征和以同樣方法處理的一組數(shù)據(jù)。2基于準(zhǔn)則測試，使用測試準(zhǔn)則來選擇測試案例。

5準(zhǔn)則：用一個只有單個值的序列來測試軟件；在不同的測試中使用不同規(guī)模的多個序列；導(dǎo)出一個測試，讓序列的第一個、中間一個和最后一個元素得到測試；測試序列的長度為零。原則：選擇能強制系統(tǒng)生成的所有錯誤信息輸入；設(shè)計能夠使系統(tǒng)的輸入緩沖溢出的輸入；重復(fù)相同的輸入或一系列輸入很多次；使產(chǎn)生無效的輸出；迫使輸出結(jié)果太大或者太小。6組件測試：1參數(shù)接口數(shù)據(jù)從一個過程傳到另外一個過程2共享內(nèi)存接口內(nèi)存塊為過程或函數(shù)所共享3程序接口子系統(tǒng)封裝一組程序，這些程序為其他子系統(tǒng)調(diào)用4消息傳遞接口子

系統(tǒng)通過傳遞消息請求其他子系統(tǒng)上的服務(wù)。接口錯誤3類：接口誤用調(diào)用者組件在調(diào)用其他組件時因接口使用不當(dāng)而發(fā)生接口錯誤。接口誤解調(diào)用者組件誤解了被調(diào)用組件的接口描述而產(chǎn)生錯誤，對唄調(diào)用組件進行了錯誤的假設(shè)。時序錯誤調(diào)用和被調(diào)用組件以不同的速度運行，中間過時的數(shù)據(jù)無法得到正確的處理.7用戶測試：α測試：軟件用戶和開發(fā)小組一起在開發(fā)小組一起在開發(fā)者的地點測試這個軟件。β測試：該軟件的版本是提供給用戶讓他們進行測驗，并向開發(fā)者提供發(fā)現(xiàn)的文題。接受測試：客戶測試系統(tǒng)決定他們是否愿意從系統(tǒng)開發(fā)者哪里接收系統(tǒng)并在客戶環(huán)境中部署。接收測試六個階段：1.定義接受準(zhǔn)則（合同）2.計劃接受測試 3導(dǎo)出接收測試 4.運行接受、測試 5協(xié)商測試結(jié)果 6 拒絕/接收系統(tǒng)

第九章

1軟件進化：變更請示、影響分析、版本規(guī)劃（缺陷修補、平臺適應(yīng)、系統(tǒng)增強）、變更實現(xiàn)、系統(tǒng)發(fā)布。變更實現(xiàn)：提議的變更、需求分析、需求更新、軟件開發(fā)緊急修補過程：變更請求、分析源代碼、修改源代碼、移交修改的系統(tǒng)。

2軟件維護：

1、修補軟件缺陷（糾正性）

2、是軟件適應(yīng)不同操作系統(tǒng)（適應(yīng)性）

3、增加或修改系統(tǒng)功能（完善性）

3投入后代價增加原因：1團隊穩(wěn)定性2糟糕的開發(fā)實踐3人員技術(shù)水平4程序年齡和結(jié)構(gòu)。

第25章

1配置管理包括：變更管理：包括跟蹤來自客戶和開發(fā)者的軟件變更請求，計算做出這些變更的花費并估計其影響，決定是否變更，何時完成變更。版本管理：包括跟蹤系統(tǒng)組件的多個版本，確保由不同開發(fā)者對組件做出的變更不會彼此干涉。系統(tǒng)構(gòu)建：是一個組裝程序組件，數(shù)據(jù)和庫的過程，然后把這些組件編譯連接成一個可以執(zhí)行的系統(tǒng)。發(fā)布管理：包括準(zhǔn)備對完發(fā)布的軟件，持續(xù)跟蹤已經(jīng)發(fā)布以供客戶使用的系統(tǒng)版本。

2配置項（軟件配置項）：與配置管理控制下的軟件項目有關(guān)的任何事物。配置項會存在多個不同的版本，每個配置項都有一個唯一的名字。

3變更管理確保系統(tǒng)的進展是一個可管理的過程。主要關(guān)心的是對提建議的變更的成本收益分析，保證變更值得做，并記錄系統(tǒng)的哪些組件已經(jīng)改變。變更請求考慮的因素：不做變更會引起的后果，變更的益處，變更影響的用戶數(shù)，變更所需花費，產(chǎn)品發(fā)布循環(huán)。

4版本管理是跟蹤軟件組件或配置信息以及使用這些組件系統(tǒng)的不同版本的過程。版本管理系統(tǒng)通常提供一系列特征：版本和發(fā)布版本識別被管理版本提交給系統(tǒng)時給他們分配標(biāo)識符存儲管理為了減少存儲空間，版本管理系統(tǒng)會提供存儲管理工具變更歷史記錄記錄并列出所有對系統(tǒng)或組件作出的變更獨立開發(fā)確保由不同的開發(fā)者對組件做出的變更互不影響項目支持一個版本管理系統(tǒng)可能支持共享組件的幾個項目的開發(fā)。

第三篇：軟件工程總結(jié)

軟件工程課程總結(jié)

摘要：

計算機是20世紀(jì)最重大的科學(xué)技巧成就之一，使當(dāng)代社會的經(jīng)濟、軍事、科研、教育、服務(wù)等方面在概念和技巧上發(fā)生了性的變化，對人類社會的進步已經(jīng)并還將產(chǎn)生極為深刻的影響。目前，計算機是世界各發(fā)達(dá)國度劇烈競爭的科學(xué)技巧領(lǐng)域之一。

電子計算機早期功效主要是計算，后來已遠(yuǎn)遠(yuǎn)超越單純計算的功效，還可模擬、思維、進行自適應(yīng)反饋處理等等，把它叫做“電腦”更為合實際。由于電子計算機功效的飛躍性發(fā)展，應(yīng)用于生產(chǎn)和生活的各個方面，直接和顯著地提高了生產(chǎn)、工作和生活的效率、節(jié)奏和水平，在軟科學(xué)研究和應(yīng)用中它也起著關(guān)鍵作用，因此它已被公認(rèn)是現(xiàn)代技巧的神經(jīng)中樞，是未來信息社會的心臟和錄魂。計算機學(xué)科分為四個領(lǐng)域，分別是計算機科學(xué)，計算機工程，軟件工程和信息系統(tǒng)。

正文：

軟件工程是研究和應(yīng)用如何以系統(tǒng)性的、規(guī)范化的、可定量的過程化方法去開發(fā)和維護軟件，以及如何把經(jīng)過時間考驗而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來的學(xué)科。包括項目管理，分析，設(shè)計，程序的編寫，測試和質(zhì)量控制。它涉及到程序設(shè)計語言、數(shù)據(jù)庫、軟件開發(fā)工具、系統(tǒng)開發(fā)平臺、標(biāo)準(zhǔn)、設(shè)計模式等方面。

學(xué)了《軟件工程》這門課程和一些有關(guān)資料后，感覺一些東西都曾經(jīng)接觸過，但在實際工作中有些理論要完全遵循可能還有些障礙，軟件工程只是提供了理論上的一些結(jié)論，但對項目的具體可操作性的規(guī)范的制定方面卻做的很少，《軟件工程》發(fā)展了幾十年，光是開發(fā)模型就達(dá)到了10多種，對不同的項目采用合適的開發(fā)模式，有些項目在不同的開發(fā)階段可能還要轉(zhuǎn)換開發(fā)模式，把它們靈活的應(yīng)用到實際中還是很困難的。

軟件技術(shù)是信息技術(shù)產(chǎn)業(yè)的核心之一，軟件技術(shù)的發(fā)展是與信息技術(shù)產(chǎn)業(yè)的發(fā)展互相促進的。當(dāng)今世界，信息技術(shù)正處于新一輪重大技術(shù)突破的前夜。預(yù)計今后 20~30 年是信息科學(xué)技術(shù)的變革突破期，可能導(dǎo)致 21 世紀(jì)下半葉一場新的信息技術(shù)革命。近年來，從 IT 界到一些國家首腦，都高度關(guān)注以物聯(lián)網(wǎng)為標(biāo)志的新一輪信息技術(shù)的發(fā)展態(tài)勢，認(rèn)為這是繼 20 世紀(jì) 80 年代 PC 機、90 年代互聯(lián)網(wǎng)、移動通信網(wǎng)之后，將引發(fā) IT 業(yè)突破性發(fā)展的第三次 IT 產(chǎn)業(yè)化浪潮。每一次重大的技術(shù)變革都會引起企業(yè)間、產(chǎn)業(yè)間甚至國家間競爭格局的重大變化，也促進了軟件技術(shù)與軟件產(chǎn)業(yè)的重大變革與發(fā)展。

近年來，信息技術(shù)、軟件技術(shù)、軟件系統(tǒng)與軟件產(chǎn)業(yè)的發(fā)展備受關(guān)注，已有不少論述、分析與判斷。近10 年內(nèi)網(wǎng)絡(luò)技術(shù)經(jīng)歷寬帶化、移動化和三網(wǎng)融合將走向基于 Ipv6 的下一代互聯(lián)網(wǎng)，2010 年 1 月，國家 863 計劃信息技術(shù)領(lǐng)域辦公室和國家 863 計劃信息技術(shù)領(lǐng)域?qū)＜医M，在上海舉辦“信息-物理融合系統(tǒng) CPS發(fā)展戰(zhàn)略論壇”，提出“信息-物理融合系統(tǒng) CPS 是一個綜合計算、網(wǎng)絡(luò)和物理環(huán)境的多維復(fù)雜系統(tǒng)，是信息和物理世界的深度的融合交互，可實現(xiàn)大型工程系統(tǒng)的實時感知、動態(tài)控制和信息服務(wù)，使系統(tǒng)更加可靠、高效與實時協(xié)同，使得人類物理現(xiàn)實和虛擬邏輯逐步融合，具有重要而廣泛的應(yīng)用前景。業(yè)界關(guān)于軟件工程的代表性觀點創(chuàng)立與使用健全的工程原則，以便經(jīng)濟地獲得可靠且高效率的軟件。應(yīng)用系統(tǒng)化，遵從原則，可被計量的方法來發(fā)展、操作及維護軟件；也就是把工程應(yīng)用到軟件上。與開發(fā)、管理及更新軟件產(chǎn)品有關(guān)的理論、方法及工具。一種知識或?qū)W科，目標(biāo)是生產(chǎn)品質(zhì)良好、準(zhǔn)時交貨、符合預(yù)算，滿足用戶所需的軟件。實際應(yīng)用科學(xué)知識在設(shè)計、建構(gòu)電腦程序，與相伴而來所產(chǎn)生的文件，以及后續(xù)的操作和維護上。

6使用與系統(tǒng)化生產(chǎn)和維護軟件產(chǎn)品有關(guān)之技術(shù)與管理的知識，使軟件開發(fā)與修改可在有限的時間與費用下進行。

7建造由工程師團隊所開發(fā)之大型軟件系統(tǒng)有關(guān)的知識學(xué)科。對軟件分析、設(shè)計、實施及維護的一種系統(tǒng)化方法。系統(tǒng)化地應(yīng)用工具和技術(shù)于開發(fā)以計算機為主的應(yīng)用。

10軟件工程是關(guān)于設(shè)計和開發(fā)優(yōu)質(zhì)軟件。

《軟件工程》是一門綜合性和實踐性很強的核心課程，它屬于是一門交叉學(xué)科，包含有：軟件開發(fā)技術(shù)（軟件開發(fā)方法學(xué)、軟件開發(fā)過程、軟件工具和軟件工程環(huán)境）、軟件工程管理（軟件管理學(xué)、軟件經(jīng)濟學(xué)、軟件心理學(xué)）。主要內(nèi)容包括軟件工程概述、可行性分析、需求分析、概要設(shè)計、詳細(xì)設(shè)計、面向?qū)ο蠓治雠c設(shè)計、編碼、軟件測試、項目計劃與管理。

本課程是面向準(zhǔn)備從事軟件開發(fā)的畢業(yè)生而開設(shè)的一門專業(yè)課程。針對計算機教學(xué)中軟件工程這一薄弱環(huán)結(jié)，結(jié)合目前軟件開發(fā)商對人才的要求，對計算機專業(yè)的畢業(yè)生進行軟件工程強化培訓(xùn)，目的是使畢業(yè)生能夠了解和掌握軟件工程的基本理論和方法，并在實際軟件開發(fā)中運用這些方法。

我理解，軟件工程是按照工程學(xué)的管理方式，有組織、有計劃的，在一定的質(zhì)量基礎(chǔ)、時間限度和成本范圍內(nèi)，實現(xiàn)功能明確的軟件系統(tǒng)。而且，軟件工程在企業(yè)范圍內(nèi)運行，一定需要企業(yè)資源的支持，要與企業(yè)的經(jīng)營、決策、管理體系聯(lián)系在一起，才能夠被踏踏實實的落實下來。

軟件工程項目是一個需要一步一步的計算，分析思考而來的，需要不斷思考，研究不斷進步，軟件業(yè)作為一個服務(wù)業(yè)，要想得到發(fā)展，首先必須形成一個對軟件服務(wù)有迫切需要的市場。其次，這個市場中的消費者必須具備足夠的購買力。軟件的消費群體簡單一點，可以分為個體消費和企業(yè)消費。中國的企業(yè)群體，數(shù)量龐大，但是質(zhì)量不高。上規(guī)模的企業(yè)極少。國內(nèi)目前能夠形成比較大規(guī)模的獨立市場的，肯定是小規(guī)模的軟件系統(tǒng)。

隨著信息化時代的到來其地位越來越受到人們的重視，軟件工程從一個學(xué)科，或是某一個研究方向來說，人員僅僅是過程，方法的執(zhí)行者，所以人員素質(zhì)往往被忽略，軟件工程是一門實踐性很強的學(xué)科，所以在實際的軟件研究過程中，人員的素質(zhì)占有很重要的地位。要有出色的軟件問世，研發(fā)人員的素質(zhì)至關(guān)重要！

作為軟件工程的學(xué)習(xí)者應(yīng)該不斷創(chuàng)新，不斷嘗試、實踐，不斷研究和學(xué)習(xí)，中國的軟件工程技術(shù)依舊滯后于國外一些軟件工程技術(shù)，作為新一代的學(xué)習(xí)者應(yīng)該擔(dān)當(dāng)起振興起中國軟件事業(yè)，使中國科技得到高速發(fā)展！

現(xiàn)在已經(jīng)是信息化時代，信息化潮流不斷涌現(xiàn)，想要掌握主動權(quán)就是掌握信息化的發(fā)展方向，這就需要我們不斷學(xué)習(xí)，時間，研究，學(xué)習(xí)國外的先進技術(shù)，轉(zhuǎn)變自己的技術(shù)，然后融合，創(chuàng)新。

軟件技術(shù)不是一成不變的，是隨著社會的進步的不斷進步，不需要不斷的創(chuàng)新，不斷的改善的，需要我們不斷的學(xué)習(xí)，不斷的研究，不斷進步。

第四篇：軟件工程總結(jié)

1.Software is a product and can be manufactured using the same technologies used for other engineering artifacts Answer: b 2.WebApps are a mixture of print publishing and software development, making their development outside the realm of software engineering practice.Answer: b 3.Software engineering umbrella activities are only applied during the initial phases of software development projects.Answer: b 4.Planning ahead for software reuse reduces the cost and increases the value of the systems into which they are incorporated.Answer: a 5.The essence of software engineering practice might be described as understand the problem, plan a solution, carry out the plan, and examine the result for accuracy.Answer: a 6.In agile process models the only deliverable work product is the working program.Answer: b 7.A most software development projects are initiated to try to meet some business need.Answer: a 8.In general software only succeeds if its behavior is consistent with the objectives of its designers.Answer: b 9.Software processes can be constructed out of pre-existing software patterns to best meet the needs of a software project.Answer: a 10.Process technology tools allow software organizations to compress schedules by skipping unimportant activities.Answer: b 11.It is generally accepted that one cannot have weak software processes and create high quality end products.Answer: a 1.Requirements engineering is a generic process that does not vary from one software project to another.Answer: a 2.A stakeholder is anyone who will purchase the completed software system under development.Answer: b 3.It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.Answer: a 4.Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.Answer: a 5.Use-case actors are always people, never system devices.Answer: b 6.Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.Answer: a 7.In win-win negotiation, the customer’s needs are met even though the developer’s need may not be.Answer: b 8.In requirements validation the requirements model is reviewed to ensure its technical feasibility.Answer: b

1.Object-oriented domain analysis is concerned with the identification and specification of reusable capabilities within an application domain.Answer: a 2.In structured analysis models focus on the structure of the classes defined for a system along with their interactions.Answer: b 3.Creation and refinement of use cases if an important part of scenario-based modeling.Answer: a 4.It is important to consider alternative actor interactions when creating a preliminary use case.Answer: b 5.Brainstorming is one technique that may be used to derive a complete set of use case exceptions.Answer: a 6.In many cases there is no need to create a graphical representation of a usage scenario.Answer: a 7.One or more attributes of a data object must be defined as a key to allow the location of an instance of the data object.Answer: a 8.Attributes are chosen for an object by examining the problem statement and identifying the entities that appear to be related.Answer: b 9.An analysis package involves the categorization of analysis model elements into useful groupings.Answer: a 10.The data flow diagram must be augmented by min-spec that can serve as a guide the design of the software component that will implement the process.Answer: a 11.The UML sequence diagram show the order in which system events are processed.Answer: b 12.Analysis patterns are discovered, they are not explicitly created.Answer: a 13.It is not possible to justify the time required for WebApp requirements analysis.Answer: b 14.UML activity diagrams can be used to represent the user observable functionality delivered by the WebApp as well as the operations contained in each analysis class.Answer: a 15.Configuration analysis focuses on the architecture of the user’s web browsing environment.Answer: b 16.Content objects are extracted from use cases by examining the scenario description for direct or indirect content references.Answer: a 1.With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.Answer: b 2.Program flow graphs are identical to program flowcharts.Answer: b 3.The cyclomatic complexity of a program can be computed directly from a PDL representation of an algorithm without drawing a program flow graph.Answer: a 4.Graph-based testing methods can only be used for object-oriented systems Answer: b 5.Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.Answer: a 6.Boundary value analysis can only be used to do white-box testing.Answer: b 7.Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.Answer: a 8.Client/server architectures cannot be properly tested because network load is highly variable.Answer: b 1.The best representation of system architecture is an operational software prototype.Answer: b 2.The architectural representations can be an enabler for communication among project stakeholders.Answer: a 3.An architectural description is often documented using an architecture template.Answer: b 4.An architectural genre will often dictate the architectural approach that may used for the structure to be built.Answer: a 5.Before an architectural pattern can be chosen for use in a specific system it must have a code implementation to facilitate its reuse.Answer: b 6.Once selected, archetypes always need to be refined further as architectural design proceeds.Answer: a 7.Quantitative methods for assessing the quality of proposed architectural designs are readily available.Answer: b

Chapter 10 Self-Check Quiz

1.In the most general sense a component is a modular building block for computer software.a.True b.False

Answer: a(Section 10.1)

2.In the context of object-oriented software engineering a component contains

a.attributes and operations b.instances of each class c.roles for each actor(device or user)d.set of collaborating classes

Answer: d(Section 10.1.1)

3.In traditional software engineering modules must serve in which of the following roles?

a.Control component b.Infrastructure component c.Problem domain component d.All of the above

Answer: d(Section 10.1.2)

4.Software engineers always need to cerate components from scratch in order to meet customer expectations fully.a.True b.False

Answer: b(Section 10.1.3)

5.Which of the following is not one of the four principles used to guide component-level design?

a.Dependency Inversion Principle b.Interface Segregation Principle c.Open-Closed Principle d.Parsimonious Complexity Principle

Answer: d(Section 10.2.1)

6.The use of stereotypes can help identify the nature of components at the detailed design level.a.True b.False

Answer: a(Section 10.2.2)

7.Classes and components that exhibit functional, layer, or communicational cohesion are relatively easy to implement, test, and maintain.a.True b.False

Answer: a(Section 10.2.3)

8.Software coupling is a sign of poor architectural design and can always be avoided in every system.a.True b.False

Answer: b(Section 10.2.4)

9.WebApp content design at the component level focuses on content objects and the manner in which they interact.a.True b.False

Answer: b(Section 10.4.1)

10.A WebApp functional architecture describes the key functional components and how they interact with each other.a.True b.False

Answer: a(Section 10.4.2)

11.Which of these is a graphical notation for depicting procedural detail?

a.box diagram b.decision table c.ER diagram d.flowchart

Answer: d(Section 10.5.1)

12.A decision table should be used

a.to document all conditional statements b.to guide the development of the project management plan c.only when building an expert system d.when a complex set of conditions and actions appears in a component

Answer: d(Section 10.5.2)

13.A program design language(PDL)is often a

a.combination of programming constructs and narrative text b.legitimate programming language in its own right c.machine readable software development language d.useful way to represent software architecture

Answer: a(Section 10.5.3)

14.In component-based software engineering, the development team examines the requirements to see which are amenable to composition, rather than construction, before beginning detailed design tasks.a.True b.False

Answer: a(Section 10.6)

15.Which of the following is not one of the major activities of domain engineering?

a.analysis b.construction c.dissemination d.validation

Answer: d(Section 10.6.1)

16.Which of the following factors would not be considered during component qualification?

a.application programming interface(API)b.development and integration tools required c.exception handling d.testing equipment required

Answer: d(Section 10.6.2)

17.Which is the following is a technique used for component wrapping?

a.black-box wrapping b.clear-box wrapping c.gray-box wrapping d.white-box wrapping

Answer: b(Section 10.6.2)

18.Which of the following is not one of the issues that form a basis for design for reuse?

a.object-oriented programming b.program templates c.standard data d.standard interface protocols

Answer: a(Section 10.6.3)

19.In a reuse environment, library queries are often characterized using the ________ element of the 3C Model.a.concept b.content c.context d.all of the above

Answer: c(Section 10.6.4)

1.The importance of software design can be summarized in a single word a.b.c.d.Answer: d(Section 8.1)

2.Which of the following is not a characteristic common to all design methods?

a.configuration management b.functional component representation c.quality assessment guidelines d.refinement heuristics

Answer: a(Section 8.2.2)

3.Which of the following can be used to represent the architectural design of a piece of software?

a.Dynamic models b.Functional models c.Structural models d.All of the above

Answer: d(Section 8.3.2)

4.Design patterns are not applicable to the design of object-oriented software?

a.True b.False

Answer: b(Section 8.3.3)

5.Since modularity is an important design goal it is not possible to have too many modules in a proposed design.a.True b.False

Answer: b(Section 8.3.5)

6.Information hiding makes program maintenance easier by hiding data and procedure from unaffected parts of the program.accuracy complexity efficiency quality

a.True b.False

Answer: a(Section 8.3.6)

7.Cohesion is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: b(Section 8.3.7)

8.Coupling is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: d(Section 8.3.7)

9.When using structured design methodologies the process of stepwise refinement is unnecessary.a.True b.False

Answer: b(Section 8.3.8)

10.Software designs are refactored to allow the creation of software that is easier to integrate, easier to test, and easier to maintain.a.True b.False

Answer: a(Section 8.3.10)

11.Which of the following is not one of the five design class types

a.Business domain classes b.Entity classes c.Process classes d.User interface classes

Answer: b(Section 8.3.13)

12.Which design model elements are used to depict a model of information represented from the user’s view?

a.Architectural design elements b.Component-level design elements c.Data design elements d.Interface design elements

Answer: c(Section 8.4.1)

13.Which design is equivalent to the floor plan of a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: a(Section 8.4.2)

14.Which design model is equivalent to the detailed drawings of the access points and external utilities for a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: d(Section 8.4.3)

15.Which design model is equivalent to a set of detailed drawings for each room in a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: b(Section 8.4.4)

16.The deployment design elements specify the build order for the software components.a.True b.False

Answer: b(Section 8.4.5)

第五篇：軟件工程總結(jié)

第一章軟件與軟件工程的概念

軟件的概念：軟件是計算機系統(tǒng)中與硬件相互依存的另一部分，軟件包括程序，數(shù)據(jù)，及其相關(guān)文檔的完整集合。程序是按事先設(shè)計的功能和性能要求執(zhí)行的指令序列。數(shù)據(jù)是使程序能夠正確地處理信息的數(shù)據(jù)結(jié)構(gòu)。文檔是與程序開發(fā)，維護和使用有關(guān)的圖文資料。

程序的最小單位是函數(shù)及子程序，程序與數(shù)據(jù)是分離的，在面向?qū)ο蟪绦蛟O(shè)計時代，程序的最小單位是類，在類中封裝了相關(guān)的數(shù)據(jù)及指令代碼。

軟件的特性，判斷正誤：1.軟件是無形的、不可見的邏輯實體，因此，軟件是無法描述的。（錯）

2、軟件的開發(fā)特性是指軟件需要大量手工勞動，難以自動化生產(chǎn)。（對）

3、有缺陷的軟件就是廢品。（錯）

4、軟件的生產(chǎn)指的是軟件的復(fù)制。（錯）

5、由于軟件的開發(fā)充滿人的個性特點，因此管理并不決定軟件開發(fā)的成?。ㄥe）。

6、軟件的開發(fā)環(huán)境往往就是軟件的運行環(huán)境，或者與其兼容。（對）

7、合格的軟件產(chǎn)品不需要維護，軟件需要維護說明其質(zhì)量不合格。（錯）

8、軟件可以不斷改進，因此軟件不需要廢棄。（錯）

軟件的分類：1，系統(tǒng)軟件：能與計算機硬件緊密配合在一起，使計算機系統(tǒng)各個部件，相關(guān)的軟件和數(shù)據(jù)協(xié)調(diào)，高效的工作的軟件。2，應(yīng)用軟件，是在系統(tǒng)軟件的支持下，在特定區(qū)域內(nèi)開發(fā)，為特定目的服務(wù)的一類軟件。3，支撐軟件，也叫工具軟件，是協(xié)助用戶開發(fā)軟件的工具性軟件。4，可復(fù)用軟件，最初實現(xiàn)的典型的可復(fù)用軟件是各種標(biāo)準(zhǔn)函數(shù)庫，通常是由計算機廠商提供的系統(tǒng)軟件的一部分。

IEEE給出的定義：軟件工程是開發(fā)，運行，維護和修復(fù)軟件的系統(tǒng)方法。軟件的定義：計算機程序，方法，規(guī)則，相關(guān)的文檔資料一集在計算機上運行時所必需的數(shù)據(jù)。

軟件危機的典型表現(xiàn)

1、成本太高，預(yù)算不準(zhǔn)

2、超過預(yù)計時間

3、軟件質(zhì)量標(biāo)準(zhǔn)不明確

4、生產(chǎn)率低

5、缺乏文檔資料，難以維護。原因：1，缺乏軟件開發(fā)的經(jīng)驗和有關(guān)軟件開發(fā)數(shù)據(jù)的積累，使得開發(fā)工作的計劃很難制定。2.軟件人員與用戶的交流存在障礙，除了知識背景的差異，缺少合適的交流方法及需求描述工具。3，軟件開發(fā)過程不規(guī)范，缺少方法和規(guī)范的指導(dǎo)。4，隨著軟件規(guī)模的增大，其復(fù)雜性往往會呈指數(shù)級升高。5，缺少有效的軟件評測手段，提交用戶的軟件質(zhì)量差。

軟件危機發(fā)生的主要原因有：

1、遇到了無法解決的高難度技術(shù)問題（不是）

2、無法招聘到足夠的編程高手（不是）

3、軟件人員與用戶互相不理解（是）

4、計劃和管理不科學(xué)、落實不力（是）

5、軟件質(zhì)量標(biāo)準(zhǔn)不明確（是）

軟件的質(zhì)量特性包括（選擇）問題1：

1、功能性

2、可靠性

3、使用性

4、經(jīng)濟性（不包括）

軟件的質(zhì)量特性包括（選擇）問題2：

1、效率

2、可維護性

3、可移植性

4、經(jīng)濟性（不包括）

軟件工程的目標(biāo)是運用先進的軟件開發(fā)技術(shù)和管理方法來提高軟件的質(zhì)量和生產(chǎn)率，也就是要以較短的周期，較低的成本生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，并最終實現(xiàn)軟件的工業(yè)化生產(chǎn)。軟件生存期：軟件的孕育，誕生，成長，成熟，衰亡的生存過程。軟件生存期由軟件定義，軟件開發(fā)和運行維護三個時期組成，每個時期又可劃分為若干個階段。

2、軟件定義時期的任務(wù)主要任務(wù)是解決“做什么”的問題，確定工程的總目標(biāo)和可行性；實現(xiàn)工程目標(biāo)的策略及系統(tǒng)功能；估計需要的資源和成本；制訂工程進度表。通常又分為3個階段：問題定義，可行性研究，需求分析。

3、軟件開發(fā)時期的任務(wù)和包含階段主要任務(wù)是解決“如何做”的問題，設(shè)計和實現(xiàn)定義的軟件。由概要設(shè)計、詳細(xì)設(shè)計、編碼和測試4個階段組成。

4、軟件運行維護時期的主要任務(wù)是使軟件持久地滿足用戶的需要，通常有4類維護活動：改正性維護；適應(yīng)性維護；完善性維護；預(yù)防性維護。開發(fā)過程中的典型文檔：軟件需求規(guī)格說明書。項目計劃。軟件測試計劃。軟件設(shè)計說明書。用戶手冊。軟件工程各個階段的基本任務(wù)

1、問題定義與可行性研究：解決什么問題？能否解決問題？是否值得做？”

2、需求分析：做什么

3、軟件設(shè)計：如何實現(xiàn)

4、程序編碼和單元測試：實現(xiàn)設(shè)計

5、集成和系統(tǒng)測試：組裝連接測試、功能驗證測試

6、軟件運行和維護：修改 第二章軟件工程方法與工具

軟件工具：是指能支持軟件生存周期中某一階段（如系統(tǒng)定義，需求分析，設(shè)計，編碼，測試，維護等）的需要而使用的軟件工具。

需求分析工具

1、結(jié)構(gòu)化圖形工具箱。通過數(shù)據(jù)流程圖DFD進行功能分析。包括DFD圖形工具，實體-關(guān)系圖(E-R)圖形工具，Jackson圖形工具，Warnier圖形工具，Visio綜合工具，2、面向?qū)ο蠊ぞ撸琑ational Rose，PowerDesigner，Visio 設(shè)計工具（1)概要設(shè)計工具：設(shè)計目標(biāo)軟件的體系結(jié)構(gòu)、控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)。軟件的體系結(jié)構(gòu)通常用模塊結(jié)構(gòu)圖來描述。模塊的數(shù)據(jù)結(jié)構(gòu)通常用實體-關(guān)系圖來描述。Visio。Rational Rose 詳細(xì)設(shè)計工具。設(shè)計模塊的算法和內(nèi)部實現(xiàn)細(xì)節(jié)。詳細(xì)設(shè)計描述方法有輸入-處理-輸出(IPO)圖。問題分析圖(PAD)。盒圖(NS圖)。流程圖(FC)。程序設(shè)計語言(PDL)。結(jié)構(gòu)化語言。判定表。判定樹

第三章軟件需求獲取與結(jié)構(gòu)化分析方法 需求獲取的主要任務(wù)是與用戶溝通，了解系統(tǒng)或產(chǎn)品的目標(biāo)是什么，客戶或用戶想要實現(xiàn)什么，系統(tǒng)和產(chǎn)品如何滿足業(yè)務(wù)的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作。獲取并理解用戶的需求是軟件工程師所面對的最困難的任務(wù)之一。

需求分析的困難體現(xiàn)：系統(tǒng)的目標(biāo)或范圍問題；需求不準(zhǔn)確性問題；需求的易變問題

需求獲取的任務(wù)：發(fā)現(xiàn)和分析問題，并分析問題的原因，結(jié)果關(guān)系。與用戶進行各種方式的交流，并使用調(diào)查研究方法收集信息。按照三個成分即數(shù)據(jù)，過程和接口觀察問題的不同側(cè)面。將獲取的需求文檔化，形式有用例，決策表，決策樹等。需求獲取的原則：深入淺出，以流程為主線。

獲取具體的需求的途徑1，與用戶交流。2，現(xiàn)有產(chǎn)品或競爭產(chǎn)品的描述文檔。3，系統(tǒng)需求規(guī)格說明。4，當(dāng)前系統(tǒng)的問題報告和改進要求。5，市場調(diào)查和用戶問卷調(diào)查。6，觀察用戶如何工作。

關(guān)于需求獲取問題的認(rèn)識辨析：

1、沒有與用戶交流就不可能獲取系統(tǒng)需求。（不能獲取準(zhǔn)確、全面的系統(tǒng)需求）

2、沒有經(jīng)過與用戶交流而獲取的需求都是不真實的需求。（一些需求從用戶以外的途徑獲?。?/p>

3、系統(tǒng)開發(fā)必須獨立完成，參考類似系統(tǒng)及技術(shù)文檔屬于抄襲行為，應(yīng)予避免。（系統(tǒng)開發(fā)包含研究行為，應(yīng)了解對手產(chǎn)品，取長補短）

4、系統(tǒng)開發(fā)包含改進當(dāng)前系統(tǒng)的缺陷和不足。（對）

5、需求調(diào)查時，用戶所說的需求未必是真實、準(zhǔn)確的需求，因此需求分析需要依賴用戶，但是不能過分迷信用戶。（對，需求描述是困難的）

6、觀察用戶如何工作也是一種需求調(diào)查行為。（對）

軟件需求分析階段的任務(wù)：需求獲取，需求分析，需求定義，需求驗證。完整性，正確性，合理性，可行性，充分性。

結(jié)構(gòu)化分析方法：是一種建模技術(shù)。核心是數(shù)據(jù)字典。

功能模型用數(shù)據(jù)流圖（DFD)來描述使用實體—關(guān)系圖（ER圖）建立數(shù)據(jù)模型。使用狀態(tài)轉(zhuǎn)換圖（簡稱狀態(tài)圖）建立系統(tǒng)行為模型。數(shù)據(jù)字典。加工規(guī)格說明。需求建模的依據(jù)是需求描述

數(shù)據(jù)建模，ER圖，需要認(rèn)真看。

第四章結(jié)構(gòu)化設(shè)計方法

結(jié)構(gòu)化設(shè)計方法是在模塊化，自頂向下逐步細(xì)化及結(jié)構(gòu)化程序設(shè)計技術(shù)基礎(chǔ)上發(fā)展起來的，結(jié)構(gòu)化設(shè)計方法可分為兩類：一類是根據(jù)系統(tǒng)的數(shù)據(jù)流進行設(shè)計，稱為面向數(shù)據(jù)流的設(shè)計，或稱過程驅(qū)動設(shè)計，另一類是根據(jù)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)進行設(shè)計，稱為面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計，或稱數(shù)據(jù)驅(qū)動的設(shè)計。

軟件的體系結(jié)構(gòu)設(shè)計，模塊化設(shè)計都是分而治之策略的具體表現(xiàn)。模塊化是將整體軟件劃分為獨立命名且可獨立訪問的模塊，不同的模塊通常具有不用的功能或指責(zé)，每個模塊可獨立開發(fā)，測試，最后組裝成完整的軟件。模塊是構(gòu)成軟件的基本構(gòu)件。模塊并不是越小越好，當(dāng)模塊數(shù)目增加時，每個模塊的規(guī)模將減小，開發(fā)單個模塊的成本確實減少了，但是隨著模塊數(shù)目增加，模塊之間關(guān)系的復(fù)雜程度也會增加，設(shè)計模塊間接口所需要的工作量也將增加。

模塊的獨立性是指軟件系統(tǒng)中每個模塊只涉及軟件要求的具體的子功能，而與軟件系統(tǒng)中其他模塊的接口是簡單的，若一個模塊只具有單一的功能且與其他模塊沒有太多的聯(lián)系，那么稱此模塊有獨立性。

自頂向下，逐步細(xì)化：抽象是指忽視一個主題中與當(dāng)前目標(biāo)無關(guān)的方面，以便更充分地注意與當(dāng)前目標(biāo)有關(guān)的方面，當(dāng)我們進行軟件設(shè)計時，設(shè)計開始時應(yīng)盡量提高軟件的抽象層次，按抽象級別從高到低進行軟件設(shè)計，將軟件的體系結(jié)構(gòu)按自頂向下方式，對各個層次的過程細(xì)節(jié)和數(shù)據(jù)細(xì)節(jié)逐層細(xì)化，直到用程序設(shè)計語言的語句能夠?qū)崿F(xiàn)為止，從而最后確定整個系統(tǒng)的體系結(jié)構(gòu)，這就是自頂向下逐步細(xì)化過程。

復(fù)用是指同一事物不做修改或稍加修改就可以多次重復(fù)使用，將服用的思想用于軟件開發(fā)，稱為軟件復(fù)用。1是盡量使用已有的構(gòu)件。2是如果確實需要創(chuàng)建新的構(gòu)件，則在設(shè)計時應(yīng)該考慮將來的可重復(fù)使用性。軟件設(shè)計的階段與任務(wù)：從工程管理的角度，可以將軟件設(shè)計分為概要設(shè)計階段和詳細(xì)設(shè)計階段。從技術(shù)的角度，傳統(tǒng)的結(jié)構(gòu)化方法將軟件設(shè)計劃分為體系結(jié)構(gòu)設(shè)計、數(shù)據(jù)設(shè)計、接口設(shè)計和過程設(shè)計4部分；概要設(shè)計包括體系結(jié)構(gòu)設(shè)計、數(shù)據(jù)設(shè)計、接口設(shè)計。詳細(xì)設(shè)計即過程設(shè)計，對結(jié)構(gòu)表示進行細(xì)化，得到軟件詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法。

軟件設(shè)計各項設(shè)計工作的依據(jù)：體系結(jié)構(gòu)設(shè)計，定義軟件模塊及其之間的關(guān)系，依賴于數(shù)據(jù)流圖。數(shù)據(jù)設(shè)計，依賴于ER圖。接口設(shè)計，依賴于頂層數(shù)據(jù)流圖。過程設(shè)計：依賴于加工規(guī)格說明、狀態(tài)圖

基于數(shù)據(jù)流方法的設(shè)計過程：1.復(fù)查并精化數(shù)據(jù)流圖。2.確定數(shù)據(jù)流圖中數(shù)據(jù)流的類型，典型的數(shù)據(jù)流類型有變換型數(shù)據(jù)流和事務(wù)型數(shù)據(jù)流。3.導(dǎo)出初始的軟件結(jié)構(gòu)圖。4.逐級分解。5.精化軟件結(jié)構(gòu)。6.導(dǎo)出接口描述和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。

軟件模塊結(jié)構(gòu)的改進方法：1，模塊功能的完善化。2，消除重復(fù)功能，改善軟件結(jié)構(gòu)。3，模塊的作用范圍應(yīng)在控制范圍之內(nèi)。4，盡可能減少高扇出結(jié)構(gòu)，隨著深度增大扇入。5，避免或減少使用病態(tài)連接。6，模塊的大小要適中。接口設(shè)計的依據(jù)是數(shù)據(jù)流圖中的自動化系統(tǒng)邊界。

自頂向下，逐步細(xì)化的設(shè)計過程主要包括兩個方面：一是將復(fù)雜問題的解法分析和細(xì)化成由若干個模塊組成的層次結(jié)構(gòu)，二是將每個模塊的功能逐步分解細(xì)化為一系列的處理。第五章編碼

編碼容易出現(xiàn)的風(fēng)格不足

1、變量或函數(shù)名字缺乏具體含義

2、變量或函數(shù)名字與其用途不符

3、變量或函數(shù)未加上必要的注釋

4、函數(shù)未說明其功能、參數(shù)的意義

5、引用的符號未加以解釋和說明

6、對循環(huán)等重要的程序語句未注釋

7、對用到的重要庫函數(shù)沒有解釋說明

8、對結(jié)構(gòu)體等復(fù)雜數(shù)據(jù)結(jié)構(gòu)的組成成分沒有解釋說明

9、缺乏必要的提示語句 第六章軟件測試方法

軟件測試是在軟件投入生產(chǎn)性運行之前，對軟件需求分析，設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量控制的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。