第一篇：學習體會：高教自考軟件工程課程概說總結

學習體會：高教自考軟件工程課程概說總結

未接觸軟件工程之前一直都很想學這門課程，因為覺得這門課很NB，是那些有工程師稱號的高手才擺弄的東西。但學過之后，最大的感觸卻是：軟件工程方法一定要從娃娃抓起，否則到了后面壞習慣已經養(yǎng)成后再回過頭來修正，那絕對是地獄般的磨難。下面就是我在近兩個月的學習中一些總結和體會，希望對后來者有所補益。由于是初學這門課程，難免淺薄和有所錯漏，還望大家多多指教。軟件工程的由來

據說上個世紀60年代的程序員都是天才，寫程式就像寫日記一樣，吃過晚飯沒事干隨手就可以寫幾個出來玩，第二天還可以拿去賣錢。所以那時候程序員在大家眼中，跟那些搞美術，音樂的是一類的，被稱為“藝術家”。

但事過境遷，就像任何人都不會嫌錢多一樣，永遠都不會有人嫌CPU快的。于是，隨之而來的就是硬件的迅猛發(fā)展和越來越變態(tài)的軟件。記得以前常去同學家拷游戲，通常幾張軟盤就可以搞定，而現(xiàn)在的游戲，兩三張CD-ROM都算少的了。像如此龐大復雜的怪物，就算你是如何的天才，一個人肯定是搞不定的，否則，等你把程式寫出來，人家Intel連奔騰N都開發(fā)出來了。既要開發(fā)大型的軟件還要追求速度(這樣才能賺錢)，于是很自然地，合作的概念被提了出來。

在開始合作的初期，由于大家都習慣了當很有個性的“藝術家”，結果可想而知，一個是畢加索派的，而另一個是意大利印象派的，再加上一個畫潑墨山水畫的，要是像這樣湊出來的東西都能不出問題的話，那么Bill早就轉行了。所以，那時侯的大型軟件，據說“藍屏”比WINDOWS 98還多。

馬克思告訴我們，萬物都是從量變到質變的。隨著問題的不斷涌現(xiàn)，一些master們開始嘗試去總結經驗，并歸納了一些規(guī)范去指導軟件的分析，設計，實現(xiàn)，測試，維護，人員交流協(xié)作，項目預算及時限控制等方方面面，這就是軟件工程的前身。

軟件工程到現(xiàn)在已發(fā)展了30多年，可以說是相當成熟的了?，F(xiàn)在開發(fā)軟件，據說都是一大幫人排排坐，按著一整套的規(guī)章制度來干活。于是，軟件開發(fā)成了“工程”，程序員也就淪為“工人”了。

最初提出問題的是Dijkstra.他于1968年寫給ACM的一封題為Goto Statement

Considered Harmful 的信中，指出了GOTO語句的負面作用，并提出了解決之道，其引發(fā)的一系列效應最終帶來了軟件工程的誕生。

軟件工程的核心

無論是在上個世紀還是在現(xiàn)在，軟件開發(fā)所涉及的工作基本上都沒有變化，它們都起始于一個實際需要或某個靈感，然后就是分析，設計，編碼，調試，維護。這些任務以某種方式動態(tài)地結合起來就構成了軟件開發(fā)的整個過程，這就是所謂的“軟件開發(fā)周期”。

但對于這些工作，具體怎樣做，什么時候做，每個人都有自己的一套方式，甚至有的人有幾套方式。這樣，當幾個人合在一起干活的時候，最終的結果就只能是一片混亂。所以就需要一套規(guī)則，大家都按規(guī)則來辦事，問題就會少得多。好的規(guī)則就叫做規(guī)范，規(guī)范都是由一些master們根據經驗總結的，又經過長時間的歷練，不斷地被補充修正，可以說都是精華，按照規(guī)范來干活，對于提高軟件質量和工作效率自然大有幫助。

而軟件工程，說白了，就是這樣一套用于軟件的團隊開發(fā)，以提高軟件質量和程序員工作效率為目的的規(guī)范。其核心就是，對于軟件開發(fā)的5個重要組成部分：需求分析，設計，編碼，調試，維護，如何組織這5個部分的工作，以及如何完成每一個工作。簡單來說，就是對于總體的組織和對于局部的實現(xiàn)。

規(guī)范只是提供一個好的例子，以描述一種思想，具體到每一個環(huán)節(jié)怎樣實現(xiàn)，對于不同的公司或團體則是各有千秋，因為根本就不可能存在一套放之天下皆可行的標準。就像C++，也只是提供了一套標準，不同的編譯器都有各自的實現(xiàn)，對標準的支持程度也互不相同。所以，在不同的公司或團體中，盡管核心思想都是大同小異，但具體到每一個步驟，往往都是不相同的。我手上就有一份GB8567-88的文檔模板，對于那些頂多只有幾千行的小程序來說，假如真按上面的要求全寫上了，簡直就是一種折磨！據說，當前業(yè)界最權威的標準是CMM.軟件開發(fā)過程的組織如何組織軟件開發(fā)過程中的每一個步驟，就是軟件開發(fā)周期模型要解決的問題。

其實開發(fā)軟件，就像是解決一個邏輯問題。想想自己平時是怎樣寫程序的。首先是要有一個想法，即我寫的這個程序是要干什么的；然后就是對要實現(xiàn)的核心功能大概構思一種或多種實現(xiàn)方法，并從中選出一種自認為是較好的；接下來就是將涉及的各種主要或次要功能分成各個模塊；最后就是分模塊來編碼和DEBUG.在我看來，除了第一步外，其余的步驟應該是一個循環(huán)的過程。在編碼的過程中，你總是需要不斷地回過頭來修改原先的模塊設計，甚至最初選定的實現(xiàn)算法。例如，最簡單的情況是，你通常都會突然發(fā)現(xiàn)在兩個成員函數中有相同的代碼，這時，程序員的直覺告訴你，你應該為你的類再添加一個private成員函數并將公共的代碼放于其中；又或者是，你突然發(fā)現(xiàn)一個模塊中的某個功能具有很高的通用性，完全可以提取出來作為一個獨立的功能組件，而你也確實應該這樣做；要是倒霉一點的話，你很有可能會在最后調試的時候突然發(fā)現(xiàn)，你的程序跑得太慢了，連你自己都無法忍受。于是你找呀找，終于找到了80/20中的那段可惡的20，原來是用了一個O(N)的算法，這時你就得老老實實地換一個更好的算法。

總之，除非你是先知，否則，對于一個具有一定規(guī)模和復雜度的軟件來說，在“設計—編碼”這個過程中，實在有太多的不可預知性和變化性，你根本不可能全盤地把握住每一個細節(jié)。當然，這是建立在我現(xiàn)時的水平之上的觀點。我不知道是否成為高手以后會有所不同，因為我身邊沒有那樣的人。

既然軟件開發(fā)是一個具有不可預知性和變化性的動態(tài)的過程，那么，對其每一個步驟的組織，即周期模型，就必須包容它的這種性質。

現(xiàn)在來看一下最古老，最經典，同時也是最倍受批評的瀑布模型。

瀑布模型是一種線性模型，其最大的特點就是簡單直觀。它將軟件開發(fā)過程規(guī)劃為“分析—設計—編碼—測試—維護”的線性過程，也就是說，你必須首先把你的軟件要干的每一件工作都分析得徹徹底底，再對每一個模塊，每一個接口，事無巨細，都設計得非常完美，然后才開始編碼的工作，并且在編碼的時候就像在對著圖紙砌模型，根本不用再回頭作任何修改，當然，是在把所有的代碼都寫完以后才開始測試的。

整個過程，光想一下就覺得冒冷汗！

瀑布模型完全忽視了軟件開發(fā)過程的動態(tài)變化。恐怕只有那些已經發(fā)展得非常成熟，且規(guī)模不大的系統(tǒng)，例如：用Access做后臺，用VB畫前端的數據庫應用程序，才有瀑布模型一展拳腳的地方。

相比之下，現(xiàn)在常用的一些周期模型則更接近于人的自然思維，例如螺旋模型就是一種我比較喜歡的模型。

軟件開發(fā)過程的實現(xiàn)

具體到每一步的工作要怎樣完成，我前面已提到過，是非常靈活的，只要把握住大體的方向就行。在進行分析，設計，編碼，調試，維護這幾部分的工作的時候，最核心的就是文檔的編寫。文檔的作用在于以下3個方面：一是可以幫助整理思路。把要完成的目標，系統(tǒng)的結構，每一個模塊的功能等整理一下，然后分門別類地寫下來，這樣在開發(fā)的過程中，就有據可依，在需要回過頭來修改設計的時候，也有證可考。二是便于交流。想象一下開會時的情形。一大幫子人爭先恐后，激烈辯論，然后會終人散，思想靈感也就隨之散了，結果是開了半天會，什么也沒討論出來。這就是后來會議記錄被發(fā)明出來的原因。在腦子里的東西一多，就會散而且亂，用語言表達的時候，很容易會丟三落四，別人也很難把握住你的思想。但經過整理寫在紙上以后，則會清晰得多，無論是別人還是自己，看起來都可以一目了然。三是可以作為以后維護時的參考資料。有一句名言：“筆和紙永遠都比大腦可靠”，意思就是說，放在大腦里的東西說不準哪天就忘了，但寫在紙上的東西，只要不發(fā)生什么意外，一般是丟不了的。當過了一段時間，你需要再回過頭來修改你的程序的時候，你就會發(fā)現(xiàn)，你以前寫下的文檔實在太有價值了。別指望你的源代碼，對于復雜一點的程序來說，單純的源代碼幾乎會扼殺掉你所有的時間。

至于文檔怎樣寫，教科書上大多都是一條一條列得滿滿的，就像一些地方政府的規(guī)章制度一樣，其實大可不必，只要能滿足需要就行。如果是在公司，則每個公司大多都有一套自己內部的文檔模板，個人沒有選擇的余地。而對于像我這種業(yè)余的，寫個程序除了練練手藝，無非就是供自己和親朋好友玩玩，則根本沒必要搞得過于復雜。以下就是我自己的一份文檔模板的概要，麻雀雖小，但五臟俱全。

可行性分析 就是關于當前項目能不能干的分析結果。主要考慮的方面包括：是否能把這個項目開發(fā)出來；假如可以的話，預計需要多少時間，能否滿足客人的時間要求；需要多少人力和資金的投入；最重要的是，這個項目能否賺錢，能賺多少。還要對可能存在的風險進行評估，例如，萬一項目主管被車撞了要怎么辦。當然，這對于我來說毫無意義，我在這里寫上只是為了保持完整而已。

項目描述 這是在決定立項以后，對當前項目的一份扼要說明。必須包括以下幾個方面：

(1)項目的名稱或編號；(2)對客戶方的描述；(3)對開發(fā)人員的描述；(4)工程任務的描述；(5)工程的輸入和輸出；(6)開發(fā)環(huán)境；(7)其他的附加條件。在這里，對工程任務的描述是從整體的角度來說的，例如：能對當前的象棋棋局進行分析并作出最優(yōu)決策的人工智能系統(tǒng)。而工程的輸入輸出則可以這樣

第二篇：自考軟件工程總結

何謂科學，何謂工程？（第一章）

科學是反映自然、社會、思維的發(fā)展與變化規(guī)律的知識體系。科學（研究）是以發(fā)現(xiàn)為核心的人類活動，探索事物的本質和運動規(guī)律，追求真理，認識世界，回答“為什么”，體現(xiàn)非物質形態(tài)財富。

工程是與生產、建設相關，運用自然科學理論和技術原理得以實現(xiàn)的活動（狹）。以構建、運行與集成為核心的人類活動，遵循社會需求，追求一定條件下的集成與綜合優(yōu)化。

2什么是可移植性（方法）？P347

把一個程序從一個硬件或軟件系統(tǒng)環(huán)境移植到另一個環(huán)境所需的工作量。

3什么是軟件生存周期？p7

軟件生存周期是軟件產品從形成概念，經過開發(fā)、使用和維護直至最后退役的全過程。大致分為如下6個階段計算機系統(tǒng)工程、需求分析、設計、編碼、測試、運行和維護

4.什么是可維護性p347

定位和修復程序中一個錯誤所需的工作量。

5文檔功能是記錄軟件-____開發(fā)___活動和階段成果，能供人和機器閱讀，是有永久保存屬性。

6.計算機軟件是指與計算機系統(tǒng)有關的程序、規(guī)則、規(guī)程有任何與之有關的文檔和數據。包括機器可執(zhí)行的程序及有關數據；機器不可執(zhí)行的與軟件開發(fā)、運行、維護、使用和培訓有關的文檔。P1 程序：用程序設計語言描述的，計算機能夠處理的語言序列。

文檔：一種數據媒體及其上所記錄的數據。文檔（功能/作用）記錄軟件開發(fā)活動和階段成果，能供人和機器閱讀，具有永久保存屬性。

7軟件開發(fā)包括哪些階段，主要解決什么問題？P19

概念定義，具體包括計劃和需求分析階段，主要解決做什么的問題。

開發(fā)，具體包括設計，編碼，測試階段，主要解決怎么做的問題。

使用維護，即運行維護階段，包括些交付、安裝、運行、維護和退役等。

8.軟件概念定義包括那三部分，主要解 決什么問題。P4P1

（英文：Software）是一系列按照特定順序組織的計算機數據和指令的集合。一般來講劃分為系統(tǒng)軟件、支撐軟件和應用軟件。

9軟件需求是指用戶對目標系統(tǒng)在功能、行為、性能、設計、約束等方面的 期望P48

10.什么是模塊？

模塊指具有一定功能的可以用名字調用的程序語句集合。

模塊化是指把一個待開發(fā)的軟件劃分成若干小的簡單部件，每個部件稱為一個模塊，每個模塊完成一個相對獨立的一個子功能，所有這些模塊集成起來就可以完成軟件系統(tǒng)的指定功能，滿足問題的要求。P66 模塊化的目的是使程序的結構清晰，易閱讀、易測試和修改。采用模塊化方法，可以控制復雜問題的求解規(guī)模，減低問題復雜度和減少求解成本。

11什么 模塊耦合度，什么是模塊內聚度？P68

耦合是一個軟件結構內不同模塊彼此之間互相連接（依賴）的緊密程度。

耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。耦合度衡量不同模塊彼此間相互依賴的緊密程度。

內聚是一個模塊內部各個元素彼此結合的緊密程度。好內聚的模塊只做一件事情。內聚度衡量同一個模塊內部的各個元素彼此結合的緊密程度。

模塊的獨立性可以由兩項指標來衡量：內聚度與耦合度。.結構圖最主要的質量指標是模塊的 內聚度和 偶合度。（第五章）

13在設計用戶界面（也稱人機界面）的過程中，幾乎總會遇到系統(tǒng)響應時間，用戶求助機制，出錯--信息處理和命令交互方式四個方面的問題。P242

14.什么是系統(tǒng)響應時間？P242

系統(tǒng)響應時間指從用戶執(zhí)行某個控制動作（如按回車鍵或單擊鼠標）到軟件做出響應（期望的輸出或動作）的時間。

15簡答有哪三類人機界面設計指南（黃金原則）？p243

讓用戶擁有控制權；減少用戶的記憶負擔；保持界面一致

16.簡述什么是編碼？第十章P251

編碼就是把軟件設計結果翻譯成用某種程序設計語言書寫的程序。

17何謂程序設計風格或編碼風格？P255

程序設計風格指一個人編制程序時所表現(xiàn)出來的特點,習慣邏輯思路等.在程序設計中要使程序結構合理、清晰，形成良好的編程習慣，對程序的要求不僅是可以在機器上執(zhí)行，給出正確的結果，而且要便于程序的調試和維護，這就要求編寫的程序不僅自己看得懂，而且也要讓別人能看懂。

包括4個方面：源程序文檔化、數據說明、語句結構、和輸入輸出。256

編寫規(guī)則：文檔化、結構化、模塊化、節(jié)簡化、簡單化、格式化。

18.為一個開發(fā)項目選擇程序設計語言時，通常會考慮 項目所屬的領域 ；算法和計算復雜性；軟件運行環(huán)境；用戶需求中關于性能方面的要求；數據結構的復雜性，軟件開發(fā)人員的知識水平因素。P255 19軟件測試的目標是什么？P263PPT 第11章

軟件測試就是在軟件投入生產性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤，進而改正錯誤的過程。發(fā)現(xiàn)和改正錯誤越多，交付的軟件就質量越高，后期糾錯性維護就越少。測試是一項很艱苦的工作，也是一項“建設性”活動

測試目標1.期望用最少的時間和人力找出軟件中潛在的各種錯誤和缺陷 2.證明軟件的功能和性能與規(guī)格說明的吻合程度3.為可靠性分析提供依據 4.通常測試每一種可能情況是不現(xiàn)實的5.沒有發(fā)現(xiàn)程序中的錯誤，并不能證明軟件沒有錯誤

20.基本路徑測試的基本思想是什么？P273程序環(huán)路復雜性有什么意義？PPT 第11章

基本思想：根據軟件詳細設計或代碼中的控制結構流程確定復雜度，然后以該復雜度定義執(zhí)行路徑的基本集合，并由此導出一組測試用。

程序的環(huán)路復雜性確定程序基本路徑集合中的獨立路徑條數。獨立路徑是指包括一組以前沒有處理的語句或條件的一條路徑。用流圖術語描述，一條獨立路徑至少包含一條在其他獨立路徑中從沒有過的邊的路徑。21簡析等價類劃分法？P277PPT 第11章

等價類劃分法是把程序的輸入數據集合按輸入條件劃分成若干個等價類，每一個等價類相對于輸入條件表示為一組有效或無效的輸入，然后據此為每一個等價類設計一個測試用例。

22.簡述驅動模塊和樁模塊的作用？ PPT 第11章

驅動模塊調用被測模塊，接收測試輸入數據并把這些數據傳送給被測試的模塊，被測模塊調用后，驅動模塊接受被測模塊的返回數據。

樁模塊也叫存根模塊，它代替被測試的模塊所調用的模塊。樁模塊使用被它代替的模塊的接口，但內部只做少量的數據操作，并且把控制和模擬結果歸還給調用它的模塊。

23為何要引入驅動模塊和樁模塊？ PPT 第11章

驅動模塊和樁模塊是測試使用的軟件，它們不是軟件的組成部分，但需要一定的開發(fā)費用。簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，只能在集成測試過程中同時完成對這些模塊的詳盡測試。

引用驅動模塊和樁模塊原則有：單元測試通常與編碼工作結合起來，通常，模塊本身不是一個獨立的程序，因此在測試模塊中必須為每一個被測模塊開發(fā)一個（引用）驅動模塊和若干個樁模塊。

24．何謂調試？ PPT 第11章

調試,又名排錯,它是根據測試出問題的外部現(xiàn)象（又名錯誤或外錯），分析找出問題的內在原因（又名故障或內錯）并加以改正的代碼執(zhí)行與人工活動。調試的任務就是確定錯誤的準確位置（定位錯誤）、分析引發(fā)錯誤的原因，最終排除錯誤。

黑盒測試（行為測試）檢查程序功能是否符合按照規(guī)格說明書的規(guī)定，測試只在程序界面上進行。包括等價類劃分、邊界值分析、比較測試、錯誤猜測何因果圖方法。

白盒測試（結構測試）檢驗程序中的每條邏輯通路能否都按預定要求正確工作，測試按照程序內部的邏輯進行。包括邏輯覆蓋測試、基本路徑測試、數據流測試和循環(huán)測試。

25旅行社把預定機票的旅客信息，如姓名、年齡、單位、身份證號、旅行時間、目的地等輸入預定機票系統(tǒng)，系統(tǒng)為旅客安排航班，打印出取票通知單（附有應交的賬款）旅客在飛機起飛前交付票款，系統(tǒng)檢查無誤后，輸出機票給旅客。

試用結構化分析方法描述系統(tǒng)的邏輯模型（系統(tǒng)的功能需求）并建立相應的數據字典，要求數據字典中至少包括一個數據流、一個數據文件、一個加工的詳細的定義。

26.為方便儲戶，某銀行擬開發(fā)計算機儲蓄管理系統(tǒng)，儲戶填寫的存款單或取款單由銀行柜臺業(yè)務員鍵入系統(tǒng)，如果是存款，系統(tǒng)記錄存款人姓名，住址，存款日期，利率等信息，并印出存款單給儲戶；如果是取款，系統(tǒng)進行取款處理并印出結算單給儲戶，請用結構化分析方法描述系統(tǒng)的邏輯模型(系統(tǒng)的功能需求)，并建立相應的數據字典，要求數據字典中至少包括一個數據流，一個文件和一個加工的詳細定義。

第三篇：自考軟件工程筆記總結

第一章 緒論

1.1 軟件工程的產生

1.1.1 軟件的特點

軟件的定義：計算機程序及其說明程序的各種文檔 軟件的特性：

(1)軟件是一種邏輯產品，它與物質產品有很大的區(qū)別

(2)軟件產品的生產主要是研制，軟件產品的成本主要體現(xiàn)在軟件的開發(fā)和研制上，軟件開發(fā)研制完成后，通過復制就產生了大量軟件產品

(3)軟件產品不會用壞，不存在磨損、消耗問題

(4)軟件產品的生產主要是腦力勞動，還未完全擺脫手工開發(fā)方式，大部分產品是“定做”的

(5)軟件費用不斷增加，軟件成本相當昂貴

1.1.2 軟件生產的發(fā)展

1)程序設計時代（1946年~1956年）

這個階段的生產方式是個體手工勞動，使用的工具是機器語言、匯編語言。

開發(fā)方法是追求編程技巧，追求程序運行效率 程序難讀、難懂、難修改

硬件特征是價格貴、存儲容量小、運行可靠性差

軟件特征是只有程序、程序設計概念，不重視程序設計方法 2)程序系統(tǒng)時代（1956年~1968年）

這個階段的生產方式是作坊式的小集團合作生產，生產工具是高級語言

開發(fā)方式仍舊靠個人技巧，但開始提出結構化方法

硬件特征是速度、容量、工作可靠性有明顯提高，價格降低，銷售有爆炸性增長

軟件特征是程序員數量猛增，大量其他行業(yè)人員進入這個行業(yè)，因為缺乏訓練，因而開發(fā)人員素質差

這時已意識到軟件開發(fā)的重要性，但開發(fā)技術沒有新的突破，大量軟件開發(fā)的需求已提出，但開發(fā)人員的素質和落后的開發(fā)技術不適應規(guī)模大、結構復雜的軟件開發(fā)，產生了尖銳的矛盾，導致了軟件危機的產生

3)軟件工程時代（1968年至現(xiàn)在）

這階段的生產方式是工程化的生產，使用數據庫、開發(fā)工具、開發(fā)環(huán)境、網絡、分布式、面向對象技術來開發(fā)軟件

硬件特征是向超高速、大容量、微型化以及網絡化方向發(fā)展

軟件特征是開發(fā)技術有很大進步，但是未能獲得突破性進展，軟件價格不斷上升，沒有完全擺脫軟件危機

1.1.3 軟件危機

1.軟件危機的產生

軟件發(fā)展到第二階段末期，軟件開發(fā)技術的進步跟不上硬件發(fā)展的速度

2.軟件危機的表現(xiàn) 1.1.4(1)經費預算經常突破，完成時間一再拖延(2)開發(fā)的軟件不能滿足用戶要求(3)開發(fā)的軟件可維護性差(4)開發(fā)的軟件可靠性差 3.軟件危機的原因

(1)軟件的規(guī)模越來越大，結構越來越復雜(2)軟件開發(fā)管理困難而復雜(3)軟件開發(fā)費用不斷增加(4)軟件開發(fā)技術落后(5)生產方式落后(6)開發(fā)工具落后 軟件工程

1968年北大西洋公約組織的工作會議上首先提出“軟件工程”的概念，要用工程化的思想來開發(fā)軟件 1.軟件工程定義

用科學知識和技術原理來定義、開發(fā)、維護軟件的一門科學 2.軟件工程的性質

軟件工程是一門綜合性的交叉學科，涉及計算機科學、工程科學、管理科學、數學等領域

計算機科學中的研究成果均可用于軟件工程，但計算機科學著重于原理和理論，而軟件工程著重于如何建造一個軟件系統(tǒng)

軟件工程要用工程科學中的觀點來進行費用估算、制定進度、制定計劃和方案

軟件工程要用管理科學的方法和原理進行軟件的生產和管理 軟禁工程要用數學的方法建立軟件開發(fā)中各個種模型和各種算法 3.軟件工程目標

目的是成功的建造一個大型軟件系統(tǒng) 所謂成功，是要達到

付出較低的開發(fā)成本

達到要求的軟件功能

取得較好的軟件性能

開發(fā)的軟件易于移植

需要較低的維護費用

能按時完成開發(fā)任務，及時交付使用

開發(fā)的軟件可靠性高 4.軟件工程內容

主要是軟件開發(fā)技術和軟件管理兩個方面

軟件開發(fā)技術中主要研究軟件開發(fā)方法、軟件開發(fā)過程、軟件開發(fā)工具和環(huán)境

軟件開發(fā)管理中主要研究軟件管理學、軟件經濟學、軟件心理學 5.軟件工程面臨的問題

a)軟件費用 b)軟件可靠性 c)軟件維護 d)軟件生產率 e)軟件重用

1.2 軟件工程過程和軟件生存周期

1.2.1 軟件工程過程

目的是為各種人員提供一個公共的框架，以便用相同的語言進行交流

(1)獲取過程(2)供應過程(3)開發(fā)過程(4)操作過程(5)維護過程(6)管理過程(7)支持過程 1.2.2 軟件生存周期

指一個軟件從提出開發(fā)要求開始直到該軟件報廢為止的整個過程

(1)可行性分析和項目開發(fā)計劃

必須要回答的問題是“要解決的問題是什么”，有可行的解決辦法嗎，如果有需要多少費用多少資源時間 明確項目性質 明確項目目標 明確項目規(guī)模

確定該問題有沒有可行的解決辦法 指定項目開發(fā)計劃(2)需求分析

確定軟件系統(tǒng)必須做什么

確定軟件系統(tǒng)必須具備哪些功能(3)概要設計

把確定的各項功能需求轉換成需要的體系結構 設計軟件的結構，明確該結構的模塊組成(4)詳細設計

為每個模塊完成的功能進行具體描述，把功能描述轉變?yōu)榫_地、結構化的過程描述(5)編碼

把每個模塊的控制結構轉換成計算機可接受的程序代碼，即寫成以某種特定程序設計語言表示的“原程序清單”(6)測試

保證軟件質量的重要手段(7)維護

1.3 軟件生存周期模型、方法和工具

1.3.1 軟件生存周期模型

描述軟件開發(fā)過程中各種活動如何執(zhí)行的模型 1.瀑布模型

將軟件生存周期各個活動規(guī)定為依線性順序連接的若干階段的模型 包括所有的軟件生存周期環(huán)節(jié)，規(guī)定了由前至后、相互銜接的固定次序 1.3.2 缺點：

理想的線性開發(fā)模式，缺乏靈活性

開發(fā)過程中用戶看不到軟件是什么樣子，造成開發(fā)方向錯誤 2.增量模型

一種非整體開發(fā)的模型，軟件在該模型中是“逐漸”開發(fā)出來的，開發(fā)一部分展示一部分，可以及早發(fā)現(xiàn)問題。或者開發(fā)一個“原型”軟件，完成部分主要功能再逐步完善

具有較大的靈活性，適合于軟件需求不明確、設計方案有一定風險的軟件項目 缺點：

對于復雜的大型軟件，開發(fā)一個原型往往達不到要求 3.螺旋模型

將瀑布模型與增量模型結合起來，加入了兩種模型均忽略了的風險分析

開發(fā)過程分為幾個螺旋周期，每個螺旋周期大致和瀑布模型相符合 每個周期內分四個工作不：制定計劃、風險分析、開發(fā)實施、用戶評估

適合于大型軟件的開發(fā) 缺點：

需要有相當豐富的風險評估經驗和專門知識，使得應用受到一定限制 4.噴泉模型

一種以用戶需求為動力，以對象作為驅動的模型，適合于面向對象的開發(fā)方法

克服了瀑布模型不支持軟件重用和多想開發(fā)活動集成的局限性 是開發(fā)過程具有迭代性和無間隙性 5.基于知識的模型

又稱只能模型，它把瀑布模型和專家系統(tǒng)結合在一起 還處于研究實驗階段，還未達到實用階段 6.變換模型

適合于形式化開發(fā)的模型 軟件開發(fā)方法

使用早已定義好的技術集和符號表示習慣來組織軟件生產的過程 1.結構化方法

由結構化分析，結構化設計、結構化程序設計構成，是一種面向數據流的開發(fā)方法。簡單實用，應用較廣，技術成熟 2.Jackson方法

面向數據結構的開發(fā)方法 3.維也納開發(fā)方法（VDM）

一種形式化的開發(fā)方法，軟件需求用嚴格的形式語言描述，然后把描述模型逐步變換成目標系統(tǒng) 4.面向對象的開發(fā)方法

90年代主流

基本出發(fā)點是盡可能按照人類認識世界的方法和思維方式來分析和解決問題

包括面向對象分析、面向對象設計、面向對象實現(xiàn)

1997年推出統(tǒng)一建模語言UML，是面向對象的標準建模語言

1.3.3 軟件開發(fā)工具

1． 軟件工具的重要性

為了支持軟件人員開發(fā)和維護活動而使用的軟件

項目估算工具、需求分析工具、編碼工具、測試工具、維護工具等 2． 工具箱

將各種軟件工具簡單組合起來就構成工具箱

工具箱的工具界面不同意，工具內部無聯(lián)系，工具切換由人工操作 3． 軟件開發(fā)環(huán)境

工具系統(tǒng)的整體化及集成化，使之形成完整的軟件開發(fā)環(huán)境 使軟件工具支持整個生存周期 4． 計算機輔助軟件工程

新的軟件工具目的是實現(xiàn)軟件生存周期各個環(huán)節(jié)的自動化，主要用于軟件的分析和設計，使用這些工具開發(fā)人員可以以對話的方式建立各種軟件系統(tǒng)

計算機輔助軟件工程可以簡單的定義為軟件開發(fā)的自動化，CASE 結構化方法可以用于瀑布模型、增量模型、螺旋模型進行開發(fā) Jackson方法可以用于瀑布模型、增量模型 維也納方法只能用于變換模型進行開發(fā)

第二章 軟件可行性研究與項目開發(fā)計劃

2.1 可行性研究

目的是用最小的代價在盡可能短的時間內去確定該項目是否能夠開發(fā)，是否值得開發(fā)

在較高層次上以較抽象的方式進行需求分析和設計過程 2.1.1 可行性研究的任務

進行概要的分析研究，初步確定項目的規(guī)模和目標，確定項目的約束和限制，列舉出來。然后進行簡要的需求分析，抽象出項目的邏輯結構，建立邏輯模型，從邏輯模型出發(fā)經過壓縮的設計，探索出若干種可供選擇的解決辦法，對每種解決方法都要研究它的可行性

可以從以下三個方面分析研究每種解決方法的可行性

1.技術可行性、技術可行性一般要考慮的情況包括(1)開發(fā)的風險(2)資源的有效性(3)技術

(4)開發(fā)人員在評估技術可行性時，一旦估計錯誤，將會出現(xiàn)災難性后果

2.經濟可行性

進行開發(fā)成本的估算以及了解取得效益的評估，確定要開發(fā)的項目是否值得投資開發(fā) 3.社會可行性

要開發(fā)的項目時候存在任何侵犯、妨礙等責任問題，要開發(fā)項目的運行方式在用戶組織內是否行得通，現(xiàn)有管理制度、人員素質、操作方式是否可行

2.1.2 可行性研究的具體步驟

1.確定項目規(guī)模和目標

2.研究正在運行的系統(tǒng)

3.建立新系統(tǒng)的高層邏輯模型

使用建立邏輯模型的工具——數據流圖和數據字典描述數據在系統(tǒng)中的流動和處理情況。不是需求分析階段，不是完整詳細的描述，只是概括的描述高層的數據處理和流動

4.導出和評價各種方案

5.推薦可行的方案

6.編寫可行性研究報告

2.1.3 可行性研究報告的主要內容

1．引言

2．可行性研究前提

3．對象有系統(tǒng)的分析

4．所建議系統(tǒng)的技術可行性分析

5．所建議系統(tǒng)的經濟可行性分析

6．社會因素可行性分析

7．其他可供選擇方案

8．結論意見 2.2 系統(tǒng)流程圖

1．系統(tǒng)流程圖的作用

用圖形符號來表示系統(tǒng)中的各個元素。表達了系統(tǒng)中各個元素之間的心理流動的情況

2．系統(tǒng)流程圖的符號

3．系統(tǒng)流程圖的例子

2.3

成本——效益分析

目的是從經濟角度評價開發(fā)一個新的軟件項目是否可行

估算將要開發(fā)的系統(tǒng)的開發(fā)成本，與可能取得的效益進行比較和權衡 效益分有形效益和無形效益 有形效益的分析 1． 貨幣的時間價值 2． 投資回收期 3． 純收入 2.4 項目開發(fā)計劃

1．項目概述

2．實施計劃

3．人員組織及分工

4．交付期限

第三章 軟件需求分析

3.1 需求分析的任務

3.1.1 需求分析的概念

開發(fā)人員要準確的理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義裝換到相應的形式功能規(guī)約（需求規(guī)格說明）的過程 需求分析的難點：(1)問題的復雜性(2)交流障礙

(3)不完備性和不一致性(4)需求易變性

軟件需求分析與說明的方法適用的基本原則：(1)必須能夠表達和理解問題的數據域和功能域

(2)可以把一個復雜問題按功能進行分解并可逐層細化(3)建模

結構化分析方法和面向對象分析方法都遵循以上原則

3.1.2 需求分析的基本任務

要準確的定義新系統(tǒng)的目標，為了滿足用戶的需要，回答系統(tǒng)必須“做什么”的問題?？尚行匝芯亢蛙浖媱濍A段對這個問題的回答是概括的、粗略的 本階段主要進行以下幾個方面的工作： 1.問題識別

雙方確定對問題的綜合需求，這些需求包括：

(1)功能需求：所開發(fā)的系統(tǒng)必須具備什么樣的功能，這是最重要的(2)性能需求：待開發(fā)的軟件的技術性能指標。存儲容量，運行時間(3)環(huán)境需求：軟件運行時所需要的軟、硬件的要求

(4)用戶界面需求：人機交互方式、輸入輸出數據格式等等

另外還有可靠性、安全性、保密性、可移植性、可維護性等方面的需求 2.分析與綜合，導出軟件的邏輯模型

對獲取的需求，進行分析檢查，逐步細化軟件的功能，劃分成各個子功能，以確定系統(tǒng)的構成及主要成分，建立新系統(tǒng)的邏輯模型 3.編寫文檔

(1)編寫“需求規(guī)格說明書”(2)編寫初步用戶使用手冊(3)編寫確認測試計劃(4)修改完善軟件開發(fā)計劃

3.1.3 需求規(guī)格說明書主要內容 3.2 結構化分析方法

簡稱SA，是面向數據流進行需求分析的方法

3.2.1 自頂向下逐層分解的分析策略

對一個復雜問題分析人員不可能一開始就考慮到問題的所有方面及全部細節(jié)，對此采取的策略是分解，把一個復雜問題劃分成若干小問題，然后分別解決，將問題的復雜性降低到人可以掌握的程度

分解可分層進行，先考慮問題最本質的方面，忽略細節(jié)形成問題的高層概念，然后逐層添加細節(jié)。頂層抽象的概括整個系統(tǒng)，底層具體畫出系統(tǒng)的每個細節(jié)，中間層是逐步過渡

這種層次分解使分析人員分析問題時不至于一下子陷入細節(jié)，而是逐步的去了解更多細節(jié)

依照這個策略，對于任何復雜的系統(tǒng)，分析工作都可以有計劃、有步驟、有條不紊的進行

3.2.2 描述工具

SA方法的描述工具是：

(1)數據流圖(2)數據字典

(3)描述加工邏輯的結構化語言、判定表、判定樹

數據流圖描述系統(tǒng)的分解，及系統(tǒng)由哪幾部分組成，各部分之間的聯(lián)系等等 數據字典定義了數據流圖中每一個圖形元素 結構化語言、判定便或判定樹詳細描述數據流圖中不能被再分解的每一個加工

3.2.3 SA分析步驟

(1)了解當前系統(tǒng)的工作流程，獲得當前系統(tǒng)的物理模型(2)抽象出當前系統(tǒng)的邏輯模型(3)建立目標系統(tǒng)的邏輯模型(4)做進一步補充和優(yōu)化

3.3 數據流圖（DFD）

簡稱DFD，是SA方法中表示系統(tǒng)邏輯模型的一種工具，只反應系統(tǒng)必須完成的邏輯功能，所以是一種功能模型

3.3.1 基本圖形符號

數據流圖有四種基本圖形符號：

(1)數據流。是數據在系統(tǒng)內傳播的路徑，由一組成分固定的數據項組成，必須有流向，除了與數據存儲之間的數據流不用命名，其他用名詞或名詞短語命名

(2)加工（又稱為數據處理）。對數據流進行某些操作或變換。加工用動詞短語命名

(3)數據存儲（又稱為文件）。指暫時保存的數據，它可以是數據庫文件或任何形式的數據組織。流向數據存儲的數據流可以理解為寫入文件或查詢文件，流出的數據可以理解為從文件讀取數據或得到查詢結果

(4)數據源點或終點：軟件系統(tǒng)外部環(huán)境中的實體（包括人員、組織或其他軟件系統(tǒng)），統(tǒng)稱為外部實體

在一張圖上可重復畫同名的源/終點，在方框的右下角加斜線則表示是一個實體。有時數據存儲也需重復標識

3.3.2 畫數據流圖的步驟

按問題的層次結構進行逐步分解，并以一套分層的數據流圖反應這種結構關系

(1)首先畫系統(tǒng)的輸入輸出，即先畫頂層數據流圖。

頂層流圖只包含一個加工，用以表示被開發(fā)的系統(tǒng)，然后考慮系統(tǒng)的輸入輸出數據。頂層圖的作用在于表明被開發(fā)的系統(tǒng)范圍以及它與周圍化境的數據交換關系

(2)畫系統(tǒng)內部，即畫下層數據流圖。一般將層號從0開始編號，采用自頂向下，由外向內的原則。一般沿著輸入流的方向，凡數據流的組成或值發(fā)生變化的地方則設置一個加工，這樣一直進行到輸出數據流。知道每一個加工足夠簡單，不能再分解為止，不能再分解的加工稱為基本加工(3)注意事項

a)命名

b)畫數據流而不是控制流

圖中不反應加工的執(zhí)行順序 c)一般不畫物質流

d)每個加工至少有一個輸入數據流和一個輸出數據流，反映出此加工數據的來源與加工的結果 e)編號

子圖的編號就是父圖中相應加工的編號，加工的編號由子圖號，小數點和局部號組成 f)父圖與子圖的平衡

子圖的輸入輸出數據流同父圖相應加工的輸入輸出數據流必須一致 保證了數據流圖的一致性 g)局部數據存儲

h)提高數據流圖的易理解性

注意合理分解

為了使數據流圖便于在計算機上輸入與輸出，以下給出了描述數據流圖的另一套基本符號

3.3.3 實例——售票管理系統(tǒng)

3.4 數據字典（DD）

簡稱DD，用來定義數據流圖中各個成分的具體含義，它以一種準確的、無二義性的說明方式為系統(tǒng)的分析、設計及維護提供了有關元素的一致的定義和詳細的描述 它和數據流圖共同構成了系統(tǒng)的邏輯模型，是需求規(guī)格說明書的主要組成部分

3.4.1 數據字典的內容及格式

數據字典是為分析人員查找數據流圖中有關名字的詳細定義而服務的，因此也像普通字典一樣，要把所有條目按一定的次序排列起來，以便查閱 數據字典有以下四類條目： 數據流 數據項 數據存數 基本加工

數據項是組成數據流和數據存儲的最小元素。源點終點一般不在字典中說明 1.數據流條目

數據流條目給出了DFD中數據流的定義，通常列出數據流的各組成數據項

在定義數據流或數據存儲組成時，使用下表給出的符號：

2.數據存儲條目

數據存儲條目是對數據存儲的定義，主要內容舉例如下：

3.數據項條目 數據項條目是不可再分解的數據單位，其定義格式及舉例如下：

4.加工條目

加工條目是用來說明DFD中基本加工的處理邏輯的，由于上層的加工是由下層的基本加工分解而來，只要有了基本加工的說明，就可理解其他加工

加工條目的內容及舉例如下：

數據字典中的加工邏輯主要描述該加工“做什么”，即實現(xiàn)加工的策略，而不是實現(xiàn)加工的細節(jié)，它描述如何把輸入數據流變換為輸出數據流的加工規(guī)則。加工邏輯有幾種常用的描述方法，結構化語言、判定表、判定樹

3.4.2 數據字典的實現(xiàn)

建立數據字典一般有兩種形式：

1.手工建立：數據字典的內容用卡片形式存放

(1)按四類條目規(guī)范的格式印制卡片(2)在卡片上分別填寫各類條目的內容

(3)先按圖號順序排列，同一圖號的所有條目按數據流、數據項、數據存儲和數據加工的順序排列(4)同一圖號中的同一類條目（如數據流卡片）可按名字的字典順序存放，加工一般按編號順序存放

(5)統(tǒng)一成分在父圖和子圖都出現(xiàn)時，則只在父圖上定義(6)建立索引目錄

2.利用計算機輔助建立并維護(1)編制一個“字典生成與管理程序”，可以按規(guī)定的格式輸入各類條目，能對字典條目增、刪、改，能打印查詢報告和清單，能進行完整性一致性檢查。美國密執(zhí)安大學研究的PSL/PSA就是這樣一個系統(tǒng)(2)利用已有的數據庫開發(fā)工具，針對數據字典建立一個數據庫文件，可將數據流、數據項、數據存儲和加工分別以矩陣表的形式來描述各個表項的內容，如數據流的矩陣表為：

有的DBMS本身包含一個數據字典子系統(tǒng)，建庫時能自動生成數據字典

計算機輔助開發(fā)數據字典比手工建立數據字典有更多的優(yōu)點，能保證數據的一致性和完整性，使用也方便，但增加了技術難度與積極開銷

3.5 加工邏輯的描述

加工邏輯也稱為“小說明”，描述加工邏輯一般用一下三種工具：

結構化語言

判定表

判定樹

3.5.1 結構化語言

介于自然語言和形式語言之間的一種半形式語言

結構可分為外層和內層兩層：

1.外層：用來描述控制結構，采用順序、選擇、重復三種基本結構

(1)順序結構：是一組祈使語句、選擇語句、重復語句的順序排列(2)選擇結構：一般用IF——THEN——ELSE——ENDIF、CASE——OF——ENDCASE等關鍵詞(3)重復結構：一般用DO——WHILE——ENDDO、REPEAT——UNTIL等關鍵字

2.內層：一般是采用祈使語句的自然語言短語，使用數據字典中的名詞和有限的自定義詞，其動詞含義要具體，盡量不用形容詞和副詞來修飾。還可使用一些簡單的算術運算和邏輯運算符號

3.5.2 判定表

在有些情況下，數據流圖中的某個加工的一組動作依賴于多個邏輯條件的取值。這時用判定表就能夠清楚地表示復雜的條件組合與應作的動作之間的對應關系

判定表由四部分組成，用雙線分隔開四個區(qū)域：

構造一張判定表，可采取以下步驟： 1.提取問題中的條件 2.標出條件的取值

3.計算所有條件的組合數N 4.提取可能采取的動作或措施 5.制作判定表 6.完善判定表

初始的判定表可能不完善，表現(xiàn)在以下幾個方面：(1)缺少判定列中應采取的動作

(2)有冗余的判定列：兩個或多個規(guī)則中，具有相同的動作，而與它所對應的各個條件組合中有取值無關的條件

判定表能夠把在什么條件下系統(tǒng)應做什么動作準確無誤的表示出來，但不能描述循環(huán)的處理特性，循環(huán)處理還需結構化語言 例子：

3.5.3 判定樹

判定樹是判定表的變形，一般情況下它比判定表更直觀，更易于理解和使用

這三種描述加工邏輯的工具各有優(yōu)缺點

對于順序執(zhí)行和循環(huán)執(zhí)行的動作，用結構化語言描述

對于存在多個條件復雜組合的判斷問題，用判定表和判定樹 判定樹較判定表直觀易讀，判定表進行邏輯驗證較嚴格，能把所有的可能性全部都考慮到，可將兩種工具結合起來，先用判定表做底稿，在此基礎上產生判定樹

經過需求分析，開發(fā)人員已經基本上理解了用戶的要求，確定了目標系統(tǒng)的功能，定義了系統(tǒng)的數據，描述了處理這些數據的基本策略。將這些共同的理解進行整理，最后形成文檔——需求說明書

3.6 IDEF方法

IDEF方法是美國空軍在1981年針對集成化計算機輔助制造工程項目中用于進行復雜系統(tǒng)分析和設計的方法。IDEF方法分為三部分：

IDEF0：用來描述系統(tǒng)的功能活動及其聯(lián)系，建立系統(tǒng)的功能模型 IDEF1：用來描述系統(tǒng)的信息及其聯(lián)系，建立系統(tǒng)的信息模型 IDEF2：用來進行系統(tǒng)模擬，建立系統(tǒng)的動態(tài)模型

3.6.1 IDEF0的圖形表示

該方法中，將系統(tǒng)功能稱為活動，將表示系統(tǒng)功能的圖形稱為活動圖形

一個活動可以沒有輸入，但一定要有控制

3.6.2 建立功能模型的基本方法

1.確定建模的范圍、觀點及目的 2.建立系統(tǒng)的內外關系圖——A-0圖 3.建立頂層圖——A0圖 4.建立低層次的圖形

分解時，應遵循兩條原則：

首先，保持在同一水平上分解（寬度優(yōu)先），如A1，A2，A3等圖，而不是A1，A11，A111（深度優(yōu)先），可避免較高層次的變化影響較低層次，造成可能的重復工作，同時可較早的查出錯誤及遺漏

其次，對于同一水平層次上的各個方框，選擇難度最大的部分往下分解，其后分解較容易的部分

在IDEF0圖中幾個活動之間無明確的順序和時間，要注意分解時箭頭表示的上下層之間的平衡關系。

3.6.3 IDEF0方法的特點

1.采用方框和箭頭等簡單的圖形符號描述系統(tǒng)的活動和數據流，描述活動所受到的約束條件及實現(xiàn)機制 IDEF0圖宜作為正式文檔

2.采用嚴格的自頂向下、逐層分解的方式建立系統(tǒng)功能模型

因此，IDEF0是建立系統(tǒng)功能模型的有效方法。在開發(fā)CIMS——計算機集成制造系統(tǒng)的管理信息系統(tǒng)（MIS）過程中，大都采用此方法建立軟件需求分析的功能模型

3.7 結構化分析方法小結

結構化分析方法是軟件需求分析中公認的、有成效的、技術成熟、使用廣泛的一種方法，它較適合于開發(fā)數據處理型軟件的需求分析 SA方法的弱點主要表現(xiàn)在：(1)不適合描述實時控制系統(tǒng)(2)

(3)

(4)

(5)為了解決實時軟件的需求分析，提出了控制流圖（CFD）的定義，也有用描述系統(tǒng)動態(tài)行為的狀態(tài)轉換圖（STD）代替CFD SA方法使用DFD在分析與描述“數據要求”方面是有局限的

數據庫技術使許多大型數據處理系統(tǒng)中的數據都組織成數據庫的形式，DFD應與數據庫技術中的實體聯(lián)系圖（ER圖）結合起來 DFD不適合描述人機界面系統(tǒng)的需求

對于一些頻繁的人機交互的軟件系統(tǒng)，SA方法往往對這一部分用自然語言做補充，對這類系統(tǒng)可采用其它的分析方法（如面向對象分析方法）不便于實現(xiàn)自動化

SA方法可與形式化方法結合起來，形式化是軟件自動化發(fā)展的基礎 形式化方法典型的有基于模型的Z語言及VDM開發(fā)方法 需求分析的質量及效率不夠高 可以借助需求分析工具提高

第四篇：自考軟件工程問答總結

一.什么是軟件

1.滿足功能要求和性能的指令或計算機程序集合;2.處理信息的數據結構;3.描述程序功能以及程序如何操作和使用所要求的文檔;

二.軟件危機以及產生軟件危機的原因

1.軟件開發(fā)生產率提高的速度,遠遠跟不上計算機迅速普及的趨勢.軟件產品“供不應求”.2.軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升.3.軟件開發(fā)人員和用戶之間的信息交流往往很不充分,用戶對“已完成的”的軟件系統(tǒng)不滿足的現(xiàn)象經常發(fā)生.4.軟件產品的質量不容易保證.5.軟件產品常常是不可維護的.6.軟件產品的重用性差,同樣的軟件多次重復開發(fā).7.軟件通常沒有適當的文檔資料.產生軟件危機的原因可歸結為兩個重要的方面: 軟件生產本身存在的復雜性;軟件開發(fā)所使用的方法和技術.三.有哪些軟件工程方法學及其要素

1.使用最廣泛的軟件工程方法學是結構化方法學和面向對象的方法學.2.要素:方法,工具和過程.四.什么是軟件生存周期 有哪些活動

4.1軟件生存周期

一個軟件從提出開發(fā)要求開始到軟件廢棄不用的整個過程.4.2 開發(fā)活動

可行性分析和項目開發(fā)計劃,需求分析和定義,軟件設計(先后細分為:概要設計和詳細設計),編碼,測試和運行維護 4.3 各活動階段主要文檔

4.3.1可行行分析和項目開發(fā)計劃 可性行研究報告 項目開發(fā)計劃

4.3.2需求分析中的文檔 需求規(guī)格說明書 初步用戶使用手冊 確認測試計劃

修改完善的軟件開發(fā)計劃 4.3.3 概要設計階段文檔 概要設計說明書 數據庫說明書 用戶手冊

修訂的測試計劃(測試的策略,方法,步驟)4.4.4 詳細設計階段 詳細設計說明書 4.4.5 系統(tǒng)測試階段 系統(tǒng)測試計劃文檔

五.有哪些主要生命周期模型

瀑布模型,原型開發(fā)模型(快速原型模型,演化模型,增量模型),螺旋模型,噴泉模型,基于知識的模型和變化模型.5.1 瀑布模型

瀑布模型(傳統(tǒng)的軟件周期模型)嚴格遵循軟件生命周期各階段的固定順序:計劃,分析,設計,編程,測試和維護,上一階段完成后才能進入到下一階段,整個模型就像一個飛流直下的瀑布 優(yōu)點:可強迫開發(fā)人員采用規(guī)范的方法,嚴格規(guī)定了各階段必須提交的文檔;要求每一階段結束后,都要進行嚴格的評審.與它最相適應的開發(fā)方法是結構化方法.缺點:不適應用戶需求的改動.5.2 原型模型

5.2.1 快速原型模型

快速原型的用途是獲知用戶的真正需求,一旦需求確定了,原型即被拋棄.主要用于需求分析階段.不追求也不可能要求對需求的嚴格定義,而是采用了動態(tài)定義需求的方法,所以不能定義完善的文檔.特征:簡化項目管理,盡快建立初步需求,加強用戶參與和決策.具有廣泛技能水平的原型化人員是原型實施的重要保證.原型化人員應該是具有經驗與才干,訓練有素的專業(yè)人員.衡量原型化人員能力的重要標準是他是否能夠從用戶的模糊描述中快速獲取需求.5.2.2 演化模型

在快速原型模型中,原型的用途是獲知用戶的真正需求,一旦需求確定了,原型即被拋棄.而演化模型應用于整個軟件開發(fā)過程,是從初始模型逐步演化為最終軟件產品的漸進過程.也就是說,快速原型模型是一種“拋棄式”的原型化方法,而演化模型則是一種“漸進式”的原型化方法.5.2.3增量模型

增量模型主要用于設計階段,把軟件產品劃分為一系列的增量構件,分別進行設計,編程,集成和測試.新的增量構件不得破壞已經開發(fā)出來的產品 5.2.4 原型模型小結

從下面的有關原型化方法的敘述中,選擇出正確的敘述:(1)快速原型方法是一種企圖克服傳統(tǒng)軟件周期模型缺點的開發(fā)方法.(2)在用戶的數據資源沒有得到很好地組織和管理的時候,應該使用原型化方法.(3)在用戶沒有明確地肯定其需求的時候,應該使用原型化方法.(4)在用戶不希望把自己的時間花在軟件開發(fā)過程中的時候,應該使用原型化方法.(5)使用原型化方法時應該使用第三代編程語言.(6)原型化加強了開發(fā)過程中用戶的參與和決策.(7)原型化方法大致可分為三類:拋棄式,演化式和遞增式.(8)原型化方法大致可分為演化式和遞增式.(9)采用原型化方法時,軟件的開發(fā)成本較高.(10)采用原型化方法時,關鍵的因素是建立原形的速度,而不是原形運行的效率.5.3 螺旋模型

螺旋模型綜合了瀑布模型和原型模型中的演化模型的優(yōu)點,還增加了風險分析.螺旋線第一圈的開始點可能是一個概念項目.從第二圈開始,一個新產品開發(fā)項目開始了,新產品的演化沿著螺旋線進行若干次迭代,一直轉到軟件生命期結束.5.4 噴泉模型

噴泉模型主要用于描述面向對象的開發(fā)過程.噴泉一詞體現(xiàn)了面向對象開發(fā)過程的迭代和無間隙特征.六.軟件過程基礎知識 6.1 軟件過程

軟件過程是指人們用于開發(fā)和維護軟件及相關產品的一系列活動,包括軟件工程過程和軟件管理過程.6.2 評估工具

軟件過程的評估,通常采用軟件能力成熟度 模型(Capability Maturity Model,CMM).CMM1.1的5個等級(由低級到高級): 初始級

軟件過程是無序的,有時甚至是混亂的,對過程幾乎沒有定義,成功取決于個人努力,管理是反應式(消防式)的.可重復級

建立了基本的項目管理過程來跟蹤費用,進度和功能特性.制定了必要的過程紀律,能重復早先類似應用項目取得的成功.已定義級

已將軟件管理和工程兩方面的過程文檔化,標準化,并綜合成該組織的標準化軟件過程.所有項目均使用經標準,裁減的標準軟件過程來開發(fā)和維護軟件.已管理級

收集對軟件過程和產品質量的詳細度量,對軟件過程和產品都有定量的理解與控制.優(yōu)化級

加強了定量分析,通過來自過程質量反饋和來自新觀念,新技術的反饋使過程能持續(xù)不斷地改進.七.軟件工程項目管理基本知識

軟件項目管理開始于任何技術活動之前,并且貫穿于整個的軟件生命周期.軟件工程項目管理一般分為時間管理,成本管理,人力資源管理,風險管理.7.1時間管理 7.1.1 Gantt圖

是一種簡單的水平條形圖,它以水平線段表示子任務的工作階段,線段的起點和終點分別對應著子任務的起始時間,線段長度指示完成該任務所需要的時間.甘特圖的優(yōu)點:直觀簡明,易學易繪,可從圖上清楚地標出子任務間的時間對比,但它也有 缺點:

(a)不能顯示地描繪各項彼此間的依賴關系;(b)進度計劃的關鍵部分不明顯,難以判斷哪些部分應當是主攻和主控的對象;(c)計劃中有潛力的部分以及潛力的大小不明確,往往造成潛力的浪費.7.1.2 PERT網圖與關鍵路徑

PERT網圖是一個由箭頭(標識任務)和結點(標識事件)組成的有向圖.將網絡方法用于工作計劃安排的評審和檢查.開發(fā)模塊A,B,C模塊的任務網絡圖 PERT圖不僅給出了每個任務的開始時間,結束時間和完成該任務所需的時間,還給出了任務之間的依賴關系,即哪些任務完成后才能開始另一些任務,以及如期完成整個工程的“關鍵路徑”.關鍵路徑(Critical Path)是由一連串的任務所組成的鏈,距離最大的一條路徑.軟件項目的管理人員應該密切注視關鍵任務的進展情況.如果希望縮短工期,只有往關鍵任務中增加資源才會有效果.7.2成本管理

一種常用的成本估算方法是先估計完成軟件項目所需的工作量(人月數),然后根據每個人月的代價(金額)計算機軟件的開發(fā)費用: 開發(fā)費用 = 人月數×每個人月的代價

另一種方法是估計軟件的規(guī)模(通常指源代碼行數),然后根據每行源代碼的平均開發(fā)費用(包括分析,設計,編碼,測試所花的費用),計算機軟件的開發(fā)費用: 開發(fā)費用=源代碼行數×每行平均費用

估算源代碼行數時,可以請n為有經驗的專家,每位專家對軟件給出3各估計值: ai---最少源代碼行數(該軟件可能的最小規(guī)模)bi---最大源代碼行數(該軟件可能的最大規(guī)模)mi---最可能的代碼行數(該軟件最可能的規(guī)模)然后計算出每位專家的估算期,n位專家的估算期望值的平均值就是代碼行數的估算值.7.3 其他管理 人力資源管理 風險管理

風險管理的主要活動有風險識別,風險估算,風險評價和風險控制.八.模塊化基本知識

模塊是指執(zhí)行某一特定任務的數據和可執(zhí)行語句程序元素的集合,通常是指可通過名字來訪問的過程,函數,子程序或宏調用等.模塊化就是將一個待開發(fā)的軟件劃分成若干個可完成某一子功能的模塊,每個模塊可獨立地開發(fā),測試,最后組裝成完整的程序.8.1模塊特性 8.1.1 可分解性

如果一種設計方法提供了將問題分解成子問題的系統(tǒng)化機制,它就能降低整個系統(tǒng)的復雜性,從而實現(xiàn)一種有效的模塊化解決方案.8.1.2 可組裝性

如果一種設計方法使現(xiàn)存的(可復用的)設計構件能被組裝成新系統(tǒng),它就能提供一種不需要一切從頭開始的模塊化解決方案.8.1.3 可理解性

如果一個模塊可以作為一個獨立的單位(不用參考其他模塊)被理解,那么它就易于構造和修改.8.1.4 連續(xù)性

如果對系統(tǒng)需求的微小修改只導致對單個模塊,而不是整個系統(tǒng)的修改,則修改引起副作用就會被最小化.8.1.5 保護性

如果模塊內部出現(xiàn)異常情況,并且它的影響限制在模塊內部,不會影響其他模塊,則錯誤引起的副作用就會被最小化.8.2 模塊與模塊的耦合性

耦合是對一個軟件結構內不同模塊之間互連程序的度量.耦合可以分成下列幾種,它們之間的耦合度由高到低排列.8.2.1 內容耦合

直接操作或修改另一模塊的數據,或不通過正常入口轉入另一個模塊.軟件設計時應堅決禁止內容耦合,應設計成單入口,單出口的模塊,避免病態(tài)連接.8.2.2 公共耦合

多個模塊引用同一全局數據區(qū).例如,C語言中的external數據類型,磁盤文件等都是全局數據區(qū).8.2.3 外部耦合

模塊與軟件以外的環(huán)境有關聯(lián).例如,輸入輸出把一個模塊與特定的設備,格式,通信協(xié)議耦合在一起.8.2.4 控制耦合

一模塊明顯把開關量,名字等信息送入另一模塊,控制另一模塊的功能.8.2.5 標記耦合

兩個模塊之間通過傳遞公共指針或地址相互作用的耦合.8.2.6 數據耦合

模塊間通過傳遞數據交換信息.8.2.7 非直接耦合(無耦合)模塊間無任何關系,獨立工作

原則上講,模塊化設計總是希望模塊之間的耦合表現(xiàn)為非直接耦合方式.在以上耦合中,耦合度從高到低,內容耦合度最高,非直接耦合度最低.8.3 模塊的內聚性

內聚是指一個模塊內各個元素彼此結合的緊密程序,它是信息隱蔽和局部的概念的自然擴展.設計時應該力求高內聚,理想內聚的模塊應當恰好做一件事情.1).偶然內聚:一個模塊的各成分之間毫無關系.比如:一組語句在程序的多處出現(xiàn),為了節(jié)省內存空間,這些語句放在一個模塊中,該模塊的內聚是偶然內聚的.2)邏輯內聚:把幾種邏輯上相關的功能組放在同一模塊中.3)瞬時內聚(時間內聚):一個模塊所包含的任務必須在同一時間間隔內執(zhí)行,例如初始化模塊.4)過程內聚:一個模塊的處理元素是相關的,而且必須按特定的次序執(zhí)行.5)通信內聚:一個模塊的所有成分都結合再同一個數據結構上.6)順序內聚:模塊的成分同一個功能密切相關,且輸出,作為另外一個成分的輸入.7)功能內聚:模塊內的所有成分屬于一個整體,完成單一的功能.在以上的內聚中,內聚度從低到高,偶然內聚度最低,功能內聚度最高.模塊的高內聚,低耦合的原則稱為模塊獨立原則,也稱為模塊設計的原則.8.4 模塊的深度,寬度,扇出與扇入 深度:表示軟件結構中控制的層數.寬度是軟件結構中同一個層次上的模塊總數的最大值 一個模塊的扇入是指直接調用該模塊的上級模塊的個數.一個模塊的扇出是指該模塊直接調用的下級模塊的個數.設計原則:低扇出 高扇入 8.5 模塊作用域和控制域

軟件設計時,模塊的作用域應在控制域之內.8.6 模塊化基礎知識小結

通過模塊的合并和分解,降低模塊的耦合度.模塊的扇入應盡量大,扇出應盡量小.一個模

塊的扇入是指直接調用該模塊的上級模塊的個數.一個模塊的扇出是指該模塊直接調用的下級模塊的個數.扇入大表示模塊的重用性高,利用率高.扇出大表示模塊的復雜度高.所以要高扇入低扇出.要將模塊的作用范圍限制在模塊的控制范圍之內.降低模塊之間的復雜性,避免“病態(tài)連接”.九.什么是軟件開發(fā)方法 有哪些主要方法

軟件開發(fā)方法:使用已定義好的技術集及符號表示習慣組織軟件生產的過程.結構化方法,面向對象方法,JACKSON方法,維也納開發(fā)方法(VDM).9.1 結構化方法學

結構化方法學也稱為生命周期方法學(瀑布模型方法),是一種面向數據流的需求分析方法.它的基本思想是自頂向下逐層分解.為了在需求改變時對軟件的影響較小,結構化分析時應該使程序結構與問題結構相對應.常用工具: 數據流圖(DFD),數據字典(DD),實例—關系圖(E—R圖)及描述加工處理的結構化語言,判定表,判定樹.9.1.1數據流圖(DFD圖)DFD的基本成分

數據流圖主要由4種成分組成

數據流(data flow):由一組固定成分的數據組成,表示數據的流向.它可以從源,文件流向加工,也可以從加工流向文件和宿,還可以從一個加工流向另一個加工.通常每個數據流必須有一個合適的名字,一方面是為了區(qū)別,另一方面也給人一個直觀的印象,使人容易理解這個數據流的含義.但流向文件或從文件流出的數據流不必命名,因為這種數據流的組成部分就是相應文件的組成部分.加工(process):描述了輸入數據流到輸出數據流之間的變換,也就是輸入數據流做了什么處理后變成了輸出數據流.每個加工有一個名字和一個編號.編號反映了該加工位于分層DFD的哪個層次和哪張圖中以及它是哪個加工分解出來的子加工.文件(file):可以表示數據文件,也可以表示一個數據記錄.流向文件的數據流表示寫文件,流出文件的數據流表示讀文件,雙向箭頭表示對文件既讀又寫.每個文件都有一個文件名.源/宿(source/sink):源是指系統(tǒng)所需數據的發(fā)源地,宿(也稱數據池)是指系統(tǒng)所產生的數據的歸宿地.無論源或宿,均對應于外部實體,在框內應加注實體的名字,在一個軟件各級軟件系統(tǒng)中,有些源和宿可以是一個外部實體,外部實體是指存在于軟件系統(tǒng)之外的人員或組織,它指出系統(tǒng)所需數據的發(fā)源地和系統(tǒng)所產生數據的歸宿地.分層數據流圖

一套分層的的數據流圖由頂層,底層,和中間層組成.畫分層數據流圖基本原則與注意事項 a.自外向內,自頂向下,逐層細化,完善 求精.b.保持父圖與子圖的平衡.也就是說,父

圖中某加工的輸入數據流中的數據必須與它的子圖的輸入數據流在數量和名字上相同.c.保持數據守恒.也就是說,一個加工所 有輸出數據流中的數據必須能從該加工的輸入數據流中直接獲得,或者是通過該加工能產生的數據.c.加工細節(jié)隱藏.根據抽象原則,在畫父

圖時,只需畫出加工和加工之間的關系,而不必畫出各個加工內部的細節(jié).d.簡化加工間關系.在數據流圖中,加工

間的數據流越少,各加工就越相對獨立,所以應盡量減少加工間輸入輸出數據流的數目.e.均勻分解.應該使一個數據流中的各個 加工分解層次大致相同.f.適當地為數據流,加工,文件,源/宿命

名,名字應反映該成分的實際意義,避免空洞的名字.g.忽略枝節(jié).應集中精力于主要的數據流, 而暫不考慮一些例外情況,出錯處理等枝節(jié)性問題.h.表現(xiàn)的是數據流而不是控制流.i.每個加工必須既有輸入數據流,又有輸

出數據流.在整套數據流圖中,每個文件必須既有讀文件的數據流又有寫文件的數據流,但在某一張子圖中可能只有讀沒有寫或者只有寫沒有讀.小結:一個軟件系統(tǒng),其數據流圖往往有多層.如果父圖有N個加工(Process),則父圖允許有0～N張子圖,但是每張子圖只能對應一張父圖.在一張DFD圖中,任意兩個加工之間可以有0條或多條名字互不相同的數據流;在畫數據流圖時,應該注意父圖和子圖的平衡,即父圖中某加工的輸入輸出數據流必須與其輸入輸出流在數量和名字上相同.DFD信息流大致可分為兩類:交換流和事務流.9.1.2 數據字典

數據字典是關于數據的信息的集合也就是對 數據流圖中包含的所有元素的定義的集合.組成部分: a.數據項條目 b.數據流條目 c.文件條目 d.加工條目

加工條目是對數據流圖中每一個不能再分 解的基本加工的精確說明.對于加工的描述是數據字典的組成內容之一,常用的加工描述方法有結構化語言,判定樹和判定表.9.1.3 結構化語言

結構化語言實際上是一種半形式化語言, 它的結構通?？煞譃閮韧鈨蓪?外層接近于形式化語言,而內層近似于自然語言的描述.9.1.4 實體——關系圖(E—R圖)實體——關系圖(Entity-Relabionship Diagram),簡稱E-R圖,包含實體,關系和屬性等3種基本成分.通常用矩形框代表實體,并用直線把實體(或關系)與其屬性連接起來.E-R圖通常用于數據庫應用系統(tǒng).9.2 結構化設計

結構化設計通?？煞譃楦乓O計和詳細設計,但是主要用于概要設計階段.概要設計的任務是確定軟件系統(tǒng)的結構,進行模塊劃分,確定每個模塊的功能,接口以及模塊間的調用關系.詳細設計的任務是為每個模塊設計實現(xiàn)的細節(jié).9.2.1 概要設計

經過需求分析階段的工作,系統(tǒng)必須“做什么”已經清楚了,概要設計的基本目的就是回答“概括地說,系統(tǒng)應該如實現(xiàn) ”這個問題.概要設計的重要任務:

將一個復雜的系統(tǒng)按功能化分為模塊,確

定每個模塊的功能,確定模塊之間的調用關系,確定模塊之間的接口(模塊之間傳遞的信息),評價模塊的結構質量.1.軟件結構圖形工具

結構化設計方法(SD)方法采用結構圖(Structure Chart),層次圖和HIPO圖描述軟件結構.結構圖的主要成分有模塊,調用和數據,結構圖中的模塊用矩形表示,在矩形框內可標上模塊的名字.模塊間如有箭頭或直線相連,表明它們之間有調用關系.層次圖用來描繪軟件的層次結構.層次圖中一個矩形框代表一個模塊,方框間的連線表示模塊間的調用關系.HIPO圖實際上就是層次圖加輸入/處理/輸出圖.HIPO圖是美國IBM公司發(fā)明的“層次圖加輸入/處理/輸出圖”,是在層次圖里出了最頂層的方框之外,每個方框都加了編號.編號規(guī)則和數據流圖的編號規(guī)則一樣.2.概要設計中的信息流

變換流:信息沿著輸入通道進入系統(tǒng),然后通過變換中心(也稱主加工)處理,再沿著輸出通道離開系統(tǒng).具有這一特性的信息流稱為變換流.具有變換流型的數據流圖可明顯地分成輸入,變換(主加工),輸出三大部分.事務流:信息流沿著輸入通道到達一個事務中心,事務中心根據輸入信息(即事務)的類型在若干個動作序列(稱為活動流)中選擇一個來執(zhí)行,這種信息流稱為事務流.事務流有明顯的事務中心,各活動以事務中心為起點呈輻射狀流出.9.2.2 詳細設計

概要設計已經確定了每個模塊的功能和接口,詳細設計的任務就是為每個模塊設計其實現(xiàn)的細節(jié).詳細設計階段的根本目標是確定應該怎樣具體地實現(xiàn)所要求的系統(tǒng),得出對目標系統(tǒng)的精確描述.1.詳細設計階段的內容

為每個模塊進行詳細的算法設計.為模塊內部的數據結構進行設計.對數據庫進行物理設計.其他

詳細設計工具主要包括程序流程圖(系統(tǒng)流程圖),盒圖(N-S圖),PAD圖和偽碼(PDL).2.人機界面設計

人機界面的設計質量,直接影響用戶對軟件產品的評價.界面的美觀,靈活和風格都很重要,但人機界面設計中最重要的也是最基本的目標是軟件的易操作性.人機界面設計主要包括系統(tǒng)響應時間,用戶幫助設計,出錯信息處理和命令交互設計等幾個方面.9.3 Jackson方法

上面講的結構化設計方法是面向數據流的,另外還有一種面向數據結構的設計方法, Jackson方法是最著名的面向數據結構的設計方法,而不是面向數據流的設計方法.Jackson方法的基本步驟是:建立系統(tǒng)的數據結構;以數據結構為基礎,對應地建立程序結構;列出程序中要用到的各種基本操作,再將這些操作分配到程序結構適當的模塊中.9.4 面向對象分析方法(00A)OTM方法的三個模型,分別從三個不同側面描述了所要開發(fā)的系統(tǒng):功能模型指明了系統(tǒng)應該“做什么”;動態(tài)模型明確了什么時候做;對象模型則定義了做事情的實體.對象模型描述了系統(tǒng)中對象的靜態(tài)結構及對象間的聯(lián)系,用對象模型圖來表示.動態(tài)模型描述了與時間和操作次序有關的系統(tǒng)屬性.動態(tài)模型由多張狀態(tài)圖組成.各個類的狀態(tài)圖通過共享事件組成系統(tǒng)的動態(tài)模型.功能模型描述系統(tǒng)內數據值的變化,它由數據流圖組成.數據流圖說明數據流是如何從外部輸入,經過操作和內部存儲而得到輸出的.十.軟件工具

軟件工具是指用于輔助軟件開發(fā),運行,維護,管理,支持等過程中的活動的軟件.通常也稱為CASE(Computer Aided Software Engineering,計算機輔助軟件工程)工具.按軟件過程的活動分為軟件開發(fā)工具,軟件維護工具和軟件管理工具等.十一.軟件開發(fā)環(huán)境

集成型開發(fā)環(huán)境通常可由工具集和環(huán)境集成機制兩部分組成.這種環(huán)境應具有開放性和可裁減性.環(huán)境集成機制主要有數據集成機制,控制集成機制和界面集成機制.十二.軟件質量管理基礎知識 12.1 軟件質量

ISO/IEC 9126軟件質量模型可從軟件功能性,可靠性,可用性,效率,可維護性,可移植性6個方面來衡量.(1).功能性

與功能及其指定的性質的一組軟件屬性.(2)可靠性

軟件在規(guī)定的一段時間內和規(guī)定的條件下保持其性能水平有關的一組軟件屬性.也可以稱為在規(guī)定的條件下和規(guī)定的時間間隔內,軟件實現(xiàn)其規(guī)定功能的概率.(3)可用性

與使用的難易程序及規(guī)定或隱含用戶對使用 方式所做的評價有關的軟件屬性.(4)效率

與在規(guī)定條件的性能水平與所用資源量之間的關系有關的一組軟件屬性.(5)可維護性

與軟件維護的難易程序有關的一組軟件屬性.(6)可移植性

軟件可從某一環(huán)境轉移到另一環(huán)境的能力有關的一組屬性.即軟件從一個計算機系統(tǒng)轉換到另一個計算機系統(tǒng)運行的難易程度是指軟件的可移植性.為了提高可移植性,應注意提高軟件的設備獨立性.采用表格驅動程序有助于提高設備獨立性.為了提高可移植性,還應有完備的文檔資料.使用C語言開發(fā)的系統(tǒng)軟件具有較好的可移植性.12.2 軟件質量保證

軟件質量保證的主要困難表現(xiàn)在以下幾個方面: 1)軟件開發(fā)的管理人員往往關心項目開發(fā)的成本與進度.因為成本和進度是顯而易見的,而軟件質量則難以度量.如果軟件開發(fā)的管理人員對交付的軟件含有多少隱患并不必負什么責任,他們必定沒有太高的熱情去控制開發(fā)的質量,更不必說保證質量并不容易且代價昂貴.開發(fā)人員的習慣一旦形成難以改變,他們的形為也難于控制,而高質量的軟件產品,又主要取決于參與開發(fā)的人員.復雜的軟件項目需要許多技術人員和管理人員參與,對問題的不同認識和誤解如不能及時消除必然影響軟件質量.軟件開發(fā)人員的頻繁流動,特別是骨干開發(fā)人員的流失,也會使軟件質量受到一定的影響.軟件質量的保證手段: 開發(fā)初期制定質量保證計劃,并在開發(fā)中堅持實行.開發(fā)前選定或制定開發(fā)標準或開發(fā)規(guī)范,并遵照實施.從開始就選擇分析設計方法和工具,形成高質量的分析模型和設計模型.嚴格執(zhí)行階段評審,以便及時發(fā)現(xiàn)問題.各個開發(fā)階段的測試.對軟件的每次“變動”都要經過申請,評估,批準,實施等步驟.軟件質量特性的度量化.軟件生存期的各階段都要完整的文檔.12.3 代碼評審技術

常用方法有代碼走查和代碼審查技術.代碼走查

程序員和測試員組成審查小組,通過邏輯運行程序.第一步:小組成員提前閱讀設計規(guī)格書,程序文本等相關文檔;第二步:利用測試用例,使程序邏輯運行,記錄程序的蹤跡,發(fā)現(xiàn),討論,解決問題 代碼審查

程序員和測試員組成審查小組.第一步:小組成員提前閱讀設計規(guī)格書,程 序文本等相關文檔;第二步:召開程序審查會,開發(fā)人員讀程序,審查小組討論,發(fā)現(xiàn),解決問題.兩者的區(qū)別

代碼審查是一種正式的評審活動,而代碼走 查的討論過程是非正式的.十三.成本-效益分析可用哪些指標進行度量

投資回收率:通常把建立系統(tǒng)若干年后所取得的收益折算成現(xiàn)在的價值和開發(fā)系統(tǒng)所需的費用進行比較得出投資回收率.投資回收期:就是使累計的經濟效益等于最初的投資費用所需的時間.純收入:整個軟件生命周期之內的累計經濟效益(折成現(xiàn)在值)與投資之差.十四.第四代語言(4GL)的主要特征

友好的用戶界面

兼有過程性和非過程性兩種特性 高校的程序代碼 完備的數據庫 應用程序生成器

十五.軟件測試

軟件測試的費用已經超過軟件開發(fā)費用的30%左右.“高產”測試是指用少量的測試用例,發(fā)現(xiàn)被測試程序盡可能多的錯誤.15.1 軟件測試經過的步驟

單元測試->集成測試->確認測試->系統(tǒng)測試 15.2 測試與軟件開發(fā)各階段的關系

單元測試對程序中每一個程序單元進行測試,檢查各個模塊是否爭取實現(xiàn)規(guī)定的功能,從而發(fā)現(xiàn)模塊在編碼中或算法中的錯誤,該階段涉及編碼和詳細設計文檔.集成測試是為了檢查與設計相關的軟件體系結構的有關問題,也就是檢查概要設計是否合理有效.確認測試主要是檢查已實現(xiàn)的軟件是否滿足需求規(guī)格說明書中已確定了的各種需求.系統(tǒng)測試是把已確認的軟件與其他系統(tǒng)元素(如硬件,其他支持軟件,數據,人工等)結合在一起進行測試,以確定軟件是否可以支付使用.15.3 白盒測試

白盒測試又稱為結構測試.可以把程序看成裝在一個透明盒子里,測試者(一般為編程者)完全知道程序的結構和處理算法.按照程序內部邏輯設計測試用例,檢測程序中的主要執(zhí)行通路是否能按預定要求正常工作.白盒測試多用于單元測試階段.邏輯覆蓋是主要的白盒測試技術.白盒測試時,確定測試數據應根據程序的內部邏輯和指定的覆蓋方式.采用一下幾種邏輯覆蓋標準: 語句覆蓋 判定覆蓋 條件覆蓋

判定/條件覆蓋 條件組合覆蓋 路徑覆蓋

滿足條件組合覆蓋測試用例,也一定滿足判定條件覆蓋.因此,條件組合覆蓋是上述五種覆蓋標準中最強的一種.15.4 黑盒測試

黑盒測試,又稱為功能測試.把軟件看做是一個不透明的黑盒子,完全不考慮(或不了解)軟件內部結構和處理算法,它只檢測軟件功能是否能按照軟件需求說明書的要求正常使用,軟件是否能適當的接受輸入數據并產生正確的輸出信息,軟件運行過程中能否保持外部信息(例如文件和數據庫)的完整性等.常用的黑盒測試技術包括等價類劃分,邊值分析,錯誤推測和因果圖等.其中等價類劃分和邊界值分析法方法最常用.如果兩者結合使用,更有可能發(fā)現(xiàn)軟件中的錯誤.15.4灰盒測試

灰盒測試介于白盒測試和黑盒測試之間,它把軟件看做是一個半透明的灰盒子,結合考慮軟件的內部結構和外部功能設計測試用例 15.5 回歸測試

糾正了程序中的錯誤之后,選擇部分或全部原先已測試過的測試用例,對修改后程序重新測試以驗證對軟件修改后有沒有引出新的錯誤,稱為回歸測試.15.6 單元測試

單元測試(Unit testing)也稱為模塊測試或結構測試,通?？煞旁诰幊屉A段(實現(xiàn)階段),主要采用邏輯覆蓋技術,由程序員對自己編寫的模塊自行測試,檢查模塊是否能實現(xiàn)了詳細設計說明書中規(guī)定的功能和算法.單元測試主要發(fā)現(xiàn)編程和詳細設計中產生的錯誤.測試一個模塊時需要為該模塊編寫一個驅動模塊和若干個樁(stub)模塊.頂層模塊測試時不需要驅動模塊,底層模塊測試時不需要樁模塊.在進行單元測試時,常用的方法是白盒測試(采用邏輯覆蓋的測試技術),輔之以黑盒測試.15.7集成測試

集成測試(integration testing)也稱為組裝測試,在單元測試的基礎之上,把所有的模塊組裝成一個系統(tǒng)進行測試.主要測試設計階段產生的錯誤,集成測試計劃應該在概要設計階段制定.非漸增式集成測試

首先將每個模塊分別進行單元測試,再把所有的模塊組裝成一個完整的系統(tǒng)進行測試.目前在進行集成測試時已普遍采用漸增式集成.漸增式集成測試

又可以分為自頂向下集成和自底向上集成.自頂向下集成先測試上層模塊,再測試下層模塊,由于測試下層模塊時上層模塊已經測試過,所以不必要另外編寫驅動模塊.自底向上集成,先測試下層模塊,再測試上層模塊.頂層模塊測試時不需要驅動模塊,底層模塊測試時不需要樁模塊.軟件的集成測試最好由不屬于該軟件開發(fā)組的軟件設計人員承擔,以提高集成測試的效果.三明治測試

從系統(tǒng)的三個角往中間包圍測試的方法.15.8 確認測試

在系統(tǒng)驗收測試中,驗證測試是在模擬的環(huán)境中進行強度測試的基礎上進行,主要依據軟件需求說明書檢測軟件的功能,性能及其他特征是否與用戶的要求一致,而確認測試是在一個實際環(huán)境中使用真實數據運行系統(tǒng).確認測試計劃應該在需求分析階段制定.α測試

由用戶在開發(fā)者的場所進行,并且在開發(fā)者的指導下進行測試.開發(fā)者負責紀錄發(fā)現(xiàn)的錯誤和使用中遇到的問題,也就是說α測試是在受控的環(huán)境中進行的.β測試是在一個或多個用戶的現(xiàn)場由該軟件的最終用戶實施的,開發(fā)者通常不在現(xiàn)場,用戶負責記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題并把這些問題報告給開發(fā)者.也就是說,β測試是在受控的環(huán)境中進行的.經過確認測試之后的軟件通常就可以交付使用了.15.9 系統(tǒng)測試

系統(tǒng)測試是將已經確認的軟件,計算機硬件,外設和網絡等其他因素結合在一起,進行信息系統(tǒng)的各種組裝測試和確認測試,其目的是通過與系統(tǒng)的需求相比較,發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方.包括以下的測試: 恢復測試:監(jiān)測系統(tǒng)的容錯能力

安全性測試:監(jiān)測系統(tǒng)的安全機制,保密措施是否完善等防范能力.強度測試:測試軟件的異常情況的處理能力.性能測試:監(jiān)測系統(tǒng)是否滿足系統(tǒng)設計方案說明書對性能的要求.可靠性測試:從平均失效間隔是否超過了規(guī)定的時限,因故障而停機的時間在一年中不應超過的時間來進行檢測.安裝測試:監(jiān)測軟件在安裝過程中是否有錯誤,是否容易操作等.系統(tǒng)測試計劃在系統(tǒng)測試階段初期制定.十六.軟件工程標準和軟件文檔

GB/T8566-2001,GB/T12504-1990,GB/T12505-1990是我國現(xiàn)階段最重要的三個軟件開發(fā)規(guī)范標準.國家標準局1988年1月批準并發(fā)布的《GB/T8567-1988計算機軟件產品開發(fā)文件編制指南》規(guī)定在一項軟件開發(fā)過程中應該產生14中文件 可行性研究報告 項目開發(fā)計劃 軟件需求說明書 數據要求說明書 概要設計說明書 詳細設計說明書 數據庫設計說明書 用戶手冊 操作手冊 模塊開發(fā)卷宗 測試計劃 測試分析報告 開發(fā)進度月報 項目開發(fā)總結報告

軟件運行和維護基礎知識

管理人員主要使用:項目開發(fā)計劃,可行性研究報告,模塊開發(fā)卷宗,開發(fā)進度月報,項目開發(fā)總結報告.開發(fā)人員:項目開發(fā)計劃,可行性研究報告,軟件需求說明書,數據要求說明書,數據庫設計說明書,概要設計說明書,詳細設計說明書,測試計劃,測試分析報告.維護人員:概要設計說明書,詳細設計說明書,數據庫設計說明書,模塊開發(fā)卷宗,測試分析報告,維護報告.用戶:用戶手冊,操作手冊.十七.軟件維護

用于軟件維護的花費約為整個軟件生命周期花費的75%(或60%～80%之間)而且還在逐年上升.17.1 軟件維護類型

根據引起軟件維護的原因,軟件維護可分為以下四種類型(1)改正性維護

使用過程中發(fā)現(xiàn)了隱蔽的錯誤后,為了診斷和改正這些隱蔽錯誤而修改軟件的活動(2)適應性維護

為了適應環(huán)境的變化而修改軟件的活動(3)完善性維護

為了擴充或完善原有軟件的功能或性能而修改軟件的活動.(4)預防性維護

預防性維護是指為了提高軟件的可維護性和可靠性,為未來的進一步改進打下基礎而修改軟件的活動.17.2 軟件的可維護性 通常影響軟件可維護性的因素有可理解性,可測試性和可修改性.(1)可理解性

可理解性是指維護人員理解軟件的結構,接口,功能和內部過程的難易程度.采用良好的編程風格有助于提高軟件的易理解性.(2)可測試性

可測試性是指測試和診斷軟件錯誤的難易程度.(3)可修改性

可修改性是指修改軟件的難易程度.怎樣提高軟件的可維護性

在軟件生命周期的各個階段都必須充分考慮維護問題.結構化設計的幾條主要原則,如模塊化,信息隱藏,高內聚,低耦合等,對于提高軟件的可理解性,可測試性和可修改性也都有重要的作用.書寫詳細正確的文檔,書寫源文件的內部注解,使用良好的編程語言,具有良好的程序設計風格,也有助于提高軟件的可理解性.使用先進的測試工具,保存以前的測試過程和測試用例,則有助于提高軟件的可測試性.十八.軟件的可靠性

在給定的時間內,在給定的環(huán)境條件下系統(tǒng)完成所指定工作的概率.衡量的標準是:平均失效等待時間MTTF 和平均失效間隔時間MTBF.

第五篇：軟件工程課程總結

軟件工程課程總結

學習軟件工程這門課程已經有一個學期了，整整一個學期下來，應該說還是有許多值得肯定的地方的。其實在我看來，軟件工程與其說是一門課程，不如說是一門思想，是一個如何去分析和處理問題的過程，應該說其范疇已經遠遠不止局限于該門課程，成為了一個綜合的能夠解決問題的思想集合。

學習軟件工程能夠加強人的整體思維能力，對人的綜合素質有所提高，培養(yǎng)良好的分析規(guī)劃和團隊意識。學習了軟件工程，我們可以在給定成本、進度的前提下，開發(fā)出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足用戶需求的軟件產品。追求這些目標有助于提高軟件產品的質量和開發(fā)效率，減少維護的困難。

在這學期的軟件工程課上，我每次都認真聽老師講課，跟著老師的腳步，領悟老師的思想，學習態(tài)度還算認真。一剛開始還覺得這門課有點枯燥乏味，但后來靜下心來看這本書感覺書上的知識對以后無論是在生活、學習還是在工作上都有很大的好處，對自身也是一種完善，因為這里面的思想博大精深，值得學習。從此我就認真地學習這門課程。盡管在學習的過程中遇到了很多困難，但經過與老師和同學的積極交流終于把問題解決了，從中學到了更深層次的知識，而這些知識又是對書本知識的補充，對學習書本知識有很大的好處。當然，學習理論知識就是用來指導實踐的，也只有把理論知識運用到實踐才能充分發(fā)揮理論的作用。所以在業(yè)余時間，我們嘗試著把所有知識串起來，并根據自身的實踐經驗完成了相關的系統(tǒng)分析報告，讓知識能更加駐留我心。

在本學期的軟件工程課程的學習中，我們學習了十章的內容。第一章軟件工程概述，這一章主要講解的是一些概念性和基礎性的內容，例如軟件的概念、特性，軟件危機的主要表現(xiàn)。了解軟件工程的的工作對象、發(fā)展背景、內容、目標。還介紹了三個常用的軟件工具Microsoft Visio、PowerDesigner和Rational Rose。第二章軟件開發(fā)過程模式，這一章主要讓我們了解軟件生存周期，認識到了軟件開發(fā)過程，熟悉了幾種常用的軟件過程模式的特點與用途。此章介紹了6種模式：瀑布模式、原型進化模式、增量模式、螺旋模式、迭代模式和組件復用模式。第三章軟件項目管理，本章詳細介紹了項目管理內容（對項目的管理、對項目成果的管理），讓我們學會如何制定項目計劃，并學習使用甘特圖、任務網絡圖（由Microsoft Project創(chuàng)建）制定項目計劃。第四章計算機系統(tǒng)工程，這一章讓我們熟悉如何從全局的計算機系統(tǒng)角度考察軟件問題，熟悉如何對軟件項目做可行性分析。該章還涉及系統(tǒng)初步建模，其中的系統(tǒng)框架圖、系統(tǒng)流程圖，可由Microsoft Visio中的基本流程圖創(chuàng)建。第五需求分析，這一章重點講解了需求分析任務及過程，讓我們學會如何獲取業(yè)務需求、建立業(yè)務模型、進行需求驗證。可通過Microsoft Visio中的組織圖創(chuàng)建業(yè)務樹，通過Rational Rose創(chuàng)建業(yè)務用例、業(yè)務活動。第六章結構化分析建模，這一章重點講解了使用變換型映射方法和事務型映射方法生成初始的模塊結構以及模塊結構的改進。說明了建立分析建模的原因和方法。我們可通過PowerDesigner創(chuàng)建實體聯(lián)系圖，通過Microsoft Visio創(chuàng)建數據流圖，通過Rational Rose創(chuàng)建事件狀態(tài)圖。第七章基于UML的面向對象分析建模，本章詳細介紹了UML的基本模式、事物、關系及建模時用到的各種圖進行了介紹?？赏ㄟ^Rational Rose進行面向對象分析建模。第八章概要設計，這一章主要講解了概要設計任務及過程，介紹了系統(tǒng)構架、數據結構、程序結構等概要設計內容。第九章結構化設計建模，本章介紹了結構化設計建模的工具，讓我們學會如何基于數據流進行程序結構映射和如何對程序結構進行優(yōu)化。該章中的程序結構圖由Microsoft Visio創(chuàng)建。第十章基于UML的面向對象設計建模，本章講解了面向對象設計建模內容，讓我們學習使用UML建立面向對象設計模型（邏輯結構、動態(tài)過程、物理裝配與部署）。通過Rational Rose進行設計建模。

學習了這門課程之后，我發(fā)現(xiàn)無論是在上課，還是在學校里面做學生工作，技術性的工作就好比變魔術。其實原理是非常簡單的，甚至可以說簡單的可笑，但是當你就是做出這么一個簡單的東西出來之后，一些外行們有時候會用崇拜的眼光看著你，覺得你很厲害，很高深莫測。但是制作的過程他們卻不知道，也許知道之后他們只是會啞然失笑，原來這個東西的制作過程是如此的簡單，這個可以說就是技術的魅力了。就比如說軟件工程中所謂的需求獲取，從字面上來看好像是一件很難的事，而其實就是一個談判，辯論，交流的過程，只不過這個交流過程可能針對性比較強。所以說軟件工程就是對生活的平凡小事的升華，它來自于生活卻高于生活。當我們在畢業(yè)之后，軟件工程是我們實際要運用的一項非常有用的技能，而且不僅僅局限于軟件工程的范疇，即使我們是從事其它行業(yè)，不也是要從需求獲取開始，一直有條有理地到最后成品的出爐嗎？應該說這就是這門課的價值所在，它讓我們既學會了管理又學會了技術。

在整個學期的學習過程中，我收獲了不少，能夠解決一些較為簡單的問題，在建模方面的能力有所加強。原來一直以為學好這門課程最重要的是會編寫程序，其實則不然。我了解到軟件并非是一些代碼這么簡單，在開發(fā)軟件的過程中，編寫代碼的工作量其實只占不到所有工程量的30%，而后期的管理和維護更是占了60%到80%之多。一個完整的項目規(guī)劃須包括：軟件的定義、可行性分析報告、項目開發(fā)計劃、軟件需求說明書、概要設計說明書、詳細設計說明書、用戶操作手冊、測試計劃、測試分析報告、開發(fā)進度報告、項目開發(fā)總結報告、軟件維護手冊、軟件問題報告、軟件修改報告等多個文檔，每個文檔都要上級驗收審查，而文檔數量眾多，要做好這點真的不是很容易，而恰恰寫好文檔正能保證完成軟件工程其中一個目的的關鍵，既研究如何用最小的開銷做出生存期較長的軟件，再加上各個階段都要進行周密的策劃、詳細的分工部署和人員安排，且各階段要據具體情況不斷的反復才能達成，所以代碼只是開發(fā)軟件這個浩大的工程的一個小小的過程。當然自己也有很多的不足之處，比如自己動手操作能力比較弱，實踐經驗匱乏，思維不緊密，不注重細節(jié)，耐心不夠，每次遇到問題就去問老師，實戰(zhàn)精神不強，所以導致很多知識學得也只是模模糊糊的。所以在以后的學習中我要加強自身綜合素質的培養(yǎng)，要注意多看多練要注意結合實際，更要多思考，面對錯誤不要一范就問，要嘗試自己去解決，這樣才能學到這門課程的精華。我覺得學好軟件工程首先要明白自己的學習目標究竟是什么，根據自己的實際工作出發(fā)，有針對性地在相應的學習方向上進行提高，制定出詳細的學習規(guī)劃。還要注意與其他科目的相輔相成，就像我們在學習語言時，要看看與C語言的聯(lián)系，多思多想，把從各個科目學到的知識融匯貫通。

在本學期我們班每位同學都做了管理信息系統(tǒng)分析報告，其中就用到了軟件工程中的不少知識。比如項目來源，項目任務，項目規(guī)劃，系統(tǒng)需求分析，系統(tǒng)結構設計，系統(tǒng)詳細設計，系統(tǒng)測試，系統(tǒng)維護等等。而我做的是酒店客房管理信息系統(tǒng)的分析報告，其中涉及到了以上幾個方面，需要明確任務目標，準備相應的項目資源，對項目實施合理的規(guī)劃，進行業(yè)務需求和功能需求分析，制定出數據字典，設計出軟件結構，并對其進行詳細設計，比如算法設計，數據庫設計和界面設計。畫出進度安排表，組織結構圖，業(yè)務流程圖，數據流圖，利用UML建模畫出圖形，通過這些圖形能更直觀地看出各個實體之間的關系，對系統(tǒng)有個比較整體的體現(xiàn)。

總之，在今后的學習中要注意多讀書、多思考、多練習、多討論，不斷熟悉書本的基礎，并以此為基礎將其擴散開來，應用于今后的實踐。不斷鍛煉自己，成為社會的可用之才，回饋社會。