從瀑布型開發到迭代型開發的轉變(ZT)

2021-09-30 07:22:12 字數 1044 閱讀 3843

(61.05 kb)

前天 10:24

illustration 多數的軟體開發團隊仍然在開發專案中使用瀑布型 的開發過程。採用極端的瀑布型開發方法意味著你要以嚴格的順序來完成一系列的專案階段:需求分析、設計、實現/整合然後是測試。當專案**現的問題解是困難的並且解決 問題是昂貴時,你可能會推遲測試直到專案週期的末端;這些問題也能夠嚴重的威脅軟體發布的期限並且使主要的團隊成員在某些開發環節上是空閒的。

實際上,多數的開發團隊使用了改進了的 瀑布型開發方法,他們將專案分解成為兩個或者更多的部分,有時這些部分被稱為階段或者是時期。這種改良可以幫助簡化整合、使測試人員更早的進行測試工作和提供更早的專案狀態的觀測。這種方法也將**分解成了易於管理 的 片斷並最小化了以存根和驅動程式形式的、被測試需要的**整合。此外這種方法允許你原型化你認為有風險的或者有難度的部分,並且使用來自每乙個階段的反饋 修改你的設計。然而,使用瀑布型開發方法的執行與想象是相反的:很多設計團隊把在階段 1 之後的修改設計視為他們的最初設計或者需求過程的失敗。雖然乙個改進了的瀑布型開發方法並不排除反饋的使用,但是它並沒有促進、支援和鼓勵反饋的使用。最 後,想要最小化風險就不要典型的驅動乙個瀑布型的開發專案。對於軟體開發過程來說,本文探索了」迭代「開發方法超越傳統的瀑布型開發方法的進步。

迭代開發的好處

相比較而言,迭代開發方法 — 以 ibm 的 rational 統一過程 ®,或者 rup ®為例— 包括了一系列的增量的步驟或者迭代。每乙個迭代都包括一些或者很多的開發活動(需求、分析、設計、實現等等),就像你在圖 1 中看到的那樣。每乙個迭代也有一系列良好定義的目標並生成最終系統 的部分工作實現。每個後續的迭代都建立在前乙個迭代的基礎上以使系統得到發展和細化,直到最終產品被完成。

早期的迭代著重於需求、分析和設計;後期的迭代著重於實現和測試。

figure 1: iterative development with rup.

圖 1: rup 的迭代開發。每乙個迭代都包括需求、分析、設計、實現和測試活動。同時,每個迭代都建立在前乙個迭代工作的基礎上,每一次迭代都會生成更加接近最終產品的可執行版本。

(27.23 kb)

前天 10:24

從瀑布型開發到迭代型開發的轉變

本文引自 developerworks 中國 多數的軟體開發團隊仍然在開發專案中使用瀑布型的開發過程。採用極端的瀑布型開發方法意味著你要以嚴格的順序來完成一系列的專案階段 需求分析 設計 實現 整合然後是測試。當專案中出現的問題解是困難的並且解決問題是昂貴時,你可能會推遲測試直到專案週期的末端 這些...

從瀑布型開發到迭代型開發的轉變(ZT)

61.05 kb 前天10 24 illustration 多數的軟體開發團隊仍然在開發專案中使用瀑布型 的開發過程。採用極端的瀑布型開發方法意味著你要以嚴格的順序來完成一系列的專案階段 需求分析 設計 實現 整合然後是測試。當專案中出現的問題解是困難的並且解決 問題是昂貴時,你可能會推遲測試直到專...

從技術開發到技術管理的轉變旁白

之前我都認為自己是個技術人,無論做事方式和工作內容,歸根結底對電腦交流好於跟人打交道。16年的時候,公司技術部門需要提拔乙個副職,在眾多候選人當中被提拔上來,無論是論資排輩還是技術能力當時都不是最出眾的,當時領導和我說,你是綜合實力最強的。其實從人機互動到人人溝通交流的轉彎,我的內心還是牴觸的,一度...