《項目名字》

投標文件

投標單位：XXXXXXXXXXXX（蓋章）

法定代表（授權）人：（簽字）

YYYY年MM月DD日

目錄

第一章投標函.............................................................................I

第二章法人代表人授權書..................................................................2

第三章投標資格文件.....................................................................3

第四章軟件開發實施技術方案............................................................16

第五章軟件銷售合同范本.................................................................67

第六章軟件功能清單.....................................................................77

第七章軟件報價表......................................................................105

第八章培訓方案........................................................................107

第一章投標函

XXXXXXXXXXX有限公司：

我公司收到貴公司《XXXXXXX采購項目招標文件》，經詳細研究我們同意并遵從招標文件所

有規定，

參與投標，為此我方謹鄭重聲明一下諸點，并對之負法律責任。我方愿意按照招標文件要求承

接項目量清單內的工作內容，我單位的投標報價總金額為人民幣元（大寫:）

一旦我方中標，我公司保證執行投標文件和雙方簽訂的經濟合同規定，按期保質保量生產和安

裝任務并為之承擔全部責任和義務。

我們愿意提供招標文件要求的所有資料，投標書在開標后90天內有效。除非貴我雙方另外達

成協議并有效，

招標人的中標通知及本投標文件將構成約束我們雙方的合同規定。

我們理解你們有選擇或拒絕任何投標者中標的權利，無需向落標者作任何落標原因的解釋，我

司絕無任何異議。

貴公司有權授予全部或部分工作內容給中標的承包商。

我們完全同意，我們所投遞的投標文件已充分考慮了各種外部因素對報價的影響。

所有有關本投標書的函電，請按下列地址聯系：

投標單位（共章）：

單位地址：郵政編碼：

法定代表人（簽字、蓋章）：

聯系人：電話'傳真：

開戶銀行：銀行賬號：

銀行地址：銀行電話：

第二章法定代表人授權書

XXXXXXXXXX有限公司公司：

本授權委托書聲明：我XXX系XXXXXXXXXXXXX的法定代表人。

現授權委托XXXXXXXXXXXXX的XX為我司代理人。全權代表我司處理投標的有關事項。

代理人在開標、評標、合同談判過程中所簽署的一切文件和處理與之有關的一切事務,我均予以承

認。

代理人無權轉委托其他人代理。

特此委托

代理人；性別;年齡:

身份證號：

單位：部門：職務：

通訊地址：

電話：傳真:

投標單位（公章）

法定代表人（簽字蓋章）：

YYYY年MM月DD日

2

第三章投標資格文件

3.1.公司簡介

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

3.2.近期部分項目業績一覽表

合同金額

序號項目名稱合同開始時間服務公司名稱項目使用地址

（萬元）

1XXXXXXXMWMMMYYYY年MM月XXXX

3

2XXXXXXXMMVMMMYYYY年MM月XXXX

3xxxxxxxMWMMMYYYY年MM月XXXX

4XXXXXXXMMVMMMYYYY年MM月XXXX

5xxxxxxxMMRfMMMYYYY年MM月XXXX

6xxxxxxxMMMMMMYYYY年MM月XXXX

7xxxxxxxMMMMMMYYYY年MM月XXXX

4

8XXXXXXXYYYY年MM月XXXX

承諾單位簽字/蓋章：

3.3.營業執照

3.4.軟件著作權

3.5.稅務登記證

3.6.IS09001質量管理體系認證證書

3.7.雙軟認證證書

3.8.AAA級信用單位

第四章軟件開發實施技術方案

4.1.系統開發組織

軟件項目的組織結構如圖:

5

項目經理

【圖：軟件項目組織結構】

項目由項目經理負責。整個項目組下設需求組、設計組、開發組、測試組、配置管理組、文檔

組和質量控制組（SQA小組）。

其中質量控制組負責整個項FI的質量控制，關鍵階段評審的組織工作等，可以由公司項目管理

人員和用戶方共同組成。需求組由于需要確定用戶的需求，并對需求進行分析，因此也需要用戶參

與。用戶可以根據自己要求和實際情況，有選擇的加入設計組。

4.1.1.職責與權限

各組的職責與權限如卜.:

人員、角色職責權限

負責與客戶的溝通協調，組織項目的設備采購、安裝、

項目經理調試等工作,完成系統的驗收交付。

對項目成敗全權負責，有權限對進度和人員進行調整

負責和用戶進行訪談，編寫需求說明書，準確、完整

需求人員

的記錄用戶的需求，并對業務提出合理建議

負責系統整體結構的設計，包括功能模塊的劃分、數

分析設計人員

據庫結構設計、通用代碼以及重要技術專題的解決

6

開發人員負責系統的詳細設計和開發工作

負責根據需求編寫測試計劃和測試用例，并完成單元

測試人員

測試、集成測試、系統測試，是軟件產品的交付的出口

負責系統的安裝部署、運行維護和故障排除。解決用

技術支持人員

戶在日常應用終于到的問題。

負責開發過程中的配置管理，采用先進的配置管理工

配置管理人員

具，進仃版本控制、配置變更通知等

質量控制組是整個項目的監督機構，負責按照

質量控制人員

IS09001的標準要求各個小組，組織各個階段的階段性評

(SQA)

審，并負責對數據的收集和整理

文檔組負責對項目+各階段的開發文檔進行整理和

文檔人員

管理

4.1.2.項目組人員說明

姓名本項目擬任崗位年齡性別專業年限職務和職稱

7

人員簡歷表

4.2.項目概述

積分商城管理系統，包括（手機端APP、小程序）實現線上到線下服務體系的全網打通，通過

信息化手段、互聯網技術，研發面向用戶的換購、換住、換游服務平臺，為用戶提供豐富的企業服

務，在線進行兌換、購買。商家可自行管理線上服務、產品、統計分析營銷數據，為自身及平臺的

升級、迭代提供數據。

8

項目名稱：積分商城管埋系統

4.3.系統整體框架

系統選取JAVA作為開發語言，保證系統具有跨平臺性和可移植性.并選取Spring技術枚作為開發

框架，采用MVC設計模式.并采用微服務進行架構，選擇springcloud技術棧,docker容器作為微服務的

支撐.初步將系統劃分為三個層級:業務級（提供具體的業務邏輯），基礎服務（為微服務提供最基本的服

務支撐），.采用前后端分離的模式，所有數據通過RestAPI進行交互.接口全部采用HTTPS協議,并對傳

輸數據進行AES加密,以確保API的安全性.并對基礎服務進行才分，為上層業務模塊提供支持.對于系

統主體方面，將每個微服務進行docker容器化管理,并采用Kubemetes對容器進行編排管理.方便業務

集群管理.

業務架構總體描述：

系統業務架構整體分為三層,Client主要為客戶提供接觸的“界面”，業務層則是支撐前臺高效

運轉，并將業務邏輯進行合理的，顆粒度足夠的戈U分,既保證獨立性.方便后期維護升級?運維管理層，提

供日志收集,消息隊列管理，容器編排等服務.

選擇SpringCloud微服務的理由：

SpringCloud來源于Spring,質量、穩定性、持續性都可以得到保證

SpirngCloud天然支持SpringBoot,更加便「業務落地。

SpringCloud是Java領域最適合做微服務的框架。

相比于其它框架,SpringC：oud對微服務周邊環境的支持力度最大。

對于中小企業來講，使用門檻較低。

SpringCloud架構圖

9

Docker:

Docker是一個開源的應月容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的

容器中，然后發布到任何流行的Linux機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相

互之間不會有任何接口。

采用Dockei'開發微服務的優勢：

隔離，抽象，可移植性

容器是操作系統內存中的應用隔離，我們并不知道這些相關的服務是不是運行在同一個機器上,

通過容器抽象來共享主機的操作系統資源。得益于Docker,我們可以從頭建立一個分布式應用，根

據應用的需求定制環境，并復用在所有Docker主機上。還可以省去不重要安裝，環境依賴，將環境

改變控制在容器內，從而保持操作系統的「純凈J。

輕量級

10

Docker輕量級，開銷很少，這使得它成為?個開發immutableinfrastructure的絕佳_L具，并且所

有組件都很容易被替代。使用Docker可以在同一臺主機上運行更多的服務和應用，不會產生性能損

失和額外的容量。

版本化的鏡像

Docker通過Docker鏡像來交付環境，你可以用Docker的強大的tag機制指定你的鏡像的版本。

這意味著你可以版本化你的整個微服務環境，不管你的應用s用是Java、Python>Ruby還是其它完

全獨立于主機操作系統的語言寫的，都可以擁有一個同質的打包系統。

4.3.1.

Docker組件是可以重用的。之前精心設計的鏡像，可以通過baseimge被重用，并且不需要從

零開始構建。

可測試

Dockerfile描述了Docker的環境，以及能夠使我們的應用運行于其上的必要的步驟。每次Docker

構建的過程，都是對這個步驟的測試，測試其能否為我們的應用程序執行創建一個完美的運行環境。

DevOps的思維方式

得益于上述幾點，開發團隊更容易從傳統思維過渡到DevOps的思維方式，關注完整的軟件交

付生命周期。Docker可以將IT運維部門從一個繁忙的、簡易的交付批準/拒絕導向的團隊，變成一

個有效率的，交付授權的部門，而且開發人員可以在容器內定制自己的運行環境，同時不會影響其

他應用。

Kubemetes:

Kubemetes是Google團隊發起并維護的開源容器集群管理系統，支持如Docker等容器技術。使

用Kubernetes,我們可以輕松搭建和管理一個私有容器云。對容器進行可視化管理與編排

11

4.4.平臺整體設計方案

4.4.1.整體框架

3000+生活

商家端用戶端

商家前端

訂

訂

訂

單

單

單

通

管

驗

理

證

知

12

4.4.2.用戶端

13

4.4.3.商家端

4.5.項目建設依據及原則

本項目涉及到系統必須以實用為原則。采用成熟的并且通過實踐考驗的先進技術和解決方案。

4.5.1.功能性

與一組功能及其指定的性質有關的一組屬性，具體包括：

適合性：與規定任務能否提供一組功能以及這組功能的適合程度有關的軟件屬性。

準確性：與能否得到正確或相符的結果或效果有關的軟件屬性。

互用性：與同其他指定系統進行交互的能力有關的軟件屬性。

依從性：使軟件遵循有關的標準，約定，法規及類似規定的軟件屬性。

安全性：與防止對程序及數據的非授權的故意或意外訪問的能力有關的軟件屬性。

充分考慮系統的安全防護，具備較強的數據管理機制和控制能力

14

4.5.2.可靠性

與在規定的一段時間和條件下，軟件維持其性能水平的能力有關的一組屬性，具體包括：

成熟性：與由軟件故障引起失效的頻度有關的軟件屬性。

容錯性：與在軟件故障或違反指定接口的情況下，維持規定的性能水平的能力有關的軟件屬性。

易恢復性：與在失效發生后，重建其性能水平并恢復直接受影響數據的能力以及為達此目的所

需的時間和能力有關的軟件屬性充分考慮性價比。

4.5.3.易用性

與一組規定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作用的評價有關的一組屬

性，具體包括：

易理解性：與用戶為認識邏輯概念及其應用范圍所花的努力有關的軟件屬性。

易學性：與用戶為學習軟件應用所花的努力有關的軟件屬性。

易操作性：與用戶為操作和運行控制所花努力有關的軟件屬性。

4.5.4.效率

與在規定的條件下，軟件的性能水平與所使用的資源量之間關系有關的一組屬性，具體包括：

時間特性：與軟件執行其功能時響應和處理時間以及吞吐量有關的軟件屬性。

資源特性：與在軟件執行其功能時所使用的資源數量及其使用時間有關的軟件屬性。

4.5.5.可維護性

與進行指定的修改所需的努力有關的一組屬性，具體包括：

易分析性：與為診斷缺陷或失效原因急為判定待修改的部分所需努力有關的軟件屬性。

易改變性：與進行修改，排除錯誤或適應環境變化所需努力有關的軟件屬性。

穩定性：與修改所造成的未預料結果的風險有關的軟件屬性。

易測試性：與確認已修改軟件所需的努力有關的軟件屬性。

15

4.5.6,可移植性

與軟件可從某一環境轉移到另一個環境的能力有關的一組屬性，具體包括：

適應性:與軟件無需采用有別于為該軟件準備的活動或手段就可能適應不同的規定環境有關的

軟件屬性。

易安裝性:與在指定環境下安裝軟件所需努力有關的軟件屬性。

遵循性:使軟件遵循與可移植性有關的標準或約定的軟件屬性。

易替換性:與軟件在該軟件環境中用來替代指定的其他軟件的機會和努力有關的軟件屬性。

4.5.7.標準化

本項目涉及到的各個系統模塊設計、系統性能、代碼編寫等應符合中國有關軟件項目的標準化的要求：

1.軟件開發過程中作業標準化。

2.確定每個作業的表示形式。

3.確定每個文檔資料的格式。

4.規定組符號。

5根據軟件開發經驗，制定出大家能夠接受的開發原則和進度.

4.6.嚴格的項目開發流程

4.6.1.開發流程概述

公司在軟件項目的開發中，將完全遵循IS09001質量體系的要求，保證開發過程的規范性和產

品的質量。

為了保證產品質量，提高用戶滿意度，公司的開發流程中采取了以下措施：

1、階段性評審

開發采用SQA模式，設立SQA組專職進行質量控制。在每個關鍵里程碑結束之前，需要通過

質量控制組（SQA）組織的評審，從而保證每一階段的正確性，避免由于設計失誤造成項弓失敗。

16

2、完善的測試，具和方法

公司特別加強了測試組的實力，通過JIRA等工具的使用，在測試階段的出現的問題均通過系統

管理。測試人員從需求分析階段就加入到項目組中，在概要設計階段完成測試計劃和測試用例，保

證測試的全面性和正確性。

3、配置管理

配置管理是保證工程質量的一個重要環節，配置管理貫穿公司整個開發流程。由專人負責配置

的管理和變更控制，對于配置產生的變更，配置管理組負責通知整個項目組，同時進行產品的版本

控制。

4、變更控制

在國內進行的軟件項目中，60%以上失敗的原因來自于需求變更的失控，對于一個大的軟件項

目，需求分析是一個困難漫長的過程，為了解決這個問題，采取了以下措施：

?按業務劃分模塊，分步進行需求調研和分析

?需求分析中完成系統原型，提供給用戶確認

?需求分析的評審用戶需要參加

?對于需求變更需要提出變更申請，通過評審方能變更

?影響開發基線的變更，變更的里程碑也要再次進行評審

需求變更的控制，不僅能夠提高產品的質量，還能夠降低項目的成本和風險，一個完整的項目

變更，應該是可以追溯、測量和控制的，只有做好了項目的需求變更，才能真正把握整個項FI的開

發過程。

4.6.2.項目策劃階段

一、職責

項目經理負責整個項目

17

項目經埋負責制定_L作計劃和項目實施

項目組負責項目開發計劃的執行，公司其他部門作相應的配合

二、工作程序

?項目組的確定

公司總經理指定項目負責人，成立項目組

?項目開發策劃

令項目經理負責依據開發任務、項目相關的合同、標書及其它相關信息對項目進

行開發策劃。

令項目經理對項目開發策劃結果按《項目計劃編寫規范》編制《項目開發計劃書》0

?《項目開發計劃書》內容

＜設計開發輸入、輸出，評審，驗證、確認等各階段的劃分和主要工作內容。

。項目資源的組織管理：各階段人員職責，權限，設備、資金保證、配合單位及

其他相關內容等。

令項目確認方式、交付期限、驗收標準。

＜項目進度要求。

?設計開發的接口管理

令項目經理負責設計開發活動組別或人員之間的接口管理，在公司內部網上或會

議進行溝通，協調。

令項目經理明確與顧客溝通責任人員。

?《項目開發計劃書》的評審

令《項目開發計劃書》的評審由質量保證組組織有關人員進行，質量保證組負責

人審批匕，按《設計評審程序》實施。

?項目管理

。項目經理負責設計任務的分配，根據《項目開發計劃書》向項目組成員下達開

發任務。

令項目成員按各自分配任務實施。

＜項目經理按《項目實施流程說明書》對開發過程進行管理。

?項目開發計劃的跟蹤監督

令質量保證組(SQA)負責對項目開發計劃進度和質量進行日常檢查和督促c

18

?形成的記錄

令保留項目開發策劃中形成的質量記錄，待項目結束后，由項目經理將所形成的

質量記錄移交經理辦公室歸檔。

三、工作成果

《項目開發計劃書》

4.6.3.需求分析階段

一、職責

?需求組負責編制《軟件需求規格說明書》

?質量保證組（SQA）負責審批《軟件需求規格說明書》，并對需求分析活動是否符合質量體

系的要求進行跟蹤監督。

二、工作程序

?需求來源

令軟件開發計劃；

?上一版本軟件的優點和不足；

令市場需求和顧客需求；

?其他同類產品的功能特點；

?同類產品的技術發展方向。

?需求分析

?在《項目開發計劃書》批準后，由項目管理組聯系用戶進行訪談。

＜項目組根據合同和用戶訪談的要求和需求來源的相應信息及合同文本、標書、立項報告、

適用的法令法規要求、對用戶的調研資料等進行顧客需求的詳細分析。

令需求分析的結果形成《軟件需求規格說明書》和《軟件功能需求說明書》，附有各類相關

資料。

?《軟件需求規格說明書》和《軟件功能需求說明書》的編制

＜根據分析結果，由項目組成員按照《軟件需求編寫規范》編制《軟件需求規格說明書》和

《軟件功能需求說明書》，必要時，編制成員可以包括顧客代表。

?《軟件需求規格說明書》主要從業務角度描寫用戶工作流程

令《軟件功能需求說明書》主要從功能角度描寫每個具體功能，包括以下幾點：

/功能說明，包括業務簡述，功能流程等

19

/界面說明，描述用戶操作界面

/數據要求，描寫本功能對數據的操作要求

?需求評審

?當《軟件需求規格說明書》編制完成后，要對需求的正確性、完整性、清晰性以及其他質

量要求進行設計評審。

令需求評審由質量保證組組織實施，參加人員可包括：質量保證組人員、項目組骨干人員、

顧客代表，必要時，還可以包括有關專家。需求評審的具體程序見《設計評審程序》。

＜評審通過后，質量保證組審批，項目組依據《項目開發計劃書》實施。

?需求分析的跟蹤監督

＜由質量保證組負責對需求分析實施過程是否符合《項目開發計劃書》。實施的結果能否達

到《軟件需求規格說明書》的要求進行跟蹤監督，保留監督記錄。

?形成的記錄

令項目組保留項目需求分析過程中形成的相關記錄，待項目完成后將相關記錄移交經理辦公

室。

三、階段成果

《軟件需求規格說明書》

4.6.4.概要設計階段

一、職貢

?設計組負責概要設計、詳細設計和編碼。

?項目經理對開發過程進行管理。

?測試組對參與此階段，并完成測試設計。

?質量保證組對設計是否符合計劃的安排進行跟蹤監督。

二、工作程序

?系統概要設計

令需求分析完成后，設計組根據評審通過的《軟件需求規格說明書》進行系統概要設計。

?系統概要設計的主要任務是確定系統的具體實現方案，系統的結構設計。

令系統概要設計的結果形成《概要設計說明書》，由項目經理指定設計人員根據《軟件概要設

計編寫規范》編制《概要設計說明書》。

令《概要設計說明書》的內容：

20

J確定系統的軟硬件運行的環境和可擴展性；

/確定系統的軟硬件開發的環境；

,確定系統整體功能的結構，使用工具；

/確定子系統/功能模塊的劃分；

/確定個系統模塊功能、性能、數據、結果、處理等要素；

,確定數據庫要求；

,確定系統的內外部接口和主界面設計；

/確定系統的錯誤處理和安全保密設計；

,確定系統的維護設計；

/明確設計所受條件約束等。

?概要設計的評審

＜評審由項目管理組提出申請，質量保證組組織實施，參加人員可包括：質量保證組、項目

管理組、項目經理、系統分析組、軟件開發組、業務有關人員，必要時，還可以包括有關

專家和用戶代表，設計評審的具體程序見《設計評審程序》。

令評審通過后，由質量保證組負責人審批。

?測試方案設計

?在系統詳細設計階段，測試組負責人應參與系統的詳細設計，確定相應的測試方案，編制

《測試計劃及測試用例》0

＜測試方案確定的具體程序見《測試和驗收交付程序》

三、階段成果

《概要設計說明書》

《測試計劃及測試用例》

4.6.5,詳細設計與編碼

一、職責

?開發組負責系統的詳細設計和編碼

?測試組對開發產品進行測試，輸出合格軟件產品。

?質量保證組對設計是否符合計劃的安排進行跟蹤監督。

二、工作程序

21

?系統詳細設計

令系統概要設計完成后，軟件開發組根據評審通過的《概要設計說明書》對關鍵性模塊進行

詳細設計。

?系統詳細設計的主要任務是進一步細化概要設計的結果，確定系統的具體實現過程，得到

對系統的精確描述。

?詳細設計評審

令評審由項目經理提出申請，質量保證組組織實施，參加人員可包括：項日經理、測試人員、

設計人員、業務有關人員，必要時，還可以包括有關專家和用戶代表，設計評審的具體程

序見《設計評審程序》

?評審內容包括：《詳細設計說明書》。

?評審通過后，由質量保證組負責人審批。

?編碼

令開發組人員根據項目需要編制《軟件設計編碼規范》，經質量保證組審批。

＜開發組人員《功能需求說明書》、《概要設計說明書》和詳細設計進行編碼。

令開發組人員在編碼過程中，應嚴格遵循《軟件設計編碼規范》，保證編碼的一致性及代碼

的正確性、易讀性、易維護性。

?編碼完成的結果形成《源程序清單》。

?項目經理對編碼的結果進行審批，對不符合《軟件設計編碼規范》的情況，返回開發人員

進行修改，直至批準通過。

?測試

?編碼經批準后，開發組人員提交相應源程序，交測試人員。

令由測試人員根據《測試和驗收交付程序》進行測試。

三、階段成果

《詳細設計說明書》

《源程序清單》

程序代碼

4.6.6.測試階段

一、職責

?測試組負責組織編制測試計劃、測試用例。

22

質量保證組負責批準測試計劃、測試用例和測試結果報告。

?測試組負責實施測試計劃。

?開發組負責提供技術支持。

二、工作程序

?測試計劃書編制與評審

＜在詳細設計階段，測試組負責人參與系統的詳細設計，并組織測試人員編制《測試計劃》、

《軟件測試用例》，包括：單元測試、集成測試、系統測試等。

?測試計劃的內容包括測試進度、測試內容、測試工具、測試環境等，集成和系統測試計戈I」,

還應驗證各部分之間的接口有無錯誤。

/A依據《軟件測試計劃與測試用例編寫規范》中的內容與上述相一致。

/B測試用例應包括對模塊的正常輸入進行測試和處理路徑的測試，以及對非法輸入，非

預期輸出，出錯處理路徑的測試。

令編制完成后，由質量保證組組織有關測試組人員、開發組人員和設計組人員按《設計評審

程序》對《測試計劃》、《軟件測試用例》進行評審，評審通過后，由質量保證組負責人

批準。

?測試計劃的實施

?測試人員按《測試計劃》內容進行單元測試，對軟件測試過程應填寫《軟件測試報告》予

以記錄，如果測試中發現的問題，應在《軟件測試報告》中注明，交測試組負責人審批后

交項目經理，并由開發人員進行修改，在程序代碼中標明。

令集成或系統的所有組成部分均需通過單元測試，得到確認后，才可進行集成或系統測試.

?測試總結

令測試完畢后，由測試人員編寫《測試分析報告》，授權的測試人員簽名，其中應清楚描述

測試過程和測試結果。

?質量保證組組織有關人員按《設計評審程序》對《測試分析報告》進行評審。

＜評審通過后，由測試保證組負責人審批《測試分析報告》。

三、階段成果

《軟件項目開發總結報告》

《軟件測試用例》

23

4.6.7.系統安裝及項目交付

一、職責

?測試組負責編寫用戶手冊

?網絡工程師負責提供技術支持和系統現場部署。

二、工作程序

?《用戶手冊》的編制

＜《用戶手冊》必須依據《用戶手冊編寫規范》在項目驗收前完成，具體編制時間、編制人

由項目經理確定。

＜《用戶手冊》內容包括：

,軟件概述；

/運行環境（硬件、支持軟件）；

,使用說明（安裝和初始化、輸入輸出）：

/運行說明

?《用戶手冊》的評審

＜評審由項目經理提出申請，質量保證組組織實施，參加人員可包括：質量保證組、項目經

理、設計組、開發組，設計評審的具體程序見《設計評審程序》；

令評審通過后，由質量保證組負責人審批。

?軟件開發組負責《用戶手冊》的制作，具體見《軟件產品制作過程控制程序》。

?待項目結束后，由項FI經理將所形成的質量記錄移交經理辦公室歸檔。

?系統的安裝部署

?確認、交付

令根據合同中規定的確認方式進行產品確認。

令開發組負責產品的交付。

＜用戶在接到產品后，雙方對產品進行驗證，并填寫《軟件復制、交付和安裝表》，由用戶

和公司雙方簽字認可。

?形成的記錄

＜對本程序所產生的質量記錄由項目經理保存，待項目驗收交付完畢移交經理辦公室統?管

理。

?提交《用戶手冊》及其相應的文檔，完成項目交付

三、階段成果

24

《系統安裝于冊》

《系統運行維護手冊》

《用戶手冊》

4.6.8.配置管理

一、職責

?配置管理組負責組織配置管理計劃的編制.

?質量保證組負責組織評審配置管理計劃。

?項目開發人員執行項目的配置管理計劃。

二、工作程序

?配置管理提供一個標識、控制和追蹤每個軟件項的有效版本的機制，通過配置管理系統應:

令唯一的標識每一軟件項的正式版本；

令標識構成一個特定版本完整產品的各軟件項的版本；

?標識在開發、交付及安裝中的軟件產品的狀態：

?控制由一個以上的程序員同時對同一軟件項進行的更新；

＜對多個產品的一處或多處的更新進行協調；

＜確定和追蹤由一個更改申請而引起的所有措施和更改，包括從開始到釋放的全過程。

?配置管理計劃編制

令所有項n在制定項目開發計劃時，配置管理組組長按《配置管理編寫規范》制定項口的《配

置管理計劃》。

?《配置管理計劃》的內容：

,有關機構及職責；

,配置管理活動；

/使用的工具、技術和方法；

,應將各配置項置于配置控制之卜的相應階段。

?《配置管理計劃》評審

?《配置管理計劃》編制完成后，由項目經理提出評審申請。

＜《配置管理計劃》評審由質量控制組負責人組織實施，參加評審的人員包括：質量控制組、

項目經理、項目組成員等，評審的具體程序見《設計評審程序》。

＜評審通過后，由質量控制組負責人審批。

25

?配置管理活動

令創建項目配置管理（CM）環境

為項目配置管理（CM）創建一環境，在此環境中可以對整個產品進行開發、構建，而且具有可

重用性或可維護性。建立開發和構建產品的環境可以分兩個部分來完成：首先設置硬件環境，然后

建立開發環境。

設置CM環境包括分配機器資源（服務器和硬盤空間）以及安裝配置管理工具。

設置開發環境包括創建儲存庫、設置產品目錄結構以及導入所有的已有文件。最初的壞境是進

一步開發工作的基線。

令配置標識和追蹤

通過制定《配置管理計劃》建立和維護軟件生命周期所有階段中標識軟件的規程，每個軟件項

應有唯一標識。這些軟件項的每一版本標識下列內容：

/功能和技術規格說明；

,影響功能和技術規格說明的所有開發工具；

,與其他軟件項和硬件的所有接口；

/與軟件項有關的所有文檔。

,對所釋放的產品應制定便于追蹤軟件項或產品的規程。

?配置變更控制

在《配置管理計劃》對在配置管理下的軟件項制定對更改的申請、標識、記錄、評審和批準的

規程。軟件項的所有更改都要按照這些規程實施，并填寫相應記錄《配置變更記錄表》、《配置狀

態報告》。

應對更改的有效性進行確認，并確定和檢查該更改對其他軟件項的影響。

應填寫《配置變更通知單》將更改情況通知有關方面并說明更改與軟件項被更改部分的追蹤方

法。

?配置狀態報告

由配置管理人員填寫《配置狀態報告》記錄配置項的狀態、更改申請和已批準更改的實現情況。

?《配置管理計劃》變更控制

?《配置管理計劃》變更由項目經理填寫《需求變更審批表》，具體變更程序見《設計變更

控制程序》。

令變更完成后，項目經理將變更情況通知所有相關部門和人員。

?形成的記錄

26

＜對本程序所產生的質量記錄山項口經理待項口驗收交付后移交經理辦公室統一保存。

三、階段成果

《配置管理計劃》

《配置變更記錄表》

《配置變更通知單》

《配置狀態報告》

4.6.9.變更控制

一、職責

?項目經理、測試組人員提出變更需求。

?質量保證組負責組織對變更需求的合理性、可行性進行評審。

?項H經理負責指定程序員進行變更，指定測試組人員對變更進行測試。

二、工作程序

?變更需求提出：

e在設計開發的各階段項目組成員發現其它階段輸出結果不適合處后或顧客提出變更需求時

的填寫《需求變更審批表》；

＜在測試階段測試人員在測試過程中填寫的《軟件測試報告》；

?變更需求確認：

中對于設計開發階段的《需求變更審批表》，經項F1經理審核后，質量保證組負貢組織相關

人員按《設計評審程序》對變更需求進行變更評審。

?對于《軟件測試報告》提出的問題經測試組確認后，由項目經理審核確認其有效性、合理

性、可行性。

?變更的實施

＜對于維護階段的變更需求由產品經理、其它變更需求由項目經理確定變更執行人（如有軟

件代碼變更，需確定測試人員），并確定相應資源配置。

令對于涉及的技術文檔的變更，變更執行人按變更需求進行分析，并執行變更，經項目經理

（或產品經理）審核后，質量保證組組織相關人員按《設計評審程序》進行評審，通過后

由項目經理（或產品經理）收回原文檔，發布新文檔，變更執行人按《配置管理計劃》操

作。

令對于軟件代碼變更

27

/測試階段中的提出的變更，山項口經理確定是否使用原有《詳細設計說明書》、《測試計

戈IJ》、《軟件測試用例》，如需要重新編寫，由項目經理指定程序員、測試員進行編寫。

,執行變更的程序員、測試人員根據有效的變更需求進行分析，確定變更方案、測試方案，

編寫《詳細設計說明書》、《測試計劃》、《軟件測試用例》。

/質量保證組組織人員按《設計評審控制程序》對《詳細設計說明書》、《測試計劃》、《軟

件測試用例》進行評審。

/評審通過后程序員依相應的《詳細設計說明書》、《軟件設計編碼規范》進行程序編碼的

變更。

/編碼完成后，由測試組測試人員依《測試計劃》、《軟件測試用例》進行測試，填寫《軟

件測試報告》。

?配置的變更

對于涉及到配置項的變更按《配置管理控制程序》、相應的《配置管理計劃》進行變更，并將

變更情況通知所有相關部門和人員

?形成的記錄

本程序所產生的質量記錄由經理辦公室進行管理。

三、階段成果

《詳細設計說明書》

《測試計劃》

《軟件測試用例》

《需求變更審批表》

4.7.項目開發/測試計劃

項目名稱：XXXX預計開始時間：YYYY年MM月

版本號：VI.0.0預計完成時問：YYYY年MM月DD日

項目經理：預計上架時間：YYYY年MM月DD日

技術負責人：產品經理：

完成時間節點階段名稱交付內容備注

28

2019年8月1日項目啟動甲方確認啟動郵件

2019年8月6日需求整理輸出功能清單/思維導圖

乙方給出E操作界面、原型

2019年8月29日原型設計

圖文檔

甲方出具《反饋調整意見》，進

2019年9月3R反饋調整

行原型圖確認

2019年9月6日UE/UI設計完成乙方給出詳細設計圖文件

乙方內部測試通過后給出

2019年11月25日開發完成

APP測試版安裝文件

甲方確認整個項目簽收

乙方交付項目源碼、接口文

2019年12月5日項目完成

檔、設計源文件、后臺使用手冊

等項目相關文件

4.8.運維及售后服務方案

4.8.1.運維系統管理方案

1、服務目標

本公司可提供的運行維護服務包括，信息系統相關的主機設備、操作系統、數據庫和存儲

設備的運行維護服務，保證用戶現有的信息系統的正常運行，降低整體管理成本，提高網絡信息系

統的整體服務水平。同時根據日常維護的數據和記錄，提供用戶信息系統的整體建設規劃和建議，

更好的為用戶的信息化發展提供有力的保障。

29

用戶信息系統的組成主要為軟件部分可分為操作系統軟件、典型應用軟件（如：數據庫軟

件、中間件軟件等）、業務應用軟件（如前端APP）等。

本公司通過運行維護服務的有效管理來提升用戶信息系統的服務效率，協調各業務應用系

統的內部運作，改善網絡信息系統部門與業務部門的溝通，提高服務質量。結合用戶現有的環境、

組織結構、IT資源和管理流程的特點，從流程、人員和技術三方面來規劃用戶的網絡信息系統的結

構。將用戶的運行目標、業務需求與IT服務的相協調一致。

本公司提供的信息系統服務的目標是，對用戶現有的信息系統基礎資源進行監控和管理，

及時掌握網絡信息系統資源現狀和配置信息、，反映信息系統資源的可用性情況和健康狀況，創建-

個可知可控的IT環境，從而保證用戶信息系統的各類業務應用系統的可靠、高效、持續、安全運行。

服務項目范圍覆蓋的信息系統資源以下方面的關鍵狀態及參數指標：

>運行狀態、故障情況

>配置信息

>可用性情況及健康狀況性能指標

2、網絡、安全系統運維服務

從網絡的連通性、網絡的性能、網絡的監控管理三個方面實現對網絡系統的運維管理。網絡、

安全系統基本服務內容。

序號服務模塊內容描述提供方

首先分析軟件升級的必要

1后臺系統軟件升級性和風險，配合用戶進行軟件升

級

按服務級別：7X24小時

2現場故障診斷

5X8小時

3電話遠程技術支持7X24小時

對遇到的問題進行匯總和

4問題管理系統

發布

30

(1)現場巡檢服務

現場巡檢服務是本公司對客戶的設備及網絡進行全面檢查的服務項目，通過該服務可使客戶獲

得設備運行的第一手資料，最大可能地發現存在的隱患，保障設備穩定運行。同時，本公司將有針

對性地提出預瞥及解決建議，使客戶能夠提早預防，最大限度降低運營風險。

巡檢包括的內容如K：

編號巡檢內容

軟件運行情況檢查項目

1

項目運行情況檢查網絡報文分析項目對接運行狀況檢查

網絡整體運行情況調查

2

網絡運行問題調查網絡變更情況-周查網絡歷史故隙調查

(2)后臺運行分析與管理服務

后臺運行分析與管理服務是指本公司工程師通過對后臺運行狀況、后臺問題進行周期性檢查、

分析后，為客戶提出指導性建議的一種綜合性高級服務，其內容包括：

服務內容服務優點

向客戶提供后臺專家電話號碼。保證重大問題第一連線至后臺專家.

后臺專家組每周與客戶進行不少于2以最小成本保證及時解答客戶關心的

小時的電話技術交流技術問題，并就某一領域技術問題展開深層

次溝通。

(3)重要時刻專人值守服務

本公司深刻知道保證重要時刻軟件穩定運行對客戶成功尤為關鍵，因此，本公司可對客戶提供

重要時刻的專人現場值守支持，包括政府客戶的重大會議期間、金融客戶的年終結算日、運營商客

31

戶的生產網重大割接或具它任何客戶認為可能對具'業務運營產?生重大影響的時刻。

如需專人值守，客戶需至少提前3周與本公司客戶服務經理聯系。對每位客戶，本公司均需按

事先合同約定提供專人值守服務。客戶如需超出合同約定范圍的更多值守支持，需額外支付相應人

力和差旅費用。

3、數據庫系統運維服務

本公司提供的數據庫運行維護服務是包括主動數據庫性能管理，數據庫的主動性能管理對系統

運維非常重要。通過主動式性能管理可了解數據庫的日常運行狀態，識別數據庫的性能問題發生在

什么地方，有針對性地進行性能優化.同時，密切注意數據庫系統的變化，主動地預防可能發生的

問題。

本公司提供的數據庫運行維護服務還包括快速發現、診斷和解決性能問題，在出現問即時，及

時找出性能瓶頸，解決數據庫性能問題，維護高效的應用系統。

本公司的數據庫運行維護服務，主要工作是使用技術手段來達到管理的目標，以系統最終的運

行維護為目標，提高用戶的工作效率。

具體數據庫運行維護監控的基本服務內容包括：

4、中間件運維服務

中間件管理是指對BEAWeblogic、MQ等中間件的日常維護管理和監控工作，提高對中間件平臺

事件的分析解決能力，確保中間件平臺持續穩定運行。中間件監控指標包括配置信息管理、故障監

控、性能監控。

■執行線程：監控WcbLogic配置執行線程的空閑數晟。

■JVM內存：JYM內存曲線正常，能夠及時的進行內存空間回收。

■JDBC連接池：連接池的初始容量和最大容量應該設置為相等，并且至少等于執行線程

的數量，以避免在運行過程中創建數據庫連接所帶來的性能消耗。

32

■檢查WEBLOG日志文件是否有異常報錯

■如果有WEBLOG集群配置，需要檢查集群的配置是否正常。

3.6.2運維服務流程

本公司建議用戶采用的服務方式為兩種：一種為技術人員現場值守，另一種是定期巡檢結合故

障現場服務。

技術人員現場值守運行維護服務的基本操作流程如下圖所示：

33

技術人員用戶現場值守，H常狀態監控

備件更換故障現場解決

記錄到維廬數據庫

I〕

目