軟體評審

軟體評審

在軟體的生命周期內所實施的對軟體本身的評審。 評審本身根據不同的評審階段,分為需求評審,功能評審,質量評審,成本評審,維護評審等。 評審的組織部門通常可以由需求部門,技術部門,質量控制部門,產品部門等。 評審的結果通常根據不同的評審目標形成評審結果。

基本信息

定義

評審是對軟體元素或者項目狀態的一種評估手段,以確定其是否與計畫的結果保持一致,並使其得到改進。

分類

一般來說,評審(Peer Review)包括下面幾種

檢視(Inspection)

團隊評審(Team Review/Technical Review)

走讀(WalkThrough)

成對編程(Pair Programming)

同行檢查(Peer DeskCheck)

特別檢查(Ad hoc Review)

評審方法間的區別(1)

評審方法間的區別(2)

誤區

評審中的誤區(1)

誤區一:評審參與者不了解評審過程

如果評審參與者不了解整個的評審過程,就會有一種自然的抗拒情緒,因為大家看不到做這件事情的效果,感覺到很迷茫,這樣會嚴重的影響大家參與評審的積極性。

評審中的誤區(2)

誤區二:評審人員評論開發人員,而不是產品

評審的主要目的是發現產品中的問題,而不是根據產品來評價開發人員的水平。但是往往會出現把產品質量和開發人員水平聯繫起來的事情,於是評審變了“味”,變成了“批鬥大會”,極大的打擊了開發人員的自尊心,以至嚴重的影響了評審的效果。

評審中的誤區(3)

誤區三:評審沒有被安排進入項目計畫

參與評審需要投入大量的時間和精力,應該被安排進入項目計畫中。但是現實的情況往往是,評審變成了“義務工”,參與評審的人員必須加班加點才能完成評審任務。如此一來,出現評審人員對評審對象不了解的情況也就不足為奇了。

評審中的誤區(4)

誤區四:評審會議變成了問題解決方案討論會

評審會議主要的目的是發現問題,而不是解決問題,問題的解決是評審會議之後需要做的事情。但是,由於開發人員對技術的追求,評審會議往往變成了問題研討會,大量的占用了評審會議的時間,導致大量評審內容被忽略,留下無數的隱患。

評審中的誤區(5)

誤區五:評審人員事先對評審材料沒有足夠了解

任何一份評審材料都是他人智慧和心血的結晶,需要花足夠的時間去了解、熟悉和思考。只有這樣,才能在評審會議上發現有價值的深層次問題。在很多的評審中,評審人員因為各種的原因,在評審會議之前對評審材料沒有足夠的了解,於是出現了評審會議變成了技術報告的怪現象。

評審中的誤區(6)

誤區六:評審人員關注於非實質性問題

經常會出現這樣的問題,在評審中,評審人員過多的關注於一些非實質性的問題,比如文檔的格式,措詞,而不是產品的設計。出現這樣的情況,可能的原因有:沒有選擇合適的人參加評審;評審人員對評審對象沒有足夠的了解,無法發現深層次的問題。

評審中的誤區(7)

誤區七:忽視細節

在組織評審的過程中,很多人不太注意細節。比如會議時間的設定,會議的通知,會議場所的選擇,會場環境的布置,會議設施的提供,會議上氣氛的調節和控制等等,而實際上這樣的細節會大大影響評審會議的效果。比如,很難想像,大家在一個空氣混濁、噪音很大的會議室裡面能夠全身心的投入。

相關詞條

相關搜尋

熱門詞條

聯絡我們