软件开发方法经典课件.pptx
- 文档编号:12048616
- 上传时间:2023-06-04
- 格式:PPTX
- 页数:99
- 大小:3.38MB
软件开发方法经典课件.pptx
《软件开发方法经典课件.pptx》由会员分享,可在线阅读,更多相关《软件开发方法经典课件.pptx(99页珍藏版)》请在冰点文库上搜索。
软件开发方法,Itisnotthestrongestofthespeciesthatsurvives,northemostintelligentthatsurvives.Itistheonethatisthemostadaptabletochange.CharlesDarwin,本章主要内容,传统软件开发流程WaterfallRational统一开发过程RUP敏捷软件开发Agile(XP,Scrum),Doself-learning,瀑布式开发:
早期的开发方法,RISK,TIME,延迟关键风险解决推迟集中系统的测试、集成没有早期部署经常导致较大的无计划重复,RUPRationalUnifiedProcess,RUP是Rational公司提出的、面向对象的软件开发过程。
当时影响较大过程:
是指为达到一个目标而采取的一系列有序的步骤RUP目标:
高效、按时地提交一个满足业务需求的软件产品RUP特点RUP提供了在开发机构中分配任务和责任的纪律化方法RUP在很大程度上是过程独立的,即,它可以用到多种不同的软件开发过程中,RUP是一种特别适合于用UML表述的软件生命周期方法,它提出了一整套以UML为基础的开发准则,用以指导软件人员以UML为基础来开发软件,RUP所要处理的问题,有缺陷、无法预测结果的、高度依赖个别“英雄”程序员的、不可重复的开发过程开发的软件难以适应用户需求在应对需求的变更方面无能为力需要单调乏味和昂贵的测试流程对项目中出现的严重缺陷发现太迟开发的软件难以维护和扩充,RUP介绍,使得开发团队涉众(包括,项目经理、测试员、系统分析员、发布维护人员、数据库管理人员、系统架构师、代码设计编写人员等)共享同一个知识库同一个开发过程同一个开发视图同一种建模语言RUP的coreidea,保持最佳实践Implementingbestpractices,RUP达到最佳实践的措施,管理需求,控制变更,使用构件架构质量检验可视化建模迭代式开发,RUP的需求管理,需求管理定义:
一种用于查找、记录、组织、跟踪系统需求变更的系统化方法,需求管理目标:
解决真正的问题,建立用户需要的系统,需求管理内容:
提取组织系统的功能和约束,将其写成文档估计需求变化,评估变更带来的影响跟踪需求的实现RUP需求管理的驱动,由UseCase驱动在透彻理解系统如何被使用的基础上建造系统(透彻理解?
),迭代式开发,降低风险得到早期用户反馈持续的测试和集成适应变更提高复用性,迭代开发:
增量式实施,每次迭代都是一个小型瀑布开发,可视化建模,描述系统结构和特点描述系统的各元素如何组织在一起保证设计和实现的一致性保证没有歧义的沟通,质量检验,为每个关键模块创建用例并测试,保证所有需求都被实现不可接受的应用性能和不能接受的可靠性对一个软件系统的影响性同样重要验证软件可靠性:
内存泄露、性能瓶颈对每一次迭代进行测试,RUP使用构件架构,构件架构的优势自下而上地设计、实现、测试体系架构用系统化的方法来定义良好的体系结构(愿望)采用定义明确的接口使变更更有弹性采用现有的或逆向工程得到构件由高级别的用例来驱动易于直观理解,构件架构,管理变更,哪些变更需要管理控制、追踪、监控项目的所有变更,从而启动每次迭代为每个开发者建立安全的工作空间对不同的工作空间的改动提供隔离机制控制所有的软件制品:
模型、文档、代码,RUP以软件体系结构为中心,强调在软件开发早期就识别出与软件体系结构紧密相关的用例。
通过对这些用例分析、实现、测试,形成系统框架在后续阶段细化已形成框架,最终实现整个系统开发阶段早期形成的良好软件体系结构有利于对系统的理解、支持重用和有效的组织开发,RUP软件开发生命周期,RUP软件开发生命周期,横轴:
时间,分为若干阶段:
起始、细化、构造、提交在每个阶段(横轴区间)都有一或多次迭代迭代是一个完整的开发周期产生一个可执行的项目发布版本,每个阶段和每次迭代都有里程碑。
-里程碑提供了一个评审点,评价关键性能是否达到,项目是否需要以某种方式被重新构造纵轴:
核心工作流coreworkflow对应于特定迭代的连续活动活动:
需求定义、分析、设计、实现、测试-Artifacts:
中间制品,TheSoftwareDevelopmentLifeCycle,Phases中各名词含义,Inception:
建立项目图景、范围和初始计划Elaboration:
设计、实施、测试(一个被认为良好的)架构,完成项目计划Construction:
建立第一个可运行的系统(软件)版本Transition:
向最终用户提交系统,Disciplines(流程)中各名词含义,Businessmodeling:
描述客户所在组织的组织结构和动态情况,Requirements:
用各种方法描述需求Analysisanddesign:
描述体系结构视图Implementation:
软件开发、单元测试、集成Test:
描述脚本、执行测试、跟踪测量缺陷Deployment:
材料清单、发布说明、培训等,Configurationmanagement:
控制变化,以维持项目制,品和各项活动管理的完整性,ProjectManagement:
描述迭代开发过程中不同的工作,策略Environment:
布署一个系统所必需的其他基础设施,RUP的起始阶段Inception,意图项目图景:
建立业务模型用例,高层需求,初始项目计划明确项目范围,解决需求和商业上的风险结果项目的实际需求,实现10-20%的用例模型初始的业务案例-成功准则、风险评估、资源评估、显示里程碑进度表和阶段计划在初始阶段最后,检查项目的生命周期目标,决定是否继续开发起始阶段涉及众多人员,RUP的细化阶段Elaboration,意图分析问题域,解决架构上的风险,建立一个健全、合理的体系结构基础,明确项目高风险因素制定一个合理的开发计划结果完成初始关键用例模型的80%一个可执行的体系结构和文档一个修订的用例图和风险评估一个针对整个项目的开发计划,最后检查已经细化的系统目标和范围、体系结构的选择、主要风险的解决方案,决定是否构建软件系统,细化阶段以项目架构师和项目经理为主,也包括分析员、开发人员、测试人员;所需人员数量、时间都多于起始阶段,RUP的构建阶段Construction,意图解决代码和运行上的风险迭代增量式开发一个准备交付用户的完整产品。
描述剩余需求、验收标准、充实设计、完善测试和实现产品完整的用例图和设计模型,用户手册可执行代码开发文档每次迭代的评测标准,改进的开发计划,在阶段最后,要决定软件、现场、用户是否已经准备妥,当,以部署第一个可操作的软件版本,本阶段涉及项目架构师、项目经理和具体构建团队的领导,也包括所有开发测试人员;,RUP的提交阶段Transition,意图,解决发布的风险,为用户安装部署软件产品,可执行程序,改进的系统模型每次迭代的评测标准对程序的描述和评测指标的描述改进的用户文档改进的开发文档,迭代与阶段之间的关系,每个阶段可有多个迭代一个迭代是一个完整的开发过程,将产生一个可执行产品的发布版本,RUP带来的软件观念性的变化,更强的计划性:
迭代开发意味着更强的计划性和预见性阶段划分、阶段内迭代都需要有仔细规划项目管理者承担更大责任:
确定迭代的内容、时间,主要依据经验,坦然面对开发中的一部分中间制品推倒重来不应过分担忧这些事情,由于迭代过程的细化和相应工具的支持,这种影响可以控制坦然面对中间制品不美观注重实效,项目管理者要充当意见缓冲区,树立讲信用和可信赖的形象,RUP带来的软件观念性的变化,把软件放在首位,过分强调规格说明是不恰当的,在开发过程中需求和规格说明都是允许变化的,尽早进行困难的工作将困难工作放在在后期是极其不利的,可能会遭遇“集成地狱”而使开发失去控制。
强调开发过程监控和量化管理对各种变化和扰动测量监控,先示范,后发布文档,尽量使开发人员信服成功的软件项目同时需要这两种特质既需要好的项目管理者也需要好的体系架构师,RUP的制品Artifacts-1,Models:
RUP最重要的制品Businessusecasemodel:
结构抽象Businessanalysismodel:
系统上下文Usecasemodel:
系统功能Analysismodel(optional):
概念设计Designmodel:
建立术语词汇Datamodel(optional):
数据结构Deploymentmodel:
硬件拓扑结构Implementationmodel:
建立运行环境,模型与工作流之间关系,RUP的制品Artifacts-2,Aviewisaprojectionintoamodel,一个视图就是指我们从某一角度观察真实模型,所看到的景象。
用数学语言描述,这个景象实际上是真实模型的在某平面上的一个投影。
RUP包含5个密切关联的视图4+1视图:
designview,interactionview,deploymentview,implementationview,andusecaseview,RUP的技术制品Artifacts,制品可分为管理制品和技术制品两类,RUP的技术制品包含如下Requirementsset:
描述系统必须做什么Analysisanddesignset:
描述系统如何构建,Testset:
描述确认和验证系统的方法脚本、测试用例、缺陷跟踪检测、验收标准Implementationset:
描述如何组合构件代码、配置文件、数据文件、软件构件、建立系统的文档说明,Deploymentset:
为交付配置系统提供数据-(软件如何包装、运输、安装、在环境中运行),RUP小结,RUP带来观念的变化,但其效果和可操作性还有待实践检验对软件开发过程的管理是为了更好地促进支持软件开发,而不是制约软件开发,不要极端软件开发成功与否的标志,不只开发出用户需求的产品,而且还包括时间、成本、维护、支持、扩充等许多方面RUP描述了如何有效地利用商业的可靠的方法开发和部署软件,是一种重量级过程,因此特别适用于大型软件团队开发大型项目。
RUP主要特点:
软件开发是一个迭代过程,软件开发由UseCase驱动软件开发以架构设计(ArchitecturalDesign)为中心,CMM、XP(Agile)、RUP学习笔记,CMM重视过程、XP重视个人、RUP重视项目CMM文档驱动、XP测试驱动(?
)、RUP用例驱动CMM要求准确设计、XP通过重构来设计、RUP要求核心设计CMM认为人可以替换、XP认为人很重要,难以替换、RUP在中间CMM不重视剪裁和重构(?
)、XP缺乏重构指南、RUP缺乏剪裁指南,33,AGILEDEVELOPMENT敏捷开发,Agile,37,wasrespondingtoaneedforprojects,tobemoreresponsivetotheirstakeholders对涉众反应更积极tobequickertodevelopfunctionalitythatuserscareabout更快地开发用户关心的功能toshowmoreandearlierprogressinaprojectslifecycle更多、更早地展示项目早期进展Andtobelessburdenedbydocumentingaspectsofaprojectthatwouldinevitablychange通过编档软件中的变化,来降低开发负担Isanyofthisinimicaltotheuseofarchitecture?
上面这些是否不利于软件架构使用?
Agileandarchitecturearenotjustwellsuitedtolivetogetherbutinfactcriticalcompanionsformanysoftwareprojects,ManifestoforAgileSoftwareDevelopment敏捷宣言,Weareuncoveringbetterwaysofdevelopingsoftwarebydoingitandhelpingothersdoit.Throughthisworkwehavecometovalue:
whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore,38,2019-07-02,39,敏捷开发核心价值(CoreValue),Individualsandinteractionsoverprocessesandtools个人和交流重于过程和工具Workingsoftwareovercomprehensivedocumentation正在运行的软件本身重于复杂的文档Customercollaborationovercontractnegotiation与客户的沟通和交流重于使用合同约束客户Respondingtochangeoverfollowingaplan对变化的快速响应重于跟随计划,40,敏捷开发原则(Principles),最高目标是通过快速的和经常的发布软件满足客户的需要欢迎需求的变更,尽管会导致开发延迟。
(尊重客户的竞争需求,)频繁提交软件,周期为几个星期到几个月,倾向于短的提交期项目开发期间,商务人员和开发人员工作在一起围绕那些有积极性的个人建立项目,要创造环境支持他们的要求,,信任他们最有效的交流方法是面对面的交流产生正确的软件是衡量进度的首要标准敏捷过程支持可持续的发展,赞助商、开发者、用户需步调一致,。
9.时刻关注优秀的技术和好的设计,保持简单,减少不必要的部分,认识到简单的设计比复杂的设计更难(simpledesignishardertoproduce)最好的结构,需求和设计来自于自组织的团队(self-organizing,team201)9-0,7-0允2,许任何人提出想法和建议,定期调整过程获得更高效率,AgileProcess-敏捷的开发流程,2019-07-02,41,AgileProcess(敏捷的开发流程)是一种软件开发流程的泛称,几项共通的特性:
客户与开发人员形成密切合作的团队,因为客户无法于初期定义完整的规格,而开发人员于开发过程中也常常无法知悉外在环境或业务的变动,所以需要两者密切合作方能开发适用的软件。
项目最终的目标是可执行的程序,因此所有的中间产品必须经过审慎评估,确认有助于最终目标,才需要制作中间产品。
采用Iterative与Incremental方式分阶段进行,密集review是否符合需求。
流程可以简单,但规划与执行必须严谨。
强调团队合作,赋予高度的责任,团队有自主权得以因应变化做调整,2019-07-02,42,AgileDevelopment,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法在敏捷开发中,项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。
2019-07-02,43,敏捷开发的设计原则,SRP单一职责原则SRP:
SingleResponsibilityPrincipleOCP开放封闭原则OCP:
OpenClosePrincipleLSPLiskov替换原则LSP:
LiskovSubstitutionPrincipleDIP依赖倒置原则DIP:
DependencyInvertionPrincipleISP接口隔离原则ISP:
InterfaceSeperatePrinciple,敏捷开发-迭代计划,最新版本,2019-07-02,44,验收测试,发布计划,迭代计划,开发,项目周期,AgilityandArchitectureMethods敏捷性与架构方法,ArchitectureDocumentation架构编档方法,所用方法:
ViewsandBeyond视图及其他。
YAGNI原则:
youaintgonnaneeditIfinformationisntneeded,dontspendtheresourcestodocumentit.“Writeforthereader”敏捷方法也强调最小编档原则,但我们更进一步强调为未来可能的读者去编档(可能以后会由这些人维护软件),AgilityandArchitectureMethods敏捷性与架构方法,47,CouldanarchitectureevaluationworkaspartofanAgileprocess?
AbsolutelyArchitectureEvaluation架构评估方法,ATAM-架构权衡分析方法itiseasytotailoralightweightarchitectureevaluation,forquickerandless-costlyanalysisandfeedbackwheneverintheprojectitiscalledfor.无论何时需要,都能很容易地实施一个轻量级、快速和低消耗的分析及反馈,结论:
敏捷方法和架构方法是非常相容、契合的!
Casestudy(敏捷与架构):
webarrow,48,要求,必须工作在一系列软、硬件平台上保证可靠和低延迟:
VoIP,屏幕共享,高安全性,但网络拓扑和防火墙规则未知容易被修改和被整合到广泛的应用环境和程序中易于被各类用户安装和使用分析很多要求之间是有矛盾的,且开发时间紧迫需要自顶向下分析架构结构,满足质量属性,并作平衡需要自下向上地分析一系列实施及环境相关的场景,并找到解决方案,Casestudy:
WebArrow,快速、粗略地制作了一个软件系统架构,并很快增量式地开发了一个只具有最基本功能的、可以给用户看的软件当新的需求到来、或者对问题有了新的认识后,调整了软件架构、并重构了设计与代码不断地进行实验、评估和架构分析有助于软件演化,49,GuidelinesfortheAgileArchitects,50,IncrementalCommitmentModelBarryBoehm,Commitmentandaccountabilityofsuccess-criticalstakeholders。
关键利益相关者的承诺与可审计性用户的满足基于成功的协商和平衡增量式和可演化的系统定义及用户责任迭代进行的系统开发和定义,交织在一起的系统定义和开发允许及早确定系统核心功能范围、不断地适,应变化、使复杂系统及时获得进展,而不必去等待每一项需求和子系统都被明,确。
风险管理。
设定里程碑,GradyBooch,Allgoodsoftware-intensivearchitecturesareagile.所有好的软件密集,型架构都是agile的成功的关键是分解、隔离相关性,以及各部分之间的独立性,使设计模式、部件间的相关性及其他重要的决策显而易见、有良好的定义和通,讯,GuidelinesfortheAgileArchitects,51,LanBass对于复杂且其需求有良好理解和定义的系统,最好能在前期做大量的架构分析设计工作对于那些需求模糊和不稳定的项目,可快速设计一个候选架构,忽略非关键的细节对于那些需求不明确的小项目,至少要在主要的模式上达成一致,但是,不要在早期就做大量的构建、编档和分析工作。
(lightweightand“just-in-time”fashion.),XP,eXtremeProgramming,XP:
eXtremeProgramming,2019-07-02,54,名词解释,故事,故事是客户想要系统做的事情,适合在一至两个迭代内完成,并且是可测试的,他不一定是商业价值的直接体现。
迭代,迭代是一个周期在2-4周,能够完成当前团队所能实现的,最具商业价值的功能,并可以提供一个可工作的小版本供发布。
Velocity,2019-07-02,55,Velocity翻译为项目周转时间。
代表团队在给定周期内能够完成多少商业价值,以便用于衡量将来该团队能够提供的商业价值。
也即昨天的天气。
名词解释,优先级,优先级主要考虑商业价值,同时兼顾市场风险、商业风险、技术风险等因素在内的一个衡量数字,优先级越高通常意味着其商业价值越高,风险系数,风险系数综合商业环境、项目资源、技术以及项目环境等等因素在内的一个衡量数字,它是优先级的重要衡量指标之一。
它通常出现在故事中。
风险系数较大意味着优先级也较大。
负载因子,负载因子是综合项目成员的技术能力、技能集、精神状态等等因素,对于团队成员的一个负载系数。
名词解释,理想时间,理想时间排除一切可能的外界干扰,同,时排除自身的精神状态,职业态度等等因素,完成某项工作所需要的时间。
实际时间理想时间乘上负载因子实际时间,任务,2019-07-02,57,任务分配到项目成员,从故事切分的出来。
通常任务时间不应该超过10个实际工作日。
2019-07-02,58,XP-eXtremeProgramming,极限编程,最轻量级的开发流程,其最主要的精神是在客户有系统需求时,给予及时满意的可执行程序,所以最适合需求快速变动的项目强调客户所要的是workable的执行码,所以把与撰写程序无关的工作降至最低,并要求客户与开发人员最好以side-by-side的方式一起工作,XP强调4个因素,2019-07-02,59,交流(communication)XP要求程序员之间以及和用户之间有大量而迅速的交流简单(simplicity)XP要求设计和实现“简单和干净”反馈(feedback)通过测试得到反馈,尽快提交软件并根据反馈修改勇气(courage)勇敢的面对需求和技术上的变化,XP开发流程,60,开发人员随时可以和客户进行有效沟通,撰写userstories以确认需求。
简易快速的系统设计,撰写独立的验证程序以解决特殊困难的问题,找出算法即可丢弃验证程序。
规划多次小型阶段的项目计划,以最快速度完成每一阶段的程序交付客户,客户负责Acceptancetests;Coding前必须完成UnitTest与Acceptancetests程序,所有模块整合前都须经过UnitTests;开发人员必须快速响应Bug与需求变更;要求二人一组使用一台计算机设计程序,当一人coding时,另一人负责思考与设计;程序必须符合程序规范,并常做程序的重构(Refactoring)。
XP原则和实践-Planning-userstories,61,userstoriesUserstories类似usecase,描述用户所见的系统功能,,但避免使用大量的文档,userstories由用户编写(不仅限于描述用户界面)。
Userstories使用用户的语言编写,不使用技术性的语言,每个userstories限于几句话。
Userstories用于在releaseplan会议上对开发时间进行评估,,也用于产生验收测试(acceptancetest),必须使用可以,自动进行的验收测试保证软件的正确性。
Userstories与传统的用户需求的区别在于详细的程度,,userstories并不会确定需求的每个细节,它只是用来简单,的描述系统功能,供开发人员进行估计开发进度,在开发过程中
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 方法 经典 课件
![提示](https://static.bingdoc.com/images/bang_tan.gif)