作業: 評定及倡導品質
這項作業專注於支援識別品質差異、評估品質差異的影響及風險,以及尋找有效的解決方案等整體性努力。
目的

這項作業的目的如下:

  • 指出及支持對軟體品質具有嚴重不利影響的問題之解決方案
  • 監視進度以及支援適當進行變更,將軟體品質提高到必要的層次
  • 針對問題提供適時的解決方案,以防止或影響測試工作
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
檢查最新的「測試評估摘要」
目的:  瞭解測試小組提出的最新產品品質問題摘要評量。 

從檢查測試小組準備好的「測試評估摘要」開始著手。將評估資訊和反覆的「測試計劃」做比較,以瞭解已規劃的工作之基礎摘要。向提供摘要的測試小組成員提出任何不明確和顧慮之處。

在這個步驟以及後續的步驟都是和收集資訊以及評估軟體品質相關,因此要盡量在使用客觀和主觀的檢測方法上,達到平衡。請記得,目標數目只能提供整個圖片的一部分,並且必須能用目前的專案「氣候」支持及解釋。另外,在軟體品質方面,不要完全依賴道聽途說以及主觀的猜測:要找出可以證實的客觀證明。我們建議您要透過和小組負責人,或如果可能的話,和各個小組成員進行討論來收集主觀的評定,以補充您的客觀資料,並拿捏客觀資料的可信程度。

檢查選擇的「測試結果」,取得額外的環境定義
目的:  對支持最新的產品品質彙集評估之「測試結果」,取得進一步瞭解。 

依據「測試評估彙總」,檢查選擇的「測試結果」,以取得額外的環境定義。深入研究測試結果,確定您確實瞭解「測試評估彙總」中指出的重要問題。

同時您也要親自審查資料,看看「測試結果」資料是否有遺漏的重要趨勢證明。一般而言,找出資料中顯示的相對趨勢,要比查看絕對數字重要得多。要注意看諸如因為某個區域的失敗,而導致其他區域也失敗所代表的徵候。

檢查主要變更要求
目的:  取得背景資訊,以便能有效地討論最重要的未解決問題以及問題的可能解決方案。 

我們建議您要將這個練習限定為最急迫的問題以及相關聯的變更要求。如此您就可以集中注意力於較少數的問題,而這些問題通常對產品品質具有最重要的影響。如果您的主要問題很多,我們建議您依據問題的相對優先順序來分配適當的注意力:不要將資源浪費在最不重要的問題上。不過,要注意大量的未完成低優先順序變更要求,對產品品質的影響,也會和少量的高優先順序變更具有同等重要的影響。請嘗試將低優先順序變更要求依據其對品質所代表的風險,將變更要求區分為邏輯的品質因素群組。如此可以協助您更清楚地表示以及提出那些變更要求對品質形成的合併效果。

在一般變更要求資料中,指出重要的趨勢證明。一般而言,找出資料中顯示的相對趨勢,要比查看絕對數字重要得多。尋找正面的徵候,例如在一段時間內,問題解決速度穩定且連續,或解決速度慢慢不斷增加,然後隨著減少。注意問題解決速度中的突發尖峰與凹槽,這些是表示開發小組可能是遇到 程序、環境、政治或其他方面的問題,導致他們的生產力降低。

注意:您也可能要趁機改進相關的變更要求清析度,釐清語義不明確以及感受性的語言和推論等。如果您是自己做這些變更,請和原來建立這些工作成果的人員討論您的改進之處,讓他們瞭解您做改進的重要性。

指出品質差異及評定相關聯的影響和風險
目的:  以主要問題對產品品質所代表的風險,以及對成功開發軟體專案所造成的相關聯風險形式,來明確陳述您對主要問題的瞭解。 

指出每一個品質差異,並評定導致品質差異的每個問題所會產生的相關聯影響和風險。考慮舒緩和臨時策略,明確陳述您對這些事情的起始創意,並和其他小組成員討論。

想想「完美」品質其實是很虛構的概念。在評估品質及指出品質差異時,注意要使用實際且能做到的「品質條圖」來表示。請參閱技術:產品品質

指出解決品質差異的必要動作
目的:  產生一份實在的小型必要動作清單,來協議主要問題的滿意解決方案。 

對於品質差異中的每一個主要間隙,考慮可能的舒緩及臨時策略。明確陳述您對這些事情的起始創意,並和其他小組成員進行非正式的討論,以取得進一步的內視並驗證您的想法。在解決方案方面,最好有幾個選擇:這種方式可以讓您權衡利弊得失,並採用對給定的環境定義最適合的解決方案。

擬定一套有用的候選解決方案和建議,來協助專案小組適當地解決每個品質間隙。這是很重要的動作,因為這項努力會被視為對解決問題很有貢獻,而不只是報告問題而已。這對指出測試小組的貢獻價值,以及獲得其他小組成員的尊重和合作是很重要的因素。

指出並參與主要的問題處理
目的:  非正式地收集對解決主要問題的支援,並有助於瞭解什麼樣的提案較可能被接受。 

支持沒有希望的事情並沒有意義。指出專案小組較可能同意、接受以及願意達成的問題解決方案,通常是比較有效益的方法。和主要的決策者維持緊密的聯繫,並考慮開始在一對一的討論中,非正式地提出這些主要問題。這通常是贏得支援以及找出可達成的解決方案的好方法。

有時您可能不得不支持在開發小組中不受歡迎的解決方案。在這種情況下,您更需要知道有哪些人會支持你,並找出方式來讓大家接受,清楚地呈現解決方案的價值,或是清楚地說明若沒有解決問題時,所會發生的最壞情況。

協議工作優先順序
目的:  在可接受的時間範圍內對適當的解決方案採取動作,並且不會影響必要的品質。 

這是倡導品質的緊要關頭:這時可以協議適當的解決方案,讓開發小組可以接受,並且不會顯著降低產品品質。請記得,在大部分的情況下,測試小組只是品質方面的顧問而已,因此您務必小心不要要求接受給定的解決方案。

不過,測試小組一定要做好倡導品質的工作,有時這會包括提供開發小組不想聽的新聞。這是優秀的測試小組可以在問題透視、可能的解決方案以及瞭解每種選擇的利弊得失方面,能對開發小組提供的好處。您有時應該適度地表現出如產品最終使用者的代理人身份,並協助協議最有利於使用者的解決方案。

監視工作進度
目的:  維持支援,參與及瞭解問題的解決進度。 

有時問題和其他變更要求會在基本的產品開發和功能擴充過程中消失不見。這部分是因為開發人員比較喜歡處理新東西,但比較不喜歡修正舊的或有問題的程式,部分是因為添加新東西比修理壞的東西,較有明顯的商業價值。為了倡導品質,測試小組需要協助整個專案看出重要的問題修正到完成作業為止。

成功的軟體小組會在不斷的品質改進,到解決問題及不斷的功能擴充之間,找到良好的平衡。測試小組可以找出方法來鼓勵和支持不斷的品質改進,來協助專案小組,而不要採取不提供協助以及反對的「品質警察」角色。

確認主要問題的適當解決方案
目的:  確認主要問題的解決方案,有效地解決問題,但不會產生嚴重的負面影響。 

不論開發小組決定採取什麼樣的解決方案來解決品質問題,該解決方案一定要能改進品質。請務必要花一些時間來評定給定的解決方案所帶來的品質提升,以及該解決方案會解決原始的問題,並且不會在其他方面影響品質。

對於本身帶有某些層次風險的解決方案,最好能在發行候選解決方案的初期就做一些測試,以免在花費許多時間和人力之後,才發現解決方案不適用而必須捨棄。

評估及驗證結果
目的:  驗證作業已適當完成,並且產生可接受的工作成果。 

現在您已經完成工作了,這時最好驗證該項工作確實具有足夠的價值,而不只是花費在大量紙上作業。您應該評估您的工作是否具有適當的品質,並且該工作的完成狀態可以讓團隊的其他成員用作他們的後續工作之輸入。請盡可能使用 RUP 提供的檢查清單,來驗證品質和完成狀態都「夠好」。

請邀請執行下游作業而必須以您的工作成果作為輸入的人參與審查您的暫時性工作。請在您仍有時間採取動作來處理他們關心的問題時執行這個動作。您同時也應該將您的工作和關鍵的輸入工作成果做評估,以確定您已經正確且適當地重新呈現那些工作成果。在這個基礎上,邀請輸入工作成果的作者審查您的工作,會有助於您評估您的工作成果。

請記得 RUP 是一項反覆式的交付程序,在許多情況下,工作成果都會隨著時間而演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致浪費許多人力物力以及成本高昂的重做。同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在呈現方式佔極大的重要性,並且可以提交專案就具有商業價值的專案環境中,您可以考慮將呈現工作交給管理資源來做。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊