第1章 概述3.ppt
软件工程导论软件工程导论（第（第4 4版）版）普通高校本科计算机专业特色教材精选张海藩 编著第一章 软件工程学概论1.1 1.1 软件危机软件危机 1.1.软件软件Software=Program+Data+DocumentSoftware=Program+Data+Document 软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。软件特征软件特征l软件是一种逻辑实体，而不是具体的物理实体l软件的生产与硬件不同l在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题软件技术的发展落后于需求时间软件复杂性软件需求差距软件技术硬、软件成本比例的变化年份成本%软件软件1950197019851995硬件硬件2 2、软件危机、软件危机软件危机包含两方面问题：软件危机包含两方面问题：-如何开发软件，以满足不断增长，日趋复杂的需求；如何开发软件，以满足不断增长，日趋复杂的需求；-如何维护数量不断膨胀的软件产品。如何维护数量不断膨胀的软件产品。鉴于软件危机的长期性和症状不明显的特点，近年来有人建议将软件危机更名为：Software depression (软件萧条软件萧条)Software affliction (软件困扰软件困扰)“慢性的苦恼慢性的苦恼”软件危机主要有以下表现：软件危机主要有以下表现：对软件开发成本和进度的估计常常不准对软件开发成本和进度的估计常常不准确。开发成本超出预算，实际进度比预确。开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。定计划一再拖延的现象并不罕见。用户对用户对“已完成已完成”系统不满意的现象经系统不满意的现象经常发生。常发生。软件产品的质量往往靠不住。软件产品的质量往往靠不住。BugBug一大堆，一大堆，PatchPatch一个接一个。一个接一个。软件的可维护程度非常之低。软件的可维护程度非常之低。软件通常没有适当的文档资料。软件通常没有适当的文档资料。软件的成本不断提高。软件的成本不断提高。软件开发生产率的提高赶不上硬件的发软件开发生产率的提高赶不上硬件的发展和人们需求的增长。展和人们需求的增长。软件开发工作量分配比例软件开发工作量分配比例40%50%10%20%费用分配比例费用分配比例55%70%引入同一变化付出的代价随时间变化的趋势引入同一变化付出的代价随时间变化的趋势3 3、消除软件危机的途径、消除软件危机的途径对计算机软件有一个正确的认识对计算机软件有一个正确的认识(软件软件程序程序）必须充分认识到软件开发不是某必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各是一种组织良好、管理严密、各类人员协同配合、共同完成的工类人员协同配合、共同完成的工程项目。程项目。推广使用在实践中总结出来的开推广使用在实践中总结出来的开发软件的成功技术和方法。发软件的成功技术和方法。开发和使用更好的软件工具。开发和使用更好的软件工具。软件工程软件工程 -Software Engineering于于1968年年 NATO 组织在组织在德国召开的一次会议上提出德国召开的一次会议上提出是把软件当作一种工业产品，要求是把软件当作一种工业产品，要求是把软件当作一种工业产品，要求是把软件当作一种工业产品，要求 “采用工程化的采用工程化的采用工程化的采用工程化的原理与方法对软件进行计划、开发和维护原理与方法对软件进行计划、开发和维护原理与方法对软件进行计划、开发和维护原理与方法对软件进行计划、开发和维护 ”。1.2 软件工程件工程围棋与软件工程的感想围棋 围棋棋谱拿过来的时候,大师问“后面应该走哪里？”十个初级爱好者选择的落点散布在棋盘各处 十个职业棋手说的落子点都差不多，甚至包括后面的几步 这就是高手和低手的差别软件工程 当一个小程序拿过来的时候,项目经理让大家编写 十个中国软件工程师写出来的程序各有“特色”、千差万别，十个印度软件工程师写出来的程序差不多，以至于怀疑是“抄袭”。项目经理也不清楚中国软件业和印度软件业的差距是多少年只是觉得差了好远好远2 2、软件工程定义、软件工程定义Software engineering.(1)The Software engineering.(1)The applicationapplication of of a systematic,disciplined,quantifiable a systematic,disciplined,quantifiable approach to the development,operation,and approach to the development,operation,and maintenance of software;that is,the maintenance of software;that is,the application of engineering to software.(2)application of engineering to software.(2)The The studystudy of approaches as in(1).of approaches as in(1).(IEEE Std(IEEE Std 610-1990.610-1990.）软件工程是软件工程是：（：（1 1）把系统的、规范的、把系统的、规范的、可度量的途径应用于软件开发、运行和可度量的途径应用于软件开发、运行和 维护过程，也就是把工程应用于软件；维护过程，也就是把工程应用于软件；（2 2）研究）研究（1 1）中提到的途径。中提到的途径。软件工程技术的两个明显特点：强调规范化强调规范化 强调文档化强调文档化转变转变对软件对软件开发开发的认识：的认识：上升上升 程序程序 系统系统 转变转变思维定式：思维定式：上升上升 程序员程序员 系统工程师系统工程师 (系统分析员系统分析员)1.3 1.3 软件生命周期软件生命周期 问题定义问题定义 软件定义软件定义 可行性研究可行性研究 需求分析需求分析 总体设计总体设计 详细设计详细设计软件生命周期软件生命周期 软件开发软件开发 编码编码 单元测试单元测试 综合测试综合测试 运行维护运行维护 持续满足用户需求持续满足用户需求软件开发模型软件开发模型 软件软件开发开发模型模型是软件开发全部过程、活是软件开发全部过程、活动和任务的动和任务的结构框架结构框架。它能直观表达软。它能直观表达软件开发全过程，明确规定要完成的主要件开发全过程，明确规定要完成的主要活动、任务和开发策略。活动、任务和开发策略。软件软件开发开发模型也常称为模型也常称为：软件软件过程过程模型模型 软件生存软件生存周周期模型期模型 软件工程范型软件工程范型1.4 软件件过程程1.1.瀑布模型瀑布模型 (Waterfall ModelWaterfall Model)传统的瀑布模型传统的瀑布模型需求分析需求分析验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护定义时期定义时期开发时期开发时期维护时期维护时期传统瀑布模型开发软件的特点传统瀑布模型开发软件的特点1.1.阶段间具有顺序性和依赖性。阶段间具有顺序性和依赖性。2.2.每个阶段必须完成规定的文档每个阶段必须完成规定的文档;每个阶段结束前完成文档审查每个阶段结束前完成文档审查,及早改正错误及早改正错误。传统瀑布模型存在什么问题？传统瀑布模型存在什么问题？传统的瀑布模型过于理想化。事实上，传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。人在工作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的在设计阶段可能发生规格说明文档中的错误。错误。而设计上的缺陷或错误可能在实现过程而设计上的缺陷或错误可能在实现过程中显现出来。中显现出来。在综合测试阶段将发现需求分析、设计在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。或编码阶段的许多错误。瀑布模型瀑布模型的优缺点的优缺点瀑布模型有许多优点：可强迫开发人员采用规范瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）；的方法（例如，结构化技术）；严格地规定了严格地规定了每个阶段必须提交的文档；要求每个阶段交出的每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。所有产品都必须经过质量保证小组的仔细验证。瀑布模型的成功在很大程度上是由于它基本上是瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。一种文档驱动的模型。“瀑布模型是由文档驱动的瀑布模型是由文档驱动的”这个事实也是它的这个事实也是它的一个主要缺点。一个主要缺点。实际项目很少按照该模型给出的顺序进行；实际项目很少按照该模型给出的顺序进行；用户常常难以清楚地给出所有需求；用户常常难以清楚地给出所有需求；用户必须有耐心，等到系统开发完成；用户必须有耐心，等到系统开发完成；开发者常常被不必要地耽搁。开发者常常被不必要地耽搁。2.原型模型-快速快速原原型模型型模型 （Rapid Prototype ModelRapid Prototype Model）快速建立起来的可以在计算机上快速建立起来的可以在计算机上 运行的程序，他所能完成的功能运行的程序，他所能完成的功能 往往是最终产品能完成的功能的往往是最终产品能完成的功能的 一个子集。一个子集。听取用听取用 户意见户意见建造建造/修改修改原型原型用户测试用户测试运行原型运行原型快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证维护过程维护过程开发过程开发过程原型模型原型模型 适用情况适用情况用户定义了一组一般性目标，但不用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出能标识出详细的输入、处理及输出需求；需求；开发者可能不能确定算法的有效性、开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形操作系统的适应性或人机交互的形式；式；原型模型可能是最好的选择原型模型可能是最好的选择 3.3.增量模型（渐增模型）增量模型（渐增模型）(Incremental Model)(Incremental Model)先完成一个系统子集的开发，再按同样的先完成一个系统子集的开发，再按同样的开发步骤增加功能开发步骤增加功能 (系统子集系统子集),),如此递增如此递增下去直至满足全部系统需求。下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应系统的总体设计在初始子集设计阶段就应作出设想。作出设想。增量模型增量模型需求分析需求分析验证验证规格说明规格说明验证验证设计设计验证验证维护维护针对每个构件完成针对每个构件完成详细设计、编码和详细设计、编码和集成，经测试后交集成，经测试后交付给用户付给用户增量模型的优点增量模型的优点在较短时间内向用户提交可完成部分工作的产在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些第一个构件交付之日起，用户就能做一些有用的工作。有用的工作。整个软件产品被分解成许多个增量构件，开发整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。人员可以一个构件一个构件地逐步开发。逐步增加产品功能可以使用户有较充裕的时间逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。软件可能给客户组织带来的冲击。采用增量模型比采用瀑布模型和快速原型模型采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。的劳动将在维护阶段获得回报。使用增量模型的困难使用增量模型的困难1.1.在把每个新的增量构件集成到现有软件在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简向现有产品中加入新构件的过程必须简单、方便，也就是说，单、方便，也就是说，软件体系结构必软件体系结构必须是开放的。须是开放的。2.2.开发人员既要把软件系统看作整体。又开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。要看成可独立的构件，相互矛盾。3.3.多个构件并行开发，具有无法集成的风多个构件并行开发，具有无法集成的风险。险。4.4.螺旋模型螺旋模型(Spiral Model)(Spiral Model)产品交付给用户后用户可能不满意；产品交付给用户后用户可能不满意；到了预定的交付日期软件可能还未开发到了预定的交付日期软件可能还未开发出来；出来；实际的开发成本可能超过预算；实际的开发成本可能超过预算；产品完成前一些关键的开发人员产品完成前一些关键的开发人员 “跳槽跳槽”了；了；产品投入市场之前竞争对手发布产品投入市场之前竞争对手发布 了一个功能相近、价格更低的软了一个功能相近、价格更低的软 件等。件等。软件风险是任何软件开发项目中都普遍存在的软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。例如：目所冒的风险也越大。例如：螺旋模型的基本思想使用原型及其他方法来尽量降使用原型及其他方法来尽量降低风险。低风险。快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析可看作在每个可看作在每个阶段之前都增阶段之前都增加了风险分析加了风险分析过程的快速原过程的快速原型模型。型模型。简化的螺旋模型简化的螺旋模型图图1.8 完整的螺旋模型完整的螺旋模型螺旋模型优点优点对可选方案和约束条件的强调有利于对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；量作为软件开发的一个重要目标；减少了过多测试或测试不足；减少了过多测试或测试不足；维护和开发之间并没有本质区别。维护和开发之间并没有本质区别。特点特点风险驱动风险驱动主要适用于内部开发的大规模软件项目主要适用于内部开发的大规模软件项目要有具有丰富风险评估专门知识的开发要有具有丰富风险评估专门知识的开发人员，否则风险更大。人员，否则风险更大。5.面向对象模型可重用部件组装模型可重用部件组装模型 (构件集成模型）构件集成模型）（Component Integration Model)基于构件的软件工程基于构件的软件工程(CBSE)(CBSE)过程模型过程模型 构构 件件 开开 发发分析分析 设计设计 编程编程 测试测试领域分析领域分析系统系统测试测试构件提交构件提交领域专家经验领域专家经验现有系统资料现有系统资料领域构领域构件需求件需求构件构件/构架库构架库领域构架领域构架领领域域构构件件系统系统开发开发系统专用构件系统专用构件应用应用系统系统构件生产线构件生产线领域构架领域构架领域构件领域构件问题域问题域用户需求用户需求系统生产线系统生产线 系系 统统 组组 装装 分析分析 设计设计 编程编程构架细化构架细化专专 用用 构构 件件 开开 发发分析分析 设计设计 编程编程 测试测试 软软 件件 生生 产产 线线应用构件应用构件提取车间提取车间构件生构件生产车间产车间标准规范标准规范 与与 质量保证质量保证1 1基础构件，基础构件，2 2功能构件功能构件 3 3接口构件，接口构件，4 4用户界面构件用户界面构件 应用应用构件库构件库 构件库构件库组装组装车间车间领域领域 1 1领域领域 2 2应用应用系统系统 .1 12 23 34 4
