第一章軟體工程學概述
1． 軟體危機
（1） 軟體危機的介紹
1）軟體危機：在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。
2）軟體危機的兩個主要問題：如何開發軟體，以滿足對軟體日益增長的需求；
如何維護數量不斷膨脹的已有軟體。
3）軟體危機的典型表現：
(1) 對軟體開發成本和進度的估計常常很不準確。
(2) 使用者對「已完成的」軟體系統不滿意的現象經常發生。
(3) 軟體產品的質量往往靠不住。
(4) 軟體常常是不可維護的。
(5) 軟體通常沒有適當的文件資料。
(6) 軟體成本在計算機系統總成本中所佔的比例逐年上公升。
(7) 軟體開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。
（2） 產生軟體危機的原因
軟體本身特點：
1） 缺乏可見性，在執行之前往往難以衡量，質量也難以評價
2） 不會因為長期使用而用壞，軟體維護通常意味著修正或修改原來的設計，較難維護。
3） 規模龐大，需分工合作，如何保證每個人的工作合在一起是極端複雜的問題。
軟體開發與維護的方法不正確
產生軟體危機的原因可歸結為兩個重要的方面：軟體生產本身存在的複雜性；
軟體開發所使用的方法和技術。
軟體生命週期：乙個軟體從定義、開發、使用和維護直到最早被廢棄。
軟體產品必須由乙個完整的配置組成（程式、文件、資料）
（3） 消除軟體危機的途徑
1） 正確認識計算機軟體
2） 認識到軟體開發是乙個協同配合、共同完成的工程專案並吸取經驗。
3） 推廣使用已總結的開發軟體成功的技術和方法
4） 開發使用更好的軟體工具
2． 軟體工程
（1） 軟體工程的介紹
軟體工程是指導計算機軟體開發和維護的一門工程學科。採用工程的概念、原理、技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地、高效的開發出高質量的軟體並有效地維護它，這就是軟體工程。
本質特性：
1） 軟體工程關注於大型程式的構造
2） 軟體工程的中心課題是控制複雜性
3） 軟體經常變化
4） 開發軟體的效率非常重要
5） 和諧地合作是開發軟體的關鍵
6） 軟體必須有效地支援它的使用者
7） 在軟體工程領域中通常由具有一種文化背景的人替具有另一種文化背景的人創造產品。
（2） 軟體工程的基本原理
1） 用分階段的生命週期計畫嚴格管理
2） 堅持進行階段評審
3） 實行嚴格的產品控制
4） 採用現代程式設計技術
5） 結果應能清楚地審查
6） 開發小組的人員應該少而精
7） 承認不斷改進軟體工程實踐的必要性
（3） 軟體工程方法學
在軟體生命週期全過程中使用的一整套技術方法的集合稱為方法學。
軟體工程方法學，三要素：方法、工具和過程。
1） 傳統方法學
2） 物件導向方法學
3． 軟體生命週期：定義、開發、維護
（1） 問題定義
（2） 可行性研究
（3） 需求分析
（4） 總體設計
（5） 詳細設計
（6） 編碼和單元測試
（7） 綜合測試
（8） 軟體維護
4． 軟體過程：為了獲得高質量軟體所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。通常使用生命週期模型簡潔的描述軟體過程。
（1） 瀑布模型
1)各個階段的順序性和依賴性；
2)劃分邏輯設計與物理設計，盡可能推遲程式的物理實現；
3)每個階段必須完成規定的文件，對其中問題通過複審及早發現，及早解決。
（2） 快速還原模型
（3） 增量模型
(1) 從部分需求出發，先建立乙個不完全的系統，通過測試執行該系統取得經驗和資訊反饋，加深對軟體需求的理解，進一步使系統擴充和完善。如此反覆，直至軟體人員和使用者對所設計完成的軟體系統滿意為止。
(2) 在漸增型開發下的軟體是隨軟體開發的過程而逐漸形成的。
(3) 漸增型開發方法適合於知識型軟體的開發，設計系統時對使用者需求的認識開始不是很清楚的，需要在開發過程中不斷認識、不斷獲得新的知識去豐富和完善系統。多數研究性質的試驗軟體，一般採用此方法。
（4） 螺旋模型
（5） 噴泉模型
（6） rational統一過程
（7） 敏捷過程與極限程式設計
（8） 微軟過程
第二章可行性研究
可行性研究的目的，就是用最小的代價在盡可能短的時間內確定問題是否能夠解決。
問題定義的任務：將使用者提出的要求具體化、定量化；確定研製系統的範圍，明確研製的邊界。
問題定義階段的工作：
1) 通過調查研究，了解系統需求；
2) 確定系統的功能需求、效能需求、可靠性需求、安全及保密性、資源、開發費用及開發進度等的需求；
3) 問題定義階段的產品--系統目標與範圍說明書。
1. 可行性研究的任務
（1） 技術可行性
（2） 經濟可行性
（3） 操作可行性
2. 可行性研究的過程
（1） 複查系統規模和目標
（2） 研究目前正在使用的系統
（3） 匯出新系統的高層邏輯模型
（4） 進一步定義問題
（5） 匯出和評價供選擇的解法
（6） 推薦行動方針
（7） 草擬開發計畫
（8） 書寫文件提交審查
3. 系統流程圖
系統流程圖是描述物理系統的傳統工具。它的基本思想是用圖形符號以黑盒子形式描繪系統裡的每個部件（程式、檔案、資料庫、**、人工過程等）。系統流程圖表達的是部件的資訊流程，而不表示對資訊進行加工處理的控制過程。
4. 資料流圖
dfd是一種圖形化技術，它描繪資訊流和資料從輸入移動到輸出的過程中所經受的變換。
與程式流程圖不同，dfd不表示程式的控制結構，只描述資料的流動
dfd分成多層(子圖、父圖概念)表示, 從而逐步展開資料流和功能的細節。
繪製資料流圖步驟
（1）確定所開發的系統的外部項（外部實體），即系統的資料**和去處。
（2）確定整個系統的輸出資料流和輸入資料流，把系統作為乙個加工環節，畫出關聯圖。
（3）確定系統的主要資訊處理功能，按此將整個系統分解成幾個加工環節（子系統）確定每個加工的輸出與輸入資料流以及與這些加工有關的資料儲存。
（4） 根據自頂向下，逐層分解的原則，對上層圖中全部或部分加工環節進行分解。
（5） 重複步驟（4），直到逐層分解結束。
（6） 對圖進行檢查和合理布局，主要檢查分解是否恰當、徹底，dfd中各層是否有遺漏、重複、衝突之處，各層dfd及同層dfd之間關係是否爭取及命名、編號是否確切、合理等，對錯誤與不當之處進行修改。
（7） 和使用者進行交流，在使用者完全理解資料圖的內容的基礎上徵求使用者的意見。
注意事項：
（1） 不要把控制流作為資料流
（2） 不要標出激發條件
（3） 資料流必須要麼從某個加工流出、要麼流入某個加工，而不能直接從外部項流向資料儲存等等。
5. 資料字典（對資料的定義）
資料字典是關於資料的資訊的集合，也就是對資料流圖中包含的所有元素的定義的集合。
（1） 資料字典的內容
資料流、資料流分量（資料元素）、資料儲存、處理
資料字典要對資料流圖中出現的所有名字（資料流，加工，檔案）進行定義。
資料字典的條目由三大類組成，分別是：資料流條目、資料項條目、檔案條目、加工條目（**明）。
（2） 定義資料的方法
+ ：和，連線兩個分量
= ：等價於
[ ]：或，用|隔開分量
：重複花括號內的分量 07表示8位字串
（）：可選，即可有可無
（3） 資料字典的用途
（4） 資料字典的實現
6. 成本/效益分析
（1） 成本估計
1） **行技術
2） 任務分解技術
3） 自動估計成本技術
（2） 成本/效益分析方法
1） 貨幣時間價值
f=p(1+i)n次方
2） 投資**期
3） 純收入
4） 投資**率
第三章需求分析
1.1)需求分析目的：
可行性分析研究階段已經粗略的描述了使用者的需求，甚至還提出了一些可行的方案，但是，許多細節被忽略了，在最終目標系統中是不能忽略、遺漏任何乙個微小細節的，所以，可行性研究不能代替需求分析。
需求分析的任務還不是確定系統怎樣完成它的工作，而僅僅是確定系統必須完成哪些工作，也就是對目標提出完整、準確、清晰、具體的要求。
通過需求分析，明確使用者對目標軟體系統在功能、效能、行為、設計約束等方面的期望，回答軟體系統「必須做什麼」。
開發人員準確的理解使用者的要求，進行細緻的調查分析，講使用者形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的需求規格說明的過程。
2)需求分析的方法：
需求分析方法由對軟體的資料域和功能域的系統分析過程及其表示方法組成，它定義了表示系統邏輯檢視和物理檢視的方式，大多數的需求分析方法是由資料驅動的，也就是說，這些方法提供了一種表示資料域的機制，分析員根據這種表示，確定軟體功能及其特性，最終建立乙個待開發軟體的抽象模型，即目標系統的邏輯模型。
2.需求分析的任務
問題識別、分析與綜合匯出軟體邏輯模型、編寫文件
它的基本任務是準確地回答「系統必須做什麼？」這個問題。需求分析所要做的工作是深入描述軟體的共能和效能，確定軟體設計的限制和軟體同其它系統元素的介面細節，定義軟體的其它有效性需求。
需求分析的任務不是確定系統如何完成它的工作，而是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。其實現步驟如下圖所示：
(1) 確定對系統的綜合要求
系統功能需求
系統效能需求
可靠性和可用性需求、
錯處理需求
介面需求、
約束逆向需求
將來可能提出的需求
(2) 分析系統的資料需求
就是在理解當前系統「怎樣做」的基礎上，抽取其「做什麼」的本質，明確目標系統要「做什麼」，可以匯出系統的詳細的邏輯模型。具體做法：首先確定目標系統與當前系統的邏輯差別；然後將變化部分看作是新的處理步驟，對功能圖（一般為資料流圖）及物件圖進行調整；最後有外及裡對變化的部分進行分析，推斷其結構，獲得目標系統的邏輯模型。
通常用資料流圖、數字字典和主要的處理演算法描述這個邏輯模型。
分析系統的資料要求通常採用建立資料模型的方法，常常利用圖形工具輔助描繪資料結構。
(3)匯出系統的邏輯模型
(4)修正系統開發計畫
3.與使用者溝通獲取需求的方法
(1)訪談
正式和非正式訪談、發調查表、情景分析
(2) 面向資料流自頂向下求精
結構化分析:使用資料流程圖、資料字典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文件-需求規格說明書。
結構化分析法就是面向資料流自頂向下逐步求精進行需求分析的方法，把資料流和資料儲存定義到元素級
(3)簡易的應用規格說明技術
(4)快速建立軟體原型
4．分析建模與規格說明
(1)分析建模
資料模型（er圖）、功能模型（資料流圖，描繪當資料在軟體系統中移動時被變換的邏輯過程，指明系統具有的變換資料的功能）、行為模型（狀態圖，指明了作為外部事件結果的系統行為）
(3) 軟體需求規格說明書
為了消除用自然語言書寫的軟體需求規格說明書中可能存在的不一致、歧義、含糊、不完整及抽象層次混亂等問題，用形式化方法描述使用者對軟體系統的需求。
5.實體—聯絡圖（資料物件及資料物件之間的關係）
(1)資料物件
一系列不同性質或屬性的事務
(4) 屬性
資料物件的性質
(5) 聯絡
資料物件彼此之間相互連線的方式稱為聯絡，也稱為關係
6.資料規範化
為了減少資料冗餘，避免出現插入或刪除異常，簡化修改資料的過程，通常需要把資料結構規範化。
工程竣工的主要內容
以單位工程為例，市政工程竣工資料報括以下主要內容。2 1施工組織設計 必須是經上一級技術負責人審批，加蓋公章並填寫了施工組織設計審批表，開工前報監理部門審批完成的，才能成為歸檔資料。2 2 圖紙會審 技術交底記錄 應儲存由建設單位組織有關單位對設計檔案進行會審的記錄。技術交底是由施工單位在開工前對專...
軟體工程導論重點內容
第一章軟體工程概述 一 什麼是軟體？1.滿足功能要求和效能的指令或電腦程式集合 2.處理資訊的資料結構 3.描述程式功能以及程式如何操作和使用所要求的文件 軟體的特點 軟體是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性。軟體是通過人們的智力活動，把知識與技術轉換成資訊的一種產品，是在研製 開...
人防工程監理歸檔主要內容
1 工程施工許可證。2 勘察合同 設人防部門對施工圖設計的審查意見。3 設計合同 施工合同及監理合同。4 監理規劃 監理月報 監理工作總結。5 設計交底與圖紙會審會議紀要。6 開竣工報告。7 工程進度計畫。8 工程變更資料。9 會議紀要。10 檢驗批質量驗收記錄。11 分項 分部及單位工程質量驗收記...