第01章软件工程概述.docx
《第01章软件工程概述.docx》由会员分享，可在线阅读，更多相关《第01章软件工程概述.docx（18页珍藏版）》请在冰豆网上搜索。
第01章软件工程概述
第一章软件工程概述
我们知道，计算机软件是整个计算机系统中具体实现各种功能和操作的核心部分。
软件工程即采用工程的概念、原理、技术和方法来开发和维护软件，将工程管理技术成功的经验和思想与具体软件的开发过程、研究技术相结合，形成一整套适合于计算机软件开发的方法、规范和技术。
因此，软件工程这门课程，对于从事软件开发研究的专业人员，特别是高层次的管理、分析、开发人员，显得比以往更加重要。
1.1软件工程的基本概念、特点、分类
1.1.1软件的概念、特点
计算机软件是程序、数据及相关文档的完整集合。
其中，程序是按事先设计的功能和性能要求执行的指令序列，数据是使程序能正常操纵信息的数据结构，文档是与程序开发、维护和使用有关的图文材料。
要深入进行计算机软件的开发和研究，首先要了解计算机软件的特点和计算机软件开发的规律。
计算机软件可归结具有如下几个共同特点：
1、软件是一种逻辑实体，而不是具体的物理实体。
因此，它具有抽象性。
2、软件的生产与硬件不同，软件是由开发或工程化而形成的，它没有明显的制造过程。
对软件的质量控制，必须立足于软件开发方面。
软件成为产品之后，其制造只是简单的拷贝而已。
3、任何机械、电子设备在运行和使用过程中，其失效率大致遵循如图1-1所示的U型曲线（即浴盆曲线）。
软件的情况与此不同，它不存在磨损和老化问题。
然而，它存在退化问题，设计人员必须多次修改（维护）软件，图1-2（a）给出了软件故障率的理想曲线，图1-2（b）给出了实际的软件故障率曲线。
4、软件的开发和运行往往受到计算机系统的限制，对计算机系统有着不同程度的依赖性。
为了解除这种依赖性，在软件开发中提出了软件移植的问题。
图1-2（b）软件的故障率曲线（实际情况）
5、迄今为止，软件的开发尚未完全摆脱手工艺的方式。
6、软件本身是复杂的。
软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。
7、软件的成本相当昂贵。
软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，它投入的成本是比较高的。
8、相当多的软件工作涉及到社会因素。
许多软件的开发和运行涉及机构设置、体制运作及管理方式等问题，甚至涉及到人们的观念和心理，这些因素直接影响到项目的成败。
9、从市场上买到的软件，它本身就是一个完整的软件，而不能作为构件再组装成新的程序。
但目前已有大量的支持“软件复用”的软件和中间件作为相对独立的构件。
1.1.2软件的分类
软件按其功能进行划分，可分为如下几大类：
1、系统软件能与计算机硬件紧密配合，使计算机系统的各个部件、相关的软件和数据协调、高效地工作的软件。
例如，操作系统、数据库管理系统、设备驱动程序以及通信处理程序等。
2、支撑软件协助用户开发软件的工具性软件，包括帮助程序人员开发软件产品的工具，也包括帮助管理人员控制开发进程的工具。
3、应用软件在特定领域内开发，为特定目的服务的软件。
按软件的规模进行划分
按开发软件所需的人力、时间以及完成的源程序行数，可确定6种不同规模的软件，如表1-1所示。
表1-1软件规模分类参考表
分类
子程序数量
参加人员
开发期限
程序规模（行）
微型
小型
中型
大型
甚大型
极大型
10-20
25-50
250-1000
1人
1人
2-5人
5-20人
100-1000人
2000-5000人
1-4周
1-6月
1-2年
2-3年
4-5年
5-10年
500以下
1K-2K
5K-50K
50K-100K
1M
1M-10M
规模大、开发时间长、参加人数多的软件项目，其开发工作必须有软件工程的知识做指导。
而规模小、开发时间短、参加人员少的软件项目也要有软件工程的概念，遵循一定的开发规范。
其基本原则是一样的，只是对软件工程技术依赖的程度不同而已。
从表中还可看出,随着项目规模的不断增大，平均开发效率将不断降低，
按软件的工作方式进行划分
1、实时处理软件指在事件或数据产生时对其立即处理，并及时反馈信号以控制需要监测的过程的软件。
实时处理软件主要包括数据采集、分析、输出3个部分。
2、分时软件允许多个联机用户同时使用计算机的软件。
3、交互式软件能实现人机通信的软件。
4、批处理软件把一组输入作业或一批数据以成批处理的方式一次运行，按顺序逐个处理的软件。
按软件服务对象的范围进行划分
1、项目软件也称定制软件，是受某个特定客户（或少数客户）的委托，由一个或多个软件开发机构在合同的约束下开发的软件，如军用防空指挥系统、卫星控制系统等。
2、产品软件由软件开发机构开发并直接提供给市场，或是为众多用户服务的软件，如文字处理软件、文本处理软件、财务处理软件、人事管理软件等。
按软件失效的影响进行划分
有的软件在工作中因出现故障而失效，可能对整个软件系统的影响不大。
有的软件一旦失效，可能带来灾难性后果，如财务金融软件、交通通信软件、航空航天软件等，称这类软件为关键软件。
1.1.3软件工程概述
许多计算机软件专家尝试，把其它工程领域中行之有效的工程学知识运用到软件开发工作中来。
经过不断的实践和总结，最后得出结论：
按工程化的原则和方法组织软件开发工作是有效的，是缓解软件危机的一个有效办法。
（1）软件工程过程（SoftwareEngineeringProcess）
软件工程过程是指为了获得软件产品，在软件工具的支持下由软件开发人员完成的一系列软件工程活动。
软件工程过程通常包含以下4种基本活动：
①P（Plan）软件计划及规格说明过程。
规定软件的功能及其运行时的限制。
②D（Do）软件开发过程。
产生满足规格说明的软件。
③C（Check）软件确认过程。
确认软件能够满足客户提出的要求。
④A（Action）软件演进过程。
为满足客户的变更要求，软件必须在使用的过程中演进。
事实上，软件工程过程是一个软件开发机构针对某类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响软件产品的质量。
（2）软件生存周期（LifeCycle）
同其他任何事物一样，软件也存在从开始到衰亡的生存过程，通常称其为计算机软件的生存周期。
针对不同的模型、不同的开发对象、不同的开发方法，对于软件的生存周期可以有不同的划分，如果不考虑上述因数及应用领域、项目规模和复杂性，与软件工程相关的工作可分为以下三个阶段。
定义阶段：
集中于“做什么”。
即在定义过程中，软件开发人员试图弄清楚要处理什么信息，预期完成什么样的功能和性能，希望有什么样的系统行为，建立什么样的界面，有什么设计约束，以及定义一个成功系统的确认标准是什么。
即定义系统和软件的关键需求。
虽然在定义阶段采用的方法取决于使用的软件工程范型（或范型的组合），但在某种程度上均有三个主要任务：
系统或信息工程，软件项目计划，和需求分析。
开发阶段：
集中于“如何做”。
即在开发过程中，软件工程师试图定义数据如何结构化，功能如何转换为软件体系结构，过程细节如何实现，界面如何表示，设计如何转换成程序设计语言（或非过程语言），测试如何执行。
在开发阶段采用的方法可以不同，但都有三个特定的任务：
软件设计，代码生成，和软件测试。
维护阶段：
集中于“改变”，与以下几种情况相关：
纠正错误；随着软件环境的演化，而要求的适应性修改；及由于用户需求的变化而带来的增强性修改。
维护阶段重复定义和开发阶段的步骤，但却是在已有软件的基础上发生的。
在维护阶段可能遇到四类修改要完成：
纠错：
即使有最好的质量保证机制，用户还是有可能发现软件中的错误。
纠错性维护是为了改正错误而使软件发生变化。
适应：
随着时间的推移，原来的软件被开发的环境（如CPU、操作系统、商业规则、外部产品特征）可能发生了变化。
适应性维护是为了适应这些外部环境的变化而修改软件。
增强：
随着软件的使用，用户可能认识到某些新功能会产生更好的效益。
完善性维护是由于扩展了原来的功能需求而修改软件。
预防：
计算机软件由于修改而逐渐退化，因此，预防性维护，常常称为软件再工程，就必须实行，以使软件能够满足其最终用户的要求。
本质上讲，预防性维护对计算机程序的修改，可使得能够更好地纠错软件的错误，提高软件的适应性和增强软件的需求。
（3）软件开发中对问题的分析方法
软件开发人员通常要处理的问题与计算机系统有关，但在进行软件开发的初期，问题本身往往与计算机没有直接的关系。
因此，首先理解问题的本质是很重要的。
特别地，我们必须要小心，不要把计算机技术强加于我们遇到的每个问题上。
首先必须解决这个问题。
然后，如果需要，使用技术作为工具来实现我们的解决方案。
大多数问题是庞大而复杂的，有时处理起来棘手。
因此人们一般是从对问题的分析入手，进行调查，将一个复杂的问题分解为若干个相对比较简单的子问题，如果处理起来还有困难，则可将子问题继续进行二次划分，直到分解成为我们能理解并尽量能处理的问题片。
因而我们能够把这个大问题用小问题集和它们间的相互关系来描述。
图1-3解释了如何分析。
重要的是要记住关系（图中的箭头，及子问题的相对位置）跟子问题本身一样重要。
有时，正是关系保持着怎样解决大问题的线索，而不简单是子问题的本身特性。
一旦分析了问题，我们必须从表述问题各方面的部件来构建解决方案。
图1-4解释了这个相反的过程：
综合（Synthesis），就是把从小建筑块装配成一个大建筑。
随着分析，单个解决方案的合成可能跟寻找这些方案本身一样富有挑战性。
为了弄清为什么，考虑写一本小说的过程。
字典包含了所有你可能想在作品里使用的词。
但是，写作最困难的部分就是决定怎样组字成句，同样的，组句成段、章以形成这部完整的书。
因此，任何解决问题的技巧必须有两部分：
分析问题以弄清它的本质，然后基于分析综合/合成出一个解决方案。
为了有助于解决问题，我们使用各种方法（method）、工具（tool）、程序（procedure）及范例（paradigm）。
一种方法（method/technique）就是一种用于产生某种结果的正式的程序（procedure）。
例如，一个厨师准备调料时，他使用一系列成分并结合一套仔细排好的时、序步骤以便调料变浓但又不凝固或分散。
准备调料的程序与时间选择和成分有关但可能并不依赖于使用何种类型的烹饪设备。
图1-4综合过程
子问题2
2
问题
子问题1
子问题4
子问题3
一件工具（tool）是一件能以更好的方式完成某件事情的设备或自动化系统。
在这里“更好方式”可能意味着这件工具使用我们更准确、更有效率、或更多产、或增强了所得产品的质量。
例如，我们使用打字机或键盘和打印机来写信是因为所得文档比手写更易于阅读。
或者我们用一把剪刀作为一种工具是因为比起撕一张纸使用剪刀会剪得更快更直。
然而，工具并不总是更好地做某件事所必须的。
例如，一个烹饪方法能做出更好的调料而不是厨师所使用的罐也非勺。
一个程序（procedure）就象一个秘诀：
是一致地产生特别产品的工具和方法的组合。
打个比方，就象将在后面章节看到的，我们的测试计划描述了我们的测试程序；它们告诉我们在何种情形下用何种工具作用在何种数据集上以便让我们检查出软件是否满足要求。
最后，范例就象一种烹饪风格；它提供了一个特别的构建软件的方案或哲学。
恰就象我们能区别出法国烹饪和中国烹饪一样，我们也能区别出象面向对象开发和过程化开发这样的范例。
一种范例比不比另一个好；每一种都有它自己的优势和劣势，一个比另一个更恰当是有条件的。
软件工程师使用工具、方法、程序和范例来增强他们软件产品的质量。
他们的目标就是使用有效的富有成果的途径来产生有效的问题解决方案。
在后续几章中，我们将突出一些支持我们所述的开发维护活动的特别途径。
1.2软件发展和软件危机
1.2.1软件的发展
自从20世纪40年代中期出现了世界上第一台计算机，就产生了程序的概念。
当时，大多数人把软件看成是不需预先计划的事情。
计算机编程很简单，没有什么系统化的方法。
软件的开发没有任何管理，一旦计划延迟了或成本提高了，程序员才开始手忙脚乱地弥补，而他们的努力一般情况下也会取得成功。
在通用的硬件已经非常普遍的时候，软件却相反，对每一类应用均需自行再设计，应用范围很有限。
软件产品还在婴儿阶段，大多数软件均是由使用它们的人员或组织自己开发的，如你写软件，使其运行，如果它有问题，你负责改好。
工作的可变性很低，管理者必须得到保证：
一旦发生了错误你必须在那里。
因为这种个人化的软件环境，设计往往仅是人们头脑中的一种模糊想法，而文档就根本不存在。
其后经过几十年的发展，计算机软件经历了4个发展阶段：
（1）程序设计阶段，约为20世纪五六十年代。
（2）程序系统阶段，约为20世纪六七十年代。
（3）软件工程阶段，约为20世纪七十年代以后。
（4）面向对象软件工程阶段，约为20世纪八十年代以后。
图1-5软件的发展
软件发展最根本的变化体现在以下几个方面：
（1）人们改变了对软件的看法。
在20世纪五六十年代时，程序设计曾经被看做一种任人发挥创造才能的技术领域。
当时人们认为，程序运行后只要能在计算机上得出正确的结果，程序的写法可以不受任何约束。
随着计算机的使用范围日趋广泛，人们要求这些程序易懂、易使用，并且容易修改和扩充。
于是，程序便从按个人意图创造的“艺术品”转变为能被广大用户接受的工程化产品。
（2）软件的需求是软件发展的动力。
早期的程序开发只是为了满足开发者自己的需要，这种自给自足的生产方式是其低级阶段的表现。
进入软件工程阶段后，软件开发的成果具有社会属性，它要在市场中流通以满足广大用户的需要。
（3）软件工作的考虑范围从只顾及程序的编写扩展到涉及整个软件生存周期。
1.2.2软件危机过程
从60年代中期到70年代中期是计算机系统发展的第二代时期，随着计算机硬件技术的进步，要求软件能与之相适应，这个时期的一个重要特征是出现了“软件作坊”，广泛使用产品软件。
但是，“软件作坊”基本上仍然沿用早期形成的个体化软件开发方法。
随着计算机应用的日益普及，软件数量急剧膨胀，软件技术的进步一直未能满足形势发展提出的要求，致使问题堆积起来，形成日益尖锐的矛盾，在程序运行时发现的错误必须设法改正；用户有了新的需求时必须相应地修改程序；硬件或操作系统更新时，通常需要修改程序以适应新的环境。
上述种种软件维护工作，以令人吃惊的比例耗费资源。
更严重的是，许多程序的个体化特性使得它们最终成为不可维护的。
“软件危机”就这样开始出现了。
1968年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，讨论软件危机问题，在这次会议上正式提出并使用了“软件工程”这个名词，软件工程学由此产生。
软件危机的主要表现
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
这些问题绝不仅仅是“不能正常运行的”软件才具有的，实际上几乎所有软件都不同程度地存在这些问题。
概括地说，软件危机包含下述两方面的问题：
如何开发软件，怎样满足对软件的日益增长的需求；如何维护数量不断膨胀的已有软件。
具体地说，软件危机主要有下述一些表现形式：
（1）对软件开发成本和进度的估计常常很不准确。
实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。
这种现象降低了软件开发组织的信誉。
而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。
（2）用户对“已完成的”软件系统不满意的现象经常发生。
软件开发人员常常在对用户要求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就仓促上阵匆忙着手编写程序。
软件开发人员和用户之间的信息交流往往很不充分，“闭门造车”必然导致最终的产品不符合用户的实际需要。
（3）软件产品的质量往往靠不住。
软件可靠性和质量保证的确切的定量概念刚刚出现不久，软件质量保证技术（审查、复审和测试）还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题。
（4）软件常常是不可维护的。
很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需要在原有程序中增加一些新的功能。
“可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件。
（5）软件通常没有适当的文档资料。
计算机软件不仅仅是程序，还应该有一整套文档资料。
这些文档资料应该是在软件开发过程中产生出来的，而且应该是“最新式的”（即和程序代码完全一致的）。
软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况；软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息；对于软件维护人员而言，这些文档资料更是至关重要必不可少的。
缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的困难和问题。
（6）软件成本在计算机系统总成本中所占的比例逐年上升。
由于微电子学技术的进步和生产自动化程度不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件规模和数量的不断扩大而持续上升。
美国在1985年软件成本大约已占计算机系统总成本的90％。
（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。
以上列举的仅仅是软件危机的一些明显的表现，与软件开发和维护有关的问题远远不止这些。
产生软件危机的原因
在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。
在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价，因此，管理和控制软件开发过程相当困难。
此外，软件在运行过程中不会因为使用时间过长而被“用坏”，如果运行中发现错误，很可能是遇到了一个在开发时期引入的在测试阶段没能检测出来的故障。
因此，软件维护通常意味着改正或修改原来的设计，这就在客观上使得软件较难维护。
软件不同于一般程序，它的一个显著特点是规模庞大。
例如，美国四代宇宙飞船的软件规模呈指数增长，70年代末穿梭号宇宙飞船的软件包含4000万行目标代码。
假设一个人一年可以开发出一个一万行的程序，为了开发一个4000万行的软件，是否集中4000人的力量一年就可以完成呢?
绝对做不到!
因为代码长度增加了4000倍，程序复杂程度的增加远远超过4000倍。
而且如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统，更是一个极端复杂困难的问题，不仅涉及许多技术问题，诸如分析方法、设计方法、形式说明方法、版本控制等，更重要的是必须有严格而科学的管理。
软件本身独有的特点确实给开发和维护带来一些客观困难，但是人们在开发和使用计算机系统的长期实践中，也确实积累和总结出了许多成功的经验。
如果坚持不懈地使用经过实践考验证明是正确的方法，许多困难是完全可以克服的，过去也确实有一些成功的范例。
但是，目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
与软件开发和维护有关的许多错误认识和作法的形成，可以归因于在计算机系统发展的早期软件开发的个体化特点。
错误认识和作法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。
事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。
只有用户才真正了解他们自己的需要，但是许多用户在开始时并不能准确具体地叙述他们的需要，软件开发人员需要做大量深入细致的调查研究工作，反复多次地和用户交流信息，才能真正全面、准确、具体地了解用户的要求。
对问题和目标的正确认识是解决任何问题的前提和出发点，软件开发同样也不例外。
急于求成，仓促上阵，对用户要求没有正确认识就匆忙着手编写程序，这就如同不打好地基就盖高楼一样，最终必然垮台。
作好软件定义时期的工作，是降低软件成本提高软件质量的关键。
如果软件开发人员在定义时期没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完全符合用户的需要，这时再修改就为时已晚了。
严重的问题是，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；而在开发的中期软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时再引入变动，当然需要付出更高得多的代价。
根据美国一些软件公司的统计资料，在后期引入一个变动比在早期引入相同变动所需付出的代价高2～3个数量级。
通过上面的论述不难认识到，轻视维护是一个最大的错误。
许多软件产品的使用寿命长达10年甚至20年，在这样漫长的时期中不仅必须改正使用过程中发现的每一个潜伏的错误，而且当环境变化时（例如硬件或系统软件更新换代）还必须相应地修改软件以适应新的环境，特别是必须经常改进或扩充原来的软件以满足用户不断变化的需要。
所有这些改动都属于维护工作，而且是在软件已经完成之后进行的，因此维护是极端艰巨复杂的工作，需要花费很大代价。
统计数据表明，实际上用于软件维护的费用占软件总费用的55％～70％。
软件工程学的一个重要目标就是提高软件的可维护性，减少软件维护的代价。
了解产生软件危机的原因，澄清错误认识，建立起关于软件开发和维护的正确概念，还仅仅是解决软件危机的开始，全面解决软件危机需要一系列综合措施。
缓解软件危机的途径
软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。
应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。
应该开发和使用更好的软件工具。
正如机械工具可以“放大”人类的体力一样，软件工具可以“放大”人类的智力。
在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。
如果把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境。
总之，为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。
软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。
1.3软件模型
软件模型是从软件项目需求定义直至软件使用后废弃为止，针对系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。
在此，我们介绍几种常用和具有代表性的模型供大家参考。
1、瀑布模型：
瀑布模型（线性顺序模型）规定了各项软件工程活动，包括制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及运行维护，如图1-6所示。
并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型包含以下活动：
系统／信息工程和建模：
因为软件总是一个大系统的组成部分，所以一开始应该建立所有系统成分的需求，然后再将其中某个子集分配给软件。
整个系统基础是，以软件作为其他成分如硬件、人及数据库的接口。
系统工程和分析包括了系统级收集的需求，以及一小部分顶层分析和设计。
信息工程包括了在战略商业级和商业领域级收集的需求。
升级会员 