《现代大学计算机基础》课件第11章.ppt

1、第11章 软件工程第11章 软件工程 11.1 软件危机与软件工程软件危机与软件工程 11.2 可行性研究可行性研究 11.3 需求分析需求分析 11.4 概要设计概要设计 11.5 详细设计和编码详细设计和编码 11.6 软件测试软件测试 11.7 软件维护软件维护 第11章 软件工程11.1 软件危机与软件工程软件危机与软件工程11.1.1 软件的发展、定义及特点软件的发展、定义及特点1.软件的发展软件的发展计算机硬件的发展遵循摩尔定律，即每18个月芯片的性能提高一倍。但软件的发展也非常迅速，在软件体系结构上，经历了从主机结构到文件服务器结构，从客户端/服务器到基于Internet的浏览器

2、/服务器结构的变化；在程序语言上，经历了从机器语言到汇编语言，从高级语言到第四代语言的变化；在开发工具上，经历了从分离开发工具到集成的可视化开发工具，从简单的命令行调试器到多功能调试器等变化。第11章 软件工程2.软件的定义软件的定义软件是用户与硬件之间的接口界面。用户主要是通过软件与计算机进行交流。软件是计算机系统设计的重要依据。为了方便用户，使计算机系统具有较高的总体效用，在设计计算机系统时，必须通盘考虑软件与硬件的结合，以及用户的要求和软件的要求。因此，我们可将软件定义如下：(1)在运行中能够提供所要求的功能和性能的指令或计算机程序集合。(2)使程序能够正确运行的数据结构。(3)描述程序

3、功能需求以及程序如何操作和使用所要求的文档。第11章 软件工程3.软件的特点软件的特点在计算机系统中，软件是一个逻辑部件，而硬件是一个物理部件。因此，软件相对硬件而言有许多特点。为了能全面、正确地理解计算机软件及软件工程的重要性，必须了解软件的特点。软件的特点可归纳如下：(1)软件是一种实体，不是具体的物理实体，因而它具有抽象性。人们可以把它记录在介质上，但却无法看到软件的形态，而必须通过测试、分析、思考和判断去了解它的功能、性能及其他特性。(2)软件是通过人们的智力活动，把知识与技术转化成信息的一种产品，是在研制、开发中被创造出来的。一旦某一软件项目研制成功，以后就可以大量地复制同一内容的副

4、本。第11章 软件工程(3)在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题。软件维护比硬件维护要复杂得多。(4)软件的开发和运行经常受到计算机系统的限制，对计算机系统有着不同程度的依赖。为了解除这种依赖，在软件开发中提出了软件移植的问题，并且把软件的可移植性作为衡量软件质量的因素之一。(5)软件的开发尚未完全摆脱手工的开发方式。因此，为了提高软件开发的效率，应促进软件技术的进展，提出和采用新的开发方法。例如，近年来出现的充分利用现有软件的复用技术、自动生成技术和其他一些有效的软件开发工具或软件开发环境，既方便了软件开发的质量控制，又提高了软件开发的效率。第11章 软件工程(6)软件的

5、开发费用越来越高。(7)软件的开发是一个复杂的过程。(8)软件的生产过程较简单，软件生产过程就是复制过程。第11章 软件工程11.1.2 软件危机与软件工程软件危机与软件工程在20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。第11章 软件工程60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高

6、级语言开始出现，操作系统的发展引起了计算机应用方式的变化，大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件的生产方式，提高软件生产率，软件危机开始爆发。1968年，北大西洋公约组织(NATO)的计算机科学家在联邦德国召开国际学术会议，讨论软件危机(Software Crisis)问题。在这次会议上正式提出并使用了“软件工程”这个名词，一门新兴的工程学科就此诞生。第11章 软件工程1.什么是软件危机什么是软件危机软件危机是指在软件开发和维护过程中所遇到的一系列严重问题，

7、这些问题皆可能导致软件产品的寿命缩短、甚至夭折。这些问题绝不仅仅是“不能正常运行”的软件才具有的，实际上几乎所有软件都不同程度地存在这些问题。概括地说，软件危机包含下述两方面的问题：如何开发软件，怎样满足对软件的日益增长的需求；如何维护数量不断膨胀的已有软件。具体地说，软件危机主要有下述一些表现：第11章 软件工程(1)对软件开发成本和进度的估计常常很不准确。实际成本比估计成本有可能高出一个数量级，实际进度比预期拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。(2)产品不符

8、合用户的实际需要。(3)软件产品的质量差。软件可靠性和质量保证的定量概念刚刚出现不久，软件质量保证技术(审查、复审和测试)没有贯穿到软件开发的全过程中，这些都导致软件产品发生质量问题。第11章 软件工程(4)软件的可维护性差。很多程序中的错误是难以改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需要在原有程序中增加一些新的功能。没能实现软件的可重用，人们仍然在重复开发功能类似的软件。(5)软件文档资料通常不完整也不合格。软件文档资料应该是在软件开发过程产生出来的，而且应该是“最新的”(即和程序代码完全一致的)。软件开发组织的管理人员可以利用它们作为“里程碑”，来管理和评价软件开

9、发工程的进展状况；软件开发人员可以利用它们在软件开发过程中准确地交流信息；对于软件维护人员而言，这些文档资料更是必不可少的。第11章 软件工程(6)软件成本在计算机系统总成本中所占的比例逐年上升。(7)软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。以上列举的仅仅是软件危机的一些明显的表现，与软件开发和维护有关的问题远远不止这些。第11章 软件工程2.产生软件危机的原因产生软件危机的原因通过对一系列危机现象的研究，人们总结发现，产生软件危机的原因主要体现在以下几个方面。(1)软件的不可见特性。软件不同于

10、硬件，它是计算机系统中的逻辑部件，缺乏“可见性”。例如，软件中存在的程序行错误，就必须等到这行程序执行时才有可能被发现。软件的不可见特性也使得对软件项目的量化管理更难实施，对软件质量的量化评价更难操作。(2)软件系统规模庞大。软件成为产品以后已不同于早期程序，随着它的功能的增多，其规模、复杂程度越来越大。例如，1968年美国航空公司订票系统达到30万条指令。第11章 软件工程(3)软件生产工程化管理程度低。软件生产的工程化管理是软件作为产品所必需的，这意味着软件也需要像硬件一样，在软件分析、设计完成之后，才能考虑软件的实现。应该说，工程化管理能够降低解决问题的代价。但是，许多软件的开发则往往是

11、在分析、设计没有完成的情况下，就已经进入编码实现阶段。由于前期准备工作不充分，致使软件项目管理纷乱，严重影响软件项目成本、开发进度和软件质量。(4)对用户需求关心程度不够。软件开发机构不熟悉用户业务领域。软件技术人员所关注的仅仅是计算机技术，它们不太愿意和用户沟通，轻视对用户的需求调查，也缺乏有效的用户调查策略、手段。由于这些问题的存在，使得用户的需求意愿不能充分反映，或被错误理解。第11章 软件工程实际上，软件是为用户开发的，只有用户才能真正了解他们自己的需要。由于没有对用户做大量深入细致的调查研究，以致软件需求规格定义不准确，并最终使得完成后的软件不能适应用户的应用需要。(5)对软件维护重

12、视程度不够。软件开发缺乏统一的规范。在软件产品开发过程中，开发者很少考虑到这个软件今后还需要提供维护。但是，软件的使用周期漫长，软件错误具有隐蔽性，许多年之后软件仍可能需要改错。另外，软件的工作环境也可能会在几年后发生改变；用户也可能在软件运行几年以后，要求对它增加新的功能。这些都是属于软件维护问题。实际上，软件的可维护性是衡量软件质量的一项重要指标，软件可维护性程度高，软件就便于修正、改版和升级，由此可以使软件具有更长的使用寿命。第11章 软件工程(6)软件开发工具自动化程度低。尽管软件开发工具比30年前已经有了很大的进步，但直到今天，软件开发仍然离不开工程人员的个人创造与手工操作，软件生产

13、仍不可能像硬件设备的生产那样，达到高度的自动化。第11章 软件工程3.消除软件危机的途径消除软件危机的途径为了消除软件危机，首先应该对计算机软件有一个正确的认识。正如前面所述，应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成，事实上，软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当地处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。虽然表面上看来在这个定

14、义中列出了软件的5个配置成分，但是，方法和规则通常是在文档中说明并在程序中实现的。第11章 软件工程更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。第11章 软件工程应该开发和使用更好的软件工具。正如机械工具可以“放大

15、”人类的体力一样，软件工具可以“放大”人类的智力。在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境。总之，为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。第11章 软件工程4.软件工程软件工程软件工程是指导计算机软件开发和维护的工程学科，是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证

16、明正确的管理技术和当前能够得到的最好的技术方法结合起来，这就是软件工程。自从1968年在联邦德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来，研究软件工程的专家学者陆续提出了100多条关于软件工程的准则。著名软件工程专家B.W.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理：第11章 软件工程(1)用分阶段的生命周期计划进行严格的管理。有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。在软件开发与维护的漫长的生命周期中，需要完成许多性质各异的工作。这条基本原理意味着，应该把软件生命周期划分成若干

17、个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划第11章 软件工程(2)坚持进行阶段评审。当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。这样说至少有两个理由：第一，大部分错误是在编码之前造成的，例如，根据Boehm等人的统计，设计错误占软件错误的63%，编码错误仅占37%；第二，错误发现与改正得越晚，所需付出的代价也越高。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。第

18、11章 软件工程(3)实行严格的产品控制。在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价。但是，在软件开发过程中改变需求又是难免的，只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。各个阶段产生的文档或程序代码基准配置管理也称为变动控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件(包括尚在开发过程中的软件)，就随意

19、进行修改。第11章 软件工程(4)采用现代程序设计技术。从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。(5)应能清楚地审查软件工程结果。软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员(或开发小组)的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使

20、得所得到的结果能够清楚地审查。第11章 软件工程(6)开发小组的人员应该少而精。这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。第11章 软件工程(7)承认不断改进软件工程实践的必要性。遵循上述6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述6条原理

21、并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步，因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验，例如，收集进度和资源耗费数据，收集出错类型和问题报告数据等。这些数据不仅可以用来评价新的软件技术的效果，而且可以用来指明必须着重开发的软件工具和应该优先研究的技术。第11章 软件工程11.1.3 软件工程方法学软件工程方法学软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源

22、，以达到既定目标的过程。通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学。软件工程方法学包含3个要素：方法、工具和过程。其中，方法是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；工具是为运用方法而提供的自动的或半自动的软件工程支撑环境；过程是为了获得髙质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。第11章 软件工程目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。1.传统方法学传统方法学传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件

23、工具或软件工程环境来支持结构化技术的运用。这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。采用这种方法学开发软件的时候，从对问题的抽象逻辑分析开始，一个阶段一个阶段地顺序进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，第11章 软件工程而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审査和管理复审，从技术和管理两个方面对这个阶段的开发成果进行检查，通过之后

24、这个阶段才算结束；如果没通过检查，则必须进行必要的返工，而且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的即和所开发的软件完全一致的”高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚第11章 软件工程准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时奠定了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生命周期的下一个阶段之前，必须补足这些遗漏的细节。目前，传统方法学仍然是人们在开发软件时使用得十分广泛的软件工程方法学。这种方法学历史悠久，为广大软件工程

25、师所熟悉，而且在开发某些类型的软件时也比较有效。第11章 软件工程2.面向对象方法学面向对象方法学当软件规模庞大，或者对软件的需求是模糊的或会随时间变化而变化的时候，使用传统方法学开发软件往往不成功，此外，使用传统方法学开发出的软件，维护起来仍然很困难。数据和对数据的处理原本是密切相关的，把数据和操作人为地分离成两个独立的部分，自然会增加软件开发与维护的难度。与传统方法相反，面向对象方法把数据和行为看成是同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。第11章 软件工程概括地说，面向对象方法学具有下述4个要点。(1)把对象作为融合了数据及在数据上的操作行为的统一的软

26、件构件。面向对象程序是由对象组成的，程序中任何元素都是对象，复杂对象由比较简单的对象组合而成。也就是说，用对象分解取代了传统方法的功能分解。(2)把所有对象都划分成类(Class)。每个类都定义了一组数据和一组操作，类是对具有相同数据和相同操作的一组相似对象的定义。数据用于表示对象的静态属性，是对象的状态信息，而施加于数据之上的操作用于实现对象的动态行为。第11章 软件工程(3)按照父类(或称为基类)与子类(或称为派生类)的关系，把若干个相关类组成一个层次结构的系统也称为类等级。在类等级中，下层派生类自动拥有上层基类中定义的数据和操作，这种现象称为继承。(4)对象彼此间仅能通过发送消息互相联系

27、。对象与传统数据有本质区别，它不是被动地等待外界对它施加操作，相反，它是数据处理的主体，必须向它发消息请求它执行它的某个操作以处理它的数据，而不能从外界直接对它的数据进行处理。也就是说，对象的所有私有信息都被封装在该对象内，不能从外界直接访问，这就是通常所说的封装性。第11章 软件工程面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程，从而使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。用面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。面向对象方法在概念和

28、表示方法上的一致性，保证了在各项开发活动之间的平滑(即无缝)过渡。面向对象方法普遍进行的对象分类过程，支持从特殊到一般的归纳思维过程；通过建立类等级而获得的继承性，支持从一般到特殊的演绎思维过程。第11章 软件工程正确地运用面向对象方法学开发软件，则最终的软件产品由许多较小的、基本上独立的对象组成，每个对象相当于一个微型程序，而且大多数对象都与现实世界中的实体相对应，因此提高了软件的可理解性，简化了软件的开发和维护工作。对象是相对独立的实体，容易在以后的软件产品中重复使用，因此，面向对象范型的另一个重要优点是促进了软件重用。面向对象方法特有的继承性和多态性，进一步提高了面向对象软件的可重用性。

29、第11章 软件工程11.1.4 软件生命周期软件生命周期概括地说，软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组成，每个时期又进一步划分成若干个阶段。软件定义时期的任务是：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。第11章 软件工程开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：概要设计，详细设计，编码和单

30、元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。第11章 软件工程下面简要介绍软件生命周期每个阶段的基本任务。1.问题定义问题定义问题定义阶段必须回答的关键问题是：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能

31、是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。第11章 软件工程2.可行性研究可行性研究这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程，也就是在较抽象的高层次上进行的分析和设计过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解

32、决办法。可行性研究的结果是客户作出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。第11章 软件工程3.需求分析需求分析这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样用软件实现人们的要求，但是对特定用户的具体要求并不完

33、全清楚。因此，系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。第11章 软件工程在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书第11章 软件工程4.概要设计概要设计这个阶段必须回答的关键问题是：“概括地说，应该怎样实现目标系统？”。首先，应该设计出实现目标系统的几种可能的方案。通常至少应该设计出低成本、中等成本和高成本3种方案。软件工程师应该用适当的表达工

34、具描述每种方案，分析每种方案的优缺点，并在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。此外，还应该制定出实现最佳方案的详细计划。如果客户接受所推荐的方案，则应该进一步完成下述的另一项主要任务。第11章 软件工程上述设计工作确定了解决问题的策略及目标系统中应包含的程序，但是，怎样设计这些程序呢？软件设计的一条基本原理就是，程序应该模块化，也就是说，一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。因此，概要设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。第11章 软件工程5.详细设计详细设计概要设计阶段以比较抽象概括的方式提出了解决问题的

35、办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：应该怎样具体地实现这个系统呢？这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。第11章 软件工程6.编码和单元测试编码和单元测试这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言(必要时用汇编语言)，把详细设计的结

36、果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。第11章 软件工程7.综合测试综合测试这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定(通常在需求分析阶段确定)，由用户(或在用户积极参加下)对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。第11章 软件工程为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效

37、地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。第11章 软件工程8.软件维护软件维护维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有4类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件，为将来的维护活动预

38、先做准备。第11章 软件工程虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求(或报告问题),分析维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了次压缩和简化了的软件定义和开发的全过程。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。第11章 软件工程以上根据应该完成的任务的性质，把软件生命周期划分成8个阶段。在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素，都影响阶段的划分。事实上，承担的软件项目不同，应该完成的任务也有差异，没有一

39、个适用于所有软件项目的任务集合。适用于大型复杂项目的任务集合，对于小型简单项目而言往往就过于复杂了。第11章 软件工程11.2 可可行行性性研研究究11.2.1 可行性研究的任务可行性研究的任务当接受一个软件开发任务时，就进入了软件生命周期的第一阶段，即进行软件项目分析。众所周知，并不是所有问题都有简单明确的解决办法，事实上，许多问题不可能在预定的系统规模之内解决。如果问题没有可行性的解，那么花费在这项开发工程上的任何时间、资源、人力和经费都是无谓的浪费。因此通过软件项目分析可以知道问题有无可行的解，进而避免人力、物力和财力上的浪费。第11章 软件工程软件项目可行性研究的目的就是用最小的代价在

40、尽可能短的时间内确定问题是否能够解决。也就是说，软件项目可行性研究的目的不是解决问题，而是确定问题是否值得去解，研究在当前的具体条件下，开发新系统是否具备必要的资源和条件。因此，软件项目可行性研究实质上是压缩简化了的系统分析和设计的过程，也就是说在较高层次上以较抽象的方式进行的系统分析和设计的过程。首先需要进一步分析和澄清问题定义。在问题定义阶段初步确定规模和目标，如果是正确的，就进一步加以肯定；如果有错误，就应该及时改正；如果对目标系统有任何约束和限制，必须把它们清楚地列举出来。第11章 软件工程在澄清了问题定义之后，分析员应该导出系统的逻辑模型。然后从逻辑模型出发，探索若干种可供选择的主要

41、解法(即系统实现方案)。对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述三方面研究每种解法的可行性：(1)技术可行性：使用现有的技术能实现这个系统吗？(2)经济可行性：这个系统的经济效益能超过它的开发成本吗？(3)操作可行性：系统的操作方式在这个用户组织内行得通吗？第11章 软件工程当然，可行性研究最根本的任务是对以后的行动方针提出建议。如果问题没有可行的解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和财力的浪费者；如果问题值得去解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。可行性研究需要的时间长短取决于工程的规模，一般说来，可行性研究的成本只是预

42、期的工程总成本的5%10%。第11章 软件工程11.2.2 可行性研究的步骤可行性研究的步骤一般来说，可行性研究有如下步骤：1.复查系统规模和目标复查系统规模和目标系统分析员应该访问关键人员，仔细阅读和分析有关的资料，以便进一步复查确认系统的目标和规模，改正含糊不清的叙述，清晰地描述对系统目标的一切限制和约束，确保解决问题的正确性，即保证分析员正在解决的问题确定是要求他解决的问题。第11章 软件工程2.研究目前正在使用的系统研究目前正在使用的系统对现有系统功能特点的充分了解是成功开发新系统的前提。对现有系统的研究包括阅读、分析和研究现有系统的各种文档资料，观察系统的运行状况和实地操作系统，收集

43、和分析用户对现有系统的意见等，总结出现有系统的优点和不足，从而得出新系统的雏形。3.导出新系统的高层逻辑模型导出新系统的高层逻辑模型优秀的设计通常总是从现有的物理系统出发，导出现有系统的高层逻辑模型，逻辑模型是由数据流图来描述的，此时的数据流图不需要细化。然后，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。第11章 软件工程4.重新定义问题重新定义问题新系统的逻辑模型实质表达了分析员对新系统的看法。那么用户是否也有同样的看法呢？分析员应该和用户一起再次复查问题定义，再次确定工程规模、目标和约束条件，并修改已发现的错误。软件项目可行性研究的前4个步

44、骤实际上构成了循环：分析员定义问题，分析问题，导出一个试探性的解，在此基础上再次定义问题，再次分析，再次修改，继续这个循环过程，直到提出的逻辑模型完全符合系统目标为止。第11章 软件工程5.导出和评价供选择的方案导出和评价供选择的方案系统分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法供比较和选择。从技术、经济和操作等方面进行分析比较，并估算开发成本、运行费用和纯收入。在此基础上对每个可能的系统进行成本/效益分析。在对提出的各种方案进行比较分析的基础上，向用户推荐一种方案，在推荐的方案中应清楚地表明：(1)本项目的开发价值；(2)推荐这个方案的理由；(3)制定实现

45、进度表，这个进度表不需要也不可能很详细，通常只需要估计生命周期每个阶段的工作量。第11章 软件工程6.推荐行动方针推荐行动方针根据可行性研究结果，做出一个关键性的决定，表明是否进行这项开发工程。分析员必须清楚地表明他对这个关键性决定的建议，并较详细地分析开发此项目成本效益情况，这可作为使用部门的负责人根据经济实力决定是否投资此项工程的依据。第11章 软件工程7.书写计划任务书书写计划任务书把上述材料进行分析汇总，草拟一份描述计划任务的可行性论证报告。此报告应包括以下内容。(1)系统概述。当前系统及其存在的问题的简单描述；新系统的开发目的、目标、业务对象和范围；新系统及其各子系统的功能与特性；新

46、系统与当前系统的比较等。新系统可以用系统流程图来描述，并附上重要的数据流图和数据字典以及加工说明作为补充。(2)可行性分析。这是报告的主体。论述新系统在经济上、技术上、运行上、法律上的可行性，以及对新系统的主客观条件的分析。第11章 软件工程(3)拟定开发计划。包括工程进度表，人员配备情况，资源配备情况，估计出每个阶段的成本、约束条件等。(4)结论意见。综合上述分析，说明新系统是否可行，结论可分为三类：可立即进行、推迟进行、不能和不值得进行。8.提交审查提交审查把上述文档提交给用户和使用部门的负责人仔细审查，以决定是否继续此项工程以及是否接受分析员推荐的方案。第11章 软件工程11.2.3 系

47、统流程图系统流程图在进行软件项目可行性研究时需要了解和分析现有的系统，并以概括的形式表达对现有系统的认识。进入设计阶段以后，应该把设想的新系统的逻辑模型转变成物理模型，因此需要描绘未来的物理系统的概貌。怎样概括地描绘一个物理系统呢？系统流程图是描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件(程序、文件、数据库、表格、人工过程等)。系统流程图表达的是信息在系统各个部件之间流动的情况，而不是对信息进行加工处理的控制过程，因此尽管系统流程图使用的某些符号和程序流程图中用的符号相同，但是它却是物理数据流图，而不是程序流程图。系统流程图的基本符号如表11-1所示。第1

48、1章 软件工程表表11-1 系统流程图的基本符号系统流程图的基本符号第11章 软件工程例如，图11.1是关于“自动阅卷系统”的系统流程图，它所表达的是：阅卷系统首先通过读卡程序读入考试答题卡片上的数据，然后经过阅卷程序计算出成绩并存入成绩数据库，在产生出成绩数据之后，系统可以通过成绩查询程序、成绩分析程序、成绩单打印程序和成绩备份程序，对成绩数据库中的数据进行相关操作。图中的每个符号定义了组成系统的一个部件，而并没有指明每个部件的具体工作过程。图中的箭头指定了系统中信息的流动(逻辑)路径。第11章 软件工程图11.1 自动阅卷系统的系统流程图第11章 软件工程11.2.4 成本成本/效益分析效

49、益分析成本/效益分析的目的是要从经济角度分析开发一个特定的新系统是否划算，从而帮助部门负责人正确地做出是否投资于这项开发工程的决定。成本/效益分析首先要估算待开发系统的开发成本，然后与可能取得的效益(有形的与无形的)进行比较与权衡。1.成本估计成本估计(1)自顶向下成本估计。这类方法着眼于软件的整体。根据被开发项目的整体特性，首先估算出总的开发成本，然后在项目内部进行成本分配。自顶向下成本估计的缺点是对开发中某些局部的问题或特殊困难容易低估，甚至没有考虑到。第11章 软件工程(2)由底向上成本估计。由底向上成本估计是将开发任务分解为许多子任务，子任务又分为子任务，直到每一任务单元的内容都足够明

50、确为止。然后把各个任务单元的成本估计出来，汇合成项目的总成本。由底向上成本估计也有缺点，由于具体工作人员往往只注意自己范围内的工作，对综合测试、质量管理和项目管理等涉及全局的花费可能估计不足，甚至完全忽视，因此就有可能使成本估计偏低。第11章 软件工程(3)算法模型估计。算法模型就是资源模型，是成本估计的又一有效工具，由于任何资源模型都是根据历史数据导出的，因此比较客观，计算结果的重复性也好(即不论什么时候使用模型都能得出同样的结果)。模型估计的关键是要选好适用的模型。模型估计法常与自顶向下估计或由底向上估计结合使用。第11章 软件工程2.费用估计费用估计(1)代码行技术。代码行技术是比较简单