在交付優質軟體和迅速交付兩者之間要取得微妙的平衡(就是所謂的軟體矛盾!),關鍵在於瞭解流程的基本元素,並遵循流程調整準則,充分滿足專案的特殊需求。不僅如此,也應該恪遵業界公認的最佳作法,以協助軟體開發專案順利完成。
以下說明有效的軟體流程之必要原則。
1. 願景:開發願景
訂定清晰的願景尤其是開發符合 關係人真正 需要的產品之關鍵。
在 RUP 中,願
景構件會擷取極高階的需求和設計限制,讓讀者瞭解所要開發的系統是什麼。願景可以提供專案核准流程的投入要素,因此會和「商業案例」環環相扣。它傳達與專案相關的基本「為何與何謂」,是驗證所有未來決策的量規。
願景內容以及任何其他相關的需求構件,都要能對下列問題提出解答,這些可以視需求,區分為較詳細的構件:
-
有哪些重要詞彙?(名詞解釋)
-
我們要嘗試解決什麼樣的問題?(問題陳述)
-
關係人是誰?誰是系統的使用者?他們的需求為何?
-
產品有哪些功能?
-
有哪些功能需求?(使用案例)
-
有哪些非功能需求?
-
有哪些設計限制?
設定清晰的願景和一組可理解的需求,是需求
規範的要素 以及平衡 競爭的關係人優先順序的原則。這包括分析問題、瞭解關係人需求、定義系統以及管理需求的變動。
2. 規劃:管理計劃
「產品只可能和它的計劃一樣好」
構思新的專案;評估範圍和風險;監視及控制專案;規劃及評估每一個反覆和階段,這些都是專案管理規範的要素。
軟體開發計劃會彙集管理專案所需要的資訊。這份資訊會用來規劃專案時程及資源需求,並用來依據排程追蹤進度。它會處理 專案組織、 排程、預算及資源等層面。它也可以包括需求管理、配置管理、問題解析、品質保證、評估及測試以及產品驗收等方面的計劃。
在簡單的專案中,這些主題都可以用一兩句話就解釋完畢。例如,配置管理規劃可能只需要指出:在每天結束時,要壓縮專案目錄結構的內容、複製到含日期及標籤的 Zip 磁碟、標上版本號碼並存放在集中歸檔匣中。
規劃構件的格式並不如規劃活動本身以及所花的心思那麼重要。計劃的外觀,或您用什麼工具在建立計劃,都不重要。 如艾森豪將軍說過的,「計劃沒什麼,規劃才是最重要的」 ("The plan is nothing; the planning is everything.")。
3. 風險:減緩風險及追蹤相關的問題
最高的風險項目以及其他相關的問題,一定要在專案的早期就找出來和處理,並加以追蹤。風險清單旨在擷取被認為會危及專案成功完成的風險。風險清單會依遞減優先順序,指出有可能會導致重大負面結果的事件。
針對每一個風險,應該要有一個減緩該風險的計劃。 這可以作為規劃專案活動的焦點,並且是用來組織反覆作業的基礎。
4. 商業案例:查驗商業案例
商業案例會以商業的觀點提供必要的資訊,以判斷是否值得投資這個專案。
「商業案例」的主要目的是要開發一份財務計劃,來實現專案願景。「商業案例」開發出來之後,即可在專案提供的投資報酬 (ROI)
上進行精確的評估。可以為專案提出有力的佐證,並建立經濟條件的限制。它可以向財務決策者提供有關專案是否值得進行的資訊,並可用來判斷是否要開始著手進行專案。
說明不應該深入探討問題的特殊點,而是應該針對為何需要產品提出令人信服的論證。不過,說明必須很簡短,以便所有專案小組成員都能不費力地瞭解和記得。在重要的里程碑時,應該重審商業案例,看看原先預估的預期回收和成本是否仍然正確,以及專案是否應該繼續進行下去。
5. 架構:設計元件架構
在 Rational Unified Process (RUP) 中,軟體系統的架構(在某種程度上)是系統的重要元件之組織或結構,透過介面,和由後續較小的元件和介面組成的元件之間的互動。 有哪些主要元件存在? 那些元件如何並存?
是否有一個組織架構可在其上加上其餘軟體?
在談論和推論軟體架構之前,您必須先定義架構表示法,也就是一種描述重要架構層面的方法。此說明會擷取在軟體 架構文件中,此文件會以多種觀點呈現架構。
每一個架構觀點解決一部份特定議題、關係人在開發流程中關心的議題:使用者、設計師、管理人員、系統工程師、維護人員等。因此這可以作為軟體架構師和其他專案小組成員,就專案所做的 重大架構性決策時之溝通媒介。
定義候選架構、修正架構、分析行為以及設計系統的元件,是分
析與設計規範的要素,並且是提高
抽象層次的原則。
6. 原型:漸進式建置及測試產品
RUP 是一種建置、測試及評估產品可執行版本的反覆式方法,以盡可能提早彰顯出問題,並解決風險和問題。
漸進地建置和測試系統元件,是實作和測試規範的要素,並且是反覆示範值的原則。
7. 評估:定期評估結果
針對直接從進行中的活動衍生出的客觀資料以及進化中的產品配置, 持續地進行開放式溝通對任何專案都很重要,定期做狀態評估可提供機制來處理、溝通及解決管理問題、技術問題以及專案風險。除了要找出問題,每個問題也要指派一個到期日,以及負責解決該問題的人員。這項作業應該定期追蹤和更新。
這些專案的 Snapshot 提供需要注意管理的活動訊號。雖然期間可能會不同,但還是要有一個推動力量來擷取專案歷程,並尋求解除妨礙進度的障礙物或瓶頸。
反覆評估會擷取反覆作業的結果、滿足評估準則的程度、所學到的經驗和要實施的流程變更。
「反覆評估」是反覆式方法的主要構件。視專案的範圍和風險,以及反覆作業的本質,這可以是很簡單的示範與結果記錄,也可以是完整的正式測試審查記錄。
這裡的關鍵是要專注於流程問題和產品問題:「愈早落後,就要花愈多時間趕上」。
8. 變更要求:管理及控制變更
一旦向使用者呈現第一個原型(並且經常在這之前就開始了),變更就會接踵而來。(這是生命中的常態之一!)為了控制那些變更,以及有效管理專案的範圍和關係人的期望,所有對任何開發構件的變更,都必須透過變更要求提出,並以一致的流程加以管理。
變更要求是用來記錄及追蹤問題、加強要求以及要變更產品的任何其他要求。「變更要求」的好處是可以提供決策記錄,並且由於其評估流程的關係,也可以確保所有專案小組成員都確實瞭解可能的變更所會帶來的衝擊。「變更要求」對於管理專案範圍,以及評估所提出變更的衝擊很重要。
管理及控制專案範圍(因為在專案生命週期中會不斷發生變更),同時保存考慮所有關係人的需求 以及盡可能符合那些需求的宗旨,是配置 及變更管理規範以及輔助
資料:控制變更的要素。
9. 使用者支援:部署可用的產品
流程的目的是要產生可以使用的產品。在修訂流程的所有層面時都應該考慮到這個目旨。
產品通常不是只有軟體本身而已。至少都要包括一本「使用手冊」,這可以透過線上說明提供。您也可能要包括「安裝手冊」和「版本注意事項」。視產品的複雜程度,也可能要包括訓練教材以及隨任何產品套裝的資料清單。這些相關聯的活動就構成 部署規範。
10. 流程:採用適合您的專案之流程
選取的流程適合您要開發的產品類型是極為重要的事情。即使在選定流程之後,也不可以盲目遵從,必須要靠一些普通常識和經驗來配置流程和工具,以適合組織和專案的需要。
改編專案流程是環境 規範的一個關鍵部分。
如需有關針對您的專案和組織改編 RUP 的詳細資訊,請參閱:概念:調整 RUP。
結論
上述要素可以讓您快速評估流程並找出最需要改進之處。如果要忽略任何這些要素,一定要探索其影響。例如:
-
沒有願景?您可能會迷失方向,並且很容易會誤入歧途。
-
沒有流程?若沒有共同的流程,團隊可能互不瞭解或誤解每個人的工作,以及什麼時候做什麼工作。
-
沒有計劃?您根本就沒有辦法追蹤進度。
-
沒有風險清單?您現在可能會專注於錯誤的議題,並且可能會連續挖掘沒有問題的東西達 5 個月之久。
-
沒有商業案例?專案可能會因而喪失時間和金錢。專案可能會因而被取消或破產。
-
沒有架構?您可能會在出現通訊、同步化和資料存取問題時,沒有應變之道;同時也可能會有調整和效能方面的問題。
-
沒有產品(原型)?要愈快將產品擺在客戶面前愈好。只是彙集一些文書並無法說服 您自己或客戶產品一定會成功,並且這也會提高預算、超過排程及/或徹底失敗的風險。
-
沒有評估?不要把頭埋在沙堆裡。一定要面對事實。您實際距離截止時間多遠? 離品質和預算目標多遠?是否適當追蹤所有問題?
-
沒有變更要求?您要如何追蹤關係人提出的要求?您要如何決定優先順序? 以及防止低優先順序者消失無蹤?
-
沒有使用者支援?若使用者有問題或不知道如何使用產品時怎麼辦? 容易取得協助嗎?
這些要素也提供每一種 RUP 規範分組:RUP
規範的簡介,並支援其關鍵 原則。
|