7.3.1.HS.1 注1:
操作環境由和顧客分別從或者組織或者供方采購,產品所需要的安裝硬件,軟件或系統組成的,從老的到新的軟件操作環境變更例子包括升級到操作系統,數據庫或溝通協議,從老的到新的硬件操作環境變更例子包括使用線路,包含在新的機架或用新的控制器,或者升級計算機硬件。
7.3.1.HS.1 注2:
假如老的環境不再被支持,針對使用的或連接老環境的進入,數據防護和審核目的必須被考慮,以符合法規和合同要求。
7.3.1.HS.2 設計開發質量測量策劃和實施
在設計開發階段,組織必須建立和保持項目選擇和報告合適的設計開發過程質量測量的方法。在此階段推薦,測量系統必須針對項目被合適地實施。測量應該覆蓋項目進度的區域(生命周期階段轉變或里程碑監視),測試實施和缺陷監視測試階段。
注:見在TL9000 注冊指南章節文件”建立和運行系統”,可幫助選擇和建立合適的項目設計開發過程測量。
7.3.1.HS.3 計算機資源
組織必須建立和保持針對目標計算機的評估和跟蹤的關鍵績效參數。
7.3.1.HS.3-Note:這些資源的例子是內存,容量,時間效率,I/O 通道. 固件例子包括處理器,內存,I/O 通道.
7.3.2.C.1 顧客與供方的輸入
組織必須建立并保持方法,以在開發新的或更改產品要求時,征求和考慮顧客與供方的輸入。
7.3.2.C.1 注:與顧客和供方輸入一樣,組織也應該考慮來之于競爭對手的分析。
7.3.2.C.2 設計和開發要求
設計和開發要求必須被確定和文件化,并應該包括:
a) 質量和可靠性的要求,
b) 產品的功能和能力,
c) 業務的,組織的和用戶的要求,
d) 安全,環境和保安的要求,
e) 可生產性,安裝性,使用性,互用性和可維修性的要求,
f) 設計限制,和
g) 測試要求,
h) 相關目標的計算機資源。
7.3.2.C.2 注:設計和開發要求應該針對關注預防錯誤的定義。
7.3.2.C.3 要求配置
組織必須文件化針對產品結構的產品要求配置。
注:被配置的要求例子應該針對軟件的響應時間,硬件熱耗散和服務必要時間。
7.3.2.H.1 要求的內容
產品要求必須包括,但不僅限于:
a) 標稱值和公差,
b) 可維修性的需要,和
c) 包裝要求。
7.3.2.S.1 軟件要求的標識
組織必須確定,分析和文件化在系統中軟件單元的要求。
7.3.3.HS.1 設計和開發輸出
設計和開發輸出應該包括但不僅限于:
a) 系統結構;
b) 系統詳細設計;
c) 原始代碼; 和
d) 用戶文件.
7.3.3.V.1 服務設計和開發輸出
服務設計和開發的輸出要求必須包含所提供服務的完整和精確的描述. 設計和開發輸出必須包括但不僅限于:
a) 服務提供的程序,
b) 資源和技能要求,
c) 對供方的依靠,
d) 受到客戶評價的服務特性, 和
e) 每項服務特性的接受標準。
7.3.5.C.1 文件驗證
組織必須在產品交付前驗證顧客和/或使用者的文件。
7.3.5.HS.1 過載測試
組織必須在過載的條件下測試產品,包括但不限于:
a) 超邊界條件和非法輸入情況;
b) 高流量和模擬峰值運載;
c) 誤操作;
7.3.5.HS.2 異常條件
組織必須在異常條件下測試產品,包括錯誤,適當時,
a) 硬件錯誤,
b) 軟件錯誤,
c) 操作,管理,維護和提供(OAM&P)的錯誤,
d) 過載通量,
e) 非法使用者進入,
f) 來自中斷的系統恢復。
7.3.5.HS.3系統測試
每一個產品發行必須服從于系統測試,符合文件化系統測試計劃。
7.3.6.C 注:在各種確認階段,可以包含顧客和第三方。
7.3.6.HS.1 發行管理
組織必須建立并保持方法以確保產品和有關文件的發行和交付是在受控條件下被實施。方法應該提供顧客如下交付:
a) 在發行前提供足夠的發行策劃信息給客戶,
b) 產品導入和發行的時間計劃,
c) 新軟件產品或發行中,詳細的交付產品特征描述和包含任何的更改,和
d) 涉及到有關合同項目的目前和策劃變更咨詢.
7.3.7.C.1 更改管理過程
組織必須建立并保持一文件化程序,以確保在產品生命周期中隨時可能出現的所有要求和設計更改,以適合生命周期階段方式均被系統地和及時地管理和跟蹤,組織必須確保不會負面相互影響質量,可靠性和功能目的的變更在批準前與顧客進行評審。更改管理應該包括:
a) 影響分析,
b) 策劃,
c) 實施,
d) 測試,
e) 文件化,
f) 溝通,和
g) 評審和批準。
7.3.7.C.1 注:當生命周期中的變更管理過程被規定時,在哪個過程中的控制可以依據生命階段。例如:在設計過程中,組織應該有能力對快速變更顧客要求作出反應,利用突出技術響應變更管理過程。在量產后變更管理過程范圍應該考慮對產品運行和維護及它的安裝基礎的變更如何影響顧客和 stakeholders 的整體性。考慮的因素應該包括質量,可靠性和功能意圖。
7.3.7.C.2 通知設計變更的客戶
組織必須建立一文件化程序, 以確保當設計更改影響到合同承諾時的客戶被通知。
7.3.7 C.3 問題解決配置管理
組織必須確保配置管理系統跟蹤解決問題和整合這些解決在未來的更改版本中。
7.3.7.H.1 零件更改
組織必須建立文件化程序,以確保材料或零件的替代或更改不會負面影響產品要求的符合性或性能。文件化程序應該包括:
a) 功能測試,
b) 認可測試,
c) 負載測試,
d) 合格部件清單,和/或
e) 關鍵部件清單。
7.4.1.C.1 采購程序
組織必須建立一文件化采購程序,確保:
a) 產品要求定義,
b) 風險被了解和管理,
c) 認可準則被建立,
d) 接受準則被建立,
e) 合同被規定,
f) 專利權,使用,所有權,擔保和許可證能滿足,
g) 產品未來的支持被策劃,
h) 持續的供方管理和監控是適當的,
i) 供方選擇準則被規定,
j) 供方再評價,和
k) 以供方的績效數據分析向主要供方的反饋。
7.4.1.C.1- 注 1 :此文件化程序適用于現貨市場產品。包括在制造中的原設備制造廠(OEM) 產品和軟件系統的現貨市場(COTS)產品。
7.4.1.C.2 供方業績管理
組織必須策劃和執行供方業績管理和開發活動,以便:
a) 依據建立的準則的合格供方,
b) 在供方選擇活動中評價的結果被考慮,
c) 依據建立的準則,供方被周期性被復評,
d) 供方質量業績被跟蹤,并反饋給供方促其改進,和
e) 針對識別的關鍵供方,當供方的產品發生時,推動TL9000 要求和測量,或其他合適的質量管理體系, TL9000 優先考慮。
7.4.1.C.2 注1 供方業績管理策劃和活動應該聯系組織的8.5 改進過程,
7.4.1.C.2 注2 應該認識到,就一組織而言,對所有供方提供一種影響程度水準是不可能的,該水準可以根據供方的業務量,產品的重要程度,問題的歷史,組織的期望,供應鏈中供方的重要性或其他因素。
7.4.1.C.2 注3:針對合適的質量管理體系的例子可以包括:調查,供應商問卷,涉及到符合標準的供應商教育和培訓,全部或部分的TL9000要求和測量;評估TL9000符合或符合一個適合的質量管理體系的第二方審核;TL9000或其它標準的認證,例如:ISO9001,AS9100,CMMI, ISO/TS16949等.
7.5.1.C.1 客戶服務資源
組織必須對與客戶接觸的員工提供適當的工具,培訓和需要的資源,以提供有效和及時的客戶服務。
7.5.1.C.2 產品交付
組織必須建立和保持在產品交付和安裝期間最小化對顧客正常運行和服務影響的方法。