软件过程模型.ppt

上次课的基本知识点回顾,软件生命周期问题定义、可行性研究、需求分析、总体设计、详细设计、编码、测试、维护传统软件过程模型瀑布模型增量模型,上次课的基本知识点回顾,传统软件过程模型原型模型螺旋模型喷泉模型现代软件过程模型基于构件的开发模型形式化方法模型,如何选择软件过程模型,软件过程模型是不断发展的各种软件过程模型各有优缺点和适用场合选用时不必拘泥于某种模型可组合多种模型也可根据实际创造新的模型,应用举例,开发一个类似于Word的字处理软件。迭代1：提供基本的文件管理、编辑和文档生成功能。迭代2：提供高级的文档编辑功能。迭代3：实现拼写和语法检查功能。迭代4：完成高级的页面排版功能。,应用举例,应用举例：开发一个教务管理系统。第一次迭代：完成基本的学籍管理、选课和成绩管理功能。（6周）客户反馈：基本满意，但是对大数据量运行速度慢效率，不需要学生自己维护学籍的功能等。第二次迭代：修改细节，提高成绩统计和报表执行效率（2周）。客户反馈：需要严格的权限控制，报表打印格式不符合要求。第三次迭代：完善打印和权限控制功能。（2周）客户反馈：可以进行正式应用验证。,面向方面的软件开发,随着现代计算机系统变得更加复杂，某些关注点客户需要的属性或技术兴趣点已经体现在整个架构设计中。某些关注点是系统的高层属性（例如安全性、容错能力），某些关注点影响了系统的功能等。,如果某个关注点涉及系统多个方面的功能、特性和信息，这些关注点通常称为横切关注点。,面向方面的软件开发,方面需求定义那些对整个软件体系结构产生影响的横切关注点。面向方面的软件开发（AOSD）通常称为面向方面编程（AOP），为定义、说明、设计和构建方面提供过程和方法，是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。,面向方面的构件工程(AOCE),AOCE对纵向分解的软件构件进行横向切片，称为“方面”，以表示构件功能及非功能的横切属性。系统的方面包括用户接口、协同工作、发布、持续性、存储器管理、事务处理、安全、完整性等。构件也许提供或需要某一方面的“方面细节信息”，如视图机制、可扩展性和接口类型（用户接口方面）；事件生成、传输和接收（分布式方面）；数据存取/查询和索引（持久性方面）；认证、编码和访问权限（安全方面）；原子事务、协同控制和登录策略（事务方面）等。,Rational统一过程,Unified Process(UP)以用例驱动、以架构为核心，迭代增量模型的软件过程,描述了如何为软件开发团队有效的部署经过商业化验证的软件开发方法。它们被称为“最佳实践”，UP为每个团队成员提供了必要准则、模板和工具指导。,获得广泛使用基于面向对象方法学使用统一建模语言UML,统一过程的三个特点,用例驱动所有的软件开发都是用户需求驱动的。UP采用用例来描述用户需求，同时提供一套方法把用例转化为设计的类图，进一步变成最终的程序代码。在整个软件开发过程中，要求用例是可跟踪的，即在设计和实现阶段，都可以找到相应的需求。以架构为核心架构刻画了系统的整体设计，舍弃细节，突出重要特征。UP提供了创建架构的方法和过程。,统一过程的三个特点,UP采用迭代和增量的开发模式，把一个软件产品划分成多个较小的部分，每次完成一个部分，每次迭代都是产品的一个增量。优点：把一个复杂系统分解成多个简单系统，提供软件项目的可控性，降低软件开发的风险，有效的应对需求变更。,UP起源,面向对象 60年代 Alan Kay发明OO语言 Smalltalk和面向对象编程（Object-Orientedprogramming,OOP）1982年Grady Booch提出面向对象设计（Object-Oriented Design,OOD）80年代末，Peter Coad创建完整的OOA/D方法 三剑客及其建模方法 James Rumbaugh提出了OMT方法 Grady Booch提出了Booch方法 Ivar Jacobson提出了Objectory（Object Factory）方法,UP起源,UML 1994年James Rumbaugh和Grady Booch创建了统一方法（Unified Method），即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阶段。,统一过程工作产品,UP每一个阶段产生的主要工作产品,产品与过程,如果过程很薄弱，最终产品必将受到影响。但是对过程的过于依赖也是很危险的。,Rational统一过程,适用场合,适合大团队大项目。,敏捷软件开发,Agile software development高效工作、快速响应变化2001年2月，17位编程大师发表敏捷软件开发宣言个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划虽然右边的项有价值，但我们更重视左边的项,敏捷Agility,敏捷软件开发的基本原则,客户参与到开发团队中确定系统需求、对需求排序、评估系统等软件以增量的方式进行开发和交付开发团队的技术和开发团队的风格应得到认可接受变更，设计软件适应变更保持所开发软件和开发过程的简单性,实践中的困难客户不一定愿意参与到开发团队中团队成员的性格需求和变更的优先级不容易确定维护简单性需要额外的时间企业文化很难改变,敏捷开发方法,极限编程：eXtreme Programming/XP自适应软件开发Adaptive Software Development/ASD并列争球法：Scrum动态系统开发方法Dynamic System Development Method/DSDM水晶法：Crystal特征驱动开发：Feature-Driven Development/FDD精益软件开发：Lean Software Development/LSD,扩展内容,极限编程,eXtreme Programming XP把好的开发实践运用到极致,为当前版本选择故事情节/需求（Scenario）,将故事情节分解成任务,规划版本,开发/集成/测试软件,发布软件,评估系统,结对编程先写测试用例再编程,极限编程XP,XP使用面向对象方法作为推荐的开发范型。XP包含了策划、设计、编码和测试4个框架活动的规则和实践。如图3-2所示。,极限编程,课本图3-2 极限编程过程,极限编程的过程,策划：策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”。每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能的全局业务价值度标明权值（故事优先级）；评估每个故事给出开发周数为单位的成本；客户和团队共同决定故事分组；团队对待开发故事进行排序团队计算项目的速度在开发过程中，用户可增加、减少故事数，以及改变故事的优先级。,极限编程的过程,设计：XP设计严格遵循KIS原则，即使用简单而不是复杂的表述。另外，设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计。鼓励使用CRC卡（类-责任-协作者）确定和组织与当前软件增量相关的类；如果某个故事的设计中遇到困难，采用Spike方案；鼓励重构XP的中心观念是设计与编码可以同时进行。,极限编程的过程,编码：XP推荐的故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。XP编码活动中的关键概念之一是结对编程。XP建议两个人共同为一个故事开发代码，提供实时解决问题和实时保证质量。,极限编程的过程,测试：在编码开始之前建立单元测试是XP方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架，这种方式支持代码修改之后即时的回归测试策略。一旦将个人的单元测试组织到一个“通用测试集”，每天都可以进行系统的集成和确认测试。XP验收测试，也称为客户测试，则客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。,极限编程的有效实践,增量式开发小版本短周期交付结对编程代码集体所有开放的工作空间可持续的开发速度：40小时/周，连续加班不超过两周,简单的设计测试驱动开发持续集成重构及时调整计划客户作为开发团队成员,敏捷开发的优点和缺点,优点：对变化和不确定性有更快速更敏捷的反应在快速的同时保持可持续的开发速度能较好的地适应商业竞争环境下对小项目提出的有限资源和有限开发时间的约束缺点：极限编程中的测试驱动开发可能会导致系统通过了测试但不是用户期望的重构而不降低系统体系结构的质量是困难的用于大型项目有很多问题,敏捷开发实例,在敏捷软件开发中，测试人员的职责有三个主要方面：定义质量(Define Quality)交流缺陷（Communication）及时反馈(Feedback),我们的测试框架提供自助测试(Self-assistant Test)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。,敏捷开发中的测试流程,结合一个软件项目，详细介绍项目流程中的主要测试活动，每个活动的前提条件和目标任务等。,项目介绍：根据一家在线 B2B 公司的要求，我们将为其开发一款类似于谷歌的搜索服务。作为 Web Service，该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后，系统会返回具体商户的列表,典型的敏捷开发和测试活动,主要由三部分构成，从最初的用户故事设计和发布计划，到几次 Sprint 周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。通常 Sprint 周期被分成两类：特征周期（Feature Sprint）和发布周期（Release Sprint）。特征周期主要涉及新功能的开发和各类测试。发布周期则会结合计划，确定新版本功能，然后对最新的功能进行测试。,典型的敏捷开发和测试活动,典型的敏捷开发和测试活动,在迭代的 Sprint 周期中，开发部分可以根据传统步骤分成编码和单元测试、重构和集成。需要指出的是，重构和集成是敏捷开发的 Sprint 迭代中不可忽视的任务。如果在新的 Sprint 周期中要对上次的功能加以优化和改进，必然离不开重构和集成。在每个 Sprint 周期结束前，测试团队将提交针对该 Sprint 周期或者上个 Sprint 周期中已完成的功能的验收测试（在实际项目中，测试团队的进度通常会晚于开发团队）。这样一来，开发团队可以运行验收测试来验证所开发的功能目前是否符合预期。当然，这个预期也是在迭代中不断变化和完善的。当产品的所有功能得以实现，测试工作基本结束后，就进入了发布周期。此时，测试团队的任务相对较多。,用户故事设计和发布计划阶段,在用户故事和发布计划阶段，项目经理和产品经理会根据客户的需求，制定概要的产品发布日程计划。此时，测试人员可以和开发人员一起学习新的功能，了解客户的需求。其中，有两个主要活动：寻找隐藏的假设和设计概要的验收测试用例。,下面我们将对各阶段相应的测试活动作详细的介绍和分析,用户故事设计和发布计划阶段,1、寻找隐藏的假设 开发人员通常关注一些重要的系统功能而忽视细节。此外，敏捷开发倡导简单的实现方案，每个开发 Sprint 周期不可能将功能完美得实现；相反，每个 Sprint 都会增量得开发一些功能。所以，测试人员在最初就需要从各种角度来寻找系统需求，探索隐藏的假设。,用户故事设计和发布计划阶段,项目实例：从在线 B2B 公司角度思考Q：这个搜索框对公司的业务有什么价值？A：搜索框可以为用户方便得提供商户的目录信息。如果越来越多用户使用这个搜索框，可以增加我们网站的访问量。从用户角度思考Q：作为查询信息、寻找商业合作伙伴的网站用户，搜索框对我有什么好处？A：坏处：找到一家商户的地址，过去才发现已经关门歇业好处：查找商户很简单，只要轻点鼠标不快：有时候在寻找一类商户，却记不清楚具体名字,用户故事设计和发布计划阶段,项目实例：从程序员角度思考Q：一个搜索框的最简单实现方法是什么？A：一个有 text input 和 search button 组成的 form；后台通过 server 程序将符合类型和地址的商户名从数据库中取出，返回给用户；每个返回项包括商户的名称、地址和评价意见。寻找这些观点中的问题Q：搜索框如何在用户忘记具体名字的时候提醒用户？A：在第一版本中实现比较困难。可以让用户输入至少一个类型来提高模糊查找的效果。最后寻找到隐藏的假设,用户故事设计和发布计划阶段,让测试人员对系统的隐含假设更加清晰,首先，系统应该能够在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。其次，用户可以在已经查找到的内容中继续查找最后，系统提供一个商户类别清单；如果用户选择商户类别而忘记具体名字，系统提供模糊查询。,用户故事设计和发布计划阶段,3.2.2 设计概要的验收测试用例定义完一系列用户故事后，测试人员就可以着手设计概要的验收测试用例。不同于单元测试，验收测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的“动作”，然后为每条“动作”制定正例和反例。,项目实例：,用户故事设计和发布计划阶段,3.3 迭代 Sprint 阶段当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在定期的 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训计划。另外，每个团队可以根据各自团队成员的能力和工作经验，适当设定一个工作负载值（Load Factor）。比如，我们团队的工作负载值为 75%，也就是说每个人平均每天工作 6 小时（以 8 小时计算）。接着，大家就可以开始分配任务。,用户故事设计和发布计划阶段,3.3 迭代 Sprint 阶段当开发团队开始编码和单元测试时，测试人员的工作重点包括：估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。,用户故事设计和发布计划阶段,3.3.1 估算验收测试时间在软件开发初期，需要估算时间以制定计划。这一点在敏捷开发中应用更加广泛。如果以前的开发模式需要测试人员估算一个软件版本发行的计划（这样的计划通常会延续几个月），那么现在则要在每个 Sprint 机会会议上估算两周到一个月的任务。此外，在每天的站立会议上，测试人员需要不断得更新自己的估算时间，以应对变化的需求。所以，每个测试人员都应该具备一定的估算任务能力。下面我们将介绍一个通用的估算测试计划的方法：,用户故事设计和发布计划阶段,快速而粗糙的方法从经验而言，测试通常占项目开发的三分之一时间。如果一个项目开发估计要 30 天 1 人，那么测试时间为 10 天 1 人。项目实例：搜索框的开发估计需要 78 天 1 人完成。但是，考虑到系统有模糊搜索的功能，所以测试任务可能会占 40左右，大概 31 天 1 人。下面列出了具体的任务：,用户故事设计和发布计划阶段,用户故事设计和发布计划阶段,3.3.2 估算测试框架的搭建测试框架是自动测试必不可少的一部分工作。由于敏捷开发流程倡导快速而高效得完成任务，这就要求一定的自动测试率。一个完善的测试框架可以大大提高测试效率，及时反馈产品的质量。在敏捷开发流程中，在第一个 Sprint 周期里，需要增加一项建立测试框架的任务。在随后的迭代过程中，只有当测试框架需要大幅度调整时，测试团队才需要考虑将其单独作为任务，否则可以不用作为主要任务罗列出来。,用户故事设计和发布计划阶段,项目实例：考虑该项目刚刚进入测试，需要为此建立一个测试框架。于是，在原先的估算中多增加一些任务。,用户故事设计和发布计划阶段,3.3.3 详细设计验收测试用例完成对测试任务的估算，接着就可以着手详细设计验收测试用例。我们可以对概要设计中的测试用例进行细化，根据不同的测试环境、测试数据以及测试结果，编写更详细的测试用例。另外，可以结合几个用例，完成一个复杂的测试操作。,用户故事设计和发布计划阶段,由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现的缺陷可以设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。,用户故事设计和发布计划阶段,项目实例：基本验证测试用例：功能测试用例：,用户故事设计和发布计划阶段,3.3.4 编写验收测试用例敏捷开发不提倡撰写太多的文档，提倡直接编写测试用例。此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化成验收测试用例。如果资源充足，最好对验收测试用例建立版本控制机制。考虑到需求在每一轮 Sprint 周期中会不断得变化，测试团队要控制测试的自动化率，正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构，反而增加很多工作量。,用户故事设计和发布计划阶段,3.4 Sprint 结束和下一个 Sprint 开始在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。团队成员可以在会议上畅所欲言，指出在过去一个 Sprint 周期中可行的，不可行的和有待改进的地方。待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。由于敏捷开发倡导增量开发，当新的 Sprint 开始时，测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。如果新 Sprint 周期没有具体的新功能开发，测试团队可以将精力集中在执行验收测试和寻找缺陷上。如果下一个 Sprint 周期是发布周期，那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。,用户故事设计和发布计划阶段,3.4.1 重构验收测试正如上文所提及，敏捷开发是以迭代方式进行的，功能在每次迭代中推陈出新。于是，验收测试用例经常需要修改或者添加，相应的验收测试代码也需要删减。这部分工作如果时间花销很大，最好在估算的时候一并提出。项目实例：在下一个 Sprint 周期中，我们需要实现之前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例，在测试“搜索”模块中添加模糊查找测试。重新估算的测试任务参加下表：,用户故事设计和发布计划阶段,用户故事设计和发布计划阶段,3.4.2 执行验收测试验收测试可以分为两大类，基本验证测试和功能测试。如果是基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。如果是功能测试，可以在每个 Sprint 后期，新功能代码提交后，由测试人员单独执行。敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题，那就说明开发人员的实现违反了最初客户定义的需求，所以不能够提交。如果功能测试出现问题，那么测试人员要及时与开发人员沟通。如果是缺陷，需及时上报给项目经理，并在每天站立会议中提出；如果不是，那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。,用户故事设计和发布计划阶段,3.4.3 执行回归测试在发布周期中，测试人员所肩负的任务非常重要，因为这是产品发布前的最后质量检验。首先，要建立一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。估算方法参加上文。其次，定期执行各类测试，包括功能和系统测试。最后，要整理之前在每个特征测试周期中出现的问题。如果已经整理并归类为回归测试用例，那么只要定时执行就可以了；否则，需一一添加。如果用例已经被自动化，可以直接运行；如果是手工测试，测试人员需要按照测试用例进行操作，最后汇总测试结果。这部分测试就是所谓的回归测试。,敏捷开发的适用场合,适用场合,适用于需求模糊且经常改变的场合，适合商业竞争环境下的小项目。,小结：现代软件过程模型,Rational统一过程,1.面向对象软件开发；2.迭代式开发；3.动态视角：初始、精化、构建和产品化4阶段；4.静态视角：6个核心工作流：业务建模、需求、分析与设计、实施、测试、部署；3个支持工作流：配置与变更管理、项目管理、开发环境；5.实践视角：可采用的良好实践建议；,适合大团队大项目,小结：现代软件过程模型,敏捷软件开发,1.对变化和不确定性有更快速更敏捷的反应；2.在快速的同时保持可持续的开发速度；3.能较好的地适应商业竞争环境下对小项目提出的有限资源和有限开发时间的约束；,1.极限编程中的测试驱动开发可能会导致系统通过了测试但不是用户期望的；2.重构而不降低系统体系结构的质量是困难的；,适用于需求模糊且经常改变，商业竞争环境下的小项目,本章参考文献,软件工程：实践者的研究方法（原书第7版），Roger S.Pressman著，郑人杰、马素霞译，机械工业出版社，2011年软件工程导论（第5版），张海藩编著，清华大学出版社，2008年软件工程，郑仁杰等编著，人民邮电出版社，2009年软件工程（第9版），Ian Sommerville著，程成等译，机械工业出版社，2011年,作业,阐述瀑布模型的优缺点。分别举出使用瀑布模型、原型化模型和增量模型的软件项目的例子（勿使用课件中的例子）。请在两周内提交作业纸质版！,