1.項目管理方案

1.1.項目實施方案

本方案提供的功能解決方案已經(jīng)包括了單位辦公系統(tǒng)需求中的所有的系統(tǒng)

模塊。所以，項目實施的重點工作是：在實施過程中要根據(jù)單位管理的實際情況

配置和調整現(xiàn)有軟件功能。從而能夠保證單位整體信息化建設的進度和質量，按

照單位的要求，建設以先進的計算機網(wǎng)絡技術為依托，以業(yè)務流轉為核心，以綜

合信息服務為基礎，以電子郵件、單位內部信息綜合查詢服務、日常行政事務管

理等為內容的綜合辦公管理平臺。

1.1.1.項目實施總體原則

協(xié)同辦公系統(tǒng)一般涉及實施的對象多、范圍廣，我們應明確項目的實施原則：

(1)“總體規(guī)劃、分步實施”

根據(jù)客戶實施應用環(huán)境、培訓后技能水平、實施力量、數(shù)據(jù)和應用等方面狀

況，既要從整體上安排近期、中期和最終目標，又要在具體上有步驟、有目標、

詳細地制訂一個執(zhí)行計劃，分模塊，有重點地一步一步推進，并且這個計劃要滾

動式地、不折不扣地跟蹤考核。

(2)“效益驅動，直點突破”

根據(jù)客戶需求與實施應用環(huán)境，確定一個成功應用點，并作為驅動整個系統(tǒng)

應用的突破口。驅動應用點的選定，關系到客戶走向管理信息化道路的全面啟動

應用。囚此，在選定時，應在容易與復雜、局部與全部、獨立與相關等問題上作

些分析與權衡。

(3)“持續(xù)改進”

通過試點單位和各單位的使用，我們應不斷對該系統(tǒng)進行維護，完善系統(tǒng)功

能，最大限度地滿足客戶實際業(yè)務。

(4)“重點突出、以點帶面”

該項目涉及使用單位較多，不可能同時實施該系統(tǒng)。我們可以選擇重點地單

位，優(yōu)先實施該系統(tǒng)。在實施過程中，還應不斷總結經(jīng)驗和進行功能改進，為大

面積地系統(tǒng)推廣做準咨和經(jīng)驗參考。

(5)“緊密結合、周密計劃”

該系統(tǒng)應與客戶的需求緊密結合，最大程度的滿足實際'業(yè)務需求；制定切實

可行的項目計劃，同時在項目每個階段，負責人也制定細化的階段計劃，作為項

目每個階段的航標，確保項目滿足客戶要求，按時、高質量提交。

在保證軟件實施質量的前提下，側重提高實施效率、成功率和加速項目實施

速度，大幅度地減少客戶費用，縮短實施周期。

1.1.2.項目實施關鍵因素

(1)嚴格按實施體系進行實施

對于大型項目，嚴格按單位的實施體系來實施，以保證項目能在預算范圍內

按時按質地完成，并能進一步豐富實施知識庫，提升單位的實施能力。單位的實

施體系由三部分組成：實施方法論、實施方法和標準實施文檔。

(2)規(guī)范試點、加強培訓

對于應用同一軟件系統(tǒng)的不同單位，我們將建議客戶從中選擇有代表性、有

影響力的單位作為試點單位進行實施，實施成功后，再將成功應用克隆到其他單

位去，為了加快實施的速度、降低實施的成本并提前和待實施的單位進行接觸和

溝通，實施組可以建議客戶采取“集中培訓、現(xiàn)場輔導”的培訓學習方式，如在

對試點單位進行實施的同時，邀請所有需要實施的單位相關人員來參加培訓，培

訓后相關業(yè)務人員需要進一步輔導的，輔導工作在其所在單位進行實施開展。

(3)階段實施、按時驗收

為了保證在實施的過程中有一個階段的實施直點，實施組應該根據(jù)實施主計

劃形成階段實施計戈同時為了讓客戶和所有參與項目的人員能保持高度的激情

和成就感，應該設立里程碑事件，階段實施計劃和里程碑事件都應該能和合同中

要求的驗收條件相一致。

(4)項目管理、團隊協(xié)作

我們應按項目管理的方法來對項目進行管理，所有我方的項目組成員都應

該掌握項目管理的基本方法、項目經(jīng)理應該有大型軟件系統(tǒng)的實施管理經(jīng)驗，并

能將項目組打造成為富有戰(zhàn)斗力和工作激情的團隊，使項目項目組成員在圓滿完

成項目任務的同時對自身的能力得到提升。

1.1.3,本項目實施方案

由于信息化工作過程中會改變原有的工作方式，流程的合理化與再造過程會

對各級使用者產生比較大的觸動，難免會遇到技術和思想上的阻力，所以在實施

過程中需要單位各級領導的參與和支持。在項目的實施中，需要雙方建立項目工

作組，并相互配合協(xié)調，共同完成辦公自動化系統(tǒng)的實施工作。

我們根據(jù)單位辦公系統(tǒng)總體方案，在今后系統(tǒng)的實施過程中，我們都嚴格按

照如卜.項目實施方案進行：

3.1.3.1.項目實施原則

堅持“整體規(guī)劃、分步實施、重點突破”的原則。定義明確的目標、范圍和

進度，并運用現(xiàn)代項目管理方法對項目實施計劃進行優(yōu)化和有效的控制，以最短

的時間、最小的投入來實現(xiàn)項目目標。

3.1.3.2.項目實施方法

單位的項目實施主要面向內部辦公管理，在實施過程中將內部辦公管理和信

息技術有效結合，一方面滿足用戶的工作目標和需求，另一方面通過由很多步驟

組成的規(guī)范化操作過程，實現(xiàn)上述結果。

軟件項目實施方法具體描述了單位實施的原則、方法、J2作規(guī)范等內容，是

我單位開展項目實施工作的主要理論依據(jù)。

3.1.3.3.項目實施主要工作流程

項

目項目實施建議書

前

期確定項目實施主計劃

準

備項目啟動會議

解

關鍵用戶培訓

決

方

需求調研與分析

案

設

項目實施方案書

計

成

用

實

現(xiàn)

系

統(tǒng)

切

換

各階段驗收

項

目

驗項目最終驗收

收

階

移交技術支持部門

段

12項目進度控制

項目的跟蹤與監(jiān)控是在項目執(zhí)行過程所選定的關鍵點或里程碑上，將工作產

品的實際規(guī)模、工作量、成本和進度計劃與項目計劃列出的相比較，以確定工作

進展情況。其目的是，當項目進程明顯偏離計劃時，采取相應調整措施或改進過

程運行效能，從而增加項目過程的透明度，使得對項目的管理能夠起到切實有效

的作用。

L2.L項目進展跟蹤

項目計劃跟蹤周期性的跟蹤任務（含進度和工作量）、費用、資源、工作成果、

風險情況等，及時了解項目的實際進展情況，為持續(xù)過程改進提供有價值的數(shù)據(jù)。

1.2.2.項目例會

項目例會是XXOO公司是常規(guī)項目管理過程的一部分。會議指出活動的實

際狀態(tài)，并與計劃相對照，同時要識別問題；對已知的問題、風險、規(guī)模和進度

進行跟蹤和糾正；識別和記錄新的問題和風險；調整后繼任務計劃并通知受影響

到相關人員。通常每周五下午舉行。項目經(jīng)理每兩周邀請衛(wèi)生局項目組參加或者

直接將例會內容匯報給衛(wèi)生局。

1.2.3.里程碑評審

在項目的早期階段，分別在本項目的需求分析完成時、系統(tǒng)設計完成時、編

碼完成時、項目完成時來設立關鍵里程碑，。在每個里程碑處，也就是在項目組

準備進行下一階段的活動之前，項目經(jīng)理組織里程碑評審。由朝陽區(qū)衛(wèi)生局和監(jiān)

理方參與，了解和監(jiān)督項目的存在的問題，共同判定是否可以進入下一個階段。

本項目共分為5個里程碑，包括需求設計評審、系統(tǒng)設計評審、系統(tǒng)編碼評

審、系統(tǒng)測試和產品發(fā)布評審。

124.項目狀態(tài)報告

由項目經(jīng)理定期完成《項目狀態(tài)報告》。狀態(tài)報告記錄了項目的測量數(shù)據(jù)，通

常包括：標注任務的完成情況、存在問題和重要的項目或配置變更情況。狀態(tài)報

告同時分發(fā)給項目組成員、軟件質量保證人員、測試人員等相關人員。

項目經(jīng)理定期（關鍵里程碑處）向客戶項目組和監(jiān)理方匯報。

1.2.5.項目度量

為了更好地表現(xiàn)項目的當前狀態(tài)，更好地為將來的項目管理積累數(shù)據(jù)，更好

地預測項目，在項目執(zhí)行過程中，需要收集一些數(shù)據(jù)（如計劃變更所花費的時間）。

數(shù)據(jù)的收集需要項目經(jīng)理和其它成員定期進行，收集到的數(shù)據(jù)由項目經(jīng)理和軟件

工程部進行分析，并產生相應文檔。

1.2.6.項目的重估算和重計劃

當項目計劃與實際情況偏離20%以上時，項目經(jīng)理需要重新估算任務的規(guī)模、

成本和工作量、識別風險、并修改計劃或者進度表，修正其它相關文檔。修改方

案要經(jīng)過評審并及時通知相關組。生成《項目il劃變更控制報告》。

1.3.項目質量保證

L3.1.項目質量管理標準

XXOO完全遵循GB/T19001,即2000版IS09001國家標準和美國SEICMM質

量管理體系標準.在所有項目中遵循公司的質量方針：項目全程受控，產品科學

可靠，質量持續(xù)改進，成果多方滿意。實現(xiàn)公司的質量目標：合同執(zhí)行合格率達

100%,顧客滿意率達100%。

以“以顧客為關注焦點，領導作用，全員參與，過程方法，管理的系統(tǒng)方法，持

續(xù)改進,基于事實的決策方法,與供方互利的關系”為質量管理的原則，切實履行

“文件控制程序”，“記錄控制程序”，“管理評審實施程序”，“合同承諾評審程序”,

“設計開發(fā)控制程序”，“采購控制程序”，“項目實施控制程序”等質量管理控制

程序。為項目的質量提供了系統(tǒng)的保障。

1.32項目質量保證的組織管理方法

我們公司在開發(fā)項目上按照規(guī)范化軟件的生產方式進行生產，在生產流程上

采用CMM的標準進行。每個項目除配備了項目開發(fā)所需角色外，還專門配備了配

置管理小組、測試小組和質量保證小組確保質量管理的實施，下面針對這三種角

色進行說明：

1.3.2.L配置管理小組職責

配置管理小組是保證項目開發(fā)完畢的同時，內部文檔和外部文檔都同時

完成。內部文檔的及時產生和規(guī)范，是保證項目開發(fā)各小組能夠更好的接口

和溝通的重要前提，從另一個方面講，也是保證T程不被某個關鍵路徑所阻

塞而延滯的前提。如上所述，配置管理小組還是保證質量保證小組得以發(fā)揮

作用的基礎。配置管理小組的主要職責包括：完善各個部門發(fā)送需要存檔和

進行版本控制的代碼、文檔（包括外來文件）和階段性成果；對代碼、文檔

等進行單向出入的控制；對所有存檔的文檔進行版本控制；提供文檔規(guī)范,

并傳達到開發(fā)組中。

1.3.2.2.測試小組職責

測試小組作為質量控制的主要手段，負責軟件的測試設計和執(zhí)行工作。

如同軟件開發(fā)一樣，測試在執(zhí)行之前，同樣需要進行測試計劃和測試策略的

設計，通常情況下測試可以分為如下幾種類型，如：正確性測試、功能性測

試、性能測試、安全測試和系統(tǒng)測試等。而這些測試均需要在測試計劃和測

試策略中進行描述用以指導測試小組成員進行測試用例編寫和測試執(zhí)行。程

序員在交給測試人員之前是進行過一定的單元測試，確保程序編譯、運行正

確。

測試人員根據(jù)詳細設計的文檔對軟件要實現(xiàn)的功能進行一一測試，保證

軟件的執(zhí)行正確的實現(xiàn)設計要求，在此也只證明了軟件正確的反映了設計思

想，但是否真正反映了用戶的需求仍需要進一步的功能性測試。

測試人員只有根據(jù)軟件需求規(guī)格說明書所提及的功能進行檢測，才能確

保項目組開發(fā)的軟件產品滿足用戶需求。在正確性測試完成之后，需要測試

的是軟件的性能，軟件的性能在本項目中占有重要的地位，性能要求有可能

改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側

重。如果有必要的話，測試小組還需要做安全測試，以確保系統(tǒng)使用安全可

靠。

1.3.23.質量保證小組職責

質量保證小組昨為質量保證的實施小組，主要職責是保證軟件透明開發(fā)

的主要環(huán)節(jié)。在項目開發(fā)的過程中幾乎所有的部門都與質量保證小組有關。

質量保證小組對項目經(jīng)理提供項目進度與項目真正開發(fā)時的差異報告，提出

差異原因和改進方法C

項目進度被延滯或質量保證小組認為某階段開發(fā)質量有問題時，提請項

目經(jīng)理、項目負責人等必要的相關人員舉行質量會議。解決當前存在的和潛

在的問題。質量保證是建立在文檔的復審基礎之上，因而文檔版本的控制，

特別是軟件配置管理，直接影響軟件質量保證的影響力和力度。

質量保證小組的檢測范圍包括：

＞系統(tǒng)分析人員是否正確的反映了用戶的需求；

＞軟件執(zhí)行體是否正確的實現(xiàn)了分析人員的設計思想；

＞測試人員是否進行了較為徹底的和全面的測試；

＞配置管理員是否對文檔的規(guī)范化進行的比較徹底，版本控制是否有效。

133.項目質量保證措施

XXOO公司嚴格遵守在軟件開發(fā)供應和維護中的使用指南中的計算機軟件質

量管理和質量保證標準部分，從管理職責、質量體系、合同評審、設計控制、文

件和資料控制、采購、產品的控制、項目實施控制、不合格品的控制、糾正和預

防措施、質量記錄的控制、內部質量審核、和分析改進的實施、培訓、服務、統(tǒng)

計系統(tǒng)等方面對軟件質量進行了要求和系統(tǒng)管理。

?遵循質量管理的基本原則

以顧客為關注焦點、領導作用、全員參與、過程方法、管理的系統(tǒng)方法、持

續(xù)改進、基于事實的決策方法、與供方互利的關系。

?軟件質量因素

1）正確性：系統(tǒng)滿足規(guī)格說明和用戶目標的程度，即，在預定環(huán)境下能正

確地完成預期功能的程度。

2）健壯性：在硬件發(fā)生故障、輸入的數(shù)據(jù)無效或操作錯誤等意外環(huán)境下，

系統(tǒng)能做出適當響應的程度。

3）效率：為了完成預定的功能，系統(tǒng)需要的計算資源的多少。

4）完整性（安全性）：對未經(jīng)授權的人使用軟件或數(shù)據(jù)的企圖，系統(tǒng)能過控

制（禁止）的程度。

5）可用性：系統(tǒng)在完成預定應該完成的功能時另人滿意的程度。

6）風險：按預定的成本和進度把系統(tǒng)開發(fā)出來，并且為用戶所滿意的概率。

7）可理解性：理解和使用該系統(tǒng)的容易程度。

8）可維修性：診斷和改正在運行現(xiàn)場發(fā)現(xiàn)的錯誤所需要的工作量的大小。

9）靈活性（適應性）：修改或改進正在運行的系統(tǒng)需要的工作量的多少。

10）可測試性：軟件容易測試的程度。

11）可移植性：把程序從一種硬件配置和（或）軟件系統(tǒng)環(huán)境轉移到另一種

配置和環(huán)境時：需要的工作量多少。有一種定量度量的方法是：用原來

程序設計和調試的成本除移植時需用的費用。

12）可再用性：再其他應用中該程序可以被再次使用的程度（或范圍）。

13）互運行性：把該系統(tǒng)和另一個系統(tǒng)結合起來需要的工作量的多少。

1?3?3?1.項目進度的質量保證

項目進度是項目進行是否順利的最直觀表現(xiàn)。要保證項目進度，首先要保證

項目開發(fā)計劃盡可能合理。

在項目計劃制定初期，由質量保證小組組織召開的項目計劃評審會，邀請公

司技術專家、用戶以及項目組成員一起討論項目計劃的可行性，會議上各抒己見,

會后由指定的記錄員形成質量記錄，發(fā)送給相關人員，對其計劃中不合理的地方

進行修改完善，并由質量保證人員對其結果跟蹤，以確保項目計劃完整性、可行

性，完善后的計劃交由配置管理人員進行版本控制。

然而在計劃實施過程中，計劃不是“固定化工項目計劃以里程碑為界限，將

整個開發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當?shù)恼{整每一個較小

的階段的任務量和完成的任務時間，這種方式非常有利于整個項目計劃的動態(tài)調

整。也利于項目質量保證的實施。

實際運作中，當質保小組發(fā)現(xiàn)計劃實施的差異后，報告項目經(jīng)理，由項目經(jīng)

理組織負責對計劃進行周期性維護，對于已經(jīng)變動的計劃由質保小組協(xié)助配置管

理小組完成版本控制。

1?3?3.2.項目開發(fā)各階段的質量保證

13.3.2.1.編制軟件質量保證計劃

軟件質量保證計劃：SoftwareQualityAssurancePlan,簡稱SQAPo

13.3.2.2.變更控制過程

項Fl成員對已創(chuàng)建或維護的工作產品提出變更請求和管理變更時使用的過程。此過

程促進了變更請求在項日成員之間的溝通，以解決變更請求，已報告的問題，以及被提

出變更的結果存在的不確定性提供了共同的過程。示怠圖：

請求變更

掛起

拒絕

結束變更

a.提交《變更申請單》

變更提出者提交《變更申請單》?！缎枨笞兏暾垎巍芬l(fā)送給SCCB的所有

成員。

b.初步判斷變更的可行性

由軟件變更控制委員會（SCCB）的核心成員對變更的可行性進行初步分析和

判斷，檢查變更內容是否合理，描述是否會有歧義?？尚行缘姆治鼋Y果為：

A可行：進入下一個流程。

＞不可行：要說明原因。

c.評估需求變更

SCCB的核心成員給SCCB成員發(fā)出通知，啟動評估活動。評估結果要包含以

下內容：

＞評估的是哪方面的影響。

＞風險。

＞評估工作量時考慮了對哪些配置項的變更。

＞評估的最終結果。

評估結果要提交給SCCB作為決策依據(jù)。

d.做出決策

SCCB的核心人員參考評估結果，對是否接受變更進行決定，結果為：

?接受并實施(Accepted-now):完全接受，并在當前版本實施。

?以后實施(Accepted-later)：完全接受但是要留到后續(xù)版本才實施

的變更申請。

?拒絕變更(Rejected)：說明拒絕的理由。

?掛起(Suspended)：表示懸而未決的變更申請。SCCB應該定期關注

這種狀態(tài)的申請。

?部分接受(Accepted-partial)：說明不接受的理由和內容，并給出

SCCB期望的結果。

此外，SCCB的核心人員還要根據(jù)變更影響的程度決定是否需要對變更后的

需求進行評審.如果需要評審，通知高級經(jīng)理，由高級經(jīng)理組織評審八

最終決策結果要通過郵件通知給所有變更影響人員，并列出下一步的任務和

任務的責任人。

e.變更記錄和執(zhí)行

根據(jù)被變更的需求所處的狀態(tài)，對從需求到當前狀態(tài)涉及到的所有配置項進行修改，在

當前狀態(tài)以后的后續(xù)任務按照正常的流程執(zhí)行，不在變更的跟蹤范圍內。

1.33.2.3.標準、條例和約定

列出軟件開發(fā)過程中要用到的標準、條例和約定，并列出監(jiān)督和保證書執(zhí)行

的措施。

質量管理標準

GB/T19001質量管理體系要求(idtISO9000:2000)

SJ/T11235-2001軟件能力成熟度模型(CMM2級)

計算機軟件工程規(guī)范國家標準

?計算機軟件開發(fā)規(guī)范,軟件技術\、標準號：GB8566-88

?軟件工程犬語\\、標準號：GB/T11457-95

?軟件工程標準分類法'計算機軟件'軟件技術'分類系統(tǒng)\、標準號：

GB/T15538-95

?計算機軟件需求說明編制指南、供應和需求,手冊\、標準號：GB9385-

88

?計算機軟件產品開發(fā)文件編制指南'產品設計'生產'文獻'編輯'手

冊\、標準號：GB8567-88

?計算機軟件開發(fā)規(guī)范'軟件技術\、標準號：GB8566-88

?計算機軟件測試文件編制規(guī)范\文件結構（計算機）'書寫'測量\、標

準號：GB9386-88

?計算機軟件質量保證計劃規(guī)范\、標準號：GB/T12504-90

?計算機軟件配置管理計劃規(guī)范'布置\、標準號：GB/T12505-90

?軟件工程標準分類法'計算機軟件'軟件技術'分類系統(tǒng)'、標準號：

GB/T15538-95

通信行業(yè)標準

?防火墻設各技術要求，編號：YD/T1132-2001；

?數(shù)據(jù)通信名詞術語，編號：YD/T1133-2001；

?數(shù)字數(shù)據(jù)網(wǎng)（DDN）節(jié)點機技術要求及測試方法，編號：YD/T1135-2001；

?綜合業(yè)務數(shù)字網(wǎng)（ISDN）基本速率終端適配器（TA）技術要求及測試

方法，編號：YD/T1136-2001；

?用于局域網(wǎng)與分組交換公用數(shù)據(jù)網(wǎng)互連的網(wǎng)橋/路由器入分組交換

公用數(shù)據(jù)網(wǎng)技術要求和檢測方法、標準號：YD/T869-1996；

?公用分組交換數(shù)據(jù)網(wǎng)工程設計規(guī)范、標準號：YD5022-96；

公安部網(wǎng)絡安全標準

?GA163-1997計算機信息系統(tǒng)安全專用產品分類原則；

?GB17859-1999計算機信息系統(tǒng)安全保護等級劃分準則；

?GB/T17900-1999網(wǎng)絡代理服務器的安全技術要求；

?GB/T18018-1999路由器安全技術要求；

?GB/T18019-1999信息技術包過濾防火墻安全技術要求；

?GB/T18020-1999信息技術應用級防火墻安全技術要求。

1.3.3.2.4.評審和檢查

XXOO公司規(guī)定項目所要進行的技術和管理兩方面的評審和檢查工作，并編

制或引用有關的評審和檢查堆積以及通過與否的技術準則。至少要進行下列各項

評審和檢查工作：

軟件需求評審sofhvarerequirementsreview

在軟件需求分析階段結束后必須進行軟件需求評審，以確保在軟件需求規(guī)格

說明書中所規(guī)定的各項需求的合適性。

概要設計評審preliminarydesignreview

在軟件概要設計結束后必須進行概要設計評審，以評價軟件設計說明書中所

描述的軟件概要設計的總體結構、外部接口、主要部件功能分配、全H數(shù)據(jù)結構

以及各主要部件之間的接口等方面的合適性。

詳細設計評審detaileddesignreview

在軟件詳細設計階段結束后必須進行詳細設計評審，以確定軟件設計說明書

中所描述的詳細設計在功能、算法和過程描述等方面的合適性。

軟件驗證與確認評審softwareverificationandvalidationreview

在制訂軟件驗證與確認計劃之后要對它進行評審，以評價軟件驗證與確認計

劃中所規(guī)定的驗證與確認方法的合適性與完整性。

功能檢查functionalaudit

在軟件釋放前，要對軟件進行功能檢查，以確認已經(jīng)滿足在軟件需求規(guī)格說

明書中規(guī)定的所有需求。

物理檢查physicalaudit

在驗收軟件前，要對軟件進行物理檢查，以驗證程序和文檔已經(jīng)一致并已做

好了交付的準備。

綜合檢查comprehensiveaudit

在軟件驗收時，要允許用戶或用戶所委托的專家對所要驗收的軟件進行設計

抽樣的綜合檢查，以驗證代碼和設計文檔的一致性、接口規(guī)格說明之間的一致性

（硬件和軟件）、設計實現(xiàn)和功能需求的一致性、功能需求和測試描述的一致性。

管理評審managementreviews

要對計劃的執(zhí)行情況定期（或按階段）進行管理評市：這些評審必須由獨立

于被評審單位的機構或授權的第三方一一監(jiān)理公司來主持進行。

1.3.3.2.5.記錄的收集、維護和保存

在項目質量保證的管理過程中，XXOO指明了需要保存的軟件質量保證活

動的記錄，并指出用于匯總、保護和維護這些記錄的方法和設施，并指明要保存

的期限。

1?3?3?3.系統(tǒng)維護的質量保證

在我們公司，技術服務小組的任務一方面是保證對項目客戶的跟蹤服務，另

一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一

個項目的開發(fā)中。所以通常項目技術服務小組成員主要由項目組的少部分開發(fā)人

員和專門的客戶服務部門人員共同承擔完成C他們不僅了解軟件的核心內容，而

且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操

作不當?shù)纫鸬膯栴}，全部由技術服務小組執(zhí)行完成,但需要用戶測試確認上線。

如果較大的修改則需要走變更控制流程，用戶或者技術服務人員填寫變更申請，

經(jīng)專家會議討論分析可行方案在由技術服務小組實施，通過測試后方可提交用戶。

1.3.3.4.配置管理

配置管理一一實施軟件質量管理的關鍵。在質量體系的諸多支持活動中，配置管理處在

支持活動的中心位置，它有機地把其它支持活動結合起來，形成一個整體，相互促進，相互

影響，有力地保證了質量體系的實施。

1.33.4.1,配置管理的基本目標

XXOO公司軟件配置管理的基本目標：

目標1:軟件配置管理的各項工作是有計劃進行的。

目標2:被選擇的項目產品得到識別，控制并且可以被相關人員獲取。

目標3:已識別出的項目產品的更改得到控制。

目標4:使相關組和個人及時了解軟件基準的狀態(tài)和內容。

1.3.3.42軟件配置管理內容

軟件配置管理（SoftwareConfigurationManagement）的目的是在整個軟

件生命周期中建立和維護軟件項目中的產品的完整性。它包括標識在給定時間

點上軟件的配置，系統(tǒng)地控制對配置的更改，并維護在整個軟件生命周期內配置

的完整性和可跟蹤性。因此，軟件配置管理可以分為兩方面的內容，一是配置項

的識別和管理，另一方面是變更管理。

a.配置項管理

軟件的配置項管理的基本流程可如《圖1＞所示，該流程描述了軟件工程組在

進行開發(fā)過程中，生成軟件工作產品，識別配置項，為配置項創(chuàng)建基線。配置管

理項最顯著的特征就是包含版本號或發(fā)布日期。實際項目管理經(jīng)常不知道該如何

識別區(qū)分配置項和基線。

項目啟動

各類項目活動

_____________________

生成軟件工作產品

＜例如；文檔、源代碼）

基線配置項（如：已完成的\廠非基線配置項（如:一、

工件或通過復審的工件》）（正在開詢工件）J

〈圖1＞

b.變更管理

上圖描述了納入配置管理的配置項進行變更的完整流程。根據(jù)新需求、項目

進度報告、客戶意見反饋、軟件工作產品復審記錄等不同的原因提出變更申請,

由項目小組或軟件變更控制委員會（SCCB）分析其影響，確定變更請求的拒絕、

接受或擱置，并根據(jù)不同的決定進行不同的處理，一直到變更請求被處理。

一旦采用了嚴格的變更控制管理流程，才能了解變更造成的影響，所有項目

組成員才了解變更，形成共識，接受變更。缺少對變更有效的控制，往往會造成

配置管理的無序，導致項目返工、延期，甚至失敗。

<圖2>

1.3?3.4.3.軟件配置管理方法

a.項目設定配置管理人員，以VisualSourceSafe為配置管理工具，根據(jù)項

目計劃擬定項目的配置管理計劃文檔，以MicrosoftProject擬定項目配置活動

的進度表。

b.項目的配置管理計劃包含以下內容：配置管理工具、目錄結構、識別配置

項的方法、配置項命名、創(chuàng)建配置管理庫、基線管理、配置審計、配置狀態(tài)報告、

變更管理。

c.在VisualSourceSafe創(chuàng)建項目的VOB（扳本對象庫），創(chuàng)建項目小組成

員的工作區(qū)和集成區(qū)，項目組成員只在各自的工作區(qū)Checkin或Checkout操

作，由配置管理人員進行合并，標識出軟件配置項。

d.由配置管理人員負責在適當?shù)臅r機（如:里程碑處或迭代結束）創(chuàng)建基線，

晉升基線，下降基線，并由其負責備份和恢復基線。

e.根據(jù)配置管理計劃對項目的配置項和基線定期（或里程碑處）進行審計，

以驗證其是否與項目配置計劃或項目開發(fā)計劃一致。

f.所有的變更請求首先向配置管理人員提出，由配置管理人員對變更請求進

行分析確定其影響，組織變更評審小組。

g.一旦同意變更，由配置管理人員Checkout需變更的配置項，然后對配置

項進行變更，變更完成后再由配置管理人員Checkin到配置管理庫中.

h.由軟件質量保證（SQA）人員定期審計配置管理的活動。

1.4.項目風險控制

在項目實施過程中，非常注重項目風險的識別，并根據(jù)識別的風險及時采

取各種應對措施，將項目風險消除在萌芽狀態(tài)，確保能夠按時按質交付滿意的

系統(tǒng)與服務。

1.4.1.項目風險分析

綜合業(yè)務上報系統(tǒng)項目的實施過程中，可能存在著技術風險、和管理風險,

風險的具體內容以及對項目的影響詳見下表:

影響程

序號風險名稱風險分類風險描述風險影響概率風險指數(shù)

度

需求開發(fā)有局

限，模塊范圍項目后期反

1需求風險技術類定義不合理，復修改，進0.66036

或模塊業(yè)務需度、成本增加

求分析不到位

由于測試與修

改組織不利，

2測試風險技術類質量、成本0.63036

造成測試周期

拖延

人力資源項目組人員發(fā)項目進度超

3管理類0.54020

風險生變動期

測試修改周

4編碼風險技術類代碼質量失控0.44016

期延長

公司對項目組

成員增加計劃

項目進度延

5計劃風險管理類外任務安排，0.53015

期

影響項目組原

定計劃的工作

底層關鍵技術

改造無法在預項目進度延

6開發(fā)風險技術類0.53015

訂時間內完全期

實現(xiàn)

注：影響程度按人日估計。

L42項目風險對策

根據(jù)以上風險分析，采取以下幾個方面的措施，確保項目的順利實施。

序號風險名稱風險指數(shù)風險應對策略責任人

1需求風險36需求評審、同類產品對比項目經(jīng)理

優(yōu)化測試修改工作流程，規(guī)范過程

2測試風險36測試負責人

管理

人力資源風確保項目組人員穩(wěn)定，并招聘備選

320項目部經(jīng)理

險人員

項目經(jīng)理、

4編碼風險16制定并落實代碼互查、走查制度

QA

5計劃風險15公司層面避免副總

對關鍵技術排優(yōu)先級，根據(jù)項目時

6開發(fā)風險15項目經(jīng)理

間要求，分步驟推出可運行版本

1.5.項目應急方案

本方案從國產民機運行故隙事故數(shù)據(jù)庫系統(tǒng)及應用平臺項目應急方案的條

款內容、應急計劃的制定、執(zhí)行的環(huán)境和條件要求以及應急條款執(zhí)行時責任和義

務幾個方面進行詳細的規(guī)定。本方案分為數(shù)據(jù)安全應急方案、系統(tǒng)應用應急方案、

運行環(huán)境應急方案。

1.5.1.總流程

L5.1.1.系統(tǒng)出現(xiàn)異常

工作內容：當系統(tǒng)的使用人員和系統(tǒng)技術人員發(fā)現(xiàn)系統(tǒng)在使用中出現(xiàn)問題和隱患

時，應立即上報專門的系統(tǒng)管理員。

責任人：使用人員和系統(tǒng)技術人員。

工作成果：必要時可法行書面匯報。

L5.1.2.評估問題和劃分

工作內容：當系統(tǒng)管理員接到問題匯報時，應在一定的時限內進行處理，分析系

統(tǒng)出現(xiàn)問題的原因，并將問題進行大體的分類，判斷是否啟動應急處理流程方案

和啟動那一類應急處理方案和流程。

責任人：系統(tǒng)管理員。

工作成果：對問題進行描述和分析。

工作建議：系統(tǒng)管理員如果對問題的評估歸類有困難，在項目質保期內可要求項

目乙方幫助處理。

1.5.13.數(shù)據(jù)安全應急

1.5.L3.1.數(shù)據(jù)安全問題

工作內容：系統(tǒng)管理員分析系統(tǒng)出現(xiàn)的數(shù)據(jù)安全訶題，對問題進行具體的定位。

責任人：系統(tǒng)管理員。

工作成果：對問題進一步描述。

工作建議：系統(tǒng)管理員如果對問題的具體定位有困難，在項目質保期內可要求項

目乙方幫助處理。

1.5.1.3.2.啟動數(shù)據(jù)安全應急方案

工作內容：執(zhí)行數(shù)據(jù)安全應急處理方案。

責任人：系統(tǒng)管理員。

工作成果：問題已經(jīng)處理，并對處理過程進行詳細記錄。

工作建議：系統(tǒng)管理員如果對問題的處理有困難，在項目質保期內可要求項目乙

方幫助處理“

L5.1.4.系統(tǒng)應用應急

1.5.L4.1.系統(tǒng)應用問題

工作內容：系統(tǒng)管理員分析系統(tǒng)出現(xiàn)的系統(tǒng)應用句題，對問題進行具體的定位。

責任人：系統(tǒng)管理員。

工作成果：對問題進一步描述。

工作建議：系統(tǒng)管理員如果對問題的具體定位有困難，在項目質保期內可要求項

目乙方幫助處理。

1.5.1.4.2.啟動系統(tǒng)應用應急方案

工作內容：執(zhí)行系統(tǒng)應用應急處理方案。

責任人：系統(tǒng)管理員。

工作成果：問題已經(jīng)處理，并對處理過程進行詳細記錄。

工作建議：系統(tǒng)管理員如果對問題的處理有困難，在項目質保期內可要求項目乙

方幫助處理。

1.5.1.5.運行環(huán)境應急

1.5.1.5.L運行環(huán)境問題

工作內容：當系統(tǒng)管理員分析系統(tǒng)出現(xiàn)的系統(tǒng)運行環(huán)境問題，對問題進行具體的

定位。

責任人：系統(tǒng)管理員。

工作成果：對問題進一步描述。

工作建議：系統(tǒng)管理員如果對問題的具體定位有困難，在項目質保期內可要求項

目乙方幫助處理。

1.5.1.5.2.啟動系統(tǒng)應用應急方案

工作內容：執(zhí)行運行環(huán)境應急處理方案。

責任人：系統(tǒng)管理員。

工作成果：問題已經(jīng)處理，并對處理過程進行詳細記錄。

工作建議：系統(tǒng)管理員如果對問題的處理有困難，在項目質保期內可要求項目乙

方幫助處理。

L5.1.6,其他情況應急

1.5.L6.1,其他未知問題

工作內容：當系統(tǒng)出現(xiàn)意外的緊急問題時，即本應急方案未制定該問題的事先應

急方案時，系統(tǒng)管理員應對本問題劃分為“其他未知問題”，并上報相關主管領

導。

責任人：系統(tǒng)管理員。

工作成果：對問題進行詳細的描述。

工作建議：系統(tǒng)管理員如果對問題的具體定位有困難，在項目質保期內可要求項

目乙方協(xié)助處理。

1.5.1.6.2.指定臨時應急方案

工作內容：針對出現(xiàn)的意外問題制定相應的應急方案。

責任人：相關主管領導。

工作成果：應急方案。

工作建議：在項目質保期內可要求項目乙方幫助處理。

1.5.1.6.3.進行處理

工作內容：執(zhí)行意外問題應急方案。

責任人：相關主管領導。

工作成果：問題己解決，并對處理過程進行詳細」,己錄。

工作建議：在項目質保期內可要求項目乙方協(xié)助。

L5.1.7.處理結果記錄歸檔管理

工作內容：需要對問題的過程的記錄進行歸集,對處理結果進行記錄并歸檔管理。

責任人：系統(tǒng)管理員。

工作成果：問題處理過程和結果記錄。

1.5.2.數(shù)據(jù)安全應急方案

1.5.2.1.非法入侵

情況描述：網(wǎng)絡管理員或系統(tǒng)管理員發(fā)現(xiàn)有非法用戶登錄系統(tǒng)，登錄系統(tǒng)后

非法執(zhí)行系統(tǒng)功能，并篡改系統(tǒng)數(shù)據(jù)時，視為緊急情況。

應對方案：

1).如果系統(tǒng)管理員處理此情況有困難，可要求應用軟件實施商幫助處

理；

2).如果能夠根據(jù)系統(tǒng)的相關日志進行針對性恢復，則屬上策；

3).否則，將系統(tǒng)恢復到最近的一個備份點；

4).注意：盡量不要整庫恢復，一定要將損失降到最低，至少要能定位

到數(shù)據(jù)表進行恢復；

5).注意：必須將系統(tǒng)數(shù)據(jù)恢復到應用系統(tǒng)認可的數(shù)據(jù)同步狀態(tài)，即恢

復后要進行相關的功能測試。

1.5.2.2.數(shù)據(jù)崩潰恢復

情況描述：網(wǎng)絡管理員或系統(tǒng)管理員發(fā)現(xiàn)數(shù)據(jù)庫管理系統(tǒng)遭到嚴重破壞時,

并且試圖進行各種技術處理無法恢復時，視為本緊急情況。

應對方案：

1).如果系統(tǒng)管理員處理此情況有困難，可要求應用軟件實施商幫助處

理；

2).重新安裝和配置數(shù)據(jù)庫服務器；

3).將系統(tǒng)恢復到最近的一個備份點。

1.5.2.3.遠程容災

情況描述：當發(fā)生非常意外情況導致本地數(shù)據(jù)和設備完全遭到破壞時，視為

本緊急情況。此時啟動遠程容災應急方案。

應對方案：

1).應該事先建立異地系統(tǒng)備份機制，否則，本方案無法執(zhí)行；

2).將系統(tǒng)切換到異地服務器繼續(xù)運行應用系統(tǒng)；

3).重新建立總部數(shù)據(jù)中心；

4).根據(jù)有關數(shù)據(jù)庫服務協(xié)議，要求數(shù)據(jù)庫供應商提供數(shù)據(jù)恢復技術服

務；

5).應用ORACLE遠程備份系統(tǒng)恢復數(shù)據(jù)庫。

1.5.3.系統(tǒng)應用應急方案

1.5.3.1.非法入侵

情況描述：網(wǎng)絡管理員或系統(tǒng)管理員發(fā)現(xiàn)有非法用戶登錄系統(tǒng)，或者登錄系

統(tǒng)后非法執(zhí)行系統(tǒng)功能，視為本緊急情況。

應對方案：

1).網(wǎng)絡管理員或系統(tǒng)管理員應及時保護操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、中間

件系統(tǒng)和應用軟件系統(tǒng)的相關日志；

2).檢查系統(tǒng)重要數(shù)據(jù)是否被非法篡改；

3).及時邀請項目的應用軟件實施商到現(xiàn)場，進行評估和處理；

4).評估安全問題出現(xiàn)在那個環(huán)節(jié)，判斷問題的嚴重行，決定是否需要

咨詢信息安全專家，并進行處理；

5).評估應用軟件實施商應該進行那些系統(tǒng)安全方面的改進；

6).應制定一個臨時應對措施。

1.5.3.2.系統(tǒng)崩潰恢復

情況描述：網(wǎng)絡管理員或系統(tǒng)管理員發(fā)現(xiàn)應用系統(tǒng)遭到嚴重破壞時，并且試

圖進行各種技術處理無法恢復時，視為本緊急情況。

應對方案：

1).如果系統(tǒng)管理員處理此情況有困難，可要求應用軟件實施商幫助

處理。

2).重新安裝中間件系統(tǒng)；

3).重新配置安裝中間件系統(tǒng)：

4）.安裝和配置應用系統(tǒng)的中間層組建;

5）.對系統(tǒng)進行全面測試。

1.5.4,運行環(huán)境應急方案

L5.4.1.網(wǎng)絡緊急情況

情況描述：網(wǎng)絡系統(tǒng)，包括保障系統(tǒng)運行的局域網(wǎng)、廣域網(wǎng)和相關的網(wǎng)絡設

備出現(xiàn)故障或可靠性嚴重下降時，視為本緊急情況。

應對方案：

在力所能及的職權范圍內，啟動本管理流程：

推薦采用冗余網(wǎng)絡。中心服務器到下屬單位的之間平常使用電力城域網(wǎng)

連接，另外可考慮使用電信的ADSL或DD7專線，通過加密的VPN設備

形成第二條輔助的VPN專網(wǎng)。當電力網(wǎng)絡繁忙或出現(xiàn)故障時，用戶客戶端

可通過輔助網(wǎng)絡連接。從而不影響正常業(yè)務工作。

網(wǎng)絡方面如下應急方案：

1）當客戶端連接服務器時，經(jīng)過長時間等待后，報服務連接失敗的錯

誤。此時有可能是網(wǎng)絡不通。請安如下步驟操作：

首先請嘗試ping本地局域網(wǎng)的其它計算機，如果不通，請聯(lián)系相關部

門及時處理。如果能連通，請ping總部的應用服務器，如果能通，則可能

屬于軟件系統(tǒng)的故障，尋求軟件實施商的幫助。如果不通，可能是總部網(wǎng)

絡故障。請求總部相關的系統(tǒng)管理員解決，并啟用備用網(wǎng)絡連接。

2）當客戶端連接時，出現(xiàn)了數(shù)據(jù)庫連接失敗的提示時，請ping數(shù)據(jù)庫

服務器，如果不通，可能是數(shù)據(jù)庫群集的網(wǎng)絡出現(xiàn)故障，請求總部相關

的系統(tǒng)管理員解決。如果能連通，可能是數(shù)據(jù)庫故障。

3）要考慮對網(wǎng)絡設備的冗余,對網(wǎng)絡設備進行備份，主要是對交換機、

防火墻、路由器等設備采用備份策略，解決網(wǎng)絡設備的單點故障，保證

網(wǎng)絡可靠的運行。

4）根據(jù)網(wǎng)絡設備的售后服務協(xié)議，及時進行維修。

5）如果是線路故障，也要及時通知有關部門進行維修。

L5.4.2,服務器和其他硬件緊急情況

情況描述:數(shù)據(jù)庫服務器、中間件服務器、域控制器等硬件設備出現(xiàn)故障時，

視為本緊急情況。

應對方案：

1).如果是一人硬件服務器出現(xiàn)故障時，系統(tǒng)將癱瘓，如果系統(tǒng)是熱備或

群集，當發(fā)現(xiàn)出現(xiàn)其中一個硬件服務器出現(xiàn)問題時，系統(tǒng)雖能工作，