作業: 建立開發案例
這項作業說明如何建立「開發案例」來描述組織或專案的軟體開發流程。
規範: 環境
關係
角色主要執行者: 其他執行者:
輸入強制:
選用:
輸出
流程用法
步驟
決定如何執行每一個規範

在修改 RUP 架構以適用於特定的專案時,有一部分是決定要導入哪些規範。 如作業:為專案量身訂作開發流程所述,請避免在單一專案中運用整個 RUP。 如果專案非常不熟悉 RUP 所描述的作法,則應該全力將未知因素減到最少,以利於團隊順利移轉到新的流程平台。

在決定需要導入哪些規範之後,請決定每一個規範: 

  • 如何執行工作流程。 
  • 應該使用工作流程的哪些部分。 
  • 在專案的生命週期內何時導入工作流程及各部分。 

為了協助您做決策,每一個規範已開發準則,稱為「<規範 X> 的重要決策」。 在這些準則中,有一段是「決定如何執行工作流程」。 如需此配置包含的規範,請參閱隨附的準則。 

在考量導入特定規範或其中一部分時,請考量:

  • 適用性。適用於專案嗎?真的值得導入嗎?
  • 解決問題和主要原因。解決任何已發現的問題和主要原因嗎?
  • 工具支援。需要什麼工具支援?
  • 時機。在專案的生命週期內何時應該導入?如需相關資訊,請參閱概念:在專案中實作流程
  • 實作的成本。在專案內實作的成本是什麼?包括:
    • 訓練專案成員的成本。 
    • 安裝支援工具的成本。
    • 開發準則和範本的成本。
根據規範來修改成果

選取要由專案產生的正確工作成果集。如果無法清楚表達為何要產生工作成果,例如沒有任何外部關係人提出要求,請考慮排除。

最好利用開發案例來記載偏離基本流程的任何偏差,因此應該解釋並記載排除的任何工作成果。

請執行下列步驟:

  1. 決定如何使用工作成果(塑造元素或文件)。關於個別工作成果重要性及是否會使用這些工作成果的分類記載法, 請參閱準則:分類工作成果
  2. 決定每一個工作成果的審查層次並記錄在「審查細節」中。 如需詳細資訊,請參閱準則:審查層次。決定如何審查每一個工作成果;亦即,採用什麼審查程序。 
  3. 決定如何捕捉規範的最終結果。您需要將結果做成書面文件嗎?如果是,您必須決定採用一或多種報告,從工具中擷取結果,並將結果做成書面文件。 
  4. 決定以哪些工具來開發和維護工作成果。
  5. 決定使用哪些內容及如何使用。請參閱每一個工作成果的「內容表」及每一個工作成果的「調整」區段。
  6. 適當的話,決定使用哪些模板。對於每一個工作成果,請參閱「調整」區段。
  7. 決定文件工作成果的大綱。對於個別的工作成果,請參閱主要說明的「大綱提要」部分。

除了這些步驟以外,您也應該:

  • 決定要使用哪些報告。決定是否有任何工作成果需要從模型中擷取資訊,然後將資訊做成文件以便於審查。 這些工作報告通常不正式,因為只是暫時文件,在審查完畢之後就會丟棄。 您可能需要修改大綱。

每一個規範還有更多事項要決定。如需每一個規範的詳細資訊,請參閱「<規範名稱> 的重要決策」準則。

根據規範來修改作業

研究已修改的工作成果集,以及使用、建立和更新這些工作成果的作業。 決定是否要修改或簡化這些作業。 請注意,對於每一項作業,請指出輸入及輸出工作成果。請記得刪除任何不必要的步驟或作業。 注意事項如下:

  • 導入新的步驟甚至是新的作業,以反映工作您必須新增的成果、報告及文件。
  • 檢查使用的工作如何輔助、自動化或甚至抑制某些步驟。
  • 在作業中導入從組織經驗中學到的任何特定準則和規則。可能做為指引點、核對清單、審查項目,或維持為可參考的個別文件。
  • 確認作業之後,審查每一個規範的相關工作流程以瞭解作業如何相互影響,再視情況來移除或新增作業。
  • 可以省略或建立全體規範。
  • 您可能必須引進一些額外的角色,以負責需要特定技能的特殊作業。

在「開發案例」中描述變更。

選擇生命週期模型

選擇專案應該採用的生命週期模型。修正 RUP 模型,必要的話,調整里程碑和里程碑評估準則。 您甚至可以決定省略一或多個階段,或是新增或移除里程碑。 如需相關資訊和觀念,請參閱概念:階段概念:反覆。 在「開發案例」的「開發案例的概觀」區段中記載專案的生命週期模型。

除了選取整體生命週期模型,也必須決定如何執行規範工作流程(執行什麼活動和以什麼順序執行), 並且決定在專案生命週期內何時導入規範流程的每一個部分。 有關如何修改每一個 RUP 規範的工作流程的相關資訊,請參閱每一個 RUP 規範提供的參照工作流程的使用注意事項。 在「開發案例」中記載規範工作流程決策。

描述樣本反覆

每一個階段至少描述一個樣本反覆(很可能描述多個)。 這些反覆說明指出專案在不同的專案反覆和階段中如何運作。 如需詳細的範例,請參閱 RUP 生命週期頁面中不同階段的說明。

在開發案例中描述樣本反覆,目的是向專案小組表達專案將執行哪些作業及採取什麼順序。 因此,可以做為更詳細的反覆計劃。樣本反覆的說明應該簡短。 請勿加入屬於作業、工作成果及準則的詳細資料。 您可以選擇以作業或活動來描述樣本反覆。以活動為主的說明較易於用在管理層次上的規劃和控制,但在情境層次上,以作業為主的說明較適合。

在大多數情況下,每一個階段至少應該描述一個樣本反覆。 視需求來描述樣本反覆;沒有道理在專案一開始就描述「轉換階段」如何進行。 一開始,請定義專案在「初始階段」如何進行。

識別關係人

關係人角色代表專案中所有可能的關係人。 您必須指出並描述不同類型的關係人、需求及責任。 例如,不同的關係人包括客戶代表、使用者代表、投資人、生產經理及買主。

在「角色」區段描述開發案例中不同的關係人及其需求。

將角色對映到工作職位

有些開發機構會定義工作職位。如果這些工作職位很常見且在組織內廣為採用,則可能值得將 RUP 的角色對映到組織的工作職位。 將工作職位對映到角色,可讓組織內的人更容易瞭解如何運用 RUP。 對映也有利於讓人們瞭解角色不等同於工作職位,這是一種常見的錯誤想法。 請將此對映記載於開發案例的「角色」區段。

將開發案例做成文件

描述開發案例。請參閱「表示法選項」區段及任何相關的指引(例如,範本及/或範例)。

維護開發案例

有許多決策應該在專案開始之前制訂。在軟體開發專案中,您應該在每一次反覆之後評估流程,並重新考量已做的決策。 如果基礎配置發行新版本,您必須更新開發案例。

主要考量


 

替代方案

詳細資訊