可取科技管理股份有限公司

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.

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

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

■黃叔敏

前言

企業中任何一個組織的作業活動，通常可以分為日常管理作業與專案管理作業，而組織中的所有成員每天都在參與這兩項作業活動。隨著環境演變，專案管理作業項目所佔的份量越來越大，企業中大部份組織部門的作業活動中超過 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