信息系統設計評審的工作該如何開展
摘要：由乙方出具設計方案的大中型的信息化系統，通常會組織較爲正式的設計方案評審會，一方面意味着甲方基本認可乙方的方案，另一方面意味着乙方將對照項目目標勾畫出具體的框架，並從此開始圍繞這個框架而開展具體的開發建設工作。那麼，如何做一個有意義的設計評審，將是本文關注的重點。
問題一：爲何需要設計評審？
設計評審不是走過場的講講濃縮的理念，回答評審專家的問題，更不是專題討論會，而是一場對之前所進行的設計工作的認可會。作爲甲方，需要在設計方案中得到乙方較爲正式的總結和敘述。而作爲乙方，需要向監理和甲方彙報設計工作，並得到他們的正式認可。設計評審的結論，作爲設計階段的收尾工作內容，直接定調設計工作是繼續完善，還是可以過渡到開發工作。因此，設計評審工作，是項目建設中必不可少的環節。
問題二：如何做一個有意義的設計評審？
一般的設計評審，分爲兩大類，一種是隻有乙方的設計師們參加的評審，專注於技術論證；另一種是項目組組織的設計評審，評審專家由甲方單位負責組織協調，大致有甲方項目經理、甲方業務專家、甲方技術專家、外聘專家等，而參與設計評審會的人大體上會有監理和乙方的相關人員。本文關注的設計評審主要是後者。
設計評審會的參與人員及前期工作：設計評審會，參與評審的專家一般是三到七人，此外監理和乙方人員若干。一般，需要在乙方做完架構設計論證、功能設計論證、UI設計論證、接口設計論證、數據庫設計論證、存儲方案設計論證、網絡方案論證等分步工作後，纔可以開始真正意義上的項目設計評審會。
設計方案中寫一些什麼內容：一般從系統架構開始，逐層分解，講述系統結構、流程和功能，並在專題章節中，寫出UI模型、接口、數據庫、系統存儲和網絡方案、系統上線方案及應急預案。在提交的這些內容中，是將前期各設計論證會議的成果總結濃縮成整體的方案，圍繞甲乙雙方的合同中提及的項目目標而撰寫的，章節中要求體現出回答了合同要求的哪些章節內容，以便讓各方知道，設計方案覆蓋了合同約定的項目目標。此外，設計方案需要就係統的性能問題、安全問題、可靠性問題、易維護性問題，對可能存在的系統崩潰點進行分析說明，並詳細說明有哪些應對措施。若是升級改造項目，在設計文稿裏面還應該體現系統的切換方案。
設計評審會前後各方的協調工作：
（1）評審前：甲方協調評審專家參加會議，以及會議組織工作，監理負責協調確定會議的議程及時間、地點、出席人員等信息，乙方負責提交設計方案及評審會議材料；
（2）評審中：甲方申明評審會議的意義和會議議程，並評審方案，監理負責記錄會議過程和內容，乙方負責陳述設計方案、回答相關問題；
（3）評審後，甲方負責總結評審成果，下定會議結論，監理負責跟蹤評審結論的執行情況，乙方負責同步後續跟進計劃。
設計評審過程中關注哪些要素：
（1）從頂層架構設計開始，逐步說明系統架構分幾層、每一層的設計依據等信息。設計依據一般來自合同要求或者是IT最新技術；
（2）需要對需求分析產生的功能進行分類說明，進而進行功能分層的設計介紹、功能點的性能指標進行說明；
（3）需要對應用層及面向用戶的終端深化設計作特別介紹，是如何滿足用戶提出來的這類型需求的；
（4）需要對接口結構、輸入輸出項、應用場景、處理效率指標進行詳細說明；
（5）需要對某些採購的產品選型進行說明，爲何選擇這些工具、模塊、軟件；
（6）數據庫是對數據流向的補充說明，是輸入輸出的補充說明，要求詳細描述各數據的對應關係（一對多...），是如何滿足需求之間的關聯關係，主外鍵說明。最好將之列爲數據字典，進行額外的專題說明；
（7）說明系統的部署方案，與外部系統之間的接入方案，關鍵事項支持，
設計評審會議的形式：
一般的評審會議，以專家打分評審、首席專家裁決制的形式舉行，這是視具體項目而定。
設計評審的結論
設計評審的結論很重要，一般是通過或者不通過需完善。這對接下來的甲方乙方工作都有很大的影響。