信息系统设计评审的工作该如何开展
摘要：由乙方出具设计方案的大中型的信息化系统，通常会组织较为正式的设计方案评审会，一方面意味着甲方基本认可乙方的方案，另一方面意味着乙方将对照项目目标勾画出具体的框架，并从此开始围绕这个框架而开展具体的开发建设工作。那么，如何做一个有意义的设计评审，将是本文关注的重点。
问题一：为何需要设计评审？
设计评审不是走过场的讲讲浓缩的理念，回答评审专家的问题，更不是专题讨论会，而是一场对之前所进行的设计工作的认可会。作为甲方，需要在设计方案中得到乙方较为正式的总结和叙述。而作为乙方，需要向监理和甲方汇报设计工作，并得到他们的正式认可。设计评审的结论，作为设计阶段的收尾工作内容，直接定调设计工作是继续完善，还是可以过渡到开发工作。因此，设计评审工作，是项目建设中必不可少的环节。
问题二：如何做一个有意义的设计评审？
一般的设计评审，分为两大类，一种是只有乙方的设计师们参加的评审，专注于技术论证；另一种是项目组组织的设计评审，评审专家由甲方单位负责组织协调，大致有甲方项目经理、甲方业务专家、甲方技术专家、外聘专家等，而参与设计评审会的人大体上会有监理和乙方的相关人员。本文关注的设计评审主要是后者。
设计评审会的参与人员及前期工作：设计评审会，参与评审的专家一般是三到七人，此外监理和乙方人员若干。一般，需要在乙方做完架构设计论证、功能设计论证、UI设计论证、接口设计论证、数据库设计论证、存储方案设计论证、网络方案论证等分步工作后，才可以开始真正意义上的项目设计评审会。
设计方案中写一些什么内容：一般从系统架构开始，逐层分解，讲述系统结构、流程和功能，并在专题章节中，写出UI模型、接口、数据库、系统存储和网络方案、系统上线方案及应急预案。在提交的这些内容中，是将前期各设计论证会议的成果总结浓缩成整体的方案，围绕甲乙双方的合同中提及的项目目标而撰写的，章节中要求体现出回答了合同要求的哪些章节内容，以便让各方知道，设计方案覆盖了合同约定的项目目标。此外，设计方案需要就系统的性能问题、安全问题、可靠性问题、易维护性问题，对可能存在的系统崩溃点进行分析说明，并详细说明有哪些应对措施。若是升级改造项目，在设计文稿里面还应该体现系统的切换方案。
设计评审会前后各方的协调工作：
（1）评审前：甲方协调评审专家参加会议，以及会议组织工作，监理负责协调确定会议的议程及时间、地点、出席人员等信息，乙方负责提交设计方案及评审会议材料；
（2）评审中：甲方申明评审会议的意义和会议议程，并评审方案，监理负责记录会议过程和内容，乙方负责陈述设计方案、回答相关问题；
（3）评审后，甲方负责总结评审成果，下定会议结论，监理负责跟踪评审结论的执行情况，乙方负责同步后续跟进计划。
设计评审过程中关注哪些要素：
（1）从顶层架构设计开始，逐步说明系统架构分几层、每一层的设计依据等信息。设计依据一般来自合同要求或者是IT最新技术；
（2）需要对需求分析产生的功能进行分类说明，进而进行功能分层的设计介绍、功能点的性能指标进行说明；
（3）需要对应用层及面向用户的终端深化设计作特别介绍，是如何满足用户提出来的这类型需求的；
（4）需要对接口结构、输入输出项、应用场景、处理效率指标进行详细说明；
（5）需要对某些采购的产品选型进行说明，为何选择这些工具、模块、软件；
（6）数据库是对数据流向的补充说明，是输入输出的补充说明，要求详细描述各数据的对应关系（一对多...），是如何满足需求之间的关联关系，主外键说明。最好将之列为数据字典，进行额外的专题说明；
（7）说明系统的部署方案，与外部系统之间的接入方案，关键事项支持，
设计评审会议的形式：
一般的评审会议，以专家打分评审、首席专家裁决制的形式举行，这是视具体项目而定。
设计评审的结论
设计评审的结论很重要，一般是通过或者不通过需完善。这对接下来的甲方乙方工作都有很大的影响。