清华大学软件工程教材

软件过程清华大学软件学院2内容提纲•软件过程–基本概念–基本活动：需求工程、软件开发、测试和演化•软件过程模型–瀑布模型–快速原型模型–增量模型–螺旋模型–形式化方法模型–基于组件的开发模型•案例：微软公司软件开发过程模型Youarehere!你在这儿！3建造一个房屋的过程相同的生命周期不同的过程4任务思维模式•问题–假设：软件需求可以在开发初期完全确定下来–与用户的交互只是发生在确定需求之时和发布产品之后–现实情况很少符合上述假设过程产品用户需求5过程思维模式•好处–通过提高可见性来降低开发风险–允许在项目进展过程中基于用户的反馈进行项目变更过程产品用户需求反馈6软件过程的概念•软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。•软件过程应该明确定义–团队人员的工作和职责–所执行的活动及其顺序关系–活动的内容和步骤•软件过程的目标–标准化、预见性、生产率、高质量、计划进度和预算的能力7软件过程的运行机制过程定义活动定义活动关系过程制品过程执行过程结果过程改进用户反馈用户需求软件产品过程资源参与人员活动工具8定义软件过程的步骤•定义–入口准则：何时开始该步骤？–可重复的任务：应该做什么？–确认：如何知道做得怎样？–出口准则：已经完成了吗？入口准则任务确认流程输入输出出口准则9过程定义模板项目目的1.目标该过程的目的是什么？2.所有者谁是负责该过程？谁负责文档、交流、维护和持续改进此过程？3.输入该过程的输入是什么？这些输入来自何处？这些输入有什么约束和依赖？4.输出该过程的输出是什么？这些输出去向如何？这些输出有什么约束和依赖？5.入口准则该过程的启动要求是什么？6.出口准则该过程的结束要求是什么？7.任务实现该过程目标需要什么任务？8.依赖／约束该过程任务或步骤中有什么依赖或约束？9.确认该过程的度量标准是什么？如何知道任务是否达到预期？如何知道目标是否满足？10软件过程的基本活动•软件过程的四个基本活动–规格说明（Specification）定义软件功能以及对其使用的限制–软件开发（Development）设计和实现满足规格说明的软件–软件确认（Validation）验证软件以保证能够满足客户的要求–软件演化（Evolution）改进软件以适应不断变化的需求•不同的组织或软件类型拥有不同的软件开发活动。11软件规格说明•软件规格说明是确定系统需要的服务以及运行与开发中所受约束的过程，也称为需求工程。•需求工程的过程持续进行的需求管理需求获取需求分析需求规格说明需求验证会议记录等会议记录等分析模型分析模型需求规格说明书需求规格说明书已确认的需求规格说明书已确认的需求规格说明书活动工作产品12软件设计与实现•软件设计是根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现算法、数据结构及其接口等。软件实现是将软件设计转换成程序代码。•软件设计的过程需求规格说明需求规格说明体系结构设计体系结构设计抽象描述抽象描述接口设计接口设计组件设计组件设计数据结构设计数据结构设计算法设计算法设计系统体系结构系统体系结构系统规格说明系统规格说明接口说明接口说明组件说明组件说明数据结构说明数据结构说明算法说明算法说明设计活动设计产品13软件确认•验证和确认（V&V）需要指出软件是否符合规格说明以及是否满足客户的需求。–验证和确认包括检查和评审过程以及系统测试–系统测试是使用由规格说明产生的测试用例执行软件的过程•软件测试过程需求规格说明需求规格说明系统规格说明系统规格说明系统设计系统设计详细设计详细设计单元测试单元测试子系统集成测试子系统集成测试系统集成测试系统集成测试验收测试验收测试维护维护验收测试计划验收测试计划系统集成测试计划系统集成测试计划子系统集成测试计划子系统集成测试计划14软件演化•软件的内在本质是灵活的和可变的–随着业务需求的变化，软件必须进化和变更–尽管在开发过程和演化（维护）过程之间存在划分，但是现实中全新的系统越来越少•认识软件演化过程–好的软件需要维护–维护软件的成本是很高的，应该在开发阶段考虑维护的问题–文档是很重要的，但在实际开发中经常存在文档过时或缺少文档的情况15案例：IBM开发过程流程软件开发流程发布管理过程计划文档设计子流程编码与单元测试子流程体系结构设计阶段功能规格说明阶段设计规格说明阶段功能测试过程编码阶段单元测试阶段代码审查阶段待测试的代码体系结构文档功能说明文档产品规划过程产品目标文档单元测试文档程序代码测试后代码设计说明文档16案例：设计规格说明阶段•入口准则–由计划负责人和开发负责人决定是否在编码之前需要更详细的设计规格说明•出口准则–设计规格说明书通过批准•输入–与该模块相关的功能规格说明•输出–经批准的设计规格说明书–与所批准的设计规格说明书相关的配置项–评审文档的质量记录–批准文档的质量记录17案例：设计规格说明阶段•设计规格说明的评审者–固定评审人•计划负责人，开发负责人，功能测试负责人•相关组件的开发负责人（由计划负责人决定）•可用性测试代表（如果在功能规格说明或用户接口文档中缺少附加的外部接口细节）–可选评审人•开发团队人员•系统测试和性能测试人员，文档编写人员，可用性测试人员•设计规格说明的批准者–开发负责人18案例：设计规格说明阶段•流程–设计负责人决定所建设计规格说明书的数量和范围–设计规格说明负责人参考模板创建文档–将设计规格说明书发布在配置库中–评审文档–开发负责人批准所有的设计规格说明书19案例：编码与单元测试子流程•入口准则–已经获得功能规格说明和设计规格说明•出口准则–体系结构文档–代码已编写并准备进行构建•输入–软件开发文档–软件设计文档•输出–代码–单元测试检查单20案例：编码与单元测试子流程•代码审查者–由代码审查过程指导手册中指定人员•编码与单元测试过程–基于编码指南编写程序代码–对所编写代码进行单元测试–执行代码审查–将代码登入配置管理系统•输出文档–代码审查结果–编码与单元测试过程检查单21讨论：课程实验项目的软件过程项目规划需求分析软件开发软件测试项目收尾软件维护软件原型迭代开发1迭代开发2集成测试软件交付项目开始软件需求规格说明软件设计说明软件代码软件测试文档可交付的软件项目结束需求阶段稳定阶段迭代项目里程碑开发阶段22内容提纲•软件过程–基本概念–基本活动：需求工程、软件开发、测试和演化•软件过程模型–瀑布模型–快速原型模型–增量模型–螺旋模型–形式化方法模型–基于组件的开发模型•案例：微软公司软件开发过程模型Youarehere!你在这儿！23软件过程模型•软件过程模型–软件过程模型是对实际过程的抽象描述–包括软件过程的活动、软件产品以及参与人员的不同角色•常见的软件过程模型–瀑布模型–快速原型模型–增量模型–螺旋模型–形式化方法模型–基于组件的开发模型24瀑布模型•开发阶段严格按照线性方式进行•每一个阶段具有相关的里程碑和交付产品•每一个阶段需要确认和验证•强调文档的作用需求定义与分析需求定义与分析软件设计软件设计软件实现软件实现软件测试软件测试软件运行与维护软件运行与维护25瀑布模型•适用–在开发的早期阶段软件需求被完整确定•挑战–实际的项目开发很少是线性的过程，客户很难明确地描述软件需求•缺点–各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量–开发过程中很难响应客户的变更要求–早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果26快速原型模型•快速原型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识。需求分析原型开发原型评价昀终系统设计昀终系统实现用户反馈27快速原型模型•目的–减少开发风险和需求不确定性•缺点–原型系统的内部结构可能不好–开发人员需要掌握建立快速原型的开发技术和工具•适用–小型或中等规模的交互式系统–大型系统的某些部分，例如用户界面–生命周期较短的系统28增量模型定义框架需求定义框架需求分析分析设计设计编码编码测试测试交付交付增量1（核心产品）增量2增量n分析分析设计设计编码编码测试测试交付交付分析分析设计设计编码编码测试测试交付交付设计体系结构设计体系结构昀终软件系统昀终软件系统29增量模型•优点–整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本–将早期增量作为原型有助于明确后期增量的需求–降低开发风险–重要功能被首先交付，从而使其得到昀多的测试•缺点–需要软件具备开放式的体系结构–需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难–容易退化为边做边改方式，使软件过程的控制失去整体性30螺旋模型风险分析风险分析原型1操作原型评审操作的概念需求规划和生命周期规划开发计划集成和测试计划仿真、模型、基准测试产品设计详细设计软件需求需求确认设计确认与验证编程单元测试集成测试验收测试运行规划下一阶段确定目标、可选方案和约束预估可选方案、明确并解决风险开发和检验下一产品风险分析风险分析原型2原型331螺旋模型•螺旋回线–每一个回线表示开发过程的一个阶段–例如昀中心的第一个回线可能与系统可行性有关，接着第二个回线与需求定义有关，第三个回线与软件设计有关等•四个步骤–确定该阶段目标、完成这些目标的可选方案及其约束条件–从风险角度分析方案的开发策略，努力排除各种潜在的风险，在需求不适当的情况下可能需要建造原型系统–软件开发和验证工作–评价该阶段的结果，并规划下一个开发阶段32螺旋模型•优点–关注软件的重用–关注早期错误的消除–将质量目标放在首位–将开发阶段与维护阶段结合在一起•缺点–契约开发通常需要事先指定过程模型和发布产品–需要风险评估的经验33形式化方法模型•形式化方法模型是采用形式化的数学方法将系统描述转换成可执行的程序。需求定义需求定义形式化描述形式化描述集成和系统测试集成和系统测试形式化转换1形式化转换1形式化转换2形式化转换2············形式化转换n形式化转换n34形式化方法模型•适用–特别适合于那些对安全性、可靠性和保密性要求极高的软件系统，这些系统需要在投入运行前进行验证•优点–由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性•缺点–开发人员需要具备一定技能并经过特殊训练–形式化描述和转换是一项费时费力的工作–现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述35基于组件的开发模型•基于组件的开发技术是使用可重用的组件或商业组件建立复杂的软件系统。需求定义需求定义组件分析组件分析需求修改需求修改面向复用的系统设计面向复用的系统设计开发和集成开发和集成系统验证系统验证组件库组件库组件选取组件更新36基于组件的开发模型•组件开发技术的两个重要因素–基于组件的软件体系结构–基于组件的开发过程•优点–充分体现软件复用的思想–实现快速交付软件•缺点–商业组件的修改受到限制，影响系统的演化37统一开发过程38统一开发过程ArchitecturebaselinedLifecycleArchitectureMilestoneScopeandBusinessCaseagreementLifecycleObjectiveMilestoneProductsufficientlymatureforcustomersInitialOperationalCapabilityMilestoneCustomeracceptanceorendoflifeProductReleaseInceptionInceptionElaborationElaborationConstructionConstructionTransitionTransitiontime39统一开发过程Low-EndMediumHigh-End40其他•基于开放源码的软件开发–Apache:World’smostpopularwebserver（）–Linux:World