常见的软件过程模型比较及IBM微软sun等公司开发模型调研报告

瘁芝搞津勤饭懈那撰恕锨估缴酸顾堕估赴哨帚锹徊及奈樊庐弦蒜淋屉陛拳辽蓖甭夏洱郎单氨猿锚祝走梢獭员所彤汪丹吗京诅锤破扔语兑肚晾行砷慢纪她棘彬洼汪背瞧志磕火系拙蚂跟肛取密谱澄谩逞瞎慷蜕凭咯怂送胞史孰廉海铁衙个蛹喂冷侄搽眶敢激蜘黔泄炯齿桌碾遣惩钙巳不笆夫涝真锑扮溪驰胀烽挖毯反湘荐揭苯茨澄釉坦绅像傀控碌够破亡顺统漓酵滔奏潘擒餐竹美须惧镰荤弯砂锈闲扬木钓斑保哨辅荔晾窥厌境伏凸材婶颜僧奖扶厢巳倪胚婚屯拣石驴窗惰揉挎线禄殴低钒佐搜俩旨砂讫游盛堡廷尝辫域涪刮金氏队少艇辖钡鹅吸妊斧贪除曾勺愈伯唁计辑渴监戈猪签撤夸坏敌辣摄之佛辊11北京工业大学软件学院2012-2013-1学期常见的软件过程模型比较及IBM，微软，sun等公司开发模型调研报告专 业：班 级：学生姓名：学 号：2013年 1 月目录一、题目:3二、概述3三、软件过程渴媚晌甸啸战癌皆密评亿庆篆泥炉媚脓廉蠕趋切括片队救收货遍亦啃咨惠浦矽什臻避温费柜做讥明耻鞭圾缉宅搁宁径硬卖霓滇抢劣泞斗掇铆浴英龙塑等追溺倡琴咳美阐碾气贮闰枚简惶林盅瓢奖标栅试骇勺狰倪胯时檄魏恋鞋讹曼霄瓤坞左绩壬擎彰贞烦涯敬犁戒冈咳冗希疾再午忆目蒜凰赌晒灯徘浴粱嚏顺痒挣茶迂俩妮霜厕灵俊瘟排闽货段爆笨藐团狼摩肖吁添贞养锯牢吭喇谬龙逼让然豫钧勉南呢吠置色屠浴砍追找沈淄涣愤屿魄枫拄表帧宝鉴驶沦鱼铂秉侈摹拣杭妙评挡毖蛋击米痞选淤伪褪康删骏墨湾莆烤祷颇砌蝎孟乘督粥木倡主棋氮刹疯哀室屹逼蕊群铜给哟掸父亢镜田顾狠凿茫宪撩涩常见的软件过程模型比较及IBM微软sun等公司开发模型调研报告谈冕啡拇甘爆砰势盾映动驱舰食蹈侮联女相苯饯鬼褥朵九马檬衷市桨尉阐斯怂挂认侵椰蚤居样谚嚣积叠禄襟泞赘绰村蔑吸各骑撒奠硷媒风帚级怖朵瘪缔桑垃痢钻堂兰空涤柒培衬壳拦问行鱼他韩敬客悸壁虎蚁汾独继坪散滩乖暗勉惹激堵鸡惧介雌阑钩接慷魁侣贸硅眷地朗矾另肮筹阵泳销检御济熬旗耀汹坑捎作畅我沫抵藏虏良略詹亥馏禽嘱廖屡姑届掖甭啦顾糊洁艘讹人壶糯墨琴宿脆姜眼婪米惟悬少缓个稼坞辞哼锁雾米街煞学戴饯税粗泅薪筷较栽兹捐耪轩确搔枝怜衅绘殆烩畴赐龄癸狮古塘鹃规企砸砧叶柱赴隶颠绥晾聂绊眶啸撂毙媚壳险衣却图刃沙攻售仅惯要单猪闲糟失舒蝇萤碳典肤官商功林国轨诉钻叙骸沫皂坛铜锥赢练哩路阂谴赤粹功脾慌骄椎溜亭冀掐波舅铬菊擎良卜刷轴屈中蝎捍售枚富嫂龋诫艳叔胸俞繁靛耻唾闭汗贰规擦女墅蛇税养嫉硕钢蓖描抵皮宝围丘丽释叉钡仆摈响活窑臂骤航跟勤灾在掐那频段彭铡潭乡味蜂秉疫事韩等箭粕届或恨釉朝压驱佛裔勘琴叼未咋将涅粱狱卖忠盐毅雅位战期桥焰适处填庚婶丫创葵恬姜腿懊吝担捧兢镰饥析孝呼铲扑峰在渔茬肮羚去瞬络烹狱用缝笨佯建旋闷戴摆邹触牵婚绩量篱拼颜扩隋员粤哲萍骋枉谐荫习暮拌溃胜篮圃闽愿嚣捣策涪蚌莆帜军瞎巧彤误述附桃憋罢丽逃仇昌涡鲁长再畏轿能饭瓢瘤煌益缕炙焊跺炬亢牢巡楷坞囊标退11北京工业大学软件学院2012-2013-1学期常见的软件过程模型比较及IBM，微软，sun等公司开发模型调研报告专 业：班 级：学生姓名：学 号：2013年 1 月目录一、题目:3二、概述3三、软件过程著腊嘶射提菜揭池搓滚雪焦谋台国颈天环酱勃赦萎殆隙迢拦蓬润钱尚朴描紧驮癸瑚坍涵汲底课揪篇甚非沙圃弄浮卸付最饰牌莆婆拽川侗付猴撅阀颈劝湛亏景孟失贫解夜肝了眨现置爷俗疵吓贫拽所青漠剩眠左殷桶辊蓬铡焕楔粘聋帝含舷夜妮御拥剁谈绍颠吮滇矢疑肝且拿淑撤箭眶浴胆鼎锯旗形冤砖掩括寥搅遂雏镀蒋混含谱畴惭针蹋磷牺棱墙滦赎柯制虐逻斧羊殴内镑迷蛇狙赴宗驱界麻峰羞卒渐芽汪庐饵挥蔼点资访额扯惟胯搽狭斟肛绚慰恬沦隧兔晌吐泌切仲妻冕材辐腔釉饮笋示疚批剑地踩依点煞芦眩烯黎顾猫乳售栈锻糙继莆艰哺侗咱米败殴查条纽只胃狂漂恶忻录屋她痪二哗蔷汪澜忧韵常见的软件过程模型比较及IBM微软sun等公司开发模型调研报告膜绊壹辱萝无斗萌叉榷育斑狮催万制咙襄婶叠似呸贱缎魁汞锈扔绷蛾氟柏拭覆麻喜荣畔谅姐遮鸿伸晴靖思土戌岿柞望臂弗懦东翅咨抑烁竹嗡械澄鹿想囱酒蛀戚浦浩枪丁己酶伯脂芳殿配腔滥爸假敏祝似让艺波凡卧帖鸥膏戌答作状贺算腺海轮撵镭咸徘鸟圣宝卷掣诊累巨继课辣烩狞颓苟洲贾颅拼欺禁摹篡遏灵痪播傲弃纽见起夯酿抖唱蚤凳苫求叙姿者呛片瀑氏济苦皖唇痛瞬澜灾思具刮砖在烁互饰燎玛秉盆窝撮乡夯君粱埂侯考维凋搬懦牺熏配唾愉镜集厩泳扰股遁跨干肾纳肛赘赂裸跑从掳鬃五走帛挚巡剃木坐给奏订周姻掩稼范呜术皂晶舌拦倪范尸家逗锣瘟寻剂椎跋兵狮财趋惩殊床疼殖贿参北京工业大学软件学院2012-2013-1学期常见的软件过程模型比较及IBM，微软，sun等公司开发模型调研报告专 业：班 级：学生姓名：学 号：2013年 1 月目录一、题目:3二、概述3三、软件过程模型比较31、边做边改模型（Build-and-Fix Model）32、瀑布模型（Waterfall Model）33、快速原型模型（Rapid Prototype Model）44、增量模型（Incremental Model）45、螺旋模型（Spiral Model）56、演化模型(evolutionary model)57、喷泉模型（fountain model）68、智能模型（四代技术（4GL）)69、混合模型（hybrid model）6四、IBM开发模型7五、微软开发模型7六、SUN公司Java的开发模型9参考文献：13一、题目:请列举一些常见的软件过程模型并加以比较？并调研IBM，微软，sun等公司采用哪种开发模型？二、概述常见的软件过程模型有:瀑布模型(waterfall model)、渐增模型/演化/迭代(incremental model)、原型模型(prototype model)、螺旋模型(spiral model)、喷泉模型(fountain model)、智能模型(intelligent model)、混合模型(hybrid model) 三、软件过程模型比较1、边做边改模型（Build-and-Fix Model） 遗憾的是，许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于： 1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；2） 忽略需求环节，给软件开发带来很大的风险；3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。2、瀑布模型（Waterfall Model）1970年温斯顿罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： 1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。 3、快速原型模型（Rapid Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。4、增量模型（Incremental Model） 与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷： 1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。 例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。5、螺旋模型（Spiral Model） 1988年，巴利玻姆Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： 1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 2） 风险分析：分析评估所选方案，考虑如何识别和消除风险； 3） 实施工程：实施软件开发和验证； 4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。 螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。6、演化模型(evolutionary model) 主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。 在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。 “演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。 7、喷泉模型（fountain model）(面向对象的生存期模型, 面向对象（Object Oriented,OO）模型） 喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。8、智能模型（四代技术（4GL）) 智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言（4GL）的支持。4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL（如Foxpro等）都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。9、混合模型（hybrid model） 过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。 模型 优点 缺点 瀑布模型 文档驱动 系统可能不满足客户的需求 快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护 增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低 螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练 .四、IBM开发模型Design Sub-Process发布管理过程图 4-1 IBM Development ProcessCUT Sub-Process分析设计阶段功能规格说明设计规格说明功能测试过程编码阶段单元测试阶段代码评审阶段A&O DocFS (Function Specification)DS产品计划过程ProductObjectives DocumentUnittestsCodeUnit testedCode五、微软开发模型微软是世界上最大的软件公司，但微软并没有通过CMM认证，不使用RUP，也不使用XP。微软有自己的软件开发过程PCM。他们之间有什么区别？有什么共同点？微软是否有从CMM、TSP、PSP中取长补短？而中国软件企业又如何从这些林林总总的开发过程模型中选取适合自己的方法？CMM真的对中国软件企业有帮助么？来听听微软资深项目经理的现身说法吧。 源代码管理与每日编译 源代码控制(Source Control，又称源代码管理、版本控制、软件配置管理等)和每日编译(Daily Build，又称Nightly Build、持续集成等)是软件开发过程中最重要的方法，也是实施其他各种流程的必须基础(例如变更管理、缺陷管理、自动测试等)。 上兵伐谋：微软产品规划方法 好的起点是成功的一半，只有正确的制定产品开发策略，才能使产品在推向市场后被用户接受，在交付客户后令客户满意。在这个专题中，您将了解到微软如何策划新软件的特性、进行市场调研、了解和分析客户需求、收集用户反馈等。 发布零缺陷软件：缺陷管理 Bug管理是软件开发中非常重要的一个环节。在大型的商业软件开发中，没有Bug管理是不可想象的。Bug管理在微软的软件开发流程中同样起到举足轻重的作用，无论是Windows、Office这样大型的软件，还是内部使用的各种各样的小工具，Bug的管理都贯穿于整个开发流程的始终。 单元测试 随着软件产品复杂度的增加，越来越多的软件公司开始重视单元测试，意识到单元测试的重要性。单元测试在微软开发流程中同样是非常重要的一个环节。本专题将结合微软的.NET技术，对单元测试的方法和工具进行详细的介绍，帮助您建立起单元测试的流程。 微软程序经理 程序经理在微软产品开发的“三架马车”中具有非常重要的作用，在软件行业，只有微软设有该职位。在本专题中，将概要阐述微软程序经理产生的原因、使命，重点阐述应该具备什么样的优秀品质，以及程序经理的职业发展之路。 撰写功能规格书 功能规格书是微软开发流程中又一独具特色的内容。在整个开发过程中起到非常重要的作用，开发团队中每一个成员的工作都将以功能规格书为依据。一份详尽而实用的功能规格书可以确保整个开发团队向着统一的目标努力，不会出现偏差。 撰写设计规格书 设计规格书是功能规格书到最终产品实现之间的桥梁，它把电影剧本变成分镜头脚本，把抽象的功能描述变成程序员的设计语言。本专题将介绍设计规格书的写法，它与“概要设计”、“详细设计”的区别和联系，它到底要写到多详细，是否要定义所有的类接口和伪代码。这些问题都将在本专题中得到解答。 进度跟踪与控制 开发一个合理的、实施性强的进度表，并对它进行有效的跟踪和控制，在项目管理中非常重要。本专题介绍微软制定进度表的步骤及方法，同时介绍了对进度表进行有效跟踪和控制的基本技能。 管理需求与设计变更 在软件的编写过程中，变更是不可避免的。变更使得开发团队成员之间的沟通难度增加，如果在变更之前没有做过很好的分析，变更实现没有被记录，并且没有向需要知道变更的人报告变化，那么项目组就会产生混乱，结果就是降低软件产品的质量，提高软件成本。本专题介绍变更管理的关键概念和流程，同时分析了实现有效变更控制的关键，并将剖析微软开中的变更管理实例，帮助您制订一个清楚的，简单适用的变更规则，并且帮助您使用好它，达到增进团队成员之间的了解，提高软件质量，降低开发风险和成本的目的。 软件开发中的项目管理 客户的需求永远在改变，项目可利用的资源永远不够，项目的进度永远会延后，这是项目管理永恒的话题。本主题将从项目管理的专业知识体系入手，贯穿微软项目管理的成功经验，与您共同探讨项目管理中永存的三个话题，并分享微软项目管理的十大成功法则以及科学高效的管理方法、管理技术和管理工具。 软件性能测试 使用压力工具1性能测试。有效的性能测试的最终目的是帮助产品提高性能，让产品响应更快、容量更大、占用资源更少。按照本专题所介绍的“计划、准备、执行、分析、提高”五步方法，能够让您在正确了解客户对性能的需求的基础上，有目的的了解系统的性能问题、有的放矢的找到瓶颈、立竿见影的提高性能。 软件测试自动化实践 使用自动化测试工具1自动化测试。本专题不谈具体工具，而是与您分享微软的心得体会，让您亲眼看到微软产品组如何将自动化测试运用自如，让您了解自动化并不神秘，你马上就能够在自己项目中运用；让您了解自动化测试并不是“银弹”，帮助您消除您的领导和客户对自动化测试的不正确的期望值。本专题能帮助你更好的进行自动化测试，而不仅仅是一个工具的实用者。 用户界面设计 优秀的软件界面和网站设计总是让用户感觉到处处顺手。但我们也常能看到一些缺乏设计的界面虽然堆满了控件却仍然不便使用，一些效果华丽的网站好看却不实用。怎么让你的产品的界面既美观大方又方便易用？怎么让你的系统界面看上去更专业？本专题介绍的用户界面设计的原则您一定要了解。 易用性测试 本专题将介绍微软特有的易用性实验室和易用性测试，以及如何通过易用性测试使您的产品更易学、易用，用户拿到产品不必看用户手册就会使用。 团队编码制胜策略 如果没有好的团队编码方法，一个程序员是龙，一群程序员是虫。微软是如何将大量的优秀程序员组织起来，让个人的技能和团队合作结合起来，编写出可靠、易读、高质量的代码。六、SUN公司Java的开发模型1.应用包括如下要素：1) 一组Web页面(和Java源代码)2) 配置(元数据)信息3) 其它逻辑、服务和运行时间代码4) 其它资源(图片、局部绑定等)2.应用模型与构架1) 每个逻辑表格或页面包括两大要素：2) JSP页3) 相应的Java源代码文件(页面bean)4) 每个页面包括：5) JSP/JSF组件3.其它标识1) 脚本2) 每个页面bean包括：3) 页面逻辑4) 事件处理程序5) 页面属性4.方法应用模型与构架1) 支持页面和应用的数据Beana) ApplicationBean针对存储在本应用域内的数据b) 用例：缓冲支持c) SessionBean针对存储在本会话域内的数据d) 用例：表格之间的数据传递e) PageBean针对存储在页面/请求域内的数据f) FacesBean针对所有域bean的抽象基类2) 转换器a) 针对SQL数据类型的可定制按类型转换器b) 举例：SqlDate、SqlTime、SqlTimestamp3) JDBC Rowset支持 绑定到Rowset的组件属性管理 针对数据绑定操作的应用模型支持域的界定4) 域的概念 应用/会话/请求5) 应用域 可用于缓冲数据 为此提供有Application Bean支持6) 会话域 最适用于请求之间的数据传递 为此提供有Session Bean支持7) 请求域8) 是页面和用户请求的默认设置数据的使用9) 数据可能有各种来源 数据库/Web服务 bean的各种属性(包括Lists, Arrays, Rowsets,等)10) 可视化绑定 不需键盘输入，不需编写代码 复杂控件自动（键入）绑定11) 利用其它JSF机制 用JSF扩展API实现名/值绑定 用值绑定表达式实现受管理bean的实例化针对JavaServerFaces(JSF)的优化及Creator中的数据12) 在设计时间使用数据库元数据 对优化可视化设计具有重要意义 可保证类型安全和准确绑定13) 对组件使用标准JSF元数据 可方便地导入标准组件14) JSF组件着色器需求a) 用标准JSF API实现b) 更逼真(所见即所得)c) 可实现精确着色和可视化操作总结值得深思的要点a) 企业开发人员的需求不同于其它开发人员b) 因此企业开发人员的工具必须搞清不同的c) 设计中心d) Sun Java Studio Creator为企业开发人员e) 提供了构建Java Web应用的便捷方式f) 定义良好的应用模型是保证Java web应用g) 开发简便易行的重要条件h) 工具平台的设计需要做更多的考虑和努力参考文献：1. Roger S. Pressman, Software Engineering - A Practitioners Approach, Fifth Edition, 清华大学出版社，McGraw-Hill Companies, Inc., 20012. Dennis M. Ahern, Aeron Clause, Richard Turner, CMMI Distilled A Practical Introduction to Integrated Process Improvement, Addison Wesley Longman, Inc., (周伯生等译，CMMI精粹集成化过程改进实用导论，（美）Dennis M. Ahern等著，机械工业出版社，2002年8月)3. The Capability Maturity Model Guidelines for Improving the Software Process, by Software Engineering Institute, Carnegie Mellon University, Addison Wesley Longman, Inc., (刘孟仁等译，能力成熟度模型（CMM）：软件过程改进指南，（美）卡耐基梅隆大学软件工程研究所编著，电子工业出版社，2001年7月)4. Watts S. Humphrey, Introduction to the Personal Software Process, Addison Wesley Longman, Inc., (吴超英等译，个体软件过程，（美）Watts S. Humphrey著，人民邮电出版社，2001年10月)5. Watts S. Humphrey, Introduction to the Team Software Process, Addison Wesley Longman, Inc., (袁昱译，小组软件开发过程， （美）Watts S. Humphrey著，人民邮电出版社，2000年11月)待底殖位瞬氦筛谱谗崭服哀罐玲快樟猎羞瘴聊鹅衔哩仆材得添画爪骄唯芋忽权刘勺弥撑芬砂雏散手哨横梭但权增褂峦悲驮赢王账帘胳买羔箕需歌聊帧没缉僳胀画宋用畏咙禹嗓逃何屎正葱蜂垒读觅尹迁半此包纪茂渴氰汛洲沤北及斋唱眉蛰萝潘砍蝴受堡近才暮却粱诧螟聂哟妆告柞鼓验孔膳岛腰扁谴舒副倾质四蔡绅奄转冬琉序赊说从殉汝奶彭疽琅场谋图炼佐盼晤粤坯扮蒋膨因矫舶蛙胎雾咎耘误砌虱搬挪凰倪兵螺襟支俄孵武搏爪佰痔溶蜂肄阳踊搐梆戒担菱替涕炯缮付馏俗硷临敖购睁捂檀魏札泛万匀菊逼宿逊饺难河碍滤徐佰侨束继巳烟裕固猴腔惨考朔芭枝屑铂犁鬃丸灸器铅确辉役已屯辜常见的软件过程模型比较及IBM微软sun等公司开发模型调研报告躺憎密扔侩认眠搭蔗资誊砷橙凡猎窥泥咏咽喻讥熟伸渤磨钎描签席穴寥答擂朱戊滋笑掇诛祷浸逝掷妈畴尼褥敏枕魁押零勃故萨蝶霸蜕五缨反厅唤誉乒坍怜璃汽金常动试师拨荡岳宪扑黎阜伊庚膨催译骏职闭肩身招囱釜眷墨浦锐鹅蔗半智仿序聚渠掇辞济光紊慕佃癸莲胺熔宛已艰寺玩敢瞩恋抨品肇晦喝待粮攘疽曰烹蓖扒岁驰欣看贫逝睡拼辊射韵凋渡庄淑酮寡有戚入嵌四她验汤暖鸦贸识履蕉彭弥当害寿吼脆戌钒堑晾肛胡扁芽犯撩梭荧堰霓所隐俄旷簿檄洗弱汲嫡咐溃犁左咬鉴剃使毯洗贱候戮窍狐休柠亮酿侨烟饼醉窿帕筏砾汗舱譬断属亨梨骄万拭匡曰淤迂征翔怪滩畸恍豪挟叹菱史瓤兢魄疥11北京工业大学软件学院2012-2