公司簡介最新消息客戶服務常見問題商品型錄聯絡資訊 
最新消息
新聞集錦
CMMI-ACQ簡介
軟體發展生命週期模式與 ETVX介紹
CMMI V&V---淺談電子商務網站的性能測試
論文件資料與建構項目管理規劃
論軟體專案的風險管理
做愈多,死愈快-如何利用CMMI 架構 降低風險 提昇利潤從大前研一新作《即戰力》談起
Decision Analysis and Resolution
CMMI 最新趨勢及資訊系統委外籌獲模式(CMMI-ACQ) 概述
CMMI 工程流程改善的第一課-需求與需求發展
專案管理與專案管理活動介紹
談資訊專案運作流程與各階段注意事項
談從CMMI V1.1 到 CMMI V1.2 (2007-08-17)
工程品質有效管控-論審查(Review)與CMMI (2007-08-17)
可取徵才Career at Coach TM
 
新聞集錦
CMMI-ACQ簡介

CMMI-ACQ簡介

■ 朱慧德

前言

隨著資訊與網路科技之快速發展與應用普及,對政府機關及民間企業都造成極大的衝擊。政府機關對內要因應民意高漲與服務水準要求不斷提昇,對外則需面對國際間追求提升國家競爭力的壓力;民間企業則由於產業環境的激烈競爭,迫使企業必須重新思考與評估內部的營運活動,辨識企業的核心能力,集中資源專注於核心活動以創造競爭優勢。因此,藉由委外導入資訊技術,提供高效率、低成本,富有彈性而快速反應的服務,已勢必成為政府機關及民間企業一股不可遏止的潮流。

資訊業務委外雖可對組織產生效益,但也會帶來一些風險。根據Standish Group International 在報告中說明,有15%的軟體專案終究沒有完成,並有超過80%的軟體專案延宕,並且超過預算;2000年的統計報告中,只有26%的軟體專案成功,另外的74%都是失敗。多位學者從影響委外績效之原因、委外的困難、委外成功因素等不同觀點作出研究,歸納出資訊系統委外所遭遇最主要的困難為品質不確定、專案時間的延長與成本超乎預算。所以,為了在合理的成本與預定時程內,交付高品質的軟體,軟體工程領域的專家學者們,不斷地研究改善各種軟體開發技術與方法。

然在軟體籌獲組織為提高委外軟體品質而要求軟體發展組織的資格評鑑或管理能力認證之餘,卻往往因本身的籌獲流程相對不成熟,沒有標準的作業程序,無法做好軟體籌獲規劃、監控等重要工作項目,進而影響軟體委外專案的成功。基於上述問題, CMU/SEI 相繼發展了「軟體籌獲能力成熟度模式(Software Acquisition Capability Maturity Model,SA-CMM)」、「能力成熟度整合模式-籌獲模組」(CMMI Acquisition Module,CMMI-AM)及「能力成熟度整合模式-籌獲」(CMMI for ACQuition,CMMI-ACQ),用以評估及改善軟體籌獲流程。

SA-CMM介紹

能力成熟度模式(CMM)是由美國卡內基美隆大學軟體工程學院所發展,以作為軟體生產全面品質管理與流程改善的架構。1987 年第一次發表研究成果,並於1991 年正式發表CMM V1.0 版。

一般稱CMM通常是指軟體能力成熟度模式SW-CMM,相較SW-CMM之於軟體組織為改善其軟體開發效能,SA-CMM 則為軟體籌獲組織為改善資訊委外流程,以達到籌獲高品質交付軟體的成熟度評估模式。

簡言之,在藉由訂定契約而獲得軟體的流程中,SW-CMM 描述的是一個好的「軟體開發者」所必須要具有的能力,而SA-CMM 描述的則是一個好的「軟體籌獲者」所必須要具有的能力。

SA-CMM 軟體籌獲流程管理的框架將軟體籌獲流程的成熟度分為五個等級,概略敘述如下:

第一等級:初始級(Initial)

在此成熟度等級的組織,專案團隊並無提供一穩定的環境以供籌獲產品;團隊的組成是基於可得的人力,以致籌獲能力散渙。籌獲程序並無適當的管理,專案需要格外的追蹤。

第二等級:可重覆級(Repeatable)

在此成熟度等級的組織,新專案的規劃與追蹤是基於過去相似的經驗。將合約管理及專案管理流程標準化,使專案團隊能「重覆」過去成功專案的實務工作。專案團隊將籌獲管理計畫及程序文件化,並建立基本籌獲管理的實務工作及控制。專案經理必須對專案成本、時程、需求及績效加以追蹤。此外,專案團隊應與供應商一起工作,以建立一穩定、合作性的工作環境,專案規劃中應包括追蹤供應商團隊的績效以確認合約需求被滿足。

第二等級的籌獲組織重複過去的成功經驗,利用文件化程序提供專案環境,對於籌獲規劃及追蹤已有穩定的模式。

第三等級:已定義級(Defined)

在此成熟度等級的組織,已建立標準的籌獲流程,以供專案應用。同時為使專案更有效執行,標準流程也會被適當地調適。組織並有一訓練規劃,以確保所有的參與者具有滿足工作的知識技能。

籌獲專案的進行以籌獲流程的標準為基礎。在此階段標準的籌獲流程已被明確定義及了解;因此對於科技上發展的管理能見度提高,管理及軟體工程活動能有效配合。此外,專案團隊能平衡政策與專案需求的衝突,確保規劃及合約需求的承諾,並與供應商一同解決可能發生的問題。在整個籌獲流程中,風險已被定義且管理。

第三等級的籌獲組織能控制執行、成本、時程及需求,並追蹤品質。

第四等級:定量級(Quantitative)

在此成熟度等級的組織,專案團隊能為籌獲流程及產品設定量化目標,並建立以量化為基礎的專案評估程序。

專案團隊在籌獲流程中,藉由量化的目標,控制專案執行的變異在可接受的範圍內。

第四等級的籌獲組織,在專案執行時預測流程及產品品質,並將其導向可接受的範圍之內;當超出範圍的產出發生時,便立即提出修正行動。

第五等級:最佳化級(Optimizing)

此階段的組織專注於籌獲流程的持續改善。能界定需最佳化的流程,利用所收集的資料產出統計數據供分析,以做為改善的建議,並利用科技革新界定、評估及制度化最佳的籌獲管理與工程實務工作。

第五等級的籌獲組織,持續努力降低執行的變異,藉由現有機制的精進及使用新科技創新來作改善。

如同其他CMM,在SA-CMM 中的每個成熟度等級中各有多個關鍵流程領域(Key Process Area,KPA);而在每個KPA 內都設定了目標(Goals),並延伸出主要的作業(Activities);此外,每個KPA 內都有一組制度化特性(Institutionalization Features),包括執行承諾(Commitment to Perform)、執行能力(Ability to Perform)、量度與分析(Measurement and Analysis)、驗證(Verification)。各成熟度等級的關鍵流程領域如表一。

表一、SA-CMM 各成熟度等級的關鍵流程領域

成熟度等級
重點
關鍵流程領域
5最佳化級
持續流程改善
籌獲創新管理持續流程改善
4定量級
定量管理
定量籌獲管理定量流程管理
3已定義級
流程標準化
訓練計畫管理籌獲風險管理合約執行管理專案執行管理使用者需求流程定義及維護
2可重覆級
基礎的專案管理
移轉支援評估合約追蹤與監督專案管理需求發展及管理招標軟體籌獲規劃
1初始級
勝任的人們及英雄式主義

CMMI-AM介紹

2003年末,在美國國防部要求將CMMI 詮釋以適籌獲組織使用下,SEI提出CMMI 籌獲模組(CMMI Acquisition Module,CMMI-AM),其目標是希望經由簡化CMMI 的最佳執行常規,幫助籌獲計畫的自我改善及自我評鑑活動,與建立有效率的籌獲執行常規,並能夠容易的被實行。CMMI 模式與CMMI 模組,是兩種不同類型的產品。CMMI 模式是CMMI產品成員的一部份,包含CMMI 最佳執行方法的正式文件,及使用標準CMMI 流程改善評鑑方法(Standard CMMI Appraisal Method for Process Improvement,SCAMPI)A級(Class A)評鑑以達一成熟度等級。然而,CMMI模組現階段只是從CMMI 模式引用,以作為流程改善的前導。模組可被用在非正式差異分析(Gap Analysis),以界定優勢、弱勢、改善機會、風險及最佳執行方法上,或作為使用CMMI SCAMPI Class A 評鑑時的非正式工具。

CMMI-AM 是植基於從CMMI、SA-CMM、FAA iCMM(The Federal Aviation Administration Integrated Capability Maturity Model)及Section 804(Section 804 of the National Defense Authorization Act)等框架上所擷取的最佳執行方法,為籌獲組織定義出有用及有效的執行方法。其重點,對組織內部而言,是確保籌獲專案可有效用的被實施;對組織外部而言,則是引導專案監督與供應商監督。這些最佳執行方法為籌獲流程的行為規範提供一個基礎,並使產品及服務的發展可高度成功的被重覆執行。

CMMI-AM 目前的版本是2005年5月公佈的1.1版,包含下列12個流程領域,如圖一所示。

《圖一》CMMI-AM流程領域

其間並沒有CMMI階段式表述之 Level 概念,這符合連續式表述的自由度與可見度特性,即在強調依其企業業務上目標選擇改善重點,本模組在結合相關流程領域,聚焦在買方籌獲流程改善,與CMMI V1.1 Continuous Representation相較,運作及支援之轉移、邀商及契約監視二項為新增的流程領域,是另一特點。對組織內部而言,其重點是確保籌獲專案可有效用的被實施,對組織外部而言,則是引導專案監督與供應商監督。

CMMI-ACQ介紹

2006年6月由通用汽車資訊科技委外部門與SEI共同發表編號為CMU/SEI-2006-SR-005,名為Adapting CMMI for Acquisition Organizations: A Preliminary Report(為籌獲組織調適CMMI:初步報告)。該報告所呈現的是CMMI-ACQ的草案初稿,CMMI-ACQ是為籌獲組織所調適的CMMI。CMMI-ACQ草案初稿乃是源於CMMI V1.2架構與框架之最佳執行方法的彙集;這些籌獲活動的最佳執行方法則是來自於政府與產業界。

CMMI-ACQ草案初稿乃是植基於CMMI的核心流程領域(亦即,涵蓋專案管理、組織與支援過程領域的16個過程領域)、CMMI-AM、以及早期SA-CMM所建構而成。這份報告也融入了多個想把為開發活動(Development)所制訂之CMMI-DEV(已於8月25日正式發行是CMMI v1.2版),調適於籌獲組織的獲取組織的意圖。

CMMI-ACQ在為籌獲取者或籌獲專業領域(acquisition discipline)的CMMI框架應用提供指導。這些執行方法主要在於供應者選擇、供應者協議的起草、簽訂的必要活動,以及透過一組標準的量度、驗收準則及供應者交付項目,來管理產品與服務的籌獲。CMMI-ACQ草案初稿整合了對於籌獲者來說至為重要的知識體系,透過這些知識體系的整合,使得本報告可以為籌獲者,在與供應者一起發展及維護產品與服務時,提供周延的解決方案。CMMI-DEV可以視為供應者在獲取提案範圍內,執行系統工程、軟體發展、及硬體設計工作時的一項參考。

CMMI-ACQ共有22個流程領域與CMMI架構一樣採一個模式兩種表述型態呈現,於階段式表述,所有的流程領域仍然分配到ML2至ML5。ML2有8個流程領域(需求管理、專案規劃、專案監控、流程與產品品質保證、度量與分析、建構管理、籌獲管理及招標與供應商管理),ML3有10個流程領域(組織流程專注、組織流程定義、組織訓練、整合專案管理、風險管理、決策分析與解決方案、籌獲技術解決方案、籌獲需求發展、籌獲驗證及籌獲確認),ML4有2個流程領域(組織流程績效及量化專案管理),ML5有2個流程領域(組織創新與推展及原因分析與解決方案)。於連續式表述,則不同於CMMI-AM將16個核心流程領域分為流程管理(組織流程專注、組織流程定義、組織訓練、組織流程績效及組織創新與推展)、專案管理(需求管理、專案規劃、專案監控、整合專案管理、風險管理及量化專案管理)與支援(流程與產品品質保證、建構管理、度量與分析、決策分析與解決方案及原因分析與解決方案)三個類別(Categories),另外個4非核心流程領域(籌獲技術解決方案、籌獲需求發展、籌獲驗證及籌獲確認)以及2個籌獲獨特流程領域(籌獲管理及招標與供應商管理)則納入籌獲此類別,如表二所示:

表二、CMMI-ACQ模式兩種表述

結論

不論是政府機關或民間企業,為集中資源專注於核心活動以創造競爭優勢,將資訊軟體委外開發已是一股不可遏止的潮流。在軟體籌獲組織為提高委外軟體品質而要求軟體發展組織的資格評鑑或管理能力認證之餘,卻往往因本身的籌獲流程相對不成熟,或缺乏標準的作業程序,而無法做好籌獲管理、招標與供應商管理等重要工作項目,進而影響軟體委外專案的成功或軟體的品質、成本與時程。CMMI-DEV為CMMI V1.2版已於8月25日正式發行,在新版中原先CMMIv1.1版之委外作業(Supplier Sourcing)此專業領域已隨著整合供應商管理流程領域融入於供應商協議管理流程領域後而移除,CMMI-ACQ未來將為組織提供委外作業一個持續的軟體籌獲流程改善指引。CMMI-ACQ預計於2007年3月正式發行,屆時籌獲組織亦可藉由CMMI SCAMPI Class A正式評鑑,呈現出組織籌獲流程成熟度。

(本文作者為德明技術學院資訊管理系副教授)

top
 
軟體發展生命週期模式與 ETVX介紹

軟體發展生命週期模式與 ETVX介紹

■黃叔敏

軟體發展生命週期模式

軟體專案規劃的初步除了需要了解專案的範圍、大小,還需要決定與敘述整個軟體開發的流程,即是所謂「軟體發展的生命週期模式 ( Software Development Life Cycle Model ; SDLC )」。一般而言,軟體發展的生命週期模式就是訂定專案的軟體發展製程,將整個專案發展過程的所有工作項目列出,並以階段( Stage/ Phase )及程序方式展開,其目的是讓專案所有相關人員對整個發展有共識,同時了解專案執行步驟及重要里程碑。

以目前軟體發展模式而言,大致有瀑布模式( Waterfall Model )、雛型發展模式 ( Prototyping Model )、螺旋型模式 ( Spiral Model )、RUP 模式 ( Rational Unified Model )、軟體維護模式 ( SW Maintenance Model )等。以下圖一為例,說明瀑布模式 ( Waterfall Model ) :

《圖一》瀑布模式

一個完整的軟體發展生命週期模式通常需要包含下述要件:1.定義每個階段所需要完成的工作項目 ( Task )。2.定義工作項目執行的順序。3.訂定能被評估的里程碑及交付的工作產品。4.以流程圖方式展示軟體發展生命週期模式。

ETVX ( Entry / Task / Verification / eXit ) 模式介紹

至於軟體發展生命週期模式與其相對應要件的描述方式,IBM公司於80年代提出一個結構化的描述架構-ETVX ( Entry / Task / Verification / eXit ) 模式來敘述整個軟體發展的生命週期模式與每個階段相對應的作業活動,讓研讀的人員能夠非常清楚整個專案的軟體發展架構。

ETVX 架構圖如下圖二所示:

《圖二》ETVX 架構圖

1.輸入(Inputs):代表此階段可能的輸入項目。例如:需求規格、合約、RFP等。2.允入準則(Entry or Entry Criteria):本階段作業啟動必需滿足的必要條件。例如:核准的合約、主管核准的RFP、審查通過的規格等。3.工作項目(Task):本階段需要執行或完成的作業事項。例如:規劃工作清單 SOW ( Statement Of Work )、規劃需求規格書、準備建議書等。4.驗證(Validation):工作項目完成後的驗證方式。例如:文件的審查、合約的審查、軟體的測試等。5.允出準則(Exit or Exit Criteria):此階段作業完成所必需滿足的必要條件。例如:合約簽約與納管、規格書審查通過與發行、軟體測試通過與發行等。6.輸出(Outputs):代表此階段可能的輸出項目。例如:合約書、建議書、規格書、報告等。ETVX 模式可以說是以品質為基礎的角度來建立作業的模式,它將計劃-執行-檢查-矯正 ( Plan - Do -Check -Action ) 品質的理念植入在作業活動中。

瀑布模式的 ETVX

茲以下述軟體發展的生命週期模式為例,敘述每個階段作業活動的 ETVX:

《圖三》

《圖四》瀑布模式的執行流程及其 ETVX

1.專案初始階段(Project initiation Phase)-建議書與合約階段

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
建議書
1.客戶的RFP經主管同意,或2.客戶的投標要求經主管同意準備建議書建議書審查建議書經主管簽核
合約
1.建議書被客戶接受,或2.議價完成準備合約書合約書審查合約書經主管簽核

2.專案規劃階段(Project Planning Phase)

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
專案規劃
1.客戶與我方簽訂合作意願書,或2.合約簽約完成1.專案估算2.準備專案計畫書3.召開專案啟動會議(Kick-Off Meeting)專案計畫書審查1.專案計畫書經主管簽核2.專案啟動會議記錄經主管簽核

3.需求分析階段(Requirement Phase/System Analysis)

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
需求分析
1.客戶的RFP2.合作意願書或合約簽約完成3.客戶接受的建議書4.主管簽核的專案計畫書1.需求訪談2.準備需求規格書(SRS)1.需求規格書審查2.需求規格書客戶確認1.需求規格書經相關主管簽核2.需求規格書經客戶確認

系統測試規劃

主管簽核或客戶確認需求規格書1.準備系統測試計畫書(System Test Plan) 2.準備系統驗收計畫書(Acceptance Test Plan)3.準備測試案例(Test Case)4.準備需求追朔表 (Requirement Traceability Matrix )1.系統測試計畫書審查2.驗收測試計畫書審查與客戶確認3.測試案例審查4.需求追朔表審查1.系統測試計畫書經相關主管簽核2.驗收測試計畫書經相關主管簽核與客戶確認3.測試案例經相關主管簽核4.需求追朔表經相關主管簽核5.里程碑會議完成

4.設計階段(Design Phase)

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
高階系統設計(High Level Design)
1.需求規格書經相關主管簽核與客戶確認2.經相關主管簽核的需求追朔表準備高階系統設計規格書高階系統設計規格書審查

高階系統設計規格書經相關主管簽核

細步設計(Low Level Design)

主管簽核的高階系統設計規格書準備細步設計規格書細步設計規格書審查細步設計規格書經相關主管簽核
整合測試規劃 (Integration Test Planning)
經相關主管簽核的細步設計規格書1.準備整合測試計畫書2.準備整合測試案例整合測試計畫書與整合測試計案例審查整合測試計畫書與整合測試計案例經相關主管簽核
單元測試規劃 (Unit Test Planning)
經相關主管簽核的細步設計規格書1.準備單元測試計畫書2.準備單元測試案例3.修訂需求追朔表1.單元測試計畫書與單元測試計案例審查2.修訂的需求追朔表審查1.單元測試計畫書與單元測試計案例經相關主管簽核2.修訂的需求追朔表經相關主管簽核3.里程碑會議完成

5.程式撰寫階段(Coding Phase)

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
程式撰寫
1.經相關主管簽核的細步設計規格書2.經相關主管簽核的需求追朔表3.程式撰寫標準1.撰寫程式2.修訂需求追朔表1.程式審查2.修訂的需求追朔表審查1.程式經相關主管簽核納管2.修訂的需求追朔表經相關主管簽核3.里程碑會議完成

6.測試階段(Testing Phase)

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
單元測試
1.經主管簽核的程式2.經主管簽核的單元測試計畫與單元測試案例3.經主管簽核的需求追朔表1.準備單元測試程序與環境2.準備單元測試資料3.執行單元測試與記錄4.準備準備單元測試報告1.審查單元測試程序、環境與資料2.審查單元測試記錄與報告單元測試報告經相關主管簽核
軟體構建(Build)
1.經主管簽核的程式2.經主管簽核的單元測試報告1.準備軟體構建程序與環境2.準備軟體構建清單(Build List)3.執行軟體構建審查軟體構建記錄(Build Log)軟體構建記錄與程式經相關主管簽核
整合測試
1.經主管簽核的軟體構建程式2.經主管簽核的整合測試計畫與整合測試案例1.準備整合測試程序與環境2.準備整合測試資料3.執行整合測試與記錄4.準備整合測試報告1.審查整合測試程序、環境與資料2.審查整合測試記錄與報告整合測試報告經相關主管簽核
系統測試
1.經主管簽核的軟體構建程式2.經主管簽核的系統測試計畫與系統測試案例1.準備系統測試程序與環境2.準備系統測試資料3.執行系統測試與記錄4.準備系統測試報告1.審查系統測試程序、環境與資料2.審查系統測試記錄與報告1.系統測試報告經相關主管簽核2.里程碑會議完成

7.交貨與驗收階段(Release & Acceptance Phase)

作業活動/ Activity
允入準則/ Entry
工作項目/ Task
驗證/ Validation
允出準則/Exit
交貨
1.經主管簽核最終軟體程式2.核准的交貨需求1.準備交貨清單2.準備交貨項目與軟體(Packing) 交貨清單、交貨項目與軟體審查交貨清單、交貨項目與軟體經相關主管簽核
驗收測試
1.經主管簽核的交貨項目與軟體2.經主管簽核與客戶確認的驗收測試計畫與測試案例3.經主管簽核與客戶確認的需求規格書1.準備驗收測試程序與環境2.準備驗收測試資料3.執行驗收測試與記錄4.準備驗收測試報告1.驗收測試報告審查2.驗收測試報告客戶確認1.測試報告經客戶確認簽署2.系統上線完成3.交貨清單經客戶確認簽署
專案終結1.經客戶確認簽署的測試報告2.經客戶確認簽署的交貨清單1.準備專案結案報告2.召開專案結案惠議專案結案報告審查1.專案結案報告經主管簽核2.專案發展資料與工作產品備份納管

top
 
CMMI V&V---淺談電子商務網站的性能測試

CMMI V&V---淺談電子商務網站的性能測試

■張文貴

前言

也許您可能會不相信,根據美國札那研究公司(Zona Research, zonaresearch.com)在1999年所做的調查報告顯示,電子商務網站(e-commerce web site)因為負載時間(load time)過長,每個月竟有美金三億六千兩百萬元(約合新台幣1,000億元)的營運損失!受影響最多的業務為安全交易部分,其次是旅遊服務與書籍出版。儘管網際網路(Internet)頻寬與網站服務主機的容量近年來大幅提升,網站性能(web-site performance)的問題卻仍繼續挑戰開發者和測試者,尤其是網站應用軟體的複雜度,結合了網路動態的特性,更造成網站性能的衰退現象,而使性能問題在您的網站和客戶端之間的任何路線上隨時可能會發生;雖然這些性能問題是由許多現象造成,但是其中有很多原始事件是可以預測並加以防止的,例如根據歷史資料發現,您的網站在假日時流量暴增,將是一項很重要的警訊。此外,也許每年3月31日繳所得稅最終期限的前幾天會把成千上萬個訪客送到您的網站,或者紐約證券交易所的交易鈴聲響起,也可能代表您的網站正要開始擁進大量的流量,甚至是您的網站上線人數已經超過了伺服器主機的最大容量值等等。一般而言,影響網站性能的因素有很多,即使是可預測的原因事件也會一大串;但是,一個好的網站管理者必需設法避免這些問題發生,尤其要特別注意防止那些可以預測的原因事件的出現。因此,本文將從客戶端的服務需求面切入,羅列若干常見的性能測試種類,探討執行測試的時機,並簡單說明如何做好電子商務網站的性能測試。

性能測試的重點

首先在進行網站性能測試之前,我們應該要先界定性能通過、或失敗的準則標準,以評估我們要測試的目的是否已經達到。很遺憾地,測試開始時測試員常常不清楚到底要測試什麼項目;換句話說,測試者首先要瞭解測試需求目的是什麼,才能決定所要量測的項目與範圍,也才能確定標的網站的性能是否通過、或不通過既定的測試程序。此外,有了這些需求基礎後,也讓您在評估或購買測試工具、甚至尋求外包服務時,較能做出智慧的決策,因為除非我們充分瞭解所要達到的測試目的,否則無法確定所要用的測試工具到底應具有什麼樣的功能特性。為節省篇幅,常見的測試重點項目簡單整理列表如下,以供參考。

重點
說明
最大負載量
在現有硬體設備下,調適網站各個元件,以支援最大的負載。
下載速率
確定95%的非編碼網頁可以在10秒之內下載完成(編碼網頁在15秒內)。
平均反應時間
決定平均反應時間。
正常性能指數
在現有的網站架構及可接受的性能下,決定最多使用者連接數目、每個小時的session initiations、每秒的交易量。
加壓性能指數
在現有的網站架構及在失效前仍能正常運作狀況下,決定最多使用者連接數目、每個小時的session initiations、每秒的交易量。
網站頻寬
在網站可以承受的每秒最大交易量下,決定網站頻寬。
超負載能力
決定網站超過最大負載時的處理能力。
下載極端值
找出下載時間最慢(5%)與最快(5%)的網頁。

《表一》性能測試之重點項目

反應時間的需求

一般來說,網站訪客對於某一網頁的反應時間(response time),若等待超過10秒鐘,便會變得沒有耐心而極可能會重新按下其他按鍵,可惜的是除非像文件說明式網站(brochureware web site),一般交易式網站(transactional web site)若遇到任意重送、或取消目前的交易,都可能使這類網站產生重大的問題,例如資料庫可能造成毀損,因而失去一些訂單、或無法獲得正確的訂單數量等等。因此,除了文件說明式網站之外,將大部分交易式網站的最大反應時間規定為10秒,應是一項相當重要的關鍵點,表二明列了三級反應時間的一般需求。

反應時間
說明
少於0.1秒
訪客感覺到網站能夠即時反應的界線,在這個極短的時間內,除了結果顯示外,並不需要再安排其它的回饋訊息;按鈕或拖曳動作的反應即屬此類。
少於1秒
訪客的思維能持續不被中斷的界線,雖然訪客會察覺到短暫的遲延,給使用者有失去直接操作資料的感覺,但一般遲延時間在一秒鐘內也不需任何的回饋機制;網頁瀏覽的啟動或Java applet的執行即屬此類。
少於10秒
吸引訪客繼續瀏覽的最大界線;完整的網頁瀏覽即屬此類。
  ※資料來源:Jakob Nielson's, Designing Web Usability, New Riders        Publishing, 2000.

《表二》反應時間的一般需求

除了上述的反應時間外,如果出現更久的延遲時間,使用者通常會在等待網站回應的這段時間中,同時處理其他工作;因此在這種狀況下,伺服器應該要提供使用者回饋的訊息,例如還要等多久才能完成使用者的需求,尤其是當反應時間的長短可能因人而異時,回饋的機制更為重要,因為如此一來,使用者知道他可期待什麼、要期待多久。但是,很不幸地,大部分的網站瀏覽器並沒有設置進度棒(progressive bar),或提供整個網頁下載時間的百分比,讓使用者處在非常不確定之操作環境中,這樣的伺服器顯然效果會很差。

另外,從使用度(usability)的觀點來看,確認一個網站中不同網頁下載時間的長短接近一致是很重要的,如此可讓網站使用者較有一致的時間感;當然一個網站管理者並不會因為某一個網頁下載太快而去做調整,使該網頁下載的時間延緩一點,但是某些反應太快的網頁的確可以考慮重新設計整個架構,例如將下載較慢網頁的部分工作項目移到較快的網頁上,舉例說,我們可以將反應較快的網頁先下載目前暫不需要的圖片,然後其它較慢的網頁便可從瀏覽器的快取記憶體(cache)快速抓到所需要的圖片,以平衡網頁的下載時間。

表三列出一些大眾化網站的反應時間,假設網路的傳輸速率為56.6 Kbps。

網站
反應時間(秒)
可用率(availability, % of uptime)
amazon.com
23.88
97.2
bamesandnoble.com
16.78
96.8
cdnow.com
18.67
87.2
ebay.com
17.28
96.1
etoys.com
18.67
93.2
gateway.com
18.37
96.2
landsend.com
17.60
97.9
macys.com
35.41
92.6
wal-mart.com
22.28
97.7
wine.com
24.52
89.4
平均值
21.36
94.4
※ 資料來源:USA Today December 9, 1999.

《表三》一般網站的反應時間

性能測試的種類

如前面所述,一般性能問題的產生可以分為兩大類:可預測性的與非可預測性的;因此性能測試應該從這兩大方向考量設計,但是實際上我們應怎樣進行性能測試?它所牽涉到的因素太多了,我們應如何真正量測網站的性能?廣義來說,性能測試是用來觀察、並評估一個網站在所有可能的負載下以及經歷各種不同時段的反應情形。通常,網站的性能測試可以再分為:煙霧測試(smoke test)、負載測試(load test)、壓力測試(stress test)、及激盪測試(spike test)或彈跳測試(bounce testing)等四種;分析這些量測的結果,可找出與性能測試的重點目的之關聯性,若發現有任何非我們所預期的狀況,相關的人員就可以適當調整加以改善。以下將分別說明網站的四種測試。

一、煙霧測試事實上,煙霧測試(smoke test)的名稱由來是源自於硬體界的測試術語,因為有些硬體在進行測試時都已開始冒煙。煙霧測試是用來評估一套軟體是否已經建置完成、準備進行測試。簡單的煙霧測試可以利用28.8 Kbps的數據機與碼表執行幾個手動的功能測試,而複雜的煙霧測試則甚至針對整個網站的期望性能,執行一套全自動的負載數據。這種測試的結果主要是作為判斷能否進入大規模性能測試的依據。但是,在執行煙霧測試時,我們必需確定在未來的測試環境中所有將要用到的資源已經存在,尤其是網路頻寬;而且我們更要確定在未來正式執行性能測試時不會影響到其它的使用者,甚至包括網站的發展者,即使也未事先知會他們。附帶一提,有些書的作者喜歡將煙霧測試稱為"穩健測試(sanity test)"、或"瀏覽測試(drive-by test)",其主要的道理就像我們準備要買一棟房子,我們必需先開車在房子四周瀏覽觀察,以決定是否要下車進去深入丈量。二、負載測試負載測試(load test)是用來觀察一個網站在短時間內承受實際負載的預期表現狀況。負載測試的結果可以幫助我們決定目前這種硬體與軟體的搭配組合是否符合性能的需求,這裡所謂的搭配環境主要包括:網站侍服器、應用侍服器、資料庫、網路頻寬等等。基本上,負載測試是用來量度網站在正常狀況下一般使用者的平均反應時間(average response time);若在發展網站的早期實施,負載測試更可以模擬某種特殊架構組合的可行性選擇,協助我們決定是否購買昂貴的硬體設備、或是投資大量資金於軟體網站的開發,因此它是一項成本效益很高的測試策略。下表是一般網站的負載測試檢核表。

通過
不通過
說明
使用28.8 Kbps數據機從任何地方連線,95%的網頁能在10秒之內下載完成。
在股票交易時間內,報價不會超過20分鐘。
訂單能在顧客提出後2分鐘之內完成。
完成交易之確認訊息能在30秒之內送出。

《表四》網站在正常狀況下的負載測試檢核表

三、壓力測試壓力測試(stress test)是用來決定我們目前硬體與軟體的組合搭配,是否在操作顛峰時段內仍有能力處理大量的交易;此外,壓力測試亦可用來觀察當我們的網站達到最大的能力極限時會發生什麼狀況?在進行壓力測試時通常會有兩個主要的目標:第一、找出系統何時以及哪裡會出狀況,第二、分析系統在出狀況後將會如何。舉例來說,假設我們的網站資源只能提供100位使用者同時連線,那麼當第101個使用者連到該網站時會發生什麼樣的結果?網站將要採取什麼樣的動作?例如:立即關掉伺服器、伺服器傳送"server not available"的訊號給第101位使用者、或是讓這第101位使用者進入伺服器的等待線排隊,一旦有其他使用者離線,立即服務這位第101位使用者。理論上,當使用者愈來愈多時,一個網站的性能應如預期的逐漸衰退,而不是突然陡降;因此一旦我們的網站超越它的能力極限時,我們應很清楚我們的網站將要如何因應。另一方面,當一個網站逐漸加壓時,雖然目的是在確保原先已能成功運作的那些功能仍能正確地運作,但我們更應注重網站所有功能的完整性(functional integrity)。例如:某一個網站能提供某一支股票的獲利百分比,但當該網站被加壓時,我們應確保該網站仍能正確地計算各種股票的獲利百分比!更進一步說,資料的完整性(data integrity)是任何一個交易性網站非常重要的特性之一。當超過負載能力時,網站將會發生什麼樣的情況實在很難說,而且它的影響會隨所處的環境而異,有可能是輕微的也有可能是災難性的,因此重要的是我們應該隨時掌握資料的完整性;壓力測試正可以協助我們防止一些潛在的災難性危險情況,尤其是當我們透過負載平衡主機(load balancer)或資料複製侍服器(data replication server)來改善網站的性能時,實施壓力測試常能找到一些無法預期的瑕疵,在這種情況下,執行壓力測試的測試案例就必需包含可能會發生的所有衝突現象,而網站管理者也需瞭解如果某種衝突一旦發生,要採取什麼樣的動作解決。基本上,壓力測試所用的交易通常都包含需要大量計算、或較為重要的資料處理工作,設法達到較有效率地顯示網站資源耗用之表徵。更確切地說,測試案例需包含有關資料庫系統的增加、修改、刪除等作業,以對資料庫網站施加輸入、輸出及例行性服務項目等方面的壓力。而另一方面,實施壓力測試的最好時機是在網站系統接近顛峰負載時,通常是當大量的使用者同時嘗試連到網站時,便可以執行壓力測試開始觀察網站系統的式微情形;以一個美國股市行情即時網站為例,網站的尖峰時刻通常是在早上9:30到10:15以及下午3:30到4:00,這段時間剛好是配合紐約股市開盤及收盤的時間。以下兩個表說明執行壓力測試的可能重點以及若干測試案例,不過,在這裡要特別強調的是,我們無法設計出一套通用的壓力測試之測試案例,因為測試案例大大取決於每一個網站的架構特性,以及我們對於網站反應的接受度;因此表六中有些測試案例並不適合每一個網站的狀況,它只是在具體說明測試案例的樣式而已,請讀者千萬不要照表套用。

最大值
說明
決定網站能支援的每秒最大交易量
決定網站能支援的每小時最大session initiations
決定網站能支援的最多同時連線人數

《表五》實施壓力測試的可能重點

通過
不通過
說明
網站系統到達80%的能量時
通知新的連線使用者"請重新連線"的訊息,直到系統恢復正常為止。
發出警告訊息給不活動的使用者(inactive user),說明將從系統中移除、除非系統恢復正常否則將無法再簽入。
關閉非關鍵性的服務(如圖表繪製),以服務其他更重要的選項。
透過e-mail發送潛伏危機的訊息給網站管理人員。
網站系統到達90%的能量時
剔除不活動的使用者。
啟動備份網站的作業。
透過e-mail再發送潛伏危機的訊息給網站管理人員。
網站系統到達100%的能量時
系統不能再啟動任何新的交易。
系統不能自行重新開機。
系統不能關掉安全性的工作項目。
系統不能暫停任何交易的登錄動作。
系統不能陷入癱瘓。
硬體元件不能燒毀。
透過e-mail發送緊急系統危機的訊息給網站管理人員。
網站系統在任何能量時
系統應保持功能的完整性。

《表六》實施壓力測試的可能測試案例

四、激盪測試就作用而言,激盪測試(spike test)類似預測網站在什麼時候會遭遇像暴風雨之類的大災難,當然我們在乎的是:這種預測是否正確?什麼時候會發生?從那裡發生?災難有多嚴重?的確,網站會遭遇像暴風雨之類的襲擊,而且傷害的程度也會因不同網站系統的架構環境而有所差異,因此我們更要進行激盪測試,找出網站性能的盲點,及早改善。因為電子商務網站是建構在網際網路的大環境中,因此任何預期性的、與非預期性的事件都可能發生,像是假日時段、頭號電腦病毒、特殊的號外新聞、及有關產品優惠的消息都有可能成為激盪事件,接下來我們唯一比較關切的問題是:這些激盪事件什麼時候會危害到我們的網站?災難強度有多少?有時候,激盪測試也被稱為超負載測試(overload test)、浸蝕測試(soak test)或浪濤測試(surge test)。另一種激盪測試的變化就是彈跳測試(bounce testing),它主要將前述激盪負載之大小稍作調整,在適當範圍內上下彈跳,以觀察某一網站是否能適應負載的變化、以及是否能自行控制資源的運用,需要資源時能提出要求,而不用時則能立即釋放出來,達到資源運用的最佳效益。因此,彈跳測試也叫做彈性測試(elasticity test)。通常激盪測試的執行,是由超出正常平均值的大量隨機需求所驅動的,甚至讓一個網站在非常短之時間內經歷異乎尋常的負載成長,進行這樣測試的道理,是基於一種事實:即使一個網站能適應負載的逐漸增強變化,但是突襲性的激盪事件仍有可能引起相當嚴重的問題。舉例來說,一個樂透網站通常會在使用者下注後經歷一波浪濤洶湧而至,雖然有些網站無法處理這種浪濤式的負載,會造成網站當機;因此,如果我們能預估某些激盪事件,則我們可以針對這些事件腳本先設計一些測試案例,再透過激盪測試來檢查分析網站的調適能力。以前述的美國股市行情即時網站為例,經過歷史資料分析發現:最有可能發生激盪事件的時機是在紐約股市剛開盤、或是將要收盤時。為具體說明激盪測試的執行,表七列出了若干測試案例,以供參考。

通過
不通過
說明
在激盪現象發生前簽入的使用者不能被刪除。
在激盪現象發生前啟動的交易需繼續執行,不受激盪現象之影響。
新的使用者仍允許簽入,不受激盪現象之影響。
在激盪現象下系統安全性的服務項目仍然有效。

《表七》實施激盪測試時的可能測試案例

執行測試的時機

講完了性能測試的重點與種類,接下來談什麼時候應該開始執行網站的性能測試?應在網站發展週期的開始?最後?或在中間?一個不爭的事實是:愈晚開始進行性能測試,將來花費在解決問題的成本就愈高,如圖一所示。因此,從一個純粹財務的觀點來看,性能測試應該在發展階段愈早開始愈好;但是這並不代表,愈早進行測試就保證將來比較沒有性能問題,事實上,它只是代表這樣所需的經費不會像在發展後期才找到錯誤所耗費的那麼多。

《圖一》網站的性能改善成本與發展週期的關係

根據Newport Group最近針對美國117個公司進行問卷調查,這些公司年收入至少兩億美元,調查報告顯示:在那些網站功能符合預期目標的公司中,有94%的公司是在產品上市前即已執行過性能測試;然而,在那些產品上市前未執行性能測試的公司中,卻發現高達90%的公司網站應用沒有達到預期目標。換句話說,如果網站產品在未上市前沒有通過性能測試,將來會出現問題的可能性將會大幅提昇。綜合而言,性能測試的執行時機愈早愈好,但是如何決定則牽涉許多因素;簡單地說,執行性能測試的最好開始時間通常取決於公司組織機構、網站發展過程和所發展的網站應用形態,比如說,我們可以在應用軟體程式尚未完成之前,就先對網站架構進行負載測試。

結語近年來,電子商務網站的大量普及,使得網站的性能測試益顯重要。本文從開發網站的性能重點出發,說明網頁反應時間的長短是評估網站性能的一項重要指標,尤其是針對交易式網站的設置,將最大反應時間規定為10秒,是一項相當實際的經驗準則;此外,若反應時間可能更長,網站瀏覽器則應設置進度棒,或提供整個網頁下載時間的百分比,讓使用者瞭解目前下載進度,增進網站操作透明度。電子商務網站的性能測試是用來評估、分析一個商務網站在不同負載與時段下所呈現的各種反應情形。性能測試一般又可分為:煙霧測試、負載測試、壓力測試、及激盪測試或彈跳測試等四種,每一種測試均有其特定目的與適用環境;最後文中提到,雖然性能測試的執行時機愈早愈好,但是,最好的開始測試時間通常取決於公司組織機構、網站發展過程和所發展的網站應用形態。實際上,影響電子商務網站性能的因素還有很多,例如:使用者操作檔案、使用者風格、使用者偏好、背景噪音等,在執行商務網站性能測試時,如何考慮這些因素的影響層面,也是很重要的課題之一,只要筆者有閒,以後將陸續撰文說明之。主要參考資料一、張文貴,因應e時代的網路環境--如何做好網站測試外包,品質月刊, 4月2001, 31-35.二、Steve Splain, Web Testing Handbook, STQE publishing, 2001, 207-220.三、Ian Sommerville, Software Engineering, 6th ed., Addison-Wesley, 2001.

(本文作者任教於東海大學資訊系,目前為中華民國品質學會-軟體品質委員會主任委員)

top
 
論文件資料與建構項目管理規劃

論文件資料與建構項目管理規劃

■ 黃叔敏

前言

軟體專案在執行過程中會產生很多文件資料,如會議記錄、軟體程式碼等,這些資料如果沒有事先規劃一套管控方法,往往會發生在需要資料時找不到所需文件資料、或使用錯誤文件資料或者交付客戶錯誤的文件資料與軟體版本等窘境,並且一再重複發生,這不僅會直接影響專案執行的效率與品質,還會嚴重打擊專案團隊人員士氣,甚至成為造成專案失敗的主凶。

因此針對專案過程所產生的種種工作產品(文件、資料、記錄、軟體等)之管理,專案經理需在專案啟動時即事先規劃,在既不要太影響人員放置與取用方便性,又不能太鬆散管理以致造成無法管控問題之間謹慎拿捏,針對不同的工作產品可以使用不同層級的管控方式,如此讓每個專案成員有一套規範可循,除了降低失誤與重工( Re-Work ) 機率,同時可以提昇專案執行效率與品質。

目前有很多相關資訊與報告談論此方面議題,然而這些文件大都是從複雜的建構管理 ( Configuration Management ) 角度來討論,並以一個很大的軟體架構格式來談論建構管理。但現實狀況是大部份的資訊專案都是中小型專案,專案成員人數也大都是10人以下,即使整個資訊部門組織也往往都是小於30人的單位,這些建構管理的方案並不合適他們使用,因此這些中小型組織裡專案所產生的文件資料管理,往往讓中小型組織的主管們非常困擾、不知如何著手中小型組織的文件資料與建構項目管理。

本文的目的是從基本文件管理觀念討論,再提出相關管理方式,希望以比較簡單有效的方法讓中小型組織與專案可以很容易建立文件管理與建構管理相關流程制度與機制,開始執行軟體專案發展過程中最基本的作業。

文件資料管理的基本觀念

文件、記錄與程式碼等資料管理的目的,就是期望在當需要這些資料時,能夠知道"在那裡"可以取得"正確的"資料,並能"確實"取得該資料。

然而專案執行過程中產生的資料相當多,要如何達到上述目的,則需從專案所產生資料的類別及資料本身屬性著手才能真正歸納出簡單與可行的方法。

建議從下述思考步驟來處理:1.專案執行過程中,有那些資料是需要管理的。2.分析需要管理資料的屬性。3.針對資料類別與屬性規劃管理。

一、專案執行過程中,那些資料需要管理?

需要管理的資料可以從兩個角度來思考:

1.對客戶承諾有關的資料

專案執行目的是在完成對客戶(內部與外部)的承諾,因此與完成客戶承諾有關的相關資料一定要納入管理;包含:

A.文件類:客戶的RFP(Request for Proposal)與我方提出的建議書(Proposal)、遞交給客戶的文件與報告、客戶提供的文件或資料等。B.記錄類:客戶的需求訪談記錄、文件的確認記錄、需求變更相關要求的提出與記錄、與客戶的會議記錄、與客戶互動或溝通討論的重要文件記錄、客戶簽收的記錄。C.其它:與客戶往來的郵件(Email)、MSN等。

這些資料基本上是紙本文件資料與電子式文件資料(含:電子郵件/Mail、MSN ),其中特別是與客戶往來的重要電子郵件一定要存檔納管,以便將來有需要時能夠查證。

2.專案發展過程中產生的工作產品專案執行過程中產出的資料以類別而言包含如下幾項:A.文件類:專案各種計畫書、規格書、建議書、使用手冊、訓練教材、簡報、合約、報告等。B.記錄類:會議記錄、審查記錄、稽核記錄、測試記錄、訪談記錄、上課記錄、採購記錄、交貨清單/簽收記錄、驗收記錄等。C.軟體:程式原始碼、Object Code、Demo System、Prototype的程式等。D.其它:與外部討論的Mail、MSN存檔記錄、多媒體資料等。

二、分析需要管理資料的屬性

針對上述所提需要管理的資料,在一個專案過程中往往就會產出上百至上千筆資料,如何讓管理與取用上能夠作到簡單又有效率,是一件工程。作法是先將上述分類的資料,分析每一種資料在使用上(型態/存放/取用)的特性(屬性),以便針對資料在使用上的特性不同,訂定各別管理規範,因為如果只用一種管理規範來管控所有屬性的資料,則將會讓很多資料在管理上的成本大幅增加,並且造成使用上相當大的不方便。這如同一個企業需要對於不同屬性的員工(業務/製造/研發)有不同管理方式一樣,才會產生管理效益與提昇作業效率。工程專案的資料通常有個非常重要的特性(屬性)就是:資料的變動性。因此資料可以區分為"非變動性資料"與"變動性資料"兩種。

1.非變動性資料:就是資料經納入管理後不會再取出變動其內容的資料,主要是記錄類文件資料與報告,包含Mail/記錄/報告/單據等。2.變動性資料: 即資料經納入管理後,可能會再次取出變動其內容後,再納入管理的資料,而且其名稱相同不變。主要是專案發展有關的計畫書、技術性文件、軟體程式、手冊與訓練教材等,這就是一般所謂的"建構項目(Configuration Item)"。這些變動性的資料在軟體發展過程中,又可依其變動次數的頻繁性,分為變動"頻率低"的資料(如:計畫書、規格書等文件)與變動"頻率高"的資料(如:軟體程式式碼),針對各種變動性類別資料的管理,可以有幾種不同的方式來管控它。

三、針對資料類別與屬性規劃管理

要達到需要這些資料時知道"在那裡"可以取得"正確的"資料,並能"確實"取得該資料,需事先規劃與建制一套資料管控的方法,並依循執行,基本上就是建立文件資料與建構項目的管控機制、規範文件資料與建構項目作業的環境與管理的遊戲規則。

實務上的作法是撰寫文件資料與建構項目的管理計畫書,在計畫書中明確敘述與說明相關作業程序與規範,通常組織可以建制一個共通性文件資料與建構項目的管理計畫書,讓組織活動與專案活動共同依循,如因客戶要求或作業屬性特殊,於執行時需要調整的狀況發生,則再由專案經理於專案啟動時特別提出變更與核准申請即可。

文件資料與建構項目管理計畫書內容概述

一、納管範圍 SCOPE

主要是明列所需納管的文件/資料/軟體等項目,將其依"建構項目"與"非建構項目"分別明列,並規範這些項目納管的時機。

二、文件資料與建構項目命名原則Naming Convention(Naming Rule)

主要是明述納管的文件/資料/軟體項目其命名原則與編碼原則,所謂命名原則就是規範 "檔案名稱"的命名方式;檔案名稱命名目的是要讓取用者可以很方便且直接的從檔案名稱上立刻辨識取用的文件資料為原則。

一般文件資料的命名原則為"專案代號/名稱"+"文件名稱"+版號或日期。例如: 專案管理計畫書:ABC專案-PMP-V01;專案管理計畫書審查記錄:ABC專案-PMP審查記錄表-20070630

至於檔案編碼的目的是為方便管理文件資料人員的管理,給每一份文件一個身份證號碼,因此需要有一套編碼遊戲規則。例如:"報告"的編碼:(1)(2)(3)(4)-(5)(6)(7)-(8)(9)(10)(11)-(12)(13)-(14)(15)碼(1)(2)(3)(4):專案代碼碼(5)(6)(7):報告性質代碼碼(8)(9)(10)(11):報告之年份碼(12)(13):報告之月份碼(14)(15):流水號

三、建構管理環境/工具

主要是明述所使用的建構管理工具(如:VSS、PVCS、CVS)及其版本、HW & OS 的作業環境與設備資源需求。

四、文件與軟體版本規範 VERSION CONTROL

主要是針對建構項目中的文件版本/版號之使用規範作明確序述說明。通常建構項目之版本別應規範起始編號、Major和Minor更新之編號原則。例如:版本/版號通常為 X.YZ

X:代表文件或軟體"重大的更新"/Major Release 文件類:章節內容重大的更動或修訂,如:需求功能重大變動。 軟體類:軟體架構更新或功能大幅度增加等。Y:代表文件或軟體"部份的更新"/Minor Release 文件類:章節內容部份更動或修訂,如:需求功能內容調整,但範圍項目    不變。 軟體類:軟體部份功能增加或調整,修訂幅度小。Z:代表文件或軟體"內容錯誤的修訂"/Error correct Release 文件類:章節內容錯誤修訂。 軟體類:程式 Bug Fixed。

一般而言,初稿版以 0.yz (0.1/0.2 ...)標示,第一份正式版本(第一次基準/Baseline 版本)才開始以1.00為版號。

五、目錄架構DIRECTORY STRUCTURE

目錄架構的目的是規定一套共通標準目錄結構名稱及每個目錄要存放的文件資料類別,讓組織成員都知道"在那裡"可以取得所需要文件資料。包含:

1."資料儲存位置":指定特定儲存設備( File Server )與路徑。2."儲存的館別(Libraries)":基準館(Baseline)、發行館(Release)、工作區(Working Area)。3.每個館的"檔案目錄架構"(Director Structure/Folder Structure):建立各別"目錄名稱"。

通常依資料產生過程的生命週期屬性分成:工作區(Working Area)基準館(Baseline)與發行館 (Release),用以區別與方便管控。

1.工作區:基本上為專案人員在作業時將過程中的資料暫時儲存的位置,通常不納入建構管理/CM管控範圍,此區域由專案經理或專案成員自行負責規劃與管理,組織通常不規範此區域的目錄名稱與存放管控,全由專案經理負責。

2.基準館:是專案工作產品(建構項目為主)經審查通過,可以為作下一階段作業的基準文件或軟體,儲存於此區域,即為正式納入建構管理/CM管控範圍,組織需要訂定標準的目錄名稱與存放管控程序。

3.發行館:是專案工作產品正式發行,特別是針對建構項目,一般將完成的記錄/報告等文件 歸放在此區,儲存於此區域亦為正式納入建構管理/CM 管控範圍,組織需要訂定標準的目錄名稱與存放管控程序。

例如 :

例如:專案發行館:路徑 Release_Library\專案\(Project Code )\Record

六、基準與更新基準之準則BASELINE/RE-BASELINE CRITERIA

所謂"基準",就是指專案發展過程的工作產品(建構項目為主)經一定審查確認程序後,可以確認作為下一個發展階段作業的基礎•將此確認後的工作產品訂定為一個正式版本基準。而更新基準之準則就是規範,建構項目建立基準與更新基準的程序要件,通常將文件與軟體分別敘述。例如 :

1.文件類:初稿版→審查通過→簽入CM→建立基準     建構項目簽出→修訂後審查通過→簽入CM→更新基準2.軟體類:新程式→審查通過(Option)→單元測試通過→程式Build成功     →簽入CM→建立基準      程式簽出→修訂後單元測試通過→程式Build成功→簽入CM     →更新基準

七、發行準則RELEASE CRITERIA

由於專案發展過程中每次所建立的基準工作產品不一定是一個完整的完成品,例如:規格書有可能是會分階段完成不同模組(Module)的規格,只要完成該模組規格,建立基準(Baseline),程式人員就可以先行撰寫該模組程式,不需要等全部模組設計完畢,建立基準(Baseline)後再撰寫程式。另一種狀況是可能只是先建立基準給內部使用,並不一定會正式發行給其它外部使用(包含客戶),因此基準的版本不一定都會正式發行( Released)。原則上專案過程中所產生的工作產品,經審查與主管核准後,即可為正式發行的版本。

基準版本的正式發行(Released)程序可為如下述 :基準的版本→稽核通過→主管簽核→正式發行

八、建構管制Configuration Control

主要是規範變動性資料(建構項目)變更的程序,用以管控建構管理項目的進出與變更,基本上需要包含下述三要項 :

1.申請文件 Documentation (變更申請表)"變更申請表"基本上要有變更的主要項目、變更的原因、衝擊分析(Impact Analysis)、變更的相關項目、審核意見等。其中"衝擊分析"需要明述變更可能的影響,包含期程(Schedule)、人力(Effort)、客戶承諾、專案品質、風險等,以利核准主管決策。2.審核變更的主管或組織通常組織可以規範建構項目變更影響嚴重性的等級及其審核的主管與組織。通常可以將變更的等級分類為"一般變更"與"嚴重性變更"兩種等級。組織需要規範"一般的變更"與"嚴重性變更"的準則(Criteria),以利專案經理人判定的基礎。一般變更可由專案主管或專案經理審核,嚴重性的變更則需要召開審核會議,邀請專案相關主管人員與會討論及決策,並事先規範專案相關主管人員名單,這份專案相關主管人員名單就是一般所謂的建構管制委員會( Configuration Control Board;CCB)。3.變更的程序(Procedures)規範變更申請與處理的流程程序,可以參考下述:變更申請提出(變更申請表)→主管審核 核判變更等級與審核 : [一般變更]→審核通過→簽出文件進行變更→審查變更文件→簽入CM     →更新基準[嚴重性變更]→召開變更審核會議→審核通過→簽出文件進行變更      →審查變更文件→簽入CM→更新基準

九、備份與存檔BACKUP AND ARCHIVAL

所存放的檔案資料需要定期備份,以免因意外狀況發生而造成嚴重損失,因此需要規範定期備份的作業,將需要備份的內容項目、備份的方法與方式、備份設備、備份時機/頻率週期、負責人員等明確敘述。其中備份時機/頻率週期可以分成每日備份與每週備份,原則上每週至少需要將全部的資料備份一次,且備份資料最好能儲存在不同的點。

十、存取權限ACCESS RIGHTS

規範專案成員或組織成員對目錄架構中檔案 Read / Write/ Delete 的權限設定。原則上只能有一位成員(建構人員)能有所有權限,其它人員都只能有讀取的權限,以免資料錯亂。當然如果有屬於機密性的文件,亦可另行特別規範,甚至於放在特別的目錄架構中,並規範一定的核准程序才能調閱。

十一、文件資料與建構項目記錄與管理報告 CM RECORDS & CM REPORT 規範建構人員應建立文件資料納管記錄(Record Log),包含: 納管的項目、時間、交付人員;如為建構項目,還需要有該納管建構項目的版本、簽出/簽入與變更申請表號碼。建構人員需於每次建構項目變動時,通知相關人員建構項目的異動狀態,並定期(每月)產生建構管理狀態報告,報告每項建構項目目前基準的版本/發行的版本、變更的狀態、建構變更的次數,用以提供專案與組織經理人瞭解專案與組織建構管理的狀況。

十二、文件管理與建構管理的稽核 CM AUDITING建構人員與專案人員在文件管理與建構管理執行的狀況為何,是否有改善之處,通常需要透過稽核機制瞭解其在文件管理與建構管理程序上依循的程度與需要改善的缺失。建構稽核在執行兩項活動 :

1.驗證 驗證每項建構項目的基準/Baseline版本,是依循前一個基準版本變更的。驗證每項建構項目正確的版本(最新的版本) 是存放在正確的位置(Folder)。2.確認 : 確認每個基準的版本均能反應客戶需求/要求,確保每個基準的完整性。確認每個建構管理項目的內容及其與需求追溯表( RTM;Requirement TraceabilityMatrix )內容的一致性。

由於文件管理與建構管理是專案發展中最重要的基礎作業,不能有所疏失,因此通常是定期(每月一次)的稽核,透過每月的稽核確保文件資料的準確性。

top
 
論軟體專案的風險管理

論軟體專案的風險管理

■ 甄 敏

前言

天有不測風雲,人有旦夕禍福,複雜的軟體專案也時時受到風險的挑戰。風險管理的目標並不是使專案避開可能的風險,而是降低專案遭受風險所受的衝擊。風險管理的做法是於風險發生前指認風險,界定出潛在的問題,在產品或專案的生命週期中規劃風險處理活動,並採取適當行動以降低對專案的不利影響。在專案進行中如果能夠妥善進行風險管理,專案成功的機率就會提高。

Rook(1984) 認為風險管理的目的是在風險對專案運作造成威脅之前,針對風險的來源,建立一個平衡、整合性的策略,並監督控制這些策略的執行。Boehm(1991)則提出如下圖的風險管理架構,成為現在所有討論風險管理的基礎:

《圖一》

風險與風險管理概念

根據委伯(Webster) 字典的定義,風險是造成損失的機率(Possibility of Loss or Injury),風險包含了機率(Probability)與損失(Loss) 兩項變數.對軟體專案而言,風險是那些可能發生的事件或狀況,同時一旦真的發生時會對專案帶來傷害或負面的影響。

風險不可與一些需要管理干預的事件或狀況等議題混淆。舉例來說,在專案測試階段幾乎一定會找到一些缺陷,因此理論上專案經理都會事先計劃一旦找到缺陷時應如何修護。同樣的,我們幾乎也可確定,專案進行時客戶需求會經常變動,因此專案經理必須事前準備與計劃何處理這類正常的事件。

專案的風險與專案的議題間的差異在於:

1.風險是針對未來的事件2.風險的發生及所造成的損失都不確定3.風險一但發生將對專案造成重大或是致命性影響

風險是一種機率事件,它有可能發生,但也有可能不發生。基於這個理由,我們通常會很樂觀的乾脆無視於風險的存在,或者希望它永遠不會發生。但是一但風險發生,造成的損失將無法估計,所以我們寧可選擇在風險發生前就採取風險管理措施。

CMMI模式的軟體專案風險管理

CMMI 整理了系統及軟體開發過程的最佳實務,除了涵蓋Boehm 的風險評估和風險控制外,也強化了風險管理準備的部分。本文即依照CMMI風險管理流程領域來討論風險管理應進行的工作。

一、風險管理準備

CMMI模式對於所有的流程都首重其目標及策略,藉由建立並維護用來界定、分析及降低風險的策略,以執行準備工作。風險管理策略通常記錄於風險管理計畫中。風險管理策略說明用來控制風險管理計畫的特定活動和管理方法。這包括界定風險來源、風險分類的方法,以及用來有效處理評估、限定和控制風險的參數。

確定風險來源和類別

風險來自專案的內部及外部。在專案進行過程中,可能界定其他的風險來源。建立風險類別提供一種機制以蒐集和分類整理風險,並對比較嚴重影響專案目標的風險,保持適當的密切觀察和管理注意。

專案有許多內部及外部的風險來源。風險來源是界定風險可能發生的共同來源,典型的內部及外部風險來源包括下列各項:

• 不確定的需求• 無前例的工作量─無法取得預估值• 不可行的設計• 不存在的技術• 不實際的時程估計值或配置• 不充分的人員配置和技能• 成本或資金議題• 不確定或不充分的分包商能力• 不確定或不充分的供應商能力很多這些風險來源常常未做充分辨識就已發生。越早界定內部和外部的風險來源,即可儘早界定風險,並在專案初期執行風險降低計畫,以排除風險的發生,或降低發生時的嚴重性。

風險類別反映「貯存倉」的概念,用來蒐集和組織風險。界定風險類別的原因之一是它可協助未來整合風險降低計畫的各項活動。

決定風險類別時,可參考CMMI所列的因素如下:• 專案生命週期模式的各階段(如:需求、設計、製造、測試與評估、  交付、汰除) • 使用的流程類型• 使用的產品類型• 計畫管理的風險(如:合約風險、預算/成本風險、時程風險、資源  風險、績效風險、支援能力的風險)

風險管理與經年累積的經驗有直接的關係,往往不是單一專案負責人所能完成,組織可以透過收集歷次專案經驗與發生的問題,或是參考SEI提供的資料,整理出風險來源和類別清單,建立組織的風險資料庫,提供專案負責人參考。專案負責人可以請教其他專案負責人及與專案團隊成員共同討論列出專案風險事項與因應對策,並定期在專案會議中監控與討論,檢查目前已列出的風險事項及其處理與變化狀況,討論是否有新的風險事項需要考量等。

定義風險參數

用來評估、分類和排序風險的參數,包括下列各項:• 風險可能性(即風險發生的機率) • 風險結果(即風險發生的影響和嚴重性) • 驅動管理活動的門檻 風險參數提供共通且一致的準則,用以比較需要管理的各種風險。沒有這些參數,則由風險導致的非預期變更,將很難估計其嚴重程度;在風險降低計畫中,也很難排定必要行動的優先順序。考慮風險管理的成本及及其成效,CMMI建議對每一風險類別,可建立門檻以決定風險的可接受性或不可接受性﹔風險的優先順序,或管理行動的啟動裝置。定義某風險類別門檻的範圍,並未限制以量或質的方式評量。範圍的定義(或範圍的條件),可用來限定風險管理投入程度,以避免資源過度消耗。範圍的訂定,可排除某個類別的風險來源,亦可排除任何發生小於某個頻率的情況。對每個已界定的風險,建立若干個監控點,以更積極的監控風險,或通知執行降低風險計畫。這些數值日後可再調修。

門檻的範例如下: • 專案門檻值:當產品成本超過目標成本10%,或當成本績效指標(CPI)   降到0.95以下時,可與資深管理階層共同研商。• 時程門檻值:當時程績效指標(SPI)降到0.95 以下時,可與資深管理  階層共同研商。• 績效門檻值:當關鍵設計項目(如處理器使用率)超過預期設計的  125%以上,可與資深管理階層共同研商。在風險資料表/庫中列入風險評估、分類及排定優先順序的準則或是風險管理需求(控制與核准層級、再評量的時間間隔等) 都是設定門檻的方式。

建立風險管理的策略

再著手進行風險管理的準備工作時,建立風險管理的策略是最關鍵的環節,CMMI建議風險管理策略應由共同的成功願景所導引,這願景從交付產品、成本及對任務之適用性的觀點,來描述對未來專案結果的期望。風險管理策略通常記錄於組織或專案的風險管理計畫。風險管理策略由相關的關鍵人員審查,以增進承諾和瞭解。

風險管理策略說明的事項如下:• 風險管理投入的範圍• 使用於風險界定、風險分析、風險降低、風險監控及溝通的方法及工具• 專案特定的風險來源• 如何組織、分類、比較及整合風險• 對已界定風險採取行動的參數,包括可能性、結果及門檻• 風險降低所使用的技術,例如:雛型製作、模擬、備選方案設計或  漸進式發展• 定義風險度量,以監控風險狀況• 風險監控或再評量的時間間隔

二、界定並分析風險風險的嚴重程度會影響用於處理風險的資源,以及何時需要適當之管理階層關切的決定。為了有效率的處理和有效的應用風險管理資源,可把相關風險組成不同的群組。進而分析優先處理順序及對策。

界定風險

風險界定應是有組織及透徹的方法,以找出在達成目標的過程中可能發生或實際的風險。為了有效起見,CMMI模式說明風險界定不應試圖說明每一可能事件,而無論其是否極不可能發生。使用由風險管理策略發展出來的類別與參數, 以及已界定的風險來源,可提供適用於風險界定的規範及效率。

在產品生命週期所有適當的階段,界定與成本、時程及績效相關的風險。已界定的風險是啟動風險管理活動的基準。風險清單應定期審查,以重新檢查可能的風險來源和狀況變更。

界定風險的方法有很多,典型的界定方法如下:• 檢查專案分工結構圖的每個元件以找出風險。• 使用風險分類表來評量風險。• 訪談主題事務專家。• 檢查學習心得文件或資料庫。• 檢查設計規格和協議書需求。• 審查可能影響專案的環境因素

專案經理也可由流程資料庫中獲得類似專案的風險與風險管理的資訊。評估與思考過去專案所碰到的風險可協助指認現在專案中可能存在、但卻未被列出來的風險。

專案經理也可利用他們的判斷與經驗來評估潛在的風險。另一個方法則是以檢閱專案管理計劃或討論會議來找出風險。

以下是其他風險的範例: • 與罷工相關的風險• 供應來源縮減• 科技循環時間• 競爭

風險說明通常以標準的格式記錄,包含風險內容、條件、相關的關鍵人員及發生的結果。風險內容提供額外的資訊,可容易瞭解風險的意義。在記錄風險內容時,考慮風險出現的相對時間順序,以及風險週遭的環境或條件,因風險會帶來關切、疑慮或不確定性。

評估、分類及排序風險

風險指認只能找出可能妨礙專案達成目標的事件,但不同的風險所造成的結果也不同,在管理這些風險之前,必須將這些風險的優先順序作排列,以保證管理計劃能針對影響較大的風險來管理。

風險排序必須依照風險真正發生時所產生的影響來決定,也就是說當風險實際發生時,為專案帶來的損失有多大?這些損失包括了直接損失、失去商機或未來商機的損失、員工士氣消失的損失等等。基於這些可能的結果以及風險發生的機率,可計算風險揭露(Risk Exposure),並進行風險排序。

這個方法需要風險機率與風險結果量化的評估,通常歷史資料可以幫助您對這些參數加以估計。由於風險是機率事件,他們並不常發生,收集資料也就特別困難。此外,任何這類資料必須加以適當的解釋,因為他們會影響所採取的行動,這個事實告訴我們必須利用更多的經驗而不是僅靠過去的一些資料。這種情況下,將發生機率與結果分類可以更幫助我們將高風險與低風險作一個區分。

因此風險排序的方法之一是估計風險發生的機率以及它的後果,這二者的乘積,亦即風險損失的預期值,便可作為排序的基準。預期值又稱之為風險揭露(risk exposure),如果Prob(R)是風險R發生的機率,而Loss(R)是風險實際發生時的總損失,則風險揭露(RE)的計算為:(註三)

RE(R)=Prob(R) * Loss(R)

PanKaj Jalote在"Software Project Management in Practice"書中分享印度著名軟體公司Infosys管理風險的方式:

1. 將風險發生的機率分為高、低、中三個等級,可分別賦予0到1不同的值:

機率
範圍
0.0-0.3
0.3-0.7
0.7-1.0

2. 將風險衝擊(損失)分為低、中、高、非常高四等級,可分別賦予1到10不同的值:

結果等級
範圍
0.0 - 3.0
3.0 - 7.0
7.0 - 9.0
非常高
9.0 - 10.0

有了這些比率與範圍,就可利用以下簡單的排序方式:•對每一個風險評估它所發生的機會的等級。如果可能,最好給定 一個值。•評估每一個風險衝擊的等級。必要的話同樣給一個1-10的分數。•根據機率以及對專案的影響分等,例如,高機率、高衝擊的風險的等級 會高於中機率、高衝擊的等級。如果有衝突,則依您的判斷(或計算 風險揭露)。•緩和最高等級的一些風險並追蹤。

風險管理的主要目標是找出最重要的幾個風險並專注在上面,因此分類是較好的方式。顯然一個風險若有較高的機率發生,衝擊又較大時,就會有較高的風險揭露值,因此優先順序也會高些。

三、控制及降低風險

處理風險的步驟,包括研訂風險處理方案、監控風險,以及超過所定義的門檻時,執行風險處理活動。對於選定的風險,應研訂和執行風險降低計畫(risk mitigation plan),以主動減少風險發生的潛在衝擊。除了事前試圖降低風險,亦應包括緊急應變計畫(contingency plan),以處理一但發生的風險衝擊。在風險管理策略中,要定義啟動風險處理活動的風險參數。

研訂風險降低計畫

針對每個關鍵風險,研訂可選擇的活動、替代方案、返回點,並對每個風險皆有建議的行動過程,是風險降低計畫的關鍵組件。特定風險的風險降低計畫包括規避、降低及控制風險發生可能性的技術和方法,或風險發生時遭受的損失程度(有時稱作「緊急應變計畫」),或上述兩者。監控風險,當風險超過設定的門檻時,展開風險降低計畫,以使受衝擊的部分回歸到可接受的風險等級。只有風險結果評定為高或無法接受時,才對該風險研訂風險降低計畫和緊急應變計畫,其它的風險可能僅是接受,並簡單地監控。 風險處理方案,CMMI整理出備選方案如下:• 風險規避:改變或降低需求,但仍符合使用者需要• 風險控制:採取主動的步驟,以降低風險• 風險轉移:重新配置設計需求,以降低風險• 風險監控:就指定之風險參數的變化,觀察並定期重新評估風險。• 風險接受:對風險有認知,但不採取任何動作

通常,特別針對「高」風險,應產生一種以上的風險處理方法。 在很多情況,風險會被接受或觀察。當風險被判定太低而不需正式的風險降低,或當似乎沒有降低風險的可行方法時,通常接受該風險。假如接受一個風險,就必須記錄此決定的理由。在績效、時間或風險曝光程度(可能性和結果的組合)的門檻能客觀定義、驗證及記錄之後,風險才可觀察。必要時才能啟動風險降低計畫,或緊急應變計畫。 應儘早且充分地考慮技術的展示、模型、模擬及雛型,做為風險降低計畫的一部分。

執行風險降低計畫

為了在工作期間有效控制和管理風險,需遵守事先安排的計畫,定期監控風險及其狀況,以及風險處理活動的結果。風險管理策略定義風險狀況應再評量的間隔。這個活動可能導致發現新風險,或可能需要重新規劃或重新評量新風險的處理方案。在任一情況,與風險相關的可接受門檻應與風險狀況比較,以決定是否需要執行風險降低計畫。從CMMI舉例的典型的工作產品:1.更新後的風險狀況清單 2.更新後的風險可能性、結果及門檻的評量3.更新後的風險處理方案清單 4.更新後的風險處理行動清單 5.風險降低計畫 可知必須定時監控風險及其狀況並且確實更新風險清單、參數、處理方案的內容,才能確實執行風險降低計畫

結語風險管理的目的是在風險發生前,界定出潛在的問題,以便在產品或專案的生命週期中規劃風險處理活動,並於必要時啟動之,如此以降低對目標達成的不利衝擊。CMMI對於風險管理提出一套有效的參考模式,強調風險管理是一個持續的、前瞻的流程,此流程是經營及技術管理流程的重要部分。風險管理應該處理可能會危害到重要目標的議題。確實持續進行有效的風險管理可以預測並降低對專案有重要影響的風險。 有效的風險管理是透過相關的關鍵人員的合作與參與,及早且積極的界定風險。成功的風險管理需要具備領導相關關鍵人員的優越領導能力,以建立自由、公開及討論風險的環境。

參考資料1.Capability Maturity zModel Integration (CMMISM) Staged Representation March 2002.2.林信惠•黃明祥•王文良,"軟體專案管理",智勝出版社,2005年7月再版3.PanKaj Jalote 原著, 曾淑峰審訂•甄敏、文德蘭、張小萍等 校/譯,"軟體專案管理最佳實務",維科出版社,2004年6月初版

top
 
做愈多,死愈快-如何利用CMMI 架構 降低風險 提昇利潤從大前研一新作《即戰力》談起

做愈多,死愈快-如何利用CMMI 架構 降低風險 提昇利潤從大前研一新作《即戰力》談起

■張建華

前言

孫子兵法有云:「昔之善戰者,先為不可勝,以侍敵之可勝。不可勝在己,可勝在敵。故善戰者,能為不可勝,不能使敵之必可勝。故曰:勝可知,而不可為。不可勝者,守也﹔可勝者,攻也。」換句話說:在平時,組織需專注於培養實力;在戰時,組織就可發揮「即戰力」。在市場競賽的態勢中,平時就建立制度(如CMMI, ISO, etc.)、充實競爭力,在賽局(如競標)狀況出現時,就能輕易脫穎而出,旗開得勝。因此所有競爭優勢就是在平常中培養和累績,無法臨時抱佛腳而得,而建置CMMI相關之品質管理制度(QMS)及落實在日常執行上都需要相當時日不斷的努力。

而日本首席管理大師-大前研一最新力作「即戰力」,適與孫子兵法上述理論不謀而合,並進一步對「即戰力」培養關鍵,有更具體的說明,亦即「語言力」、「財務力」和「問題解決力」。筆者根據多年經驗,將此理論加以應用,並與有意改善資訊服務或軟體業的讀者共享。

語言力

毫無疑問地,一口流利的外語,在地球是平的時代中,當然可以輕鬆立足無國界經濟圈,也較他人或他公司更能吸收新知和開發更多機會或客源。根據筆者經驗,業者導入CMMI過程中,應使用中、英文雙語,在開始導入階段或許有些困難,但長期下來,一般CMMI術語便能朗朗上口,聽力亦會有所進步,在評鑑完成之後,除可藉由CMMI或建立或補強QMS和提升公司品牌位階外,更有充份的自信走向國際舞台,利用第一關鍵力-語言力來爭取更多商機。至此,政府資助下的資服業及軟體有關業者才有機會跨出台灣市場,或成為IT硬體製造業者步入微利時代後之加值,如此,上億元的CMMI導入資助才有意義和價值。

財務力

從CMMI架構來看,台灣的專案及產品開發的財務能力擁有許多待加強和提升空間,由於一般專案經理或產品經理(PM)均沒有確實計劃(PP)和掌控(PMC)專案或產品的投入與產出、或是成本、收益、風險和利潤的事前估算與事後掌握;一般而言,大多PM都交給公司的會計或財務人員,將之推諉給公司或老板,大夥糊?婼k塗地賺錢或賠錢。一般多在結案之後才大概知道是賺或是賠?事前、事中和事後都是摸著石子過河。在CMMI或在PMI/PMP的專案管理要求下,專案經理財務力的磨鍊,尚有很大的學習成長空間。在CMMI的導入中PP: SG 1 Establish Estimates 財務力一直是第一件要學習的技巧。(PP: Project Planning/Estimation; PMC: Project Monitor & Control)。

問題解決力

在CMMI的世界裡,DAR, CAR及其他流程領域中對於問題解決力有諸多要求。在流程領域中定好時間審查、發現問題、追蹤問題,直到解決問題,最後並做檢討、記錄和經驗分享,以避免再次落入類似陷阱,並準備下次在類似案例中,有例可尋以降低開發成本。問題解決力(Problem-solving)與決策力(Decision-making)也或顯或隱地散落於QMS各程序書中,公司同仁在操演問題解決力的事件中相互學習和共同成長。問題隨時可能發生,或輕或重或急或緩,因此公司對於問題解決方法有共識並在平時就培養問題解決力,即戰力之一的問題解決力的鑽研,誰曰不宜?

做愈多,賺愈多 vs. 做愈多,死愈快

理論上,做愈多,賺愈多;否則何必多做呢?但實際上,若沒建置相關標準作業程序(SOP),做愈多,不見得賺愈多。對軟工或資服業而言,若沒建置相關作業程序(CMMI-QMS)的話,做愈多,營業額愈高,成本也愈高,結果利潤沒愈多,可是風險卻相對愈高。一般企業經營者短視近利,只見營業額和有多少案子而拼命的加班、趕工(不一定加人,因加人會加成本和減利潤),盡一切可能趕快結案、趕快收錢,其結果也難免落入惡性循環(Vicious cycle)---做愈多,死愈快。君可見:許多公司因為太忙了(事實上,沒有不忙的公司和不忙的員工---就是不忙,也要裝忙,否則老板鐵定加工、不加錢)。忙而亂是你我看到的臺灣企業經營景象。臺灣人平均工時為世界前三名,而生產力卻在十名之外,您知道為什麼嗎?!

因此在CMMI導入公司中,常見以下狀況:在同仁和部屬強烈反應(或反對)下,將不賺錢的CMMI案子延後,以免影響賺錢的其他案子。然而,CMMI案不賺錢,卻是省錢的引子。太多的重覆作業(re-work)、太少的重覆使用(re-use)。太多的浪費,太少的節制,公司豈能賺錢?一般優秀的A級主管只能見陽(表象),不能見陰(裡實),才會拼命趕進度,才能對老板和客戶有交代,因此就輕易地落入了「做愈多、死愈快」的旋渦---趕完一個案子,再接下一個案子,永遠忙不完,永遠沒空想與做品質管理制度(QMS);只有卓越的A+主管能見陽,也能見陰。唯有能增加營業額,也能(省)降低成本及提高品質的主管,才能在維持(或不犧牲)品質要求下,擴大獲利空間。甚至於建立公司的聲譽和產品的品牌形象。公司的老板(GM or President)若沒有真確的品質認知和決心與毅力下,在各專案主管的共同要求(或隱性威脅)下,終究是暫緩CMMI的推行。

結語

對於資服業而言,CMMI為目前全球共同接受,一套世界級、成功和可行的參考標準。藉由其架構來檢視組織的體質健康(完整)與否(Gap analysis, SCAMPI Class C or B)?再依評量的結果進一步調整和補強,使組織更強健,更符合國際規格。建立或補強一個公司內的溝通平台,再通知客戶:公司有此品牌認證外,也同時建立公司對外的分工合作基礎。在地球是平的今天,取得此國際公認證書,豈可延誤、暫緩?而CMMI無庸置疑地位在這轉捩點上(The turning point between vicious cycle and positive cycle),而總經理與導入團隊(SEPG Lead)隊長卻是掌握這轉捩點的人,試問讀者是否正是CMMI成功與否的關鍵人物,能帶領組織脫離苦海的船長與大副?而船長與大副的品質意志力,決定了整個公司未來的方向,您以為呢?

top
 
Decision Analysis and Resolution

Decision Analysis and Resolution

決策分析與解決方案

■黃叔敏

目的

決定分析和解決方案主要的目的是提供組織在需要作重大決策或尋找解決方案時,可以透過一套結構化評估的程序與方法,找出針對議題最合適的解決方案,同時降低決策的風險。

使用結構化決策過程可以降低或減少每個人在主觀上的本質影響度,同時透過客觀的方式,可以提出更多的選擇的方案,用以提升決策的品質,並讓所決策的方案正確性大幅提高。

使用的時機

結構化決策程序與方法可以適用於技術性或非技術性上的議題。在專案執行過程中,通常用在專案的重大決策上,特別是會影響專案的承諾、品質、成本、期程等重大議題的決策與問題上。

典型的決策應用時機,可參考下列所述 :

一、當需要決策議題是被評估為中等或高風險的項目時。 二、當決策需要牽涉到異動建構管理項目時。 三、當決策將導致專案的期程變動超過組織所規範允許的變動範圍時。 四、當決策將影響專案目標的達成時。 五、當決策過程所花費成本與決策結果的衝擊兩者比較是合理時。

專案執行過程中,針對下述事項,建議專案經理考量使用 :

一、系統架構的選擇。 二、自行開發或委外的決策。 三、委外/合作廠商的選擇。四、專案開發模式 ( Life Cycle Model ) 的選擇。五、產品新功能提供的選擇。 六、外購 Solution 的選擇。 七、工具的選擇。

基本上組織可以在程序書或工作指導書上規範那些項目是必需要經由此決策的過程,那些項目是建議參考使用,由專案經理依專案狀況來決定之。

決策分析與解決方案的程序與作業項目

一、規劃決策會議 :

1.規劃會議的主題,期望達到的目的,議程與每項議程安排的時間。 決策會議以針對目標議題確認其解決方案為主要的的方針、議題、目的/目標,整個會議進行的方式與議程,及每項議程預訂使用的時間等,都需要在會議前先規劃與明確的訂定, 並於會議前送交所有與會人員,讓他們事先研讀與準備。

2.整理已取得的相關資料, 並於會議前先發給與會人員參考與研讀。包含 :a.目的/目標與議題說明 ( 背景說明 )。b.可能的解決方向或方案( Alternative Solution ) 。c.限制條件 ( 成本、期程、品質要求、效能要求、環境要求、標準要求等 ) 。d.可能的衝擊,風險與現況分析。

3.規劃必要的參與人員。包含 : a.與此決策(結果)有直接影響的關鍵人員。b.決策(結果)的執行者。c.QA人員。

二、規劃解決方案必需要滿足的必要要件或準則(Evaluation Criteria)及其相對的權重(Weight)

1.在決策會議舉行前,負責人員需要先訂定決策的評估準則( Evaluation Criteria )。 2.評估的準則需要考量的項目如下 :

a.技術上或標準上的限制條件。 b.客戶的需求 ( 技術性需求與非技術性需求 ) 。c.風險。d.軟體架構或效能上的需求。e.成本。d.期程。f.所需的技能等。

3.評估的準則需要依其優先等級與重要性,訂定其相對的權重( Weight ),並檢視以確保所有。關鍵性的要項均已考量並列為評估必要條件( 或關鍵充份條件 ) 。 4.決策評估的準則及其選擇的原由之摘要敘述說明, 需要將其於會議前與會議的議程一併送交會議參與者參考研讀。

三、規劃決策過程將使用的技術或方法( Evaluation Method or Techniques ) :

決策過程所採用的技術/方法,通常需要考量決策議題的重要性,複雜性與現有的資源。 考量的因素包含 :

1.決策目的。2.使用該種技術所需資源 (是否可以取得、取得成本、時間 )。 3.使用技術是否可提供議題的解決方案。 4.對現有的預算(成本)、期程、效能、風險策略的衝擊影響。

針對技術性議題,其評估的方法可以考量採用模擬法 ( Simulation )、雛型法 (Prototype)、模型法( Modeling )、先導試行法 ( Piloting ) 等方式來評估各種可行方案。必要時,甚至可用多種方法來評估與驗證這些方案的可行性,以避免單一方法的缺陷。

需將評估所預備使用的評估方法及選擇的原由,記載於決策文件或會議的記錄中。

四、可行方案( Alternate Solution )的思考與討論方式 :

1.可行方案的思考模式,通常所使用的方法是腦力激盪( Brain Storming )的方法請參考《附錄1》,它是透過群體人員的共同思考,提出多項可能的解決方案。 2.所提出的各種解決方案,均需要記載於會議記錄中,同時經過分析與探討來選擇最佳的行動方案。

針對所提的各種選擇方案,可以透過上述所提技術評估方法或文件的審查,以及所選擇的評估準則於會議中討論,尋求出最佳方案。

五、擇解決方案 ( Select Solution ) :

1.將先前所提的各種方案分類與歸類,整合相類同方案, 依會議前已訂定方案所必需要滿足的準則( Criteria ) 或要件,檢視所整理的結果,消除那些未能合乎準則要件的方案。 2.以評估準則為基礎,使用各種評估的方法,依據評估準則要項,針對所提各種可行方案,逐一評估,並將評估過程、假設條件、評估結果與其原由說明,逐項記錄之。

此階段評估的方法,可使用《附錄 2》所列技巧來評估。經由這樣評估的程序,可以增強選擇方案的信心,同時可以驗證/確認所選擇的方案。

3.針對最後決策的選擇方案,規劃執行計畫。

包含其相關的作業項目、各工作項目完成的日期、產出的工作產品與指派的負責人員等,並記錄於會議記錄中。

4.針對最後所選擇的方案,除上述事項記錄外,尚需將其可能的風險項目與限制明述與記錄。5.整個評估過程及其使用評估方法,均要明確記載在決策會議記錄中, 以供其它專案參考。

 

《附錄1》可行方案思考的模式(Alternate Solution Method): 腦力激盪( Brain Storming )

腦力激盪是一種針對問題開發創造性解答的方法。針對特定的議題,在討論中每個人盡可能針對此議題,在不考量任何限制條件的狀況下,盡量發揮自己的想象力, 提出各種可能的解答方案或想法。

腦力激盪開始的方式為,可由一位引言者,先提出可能的方案或構思方向為起點,來推動與激發參與討論的人員的腦力, 讓與會者能毫無拘束的提出各種可能方案或構想。

一、腦力激盪需遵守的原則

1.在腦力激盪的期間,與會者只能針對所討論的議題提出各種可能方案或構想,但對其它與會人所提的方案或構想,不得提出任何評論。2.思考可能方案或構想時,以不受任何限制、盡量開放為原則,考量有甚麼方式可能解決此問題,而暫時不考量其所需資源、條件、限制或個人偏見。

一旦腦力激盪階段結束後,即可針對所提出的各種解決方案作分析,尋找最佳解決方案,此可透過進一步腦力激盪或者是使用傳統的分析方法。 二、腦力激盪可以參考下列步驟來執行

1.推派一位主導者來管控腦力激盪的進行。2.與會者安排的考量:

腦力激盪中參與討論的與會者考量盡可能來自不同的經驗與組織的人員,這可為會議中帶來很多創造性的想法。

3.首先需要針對解決的議題定義清楚,並規範解決問題的方案必需滿足的準則或要件,以及腦力激盪議程的時間長度,然後開始執行腦力激盪的議程。 4.在過程中主導者需要不斷的以熱心來鼓舞與會者提出任何構想,同時對所有與會者不能有所批評,並確保維持會議的熱絡,不要讓與會者的思路中斷/停頓太久,設法維持所有思路聚焦在主題上而不要偏離主題,必要時可以引導與會者提出的構想與方案,能夠朝比較實用解決的方案上發展。5.主導者能適時鼓勵與會者提出有趣的解決方案或構想,竭盡所能提出任何想像得到的方案,特別是那些創新的方案是最為歡迎的(尤其是有關市場性、產品開發等議題上,特別需要) 。 6.在腦力激盪的會議期間中,任何提出的方案或構想,任何人都不能批評或評估。

因為批評會招致與會人員思路中斷的風險,同時會產生抑制創造性構想與破壞腦力激盪的自由本質。

7.腦力激盪的過程不是只能提出完全新的想法,與會人員也可以針對已提出的方案或構想中,透過聯想力,聯想其它的可能方案,或從所提出的方案或構想中開發出另一種方案或對已提出的方案或構想,提出一些可以加強或調整的地方。 8.需要將整個過程與所提出的方案記錄,用以作為下一階段的分析與評估用。

如果可以使用白版將所提出方案摘要列出讓與會者都能一目了然,將更有助於會議的進行。

9.腦力激盪可以經由個人,群體或將此兩種混用的方式來執行。

a.個人單獨的腦力激盪 : 個人單獨的腦力激盪比群體腦力激盪能提供更廣泛構思方案,可以自由發揮其想法,不受外在拘束或干擾,而且不受時間與群體限制影響。但會比較沒有效率,且可能因個人因素,往往只會考量能力所及範圍。

b.群體的腦力激盪 : 群體腦力激盪可以針對議題發展出更深入與更有效率的解決方案與構想,當個人考量方案的思路遇到困難時,可藉由其他人創新的構思或經驗來彌補此方面困擾。但群體腦力激盪有時會發生針對某一方案議題探討更深入細節討論上,因而佔用太多時間,造成方案與構想數量太少的現象,或因少數人發言太強烈,而壓抑其它較安靜人員的發言機會與創新方案產生。

10.個人單獨腦力激盪與群體腦力激盪可混合使用。

只要先將問題定義清楚後,就可以讓每位與會者先作個人單獨的腦力激盪,提出各種可能解決方案,再將這些解決方案帶到群體腦力激盪議程來討論,以增進及加強方案強度或能力。

《附錄 2 》評估的方法(Evaluation Method)

一、.T 圖表(T-Chart)

T圖表是針對每項可行方案,依評估要項的順序,針對每一個被評估的方案,將其優點及缺點分別敘述陳列的方式來展現,並以圖表方式呈現其結果,用以確保針對每項評估要項、方案的優點和缺點均被考量與審查。

例如 : 針對考量買車作為代步工具的優點與缺點

優點
缺點
能快速到達目的
停車位難找的問題
良好的安全性
汽油的費用高
能擋風防雨
維護與保險費用昂貴

另一種圖表方式是將兩種可行方案並列 ,各別陳述其優點/ 論證/效益。 例如 :公司考量MIS系統是否自己發展程式(Coding)或委由軟體公司代工處理。

委由軟體公司代工
自己發展程式
專精的專業技術
能夠快速的反應
良好的技術文件
對自己需求有較好的認知
良好的品質管理制度
易於與內部人員溝通

此表格亦可適用在超過兩項以上的選擇方案,並增列項目陳述每一方案的缺點項目。

二、PMI 圖表法

將上述的 T 圖表加以修訂, 將考量要項從單一的項目"優點",修訂成三個不同項目(優點/Plus ,缺點/ Minus,興趣/Interest)來評估 ,稱之為 PMI 圖表。首先列出此方案所有優點,然後列出所有缺點,最後列出其它可供參考事項;例如 : 重要性/影響力、稀奇/特別之處等,其它認為可列入作為評估參考,但無法明確判定其是否為優點還是缺點的事項。

這是一個非常有效力但常被忽略的技術,因為通常在最後決策方案時,雖然大家都表示會先考量每個方案的優缺點後才作決策,但實際上,往往是先決定方案後,再尋找有力的理由支持它。

因此首先考量/陳述每個方案可能的優點與缺點,然後經相互比較對照後,再來裁決/選擇比較合適的方案,如此可以盡量避免與或降低因個人的感情因素,而產生對於決策的品質所帶來的衝擊影響。

三、Burden's Ass

此種決策的方法適用在當同時面對兩個或多個非常具有吸引力的方案,其評估結果勢力均相當,無法決策選擇時。處理的方式就是針對每個方案只列出其所有的缺點。那是因為當有二個以上似乎都是滿意的答案可以選擇時,人們往往只思考它們的優點,而疏忽它們可能的缺點,因而作出錯誤決策。Burden's Ass的方法就是簡單地將考量範圍只集中於缺點。

四、Measured Criteria

這個技術的使用方式即為:

1.明列最後決策的方案所需滿足的評估要件。2.針對每項要件在整體要件中相對重要性給與不同權重(Weigh)。3.針對每一方案,依據其能滿足每個要件的程度,給與適當的點數(點數通常以1到10為範圍)。 4.當對每個方案依每項評估要件分配它們應得的各個數據後,將此數據與每個評估項目的權重(Weight)相乘,最後加總所有的點數,選擇最高點數的方案。

下圖表為以長途旅行選擇搭乘的工具為例子 :

Item
Weight
火車
飛機
巴士
舒適
2
9(18)
6(12)
5(10)
速度
3
6(18)
9(27)
5(15)
安全
4
7(28)
8(32)
6(24)
食物/餐點
2
6(12)
2(4)
9(18)
價格
5
5(25)
3(15)
8(40)
Total合計
(84)
(90)
(107)

在上述案例,巴士的總點數最高,是最合適的選擇。

top
 
CMMI 最新趨勢及資訊系統委外籌獲模式(CMMI-ACQ) 概述

CMMI 最新趨勢及資訊系統委外籌獲模式(CMMI-ACQ) 概述

■甄 敏

CMMI 最新趨勢

自從卡內基美隆大學(Carnegie Mellon University)的軟體工程研究所(Software Engineering Institute-以下簡稱SEI) 於2000年開辦CMMI簡介課程以來,已培訓300餘位SEI授權講師,上課人數超過四萬人;養成400多位SEI授權之主評鑑員在全球六大洲完成超過1000件SCAMPISM評鑑案件。SEI於2002年一月發行CMMI V 1.1 版套裝產品後,進而在2006 年8月公告發行CMMI for Development (CMMI-DEV), V1.2, 內容與CMMI V1.1 差異不大,但強調適用於系統及軟體開發型組織的流程改善模式。由於各界對CMMI的熱烈迴響,SEI在基於和CMMI-DEV相同架構上規劃了適用於資訊委外籌獲型組織的CMMI-ACQUISITION,簡稱CMMI-ACQ;以及適用於服務型組織的CMMI-SERVICE,簡稱CMMI-SVC。CMMI-DEV、CMMI-ACQ及CMMI-SVC合成所謂的互補薈集 (Three Complementary Constellations) 。CMMI-DEV對於資訊系統/軟體開發流程提供了管理、度量及監控的指引,CMMI-ACQ促使委外籌獲單位居於清楚認知及決策領導的地位。CMMI-SVC的重點則在於提供組織內部及外部客戶服務的參考模式。CMMI互補薈集的三項模式都是SEI對於來自於政府單位與產業界最佳執行方法彙集研究的成果,足供力圖改善的組織作為參考。關於CMMI-ACQ, SEI和通用汽車資訊科技委外部門於2006年6月共同發表Adapting CMMI for Acquisition Organizations: A Preliminary Report (籌獲組織適用的CMMI模式:初步報告),預計於2007年上半年正式發行。關於CMMI-SVC ,CMMI專案團隊正在進行模式內容的研究中。

下圖為摘自SEI網站CMMI V1.2 概述的內容,基本上CMMI-ACQ,CMMI-DEV及CMMI-SVC (供服務型的組織採用) 都採用相同的架構,同樣都是分為四類,其中流程管理類、專案管理類、支援類流程領的16個流程領域相同,針對各模式的特質有適用的流程領域,三者彼此之間又可視需要互補運用︰

資訊委外籌獲模式(CMMI-ACQ) 概述

無論政府或是企業組織,提升效率及產能都是重要的課題。集中資源專注於核心活動以創造競爭優勢,將資訊系統/軟體委外已是一股不可遏止的潮流。對於資訊系統/軟體,舉凡政府機關、國營事業、軍方、金融單位、製造業、醫療體系等機關組織的委外採購單位及開發供應方都希望能夠有效溝通合作,共同改善資訊軟體委外專案的品質、成本與時程,達成既定目標。在開發供應方固然可參考CMMI-DEV模式提升品質及產能﹔委外籌獲方亦可將CMMI-ACQ作為對開發供應方提出清楚要求,採取有效管控決策,有效溝通互動,達到雙贏效果的參考。

CMMI-DEV 共有22個流程領域,對於每一項流程領域依照個別的能力度(Capability Level),分為0到5六個等級:0.未完成 (Incomplete)1.已被執行 (Perfromed)2.已被管理 (Managed)3.已被定義 (Defined) 4.已被量化管理 (Quantitatively Managed)5.最佳化 (Optimizing)22個流程領域又依照成熟度(Maturity Level)分成1至5個階段:1.初始階段 (Initial)2.已管理階段(Managed)3.已定義階段(Defined)4.已被量化管理階段 (Quantitatively Managed)5.最佳化階段 (Optimizing)

在下表中可以清楚的看出CMMI-ACQ中流程領域的類別和成熟度之間的關係:

     類別

成熟度

流程管理Process Management
專案管理ProjectManagement
支援Support
籌獲Acquisition
ML5 Optimizing最佳化•組織創新與推展 OID •原因分析與 解決方案CAR 
ML4 Quantitatively Managed •組織流程績效OPF•量化專案管理QPM  
ML3 Defined•組織流程專注OPF•組織流程定義OPD•組織訓練OT•整合專案管理IPM•風險管理RSKM•決策分析與 解決方案DAR•籌獲需求發展 ARD•籌獲技術解決 方案ATS•籌獲確認AVER•籌獲驗證AVAL
ML2 Managed  •專案規劃PP•專案監控PMC•需求管理REQM•建構管理CM•流程與產品品質 保證PPQA•度量與分析MA•籌獲管理AM•招標與供應商 協議發展SSAD

CMMI-DEV及CMMI-ACQ在流程管理類、專案管理類、支援類流程領的16個流程領域雖然大體相同,但是畢竟組織任務型態不同,所以內容也有些微調整區隔。CMMI-DEV V1.2的工程類流程領域適用於開發流程,所以在CMMI-ACQ調整成為籌獲類,包括下列6個流程領域,內容重點在剖析委外工作的主體:•籌獲管理 Acquisition Management - AM•籌獲需求發展Acquisition Requirement Development - ARD•籌獲技術解決方案Acquisition Technical Solution -ATS•籌獲確認Acquisition Verification -AVER•籌獲驗證 Acquisition Validation - AVAL•招標與供應商協議發展 Solicitation and Supplier Agreement Management -SSAD

結論資訊系統/軟體委外籌獲組織可以選擇個別的流程領域進行能力度改善,也可以採用成熟度等級所規劃的方式導入整組的流程領域。據以提高和資訊系統/軟體供應者之間的良好合作互動模式。

top
 
CMMI 工程流程改善的第一課-需求與需求發展

CMMI 工程流程改善的第一課-需求與需求發展

■黃叔敏

前言

一個資訊系統專案要能成功,最重要的關鍵要素就是 "需求的瞭解"、"需求項目的明確敘述與確認"、 "需求變更的管控" 這三件要項。它們涉及需求發展的工程與需求管理工程,本文茲將相關的事項敘述,期望能提供相關人員參考。

需求定義(Requirements Definition)

資訊系統成功的起步就是對客戶需求的瞭解與認知,並將所認知的"客戶需求"以明確的敘述方式描述,透過描述的文件與客戶溝通並得到確認,而要達到客戶與資訊系統開發者雙方都針對系統所需要提供的需求瞭解與確認,並在往後系統發展過程中掌握客戶需求的變更,這是一個關鍵性的難題。

因為客戶對資訊系統的需求通常不是整體性提出與展現,常常想到什麼就提什麼,沒有整理,因此需求項目往往看起來既不明確也很雜亂。因此,資訊系統開發人員需要先將客戶的眾多需求分類整理,然後再以客戶的語言描述每個需求項目的內容。

通常在資訊系統專案上將客戶的需求分為技術性需求 ( Technical Requirement ) 與非技術性需求 ( Non-Technical Requirement )。其中,技術性需求(Technical Requirement)又分為功能性需求( Functional Requirement )與非功能性需求 ( Non-Functional Requirement )。

如下圖一所示:

《圖一》

一、技術性需求 ( Technical Requirement )就是與資訊技術相關的需求,包含資訊系統所需要提供的功能與功能限制、技術性的規格要求、技術性的規範或限制要求等,一般再往下區分為功能性需求(Functional Requirements)與非功能性需求( Non-Functional Requirements)。

1.功能性需求 (Functional Requirements)

主要是資訊系統在業務上所需要提供的系統功能( Fundamental functions of the system ) ,此亦包含需要提供的操作介面與操作方式、需要提供的服務性功能等均屬之。

需要針對所需要的作業項目,列出其所需要的功能,敘述內容包含---功能性 Functional

  • 使用者介面架構與行為模式
  • 輸入項目&輸出項目
  • 資料處理
    • 正確性
    • 精確度…
  • 系統錯誤處理流程 ( Error Handling )
  • 系統啟動/結束 ( Initialization / Shutdown )

例如 :

2.非功能性需求(Non functional requirements)

通常是資訊系統在非業務面所需要提供的系統功能或限制要求。包含:設計的系統其能力/效能期望達到的要求、系統設計所使用的環境/工具、系統設計所需遵循的規範/標準等。

  • 運作環境(如:Window 2000, Linux ,…)
  • 安全性要求(如:users 使用等級與限制 …)
  • 系統效能要求(如:Response Time < 3 sec )
  • 可靠度的要求(如:Down Time < 1/ Year )
  • 系統可攜性要求(如:可使用在 Window , PDA , Linux )
  • 系統處理能力要求(如:Handle 1000 Concurrent users )
  • 系統設計限制(如:使用的開發工具, 資料庫,..)
  • 需與現有系統的整合
  • 舊系統的資料轉換
  • 系統限制性要求

二、非技術性需求 ( Non-Technical Requirements )

通常是針對客戶在資訊系統以外的事務性業務面需求,包含:

  • 專案管理上的要求(如:定期的會議與進度報告)
  • 專案期間需要提供的文件項目與日期
  • 交付產品的方式、數量與交貨日期
  • 驗收方式/程序
  • 教育訓練
  • 安裝與輔導上線
  • 議題/問題處理程序與反應時間(如:Service Level Agreement )

需求發展工程(Requirements Engineering)

需求發展的工程首先是了解客戶需求,包含各個層面的客戶對需求的定義(要求與期望),將這些資料匯整成客戶的業務性需求 ( Business Requirement ) 或需求規格 ( Requirement Specification ),經客戶確認後,再將其轉換為資訊系統的軟體需求規格 ( Software Specification ),也就是一般所言的軟體需求規格書 ( SRS; Software Requirement Specification ) 。

需求定義 (客戶業務面業務) --> 需求規格 --> 軟體規格(技術面需求)

整個需求發展工程的作業流程包含:

  • 需求獲取 Requirements Capture
  • 需求分析 Requirements analysis
  • 可行性研究 Feasibility study
  • 需求定義 Requirements definition
  • 撰寫需求規格文件 Prepare Requirements Document
  • 需求規格文件審查 Review Requirements Document
  • 需求規格確認 Requirements validation
  • 需求變更管理 Requirement Change Management

需求發展流程(Requirements Process)介紹

一、需求獲取 Requirements Capture

主要就是透過各種活動來蒐集與了解客戶的需求,以作為分析的資料來源。需求獲取的方法包含:

  • 與客戶面談
  • 研讀客戶的RFP ( Request For Proposal )
  • 客戶需求問卷調查
  • 客戶以往功能增加的要求
  • 客戶抱怨
  • 競爭產品評估
  • 市場產品需求調查
  • 檢視目前與未來的產品標準
  • 審查公司市場策略
  • 雛型 (或產品試用)
  • 展示/Demo

二、需求分析 Requirements analysis

主要就是系統分析人員透過專業領域的知識、工作的經驗、工具與方法 ( Methodology) 、來釐清客戶與使用者針對系統的真正需求。可能的話,並將客戶需求以下述方式分類:

  • 必要性需求 Mandatory
  • 充份性需求 Required
  • 期望性需求 Desired

以作為系統發展時,因預算與期程的限制其開發優先順序的考量。

三、可行性研究 Feasibility study

可行性研究是針對分析結果所明述的需求要項,針對目前的資訊技術上 ( 已擁有的及未來會掌握的 ) ,客戶所給予預算上與期程上的可行性分析,並提出可能的風險項目與風險分析,以作為對客戶承諾及專案發展計畫規劃的重要基礎。其中,技術上的可行性分析,必要時實施各種驗證的方法(如:建立系統雛型、模擬作業、Benchmark等)來確認技術上的可行性與滿足性,用以降低專案開發的風險。

四、需求定義 Requirements definition

需求定義就是將分析的結果,以客戶瞭解的語言格式敘述/定義客戶的需求。

資訊系統發展的組織應該建立需求文件的標準格式與需求文件撰寫指引,以維護需求文件撰寫的品質。

其內容敘述時考量:

  • 定訂 "特定的語詞" 用以分別敘述客戶 "必要的" 需求 與 "期望的" 需求。
  • 針對客戶關鍵性的需求,使用顯著的方式標示。
  • 避免使用電腦術語敘述客戶的需求。

五、撰寫需求規格文件 Prepare Requirements Document

需求規格文件(Requirements specification) 定義需求的細節,通常包含下述章節:需求規格:

  • 範圍 Scope
  • 需求一般性敘述 General description of requirements
    • 產品的願景/展望 Product perspective
    • 產品功能 Product functions
    • 使用者特性 User attributes
    • 限制 Constraints
    • 假設條件與依賴性條件 Assumption and dependencies
  • 需求規格描述 Description of specific requirements
    • 功能需求 Functional requirements
    • 效能需求 Performance requirements
    • 設計限制 Design constraints
    • 標準的要求 Standards compliance
    • 產品特殊屬性要求 Product attributes (Security, maintainability)
    • 與外部( 產品 )聯結介面 External interface
  • 介面規格 Interfaces
    • 使用者介面 User interface
    • 硬體介面 Hardware interfaces
    • 軟體介面 Software interfaces
  • 效能需求 Performance requirements
    • 聯結建立的時間 Connection setup time
    • 資料傳送速度 Data transfer rate
  • 設計限制 Design constraints
    • 依循標準 Standards compliance
    • 硬體限制 Hardware limitations
    • 安全性要求 Security
    • 可攜性要求Portability
  • 非功能性需求 Specification of non functional requirements
    • 成本 Cost
    • 上市時間 Time to market / 交貨時間 Delivery Date.
    • 提供發展的資源 Resources for development
    • 測試的資源 Resources for testing

六、需求規格文件審查 Review Requirements Document

需求規格文件撰寫完成後,需要將文件交與相關的關鍵人員( 資深的系統分析師、產業分析人員) 及專案負責人,進行需求規格文件的技術性審查驗証工作,事先可以先建立需求規格文件檢查的項目清單,提供審查人員執行審查工作的參考,審查人員在執行審查工作時亦可以視專案實務狀況修訂審查清單的項目。

需求規格書審查清單範例 :

技術性審查驗証工作是審查人員以技術性角度及個人的經驗、專業領域的Domain 等,檢視需求規格文件中對需求項目得描述是否滿足客戶/合約的要求、是否有描述不明確之處、需要修訂或缺失之處。針對相關的項目提出意見與建議,並將審查結果送交專案負責人與撰寫者,專案負責人得視審查的結果召開審查會議討論各審查人員所提的缺失與建議,撰寫者針對審查的缺失修訂,並將修訂結果送交各審查者確認。審查通過後填寫需求追溯表,並將需求規格文件納管,建立需求規格文件的基準 ( Baseline )。

七、需求規格確認 Requirements validation

需求規格確認通常是在需求規格文件的基準建立後,透過會議討論的型式針對客戶講解需求規格,與客戶協調需求內容,取得他們的確認與接受(同意),以便能開始執行下一個階段的工程作業(軟體設計工程),同時也需要對內部的設計單位講解需求規格書,以便讓設計單位了解並接手後續的設計工作,此項活動可以在需求階段完成的里程碑會議上同時舉行。

需求規格確認後,需要建立需求追溯表 ( RTM;Requirement Traceability Matrix ),一方面用以確保客戶的需求完全被滿足,在往後的工程執行被確實完成,另一方面當客戶提出需求變更時,可以用以檢視所可能被影響的文件與程式,當所有文件經確認與稽核完成後,專案的需求規格書可以正式完成發行 ( Release )。

八、需求變更管理Requirement Change Management

主要是針對專案執行過程中,客戶提出需求變更時的處理程序,當需求規格確認後,客戶往往因業務環境的變化或作業模式的演變,提出需求上的變更要求。在資訊專案發展的生命週期中,需求的變更是一種常態性的行為,因此組織或專案需要訂定一套制式流程處理客戶的需求變更。

需求變更的程序如下:

其中最主要的是需求變更的衝擊分析 ( Impact Analysis ) ,分析需求變更可能帶來的影響。包含:

1.專案的範圍 ( Scope )、大小 ( Size ) 是否改變 ? 2.需求變更影響的工作產品(包含目前已執行完成及進行中的工作產品),及其影響的程度。3.需求變更所需要花費的人力 ( Effort )。4.處理需求變更所需增加的期程 ( Schedule )。5.需求變更所帶來的技術性問題。6.考量需求變更的風險。7.需求變更所帶來的成本變動。

並開會邀請關鍵人員與會討論是否同意變更,必要時需與客戶討論、協調需求變更的內容,提出雙方認可的可行方案,確認後再依建構管理程序,將此次需求變更相關的文件項目(或軟體原始碼)簽出修訂、審查、再簽入以建立文件(或軟體原始碼)新的版本基準 ( Re-Baseline )。

top
 
專案管理與專案管理活動介紹

專案管理與專案管理活動介紹

■黃叔敏

前言

企業中任何一個組織的作業活動,通常可以分為日常管理作業與專案管理作業,而組織中的所有成員每天都在參與這兩項作業活動。隨著環境演變,專案管理作業項目所佔的份量越來越大,企業中大部份組織部門的作業活動中超過 80% 以上是專案性業務活動,因此專案管理作業在組織所扮演的角色越來越重要,甚至成為組織生存與成長的關鍵業務與組織在市場競爭中最重要的核心競爭力。面臨這樣的變化,組織中的任何成員,遲早都有可能扮演專案管理的角色,專案管理不再是專案經理人的專屬職責,組織的成員必需要好好面對它、對它有深度認知, 同時利用每次專案執行的過程,歷練自己的核心競爭能力。

專案管理相關領域

一般而言,專案管理相關領域大約可以分為下述9個領域,茲將9個領域略述如下:

  • 整合管理Integration Management
  • 範圍管理Scope Management
  • 時間管理Time Management
  • 成本管理Cost Management
  • 品質管理Quality Management
  • 人力資源管理Human Resource Management
  • 溝通管理Communications Management
  • 風險管理Risk Management
  • 採購管理Procurement Management

一、整合管理Integration Management

整合管理的主要目的是確保專案計畫中所有相關計畫間的匹配與一致性。

通常一個專案因作業項目、作業分工或階段性作業等因素需要,可能將一個計畫切割成幾個子計畫,如此將會有一個主計畫與幾個切割的子計畫,此主要的目的是用以讓專案團隊中扮演不同業務角色的成員,易於負責與管理其所負責的作業項目。

整合管理包含下述活動:

  • 各項專案計畫規劃Project Plan Development
  • 各項專案計畫執行 Project Plan Execution
  • 整體專案計畫的控管 Integrated Change Control

專案負責人必須確保各子計畫與主計畫間以及各子計畫間的匹配與一致性,以及整體專案計畫的完整性,並在專案執行過程的控管活動與專案計劃變更發生時,邀集各子計畫負責人員共同參與討論。

二、範圍管理Scope Management

範圍管理的主要目的是確保專案範圍的正確性與完整性。

專案任務就是在有限資源與時間內達成專案的目標。既然是在有限資源與時間內要完成,專案的範圍一定要規範並且明確的定義清楚,否則不僅無法在有限資源與時間內完成,專案完成所需要的資源與時間將無法估算與預期,並且完成時間將是遙遙無期了。範圍管理包含下述活動:

  • 專案範圍規劃 Scope Planning
  • 專案範圍定義Scope Definition
  • 專案範圍驗證 Scope Verification
  • 專案範圍變更管理 Scope Change Control

專案範圍在規劃時,除了需要有明確定義外,同時要考量它是可以驗證的,無法驗證將無法確認專案目標的達成。在專案執行的過程中,需求的變更是常態性的現象,而且在執行過程中將不斷發生,因此需要規範一套需求變更/範圍變更的處理程序與管理規則,讓專案成員與需求者都有共同的規範,否則就會形成需求不斷的變更,造成專案範圍的不確定,甚至讓專案進入無法結案的狀態,這是專案管理中最需要避免的問題。

三、時間管理Time Management

時間管理的主要目的是確保專案在合約約定或主管所給予的期限內完成。

「專案」的定義是在「有限的期程」內完成任務的作業,因此如何在要求的期程內完成所賦予的任務是專案規劃中最重要的事項之一。

時間管理包含下述活動:

  • 專案各項活動定義 Activity Definition
  • 專案活動順序 Activity Sequencing
  • 專案各項活動期程估算 Activity Duration Estimating
  • 專案各項活動排程規劃 Schedule Development
  • 排程控管 Schedule Control

整個規劃過程首先需要明列專案所有的工作項目,針對每個工作項目估算其所需要的人力 ( Effort ) 、考量工作項目之間的順序性與依賴性( Dependence ),依此規劃排程。規劃排程時,尚需考量專案團隊的人員的技能與每一位成員的工作量及產能來編排進度表,標示出專案執行過程最長的執行作業程序/關鍵要徑( Critical Path ),在專案執行監控中,需要特別監控此項最長的執行作業程序/關鍵要徑 ( Critical Path ),因為此項目的變動,將牽聯整個專案期程的變動。

四、成本管理Cost Management

成本管理的主要目的是確保專案在預算範圍內完成。

每個專案都會規定其預算與資源,通常的狀況是沒有一個專案會給予足夠的預算與資源。專案負責人如何在有限的(不足的)預算與資源內完成任務達成目標,往往是專案負責人最高難度的挑戰。

成本管理包含下述活動:

  • 資源規劃 Resource Planning
  • 成本估算 Cost Estimating
  • 預算編列 Cost Budgeting
  • 成本控制 Cost Control

在專案執行過成中,每個專案負責人最常抱怨的事就是資源問題,一個組織在同一期間內往往有很多專案同時進行,每個專案所需面對的除了有限預算需要控制外,在組織資源有限的狀況下,常常發生每個專案都在搶資源,特別是關鍵性的資源。因此專案負責人除了成本管理活動外,最常需要考量的就是專案與專案之間共用的資源協調與配合。

五、品質管理Quality Management

品質管理的主要目的是確保專案工作產品的品質是在預估的範圍內。

為了確保專案執行的最終成果不僅能滿足專案品質目標的要求,而且能得到客戶的滿意,在專案執行過程中,必須規劃相關品質管理作業活動,以期能達到此目標。

品質管理包含下述活動:

  • 品質規劃 Quality Planning
  • 品質保證 Quality Assurance
  • 品質控管 Quality Control

品質保證活動(Quality Assurance) 基本上是指審查與稽核的活動。審查的活動是專案執行過程中,針對里程碑的成果實施審查相關的活動,例如:文件(如:計畫書/規格書/操作手冊等文件)與程式的審查。主要的目的是希望透過每個階段的審查活動,檢驗該階段成果是否有缺失,期能提早發現問題、避免問題擴充與延續至下一階段,造成嚴重的修訂作業( Re-Work )人力耗損與抱怨。

稽核的活動是專案執行過程中,針對里程碑的成果與執行過程實施稽核的相關活動,確保專案團隊是依照組織規範與計畫程序/步驟實施專案活動。其主要目的是用以保證執行成果有一定的品質水準。

品質控管活動(Quality Control )基本上是測試相關的活動,在軟體開發過程中基本的測試活動包含:單元測試、整合測試、系統測試與驗收測試。其主要目的是確保最後交付的工作產品沒有缺失( Bugs)。

六、人力資源管理Human Resource Management

人力資源管理主要目的是確保專案團隊人力資源的有效使用與團隊士氣。

人力資源管理包含下述活動:

  • 專案組織規劃 Organizational Planning
  • 專案團隊成員的取得 Staff Acquisition
  • 專案團隊發展 Team Development

專案每一項作業的執行終究需依賴「人」來完成,執行者技能與經驗是否足以擔當該項作業,將對專案成果品質造成直接的影響。因此專案團隊的組織規劃、工作配置、執行每件作業所需的技能與經驗規格需求皆需要明確的標示,更何況組織的人力資源非常有限,經常無法提供足以擁有能執行該項作業技能與經驗的人力,所安排的人員通常無法滿足該項作業所需技能與經驗規格的需求,針對現實的人力狀況,專案負責人如何在專案執行過程中安排訓練與評估成員能力,是專案規劃中必需要考量與規劃的工作事項。

專案團隊在執行專案任務時,經常會發生情緒上的問題,特別是期程較長的專案. 專案負責人如果沒有警覺性或處理不當,往往影響整個團隊的士氣與工作意願, 甚至造成人員的異動。處理情緒問題通常是最棘手的議題,但專案負責人無法不面對它,因此在平常工作中需針對此項議題特別注意,除了研讀相關資訊與參加相關訓練外,實務上可以從部門主管或其它經理人如何處理該項議題的經驗中去學習。

七、溝通管理Communications Management

溝通管理的主要目的是確保專案團隊內部成員與外部關鍵人員間有關專案執行的狀況與資訊的了解與共識。

溝通管理包含下述活動:

  • 溝通規劃 Communications Planning
  • 資訊的傳遞 Information Distribution
  • 專案工作報告 Performance Reporting

溝通管理通常有兩項作業項目:第一項是專案有關議題的提出/討論/共識(承諾),此部份通常是透過定期專案會議(內部與外部)及報告來達成,對議題的提出/討論/共識(承諾),專案負責人需規劃其遊戲規則,讓團隊成員及外部(客戶)有一共通的處理模式,特別是針對客戶,必須明確規範雙方互動模式與窗口負責人。

第二項是針對專案資訊的產生、傳遞、收集、儲存的處置,需要規範那些資訊需要產生、何時產生、如何收集、匯整與報告由誰負責等,並且要定期產出專案執行狀況報告,將此報告Mail給所有專案成員、主管與外部關鍵人員,讓他們清楚專案的執行狀況。

八、風險管理Risk Management

風險管理的主要目的是確保專案執行過程的順利,避免特殊或意外的事件發生。影響專案的進行。

專案管理最重要的準則就是專案能在控管中完成任務,專案所有發生的議題都是在意料中或計畫中,而意外事件代表它是在非意料中或計畫中的議題,是超出控管的現象,特別是因事先沒有因應規劃,其發生往往會造成專案的失敗,因此需事先針對專案過程中可能的風險事項的辨識、分析、規劃與控管,以避免超出控管的事項的發生。

風險管理包含下述活動:

  • 風險管理規劃 Risk Management Planning
  • 風險事項的辨識 Risk Identification
  • 風險度評估 Risk Assessment
    • 衝擊影響度分析 Impact Analysis
    • 機率分析 Probability of occurrence
    • 風險期望值 Risk Exposure = Impact * Probability
  • 風險事項的應變規劃 Risk Response Planning
    • 預防計畫Mitigation plan
    • 應變計畫Contingency plan
  • 風險事項的監控 Risk Monitoring and Control

風險管理與經年累積的經驗有直接關係,往往不是單一專案負責人所能完成的。組織可以透過收集歷次專案經驗與發生的問題,建立組織風險資料庫,提供專案負責人參考。專案負責人可以請教其他專案負責人及與專案團隊成員共同討論列出專案風險事項與因應對策,並定期在專案會議中監控與討論,檢查目前已列出的風險事項及其處理與變化狀況,討論是否有新的風險事項需要考量等。

應變規劃策略通常分為:預防計畫( Mitigation Plan )與應變計畫 ( Contingency Plan )。預防計畫( Mitigation Plan ) 主要是對發生機率特別高的風險項目,針對如何降低或減緩其發生的機率提出的處理規劃;應變計畫 ( Contingency Plan )主要是對風險發生時其影響特別嚴重的風險項目,針對其發生時,如何降低或減少其嚴重度的處理規劃。

九、採購管理Procurement Management

採購管理的主要目的是確保採購或委外的項目其功能與品質均能如期完成,並作合適的技術移轉。

專案執行過程中有時因專案的需求,需要進行對外採購,特別是需要將某部份的專案作業項目委外時,採購管理將是一項非常重要的業務活動。

採購管理包含下述活動:

  • 採購規劃 Procurement Planning
  • 招商規劃 Solicitation Planning
  • 選擇供應商 Source Selection
  • 合約管理 Contract Administration
  • 驗收 Contract Closeout

以委外作業為例:在採購規劃中需要考量委外的策略、委外的標地物與詳細的需求規格、預算編列、委外期程與我方專案發展期程的配合等。

在選擇供應商活動中需要考量:如何評估供應商的能力與品質(合格廠商的評定)、如何從合格供應商中選擇專案最合適的合作伙伴(廠商評選的準則)。

在合約管理活動中需要考量:如何與供應商合作共同完成目標、如何在供應商執行過程中監控(透過審查與稽核)其階段性作業執行成果品質、當問題發生時如何處理及無法解決時的因應對策。

在驗收活動中需要考量:委外工作產品如何與我方工作產品的整合、驗收程序與方式、工作產品的維護與支援技術移轉、相關的教育訓練等。

專案發展的生命週期階段 - Project Lifecycle Phases

一般而言,專案發展過程生命週期可以分為下述5個階段,茲將5個階段略述如下:

  • 專案啟動階段Project Initiation Phase
  • 專案規劃階段Project Planning Phase
  • 專案執行階段Project Execution Phase
  • 專案監控階段Project Monitor & Control Phase
  • 專案結束階段Project Closeout Phase

一、專案啟動階段Project Initiation Phase

專案啟動階段是專案的起始作業活動。一般而言是從主管因業務需求指派專案負責人授與專案任務後,開始進入此階段。

這個階段主要的作業活動包含:

1.規劃初步資源需求計畫Prepare Draft Resource Plan2.專案初始會議 Project Initial Meeting:

專案初始會議的目的在於取得各支援單位對於專案負責人所提出的資源需求計畫的承諾。專案負責人在接受任務後,即著手於專案規劃活動,並將專案執行所需要資源需求事先提出與相關主管協調,其最主要的方式就是透過專案初始會議。會議的主要議題為:

  • 專案介紹
  • 初步資源需求計劃
  • 專案需求討論
  • 取得相關單位主管承諾

出席者包含:部門主管、品管主管、專案負責人、相關部門代表人員。

二、專案規劃階段Project Planning Phase

專案規劃階段是承接專案啟動階段後的作業活動,整個階段最主要的作業就是規劃專案計劃與取得專案團隊成員的承諾。

這個階段主要的作業活動包含:

1.規劃專案生命週期流程 Planning Project Life Cycle Process

專案的生命週期基本上最重要的是專案開發製程,以瀑布開發模式( Water Fall Model )而言,包含分析、設計、編碼、測試、驗收(如下圖一所示)。

《圖一》

針對生命週期中的每一個階段,可以使用 ETVX 模式訂定其允入準則 ( Entry Criteria )、工作項目(Task)、確認方式(Validation)與允出準則(Exit Criteria),以作為每一階段/里程碑執行作業的標準規範。

2.規劃專案計畫書 Planning Project Plan

專案規劃包含專案範圍的了解與確定、工作項目的結構化分解、專案大小估算、專案所需人力估算、專案所需的資源與人力,各項工作項目人力安排與排程( Schedule)、里程碑與工作產品、專案團隊組織及人員與職責等。

通常專案計畫書除主計畫外尚需考量:

  • 風險管理計畫Risk Management Plan
  • 品質計畫Quality Plan
  • 訓練計畫Training Plan
  • 建構管理計畫Configuration Management Plan
  • 專案監控計畫 Project Monitor & Control Plan.
  • 訓練計劃 Training Plan
  • 專案計畫修訂準則 Project Plan Revision Criteria

特別是專案計畫修訂準則,專案計畫書不是規劃完後就不變的,它需要依專案執行的進度狀況與問題,適時調整及維護計畫書內容,讓計畫書內容與實際的執行狀況能夠一致。

專案計畫修訂準則通常為:

  • 里程碑與檢查點調整
  • 專案生命週期的變更
  • 專案期程某一階段發生嚴重落後 > 20%
  • 稽核缺失

3.專案啟動會議 Project Kickoff Meeting

專案啟動會議目的在於讓所有專案成員與專案重要關係人(外部)了解專案計畫書內容,以及專案成員每個人的任務/職責/負責事項,並取得專案成員的共識與承諾。

會議的主要議題為:

  • 專案計畫書介紹
  • 專案計畫書討論與修訂/調整
  • 專案團隊成員的共識與承諾

出席者包含:專案負責人、專案成員、品質保證人員、支援單位人員、部門主管、專案的重要關係人(外部)。

三、專案執行階段 Project Execution Phase

專案執行階段是承接專案規劃階段後的作業活動,整個階段最主要的作業就是依專案計畫書執行專案,並將專案執行狀況的資訊適時提供專案負責人及主管參考。

專案執行狀況的資訊包含:

  • 人力使用資訊 Effort Status
  • 專案進度資訊 Schedule Status
  • 資源使用資訊 Resources Usage Status
  • 成本使用資訊 Cost Usage Status
  • 專案缺失資訊 Defect Status
  • 風險狀況資訊 Risk Status

四、專案監控階段 Project Monitor &Control Phase

專案監控階段也是承接專案規劃階段後的作業活動,整個階段最主要的作業就是依照專案計畫書監控專案執行,通常是透過專案會議來監控專案執行狀況,監控過程中若發現有與計畫書內容不一致的狀況發生,需要適時提出討論,並採取矯正措施,專案過程中有任何議題發生時,需要適時處理與反應,記錄並追蹤議題的解決,同時依專案執行狀況修訂專案計畫書內容,並定期對主管提出專案執行報告。

這個階段主要的作業活動包含:

1.專案團隊會議 Team Meetings

通常是定期舉行:每週一次或每兩週一次,主要的議題內容是:

  • 檢視專案各項計畫進度
  • 討論專案度量數據
  • 風險追蹤

出席者是:專案負責人、專案團隊成員。2.里程碑會議 Milestone Meetings

通常是每個階段或里程碑完成時舉行,主要的議題內容是:

  • 檢視每個階段/里程碑的允出準則
  • 檢視每個階段/里程碑工作產品
  • 討論專案度量數據
  • 討論階段/里程碑的品質目標
  • 風險追蹤
  • 行動方案(矯正措施)

出席者是:專案負責人、專案團隊成員、品質保證人員、部門主管、品管主管、其它相關單位代表。3.專案報告

  • 週報 Weekly Status Report
  • 月報/階段報告Monthly /End Phase Assessment Report

五、專案結束階段Project Closeout Phase

專案結束階段是承接專案執行階段後的作業活動,整個階段最主要的作業就是審查專案執行的最終成果,檢視專案執行過程的最佳典範與缺失,並提出改善建議與報告,特別是需要將專案過程所發生的重大議題及其處理過程作探討與記錄。以作為往後其它專案的參考。

這個階段主要的作業活動包含:

1.專案最終審查 Final Inspection2.專案最終版本發行 Release3.專案資料歸檔 Archival

專案資料歸檔不僅是要將專案執行過程中的資料:如 Mail、文件、記錄、程式原始碼、最終版本等歸檔納管,最好是將整個專案的開發環境、測試環境、原始碼、最終版本等壓成CD歸檔納管,以便未來如果有需要時可還原使用,並將錄製的CD安裝測試OK後歸檔。4.專案結案會議 Project Closeout Meeting

主要的議題內容是:

  • 專案成果討論
  • 最佳典範與缺失(經驗分享)
  • 改善建議

出席者:專案負責人、專案團隊成員、品質保證人員、部門主管、品管主管、其它相關單位代表。5.專案結案報告Project Closeout report

top
 
談資訊專案運作流程與各階段注意事項

談資訊專案運作流程與各階段注意事項

■黃叔敏

資訊專案一般而言可以分成規劃階段/執行階段/維護階段,茲將各階段流程重要的工作與注意事項略述如下,用以提供在規劃資訊專案流程制度與建制相關的程序書/工作指導書之參考。

資訊專案運作流程圖

資訊專案運作與各階段應注意事項

1.專案合約除一般性事物主題外,通常需要含蓋下列與專案執行有關的主題:

  • 專案的目的、範圍
  • 雙方的專案團隊、負責人(專案經理)
  • 雙方的責任義務與配合事項、專案會議、互動的方式與遊戲規則
  • 專案期程
  • 交貨項目、審查與驗收方式
  • 保固與維護方式

2.特別是雙方的責任義務與配合事項、專案會議、互動的方式與Communication的遊戲規則,需要定訂每個里程碑( Mile Stone )會議與定期的專案會議(每月一次)及雙方的互動行為方式與責任義務等細節,將這些事項規劃在合約或會議記錄中,用以提昇雙方溝通效率與減少誤解。

註:所敘述的細節可以事先在合約上,或者要求在「專案開發建議書Proposal」上列為必要的章節部份。

一、專案成立

1.專案起始會議:主要是業務人員將專案先前的業務活動、客戶的特質、合約要項與承諾對執行的專案經理作整理、報告與交接。專案經理透過此會議提出專案規劃與專案執行所需要的資源與人力需求。

2.專案啟動會議:專案經理針對專案團隊成員提出專案計畫說明與討論,以取得團對成員的共識與承諾。3.規劃專案計畫書:專案計畫書的重點是:

  • 專案的目的與範圍
  • 專案的工作項目
  • 專案開發所需要的人力資源需求 (能力、經驗、Domain Know how與人數)
  • 專案團隊組織、成員角色與職責、負責的工作
  • 客戶的專案負責人與團隊
  • 專案進行的方式與雙方各自的責任義務、扮演的角色;雙方的責任範圍以正面表列非常明確的標示出來,而非用攏統的語句。必須標明需要作到何種範圍、何種界限。
  • 客戶需要提供的事物與配合的事項。
  • 整個專案的時間(合約期限)、進度表、審查點(里程碑)。
  • 專案開發與測試所需要的H/W,S/W其它特殊資源。硬體環境與架構:H/W系統架構、網路架構(專線申請)、終端設備、PC、周邊設備(列表機等)軟體環境:系統載台(OS)、開發與測試的工具軟體、資料庫系統、伺服器軟體等。
  • 專案執行過程中,所需發展的各階段工作產品(專案計畫書、測試計畫書、軟體開發文件、軟體程式、測試文件報告等)及這些工作產品審查與管理的規則(如:建構管理計畫)、負責人員、預計完成時間與預估的作業人時(Effort)。
  • 專案的風險計畫:專案執行過程中可能的風險項目、發生的階段、影響度、預防與應變的措施/計畫。
  • 專案品保計畫:審查計畫(各工作產品的審查人員與預計時間)與稽核計畫(工作產品與專案監控流程的稽核、稽核人員與預計時間)。

二、客戶需求與系統分析

1.客戶訪談規劃:

  • 訪談單位與被訪談的主要人員(包含:業務流程負責主管、系統使用者),誰說了算數、居間的協調人員。
  • 訪談目地與議題。
  • 客戶需要提供與配合的事項(準備的資料、業務流程、目前使用的表單..),訪談進行的方式,訪談記錄與資料的確認。
  • 保密協定問題。
  • 需求文件的撰寫,審查與確認。
  • 訪談的預訂時間、時程表。
  • 訪談地點。

2.訪談記錄與確認、業務需求規格書(客戶的業務需求功能)

包含:

  • 訪談的記錄、需求規格書文件規格、確認的方式、確認代表人、確認的時間、修改與再確認的處理方式。其中客戶的業務需求功能,以客戶的語言,明確的方式 (輸入、處理流程、輸出)列出。
  • 必要時可以透過一些Demo或雛型方式,以確認關鍵的功能要項。

3.技術的需求規格書(SRS):

系統分析人員將客戶確認的業務需求功能,轉換為設計人員需要的技術性需求規格書(SRS),開始軟體設計與程式撰寫。軟體的需求規格書( SRS )是技術性文件,通常客戶看不懂,因此需求的確認,需要從客戶看得懂的文件,客戶的業務流程著手,客戶確認後,再將其轉換為技術性文件,一方面客戶比較願意確認簽字,作為驗收功能的依據,一方面減少雙方的誤解與無法驗收的風險。

內容重點:

  • 系統目標
  • 系統功能架構圖
  • 系統介面
  • 操作概述與使用者劇本(Scenario)
  • 功能性需求(Functional Requirements)
  • 非功能性需求(Non-Functional Requirements)
  • 設計限制(Design Constraint)

三、系統設計

1.設計文件的撰寫、審查與確認。2.考慮不同的設計架構、選擇與決策。3.考慮各模組元件取得的方式(全新開發、使用先前的元件、委外、購買現成品)。4.程式發展的順序(系統建構的順序)。5.文件內容重點:

  • 系統功能架構圖
  • 模組/單元功能規格包含:每個功能的流程敘述(Scenario)、介面(畫面)的設計(Input /Out畫面)
  • 公用模組/功能規格
  • 相依性說明
  • 模組整合程序
  • 設計影響和限制
  • 資料庫結構(Data Base Schema)

四、程式開發

1.程式撰寫的標準規範Coding Standard2.模組與程式開發的順序3.程式Code Review:

  • 先請資深人員撰寫各種類型程式,透過程式Code Review讓資淺人員認知撰寫方式與標準。
  • 針對資淺人員撰寫的第一支程式,立刻作Code Review,以便立刻糾正與減少失誤程度。
  • 針對核心模組與關鍵模組作Code Review,以降低缺失Bugs。
  • 程式撰寫過程中,專案經理可以透過每日的定時存檔於指定的工作區來管理程式異動。
  • 程式撰寫同時,製作單元測試 Test Case,同仁採行交互測試。
  • 將測試記錄與Bug分類記錄。如果採用適當的Bug Control System記錄,以便追蹤與缺失原因分類,並可用來預防未來專案缺失的發生。

五、系統安裝與測試

1.系統測試計畫 包含:

  • 系統測試環境:測試環境架構圖、軟體需求、測試工具
  • 測試項目定義:測試項目、測試特徵與非測試特徵、測試方法
  • 軟體測試管理:專案組織/人員與權責、規劃時程與工作產品
  • 測試程序:測試允入準則、測試允出準則、暫停與重新開始原則
  • 記錄/報告之流程

2.測試案例與資料準備包含:

  • 測試設計規格:測試項目定義、細部測試方法
  • 非功能性測試:一致性(Compatibility)、效能測試(Performance)、壓力測試(Stress Testing)、迴歸測試 ( Regression Testing )
  • 測試識別Identification
  • 測試個案規格

六、教育訓練

客戶教育訓練規劃包含:1.上課的單位、人數、雙方負責人及上課通知。2.教育訓練課程/項目、教育訓練進行方式、訓練的次數/場次、是否需要測驗。3.訓練的時間表/時數。4.上課地點。5.上課設備與環境:H/W & S/W環境、教具(投影機…)、網路、周邊設備( Printer、POS.. )。6.上課的講議/教材與份數。7.上課記錄與訓練調查表(Training Feed Back Form)或報告。七、上線驗收階段

1.客戶上線驗收可能方式可能有:

  • 平行上線
  • 分批上線 因此需要與客戶就系統上線與驗收方式討論,雙方如何進行與配合的事項,特別是客戶系統使用時是安裝在全省各據點,或大陸等海外地區。因此系統的安裝與測試地點的選擇,配合的事項需要非常明確列出與確認。在此情況下,通常是訓練客戶安裝與測試的種子團隊/教官,由此種子團隊/教官負責驗收後客戶自行全面的佈置與推展的任務,我方作第二線技術支援。

2.必要時擬訂獨立的上線驗收計畫:包含:

  • 雙方驗收負責主持人,負責驗收的 "相關單位" 與各單位代表人/負責人
  • 驗收進行方式(一次全驗或分批驗收)
  • 驗收進行的地點與單位
  • 交貨方式與點收
  • 驗收啟動與進行之程序如:•驗收時間•驗收的Cycle (從 issue 驗收到 close)期程•第二次驗收時間(未通過項目)
  • 客戶需要準備配合事項與驗收測試資料
  • 驗收環境與驗收相關的設備
  • 驗收項目(驗收清單/表單)與合格規範/條件(不合格規範),何種狀況為合格?何種狀況為不合格?
  • 不合格事項之處理方法與改善處理方式
  • 系統驗收合格條件:如系統上線三個月(Or一個月)無問題即視為驗收合格等
  • 系統上線期間問題處理方式;客戶問題清單的提出、由誰提出、提出的方式
  • 驗收記錄與報告

八、結案

本階段兩項作業:1.結案報告與結案會議專案經理需要將整個專案執行過程,作一個總結報告。除了專案執行過程的統計資料與分析外,主要的目的是提出專案執行過程中:

  • 值得組織參考的經驗或典範,作為經驗分享
  • 執行過程中發生的缺失,原因與未來如何預防的建議
  • 執行過程中所發生的風險與處理過程
  • 改善建議事項

2.專案資料的備份與歸檔

  • 專案結案需要專案執行過程中,所有資料與文件的最終版本,記錄與報告,軟體程式原始碼Source Code、軟體程式執行碼、Object Code、Set-Up程式等壓成CD備份。
  • 專案開發的環境(OS,開發工具)與測試環境,測試工具壓成CD備份
  • 當保固期滿,相同的方式處理,備份兩套
  • 上述項目建議備份兩套,一套存放在不同的地點

九、系統維護與保固

規劃保固計劃或維護計畫。包含:

  • 保固維護的責任範圍(包含負責的工作項目與工作地點)、軟體的Bugs、Bug所產生的損害、資料庫資料整理、整救(Crash處理管理、資料庫維護與管理DBA。
  • Bugs的定義與界定、功能瑕疵的定義與界定、保固維護進行的方式、On-Site Support、On-Call Support、Mail Support…等
  • 服務的方式與問題的提出方式(問題記錄單,Mail or 電話)
  • 問題的提出者與接收者
  • 問題反應與回覆時間
  • 問題解決的方式與期限
  • 服務的時間(如:上班時間;08:30 AM - 18:00 PM,假日除外)
  • 收費項目與計費方式(不是免費服務的項目、如出差、非上班時間工作、非責任範圍的工作、因客戶人為疏失造成的系統問題、非人力所能控制造成的損失…)
  • 保固期限、保固期起算點
  • 保固責任的地點
  • 保固期滿後的服務方式、軟體系統維護合約
  • 需求功能/設計功能/表單等,因業務活動的變動,需要新增或修改軟體時的處理方式(如:由何人提出、確認、報價/計費、驗收、文件修改..)
top
 
談從CMMI V1.1 到 CMMI V1.22007-08-17

談從CMMI V1.1 到 CMMI V1.2

■甄 敏

前言

正如同 CMMI V1.1 的推出是基於使用者對於SW-CMM 改善的需求,在CMMI 推行過程中,SEI 也持續收集各方意見,作為CMMI 改版的基礎。預計在2006年底推出的 CMMI V1.2 內容沒有重大改變,主要是整合了階段式及連續式表述,以Mary Beth Chrissis, Mike Konrad and Sandy Shrum 所著的 "CMMI Guidelines for Process Integration and Product Improvement (Addison-Wesley, 2003) "為主要的素材,納入新領域(例如,服務、採購)於模型架構的最佳執行方法中,增加硬體相關的範例及強化流程領域內對於採用不同專業領域時的特別說明(amplifications)。

CMMI 現況

自從2000年開辦CMMI簡介課程以來,已培訓300位SEI授權講師,上課人數超過四萬人。培訓400多位SEI授權之主評鑑員,全球六大洲超過1000件SCAMPISM評鑑案件。現行CMMI 1.1 版套裝產品發行於2002年一月。很多SW-CMM的使用者也成功整合到CMMI,SW-CMM及相關產品(如CBA IPI及SCE)已於2005年底功成身退,從CBA IPI 及SCE 評鑑來的SW-CMM評鑑結果也將於2007年底到期。關於CMMI 的導入成效,SEI收集分析30家導入CMMI組織之成果報告,公告在SEI網站http://www.sei.cmu.edu/cmmi/results.html

從CMMI V1.1 到 CMMI V1.2 - 重要事項時間表

When
What
How
2006年8月 CMMI V1.2 套裝產品 計劃於此時發行

2006年8月CMMI V1.2 發行後開始CMMI V1.1 改版升級期開始
  使用新舊版混合的CMMI模組及評鑑方法在改版升級期是有效的,若其中一種是V1.1版,就會被認定為是V1.1的評鑑。
2006年12月底CMMI V1.1 簡介課程(分段式與連續式)落幕
2007年1月起CMMI V1.2簡介課程只提供整合了分段及連續表述式的單一版CMMI課程
  V1.2版CMMI簡介的升級課程授課對象有CMMI簡介課程的講師,SCAMPI主評鑑員及曾上過簡介課程的學員。升級課程內容將再擇期公告。
2007年12月底前CMMI V1.1 改版升級期結束
2008年1月起SCAMPI評鑑必須只使用V1.2版CMMI模組及V1.2版SCAMPI方法
  使用V1.1版CMMI模組或V1.1版SCAMPI方法所做的SCAMPI評鑑將不被認可為有效的組織性評鑑或取得主評鑑員的持續認證。
  SCAMPI Class A評鑑效期正式制定最多為三年,評鑑結果會隨時間而過期無效。SEI會在組織單位通過評鑑滿兩年的時候,提醒要在評鑑結果失效前,再規劃新的評鑑。
  所有V1.1 SCAMPI Class A評鑑的名單, 將於評鑑完成日三年後或V1.2版發行後一年(擇較晚之日期),從SEI『評鑑結果公告』的網站上移除。

CMMI套裝產品V1.2 新版內容

CMMI套裝產品V1.2計劃於2006年8月發行,雖無重大改變,然新版內容將包含如下:

一、Model Improvements

模組改善項目---

  • incorporating a model architecture that accommodates the expansion of best practices into new areas (e.g., services, acquisition)納入適用於從最佳執行方法擴展至新領域(例如,服務、採購)的模型架構
  • releasing CMMI in a single-book format that reflects both the staged and continuous representations 發行整合CMMI分段式及連續式兩種表述式的合訂本
  • eliminating the concepts of advanced practices and common features 刪除進階執行方法與共同特性的觀念
  • simplifying the integrated product and process development (IPPD) material 簡化整合的產品與流程發展資料
  • incorporating the supplier sourcing (SS) extension into the base model 納入供應商委外延伸在基礎模型中
  • adding hardware-related examples 增加硬體相關的範例
  • amplifications improved改善流程領域內對於採用不同專業領域時的特別說明

二、SCAMPI Appraisal Method Improvements

SCAMPI評鑑方法改善項目---

  • removing the requirement for instruments (e.g., surveys) 移除對執行方法(例如,調查表)的要求
  • adding guidance on how to characterize alternative practices 增加如何描述替代性執行方法的導引
  • setting limits for the maximum length of appraisals 限制評鑑最長期限
  • defining requirements for sampling and incremental appraisals 定義採樣式與漸進式評鑑的要求
  • expanding the scope of readiness reviews to include the readiness of the organization, the team, and logistics 擴大備審查的範圍,納入組織、團隊及後勤的備審查
  • requiring the appraisal sponsor's signature on the Appraisal Disclosure Statement 要求評鑑贊助人在Appraisal Disclosure Statement上簽署
  • limiting the validity of appraisal results to a maximum of three years 限定評鑑結果的最長效期為三年

三、Training Improvements

教育訓練改善項目---

  • updating course materials to reflect changes in CMMI models and appraisal method 更新課程教材,以與CMMI模型及評鑑方法的變動相呼應
  • improving the clarity and consistency of the course materials 改善課程教材的明確性與一致性

四、流程領域對照

根據目前的資料顯示,CMMI V1.2 中部分流程領域的特定目標與特定執行方法有部分的變動如下:

1.Mturity Level II 成熟度第二級

  • Supplier Agreement Management 供應商合約管理
CMMI V 1.1
CMMI V 1.2
SG 2 Satisfy Supplier Agreements滿足供應商協議
SP 2.1-1 Review COTS Products審查市面上所售商品
SP 2.2 Monitor Selected Supplier Processes 監督選擇的供應商流程

2.Maturity Level III 成熟度第三級

  • Requirement Development 需求發展
CMMI V 1.1
CMMI V 1.2
SG 1 Develop Customer Requirements發展客戶需求
SP 1.1-1 Collect Stakeholder Needs收集相關關鍵人士的需求
  
SG 3 Analyze and Validate Requirements分析及確認需求
SP 3.5-1 Validate Requirements with comprehensive methods.用廣泛的方法確認需求
  
  • Technical Solution 技術解決方案
CMMI V 1.1
CMMI V 1.2
SG 1 Select Product-Component Solutions選擇產品組件解決方案
SP 1.1-2 Develop Detailed Alternative Solutions and Selection Criteria對所選擇的標準條件展開詳細的替代解決方案
  
SP 1.2-2 Evolve Operational Concepts and Scenarios展開操作觀念及情境
  
SP 2.3-1 Establish Interface Descriptions 建立介面描述
  
  • Organization Process Definition 組織流程定義
CMMI V 1.1
CMMI V 1.2
SG 1 Establish Organizational Process Assets建立組織流程資產
  
SP 1.6 Establish Work Environment Standards 建立標準工作環境
    
SG 2 Enable IPPD Management促成 IPPD 管理
  
SP 2.1 Establish Empowerment Mechanisms 建立授權機制
  
SP 2.2 Establish Rules and Guidelines for Integrated Teams建立整合團隊的規則及指引
  
SP 2.3 Establish Guidelines to Balance Team and Home Organization Responsibilities 建立在專案團隊及原屬組織之間責任平衡的指導原則
  • Integrated Project Management 整合的專案管理
CMMI V 1.1
CMMI V 1.2
SG 1 Use the Project's Defined Process
  
SP 1.3 Establish the Project's Work Environment建立專案的工作環境
SG 3 Use the Project's Shared Vision for IPPD使用專案共同的看法
SG 3 Apply IPPD Principles

適用 IPPD 原則

SP 3.1-1 Define Project's Shared-Vision Context定義專案共同願景的範圍
SP 3.1 Establish the Project's Shared Vision建立專案的共同看法
SP3.2 Establish the Project's Shared Vision建立專案的共同願景
SP 3.2 Establish Integrated Team Structure for the Project建立專案的整合團隊架構
  
SP 3.3 Allocate Requirements to Integrated Teams配置對於整合團隊的需求
  
SP 3.4 Establish Integrated Teams建立整合團隊
  
SP 3.5 Establish Coordination among Interfacing Teams建立整合團隊之間的拹同互動
SG 4 Organize Integrated Teams for IPPD 組織IPPD的整合團隊
  
SP 4.1-1 Determine Integrated Team Structure for the Project決定專案的整合團隊架構
  
SP 4.2-1 Develop a Preliminary Distribution of Requirements to Integrated Teams展開對於整合團隊需求的基本描述
  

結語

2007年12月底前 CMMI V1.1 改版升級期結束,2008年1月起SCAMPI評鑑必須只使用V1.2版CMMI模組及V1.2版SCAMPI方法。SCAMPI Class A評鑑效期正式制定最多為三年,評鑑結果會隨時間而過期無效。所有V1.1 SCAMPI Class A評鑑的名單, 將於評鑑完成日三年後或V1.2版發行後一年(擇較晚之日期),從SEI『評鑑結果公告』的網站上移除。CMMI 導入公司預計在2008年1月以後接受評鑑者,建議都宜及早規劃在導入過程中納入V1.2 相關適用的流程規範,以便有充分的準備接受評鑑。參考資料

1."Sunsetting Version 1.1 of the CMMI Product Suite", SEI, January 3, 20062.Translation of "Sunsetting Version 1.1 of the CMMI Product Suite", SPIN Taiwan - http://72.14.203.104/search?q=cache:4yDPHy6HqfoJ:www.cmmi.org.tw/SPIN/CMMI20060119.htm+%22CMMI%22%2B%22Version%22%2B%221.%22&hl=zh-TW&gl=tw&ct=clnk&cd=13."CMMI Version 1.2 and Beyond" ,Mary Beth Chrissis and Jack Ferguson,

top
 
工程品質有效管控-論審查(Review)與CMMI2007-08-17

工程品質有效管控-論審查(Review)與CMMI    

■ 甄 敏

前言

軟體系統開發的需求了解、系統分析/設計到完成驗收的過程中,能夠對期間所產生的重要工作產品及最終完成產品加入驗證(Verification)和確認(Validation)機制是提高產能及管控品質的重要環節。

驗證通常是漸進式的流程,由產品組件的驗證開始,最後是組合完成之產品的驗證。 CMMI 驗證流程領域中談到的驗證(Verification)方法包括(但不限於)檢查(Inspection)、同仁審查(Peer Review)、稽核(Audit)、逐步審查(walkthroughs)、分析(analyses)、模擬(simulation)、測試(testing)及展示(demonstrations)。對於不同工作產品/產品組件有不同驗證方式。在何時對於哪種工作產品要採用何種驗證方法必須及早進行規劃及準備。

CMMI將檢查(Inspection) 和結構化逐步審查(structured walkthroughs) 都歸類成同仁審查(Peer Review)的不同型式。CMMI使用「同仁審查(peer review)」,而不使用「工作產品審查(work product review)」。本質上,這兩個術語的意義是相同的。「同仁審查」是強調在工作產品發展期間,由工作同仁對工作產品所執行的審查,用以界定須移除的缺失。

審查(Review)的意義和目的

所謂旁觀者清,當局者迷,審查是一種工程品質控制的方法,藉由作者以外的人來找到工作產品乃至最終產品的缺失並改進。從審查的英文名稱 REVIEW 由RE加上VIEW組成,也可以了解審查是藉由冷靜清楚的重新審視工作產品/產品來發現及改正缺失,聚合共識。

在產品發展與維護時及早移除缺失,並對發展與維護中的工作產品和產品組件,提供有用和深入的瞭解。

下面參考資料說明在軟體/系統專案流程生命週期中,在缺陷發生後及早發現及修正缺陷會比到後續階段才發現所付出的成本要低廉得多。

缺陷分布階段
相對的修正成本
  需求階段 - 57%  設計階段 - 27%  編碼階段 - 7%  其它   - 9%  X  X * 10  X * 100  X * 1000 依此類推

審查也可當成一個訓練場所,使年輕專案成員能夠觀察學習不同的軟體分析,設計和實施方法。也促進備位接替及連續性,很多其他人因此得以熟悉他們原本不可能接觸軟體的部分。

審查(Review)的種類

審查的種類、名稱及定義繁複,眾說紛紜,在 Karl E. Wiegers 所著的 "Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002)"書中依照審查程序的嚴謹度從高到低分成下列幾類:

  • 檢查/檢驗(inspection)
  • 團隊審查(team review)
  • 逐步審查(walkthrough)
  • 配對程式開發(pair programming)
  • 同仁桌上檢查 (peer desk check, passaround )
  • 特定的審查(ad hoc review)

CMMI 在驗證流程領域特定執行方法SP2.1 中,則對於審查方法舉了三種例子:

  • 檢查 (Inspections)
  • 結構化逐步審查 (tructured walkthroughs)
  • 有效審查(Active reviews)

審查(Review)的方式

由於審查活動的方法及內容繁複,將在未來的篇幅中陸續對不同種類的審查分別予以介紹。無論採取哪一種審查方式,都須考慮納入CMMI所一再強調的制度化/使約定俗成化(Institutionalize)所須注意的事項:

  • 建立組織政策(GP 2.1)
  • 規劃流程(GP 2.2)
  • 提供資源(GP 2.3)
  • 指派責任(GP 2.4)
  • 訓練人員(GP 2.5)
  • 管理建構(GP 2.6)
  • 界定並納入相關的關鍵人員(GP 2.7)
  • 監控流程(GP 2.8)
  • 客觀評估遵循程度(GP 2.9)
  • 與上層管理人員審查各種狀況(GP 2.10)
  • 建立已定義流程 (GP 3.1)
  • 蒐集改善資訊 (GP 3.2)

結語

由於同仁審查是重要而且經過證實有效的工程方法,經由檢查、結構化逐步審查或其他適合的審查方式來執行。所以實施同仁審查在CMMI驗證流程領域中特別被提出列為一項特定目標(Specific Goal - SG)並有其特定的執行方法來配合說明;建議要達到能力成熟度第三級的組織宜參考並且納入組織及專案流程活動中。

top
 
可取徵才Career at Coach TM
top