motogp铃木车队25号:ERP监理方法系列④：概要详细设计阶段的监理工作

ERP监理方法系列④：概要详细设计阶段的监理工作
[收藏此页] [打印]
作者：北京利玛信息技术有限公司王希跃 黄岳  2007-01-08
内容导航：
设计监理总则 第1页： 设计监理总则 第2页： 概要设计的评审 第3页： 详细设计的评审
【ERP监理方法系列导读】
ERP监理方法系列①：ERP监理的目标和内容
ERP监理方法系列②：ERP项目准备阶段的监理ERP监理方法系列③：企业调研、需求分析阶段的监理工作
ERP监理方法系列④：概要详细设计阶段的监理工作
ERP监理方法系列⑤：编码、测试阶段的监理工作ERP监理方法系列⑥：实施阶段的监理工作
ERP监理方法系列⑦：验收阶段的监理工作
【IT168 专稿】软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列的设计质量的评审，以便及时发现和及时解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。
设计监理总则
软件设计监理的基本准则包括： 审查提交的文档是否齐全，审查文档编制与描述工具是否符合规范。确定承办单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，评价软件设计方案与数学模型的可行性，评价接口设计方案和运行环境的适应性，审查软件集成测试计划的合理性和完备性，审查数据库设计的完备性和一致性。并确定该阶段文档能否作为详细设计的依据，决定可否转入详细设计阶段。确认软件详细设计文档的内容符合软件编码的要求。
设计阶段中监理单位要尽可能与业主单位协调配合工作，听取业主单位从业务角度出发提出的对开发方设计的意见。监理单位主要从文档的规范性、可实施性出发，以国家相关标准为依据，从软件工程学的角度对承建单位提出意见与建议，配合业主单位工作，敦促承建单位做好工程项目的设计工作。在设计阶段，监理单位主要针对需求的覆盖性及可跟踪性、模块划分的合理性、接口的清晰性、技术适用性、技术清晰度、可维护性、约束与需求的一致性、可测试性、对软件设计的质量特性的评估、对软件设计的风险评估、对比情况、文档格式的规范性等几个方面进行评审。在此过程中，业主单位也需要对设计文档做检查，主要在功能设计是否全面准确地反映了需求、输入项是否完全与正确并符合需求、输出项是否符合需求、与外界的数据接口是否完全与正确并符合需求、各类编码表是否完全与准确并符合需求、界面设计是否符合需求、维护设计是否符合需求、各类数据表格式和内容是否符合要求、是否存在其它有疑问的设计等几个方面进行核查。
设计的评审内容
（1） 可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否复盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。
（2） 接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。
（3） 风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
（4） 实用性：即确认该软件设计对于需求的解决方案是否实用。
（5） 技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。
（6） 可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
（7） 质量：即确认该软件设计是否表现出良好的质量特征。
（8） 各种选择方案：看是否考虑过其它方案，比较各种选择方案的标准是什么。
（9） 限制：评估对该软件的限制是否现实，是否与需求一致。
（10） 其它具体问题：对于文档、可测试性、设计过程，……，等等进行评估。
在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能、以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。
McGlanghlin给出在将需求转换为设计时判断设计好坏的三条特征：
① 设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
② 设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
③ 设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
以上三点就是软件设计过程的目标。为达到这些目标，必须建立衡量设计的技术标准。
① 设计出来的结构应是分层结构，从而建立软件成份之间的控制。
② 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
③ 设计应当既包含数据抽象，也包含过程抽象。
④ 设计应当建立具有具有独立功能特征的模块。
⑤ 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
⑥ 设计应能根据软件需求分析获取的信息，建立可驱动可重复的方法。
软件设计过程根据基本的设计原则，使用系统化的方法和完全的的设计评审来建立良好的设计。
一、概要设计的评审
软件概要设计监理的目的是对软件概要设计有关内容（重点是软件的结构、软件的功能、软件的结构、接口设计、接口关系等）、概要设计过程、概要设计活动、文档格式进行审查，确定承建单位提出的软件总体结构设计是否实现了软件需求规格说明的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件详细设计的前提和依据。
＃
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
是否所有的假设、约束、策略及依赖都被记录在本文档了？
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
是否所有的TBD的影响都已经被评估了？
是否仍存在可能不可行的设计部分？
是否已记录设计时的权衡考虑？ 该文件是否包括了权衡选择的标准和不选择其它方案的原因？
依从性
是否遵守了项目的文档编写标准？
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
可行性
从进度、预算和技术角度上看该设计是否可行？
是否存在错误的、缺少的或不完整的逻辑？
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化？
是否还有任何需要的但还没有定义的数据结构，反之亦然？
是否已描述最低级别数据元素？是否已详细说明取值范围？
功能性
是否对每一下级模块进行了概要算法说明？
所选择的设计和算法能否满足所有的需求？
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）？
是否已描述界面的功能特性？
界面将有利于问题解决吗？
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致？
是否所有的界面都提供了所要求的信息？
是否已说明内部各界面之间的关系？
界面的数量和复杂程度是否已减少到最小？
可维护性
该设计是否是模块化的？
这些模块具有高内聚度和低耦合度？
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？
性能
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）？
可靠性
该设计能够提供错误检测和恢复（例如：输入输出检查）？
是否已考虑非正常情况？
是否所有的错误情况都被完整和准确地说明？
该设计是否满足该系统进行集成时所遵守的约定？
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
1
二、详细设计的评审
软件详细设计监理的目的是对软件详细设计有关内容（重点是软件的算法、数据结构、数据类型、异常处理、计算效率等）、详细设计过程、详细设计活动、文档格式进行审查，确定承建单位提出的软件详细设计内容是否实现了软件概要设计的要求，确认是否满足要求；给出是否符合要求的结论；确定其可否作为软件编码的前提和依据。
＃
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件 （大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
是否所有参数和控制标志由已描述的单元传递或返回？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例如过程时间和规模都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出有意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）？
是否所有的逻辑都能被测试？
是否已描述测试程序、测试数据集和测试结果？
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求？
是否所有的设计决定都能追溯到权衡考虑？
单元需求是否都能上溯到更高级别的文档？ 更高级别文档的需求是否已经在单元中体现？
1