软件设计评审检查单

 

软件设计评审检查单

很多企业在做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
类的访问权限是否合适?

http://blog.csai.cn/user1/15522/archives/2008/21386.html

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值