1、嚴(yán)格把軟件項(xiàng)目的開發(fā)分隔成各個(gè)開發(fā)階段:需求分析,要件定義,基本設(shè)計(jì),詳細(xì)設(shè)計(jì),編碼,單體測(cè)試,結(jié)合測(cè)試,系統(tǒng)測(cè)試等。
使用里程碑的方式,嚴(yán)格定義了各開發(fā)階段的輸入和輸出。如果達(dá)不到要求的輸出,下一階段的工作就不展開。
2、重視和強(qiáng)調(diào)過程文檔,在開發(fā)的中后期才會(huì)看到軟件原型,早起只能通過文檔來了解系統(tǒng)的模樣。
在這種情況下,文檔的重要性仿佛已經(jīng)超過了代碼的重要性。
瀑布模型把每個(gè)開發(fā)階段都定義為黑盒,希望每個(gè)階段的人員只關(guān)心自己階段的工作,不需要關(guān)注其他階段的工作。
這種模式一般適用于需求比較明確、to B端項(xiàng)目。
敏捷開發(fā)模式:
敏捷開發(fā)的核心是快速迭代,擁抱變化。因?yàn)槟繕?biāo)是讓客戶滿意,所以能夠主動(dòng)接受需求變更,這就使設(shè)計(jì)出來的軟件有靈活性,可擴(kuò)展性。
與傳統(tǒng)模式相比,敏捷開發(fā)具有以下特點(diǎn):
(1)敏捷開發(fā)的過程有著更強(qiáng)的適應(yīng)性而不是預(yù)設(shè)性。
從敏捷宣言的第四條響應(yīng)變化高于預(yù)設(shè)計(jì)劃便可以看出來。因?yàn)檐浖_發(fā)過程的本身的不可預(yù)見性,很多用戶在項(xiàng)目開始時(shí)不可能對(duì)于這個(gè)項(xiàng)目有著一個(gè)完整而明確的預(yù)期。很多對(duì)軟件的預(yù)期都在后期的修改和完善過程中產(chǎn)生,因此高適應(yīng)性顯然更加符合軟件工程開發(fā)的實(shí)際,而敏捷開發(fā)實(shí)現(xiàn)其適應(yīng)性的方式主要在于:
一,縮短把項(xiàng)目提交給用戶的周期;
二,增加用戶,業(yè)務(wù)人員,開發(fā)人員這三者之間的交流;
三,通過減少重構(gòu)的成本以增加軟件的適應(yīng)性。
(2)敏捷開發(fā)的過程中,更加的注重人的因素。
在傳統(tǒng)軟件工程中,個(gè)人的因素很少被考慮到分工中,每個(gè)個(gè)體都是只是整個(gè)代碼開發(fā)機(jī)器的一個(gè)小小的螺絲釘,為了更好的為集體服務(wù),個(gè)人的意志和創(chuàng)造力很大程度上被抹去。
而在敏捷開發(fā)過程中,每個(gè)個(gè)人的潛力被充分的考慮,應(yīng)用什么技術(shù)很大程度上直接由在線開發(fā)的技術(shù)人員決定;每個(gè)人的特點(diǎn)和創(chuàng)造力都可以充分發(fā)揮,這樣開發(fā)出來的軟件更加具有生命力。開發(fā)者融入了他的心血和創(chuàng)意,他不再是進(jìn)行機(jī)械的乏味堆砌,而是創(chuàng)造屬于自己的藝術(shù)品。在這樣的條件下產(chǎn)生的代碼必然在質(zhì)量上更占優(yōu)勢(shì)。
(3)在敏捷開發(fā)的過程中,整個(gè)項(xiàng)目是測(cè)試驅(qū)動(dòng)的而不是文檔驅(qū)動(dòng)的。
不僅每個(gè)模塊有著自己的相應(yīng)的測(cè)試單元,開發(fā)人員在開發(fā)自己的模塊的過程中必須自己所開發(fā)的模塊可以通過這一單元的測(cè)試,并且集成測(cè)試貫穿了整個(gè)開發(fā)過程的始終。集成測(cè)試每天會(huì)進(jìn)行十幾次甚至幾十次,而不是像傳統(tǒng)方法一樣只有當(dāng)各個(gè)模塊的編碼都結(jié)束了之后再進(jìn)行聯(lián)合調(diào)試。因此,在軟件開發(fā)進(jìn)程中,每一點(diǎn)改動(dòng)所引起的問題都容易暴露出來,使得錯(cuò)誤更容易在剛剛產(chǎn)生的時(shí)候就被發(fā)現(xiàn),從而解決問題,也就避免了在整個(gè)系統(tǒng)完成時(shí),由于錯(cuò)誤隱藏太深而給調(diào)試造成極大困難。
總之,敏捷開發(fā)模式更適用于需求不明確、創(chuàng)新性強(qiáng)的項(xiàng)目,或者需要搶占市場(chǎng)的項(xiàng)目。