《软件详细设计教程》课件第1章

第1章软件工程概述1.1软件1.2软件危机1.3软件工程1.4软件工程知识体系(SWEBOK)1.5软件过程1.6软件项目管理基础1.7小结 1.1软件

1.1.1软件的定义

在软件的发展过程中，软件从手工作坊式的程序演变为工程化的产品，人们对软件的看法也发生了根本性的变化。“软件=程序”显然不能涵盖软件的完整内容，除了程序之外，软件还应包括与之相关的文档和配置数据，用以保证这些程序的正确运行。

《IEEEStandardGlossaryofSoftwareEngineeringTerminology》给出了有关软件的定义：软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据。其中：①计算机程序是计算机设备可以接受的一系列指令和说明,为计算机执行提供所需的功能和性能；②数据是事实、概念或指令的结构化表示，能够被计算机设备接受、理解或处理；③文档是描述过程、方法及使用的图文材料。

然而，软件的真正含义却不是一个形式的定义所能体现的。从软件的内容来看，软件更像是一种嵌入式的数字化知识，其形成是一个通过交互对话和抽象理解而不断演化的

过程。

软件的应用领域十分广泛，呈现形式也是多种多样的，在某种程度上很难对软件的类型给出一个通用的界定。根据软件服务对象的范围不同，一般可以将软件划分为通用软件和定制软件两种类型。

1．通用软件(GenericSoftware)

通用软件是由软件开发组织开发，面向市场用户公开销售的独立运行系统，像操作系统、数据库系统、字处理软件、绘图软件包和项目管理工具等都属于这种类型。有时，通用软件也被称为套装软件(PackagedSoftware)

2．定制软件(CustomizedSoftware)

定制软件是受某个特定客户委托，由软件开发组织在合同的约束下开发的软件，像企业ERP系统、卫星控制系统和空中交通指挥系统等都属于这种类型。通用软件由开发组织根据市场调研自主提出产品需求，并以此进行设计和开发。其最大的优势在于，可以通过近乎零成本的复制来分摊最初投入的一次性开发成本，最终使原本昂贵的软件产品的价格降至众多用户可接受的程度，从而有效地提高市场份额和利润。但是，为了分摊最初的开发投入，通用软件必须面对足够大的市场空间，其功能设计也只能面向大规模用户普遍存在的共性需求。

对于不同的用户来说，除了共性需求之外还存在着个性化的需求，而这些个性化需求对于很多用户来说，恰恰是应用的关键所在。定制软件完全是订单开发，即按照单个客户的个性化要求，以软件项目的方式为其提交个性化的解决方案，从而更好地满足客户的需求。1.1.2软件的特性

计算机在使社会生产力得到迅速解放、使人类生活高度自动化和信息化的同时，却没有使计算机本身的软件生产得到类似的巨大进步。软件开发依然面临着过分依赖人工、软件难以重用、大量重复开发和生产率低下等问题，而导致这些问题的关键在于软件本身的特性。

(1)软件是复杂的。软件是人类思维和智能的一种延伸和在异体上的再现，远比任何以往人类的创造物都复杂得多。在大型软件系统中，无数种数据、状态和逻辑关系的组合以及人类思维的复杂性和不确定性导致的理解歧义和差异，使整个系统的复杂性急剧增加，也使软件的设计、实现和测试都变得相当困难。在著名的《没有银弹：软件工程中的根本和次要问题》一文中，FredBrooks认为正是软件固有的复杂性造成了软件开发的诸多问题。由于复杂性，人们难以全面理解问题，团队成员之间的沟通也变得非常困难，从而导致了产品缺陷、成本超支和进度拖延；由于复杂性，描述和理解软件系统所有可能的状态是极其困难的，影响了产品的可靠性；由于软件结构及其依赖关系的复杂性，软件的任何更改和扩充都有可能带来灾难性的后果，形成所谓的“雪崩效应”。

(2)软件是不可见的。一般情况下，人们可以通过几何抽象模型准确地描述有形的物体，例如建筑师可以用平面图描述建筑物的结构，硬件工程师可以用电路图描述计算机的系统结构，甚至化学家也可以用分子模型描述客观事物的微观结构。但是，软件是客观世界空间和计算机空间之间的一种逻辑实体，不具有物理的形体特征。人们一直试图用不同的图形技术来描述软件结构，即便是现在流行的面向对象技术，也仍然无法给出其准确、完整的描述。

(3)软件是不断变化的。软件是纯粹思维活动的产物，它不会像硬件一样发生磨损，而是需要随着应用、硬件、用户和社会等各种因素的变化不断地被修改和扩展。由于软件是人类思维和智能的一种延伸，因此当软件被真正应用之后，人们往往希望超越原有的应用边界进行软件功能的提升或扩展；另外，由于软件必须依附于硬件平台，因此需要随着硬件设备的更新和接口的不同而变化。

人们总是认为软件是很容易被修改的，通常忽视了修改带来的副作用，即引入新的错误，造成故障率的升高。图1.1显示了软件修改对其质量带来的冲击，不断的修改最终将导致软件的退化，从而结束其生命周期。图1.1软件的故障率曲线

(4)大多数软件仍然是定制的，而不是通过已有构件组装而成的。在软件的发展历程中，曾经涌现出许多开发技术和开发工具，当前流行的面向对象开发技术也日趋成熟，但是手工作坊式的软件开发方式仍占主导地位。随着数字化、网络化、智能化成为信息产业的发展趋势，软件复用和软件构件技术受到了广泛的关注，并成为一种社会化的开发方法，有助于软件工程化、工厂化生产的实现。1.1.3软件的发展

伴随着第一台计算机的问世，计算机程序就出现了。在以后几十年的发展过程中，人们逐步认识了软件的本质特性，发明了许多有意义的开发技术与开发工具，同时软件的规模也在不断扩大，其应用几乎渗透到各个领域。纵观整个软件的发展过程，大致可以将其分成以下4个重要的阶段：

(1)第一阶段：20世纪50～60年代。在计算机发展的早期阶段，计算机的主要应用是快速计算，出现了以Algol、Fortune等编程语言为标志的算法技术。在这一时期，程序设计被认为是一种任人发挥创造才能的活动，不存在什么系统化的方法和开发管理，程序的质量完全依赖于程序员个人的技巧。随着软件规模的扩大，20世纪60年代末期出现了“软件危机”。

(2)第二阶段：20世纪70年代。计算机应用开始涉及各种以非数值计算为特征的商业事务领域，交互技术、多用户操作系统、数据库系统等随之发展起来，出现了以Pascal、Cobol等编程语言和关系数据库管理系统为标志的结构化软件技术。在这一时期，软件的概念不再仅仅是程序，还包括开发、使用、维护程序需求的所有文档，软件的工作范围从只考虑程序的编写扩展到从定义、编码、测试到使用、维护等整个软件生命周期，瀑布模型被普遍使用。

(3)第三阶段：20世纪80年代。微处理器的出现与应用使计算机真正成为大众化的东西，而软件系统的规模、复杂性以及在关键领域的广泛应用，促进了软件开发过程的管理及工程化开发。在这一时期，软件工程开发环境CASE及其相应的集成工具大量涌现，软件开发技术中的度量问题受到重视，出现了著名的软件工作量估计COCOMO模型、软件过程改进模型CMM等。20世纪80年代后期，以Smalltalk、C++等为代表的面向对象技术重新崛起，传统的结构化技术受到了严峻的考验。

(4)第四阶段：20世纪90年代至今。Internet技术的迅速发展使软件系统从封闭走向开放，Web应用成为人们在Internet上最主要的应用模式，异构环境下分布式软件的开发成为一种主流需求，软件复用和构件技术成为技术热点，出现了以Sun公司的EJB/J2EE、Microsoft的COM+和OMG的CORBA/OMA为代表的3个分支。与此同时，需求工程、软件过程、软件体系结构等方面的研究也取得了有影响的成果。进入21世纪，Internet正在向智能网络时代发展，以网格计算(GridComputing)和网络服务(WebServices)为代表的分布式计算日趋成熟，从而实现了信息充分共享和服务无处不在的应用环境；高信度计算(TrustworthyComputing)普遍引起了人们的高度重视，从而为人们创造了一个安全、可靠、值得信赖的环境。 1.2软件危机

所谓软件危机，是指在计算机软件的开发和维护过程中遇到的一系列严重问题。软件危机在20世纪60年代末全面爆发，至今四十多年过去了，虽然软件开发的新工具和新方法层出不穷，但是软件危机依然没有消除。

(1)软件开发的成本和进度难以准确估计，延迟交付甚至取消项目的现象屡见不鲜。1995年，美国Standish咨询集团公布了题为“混沌”的研究报告，如图1.2所示的研究数据表明：在20世纪90年代初期，软件项目的平均成功率只有16.2%，在这里，成功的含义是指在计划的时间和预算内实现项目目标。仅1995年这一年间，有30%的项目在完工之前就被取消了，其余53.8%的项目由于各种原因在开发过程中遇到了这样或那样的问题，在开发成本、交付时间、产品功能或性能等方面没有实现预期的目标。近几年，有关统计资料显示：软件项目的平均成功率上升到26%，但仍有46%的项目超出预算和最后期限，另有28%的项目没有完成。图1.220世纪90年代初期软件项目的成功率

(2)软件存在着错误多、性能低、不可靠、不安全等质量问题。投入极大努力开发出来的软件常常出现人们无法预料的错误，甚至造成严重的后果。1996年6月，Ariane5火箭在发射37秒之后突然发生爆炸，其错误原因是浮点数转换成整数时发生溢出，系统对此也没有提供相关的异常处理程序。就这样，一个简单的疏漏造成了这枚耗资70亿美元的火箭发射失败。另一个例子是在1991年的海湾战争期间，美国对抗伊拉克的飞毛腿导弹曾发生过几次对抗失利，其中一枚导弹在沙特阿拉伯的多哈误击了28名美国士兵，而问题的症结在于导弹的软件存在一个累加计时的故障。一个很小的系统时钟错误积累起来就可能产生14个小时的误差，从而使跟踪系统失去准确度。今天，随着计算机网络应用的不断普及，计算机病毒的传播、拒绝服务的攻击、网络信息的安全等问题日益突出，软件的质量保证成为人们关注的焦点。

(3)软件成本在计算机系统的整个成本中所占比例越来越大。在过去的四十多年里，硬件性能至少跨越了8个重要的阶段，其成本也随着硬件技术的飞速发展而大幅度地下降。但令人遗憾的是，软件开发的能力却未能与硬件的发展保持同步。伴随着软件规模和复杂性的不断增长，软件成本在整个系统成本中所占的比例也持续上升，图1.3显示了软件成本的上升趋势。图1.3软件成本在系统总成本中所占比例

(4)软件维护极其困难，而且很难适应不断变化的用户需求和使用环境。在软件交付使用的初期，需要识别和纠正软件的错误，改正软件性能上的缺陷，避免实施中的错误使用。即使软件进入了正常的使用期，由于计算机新技术的出现和用户新需求的提出，也需要修改和改进软件。然而，软件维护依然是一件非常困难的工作，常常出现诸如错误难以修改或者修改又带来新的错误等现象，长期不断的修改也引起了软件的退化。

另外，由于软件开发本身的缺陷和软件维护技术的不成熟，软件维护需要消耗大量的工作量，从而造成维护成本相当昂贵。统计数据表明，软件维护费用占软件整个生存周期总费用的55%～70%。 1.3软件工程

1.3.1软件工程的概念

1968年10月，NATO科学委员会在德国的加尔密斯(Garmisch，Germany)开会讨论软件可靠性与软件危机的问题，FritzBauer首次提出了“软件工程”的概念，他认为：软件工程是为了经济地获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列好的工程化原则。

后来，人们曾经多次给出了有关软件工程的定义。这里引用《IEEEStandardGlossaryofSoftwareEngineeringTerminology》给出的一个更为全面的定义：①软件工程是将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即将工程化应用到软件上；②对①中所述方法的研究。

从上述定义中可以看出，软件工程包括以下两方面的内容：

(1)软件工程是工程概念在软件领域里的一个特定应用。与其他工程一样，软件工程是在环境不确定和资源受约束的条件下，采用系统性的、规范化的、可定量的方法进行有关原则的实施和应用，这些原则一般是以往经验的积累和提炼，经过时间检验并证明是正确的。因此，软件工程师需要选择和应用适当的理论、方法和工具，同时还要不断探索新的理论和方法，解决新的问题。

(2)软件工程涉及软件产品的所有环节。人们往往偏重于软件开发技术，忽视软件项目管理的重要性。统计数据表明，导致软件项目失败的主要原因几乎与技术和工具没有任何关系，更多的是由于不适当的管理造成的。

1.3.2软件工程的三要素

软件工程以关注软件质量为目标，由过程、方法和工具三个要素组成，如图1.4所示。图1.4软件工程的三要素软件工程的方法为软件开发提供了“如何做”的技术，通常包括某种语言或图形的模型表示方法、良好的设计实践以及质量保证标准等，其中使用最广泛的两种方法是传统的软件开发方法和当前流行的面向对象方法。

软件工程的过程是管理和控制产品质量的关键，它定义了技术方法的采用、工程产品(包括模型、文档、数据、报告、表格等)的产生、里程碑的建立、质量的保证和变更的管理，从而将人员、技术、组织与管理有机地结合在一起，实现在规定的时间和预算内开发高质量软件的目标。软件工具为软件工程方法提供了自动的或半自动的软件支撑环境，辅助软件开发任务的完成。现有的软件工具覆盖了需求分析、系统建模、代码生成、程序调试和软件测试等多个方面，形成了集成化的软件工程开发环境CASE(ComputerAidedSoftwareEngineering，计算机辅助软件工程)，提高了开发效率和软件质量，降低了开发成本。1.3.3软件质量的特性

软件工程的一个重要目标是“开发出高质量的软件”，那么如何看待“软件质量”的含义呢？简单地说，软件质量是软件产品与明确的和隐含的需求相一致的程度，它通常由一系列的质量特性来描述。例如，除了要求软件正确运行之外，人们可能还希望软件运行的响应时间符合要求、软件使用方便快捷、程序代码易于理解等，而“程序代码易于理解”往往是一种用户没有明确提出的需求，但却是影响软件质量的重要因素。

需要强调的是，软件质量并不取决于开发人员的观点，它通常与用户、维护人员等提出的要求密切相关。图1.5显示了不同的软件质量视角。图1.5不同的软件质量视角1.3.4软件工程方法

传统的软件开发方法主要是以功能分析和数据分析为基础的结构化方法，它以算法作为基本构造单元，强调自顶向下的功能分解，对功能和数据进行了一定程度的分离。结构化设计要求控制集中在高层模块中，不同模块之间的控制信息需要通过上、下调用来传递。随着软件系统的日益复杂，结构化开发方法暴露出严重的不足，主要体现在以下方面：

(1)由于采用功能与数据分离的软件设计结构，它与人类的现实世界环境有着根本性的差别，因此，人们对现实世界的认识与编程之间存在着理解上的鸿沟。

(2)由于强调自顶向下的功能分解，上下层模块存在着十分紧密的依赖关系，因此系统的变动和修改十分困难，而且这也在很大程度上限制了软件的重用。

(3)由于控制集中在高层模块中，模块之间的直接通信受到了限制，同时控制信息的传送效率低且易出错，因此，结构化开发方法无法适应需要突出控制特性的系统的要求。面向对象方法从现实世界中客观存在的事物(即对象)出发，尽可能地运用人类的自然思维方式来构造软件系统。它运用人类在日常的逻辑思维中经常采用的思想方法与原则，例如抽象、分类、继承、聚合、封装等，将其贯穿于整个分析和设计过程中，实现了客观世界到计算机系统的平滑过渡。当前，面向对象方法已成为软件工程学中的主流方法，其主要优势在于：

(1)按照人类的自然思维方式，面对客观世界建立软件系统模型，有利于对问题域和系统责任的理解，也有利于人员的交流。

(2)在整个开发过程中采用统一的概念和模型表示，填平了语言之间的鸿沟，使得开发活动之间能够平滑过渡。

(3)在面向对象的方法中，系统由对象构成，对象是一个包含属性和操作的独立单元，对象之间通过消息联系。这样的系统一旦出错，容易定位和修改，系统的可维护性好。

(4)对象所具有的封装性和信息隐蔽等特性，使其容易实现软件复用。对象类可以派生出新类，类可以产生实例对象，从而实现了对象类的数据结构和操作代码的软构件的复用。

图1.6显示了传统的软件工程方法与面向对象方法的比较。图1.6传统的软件工程方法与面向对象方法的比较 1.4软件工程知识体系(SWEBOK)

1.4.1SWEBOK项目介绍

1998年，SWECC发起研究和制定软件工程知识体系(SoftwareEngineeringBodyofKnowledge，SWEBOK)的项目。整个项目分为草人(Strawman)、石人(Stoneman)和铁人(Ironman)三个阶段。1998年9月完成“草人”版的SWEBOK指南，形成了软件工程知识体系的框架；2001年5月完成“石人”版SWEBOK指南，目前最新发布的是《SWEBOK指南V1．00(试用版)》。

开展SWEBOK项目的目的是为软件工程学科的边界提供一致确认的特征，为支持该学科的知识体系提供指导，其具体目标如下：

(1)描述软件工程学科的内容和特征；

(2)确定软件工程知识体系的各个专题；

(3)促进软件工程知识体系在世界范围内的共识；

(4)明确软件工程与其他相关学科(诸如计算机科学、项目管理、计算机工程、数学等)的关系，并设定软件工程学科的边界；

(5)为软件工程课程计划的开发和职业资格的认证提供依据。1.4.2SWEBOK的组成

SWEBOK将软件工程知识分解成若干知识域(KnowledgeAreas)及其组成部分，并将其组织成一个多级层次化的体系结构，以此确定软件工程学科的内容和边界。

在SWEBOK中，软件工程知识体系被划分为10个知识域，即软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法、软件质量，其组成结构如图1.7所示。图1.7软件工程知识体系的组成

1．软件需求(SoftwareRequirements)

需求是解决现实世界问题所必须展示的特性。SWEBOK将软件需求知识域进一步划分为6个知识子域，分别是需求工程过程、需求获取、需求分析、需求规格说明、需求验证和需求管理。

(1)需求工程过程说明需求工程与整个软件工程过程的吻合程度，包括过程模型、过程参与者、过程支持与管理、过程质量改进等内容；

(2)需求获取涉及从何处获取以及如何收集需求，包括需求来源和获取技术等内容；

(3)需求分析涉及分析需求的过程，如发现和解决需求之间的冲突、发现系统边界及其与周围环境的交互、将软件需求细化成系统需求等，包括需求分类、概念模型、体系结构设计以及需求分配和需求协商等内容；

(4)需求规格说明描述了需求文档的结构、质量和确认，包括系统需求定义文档和软件需求规格说明书两个部分；

(5)需求验证的目的是在提交需求分析结果之前找出问题，保证需求文档正确地定义了正确的系统，包括需求评审、开发原型、模型验证和验收测试等内容；

(6)需求管理是一项跨越整个软件生命周期的活动，主要涉及变更管理和需求维护，以保证需求说明准确地反映了待开发或已开发软件，它包括变更管理、需求属性和需求跟踪等内容。

2．软件设计(SoftwareDesign)

根据IEEE的定义，设计既是定义系统或构件的结构、组成、接口和其他特征的过程，也是该过程的结果。从过程来看，软件设计是软件生命周期中的一个活动，其任务是分析软件需求，从而生成有关系统内部结构与组成的描述，并以此作为软件构造的基础。从结果来看，软件设计必须描述系统的体系结构，即系统被分解和组织成各个构件的方式以及这些构件之间的接口，并且详细描述这些构件以方便后续的构造。

SWEBOK将软件设计知识域进一步划分为6个知识子域，分别是基本概念、关键问题、构成与体系结构、质量分析与评价、设计符号以及设计策略与方法。

(1)软件设计基本概念是理解软件设计的作用和范围的基础，包括软件设计的一般概念、软件设计的内容、设计过程和可采用的技术等；

(2)软件设计关键问题包括并发性、事件控制与处理、分布性、错误和异常处理、交互系统和持久性等问题；

(3)软件构成与体系结构主要包括体系结构风格、设计模式、程序及其框架的体系；

(4)软件设计质量分析与评价包括软件设计的质量属性、质量分析、评估工具与度量；

(5)软件设计符号包括结构描述和行为描述；

(6)软件设计策略与方法包括一般设计策略、面向功能的方法、面向对象的方法、以数据结构为中心的设计，以及诸如形式化与转换方法等其他方法。

3．软件构造(SoftwareConstruction)

软件构造是软件工程的基本活动，其任务是通过编码、验证和单元测试构造出有意义的、可工作的软件。进一步分解软件构造知识域的首要方法是认识对软件构造最具影响的4项原则，即降低复杂性、预知多样性、结构化验证和使用外部标准；其次是认识软件构造的3种方法，即语言方法、形式化方法和可视化方法。

(1)降低复杂性涉及软件构造过程中用于减少复杂性的3个主要技术，即消除复杂性、自动消除复杂性以及使复杂性局部化；

(2)预知多样性是预测软件在整个生命周期可能发生的变化，包括通用化、实验法和局部化3种技术；

(3)结构化验证是指以模块化方式构造软件，以便能够在单元测试和后续的测试活动中容易地发现错误和遗漏；

(4)由专用语言构造的软件在长期的使用过程中会遇到严重的障碍，因此，应当采用符合外部标准的构造语言(如一般编程语言)，或者提供足够详细的语法说明，以方便人们理解。

4．软件测试(SoftwareTesting)

软件测试是采用从无限执行域中适当挑选有限测试用例集，对照预期指定的行为，动态验证程序实际行为的过程，包括基本概念和定义、测试级别、测试技术、测试相关度量和测试过程管理。

(1)基本概念和定义包括测试术语、测试理论基础以及测试与其他活动的关系；

(2)测试级别包括单元测试、集成测试和系统测试3个阶段，而从测试的目标划分，还可以分为验收测试、安装测试、a测试与b测试、功能测试、衰退测试、性能测试、压力测试、回归测试、恢复测试、配置测试和可用性测试等；

(3)测试技术包括测试用例选取标准、测试技术以及如何选择和组合这些技术；

(4)测试相关度量包括评价所测试的程序和评价所执行的测试；

(5)测试过程管理涉及与测试管理相关的问题和测试活动。

5．软件维护(SoftwareMaintenance)

软件一旦交付使用，就进入维护阶段，其任务包括纠正软件运行时出现的错误、改进软件系统以便适应环境的变化和满足用户新的需求等。软件维护包括基本概念、维护过程、关键问题和维护技术这4个知识子域。

(1)基本概念涉及软件维护的定义、类型和问题；

(2)维护过程描述基于IEEE1219和ISO/IEC14764标准的过程模型以及有关活动；

(3)关键问题涉及软件维护过程中的技术、管理、成本、预算和度量等方面的问题；

(4)维护技术包括程序理解、再工程、逆向工程和影响分析等。

6．软件配置管理(SoftwareConfigurationManagement)

软件配置管理在明确的时间点上确定系统的配置，从而保证在整个系统生命周期中系统地控制配置的变化并维护配置的完整性和可跟踪性。软件配置管理包括配置过程管理、配置识别、配置控制、配置状态报告、配置审计以及软件发布管理与交付6个知识子域。

(1)配置过程管理包括配置组织环境、配置约束与指南、配置计划与监督等；

(2)配置识别就是确定要控制的配置项，为配置项及其版本建立标识模式，并建立用于采集和管理这些配置项的工具和技术；

(3)配置控制对软件生命周期中的变化进行管理，包括申请、评估和批准软件变更、实施变更以及转移和放弃变更等3个方面；

(4)配置状态报告用于记录和报告软件配置管理所需的信息；

(5)配置审计由软件功能配置审计、软件物理配置审计和软件基线审计等组成；

(6)软件发布管理与交付包括软件建立和软件发布管理。

7．软件工程管理(SoftwareEngineeringManagement)

软件工程管理包括组织管理、过程/项目管理、软件工程度量这3个知识子域。

(1)组织管理由策略管理、个人管理、沟通管理、协调管理和采购管理等组成；

(2)过程/项目管理包括项目启动和范围定义、计划的制定、规定的建立、项目评审和评价、项目收尾等；

(3)软件工程度量涉及软件度量的基本原理，包括度量目标、度量选择、软件度量及其发展、数据收集和软件测量模型。

8．软件工程过程(SoftwareEngineeringProcess)

软件工程过程涉及软件工程过程本身的定义、实施、度量、管理、变更和改进，可进一步分为软件过程概念、过程基础设施、过程度量、过程定义、定性分析以及过程实施与变更这6个知识子域。

(1)软件过程概念包括软件工程过程的活动和术语；

(2)过程基础设施包括建立软件工程过程小组和经验工厂，从而为过程分析、实施和改进提供有力的支持；

(3)过程度量描述软件工程过程的度量方法和范例；

(4)过程定义描述过程定义类型、生命周期框架模型和软件过程模型等有关知识，并说明这些定义的符号、方法与自动化；

(5)定性分析主要包括过程定义评审和根本原因分析；

(6)过程实施与变更包括过程实施与变更的范例、指南和效果评价。

9．软件工程工具与方法(SoftwareEngineeringToolsandMethods)

软件工程工具与方法包括软件开发工具和开发方法。其中：软件开发工具是支持软件开发过程的计算机工具；软件开发方法是指软件开发活动的组织方法，目的是系统化地组织开发活动以实现成功最大化。

(1)软件开发工具包括需求分析、设计、构造、测试、维护、过程、质量、配置、管理、基础设施和其他活动所需的各种工具；

(2)软件开发方法包括启发式方法、形式化方法、原型法和其他混合方法等。

10．软件质量(SoftwareQuality)

软件质量是贯穿于整个软件工程活动的关注焦点，包括软件质量概念、软件质量保证(SoftwareQualityAssurance，SQA)与验证和确认(VerificationandValidation，V＆V)的目的与计划、SQA与V&V的活动与技术适用于SQA与V&V的度量。

(1)软件质量概念包括质量值的度量、ISO9126的质量描述、可靠性、特殊类型系统与质量要求；

(2) SQA与V&V的目的与计划包括通用计划活动、SQA计划和V&V计划；

(3) SQA与V&V的活动与技术用于描述SQA与V&V的活动和计划，包括静态技术、动态技术以及其他的SQA与V＆V测试技术；

(4)适用于SQA与V&V的度量描述用于SQA与V&V的度量技术，包括度量原理、测量、度量分析技术、缺陷特征以及有关数据使用等。1.4.3软件工程与其他相关学科的关系

软件工程是一门交叉性的工程学科，如图1.8所示，它将计算机科学、数学、工程科学和管理科学等基本原理应用于软件开发的工程实践中，并借鉴传统工程的原则和方法，以系统的、可控的、有效的方式产生高质量的软件。图1.8软件工程与其他相关学科的关系软件工程以计算机科学和数学为基础，将这些学科的基本原理应用于构造软件的模型与算法，力求提出更系统化和更形式化的软件开发方法，并采用适当的方法验证即将开发的软件。

然而，正确的软件开发实践不仅仅需要计算学科的基本原理，更重要的是将工程化的原则和方法应用于软件的分析与评价、规格说明、设计、实现和演化等过程。软件工程运用工程科学的基本原理，结合特定领域的基础知识和相关的专业知识，通过评估成本与确定权衡，提出合理的问题解决方案，在软件开发实践的基础上总结制定标准与规范，重用设计和设计制品。事实证明，成功的软件开发往往离不开规范化的开发管理。软件工程将管理科学应用于软件开发的计划、资源、质量、成本等管理，协调和控制整个过程与项目的进展，组织和建设开发团队，实施风险分析和变更管理，最终实现软件开发的目标。

需要强调的是，由于软件自身的特殊性，软件工程与传统工程存在着明显的区别，它更强调抽象、建模、信息组织与表示以及变更管理，另外还包括软件开发过程的质量控制活动，而且持续的演变(即“维护”)也尤为重要。 1.5软件过程

1.5.1软件过程的概念

1．任务思维与过程思维

在软件发展的前期阶段，人们强调软件开发的结果而忽略软件开发的过程，所采用的开发模式如图1.9所示。在这种任务思维的模式中，整个软件开发过程仿佛是一个混沌的“黑盒子”，软件需求必须在开发初期完全确定下来，用户的交互只能发生在确定需求之时和产品发布之后，这种要求显然不符合软件开发的实际情况。软件更像是一种嵌入式的数字化知识，其形成是一个通过交互对话和抽象理解而不断演化的过程，尤其是在软件系统规模日益扩大的情况下，软件开发必须在适应需求不断变化的过程中迭代式地演进。图1.9软件开发的任务思维模式

WattsHumphrey首先将过程管理的原则和思想引入到软件开发之中，他认为：为了解决软件的问题，首要的步骤是将整个软件开发任务看做是一个可控的、可度量的和可改进的过程。在图1.10所示的过程思维模式中，整个软件开发过程被划分成若干可管理的开发阶段，人们可以“听见”过程的声音，并让用户的声音与过程的声音相吻合。图1.10软件开发的过程思维模式

2．软件过程的定义

在软件工程的三要素中，软件过程将人员、技术、组织与管理有机地结合在一起，下面给出的定义说明了软件过程的“黏合”性质：

软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。

图1.10显示了软件过程的基本组件与运行机制。其中软件过程的基本元素由一系列软件工程活动和活动之间的关系组成，通过一系列顺序和步骤执行这些活动，可以产生诸如代码、文档和数据等各种过程制品，最终取得预期的过程结果。另外，软件过程需要参与活动的人员和活动工具等过程资源的支持，并通过反馈和度量过程的结果来实现过程的可持续改进。

3．软件过程的基本活动

由于软件的复杂性和多样性，软件开发并没有一个理想的过程，不同的开发组织或者不同的软件类型往往存在着完全不同的软件开发过程。尽管如此，一般的软件过程都包括问题提出、软件需求规格说明、软件设计、软件实现、软件确认和软件演化等基本活动。

1)问题提出

软件产品往往起源于人们的设想或者现实问题，但是这些设想或问题的描述可能是模糊的、不合理的或不可能实现的。因此，人们通过开展技术探索和市场调查等活动，研究系统的可行性和可能的解决方案，确定待开发系统的总体目标和范围。在可行性分析过程中，人们需要研究现有的软件和硬件技术是否能够实现待开发系统的要求、实际开发是否亏本等问题，从技术、市场、效益等方面确定该系统是否值得开发。

2)软件需求规格说明

在完成可行性研究和软件计划之后，系统分析人员开始着手分析、整理和提炼所收集到的客户需求，建立完整的需求分析模型，编写软件需求规格说明。最后，通过评审需求规格说明，确保对用户需求达到共同的理解与认识。

软件需求规格说明是将需求分析活动中获得的信息以文档的形式确定下来，它明确地描述了软件的功能，列出软件必须满足的所有约束条件，并定义软件的输入和输出接口。

3)软件设计

软件设计的目标是决定软件怎么做，设计人员根据软件需求规格说明文档，确定软件的体系结构，再进一步设计每个系统部件的实现算法、数据结构和接口等，编写软件设计说明书，并组织进行设计评审。

软件设计说明书是将体系结构设计和详细设计的结果以文档的形式描述出来。其中，体系结构设计确定组成该系统的所有子系统及其相互之间的关系，详细设计确定每一个子系统的接口、数据结构和实现算法。

4)软件实现

软件实现是将所设计的各个子系统编写成计算机可接受的程序代码。与实现相关的文档就是源程序以及合适的注释。

5)软件确认

软件确认是检查和验证所开发的系统是否符合客户的期望，它涉及从用户需求定义到软件实现的每一个阶段的审查和评审，以及程序实现之后的软件测试。软件测试首先测试系统的各个组件，然后将各个组件集成在一起进行测试，最后使用客户的数据测试整个产品的功能和性能是否满足要求。

在软件确认的过程中，一旦发现软件有缺陷，开发人员就需要回到前面的开发阶段进行修改，然后再进行修改后的确认，这是一个不断反复的过程。

6)软件演化

人们一直习惯于将软件过程划分为软件开发和软件维护两部分。软件开发覆盖从概念的提出到形成一个可运行系统的整个过程；软件维护则是系统投入使用后所产生的修改。于是，人们总是将软件开发视为一项富有创造性的工作，而认为软件维护工作缺少挑战性和吸引力。

今天，大部分的软件都是在已有组件或原有系统的基础上开发出来的，开发与维护的界限越来越不清晰，因此整个软件过程被看做是一个不断演化的过程。

4．软件过程的制品

在软件过程的不同阶段，有可能产生各种不同的软件制品，诸如需求规格说明、设计说明、源程序与构件、测试用例、用户手册以及各种开发管理文档等。图1.11列出了软件过程的一些基本活动以及所产生的主要过程制品。图1.11软件过程的基本活动及其制品软件过程制品涉及软件需求、软件设计、软件实现、软件测试和软件实施等活动产生的结果，这些制品通常在不同的开发活动之间进行转移和演进，其主要内容包括：

(1)软件需求制品：构想文档描述了所开发系统的整个构想，形成了投资方和开发组织对项目范围的共同认定；需求模型涉及系统原型和描述系统需求的各种模型，诸如用例模型和领域模型等；软件需求规格说明清楚地描述了所开发软件的功能、性能和接口等要求。

(2)软件设计制品：软件体系结构文档描述系统的基本构件及其之间的关系；设计模型反映各个构件的内部结构和行为信息。

(3)软件实现制品：源代码表示构件的具体实现；目标代码是源代码编译产生的文件；可执行构件包括定制的组件、商业组件或遗留组件等。

(4)软件测试制品：测试规程描述测试运行环境、测试方法和测试步骤；测试用例描述测试的输入数据和预期的输出结果等；软件测试报告记录所检测的软件缺陷，并分析这些缺陷的严重程度。

(5)软件实施制品：相关的运行时文件包括可执行软件、安装脚本以及使用软件所需的特定目标数据等；用户手册是用户使用已交付的软件所需要的参考文档。

(6)开发管理制品：涉及与开发过程的计划和执行有关的文档，这些文档通常由项目相关人员采用变更分析和正式评审的方式进行评价，其主要内容包括：

●工作分解结构实现对项目活动的分解，为项目计划和财务分析等奠定基础；

●业务案例提供必要的信息来确定项目是否值得投资；

●发布规格说明描述软件发布版本的范围、计划和基线目标；

●软件开发计划涉及整个软件开发的资源、成本、进度、质量等的具体规划；

●发布版本说明记录每次发布的结果；●状态评估反映项目进展的实际情况，包括风险评估、质量指标和管理指标等；

●软件变更申请描述软件基线的变更内容和结果；

●实施文档涉及项目收尾、市场计划、用户培训和系统演示等内容；

●环境包括系统的硬件和软件配置、软件开发工具以及相应的间接培训等。1.5.2软件过程模型

软件过程模型描述软件过程的整体框架，它是软件过程的一种抽象表示。下面介绍一些常见的软件过程模型，这些模型以不同的方式定义了软件过程活动的流程框架，并在实际应用中体现出各自的特点。

1．瀑布模型

在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用最广泛的过程模型。图1.12所示为传统的瀑布模型。图1.12传统的瀑布模型按照传统的瀑布模型来开发软件，有如下几个特点：

(1)阶段间具有顺序性和依赖性。阶段间具有顺序性和依赖性特点有两重含义：①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。可是，万一在生命周期某一阶段发现了问题，很可能需要追溯到在它之前的一些阶段，必要时还要修改前面已经完成的文档。然而，在生命周期后期改正早期阶段造成的问题，需要付出很高的代价，这就好像水已经从瀑布顶部流泻到底部，再想使它返回到高处需要付出很大能量一样。

(2)推迟实现的观点。缺乏软件工程实践经验的软件开发人员，接到软件开发任务以后常常急于求成，总想尽早开始编写程序。但是，实践表明，对于规模较大的软件项目来说，往往编码开始得越早，最终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性的后果。

瀑布模型在编码之前设置了系统分析与系统设计这两个阶段，用于分析与设计阶段的基本任务规定。在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。

清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。

(3)质量保证的观点。软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持以下两个重要做法：

①每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。

②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。事实上，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障或改正错误所需付出的代价也越高。因此，及时审查是保证软件质量、降低软件成本的重要措施。传统的瀑布模型过于理想化，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实现过程中显现出来；在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。因此，实际的瀑布模型是带“反馈环”的，如图1.13所示(图中实线箭头表示开发过程，虚线箭头表示维护过程)。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。图1.13瀑布模型的开发过程与维护过程瀑布模型有许多优点：可强迫开发人员采用规范的方法(例如结构化技术)；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的，遵守瀑布模型的文档约束，将使软件维护变得比较容易一些。由于绝大部分软件预算都花费在软件维护上，因此，使软件变得比较容易维护就能显著降低软件预算。可以说，瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。但是，“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。仅仅通过写在纸上的静态的规格说明，很难全面、正确地认识动态的软件产品。而且事实证明，一旦一个用户开始使用一个软件，在他的头脑中关于该软件应该做什么的想法就会或多或少地发生变化，这就使得最初提出的需求变得不完全适用了。其实，要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的。总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。而下面将要介绍快速原型模型，有助于保证用户的真实需要得到满足。

2．快速原型模型

快速原型模型又称原型模型，它是增量模型的另一种形式，是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作的。快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成功能全集的一个子集。

图1.14描述了快速原型模型的应用过程，快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用，反复迭代这一过程，软件随之演进。一旦用户认为这个原型系统确实能完成他们的业务，开发人员便可据此写出规格说明文档，根据这份文档开发出的软件则可更准确地满足用户的真实需求。图1.14快速原型模型应用过程快速原型模型是不带反馈环的，软件产品的开发基本上是以线性顺序进行的，这一点正是该过程模型的主要优点。快速原型模型能做到线性顺序开发的主要原因如下：

①原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户的需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。

②开发人员通过建立原型系统已经学到了许多东西(至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”)，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成维护工作的不同分类，可能需要返回到需求分析、规格说明、设计或编码等不同阶段。

快速原型的本质是“快速”，开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃，因此，原型系统的内部结构并不重要，重要的是，必须迅速地构建原型，然后根据用户意见迅速地修改原型。UNIXShell和超文本都是广泛使用的快速原型语言，近年来，这一技术趋势发展为广泛地使用第四代语言(4GL)来构建快速原型。当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分用到最终的软件产品中。例如，用户界面通常是快速原型的一个关键部分，当使用屏幕生成程序和报表生成程序自动生成用户界面时，实际上可以把这样得到的用户界面用在最终的软件产品中。

3．增量模型

增量模型也称为渐增模型，如图1.15所示。使用增量模型开发软件时，是把软件产品作为一系列的增量构件来设计、编码、集成和测试的。每个构件都由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。例如，使用增量模型开发字处理软件时，第一个增量构件可能提供基本的文件管理、编辑和文档生成功能；第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时唯一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。图1.15增量模型采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品，每次用户都得到一个满足部分需求的可运行的产品，直到最后一次得到满足全部需求的完整产品。从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成一些有用的工作的产品，是增量模型的一个优点。增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。从长远观点看，具有开放结构的软件拥有真正的优势，这样的软件的可维护性明显好于封闭结构的软件。因此，尽管采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。如果一个设计非常灵活而且足够开放，足以支持增量模型，那么，这样的设计将允许在不破坏产品的情况下进行维护。事实上，使用增量模型时开发软件和扩充软件功能(完善性维护)并没有本质区别，都是向现有产品中加入新构件的过程。

从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看做一个整体，另一方面又要求开发人员把软件看做构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。图1.15所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计的工作，由于在开始构建第一个构件之前已经有了总体设计，因此风险较小。图1.16描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档，完成后，规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构件……用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。图1.16风险更大的增量模型

4．螺旋模型

软件开发几乎总要冒一定风险，例如，产品交付给用户之后用户可能不满意，到了预定的交付日期软件可能还未开发出来，实际的开发成本可能超过预算，产品完成前一些关键的开发人员可能“跳槽”了，产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件等等。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量，因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。构建原型是一种能使某些类型的风险降至最低的方法。为了降低交付给用户的产品不能满足用户需要的风险，一种行之有效的方法就是在需求分析阶段快速地构建一个原型，在后续的阶段中也可以通过构造适当的原型来降低某些技术风险。当然，原型并不能“包治百病”，对于某些类型的风险(例如聘请不到需要的专业人员或关键的技术人员在项目完成前“跳槽”)，原型方法是无能为力的。螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型，如图1.17所示。图1.17螺旋模型完整的螺旋模型如图1.18所示，图中带箭头的虚线的长度代表当前累计的开发费用，螺旋线旋过的角度值代表开发进度。螺旋线的每一周对应于一个开发阶段。每个阶段开始时(左上象限)的任务是，确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件。接下来的任务是，从风险角度分析上一步的工作结果，努力排除各种潜在的风险，通常用建造原型的方法来排除风险。如果风险不能排除，则停止开发工作或大幅度地削减项目规模。如果成功地排除了所有风险，则启动下一个开发步骤(右下象限)，这个步骤的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工作成果并计划下一个阶段的工作。图1.18完整的螺旋模型螺旋模型有许多优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试(浪费资金)或测试不足(产品故障多)所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。螺旋模型的主要优势在于，它是风险驱动的，但是，这也可能是它的一个弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常。

5．喷泉模型

迭代是软件开发过程中普遍存在的一种内在属性。经验表明：软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代，在面向对象范型中比在结构化范型中更常见。图1.19所示的喷泉模型是典型的面向对象生命周期模型。图1.19喷泉模型“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。图1.19中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在交叠；而面向对象方法在概念和表示方法上的一致性，保证了在各项开发活动之间的无缝过渡。事实上，用面向对象方法开发软件时，在分析、设计和编码等项开发活动之间并不存在明显的边界。图中在一个阶段内的向下箭头代表该阶段内的迭代(或求精)，较小的圆圈代表维护，圆圈较小象征着采用了面向对象范型之后维护时间缩

短了。

为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程(例如，快速原型模型或图1.19中的中心垂线)作为总目标。但是，同时也应该记住，面向对象范型本身要求经常对开发活动进行迭代或求精。

1.6软件项目管理基础

随着计算机应用的飞速发展，软件开发规模和开发队伍日益庞大，软件开发不再像过去那样是由个别开发人员即可解决的事情，因此，有必要将软件项目管理引入到软件开发活动中，从而有效地保证软件项目能够按照预定的成本、进度、质量要求顺利完成。事实证明，软件项目管理有利于将软件开发人员的个人开发能力转化成企业的开发能力，并使企业的软件开发能力不断提高和成熟。

从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。目前，软件仍然是一种新兴的特殊工程领域，它远远没有其他工程领域那么规范，其开发过程缺乏成熟的理论和统一的标准，因此，软件项目管理具有相当的特殊性和复杂性，它对软件开发具有决定性的意义。

1．软件项目的特征

与其他工程项目相比，软件项目具有以下显著特征：

(1)软件产品的不可见性。软件开发不同于其他产品的制造，其整个过程都是设计过程，其开发过程和产品既看不见又摸不着。因此，软件项目具有特别的复杂性和抽象性。

(2)项目的高度不确定性。软件的不可见性给项目的估算和计划带来了极大的不确定性，项目管理者也难以预见问题的出现，容易造成项目的预定计划与实际情况存在较大的偏差。另外，计算机技术的飞速发展使得软件项目的技术更新非常快，过去积累的经验教训难以在新的项目中发挥作用。

(3)软件过程的多变化性。在软件开发过程中，需求分析、架构设计、详细设计、软件测试和交付等各个工作环节通常是一个典型的迭代和增量发展的动态变化过程。因此，软件项目的开发过程具有复杂性、多样性和不稳定性的特点，特别是客户需求的不确定性和多变性往往给软件开发带来极大的困难和风险。

(4)软件人员的高流动性。在软件开发过程中，不需要使用大量的物质资源，人力资源往往是关键性的因素。由于软件产业发展迅速，人才需求旺盛，因此开发人员，尤其是项目的核心技术人才流动性高，这也给项目管理带来了很大的风险。

总而言之，“复杂”和“变化”给软件项目的管理带来了相当大的难度，降低复杂性和控制变化成为软件项目管理面临的关键问题。

2．软件项目管理的“4P”

有效的软件项目管理集中于4个方面：人员(People)、产品(Product)、过程(Process)和项目(Project)，简称为项目管理的“4P”，其关系如图1.20所示。图1.20项目管理中的“4P”

1)人员(People)

软件开发是人类从事的对智力创造要求较高的一项工作，故相对于工具或技术来说，软件人员的素质和组织管理是保证项目成功的更为重要的因素。一般来说，大型软件项目需要整个团队的努力和协作，其开发人员的选择、组织、分工与管理是一项十分重要而又复杂的工作，它直接影响到整个项目的成败。

在微软公司的成功经验中，最值得研究的就是如何得到优秀的员工，以及如何让员工尽量发挥自己的能力。因此，软件开发的管理应处处体现“以人为本”的思想，注重发现和培养有创造力的、技术水平高的软件人员，并使这些人员保持高昂的斗志和不断的创新。

2)产品(Product)

软件项目的目标是在规定的时间和预算内开发出满足客户需求的软件产品。但是，以往的统计资料表明，软件产品的问题主要发生在软件需求阶段，其根源在于软件需求的不确定和需求规格说明的不准确。

在软件开发的整个过程中，软件需求为准确的项目估算、有效的风险评估、适当的任务划分和合理的进度安排等奠定了可靠的基础，是软件项目成功的一个关键因素。因此，软件项目管理必须有效地解决需求分析和需求变更的问题，使开发人员能够获取用户的真正需求，准确完整地描述需求分析结果，并能有效地控制需求的变化。

3)过程(Process)

软件产品从概念的提出到最终的形成需要经历一个复杂的过程。软件过程将软件开发和维护所用到的技术、方法、活动和工具有机地结合起来，确保项目的成功经验和最佳实践得以有效的总结和重用，并且在以后的项目实践中不断地完善和优化。

在软件过程管理中，人们需要定义整个软件开发的活动、所采用的技术方法、各个阶段的里程碑、各种工程制品等，这