福利视频专区,国产精品视频一区二区三区不卡

江西貝思特信息科技有限公司的各級管理人員和各個(gè)開發(fā)組都認(rèn)識到，只有通過不斷的過程改進(jìn)才能使我們?nèi)藛T的能力和先進(jìn)的技術(shù)得到充分的發(fā)揮。因此，公司決定采用軟件能力成熟度模型（CMMI3 ）這一標(biāo)準(zhǔn)來提高軟件組織的工作效率、產(chǎn)品質(zhì)量和項(xiàng)目的可預(yù)見性。

為了使公司所有項(xiàng)目組都使用統(tǒng)一的過程和文檔，得到的文檔和實(shí)踐集合將被所有大小項(xiàng)目組共同使用。這些文檔和實(shí)踐集合同時(shí)也是項(xiàng)目執(zhí)行績效考核的指標(biāo)。

1.2 目標(biāo)

1、確定軟件開發(fā)過程中最基本的文檔模板和實(shí)踐

2、統(tǒng)一項(xiàng)目組的過程管理

3、項(xiàng)目執(zhí)行績效考核的指標(biāo)

4、公司順利推行CMMI3

1.3 適用范圍

公司所有項(xiàng)目組的軟件產(chǎn)品開發(fā)過程管理要求符合本手冊的要求。

1.4 術(shù)語

PP：Project Plan項(xiàng)目策劃

PTO：Project Tracing and Oversight項(xiàng)目跟蹤與監(jiān)督

RM：Requirement Management需求管理

SQA：Software Quality Assurance軟件質(zhì)量保證

SCM：Software Configuration Management軟件配置管理

LC：Life Cycle生命周期

SCCB：Software Change Control Board軟件變更控制委員會

NC：NonCompliance不符合問題

2 文件清單

下面列出經(jīng)過過程裁減后的文件最小集合，文件的使用方法請參見模板。

2.1 軟件項(xiàng)目策劃PP

以下文件路徑為：http://192.168.0.20

序號

文件名稱/文檔標(biāo)識

文檔類型

使用頻率

備注

軟件開發(fā)計(jì)劃/

軟件工作產(chǎn)品

一個(gè)

需要正規(guī)技術(shù)評審

需要上傳到項(xiàng)目工作管理系統(tǒng)

項(xiàng)目估算表

軟件工作產(chǎn)品

一個(gè)

需要正規(guī)技術(shù)評審

需要上傳到項(xiàng)目工作管理系統(tǒng)

軟件主進(jìn)度計(jì)劃/

軟件工作產(chǎn)品

一個(gè)

使用項(xiàng)目工作管理系統(tǒng)，有必要可以導(dǎo)出。需要正規(guī)技術(shù)評審

需要上傳到項(xiàng)目工作管理系統(tǒng)

迭代進(jìn)度計(jì)劃/

軟件工作產(chǎn)品

每個(gè)迭代周期一個(gè)本周期的進(jìn)度計(jì)劃

使用項(xiàng)目工作管理系統(tǒng)，有必要可以導(dǎo)出

2.2 軟件項(xiàng)目跟蹤與監(jiān)督PTO

以下文件路徑為：

序號

文件名稱/文檔標(biāo)識

文檔類型

使用頻率

備注

啟動會議紀(jì)要

軟件工作產(chǎn)品

每階段一個(gè)

需要上傳到項(xiàng)目工管理系統(tǒng)

周例會紀(jì)要/

軟件工作產(chǎn)品

每周一個(gè)

需要上傳到項(xiàng)目工作管理系統(tǒng)

風(fēng)險(xiǎn)狀態(tài)跟蹤表/

軟件工作產(chǎn)品

一個(gè)

初始評估或者風(fēng)險(xiǎn)影響及狀態(tài)等發(fā)生變化時(shí)填寫

項(xiàng)目工作總結(jié)/

軟件工作產(chǎn)品

項(xiàng)目結(jié)束時(shí)每人一個(gè)

需要上傳到項(xiàng)目工作管理系統(tǒng)

里程碑工作總結(jié)/

軟件工作產(chǎn)品

每個(gè)里程碑一個(gè)

需要上傳到項(xiàng)目工作管理系統(tǒng)

項(xiàng)目管理度量報(bào)告

軟件工作產(chǎn)品

每個(gè)里程碑一個(gè)

需要上傳到項(xiàng)目工作管理系統(tǒng)

2.3 需求管理RM

以下文件路徑為：

序號

文件名稱/文檔標(biāo)識

文檔類型

使用頻率

備注

特征狀態(tài)跟蹤表/

軟件工作產(chǎn)品

一個(gè)

每迭代周期更新。可以使用CaliberRM導(dǎo)出符合格式的文檔

2.4 軟件生命周期LC

以下文件路徑為：

序號

文件名稱/文檔標(biāo)識

文檔類型

使用頻率

備注

工作任務(wù)書/

軟件產(chǎn)品

一個(gè)

需要正規(guī)技術(shù)評審

需要上傳到項(xiàng)目工作管理系統(tǒng)

需求規(guī)格說明書/

軟件產(chǎn)品

一個(gè)

需求規(guī)格說明書(SRS)包括：需求項(xiàng)與特征、PowerPoint演示文檔、界面雛形(只需要增加原產(chǎn)品中沒有的部分)、用例說明。其中對界面雛形變更修改不作要求。需要正規(guī)技術(shù)評審

領(lǐng)域模型文件

軟件工作產(chǎn)品

一個(gè)

ROSE的mdl文件，術(shù)語表文件

需要正規(guī)技術(shù)評審

產(chǎn)品模式不需要

新開發(fā)項(xiàng)目需要

數(shù)據(jù)庫設(shè)計(jì)文件(cdm文件)

軟件工作產(chǎn)品

一個(gè)

有選擇值的字段必須加上說明。需要正規(guī)技術(shù)評審

概要設(shè)計(jì)說明書/

軟件產(chǎn)品

一個(gè)

需要正規(guī)技術(shù)評審

詳細(xì)設(shè)計(jì)說明書/

軟件產(chǎn)品

多個(gè)

1個(gè)模塊或幾個(gè)模塊1份。需要走查

用戶手冊/

軟件產(chǎn)品

一個(gè)

在線幫助，使用幫助文檔工具編寫，例如robohelp。需要走查

部署說明書/

軟件產(chǎn)品

一個(gè)

單元測試記錄表/

軟件工作產(chǎn)品

一個(gè)

10.

系統(tǒng)測試用例/

軟件工作產(chǎn)品

一個(gè)

保存在TD中，項(xiàng)目結(jié)束時(shí)導(dǎo)出到文檔放入項(xiàng)目組的配置庫。需要走查

11.

系統(tǒng)測試總結(jié)報(bào)告/

軟件工作產(chǎn)品

每個(gè)里程碑一個(gè)

12.

系統(tǒng)測試任務(wù)單/

軟件工作產(chǎn)品

每次提交到測試組測試時(shí)一個(gè)

填寫紙質(zhì)文件

13.

技術(shù)評審報(bào)告/

軟件工作產(chǎn)品

每次評審一個(gè)

14.

系統(tǒng)發(fā)布操作手冊

軟件工作產(chǎn)品

一個(gè)

包含多個(gè)系統(tǒng)的發(fā)布操作說明，和單個(gè)系統(tǒng)的發(fā)布說明，寫明重要的檢查內(nèi)容

15.

系統(tǒng)發(fā)布說明

軟件工作產(chǎn)品

每次向客戶發(fā)布時(shí)一個(gè)

填寫電子文件，打印紙質(zhì)簽字

2.5 軟件質(zhì)量保證SQA

以下文件路徑為：

序號

文件名稱/文檔標(biāo)識

文檔類型

使用頻率

備注

SQA進(jìn)度計(jì)劃/

軟件工作產(chǎn)品

一個(gè)

走查

SQA報(bào)告/

軟件工作產(chǎn)品

每月一個(gè)

每周更新

項(xiàng)目階段質(zhì)量檢查表/

軟件工作產(chǎn)品

每個(gè)里程碑一個(gè)，項(xiàng)目結(jié)束時(shí)一個(gè)

SQA質(zhì)量報(bào)告/

軟件工作產(chǎn)品

每里程碑及項(xiàng)目結(jié)束時(shí)一個(gè)

3 項(xiàng)目過程

文檔必須和過程結(jié)合在一起，才能發(fā)揮作用。我們可以將項(xiàng)目過程及文檔分為技術(shù)和管理兩個(gè)部分。下圖描述在軟件工程和項(xiàng)目管理的各個(gè)步驟文檔的輸出。

軟件工程的文檔輸出

項(xiàng)目管理的文檔輸出

4 組間協(xié)作

A.軟件項(xiàng)目內(nèi)各組之間（如QA組，CM組，測試組，開發(fā)組等）的交流、協(xié)調(diào)工作由項(xiàng)目經(jīng)理負(fù)責(zé)，一般采取項(xiàng)目會議的形式。任何組如果有計(jì)劃上的變更，需要通過會議、進(jìn)度報(bào)告和內(nèi)部郵件的方式與各相關(guān)組進(jìn)行約定。

B.需與項(xiàng)目外其它組進(jìn)行的協(xié)作，則通過PM或高層經(jīng)理完成，協(xié)調(diào)工作的進(jìn)展與結(jié)果可通過會議、進(jìn)度報(bào)告和內(nèi)部郵件的方式與各相關(guān)組進(jìn)行溝通。

C.與客戶聯(lián)絡(luò)工作由客戶交流窗口和項(xiàng)目經(jīng)理（可為同一人）共同負(fù)責(zé)，必要時(shí)，高層經(jīng)理也會適當(dāng)參與。如果有計(jì)劃上的變更，需要通過會議、進(jìn)度報(bào)告和內(nèi)部郵件的方式與各相關(guān)組進(jìn)行協(xié)商。

5 關(guān)鍵實(shí)踐集

這些關(guān)鍵實(shí)踐來自于經(jīng)典軟件工程和CMMI的實(shí)踐方法和經(jīng)驗(yàn)總結(jié)。無論項(xiàng)目組大小，項(xiàng)目采取何種生命周期，項(xiàng)目實(shí)施周期長短，熟練運(yùn)用這些實(shí)踐可以起到很好的效果，例如縮短原定進(jìn)度，改善過程可視性，降低項(xiàng)目風(fēng)險(xiǎn)等。因此這些關(guān)鍵實(shí)踐是每個(gè)項(xiàng)目都必須執(zhí)行的。

5.1 項(xiàng)目準(zhǔn)備

項(xiàng)目準(zhǔn)備階段，項(xiàng)目經(jīng)理與需求分析人員進(jìn)行初步的需求調(diào)研，整理客戶需求形成工作任務(wù)書，并根據(jù)工作任務(wù)書制定項(xiàng)目計(jì)劃(包括軟件開發(fā)計(jì)劃、軟件主進(jìn)度計(jì)劃、軟件項(xiàng)目估計(jì))，軟件開發(fā)計(jì)劃中必須指明需求規(guī)格說明書、概要設(shè)計(jì)說明書的評審時(shí)間。列出初始評估的風(fēng)險(xiǎn)狀態(tài)跟蹤表。工作任務(wù)書、項(xiàng)目計(jì)劃評審?fù)ㄟ^，配置庫和TD庫建立之后正式進(jìn)入第一個(gè)迭代周期。

5.2 軟件估計(jì)

通過功能點(diǎn)估計(jì)法可以估算出一個(gè)產(chǎn)品的規(guī)模。在項(xiàng)目策劃初期，根據(jù)需求估計(jì)出功能點(diǎn)數(shù)，由公司的生產(chǎn)率（功能點(diǎn)數(shù)/人月），可以得出完成系統(tǒng)所需的工作量，作為人力資源安排的參考。在需求項(xiàng)有變化時(shí)也應(yīng)更新估計(jì)。

理解客戶需求最好的辦法是站在客戶的角度分析軟件系統(tǒng)產(chǎn)生的結(jié)果，從而來確定客戶關(guān)心的問題。功能點(diǎn)分析的一個(gè)主要的目標(biāo)就是從用戶的角度定義系統(tǒng)的能力。從用戶的觀點(diǎn)來看，系統(tǒng)是從五個(gè)基本方面幫助他們進(jìn)行工作的：

內(nèi)部邏輯文件、外部接口文件、外部輸入、外部輸出、外部查詢

除了以上五個(gè)方面，功能點(diǎn)分析中還要考慮分布式數(shù)據(jù)處理、在線更新等14項(xiàng)復(fù)雜度的調(diào)整。

功能點(diǎn)估計(jì)的模板參見配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\pp\template\《軟件項(xiàng)目估計(jì)模板(comtop-pp-tmp-est).xls》。

5.3 啟動會議

啟動會議(包括階段啟動會議)的參與人員有：研發(fā)中心經(jīng)理、項(xiàng)目部經(jīng)理、技術(shù)研究部經(jīng)理、項(xiàng)目經(jīng)理、軟件工程組（包括分析設(shè)計(jì)、開發(fā)、測試、配置管理工程師）、質(zhì)量保證工程師、文檔支持組等。

會前的準(zhǔn)備工作：

確定項(xiàng)目經(jīng)理，挑選合適的人員加入軟件工程組，確定項(xiàng)目需要的資源和支持，包括人力資源，設(shè)備，工具，文檔支持，技術(shù)研究部的支持，設(shè)備采購的支持等。

啟動會議的主要內(nèi)容：

介紹項(xiàng)目背景，目標(biāo)，范圍以及項(xiàng)目的風(fēng)險(xiǎn)；

正式任命項(xiàng)目經(jīng)理；

確定項(xiàng)目的組織結(jié)構(gòu)和人員的角色職責(zé)；

采用頭腦風(fēng)暴法進(jìn)行團(tuán)隊(duì)建設(shè)活動，為團(tuán)隊(duì)命名，口號，行動綱領(lǐng)，隊(duì)徽。

5.4 迭代開發(fā)

經(jīng)過幾十年的發(fā)展，軟件工程領(lǐng)域出現(xiàn)了很多種軟件生命周期模型，有瀑布型，迭代型，增量型等等。瀑布模型來源于建筑行業(yè)、制造行業(yè)等可預(yù)測的生產(chǎn)，本來就無法適應(yīng)需求不穩(wěn)定的軟件項(xiàng)目。因此許多項(xiàng)目盡管在一開始就規(guī)定采用瀑布型，卻在實(shí)踐中慢慢變成了迭代型。迭代是一個(gè)能夠產(chǎn)生內(nèi)部版本的袖珍項(xiàng)目－或多或少要經(jīng)歷所有的核心工作流。通過循環(huán)反復(fù)的活動和原則使產(chǎn)生的結(jié)果越來越接近期望的結(jié)果。

迭代型的開發(fā)進(jìn)度計(jì)劃可以分為兩個(gè)層次，第一個(gè)層次是總體的計(jì)劃(主進(jìn)度計(jì)劃)，可能歷時(shí)幾年或者幾個(gè)月，為團(tuán)隊(duì)的工作指出了方向。在總體進(jìn)度計(jì)劃中主要關(guān)注里程碑，每個(gè)里程碑要完成的目標(biāo)或者需求項(xiàng)(可以包括特征)?？傮w計(jì)劃劃分整個(gè)項(xiàng)目的工作到各個(gè)迭代周期中，并不關(guān)注執(zhí)行細(xì)節(jié)，時(shí)間跨度較大可能會因?yàn)樾枨蟮淖兓抻啞？傮w計(jì)劃要確定迭代周期多長，一般為2-3周。第二個(gè)層次是短期的詳細(xì)計(jì)劃，即各個(gè)迭代周期的計(jì)劃，關(guān)注執(zhí)行細(xì)節(jié)，將具體的任務(wù)落實(shí)到人，并且由于時(shí)間跨度小相對穩(wěn)定，可以確定本迭代周期完成時(shí)的詳細(xì)交付物。每次迭代，我們只需要制定當(dāng)前迭代周期的計(jì)劃即可，到了迭代的后期才能確定什么需要在下個(gè)周期內(nèi)完成的事情。進(jìn)度計(jì)劃中必須包含項(xiàng)目管理的工作，如編寫文檔、評審、代碼走查、周例會等。

總體計(jì)劃中，2-3個(gè)迭代周期要定義一個(gè)里程碑。

作為迭代周期完成的標(biāo)志，每個(gè)迭代周期完成后要開會總結(jié)，評估迭代的交付物，明確下一個(gè)迭代周期的任務(wù)。

5.5 設(shè)計(jì)界面雛形與用例說明

對于產(chǎn)品型的項(xiàng)目，產(chǎn)品中已有的部分不需要編寫界面雛形，只需要對產(chǎn)品中沒有的模塊設(shè)計(jì)界面雛形，對于非產(chǎn)品型的項(xiàng)目，必須設(shè)計(jì)界面雛形。

界面雛形作為需求規(guī)格說明書的一部分，在與客戶或相關(guān)人員溝通時(shí)，比用一般的書面文字說明更容易被理解，從而更有效的獲得用戶及相關(guān)人員的反饋。

需求或設(shè)計(jì)變更后，對界面雛形的修改不做要求。

界面雛形使用html編制，使用ppt向客戶進(jìn)行演示。

設(shè)計(jì)界面雛形用來收集用戶的需求有以下好處：

使最終用戶更熱情的參與到需求活動中來，并且改善系統(tǒng)需求的反饋；

減少項(xiàng)目風(fēng)險(xiǎn)，因?yàn)橛脩艚涌谥芯哂酗L(fēng)險(xiǎn)的部分在早期就發(fā)現(xiàn)了；

使軟件產(chǎn)品和最終用戶的需要更接近；

減少系統(tǒng)特性的數(shù)量，迅速確定系統(tǒng)的特征和功能；

減少用戶需求的變化；

提高項(xiàng)目早期工作進(jìn)展的可見性。

用戶界面雛形要讓用戶參與，積極征求他們的反饋意見。用戶界面雛形要有一個(gè)漂亮的外觀吸引用戶的注意力。最好讓經(jīng)驗(yàn)豐富的開發(fā)人員來構(gòu)建界面雛形。在構(gòu)建界面雛形時(shí)，開發(fā)人員要有一個(gè)良好的意識，就是要以盡量小的工作量來探明界面雛形中涉及到的風(fēng)險(xiǎn)。

用例描述了在不同條件下，系統(tǒng)對某一系統(tǒng)相關(guān)人員的請求所作出的響應(yīng)。提出請求的人員被稱為執(zhí)行者。執(zhí)行者通過發(fā)起與系統(tǒng)的一次交互來實(shí)現(xiàn)某個(gè)目標(biāo)。根據(jù)執(zhí)行作出的請求和請求涉及的條件，系統(tǒng)將執(zhí)行不同的行為序列（基本流程與可選流程）。

一個(gè)用例至少要包括以下幾個(gè)部分：

用例名稱

執(zhí)行者：啟動與被討論系統(tǒng)的一次交互活動，從而達(dá)到某一目標(biāo)的人或物。

前置條件：在用例執(zhí)行之前必須滿足的條件。

基本流程：一切順利的情況。

可選流程：執(zhí)行過程中出現(xiàn)的不同情況

業(yè)務(wù)規(guī)則

用例詳細(xì)地描述了系統(tǒng)被使用時(shí)的行為細(xì)節(jié)，在需求開發(fā)階段，用例與界面雛形相輔相成，使得用戶能夠明白新系統(tǒng)到底是什么樣的。有利于用戶盡早對系統(tǒng)運(yùn)行的細(xì)節(jié)作出判斷。

用例評審?fù)ㄟ^后，開發(fā)人員據(jù)此進(jìn)行設(shè)計(jì)與編寫代碼，測試組參考編寫測試用例，文檔編寫組參考編寫用戶手冊。

當(dāng)用戶需求有變化，必須更新用例說明。

編寫用例時(shí)，應(yīng)顯示執(zhí)行者的意圖而不是動作，并避免大量描述用戶接口，如想象中的界面及其按鈕。使得用例變成了用戶手冊，而不是需求文檔。

5.6 特征跟蹤

需求項(xiàng)的粒度過大，對于需求項(xiàng)的完成及變更情況難以跟蹤，不利于迭代。我們將每個(gè)需求項(xiàng)細(xì)分為若干個(gè)特征，可以很方便的將特征分配到各個(gè)迭代周期中，從而對特征的完成情況及變更進(jìn)行跟蹤，使項(xiàng)目更容易被控制。將需求項(xiàng)細(xì)分為多個(gè)特征，比如：項(xiàng)目審批（需求項(xiàng)）可以分為以下特征：增、刪、改、查、關(guān)聯(lián)到申請書、發(fā)送、批量發(fā)送、默認(rèn)回退、指定回退、改變申請人等。項(xiàng)目組在需求管理中必須利用特征跟蹤表對特征進(jìn)行跟蹤。

5.7 設(shè)計(jì)領(lǐng)域模型

在概要設(shè)計(jì)評審之前，項(xiàng)目組必須使用ROSE完成領(lǐng)域模型的設(shè)計(jì)（*.mdl文件），對領(lǐng)域模型必須劃分出包的結(jié)構(gòu)，以類圖的形式來表現(xiàn)，類圖中要有類的關(guān)鍵屬性、類之間的關(guān)聯(lián)關(guān)系（聚合，組合，關(guān)聯(lián)，泛化，實(shí)現(xiàn)，一對多，多對多等），領(lǐng)域模型不需要描述類的方法。應(yīng)該使用術(shù)語表來說明類圖中的英文含義。術(shù)語表另附文件。

在系統(tǒng)開發(fā)過程中，領(lǐng)域模型設(shè)計(jì)必須與最新的變化保持一致。

5.8 詳細(xì)設(shè)計(jì)

1）詳細(xì)設(shè)計(jì)說明書的定位：起溝通和備忘錄的作用

2）項(xiàng)目組確定哪些模塊需要編寫詳細(xì)設(shè)計(jì)，以及模塊的英文簡寫，并提供清單給QA

3）詳細(xì)設(shè)計(jì)說明書的內(nèi)容：

ü 各模塊之間的聯(lián)動，對一個(gè)模塊的操作將引起其他哪些模塊做哪些變化

ü 公式(比如資金計(jì)算公式等)及算法

ü 實(shí)現(xiàn)時(shí)候的注意事項(xiàng)，例如性能、數(shù)據(jù)庫事務(wù)等

ü 查詢、導(dǎo)出的數(shù)據(jù)的檢索條件

ü 權(quán)限的分配(數(shù)據(jù)權(quán)限，操作權(quán)限等)

ü 新增數(shù)據(jù)的初始值

ü 數(shù)據(jù)的狀態(tài)變化，例如項(xiàng)目的狀態(tài)值

ü 級聯(lián)刪除

ü 不能重復(fù)的信息，例如用戶賬號

……

以下內(nèi)容不必寫在詳細(xì)設(shè)計(jì)文檔中：

ü 系統(tǒng)的操作步驟

ü 界面的跳轉(zhuǎn)

ü 系統(tǒng)的按鈕操作

……

4）詳細(xì)設(shè)計(jì)說明書的描述：可以是文字、圖形、表格、結(jié)構(gòu)化語言。模板參見\軟件過程管理指南(適用于公司所有項(xiàng)目)\lc\template\詳細(xì)設(shè)計(jì)說明書模板

5）項(xiàng)目組要走查詳細(xì)設(shè)計(jì)說明書

5.9 使用項(xiàng)目工作管理系統(tǒng)

項(xiàng)目工作管理系統(tǒng)是江西貝思特信息科技有限公司為管理項(xiàng)目而開發(fā)的一套管理系統(tǒng)，其中最主要的功能是進(jìn)度安排、項(xiàng)目文件和工作日志。每個(gè)項(xiàng)目組必須使用項(xiàng)目工作管理系統(tǒng)進(jìn)行項(xiàng)目內(nèi)部的協(xié)作和溝通。具體要求如下：

項(xiàng)目經(jīng)理制定總體進(jìn)度計(jì)劃，確定里程碑。

項(xiàng)目經(jīng)理制定迭代進(jìn)度計(jì)劃，并將工作分配給項(xiàng)目成員。

項(xiàng)目成員在完成工作后必須及時(shí)填寫進(jìn)度安排的實(shí)際開始和結(jié)束時(shí)間。

項(xiàng)目發(fā)生需求變更或者進(jìn)度落后時(shí)，項(xiàng)目經(jīng)理必須及時(shí)更新進(jìn)度安排以符合實(shí)際情況。

項(xiàng)目過程中產(chǎn)生文檔必須及時(shí)上傳到項(xiàng)目文件中，使相關(guān)人員了解到項(xiàng)目的實(shí)際情況。必須上傳的文件見第2章文件清單，必須上傳的文件在“備注”一欄有說明。

項(xiàng)目的所有成員包括項(xiàng)目經(jīng)理每天都必須填寫工作日志。

項(xiàng)目經(jīng)理必須每天查看項(xiàng)目組員的工作日志。

每周必須有周例會紀(jì)要，周例會紀(jì)要必須24小時(shí)內(nèi)放入配置庫及上傳到項(xiàng)目工作管理系統(tǒng)中。

5.10 里程碑會議

項(xiàng)目經(jīng)理需要確定項(xiàng)目采用何種軟件生命周期模型，默認(rèn)情況下里程碑就是各個(gè)階段點(diǎn)。階段點(diǎn)太近時(shí)可以合并里程碑會議，項(xiàng)目中的一些重要事件也可以設(shè)定為里程碑。

里程碑會議之前要完成并通過項(xiàng)目的內(nèi)部驗(yàn)收。里程碑會議上，項(xiàng)目經(jīng)理總結(jié)該階段的工作成果和交付項(xiàng)，研發(fā)中心經(jīng)理、項(xiàng)目部經(jīng)理將出席，就項(xiàng)目的上一階段工作成果進(jìn)行階段性驗(yàn)收。如果有可能，應(yīng)該邀請客戶代表出席該會議。會議上對運(yùn)行的系統(tǒng)進(jìn)行演示，如果從項(xiàng)目開始或從上里程碑到當(dāng)前里程碑有軟件測試活動，則里程碑會議上測試組必須提交測試總結(jié)報(bào)告，SQA組提交階段質(zhì)量報(bào)告并且匯報(bào)內(nèi)部驗(yàn)收的執(zhí)行情況。

里程碑會議的主要內(nèi)容是：

1. 與會人員與會議議程介紹

2. 階段工作總結(jié)

3. 項(xiàng)目度量數(shù)據(jù)匯報(bào)

4. 質(zhì)量保證工作匯報(bào)

5. 測試工作匯報(bào)

6. 組員談本階段的工作體會

7. 系統(tǒng)演示

8. 下階段工作安排

9. 自由發(fā)言

5.11 風(fēng)險(xiǎn)清單

風(fēng)險(xiǎn)清單是一種能夠幫助我們監(jiān)控軟件項(xiàng)目風(fēng)險(xiǎn)的簡單的工具。該清單中包括了組織積累的各種等級的風(fēng)險(xiǎn)并對各個(gè)風(fēng)險(xiǎn)所制定的預(yù)防計(jì)劃。能夠提高項(xiàng)目組的風(fēng)險(xiǎn)意識，同時(shí)能提醒大家盡快找到解決方法。

在有風(fēng)險(xiǎn)影響及狀態(tài)變化時(shí)必須更新風(fēng)險(xiǎn)狀態(tài)跟蹤表，風(fēng)險(xiǎn)清單應(yīng)該由項(xiàng)目組共同維護(hù)，包括項(xiàng)目經(jīng)理、軟件工程組、SCM、SQA。

5.12 技術(shù)評審

1）技術(shù)評審分為走查（可以是代碼走查、文檔走查），正規(guī)評審

2）對需要評審的文檔項(xiàng)目組內(nèi)部必須事先達(dá)成一致

3）在正式評審前要有個(gè)預(yù)備會議，作者進(jìn)行講解（或由作者個(gè)別溝通講解），使評審員都對文檔了解后再進(jìn)行評審

4） SQA在正式評審前先詢問與會人員是否了解文檔的內(nèi)容，若有人不了解，會議另行擇期舉行

5）建議技術(shù)評審使用各類檢查表（參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\lc\checklist）。評審人員在評審過程中可以對原有的檢查表進(jìn)行完善和補(bǔ)充，將完善后的檢查表提交給SEPG審查后入配置庫

6）評審人員在正式評審會議上提出所發(fā)現(xiàn)的缺陷

7）限制評審會的時(shí)間，最好不超過2小時(shí)

8）評審會后24小時(shí)內(nèi)將發(fā)現(xiàn)的缺陷錄入TD，填寫技術(shù)評審報(bào)告并入配置庫

a) 文檔評審中發(fā)現(xiàn)的錯(cuò)別字可以當(dāng)場改正，不需要作為缺陷錄入TD

b) 組內(nèi)代碼走查需要將發(fā)現(xiàn)的缺陷錄入TD并且填寫技術(shù)評審報(bào)告

9）跟蹤人檢查缺陷的修改與關(guān)閉

10）評審發(fā)現(xiàn)的缺陷必須在一周內(nèi)關(guān)閉

11）技術(shù)評審的文檔與參加角色

文檔名稱

評審形式

參加角色

工作任務(wù)書

正規(guī)技術(shù)評審

高級經(jīng)理、項(xiàng)目經(jīng)理、SQA

軟件開發(fā)計(jì)劃、軟件主進(jìn)度計(jì)劃、軟件項(xiàng)目估計(jì)

正規(guī)技術(shù)評審

高級經(jīng)理、項(xiàng)目經(jīng)理、SQA、測試人員、技術(shù)研究部代表

需求規(guī)格說明書

正規(guī)技術(shù)評審

高級經(jīng)理、項(xiàng)目經(jīng)理、SQA、測試人員、技術(shù)研究部經(jīng)理

領(lǐng)域模型文件

正規(guī)技術(shù)評審

高級經(jīng)理、項(xiàng)目經(jīng)理、SQA、技術(shù)研究部經(jīng)理；評審時(shí)間在需求規(guī)格說明書評審之后，在概要設(shè)計(jì)說明書評審之前。

數(shù)據(jù)庫設(shè)計(jì)文件(cdm文件)

正規(guī)技術(shù)評審

項(xiàng)目經(jīng)理、技術(shù)研究部代表

概要設(shè)計(jì)說明書

正規(guī)技術(shù)評審

項(xiàng)目經(jīng)理、技術(shù)研究部代表

詳細(xì)設(shè)計(jì)說明書

走查

項(xiàng)目經(jīng)理、設(shè)計(jì)人員、開發(fā)人員

系統(tǒng)測試用例

走查

項(xiàng)目經(jīng)理、測試人員、設(shè)計(jì)人員

用戶手冊/在線幫助

走查

項(xiàng)目經(jīng)理、測試人員

12）項(xiàng)目結(jié)束時(shí)，必須對領(lǐng)域模型、概要設(shè)計(jì)說明書、數(shù)據(jù)庫設(shè)計(jì)進(jìn)行再次評審

13）代碼走查說明

a) 各個(gè)項(xiàng)目無論是開發(fā)、實(shí)施、維護(hù)階段，都需要進(jìn)行代碼走查

b) 各項(xiàng)目成員至少每周要check in提交一次代碼

c) 每個(gè)項(xiàng)目組至少有一位代碼負(fù)責(zé)人，代碼負(fù)責(zé)人負(fù)責(zé)每天檢查項(xiàng)目組最新入庫的代碼，主要檢查Action、DAO代碼是否有“常見的代碼壞味道”(參見公司的BBS上的技術(shù)交流區(qū) >> 軟件工程>>關(guān)于代碼走查的討論)，Action、JSP文件的命名以及所在目錄是否正確，并且盡量給出更合理的實(shí)現(xiàn)方式

d) 要求各項(xiàng)目組每周舉行一次代碼走查的會議，會議議程主要是公布代碼負(fù)責(zé)人每天走查的情況和其他項(xiàng)目組走查的代碼常見問題，會議中還可以抽查部分代碼的規(guī)范問題

e) 每周進(jìn)行代碼重構(gòu)，如沒有進(jìn)行，要說明原因(填寫在技術(shù)評審報(bào)告中)

f) 每周提交一個(gè)技術(shù)評審報(bào)告

g) 代碼走查委員會每月舉行一次總結(jié)會議

5.13 建立配置庫

配置管理是軟件開發(fā)的最重要的基礎(chǔ)。配置庫在項(xiàng)目啟動會議前建立，目錄結(jié)構(gòu)參見\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\stadard\配置庫目錄結(jié)構(gòu).rar。

其中，配置庫存放軟件開發(fā)整個(gè)生命周期中的所有軟件工作產(chǎn)品及軟件產(chǎn)品。在項(xiàng)目開發(fā)的每個(gè)迭代周期完成之后，將該迭代周期內(nèi)的所有完成評審的文檔及相對穩(wěn)定不變的代碼進(jìn)行受控，在配置庫中對其文件或目錄進(jìn)行權(quán)限控制。

在每個(gè)迭代周期完成之后，建立一個(gè)產(chǎn)品基線。其中的源代碼必須能夠正常編譯、打包、發(fā)布、單元測試及運(yùn)行。產(chǎn)品基線分為外部產(chǎn)品發(fā)布基線和內(nèi)部發(fā)布基線，在需要向客戶發(fā)布系統(tǒng)時(shí)，必須建立外部產(chǎn)品發(fā)布基線，否則建立內(nèi)部發(fā)布基線?；€標(biāo)識請參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\stadard\項(xiàng)目工作產(chǎn)品命名方法

每個(gè)項(xiàng)目組都必須使用StarTeam來建立配置庫。配置庫必須統(tǒng)一目錄結(jié)構(gòu)和物理存放位置。配置庫由配置管理員負(fù)責(zé)管理，或者項(xiàng)目經(jīng)理充當(dāng)配置管理員角色。開發(fā)人員只有在提交變更申請單后才被授權(quán)check out配置庫中已受控相關(guān)配置項(xiàng)，修改提交后由配置管理員收回相應(yīng)的check in權(quán)限。

通過配置項(xiàng)審計(jì)和基線審計(jì)，能夠避免代碼和文檔丟失，確保配置項(xiàng)的安全。

質(zhì)量管理部門將定期審計(jì)各個(gè)項(xiàng)目組的在配置管理方面的執(zhí)行情況。具體的目錄結(jié)構(gòu)請參見：

\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\stadard\項(xiàng)目文件架構(gòu)

具體的配置項(xiàng)標(biāo)識規(guī)則請參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\standard\項(xiàng)目工作產(chǎn)品命名方法

由公司的專門負(fù)責(zé)人對所有配置庫進(jìn)行備份。具體方法請參見：\軟件過程改進(jìn)\standard regulation \org level\公司備份制度

項(xiàng)目結(jié)束時(shí)，項(xiàng)目組必須把通過驗(yàn)收的產(chǎn)品基線(包括文檔、代碼、重用庫組件源代碼)刻盤備份

5.14 變更控制

每個(gè)項(xiàng)目組都必須建立變更控制委員會(SCCB)，即使該項(xiàng)目組只有2-3人，必須有各方代表組成，包括項(xiàng)目經(jīng)理、開發(fā)人員、測試人員、設(shè)計(jì)人員、質(zhì)量保證人員。

SCCB通常進(jìn)行變更分析，評估進(jìn)行變更的風(fēng)險(xiǎn)、工作量、影響的配置項(xiàng)等，根據(jù)評估結(jié)果接受或者拒絕變更。SCCB還能夠把一些相關(guān)的細(xì)小變更打包給開發(fā)人員，而不是讓開發(fā)人員處理一連串不協(xié)調(diào)的細(xì)小變更。

需要修改已經(jīng)受控的配置項(xiàng)，必須按照變更控制規(guī)程執(zhí)行。具體如下：

變更可能來自項(xiàng)目組內(nèi)部（例如系統(tǒng)測試）或者客戶，由建議者填寫變更申請單，由項(xiàng)目經(jīng)理初審，工作量小的變更項(xiàng)目經(jīng)理可以直接批準(zhǔn)，否則將提交SCCB評審。

SCCB分析出變更所影響的一系列工作，指定驗(yàn)證者和修改者完成變更的工作。

SCM授權(quán)相關(guān)配置項(xiàng)給修改者。

修改者check-out配置項(xiàng)，執(zhí)行變更，并且進(jìn)行技術(shù)評審或者單元、系統(tǒng)測試，然后將配置項(xiàng)check-in配置庫，SCM收回權(quán)限將配置項(xiàng)受控。

驗(yàn)證者跟蹤時(shí)確認(rèn)文檔經(jīng)過了評審或者代碼經(jīng)過單元、系統(tǒng)測試。

SCM收回相關(guān)配置項(xiàng)的授權(quán)。

SCCB授權(quán)關(guān)閉

具體的變更控制流程如下圖：（請參見變更控制規(guī)程）

變更控制處理流程

項(xiàng)目上線后一個(gè)月集中以會議形式給測試組提交需求變更，更新測試用例。

5.15 組件重用

重用是一個(gè)公司建立常用組件庫的長遠(yuǎn)策略，它使新的程序可以很快的用這些已有的組件來集成。另外將現(xiàn)有程序中的代碼移植到新程序中的方式，也可以作為短期的重用方式。

公司的重用管理小組直接負(fù)責(zé)維護(hù)可重用的組件庫。

在項(xiàng)目開始時(shí)在重用庫中對可重用組件進(jìn)行檢查，尋找到需要的組件。

在項(xiàng)目進(jìn)展中發(fā)現(xiàn)需要創(chuàng)建可重用組件時(shí)，要及時(shí)將創(chuàng)建工作移交給重用管理小組來負(fù)責(zé)或者將項(xiàng)目組自己創(chuàng)建的重用組件交由重用管理小組負(fù)責(zé)管理。

如果在項(xiàng)目進(jìn)展中有修改重用組件的需要或者發(fā)現(xiàn)重用組件存在缺陷，要通過缺陷管理工具（TD）及時(shí)反饋給重用管理小組，項(xiàng)目組無權(quán)直接修改重用組件。

在項(xiàng)目開始時(shí)，技術(shù)研究部必須為項(xiàng)目搭建系統(tǒng)框架，系統(tǒng)框架的內(nèi)容主要有：登錄、系統(tǒng)管理部分、菜單、權(quán)限處理以及一些常用的組件和使用功能：分頁、字典、文檔管理（文件上傳下載）。

5.16 持續(xù)集成

1）項(xiàng)目啟動后項(xiàng)目經(jīng)理確定持續(xù)集成開始時(shí)間，并告訴配置管理員和QA

2）持續(xù)集成采用Ant和CruiseControl工具自動進(jìn)行

3）持續(xù)集成依次完成以下任務(wù)：建數(shù)據(jù)庫表（SQL文件），自動從配置庫獲取源代碼，編譯（類＋JSP），打包，部署(EJB/Action/JSP)

4）從開始時(shí)間起每天進(jìn)行持續(xù)集成

5）配置管理員每天查看持續(xù)集成結(jié)果，若失敗，則查找原因，告知相關(guān)人員修改

6）配置管理員每天把持續(xù)集成情況填寫在工作日志中，如果失敗要記錄失敗的原因

7）至少每周成功一次

5.17 單元測試

1）項(xiàng)目經(jīng)理預(yù)先填寫好待測試的功能名稱在《單元測試記錄表》，記錄表模板參見\軟件過程管理指南(適用于公司所有項(xiàng)目)\lc\template\單元測試記錄表

2）功能開發(fā)完成后，開發(fā)人員向項(xiàng)目經(jīng)理或指定人員演示

3）項(xiàng)目經(jīng)理或指定人員在演示過程中檢查功能、界面(按照界面規(guī)范檢查)、數(shù)據(jù)庫（打開數(shù)據(jù)庫查看數(shù)據(jù)）是否正確

4）在《單元測試記錄表》記錄檢查情況

5）《單元測試記錄表》采用電子文檔，存放于各項(xiàng)目組的配置庫中SEDoc\test\testReport目錄下

6）每周更新《單元測試記錄表》

5.18 啟動測試流程

1）項(xiàng)目組單元測試通過后填寫《系統(tǒng)測試任務(wù)單》，列出該版本修改了哪些特征，或者指明測試的要點(diǎn)

2）項(xiàng)目組向測試人員在測試環(huán)境中演示系統(tǒng)，同時(shí)講解需求、特征的變化

a) 系統(tǒng)第一次提交測試時(shí)，項(xiàng)目組必須先根據(jù)《系統(tǒng)介紹》向測試人員講解，然后演示系統(tǒng)

b) 在以后系統(tǒng)提交測試時(shí)，一般也需要演示，如果項(xiàng)目組與測試人員均認(rèn)為不需要演示，則必須經(jīng)過測試組組長的同意

3）測試人員根據(jù)演示的情況決定是否接受測試

4）如果接受，以后的測試執(zhí)行按照《軟件系統(tǒng)測試規(guī)程》中的相關(guān)規(guī)定進(jìn)行。規(guī)程所在位置：\軟件過程管理指南（適用于公司所有項(xiàng)目）\test\《軟件系統(tǒng)測試規(guī)程》

5）系統(tǒng)上線后半年內(nèi)至少一個(gè)月要提交一次系統(tǒng)測試，從上次測試完成起算

5.19 缺陷管理

每個(gè)項(xiàng)目組都必須使用TestDirector來跟蹤和關(guān)閉缺陷（包括測試和技術(shù)評審發(fā)現(xiàn)的缺陷）。

項(xiàng)目經(jīng)理確定項(xiàng)目組成員名單和相關(guān)權(quán)限，填寫《新建/修改TD庫申請表》并提交給TD管理員，TD管理員建立項(xiàng)目TD庫。申請表參見：\軟件過程管理指南（適用于公司所有項(xiàng)目）\test\template\新建修改TD庫申請表

缺陷管理的具體流程如下圖(以測試為例)：

測試人員將系統(tǒng)測試中得到的缺陷錄入TestDirector，此時(shí)任務(wù)的狀態(tài)為New。

項(xiàng)目經(jīng)理分配具體負(fù)責(zé)人完成修改缺陷的工作，此時(shí)任務(wù)的狀態(tài)為Open。或者拒絕修改，更新狀態(tài)為Rejected，或者暫緩修改缺陷，更新狀態(tài)為暫緩。對于暫緩的缺陷，在項(xiàng)目收尾階段分析、整理后提交到維護(hù)組。

負(fù)責(zé)人判斷待修改的配置項(xiàng)是否受控，如果已受控則進(jìn)入變更控制流程。

負(fù)責(zé)人完成工作后，修改狀態(tài)為Fixed。

最后由測試人員驗(yàn)證缺陷是否可以關(guān)閉，修改狀態(tài)為Closed。如果缺陷仍然存在，那么修改狀態(tài)為Reopen。

有關(guān)活動的描述、缺陷等級、缺陷狀態(tài)請參見：軟件過程管理指南（適用于公司所有項(xiàng)目）\test\《軟件系統(tǒng)測試規(guī)程》

缺陷管理流程

重用庫缺陷處理：各項(xiàng)目組在TD庫里建一個(gè)tr的賬號，把測試發(fā)現(xiàn)的屬于重用庫的缺陷分配給他，然后通知（可口頭或用工作通知的形式，但一定要通知到）重用庫的維護(hù)接口人。

5.20 系統(tǒng)發(fā)布

若是多個(gè)系統(tǒng)(子系統(tǒng))合并后的大系統(tǒng)（如EIS）發(fā)布，發(fā)布的子系統(tǒng)至少有一名熟悉的成員在旁協(xié)助，否則，可以拒絕系統(tǒng)的發(fā)布。

流程如下圖所示：

系統(tǒng)發(fā)布流程圖

1）可選的步驟：拷貝系統(tǒng)日志

2）第一版發(fā)布到正式服務(wù)器上之前，必須進(jìn)行系統(tǒng)測試與性能測試。

3）以后修改版發(fā)布到客戶服務(wù)器之前，如果有數(shù)據(jù)庫結(jié)構(gòu)等可能影響到性能的修改，建議在與客戶服務(wù)器相同(或類似)的環(huán)境下通過性能測試

4）系統(tǒng)發(fā)布前必須由項(xiàng)目經(jīng)理填寫電子的《系統(tǒng)發(fā)布說明》，放入項(xiàng)目配置庫的/SEDoc/deliever/。打印后，簽字，交給配置管理員

5）系統(tǒng)發(fā)布時(shí)，必須備份客戶的數(shù)據(jù)

6）系統(tǒng)發(fā)布根據(jù)《系統(tǒng)發(fā)布操作手冊》進(jìn)行

7）將現(xiàn)場最新版發(fā)布文件(發(fā)布用的代碼、只有表結(jié)構(gòu)的dmp和初始數(shù)據(jù)的sql語句)打包成zip文件，打包文件命名參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\standard\項(xiàng)目工作產(chǎn)品命名方法(comtop-scm-tmp-naming).doc

8）將zip文件存放在專用服務(wù)器，只須保存最近兩次的zip文件

注意：若到客戶現(xiàn)場發(fā)布系統(tǒng)，項(xiàng)目經(jīng)理要檢查是否將修改的文件放入配置庫。

5.21 實(shí)施管理

項(xiàng)目的整個(gè)生命周期可分為三個(gè)階段：項(xiàng)目開發(fā)、項(xiàng)目實(shí)施、項(xiàng)目維護(hù)。

項(xiàng)目開發(fā)就是指系統(tǒng)上線前的階段，過程管理的要求見本節(jié)之前的章節(jié)。

項(xiàng)目實(shí)施是指系統(tǒng)上線后項(xiàng)目組進(jìn)行系統(tǒng)修改、完善的階段。一般在軟件開發(fā)的主進(jìn)度計(jì)劃完成之后進(jìn)入項(xiàng)目實(shí)施階段。

項(xiàng)目維護(hù)是指系統(tǒng)從項(xiàng)目組移交給專人維護(hù)后的階段。

項(xiàng)目實(shí)施階段的實(shí)踐有：實(shí)施型項(xiàng)目月計(jì)劃、實(shí)施型項(xiàng)目月報(bào)、系統(tǒng)發(fā)布說明。

5.21.1 實(shí)施型項(xiàng)目月計(jì)劃

1）每月底前制定下月的月計(jì)劃，Project文件，內(nèi)容有：任務(wù)名稱、工期、開始時(shí)間、完成時(shí)間、前置任務(wù)、資源名稱

2）文件命名參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\stadard\項(xiàng)目工作產(chǎn)品命名方法

3）發(fā)給產(chǎn)品經(jīng)理，由產(chǎn)品經(jīng)理匯總后發(fā)給各領(lǐng)導(dǎo)

4）文件放入項(xiàng)目配置庫/PMdoc/Plan/

5.21.2 實(shí)施型項(xiàng)目月報(bào)

1）每月第一周編寫上月月報(bào)，模板參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\lc\temp\項(xiàng)目月報(bào)

2）文件命名參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\stadard\項(xiàng)目工作產(chǎn)品命名方法

3）發(fā)給產(chǎn)品經(jīng)理，由產(chǎn)品經(jīng)理匯總后發(fā)給各領(lǐng)導(dǎo)

4）文件放入項(xiàng)目配置庫/PMdoc/ProjectReport/

5.21.3 系統(tǒng)發(fā)布說明

1）每次系統(tǒng)發(fā)布前必須由項(xiàng)目經(jīng)理填寫電子的《系統(tǒng)發(fā)布說明》，文檔模板參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\lc\template\系統(tǒng)發(fā)布說明

2）文件命名參見：\軟件過程管理指南(適用于公司所有項(xiàng)目)\scm\stadard\項(xiàng)目工作產(chǎn)品命名方法

3）文件放入項(xiàng)目配置庫/SEdoc/deliever/

4）打印后，簽字，交給配置管理員

5.22 產(chǎn)品與項(xiàng)目管理

本節(jié)的項(xiàng)目是指某個(gè)產(chǎn)品下的項(xiàng)目。

1）配置管理

a) 配置庫：產(chǎn)品配置庫作為主視圖，分出的各個(gè)項(xiàng)目作為子視圖。項(xiàng)目開發(fā)在項(xiàng)目視圖上進(jìn)行，更新不反應(yīng)到產(chǎn)品視圖。產(chǎn)品基線建在產(chǎn)品視圖上，項(xiàng)目的產(chǎn)品基線建立在項(xiàng)目視圖上。

b) 產(chǎn)品變更一定按變更流程進(jìn)行，通過SCCB會議確定。產(chǎn)品變更的來源：測試的缺陷；項(xiàng)目經(jīng)理或成員提出的改進(jìn)項(xiàng)

2）產(chǎn)品經(jīng)理必須參加項(xiàng)目前期的調(diào)研

3）項(xiàng)目的工作任務(wù)書里記錄該項(xiàng)目所來源的產(chǎn)品版本

5.23 客戶問題管理

每個(gè)項(xiàng)目組一定要把客戶問題用電子檔形式記錄下來，具體形式不拘（可以用TD，Starteam，Excel等）。

5.24 軟件質(zhì)量保證

SQA工程師的活動或任務(wù)有以下幾類：

1）參與項(xiàng)目組策劃

a) 指導(dǎo)項(xiàng)目組完成啟動會議前的工作

b) 協(xié)助項(xiàng)目組編寫計(jì)劃、估計(jì)等文檔

c) 協(xié)助項(xiàng)目組確定項(xiàng)目所要遵守的標(biāo)準(zhǔn)、規(guī)范

d) 制定SQA進(jìn)度計(jì)劃

2）評審項(xiàng)目組活動

a) 在項(xiàng)目的整個(gè)生命周期中，SQA工程師對項(xiàng)目組的軟件工程活動、軟件過程活動進(jìn)行評審，驗(yàn)證其與指南、規(guī)范的符合性

b) 評審方法和頻率參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\sqa\軟件過程管理指南所有必備項(xiàng)列表及評審方法

3）審計(jì)項(xiàng)目組工作產(chǎn)品

在項(xiàng)目整個(gè)生命周期中，SQA工程師對項(xiàng)目工作產(chǎn)品（軟件工作產(chǎn)品和軟件產(chǎn)品）進(jìn)行審計(jì)，評估其與適當(dāng)?shù)哪０?、?guī)范的符合性。

4）不符合問題管理

a) 不符合問題：SQA工程師在評審或?qū)徲?jì)過程中發(fā)現(xiàn)的與軟件過程管理指南偏離的問題

b)如果項(xiàng)目組成員發(fā)現(xiàn)有些做法不符合指南和規(guī)程，而又是在特殊情況下需要這么做，要事先跟SQA說明

c) 在評審活動過程中主要從以下幾個(gè)方面判別是否存在不符合問題：活動是否進(jìn)行了（與指南比較），活動是否進(jìn)行得正確（與指南比較），活動是否按照進(jìn)度進(jìn)行（與項(xiàng)目計(jì)劃進(jìn)度比較）

d) 在審計(jì)產(chǎn)品過程中主要以以下幾個(gè)方面判別是否存在不符合問題：是否符合模板，內(nèi)容是否填寫正確與完整，與相關(guān)文檔是否一致

e) 不符合問題偏離程度：High－活動沒有進(jìn)行，工作產(chǎn)品沒有；Medium－活動進(jìn)行得不正確，工作產(chǎn)品的重要內(nèi)容不正確

f) 不符合問題處理流程：

不符合問題處理流程

說明：SQA發(fā)現(xiàn)NC并錄入NC庫后要及時(shí)通知項(xiàng)目經(jīng)理。

g) 不符合問題（NC）關(guān)閉：必須在一周內(nèi)關(guān)閉

5）定期匯報(bào)SQA活動

a) 周報(bào)：周例會上，向項(xiàng)目報(bào)告SQA活動情況，主要說明發(fā)現(xiàn)的不符合問題；每周五將所負(fù)責(zé)項(xiàng)目組的不符合問題報(bào)給高級經(jīng)理和總經(jīng)理，報(bào)告格式參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\sqa\template\SQA報(bào)告模板

b) 月報(bào)：每月最后一天將所負(fù)責(zé)項(xiàng)目一月的不符合問題統(tǒng)計(jì)上報(bào)給高級經(jīng)理和總經(jīng)理，報(bào)告格式參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\sqa\template\SQA報(bào)告模板

c) 階段報(bào)告：項(xiàng)目組里程碑前進(jìn)行質(zhì)量檢查，參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\sqa\template\項(xiàng)目階段質(zhì)量檢查表；并且出質(zhì)量報(bào)告，參見軟件過程改進(jìn)配置庫：\軟件過程管理指南(適用于公司所有項(xiàng)目)\sqa\template\SQA質(zhì)量報(bào)告

6 引用的過程及規(guī)程文件列表

序號

類別

所屬KPA

文件名稱

組織級

SCM

《公司備份制度》

過程

《軟件過程維護(hù)指南》

規(guī)程

《軟件系統(tǒng)測試規(guī)程》

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點(diǎn)擊舉報(bào)。

九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区