软件工程基础讲解课件

软件工程主讲：姜宁软件工程主讲：姜宁教材《软件工程》张海藩清华大学出版社

教材《软件工程》参考书目《软件工程实践者的研究方法》机械工业出版社《软件工程》卢潇清华大学出版社软件业的生存之道人月神话参考书目《软件工程实践者的研究方法》机械工业出版社学习方式完成必要的作业完成每次的实验题目完成一次综合性的项目分析开发学习方式完成必要的作业软件工程师的基本功底扎实的基础

丰富的想象力最简单的是最好交流能力良好的编程风格韧性和毅力软件工程师的基本功底扎实的基础“开发流程＋英文优势”印度软件在中国的发展

根据统计数据，2004年前三个季度，有21家印度公司在中国直接投资，但投资总额仅为1700万美元，在同期外国IT企业在华直接投资中所占的比例小得可怜。考虑到从2002年起，印度前四名的软件企业塔塔、InfoSys、Wipro以及Satyam就已陆续在上海登陆“开发流程＋英文优势”印度软件在中国的发展

根据统计数据，2学习目的对项目的定位分析软件工程思想建模软件工程是典型的计算机科学和数学，管理科学，心理学，社会学等学科的综合。学习目的对项目的定位分析软件的发展程序设计阶段（20世纪40年代初~60年代中期）程序系统阶段（60年代中期到70年代末期）软件工程阶段（20世纪70年代中）第四阶段个体化的软件环境

软件规模小，编写者和使用者往往是同一个人，除程序清单外，无其它文档资料。“软件作坊”

比较广泛使用产品软件，仍沿用个体化开发方法。软件维护工作很难进行，甚至不可维护（不能修改运行时发现的错误，不能适应新的硬件环境）由于软件的“不可维护”，而导致了“软件危机”。微处理器出现

个人计算机产品、分布式系统对软件开发提出更高要求，软件在工业、学术界应用广泛，个人应用少。更强大的硬件和软件复杂操作系统控制的强大的桌面系统，局域网和广域网，先进的应用软件配合，成为主流。集中主机环境转变为分布的C/S，B/S环境。面向对象技术取代传统技术。软件的发展程序设计阶段（20世纪40年代初~60年代中期）个

例:Windows95有1000万行代码

Windows2000有5000万行代码Exchange2000和Windows2000开发人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人例:Windows95有10软件工程概论什么是软件软件的分类软件的发展软件生存期软件工程软件工程的目的和要求软件工程概论什么是软件软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合软件＝程序＋数据＋文档资料程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数软件的分类按软件的功能进行划分：系统软件使计算机系统各个部件、相关软件和数据协调、高效地工作的软件操作系统数据库管理系统设备驱动程序通信处理程序等软件的分类按软件的功能进行划分：支撑软件协助用户开发软件的工具软件文本编辑程序文件格式化程序磁盘向磁带进行数据传输的程序程序库系统支持需求分析、设计、实现、测试和支持管理的软件支撑软件应用软件商业数据处理软件工程与科学计算软件计算机辅助设计／制造软件系统仿真软件智能产品嵌入软件医疗、制药软件事务管理、办公自动化软件计算机辅助教学软件应用软件按软件规模进行划分：类别参加人员数 研制期限源程序行数

微型 1 1～4周0.5k小型1 1～6月1k～2k

数值计算或数据处理,通常没有与其它程序的接口。需要按一定的标准化技术、正规的资料书写以及定期的系统审查。只是没有大题目那样严格。中型2～5 1～2年5k～50k

软件人员之间、与用户之间的联系、协调的配合关系。因而计划、资料书写以及技术审查需要比较严格地进行。应用程序和系统程序。系统的软件工程方法是完全必要的。按软件规模进行划分：大型5～20 2～3年50k～100k

编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，每组5人以下。人员调整往往不可避免，新手的培训。采用统一的标准，实行严格的审查是绝对必要的。甚大型100～10004～5年1M(=1000k)

若干个子项目，每一个子项目都是一个大型软件。子项目之间具有复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问题没有软件工程方法的支持，它的开发工作是不可想象的。极大型2000～50005～10年1M～10M

军事指挥、弹道导弹防御系统。只是对软件工程技术依赖的程度不同而已。大型5～20 2～3年50k按软件工作方式划分：

实时处理软件分时软件交互式软件批处理软件按软件工作方式划分：按软件服务对象的范围划分：

项目软件

合同约束，实验研究特殊定制的产品软件

提供市场，功能、性能、培训及服务按软件服务对象的范围划分：按使用的频度进行划分：低频度使用频繁使用按使用的频度进行划分：按软件失效的影响进行划分：高可靠性软件一般可靠性软件按软件失效的影响进行划分：软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性软件的生产与硬件不同，在它的开发过程中没有明显的制造过程在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而它具软件工程基础讲解软件对硬件和环境有着不同程度的依赖性，导致了软件升级和移植的问题。传统的手工开发方式使软件开发的效率受到很大的限制。因此，应促进软件技术自动生成技术和其他一些有效的软件开发工具或软件开发环境。软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵大多数软件是新开发的，而不是通过已有的构件组装而来的。相当多的软件工作涉及到社会因素软件对硬件和环境有着不同程度的依赖性，导致了软件升级和移植的软件生产随规模增大而复杂度增大以美国宇航局的软件系统为例：1963年水星计划系统200万条指令1967年双子星座计划系统400万条指令1973年阿波罗计划系统1000万条指令1979年哥伦比亚航天飞机系统4000万条指令假设1个人一年生产一万条有效指令，那么是否4000人生产一年，或400人生产10年就能完成任务吗？答案是否定的。一万条指令的复杂度决不仅仅是100条指令复杂度的100倍。软件生产随规模增大而复杂度增大以美国宇航局的软件系统为例：软件开发进度难以预测拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。以丹佛新国际机场为例。该机场规模是曼哈顿机场的两倍，宽为希思机场的10倍，可以全天侯同时起降三架喷气式客机；投资1.93亿美元建立了一个地下行李传送系统，总长21英里，有4，000台遥控车，可按不同线路在20家不同的航空公司柜台、登机门和行李领取处之间发送和传递行李；支持该系统的是5，000个电子眼、400台无线电接受机、56台条形码扫描仪和100台计算机。按原定计划要在1993年万圣节前启用，但一直到1994年6月，机场的计划者还无法预测行李系统何时能达到可使机场开放的稳定程度。软件开发进度难以预测拖延工期几个月甚至几年的现象并不罕见，这典型失败系统的例子IBM公司开发OS/360系统，共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付。在交付使用后的系统中仍发现大量（2000个以上）的错误。典型失败系统的例子IBM公司开发OS/360系统，共有400没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大确实，直到上个世纪末，20多年以来，软件行业的生产效率依然没有数量级的提高，软件在帮助传统行业提高效率的同时，自身却成为最原始意义上的“手工行业”。虽然，许多大型的企业级应用软件采取了大规模的生产和协作，但是这种软件往往开发时间长，效率低，无法动态调整，无法由僵硬变得灵活和敏捷。软件业也需要脱离手工作坊时代和工业时代，而走进敏捷定制的后工业时代。确实，直到上个世纪末，20多年以来，软件行业的生产效率依然没软件生产方式的落后，加之需求和环境的进一步复杂，使得传统软件的生产方式，不但不能缓解软件工程的危机，而是处于不断加深的危机之中。互联网应用时代，企业期望的是以更低的成本，更快的速度，获得高质量、高灵活性的随处可得的软件。显然，依靠传统软件业落后的生产方式和僵化的软件结构，无法面对互联网应用的挑战。矛盾在不断加剧，危机在不断加深。软件生产方式的落后，加之需求和环境的进一步复杂，使得传统软件僵化的软件结构无法产生银弹——从代码级做起的软件，强调功能实现，天生具有庞大、僵化、无法适应变化的缺点。编码式的软件，无论是采取何种方式，都无法真正实现“敏捷定制”。代码级的编程、代码级的维护使得效率不可能真正地提高。僵化的软件结构无法产生银弹——从代码级做起的软件，强调功能实软件开发中的问题计划很难制定致使经费预算常常突破

由于缺乏软件开发的经验，主观盲目地制定计划，执行起来和实际情况有很大差距，对于工作量估计不准确，进度计划无法遵循，开发工作完成的期限一拖再拖。已经拖延了的项目，为了加快进度赶上去而增加人力，反而更加延误了。软件开发中的问题计划很难制定致使经费预算常常突破需求在开发的初期阶段提得不够明确,或是未能得到确切的表达。

软件人员和用户又未能及时交换意见，使得一些问题不能及时解决，造成开发后期矛盾的集中暴露。然而这时问题既难于分析，也难于挽回。开发过程没有统一的、公认的方法论和规范指导加之不重视文字资料工作，资料很不完整；忽视每个人与其他人的接口部分，发现了问题修修补补，这样的软件很难维护。需求在开发的初期阶段提得不够明确,或是未能得到确切的表达。未能充分做好检测工作

在运行中暴露出大量的问题，轻者影响系统的正常工作，重者发生事故，甚至造成生命财产的重大损失。

美国IBM公司在1963年至1966年开发的IBM360机的操作系统。5000人-年的工作量，1000人投入，近100万行源程序。每次发行的新版本都是从前一版本中找1000个程序错误，项目负责人F.D.Brook总结时说：“正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难。“未能充分做好检测工作按工程化的原则和方法组织软件开发是软件开发中的问题一个主要出路。

软件工程阶段，约为70年代以后。50年代到60年代时，程序设计曾经被看做是一种任人发挥创造才能的技术领域。写出的程序通篇充满了程序技巧，这些程序很难被别人看懂。然而随着计算机的广泛使用，人们逐渐抛弃了这种观点。对于稍大的程序，并需要较长时间为许多人使用的程序，人们要求这些程序容易看懂、容易使用，并且容易修改和扩充。多个软件人员分工合作、共同完成；只有在项目的总体要求和技术规范的约束下充分发挥和施展。按工程化的原则和方法组织软件开发是软件开发中的软件危机的具体体现（1）软件开发进度难以预测（2）软件开发成本难以控制（3）用户对软件功能难以满足（4）软件产品质量无法保证（5）软件产品难以维护（6）软件缺少文档资料软件危机的具体体现（1）软件开发进度难以预测软件工程的定义软件工程：是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。实质上，软件工程就是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和最先进的软件开发技术结合起来，应用到软件开发和维护过程中去。IEEE：(InstituteofElectricalandElectronicsEngineers)软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护过程，即将工程化应用于软件中的方法的研究。软件工程的定义软件工程：是一门研究如何用系统化、规范化、数量软件工程三要素：

方法、工具和过程工具层：为软件工程方法提供了自动的或半自动的软件支撑环境。

CASE：计算机辅助软件工程，将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。使用软件工程工具可以有效地改善软件开发过程，提高开发效率，降低开发成本软件工程三要素：

方法、工具和过程工具层：为软件工程方法提供软件工程三要素方法层：提供了软件开发的各种方法。方法覆盖了一系列的任务，包括项目计划与估算方法、需求分析和设计的方法、编程、测试方法及维护方法等软件工程方法为软件开发提供了“如何做”的技术软件工程三要素方法层：提供了软件开发的各种方法。方法覆盖了一软件工程三要素过程层：是软件工程的基础。软件工程过程是为了获得软件产品，在软件工具支持下由软件人员完成的一系列软件工程活动。（具体实施）软件工程三要素过程层：是软件工程的基础。软件工程过程是为了获软件工程过程定义了:方法使用的顺序要求交付的文档资料为保证质量和适应变化所需要的管理软件开发各个阶段完成的里程碑软件工程过程定义了:软件工程项目的基本目标付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用软件工程项目的基本目标付出较低的开发成本软件开发项目力图在以上目标的冲取得一定程度的平衡。软件开发项目力图在以上目标的冲取得一定程度的软件生存期

lifecycle软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期软件生存期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护软件生存期lifecycle软件有一个孕育、诞生、成长、制定计划确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度制定出完成开发任务的实施计划,连同可行性研究报告，提交管理部门审查制定计划确定要开发软件系统的总目标需求分析和定义对待开发软件提出的需求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审需求分析和定义对待开发软件提出的需求进行分析并给出详细的定义软件设计概要设计—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审。软件设计概要设计—把各项需求转换成软件的体系结构。结构中程序编写把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”写出的程序应当是结构良好、清晰易读的，且与设计相一致的程序编写把软件设计转换成计算机可以接受的程序代码，即写成以某软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正组装测试，将已测试过的模块按一定顺序组装起来按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠运行／维护改正性维护运行中发现了软件中的错误需要修正适应性维护为了适应变化了的软件工作环境，需做适当变更完善性维护为了增强软件的功能需做变更运行／维护改正性维护运行中发现了软件中的错误需要修正软件开发过程模型软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架瀑布模型原型模型（快速原型模型）螺旋模型喷泉模型构件组装模型统一过程RUP模型

第四代技术软件开发过程模型软件生存期模型是跨越整个生存期的系统开发、运瀑布模型

需求分析7%系统设计6%软件编程7%软件测试13%软件维护67%用户要求分析报告系统设计报告源程序测试报告更改要求UAMATMMPUTPUAMPA系统分析员M项目管理员P程序员T高级程序员U用户瀑布模型需求分析7%系统设计6%软件编程7%软件测试13%软件工程基础讲解瀑布模型优点：a.强调开发的阶段性；b.强调早期计划及需求调查；

c.强调产品测试。将系统逻辑设计与物理实现严格分开，尽可能在设计结果通过审查确定无误时开始编码工作，推迟物理实现的观点是瀑布型模型的一个重要知道思想。瀑布模型优点：缺点：

a.依赖于早期进行的唯一一次需求调查，不能适应需求的变化；

b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；

c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。缺点：快速原型（RapidPrototype）基本思想是：软件开发人员在与用户进行需求分析时，以比较小的代价快速建立一个能够反映用户主要需求的原型系统，让用户在计算机上进行操作，在实践过程中提出改进意见，开发人员根据用户的意见，对原型进行补充和完善，然后再由用户试用、评价、提出建议，重复这一过程，直到用户对开发的原型系统满意为止。快速原型（RapidPrototype）基本思想是：软件开需求分析原型开发原型评价最终系统设计最终系统实现原型模型用户反馈需求分析原型开发原型评价最终系统设计最终系统实现原型模型用户快速原型（RapidPrototype）在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。它最重要的目的是为了确定用户的真正需求。快速原型（RapidPrototype）在功能上等价于产品螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析──分析所选方案，考虑如何识别和消除风险实施工程──实施软件开发客户评估──评价开发工作，提出修正建议螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面

优点：a.强调严格的全过程风险管理。b.强调各开发阶段的质量。c.提供机会检讨项目是否有价值继续下去。优点：缺点：

a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员，资金，和时间的投入。

缺点：喷泉模型软件的开发方法是基于迭代和无间隙的特性时，就可以使用喷泉模型来构造开发模型。迭代：是指系统的某个部分的工作需要多次重复，经过每次的重复后，该部分的功能将被补充和完善。无间隙：是指软件开发各个阶段的活动（分析、设计和编码）之间不存在明显的边界。喷泉模型软件的开发方法是基于迭代和无间隙的特性时，就可以使用喷泉模型喷泉模型演化模型

演化模型是利用一种迭代的方法使软件渐进地开发，经过一段时间的演化，逐步完善。需求往往不够清晰，且常常变化。紧迫的市场期限。先提交一个有限的版本，其目标只是在于探索可行性，弄清软件需求。细节部分可以进一步定义和开发。演化模型演化模型是利用一种迭代的方法使软件渐演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出增量模型增量模型增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征增量模型强调每一个增量都发布一个可运行的产品增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每增量模型特别适用于：需求经常变化的软件开发市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术增量模型特别适用于：统一过程RUP模型RUP是一种用例（Use-case）驱动的软件开发过程RUP是以体系结构（Architecture）为中心的过程迭代开发与增量开发相结合的过程统一过程RUP模型RUP是一种用例（Use-case）驱动的基于第四代技术的模型基于第四代技术的模型第四代技术的模型优点：软件生产所需的时间大大降低，小型应用软件的分析和设计所需的时间也降低了。缺点：需要更多的分析、设计和测试，生成的结果源代码效率较低，利用4GT开发的大型软件系统的可维护性是令人怀疑的。第四代技术的模型优点：软件生产所需的时间大大降低，小型应用软形式化方法模型形式化方法模型是用数学来描述计算机软件的方法。采用严格的数学表示体系来说明、开发和验证系统能消除其他软件工程范型难以克服的问题更容易发现和纠正二义性、不完整性和不一致性在商业环境中的可用性还需考虑：形式化模型的开发还很费时和昂贵很少有软件开发者具有形式化方法所需的背景知识难以使用该模型作为与对其一无所知的用户进行沟通的机制形式化方法模型形式化方法模型是用数学来描述计算机软件的方法。混合模型混合模型混合模型容许一个项目沿着最有效的路径发展适应性强混合模型容许一个项目沿着最有效的路径发展软件开发方法简述软件开发方法是指软件开发过程中所应遵循的方法和步骤。

1、结构化方法2、面向数据结构的开发方法3、面向对象的方法4、可视化开发方法软件开发方法简述软件开发方法是指软件开发过程中所应遵循的方法结构化方法结构化方法也称为面向功能的软件开发方法或Yourdon方法，是20世纪80年代使用最广泛的软件开发方法。结构化方法采用结构化分析方法（StructuredAnalysis,SA）对软件进行需求分析，然后用结构化设计方法（StructuredDesign,SD）进行总体设计和详细设计，最后是结构化编程（StructuredProgramming,SP）。结构化方法结构化方法也称为面向功能的软件开发方法或Yourd结构化方法结构化分析（SA）方法是一种面向数据流的需求分析方法，它适用于分析大型数据处理系统。结构化分析方法的基本思想是按照功能分解的原则，自顶向下，逐层分解，把一个问题分解成若干个小问题，每个小问题再分解成若干个更小的问题，经过多次逐层分解，每个最低层的问题都是足够简单、容易解决的，这个过程就是分解的过程。SA方法的分析结果由数据流图DFD、数据词典和加工逻辑说明几个部分组成结构化方法结构化分析（SA）方法是一种面向数据流的需求分析方结构化方法结构化设计（SD）方法是一个面向数据流的软件设计方法，它可以与SA方法衔接，SD方法采用结构图（SC）来描述程序的结构。结构图的基本成分由模块、调用和输入/输出数据组成。在需求分析阶段，用SA方法产生了数据流图。面向数据流的设计能方便地将DFD转换成程序结构图，DFD中从系统的输入数据到系统的输出数据流的一连串连续变换将形成一条信息流。DFD的信息流大体可分为两种类型，一种是变换流，另一种是事务流。结构化方法结构化设计（SD）方法是一个面向数据流的软件设计方结构化方法SD方法的设计步骤有：①复查并精化数据流图；②确定DFD的信息流类型；③根据信息流类型分别将变换流或事务流转换成程序结构图；④根据软件设计的原则对程序结构图作为改进。结构化方法SD方法的设计步骤有：①复查并精化数据流图；②确定结构化方法优点：简单、实用，可有效地控制系统的复杂度。缺点：1、构造的软件系统不够稳定2、从数据流程图到软件结构图之间的过渡有明显的断层，导致设计回溯到需求有困难。结构化方法优点：简单、实用，可有效地控制系统的复杂度。面向数据结构的开发方法有两种开发方法：1、结构化数据系统开发方法（DSSD）

又称Warnier方法2、Jackson系统开发方法（JSD）

简称Jackson方法面向数据结构的开发方法有两种开发方法：面向数据结构的开发方法基本思想：从目标系统的输入/输出数据结构入手，导出程序的基本框架结构，在此基础上，对细节进行设计，得到完整的程序结构图。面向数据结构的开发方法基本思想：从目标系统的输入/输出数据结面向对象的方法类的概念，应用了继承机制和动态链接优点：更符合人类的思维方式。它通过将现实世界问题向面向对象解空间映射的方式，实现对现实世界的直接模拟。它以数据为中心，而不是基于对功能的分解，因此当系统功能发生变化时不会引起软件结构的整体变化，往往只需要进行一些局部的修改。相对来说，软件的重用性、可靠性、可维护等特性都较好。面向对象的方法类的概念，应用了继承机制和动态链接可视化开发方法可视化方法是随着图形用户界面的兴起而发展起来的，可视化开发工具除了提供图形开发的界面，还应提供可直接使用的界面元素，如窗口、按钮、对话框、编辑框、菜单、单选框、复选框、列表框和滚动条等，以方便开发人员直接引用这些界面元素，生成通用的、标准化的图形界面。可视化开发方法可视化方法是随着图形用户界面的兴起而发展起来的可视化开发方法从本质上讲并不能作为一种开发方法，确切地说它只是一种辅助工具。工作方式：事件驱动，通过对界面元素的操作，触发某一事件，引发相应的响应函数进行处理，实现用户和计算机的交互过程。优点：简单、易学、易上手。可视化开发方法从本质上讲并不能作为一种开发方法，确切地说它只软件工程的最新发展动向软件形式语言的研究构建技术质量管理（软件质量保障）软件工程的最新发展动向软件形式语言的研究结束结束软件工程主讲：姜宁软件工程主讲：姜宁教材《软件工程》张海藩清华大学出版社

教材《软件工程》参考书目《软件工程实践者的研究方法》机械工业出版社《软件工程》卢潇清华大学出版社软件业的生存之道人月神话参考书目《软件工程实践者的研究方法》机械工业出版社学习方式完成必要的作业完成每次的实验题目完成一次综合性的项目分析开发学习方式完成必要的作业软件工程师的基本功底扎实的基础

丰富的想象力最简单的是最好交流能力良好的编程风格韧性和毅力软件工程师的基本功底扎实的基础“开发流程＋英文优势”印度软件在中国的发展

根据统计数据，2004年前三个季度，有21家印度公司在中国直接投资，但投资总额仅为1700万美元，在同期外国IT企业在华直接投资中所占的比例小得可怜。考虑到从2002年起，印度前四名的软件企业塔塔、InfoSys、Wipro以及Satyam就已陆续在上海登陆“开发流程＋英文优势”印度软件在中国的发展

根据统计数据，2学习目的对项目的定位分析软件工程思想建模软件工程是典型的计算机科学和数学，管理科学，心理学，社会学等学科的综合。学习目的对项目的定位分析软件的发展程序设计阶段（20世纪40年代初~60年代中期）程序系统阶段（60年代中期到70年代末期）软件工程阶段（20世纪70年代中）第四阶段个体化的软件环境

软件规模小，编写者和使用者往往是同一个人，除程序清单外，无其它文档资料。“软件作坊”

比较广泛使用产品软件，仍沿用个体化开发方法。软件维护工作很难进行，甚至不可维护（不能修改运行时发现的错误，不能适应新的硬件环境）由于软件的“不可维护”，而导致了“软件危机”。微处理器出现

个人计算机产品、分布式系统对软件开发提出更高要求，软件在工业、学术界应用广泛，个人应用少。更强大的硬件和软件复杂操作系统控制的强大的桌面系统，局域网和广域网，先进的应用软件配合，成为主流。集中主机环境转变为分布的C/S，B/S环境。面向对象技术取代传统技术。软件的发展程序设计阶段（20世纪40年代初~60年代中期）个

例:Windows95有1000万行代码

Windows2000有5000万行代码Exchange2000和Windows2000开发人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人例:Windows95有10软件工程概论什么是软件软件的分类软件的发展软件生存期软件工程软件工程的目的和要求软件工程概论什么是软件软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合软件＝程序＋数据＋文档资料程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数软件的分类按软件的功能进行划分：系统软件使计算机系统各个部件、相关软件和数据协调、高效地工作的软件操作系统数据库管理系统设备驱动程序通信处理程序等软件的分类按软件的功能进行划分：支撑软件协助用户开发软件的工具软件文本编辑程序文件格式化程序磁盘向磁带进行数据传输的程序程序库系统支持需求分析、设计、实现、测试和支持管理的软件支撑软件应用软件商业数据处理软件工程与科学计算软件计算机辅助设计／制造软件系统仿真软件智能产品嵌入软件医疗、制药软件事务管理、办公自动化软件计算机辅助教学软件应用软件按软件规模进行划分：类别参加人员数 研制期限源程序行数

微型 1 1～4周0.5k小型1 1～6月1k～2k

数值计算或数据处理,通常没有与其它程序的接口。需要按一定的标准化技术、正规的资料书写以及定期的系统审查。只是没有大题目那样严格。中型2～5 1～2年5k～50k

软件人员之间、与用户之间的联系、协调的配合关系。因而计划、资料书写以及技术审查需要比较严格地进行。应用程序和系统程序。系统的软件工程方法是完全必要的。按软件规模进行划分：大型5～20 2～3年50k～100k

编译程序、小型分时系统、实时控制系统等。二级管理，若干小组，每组5人以下。人员调整往往不可避免，新手的培训。采用统一的标准，实行严格的审查是绝对必要的。甚大型100～10004～5年1M(=1000k)

若干个子项目，每一个子项目都是一个大型软件。子项目之间具有复杂的接口。如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、军事指挥系统通常现有这样的规模。很显然，这类问题没有软件工程方法的支持，它的开发工作是不可想象的。极大型2000～50005～10年1M～10M

军事指挥、弹道导弹防御系统。只是对软件工程技术依赖的程度不同而已。大型5～20 2～3年50k按软件工作方式划分：

实时处理软件分时软件交互式软件批处理软件按软件工作方式划分：按软件服务对象的范围划分：

项目软件

合同约束，实验研究特殊定制的产品软件

提供市场，功能、性能、培训及服务按软件服务对象的范围划分：按使用的频度进行划分：低频度使用频繁使用按使用的频度进行划分：按软件失效的影响进行划分：高可靠性软件一般可靠性软件按软件失效的影响进行划分：软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性软件的生产与硬件不同，在它的开发过程中没有明显的制造过程在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而它具软件工程基础讲解软件对硬件和环境有着不同程度的依赖性，导致了软件升级和移植的问题。传统的手工开发方式使软件开发的效率受到很大的限制。因此，应促进软件技术自动生成技术和其他一些有效的软件开发工具或软件开发环境。软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵大多数软件是新开发的，而不是通过已有的构件组装而来的。相当多的软件工作涉及到社会因素软件对硬件和环境有着不同程度的依赖性，导致了软件升级和移植的软件生产随规模增大而复杂度增大以美国宇航局的软件系统为例：1963年水星计划系统200万条指令1967年双子星座计划系统400万条指令1973年阿波罗计划系统1000万条指令1979年哥伦比亚航天飞机系统4000万条指令假设1个人一年生产一万条有效指令，那么是否4000人生产一年，或400人生产10年就能完成任务吗？答案是否定的。一万条指令的复杂度决不仅仅是100条指令复杂度的100倍。软件生产随规模增大而复杂度增大以美国宇航局的软件系统为例：软件开发进度难以预测拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。以丹佛新国际机场为例。该机场规模是曼哈顿机场的两倍，宽为希思机场的10倍，可以全天侯同时起降三架喷气式客机；投资1.93亿美元建立了一个地下行李传送系统，总长21英里，有4，000台遥控车，可按不同线路在20家不同的航空公司柜台、登机门和行李领取处之间发送和传递行李；支持该系统的是5，000个电子眼、400台无线电接受机、56台条形码扫描仪和100台计算机。按原定计划要在1993年万圣节前启用，但一直到1994年6月，机场的计划者还无法预测行李系统何时能达到可使机场开放的稳定程度。软件开发进度难以预测拖延工期几个月甚至几年的现象并不罕见，这典型失败系统的例子IBM公司开发OS/360系统，共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付。在交付使用后的系统中仍发现大量（2000个以上）的错误。典型失败系统的例子IBM公司开发OS/360系统，共有400没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大确实，直到上个世纪末，20多年以来，软件行业的生产效率依然没有数量级的提高，软件在帮助传统行业提高效率的同时，自身却成为最原始意义上的“手工行业”。虽然，许多大型的企业级应用软件采取了大规模的生产和协作，但是这种软件往往开发时间长，效率低，无法动态调整，无法由僵硬变得灵活和敏捷。软件业也需要脱离手工作坊时代和工业时代，而走进敏捷定制的后工业时代。确实，直到上个世纪末，20多年以来，软件行业的生产效率依然没软件生产方式的落后，加之需求和环境的进一步复杂，使得传统软件的生产方式，不但不能缓解软件工程的危机，而是处于不断加深的危机之中。互联网应用时代，企业期望的是以更低的成本，更快的速度，获得高质量、高灵活性的随处可得的软件。显然，依靠传统软件业落后的生产方式和僵化的软件结构，无法面对互联网应用的挑战。矛盾在不断加剧，危机在不断加深。软件生产方式的落后，加之需求和环境的进一步复杂，使得传统软件僵化的软件结构无法产生银弹——从代码级做起的软件，强调功能实现，天生具有庞大、僵化、无法适应变化的缺点。编码式的软件，无论是采取何种方式，都无法真正实现“敏捷定制”。代码级的编程、代码级的维护使得效率不可能真正地提高。僵化的软件结构无法产生银弹——从代码级做起的软件，强调功能实软件开发中的问题计划很难制定致使经费预算常常突破

由于缺乏软件开发的经验，主观盲目地制定计划，执行起来和实际情况有很大差距，对于工作量估计不准确，进度计划无法遵循，开发工作完成的期限一拖再拖。已经拖延了的项目，为了加快进度赶上去而增加人力，反而更加延误了。软件开发中的问题计划很难制定致使经费预算常常突破需求在开发的初期阶段提得不够明确,或是未能得到确切的表达。

软件人员和用户又未能及时交换意见，使得一些问题不能及时解决，造成开发后期矛盾的集中暴露。然而这时问题既难于分析，也难于挽回。开发过程没有统一的、公认的方法论和规范指导加之不重视文字资料工作，资料很不完整；忽视每个人与其他人的接口部分，发现了问题修修补补，这样的软件很难维护。需求在开发的初期阶段提得不够明确,或是未能得到确切的表达。未能充分做好检测工作

在运行中暴露出大量的问题，轻者影响系统的正常工作，重者发生事故，甚至造成生命财产的重大损失。

美国IBM公司在1963年至1966年开发的IBM360机的操作系统。5000人-年的工作量，1000人投入，近100万行源程序。每次发行的新版本都是从前一版本中找1000个程序错误，项目负责人F.D.Brook总结时说：“正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难。“未能充分做好检测工作按工程化的原则和方法组织软件开发是软件开发中的问题一个主要出路。

软件工程阶段，约为70年代以后。50年代到60年代时，程序设计曾经被看做是一种任人发挥创造才能的技术领域。写出的程序通篇充满了程序技巧，这些程序很难被别人看懂。然而随着计算机的广泛使用，人们逐渐抛弃了这种观点。对于稍大的程序，并需要较长时间为许多人使用的程序，人们要求这些程序容易看懂、容易使用，并且容易修改和扩充。多个软件人员分工合作、共同完成；只有在项目的总体要求和技术规范的约束下充分发挥和施展。按工程化的原则和方法组织软件开发是软件开发中的软件危机的具体体现（1）软件开发进度难以预测（2）软件开发成本难以控制（3）用户对软件功能难以满足（4）软件产品质量无法保证（5）软件产品难以维护（6）软件缺少文档资料软件危机的具体体现（1）软件开发进度难以预测软件工程的定义软件工程：是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。实质上，软件工程就是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和最先进的软件开发技术结合起来，应用到软件开发和维护过程中去。IEEE：(InstituteofElectricalandElectronicsEngineers)软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护过程，即将工程化应用于软件中的方法的研究。软件工程的定义软件工程：是一门研究如何用系统化、规范化、数量软件工程三要素：

方法、工具和过程工具层：为软件工程方法提供了自动的或半自动的软件支撑环境。

CASE：计算机辅助软件工程，将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。使用软件工程工具可以有效地改善软件开发过程，提高开发效率，降低开发成本软件工程三要素：

方法、工具和过程工具层：为软件工程方法提供软件工程三要素方法层：提供了软件开发的各种方法。方法覆盖了一系列的任务，包括项目计划与估算方法、需求分析和设计的方法、编程、测试方法及维护方法等软件工程方法为软件开发提供了“如何做”的技术软件工程三要素方法层：提供了软件开发的各种方法。方法覆盖了一软件工程三要素过程层：是软件工程的基础。软件工程过程是为了获得软件产品，在软件工具支持下由软件人员完成的一系列软件工程活动。（具体实施）软件工程三要素过程层：是软件工程的基础。软件工程过程是为了获软件工程过程定义了:方法使用的顺序要求交付的文档资料为保证质量和适应变化所需要的管理软件开发各个阶段完成的里程碑软件工程过程定义了:软件工程项目的基本目标付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作，及时交付使用软件工程项目的基本目标付出较低的开发成本软件开发项目力图在以上目标的冲取得一定程度的平衡。软件开发项目力图在以上目标的冲取得一定程度的软件生存期

lifecycle软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期软件生存期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护软件生存期lifecycle软件有一个孕育、诞生、成长、制定计划确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度制定出完成开发任务的实施计划,连同可行性研究报告，提交管理部门审查制定计划确定要开发软件系统的总目标需求分析和定义对待开发软件提出的需求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审需求分析和定义对待开发软件提出的需求进行分析并给出详细的定义软件设计概要设计—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审。软件设计概要设计—把各项需求转换成软件的体系结构。结构中程序编写把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”写出的程序应当是结构良好、清晰易读的，且与设计相一致的程序编写把软件设计转换成计算机可以接受的程序代码，即写成以某软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正组装测试，将已测试过的模块按一定顺序组装起来按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠运行／维护改正性维护运行中发现了软件中的错误需要修正适应性维护为了适应变化了的软件工作环境，需做适当变更完善性维护为了增强软件的功能需做变更运行／维护改正性维护运行中发现了软件中的错误需要修正软件开发过程模型软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架瀑布模型原型模型（快速原型模型）螺旋模型喷泉模型构件组装模型统一过程RUP模型

第四代技术软件开发过程模型软件生存期模型是跨越整个生存期的系统开发、运瀑布模型

需求分析7%系统设计6%软件编程7%软件测试13%软件维护67%用户要求分析报告系统设计报告源程序测试报告更改要求UAMATMMPUTPUAMPA系统分析员M项目管理员P程序员T高级程序员U用户瀑布模型需求分析7%系统设计6%软件编程7%软件测试13%软件工程基础讲解瀑布模型优点：a.强调开发的阶段性；b.强调早期计划及需求调查；

c.强调产品测试。将系统逻辑设计与物理实现严格分开，尽可能在设计结果通过审查确定无误时开始编码工作，推迟物理实现的观点是瀑布型模型的一个重要知道思想。瀑布模型优点：缺点：

a.依赖于早期进行的唯一一次需求调查，不能适应需求的变化；

b.由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；

c.风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。缺点：快速原型（RapidPrototype）基本思想是：软件开发人员在与用户进行需求分析时，以比较小的代价快速建立一个能够反映用户主要需求的原型系统，让用户在计算机上进行操作，在实践过程中提出改进意见，开发人员根据用户的意见，对原型进行补充和完善，然后再由用户试用、评价、提出建议，重复这一过程，直到用户对开发的原型系统满意为止。快速原型（RapidPrototype）基本思想是：软件开需求分析原型开发原型评价最终系统设计最终系统实现原型模型用户反馈需求分析原型开发原型评价最终系统设计最终系统实现原型模型用户快速原型（RapidPrototype）在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。它最重要的目的是为了确定用户的真正需求。快速原型（RapidPrototype）在功能上等价于产品螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析──分析所选方案，考虑如何识别和消除风险实施工程──实施软件开发客户评估──评价开发工作，提出修正建议螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面

优点：a.强调严格的全过程风险管理。b.强调各开发阶段的质量。c.提供机会检讨项目是否有价值继续下去。优点：缺点：

a.引入非常严格的风险识别，风险分析，和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员，资金，和时间的投入。

缺点：喷泉模型软件的开发方法是基于迭代和无间隙的特性时，就可以使用喷泉模型来构造开发模型。迭代：是指系统的某个部分的工作需要多次重复，经过每次的重复后，该部分的功能将被补充和完善。无间隙：是指软件开发各个阶段的活动（分析、设计和编码）之间不存在明显的边界。喷泉模型软件的开发方法是基于迭代和无间隙的特性时，就可以使用喷泉模型喷泉模型演化模型

演化模型是利用一种迭代的方法使软件渐进地开发，经过一段时间的演化，逐步完善。需求往往不够清晰，且常常变化。紧迫的市场期限。先提交一个有限的版本，其目标只是在于探索可行性，弄清软件需求。细节部分可以进一步定义和开发。演化模型演化模型是利用一种迭代的方法使软件渐演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出增量模型增量模型增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征增量模型强调每一个增量都发布一个可运行的产品增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每增量模型特别适用于：需求经常变化的软件开发市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术增量模型特别适用于：统一过程RUP模型RUP是一种用例（Use-case）驱动的软件开发过程RUP是以体系结构（Architecture）为中心的过程迭代开发与增量开发相结合的过程统一过程RUP模型RU