概要设计的监理.docxVIP

PAGE PAGE 1 GB/T19668.5—2018 概要(结构)设计的监理 监理机构应督促承建单位开展概要(结构)设计活动，审查承建单位的概要(结构)设计文档。监理服务内容和要点如下： 监理机构应督促承建单位按照计划的要求开展系统概要(结构)设计活动。 监理机构宜配合业主单位制定相应的业务指标评价体系,监督承建单位对系统结构开展合理的方案设计。如适用,监理机构宜组织业主单位和承建单位按照计划的要求开展业务流程再造、业务持续改进、信息资源利用的设计活动。 监理机构应要求承建单位提交系统概要(结构)设计文档,概要(结构)设计文档应符合相关标准要求。 监理机构应组织业主单位和承建单位对系统概要(结构)设计文档进行检查,形成概要（结构）设计检查表(参见表 A.4)。 监理机构应协助业主单位以审核、确认、联合评审等方式对系统概要(结构)设计进行评价,评价时要考虑下列准则： 与承建合同的可追溯性、一致性； 与业务目标的符合性； 系统需求的可追溯性、一致性； 所使用的设计标准和方法的适宜性； 软件项满足指定需求的可行性； 基于信息资源规划和业务指标评价体系的可测试性； 业务流程再造、业务持续改进、信息资源开发的可行性； 运行和维护的可行性。 监理机构应监督承建单位及时解决系统概要 结构设计中发现的问题和不合格项并提出监理意见。 表A.4 概要(结构)设计检查表 工程名称 系统名称 业主单位 承建单位 监理单位 检查依据 检查类目 检查内容 检查结果 备注 清晰性 是否所设计的架构,包括数据流,控制流和接口,被清楚地表达了 是/否 是否所有的假设、约束、策略及依赖都被记录在本文档了 是/否 是否定义了总体设计目标 是/否 完整性 是否所有的以前的 TBD(待确定条目)都已经被解决了 是/否 是否设计已经可以支持本文档中遗留的 TBD 有可能带来的变更 是/否 是否所有的 TBD 的影响都已经被评估了 是/否 是否仍存在可能不可行的设计部分 是/否 是否已记录设计时的权衡考虑? 该文档是否包括了权衡选择的标准和不选择其他方案的原因 是/否 依从性 是否遵守了项目的文档编写标准 是/否 一致性 数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致 是/否 该设计是否反映了实际操作环境(硬件、软件、支持软件) 是/否 可行性 从功能、成果、进度、预算和技术角度上看该设计是否可行 是/否 是否存在错误的、缺少的或不完整的逻辑 是/否 数据使用 所有复合数据元素、参数以及对象的概念是否都已文档化 是/否 是否还有任何需要的但还没有定义的数据结构,反之亦然 是/否 是否已描述最低级别数据元素? 是否已详细说明取值范围 是/否 功能性 是否对每一下级模块进行了概要算法说明 是/否 所选择的设计和算法能否满足所有的需求 是/否 接口 操作界面的设计是否有为用户考虑(例如：词汇、使用信息和进入的简易) 是/否 是否已描述界面的功能特性 是/否 界面是否有利于问题解决 是/否 是否所有界面都互相一致,与其他模块一致,以及和更高级别文档中的需求一致 是/否 是否所有的界面都提供了所要求的信息 是/否 是否已说明内部各界面之间的关系 是/否 界面的数量和复杂程度是否已减少到最小 是/否 可维护性 该设计是否是模块化的 是/否 这些模块是否具有高内聚度和低耦合度 是/否 是否已经对继承设计、代码或先前选择工具的使用进行了详细说明 是/否 性能 主要性能参数是否已被详细说明 是/否 可靠性 该设计是否能够提供错误检测和恢复 是/否 是否已考虑非正常情况 是/否 是否考虑了网络、数据安全 是/否 该设计是否满足该系统进行集成时所遵守的约定 是/否 易测性 是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的 是/否 该套系统是否能用增量型的方法来集成和测试 是/否 可追溯性 是否各部分的设计都能追溯到需求说明书的需求 是/否 是否所有的设计决策都能追溯到原来确定的权衡因素 是/否 所继承设计的已知风险是否已确定和分析 是/否 业主单位代表签字： 年 月 日 承建单位代表签字： 年 月 日 监理机构代表签字： 年 月 日 XX公司规范 1.4概要设计阶段的质量控制 1. 系统分析 系统分析是进入软件系统设计阶段的首先要做的工作。监理单位要求承建单位做系统分析时包括确定问题域,对需求建模即快速原形系统,建立分析对象模型,系统分析合并。 2. 系统设计（概要设计） 概要设计，即将软件需求转化为数据结构和软件的系统结构，一般包括数据设计和系统结构设计。其中数据设计侧重于数据结构的定义，系统结构设计定义软件系统各主要成份之间的关系。 在承建单位进行概要设计的过程中，监理单位需要监督以下方面： （1）制定规范 在进入软件开发阶段之初，首先