设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

(王咏刚

文档类型：

Adobe Acrobat PDF 文档文档大小：229.46KB

(王咏刚2003年7月)凌波微步II・前言非常高兴能在《程序员》杂志上开辟这样一个专栏.专
栏名称凌波微步II的由来是这样的:我是一个普通得不能再普通的程序员,除了吃饭睡觉、谈情说爱以外,我把大部分时间都消磨在了控制电脑(编写自以为是的代码)和被电脑控制(应付层出不穷的Bug)的辩证关系里.两年前、当我像刘正风一样受了魔教的,打算金盆洗手之时,我下定决心要写一本回忆录来纪念我的程序员生涯这件事最终的结果是,因为生活所迫、我至今也没有兑现金盆洗手的诺言、设想中的回忆录也被我写成了一本据说还算有趣的案例分析教程,就是拙著《凌波微步》一书了.现在大家看到的专栏凌波微步II实际上是《凌波微步》一书的延续、我将在这一专栏中、使用与《凌波微步》大致相仿的体例和风格,继续我的案例分析历程.专栏拟以时间为序,大致依照软件开发的先后顺序,逐期讨论需求,接口设计,算法与数据结构,用户界面设计,开发语言选择,面向对象设计,代码优化,代码安全,测试,调试,用户支持文档,软件发布与维护等12个问题这样一个续集形式的专栏,如果不能叫凌波微步II的话、恐怕就只能赶一回《黑客帝国》的时髦,叫做凌波微步RELOADED了.总的来说,我希望凌波微步II在质量上能够超越《凌
波微步》.但俞平伯先生说过:凡书都不能续、不但《红楼梦》不能续;凡续书的人都失败,不但高鹗诸人失败而已
①.因此,我对专栏的价值并没有太高的奢求,诚如《凌波
微步・前言》中所说:只要它能帮助大家对实际的软件开发过程有个粗疏的概念,大致知道一个程序员在经过了学校和编程教科书的训练以后,还要学习哪些东西才能在项目组里有效地工作,我就非常满意了②.寻找小李飞刀
1 问题引入凌波微步II的传奇将从需求开始.无论你采用何种软件过程模型,在整个软件生命周期中、需求分析和需求管理都是你必须首先关注的事情.从本质上说,需求分析是项目组和客户一同明确,细化需求,并为将来必然发生的需求变更准备充足的文档或记录的过程.请注意,像所有刻板,唠叨的教书先生一样,我将在本文中反复强调一件事:需求总会发生变化,需求管理工作将贯穿项目始终;如果你有幸见过一个从未改变需求的项目,那么恭喜你,你可以立即到卡内基・梅隆大学领取软件工程年度幸运奖了!这里有一个和需求变更有关的案例.一家名叫小李飞刀的航空公司(这当然是一个杜撰的名字,没有谁会愿意乘坐像飞刀一样有去无回的飞机;不过,案例本身倒的确是某个真实事件的演义)要求我公司为其建设一个专供那些代售该航空公司机票的代理商使用的网站,网站名字叫飞刀在线.讨论项目需求的时候,航空公司的项目负责人极为敬业,在短短3天时间里就攒出了一份厚达34页的《需求说明书草案》.草案详细罗列了网站需要提供的代理商园地,新闻中心、实时航班查询,实时天气查询,代理商等五大功能,甚至还提出了对网页布局、背景颜色等细节的要求,其翔实程度让我公司的项目经理倒抽凉气、唏嘘不已.要知道,我们见过的许多客户在提需求的时候根本就不知道他们想采购的是什么样的一套系统!和那些粗放型的客户相比、这家航空公司足可称得上百年不遇的好客户了.在优质客户和优质需求的双重刺激下,项目组很快完成了需求分析工作.值得一提的是,项目组在工作中发扬一不怕丢面子,二不怕扣帽子的厚脸皮精神,拖住客户方的项目负责人死缠烂打,同时使用业务建模,快速原型,情景分析,需求跟踪表,CRC模型,数据流图,UML用例图等几乎所有先进的需求分析技术,发挥Rational RequisitePro等需求管理软件的强劲效能,终于在需求分析结束后获得了一份客户及项目组双方都签字认可的《需求说明书》,文档长度竟然超过了90页!但是,就在项目组顺利完成了分析,设计,开发,测试等关键任务,正全力监控飞刀在线试运行版运行状况的时候,一位航空公司的领导抽空儿亲自感受了一下飞刀在线的使用体验、然后把航空公司负责该项目的人叫来说:网站做得不错.不过,代理商卖机票时难道就不能使用这套系统吗不能,项目负责人回答、我们当初提的需求里没有预售机票的功能.但代理商仍然可以通过原有的UNIX终端出售机票.胡闹!同样是给代理商提供服务,为什么不能把预售机票也集成在同一个应用界面里呢在飞刀在线上查询了航班信息之后,自然就可以出售机票了嘛!记住,我要看到一个统一的系统.就这样,我们公司那位可怜的项目经理碰到了一次让人头疼的需求变更.问题的症结在于,要在飞刀在线系统中增加机票预售功能并不像想象中的那么简单:与航班查询不同、为了保证交易完整性,所有机票预售交易都必须由航空公司的UNIX主机直接处理,代理商传统的做法是通过字符终端登录到UNIX主机、再使用主机上的预售程序售票,除此以外,UNIX主机并没有为其他系统提供任何与售票相关的应用接口(目前、国内机票代理商大都使用UTS终端连入中国航信的UNISYS主机完成机票预售交易,实际的系统架构比较复杂.本文属案例性质,为简便起见、文中有关系统架构的介绍与国内民航系统多有出入,还望业内人士海涵).也就是说,要想为飞刀在线增加售票功能,多半要修改UNIX主机上的售票程序,使其能通过RPC,CORBA或者随便什么通信方式,为飞刀在线网站的We b服务端代码提供售票接口.我公司的项目经理和航空公司的项目负责人为这件事争论了整整一个星期.我公司的项目经理认为、航空公司随意更改已签字的需求,这种做法本身就缺乏严肃性,如果真的要改也不是不可以,但前提是航空公司必须允许项目组修改UNIX主机上的售票程序;航空公司一方面坚持要在最短的时间内增加售票功能,另一方面又坚决不同意项目组修改主机程序的请求,因为主机上的程序已经稳定运行了五、六年了,在没有充足时间开发,测试的情况下,对售票等核心程序所做的任何一处改动都有可能引发灾难性的后果.此时,项目已经临近尾声,双方仍就新的需求争执不下,谈判濒临破裂.就在双方代表都已的情况下,我们的项目经理
突然灵机一动:不就是要把售票功能集成在飞刀在线的界面里吗这太简单了,只消在客户端,也就是浏览器的界面里嵌入一个ActiveX控件,这个控件通过Telnet方式远程登录到UNIX主机、并模拟字符终端的输入输出、运行主机上的售票程序,这不就行了吗我不知道大家对这个方案的感想如何,我们的项目经理当时被自己的聪明才智感动得涕泪横飞,他义无反顾地把这种嵌入仿真终端控件的创意称为借尸还魂.说干就干,项目组来不及征询客户的意见、仅用两周时间就开发出了一个几乎与NetTerm功能一样强大的ActiveX控件.飞刀在线系统的交付时间虽然因此推迟了两周,但代理商现在可以直接通过浏览器界面预售机票了.图1就是飞刀
在线预售机票时的屏幕截图:图1 飞刀在线嵌入仿真终端控件的界面怎么样,看到图1中HTML页面里所嵌的仿真终端控件了吗你也许从没见过这种将网络时代与主机时代结合得天衣无缝的用户界面吧看到这样的界面就仿佛看见了一位北京猿人站在西直门的立交桥上指挥交通.不过,无论它如何怪异,这一方案的确实现了用户的需求.现在的问题是,你认为客户会对这样的结果满意吗我们的项目经理在需求分析和需求管理方面做得是否到位如果你是这个项目的项目经理,对于类似的需求变更,你有什么更好的处理方法吗
2 一些题外话大多数项目经理在需求阶段都怀有一种近乎完美的理
想:希望客户能清晰地描述出自己需要的业务流程和系统功能;希望客户能随时回答项目组关于系统需求的任何问题;希望客户向项目组开放所有信息;希望客户充分尊重项目组关于需求的改进建议;希望客户乐于确认已有的需求并很少对需求作改动一句话、所有项目经理都在寻找一把可以一击中的,例无虚发的小李飞刀、都希望通过一次访谈就能与客户达成全部共识,就可以获得一份完美的需求.很不幸、尽管有人已经听到了飞刀破空的声音,但那也只是听到而已.与此同时,那些躲在未名湖畔、荷花池边精研武学的大宗师们,还有那些匿于华山峰顶,雁门关外愤世嫉俗的大侠客们,又都不肯甘于寂寞,每年总要推陈出新,弄出几套需求分析和需求管理的新理论、新方法来.一时间,重量级需求管理和轻量级需求分析互不相让,RUP业务建模和XP用户故事各擅胜场、需求模型不断翻新,图表矩阵层出不穷,再加上RequisitePro之类价值不菲的管理工具在一旁擂鼓助阵,需求世界里的热闹劲儿其实一点儿也不比面向对象设计或系统架构等时髦领域差.每一种新推出的需求分析技术和需求管理工具都俨然有小李飞刀、舍我其谁的优越感,但无论方法和工具多么完善,项目经理们总会在项目中遇上种种
与需求有关的麻烦:要么是客户根本提不出成形的需求,要么是项目组认为客户的想法简直愚蠢透顶,最让人头疼的当然还要数客户随时随地,随心所欲地改动需求了说实话、让客户在需求书上签字与让总统在选民面前发誓并没有什么本质的区别;客户想改变需求的时候,我相信绝不会有哪个项目经理莽撞到胆敢拿着客户签字的需求书到随便什么法庭上与客户对簿公堂!作为一名普通的程序员,我并没有医治上述疾患的灵丹妙药,我想在这里告诉大家的仅仅是我在软件项目管理中的
几点个人体会而已:需求分析和需求管理其实不过是客户和项目组之间,项目经理和项目组成员之间就项目范围反复沟通,反复推敲的过程,任何把需求过程简单化或复杂化的做法都只会自讨苦吃;在大多数需求过程里、最简单的技术和工具通常也最为
有效:让客户理解UML用例图并发表意见显然不如给客户讲故事来得直截了当;让项目组花一周的时间学习RequisitePro也许还不如让大家直接用WORD,Email,白板,便签乃至餐巾纸来交流思想;与其和客户计较某项需求到底是业务需求还是技术规约,还不如陪客户上网玩两把四国大战保证需求文档清晰,准确,保证每一次需求变更都有法可依、有据可查才是需求过程的工作核心;使用何种技术和工具只是末节而已;需求永远在变,完美的需求即使存在,也只是一瞬间的事情;也许、寻找一劳永逸的小李飞刀就像老外们寻找银弹一样,至少在目前还只是痴人说梦而已.
3 案例分析让我们回到飞刀在线的案例.我们已经知道,在这个案例里、航空公司为项目组提供了详细的需求文档,在需求变更之前、项目组和客户的合作看上去也非常愉快.从这一意义上说,项目经理几乎已经找到了传说中的小李飞刀!但最终的结果如何呢当客户提出要把机票预售功能纳入飞刀在线的时候,系统已经进入了试运行阶段,项目组这才猛然发现,因为技术体系的差异,看似十分简单的新需求实际上要付出相当大的代价(修改主机程序)才能实现.一切好像都已经晚了,项目组和客户谁都无法承受仓促修改主机程序可能带来的项目延迟和系统风险.不得已,项目组想出了一条应急的妙计,使用仿真终端控件暂时解决了燃眉之急.应急的方法终归不能瞒天过海,项目的结局绝不像项目
经理想象的那样完满:飞刀在线项目不仅延迟了两周才正式交付客户,客户对该系统的最终表现也极为不满,迟迟不肯与我公司结清剩余的账款.客户不满的原因非常简单:航空公司领导希望看到的是代理商能在一个统一、漂亮的图形界面中一次完成航班查询和机票预售操作,而我方给出的仿真终端控件方案只不过是将两种类型的应用程序生硬地绑在了一起,We b应用和机票预售程序并不能真正互联互通,代理商也不得不忍受浏览器外加字符终端这样诡谲离奇的使用体验.按照我公司评价和考核项目的标准,这样的项目只能被归为失败一类.顺便说一句,我公司一向
只以成败论英雄:凡是不能创造价值的项目就不是好项目,凡是不能讨好客户的项目经理就不是好经理,简称两个凡是.说句心里话、我们的项目经理在这个项目中着实算得上兢兢业业了,起早贪黑不说,还在关键时刻显露了一下暗度陈仓,借尸还魂的巧妙心机、但项目最终的结果既不能博得用户欢心、也无法为公司带来足够的收益,项目经理的一番心血付之东流.难道这一切仅仅是因为客户在项目临近结束时随意更改需求吗难道就没有什么其他更深层的原因吗据事后我和这位项目经理讨论的结果,我们认为飞刀在线项目的问题主要出在需求分析和需求管理的过程中.
从表面上看,项目失败的原因来自客户:客户最初提需求时并没有充分考虑领导的意见、直到领导直接介入后才想起要把飞刀在线和机票预售整合;但这时已经到了项目收尾的紧要关头,因为时间紧迫、技术模型迥异,恐怕任谁都难于在短时间内找到理想的整合方案了说实话、项目经理能临危不乱,想出仿真终端控件这样的应急之策,也算不易了.不过,在项目失败后指摘客户的过错,除了可以替自己文过饰非之外,又有什么实际意义可言呢你总不能因为项目失败而让客户赔礼道歉、赔偿损失吧.抛开客户的因素不谈,只要深入分析就会发现,我们的项目组特别是项目经理在此项目中、也要为项目失败承担一定的责任,如果项目经理在需求阶段能把工作做得再细一
些、如果项目组在客户提出新需求的时候能够坚持一些基本原则,项目的结果也许就不会这么坏.根据我们的分析,在需求分析和需求管理过程中、项目经理至少犯了四个严重的
错误:
第一、项目经理在需求分析时没有严格区分客户的需求和最终用户的需求之间的差异.也许是因为飞刀在线的客户过于爽快了,一下子就捧出了厚厚一本需求草案,致使我们的项目经理兴奋过度,忘了需求分析还要清晰界定客户与最终用户的不同诉求.其实,在企业级应用中、客户(Customer,为项目买单的人)和最终用户(End user,使用系统的人)往往并不代表同一个实体,他们对软件的需求也会各有侧重.例如,对飞刀在线系统而言、航空公司是项目的客户,而航空公司的所有代理商才是项目的最终用户.需求分析时,除了要考虑客户的想法以外,还必须认真分析最终用户的诉求,或者将原始需求放到最终用户的实际工作环境下加以考察和评估.换句话说,如果我们的项目经理记得在需求分析时考察一下代理商的工作方式,为最终用户绘制几个UML用例图,
他就一定会发现:代理商最常使用的软件其实是航空公司提供的机票预售系统,飞刀在线的最初设想只是为代理商提供一些增值服务,这并不是代理商赖以生存的核心应用;如果飞刀在线不能整合机票预售功能,那对于代理商来说就只不过是一套可以查询信息,寻找商机的辅助系统;如果飞刀在线以We b方式实现,作为最终用户的代理商就必须在日常工作中面对We b和字符终端这两类截然不同的系统界面,信息查询和机票预售的使用情景就无法统一.面对这些潜在的需求隐患,项目经理应该能预见到,航空公司可能会在今后某个时候提出将二者整合的需求,项目组应在项目开始以前就和航空公司的项
目负责人认真讨论这个问题:要么尽早考察应用整合的可行性,要么尽早请领导确认此项目范围不包括应用整合的功能.
第二、项目经理在需求分析时对相关的技术因素缺乏细致,周密的调研.我知道,有很多人反对在需求分析中引入过多与技术相关的内容.敏捷建模法(Agile Modeling)的创始人ScottW.Ambler也明确指出项目甲方指定了技术方案是需求建模中的常见难题之一③.但在需求分析的实践中、我们或者难以界定某个需求到底位于业务层面还是位于技术层面,或者无法阻止客户提出有关技术选型的要求.例如,许多客户都会因为已经购买了某种应用服务平台(如IBM WebSphere)而指定软件开发商也必须基于该平台甚至该平台的某个特定版本开发软件,更有一些听信了某种宣传的客户会在邀标书中明确规定软件开发商必须使用消息队列或者其他什么技术来实现远程数据同步.遇到这样的客户,项目经理要做的第一件事决不是抱怨,而是应当仔细研究在技术选型受限的情况下按时完成项目的可行性.拿我们的案例来说,航空公司虽然没有给项目组提出过多的技术要求,但项目经理有责任在需求分析时认真考察航空公司和机票代理商之间的系统现状.当项目经理发现预售机票等关键应用是实现在封闭的主机环境上时,就该进一步考虑到,飞刀在线与核心业务系统的技术模式相差甚远,如果今后客户希望飞刀在线系统与主机上的应用系统或关键数据打交道,主机系统就必然要为飞刀在线的服务端程序提供可访问的接口,项目组应该在项目早期就与客户讨论这种假设的可能性和技术上的可行性.事实上,我曾见过的一个项目为我们提供了非常出色的
正面教材:该项目组为某银行客户开发内部使用的报表生成和查询系统,在需求分析时,项目组通过调研发现,银行领导希望通过方便,美观的浏览器界面查询报表,与此同时,银行网点的操作员也有查询和打印报表的需求,但操作员通常只配有办理业务用的UNIX字符终端,无法运行图形界面的浏览器软件.鉴于银行内部应用环境的多样性,项目组最终决定为银行客户开发两种报表查询和打印界面,一种是We b方式的,另一种则是UNIX终端方式的.后一种界面的开发还需要修改银行原有的UNIX程序,但因为方案提出较早,项目组和银行客户都有条件对修改后的UNIX程序进行充分的测试.这个银行报表项目的成功经验显然可以被飞刀在线项目借鉴.套用微软解决方案框架(MSF)中的
BAIT模型来说就是:在需求分析和系统设计时一定要综合考虑业务(Business),应用(Application),信息(Information),技术(Technology)等四方面的因素,只有这样才能保证技术方案和商业需求的一致性④(见图2).图2 MSF BAIT模型
第三、项目经理显然没有充分发挥快速原型技术在需求分析中的重要作用.几乎所有软件工程教材都告诉我们,快速原型对于用户界面的开发最为有效⑤.如果飞刀在线的项目经理在需求分析时,能把系统的原型提供给航空公司中所有与项目前景相关的关键人物试用,也许、航空公司的领导看过原型之后,就能及时发现自己对系统表现的不满意之处,应用整合问题也就能及时暴露在项目组面前了.当然,
这样做难度不小,关键的问题仍然是沟通:项目组要有足够的耐心说服每一位项目关系人、让他们充分了解系统原型并尽早提出改进意见.在以上的讨论中、我反复强调要尽早识别或预测可能发生的需求变更.这是因为、根据风险控制的原则,尽早识别风险并经常重复风险分析过程是项目成功的基础⑥.项目风险可能来自方方面面,飞刀在线项目的风险显然源于技
术因素:在原有的基于主机终端模式的机票预售系统之外另外建设一套供代理商使用的We b应用系统,这一项目本身就存在着新,老技术架构上的矛盾.如果项目组能够在项目早期识别该项目的技术风险,并与客户重新对两个系统的功能,相互关系以及系统架构进行定位、也许可以得到一份更加完美的需求.例如,项目组和客户或许能够发现,如果在飞刀在线项目之外,再成立一个小型项目组,负责在UNIX主机或其前置计算机上实现一组通用,安全的远程调用接口,供其他应用程序访问主机上的核心交易或关键数据,这样,在飞刀在线开发,测试的同时,主机接口的开发可能已经完成了,要在飞刀在线上增加与主机相关的新功能,就不费吹灰之力了.
第四、项目经理在需求发生变化时的处置方式有失水准.我们知道,需求永远都在变化,惟一不变的就是变化本身⑦.问题的关键在于如何应对可能发生的变化.项目经理在飞刀在线试运行期间被迫同意了客户新增功能的要求,并在没有与客户充分沟通的情况下,使用仿真终端控件暂时解决了问题.殊不知此举已经犯下了软件开发的
大忌:在软件的一个可发布版本趋于稳定后,任何新的功能都应当增加到下一个版本中;在已稳定的版本中增加新功能意味着引入了新的不稳定因素.这非常重要、重要到可以拿
肆虐全球的SARS病毒来两相印证:在已稳定的软件中增加新功能就好比在接连10天没有确诊病例报告的城市里引入信息业务应用技术了新的高危人群!也就是说,我们的项目经理在获知新需求时,如果飞刀在线已经开始试运行、他就应该果断地建议客户把新功能放到后续的升级版本中实现,而不要影响当前版本的上线进度.有人马上会说,在项目过程中、客户就是上帝、想说服客户暂缓增加需求简直比说服SARS病毒别再惹是生非还要困难.没错,如果飞刀在线的项目经理打算这么做的话、他的确会面临许多困难.不过,我和项目经理事后总结出了一些可供选择的办法,也许能起到一定的作用:当客户提出新需求的时候,项目经理最好能用讲故事的方式,为客户阐明现阶段增加需求可能为已有的系统带来什么样的风险,请客户判断航空公司是否能够承受这样的风险;在客户不同意立即修改主机程序时,支持客户的想法,并告诉客户最理想的结果是在适当的时机修改主机程序,提供外部接口,然后再升级飞刀在线;当项目经理想出仿真终端控件的方案时,不要急于实施,不妨再开发一个快速原型,让客户体验一下.即便客户接受浏览器和字符终端整合这种诡异的集成方式,也要建议客户先稳定和发布当前系统,然后再着手增加功能;把项目面临的问题和项目组的处理方法告诉公司内负责此项目的销售人员.在企业级应用领域,销售人员总会与关键客户保持有良好的关系,他们在劝阻客户方面往往比项目经理更有优势;试图签订一份新的合同.当前版本稳定后,客户如果提出了新的需求,完全可以由销售人员出面,和客户另签一份合同、作为当前系统的改进项目来实施.新的项目能够收费当然最好,免费赠送给客户也未尝不可,关键是要让客户认识到,新的需求最好能有一个充足的开发和测试时间,不要混在已稳定的版本中仓促上马.
4 补充说明本文讨论的需求过程主要是针对企业客户而言.一般来说,不同类型的软件,其需求管理技术也存在着较大的差异,
例如:分析杀毒软件的需求和分析工控软件的需求,使用的技术与工具可能大相径庭;与企业客户交谈的技巧,也许很难用于和学生用户的沟通;收集网络游戏的用户诉求恐怕要比收集手机软件的用户诉求容易得多但无论如何,有关需求管理的一些基本原理,比如加强沟通,比如未雨绸缪,还是可以普遍适用的.
5 总结一下没有小李飞刀、也没有完美的需求.与其追求一次到位的需求,不如时刻为需求变更做好准备.尽可能提前预测和评估风险,是应对需求变更的最佳途径.
①俞平伯. 红楼梦辨. 上海: 上海书店, 1990
②王咏刚, 周虹. 凌波微步: 软件开发警戒案例集. 北京:清华大学出版社, 2002
③AmblerSW. Agile Requirements Modeling.
④Microsoft. Microsoft Solutions Framework White Paper.
⑤SchachSR. 软件工程: Java语言实现. 北京: 机械工业出版社, 1999
⑥Microsoft. MSF Risk Management Discipline.
⑦BrooksFP. 人月神话. 北京: 清华大学出版社, 2002

pdf文档的标签：

更多推荐标签：教师制度建材市场提案李白幽愤论初二课后答案农业企业物流中考自鉴书医学生职业个人要房申请研究论语公共卫生综合合作提案法律类火电厂省煤器质量员一本通足球基础合同附件范本家好花园美与健康入党志愿表格依法治国案例上岗实习报告怎样做大的台静农图纸会审表格致命砍人节要事第一光学薄膜技术美容新潮流奥赛实施办法内部晋升表格