設計開發以什麼文件形式加以規定

⑴ 常見的[平面設計]圖形文件格式都是有哪些如題 謝謝了

每個設計師都想在某一風格成為流行前把握它。沒有人願意自己的設計和流行趨勢脫節。但是無論如何，這些趨勢總是會露出端倪。 現在網頁中的圖形文件主要使用jpg、gif、bmp、tif等格式，但最易見的是gif和jpg，它們都對圖像進行了壓縮，而視覺效果並不比「巨大」的bmp、tif差多少，圖像文件的尺寸卻很小，易於在網上傳輸。但兩者還是有所區別的。 jpg：現在，一般使用掃描儀等設備所獲取或儲存的大圖片推薦使用jpg格式保存，它對顏色的保存度要比gif或tif高，在一些細節上表現要自然。所以網頁上一些人物、風景等一些圖片用的一般是jpg格式，jpg圖形一般比較柔和自然，是因為它在色塊分界上像素點過度得更加自然。但如果圖形尺寸很小，而要清晰表現線條輪廓，那樣效果就不理想了。 gif：而像按鈕或標題文字不需要太多色彩變化，要的就是直觀，而且標題文字往往還要表現出動態效果，這樣gif就當仁不讓了。gif格式可以儲存8位／點至l位／點的圖像，它減少了圖像調色板中的色彩數量，對於色彩進行了簡化，非常適合網路圖形的需要。gif圖片可以將圖片中的背景設為透明色，以便更好地與網頁融為一體；gif圖片最大的優點是它能夠在一幅圖片中內嵌多幅圖片，並設置一定的時間間隔讓這多幅圖片循環交替顯示，以此達到動畫的效果，由於gif圖片的這些特點，它比較多地用在網頁上顯示面積比較小的圖片上，比如導航欄中的標題、一些小動畫，等等。 下面給出幾種圖形圖像文件的格式，以供參考。 GIF(Graphics Interchange Format)文件 GIF是80年代初Compuserve公司針對網路傳輸帶寬的限制，採用無損壓縮方法中效率較高的LZW演算法推出的一種高壓縮比的彩色圖像格式，主要用於圖像文件的網路傳輸。GIF文件擴展名為.gif。考慮到網路傳輸中的實際情況，GIF除了一般的逐行顯示方式外，還增加了漸顯方式。也就是說，在圖像傳輸過程中，用戶可以先看到圖像的大致輪廓，隨著傳輸過程的繼續而逐漸看清圖像的細節部分，從而適應了用戶的觀賞心理，這種方式以後也被其他圖像格式所採用，如JPEG等。最初，GIF格式只是為了存儲單幅靜止圖像，稱為GIF87a，後來進一步發展成為GIF89a，可以同時存儲若干靜止圖像進而形成了動畫。目前，網路上許多動畫文件就採用了GIF89a。GIF文件的應用范圍很廣，是可在Macintosh、Amiga、Atati、IBM機器間進行移植的一種標准圖像格式。 BMP(Bitmap)文件 BMP是Windows中的標准圖像文件格式，已成為PC機Windows系統中事實上的工業標准，有壓縮和不壓縮2種形式。BMP文件擴展名為.bmp。BMP文件以獨立於設備的方法描述點陣圖，可以有黑白、16色、256色、真彩色等幾種形式，能夠被多種Windows應用程序所支持。 TIFF(Tag Image File Format)文件 TIFF由Als和微軟聯合開發，最早是為了存儲掃描儀圖像而設計的，因而它現在也是微機上使用最廣泛的圖像文件格式，在Macintosh和PC機上移植TIFF文件也十分便捷。TIFF文件的擴展名為.tif或.tiff。該格式支持的顏色深度，最高可達24位，因此存儲質量高，細微層次的信息多，有利於原稿的復制。該格式有壓縮和非壓縮2種形式，其中壓縮採用的是LZW無損壓縮方案。不過，TIFF格式包羅萬象，造成了結構較為復雜，變體很多，兼容性較差，它需要大量的編程工作來全面解碼。因此，有時您的軟體能認識TIFF文件，有時可能就不認識，對此，您不必大驚小怪。另外，使用過Photoshop的人都知道，在Photoshop中，*.tif文件可以支持24個通道，是除了Photoshop自身格式以外，惟一能存儲多於4個通道的文件格式。 TGA(Tagged Graphics)文件 TGA是由美國Truevision公司為其顯示卡開發的一種圖像文件格式，已被國際上的圖形、圖像工業所接受。現在已成為數字化圖像，以及運用光線跟蹤演算法所產生的高質量圖像的常用格式。TGA文件的擴展名為.tga。TGA的結構比較簡單，屬於一種圖形、圖像數據的通用格式，目前大部分文件為24位或32位真彩色，在多媒體領域有著很大影響。由於Truevision公司推出TGA的目的是為了採集、輸出電視圖像，所以TGA文件總是按行存儲、按行進行壓縮的，這使得它同時也成為計算機生成圖像向電視轉換的一種首選格式。 JPEG文件 JPEG是the Joint Photographic Experts Group(聯合圖像專家組)的縮寫，是用於連續色調靜態圖像壓縮的一種標准。其主要方法是採用預測編碼(DPCM)、離散餘弦變換(DCT)以及熵編碼，以去除冗餘的圖像和彩色數據，屬於有損壓縮方式。JPEG是一種高效率的24點陣圖像文件壓縮格式，同樣一幅圖像 ，用JPEG格式存儲的文件是其他類型文件的1/10～1/20，通常只有幾十KB，而顏色深度仍然是24位，其質量損失非常小，基本上無法看出。JPEG文件的應用也十分廣泛，特別是在網路和光碟讀物上，肯定都有它的影子。JPEG文件的擴展名為.jpg或.jpeg。 PNG(Portable Network Graphics)文件 PNG是一種可以存儲32位信息的圖像文件格式，採用無損壓縮方式來減少文件的大小。目前越來越多的軟體開始支持這一格式，而且在網路上也開始流行。PNG文件的擴展名為.png。PNG使用的是高速交替顯示方案，顯示速度快，只需下載1/64的圖像信息就可以顯示出低解析度的預覽圖像，遺憾的是它不支持動畫。 WMF(Windows Metafile Format)文件 WMF是Windows中常見的一種圖元文件格式，是矢量文件格式。它具有文件短小、圖案造型化的特點，整個圖形常由各個獨立的組成部分拼接而成，但其圖形往往較粗糙。WMF文件的擴展名為.wmf。 EMF(Enhanced Metafile)文件 EMF是微軟公司開發的一種Windows 32位擴展圖元文件格式，是矢量文件格式。其總體目標是要彌補使用WMF的不足，使得圖元文件更加易於接受。EMF文件的擴展名為.emf。 EPS(Encapsulated PostScript)文件 EPS是用PostScript語言描述的一種ASCII碼文件格式，即可以存儲矢量圖，也可以存儲點陣圖，最高能表示32位顏色深度，特別適合PostScript列印機。該格式分為Photoshop EPS格式(Adobe Illustrator EPS)和標准EPS格式，其中標准EPS格式又可分為矢量格式和點陣圖格式。EPS文件的擴展名為.eps。EPS一般包含2部分：第一部分是屏幕的低解析度影像，方便處理時的預覽和定位; 第二部分包含各個分色的單獨資料。 DXF(Autodesk Drawing eXchange Format)文件 DXF是AutoCAD中的矢量文件格式，它以ASCII碼方式存儲文件，在表現圖形的大小方面十分精確。DXF文件可以被許多軟體調用或輸出。DXF文件的擴展名為.dxf。 SWF(Shockwave Format)文件 SWF是二維動畫軟體Flash中的矢量動畫格式，主要用於Web頁面上的動畫發布。目前，已成為網上動畫的事實標准。SWF文件的擴展名為.swf。

⑵ 軟體開發文檔的分類

1. 《功能要求》 -- 來源於客戶要求和市場調查，是軟體開發中最早期的一個環節。客戶提出一個模糊的功能概念，或者要求解決一個實際問題，或者參照同類軟體的一個功能。有軟體經驗的客戶還會提供比較詳細的技術規范書，把他們的要求全部列表書寫在文檔中，必要時加以圖表解說。這份文檔是需求分析的基礎。
2. 《投標方案》 -- 根據用戶的功能要求，經過與招標方溝通和確認，技術人員開始書寫《投標方案》，方案書一般包括以下幾個重要的章節： 前言 -- 項目背景、公司背景和業務、技術人員結構、公司的成功案例介紹等。 需求分析 -- 項目要求、軟體結構、功能列表、功能描述、注意事項等。 技術方案 -- 總體要求和指導思想、技術解決方案、軟體開發平台、網路結構體系等。 項目管理 -- 描述公司的軟體開發流程、工程實施服務、組織和人員分工、開發進度控制、軟體質量保證、項目驗收和人員培訓、軟體資料文檔等。 技術支持 -- 公司的技術支持和服務介紹、服務宗旨和目標、服務級別和響應時間、技術服務區域、技術服務期限、授權用戶聯系人等。 系統報價 -- 軟、硬體平台報價列表、軟體開發費用、系統維護費用等。 項目進度 -- 整個項目的進度計劃，包括簽署合同、項目啟動、需求分析、系統分析、程序開發、測試維護、系統集成、用戶驗收、用戶培訓等步驟的時間規劃。
3. 《需求分析》 -- 包括產品概述、主要概念、操作流程、功能列表和解說、注意事項、系統環境等。以《功能要求》為基礎，進行詳細的功能分析 ( 包括客戶提出的要求和根據開發經驗建議的功能 ) ，列出本產品是什麼，有什麼特殊的概念，包括哪些功能分類，需要具備什麼功能，該功能的操作如何，實現的時候該注意什麼細節，客戶有什麼要求，系統運行環境的要求等。這里的功能描述跟以後的使用手冊是一致的。
4. 《技術分析》 -- 包括技術選型、技術比較、開發人員、關鍵技術問題的解決、技術風險、技術升級方向、技術方案評價，競爭對手技術分析等。以《需求分析》為基礎，進行詳細的技術分析 ( 產品的性能和實現方法 ) ，列出本項目需要使用什麼技術方案，為什麼，有哪些技術問題要解決 ，估計開發期間會碰到什麼困難，技術方案以後如何升級，對本項目的技術有什麼評價等。
5. 《系統分析》 -- 包括功能實現、模塊組成、功能流程圖、函數介面、數據字典、軟體開發需要考慮的各種問題等。以《需求分析》為基礎，進行詳細的系統分析 ( 產品的開發和實現方法 ) ，估計開發期間需要把什麼問題說明白，程序員根據《系統分析》，開始在項目主管的帶領下進行編碼。
6. 《資料庫文檔》 -- 包括資料庫名稱、表名、欄位名、欄位類型、欄位說明、備注、欄位數值計算公式等。以《系統分析》為基礎，進行詳細的資料庫設計。必要時可以用圖表解說，特別是關系資料庫。
7. 《功能函數文檔》 -- 包括變數名、變數初值、功能，函數名，參數，如何調用、備注、注意事項等。以《系統分析》為基礎，進行詳細的說明，列出哪個功能涉及多少個函數，以便以後程序員修改、接手和擴展。
8. 《界面文檔》 -- 包括軟體外觀、界面素材、編輯工具、文件名、菜單、按鈕和其它界面部件的要求，這里與軟體完成後的運行界面是一致的。
9. 《編譯手冊》 -- 包括伺服器編譯環境、操作系統、編譯工具、 GNU 的 C++ 編譯器版本信息、目錄說明、程序生成、源程序文件列表、 Makefile 配置及其相關程序的對應關系列表。客戶端的編譯過程、編譯結果、編譯示例、編譯環境、操作系統、編譯工具、源文件列表和製作安裝程序的過程。
10. 《 QA 文檔》 -- 包括產品簡介、產品原理、產品功能列表、功能描述、功能流程、執行結果、資料庫結構、測試要求等，提供給軟體測試人員使用。
11. 《項目總結》 -- 包括項目簡介、項目參與人員和開發時間、項目風險管理過程、項目功能列表、項目結構特點、技術特點、對項目的升級建議、對以後的項目的建議、人員素質情況等。 1. 《產品簡介》 -- 包括公司背景、產品概念、適用范圍、產品功能、功能特點、運行要求和公司聯系地址。
2. 《產品演示》 -- 包括公司簡介、產品背景、產品描述、產品特點、產品作用、適用范圍、使用分析、功能模塊、解決問題、合作夥伴、成功案例等。一般用 Power point 或者 VCD 錄制軟體實現。
3. 《疑問解答》 -- 列出用戶關心的問題和處理方法。用於解答軟體的操作功能和解決用戶的疑難問題。
4. 《功能介紹》 -- 以《需求分析》為書寫基礎，包括軟體介紹、軟體結構、功能列表、功能描述和公司聯系地址。
5. 《技術白皮書》 -- 以《技術分析》為書寫基礎，包括功能實現、技術選型、關鍵技術問題的解決、技術方案特點、技術升級方向等。
6. 《評測報告》 -- 第三方權威評測報告。包括評測目的、評測范圍、評測環境、評測內容、實測數據、性能表現、結果分析和評測總結等。
7. 《安裝手冊》 -- 包括系統環境、運行平台、產品安裝過程、初始環境設置、安裝記錄等。
8. 《使用手冊》 -- 包括產品簡介、功能列表、功能描述和解釋、功能操作、客戶服務和聯系方式等。
9. 《維護手冊》 -- 包括產品簡介、系統須知、初始環境設置、系統配置、數據管理和備份、技術問題解答和聯系方式等。
10. 《用戶報告》 -- 包括產品簡介、購買時間、使用目的、使用時間、使用地點、實施過程、出現問題和解決、產品總結和建議等。
11. 《銷售培訓》 -- 包括項目簡介、產品功能、產品特點、商業優勢、系統運行環境、適用范圍、目標客戶等。 第一、需求分析文檔
用戶需求分析文檔是指在和客戶進行溝通時，把用戶所要求的信息記錄下來，根據用戶的要求進行需求分析，規劃出我們要開發的軟體所要實現哪些功能。
第二、概要設計文檔
概要設計：顧名思義，就是對我們所要開發的軟體進行一個整體的概括，把這個軟體所包含的功能模塊作一個設計，以後我們在開發的時候就有目標，有方向了。
第三、系統設計文檔
系統設計，就是對概要的一個詳細的實施，就是分析我們所要開發軟體各大功能模塊中所包含的小模塊，把這些小模塊都一一列舉出來，然後再對軟體開發人員進行有條理的進行開發任務的分配。
第四、詳細設計文檔
詳細設計文檔，主要是把我們每個小模塊，小功能的業務邏輯處理用文字的方式表達出來，讓程序員在編碼的時候有一個依據和參照；同時，在進行詳細文檔設計的時候，有的軟體公司也會根據不同的項目作出相應的《軟體開發代碼規范》性文檔。以保障我們所做工作的統一性。
第五、軟體測試文檔
當我們參照軟體詳細設計文檔編碼完成後，接著就會根據我們所實現的功能，進行軟體測試文檔的編寫；大多測試文檔有兩類，一類是軟體單體測試文檔，一類是軟體結合測試文檔；顧名思義，單體測試：就是對軟體中每個小的方法，一個獨立的方法進行測試的文檔；結合測試：就是把多個功能模塊組合到一起進行測試，主要是為了檢測每個功能模塊之前的交互性和功能的結合實現性。
第六、軟體完成後的總結匯報型文檔
不管所開發軟體的規模大小，在一個軟體開發結束後，我們都會把開發過中的問題和項目開發總結一起記錄下來，以防以後在開發過程中再有類似問題出現，提高我們的開發效率。
根據軟體開發公司的規模、標准和客戶的需求不同，開發文檔的種類和數量也不同，我在這里和大家討論的軟體開發相關文檔都是最基礎的；在軟體行業有一句話：一個軟體能否順利的完成並且功能是否完善，重要是看這個軟體有多少文檔，軟體開發文檔是一個軟體的支柱，如果你的開發文檔漏洞百出，那麼你所開發出來的軟體也不可能會好；開發文檔的好壞可以直接影響到所開發出來軟體的成功與否。

⑶ 醫療器械的設計開發工作有哪些輸入文件和輸出文件

1、設計開發任務書在前，它是在設計開發「策劃」階段，根據產品的特點，對設計開發活動進行策劃時形成的文件，比較宏觀，而且除技術層面外還應包括「設計和開發各階段人員和部門的職責、許可權和溝通」。2、設計開發輸入是則相對具體，「包括預期用途

⑷ 化工企業IS09000質量管理體系設計開發程序文件內容

******公司文件

設計和開發控製程序

文件編號：******
版 號： *
修 改 號： *

編 制： *** **** 年 **月 **日
審 核： *** **** 年 **月 **日
批 准： *** **** 年 **月 **日

發放號： ** 受控狀態：

**** 發布 ****實施
*****有限公司 發布

1 目的
對產品的設計和開發過程實施控制，確保新產品的質量滿足合同或顧客的要求，項目環境、安全、職業健康影響因素得到識別和控制。
2 適用范圍
適用於本公司新產品設計和開發的實施、評審、驗證、確認和更改等過程的控制。
3 職責
3.1總工辦負責產品設計和開發，提供相關的產品設計和開發方案，進行適宜的設計和開發評審、驗證以及確認。
3.2 副總經理（主管營銷）負責組織銷售部進行市場調研和市場的可行性分析，生產管理部負責中試原料采購計劃的編制，采購科負責樣品、小批試制所需物料的采購。
3.3 研發室和生產管理部負責組織預研、小試、工藝優化及中試和試生產。
3.4 質檢科負責樣品及小批量試制樣品的檢驗和測試。
4 工作程序
4.1產品設計和開發的信息來源：
a. 依據顧客提出的要求進行設計和開發。
b. 依據社會的需求和市場調查自行設計和開發。
c. 與總公司、科研院所合作，引進技術和圖樣；總公司下達的設計開發任務。
4.2設計和開發的策劃
4.2.1 初步策劃
a.公司各部門及各員工根據獲得的信息(包括新產品、新技術合同意向)，可對公司提出項目建議，填寫「項目建議書」，提交總工辦，由技術人員對工藝可行性、環境影響、安全影響、職業健康影響進行初步評價，提交總工程師審核後，報總經理審批。決定預研的項目由總工程師將預研任務填入「預研任務書」，由總工辦將預研任務書下達至相關設計開發部門進行預研。總工辦制定預研項目編號，將該項目列入「預研項目匯總表」中。對於新產品新技術，預研項目負責人應委託銷售部進行市場調研工作。
b.對公司已開發成功的小試技術進行中試或試生產調試時，可不做預研，直接提交「項目可行性分析報告」 ，按本程序4.2.3後執行。
對於某些項目（如：屬客戶訂單產品或客戶委託試制產品；技術服務類項目），可不做較深入的市場可行性分析，只做工藝可行性、環境影響、安全影響、職業健康影響初步評價。
c.對於總公司研發中心已完成預研或小試後下達的研發任務，由總工程師下發驗證任務書，組織技術人員進行驗證。總工辦組織對驗證結果進行評審，並根據評審結果確定進行下步實驗，總工辦下發相應的設計任務書。
4.2.2預研階段
項目預研負責人根據預研任務要求組織實施預研階段的工作。
預研階段的結論由預研負責人形成文字材料後提交總工辦，並填入「項目可行性分析報告」相應欄中。文字材料應包括：文獻調研報告、預研實驗結論及工藝可行性、環境影響、安全影響、職業健康影響初步評價、市場調研報告等內容。
4.2.3項目可行性評審及立項
a. 「項目可行性分析報告」由總工程師組織相關人員進行評審，並做記錄。
b.評審內容包括：工藝可行性、環境影響、安全影響、職業健康影響初步評價、市場可行性分析、本公司的開發優勢、人力資源、原料和設備獲得、研發計劃、時間及相關法規等。
c.經評審通過，方予立項。評審結果填寫於「項目可行性分析報告」的相應欄目中，並由總工程師簽字確認，報呈總經理批准。
d.對批准立項的項目，由總工程師下達「設計開發任務書」交相關設計開發部門。總工辦制定項目編號，並將該項目列入「設計開發項目匯總表」中。其中項目編號按以下規則制定：
□□ □□□ □□ □□□ □

e.對不予立項的項目，根據評審結論停止研發或採取相應的糾正措施。
4.2.4設計開發任務書
「設計開發任務書」應包括以下方面內容：
a. 設計和開發輸入文件內容；技術條件要求；
b. 人員及其職責；
c. 進度安排以及專業協作分工；
d. 設計和開發的評審、驗證和確認的時機及相應的方式；
f. 計劃隨設計和開發的進展可作必要的調整、補充。
4.3產品設計和開發的輸入
4.3.1設計開發輸入由項目負責人（中試項目技術負責人即為項目負責人）根據「設計開發任務書」內容組織並進行評審，填寫「設計開發輸入清單」。
4.3.2設計開發輸入包括以下內容：
a.設計和開發依據，包括顧客提供的設計和開發基礎資料；
b.產品或技術服務的主要功能，性能要求（可提供如合同復印件、相關信函、訂單復印件、項目建議書及項目可行性預研報告等相關資料）；
c.適用的法律法規和其他要求（如三廢排放法規，相應的國家標准、企業標准等）；
d.對確定產品的安全性和適用性至關重要的特性要求，包括安全、包裝、貯存、維護及環境等；
e.以前類似設計提供的信息；
f.設計和開發所必需的其他要求。
4.3.3 由總工辦對設計和開發輸入的文件、資料組織進行評審，以確保輸入內容是充分的與適宜的，滿足設計和開發的要求，輸入內容要求應完整、清楚，並且不能自相矛盾，設計和開發輸入評審應形成記錄。
4.4產品設計和開發的輸出
4.4.1設計開發人員根據設計開發計劃書開展設計開發工作，並編制設計開發輸出文件。
4.4.2設計開發輸出文件以能針對設計開發輸入進行驗證的形式提出。項目負責人提交設計和開發實驗報告（或中試/試生產調試報告）、相應的輸出文件和樣品，以便於證明滿足輸入要求，為下一階段任務實施提供充分的信息。
4.4.3設計開發的輸出文件包括：工藝路線、工藝流程圖、三廢處理方法、原料分析方法、中控方法、產品分析方法和報告、重要圖譜、成本核算、采購物資分類明細表和產品接收標准、原料接收標准、物料衡算、原料物性、中間體產品物性和產品物性，產品穩定性試驗結果、產品貯存有效期，產品包裝要求等。如設計開發的輸出文件用於指導中試和試生產，則設計開發輸出文件還應包括：指導中試和試生產等活動的圖樣和文件，如工藝操作規程、工藝流程圖，並對產品包裝提出指導性意見；三廢處理方案；產品質量的測試報告；中試或試生產采購物資分類明細表；產品技術規范；中試或試生產設備清單，中試（試生產）備案材料。
4.4.4設計和開發輸出應確保
a.符合合同和有關法規的要求；
b.能夠對照設計和開發輸入要求進行驗證和確認。
4.4.5根據產品特點規定對安全和正常使用至關重要的產品特性，包括安裝、使用、搬運、維護及處置的要求。
4.4.5項目負責人填寫「設計開發輸出清單」，經設計開發部門負責人審核、總工程師審批或會議評審通過後輸出文件。
4.5設計和開發評審
設計開發的評審應貫穿於設計開發的整個過程中。
4.5.1評審以會議進行。對每個過程的評審要有記錄，根據評審結果填寫「設計開發評審報告」，評審記錄需經總工程師簽字認可，會議評審必須有會議記錄或會議紀要。
4.5.2評審由總工辦組織相關人員參加，評審結論由參評人員評審確定，項目負責人根據需要採取相應的改進或糾正措施。
4.5.3評審的頻次：評審計劃由總工辦根據項目研發計劃制定，並按計劃組織實施。除此之外，總工程師根據需要可不定期召開評審會議。
4.5.4評審的目的是評價滿足階段設計開發需求及對應於內外部資源適應性，滿足總體的設計輸入要求的充分性。確認是否滿足設計開發進度；識別和預測問題，提出糾正措施，以確保最終滿足顧客要求及環境、安全、職業健康要求。
4.5.5評審時應識別存在的問題並提出解決的措施，由項目負責人確認後進行實施，組織評審的部門進行跟蹤驗證，在評審報告中記錄完成情況即可。
4.5.6如在評審中發現該項目因具有不適宜性，決定終止或長時間暫緩研發，經評審做出結題的決定，由項目負責人填寫「結題報告書」。
4.5.7 設計和開發的評審內容：
a. 設計和開發方案是否合理，是否滿足合同的要求；
b. 工藝方案是否滿足加工要求或便於加工，是否節能低耗，清潔生產；
c. 技術參數的選用以及其可靠性和安全性；
d. 三廢處理措施是否切實可行。
4.6 設計和開發驗證
4.6.1總工辦組織有關人員對設計開發的輸出進行驗證，以確認與設計開發的輸入一致。驗證應對設計開發過程或試驗結果予以分析和查證。產品根據需要可由質檢科進行檢測或送權威檢測機構檢測，並出具檢測報告，或由客戶試用或使用，以驗證品質。
4.6.2設計和開發驗證的方式除設計和開發評審外，還可以採用以下方法進行：
a. 變換方法進行計算；
b. 可能時，將新設計與已證實的類似設計進行對比；
c. 進行試驗和證實。
4.6.3小試項目經驗證後由項目負責人組織完成「設計開發驗證報告」，記錄驗證的結果及跟蹤的措施，報總工程師批准。
4.6.4設計和開發驗證的結果應明確設計和開發輸出是否滿足設計和開發輸入的要求。
4.7 設計和開發確認
4.7.1在成功的設計和開發驗證後，根據計劃的安排進行產品的設計和開發確認。
4.7.2確認的目的是證明設計開發的結果能夠滿足預期的使用要求。通常應在設計開發交付之前（如技術轉讓、技術服務、技術咨詢）或產品實施（如批量生產）之前完成。如需經用戶使用一段時間才能完成確認工作的，應在可能的適用范圍內實現局部確認。根據產品的特點，可以選擇下述幾種確認方式之一：
a. 由總工辦組織相關專家進行會議評審方式進行確認。
b. 通過中試、試生產或試用的方法進行確認。必要時由銷售部將樣品提交客戶確認，由客戶出具確認報告。
c. 對外技術轉讓、技術服務和技術咨詢項目以顧客的驗收報告作為確認。
上述報告及相關資料為確認的結果，設計開發部門對此結果進行分析，根據需要採取相應的跟蹤和改進措施。
4.8設計和開發更改
設計開發人員應正確識別和評估設計更改對產品的原材料使用、生產過程、使用性能、安全性、可靠性等方面帶來的影響。
4.8.1對於設計開發過程中，由於顧客提出的產品要求變更、設計開發計劃變更等原因，引起對設計開發的更改，提出更改人填寫「設計開發變更申請單」，附上相關資料，經部門負責人審核、總工程師審批後，由設計開發部門執行更改。
4.8.2當更改涉及到主要技術參數和功能、性能指標的改變，或人身安全及相關法律法規要求時，應對更改進行適當的評審(設計開發更改的評審應包括評價更改對產品組成部分和已交付產品的影響)、驗證和確認。
4.8.3對設計開發更改過程中引起的文件變更，局部更改由授權技術員劃改即可，若出現較大調整執行「工藝更改通知單」，並履行有關審批手續。
4.9 結題
4.9.1設計開發項目因下列各種狀況可予結題：
a. 項目開發成功、完成開發任務、需結束研發或立即轉移至其他部門；
b. 完成合同要求或得到客戶確認時；
c. 因未能完成開發目標而終止項目時；
d. 因各種原因，合同中斷執行。
4.9.2結題時填寫「結題報告書」。
4.9.3 「結題報告書」需經總工程師審核，總經理批准。
4.9.4結題後應將所有設計開發資料交總工辦匯總保存，總工辦將該項目列入「結題項目匯總表」中，按《記錄控製程序》的要求執行。
4.10中試達到預期目的後，公司根據市場情況組織試生產，試生產驗收合格後適時組織大生產。
5 相關文件
5.1 《文件控製程序》
5.2 《記錄控製程序》
6 記錄
6.1 項目建議書
6.2 預研項目匯總表
6.3 項目可行性分析報告
6.4 設計開發項目匯總表
6.5 項目設計開發任務書
6.6 設計開發輸入清單
6.7 設計開發輸出清單
6.8 設計開發評審報告
6.9 結題報告書
6.10 設計開發驗證報告
6.11 設計開發變更申請單
6.12 結題項目匯總表
6.13 項目預研任務書
6.14 工藝更改通知單
7 附件
附：設計和開發簡易流程