搜索
3软件工程的过程模型前次课内容回顾：软件工程的核心概念与思想•软件工程的本质•不同抽象层次之间的映射与转换•软件工程所关注的目标•产品、过程•功能性需求、非功能性需求•软件开发中的多角色•“软件工程”的背后•科学、管理与工程•系统、软件系统•软件工程=最佳实践•软件工程的核心理论概念•复用、分治、折中•软件工程的学习方法•实践、实践、再实践3软件工程的过程模型主要内容•3.1软件过程•3.2典型软件过程模型•瀑布模型•增量过程模型•增量模型•快速应用程序开发(RAD)•演化过程模型•螺旋模型•原型模型•3.3各类过程模型的对比•开放源码过程•统一过程模型(RUP)•其他过程模型•形式化过程•软件复用过程第二章软件开发过程管理3.1软件过程3软件工程的过程模型3.1.1软件过程•软件过程：用来开发软件系统所需要的一组结构化的活动；•例如：•需求分析•设计•实现•度量与验证•部署与实施•演化与维护3软件工程的过程模型3.1.1软件过程•软件过程定义以下内容：•人员与分工•所执行的活动•活动的细节和步骤•软件过程通过以下方式组织和管理软件生命周期：•定义软件生产过程中的活动•定义这些活动的顺序及其关系•软件过程的目的：•标准化、可预见性、开发效率、高质量产品•制定时间和预算计划的能力3软件工程的过程模型…构造一所房子…相同的生命周期不同的活动3软件工程的过程模型3.1.2黑盒过程与白盒过程•存在的问题：•要求开发之前需求被充分理解•与客户的交互只在开始(需求)和最后(发布)•而实际情况完全不是这样ProductProcessInformalRequirements3软件工程的过程模型3.1.2黑盒过程与白盒过程•优点：•通过改进可见性来减少风险•在开发过程中，通过不断地获得顾客的回馈允许变更ProductProcessInformalRequirementsfeedback3软件工程的过程模型3.1.3软件过程中的每一个步骤•Entrycriteria(入口标准)：满足何种条件可以开始？•Repeatabletasks(任务)：要做什么事情？•Validation(验证)：如何得知得到了预期的结果？•Exitcriteria(出口标准)：是否已经结束？输出入口标准任务验证过程输入出口标准3软件工程的过程模型[课堂讨论1]•[课堂讨论1]每四人一组，通过讨论来回答。•背景：任选一项你的日常活动，如“中午去食堂吃饭”；•问题：分析其入口标准、任务、验证和出口标准；•时间：2分钟•随机选择三组，每组选择一名代表口头陈述本组的讨论结果3软件工程的过程模型3.1.4软件过程的典型阶段•Dream(提出设想)•Investigation(深入调研)•SoftwareSpecification(软件规格说明)•SoftwareDesign(软件设计)•SoftwareImplementation(软件实现)•SoftwareValidation(软件验证)•SoftwareEvolution(软件演进)3软件工程的过程模型(1)提出设想•Inputs：现实中存在的且未解决的问题；•Entrycriteria：无•Tasks：思考•通过头脑风暴发现新想法；•这些想法在技术上可行吗？•这些想法能够赚钱吗？•Validation：与同事、朋友讨论；•Exitcriteria：•是否有足够的自信来说服决策者？•是否有足够的自信来获得启动资金？•Output：•一项新技术/新的市场机会3软件工程的过程模型(2)深入调研•Inputs：一项新技术/新的市场机遇•Entrycriteria：决策者同意、你获得相应的资金；•Tasks：技术•对关键技术问题加以证实；•对关键市场问题加以调研：有多少潜在客户？预计年收益有多大？•Validation：•工程师能够按你的技术方案进行实际生产或开发；•通过调查发现市场机会足够大；•Exitcriteria：•准备将方案提交工程部门；•准备启动产品开发的新项目或构建新公司；•Output：原型或商业计划3软件工程的过程模型[课堂讨论2]•[课堂讨论2]每四人一组，通过讨论来回答。•背景：你们所在的是一家旅游公司，但近一年来市场业绩逐渐下滑，公司CEO急需你想出一些好点子来挽救市场份额。•问题：发挥创造力，构想某项新业务，并说服CEO接受你的idea。•时间：5分钟•随机选择三组，每组选择一名代表口头陈述本组的讨论结果3软件工程的过程模型(3)软件规格说明•Inputs：目标客户或市场•Entrycriteria：批准市场调研，并拥有市场资源•Tasks：•调查和分析市场需求•调查和分析客户需求•Validation：•听取行业专家和客户的反馈•最好和客户一起评价系统原型•Exitcriteria：•需求集合•Output：软件需求规格说明书3软件工程的过程模型(4)软件规格说明•软件规格说明的任务是定义所开发系统的具体内容(功能)及其相关约束(性能、开发环境、运行环境等)需求管理需求获取需求分析规格说明需求验证会议纪要讨论纪要会议纪要讨论纪要分析模型分析模型需求规格说明书需求规格说明书审核通过的规格说明书审核通过的规格说明书活动产出物3软件工程的过程模型(5)软件设计•Inputs:需求规格说明书•Tasks:•将市场或客户需求转换成软件需求•设计软件的体系结构•Validation:•设计评审•原型•UML模型•Exitcriteria:•已验证的切实可行的体系结构•应开发的主要功能•Output:设计规格说明书3软件工程的过程模型(5)软件设计•软件设计阶段的活动•体系结构设计－构件设计•抽象模型－数据结构设计•接口设计－算法设计需求规格说明书需求规格说明书体系结构设计体系结构设计抽象规格设计抽象规格设计接口设计接口设计构件设计构件设计数据结构设计数据结构设计算法设计算法设计系统体系结构规格说明书系统体系结构规格说明书系统规格说明书系统规格说明书接口规格说明书接口规格说明书构件规格说明书构件规格说明书数据结构规格说明书数据结构规格说明书算法规格说明书算法规格说明书活动产出物3软件工程的过程模型(6)软件实现•Inputs：设计规格说明书•Tasks：•将体系结构中的各模块细化成可管理的、有进度要求的编程任务•编程实现这些模块•单元测试•Validation：•代码审查•单元测试用例•Exitcriteria：•所有设计说明变成程序•完成单元测试•Output：经过单元测试的源程序3软件工程的过程模型(7)软件验证•确认和验证(V&V，VerificationandValidation)的目的是证明所开发的系统符合规格说明，并满足客户的需求。•包括所有检查、评审和测试需求规格需求规格系统设计规格系统设计规格系统设计系统设计详细设计详细设计模块代码与测试模块代码与测试子系统集成测试子系统集成测试系统集成测试系统集成测试可接受性测试可接受性测试服务服务可接受性测试计划可接受性测试计划系统集成测试计划系统集成测试计划子系统集成测试计划子系统集成测试计划3软件工程的过程模型(8)软件演化•当需求随着商业环境的变化发生变化时，软件必须进行改进和变化；•维护必须在软件开发一开始就进行考虑和计划；•文档非常重要，在维护时会发现文档常常过时或根本没有。评估当前系统设计系统变更方案修改系统新系统当前系统定义系统需求3软件工程的过程模型例子：IBM软件过程模型发布管理过程CommittedPIwithassignedPIownerDevelopmentProcessDesignSub-ProcessCUTSub-Process分析设计阶段功能规格说明设计规格说明功能测试过程编码阶段单元测试阶段代码评审阶段CodereadyForFTA&ODocFSDS产品计划过程ProductObjectivesDocumentUnittestsCodeUnittestedCode3软件工程的过程模型例子：软件开发生命周期模型SDLC定义问题确认可行性制定进度表制定人员表计划阶段分析阶段设计阶段实现阶段支持阶段需求调查需求分析需求建模需求验证需求管理体系结构设计界面设计数据设计内部设计接口设计编码测试培训计划系统部署系统维护第二章软件开发过程管理3.2典型的软件过程模型3软件工程的过程模型典型的软件过程模型•瀑布模型(waterfallmodel)•增量过程模型(incrementalprocessmodel)•增量模型(incrementalmodel)•快速应用程序开发(RapidApp.Dev.,RAD)•演化过程模型(evolutionarymodel)•螺旋模型(spiralmodel)•原型模型(iterativemodel)•开放源码过程(opensource)•统一过程模型(RationalUnifiedProcess,RUP)•其他过程模型(othermodels)•形式化过程(formalmethodmodel)•软件复用过程(component-basedreuse)3软件工程的过程模型3.2.1瀑布模型计划运行维护定义阶段开发阶段运行、维护阶段需求分析设计编码测试•上一个阶段结束，下一个阶段才能开始；•每个阶段均有里程碑和提交物；•每个阶段均需要进行V&V；•侧重于文档与产出物；3软件工程的过程模型3.2.1瀑布模型•优点：•简单、易懂、易用；•每个阶段必须提供文档，而且要求每个阶段的所有产品必须由SQA小组仔细验证。•缺点：•在开发早期，用户难以清楚地确定所有需求，需求的错误很难在开发后期纠正，因此难以快速响应用户需求变更；•这种模型几乎完全依赖规格说明文档，而客户无法理解和阅读这些文档，容易导致不能满足客户需求。•客户必须在项目接近尾声的时候才能得到可执行的程序，对系统中存在的重大缺陷，如果在评审之前没有被发现，将可能会造成重大损失。3软件工程的过程模型3.2.1瀑布模型•瀑布模型太理想化，太单纯，已不再适合现代的软件开发模式，在大型系统开发中已经很少使用；•但是，“线性”是最容易掌握并能熟练应用的思想方法。3软件工程的过程模型3.2.2增量过程模型•在很多情况下，由于初始需求的不明确，开发过程不宜采用瀑布模型；•另外，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再细化和扩展功能。•在这种情况下，需要选用增量方式的软件过程模型。•两种典型形态：•增量模型•RAD模型3软件工程的过程模型(1)增量模型第1个增量交付第1个增量第2个增量交付第2个增量第n个增量交付第n个增量沟通策划建模(分析、设计)构建(编码、测试)部署(交付、反馈)软件功能和特征项目时间3软件工程的过程模型(1)增量模型•软件被作为一系列的增量来设计、实现、集成和测试，每一个增量是由多种相互作用的模块所形成的提供功能的代码片段构成。•本质：以迭代的方式运用瀑布模型•第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性；•客户使用上一个增量的提交物并进行自己评价，制定下一个增量计划，说明需要增加的特性和功能；•重复上述过程，直到最终产品产生为止。3软件工程的过程模型(1)增量模型•优点：•增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品；•如果找不到足够的开发人员，可采用增量模型：早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力；•可以规避技术风险。•困难：•每个附加的构件在并入现有的软件体系结构时，必须不破坏原来已构造好的东西。3软件工程的过程模型(2)RAD模型建模业务建模数据建模流程建模建模业务建模数据建模流程建模构建构件复用代码自动生成测试构建构件复用代码自动生成测试建模业务建模数据建模流程建模建模业务建模数据建模流程建模构建构件复用代码自动生成测试构建构件复用代码自动生成测试建模业务建模数据建模流程建模建模业务建模数据建模流程建模构建构件复用代码自动生成测试构建构件复用代码自动生成测试Team#1Team#2Team#n部署集成交付反馈部