tceic.com
學霸學習網 這下你爽了
當前位置:首頁 >> 計算機軟件及應用 >>

第13章 軟件項目管理_圖文

第13章 軟件項目管理
? ? ? ? 軟件項目管理概述 項目估算 進度管理 配置管理

13.1 軟件項目管理概述
管理目標
? 通常認為,項目成功的標志,也是項目管理人員 爭取的目標,應該包括以下幾個方面。
(1)達到項目預期的軟件產品功能和性能要求。也就是軟件 產品達到了用戶已認可的需求規格說明的要求。

(2)時限要求。項目應在合同規定的期限內完成。
(3)項目開銷限制在預算之內。

管理涉及的范圍
軟件項目管理涉及的幾個主要方面是人員、產品、過程和 項目,即所謂4P(People、Product、Process、 Project)。 (1)人員管理

美國卡內基· 梅隆大學軟件工程研究所的Bill Curtis在
1994年發表了“人員管理能力成熟度模型”(people capability maturity model,P-CMM)。該模型力圖通過 吸引、培養、激勵、部署和騁用高水平的人才來提升軟件組 織的軟件開發能力。

管理涉及的范圍
人員管理涉及:
① 共利益者。 包括: ● 項目的高級管理者——負責項目商務問題的決策; ● 項目經理——負責項目的計劃與實施以及開發人員的組 織與管理; ● 開發人員——項目開發的實施者; ● 客戶——提出需求并代表用戶與開發人員交往的人員; ● 最終用戶——直接使用項目成果(產品)的人員。 ② 團隊負責人。在小項目的情況下,項目經理就是團隊負 責人。而大型項目也許會有若干個設計、編程團隊或是若干 個測試團隊。團隊負責人除去負有團隊日常工作的安排、組 織和管理之外,還應特別注意發揮團隊成員的潛能。

管理涉及的范圍
③ 團隊集體。團隊內部有分工是必要的,但必須很好地配 合,做到步調一致,為此必須強調以下3點。
● 個人的責任心,這是團隊完成工作的基本條件。 ● 互相信任、尊重以及互相支持。 ● 充分的交流與溝通。

管理涉及的范圍
(2)產品管理 項目經理必須在項目開始時就明確項目的以下三個目標:
● 產品的工作環境。

● 產品的功能和性能。 ● 產品工作處理的是什么數據,經它處理后得到什么數據。 只有明確了項目的這些基本要求才能著手項目管理的各項
工作,如項目估算、風險分析、項目計劃的制定等。

管理涉及的范圍
(3)過程管理
過程在軟件工程項目中是重要的因素,它決定著項目中 開展哪些活動以及對活動的要求和開展活動的順序。 (4)項目管理 項目管理的任務是如何利用已有的資源,組織實施既定 的項目,提交給用戶適用的產品。

13.2 項目估算
通常在項目的目標確定和軟件基本功能確定之后,就應 該著手項目計劃的制定工作。項目估算是制訂計劃的基 礎和依據。

? 項目策劃與項目估算
項目策劃是項目開展初期階段的重要工作,其主要目

標是得到項目計劃,或者說計劃(plan)是策劃
(planning)的結果。

13.2 項目估算
? 項目策劃中需要開展的活動
(1) 確認并分析項目的特征。 (2) 選擇項目將遵循的生存期模型,確定各階段的任務。

(3) 確定應得到的階段性工作產品以及最終的產品。
(4) 開展項目估算,包括估算產品規模、工作量、成本以及 所需的關鍵計算機資源。

(5) 制訂項目進度計劃。
(6) 對項目風險進行分析。 (7) 制訂項目計劃。

13.2 項目估算
在項目估算中,要解決的問題是項目實施的幾個主要屬 性,即將要開發產品的規模(size)、項目所需的工作量
(effort)以及項目的成本(cost)。

13.2 項目估算
(1)規模。項目的規模指的是得到最終軟件產品的大小。 一般以編程階段完成以后得到程序的代碼行表示,如以1千 行代碼為單位,記為KLOC。 當然,在項目的開始只是對代碼行的估計值。另一表示方法 是功能點,記為FP,它是根據軟件需求中的功能估算的。

13.2 項目估算
(2)工作量。項目的工作量按項目將要投入的人工來考
慮,以一個人工作一個月為單位,記為“人月”。 (3)成本。軟件項目的成本通常只考慮投入的人工成本, 如某項目投入的總人工費用為12萬元。

13.2 項目估算
?

成本計算

一個軟件組織在完成多個項目以后積累了一些數據,進行 成本分析后便可得到自己的生產率數值和人工價格。 生產率是平均每個人月完成的源程序行數,可記為 KLOC/人月或FP/人月。
? ?

人工價則為每人月的價值。

有了這兩個數值,如果在估出項目規模以后就可以很容易 得到項目的工作量和成本,即

工作量=規模/生產率
成本=工作量×人工價

項目估算的功能點方法
? 功能點方法(function point)簡稱FP方法,該
方法克服了項目開始時無法得知源程序行數的實

際困難,從軟件產品的功能度(functionality)
出發估算出軟件產品的規模。

項目估算的功能點方法
1.功能度
功能點方法是以項目的需求規格說明中已經得到確認的軟 件功能為依據,著重分析要開發系統的功能度,并且認為, 軟件的大小與軟件的功能度相關,而與軟件功能如何描述無 關,也與功能需求如何設計和實現無關。

項目估算的功能點方法
? 1.功能度
為具體說明功能點方法,區分各種不同的功能, 需要建立應用系統邊界的概念。
?

應用系統邊界把目標應用系統與用戶和與其相關 的應用系統分割開來。

?

內部功能僅限于應用系統的邊界之內,而外部功 能則是跨邊界的。

項目估算的功能點方法
?

系統邊界
圖中系統A有4項功能都是跨越邊界的,稱其為外部功能。

項目估算的功能點方法
?

五種類型的功能:

(1)外部輸入。外部輸入處理那些進入應用系統邊界的數 據或是控制信息。經特定的邏輯處理后,形成內部邏輯文 件。 (2)外部輸出。外部輸出處理離開應用系統邊界的數據或 控制信息。 (3)內部邏輯文件。是用戶可識別的邏輯相關數據或控制 信息組,它可在應用系統邊界之內使用。內部邏輯文件代 表 應用系統可支持的數據存儲需求。

項目估算的功能點方法
?

五種類型的功能:

(4)外部接口文件。外部接口文件是用戶可識別的邏輯相 關數據或控制信息構成的集合,該控制信息為應用系統所 使用,卻被另一應用系統所支持。外部接口文件代表應用 系統外部支持的數據存儲需求。 (5)外部查詢。外部查詢是唯一的輸入/輸出組合,它為實 現即時輸出引起所需數據的檢索,代表了應用系統查詢處 理的需求。

項目估算的功能點方法
2.功能復雜性
軟件項目每類功能的復雜程度可能各不相同,為表明功能 復雜性的差別,將其分為簡單的、中等的和復雜的3個等 級。同時為表示其差異程度,分別給予不同的影響參數。下 表列出了功能復雜性的影響參數值。

項目估算的功能點方法
3.未調節功能點
只要能夠從規格說明中得到了以上5種功能度的各級復雜 性功能點的個數C,不難計算出未調節功能點的值。
UFP = ?? ωij Cij
i =1 j =1 5 3

其中:i 代表功能度類型號;i=1,2,…,5; j 代表復雜性的等級;j=1,2,3; ωij是第i類功能度和第j級復雜性的影響參數,即上表 中第i行,第j列的參數值; Cij是第i類功能度和第j級復雜度功能點的個數。

項目估算的功能點方法
4.調節因子
任何軟件都會有其自身特性,在考慮其各種自身特性時, 從 以下兩個方面分解功能點計算的調節因子。 (1)影響因子。經過對各類軟件的分析,綜合出以下14種 類型的影響因子: ? ? ? ? ? ? ? 數據通信 分布數據處理 性能目標 系統配置要求 事務率 聯機數據錄入 最終用戶效率 ? 聯機更新 ? 復雜的處理邏輯 ? 可復用性 ? 易安裝性 ? 易操作性 ? 多工作場所 ? 設施變更

項目估算的功能點方法
(2)影響級。上述影響因子對軟件功能度的影響有多大必 須加以區分,于是將影響因子的影響程度分為6級,即 0級 無影響 1級 微小影響 2級 輕度影響 3級 中度影響 4級 顯著影響 5級 重大影響 綜合考慮14類影響因子的影響度N,應是將14種影響疊加 起來,其值為0~70(14×5)。由此得到復雜度調節因子 (complexity adjustment factor,CAF) CAF=0.65+0.01N 其值應在0.65~1.35,其中基本調節常數是0.65,可見最大 的調節量為35%。

項目估算的功能點方法
5.交付功能點
經過調節因子調節后的功能點值被稱為交付功能點 (delivered function point,DFP) DFP=CAF×UFP

6.交付功能點與軟件規模
一些研究成果表明,上述計算出的功能點的值可以代表軟 件的規模,也可作為估算成本的依據。軟件的規模可用交付 的源代碼行數(delivered lines of code,DLOC)來表 示。

項目估算的功能點方法
功能點與DLOC的對應關系如下表所示。例如, 1 DFP相當于105 DLOC(COBOL程序) 1 DFP相當于128 DLOC(C程序)

項目估算的功能點方法
7.功能點方法的優點
(1)DFP只與由規格說明得到的信息相關,而交付代碼的 行數若不通過功能點計算是不能直接從規格說明中得到的。 (2)DFP與實現軟件的語言無關。

項目估算的功能點方法
8.功能點方法的不足之處
(1)針對需求規格說明進行分析時,主觀因素難以完全排 除,這包括: ● 對于規格說明,每人可能有不同的解釋; ● 對于功能度的復雜性估計也可能因人而異;

● CAF計算時會有主觀因素。
(2)非數據處理問題,如實時軟件、系統軟件、科學計算 軟件等功能點的上述計算方法并不適用。 (3)DFP的計算目前尚不能借助工具自動完成。

軟件開發成本估算
1.專家判定——Delphi方法
專家判定技術就是由多位專家進行成本估算,取得多個估
算值。有多種方法把這些估算值合成一個估算值,Read公

司提出了Delphi技術,作為統一專家意見的方法。可得到極
為準確的估算值。

軟件開發成本估算
標準Delphi技術的步驟:
① 組織者發給每位專家一份軟件系統的規格說明書(略去 名稱和單位)和一張記錄估算值的表格,請他們進行估算。 ② 專家詳細研究軟件規格說明書的內容,然后組織者召集 小組會議,在會上,專家們與組織者一起對估算問題進行討

論。

軟件開發成本估算
? 標準Delphi技術的步驟:
③ 各位專家對該軟件提出3個軟件規模的估算值,即 ai——該軟件可能的最小規模(最少源代碼行數); mi——該軟件最可能的規模(最可能的源代碼行數); bi——該軟件可能的最大規模(最多源代碼行數)。

無記名地填寫表格,并說明做此估算的理由。

軟件開發成本估算
標準Delphi技術的步驟:
④ 組織者對各位專家在表中填寫的估算值進行綜合和分 類,做以下事情。 ● 計算各位專家(序號為i,i=1,2,…,n)的估算期望 值Ei和估算值的期望中值E。

● 對專家的估算結果進行分析。

軟件開發成本估算
標準Delphi技術的步驟:
⑤ 組織者召集會議,請專家們對其估算值有很大差異之處 進行討論。專家對此估算值另做一次估算。 ⑥ 在綜合專家估算結果的基礎上,組織專家再次無記名地 填寫表格。

軟件開發成本估算
從步驟④到步驟⑥適當重復幾次,最終可獲得一個得到多 數專家共識的軟件規模(源代碼行數)。 最后,通過與歷史資料進行類比,根據過去完成項目的規 模和成本等信息,推算出該軟件每行源代碼所需成本。然后

再乘以該軟件源代碼行數的估算值,得到該軟件的成本估算
值。

軟件開發成本估算
2.COCOMO模型
軟件工程專家Barry Boehm在其著作《軟件工程經濟學》中 提出了軟件估算模型層次結構,稱為構造式成本模型 COCOMO(COnstructive Cost MOdel),也許這是在軟 件界影響最為廣泛、最為著名的估算模型。

軟件開發成本估算
(1) 3種類型的軟件
COCOMO是針對Boehm劃分的3種類型軟件進行估算的。 ① 固有型(organic mode)項目。規模較小,較為簡單的 項目,開發人員對項目有較好的理解和較為豐富的工作經 驗。 ② 嵌入型(embedded mode)項目。這類項目的開發工作 緊密地與系統中的硬件、軟件和運行限制聯系在一起,如 飛機的飛行控制軟件。 ③ 半獨立性(semi-detached mode)項目。項目的性質介 于上述兩個類型之間,其規模與復雜性均屬中等,如事務 處理系統,數據庫管理系統等。

軟件開發成本估算
(2)COCOMO的3級模型 ① 基本COCOMO模型(basic model)。 ● 該模型為靜態、單變量,以估算出的源代碼行數計算。 ● 開發工作量
E ? ab (KLOC)bb (人月)

其中,KLOC為交付的千行代碼數。ab、bb為模型系數。

軟件開發成本估算
●開發周期
D ? cb db E db

(月 )

● 系數
基本COCOMO模型系數如下表所示。

軟件開發成本估算
② 中級COCOMO模型(intermediate)
● 該模型除考慮源代碼行數外,還考慮調節因子(EAF), 用其體現產品、軟件、人員和項目等因素。

● 開發工作量

E ? ai (KLOC)bi ? EAF
● 系數

軟件開發成本估算
● 調節因子EAF(effort adjustment factor)。包含了4類15種屬性, 其值為0.7~1.6。

軟件開發成本估算
③ 高級COCOMO模型(advanced)
● 高級COCOMO模型除保留中級模型的因素外,還涉及軟 件工程過程不同開發階段的影響,以及系統層、子系統 層和模塊層的差別。 ● 軟件可靠性在子系統層各開發階段有不同的調節因子。

13.3 進度管理
? ? ? ? 進度控制問題 甘特圖 時標網狀圖 PERT圖

進度控制問題
1.值得重視的現象
軟件項目能否按計劃的時間完成,及時提交產品是項目 管理的一個重要課題。我們都希望按計劃及時完成,但項 目未能按預期的進度提交產品,延誤工期的現象經常會出 現。我們必須重視這一現象,分析其原因,并有針對性地 采取措施。

2.制訂項目進度安排的條件
制訂項目進度安排計劃是為了實施,自然希望越準確, 越符合實際越好,但是怎樣才能做到這一點,需要在這以 前做些工作,創造良好的條件,使得進度安排的確定是有 根據的。

進度控制問題
這些條件包括以下7條:
(1)項目分解。無論多么大、多么復雜的項目都必須首先 將其劃分成能夠管理的若干活動和若干任務,并且往往這種 分解是多個層次的。 (2)確定各部分之間的相互關系。劃分后的活動和任務按

項目本身的要求,必定存在著一定的相互依賴關系,如誰先
誰后,或是兩者應該并行互不依賴等。 (3)時間分配。為每項活動和任務分配需要的時間,如需 要多少人天的工作量。

進度控制問題
(4)確認投入的工作量。應確認按項目要求的人力投入工
作量在實際工作中能夠予以滿足,而不致出現某些工作階段 人力投入不足的現象。 (5)確定人員的責任。 (6)規定工作成果。任何分配的任務都應給出符合要求的

工作成果,它應該是整個項目的一個組成部分。
(7)規定里程碑。任何一項工作完成后需經過一定形式的 檢驗,如經過評審或審核(批準)得到認可,被認為確已完

成,表示一個里程碑已經完成。里程碑也被稱為基線。

甘特圖
?

甘特圖(Gantt chart)是表示工作進度計劃以及工作實 際進度情況最為簡明的圖示方法。 甘特圖中橫坐標表示時間,以水平線段表示子任務的工作 階段,可以為其命名。 線段的起點和終點分別對應著該項子任務的開工時間和完 成時間,線段的長度表示完成它所需的時間,有實線和虛 線之分,一開始做出各項子任務的計劃時間,應該都以虛 線表示。

?

?

甘特圖

甘特圖可以清楚地表示各項子任務在時間對比上的關系,但 無法表達多個子任務之間更為復雜的銜接關系。

甘特圖

時標網狀圖
為克服甘特圖的缺點,將 甘特圖做了一些修改,形成 了時標網狀圖(time scalar network),如右圖所示。 圖中的任務以有向線段表示,

其指向點表示任務間的銜接
點,并且都給予編號,可以 顯示出各子任務間的依賴關系。它顯示出比甘特圖具有優 越性。

PERT圖
計劃評審技術(program evaluation and review
techique,PERT)也稱網絡圖方法,或簡稱PERT圖方 法,它的另一名稱是關鍵路徑法(critical path method, CPM)。

PERT圖
?

PERT圖中以有向的箭頭作為邊表示子任務,它是有名稱 (即子任務名)、有長度(即完成此項子任務所需的時間) 的向量; 以有編號的圓圈作為結點,它應該是子任務向量的始發點 或指向點;
由若干條邊和若干個結點構成了網狀圖,于是我們可以沿 相互銜接的子任務形成的路徑,進行路徑長度的計算、比 較和分析,從而實現項目工期的控制。

?

?

實例
? PERT圖

實例
? 分層PERT圖

13.4 配置管理
?

軟件工程項目隨著工作的進展會產生多種信息,包括技 術資料、管理資料等,如何管好這些資料是項目管理面 臨的重要問題。 另一方面,還必須考慮到,這些資料和信息不僅不斷地 產生,而且還在不斷地演化和變更。
如何遵循一套嚴謹、科學的管理辦法,使信息和資料的 產生、存放、查找和使用既有序又高效,不致發生混亂 和差錯的現象,這正是配置管理所要解決的問題。

?

?

13.4 配置管理
? ? ? ? ? ? ? 配置管理概述 軟件配置標識 變更管理 版本控制 系統建立 配置審核 配置狀態報告

軟件配置管理概述
?

軟件配置管理的目的是為某個過程或某個項目的 軟件項建立和保持完整性,以便相關方便于使用。 軟件配置管理要開展的活動包括:配置標識、配 置控制、配置狀態報告、配置評價以及發布管理、 交付等。

?

軟件配置管理概述
我們將軟件配置管理的對象稱為軟件配置項 (software configuration item),包括:
(1)與合同、過程、計劃和產品有關的文檔及數據; (2)源代碼、目標代碼和可執行代碼; (3)相關的產品,包括軟件工具、庫內的可復用軟件、外 購軟件及顧客提供的軟件。

軟件配置管理概述
軟件配置管理的主要任務如下:
(1)制訂軟件配置管理計劃。包括: ① 配置標識規則; ② 如何建立配置數據庫,并將配置項置于配置管理之下; ③ 配置管理人員的職責及配置管理活動;

④ 所采用的配置管理工具、技術和方法。
(2)實施變更管理,防止項目進行中因變更導致的混亂。 (3)實施版本管理和發布管理。

軟件配置管理概述
軟件配置管理的工作是要解決下列問題:
(1)采用什么方式去標識和管理數量眾多的程序、文檔等 的各種版本? (2)在軟件產品交付用戶之前和交付之后如何控制變更? 實現有效的變更?

(3)誰有權批準變更以及安排變更的優先級?
(4)用什么方法估計變更可能引起的其他問題? 這些問題的解決正是軟件配置管理應完成的任務:配置 標識、版本管理、變更管理、配置審核及配置報告。

軟件配置標識
軟件配置是一個動態的概念。不僅隨著開發工作的進展會
出現許多需控制的文檔,而且開發過程中會出現各種變更。 為了達到特定的要求,必須對配置項進行控制,而實現控制 的首先就要對它們命名,這正是配置標識的任務。 制訂適當的命名規則是配置標識的第1步工作。命名不能

任意、隨機地進行,命名要求具有:
(1)唯一性:目的在于避免出現重名,造成混亂; (2)可追溯性:使命名能夠反映命名對象間的關系。

軟件配置標識
? 例如,可以采用層式命名規則以利反映樹狀結構,某樹狀 結構軟件的結構圖如圖所示。CODE部分可沿樹狀結構命名 為 PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE

軟件配置標識
可以利用面向對象的方法進行標識。通常需標識 兩類型對象:基本對象和復合對象。
?

基本對象是由軟件工程師在分析、設計、編碼和測試時所 建立的“文本單元”。
?

例如,基本對象可能是需求規格說明中的一節,一個模塊 的源程序清單、一組用來測試一個等價類的測試用例。
?復合對象則是基本對象和其他復合對象的集合。

軟件配置標識
復合對象實例:“設計規格說明”是一個復合對象,它是 一些基本對象(如“數據模型”和“模塊N”)的集合。
?

軟件配置標識
每個對象可用一組信息來唯一地標識,這組信息包括:
(名字、描述、資源、實現)
?

對象的名字是一個字符串,它明確地標識對象。

?

對象描述是一個表項,它包括:對象所表示的軟件配置項類型(如 文檔、程序、數據)、項目標識、變更或版本信息。
資源是“由對象所提供的、處理的、引用的或其他所需要的一些實 體”。例如,數據類型、特定函數,甚至變量名都可以看做是對象 資源。 對于一個基本對象來說, “實現”是指向“文本單元”的指針,而 對于復合對象來說,則為null(空)。

?

?

軟件配置標識
? 配置對象的標識還必須考慮在命名對象之間存在的聯系。
?

<part of> 聯系: 一個對象可以是一個復合對象的一個 組成部分,使用聯系<part of>進行標識。這個聯系定義 了對象的層次。例如, E—R diagram 1.4 <part of> data model; data model <part of> Design Specification;

?

<interrelated>聯系:對象之間的聯系可以跨越對象層次 的分支相互關聯。
data model <interrelated> data flow model;

變更管理
1.變更不可避免
軟件開發過程中變更是不可能避免的,變更控制就是要 把變更嚴格地控制起來,隨時保留變更的有關信息,把精 確、清晰的信息傳遞到開發過程的下一活動或下一任務, 防止出現混亂。變更管理的任務如下: (1)分析變更,根據成本—效益和涉及的技術等因素判斷 變更實施的必要性,確定是否實施變更。 (2)記錄變更信息,并追蹤變更信息。 (3)確保變更在受控條件下進行。 為有效地實現變更控制需借助于配置數據庫和基線的概念。

變更管理
2.配置數據庫
設置配置數據庫,使它發揮出以下作用:

(1)用其收集與配置有關的所有信息;
(2)評價系統變更的效果; (3)提供配置管理過程的管理信息。

變更管理
配置數據庫可分為開發庫、受控庫和產品庫3類。
① 開發庫:專供開發人員使用,其中的信息可以進行頻繁 的修改,對其控制相當寬松。 ② 受控庫:其中存放在生存期某一階段工作結束時釋放的 階段產品,這些是與軟件開發工作相關的計算機可讀信息 和人工可讀信息。軟件配置管理正是對受控庫中的各個軟 件項進行管理,受控庫也稱為軟件配置管理庫。 ③ 產品庫:在開發的軟件產品完成系統測試后,作為最終 產品存入產品庫中,等待交付用戶或現場安裝。

變更管理
3.基線和變更控制
基線(baseline)是軟件生存期各開發階段末尾的特定點, 也被稱為里程碑(milestone)。
?

它的作用是把各階段的開發工作劃分得更加明確,使得本 來連續的工作在這些點上斷開,使之便于檢驗和確認階段開 發成果。
?

它對變更控制起的作用是,不允許跨越里程碑去修改另一 階段的工作成果。
?

變更管理
下圖所示為軟件開發過程的若干配置基線。以設計基線
為例,若項目的進展已跨過了設計基線,開始了編碼工 作,那么設計的變更必須受到嚴格的控制,原則上已不允 許,應該認為,此時的設計已被“凍結”。

變更管理
4.變更管理過程
變更管理過程可用下圖給出的流程來說明。

變更管理
? 變更請求表(change request form,CRF)的格式如下 表所示。表中一些內容需由變更分析人員對變更進行分析和 評估以后填寫。

變更管理
?

“檢出”和“登入”處理實現了兩個重要的變更 控制要素,即存取控制和同步控制。
存取控制管理各個工程師存取或修改一個特定軟 件配置對象的權限; 同步控制可用來確保由不同的人所執行的并發變 更不會產生混亂。

?

?

變更管理
?

存取和同步控制如圖所示。根據經批準的變更請求和
變更實施方案,軟件工程師從項目數據庫中檢出要變更的 配置對象。

變更管理
?
?

存取控制功能保證了軟件工程師有檢出該對象的權限。

同步控制功能則封鎖(lock)了項目數據庫中的這個對象, 使得當前檢出的版本在沒有被置換前不能再更新它。

變更管理
?
? ?

軟件的變更通常有兩類不同的情況: 為改正小錯誤需要的變更; 為了增加或者刪掉某些功能,或者為了改變完成 某個功能的方法而需要的變更。

版本控制
1.版本管理和發行管理
(1)版本管理
?

?
?

?

版本管理(version management)是對系統不同版本 進行標識和跟蹤的過程。 版本標識的目的是便于對版本加以區分、檢索和跟蹤, 以表明各個版本之間的關系。 一個版本是軟件系統的一個實例,在功能上和性能上與 其他版本有所不同,或是修正、補充了前一版本的某些 不足。 這些不同的版本可能在功能上是等價的,但它們分別適 應于不同的硬件或軟件環境的要求。

版本控制
(2)系統發行 系統發行(system release)是分配給客戶一個版本, 每次系統發行都應有新的功能或是針對不同的系統運行環 境。通常軟件系統的版本數要比發行次數多,因為有的版本 并未發行。例如,有的版本僅供開發機構內部使用,或是專 供測試等。 通常一次發行不僅只是提供一個可執行程序,或一套程 序,可能還要包括: ● 配置文件:規定發行所作的特定安裝; ● 數據文件:系統運行所需的數據; ● 安裝程序:表明系統如何安裝到目標機上; ● 電子文檔或書面文檔:這是對系統的描述。

版本控制
2.版本標識
版本標識(version identification)是由版本的命名規則 決定的。由于前后版本存在著傳遞關系,因此,如何正確地 反映這一傳遞關系,就應當體現在其命名中。 可能使用的命名規則有下面所述的幾種:
?號碼順序型版本標識 ?符號命名版本標識 ?屬性版本標識

版本控制
(1)號碼順序型版本標識 ? 如下圖所示。這種標識十分明顯地給出了版本之 間的傳遞關系,但是如果當前版本生出了多個新 版本,標識就稍有困難。

版本控制
(2)符號命名版本標識 用符號表達版本間的傳遞關系,如不用V1.1.2的形式, 而采用V1/VMS/DB Server來表示一個在VMS操作系統上 運行的數據庫服務器版本。 (3)屬性版本標識 屬性版本標識是把有關版本的重要屬性反映在標識中, 可以包括的屬性有:客戶名、開發語言、開發狀態、硬件平 臺、生成日期等。每個版本都由唯一的一組屬性標識,即一 組具有唯一性的屬性值。

版本控制
3.發行管理
一個系統的新發行與新版本有著不同的含義。
?

新版本是在修改發現的軟件缺陷后,開發出新的程序、形 成新的系統; 新發行是除了寫出新的程序,形成新系統之外,還要為用 戶準備數據、配置文件、編寫新文檔,準備新包裝。 新發行要比新版本開銷大。

?

?

版本控制
?

系統發行策略

?無論是哪一種維護工作完成之后,配置管理人員都要分析

變更影響的組件,確定何時生成新系統、何時進行系統發行。
?通常一個系統改動越多,引入錯誤的機會也越多,發現的

錯誤必須在下次發行時解決。為了把出現問題的機會分散開, 往往把修補變更后的發行與系統功能變更的發行交叉起來, 如將其按下圖所示的順序來安排。

系統建立
?

系統建立(system building)是將系統的組件組 合成完整的程序,以執行某一特定目標配置的過 程。 該過程中可能包括一些組件的編譯以及將目標代 碼結合在一起,構成可執行系統的連接過程。

?

系統建立
?

系統建立必須要考慮的因素有:

(1) 構成系統的所有組件是否都已包含在系統建立的指令中? (2) 每個需要組件的適當版本是否包含在系統建立的指令中? (3) 所有需要的數據文件都是可用的嗎? (4) 如果在一個組件內引用了數據文件,所有數據名與目標機 上數據文件的名字是否一致? (5) 編譯程序和其他所需工具的適用版本是可用的嗎?軟件工 具目前流行的版本是否與開發系統時所用的版本兼容?

配置審核
?

軟件的完整性,是指開發后期的軟件產品能夠正確地反映 用戶所提出的對軟件的要求。 軟件配置審核(configuration audit)的目的就是要證實 整個軟件生存期中各項產品在技術上和管理上的完整性。 同時,還要確保所有文檔的內容變動不超出當初確定的軟 件要求范圍。使得軟件配置具有良好的可跟蹤性。 這是軟件變更控制人員掌握配置情況、進行審批的依據。

?

?

配置審核
?

軟件的變更控制機制通常只能跟蹤到工程變更順序產生為

止,那么如何知道變更是否正確完成了呢?一般可以用正式 技術評審和軟件配置審核兩種方法審查。 正式的技術評審著重檢查已完成修改的軟件配置對象的技 術正確性,評審者評價軟件配置項,決定它與其他軟件配置 項的一致性,是否有遺漏或可能引起的副作用。原則上,正 式技術評審應對所有的變更進行。
?

軟件配置審核作為正式技術評審的補充,評價在評審期間 沒有考慮的軟件配置項特性。
?

配置狀態報告
為了清楚、及時地記載軟件配置的變化,不致于到后期造 成貽誤,需要對開發的過程做出系統的記錄,以反映開發活 動的歷史情況。這就是配置狀態報告的任務。 報告的主要根據是變更控制小組會議的記錄,報告對于每 一項變更說明: (1)發生了什么? (2)為什么會發生? (3)誰做的? (4)什么時候發生的? (5)會有什么影響?

配置狀態報告
下圖描述了配置狀態報告。每次新分配一個軟件配置項或更 新一個已有軟件配置項的標識,或者一項變更申請被變更控 制負責人批準,并給出一種工程變更順序時,在配置狀態報 告中就要增加一條變更記錄條目。一旦進行了配置審核,其 結果也應該寫入報告之中。


推薦相關:

第13章軟件項目管理_圖文.ppt

第13章軟件項目管理 - 第13章 軟件項目管理 ? 軟件項目管理概述 ? 項目估算 ? 進度管理 ? 配置管理 13.1 軟件項目管理概述 管理目標 ? 通常認為,項目成功的...

第13章 軟件項目管理_圖文.ppt

第13章 軟件項目管理 13.1 13.2 13.3 13.4 13.5 13.

軟件工程 第13章 軟件項目管理_圖文.ppt

軟件工程 第13章 軟件項目管理 - 第13章 軟件項目管理 13.1 13.2

第13章軟件項目管理方案_圖文.ppt

第13章軟件項目管理方案 - 第13章 軟件項目管理 13.1 估算軟件規模 1

第13章 軟件質量與軟件項目管理_圖文.ppt

第13章 軟件質量與軟件項目管理 - 第13章 軟件質量與軟件項目管理 ? 復習

第13章軟件項目管理概述_圖文.ppt

第13章軟件項目管理概述 - 第13章 軟件項目管理 第13章 軟件項目管理 1

軟件工程第十三章 軟件項目管理_圖文.ppt

軟件工程 第十三章 軟件項目管理 中南大學 Central South Univ

張海藩第13章 軟件項目管理_圖文.ppt

第13章 軟件項目管理 13.1 13.2 13.3 13.4 13.5 估算軟

第13章軟件項目管理_圖文.ppt

第13章軟件項目管理 - 第13章 軟件項目管理 13.1 估算軟件規模 13.

第十三章軟件工程管理-_圖文.ppt

第十三章軟件工程管理- - 第十三章 軟件工程管理 本章開始軟件項目管理有關內容

第13章軟件項目管理_圖文.ppt

第13章軟件項目管理 - 第13章 軟件項目管理 所謂管理就是通過計劃、組織和控制 等一系列活動,合理地配置和使用各種資 項目管理過程 軟件項目管理的對象是軟件工程...

軟件工程課件之第13章_軟件項目管理(第五版)(張海藩編....ppt

軟件工程課件之第13章_軟件項目管理(第五版)(張海藩編著)_理學_高等教育_教育專區。第13章 軟件項目管理 13.1 13.2 13.3 13.4 13.5 13.6 13.7 估算...

第13章it軟件項目收尾管理_圖文.ppt

第13章it軟件項目收尾管理 - ? 所謂項目收尾管理就是對IT軟件項目的收尾工作進 行管理,它按項目的進展一般可以分為兩種情況: ? (1)當項目進展順利到正常結束的...

第13章 軟件項目管理_圖文.ppt

第13章 軟件項目管理 - 第13章 軟件項目管理 1 本章內容: ? ? ?

【項目管理】第13章 IT軟件項目收尾管理_圖文.ppt

項目管理第13章 IT軟件項目收尾管理_計算機軟件及應用_IT/計算機_專業資料。第13章 IT軟件項目收尾管理 ? 所謂項目收尾管理就是對IT軟件項目的收尾工作進 行...

第13章 軟件項目管理_圖文.ppt

第13章 軟件項目管理 - ? ? ? ? ? 項目管理過程 軟件生產率和質量的

第十三章項目管理軟件及其應用_圖文.ppt

第十三章項目管理軟件及其應用 - 第十三章 項目管理軟件及其應用 本章內容 ? ? ? ? ? 項目管理軟件的發展 項目管理軟件的應用現狀 項目管理軟件的主要功能 項目...

第13章 軟件項目管理_圖文.ppt

第13章 軟件項目管理 - 第13章 軟件項目管理 章 13.1 13.2 13

第13章it軟件項目收尾管理_圖文.ppt

第13章it軟件項目收尾管理 - 文檔均來自網絡,如有侵權請聯系我刪除文檔... 第13章it軟件項目收尾管理_計算機軟件及應用_IT/計算機_專業資料。文檔均來自網絡,如有...

第13章 軟件項目管理.ppt

第13章 軟件項目管理_計算機軟件及應用_IT/計算機_專業資料。第13章 軟件項目管理 ? ? ? ? 軟件項目管理概述 項目估算 進度管理 配置管理 13.1 軟件項目管理...

網站首頁 | 網站地圖
All rights reserved Powered by 學霸學習網 www.tghxrb.tw
copyright ©right 2010-2021。
文檔資料庫內容來自網絡,如有侵犯請聯系客服。[email protected]
四川快乐12软件