檢查問題報(bào)告

開篇：寫作不僅是一種記錄，更是一種創(chuàng)造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇檢查問題報(bào)告，希望這些內(nèi)容能成為您創(chuàng)作過程中的良師益友，陪伴您不斷探索和進(jìn)步。

第1篇

關(guān)鍵詞：軟件代碼審查；代碼審查過程；代碼審查問題

中圖分類號(hào)：TP311.52文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1007-9599 (2012) 03-0000-02

Discussion on the Code Review of Software Static Testing

Yuan Zhengjiang

(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)

Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.

Keywords:Software code review;Code review process;Code review problem

一、引言

軟件測(cè)試常用方法可分為動(dòng)態(tài)測(cè)試和靜態(tài)測(cè)試，只有動(dòng)態(tài)測(cè)試和靜態(tài)測(cè)試有效結(jié)合，才能更好的完成軟件測(cè)試工作。代碼審查是軟件靜態(tài)測(cè)試中常用的軟件測(cè)試方法之一，代碼審查時(shí)，只要測(cè)試人員方法得當(dāng)、足夠細(xì)心，往往能夠產(chǎn)生意想不到的效果。

二、代碼審查的作用

代碼審查是在不執(zhí)行軟件的條件下有條理的仔細(xì)審查軟件代碼，從而找出軟件缺陷的過程。

代碼審查可以找出動(dòng)態(tài)測(cè)試難以發(fā)現(xiàn)或隔離的軟件缺陷。在開發(fā)過程初期讓測(cè)試人員集中精力進(jìn)行軟件代碼審查非常有價(jià)值：可以提高代碼質(zhì)量；在項(xiàng)目的早期發(fā)現(xiàn)缺陷，將損失降至最低；促進(jìn)團(tuán)隊(duì)溝通、促進(jìn)知識(shí)共享、共同提高。

代碼審查還可以為動(dòng)態(tài)測(cè)試時(shí)設(shè)計(jì)和執(zhí)行測(cè)試用例提供思路。通過代碼審查，可以確定有問題或者容易產(chǎn)生軟件缺陷的特性范圍。

三、代碼審查的過程

代碼審查過程可分為：代碼審查策劃階段、代碼審查實(shí)施階段以及代碼審查總結(jié)階段。

（一）代碼審查策劃階段

1.項(xiàng)目負(fù)責(zé)人分配代碼審查任務(wù)；

2.確定代碼審查策略：依據(jù)軟件開發(fā)文檔，確定軟件關(guān)鍵模塊，作為代碼審點(diǎn)；將復(fù)雜度高的模塊也作為代碼審查的重點(diǎn)；

3.項(xiàng)目負(fù)責(zé)人確定代碼審查單，審查內(nèi)容一般可包括：

（1）可追溯性：

――代碼是否遵循詳細(xì)設(shè)計(jì)？

――代碼是否與需求一致？

（2）邏輯：

――表示優(yōu)先級(jí)的括號(hào)用法是否正確？

――代碼是否依賴賦值順序？

――“if…else”和“switch”使用是否正確清晰？

――循環(huán)能否結(jié)束？

――復(fù)合語句是否正確地被花括號(hào)括起來？

――case語句是否所有可能出現(xiàn)的情況均已考慮？

――“goto”是否使用？

（3）數(shù)據(jù)：

――變量在使用前是否已初始化？

――變量的聲明是否按組劃分為外部的和內(nèi)部的？

――除最明顯的聲明外，是否所有聲明都有注釋？

――每個(gè)命名是否僅用于一個(gè)用途？

――常量名是否都大寫？

――常量是否都是通過“#define”定義的？

――用于多個(gè)文件中的常量是否在一個(gè)頭文件中定義？

――頭文件中是否存在可執(zhí)行的代碼？

――定義為指針的變量是否作為指針使用（而不是作為整數(shù)）？

――指針是否初始化？

――釋放內(nèi)存后是否將指針立即設(shè)置為NULL（或0）？

――傳遞指針到另一個(gè)函數(shù)的代碼是否首先檢查了指針的有效性？

――通過指針寫入動(dòng)態(tài)分配內(nèi)存的代碼是否首先檢查了指針的有效性？

――宏的命名是否都大寫？

――數(shù)組是否越界？

（4）接口：

――在所有的函數(shù)及過程調(diào)用中，參數(shù)的個(gè)數(shù)都正確嗎？

――形參與實(shí)參類型匹配嗎？

――參數(shù)順序正確嗎？

――如果訪問共享內(nèi)存，是否具有相同的共享內(nèi)存結(jié)構(gòu)模式？

（5）文檔：

――軟件文檔是否與代碼一致？

（6）注釋：

――注釋與代碼是否一致？

――用于理解代碼的注釋是否提供了必要的信息？

――是否對(duì)數(shù)組和變量的作用進(jìn)行了描述？

（7）異常處理：

――是否所有可能的錯(cuò)誤都已加以考慮？

（8）內(nèi)存：

――在向動(dòng)態(tài)分配的內(nèi)存寫入之前是否檢查了內(nèi)存申請(qǐng)是否成功？

――若采用動(dòng)態(tài)分配內(nèi)存，內(nèi)存空間分配是否正確？

――當(dāng)內(nèi)存空間不再需要時(shí)，是否被明確的釋放？

（9）其它：

――是否檢查了函數(shù)調(diào)用返回值？

――所有的輸入變量都用到了嗎？

――所有的輸出變量在輸出前都已賦值了嗎？

4.確定代碼審查進(jìn)度安排，項(xiàng)目負(fù)責(zé)人負(fù)責(zé)安排代碼審查的進(jìn)度。

（二）代碼審查實(shí)施階段

1.代碼講解：軟件開發(fā)人員詳細(xì)向測(cè)試人員講解如何以及為何這樣實(shí)現(xiàn)，測(cè)試人員提出問題和建議。通過代碼講解，測(cè)試人員對(duì)被審查的軟件有了一個(gè)全面的認(rèn)識(shí)，為后續(xù)代碼審查打下良好的基礎(chǔ)。

2.靜態(tài)分析：一般采用靜態(tài)分析工具進(jìn)行，主要分析軟件的代碼規(guī)模、模塊數(shù)、模塊調(diào)用關(guān)系、扇入、扇出、圈復(fù)雜度、注釋率等軟件質(zhì)量度量元。靜態(tài)分析在代碼審查時(shí)應(yīng)優(yōu)先進(jìn)行，有利于軟件測(cè)試人員在后續(xù)代碼審查時(shí)對(duì)軟件建立宏觀上認(rèn)識(shí)，在審查中容易做到有的放矢，更易于發(fā)現(xiàn)軟件代碼中的缺陷。

3.規(guī)則檢查：采用靜態(tài)分析工具對(duì)源程序進(jìn)行編碼規(guī)則檢查，對(duì)于工具報(bào)出的問題再由人工進(jìn)行進(jìn)一步的分析以確認(rèn)軟件問題，是一種比較有效的方法。

4.正式代碼審查：代碼審查可分兩步進(jìn)行：獨(dú)立審查和會(huì)議審查。根據(jù)情況，這兩步可以反復(fù)進(jìn)行多次。

（1）獨(dú)立審查：測(cè)試人員根據(jù)項(xiàng)目負(fù)責(zé)人的工作分配，獨(dú)自對(duì)自己負(fù)責(zé)的軟件模塊進(jìn)行代碼審查。測(cè)試人員根據(jù)代碼審查單，對(duì)相關(guān)代碼進(jìn)行閱讀、理解和分析后，記錄發(fā)現(xiàn)的錯(cuò)誤和疑問。

（2）會(huì)議審查：項(xiàng)目負(fù)責(zé)人主持召開會(huì)議，測(cè)試人員和開發(fā)人員參加；測(cè)試人員就獨(dú)立審查發(fā)現(xiàn)的問題和疑問與開發(fā)人員溝通，并討論形成一致意見；對(duì)發(fā)現(xiàn)的問題匯總，填寫軟件問題報(bào)告單，提交開發(fā)人員處理。

5.更改確認(rèn)：開發(fā)人員對(duì)問題進(jìn)行處理，代碼審查人員對(duì)軟件的處理情況進(jìn)行確認(rèn)，驗(yàn)證更改的正確性，并防止出現(xiàn)新的問題。

（三）代碼審查總結(jié)階段

代碼審查工作結(jié)束后，項(xiàng)目負(fù)責(zé)人總結(jié)代碼審查結(jié)果；編寫測(cè)試報(bào)告，對(duì)軟件代碼質(zhì)量進(jìn)行評(píng)估，給出合理建議。

把代碼審查提出的所有問題、亮點(diǎn)及最終結(jié)論詳細(xì)的記錄下來，供其他軟件項(xiàng)目代碼審查借鑒。必要時(shí)，可建立常見軟件代碼缺陷數(shù)據(jù)庫，為軟件代碼審查人員培訓(xùn)和執(zhí)行代碼審查提供數(shù)據(jù)支持，也可以為軟件編碼規(guī)則制定規(guī)范提供實(shí)踐依據(jù)。

四、代碼審查中的常見問題

如果軟件測(cè)試人員熟悉常見的軟件代碼審查問題，對(duì)代碼審查效率是很有幫助的。筆者根據(jù)自己的應(yīng)驗(yàn)，列舉部分常見軟件代碼審查問題如下（僅供參考）：

（1）浮點(diǎn)數(shù)相等比較：可能造成程序未按設(shè)計(jì)的路徑執(zhí)行；

（2）因設(shè)計(jì)原因?qū)е履承┐a不能執(zhí)行：如邏輯表達(dá)式永遠(yuǎn)為真（或假）造成某分支不能執(zhí)行、代碼前面有return語句、某模塊從未被調(diào)用等；

（3）switch語句沒有break語句（有意如此設(shè)計(jì)時(shí)除外）；

（4）數(shù)組越界使用：數(shù)組越界容易發(fā)生在數(shù)組下標(biāo)是計(jì)算得到的情況下，而且審查時(shí)很難發(fā)現(xiàn)這種代碼缺陷，應(yīng)加以重視；

（5）變量未初始化就使用或者是條件賦值就使用；

（6）程序中存在未使用的多余變量；

（7）復(fù)合邏輯表達(dá)式?jīng)]有使用括號(hào)造成運(yùn)算順序錯(cuò)誤；

（8）有返回值的函數(shù)中return沒有帶返回值；

（9）邏輯判別的表達(dá)式不是邏輯表達(dá)式；

（10）動(dòng)態(tài)分配的內(nèi)存沒有及時(shí)釋放：忘記寫內(nèi)存釋放代碼或由于其它邏輯缺陷導(dǎo)致內(nèi)存釋放代碼未得到執(zhí)行；

（11）沒有對(duì)緩沖區(qū)溢出進(jìn)行必要的防護(hù)；

（12）訪問空指針，即指針未初始化就使用；

（13）指針指向的內(nèi)存釋放后，未將指針置為NULL：其它函數(shù)訪問該指針時(shí)，判斷指針不為空，當(dāng)作有效指針使用，會(huì)造成內(nèi)存訪問錯(cuò)誤；

（14）注釋說明與程序代碼實(shí)現(xiàn)不一致，甚至相反；

（15）循環(huán)存在不能跳出的可能，程序中沒有相應(yīng)的保護(hù)機(jī)制。

五、結(jié)束語

第2篇

[關(guān)鍵詞]項(xiàng)目管理軟件需求開發(fā)進(jìn)度成本質(zhì)量管理模型

一、引言

軟件需求開發(fā)是軟件工程的一個(gè)重要環(huán)節(jié)，在軟件生命周期中的需求、設(shè)計(jì)、編碼、測(cè)試和維護(hù)等各個(gè)階段中，需求開發(fā)處于軟件工程的開始部分，它提供構(gòu)建軟件項(xiàng)目的根基，決定軟件開發(fā)成果滿足客戶需求的匹配程度。軟件需求開發(fā)環(huán)節(jié)的失誤會(huì)隨著開發(fā)進(jìn)度的擴(kuò)大而蔓延，資料表明，軟件項(xiàng)目中由于需求開發(fā)管理混亂而造成的返工開銷幾乎占了總開發(fā)的50％。本文應(yīng)用項(xiàng)目管理理論分析軟件需求開發(fā)階段的系統(tǒng)構(gòu)成，并設(shè)計(jì)管理模型來提高軟件需求開發(fā)的管理效率。

二、軟件需求開發(fā)管理過程

由于計(jì)算機(jī)技術(shù)的迅速發(fā)展，使得軟件需求具有模糊性、不確定性、變化性、主觀性等特點(diǎn)，并帶來軟件需求開發(fā)管理的復(fù)雜性。軟件需求開發(fā)是一定的組織利用有限的資源在規(guī)定的時(shí)間內(nèi)完成，可以作為項(xiàng)目來進(jìn)行管理，其管理過程由需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗(yàn)證四個(gè)階段構(gòu)成。

1.需求獲取

需求獲取是在問題和最終解決方案之間架設(shè)橋梁，其主要任務(wù)是和用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員進(jìn)行溝通，獲取用戶的具體需求，并了解用戶的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等具體情況，同用戶建立起良好的溝通渠道和方式。軟件需求獲取的方法有：與用戶交談，向用戶提問題；參觀用戶的工作流程，觀察用戶的操作；用戶工作的情景分析；現(xiàn)有系統(tǒng)的問題報(bào)告和改進(jìn)要求，事件和響應(yīng)；市場(chǎng)調(diào)查和向用戶群體發(fā)調(diào)查問卷；與同行、專家交談，聽取他們的意見；分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求；從現(xiàn)有產(chǎn)品或競(jìng)爭(zhēng)產(chǎn)品的文檔中提取需求；從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求；從Internet上搜查相關(guān)資料等。

2.需求分析

需求分析主要通過建立業(yè)務(wù)模型的方式來描述用戶的功能需求，為客戶、用戶、開發(fā)方等不同參與者提供一個(gè)交流的渠道。業(yè)務(wù)模型可以映射出軟件產(chǎn)品的核心需求，即功能需求。功能需求應(yīng)描述軟件提供的功能和服務(wù)、對(duì)輸入的響應(yīng)，并描述特定條件下的系統(tǒng)構(gòu)成等。軟件產(chǎn)品本身可能還存在與業(yè)務(wù)無直接關(guān)系的非功能需求，具體與系統(tǒng)的總體特性有關(guān)，如可靠性、響應(yīng)時(shí)間、存儲(chǔ)空間等。非功能需求定義系統(tǒng)提供服務(wù)或功能的約束，包括時(shí)間約束、空間約束、開發(fā)過程約束及應(yīng)遵循的標(biāo)準(zhǔn)等。通常這兩類需求構(gòu)成軟件需求的總集。

3.編制軟件需求規(guī)格

軟件需求規(guī)格的編制是為了使用戶和軟件開發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)，需求分析完成的標(biāo)志就是提交一份完整的軟件需求規(guī)格說明書。軟件需求規(guī)格說明書以一種開發(fā)人員可用的技術(shù)形式闡述軟件必須提供的功能和具備的性能，以及必須考慮的限制條件。軟件項(xiàng)目客戶通過軟件需求規(guī)格了解軟件項(xiàng)目能夠提供的軟件產(chǎn)品，檢查軟件需求是否滿足需要；項(xiàng)目管理人員根據(jù)軟件需求規(guī)格制定項(xiàng)目的開發(fā)計(jì)劃和管理過程；軟件開發(fā)人員通過軟件需求規(guī)格理解要開發(fā)的產(chǎn)品及具體要開發(fā)的內(nèi)容；軟件測(cè)試人員通過軟件需求規(guī)格驗(yàn)證軟件。

4.需求評(píng)審

編寫的軟件需求規(guī)格說明書還應(yīng)當(dāng)進(jìn)行需求評(píng)審，確保需求確定的科學(xué)性。可采用下列指標(biāo)進(jìn)行評(píng)審：(1)正確性:每條需求都正確代表構(gòu)建軟件系統(tǒng)所要完成的事情。(2)無歧義:每條需求只有一種解釋。(3)完備性:需求不能發(fā)生遺漏，應(yīng)全面考慮相關(guān)問題。(4)一致性:用戶需求必須和業(yè)務(wù)需求一致，功能需求必須和用戶需求一致。(5)重要性和穩(wěn)定性分級(jí):現(xiàn)有資源不足以實(shí)現(xiàn)所有需求時(shí)，可以根據(jù)級(jí)別的高低決定實(shí)現(xiàn)的先后，舍棄一些級(jí)別低的需求以保證項(xiàng)目的按期交付。(6)可驗(yàn)證性:需求分析是可測(cè)試的，只有系統(tǒng)的所有需求都是可以被測(cè)試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統(tǒng)是成功的。(7)可修改性:每一條需求都易于完整一致的進(jìn)行變更，且不改變需求集的結(jié)構(gòu)和風(fēng)格。(8)可跟蹤性:每條需求都是可溯源的，且存在一種機(jī)制使得在以后的工作中引用需求是可行的。(9)可理解性:用戶和開發(fā)人員都完全理解需求集的整體行為、所提供的功能及其中的每條需求的含義。

三、軟件需求開發(fā)管理模型

1.軟件需求開發(fā)管理模型構(gòu)建原則

軟件需求開發(fā)是一項(xiàng)復(fù)雜的系統(tǒng)工程，管理模型的構(gòu)建應(yīng)遵循下列原則:(1)程序性原則：軟件需求開發(fā)管理應(yīng)遵循固定的業(yè)務(wù)流程，可將其劃分為需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗(yàn)證四個(gè)階段，前一階段的工作完成后才能進(jìn)入下一階段。(2)系統(tǒng)性原則：軟件需求開發(fā)要在限定的時(shí)間、成本條件約束下達(dá)到一定的質(zhì)量，實(shí)現(xiàn)軟件系統(tǒng)的最優(yōu)，要求管理遵循系統(tǒng)管理原則，實(shí)現(xiàn)目標(biāo)最優(yōu)。(3)簡(jiǎn)化性原則：化繁為簡(jiǎn)，將模糊的、潛在的復(fù)雜問題明確化，以圖表的形式表示出，并以簡(jiǎn)化的解決方案解決問題，便于項(xiàng)目管理。(4)平衡性原則：管理軟件需求開發(fā)的具體事務(wù)要有一定的側(cè)重。對(duì)于需求開發(fā)過程事項(xiàng)，應(yīng)根據(jù)影響大小分清主次，關(guān)鍵的事項(xiàng)或者事項(xiàng)里的某個(gè)多發(fā)問題點(diǎn)，著重管理，達(dá)到在管理上的主次平衡。(5)高效性原則:模型的設(shè)計(jì)必須以促進(jìn)需求開發(fā)目標(biāo)的實(shí)現(xiàn)為前提，提供給相關(guān)人員一個(gè)展示需求開發(fā)管理和有效解決方案的平臺(tái)。（6）時(shí)時(shí)控制性原則:及時(shí)控制需求開發(fā)過程中影響進(jìn)度、成本、質(zhì)量等問題，及時(shí)發(fā)現(xiàn)解決沖突事件，做到事前、事中、事后控制，保證項(xiàng)目按時(shí)保質(zhì)保量完成。(7)動(dòng)態(tài)性原則:開發(fā)中應(yīng)關(guān)注信息技術(shù)的發(fā)展，將先進(jìn)的技術(shù)應(yīng)用到軟件需求開發(fā)中，并學(xué)習(xí)借鑒相關(guān)軟件需求開發(fā)的成果。

2．軟件需求開發(fā)管理模型

基于以上分析，本文構(gòu)建了軟件需求開發(fā)管理模型，見下圖：

該模型遵循了軟件需求開發(fā)的管理流程。啟動(dòng)階段，軟件開發(fā)進(jìn)行了可行性研究，軟件項(xiàng)目已立項(xiàng)，項(xiàng)目正式啟動(dòng)。軟件需求開發(fā)管理階段是模型的主要部分，按照項(xiàng)目流程，依次劃分為需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗(yàn)證四個(gè)階段。總結(jié)階段，對(duì)軟件需求開發(fā)管理進(jìn)行總結(jié)，并進(jìn)入到軟件程序設(shè)計(jì)階段。模型的核心部分是應(yīng)用項(xiàng)目管理的進(jìn)度管理、成本管理、質(zhì)量管理，對(duì)軟件需求開發(fā)進(jìn)行動(dòng)態(tài)管理。進(jìn)度管理就是制定出經(jīng)濟(jì)合理的進(jìn)度計(jì)劃，然后在計(jì)劃執(zhí)行過程中，檢查實(shí)際進(jìn)度與計(jì)劃進(jìn)度之間的差異，并及時(shí)找出出現(xiàn)差異的原因，采取有效的補(bǔ)救措施，以確保項(xiàng)目按時(shí)按質(zhì)完成。進(jìn)度管理應(yīng)加強(qiáng)溝通，掌握可能延誤進(jìn)度的環(huán)節(jié)，并嚴(yán)格控制進(jìn)度變更。成本管理就是對(duì)項(xiàng)目所需的成本情況進(jìn)行詳細(xì)地分析和估算，編制資源需求計(jì)劃，并編制項(xiàng)目所需的成本估算和預(yù)算，在執(zhí)行過程中，采取相應(yīng)的措施對(duì)項(xiàng)目成本進(jìn)行控制。成本管理應(yīng)嚴(yán)格控制加班、浪費(fèi)等額外支出。質(zhì)量管理是為了保證項(xiàng)目的可交付成果能夠滿足客戶的需求，圍繞項(xiàng)目質(zhì)量而進(jìn)行的計(jì)劃、協(xié)調(diào)和控制等活動(dòng)，其具體內(nèi)容涉及質(zhì)量規(guī)劃、實(shí)施質(zhì)量保證和質(zhì)量控制。通過進(jìn)度管理、成本管理和質(zhì)量管理，使軟件需求開發(fā)成為進(jìn)度快、成本低和質(zhì)量合格的有機(jī)統(tǒng)一體。

該模型規(guī)范了軟件需求開發(fā)的業(yè)務(wù)流程，并在整個(gè)軟件需求開發(fā)的不同環(huán)節(jié)之間建立聯(lián)系，明確需求開發(fā)過程與自身各任務(wù)項(xiàng)之間以及項(xiàng)目其余環(huán)節(jié)所存在的各種聯(lián)系。模型各環(huán)節(jié)間的相關(guān)性、可追溯性保證了軟件項(xiàng)目需求開發(fā)過程，可以遵循統(tǒng)一的管理模式。該模型具備可配置性。每個(gè)軟件項(xiàng)目，都具有個(gè)性化管理需求，在進(jìn)度管理、成本管理、質(zhì)量管理等方面有不同的要求，可以針對(duì)具體的開發(fā)團(tuán)隊(duì)，項(xiàng)目要求，管理側(cè)重點(diǎn)，擴(kuò)增相應(yīng)的管理模塊，將此模型推廣到任何一個(gè)軟件需求開發(fā)項(xiàng)目。

3.模型應(yīng)用

由于軟件需求開發(fā)具有復(fù)雜性，其主要表現(xiàn)為需求描述問題，明確表達(dá)需求較難確定，并且難以統(tǒng)一；需求完備問題，需求沒有遺漏，難以準(zhǔn)確劃定系統(tǒng)范圍；需求的變更問題，需求變化是永恒，需求不可能是完備。模型應(yīng)用需做好以下工作：（1）文檔化管理。需求必須有文檔來記錄，該文檔必須是正確的，是經(jīng)過驗(yàn)證的，是在受控的狀態(tài)下變更的。開發(fā)或管理人員常常會(huì)在含糊的情況下把認(rèn)為是相對(duì)簡(jiǎn)單的需求忽視而省略文檔記錄，其實(shí)未必簡(jiǎn)單，只有想清楚、寫清楚、說清楚才說明已經(jīng)真正把需求整理清楚了，同時(shí)方便日后維護(hù)工作的展開。需求含糊的情況下要進(jìn)行會(huì)議形式處理，并邀請(qǐng)相關(guān)人員參加進(jìn)行需求澄清及確定，需求在進(jìn)行多方確定后進(jìn)行歸檔。同時(shí)軟件需求的復(fù)用率也是相當(dāng)高的，可以避免升級(jí)時(shí)重新將需求再次獲取，只需要在原來的基礎(chǔ)上作為文擋需求復(fù)用升級(jí)處理。（2）審核評(píng)估需求變更，減少變更的影響。在管理軟件開發(fā)過程中，需求漸變是必然的，無論需求變化的程度如何，只要需求變更就必須進(jìn)行評(píng)估。在需求變更之前必須由項(xiàng)目管理人員審核，再傳給開發(fā)人員進(jìn)行評(píng)估等工作。管理人員必需依據(jù)對(duì)整套系統(tǒng)的了解程度分析需求變更過程中可能受影響的系統(tǒng)及受關(guān)聯(lián)的功能模塊，并制定積極應(yīng)對(duì)措施。(3)整體管理。應(yīng)識(shí)別、確定、結(jié)合、統(tǒng)一與協(xié)調(diào)軟件需求開發(fā)管理過程中所需要進(jìn)行的各種過程和活動(dòng)，保證進(jìn)度、成本、質(zhì)量等各要素的相互協(xié)調(diào)。

四、結(jié)語

軟件需求開發(fā)在軟件項(xiàng)目管理中具有重要地位。本文應(yīng)用項(xiàng)目管理理論，設(shè)計(jì)了軟件需求開發(fā)管理模型。該模型遵循項(xiàng)目管理流程，將軟件需求開發(fā)劃分啟動(dòng)、需求開發(fā)過程、總結(jié)三個(gè)階段，并將軟件需求開發(fā)過程劃分為需求獲取、需求分析、編寫軟件需求規(guī)格和需求驗(yàn)證四個(gè)階段，模型應(yīng)用項(xiàng)目管理的進(jìn)度管理、成本管理、質(zhì)量管理，對(duì)軟件需求開發(fā)進(jìn)行動(dòng)態(tài)管理，實(shí)現(xiàn)軟件需求開發(fā)項(xiàng)目目標(biāo)最優(yōu)。該模型能夠提高軟件需求開發(fā)管理效率，確保軟件開發(fā)能夠按進(jìn)度，低成本，高質(zhì)量地完成。

參考文獻(xiàn)：

[1]景慎艷:軟件項(xiàng)目需求管理的探索與實(shí)踐[J].電腦知識(shí)與技術(shù)，2008（27）

[2]左懷遠(yuǎn):軟件項(xiàng)目中的風(fēng)險(xiǎn)管理研究[J].世界科技研究與發(fā)展，2008（3）

[3]孫琦龍:加強(qiáng)軟件項(xiàng)目管理的實(shí)踐模式[J].科技信息，2008（7）