1、第2章 软件过程,软件工程_一种层次化技术软件过程框架软件能力成熟度(CMM)软件过程模型,当开发产品或构建系统时，遵循一系列可预测的步骤即路线图是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图就称为“软件过程”。,软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。但是，现代软件工程方法必须是“灵活”的。也就是要求软件工程活动、控制以及文档的编制适合于项目团队和要开发的产品。,软件工程_一种层次化的技术,软件工程是一种层次化的技术。任何工程方法(包括软件工程)必须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的
2、过程改进，正是这种改进导致了更加成熟的软件工程方法的不断出现。支持软件工程的根基就在于对质量的关注。,软件工程层次图,Software engineering layers,软件工程的基层是过程层。软件工程过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 软件工程过程是将技术层结合在一起的凝聚力，使得计算机软件能够被合理地和及时地开发出来。 关键过程区域构成了软件项目的管理控制的基础，并且确立了上下各区域之间的关系，其中规定了技术方法的采用、工程产品(模型、文档、数据、报告、表格等)的产生、里程碑的建立、质量的保证及变化的适当管理。,软件工程的方法层为建造
3、软件提供技术上的解决方法（“如何做”）。方法覆盖面很广，包括沟通、需求分析、设计建模、编程、测试和支持。软件工程方法依赖于一组基本原则，这些原则涵盖了软件工程包括建模和其它技术等在内的所有技术领域。,软件工程的工具层为过程和方法提供自动化或半自动化的支持。这些工具可以集成起来，使得一个工具产生的信息可被另外一个工具使用，这样就建立了软件开发的支撑系统，称为计算机辅助软件工程。,软件过程框架,一个公共过程框架，是通过定义若干框架活动来建立的，如果不考虑其规模和复杂性，这些活动适用于所有软件项目。若干任务集合每一个集合都由软件工程工作任务、项目里程碑、软件工程产品和交付物以及质量保证点组成使得框架
4、活动适应于不同软件项目的特征和项目组的需求。最后是保护性活动如软件质量保证，软件配置管理和测度，它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程。,五个最基本的过程框架活动,沟通 这个框架活动包含了与客户之间大量的交流和协作，还包括需求获取以及其他相关活动。计划 指为后续的软件工程工作制定计划。它描述了需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。建模 它包括创建模型和设计两方面。创建模型有助于客户和开发人员更好地理解软件需求；设计可以实现需求。构建 它包括编码（手写的或者自动生成的）和测试以发现编码中的错误。部署 软件（全部或者完成的部分）交
5、付到用户，用户对其进行评测并给出反馈意见。,典型的保护性活动：,软件项目跟踪和控制 允许项目组根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。风险管理 评估可能对项目成果或者产品质量产生影响的风险。软件质量保证 确定和执行用以保证软件质量的活动。正式技术评审 评估软件工程产品，尽量在错误传播到下一个动作或活动之前，发现并清除错误。,测量 定义和收集过程、项目和产品的度量，以帮助团队在发布软件的时候满足客户要求。同时，测量还可与其它框架和总括活动协同使用。软件配置管理 管理整个软件过程中变更所带来的影响。可复用管理 定义产品复用的标准（包括软件构件），并且建立构件复用机制。工作
6、产品的准备和生产 包括了创建产品所必须的活动如建模、文档、日志、表格和列表等。,软件过程成熟度模型,软件过程成熟度模型也称软件能力成熟度模型（Capability Maturity Model），它并不是一个软件生命周期模型，而是改进软件过程的一种策略。近20年来，很多人试图通过采用新的软件开发技术来解决在软件生产率和软件质量等方面存在的问题，但效果并不十分令人满意。这一现象促使人们进一步考察软件过程，从而发现对软件过程的管理不尽人意。事实表明，在无规则和混乱的管理之下，先进的技术和工具并不能发挥应有的作用。,1987年，CMU（美国卡内基梅隆大学）的SEI（软件工程研究所）发表了一个简短的软
7、件过程成熟度框架，其后在Humphrey管理软件过程一书中进行了扩充。书中提出了两种方法：一种是软件过程评估和软件能力评价，另一种是成熟度问卷，用于评价软件过程的成熟度。 1991年发布CMM1.0版本; 1993年发布CMM1.1版本。 1997年SEI开始研究CMMI，其任务是将已有的CMM模型结合成一个模型。 2001年12月发布CMMI1.1版本。,不成熟过程与成熟过程的对比角色与职责处理变更的方式对发生问题的反映可靠性对工作人员的奖励预见性,CMM将软件过程的成熟度分为5个等级，每一个成熟程度级别由几个关键过程区域组成，较为全面地描述和分析软件过程能力的发展程度，一个软件开发组织可采
8、用一系列改良步骤向更高的成熟度等级迈进。,这五个级别主要特征为：(1) 初始级。软件过程的特点是杂乱无章，有时甚至混乱，几乎没有明确定义的步骤，成功完全依赖于个人的能力和行为。(2) 可重复级。建立了基本的项目管理过程来跟踪成本、进度和功能。建立了必要的过程规范，使得可以重复以前类似项目所取得的成功。(3) 确定级。用于管理和工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件开发过程中。所有项目都使用文档化的、组织批准的过程来开发和维护软件。(4) 管理级。制定了软件过程和产品质量的详细的度量标准。软件过程和产品的质量都被开发组织的成员所理解和控制。(5) 优化级。加强了定量分
9、析，通过来自过程质量反馈和来自新观念、新科技的反馈使过程能不断持续地改进。,软件过程能力成熟度等级,每个成熟级别的可视性,初始级的可视性,对管理员或用户而言，只能看到项目的要求和项目的结果，整个软件过程是一个黑箱，无法看到项目的软件过程。当然无法确定开发活动的阶段。项目开发如同黑色魔术，处于一种不可控方式下进行。管理者不了解软件，要想了解某个具体项目的进度状况，或制定项目计划都是非常困难的。用户只有在软件交付时，才能评估软件产品是否符合需求。,可重复级的可视性,开发过程好像一系列的黑盒子。可以按阶段来进行软件开发的控制和管理。这种管理控制允许在某些定义的时段（里程碑）上，可使项目活动情况可视。
10、但在黑盒内部发生的事，仍然看不见。 因此，用户的需求和工作产品只在一定程度上可以控制。这时候可以建立基本的项目管理活动，在过程的检查点上对产品进行检查，以考察过程是否正常进行，或对发生的问题作出反应。用户也可在检查点上了解项目的进展。,确定级的可视性,可以看到盒子中的内部结构，例如项目所定义的软件过程的任务。 这种内部结构表示了软件开发组织已有的标准软件过程正应用于特定的项目时的情况。因此，管理人员在理解自己在过程中的责任和任务情况下，在一定程度上能和各种软件开发活动进行交互。 管理人员并能预见可能发生的风险，为此作一定准备。 用户能得到较为准确而快速的状态报告。,管理级的可视性,在这一级可以
11、定量地指导和控制所定义的软件过程。 管理者可以根据客观的度量，预见过程中的经费支出和其他情况。定量地、有目标地做出决定。 当软件过程的不稳定性减少时，预见结果的能力也增大，变为更精确。 用户能定量地理解过程的能力及存在的风险。,优化级的可视性,为了提高生产率和质量，从组织上已经有控制地、不断地、系统地尝试新的改进方法。“制度变动”成为一种生活方式。 对现存的过程的认识超越了仅仅考虑过程可能变化的影响，而是自觉地识别不够有效和可能出错的活动，并将以改正和替换，以达到更进一步的效果。工作成就的标准不再是达到里程碑的要求，而是减少错误率。 管理人员可以有能力来估计及定量跟踪变化的影响和效果。 用户和
12、开发组织合作关系良好。,软件过程评估。是用来判断一个组织当前的软件过程的能力状态，判断一个组织所面对的更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对该组织的软件过程进行有效的改进。软件能力评价。是用来判断有意承担某个软件项目的软件组织（也就是投标者）的软件过程能力，或是判断已进行的软件过程 所处的状态是否正确或是否正常。,CMM的应用,软件过程评估和软件能力评价的步骤,软件过程模型体现的是开发策略，并覆盖过程、方法和工具三个层次。典型的软件过程模型：瀑布模型（线性顺序模型）原型实现模型RAD模型增量模型螺旋模型,软件过程模型,基于构件的开发形式化方法模型面向方面的软件开发统一过程
13、,瀑布模型,瀑布模型的特点,阶段间具有顺序性和依赖性两重含义：（1）必须等前一阶段的工作完成之后，才能开始后一阶段的工作；（2）前一阶段的输出文档就是后一阶段的输入文档。,推迟实现的观点瀑布模型在编码之前设置了系统分析和系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。,质量保证的观点每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。,实际的
14、瀑布模型是带“反馈环”的， 当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。,实际的瀑布模型,瀑布模型的优点,可强迫开发人员采用规范化的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。,瀑布模型的缺点,由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。,原型实现模型(快速原型模型),所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。,听取用户意见,建造/修改原型,
15、用户测试运行原型,原型实现模型,快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用。一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。,原型实现模型的优点,有助于满足用户的真实需求原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。,因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现
16、规格说明文档的错误而进行较大的返工。开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。,快速应用开发()模型,是一个线性顺序的软件开发模型，强调极短的开发周期。通过使用基于构件的建造方法获得快速开发主要用于信息系统应用软件的开发。,RAD模型,增量模型,增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。,增量模型,增
17、量模型的优点,能在较短时间内向用户提交可完成一些有用的工作的产品，即从第一个构件交付之日起，用户就能做一些有用的工作。逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。,增量模型的困难,在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。,传统的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计的工作。由于在开始构建第一个构件之前已经有了总体设计，
18、因此风险较小。 在实际操作中，为了加快工程进度，常采用一种风险更大的增量模型，即不同构件将并行的构件。如图2.5所示。使用这种方法将冒构件无法集成到一起的风险，因此在整个开发过程中，需要密切的监控，否则整个工程可能毁于一旦。,风险更大的增量模型,螺旋模型,软件开发几乎总要冒一定风险，因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。,螺旋模型,螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划确
19、定软件目标，选定实施方案，弄清项目开发的限制条件风险分析分析所选方案，考虑如何识别和消除风险实施工程实施软件开发客户评估评价开发工作，提出修正建议,螺旋模型的优点,对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险；在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别.,螺旋模型的缺点,螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。,基于构件的开发,基于构件开发模型具有许多螺旋模型
20、的特点，需要以迭代方式构建软件。不同之处在于，基于构件开发模型采用预先打包的软件构件开发程序。建模和构建活动开始于识别可选构件。这些构件有些设计成通用的软件模块,有些设计成面向对象的类或软件包。,基于构件开发模型由以下步骤组成：对于该问题领域的基于构件的可用的产品进行研究和评估。考虑构件集成的问题。设计软件架构以容纳这些构件。将构件集成到架构中。进行充分的测试以保证功能正常。,形式化方法模型,形式化方法模型的主要活动是生成计算机软件形式化的数学规格说明。形式化方法使软件工程师可以应用严格的数学符号来说明、开发和验证基于计算机的系统。这种方法的一个变型，称为净室软件工程。使用形式化方法，歧义性问
21、题、不完整问题、不一致问题都能够更容易地被发现和改正，不是依靠特定的评审，而是应用数学分析的方法。,形式化方法的意义在于可以提供无缺陷的软件。尽管如此，人们还是怀疑在商业环境中应用形式化方法：目前，形式化模型开发非常耗时，成本也很高。只有极少数程序员具有应用形式化方法的背景，因此需要大量的培训。对于技术水平不高的客户，很难用这种模型进行沟通。,面向方面的软件开发,不论选择什么软件过程，复杂软件无一例外地实现了一套局部化的特征、功能和信息内容。这些局部的软件特性被做成构件(例如,面向对象的类)，然后在系统架构中使用。随着现代计算机系统变得更加复杂，某些关注点(客户需要的属性或者技术兴趣点)体现在
22、了整个架构设计中。例如安全性，容错能力,商业规则等。 如果某个关注点涉及到系统多个方面的功能、特性和信息时，这些关注点通常称为横切关注点。,方面的需求（Aspectual Requirements）定义那些对整个软件体系结构产生影响的横切关注点。面向方面的软件开发（AOSD，Aspect-Oriented Software Development）通常称为面向方面编程（AOP，Aspect-Oriented Progamming），是相对较新的一种软件工程模型。,Rational统一软件开发过程（RUP）,90年代早期，James Rumbaugh ，Grady Booch 和Ivar Jac
23、obson 开始研究“统一方法”，他们的目标是联合各自方法中最好的特点，并吸收其它OO领域专家提出的其他特点。他们的成果就是UML统一建模语言。到了1997年，UML已经变成了面向对象软件开发的工业标准。同时，Rational公司和其它生产商开发了自动化工具以支持UML方法。,UML提供了支持了面向对象软件工程实践必要的技术，但它没有提供指导项目团队应用该技术时的过程框架。接下来的几年中，Jacobson，Rumbaugh和Booch建立了统一过程模型，一种用UML进行面向对象软件工程的框架。目前，统一过程和UML广泛应用在各种各样的面向对象项目中。统一过程提出的迭代增量模型能够而且应该能够满
24、足特定的项目需要。,Rational统一软件开发过程（）是以UML（Unified Modeling Language）作为建模语言进行软件开发的过程。Rational统一过程涵盖了整个软件生命周期，可用来指导更有效的软件开发实践。统一过程的发展经历了从“对象工厂过程”（1987年发布）到“Rational对象工厂过程”（1997年发布），再到“Rational统一过程”（1998年发布）。,到1998年中期，Rational对象工厂过程已经完全成熟，能够支持整个软件开发生命周期。1998年6月，Rational公司发布了该产品的新版本Rational统一过程（）5.0版本。名称的变化反映了统
25、一是从多个角度进行的：开发方法的统一，使用统一建模语言以及很多方法论研究人员的研究成果的统一。,统一过程是基于构件的（component-based），即所构造的软件系统是由软件构件通过明确定义的接口相互连接构造起来的。其突出特点是：用况驱动、以构架为中心、迭代和增量的开发过程。,1. 统一过程是用况驱动的用户与系统的一次交互就称为一个用况（use-case，用例）。用况获取的是功能需求。所有的用况合在一起构成用况模型，它描述了系统的全部功能。用况不仅是确定系统需求的工具，它们还能驱动系统设计、实现和测试的进行，即用况可以驱动开发过程。基于用况模型，开发人员可以创建一系列实现这些用况的设计和实
26、现模型。测试人员测试实现模型的构件是否正确实现了用况。,2.统一过程是以构架为中心的 软件系统的构架从不同的角度描述了即将构造的软件系统，软件构架概念包含了系统中最重要的静态和动态特征。 每一种产品都有功能和表现形式两个方面。其中，功能与用况相对应，表现形式与构架相对应。用况和构架之间是相互影响的。一方面，用况在实现时必须适合于构架；另一方面，构架必须预留空间以实现现在或将来所有需要的用况。,3. 统一过程是迭代和增量的过程 面对当今的复杂的软件系统,使用连续的开发方法,如首先定义整个问题,设计完整的解决方案,编制软件，并最终测试产品是不可能的。需要一种能够通过一系列细化若干个渐进的反复过程，
27、而生成有效解决方案的迭代方法，支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法，极大地减少了项目的风险性.,4. 统一过程的模型 开发过程可以用二维结构或沿着两个坐标轴来表达,横轴代表了制订开发过程时的时间,体现了过程的动态结构,它以术语周期阶段, 迭代和里程碑来表达,纵轴表现了过程的静态结构.,阶段和迭代_时间轴这是开发过程沿时间的动态组织结构软件生命周期被分解为周期，每一个周期工作在产品新的一代上， 将周期又划分为四个连续的阶段 初始阶段 细化阶段 构造阶段 交付阶段每个阶段终结于良好定义的里程碑，某些关键决策必须做出的时间点,因此关键的目标必须被达到.,初始阶段的目标是为系统建立商业案例和确定项目的边界细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素.在构建阶段所有剩余的构件和应用程序功能被开发并集成为产品所有的功能被详尽的测试.交付阶段的目的是将软件产品交付给用户群体.,Thats All!,
