第一章软件工程的回顾.docx
《第一章软件工程的回顾.docx》由会员分享，可在线阅读，更多相关《第一章软件工程的回顾.docx（28页珍藏版）》请在冰点文库上搜索。
第一章软件工程的回顾
第一章软件工程的回顾
§1分析法的演变与软件工程
软件工程是伴随计算机软件系统开发而形成并逐步完善的一个独立的工程学科。
自1968年北大西洋公约组织（NATO）的计算机科学家正式提出了“软件工程”（SoftwareEngineering）的术语，并为之制定了一个设计软件程序的标准化的步骤框架以来，围绕软件工程内部的各种具体技术手段和方法的研究工作一直就没有停止过。
所有这一切研究都是为了寻找出能够开发适应不同的应用环境的高质量、高可靠、高安全、高效率、长寿命、高可维护、低成本的软件系统的技术和实施方法。
这当中具有系统分析和设计套路的知名方法就有数十种。
但在面向对象的分析与设计方法问世之前，几乎所有的系统分析和设计方法都有一个相同的特点：
以软件系统所处理的数据为核心，归纳、分析处理的每个步骤，最终建立系统的分析和设计模型。
因而被统称为面向过程的分析方法。
本书主要是以二十世纪八十年代中期以后逐渐流行起来的面向对象的分析和设计方法为重点，论述其主要的思维方法，并将之与传统的面向过程的分析方法进行适当的比较。
由于面向对象的分析和设计方法并非独立于传统的面向过程的分析方法而发展起来的，而是在总结面向过程的分析方法在工程实践中的成功和失败的经验、教训的基础上继承、提炼其可用成份后逐步形成的。
所以，对于根本没有系统学习过软件工程的读者，有必要对软件工程的概要内容进行补充性的学习，以利于读者能够迅速接受面向对象的分析和设计方法的思维模式。
但由于软件工程的学科内容十分庞大，不可能全面展开，只能兼顾面向对象分析与设计方法对其继承的程度有所侧重。
本章内容正是基于这样的思考而专门安排的。
§1.1软件工程的形成
最初的计算机程序设计完全是专业人员的个人行为，根本没有什么设计规范和设计方法的约束。
由各种分散的、无规则的分析与设计方法最终形成有规范的软件工程则经历了计算机诞生的最初二十多年连续的演变历程。
一．六十年代中期以前的发展
这个时期由于计算机的CPU运算速度低、存储容量小，程序从分析、设计、使用到维护大都由一个人完成（研发的软件系统的部门既是开发方也是受益方）。
此时，设计者只是注意在编程时要如何节省存储单元，提高运算速度，并没有十分详尽的系统分析、设计文档。
因此，这一阶段的程序设计又被称为代码设计阶段。
二．六十年代中期至七十年代中期
由于集成电路的出现，计算机CPU的运算速度和存储容量都成倍提高，从而使计算机可以受理的计算或信息处理的能力都大为提高。
这时的程序设计量已不是一个人可以承受的，从而出现了多个人分工合作开发软件的局面。
甚至也已出现了由“软件作坊”设计出来的可以作为商品出售的小型、专用的软件程序。
商业化的介入必然导致软件开发成本核算的经济管理的出现。
这时人们发现一个花费巨额人力、物力和财力开发出来的软件，可能由于存在一些不适应用户要求的小问题而导致滞销乃至失败。
而当开发人员打算修改这些小问题时，却又发现这个修改工作量与问题不成比例，可能需要再花费巨大的人财物的投入才能将问题解决。
最典型的例子要算IBM公司的OS/360系统了。
这就是被人们称之为的“软件危机”现象。
此时，人们开始期望能有一种标准化的软件设计规范来实现软件程序设计上“多、快、好、省”的目标。
三．七十年代中期到八十年代中期
随着这一时期大规模集成电路的发展，计算机中软件设计的投资所占的比例越来越高。
到1985年，美国公布的统计资料显示，当时的软件投资已占到计算机系统总投资的90%。
这时的软件用户需求不断提高，开发周期日益缩短，软件的生存周期也随之缩短。
因此一旦出现决策失误，软件开发商的损失将是非常巨大的。
因而这段时期的软件工程出现了许多配套的、有详细设计规范、设计步骤文档和描述标准。
在这些标准中便具体地定义了多种软件开发的方法。
§1.2软件危机的出现
软件危机较为准确的定义是计算机软件在开发和维护时所遇到的所有问题的总和。
因而解决软件危机就要解决如何在最小的成本投入的前提下使所开发的软件可以不断地满足人们日益增长的各种需求和如何能够尽可能降低维护工作量这两个主要问题。
一．软件危机的主要表现形式
⒈不可预计的开发成本和开发进度
随着软件的应用领域的不断扩大，做为软件的开发、设计人员大多并不熟悉和了解该软件的应用领域。
如果开发人员与用户之间的信息交流不够或理解偏差，都会导致所开发出来的软件产品存在大量问题，以至于进度不能如期完成。
⒉软件产品的质量差
由于对于软件质量没有一套明确的评估标准，尤其是没有一套诸如工程监理制那样的质量评估体系对软件的每个开发步骤实施质量监督，因而对软件产品的质量好、坏评价常常是随意的。
⒊可维护性差
一个软件在应用一段时间后发现问题而需要修改时，开发方由于没有开发时的任何文档说明而陷入困境。
这种开发不健全是导致这一问题的要害。
⒋软件开发速度低于硬件的发展和用户需求的改变
硬件可利用原有的体系结构或局部模板转型成为新一代体系。
其生产工艺可以只对原有生产线稍加修改即转入生产。
与之相配套的软件却由于硬件的改变而不得不重新开发，很难能够利用原有系统。
这是令软件开发商十分痛苦的事情。
例如PC的CPU中32位的Pentium芯片早在1993年就已出现，但到1996年时在其上执行的32位的应用软件系统的数目远少于相应的16位应用软件系统。
二．产生软件危机的原因
产生软件危机的原因不仅与软件本身的特点有关，也与软件人员开发时存在的问题有关。
软件是计算机系统中的逻辑部件。
由于这类产品往往规模庞大，给软件的开发和维护带来了客观上的困难。
一个软件产品一般要使用3~10年，在这样漫长的时间内，很可能出现在开发时没有考虑周全的问题，从而导致运行一端时间后出现问题（如计算机2000年问题）。
另外开发人员忽视软件需求分析的重要性，轻视软件维护，也是造成软件危机的重要原因之一。
三．解决软件危机的途径
在现有的计算机模式下，可以解决软件危机的手段主要是：
·使用好的软件开发技术和方法；
·形成良好的组织、严密的管理和能使各类人员协同工作的环境机制以利于开发工作的顺利完成；
·选择并使用好的软件开发工具以提高软件的生产率。
上述原则实际上体现了技术保障和组织保障两大综合体系的作用。
§1.3软件工程概述
鉴于上述的问题，人们便开始理智地、系统地对计算机软件及其开发过程开始进行研究并总结出了一系列带有规律性的结论。
在软件的软件的发展历程分段上，研究的共识基本上分为程序、软件、软件产品等三个阶段。
当软件需求量大大增加后，人们把软件视为产品，强调软件的“可维护性”，确定了软件开发的各个阶段必需完成的各种规格书、说明书、用户手册等（称为“文档”）。
B.Boehm指出：
“软件是程序以及开发、使用和维护所需要的所有文档（documents）的总和”。
特别当软件成为商品时，文档是必不可少的。
没有文档，仅有程序是不能称为软件产品的。
既然软件的开发是一个复杂的生产过程，就必须遵循一定的规则或规范来进行组织、调度和管理。
这也是软件工程研究的根本目的。
软件工程是指导计算机软件开发和维护的工程学科。
软件工程采用工程的概念、原理、技术和方法来开发与维护软件。
软件工程的目标是实现软件的优质、高产和低耗。
软件作为可以出售的商品便具有了开发、生产、流通、使用和报废等一系列的商品的属性。
一个软件从定义、开发、使用和维护，直到陈旧退役，要经历一个漫长的时期，称为软件的生存周期。
这如同
一个人从出生开始，经过儿童、青年、中年、老年到死亡。
在人的一生中，国家和社会对人的负担主要在儿童、青少年时期的培养及老年丧失劳能力后的供养。
而人从参加社会生产活动后就应对国家与社会作出贡献。
贡献越大，人的价值也就越大。
同样，在软件生存周期中，软件的开发要进行投资，消耗价值，当软件交付使用后开始产生价值，软件维护又要消耗价值（如图1-1）。
在软件生存周期中，消耗价值越少，即软件开发与维护所花的费用越低，软件的使用寿命越长，产生的价值就越大，这就是软件工程学科进行研究的主要内容。
这些内容又分为软件开发技术和软件工程管理两大部分。
其中，软件开发技术包含了软件开发方法、软件工具和软件工程环境，软件工程管理包含了软件工程经济学和软件管理学。
图1-1软件的生命周期示意
一．软件开发方法（SoftwareDevelopmentMethods）
早期的程序设计属于个人活动性质，程序员无统一的方法可循，到了60年代后期，兴起了结构化程序设计，人们采用结构化的方法来编写程序。
经典的结构化程序设计只允许使用顺序、选择（或条件分支）和循环这三种基本结构。
这样不仅可改善程序的清晰度，而且能提高软件的可靠性和开发效率。
随后，人们认识到编写程序仅是软件开发过程中的一个环节。
典型的软件开发工作中编写程序所需的工程量只占软件开发全部工作量的10-20%。
有效的开发还应包括需求分析、软件设计、编写文档、常规维护等几个阶段。
于是形成了“结构化分析”、“结构化设计”、Jackson方法、Warnier方法等具体体现某种模型套路的软件开发方法。
到80年代后半期又广泛兴起了面向对象的设计方法。
各种软件开发方法的适用范围不尽相同，本章将介绍一些比较成熟的且在目前仍广泛使用的结构化软件开发方法。
二．软件工具（SoftwareTools）
为了提高软件设计的质量和开发效率，已发展了许多“帮助开发和维护软件的软件。
人们称之为软件工具（softwaretools），也称软件自动工具（automatedtools）。
例如，我们要在微机上用某种高级语言开发一个应用软件，往往首先要用编辑程序把源程序输入计算机；然后用编译程序对源程序进行编译；如果发现错误，就要重新用编辑程序对源程序进行修改。
编译通过后，用连接程序把所有的目标程序，同有关的库程序连接起来，构成一个可执行软件。
这里，编辑程序、编译程序、连接程序及支持它们的计算机操作系统都属于软件工具。
另外，有测试阶段的测试数据产生器、排错程序、跟踪程序、静态分析工具和覆盖监视工具等，设计阶段和分析阶段也有一些工具。
众多的软件工具组成了“工具箱（toolbox）”或“集成工具（integratedtool）”，供软件开发人员在软件生存期的各个不同阶段，根据不同的需要选择使用。
目前，软件工具发展迅速，许多用于软件分析和设计的工具正在被大量推出，其目标是为了提高软件生存期各个环节的开发效率。
三．软件工程环境（SoftwareEngineeringEnvironment，简称SEE）
软件开发方法和工具是软件开发的两大支柱，它们之间有着密切的关系。
软件开发方法提出了明确的工作步骤和标准的文档格式，这是设计软件的基础。
而软件工具的实现又将促进软件开发方法的推广和发展。
软件工程环境正是软件开发方法和软件工具的结合。
在1985年第八届国际软件工程会议上，关于“软件开发环境”的定义是：
“软件开发环境是相关的一组软件工具集合，它支持一定的软件开发方法或按照一定的软件开发模型组织而成”。
软件开发环境的设计目标是提高软件开发效率和改善软件质量。
四．软件工程管理学
一个企业如果只有先进的设备和技术，但没有完善的管理，是不可能获得应有的经济效益的。
软件开发也一样,如果管理不善，是不可能高质量、按时完成开发任务的。
软件工程管理就是对软件工程生存期内的各阶段的活动进行管理。
软件工程管理的目的是为了能按预定的时间和费用，成功地完成软件的开发和维护任务。
软件工程管理学的内容包括软件费用管理、人员组织管理、工程计划管理、软件配置管理等各方面内容。
⒈费用管理
一般来讲，开发一个软件是一种投资行为。
人们总是期望以较低的投入来获得较大的经济效益。
要从经济角度上分析开发一个软件系统是否划算，而让使用部门负责人正确地作出是否开发这项系统的决定。
这是费用管理的最终目标。
费用管理从软件开发成本、运行费用、经济效益等方面来估算整个系统的投资和回报的经费数量。
软件开发成本主要表现为人力消耗（即开发人员的工资报酬）、获得所需的最新软件开发信息的花费和新型软件开发工具的投入。
软件运行费用取决于系统的测试费用和维护费用。
其中测试费用包括测试人员的报酬、各类物资消耗等各项开支。
系统的经济效益是指因使用系统而可以节省的费用和增加的收人与原运作模式状况的对比。
由于运行费用和经济效益两者在软件的整个生存周期内都存在，总的效益和软件生存周期的长度有关。
所以，应合理地估算软件的寿命。
一般在进行成本／效益分析时通常设定生存周期为5年。
⒉人员组织
软件开发已非个体劳动，需要各类人员协同配合，共同完成工程任务，因而应该有良好的组织和周密的管理。
⒊工程计划管理
软件计划是在软件生存周期的早期确定的。
在计划实施过程中的必要时段可对工程进度安排作适当的调整。
在软件开发结束后应写出软件开发总结，以便在今后的软件开发工程中能作出更切合实际的计划。
⒋软件配置管理
软件工程各阶段所产生的全部文档和软件程序及相关成份（如加密装置）构成软件配置。
每当完成一个软件工程步骤，就涉及到软件工程配置。
必须使软件配置始终保持其精确性和完整性。
软件配置管理就是要不断检查、控制软件配置的全部变动。
§2软件开发模型
§2.1软件生存周期的阶段划分
软件生存周期是软件工程的一个重要概念。
把整个软件生存周期划分为若干个阶段，是实现软件开发工程化的重要步骤。
赋予每个阶段相对独立的任务分步完成，能够简化每个阶段的工作，容易确立系统开发计划，还可明确系统各类开发人员的分工与职责范围，以便分工协作，保证所开发软件的工期和质量。
每个阶段都要有技术审查和管理复审，从技术和管理两方面对该阶段的开发成果进行检查，及时决定系统是继续进行，还是停工或是返工。
应防止直到开发结束时才发现已出现了损失和失败的结局。
对每个开发阶段都应进行认真的检查。
主要检查内容应包括是否有高质量的文档资料和开发日志。
确保前一个开发阶段完全结束后，下一个阶段才能开始。
划分软件开发阶段的方法有许多种，可按软件规模、种类、开发方式、开发环境等来划分生存周期。
不管用哪种方法划分，都要遵守以下两条原则：
一是各阶段工作任务彼此间尽可能相对独立；二是同一阶段的工作任务性质尽可能相同。
这样有利于软件工程的开发和组织管理。
软件生存周期一般由软件计划、软件开发和软件运行维护三个时期组成（即后面讨论的瀑布模型）。
软件计划时期分为问题定义、可行性研究两个阶段。
软件开发时期可分为需求分析、软件设计、测试等阶段。
软件交付使用后到软件废弃为软件运行维护时期，这个时期对软件系统需要不断地维护和修改，使软件能持久地满足用户的需要。
⒈问题定义
该阶段是软件生存期中最短的阶段。
这个阶段要确定系统“解决什么问题”。
对系统的目标、规模要有书面报告。
这就需要对系统用户和使用单位的负责人进行调查，问题定义报告要征得用户的同意。
⒉可行性研究
该阶段对问题定义阶段确定的系统目标进行全面的分析；探索问题是否有可能解决；更具体地确定工程的规模、目标；并估计系统的成本和效益；得出系统是否需要开发的结论。
对决策层及时作出中止不值得投资的项目，避免出现不必要的浪费的决策具有重大的作用。
可行性研究的任务是对今后的行动提出建议，其目的是确定问题是否值得解决，而不是立即去解决问题。
要达到这个目的必须进行客观分析，而且应在尽量短的时间内确定问题是否可行。
因而可行性研究是简化了的系统分析和设计。
首先需进一步分析问题定义，如果问题定义阶段确定的目标、规模正确，应进一步导出系统逻辑模型，经分析后提出几种可能的解法，对每种解法仔细研究其可行性。
如果问题定义阶段确定的规模过大，目标难于达到或开发成本过高，收益甚微，不值得投资，就应及时建议停止该项目的开发。
从而避免人力、物力、财力和时间上的浪费。
一般来说，每种解决方法的可行性应从以下两方面进行研究：
①经济可行性
根据系统规模和目标，确定系统的硬件资源和软件资源的需求规格，估算软件开发成本，分析系统的经济效益是否能超过它的开发总成本，获得从经济上分析系统是否值得投资的结论。
②技术可行性
分析系统是否存在有某些约束条件。
如果有，要全部列出并根据现有的技术，分析是否能够实现系统目标并研究用户是否能接受预定的操作方式。
得出在技术上是否值得研发的结论。
③使用可行性
研究将开发出来的系统是否能为公众和社会所接受。
④管理可行性
研究现有人员是否有胜任管理好系统的开发、运行和维护等系统所必需的经常性管理工作。
⑤法律可行性
研究期望的系统以及日后对系统的更新是否存在有违反现行法律的问题。
⒊需求分析
主要确定软件系统应具备的具体功能。
通常用数据流图、数据字典和简明算法描述出系统的逻辑模型。
虽然用户熟悉系统的全部功能和完成任务的全过程，但常常不能完整地、准确地提出任务要求。
而软件开发人员若不作深入、细致的调查、归纳和分析，就会对用户的具体要求了解不全面，理解不透彻。
自然这样设计出来的目标系统就肯定不会完全符合用户的需求。
这个阶段应当准确、完整地描述用户的要求，因而必须经用户确认才能进入下一阶段，这样可以防止出现系统设计与用户的实际需求不相符的后果。
⒋软件设计
通常软件设计的第一步是先进行总体设计。
总体设计要提出几种可能的解决方案，分析各种方案的成本／效益，与用户共同确定系统所采纳的方案，再进行系统结构设计，确定软件的体系结构。
软件设计的第二步是详细设计，描述如何具体地实现系统。
此后才是软件设计的第三步即程序设计（也称编码）。
软件设计的第四步是测试。
测试时先测试软件的每个部件（模块），再将部件（模块）装配在一起进行集成测试，最后在用户的参与下进行验收测试，用户验收通过后软件才可交付使用。
⒌软件维护
软件运行期间，通过各种必要的维护使系统适应环境变化，延长使用寿命和提高软件的效益。
软件运行期间会由于潜在的问题而发生错误；用户在使用后会提出一些改进或扩充软件的要求；软件运行的硬件、软件环境有时也会发生变化等，这些情况使软件需要不断地进行维护才能继续使用而不至于被废弃。
每次维护的要求、方案、计划及如何修改程序、重新测试、验收等一系列步骤都应详细准确地记录下来，作为文档加以保存。
§2.2软件开发模型
根据软件开发工程化的需要，软件生存周期内的开发阶段的划分也可以有所不同，从而形成了不同的软件生存周期模型（Softwarelifecyclemodel），或称软件开发模型。
软件开发模型实际上是一种开发软件系统所使用的宏观技术手段的递进的形式。
因此，软件开发模型不包括软件开发所必须的管理要素技术实施细节。
较为常见的软件开发模型有：
瀑布模型，快速原型，喷泉模型，软件重用开发模型和螺旋模型等。
一．瀑布模型（WaterfallMode1）
瀑布模型忠实遵循软件生存期内的开发阶段的划分，明确规定每个阶段的任务，各个阶段的工作顺序展开，恰如奔流不息拾级而下的瀑布（如图l-2所示）。
瀑布模型按照软件生存周期的计划、开发、运行三个大体的开发时期又可细分为若干个阶段：
计划时期可分为问题定义、可行性研究两个阶段，开发时期分为需求分析、总体设计、详细设计、程序设计、软件测试等阶段，运行时期则是运行和维护交织在一起的阶段。
瀑布模型软件开发有以下几个特点。
对应的文挡资料内容
系统目标
方案论证报告或计划任务书
开
需求规格说明书
发
系统功能结构图
时
设计规格书
期程序规格书和源程序
测试记录和用户操作手册
评价报告和维护记录
图1-2典型瀑布模型图
⒈软件生存周期的顺序性
只有前一阶段工作完成以后，后一阶段的工作才能开始。
前一阶段的输出文档，就是后一阶段的开发依据。
只有前一阶段有正确的结论，后一阶段才可能有正确的结果。
如果在生存周期的某一阶段出现了错误，往往要追溯到在它之前的某一阶段。
因此，瀑布模型开发适合于在软件需求比较明确，开发技术比较成熟，工程管理比较严格的场合下使用。
⒉尽可能推迟软件的编码
程序设计也称为编码。
实践表明，大、中型软件系统编码开始得越早，完成所需的时间反而越长。
瀑布模型在编码之前安排了需求分析、总体设计、详细设计等阶段，从而把逻辑设计和编码清楚地划分开来，尽可能推迟程序编码阶段。
⒊保证质量
为了保证质量，瀑布模型软件开发在每个阶段都要完成规定的文档，每个阶段都要对已完成的文档进行复审，以便及早发现隐患，排除故障。
瀑布模型是软件工程中较为典型的开发模型（套路），因而是学习软件工程的学生必须掌握的内容。
而且，在该瀑布模型中所介绍的许多具体开发方法、步骤、工具，也往往是其他软件开发模型的重要的参考内容。
二．快速原型（RapidPrototypeMode1）
正确的需求定义是软件系统开发成功的关键。
但是许多用户在开始时往往不能准确地叙述他们的需要，软件开发人员需要反复多次地和用户交流信息，才能全面、准确地了解用户的要求。
当用户实际使用了目标系统以后，也常常会改变原来的某些想法，对系统提出新的需求，以便使系统更加符合他们的期望需求。
快速原型（如图1-3所示）的思路是先根据需求分析的初步结果开发一个原型系统，请用户试用一段时间，以便能准确地认识到他们的实际需要应当是什么。
这相当于在工程上先制作“样品”试用后，作若干次的适应性改进，待定型后再批量生产一样。
虽然此法要额外花费一些成本，但是可以尽早获得更准确、更完整的需求，可以减少测试和调试的工作量，提高软
图1-3快速原型开发流程图
件质量。
因此快速原型法使用得当，能减少软件的总成本，缩短开发周期，也是目前比较流行的实用开发模式。
根据建立原型的目的不同，实现原型的途径也有所不同，通常有下述三种类型。
⒈渐增型
先选择一个或几个关键功能，建立一个不完全的系统。
此时只包含目标系统的一部分功能或对目标系统的全部功能从某些方面作简化，通过运行这个系统取得经验，加深对软件需求的理解，逐步使系统扩充和完善。
如此反复进行，直到用户对所设计的软件系统满意为止。
渐增型开发的软件系统是逐渐增长和完善的，所以从整体结构上不如瀑布型方法开发的软件那样清晰。
但是，由于渐增型开发过程自始至终都有用户参与，因而可以及时发现问题并加以修改，且更好地满足用户的需求。
⒉用于验证软件需求的原型
系统分析员在确定了软件需求之后，从中选出某些应验证的功能，用适当的工具快速构造出可运行的原型系统，由用户进行试用和评价。
这类原型往往在系统正式使用后就被废弃，因此构造它们的开发环境不必与目标系统的开发环境完全一致。
通常使用简洁而易于修改的超高级语言对原型进行编码。
⒊用于验证设计方案的原型
为了保证软件产品的质量，在总体设计和详细设计过程中，用原型来验证总体结构或某些关键算法的正确性。
在设计方案验证完成后就将原型废弃。
如果想把原型作为最终产品的一部分，原型和目标系统可使用同样的程序设计语言。
三．喷泉模型（Fountainmodel）
按传统的瀑布模型开发软件系统需要有两个前提：
①用户能清楚地提供系统的需求；
②开发者能完整地理解这些需求且软件生存周期的各阶段能明确地划分出来；
然而，在发软件系统实际开时，用户往往难以说清系统需求；由于多种主客观的原因，开发者也往往缺乏与用户交流的机会。
其结果是当系统开发完成后，修改、维护的开销及难度过大。
在面向对象软件开发的喷泉模型中，着重强调不同阶段之间的重叠；认为面向对象软件开发过程是一个螺旋形渐进的进化过程，不需要或不应该严格区分不同的开发阶段。
基于喷泉模型，Hodge等人提出将软件开发过程划分为概念模型分析、系统设计、对象设计和对象实现及系统组装等几个阶段，它也体现出分析和设计之间的重叠。
⒈概念模型分析
这个阶段主要目标是建立系统分析模型。
系统分析模型中的对象是现实世界中的客观对象的抽象，结构清晰、易于理解、易于描述。
在分析阶段面向问题（空间）域建立对象模型和过程模型。
⒉系统设计
给出符
升级会员 