Detailed design 的一些实施中的问题

04-01-02 nova
    

背景:类似外包性质的项目,需求变更很快

问题一 :Detailed Design 应该怎么划?

应该详细到什么级别? 代码级别?是不是做代码的时候,

只参考design既可,无须参考URS?这种非常详细的design是不是在浪费时间呢,

需求变更的太快,过于详细的design 也许是很难维护的

问题二:Detailed Design 是否需要很多人都来做?

前期很多人做的design后来需要进行更新,更新的过程中就发现了大致一样的功能,

两个人实现的不一致,虽然最终都可以实现,但很简单的东西没有必要花费时间去思考另一种实现方案

,design 大家都设计的一样才叫好,并且发现很多错误的design,

我们公司的Detailed Design 都是每个人都参与的,因为每个人的水平及其实现方案不一样,

虽然都有一个共同的标准,但是还有很大的出入的,PL review 也不可能细致的看完每个人的design,

这样就导致了design的不协调性,特别是人多的时候(我们的是6-8个人),后来的别人维护也就更难了,

基本是重新来了解别人的业务,然后重新来画,

个人认为detailed design只需很少的几个协调性强的人(2-3人是很容易沟通的),业务(URS)可以大家分着来研究,

做design的人应该了解

所有的业务(并不是只了解自己画的那部分业务),这样一来分的很清楚了,日后的维护,相信一个人就可以承担

问题三:Detailed Design 是如何version control的?

使用的是rose , 感觉这方面很麻烦的,据说可以使用clearcase来控制,

但听同事说,也是很难控制的,现在的做法,要不是一个人在做,大家在等,或者是个做个的,

最后进行合并,这种方案要不是慢,要不就是丢失一些必要的东西,方法或者方法的注释

希望给些建议,谢谢!

    

banq
2004-01-25 12:31

>问题一 :Detailed Design 应该怎么划?

划分为架构设计和具体功能实现

>问题二:Detailed Design 是否需要很多人都来做?

架构设计由1-2人组成的架构师设计组完成,并且解决具体功能中新技术难题,用新技术完成一个核心功能作为模板,供程序员参考开发其它类似功能。

>问题三:Detailed Design 是如何version control的?

版本控制建议建立在代码级别,架构设计完成也是以代码为标志,也就是类似一般开源代码的1.0版本那样,所以架构师我认为也是要编码的,并且是编码水平非常熟练的那种。