【文章內容簡介】 審類型中應涉及什么功能組，如果需要召開評審會議，應由誰主持； c 必須產什么記錄，例如：會議記錄、結果、問題、措施和措施狀態(tài)。 在設計文件的設計評審程序應提及下述內容： a 為保證符合性對規(guī)則、慣例和約定的應用進行監(jiān)督的方法，如同行評審、審查、代友審查； b 在進行評審之前必須做些什么，如制定目標、會議日程、需要的文檔和評審人員的分工； c 評審期間要做些 什么，包括需采用的技術和所有參加人員的守則；。 d 評審通過的準則； e 采用什么跟蹤方法以確保評審中發(fā)現(xiàn)的問題得以解決。 合同中有夫規(guī)定時，供方應與顧客合作召開設計評審會議。雙方應對評審結果協(xié)商一致。 建議只有當所有已知的缺陷都得到滿意的解決，或者繼續(xù)進行的風險已知時，才繼續(xù)進行一步的設計活動。 注：為得到更多的信息。參看 ISO/IEC12207： 1995 的 , 和 設計驗證 在設計的適當階段 ,應進行設計驗證 ,以確保設計階段的輸出滿 足該設計階段輸入的要求 .設計驗證應予以記錄 (見 ) 注 :除實施設計評審 (見 )之外 ,設計驗證還可包括下活動 : —— 變換方法進行計算； —— 可能時，將新設計與已證實的類似設計進行比較； —— 進行試驗和證實； —— 對發(fā)放前的設計階段文件進行評審。 建立在開發(fā)過程中，適當?shù)剡M行設計驗證。設計驗證可由設計輸出評審，包括原型和仿真的演示或測試組成。驗證可對其他開發(fā)活動的輸出進行。這些驗證活動應根據(jù)質量計劃或形成文件的程序予以記錄，并胩當措施完成時進行核算。 只有經驗證的開發(fā)輸出才應提交驗收 和后續(xù)使用。建立對任何發(fā)現(xiàn)的問題都有要充分論述并加以解決。 注：為得到更多的信息，參看 ISO/IEC12207： 1995 的 , 和 條 . 設計確認 應進行設計確認，以確保產品符合規(guī)定的使用者需要和 /或要求。 注： 設計確認在成功的設計驗證（見 ）之后進行； 確認通常在規(guī)定的操作條件下進行； 確認通常針對最終產品進行，但產品完成前的各階段也可能需要進行； 如果有不同的預期用途，也可以進行多次確認。 在產品提 交顧客驗收之前，例如在最終檢驗和測試期間，供方根據(jù)其規(guī)定的預期用途確認產品。 在軟件開發(fā)中，為了確保滿足規(guī)定的要求，確認結果以及需進一步采用的措施應加以記錄，并且當措施完成時加以檢查。這一點非常重要。只有經確認的產品才應提交驗收或后續(xù)使用。 注：為了得到更多信息，參見 ISO/IEC12207： 1995 的 和 條。 設計更改 所有的設計更改和修改的實施之前都應由授權人員加以確定，形成文件，并評審和批準。 供方應建立和維持控制任何設計更改的實施的程序，這種更改可能在產品開發(fā)生存周 期的任何時期發(fā)生。建立這種程序為了： 將更改形成文檔并證實它是否是合理的； 評價更改的后果； 批準或不批準更改； 實施并驗證更改。 在軟件開發(fā)環(huán)境中，設計更改的控制通常在配置管理規(guī)定中說明。 注：為了得到更多信息，參見 ISO 12207： 1995 的 , 和 條。 ISO 9000397 質量管理和質量保證標準 ISO 9001： 1994 在計算機軟件開發(fā)、供應、安裝和維護中的應用指南（續(xù)） 文件和資料控制 總則 供方應建立并保持形成文件和程序，以控制與本標準要求有關的所有文件和資料，并包括適當范圍的外來文件，如標準和顧客提供的圖樣。 注：文件和資料可以呈任何形式，如硬拷貝或電子媒體。 配置管理程序可以用來實施文檔和數(shù)據(jù)控制。在建立的控制所有文檔和數(shù)據(jù)的程序中，供方應確定那些需服從控制程序的文檔的數(shù)據(jù)，包括外部來源的文檔和數(shù)據(jù)，例如標準和顧客提供的數(shù)據(jù)。 文檔和數(shù)據(jù)控制程序應用于有關的文檔和數(shù)據(jù)，包括下述種類： 合同規(guī)定的文檔，包括需求規(guī)格說明書； 用于描述軟件生存周期內的質量體系的形式文件的程序； 描述供方活動的策劃和進展，以及供方與顧客相互配合的計劃文檔； 描述一具有軟件產品的或與特定軟件產品相關聯(lián)的產品文件和數(shù)據(jù)。 注：為了得到更多信息，參見 ISO/IEC 12207： 1995 的 條。 文件和資料的批準和發(fā)布 文件和資料在發(fā)布前應由授權人員審批其適用性。應制定并可隨時得到識別文件的現(xiàn)行修訂狀態(tài)的控制清單或相當?shù)奈募刂瞥绦?，以防止使用失效?/或作廢的文件。 這種控制應確保： 在對質量體系有效運行起重要作用的各個場所，都能得到相應文件的有效版本； 從所有發(fā)放或使用場所 用時撒出失效和 /或作廢的文件， 或以其他方式確保防止誤用； 為法律和 /或積累知識的目的所保留的任何已作廢的文件，都應進行適當標識。 在使用電子手段實現(xiàn)文檔控制的地方，對其適當?shù)呐鷾蚀嫒?、發(fā)放、媒體和歸檔規(guī)程應予以特別注意。 文件和資料的更改 除非有專門指定，文件和資料的更改應由該文件的原審批部門 /組織進行審批。若指定其他部門 /組織審批時，該部門 /組織應獲得審批所需依據(jù)的有關背景資料。 可行時，應在文件或相應的附件上標明更改的性質。 不需要有與軟件有關的進一步指南。 采購 總則 供方應建立并保持形成文件的程序，以確保所采購的產品（見 ）符合規(guī)定要求。 在開發(fā)、供應、安裝和維護軟件產品過程中，采購的產品可包括： —— 市售現(xiàn)成軟件軟件； —— 分承包方開發(fā)的軟件； —— 計算機和通信硬件； —— 幫助軟件開發(fā)的工具； —— 合同制工作人員； —— 維護和顧客支持服務； —— 培訓課程和教材。 注：為了得到更多信息，參看 ISO/IEC12207： 1995 的 條。 分承包方的評價 供方應： 根據(jù)滿足分合同要求（包括質量體系和特定的質量保證要求） 的能力評價和選擇分承包方； 明確供方對分承包方實行控制的方式和程度，這種方式和程度取決于產品的類別以及分承包的產品對成品質量的影響，還取決于已證實的分承包方能力和業(yè)績的質量審核報告和 /或質量記錄； 建立并保存合格分承包方的質量記錄（見 ）。 不需要有與軟件有關的進一步指南。 采購資料 購文件應清楚地說明訂購產品的資料，可包括： 類別、形式、等級或其他準確標識方法； 規(guī)范、圖樣、過程要求、檢驗規(guī)程及其他有關技術資料（包括產品、程序、過程設備和人員的認可或鑒定要求）的名稱或其他 明確標識和適用版本； 適用的質量體系標準的名稱、編號和版本。 供方應在采購文件發(fā)放前對規(guī)定的要求是否適當進行審批。 用于軟件開發(fā)的采購文檔最好包括清楚地說明訂購產品的數(shù)據(jù)，可包括： 訂購產品的準確標識，如產品名稱和 /或產品編號； 需求規(guī)格說明，或它的等同文檔（或當需求規(guī)格說明在訂購時尚未完全確定，就規(guī)定確定需求規(guī)格說明的規(guī)程）； 采用的標準（例如通信協(xié)議、體系結構規(guī)范）； 規(guī)程和 /或工作需求說明； 開發(fā)環(huán)境； 對人員的要求。 關于合同評審的考慮也可用于分合同。 采購產品的驗證 供方在分承包方貨源處的驗證 當供方提出在分承包方貨源處對采購產品進行驗證時，供方應在采購文件中規(guī)定驗證安排以及產品放行的方式。 不需要有與軟件有關的進一步指南 顧客對分承包方產品的驗證地 當合同規(guī)定時，供方顧客或其代表應權在分承包方處和供方處對分承包的產品是否符合規(guī)定要求進行驗證。供方不能把該驗證用作分承包方對質量進行了有效控制的證據(jù)。顧客的驗證既不能免供方提供可接收產品的責任，也不能排除其后顧客的拒收。 不需要有與軟件有關的進一步指南。 顧客提供產品的控 制 供方對顧客提供的產品（用于供應品或有關活動）應建立并保持驗證、貯存和維護的形成文件的控制程序。如有丟失、損壞或不適用的情況，應予以記錄并向顧客報告（見 ) 供方的驗證不能免除顧客提供可接收產品的責任。 顧客可能要求供方取得由顧客提供的包括數(shù)據(jù)在內的產品，并將其納入供方產品中，例如： 軟件產品，包括顧客提供的市售軟件產品； 開發(fā)工具； 開發(fā)環(huán)境，包括網絡服務； 測試數(shù)據(jù)和運行數(shù)據(jù)； 接口規(guī)格說明或其他規(guī)格說明； 硬件； 顧客專有信息，包括規(guī)格說明。 在任何與待交付的產品有關的維 護協(xié)議中，最好在合同中說明這類軟件產品所需的許可證和支持。 應確定已接收并已集成的顧客提供的軟件項的更新方法，供方可以應用與采購產品相同的驗證活動來驗證顧客提供的產品。 注：為得到更多信息，參看 ISO/IEC 12207： 1995 的 條。 產品標識和可追溯性 必要時，供方應建立并保持形成文件的程序，在接收和生產、交付及安裝的各階段以適當?shù)姆绞綐俗R產品。 在規(guī)定有可追溯性要求的場合，供方應建立并保持形成文件的程序，對每個或每批產品都應有唯一標識，這種標識應加以記錄（見 ）。 供方最 好建立并保持程序，用以標識從規(guī)格說明到開發(fā)、復制與交付的所有階段的軟件項。如果合同要求，這些程序也要適用于產品交付之后。 該程序最好跟蹤產品整個生存周期的軟件項或軟件產品的部件。根據(jù)合同和市場需求的不同，從可將某一變更要求加于特定發(fā)行物到記錄產品的每一變更目標和用法。 在軟件中，可以實現(xiàn)的標識可追溯性的一種方法就是配置管理。配置管理是一種管理學科，對配置項（包括軟件項）的開發(fā)和生存周期的支持，給予技術和管理指導。這種學科還適用于有關的文檔編制硬件。配置管理的使用取決于項目規(guī)模和復雜性以及風險水平。 配 置管理的一個目標編制文檔，并對產品現(xiàn)有配置和達到其要求的狀態(tài)提供足夠的可視性。另一目標是項目的每個工作人員工在項目的生存周期中的任何時刻都能采用正確的和準確的信息。 配置管理系統(tǒng)可以提供下述能力： 唯一地標識每一軟件項的版本； 標識共同構成一完整產品的特定版本的每一軟件項的版本； 標識正在開發(fā)的和已交付安裝的軟件產品的構成狀態(tài)； 控制由兩個或多個獨立工作的人員同時對一給定的軟件項的更新； 按要求在一個或多個位置對復雜產品的更新進行協(xié)調； 標識并跟蹤所有的措施和更改，這些措施和更改是在從直到放行 期間，由于更改請求或問題引起的。 供方應按下述內容標識配置： 產品結構和配置項的選擇； 文檔編制和計算機文檔； 命名慣例； 配置基線的建立。 可能由配置管理系統(tǒng)管理的產品包括： 與合同、過程、計劃和產品有關的文檔和數(shù)據(jù)； 源代碼、目標代碼和可執(zhí)行代碼； 相關產品，包括： —— 軟件工具； —— 包括庫在內的可重復用軟件； —— 外購軟件； —— 顧客提供的軟件。 供方最好建立程序，以保證每一軟件項的下述內容都能標識： 文檔； 所有有關的開發(fā)工具； 與其他軟件的接口與硬件的接口； 硬件環(huán)境與軟件環(huán)境。 供方應建立和維持配置管理狀態(tài)報告規(guī)程，以記錄、管理和報告軟件項的狀態(tài)，更改要求的狀態(tài)和已批準的更改實施狀態(tài)。 供方最好建立并實施一個包含以下內容的配置管理計劃： 負責配置管理的組織以及每一個管理組織的職責； 需要進行的配置管理活動； 所使用的配置管理工具、技術及方法； 將軟件項置于配置控制之下的時機。 注：為得到更多配置管理的信息，參見 ISO 10007 和 ISO/IEC 12207： 1995 的 條和 條。 過程控制 供方應確定并策劃直接影響質量的生產、 安裝和服務過程，確保這些過程在受控狀態(tài)下進行。受控狀態(tài)包括： 如果沒有形成文件的程序就不能保證質量時，則尋生產、安裝和服務的方法制定形成文件的程序； 使用合適的生產、安裝和服務設備并安排適宜的工作環(huán)境； 符合有關標準 /法規(guī)、質