第一篇：軟件工程總結(jié) -背誦

第一章 軟件工程概論

1．什么是軟件危機(jī)？

軟件危機(jī)是指在計(jì)算機(jī)軟件的開(kāi)發(fā)和維護(hù)過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題。這些問(wèn)題表現(xiàn)在以下幾個(gè)方面：

(1)用戶(hù)對(duì)開(kāi)發(fā)出的軟件很難滿(mǎn)意。

(2)軟件產(chǎn)品的質(zhì)量往往靠不住。

(3)一般軟件很難維護(hù)。

(4)軟件生產(chǎn)效率很低。

(5)軟件開(kāi)發(fā)成本越來(lái)越大。

(6)軟件成本與開(kāi)發(fā)進(jìn)度難以估計(jì)。

(7)軟件技術(shù)的發(fā)展遠(yuǎn)遠(yuǎn)滿(mǎn)足不了計(jì)算機(jī)應(yīng)用的普及與深入的需要。

2．產(chǎn)生軟件危機(jī)的原因？

1.軟件本身的特點(diǎn)：邏輯部件，不具有直觀可見(jiàn)性；規(guī)模日趨龐大，開(kāi)發(fā)與管理十分復(fù)雜性

2.錯(cuò)誤的軟件開(kāi)發(fā)與維護(hù)方法:忽視軟件需求分析;輕視文檔的重要性;忽略軟件維護(hù)等

3．怎樣克服軟件危機(jī)？

(1)充分吸收和借鑒人類(lèi)長(zhǎng)期以來(lái)從事各種工程項(xiàng)目中積累的行之有效的有效原理、概念、技術(shù)與方法，特別是吸取幾十年來(lái)人類(lèi)從事計(jì)算機(jī)硬件研究和開(kāi)發(fā)的經(jīng)驗(yàn)教訓(xùn)。在開(kāi)發(fā)軟件的過(guò)程中努力作到良好的組織，嚴(yán)格的管理，相互友好的協(xié)作。

(2)推廣在實(shí)踐中總結(jié)出來(lái)的開(kāi)發(fā)軟件的成功的技術(shù)和方法，并研究更好、更有效的技術(shù)和方法，盡快克服在計(jì)算機(jī)系統(tǒng)早期發(fā)展階段形成的一些錯(cuò)誤概念和作法。

(3)根據(jù)不同的應(yīng)用領(lǐng)域，開(kāi)發(fā)更好的軟件工具并使用這些工具。將軟件開(kāi)發(fā)各個(gè)階段使用的軟件工具集合成一個(gè)整體，形成一個(gè)很好的軟件開(kāi)發(fā)支環(huán)環(huán)境。

總之為了解決軟件危機(jī)，既要有技術(shù)措施(方法和工具)，又要有必要的組織管理措施。

2．假設(shè)自己是一家軟件公司的總工程師，當(dāng)把圖1.1給手下的軟件工程師們觀看，告訴他們及早發(fā)現(xiàn)并改正錯(cuò)誤的重要性時(shí)，有人不同意這個(gè)觀點(diǎn)，認(rèn)為要求在錯(cuò)誤進(jìn)入軟件之前就清除它們是不現(xiàn)實(shí)的，并舉例說(shuō)：“如果一個(gè)故障是編碼錯(cuò)誤造成的，那么，一個(gè)人怎么能在設(shè)計(jì)階段清楚他呢？”應(yīng)該怎樣反駁他？

反駁：發(fā)生在編碼時(shí)期的故障極有可能是需求分析階段由于操作不當(dāng)產(chǎn)生的，所以必須及時(shí)消除錯(cuò)誤，否則，到了后期軟件運(yùn)行和維護(hù)階段再回過(guò)頭來(lái)修改，將會(huì)付出更大的代價(jià)。

4、什么是軟件工程?有哪些本質(zhì)特性怎樣用軟件工程消除軟件危機(jī)？

軟件工程是指導(dǎo)計(jì)算機(jī)軟件開(kāi)發(fā)和維護(hù)的工程學(xué)科。

來(lái)；

(1)它采用工程的概念、原理、技術(shù)和方法來(lái)開(kāi)發(fā)和維護(hù)軟件；

(2)它將管理技術(shù)與當(dāng)前經(jīng)過(guò)時(shí)間考驗(yàn)的而證明是正確的技術(shù)方法結(jié)合起(3)它強(qiáng)調(diào)使用生存周期方法學(xué)和結(jié)構(gòu)分析和結(jié)構(gòu)技術(shù)；(4)經(jīng)過(guò)人們長(zhǎng)期的努力和探索，圍繞著實(shí)現(xiàn)軟件優(yōu)質(zhì)高產(chǎn)這個(gè)目標(biāo),從技術(shù)到管理兩個(gè)方面做了大量的努力,逐漸形成了“軟件工程學(xué)”這一新的學(xué)科。

消除軟件危機(jī)的措施：

（1）對(duì)計(jì)算機(jī)軟件有一個(gè)正確的認(rèn)識(shí)（軟件≠程序）

（2）必須充分認(rèn)識(shí)到軟件開(kāi)發(fā)不是某種個(gè)體勞動(dòng)的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類(lèi)人員協(xié)同配合、共同完成的工程項(xiàng)目。

（3）推廣使用在實(shí)踐中總結(jié)出來(lái)的開(kāi)發(fā)軟件的成功技術(shù)和方法。（4）開(kāi)發(fā)和使用更好的軟件工具

5．什么是軟件生命周期，各階段的任務(wù)？

軟件生命周期是指從軟件定義、軟件開(kāi)發(fā)、軟件維護(hù)的全過(guò)程。

定義時(shí)期：?jiǎn)栴}定義 可行性研究 需求分析

開(kāi)發(fā)時(shí)期：總體設(shè)計(jì) 詳細(xì)設(shè)計(jì) 編碼和單元測(cè)試 綜合測(cè)試 維護(hù)時(shí)期：綜合測(cè)試

(1)問(wèn)題定義：通過(guò)對(duì)系統(tǒng)實(shí)際用戶(hù)和使用部門(mén)負(fù)責(zé)人的訪問(wèn)調(diào)查，明確要解決問(wèn)題性質(zhì)、工程目標(biāo)和規(guī)模。(2)可行性研究：導(dǎo)出系統(tǒng)的高層邏輯模型（數(shù)據(jù)流圖），并在此基礎(chǔ)上更準(zhǔn)確、更具體的確定工程的規(guī)模和目標(biāo)；更準(zhǔn)確的估計(jì)系統(tǒng)的成本和效益。

(3)需求分析：和用戶(hù)密切配合，充分交流信息，以得到用戶(hù)確認(rèn)的系統(tǒng)邏輯模型（數(shù)據(jù)流圖、數(shù)據(jù)字典及簡(jiǎn)要的算法表示的系統(tǒng)邏輯模型）。(4)總體設(shè)計(jì)：

1）提出幾種可能的解決方案，權(quán)衡各種方案的利弊，并推薦出最佳方案；

2）設(shè)計(jì)軟件的結(jié)構(gòu)，確定軟件的模塊構(gòu)成及模塊之間的關(guān)系。

(5)詳細(xì)設(shè)計(jì)：把解決問(wèn)題的方案具體化，設(shè)計(jì)出程序的詳細(xì)規(guī)格說(shuō)明，并包含必要的細(xì)節(jié)信息。(6)編碼和單元測(cè)試：將詳細(xì)設(shè)計(jì)的結(jié)果翻譯成高級(jí)程序設(shè)計(jì)語(yǔ)言的源程序，并仔細(xì)測(cè)試編寫(xiě)的每一個(gè)模塊。

(7)綜合測(cè)試：通過(guò)各類(lèi)型的嚴(yán)格測(cè)試與調(diào)試，使軟件達(dá)到預(yù)定的要求。

1）集成測(cè)試：各模塊裝配后測(cè)試；

2）驗(yàn)收測(cè)試：按規(guī)格說(shuō)明書(shū)。

(8)軟件維護(hù)：通過(guò)必要的維護(hù)工作使得系統(tǒng)持久的滿(mǎn)足用戶(hù)的需要： 1）改正性維護(hù)；2）適應(yīng)性維護(hù)； 3）完善性維護(hù)；4）預(yù)防性維護(hù)

6、軟件過(guò)程的定義？

為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)框架，他規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。

7、軟件工程的定義：

采用工程的概念、原理、技術(shù)和方法來(lái)開(kāi)發(fā)與維護(hù)軟件，把經(jīng)過(guò)時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的技術(shù)方法結(jié)合起來(lái)，來(lái)指導(dǎo)軟件的開(kāi)發(fā)與維護(hù)

8、軟件工程的基本原理：

（1）用分階段的生命周期計(jì)劃嚴(yán)格管理

項(xiàng)目概要計(jì)劃，里程碑計(jì)劃，項(xiàng)目控制計(jì)劃，產(chǎn)品控制計(jì)劃，驗(yàn)證計(jì)劃，運(yùn)行維護(hù)計(jì)劃。

（2）堅(jiān)持進(jìn)行階段評(píng)審（評(píng)審過(guò)程）

每個(gè)階段都進(jìn)行嚴(yán)格的評(píng)審，以便盡早發(fā)現(xiàn)錯(cuò)誤。（3）實(shí)行嚴(yán)格的產(chǎn)品控制

實(shí)行基準(zhǔn)配置（經(jīng)過(guò)階段評(píng)審后的軟件配置成份，包括文檔和程序代碼）對(duì)軟件的修改進(jìn)行嚴(yán)格管理。（4）采用現(xiàn)代的程序設(shè)計(jì)技術(shù)

結(jié)構(gòu)化分析(SA)與設(shè)計(jì)(SD);面向?qū)ο蟮姆治?OOA)與設(shè)計(jì)(OOD)。

（5）結(jié)果能清楚的審查

規(guī)定開(kāi)發(fā)組織的責(zé)任和產(chǎn)品標(biāo)準(zhǔn)。

（6）開(kāi)發(fā)小組的人員應(yīng)該少而精

成員素質(zhì)要好，人數(shù)不宜過(guò)多。

（7）承認(rèn)不斷改進(jìn)軟件工程實(shí)踐必要性

9、軟件工程方法學(xué)定義及三要素？

通常把在軟件生命周期全過(guò)程中使用的一整套技術(shù)方法的集合成為?（亦為范： 方法、工具、過(guò)程 型）

10.軟件工程方法學(xué)的包括：

簡(jiǎn)述結(jié)構(gòu)化范型和面向?qū)ο蠓缎偷囊c(diǎn)，并分析它們的優(yōu)缺點(diǎn)

傳統(tǒng)方法學(xué)（生命周期方法學(xué)/結(jié)構(gòu)化范型）（1）仍然是使用十分廣泛的軟件工程方法學(xué)。

（2）采用結(jié)構(gòu)化技術(shù)來(lái)完成軟件開(kāi)發(fā)的各項(xiàng)任務(wù)，并使用適當(dāng)?shù)能浖ぞ呋蜍浖こ汰h(huán)境來(lái)支持結(jié)構(gòu)化技術(shù)的運(yùn)用。

（3）從上而下，順序地完成軟件開(kāi)發(fā)的各階段任務(wù) 面向?qū)ο蟮姆椒▽W(xué)

（1）出發(fā)點(diǎn)和基本原則是盡量模擬人類(lèi)習(xí)慣的思維方式，使開(kāi)發(fā)軟件的方法與過(guò)程盡可能接近人類(lèi)認(rèn)識(shí)實(shí)踐解決問(wèn)題的方法與過(guò)程，從而使描述問(wèn)題的問(wèn)題空間與實(shí)現(xiàn)解法的解空間在結(jié)構(gòu)上盡可能一致

（2）把對(duì)象作為融合了數(shù)據(jù)及在數(shù)據(jù)上的操作行為的統(tǒng)一軟件構(gòu)件；（3）把所有對(duì)象都劃分成類(lèi)；

（4）按照父類(lèi)與子類(lèi)的關(guān)系，把若干個(gè)相關(guān)類(lèi)組成一個(gè)層次結(jié)構(gòu)的系統(tǒng)；（5）對(duì)象彼此間僅能通過(guò)發(fā)送消息互相聯(lián)系

11． 什么是軟件生命周期模型？ 模型分類(lèi)？

軟件開(kāi)發(fā)過(guò)程模型是軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。它能直觀表達(dá)軟件開(kāi)發(fā)全過(guò)程，明確規(guī)定要完成的主要活動(dòng)、任務(wù)和開(kāi)發(fā)策略。

亦稱(chēng)為： 軟件開(kāi)發(fā)模型 軟件生存期模型

分類(lèi)(1)瀑布模型(2)快速原型模型(3)增量模型（4）螺旋模型（5）噴泉模型

12、軟件過(guò)程的模型 瀑布模型：

【適用領(lǐng)域】：用戶(hù)需求清楚的表達(dá) 優(yōu)點(diǎn)：1.可強(qiáng)迫開(kāi)發(fā)員采用規(guī)范的方法 2.嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文件

3.要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過(guò)質(zhì)量保證小組的仔細(xì)驗(yàn)證。

缺點(diǎn)：傳統(tǒng)的瀑布模型過(guò)于理想化，是由文檔驅(qū)動(dòng)的。快速原型模型：（1）一般用于最終系統(tǒng)的早期用戶(hù)評(píng)價(jià),開(kāi)發(fā)工期短，質(zhì)量有保證

（2）軟件產(chǎn)品的開(kāi)發(fā)基本是線(xiàn)性順序進(jìn)行的，加速軟件開(kāi)發(fā)，節(jié)省軟件開(kāi)發(fā)成本

【適用領(lǐng)域】：事先不能完整定義需求的領(lǐng)域 增量模型：

【適用領(lǐng)域】：用戶(hù)逐步需求提交產(chǎn)品

（1）先完成一個(gè)系統(tǒng)子集的開(kāi)發(fā)，再按同樣的開(kāi)發(fā)步驟增加功能(系統(tǒng)子集),如此遞增下去直至滿(mǎn)足全部系統(tǒng)需求。

（2）系統(tǒng)的總體設(shè)計(jì)在初始子集設(shè)計(jì)階段就應(yīng)作出設(shè)想 13．軟件開(kāi)發(fā)方法：軟件開(kāi)發(fā)過(guò)程所遵循的方法和步驟

開(kāi)發(fā)過(guò)程一般包括：需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)等活動(dòng) 主要針對(duì)需求和設(shè)計(jì)的典型方法： 結(jié)構(gòu)化方法(SASD)面向數(shù)據(jù)結(jié)構(gòu)方法(OSD)面向?qū)ο蠓椒?OO)第二章 可行性研究

1.可行性研究目的?

確定在問(wèn)題定義中所提出的問(wèn)題是否值得去解，在限制條件下，問(wèn)題能否解決。

2．可行性研究的任務(wù)？

(1)進(jìn)一步分析和澄清問(wèn)題的定義，在澄清問(wèn)題的基礎(chǔ)上，導(dǎo)出系統(tǒng)的邏輯模型；

(2)從系統(tǒng)邏輯模型中，選擇問(wèn)題的若干種主要解法，研究每一種解法的可行性，為以后的行動(dòng)提出建議；

(3)如果問(wèn)題沒(méi)有可行的解，建議停止系統(tǒng)開(kāi)發(fā)；如果問(wèn)題有可行的解，應(yīng)該推薦一個(gè)較好的解決方案，并為工程制定一個(gè)初步的計(jì)劃。

3．可行性研究包括哪幾方面的內(nèi)容？

(1)技術(shù)可行性：現(xiàn)有技術(shù)能否實(shí)現(xiàn)本系統(tǒng)，現(xiàn)有技術(shù)人員能否勝任，開(kāi)發(fā)系統(tǒng)的資源能否滿(mǎn)足；

(2)經(jīng)濟(jì)可行性：經(jīng)濟(jì)效益是否超出開(kāi)發(fā)成本；

(3)操作可行性：系統(tǒng)操作在用戶(hù)內(nèi)部行得通嗎？

(4)法律可行性：新系統(tǒng)開(kāi)發(fā)是否會(huì)侵犯他人、集體或國(guó)家利益，是否違反國(guó)家法律。

4．可行性研究的步驟?

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

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

(3)導(dǎo)出新系統(tǒng)的高層邏輯模型；

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

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

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

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

（8）書(shū)寫(xiě)文檔提交審查。

5、數(shù)據(jù)流圖（DFD）:是一種圖形化技術(shù)，他描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過(guò)程中所經(jīng)受的變換。

有四種成分：源點(diǎn)或終點(diǎn)，處理，數(shù)據(jù)存儲(chǔ)，數(shù)據(jù)流。

6、數(shù)據(jù)字典

數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合，也是對(duì)數(shù)據(jù)流圖中包含所有的所有元素的定義的集合。

組成：數(shù)據(jù)流、數(shù)據(jù)元素、數(shù)據(jù)存儲(chǔ)、處理。

作用：對(duì)用戶(hù)來(lái)講,數(shù)據(jù)字典為他們提供了數(shù)據(jù)的明確定義；對(duì)系統(tǒng)分析員來(lái)講,數(shù)據(jù)字典幫助他們比較容易修改已建立的系統(tǒng)邏輯模型。

用途：

a.作為分析階段的工具，與數(shù)據(jù)流圖共同來(lái)完整的描述一個(gè)系統(tǒng)。數(shù)據(jù)流圖只描述了系統(tǒng)的邏輯模型，但是沒(méi)有給出數(shù)據(jù)及各個(gè)加工處理過(guò)程的具體含義；而數(shù)據(jù)字典則是其有益的補(bǔ)充。

b.數(shù)據(jù)字典中包含的每個(gè)數(shù)據(jù)元素的控制信息是很有價(jià)值的。c.開(kāi)發(fā)數(shù)據(jù)庫(kù)的基礎(chǔ)。8.數(shù)據(jù)流圖的用途：(1)作為交流信息的工具(2)作為分析和設(shè)計(jì)的工具

第三章 需求分析

1.為什么要進(jìn)行需求分析？對(duì)軟件系統(tǒng)有哪些需求？

為了開(kāi)發(fā)出真正滿(mǎn)足用戶(hù)需求的產(chǎn)品，首先必須知道用戶(hù)的需求。

對(duì)系統(tǒng)的要求：功能需求、性能需求、可靠性和可用性需求、出錯(cuò)性處理需求、接口需求、約束、逆向需求、將來(lái)可能提出的需求。

2、邏輯模型

用數(shù)據(jù)流圖、實(shí)體-聯(lián)系圖、狀態(tài)轉(zhuǎn)換圖、數(shù)據(jù)字典、主要的處理算法來(lái)描述。

3、訪談

在訪談的過(guò)程中使用情景分析技術(shù)非常有效，情景分析就是對(duì)用戶(hù)將來(lái)使用 目標(biāo)系統(tǒng)解決具體的問(wèn)題的方法和結(jié)果進(jìn)行分析。

3.與用戶(hù)溝通獲取需求的方法：

（1）訪談、分發(fā)調(diào)查表、情景分析技術(shù)（2）面向數(shù)據(jù)流自頂下下求精（3）簡(jiǎn)易的應(yīng)用規(guī)格說(shuō)明書(shū)（4）快速建立軟件原型

4．訪談分類(lèi)：正式的訪談、非正式的訪談

5．情景分析技術(shù)的用處主要體現(xiàn)在以下兩個(gè)方面：

（1）它能在某種程度上演示目標(biāo)系統(tǒng)的行為，從而便于用戶(hù)解釋?zhuān)疫€可以進(jìn)一步揭示出一些分析員目前還不知道的需求。

（2）由于情景分析較易為用戶(hù)所理解，使用這種技術(shù)能保證用戶(hù)在需求分析的過(guò)程中始終扮演一個(gè)積極主動(dòng)的角色。

6．（1）結(jié)構(gòu)化分析方法：就是面向數(shù)據(jù)流自頂向下逐步求精進(jìn)行需求分析的方法。（2）結(jié)構(gòu)化分析實(shí)質(zhì)上是一種創(chuàng)建模型的活動(dòng)。

（3）根據(jù)結(jié)構(gòu)化分析準(zhǔn)則，需求分析過(guò)程應(yīng)該建立3種模型: 數(shù)據(jù)模型、功能模型、行為模型

（4）實(shí)體-聯(lián)系圖（ERD）描繪數(shù)據(jù)對(duì)象及數(shù)據(jù)對(duì)象之間的關(guān)系，用于建立數(shù)據(jù)模型的圖形。

（5）數(shù)據(jù)流圖描繪數(shù)據(jù)在軟件中移動(dòng)時(shí)被變換的邏輯過(guò)程，指明系統(tǒng)具有的變換數(shù)據(jù)的功能，數(shù)據(jù)流圖是建立功能模型的基礎(chǔ)。

（6）狀態(tài)轉(zhuǎn)換圖（狀態(tài)圖STD）指明作為外部事件結(jié)果的系統(tǒng)行為。狀態(tài)轉(zhuǎn)換圖描繪系統(tǒng)的各種行為模式和在不同狀態(tài)間轉(zhuǎn)換的方式。狀態(tài)轉(zhuǎn)換圖是行為建模的基礎(chǔ)。

7．從哪些方面驗(yàn)證軟件需求的正確性？

一致性、完整性、現(xiàn)實(shí)性、有效性 8.驗(yàn)證軟件需求的的方法：

（1）驗(yàn)證需求的一致性：軟件工具

（2）驗(yàn)證需求的現(xiàn)實(shí)性：仿真或性能模擬技術(shù)

（3）驗(yàn)證需求的完整性和有效性：只有在用戶(hù)的密切合作下才能完成 9.需求分析的描述工具有哪些?

有數(shù)據(jù)流圖、數(shù)據(jù)字典、判定表、判定樹(shù)、結(jié)構(gòu)化自然語(yǔ)言、層次方框圖、Warnier圖、IPO圖和需求描述語(yǔ)言等

5、E-R圖包含：實(shí)體、關(guān)系、屬性。

6、層次方框圖：用樹(shù)形結(jié)構(gòu)的、一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。

7.系統(tǒng)流程圖與數(shù)據(jù)流程圖有什么區(qū)別?

系統(tǒng)流程圖描述系統(tǒng)物理模型的工具，數(shù)據(jù)流程圖描述系統(tǒng)邏輯模型的工具。

系統(tǒng)流程圖從系統(tǒng)功能的角度抽象的描述系統(tǒng)的各個(gè)部分及其相互之間信息流動(dòng)的情況。

數(shù)據(jù)流程圖從數(shù)據(jù)傳送和加工的角度抽象的描述信息在系統(tǒng)中的流動(dòng)和數(shù)

據(jù)處理的工作狀況。4．（1）設(shè)計(jì)原理：

模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨(dú)立（2）抽象(Abstraction)：解決問(wèn)題時(shí)只考慮與問(wèn)題有關(guān)的方面，不考慮與問(wèn)題無(wú)關(guān)的方面。即抽出事物的本質(zhì)特性而不考慮細(xì)節(jié)

（3）逐步求精定義：

為了能集中精力解決主要問(wèn)題而盡量推遲對(duì)問(wèn)題細(xì)節(jié)的考慮。人類(lèi)解決復(fù)雜問(wèn)題時(shí)采用的基本方法，也是許多軟件工程技術(shù)(例如，規(guī)格說(shuō)明技術(shù)，設(shè)計(jì)和實(shí)現(xiàn)技術(shù))的基礎(chǔ) 作用：

幫助軟件工程師把精力集中在與當(dāng)前開(kāi)發(fā)階段最相關(guān)的那些方面上忽略那些對(duì)整體解決方案來(lái)說(shuō)雖然是必要的，然而目前還不需要考慮的細(xì)節(jié)，這些細(xì)節(jié)將留到以后再考慮（4）信息隱蔽的含義：

有效的模塊化可以通過(guò)定義一組獨(dú)立模塊來(lái)實(shí)現(xiàn)，這些模塊相互之間只交流軟件功能必需的信息。

目的： 提高模塊的獨(dú)立性，減少修改或維護(hù)時(shí)的影響面。（5）信息局部化：把關(guān)系密切的軟件元素物理地放得彼此靠近。

優(yōu)點(diǎn)：可維護(hù)性好、可靠性好、可理解性好 5．模塊化(Modularity)？模塊設(shè)計(jì)的準(zhǔn)則？

是按規(guī)定的原則將一個(gè)大型軟件劃分為一個(gè)個(gè)較小的、相對(duì)獨(dú)立但又相關(guān)的模塊。準(zhǔn)則：

(1)改進(jìn)軟件結(jié)構(gòu), 提高模塊獨(dú)立性:在對(duì)初步模塊進(jìn)行合并、分解和移動(dòng)的分析、精化過(guò)程中力求提高模塊的內(nèi)聚，降低藕合。

(2)模塊大小要適中:大約50行語(yǔ)句的代碼，過(guò)大的模塊應(yīng)分解以提高理解性和可維護(hù)性;過(guò)小的模塊,合并到上級(jí)模塊中。

(3)軟件結(jié)構(gòu)圖的深度、寬度、扇入和扇出要適當(dāng)。一般模塊的調(diào)用個(gè)數(shù)不要超過(guò)5個(gè)。

(4)盡量降低模塊接口的復(fù)雜程度；(5)設(shè)計(jì)單入口、單出口的模塊。

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

6．模塊？特征？總體設(shè)計(jì)主要考慮什么特征？

（1）模塊是數(shù)據(jù)說(shuō)明、可執(zhí)行語(yǔ)句等程序?qū)ο蟮募希梢詥为?dú)命名且可通過(guò)名字來(lái)訪問(wèn)。

（2）模塊具有輸入和輸出(參數(shù)傳遞)、功能、內(nèi)部數(shù)據(jù)結(jié)構(gòu)(局部變量)和程序代碼四個(gè)特性。

（3）概要設(shè)計(jì)主要考慮輸入、輸出(參數(shù)傳遞)和功能兩個(gè)特性

7.模塊獨(dú)立：的概念是模塊化、抽象、信息隱藏、局部化概念的直接結(jié)果 特點(diǎn)：具有特定子功能、接口簡(jiǎn)單

耦合強(qiáng)度依賴(lài)的因素：

一模塊對(duì)另一模塊的引用

一模塊向另一模塊傳遞的數(shù)據(jù)量 一模塊施加到另一模塊的控制的數(shù)量 模塊間接口的復(fù)雜程度

去除模塊間控制耦合的方法：

(1)將被調(diào)用模塊內(nèi)的判定上移到調(diào)用模塊中進(jìn)行(2)被調(diào)用模塊分解成若干單一功能模塊 如何降低模塊間耦合度：

(1)如模塊必須存在耦合，選擇適當(dāng)?shù)鸟詈项?lèi)型原則：

盡量使用數(shù)據(jù)耦合 少用控制耦合

限制公共耦合的范圍

堅(jiān)決避免使用內(nèi)容耦合(2)降低模塊間接口的復(fù)雜性

內(nèi)聚性：

一個(gè)模塊內(nèi)部各成分之間相互關(guān)聯(lián)的強(qiáng)度

耦合、內(nèi)聚與模塊獨(dú)立性關(guān)系

耦合與內(nèi)聚都是模塊獨(dú)立性的定性標(biāo)準(zhǔn)，都反映模塊獨(dú)立性的良好程度。但耦合是直接的主導(dǎo)因素，內(nèi)聚則輔助耦合共同對(duì)模塊獨(dú)立性進(jìn)行衡量。

第五章 總體設(shè)計(jì)

1.總體設(shè)計(jì)包括哪兩個(gè)階段? 系統(tǒng)設(shè)計(jì)階段與結(jié)構(gòu)設(shè)計(jì)階段。

2、總體設(shè)計(jì)的步驟

設(shè)想供選擇的方案、選取合理的方案、推薦最佳方案、功能分解、設(shè)計(jì)軟件結(jié)構(gòu)、設(shè)計(jì)數(shù)據(jù)庫(kù)、制定測(cè)試計(jì)劃、書(shū)寫(xiě)文檔、審查和復(fù)查 3.總體設(shè)計(jì)的 目標(biāo)

形成軟件的一種層次的可對(duì)底層結(jié)點(diǎn)交叉引用的模塊化模型

4、設(shè)計(jì)原理

模塊化就是把程序劃分成獨(dú)立命名且可獨(dú)立訪問(wèn)的模塊，每個(gè)模塊完成一個(gè)子

功能，把這些模塊集成起來(lái)構(gòu)成一個(gè)整體，可以完成指定的功能滿(mǎn)足用戶(hù)的需求。5.模塊的獨(dú)立程度用內(nèi)聚和耦合來(lái)衡量。

耦合：對(duì)一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量。數(shù)據(jù)耦合是低耦合，內(nèi)容耦合是最高程度的。

內(nèi)聚：表示一個(gè)模塊內(nèi)各個(gè)元素彼此結(jié)合的緊密程度。

6、變換型數(shù)據(jù)流由哪幾部分組成，及步驟？

變換型結(jié)構(gòu)由三部分組成:傳入路徑、變換中心和傳出路徑。

步驟：

(1)區(qū)分傳入、傳出和變換中心三部分，劃分DFD圖的分界線(xiàn)；

(2)完成第一級(jí)分解:建立初始SC圖的框架；

(3)完成第二級(jí)分解:分解SC圖的各個(gè)分支；

(4)對(duì)初始結(jié)構(gòu)圖按照設(shè)計(jì)準(zhǔn)則進(jìn)行精化與改進(jìn)。

7.事務(wù)型數(shù)據(jù)流由哪幾部分組成？

事務(wù)型結(jié)構(gòu)由至少一條接受路徑、一個(gè)事務(wù)中心與若干條動(dòng)作路徑組成。

步驟：

(1)在DFD圖中確定事務(wù)中心、接收部分(包含全部接收路徑)和發(fā)送部分(包含全部動(dòng)作路徑);

(2)畫(huà)出SC圖框架,把DFD圖的三部分分?quot;映射"為事務(wù)控制模塊,接收模塊和動(dòng)作發(fā)送模塊.一般得到SC圖的頂層和第一層(如果第一層簡(jiǎn)單可以并入頂層);

(3)分解和細(xì)化接收分支和動(dòng)作分支,完成初始的SC圖;

(4)對(duì)初始結(jié)構(gòu)圖按照設(shè)計(jì)準(zhǔn)則進(jìn)行精化與改進(jìn)。

8、比較層次方框圖與結(jié)構(gòu)圖是的異同？

(1)層次方框圖描繪數(shù)據(jù)的層次結(jié)構(gòu), 結(jié)構(gòu)圖描繪的是軟件結(jié)構(gòu)。

(2)二者都采用多層次矩形框樹(shù)形結(jié)構(gòu)。層次方框圖的頂層矩形框代表完整的數(shù)據(jù)結(jié)構(gòu), 下面各層矩形框依次代表上個(gè)框數(shù)據(jù)的子集；結(jié)構(gòu)圖

是在層次圖的每一個(gè)方框內(nèi)注明模塊的名字或主要功能，方框之間的直線(xiàn)表示模塊的調(diào)用關(guān)系，用帶注解的箭頭表示模塊調(diào)用過(guò)程中傳遞的信息。

9、啟發(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è) 名稱(chēng)解釋?zhuān)?/p>

（1）深度：表示軟件結(jié)構(gòu)中控制的層數(shù)，粗略的標(biāo)志了一個(gè)系統(tǒng)的大小和復(fù)雜程度（2）寬度：軟件結(jié)構(gòu)內(nèi)同一個(gè)層次上的模塊總數(shù)的最大值。一般來(lái)說(shuō)，寬度越大系統(tǒng)越復(fù)雜。對(duì)寬度影響最大的因素是模塊的扇出。

（3）扇出：是一個(gè)模塊直接控制（調(diào)用）的模塊數(shù)模，扇出過(guò)大意味著模塊過(guò)分復(fù)雜，需要控制盒協(xié)調(diào)過(guò)多的下級(jí)模塊。

9.描繪軟件結(jié)構(gòu)的圖形工具：

（1）層次圖(Hierarchy圖)和HIPO圖（帶編號(hào)）

（2）結(jié)構(gòu)圖（SC）

10.（1）IPO圖——是輸入、處理、輸出圖的簡(jiǎn)稱(chēng)，它是美國(guó)IBM公司發(fā)展完善起來(lái)的一種圖形工具，能夠方便地描繪輸入數(shù)據(jù)、對(duì)數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關(guān)系。（2）IPO圖的基本形式是：

A.在左邊的框中列出有關(guān)的輸入數(shù)據(jù)，B.在中間的框內(nèi)列出主要的處理，C.在右邊的框內(nèi)列出產(chǎn)生的輸出數(shù)據(jù)。

12.面向數(shù)據(jù)流的設(shè)計(jì)方法

（1）面向數(shù)據(jù)流的設(shè)計(jì)方法是把信息流映射成軟體結(jié)構(gòu)，信息流的類(lèi)型決定了映射的方法。

（2）信息流的兩種類(lèi)型：變換流

事務(wù)流

（3）事務(wù)流/事務(wù)中心完成的任務(wù)：接收輸入數(shù)據(jù)

分析每個(gè)事務(wù)以確定它的類(lèi)型

根據(jù)事務(wù)類(lèi)型選取一條活動(dòng)通路（4）面向數(shù)據(jù)流方法的設(shè)計(jì)過(guò)程：

（5）設(shè)計(jì)步驟：

1復(fù)查基本系統(tǒng)模型

○2復(fù)查并精華數(shù)據(jù)流圖

○3確定數(shù)據(jù)流圖具有變換特性還是事務(wù)特性

○4確定輸入流和輸出流的邊界，從而孤立出變換中心

○5完成“第一級(jí)分解”

○6完成“第二級(jí)分解”

○7使用設(shè)計(jì)度量和啟發(fā)式規(guī)則對(duì)第一次分割得到的軟件結(jié)構(gòu)進(jìn)一步精化

○（6）設(shè)計(jì)步驟的目的：開(kāi)發(fā)出軟件的整體表示。即一旦確定了軟件結(jié)構(gòu)就可以把它作

為一個(gè)整體來(lái)復(fù)查，從而能夠評(píng)價(jià)和精化軟件結(jié)構(gòu)

（7）概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)的區(qū)別

——概要設(shè)計(jì)就是設(shè)計(jì)軟件的結(jié)構(gòu)，包括組成模塊，模塊的層次結(jié)構(gòu)，模塊的調(diào)用關(guān)

系，每個(gè)模塊的功能等等。同時(shí)，還要設(shè)計(jì)該項(xiàng)目的應(yīng)用系統(tǒng)的總體數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫(kù)結(jié)構(gòu)，即應(yīng)用系統(tǒng)要存儲(chǔ)什么數(shù)據(jù)，這些數(shù)據(jù)是什么樣的結(jié)構(gòu)，它們之間有什么關(guān)系。——詳細(xì)設(shè)計(jì)階段就是為每個(gè)模塊完成的功能進(jìn)行具體的描述，要把功能描述轉(zhuǎn)變?yōu)榫_的、結(jié)構(gòu)化的過(guò)程描述。

第六章 詳細(xì)設(shè)計(jì)

1.詳細(xì)設(shè)計(jì)的目的? 為軟件結(jié)構(gòu)圖(SC圖或HC圖)中的每一個(gè)模塊確定采用的算法和塊內(nèi)數(shù)據(jù)結(jié)構(gòu),用某種選定的表達(dá)工具給出清晰的描述.2.詳細(xì)設(shè)計(jì)的主要任務(wù)? 編寫(xiě)軟件的“詳細(xì)設(shè)計(jì)說(shuō)明書(shū)”.軟件人員要完成的工作:(1)為每一個(gè)模塊確定采用的算法, 選擇某種適當(dāng)?shù)墓ぞ弑磉_(dá)算法的過(guò)程,寫(xiě)出模塊的詳細(xì)過(guò)程描述.(2)確定每一模塊使用的數(shù)據(jù)結(jié)構(gòu).(3)確定模塊結(jié)構(gòu)的細(xì)節(jié),包括對(duì)系統(tǒng)外部的接口和用戶(hù)界面,對(duì)系統(tǒng)內(nèi)部其它模塊的接口,以及關(guān)于模塊輸入數(shù)據(jù)、輸出數(shù)據(jù)及局部數(shù)據(jù)的全部細(xì)節(jié).(4)為每一個(gè)模塊設(shè)計(jì)出一組測(cè)試用例,以便在編碼階段對(duì)模塊代碼(即程序)進(jìn)行預(yù)定的測(cè)試.3、詳細(xì)設(shè)計(jì)工具：(1)圖形工具(2)表格工具

(3)語(yǔ)言工具 4結(jié)構(gòu)程序設(shè)計(jì)？

（1）完成軟件模塊過(guò)程設(shè)計(jì)的一種重要技術(shù)

（2）所有程序都可以建立在一組已有的邏輯構(gòu)成元素上，這一組邏輯構(gòu)成元素強(qiáng)調(diào)了“對(duì)功能域的維護(hù)”。

（3）這些邏輯構(gòu)成元素是結(jié)構(gòu)化程序設(shè)計(jì)的基礎(chǔ)。

6、程序（過(guò)程）設(shè)計(jì)工具

程序流程圖

盒圖(N-S圖)

問(wèn)題分析圖(PAD)設(shè)計(jì)語(yǔ)言(PDL)(偽碼)

判定表

程序流程圖/程序框圖

缺點(diǎn)：（1）誘使程序員過(guò)早的考慮程序的控制流程，而不去考慮程序的全局結(jié)構(gòu)

（2）在程序流程圖中用箭頭表示控制流，因此控制員不受任何約束，可以完全不顧結(jié)構(gòu)程序設(shè)計(jì)的精神，隨意轉(zhuǎn)移控制（3）程序流程圖不易表示數(shù)據(jù)結(jié)構(gòu)

盒圖(N-S圖)

特點(diǎn)：（1）功能域明確，可以從盒圖上一眼就能看出來(lái)

（2）不可能任意轉(zhuǎn)移控制

（3）很容易確定局部和全程數(shù)據(jù)的作用域

（4）很容易表現(xiàn)嵌套關(guān)系，也可表示模塊的層次結(jié)構(gòu)

問(wèn)題分析圖(PAD圖)

優(yōu)點(diǎn)：（1）使用表示結(jié)構(gòu)化控制結(jié)構(gòu)的PAD符號(hào)所設(shè)計(jì)出來(lái)的必然是結(jié)構(gòu)化

程序

（2）PAD圖所描繪的程序十分清晰

（3）用PAD圖變現(xiàn)程序邏輯，易讀，易懂，易記

（4）PAD圖的符號(hào)支持自頂向下、逐步求精方法的使用

（5）容易將PAD圖轉(zhuǎn)換成高級(jí)語(yǔ)言源程序

（6）即可用于表示程序邏輯，也可用于描述數(shù)據(jù)結(jié)構(gòu)

過(guò)程設(shè)計(jì)語(yǔ)言(PDL)(偽碼)特點(diǎn)：

（1）關(guān)鍵字的固定語(yǔ)法，它提供了結(jié)構(gòu)化控制結(jié)構(gòu)、數(shù)據(jù)說(shuō)明和模塊化的特點(diǎn)

（2）自然語(yǔ)言的自由語(yǔ)法，它描述出來(lái)特點(diǎn)

（3）數(shù)據(jù)說(shuō)明的手段

（4）模塊定義和調(diào)用的技術(shù)，應(yīng)該提供各種接口描述模式 作為設(shè)計(jì)工具的優(yōu)點(diǎn)：

（1）可以作為注釋直接插在源程序中間

（2）可以使用普通的正文編輯程序或文字處理系統(tǒng)，很方便的完成PDL的書(shū)寫(xiě)和編輯工作

（3）已經(jīng)有自動(dòng)處理PDL的程序存在，而且可以自動(dòng)有PDL生產(chǎn)程序代碼 缺點(diǎn)：不如圖形工具形象直觀，描述復(fù)雜的條件組合與動(dòng)作之間的對(duì)應(yīng)關(guān)系時(shí)，不如判斷表清晰簡(jiǎn)單

判定表

組成：左上部列出所有條件、左下部是所有可能做的動(dòng)作、右上部是表示各種條件組合的一個(gè)矩陣、右下部是和每種條件組合相對(duì)應(yīng)的動(dòng)作

判斷樹(shù)

優(yōu)點(diǎn)：形式簡(jiǎn)單到不需任何說(shuō)明，一眼就可以看出其含 義，易于掌握和利用。

第七章 編碼

1.軟件測(cè)試的基本任務(wù)？ 軟件測(cè)試是按照特定的規(guī)則，發(fā)現(xiàn)軟件錯(cuò)誤的過(guò)程；好的測(cè)試方案是盡可能發(fā)現(xiàn)迄今尚未發(fā)現(xiàn)錯(cuò)誤的測(cè)試；成功的測(cè)試方案是發(fā)現(xiàn)迄今尚未發(fā)現(xiàn)錯(cuò)誤的測(cè)試；

2、.測(cè)試與調(diào)試的主要區(qū)別？

(1)測(cè)試從一個(gè)側(cè)面證明程序員的失敗；調(diào)試證明程序員的正確；

(2)測(cè)試從已知條件開(kāi)始，使用預(yù)先定義的程序，且有預(yù)知的結(jié)果，不可預(yù)見(jiàn)的僅是程序是否通過(guò)測(cè)試；調(diào)試從不可知內(nèi)部條件開(kāi)始，除統(tǒng)計(jì)性調(diào)試外，結(jié)果是不可預(yù)見(jiàn)的；

(3)測(cè)試有計(jì)劃并且要進(jìn)行測(cè)試設(shè)計(jì)；調(diào)試不受時(shí)間約束；

(4)測(cè)試是發(fā)現(xiàn)錯(cuò)誤、改正錯(cuò)誤、重新測(cè)試的過(guò)程；調(diào)試是一個(gè)推理的過(guò)程；(5)測(cè)試執(zhí)行是有規(guī)程的；調(diào)試執(zhí)行要求程序員進(jìn)行必要的推理；

(6)測(cè)試由獨(dú)立的測(cè)試組在不了解軟件設(shè)計(jì)的件下完成；調(diào)試由了解詳細(xì)設(shè)計(jì)的程序員完成；

(7)(大多數(shù)測(cè)試的執(zhí)行和設(shè)計(jì)可由工具支持；調(diào)試用的工具主要是調(diào)試 4.什么是黑盒測(cè)試?黑盒測(cè)試主要采用的技術(shù)有哪些?

黑盒測(cè)試也稱(chēng)為功能測(cè)試,它著眼于程序的外部特征,而不考慮程序的內(nèi)部邏輯結(jié)構(gòu)。測(cè)試者把被測(cè)程序看成一個(gè)黑盒,不用關(guān)心程序的內(nèi)部結(jié)構(gòu)。黑盒測(cè)試是在程序接口處進(jìn)行測(cè)試，它只檢查程序功能是否能按照規(guī)格說(shuō)明書(shū)的規(guī)定正

常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫(kù)或文件)的完整性。

黑盒測(cè)試主要采用的技術(shù)有:等價(jià)分類(lèi)法、邊沿值分析法、錯(cuò)誤推測(cè)法和因果圖等技術(shù)。

5.什么是白盒測(cè)試?白盒測(cè)試主要采用的技術(shù)有哪些? 測(cè)試者了解被測(cè)程序的內(nèi)部結(jié)構(gòu)和處理過(guò)程,對(duì)程序的所有邏輯路徑進(jìn)行測(cè)試,在不同點(diǎn)檢查程序狀態(tài),確定實(shí)際狀態(tài)與預(yù)期狀態(tài)是否一致。

白盒測(cè)試主要采用的技術(shù)有：路徑測(cè)試技術(shù)和事務(wù)處理流程技術(shù)，對(duì)包含有大量邏輯判斷或條件組合的程序采用基于邏輯的測(cè)試技術(shù)。8.軟件測(cè)試的一般步驟? 單元測(cè)試、子系統(tǒng)測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試、平行測(cè)試。

9、調(diào)試路徑：蠻干法、回溯法、原因排除法

第八章 軟件維護(hù)

1.軟件維護(hù)的定義：在軟件已經(jīng)交付使用之后，為了改正錯(cuò)誤或滿(mǎn)足新的需要而修改軟件的過(guò)程

2.軟件的維護(hù)一般分為哪幾類(lèi)？

改正性維護(hù)：滿(mǎn)足用戶(hù)對(duì)已開(kāi)發(fā)產(chǎn)品的性能與運(yùn)行環(huán)境不斷提高的要求，進(jìn)而達(dá)到延長(zhǎng)軟件壽命的目的。

適應(yīng)性維護(hù)：對(duì)程序使用期間發(fā)現(xiàn)的程序錯(cuò)誤進(jìn)行診斷和改正的過(guò)程，配合變化了的環(huán)境進(jìn)行修改軟件的活動(dòng)；

完善性維護(hù)：滿(mǎn)足用戶(hù)在使用過(guò)程中提出增加新的功能或修改已有功能的建議而進(jìn)行的工作；

預(yù)防性維護(hù)：為了改善未來(lái)的可維護(hù)性或可靠性而修改軟件的工作。5.決定軟件可維護(hù)性的因素？

(1)軟件的可理解性、可測(cè)試性、可修改性；

(2)文檔描述符合要求、用戶(hù)文檔簡(jiǎn)潔明確、系統(tǒng)文檔完整并且標(biāo)準(zhǔn)。

第十三章 軟件工程管理

影響軟件質(zhì)量的主要因素有哪些？

(1)產(chǎn)品運(yùn)行:正確性、風(fēng)險(xiǎn)性、效率、完整性、健壯性和可用性；

(2)產(chǎn)品修改:可理解性、可維護(hù)性、靈活性、可測(cè)試性；

(3)產(chǎn)品轉(zhuǎn)移：可移植性、可重用性和互運(yùn)行性。

第二篇：軟件工程總結(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ù)算，滿(mǎn)足用戶(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ā)充滿(mǎn)人的個(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ù)是使軟件持久地滿(mǎn)足用戶(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)品如何滿(mǎ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ù)等。需求獲取的原則：深入淺出，以流程為主線(xiàn)。

獲取具體的需求的途徑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ò)程。

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

一、軟件工程概述

1．軟件特點(diǎn)

軟件：計(jì)算機(jī)程序（人們?yōu)榱藢?shí)現(xiàn)特定的功能而編制的一組指令集），軟件文檔，以及計(jì)算機(jī)程序運(yùn)行時(shí)所需要的數(shù)據(jù)。

軟件是計(jì)算機(jī)系統(tǒng)中的邏輯成分，具有無(wú)形性，可復(fù)用性。

2．軟件分類(lèi)（1）按功能劃分：系統(tǒng)軟件、支撐軟件、應(yīng)用軟件。（2）按工作方式劃分：實(shí)時(shí)處理軟件、分時(shí)處理軟件、交互式軟件、批處理軟件。（3）按規(guī)模劃分：微型軟件、小型軟件、中型軟件、大型軟件。（4）按服務(wù)對(duì)象劃分：通用軟件、定制軟件。3．軟件發(fā)展階段（1）程序設(shè)計(jì)時(shí)代（20世紀(jì)50年代）。（2）程序系統(tǒng)時(shí)代（20世紀(jì)60年代）。（3）軟件工程時(shí)代（20世紀(jì)70年代起）。4．軟件危機(jī)

（1）危機(jī)現(xiàn)象：軟件開(kāi)發(fā)成本與進(jìn)度估計(jì)不準(zhǔn)確，軟件產(chǎn)品與用戶(hù)要求不一致，軟件產(chǎn)品質(zhì)量可靠性差，軟件文檔不完整不一致，軟件產(chǎn)品可維護(hù)性差，軟件生產(chǎn)率低。

（2）危機(jī)原因：科學(xué)的工程化思想組織和指導(dǎo)，完善的質(zhì)量保證體系，軟件文檔的不重視，軟件的不可見(jiàn)性，系統(tǒng)規(guī)模龐大，生產(chǎn)工程化程度低，對(duì)用戶(hù)需求關(guān)心不 夠，對(duì)維護(hù)不夠重視，開(kāi)發(fā)工具自動(dòng)化程度低。5．軟件工程

軟件工程：運(yùn)用現(xiàn)代科學(xué)技術(shù)知識(shí)來(lái)設(shè)計(jì)并構(gòu)造計(jì)算機(jī)程序及為開(kāi)發(fā)、運(yùn)行和維護(hù)這些程序所必須的相關(guān)文件資料。軟件工程是一門(mén)關(guān)于軟件開(kāi)發(fā)與維護(hù)的工程學(xué)科，它涉及軟件生產(chǎn)的各個(gè)方面，能夠?yàn)榻?jīng)濟(jì)、高效地開(kāi)發(fā)高質(zhì)量的軟件產(chǎn)品提供最有效的支持。

軟件工程的目標(biāo)：控制成本，滿(mǎn)足需求，提高質(zhì)量，提高可靠性，是產(chǎn)品易于維護(hù)，移植，升級(jí)和使用，控制開(kāi)發(fā)周期。

（1）工程方法：結(jié)構(gòu)化方法、JSD方法、面向?qū)ο蠓椒ā＃?）軟件工具：具有自動(dòng)化特征的軟件開(kāi)發(fā)集成支撐環(huán)境。（3）工程過(guò)程：在軟件工具支持下的一系列工程活動(dòng)，基本活動(dòng)是軟件定義、軟件開(kāi)發(fā)、軟件驗(yàn)證、軟件維護(hù)。（4）工程管理：項(xiàng)目規(guī)劃，項(xiàng)目資源調(diào)配，軟件產(chǎn)品控制。（5）工程原則：分階段生命周期計(jì)劃，階段評(píng)審制度，嚴(yán)格的產(chǎn)品控制，采用先進(jìn)的技術(shù)，成果能清楚地審查，開(kāi)發(fā)隊(duì)伍精練，不斷改進(jìn)工程實(shí)踐。（6）工程目標(biāo)：開(kāi)發(fā)成本較低，軟件功能能滿(mǎn)足用戶(hù)需求，軟件性能較好，軟件可靠性高，軟件易于使用、維護(hù)與移植，能按時(shí)完成開(kāi)發(fā)任務(wù)并及時(shí)交付使用。（7）工程文化：包括工程價(jià)值、工程思想和工程行為三個(gè)方面的內(nèi)容。

二、軟件工程過(guò)程模型 1．軟件生命周期 如同任何事物都有一個(gè)發(fā)生、發(fā)展、成熟直至衰亡的全過(guò)程一樣，軟件系統(tǒng)或軟件產(chǎn)品也有一個(gè)定義、開(kāi)發(fā)、運(yùn)行維護(hù)直至被淘汰這樣的全過(guò)程，我們把軟件將要經(jīng)歷的這個(gè)全過(guò)程稱(chēng)為軟件的生命周期。它包含：軟件定義、軟件開(kāi)發(fā)、軟件運(yùn)行維護(hù)三個(gè)時(shí)期，并可以細(xì)分為可行性研究、項(xiàng)目計(jì)劃、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼實(shí)現(xiàn)與單元測(cè)試、系統(tǒng) 2 集成測(cè)試、系統(tǒng)確認(rèn)驗(yàn)證、系統(tǒng)運(yùn)行與維護(hù)等幾個(gè)階段。

軟件定義期 軟件定義是軟件項(xiàng)目的早期階段，主要由軟件系統(tǒng)分析人員和用戶(hù)合作，針對(duì)有待開(kāi)發(fā)的軟件系統(tǒng)進(jìn)行分析、規(guī)劃和規(guī)格描述，確定軟件是什么，為今后的軟件開(kāi)發(fā)做準(zhǔn)備。這個(gè)時(shí)期往往需要分階段地進(jìn)行以下幾項(xiàng)工作。1．軟件任務(wù)立項(xiàng) 軟件項(xiàng)目往往開(kāi)始于任務(wù)立項(xiàng)，并需要以“軟件任務(wù)立項(xiàng)報(bào)告”的形式針對(duì)項(xiàng)目的名稱(chēng)、性質(zhì)、目標(biāo)、意義和規(guī)模等作出回答，以此獲得對(duì)準(zhǔn)備著手開(kāi)發(fā)的軟件系統(tǒng)的最高層描述。2．項(xiàng)目可行性分析 在軟件任務(wù)立項(xiàng)報(bào)告被批準(zhǔn)以后，接著需要進(jìn)行項(xiàng)目可行性分析。可行性分析是針對(duì)準(zhǔn)備進(jìn)行的軟件項(xiàng)目進(jìn)行的可行性風(fēng)險(xiǎn)評(píng)估。因此，需要對(duì)準(zhǔn)備開(kāi)發(fā)的軟件系統(tǒng)提出高層模型，并根據(jù)高層模型的特征，從技術(shù)可行性、經(jīng)濟(jì)可行性和操作可行性這三個(gè)方面，以“可行性研究報(bào)告”的形式，對(duì)項(xiàng)目作出是否值得往下進(jìn)行的回答，由此決定項(xiàng) 目是否繼續(xù)進(jìn)行下去。3．制定項(xiàng)目計(jì)劃 在確定項(xiàng)目可以進(jìn)行以后，接著需要針對(duì)項(xiàng)目的開(kāi)展，從人員、組織、進(jìn)度、資金、設(shè)備等多個(gè)方面進(jìn)行合理的規(guī)劃，并以“項(xiàng)目開(kāi)發(fā)計(jì)劃書(shū)”的形式提交書(shū)面報(bào)告。4．軟件需求分析 軟件需求分析是軟件規(guī)格描述的具體化與細(xì)節(jié)化，是軟件定義時(shí)期需要達(dá)到的目標(biāo)。需求分析要求以用戶(hù)需求為基本依據(jù)，從功能、性能、數(shù)據(jù)、操作等多個(gè)方面，對(duì)軟件系統(tǒng)給出完整、準(zhǔn)確、具體的描述，用于確定軟件規(guī)格。其結(jié)果將以“軟件需求規(guī)格說(shuō)明書(shū)”的形式提交。在軟件項(xiàng)目進(jìn)行過(guò)程中，需求分析是從軟件定義到軟件開(kāi)發(fā)的最關(guān)鍵步驟，其結(jié)論不僅是今后軟件開(kāi)發(fā)的基本依據(jù)，同時(shí)也是今后用戶(hù)對(duì)軟件產(chǎn)品進(jìn)行驗(yàn)收的基本依據(jù)。軟件開(kāi)發(fā)期 在對(duì)軟件規(guī)格完成定義以后，接著可以按照“軟件需求規(guī)格說(shuō)明書(shū)”的要求對(duì)軟件實(shí)施開(kāi)發(fā)，并由此制作出軟件產(chǎn)品。這個(gè)時(shí)期需要分階段地完成以下幾項(xiàng)工作。1．軟件概要設(shè)計(jì) 概要設(shè)計(jì)是針對(duì)軟件系統(tǒng)的結(jié)構(gòu)設(shè)計(jì)，用于從總體上對(duì)軟件的構(gòu)造、接口、全局?jǐn)?shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)環(huán)境等給出設(shè)計(jì)說(shuō)明，并以“概要設(shè)計(jì)說(shuō)明書(shū)”的形式提交書(shū)面報(bào)告，其結(jié)果將成為詳細(xì)設(shè)計(jì)與系統(tǒng)集成的基本依據(jù)。模塊是概要設(shè)計(jì)時(shí)構(gòu)造軟件的基本元素，因此，概要設(shè)計(jì)中軟件也就主要體現(xiàn)在模塊的構(gòu)成與模塊接口這兩個(gè)方面上。結(jié)構(gòu)化設(shè)計(jì)中的函數(shù)、過(guò)程，面向?qū)ο笤O(shè)計(jì)中的類(lèi)、對(duì)象，它們都是模塊。概要設(shè)計(jì)時(shí)并不需要說(shuō)明模塊的內(nèi)部細(xì)節(jié)，但是需要進(jìn)行全部的有關(guān)它們構(gòu)造的定義，包括功能特征、數(shù)據(jù)特征和接口等。在進(jìn)行概要設(shè)計(jì)時(shí)，模塊的獨(dú)立性是一個(gè)有關(guān)質(zhì)量的重要技術(shù)性指標(biāo)，可以使用模塊的內(nèi)聚、耦合這兩個(gè)定性參數(shù)對(duì)模塊獨(dú)立性進(jìn)行度量。2．軟件詳細(xì)設(shè)計(jì) 設(shè)計(jì)工作的第二步是詳細(xì)設(shè)計(jì)，它以概要設(shè)計(jì)為依據(jù)，用于確定軟件結(jié)構(gòu)中每個(gè)模塊的內(nèi)部細(xì)節(jié)，為編寫(xiě)程序提供最直接的依據(jù)。詳細(xì)設(shè)計(jì)需要從實(shí)現(xiàn)每個(gè)模塊功能的程序算法和模塊內(nèi)部的局部數(shù)據(jù)結(jié)構(gòu)等細(xì)節(jié)內(nèi)容 3 上給出設(shè)計(jì)說(shuō)明，并以“詳細(xì)設(shè)計(jì)說(shuō)明書(shū)”的形式提交書(shū)面報(bào)告。3．編碼和單元測(cè)試 編碼是對(duì)軟件的實(shí)現(xiàn)，一般由程序員完成，并以獲得源程序基本模塊為目標(biāo)。編碼必須按照“詳細(xì)設(shè)計(jì)說(shuō)明書(shū)”的要求逐個(gè)模塊地實(shí)現(xiàn)。在基于軟件工程的軟件開(kāi)發(fā)過(guò)程中，編碼往往只是一項(xiàng)語(yǔ)言轉(zhuǎn)譯工作，即把詳細(xì)設(shè)計(jì)中的算法描述語(yǔ)言轉(zhuǎn)譯成某種適當(dāng)?shù)母呒?jí)程序設(shè)計(jì)語(yǔ)言或匯編語(yǔ)言。為了方便程序調(diào)試，針對(duì)基本模塊的單元測(cè)試也往往和編碼結(jié)合在一起進(jìn)行。單元測(cè)試也以“詳細(xì)設(shè)計(jì)說(shuō)明書(shū)”為依據(jù)，用于檢驗(yàn)每個(gè)基本模塊在功能、算法與數(shù)據(jù)結(jié)構(gòu)上是否符合設(shè)計(jì)要求。4．系統(tǒng)集成測(cè)試 所謂系統(tǒng)集成也就是根據(jù)概要設(shè)計(jì)中的軟件結(jié)構(gòu)，把經(jīng)過(guò)測(cè)試的模塊，按照某種選定的集成策略，例如漸增集成策略，將系統(tǒng)組裝起來(lái)。在組裝過(guò)程中，需要對(duì)整個(gè)系統(tǒng)進(jìn)行集成測(cè)試，以確保系統(tǒng)在技術(shù)上符合設(shè)計(jì)要求，在應(yīng)用上滿(mǎn)足需求規(guī)格要求。5．系統(tǒng)確認(rèn)驗(yàn)證 在完成對(duì)系統(tǒng)的集成之后，接著還要對(duì)系統(tǒng)進(jìn)行確認(rèn)驗(yàn)證。系統(tǒng)確認(rèn)驗(yàn)證需要以用戶(hù)為主體，以需求規(guī)格說(shuō)明書(shū)中對(duì)軟件的定義為依據(jù)，由此對(duì)軟件的各項(xiàng)規(guī)格進(jìn)行逐項(xiàng)地確認(rèn)，以確保已經(jīng)完成的軟件系統(tǒng)與需求規(guī)格的一致性。為了方便用戶(hù)在系統(tǒng)確認(rèn)期間能夠積極參入，也為了系統(tǒng)在以后的運(yùn)行過(guò)程中能夠被用戶(hù)正確使用，這個(gè)時(shí)期往往還需要以一定的方式對(duì)用戶(hù)進(jìn)行必要的培訓(xùn)。在完成對(duì)軟件的驗(yàn)收之后，軟件系統(tǒng)可以交付用戶(hù)使用，并需要以“項(xiàng)目開(kāi)發(fā)總結(jié)報(bào)告”的書(shū)面形式對(duì)項(xiàng)目進(jìn)行總結(jié)。

軟件運(yùn)行與維護(hù)期 軟件系統(tǒng)的運(yùn)行是一個(gè)比較長(zhǎng)久的過(guò)程，跟軟件開(kāi)發(fā)機(jī)構(gòu)有關(guān)的主要任務(wù)是對(duì)系統(tǒng)進(jìn)行經(jīng)常性的有效維護(hù)。軟件的維護(hù)過(guò)程，也就是修正軟件錯(cuò)誤，完善軟件功能，由此使軟件不斷進(jìn)化升級(jí)的過(guò)程，以使系統(tǒng)更加持久地滿(mǎn)足用戶(hù)的需要。因此，對(duì)軟件的維護(hù)也可以看成為對(duì)軟件的再一次開(kāi)發(fā)。在這個(gè)時(shí)期，對(duì)軟件的維護(hù)主要涉及三個(gè)方面的任務(wù)，即改正性維護(hù)、適應(yīng)性維護(hù)和完善性維護(hù)。2．瀑布模型 瀑布模型誕生于20世紀(jì)70年代，是最經(jīng)典的并獲得最廣泛應(yīng)用的軟件過(guò)程模型。瀑布模型中的“瀑布”是對(duì)這個(gè)模型的形象表達(dá)，即山頂傾瀉下來(lái)的水，自頂向下、逐層細(xì)化。（1）特點(diǎn)：線(xiàn)性化模型、階段具有里程碑特征、基于文檔的驅(qū)動(dòng)、階段評(píng)審機(jī)制。（2）作用：為軟件項(xiàng)目按規(guī)程管理提供了便利，為其他過(guò)程模型的推出提供了一個(gè)良好的 拓展平臺(tái)。（3）局限性：主要適合于需求明確且無(wú)大的需求變更的軟件開(kāi)發(fā)，但不適合分析初期需求 模糊的項(xiàng)目。3．原型模型（1）快速原型方法：是原型模型在軟件分析、設(shè)計(jì)階段的應(yīng)用，用來(lái)解決用戶(hù)對(duì)軟件系統(tǒng)在需求上的模糊認(rèn)識(shí)，或用來(lái)試探某種設(shè)計(jì)是否能夠獲得預(yù)期結(jié)果。（2）原型進(jìn)化模型：針對(duì)有待開(kāi)發(fā)的軟件系統(tǒng)，先開(kāi)發(fā)一個(gè)原型給用戶(hù)使用，然后根據(jù)用 戶(hù)的使用意見(jiàn)，對(duì)原型不斷修改，使它逐步接近，并最終到達(dá)開(kāi)發(fā)目標(biāo)。