ch1 软件工程学概述

软件工程学概述

(Introduction)前言Programmingisfun,butdevelopingqualitysoftwareishard.---PhilippeKruchten2outline软件软件危机软件工程软件生命周期软件过程及模型3outline软件软件危机软件工程软件生命周期软件过程及模型4软件的概念软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。程序是按事先设计和的功能性能要求执行的指令序列(instructions)数据是使程序能正常操纵信息的数据结构(datastructures)文档是与程序开发，维护和使用有关的图文材料(documents)

软件=程序+数据+文档程序=算法+数据结构软件是人类心灵和智慧在虚拟空间中的投射。5问题1有哪些类型的程序设计语言？面向机器汇编语言、机器语言等面向过程

Fortran,Pascal,C等面向对象

C++,Java等面向问题结构化查询语言SQL等6问题2在软件开发过程中会产生哪些文档？可行性研究报告需求规格说明书概要设计说明书详细设计说明书测试报告用户手册……….7问题3软件开发过程中为什么要编写文档？便于对软件开发的管理和维护便于各种人员的交流有哪些文档标准国际标准ISO行业标准IEEE、CMMI国家标准GB企业标准8CaseAnalysis19案例黄河水量调度综合监视系统系统开发流程：瀑布模型开发工具：VisualBASIC.NET地理信息系统：ARCIMS数据库管理系统：MicrosoftSQLServer7.0运行环境：局域网络（LAN）操作系统（WindowsNTServer2000）系统结构：三层Browser/Server结构10系统介绍黄河水量调度综合监视系统主要功能水量调度实时水情监视监视与预警流域信息查询气象信息查询水调资料查询水情信息查询引退水信息查询降雨信息查询水质信息查询水调方案查询重要文档查询功能设置以及地图标绘11实时水情监视12河道概况13生成报表14水库概况选择水库名称后，电子地图会定位到相应位置，并弹出水库概况信息窗口15水库概况16水库概况-库容曲线17云图应用查询18水库水情19日雨量信息该站雨量信息20时段雨量信息21雨量信息图22墒情信息图23软件的特点表现形式软件是一种逻辑实体，具有抽象性。生产方式软件的开发过程中没有明显的制造过程，大多数软件仍是定制的。要求

软件产品不允许误差维护在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题24软件的特点软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性软件的开发至今尚未完全摆脱手工的开发方式软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵25软件的分类按软件的功能进行划分：系统软件应用软件按软件规模进行划分：类别参加人员数研制期限源程序行数

微型1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)极大型2000～50005～10年1M～10M26软件的发展软件发展的四个阶段软件发展存在的问题27软件发展的四个阶段1950---1965

没有系统的软件开发方法和管理机制、自定义软件、批处理、有限分布。1965---1975

产生人机交互的新概念、新技术软件产品、多用户、实时、数据库。281973---1988

微处理器的出现并广泛应用 分布式系统、嵌入智能、低成本硬件、消费者的影响。1988---至今

广域和局域网络迅速普及 强大的桌面系统、面向对象技术、专家系统、人工智能、神经网络、并行计算、网络计算机。软件发展的四个阶段29软件发展存在的问题软件开发能力不能满足人们的需要。社会对软件的依赖程度加大，人们普遍关注软件的安全和可靠性。建造高可靠性、高质量软件的任务任重路远。若干年前开发的应用软件经过几十次修改已无人认识它的内部结构，己经不可维护。30outline软件软件危机软件工程软件生命周期软件过程及模型31案例分析1：IBM360美国IBM公司在1963年至1966年开发的IBM360的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源序。......据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。......这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭，......一批批程序员被迫在泥潭中拼命挣扎，......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。SoftwareCrisis!32人月神话：“没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性”。1、大前提：软件活动包含根本任务和次要任务根本任务——打造构成抽象软件实体的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，并在时间和空间内将它们映射成机器语言。2、小前提：现有解决方案致力于解决次要任务考察和评估几乎现有所有的软件工程解决方案，布鲁克斯指出：现有所有方案全都在致力于解决软件工程中的次要问题。3、结论：没有银弹无论这些方案多么完善，都不可能在根本上解决问题，即使将全部次要任务的时间缩减到零，也不会带来生产率数量级上的提高。33案例分析2：Ariane5June4,1996EuropeanSpaceAgencylostnewestrocket,theAriane5,successortotheAriane4Morethan$370Millionlostonfirstflight34案例分析2：Ariane5TheAriane5softwarereusedthespecificationsfromtheAriane4,buttheAriane5'sflightpathwasconsiderablydifferentandbeyondtherangeforwhichthereusedcomputerprogramhadbeendesigned.Adataconversionfroma64-bitfloatingpointto16-bitsignedintegervaluecausedanarithmeticoverflow,asthefloatingpointnumberhadavaluetoolargetoberepresentedbya16-bitsignedinteger.Itisoneofthemostinfamouscomputerbugsinhistory35软件危机的概念软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。Keypoints:howtodevelopnewsoftwarehowtosupportoldsoftware36软件危机的典型表现典型表现：对软件开发成本和进度的估计常常很不准确。用户对“已完成的”软件系统不满意的现象经常发生。软件产品的质量往往靠不住。软件常常是不可维护的。软件通常没有适当的文档资料。软件成本在计算机系统总成本所占的比例逐年上升。软件开发生产率提高的速度，远远跟不上计算机应用普及的速度。37开发成本高举例38产生软件危机的原因客观：软件本身的特点软件的规模加大、复杂性提高、性能增强软件是逻辑产品，尚未完全认识其本质和特点主观：不正确的开发、管理方法缺乏有效的、系统的开发、维护大型软件项目的技术手段和管理方法用户对软件需求的描述和软件开发人员对需求的理解往往存在差异计划不周，最终导致进度拖延没有充分的文档资料软件可靠性缺少度量的标准，质量无法保证忽视软件维护，使其维护，不易升级39outline软件软件危机软件工程软件生命周期软件过程及模型40软件工程的概念必须意识到：“软件”编程，它有自己的生命周期

(lifecycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。

“软件工程”(SoftwareEngineering)NATOConference,Garmisch,Germany,1968.解决问题的想法：软件危机根源解决途径软件工程41软件工程定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。IEEE：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。42软件工程定义概括地说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。43软件工程定义软件工程是一门交叉学科软件开发技术:

软件开发方法软件开发过程软件工具和软件工程环境软件工程管理:

软件管理学软件经济学

软件工程所包含的内容不是一成不变的，随着人们对软件系统的研制开发和生产的理解。应该用发展的眼光看待它。44

转变对软件开发的认识：

上升

程序系统

转变思维定式：

上升

程序员系统工程师(系统分析员)

工程化训练45a“quality”focusprocessmodelmethodstools方法使用的顺序；要求交付的文档资料；为保证质量和适应变化所需要的管理；软件开发各个阶段完成的里程碑。软件开发提供了“如何做”的技术。为软件工程方法提供了自动的或半自动的软件支撑环境，CASE软件工程三要素46软件工程的历史起源于20世纪50年代但是从学术的角度看，软件工程还是一个年轻的学科第一次会议在20世纪60年代后期在80年代才从计算机科学分离开47软件工程的历史1、60年代末～80年代初状况：软件系统的规模、复杂性以及在关键领域的广泛应用促进了软件开发过程采纳工程化的方法进行管理。研究：开发模型、支持工具、开发方法。成果：瀑布模型、结构化语言（Pascal等）、结构化方法、各种管理方法（如费用估算、文档复审）。事件：前期主要研究系统实现技术；后期则开始强调管理和软件质量。焦点：软件项目482、80年代初～现在

状况：“软件工厂”的概念已经提出。研究：软件生产技术，特别是软件复用技术和软件生产管理的研究和实践。成果：提出了具有广泛应用前景的面向对象方法和相关的编程语言。事件：软件过程改进。在工业实践中建立起一种量化的评估程序，判定软件组织成熟的程度。焦点：软件过程软件工程的历史493、近几年

研究从过程管理转向产品开发，更加注重新的程序开发范型和软件生产。范围：面向agent语言、复用技术、需求分析规格说明的形式化研究、高智能高自动化的CASE成为热点。软件工程的历史50软件工程原理Boehm于1983年提出7条基本原理：(1)用分阶段的生命周期计划严格管理(2)坚持进行阶段评审(3)实行严格的产品控制——基线配置管理

(Baselineconfigurationmanagement)(4)采用现代程序设计技术(5)结果应能清楚地审查—setstandards(6)开发小组的成员应该少而精(7)承认不断改进软件工程实践的必要性51outline软件软件危机软件工程软件生命周期软件过程及模型52软件生命周期软件的生命周期是软件产品或系统一系列相关活动的全周期。从形成概念开始，经过研制，交付使用，在使用中不断增补修订，直到最后退役，让位于新的软件产品的全过程。生命周期的构成：软件定义问题定义可行性研究需求分析软件开发总体设计详细设计编码和单元测试综合测试软件维护维护退役53软件生命周期问题定义“要解决的问题是什么？”确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求可行性研究“对于问题定义所确定的问题有可行的解决方法吗？”了解用户要求和现实环境从技术、经济、市场等方面研究并论证开发该软件系统的可行性54软件生命周期可行性研究(cont.)技术可行性：当前的软件开发方法和工具能否支持需求的实现；操作可行性：用户能否在特定的环境下使用这个软件；经济可行性：开发和使用、维护这个软件的成本能否被用户所接受。阶段性产品可行性论证报告制定初步项目开发计划(人员,进度)55软件生命周期需求分析“为了解决问题，目标系统必须做什么？”任务：确定用户对软件系统的需求：功能需求：软件必须要完成的功能；性能需求：软件的安全性、可靠性、可维护性、精度、错误处理、适应性、用户培训等；运行环境约束：待开发的软件产品必须满足的环境要求重要性：软件开发的依据，软件验收的标准56软件生命周期需求分析(cont.)困难：难以说清、动态变化、歧义、复杂。应用软件的需求分析涉及应用领域的知识和经验。需求分析过程需求分析人员必须与用户不断、反复地交流和商讨，使用户需求逐步准确、一致、完全。方法：抽象、问题分解、快速原型、多视点等面向数据流的分析方法、面向数据的分析方法、面向对象的分析方法工具：RationalRose,WitClass,VisualModel57

需求分析阶段性产品软件需求规格说明书SRS用软件需求规格说明语言描述软件系统的功能需求、性能需求、接口需求、设计需求、软件产品的基本结构、采用的开发标准和验收原则等。用户手册概要58软件生命周期总体设计工具

面向数据流的设计方法结构图面向数据的设计方法面向对象的设计方法RationalRose阶段性产品概要设计规格说明书数据库或数据结构设计说明书集成测试计划59软件生命周期详细设计“应该怎样具体地实现这个系统呢？”任务细化概要设计所生成的各个模块,并详细描述程序模块的内部细节(算法，数据结构等)，形成可编程的程序模块，制订单元测试计划阶段新产品详细设计规格说明书,单元测试计划60软件生命周期编码和单元测试任务把软件设计转换成程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”写出的程序应当是结构良好、清晰易读的，且与设计相一致的仔细测试每个单元模块61软件生命周期编码和单元测试方法以详细设计规格说明书为依据、基于某种程序设计语言进行编码。

结构化程序设计、面向对象程序设计工具Eclipse,VisualStudio.NET,etcIDE阶段产品源程序代码62软件生命周期综合测试任务将已测试过的模块按一定顺序组装起来，按规定的各项需求，逐项进行有效性测试。

方法用户参与，以软件需求规格说明书为依据进行测试工具专用测试工具阶段性产品可供用户使用的软件产品(文档，源程序)63软件生命周期软件运行确认测试后的软件安装在用户环境中；测试通过后移交用户使用；尽量扩大软件发行量发挥更大的社会和经济效益；软件使用过程中用户要认真收集软件错误，并撰写软件问题报告和软件维护报告64软件生命周期软件维护软件工作环境不断变化，软件也必然跟着变化，软件必须不断进化以满足客户的需求变化，这是软件产品最根本的特性。软件维护占用软件开发60%以上的工作量。正确性维护扩充性维护适应性维护阶段性产品：软件产品的新版本

65outline软件软件危机软件工程软件生命周期软件过程及模型66软件过程软件过程是近十年来人们关注的焦点。软件过程规定了获取、供应、开发、操作、和维护软件时，要实施的过程、活动和任务。其目的是为各种人员提供一个公共的框架，以便用相同的语言进行交流。软件过程模型是软件过程的抽象表示。软件过程模型也常称为：

软件工程模式软件生存周期模型67软件过程模型建造-修正模型瀑布模型快速原型模型增量模型螺旋模型喷泉模型形式化方法模型基于构件的开发模型RUP敏捷过程与极限编程微软过程模型注：软件过程模型是不断发展的，每种模型都有各自的优缺点，使用时可组合多种模型。68建造－修正模型BuildandFixORCodelikeHell(鲁莽编码)从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作。可能有或可能没有规范发布（可能）69建造－修正模型好处：成本可能很低。只需要很少的专业知识，任何写过程序的人都可以。对于一些非常小的、开发完后就会很快丢弃的软件可以采用。缺点：对于规模稍大的项目，采用这种模型是很危险的。70传统的瀑布模型实际的瀑布模型瀑布模型711.阶段间具有顺序性和依赖性前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。2.推迟实现的观点对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。3.质量保证的观点每个阶段都必须完成规定的文档，是“文档驱动”的模型；每个阶段结束前都要对所完成的文档进行评审，尽早发现问题，改正错误。瀑布模型的特点721.瀑布模型的优点：可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。2.瀑布模型的缺点：只能通过文档了解产品，不经过实践的需求是不切实际的。3.瀑布模型适用于：需求是预知的；软件实现方法是成熟的；项目周期较短。瀑布模型的优缺点73导致问题的主要原因用户与开发者之间存在着差异，由于没有有效的沟通渠道或媒介，这种差异常常无法协调。2.用户由于不熟悉信息技术，可能提出非常含糊甚至不可行的需求，这种需求经常被开发人员所误解。3.经验表明，一旦用户开始使用一个计算机系统他们对目标系统的理解可能又会发生很多变化这导致原始需求失效。更严重的是一个大型系统往往需要很多人，花几年的时间才能完成。在这期间，用户的需求和环境可能发生了大变化，从而使最终的系统不能使用。74

实际上，软件开发，特别是开发的早期阶段，应该是学习和实践的过程，这个活动（action）应该包括开发人员和用户两个方面。尽管用户在开始时说不清楚所要求的未来软件系统(目标系统）会是什么样子（需求），但他们却可以对IT人员开发的系统非常熟练地进行挑剔！这就启发我们能否一开始就给用户展示一个目标系统的的雏形，让用户评头论足，然后逐步进行修改，直至成功。这就是所谓的快速原型模型。

解决办法75快速原型模型快速原型模型快速原型：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

76适用于用户驱动的系统（即需求模糊或随时间变化的系统）软件产品的开发基本上是线性、顺序的改善的用户参与提高系统的实用性、可维护性节省开发的投入、缩短整个软件的开发周期本质就是“快速”优点77原型模型存在的问题用户有时误解了原型的角色：例如他们可能误解原型应该和真实系统一样可靠缺少控制：由于用户可能不断提出新要求，因而原型迭代的周期很难控制额外的花费：研究结果表明构造一个原型可能需要10%额外花费为了尽快实现原型，采用了不合适的技术，运行效率可能会受影响原型法要求开发者与用户密切接触，有时这是不可能的，例如外包软件。78注意虽然有问题存在，但是快速原型模型仍是软件开发的一个有效的过程模型。关键是定义了开始的游戏规则，即用户与开发者两方面必须达成一致：原型被建造仅是为了定义需求，之后被抛弃（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护行之后才被开发。79构建原型的方法1.手工绘制一个书面原型，或采用简单的开发平台，如微机，构造一个功能型界面。2.使用开发工具，快速开发一个初步的、符合用户基本（主要）需求的、可运行的原型。3.借用一个商品化的，或第三方开发的类似系统，或对成功软件的功能复用（部分的或全部的）请用户评价是否符合需求，在明确了基本需求之后，再着手开发自己的原型。80CaseAnalysis281案例：构建原型《全省雨水情监视预警系统》

项目初期需求不是很清晰，难以获得完整的需求，瀑布模型不适用，考虑使用快速原型模型，先构建一个原型系统给用户用，在用户使用的过程中获取更多的需求。

构建好的原型系统就是用户和开发人员之间进行沟通的纽带。82系统介绍 《全省雨水情监视预警系统》根据今年省水利厅的防汛要求可以随时随地地让防汛有关工作人员看到报警信息，当出现紧急情况时，能主动把报警信息推送到这些工作人员的电脑桌面，也可以以短消息或者图片的形式发到工作人员的移动设备上，使相关人员随时了解实时信息，为监视、分析、决策、指挥提供灵活方便的信息获取手段。83“客户端登录”功能原型在本界面用户输入服务器地址、用户名及密码，可以进行登录，也可以勾选自动登录以便下次运行时自动使用已保存的用户名与密码进行登录。84“自动预警”功能原型

当有预警消息传送至桌面，会进行判断客户端是否开启，若客户端开启，则自动打开预警消息的弹窗并显示预警消息，否则会等待下次开启客户端时进行离线传送。85“用户管理”功能原型

用户管理用于管理接受预警信息的用户。用户权限分为3种，超级管理员，管理员，普通用户。超级管理员默认只有一位，可以查看编辑所有用户信息，管理员可以查看编辑自己的用户信息以及普通用户的信息，普通用户仅仅可以查看自己的用户信息。86“用户管理”功能原型87“测站管理”功能原型

测站管理功能实现对所有测站的基础信息的管理，包括测站基础数据浏览与查看、测站的预警标识的设置。测站信息是系统数据的关键基础部分，通过测站的添加与删除，为系统提供了测站的预警范围，同时可以根据预警需要进行设置测站是否预警。88“测站管理”功能原型89“预警管理”功能原型

预警管理页面是对预警信息进行管理，预警信息是预警系统当中重要预警功能重要的组成部分，包括降雨量门槛，流量门槛，水位门槛，水库站门槛。

预警管理页面将对这些门槛进行设置，设置后的门槛值为系统提供预警条件，当预警条件改变时也可以通过预警管理页面编辑对门槛值进行修改。90“预警管理”功能原型91“日志管理”功能原型

日志管理页面用于查询历史记录，可以查询特定用户的预警信息，可以查看历史记录状态是已经发送，未发送，还是通过离线发送，可以对历史记录进行删除。日志管理页面是预警系统结果反馈的重要组成部分。92“日志管理”功能原型93“消息管理”功能原型

消息管理用于用户自定义自己习惯的消息格式，每个用户对于消息格式有不同的要求，消息管理界面用于对所有的消息格式总共9类进行编辑，对于消息格式不正确的格式，系统会自动判断，并且自动替换成正确的消息格式。消息管理功能为用户提供了多样性选择，便于系统扩展。94“消息管理”功能原型95增量模型

增量模型把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。96增量模型需求分析验证规格说明验证概要设计验证针对每个构件，完成详细设计、编码和集成、经测试后交付给用户维护97增量模型适用于：适用于需求经常改变的软件开发过程。如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。98螺旋模型螺旋模型的基本思想：使用原型及其他方法来尽量降低风险。把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。

简化的螺旋模型99完整的螺旋模型100螺旋模型适用于：特别适用于庞大、复杂并具有高风险的系统。适用于内部开发的大规模软件项目。101支持软件复用。利用预先包装好的软件构件来构造应用系统。领域分析构件可变性分析构建可复用构件领域模型领域基准体系结构图可复用构件库分析体系结构设计获取构件构件特化和修改评价构件组装和测试开发未找到构件的部分应用系统工程应用系统领域工程基于构件的开发模型102形式化方法是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求