軟體生命週期模型
軟體生命週期的6個階段
各階段基本任務
可行性研究
需求分析
概要設計
詳細設計
實現整合測試
確認測試
軟體維護瀑布模型
採用規範的方法；嚴格規定每個階段提交的文件；要求每個階段交出的產品必須經過驗證。
瀑布模型適合於使用者需求明確、完整、無重大變化的軟體專案開發。瀑布模型的成功在很大程度上是由於它基本上是一種文件驅動的模型。
對如何處理開發中產品和活動的變化沒有提供相關的指導
將軟體開發視為製造而不是創造
創造乙個產品沒有迭代的活動
需要等待很長時間
原型化模型
原型是乙個部分開發的產品
原型化：
使開發者能夠對評估可選的設計策略 (設計原型)
幫助使用者理解系統將會是什麼樣子 (使用者介面原型)
允許需求或設計反覆調查
減少開發中的風險和不確定性
為了使原型盡快的工作，沒有考慮軟體的總體質量和長期的可維護性。
為了演示，可能採用不合適的作業系統、程式語言、效率低的演算法，這些不理想的選擇成了系統的組成部分。
開發過程不便於管理。
增量和迭代模型
增量開發: 先定義乙個小的功能子系統，再在每個新的發布中增加新功能
迭代開發: 一開始就提交完整的系統，再在每乙個新的發布中改變每個子系統的功能
減少迴圈時間
系統一部分一部分地交付: 系統其他部分在開發時，客戶能獲得一部分功能
兩個系統功能可以並行
產品系統 (發布n): 正在執行
開發系統 (發布 n+1): 下乙個版本
即使缺少某些功能，也可以在早期的發布中就可以開始進行培訓
可以及早為那些以前從未提供的功能開拓市場
經常性的發布可以使開發人員全面、快速修復這些問題
開發團隊將重點放在不同的專業領域技術上
螺旋模型 計畫
確定目標、可選方案、約束
評估可選方案和風險
開發和測試
風險驅動，需要相當豐富的風險評估經驗和專門知識，否則風險更大
隨著迭代次數的增加，工作量加大，軟體開發成本增加
對可選方案和約束條件的強調有利於已有軟體的重用，也有助於把軟體質量作為軟體開發的乙個重要目標
減少了過多測試或測試不足
維護和開發之間並沒有本質區別
敏捷軟體過程
敏捷方法的兩大主要特徵是對「適應性」的強調，以及對「人」的關注。敏捷過程非常強調人的作用
敏捷過程將整個軟體生命週期分解為若干個小的迭代週期，通過在每個迭代週期結束時交付階段性成果獲取切實有效的客戶反饋。
其目的是希望通過建立及時的反饋機制，以應對隨時可能的需求變更，並做出相應的調整，從而增強對軟體專案的控制能力。
相對於經典的軟體開發過程的計畫性特徵，該過程在適應性上具有更大的優勢
相對於過程和工具，更強調個人和互動的價值
更喜歡在生產執行的軟體上投入時間 ，而不是在文件的編寫上
注重客戶的合作，而不是合同談判
專注於對變化的反應，而不是建立乙個計畫而後遵循這個計畫
極限程式設計
極限程式設計是敏捷軟體開發中最富有成效的幾種方法學之一.
是「輕量型」和「靈活」的軟體過程模型，並且與物件導向語言結合起來，提供了一種很有特點的軟體開發解決方案。
是用於解決大型軟體開發過程中所遇到的問題的方法，可以稱為「專家協作」的開發方式。
交流包括開發人員與客戶的交流、開發人員之間的交流、開發人員與管理人員的交流。
簡單是指設計簡單、編碼簡單、注釋簡單以及測試簡單。
反饋包括客戶對軟體的反饋，以及測試**對功能**的反饋。
勇氣是指接受任務的勇氣。
軟體工程 第二章
2.1 問題定義 軟體生命週期的計畫階段 問題定義，可行性研究，需求分析三個階段。2.2 可行性研究 2.2.1可行性研究的任務 可行性研究的根本目的並不是解決問題，而是確定問題是否值得去解決，也就是判斷系統原定的目標和規模是否能實現，軟體使用所能帶來的效益是否值得使用者去投資開發。因此，可行性研究...
軟體工程 第二章 軟體計畫
第二章軟體計畫 行 line of code 問題定義 問題定義為軟體需求分析功能和效能的依據。定義內容 問題背景，開發系統的現狀，開發的條件與理由，總體要求，問題性質，型別轉換，什麼目標，開發條件，環境要求等。可行性研究 包括的五個方面 經濟可行性 技術可行性 操作可行性 法律可行性 時間可行性。...
軟體工程第二章作業
1.在軟體開發的早期階段為什麼要進行可行性研究？應該從哪些方面研究目標系統的可行性？答 因為我們需要在軟體開發前確定其是否具有價值，乙個沒有價值的軟體開發出來也沒有意義 五個方面 技術可行性 經濟可行性 操作可行性 執行可行性 法律可行性 2.為方便儲戶，某銀行擬開發計算機儲蓄系統。儲戶填寫的存款單...