软件设计评审检查单
2012-05-21 15:44
176 查看
很多企业在做CMMI 3级,都要求了项目组要写设计文档,做设计评审。按Watts S. Humphrey的建议,设计评审的工作量要大于设计工作量的1/2。很多企业也做了设计评审,但是很少发现实质性的问题。经过我的分析,发现缺少设计评审的检查单是其中一个很重要的原因,设计评审时专家使用的检查单是企业设计经验的总结,是企业的财富,代表了在企业里软件设计质量的价值观。而我看到的多个企业的设计评审检查单,要么是过于理论,要么纯粹是对设计文档格式的检查,都很难帮助评审专家真正的发现问题,这实际上是典型的“形式上达到了模型的要求,但实际上却未获得价值”,这种现象如果持续久了,势必会降低大家做设计评审的积极性,难以使技术评审成为企业的文化,反而助长公司的形式主义。
于是根据我对OOD的理解,设计了如下的检查单,在此检查单中,所有的数字其实可以根据公司的实际情况进行调整,所有的检查项回答为否也并非代表一定存在问题,需要进行专家判断。这些检查项背后隐藏了OO设计的一些基本原则。
序号检查项
//需求
1所有的功能需求与非功能需求是否都体现在了设计中?
2在设计中是否增加了不必要的功能?是否为未来的变更进行了过度设计?
// 概要+详细
3类的属性是否超过了公共方法的个数的2倍?
4类提供的公共方法是否超过了7个?
5某个类的方法是否即执行了修改又执行了查询?
6方法的参数是否超过了3个?
7每个方法估计的规模是否超过了200行代码?
8类依赖的对象是否超过了5个?
9类继承层次是否超过了6层?
10是否有的子类并非父类的特殊种类,而是父类的角色?
11是否存在某个基类不是抽象类?
12继承自非抽象类的关系是否合适?
13是否存在某个接口,某些客户仅仅使用其部分方法?
14是否需要在运行时刻判断对象的类型?
15类的访问权限是否合适?
于是根据我对OOD的理解,设计了如下的检查单,在此检查单中,所有的数字其实可以根据公司的实际情况进行调整,所有的检查项回答为否也并非代表一定存在问题,需要进行专家判断。这些检查项背后隐藏了OO设计的一些基本原则。
序号检查项
//需求
1所有的功能需求与非功能需求是否都体现在了设计中?
2在设计中是否增加了不必要的功能?是否为未来的变更进行了过度设计?
// 概要+详细
3类的属性是否超过了公共方法的个数的2倍?
4类提供的公共方法是否超过了7个?
5某个类的方法是否即执行了修改又执行了查询?
6方法的参数是否超过了3个?
7每个方法估计的规模是否超过了200行代码?
8类依赖的对象是否超过了5个?
9类继承层次是否超过了6层?
10是否有的子类并非父类的特殊种类,而是父类的角色?
11是否存在某个基类不是抽象类?
12继承自非抽象类的关系是否合适?
13是否存在某个接口,某些客户仅仅使用其部分方法?
14是否需要在运行时刻判断对象的类型?
15类的访问权限是否合适?
相关文章推荐
- 软件设计评审检查单
- 软件需求设计评审的八项要点需注意
- 05-软件XX(设计方案、需求、概要...)评审报告
- 软件需求设计评审的八项要点需注意
- 软件测试的艺术(2)代码走查,检查与评审
- 使用意法的STM32CubeMX工具软件进行系统设计和检查(草稿)
- 软件需求设计评审之八项注意
- 软件需求设计评审之八项注意
- 软件需求设计评审的八项要点需注意
- 软件需求设计评审之八项注意
- 软件需求规格说明书评审检查单模板
- 软件项目计划时常犯的一些错误, 项目计划评审时的检查点(checklist), 成功进行软件项目策划的基本要点
- 软件测试技术---代码检查,走查与评审
- 软件测试技术---代码检查,走查与评审
- 数据库设计评审检查单
- 软件项目设计和开发评审指南
- 软件需求设计评审之八项注意
- 软件需求设计评审之八项注意
- ubuntu更换源解决--“下载软件仓库信息失败,检查您的internet连接”
- OO系统设计师之路--设计模型系列(1)--软件架构和软件框架[从老博客搬家至此]