1. 傳統開發流程的問題
傳統的軟體開發流程是乙個文件驅動的流程，它將整個軟體開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務（文件）後才能夠進入下乙個階段。 如必須完成全部的系統需求規格說明書之後才能夠進入概要設計階段，編碼必需在系統設計完成之後才能夠進行。這就意味著只有當所有的系統模組全部開發完成之後，我們才進行系統整合，對於乙個由上百個模組組的複雜系統來說，這是乙個非常艱鉅而漫長的工作。
隨著我們所開發的軟體專案越來越複雜，傳統的瀑布型開發流程不斷地暴露出以下問題：
需求或設計中的錯誤往往只有到了專案後期才能夠被發現例如：系統交付客戶之後才發現原先對於需求的理解是錯誤的，系統設計中的問題要到測試階段才能被發現。
對於專案風險的控制能力較弱專案風險在專案開發較晚的時候才能夠真正降低，往往是經過系統測試之後，才能確定該設計是否能夠真正滿足系統需求。
軟體專案常常延期完成或開發費用超出預算專案開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發周期，造成專案延期或費用超支。
專案管理人員專注於文件的完成和審核來估計專案的進展情況所以專案經理對於專案狀態的估計往往是不準確的，當他回答系統已完成了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個專案80%的開發資源。
在傳統的瀑布模型中，需求和設計中的問題是無法在專案開發的前期被檢測出來的，只有當第一次系統整合時，這些設計缺陷才會在測試中暴露出來，從而導致一系列的返工：重新設計、編碼、測試，進而導致專案的延期和開發成本的上公升。
2. 採用迭代化開發控制專案風險
為了解決傳統軟體開發流程中的問題，我們建議採用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟體系統開發這個大目標。在迭代化的方法中，我們將整個專案的開發目標劃分成為一些更易於完成和達到的階段性小目標，這些小目標都有乙個定義明確的階段性評估標準。
迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據專案當前的狀態和所要達到的階段性目標制定迭代計畫，整個迭代過程包含了需求、設計、實施（編碼）、部署、測試等各種型別的開發活動，迭代完成之後需要對迭代完成的結果進行評估，並以此為依據來制定下一次迭代的目標。
與傳統的瀑布式開發模型相比較，迭代化開發具有以下特點：
允許變更需求
需求總是會變化，這是事實。給專案帶來麻煩的常常主要是需求變化和需求"蠕變"，它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。通過向使用者演示迭代所產生的部分系統功能，我們可以盡早地收集使用者對於系統的反饋，及時改正對於使用者需求的理解偏差，從而保證開發出來的系統真正地解決客戶的問題。
逐步整合元素
在傳統的專案開發中，由於要求一下子整合系統中所有的模組，整合階段往往要佔到整個專案很大比例的工作量（最高可達40%），這一階段的工作經常是不確定並且非常棘手。在迭代式方法中，整合可以說是連續不斷的，每一次迭代都會增量式整合一些新的系統功能，要整合的元素都比過去少得多，所以工作量和難度都是比較低的。
盡早降低風險
迭代化開發的主要指導原則就是以架構為中心，在早期的迭代中所要解決的主要問題就是盡快確定系統架構，通過幾次迭代來盡快地設計出能夠滿足核心需求的系統架構，這樣可以迅速降低整個專案的風險。等到系統架構穩定之後，專案的風險就比較低了，這個時候再去實現系統中尚未完成的功能，進而完成整個專案。
有助於提高團隊的士氣
開發人員通過每次迭代都可以在短期內看到自己的工作成果，從而有助於他們增強信心，更好地完成開發任務。而在非迭代式開發中，開發人員只有在專案接近尾聲時才能看到開發的結果，在此之前的相當長時間，大家還是在不確定性中摸索前近。
生成更高質量的產品
每次迭代都會產生乙個可執行的系統，通過對這個可執行系統進行測試，我們在早期的迭代中就可以及時發現缺陷並改正，效能上的瓶頸也可以盡早發現並處理。因為在每次迭代中總是不斷地糾正錯誤，我們可以得到更高質量的產品。
保證專案開發進度
每次迭代結束時都會進行評估，來判斷該次迭代有沒有達到預定的目標。專案經理可以很清楚地知道有哪些需求已經實現了，並且比較準確地估計專案的狀態，對專案的開發進度進行必要的調整，保證專案按時完成。
容許產品進行戰術改變
迭代化的開發具有更大的靈活性，在迭代過程中可以隨時根據業務情況或市場環境來對產品的開發進行調整。例如為了同現有的同類產品競爭，可以決定採用搶先競爭對手一步的方法，提前發布乙個功能簡化的產品。
迭代流程自身可在進行過程中得到改進和精煉
一次迭代結束時的評估不僅要從產品和進度的角度來考察專案的情況，而且還要分析組織和流程本身有什麼待改進之處，以便在下次迭代中更好地完成任務。
迭代化方法解決的主要是對於風險的控制問題，從下圖可以看出，傳統的開發流程中系統的風險要到專案開發的後期（主要是測試階段）才能夠被真正降低。 而迭代化開發中的風險，可以在專案開發的早期通過幾次迭代來盡快地解決掉。在早期的迭代中一旦遇到問題，如某乙個迭代沒有完成預定的目標，我們還可以及時調整開發進度以保證專案按時完成。
一般到了專案開發的後期（風險受控階段），由於大部分高風險的因素（如需求、架構、效能等）都已經解決，這時候只需要投入更多的資源去實現剩餘的需求即可。這個階段的專案開發具有很強的可控性，從而保證我們按時交付乙個高質量的軟體系統。
迭代化開發不是一種高深的軟體工程理論，它提供了一種控制專案風險的非常有效的機制。在日常的工作我們也經常地應用到這一基本思想，如對於乙個非常大型的工程專案，我們經常會把它分為幾期來分步實施，從而把複雜的問題分解為相對容易解決的小問題，並且能夠在較短週期內看到部分系統實現的效果，通過盡早暴露問題來幫助我們及早調整我們的開發資源，加強專案進度的可控程度，保證專案的按時完成。
3. 管理迭代化的軟體專案
當我們在實際工作中實踐迭代化思想時，rational統一開發流程rup(rational unified process)可以給予我們實踐的指導。rup是乙個通用的軟體流程框架，它是乙個以架構為中心、用例驅動的迭代化軟體開發流程。rup是從幾千個軟體專案的實踐經驗中總結出來的，對於實際的專案具有很強的指導意義，是軟體開發行業事實上的行業標準。
3.1 軟體開發的四個階段
在rup中，我們把軟體開發生命週期劃分為四個階段，每個階段的結束標誌就是乙個主要的里程碑（如下圖所示）。
這四個階段主要是為了達到以下階段性的目標里程碑：
先啟(inception)：確定專案開發的目標和範圍
精化(elaboration)：確定系統架構和明確需求
構建(construction)：實現剩餘的系統功能
產品化(transition)：完成軟體的產品化工作，將系統移交給客戶
每個目標里程碑都是乙個商業上的決策點，如先啟階段結束之後，我們就要決定這個專案是否可行、是否要繼續做這個專案。每乙個階段都是由里程碑來決定的，判斷乙個階段是否結束的標誌就是看專案當前的狀態是否滿足裡碑中所規定的條件。
從這種階段劃分模式中可以看出，專案的主要風險集中在前兩個階段。在精化階段中經過幾次迭代後，我們要為系統建立乙個穩定的架構，在此之後再實現更多的系統需求時，不再需要對該架構進行修改。同時，在精化階段中，我們通過迭代來不斷地收集使用者的需求反饋，便得系統的需求逐步地明確和完整。
3.2 關於開發資源的分配
基於 rup風險驅動的迭代化開發模式，我們只需要在專案的先啟階段投入少量的資源，對專案的開發前景和商業可行性進行一些探索性的研究。在精化階段再投入多一些的研發力量來實現一些與架構相關的核心需求，逐步地把系統架構搭建起來。等到這兩個階段結束之後，專案的一些主要風險和問題也得到了解決，這時候再投入整個團隊進行全面的系統開發。
等到產品化階段，主要的開發任務已經全部完成，專案不再需要維持乙個大規模的開發團隊，開發資源也可以隨之而減少。在專案開發周期中，開發資源的分配可以如下圖所示。
這樣安排可以最充分有效地利用公司的開發資源，緩解軟體公司對於人力資源不斷增長的需求，從而降低成本。另外一方面，由於前兩個階段（先啟和精化） 的風險較高，我們只是投入部分的資源，一旦發生返工或是專案目標的改變，我們也可以將資源浪費降到最低點。在傳統的軟體開發流程中，對於開發資源的分配基本上是貫穿整個專案週期而不變的，資源往往沒有得到充分有效地利用。
基於這種資源分配模式，乙個典型的專案在專案進度和所完成的工作量之間的關係可能如下表中的資料所示。
3.3 迭代策略
關於迭代計畫的安排，通常有以下四種典型的策略模式：
增量式(incremental)
這種模式的特點是專案架構的風險較小（往往是開發一些重複性的專案），所以精化階段只需要乙個迭代。但專案的開發工作量較大，構建階段需要有多次迭代來實現，每次迭代都在上一次迭代的基礎上增加實現一部分的系統功能，通過迭代的進行而逐步實現整個系統的功能。
演進式(evolutionary)
當專案架構的風險較大時（從未開發過類似專案），需要在精化階段通過多次迭代來建立系統的架構，架構是通過多次迭代的探索，逐步演化而來的。當架構建立時，往往系統的功能也已經基本實現，所以構建階段只需要一次迭代。
增量提交(incremental delivery)
這種模式的特點產品化階段的迭代較多，比較常見的例子是專案的難度並不大，但業務需求在不斷地發生變化，所以需要通過迭代來不斷地部署完成的系統；但同時又要不斷地收集使用者的反饋來完善系統需求，並通過後續的迭代來補充實現這些需求。應用這種策略時要求系統架構非常穩定，能夠適應滿足後續需求變化的要求。
單次迭代(grand design)
傳統的瀑布模型可以看作是迭代化開發的乙個特例，整個開發流程只有一次迭代。但這種模式有乙個固有的弱點，由於它對風險的控制能力較差，往往會在產品化階段產生一些額外的迭代，造成專案的延誤。
這幾種迭代策略只是一些典型模式的代表，實際應用中應根據實際情況靈活應用，最常見的迭代計畫往往是這幾種模式的組合。
3.4 制定專案開發計畫
在迭代化的開發模式中，專案開發計畫也是隨著專案的進展而不斷細化、調整並完善的。傳統的專案開發計畫是在專案早期制定的，專案經理總是試圖在專案的一開始就制定乙個非常詳細完善的開發計畫。與之相反，迭代開發模式認為在專案早期只需要制定乙個比較粗略的開發計畫，因為隨著專案的進展，專案的狀態在不斷地發生變化，專案經理需要隨時根據迭代的結果來對專案計畫進行調整，並制定下一次迭代的詳細計畫。
軟體開發流程
0 定義assoc顯示或修改副檔名關聯。attrib 顯示或更改檔案屬性。break設定或清除擴充套件式 ctrl c 檢查。bootcfg 設定 boot.ini 檔案的屬性以便控制 cacls顯示或修改檔案的訪問控制列表 acl call從另乙個批處理程式呼叫這乙個。cd顯示當前目錄的名稱或將其...
Scrum軟體開發流程
2001年2月由17位世界輕量級方法學家提出了乙份敏捷聯盟宣言，這個宣言只是簡單的四句話，但卻是敏捷方法的精髓，也是對敏捷的高度抽象，這便是敏捷之道的最高境界 人與互動勝過過程與工具 可以工作的軟體勝過面面俱到的文件 客戶協作勝過合同談判 響應變化勝過遵循計畫 scrum 方法簡介 scrum 是目...
軟體開發流程說明
第一步 需求調研分析 1 相關系統分析員向使用者初步了解需求，然後用word列出要開發的系統的大功能模組，每個大功能模組有哪些小功能模組，對於有些需求比較明確相關的介面時，在這一步裡面可以初步定義好少量的介面。2 系統分析員深入了解和分析需求，根據自己的經驗和需求用word或相關的工具再做出乙份文件...