软件工程 主讲：杜亚军 教授

教材 《软件工程导论（第四版）》,张海藩，清华大学出版社 参考书 《实用软件工程》, 赵池龙, 电子工业出版社 先修课程： 数据结构、数据库原理、操作系统、程序设计语言

参考读物 [人月神话]The Mythical Man-month （Frederick P. Brooks Jr.弗雷德里克.布鲁克斯） 为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。内容来自布鲁克斯在IBM公司 System/360 家族和OS/360中的项目管理经验。 [人件（第2版）]Peopleware（Tom DeMarco & Timothy Lister 汤姆.迪马可，蒂姆.李斯特） 专门讨论了软件开发和维护团队的管理问题，并向人们的传统认识提出了挑战。书中推崇人本管理思想，正确指出知识型企业的核心是人，而不是技术，呼吁给予软件工作者充分的自由和信任。 [最后期限]The Deadline（ Tom DeMarco汤姆.迪马可） 这本项目管理的通俗读物让人读起来回味无穷，爱不释手。《最后期限》是一个创新性与趣味性并重的故事，几乎每章结尾都有非常有效的项目管理实践准则。

第1章 软件工程学概述 1.1 软件危机 1.2 软件工程 1.3 软件生命周期 1.4 软件过程

软件的定义 软件是计算机系统中与硬件相互依存的另一部分，它是包括计算机程序、数据及文档的完整集合。 即软件是: （1） 能够完成预定功能和性能的可执行指令； （2） 使得程序能够适当地操作信息的数据结构； （3）描述程序研制过程、方法及使用的文档。

软件的发展阶段

软件的特点 软件是一种逻辑实体； 软件的生产与硬件不同，它没有明显的制作过程； 软件在运行、使用期间不存在磨损、老化问题； 软件的开发、运行对计算机系统具有依赖性，受计算机系统的限制，这导致了软件移植的问题； 软件复杂性高，成本昂贵； 软件开发涉及诸多的社会因素。

软件复杂性 差距 软件需求 软件技术 时间 软件技术的发展落后于需求

软件的分类 按软件的功能进行划分： 系统软件 支撑软件 应用软件

按软件规模进行划分： 类别 参加人员数 研制期限 源程序行数 微型 1 1～4周 0.5k 小型 1 1～6月 1k～2k 类别 参加人员数 研制期限 源程序行数 微型 1 1～4周 0.5k 小型 1 1～6月 1k～2k 中型 2～5 1～2年 5k～50k 大型 5～20 2～3年 50k～100k 甚大型 100～1000 4～5年 1M(=1000k) 极大型 2000～5000 5～10年 1M～10M

按软件工作方式划分： 实时处理软件 分时软件 交互式软件 批处理软件

按软件服务对象的范围划分： 项目软件：也称定制软件 产品软件：提供给市场

按软件失效的影响进行划分： 高可靠性软件 一般可靠性软件

软件危机 计算机软件发展的三个时期： 早期时代（60年中期以前） 软件作坊（60-70年代） 软件工程 软件技术面临的问题: 复杂性 生产率

Windows2000 项目经理 约250人 开发人员 约1700人 测试人员 约3200人 例:Windows95有1000万行代码

什么是软件危机： 指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 软件危机包括两个方面的问题： 如何开发软件，怎样满足对软件的日益增长的需要。 如何维护数量不断膨胀的已有软件。

软件危机的主要表现：  对软件开发成本和进度估计常常很不准确

 用户对“已完成的”软件系统不满意的现象经常发生。  软件产品的质量往往靠不住。  软件常常是不可维护的。  软件没有适当的文档资料。  软件成本在计算机系统总成本中所占的比重在逐年上升。  软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

产生软件危机的原因： 在软件开发过程中出现的严重问题主要与： 软件本身有关。 软件开发与维护的方法不正确有关。

客观原因：  软件与硬件不同，是逻辑部件。 软件开发过程的进展情况难以衡量。 软件开发的质量也难以评价。 管理与控制软件开发过程相当困难。 修改或改正软件设计等软件维护比较困难。

 软件不同于一般的程序，其规模庞大。 需要多人协作完成，会涉及诸多技术问题，比如：分析方法、设计方法、形式说明方法、版本控制等。 需要严格、科学的管理。

主观原因： 软件开发与维护中长期形成的错误认识与作法。 比如： 忽视软件的需求分析，急于动手编写程序； 轻视软件的维护等。

一些不正确的观念： 观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。 观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。 良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境的是一群庸人，难保他们不干出南辕北辙的事情。 观念之三：如果我们落后于计划，可以增加更多的程序员来解决 观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。

消除软件危机的途径 软件工程 技术措施 组织管理措施 使用更好的软件开发方法和开发工具 建模语言 配置管理工具 缺陷管理工具 自动测试工具 组织良好、管理严密、各类人员协同配合、共同完成 软件工程

作用：摆脱软件危机的一个主要出路 目标：高效开发高质量软件

软件工程的定义 1968年Fritz Bauer在NATO会议上给出的定义：“软件工程是为了经济地获得可靠的和能在实际机器上有效运行的软件，而建立和使用完善的工程原理。 IEEE给出了一个更加综合的定义： “将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。” 本书的定义： 软件工程是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，并把正确的管理技术与当前最好的技术方法结合起来。

软件工程三个要素 软件工程是一种层次化的技术，其中过程、方法和工具是软件工程的三个要素。 （1） 过程定义了技术方法的采用、工程产品（包括模型、文档、数据、报告、表格等）的产生、里程碑的建立、质量的保证和变更的管理。 （3） 软件工程方法为软件开发提供"如何做"的技术，它涵盖了项目计划、需求分析、系统设计、程序实现、测试与维护等一系列的任务。 （4）软件工具为过程和方法提供自动的或半自动的支持。这些软件工具被集成起来，建立起一个支持软件开发的系统，称之为计算机辅助软件工程CASE （ Computer Aided Software Engineering）。CASE集成了软件、硬件和一个存放开发过程信息的软件工程数据库，形成了一个软件工程环境。

软件工程的基本原理：（7条基本原理） 用分阶段的生命周期计划严格管理。 统计表明，50%以上的失败项目是由于计划不周而造成的。 在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。  坚持进行阶段评审。 统计结果显示： 大部分错误是在编码之前造成的，大约占63%; 错误发现得越晚，改正它要付出的代价就越大。

2000 5.0 改正一个问题估计的工作量 改正一个问题的估计费用 1000 2.5 200 0.5 (美元) 20 0.05 (人天) 需 改正一个问题需付出的代价 2000 5.0 改正一个问题估计的工作量 改正一个问题的估计费用 1000 2.5 200 0.5 (美元) 20 0.05 (人天) 需 求 分 析 结构设计 详细设计 编码 集成测试 系统测试 现场

 实行严格的产品控制。 需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理(Baseline configuration management) 。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。  采用现代程序设计技术。 采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。

 结果应该清楚地审查。 软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。  开发小组成员应该少而精。 这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多； 当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。

 承认不断改进的软件工程实践的必要性。 根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

软件工程方法学 传统方法学（结构化） 面向对象方法学 对象＋类＋继承＋用消息通信

软件过程与软件生命（生存）周期 软件过程是为获得软件产品，在软件工具支持下由软件工程师完成的一系列软件工程活动。 软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。 软件工程的主要环节包括人员管理、项目管理、需求分析、系统设计、程序设计、测试、维护等。 软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程。

软件工程的传统途径： 采用生命周期法，从时间角度对软件开发和维护的复杂问题进行分解，把软件的生命周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。 前一阶段任务完成是开始后一阶段工作的前提和基础。后一阶段任务的完成是前一阶段的进一步具体化。 每一阶段的开始与结束都有严格的标准。在每一阶段结束之前必须进行正式严格的技术审查与管理复审。

软件生命周期 本书： 软件定义（问题定义、可行性研究、需求分析） 软件开发（总体设计、详细设计、编码和单元测试、综合测试） 软件维护 另一分法： 制定计划 (Planning) 需求分析和定义(Requirement Analysis and Definition) 软件设计( Software Design) 程序编写(Coding, Programming) 软件测试(Testing) 运行/维护(Running/Maintenance)

问题定义 问题定义阶段必须回答的关键问题是：“要解决的问题是什么”。 可行性研究 这个阶段要回答的关键问题是：“上一个阶段所确定的问题是否有行得通的解决办法”。

需求分析 这个阶段的任务仍然不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”这个问题。 这个阶段的另外一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明(specification)。

概要设计 这个阶段的基本任务是，概括地回答“怎样实现目标系统?”这个问题。概要设计又称为初步设计、逻辑设计、高层设计或总体设计。 首先，应该设计出实现目标系统的几种可能的方案。 概要设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。

详细设计 概要设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答“应该怎样具体地实现这个系统”这个关键问题。这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。

编码和单元测试 这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。

综合测试 这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。（集成测试、子系统测试、系统测试、性能测试、验收测试等）

软件维护 维护阶段的关键任务是：通过各种必要的维护活动使系统持久地满足用户的需要。 通常有四类维护活动： 改正性维护，也就是诊断和改正在使用过程中发现的软件错误； 适应性维护，即修改软件以适应环境的变化； 完善性维护，即根据用户的要求改进或扩充软件使它更完善； 预防性维护，即修改软件为将来的维护活动预先做准备。

软件过程（生命周期模型）： 软件生命周期模型是跨越整个生命周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。 *为了解决产业环境中的实际问题，一个软件工程师或一组软件工程师必须综合出一个开发策略，覆盖过程、方法、和工具。这个策略常常被称为 软件过程模型。

传统瀑布模型存在什么问题？ 传统的瀑布模型 传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。 在设计阶段可能发生规格说明文档中的错误。 而设计上的缺陷或错误可能在实现过程中显现出来。 在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。 传统的瀑布模型

实际的瀑布模型 发现错误就必须及时改正，因此，实际的瀑布模型是带“反馈环”的（图中实线箭头表示开发过程，虚线箭头表示维护过程）。 当在后面阶段发现前面阶段所犯的错误时，需要沿图中左侧的“反馈线”返回前面的阶段，修正前面阶段的产品（文档或程序）之后再回来继续完成后面阶段的任务。 实际的瀑布模型

瀑布模型的特点 1、阶段间具有顺序性和依赖性 2、推迟实现的观点: 清楚地区分逻辑设计与物理设计，尽可能推迟软件的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。 3、质量保证的观点: 在瀑布模型的每个阶段都坚持下述的两个重要做法： 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。 每个阶段结束前都要对该阶段所完成的文档（或程序）进行评审（或测试），以便尽早发现问题，及时改正错误。

使用瀑布模型会遇到一些问题： 适用：需求确定、变更相对较少 不适用：需求经常发生变更 （1）实际项目很少按照该模型给出的顺序进行。 （2）用户常常难以清楚地给出所有需求，而模型却要求如此，不能接受在许多项目的开始阶段自然存在的不确定性。 （3）用户必须有耐心。程序的运行版本一直要等到项目开发晚期才能得到。大的错误指导检查运行程序时才能被发现，后果可能是灾难的。 （4）开发者常常被不必要地耽搁。 线性特性会导致“阻塞状态”，其中某些项目组成员不得不等待组内其它成员，先完成其依赖的任务。 适用：需求确定、变更相对较少 不适用：需求经常发生变更

快速原型模型 适用情况 用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求； 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式； …… 快速原型模型可能是最好的选择

快速原型模型步骤 快速原型模型从需求收集开始。 开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。 然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。 原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解， 这个过程是迭代的。

不带反馈环的，基本上是顺序的。

采用快速原型模型的软件生存周期 分析定义 系统需求 生成 原型 系统 设计 程序 编码 测试 运 行 和维护 原型化 含原型化的 软件生存期

应用快速原型模型的效果 保证可维护性 改善交流和思想沟通 减少返工 作为培训环境 开发成本降低，周期缩短

快速原型的特性 实际工作的系统 可抛弃 必须快,便宜 完整重复的过程

增量模型 把软件产品作为一系列的增量构件来设计、编码、集成和测试。

风险更大的增量模型

增量模型融合了瀑布模型的基本成分和原型的迭代特性。 例如，使用增量模型开发字处理软件 基本的文件管理、编辑和文档生成功能。 更完善的编辑和文档生成能力。 实现拼写和文法检查功能。 完成高级的页面布局功能。 第一个增量往往是核心产品 每一个增量均发布一个可操作产品 早期的增量是最终产品的“可拆卸”版本

螺旋模型 在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型 。 基本思想 在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型 。 螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即： 制定计划；风险分析；实施工程；客户评估

螺旋模型

优点 特点 主要适用于内部开发的大规模软件项目 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标； 减少了过多测试或测试不足； 维护和开发之间并没有本质区别。 特点 风险驱动的 主要适用于内部开发的大规模软件项目

四种模型总结 瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法；这种模型的问题是，最终交付的产品可能不是用户真正需要的。 快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建起一个可运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。

增量模型具有能在软件开发的早期阶段使投资获得明显回报和易于维护的优点，但是，要求软件具有开放结构是使用这种模型时固有的困难。 风险驱动的螺旋模型适用于大规模的内部开发项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。