『壹』 軟體工程導論(第五版)張海藩編著，請問用楊輝三角形畫出HIPO圖和數據流程圖
我擦，胖子...
『貳』 軟體工程航空公司機票預定系統
軟體工程課程設計
一、 課程設計題目：
航空公司機票預訂系統。
二、 課程設計內容簡要分析：
航空公司為方便旅客，需開發一個機票預定系統。為便於旅客由旅行社代替航空公司負責為旅客定票，旅行社把預定機票的旅客信息，包括姓名、性別、工作單位、身份證號碼、旅行時間、旅行目的地，輸入機票預定系統的客戶端程序，系統經過查詢航空公司內的航班數據伺服器後，為旅客安排航班，印出取票通知。旅客在飛機起飛前一天憑取票通知和帳單交款後取票，系統校對無誤後即印出機票給旅客。
要求系統能有效、快速、安全、可靠和無誤的完成上述操作。並要求客戶機的界面要簡單明了，易於操作，伺服器程序利於維護。
三、主要設計過程：
1、問題定義：
航空運輸現在已經逐漸成為我國運輸事業的重要手段，但是對於航空運輸來說，天氣或人為的種種的因素，會給航空機票的預定和退訂帶來困難，特別是對於機票的預定和退訂的條理性、及時性和准確性，也同樣帶來巨大的困難。
對以上的問題，完全可以建立一套完整的航空公司機預定系統，來對信息進行錄入、查詢、訂票、退票等日常管理工作，盡量少的人員介入和數據冗餘，以簡練實用為基礎，實現信息管理計算機化，提高工作效率和信息化水平。
2、可行性分析：
可行性分析對系統的開發至關重要，可以大幅減少不必要的損失，保證系統開發的順利進行。可以從技術可行性、經濟可行性、操作可行性三方面進行系統可行性分析：
2.1、技術可行性：
這些年來，計算機技術的發展異常迅猛，而絕大多數的企業和單位，都已經把計算機作為信息和數據處理、保存和管理的重要工具。
Java是Sun Microsystem公司的James Gosling開發的編程語言。它以C++為基礎，但是卻是一個全新的軟體開發語言。Java是一個簡單，面象對象、分布式、解釋性、強壯、安全，與系統無關、可移植、高性能、多線程和動態的語言，利用Java就可以編制出程序介面好、圖形界面優美的管理系統。同時，微軟公司開發的SOL Server 2000，為資料庫的開發和管理帶來了極大的方便。
2.2、經濟可行性：
一方面，對於新系統的開發和研究，不需要花費更多的費用，而且對於人員的培訓，不同樣不需要花費很多；另一方面，航空公司的原有伺服器和計算機系統，同樣可以用來使用，不需要更新系統。
2.3、操作可行性：
對於用Java開發的本系統，通過簡單的學習就可以熟練操作，同時，對於票務的管理，也同樣因為本系統的高效性、及時性和方便性而易於管理。
通過以上的分析，航空公司機票預定系統在經濟上、技術上、操作上都是可行的。
3、 需求分析：
需求分析階段的主要目標是准確了解用戶對未來軟體的系統結構的需求，是發現、求精、建模、規格說明和復審過程。
在需求分析中，可以採用主要流程和數據流程圖來描述。
3.1、該系統主要要完成的流程為：
a) 錄入：可以錄入航班情況（數據可以存儲在一個數據文件中，數據結構、具體數據自定）
b) 查詢：可以查詢某個航線的情況（如，輸入航班號，查詢起降時間，起飛抵達城市，航班票價，票價折扣，確定航班是否滿倉）；可以輸入起飛抵達城市，查詢飛機航班情況；
c) 訂票：（訂票情況可以存在一個數據文件中，結構自己設定）可以訂票，如果該航班已經無票，可以提供相關可選擇航班；
d) 退票： 可退票，退票後修改相關數據文件；客戶資料有姓名，證件號，訂票數量及航班情況，訂單要有編號。
3.2、數據流程圖：
數據流程圖是描繪信息流和數據從輸入移動到輸出的過程中所經歷的變換。是一種能全面描述信息系統邏輯模型的主要工具,也是系統分析人員與用戶進行交流的有效手段。
旅客的訂票流程圖如下：
旅客取票的流程圖如下：
訂票旅客清單
列印機票
旅客信息查詢
旅客
旅客
售出機票信息
4、概要設計：
4.1、本系統的設計總框圖：
說明：本系統共分為兩大子系統：客戶定票系統和後台管理系統。
客戶服務系統包含三個子系統：
1、查詢系統（實現查詢功能）
2、定票系統（實現定票功能）
3、退票系統（實現退票和修改功能）
後台處理系統包含三個子系統：
1、航班信息查詢 (實現航班信息的查詢功能)
2、航班信息修改（實現航班信息的修改、新增、刪除功能）
3、乘客信息查詢（實現乘客信息的查詢）
兩大系統共用兩個數據文件：航班基本信息文件和客戶定票信息文件。
4.2、客戶定票系統的概要設計：
說明：
1）查詢：用戶可以通過輸入航班號單關鍵字查詢，飛機的起降地點和飛機的起飛時間雙關鍵字查詢兩種方式進行查詢。（註：結構圖里查詢和訂票之間的連線表示客戶可以由查詢界面直接進入訂票界面）
2）訂票：客戶可以直接從主界面直接進入訂票界面，也可以從航班信息查詢界面通過事件觸發進入訂票界面。客戶在訂票界面內填寫客戶基本信息和所定航班的關鍵信息，然後由提交事件進行信息有效性判斷。如果數據有效，則修改航班基本信息，新增客戶信息。
3）退票和修改：在客戶正確輸入交易單號，乘客姓名，身份證號的前提下，系統確定數據有效性，客戶擁有退票或修改交易的許可權。此時對航班基本信息數據文件和客戶訂票信息文件進行數據項的刪除或修改。
4）客戶修改的主要作用：當客戶對於所定機票的航班號，數量，等級等內容需要修改時，可啟動此功能。
同時，為方便客戶修改過程能准確的了解航班基本信息，在客戶退票界面加入了查詢按鈕。可以通過事件觸發進入相關界面。
4.3、後台管理系統的概要設計：
說明：
1) 航班信息修改：管理人員可以通過輸入航班號與日期查詢該航班的基本信息 。可在查詢的結果上進行修改，也可刪除該條信息。所有數據修改都應在數據文件中完成，在界面上顯示出來。
2) 航班信息錄入：管理人員可以通過輸入新的航班信息新加一條航班的基本信息。
3) 乘客信息查詢：管理人員可以通過輸入交易單號碼，乘客姓名，乘客身份證號查詢乘客的基本信息。
4.4、機票預訂系統的邏輯模型如下：
航班機票信息
旅行時間
姓名
性別
旅行地點
身份證號碼
工作單位
旅客
1
價格
航空公司
取票通知
帳單
訂票
1 1
時間
旅行社
合適航班機票
N
訂票旅客清單
售出機票信息
可售機票
等級
5、詳細設計：
5.1、主界面程序流程圖設計：
說明：在主界面，可以設置四個按鈕以供選擇：查詢、訂票、退票和退出。
選擇不同的按鈕觸發不同事件。
5.2、查詢系統程序流程圖設計：
5.3、訂票系統程序流程圖設計：
5.4、 退票系統流程流程圖設計：
6、實現和單元測試：
6.1、編碼：
航班信息鏈表類核心代碼：
public class FlightList implements Serializable
{
public FlightListNode firstNode; // 第一架航班的信息表
public FlightListNode lastNode; // 最後一架航班的信息表
public String name;
public int numberOfRecords; // 全天起落航班的總記錄
public FlightList( String s )
{
name = s;
firstNode = lastNode = null;
}
public boolean exist( String sFlightNo, Date date ) //判斷含傳入航班號和日期的結點是否存在
{
FlightListNode current = firstNode; // 航班信息的第一個結點
while( current != null)
{
if( current.data.flightNum.equals( sFlightNo )
&& current.data.date.equals( date ) )
return false;
else
current = current.next; //當前航班號不存在時轉入下一個結點
}
return true;
}
public void insertAtFront( FlightInfo insertItem ) //在鏈首插入結點
{
if( isEmpty() )
firstNode = lastNode = new FlightListNode( insertItem );
else
firstNode = new FlightListNode( insertItem, firstNode );
return numberOfRecords ++;
}
public void insertAtBack( FlightInfo insertItem ) //在鏈尾插入結點
{
if( isEmpty() )
firstNode = lastNode = new FlightListNode( insertItem );
else
lastNode = lastNode.next = new FlightListNode( insertItem );
return numberOfRecords ++;
}
public void delete( FlightInfo deleteItem ) //刪除航班信息結點
{
FlightListNode deleteNode = new FlightListNode( deleteItem );
FlightListNode current = firstNode;
if( isEmpty() )
throw new EmptyListException( name );
FlightListNode temp = firstNode;
int flag = 0 ;
while( current != null )
{
if( current.data.flightNum.equals( deleteNode.data.flightNum ))
{
if( flag == 0 )
{
firstNode = firstNode.next;
}
temp.next = current.next;
break;
}
else
{
temp = current;
current = current.next;
flag ++;
}
}
numberOfRecords --;
}
}
7、軟體維護：
維護方面主要為對伺服器上的資料庫數據進行維護。可使用 SQL SERVER 2000的資料庫維護功能機制。例如，定期為資料庫進行Backup，維護管理資料庫死鎖問題和維護資料庫內數據的一致性等。
三、 主要參考文獻：
1 張海潘. 軟體工程導論. 北京：清華大學出版社,2005
2 趙松濤. SQL Server 2000系統管理實錄. 北京：電子工業出版社, 2006
3 宋波. Java Web應用與開發教程. 北京：清華大學出版社,2006
4 孫衛琴. Java面向對象編程. 北京：電子工業出版社,2006
『叄』 軟體開發工程
軟體工程
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：
Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。
IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。
Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
軟體工程必須遵循什麼原則
圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：
(1)選取適宜的開發模型
該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。
(2)採用合適的設計方法
在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。
(3)提供高質量的工程支撐
工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。
(4)重視軟體工程的管理
軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。
軟體工程是指導計算機軟體開發和維護的工程學科。
採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。
軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是
在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對
軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策
略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略
。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題
進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立
的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，
從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務
的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是
使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開
始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就
是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查
和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這
個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再
經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所
開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有
一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了
到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎
。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做
了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周
期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結
構分析或結構設計技術。
把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡
單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體
生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段
結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的
工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的
質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高
軟體開發的成功率，軟體開發的生產率也能明顯提高。
目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、
開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體
生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相
對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程
度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟
件生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步
劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。
軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行
性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程
需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析
，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定
義、可行性研究和需求分析。
開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組
成：總體設計，詳細設計，編碼和單元測試，綜合測試。
維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在
使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境
；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再
進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開
發過程。
下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。
1問題定義
問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道
問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最
終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的
，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和
規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員
扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份
書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都
滿意的文檔。
問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的
時間。
2可行性研究
這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解
決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的
系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。
可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范
圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究
階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更
准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效
益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的
重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進
行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值
得投資的工程項目，可以避免更大的浪費。
3需求分析
這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，
目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。
用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表
達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道
怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統
分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確
認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏
輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因
此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術
專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的
細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結
構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完
整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有
效地防止和克服急於著手進行具體設計的傾向。
4總體設計
這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」
首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用
計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是
人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮
下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工
作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用
起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒
有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的
能力在實踐中將證明是很有價值的。
高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功
能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種
方案的成本和效益，還應該在充分權衡各種方案的利弊的
『肆』 學習《軟體工程》心得和體會
軟體工程學習心得
在本學期的軟體工程課程的學習中，我們學習了十一章的內容。第一章軟體與軟體工程的概念，這一章主要講解的是一些概念性和基礎性的內容，例如軟體的概念、特性，軟體危機的主要表現，軟體工程的概念以及軟體生存期、典型生存期模型等等。第二章軟體工程方法與工具，這一章主要對軟體工程方法進行介紹，包括三種方法：傳統方法、面向對象方法、形式化方法。還引出了工具UML。第三章軟體需求獲取與結構化分析方法，本章詳細介紹了需求獲取與需求分析階段的任務以及結構化分析方法，畫分層的數據流圖、E-R圖以及狀態圖式本節的重點。第四章結構化分析方法，這一章重點講解了使用變換型映射方法和事務型映射方法生成初始的模塊結構以及模塊結構的改進。第五章編碼，這一章重點講解了編碼的風格及規范，還告訴我們編碼規范說帶來的好處，並告誡我們將來一點要形成好的編碼風格。第六章軟體測試方法，本章講解了軟體測試相關的概念及重要性，軟體測試與開發各個階段的關系；還介紹了白盒測試技術以及黑河測試技術。第七章統一建模語言UML概述，本章詳細介紹了UML的基本模式、事物、關系及建模時用到的各種圖進行了介紹。第八章面向對象分析，這一章主要講解了面向對象分析的3種模型，包括功能模型、靜態模型和動態模型。第九章軟體體系結構與設計模式，本章對軟體體系結構的基本概念、典型風格等進行了講解。第十章面向對象設計，本章的重點是對面向對象分析時建立的對象模型進行調整和細化。第十一章軟體維護，本章主要介紹軟體維護的任務、軟體維護活動以及軟體維護方法進行了介紹。
要學習軟體工程，學會如何系統的思考，以及養成良好的編碼習慣，想學好軟體工程，就必須知道軟體工程的目標、過程和原則：
軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
我們學習了詳細設計的方法，其原則是過程描述是否易於理解、復審和維護，進而過程描述能夠自然地轉換成代碼，並保證詳細設計與代碼完全一致。包括程序流程圖、N-S圖、PAD圖、HIPO圖
程序流程圖：程序流程圖又稱之為程序框圖，它是軟體開發者最熟悉的一種演算法表達工具。它獨立於任何一種程序設計語言，比較直觀和清晰地描述過程的控制流程，易於學習掌握。在流程圖中只能使用下述的五種基本控制結構：順序型；選擇型；while型循環；until型循環；多情況型選擇。
N-S圖：一種符合結構化程序設計原則的圖形描述工具，稱為盒圖，又稱為N-S圖。在N-S圖中，為了表示五種基本控制結構，規定了五種圖形構件。順序型；選擇型；WHILE重復型；UNTIL重復型；多分支選擇型。
PAD圖：它是用結構化程序設計思想表現程序邏輯結構的圖形工具。PAD也設置了五種基本控制結構的圖示，並允許遞歸使用。
HIPO圖：HIPO圖是由一組IPO圖加一張HC圖組成。它是美國IBM公司在軟體設計中使用的主要表達工具。
HC圖既是層次圖，用於表示軟體的分層結構。HC圖中的每一個模塊，均可用一張IPO圖來描述。IPO 圖由輸入、處理和輸出三個框組成，需要時還可以增加一個數據文件框，這種圖形的優點，是能夠直觀地顯示輸入—處理—輸出三者之間的聯系。
還有測試方法:按照測試過程是否在實際應用環境中來分，有靜態分析與動態測試。測試方法有分析方法（包括靜態分析法與白盒法）與非分析方法（稱黑盒法）。
靜態分析技術：不執行被測軟體，可對需求分析說明書、軟體設計說明書、源程序做結構檢查、流程分析、符號執行來找出軟體錯誤。
動態測試技術：當把程序作為一個函數，輸入的全體稱為函數的定義域，輸出的全體稱為函數的值域，函數則描述了輸入的定義域與輸出值域的關系。
還學習了其他很多工具、語言、方法等，雖然不是都學得很透徹，但我相信在今後的學習中一定會慢慢的完善的。
軟體工程對於初學者來說，知識基礎較薄弱，對一些應用操作、概念、工具方法等理解起來較為困難，要能從整體概念上較好地理解和把握、學好軟體工程，不是僅僅把幾本專業書籍細致地看幾遍，然後上機練習幾次就可以成功，學習過程中要注意多看多練要注意結合實際，更要多思考，面對錯誤不要一范就問，要嘗試自己去解決。但是還要注意什麼都學，肯定是什麼都學不透的，要集中精力打攻堅戰，學習軟體工程首先要明白自己的學習目標究竟是什麼，根據自己的實際工作出發，有針對性的在相應的學習方向上進行提高，制定出詳細的學習規劃。還要注意與其他科目的相輔相成，就像我們在學習面向對象分析的時候要結合大一學習的面向對象及其方法學這一專業科目進行研究拓展;在學習語言時，要看看與C語言的聯系，多思多想，把從各個科目學到的知識通匯貫通。
在軟體工程的學習中，我了解到了軟體並非是一些代碼這么簡單，在開發軟體的過程中，編寫代碼的工作量其實只佔不到所有工程量的30%，而後期的管理和維護更是佔了60%到80%之多。一個完整的項目規劃須包括，軟體的定義，可行性分析報告，項目開發計劃，軟體需求說明書，概要設計說明書，詳細設計說明書，用戶操作手冊，測試計劃，測試分析報告，開發進度報告，項目開發總結報告，軟體維護手冊，軟體問題報告，軟體修改報告，等多個文檔，每個文檔都要上級驗收審查，而文檔數量眾多，要做好這點真的不是很容易，而恰恰寫好文檔正能保證完成軟體工程其中一個目的的關鍵，既研究如何用最小的開銷做出生存期較長的軟體，再加上各個階段都要進行周密的策劃、詳細的分工部署和人員安排，且各階段要據具體情況不斷的反復才能達成，所以代碼只是開發軟體這個浩大的工程的一個小小的過程。
而編碼的學習中，我更了解到形成自己獨特的規范的編碼風格是非常重要的事。因為這影響到了軟體後期繁重的維護，大家都要閱讀你的程序，如果你寫的程序毫無規范可言，那麼別人怎麼能讀懂你的程序？讀不懂程序，維護又從何談起呢？所以，我們在今後的學習中，一定要注意這方面的培養，在寫程序的過程中，要逐步的在規范的基礎上形成屬於自己的風格，即方便自己的修改，也方便日後他人的閱讀。
在學習中，我們還要注意比較三種方法的優缺點，例如：傳統方法雖然使軟體擺脫了混亂和無序，但其在適應需求變化的方面不夠靈活，而且傳統方法要麼面向行為，要麼面向數據，缺乏兩者的有機結合。而面向對象方法的程序設計和問題求解更符合人們日常自然的思維習慣，適合大型、復雜及交互性比較強的系統。形式化方法則是一中基於形式化數學變換的軟體開發方法，它可將系統的規格說明轉換為可執行的程序。
在今後的學習中要注意多讀書、多思考、多練習、多討論，不斷熟悉書本的基礎，並以此為基礎將其擴散開來，應用於今後的實踐。不斷鍛煉自己，向一名合格的程序設計師邁進。
『伍』 關於軟體工程這門課程
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：
Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。
IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。
Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理．
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。
軟體工程基本原理
著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理。
（1）用分階段的生存周期計劃進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程序設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
B.Boehm指出，遵循前六條基本原理，能夠實現軟體的工程化生產；按照第七條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
軟體工程必須遵循什麼原則
圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：
(1)選取適宜的開發模型
該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。
(2)採用合適的設計方法
在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。
(3)提供高質量的工程支撐
工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。
(4)重視軟體工程的管理
軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。
軟體工程是指導計算機軟體開發和維護的工程學科。
採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。
軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結構分析或結構設計技術。
把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高軟體開發的成功率，軟體開發的生產率也能明顯提高。
目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。
軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定義、可行性研究和需求分析。
開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。
維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。
下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。
1問題定義
問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。
問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。
2可行性研究
這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。
可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。
3需求分析
這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。
用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。
4總體設計
這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」
首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。
高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。
上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。
5詳細設計
總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」
這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。
通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。
6編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。
程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。
7綜合測試
這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。
最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。
通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。
應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。
8軟體維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。
通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
『陸』 軟體工程相關基礎問題
淺論軟體工程
軟體工程 (Software Engineering，簡稱為SE)是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程序設計語言，資料庫，軟體開發工具，系統平台，標准，設計模式等方面。
在現代社會中，軟體應用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，操作系統，編譯器，資料庫，游戲等。同時，各個行業幾乎都有計算機軟體的應用，比如工業，農業，銀行，航空，政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。
軟體工程師是對應用軟體創造軟體的人們的統稱，軟體工程師按照所處的領域不同可以分為系統分析員，軟體設計師，系統架構師，程序員，測試員等等。人們也常常用程序員來泛指各種軟體工程師。
軟體工程的主要課程：
外語、高等數學、線性代數、高等代數、電子技術基礎、離散數學、計算機引論（C語言）、數據結構、C++程序設計、匯編語言程序設計、演算法設計與分析、計算機組成原理與體系結構、資料庫系統、計算機網路、軟體工程、軟體測試技術、軟體需求與項目管理、軟體設計實例分析、CMM/ISO9000等。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
[編輯本段]軟體工程的定義
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：
（1）。Barry Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。
（2）。IEEE在軟體工程術語匯編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、運行和維護，即將工程化應用於軟體；2.在1中所述方法的研究
（3）。Fritz Bauer在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
目前比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。
（4）。《計算機科學技術網路全書》中的定義：軟體工程是應用計算機科學、數學及管理科學等原理，開發軟體的工程。軟體工程借鑒傳統工程的原則、方法，以提高質量、降低成本。其中，計算機科學、數學用於構建模型與演算法，工程科學用於制定規范、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計劃、資源、質量、成本等管理。
[編輯本段]軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理．
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。
[編輯本段]軟體工程基本原理
著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理。Boehm
（1）用分階段的生存周期計劃進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程序設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
B.Boehm指出，遵循前六條基本原理，能夠實現軟體的工程化生產；按照第七條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則
[編輯本段]軟體工程必須遵循什麼原則
圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：
(1)選取適宜的開發模型
該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。
(2)採用合適的設計方法
在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。
(3)提供高質量的工程支撐
工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。
(4)重視軟體工程的管理
軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。
軟體工程是指導計算機軟體開發和維護的工程學科。
採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。
軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結構分析或結構設計技術。
把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高軟體開發的成功率，軟體開發的生產率也能明顯提高。
目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。
軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定義、可行性研究和需求分析。
開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。
維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。
下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。
1問題定義
問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。
問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。
2可行性研究
這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。
可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。
3需求分析
這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。
用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。
4總體設計
這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」
首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。
高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。
上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。
5詳細設計
總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」
這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。
通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。
6編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。
程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。
7綜合測試
這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。
最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。
通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。
應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。
8軟體維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。
通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
『柒』 軟體工程分工合作的問題
Engineering，簡稱為SE)是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程序設計語言，資料庫，軟體開發工具，系統平台，標准，設計模式等方面。
在現代社會中，軟體應用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，操作系統，編譯器，資料庫，游戲等。同時，各個行業幾乎都有計算機軟體的應用，比如工業，農業，銀行，航空，政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。
軟體工程師是對應用軟體創造軟體的人們的統稱，軟體工程師按照所處的領域不同可以分為系統分析員，軟體設計師，系統架構師，程序員，測試員等等。人們也常常用程序員來泛指各種軟體工程師。
軟體工程的主要課程：
外語、高等數學、線性代數、高等代數、電子技術基礎、離散數學、計算機引論（C語言）、數據結構、C++程序設計、匯編語言程序設計、演算法設計與分析、計算機組成原理與體系結構、資料庫系統、計算機網路、軟體工程、軟體測試技術、軟體需求與項目管理、軟體設計實例分析、CMM/ISO9000等。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
[編輯本段]軟體工程的定義
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：
（1）。Barry Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。
（2）。IEEE在軟體工程術語匯編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、運行和維護，即將工程化應用於軟體；2.在1中所述方法的研究
（3）。Fritz Bauer在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
目前比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。
（4）。《計算機科學技術網路全書》中的定義：軟體工程是應用計算機科學、數學及管理科學等原理，開發軟體的工程。軟體工程借鑒傳統工程的原則、方法，以提高質量、降低成本。其中，計算機科學、數學用於構建模型與演算法，工程科學用於制定規范、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計劃、資源、質量、成本等管理。
[編輯本段]軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理．
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。
[編輯本段]軟體工程基本原理
著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理。Boehm
（1）用分階段的生存周期計劃進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程序設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
B.Boehm指出，遵循前六條基本原理，能夠實現軟體的工程化生產；按照第七條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則
[編輯本段]軟體工程必須遵循什麼原則
圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：
(1)選取適宜的開發模型
該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。
(2)採用合適的設計方法
在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。
(3)提供高質量的工程支撐
工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。
(4)重視軟體工程的管理
軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。
軟體工程是指導計算機軟體開發和維護的工程學科。
採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。
軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結構分析或結構設計技術。
把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高軟體開發的成功率，軟體開發的生產率也能明顯提高。
目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。
軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定義、可行性研究和需求分析。
開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。
維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。
下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。
1問題定義
問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。
通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。
問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。
2可行性研究
這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。
可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。
在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。
可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。
3需求分析
這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。
用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。
在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。
4總體設計
這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」
首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：
低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。
中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。
高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。
系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。
上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。
5詳細設計
總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」
這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。
通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。
6編碼和單元測試
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。
程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。
7綜合測試
這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。
最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。
必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。
為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。
通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。
應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。
8軟體維護
維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。
通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。
雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。
『捌』 軟體工程試題，誰知道答案
一, 單項選擇題(每題1分,共10分):
1. ( ) 計算機系統就是:
A) 主機,顯示器,硬碟,軟碟機,列印機等.
B) CPU,存儲器,控制器,I/O介面及設備.
C) 計算機硬體系統和軟體系統.
D) 計算機及其應用系統.
2.( )產生軟體危機的原因主要與兩個方面的問題有關:
A) 軟體在計算機中很難識別,存在磁碟中也看不到.
B) 軟體設計對人的智商要求很高,也要求很高的資金投入.
C) 軟體產品本身的特點與其它工業產品不一樣,而且在軟體的開發和維護過程中用
的方法不正確.
D) 軟體很難理解,硬體也很復雜.
3.( )軟體開發瀑布模型中的軟體定義時期各個階段依次是:
A) 可行性研究,問題定義,需求分析.
B) 問題定義,可行性研究,需求分析.
C) 可行性研究,需求分析,問題定義.
D) 以上順序都不對.
4.( )軟體維護的四類維護活動是:
A) 改正性維護,適應性維護,完善性維護和預防性維護.
B) 適應性維護,完善性維護,搶救性維護和輔助性維護.
C) 改正性維護,適應性維護,完善性維護和輔助性維護.
D) 適應性維護,完善性維護,搶救性維護和預防性維護.
5.( ) 可行性研究主要從以下幾個方面進行研究:
A) 技術可行性,經濟可行性,操作可行性.
B) 技術可行性,經濟可行性,系統可行性.
C) 經濟可行性,系統可行性,操作可行性.
D) 經濟可行性,系統可行性,時間可行性.
6.( ) 系統邏輯模型主要由以下內容:
A) 數據流程圖,數據字典,簡要的演算法描述.
B) 程序流程圖,Jackson圖,IPO圖.
C) 數據流程圖,數據字典,ER圖.
D) Jackson圖,ER圖,IPO圖.
7. ( ) 耦合是對軟體不同模塊之間互連程度的度量.各種耦合按從強到弱排列如下:
A) 內容耦合,控制耦合,數據耦合,公共環境耦合.
B) 內容耦合,控制耦合,公共環境耦合,數據耦合.
C) 內容耦合,公共環境耦合,控制耦合,數據耦合.
D) 控制耦合,內容耦合,數據耦合,公共環境耦合.
8. ( ) 在詳細設計階段所使用到的設計工具是:
A) 程序流程圖,PAD圖,N-S圖,HIPO圖,判定表,判定樹.
B) 數據流程圖,Yourdon 圖,程序流程圖,PAD圖,N-S圖,HIPO圖.
C) 判定表,判定樹,數據流程圖,系統流程圖,程序流程圖,PAD圖,N-S圖.
D) 判定表,判定樹,數據流程圖,系統流程圖,程序流程圖,層次圖.
9. ( ) 按照軟體工程的原則,模塊的作用域和模塊的控制域之間的關系是:
A) 模塊的作用域應在模塊的控制域之內.
B) 模塊的控制域應在模塊的作用域之內.
C) 模塊的控制域與模塊的作用域互相獨立.
D) 以上說法都不對.
10. ( ) 包含所有可能情況的測試稱為窮盡測試.下面結論成立的是:
A) 只要對每種可能的情況都進行測試,就可以得出程序是否符合要求的結論.
B) 一般來說對於黑盒測試,窮盡測試是不可能作到的.
C) 一般來說對於白盒測試,窮盡測試是不可能作到的.
D) 在白盒測試和黑盒測試這兩個方法中,存在某一個是可以進行窮盡測試的.
二, 填空題(每題1分,共10分)
1.軟體危機是指在( )所遇到的一系列嚴重問題.
2.在軟體開發的各個階段經過階段評審後的文檔和程序代碼成為( ).
3.結構程序設計的基本思想是( ).
4.總體設計的第二項任務是設計軟體的結構,即確定( ).
5.描繪物理系統的傳統工具是( ).
6.如果模塊內所有元素都使用同一個輸入數據和產生同一個輸出,稱為( )內聚.
7.數據流程圖按照信息流的類型主要分為( )兩種.
8.( )年,( )和( )證明了SISO程序只需要三種基本控制結構.
9. 從應用特點分類,高級語言主要分為( ),( )和( )三類.
10. 黑盒測試又稱為( ),白盒測試也稱為( ).
三, 多項選擇題(以下各題均有兩個以上的正確答案.將正確答案的標號填入各題前面括弧
內,注意多選或少選該題均不得分,每題2分,共20分):
1.( )軟體開發各個階段所耗費的時間或工作量是:
A) 可行性研究佔5%;
B) 綜合測試佔40%;
C) 設計階段在所有開發階段所佔的比例最大.
D) 編碼和單元測試佔20%.
E) 以上說法都不對.
2.( )對軟體開發與維護,以下觀點是正確的:
A) 為了加快開發速度,可以一邊寫程序,一邊設計文檔.
B) 對於軟體而言,程序和軟體配置成分是同等重要的,不能重此偏0.
C) 把軟體漫長的生命周期劃分為若干個階段的出發點是降低開發的困難程度和
簡化復雜性.
D) 可行性研究的主要任務就是確定軟體項目的工程規模和目標.
E) 面向對象的方法學比傳統的軟體開發方法開發軟體容易,開發效率提高.
3.( ) 對於以下圖形工具的作用,
A) 數據流程圖和數據字典共同構成軟體的高層數據模型.
B) 層次圖是用來描述軟體結構的,不能用於描述數據結構.
C) IPO圖能方便地描繪輸入數據,對數據的處理和輸出數據的關系,它是美國微
軟公司發明並逐漸發展完善起來的.
D) ER圖描述現實世界中的實體,不涉及這些實體在系統中的實現方法.
E) Yourdon圖實際上也是結構圖,所以它與層次方框圖是等價的.
4.( ) 面向數據結構的設計方法有:
A) Jackson方法.
B) Warnier方法.
C) Halstead方法.
D) PAD方法.
E) G. M y e r s方法.
5.( )以下測試方法是白盒測試方法的是:
A) 判定覆蓋和邊界值分析法.
B) 等價劃分和錯誤推測法.
C) 路徑覆蓋和判定/條件覆蓋法.
D) 條件組合覆蓋和語句覆蓋法.
E) 條件覆蓋和錯誤推測法.
6.( )以下關於集成測試的論述,正確的是:
A) 先對每個模塊分別測試,然後統一組裝成軟體系統的方法稱為非漸增式測試.
B) 自頂向下的集成測試本質上是漸增式測試方法.
C) 存根模塊是漸增式測試方法中使用的,在非漸增式測試中也用不到樁模塊.
D) 一般來說,存根模塊和樁模塊在用過以後,不會作為軟體的正式模塊而存在.
E) 由於是對程序進行測試,測試方案的設計一般在詳細設計階段完成以後才進行.
7. ( ) 對於程序設計,正確的陳述是:
A) 為了減少程序的長度,最好不要在程序中增加註釋.
B) 變數名以簡潔為好,名字太長了難以理解,增加了程序的復雜性.
C) 程序語句要求體現層次性,以使結構清晰明顯.
D) 數據結構的組織和復雜程度在設計期間確定,但數據說明的風格是在寫程序時確
定的.
E) 對所有的輸入數據都要進行檢驗,以便確定其合法性.
8. ( ) 內聚標志一個模塊內各個元素彼此結合的緊密程度.
A) 內聚是信息隱蔽和局部化概念的自然擴展.理想內聚的模塊只做臆見事情.
B) 一個模塊所包含的任務必須在同一段時間內執行,該模塊的內聚為時間內聚.
C) 一個模塊內的處理元素是相關的,必須以特定次序執行,稱為過程內聚.
D) 順序內聚和功能內聚是高內聚,而偶然內聚和邏輯內聚是低內聚.
E) 時間內聚,通信內聚,過程內聚是中等程度的內聚.
9. ( )McCabe方法對程序復雜程度的定量度量的結果稱為程序的環行復雜度,
其計算公式是:V(G)=m-n+p.
A) 應用McCabe方法的前提是對應的程序圖變換成強連通圖.
B) V(G)代表程序圖G的線性無關環的個數.
C) 一般對於結構化程序,p恆等於1.
D) m是有向圖G中的弧數.
E) n是有向圖G中的節點數.
10.( )詳細設計階段的根本目標是確定應該怎樣具體的實現所要求的系統.
A) 詳細設計階段不具體的編寫程序.
B) 詳細設計階段的設計結果基本決定了最終的程序代碼質量.
C) 詳細設計的目標不僅要邏輯上正確的實現每個模塊的功能,而且對每個模塊的處
理過程也應確保簡明易懂,清晰具體.
D) 詳細設計的關鍵技術是結構程序設計技術.
四, 基本概念題(每題2分,共10分)
1. 軟體工程.
2. 軟體測試.
3. 數據流圖及其組成和作用.
4. 結構化分析方法.
5. 信息隱蔽原理.
五, 敘述分析題:(每題5分,共20分)
1. 試述對用戶要求沒有完整的認識就匆忙著手編寫程序是許多軟體開發工程失敗的主要
原因.
2. 簡述軟體可靠性和可用性的定義,平均無故障時間的計算公式及應用.
3. 簡述軟體重用的定義,范圍和主要技術.
4. 說明軟體測試在軟體開發階段的地位和作用.比較測試和調試的異同點.
六, 設計,作圖,計算題(每題5分,共30分)
1.以下是某系統的數據流程圖,請將其轉換成相應的SC圖.
2. 研究下面的偽碼程序,完成以下問題:
START
INPUT X,N
DIMENSION A(N),F(N)
DO I=1 TO N
INPUT F(I)
END DO
K=0
DO WHILE (KA(K)=0
DO J=1 TO N-K
A(K)=A(K)+F(J)*F(J+K)/(N-K+1)
END DO
PRINT K*X,A(K)
K=K+1
END DO
STOP
A) 畫出等價的控制流程圖,.
B) 判斷是否結構化的,說明理由.
C) 寫出對應的PAD圖.
D) 用McCabe方法計算環行復雜度.
3. 為方便儲戶,某銀行擬開發計算機儲蓄系統.儲戶填寫的存款單或取款單由業務員鍵
入系統.如果是存款,系統記錄存款人姓名,住址,存款類型,存款日期,利率等信
息,並印出存款單給儲戶;如果是取款,系統計算利息並印出利息清單給儲戶.
1)畫出該系統的高層數據流程圖和第二層細化流程圖.
2)對數據流定義數據字典.
4. 某航空公司規定,乘客可以免費托運不超過20公斤的行李.當行李重量超過20公斤
時,對頭等艙的乘客超重部分每公斤收費4元,其它艙的乘客收費6元.對殘疾乘客超重部分
在艙位等次相同的情況下收費減半.用判定表描述行李托運費的處理過程.
5.設計程序,先讀入三個整數值代表一個三角形的三條邊,然後根據這三個值判斷該三
角形屬於不等邊,等腰或等邊三角形中的哪一種.請設計滿足判定/條件覆蓋標準的測試
方案.
6.設模塊RootForSquare(int a,int b,int c,int *x,int *y) 的功能是一元二次方程求根.請使用
等價劃分法來設計測試方案.