敬請註冊 ... !    登入
關於本協會
登入
軟體品質資源專區
主選單
最新討論文章
討論區主頁
   軟體構型管理
     Software Configuration Audits履行實務
無發表權

樹狀顯示 | 新的在前 前一個主題 | 下一個主題 | 頁尾
發表者 討論內容
tyrone
發表時間: 2011-09-19 12:41
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Software Configuration Audits履行實務
(※ Configuration一詞,在CNS國家標準用語中,譯為 "組態"。)

在軟體專案中,買方為了要驗證,賣方已經完全依照合約需求及規格,在軟體組態項目上,已提供了買方所期望的效能能力,並證明,文件是已經交付的,組態項目的精確代表物,而買方所購買的是,符合買方所核准詳細規格的軟體組態項目,因此,需要實施軟體組態稽核(configuration audits),包含功能組態稽核(FCA)與物理組態稽核(PCA)。而專案中於何時及如何實施組態稽核,以及組態稽核應有何種產出,乃是組態管理(configuration management)的重大課題。

在CMMI的CM過程領域中,對於專案組態稽核活動並沒有給出實務的作法與指導,因此,在國內,即使已經通過CMMI ML2或更高等級評鑑的組織,若非將此項工作忽略,即是誤將組態稽核交由品保人員來實施,成為品質保證工作的一環,更無法達到組態管理所要求的組態項目(CI)的完整性(integrity)與一致性(consistency)。

專案中的軟體組態稽核,至少有10項稽核主題領域:
1.驗證程序與結果,滿足規格需求,並被接受。
2.效能規格是完整的,且足以定義該(等)項目。
3.詳細規格是完整的,且足以定義該CI。
4.軟體表列是完整的,且準確地反映可交付軟體媒體上所含數位資訊。
5.驗收測試程序及結果滿足規格需求,並被接受。
6.VDD是完整的,且準確地反映軟體營運與支援所需的文件
7.軟體媒體符合合約需求,且可依所欲目的使用
8.手冊是完整的,且準確地符合軟體的最新版本。
9.品項檢視/接收文件充分定義硬體/軟體。
10.合約商的工程釋出系統與變更控制程序,對於工程變更的處理與正式釋出是充分的。

在本課程中,將說明與組態稽核(configuration audits)有關的概念、組態稽核規劃與執行、各組態稽核主題項目如何查核、以及組態稽核應有的結果與產出。

CM概念與FCA/PCA的實務作法:有關組態稽核實施的實務部分從22:20之後開始。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

morrison
發表時間: 2011-12-22 17:13
Just popping in
註冊日: 2011-12-22
來自:
發表數: 2
Re: Software Configuration Audits履行實務
標準不標準!!!

CNS 14238:1998 品質管理 - 形態管理指導綱要 idt ISO 10007:1995, Quality Management - Guidelines for Configuration Management

Configuration: 型態、形態、構型、組態、構形、.....

為何組態稽核不能交由品保人員來實施?品保在組織本來就是兼顧老板與顧客角色的代表,相對於研發或編碼人員,是獨立的第二方,不知誤在那裡?為何會影響到Configuration Management中Configuration Items的完整性與一致性?

Configuration Management是兼顧形式與內容的物管,由專案管理負責Configuration Management會太著重於形式,Configuration = Characteristics,Quality Control and Quality Management不就是以物(products)的特性(characteristics)或事(processes)的參數(parameters)為工作對象嗎?為何還要創造其他負責的人?
tyrone
發表時間: 2011-12-22 22:50
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: Software Configuration Audits履行實務
1. ISO 10007 (CNS 14238)在國際標準化組織是在TC176/SC2中所制訂。

2. 與系統工程、軟體工程有關的process、定義等的標準,屬於JTC1,其中比較關心的像是ISO/IEC 12207(軟體生命週期過程標準)及ISO/IEC 15288(系統生命週期過程標準)及ISO/IEC 24765 (系統工程與軟體工程字彙),這些是由JTC1/SC7(聯合技術委員會1/子委會員7)所制訂。在此體系中,configuration及configuration management有關的意義與作法均有其定義,這類用語的定義其承襲美軍軍規、IEEE S2SC。看看ISO/IEC 24765再對照美軍軍規或軍方手冊(含MIL-STD 973、MIL-HDBK-61及MIL-STD 1521B)、IEEE 1042、IEEE 828等標準,即可知道其間的關聯性。而MIL-STD 973與MIL-HDBK 61等其歷史,均早於ISO 10007,且較ISO 10007的內容更為深入、規定更詳細。

3. ISO 10007屬於品質系統ISO 9000系列文件,目的在建立組織的品質管理系統,並使之有效運行。ISO 10007要處理的雖然不只是文件,同時,MIL-HDBK-61後期的版本,亦提到對於ISO 10007的符合,但是此一規定係為有助於產品品質的管理。

4. configuration 為何不能交給品保人員來實施,這個問題在於現在國內對於所謂的品保人員有所侷限,就是在管ISO 9000品質管理制度的那些人,品質小組、內稽的人員。但基本上,所謂的品質保證人員,應該是廣義的,我們在對於角色的定義時,其實是以其工作而賦予其名。也就是,執行品質保證工作的人員,才稱之為品保人員。因此,執行品質保證的人,除了根據原則--不能稽核自己的工作,其實產品的開發,很多都該是由開發小組的人員來實施的(這些人參與品保工作時,也就是品保人員),像是需求分析文件,會由分析師、設計師、測試人員等等一起來審查,這種工作中,品質系統的品質保證人員會參與,但是他們看的是該項"審查活動是不是依照組織或專案的標準來實施",對於真正產品的品質保證活動,其實是分析師、設計師、測試人員來實施的(對產品的真正品保人員)。之所以如此,因為品質保證人員對於技術性的東西是不了解的,當然,組織裡有很多活動,外部稽核的時候,會有外部專家來提供意見,內部稽核時,稽核小組是由各功能部門納編人員來實施的,如果不是如此,那麼這個品質稽核人員可能就神通廣大了,什麼都懂,甚至於組織裡所有部門的工作都要有經驗才行。不然叫這些人來稽核或做品質保證,那是"看熱鬧"而已,無法"看出門道"。對於configuration的FCA、PCA應該有一群人叫做Configuration Auditor(從工作的角度來看,賦予其名,而誰是組態稽核員,甲乙雙方的專案管理代表、需求提出者的代表、使用者代表、開發小組的代表等等)。

5. 品質保證是個概念,實際的執行,其使用技術包括驗證、確認、審查及稽核(可參閱ISO/IEC 12207:1995(E)的附錄)。所以正常來說,除了因工作的當下,賦予其名,而名之為"品質保證者"(同樣見12207:1995),不該有一種人叫做 "品保人員"或"品保工程師",有的話是很奇怪的事情,但是不明究理的人或組織,總以為,在組織或專案裡設一個品保工程師的職缺,這樣產品的品質就有保障。但是,品質稽核看的是對於計畫與標準(包含過程標準)的符合性,而驗證、確認、審查等所看的範圍就會包括需求、技術、及產品實現有關的細節了。

6. 品質人人有責。專案或組織裡有品質保證工程師的編制,並不會讓產品品質獲得保證,真正要讓人對品質有信心,是需要組織裡的每個人一起貢獻心力的。品質保證工程師,除非自己也參與開發、驗證、確認、審查、測試的工作,否則永遠只能看到文件是不是合乎要求的格式、有沒有錯別字、圖示是不是專案或組織所要求的,看不到需求有沒有被展成設計,有沒有將技術風險納入考量,change reguest裡所有該做的事情(不只是把表格中該填的東西填滿而已)是不是付諸實行,納入需求、設計,並且實現於產品之中了。

7. "品保在組織本來就是兼顧老板與顧客角色的代表,相對於研發或編碼人員,是獨立的第二方",國內實務上是否如此?每個組織不同,更多的組織其品保所負責的主要是品質管理系統那一塊而已。而從ISO 9000系列中,亦未有明確的說"品保代表老板與顧客",這個說法可能只是一些ISO 9000顧問自己的解讀而已,至少個人接觸ISO 9000系統多年時間,沒有聽過這個說法。而顧客,從品質的觀念來說,指的是產品/服務的接收者。如果花錢的客戶有10項需求,但是設計者只提出了9項需求的設計,誰能說這個有問題?品質稽核/品質保證工程師會看出來嗎?也許花錢的客戶在某次的會議中將其中的一項去掉了,也或許是提出了CR,將其中一項去掉了,也或許設計者在系統/軟體架構設計階段遺漏了一項,或許根本沒有漏,只是軟體架構設計的時候,依技術做了整合、合併所以看起來好像遺漏了....這些,品質稽核/品質保證工程師看得出來嗎?要他們看得出來,可能需要給很多的教育訓練及工作經驗吧。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

樹狀顯示 | 新的在前 前一個主題 | 下一個主題 | 頁首

無發表權
 
-=協會通訊地址:10449 台北市中山北路二段106-2號11樓=-
電話:(02)2523-6548 傳真:(02)2523-6547 電子信箱:register@csqa-tw.org.tw=-
-=本網著作權為中華民國資訊軟體品質協會所有,禁止未經授權轉貼節錄=-
Powered by XOOPS , Twe76.net