软件工程01.ppt

《软件工程01.ppt》由会员分享，可在线阅读，更多相关《软件工程01.ppt（136页珍藏版）》请在三一办公上搜索。

1、软件工程导论,2/130,要求：,上课时间：每周一（1-2）上机时间：每周一（3-4）研讨时间：每周四（3-4）注：周四（3）for(1)班和(3)班 周四（4）for(2)班和(4)班 4人/组，每周3组考核方案：平时成绩40%（出勤10%+研讨15%+上机15%）考试成绩60%不迟到、早退,3/130,内容摘要,计算机软件软件危机软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境,4/130,内容摘要,计算机软件软件危机软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境,5/130,计算机软件,计算机软件指计算机系统中的程序及其文档程序是计算任务的处理对象和处理规则的描述任

2、务：以计算机为处理工具的任务都是计算任务处理对象：数据（如数据、文字、图形、图像、声音等，它们只是表示，而无含义）或信息（数据及有关的含义）处理规则一般指处理的动作和步骤。程序必须装入计算机内才能工作文档是为了便于了解程序所需的阐明性资料，文档一般是给人看的，不一定装入计算机,6/130,软件的发展,1946-1956年(第一阶段)从计算机问世到实用的高级程序语言出现前存储容量比较小，运算速度比较慢采用个体工作方式,用低级语言编写程序应用领域主要是以数值数据处理为主的科学计算，其特点是输入、输出量较小衡量程序质量的标准主要是功效，即运行时间省、占用内存小主要研究内容是科学计算程序、服务性程序和

3、程序库，研究对象是顺序程序,机器指令（操作码和数据码组成，都是由0和1组成的序列）。汇编语言（机器指令和存储地址可以用助记符号来表示）机器只能识别和理解二进制，所以需要“汇编程序”将汇编语言写的程序翻译成机器指令程序。,7/130,1956-1968年（第二阶段）从实用的高级程序语言出现到软件工程出现前存储器容量大，外围设备得到迅速发展，出现了高级程序设计语言应用领域包括数据处理（非数值数据），其特点是计算量不大，但输入、输出量却较大高速主机与低速外围设备的矛盾突出，出现了操作系统、并发程序、数据库及其管理系统20世纪60年代初提出了软件一词，开始认识到文档的重要性研究高级程序设计语言、编译程

4、序、操作系统、支持编程的工具及各种应用软件工作方式逐步从个体方式转向合作方式出现软件危机,8/130,1968年-至今（第三阶段）从软件工程出现到现在硬件向巨型机和微型机二个方向发展，出现了计算机网络，软件方面提出了软件工程，出现了“计算机辅助软件工程”（CASE）计算机的应用领域渗透到各个业务领域，出现了嵌入式应用，其特点是受制于它所嵌入的宿主系统开发方式逐步由个体合作方式转向工程方式软件工程方面的研究主要包括软件开发模型、软件开发方法及技术、软件工具与环境、软件过程、软件自动化系统等软件方面重点研究以智能化、自动化、集成化、并行化、以及自然化为标志的软件开发新技术,9/130,软件危机,许

5、多软件项目不能满足客户的要求 许多软件项目超出预算和时间安排,10/130,软件危机的表现,对软件开发成本和进度的估计常常很不正确用户对“已完成的”软件系统不满意的现象经常发生软件产品的质量往往靠不住软件常常是不可维护的软件通常没有适当的文档资料软件成本在计算机系统总成本中所占的比例逐年上升软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势,11/130,产生软件危机的原因,软件是逻辑产品，开发进度、成本难以估计缺乏或不完整、不一致的文档给维护带来困难用户对软件需求的描述往往不够精确，有遗漏，有二义软件开发人员对需求的理解与用户的本来愿望有差异大型软件项目需多人协同完成，缺乏管理经

6、验开发人员不能有效地、独立自主地处理大型软件的全部关系缺乏有力的方法学和工具的支持软件项目的特殊性和人类智力的局限性,12/130,克服软件危机的途径,消除错误的概念和做法推广使用成功的开发技术和方法使用软件工具和软件工程支持环境加强软件管理,13/130,软件的特点,软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算软件是被开发的或被设计的，它没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大软件的使用没有硬件那样的机械磨损和老化问题,14/130,“浴缸理论”图1.1：表明了硬件在其生命初期有较高的故障率（主要是由于设计或制造的缺陷），修正后，会在一段

7、时间内降到一个稳定的水平。图1.2：理论上是一条理想曲线，未发现的错误会引起程序在其生命初期具有较高的故障率。（当错误改正后不引入新的错误）。实际修改后会引入新的错误，导致锯齿形,15/130,软件的其它特点：软件的开发和运行常受到计算机硬件的限制，对计算机硬件有着不同程度的依赖性软件的开发至今尚未完全实现自动化软件成本相当昂贵相当多的软件工作涉及到社会因素,16/130,17/130,软件的分类（计算机科学技术百科全书）,系统软件：属于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。支撑软件：支持软件的开发和维护的软件。如数据

8、库管理系统、网络软件、软件开发环境等。应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。,18/130,按软件工作方式划分：实时处理软件 分时软件 交互式软件 批处理软件 按软件服务对象的范围划分：项目软件 产品软件,19/130,按使用的频度进行划分：一次使用 频繁使用 按软件失效的影响进行划分：高可靠性软件 一般可靠性软件,20/130,软件语言software language,软件语言是用于书写计算机软件的语言。它主要包括：需求定义语言 功能性语言 设计性语言 实现性语言（即程序设计语言）文档语言,21/130,需求定义语言re

9、quirements definition language,需求定义语言用来书写软件需求定义。软件需求定义是软件功能需求和非功能需求的定义性描述。软件功能需求刻画软件“做什么”，软件非功能需求刻画诸如功能性限制、设计限制、环境描述、数据与通信规程及项目管理等典型的需求定义语言有PSL语言（Problem Statement Language问题陈述语言）,22/130,功能性语言functional language,功能性语言用来书写软件功能规约（functional specification）软件功能规约是软件功能的严格而完整的陈述。通常它只刻画软件系统“做什么”的外部功能，而不涉及系

10、统“如何做”的内部算法。典型的功能性语言有广谱语言、Z语言。,23/130,设计性语言design language,设计性语言用来书写软件设计规约（design specification）软件设计规约是软件设计的严格而完整的陈述。一方面，它是软件功能归约的算法性细化，刻画软件“如何做”的内部算法，另一方面，它是软件实现的依据。典型的设计性语言有PDL语言（Program Design Language）,24/130,实现性语言,实现性语言用来书写计算机程序 实现性语言也称编程语言或程序设计语言（programming language）程序设计语言可按语言的级别、对使用者的要求、应用范围

11、、使用方式、成分性质等多种角度进行分类,25/130,按语言级别分：低级语言和高级语言 低级语言是与特定计算机体系结构密切相关的程序设计语言，如机器语言、汇编语言。其特点是与机器有关，功效高，但使用复杂，开发费时，难维护。高级语言是不反映特定计算机体系结构的程序设计语言，它的表示方法比低级语言更接近于待解问题的表示方法。其特点是在一定程度上与具体机器无关，易学、易用、易维护。但高级语言程序经编译后产生的目标程序的功效往往较低。,26/130,按用户要求分：过程式语言和非过程式语言 过程式语言（procedural language）是通过指明一列可执行的运算及运算次序来描述计算过程的程序设计语

12、言。如FORTRAN、COBOL、C等。非过程式语言（nonprocedural language）是不显式指明处理过程细节的程序设计语言。在这种语言中尽量引进各种抽象度较高的非过程性描述手段，以期做到在程序中增加“做什么”的描述成分，减少“如何做”的细节描述。如第四代语言（4GL）、函数式语言、逻辑式语言。,27/130,函数式语言(functional programming language)中函数是构造程序的基本成分，它提供一些设施用于构造更为复杂的函数。程序人员根据提出的问题去定义求解函数（即主程序），其中可能包含一些辅助函数。如Lisp语言。逻辑式语言(logic programm

13、ing language)的基本运算单位是谓词。谓词定义了变元间的逻辑关系。例如，Prolog语言的基本形式是Horn子句，其程序围绕着某一主题的事实、规则和询问三类语句组成。这三类语句分别用来陈述事实、定义规则和提出问题。,28/130,按应用范围分：通用语言和专用语言 通用语言指目标非单一的语言，如FORTRAN、COBOL、C等。专用语言指目标单一的语言，如自动数控程序APT。,29/130,文档语言documentation language,文档语言用来书写软件文档。计算机软件文档是计算机开发、维护和使用过程的档案资料和对软件本身的阐述性资料。通常用自然语言或半形式化语言书写。,30

14、/130,内容摘要,计算机软件软件危机软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境,31/130,软件工程定义,1968年NATO(北大西洋公约组织)会议上首次提出Fritz Bauer：软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而建立和使用的好的工程原则；IEEE：软件工程是（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中；（2）（1）中所述方法的研究计算机科学技术百科全书：软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法制作软件的工程,32/130,软件工程的本质特征,1.软件工程关注于大型

15、程序的构造。“大”与“小”的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。传统的程序设计技术和工具是支持小型程序设计的，不能简单地把这些技术和工具用于开发大型程序。事实上，在此处使用术语“程序”并不十分恰当，现在的软件开发项目通常构造出包含若干个相关程序的“系统”。,33/130,软件工程的本质特征,2.软件工程的中心课题是控制复杂性。通常，软件所解决的问题十分复杂，以致不能把问题作为一个整体通盘考虑。人们不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂

16、性，但是却可使它变成可以管理的。注意，许多软件的复杂性主要不是由问题的内在复杂性造成的，而是由必须处理的大量细节造成的。,34/130,软件工程的本质特征,3.软件经常变化 绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能的变化。4.开发软件的效率非常重要 目前，社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。,35/130,软件工程的本质

17、特征,5.和谐地合作是开发软件的关键 软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。事实上仅有上述规定还不够，每个人还必须严格地按规定行事。为了迫使大家遵守规定，应该运用标准和规程。通常，可以用工具来支持这些标准和规程。总之，纪律是成功地完成软件开发项目的一个关键。,36/130,软件工程的本质特征,6.软件必须有效地支持它的用户 开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。如果用户对软件系统不满意，可以弃用该系统，至少也会立即提出新的需求。因此，仅仅用正确的方法构造系统还不够，还必须

18、构造出正确的系统。有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求(例如，可靠性、响应时间等)。有效地支持用户还意味着，软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料，此外，还必须注意建立使用新系统的环境。,37/130,软件工程的本质特征,7.在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人 软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言(UML)等方面的专家，他们通常并不是图书馆管理、航空控制或银行事务等领域的专家，但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的

19、常见原因。软件工程师不仅缺乏应用领域的实际知识，他们还缺乏该领域的文化知识。例如，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现了这个工作流程。,38/130,软件工程的基本原理,自从1968年在德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则。著名的软件工程专家B.W.Boehm综合这些学者们的意见并总结了TRW公司多年开发软件的经验，于1983年在一篇论文中提出了软件工程的7条基本原理。他认为这7条原理是确保软件产品质量和开发效率的原理的最小集合。,39/130,软件工程的7

20、条基本原理,1.用分阶段的生命周期计划严格管理。有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。可见把建立完善的计划作为第一条基本原理是吸取了前人的教训而提出来的。这条基本原理意味着，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。,40/130,软件工程的7条基本原理,2.坚持进行阶段评审；软件的质量保证工作不能等到编码阶段结束之后再进行。,第一，大部分错误是在编码之前造成的，例如，根据Bo

21、ehm等人的统计，设计错误占软件错误的63%，编码错误仅占37%；第二，错误发现与改正得越晚，所需付出的代价也越高。,41/130,软件工程的7条基本原理,3.实行严格的产品控制 在软件开发过程中不应随意改变需求。改变需求是难免的，只能依靠科学的产品控制技术来顺应这种要求。主要是实行基准配置管理。所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。基准配置管理也称为变动控制：一切有关修改软件的建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。,42/130,软件工程的7条基本原理,4.采用现代程序设计技术 从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序

22、设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。,43/130,软件工程的7条基本原理,5.结果应能清楚地审查 软件产品是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。,44/130,软件工程的7条基本原理,6.开发小组的人员应该少而精 开发小组人员的素质和数量是影

23、响软件产品质量和开发效率的重要因素。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N-1)/2条，可见随着人数N的增大，通信开销将急剧增加。,结论：组成少而精的开发小组是软件工程的一条基本原理。,45/130,软件工程的7条基本原理,7.承认不断改进软件工程实践的必要性 仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。

24、,46/130,软件工程的框架,目标：生产具有正确性、可用性以及价格合宜的产品正确性反映软件产品实现相应功能规约的程 度；可用性反映软件的基本结构、实现及其文档为 用户可用的程度；价格合宜反映软件开发与运行的总代价满足用户要求的程度。,47/130,原则：选取适宜的开发模型 采用合适的设计方法 提供高质量的工程支持 重视软件工程的管理,48/130,软件生命周期（software life cycle）,软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期,49/130,软件生命周期,概括地说，软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组

25、成。软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。软件定义时期的工作通常又称为系统分析，由系统分析员负责完成。,50/130,软件生命周期,开发时期就是具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：总体设计，详细设计，编码和测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了

26、的定义和开发过程。,51/130,1.问题定义必须回答的关键问题“要解决的问题是什么？”2.可行性研究这个阶段回答的关键问题是“对于上一个阶段所确定的问题有行得通的解决办法吗？”系统分析员要进行一次大大压缩和简化了的系统分析和设计过程，也就是在较抽象的层次上进行分析和设计过程。并不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解决，是否有可行的解决办法，是否继续下去。,52/130,软件需求分析主要解决待开发软件要“做什么”的问题确定目标系统必须具备哪些功能、性能、数据、界面等要求，生成软件需求规约。在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，必须完成的体现用户

27、的需求。这个阶段的一个重要任务就是需求规约（需求规格说明书specification）,53/130,软件设计主要解决待开发软件“怎么做”的问题。软件设计通常可分为系统设计（也称概要设计或总体设计）和详细设计。系统设计必须回答的问题“概括地讲，应该怎样实现目标系统？”。的任务是设计软件系统的体系结构，包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通信，同时设计全局数据结构；确定程序由哪些模块组成以及模块之间的关系。详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法等。这个阶段并不是编写程序，而是设计出程序的详细的规格说明。,54/130,编码 用某种程序设计语言，将

28、设计的结果转换为可执行的程序代码。测试 发现并纠正软件中的错误和缺陷。测试主要包括单元测试、集成测试、确认测试和系统测试。运行和维护 在软件运行期间，当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时对软件进行修改。,55/130,内容摘要,计算机软件软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境,56/130,软件过程,软件过程是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。软件过程有三层含义：个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程，软件管理过程等；整体含义，即指软件产品或系统在所有上述含义

29、下的软件过程的总体；工程含义，即指解决软件过程的工程，它应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件生产率，降低成本。,57/130,ISO12207软件生存周期过程,ISO/IEC 12207标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个组织过程。每一个过程划分为一组活动，每项活动进一步划分为一组任务。,58/130,基本（primary）过程供各当事方在软件生存周期期间使用。包括：获取（acquisition）过程：确定需方和组织向供方获取系统、软件或软件服务的活动。供应（supply）过

30、程：确定供方和组织向需方提供系统、软件或软件服务的活动。开发（development）过程：确定开发者和组织定义并开发软件的活动。运作（operation）过程：确定操作者和组织在规定的环境中为其用户提供运行计算机系统服务的活动。维护（maintenance）过程：确定维护者和组织提供维护软件服务的活动。,59/130,支持（supporting）过程用于支持其他过程，它有助于软件项目的成功和质量提高。包括：文档编制（documentation）过程：确定记录生存周期过程产生的信息所需的活动。配置管理（configuration management）过程：确定配置管理活动。质量保证（qual

31、ity assurance）过程：确定客观地保证软件和过程符合规定的要求以及已建立的计划所需的活动。验证（verification）过程：根据软件项目要求，按不同深度确定验证软件所需的活动。,60/130,确认（validation）过程：确定确认软件所需的活动。联合评审（joint review）过程：确定评价一项活动的状态和产品所需的活动。审计（audit）过程：确定为判断符合要求、计划和合同所需的活动。问题解决（problem resolution）过程：确定一个用于分析和解决问题的过程。,61/130,组织（organizational）过程用于软件组织建立和实现构成相关生存周期的基础

32、结构和人事制度，并不断改进这种结构和过程。包括：管理（management）过程：确定生存周期过程中的基本管理活动。基础设施（infrastructure）过程：确定建立生存周期过程基础结构的基本活动。改进（improvement）过程:确定一个组织为建立、测量、控制和改进其生存周期过程所需开展的基本活动。培训（training）过程:确定提供经适当培训的人员所需的活动。,62/130,ISO/IEC 12207为软件生存周期过程建立了一个公共框架，它提供了一组标准的过程、活动和任务。对于一个软件项目，可根据其具体情况对标准的过程、活动和任务进行剪裁，即删除不适用的过程、活动和任务。,63/1

33、30,能力成熟度模型CMM,CMM（Capability Maturity Model）即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。,64/130,软件组织的成熟与不成熟,1.不成熟的软件组织软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划有时，即使软件过程已计划好，仍不按计划执行没有一个客

34、观的基准来判断产品质量，或解决产品和过程中的问题对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消产品在交付前，对客户来说，一切都是不可见的没有长远目标，管理员通常只关注解决任何当前的危机由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度。,65/130,2.成熟的软件组织具有全面而充分的组织和管理软件开发和维护过程的能力管理员监视软件产品的质量以及生产这些产品的过程制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题进度和预算可以

35、按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作凡规定的过程都编成文档,66/130,软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程。全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，每人各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生。,67/130,软件过程成熟度等级,CMM提供了一个成熟度等级框架：1级-初始级、2级-可重复级、3级-已定义级、

36、4级-已管理级和5级-优化级。1.初始（initial）级：软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。2.可重复（repeatable）级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。,68/130,3.已定义（defined）级：己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。4.已管理（managed）级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和

37、控制。5.优化（optimizing）级：整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进。,69/130,70/130,能力成熟度模型集成CMMICapability Maturity Model Integration,CMM的成功导致了各种模型的衍生，每一种模型都探讨了某一特定领域中的过程改进问题SW-CMM：适用于软件开发SE-CMM：系统工程能力成熟度模型SA-CMM：适用于软件获取SECAM：系统工程能力评估模型People CMM：讨论软件组织吸引、开发、激励、组织和留住人才的能力EIA/IS 731：替

38、代SW-CMM和SECAMIPD-CMM：适用于集成化产品开发FAA-iCMM：集成了SE-CMM、SA-CMM、SW-CMM,71/130,CMMI V1.1的24个过程域的分组如下：,72/130,内容摘要,计算机软件软件工程软件过程软件过程模型敏捷软件开发CASE工具与环境,73/130,软件过程模型,软件过程模型是软件开发全部过程、活动和任务的结构框架也称软件开发模型或软件生存周期模型。通常使用生命周期模型简洁地描述软件过程，生命周期模型规定了把生命周期划分成哪些阶段以及各个阶段的执行顺序，因此，也称之为过程模型。,74/130,软件过程模型,典型的软件过程模型有：瀑布模型（water

39、fall model）演化模型（evolutionary model）增量模型（incremental model）原型模型（prototyping model)螺旋模型（spiral model）喷泉模型（water fountain model）基于构件的开发模型（component-based development model）形式方法模型（formal methods model）,75/130,瀑布模型,图1.2 传统的瀑布模型,在20世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以

40、用瀑布模型来描述。,76/130,1970年W.Royce提出瀑布模型 特征接受上一阶段的结果作为本阶段的输入利用这一输入实施本阶段应完成的活动对本阶段的工作进行评审将本阶段的结果作为输出，传递给下一阶段 缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大,77/130,图1.3 实际的瀑布模型,1.优点2.文档驱动,78/130,大量实践表明，在开发初期，很难得到一个完整的、准确的需求规约，这主要是由于用户往往不能准确地表达对系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求常常不完整、不准确，有时甚至是有歧义的。

41、,79/130,许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功。可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型适用于对软件需求缺乏准确认识的情况。典型的演化模型有：增量模型、原型模型、螺旋模型。,演化模型,80/130,所谓快速原型是快速建立起来的可以在计算机上运行的程

42、序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。,快速原型模型,81/130,快速原型模型,图1.4 快速原型模型,快速原型模型是不带反馈环的，开发过程基本上是线性的。,82/130,（1）原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。（2）开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计

43、和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，。,快速原型模型,83/130,快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，原型系统的内部结构并不重要，重要的是，必须迅速地构建原型然后根据用户意见迅速地修改原型。,快速原型模型,84/130,原型的类型：探索型（exploratory prot

44、otyping）其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性实验型（experimental prototyping）其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。演化型（evolutionary prototyping）其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。,85/130,原型的使用策略：废弃（throw away）策略 主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结

45、构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统。追加（add on）策略 主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统。原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中。,86/130,增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最

46、核心的功能。第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。,增量模型,87/130,能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。,增量模型,88/130,增量模型,89/130,增量模型的第2个优点：逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户

47、组织带来的冲击。使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。但是，从长远观点看，具有开放结构的软件拥有真正的优势，这样的软件的可维护性明显好于封闭结构的软件。,增量模型,90/130,增量模型特别适用于：需求经常变化的软件开发市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发,91/130,B.Boehm于1988年提出是瀑布模型和演化模型的结合，并增加了风险分析（软件开发总是

48、有风险的）螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析：评价所选的方案，识别风险，消除风险工程实施：实施软件开发，验证工作产品客户评估：评价开发工作，提出修正建议,螺旋模型,92/130,93/130,螺旋模型出现了一些变种，它可以有3到6个任务区域。螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止。多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。,94/130,喷泉模型

49、,95/130,喷泉模型是一种支持面向对象开发的模型体现迭代和无间隙特征迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统无间隙：开发活动之间不存在明显的边界,96/130,支持软件复用（reuse）利用预先包装好的软件构件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统,基于构件的开发模型,97/130,98/130,领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。领域分析分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构（reference architecture），标识领域的候选构件。对候选构件进行可变性分

50、析，以适应多个应用系统的需要。构建可复用构件，经严格测试和包装后存入可复用构件库（称为构件工程）。,99/130,应用系统工程的目的是使用可复用构件组装应用系统。分析待开发的应用系统，设计应用系统的体系结构，标识应用系统所需的构件。在可复用构件库中查找合适的构件（也可购买第三方的构件）。特化选中的构件，必要时作适当的修改，以适应该应用系统的需要。开发那些未找到合适构件的应用部分。组装应用系统。评价构件的复用情况，以改进可复用构件，同时对新开发的部分进行评价，并向构件工程推荐候选构件。,100/130,根据AT&T、Ericsson、HP公司的经验，有的软件复用率高达90%以上，产品上市时间可缩