微軟解決方案架構(模組五)(3) (轉)

amyz發表於2007-08-17
微軟解決方案架構(模組五)(3) (轉)[@more@]

範圍:namespace prefix = o ns = "urn:schemas--com::office" />

I.  功能範圍

範圍:能夠在給定版本的下完成的解決方案的設想的各個部分

l 解決方案的範圍:在一個版本的解決方案中提供的產品和服務的總和

l 專案的功能範圍:在解決方案的範圍內團隊工作提交的物品

為完成一個整體的解決方案可能要做多個專案

II.  透過版本化約束功能範圍

任務:

l 透過將解決方案劃分成一系列的釋出版本來確定它的功能範圍

l 決定目前的解決方案和接下來的解決方案的內容

l 建立多版本的計劃

l 為版本1設定功能範圍

III.  功能範圍管理

功能範圍管理的重點

l 避免功能範圍的蔓延

l 清楚的定義功能範圍的邊界

功能範圍管理的技術

l 平衡三角形

l 平衡矩陣

定義:

l 功能範圍的蔓延:無管理的功能範圍的擴張

IV.  使用平衡三角形來管理功能範圍

三角形代表資源,日程和特性之間的變數關係

V.  使用專案平衡矩陣來管理功能範圍

解決方案架構是團隊和之間的一個

資源是固定的,日程是可選擇的,特性是可以調整的

VI.  起草功能範圍

功能範圍的文件包括:

l 問題描述

l 設想

l 初始需求

l 使用者檔案

l 功能範圍

l 解決方案的概念

l 專案的功能範圍

記住:設想是一個迭代的過程

臨時里程碑:功能範圍的基線被定義

VII.評估風險

任務:

l 在專案啟動階段就開始

l 核心團隊集結在一起透過頭腦風暴來發現專案風險

l 繼續風險評估過程以便:

n  分析和排列風險

n  建立風險評估文件

重要:

l 表現專案風險的初始評估

l 為正在進行的風險管理提供基礎

l 被用做安排日程和做決策的基礎

I.  建立可追溯性

確保最後結果滿足初始業務目標和需求

II.  可追溯性的益處

把特性與業務需求聯絡在一起

與變化控制緊密結合

推動與正式質量管理標準的一致

III.  建立變化控制

重要:

l 應用於所有的變化

l 推動變化的簡單結合

l 建立在微軟解決方案架構核心建立活動文件概念的基礎上

l 早做文件基線,但儘可能晚的定型以保持團隊的靈活性

定義:

l 變化控制:一個要求,稽核,透過,建文件和釋出變化的過程

IV.  建立管理

重要:

l 推動早期配置的再生或回滾

l 要求團隊將配置文件化到或其他工具中去

定義:

l 配置管理是用來跟蹤和控制不同解決方案產物的狀態的正式過程

V.  設想階段的里程碑和傳遞物品複習

組建核心團隊/為功能範圍定基線

提交的物品

l 功能範圍文件

l 專案結構文件

l 初始風險評估文件

VI.  設想階段的成功標準

投資人和專案團隊就以下幾個方面達成了一致:

l 專案的動機

l 解決方案的設想

l 解決方案的功能範圍

l 解決方案的概念

l 專案團隊和結構

約束和目標已經形成文件

做了初始的風險評估

建立了變化控制和配置管理的過程

發起人或關鍵投資人正式批准了設想

設想階段的目標是為了建立一個高階別的專案目標和解決方案的初始概念的檢視。

團隊準備情況的關鍵步驟是度量熟練程度,分析差距,建立學習計劃並且學習計劃。

一個共有的設想使團隊適應一個共同的方向,強化方案的目標,並且保持關注方案的質量。

設想階段的臨時里程碑是核心團隊的組建,功能範圍的起草,提交的物品是功能範圍文件,專案結構文件,以及初始評估文件。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752019/viewspace-963627/,如需轉載,請註明出處,否則將追究法律責任。

相關文章