瀑布式開發(fā)目標(biāo)設(shè)計(jì)

需求階段通常定義系統(tǒng)的需求，明白系統(tǒng)的目標(biāo)。

設(shè)計(jì)階段通常確定系統(tǒng)使用什么數(shù)據(jù)庫(kù)，系統(tǒng)模塊的劃分，各個(gè)模塊的功能。

編碼階段用編程語(yǔ)言對(duì)設(shè)計(jì)階段的實(shí)現(xiàn)。

測(cè)試階段分黑盒測(cè)試，白盒測(cè)試。測(cè)試系統(tǒng)的功能是否實(shí)現(xiàn)，是否準(zhǔn)確。

維護(hù)階段是根據(jù)用戶新的需要重新修改系統(tǒng)，使系統(tǒng)更加穩(wěn)定，更符合用戶的要求。

需求階段的工作是否到位是整個(gè)系統(tǒng)開發(fā)的關(guān)鍵，在需求階段有很多方式可以幫助自己完成工作，例如與客戶暢所欲言，跟隨客戶參與業(yè)務(wù)過程等等。不管任何一種方法，任何一種方式，在需求階段首先確定系統(tǒng)邊界，確定組織邊界，然后摸清企業(yè)為消費(fèi)者創(chuàng)造的價(jià)值，看清企業(yè)的價(jià)值鏈，摸清價(jià)值鏈上的實(shí)體。最后要平衡價(jià)值鏈上各個(gè)實(shí)體之間的利益，爭(zhēng)取系統(tǒng)做到大家都滿意這個(gè)理想的狀態(tài)。

瀑布模型式是最典型的預(yù)見性的方法，嚴(yán)格遵循預(yù)先計(jì)劃的需求、分析、設(shè)計(jì)、編碼、測(cè)試的步驟順序進(jìn)行。步驟成果作為衡量進(jìn)度的方法，例如需求規(guī)格，設(shè)計(jì)文檔，測(cè)試計(jì)劃和代碼審閱等等。

瀑布式的主要的問題是它的嚴(yán)格分級(jí)導(dǎo)致的自由度降低，項(xiàng)目早期即作出承諾導(dǎo)致對(duì)后期需求的變化難以調(diào)整，代價(jià)高昂。瀑布式方法在需求不明并且在項(xiàng)目進(jìn)行過程中可能變化的情況下基本是不可行的。

有論文統(tǒng)計(jì)他是造成70%軟件開發(fā)失敗的原因。

大體分為這幾個(gè)階段：需求分析、設(shè)計(jì)、編碼、測(cè)試、維護(hù)。

敏捷式vs.瀑布式：都需要經(jīng)常，細(xì)致的交互

團(tuán)隊(duì)和利益相關(guān)者之間需要經(jīng)常并且細(xì)致的交互。建立互信，人們之間維持開放并且忠誠(chéng)的關(guān)系非常重要。這樣的氛圍使得溝通更為有效，幫助大家構(gòu)建對(duì)于正確需求的一致理解。

對(duì)于我來說，價(jià)值比費(fèi)用更重要。如果你知道哪一個(gè)需求最為重要，那么開發(fā)它所需的成本反而不那么要緊。對(duì)價(jià)值的理解也會(huì)激勵(lì)大家，幫助大家關(guān)注于持續(xù)選擇并開發(fā)正確的需求。

使用敏捷項(xiàng)目框架，比如scrum、XP、SAFe或者LeSS并不會(huì)自動(dòng)保證項(xiàng)目的成功。需要以適合項(xiàng)目需求的方式使用這些框架。選擇合適的方式，在工作方法上達(dá)成一致。不用太擔(dān)心項(xiàng)目一開始時(shí)達(dá)不到完美，反思之類的活動(dòng)會(huì)幫助大家持續(xù)學(xué)習(xí)并在過程中不斷改進(jìn)。 2100433B

瀑布開發(fā)也有一些缺點(diǎn)，但是，在你初履新職，剛剛接手管理一個(gè)新的團(tuán)隊(duì)，同時(shí)獲得了一種支持瀑布開發(fā)模式的解決方案的情況下，這種開發(fā)模式可以令你很快進(jìn)入角色把工作開展起來，從而為將來采用更高級(jí)的開發(fā)方式做好了準(zhǔn)備。

瀑布開發(fā)過程在政府項(xiàng)目中特別受到歡迎，在這樣的軟件開發(fā)項(xiàng)目中，其規(guī)劃階段超出了大多數(shù)企業(yè)部署階段的時(shí)間和力度。采用這種方式的其他用戶包括那些理解比較全面和深入的軟件項(xiàng)目，相關(guān)的解決方案對(duì)團(tuán)隊(duì)而言非常熟悉，或者只需要小小的改動(dòng)。

瀑布開發(fā)方式的缺點(diǎn)也是明顯的。如果期間的每一階段沒有得到堅(jiān)決貫徹和實(shí)現(xiàn)，那么隱藏的問題最終會(huì)影響項(xiàng)目的成功。雖然瀑布管理方式對(duì)項(xiàng)目經(jīng)理而言非常方便，但是對(duì)開發(fā)人員而言就可能顯得太嚴(yán)酷了。因?yàn)闇y(cè)試過程在開發(fā)階段之后實(shí)施，子系統(tǒng)測(cè)試所暴露的問題可能需要立即修改代碼，這樣就顯著增加了計(jì)劃架構(gòu)的成本。

調(diào)試過程可能非常復(fù)雜，原因在于，開發(fā)人員在同一階段通常還可以從事其他項(xiàng)目的開發(fā)工作，而所需要的軟件修改可能會(huì)降低開發(fā)人員的生產(chǎn)率和工作質(zhì)量。有時(shí)工作區(qū)還必須集中到一個(gè)地方來，從而威脅到解決方案的完整性。

另一可能的危險(xiǎn)是你只有到解決方案啟動(dòng)的時(shí)候才能知道當(dāng)初所預(yù)計(jì)的是否成功，所以余下用來改正問題的時(shí)間和空間都非常有限。而設(shè)計(jì)工作上的疏漏和缺陷可能會(huì)嚴(yán)重地影響解決方案的啟動(dòng)日期。

這種模式的另一問題在于，除了到階段終止之時(shí)，其他時(shí)候幾乎沒有獲取反饋的時(shí)間，還有，一旦開發(fā)工作開始啟動(dòng)那么修改的空間也就沒有了。最后，假如系統(tǒng)測(cè)試表面功能或者性能沒有達(dá)到要求也許到這個(gè)時(shí)候已經(jīng)沒有糾正問題的可能了。

在部署瀑布開發(fā)模式之前你必須仔細(xì)評(píng)估自己所處的環(huán)境和條件。如果客戶希望在開發(fā)工作開始之后加入進(jìn)來或者你要處理很多未知的問題，那么你或許最好采用一種更具重復(fù)性的開發(fā)過程。2100433B

瀑布開發(fā)也被稱作系統(tǒng)開發(fā)生命期模式，簡(jiǎn)稱SDLC（Systems Development Lifecycle Model），這是一種軟件開發(fā)途徑，它把項(xiàng)目分解為有限的階段。每一個(gè)階段都有序執(zhí)行，并且依賴于先前已完成的階段。在采用瀑布開發(fā)方法的情況下，開發(fā)工作的各個(gè)部分必須分別評(píng)估，而且通常由不同的開發(fā)隊(duì)伍來實(shí)施。具體開發(fā)階段的劃分存在一定的爭(zhēng)議，但各個(gè)階段基本上取決于任務(wù)相對(duì)繁重的預(yù)先規(guī)劃。以下就是瀑布開發(fā)過程的常見階段劃分：

問題評(píng)估—也就是概念形成階段。明確現(xiàn)有解決方案所存在的問題同時(shí)收集相關(guān)信息。

計(jì)劃解決方案—提出解決方案的詳細(xì)說明，包括軟件的優(yōu)點(diǎn)和缺點(diǎn)以及試圖解決的問題。確定開發(fā)時(shí)序，工作結(jié)構(gòu)分解以及其他支持文檔。最重要的是明確和分析軟件需求。

設(shè)計(jì)系統(tǒng)架構(gòu)—提案獲得接受之后即可創(chuàng)建解決方案模式，包括工作流和數(shù)據(jù)流圖、模塊和功能層次已經(jīng)其他由解決方案所需要的說明。在這一階段通?？偸前殡S一個(gè)有力度的檢查過程。

開發(fā)代碼—用以上階段創(chuàng)建的藍(lán)圖編寫、調(diào)試和單元測(cè)試軟件代碼。接著，集成系統(tǒng)的代碼和測(cè)試部分。最后測(cè)試整個(gè)系統(tǒng)。該階段要到測(cè)試完全通過才能結(jié)束。

部署和使用系統(tǒng)—部署最終功能，同時(shí)向用戶提供所需的培訓(xùn)和文檔。

維護(hù)解決方案—在必要的時(shí)候指出和升級(jí)軟件并且修補(bǔ)軟件錯(cuò)誤。

有時(shí)測(cè)試會(huì)成為單獨(dú)的一個(gè)階段，其中包括軟件調(diào)試而不是在開發(fā)階段進(jìn)行代碼調(diào)試。此外，獲取軟件需求也可能成為獨(dú)立的階段。無論采取怎么樣的開發(fā)路線，以上過程都是一次實(shí)施的，同時(shí)還要整合到整個(gè)解決方案中來。