第一章软件工程学概述.docx

第一章软件工程学概述.docx

《第一章软件工程学概述.docx》由会员分享，可在线阅读，更多相关《第一章软件工程学概述.docx（18页珍藏版）》请在冰豆网上搜索。

第一章软件工程学概述

第一章软件工程学概述

一、软件及其特点

软件：

是程序、数据和相关文档的完整集合。

程序是为了解决某一问题、按事先设计的功能和性能要求、用程序设计语言描述的适合计算机执行的语句序列；数据是使程序能正常操纵信息的数据结构；文档是描述程序、数据和系统开发及使用的各种图文资料。

文档的作用是：

①记录软件开发活动和阶段性成果，具有永久性，可供人或机器阅读；②用于专业人员和用户之间的通信和交流；③控制软件生产过程；④管理、维护、介绍软件产品。

软件的特点：

软件是逻辑产品，而不是物理产品（如硬件）。

其特点为：

（1）具有抽象性，缺乏可见性，可以记录在纸上，存储器中，可以运行，但无法看到它的形态。

（2）软件本身是复杂的。

软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。

（3）软件中存在的潜伏错误，不像硬件错误那样比较容易发现和一般都能被排除。

所以，必须对软件开发过程进行质量控制，减少出错。

（4）软件开发更依赖于开发人员的智力、业务素质、人员的组织、合作和管理。

（5）软件开发设计几乎都是从头开始，工作量大、成本高、进度难以估计。

（6）软件开发成功后，可以对原版进行复制，因此存在知识产权问题。

（7）软件不会磨损和老化，但会退化、过时，在使用过程中必须要多次修改（维护）软件。

软件在使用过程中的维护是复杂：

a.纠错性维护----改正运行期间发现的潜伏错误；

b.完善性维护----提高或完善软件的性能；

c.适应性维护----修改软件，以适应软硬件环境的变化；

d.预防性维护----改进软件未来的可维护性和可靠性。

软件具有生命周期，一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生命周期。

（8）相当多的软件工作涉及到社会因素。

许多软件的开发和运行涉及机构、体制及管理方式等问题，甚至涉及到人的观念和人们的心理。

社会因素直接影响到项目的成败。

二、软件发展的四个阶段

第一阶段----20世纪60年代中期以前，软件通常只是规模较小的程序；软件开发处于个体化生产状态；软件设计通常是人们头脑里进行的一个隐含的过程；除了程序清单之外，没有其他的文档资料被保存下来。

在这一阶段中，软件还没有系统化的开发方法；目标主要集中在如何提高时空效率上。

第二阶段----从20世纪60年代中期到70年代末期。

软件开发已进入了作坊式生产方式，即出现了“软件作坊”；软件开发开始形成产品；基本沿用前面的开发方法。

因此，从20世纪60年代末开始，出现了逐步比较严重的“软件危机”，“软件工程”被提出。

第三阶段----从20世纪70年代中期到20世纪80年代末期。

软件开发进入了产业化生产，即出现了众多大型的“软件公司”。

在这一阶段，软件产品急剧增加，软件规模迅速加大，软件开发开始采用了“软件工程”的方法，质量也有了很大的提高。

第四阶段----从20世纪80年代末期开始的。

这是一个软件产业大发展的时期。

也是软件工程大发展的时期，人们开始采用面向对象的技术和可视化的集成开发环境。

迄今为止，我们仍然没有彻底摆脱“软件危机”的困扰，软件已经成为限制计算机系统发展的瓶颈。

为了更有效地开发与维护软件，软件工作者在20世纪60年代后期开始认真研究消除软件危机的途径。

借助于计算机科学与技术、数学、管理科学与工程等诸多学科，逐渐形成了一门新兴的工程学科----计算机软件工程学（通常简称为软件工程）。

三、软件危机

1、什么是软件危机----软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题和难题。

它包括两方面：

如何开发软件，以满足对软件日益增长的需求；如何维护数量不断增长的已有软件。

2、软件危机的典型表现P2

（1）对软件开发成本和进度的估计常常很不准确。

常常出现实际成本比估算成本高出一个数量级、实际进度比计划进度拖延几个月甚至几年的现象。

而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。

这些都降低了开发商的信誉，引起用户不满。

（2）用户对已完成的软件不满意的现象时有发生。

P9

（3）软件产品的质量往往是靠不住的。

P10

（4）软件常常是不可维护的。

P10

（5）软件通常没有适当的文档资料。

文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。

软件开发中文档的作用：

P2，P11

（6）软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。

（7）开发生产率提高的速度远跟不上计算机应用普及的需求。

3、产生软件危机的原因

（1）来自软件自身的特点P3，P14~15

（2）软件开发与维护的方法不当P3~4，P17~24

a.对软件缺乏正确的认识，认为“软件就是程序，软件开发就是编写程序并使之运行”；忽视问题定义、可行性研究和需求分析等；P20

b.缺乏有力的方法学的指导和有效的开发工具的支持。

软件开发过多地依靠程序员的“技巧”，从而加剧了软件产品的个性化；

c.只重视程序，而忽视软件的完整配置；

d.轻视软件维护。

另外，由于前面的原因导致软件维护费用急增；

e.面对日益增长的软件需求，人们显得力不从心。

从某种意义上说，解决供求矛盾将是一个永恒的主题。

4、缓解软件危机的途径

（1）为了消除软件危机，首先应该对计算机软件有一个正确的认识。

首先，应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。

一个软件必须由一个完整的配置组成，软件是程序、数据及相关文档的完整集合。

其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当地处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。

更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

（2）使用现代工程学的原理、技术和方法进行软件的开发、管理、维护和更新。

许多计算机和软件科学家尝试，把其它工程领域中行之有效的工程学知识运用到软件开发工作中来。

经过不断实践和总结，最后得出一个结论：

按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一个主要出路。

（3）开发和使用更好的软件工具，支持软件开发的全过程。

总之，为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。

于是，人们提出了“软件工程”的概念。

软件开发不再是某种个体劳动的神秘技巧，而是一种组织良好、管理严密、各类人员协调配合、共同完成的工程项目。

软件工程从管理和技术两个方面研究如何开发和维护计算机软件，是计算机科学技术的一个新的研究领域。

四、软件工程

1、软件工程的定义

采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。

（1）1968年首次提出的定义：

用工程、科学和数学的原则与方法开发、维护计算机软件的有关技术和管理方法。

（2）1993年IEEE的定义：

软件工程是：

①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。

”

软件工程由方法、工具和过程三部分组成，称软件工程的三要素。

①软件工程中的各种方法为软件开发提供了“如何做”的技术。

它包括了多个方面，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。

②软件工程使用的软件工具能够自动或半自动地支持软件的开发、管理和文档的生成。

③软件工程中的过程是贯穿于整个工程的各个环节，是将软件工程的方法和工具综合起来，合理、及时地进行计算机软件开发的过程。

过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。

2、软件工程的本质特征P6~7，P31~36

3、软件工程的7条基本原理P7~9，P39~46

这7条原理被认为是确保软件产品质量和开发效率的原理的最小集合，又是相互独立、缺一不可、相当完备的最小集合。

4、软件工程的主要目标：

使软件系统向高性价比方向发展，在给定成本、进度的前提下，最终获得项目的成功。

成功指的是达到以下几个主要目标：

（1）付出较低的开发成本

（2）达到要求的软件功能

（3）取得较好的软件性能（时、空效率和可靠性）

（4）开发的软件易于移植

（5）需要较低的维护费用

（6）能按时完成开发任务，及时交付使用。

五、软件工程方法学

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（methodology），也称为范型（paradigm）。

软件工程方法学包含3个要素：

方法、工具和过程。

其中，方法是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；工具是为运用方法而提供的自动的或半自动的软件工程支撑环境；过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。

1、传统方法学

在软件工程中，把面向对象方法产生之前的软件开发方法统称为传统的开发方法，主要有面向数据流的结构化方法和面向数据结构的Jackson方法。

P9~10，P49~52

其共同特点是：

（1）采用结构化技术，

（2）采用生命周期方法学

（3）每一个阶段结束之前都必须进行正式严格的技术审查和管理复审

（4）强调文档的作用

（5）数据和操作分离，因而不利于软件的维护（修改、更新）。

2、面向对象方法学

与传统方法相反，面向对象方法把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。

其特点是：

（1）将对象作为融合了数据及其对数据的操作行为的软件构件，用对象分解取代了传统的功能分解，最终的软件产品由许多较小的、基本独立的对象组成。

从而使描述问题的问题空间（也称为问题域）与实现解法的解空间（也称为求解域）在结构上尽可能一致。

（2）把所有对象划分成类。

分类，模拟人类从特殊到一般的归纳思维过程。

类是对具有相同数据和相同操作的一组相似对象的定义。

（3）按照父类与子类的关系，把相关类组织成一个层次结构的系统。

在类等级中，下层派生类自动拥有上层基类中定义的数据和操作，这种现象称为继承。

继承，模拟人类从一般到特殊的演绎思维过程。

（4）对象之间仅能通过发送消息互相联系。

（5）软件的重用性好。

六、软件的生命周期

一个软件，从定义、开发、使用和维护，直到最终退役，所经历的全过程称为软件生命周期。

可将软件生命周期划分为3个时期，每个时期包含若干个阶段。

3个时期是：

软件定义、软件开发、软件运行与维护。

1、软件定义（系统分析）。

软件定义时期的任务是：

确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。

这个时期的工作通常又称为系统分析，由系统分析员负责完成。

软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。

（1）问题定义，确定系统要解决的问题是什么。

成果：

关于问题性质、工程目标和工程规模的报告。

P12，P63

（2）可行性研究，确定问题是否有可用的、能行得通的解（包括：

技术、经济、操作、社会等方面的可行性）。

成果：

可行性研究报告。

P64

（3）需求分析，确定软件系统的必须实现的功能、必须达到的性能、必须满足的运行环境要求。

成果：

软件需求规格说明书（SRS），内容包括系统（子系统）的名称、功能描述、接口、基本数据结构、性能、设计需求、开发标准、验收原则等。

P12，P65~66

2、软件开发。

开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：

总体设计，详细设计，编码和单元测试，综合测试。

其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。

（1）总体设计（概要设计），回答“怎样实现目标系统”。

建立系统的总体结构，划分子系统；确定系统由哪些模块组成，各子系统间、各模块间的关系（包括定义各子系统接口界面和各功能模块的接口，设计全局数据库或数据结构，规定设计约束，制定组装测试计划）。

成果：

概要设计说明书、数据库或数据结构说明书、系统的组装测试计划等文档。

P12~13，P67~68

（2）详细设计，设计每个程序模块的内部细节，包括数据结构、算法以及各程序模块间的接口信息，并设计模块的单元测试计划。

成果：

详细设计规格说明（或称“模块开发卷宗”）和单元测试计划等详细设计文档。

以上

（1）、

（2）又合称为软件设计。

（3）编码（编程）和单元测试，根据详细设计规格说明，选用某种程序设计语言把详细设计的结果转化为机器可运行的源程序模块；运行和调试每一个程序模块；每编写出一个程序模块的源程序，调试通过后，即对该模块进行测试。

成果：

按一定规则存在盘上的通过了单元测试的各功能模块的集合；详细的单元测试报告等文档。

（4）综合测试，通过各种类型的测试（及相应的调试）使软件达到预定的要求。

最基本的测试是集成测试和验收测试。

成果：

①满足概要设计要求、可运行的软件系统和源程序清单；组装测试报告等文档。

②验收测试报告、项目开发总结报告，向用户提交的源程序清单、最终用户手册、操作手册等文档资料；由专家、用户负责人、软件开发和管理人员组成软件评审小组对软件验收测试报告、测试结果和软件进行评审，最终验收软件产品。

以上（3）、（4）又合称为软件实现。

三种不同的软件测试：

单元测试、集成测试、验收测试：

P13，P70

*3、软件运行与维护。

软件技术人员通过各种维护活动使软件系统持久满足用户需要。

具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。

P14，P72

通常对维护时期不再进一步划分阶段，但每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

每个维护都要经历提出维护要求、分析维护要求、提出维护方案、审批维护方案、确定维护计划、修改软件设计、修改程序、测试程序、评审、验收等步骤。

成果：

①更新后的软件产品；②准确记录维护活动的文档。

七、软件过程

软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

（对比软件的生命周期）

软件过程定义了运用技术方法的顺序、应交付的文档资料、为保证质量和协调软件变化必须采取的管理措施，以及标志完成了相应开发活动的里程碑。

也就是说，科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。

通常，一个任务集合包括一组软件工程任务、里程碑和应该交付的产品。

软件过程包括制作软件产品的一组活动及其结果，这些活动主要由软件人员来完成。

软件活动主要有：

软件描述：

P—Plan，规定软件的功能及其运行的限制；

软件开发：

D—Do，产生满足规格说明的软件；

软件有效性验证：

C—Check，确认软件能够完成客户提出的要求；

软件进化：

A—Action，为满足客户的变更要求，软件必须在使用的过程中进化。

通常使用生命周期模型（也称为软件开发模型、过程模型）简洁地描述软件过程。

生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的顺序。

它是软件开发过程的概括，它为软件开发过程提供原则和方法，并为软件工程管理提供里程碑和进度表。

因此，软件开发模型也是软件工程的重要内容。

主要的几种软件模型有：

1、瀑布模型

是最早使用的软件生命周期模型之一。

在它的描述中，软件活动从一个阶段到另一个阶段逐次下降，其工作流程形式上很像瀑布，因此被称为瀑布模型。

P78

瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。

它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。

因此，它是一种以文档作为驱动的模型。

（1）瀑布模型的特点P15~16，P79~81

（2）传统的瀑布模型与改进的瀑布模型P78、P82~83

（3）瀑布模型的优点P16，P84

（4）瀑布模型的缺点P16，P85

在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。

在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。

很多错误只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。

*2、快速原型模型

P86

其基本思想是：

软件开发人员根据用户提出的软件基本需求快速开发一个原型，以便向用户展示软件系统应有的一部分或全部功能和性能，同时使用户熟悉系统。

在征求用户对原型的初步意见后，进一步使需求完全化、精确化，并据此改进、完善原型。

如此迭代，直到软件开发人员和用户都通过原型确认软件系统的需求并达成一致的理解为止。

软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤。

P88（对比P83改进的瀑布模型）

（1）快速原型模型主要包括两个阶段：

（I）原型开发阶段

软件开发人员快速建立一个能反映用户主要需求的原型系统。

开发原型的主要途径有：

①仅模拟软件系统的人机界面和人机交互方式；②真正开发一个原型；③找一个或几个正在运行的类似软件进行比较。

让用户在计算机上试用原型系统。

通常，用户试用之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。

如果某个部分是比较成熟的功能模块，可以把这部分直接用到最终的软件产品中。

（II）目标软件开发阶段

确认对软件系统的需求达到了与用户一致的理解，就进一步开发实际系统（进行软件生命周期的其他阶段）。

在实际工作中，由于种种原因，大多数原型都被废弃不用，仅仅把建立原型的过程当作帮助定义软件需求的一种手段。

（2）特点：

开发过程基本上是线性的；（原因有二：

P17，P89）

加快了开发过程，降低了开发成本；

原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架；

它适合于那些不能预先确切定义需求的软件系统的开发，适合于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。

（3）原型的作用：

P90

（4）建立原型的工具：

P90

3、增量模型

其基本思想是：

把一个软件产品划分为一系列的增量构件来设计、编码、集成和测试，并逐个添加到软件产品中去，逐步向用户提交产品。

每个构件能够完成特定的功能。

特点：

P18~19，P91~94

构件的分解要易于测试、规模适中

软件的实现和维护阶段没有明显的分界线

用户在很短时间内就可以使用产品的部分功能

用户适应新产品的时间较充裕

软件的体系结构是开放的，易于扩充和维护

从某种意义上说，增量模型本身是自相矛盾的，目前实用意义不大

4、螺旋模型

（1）引入螺旋模型的原因：

软件风险，普遍存在于软件开发项目中，项目越大，风险越大。

软件风险可能在不同程度上损害软件开发过程和软件产品质量。

存在哪些风险：

产品交付给用户后用户可能不满意；

到了预定的交付日期软件可能还未开发出来；

实际的开发成本可能超过预算；

产品完成前一些关键的开发人员“跳槽”了；

产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件

等等。

所以，需

要采取适当措施减少或消除风险。

（2）简化的螺旋模型是在快速原型模型的基础上扩展而成的，把它看作在每个阶段之前都增加了风险分析过程的快速原型模型

。

P101

（3）完整的螺旋模型，将瀑布模型与原型模型结合起来，并且加入前两种模型均忽略了的风险分析（图1.8）P102。

原型是每一步结束的阶段性成果，软件工程始于原型、终于原型，螺旋的每一周，实际上是软件开发过程的一次迭代，软件系统就生成一个新的版本（原型），它是对目标系统的一个逼近。

经过若干次迭代后，系统应该尽快地收敛于用户可以接受的目标范围，否则也有可能夭折。

（4）螺旋模型主要适用于内部开发的大规模软件项目。

主要优、缺点：

P20~21，P103~104

（5）在螺旋模型中，开发和维护过程没有本质的区别，都是螺旋中的一周。

5、喷泉模型

是近几年提出来的软件生存周期模型。

它是以面向对象的软件开发方法为基础，以用户需求为动力，以对象来驱动的模型。

“喷泉”一词本身体现了迭代和无间隙特性。

系统某个部分工作常常重复多次，相关功能在每次迭代中随之加入演进的系统。

所谓无间隙是指在开发活动，即分析、设计和编码之间不存在明显的边界。

该模型很自然地支持软部件的重用。

6、Rational统一过程（从第5版开始才引入）

六条很有效的开发经验：

P22~23

（1）迭代式开发；

（2）管理需求；

（3）使用基于构件的体系结构；

（4）可视化建模；

（5）注重软件质量的评估；

（6）控制软件变更。

RUP的生命二维周期模型

（1）核心工作流（软件过程中的任务）：

P23~24

（2）通过一次或多次迭代完成的工作阶段（软件过程中的步骤）：

P24~25

（3）迭代开发模式：

P25

7、其他软件过程模型

基于构件的软件工程模型：

构件（components）：

可重用的软件成份

形式化方法模型

敏捷过程和极限编程P25~28

微软过程P29~31

八、本章作业

P32~331、3、4、7