討論區主頁 軟體驗證測試 檢視、技術審查等審查方式之使用時機或原則為何? | 無發表權 |
樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁尾 |
發表者 | 討論內容 |
---|---|
womwom | 發表時間: 2007-11-30 17:15 |
Just popping in 註冊日: 2003-09-29 來自: 資拓宏宇國際(股)公司' 發表數: 4 |
檢視、技術審查等審查方式之使用時機或原則為何? 各位先進,您好:
1.目前常見審查方式有管理審查、技術審查、檢視(Inspection)、導覽(Walkthrough)、email審查等方式。請問各類審查方式之選擇原則或使用時機為何? 2.技術審查中有所謂之決策者(Decision maker),一般是由誰擔任此角色,此角色是否為專案成員以外的成員? 3.各類審查標的之審查準則是否有可參考之範例,或有可參考之文件或資料? 以上問題,擬請各位先進指教。謝謝! |
tyrone | 發表時間: 2008-01-05 10:24 |
網站管理員 註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
Re: 檢視、技術審查等審查方式之使用時機或原則為何? 1. 管理審查、技術審查、檢視(Inspection)、導覽(Walkthrough)、email審查等方式的選擇原則或使用時機在基本上可以由公司自己定義,但是在選擇之前最好能夠了解這些審查方式各別的目的、執行的程序、可能的風險、參與人員的職能與專業需求、審查的資料量、預期發現的缺失、產品的關鍵性、可用於審查的時間等等因素。因為這些因素都會影響到審查的績效。
有關於各種審查的目的、可交付審查之軟體產品、程序等等,可以參考IEEE Std 1028軟體審查標準。 上述中需要注意的是,E-Mail審查。這個審查基本上來說是一項非正式的審查,雖然不需要將人集中於一處開會,但是因為這種審查方式聽不到作者的一些說明或解釋,可能會有誤解或誤判問題的狀況,而使得一個會議可以全部解決的問題,卻在不斷往來澄覆之中消耗時間,這種方法較適合案情單純,僅在做文字勘誤、格式形式、語句修飾之類的書面審查,或者用來作為分組審查窗口聯繫時使用,因為分組審查時,各聯繫點只是透過電子郵件收發交付審查的軟體產品與回覆的修正建議而已,實際上的審查還是在各分組實際召集的審查會議。如果掌握前述的一些問題及用途,E-Mail審查可施用於各種技術性與管理性文件上。 導覽最好用於軟體產品初稿形成的階段,可以廣納各方意見,融合於開發設計結果之中。而專注於找尋錯誤、缺陷與異常事項時,則宜採用正規檢視。完成前述的導覽與檢視時,再交付技術審查及管理審查,在完成技術審查後的管理審查,是為了獲得文件的核准,而交付獲授權之管理者的批准簽署。 在專案之中,管理與技術審查兩類一定會存在,而工作階層的審查(以同儕審查(peer review)方式執行),包含檢視、導覽及E-Mail審查,則是視案情、文件涉及問題層面的複雜度、最終產品的關鍵性、編列多少預算實施審查而決定的。 2. 技術審查中的決策者(Decision maker),不就是主席嗎?技術審查通常會是指聯合審查的一種,屬於客戶代表與乙方專案代表(專案經理或計畫主持人)共同擔任主席的會議,在討論與最終產品有關之系統與技術文件的正確性、適用性、可行性等等。當然,對於公司自家產品的開發可能是不會有所謂的客戶代表(最好由公司的市場或業務人員擔任這個角色)的,那麼這個技術審查的主席還是可以由負責專案成敗的專案經理或是計畫主持人來擔任。 3. 審查標的審查準則可以寫在審查使用的checklist上。checklist分成兩種,一種是供文件的形式審查使用(根據公司的文件範本與文件寫作規範建立),另外一種則是用於實質內容的審查上。特定文件之審查準則的範例可以到網路上搜尋一下應該有很多,尤其是美國政府部門常常有這類的準則被釋出,是很好的參考來源,但無論如何,每個專案的每個文件,甚至於同一份文件在不同的階段都會有不同的審查準則。就以專案管理計畫來說,專案管理計畫審查不是在專案開始審查一次就行了,每次計畫改版、修訂或是專案重新規劃的時候,專案管理計畫通通都要再次交付審查的,至少要找relevant stakeholders一起進來看看計畫的可行性吧;另外,也需要形式部分的審查,因為有可能改版中,整個文件的外觀發生變動,而偏離了文件寫作規範,這可能會影響到文件的閱讀。所以每次在審查的時候,還是應依照需要,產生適當的審查準則的,而且最好能夠highlight出該次審查特別要注意的地方。
凡所有相皆是虛妄。見諸相非相。即見如來。 |
樹狀顯示 | 新的在前 | 前一個主題 | 下一個主題 | 頁首 |
無發表權 | |