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

第一章

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

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

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

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

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

2、容易得到用戶(hù)及時(shí)的反饋

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

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

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

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

第三章

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

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

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

第四章

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

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

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

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

第五章

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

第六章

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

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

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

第七章

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

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

第八章

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

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

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

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

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

第九章

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

2軟件維護(hù)：

1、修補(bǔ)軟件缺陷（糾正性）

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

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

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

第25章

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

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

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

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

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

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

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

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

1、問(wèn)題定義

2、可行性研究

3、需求分析

4、總體設(shè)計(jì)

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

6、編碼和單元測(cè)試

7、綜合測(cè)試

8、軟件維護(hù)

（7）：幾個(gè)模型優(yōu)缺點(diǎn)

1、瀑布模型

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

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

2、快速原型模型

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

3、增量模型

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

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

4、螺旋模型

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

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

5、噴泉模型

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

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

過(guò)程：

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

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

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

4、進(jìn)一步定義問(wèn)題

5、導(dǎo)出和評(píng)價(jià)供選擇的解法

6、推薦行動(dòng)方針

7、草擬開(kāi)發(fā)計(jì)劃

8、書(shū)寫(xiě)文檔提交審查

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

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

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

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

4、、處理

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

1、代碼行技術(shù)

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

3、自動(dòng)估計(jì)成本技術(shù)

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

1、貨幣的時(shí)間價(jià)值

2、投資回收期

3、純收入

4、投資回收率

（1）：設(shè)計(jì)過(guò)程的9個(gè)步驟

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

2、選取合理的方案

3、推薦最佳的方案

4、功能分解

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

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

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

8、書(shū)寫(xiě)文檔

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

1、模塊化

2、抽象

3、逐步求精

4、信息隱藏和局部化

5、模塊獨(dú)立（3）：?jiǎn)l(fā)規(guī)則

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

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

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

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

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

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

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

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

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

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

2、可以使用的編譯程序

3、可以得到的軟件工具

4、工程規(guī)模

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

6、軟件可移植性要求

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

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

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

3、語(yǔ)句構(gòu)造

4、輸入輸出

5、效率

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

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

2、應(yīng)該遠(yuǎn)在測(cè)試開(kāi)始之前就制定出測(cè)試計(jì)劃。

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

4、應(yīng)該從”小規(guī)模“測(cè)試開(kāi)始，并逐步進(jìn)行”大規(guī)模“測(cè)試。

5、窮舉測(cè)試是不可能的。

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

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

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

摘要：

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

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

正文：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第四篇：軟件工程總結(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é)

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

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

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

軟件的特性，判斷正誤：1.軟件是無(wú)形的、不可見(jiàn)的邏輯實(shí)體，因此，軟件是無(wú)法描述的。（錯(cuò)）

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

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

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

5、由于軟件的開(kāi)發(fā)充滿人的個(gè)性特點(diǎn)，因此管理并不決定軟件開(kāi)發(fā)的成敗（錯(cuò)）。

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

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

8、軟件可以不斷改進(jìn)，因此軟件不需要廢棄。（錯(cuò)）

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

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

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

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

2、超過(guò)預(yù)計(jì)時(shí)間

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

4、生產(chǎn)率低

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

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

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

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

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

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

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

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

1、功能性

2、可靠性

3、使用性

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

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

1、效率

2、可維護(hù)性

3、可移植性

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

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

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

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

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

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

2、需求分析：做什么

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

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

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

6、軟件運(yùn)行和維護(hù)：修改 第二章軟件工程方法與工具

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

需求分析工具

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

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

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

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

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

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

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

2、沒(méi)有經(jīng)過(guò)與用戶(hù)交流而獲取的需求都是不真實(shí)的需求。（一些需求從用戶(hù)以外的途徑獲取）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5、引用的符號(hào)未加以解釋和說(shuō)明

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

7、對(duì)用到的重要庫(kù)函數(shù)沒(méi)有解釋說(shuō)明

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

9、缺乏必要的提示語(yǔ)句 第六章軟件測(cè)試方法

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