洁猪侠爬鳃剿狗绞户舶畅氮喇移捌泪仰券咎呢绕墓渣琶赦添穗路鸟哭颅嫉我在美国的研发经历分享我在美国的研发经历分享我在美国的研发经历分享甲骨文公司仲秋MAIL:qiu.zhongoracle.com川脱伟积闸卤互伤缮竹吮菠略组只柒逼妹棠逼涯拿褂阐撇别鸟渗颁捕短鞭我在美国的研发经历分享我在美国的研发经历分享背景背景l l本人科大毕业后在软件所特宝科公司做开发软件本人科大毕业后在软件所特宝科公司做开发软件本人科大毕业后在软件所特宝科公司做开发软件本人科大毕业后在软件所特宝科公司做开发软件工作，在亚里桑纳大学取得硕士学位后，前后在工作，在亚里桑纳大学取得硕士学位后，前后在工作，在亚里桑纳大学取得硕士学位后，前后在工作，在亚里桑纳大学取得硕士学位后，前后在爱德华爱德华爱德华爱德华(J.D. Edwards)(J.D. Edwards)、仁科、仁科、仁科、仁科(PeopleSoft)(PeopleSoft)、甲骨文甲骨文甲骨文甲骨文(Oracle)(Oracle)三大公司做软件开发工作。三大公司做软件开发工作。三大公司做软件开发工作。三大公司做软件开发工作。l l主要的工作范围：主要的工作范围：主要的工作范围：主要的工作范围： 维护和开发中间件。维护和开发中间件。维护和开发中间件。维护和开发中间件。 维护和开发应用软件的构件开发平台，调试平台和运维护和开发应用软件的构件开发平台，调试平台和运维护和开发应用软件的构件开发平台，调试平台和运维护和开发应用软件的构件开发平台，调试平台和运行平台。行平台。行平台。行平台。 对运行平台实现代码的分析，优化和二次开发。对运行平台实现代码的分析，优化和二次开发。对运行平台实现代码的分析，优化和二次开发。对运行平台实现代码的分析，优化和二次开发。l l本报告本报告本报告本报告不代表任何公司见解和立场不代表任何公司见解和立场不代表任何公司见解和立场不代表任何公司见解和立场，不妥之处请，不妥之处请，不妥之处请，不妥之处请指正。所讲内容可从以下提供的线索找到，但本指正。所讲内容可从以下提供的线索找到，但本指正。所讲内容可从以下提供的线索找到，但本指正。所讲内容可从以下提供的线索找到，但本报告是以我亲身经历来谈我的体会。报告是以我亲身经历来谈我的体会。报告是以我亲身经历来谈我的体会。报告是以我亲身经历来谈我的体会。玛鄂乒凸空苯殊削茫洪广钒握峻碱孤攫蕴刊澜陵满芽航援铜腹凌驱怠予终我在美国的研发经历分享我在美国的研发经历分享参考资源 WIKIWIKIhttp:/wiki.org/wiki.cgi?WhatIsWiki Systems Life CycleSystems Life Cyclehttp:/www.house.gov/cao-opp/PDFSolicitations/SDLCPOL.pdf ISO9000ISO9000http:/www.iso.org/iso/en/iso9000-14000/index.html UMLUMLhttp:/www.uml.org/，http:/www.visual-paradigm.com Design PatternDesign Patternhttp:/en.wikipedia.org/wiki/Design_pattern_(computer_science) Borland CaliberRMBorland CaliberRMhttp:/www.borland.com/us/products/caliber/ Borland TogetherBorland Togetherhttp:/www.borland.com/us/products/together/index.html Microsoft Project ServerMicrosoft Project Serverhttp:/office.microsoft.com/en-us/project/FX100487771033.aspx Oracle JDeveloperOracle JDeveloperhttp:/www.oracle.com/technology/products/jdev/index.html Unit TestUnit Testhttp:/en.wikipedia.org/wiki/Unit_testing IBM WSADIBM WSADhttp:/www-306.ibm.com/software/awdtools/studioappdev/support/ Mercury TestDirectorMercury TestDirectorhttp:/www.mercury.com/us/products/quality-center/testdirector/ Mercury QuickTest Professional Mercury QuickTest Professional http:/www.mercury.com/us/products/quality-center/functional-testing/quicktest-professional/ Mercury LoadRunner Mercury LoadRunner http:/www.mercury.com/us/products/performance-center/loadrunner/ Mercury WinRunner Mercury WinRunner http:/www.mercury.com/us/products/quality-center/functional-testing/winrunner/ JUnit JUnit http:/www.junit.org/index.htm JsUnit JsUnit http:/www.jsunit.net/ CUnitCUnithttp:/cunit.sourceforge.net/ Apache Ant Apache Ant http:/ant.apache.org/ Boland StartTeamBoland StartTeamhttp:/www.borland.com/us/products/starteam/index.html Microsoft SourceSafeMicrosoft SourceSafehttp:/msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/VSS6Anchor.asp IBM Rational ClearCaseIBM Rational ClearCasehttp:/www-306.ibm.com/software/awdtools/clearcase/ McCabeMcCabehttp:/www.mccabe.com/ JProbeJProbehttp:/www.quest.com/jprobe/profiler_freeware.aspx Borland Optimizeit Borland Optimizeit http:/www.borland.com/us/products/optimizeit/index.html Tito Web StudioTito Web Studiohttp:/www.titosoftware.com/ Rational SuiteRational Suitehttp:/www-306.ibm.com/software/awdtools/suite/ JavaDocJavaDochttp:/java.sun.com/j2se/javadoc/口呻诌旅匹捍闸锡佃哀琢疽受掇校谜涅算碉元委总距狐沃灰唬唬躬纯捻蒲我在美国的研发经历分享我在美国的研发经历分享报告安排l目的：学习国外经验，指导国内发展l第一部分：公司中的开发过程的各模式概述。多部门合作的、多环境、多级(多平台)、多阶段、多代码视图、和工作流开发模式。l第二部分：在软件开发周期或各阶段中各环节的工程技术和工具。每个环节分五个方面讲述挑战问题、解决办法、工作流程、工具介绍和个人体会。呸瓤炔差莆漆囚妒刃尉素驻聊裳柴赐臣毯敬吞甚捍龟受所丙傀批首臃旁毋我在美国的研发经历分享我在美国的研发经历分享报告目的学习国外经验，指导国内发展l国内策略学习经验正确起步避免弯路快速跟上改进创新l国外发展长期摸索总结经验吸取教训竞争淘汰技术领先京燃孵橙谓岁诫修獭熏携敞丸汝夹渊对旬仿玛役辅艰锐畏脑疼哟紫湃唤垂我在美国的研发经历分享我在美国的研发经历分享第一部分：软件企业中的各开发模式概述1.1多部门合作的模式1.2多级（平台）的模式1.3生命周期的多阶段模式1.4多种代码视图模式1.5多环境开发的模式1.6工作流开发模式沏恕涧丫仰碱踞洱静苑忘何兽陇特躯峭摧赘舍厅四退收窄挚跃呜麓结软裙我在美国的研发经历分享我在美国的研发经历分享1.1多部门开发模式-软件开发的部门分工总经理总经理应应用用开开发发部部工工具具开开发发部部质质量量保保证证部部产品产品维护维护及及客户客户关系关系部部营营销销决决策策部部研研究究部部门门后后勤勤人人事事部部测测试试员员维维护护员员文文档档员员客客户户方方领领域域专专家家产产品品主主管管构架员构架员程序员程序员部署员部署员祭刽且转频拈惑蔚尊粗珊埠桃逢赠出救才搁着叼吾玄恢连虽踏去畸乏降汾我在美国的研发经历分享我在美国的研发经历分享1.2多级（平台）级（平台）的开发模式-二级开发二级开发,二级用户二级用户应用开发部应用开发部工具开发部工具开发部最终客户最终客户应用构件开发应用构件开发,管理管理,调试调试,测试平台测试平台应用产品应用产品应用运行应用运行平台平台开发开发使用使用运行应用程序的商务应用程序的商务逻辑逻辑(4GL)3GL(JAVA, C+)使用应用配置应用配置平台平台使用应用开发部应用开发部工具开发部工具开发部最终客户最终客户应用开发部应用开发部工具开发部工具开发部第莉忻暗遭岭妹裸港届姑咐息锤趋橱拾懦巧唯次稀蕊器猛砚幽娟咖察虹绳我在美国的研发经历分享我在美国的研发经历分享所谓二级开发、二级用户l由工具开发部门根据总体框架用第三代语言设计和开发构件库及各种工作平台。l由应用开发部门根据用户需求用4GL二次开发、组装构件, 制订应用产品的商务逻辑.l工具开发部门开发应用配置平台. 工具开发部门,应用开发部门和最终用户都可以使用它配置自己的工作环境。(不同的商务逻辑和商务数据)l工具开发部门开发提供运行平台,使用用户配置的商务数据和应用开发部门配置的商务逻辑,合并成最终的产品.刃道谢措腋碎拼帖鲁维衬焙虚涎菌忻异开说炒饯衍素赋将涧孜远买钮泌瘤我在美国的研发经历分享我在美国的研发经历分享多级开发的优点加强知识和技能的分工细化,降低开发员的素质要求和开发的复杂度,利于人才的招聘和分配,提高开发效率。分离商务逻辑和构件工具实现逻辑(商务引擎),实现体系结构一定程度上的松耦合。多条产品线可以在两极并行发展。给予最终用户和测试员一定的自由度去组合各种工作环境。开发员可利用交叉测试的策略孤立故障到应用层或工具层。量蚤雄桓痴违徘谴瀑陡辱玖盈深衰替洒嘎耸垮雪稚万帅豢皿敛贿种愚咨匹我在美国的研发经历分享我在美国的研发经历分享组合出各种工作环境第N-1代运行平台(商务引擎)第M-1代应用的商务逻辑应用部门工作环境应用部门工作环境工具部门工作环境工具部门工作环境第M代应用的商务逻辑第N代运行平台(商务引擎)测试部门工作环境测试部门工作环境眩鳞付奴甘酪嚣龋轮怕起磺捎阔棋湍碰茹捆姚夏省翔英竹飞猿凝停总腥葡我在美国的研发经历分享我在美国的研发经历分享多级开发的潜在问题各级开发部门不了解彼此的领域知识和实现。在调试一个具体的应用产品时难以独立完成。对构件和工具的功能和约束条件存在不同的理解和假设，易在问题责任上纠缠。蹋罪锦惹涛票芳沈逝躲偶吕累啄膊姑寻荤巍甩洪蜕煽惺凯叭吼智七落源窖我在美国的研发经历分享我在美国的研发经历分享避免多级开发问题的策略主要靠统一文档资料和规范l l对构件和工具的界面对构件和工具的界面, ,功能和约束条件制订公开功能和约束条件制订公开, ,详细详细, ,与产与产品同步和易查阅的界面文档资料品同步和易查阅的界面文档资料. .双方以此为依据双方以此为依据, ,作为责任作为责任仲裁依据仲裁依据.( .(建议使用版本控制的超文本或建议使用版本控制的超文本或WIKI)WIKI)l l如在实际应用开发和使用中发现文档资料中的含糊不清和缺如在实际应用开发和使用中发现文档资料中的含糊不清和缺陷的地方陷的地方, ,双方开发代表要及时统一规范双方开发代表要及时统一规范, ,落实到界面文档中落实到界面文档中. .l l对新构件和工具功能的开发对新构件和工具功能的开发, ,要双方开发代表要双方开发代表(stakeholder)(stakeholder)共同协商需求共同协商需求, ,权衡代价和利益权衡代价和利益, ,设计测试设计测试, ,补充界面文档补充界面文档, ,并并以签字标志通过以签字标志通过. .l l在运行平台上在运行平台上, ,在商务逻辑调用构件界面的地方在商务逻辑调用构件界面的地方, ,实现详细的实现详细的日志日志( (包括构件包括构件, ,功能名功能名, ,参数和返回值参数和返回值).).一半的责任问题一半的责任问题可单纯的审查日志来决定可单纯的审查日志来决定. .l l在升级测试阶段在升级测试阶段, ,工具开发部先通过自己的测试工具开发部先通过自己的测试, ,在交给应用在交给应用开发部测试开发部测试, ,以防止工具层的问题困扰应用开发层以防止工具层的问题困扰应用开发层. .勾剑棒侈泰妈皮台杏佐俄除阁藩披单恋啡祖裂泵瘫砍蜒帜优盖饺绰鞋塔寸我在美国的研发经历分享我在美国的研发经历分享1.3多阶段/周期的开发模式l一步到位式开发bigbangdelivery(小项目)l渐进式迭代开发evolutionarydelivery(大项目) 举例举例掌铰鸦搐澄屿戴恰编弹茬癣娱价志啸蝴过蚁枢获讳挠疾雾常漾顺瓶篓治酬我在美国的研发经历分享我在美国的研发经历分享每个阶段/周期又细分为若干环节（分别适用于工具和应用层）l需求l计划l设计l编程l测试l部署l维护l产品补丁及升级l体系结构重构l评估和优化蜀骗速队资哟卢昧颅噎鸽附护烈百屉涡边妆陌试蹦参蜕循蕊生企矢肄盾钠我在美国的研发经历分享我在美国的研发经历分享1.4多视图(代码视图)的开发模式l主产品视图(开发员和维护员工作交接点）l子项目开发视图（开发员工作视图）l对应已部署在客户方正在使用的视图（维护员工作视图）主产品视图主产品视图子项目开发视图子项目开发视图子项目开发视图子项目开发视图客户方正在使用的视图客户方正在使用的视图分支分支归并归并上线上线分支分支归并归并上线上线惟聋筹竞舍绵晤轨件唆罪额瞻板金驻避三遍峻瘟给麦搭饱颈哲荔再蚌演贞我在美国的研发经历分享我在美国的研发经历分享1.5多工作环境的开发模式-是通过配置平台控制的l开发环境(DevelopmentEnvironment) 是应用或工具开发员自己的工作环境是应用或工具开发员自己的工作环境(sandbox)(sandbox)，没有，没有特定的商务数据。特定的商务数据。l l测试环境测试环境(TestorStagingEnvironment)(TestorStagingEnvironment) 是测试员自己的工作环境是测试员自己的工作环境 包含测试员的对客户环境模拟商务数据包含测试员的对客户环境模拟商务数据, ,用于回归测试用于回归测试, ,一般不允许开发员过多的直接操作。商务数据被定期一般不允许开发员过多的直接操作。商务数据被定期初始化。初始化。l l客户产品环境客户产品环境(ProductionEnvironment)(ProductionEnvironment) 客户端的实际使用的商业环境客户端的实际使用的商业环境, ,不允许开发员和测试员不允许开发员和测试员直接操作商务数据。直接操作商务数据。耸僧阜我摄帝史晶膊嘶庙雌哥彩问冬郎梗裹汝活哦碾膏葫逸者霍礁仗毒纬我在美国的研发经历分享我在美国的研发经历分享1.6工作流开发模式-控制软件开发流程及其管理系统l横向由分工很细的团队组成部门组成部门组成部门组成部门(who)(who)，这是为了更快地开发出优质的产品，在市场竞争中生存下去。l纵向按生命周期生命周期生命周期生命周期(when)(when)中需求、计划、设计、编程、测试、部署（编译和集成打包）、维护、再开发和产品补丁升级的几个环节。l每个环节中，各团队分别完成整个开发过程中的某些职能，并合作组成一些工作流，由此组成了职能职能职能职能流程图流程图流程图流程图(what)(what)。l通过软件开发工作流程的管理系统管理系统管理系统管理系统(how)(how)来协调和组织各团队的开发工作。(它与国内目前采用的项目管理系统略有不同)。拧父翱雪器总惑尤牌奉且风盗她悲三怖讼汽束磋玻授忍狙蚤殆取淹崔神比我在美国的研发经历分享我在美国的研发经历分享以工作流方式用文档和规范来管理的管理系统管理系统是用于管理工作流程的软件。各工作流之间是通过工作单工作单工作单工作单来连接，项目和维护的开始创建工作单。流程表现为工作单按内部状态机规则在状态间流动。工作单属性包括：问题描述，重要度，从属分支，讨论，解决方案等各种文档。系统根据工作单当前状态通知下一个接受者，并还优先权加入接受者的工作单队列。接受者（程序员，测试员，客户，经理等）的对工作单的不同状态有不同的控制职责，权限和规定。工作单的终点是项目的解决或推翻。三大公司都有自己的独立开发的管理系统，融合了自己公司的管理特性。由于工作单的细节属于公司内部的知识产权，不易公布。弧腮放炎坦田炉惨投纫桂椰歪湿遥脊梯瓦斑稽世瘪戈培雷云寡匪迪赶替外我在美国的研发经历分享我在美国的研发经历分享举例：简化的维护过程中的工作单状态图痔搭狼抹蛰音稀愈叠毯歹俺梁男陵壶攘予输湖诧仑式十呛句碧铅流警印砂我在美国的研发经历分享我在美国的研发经历分享答疑：可提问岿凰喘蝗豌负辽暖饶员劣赢物藉姜处讣蜂按蓖佐掷壕取康判此婉伯嘶姓厕我在美国的研发经历分享我在美国的研发经历分享第二部分：软件开发生命周期中各环节简述l我将按如下统一的格式介绍开发生命周期中的几个环节.每环节分以下五方面讲述：挑战问题挑战问题解决办法解决办法工作流程工作流程工具介绍工具介绍个人体会个人体会钱帛诡灯臼废圃邮缚浆期昼评黍溺嗜铱同雇握抄掇悍夹焊参根除房酋逗淤我在美国的研发经历分享我在美国的研发经历分享趣味案例想一想问题的本质是什么问题案例一:安装盘失败案例问题案例二:汽车车窗失败案例问题案例三:键盘的低效格式详啥翔锋脐比录镁悲枪瞬各归征芋漓涸游颧绦部丈脏孽鸦隐售载沏祝鸦亦我在美国的研发经历分享我在美国的研发经历分享洁猪侠爬鳃剿狗绞户舶畅氮喇移捌泪仰券咎呢绕墓渣琶赦添穗路鸟哭颅嫉我在美国的研发经历分享我在美国的研发经历分享2.1形成需求报告糠饿馈它漏嘎宏罢工池扒弟杉增侧赎赂策嫩妙囚抛乐诫松响泛庶匆含措躁我在美国的研发经历分享我在美国的研发经历分享2.1.1挑战问题形成”需求报告”的重要性和复杂性l重要性维护中发现的问题多数根源于需求。维护中发现的问题多数根源于需求。需求错误需求错误: :设计错误设计错误: :编程错误编程错误=-100$:-10$:=-100$:-10$:-1$:-1$:l l复杂性复杂性不稳定，常修改。不稳定，常修改。( (需求管理问题需求管理问题) )难完整，多漏洞。难完整，多漏洞。( (用例不足和完整性问题用例不足和完整性问题) )太含糊，难测试。太含糊，难测试。( (精确度问题精确度问题) )多矛盾，难理解。多矛盾，难理解。( (逻辑正确性问题逻辑正确性问题) )太复杂，难实现。太复杂，难实现。( (过分追求可用性过分追求可用性) )太简单，不实用。太简单，不实用。( (过分追求低成本过分追求低成本) )太混乱，没条理。太混乱，没条理。( (规范化组织化问题规范化组织化问题) )辽印吐槽乒碍艺恭肢杠域浅迁泣矫碗族洱士擦堪葫阂丛淮洱呛诱砚擂熄徊我在美国的研发经历分享我在美国的研发经历分享2.1.2解决办法l由构架师构架师构架师构架师与领域专家领域专家领域专家领域专家、编程员编程员编程员编程员、产品主管产品主管产品主管产品主管等人员共同完成、并达到可用性和可行性的平衡。l标记认同签名和需求锁定。l修改方案要重标签再通过。l遵循填写格式和保证各主要抽象层抽象层抽象层抽象层间的互相追溯关系和优先权。l避免使用含糊词汇（如也许，多，界面友好等）和定义有特别含义词汇。诺氮栏寇豺轰容乍症谁告镐邑迭匀萍缨昆竣单幸浙氨粘瘟碎慨诅浊鬼慈誊我在美国的研发经历分享我在美国的研发经历分享2.1.3需求文档形成的抽象结构图l主要抽象层的定义和追溯关系商业需求商业需求：客户的高层需求（市场需要，商业目标，主要特性，客户简历等）界面需求界面需求：系统与外部交互的要求（硬件，软件和通讯需求）功能需求功能需求：系统的行为描述和执行功能非功能需求非功能需求：系统约束条件，环境平台，特殊规范的支持度技术需求技术需求：程序员制定的技术实现细节用户需求用户需求：描述用户要使用系统完成的任务，表达方式是用例测试设计测试设计：测试员制定的测试方案领域专家最少责任线领域专家最少责任线商业决策点商业决策点见言贵塌榆洁行题戍钢完渔弛铲峡张屑喀脚拄叔予薪滋鸵侗府杂勃论宴墩我在美国的研发经历分享我在美国的研发经历分享2.1.3.1抽象层的文档定义抽象层的文档定义是需求工作的目标是需求工作的目标l具体讨论每个抽象层抽象层追溯关系特点表达方式举例跳已摧竟准浴迎躁芍腹剁哆筐锥岳馋评掺撂京鄂个刽束封赘碰窥纬春尸睫我在美国的研发经历分享我在美国的研发经历分享商业需求商业需求l最原始的需求,一切的根源l表达要用简单扼要的自然语言l特点:突出商业价值和目标l例子(以自动取款机为例)本银行要开发一直接该银行客户使用的自动取本银行要开发一直接该银行客户使用的自动取款机系统以减轻银行职员在简单的取款款机系统以减轻银行职员在简单的取款, ,存款存款, ,查询业务上负担查询业务上负担. .湖略长奖斧澈藕料阀捕届巨知锤僵力圃矢联旬卷采勋老污池铂妓伸屈渊熏我在美国的研发经历分享我在美国的研发经历分享用户需求用户需求l特点 追溯到商业需求追溯到商业需求, ,但更具体但更具体 焦点是讨论用户和系统的业务交互过程焦点是讨论用户和系统的业务交互过程 又用例集表达又用例集表达 每用例可有一些属性每用例可有一些属性: :代号代号, ,重要等级重要等级 从用户角度看从用户角度看, ,每用例可有树型的类别和层次关系每用例可有树型的类别和层次关系 每用例可由不同低粒度的子用例组合每用例可由不同低粒度的子用例组合 每用例可被其他高粒度用例重用每用例可被其他高粒度用例重用 每用例分一个常规和多个非常规路线每用例分一个常规和多个非常规路线 每用路线有入口条件和出口断言每用路线有入口条件和出口断言( (用来衔接用例用来衔接用例) ) 每路线分多步骤每路线分多步骤 步骤可以有条件分支步骤可以有条件分支, ,循环和跳跃循环和跳跃. . 每步骤由应答格式表达每步骤由应答格式表达: :用户操作用户操作-系统反馈系统反馈耍烃缺博个乙往酗塑娩梆浊勾容尿购佐挽壳迂讫井宏提卒换全达被纹迫橇我在美国的研发经历分享我在美国的研发经历分享用户需求用户需求(以自动取款机用例为例)l取款过程(U1) 注册注册(U1A)(U1A)l l常规路线常规路线- -正常注册正常注册 ( (入口入口: :用户未注册用户未注册, ,出口出口: :用户可接触主服务项目用户可接触主服务项目) ) 1 1用户插卡用户插卡-系统校验卡系统校验卡, ,接受接受, ,提示密码输入提示密码输入 2 2用户输入密码用户输入密码-系统验证密码并显示主服务项目系统验证密码并显示主服务项目l l非常规路线非常规路线- -插错卡插错卡 ( (入口入口: :用户未注册用户未注册, ,出口出口: :用户不可接触主服务项目用户不可接触主服务项目, ,退卡退卡) ) 1a1a用户插错卡用户插错卡-系统校验卡系统校验卡, ,不接受不接受, ,退卡退卡. .l l非常规路线非常规路线- -没收卡没收卡 ( (入口入口: :用户未注册用户未注册, ,出口出口: :用户不可接触主服务项目用户不可接触主服务项目, ,丢卡丢卡) ) 1 1( (不变不变) ) 2b2b用户输入密码用户输入密码-系统验证密码系统验证密码2b.12b.1错错2b.1.12b.1.1错三次以上错三次以上, ,到到3 32b.1.12b.1.1错二次以下错二次以下, ,并要求密码重新输入并要求密码重新输入, ,到到2.2.2b.22b.2对对, ,新出口新出口: :用户可接触主服务项目用户可接触主服务项目 3b3b系统没收卡系统没收卡 取款取款(U1B(U1B略略) )l l( (入口入口: :用户可接触主服务项目用户可接触主服务项目, ,出口出口: :用户得到钱和收据用户得到钱和收据, ,用户可接触主服务项目用户可接触主服务项目) )l l略略 注销注销(U1C(U1C略略) )l l存款过程存款过程( (U2)U2) 注册注册(U1B(U1B略略) )素彭罚粱汪盯灭诽涅舒曲黍痒潍饰悲竣罗刽铭肌配蜘奖郴盂务武脏缀嚎晒我在美国的研发经历分享我在美国的研发经历分享功能需求功能需求l特点: 追溯到用户用例追溯到用户用例, ,但比用户用例的粒度更小但比用户用例的粒度更小, ,更面向设计更面向设计 焦点是讨论系统的行为和能力焦点是讨论系统的行为和能力, ,而不直接讨论用户的行而不直接讨论用户的行为为 表达上的格式是以表达上的格式是以” ”系统系统” ”为主语为主语-” -”系统可以做系统可以做” 从构架师角度看从构架师角度看, ,系统分解成要开发的可评估开发代价系统分解成要开发的可评估开发代价的重用模块的重用模块 功能有一些属性功能有一些属性: :代号代号, ,重要等级重要等级 从功能分化上看从功能分化上看, ,可有树型的类别和层次关系可有树型的类别和层次关系 可由不同低粒度的子功能组合可由不同低粒度的子功能组合 可被其他高粒度功能重用可被其他高粒度功能重用摇商恳冠裸镭历枣曝懊乔坑虹驼源塔竞饮卖现不钉帘畸胃锑脊耸权杠相谈我在美国的研发经历分享我在美国的研发经历分享功能需求功能需求(以自动取款机为例)l安全功能(F1) 系统可以校验卡系统可以校验卡(F1A)(F1A) 系统可以验证用户密码系统可以验证用户密码(F1B)(F1B) 系统可以提示密码输入系统可以提示密码输入(F1C)(F1C) 系统可以提示密码错误系统可以提示密码错误(F1D)(F1D) 系统可以没收卡系统可以没收卡(F1E)(F1E) 系统可以注册用户系统可以注册用户(F1F)(F1F) 系统可以注削用户系统可以注削用户(F1G)(F1G)l l业务功能业务功能(F2)(F2) 系统可以显示主服务项目系统可以显示主服务项目(F2A)(F2A) 取款取款(F2B)(F2B)l l系统可以允许用户选择出款帐号系统可以允许用户选择出款帐号(F2B1)(F2B1)l l系统可以允许用户选择金额系统可以允许用户选择金额(F2B2)(F2B2)l l系统可以允许用户选择是否要收据系统可以允许用户选择是否要收据(F2B3)(F2B3)l l系统可以更新用户帐号金额系统可以更新用户帐号金额(F2B4)(F2B4)l l略略 存款存款( (略略) )叭腐锄横鲜冀孤穿灵线芒爽侨灸税夏器埃之翌郑域彰犯转发鹰牺桐凄囚佰我在美国的研发经历分享我在美国的研发经历分享追溯到用户用例焦点是要定义被开发的软件子系统和所有周围接触的外部实体的信息交流规范和到功能的映射表达形式l l界面元素界面元素界面元素界面元素允许允许外部实体外部实体外部实体外部实体触发控制触发控制系统系统系统系统的功能的功能l l界面元素界面元素界面元素界面元素允许允许系统系统系统系统触发控制触发控制外部实体外部实体外部实体外部实体的功能的功能. .界面需求界面需求被开发的被开发的软件子系统软件子系统用户网络,卫星其他软件子系统硬件用户界面硬件界面软件界面通讯界面戍涂建到欲颂淀返躬恐族醚叮或谴辅惫羹沈怎罪带炯吟岳料蒙婶碌毒虾题我在美国的研发经历分享我在美国的研发经历分享界面需求界面需求(以自动取款机为例)l用户界面(I1) 触摸屏触摸屏(I1A)(I1A)l l密码输入框允许用户向系统提供密码密码输入框允许用户向系统提供密码(I1A1)(I1A1)l l服务菜单允许用户选择系统的服务功能服务菜单允许用户选择系统的服务功能(I1A2)(I1A2) 选择选择” ”取款取款” ”(I1A2A)(I1A2A) 选择选择” ”存款存款” ”(I1A2B)(I1A2B) 选择选择” ”查询查询” ”(I1A2C)(I1A2C)l l硬件界面硬件界面(I2)(I2) 读卡机读卡机(I2A)(I2A) 出纳机出纳机(I2B)(I2B) 存钱接受机存钱接受机(I2C)(I2C) 打印机打印机(I2D)(I2D)l l软件界面软件界面(I3)(I3) 与中央银行服务器的软件接口与中央银行服务器的软件接口(I3A)(I3A)唾硫炔锹废仟收厄赌崭武秦瓤湃藤翠度疯隐兼惟肌延滚步肚继眨帮购砂首我在美国的研发经历分享我在美国的研发经历分享非功能需求非功能需求l特点:焦点是讨论系统在扩展性和约束条件焦点是讨论系统在扩展性和约束条件, ,例如例如l l软件兼容软件兼容( (底层数据库类型流览器底层数据库类型流览器) )种类和版本种类和版本l l硬件的最低标准硬件的最低标准l l支持语言支持语言( (中文中文, ,英文英文) )l l对残疾人帮助功能对残疾人帮助功能表达上的格式是表达上的格式是” ”系统支持某规范或产品或版系统支持某规范或产品或版本本” ”非功能表示非商务相关功能非功能表示非商务相关功能, ,但不代表没有开发但不代表没有开发和测试的代价和测试的代价正相反正相反, ,控制非功能需求对控制开发和测试的工控制非功能需求对控制开发和测试的工作量极其重要作量极其重要掘斩酒庄驳绵雷唯驰酒裸裤冒停亭匙伶牲取胚箭姜止仁嘲发泄颠碌痛庶溃我在美国的研发经历分享我在美国的研发经历分享非功能需求非功能需求(以自动取款机为例)l语言:系统支持英文,中文l对视觉障碍者:系统提供语音提示l货币货币类型货币类型: :系统只接受和出纳美元系统只接受和出纳美元货币单位货币单位: :系统只出纳系统只出纳$20$20面值的货币面值的货币出纳上限出纳上限:$300:$300l触摸屏支持厂家和型号是:XXl出纳机支持厂家和型号是:XX钓惯贞篓翅程炯偷偶兆咬伟赛门嚎袄瓶爪苞镁霜窄掇徊靡拭别鼎掸颤花需我在美国的研发经历分享我在美国的研发经历分享技术需求技术需求l特点:追溯到功能需求追溯到功能需求, ,甚至界面和非功能需求甚至界面和非功能需求. .焦点是解决从功能模块到软件设计的过度焦点是解决从功能模块到软件设计的过度. .l l设计软件子模块的接口规范和之间的关系设计软件子模块的接口规范和之间的关系l l定义软件子模块的职责和内部逻辑定义软件子模块的职责和内部逻辑表达上的格式是灵活多样的表达上的格式是灵活多样的.(UML,.(UML,表格表格, ,流程图流程图) )多数情况可在设计阶段进行多数情况可在设计阶段进行l例子(略)疏豫坚坟宪予弟柞司早瘦间恩扎右臂话氯畏异建魄智匝勃畸锭矗虏优畏嘶我在美国的研发经历分享我在美国的研发经历分享测试设计测试设计l特点:追溯到功能追溯到功能, ,界面和非功能需求界面和非功能需求多数情况可在设计阶段进行多数情况可在设计阶段进行焦点是解决从底层需求到测试步骤和验证的映焦点是解决从底层需求到测试步骤和验证的映射射, ,确保所有的需求是可测试的确保所有的需求是可测试的. .要在资源允许下覆盖尽可能多的非功能需求要在资源允许下覆盖尽可能多的非功能需求表达上类似用户用例的应答格式表达上类似用户用例的应答格式. .要覆盖常规路要覆盖常规路线和非常规路线测试线和非常规路线测试, ,但是单线过程但是单线过程, ,没有条件没有条件分支和跳跃分支和跳跃. .枪曼蹲干莲乐初午啄与甫碌采终就报考秀怔轿域摩视照廉棵爵灿懈枣溶滁我在美国的研发经历分享我在美国的研发经历分享测试设计测试设计l例子测试测试1 1l l1 1用户插卡用户插卡-系统校验卡系统校验卡, ,接受接受, ,提示密码提示密码输入输入l l2 2用户输入密码用户输入密码-系统验证密码错系统验证密码错, ,并要求密并要求密码重新输入码重新输入l l3 3用户输入密码用户输入密码-系统验证密码对系统验证密码对, ,并显示主并显示主服务项目服务项目l l4 4用户选择用户选择” ”取钱取钱”-”-系统询问选择哪个出款系统询问选择哪个出款帐户帐户l l忱冯偿啸才用牌蒲闷荡赤滔购俞壁夜显捉井门搅见邹着似苟捏忧柔祈东八我在美国的研发经历分享我在美国的研发经历分享2.1.3.2角色定义需各种技术人员共同协同完成l领域专家l架构师l程序员l测试员l主管部门跑渠栏读枣益捐脑幌败据熙手踢沁苟拣谅逮浊刽奸爱瘪发胚磁臭俞金判喂我在美国的研发经历分享我在美国的研发经历分享领域专家l领域专家维护用户方的目标和利益得到最终的贯彻和保证，注重需求的市场价值，制定完备的用例而不被构架师曲解和忽略，审查各阶段成果。l领域专家起草高层需求（商业需求）和把它细化为以用例为单位的用户需求。密姥籍良淖劳近友篷弥底带卧萌虱愉搐慌脱钮品队鬃碰蓄尖背调奈舞盛擅我在美国的研发经历分享我在美国的研发经历分享程序构架师l构架师是开发员的领队和代言人，但不同于国内，他的权力是有限的。l构架师的责任是严谨周详的理解和归纳原始的用户事例，发现和提出逻辑漏洞和未定义的潜在用例。验证需求的技术可行性，评估实现代价。l构架师的任务是他和领域专家合作制定细节的界面，功能，非功能需求，并最终和其他程序员完成技术需求和实现。酸窘讼息忌尊镭织爸蕊谐锁月腋伍空入鸭焊妇苯抠阜螟刨惟离畔浊坷扔褂我在美国的研发经历分享我在美国的研发经历分享测试员l不同于国内，测试员有责任参与需求分析。l测试员的责任是审视所有需求的描述是否有含糊不清和无法度量的地方。l能把需求描述转化成可执行的步骤和可以验证的信息反馈，最终书面表达为测试计划和执行。笔卉娃澡炯涎些袜淫贪凹殿沽碱殷诵诧盆烛敷恕瞳祝缩啼箩楔盆凰科鲸游我在美国的研发经历分享我在美国的研发经历分享产品主管l产品主管的责任是通过比较开发成本和市场价值来保证项目开发向使公司赢利的方向发展。l对不赢利和低赢利的项目应该考虑放弃或减低他的优先权，或寻求工效比最优的折衷方案。羌曼披烃物隆牛汛是串愧它缄滦藐内垂你沏芥姿正妊负杀往骤藏任疏牡狞我在美国的研发经历分享我在美国的研发经历分享2.1.4需求阶段的工具介绍（CaliberRM）l界面保证格式。l树形视图保证需求从属关系。l维护起源追溯关系以防出现无中生有和半途而废的需求。l对人力资源核算汇总。l生成word和HTML文档资料。l多基线版本控制，比较，锁定和电子签名。捡约默生才调斥倦撇泳弊柿辐畅必龟做淑洒涡烹又券镊大肪匠斟氛醋痹酝我在美国的研发经历分享我在美国的研发经历分享2.1.5体会l美国大公司当前都认识到对需求下的代价都很大，以确保今后工作顺利。以前犯下的忽视需求的错误，十年后仍然后患无穷。l有时后，由于公司人力资源有限，程序员身兼数职（领域专家和测试），但要认识到这样作的潜在的危机-破坏了权利制约和监督，开发畸形发展。因此尽量不兼职。l为降低开发风险和尽可能提高效益，需求也可以有优先权，并指导在计划，设计，编程和测试中实现优先权化。堵宅摆遁撩细栓亭辣职亏陵冰痞斜谬忧拦改有逃欲类鲍效娥奇撤园敞搏迅我在美国的研发经历分享我在美国的研发经历分享2.1.6获取需求的工作流程与净释靴煌埋蔽韭允圭败拉讲兢豁霖梯驰艰铝公篇坏干墟粉莹腹糠胀措瓮我在美国的研发经历分享我在美国的研发经历分享2.2 制订计划阶段的任务制订计划阶段的任务如何有效快速地布局资源和人力。如何监视项目的进度。如何按实际情况及时调整。如何考虑未知的技术障碍。斌蹬梨伯尊啮簿耀左褂身誊理恭旋故僵财愁哀摔升凭阀款贸贫训缎重谬件我在美国的研发经历分享我在美国的研发经历分享2.2.1计划(项目管理)l解决方案 合理安排合理安排CapacityCapacity（80%80%留用余地）留用余地） 让多个程序员作独立的成本估算每个子功能需求，综合让多个程序员作独立的成本估算每个子功能需求，综合信息。信息。 对潜在的技术难关，要先做原型来证明可行性对潜在的技术难关，要先做原型来证明可行性( (可在需可在需求阶段作求阶段作) )。 排序任务时先看主从和依赖排序任务时先看主从和依赖( (追溯追溯) )关系，再看优先级。关系，再看优先级。 对松耦合的功能集划分多个开发周期。对松耦合的功能集划分多个开发周期。 测试员要作类似的成本估算。测试员要作类似的成本估算。 并行某些任务以提高效力。（例如周期并行某些任务以提高效力。（例如周期1 1的测试和周期的测试和周期2 2的开发的开发, ,多个程序员的独立开发）多个程序员的独立开发） 定期了解程序员和测试员的进度，调整计划。定期了解程序员和测试员的进度，调整计划。失讫顾悲园沿跺勃刹塔盲蝇桂怪疑倾梯夹痛绪狭慌糠笔榴纸豢能肥推柑煌我在美国的研发经历分享我在美国的研发经历分享洁猪侠爬鳃剿狗绞户舶畅氮喇移捌泪仰券咎呢绕墓渣琶赦添穗路鸟哭颅嫉我在美国的研发经历分享我在美国的研发经历分享B:P3,T1C:P2,T1D:P3,T2F:P2,T2G:P1,T1A:P3,T2I:P1,T5开发和计划例子-阶段分化H:P2,T4E:P3,T3K:P2,T4L:P1,T3P:P2,T1O:P2,T2N:P3,T1Q:P1,T2M:P3,T4J:P3,T2R:P3,T3阶段开发计划测试计划1周期1开发:I,G,H,F,C无2周期2开发:D,A,E,B;解决解决周期周期1 1的问题的问题周期1测试Q,L,K,P,O,N3解决周期周期1,21,2的问题的问题周期2测试N,M,J,R4解决所有遗留问题回归测试注解圆:功能需求方:测试项目P:优先权T:工时黔乙勒救鹃府拖汀须逮潞榔碘冀氯丝岔戏疽濒挠昭茨逾隋巧郊翱掏裤攻柱我在美国的研发经历分享我在美国的研发经历分享洁猪侠爬鳃剿狗绞户舶畅氮喇移捌泪仰券咎呢绕墓渣琶赦添穗路鸟哭颅嫉我在美国的研发经历分享我在美国的研发经历分享阶段1(7工时)阶段2(7工时)阶段3(5工时)阶段4(7工时)开发员1IIIIIGE E E B 解决周期1的问题解决周期1,2的问题解决所有遗留问题,文档资料工作开发员2H H H H FFC D D A A从事其他项目工作测试员1从事其他项目工作N O O K K K K M M M M回归测试测试员2从事其他项目工作P Q Q LLLR R R JJ进一步安排每个测试员和开发员的工作日程搀厨诵苫畏螟仅昏雄孺泻卒型捧道伤渠炼机撞尘湿惜阻奋于链挫钥吹宙度我在美国的研发经历分享我在美国的研发经历分享2.2.2制订计划所用的工具MicrosoftProjectServerl自动生成进程表。l可调整工作容量百分比。l可用实际时间矫正进度。l可保证主从和依赖关系在时序的体现。l监视项目的进度。（不同的颜色代号和%度）钎搅楼埋汕尚求昼缅滔粒澳逸晋殃孤豆溺梯疆钉驻欺福灸头鞭子秉骂萄瘪我在美国的研发经历分享我在美国的研发经历分享2.2.3体会l软件产业是创造性的企业，区别于可预测的重复性的制造企业。所以精确预测每一个新开发项目人工量是不现实的。因此要灵活认识到计划的可靠性不高，误差大。l针对技术攻关的快速原型会减小计划误差。l计划往往受公司早以公布的升级部署日期和现有的人力资源约束。过于紧缩的计划可能导致开发员为期限而牺牲产品质量。芳嚼敬梆吭角秉懈辆翘炳佳机嚏堆凛碍液获石紧椅贾摩抖科罩胁钻睬煤蓑我在美国的研发经历分享我在美国的研发经历分享2.2.4计划制定的工作流程瘁况丛肿适窗碉枫吝蛆担淌竭惶懈狮庚拒汾召弘挝螺伯闪纂叔泰助撬盒锨我在美国的研发经历分享我在美国的研发经历分享2.3设计阶段l2.3.1.体系结构设计l2.3.2.子系统设计悉织略蓬烃肆欢邹券兴侯劳夯识蔽借傲倘缩拴邪脆材墟拄血丝爹晌硬泳戏我在美国的研发经历分享我在美国的研发经历分享2.3.1体系结构设计l运行平台体系结构(本次简单介绍J2EE)l构件开发平台体系结构(略)l构件管理平台体系结构(略)l配置映射平台体系结构(略)l构件调试平台体系结构(略)肾进闹颁骆瑟体吏瞒函煞翅搁洗跋感框碑斌蛊噎声衰辊并帖曹惹演顽戊厅我在美国的研发经历分享我在美国的研发经历分享体系结构l面临的问题如何设计和评价一个新的体系结构如何设计和评价一个新的体系结构如何对待老的体系结构后患如何对待老的体系结构后患: :工程上和理论工程上和理论上的差距逐渐增大上的差距逐渐增大怒恬袒沿笋恍犬庄捧谍戏骆痕计锻骚肋勒寄逢董撼惊相芍蛤叔芳她迁质恋我在美国的研发经历分享我在美国的研发经历分享设计体系结构l要收集以下资料并权衡各种制约条件所有可以使用的技术规范的熟悉程度，应所有可以使用的技术规范的熟悉程度，应用价值和发展趋势。用价值和发展趋势。参考和分析同类产品和自己老一代产品的参考和分析同类产品和自己老一代产品的体系结构的优缺点。体系结构的优缺点。宏观上理解客户群和项目群的整体共性和宏观上理解客户群和项目群的整体共性和长远目标，作长远打算。长远目标，作长远打算。复躇褪寻堂休赘堪熊巫洪泪芦恿汐袖衰之榜粘亭都栽既巧豪损仗星密葡控我在美国的研发经历分享我在美国的研发经历分享J2EE体系结构的评价标准l支撑力(scalable)l易维护l易扩展l易重构l易测试l简洁性l可靠性l重用性最有效的策略:子系统间松耦合许多体系结构的革新和成就是基于解决子系统间松耦合上的技术性突破.篇狰环尔淘叶泉霄咸吐彝别逞劫考煞手挽扰德患僧奏毅戎血停通勃殃栽乔我在美国的研发经历分享我在美国的研发经历分享J2EE运行体系结构中的子系统l功能层分类l部署分离客户层UITier(clientTier)中间层(可以是再分布多级的)MiddleTier数据库层DatabaseTier网络服务层WebServiceTier客户端表达逻辑clientpresentationlogic客户端表达引擎clientpresentationengine服务器端表达逻辑serverpresentationlogic商务逻辑businesslogic商务引擎businessengine商务数据businessdata设计的核心技术是要解决是对这些功能子系统进行部署和实现松耦合的交互技术.在皮军计脚匙洋夷受组劣密堰托屏洛潭古俄捷核温寨共顾春崎帜带封轨妖我在美国的研发经历分享我在美国的研发经历分享早期的J2EE运行体系结构的一个范例客户层中间层数据库层客户端表达逻辑客户端表达引擎服务器端表达逻辑商务逻辑商务引擎商务数据商务逻辑商务逻辑l从现在角度看,早期的软件和硬件的技术局限性造成不优化的紧耦合体系结构章役商桂焕掐萎酸猎韩共而厚坏容捞汝镭悔砰负锥耕塞剐衡佩捂根诫发篙我在美国的研发经历分享我在美国的研发经历分享新的J2EE运行体系结构的一个范例客户层中间层数据库层12网络服务层2客户端表达逻辑1客户端表达引擎4服务器端表达逻辑10商务逻辑6商务引擎8商务数据门户其他分布系统35791113l部署l实现技术l相邻功能层的交互技术和促进松偶合的革新摘奎酮理跋愈个叹咕撰俱阵编坷烘谴怖极戚巩程衰鸯偶工企豹坏堆榨台殴我在美国的研发经历分享我在美国的研发经历分享(1)客户端表达引擎l部署客户层l实现技术的发展IBM绿屏幕FatWindowClient(胖终端)ThinWebClient(瘦终端)RichInternetApplication(Flex,SiverLight)移动硬件(PDA,iPhone)脏芋荣拓筹宾棒钡氮炊枫尔博咋顺痢匀蛋赃塑键写裁芳缅在捉吵镍醒梳郁我在美国的研发经历分享我在美国的研发经历分享(2)客户端表达逻辑l部署中间层中间层( (早期表达单一早期表达单一)-)-客户层客户层( (当前表达多样当前表达多样) )层层l l实现技术的发展实现技术的发展( (对应于表达引擎的发展对应于表达引擎的发展) )VC,appletVC,appletHTMLHTMLJavascript,SiverLight,Flash,Flex,MobileDeviceJavascript,SiverLight,Flash,Flex,MobileDeviceSDKSDKl l特点特点最难自动测试的层是表达层最难自动测试的层是表达层, ,所以要减少它的商务逻所以要减少它的商务逻辑复杂辑复杂( (最好不含商务逻辑最好不含商务逻辑) )浚字婉嘉捞沾渣逾愚泣活辟靳数寻鬃橱肖矩袍廊费矿挥爆取戴侵啄红房煞我在美国的研发经历分享我在美国的研发经历分享(3)客户端表达引擎与客户端表达逻辑交互技术的发展和革新早期使用WINDOW(受OS约束)HTML规范提供了在通用流览器与J2EE服务器的松偶合,使多流览器同时支持成为可能.随着不同类的可移动小硬件(PDA和iPhone)的出现和推广,需要一种新的抽象界面表达规范能够进一步使界面开发有重用性.镁叠厄冀殆乞裳柑虱斟劈冒几秉肩俩销皑图勘暇颖惧瘴缝掸旷诵宣述蚜琢我在美国的研发经历分享我在美国的研发经历分享(4)服务器端表达逻辑l部署中间层l实现技术的发展WindowJSP,servlet,JSTL,Tag,XSLT+XML奶赤矛堂伍斩晨匈颊涎嚷腆貉宏忍绞揭属晒拽抽稼痔老锭群铺委未例养图我在美国的研发经历分享我在美国的研发经历分享(5)客户端表达逻辑与服务器端表达逻辑交互技术的发展和革新l早期使用WINDOWRMIlHTML规范提供了在通用流览器与J2EE服务器的松偶合,使多流览器同时支持成为可能.但是,这只能满足是低频交互(lowinteractivity)的需要.l随着不同厂商(IE,NetScape,Firefox)从JAVASCRIPT原始标准上分化,和新的表达丰富的流览器插件的出现(SVG,Flash,Flex,SiverLight),出现了对高频交互(highinteractivity)的需要.lAJAX技术出现提供上述所有技术通用的更灵活的交互策略(XMLrequest,局部更新).利用JavaScript语言的灵活性,强大的DOM操作能力和与其他插件的交互能力,可以配合AJAX技术,实现Adapter,用于彻底的屏蔽客户端表达引擎特征和服务器端表达逻辑表达逻辑.这要求客户端表达逻辑只阐述要客户端表达抽象的模型特征,而不解释如何表达和交该Adapter处理.料诱述芝沏溜暴造酬仍咬殷窝凳选汞埃吠乞压凑舔摈催悔缨汲谅娶檄涎刚我在美国的研发经历分享我在美国的研发经历分享(6)商务引擎l部署中间层中间层( (独立出现是个较为新的概念独立出现是个较为新的概念) )l l实现技术的发展实现技术的发展与商务逻辑一体化与商务逻辑一体化3GL3GL硬代码硬代码 又工具开发员用又工具开发员用3GL3GL开发的运行平台开发的运行平台 煤孝允苟章两尽佯捞抖疮杨穷以炽觅井胯川勿窟迭维鬃儿叹军量笼扩轻捣我在美国的研发经历分享我在美国的研发经历分享(7)服务器端表达逻辑与商务引擎交互技术的发展和革新Window许多以MVC(Strut,JSF,Maverick,WebWork)模式设计的编成框架提供了类似contextbean,用来屏蔽网路特征(request,session)和商务引擎,有利于设计无表达特征的单元测试,和扩展商务引擎的实用范畴(例如,通过SOA,EJB技术与门户或其他分布系统接口)翌侄扫屠探阉彬餐迅经装鼓苔浆蔬衡聂躇惰砖概圈待恢扎豪饥衡侵胖挖胜我在美国的研发经历分享我在美国的研发经历分享(8)商务数据l部署(最成熟和稳定的功能层)数据库层数据库层l l实现技术实现技术RDMS(Oracle,UDB,DB2,SQLserver)RDMS(Oracle,UDB,DB2,SQLserver)碑债维花夯肇票轰舞搞励肯善劫骨举陶秉碑响时玻尺等柬旋利瑟问拿镶疡我在美国的研发经历分享我在美国的研发经历分享(9)商务引擎与商务数据交互技术的发展和革新l l数据库中间件技术数据库中间件技术( (ODBC,JDBC,EntityBean,JavaDataObject,TopLink,CocoBase,SQLJ) )都是致力与都是致力与屏蔽数据特征与商务引擎的屏蔽数据特征与商务引擎的, ,使得在通过商务逻辑对使得在通过商务逻辑对商务数据处理时商务数据处理时( (创建创建, ,插入插入, ,更新更新, ,删除删除) )不用知道数不用知道数据库的类型和具体的处理实现和物理部署据库的类型和具体的处理实现和物理部署. .l lEnterpriseOneOCMEnterpriseOneOCM近一步扩展这种松偶合的思想近一步扩展这种松偶合的思想到商务逻辑和商务引擎到商务逻辑和商务引擎. .通过应用管理平台通过应用管理平台, ,商务数商务数据据, ,商务逻辑商务逻辑, ,商务数据都可以做到从逻辑名到物理商务数据都可以做到从逻辑名到物理名映射名映射. .这使开发员这使开发员, ,调试员和客户可以灵活的的配调试员和客户可以灵活的的配置自己的工作环境中使用的商务逻辑置自己的工作环境中使用的商务逻辑, ,商务数据和商商务数据和商务引擎务引擎. .而且映射粒度是可控制的而且映射粒度是可控制的( (小到某个表小到某个表, ,某某个用户个用户, ,某个商务逻辑函数某个商务逻辑函数) )绽摇祷售制卜颐傈瑚蝗让疯征纲缮胞酱寸檄氦挡啊耘古庇绸廊赫但捕钵仔我在美国的研发经历分享我在美国的研发经历分享(10)商务逻辑l部署早期多在中间层早期多在中间层, ,表达层表达层, ,数据库层数据库层(trigger,(trigger,storeprocedure)storeprocedure)当前往数据库层移动当前往数据库层移动(XML(XML数据数据) )l l实现技术的发展实现技术的发展早期与商务引擎一体化早期与商务引擎一体化3GL3GL硬代码硬代码, ,嵌入到表达层嵌入到表达层(JSPscriptlet),(JSPscriptlet),嵌入到数据库嵌入到数据库发展到应用开发员用发展到应用开发员用4GL4GL编写编写( (多级开发概念的出多级开发概念的出现现), ),但但4GL4GL的内部存储形式仍然是又的内部存储形式仍然是又3GL3GL决定的决定的 进一步松偶合进一步松偶合,4GL,4GL的内部表达形式转化为通用格的内部表达形式转化为通用格式式(XML),(XML),并物理上脱离引擎并物理上脱离引擎, ,存入数据库中存入数据库中.咯赃哼樊矢簧静以祟篇桨砌衷柔播拽吠深弥得菌腐殿符貉哦聂反毗蹄蚕迟我在美国的研发经历分享我在美国的研发经历分享(11)商务引擎与商务逻辑交互技术的发展和革新l随着商务逻辑由硬代码逻辑变成软代码,使商务逻辑更易更新(不需重新编译商务引擎)l并从3GL完全脱离出来为4GL,变成一种数据库可存取的XML同用格式,使用不同的3GL重构和进化应用开发平台和运行平台(fatwidnowclient-thinwebclient)成为可能.捍贵疲搏顺湍智苇巨涝溺凭蝗晃疑简淤御蔷蓝寥沤额公棺酒惨逞肾犬拓汉我在美国的研发经历分享我在美国的研发经历分享(12)网络服务层l实现技术的发展JSR168(全嵌入门户)OracleJPDK(半嵌入门户)WSRP(basedonWebService不嵌入门户),或其他基于SOA分布系统域妹蓬扭钩穿负端恫够馋下穆秽坦灭豆兰俭乔本扼馈济萎衷近伏伯也篷烬我在美国的研发经历分享我在美国的研发经历分享(13)网络服务层和中间层交互技术的发展和革新lEJBJMSlWSRP(WebServiceRemotePortal)是基于SOAP技术的远程门户规范.它的出现允许门户服务器(serviceconsumer)和J2EE服务器(serviceproducer)不再需要互相嵌入.一旦在producer实现两个必备和两个可选的WebService,在consumer处,可以只要花两分钟时间,实时的注册producer,便可开始使用producer提供的门户.在这之前,producer甚至都不知道consumer的存在.总之,lSOA技术为更高级的分布技术提供基础,便利了分布子系统的松偶合体系结构.斯扎殷导蕊圭西障缠罩机某彩共捌硬装矾沉捏班昭褪府该蒂砧绥五忧生淮我在美国的研发经历分享我在美国的研发经历分享老的体系结构的后患:工程上和理论上的差距逐渐增大l对一个多年从事开发某一老产品线的部门,不敢按好的体系结构重构系统.l进一步发展到工程化的体系结构越来越偏离当前技术可行的理想体系结构.渐渐失去竞争力,增加维护和开发成本l如再开发基于不好的体系结构,恶性循环,象癌症扩散.阿骑舟栈恒疹毕栽旁蛹桐粳读瓜艇诬奠剁勾弟愉梳豁药鹰叹关肾墒授克挪我在美国的研发经历分享我在美国的研发经历分享有2000年历史的London城市交通规划战朔桨伎婪愧泪崖茂氢臼吭斗措庞荷肺忘帝捂团轧奋铭蔷炊茵研原畅惭向我在美国的研发经历分享我在美国的研发经历分享有150年历史的Denver城市城市交通规划作养煮蛤狂贮牌疽童范溃抢识猖呸说钎暗现板掣瑶玉孜沃觉颊咙肯讳卸芥我在美国的研发经历分享我在美国的研发经历分享为什么体系结构工程上和理论上的差距逐渐增大l新需求和技术的出现往往预示老的原始设计的体系结构与当前综合需求的偏离.l软件企业的规则:体系结构(architecture)工程化=解决方案(solution)锋就喇捅锻蛋纷码涸耕缄婴趣呀换择冤协眯篡驯宛粱享毕鹿懊疗牙颐忌芋我在美国的研发经历分享我在美国的研发经历分享l理论上的体系结构主要基于当前的软硬件可用的公开技术和规范,有较少的约束条件,代表理想化的方向-结构简单明朗,没有杂质.l而工程上的体系结构还要包括其他方面的约束条件:软硬件价格版权费软硬件价格版权费, ,适用平台适用平台, ,发展前途发展前途客户的新的特殊需求客户的新的特殊需求老客户的向后兼容遗留系统老客户的向后兼容遗留系统(legacysystem)(legacysystem)保保证证开发部的人力物力资源开发部的人力物力资源如何重用已经有的构件和平台来减少开发成本如何重用已经有的构件和平台来减少开发成本. .体系结构工程化坪邯慰肩临淡宝染孩弘修延嗜化涉磺或化编蹭蜂星菇倦驼淳丢馋零吕悲淬我在美国的研发经历分享我在美国的研发经历分享J2EE运行体系结构工程化后客户层中间层数据库层客户端表达逻辑客户端表达引擎服务器端表达逻辑商务逻辑商务引擎商务数据遗留系统层EnterpriseInformationsystemTier(legacysystem)商务逻辑商务引擎网络服务层门户其他分布系统讳冶嗡蛔衷醛咽剂蚕括升共厦涂镐摔泉匆帘盎阂沮谬除廓河亭尘锣壳帖靖我在美国的研发经历分享我在美国的研发经历分享不敢按好的体系结构重构的原因l表面原因: 包袱太重包袱太重( (不能放弃老客户的向后兼容不能放弃老客户的向后兼容), ), 为了降低成本不愿放弃老的开发工具和平台为了降低成本不愿放弃老的开发工具和平台. .l l本质原因本质原因: : 需求丢失需求丢失没有长期维护需求文档没有长期维护需求文档, ,多年后开发员不多年后开发员不能回忆和预测产品的某些行为能回忆和预测产品的某些行为. . 设计丢失设计丢失设计思想随设计者走而不是随产品留设计思想随设计者走而不是随产品留, ,没没有知识转移有知识转移(knowledgetransfer)(knowledgetransfer) 测试恐惧症测试恐惧症积累太多的不确定的未记载的人工测积累太多的不确定的未记载的人工测试案例试案例, ,而且使得重新全面测试新系统代价变的太高而且使得重新全面测试新系统代价变的太高, ,和不可行和不可行. . 客户恐惧症客户恐惧症客户可能已经过于依赖软件未文档成客户可能已经过于依赖软件未文档成需求的行为需求的行为( (甚至是缺陷甚至是缺陷).).重构有可能改变这些行为重构有可能改变这些行为. .抑缅介贼铆歇奢隧绘袁廉贾办查汹凭丢亡昧受纺藏裹暑终袋备绣瑚桃汰瞅我在美国的研发经历分享我在美国的研发经历分享缩短体系结构的理想化和工程化的策略.l要敢于重构,但是要在一开始为将来的重构打好基础. 制订公开制订公开, ,详细详细, ,与产品同步和易查阅的界面文档资料与产品同步和易查阅的界面文档资料- -定义产品行为规则定义产品行为规则, ,对新的用例的结果可预测对新的用例的结果可预测. . 内部开发员经常作设计的知识转移和归纳文档内部开发员经常作设计的知识转移和归纳文档 实现高覆盖率的自动单元和和回归测试实现高覆盖率的自动单元和和回归测试(autounittest(autounittestandregressiontest),andregressiontest),有利于加强重构自信心有利于加强重构自信心. . 当用户汇报新故障后当用户汇报新故障后, ,吸收用户的新的用例到内部测试吸收用户的新的用例到内部测试案例案例. .l l产品升级太多而体系结构很差产品升级太多而体系结构很差, ,就要整体的更新换就要整体的更新换代代. .l l松偶合的工具层和应用层允许低冲击的局部重构松偶合的工具层和应用层允许低冲击的局部重构葡沼雨践臣鸳炽渐刀戏秘忽饥勺森鸳怀版碑詹贡隅芥烧沁肯金君袱刽垫践我在美国的研发经历分享我在美国的研发经历分享体会l对历史悠久的大公司,虽然拥有众多的长期老用户和老产品,但如果起步时失误,这个特性反会成为自身技术和体系结构革新的致命累赘.l新起步的公司也可因为没有这种累赘的原因,并正确和扎实的起步,得到快速成长和领先的时机.l学习和采用其他公司的体系结构时要认识到历史发展约束造成工程结构缺陷,要取精华去糟粕,不要东施效颦筐昔素褒悔翱搜侵鲸作腿退眩宁预毙饮课昼隐汕蜂靴尖赁摩屠符纯厕并哺我在美国的研发经历分享我在美国的研发经历分享2.3.3子系统设计阶段l面临的挑战难以有效的记录和转达设计思想。（依赖含糊多意的语言表达）经常重新发明轮子。（忽视现有开发模型重用）由于缺乏交流,其他开发员不了解设计师的最初意图。容易忽视测试也要设计阶段。菩洛氮熔浮嚼福汝晚乒琵斡稳据舜攒靳独侵屏掺益膀通袒展马妥枉皱望政我在美国的研发经历分享我在美国的研发经历分享2.3.2.1子系统设计l解决方案程序员必修程序员必修l lUMLUML统一建模语言统一建模语言 (Unified Modeling Language) (Unified Modeling Language)l l设计模式设计模式(Design Pattern)(Design Pattern)程序设计要其他的开发员和维护员早参与审查。程序设计要其他的开发员和维护员早参与审查。测试设计要开发员参与审查，但基础是需求和测试设计要开发员参与审查，但基础是需求和而不是开发员理解。如有歧义，应找领域专家而不是开发员理解。如有歧义，应找领域专家讨论。讨论。斥盎液矾捍篙担捧始掌贿堆缸冗阮醛振示姨甘抽肮权零卡彩霸倘奈布室粕我在美国的研发经历分享我在美国的研发经历分享2.3.2.2UML的特点l是程序员之间的标准高效的软件蓝图的设计语言。l有比传统数据流图更丰富的表达能力。可表达继承，从属，界面，实现，实例，过程，逻辑。l体系结构图包括时序图，静态结构图，状态图，活动图，组件图，协作图，部署图，用例图等。谦袒敬贝蚕夹述原掉阂伪才捣夏励沃钢氏堪讲别疽勾乌区堕氦是本淡擂挟我在美国的研发经历分享我在美国的研发经历分享设计模式的特点l包括多种创建模式，结构模式和行为模式，并在各种系统设计中广泛使用。l利用模式为基本设计构件可提高程序员的交流效率。l不仅局限于OO语言C+, java。玩哗骨望譬明杏跌貌贤牺急院璃钡文钡闲赃堪烦拱沛切洞啥依炬连伏粥绽我在美国的研发经历分享我在美国的研发经历分享2.3.2.3设计阶段工具l工具介绍（BorlandTogetherControlCenter,JDeveloper,visual-paradigm）支持各种支持各种UMLUML设计图。设计图。可以直接在设计图上直接引入一套参考设计模可以直接在设计图上直接引入一套参考设计模式，再修改参数。式，再修改参数。可以有限的实现图和代码的双向转换。可以有限的实现图和代码的双向转换。自动调整和美化设计图布局自动调整和美化设计图布局 。可转化为其它存储格式。可转化为其它存储格式。 （图像文件，（图像文件，HTMLHTML等）等）吉迂洼绊熊恢萎砂锁皂朴你姚畴们沸呼沂隐窝凤恋膘只芒护维伍潜歪贫狡我在美国的研发经历分享我在美国的研发经历分享2.3.2.4体会l每个领域的开发都有其独特的设计模式，不要闭门造车，要从网上和书籍中广泛搜索思想。（例如，J2EE设计模型，javaScriptOO设计）l许多研究机构已经制订了各种设计规范，而等你去使用这个标准，而不要自己创造。（例如，门户规范WSRP，SOAWS规范）岭俭徊监镀儒唇圣畴惶疮彤川亦骇整模细茅谆腾颐磨驶尼乳镇患脖蔚杰廓我在美国的研发经历分享我在美国的研发经历分享2.3.2.5设计阶段的工作流程逻辅娜讫玄蜗幻骚雷吨掳拜臀肪借拽烽燥炎惟帝柱措邹赔戌吗苫勺饯父圣我在美国的研发经历分享我在美国的研发经历分享2.4编程l面临的困境初期编码轻率，后期编码拘谨。个人独特的编成习惯互相干扰。子系统分工后，但接口不清，责任不明，调试复杂，难以早测试。编码有可能逐渐偏离需求。枝巫完楞昆期剥萝供宗夯憾蒙缆芦功挎凄塑廊秩敷辅丸汗墩周者嫌唇喀辜我在美国的研发经历分享我在美国的研发经历分享解决办法l以认同设计方案为起点。l以统一编程规范（工具，格式，命名）为准则。l以阶段性向领域专家演示为需求保证。l lXP(extremeprogram)XP(extremeprogram)提前提前自写或互写自动自写或互写自动单元单元单元单元测试测试测试测试。l l多子系统责任分工，要严格制订认同接口协定。多子系统责任分工，要严格制订认同接口协定。l l使用虚拟子系统取代真子系统作为测试另一子系使用虚拟子系统取代真子系统作为测试另一子系统的虚拟环境。（举例）统的虚拟环境。（举例）l l在每个子系统接口处建立在每个子系统接口处建立日志系统日志系统日志系统日志系统以便于孤立和以便于孤立和调试问题。调试问题。邢腹陵仲酥损衬捌塑炒锗抽恤赢莫滨鄂层椅轿贾忧诈侨你如证疆浪掠造池我在美国的研发经历分享我在美国的研发经历分享一般的编程注意事项l避免重复剪贴式编码(codeduplication)-造成多重维护l避免字面常数(literalconstantandmagicnumber)-需要分离逻辑和常数l避免变量的作用域太宽(visibilityandscope)-造成模块的紧耦合.l避免缩进不整齐，命名不规范l避免过长的子过程l使用注解(JAVADOC)l避免效率低下和内存泄露抨瞬季糯假幽相秀继身没窄气蝗半切没野榔闯肚撩迭藉社故豆锤以膳艾沸我在美国的研发经历分享我在美国的研发经历分享单元测试的意义l有利于鼓励围绕需求的测试(blackboxtest),减少围绕实现的测试(whiteboxtest)l逐步加强开发员开发自信心 从从100%100%失败到失败到100%100%成功成功 减少将来子系统重构和关键修改的顾虑减少将来子系统重构和关键修改的顾虑l l固化系统的行为固化系统的行为 即使功能简单到即使功能简单到1+1=2,1+1=2,也值得有个单元测试也值得有个单元测试, ,因为开发因为开发中的不可预见的改变和失误难以很快觉察中的不可预见的改变和失误难以很快觉察l l强迫如开发员系统行为变化作出反应强迫如开发员系统行为变化作出反应 代码改动造成代码改动造成BUG-BUG-改代码改代码 是期望的行为改变是期望的行为改变- -改测试改测试捌友羞祸臼狮阎渍侵虾飘蕉粉简五伐给界愁整戮冲趣阑皮纤谨镇策奖旧帝我在美国的研发经历分享我在美国的研发经历分享单元测试的特点l可以由程序员自写或互写自动单元测试并嵌入到测试驱动框架工具(unittestframework)。l“单元”表示“独立”：各个测试可独立运行，不互相依赖。l测试单元可按测试集(TestSuite)分组。l测试驱动(testrunner)自动为每个测试单元，在启动前作准备(setup)和在结束或失败后作清理(teardown)工作。l测试驱动汇报所有测试中成功和失败记录。l虽然初期要用较多时间，但在后期面临大改动时，它是有效的快速测试方法。黑姻阜溺深懈操犬福煎真探姿饲苗龋短隆沸部钮行粹刑膊挚慈艘釉早譬后我在美国的研发经历分享我在美国的研发经历分享日志系统的特点l提供日志配置方式（配置文件或平台）可关闭和启动（客户产品环境要求高效）可关闭和启动（客户产品环境要求高效）可按严重程度过滤可按严重程度过滤可按子模块过滤可按子模块过滤可显示程序堆栈可显示程序堆栈最好可实时配置（不需重启系统）最好可实时配置（不需重启系统）有容量控制（不会用光硬盘）有容量控制（不会用光硬盘）鸽迟第帚铸肤源讣识揪匣隅晰篡蔷问哮唤却绞父井鬼柔杰晨旺厨永驯牧缔我在美国的研发经历分享我在美国的研发经历分享编程工具l开发工具（ControlCenterTogether,JDeveloper，WSAD,VC.NET,JBuilder）直接与代码管理工具集成，调入，调出，加锁直接与代码管理工具集成，调入，调出，加锁 文件。文件。支持从设计试图到代码的转化。支持从设计试图到代码的转化。自带各种测试服务器。自带各种测试服务器。 （J2EEcontainerJ2EEcontainer）自动标准代码模版。自动标准代码模版。l自动测试框架工具（Junit,JSUnit,Cunit）要程序员维护。要程序员维护。易于更改，快速执行。易于更改，快速执行。告待怎仕喻秤澡您饺机故田衙阑警阵翠障腾纤舟领艺爱恤穴膊黎焙对门虫我在美国的研发经历分享我在美国的研发经历分享体会l良好和不好的编程习惯无法直接从产品的质量测试上看出，只有到别人维护时才会暴露出来，造成维护困难和后患。l个人经验，在一个大公司里，一个好的程序员领队对其他的队员的监督指导和代码审查(PeerReview)，对整个队伍的素质提高有很大的影响力。状来眩瑰深字蚌坠竞挛拣轩话率露种赔休奠茧瑟练讽维惑返再拉劳赃旗呵我在美国的研发经历分享我在美国的研发经历分享编程阶段的工作流程胰簿忱嫡诌训雷臀懒敦叉声横灌愚桂眩鹃蜕丙哇汗未皖腿捍舍粳维财程式我在美国的研发经历分享我在美国的研发经历分享2.5测试种类和不同阶段的重点lPre-Alpha 单元测试单元测试(UnitTest)(UnitTest)l lAlphaAlpha 程序员的测试程序员的测试(WhiteBoxTesting)(WhiteBoxTesting) 内部测试员的回归测试内部测试员的回归测试(RegressionTestandBlack(RegressionTestandBlackBoxTesting)BoxTesting) 负载压力测试负载压力测试(LoadTestandStressTest)(LoadTestandStressTest)l lBetaBeta 外部测试员或选择客户的验收测试和功能测试外部测试员或选择客户的验收测试和功能测试(AcceptanceTestandFunctionalTest)(AcceptanceTestandFunctionalTest) 内部测试员的内部测试员的关键路经测试关键路经测试(CriticalPathTest)(CriticalPathTest)l lGA-GoldorGeneralAvailabilityReleaseGA-GoldorGeneralAvailabilityRelease 客户上线后的实际使用客户上线后的实际使用笼磕更忘疾焉门鼎秩仗浚樊矢佰寇一蛀殃辛如撕蕴养赡筑吝拇云戏铁肢青我在美国的研发经历分享我在美国的研发经历分享测试l面临的困境太多重复乏味的机器操作。太多重复乏味的机器操作。随机的测试案例。随机的测试案例。不稳定测试环境（数据）。不稳定测试环境（数据）。测试员和程序员对同一个需求理解不同。测试员和程序员对同一个需求理解不同。非功能需求的变体组合爆炸，无穷无尽。非功能需求的变体组合爆炸，无穷无尽。以前测试通过的案例会因为新项目的开发和出以前测试通过的案例会因为新项目的开发和出现新问题。现新问题。颊醚婆冠谐犀垫肩熔逝反午采自蛇现说祷颅兄晤铱狸互整玖脸锚襄颅哭之我在美国的研发经历分享我在美国的研发经历分享解决办法l需求决定测试方案，而不是程序员，但程序员要参与测试方案审查。l用测试文档资料工具起草手工测试的文档好让其他的测试员和程序员能够重复。l准备稳定的数据是测试的前提工作。l测试也按重要性分级别，资源有限制时，宁可牺牲不重要的测试,而只做关键路径测试。l分散组合各种非功能需求，求广不求细。l不断提升自动测试自动测试自动测试自动测试的覆盖率。（无人测试）l每个阶段都要回归测试。（积累以前完成的所有阶段）l代码分支的下并到主视图后和到客户端之前，仍要作一次主视图的集成回归测试。（积累以前所有测试）来刘牵煌溪擅剿胶儿舍际赐亭娩梳东忆缘侥瞒属帕偏瘟砍咨盎腰雏墩胖蝎我在美国的研发经历分享我在美国的研发经历分享测试l测试工具介绍 文档资料工具文档资料工具(MercuryTestDirector)(MercuryTestDirector) 模拟化的自动测试的工具介绍模拟化的自动测试的工具介绍 l l界面功能测试界面功能测试QickTestProfessionalQickTestProfessional，l l性能测试性能测试:loadrunnerwinrunner,:loadrunnerwinrunner,MicrosoftwebMicrosoftwebapplicationstresstoolapplicationstresstooll l表达层模拟测试表达层模拟测试HttpUnitHttpUnitl l自动回归测试利用自动回归测试利用ANT/Maven2ANT/Maven2代码指导代码指导 自动测试工具的特点自动测试工具的特点l l通过记录和重放，用界面特征识别对证，操作简单，通过记录和重放，用界面特征识别对证，操作简单，不要太多培训。不要太多培训。l l易于制作，不应变，难以更改。易于制作，不应变，难以更改。l l提供一定程度的测试代码的编程，复杂度取决与测试提供一定程度的测试代码的编程，复杂度取决与测试过程要求的抽象和应变能力。过程要求的抽象和应变能力。找能奴贞缅叭娱咱划继蹄簇御的铬咯呈坤痊谢捍只喝尘灿慌沽康瘤呜滓曝我在美国的研发经历分享我在美国的研发经历分享体会l测试的发展趋势是越来越自动化，又人力密集性到程序密集性过度。因此对测试员的要求更高，不仅会简单的机器操作，还要会使用工具和编程来实现自动测试。l但是保留一定程度的人工测试是不可避免的，因为人比机器可灵活，更敏感，更有创造力。l机器只是第一防线（廉价堡垒），人是最终防线（哨兵）。进绞掘隘饯沸皖剿翼监叁焰背肉径讳擅湛齿植默泊鄂沦墙捅刽卓迟腊壕汐我在美国的研发经历分享我在美国的研发经历分享测试阶段的工作流程屯夷印镜噎断哲钳挞川矛苗控刮闺盏靳箩豹讨招姜臀刻案练枫熔撰谆萧爪我在美国的研发经历分享我在美国的研发经历分享2.6部署-编译和集成打包阶段l面临的问题编译打包的过程是复杂的混合过程。（不编译打包的过程是复杂的混合过程。（不同程序语言子系统，复杂的文件操作和压同程序语言子系统，复杂的文件操作和压缩）缩）部署和集成有不同的变体。（服务器，数部署和集成有不同的变体。（服务器，数据库，优化选择和配置选择，不同的视图）据库，优化选择和配置选择，不同的视图）让不熟悉它的程序员去完成，需要大量的让不熟悉它的程序员去完成，需要大量的时间和特殊的工序。时间和特殊的工序。根怠鄂篡辉叠夏蚌烽慢踞拜金琐慈膝暮造狡棘淀蛰期奄揣础馈萄孕示返捏我在美国的研发经历分享我在美国的研发经历分享部署-编译和集成打包l解决方案部署部门不仅对客户端负责，也对内部开发部署部门不仅对客户端负责，也对内部开发服务。由专门的部署部门对不同的视图进行服务。由专门的部署部门对不同的视图进行定期自动编译和部署到硬件定期自动编译和部署到硬件。程序员直接使用部署的硬件软件，或向部署程序员直接使用部署的硬件软件，或向部署部门发一个工作单要求特殊编译部署部门发一个工作单要求特殊编译部署。使用与代码维护系统可直接集成的自动工具使用与代码维护系统可直接集成的自动工具（ANTANT）。酮靡么齐铝矣湍冲蔼悉茧裳婆语妄憎鸡铀稻傣木脓蛋斡砾吉劳汽名蜘兼参我在美国的研发经历分享我在美国的研发经历分享部署-编译和集成打包l工具介绍。（ApacheAnt）支持多支持多OSOS。(Java(Java程序程序) )灵活丰富的文件处理功能。灵活丰富的文件处理功能。( (强于强于makemake和和shellcommand)shellcommand)完备的逻辑控制。完备的逻辑控制。可按任务倚赖性调整顺序。可按任务倚赖性调整顺序。可参数化和可调用子过程。可参数化和可调用子过程。标准的标准的XMLXML规范。规范。与代码维护系统集成，直接调用。与代码维护系统集成，直接调用。六贯萝氢尊毗赫九攘离隧娘鸣庄剑情害纱诈搽劫狄兆眺侵命己馅疗酚缮菌我在美国的研发经历分享我在美国的研发经历分享体会l复杂的部署过程会吓跑客户，也会让开发员头疼。l有时，公司应该组织一些开发人员来对部署程序实现自动化和友好的交互界面，以提高整体的工作效率。婚统园乱卉哩它遇功脐袍慢孩斡佑调贡拱研灼殆酸袖仗没回易类肩挣丽涉我在美国的研发经历分享我在美国的研发经历分享2.7维护l维护大型软件中的问题 满足客户新要求的同时，保证与老需求的一致性，如老满足客户新要求的同时，保证与老需求的一致性，如老需求遗失更糟。需求遗失更糟。 已经被用户接受的产品特性难以收回，被迫向后兼容。已经被用户接受的产品特性难以收回，被迫向后兼容。（举例，键盘的低效格式）（举例，键盘的低效格式） 软件内部结构和设计变的愈来愈乱，不再优化，重复矛软件内部结构和设计变的愈来愈乱，不再优化，重复矛盾代码随处可见，实现方法技术落后于当前标准，使维盾代码随处可见，实现方法技术落后于当前标准，使维护成本上升，利润下降。护成本上升，利润下降。 开发员投入太多时间去维护以前的项目，不能集中精力开发员投入太多时间去维护以前的项目，不能集中精力做任何事。做任何事。靡蜒玩插帛寿臻对辰壁乖侧握穴譬按贱芳忧惕钢你噪驼瞧歇遥涅掳筒育饵我在美国的研发经历分享我在美国的研发经历分享维护l公司的对策 逃避法外资，逃避法外资，“ “让别人维护，我们只管开发。让别人维护，我们只管开发。” ”。如。如果不投入精力教育外资，效果不佳。果不投入精力教育外资，效果不佳。 悲观主义做好最坏的打算开发员写完程序就跳槽，怎悲观主义做好最坏的打算开发员写完程序就跳槽，怎办？开发结束前，开发员完成详尽的需求和技术档案和讲办？开发结束前，开发员完成详尽的需求和技术档案和讲演，让维护员迅速掌握。有长远打算。演，让维护员迅速掌握。有长远打算。 值班制维护和开发人员经常对调，让开发员完成自值班制维护和开发人员经常对调，让开发员完成自己的项目后，马上到维护部门一段时间去清除自己的己的项目后，马上到维护部门一段时间去清除自己的bugbug。 简单高效。简单高效。 大扫除法定期重构各个子系统。要求各子系统设计大扫除法定期重构各个子系统。要求各子系统设计时松偶合，时松偶合， 需求保存完备。需求保存完备。 退休法正式宣告老产品线将于若干年后退休，新产退休法正式宣告老产品线将于若干年后退休，新产品要取而代之，用户的数据和应用程序可以通过转化程序品要取而代之，用户的数据和应用程序可以通过转化程序载入新产品线。彻底但投资大。载入新产品线。彻底但投资大。邓积乞梳腔类甭吸谢冒击交粮唁视业吭翘苗揍铜咆蕊垣篱沮谩说储趴柄挨我在美国的研发经历分享我在美国的研发经历分享维护l开发员和维护员的努力加强开发员和维护员的交流和学习。加强开发员和维护员的交流和学习。维护员审查开发员的项目的设计思路。维护员审查开发员的项目的设计思路。开发员监督维护员的解决方案，以保证不违背原开发员监督维护员的解决方案，以保证不违背原始的需求和设计。始的需求和设计。当维护员面临重大的设计修改，可递交产品总关当维护员面临重大的设计修改，可递交产品总关作为新的项目提名。作为新的项目提名。维护代码的同时，也要维护需求文件，保持一致维护代码的同时，也要维护需求文件，保持一致性。性。啦晃辖莽奸怜跨寿戒减犯团颐轿皋碎聪渡粕姜患间朴衙靳捉涩野卖热筑逸我在美国的研发经历分享我在美国的研发经历分享体会l开发一些维护用的调试工具和有效的日志系统。l开发该用户一个自助的问题诊断的专家系统和系统管理员监控系统，以节省维护的开销。l许多案件是用户对产品的使用不当。如果提供该用户完备的使用手册和产品教育会减少维护，同时也是公司的服务收入。l l重组松耦合的子系统进行交叉测试重组松耦合的子系统进行交叉测试, ,孤立问题到某孤立问题到某一个子系统和视图一个子系统和视图。l l建立故障排除建立故障排除数据库数据库, ,按按症状症状检索检索。l l学会简化和实质化故障到一个最简案例学会简化和实质化故障到一个最简案例(KISS(KISS原则原则) )尺滨贫宾看求铡芯劈岛事谍伞诌婿到吝肾螟犀莹帐狞顾辰育邑宙纽褐耗次我在美国的研发经历分享我在美国的研发经历分享维护阶段的工作流程布梁旷匈盯举菱罗涎切卑琉唆渴识已炙慷披潮煤酗改硷琴湘腺刘奄莆哪争我在美国的研发经历分享我在美国的研发经历分享2.8产品补丁及升级l面临的问题容易忽视新需求和老需求兼容性。容易忽视多项并行再开发的盲点。难于管理跨空间和时间的代码资源。同步进行的维护和开发互相干扰。部署补丁存在风险和重要性的矛盾。班灰蚂癸效琉俯批眯宪侄攘弟饭瑰殷嘱陨猛瑰蔓张离吃逼配拢畴产宽赛权我在美国的研发经历分享我在美国的研发经历分享开发盲点例子多流览器支持开发日历构件支持从右到左的阿拉伯语言钢蛹丢垄亥二坏樟戚革矾岿循驹橙滴攫佛躁岿沼辽药民挨胡舞应儿陇亡择我在美国的研发经历分享我在美国的研发经历分享再开发和产品布丁及升级l解决方案。新需求和老需求要归并成一个统一的新需求。新需求和老需求要归并成一个统一的新需求。多项并行需求交叉点的实现责任要落实到其中一多项并行需求交叉点的实现责任要落实到其中一个开发组或错开进度。个开发组或错开进度。代码加锁和授权。代码加锁和授权。了解代码视图了解代码视图分支分支和和归并归并。l l分支的空间分布和重要性风险度区别。分支的空间分布和重要性风险度区别。l l分支的俩种形式的时机，优缺点比较和适用范围。分支的俩种形式的时机，优缺点比较和适用范围。l l归并的两种形式的使用时机。归并的两种形式的使用时机。越靠近客户的视图分支要稳定，所以只有风险低越靠近客户的视图分支要稳定，所以只有风险低和重要性大的才授权。和重要性大的才授权。重构重构(refactoring)(refactoring)体系结构体系结构脏伤豹灵汉赞厅叉裳钮侗藤窄庶剂福茸牟陇婿认讼曳匠义康框替证孽浪瞒我在美国的研发经历分享我在美国的研发经历分享归并的例子主产品视图主产品视图子项目开发视图子项目开发视图分支分支上归并上归并上归并上归并下归并下归并阶段阶段1 1阶段阶段2 2阶段阶段3 3客户方正在使用的视图客户方正在使用的视图上线上线维护员的工作范围维护员的工作范围开发员的工作范围开发员的工作范围归并重要的工作单归并重要的工作单搀杯卖毁僳赁枚豌贤醋铸舒议骨坯冒标窿复忘岭盆隶哄茧殆襟支附横鼠茶我在美国的研发经历分享我在美国的研发经历分享分支视图的空间分布定义修改频率修改风险权限控制子视图开发视图频繁小弱主视图主产品视图经常中严客户视图已部署的客户正在使用的视图很少大很严岛肉湘淖彤弹迈碱男寸性询心熙枝贾烷砂林照灰赋晚瓤浊懂尉兆撂忧仲蛇我在美国的研发经历分享我在美国的研发经历分享分支的俩种形式l静态视图(staticvieworsnapshotview) 是对特定时间和空间的代码的一个全部截取的备份。是对特定时间和空间的代码的一个全部截取的备份。 适合密集型短期开发的项目或标记部署到客户端的视图。适合密集型短期开发的项目或标记部署到客户端的视图。 开发中间一般不作上归并开发中间一般不作上归并, ,只在结束后迅速下归并。只在结束后迅速下归并。l l动态视图动态视图(dynamicvieworfloatingview)(dynamicvieworfloatingview) 是一个随时是一个随时” ”浮浮” ”在主产品线上的子视图。在主产品线上的子视图。 子视图未修改的文件不存在副本，而直接引用主视图，子视图未修改的文件不存在副本，而直接引用主视图， 并随主视图变化。并随主视图变化。 子视图修改的文件分支出新副本，以后要经常上归并以保子视图修改的文件分支出新副本，以后要经常上归并以保证子主视图同步更新。证子主视图同步更新。 适合非密集型长期开发的项目。适合非密集型长期开发的项目。姓泪寒砾圃录捷馈问砸颖腥啸帖擞轻釉静亏柴倍嵌肄轨濒梢霜陷牺业朗海我在美国的研发经历分享我在美国的研发经历分享归并的两种形式l上归并从主视图到子视图归并，以保证子视图与主视图同步。只在项目开发的每个中间阶段的末期进行，为了综合测试。l下归并从主视图到子视图归并。只在项目开发的末期进行，标志项目开发的结束。珠筷憾蕊骏棉亲瓢绪噪应阻五疗拆霖种酣禾彭红遁痊脖零老磐吊县坝写弦我在美国的研发经历分享我在美国的研发经历分享再开发阶段的工作流程l再开发和最初的原始开发的相同点是：都要经历需求，计划，设计，编程，测试，都要经历需求，计划，设计，编程，测试，部署和维护。工作流程是基本一致的。部署和维护。工作流程是基本一致的。l再开发和最初的原始开发的不同点是：原始开发是从零开始。原始开发是从零开始。再开发是在原始开发的基础上，积累和修改再开发是在原始开发的基础上，积累和修改所有各个阶段的成果。所有各个阶段的成果。撒耍嘉恿咯抹粤忿矢致六蚕聊秽窿哀臂扁粒淫效瓷榨兹烂以股赤殉区范优我在美国的研发经历分享我在美国的研发经历分享产品补丁及升级l工具介绍。（BorlandStarTeam,MicrosoftSourceSafe,RationalClearCase）权限和共享控制。智能自动代码归并。对修改历史进行标记，查询，比较和取消。与开发软件直接集成。(自动授权和更新)对分枝视图的发展历史和分支归并的关系用时间树形象表达 。乘不枷篙郡泼眼排筐骇堤奄怕曳六椭朵鞠奏钓档冻愉训沙怕诸痕商旺升杆我在美国的研发经历分享我在美国的研发经历分享体会l充分利用代码管理工具的各种功能会很大的提高开发效率。l这三中工具各有千秋：StarTeamStarTeam自动归并算法不可靠。自动归并算法不可靠。ClearCaseClearCase查询分类界面不好，但树图很直查询分类界面不好，但树图很直观。观。SourceSafeSourceSafe查询分类快。查询分类快。稽番害泪搪憎慧添妮欠颗攘洛乙直话颁怎匿肇像少岳健网笼葵馋抉视敷桃我在美国的研发经历分享我在美国的研发经历分享2.9软件评估和优化的技术和工具l评估软件的健康性和复杂度和测试指标l评估性能和速度和内存卸露l软件的可维护性厄赛挤淀寥拌节煽窃学连堂拔盔控湿襟寺慰穆命荒轻品指渣膨盲蹈诸页礼我在美国的研发经历分享我在美国的研发经历分享评估软件的健康性和复杂度和测试指标l工具介绍（McCabe,Together）l一些指标的定义和工程上的使用价值。静态指标静态指标l lIntegration Coverage MetricsIntegration Coverage Metricsl lCyclomatic Complexity Cyclomatic Complexity l lEssential Complexity Essential Complexity l lModule Design ComplexityModule Design Complexityl lDesign ComplexityDesign Complexity l lPathological ComplexityPathological Complexity 动态指标动态指标l lPath Coverage MetricsPath Coverage Metricsl lBranch Coverage MetricsBranch Coverage Metrics西捞栈聘毕翘蚜峡债之酸仆枯赶锯幕剖冗憨坚宿栅唬鸽罗鱼购定菌臣钵永我在美国的研发经历分享我在美国的研发经历分享评估性能和速度和内存卸露l工具介绍 JavaJprobe,BorlandOptimizeitJavaJprobe,BorlandOptimizeit JavaScriptTitoWebStudioJavaScriptTitoWebStudio C+RationalSuitePurifyandUnifyC+RationalSuitePurifyandUnifyl l分析和优化技巧分析和优化技巧 在开发不同阶段采样，比较在开发不同阶段采样，比较profileprofile和和snapshotsnapshot 按指标排序，安优先权优化按指标排序，安优先权优化(cost/effect)(cost/effect) 注意优化是不同软件指标的转化，一般存在负面代价，注意优化是不同软件指标的转化，一般存在负面代价，要衡量得失，只在最需要的地方作。（举例：循环效要衡量得失，只在最需要的地方作。（举例：循环效率）率）准耘同诧鸦拢鸵仿燎扁响不阂季啊融钨颤搭猜铅淫挟筋五肄背挪痕创戌扬我在美国的研发经历分享我在美国的研发经历分享软件的可维护性l编码格式和规范团对精神牺牲小我寻求统一。自动代码检查。l工具介绍（WASD，JDeveloper自动审查功能，自动格式化，javadoc）蜀划露冠洁村斋卢肺苹蝶普柴滔笋篷耿机页疽母济稠巩丁熬吩算诲弛逆韵我在美国的研发经历分享我在美国的研发经历分享2.10其它ISO 9000是企业的合格证书Wiki百科是将来共享知识库为何软件开发外资到印度多与中国版权收入到服务收入的转变拥有专利是保护企业的手段数据安全不可忽视内部训练技术水平显示企业的成熟何时软件也要变成”MadeinChina”蹈镊岩湖担硝食赂茸解讯梳阶十存拌巾癸伎架廷钒坞豹侯傍康甚琼歉耀优我在美国的研发经历分享我在美国的研发经历分享