特點：軟體是乙個邏輯的而不是物理的產品1) 軟體的開發成本和開發進度的估計常常很不準確
2) 使用者對「已完成」軟體系統不滿意的現象常常發生
3) 軟體產品的質量往往靠不住
4) 軟體通常沒有適當的文件資料
5) 軟體常常是不可維護的
6) 其他定義：採用工程的概念、原理、技術和方法來開發和維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠用得到的技術方法結合起來，來指導軟體的開發與維護。1) 用分階段的生命週期計畫嚴格管理
2) 堅持進行階段評審
3) 實行嚴格的產品控制
4) 採用現代的程式設計技術
5) 結果能夠清楚的審查
6) 開發小組的人員應該少而精
7) 承認不斷改進軟體工程實踐必要性常見的軟體生存週期模型有瀑布模型、演化模型、螺旋模型、噴泉模型等po、 oo軟體活動過程描述：
1) 成果：軟體過程活動的產品
2) 角色：軟體過程中的參與人及職責
3) 前置條件：活動能夠開展的前提條件
4) 後置條件：活動成功完成後對軟體系統開發帶來的影響
軟體過程模型概念：軟體過程模型是軟體開發全部過程、活動和任務的結構框架。它能直觀的表達軟體開發全過程，明確規定要完成的主要活動、任務和開發策略。(1)瀑布模型
(2)增量模型
(3)原型模型
適用領域：事先不能完整定義需求的領域
(4)螺旋模型
(5)瀑布模型rup的核心工作流程：
1) 商業建模：對系統的商業環境和範圍進行建模，確保所有參與人員對開發系統有共同的認識
2) 需求分析:定義系統功能及其他非功能需求，成果是軟體需求說明書
3) 分析與設計：根據系統需求給出實現方案，成果為軟體設計說明書
4) 實施：定義**的組織結構、實現**、單元測試、系統整合
5) 測試：驗證各個子系統的互動整合。測試分別從可靠性、功能性和系統效能來進行。
6) 部署：成功的生成版本並將軟體分發給終端使用者
7) 配置和變更管理：管理並行開發、分布式開發；自動化建立工程；記錄產品修改的原因、時間、人員、審計記錄
8) 專案管理：為計畫、執行和監控軟體開發專案提供有效支援
9) 環境：為組織提供過程管理和工具的支援
特點：
1) 物件導向：從技術角度，rup的軟體系統開發是基於物件導向技術的。rup使用和支援物件導向，且建立的設計、實現模型均是物件模型。
2) use case驅動：系統開發從建立業務領域的用例模型開始。用例模型表達了系統的需求，後面的各種工作圍繞如何實現用例模型展開
3) 以體系結構為中心：系統開發過程中，體系結構用作開發的基石。系統的概念化、構造和管理均圍繞系統體系結構進行
4) 迭代式、增量式的開發過程：rup採用迭代式、增量式的思想，開發過程有一連迭代增量構成
5) 以質量控制和風險管理為目標：質量控制貫穿於軟體開發的全過程。在每一次迭代週期，都要進行質量評估；在軟體專案立項之初，就盡可能識別專案的開發風險，找出避免、克服或減少風險的對策
6) 與uml配套：uml的概念和表示方法與rup相結合形成一種高效的軟體系統開發方法和技術。
7) 適用性強：rup可適用於各型別和各種規模的軟體開發。rup採用管理與技術相結合的二維方法，特別適合處理需求變動比較大的高風險專案策略：
1) 小規模，頻繁的版本發布，短迭代週期
2) 測試驅動開發（test-driven development）
3) 結對程式設計（pair programming）
4) 持續整合（continuous integration）
5) 每日站立會議（daily stand-up meeting）
6) 共同擁有**collative code ownership
7) 系統隱喻（system metaphor）
特點：
1) 敏捷開發方法是「適應性」(adaptive)而非「預設性」(predictive)
2) 敏捷開發方法是「面向人」(people oriented)而非「面向過程」(process oriented)。任務：可行性研究的只要任務是「了解客戶的要求及實現環境，從技術、經濟和社會因素等三方面研究並論證本軟體專案的可行性，編寫可行性研究報告，制定初步的專案開發計畫」
方法：
1) 確定軟體的目標和規模
2) 研究分析現有系統
3) 匯出新系統的高層邏輯模型
4) 重新定義問題
5) 匯出和評價供選擇的方案
6) 推薦行動方針
7) 草擬開發計畫
8) 撰寫《可行性研究報告》
意義：任務：清楚的理解使用者要解決的問題，完整準確的獲取使用者的需求，並用《軟體需求規格說明書》規範的形式準確的表達使用者的需求。
主要活動：需求獲取，需求描述，需求有效性驗證
方法：
活動：內容：功能需求，非功能需求
層次：業務需求，使用者需求，系統需求策略：
1. 使用者訪談
2. 使用者調查
3. 其他方法內容：檢測需求是否正確、完備和一致，且為後續設計開發和測試提供了足夠的基礎。通常為軟體公司內部審查過程
方法：快速原型，需求評審內容：組織記錄軟體需求，控制變更，並確保軟體開發與軟體需求一致的一系列方法與活動。
流程：需求標識，建立基線，變更控制，需求追蹤
方法：任務：針對需求分析階段提出的系統需求，給出具體的軟體設計方案，解決如何做的問題
內容：互動設計、視覺設計、業務邏輯層設計，資料儲存設計，資料庫設計，任務：將軟體設計的結果翻譯成計算機可以「理解」的形成—使用某種語言描述程式地位：程式的質量主要取決於軟體設計的質量，程式語言的特性和編碼的途徑也對程式的可靠性、可讀性、可測試性和可維護性產生深遠的影響任務：
目的：發現程式中的錯誤
原則：
1) 開發和測試隊伍分別建立
2) 測試用例應由輸入資料和預期的結果兩部分組成
3) 兼顧合理的輸入和不合理的輸入資料
4) 應檢查程式是否做了不該做的事
5) 程式修改後要回歸測試
6) 應長期保留測試用例，直至系統廢棄靜態測試：對需求規格說明書，軟體設計說明書，源程式做結構分析，流程圖分析，符號執行來找錯
動態測試：通過執行軟體來檢驗軟體的動態行為和執行結果的正確性黑盒測試：從使用者的觀點，按規格說明書要求的輸入資料與輸出資料的對應關係設計測試用例，是根據程式外部特徵進行測試。
白盒測試：根據程式內部邏輯結構進行測試目的：通過必要的維護工作時的系統持久的滿足使用者需要特點：
1) 改正性維護：為識別和糾正軟體錯誤，改正軟體效能上的缺陷，排除實施過程中的誤使用
2) 適應性維護：為適應外部條件的變化，而修改軟體
3) 完善性維護：擴充軟體功能，增強軟體效能，改進加工效率，提高軟體的可維護性
4) 預防性維護：採用先進的軟體工程方法對需要維護的軟體或軟體中的一部分重新進行設計，編碼和測試因素：
1) 可理解性
2) 可使用性
3) 可測試性
4) 可移植性
5) 可修改性
6) 效率
7) 可靠性逆向工程，再生工程任務：專案管理是一些列的伴隨著專案的進行而進行的，目的是為了確保專案能夠達到期望的結果的一系列管理行為
軟體工程知識
1.在專案的活 中，乙個專案中時間最長的活動序列決定專案的最短工期。活動最早什麼時候可以開始？前面的最早完成後 時間最長 就開始。活動最多可以晚開始幾天而不影響整個專案的進度?如果該活動在關鍵路徑上的話，鬆弛時間為0 如果不在關鍵路徑上的話，用關鍵路徑的長度減去包含該活動的最長路徑的長度。2.軟體變...
軟體工程第六章知識點總結
第六章 詳細設計 1.詳細設計，詳細設計的根本目標是確定應該怎樣具體地實現所要求的系統。詳細設計階段的任務還不是怎麼具體編寫程式，而是要設計出程式的 藍圖 以後程式設計師根據這個 藍圖 寫出實際的 因此詳細設計的結果基本上決定了最終的程式 的質量。2.結構詳細設計，順序結構 選擇結構 迴圈結構 3....
軟體工程過程知識點整理（一）
軟體過程指軟體生存週期過程，由若干個有序的活動組成，每個活動又包含了若干具體的動作，動作的執行需要依託一系列任務的完成。專案計畫 某個軟體過程模型的例項。早期 立項 需求分析 設計 編碼 測試 交付 維護 退役 又加入了 驗收，配置管理，資源，溝通，文件過程，評審.各種管理活動 質量保證，環境基礎設...