我們公司過去幫客戶開發軟體時，都是採取傳統的瀑布式(Waterfall)生命週期模式，以結構化方法進行開發，但因為國內客戶的成熟度多半偏低，需求也多不明確，都是到了最後階段才會確認需求，以致於到後來不斷修改程式，文件也常無法同時配合修正，工期也難以掌控 ......

因此，我們公司最近除了引進軟體工具外，對大多數需求較不明確的軟體專案，都改採漸增式(Incremental)生命週期模式，以 UP (Unified Process)方法和反覆式(Iterative)的軟體製程來進行.

我想請教的問題是：採用 UP 和漸增式生命週期模式，在軟體開發的人力和工作規劃上，跟傳統的瀑布式生命週期模式主要的不同為何 ? 有哪些特別需要注意的地方呢 ?

首先要說明的是UP是一種漸增式生命週期模式，但是，漸增式的生命週期模式不是只有UP一種。為了讓討論不失焦，在此只比較UP與傳統的瀑布式生命週期模式，在軟體開發的人力和工作規劃上的差別。

瀑布式生命週期模式的最主要特徵就是它將軟體開發的工作分為：分析、設計、程式撰寫、測試與安裝等“階段”。 理論上，在同一時間中只進行一件工作，所以只需要一種角色的人力，也就是在分析階段只需要“軟體分析師”這種角色的人員執行軟體需求分析的工作，在設計階段就只需要“軟體設計師”這種角色的人員，在“程式撰寫”階段時就只需要“程式設計師”… 其餘各階段請自行類推。因此，採用這種生命週期模式的軟體開發專案，在人力規劃上比較簡單，甚至可以由同一個人在不同的階段扮演不同的角色。譬如：張高手在分析階段時是“軟體分析師”，到了設計階段就成為“軟體設計師”，到了“程式撰寫”階段又搖身一變成了“程式設計師”。

採用UP作為軟體開發的生命週期模式時，就不能這樣了。因為UP與瀑布式的最大不同就是：它的工作安排方式是“平行的”。也就是說它的四個階段，分別為起始(Inception)、詳述(Elaboration)、建構(Construction)與移轉(Transition)都要進行多種不同的工作(包括：需求、分析設計、程式撰寫、測試…等)以完成該階段的目標，所以每個階段都要有扮演不同角色的人，來執行這些不同的工作，而每個角色在不同的階段也都有不同的工作要執行。因此採用UP的專案團隊，在專案之初就要把專案中會用到哪些角色(標準UP有10種角色與24種活動)的人員、執行哪些工作(活動)、完成哪些工作產出都要定義出來。之後再將它們安排到各階段與反覆中，並定義各反覆的允入與允出準則(也就是里程碑)…。再說下去說不完了，就此打住。

簡單的做一個結論就是：採用UP的軟體開發專案，至少要做到：
1. 人員要專業分工，在專案中要扮演固定角色；
2. 要有比較好(與瀑布式比較)的專案規劃與監控能力；
3. 事先具有已為組織裁適好的工作流程。

軟體品質協會資深管理師 周茂松 敬上

的確,為了提高客戶的滿意度,傳統瀑布式的開發方式的確也不大可行,不過針對UP或者平行式的開發生命週期,我都有一個疑問,不斷反覆且接近平行的執行這些開發工作,但最終仍需要做完整的整合測試,是否在整合測試的階段,是無法平行作業的呢?? 否則光是分階段的開發與分段測試但沒有整合系統測試,仍然是會有風險吧?!

UP的每一個反覆(iteration)都會有一個發行(release)，它可能是內部的發行或外部的發行。如果，那一次的發行中包含最終產品(也就是程式碼)的話，那這個產品就是一個建構(buid)。每一個建構不論它的功能是否完整，都必須是整合好的。

UP從發展出每一個建構的角度看，它是一個以瀑布式為生命週期的迷妳專案。所以，它可以用V-Model來執行測試工作。由反覆(代表時間)的角度看，需求、分析、設計、編碼、測試…等工作是平行進展的。從最終的產品(成熟的產品)看，它是漸增的，換個說法：軟體是“長”出來的，不是“併湊”出來的。再說的清楚一點，就是在每一個反覆結束的那一點上，產品都是完整的(被整合好的)。就像在母親腹中的胎兒一般，在每一個時刻它都是完整的，雖然不夠成熟，它要成長到足夠成熟時才會脫離母體。

在UP中，建構是其中很重要的一個基石，如果，不瞭解它會產生很多的誤解，也就沒有能力把它落實到專案中。

希望這短短的解說能對您有些許的幫助。