1、 为什么需要软件工程？什么是软件工程？软件工程导论软件工程导论（第（第5 5版）版）普通高校本科计算机专业特色教材精选普通高校本科计算机专业特色教材精选张海藩张海藩 编著编著第一章 软件工程学概论1.1 1.1 软件危机软件危机 1.1.软件软件Software=Program+Data+DocumentSoftware=Program+Data+Document 软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。软件特指大型复杂的程序软件的发展软件的发展早期早期面向批处理有限
2、的分布自定义软件第二阶段第二阶段多用户实时数据库软件产品第三阶段第三阶段分布式系统嵌入“智能”低成本硬件消费者的影响第四阶段第四阶段强大的桌面系统面向对象技术专家系统人工神经网络并行计算网路计算机195019601970198019902000软件特征软件特征l 软件是一种逻辑实体，而不是具体的物理实体软件是一种逻辑实体，而不是具体的物理实体l 软件的生产与硬件不同软件的生产与硬件不同l 在软件的运行和使用期间，没有硬件那样的机械在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题磨损，老化问题磨合调整磨损用坏硬件失效率曲线时间失效率修改点实际曲线理想曲线时间失效率软件失效率曲线l软件的成
3、本相当昂贵软件技术的发展落后于需求时间软件复杂性软件需求差距软件技术硬、软件成本比例的变化年份成本%1950197019851995硬件硬件软件特征软件特征 软件是一种逻辑实体，具有抽象性 软件没有明显的制造过程 软件在使用过程中，没有磨损、老化的问题 软件对硬件和环境有着不同程度的依赖性 软件的开发至今尚未完全摆脱手工作坊式 的开发方式，生产效率低 软件是复杂的，而且以后会更加复杂 软件的成本相当昂贵 大多数软件是自定的，而不是通过已有的 构件组装而来的 软件工作牵涉到很多社会因素 2 2、软件危机、软件危机过去几十年的大型软件系统的开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地
4、挣扎。拉布雷阿的焦油坑（拉布雷阿的焦油坑（Mural of La Brea Tar PitsMural of La Brea Tar Pits）软件危机包含两方面问题：软件危机包含两方面问题：-如何开发软件，以满足不断增长，日趋复杂的需求；如何开发软件，以满足不断增长，日趋复杂的需求；-如何维护数量不断膨胀的软件产品。如何维护数量不断膨胀的软件产品。鉴于软件危机的长期性和症状不明显的特点，近年鉴于软件危机的长期性和症状不明显的特点，近年来有人建议将软件危机更名为：来有人建议将软件危机更名为：Software depression (软件萧条软件萧条)Software affliction (软
5、件困扰软件困扰)“慢性的苦恼慢性的苦恼”软件危机主要有以下表现：软件危机主要有以下表现：对软件开发成本和进度的估计常常不准确。对软件开发成本和进度的估计常常不准确。开发成本超出预算，实际进度比预定计划开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。一再拖延的现象并不罕见。用户对用户对“已完成已完成”系统不满意的现象经常系统不满意的现象经常发生。发生。软件产品的质量往往靠不住。软件产品的质量往往靠不住。BugBug一大堆，一大堆，PatchPatch一个接一个。一个接一个。软件的可维护程度非常之低。软件的可维护程度非常之低。软件通常没有适当的文档资料。软件通常没有适当的文档资料。软件
6、的成本不断提高。软件的成本不断提高。软件开发生产率的提高赶不上硬软件开发生产率的提高赶不上硬件的发展和人们需求的增长。件的发展和人们需求的增长。软件危机的原因 一方面是与软件本身的特点一方面是与软件本身的特点有关有关 另一方面是由软件开发和维另一方面是由软件开发和维护的方法不正确有关护的方法不正确有关 软件开发工作量分配比例软件开发工作量分配比例40%50%10%20%引入同一变化付出的代价随时间变化的趋势引入同一变化付出的代价随时间变化的趋势 费用分配比例费用分配比例55%70%例例:Windows95Windows95有有10001000万行代码万行代码 Windows2000Window
7、s2000有有50005000万行代码，万行代码，30003000多个工程师，几百个小团队。多个工程师，几百个小团队。Exchange2000Exchange2000和和Windows2000Windows2000开发人员结构开发人员结构Exchange2000Exchange2000 Windows2000 Windows2000项目经理项目经理2525人人 约约250250人人开发人员开发人员140140人人 约约17001700人人测试人员测试人员350350人人 约约32003200人人3 3、消除软件危机的途径、消除软件危机的途径 对计算机软件有一个正确的认识对计算机软件有一个正确的
8、认识(软件软件程序程序）必须充分认识到软件开发不是某必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各是一种组织良好、管理严密、各类人员协同配合、共同完成的工类人员协同配合、共同完成的工程项目。程项目。推广使用在实践中总结出来的开推广使用在实践中总结出来的开发软件的成功技术和方法。发软件的成功技术和方法。开发和使用更好的软件工具。开发和使用更好的软件工具。1.2 1.2 软件工程软件工程1.1.工程工程工程是对技术（或社会）实体的分析、设计、建造、验证和管理。水利工程水利工程建筑工程建筑工程机械工程机械工程传统工程新兴工程气象工程气
9、象工程生物工程生物工程软件工程软件工程 -Software Engineering于于1968年年 NATO 组织在组织在德国召开的一次会议上提出德国召开的一次会议上提出围棋与软件工程的感想围棋 围棋棋谱拿过来的时候,大师问“后面应该走哪里？”十个初级爱好者选择的落点散布在棋盘各处 十个职业棋手说的落子点都差不多，甚至包括后面的几步 这就是高手和低手的差别软件工程 当一个小程序拿过来的时候,项目经理让大家编写 十个中国软件工程师写出来的程序各有“特色”、千差万别，十个印度软件工程师写出来的程序差不多，以至于怀疑是“抄袭”。项目经理也不清楚中国软件业和印度软件业的差距是多少年只是觉得差了好远好远
10、2 2、软件工程定义（、软件工程定义（1 1）The establishment and use of sound The establishment and use of sound engineering engineering principles(methods)principles(methods)in in order to obtain economically software order to obtain economically software that is reliable and works on real that is reliable and works o
11、n real machines.(1968-machines.(1968-Fritz Bauer)软件工程就是为了经济地获得可软件工程就是为了经济地获得可靠的且能在实际机器上高效运行靠的且能在实际机器上高效运行的软件，而建立和使用完善的工的软件，而建立和使用完善的工程原理。程原理。软件工程定义（软件工程定义（2 2）Software engineering.(1)The Software engineering.(1)The applicationapplication of a of a systematic,disciplined,quantifiable approach systema
12、tic,disciplined,quantifiable approach to the development,operation,and maintenance to the development,operation,and maintenance of software;that is,the application of of software;that is,the application of engineering to software.(2)The engineering to software.(2)The studystudy of of approaches as i
13、n(1).approaches as in(1).(IEEE Std 610-1990.(IEEE Std 610-1990.）软件工程是软件工程是：（：（1 1）把系统的、规范的、把系统的、规范的、可度量的途径应用于软件开发、运行和可度量的途径应用于软件开发、运行和 维护过程，也就是把工程应用于软件；维护过程，也就是把工程应用于软件；（2 2）研究）研究（1 1）中提到的途径。中提到的途径。Software engineering(3)SEI software engineering definition from 1990 SEI Report on Undergraduate Softw
14、are Engineering Education(CMU/SEI-90-TR-003):Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind.Software engineering is that form of engineering that applies the principles of computer sc
15、ience and mathematics to achieving cost-effective solutions to software problems.总之：总之：软件工程是应用计算机科学、软件工程是应用计算机科学、数学及管理科学等原理开发软数学及管理科学等原理开发软件的工程。它借鉴传统工程的件的工程。它借鉴传统工程的原则、方法，以提高质量，降原则、方法，以提高质量，降低成本为目的。低成本为目的。软件工程是一门交叉学科软件工程是一门交叉学科软件工程的主要研究内容软件工程的主要研究内容u 软件开发技术软件开发技术:软件开发方法学软件开发方法学 软件开发过程软件开发过程 软件工具和软件工
16、程环境软件工具和软件工程环境 u 软件工程管理软件工程管理:软件管理学软件管理学 软件经济学软件经济学 软件心理学软件心理学软件工程：一种层次化技术一种层次化技术质量焦点质量焦点过程过程方法方法工具工具 软件工程层次图软件工程层次图软件工程三个要素：软件工程三个要素：方法、工具、过程方法、工具、过程Software engineering layers 软件工程是一种层次化的技术，以有组织的质量保证为基础软件工程是一种层次化的技术，以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的过程改进，全面的质量管理和类似的理念刺激了不断的过程改进，正是这种改进导致了更加成熟的软件工程方法的
17、不断出现。正是这种改进导致了更加成熟的软件工程方法的不断出现。支持软件工程的根基就在于对质量的关注。支持软件工程的根基就在于对质量的关注。软件工程的基层是过程层软件工程的基层是过程层。软件工程过程是将技术层结合在一起的凝聚力，使得计软件工程过程是将技术层结合在一起的凝聚力，使得计算机软件能够被合理地和及时地开发出来。算机软件能够被合理地和及时地开发出来。过程定义了一组关键过程区域框架，构成了软件项目的过程定义了一组关键过程区域框架，构成了软件项目的管理控制的基础，并且确立了上下各区域之间的关系。管理控制的基础，并且确立了上下各区域之间的关系。规定了技术方法的采用、工程产品（模型、文档、数据、规
18、定了技术方法的采用、工程产品（模型、文档、数据、报告、表格等）的产生、成本的建立、质量的保证及变化的报告、表格等）的产生、成本的建立、质量的保证及变化的适当管理。适当管理。软件工程的方法层提供建造软件在技术上需软件工程的方法层提供建造软件在技术上需要要“如何做？如何做？”。方法涵盖了一系列的任务：方法涵盖了一系列的任务：需求分析、设计、编程、测试和维护。需求分析、设计、编程、测试和维护。软软件工程方法依赖于一组基本原则，这些原则件工程方法依赖于一组基本原则，这些原则控制了每一技术区域，且包含建模活动和其控制了每一技术区域，且包含建模活动和其他描述技术。他描述技术。软件工程的工具层对过程和方法提
19、供了自动软件工程的工具层对过程和方法提供了自动的或半自动的支持。的或半自动的支持。当这些工具被集成起来当这些工具被集成起来使得一个工具产生的信息可被另外一个工具使得一个工具产生的信息可被另外一个工具使用时，一个支持软件开发的系统就建立了，使用时，一个支持软件开发的系统就建立了，称为计算机辅助软件工程（称为计算机辅助软件工程（CASECASE）。）。CASECASE集集成了软件、硬件和一个软件工程数据库（一成了软件、硬件和一个软件工程数据库（一个仓库，其中包含了分析、设计、编程和测个仓库，其中包含了分析、设计、编程和测试的重要信息）。试的重要信息）。软件工程框架可可用用性性性性性性确确正正合合算
20、算选取适宜的开发模型选取适宜的开发模型采用合适的设计方法采用合适的设计方法提供高质量的工程支持提供高质量的工程支持重视软件工程的管理重视软件工程的管理基基本本过过程程原则原则 目标目标 过过 程程支支持持过过程程组组织织过过程程软件工程与一般工程的差异软件工程与一般工程的差异 软件是逻辑产品而不是实物产品软件是逻辑产品而不是实物产品 软件的功能依赖于硬件和软件的运软件的功能依赖于硬件和软件的运行环境以及人们对它的操作行环境以及人们对它的操作 软件设计的复杂性软件设计的复杂性 软件特征：软件特征：功能的多样性功能的多样性 实现的多样性实现的多样性 能见度低能见度低 软件结构合理性差软件结构合理性
21、差 智力密集及知识产权保护智力密集及知识产权保护软件工程知识体系指南（软件工程知识体系指南（2004 2004 版）版）Guide to the Software Engineering Body of Knowledge Guide to the Software Engineering Body of Knowledge 2004 Version2004 Version IEEEIEEE计算机学会（计算机学会（IEEE Computer SocietyIEEE Computer Society）SWEBOK SWEBOK 的的1010个知识域（个知识域（Knowledge AreasKno
22、wledge Areas，KAKA），），软件需求软件需求 Software RequirementsSoftware Requirements软件设计软件设计 Software DesignSoftware Design软件构造软件构造 Software ConstructionSoftware Construction软件测试软件测试 Software TestingSoftware Testing软件维护软件维护 Software MaintenanceSoftware Maintenance软件配置管理软件配置管理 Software Configuration ManagementSo
23、ftware Configuration Management软件工程管理软件工程管理 Software Engineering ManagementSoftware Engineering Management软件工程过程软件工程过程 Software Engineering ProcessSoftware Engineering Process软件工程工具和方法软件工程工具和方法 Software Engineering Tools and MethodsSoftware Engineering Tools and Methods软件质量软件质量 Software QualitySoftw
24、are Quality20042004软件工程知识体系指南软件工程知识体系指南软件工程相关学科软件工程相关学科 计算机工程计算机工程 Computer EngineeringComputer Engineering 计算机科学计算机科学 Computer ScienceComputer Science 管理管理 ManagementManagement 数学数学 MathematicsMathematics 项目管理项目管理 Project ManagementProject Management 质量管理质量管理 Quality ManagementQuality Management 软件
25、人类工程学软件人类工程学 Software ErgonomicsSoftware Ergonomics 系统工程系统工程 Systems EngineeringSystems Engineering软件工程软件工程 本质特征本质特征 软件工程关注于大型程序的构造软件工程关注于大型程序的构造 软件工程的中心课题是控制复杂性软件工程的中心课题是控制复杂性 软件经常变化软件经常变化 开发软件的效率非常重要开发软件的效率非常重要 和谐地合作是开发软件的关键和谐地合作是开发软件的关键 软件必须有效地支持它的用户软件必须有效地支持它的用户 在软件工程领域中是由具有一种文化在软件工程领域中是由具有一种文化背
26、景的人替具有另一种文化背景的人背景的人替具有另一种文化背景的人创造产品创造产品软件工程的基本原理软件工程的基本原理用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性软件工程技术的两个明显特点：强调规范化强调规范化 强调文档化强调文档化软件产品的标准化软件产品的标准化软件开发过程的标准化软件开发过程的标准化“软件工程软件工程”课程课程 与其它软件专业课的区别与其它软件专业课的区别(1)(1)立足于系统的整体。立足于系统的整体。(2)(2)讲授系统分析、系统设计、讲授系统分析、系统设计、测试
27、及维护的理论和方法。测试及维护的理论和方法。(3)(3)构筑一个软件系统，实践构筑一个软件系统，实践 软件开发全过程。软件开发全过程。“软件工程”课程教学与实践的目标转变对软件开发的认识：转变对软件开发的认识：上升上升 程序程序 系统系统 转变思维定式：转变思维定式：上升上升 程序员程序员 系统工程师系统工程师 (系统分析员系统分析员)工程化训练工程化训练系统分析员的地位系统分析员的地位用户用户分析员分析员程序员程序员职业素质职业素质 Professional Practice Communication skills Honesty/Integrity Teamwork skills Int
28、erpersonal skills Motivation/Initiative Strong work ethic3 3、软件工程方法学、软件工程方法学 把在软件生命周期全过程中使用的一整套技术方把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学。法的集合称为方法学。（Methodology or Paradigm）软件工程方法学包含软件工程方法学包含3 3个要素：个要素：方法、工具和过程方法、工具和过程 方法方法 完成软件开发的各项任务的技完成软件开发的各项任务的技 术方法，回答术方法，回答“怎样做怎样做”的问题；的问题；工具工具 为运用方法而提供的自动的或为运用方法而提供的自动的
29、或 半自动的软件工程支撑环境；半自动的软件工程支撑环境；过程过程 为了获得高质量的软件所需要为了获得高质量的软件所需要 完成的一系列任务的框架，它规定了完完成的一系列任务的框架，它规定了完 成各项任务的工作步骤。成各项任务的工作步骤。软件工程方法学分类：软件工程方法学分类：传统方法学传统方法学 面向对象的方法学面向对象的方法学传统方法学传统方法学(生命周期方法学生命周期方法学)仍然是使用十分广泛的软件工程方法学。采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。从上而下，顺序地完成软件开发的各阶段任务。面向对象的方法学面向对象的方法学 出发点和基
30、本原则是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识实践解决问题的方法与过程，从而使描述问题的问题空间与实现解法的解空间在结构上尽可能一致。面向对象的方法学的特点面向对象的方法学的特点 把对象作为融合了数据及在数据上的操作行为的统一软件构件；把所有对象都划分成类；按照父类与子类的关系，把若干个相关类组成一个层次结构的系统；对象彼此间仅能通过发送消息互相联系。1.3 1.3 软件生命周期软件生命周期 问题定义问题定义 软件定义软件定义 可行性研究可行性研究 需求分析需求分析 总体设计总体设计 详细设计详细设计软件生命周期软件生命周期 软件开发软件开发 编码编码 单元测试单
31、元测试 综合测试综合测试 运行维护运行维护 持续满足用户需求持续满足用户需求1.4 1.4 软件过程软件过程 软件过程是为了获得高质量软件所需要完成的软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的一系列任务的框架，它规定了完成各项任务的工作步骤。工作步骤。工作任务里程碑、交付物SQA点 过程定义了运用方过程定义了运用方法的顺序、应该交法的顺序、应该交付的文档资料、为付的文档资料、为保证软件质量和协保证软件质量和协调变化所需要采取调变化所需要采取的管理措施，以及的管理措施，以及标志软件开发各个标志软件开发各个阶段任务完成的里阶段任务完成的里程碑。程碑。公共过程框
32、架公共过程框架辅助活动辅助活动框架活动框架活动任务集合任务集合软件开发模型软件开发模型 软件开发模型软件开发模型是软件开发全部过程、活是软件开发全部过程、活动和任务的动和任务的结构框架结构框架。它能直观表达软。它能直观表达软件开发全过程，明确规定要完成的主要件开发全过程，明确规定要完成的主要活动、任务和开发策略。活动、任务和开发策略。软件开发模型也常称为软件开发模型也常称为：软件过程模型软件过程模型 软件生存周期模型软件生存周期模型 软件工程范型软件工程范型1.1.瀑布模型瀑布模型 (Waterfall Model)(Waterfall Model)传统的瀑布模型传统的瀑布模型需求分析需求分析
33、验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护定义时期定义时期开发时期开发时期维护时期维护时期传统瀑布模型开发软件的特点传统瀑布模型开发软件的特点1.1.阶段间具有顺序性和依赖性。阶段间具有顺序性和依赖性。2.2.推迟实现的观点。推迟实现的观点。3.3.每个阶段必须完成规定的文档每个阶段必须完成规定的文档;每个阶段结束前完成文档审查每个阶段结束前完成文档审查,及早改正错误。及早改正错误。传统瀑布模型存在什么问题？传统瀑布模型存在什么问题？传统的瀑布模型过于理想化。事实上，传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。人在工作过程中不可
34、能不犯错误。在设计阶段可能发生规格说明文档中在设计阶段可能发生规格说明文档中的错误。的错误。而设计上的缺陷或错误可能在实现过而设计上的缺陷或错误可能在实现过程中显现出来。程中显现出来。在综合测试阶段将发现需求分析、设在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。计或编码阶段的许多错误。实际的瀑布模型实际的瀑布模型 瀑布模型的优点瀑布模型的优点 1.1.可强迫开发人员采用规范的方法（例可强迫开发人员采用规范的方法（例如，结构化技术）；如，结构化技术）；2.2.严格地规定了每个阶段必须提交的文严格地规定了每个阶段必须提交的文档；档；3.3.要求每个阶段交出的所有产品都必须要求每个阶段交出
35、的所有产品都必须经过质量保证小组的仔细验证。经过质量保证小组的仔细验证。瀑布模型的成功在很大程度上是由于它瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。基本上是一种文档驱动的模型。瀑布模型的缺点瀑布模型的缺点 1.1.“瀑布模型是由文档驱动的瀑布模型是由文档驱动的”这这个事实也是它的一个主要缺点。个事实也是它的一个主要缺点。2.2.实际项目很少按照该模型给出的顺实际项目很少按照该模型给出的顺序进行；序进行；3.3.用户常常难以清楚地给出所有需求；用户常常难以清楚地给出所有需求；4.4.用户必须有耐心，等到系统开发完用户必须有耐心，等到系统开发完成；成；5.5.开发者常常被不必要
36、地耽搁。开发者常常被不必要地耽搁。2.原型模型-快速原型模型快速原型模型 （Rapid Prototype ModelRapid Prototype Model）快速建立起来的可以在计算机上快速建立起来的可以在计算机上 运行的程序，他所能完成的功能运行的程序，他所能完成的功能 往往是最终产品能完成的功能的往往是最终产品能完成的功能的 一个子集。一个子集。快速原型模型工作过程快速原型模型工作过程 原型模型从需求收集开始。开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。原型
37、由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解，这个过程是迭代的。按线性模型构建软件系统 听取用听取用 户意见户意见建造建造/修改修改原型原型用户测试用户测试运行原型运行原型快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证维护过程维护过程开发过程开发过程原型模型原型模型 适用情况适用情况 用户定义了一组一般性目标，但不用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出能标识出详细的输入、处理及输出需求；需求；开发者可能不能确定算法的有效性
38、、开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形操作系统的适应性或人机交互的形式；式；原型模型可能是最好的选择原型模型可能是最好的选择 原型模型存在的问题 用户似乎看到的是软件的工作版本，其实 开发者常常需要实现上的折衷，以使原型能够尽快工作。3.3.增量模型（渐增模型）增量模型（渐增模型）(Incremental Model)(Incremental Model)先完成一个系统子集的开发，再按同样先完成一个系统子集的开发，再按同样的开发步骤增加功能的开发步骤增加功能 (系统子集系统子集),),如此递如此递增下去直至满足全部系统需求。增下去直至满足全部系统需求。系统的总体设计在
39、初始子集设计阶段就系统的总体设计在初始子集设计阶段就应作出设想。应作出设想。增量模型增量模型需求分析需求分析验证验证规格说明规格说明验证验证设计设计验证验证维护维护针对每个构件完成针对每个构件完成详细设计、编码和详细设计、编码和集成，经测试后交集成，经测试后交付给用户付给用户分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2 增量3增量4 交付交付交付交付增量模型的优点增量模型的优点1.1.在较短时间内向用户提交可完成在较短时间内向用户提交可完成部分工作的产品，并分批、逐步部分工作的产品，并分批、逐步地向用户提交产品。从第一个构地向用户提交产品。从第一个构件交付之日起
40、，用户就能做一些件交付之日起，用户就能做一些有用的工作。有用的工作。2.2.整个软件产品被分解成许多个增整个软件产品被分解成许多个增量构件，开发人员可以一个构件量构件，开发人员可以一个构件一个构件地逐步开发。一个构件地逐步开发。3.3.逐步增加产品功能可以使用户有较逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，充裕的时间学习和适应新产品，从而减少一个全新的软件可能给从而减少一个全新的软件可能给客户组织带来的冲击。客户组织带来的冲击。4.4.采用增量模型比采用瀑布模型和快采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在
41、但在设计阶段多付出的劳动将在维护阶段获得回报。维护阶段获得回报。使用增量模型的困难使用增量模型的困难1.1.增量构件必须不破坏原来已经开发增量构件必须不破坏原来已经开发出的产品。出的产品。2.2.软件的体系结构便于进行扩充，加软件的体系结构便于进行扩充，加入新构件的过程必须简单、方便，入新构件的过程必须简单、方便，即即软件体系结构必须是开放的。软件体系结构必须是开放的。3.3.开发人员既要把软件系统看作整体。开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。又要看成可独立的构件，相互矛盾。4.4.多个构件并行开发，具有无法集成多个构件并行开发，具有无法集成的风险。的风险。4.4.
42、螺旋模型螺旋模型(Spiral Model)(Spiral Model)螺旋模型的核心是关注风险：螺旋模型的核心是关注风险：软件风险是任何软件开发项目中软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风软件越复杂，承担该项目所冒的风险也越大。险也越大。软件风险主要有：软件风险主要有：产品交付给用户后用户可能不满意；到了预定的交付日期软件可能还未开发出来；实际的开发成本可能超过预算；产品完成前一些关键的开发人员 “跳槽”了；产品投入市场之前竞争对手发布 了一个功能相近、价格更低的软 件等。螺旋模型的基本思想 使用原型及其他方
43、法来尽量降使用原型及其他方法来尽量降低风险。低风险。快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析可看作在每个可看作在每个阶段之前都增阶段之前都增加了风险分析加了风险分析过程的快速原过程的快速原型模型。型模型。简化的螺旋模型简化的螺旋模型图图1.8 完整的螺旋模型完整的螺旋模型 螺旋模型风险风险分析分析工程工程实施实施用户通信用户通信用户用户评估评估产品维护项目产品维护项目产品增强项目产品增强项目新产品开发项目新产
44、品开发项目概念开发项目概念开发项目计划计划建造及发布建造及发布螺旋模型 优点优点 对可选方案和约束条件的强调有利于对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；量作为软件开发的一个重要目标；减少了过多测试或测试不足；减少了过多测试或测试不足；维护和开发之间并没有本质区别。维护和开发之间并没有本质区别。特点特点 风险驱动风险驱动 主要适用于内部开发的大规模软件项目主要适用于内部开发的大规模软件项目 要有具有丰富风险评估专门知识的开发要有具有丰富风险评估专门知识的开发人员，否则风险更大。人员，否则风险更大。5.面向对象
45、模型喷泉模型喷泉模型 (Fountain Model)可重用部件组装模型可重用部件组装模型 (构件集成模型）构件集成模型）（Component Integration Model)喷泉模型分析分析设计设计实现实现测试测试集成集成演化演化喷泉模型特点 主要用于支持面向对象开发主要用于支持面向对象开发过程体现了软件创建所固有的迭过程体现了软件创建所固有的迭代和无间隙的特征代和无间隙的特征可重用部件组装模型可重用部件组装模型(构件集成模型构件集成模型)使用重用技术的软件工程模型使用重用技术的软件工程模型构件构件(components)：可重用的软件成份可重用的软件成份可复用性可复用性（Reusabi
46、lity）集成化软件开发环境集成化软件开发环境（ISEE）可重用部件组装模型可重用部件组装模型用户用户通信通信计划计划产品开发及发布产品开发及发布用户用户评估评估风险风险分析分析标志候标志候选构件选构件查找查找构件构件若存在则若存在则提取构件提取构件若不存在则若不存在则构造构件构造构件进行下进行下一次迭代一次迭代将新构件将新构件存入库中存入库中基于构件的软件工程基于构件的软件工程(CBSE)(CBSE)过程模型过程模型 构构 件件 开开 发发分析分析 设计设计 编程编程 测试测试领域分析领域分析系统系统测试测试构件提交构件提交领域专家经验领域专家经验现有系统资料现有系统资料领域构领域构件需求件
47、需求构件构件/构架库构架库领域构架领域构架领领域域构构件件系统系统开发开发系统专用构件系统专用构件应用应用系统系统构件生产线构件生产线领域构架领域构架领域构件领域构件问题域问题域用户需求用户需求系统生产线系统生产线 系系 统统 组组 装装 分析分析 设计设计 编程编程构架细化构架细化专专 用用 构构 件件 开开 发发分析分析 设计设计 编程编程 测试测试 软软 件件 生生 产产 线线应用构件应用构件提取车间提取车间构件生构件生产车间产车间标准规范标准规范 与与 质量保证质量保证1 1基础构件，基础构件，2 2功能构件功能构件 3 3接口构件，接口构件，4 4用户界面构件用户界面构件 应用应用构
48、件库构件库 构件库构件库组装组装车间车间领域领域 1 1领域领域 2 2应用应用系统系统 .1 12 23 34 46.6.形式化方法模型形式化方法模型转换模型转换模型(Transformational Model)(Transformational Model)净室模型净室模型(Cleanroom Model)(Cleanroom Model)转换模型转换模型形式化形式化规格说明规格说明与需求比与需求比较后修正较后修正形式化开发记录形式化开发记录变换变换n变换变换2变换变换1测试测试系统需求系统需求目标系统目标系统 形式化规格语言及其变换技术形式化规格语言及其变换技术 基于模型的规格说明及其
49、变换技术基于模型的规格说明及其变换技术 基于代数结构及其变换技术基于代数结构及其变换技术 基于时序逻辑的规格说明和验证技术基于时序逻辑的规格说明和验证技术 基于可视形式化技术基于可视形式化技术 净室模型净室模型(形式化的增量开发模型形式化的增量开发模型)基于思想基于思想：力求在分析和设计阶段就消除错误，力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或确保正确，然后在无缺陷或“洁净洁净”的状态的状态下实现软件的制作。下实现软件的制作。三个关键技术三个关键技术：置于统计过程控制之下的增量开发置于统计过程控制之下的增量开发 基于函数的规范、设计、验证基于函数的规范、设计、验证 统计测试和软件认证统计测试和软件认证 净净 室室 模模 型型盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#1盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#2盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#1.作业：习题作业：习题1 1，1 1、3 3、7 7题。题。
