記錄一下自己的心得體會，分享給大家，有不足之處，望指教。
作者在第一章中曾提到：第二階段，第三階段，第四階段，第五階段是可以迴圈發生的，也稱為迭代。第三階段可以回到第二階段開始迴圈；第四階段可以回到第三階段或者第二階段開始迴圈；第五階段可以回到第四階段或者第三階段或者第二階段開始迴圈。每一次迴圈開始的階段越早耗費的成本越高。
接下來進一步討論每個階段的迴圈條件和決定開始迴圈時的其他應該考慮的因素。
第一階段：假想階段
本階段不會有迴圈。即使有也是本階段內部迴圈。不會有跨階段迴圈。
第二階段：需求開發階段
從本階段開始會發生迴圈。本階段的影響範圍相對來說最大，如果需求變更了，那麼接下來的設計階段，實現階段，質量檢測階段都會被影響到。但是很多時候需求變更都是從此處開始的，需求變更的體現就是本階段的輸出物-功能說明書發生了改變。如果是甲乙方合作模式（甲乙方可以是兩個公司，也可以是兩個部門，也可以是兩個組），通常需求變更都是要額外收取費用的。乙方的第一次提交物通常都是按照合同中附帶的功能說明書的要求完成的。之後每次功能說明書發生了變化都算做需求變更，會按照合同中約定的方式處理。通常都是甲方來承擔這個成本，所以甲方在決定是否開始乙個需求變更或者說是否開始從本階段開始迴圈的時候通常都會經過一系列的審批流程。這個審批流程也就是本階段的迴圈條件。當然也可能是後面階段發現需求本身有邏輯問題或者基於現有技術不可實現。
在此再多討論一點，在作者經歷，目睹，耳聞的一些甲乙方合作過程中，專案後期的許多矛盾的根源都源於此階段。在此給弱勢甲方的建議就是要有乙份盡可能完備的功能說明書附在合同中，如果甲方沒有能力提供這份說明書那就有必要去請行業內資深的顧問來幫忙完成這份說明書。給弱勢乙方的建議就是一定要在合同中明確需求變更的定義和處理方式。也許通常人們會認為如果合作非正常終止了，最終虧損的是乙方，作者認為最終虧損可能是甲方，可能是乙方，長遠看來是雙方。與其說是乙方的責任不如說是雙方的責任。
第三階段：設計階段
從本階段開始直到實現階段，質量檢查階段通常都會發生在乙方單方面，所以迴圈條件可能會相對簡單一些。當然甲方也完全可以把本階段放在甲方方面完成。本階段的迴圈條件通常是需求階段發生了變化或者實現階段發現的設計缺陷或者是質量檢查階段發現的設計缺陷。
第四階段：實現階段
本階段的迴圈條件是設計階段發生變化或者當質量檢查階段發現了實現階段的缺陷，比如說未按功能說明書的規定實現或者實現的功能未能正常工作。
第五階段：質量檢查階段
本階段的迴圈條件是實現階段發生變化。
第六階段：部署階段
本階段不會有迴圈。即使有也是本階段內部迴圈。不會有跨階段迴圈。
總結：
其實每個階段都會有內部迴圈的，只是影響範圍相對來說較小，所以就沒有詳細論述。
軟體開發生命週期 3 每個階段的輸入輸出
記錄下一點自己的心得體會，分享給大家，有不足之處，望指教。第一階段 假想階段 本階段是整個軟體開發的開始階段，輸入可以是為了提高工作效率的某個好的想法或者是公司領導為了幫助管理發出的命令。輸出就是業務需求文件，英文稱為business requirement document。這個文件的文字描述的抽...
軟體開發生命週期各階段的任務
1 問題定義 本階段需要明確回答 要解決的問題是什麼？統分析員應該提出問題的性質 目標和規模的書面報告。通過對實際使用者和使用部門的調查 研究，以及討論 交流，得出乙份雙方都滿意的文件 2 可行性分析 本階段需要回答的是 上一階段確定的問題有無可行的解決方案，是否值得解決？更進一步明確專案的規模和目...
RUP軟體開發生命週期
rup rational unified process 統一軟體開發過程，統一軟體過程是乙個物件導向且基於網路的程式開發方 1.起始階段 為專案建立乙個業務案例 1 意圖 建立業務模型用例 明確專案的範圍 2 結果 專案的實際需求 初始的業務案例。包括 成功準則，風險評估，所需資源評估，顯示主要里...