软件工程学概述

SchoolofComputerEngineering，HuaihaiInstituteofTechnology软件工程SoftwareEngineering淮海工学院计算机工程学院软件工程系

樊宁计算机楼409TEL:85892393E-MAIL:angelafn66@163.com教材、参考书教材《软件工程导论》，张海藩编著，清华大学出版社，2008.2《软件工程导论学习辅导》，张海藩编著，清华大学出版社，2008.9参考书《软件工程》，齐治昌谭庆平宁洪编著，高等教育出版社。《软件工程自考应试指导》，刘海岩等编著，南京大学出版社。《软件工程学实验》，周苏等编著，科学出版社，2005.4《软件工程（英文版·第7版）》，IanSommerville,机械工业出版社，2004.11软件工程课程说明软件工程涉及：软件生命周期(定义、设计、编码、测试、发布、维护、淘汰)各阶段的任务与内容软件开发生产中有关工艺、模式、方法和工具的管理与技术问题软件工程不涉及：程序语言的内容软件编程软件工程着力于解决软件危机，即软件经常不能按时按质地交付使用与其它软件专业课的区别(1)立足于系统的整体。(2)讲授系统分析、系统设计、测试及维护的理论和方法。(3)构筑一个软件系统，实践软件开发全过程。

“软件工程”课程教学与实践的目标

转变对软件开发的认识：上升程序系统转变思维定式：上升程序员系统工程师(系统分析员)

工程化训练软件工程与一般工程的差异软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件设计的复杂性软件特征：功能的多样性实现的多样性能见度低软件结构合理性差智力密集及知识产权保护内容安排第一章软件工程学概述第二章可行性研究第三章需求分析第四章总体设计第五章详细设计第六章实现第七章测试第八章维护第九章面向对象方法学引论第十章面向对象分析第十一章面向对象设计第十二章面向对象实现第十三章软件项目管理第一章软件工程学概述学习目标了解软件产生软件危机的原因和消除软件危机的途径；掌握软件生命周期的概念与生命周期中各阶段划分；熟练掌握软件过程模型或生命周期模型中典型的几个模型——瀑布模型、原型模型、增量模型和螺旋模型、喷泉模型。了解目前比较流行的Rational统一过程、以极限编程为杰出代表的敏捷过程以及微软过程。软件工程发展的大事记1968.10NATO在德国南部的Gamisch会议上首次提出“软件工程”1976IEEE成立标准委员会，“软件工程”成为计算机科学专业的一门课程1987ISO/IEC成立标准委员会，“软件工程”成为一个专业1993IEEECS/ACM成立联合委员会1998美国德州首次发布“软件工程师”执照;开始执行软件工程知识体项目软件是程序及其有关的文件与数据的集合。软件的开发周期大大长于生产周期。软件不像硬件一样会磨损，但会过时。软件很容易复制，因此具有复杂的知识产权问题。软件是计算机系统产品的灵魂。随着计算机系统的普及，软件的复杂性与重要性与日俱增。软件的特点软件与硬件产品的故障率时间时间故障率使用初期磨损期理想曲线实际曲线修改硬件故障率分布曲线软件故障率分布曲线软件应用领域系统软件操作系统编译器编辑器应用软件企业管理教育应用

实时软件系统控制嵌入软件

个人计算机软件所有用于个人计算机的软件科学与工程计算仿真计算机辅助设计人工智能专家系统人工神经网络软件应用于所有需要人类智能的领域类别参加人员数研制期限源程序行数微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～51～2年5k～50k大型5～202～3年50k～100k甚大型100～10004～5年1M(=1000k)极大型2000～50005～10年1M～10M 按软件规模进行划分：软件的发展19501960197019801990第一代第二代第三代第四代批处理分发量小专用软件多用户实时性数据库商品软件C/S结构开发工具分布式系统嵌入式数据仓库面向对象网络环境合作开发分布计算并行计算软件发展趋势并行计算提高计算速度面向对象的软件开发方法软件框架（frameworks）用于处理大型软件系统图形接口越来越强人工智能和神经网络技术高级程序设计语言专用工具软件开放资源软件(OpenSourceSoftware)第1章软件工程学概述1.1

软件危机软件危机的出现：60年代中期到70年代中期，许多软件最终成为不可维护的，这就是软件危机.软件工程就是为解决软件危机问题而出现的。1968年，正式提出并使用“软件工程”的概念。1.1.1什么是软件危机？对软件开发成本和进度的估计常常很不准确。用户对为他们开发的软件往往不满意。软件产品的质量往往靠不住。软件常常是不可维护的。软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。包括：软件通常没有适当的文档资料。软件成本在计算机系统总成本中所占的比例逐年上升。软件开发生产率提高的速度太慢。以上的这些问题能够解决吗?1.1.1什么是软件危机？1.1.2产生软件危机的原因不能用象硬件替换部件的方式修复软件的故障软件质量是一个牵涉到人的因素的问题软件项目管理者往往没有软件开发的经验软件开发者往往没有经过正规的工程训练编程人员不愿意将软件开发的艺术过程转化为工程过程•Windows95有1000万行代码•

Windows2000有5000万行代码，3000多个工程师，几百个小团队。•Exchange2000和Windows2000开发人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人例对软件的常见误解用户的误解开发人员的误解管理者的误解误解先对软件需求做一般的说明，以后再逐步明确就可以了.需求本身就是不断变化的，软件容易改变可以很快调整适应这种变化.现实软件需求不明确是造成软件开发费用增加和延时交货的主要原因.软件开发费用随着开发阶段的后移而大大增加.1x1.5-6x60-100x软件开发费用设计阶段开发阶段维护阶段用户的误解开发人员的误解误解一旦程序开发完毕工作正常，我的任务就完成了在程序工作之前，无法顾及软件的质量问题.对于一个成功的项目来说，唯一能够提供的就是可以工作的程序.现实一个软件的50%-70%的工作量耗在软件交付使用以后.对于某些错误,软件审查比软件测试更加有效.一个完整的软件要包括程序、各种文件和各种数据.管理者的误解误解书上已经有各种软件开发的标准，拿来用就是了.已经有足够的软件开发工具可供使用.一旦项目的程序员不够可以随时增加.现实书上是有各种软件开发的标准，但不是过时就是不适用.软件工具不是一拿来就能用的.“项目后期增加程序员会使项目的完成更加推后."--Brooks1.1.3解决软件危机的途径推广使用在实践中总结出来的开发软件的成功的技术和方法。开发和使用更好的软件工具。总之，为了解决软件危机，既要有技术措施，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究更好地开发和维护计算机软件地一门新兴学科。1.2软件工程IEEEstd610.12定义为:应用一种系统的、科学严格的、定量的方法来开发、运行和维护软件;也就是说将工程的方法用于开发软件.Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料.FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法.1.2.1软件工程的本质特性关注大型程序的构造中心问题是控制复杂性软件经常变化开发效率非常重要和谐地合作是开发软件的关键有效地支持它的用户具有一种文化背景的人替另一种文化背景的人创造产品1.2.2软件工程的基本原理用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚地审查开发小组成员应少而精承认不断改进软件工程实践的必要性软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。在软件工程领域中，这两个术语的含义基本相同。1.2.3软件工程方法学1.2.3软件工程方法学传统方法学面向对象方法学1.3软件生命周期生命周期方法学从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。软件定义问题定义：要解决的问题是什么？可行性研究：有可行的解决办法吗？需求分析：为解决问题，目标系统必须做什么？软件设计总体设计：概括地说，应如何解决该问题？详细设计：应怎样具体实现这个系统？编码和单元测试：编写代码，测试模块综合测试：通过测试，使软件达到要求软件维护软件维护：通过各种维护活动使系统持久地满足用户地需要1.3软件生命周期软件开发的过程制定开发计划软件项目划分软件需求定义编写软件需求说明制定软件测试计划与方法数据结构与数据字典用户文件软件设计编写软件设计说明制定软件测试计划与方法数据结构与数据字典编码与测试编码软件测试计划与方法生产，销售与维护用户手册维护服务软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。通常使用生命周期模型简洁地描述软件过程。1.4软件过程1.4软件开发模型软件开发模型（又称为软件生命周期模型）—软件项目开发和维护的总体过程思路的框架。它指出了软件开发过程各阶段之间的关系和顺序，是软件开发过程的概括。它为软件开发过程提供原则和方法，并为软件工程管理提供里程碑和进度表。因此，软件开发模型也是软件工程的重要内容。1.4软件开发模型软件开发模型的几种类型：以软件需求完全确定为基础的瀑布模型；在开发初期仅给出基本需求的渐进式模型，如原型模型、螺旋模型、喷泉模型等；以形式化开发方法为基础的变换模型、基于四代技术的模型；基于知识的智能模型等等。在实际开发时，应根据项目的特点和现有的条件选取合适的模型，也可以把几种模型组合起来使用以便充分利用各模型的优点。1.4.1瀑布模型瀑布模型（waterfallmodel）是由W.Royce于1970年提出来的。又称为软件生存周期模型。瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。1.4.1瀑布模型问题定义可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护特点：1.阶段间具有顺序性和依赖性2.推迟实现的观点3.质量保证的观点瀑布模型优点提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。瀑布模型缺点1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。2）在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。3）作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。瀑布模型适应场合瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。1.4.2原型模型原型模型（prototypingmodel）的基本框架是软件开发人员根据用户提出的软件基本需求快速开发一个原型，以便向用户展示软件系统应有的部分或全部功能和性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤。需求的采集和细化快速设计建造原型用户评价原型对原型加工(需求精确化)产品样品(需求确认)开始停止图1-4-2使用原型确定需求的过程快速原型的开发途径有三种：1）仅模拟软件系统的人机界面和人机交互方式。2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见部分，如人机界面、数据的输入方式和输出格式等。原型模型的适应场合原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。1.4.3螺旋模型螺旋模型（spiralmodel）是B.Boehm于1988年提出的。它综合了瀑布模型和原型模型的优点，即将两者结合，并加入了风险分析机制。螺旋模型的基本框架如图1-4-3所示。生命周期计划需求计划风险分析原型1原型2原型3可操作的原型建模模拟评价操作概念软件需求需求确认开发计划组装测试计划风险分析风险分析风险分析软件产品设计设计验证与确认详细设计编码单元测试组装测试验收测试实现成本顺时针为进展方向计划：明确目标、约束条件选择方案风险分析构造原型工程实现用户评价；阶段评审图1-4-3螺旋模型验收测试计划需求精化计划需求评价评审决策实现计划1.4.3螺旋模型螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。1．计划（需求定义）第一周期开始利用需求分析技术理解应用领域，获取初步用户需求，制定项目开发计划（即整个软件生命周期计划）和需求分析计划。经过一个周期后，根据用户和开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发计划。1.4.3螺旋模型2．风险分析根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步分析风险，给出消除或减少风险的途径。此时根据风险分析的结果决策项目是否继续。所以，螺旋模型是一个风险驱动的模型。3．工程实现利用构造的原型进行需求建模或进行系统模拟，…，直至实现软件系统。1.4.3螺旋模型4．用户评价与阶段评审将原型提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等。螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整个软件系统开发完成。螺旋模型的优点支持用户需求的动态变化。这就要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性。也支持软件系统的可维护性，每次维护过程只是沿螺旋模型继续多走一两个周期。原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。螺旋模型的优点螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。螺旋模型的缺点和适应场合缺点：①如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；②使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。开发字处理软件使用增量模型：第一个增量构件往往实现软件的基本需求。第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。1.4.4增量模型图1.5增量模型采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。图1.6风险更大的增量模型1.4.5喷泉模型喷泉模型是近几年提出来的软件生存周期模型。它是以面向对象的软件开发方法为基础，以用户需求为动力，以对象来驱动的模型。维护测试实现设计分析演化图1-4-4喷泉模型喷泉模型的特点1．软件系统可维护性较好；2．各阶段相互重叠，表明了面向对象开发