第1章 软件工程概述

第1章 软件工程概述

人类社会已经跨入了21世纪,计算机系统已经渗入人类生活的各个领域,同时计算机软件已经发展成为当今世界最重要的技术领域。研究软件本身则产生了一门重要的学科就是软件工程。软件工程的研究领域包括软件的开发方法、软件的生命周期以及软件的工程实践等。

1.1 软件危机与软件工程的起源

1.1.1 计算机系统的发展历程

20世纪60年代中期以前,是计算机系统发展的早期。在这个时期通用硬件已经相当普遍,软件却是为每个具体应用而专门编写的,大多数人认为软件开发是无须预先计划的事情。这时的软件实际上就是规模较小的程序,程序的编写者和使用者往往是同一个(或同一组)人。由于规模小,程序编写起来相当容易,也没有什么系统化的方法,对软件开发工作更没有进行任何管理。这种个体化的软件环境,使得软件设计往往只是在人们头脑中隐含进行的一个模糊过程,除了程序清单之外,根本没有其他文档资料保存下来。

从20世纪60年代中期到70年代中期,是计算机系统发展的第二代。在这10年中计算机技术有了很大进步。多道程序、多用户系统引入了人—机交互的新概念,开创了计算机应用的新境界,使硬件和软件的配合上了一个新的层次。实时系统能够从多个信息源收集、分析和转换数据,从而使得进程控制能以毫秒而不是分钟来进行。在线存储技术的进步导致了第一代数据库管理系统的出现。

计算机系统发展的第二代的一个重要特征是出现了“软件作坊”,广泛使用产品软件。但是,“软件作坊”基本上仍然沿用早期形成的个体化软件开发方法。随着计算机应用的日益普及,软件数量急剧膨胀。在程序运行时发现的错误必须设法改正;用户有了新的需求时必须相应地修改程序;硬件或操作系统更新时,通常需要修改程序以适应新的环境。上述种种软件维护工作,以令人吃惊的比例耗费资源。更严重的是,许多程序的个体化特性使得它们最终成为不可维护的。“软件危机”就这样开始出现了。1968年北大西洋公约组织的计算机科学家在联邦德国召开国际会议,讨论软件危机问题。在这次会议上正式提出并使用了“软件工程”这个名词,一门新兴的工程学科就此诞生了。

1.1.2 软件危机介绍

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的。实际上,几乎所有软件都不同程度地存在这些问题。概括地说,软件危机包含下述两方面的问题:如何开发软件,以满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。鉴于软件危机的长期性和症状不明显的特征,近年来有人建议把软件危机更名为“软件萧条(depression)”或“软件困扰(affliction)”。不过“软件危机”这个词强调了问题的严重性,而且也已为绝大多数软件工作者所熟悉,所以本书仍将沿用它。

具体来说,软件危机主要有以下一些典型表现。

① 对软件开发成本和进度的估计常常很不准确。实际成本比估计成本有可能高出一个数量级,实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量,从而不可避免地会引起用户的不满。

② 用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员常常在对用户要求只有模糊的了解,甚至对所要解决的问题还没有确切认识的情况下,就仓促上阵匆忙着手编写程序。软件开发人员和用户之间的信息交流往往很不充分,“闭门造车”必然导致最终的产品不符合用户的实际需要。

③ 软件产品的质量往往靠不住。软件可靠性和质量保证的确切定量概念刚刚出现不久,软件质量保证技术还没有坚持不懈地应用到软件开发的全过程中,这些都导致软件产品发生质量问题。

④ 软件常常是不可维护的。很多程序中的错误是非常难改正的,实际上不可能使这些程序适应新的硬件环境,也不能根据用户的需要在原有程序中增加一些新的功能。“可重用的软件”还是一个没有完全做到的、正在努力追求的目标,人们仍然在重复开发类似的或基本类似的软件。

⑤ 软件通常没有适当的文档资料。计算机软件不仅仅是程序,还应该有一整套文档资料。这些文档资料应该是在软件开发过程中产生出来的,而且应该是“最新式的”(即和程序代码完全一致的)。软件开发组织的管理人员可以使用这些文档资料作为里程碑(milestone),来管理和评价软件开发工程的进展状况;软件开发人员可以利用它们作为通信工具,在软件开发过程中准确地交流信息;对于软件维护人员而言,这些文档资料更是至关重要、必不可少的。缺乏必要的文档资料或者文档资料不合格,必然给软件开发和维护带来许多严重的困难和问题。

⑥ 软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程度不断提高,硬件成本逐年下降,然而软件开发需要大量人力,软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续上升。美国在1985年软件成本大约已占计算机系统总成本的90%。

⑦ 软件开发生产率提高的速度,既跟不上硬件的发展速度,也远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象,使人类不能充分利用现代计算机硬件提供的巨大潜力。

以上列举的仅仅是软件危机的一些明显的表现,与软件开发和维护有关的问题远远不止这些。

1.1.3 产生软件危机的原因

在软件开发和维护的过程中存在这么多严重问题,一方面与软件本身的特点有关,另一方面也和软件开发与维护的方法不正确有关。

软件不同于硬件,它是计算机系统中的逻辑部件而不是物理部件。由于软件缺乏“可见性”,在写出程序代码并在计算机上试运行之前,软件开发过程的进展情况较难衡量,软件的质量也较难评价,因此,管理和控制软件开发过程相当困难。此外,软件在运行过程中不会因为使用时间过长而被“用坏”,如果运行中发现错误,很可能是遇到了一个在开发时期引入的在测试阶段没能检测出来的错误,因此,软件维护通常意味着改正或修改原来的设计,这就在客观上使得软件较难维护。

软件不同于一般程序,它的一个显著特点是规模庞大,而且程序复杂性将随着程序规模的增加而呈指数上升。为了在预定时间内开发出规模庞大的软件,必须由许多人分工合作。然而,如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统,更是一个极端复杂困难的问题,不仅涉及许多技术问题,诸如分析方法、设计方法、形式说明方法、版本控制等,更重要的是必须有严格而科学的管理。

软件本身独有的特点确实给开发和维护带来一些客观困难,但是人们在开发和使用计算机系统的长期实践中,也确实积累和总结出了许多成功的经验。如果坚持不懈地使用经过实践考验证明是正确的方法,许多困难是完全可以克服的,过去也确实有一些成功的范例。但是,目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念,在实践过程中或多或少地采用了错误的方法和技术,这可能是使软件问题发展成软件危机的主要原因。

与软件开发和维护有关的许多错误认识和做法的形成,可以归于在计算机系统发展的早期阶段软件开发的个体化特点。错误的认识和做法主要表现为忽视软件需求分析的重要性,认为软件开发就是编写程序并设法使之运行,轻视软件维护等。

事实上,对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。只有用户才真正了解他们自己的需要,但是许多用户在开始时并不能准确具体地叙述他们的需要,软件开发人员需要做大量深入细致的调查研究工作,反复多次地和用户交流信息,才能真正全面、准确、具体地了解用户的要求。对问题和目标的正确认识是解决任何问题的前提和出发点,软件开发同样也不例外。急于求成,仓促上阵,对用户要求没有正确认识就匆忙着手编写程序,这就如同不打好地基就盖高楼一样,最终必然垮台。事实上,越早开始编写程序,完成它所需要用的时间往往越长。

一个软件从定义、开发、使用和维护,直到最终被废弃,要经历一个漫长的时期,这就如同一个人要经过胎儿、儿童、青年、中年和老年,直到最终死亡的漫长时期一样。通常把软件经历的这个漫长的时期称为生命周期。软件开发最初的工作应是问题定义,也就是确定要求解决的问题是什么;然后要进行可行性研究,决定该问题是否存在一个可行的解决办法;接下来应该进行需求分析,也就是深入具体地了解用户的要求,在所要开发的系统(不妨称之为目标系统)必须做什么这个问题上和用户取得完全一致的看法。经过上述软件定义时期的准备工作才能进入开发时期,而在开发时期首先需要对软件进行设计(通常又分为概要设计和详细设计两个阶段),然后才能进入编写程序的阶段,程序编写完之后还必须经过大量的测试工作(需要的工作量通常占软件开发全部工作量的40%~50%)才能最终交付使用。所以,编写程序只是软件开发过程中的一个阶段,而且在典型的软件开发工程中,编写程序所需的工作量只占软件开发全部工作量的10%~20%。

另一方面还必须认识到程序只是完整的软件产品的一个组成部分,在上述软件生命周期的每个阶段都要得出最终产品的一个或几个组成部分(这些组成部分通常以文档资料的形式存在)。也就是说,一个软件产品必须由一个完整的配置组成,软件配置主要包括程序、文档、数据等成分。必须清除只重视程序而忽视软件配置其余成分的糊涂观念。

做好软件定义时期的工作,是降低软件成本提高软件质量的关键。如果软件开发人员在定义时期没有正确全面地理解用户需求,直到测试阶段或软件交付使用后才发现“已完成的”软件不完全符合用户的需要,这时再修改就为时晚矣。

严重的问题是,在软件开发的不同阶段进行修改需要付出的代价是很不相同的。在早期引入变动,涉及的面较少,因而代价也比较低;在开发的中期,软件配置的许多成分已经完成,引入一个变动要对所有已完成的配置成分都做相应的修改,不仅工作量大,而且逻辑上也更复杂,因此付出的代价剧增;在软件“已经完成”时再引入变动,当然需要付出更高的代价。根据美国一些软件公司的统计资料,在后期引入一个变动比在早期引入相同变动所需付出的代价高2~3个数量级。图1.1所示为在不同时期引入同一个变动需要付出的代价随时间变化的趋势。

0101

图1.1 引入同一个变动付出的代价随时间变化的趋势

通过上面的论述不难认识到,轻视维护是一个最大的错误。许多软件产品的使用寿命长达10年甚至20年,在这样漫长的时期中不仅必须改正使用过程中发现的每一个潜伏的错误,而且当环境变化时(如硬件或系统软件更新换代)还必须相应地修改软件以适应新的环境,特别是必须经常改进或扩充原来的软件以满足用户不断变化的需要。所有这些改动都属于维护工作,而且是在软件已经完成之后进行的,因此,维护是极端艰巨复杂的工作,需要花费很大代价。统计数据表明,实际上用于软件维护的费用占软件总费用的55%~70%。软件工程学的一个重要目标就是提高软件的可维护性,减少软件维护的代价。

了解产生软件危机的原因,澄清错误认识,建立起关于软件开发和维护的正确概念,还仅仅是解决软件危机的开始,全面解决软件危机需要一系列综合措施。

1.1.4 消除软件危机的途径

为了消除软件危机,首先应该对计算机软件有一个正确的认识。正如1.1.3小节中讲过的,应该彻底清除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成。事实上,软件是程序、数据及相关文档的完整集合。其中,程序是能够完成预定功能和性能的可执行的指令序列;数据是使程序能够适当地处理信息的数据结构;文档是开发、使用和维护程序所需要的图文资料。1983年IEEE(电气和电子工程师协会)为软件下的定义是:计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。虽然表面上看来在这个定义中列出了软件的5个配置成分,但是,方法和规则通常是在文档中说明并在程序中实现的。

更重要的是,必须充分认识到软件开发不是某种个体劳动的神秘技巧,而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法,特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。

应该推广和使用在实践中总结出来的开发软件成功的技术和方法,并且研究探索更好、更有效的技术和方法,尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。

应该开发和使用更好的软件工具。正如机械工具可以“放大”人类的体力一样,软件工具可以“放大”人类的智力。在软件开发的每个阶段都有许多烦琐重复的工作需要做,在适当的软件工具辅助下,开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机地集合成一个整体,支持软件开发的全过程,则称为软件工程支撑环境。

总之,为了消除软件危机,既要有技术措施(方法和工具),又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

1.2 软件工程

1.2.1 什么是软件工程

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

下面给出软件工程的几个定义。

1983年IEEE给软件工程下的定义是:“软件工程是开发、运行、维护和修复软件的系统方法。”这个定义相当概括,它主要强调软件工程是系统方法而不是某种神秘的个人技巧。

Fairly认为:“软件工程学是为了在成本限额以内按时完成开发和修改软件产品所需要的系统生产和维护技术及管理学科。”这个定义明确指出了软件工程的目标是在成本限额内按时完成开发和修改软件的工作,同时也指出了软件工程包含技术和管理两方面的内容。

Fritz Bauer给出了下述定义:“软件工程是为了经济地获得可靠的且能在实际机器上有效地运行的软件,而建立和使用的完善的工程化原则。”这个定义不仅指出软件工程的目标是经济地开发出高质量的软件,而且强调了软件工程是一门工程学科,它应该建立并使用完善的工程化原则。

1993年IEEE进一步给出了一个更全面的定义。

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

认真研究上述这些关于软件工程的定义,有助于我们建立起对软件工程这门工程学科的全面的整体性认识。

1.2.2 软件工程的基本原理

自从1968年在联邦德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来,研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或“信条”。著名的软件工程专家Barry W. Boehm综合这些学者们的意见并总结了TRW公司多年开发软件的经验,于1983年在一篇论文中提出了软件工程的7条基本原理。他认为这7条原理是确保软件产品质量和开发效率原理的最小集合。这7条原理是互相独立的,其中任意6条原理的组合都不能代替另一条原理,因此,它们是缺一不可的最小集合。然而这7条原理又是相当完备的,人们虽然不能用数学方法严格证明它们是一个完备的集合,但是可以证明在此之前已经提出的100多条软件工程原理都可以由这7条原理的任意组合蕴含或派生。

下面简要介绍软件工程的7条基本原理。

1.用分阶段的生命周期计划严格管理

有人经统计发现,在不成功的软件项目中有一半左右是由于计划不周造成的,可见把建立完善的计划作为第1条基本原理是吸取了前人的教训而提出来的。

在软件开发与维护的漫长生命周期中,需要完成许多性质各异的工作。这条基本原理意味着,应该把软件生命周期划分成若干个阶段,并相应地制定出切实可行的计划,然后严格按照计划对软件的开发与维护工作进行管理。Boehm认为,在软件的整个生命周期中应该制定并严格执行6类计划,它们是项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划。

不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作,绝不能受客户或上级人员的影响而擅自背离预定计划。

2.坚持进行阶段评审

当时已经认识到,软件的质量保证工作不能等到编码阶段结束之后再进行。这样说至少有两个理由:第一,大部分错误是在编码之前造成的,如根据Boehm等人的统计,设计错误占软件错误的63%,编码错误仅占37%;第二,错误发现与改正得越晚,所需付出的代价也越高(参见图1.1)。因此,在每个阶段都进行严格的评审,以便尽早发现在软件开发过程中所犯的错误,是一条必须遵循的重要原则。

3.实行严格的产品控制

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

4.采用现代程序设计技术

从提出软件工程的概念开始,人们一直把主要精力用于研究各种新的程序设计技术。20世纪60年代末提出的结构程序设计技术,已经成为绝大多数人公认的先进的程序设计技术。以后又进一步发展出各种结构分析(structured analysis,SA)与结构设计(structured design,SD)技术。近年来,面向对象技术已经在许多领域中迅速地取代了传统的结构化开发方法。实践表明,采用先进的技术不仅可以提高软件开发和维护的效率,而且可以提高软件产品的质量。

5.结果应能清楚地审查

软件产品不同于一般的物理产品,它是看不见摸不着的逻辑产品。软件开发人员(或开发小组)的工作进展情况可见性差,难以准确度量,从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性,更好地进行管理,应该根据软件开发项目的总目标及完成期限,规定开发组织的责任和产品标准,从而使得所得到的结果能够清楚地审查。

6.开发小组的人员应该少而精

这条基本原理的含义是,软件开发小组的组成人员的素质应该好,而人数则不宜过多。开发小组人员的素质和数量,是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍,而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。此外,随着开发小组人员数目的增加,因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时,可能的通信路径有N(N−1)/2条,可见随着人数N的增大,通信开销将急剧增加。因此,组成少而精的开发小组是软件工程的一条基本原理。

7.承认不断改进软件工程实践的必要性

遵循上述6条基本原理,就能够按照当代软件工程基本原理实现软件的工程化生产。但是,仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐,不能跟上技术的不断进步,因此,Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理,不仅要积极主动地采纳新的软件技术,而且要注意不断总结经验,如收集进度和资源耗费数据,收集出错类型和问题报告数据等。这些数据不仅可以用来评价新的软件技术的效果,而且可以用来指明必须着重开发的软件工具和应该优先研究的技术。

1.3 软件工程包含的领域

IEEE(Institute of Electrical and Electronics Engineers,电气电子工程师学会)在2014年发布的《软件工程知识体系指南》中将软件工程知识体系划分为以下15个知识领域。

(1)软件需求(software requirements)。软件需求涉及软件需求的获取、分析、规格说明和确认。

(2)软件设计(software design)。软件设计定义了一个系统或组件的体系结构、组件、接口和其他特征的过程以及这个过程的结果。

(3)软件构建(software construction)。软件构建是指通过编码、验证、单元测试、集成测试和调试的组合,详细地创建可工作的和有意义的软件。

(4)软件测试(software testing)。软件测试是为评价、改进产品的质量、标识产品的缺陷和问题而进行的活动。

(5)软件维护(software maintenance)。软件维护是指由于一个问题或改进的需要而修改代码和相关文档,进而修正现有的软件产品并保留其完整性的过程。

(6)软件配置管理(software configuration management)。软件配置管理是一个支持性的软件生命周期过程,它是为了系统地控制配置变更,在软件系统的整个生命周期中维持配置的完整性和可追踪性,而标识系统在不同时间点上的配置的学科。

(7)软件工程管理(software engineering management)。软件工程的管理活动建立在组织和内部基础结构管理、项目管理、度量程序的计划制定和控制三个层次上。

(8)软件工程过程(software engineering process)。软件工程过程涉及软件生命周期过程本身的定义、实现、评估、管理、变更和改进。

(9)软件工程模型和方法(software engineering models and methods)。软件工程模型特指在软件的生产与使用、退役等各个过程中的参考模型的总称,诸如需求开发模型、架构设计模型等都属于软件工程模型的范畴;软件开发方法,主要讨论软件开发各种方法及其工作模型。

(10)软件质量(software quality)。软件质量特征涉及多个方面,保证软件产品的质量是软件工程的重要目标。

(11)软件工程职业实践(software engineering professional practice)。软件工程职业实践涉及软件工程师应履行其实践承诺,使软件的需求分析、规格说明、设计、开发、测试和维护成为一项有益和受人尊敬的职业;还包括团队精神和沟通技巧等内容。

(12)软件工程经济学(software engineering economics)。软件工程经济学是研究为实现特定功能需求的软件工程项目而提出的在技术方案、生产(开发)过程、产品或服务等方面所做的经济服务与论证,计算与比较的一门系统方法论学科。

(13)计算基础(computing foundations)。计算基础涉及解决问题的技巧、抽象、编程基础、编程语言的基础知识、调试工具和技术、数据结构和表示、算法和复杂度、系统的基本概念、计算机的组织结构、编译基础知识、操作系统基础知识、数据库基础知识和数据管理、网络通信基础知识、并行和分布式计算、基本的用户人为因素、基本的开发人员人为因素和安全的软件开发和维护等方面的内容。

(14)数学基础(mathematical foundations)。数学基础涉及集合、关系和函数,基本的逻辑、证明技巧、计算的基础知识、图和树、离散概率、有限状态机、语法,数值精度、准确性和错误,数论和代数结构等方面的内容。

(15)工程基础(engineering foundations)。工程基础涉及实验方法和实验技术、统计分析、度量、工程设计,建模、模拟和建立原型,标准和影响因素分析等方面的内容。

软件工程知识体系的提出,让软件工程的内容更加清晰,也使得其作为一个学科的定义和界限更加分明。

小结

本章对计算机软件工程学作了一个简短的概述。首先通过回顾计算机系统发展简史,说明开发软件的一些错误方法和观念是怎样形成的;然后列举了这些错误方法带来的严重弊病(软件危机),澄清了一些糊涂观念。为了计算机系统的进一步发展,需要认真研究开发和维护软件的科学技术。应总结开发计算机软件的历史经验教训,借鉴其他工程领域的管理技术,逐步使软件工程这门新学科发展和完善起来。

习题

一、判断题

1.软件就是程序,编写软件就是编写程序。

(  )

2.软件危机的主要表现是软件需求增加,软件价格上升。

(  )

3.软件工程学科出现的主要原因是软件危机的出现。  

(  )

4.与计算机科学的理论研究不同,软件工程是一门原理性学科。  

(  )

二、选择题

1.在下列选项中,(  )不是软件的特征。

  A.系统性与复制性  

  B.可靠性与一致性

  C.抽象性与智能性  

  D.有形性与可控性

2.软件危机的主要原因是(  )。

  A.软件工具落后  

  B.软件生产能力不足

  C.对软件的认识不够 

  D.软件本身的特点及开发方法

3.下列说法中正确的是(  )。

  A.20世纪50年代提出了软件工程的概念

  B.20世纪60年代提出了软件工程的概念

  C.20世纪70年代出现了客户机/服务器技术

  D.20世纪80年代软件工程学科达到成熟

4.(  )是将系统化的、规范的、可定量的方法应用于软件的开发、运行和维护的过程,它包括方法、工具和过程三个要素。

  A.软件生命周期

  B.软件测试 

  C.软件工程

  D.软件过程

5.在下列选项中,(  )不属于软件工程学科所要研究的基本内容。

  A.软件工程材料  

  B.软件工程目标 

  C.软件工程原理  

  D.软件工程过程

6.软件工程的三要素是(  )。

  A.技术、方法和工具 

  B.方法、对象和类

  C.方法、工具和过程 

  D.过程、模型和方法

7.用来辅助软件开发、运行、维护、管理、支持等过程中的活动的软件称为软件开发工具,通常也称为(  )工具。

  A.CAD B.CAI C.CAM D.CASE

三、简答题

1.与计算机硬件相比,计算机软件有哪些特点?

2.软件就是程序吗?如何定义软件?

3.什么是软件危机?什么原因导致了软件危机?

4.为什么说软件工程的发展可以在一定程度上解决软件危机的各种弊端?

5.请简述软件工程研究的内容。

6.请简述软件工程的三要素。

7.请简述软件工程的目标、过程和原则。

8.请简述软件工程的基本原则。

9.请简述现代软件工程与传统软件工程显著的区别和改进。

目录

  • 版权
  • 内容提要
  • 出版者的话
  • 第4版前言
  • 第1篇 软件工程与软件过程
  • 第1章 软件工程概述
  • 第2章 软件过程
  • 第2篇 传统方法学
  • 第3章 结构化分析
  • 第4章 结构化设计
  • 第5章 结构化实现
  • 第3篇 面向对象方法学
  • 第6章 面向对象方法学导论
  • 第7章 面向对象分析
  • 第8章 面向对象设计
  • 第9章 面向对象实现
  • 第10章 统一建模语言
  • 第4篇 软件项目管理
  • 第11章 计划
  • 第12章 组织
  • 第13章 控制
  • 第14章 软件维护与软件文档
  • 第5篇 高级课题
  • 第15章 形式化方法
  • 第16章 软件重用
  • 参考文献

推荐用户

同系列书

人邮微信
本地服务
教师服务
教师服务
读者服务
读者服务
返回顶部
返回顶部