软件工程的概要介绍[上学期]

(共68张PPT)
第1章 软件工程学概述
1.1 软件危机
1.2 软件工程
1.3 软件生命周期
1.4 软件过程
1.5 小结
迄今为止，计算机系统已经经历了4个不同的发展阶段。
1.1.1 软件危机的介绍
软件危机:
是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
概括：如何开发软件，以满足对软件日益增长的需求；
如何维护数量不断膨胀的已有软件。
具体：
软件危机的典型表现：
1.1 软件危机
软件危机的典型表现：
对软件开发成本和进度的估计常常很不准确。
用户对“已完成的”软件系统不满意的现象经常发生。案例1
(3) 软件产品的质量往往靠不住。案例2
(4) 软件常常是不可维护的。统计数据
(5) 软件通常没有适当的文档资料。
(6) 软件成本在计算机系统总成本中所占的比例逐年上升。
(7) 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
软件危机典型表现案例1：
美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。......据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。......
这个项目的负责人F. D. Brooks事后总结了他在组织开发过程中的沉痛教训时说：“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭，......一批批程序员被迫在泥潭中拼命挣扎，......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。
Software Crisis !
软件危机典型案例2：
In the early 1980s, the United States’ Internal Revenue Service (IRS)国内税收 hired Sperry Corporation to build an automated federal income tax form processing system. According to the Washington Post, the “system has proved inadequate to the workload, cost nearly twice what was expected and must be replaced soon” (Sawyer 1985). In 1985, an extra $90 million was needed to enhance the original $103 million worth of Sperry equipment. In addition, because the problem prevented the IRS from returning refunds退款 to taxpayers by the deadline, the IRS was forced to pay $40.2 million in interest and $22.3 million in overtime wages for its employees who were trying to catch up.
软件危机典型案例2：
In 1996, the situation had not improved. The Los Angeles Times reported on March 29 that there was still no master plan for the modernization of IRS computers, only a six-thousand-page technical document. Congressman Jim Lightfoot called the project “a $4-billion fiasco惨败 that is floundering(挣扎) because of inadequate planning” (Vartabedian 1996).
Myth: If we get behind schedule, we can add more programmers and catch up.
Reality: Software development is not a mechanistic process like manufacturing. In the words of Brooks, “adding people to a late software project makes it later.”
1979年，美国US Government Accounting Office对政府项目进行了调查
与软件本身的特点有关；
软件缺乏“可见性”——管理和控制软件开发相当困难
规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
与软件开发与维护的认识和观念不正确有关。
忽视软件需求分析的重要性——许多软件开发工程失败的主要原因之一
认为软件开发就是写程序并设法使之运行，没有足够的文档，轻视软件维护。——软件产品=程序+文档+数据
软件开发与维护的方法不正确
对系统需求没有清楚和准确的认识就进入开发阶段
忽视对软件开发过程的管理；
1.1.2 产生软件危机的原因
首先应该对计算机软件有一个正确的认识。
1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。
既要有技术措施(方法和工具)
又要有必要的组织管理措施。
1.1.3 消除软件危机的途径
简单的正确认识：
编写程序只是软件开发过程中的一个阶段，而且在典型的软件开发工程中，编写程序所需的工作量只占软件开发全部工作量的10%～20%。
程序只是完整的软件产品的一个组成部分，在上述软件生命周期的每个阶段都要得出最终产品的一个或几个组成部分(这些组成部分通常以文档资料的形式存在)。
做好软件定义时期的工作是降低成本和提高质量的关键。
“软件”编程，它有自己的生命周期 (life cycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。
——诞生“软件工程”(Software Engineering)” 学科
NATO Conference , Garmisch , Germany , 1968.
软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。
概括地说，软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
1.2 软件工程
1.2.1 软件工程的介绍
软件工程定义
Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
IEEE：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。
Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
软件工程是一类求解软件的工程，它应用计算机科学、数学（用于构造模型和算法）和管理科学（用于计划、资源、质量和成本等的管理）等原理，借鉴传统工程（用于制定规范、设计范型、评估成本、权衡结果）的原则和方法，创建软件以达到提高质量、降低成本的目的。
软件工程是一门指导计算机软件开发和维护的工程学科。
软件工程是一门交叉学科
软件开发技术:软件开发方法学
软件开发过程
软件工具和软件工程环境
软件工程管理:软件管理学
软件经济学
软件心理学
软件工程所包含的内容不是一成不变的，随着人们对软件系统的研制开发和生产的理解。应用发展的眼光看待它。
软件需求
软件设计
软件构造
软件测试
软件维护
软件配置管理
软件工程管理
软件工程过程
软件工程工具和方法
软件质量
软件工程知识结构
1. 用分阶段的生命周期计划严格管理
2. 坚持进行阶段评审
软件开发的不同阶段进行修改需要付出的代价
3. 实行严格的产品控制---实行基准配置管理
4. 采用现代程序设计技术
5. 结果应能清楚地审查
6. 开发小组的人员应该少而精
7. 承认不断改进软件工程实践的必要性
1.2.2 软件工程的基本原理
在软件开发的不同阶段进行修改需要付出的代价是很不相同的：
在早期引入变动，涉及的面较少，因而代价也比较低；
在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；
在软件“已经完成”时再引入变动，当然需要付出更高的代价。
下图定性地描绘了在不同时期引入一个变动需要付出的代价的变化趋势。
软件开发的不同阶段进行修改需要付出的代价
图1.1引入同一变动付出的代价随时间变化的趋势
软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。
所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。
1.2.3 软件工程方法学
软件工程方法学包含3个要素：方法、工具和过程。
方法 是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；（目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学）.
工具 是为运用方法而提供的自动的或半自动的软件工程支撑环境；
过程 是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤
软件工程方法学的3要素
1. 传统方法学
传统方法学也称为生命周期方法学或结构化范型。特点：
它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。
前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。
在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审。
审查的一条主要标准就是每个阶段都应该交出“最新式的”(即和所开发的软件完全一致的)高质量的文档资料。
目前使用最广泛的软件工程方法学
2. 面向对象方法学
当软件规模庞大，或者对软件的需求是模糊的或会随时间而变化的时候，使用传统方法学开发软件往往不成功，此外，使用传统方法学开发出的软件，维护起来仍然很困难。
面向对象方法是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。
正确地运用面向对象方法学开发软件产品降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。
促进了软件重用。
定义：
概括地说，软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组成，每个时期又进一步划分成若干个阶段。
1.3 软件生命周期
软件定义时期的任务
确定软件开发工程必须完成的总目标；
确定工程的可行性；
导出实现工程目标应该采用的策略及系统必须完成的功能；
估计完成该项工程需要的资源和成本，并且制定工程进度表。
这个时期的工作通常又称为系统分析，由系统分析员负责完成。
软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。
开发时期时期的任务
具体设计和实现在前一个时期定义的软件。
通常由下述4个阶段组成：
总体设计，详细设计，编码和单元测试，综合测试。
系统设计 系统实现
维护时期的任务
主要是使软件持久地满足用户的需要。具体地说，
当软件在使用过程中发现错误时应该加以改正；
当环境改变时应该修改软件以适应新的环境；
当用户有新要求时应该及时改进软件以满足用户的新需要。
每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
软件生命周期每个阶段的基本任务
1.问题定义
2. 可行性研究
3. 需求分析
4. 总体设计
5. 详细设计
6. 编码和单元测试
7. 综合测试
8. 软件维护
教材：p11~14
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
在完成开发任务时必须进行一些开发活动，并且使用适当的资源，在过程结束时将把输入转化为输出。
ISO 9000对过程的定义：
“使用资源将输入转化为输出的活动所构成的系统。”
此处，“系统”的含义是广义的：“系统是相互关联或相互作用的一组要素。”
1.4 软件过程
过程定义了：
运用方法的顺序；
应该交付的文档资料；
为保证软件质量和协调变化所需要采取的管理措施；
标志软件开发各个阶段任务完成的里程碑。
为获得高质量的软件产品，软件过程必须科学、有效。
通常使用生命周期模型简洁地描述软件过程。
生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。
在20世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。
1.4.1 瀑布模型
图1.2 传统的瀑布模型
图1.2所示为传统的瀑布模型。按照传统的瀑布模型开发软件，有下述的几个特点。
1. 阶段间具有顺序性和依赖性
2. 推迟实现的观点
3. 质量保证的观点
在瀑布模型的每个阶段都应坚持两个重要做法： （1） 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
（2） 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。事实上，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量，降低软件成本的重要措施。
实际的瀑布模型
传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出来，在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带“反馈环”的，如图1.3所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
图1.3 实际的瀑布模型
瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。遵守瀑布模型的文档约束，将使软件维护变得比较容易一些。由于绝大部分软件预算都花费在软件维护上，因此，使软件变得比较容易维护就能显著降低软件预算。可以说，瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
但是，“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。但是，仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品。而且事实证明，一旦一个用户开始使用一个软件，在他的头脑中关于该软件应该做什么的想法就会或多或少地发生变化，这就使得最初提出的需求变得不完全适用了。事实上，要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的。总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。
所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。如图1.4所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。
1.4.2 快速原型模型
通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。
从图1.4可以看出，快速原型模型是不带反馈环的，这正是这种过程模型的主要优点： 软件产品的开发基本上是线性顺序进行的。能做到基本上线性顺序开发的主要原因如下：
图1.4 快速原型模型
（1） 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
（2） 开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，如图1.4中虚线箭头所示。
快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，原型系统的内部结构并不重要，重要的是，必须迅速地构建原型然后根据用户意见迅速地修改原型。UNIX Shell和超文本都是广泛使用的快速原型语言，最近的趋势是，广泛地使用第四代语言（4GL）构建快速原型。
当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分用到最终的软件产品中。
增量模型也称为渐增模型，如图1.5所示。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。
1.4.3 增量模型
把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。
采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。
图1.5 增量模型
增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。但是，从长远观点看，具有开放结构的软件拥有真正的优势，这样的软件的可维护性明显好于封闭结构的软件。
因此，尽管采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。如果一个设计非常灵活而且足够开放，足以支持增量模型，那么，这样的设计将允许在不破坏产品的情况下进行维护。事实上，使用增量模型时开发软件和扩充软件功能（完善性维护）并没有本质区别，都是向现有产品中加入新构件的过程。
从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。
图1.5所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计的工作。由于在开始构建第一个构件之前已经有了总体设计，因此风险较小。图1.6描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档，完成后规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构件……用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。
图1.6 风险更大的增量模型
软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。
1.4.4 螺旋模型
构建原型是一种能使某些类型的风险降至最低的方法。正如1.4.2节所述，为了降低交付给用户的产品不能满足用户需要的风险，一种行之有效的方法是在需求分析阶段快速地构建一个原型。在后续的阶段中也可以通过构造适当的原型来降低某些技术风险。当然，原型并不能“包治百病”，对于某些类型的风险，原型方法是无能为力的。
螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型，如图1.7所示。
完整的螺旋模型如图1.8所示。
图1.7 简化的螺旋模型
图1.8 完整的螺旋模型
螺旋模型有许多优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。
螺旋模型的主要优势在于，它是风险驱动的，但是，这也可能是它的一个弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常。
本章力图对计算机软件工程学作一个简短的概述。首先通过回顾计算机系统发展简史，说明开发软件的一些错误方法和观念是怎样形成的。然后列举了这些错误方法带来的严重弊病(软件危机)，澄清了一些糊涂观念。为了计算机系统的进一步发展，需要认真研究开发和维护软件的科学技术。应总结计算机软件的历史经验教训，借鉴其他工程领域的管理技术，逐步使软件工程这门新学科发展和完善起来。
1.5 小结
本章力求使读者对软件工程的基本原理和方法有概括的本质的认识。生命周期方法学把软件生命周期划分为若干个相对独立的阶段，每个阶段完成一些确定的任务，交出最终的软件配置的一个或几个成分(文档或程序)； 基本上按顺序完成各个阶段的任务，在完成每个阶段的任务时采用结构化技术和适当的软件工具；在每个阶段结束之前都进行严格的技术审查和管理复审。
当软件规模庞大或对软件的需求模糊易变时，采用生命周期方法学开发往往不成功，近年来在许多应用领域面向对象方法学已经迅速取代了生命周期方法学。面向对象方法学有4个要点，可以用下列方程式概括：
面向对象方法=对象+类+继承+用消息通信
也就是说，面向对象方法就是既使用对象又使用类和继承等机制，而且对象之间仅能通过传递消息实现彼此通信的方法。
面向对象方法简化了软件的开发和维护，提高了软件的可重用性。
按照在软件生命周期全过程中应完成的任务的性质，在概念上可以把软件生命周期划分成问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试以及运行维护等8个阶段。实际从事软件开发工作时，软件规模、种类、开发环境及使用的技术方法等因素，都影响阶段的划分。
软件过程是为了获得高质量的软件产品所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。由于没有一个适用于所有软件项目的任务集合，科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。
通常使用软件过程模型简洁地描述软件过程，它规定了把软件生命周期划分成的阶段及各个阶段的顺序。本章介绍了4种典型的软件过程模型。
瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法；这种模型的问题是，最终开发出的软件产品可能并不是用户真正需要的。
快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建起一个可在计算机上运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。
增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点，但是，要求软件具有开放的结构是使用这种模型时固有的困难。
风险驱动的螺旋模型适用于内部开发的大型软件项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。
1-1 什么是软件危机 它有哪些典型表现 为什么会出现软件危机
1-2 假设你是一家软件公司的总工程师，当你把图1.1给手下的软件工程师们观看，告诉他们及早发现并改正错误的重要性时，有人不同意你的观点，认为要求在错误进入软件之前就清除它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢 ”你怎么反驳他
1-3 什么是软件工程 它有哪些本质特性 怎样用软件工程消除软件危机
习题
1-4 简述结构化范型和面向对象范型的要点，并分析它们的优缺点。
1-5 根据历史数据可以做出如下的假设：
对计算机存储容量的需求大致按下面公式描述的趋势逐年增加：M=4080e0.28(Y-1960)
存储器的价格按下面公式描述的趋势逐年下降：P1=0.3×0.72Y-1974(美分/位)
如果计算机字长为16位，则存储器价格下降的趋势为：P2=0.048×0.72Y-1974(美元/字)
在上列公式中Y代表年份，M是存储容量(字数)，P1和P2代表价格。
基于上述假设可以比较计算机硬件和软件成本的变化趋势。要求计算：
(1) 在1985年对计算机存储容量的需求估计是多少 如果字长为16位，这个存储器的价格是多少
(2) 假设在1985年一名程序员每天可开发出10条指令，程序员的平均工资是每月4000美元。如果一条指令为一个字长，计算使存储器装满程序所需用的成本。
(3) 假设在1995年存储器字长为32位，一名程序员每天可开发出30条指令，程序员的月平均工资为6000美元，重复(1)、(2)题。
1-6 什么是软件过程 它与软件工程方法学有何关系
1-7 什么是软件生命周期模型 试比较瀑布模型、快速原型模型、增量模型和螺旋模型的优缺点，说明每种模型的适用范围。