软件工程原理与实践（硕士）课件 02 软件过程

高级软件工程

SoftwareEngineering软件过程02-软件开发过程01-软件过程概述03-软件运维过程204-软件过程的实施与改进软件过程定义了软件组织和人员在软件产品的定义、开发和维护等阶段所实施的一系列活动。软件过程发展历史20世纪50年代：包含在硬件工程中的编码、测试等软件开发相关活动。20世纪60年代：形成了“软件工艺”的概念，以一种黑盒的方式存在（Code-and-Fix）20世纪70年代：在IBM360等大型项目经验基础上逐渐形成规范化软件过程的思想，出现瀑布模型等过程模型，显式定义开发过程。20世纪90年代：开发优秀软件过程的重要性得到广泛认同，CMUSEI提出了软件开发能力成熟度模型CMM/CMMI，用于评估和改进软件过程。21世纪00年代：敏捷开发的思想成为主流,出现了多种具有快速迭代反馈、适应需求变化等“轻量级”特点的开发过程。21世纪10年代：开发运维一体化（DevOps），打破开发和运维的界限，实现从运维到开发的快速反馈。3ISO/IEC12207软件生命周期过程4软件生存周期模型软件生存周期模型：又称软件过程模型，是对开发人员所采用的软件开发过程组织整体结构的抽象描述，表达了软件过程的结构框架软件生存周期模型的分类：线性顺序模型WaterfallModel增量模型IncrementalModel演化模型EvolutionaryModel又称迭代模型，是目前的主流模型敏捷过程是演化模型中的主流5线性顺序模型最早的软件开发模型1970年W.Royce提出又称为瀑布(Waterfall)模型需求设计编码测试运营和维护需求规约设计文档系统被确认的系统6优点重视需求和设计引入阶段评审，强调质量简单缺点串行，进度慢无法应对需求变更测试太迟，无法及时获得用户反馈和质量反馈增量（Incremental）模型需求和架构确定后，增量式进行开发，构造一系列可执行的版本7优点并行，加快了进度缺点未能缓解变更和质量风险需求变更和架构重构时的返工成本大大增加需要大量的开发人员演化模型风险驱动的迭代过程首先执行风险最大的任务并行开发每次迭代都有迭代的起因可以在细化所有需求之前启动开发工作更多的需求设计编码测试初始需求维护请求完整产品示例：迭代顺序执行的演化模型8优点有效缓解了进度、变更、技术、质量等风险缺点复杂，如何设计迭代？迭代原则每次迭代都应产生一个可执行的软件版本每次迭代本身都包括计划、建模、需求、分析和设计、实现、测试、评估等活动。基于风险，规划迭代－－有计划的迭代一个软件开发项目通常由3~9个迭代组成，项目的风险越高，迭代就越多。风险越高的工作，越在早期的迭代中执行。迭代周期一般是2~6周，这受软件项目的规模和复杂性、开发组织的规范、稳定性和成熟度、以及软件开发的自动化程度等影响。迭代可以并行、重叠、串行。9增量模型vs演化模型10增量模型演化模型演化模型成为主流现代软件过程都采用演化模型统一软件过程RUP敏捷过程（SCRUM、XP等）净室（Cleanroom）软件过程……11不同复杂性的软件应采用不同的过程模型12简单的软件–瀑布模型繁杂的软件–增量模型复杂的软件–演化模型混沌/模糊/无序的软件–

敏捷模型从瀑布到敏捷13瀑布vs敏捷StandishGroup2017ChaosReport1402-软件开发过程统一软件过程RUP敏捷过程XPSCRUMKanban01-软件过程概述03-软件运维过程1504-软件过程的实施与改进RUP蕴涵了最佳实践准则BestPracticesProcessMadePracticalDevelopIterativelyManageRequirementsUseComponentArchitecturesModelVisually(UML)ContinuouslyVerifyQualityManageChange16统一软件过程RUP17RUP是一个风险驱动的、基于UML和构件式架构的迭代、递增型开发过程

。InceptionElaborationConstructionTransitionRUP的四个阶段LifecycleObjectiveMilestoneLifecycleArchitectureMilestoneInitialOperationalCapabilityMilestoneProductReleasetimeInception-DefinethescopeofprojectElaboration-Planproject,specifyfeatures,baselinearchitectureConstruction-BuildtheproductTransition-Transitiontheproductintoendusercommunity每个阶段结束是一个大的里程碑18TypicalEffortandTimePercentagesbyPhaseIncElabConstTransEffort5%20%65%10%Time/Schedule10%30%50%10%TimePeopleConstElabTransInc19阶段和迭代Planned(Technical)VisibilityPointsInceptionElaborationConstructionTransitionPreliminaryIterationArchitectureIterationArchitectureIterationDevelopment

IterationDevelopment

IterationDevelopment

IterationTransitionIterationTransitionIterationAcceptanceorendoflifeProductsufficiently

matureforcustomerstouse

(Haveasolution)Architecturebaselined

(Understandthesolution)ScopeandBusiness

Caseagreement

(Understandtheproblem)Planned(Business)DecisionPoints20ConditionsthatIncreasetheNumberofIterationsInceptionWorkingwithnewfunctionalityUnknownbusinessenvironmentHighlyvolatilescopeMake-buydecisionsElaborationWorkingwithnewsystemenvironment(newarchitecturalfeatures)UntestedarchitecturalelementsNeedforsystemprototypesConstructionLotsofcodetowriteandverifyNewtechnologyordevelopmenttoolsTransitionNeedforalphasandbetasConversionsofcustomerbaseIncrementaldeliverytocustomers21RUP按内容组织Thedisciplinesare:BusinessModelingRequirementsAnalysis&DesignImplementationTestRUPcontentisorganizedintodisciplines.Adisciplineisacollectionofactivitiesthatareallrelatedtoamajor‘areaofconcern’.DeploymentConfiguration&ChangeManagementProjectManagementEnvironment22多个迭代ReqDesignImplTestDeployIteration1Iteration2Iteration3Time23工件的演化Withtheiterativeapproach,artifactsetsmatureovertime.24案例：选课系统的RUP软件过程现在计划重新开发交大的选课系统。现有的系统存在很多问题，其中最大不足就是抢课时系统出现的性能问题。新系统计划10月1日开始开发，要求1月1日上线，因为老师要选课了。注：学生选课在2月底。估计开发时间要4个月。请设计本项目的RUP软件过程提示：迭代的设计要诀：风险高的、优先级高的在前面的迭代完成阶段和阶段都是串行的每个迭代都包括需求分析、设计、编码、测试、发布每个迭代都产生可运行的版本25讨论：我们应该让迭代“重叠”吗？IBMRational对该问题的正式立场是不能重叠您的迭代。但许多成功的项目都宣称按此方式运作的。它致使许多人怀疑，“非重叠迭代”策略是否仅是对于实践概念的一种教条，或者在该策略背后是否真的存在某种原因。讨论：1）我们应该让迭代“重叠”吗？为什么？2）迭代“重叠”的风险有哪些？3）在什么情况下可以让迭代“重叠”？2602-软件开发过程统一软件过程RUP敏捷过程XPSCRUMKanban01-软件过程概述03-软件运维过程2704-软件过程的实施与改进预想目标实际目标计划执行定义性的过程定义性的过程28预想目标实际目标经验性的过程经验性的过程29敏捷过程敏捷过程很容易适应变化并迅速做出自我调整，在保证质量的前提下，实现企业效益的最大化。核心理念基于适应而非预测:通过快速、短迭代式的开发，不断产出和演化可运行软件，根据用户的反馈信息作适应性调整，然后进入下一轮快速短迭代式开发以人为导向而非过程导向:努力营造诚信、开放的组织氛围，根据项目中信息流通的具体情况，按高内聚、松耦合的原则，将项目组划分为若干个小组（每个小组以不超过10人为宜，组员均在一个工作间内工作），通过小组内各种渠道的沟通，来减少中间制品的工作负担，提高应变能力--MartinFowler“NewMethodology”30XPSCRUMKanbanCrystalFDDDSDMASDLeanDevelopmentAgileThinkingExplainedNeedtorespondtoconstantchangesValuesPrinciplesPracticesThefundamentalreasonforanewparadigmDefinesthesetofbeliefsaboutwhatisthemostimportantDefinesasetofwaystomeetthevaluesDefinesindetailhowthisisimplementedinpractice31Value--敏捷宣言较之于过程和工具，更注重人及其相互作用的价值较之于无所不及的各类文档，更注重可运行的软件的价值较之于合同谈判，更注重与客户合作的价值较之于按计划行事，更注重响应需求变化的价值322001年2月，敏捷过程的一些创始人在美国犹他州成立Agile联盟()，制定了敏捷宣言Principles--敏捷过程的12条指导原则（1）在快速不断地交付用户可运行软件的过程中，将使用户满意放在第一位以积极的态度对待需求的变化（不管该变化出现在开发早期还是后期）以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用在项目中，业务人员和开发人员最好能一起工作以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任在项目组中，最有用、最有效的信息沟通手段是面对面的交谈33Principles--敏捷过程的12条指导原则（2）测量项目进展的首要依据是可运行的软件高度重视可持续开发项目发起者、开发者和用户应能始终保持步调一致应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力简单化（尽可能减少不必要工作的艺术）最好的框架结构、需求和设计产生于自组织的项目组项目组要定期对其运作情况进行反思，提出改进意见，并进行相应的微调34敏捷过程的实践效果敏捷过程对当今时代的作用可与CMM在八十年代和九十年代初的作用相媲美

--TomDeMarco,CutterTrendsReport敏捷过程在实践中取得了巨大的成功

IONA公司的Obix技术支持小组在采用了XP方法后，软件生产率提高了67%SPG(softwareproductivitygroup)的CapersJones则称，SCRUM方法可提高生产率6倍35敏捷过程的适用范围适合采用敏捷过程的软件项目：需求不确定、易挥发有责任感和积极向上的开发人员用户容易沟通并能参与小于10个人的项目团队3602-软件开发过程统一软件过程RUP敏捷过程XPSCRUMKanban01-软件过程概述03-软件运维过程3704-软件过程的实施与改进极限编程（XP）－敏捷的软件开发技术由KentBeck、WardCunningham、RonJeffries等人提出反响最大、最为完善的敏捷过程方法。现场客户（On-siteCustomer）计划博弈（PlanningGame）系统隐喻（SystemMetaphor）简化设计（SimpleDesign）集体拥有代码（CollectiveCodeOwnership）结对编程（PairProgramming）测试驱动（Test-driven）小型发布（SmallReleases）重构（Refactoring）持续集成（Continuousintegration）每周40小时工作制（40-hourWeeks）代码规范（CodingStandards）38现场客户随时能联系客户是XP方法的基本要求之一XP的所有阶段都要求客户的强参与需求的调研Release的反馈参与测试…最好有客户派员直接参与开发组有时，派开发组进驻客户现场39计划博弈XP要求结合业务和技术情况，快速确定下一次发布的范围。在项目计划的4要素（费用、时间、质量和范围）中，由客户选择3个，而程序员可以选择剩下的1个。通常客户从业务角度确定项目范围、需求优先级和开发进度，开发人员则做出具体的成本和技术估计。XP强调简短和突发性的计划，有时只用几个小时甚至几分钟就能完成，而且可以随时按需进行多次计划。40系统隐喻XP通过一个简单的关于整个系统如何运作的隐喻性描述（story）来指导全部开发。隐喻可以看作是一种高层次的系统构想，通常包含了一些可以参照和比较的类和模式，它还给出了后续开发所使用的命名规则。XP不需要事先进行详细地架构设计。41简化设计需求是会经常变化的，因此设计不能一蹴而就而应该是一项持续进行的过程。KentBeck认为对于XP来说，简单设计应该满足以下几个原则：成功执行所有的测试；不包含重复的代码；向所有的开发人员清晰地描述编码以及其内在关系；尽可能包含最少的类与方法。42集体拥有代码认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。代码全体拥有并不意味者开发人员可以互相推委责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行BUG的修复。没有人会成为变更的瓶颈。43结对编程由两名程序员在同一台电脑上结成对子共同编写解决同一问题的代码。通常一个人写代码，另一个人同时负责保证代码的正确性和可读性，比如编写单元测试程序、进行代码走查。PP可以看作是一种非正式的持续进行的同行评审（peerreview）。44测试驱动先测试，再编码；代码未动，测试先行强调“测试先行”。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。注：测试的自动化。45小型发布强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。用户在发布后两个工作日内，向项目小组提交“用户接收测试报告”，由项目经理评估测试报告，将有效的BUG提交并分配给相应的开发人员。项目小组应该在下一个迭代周期结束前修复所有用户提交的问题。46重构强调代码重构在其中的作用，认为应该经常进行重构。重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。47持续集成开发人员应不断地将代码集成到代码库中，几小时一次，绝不超过1天每个人需要在最后的版本上工作持续集成能够在早期避免或发现一些兼容性问题。“现在付钱还是以后付更多的钱？”48每周40小时工作制不加班，不熬夜超时工作会吞噬开发组的精神和热情，加班不得连续超过两周，否则反而会影响生产率利用版本计划会来改变项目的范围和时间要求项目进度拖延时通过增加资源来改进也不是推荐的方法49代码规范所有代码必须采用统一标准以便理解。代码就是文档。强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。50

51XP与RUP的共性基础都是面向对象方法（取代传统的结构化方法）都重视代码、文档的最小化和设计的简化采用动态适应变化的演进式迭代周期（取代传统的瀑布型生命周期）需求和测试驱动鼓励用户积极参与52XP与RUP的区别XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念。RUP过程通常以架构为中心，细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。XP不包含业务建模、部署、过程管理等概念。RUP适合各种规模的项目，XP只适用于小团队。5302-软件开发过程统一软件过程RUP敏捷过程XPSCRUMKanban01-软件过程概述03-软件运维过程5404-软件过程的实施与改进Scrum－敏捷的软件项目管理1994年由KenSchwaber和JeffSutherland提出的敏捷过程Scrum一词来源于橄榄球运动，意为两队并列争球Scrum过程的核心：TeamEmpowerment自我管理IterativeDevelopment迭代开发55Scrum过程框架Sprint

(冲刺)：固定周期的迭代;Backlog(待办列表)：需求列表DailyScrum（每日站会）：每日15分钟简会56Scrum项目组团队组成（理想规模是7±2）ProductOwnerAddsitemstoproductbackloglistSetprioritiesTeamDeterminessprintlistDevelopssoftwareScrumMasterResponsibleforScrumprocessRemovesimpediments57团队要求自主管理（Self-managing）以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并实施。自我组织（Self-organizing）以前做好自己的事情就好了，现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。多功能型（Cross-functional）以前需求分析由需求分析员来做，测试由测试人员来做，现在每个人都全面负责，进行需求分析、设计和编码，同时自己测试。Backlog产品待办列表（ProductBacklog）是囊括了开发产品可能需要的所有事项的优先排列表。由ProductOwner负责，排出优先级，并估算开发时间Sprint待办列表（SprintBacklog）包含了在一个Sprint内将产品待办事项列表转化成最终可交付产品增量的所有任务。在Sprint计划会议上，Team选择并承诺实现SprintBacklog。在Sprint过程中，任何人无权改动SprintBacklog，直至Sprint结束。58一个SprintSprintPlanningmeeting(two4hoursegments)Productowner

&Team:identifiesbacklogitemstobedeliveredinsprint/TeamcommitsTeamplansdetailsinSprintBacklogDailyScrumMeeting(15minutes)Team:Reviewpriorday,identifyimpediments,plandaySprintReviewMeeting(4hours)Team:demonstratescompletedfunctionality-toProductOwner

andotherinterestedpartiesSprintRetrospectivemeeting(3hours)Team:howtoimprovenextsprintormakemoreenjoyable59Sprint的规则时间盒：限期N个连续日历日Team将利用这段时间构建为stakeholder提供重大效益的功能，并保证它能交付若Sprint发生异常，ScrumMaster可非正常终止Sprint。Team若认定无法在Sprint内兑现SprintBacklog承诺，可与ProductOwner协商从当前Sprint中删除部分条目。若删除条目过多，导致Sprint失去价值，ScrumMaster应非正常终止Sprint。Team若认定可在Sprint内超额处理Sprint计划的SprintBacklog，可与ProductOwner协商，添加额外的条目。60Sprint期间的交流和管理1)Scrum任务板2)Scrum每日立会3)燃尽图（Burndown）611)Sprint任务板62ToDo待处理的任务Doing进行中的任务Done已完成的表示任务2)ScrumMeeting团队通过每日例会（ScrumMeeting）来面对面的交流，团队成员大多站着开会，所以又称每日立会：我昨天做了啥我今天要做啥我碰到了哪些问题每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建，让大家每天都能看到一个逐渐完善的版本。633)燃尽图Sprintburndown64发布燃尽图（ReleaseBurndown）衡量在一个发布计划的时间段内剩余的产品待办事项列表。Sprint燃尽图（SprintBurndown）衡量在一个Sprint时间段内剩余的Sprint待办事项列表条目。1用户注册52登入商品133展示商品54搜索商品35在线交易86交易状态确认27特色商品推广58第三方支付139高级搜索功能310信用评价511返点活动支持312虚拟商品支持813物流跟踪814投诉处理5发布燃尽图Sprint1Sprint2Sprint….Sprintn产品代办事项优先级内容大小Sprint待办事项Sprint

燃尽图Sprint计划会议Sprint评审Sprint回顾每日scrum会议项目启动1.产品开发过程1.1高度透明1.2不断反馈调整PODEVDEVDEV/QAQASMDEV/QA2.团队2.1多功能2.2自组织3.持续改进3.1将改进嵌入开发过程3.2不断暴露和解决问题改善65案例：Scrum的好处通过“限定时间”避免过分追求完美通过“增量交付”改进工程实践通过“放权”和“自组织”激发创造力，更好地处理复杂问题，提升员工满意度66导致SCRUM项目失败的主要原因软件团队不是自组织团队，团队由项目经理或ScrumMaster进行指导和组织。ProductOwner或客户不参与每次迭代，不进行需求优先级划分，不参与每次演示，并且不为下一迭代选择具有最高商业价值的项。在迭代期内给团队成员追加新的需求或额外的任务。6702-软件开发过程统一软件过程RUP敏捷过程XPSCRUMKanban01-软件过程概述03-软件运维过程6804-软件过程的实施与改进什么是kanban看板方法源自丰田的JIT（just-in-time）生产方式。看板方法是用于高效管理软件开发流程的新技术。三大要素：流程可视化限制WIP

(work-in-progress,在制品)量度生产周期69kanban的特点kanban没有规定角色开发需求测试运维71kanban的特点kanban没有固定时长的迭代72kanban的特点反馈环:

改变=>检查结果=>从中学习=>继续改变73kanban的特点

WIP上限74kanban中的原则看板的原则是“一件出去，一件进来”（由WIP驱动），所以看板团队的响应时间（多久才能响应优先级的变化）就等于他们要花多长时间才能把手头的事情做完。75kanban中的团队看板不强制要求跨功能团队，看板图也不是独归某个团队所有。看板图对应的是流程，不必非得是一个团队。76看板图示例77看板图示例78看板图示例79看板图示例80看板图示例81看板图示例82看板图示例83看板图示例84看板图示例85看板图示例86看板图的例子87看板图示例88过程的选择软件过程的选择应综合考虑以下多种因素，进行敏捷和规范的平衡：产品/项目自身的特点“重”量级的软件过程适合需求相对稳定、项目规模较大、开发周期较长、质量攸关、产品/项目较广的情形。而以敏捷开发为代表的“轻”量级过程比较适合需求变化快、项目规模小、开发周期短、项目干系人少的项目。团队的实际情况和企业文化敏捷开发为主的软件过程对团队成员的要求非常高，无论是专业技能、沟通技巧还是职业精神。要求软件组织对开发团队充分信任、充分授权、积极支持。客户的影响通常客户不会直接介入开发团队对过程的选择。但是大型客户对于供应商可能有强制的过程标准。8902-软件开发过程01-软件过程概述03-软件运维过程9004-软件过程的实施与改进软件运维的实践现状2006年10月13日，民航总局离港系统主机发生故障，导致长沙、北京、上海和广州等全国多个机场离港系统瘫痪；2006年4月20日，中国银联全国性瘫痪8小时；2002年7月23日，首都机场因电脑系统故障，150多驾飞机延误；2002年5月29日上午，南京火车站电脑售票系统由于电脑升级换代，调试时线路发生故障，引发系统瘫痪。2002年9月5日广东省工行因系统故障，全线停业一个半小时，这是工行实施全国统一平台运作后的首次故障。91从系统管理到IT服务管理20世纪80年代，英国中央计算机与电信开发了一套IT服务管理方法，即ITIL（InformationTechnologyInfrastructureLibrary），它被公认为IT管理的最佳实践。2005年以ITIL为基础的英国国家标准BS15000被国际标准化组织接受，成为IT服务管理ISO/IEC20000国际标准。92软件运维过程（Operation&Maintenance）93开发运维一体化DevOps很多组织将开发和运维划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，造成了鸿沟。DevOps将敏捷的精神延伸到运维阶段，提出软件开发和运维之间的沟通、协作和集成所采用的一体化流程、方法和体系，以提高软件交付的价值、速度和质量。94快速迭代的增量开发持续的自动化测试持续集成频繁部署持续的质量和性能监控快速的反馈和改进机制实现价值从开发到运维的快速流动持续集成和持续交付（CICD)开发人员能快速地完成开发、集成、验证，并将代码更新部署到生产环境中，从而有效地将前置时间（从开发任务产生到交付相应的价值的这段时间）缩短到小时直至分钟级别9502-软件开发过程01-软件过程概述03-软件运维过程9604-软件过程的实施与改进IDEALModel

97过程实施NewProcessCompletely

ImplementedPlanImplementationDefineProcessEvaluateProcessAssessDevelopmentOrganization45326EstablishProcessInfrastructureDeployProcess-MakeToolsWork-TrainPeople-…1981)EstablishProcessInfrastructureToestablishsoftwarelifecycleprocess,itisnecessarytohaveanappropriateinfrastructureinplace,meaningthattheresourcesmustbeavailable(competentstaff,tools,andfunding)andtheresponsibilitiesassigned.Whenthesetaskshavebeencompleted,itisanindicationofmanagement’scommitmentto,andownershipof,thesoftwareengineeringprocesseffort.Variouscommitteesmayhavetobeestablished,suchasasteeringcommitteetooverseetheSEprocesseffort.TheSoftwareEngineeringProcessGroup(SEPG)992)AssessDevelopmentOrganizationBusinessContextExternalFactorsInternalFactorsProductCharacteristicsProcessImplem