軟體工程導論復習整理
- 軟體工程導論復習整理（第一、二、三章）
- 第一章 軟體工程學概述
- 1.1 軟體危機
- 1.2軟體工程
- 第二章 可行性研究
- 2.1可行性研究的任務
- 2.2可行性研究程序
- 2.3系統流程圖
- 2.4資料流圖
- 2.5資料字典
- 2.6成本/效益分析
- 第三章 需求分析
- 3.1需求分析的任務
- 3.1.1 確定對系統的綜合要求
- 3.1.2 分析系統的資料要求
- 3.1.3 匯出系統的邏輯模型
- 3.1.4 修改系統開發計劃
- 3.2 與用戶溝通獲取需求的方法
- 3.3分析建模與規格說明
軟體工程導論復習整理（第一、二、三章）
第一章 軟體工程學概述
1.1 軟體危機
1、軟體危機：指在計算機軟體的開發和維護程序中所遇到的一系列嚴重問題，
2、軟體危機的典型表現：
（1）對軟體開發成本和進度的估計常常很不準確，
（2）用戶對“已完成的”軟體系統不滿意的現象經常發生，
（3）軟體產品的質量往往靠不住，
（4）軟體常常是不可維護的，
（5）軟體通常沒有適當的檔案資料，
（6）軟體成本在計算機系統總成本中所占的比例逐年上升，
（7）軟體開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢，
3、產生軟體危機的原因：
(1)?軟體不同于硬體，它是計算機系統的邏輯部件而不是物理部件，
(2)?軟體開發的程序是多人分工合作，分階段完成的程序，參與人員之間的溝通和配合十分重要，??
(3)?開發和管理人員只重視開發而輕視問題的定義，使軟體產品無法滿足用戶的要求，
(4)?軟體管理技術不能滿足現代軟體開發的需要，沒有統一的軟體質量管理規范，
(5)?在軟體的開發和維護關系問題上存在錯誤的觀念，
為了解決軟體危機，既要有技術措施（方法和工具），又要有必要的組織管理措施，軟體工程正是從__管理和技術__兩方面研究如何更好地開發和維護計算機軟體的一門新興學科，
1.2軟體工程
1、軟體工程（概念）：軟體工程是指導計算機軟體開發和維護的一門學科，采用工程的概念、原理、技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟體并有效的維護它，
2、軟體工程的7潭訓本原理
（1）用分階段的生命周期計劃嚴格管理
（2）堅持進行階段評審
（3）實行嚴格的產品控制
（4）采用現在程式設計技術
（5）結果應能清楚地審查
（6）開發小組的人員應該少而精
（7）承認不斷改進軟體工程實踐的必要性
軟體是程式、資料、相關檔案的完整集合，
軟體工程方法學包含3個要素：方法、工具和程序，
軟體工程方法學：
1.傳統方法學(資料流方法學或結構化范型)——強調自頂向下
? SA->SD->SP
2.面向物件方法學——強調主動地多次反復迭代
? OOA->OOD->OOP->OOT
3、軟體生命周期
三個時期八個階段：軟體生命周期由軟體定義、軟體開發和運行維護(也稱為軟體維護)三個時期組成，每個時期又進一步劃分成若干個階段， （明確每個階段的任務）
4、維護階段的關鍵任務：通過各種必要的維護活動使系統持久的滿足用戶的需要，
4類維護活動：1.改正性維護 2.適應性維護 3.完善性維護 4.預防性維護
軟體程序（P15）
| 模型名稱 | 優點 | 缺點 | 使用范圍 |
|---|---|---|---|
| 瀑布模型（檔案驅動） | 可強迫開發人員采用規范的方法；嚴格規定了每個階段必須提交的檔案；要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證 | 缺乏靈活性、失敗率高 | 適用于需求明確/需求凍結的軟體開發、檔案驅動 |
| 快速原型模型（用戶驅動） | 減少由于軟體需求不明確帶來的開發風險；軟體開發成本較低；快速； | 所選的開發技術和工具不一定符合主流的發展，快速建立的系統結構加上連續的修改可能會導致產品質量低下 | 適用于需求不明確的軟體開發、需求驅動 |
| 增量模型（構建驅動） | 能在較短時間內向用戶提交可完成部分作業的作品；每次只提交部分功能，使用戶有較充足的時間學習和適應新產品，減少給用戶帶來的沖擊；提高系統可維護性，當需求變更時只變更部分部件，不必影響整個系統 | 在把每個新的增量構件集成到現有的軟體體系中時，要求必須不破壞原來已經開發出的產品；軟體體系結構必須是開放的 | 適用于團隊小、用戶希望較早開始使用的情況、設計方案有一定風險的軟體專案 |
| 螺旋模型（風險驅動） | 引入了風險分析；設計靈活，可以在專案各個階段變更；成本計算容易；保證了專案的可控性 | 建設周期長，很容易引起軟體開發完畢后和當前的技術水平差距大，無法滿足當前用戶需求 | 適用于內部開發的大規模軟體專案、風險驅動 |
| 噴泉模型（物件驅動） | 各個階段沒有明顯界限，開發人員可以同步進行開發；提高軟體專案開發效率；節省開發時間 | 各個開發階段是重疊的，所以對開發人員需求大，不利于專案管理 | 適用于面向物件的軟體開發、物件驅動 |
| V模型（測驗驅動） | 整個開發程序中貫穿測驗；能盡早發現缺陷進行修復；測驗與開發獨立起來，并與開發并行 | 由于需求變數較大，導致要重復變更需求、設計、編碼、測驗，返工量大 | 測驗驅動 |
5、RUP統一程序（重點）
6、極限編程的四個價值觀：
（1）個體和互動勝過程序和工具；
（2）可以作業的軟體勝過面面俱到的檔案；
（3）客戶合作勝過合同談判；
（4）回應變化勝過遵循計劃，
第二章 可行性研究
2.1可行性研究的任務
1、可行性研究的目標：用最小的代價在盡可能短的時間內確定問題是否能夠解決，
2、可行性研究的方面：技術可行性，經濟可行性，操作可行性，社會因素可行性，
2.2可行性研究程序
1.復查系統規模和目標
2.研究目前正在使用的系統
3.匯出新系統的高層邏輯模型
4.進一步定義問題
5.匯出和評價供選擇的解法
6.推薦行動方針
7.草擬開發計劃
8.書寫檔案提交審查
2.3系統流程圖
系統流程圖：是概括地描繪物理系統的傳統工具，表達的是資料在系統各部件之間流動的情況，而不是對資料進行加工處理的控制程序，
2.4資料流圖
（1）基本符號：
資料存盤：資料存盤是處于靜止狀態的資料； 資料流：資料流是處于運動中的資料，
資料流圖所描述的是實際系統的邏輯關系，
（2）附加符號： 星號（*）：表示“與”關系；
? 加號（+）：表示“或”關系；
? 異或（⊕）：表示互斥關系，
（3）原則：
① 資料流一定和加工有關
② 資料守恒和資料封閉（黑洞、灰洞和奇跡）
③ 子圖和父圖的平衡（父圖的加工可分解）
④ 合理使用存盤
⑤ 加工分解的原則：自然性；均勻性；分解度不超過7個，
2.5資料字典
資料字典
（1）定義：關于資料的資訊集合，也就是對資料流圖中包含的所有元素的定義集合，
資料流圖和資料字典共同構成系統的邏輯模型，
（2）資料字典的組成：資料流；資料流分量(即資料元素)；資料存盤；處理，
2.6成本/效益分析
每行代碼的平均成本主要取決于軟體的復雜程度和工資水平，
P50頁 表2.2
第三章 需求分析
需求分析是軟體定義時期的最后一個階段，
①它的基本任務是準確地回答“系統必須做什么”這個問題
②對目標系統提出完整、準確、清晰、具體的要求
③系統分析員應該寫出軟體需求規格說明書，以書面形式準確地描述軟體需求，
3.1需求分析的任務
3.1.1 確定對系統的綜合要求
1.功能需求 要求收集、整理分析需求、生成需求規格說明書
2.性能需求 性能點串列
3.可靠性和可用性需求
4.出錯處理需求
5.介面需求 介面串列
6.約束
7.逆向需求
8.將來可能提出的要求
3.1.2 分析系統的資料要求
常用的圖形工具有層次方框圖和Warnier
3.1.3 匯出系統的邏輯模型
通常用資料流圖、物體-聯系圖、狀態轉換圖、資料字典和主要的處理演算法描述這個邏輯模型，
3.1.4 修改系統開發計劃
3.2 與用戶溝通獲取需求的方法
1.訪談
2.面向資料流自頂向下求精
3.簡易的應用規格說明技術
4.快速建立軟體原型
3.3分析建模與規格說明
1、分析建模
（1）資料模型：E-R圖；
? 功能模型：資料流圖；
? 行為模型：狀態轉換圖；資料字典，
（2）DFD和E-R描述了系統的靜態方面的資訊，STD（狀態轉換圖）描述了系統行為方面的資訊，
（3）資料字典是分析模型的核心；物體-聯系圖用于建立資料模型的圖形；資料流圖是建立功能模型的基礎；狀態轉換圖是行為建模的基礎 ，
2、分析系統的資料要求
建立資料模型——ER圖 描繪資料結構——層次方框圖和Warnier圖 資料結構規范化
3、其他圖形工具（了解）
層次方框圖
IPO圖（輸入、處理、輸出圖）
4、驗證軟體需求
一致性：需求必須是一致的，任何一條需求不能和其他需求互相矛盾
完整性：需求必須是完整的
現實性：需求應該是現有的硬體技術和軟體技識訓本可以實作的
有效性：必須證明需求是正確有效的
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/201796.html
標籤：其他