記錄下一點自己的心得體會，分享給大家，有不足之處，望指教。
第一階段：假想階段
本階段是整個軟體開發的開始階段，輸入可以是為了提高工作效率的某個好的想法或者是公司領導為了幫助管理發出的命令。輸出就是業務需求文件，英文稱為business requirement document。這個文件的文字描述的抽象層次很高，比如業務人員說我需要乙個軟體，能夠實現無紙化辦公，能夠管理合同，管理客戶資訊，能夠在登入時選擇角色，選擇顯示語言，登入成功後自動列出登入人的當前要做的任務項，等等。這個文件主要來自業務人員，所以主要完成業務概念的描述。
第二階段：需求開發階段
本階段的主要工作是基於業務需求文件進一步分析業務人員的真實需求，輸入是假想階段的業務需求文件，輸出是功能說明文件，英文稱為funtion specification。功能說明文件與業務需求文件的主要區別是業務需求文件主要描述業務概念，而功能說明描述的是資訊科技概念，此文件的主要功能是完成從業務概念到資訊科技概念的匹配和對齊，在保證實現業務人員真實想法的同時還要結合資訊科技保證系統功能的邏輯合理性和優化性。可以說通常業務需求文件描述的乙個點到這裡都會擴充套件成為乙個面。作者認為本階段的工作至關重要，這個階段的工作輸出會直接影響到下面的設計階段和實現階段的工作。所以本階段需要很多重要角色的參與，之前提到過的有軟體產品設計師，軟體開發架構師，軟體開發負責人，軟體測試負責人和業務負責人。這些角色要共同齊心合力完成乙份高質量的功能說明文件。
第三階段：設計階段
本階段的輸入是功能說明文件，輸出是軟體架構設計文件，硬體架構設計文件，測試計畫文件。這三份文件可以同時進行，值得一提的是軟體架構設計和硬體架構設計通常是同時考慮完成的，沒有絕對的誰先完成誰後完成，並且都可以再細分。硬體設計可以分為概要設計和詳細設計，概要設計通常要描述出有幾個環境，每個環境有幾台伺服器，使用的是虛擬伺服器還是物理伺服器，每個伺服器的作用，分別在哪個級別的安全區域，防火牆分布，負載均衡裝置的分布，資料庫產品資訊，是單例項還是集群；詳細設計除了要描述出這些資訊還要描述出每台伺服器的硬體配置資訊，位址，開放的埠，http請求或者其他型別的請求的走向，是單方向還是雙方向，每台伺服器上執行的作業系統，應用伺服器的產品資訊和版本資訊，防火牆的設定，負載均衡裝置的設定，資料庫例項名稱，軟體的所有元件在每個應用伺服器上的分布資訊等。
測試計畫分為功能測試計畫，效能測試計畫，安全測試計畫。通常要描述出測試案例，測試環境的組建，測試工具，測試技術。每個測試的話題都可以作為乙個專業的方向單獨拿出來描述，限於篇幅，這裡就不多說了。
第四階段：實現階段
如果設計階段的工作做得足夠充分，那麼這個階段的工作將變得容易得多。這個階段的輸入是設計文件。輸出是源**和構建出來的軟體安裝包。源**的書寫必須遵循統一的規範，必須遵循設計階段定義的統一的架構，必須達到規定的安全標準，用合理的方式實現設計文件所設計的功能。
第五階段：質量檢查階段
這個階段的輸入是準備測試的系統和測試案例。輸出是缺陷記錄和缺陷報告。
第六階段：部署階段
這個階段的輸入是可供部署的軟體安裝包和部署文件。輸出是可供使用者使用的業務系統，備份和恢復計畫。
總結：
我們可以這樣看待乙個業務軟體，對於乙個業務軟體有業務線，軟體線，硬體線三條線，業務想法由軟體來實現，軟體需要執行在硬體上。
軟體開發生命週期 4 每個階段的迴圈條件
記錄一下自己的心得體會，分享給大家，有不足之處，望指教。作者在第一章中曾提到 第二階段，第三階段，第四階段，第五階段是可以迴圈發生的，也稱為迭代。第三階段可以回到第二階段開始迴圈 第四階段可以回到第三階段或者第二階段開始迴圈 第五階段可以回到第四階段或者第三階段或者第二階段開始迴圈。每一次迴圈開始的...
軟體開發生命週期各階段的任務
1 問題定義 本階段需要明確回答 要解決的問題是什麼？統分析員應該提出問題的性質 目標和規模的書面報告。通過對實際使用者和使用部門的調查 研究，以及討論 交流，得出乙份雙方都滿意的文件 2 可行性分析 本階段需要回答的是 上一階段確定的問題有無可行的解決方案，是否值得解決？更進一步明確專案的規模和目...
RUP軟體開發生命週期
rup rational unified process 統一軟體開發過程，統一軟體過程是乙個物件導向且基於網路的程式開發方 1.起始階段 為專案建立乙個業務案例 1 意圖 建立業務模型用例 明確專案的範圍 2 結果 專案的實際需求 初始的業務案例。包括 成功準則，風險評估，所需資源評估，顯示主要里...