论设计与编程的关系

2008-04-09 04:02:36来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

  在IT领域从业六年中,大大小小的项目已担负了十几个。从项目行业上看,复杂的有大型ERP系统、银行贷款系统,相对简单的有OA系统、人力资源系统。从性质上看,既有解决实际需求的应用系统,也有属于技术攻关的科研项目。从这些项目的开发、管理中,有很多的感想,我认为是非常宝贵的经验。比如如何看待设计与编程,如何用好特殊程序员等问题。在项目管理上采取的方式是否是正确的、最佳的,项目开发成本有几倍、几十倍的差别。

  在一个系统的开发过程中,作为项目管理者,经常要碰到一个要仔细衡量又极难把握的问题:设计与编程究竟各要花多少比例的时间?遇到这样的问题有时是由于项目组的成员水平参差不齐,有很多程序员只能开发简单的定义明确的程序,而不能就一个问题进行解答性的设计,这使得项目管理者常常考虑安排专门的人来进行设计;有时是由于项目管理者主观就认为设计与编程是相互独立的工作,理应该分配不同的人来承担。做设计的认为设计工作要占60%以上的工作量,是主要工作,做编程的认为编程工作要占80%以上的工作量,才是真正主要的工作。到底怎样的比例才是公平的呢?我们很难作出回答。

  软件生存期在大部分项目中可以概括为如图的形式:

  

  毫无疑问,开发过程的成本是项目的核心成本,其成功与否实际就代表了项目的成功与否。开发过程中最主要的工作就是设计与编程。

  怎样确定设计与编程的工作量

  确定的可衡量的工作量是文字,设计成果是通过文档表示的,程序是由代码组成的,两者的共同点就是由文字来表示成果。一个系统,设计文挡比如是10万字,编写的程序代码是90万字(不包含通过开发工具生成的代码),则可明确衡量的工作量之比是1:9。肯定有很多人口头上反对这种衡量方式,认为这是机械的、呆板的。如果只计算最终通过确认的设计文档、通过测试验收的程序代码,会发现这种方式常常是最客观地反映了项目组各成员的工作业绩。

  做设计要思考,做编程同样需要思考,而且还要反复调试,可以说写同样多的文字,编程需要的时间决不比设计需要的时间少。公司招聘设计人员与招聘编程人员花的代价是不相同的,作为设计人员自然要求具有设计的水平和能力,作为编程人员同样要求具有编程的技术和能力。所以两者不能说自己的工作性质不同,写同样的文字需要的时间不同。否则,企业就太亏了。

  从经验看来,在一个项目中,如果设计与编程人员都努力工作,没有松懈的时间的话,设计人员与编程人员的比例大概为1:5,设计人员与编程人员的个人工资比例大概是3:1,项目中工作时间之比大概是1:5。可计算设计与编程的时间成本之比为:

  1*3*1:5*1*5=3:25约为1:8的比例

  这个比例应该是比较公平符合实际的。而很多企业的软件项目盲目夸大设计工作的比重,如人员比例安排为1:3,工资比例为3:1,工作时间比例为2:1,两者最终成本之比为:

  1*3*2:3*1*1=6:3=2:1

  这就体现了不少人认为的设计占绝大比重的观点。而实际上,按这种比例带来的结果是,设计人员轻松得要命,但表现出来也很累,因为他们要不断地催编程人员的进度、等编程人员的结果。而编程人员却累得要命,拼命加班加点,还是很难应付过来,并且到头来还老挨设计人员的教训。

  设计所需的工作时间实际是很少的,因为它主要在于设计者的经验、文字表述,而不需要调试。一个大型的ERP项目,如果设计者得其人,一人即够,而编程却需要上百人--真正的花时间的工作是编程与调试。为什么一些企业有那么多IT失败的项目,一个原因就是他们盲目的看重了设计的比重,在设计上投入了总预算的60%以上的成本,结果发现真正的主体工作是编程,到那时才发现剩下的预算成本已远远不够。

15f

  边设计边编程是提高效率的捷径

  在设计与编程上,用得上一句老话:说一千句,不如做一件。实际上设计与编程是很难分开独立进行的,首先光做设计而不及早进入编程,项目极可能流产。边设计边编程,甚至以编程催动设计,是使项目成功的捷径。因为只有编程了,才真正明白哪些内容需要设计,哪些是简单的。实际中我们也经常发现,花了好几天工夫设计了一个方案,结果编程者根本不需要理会你的设计,他只要几分钟时间就做好了。

  在一个大型信息系统中,项目经理安排了三个人花了四天时间做一个客户可定制的菜单系统的设计,同时安排一个程序员钻研相关编程上的实现方法,四天后,设计人员拿出了设计,但总还感到不放心,当他们去和程序员交流时,发现程序员已经把菜单系统做好了,实际的功能还超过了他们的设计,这让三名设计者无地自容。如果项目经理据此认为编程工作简单,那必定又大错特错。设计,需要与当时的技术,程序员的水平与经验结合考虑,大部分情况下需要在编程中摸索,才能决定究竟是否需要独立设计,究竟有多少工作量。

  这样说,并不是说设计就不值得一做了,设计仍然是相当重要的,特别对于延续性的开发项目。但我们要看到,有时候,效率、速度是高于一切的,而且,在我们的IT队伍中,有不少程序高手,他们的确能制造奇迹。

  一个朋友告诉我,当他在学校的时候,有一个机会参加了国家重点实验室计算机语音合成技术的研究。在他加入该课题时,课题组已有不少人研究超过一年以上,其中有博士和硕士。他们将设计看得很重,哪怕是汉字音节的录音,都几经计划,并录了好多次。在给他分配任务时,根本没认为他可以为研究项目提供什么帮助,只是泛泛的要他看看书、尝试做一些小程序。设计固然非常重要,但过分强调,就成了研究人员,特别是“主要设计人员”状态松懈的借口,他们可以一周两周漫无边际地翻阅书籍,可以一月两月就某个“重要问题”进行“深入地、细致地”探讨。我们不能指责他们探讨交流不应该,但在那方面花费太多的时间已使得工作效率极其低下,课题进展非常缓慢。朋友参与课题研究后,没有象他们那样先设计然后再编程,而是一开始就编程,有任何一点想法就立即通过程序实现。因为有了想法后如果不实现,就不会有进一步的思考,而实现了则可以非常明确的对前一想法进行修正或进一步往前思考。在研究开发过程中,他也很少与同组人员进行讨论,因为一个明显的理由告诉他,对于不太复杂的问题,有讨论的十分之一时间,自己也能通过程序试验出来了。结果,他只花了三个月时间,就将语音合成的主要技术问题如音节/音素合成、词组处理、多音字处理、语音数据压缩、句式处理都解决了,并开发出了一个简单的但具备完整功能的语音合成程序。这在其他人看来是不可思议的。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:主流测试工具介绍

下一篇:TCP/IP通信程序设计的丰富多样性