第1部分 软件工程概述.ppt

1、第1部分 软件工程概述,学习目标,了解软件危机产生的背景 掌握软件工程的概念及其研究内容 熟悉软件工程过程和软件生存周期,软件危机的产生,软件的定义与特点 软件的发展历史 软件危机的现象和原因,软件的定义与特点,软件的定义,软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。 Software = Program + Data + Document,软件的特点,软件是逻辑的，而不是物理的产品。 逻辑往往实际只存在于人的头脑当中，软件人员好比“皇帝的新衣”故事中的裁缝，软件的开发过

2、程极难加以控制。 软件是由开发或工程化而形成的，没有明显的制造过程。 软件成本集中于“开发上，意味着软件项目不能象硬件制造项目那样来管理。,软件在运行和使用期间，不存在硬件那样的磨损和老化问题，但它存在退化问题，开发人员必须维护软件。,磨合调整,磨损用坏,修改点,实际曲线,理想曲线,大多数软件是自定的，而不是通过已有构件组装而成的。 迄今为止，软件的开发尚未完全摆脱手工的方式。 软件成本相当昂贵。 IBM360操作系统的研制人员最多时可达1000多人，从1963年到1966年共花了四年时间才完成，总计耗费5000多人年，以后又进行不断的修改和补充。该系统的整个研制费用为5亿美元，其中近一半花在

3、软件上。 微软开发windows XP开发花费超过了制造一架波音飞机的成本,软件本身是复杂的。 微软开发windows NT4.0发布时源程序的代码超过40,000,000行.,软件的发展历史,早期 面向批处理 有限的分布 自定义软件,第二阶段 多用户 实时 数据库 软件产品,第三阶段 分布式系统 嵌入“智能” 低成本硬件 消费者的影响,第四阶段 强大的桌面系统 面向对象技术 专家系统 人工神经网络 并行计算 网路计算机,1960,1970,1980,1990,2000,早期阶段 用途:科学计算 程序的质量完全依赖于程序员个人的技巧. 第二阶段 多用户引入了人机交互的新概念 实时系统 使进程的

4、控制和输出以毫秒而不是分钟来计算 在线存储的发展产生了第一代数据库管理系统,第三阶段 始于70年代中期,分布式、网络的发展极大地提高了计算机系统的复杂性。 软件工作量估计COCOMO模型、软件过程改进模型CMM等 第四阶段 强大的桌面系统和计算机网络迅速发展时期，计算机体系结构由中央主机控制为客户机/服务器方式 面向对象技术在许多领域迅速取代了传统软件开发方法,软件发展的根本变化,人们改变了对软件的看法 个人化程序 工程化产品 软件=程序 软件=程序+数据+文档 软件的需求是软件发展的动力 自给自足 市场流通以满足用户的需要 软件工作的考虑范围发生根本变化 只顾及程序的编写 涉及整个软件生存周

5、期 软件质量的概念发生变化 单纯的产品质量 产品质量+过程质量,软件危机的现象和原因,软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 如何开发软件，以满足不断增长，日趋复杂的需求； 如何维护数量不断膨胀的软件产品。,软件危机主要表现,（1）对软件开发成本和进度的估计常常不准确。开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。 （2）用户对“已完成”系统不满意的现象经常发生。 （3）软件产品的质量往往靠不住。Bug一大堆，Patch一个接一个。 （4）软件的可维护程度非常之低。,软件危机主要表现,（5）软件通常没有适当的文档资料。 （6）软件的成本不断提高。 （7

6、）软件开发生产率的提高赶不上硬件的发展和人们需求的增长。,软件危机的原因,软件本身的特点有关 软件开发和维护的方法不正确有关 忽视软件开发前期的需求分析； 忽视测试阶段的工作，提交用户的软件质量差； 在1985年到1987年之间，至少有2个病人是死于Therac-25医疗线性加速器的过量辐射，其原因是控制软件中的一个故障。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分出于控制系统的故障，一个小小的疏漏往往会造成上千万美元的损失。 轻视软件的维护。,开发过程没有统一的、规范的方法论的指导，文档资料不齐全，忽视人与人的交流； 60%70%的错误都是规格说明和设计错误 无人太空计划

7、软件统计结果 平均每页规格说明文档有大概1.9 个错误 每页设计文档有大概0.9个错误 每页代码只有约0.3个错误 Bhandari et al. 1994等报告中给出了一组新的数据 只有13%的错误是从编译器的前一个版本带来的 16%的错误是在规格说明阶段产生的 71%是在设计阶段产生的 提高规格说明和设计技术非常重要。减少10%的规格说明和设计错误，就意味着减少整个错误数的6%-7%,消除软件危机的途径,对计算机软件有一个正确的认识 (软件程序） 必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。 推广使用在实践中总结出

8、来的开发软件的成功技术和方法。 开发和使用更好的软件工具。,软件工程的概念 软件工程方法学,软件工程的概念,“软件工程”,-Software Engineering,于1968年 NATO 组织在 德国召开的一次会议上提出,软件工程是开发、运行、维护和修复软件的系统方法。,是为了经济地获得能够在实际机器上高效运行的 可靠软件而建立和使用的一系列好的工程化原则。,强调软件工程是系统方法而不是神秘的个人技巧,软件工程学是为了在成本限额以内按时完成开发和 修改软件产品所需要的系统生产和维护技术及管理 学科。,软件工程的目标是在成本限额内按时完成开发修改软件的工作，同时指出软件工程包含技术和管理两方面

9、的内容。,软件工程的目标是经济地开发出高质量的软件，而且强调软件工程是一门工程学科，应该建立并使用完善的工程化原则。,1983年，IEEE（Institute of Electrical & Electronic Engineers，电气与电子工程师协会）给出了一个更为全面的定义： 研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。 基本思想都是强调在软件开发过程中应用工程化原则，解决软件的整体质量较低、最后期限和费用没有保证等问题。,水利工程,建筑工程,机械工程, ,软件工程,传统工程,新兴工程,气象工程,生物工程,工程,工程是对技术（或社会）实体

10、的分析、设计、建造、验证和管理。,华盛顿洲的 1940年 Tacoma Narrows大桥使用了不到3个月,围棋与软件工程的感想,围棋 围棋棋谱拿过来的时候,大师问“后面应该走哪里？” 十个初级爱好者选择的落点散布在棋盘各处 十个职业棋手说的落子点都差不多，甚至包括后面的几步 这就是高手和低手的差别,软件工程 当一个小程序拿过来的时候,项目经理让大家编写 十个中国软件工程师写出来的程序各有“特色”、千差万别，十个印度软件工程师写出来的程序差不多，以至于怀疑是“抄袭”。 项目经理也不清楚中国软件业和印度软件业的差距是多少年 只是觉得差了好远好远,思考： 软件开发是否需要追求风格一致和代码一致 软

11、件开发是否应该抹杀个人的创造性,软件工程方法学,把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（也称范型）。,软件工程方法学,层次化技术，三要素：,软件工程方法,完成软件开发的各项任务的技术方法，回答“怎样做”的问题； 结构化分析与设计方法 面向数据流的方法 面向对象的分析与设计 以对象为最基本元素，按照人类认识世界的方法和思维方式来分析和解决问题。,软件工程过程,为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施以及标志软件开发各个阶段任务完成的里程碑。,

12、软件工程工具,为运用方法而提供的自动的或半自动的软件工程支撑环境； CASE按软件过程的活动来分类，归纳为以下三类： 支持软件开发过程的工具，包括需求分析工具、软件设计工具、编码工具、测试工具和纠错工具等。,支持软件维护的工具，包括版本控制工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具等。 支持软件管理过程和支持过程的工具，主要包括项目管理工具、配置管理工具和软件评价工具等。,软件工程的目标,合理预算开发成本，付出较低的开发费用 实现预期的软件功能，达到较好的软件性能，满足用户的需求 提高所开发软件的可维护性，降低维护费用 提高软件开发生产率，及时交付使用 开发的软件易于移植,对

13、软件工程的认识,如何达到软件工程的目标提高开发质量和生产率？ 过去的认识：技术的发展是达到上述目标的主要或唯一途径； 80年代后期，CASE工具和环境被认为是最好的解决方案，即通过自动化工具的支持可以很容易地提高质量和效率； 90年代，GUI生成技术和OO技术也被寄予厚望； 原因：技术可以给出立即可见的解决方案，并很快得到收益； 结果：经常不尽人意。,对软件工程的认识,技术并不能唯一保证达到预期的目标和效果，开发过程的改善是达到目标的重要因素。过程改善将导致企业组织和管理方式改变，需要高层的承诺和长期的投资。 过程改善+技术提高=完善的解决方案,对软件工程的认识,过程改善与技术提高同等重要 技

14、术提高 软件工程思想已被普遍接受，CASE技术不断发展，工具市场不断扩大，但能有效支持过程改善的工具还不多见 中间件与平台软件的研究与开发受到广泛重视 过程改善 已有若干软件过程模型，出现了企业认证热潮 美国、印度的CMM认证，国际上的ISO9001认证。,对软件工程的认识,两方面的权衡 欧洲委员会（EC）资助的ESSI（Europe Software and System initiative），在SBP（Software Best Practice）计划中对软件企业（或开发单位）进行了调查 问题：为提高质量和效率，最愿意投资于技术还是过程改善？,结果： 大公司（大于500人）绝大部分愿意投

15、资于过程改善 中等公司（50-500人）技术和过程改善投资基本对半 小公司（50人以下）绝大部分愿意投资于技术（购买工具），因为过程改善投资力度大，周期长。比如要通过CMM的2级认证要投入几十万人民币的，而且要长期的投入。,软件工程知识体系,IEEE 2001年提出软件工程的十大知识体系 软件需求 软件设计 软件构造 软件测试 软件维护 软件配置管理 软件工程管理 软件工程过程 软件工程工具和方法 软件质量,软件工程知识体系,软件需求 需求工程过程 需求识别 需求分析 需求规格说明 需求验证 需求管理,软件工程知识体系,软件设计 软件设计的基本概念 软件设计中的关键问题 软件的结构和体系结构

16、软件设计的质量分析和评估 软件设计的表示方法 软件设计的策略和方法,软件工程知识体系,软件构造 基本策略 降低复杂性 多样性 构造的验证 使用外部标准 构造方法 语言 形式化 可视化,软件工程知识体系,软件测试 测试的基本概念和定义 测试的层次 测试的技术 与测试有关的度量 测试过程的管理 软件维护 软件维护的基本概念 软件维护的过程 维护过程中的关键问题 软件维护的技术（比如逆向工程、再工程）,软件工程知识体系,软件配置管理 软件配置过程的管理 软件配置识别 软件配置控制 软件配置状态报告 软件配置审计 软件发布管理和交付 软件工程管理 组织管理 项目管理 软件工程度量,软件工程知识体系,软

17、件工程过程 软件工程过程的概念 软件过程结构 过程度量 过程定义 量化过程分析 过程实施和改进,软件工程知识体系,软件工程的工具和方法 软件工程工具 软件工程方法 软件质量 软件质量的概念 质量定义和计划 缺陷管理 质量评价,软件工程的主要研究内容,软件开发技术和软件项目管理。 软件开发技术包括： 软件开发方法学 开发软件的规范化方法 软件工具 指能支持软件生存周期中某一阶段（如系统定义、需求分析、设计等）的需要而使用的软件系统； 软件过程 软件项目管理包括： 软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等。,软件工程过程和软件生存周期,软件生命周期模型 瀑布模型 原型模型 增量

18、模型 螺旋模型 跌代模型 喷泉模型 RUP（统一软件过程）模型,软件生存周期,软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。 软件定义 问题定义 可行性研究 需求分析,软件开发 概要设计 详细设计 编码和单元测试 综合测试 运行维护,软件生命周期模型,规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称过程模型。,建造修补模型,对于100或200行长的短程序可以做得很好 问题 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改 忽略需求环节，给软件开发带来很大风险,没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难,瀑布模

19、型,20世纪80年代初，唯一被广泛接受的生命周期模型 特点 阶段间具有顺序性和依赖性 推迟实现的观点 质量保证的观点 每个阶段都必须完成规定的文档 每个阶段结束前都要对所完成的文档进行评审,瀑布模型的应用范围,缺点 开发过程一般不能逆转，否则代价太大 规格说明很难理解 软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心 瀑布模型的应用范围 用户的需求非常清楚全面，且在开发过程中没有或很少变化 开发人员对软件的应用领域很熟悉 用户的使用环境非常稳定 开发工作对用户参与的要求很低,不断地重复瀑布式的过程被称为跌代模型。当然，并不是在每次跌代中都包括瀑布模型中的所有阶段。,快速原

20、型开发模型,用户测试 运行原型,建造/修改 原型,听取用 户意见,“快速原型”：一个与产品子集功能上相同的工作模型 建立快速原型生命周期的第一步是建造一个快速原型，并让客户和未来的用户试用快速原型,快速原型开发模型,瀑布模型和快速原型模型,瀑布模型 许多成功的例子 但存在最大缺点：交付给客户的产品可能不是客户真正需要的 快速原型模型 没有被证明是否毫无问题 解决方案 将两种方法结合起来 快速原型可以用作需求分析技术 剩余阶段的开发遵循瀑布模型,原型模型的特点和应用范围,原型模型的特点 可以得到比较良好的需求定义，容易适应需求的变化 有利于开发与培训的同步 开发费用低、开发周期短、维护容易且对用

21、户更友好 客户与开发者对原型理解不同 准确的原型设计比较困难 不利于开发人员的创新,原型模型的特点和应用范围,原型模型的应用范围 对所开发的领域比较熟悉而且有快速的原型开发工具 项目招投标时，可以以原型模型作为软件的开发模型 进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的,增量模型,产品是以一系列增量构件的形式设计、实现、集成和测试的 其中每个构件由一些代码块组成，这些代码块来自多个相互作用的模块，完成特定的功能,对每个构件： 详细设计、实现、集成、测试和交付,例：用增量模型开发字处理软件 第一个增量构件提供基本的文件管理、编辑和文档生成功能； 第二个增量构件提供

22、更完善的编辑和文挡生成功能；第三个增量构件实现拼写和语法检查功能； 第四个增量构件完成高级的页面排版功能,增量模型优点,瀑布模型和快速原型模型的目标 交付给客户一个完整的、可用的产品 增量模型的优点 每个阶段交付一个可用的产品 减少一个全新产品给客户带来的心理上的影响 分阶段地交付产品不需要大的资金支出 需求经常变化，增量模型的灵活性使其具有更加优越的适用性,增量模型缺点,增量模型的困难 需要一个开放的结构，方便构件的加入 可能会退化为建造-修补方法 增量模型本身就是一个矛盾的名词 增量模型的变种适合用于面向对象生命周期,风险更大的增量模型,螺旋模型,1988年，Barry Boehm正式发表

23、了软件系统开发的螺旋模型，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析 简化版本 瀑布模型+风险分析 每个阶段之前 确定目标，可供选择的办法及其限制条件 风险分析 每个阶段之后 评估 计划下一阶段,简化的螺旋模型,假如某阶段风险不能排除，那么停止项目,完整的螺旋模型,优点 容易确定什么时候已经对某一阶段的产品充分测试完毕 维护和开发之间没有什么本质上的差别 缺点 仅适合于大型软件的内部开发 仅适合于大型软件 风险驱动既是优点也是缺点,几种常见模型的优缺点,V模型,跌代模型,跌代软件开发模型的一个额外的优点是能够在每次跌代中都收集到过程中产生的各种度量数据。 例如：在第一次

24、跌代时记录下小组进行设计和实现所花费的时间，依此即可以改进对后续设计和实现花费时间的估计方法。,当跌代的速度加快，每次跌代只是在前一次的基础上增加少量功能的时候，我们称这种跌代过程为增量开发过程。,面向对象的生命周期模型,对软件过程阶段之间或阶段各部分之间有更多的迭代需求 喷泉模型 递归/并行生命周期 (Recursive/parallel life cycle) 往返式格式塔设计(Round-trip gestalt) 统一软件开发过程(Unified software development process，RUP) 所有这些模型都是 迭代的 并行性 增量开发,喷泉模型(Fountain

25、Model),特性 交叠(并行性) 箭头(迭代) 维护圆圈较小,RUP迭代模型,项目管理,环境,业务建摸,实现,测试,分析与设计,初始迭代(s),迭代1,阶段,过程工作流,迭代,支持工作流,迭代2,迭代n,迭代n+1,迭代n+2,迭代m,迭代m+1,部署,配置与变化管理,需求,精化,过渡,开始,构造,软件开发中的人员角色,对软件工程的一些认识,关于猴子的故事,有这样一个笑话：一个旅客走进硅谷一家宠物店，浏览展示的宠物。这时，走进一个顾客，对店主说：“我要买一只C猴。”店主点了点头，走到商店一头的兽笼边，抓出一只猴，递给顾客说：“总共5000美元。” 顾客付完款，然后带走了他的猴子。 这位旅客非

26、常惊讶，走到店主跟前说：“那只猴子也太贵了！” 店主说：“那只猴子能用C编程，非常快，代码紧凑高效，所以值那么多钱。” 这时，旅客看到了笼子中的另一只猴子，它标价10000美元。于是又问：“那只更贵！它能做什么？”,关于猴子的故事,店主回答：“喔，那是一只C+猴；它会面向对象的编程，会用visual C+，还懂得一点Java,是非常有用的。” 旅客又逛了一会儿，发现了第三只猴子，它独占一个笼子，脖子上的标价是50000美元，旅客倒抽一口气，问道：那只猴子比其他所有猴子加起来都贵！它究竟能做什么？“ 店主说：”我们也不知道它究竟能做什么，不过它是做项目顾问出身的。“ 虽然这只是一个笑话，但是有一点是可以肯定的，项目管理是非常重要的，而项目管理的人才又是极为缺乏的。,关于软件的错误观点（1）,我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。 好的参考书无疑能指导我们的软件开发，但真正的软件工程是从实践中得来的，并不依赖于