需求的实践(2)

需求的实践(2)yun_qi_img/c.gif能力和过程
林星 (iamlinx@21cn.com)
2001 年 11 月本文作为这个关于需求的软件工程专栏的第二篇,作者将继续花了一些篇幅来讨论软件工程中的一些基本概念,以求大家能够从整体的角度来理解需求过程。
1、煮鸡蛋的启示
有个英国人学煮鸡蛋,开始,他把鸡蛋放到开水里煮时总会炸裂。他为此想了各种方法,并找到了一个解决方案:在鸡蛋上打个孔。但在鸡蛋上打孔带来了另一个问题:孔打小了,鸡蛋还会裂;孔打大了,蛋清会在它凝固以前流出来。于是,这个英国人给一批鸡蛋分别打了各种不同孔径的洞,并记录下每个鸡蛋孔径的大小。通过这一方法,他找到了一个最合适的大小──既避免了炸裂,又保证蛋清不会流出来。这时,虽然煮鸡蛋炸裂的问题解决了,但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。为了解决这个问题,他又开始尝试煮不同时间的结果,并从中找出最佳的时间长度。最后,他终于找到了一个放之四海而皆准的煮鸡蛋的方法。这个案例对很多中国人来说是个可笑的例子。因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。
从煮鸡蛋这样一个小小的事件上,中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果,而英国人却仔细地把每一个过程细化到最简单,然后按部就班地执行。(管理软件的发展之路 洪奇)
聪明的中国人虽然拥有四大发明,但是对于现代的管理思想,中国人一直没有领会到真谛所在。无论是哪一种的管理方法,过程能力都是特别重要的,虽然生产一件产品的相关人员有千千万万,但是生产出来的产品却只有一种。这种能力并不是从天上掉下来的,是通过制定极为详尽的生产过程规定得到的。在中国接受了ISO的思想之后,这种能力也在国内的制造业中逐渐体现出来。但是在软件行业中,拥有这种过程能力的软件组织仍然是少的可怜,大多数的软件组织奉行的还是一种在八九十年代的个人英雄主义,开发软件单靠个人的力量,能力强的程序员能够成功的完成软件,能力差的则失败。大多数的软件组织中,少数人掌握着代码,他们就是一切,如果他们因为私人原因离开所在的组织,手上的代码则是他们的资本,原有的组织将受到沉重的打击。
中国人热衷于结果,2001年的热点在CMM上,现在还很难说CMM中是不是有一定的泡沫存在,但是可以肯定的一点是,CMM之进入中国软件组织为中国软件工业的发展开创了一个新的时代。中国的软件工业将逐渐摆脱原来的作坊式开发,进入软件工业时代。之所以用软件工业而不用软件产业的原因是希望软件产品能够像工业革命那样进入大规模生产,降低价格的时代。

时间: 2024-05-23 02:45:00

需求的实践(2)的相关文章

需求的实践(3)

需求的实践(3) yun_qi_img/c.gifCustomer Oriented,而不是Program Oriented 林星 (iamlinx@21cn.com)2001 年 10 月软件开发人员总是在困惑为什么软件分明是按照需求做出来的,可是客户为什么仍然不满意.客户总是在困惑为什么软件和自己想要的差距会那么大.这究竟是怎么回事?如何才能把开发人员和客户之间的沟壑填平?本文作为这个关于需求的软件工程专栏的第三篇,将向您介绍这个把客户和开发人员联系在一起的工具

需求的实践(5)(下)

需求的实践(5)细节需求时期(下)和业务建模时期不同的是,我不再花费笔墨讨论需求要如何做,因为做法.注意点和业务建模时期并没有什么太大的区别.而在完整的流程上,像RUP.XP之类的方法学可比我讲的要好的多.因此,我会把焦点集中在我在实际工作中的一些困惑,以及一些思考.1."和其它阶段的关系"的再思考.上一篇的末尾我们简单的讨论了细节需求阶段和其它阶段的关系.对于软件过程的各个阶段,不同之处只是注重的焦点不同而已.在业务建模阶段,我们关注于系统的整体需求:在细节需求阶段,我们更关注于需求

需求的实践(4) 下

需求的实践(4) yun_qi_img/c.gif业务建模时期(下) 林星 (iamlinx@21cn.com)2001 年 11 月和上一篇的理论不同,这一篇文章更注重于实际,举出了在业务建模简短需要注意的一些原则和实践,每一条都来自于实践之中,也都有理论的支持.其中的很多内容更是经过多次的失败才总结出来的.相信大家如果能够理解这些原则和实践的某些方面,至少能够避免重蹈覆辙.原则(Principle)1. 谁才是"上帝" <我们说客户是上帝,是因为客户的重要性,客户占有决定性的

需求的实践(4)

需求的实践(4) yun_qi_img/c.gif业务建模时期(上) 林星 (iamlinx@21cn.com)2001 年 11 月在大规模的需求调研展开之前,有一个重要的工作要做.这项工作在项目中所占的时间跨度非常的小,但是却有非常重要的意义.不同的人.不同的方法对这项工作有不同的描述,在我们的文章中,根据UP的思想,称之为"业务建模".所有的项目都有业务建模时期1. 业务建模是什么 业务建模(Business Modeling),业务建模是一个复杂的过程,对其下一个准确的定义是困

《软件需求最佳实践:SERU过程框架原理与应用》笔记

最近看了这本书,和实际的结合比较紧密,对实际的需求有一定的指导作用,特别市对于国内的特色需求,有很好的指导. <软件需求最佳实践:SERU过程框架原理与应用> 首先从软件需求实践中出现的主要问题和困难入手,指出了改进的主要方向:然后逐一说明了需求定义.需求捕获.需求分析与建模.编写规约.需求验证等需求开发活动的任务.要点和具体手段:并提出了一个可操作性强.易于上手的SERU过程框架,能够帮助读者清晰地了解整个过程,理解各阶段的关键产物和产物之间的关系. 还对包括需求基线.变更管理.需求跟踪在内

用例驱动的需求过程实践

一.需求矛盾 根据CHAO的权威统计,虽然自"软件危机"提出以来,软件工程方法得到了长足的发展与进步,但在去年的软件项目成功率仍然不足30%,绝大多数的软件项目仍然超进度.超成本.而在这些不成功的项目中,由于需求不清晰.需求不完整等方面的因素,占到了60%左右. 根据笔者多年来从事软件需求捕获.分析工作的实践经验,认为造成这一现象的根本原因在于客户与开发人员之间的沟通存在障碍,双方都以自己的角度.自己的专业术语进行沟通,这使得大家并不能够很好地就软件需求达成共识. 由于帮助客户更好地利

需求调研中的5W+1H定律

对于软件的需求调研活动,曾经写过三篇相关的需求管理文章,出发角度是从整体的需求管理过程考虑:在引入CMM(二)需求管理KPA活动的基础上,列举了如何进行需求调研前的需求管理计划活动:在失败的项目中,找出规范和管理软件需求过程的关健点及需求关联的模型架构(这些可以参考以前写过的<CMM需求管理实践经验记录谈>.<从CMM角度考虑需求管理计划>.<如何用CRC模型来确定需求>). 一直以来,感觉自己在经过几个项目试验的基础上对于软件的需求管理应该是有一定的基础和经验了,然而

从项目需求角度,使用纯CSS方案解决垂直居中

原文:从项目需求角度,使用纯CSS方案解决垂直居中  CSS是HTML元素的剪刀手,它极度的丰富了web页面的修饰.在众多CSS常见的样式需求中,有一奇葩式的存在[垂直居中],因为不管是从逻辑实现方面还是从正常需求量来讲,这都没理由让这个需求在实践过程中,显的那么艰难.我们往往需要额外添加标签元素与充满hack味道的属性才能解决,而在涉及到不固定元素尺寸的时候,更显艰难.唉,日子还得照样过,工作还得继续干,这里就从实际需求的角度来归纳一些纯CSS方案.[特别说明,现实中的需求千变万化,请阅者根据

四层架构设计驱动模型在CKM中的实践

写在前面:本文纯属个人想法和http://www.aliyun.com/zixun/aggregation/7335.html">经验总结,如转载请注明出处,如有雷同纯属巧合 (: 1. 一般的架构设计流程 所有的软件开发方法都要解决从需求到实践的转换问题,为了提高软件的质量,前辈们提出了需求分析工程和各种建模技术,但是在需求和设计之间还是很难逾越,也就是说缺乏能够反映做决策的中间过程,于是软件架构设计应运而生. 对于架构设计人们已经提出了许多方法,分类为:工件驱动的方法:用例驱动的法:模