軟體開發計劃
1.0 版
修訂歷程
日期 |
版本 |
說明 |
作者 |
---|---|---|---|
1999 年 1 月 15 日 |
1.0 |
起始版本 |
Rick Bell |
|
|
|
|
|
|
|
|
|
|
|
|
軟體開發計劃
這個「軟體開發計劃」的目標是要從實作 Wylie College 之電腦化類別登錄系統所需的階段和反覆的角度,定義開發活動。
本「軟體開發計劃」說明整體計劃,此計劃要供 Wylie College Information Systems 用於開發 Wylie College 的「課程登錄系統」。「反覆計劃」中將說明個別反覆的詳細資料。
本文件中概述的計劃係依據願景文件 [1] 中定義的產品需求。
請參閱名詞解釋 [4]。
適用的參考資料有:
「軟體開發計劃」包含下列資訊:
專案概觀 - 提供專案之目的、範圍和目標的說明。它並定義預期專案要交付的工作成果。
專案組織 - 說明專案小組的組織結構。
管理流程 - 解說預估的成本和排程、 定義專案的主要階段和里程碑,以及說明將如何監視專案。
技術流程計劃 - 提供軟體開發流程的概觀,其中包括要遵循的方法、工具和技術。
支援流程計劃 - 這包含配置管理計劃。
本「軟體開發計劃」說明整體計劃,此計劃要供 Wylie College Information Systems 用於開發 Wylie College 的「課程登錄系統」。「反覆計劃」中將說明個別反覆的詳細資料。
本文件中概述的計劃係依據願景 [1] 中定義的產品需求。
此系統是計劃要作為 1999 年第一學期之學生登錄的主要管道。由於課程登錄在 1999 年 8 月 1 日開始,因此系統必須在這個日期以前完全可供使用。
下列工作成果將會在專案期間產生,並且交付給維護組織。
將會如專案開發案例中所述,產生其他的工作成果,但是這些工作成果並沒有打算要交付給維護組織。
在每一個反覆階段開始之前,都會修訂「軟體開發計劃」。
「專案管理人員」將提供「狀態評量」(在本計劃中排定)給「IT 主管」關係人(請參閱願景 [1])。
專案小組也會與其他關係人互動,以請求相關工作成果的輸入和審查。
下表識別一些組織單位,這些單位將負責每一個規範、活動及支援流程。
角色 |
責任 |
---|---|
專案管理人員 |
如 Rational Unified Process [6] 中所述。負責管理整體的「專案管理」規範。領導延伸的「專案管理團隊」。 |
流程工程師 | 負責專案環境,並如 Rational Unified Process 中的「環境」規範中所定義,對專案中的小組提供流程相關支援。 參與延伸的「專案管理團隊」。 |
配置管理人員 / 變更控制管理人員 | 負責對於專案的「配置控制」,以及負責在專案中演練 Wylie College 變更要求流程。參與延伸的「專案管理團隊」。 |
系統工程小組負責人 |
領導小組,主要負責「商業模型」和「需求」規範。參與延伸的「專案管理小組」。 |
軟體工程小組負責人 |
主要負責「分析 & 設計」和「實作」規範。參與延伸的「專案管理小組」。 |
測試小組負責人 |
領導小組,負責管理「測試」規範。參與延伸的「專案管理小組」。 |
部署小組負責人 | 領導小組,負責一般使用者環境中的安裝活動和基礎架構。 參與延伸的「專案管理團隊」。 |
專案預估係依據「課程登錄系統」的成本模型和分析報告 [7]。
「課程登錄系統」在複雜度和架構上類似「線上書庫系統」,這是 Wylie College 在 1997 年所建置。課程登錄系統資料庫的複雜度大約高出 25%,而使用案例的數目和複雜度則暗示系統整體的複雜度大約將高出 20%。這份報告中的時間範圍和投入成本是專案的預算和排程的基礎。
正在準備「工作分解結構」,將會在本文件的下一個版本中提供。
將會使用分階段的方法(其中一個階段內發生多個反覆)處理「課程登錄系統」的開發。這個計劃中的階段和反覆並不重疊。以下的表格中顯示相對時間表的摘要:
階段 |
反覆數 |
結束 |
---|---|---|
初始階段 |
1 |
第 7 週 |
詳述階段 |
1 |
第 14 週 |
建構階段 |
1 |
第 19 週 |
轉換階段 |
4 |
第 32 週 |
表 4.2.1 相對時間表摘要
表 4.2.2 說明每一個階段以及標示階段完成的主要里程碑。
階段 |
說明 |
里程碑 |
---|---|---|
初始階段 |
「初始階段」將會開發產品需求,並建立「課程登錄系統」的企業案例。將會開發主要使用案例以及高階「軟體開發計劃」。在「初始階段」結束時,Wylie College 將會根據企業案例,決定是否要繼續進行該專案以及提供資金。 |
在此階段結尾的企業案例審查里程碑標示專案的「執行/不執行」決定。 |
詳述階段 |
「詳述階段」將會分析需求,並且會開發架構原型。在「詳述階段」完成時,針對 1.0 版所選取的所有使用案例都會已完成分析 & 設計。此外,也會分析並設計好 2.0 版的高風險使用案例。架構原型將會測試 1.0 版所需之架構的可行性和效能。 |
架構原型里程碑標示「詳述階段」的結束。這個原型表示驗證包含 R1.0 版的主要架構元件。 |
建構階段 |
在「建構階段」期間,將會分析並設計其餘的使用案例。將會開發並分送 1.0 版的測試版進行評估。將會完成支援 R1.0 和 R2.0 版的實作和測試活動。 |
起始作業功能里程碑(測試版完成)標示「建構階段」的結束。 |
轉換階段 |
將會分送並評估 1.0 版的測試版。「轉換階段」將會準備 R1.0 和 R2.0 版進行分送。它提供確定順利安裝所需的支援,其中包括使用者訓練。 |
R2.0 版里程碑標示「轉換階段」的結束。這時,願景文件 [1] 中所定義的所有功能都已安裝好,並可供使用者使用。 |
表 4.2.2 專案階段和主要里程碑
每一個階段都分成 4.3 中所述的開發反覆。
4.2.4 節說明高階專案排程,此排程顯示階段、反覆,以及主要里程碑。
每一個階段都由開發反覆所組成,在這些反覆中會開發系統的子集。一般而言,這些反覆:
下表說明一些反覆,連同相關聯的里程碑以及所處理的風險。
階段 |
反覆 |
說明 |
相關里程碑 |
所處理的風險 |
---|---|---|---|---|
初始階段 |
初步反覆 |
定義商業模型、 產品需求、軟體開發計劃,以及企業案例。 |
企業案例審查 |
事先釐清使用者需求。 開發實際的「軟體開發計劃」和範圍。 從商業的觀點判定專案的可行性。 |
詳述階段 |
E1 反覆 - 開發架構原型 |
完成所有高風險需求的設計 & 設計。開發架構原型。
|
架構原型 |
已釐清架構問題。 已降低技術風險。 用於使用者審查的早期原型。 |
建構階段 |
C1 反覆 - 開發 R1 測試版 |
實作及測試關鍵的 R1 需求以提供 R1 測試版。
評定版本是否已準備好進行外部測試。 |
起始作業功能(R1 測試版程式碼完成) |
使用者和架構視景中的所有重要特性都已在測試版中實作。
|
轉換階段 |
T1 反覆 - 開發/佈署 R1 版 |
部署 R1 測試版。 修正了測試版中的問題,並納入來自測試版的意見。
實作及測試其餘的 R1 需求。 封裝、分送及安裝 R1 版。 完整詳述了其餘的低風險 R2 使用案例。 |
R1 測試版測試完成
R1 程式碼完成
R1 產品發行 |
發行 R1 之前的使用者意見。
產品的品質應該相當高。 問題已減至最少。 品質的成本已降低。 二階段版本將問題減至最少。 二階段版本為使用者提供較簡易的轉換。 使用者群組完整審查了 R1。 |
|
T2 反覆 - 開發 R2 Internal 1 |
設計、實作及測試 R2 Internal 1 需求。 納入來自 R1 的加強功能和問題。 部署 R2 Internal 1。 |
R2 Internal 1 測試完成 |
必要的話,可以發行 R2 Internal 1 來處理 R1 問題,以協助處理客戶的滿意度。 |
|
T3 反覆 - 開發 R2 Internal 2 |
設計、實作及測試 R2 Internal 2 需求 納入來自 R2 Internal 2 的加強功能和問題。 部署 R2 Internal 2。 |
R2 Internal 2 測試完成 |
使用者群組非正式地審查了 R2 Internal 1。
必要的話,可以發行 R2 Internal 1 來處理 R1 問題,以協助處理客戶的滿意度。 |
|
T4 反覆 - 開發/佈署 R2 版 |
封裝、分送及安裝 R2 版。 |
R2 程式碼完成
R2 產品發行 |
使用者群組非正式地審查了 R2 Internal 2。 二階段版本為使用者提供較簡易的轉換。 |
這個「軟體開發計劃」處理「課程登錄系統」的前 2 個版本。已針對前 2 個版本,設定願景文件 [1] 中定義的重要特性為目標。已針對第一個版本 (R1.0) 規劃了對於學生登錄非常重要的所有特性。
預期規劃的版本內容會隨著專案進行而改變。這可能是由於若干個企業和技術因素。為了調節這些變更,將會使用 Rational RequisitePro 來管理產品需求及追蹤版本內容。特別是,會使用收益、投入成本和風險等屬性來決定產品需求的優先順序,這也就是目標版本。
預期將透過 2-4 個主要版本發行「課程登錄系統」,以供在 Wylie College 的一般使用。
第 1 版至少必須包含以下所示的基本功能:
第 2 版應包含:
尚未決定第 3 版的功能。預期這個版本會包含現有功能的提升。
已設定目標在將來的 2005 年第 4 版中置換舊版的「帳單結算系統」和「課程資料庫系統」。
此外,「測試版」將會在 R1.0 產品版本之前,並且會包含所有的重要 R1 功能。會將測試版視同真實系統來部署,唯一例外的是它會與現有舊版系統的隔離複本互動,以避免造成現有系統任何的分裂。將會要求一組選定的學生和教職員來正式評估測試版。
此外,將會有一個內部版本,用來維護正常活動訊號以協助使專案按部就班,以及在起始版本之後能夠有其他版本的可能(必要的話)。內部版本可以由學生及教職員以非正式的方式審查。以下提供這其中的每一個內部版本之目標的簡要說明:
尚未決定第 3 版的功能。預期這個版本會包含現有功能的提升。
已設定目標在將來的 2005 年第 4 版中置換舊版的「帳單結算系統」和「課程資料庫系統」。
顯示專案階段、反覆和里程碑的高階排程包含在課程登錄高階專案排程 [5] 中,如以下所示。
|
已將 8.1 節中的「組織表」內所識別的 IT 員工分配給專案。要等到在「初始階段」結束時審查企業案例,以及針對專案作出「執行/不執行」的決定時,才會配置人員給其它資源。
測試組織將取決於來自軟體工程組織的支援,這由組織表中的虛線來顯示。
Wylie College IT 部門的「開發人員」和「設計師」不足,無法滿足專案需求。Wylie College Recruiting Office 已準備聘雇具有多年 C++ 經驗的「資深開發人員」、 富經驗的「系統整合人員」,以及 2 位具有至少 1 年 C++ 經驗的實作人員/測試人員(低年級)。
在設計活動開始之前,會針對專案小組處理有關下列技能的訓練:
依據起始預估的專案預算
請參閱課程登錄系統 E1 反覆計劃 [11]。
願景 [1] 及關係人要求 [3] 文件中記錄了這個系統的需求。
專案管理人員會維護一個摘要排程,其中顯示每一個里程碑的預期日期,其為「狀態評量報告」的一部分(這在報告計劃說明)。「狀態評量報告」會提供給 IT 主管,他可以利用這份報告來設定新的優先順序或是建議更正動作。
摘要排程衍生自小組管理人員所維護的詳細排程。詳細排程中的行項目是指派給個人的詳細排程。每一位獲指派工作套件的個人會每週提供 % 完成資訊給他的小組管理人員。
支出由專案管理人員監控,並透過「狀態評量報告」來報告及評定。
進行適當的審查流程需要所有的工作成果。審查(使用 Rational Unified Process [6] 審查準則和核對清單中所述的準則)是必要的,以確定每一項工作成果的品質都可以被接受。
此外,還會記錄及追蹤問題,並依照 Wylie 軟體流程網站 [10] 上所述,收集問題測量值。
「專案管理人員」每個月會至少準備一次「狀態評量報告」。這包括:
- 更新過的成本和排程估計值
- 測量值摘要
將會收集 Wylie College 軟體流程網站 [10] 中所說明的標準專案測量值,並包含在「狀態評量報告」中。
請參閱課程登錄系統風險清單 [8]。
排程將會顯示其他專案的職員逐漸減少。在交付之後,IT 部門至少會保留一位兼職的開發人員以提供系統的維護。
將會提交一份彙總了所學經驗的「後置審查」給 IT 主管,其中包括實際成本以及排程對預測的評量。
請參閱課程登錄系統開發案例 [9]。
請參閱 Wylie College 軟體流程網站 [10]。
不適用
不適用
請參閱 Wylie 軟體流程網站 [10]。
不適用。
不適用。
不適用。