第1章与软件工程的概念

1软件工程SoftwareEngineering2第1章

软件与软件工程

的概念3教学要求：【教学目的和要求】掌握：软件和软件工程的基本概念。了解：软件生存周期及软件开发的各种模型。【教学重点】软件、软件工程、软件生存周期和软件开发模型。【教学难点】软件生存周期和软件开发模型。【教学方法】课堂讲授、实证分析与学生自学相结合。4

教学内容：1.1软件的概念、特性和分类1.2软件危机与软件工程1.3系统工程的目标1.4软件生存期1.5软件生存期模型1.6软件工程知识体系及知识域51.1软件的概念、特性和分类软件的作用具有产品和产品生产载体的双重作用。作为产品，软件显示了由计算机硬件体现的计算能力，扮演着信息转换的角色：产生、管理、查询、修改、显示或者传递各种不同的信息。作为产品生产的载体，软件提供了计算机控制（操作系统）、信息通信（网络），以及应用程序开发和控制的基础平台（软件工具和环境）。

6软件的概念

虽然软件对于现代的人并不陌生，但很多人对于软件的理解并不准确，“软件就是程序，软件开发就是编程序”的这种错误观点仍然存在。什么是软件？7软件的概念软件：是计算机系统中与硬件相互依存的另一部分，包括程序，数据及其相关文档的完整集合。

程序：是按事先设计的功能和性能要求执行的指令序列。

数据：是使程序能正常操纵信息的数据结构。

文档：是与程序开发，维护和使用有关的图文材料。8软件的特性(1)形态特性：软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它是毫无意义的。(2)

智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题。9软件的特性(3)

开发特性：尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素。(4)

质量特性：目前还无法得到完全没有缺陷的软件产品。10软件的特性(5)

生产特性：与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限。(6)

管理特性：由于上述的几个特点，使得软件的开发管理显得更为重要，也更为独特。11软件的特性(7)

环境特性：软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性。

(8)

维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大差别。

12软件的特性(9)

废弃特性：与硬件不同，软件并不是由于被“用坏”而被废弃的。(10)

应用特性：软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位。

13软件的分类

按照软件的作用，一般将软件做如下分类：

(1)系统软件

(2)应用软件

(3)支撑软件

(4)可复用软件14软件危机暴发于上个世纪六十年代末。主要表现为：软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难。1.2软件危机与软件工程软件危机15软件危机软件危机：指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件具有的，实际上，几乎所有软件都不同程度地存在这些问题。软件危机包含两方面问题：

(1)如何开发——

以满足社会对软件日益增长的需求；

(2)如何维护——

更有效地维护数量不断膨胀的已有软件。16软件危机典型案例

典型案例——

软件危机历史教训

IBM360系统开发时间：1963-1966年投入人力：2000人总投资：5亿美元代码量：100万行每个版本都是从上一个版本找出1000个错误而修订的结果该项目负责人在总结项目时说：“正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难,……程序设计工作正像这样一个泥潭，……一批批程序员被迫在泥潭中拼死挣扎！！……谁也没有料到问题竟会陷入这样的困境……”

程序设计工作正像这样一个泥潭，一批批程序员被迫在泥潭中拼死挣扎！！17软件危机的典型表现(1)对软件开发成本和进度的估计常常很不准确.实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见。

1979年，美国审计署对政府项目进行了调查，其中9个软件项目的结果如下：2004年，StandishGroup(一个分析软件开发项目的研究机构)对9236个软件项目的研究结果如下：成功：29%取消：18%

推迟完成、超出预算和/或特性缺失：53%18

Year2009Year2006Year2004Year2002Year2000Year1998Year1996Year1994Successful32%35%29%34%28%26%27%16%Challenged44%19%53%15%23%28%40%31%Failed24%46%18%51%49%46%33%53%StandishGroup19软件危机的典型表现(2)用户对“已完成的”软件系统不满意的现象经常发生;

一般情况下，软件开发人员在开发初期对用户的要求只有模糊的了解，未能得到明确表达，就匆忙着手编写程序。开发工作开始后，软件人员和用户又未能及时交换意见，使得一些问题不能及时解决而隐藏下来，造成开发后期矛盾的集中暴露，导致开发的软件产品不能满足用户的要求。

“闭门造车”必然导致最终的产品不符合用户的实际需要。20软件危机的典型表现(3)软件产品的质量往往靠不住;

由于在开发过程中，没有确保软件质量的标准和措施，在软件测试时，又没有严格的、充分的、完全的测试，提交给用户的软件质量差，在运行中暴露出大量的问题。这种不可靠的软件，轻者会影响系统正常工作，重者会发生事故，甚至造成生命财产的重大损失。

例如：医疗软件的错误可能造成病人的生命危险，银行系统的错误会使金融混乱，航管系统的错误会造成飞机失事等等。21软件危机的典型表现(4)软件常常是不可维护的;

由于软件开发过程没有统一的、公认的规范指导，软件开发人员按各自的风格工作，各行其是。许多程序的个体化特性（程序的太过于技巧性），使得程序难以读懂，很多程序中的错误非常难改；或者是忽视了每个人的工作与其他人的接口部分，发现了问题修修补补，难以维护。

比如：当硬件环境发生变化，由于难于修改，而使它不可能适应新的硬件环境，当用户提出新的要求时，也不可能在程序中添加新功能，致使软件最终成为不可维护的。22软件危机的典型表现(5)软件通常没有适当的文档资料；

计算机软件不仅仅是程序，还应该有一整套文档资料。（“最新式的”）。管理人员：管理、评价软件开发工程的进展状况；开发人员：作为通信工具；维护人员：文档资料更是必不可少的——维护的依据

缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的困难和问题。23软件危机的典型表现(6)软件成本在计算机系统总成本中所占比例逐年上升；由于微电子学技术的进步和生产自动化程度不断提高，硬件成本逐年下降；随着软件规模和数量的不断扩大，软件开发需要大量人力，即软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，因此软件的成本是比较高的，且呈逐年上升趋势。

如：美国在1985年软件成本大约已占计算机系统总成本的90%。24软件危机的典型表现(7)软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。25产生软件危机的原因产生软件危机的原因:客观原因：

与软件本身的特点有关主观原因：

和软件开发与维护的方法不正确有关26产生软件危机的客观原因--软件本身的特点①软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。

软件人员就像：皇帝的新衣中的裁缝

逻辑往往存在于人的头脑当中，无法看到它的具体形态。由于软件缺乏“可见性”，因此，管理和控制软件的开发过程相当困难。

27产生软件危机的客观原因--软件本身的特点②软件在运行过程中不会因为使用时间过长而被“用坏”，但是会退化。

软件维护通常意味着改正或修改原来的设计，这就在客观上使得软件较难维护。

28产生软件危机的客观原因--软件本身的特点③软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统，更是一个极端复杂困难的问题，不仅涉及许多技术问题，诸如分析方法、设计方法等，更重要的是必须有严格而科学的管理。

29产生软件危机的主观原因—开发与维护方法主观原因：软件开发与维护的方法不正确①早期阶段软件开发的个体化特点

忽视软件需求分析的重要性，认为软件开发就是写程序，轻视软件维护等。事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。

30产生软件危机的主观原因—开发与维护方法②软件开发和维护要经历一个漫长的生命周期.

a)

问题定义

b)

可行性研究

c)

需求分析

d)

软件设计（总体设计和详细设计）

e)

编写程序（软件开发全部工作量的10%-20%）

f)

测试（软件开发全部工作量的40%-50%）

编写程序只是软件开发过程中的一个相对来说比较次要的阶段。

原理31产生软件危机的主观原因—开发与维护方法③程序只是完整的软件产品的一个组成部分，一个软件产品必须由一个完整的配置组成.

软件配置主要包括:a)程序

b)文档

c)数据

程序是能够完成预定功能和性能的可执行的指令序列；

文档是开发、使用和维护程序所需要的图文资料。

数据是使程序能够适当地处理信息的数据结构；32产生软件危机的主观原因—开发与维护方法④轻视维护是一个最大的错误。

严重的问题是，在软件开发的不同阶段进行修改需要付出的代价是很不相同的。

在早期引入变动，代价比较低；在中期引入变动，逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时再引入变动，当然需要付出更高的代价。不同阶段发现和纠正一个相同错误的花费：需求阶段：10元分析阶段：30元设计阶段：40元实现阶段：520元交付后维护阶段：3680元

图1.1引入同一变动付出的代价随时间变化的趋势60%~70%的错误都是需求、分析或设计错误33消除软件危机的途径要想消除软件危机：除了应该对计算机软件有一个正确的认识外，更重要的是：既要有技术措施（方法和工具），又要有必要的组织管理措施。

组织管理：软件开发不是某种个体劳动的神秘技巧，软件开发应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。方法：应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法。工具：应该开发和使用更好的软件工具。在适当的软件工具辅助下，开发人员可以把许多繁琐重复的工作做得既快又好。（如：计算机辅助软件工具CASE工具）34如何摆脱软件危机彻底消除“软件就是程序”的错误观念。充分认识到软件开发应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。推广和使用在实践中总结出来的开发软件的成功技术、方法和工具。按工程化的原则和方法组织软件开发工作。35软件工程的概念为了克服软件危机，1968年10月在北大西洋公约组织（NATO）召开的计算机科学会议上，FritzBauer首次提出“软件工程”的概念，试图将工程化方法应用于软件开发。在NATO会议上，FritzBauer对软件工程的定义是：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。”361993年IEEE给出的定义：“软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；②研究①中提到的途径。”。软件工程的概念37软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。它不仅指出了软件工程的目标是经济地开发出高质量的软件并有效地维护它，而且强调了软件工程是一门工程学科，它应该建立并使用完善的工程原理。

软件工程的概念38软件工程的两个层面：软件工程是工程领域的一个专业领域，如同建筑工程、电力工程等，因此系统工程的一些概念、原理和方法也适用于软件工程，----用工程化的思想来解决软件开发的管理问题软件工程是一门学科，是研究如何将软件开发工程化的方法和技术，目标是要软件生产工程化----生产计算机软件产品（例如组件就是计算机软件插件）软件工程的作用就是告诉你如何开发正确的软件----客户所需要的软件如何正确地开发软件----包括一个过程，一组方法，一系列工具39软件工程的本质特性①软件工程关注于大型程序的构造把多人合作用时半年以上才写出的程序称为大型程序②软件工程的中心课题是控制复杂性

复杂问题简单化——

分解成模块，便于管理控制如：图书借阅系统——

图书检索、借阅处理、图书管理等

③软件经常变化

软件必须随着所模拟的现实事物一起变化如：不满足用户需求、扩充完善；操作系统、硬件环境、网络化④开发软件的效率非常重要寻求开发与维护软件的更好更有效的方法和工具。如：软件重用、软件移植40软件工程的本质特性⑤和谐地合作是开发软件的关键提倡团队合作精神——

每个中国人都是一条龙⑥软件必须有效地支持它的用户

满足用户的需求。如：功能需求、可靠性、响应时间等为用户提供服务。如：提供用户手册、进行培训、帮助用户习惯新流程、网络环境等。⑦在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。

软件工程师不得不为自己不熟悉的专业领域开发应用系统。决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程。如：图书馆管理、银行事务、对外贸易、股票证券等。

41软件工程的基本原理软件工程的7条基本原理:--1983著名的软件工程专家B.W.Boehm①用分阶段的生命周期计划严格管理②坚持进行阶段评审③实行严格的产品控制④采用现代程序设计技术⑤结果应能清楚地审查⑥开发小组的人员应该少而精⑦承认不断改进软件工程实践的必要性42软件工程的基本原理软件工程的7条基本原理:①用分阶段的生命周期计划严格管理

计划是第一位的。

如：目标、进度计划、成本计划等②坚持进行阶段评审

软件的质量保证原理

——不能等到编码结束之后③实行严格的产品控制

变动控制原理：a)评审、审批

b)软件配置一致性（文档“最新式的”）50%失败项目由于计划不周63%设计错误变动不可避免生命周期43软件工程的基本原理软件工程的7条基本原理:④采用现代程序设计技术采用先进的技术提高效率和质量。⑤结果应能清楚地审查规定明确的责任、目标、产品标准，以此作为审查的标准。⑥开发小组的人员应该少而精⑦承认不断改进软件工程实践的必要性在今后的实践中不断总结经验，积累有价值的数据资料。

开发过程不可见

难以度量

借助木棒翘起巨石

—方法比力气更有效44软件工程方法学比喻（故事）：围棋与软件工程的感想围棋围棋棋谱拿过来的时候,大师问“后面应该走哪里？”十个初级爱好者选择的落点散布在棋盘各处……

十个职业棋手说的落子点都差不多，甚至包括后面的几步……

这就是高手和低手的差别……软件工程当一个小程序拿过来的时候,项目经理让大家编写……

十个中国软件工程师写出来的程序各有“特色”、千差万别，十个印度软件工程师写出来的程序差不多，以至于怀疑是“抄袭”。项目经理也不清楚中国软件业和印度软件业的差距是多少年只是觉得差了好远好远……软件必须有正确的方法做指导45软件工程方法学软件工程方法学:

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型。包括三个要素：①方法：

完成软件开发的各项任务的技术方法，回答“怎样做”的问题。

②工具：

为运用方法而提供的自动的或半自动的软件工程支撑环境。

③过程：为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。46软件工程方法学目前使用得最广泛的软件工程方法学：传统方法学面向对象方法学47软件工程方法学—传统方法学传统方法学：

传统方法学－生命周期方法学/结构化范型把软件生命周期的全过程依次划分为若干个阶段，每个阶段有相对独立的任务，然后顺序地完成每个阶段的任务。48软件工程方法学—面向对象方法学面向对象方法学

是把数据和行为看成同等重要，是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。用对象分解取代传统的功能分解。把所有的对象都划分成类。比如：人按照父类与子类的关系，把若干个相关类组织成一个层次结构的系统。（继承）对象彼此间仅能通过发送消息相互联系。面向对象的4个要点，可用下列方程式概括：

面向对象方法=对象+类+继承+用消息通信491.3软件工程的目标软件工程的目标：是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。软件质量：就是“软件与明确地和隐含地定义的需求相一致的程度”。具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。50软件的质量特性功能性：是指软件所实现的功能达到它的设计规范和满足用户需求的程度；可靠性：是指在规定的时间和条件下，软件能够正常维持其工作的能力；可使用性：是指为了使用该软件所需要的能力；效率：是指在规定的条件下用软件实现某种功能所需要的计算机资源的多少；可维护性：是指当环境改变或软件运行发生故障时，为了使其恢复正常运行所做努力的程度（工作量的大小）；可移植性：是指软件从某一环境转移到另一环境时所做努力的程度。51质量目标之间的关系521.4软件生存期软件也有一个孕育、诞生、成长、成熟和衰亡的生存过程，我们称这个过程为软件生命周期或软件生存期。软件生存期由软件定义、软件开发和运行维护3个时期组成，每个时期又可划分为若干个阶段。软件定义时期问题定义、可行性研究、需求分析软件开发时期总体设计、详细设计、编码和单元测试、综合测试运行维护时期软件维护

53软件定义时期这个时期的工作通常又称为系统分析，由系统分析员负责完成。①问题定义必须回答的关键问题是：“要解决的问题是什么?”

比如：

◆

问题性质：关于什么的软件、要解决什么问题等

◆工程目标：项目最后要达到什么目标、问题能解决到什么程度

◆

工程规模：

投入的人财物、网络化等

系统分析员根据自己对问题的理解，扼要地写出书面文档。54软件定义时期②可行性研究要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗?”

主要是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。

◆技术可行性：现有技术能实现吗？

◆

经济可行性：成本/效益分析

◆

操作可行性：此操作方式能行得通吗？通常用系统流程图、数据流图等表示系统的逻辑模型，还要进行成本/效益分析，写出《可行性研究报告》。55软件定义时期③需求分析是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。

◆获取用户的要求——要做到准确完整，◆建立系统的功能逻辑模型

——分析员要分析、整理和提炼所收集到的用户需求，据此建立完整的分析模型

◆编写软件《需求规格说明》。通常用数据流图、实体-联系图、层次方框图、IPO图等工具描述系统的逻辑模型。56软件开发时期①总体设计

要回答的关键问题是：“概括地说，应该怎样实现目标系统?”。总体设计又称为概要设计。”

◆

设计出实现目标系统的几种可能的方案

——用一些表达工具描述每种方案

◆

分析每种方案的优缺点，并做比较权衡利弊

——推荐一个最佳方案。

◆

设计程序的体系结构

——确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图等工具描绘软件的结构。57软件开发时期②详细设计——模块设计

要回答的关键问题是：“应该怎样具体地实现这个系统呢?”，也就是把解法具体化。◆详细地设计每个模块

——确定实现模块功能所需要的算法和数据结构。◆

设计出程序的《详细规格说明》——程序员可以根据它们写出实际的程序代码。

通常用程序流程图、盒图(N-S图)、PAD图、判定树、判定表等工具描述详细设计的结果。

工程蓝图58软件开发时期③编码和单元测试

这个阶段的关键任务是写出正确的、容易理解、容易维护的程序模块。◆写程序代码

——程序员选取一种适当的程序设计语言，把详细设计的结果“翻译”成可以在计算机上正确运行的程序代码。

◆测试编写出的每一个模块——模块测试

59软件开发时期④综合测试

这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。通常包括：

◆集成测试：组装测试

◆验收测试：确认测试。

——按照规格说明书的规定，进行验收

用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，写出《测试报告》。

60运行维护时期软件维护维护阶段的关键任务是：通过各种必要的维护活动使系统持久地满足用户的需要。通常有4类维护：纠错性维护：诊断和改正软件错误，50%

适应性维护：修改软件以适应环境的变化完善性维护：改进或扩充软件使它更完善预防性维护：修改软件为将来做准备每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。许多组织将其软件预算的70%~80%或更多用于交付后维护。

61

软件生命周期各个阶段的基本任务问题定义可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护要解决的问题是什么？问题性质、工程目标和规模的报告分析员：实际用户+负责人是否有解决办法？分析员

高层逻辑模型，准确和具体的工程规模和目标，成本/效益分析等可行性报告为了解决的问题，目标系统必须做什么？准确确定系统的功能系统的逻辑模型（数据流图+数据字典+简要算法）如何解决这些问题模块划分软件结构如何具体地实现系统：每个模块的流程图（程序的详细规格说明）通过各种类型的测试，使软件达到预定的要求写出正确的容易理解和容易维护的程序模块

通过各种必要的维护活动使系统持久地满足用户的需要62软件工程与软件文档软件工程实施的效果如何

——文档资料是否完整、健全、一致。

总之：

软件工程是软件开发的必由之路；

软件文档是软件工程的重要成果。63

软件文档是以可读的形式出现的技术数据和信息。文档描述或规定软件设计细节，说明软件具备的能力，或为使用软件以便从软件系统得到所期望的结果而提供的操作指令。什么是软件文档64

——是软件工程的重要质量保证措施（1）管理依据（2）任务之间联系的凭证（3）质量保证（4）培训与参考（5）软件维护支持（6）历史档案

软件文档的作用65按照软件生存周期划分：（1）软件定义时期（2）软件开发时期（3）软件的维护时期

软件文档的分类（一）66定义时期(1)问题定义立项报告1问题性质2工程目标3工程规模……系统分析员Systemanalyst客户customer（要解决什么问题）67定义时期(2)可行性研究可行性研究报告1可行性2方案选择3初步计划和预算……系统分析员Systemanalyst（确定问题能否解决）68定义时期（3）需求分析需求规格说明书

1.功能

2.性能

3.数据

4.环境

5.将来系统分析员Systemanalyst（确定系统的功能）69开发时期（4）概要设计概要设计说明书

1.方案设计

2.体系结构设计

软件工程师Softwareengineer（建立软件结构）70开发时期(5)详细设计详细设计说明书

1.模块设计

2.数据结构设计

软件工程师Softwareengineer（确定模块的过程结构）71开发时期（6）编码和单元测试程序代码：Main(){inta,b,c;Scanf(a,b,c);Printf();}程序员programmer（编写程序）72开发时期（7）综合测试系统测试员Systemtester客户customer操作员operator测试计划测试报告（发现并排除错误）73运行时期（8）软件维护维护工程师Maintenanceengineer软件问题报告、软件修改报告（运行和管理）74软件生命周期计划时期开发时期运行问题定义可行性研究需求分析总体设计(系统分析)详细设计(系统设计)编码测试维护主要文档：

可行性研究报告、开发实施计划、软件需求说明书、初步用户手册、确认测试计划软件概要设计说明书、软件详细设计说明书、数据库设计说明书、测试计划、测试报告软件问题报告、软件修改报告75（1）开发文档：是描述软件开发过程的一类文档。

软件文档的分类（二）基本的开发文档有：（1）可行性研究和项目任务书。（2）需求规格说明（3）功能规格说明（4）设计规格说明，包括程序和数据规格说明（5）开发计划（6）软件集成和测试计划（7）质量保证计划、标准、进度（8）安全和测试信息76基本的产品文档包括：（1）培训手册（2）参考手册和用户指南（3）软件支持手册（4）产品手册和信息广告（2）产品文档描述开发过程的产物的一类文档，规定关于软件产品的使用、维护、增强、转换和传输的信息。77（3）管理文档：记录项目管理的信息。基本的管理文档包括：（1）进度变更记录（2）软件变更情况记录（3）配置管理报告（4）里程碑报告781.5软件生存期模型软件过程软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。通常使用生命周期模型简洁地描述软件过程。典型的软件过程模型：瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、统一过程79瀑布模型

在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型。传统的瀑布模型如图1-1所示。

现在它仍然是软件工程中应用得最广泛的过程模型。

各阶段的工作自顶向下从抽象到具体顺序进行，就好像奔流不息的瀑布，一泻千里，总是从高处依次流到低处。

实线——开发过程虚线——维护过程80瀑布模型的特点特点：①阶段间具有顺序性和依赖性

a)前一阶段的工作是后一阶段工作的基础；

b)前一阶段的输出文档是后一阶段的输入文档。②推迟实现的观点

在编码之前设置了系统分析与系统设计的各个阶段，避免急于求成，付出巨大代价。

若使瀑布落下的水回流，付出的代价是巨大的。

81瀑布模型的特点

特点：③质量保证的观点

a)每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。

b)每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误，降低软件的成本。82瀑布模型的优缺点

优点：

①强迫开发人员采用规范的方法；②严格地规定了每个阶段必须提交的文档；③每个阶段结束前必须正式进行严格的技术审查和管理复审。

缺点：在可运行的软件产品交付给用户之前，用户只能通过文档（静态）来了解产品是什么样的，通常很难使用户全面正确地认识动态的产品软件。开发人员和用户之间缺乏有效的沟通，而只是完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。瀑布模型只适用于项目开始时需求已确定的情况。

文档驱动型

83快速原型模型快速原型：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。快速原型模型如图1-3所示。84快速原型模型的优点(1)有助于满足用户的真实需求。(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。(3)软件产品的开发基本上是按线性顺序进行。(4)因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。85快速原型模型的优点(5)开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。(6)快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途：获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此原型系统的内部结构并不重要，关键是迅速构建和修改。86螺旋模型螺旋模型

螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动。

实线——开发过程虚线——维护过程图1.7简化的螺旋模型基本思想是，使用原型及其他方法来尽量降低风险。--增加了风险分析过程的快速原型模型87完整的螺旋模型螺旋模型的四个步骤：

制定计划──确定软件目标，选定实施方案，弄清项目开发的限制风险分析──分析所选方案，考虑如何识别和消除风险实施工程──实施软件开发客户评估──评价开发工作，提出修正建议8889螺旋模型的优缺点

优点：对可选方案和约束条件的强调有利于已有软件的重用有助于把软件质量作为软件开发的一个重要目标减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别适用于内部开发的大规模软件项目它是风险驱动的.缺点：要求软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险。90喷泉模型是典型的面向对象的软件过程模型之一。面向对象的方法学：在分析、设计、实现阶段使用统一的概念和表示符号，整个开发过程是“无缝”连接的“喷泉”一词体现了迭代和无间隙特性。图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在重叠。

迭代和求精91增量模型增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。92增量模型增量模型如图所示。

93增量模型的优点(1)能在较短时间内向用户提交可完成一些有用的工作产品，即从第1个构件交付之日起，用户就能做一些有用的工作。(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。因此，最重要的系统服务将接受最多的测试。94增量构件开发

每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布模型的方式，如图所示。

95采用增量模型需注意的问题(1)在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。(2)软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。96基于构件的开发模型基于构件的软件工程（component-basedsoftwareengineering，CBSE）是强调使用可复用的软件“构件”来设计和构造基于计算机的系统的过程。97基于构件的开发模型Clements对CBSE给出了如下描述。

CBSE正在改变大型软件系统的开发方式。CBSE体现了FrodBrooks和其他人支持的“购买，而非构造”的思想。就如同早期的子程序将程序员从考虑编程细节中解脱出来一样，CBSE将考虑的重点从编码转移到组装软件系统。

考虑的焦点是“集成”，而不再是“实现”。

这样做的基础是假定在很多大型软件系统中存在足够多的共性，使得开发可复用的构件来满足这些共性是可行的。98基于构件的开发模型当软件团队使用传统的需求获取技术确定了待开发软件的系统需求时，该过程开始。体系结构设计完成后，并不立即进行详细设计任务，而是针对每一系统需求考虑以下问题:(1)现有的商品化构件（commercialoff-the-shelf，COTS）是否能够实现该需求？(2)内部开发的可复用构件是否能够实现该需求？(3)可用构件的接口与待构造系统的体系结构是否相容？99基于构件的开发模型100基于构件的开发模型开发步骤

不考虑构件的开发技术，基于构件的开发模型由以下步骤组成：(1)对于该问题领域的基于构件的可用产品进行研究和评估。(2)考虑构件集成的问题。(3)设计软件架构以容纳这些构件。(4)将构件集成到架构中。(5)进行充分的测试以保证功能正常。101典型的构件模型(1)OMG/CORBA。对象