软件工程基础之软件过程模型.ppt

第二章 软件过程模型,1,2,3,4,什么是软件过程？-解决问题的过程,问题定义,技术开发,方案集成,目标现状,什么是软件过程？,虽然过程是多种多样的，但所有过程都具有以下的共同活动,沟通,该活动包括软件设计者与客户沟通，客户提出要求，软件设计者收集材料，以及其它相关活动。,计划,软件开发小组讨论使用何种方法及何种工具来实现客户需求。,建模,在这一部分，软件开发小组讨论选择何种模型来满足需求。不同的需求需要不同的模型。,构造,部署,编码和测试。,软件交付给客户。客户给出建议和反馈，软件实施小组改进软件。,什么是软件过程？,贯穿始终的普适性活动：项目跟踪控制、风险管理、质量保证、配置管理、技术评审等,过程评估与改进,用于过程改进的 CMMI标准评估方法 提供了五步的过程评估模型：启动、诊断、建立、执行和学习。用于组织内部过程改进的CMM评估采用SEI的CMM作为评估的依据，提供了一种诊断方法，用以分析软件开发机构相对成熟度。SPICEThe SPICE(ISO/IEC15504)标准定义了软件过程评估的一系列要求。该标准的目的是帮助软件开发组织建立客观的评价体系，以评估定义的软件过程的有效性。软件ISO 9001:2000这是一个通用标准，任何开发组织如果希望提高所提供的产品、系统或服务的整体质量，都可以采用这个标准。因此，该标准可直接应用于软件组织和公司。,持续的过程改进,量化管理,4 量化管理级,过程标准化,3 已定义级,基本项目管理,有能力的人和个人英雄主义,2 可重复级,1 初始级,CMM,工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。,管理制度化，建立了基本的管理制度和规程，管理工作有章可循。初步实现标准化，开发工作比较好地按标准实施。变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。,开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解。,成熟度模型标准（CMM）,产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。,可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法,软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件过程模型也常称为：软件开发模型 软件生存周期模型 软件工程范型,软件过程模型,常用过程模型,瀑布模型(经典的生命周期模型)增量过程模型增量模型RAD模型演化过程模型原型模型螺旋模型喷泉模型其他过程模型,？常用过程模型提倡结构化和有序的软件工程方法，那么对于富于变化的软件世界，这一模型是否合适呢？如果抛弃传统过程模型（以及它们带来的秩序），取而代之以一些不够结构化的模型，是否会使如软件工作无法达到协调和一致？,1.瀑布模型(Waterfall Model),由Winston Royce 在1970年最早提出的软件开发模型。软件开发过程与软件生命周期是一致的，也称经典的生命周期模型。规定了各项软件工程活动，以及它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。是一种使用广泛，以文档为驱动的模型。,瀑布模型,带反馈的瀑布模型,瀑布模型的特点,阶段间具有顺序性和依赖性。推迟实现的观点。每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。,瀑布模型主要问题,线性过程太理想化各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。,怎么办？,增量过程模型(Incremental Model),增量模型是一种非整体开发的模型。是一种进化式的开发过程。它允许从部分需求定义出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善。如此反复进行，直至软件人员和用户对所设计的软件系统满意为止。增量模型RAD,增量模型,增量模型结合了原型模型的基本要素和迭代的特征，该模型采用基于时间的进展而交错的线性序列，每个确定线性序列都会输出该软件的一个“增量”。,增量模型特点,增量小而可用的软件特点在前面增量的基础上开发后面的增量每个增量的开发可用瀑布或快速原型模型迭代的思路,增量模型的优缺点,增量包概念的引入，以及它不需要提供完整的需求。只要有一个增量包出现，开发就可以进行。在项目的初始阶段不需要投入太多的人力资源。增量可以有效地管理技术风险。每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。,Advantages,Disadvantages,快速应用开发模型（RAD）,快速应用开发模型（RAD）是一个增量过程模型，强调短暂的开发周期。RAD 模型是瀑布模型的“高速”变体，通过基于构件的构建方法实现快速开发。如果需求以及项目范围得到明确界定，RAD 能使开发团队在很短的时间内（如60 到90 天）建立一个“全功能系统”。RAD不使用传统程序设计语言,而是基于构件技术,复用已有的程序结构,或使用可复用构件,或创建可复用构件进行。如果一个业务可被模块化并使每个主要功能均可在3月内完成，则RAD是一个候选，每一个主要功能由一个单独的RAD组完成，并最后集成起来成为一个整体。,演化模型,演化过程模型原型模型螺旋模型演化模型的思想是首先实现软件的最核心的、最重要的功能,原型模型,通过总体目标或已确认需求，实现一个可实际运行的系统初步模型，供开发人员和用户进行交流和评审，以便较准确获得用户的需求，然后采用逐步求精方法使原型逐步完善。客户给出一些基本功能描述，但是没有详细定义功能和特性需求；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时，原型法是很好的选择。,原型模型,原型模型的优缺点,优点：开发效率高，原型使总的开发费用降低，时间缩短，开发者与用户交流直观，可以澄清模糊需求，调动用户的积极性，能及早地暴露系统实施后潜在的一些问题。缺点：产品原型在一定程度上限制了开发人员的创新，没有考虑软件的整体质量和可维护性，由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计，相关利益者不会意识到质量问题，而使开发管理陷入失效。设计者在质量和原型间有所折衷，会采用熟悉的工具和环境、低效的算法，一旦适应后，忘记初衷，造成质量问题。,螺旋模型（Spiral Model）,螺旋模型最早由Boehm 在Boehm1998中提出，与RAD 模型相似，该模型结合了瀑布模型和原型模型的特点。螺旋模型强调风险管理，因此该模型适用于大型系统的开发。,螺旋模型（Spiral Model）,四个象限上分别表达四个方面的活动,螺旋模型沿着螺线旋转，在笛卡尔坐标的四个象限上分别表达了四个方面的活动：制定计划。确定软件目标，选定实施方案，弄清项目开发的限制条件。风险分析。分析所选方案，考虑如何识别和消除风险。设计实施。设计、编码、测试、优化。用户反馈。评价开发工作，提出修正建议。,螺旋模型的优点,支持用户需求的动态变化。原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。引入一个非常严格的风险识别，风险分析和风险控制，它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。,螺旋模型的缺点和适应场合,如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。,缺点,适应场合,喷泉模型(Fountain Model),喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。具有自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。,喷泉模型的优缺点,喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。,优点,缺点,如何选择过程模型？,软件开发模型是不断发展的各种软件开发模型各有优缺点选用时不必拘泥与某种模型可组合多种模型也可根据实际创建新的模型,参考原则,1.在前期需求明确的情况下，尽量采用瀑布模型或改进的瀑布模型。2.在用户无系统使用经验，需求分析人员技能不足情况下一定要借助原型。3.在不确定因素很多，很多东西前面无法计划的情况下尽量采用增量迭代和螺旋模型。4.在需求不稳定的情况下尽量采用增量迭代模型。5.在资金和成本无法一次到位的情况下可采用增量模型，软件产品多个版本进行发布。6.对于完成多个独立功能开发可以在需求分析阶段就进行功能并行，但每个功能内部都应该遵循瀑布模型。7.对于全新系统的开发必须在总体设计完成后再开始增量或并行。8.对于编码人员经验较少的情况下建议不要采用敏捷或迭代等生命周期模型。9.增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则。10.UP适用于面向对象项目。11.敏捷开发适合高开发效率和响应能力需求的项目。,以产品为中心,过程 B,产品,过程 C,过程 A,需求,Focus,产品,产品,过程和产品,过程很薄弱，最终产品必将受到影响过分依赖过程，也是非常危险的,以过程为中心,小结,软件生命周期-软件过程-软件过程模型过程定义了谁在做什么，何时以及如何达到一定的目标。常见的过程模型：瀑布、增量、原型、螺旋软件过程决定了软件产品的质量，不同的项目需要不同的过程模型或者过程模型的组合,过程模型工具,Igrafx process tools,流程分析仿真Objexis Team Portal,协同策略管理,软件工程知识,经常听人们说，软件开发知识的半衰期为3年：现在你需要知道的那些知识，在三年内会有一半将过时。在技术相关的知识领域内，这种说法可能是正确的。但还有另一种软件开发知识一种我认为是“软件工程原则”并没有3年半衰期的说法。这些软件工程原则可以为专业程序设计人员在其整个职业生涯内提供服务。,Steve McConnell,指导过程的原则,原则1：敏捷。你所选择的过程模型是否是传统的或敏捷的，敏捷开发的基本原则会提供给你判断的方法。原则2：每一步都关注质量。每个过程活动、动作及任务的出口条件应关注生产的工作产品质量。原则3：做好适应准备。过程不是信仰体验，其中没有信条。当需要的时候，就让你的方法适应于由问题、人员以及项目本身施加的限制。原则4：建立一个有效团队。软件工程过程和实践是重要的，但最根本的还是人。必须建立一个彼此信任和尊重的自组织团队。,指导过程的原则,原则5：建立沟通和协调机制。项目失败是由于遗漏重要信息，以及（或者）利益相关者未能尽力去创造一个成功的最终产品。原则6：管理变更。管理变更的方法可以是正式的或非正式的，但是必须建立一种机制，来管理变更要求的提出、变更的评估、变更的批准以及变更实施的方式。原则7：评估风险。在进行软件开发时，会做错很多事。建立应变计划是非常重要的。原则8：创造能给别人带来价值的工作产品。仅仅创建那些能为其他过程活动、动作或任务提供价值的工作产品。,指导实践的原则,原则1：分治策略。更具技术性的表达方式，分析和设计中应经常强调关切问题分解(SoC)。原则2：理解抽象的使用。在这一核心原则中，抽象就是对一个系统中一些复杂元素的简单化，用以传达词组的含义。原则3：力求一致性。一个熟悉的环境使软件更易于使用。原则4：关注信息传递。特别注意界面分析、设计、构建以及测试。,指导实践的原则,原则5：构建能展示有效模块化的软件。对重要事务的分割（原则1）建立了软件的哲学。模块化提供了认知这一哲学的机制。原则6：寻找模式。Brad Appleton App00指出：软件界内模式的目标是建立一个典型集，帮助软件开发者解决整个软件开发过程中反复出现的问题。原则7：在可能的时候，用大量不同的观点描述问题及其解决方法。原则8：记住：有人将要对软件进行维护。,沟通原则,原则1：倾听。一定要仔细倾听讲话者的每一句话，而不是急于叙述你对这些话的看法。原则2：有准备的沟通。在与其他人碰面之前花点时间去理解问题。原则3：沟通活动需要有人推动。每个沟通会议都应该有一个主持人（推动者），其作用是：（1）保持会议向着有效的方向进行；（2）能调解会议中所发生的冲突；（3）能确保遵循我们所说的沟通原则。原则4：最好当面沟通。但是，当能把一些相关信息呈现出来时，通常可以工作得更好。,沟通原则,原则5：记笔记并且记录所有决定。参与交流的人应充当“录音机”，并记录所有要点和决定。原则6：力求协作。当团队成员的想法需要汇集在一起用以阐述一个产品或者某个系统的功能或特征的时候，就产生了协作和协调的问题。原则7：把讨论集中在限定范围内。在任何交流中，参与的人越多，话题转移到其他地方的可能性就越大。原则8：如果某些东西很难表述清楚，采用图形表示。原则9：（a）一旦认可某件事情，转移话题；（b）如果不认可某件事情，转移话题；（c）如果某项特性或者功能不清晰，当时无法澄清，转移话题。原则10：协商不是一场竞赛或者一个游戏，协商双赢时才发挥了协商的最大价值。,决策原则,原则1：理解项目范围。如果你不知道要去哪里，就不可能使用路线图。范围可以为软件开发团队提供一个目的地。原则2：使利益相关者参与决策活动。利益相关者确定优先事项，确定项目的约束。原则3：要认识到计划的制定应按照迭代方式进行。项目计划不可能一成不变。在工作开始的时候，有很多事情有可能改变。原则4：基于已知的估计。估计的目的是基于团队将要完成工作的当前理解，提供一种关于工作量、成本和任务工期的指标。,决策原则,原则5：计划时考虑风险。如果团队已经明确了哪些风险最容易发生且影响最大，那么应急计划就是必需的了。原则6：保持脚踏实地。人们不可能每天每时每刻都工作。原则7：调整计划粒度。粒度主要指制定项目计划细节的精细程度。原则8：制定计划确保质量。计划应该确定软件开发团队如何去确保开发的质量。原则9：描述如何适应变化。即使最好的策划也有可能被无法控制的变化破坏。原则10：经常跟踪并根据需要调整计划。软件项目一次会落后进度一天的时间。,建模原则,在软件工程中，要创建两类模型：需求模型(也称分析模型)通过在以下三个不同域描述软件来表达客户的需求：信息域、功能域和行为域。设计模型表述了可以帮助开发者高效开发软件的特征：架构、用户界面以及构件细节。,需求建模原则,原则1：必须描述并理解问题的信息域。原则2：必须确定软件所要实现的功能。原则3：必须描述软件的行为（作为外部事件的结果）原则4：描述信息、功能和行为的模型必须以一种能揭示分层（或者分级）细节的方式分解开来。原则5：分析任务应该从本质信息转向实现细节。,设计建模原则,原则1：设计可追溯到需求模型。原则2：要始终关注待建系统的架构。原则3：数据设计与功能设计同等重要。原则4：必须精心设计接口。原则5：用户界面设计必须符合最终用户要求。但是，在任何情况下，界面的设计都强调使用的方便性。原则6：构件级设计应是功能独立的。原则7：构件之间以及构件与外部环境之间松散耦合。原则8：设计表述（模型）应该做到尽可能易于理解。原则9：设计应该迭代进行。每一次迭代，设计者都应该力求简洁。,敏捷建模原则,原则1：软件团队的主要目标是构建软件而不是创建模型。原则2：轻装前进不要创建任何你不需要的模型。原则3：尽量创建能描述问题和软件的最简单模型。原则4：用能适应模型改变的方式构建模型。原则5：明确描述创建每一个模型的目的。原则6：调整所开发模型来适应待开发系统。原则7：尽量构建有用的模型而不是完美的模型。原则8：对于模型的构造方法不要过于死板。如果模型能成功地传递信息，那么表述形式是次要的。原则9：如果直觉告诉你模型不正确，尽管看上去正确，那么你要仔细注意了。原则10：尽可能快地获得反馈。,构造原则,构造活动包括一系列编码和测试任务，从而为客户和最终用户交付可运行软件做好准备。编码原则和概念与编程风格、编程语言和编程方法紧密结合。测试原则和概念导致设计一些能用最短的时间、最少的工作量来系统地揭示不同类型错误的测试,准备原则,在写下每行代码之前，要确保：理解所要解决的问题。理解基本的设计原则和概念。选择一种能够满足构建软件以及运行环境要求的编程语言。选择一种能提供工具以简化工作的编程环境。构件级编码完成后创建一组单元测试。,编码原则,在开始编码时，要确保：遵循结构化编程方法来约束算法Boh00.考虑使用结对编程。选择能满足设计要求的数据结构。理解软件架构并开发出与其相符的接口。尽可能保持条件逻辑简单。开发的嵌套循环应使其易于测试。选择有意义的变量名并符合相关编码标准。编写注释，使代码具有自说明性。创建可视化布局帮助理解代码（例如：缩进和空行）,确认原则,在完成第一阶段的编码之后，要确保：适当进行代码走查。进行单元测试并改正所发现的错误。重构代码。,测试原则,Al Davis 提出下面的原则：原则1：所有的测试都应该可以追溯到用户需求。原则2：测试计划应该远在测试之前就开始着手。原则3：将Pareto原则应用于软件测试。原则4：测试应该从“微观”开始，逐步转向“宏观”。原则5：穷举测试是不可能的。,关于Pareto法则,Pareto principle 即帕累托法则。帕累托法则又称80/20法则、马特莱法则、二八定律、帕累托定律、最省力法则、不平衡原则、犹太法则此法则是由意大利经济学家帕累托提出的。80/20的法则认为：原因和结果、投入和产出、努力和报酬之间本来存在着无法解释的不平衡。一般来说，投入和努力可以分为两种不同的类型 多数，它们只能造成少许的影响；少数，它们造成主要的、重大的影响。,作业,1.试比较分析瀑布模型、增量模型、原型模型和螺旋模型的联系和区别。2.根据你的理解，分别举出使用了瀑布模型、原型模型和增量模型的软件项目的例子。3.查找最新的CMMI资料，试回答：什么是KPA？CMMI共包含多少KPA？,