《《敏捷开发基础知识》课件.docx》由会员分享，可在线阅读，更多相关《《敏捷开发基础知识》课件.docx（16页珍藏版）》请在三一办公上搜索。
1、敏捷开发基础知识软件工程及软件过程模型1.软件需求分析与定义软件需求是一个为解决特定问题而必须由披开发或被修改的软件展示的特性。这个问题可能是使用软件的某人的任务中的一个自动化部分，或是支持委托开发软件的组织的业务流程，或修正当前软件的缺点,或是控制一个设备等。用户、业务流程和设备的功能通常根复杂，因此，特定软件的需求在外延上通常是来自一个组织不同层次的不同人员的需求和来自软件将要在其中运行的环境的需求的复杂组合。所有软件需求的一个基本特性就是可验证性。验证某些软件需求可能很困难或者成本很高。软件需求和软件质保人员都必须保证，在现有的资源约束下，需求可以被验证。除了其表达的行为特性外，需求还有
2、其他特性，如优先级，以便在资源有限时进行权衡。通常,要唯一地标识软件需求，才能在整个软件生命周期中,进行软件配置控制和管理。需求分析涉及分析需求的过程，其目的如下。(1)检测和解决需求之间的冲突。(2)发现软件的边界，以及软件与其环境如何交互。(3)详细描述系统需求，以导出软件需求。描述需求时必须仔细，应该精确到能确认需求，验证需求的实现，估算需求的成本。开发真实世界问题的模型是软件需求分析的关键模型的目的是帮助理解问题，而不是启动方案的设计。因此，概念模型由来自问题域的实体模型组成，实体模型反映了它们在真实世界的联系和依赖。可以开发的模型包括数据和控制流、状态模型、事件追踪、用户交互、对象模
3、型、数据模型,以及其他模型。架构设计是需求过程与软件或系统设计重叠进行的,将二者截然分开是不可能的。其工作是需求分配，即将满足需求的职责分配到组件上。需求协商的另一个普遍使用的术语是解决冲突。这涉及需求冲突的问题，冲突发生在两个不兼容的需求之间，或者发生在需求与资源之间，或者在功能与m期能需求之间。2 .软件设计、测试与维护软件设计软件设计是定义一个系统或组件的架构、组件、接口和其他特征的逆程，并得到这个过程的结果Mo作为过程看待时，软件设计是一种软件生命周期活动，在这个活动中，要分析软件需求，以产生一个软件内部结构的描述，并将其作为软件构造的基础。更精确地说，软件设计必须描述软件架构和这些组
4、件之间的接口，也必须在详细的层次上描述组件，以便能构造这些组件。软件设计在软件开发中起着重要作用，通过它形成要实现的各种不同模型。分析和评价这些模型，以确定它们能否实现各种不同的需求，在各种不同的候选方案中进行权衡，确定最终方案。最后，将其作为构造和测试的输入和起始点，并用来规划后续的开发活动。软件设计由两个处于软件需求和软件构造之间的活动组成。软件架构设计（有时叫做高层设计）：描述软件的结构和组织，标识各种不同的组件。软件详细设计:详细地描述各个组件，使之能被构造.软件架构是一个描述软件系统的子系统和组件,以及它们之间相互关系的学科。架构试图定义软件的内部结构。通过视图可以从不同角度描述软件
5、结构,主要包括逻辑视图（满足功能需求过程视图（并发问题组件视图（实现问题部署视图（分布问题模式提供了架构设计的某些方法。模式是给定上下文中普遍问题的普遍解决方案，主要涉及设计模式（微观架构模式）和架构模式（宏观架构软件测试测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。软件测试是针对一个程序的行为，在有限测试用例集合上，动态验证是否达到预期的行为，需要选取适当的测试用例。测试不再只是一种仅在编码阶段完成后才开始的活动。现在的软件测试被认为是一种应该包括在整个开发和维护过程中的活动,它本身是实际产品构造的一个重要部分。测试不仅是检查预防措施是否有效的主要手段，而且是识别由于某种原因
6、预舫措施无效而产生的错误的主要手E殳。需要注意的是,在广泛的测试活动成功完成后,软件可能仍包含错误,交付后出现的软件失效的补救措施是由软件维护达成的。软件测试随开发和维护过程，通常在不同的级别上进行，可以在概念上区分三个大的测试阶段：单元测试、集成测试和系统测试。23.软件维护软件开发工作的结果是交付满足用户需求的软件产品。相应地，软件产品必然存在变更和演化。一旦投入运行，就可能发现缺昭，运行环境可能会变化，用户会提出新的需求。软件维护是坐命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动。这些活动包括在交付前完成的活动，以及交付后完成的活动。交付前完成的活动包括交付后运行的
7、计划和维护计划等。交付后的活动包括软件修改、培训、帮助资料等。软件维护包括如下类型。Q)更正性维护：软件产品交付后进行的修改，以更正发现的问题。(2)适应性维护：软件产品交付后进行的修改，以保持软件产品能在变化后或变化中的环境中可以继续使用。(3)完善性维护：软件产品交付后进行的修改，以改进性能和司维护性。(4)预防性维护：软件产品交付后进行的修改，以在软件产品中的潜在错误成为实际错误前，检测和更正它们。3 .软件复用软件复用是指利用已有软件的各种有关知识构造新的软件以缩减软件开发和维护的费用。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，
8、后来扩大到包括领域知识、开发经验、设计决策、架构、需求、设计、代码和文档等一切有关方面。软件复用是一种计算机软件工程方法和理论。20世纪60年代的软件危机”使程序设计人员明白难于维护的软件的成本是极其高昂的，当软件的规模不断扩大时，这种软件的综合成本可以说是没有人能负担的，并且即使投入了高昂的资金也难以得到可靠的产品，而软件重用是解决这一问题的有效方法。软件复用的主要思想是，将软件看成是由不同功能的组件所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具，这样，如果完成各种工作的组件被建立起来以后,编写某一特定软件的工作就变成了将各种不同组件组织连接起来的简单问题,这对于软
9、件产品的最终质量和维护工作都有本质性的改变。软件制品的复用，按抽象程度的高低，可以划分为如下复用级别：代码的复用、设计的复用、分析的复用、测试信息的复用等。支持软件复用是人们对面向对象方法寄托的主要希望之一，也是这种方法受到广泛重视的主要原因之一。面向对象方法之所以特别有利于软件复用,是由于它的主要概念及原则与软件复用的要求十分吻合。面向对象的软件开发和软件复用之间的关系是相辅相成的。一方面，面向对象的方法的基本概念、原则与技术提供了实现软件复用的有利条件；另一方面，软件复用技术也对面向对象的软件开发提供了有力的支持。4 .软件开发环境软件开发工具是用于辅助软件生命周期过程的基于计算机的工具。
10、通常可以设计并实现工具来支持特定的软件工程方法，减少手工方式管理的负担。与软件工程方法一样，它们试图让软件工程更加系统化，工具的种类包括支持单个任务的工具及囊括整个生命周期的工具。1 .软件需求工具软件需求工具包括需求建模工具和需求追踪工具。2 .软件设计工具软件设计工具用于创建和检查软件设计,因为软件设计方法的多样性，这类工具的种类很多。3 .软件构造工具软件构造工具包括程序编辑器、4 .软件测试工具软件测试工具包括测试生成器、能分析工具。编译器和代码生成器、解释器、调试器等。测试执行框架、测试评价工具、测试管理工具5 .软件维护工具软件维护工具包括理解工具（如可视化工具）和再造工具（如重构
11、工具6 .软件配置管理工具软件配置管理工具包括追踪工具、版本管理工郸口发布工具。7 .软件工程管理工具软件工程管理工具包括项目计划与追踪工具、风险管理工郸口度量工具。8 .软件工程过程工具软件工程过程工具包括建模工具、管理工具、软件开发环境。9 .软件质量工具软件质量工具包括检查工郸口分析工具。5软件过程模型5.1. 概述软件过程模型是指一种用于指导软件开发过程的特定方法,它包括软件开发中的所有活动和任务，并在整个过程中提供了一系列的标准和规范。软件过程模型的核心思想是将软件开发过程分为一系列的步骤,并且在每个步骤中设置相应的输入、输出和控制流程，从而使得整个软件开发过程变得更加可靠和高效。5
12、.2. 常见的软件过程模型1 .瀑布模型瀑布模型是一种传统的软件过程模型，将整个软件开发过程分为五个阶段，分别是需求分析、设计、实现、测试和维护。瀑布模型的优点是结构简单，易于理解和使用，同时缺点也很明显，比如缺乏灵活性、周期较长、迭代困难等。2 .增量模型增量模型是一种将软件开发过程分为若干个增量,对每个增量进行开发和测试，最后再进行集成的过程模型。增量模型的优点是可以快速地得到一个基本功能完整的软件系统,同时也可以逐步完善和优化软件系统。缺点是增量之间的集成会存在较大的风险,需要注意控制。3 .螺旋模型螺旋模型是一种基于风险管理的软件过程模型,将软件开发过程分为四个阶段，分别是计划、风险分
13、析、工程实施和评估。螺旋模型的优点是可以快速地发现和控制风险，同时也可以在开发过程中逐步完善和优化软件系统。缺点是需要更多的资源和时间来进行风险分析和控制。5.3. 如何选择合适的过程模型在选择软件过程模型的时候,需要考虑以下几个方面：1 .项目的规模和复杂度。如果项目规模较大，应该选择一种较为成熟和完善的软件过程模型，比如RUP或者敏捷开发等；如果项目规模较小,则可以选择更加简单的模型,比如瀑布模型或增量模型。2 .团队成员的经验和技能。如果团队成员经验丰富且具备较高的技能水平,则可以选择一种较为灵活和动态的软件过程模型，比如敏捷开发等；如果团队成员水平较为一般，则需要选择一种更加规范和标准
14、的软件过程模型，比如RUP或瀑布模型。3 .项目的需求和特点。软件开发项目的需求和特点不同，需要选择适合的软件过程模型。比如对于需要快速交付的项目，可以选择增量模型或快速原型模型等；对于需要长期维护的项目，可以选择螺旋模型或演化式开发等。敏捷开发特点及思想敏捷软件开发是基于敏捷宣言定义的价值观敏捷软件开发宣言和原则敏捷软件的十二条原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力,这就叫做敏捷开发。2.核心理念敏捷开发是一
15、种软件开发思想和方法论,其核心理念包括以下几个重要方面:个体互动比流程和工具重要：敏捷开发强调人与人之间的交流和协作。虽然工郸口流程也很重要，但更加注重开发团队成员之间的互动，以及与客户和利益相关者之间的有效沟通。可工作的软件比详尽的文档重要海攵捷开发倡导快速交付可工作的软件原型,而不是过度关注文档编写。通过这种方式，可以更早地获取用户反馈，从而更好地满足用户需求。客户合作比合同谈判重要：敏捷开发强调与客户的积极合作，以理解和满足他们的需求。这意味着在项目进程中，随着需求的变化，开发团队愿意灵活地调整软件的功能。响应变化比遵循计划重要：敏捷开发认识到需求和市场条件会不断变化，因此更注重灵活性和
16、适应性,而不是死板地遵循预定计划。技术卓越比满足最低需求重要：敏捷开发鼓励团队努力追求技术卓越，以确保交付的软件是高质量、可维护和可扩展的。持续交付比一次性交付重要：敏捷开发推崇通过小而频繁的软件交付，持续提供价值，而不是等待一个完整的产品版本交付。合作比合作阵营重要:敏捷开发鼓励开发团队内部和与利益相关者之间的合作，以创造共同的理瞬口成功。简单性比复杂性重要：敏捷开发鼓励简化过程和软件设计，以降低复杂性，提高可维护性。总的来说，敏捷开发的思想强调灵活性、合作、响应变化和交付价值。这些原则有助于更好地适应不断变化的需求和市场条件,以便更成功地开发软件项目。2 .特点敏捷开发是一种软件开发方法论
17、，它强调快速、灵活和协作的方式来开发软件。以下是敏捷开发的一些主要特点：迭代和增量开发：敏捷开发采用迭代和增量的方式，将项目分解成小的可管理的部分，每个迭代都会产生一个可用的软件版本，逐步完善软件，以便及时反馈和改进。重视用户需求和反馈：敏捷开发注重与用户的密切互动，持续收集用户需求和反馈，以确保软件能够满足用户的实际需求。自组织的团队：敏捷开发鼓励自组织的开发团队，团队成员在项目中具有更多的自主权和决策权,以提高工作效率和质量。重视人际沟通和协作：敏捷开发强调团队成员之间的沟通和协作，通过日常站会、讨论和合作解决问题，以推动项目的进展。可变性和适应性：敏捷开发接受需求和优先级的变化,可以随时
18、进行调整，以应对不断变化的市场需求和技术挑战。持续集成和自动化测试：敏捷开发强调持续集成,通过自动化测试和部署，确保软件质量和稳定性，并减少人为错误。小团队和小项目规模：敏捷开发通常更适用于小型至中等规模的项目和小团队，以提高团队的协作和决策效率。可视化工具和度量：使用敏捷开发的团队通常使用可视化工具来跟踪项目进度和度量项目绩效，以帮助做出更明智的决策。注重质量：敏捷开发注重交付高质量的软件，通过反复的测试和持续改进来确保软件的可维护性和稳定性。总的来说，每攵捷开发强调快速交付、灵活性、用户导向和协作，以满足不断变化的需求和市场条件。这些特点有助于提高软件开发的效率和质量。3 .敏捷开发十二原
19、则1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户尽早交付有价值的软件。2、频繁地交付可运行的软件，数周或者数月交付一次频繁发布新版本。3、可运行的软件是衡量进展的主要标准软件比文档更重要4、接受需求变更,即便是在开发最后阶段一倾听，并快速学习5、项目期间业务人员与开发者共同工作紧密协作6、找积极主动的人来开发项目为他们提供所需的环境和支持,相信他们能做好自己的工作7、开发团队里最节省时间最有效的信息传递方式是面对面的交流8、自发组织的团队才能做出最好的架构、和设计架构要敏捷，好主意无处不在9、持续关注先进的技术和优秀的设计能促进敏捷性频繁地重构10、敏捷过程促进可持续的开发此举应能
20、维持相对稳健的节奏而不是导致失败11、简洁是一切的基础少即是多12、团队定期反思如何提高效率,并调整工作流程事后反思2.3. 敏捷开发方法介绍2.3.1. 敏捷开发流程简介敏捷软件开发核心是迭代式开发，增量交付。每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。迭代型的方法就是将整个软件生命周期分成多个小的迭代,每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一
21、定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。敏捷流程详解图-敏捷流程图POTMSM232敏捷流程三种角色及其职责角色名称角色定义角色职责注意事项Product确保Team做代表利益相关人（如除了客户需求Owner(PO)正确的事用户、市场、管理等），之外，内部任产品负责人对产品投资回报负责务如重构、持确定产品发布计划续集成环境搭建等也由PO定义产品需求，根据纳入统一管理市场价值确定功能优先级验收迭代结果，并根据验收结果和需求变化更新需求清单和优先级ScrumMaster(SM)-Scrum教练确保Team正确的做事 辅导团队正确应用敏捷实践 引导团队建立并遵守规则 保护团队
22、不受打扰 推动解决团队遇到的障碍 保证开发过程按计划进行，组织站立会，冲刺评审会，冲刺回顾会议不命令和控制TeamTeam-开发团队负责产品需求实现负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量向Po和利益相关人一般由5-9人左右跨职能领域人员（开发人员、测试人员、设计师等）员演示工作成果（可运行的软件）团队车管员构团队自身管理、持续成在sprint内改进不允许变化有共同的目标、共担责任团队成员严格遵守团队规则233敏捷开发流程详解2.3.3.1.流程图详解步骤1.制定产品需求列表PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制T分按优先级排序的、明确的、可
23、度量的、合理的产品需求列表；2召开计划会议PO召集TM和SM（也可邀请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物，冲刺计划就是确定该冲刺阶的长度（建议冲刺长度1-4周目标和冲刺任务单及其工作量估算（以理想人天manday=7.5h估算,单位为小时计算），会议时间建议不要超过6h时间;在计划会议上就需要进行确认,是否需要使用持续集成；若使用持续集成，团队需要每天科壬前至少提交一次私有构建成功的代码到服务器,并且要求写详细的日志信息；若不使用持续集成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关
24、人员；项目计划会议上可以确定每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决，在私下进行沟通,不要在会议上讨论。站立会上只有TM人员有发言权，其他人员不要干预，SM主要是维护秩序、规则及其引导作用。3 .需求分析、设计、编码和测试：计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试；这里特别要说明的是,开发和测试是并行工作,必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等具体情况，需要项目组根据实际情况决定，但客户
25、要求交付的文档必须要输出；4 .冲刺任务单和燃尽图更新每天SM需要根据每日站立会上TM反馈的情况进行更新冲刺任务单和燃尽图或SM和TM之间达成共识，TM各自完成后进行更改状态,这里涉及到的文档都会有相对应的模板供参考使用。5 .迭代周期结束点已到迭代周期结束点,只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。这里要特别注意,所谓的测试通过不是说要把所有的问题都解决才算是通过,这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需求列表中挑选优先级高的进行开发。6 .冲刺评审会议TM需要召开冲刺评审会议,邀
26、请P0、客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时，参加人员除PO及其相关利益人来参加外，TM全体成员,也可以邀请其他相关人员参加。7 .冲刺回顾会议迭代输出的增量交付可能会引起原产品需求列表的改变,可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括:POsSMxTM,其他相关人员也可以参加。这里要说明的是在每次的计划会议上要注意安排时间做冲刺评审会议和冲刺回顾会议。下一次迭代的计划会议建议在上一次迭代的冲刺回顾会议结束后再开展。8 .重复2-7步骤直到所有列入本版本规划的任务单都完成，最后发布版本；特别说明：通常最后一个迭代可能是全量进行验证的周期。
