鲲鹏应用开发与迁移 -课件 单元三 华为云DevCloud开发平台

华为云DevCloud开发平台010203瀑布开发模型敏捷开发模型DevOps开发模型瀑布开发模型瀑布模型概念瀑布开发模型是一种顺序软件开发模型，通常按照需求分析、设计、开发、测试、维护阶段依次执行，每个阶段只执行一次，它要求在前一个阶段的交付是完整且成熟的基础上进行下一个阶段的开发。瀑布开发模型一般适用于（但不限于）需求稳定或事后变更的代价比较高的场合。瀑布开发模型开发流程——需求分析需求分析就是回答做什么的过程。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，并把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书并最终得到用户的认可。需求分析的主要方法有结构化分析、数据流程图和数据字典等方法。本阶段的工作是根据需求规格说明书的要求，设计并建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计和定义，编写软件概要设计和详细设计说明书、数据库或数据结构设计说明书，组装测试计划。需求分析阶段主要需要解决的问题如下所示。分析方向解决的问题可行性分析是否具备资源完成；是否合规；是否能够解决用户问题；业务逻辑是否闭环；需求分析拆分大致的功能模块：权限、前台、后台；按照功能模块细化需求；是否有特殊要求：统一登录、前后端分离、日志格式、数据是否接入公司数据仓库等；瀑布开发模型开发流程——设计阶段软件设计可以分为概要设计和详细设计两个阶段。实际上，软件设计的主要任务就是将软件分解成能够实现特定功能的模块。这些模块可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元，然后进行概要设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，设细设计中的常用方法是结构化程序设计方法。需求分析阶段主要需要解决的问题如下所示。设计方向解决的问题概要设计系统性设计；基本处理流程；模块划分；功能分配；数据流图；ER图；软件选型等详细设计对概要设计进行细化；涉及的算法；采用的数据结构；类的继承关系（UML）；各个功能模块的接口划分；公共函数的定义；接口参数的定义等瀑布开发模型开发流程——开发阶段软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一种程序设计语言表示的“源程序清单”。如图所示，充分了解软件开发语言、工具的特性和编程风格，有助于开发人员更好地选择开发工具以及保证软件产品的开发质量。在当前的软件开发中，除在专用场合以外，已经很少使用20世纪80年代的高级语言，取而代之的是面向对象的开发语言，而且面向对象的开发语言和开发环境大都合为一体，大大提高了软件开发的速度。瀑布开发模型开发流程——测试阶段软件测试的目标是以较小的代价发现尽可能多的错误。实现这个目标的关键在于设计出一套出色的测试用例（测试数据和预期的输出结果组成了测试用例）。设计出一套出色的测试用例的关键在于理解测试方法。不同的测试方法对应不同的测试用例设计方法。常用的测试方法包括白盒法和黑盒法，白盒法的测试对象是源程序，其依据程序内部的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。黑盒法依据软件的功能或软件行为描述来发现软件的接口错误、功能错误和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化及系统错误。黑盒法测试用例设计的关键是以较少的用例覆盖模块输出和输入接口。测试是软件开发的重要阶段，如图所示，测试工作贯穿在软件开发的全过程中。瀑布开发模型开发流程——维护阶段维护是指在已完成对软件的研制（需求分析、设计、开发和测试）工作并交付用户使用以后，对软件产品所进行的一些软件工程的活动，即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正软件运行中发现的错误，并编写软件问题报告、软件修改报告。一个中等规模的软件，如果研制阶段需要一年至两年，在它投入使用以后，其运行或工作时间可能持续五年至十年，那么它的维护阶段也是在运行的这五年至十年期间。在这段时间，维护人员几乎需要着手解决研制阶段所遇到的各种问题，同时要解决某些维护工作本身特有的问题。做好软件维护工作，不仅能排除障碍，使软件正常工作，而且可以使它扩展功能，提高性能，为用户带来明显的经济效益。然而遗憾的是，人们对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。敏捷开发模型敏捷开发概述21世纪，各种敏捷方法如雨后春笋般蓬勃发展。自2001年起，“敏捷”一词在软件领域中被赋予了新的含义。“敏捷软件开发宣言”是我们认为在敏捷开发领域的权威文献。它是在2001年由17位轻型方法论家，在美国犹他州的雪鸟滑雪场上讨论了3天之后达成的共识，包括4项价值观和12条原则，其中值得我们注意的是第1条和第7条原则，如图所示。敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观

个体和互动

高于流程和工具

工作的软件

高于详尽的文档

客户合作

高于合同谈判

响应变化

高于遵循计划

也就是说，尽管右项有其价值，

我们更重视左项的价值。KentBeck

MikeBeedleArievanBennekum

AlistairCockburn WardCunningham MartinFowler

JamesGrenning JimHighsmith AndrewHunt

RonJeffries JonKern BrianMarick

RobertC.Martin SteveMellor KenSchwaber

JeffSutherland DaveThomas placeholder著作权为上述作者所有，2001年

此宣言可以任何形式自由地复制，但其全文必须包含上述申明在内。

敏捷开发12原则我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调整自身的举止表现。可工作的软件是进度的首要度量标准开发软件就像是制造汽车，都是自底向上逐步有序的创作过程。敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品。传统开发敏捷开发价值驱动-敏捷与传统瀑布型模式的最大区别敏捷基于这种方式，可以实现研发过程的持续高可视性、高可适应性，更早且持续产出业务价值，更早发现和解决风险。固定的估算的需求资源时间特性资源时间计划驱动价值驱动瀑布敏捷敏捷研发之价值主张可视性适应性业务价值风险敏捷研发传统研发进度进度进度进度敏捷常用的工程方法根据最新的第13届VersionOne版年度敏捷行业状态报告（如左图），以Scrum为基础的方法论（包括Scrum、Scrum/XP混合等）体系仍然居于主流地位，使用率最高。其他还有：看板方法、精益创业、极限编程等。除此之外，还有DSDM、FDD、RAD等一些符合敏捷精神的小众方法论，以及一些规模化敏捷的方法论，在此未一一列出。敏捷开发管理方法-Scrum1986年竹内弘高、野中郁次郎，《TheNewNewProductDevelopmentGame》1993年JeffSutherland首次在Easel公司定义了用于了软件开发行业的Scrum流程1995年JeffSutherland和KenSchwaber，规范化了Scrum框架，并在OOPSLA95上公开发布2001年敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法2001年KenSchwaber和MikeBeedle，第一本Scrum书籍《Scrum敏捷软件开发》2002年KenSchwaber和MikeCohn，共同创办了Scrum联盟全面视角的Scrum框架Scrum是一个轻量级的项目管理的框架，它的核心在于迭代。通过迭代去实现最终的产品。在整个框架当中，首先要有产品待办列表，在计划会议上团队从产品代表列表当中，选择合适的条目进入到迭代的待办列表，然后团队开始2~4周的迭代开发，在迭代开发的每一天团队都会进行每日站会，迭代结束后会提交一个潜在的可交付的增量，给用户评审，迭代最后团队会共同开展一次回顾会议，针对本次迭代的内容进行回顾。Scrum团队模型Scrum是一个包括了一系列实践和预定义角色的过程框架。任何的软件开发过程框架都可以由最基本的三个要素组成：角色（人）、活动及其输入输出的工件，Scrum框架主要包括以下内容：角色产品负责人（ProductOwner）

、Scrum主管（ScrumMaster）、团队成员活动冲刺规划会议（SprintPlanMeeting）、每日站立会议（ScrumDailyMeeting）、冲刺复审会议（SprintReviewMeeting）、冲刺回顾会议（SprintRetrospectiveMeeting）工件产品订单（ProductBacklog）、冲刺订单（SprintBacklog）、燃尽图（BurndownChart）、新的功能增量Scrum团队模型——角色ScrumMasterProduct

Owner团队保证Scrum团队可以遵守；Scrum的价值，实践和规范帮助Scrum团队和组织采用Scrum模式进行项目流程组织；指导并带领团队变得更加高效，实现更高质量；保护团队不要受到外界因素的干扰；保证各个不同角色之间的良好写作，消除障碍；帮助PO更好地利用团队的能力；不要管理团队。PO是一个人并只能由一个人来担任；负责管理产品待办事项表（ProductBacklog）并保证其对于客户和团队保持透明度；对产品代办事项表进行优先级排序；与团队一起来进行工作量估算；对于项目的成功负责并保证投资回报率（ROI）。最佳团队大小：5-9人；多功能团队：程序员，测试人员，设计师，数据库管理员和架构师；保证团队成员全职参与开发自我管理，没有头衔之分，不组建子团队；成员更替只能在迭代之间进行，最佳方式是在发布之间进行。Scrum三种工件产品BacklogSprintBacklog产品增量产品需求变动的唯一来源动态，永不完整,持续更新有序，排序越高越清晰具体;排序越低，

细节越少每个产品一个,与团队数量无关产品负责人负责管理其内容,可用性和排序包含产品待办事项列表中当前Sprint的子集包含完成Sprint目标所需的任务细节开发团队可视情况增加或移除任务当前Sprint完成的产品待办事项列表,以及之前所产生增量的总和必须达到"完成"的标准无论是否发布,必须是可用的Scrum过程模型(5个活动+1个合约)

迭代计划会议迭代合约迭代评审会议进行迭代规划；PO向团队介绍产品待办事项表；团队在PO的协助下充分了解产品待办事项；确定迭代目标和迭代合约；对产品待办事项进行细分并创建迭代待办事项。团队组成（成员列表，角色分配）；完成规范；团队对迭代目标的承诺；迭代长度；迭代待办事项的估算；迭代评审和下一次计划会议的时间和地点。团队展示完成的功能并收集反馈；对未完成的功能进行描述并说明原因；PO接受/不接受当前迭代；邀请所有人，包括客户参与。迭代团队用来实现迭代目标的时间区间；迭代目标：可发布的软件产品；1-4周，不多不少；时间长度决定何时结束迭代，而不由工作量的完成来决定；为团队提供保障。每日站立会议站立进行，固定时间，固定地点进行；3问题;你昨天完成了哪些工作？你今天计划做哪些工作？你遇到了哪些障碍？信息沟通用途，不解决任何问题不向任何人汇报。回顾会议那些做的好？那些做的不好？那些可以改进?仅团队成员参与。

时间盒原则时间盒原则敏捷开发管理方法-看板看板（kanban）一词来自日文，源于精益生产实践（丰田生产），敏捷开发将其背后的可视化管理理念借鉴过来。看板使得项目管理最大的可视化，但是看板更可以将研发的过程进行管理，记录下用户故事研发过程中的细节和历程。看板工具的实质是：后道工序在需要时，通过看板向前道工序发出信号——请给我需要数量的输入，前道工序只有得到看板后，才按需生产。看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。拉动的源头是最下游的客户价值，也就是客户订单或需求。思想工具(尊重他人，持续改善…)看板其他实践工具(标准化，可视化，5S，改进小组…)准时化自动化高质量，低成本，快速响应丰田生产方式(精益生产)的两大支柱是准时化和自动化，看板是运行它们的方法。丰田屋—丰田生产方式产品承载的价值流看板传递的信息流原材料输入工序N工序N+1客户价值(订单)看板看板看板……最终客户价值拉动制造工序N+1→工序N：请提供我完成工作的输入加工->组装型号1500-2100品名SA机油泵数量10看板展示核心元素看板中，通常存在分层、泳道、列、价值流、在制品（WIP）、风险&瓶颈、拉动式开发等核心元素，如下图：在制品数量限制：限制各阶段的在制品（含进行中的和完成的）允许的最大数目。在制品数量达到上限，不能再从上游拉入更多的工作。在制品数量小于上限，可以从上以环节拉入新的工作。形成一个从下游向上游的拉动机制。进行中完成进行中完成进行中完成Backlog设计开发测试发布2/34/43/3待开发1/3待测试2/4版本交付泳道紧急泳道拉动拉动拉动阻塞风险禁止拉动个人构建代码检视设计文档场景完善准入准出规则价值流看板分层架构基于产品研发等不同视角的价值流，看板可以划分为多层视图，更好的管理产品的价值的流动。产品级看板：基于产品视角看到的研发价值流，这是每个项目开展精益看板时，首先要分析和建立的看板系统。管理产品特性的流动。团队级看板：基于设计团队、开发团队、SIT测试团队的价值流视图，这是团队开展和改进的视图。精细化管理需求在设计阶段、Story开发、需求测试的流动。产品看板团队看板特性池分析开发测试SIT产品价值流完成设计开发团队Selected团队价值流StoryBacklog开发团队业务控制三层业务测试协议组……完成设计团队…分析团队…测试团队…卷积DevOps开发模型DevOps是什么DevOps的概念DevOps领先企业的观点DevOps专家的观点DevOps打破开发与运维之间的孤岛，积极协作。广义上指整个组织级的协作优化，包括IT、HR、财务、和公司供应商。约束理论告诉我们，需要优化整体而非单个“孤岛”。整体是与客户问题相关的业务，从精益角度来说，是整个价值链。PatrickDebois，DevOps名词的发明和运动的推动者，DevOpsDays创办人之一DevOps通常指的是新兴的专业化运动，提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性”。DevOps聚焦实现更快的上市时间，减少IT浪费，提高组织效率。GeneKim，DevOps领导者，《ThePhoenixProject:ANovelAboutIT,DevOps》、《TheVisibleOpsHandbook》作者亚马逊DevOps侧重于改善协作，沟通，整合软件开发与IT运维。是一个总称，用来描述一种理念、文化变革和模式转变。DevOps帮助亚马逊从软件开发敏捷走向业务和运维的敏捷。开发阶段，DevOps重点放在代码构建，代码覆盖，单元测试，打包和部署；运维阶段，在基础设施上聚焦环境分配，配置，编排和部署。微软DevOps不仅是一项技术或工具集，也是观念和文化的转变。它结合人、流程、适当的工具，使应用程序生命周期更快，更可预测。我们应将DevOps视为过程而非目的，应该选定适合范围的项目，增量式实施，通过这些项目展示成功，学习，并演进。DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。---维基百科，/wiki/DevOpsDevOps生命周期过程计划编码构建验证部署Dev运维/运营Ops持续集成持续交付自动化度量监控指标分析监控分享打破壁垒精益敏捷文化反馈发布DevOps持续交付实施框架100天发布1次1天发布100次10天发布1次1天发布1次1天发布10次分支模型测试模型技术架构部署模型基础设施数据库团队模型采用瀑布式开发的职能型矩阵结构采用迭代式开发的职能型矩阵结构采用迭代式开发的跨职能混合团队结构按照职能划分分支结构主干开发，分支发布主干开发，主干发布特性分支，主干发布独立测试部门承担功能性测试和自动化测试开发与测试的混合团队，共同承担功能性测试和自动化测试在流水线中自动运行的大量的单元测试，自动化功能测试和性能测试整体全量部署的单体应用可独立/增量部署的单独产品遵循SOA规范，并提供向后兼容性的微服务架构严格控制的发布周期和部署窗口灰度上线，AB测试，功能开关等允许代码直接上线的实践按需上线，开发人员直接推送代码进入生产环境独立运维部门严格管控的基础设施使用脚本自动创建生产环境一致的基础设施自助化弹性扩展的Paas或IaaS平台支持的InfraasCode服务手工完成数据结构迁移差异化增量脚本完成数据迁移提供数据结构的向前/向后兼容性关注七大领域，持续优化交付粒度，加快交付速度，提升交付质量敏捷与DevOps关系-知识体系EXINDevOpsMaster白皮书由EXIN（国际信息科学考试学会）推出；DevOps知识体系如下图，包括如下构成部分：敏捷管理、持续交付、IT服务管理（ITSM）、精益管理（Lean/TPS）。计划Planning需求

Requirement设计Design开发Development部署Deployment运营Operation周期终止EOL敏捷管理DisciplinedAgile持续交付ContinuousDeliveryIT服务管理（ITSM）ITServiceManagementSizeofTaskDoD,CIIteration(TimeBox)ProcessAutomationPatternofdeploymentAutomatedTestingBusinesscontinuity精益管理（Lean/TPS)Lean/ToyotaProductionSystemJust-In-Time(JIT),Autonomous(ANDONSystem)Ji-Koutei-Kanketsu(JKK)One-pieceflow(levelingworkload)Learningorganization(Reflection,KAIZEN)持续集成持