03-第2章软件过程模型

上次课的基本知识点回顾软件生命周期问题定义、可行性研究、需求分析、总体设计、详细设计、编码、测试、维护传统软件过程模型瀑布模型增量模型上次课的基本知识点回顾传统软件过程模型原型模型螺旋模型喷泉模型现代软件过程模型–基于构件的开发模型–形式化方法模型如何选择软件过程模型软件过程模型是不断发展的各种软件过程模型各有优缺点和适用场合选用时不必拘泥于某种模型可组合多种模型也可根据实际创造新的模型应用举例开发一个类似于Word的字处理软件。–迭代1：提供基本的文件管理、编辑和文档生成功能。–迭代2：提供高级的文档编辑功能。–迭代3：实现拼写和语法检查功能。–迭代4：完成高级的页面排版功能。应用举例应用举例：开发一个教务管理系统。第一次迭代：完成基本的学籍管理、选课和成绩管理功能。（6周）客户反馈：基本满意，但是对大数据量运行速度慢效率，不需要学生自己维护学籍的功能等。第二次迭代：修改细节，提高成绩统计和报表执行效率（2周）。客户反馈：需要严格的权限控制，报表打印格式不符合要求。第三次迭代：完善打印和权限控制功能。（2周）客户反馈：可以进行正式应用验证。面向方面的软件开发随着现代计算机系统变得更加复杂，某些关注点——客户需要的属性或技术兴趣点——已经体现在整个架构设计中。某些关注点是系统的高层属性（例如安全性、容错能力），某些关注点影响了系统的功能等。如果某个关注点涉及系统多个方面的功能、特性和信息，这些关注点通常称为横切关注点。面向方面的软件开发方面需求定义那些对整个软件体系结构产生影响的横切关注点。面向方面的软件开发（AOSD）通常称为面向方面编程（AOP），为定义、说明、设计和构建方面提供过程和方法，是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。面向方面的构件工程(AOCE)*AOCE对纵向分解的软件构件进行横向切片，称为“方面”，以表示构件功能及非功能的横切属性。*系统的方面包括用户接口、协同工作、发布、持续性、存储器管理、事务处理、安全、完整性等。*构件也许提供或需要某一方面的“方面细节信息”，如视图机制、可扩展性和接口类型（用户接口方面）；事件生成、传输和接收（分布式方面）；数据存取/查询和索引（持久性方面）；认证、编码和访问权限（安全方面）；原子事务、协同控制和登录策略（事务方面）等。Rational统一过程UnifiedProcess(UP)以用例驱动、以架构为核心，迭代增量模型的软件过程描述了如何为软件开发团队有效的部署经过商业化验证的软件开发方法。它们被称为“最佳实践”，UP为每个团队成员提供了必要准则、模板和工具指导。获得广泛使用基于面向对象方法学使用统一建模语言UML统一过程的三个特点用例驱动所有的软件开发都是用户需求驱动的。UP采用用例来描述用户需求，同时提供一套方法把用例转化为设计的类图，进一步变成最终的程序代码。在整个软件开发过程中，要求用例是可跟踪的，即在设计和实现阶段，都可以找到相应的需求。以架构为核心架构刻画了系统的整体设计，舍弃细节，突出重要特征。UP提供了创建架构的方法和过程。统一过程的三个特点UP采用迭代和增量的开发模式，把一个软件产品划分成多个较小的部分，每次完成一个部分，每次迭代都是产品的一个增量。优点：把一个复杂系统分解成多个简单系统，提供软件项目的可控性，降低软件开发的风险，有效的应对需求变更。UP起源面向对象–60年代AlanKay发明OO语言Smalltalk和面向对象编程（Object-Orientedprogramming,OOP）–1982年GradyBooch提出面向对象设计（Object-OrientedDesign,OOD）–80年代末，PeterCoad创建完整的OOA/D方法三剑客及其建模方法–JamesRumbaugh提出了OMT方法–GradyBooch提出了Booch方法–IvarJacobson提出了Objectory（ObjectFactory）方法UP起源UML–1994年JamesRumbaugh和GradyBooch创建了统一方法（UnifiedMethod），即UML第一个草案–三人加入Rational公司（后被IBM收购），领导了OMG的建模标准制定–1997年UML1.0发布，2004年UML2.0发布，成为OO建模标准UP起源UP历史Rational统一过程从3个视角描述软件开发过程动态视角：随时间变化的各个阶段静态视角：所进行的活动实践视角：可采用的良好实践建议Rational统一过程初始：项目计划、评估风险；精化：设计系统的体系结构、制定项目计划、确定资源需求；构建：开发出所有组件和应用程序，集成并进行详尽测试；产品化：将产品移交给用户。动态视角静态视角统一过程的最佳实践准则实践视角：6条最佳实践1.迭代式开发需求变更不可避免每次迭代产生一个可交付版本，用户反馈，减少风险根据客户的轻重缓急来规划增量，先开发和交付优先级最高的增量2.管理需求采用用例分析来捕获需求，由用例驱动设计和实现对需求及其变更进行管理3.使用基于构件的体系结构将体系结构组建成基于构件的提高软件复用率4.可视化建模使用统一建模语言（UML）对系统进行可视化建模5.验证软件质量软件质量评估贯穿于整个开发过程的所有活动中全体成员参与6.控制软件变更描述了如何控制和跟踪软件的变更统一过程的最佳实践准则Rational统一过程初始：项目计划、评估风险；精化：设计系统的体系结构、制定项目计划、确定资源需求；构建：开发出所有组件和应用程序，集成并进行详尽测试；产品化：将产品移交给用户。动态视角静态视角起始阶段(inception)：[沟通、策划]包括客户沟通和策划活动。该阶段识别基本的业务需求，并初步用“用例”描述每一类用户所需要的主要特征和功能。此时的架构仅是主要子系统及其功能、特性的试探性概括。策划活动识别各种资源，评估主要风险，定义进度计划，并为用于软件增量开发的各个阶段建立基础。统一过程的阶段统一过程的阶段细化阶段(elaboration)[策划、建模]包括用户沟通和通过过程模型的建模活动。该阶段扩展了起始阶段定义的用例，并扩展体系结构以包括软件的五种视图——用例模型、分析模型、设计模型、实现模型和部署模型。体系结构基线证明了体系结构的可实现性，但没有提供系统使用所需的所有功能和特性。另外，在细化的最终阶段将评审项目计划以确保项目的范围、风险和交付日期合理。同时对项目计划进行修订。统一过程的阶段构建阶段(construction)：[部署]与通用软件过程中的构建活动相同。该阶段采用体系结构模型作为输入，开发或获取软件构件，使得最终用户能够操作用例。转换阶段(transition):[构建、部署]包括通用构建活动的后期阶段以及第一部分通用部署活动。软件被提交给最终用户进行Beta测试，用户反馈缺陷及必要的变更。另外，软件开发团队创建系统发布所必要的支持信息。统一过程的阶段生产阶段(production)：[发布]与通用过程的部署活动一致。在该阶段，监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。一个软件工程的工作流分布在所有UP阶段。统一过程工作产品起始阶段愿景文档初始用例模型初始项目术语表初始业务用例初始风险评估项目计划阶段及迭代业务模型如果需要一个或多个原型细化阶段用例模型补充需求包括非功能需求分析模型软件体系结构描述可执行的体系结构原型初步的设计模型修订的风险列表项目计划，包括迭代计划调整的工作流里程碑技术工作产品初始用户手册构建阶段设计模型软件构件集成的软件增量测试计划及步骤测试用例支持文档用户手册安装手册对于并发增量的描述转化阶段提交的软件增量Beta测试报告综合用户反馈UP每一个阶段产生的主要工作产品产品与过程如果过程很薄弱，最终产品必将受到影响。但是对过程的过于依赖也是很危险的。Rational统一过程适用场合适合大团队大项目。敏捷软件开发Agilesoftwaredevelopment高效工作、快速响应变化2001年2月，17位编程大师发表敏捷软件开发宣言①个体和交互胜过过程和工具②可以工作的软件胜过面面俱到的文档③客户合作胜过合同谈判④响应变化胜过遵循计划虽然右边的项有价值，但我们更重视左边的项敏捷Agility敏捷软件开发的基本原则客户参与到开发团队中确定系统需求、对需求排序、评估系统等软件以增量的方式进行开发和交付开发团队的技术和开发团队的风格应得到认可接受变更，设计软件适应变更保持所开发软件和开发过程的简单性•实践中的困难–客户不一定愿意参与到开发团队中–团队成员的性格–需求和变更的优先级不容易确定–维护简单性需要额外的时间–企业文化很难改变敏捷开发方法极限编程：eXtremeProgramming/XP自适应软件开发AdaptiveSoftwareDevelopment/ASD并列争球法：Scrum动态系统开发方法DynamicSystemDevelopmentMethod/DSDM水晶法：Crystal特征驱动开发：Feature-DrivenDevelopment/FDD精益软件开发：LeanSoftwareDevelopment/LSD…扩展内容极限编程eXtremeProgramming–XP把好的开发实践运用到极致为当前版本选择故事情节/需求（Scenario）将故事情节分解成任务规划版本开发/集成/测试软件发布软件评估系统•结对编程•先写测试用例再编程极限编程XPXP使用面向对象方法作为推荐的开发范型。XP包含了策划、设计、编码和测试4个框架活动的规则和实践。如图3-2所示。极限编程课本图3-2极限编程过程极限编程的过程策划：策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”。每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能的全局业务价值度标明权值（故事优先级）；评估每个故事给出开发周数为单位的成本；客户和团队共同决定故事分组；团队对待开发故事进行排序团队计算项目的速度在开发过程中，用户可增加、减少故事数，以及改变故事的优先级。极限编程的过程设计：XP设计严格遵循KIS原则，即使用简单而不是复杂的表述。另外，设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计。鼓励使用CRC卡（类-责任-协作者）确定和组织与当前软件增量相关的类；如果某个故事的设计中遇到困难，采用Spike方案；鼓励重构XP的中心观念是设计与编码可以同时进行。极限编程的过程编码：XP推荐的故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。XP编码活动中的关键概念之一是结对编程。XP建议两个人共同为一个故事开发代码，提供实时解决问题和实时保证质量。极限编程的过程测试：在编码开始之前建立单元测试是XP方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架，这种方式支持代码修改之后即时的回归测试策略。一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。XP验收测试，也称为客户测试，则客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。极限编程的有效实践增量式开发小版本短周期交付结对编程代码集体所有开放的工作空间可持续的开发速度：40小时/周，连续加班不超过两周•简单的设计•测试驱动开发•持续集成•重构•及时调整计划•客户作为开发团队成员敏捷开发的优点和缺点优点：对变化和不确定性有更快速更敏捷的反应在快速的同时保持可持续的开发速度能较好的地适应商业竞争环境下对小项目提出的有限资源和有限开发时间的约束缺点：极限编程中的测试驱动开发可能会导致系统通过了测试但不是用户期望的重构而不降低系统体系结构的质量是困难的用于大型项目有很多问题敏捷开发实例在敏捷软件开发中，