免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2016 | 回复: 0

用数字解释软件开发的8个为什么 [复制链接]

论坛徽章:
0
发表于 2013-01-31 15:02 |显示全部楼层
软件开发,尤其是信息管理类软件的开发,失败率非常高【第1个为什么】

中国尤其突出,因为中国的甲方、用户特别牛

自己则比较幸运,做过的这些项目和系统,基本都还是比较成功,失败的相当少

要知道这些系统的用户有些是机关单位,有些是银行等金融机构

都是最难伺候的甲方了,居然能让他们满意,除了幸运就多一点后怕了

所以,希望能对还在沼泽泥坑里奋战的同行有所帮助和引起共鸣、探讨



业界一般总结的经验是,要想成功开发管理信息系统,工作量(时间进度)的分布为:

需求分析、设计阶段占60%

编码实现、内部调试占30%

最后联调验收占10%  【第2个为什么】

需求分析、设计是动嘴动脑而已,编码实现才是动手落实

一般都说“领导动动嘴,干活跑断腿”,

为什么“动嘴皮子”的反而比“跑腿杆子”的要工作量大?【第3个为什么】

系统分析师、设计师为什么比程序员“贵”那么多?【第4个为什么】

除了前者资历往往要比较高,可是有必要吗?

不同程序员的工作效能,为什么往往能差几倍到几十倍?!【第5个为什么】

同样的项目,不同人、团队实现,所需的时间也往往能差几倍到几十倍?!【第6个为什么】

为什么软件的错误,发现越早,修改的代价就越低。

发现修改的早、晚导致的工作量不同,往往能差几倍到几十倍?!【第7个为什么】



这么多“为什么”!有些“为什么”其实是其它“为什么”的原因,而最终的根源只有2点:

1、软件系统的功能,往往是很多步骤、环节组合而成的

每个环节都有多种潜在的不同做法,不连贯起来、系统性地看,很难判断哪一种做法就是本环节最佳的做法

2、用户在看到、使用到具体的系统、每个环节前,无法提出完整准确的需求意见

哪怕这个系统将由他自己使用,他以前也按传统、手工模式从事着同样的业务



由根源1可以得知,假如一个系统有10个环节,每个环节有2种做法供选择(这已经是很理想的情况了)

那么这个系统就有2^10=1024种选择(每种选择都是长度为10的路径),

而用户真正想要的选择只是其中一种:10个环节都选对做法了的情况(路径)。

这就能解释【第1个为什么】了:一千条路径里面只对了一条!

当然,开发者根据粗略的需求,替用户做的判断,也不是每个环节都是正好选错了的,

所以成功率由理论上的1‰“猛升”到现实中的5%至40%



正是“领导动动嘴,干活跑断腿”,

所以,开发者希望能实际干活跑腿前,能把用户的需求确定下来,

免得用户嘴巴乱动,开发人员跑断腿也跟不上

所以,开发前做好需求分析和功能设计,不是闲得没事的结果

而是血的教训和现实的逼迫



但是,根源2决定了没法直接从用户嘴里得到正确的路径!

即使用户很想配合,也没有用——人之常情,

所以,不能希望用户正好是合格的需求分析师

怎么办,只有开发者把这10个环节一一分解,逐个环节地展开每个可能的选择

同时,为每种选择举一个【典型示例】,说明选择它会有什么样的特别效果、影响

与其他选择的区别在哪里——不够典型就无法区分,用户的判断也就随意了

用户面对具体环节里的所有选择了,才能发挥他作为业务专家的作用:

哦,这个环节我是希望第一个做法,而不是第二个做法!

当然,前提还得是:具体来帮开发者做选择的用户的确是个熟悉业务的人,

而且是个能明白是非逻辑的人,另外,最重要的是他愿意配合!

(最后这个“配合”前提看似废话,其实也是非常难达到的,因为系统做好了,

他作为业务专家、业务骨干的价值、在单位里的地位,往往也就降低了,

有些甚至是浑水摸鱼、损公肥私的机会大大减少了,即使领导要他配合,他也只是阳奉阴违

当然,这不是本话题希望展开的内容了)



需求分析者要做的工作就是把这1024种选择逐个环节地罗列出来

分别配以能说明特征的【典型示例】

并从用户那里得到确认——这种情况下,用户是可以确认了



所以,需求、设计的“动嘴皮子”其实是在“嘴”上跑1000条路径后,

才能从用户那里得到确定的1条正确路径,

“跑腿杆子”则只需要以代码跑出这1条正确的路径!

所以,【第3个为什么】“动嘴皮子”的反而比“跑腿杆子”的要工作量大,

因为两者有相差更大的倍数(1000:1)!

所以,【第2个为什么】需求设计占60%,编码实现占30%

(从此可以反推:如果路径数量相同,“动嘴皮子”和“跑腿杆子”的工作量之比其实是1:500

说明“领导动动嘴,干活跑断腿”这句老话也的确没错)
磨刀不误砍柴工,这句老话在这里也是很好的总结


如果没有先确定唯一的正确路径,可能需要程序员根据自己的理解做判断

这样的选择不是必然错误,也是近半环节会选错

假设7个环节都选对了,也还是在2^(10-7)=8条路径里误打误撞

相当于需要程序员跑腿8遍才能最终得到正确(用户想要)的系统!



同样的项目,有好的系统分析师,总共需要100%的工期

差的系统分析师,就是10%(需求分析、设计)+8x30%(编码)+10%(联调)=260%的工期了!

如果是40个环节,选择对了30个环节,则是:

10%(需求分析、设计)+(2^(40-30))x30%(编码)+10%(联调)=30740%的工期了!

也就是300倍的工期了!显然,这就是《人月神话》里说的沼泽泥坑了!!

(当然,真的返工几遍,有些模块其实可以重用,不一定都要再次实现

但是,设计不好,有些不同的路径,会导致很多模块要彻底推翻)



可见,不同水平的需求分析、设计人员,决定了工期差几倍到几十倍!【第6个为什么】



系统分析师能在事先一步步诱导用户,根据粗略、零碎的需求,总结汇总得到所有的可能路径

并附注以对应的【典型示例】,让用户看到不同选择的结果差别

再一步步让用户配合进行选择、排除、确认,得到正确的路径

往往在需求获取、确认的过程中,系统分析师就已经成为比用户还精通业务的行业专家了

在【典型示例】的寻找和验证过程中,已经完全了解了业务发展变化所有趋势和结果

因为他们逻辑性强、思维慎密,既善于沟通探讨、又善于整理归纳

这样的人,比只需根据正确路径写出实现代码的程序员“贵”很多,有什么奇怪的?【第4个为什么】



当然,在中国国情下,很多小的项目,或者大项目的很多环节也分析得没那么精确

很多时候,往往需要程序员发挥系统分析师的作用,由他们自行进行小的、局部的路径展开和确认

这种展开和确认,与正规的需求分析其实没什么本质差异,同样有覆盖面、正确率的问题

所以,即使编码水平相同,分析能力决定了不同程序员的工作效能差几倍到几十倍!【第5个为什么】



同样,发现修改的早,需要修改的只是“动嘴皮子”,发现修改的晚,需要修改的就是“跑腿杆子”了

根据上面的推论,“动嘴皮子”和“跑腿杆子”的工作量之比其实是1:500

所以,它们能差几倍到几十倍也不足为奇了!【第7个为什么】

(需求、设计)差之毫厘,(开发、实现)谬之千里

——中国古话用在现代的软件开发里,居然也这么恰如其分,真的是有点不可思议

可能很多事情,抽象到了终极的程度,其实就是一个哲学问题了

它就不分时代、不分国界、不分行业了



另外,不知道大家注意到没有,上面的工作量和工期,有点混用

这也是软件开发的另一个特点了:

人多不一定有用(减少工期),很可能反而增加工期【第8个为什么】

也许,严格一点应该说是中国大多数小型开发团队的特点了

这个特点,也是因为需求分析、设计的普遍低水平

如果分析、设计做好了,路径明确了,的确是可以多人并发编码,也就没这个特点(缺点)了

但是,理想是丰满的,现实是骨感的

分析、设计没做好,才导致编码工期远远超出30%,这时再来加人,新人需要设计者从头介绍项目情况

而且因为模块间耦合度高(分析没做好,设计也一般),还需要已有程序员停下工作介绍复杂的接口机制

甚至时不时共同修改接口。。。。





上面,都只是示例化地比较了各种悬殊的差异产生过程

证明了需求分析、设计工作的重要性,

我们如何具体地做到把需求设计做成功?

从上面的分析,也容易得到:

1、各个环节想清楚,不要遗漏

2、每个环节的每种可能的做法不要遗漏

3、通过构造【典型示例】,为可能的做法增加效果说明

4、设计好环节间的耦合、传递、协作关系

1、2、3要求分析师逻辑性强、思维慎密

这时如果遗漏了,到编码时或使用时才发现,很可能不仅仅是增加做法就行了

而是需要前后环节都跟着改,运气不好,甚至原来的模式都无法满足这个“新冒出”的需求,

需要重新设计部分甚至全部的模式!

对于如何加强这3项工作,基本有2个工具,后面具体介绍

4主要受1、2的限制,更多是设计了,基本靠设计师的基本功了



工具1:思维导图工具(如xmind、freemind、mindmanager)

多个环节-多种候选,就是很典型的多层次、多分支的“决策”树

没有专门的层次编辑、展示工具,很容易遗漏层次或分支

在罗列完成后,根据用户的判断,分析师能当场方便地做出调整(増、删、改、移分支及层次)

或者基于Treeview的层次树形编辑工具

我自己都做过一个: http://xq.com.nu/?app=mytree

工具2:快速开发工具

经常听到:语言不重要,业务逻辑才是最重要

但是语言决定了:你能不能把主要的精力花在实现业务逻辑上

(差的语言让你不得不把小半甚至多半的精力花在基本的字符串操作、对象操作、界面控制上了)

且慢!不是需求分析吗?怎么又说到编码实现了?!

对,用户要看到东西才能确定你想的做法对不对,你不能给他看,他自然就无法判断

当然,绝大多数开发平台、语言、工具是无法做到:

在需求分析时就让用户有“系统”可以“运行”起来“使用”的

那就没办法,老老实实在文档里写吧,再图文并茂也不如用户能直接交互的

有工具可以做能交互的原型,但是,最好是能当着用户的面,针对用户的意见直接修改

因为用户此时的意见仍然不一定对,只有(低成本、快速地)真的把他的意见实现了

他看到了不合理的地方,才会发现自己真的错了(当然,前提也是他不是死要面子的人)
delphi就是最高效的win32桌面应用快速开发工具,没有之一,不但开发快速,运行也快速(意外)
只是已经多年不再流行了
实在没有快速开发能力,就需要【典型示例】了,
之所以一直强调典型,就是要求这个示例能明确区分自己和其他选择的不同后果

这样用户看了结果才能知道哪个选择才是自己想要

注意,这种示例不是UML里的用例图(User Case),除非你的用户是同行,能接受用例图

有了这些,管理软件的开发应该不再是噩梦,MIS的成功率应该也会大幅攀升
同行们也可以有真正的舒心日子了

首发于:
http://blog.csdn.net/sz_haitao/article/details/8547210

补充(下面就是利用层次工具编辑所得)
├1、需求不一定都是一条路径
│├的确,需求里的某个环节可能就是5种做法里同时支持3种
│├不同的前提下对应选择不同的做法
│├这些不妨碍分析师的工作,都是最基本的
│└单路径只是一种简化的形象说法
├2、需求,比复杂更可怕的是老变
│├简介
││├的确,用户越强势,需求越是容易变
││└所以,中国这种情况是很普遍的
│├原因之一
││├但是,很多“变”,其实是因为分析师预先没罗列到
││├以至于用户根据使用情况遇到了,不得不后期加进去
││└如果前期已经考虑到了,就不存在“变”了
│└原因之二
│ ├有些“变”的确是当时的需求之外的
│ ├但是,如果分析师真的全盘了解了用户的情况
│ ├自然应该比用户更深远地想到不久之后的发展情况
│ ├在系统里增加扩展余地或直接预留、实现
│ └这样,那些“变”也不算是变了
└3、需求,比老变更可怕的是矛盾
 ├这个的确也是最棘手的,也是很常见的
 ├因为用户其实是一个多层次的群体
 ├最简单就有领导和员工,他们的需求就是对立、矛盾的
 │├领导希望的是管理、监控、统计越完善越好
 │└员工是希望监控、约束、工作量越少越少
 ├这种情况,顾了领导就是“害”了员工,顾了员工就无法满足领导
 ├唯一的解法就是利用IT带来的替代机械、重复劳动,来缓解员工的工作量、出错率
 └从而换取员工对系统带来的新要求的谅解

架构师是负责系统运行的技术模式的选择、创建,行政、市场(项目经理、产品经理的事情)应该不用他分心了。
系统分析师更关键:承接用户,发掘需求,归纳总结,从千万条可能的功能路径里排除大部分,剩下的再征求用户的有效反馈,最后落实到一条功能路径,以便后续的编码实现。
项目经理、产品经理是负责整体项目,更多行政、市场等非技术因素、环节;
系统分析师、架构师则是侧重技术部分的总体把控,其中后者作用可能会少一点:类似的项目、系统,架构其实是可以复用、照搬的;而需求则是不同客户都不尽相同的,除非是SAP这样的软件商,可以店大欺客。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP