过程VS技术[From selab].docVIP

过程VS技术[From selab] 发信人: qlw (钱五哥), 信区: SoftEng 标 题: 过程VS技术[From selab] 发信站: BBS 水木清华站 (Thu Nov 9 16:16:49 2000) Dave 此文极佳，建议Dave再做一些文字修饰后作为一份永久文档保存。 ----- Original Message ----- From: Dave Wang To: selab@ Sent: Wednesday, November 08, 2000 1:10 AM Subject: Re: [selab] 过程变更 VS 技术变更(胡说几句) all: 作为一个组织如何利用CMM来进行改进，有很多人都在谈。 大家也谈了些，我今天也来谈谈。 （大家知道规程、技术和方法、人员----软件过程铁三角 ----联合构筑了软件过程，这也得到了广泛认同。事实上， 我前一段时间的文章也对规程、人做了一些讨论，然而一 直没有专门讨论工具和技术，虽然不可避免地流露出一些 观点。今天则将重点探讨工具和技术对我们软件开发的影 响。） 首先我坚定地认为：对于我们大多数cmm level 1的企业 来讲，尤其在中国，要进行过程改进，提高质量、提高可 预测性和核心竞争力，提高我们产品开发的信心，CMM实 实在在给出了一条渐进之路----它也体现了软件工业自身 谋求成熟和发展（说白了不就是为了提高软件质量、服务、 成本、时间吗！-----不是短期，而是长期，这才是核心 开发（！）竞争力）所积累的成功经验的大成（注：成功 经验来自很多失败）！ 至于为什么要先spp/spto/scm/rm/sqa/ssm，很多人都做 了解释，但是依然不足以粉碎存在于中国的、大家心中的 “技术（工具）唯上论”和“人唯上论”，它们确实和过 程密不可分，经常难以分开。然而“技术（工具）唯上论” 和“人唯上论”实在对我们太有害了，尤其对中国，这种 思想已经根深蒂固，我们已经受害至深-------真心希望 大家能够通过论坛倾心沟通，尽可能达成共识，并竭你我 之力宣传，粉碎幻想。 CMM是一种工具（然而“好的工具往往被人所误用”----这 实在是至理名言，因为它现在就发生在我们眼前）。技术和 人的作用无疑是极为重要的，然而如果所谓的技术是指： （1）软件分析/设计/开发技术和工具（包括面向对象技术）： 兄弟我曾经是多么狂热迷恋这些内容，十年来也开发了无穷 多程序，专研或苦推过什么ooa/ood/use case use case map/som(系统对象模型)/com/corba orb/multimedia orb/ M-Queue/reuse/pattern/sdl/uml/rup/msf等等等等，也 曾热衷于更多的case工具和solution，不过现在我希望能 够静下心来，做更重要的，用一句话来讲，叫process first! 大家用uml/use case/oo 分析方法，期望把握系统/需求的最稳 定的部分，使系统设计的鲁棒性增强；作大量的努力期望成 为相应应用领域的专家，以更好地把握需求；在技术方案TS 上，为提高性能和开发效率，期望更可能用构件、分布式对 象，分配负载，增加重用-----这可真正是美妙无比的思想啊。 还有更美妙的，就是通过美妙的个人构思就能产生质量。 也有很多人以为这就是软件工程，并期望能够下大力气有所突破， 事实上我们也不是不努力，可是我们的软件就是这么弱！ 大家是不是指望所有的人未来都是系统分析的高手，写垃圾 代码、制造垃圾软件的跛子！------痛苦的是，即使如此， 也仅仅一厢情愿，是梦想。 说是系统分析与设计的高手， 这只是好听点，另一个词叫hacker，因为这些家伙们（注：不 针对任何具体个人）不懂管理（或者以为会用project,知道 pert/gantt就以为懂了管理）、不真正知道过程，其实即使 是分析与设计，对于稍微大点的系统的设计，又何止千疮百 孔。为什么呢？因为系统开发不是小家子工艺品，不是艺术， 不是science，现实是，它永远是一项工程，一项系统工程， 它更多的意味着是在复杂经营环境下的协作。 看看我们现在的问题，其实是大家看看我们的无能(inability) 和