deng-第一章软件工程概述

软件工程导论

邓娜计算机学院

1/70课程介绍及要求用工程化的方法来开发软件2/84教学目标为什么要学习这门课程有助于正确理解和认识“软件”的概念及其特点理解软件开发面临的问题和挑战掌握软件工程的原则、方法和思想来系统地开发软件，尤其是复杂、庞大的软件的开发了解和接触软件开发所需的各种技术手段理解、掌握和运用3/84理解什么是软件工程为什么需要软件工程(产生背景)软件工程需要解决那些问题软件工程涉及那些方面内容4/84掌握软件工程概念技术过程手段工具5/84运用运用工程化思想进行软件开发需求分析软件设计程序设计软件维护6/84先导要求程序设计语言最好有一定的软件开发经验7/84学习要求听理解知识点和思想无需死记硬背做实践体会软件工程的原则、方法和技术，在实践中提高培养抽象思维能力培养独立解决问题的能力培养合作精神想阅读相关资料8/84考核方式考试(60%)课程设计(30%)考勤(10%)9/84课程设计(1/2)内容选择一个项目开发课题，用软件工程的思想知道其开发过程。完成需求分析，详细设计，测试，项目汇报。分组以小组为单位，6—8人一组为宜时间平时可以分组着手准备和进行，期末考试前要交，具体时间待定10/84课程实习要求(2/2)提交内容课程设计纸质文档，装入文件袋评价方法文档:完整性、合理性、规范性11/84教材和课件教材薛继伟高等学校“十二五”规划教材•计算机软件工程系列:软件工程导论，第1版哈尔滨工业大学出版社课件下载公共邮箱（还未申请）12/84参考文献软件工程导论（第五版），张海藩，清华大学出版社软件工程实践导论--有关方法、设计、实现、管理之三十六计，金尊和，清华大学出版社，2005.软件开发的科学与艺术，微软亚洲研究院，电子工业出版社，2002

年

软件工程－实践者的研究方法，RS.Pressman,机械工业出版社现代软件工程,周之英编著,科学出版社13/84参考书籍14/84第1章软件工程概述软件工程产生的背景(软件危机)软件工程定义软件工程方法学软件过程模型软件工程知识体系软件工程师道德规范小结15/841.1软件工程产生的背景软件

a.软件的定义软件（

Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program）

，数据（Data）及其相关文档（Document）的完整集合。Software=Program+Data+Document程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料16/84非常复杂逻辑复杂远远高于硬件的逻辑复杂度开发复杂成本难以估算进度难以控制人员素质要求质量得不到保证1.1软件工程产生的背景

b、软件的特征17/84成本高1.1软件工程产生的背景

b、软件的特征18/84风险大1995年美国Standish咨询集团的统计分析(至90年代初的软件项目执行情况)成功：16.2%失败：31％受到挑战：53.8%近几年来的统计数据成功：26％失败：28％受到挑战：46%1.1软件工程产生的背景

b、软件的特征19/84维护困难维护形式多样化改正性：修改故障完善性：增加功能适应性：移植维护成本越来越高55%到70％维护带来的问题1.1软件工程产生的背景

b、软件的特征20/841.1软件工程产生的背景c.软件的发展早期面向批处理有限的分布自定义软件第二阶段多用户实时数据库软件产品第三阶段分布式系统嵌入“智能”低成本硬件消费者的影响第四阶段强大的桌面系统面向对象技术专家系统人工神经网络并行计算网路计算机1950196019701980199020001968年10月，北大西洋公约组织（NATO）的科学家在德国召开的学术会议上正式提出了软件危机问题。21/84

软件危机1963年美国飞往火星的火箭爆炸，造成1000万美元的损失。原因是FORTRAN程序：

DO5Ⅰ=1，3

误写成：DO5Ⅰ=1.31967年苏联“联盟一号”载人宇宙飞船在返航时，由于软件忽略一个小数点，在进入大气层时因打不开降落伞而烧毁。22/84美国IBM公司在1963年至1966年开发的IBM360机的操作系统。5000人-年的工作量，1000人投入，近100万行源程序。每次发行的新版本都是从前一版本中找1000个程序错误，项目负责人F.D.Brook总结时说：“正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难。”

软件危机23/841.1软件工程产生的背景2)软件危机a、软件危机的表现（1/3）

成本高IBM360OS,5000多人年，耗时4年(1963－1966)，花费2亿多美元美国空军：1955年软件占总费用(计算机系统)的18%，70年60%，85年达到85％美国全球军事指挥控制系统，硬件1亿美元，软件高达7.2亿美元计算机软件和硬件费用比24/84软件质量得不到保证软件应用面的扩大：科学计算、军事、航空航天、工业控制、企业管理、办公、家庭软件越来越多的应用于安全攸关(safetycritical)的系统，对软件质量提出更高的要求80年代欧洲亚丽安娜火箭的发射失败，原因是软件错误美国阿托拉斯火箭的发射失败，原因是软件故障英国1986年开发的办公室信息系统Folios经4年，因性能达不到要求，1989年取消日本第5代机因为软件问题在投入50亿美元后于1993年下马由于软件质量问题导致失败的软件项目非常多a、软件危机的表现（2/3）25/84a、软件危机的表现（3/3）进度难以控制项目延期比比皆是由于进度问题而取消的软件项目较常见只有一小部分的项目能够按期完成维护非常困难软件维护的多样性软件维护的复杂性软件维护的副作用26/84软件危机主要有以下表现：对软件开发成本和进度的估计常常不准确。开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。用户对“已完成”系统不满意的现象经常发生。软件产品的质量往往靠不住。Bug一大堆，Patch一个接一个。软件的可维护程度非常之低。软件通常没有适当的文档资料。软件的成本不断提高。软件开发生产率的提高赶不上硬件的发展和人们需求的增长。27/84b、产生软件危机的原因与软件本身的特点有关(难于维护,逻辑复杂)与软件开发与维护的方法不正确有关:软件≠程序急于求成=拔苗助长各自为阵无方法/学28/84引入同一变化付出的代价随时间变化的趋势29/84消除软件危机的途径对计算机软件有一个正确的认识

(软件≠程序）必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。非个人英雄主义推广使用在实践中总结出来的开发软件的成功技术和方法。开发和使用更好的软件工具。30/84开发一个具有一定规模和复杂性的软件系统与编写一个简单的程序不一样正如建设狗窝和高楼大厦大型、复杂软件系统的开发是一项工程，必须按照工程化的方法组织软件的生产和管理，必须经过分析、设计、实现、测试、维护等一系列软件过程和活动C、软件工程（学）因危机而产生31/84软件工程工程工程是对技术（或社会）实体的分析、设计、建造、验证和管理。……水利工程建筑工程机械工程软件工程传统工程新兴工程气象工程生物工程32/84软件工程----SoftwareEngineering于1968年NATO组织在德国召开的一次会议上提出是把软件当作一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护”。33/84围棋与软件工程的感想围棋围棋棋谱拿过来的时候,大师问“后面应该走哪里？”十个初级爱好者选择的落点散布在棋盘各处……

十个职业棋手说的落子点都差不多，甚至包括后面的几步……

这就是高手和低手的差别……软件工程当一个小程序拿过来的时候,项目经理让大家编写……

十个中国软件工程师写出来的程序各有“特色”、千差万别，十个印度软件工程师写出来的程序差不多，以至于怀疑是“抄袭”。项目经理也不清楚中国软件业和印度软件业的差距是多少年只是觉得差了好远好远……34/84d、软件工程(学):克服软件危机的努力

（1）从管理的角度

软件开发过程的研究、文档的标准化以及人们

的交流方式等（2）软件开发方法的研究

结构化软件开发方法,面向对象的开发35/84提出有效的方法和工具支持软件开发1968年提出软件工程概念和思想20世纪70年代的结构化软件开发方法20世纪80年代的面向对象的软件开发方法新的技术:软件重用、快速原型、需求工程典型技术:COM,Java,C++,J2EE,.Net,….支撑工具和环境：Jbuilder,VisualStudio,WebLogic,…1、解决危机的技术途径36/8420世纪80年代末，美国国防部DoD和工业界开始认识到管理的重要性美国DoD的一项研究表明，70%的项目由于管理不善导致难以控制进步、成本和质量；进一步的研究发现：管理是影响软件项目成功开发的全局性因素，而技术只影响局部如果软件开发组织不能对软件项目进行有效管理，就不能充分发挥软件开发方法和工具的潜力，也就不能高效率地开发出高质量的软件产品2、解决危机的管理途径37/841.2软件工程定义(1)Theestablishmentanduseofsoundengineeringprinciples(methods)inordertoobtaineconomicallysoftwarethatisreliableandworksonrealmachines.(1968-FritzBauer)

软件工程就是建立和使用一套合理的工程原理，从而经济地获得可靠的、可以在实际机器上高效运行的软件。38/841.2软件工程定义(2)Softwareengineering.(1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)Thestudyofapproachesasin(1).(IEEE(TheInstituteforElectricalandElectronicengineers)Std610-1990.）

软件工程是：（1）把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；（2）研究（1）中提到的途径。39/841.2软件工程定义(3)

Engineeringisthe

systematicapplicationofscientificknowledge

increatingandbuildingcost-effectivesolutionstopracticalproblemsintheserviceofmankind.

Softwareengineeringisthat

formofengineering

thatappliestheprinciplesofcomputerscienceandmathematics

toachievingcost-effectivesolutionstosoftwareproblems.SEIsoftwareengineeringdefinitionfrom1990SEIReportonUndergraduateSoftwareEngineeringEducation(卡耐基梅隆大学在本科生软件工程教育的报告):40/841.2软件工程定义总之：软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。41/84软件工程是一门交叉学科软件工程的主要研究内容软件开发技术:软件开发方法学软件开发过程软件工具和软件工程环境软件工程管理:软件管理学软件经济学软件心理学42/84软件工程与一般工程的差异软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件设计的复杂性软件特征：功能的多样性实现的多样性能见度低软件结构合理性差智力密集及知识产权保护43/84软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。在软件工程领域中，这两个术语的含义基本相同。软件工程方法学包含3个要素：方法、工具和过程。1.3软件工程方法学44/841.3软件工程方法学软件工程：一种层次化技术质量关注点过程方法工具

软件工程层次图软件工程三个要素：工具、方法、过程基础层，综合方法及工具，定义方法使用的顺序，所需要的管理为软件开发提供“如何做”的技术为软件开发提供自动或半自动的软件支撑环境，建立计算机辅助软件工程(CASE)的软件开发支撑系统45/841.4软件生命周期模型问题定义软件定义可行性研究

需求分析

总体设计详细设计软件生命周期软件开发编码单元测试综合测试运行维护

持久满足用户需求46/841.4软件过程模型软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。AprocessdefinesWhoisdoingWhat,When,andHow,inordertoreachacertaingoal.公共过程框架辅助活动任务集合软件过程47/841.4软件过程模型

软件生命周期的每一阶段都有明确的任务，把规模大、结构复杂、管理复杂的软件开发变得容易控制和管理。各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架（忽略不必要的细节）用一种模型表示出来，称为软件过程模型（或软件开发模型或软件生命周期模型）。

也就是说，

软件过程模型是软件开发全部过程、活动和任务的结构框架。48/841.4软件过程模型（1）瀑布模型(WaterfallModel）

传统瀑布模型瀑布模型也称为线性顺序模型,在20世纪80年代以前，瀑布模型一直是唯一被广泛采用的生命周期模型49/841.4软件过程模型传统瀑布模型的特点提供了软件过程模型的基本框架（模板）。强调了每一阶段活动的严格顺序。质量保证观点：以经过评审确认了的阶段工作产品（文档）驱动下一阶段的工作，便于管理。是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。

传统瀑布模型存在什么问题？50/841.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的错误。而设计上的缺陷或错误可能在实现过程中显现出来。在综合测试阶段将发现需求分析、设计或编码阶段的许多错误传统化（理想化）瀑布模型的缺点51/841.4软件过程模型实际的瀑布模型52/841.4软件过程模型瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。可强迫开发人员采用规范的方法严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行；用户常常难以清楚地给出所有需求；用户必须有耐心，等到系统开发完成。

瀑布模型的优缺点53/841.4软件过程模型（2）原型模型—快速原型模型（RapidPrototypeModel）在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。建造/修改原型

听取用户意见用户测试运行原型原型实现范型54/841.4软件过程模型快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程55/841.4软件过程模型原型模型存在的问题

⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。

⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。

⑶开发过程不便于管理。有效的使用原型模式建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。56/841.4软件过程模型（3）增量模型(IncrementalModel)是一种渐进地开发逐步完善的软件版本的模型。需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户57/841.4软件过程模型分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2增量3增量4交付交付交付交付●●●●●

•

反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个“增量”的发布或提交，该增量均是一个可运行的产品。

•

早期的版本实现用户的基本需求，并提供给用户评估的平台。增量模型58/841.4软件过程模型在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。增量模型的优点59/841.4软件过程模型增量模型的困难在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。多个构件并行开发，具有无法集成的风险。60/84增量模型适用的情况客户能够接受分阶段交付工期紧且可分阶段提交或者对目标、环境不熟悉用户可参与到整个软件开发过程中软件开发组织自己应该拥有较好的类库、构件库软件企业开发大型项目时，一般还是采用增量模型，因为可以根据轻重缓急，逐个实现子系统61/84增量模型与瀑布模型、快速原型模型区别：瀑布模型、快速原型模型：一次性地把一个满足所有需求的产品交付给用户增量模型：分批交付VS62/841.4软件过程模型（4）螺旋模型(SpiralModel)

软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。——产品交付给用户后用户可能不满意；——到了预定的交付日期软件可能还未开发出来；——实际的开发成本可能超过预算；——产品完成前一些关键的开发人员“跳槽”了；——产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件等。63/841.4软件过程模型（4）螺旋模型(SpiralModel)

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了风险分析。在该模型中，软件开发是一系列的增量发布，早期的迭代中，发布的增量可能是一个纸上的模型或原型，在以后的迭代中，逐步产生系统更加完善的版本。螺旋模型的基本思想是降低风险。64/841.4软件过程模型快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证风险分析风险分析风险分析风险分析风险分析风险分析可看作在每个阶段之前都增加了风险分析过程的快速原型模型。简化的螺旋模型65/84

66/84每一次迭代都包含以下步骤：

1.决定目标、替代方案和约束2.识别和解决项目的风险3.评估技术方案和替代解决方案4.开发本次迭代的交付物和验证迭代产出的正确性5.计划下一次迭代6.提交下一次迭代的步骤和方案67/841.4软件过程模型螺旋模型的优点对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别68/84螺旋模型的缺点风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大要求用户参与阶段评估过多的迭代次数增加了开发成本，延迟了提交时间69/84螺旋模型适用的情况内部开发的大规模软件项目：方便中止但是如果风险分析费用接近整个项目的预算，则风险分析是不可行的不确定因素很多，很多东西开始无法计划的情况70/841.4软件过程模型（5）喷泉模型(FountainModel)特点：主要用于支持面向对象开发过程，体现了面向对象方法所固有的迭代和无间隙的特征71/84认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限

72/84喷泉模型的特点规定了五个阶段：分析、设计、实现、维护和演化高层到底层无资源消耗资源消耗呈塔状，在分析阶段消耗最多资源各阶段的重叠反映了软件过程的并行性增量开发，是迭代的逐步提炼的过程73/84四种模型的总结：瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法；这种模型的问题是，最终开发出的软件产品可能并不是用户真正需要的。快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建起一个可在计算机上运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点，但是，要求软件具有开放的结构是使用这种模型时固有的困难。风险驱动的螺旋模型适用于内部开发的大型软件项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。741.4软件过程模型（6）可重用部件组装模型(构件集成模型)

(ComponentIntegrationModel)

构件（components)也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件集成起来协调工作。该模型支持软件重用（Reusability）

，对缩短软件开发周期、降低项目成本有重要的现实意义。构件集成模型如下图所示：75/84

构件集成模型软件体系结构被建立后，必须用构件去充实，这些构件可从复用库中获得，或者根据专门需要而开发。76/84软件工程知识体系指南（2004版）

GuidetotheSoftwareEngineeringBodyofKnowledge2004Version