《軟件質量管理制度》

《軟件質量管理制度》

一、管理組織

本公司的軟件質量保證活動統(tǒng)一由質量管-理?員進行管理、檢查

與匯報，公司相關部門經(jīng)理及項目中的項目經(jīng)理、程序經(jīng)理、開發(fā)經(jīng)

理、測試經(jīng)理、產(chǎn)品經(jīng)理、測試經(jīng)理、用戶教育經(jīng)理是質量保證活動

中的第一責任人。

二、軟件開發(fā)過程

本公司的軟件開發(fā)過程分為以下8個階段：項目策劃階段、需求

分析階段、設計階段、開發(fā)階段、測試階段、實施階段、驗收階段、

維護階段，每個階段的主要活動分別為：業(yè)務啟動和項目規(guī)劃、需求

分析、邏輯設計和物理設計、軟件開發(fā)、軟件測試、系統(tǒng)實施及用戶

培訓、用戶試用及驗收、維護，里程碑分別為：策劃完成、需求明確、

設計完成、開發(fā)完成、測試通過、系統(tǒng)上線、驗收通過、合同結束。

每階段結束后，必須對相應的里程碑進行檢查，方式為評審或批準。

三、項目文檔項目文檔分為兩種：管理類文檔與技術類文檔，所

有文檔必須保存于知識庫及相應的vss庫中。文檔共有三種狀態(tài)：編

制完成、審核通過、批準通過。其中管理類文檔只有編制和批準兩種

狀態(tài)，技術類文檔擁有所有三種狀態(tài)。所有文檔必須明確說明當前文

檔版本號。

管理類文檔包含以下類型：計戈I」、總結、報告、會議紀要、備忘

錄、申請等。技術類文檔包含：設計文檔、需求文檔、測試設計文檔、

界面原型軟件、使用手冊、安裝手冊、技術白?皮■書、培訓資料、源

代碼、軟件產(chǎn)品等。除VSS庫中的文檔以外，放入知識庫中的文檔由

部門助理統(tǒng)一放入，文檔必須批準通過。

文檔的編制、審核、批準可在文檔中直接寫明，也可使用單獨的

審批文檔進行說明。

每個項目在不同階段必須產(chǎn)生的文檔如下，但不限于此：

1、項目開始前：

合同、技術方案、市場立項表。以上文檔存放于知識庫。

2、項目策劃階段:

業(yè)務啟動表（excel格式）、項目規(guī)劃（word格式）、項目進度

（project格式）等。必須使用規(guī)定模板編寫。以上文檔存放于知識庫。

3、需求分析階段：

需求模型（ea格式）、軟件需求規(guī)格說明書（word格式）、單據(jù)

報表格式（excel格式）、需求分析評審表（word格式）、需求分析計

劃（word格式和project兩種格式）。必須使用規(guī)定模板編寫。以上

文檔存放于知識庫。

4、設計階段

軟件開發(fā)計劃（project格式）、邏輯設計（ea格式）、物理設計

（vs.格式）、設計評審表（word格式），必須使用規(guī)定模板編寫。物

理設計存放于vss庫，其它文檔存放于知識庫。

5、開發(fā)階段

源代碼、可安裝的軟件、安裝手冊、評審表（word格式）。源代

碼、可安裝的軟件存放于vss庫，其它文檔存放于知識庫。

6、測試階段

測試用例設計、軟件bug、測試計劃（word格式和project兩種

格式）、測試報告（word格式）、開發(fā)的測試工具源代碼及軟件、測

試通過的軟件產(chǎn)品、軟件評審表（word格式）。開發(fā)的測試工具源代

碼及軟件、測試通過的軟件產(chǎn)品存放于vss庫，其它文檔存放于知識

庫。軟件bug存于td中。

7、實施階段實施計劃（word格式和project兩種格式）、實施報

告（word格式）、用戶使用手冊、用戶培訓資料、用戶培訓記錄、軟

件問題反饋表（excel格式）、上線報告（書面、電子掃描件）等。必

須使用規(guī)定模板編寫。以上文檔存放于知識庫。

8、驗收階段

驗收材料、驗收報告（書面、電子掃描件）。以上文檔存放于知

識庫。

9、維護階段

維護報告（word格式），以上文檔存放于知識庫。

四、檢查和審查

本公司的項目關鍵檢查點有以下8個，采取評審和批準的方式，

由質量管?理?員進行跟蹤C

1、策劃完成里程碑

以總經(jīng)理批準通過業(yè)務啟動表為標志，質量管?理?員檢查業(yè)務啟

動表、項目規(guī)劃、項目風驗控制計劃、項目進度、技術方案文檔是否

進入知識庫。負責人為項目經(jīng)理。

審表是否進入知識庫。負責人為測試經(jīng)理。

6、系統(tǒng)上線里程碑

以用戶簽署通過上線報告為標志，評審參與人員必須包括。用戶

代表、公司代表、項目經(jīng)理。質量管■理■員檢查上線報告、實施計劃、

培訓材料等文檔是否進入知識庫。如上線報告為紙質文檔，則掃描后

入庫。負責人為實施經(jīng)理。

7、驗收通過里程碑

以用戶簽署通過驗收報告為準，評審參與人員必須包括。用戶代

表、公司代表、項目經(jīng)理。質量管■理-員檢查驗收報告文檔是否進入

知識庫，如上線報告為紙質文檔，則掃描后入庫。負責人為項目經(jīng)理。

8、合同結束里程碑

合同結束，項目跟蹤完成。負責人為軟件業(yè)務部技術服務組長。

五、測試本公司的軟件必須通過測試。測試工作由開發(fā)部測試組

負責，所有測試出來的bug必須統(tǒng)一存放，由測試組負責管理。在測

試活動進行前必須有測試計劃，測試完成后必須編寫測試報告。測試

報告由測試經(jīng)理負責編寫，測試組長批準。

六、配置管理

軟件開發(fā)過程中的配置管理工作由配置管?理?員負責，配置管理

工作詳細要求依據(jù)《配置管理規(guī)范》進行。

七、媒體控制

在軟件開發(fā)過程中產(chǎn)生的正式文檔必須存入于知識庫中或vss庫

中，由公司系統(tǒng)管-理-員負責每天進行物理備份。在項目進行過程中

的備份采用移動硬盤進行，已結項的項目使用刻錄光盤存檔備份。

八、質量記錄

質量記錄主要包括各種評審記錄和審批記錄，形式有評審表、簽

名文件、會議紀要、質量報告等。所有的質量記錄由質量管■理■員統(tǒng)

一管理，紙質的保存在指定的文件柜中，電子的保存在知識庫中。質

量記錄的保存期限是3年。

九、風險和應急公司所有的項目必須有獨立的風險控制計劃，風

險控制計劃由項目經(jīng)理負責編寫并跟蹤，風險控制計劃由項目管理部

門批準。風險計劃中必須包括風險列表、風險度、應急方案、緩解方

案、責任人、風險狀態(tài)。風險度由風險發(fā)生可能性和風險造成的危害

程度相乘得到。

十、質量報告

項目的質量管■理■員必須在每周五12:00以前制作當前的項目質

量報告，報告公司當前正在進行的項目的質量狀態(tài)。主要包括：項目

文檔的審核情況、存放情況、完備情況;各里程碑的評審執(zhí)行情況;各

種計劃的跟蹤情況，責任人是否及時更新計劃;各項規(guī)范的符合程度;

等等。質量報告屬于項目狀態(tài)報告的一部分，與其一同填寫。具體格

式參見《項目狀態(tài)報告》。

十一、質量會議

質量會議與公司的項目月例會合并召開，開會時必須提交質量報

告。參會人員必須包括軟件業(yè)務部部門經(jīng)理、產(chǎn)品組組長、實施組組

長和開發(fā)部部門經(jīng)理、開發(fā)組組長、技術支持組組長、測試組組長、

各項目經(jīng)理。如遇特殊情況，質量管-理?員可臨時針對某類問題發(fā)起

會議，會議結束時必須有會議紀要并存檔。

十二、工具及技術在進行質量保證活動中，主要使用兩種工具軟

件：知識管理系統(tǒng)和msvisualsourcesafeo前者用來存放項目產(chǎn)生的各

種文檔，后者主要用于存放源碼。公司在所有正式場合中所使用的項

目文檔均以這兩個系統(tǒng)中的數(shù)據(jù)為準。在使用工具軟件的過程中，各

項目成員的權限統(tǒng)一由公司文檔管■理■員進行分配。

十三、變更控制委員會

公司所有在建項目必須成立變更控制委員會，該委員會最小要包

括以下人員：用戶代表、市場代表、軟件業(yè)務代表、開發(fā)代表、項目

經(jīng)理，但不限于此。一般情況下，產(chǎn)品經(jīng)理、程序經(jīng)理、開發(fā)經(jīng)理、

測試經(jīng)理、實施經(jīng)理、用戶教育經(jīng)理也可包括在該組織中。對于維護

性項目，變更控制委員會由營銷中心主任、軟件業(yè)務部經(jīng)理、開發(fā)部

經(jīng)理組成。

第二篇：軟件質量保證管理1、v模型：v模型是在rad模型的基

礎上演變而來的，由于開發(fā)過程構造成一個v字形而得名。v模型強

調(diào)軟件開發(fā)的協(xié)作和速度，將軟件實現(xiàn)和驗證有機地結合起來，在保

證較高的軟件質量情況下縮短開發(fā)周期。v模型具有面向客戶、效率

高、質量防范意識等特點。

左邊是設計和分析，是軟件設計實現(xiàn)的過程，同時伴隨著質量保

證活動一審核過程，也就是靜態(tài)的測試過程；右邊是對左邊結果的驗

證，是動態(tài)的過程，即對設計和分析的結果進行測試，以確認是否滿

足用戶的需求。V模型避免了瀑布模型所帶來的誤區(qū)--軟件測試是

在代碼完成之后進行的。p30

2、什么是變更控制。(pill)

軟件開發(fā)過程中都會產(chǎn)生許多變更，如配置項，配置，基線，構

建的版本，發(fā)布的版本的變更，對于這些變更，都要有一個控制機構,

以保證所有的變更都是可控的，可跟蹤的，可重現(xiàn)的。這樣的一類機

構對變更的管理，就是變更控制。

3、軟件可靠性概念。(pl76)

軟件可靠性是指在給定時間內(nèi)，特定環(huán)境下軟件無錯運行的概

率，軟件可靠性包含了以下三個要素：規(guī)定的時間，規(guī)定的環(huán)境條件,

規(guī)定的功能。

4、cmm(pl95)

cmm：能力成熟度模型，用來衡量組織軟件過程成熟度和評價其

軟件過程能力。能力成熟度是指一個特定過程被明確定義，管理，測

量，控制并且是有效的程度。分為五個等級：初始級軟件過程的特點

是無序的，甚至是混亂的。幾乎沒有什么過程是進過定義的?？芍貜?/p>

級關鍵過程區(qū)域集中關注軟件項目所關心的，與建立基本項目管理控

制有關的事情。

已定義級將軟件生命周期的各個階段嚴格的劃分出來，從組織這

個層次來保證過程質量該進

已管理級軟件產(chǎn)品的質量目標被量化管理，它遵循了全面質量管

理活動的科學程序，關鍵過程域的關注焦點是建立起對軟件過程和正

在構造的軟件工作產(chǎn)品的定量了解。

優(yōu)化級關鍵過程域包括那些為了實施連續(xù)不斷的和可測的軟件

過程改進，組織和項目都必須解決的問題。

5、tqm的實施步驟（p265）

（1）建立質量小組，負責過程改進，流程完善，不斷發(fā)現(xiàn)質量

問題提出并實施解決方案。

（2）進行tqm思想的教育，通過教育，要讓每個員工深刻認識

到“滿足顧客的需求是第一的”的思想，理解“什么是顧客需求”，

如何讓顧客滿意等內(nèi)容。

（3）了解市場，明確顧客需求，了解目前研發(fā)的軟件產(chǎn)品的市

場，包括競爭對手，客戶群等，讓員工明白什么是質量好的軟件產(chǎn)品

或軟件服務，認真對待質量要求，開發(fā)出合格的產(chǎn)品。

（4）建立明確的質量基準和質量評估機制，以便和實際質量水

平進行對比，識別質量的目標和工作的重點區(qū)域，采取相應措施。

（5）建立相對完善的獎勵機制，在認可和給予獎勵的過程中，

應力求公正，真實，選擇恰當?shù)臅r間，恰當?shù)膱龊?，恰當?shù)姆绞健?/p>

2、版本控制的目的。是在于對軟件開發(fā)過程中文件或目錄的發(fā)

展過程提供有效的追蹤手段，保證在需要時找到舊的版本，避免文件

的丟失，修改文件的丟失和相互覆蓋，通過對版本庫的訪問控制避免

未經(jīng)授權訪問和修改。另外軟件的控制是實現(xiàn)團隊開發(fā)，提高效率的

基礎。

3、pdca包括4個部分：計劃、執(zhí)行、檢查、行動描述總結

（1）計劃計劃：就是分析當前狀況，發(fā)現(xiàn)問題，找出原因和主

要原因，制定質量方針、質量

目標、質量計劃書和管理原則。管理原則有。過程方法、管理的

系統(tǒng)方法、持續(xù)改進

（2）執(zhí)行：執(zhí)行時計劃的履行和實現(xiàn)，主要按計劃實施地去做,

去落實具體對策，并實施過

程的監(jiān)控，使活動按預期設想前進，最終達到計劃設定的目標。

（3）檢查。是對執(zhí)行后效果的評估。檢查是伴隨著實施過程自

始至終的，不斷收集數(shù)據(jù)、信

息獲取的過程，并通過數(shù)據(jù)分析、結果度量來完成檢查。

行動。重點在于檢查完結果，要采取措施，即息結成功的經(jīng)驗，

吸取失敗的教訓，實施標準化，以后依據(jù)標準執(zhí)行。

4、階段性開發(fā)模型：增量模型和迭代模型

（1）增量模型描述軟件產(chǎn)品的不同階段是按產(chǎn)品所具有的功能

進行劃分的，先開發(fā)主要

功能或用戶最需要的功能，然后隨著時間的推進，不斷增加新的

輔助功能或次要功能，最終開發(fā)出一個功能完善的，穩(wěn)定的產(chǎn)品。

（2）迭代模型描述軟件產(chǎn)品的不同階段是按產(chǎn)品深度或細化程

度來劃分，先將產(chǎn)品的整個框架都建立起來，在系統(tǒng)的初期，已經(jīng)具

有用戶所需要的全部功能。然后隨著時間推進，不斷細化已具有的功

能或完善已具有的功能，這個過程是一個迭代的過程

6、零缺陷質量管理的實施步驟：（p268）

（1）建立推行零缺陷質量管理的組織事情的推行都需要組織的

保證，通過建立組織，可以動員和組織全體職工積極的投入零缺陷管

理，提高他們參與管理的自覺性也可以對每個人的合理化建議進行統(tǒng)

計分析，不斷進行經(jīng)驗交流，公司的最高管理者要親自參加，表明決

心，做出表率，要任命相應的領導人，建立相應的制度，要教育和訓

練員工

（2）確定零缺陷管理的目標，確定零缺陷小組在一定時期內(nèi)所

要達到的具體要求，包括確定目標項目，評價標準和目標值

（3）進行績效評價，

（4）建立相應的提案機制

（5）建立表彰制度

sqa組織的責任是審計軟件經(jīng)理和軟件工程組的質量活動中出現(xiàn)

的偏差。

7、sqa計劃（p283）

sqa在項目早期要根據(jù)項目計劃制定與其相應的sqa計劃，定義

各階段的檢查點。標識出檢查審計的工作產(chǎn)品對象，以及在每個階段

sqa的輸出產(chǎn)品。具體實施步驟如下：

（1）了解項目的需求，明確項目sqa計劃的要求和范圍

（2）選擇sqa任務

（3）估計sqa的工作量和資源

（4）安排sqa任務和日程

（5）形成sqa計劃

（6）協(xié)商，評審sqa計劃

（7）批準sqa計劃

（8）執(zhí)行sqa計劃

sqa計劃包含以下內(nèi)容：

（1）目的，sqa計劃的目的和范圍（2）參考文件，該sqa計劃

參考的文件列表（3）管理，組織，任務，責任（4）文檔，列出所有

的相關文檔，如程序員手冊，測試計劃，配置管理計劃等（5）標準

定義，文檔標準，邏輯結構標準，代碼編寫標準，注釋標準等（6）

評審/審核（7）配置管理，配置定義，配置控制，配置評審（8）問

題報告和處理（9）工具，技術，方法（10）代碼控制（11）事故/

災難控制，包括火災，水災，緊急情況等。

8、評審和審核的區(qū)別。（p285）

評審：過程進行時，sqa對過程的檢查，sqa的角色在于確保當

執(zhí)行工程活動時，各項計劃所規(guī)定的過程得到遵循，評審通常通過評

委會的的方式進行，是對工作流程的評審

審核。在軟件工作產(chǎn)品生成時，sqa對工作產(chǎn)品進行的檢查，sqa

的角色在于確保開發(fā)工作產(chǎn)品中各項計劃所規(guī)定的過程得到遵循，審

核通常通過對工作產(chǎn)品的審查來執(zhí)行。側重于產(chǎn)品本身。

sqa報告應遵循三條原則sqa和高級管理者之間應有的溝通渠

道，sqa報告必須發(fā)布給軟件工程組織但不必發(fā)布給項目管理人員，

在可能的情況下向關心軟件質量的人發(fā)布。

sqa度量是記錄花費在sqa活動時間人力數(shù)據(jù)。涉及以下三方面:

軟件產(chǎn)品評估度量、軟件產(chǎn)品質量度量、軟件過程審核度量。

sqa的評估任務是軟件開發(fā)前期對目標的軟件和硬件資源進行評

估，以確保其充分性和適合性。

9、白盒測試、黑盒測試(p390)

白盒測試將被測試程序看做一個盒子，測試者能夠看到被測程

序，可以分析被測程序的內(nèi)部結構。

白盒測試可以用來對代碼結構進行全面測試，常用的有語句覆

蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，條件組合覆蓋，路徑覆

蓋，循環(huán)測試

黑盒測試常用來驗證軟件或模塊功能是否得到實現(xiàn)，主要運用單

元的性能和功能方面的測試除了測試其功能外，還需確保代碼在結構

上可靠，健全并能夠有良好的響應。黑盒測試主要運用于單元的功能

和性能方面的測試。功能測試包括用戶界面測試各種操作的測試不同

的數(shù)據(jù)輸入邏輯思路，數(shù)據(jù)輸出和存儲的測試。

區(qū)別：關鍵區(qū)別應該就是測試對象不一樣，白盒測試主要針對的

是程序代碼邏輯，黑盒測試主要針對的是程序所展現(xiàn)給用戶的功能，

簡單的說就是前者測試后臺程序后者測試前臺展示功能

10、測試的原則概括為10項：

(1)所有測試的標準都是建立在用戶需求之上2軟件測試必須

基于“質量第一”的思想去開展各項工作3實現(xiàn)定義好產(chǎn)品的質量標

準4軟件項目一啟動。軟件測試也就是開始5窮舉測試是不可能的6

第三方進行測試會更客觀，更有效7軟件測試計劃是做好軟件測試工

作的前提8測試用例的設計出來的，不是寫出來的9不可將測試用例

置之度外，排除隨意性10對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入

的測試

39、功能測試的概念。是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所

應具有的功能，從用戶角度來進行功能驗證，以確認每個功能是否能

正常使用、是否實現(xiàn)了產(chǎn)品規(guī)格說明書要求、是否能適當?shù)亟邮蛰斎?/p>

數(shù)據(jù)而產(chǎn)生正確的輸出結果等。

5、風險管理法：sei（軟件工程研究所）風險控制一般分5個步

驟：p80

（1）風險識別：試圖系統(tǒng)化的方法來確定威脅項目計劃的因素。

識別方法包括：風險檢

測表、頭腦風暴會議、流程圖分析、與項目人員面談。

（2）風險分析?？梢苑譃槎ㄐ燥L險分析和定量風險分析。定性

風險分析是評估已經(jīng)識別

風險的影響和可能性的過程。定量風險分析是量化分析每一風險

的概率及其對項目目標造成的后果，同時也要分析項目總體風險的程

度。

（3）風險計劃：制定風險行動計劃，應考慮以下部分：責任、

資源、時間、活動、應對

措施、結果、負責人。

（4）風險控制：方法：風險避免、風險弱化、風險承擔、風險

轉移。

（5）風險跟蹤：監(jiān)視風險的狀況，檢查風險的對策是否有效、

跟蹤機制是否在運行，不

斷識別新的風險并制定對策。

6、評審的內(nèi)容：分為管理評審、技術評審、文檔評審、過程評

審（p217簡答）

（1）管理評審是以實施質量方針和目標的質量體系的適應性和

有效性為評論基準，對體系文

件的適應性和質量活動的有效性進行評價。目標：按規(guī)定的時間

間隔對質量體系進行評審，確保持續(xù)的適宜性和有效性，以滿足本標

準要求和提供的質量方針和目標。輸入：體系審核的結果。輸出：《管

理評審報表》

（2）技術評審是對產(chǎn)品以及各階段的輸出內(nèi)容進行評估。目的:

確保需求說明、設計說明書

與最初的說明書保持一致，并按照計劃對軟件進行了正確的開

發(fā)。輸入：需求文檔、源代碼、測試用例、評審檢查單、其它文檔。

輸出：技術評審報告

（3）文檔評審分為格式評審和內(nèi)容評審。

（4）過程評審是對軟件開發(fā)過程的評審，其主要任務是通過對

流程的監(jiān)控，保證sqa組織

定義的軟件過程在項目中得到了遵循，同時保證質量方針能得到

更快更好的執(zhí)行。

40.朱蘭三部曲:

質量策劃：

為建立有能力滿足質量標準化的工作程序，質量策劃是必要的

質量控制：

為了掌握何時采取必要措施糾正質量問題就必須實施質量控制

質量改進：質量改進有助于發(fā)現(xiàn)更好的管理工作方式

40、從軟件開發(fā)的各階段論述如何提高軟件產(chǎn)品的質量。

1、需求

我們知道人與人的交流總是會存在一些誤會，同樣一句話，心情

不好與心情好的時候聽起來的感覺可能會截然相反，正是因為人們之

間存在著理解上的偏差，在描述需求的語言上就應該注意盡量避免歧

義的產(chǎn)生。如果對uml比較熟悉的話，需求分析可以利用uml工具進

行，這樣可以減少一些自然語言引起的歧義，但是uml可能與用戶溝

通起來有一些障礙，因為并不是所有的用戶都了解uml各種圖形的意

思。除了工具之外，我們可以從以下幾個方面來保證需求描述的質量。

1、看句子和段落是否簡短，一個很長的句子，看起來會非常困

難，因此無法弄懂真正的需求，另外過長的句子和段落容易讓人忽視

一些需求，所以如果一個句子不能完全描述清楚需求，應該將其拆分

成多個小句子。

2、句子是否有語法錯誤，還要注意標點符號，有時，標點符號

點錯了，就完全成了另外一個意思了。

3、是否存在模糊不清的需求，出現(xiàn)類似于可能，大概，或者等

詞匯表述的需求。

4、另外注意引用的術語和詞匯是否前后一致。

5、是否存在一些形容詞、比較性詞語，比如。容易的、快速的、

方便的、有效的、許多、很少、簡單、復雜、最新的，界面友好的，

減少、擴大，不小于等等，需要將描述性詞語進行量化，并且給出具

體值或者范圍，要不然不同的人根據(jù)不同的理解就會得出不同的結

果，最終可能跟用戶最初的要求有偏差，那“炒回鍋肉”的事情就不

可避免地會發(fā)生。

另外保證需求質量的一個很重要的因素就是需求是否細化，如果

需求不細化也會很容易造成代碼的返工，于是就出現(xiàn)了我們的程序員

盡管總是加班加點卻總是不能如期的完成任務的情景。那么我們怎樣

才能判斷需求細化的程度呢。需求細化程度確實很難把握，什么樣的

需求可以算是比較細了，不用再進行細化了呢。哪些需求又太粗了呢。

答案是需求是否可以寫出相應的測試用例，如果寫不出來，就說明需

求還不是很細，還需要再進行細化。

2、設計

軟件架構設計在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開

發(fā)出來的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會涉及到方方面面的角色，

例如：用戶、項目管理人員、程序員、測試員、維護人員等等。不同

的角色對架構設計的要求也不相同。例如用戶關心的是需求，因此我

們的設計對需求的覆蓋率是多少。對于程序員來說模塊是否清晰，類

的功能是否單一等等，對于測試人員來說系統(tǒng)的是系統(tǒng)的可測試性。

對于維護人員來講系統(tǒng)的擴展性、可維護性如何。一個高質量的軟件

架構，應該最大限度的考慮并滿足不同角色的不同要求。正

是因為有這些要求，我們在進行軟件設計的時候，應該進行全面

的考慮。一般用來衡量軟件設計質量的標準可以從以下幾個方面來考

慮：

1）、功能性。包括完全性、正確性、安全性、兼容性、互用性。

完全性包括功能點覆蓋率，重點功能點覆蓋率，優(yōu)先功能覆蓋率。正

確性包括需求一致度。安全性根據(jù)軟件需求的不同有不同的安全性要

求。

2）、效率。包括產(chǎn)品運行的時間效率和利用的硬件資源兩方面來

考慮。

3）維護性。包括架構的可改正性，可擴充性以及可測試性。如

果用戶的一個很小的需求變更會引起架構設計很大的變化，那么這樣

的架構設計的可改正性和可擴充性就比較差。

4）可移植性。包括硬件的獨立性、軟件獨立性、可安裝性、可

重用性。軟件設計是否模塊化、每個模塊的可復用性如何都是應該考

慮的因素。

5）可靠性。包括缺陷數(shù)量、容錯性、可用性。

6）使用性。包括可理解性、易學習性、可操作性、易溝通性。

我們軟件的最終目的是讓用戶來使用的，如果易用性不好，可操作性

不好都會影響用戶對軟件的接納程度。因此在軟件的可使用性也是非

常重要的。

3、編碼

代碼質量的一個很重要的標準就是代碼的可讀性及規(guī)范性，可讀

性不一定是簡單的代碼，而是容易理解的代碼，因為過于復雜的代碼

難以測試和維護，同時出錯的幾率也會更高。如果一個方法內(nèi)部的代

碼很長，而且使用了很多令人難以理解的數(shù)據(jù)集，這樣就會帶來代碼

維護的困難，因為很少有人能夠有效地分析它們，因此也就是最容易

出現(xiàn)缺陷和錯誤的地方。類之間的耦合度會造成類與類之間的相互關

聯(lián)，當一個類發(fā)生改變時會使其他的類發(fā)生意想不到的變化，一般從

導入類的個數(shù)判斷類之間的耦合度，如果導入類的個數(shù)很多，每一個

導入類發(fā)生變化都會影響到該類本身，另外如果該類的public方法太

多也會導致類之間的高耦合性增加。

也許有的程序員會認為寫出可讀、規(guī)范的代碼會影響工作進度。

的確，對于程序員個體短時間來說為代碼寫上注釋是要花費些時間，

但如今軟件開發(fā)是多人協(xié)作

周期很長的過程，寫過程序的人都知道，如果自己寫了不規(guī)范的

代碼，隨著自己所寫的代碼越來越多，到后來需要修改某個前期寫的

模塊時都不知道自己當初是怎么想的了，讀自己的代碼也需要花很長

時間才讀懂。況且如果隨著人員的調(diào)動等其他原因，往往維護代碼的

程序員已不是當初寫代碼的人，很多情況就是讀懂了一段糟糕的代碼

還比重新寫出一段代碼花費的時間還長，嚴重影響工作效率（有些時

候還影響維護人員的心情），反過來，如果大家都講究把代碼寫成規(guī)

范可讀的，無疑對于整個組織來說提高總體工作效率是非常有用的。

代碼質量另一個非常重要的衡量手段就是測試，通過統(tǒng)計測試代

碼所產(chǎn)生的缺陷情況，如嚴重等級分布、缺陷曲線的變化等可以從一

個方面來簡單地評估代碼質量。

4、測試

測試人員在測試過程中，需要站在不同的利益相關者的角度，對

測試對象的質量進行檢查和驗證，例如：測試人員除了關注需求文檔

中明確描述的需求條目之外，還應該關注隱現(xiàn)的需求，比如：競爭對

手的產(chǎn)品特征、用戶的群體特征和使用習慣等。因此，在測試過程中,

測試人員除了關注測試對象的功能測試之外，還需要針對其他非功能

特性進行測試。

為了在測試過程中盡量多的覆蓋質量特性，測試人員需要清楚的

了解產(chǎn)品有哪些質量特性是客戶最關注的因此，測試人員在進行具體

的測試用例設計和執(zhí)行之前，需要定義該產(chǎn)品應該滿足的質量特性

集。

第三篇：有效的軟件質量管理有效的軟件質量管理（上）

一、引言

隨著社會信息化水平的不斷提高，信息行業(yè)急速膨脹，信息企業(yè)

快速成長，隨之帶來的信息市場競爭激烈，企業(yè)為了求生存，滿足客

戶要求則成為各行各業(yè)的首要責任。依賴于質量、成本和進度的客戶

滿意度，質量則是重點支撐之一，這樣要求我們對質量管理需要加強

認識。我們都知道pmbok把項目管理劃分為9個知識領域，即范圍

管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、

采購管理、風險管理和綜合管理。質量管理作為9大知識領域之一,

可見其重要性。

質量管理包括。質量計劃編制、質量保證和質量控制三個過程域。

質量計劃是質量管理的第一過程域，它主要結合各個公司的質量方

針，產(chǎn)品描述以及質量標準和規(guī)則通過收益、成本分析和流程設計等

工具制定出來實施方略，其內(nèi)容全面反應用戶的要求，為質量小組成

員有效工作提供了指南，為項目小組成員以及項目相關人員了解在項

目進行中如何實施質量保證和控制提供依據(jù)，為確保項目質量得到保

障提供堅實的基礎。質量保證則是貫穿整個項目全生命周期的有計劃

和有系統(tǒng)的活動，經(jīng)常性地針對整個項目質量計劃的執(zhí)行情況進行評

估、檢查與改進等工作，向管理者、顧客或其他方提供信任，確保項

目質量與計劃保持一致。質量控制是對階段性的成果進行檢測、驗證,

為質量保證提供參考依據(jù)，它是一個pdca循環(huán)過程。

二質量管理責任分配

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

生產(chǎn)流程上采用iso9000的標準進行。每個項目除配備了項目開發(fā)所

需角色外，還專門配備了配置管理小組、測試小組和質量保證小組確

保質量管理的實施，下面針對這三種角色進行說明：

1、配置管理小組職責

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

都同時完成。內(nèi)部文檔的及時產(chǎn)生和規(guī)范，是保證項目開發(fā)各小組能

夠更好的接口和溝通的重要前提，從另一個方面講，也是保證工程不

被某個關鍵路徑所阻塞而延滯的前提。如上所述，配置管理小組還是

保證質量保證小組得以發(fā)揮作用的基礎。配置管理小組的主要職責包

括：完善各個部門發(fā)送需要存檔和進行版本控制的代碼、文檔（包括

外來文件）和階段性成果；對代碼、文檔等進行單向出入的控制；對

所有存檔的文檔進行版本控制；提供文檔規(guī)范，并傳達到開發(fā)組中。

2、測試小組職責

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

工作。如同軟件開發(fā)一樣，測試在執(zhí)行之前，同樣需要進行測試計劃

和測試策略的設計，通常情況下測試可以分為如下幾種類型，如：正

確性測試、功能性測試、性能測試、安全測試和系統(tǒng)測試等。而這些

測試均需要在測試計劃和測試策略中進行描述用以指導測試小組成

員進行測試用例編寫和測試執(zhí)行。程序員在交給測試人員之前是進行

過一定的單元測試，確保程序編譯、運行正確。測試人員根據(jù)詳細設

計的文檔對軟件要實現(xiàn)的功能進行一一測試，保證軟件的執(zhí)行正確的

實現(xiàn)設計要求，在此也只證明了軟件正確的反映了設計思想，但是否

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

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

才能確保項目組開發(fā)的軟件產(chǎn)品滿足用戶需求。在正確性測試完成之

后，需要測試的是軟件的性能，軟件的性能在本

項目中占有重要的地位，性能要求有可能改變軟件的設計，為避

免造成軟件的后期返工，測試在性能上需要較大的側重。如果有必要

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

3、質量保證小組職責

質量保證小組作為質量保證的實施小組，主要職責是保證軟件透

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

證小組有關。質量保證小組對項目經(jīng)理提供項目進度與項目真正開發(fā)

時的差異報告，提出差異原因和改進方法。

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

時，提請項目經(jīng)理、項目負責人等必要的相關人員舉行質量會議。解

決當前存在的和潛在的問題。質量保證是建立在文檔的復審基礎之

上，因而文檔版本的控制，特別是軟件配置管理，直接影響軟件質量

保證的影響力和力度。質量保證小組的檢測范圍包括：系統(tǒng)分析人員

是否正確的反映了用戶的需求；軟件執(zhí)行體是否正確的實現(xiàn)了分析人

員的設計思想；測試人員是否進行了較為徹底的和全面的測試；配置

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

三質量管理實施

有了良好的資源配備，又如何在項目全生命周期內(nèi)實施質量保

證，讓我們從以下幾個方面來看質量保證的實施過程：

1、項目進度的質量保證

項目進度是項目進行是否順利的最直觀表現(xiàn)。顯然在項目開始之

前，項目開發(fā)計劃是必須的。如果項目開發(fā)計劃的制定的是完全合理

的，那項目進度也就真正表達了項目與最終的交付使用之間的距離，

然而要制定完全合理的項目開發(fā)計劃幾乎不太可能?？梢娨ＷC項目

進度，首先要保證項目開發(fā)計劃盡可能合理。

項目計劃的合理程度與項目計劃制定者從事類似規(guī)模和類似業(yè)

務的項目的經(jīng)驗有直接關系，通過經(jīng)驗往往能夠預見潛在的阻礙，這

樣要求項目計劃制定者需要集眾人之力來完善計劃。當項目計劃制定

初期，由質量保證小組組織召開的項目計劃評審會，邀請公司技術專

家、用戶以及項目組小組成員一起討論項目計劃的可行性，會議通常

采用頭腦風暴法，各抒己見，會后由指定的記錄員形成質量記錄，發(fā)

送給相關人員，對其計劃中不合理的地方進行修改完善，并由質量保

證人員對其結果跟蹤，以確保項目計劃完整性、可行性，完善后的計

劃交由配置管理人員進行版本控制。

然而在計劃實施過程中，計劃不是“固定化二常有人道，“計劃

趕不上變化”，但“要跟上變化”。項目計劃以里程碑為界限，將整個

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

個較小的階段的任務量和完成的任務時間，這種方式非常有利于整個

項目計劃的動態(tài)調(diào)整。也利于項目質量保證的實施。

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

由項目經(jīng)理組織負責對計劃進行周期性維護，對于已經(jīng)變動的計劃由

質保小組協(xié)助配置管理小組完成版本控制。本公司已經(jīng)開發(fā)湖南移動

的集中客服系統(tǒng)，開發(fā)中的子項目多達六個，歷時十個月，目前多數(shù)

項目已經(jīng)開發(fā)完畢，系統(tǒng)正在試運行階段，項目金額數(shù)千萬元。在這

樣的項目中，從管理者到開發(fā)人員到測試人員都積累了較為豐富的經(jīng)

驗，特別是項目開發(fā)計劃的制定，和項目進度的控制。

有效的軟件質量管理（下）

2、項目開發(fā)各階段的質量保證

a、需求分析

需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從

系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對

系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流

確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析

時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期,

糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工

期和系統(tǒng)的質量。

解決系統(tǒng)分析錯誤的方法我們公司通常采用邀請用戶參與進行

需求評定，然后對其用戶的意見由質保成員跟蹤檢測是否納入需求規(guī)

格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入

配置管理庫。

雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求

變更請求。對于開發(fā)過程存在的需求變動，我們要求用戶填寫變更申

請單發(fā)送給項目配置管理員，在通過配置配置員轉交質保小組，負責

組織專家小組和項目組成員一起討論實施變更的可行性及實施后所

帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項

欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相

應的文檔實施同步變更（包括需求規(guī)格說明書、詳細設計文、安裝手

冊、操作手冊等）。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而

將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進

行協(xié)調(diào)會議，討論變更取舍問題或是項目進度變更問題。

決定變更之后，由項目經(jīng)理組織實施變更，測試人員檢測變更結

果，而質保小組成員監(jiān)督變更實施過程并協(xié)助配置管理員對變更后的

成果物進行版本控制。變更實施完后，上線前還需要指定人員協(xié)助用

戶一同測試并由用戶簽字后同意方可上線。

b、系統(tǒng)設計

優(yōu)良的體系結構應當具備可擴展性和可配置性，而好的體系結構

則需要好的設計方法，自然設計選型成為了系統(tǒng)設計首要的工作，究

竟是采用哪種設計方法好呢。

對于設計選型不能一概而論，需要針對項目的結構、項目的特征

和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質，如

果其中大部分都沒有從事過面向對象的設計且項目進對緊迫，這樣沒

有多余的時間來培訓小組成員來掌握面向對象的設計方法，盡管眾所

周知面向對象設計方法的優(yōu)勢，我們還是不如采用面向過程的方式

（除用戶指定開發(fā)設計方式外）可以減少項目承擔的技術風險。

我們公司有過一個項目，用戶指定需要采用面向對象分析、設計

和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能選用面向對

象的軟件開發(fā)過程，由于項目小組很少從事過面向對象的開發(fā)，經(jīng)驗

缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。針

對此次開發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對于新技

術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，

導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用

集中辦公，分塊學習，學習的成果馬上向項目相關人員發(fā)布，再由配

置管理員對其發(fā)布的文檔進行整理、規(guī)類放入配置庫以供大家共享。

這樣方便大家的互相學習，減少重復的工作。在這次開發(fā)中我們公司

從管理人員、設計人員到開發(fā)人員都汲取了很多教訓，同時經(jīng)過此次

項目的開發(fā)，小組成員也積累了豐富的面向對象的開發(fā)經(jīng)驗。除設計

選型，還有一個容易被忽視的問題，就是公共類開發(fā)。公共類開發(fā)可

以減少工作中

的重復工作，降低開發(fā)成本。這要求我們再設計階段通過對用戶

需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責

設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文

檔，由質保小組組織技術專家、項目組設計人員、開發(fā)人員和測試人

員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，

及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計

文檔能為開發(fā)人員、測試人員提供切實的指導。對于可復用的設計進

行提取作為公共庫設計和開發(fā)，提供項目組或整個公司重用。最后交

由配置管理員進行設計文檔的版本控制。

C、實現(xiàn)

實現(xiàn)也就是代碼的生產(chǎn)過程。這里不僅包括代碼的產(chǎn)生，同時也

包括測試用例的產(chǎn)生。針對上一階段提供詳細設計，程序員開始編碼

并且調(diào)試程序，測試人員則根據(jù)設計進行測試用例的設計，設計出來

的用例需要得到項目組成員認可由項目經(jīng)理審核通過才能進入配置

庫。同時程序員調(diào)試完程序提交測試人員進行程序正確性檢測。

d、文檔管理

文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為

內(nèi)部文檔和外部文檔。內(nèi)部文檔包括：項目開發(fā)計劃；需求分析；體

系結構設計說明；詳細設計說明；構件索引；構件成分說明；構件接

口及調(diào)用說明；組件索引；組件接口及調(diào)用說明；類索引；類屬性及

方法說明；測試報告；測試統(tǒng)計報告；質量監(jiān)督報告；源代碼；文檔

分類版本索引；軟件安裝打包文件。

外部文檔主要包括。軟件安裝手冊；軟件操作手冊；在線幫助；

系統(tǒng)性能指標報告；系統(tǒng)操作索引。

如何保證文檔的全面性，使其真正為項目的進度提供保證，又不

因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問

題。解決此問題，其核心仍然是個“度”的問題。在本項目的開發(fā)中，

配置管理小組的一個非常重要的任務還是書寫文檔規(guī)范和文檔模板。

當有文檔模板后需要書寫文檔的人員只剩下“填空”的工作，從某種意

義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更

細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時

文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者

進行復審，復審通過后方可以正式提交，進入軟件配置管理的循環(huán)中。

配置管理小組真正核心的工作是對文檔的組織管理。根據(jù)文檔的

不同，文檔的來源也不同，有些是通過質量保證小組經(jīng)過復審之后轉

交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。

文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開

發(fā)對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風

險，更重要的是在項目進行到后百分之十的時候起到拉動項目的作

用。

從以往做大項目的經(jīng)驗來看，寫作文檔在項目開發(fā)的早期可能會

使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需

要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)

過程，才能使自己的開發(fā)向前推進。一個明顯的例子就是系統(tǒng)整合，

或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎之上時，就更顯現(xiàn)出文檔

交流的準確性和高效性。

3、系統(tǒng)維護質量保證

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

務，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來

以便投入到下一個項目的開發(fā)中。所以通常項目維護小組成員主要由

項目組的少部分開發(fā)人員承擔完成。他們不僅了解軟件的核心內(nèi)容，

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

的錯誤，如操作不當?shù)纫鸬膯栴}，全部由維護小組執(zhí)行完成，但需

要用戶測試確認上線。如果較大的修改則需要走

變更控制流程，用戶或者維護人員填寫變更申請，經(jīng)專家會議討

論分析可行方案在由維護小組實施，通過測試后方可提交用戶。

維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用

戶時，在維護小組有較多的人員進行跟進，隨軟件的穩(wěn)定，跟進的人

逐步減少，并轉移到其它項目中去。

第四篇：正版軟件管理制度正版軟件管理制度

為切實增強廣大干部職工尊重和保護知識產(chǎn)權的意識，加強鎮(zhèn)政

府的軟件正版化管理，建立長效管理機制，特制訂本管理制度。

第一條適用范圍

本制度適用于妙峰山鎮(zhèn)全體干部職工。第二條職責部門

鎮(zhèn)政府成立軟件正版化領導小組（設在辦公室），負責全面管理

和監(jiān)督本制度的貫徹和落實情況。具體負責軟件正版化工作的組織和

日常維護。

第三條軟件正版化工作重點范圍操作系統(tǒng)、辦公軟件、安全軟件

等。

第四條各科室負責人作為第一責任人，保證本科室軟件使用正版

化。

第五條領導小組辦公室制定軟件資產(chǎn)管理制度。指定人員擔任正

版軟件資產(chǎn)管理員崗位，負責正版軟件的登記造冊等工作。

第六條根據(jù)需求制定正版軟件采購計劃，并將軟件采購費用納入

年度預算，確保軟件正版化工作資金到位、措施到位、管理到位。

第七條加強軟件資產(chǎn)管理。規(guī)范正版軟件采購，購買計算機辦公

設備必須符合預裝正版操作系統(tǒng)軟件的要求，更新計算機操作系統(tǒng)軟

件必須使用正版產(chǎn)品。

第八條要建立規(guī)范的正版軟件管理臺賬，對各類正版軟件進行登

記。內(nèi)容包括：軟件名稱、版本、授權、安裝與使用情況。同時對有

關的資料（如軟件介質、說明書等）進行妥善保存。

第九條要加強軟件正版化培訓工作，進一步提高工作人員操作、

使用軟件的能力和水平，提高工作人員的法律意識，使用正版軟件更

好地服務于機關各項工作。

第十條防止任何可能侵犯軟件知識產(chǎn)權的風險應注意：

1.電腦內(nèi)已安裝未授權的軟件，應立即移除。

2.對以團體身份獲得使用權的軟件，需確保已安裝的軟件數(shù)目沒

有超過已購置的軟件許可數(shù)RO

3,購買新的電腦時，已預裝相關軟件的，要核對該軟件是否已獲

得適當?shù)氖跈唷?/p>

4.加強版權意識，不準向其他單位或個人提供任何正版軟件。因

向其他單位或個人提供正版軟件而造成版權糾紛者，由軟件提供人承

擔一切后果，未取得版權擁有人的明確批準，不得復制及更改軟件。

第十一條鎮(zhèn)機關職工不得從事下列行為：

1.擅自復制和銷售計算機軟件產(chǎn)品的復制品。

2.在購買計算機等設備時，要求或允許銷售商安裝非正版軟件。

3.超越授權使用許可的要求擴大安裝范圍。

4.未經(jīng)授權把計算機軟件放在網(wǎng)上供他人下載。

5.明知未經(jīng)授權的計算機軟件而從網(wǎng)上下載。

6.故意規(guī)避或破壞軟件著作權人為保護其著作權而采用的技術

措施。

7.故意刪除或改變計算機軟件權力管理信息。

第十二條對于使用非法軟件給鎮(zhèn)機關形象造成重大影響的，一經(jīng)

查出，除追究相關責任人的責任外，還將追究相關科室負責人的行政

責任。

第十三條本管理制度由鎮(zhèn)軟件正版化領導小組辦公室負責解釋

說明。

第十四條本管理制度自印發(fā)之日起施行。

第五篇：軟件部門管理制度軟件部門管理制度

第一章、工作

第1條員工應遵守本公司一切規(guī)章、通告及公告。

第2條員工應遵守下列工作事項：

1）在每工作日9。10前明確（制定）當天的工作計劃。

2）在每工作日17。50前必須將代碼在不報錯的形式下簽入指定

的源代碼管理器中，并且做好自己的本地備份，并且在工作計劃系統(tǒng)

里提交當天的工作總結。項目主管每周五負責對源代碼管理器進行本

地備份及錯誤的修復。

3）員工在每月的10號前對本月的工作大概做出計劃，并且對上

月的工作計劃做出總結，以書面形式交由部門經(jīng)理。

4）對公司產(chǎn)品軟件的任何修改都需要業(yè)務部門及信息中心相關

領導的審批，并且修改之后的效果也必須經(jīng)由相關領導認可，及時將

所更改的功能對相關培訓人員進行講解。

5）嚴格遵守以下的軟件開發(fā)流程：

①.簽定《系統(tǒng)開發(fā)需求申請單》；

②,進行需求調(diào)查，填寫《需求說明書》；

③制定相應的《項目開發(fā)計劃》；

④,填寫《項目估計表》，進入需求封閉期；

⑤.在規(guī)定的時間內(nèi)向業(yè)務部門提交《需求設計報告》（注：此項

流程不計入開發(fā)周期）；

⑥.嚴格控制需求變更，如果實在需要變更需求，需要填寫《需

求變更報告》，并且及時更新相應的文檔；

⑦.在開發(fā)周期內(nèi)根據(jù)《項目開發(fā)計劃》進行軟件項目的開發(fā)；

⑧.在開發(fā)周期內(nèi)開發(fā)人員每天需要向上級提交電子檔的《開發(fā)

進度報告》，總結每天的編程心得；

⑨.在開發(fā)周期內(nèi)至少每周制定一次《技術評審計劃》并且填寫

《技術評審報告》；

⑩.對系統(tǒng)進行測試時需要制定《系統(tǒng)測試計劃》、設計《測試用

例》，最終填寫《測試報告》；

?.測試完畢，在實際系統(tǒng)中上版，并對相關操作人員進行培訓

6）在開發(fā)的過程中必須嚴格遵守公司頒布的最新的《編碼規(guī)范》

和《數(shù)據(jù)庫設計

規(guī)范》。

7）在每周一部門經(jīng)理應對本周工作做出計劃及安排，并在周五

進行一次工作總結。

8）在工作時間里不得怠慢拖延，不得干與本職工作無關的事情。

9）在工作時間里不得中途任意離開崗位，如需離開應向主管人

員請示并獲批準后

方可離開。

10）未經(jīng)許可不得私自將公司資料攜帶出公司。

11）任何人未經(jīng)允許，不得擅自將自己的電腦配件安裝在工作電

腦上。

12）未經(jīng)機主本人允許，不得擅自使用、移動或拆裝他人的計算

機。

13）員工對自己的工作電腦既有使用的權利又有保護的義務。任

何的硬件損壞必須

給出損壞報告，說明損壞原因。

14）不得安裝有可能危及公司計算機網(wǎng)絡的任何軟件，如果確實

有需要進行軟件測

試的，必須將計算機脫離公司計算機網(wǎng)絡進行單機操作。任何對

公司內(nèi)部計算機網(wǎng)絡的黑客行為是絕對禁止的，一經(jīng)查實將按公司有

關規(guī)定嚴肅處理。

15）公司提供的互聯(lián)網(wǎng)訪問服務只能被使用在與公司業(yè)務有關的

方面，否則一經(jīng)查

實將按公司有關規(guī)定嚴肅處理

第二章、培訓

第3條為提高員工的知識技能及發(fā)揮其潛在智能，使公司人力資

源能適應本

公司日益迅速發(fā)展的需要，公司將舉行各種教育培訓活動，被指

定員工，不得無故缺席，確有特殊原因，應按有關請假制度執(zhí)行。

第4條新員工進入公司后，須接受公司的崗前專業(yè)培訓，培訓時

間應不少于

20小時，新員工培訓由公司根據(jù)人員錄用的情況安排，在新進

公司的前三個月內(nèi)進行，培訓不合格者不再繼續(xù)留用。

第5條員工培訓期間，針對每次培訓I,都需要有培訓記錄及總結。

第6條培訓的主要內(nèi)容：

1）本職位的任務、責任和權限；

2）代碼規(guī)范及其它相關開發(fā)規(guī)定；

3）專業(yè)技術的提高；

4）需求分析能力；

5）產(chǎn)品意識；