軟體項目開發，全系列規範及約束文件

02-12

軟體開發，過程與思想

計算機軟體尤其是資料庫軟體，成為了當代計算機應用的主流。因此軟體開發人員就

必須掌握正確的開發手段，了解軟體開發的主要過程，這樣心中對軟體項目才有清醒的認

識，才能達到事半功倍的效果。本文就軟體開發過程中的一些方法，結合本人開發過的一

些軟體項目做一些詳細論述。

1 開發前的準備工作

一般軟體項目在開發前都有系統任務書，主要規定軟體的開發目標、主要任務、功能

、性能指標及研製人員和經費、進度等安排，作為系統設計開發和檢驗的基本依據。

系統任務書的基本框架如下：

（1）引言

包括編寫目的，背景，參考資料。

（2）系統的目標及任務

包括系統建設目標，系統的主要任務，系統性能指標，系統標準化要求。

（3）系統的結構及功能

包括系統應用組成及結構，系統主要功能。

（4）系統的規模及進度要求

包括系統規模，系統研製進度，人員計劃。

但是系統任務書只是這個軟體項目的一個基本要求，針對具體情況，軟體開發人員和

需求分析人員就要聯合對軟體項目的細節進行具體分析，必要時還要進行實地調研，然後

共同商討寫出系統的需求分析，需求分析的編寫目的在於：

說明系統在軍事方面、技術方面、經濟方面和社會條件方面實現的可行性和必要性；

分析原系統（工作環境）現狀,描述待開發系統的詳細需求，提供用戶和開發人員之間溝通

的基礎，提供項目設計的基本信息。

需求分析報告的基本框架如下：

（1）概述

包括編寫目的，背景，參考資料，術語及縮寫詞。

（2）對現有系統的分析

（3）待開發系統的詳細需求

包括功能需求，使用範圍，業務流程，用戶界面，輸出要求，故障處理。

（4）使用環境

包括網路環境，硬體環境，軟體環境，與其他系統的關係，安全與保密。

（5）可行性分析

包括可行性分析，經濟可行性分析，人員可行性分析，影響待開發系統的主要因素。

（6）結論意見

2 軟體開發過程

有了系統任務書和需求分析報告，軟體設計人員就要對軟體項目的實現進行系統分析，系統分析包括系統的總體方案，系統的設計說明，作為軟體設計的依據。具體說明如下

2.1 系統總體方案

在系統開發單位和用戶充分交互、理解的基礎上，提出系統的技術構架，對系統功能

、性能等主要指標作描述，對實現方法和要求作規定，是系統進行詳細設計的依據。

系統總體方案基本框架包括：

（1）引言

包括：編寫目的，背景，參考資料，術語及定義。

（2）項目概述

包括：

--項目的主要內容

--系統需求分析：①用戶需求調查分析②現行系統的現狀調查分析。

--系統功能：①系統的功能要求②系統主要技術性能。

--系統的數據要求：①基礎數據②業務數據③交換數據④其它數據。

--系統的設計要求：①技術結構要求②系統劃分及其介面要求③系統運行環境要求④

系統標準化綜合要求。

（3）實施總計劃

包括：進度，預算，問題和措施。

2.2 系統設計說明

根據《系統總體方案》提出的系統構架、功能、性能及數據要求，確定系統的物理結

構，說明系統主要技術方面的設計和採用的技術方法以及系統的標準化約束等，是系統實

施的基本依據。就本人曾經開發過的一個軟體項目，說明其基本框架：

（1）引言

包括：編寫目的；背景；條件和限制；參考資料；術語及定義。

（2）系統總體技術方案

包括：

--概述：①系統目標②基本要求。

--系統設計：

①系統結構

a、應用結構。

b、功能結構。

c、技術結構。

② 系統功能設計：根據以上的分析，功能設計自然

包括業務管理功能設計、綜合查詢功能設計、郵件收發功能設計、資料庫介面設計、

文電介面設計。在對這些功能進行綜合分析的基礎上，開始進行資料庫表的設計。在對錶

的設計過程中，既要考慮到關係資料庫冗餘欄位的處理，又要考慮到系統運行的速度和實

現的方便性等綜合因素，筆者在實際開發後認為這兩種考慮比例可以為7：3。

③系統安全設計：可以考慮以下一些安全設計思想，例如系統的數據傳輸通過電子郵件實現

，要求電子郵件內部只傳代碼，不傳涉密數據；系統的資料庫操作需要充分利用Oracle數

據庫的事務提交和回滾機制，確保業務處理的完整性和一致性；系統的數據結構應充分利

用存儲空間，在不同的用戶之間通過數據冗餘提高整個系統的數據安全性；系統中存貯的

用戶口令、備份口令、資料庫連接信息等重要數據，必需經過安全加密。

④Oracle資料庫自動優化設計：對於Oracle資料庫可以進行資料庫配置，可以大大提高大數

據量查詢速度，筆者已經做過嘗試，並已經成功應用。

⑤ 友好界面設計：對於一個良好的應用系統當然需要設計良好的使用界面。

2.3 軟體開發

對於開發語言的選擇因人而易，開發資料庫系統我比較傾向於DELPHI，因為它對於數

據庫開發的支持是很完善的。在軟體實現方面，上面已經說明了一種客戶/伺服器結構，但

是這種結構本身也包含了一些問題，例如客戶/伺服器結構經常把應用系統的企業邏輯編寫

在客戶端的應用程序中，因此當應用系統需要改變時，所有在客戶端的應用系統都必須改

變，這對於MIS系統的維護來說成本太高了；為了解決這些重複開發應用系統的成本以及為

了增加應用系統的重複使用性發揮面向對象分析/面向對象設計的功能，就必須導入所謂的

應用程序伺服器，軟體開發人員以一種特定的組件形式，例如Microsoft的COM/DCOM，CORB

A對象，或是Enterprise Java

Bean等，組裝企業的邏輯程序代碼。這種經過組裝，能夠執行特定企業功能的對象便稱為"

企業對象"，然後把這些企業對象分發到此應用程序伺服器。由於本文不是專門討論多層系

統的文章，所以只是簡單提一下，不再贅述。

程序設計中要注意合理的程序設計結構，可以將所有的公用組件放在一起。例如Delph

i語言中可以新建一個單元，將所有編寫的函數放在這個單元里，其他單元均可以調用，還

可以新建一個數據模塊（Datamodule）,將所有的公共資料庫控制項放在這裡，可以減少系統

資源浪費，優化資料庫程序設計。

關於程序設計中的技巧很多，這裡也不再贅述。

3 軟體開發後的工作

軟體項目在開發完成後還要進行系統測試，以測試開發出的軟體的功能和性能是否達

到預定要求。項目成功九要素

一般來說，項目完成了既定目標，滿足了項目三要素：時間進度、成本控制、質量要求，

就可以認為項目是成功的。但有時候項目的成果被顧客接受就可以認為成功。比如在 IT行

業里，產品研發突破原定時間、成本要求的情況非常普遍，但是如果最終項目得以技術實現，

而且被顧客接受，也算做成功。不過，企業還是應該根據自己的實際情況制定有利於企業發

展的項目成敗標準，比如項目延期不超過 30%進度算達標這樣的指標。

對於投資類項目，所謂"項目成功"具有不同的判別標準，項目本身實現只是一個方面，

項目產生的經濟收益，社會影響，環境影響等都會成為評價項目成功程度的指標。研發類項

目通常已通過項目的客戶驗收為成功的標誌點，投資類則不限於此，可能會在項目完工並運

行一段時間（比如 2年）後進行項目後評價環節，在項目的後評價中最後給出項目成敗的最

終評判。

達到項目成功的方法

項目的成敗受到四個方面的影響，即項目組內環境、項目所處的組織環境、客戶環境、

自然社會環境。從可控角度，通常需著重考慮前三個方面。把前三個方面放在整個項目生命

周期進行考察，可以得到影響項目成敗的因素。

以下從項目運行環境、項目計劃、項目監控及項目溝通、過程改進和技術革新、項目經

理素質等幾個方面總結獲得項目成功的方法。

要素一、良好的項目運行環境

1）流程：

最遲在項目啟動的前期，應該定義一套適合於具體項目的流程體系，這是項目成功的制

度化保證。使流程得到不斷優化，使用最簡的優化流程。

2）組織機構：

選擇合適的項目管理組織架構，以及團隊成員選擇，建立激勵考評機制。在同一個管理

平台上並行運作多個項目的組織，傾向於選擇矩陣式結構；對於項目期限特別長的專項投資

項目也可能選用純粹項目管理模式；項目存在多個子項目組的複雜協調，且項目存在比較大

的技術瓶頸的項目宜選擇強矩陣式，就是有一個全職的項目經理承擔管理性工作，以使技術

經理把大部分經理花在攻克技術難關上。

"人"是項目成功的最關鍵因素，選用具備必要技能、能與小組很好融合、具有強的責

任心和事業心的成員進入小組，將極大的促進項目的成功。

把責任、績效與獎勵捆綁在一起，實施目標管理，採取必要的激勵措施。一套行之有效

的激勵考評體系將極大調動團隊成員的積極性。

3）內部支持環境

多數情況下，項目組織並不作為一個單獨的經濟實體存在，它依託於特定的管理平台。

相對於外部客戶來說，這屬於內部支持環境。理順項目運行內環境的內容包括，彙報渠道、

財務聯繫、人力資源以及公司內部其它職能管理機構的聯繫。

要素二、強將手下無弱兵

項目經理是項目的靈魂人物，項目經理的素質包括在業務和技術和管理三個方面不斷提

升自己、領導能力、市場與客戶意識、還要特別關注團隊文化的建設。

一個成功的項目經理應該倡導有魅力的團隊文化。現代社會，人們對工作賦予了更多的

精神需求。一個有魅力的團隊文化應該包括認可和尊重、自信和信任、分工協作的良好平衡、

愉快和上進的氣氛、遵守共同規範、多層次交流和溝通等。好的團隊文化最終達到吸引人才、

留住人才、激勵人才的作用。

要素三、計劃先行

"凡事預則立，不預則?quot;講的就是項目策劃的重要性。項目策劃的結果是形成文檔

化的項目計劃。策劃階段是很容易被忽視的階段，任務書下達後，匆匆忙忙投入到項目中

往往為項目的挫折甚至失敗埋下了伏筆。項目計劃應該包括項目內容、時間進度、預算、需

要的各方面支持性條件，項目風險預測等。

需要特彆強調的是計劃是個動態過程，一定要進行維護，否則計劃就名存實亡了。對於

不確定性很大的活動可以把計劃制訂的粗一點，然後隨著項目的推移周期性的滾動細化，這

就是所謂的"滾動式計劃方法"，應用此法，可有效的減少計劃的維護量。總之，即使"計劃

趕不上變化"，但一定要"跟上變化"。

仔細鑒別獲取的項目基本數據，儘可能進行量化估計將使得計劃更加客觀科學。項目基

本數據可能包括以往進行類似項目的工作量數據、效率數據、WBS（工作分解結構）等。

要素四、對控制點進行有力度的管理

使目標管理和過程管理相結合。過程管理要求有適當的方法提供項目的透明度，消除"

項目黑箱"。所謂"項目黑箱"就是管理者只關心和只能了解到項目的輸入和輸出，項目的運

作過程不了解，項目缺乏控制。這種狀況會帶來很大的風險，一旦項目運行存在偏差，只能

在項目完成後被發現，大大增加了糾偏的難度，甚至已無法糾正。項目的監控大致按照如下

的四個步驟執行：獲取項目過程信息、分析判斷、採取糾偏措施、驗證。

要素五、交流通暢

項目計劃、進度和項目範圍必須能夠被項目成員方便的得到，以確保大家是在統一的平

台上朝者同一個目標前進。為此，需要建立必要的內部郵件系統或採用適當的圖表和模版以

增強溝通效果。

要素六、實事求是的決策

項目運作的過程時刻要記的不要脫離實際，包括各級計劃的制定和決策過程中，"頭腦

發熱"或"市場壓力"形成的不切實際的項目計劃往往從計劃那一刻就註定要失敗的。

此外還應該注意，並不是好的東西就一定適合於自己的項目。時髦的理念、新穎的方法、

流行的工具並不一定會對項目的成功起促進作用。項目經理一定要對項目所處的內外環境有

冷靜的認識。

要素七、確保項目平穩運作

雖然存在不同項目管理者的管理風格差異，但是總體來說，在項目中引入大的變革盡量

要採取漸進的方式。這包括過程的改進、新技術的引進和組織架構調整等。類似的變革應該

進行足夠的影響分析。必要時，可以進行試點和評估，然後再大面積引進。

要素八、項目管理人員責權對等

責權對等是管理學的基本原則。之所以會出現責權不匹配的情況，多數是因為，上級管

理者不能信任下屬的能力和做到有效授權。項目出現問題進行檢討時，往往才發現項目經理

並不能對所出現的問題負責，問題的根源往往是高層經理在信息不完整的情況下做出的決策

造成的。

要素九、項目委託方的密切配合

項目委託方顯然對項目的成功負有一定的責任，特別是項目需求分析階段。多數項目都

應該任命委託方項目經理，明確合同雙方的責任，對於項目前期的工作給予密切的協作。

那些到了項目驗收時才關注項目的業主態度是危險的。

項目成功的 12個關鍵原則

1、項目經理必須關注項目成功的三個標準

簡單地說，一是準時；二是預算控制在既定的範圍內；三是質量得到經理和用戶們的贊

許。項目經理必須保證項目小組的每一位成員都能對照上面三個標準來進行工作。

2、任何事都應當先規劃再執行

就項目管理而言，很多專家和實踐人員都同意這樣一個觀點：需要項目經理投入的最重

要的一件事就是規劃。只有詳細而系統的由項目小組成員參與的規劃才是項目成功的唯一基

礎。當現實的世界出現了一種不適於計劃生存的環境時，項目經理應制定一個新的計劃來反

映環境的變化。規劃、規劃、再規劃就是項目經理的一種生活方式。

3、項目經理必須以自己的實際行動向項目小組成員傳遞一種緊迫感

由於項目在時間、資源和經費上都是有限的，項目最終必須完成。但項目小組成員大多

有自己的愛好，項目經理應讓項目小組成員始終關注項目的目標和截止期限。例如，可以定

期檢查，可以召開例會，可以製作一些提醒的標誌置於項目的場所。

4、成功的項目應使用一種可以度量且被證實的項目生命周期

標準的信息系統開發模型可以保證專業標準和成功的經驗能夠融入項目計劃。這類

模型不僅可以保證質量，還可以使重複勞動降到最低程度。因此，當遇到時間和預算壓力需

要削減項目時，項目經理應確定一種最佳的項目生命周期。

5、所有項目目標和項目活動必須生動形象地得以交流和溝通

項目經理和項目小組在項目開始時就應當形象化地描述項目的最終目標，以確保與

項目有關的每一個人都能記住。項目成本的各個細節都應當清楚、明確、毫不含糊，並確保

每個人對此都達成了一致的意見。

6、採用漸進的方式逐步實現目標

如果試圖同時完成所有的項目目標，只會造成重複勞動，既浪費時間又浪費錢。俗

話說，一口吃不成個胖子。項目目標只能一點一點地去實現，並且每實現一個目標就進行一

次評估，確保整個項目能得以控制。

7、項目應得到明確的許可，並由投資方簽字實施

在實現項目目標的過程中獲得明確的許可是非常重要的。應將投資方的簽字批准視

為項目的一個出發點。道理很簡單：任何有權拒絕或有權修改項目目標的人都應當在項目啟

動時審查和批准這些項目目標。

8、要想獲得項目成功必須對項目目標進行透徹的分析

研究表明，如果按照眾所周知記錄在案的業務需求來設計項目的目標，則該項目多

半會成功。所以，項目經理應當堅持這樣一個原則，即在組織機構啟動項目之前，就應當為

該項目在業務需求中找到充分的依據。

9、項目經理應當責權對等

項目經理應當對項目的結果負責，這一點並不過分。但與此相對應，項目經理也應

被授予足夠的權利以承擔相應的責任。在某些時候，權利顯得特別重要，如獲取或協調資源，

要求得到有關的中小企業的配合，做相應的對項目成功有價值的決策等等。

10、項目投資方和用戶應當主動介入，不能被動地坐享其成

多數項目投資方和用戶都能正確地要求和行使批准（全部或部分）項目目標的權力。

但伴隨這個權力的是相應的責任——主動地介入項目的各個階段。例如，在項目早期要幫助

確定項目目標；在項目進行中，要對完成的階段性目標進行評估，以確保項目能順利進行。

項目投資方應幫助項目經理去訪問有關的中小企業和目標顧客的成員，並幫助項目經理獲得

必要的文件資料。

11、項目的實施應當採用市場運作機制

在多數情況下，項目經理應將自己看成是賣主，以督促自己完成投資方和用戶交付

的任務。項目計劃一旦批准項目經理應當定期提醒項目小組成員該項目必須滿足的業務需求

是什麼，以及該怎樣工作才能滿足這些業務需求。

12、項目經理應當獲得項目小組成員的最佳人選

最佳人選是指受過相應的技能培訓，有經驗，素質高。對於項目來說，獲得最佳人

選往往能彌補時間、經費或其它方面的不足。項目經理應當為這些最佳的項目成員創造良好

的工作環境，如幫助他們免受外部干擾，幫助他們獲得必要的工具和條件以發揮他們的才能。

軟體工程的七條基本原理

1、用分階段的生命周期計劃嚴格管理

有人經統計發現，在不成功的軟體項目中有一半左右是由於計劃不周造成的，可見把建

立完善的計劃作為第一條基本原理是吸取了前人的教訓而提出來的。

在軟體開發與維護的漫長的生命周期中，需要完成許多性質各異的工作。這條基本原理

意味著，應該把軟體生命周期劃分成若干個階段，並相應地制定出切實可行的計劃，然後嚴

格按照計劃對軟體的開發與維護工作進行管理。Boehm 認為，在軟體的整個生命周期中應該

制定並嚴格執行六類計劃，它們是項目概要計劃，里程碑計劃，項目控制計劃，產品控制計

劃，驗證計劃，運行維護計劃。不同層次的管理人員都必須嚴格按照計劃各盡其職地管理

軟體開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃。

2、堅持進行階段評審

當時已經認識到，軟體的質量保證工作不能等到編碼階段結束之後再進行。這樣說至少

有兩個理由：第一，大部分錯誤是在編碼之前造成的，例如，根據 Boehm 等人的統計，設

計錯誤占軟體錯誤的 63%，編碼僅占 37%；第二，錯誤發現與改正得越晚，所需付出的代價

也越高。因此，在每個階段都進行嚴格的評審，以便儘早發現在軟體開發過程中所犯的錯誤，

是一條必須遵循的重要原則。

3、實行嚴格的產品控制

在軟體開發過程中不應隨意改變需求，因為改變一項需求往往需要付出較高的代價，但

是，在軟體開發過程中改變需求又是難免的，由於外部環境的變化，相應地改變用戶需求是

一種客觀需要，顯然不能硬性禁止客戶提出改變需求的要求，而只能依靠科學的產品控制技

術來順應這種要求。也就是說，當改變需求時，為了保持軟體各個配置成分的一致性，必須

實行嚴格的產品控制，其中主要是實行基準配置管理。所謂基準配置又稱基線配置，它們

是經過階段評審後的軟體配置成分（各個階段產生的文檔或程序代碼）。基準配置管理也稱

為變動控制：一切有關修改軟體的建議，特別是涉及到對基準配置的修改建議，都必須按照

嚴格的規程進行評審，獲得批准以後才能實施修改。絕對不能誰想修改軟體（包括尚在開發

過程中的軟體），就隨意進行修改。

4、採用現代程序設計技術

從提出軟體工程的概念開始，人們一直把主要精力用於研究各種新的程序設計技術。60

年代末提出的結構程序設計技術，已經成為絕大多數人公認的先進的程序設計技術。以後又

進一步發展出各種結構分析（SA）與結構設計（SD）技術。實踐表明，採用先進的技術既可

提高軟體開發的效率，又可提高軟體維護的效率。

5、結果應能清楚地審查

軟體產品不同於一般的物理產品，它是看不崢摸不著的邏輯產品。軟體開發人員（或開

發小組）的工作進展情況可見性差，難以準確度量，從而使得軟體產品的開發過程比一般產

品的開發過程更難於評價和管理。為了提高軟體開發過程的可見性，更好地進行管理，應該

根據軟體開發項目的總目標及完成期限，規定開發組織的責任和產品標準，從而使得所得到

的結果能夠清楚地審查。

6、開發小組的人員應該少而精

這條基本原理的含義是，軟體開發小組的組成人員的素質應該好，而人數則不宜過多。

開發小組人員的素質和數量是影響軟體產品質量和開發效率的重要因素。素質高的人員的開

發效率比素質低的人員的開發效率可能高几倍至幾十倍，而且素質高的人員所開發的軟體中

的錯誤明顯少於素質低的人員所開發的軟體中的錯誤。此外，隨著開發小組人員數目的增加，

因為交流情況討論問題而造成的通信開銷也急劇增加。當開發小組人員數為 N時，可能的通

信路徑有 N（N?/FONT>1）/2條，可見隨著人數 N的增大，通信開銷將急劇增加。因此，組

成少而精的開發小組是軟體工程的一條基本原理。

7、承認不斷改進軟體工程實踐的必要性

遵循上述六條基本原理，就能夠按照當代軟體工程基本原理實現軟體的工程化生產，但

是，僅有上述六條原理並不能保證軟體開發與維護的過程能趕上時代前進的步伐，能跟上技

術的不斷進步。l因此，Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程

的第七條基本原理。按照這條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷

總結經驗，例如，收集進度和資源耗費數據，收集出錯類型和問題報告數據等等。這些數據

不僅可以用來評價新的軟體技術的效果，而且可以用來指明必須著重開發的軟體工具和應該

優先研究的技術

軟體工程式控制制的重要性

軟體開發過程問題多多，且並不因軟體開發工具的完善而有大的改善，軟體工程式控制制的

重要性越來越被重視。軟體開發過程的問題常有如下幾種：

（1）對軟體開發成本和進度的估計常常很不準確。實際成本比估計成本有可能高出一

個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象並不罕見。這種現象降低了軟體

開發組織的信譽。而為了趕進度和節約成本所採取的一些權宜之計又往往損害了軟體產品的

質量，從而不可避免地會引起用戶的不滿。

（2）用戶對"已完成的"軟體系統不滿意的現象經常發生。軟體開發人員常常在對用

戶要求只有模糊的了解，甚至對所要解決的問題還沒有確切認識的情況下，就倉促上陣匆忙

著手編寫程序。軟體開發人員和用戶之間的信息交流往往很不充分，"閉門造車"必然導致

最終的產品不符合用戶的實際需要。

（3）軟體產品的質量往往靠不住。軟體可靠性和質量保證的確切的定量概念剛剛出現

不久，軟體質量保證技術（審查、複審和測試）還沒有堅持不懈地應用到軟體開發的全過程

中，這些都導致軟體產品發生質量問題。

（4）軟體常常是不可維護的。很多程序中的錯誤是非常難改正垢，實際上不可能使這

些程序適應新的硬體環境，也不能根據用戶的需要在原有程序中增加一些新的功能。"可重

用的軟體"還是一個沒有完全做到的、正在努力追求的目標，人們仍然在重複開發類似的或

基本類似的軟體。

（5）軟體通常沒有適當的文檔資料。計算機軟體不僅僅是程序，還應該有一整套文檔

資料。這些文檔資料應該是在軟體開發過程中產生出來的，而且應該是"最新式的"（即和

程序代碼完全一致的）。軟體開發組織的管理人員可以使用這些文檔資料作為"里程碑"，

來管理和評價軟體開發工程的進展狀況；軟體開發人員可以利用它們作為通信工具，在軟體

開發過程中準確地交流信息；對於軟體維護人員而言，這些文檔資料更是至關重要必不可少

的。缺乏必要的文檔資料或者文檔資料不合格，必然給軟體開發和維護帶來許多嚴重的困難

和問題。

（6）軟體成本在計算機系統總成本中所佔的比例逐年上升。由於微電子學技術的

進步和生產自動化程度不斷提高，硬體成本逐年下降，然而軟體開發需要大量人力，軟體成

本隨著通貨膨脹以及軟體規模和數量的不斷擴大而持續上升。美國在 1985年軟體成本大約

已佔計算機系統總成本的 90%。

（6）軟體成本在計算機系統總成本中所佔的比例逐年上升。由於微電子學技術的進步

和生產自動化程度不斷提高，硬體成本逐年下降，然而軟體開發需要大量人力，軟體成本隨

著通貨膨脹以及軟體規模和數量的不斷擴大而持續上升。美國在 1985年軟體成本大約已佔

計算機系統總成本的 90%。

（7）軟體開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。軟體

產品"供不應求"的現象使人類不能充分利用現代計算機硬體提供的巨大潛力。

軟體文檔的作用和分類

軟體文檔(document)也稱文件，通常指的是一些記錄的數據和數據媒體，它具有固定

不變的形式，可被人和計算機閱讀。它和計算機程序共同構成了能完成特定功能的計算機

軟體(有人把源程序也當作文檔的一部分)。我們知道，硬體產品和產品資料在整個生產過

程中都是有形可見的，軟體生產則有很大不同，文檔本身就是軟體產品。沒有文檔的軟體，

不成其為軟體，更談不到軟體產品。軟體文檔的編製(documentation)在軟體開發工作中占

有突出的地位和相當的工作量。高效率、高質量地開發、分發、管理和維護文檔對於轉讓、

變更、修正、擴充和使用文檔，對於充分發揮軟件產品的效益有著重要意義。

然而，在實際工作中，文檔在編製和使用中存在著許多問題，有待於解決。軟體開發

人員中較普遍地存在著對編製文檔不感興趣的現象。從用戶方面看，他們又常常抱怨：文

檔售價太高、文檔不夠完整、文檔編寫得不好、文檔已經陳舊或是文檔太多，難於使用等

等。究竟應該怎樣要求它，文檔應該寫哪些，說明什麼問題，起什麼作用?這裡將給出簡要

的介紹。

圖文檔橋樑作用

文檔在軟體開發人員、軟體管理人員、維護人員、用戶以及計算機之間的多種橋樑作，軟體開發人員在各個階段中以文檔作為前階段工作成果的體現和後階段工作的依據，這個作用是顯而易見的。軟體開發過程中軟體開發人員需制定一些工作計劃或工作報告，這些計劃和報告都要提供給管理人員，並得到必要的支持。

管理人員則可通過這些文檔了解軟體開發項目安排、進度、資源使用和成果等。軟體開發人員需為用

戶了解軟件的使用、操作和維護提供詳細的資料，我們稱此為用戶文檔。以上三種文檔構

成了軟體文檔的主要部分。我們把這三種文檔所包括的內容列在圖 6中。其中列舉了十三

個文檔，這裡對它們作一些簡要說明：

可行性研究報告：說明該軟體開發項目的實現在技術上、經濟上和社會因素上的可行

性，評述為了合理地達到開發目標可供選擇的各種可能實施的方案，說明並論證所選

定實施方案的理由。

項目開發計劃：為軟體項目實施方案制定出具體計劃，應該包括各部分工作的負責人

員、開發的進度、開發經費的預算、所需的硬體及軟體資源等。項目開發計劃應提供

給管理部門，並作為開發階段評審的參考。

軟體需求說明書：也稱軟體規格說明書，其中對所開發軟件的功能、性能、用戶界面

及運行環境等作出詳細的說明。它是用戶與開發人員雙方對軟體需求取得共同理解基

礎上達成的協議，也是實施開發工作的基礎。

數據要求說明書：該說明書應給出數據邏輯描述和數據采集的各項要求，為生成和維

護系統數據文卷作好準備。

概要設計說明書：該說明書是概要設計階段的工作成果，它應說明功能分配、模塊

劃分、程序的總體結構、輸入輸出以及介面設計、運行設計、數據結構設計和出錯處

理設計等，為詳細設計奠定基礎。

詳細設計說明書：著重描述每一模塊是怎樣實現的，包括實現演算法、邏輯流程等。

用戶手冊：本手冊詳細描述軟體的功能、性能和用戶界面，使用戶了解如何使用該軟體。

文檔編製的質量要求

為了使軟體文檔能起到前節所提到的多種橋樑作用，使它有助於程序員編製程序，有

助於管理人員監督和管理軟體開發，有助於用戶了解軟體的工作和應做的操作，有助於維

護人員進行有效的修改和擴充，文檔的編製必須保證一定的質量。質量差的軟體文檔不僅

使讀者難於理解，給使用者造成許多不便，而且會削弱對軟體的管理(管理人員難以確認和

評價開發工作的進展)，增高軟件的成本(一些工作可能被迫返工)，甚至造成更加有害的後

果(如誤操作等)。

造成軟體文檔質量不高的原因可能是：

缺乏實踐經驗，缺乏評價文檔質量的標準。

不重視文檔編寫工作或是對文檔編寫工作的安排不恰當。

最常見到的情況是，軟體開發過程中不能按表 5給出的進度，分階段及時完成文檔的

編製工作，而是在開發工作接近完成時集中人力和時間專門編寫文檔。另一方面，和程序

工作相比，許多人對編製文檔不感興趣。於是在程序工作完成以後，不得不應付一下，把

要求提供的文檔趕寫出來。這樣的做法不可能得到高質量的文檔。實際上，要得到真正高

質量的文檔並不容易，除去應在認識上對文檔工作給予足夠的重視外，常常需要經過編寫

初稿，聽取意見進行修改，甚至要經過重新改寫的過程。

高質量的文檔應當體現在以下一些方面：

①針對性；文檔編製以前應分清讀者對象，按不同的類型、不同層次的讀者，決定怎

樣適應他們的需要。例如，管理文檔主要是面向管理人員的，用戶文檔主要是面向用戶的，

這兩類文檔不應像開發文檔(面向軟體開發人員)那樣過多地使用軟體的專業術語。

②精確性：文檔的行文應當十分確切，不能出現多義性的描述。同一課題若干文檔內

容應該協調一致，應是沒矛盾的。

⑧清晰性：文檔編寫應力求簡明，如有可能，配以適當的圖表，以增強其清晰性。

④完整性：任何一個文檔都應當是完整的、獨立的，它應自成體系。例如，前言部分

應作一般性介紹，正文給出中心內容，必要時還有附錄，列出參考資料等。同一課題的幾

個文檔之間可能有些部分相同，這些重複是必要的。例如，同一項目的用戶手冊和操作手

冊中關於本項目功能、性能、實現環境等方面的描述是沒有差別的。特別要避免在文檔中

出現轉引其它文檔內容的情況。比如，一些段落並未具體描述，而用"見××文檔××節"

的方式，這將給讀者帶來許多不便。

⑤靈活性：各個不同的軟體項目，其規模和複雜程度有著許多實際差別，不能一律看

待。圖 6所列文檔是針對中等規模的軟體而言的。對於較小的或比較簡單的項目，可做適

當調整或合並。比如，可將用戶手冊和操作手冊合併成用戶操作手冊；軟體需求說明書可

包括對數據的要求，從而去掉數據要求說明書；概要設計說明書與詳細設計說明書合併成

軟體設計說明書等。

文檔的管理和維護

在整個軟體生存期中，各種文檔作為半成品或是最終成品，會不斷地生成、修改或補

充。為了最終得到高質量的產品，達到上節提出的質量要求，必須加強對文檔的管理。以

下幾個方面是應注意做到的：

①軟體開發小組應設一位文檔保管人員，負責集中保管本項目已有文檔的兩套主文本。

兩套文本內容完全一致。其中的一套可按一定手續，辦理借閱。

②軟體開發小組的成員可根據工作需要在自己手中保存一些個人文檔。這些一般都應是

主文本的複製件，並注意和主文本保持一致，在作必要的修改時，也應先修改主文本。

③開發人員個人只保存著主文本中與他工作相關的部分文檔。

④在新文檔取代了舊文檔時，管理人員應及時註銷舊文檔。在文檔內容有更動時，管

理人員應隨時修訂主文本，使其及時反映更新了的內容。

⑤項目開發結束時，文檔管理人員應收回開發人員的個人文檔。發現個人文檔與主文本

有差別時，應立即著手解決。這常常是未及時修訂主文本造成的。

⑥在軟體開發過程中，可能發現需要修改已完成的文檔，特別是規模較大的項目，主文

本的修改必須特別謹慎。修改以前要充分估計修改可能帶來的影響，並且要按照：提議、評

議、審核、批准和實施等步驟加以嚴格的控制。

程序文檔合一與動態文檔

很多企業已經建立了許多龐大的計算機管理系統，而且將不斷地推出新的系統。滿足經

營的需求須不斷維護、改造計算機系統，但同時又要不影響現行生產，所以必須建立一整套

機制來評價、控制和完成對系統的維護。在軟體維護過程中，提出程序與文檔合一的概念在

軟體開發的同時建立動態文檔。

程序與文檔合一概念的提出

一、目前軟體的狀況

程序與文檔的形式分離，不僅是用各自獨立的形式存放，而且使用不同的工具在不同的

時間裡書寫和檢索。維護程序時不能方便地得到文檔的幫助，不能同步修改文檔。

程序與文檔的內容分離，由於程序與文檔採用不同的描述，既有計算機語言也有自然語

言。維護過程中不能及時、一致地更新文檔或程序，使文檔不能準確地描述程序而幾乎成為

廢紙甚至帶來負麵價值。

軟體開發與維護的分離，絕大多數軟體在設計、開發時不太考慮以後可能的修改，加大

了軟體維護的難度，而且使維護容易引入新的錯誤。

這些分離也表現在設計、開發的不同階段的文檔之間的不相容性，例如：需求分析說明

書是紙上的東西，在概要設計階段不能很好地繼承、利用需求分析說明書，設計、編製概要

設計時必須從零開始，需要重新分析、理解需求分析，這種思維上的脫節，不僅延緩開發進

度、加重設計人員的負擔，而且由於理解上的不同導致不同階段描述的對象有許多不相容情

況。這些分離使得文檔在系統的設計、開發、維護中的作用下降，這也是很多軟體人員不願

意編寫文檔的主要原因。

二、程序與文檔合一的概念提出

怎樣才是好的文檔系統呢？應當具備以下屬性：

1. 能夠準確地描述軟體、並且簡單易懂；

2. 能夠迅速錯誤定位、影響分析、修正設計；

3. 能夠提高軟體維護質量；

4. 能夠方便程序修改時理解程序。

為此提出了程序與文檔合一的概念。這概念使軟體成為真正意義上的軟體：程序+文檔，

程序就是文檔，文檔集成在程序中。它要求在選擇開發環境時不僅要考慮環境對設計、開發

的完美支持，而且要考慮對維護、文檔的支持；它要求軟體人員在設計、開發過程中要考慮

維護問題、文檔問題；它要求程序與文檔存儲在同一位置、同一系統中；它要求使用相同工

具進行程序與文檔的書寫、檢索；它要求在編寫和維護程序的同時形成文檔，在書寫文檔時

編寫、維護程序。程序與文檔合一的概念不僅存在於系統的設計、開發階段而且存在於系統

的維護階段，它貫穿軟體的生命周期。

動態文檔系統是建立在程序與文檔合一的概念基礎上的、文檔與程序一致的、簡單易懂

的聯機文檔系統。它包括構件說明與數據描述、對構件與構件之間、構件與數據之間的關係

進行的描述。動態文檔系統是提高了文檔的可用性、易用性和連貫性，使文檔更加有效，是

解決維護問題的有效途徑。

動態文檔系統問題分析

需要解決的問題是：軟體文檔的內容劃分與獲取、文檔的存儲與維護、文檔的檢索、軟

件文檔的生成列印。

一、軟體文檔的內容劃分成：語義文檔、結構文檔、過程文檔

語義文檔是對軟體的功能、概念、總體設計、流程、規約等用自然語言的描述，是軟體

人員根據規範在使用 CASE工具編寫並填入程序的文檔，它也是為更全面的解釋文檔而靈活

加入的額外信息。

結構文檔是在軟體設計工具、開發環境中對象的屬性、構件間介面、構件間引用關係、

軟體的結構等的描述。利用詞法、語法分析程序對整個系統的對象、構件進行識別、分析，

獲取上述描述並形成表格文件。

過程文檔是對軟體的設計、編碼、維護過程中形成的過程描述和程序注釋，如設計目的、

設計人、時間等說明，利用開發環境對軟體人員在設計、開發、維護過程中操作的記錄形成

操作跟蹤。

二、程序與文檔的統一存儲與維護

根據程序與文檔合一的概念和文檔從程序中提取的要求，文檔必須存放在程序中，甚至

文檔固有的源代碼中。結構如此的程序源代碼的存儲必須採用一種新技術—對象倉儲

（Repository）技術，而不能採用流式文件，這樣才能使程序與文檔既結合又分離。程序與

文檔結合在一個對象倉儲中，結合在統一的開發環境中；結合在修改代碼時可以同時修改文

檔、修改文檔時可以同時人工檢查和修改程序，並在多次文檔生成而不會丟失手工輸入的文

檔。程序與文檔應當分別存放在對象倉儲中的不同表或不同的欄位中，在編譯與運行時分離。

三、文檔的檢索

對單個對象、構件文檔的檢索方式是若於文檔存放在一個對象倉儲中，它可以隨源代碼

一起檢索和維護。這種檢索給分析和維護單個構件、對象提供文檔支持。建立多種視圖、編

寫程序對整個系統進行文檔的檢索和獲取，完成對整個系統的分析，對整個系統進行實時文

檔支持。這將在例子中較詳細的描述。

四、軟體文檔的生成列印

編寫程序檢索和獲取整個系統的文檔，按照國家軟體標準的文檔式樣建立文檔模板並將

按模板生成文檔和利用文字處理軟體強大的功能進行創建、編輯文檔並列印。

根據上述分析，文檔分布和獲取對開發環境提出了要求：開發環境應該是設計工具、開

發工具的集成，應該基於 CASE技術、對象倉儲技術、構件技術、OLE技術。基於 CASE技術

的開發環境；設計、開發、維護過程中形成的文檔並植入程序代碼中，使文檔成為程序的一

部分。基於對象倉儲技術的開發環境，將文檔與程序統一存儲在對象倉儲中方便檢索。基於

構件技術的開發環境，便於識別、獲取構件，分析、形成結構文檔和過程文檔。基於 OLE

等技術使文檔可以很好地利用 Word等文檔處理軟體。

動態文檔系統的一個應用實例

廣州電信科技開發有限公司自行設計、開發的名為九七系統的龐大的電信管理計算機系

統自 1997年投產驗收後，將長期用於生產，維護工作非常重要和緊迫。這為動態文檔系統

提供了需求和試驗場所。在長期維護的過程中，體會到好文檔的重要性並提出了程序文檔合

一的概念，這為動態文檔系統提供了理論基礎。九七系統是使用 Uniface開發環境。這種開

發環境採用了 CASE技術、對象倉儲技術、構件技術，這為動態文檔系統提供了技術支撐。

一、廣州電信動態文檔系統的建立步驟

1. 理解 Uniface、Oracle工具的開發環境，規劃語義文檔在各級對象中存放的表與字

段，並根據工具的特性制定填寫的規則。

2. 尋找結構文檔、過程文檔在 Uniface、Oracle工具中存放的表與欄位。

3. 在設計、開發和維護軟體的過程中對這些表或欄位按照規則進行填寫。

4. 建立一整套模板使文檔結構與信息源建立映像，包括：數據字典模板、設計文檔模

板、結構文檔模板、開發過程文檔模板等。

5. 將這些模板組裝成文檔系統，並使它獨立於開發目標系統。

廣州電信動態文檔系統的組成可以分為文檔查詢、維護記錄查詢、文檔生成。

文檔查詢不僅包括構件說明與數據描述，而且包括對構件與數據之間的關係的描述，是

實時的聯機文檔查詢系統。維護記錄查詢是對軟體維護過程中的各個環節進程進行記錄與追

蹤，用於規範維護工作。它包括問題報告、問題分析、錯誤定位、維護設計、維護執行、確

認測試、維護評審、維護提交、問題跟蹤等。文檔生成則是根據需要實時生成軟體設計說明

書。

二、程序與文檔合一概念與動態文檔系統的意義

廣州電信動態文檔系統的基本任務是輔助錯誤定位、維護影響分析、記錄維護進程、生

成文檔。使用 Uniface的開發環境開發的，可以安裝在用 Uniface開發的不同的應用系統中。

該系統已經在九七計費系統的維護中發揮重要作用。

它推崇的程序與文檔合一的概念，提出文檔就是程序，程序就是文檔的思路，文檔融合

在程序中的構思並已實現，這一概念指導了軟體人員進行有效地工作。合一的概念貫穿了設

計、開發、維護整個軟體周期，保證了文檔之間的繼承性和一致性，在設計、開發每一階段

是繼承前階段的程序和文檔的結果。這樣極大地消除了程序與文檔、文檔與文檔之間的不一

致性，加快了軟體設計進度，提高了軟體開發、維護的質量。它是軟體工程在具體應用中的

一種嘗試，它從程序文檔合一的角度出發，進一步規範軟體設計、開發、維護。程序文檔合

一的概念為軟體開發環境發展提供了一種思路；設計更好的對象倉儲來滿足開發、維護人員

對程序文檔合一的概念的需求。

動態文檔系統的局限與發展

廣州電信動態文檔系統有很大的局限性，只能用於 Uniface或 Oracle開發的系統中。

目前的廣州電信動態文檔系統的構件的識別與獲取主要依賴開發工具提供的構件和構件的

特徵進行識別的。這種動態文檔系統難以在一些 3GL工具—未使用對象倉儲技術、構件技術

開發的軟體—中實現程序與文檔的合一與分離。大型軟體系統的環境是複雜的，往往採用了

多種開發環境，如何對其他開發環境進行支持還要進行技術探討和實踐上的摸索。

另一個局限問題是目前的動態文檔系統描述的是程序文檔，其主要在編碼、維護的過程

中進行建設，系統進入維護階段使用。如何使動態文檔系統不僅對軟體維護階段進行支持，

而且對軟體的設計、開發階段進行更多的支持？一種可能的解決途徑是將軟體復用技術拓寬

到包括文檔復用，包括程序復用、程序文檔復用和設計文檔復用，而且將動態文檔系統建立

在基於這種軟體復用系統之上。

軟體質量評價標準

我們把影響軟體質量的因素分成三組，分別反映用戶在使用軟體產品時的三種不同傾向

或觀點。這三種傾向是：產品運行、產品修改和產品轉移。信息系統作為一個產品，也可以

參照這三種傾向來定義。

我們可以採取以下步驟實施全面質量控制：

1．實行工程化開發

"信息系統開發方法"一詞的廣義理解是"探索複雜系統開發過程的秩序"；狹義理解

是"一組為信息系統開發起工具作用的規程"，按這些規程工作，可以較合理地達到目標。

規程由一系列活動組成，形成方法體系。信息系統是一項系統工程，必須建立嚴格的工程式控制

制方法，要求開發組的每一個人都要遵守工程規範。

2．實行階段性凍結與改動控制

信息系統具有生命周期，這就為我們劃分項目階段提供了參考。一個大項目可分成若干

階段，每個階段有自已的任務和成果。這樣一方面便於管理和控制工程進度，另一方面可以

增強開發人員和用戶的信心。

在每個階段末要"凍結"部分成果，作為下一階段開發的基礎。凍結之後不是不能修改，

而是其修改要經過一定的審批程序，並且涉及到項目計劃的調整。

3．實行里程碑式的審查與版本控制

里程碑式審查就是在信息系統生命周期每個階段結束之前，都正式使用結束標準對該階

段的凍結成果進行嚴格的技術審查，如果發現問題，就可以及時在階段內解決。

版本控制是保證項目小組順利工作的重要技術。版本控制的含義是通過給文檔和程序文

件編上版本號，記錄每次的修改信息，使項目組的所有成員都了解文檔和程序的修改過程。

廣義的版本控制技術稱為軟體配製管理，並已有功能完善的軟體工具支持，如 PVCS和

Microsoft Visual SourceSafe。

4．實行面向用戶參與的原型演化

在每個階段的後期，快速建立反映該階段成果的原型系統，通過原型系統與用戶交互，

及時得到反饋信息，驗證該階段的成果並及時糾正錯誤，這一技術被稱為"原型演化"。原

型演化技術需要先進的 CASE工具的支持。

5．盡量採用面向對象和基於構件的方法

面向對象的方法強調類、封裝和繼承，能提高軟體的可重用性，將錯誤和缺憾局部化，

同時還有利於用戶的參與，這些對提高信息系統的質量都大有好處。

基於構件的開發又被稱為"即插即用編程"方法，是從計算機硬體設計中吸收過來的優

秀方法。這種編程方法是將編製好的"構件"插入已做好的框架中，從而形成一個大型軟體。

構件是可重用的軟體部分，構件既可以自己開發，也可以使用其他項目的開發成果，或者直

接向軟體供應商購買。當我們發現某個構件不符合要求時，可對其進行修改而不會影響其他

構件，也不會影響系統功能的實現和測試，就好像整修一座大樓中的某個房間，不會影響其

他房間的使用。

6．全面測試

要採用適當的手段，對系統調查、系統分析、系統設計、實現和文檔進行全面測試。

7．引入外部監理與審計

要重視信息系統的項目管理，特別是項目人力資源的管理，因為項目成員的素質和能力

以及積極性是項目成敗的關鍵。同時還要重視第三方的監理和審計的引入，通過第三方的審

查和監督來確保項目質量。

如何評價軟體的質量

我們常說某某軟體好用，某軟體功能全、結構合理、層次分明。這些表述很含糊，用來

評價軟體質量不夠確切，不能作為企業選購軟體的依據。對於企業來說，開發單位按照企業

的需求，開發一個應用軟體系統，按期完成並移交使用，系統正確執行用戶規定的功能，僅

僅滿足這些是遠遠不夠的。因為企業在引進一套軟體過程中，常常會出現如下問題：

• 定製的軟體可能難於理解，難於修改，在維護期間，企業的維護費用大幅度增加；

• 企業對外購的軟體質量存在懷疑，企業評價軟體質量沒有恰當的指標，對軟體可靠

性和功能性指標了解不足；

• 軟體開發商缺乏歷史數據作為指南，所有關於進度和成本的估算都是粗略的。因為

沒有切實的生產率指標，沒有過去關於軟體開發過程的數據，企業無法精確評價開

發商的工作質量。

為此，有必要先了解軟體的質量評價體系。美國的 B.W.Ｂoehm和 R.Brown 先後提出了

三層次的評價度量模型：軟體質量要素、準則、度量。隨後 G.Mruine提出了自己的軟體質

量度量 SQM技術，波音公司在軟體開發過程中採用了 SQM技術，日本的 NEC公司也提出了自

己的 SQM工具，即 SQMAT，並且在成本控制和進度安排方面取得了良好的效果。

第一層是軟體質量要素，軟體質量可分解成六個要素，這六個要素是軟體的基本特徵：

1. 功能性：軟體所實現的功能滿足用戶需求的程度．功能性反映了所開發的軟體滿足

用戶稱述的或蘊涵的需求的程度，即用戶要求的功能是否全部實現了。

2. 可靠性：在規定的時間和條件下，軟體所能維持其性能水平的程度。可靠性對某些

軟體是重要的質量要求，它除了反映軟體滿足用戶需求正常運行的程度，且反映了在故障發

生時能繼續運行的程度。

3. 易使用性：對於一個軟體，用戶學習、操作、準備輸入和理解輸出時，所做努力的

程度。易使用性反映了與用戶的友善性，即用戶在使用本軟體時是否方便。

4. 效率：在指定的條件下，用軟體實現某種功能所需的計算機資源（包括時間）的有

效程度。效率反映了在完成功能要求時，有沒有浪費資源，此外＂資?quot;這個術語有比較

廣泛的含義，它包括了內存、外存的使用，通道能力及處理時間。

5. 可維修性：在一個可運行軟體中，為了滿足用戶需求、環境改變或軟體錯誤發生時，

進行相應修改所做的努力程度。可維修性反映了在用戶需求改變或軟體環境發生變更時，對

軟體系統進行相應修改的容易程度。一個易於維護的軟體系統也是一個易理解、易測試和易

修改的軟體，以便糾正或增加新的功能，或允許在不同軟體環境上進行操作。

6. 可移植性：從一個計算機系統或環境轉移到另一個計算機系統或環境的容易程度。

運用全面質量管理提高軟體質量

當前軟體產品開發過程中出現的質量問題，可以認為是由以下原因導致的：

1、管理者缺乏質量觀念，沒有保證質量的全面計劃、有效措施，未將質量放在足夠重

要的地位，未從一開始就強調質量。

2、開發者未將保證質量作為他們的重要而且是必須完成的任務，把保證產品質量看成

是質量檢測人員的責任。缺乏全面質量管理、人人都是質量保證者和責任人的觀念。

3、大家都缺乏這種觀念：在每個產品開發階段都不做出不合格工作，決不把不合格的

中間產品帶到下一階段，而不是到產品最後階段才由專門的質量檢測人員檢查並保證產品質

量。這就需要明確制定每一階段工作的檢測標準，讓大家知道什麼才是合格的工作。

4、沒有良好的激勵機制。沒有將個人的所得（物質和心理兩方面）與其工作績效直接

聯繫起來。也沒有好的個人績效評價機制。做不好是大家整體的責任，自己的利益不受影響。

做好了也沒有及時明顯的獎勵。總之，做好做不好差不多，大家沒有積極性，沒有人會拚命

高質量地完成自己的工作。

5、大家看不到提高質量對公司的生存發展有多重要，普遍缺乏主人翁責任感。

6、顯然，不單單是質量問題。還有管理者和開發者的關係問題。例如因為管理者的指

示未得到切實地執行，才導致版本不一致等問題。又比如管理者強調質量和維護質量的措施

會引起開發者的反感。如果大家能很好地交流和合作，此類問題會大大減少。

7、大家對顧客的質量要求不了解，不理解顧客的心理，缺乏使顧客滿意的思想。

什麼是 TQM？

TQM是一種思想觀念，一套方法、手段和技巧，通過全體員工的參與、改進流程、產品、

服務和公司文化，達到在百分之百時間內生產百分之百的合格產品，以便滿足顧客需求

（CustomerSatisfaction,CS），從而獲取競爭優勢和長期成功。

TQM的要點是什麼？

1、客戶滿意

顧客包括兩種：外部顧客和內部顧客。外部顧客指公司產品的最終用戶。內部顧客指在

公司內部和自己的工作有聯繫的那些人。

2、全員參與

質量不僅僅是 QA,Tester,LanguageConsultant的事，每一個員工都有維護質量的責任。

每個員工都有責任、也有權利提出改進建議，並將合理的建議付諸實施。

3、團隊精神

TQM要求全體成員之間的有效交流，緊密合作。管理者要改變發號施令的角色，變成教

練、協調人、組織者。

4、百分之百的優質

任何一個小錯誤都可能造成大的損失。只有消除僥倖心理，時刻追求百分之百的優質，

才能實現 TQM，充分滿足顧客需求。

5、貫徹始終

在產品開發的每一個階段都應實行全面的質量管理，而不是僅在某一階段。

6、事前主動

防患於未然。經常組織討論，主動尋找出可能發生的問題，並及時加以解決。

7、持續改進

實施 TQM不可能畢其功於一役。必須堅持持續改進，將 TQM融入日常的工作和管理。

TQM實施的步驟有哪些？

1、進行全面質量管理思想的教育

對全體員工進行全面質量管理思想的教育，以達到以下目的：

1）將滿足顧客的需求放在首位

要讓每個人深刻理解"顧客滿意"的思想。為了理解並實行"顧客滿意"的思想，可以

將員工分組進行"換位思維"，並討論清楚如下問題：

所有參與產品開發的人員：如果自己是個顧客，對產品的質量是怎麼要求的？希望自己

得到什麼樣的服務？

管理人員：如果自己是個開發者，對開發過程中遇到的問題會有何想法？希望得到什麼

樣的幫助和理解？希望管理者如何對待自己？

開發者：假如自己是個管理者，會如何管理整個開發過程？對開發中出現的問題怎麼

看？知道它們的起源和解決方法么？

要鼓勵大家以自己希望得到的那種服務方式去為自己的顧客服務，要將每個人都作為自

己的一個重要顧客，想方設法是其滿意。比如，CourseDesigner要提供足夠清晰的 Script

及必要解釋，使 GraphicDesigner清楚該畫什麼樣的圖，讓他們滿意，讓他們愉快地進行下

一步的工作。

2）明白提高質量與降低成本的關係

質量提高，不僅不會提高成本，反而會降低成本。這是因為：質量高了，會減少反覆修

改的時間，縮短開發周期，降低人力資本。還會提高士氣，提高工作效率。

3）樹立百分之百合格產品的責任感

使百分之百的員工成為抓質量的主人。要達到此種境界：當問一個員工"誰負責產品的

質量？"時，得到的回答是"我！"，而不是"Tester"或"QA"或其它。讓大家明白：如果

存在任何問題，都會最終出現並影響產品質量和公司形象。在開始階段的問題不解決，只能

在最後的階段以更高的代價解決。教育員工樹立百分之百合格產品的責任感，消除僥倖心理。

2、明確顧客需求

搞清楚什麼樣的產品是讓用戶滿意的產品。

3、了解市場

經常將別的廠商的產品向大家展示，並進行研究，讓大家明白別人是怎麼做得，我們有

何差距。

4、讓員工明白什麼是好的產品

給出樣板，進行足夠的培訓，讓大家都真正明白什麼是好的合格的產品。

5、建立明確的質量基準和質量測評制度

產品好壞一定要有一個明確公開的標準來衡量。每個人都可以把自己的工作結果與之對

照，從而知道自己做得是好是壞。而且這種標準要以一種制度的形式切實付諸實施，才能增

加可信度。

6、建立相對完善的激勵機制

如果檢測的結果對個人的利益無任何影響，則員工沒有儘力提高質量的動力。要在物質

和精神方面對員工根據他們的績效進行不同的激勵。

7。幫助質量檢測部門變成提高質量的催化劑

改變質檢人員"挑問題者"的角色，消除 Tester,QA同開發者之間的隔閡和對立。可以

採取三種措施：

讓質檢人員與開發者一起參加有關培訓，使他們彼此更好地理解對方的工作。

讓質檢人員成為開發小組的一部分，讓小組成員有更多的了解。

提高質檢人員與開發者的溝通技巧。

8、建立一套明確一致的解決問題的方法

一旦出現問題，大家能夠按照此方法去解決問題，而不是互相埋怨或手足無措。

解決問題常用的 6步法：

討論並確定問題

找出問題的根源

提出可能的解決方法

選擇最佳辦法

建議、批准和實施

測試、評估、調整和慶賀

9、在全體員工中培育主人翁意識和敬業精神

如果大家都抱著"公司不是我的，我是來打工的，公司效益好壞、能夠存活發展與我無

關"，產品質量如何提高，公司如何搞好？

10、讓員工有一定的自由和權利

有了權利，才會有主動性。允許員工提出問題，解決問題，並將解決方案付諸實施。如

果什麼問題都要 Leader來決定，大家只有消極工作和等待。

11、建立質量小組

質量小組由不同角色的人員組成，負責發現質量問題，討論解決方法，提出並實施解決

方案。

12、加強 Teamwork的培訓

培訓員工，尤其是 Leader如何有效地制定 Teamsgoal，如何不斷增強這個 goal，如何

始終圍繞這個 goal工作。教給大家如何更好地交流，如何更好地合作，如何在解決問題時

對事不對人。

八項質量管理原則

為了成功地領導和運作一個組織，需要採用一種系統和透明的方式進行管理。針對所有

相關方的需求，實施並保持持續改進其業績的管理體系，使組織獲得成功。組織為實現質量

目標，應遵循以下八項質量管理原則。

原則 1：以顧客為中心

組織依存於其顧客。因此，組織應理解顧客當前的和未來的需求，滿足顧客要求並爭取

超越顧客期望。

1、組織實施本原則的主要利益

2、組織實施本原則時一般要採取的主要措施

3、本原則在標準中的體現

原則 2：領導作用

領導將本組織的宗旨、方向和內部環境統一起來，並創造使員工能夠充分參與實現組織

目標的環境。

1、組織實施本原則的主要利益

2、組織實施本原則時一般要採取的主要措施

3、本原則在標準中的體現

原則 3：全員參與

各級人員是組織之本。只有他們的充分參與，才能使他們的才幹為組織帶來最大的收益。

1、織實施本原則的主要利益

2、組織實施本原則時一般要採取的主要措施

3、本原則在標準中的體現

原則 4：過程方法

將相關的資源和活動作為過程進行管理，可以更高效地得到期望的結果。

過程方法的原則不僅適用於某些較簡單的過程，也適用於由許多過程構成的過程網路。

在應用於質量管理體系時，2000版 ISO9000族標準建立了一個過程模式。此模式把管理職

責、資源管理、產品實現、測量、分析與改進作為體系的四大主要過程，描述其相互關係，

並以顧客要求為輸入，提供給顧客的產品為輸出，通過信息反饋來測定的顧客滿意度，評價

質量管理體系的業績。

1、實施本原則的主要利益

2、組織實施本原則時一般要採取的主要措施

3、本原則在標準中的體現

原則 5：管理的系統方法

針對設定的目標，識別、理解並管理一個由相互關連的過程所組成的體系，有助於提高

組織的有效性和效率。

ISO/DIS9000的 3.3列出了建立和實施質量管理體系的十三個步驟：

1、實施本原則的主要利益

2、組織實施本原則時一般要採取的主要措施

3、本原則在標準中的體現

軟體工程標準化

人們社會生活離不開交往。在交往中最先遇到和首先要解決的是通訊工具——語言文

字問題，計算機問世以後，同樣是語言問題。人要和計算機打交道，需要程序設計語言，

這種語言不僅應讓計算機理解，而且還應讓別人看懂，使其成為人際交往的工具。程序設

計語言的標準化最早提到日程上來。60年代程序設計語言蓬勃發展，出現了名目繁多的語

言，這對於推動計算機語言的發展無疑有著重要作用。但同時也帶來許多麻煩。即使同一

種語言，由於在不同型號的計算機上實現時，作了不同程度的修改和變動，形成了這一語

言的種種"方言"，為編寫出程序的交流設置了障礙。制定標準化程序設計語言，為某一

程序設計語言規定若干個標准子集，對於語言的實現者和用戶都帶來了很大方便。

隨著軟體工程學科的發展，人們對計算機軟體的認識逐漸深入。軟體工作的範圍從只

是使用程序設計語言編寫程序，擴展到整個軟體生存期。諸如，軟體概念的形成、需求分

析、設計、實現、測試、製造、安裝和檢驗、運行和維護直到軟體引退(為新的軟體所代替)。

同時還有許多技術管理工作(如過程管理、產品管理、資源管理)以及確認與驗證工作(如評

審與審計、產品分析、測試等)常常是跨越軟體生存期各個階段的專門工作。所有這些方面

都應逐步建立起標準或規範來。

另一方面，軟體工程標準的類型也是多方面的。它可能包括過程標準(如方法、技術、

度量等)、產品標準(如需求、設計、部件、描述、計劃、報告等)、專業標準(如職別、道

德準則、認證、特許、課程等)以及記法標準(如術語、表示法、語言等)。

軟體工程標準化的意義

為什麼要積極推行軟體工程標準化工作，其道理是顯而易見的。僅就一個軟體開發項

目來說，有多個層次、不同分工的人員相互配合，在開發項目的各個部分以及各開發階段

之間也都存在著許多聯繫和銜接問題。如何把這些錯綜複雜的關係協調好，需要有一系列

統一的約束和規定。在軟體開發項目取得階段成果或最後完成時，需要進行階段評審和驗

收測試。投入運行的軟體，其維護工作中遇到的問題又與開發工作有著密切的關係。軟體

的管理工作則滲透到軟體生存期的每一個環節。所有這些都要求提供統一的行動規範和衡

量準則，使得各種工作都能有章可循。

我國的軟體工程標準化工作

1983年 5月我國國家標準總局和原電子工業部主持成立了 "計算機與信息處理標準化

技術委員會"，下設十三個分技術委員會。和軟體相關的是程序設計語言分技術委員會和

軟體工程技術委員會。我國制定和推行標準化工作的總原則是向國際標準靠攏，對於能夠

在我國適用的標準一律按等同採用的方法，以促進國際交流。

軟體測試概述

信息技術的飛速發展，使軟體產品應用到社會的各個領域，軟體產品的質量自然成為人

們共同關注的焦點。不論軟體的生產者還是軟體的使用者，均生存在競爭的環境中，軟體開

發商為了佔有市場，必須把產品質量作為企業的重要目標之一，以免在激烈的競爭中被淘汰

出局。用戶為了保證自己業務的順利完成，當然希望選用優質的軟體。質量不佳的軟體產品

不僅會使開發商的維護費用和用戶的使用成本大幅增加，還可能產生其他的責任風險，造成

公司信譽下降，繼而衝擊股票市場。在一些關鍵應用 (如民航訂票系統、銀行結算系統、證

券交易系統、自動飛行控制軟體、軍事防禦和核電站安全控制系統等) 中使用質量有問題的

軟體，還可能造成災難性的後果。

軟體危機曾經是軟體界甚至整個計算機界最熱門的話題。為了解決這場危機，軟體從業

人員、專家和學者做出了大量的努力。現在人們已經逐步認識到所謂的軟體危機實際上僅是

一種狀況，那就是軟體中有錯誤，正是這些錯誤導致了軟體開發在成本、進度和質量上的失

控。有錯是軟體的屬性，而且是無法改變的，因為軟體是由人來完成的，所有由人做的工作

都不會是完美無缺的。問題在於我們如何去避免錯誤的產生和消除已經產生的錯誤，使程序

中的錯誤密度達到儘可能低的程度。

給軟體帶來錯誤的原因很多，具體地說，主要有如下幾點：

①、交流不夠、交流上有誤解或者根本不進行交流

在應用應該做什麼或不應該做什麼的細節(應用的需求)不清晰的情況下進行開發。

②、軟體複雜性

圖形用戶界面(GUI)，客戶/伺服器結構，分散式應用，數據通信，超大型關係型資料庫

以及龐大的系統規模，使得軟體及系統的複雜性呈指數增長，沒有現代軟體開發經驗的人很

難理解它。

③、程序設計錯誤

象所有的人一樣，程序員也會出錯。

④、需求變化

需求變化的影響是多方面的，客戶可能不了解需求變化帶來的影響，也可能知道但又不

得不那麼做。需求變化的後果可能是造成系統的重新設計，設計人員的日程的重新安排，已

經完成的工作可能要重做或者完全拋棄，對其他項目產生影響，硬體需求可能要因此改變，

等等。如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴性可能會

相互影響而導致更多問題的出現，需求改變帶來的複雜性可能導致錯誤，還可能影響工程參

與者的積極性。

⑤、時間壓力

軟體項目的日程表很難做到準確，很多時候需要預計和猜測。當最終期限迫近和關鍵時

刻到來之際，錯誤也就跟著來了。

⑥、自負人更喜歡說:

沒問題

這事情很容易

幾個小時我就能拿出來

太多不切實際的沒問題，結果只能是引入錯誤。

⑦、代碼文檔貧乏

貧乏或者差勁的文檔使得代碼維護和修改變的異常艱辛，其結果是帶來許多錯誤。事實

上，在許多機構並不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和容易

理解，相反他們認為少寫文檔可以更快的進行編碼，無法理解的代碼更易於工作的保密("寫

得艱難必定讀的痛苦")。

⑧、軟體開發工具

可視化工具，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤帶到應用軟體

中。就象我們所知道的，沒有良好的工程化作為基礎，使用面向對象的技術只會使項目變得

更複雜。為了更好地解決這些問題，軟體界做出了各種各樣的努力。

人們曾經認為更好的程序語言可以使我們擺脫這些困擾，這推動了程序設計語言的發

展，更多的語言開始流行，為了使程序更易於理解開發了結構化程序設計語言，如

PL/1,PASCAL等；為了解決實時多任務需求開發了結構化多任務程序設計語言，如 Modula，

Ada等；為了提高重用性開發了面向對象的程序設計語言，如 Simlasa等；為了避免產生不

正確的需求理解，開發形式化描述語言，如 HAL/S等，這使得建立基於自然語言的描述成為

可能，人們以形式化語言來描述需求；為了支持大型資料庫應用，開發了可視化工具，如

Visual Studio、Power Builder等。程序語言對提高軟體生產效率起到了一定的積極作用，

但它對整個軟體質量尤其是可靠性的影響，與其他因素相比作用較小。

可能是因為程序語言基於嚴格的語法和語義規則，人們企圖用形式化證明方法來證明程

序的正確性。將程序當作數學對象來看待，從數學意義上證明程序是正確的是可能的。數學

家對形式化證明方法最有興趣，在論文上談起來非常吸引人，但實際價值卻非常有限，因為

形式化證明方法只有在代碼寫出來之後才能使用，這顯然太遲了，而且對於大的程序證明起

來非常困難。受到其他行業項目工程化的啟發，軟體工程學出現了，軟體開發被視為一項

工程，以工程化的方法來進行規劃和管理軟體的開發。

針對需求不確定的應用，可以使用漸進和迭代類的開發模型。還可以採用快速應用程序

開發(RAD)和協同應用程序開發（JAD）技術，由軟體開發者和用戶代表共同參與開發軟體規

范。RAD和 JAD的基本思路是開發者和用戶共同設計系統中的屏幕，開發者迅速地把實現這

些屏幕的最基本功能編寫好，然後把它們交給用戶看，然後用戶和開發者回顧這些屏幕以確

認它們達到了用戶的要求，這個周期一直持續到系統的基本部分定義完畢。一旦設計被用戶

接受，開發者將完成完全實現屏幕需要的代碼。RAD和傳統軟體開發項目之間的一個基本區

別是：應用程序 RAD系統是按階段發布的。傳統項目一般一次發布，也叫"big bang"。RAD

方法使用高效開發工具，開發者能夠非常迅速地設計出系統的基本屏幕，允許用戶在開發周

期中很早就能見識到系統將來看起來怎麼樣，避免了在傳統開發項目中長篇大論並且枯燥難

懂的說明。

IBM的 Dr.Harlan Mills提出了凈室過程。凈室過程組合了形式化程序驗證和統計過程

控制(SPC)。在這種方法中，首先用正確性數學證明預防缺陷發生，然後用 MTBF度量軟體質

量。凈室過程是一種相當新的軟體開發方法，它要求軟體開發在管理方式和技術方法上作重

大改變，特別是要求 SPC應用到軟體的知識，這影響了其被廣泛的接受。

硬體成本持續降低，可支持 CASE工具運行的新的強大的工作站和網路已經成為軟體工

程使用的工作平台，CASE工具可完成一些特定的軟體開發過程。這些工具提供給軟體設計

者以圖形方式描述軟體設計的能力，這樣就易於維護、易於交叉檢查、易於理解。許多人（尤

其是 CASE工具供貨商）相信 CASE工具扮演了解決軟體危機和拯救軟體工業的角色，但事實

上我們看到的情形卻是許多公司花了大量的金錢買回的 CASE工具但很少使用，原因在於這

些工具執行的過程與機構的軟體設計過程不相適用。

在可以藉助許多新的技術和工具進行軟體開發的今天，軟體開發過程的成熟性問題開始

引起人們的重視。這種產品一致性問題的主要癥結在於管理，因此人們將目標轉向了管理的

改善，一些以改進軟體開發過程為目標的活動已經展示出積極的結果。

以下是一些比較典型的文本。

SEI SW-CMM

ISO SPICE(Software Process Improvement and Capability dEtermination)

Bootstrap

ISO-9000-3

TickIT

Trillium

事實上，對於軟體來講，還沒有象銀彈那樣的東西。不論採用什麼技術和什麼方法，軟

件中仍然會有錯。採用新的語言、先進的開發方式、完善的開發過程，可以減少錯誤的引入，

但是不可能完全杜絕軟體中的錯誤，這些引入的錯誤需要測試來找出，軟體中的錯誤密度也

需要測試來進行估計。測試是所有工程學科的基本組成單元，是軟體開發的重要部分。自

有程序設計的那天起測試就一直伴隨著。統計表明，在典型的軟體開發項目中，軟體測試工

作量往往占軟體開發總工作量的 40％以上。而在軟體開發的總成本中，用在測試上的開銷

要佔 30％到 50％。如果把維護階段也考慮在內，討論整個軟體生存期時，測試的成本比例

也許會有所降低，但實際上維護工作相當於二次開發，乃至多次開發，其中必定還包含有許

多測試工作。因此，測試對於軟體生產來說是必需的，問題是我們應該思考"採用什麼方法、

如何安排測試?"

軟體目的

軟體測試的目的決定了如何去組織測試。如果測試的目的是為了儘可能多地找出錯誤，

那麼測試就應該直接針對軟體比較複雜的部分或是以前出錯比較多的位置。如果測試目的是

為了給最終用戶提供具有一定可信度的質量評價，那麼測試就應該直接針對在實際應用中會

經常用到的商業假設。

不同的機構會有不同的測試目的；相同的機構也可能有不同測試目的，可能是測試不同

區域或是對同一區域的不同層次的測試。

在談到軟體測試時，許多人都引用 Grenford J. Myers在《The Art of Software Testing》

一書中的觀點：

①、軟體測試是為了發現錯誤而執行程序的過程；

②、測試是為了證明程序有錯，而不是證明程序無錯誤。

③、一個好的測試用例是在於它能發現至今未發現的錯誤；

④、一個成功的測試是發現了至今未發現的錯誤的測試。

這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟體的正確功能。但

是僅憑字面意思理解這一觀點可能會產生誤導，認為發現錯誤是軟體測試的唯一目，查找不

出錯誤的測試就是沒有價值的，事實並非如此。

首先，測試並不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分布特徵，

可以幫助項目管理者發現當前所採用的軟體過程的缺陷，以便改進。同時，這種分析也能幫

助我們設計出有針對性地檢測方法，改善測試的有效性。

其次，沒有發現錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。詳

細而嚴謹的可靠性增長模型可以證明這一點。例如 Bev Littlewood發現一個經過測試而正

常運行了 n小時的系統有繼續正常運行 n小時的概率。

軟體測試的基本方法

軟體測試的方法和技術是多種多樣的。

對於軟體測試技術，可以從不同的角度加以分類：

從是否需要執行被測軟體的角度，可分為靜態測試和動態測試。

從測試是否針對系統的內部結構和具體實現演算法的角度來看，可分為白盒測試和黑盒測

試；

1、黑盒測試

黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來

檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不

考慮程序內部結構和內部特性的情況下，測試者在程序介面進行測試，它只檢查程序功能是

否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出

信息，並且保持外部信息（如資料庫或文件）的完整性。黑盒測試方法主要有等價類劃分、

邊值分析、因—果圖、錯誤推測等，主要用於軟體確認測試。 "黑盒"法著眼於程序外部

結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。"黑盒"法是窮舉輸入測

試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。

實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是

可能的輸入進行測試。

2、白盒測試

白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢

測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗

程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法

有邏輯驅動、基路測試等，主要用於軟體驗證。

"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉

路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，

得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯

誤。第一，窮舉路徑測試決不能查出程序違反了設計規範，即程序本身是個錯誤的程序。第

二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了

一些與數據相關的錯誤。

3．ALAC(Act-like-a-customer)測試

ALAC測試是一種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於複雜

的軟體產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容

易遇到的錯誤。

軟體測試的組織與管理

作為軟體開發的重要環節，軟體測試越來越受到人們的重視。隨著軟體開發規模的增大、

複雜程度的增加，以尋找軟體中的錯誤為目的的測試工作就顯得更加困難。然而，為了盡可

能多地找出程序中的錯誤，生產出高質量的軟體產品，加強對測試工作的組織和管理就顯得

尤為重要。

從軟體的生存周期看，測試往往指對程序的測試，這樣做的優點是被測對象明確，測試

的可操作性相對較強。但是，由於測試的依據是規格說明書、設計文檔和使用說明書，如果

設計有錯誤，測試的質量就難以保證。即使測試後發現是設計的錯誤，這時，修改的代價是

相當昂貴的。因此，較理想的做法應該是對軟體的開發過程，按軟體工程各階段形成的結果，

分別進行嚴格的審查。軟體的生命周期可用圖 1的流程表示。

為了確保軟體的質量，對圖 1的過程應進行嚴格的管理。雖然測試是在實現且經驗證後

進行的，實際上，測試的準備工作在分析和設計階段就開始了。

1．測試的過程及組織

當設計工作完成以後，就應該著手測試的準備工作了，一般來講，由一位對整個系統設

計熟悉的設計人員編寫測試大綱，明確測試的內容和測試通過的準則，設計完整合理的測試

用例，以便系統實現後進行全面測試。

在實現組將所開發的程序經驗證後，提交測試組，由測試負責人組織測試，測試一般可

按下列方式組織：

(1)首先，測試人員要仔細閱讀有關資料，包括規格說明、設計文檔、使用說明書及在

設計過程中形成的測試大綱、測試內容及測試的通過準則，全面熟悉系統，編寫測試計劃，

設計測試用例，作好測試前的準備工作。

(2)為了保證測試的質量，將測試過程分成幾個階段，即：代碼審查、單元測試、集成

測試和驗收測試。

(3)代碼會審：

代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程。會審小組由組

長，2～3名程序設計和測試人員及程序員組成。會審小組在充分閱讀待審程序文本、控制

流程圖及有關要求、規範等文件基礎上，召開代碼會審會，程序員逐句講解程序的邏輯，並

展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在。實踐表明，程序員在講解過程中能發現

許多自己原來沒有發現的錯誤，而討論和爭議則進一步促使了問題的暴露。例如，對某個局

部性小問題修改方法的討論，可能發現與之有牽連的甚至能涉及到模塊的功說明、模塊間接

口和系統總結構的大問題，導致對需求定義的重定義、重設計驗證，大大改善了軟體的質量。

(4)單元測試：

單元測試集中在檢查軟體設計的最小單位—模塊上，通過測試發現實現該模塊的實際功

能與定義該模塊的功能說明不符合的情況，以及編碼的錯誤。由於模塊規模小、功能單一、

邏輯簡單，測試人員有可能通過模塊說明書和源程序，清楚地了解該模塊的 I/O條件和模塊

的邏輯結構，採用結構測試（白盒法）的用例，儘可能達到徹底測試，然後輔之以功能測試

（黑盒法）的用例，使之對任何合理和不合理的輸入都能鑒別和響應。高可靠性的模塊是組

成可靠系統的堅實基礎。

(5)集成測試：

集成測試是將模塊按照設計要求組裝起來同時進行測試，主要目標是發現與介面有關的

問題。如數據穿過介面時可能丟失；一個模塊與另一個模塊可能有由於疏忽的問題而造成有

害影響；把子功能組合起來可能不產生預期的主功能；個別看起來是可以接受的誤差可能積

累到不能接受的程度；全程數據結構可能有錯誤等。

(6)驗收測試：

驗收測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已

經按照設計把所有的模塊組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就

應該進一步驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能和性能如同用戶所合

理期待的那樣。

經過上述的測試過程對軟體進行測試後，軟體基本滿足開發的要求，測試宣告結束，經

驗收後，將軟體提交用戶。

2．測試方法的應用

集成測試及其後的測試階段，一般採用黑盒方法。其策略包括?/p>

(1)用邊值分析法和（或）等價分類法提出基本的測試用例；

(2)用猜測法補充新的測試用例；

(3)如果在程序的功能說明中含有輸入條件的組合，宜在一開始就用因果圖法，然後再

按以上（1）、（2）兩步進行。

單元測試的設計策略稍有不同。因為在為模塊設計程序用例時，可以直接參考模塊的源

程序。所以單元測試的策略，總是把白盒法和黑盒法結合運用。具體做法有兩種：

a、先仿照上述步驟用黑盒法提出一組基本的測試用例，然後用白盒法作驗證。如果發

現用黑盒法產生的測試用例未能滿足所需的覆蓋標準，就用白盒法增補新的測試用例來滿足

它們。覆蓋的標準應該根據模塊的具體情況確定。對可靠性要求較高的模塊，通常要滿足條

件組合覆蓋或路徑覆蓋標準。

b、先用白盒法分析模塊的邏輯結構，提出一批測試用例，然後根據模塊的功能用黑盒

法進行補充。

3．測試的人員組織

為了保證軟體的開發質量，軟體測試應貫穿於軟體定義與開發的整個過程。因此，對分

析、設計和實現等各階段所得到的結果，包括需求規格說明、設計規格說明及源程序都應進

行軟體測試。基於此，測試人員的組織也應是分階段的。

(1)軟體的設計和實現都是基於需求分析規格說明進行的。

需求分析規格說明是否完整、正確、清晰是軟體開發成敗的關鍵。為了保證需求定義的

質量，應對其進行嚴格的審查。審查小組由下列人員組成：

組長：1人

成員：包括系統分析員，軟體開發管理者，軟體設計、開發和測試人員和用戶

(2)設計評審：

軟體設計是將軟體需求轉換成軟體表示的過程。主要描繪出系統結構、詳細的處理過程

和資料庫模式。按照需求的規格說明對系統結構的合理性、處理過程的正確性進行評價，同

時利用關係資料庫的規範化理論對資料庫模式進行審查。評審小組由下列人員組成：

組長：1人

成員：包括系統分析員、軟體設計人員、測試負責人員各一人。

(3)程序的測試：

軟體測試。是整個軟體開發過程中交付用戶使用前的最後階段，是軟體質量保證的關鍵。

軟體測試在軟體生存周期中橫跨兩個階段：通常在編寫出每一個模塊之後，就對它進行必要

的測試（稱為單元測試）。編碼與單元測試屬於軟體生存周期中的同一階段。該階段的測試

工作，由編程組內部人員進行交叉測試（避免編程人員測試自己的程序）。這一階段結束後，

進入軟體生存周期的測試階段，對軟體系統進行各種綜合測試。測試工作由專門的測試組完

成，測試組設組長一名，負責整個測試的計劃、組織工作。測試組的其他成員由具有一定的

分析、設計和編程經驗的專業人員組成，人數根據具體情況可多可少，一般 3～5人為宜。

4．軟體測試文件

軟體測試文件描述要執行的軟體測試及測試的結果。由於軟體測試是一個很複雜的過

程，同時也是設計軟體開發其它一些階段的工作，對於保證軟體的質量和它的運行有著重要

意義，必須把對它們的要求、過程及測試結果以正式的文件形式寫出。測試文件的編寫是測

試工作規範化的一個組成部分。

測試文件不只在測試階段才考慮，它在軟體開發的需求分析階段就開始著手，因為測試

文件與用戶有著密切的關係。在設計階段的一些設計方案也應在測試文件中得到反映，以利

於設計的檢驗。測試文件對於測試階段工作的指導與評價作用更是非常明顯的。需要特別指

出的是，在已開發的軟體投入運行的維護階段，常常還要進行再測試或回歸測試，這時仍須

用到測試文件。

(1)測試文件的類型

根據測試文件所起的作用不同，通常把測試文件分成兩類，即測試計劃和測試分析報告。

測試計劃詳細規定測試的要求，包括測試的目的和內容、方法和步驟，以及測試的準則等。

由於要測試的內容可能涉及到軟體的需求和軟體的設計，因此必須及早開始測試計劃的編寫

工作。不應在著手測試時，才開始考慮測試計劃。通常，測試計劃的編寫從需求分析階段開

始，到軟體設計階段結束時完成。測試報告用來對測試結果的分析說明，經過測試後，證實

了軟體具有的能力，以及它的缺陷和限制，並給出評價的結論性意見，這些意見即是對軟體

質量的評價，又是決定該軟體能否交付用戶使用的依據。由於要反映測試工作的情況，自然

要在測試階段內編寫。

(2)測試文件的使用

測試文件的重要性表現在以下幾個方面：

a、驗證需求的正確性：測試文件中規定了用以驗證軟體需求的測試條件，研究這些測

試條件對弄清用戶需求的意圖是十分有益的，

b、檢驗測試資源：測試計劃不僅要用文件的形式把測試過程規定下來，還應說明測試

工作必不可少的資源，進而檢驗這些資源是否可以得到，即它的可用性如何。如果某個測試

計劃已經編寫出來，但所需資源仍未落實，那就必須及早解決。

c、明確任務的風險：有了測試計劃，就可以弄清楚測試可以做什麼，不能做什麼。了

解測試任務的風險有助於對潛伏的可能出現的問題事先作好思想上和物質上的準備。

d、生成測試用例：測試用例的好壞決定著測試工作的效率，選擇合適的測試用例是作

好測試工作的關鍵。在測試文件編製過程中，按規定的要求精心設計測試用例有重要的意義。

e、評價測試結果：測試文件包括測試用例，即若干測試數據及對應的預期測試結果。

完成測試後，將測試結果與預期的結果進行比較，便可對已進行的測試提出評價意見。

f、再測試：測試文件規定的和說明的內容對維護階段由於各種原因的需求進行再測試

時，是非常有用的。

g、決定測試的有效性：完成測試後，把測試結果寫入文件，這對分析測試的有效性，

甚至整個軟體的可用性提供了依據。同時還可以證實有關方面的結論。

(3)測試文件的編製

在軟體的需求分析階段，就開始測試文件的編製工作，各種測試文件的編寫應按一定的

格式進行。

軟體項目風險管理

1 前言

一般來說，軟體工程師總是非常樂觀。當他們在計劃軟體項目時，經常認為每件事情都會像計劃那樣

運行，或者，又會走向另外一個極端。軟體開發的創造性本質意味著我們不能完全預測會發生的事情，因

此制定一個詳細計劃的關鍵點很難確定。當有預想不到的事情引起項目脫離正常軌道時，以上兩種觀點都

會導致軟體項目的失敗。

目前，風險管理被認為是 IT軟體項目中減少失敗的一種重要手段。當不能很確定地預測將來事情的時

候，可以採用結構化風險管理來發現計劃中的缺陷，並且採取行動來減少潛在問題發生的可能性和影響。

風險管理意味著危機還沒有發生之前就對它進行處理。這就提高了項目成功的機會和減少了不可避免風險

所產生的後果。

2 什麼是風險

所謂"風險"，歸納起來主要有兩種意見，主觀說認為，風險是損失的不確定性；客觀學認為，風險

是給定情況下一定時期可能發生的各種結果間的差異。它的兩個基本特徵是不確定性和損失。IT行業中的

軟體項目開發是一項可能損失的活動，不管開發過程如何進行都有可能超出預算或時間延遲。項目開發的

方式很少能保證開發工作一定成功，都要冒一定的風險，也就需要進行項目風險分析。在進行項目風險分

析時，重要的是要量化不確定的程度和每個風險相當的損失程度，為實現這一點就必須要考慮以下問題：

要考慮未來，什麼樣的風險會導致軟體項目失敗？

要考慮變化，在用戶需求、開發技術、目標、機制及其它與項目有關的因素的改變將會對按時交付和

系統成功產生什麼影響？

必須解決選擇問題，應採用什麼方法和工具，應配備多少人力，在質量上強調到什麼程度才滿足要求？

要考慮風險類型，是屬於項目風險、技術風險、商業風險、管理風險還是預算風險等？

這些潛在的問題可能會對軟體項目的計劃、成本、技術、產品的質量及團隊的士氣都有負面的影響。

風險管理就是在這些潛在的問題對項目造成破壞之前識別、處理和排除。

3 風險管理

項目風險管理實際上就是貫穿在項目開發過程中的一系列管理步驟，其中包括風險識別、風險估計、

風險管理策略、風險解決和風險監控。它能讓風險管理者主動"攻擊"風險，進行有效的風險管理。

在項目管理中，建立風險管理策略和在項目的生命周期中不斷控制風險是非常重要的，風險管理包括

四個相關階段：

風險識別識別風險的方法常用的有風險識別問詢法（座談法、專家法）、財務報表法、流程圖法、現

場觀察法、相關部門配合法和環境分析法等。

風險評估對已識別的風險要進行估計和評價，風險估計的主要任務是確定風險發生的概率與後果，風

險評價則是確定該風險的經濟意義及處理的費/效分析，常用的方法有：概率分布、外推法、多目標分析法

等。

風險處理一般而言，風險處理有三種方法，①風險控制法，即主動採取措施避免風險，消滅風險，中

和風險或採用緊急方案降低風險。②風險自留，當風險量不大時可以余留風險。③風險轉移。

風險監控包括對風險發生的監督和對風險管理的監督，前者是對已識別的風險源進行監視和控制，後

者是在項目實施過程中監督人們認真執行風險管理的組織和技術措施。

在 IT軟體項目管理中，應該任命一名風險管理者，該管理者的主要職責是在制訂與評估規劃時，從風

險管理的角度對項目規劃或計划進行審核並發表意見，不斷尋找可能出現的任何意外情況，試著指出各個

風險的管理策略及常用的管理方法，以隨時處理出現的風險，風險管理者最好是由項目主管以外的人擔任。

4 風險識別

風險識別就是企圖採用系統化的方法，識別某特定項目已知的和可預測的風險。常用方法是建立"風

險條目檢查表"，利用一組提問來幫助項目風險管理者了解在項目和技術方面有些風險。在"風險條目檢

查表"中，列出了所有可能的與每一個風險因素有關的提問，使得風險管理者集中來識別常見的、已知的

和可預測的風險，如產品規模風險、依賴性風險、需求風險、管理風險及技術風險等。 "風險條目檢查表"

可以以不同的方式組織，通過判定分析或假設分析，給出這些提問確定的回答，就可以幫助管理或計劃人

員估算風險的影響。軟體項目一般有如下五類風險：

4.1 產品規模風險

有經驗的項目經理都知道：項目的風險是直接與產品的規模成正比的。與軟體規模相關的常見風險因

素有：

估算產品的規模的方法（LOC或代碼行，FP或功能點，程序或文件的數目）。

產品規模估算的信任度

產品規模與以前產品規模平均值的偏差

產品的用戶數

復用的軟體有多少

產品的需求改變多少

4.2 需求風險

很多項目在確定需求時都面臨著一些不確定性和混亂。當在項目早期容忍了這些不確定性，並且在項

目進展過程當中得不到解決，這些問題就會對項目的成功造成很大威脅。如果不控制與需求相關的風險因

素，那麼就很有可能產生錯誤的產品或者拙劣地建造正確的產品。每一種情況都會導致使人不愉快。

與客戶相關的風險因素有：

對產品缺少清晰的認識

對產品需求缺少認同

在做需求中客戶參與不夠

沒有優先需求

由於不確定的需要導致新的市場

不斷變化需求

缺少有效的需求變化管理過程

對需求的變化缺少相關分析

4.3 相關性風險

許多風險都是因為項目的外部環境或因素的相關性產生的。經常我們不能很好地控制外部的相關性，

因此緩解策略應該包括可能性計劃，以便從第二資源或協同工作資源中取得必要的組成部分，並且覺察潛

在的問題。與外部環境相關的因素有：

客戶供應條目或信息

內部或外部轉包商的關係

交互成員或交互團體依賴性

經驗豐富人員的可得性

項目的復用性

4.4 管理風險

儘管管理問題制約了很多項目的成功，但是不要因為風險管理計劃中沒有包括所有管理活動而感到驚

奇。在大部分項目里，項目經理經常是寫項目風險管理計劃的人，並且大部分人都不希望在公共場合暴露

自己的弱點。然而，像這些問題可能會使項目的成功變得更加困難。如果不正視這些棘手的問題，它們就

很有可能在項目進行的某個階段影響項目。當我們定義了項目追蹤過程並且明晰項目角色和責任，就能處

理這些風險因素：

計劃和任務定義不夠充分

實際項目狀態

項目所有者和決策者分不清

不切實際的承諾

員工之間的衝突

4.5 技術風險

軟體技術的飛速發展和經歷豐富員工的缺乏，意味著項目團隊可能會因為技巧的原因影響項目的成功。

在早期，識別風險從而採取合適的預防措施是解決風險領域問題的關鍵，比如：培訓、僱傭顧問以及為項

目團隊招聘合適的人才等。主要有下面這些風險因素：

缺乏培訓

對方法、工具和技術理解的不夠

應用領域的經驗不夠

新的技術和開發方法

不能正確工作的方法

5 風險估計

風險估計，又稱風險預測，常採用兩種方法估價每種風險。一種是估計風險發生的可能性或概率，另

一種是估計如果風險發生時所產生的後果。一般來講，風險管理者要與項目計劃人員、技術人員及其他管

理人員一起執行四種風險活動：

（1）建立一個標準（尺度），以反映風險發生的可能性。

（2）描述風險的後果。

（3）估計風險對項目和產品的影響。

（4）確定風險的精確度，以免產生誤解。

另外，要對每個風險的表現、範圍、時間做出盡量準確的判斷。對不同類型的風險採取不同的分析辦

法。

1．確定型風險估計

（a）盈虧平衡分析

盈虧平衡分析（Break-Even Analysis）通常又稱為量本利分析或損益平衡分析。它是根據軟體項目在

正常生產年份的產品產量或銷售量、成本費用、產品銷售單價和銷售稅金等數據，計算和分析產量、成本

和盈利這三者之間的關係，從中找出它們的規律，並確定項目成本和收益相等時的盈虧平衡點的一種分析

方法。在盈虧平衡點上，軟體項目既無盈利，也無虧損。通過盈虧平衡分析可以看出軟體項目對市場需求

變化的適應能力。

（b）敏感性分析

敏感性分析（Sensitivity Analysis）的目的，是考察與軟體項目有關的一個或多個主要因素髮生變

化時對該項目投資價值指標的影響程度。通過敏感性分析，使我們可以了解和掌握在軟體項目經濟分析中

由於某些參數估算的錯誤或是使用的數據不太可靠而可能造成的對投資價值指標的影響程度，有助於我們

確定在項目投資決策過程中需要重點調查研究和分析測算的因素。

（c）概率分析

它是運用概率論及數理統計方法，來預測和研究各種不確定因素對軟體項目投資價值指標影響的一種

定量分析。通過概率分析可以對項目的風險情況做出比較準確的判斷。主要包括解析法和模擬法（蒙特卡

羅 Monte Carlo技術）兩種。

2．不確定型風險估計

主要有小中取大原則、大中取小原則、遺憾原則、最大數學期望原則、最大可能原則。

3．隨機型風險估計

主要有最大可能原則、最大數學期望原則、最大效用數學期望原則、貝葉斯後驗概率法等。

5.1 建立風險清單

風險清單是關鍵的風險預測管理工具，清單上列出了在任何時候碰到的風險名稱、類別、概率及該風

險所產生的影響。其中整體影響值可對四個風險因素（性能、支持、成本及進度）的影響類別求平均值（有

時也採用加權平均值）。

一旦完成了風險表的內容，就可以根據概率及影響來進行綜合考慮，風險影響和出現概率從風險管理的角

度來看，它們各自起著不同的作用（見圖 1）。一個具有高影響但低概率的風險因素不應當佔用太多的風

險管理時間，而具有中到高概率、高影響的風險和具有高概率及低影響的風險，就應該進行風險分析。

5.2 風險評估

在風險分析過程中，我們對風險進行評估時可以建立一個如下的四元數組：

[ri , li, xi，yi]

其中，ri是風險，li 為風險出現的概率，xi 則表示風險損失大小，yi 則表示期望風險。

一種對風險評估的常用技術是定義風險的參照水準，對絕大多數軟體項目來講，風險因素——成本、

性能、支持和進度就是典型的風險參照系。也就是說對成本超支、性能下降、支持困難、進度延遲都有一

個導致項目終止的水平值。如果風險的組合所產生的問題超出了一個或多個參照水平值時，就終止該項目

的工作，在項目分析中，風險水平參考值是由一系列的點構成的，每一個單獨的點常稱為參照點或臨界點。

如果某風險落在臨界點上，可以利用性能分析、成本分析、質量分析等來判斷該項目是否繼續工作。圖 2 表

示了這種情況。

但在實際工作中，參照點很少能構成一條光滑的曲線，大多數情況下，它是一個區域，而且是個易變

的區域。因而在做風險評估時，盡量按以下步驟執行：

（1）定義項目的水平參照值

（2）找出每組[ri , li, xi，yi]與每個水平參照值間的關係

（3）估計一組臨界點以定義項目的終止區域

（4）估計風險組合將如何影響風險水平參照值

5.3 估計損失的大小

表 1是風險分析表的一個例子，可以建立一個用風險、損失概率、損失大小和期望風險這樣的風險評

估表。

在表 1所示的風險估價的例子中，一個理論項目已經識別了從 1到 20周期間的潛在的幾個風險，風險

發生的概率範圍在 5%到 50%之間。在現實的項目中，可能會識別出比此表要多得多的風險。

損失的大小常常比概率更容易受到控制。在以上的例子中，可以很精確地估計出完全支持自動從主機

更新數據的時間是 20個月。根據管理層將在何時討論項目建議書,可以知道項目不是在 2月 1日就是 3月

1日會被批准。如果假定會在 2月 1日批准，項目被批准的風險大小會比期望的長一些，也就是 1個月時

間。

如果損失的大小不容易直接估計出來，可以將損失分解為更小的部分，再對其進行評估，然後將各部

分評估結果累加，形成一個合計評估值。例如，如果使用 3種新編程工具，可以單獨評估每種工具未達到

預期效果的損失，然後再把損失加到一起，這要比總體評估容易多了。

5.4 評估損失的概率

評估損失的概率要比評估損失大小更具有主觀性。這裡有許多實踐方法可以提高主觀評估的準確度。

有以下方法：

由最熟悉系統的人評估每個風險的發生概率，然後保留一份風險評估審核文件。

使用 Delphi法或少數服從多數的方法。使用 Delphi法，必須要求每個人對每個風險進行獨立地評估，

然後討論（口頭或紙上）每個評估的合理性，特別是最高和最低的那個。一輪輪討論，直到達成共識。 ? 使

用"形容詞標準"。首先讓每個人用表示可能性的形容詞短語選擇風險的級別，如非常可能、很可能、可

能、或許、不太可能、不可能、和根本不可能。然後把可能性的評估轉換為數量化的評估（Boehm1989）。

5.5 整個項目超限和緩衝

實際上，表 1中表示的期望風險的計算數值來源於一個被稱為"期望值"的統計術語。設計欠佳引起

的風險如果真正發生將花費 15周的時間。既然它不是 100%地會發生，當然不能預計損失 15周時間。但它

也不是沒有可能發生，所以也不應指望不會發生損失。統計學認為，預計損失的數量是概率乘以損失大小，

即 15%乘以 15周。因此，在這個例子中，預計的是損失 2.25周。由於只是談論計劃風險，可以累加所有

的風險暴露量來得到項目的全部可預料超標值。這個項目可預料的超標值是 12.8到 13.2周，這就是如果

不做任何風險管理的話有可能超過計劃的周數。

超出預期值的大小為整個項目風險控制級別的確定提供了依據。如果例子中的項目是個 25周的項目，

超出預期值的 12.8到 13.2周就很明顯需要進行風險管理了。

6 風險管理策略

風險管理策略就是輔助項目組建立處理項目風險的策略。項目開發是一個高風險的活動，如果項目采

取積極的風險管理策略，就可以避免或降低許多風險，反之，就有可能使項目處於癱瘓狀態。一般來講，

一個較好的風險管理策略應滿足以下要求：

（1）在項目開發中規劃風險管理，盡量避免風險

（2）指定風險管理者，監控風險因素

（3）建立風險清單及風險管理計劃

（4）建立風險反饋渠道

7 風險駕馭和監控

風險的駕馭與監控主要靠管理者的經驗來實施，它是利用項目管理方法及其它某些技術，如原型法、

軟體心理學、可靠性等來設法避免或轉移風險。風險的駕馭和監控活動可用圖 3 來表示。

7.1 建立風險駕馭與監控計劃

從圖 3中可以看出，風險的駕馭與監控活動要寫入 RMMP（Risk Monitoring and Management Plan風

險駕馭與監控計劃）。RMMP記述了風險分析的全部工作，並且作為整個項目計劃的一部分為項目管理人員

所使用。

風險管理策略可以包含在軟體項目計劃中，也可以組織成一個獨立的風險緩解、監控和管理計劃（RMMP

計劃）。RMMP計劃將所有風險分析工作文檔化，並由項目管理者作為整個項目計劃中的一部分來使用。一

旦建立了 RMMP計劃，且項目開始啟動，則風險緩解及駕馭及監控步驟也開始了。正如前面討論的，風險緩

解是一種問題避免活動。風險駕馭及監控則是一種項目跟蹤活動，它有三個主要目標： ? 判斷一個預測的

風險是否事實、是否發生。

進行風險再估計，確保針對某個風險而制定的風險消除活動正在使用。

收集可用於將來進行風險分析的信息。

風險駕馭及監控的策略如下：

與在職人員協商，確定人員流動原因。

在項目開始前，把緩解這些流動原因的工作列入風險駕馭計劃。

項目開始時，要作好人員流動的思想準備，並採取一些措施確保人員一旦離開時，項目仍能繼續。

制定文檔標準，並建立一種機制，保證文檔及時產生。

對所有工作進行細微詳審，使更多人能夠按計划進度完成自己的工作。

對每個關鍵性技術人員培養後備人員。

在考慮風險成本之後，決定是否採用上述策略。

7.2 軟體項目風險追蹤工具

追蹤風險的一個辦法是將風險輸入缺陷追蹤系統中，缺陷追蹤系統能將風險項目標示為已解決或尚未

處理等狀態，也能指定解決問題的項目團隊成員，並安排處理順序。可將軟體風險項目依序排列出來，按

照缺陷存在的時間與負責者等資料排列。這樣，缺陷追蹤系統就是追蹤風險的工作能更好執行並且不那麼

單調。

8 結束語

軟體項目風險管理是一種特殊的規劃方式，當對軟體項目有較高的期望值時，一般都要進行風險分析。

進行過大中型項目開發的人都親身體驗到許多事情可能出錯，最成功的項目就是採取積極的步驟對要發生

或即將發生的風險進行管理。對任何一個軟體項目，可以有最佳的期望值，但更應該要有最壞的準備，"最

壞的準備"在項目管理中就是進行項目的風險分析。

項目管理學科發展的特點和趨勢

管理是無邊界的大概念，任何事物都需要管理。管理是使事物的發展從混亂、無序走向

有序、有效發展的唯一方法。管理與人類發展並存，人類從原始走向現代，管理也從低級走

向高級，從自發走向自覺，從分散孤立的思想和方法，走向綜合統一的學科體系。這種學科

體系的建立是不斷探索、逐漸完善的過程。項目管理學科的發展也正在經歷著這樣一條發展

的道路。

一、項目管理專業化發展是現代項目管理髮展的三大特點之一

儘管人類的項目實踐可以追溯到幾千年前，但是將項目管理作為一門科學來進行分析研

究，其歷史並不長。從世界第一個專業性國際組織 IPMA 1965年成立至今不過 30多年的時

間。經過這 30多年的努力，目前國際專業人士對項目管理重要性及基本概念已有了初步共

識。分析當前國際項目管理的發展，有三個特點即：全球化的發展、多元化的發展和專業化

的發展。專業化的發展即為三大特點之一。

項目管理的全球化發展

知識經濟時代的一個重要特點是知識與經濟發展的全球化，因為競爭的需要和信息技術

的支撐，促使了項目管理的全球化發展。主要表現在國際間的項目合作日益增多、國際化的

專業活動日益頻繁、項目管理專業信息的國際共享等等。項目管理的全球化發展既為我們創

造了學習的機遇，也給我們提出了高水平國際化發展的要求。

項目管理的多元化發展

由於人類社會的大部分活動都可以按項目來運作，因此當代的項目管理已深入到各行各

業，以不同的類型，不同的規模而出現，這種行業領域及項目類型的多樣性，導致了各種各

樣項目管理理論和方法的出現，從而促進了項目管理的多元化發展。

項目管理的專業化發展

項目管理的廣泛應用促進了項目管理向專業化方向的發展，突出表現在項目管理知識體

系（PMBOK）的不斷發展和完善、學歷教育和非學歷教育競相發展、各種項目管理軟體開發

及研究諮詢機構的出現等等。應該說這些專業化的探索與發展，也正是項目管理學科逐漸走

向成熟的標誌。

二、項目管理學科在雙向探索中發展

自 50年代末，60年代初以來，學術界與各有關專業人士對項目管理的研究基本上在兩

個方向努力。一方面是各領域的專家們在探討本學科在項目管理中有無用武之地，如何將本

學科領域的專業理論、方法應用於項目管理。例如：計算機、控制論、模糊數學等等。另一

方面則是各行各業的專家們在探討如何把項目管理的理論、方法應用到本行業中去。如建築

業、農業、軍事工業以及近幾年呼聲很高的 IT行業等等（見圖一）。

這種雙向探索儘管均出自於外界的需求，但卻極大地促進了項目管理自身的發展。使得

項目管理也在向兩個方向發展：一是向學科化方向發展。項目管理在吸收各學科的有用部分，

逐漸形成一些自己獨立的內容體系。例如：美國 PMI於 1986年提出的項目管理知識體系

（PMBOK），國內外大學所建立的學士、碩士、博士學歷教育體系、成人教育的課程體系等

等。另一方面，為了適應各行業發展的需要，項目管理學科也正在向實用化方向發展，包括

各種方法、工具、標準、法規等等。如 1992年我國的 GB/T 13400.1～13400.3-92,"網路

計劃技術"，國際標準化組織於 1997年推出的 ISO 10006"質量管理—項目管理質量指導"

以及各種計算機應用軟體系統等等。這種跨行業、跨專業、有理論、有實踐的學科發展，進

一步促進了項目管理專業學科—"項目學"的建立和發展。

三、關於項目學發展的幾個趨勢

關於項目學的體系結構，在"時代的呼喚——論項目學的建立"一文中曾有論述。項目

學學科的發展像任何其他學科的發展一樣，其成長和發展需要有一個漫長的過程，而且是永

無止盡的。

其近期的發展趨勢是：

1．項目學的主體是應用項目學，應用項目學的主體是微觀項目管理

任何學科的發展都離不開時代背景，都有客觀環境的制約。當今時代儘管有各種各樣的

項目，對項目的管理也有各種層次，但最基本的是單一項目的管理，也就是我們所說的微觀

項目管理。這種單個項目是國民經濟發展的細胞。它們的數量、類別、複雜程度，規模大小、

周期長短，綜合反映了一個國家的經濟發展程度和科技發展水平。因此微觀項目管理從大的

方面說，是關係到國民經濟發展的重要的因素，從小的方面來說，是各個項目相關單位興衰、

存亡的關鍵，這也是為什麼微觀項目管理在國內外項目管理專業領域受到特別重視的原因。

2．世界各國研究的 PMBOK是當前項目管理學科發展的重要內容

從 80年代以來，世界各國專業人員與組織，紛紛提出了項目管理知識體系（PMBOK）的

問題，PMBOK之所以受到專業學術領域的如此重視，有以下幾方面的原因：

其最主要的原因，在於它跨越了行業的界限。它歸納出的項目管理體系，是各行業的項

目管理人員所必需的基本知識。就像網路計劃技術可以適用於各行各業的計劃管理一樣，

PMBOK總結歸納出的知識體系，也可以適用於各行各業。

有了這一知識體系，對提高項目管理專業人員的水平有極大的促進作用。知識體系與專

業資格認證的結合從某種意義上說也反映了知識經濟時代的特點。

3．項目學是知識創新與市場相結合的綜合化發展

隨著世界經濟由工業經濟向知識經濟的轉變，人們對勞動價值的衡量與評價也發生了變

化。在知識經濟時代，人們將知識通過創新勞動，轉化為產品，投向市場，從而產生經濟效

益。其中極其重要的實現方式就是各種各樣的項目。因此項目學的研究也將在知識、創新和

市場的綜合發展中而逐步發展成熟。

4. 項目學是科學、技術和藝術相結合的綜合

有越來越多的跡象表明，項目管理專家們正以極大的興趣關注著所謂項目的"軟"問

題，諸如項目過程中的思維、行為、情感、適應性、項目管理中的交叉文化問題、項目經理

的領導藝術等等。因此有人說，項目管理是將思想轉化為現實，將抽象轉化為具體的科學和

藝術。

項目管理學科的發展，不管在國內還是國外，都進入了一個超乎尋常的發展速度，她對

於中國經濟的發展，對於西部大開發也必將發揮越來越大的作用，衷心希望國內同行們團結

一致，為提高我國項目管理水平，為促進國內外項目管理的接軌而共同努力。

西邊人西說測試，

頭條號(軟體測試資源站)作者，程序爬蟲獲取國內外測試資源分享給自學愛好者。

今日頭條關注後，私信回復如下關鍵詞獲取大量打包資料下載。

測試資料、工具、Python、自動化測試報告、梯子等

如果需要pdf文檔，私信回復關鍵詞文檔即可