企业管理软件制造是个复杂的过程

在计算机发展的初期，由于硬件的成本占据了整个计算机系统成本的绝大部分，因此，计算机系统就采用了面向硬件的管理模式来进行构建。为了能够有效地控制硬件的成本，人们建立了一系列与硬件有关的规范技术和控制标准，并基于此应用了相应的方法和工具，这就是所谓的硬件工程。在那时，计算机程序的设计被看作是一门“艺术”，几乎没有规范化的方法。软件开发主要体现为个人英雄主义，程序员往往从试验和错误中积累经验，这使得软件开发被蒙上了一层神秘的面纱。
随着软件产品在计算机系统成本中所占的比例越来越大，人们对软件系统的需求越来越复杂，软件的开发人员和管理者就不断地遇到一系列棘手的问题。为了解决这些问题，软件过程作为软件工程中的一个重要方面越来越受到人们的关注。

2．1．1软件制造是个复杂的过程
2．1绪论
20世纪后半叶以来，软件系统在世界经济中扮演的角色发生了巨大的变化，软件产业已经不再是一个无足轻重的产业了。现在，计算机软件在经济环境中担任着双重角色，一方面它是～种产品，另一方面又是开发和运行其他产品的载体。作为一种产品，它表达了计算机硬件所体现出来的汁算潜能。而作为开发运行其他产品的载体，软件系统不但是计算机进行控制和信息通信的基础，而且也是开发和创建其他应用程序的基础。
随着科学技术的发展、计算机内存和硬盘容量的快速增加、大量输入输出设备的多种选择，以及计算机体系结构的不断地变化，这些都促进了更为成熟和更为复杂的计算机系统的出现。计算机硬件的性能获得了突飞猛进的提高，人们一直期待着软件能够像计算机硬件一样获得相应的发展。但是，往往事与愿违，一系列与软件相关的问题在计算机系统发展的整个过程中一直存在，而且还有继续恶化的趋势。所有这些都足以看出软件的开发和制造是一个极其复杂的过程。
软件制造的复杂性主要是由于软件的以下特征决定的。
(1)软件是计算机系统中的一种逻辑部件，具有抽象性。
软件与其他工业产品之间存在明显的差异，它可以被记录在纸、内存、光盘或磁盘等存储设备上，但却无法看到其自身的形态，必须通过观察、分析、判断和思考等方式才能了解软件产品的功能和性能。
(2)软件是由设计或工程化的方法开发出来的，与传统工业的生产制造存在很大差别。虽然表面上软件的开发和硬件的制造有一些相似之处，但实际上两者具有本质上的不同。例如：
①计算机软硬件都可以通过良好的设计来获得较高的质量，但对于硬件来说，同一批量的重复制造可能会引入一些质量问题，而这种情况对于软件而言几乎不存在。当软件开发完之后，其重复制造就是简单的拷贝而已，不会引入其他问题。
②计算机软硬件都依赖于人的劳动，但在开发或制造过程中参与的人员和完成的工作之间的关系存在很多不同之处。
③计算机软硬件都是在建造某一产品，但是它们所采用的过程和方法却完全不同。
尽管在20世纪80年代中期以来，人们提出了“软件工厂”的概念并把它引入到软件的开发过程中，但“软件工厂”并没有认为软件的开发和硬件的制造是等价的，而只是希望通过一些自动化的工具来提高软件开发的质量和效率。
(3)软件系统不会“磨损”。
就像其他的工业产品一样，计算机硬件会随着时问和环境(例如所使用的时间、周围的灰尘、工作台的振动、系统的滥用或温度的急剧变化等)的改变而发生故障和磨损。
软件有其自身的特征，它不会受这些因素的影响。软件系统中隐藏的错误往往会导致程序在运行初期具有较高的故障率。但如果这些错误能够在没有引入其他错误的情况下得到改正，那么软件的质量就会趋于平稳。
虽然如此，但是在软件的修改和维护等过程中，经常会引入新的错误，使得软件的故障率提高，导致软件的质量出现不稳定。当维护或修改的成本变得难以接受时，软件生命周期就相应终止。同时，当一个硬件发生磨损或故障时，可用另一个备用硬件来进行替换，但软件系统一般没有替代品。因此，对软件进行维护要比对硬件进行维护困难得多。
(4)大多数软件产品是定制的，而不是通过对已有构件组装完成的。
从上可知，软件没有备用的零件可以替换和组装，也几乎没有满足要求的软件构件可供选择。虽然关于“软件复用”已有大量论著，但是要实现真正意义上的软件复用，还有很长的一段路要走。
此外，软件需求的不确定性和软件开发过程中所涉及的一系列的社会和经济问题也会导致软件制造的复杂性。
实际上，软件工程是一种层次化的技术，它不仅包括工具和方法，也包括过程方面的内容，如图2-1所示。软件工程的基层是过程层，软件过程可以看成是软件开发的一种规范化流程，并定义了软件开发中采用的方法和技术，一种好的软件过程可以促进软件开发的顺利进行，并能够尽量保证软件质量的提高。软件过程是将技术层结合在一起的凝聚力，使得软件能够被合理地、及时地开发出来。方法层提供了开发软件在技术上需要“如何做”，涵盖了一系列的任务：需求分析、设计、编程、测试和维护，确定给出实现这些任务的技术方法，也包含建模活动和其他描述技术。工具层对过程和方法提供了自动或半自动的支持，当这些工具被集成起来使得一个工具的信息可被另一个工具使用时，一个支持软件开发的系统就建立了。

2．1．2软件过程分类
过去，人们并未注意到软件过程的重要性，而是把视野主要集中于软件开发上(这属于软件开发过程，是软件过程之一)。实际上，所有的软件开发人员都要同软件过程打交道。最早的软件过程瀑布式模型就是一种最粗略的软件过程模型，它提供了一种软件开发的基本过程框架。但这个模型过于粗略、笼统，未能体现出不同类型软件项目及项目个体之间软件过程的差异。通过对软件过程的深入研究，认识到不同的软件项目应根据其自身的特点，选择不同种类的过程框架，通过剪裁过程定义所需的活动和任务，建立适合于自身特点的过程模型。软件过程中的各个过程实际上就是对该过程模型的动态执行过程。改善软件过程就是改进软件生产的工艺流程，从而提高软件的质量。
《ISO／IEC12207信息技术一软件生存周期过程》将软件过程分成三类：主要过程类、支持过程类和组织过程类。
1．主要过程类
供各主要当事方(如需方、供方、开发者、运行者和维护者)在参与或完成软件产品开发、运行或维护时使用。
1)获取过程
需方获取系统、软件产品或软件服务的活动。包括：定义、分析需求或委托供方进行需求分析后认可，招标准备，合同准备及验收。
2)供应过程
供方向需方提供系统、软件产品或软件服务的活动。包括：评审需求，准备投标，签订合同，制订并实施项目计划，开展评审及评价，交付产品。
3)开发过程
开发者定义并开发软件产品的活动。包括：系统需求分析，系统结构设计，软件需求分析，软件结构设计，软件详细设计，软件程序设计与测试，软件集成，软件合格测试，系统集成，系统合格测试，软件安装及软件验收支持。
4)运行过程
运行者在规定的环境中为其用户提供计算机系统服务的活动。包括：制订并实施运行计划，运行测试，系统运行，对用户提供帮助和咨询。
5)维护过程
维护者提供维护软件产品服务的活动。包括：问题和变更分析，实施变更，维护评审和维护验收，软件移植和软件退役。

2．支持过程类
支持过程类中的过程对基本过程类中的过程提供支持。被支持的过程根据需要采用一些支持性过程，并与该过程结合，帮助软件项目获得成功及良好的产品质量。
1)文档编制过程
记录生存期过程中产生的信息所需的活动。包括：设计文档编制标准，确认文档输入数据的来源和适宜性，文档的评审和编辑，文档发布前的标准，文档的生产与提交、储存和控制，文档的维护。
2)配置管理过程
实施配置管理的活动。包括：配置标识，配置控制，记录配置状态，评价配置，发行管理与交互。
3)质量保证过程
为确保软件产品和软件过程符合规定的需求并能坚持既定计划所需的活动。包括：软件产品的质量保证，软件过程的质量保证以及按IS09001标准实施的质量体系保证。
4)验证过程
为确保一个活动的产品满足前一活动对它的要求和条件的活动。包括：合同、过程、需求、设计、程序没计、集成和文档等的验证。
5)确认过程
为确保最终产品满足预期使用要求的活动。包括：为分析测试结果实施特定的测试，确认软件产品的用途，测试软件产品的适用性。
6)联合评审过程
评审方与被评审方共同对某一活动的状态和产品进行评审的活动。包括：实施项目管理评审(项目计划、进度、标准、指南等的评价)，技术评审(评价软件产品的完整性、符合标准等)。
7)审核过程
审核项目是否按要求、计划、合同完成的活动。包括：检验项目是否符合需求、计划、合同以及规约和标准。
8)问题解决过程
分析和解决在开发、运行、维护或其他过程中出现的问题的活动。包括：分析和解决开发、运行、维护或其他过程中出现的问题，提出响应对策，使问题得到解决。

3．组织过程类
此类过程用来建立和实施一种基础结构，并且不断改进该基础结构的过程。基础结构由一些相关的过程和人员组成。
1)管理过程
规定软件生存周期过程中的基本管理活动，含项目管理。包括：制订计划，监控计划的实施，评价计划实施，涉及有关过程的产品管理、项目管理和任务管理。
2)基础设施过程
建立软件生存周期过程的基础结构所需的基本活动。包括：为其他过程所需的硬件、软件、工具、技术、标准，以及开发、运行或维护所用的各种基础设施的建立和维护服务。
3)改进过程
一个组织为了建立、测量、控制和改进其过程需完成的基本活动。这个组织包括需方、供方、开发者、操作者、维护者或另一个过程的管理者。包括：对整个软件过程进行评估、度量、控制和改进。
4)培训过程
为培训合格人员所进行的活动。包括：制订培训计划，编写培训资料，培训计划的实施。
软件并行开发把软件过程放在中心地位来看待，关注的核心是开发过程，并涉及相关的其他过程。软件并行开发中对各种并行成分的划分、建模、执行都建立在软件过程模型的基础之上。

2．2软件开发的主要活动
在软件开发过程中，主要包括需求分析与管理、设计、程序设计、测试、运行与维护、项目管理、配置管理、质量保证和文档管理等活动。

2．2．1需求分析与管理
所谓需求分析，是指对需要解决的问题进行详细的分析，以弄清楚问题的本质要求。在软件工程中，软件需求分析就是在确定软件开发可行的情况下，对软件计划阶段建立的软件可行性分析进行细化和求精，分析各种可能的结果，并且分配给各个软件元素。
需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤。但是根据StandishGroup对23000个项目进行的研究结果表明，28％的项目是彻底失败的，46％的项目超出经费预算或者超出工期，只有约26％的项目获得成功。而在这些高达74％的不成功项目中，有约60％的失败是源于需求问题，也就是差不多有一半的项目都遇到相同的问题，这一可怕的现象使人们不得不对需求分析产生高度重视，越来越多的人认识到它是整个过程中最关键，也是最困难的一个过程。这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。由于种种原因，需求会在整个软件开发过程中不断改变和深入，并且需求分析过程中具有用户与开发人员很难进行交流、用户的需求是动态变化的和系统变更的代价呈非线性增长等特点，对软件需求进行管理也是至关重要的。软件需求管理可以定义为一个为系统的需求进行启发、组织、建档的系统方法，一个建立与维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。

2．2．2设计和程序设计
软件设计是把许多事物和问题抽象起来，并且抽象它们不同的层次和角度。软件设计可以定义为应用各种各样的技术和原理，并用它们足够详细的定义一个设备、一个程序或系统的物理实现的过程。
软件的设计是一个将需求转变为软件陈述(表达)的迭代过程。软件的设计包括两个基本步骤：
(1)体系结构设计，主要关注如何将需求转换成软件的系统架构。
(2)构件设计，关注将设计出的体系结构逐步求精细化为具体的数据结构和软件的算法表达。
软件设计中的要素包括软件的结构设计、数据设计、接口设计和过程设计等，其中，结构设计是指定义软件系统各主要部件之间的关系；数据设计是指将模型转换成数据结构的定义；接口设计是指软件内部，软件和操作系统间以及软件和人之间如何通信；过程设计是指系统结构部件转换成软件的过程描述。
要获得一个良好的软件设计不是靠碰运气，而是需要在设计过程中通过综合运用各种设计原理、系统方法和彻底的评定回顾才能实现。软件设计方法每天都在变化，但是一般而言，良好的设计应保持如下的几个原则：
(1)设计对于分析模型应该是可跟踪的：软件的模块可能被映射到多个需求上。
(2)设计结构应该尽可能的模拟实际问题。
(3)设计应该表现出一致性。
(4)不要把设计当成编写代码。
(5)在创建设计时就应该能够评估质量。
(6)评审设计以减少语义性的错误。
当软件设计完成之后，为了获得可以运行的系统，必须依据设计进行程序设计。
软件程序设计是指将上一阶段的详细设计得到的处理过程的描述转换为基于某种计算机语言的程序，即源程序代码。在程序设计中需注意根据项目的应用领域选择适当的编程语言、编程的软硬件环境以及程序设计的程序设计风格等事项。
如果设计已经表示得很详细，那么部分代码的生成可以自动完成。

2．2．3软件测试
一旦生成了代码，就可以开始进行程序测试了。软件测试就是为了发现错误而执行程序的过程，是根据程序开发阶段的规约说明及程序内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序，以发现程序错误的过程。执行测试之后，需要对发现的故障进行跟踪，以确保开发的软件产品适合用户的需求。
测试过程要集中在软件的内部逻辑和外部功能两个方面，内部逻辑方面保证所有语句都测试到，外部功能方面可以引导测试去发现错误，并保证定义好的输入能够产生与预期结果相同的输出。从软件开发者的角度出发，则希望软件测试能够暴露软件中隐藏的错误和缺陷，从而为软件的改进奠定基础。
GrenfordJ．Myers曾对软件测试的目的提出过以下的三个观点：
(1)测试是为了发现程序中的错误而执行程序的过程。
(2)好的测试方案应该尽可能地发现迄今为止尚未发现的错误。
(3)成功的测试是发现了至今为止尚未发现的错误的测试。
这些观点指出软件测试是以查找错误为中心。然而，实际上发现错误并不是软件测试的唯一目的。在进行软件测试过程中，应该把握以下原则：
(1)软件测试并不仅仅只是为了找出软件中存在的错误。在软件测试中，除了发现软件中存在的错误之外，还需要分析错误产生的原因和错误的发生趋势，帮助项目开发者发现当前软件开发过程中的缺陷，以便进行及时改进。
(2)这种分析也能帮助测试人员设计出更有针对性的测试用例和方法，改善测试的效率和有效性。
(3)没有发现错误的测试也是有价值的，完整的测试应该也是评定软件质量的一种方法。

2．2．4运行与维护
变化是所有软件工作中普遍存在的性质，当软件在交付给用户之后不可避免地要发生修改。一般在如下情况下会发生修改：当遇到错误时；当软件必须适应外部环境的变化时(例如，因为使用新的操作系统或外设)；当用户希望增强功能或性能时。系统运转之后，任何针对系统改变所做的工作，都可以被认为是维护。
对于软件系统而言，系统的维护与硬件的维护不同。硬件的维护是为了修复或预防损坏及零部件不能正常工作的情况，更换磨损的零部件或者使用技术来延长硬件系统的寿命。然而，对于软件系统，循环结构在循环一万次之后也不会磨损，程序中的符号也不会从语句中脱落，即软件并不会损坏，不需要定期维修。
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序，修改后要填写程序修改登记表，并在程序变更通知书上写明新旧程序的不同之处。
维护的目的是为了保证软件系统能持续地与用户环境，数据处理操作，政府或其他有关部门的请求取得协调。
软件维护并不仅仅是“修正错误”，软件维护一般包括以下四类活动：纠错性维护；适应性维护；完善性维护或增强；预防性维护或再工程。
所有维护工作中仅仅大约20％花费于“修正错误”，其余的80％是花费在修正现有系统已适应外部环境的改变，根据用户要求进行增强，以及为了未来的使用对应用进行再工程。

2．2．5软件项目管理
软件项目管理是美国在20世纪70年代中期提出的，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70％的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理问题。
软件项目管理是指为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员、产品、过程和项目进行分析和管理的活动。软件项目管理的对象是软件项目本身，它所涉及的范围覆盖了整个软件工程过程。软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、程序设计到测试、维护全过程)都能在管理者的控制之下，以预定成本按期按质地完成软件并交付给用户使用。
为能够使软件项目的开发获得成功，关键是必须对软件项目的工作范围、可能存在的风险、需要的各种资源、系统要实现的功能、需要经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。这种管理在技术工作开始之前就应开始，始终贯穿于软件开发的整个过程中，直到软件工程过程结束时才终止。
根据软件项目管理的目的，一般的软件项目管理的内容主要包括如下几个方面：人员的组织与管理；软件项目计划；风险管理；软件度量；软件配置管理；软件过程能力评估等。这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理主要是把注意力集中在项目组成员的构成、调整和优化上；软件项目计划主要包括软件开发中的工作量、成本、开发时间的估算，并根据估计值制定和调整项目组成员的工作，项目计划应能允许一定程度的需求变更或项目范围的扩展；风险管理是指为了预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防的活动；软件度量是用量化的方法评估软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面；软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略；软件过程能力评估是对软件开发能力的高低进行衡量。
在20世纪80年代初，著名软件工程专家B．W．Boehm总结出了软件开发时需遵循的七条基本原则，同样，在进行软件项目管理时，也应该遵循这七条原则。它们是：
(1)用分阶段的生命周期计划严格管理。
(2)坚持进行阶段评审。
(3)实行严格的产品控制。
(4)采用现代程序设计技术。
(5)结果应能够清楚地审查。
(6)开发小组的人员应该少而精。
(7)承认不断改进软件工程实践的必要性。

2．2．6软件配置管理
对于软件开发项目而言，如何进行控制是～项十分重要的管理活动。在目前软件开发过程中面临着许多问题，如在有限的时间、资金内满足不断增长的产品质量要求；软件开发的环境日益复杂，程序的规模越来越大；代码共享日益困难，需跨越的平台增多；软件的维护越来越困难；软件的重用性需要提高等。为了解决这一系列的问题，软件工程中提出了软件配置管理的方法。
软件配置管理(SoftwareConfigurationManagement，SCM)是应用于整个软件过程中的保护性活动，它是指标识、控制和管理软件变更的一种管理方法。软件配置由一组相互关联的对象组成，这些对象也称为配置项。配置项是作为软件工程活动的结果而产生的。除了程序、文档和数据等配置项之外，用于开发软件的开发环境也可置于配置控制之下。一旦一个配置对象已被开发出来并且通过了评审，它就变成了基线。对基线对象的修改导致建立该对象的版本。是否进行配置管理与软件的规模有关，它的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。
在IS09000．3中，配置管理的功能包括如下内容：
(1)唯一地标识每个软件项的版本。
(2)标识共同构成一个完整产品的特定版本的每一软件项的版本。
(3)控制由两个或多个独立工作的人员同时对一给定软件项的更新。
(4)按要求在一个或多个位置对复杂产品的更新进行协调。
(5)标识并跟踪所有的措施和更改。
这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。
软件配置管理分为版本管理、问题跟踪和建立管理三个部分，其中版本管理是基础。

2．2．7软件质量保证
最初，对于像IBM、CA、PeopleSoft等国外的很多大公司来说，保证质量的主要手段就是系统测试。后来，由于缺乏有效的项目计划和项目管理。留给系统测试的时间很少。此外，需求变化太快，没有完整的需求文档，测试人员只能依据自己的想象来进行测试。因此，测试就难以真正保障产品的质量。在这种情况下，具有事先预防的质量保证(QualityInsurance，QA)职能就应运而生。事先预防的QA也符合软件工程“缺陷越早发现越早修改越经济”的原则。
软件质量保证(So{twareQualityInsurance，SQA)就是建立一套系统化的方法，来向管理层保证拟定出的步骤、标准、实践和方法能够正确地被所有项目所采用。软件质量保证是在软件过程中的每一步都应该进行的“保护性活动”，其目的是通过对软件产品和活动进行评审和审计来验证软件是合乎标准的，从而使软件过程对于管理人员来说是可见的。
软件质量保证的方式主要有：基于执行的测试(通常所说的测试)、基于非执行的测试(也称为评审)和程序正确性证明。其中，软件评审是sQA中最为重要的活动之一，其作用就是在发现和改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行评审的两类方法。走查过程一般较为随意；审查过程不仅步数比走查多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大多数是规约说明错误或设计错误，而正式的技术评审发现这两类错误的有效性高达75％，因此是一种非常有效的软件质量保证方法。

2．3软件过程模型
软件过程模型是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、程序设计和测试等阶段，有时也包括维护阶段。软件过程模型能够清晰、直观地表达软件开发的全过程，明确规定要完成的主要活动和任务，用来作为项目实施的基础。对于不同的软件项目，可以采用不同的过程模型来指导项目的实施。
传统的软件过程模型是线性顺序模型，它是最早、也是应用最广泛的软件工程模型。但是，随着软件工程技术的发展，又产生了一些新的模型，本节主要对它们进行介绍。

2．3．1瀑布模型
20世纪70年代WinstonRoyce提出了软件生命周期中著名的模型——“瀑布模型”，直到20世纪80年代初，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制订计划、需求分析、软件体系结构设计、构件设计、程序程序设计、软件测试和运行维护等基本活动，并且规定了它们自上而下、相互衔接的固定次序。即在瀑布模型中，首先是对需求进行仔细的分析并制订一份功能／结构说明，接着是体系结构设计，构件设计，然后才着手程序设计。程序设计结束后进行测试，最后才是软件的发布。瀑布模型强调文档的作用，要求每一个阶段都有明确的文档产出，并要求每个阶段都要仔细验证，当评审通过，且相关的产出物都已成为基线后才能够进入到下一个阶段。
可以看出，瀑布模型中至关重要的一点是：只有当一个阶段的文档已经编制好并获得认可才可以进入下一个阶段。这样，瀑布模型就是通过强制性的提供规约文档要求来确保每个阶段都能很好的完成任务。
瀑布模型是早期软件设计的主要手段，其优点包括：
(1)强调软件开发的阶段性。
(2)强调早期计划及需求调查的重要性。
(3)强调产品测试。
虽然瀑布模型有很多很好的思想可以借鉴，看上去很有逻辑，但整个的模型几乎都是以文档驱动的，模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
(1)依赖于开发早期进行的唯一一次需求调查，不能适应需求的变化。
(2)各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
(3)由于是单一流程，开发中的经验教训不能反馈应用于本产品的开发过程中。
(4)风险往往会迟至开发的后期才显露，因而失去及早纠正的机会，从而增加了开发的风险。

2．3．2迭代模型和增量模型
任何项目都会涉及一定的风险，虽然不可能预知所有的风险，但是如果能在生命周期中尽早发现并避免尽量多的风险，那么项目的计划自然就更趋精确。迭代模型和瀑布模型的最大的差别就在于风险的暴露时间上。在瀑布模型中，文档是主体，很多的问题要到最后才暴露出来，为了解决这些问题就会付出巨大的代价。因此，早在20世纪50年代末期，软件领域中就出现了迭代模型。早期的迭代过程被描述为“分段模型(Stagewisemodel)”，其应用背景是Benington领导的美国空军SAGE项目。
在迭代模型中，只需根据主要风险列表选择要在迭代中开发的新增内容，当每次迭代完成后就会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险，如图2-3所示。迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。每次迭代都至少包括需求、分析设计、实施和测试等工作流程，而且每次迭代完成后都是一个可以交付的原型。但迭代不是并行，在每次迭代过程中仍然要遵循需求、设计到开发的瀑布过程，它类似小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
迭代模型的使用条件如下：
(1)在项目开发早期需求可能会有所变化。
(2)分析设计人员对应用领域比较熟悉。
(3)项目风险比较高。
(4)用户可以不同程度地参与整个项目的开发。
(5)可以使用面向对象设计方法或统一建模语言(UnifiedModelingLanguage，UML)。
(6)能够充分使用计算机辅助软件工程(ComputerAidedSoftwareEngineering，CASE)SI二具。
(7)具有高素质的项目管理者和软件研发团队。
在迭代模型中，迭代周期的长度与项目的周期和规模有很大的关系。小型项目可以一周一次迭代，而对于大型项目而言则可以2～4周一次迭代。如果在项目的开发中没有一个优秀的架构师，则很难规划出每次迭代的内容、要到达的目标、需要验证的相关交付和产出。因此应用迭代模型虽然能够与用户进行很好的交互，可以满足需求的变化，显著减少项目实施的风险，但是要用好它却并非易事。
与迭代模型容易混淆的是增量模型，增量模型如图2—4所示。在增量模型中，软件系统被看作是一系列的增量来进行设计、实现、测试和集成，每一个增量是由多个相互作用的具有特定功能的模块构成。
增量模型在各个阶段并不需要交付一个可运行的完整产品，而只要交付满足客户需求的一个子集的可运行产品。开发人员逐个对各个增量进行交付，这样可以使软件的开发较好地适应需求和环境的变化，客户也能够不断地看到所开发的系统，从而降低开发的风险。增量模型与迭代模型表面上相似，实际上它们具有很大的差异。假设要开发的系统具有A、B、C、D四个大的业务功能，每个功能的开发都需要两周左右的时间。对于增量方法而言，可以将这四个功能进行两次增量来完成，第一次增量完成A、B功能，第二次增量完成c、D功能；而对于迭代方法而言，也可以分两次迭代来进行开发，但是实施具有不同：第一次迭代完成A、B、C、D四个部分的基本业务功能，暂不实现复杂的业务逻辑，第二次迭代再逐渐细化补充完整相关的业务逻辑。此系统的开发中，若采用增量方法，在第一个月过去后A、B功能全部开发完成而C、D功能还一点都没有动；若采用迭代方法，则A、B、C、D四个的基础功能都已经完成。虽然增量和迭代有区别但两者又经常一起使用。
对风险的消除而言，迭代模型和增量模型都能够很好的控制项目前期的风险并进行解决。但是迭代模型在这方面更具优势，因为迭代模型更多的是从总体方面系统地思考问题，从而能够最早地给出系统相对完善的框架或原型，以后的每次迭代都是针对上次迭代的逐步精化。

2．3．3螺旋模型
1988年，BarryBoehm正式提出了软件生命周期的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型中所忽视的风险分析，特别适合于开发大型复杂的软件系统。
螺旋模型采用一种周期性的方法来进行系统开发，基本做法是以进化的开发方式为中心，在每个项目阶段使用瀑布模型法，在瀑布模型的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制。
螺旋模型把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。这个模型沿着螺线进行若干次迭代，每次迭代都包括代表了以下活动。
1)制订计划
确定系统的目标和需求，选定实施的方案，弄清系统开发中的限制条件等。
2)风险分析
对所选方案进行分析和评估，考虑如何识别和消除开发中的风险。
3)工程实现
对系统进行开发和验证。
4)客户评审
评价开发工作，提出修正建议，制订下一步的计划。
对于螺旋模型中的每次迭代，首先是确定该次迭代的目标、完成目标所选的方案及其约束条件，然后从风险角度分析所选方案的开发策略，尽可能地排除各种潜在的风险。如果某些重要风险不能排除，该方案就立即终止，否则启动下一个阶段的开发步骤。最后，评价该次迭代的结果，并对下一次迭代进行设计。在软件开发过程中，每进行一次迭代，软件开发就向前进了一个层次。
螺旋模型很大程度上是一种风险驱动的方法体系，它强调风险识别、分析和控制，使得开发人员和用户对每次迭代中出现的风险有所了解，从而做出应有的反应，特别适用于庞大、复杂并具有高风险的系统的开发。对于此类系统来说，风险是系统开发中不可忽视且潜在的不利因素，它会在不同程度上损害软件开发过程，影响软件产品的质量，因此，减小此类软件系统开发风险就至关重要。减小风险的目标就是在未造成危害之时，及时对风险进行识别和分析，采取相应对策来减少或消除风险的损害。
螺旋模型实现了随着项目成本投入不断增加，风险逐渐减小，有助于加强项目的管理和跟踪，在每次迭代结束后都需要对产出物进行评估和验证，当发现无法继续进行下去时可以及早的终止项目。但是，螺旋模型并不是比其他模型拥有绝对优越，它也有其自身的缺点：(1)螺旋模型强调风险分析，因此，采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时识别风险，势必造成重大损失。
(2)执行风险分析和过多的迭代次数都会增加系统开发的成本，影响项目的利润，延迟提交时间，因此，螺旋模型只适合于大规模软件项目。
此外，需要注意的是，螺旋模型的每一次迭代可能只强调瀑布模型的某一个或两个阶段。如第二次迭代的重点是需求，而第三次迭代则强调总体设计和后续设计开发计划等。因此，螺旋模型与迭代模型有本质的区别，迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶段的工作。

2．3．4原型模型
由于用户对需求往往具有模糊性和变更性，为T能够iEm户确定真正的需求，在开发的初始阶段，构造一个统一的软件系统原型是有必要的。
原型法的基本思想是确定需求策略，对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型，对问题定义采用启发的方式，由用户作出响应。具体做法是，在获取～组基本的需求之后，利用一些比较高级的软件工具可视化地开发环境，快速地建立一个目标系统的最初版本，并把它交给用户进行试用，发现其中的不足，再进行补充和修改，产生新的版本。经过这样一个反复补充和修改过程，直到用户满意为止。
由于原型法是不断地运行系统“原型”来进行启发、判断、揭示、修改和完善的系统开发。它根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品，这个产品只是实现最重要的功能。因此，原型模型在“功能”上等价于产品的一个子集，关键在于尽可能快速地建造出软件原型来确定用户的真正需求。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
利用原型法进行信息系统的设计过程中，分四步进行：首先快速分析，弄清用户／设计者的基本信息需求；然后构造原型，开发初始原型系统；最后系统开发人员修改和完善原型系统。原型模型之后，用户和系统开发人员使用并评价原型；最后系统开发人员修改和完善原型系统。原型模型的使用。
建立原型的基本要求包括：体现系统主要的功能；提供基本的用户界面风格；展示比较模糊的部分以便于进一步确认和明确；原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
原型可以分为三类。
1)淘汰／抛弃式
如果原型仅仅是由于需求阶段方面和用户沟通，那么当原型的目的达到之后即被抛弃，原型不作为最终的产品。
2)演化式
软件系统的形成和发展是逐步完成的，它需要不断动态的迭代和高度的循环，每次迭代都要对系统重新进行规约说明、设计、实现和评价，每次迭代的产出都是可以独立运行和包含基础功能的系统，是后续细化的基础，所以演化式方式是对付变化最为有效的方法。这类原型一般都不建议抛弃，后期的设计开发也要基于该原型逐渐的进行完善。
3)增量式
增量式是指对系统进行一次一段的增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的，其应付变化的能力就比演化式方法差些。
在软件系统设计的过程中，常用的原型形式有以下几种。
1)数据输入原型
建立数据输入的原型，不但能够检查输入数据的正确性和速度，还能够进行完整性和有效性的检验。
2)对话原型
对话原型模拟预期终端的交互，使用户可以从屏幕上查看相关的信息和操作，并提出遗漏之处，从而加深对系统的正确理解。
3)计算和逻辑原型
计算和逻辑原型主要用于应用逻辑或计算比较复杂的情况。这时，分析和设计人员通过使用高级程序语言建立所需的计算实例，用户可以使用这些原型来验证所求结果的准确性。
4)应用程序包原型
应用程序包原型用于在一个应用程序包和其他应用系统相连或实际使用之前来鉴定这个应用程序包的满意度。若用户不满意则可以对它们进行修改，直到满意为止。
5)数据系统原型
数据系统原型原来生成一个含有少量记录的原型数据库，使用户和分析员与此原型进行交互，生成报表并显示有用信息。这种交互经常会产生对不同的数据类型、新的数据域或不同的数据组织方式的需求，也可以在原型的帮助下探索用户如何对信息进行使用。
6)报表系统原型
提供给用户的各种报告应在整个系统实现之前给用户看，报表子系统需要经常进行大量修改以满足系统的需要，因此，可以把报表生成器作为原型。

2．3．5统一过程模型
统一过程(UnifiedProcess，UP)是一种现代的软件开发过程模型，它的历史最早可以回溯到1967的Ericsson方法。UP把复杂系统构造为一组相互联系的功能块，小的功能块相连形成更大的功能块以构造出完整的系统。尽管对于只触及到系统的部分的任何成员来说，整个系统可能是不可理解的，但是当系统被分成更小的组件时，人们可以理解每个组件提供的服务(即组件的接口)以及这些组件是如何协调工作的。或者可以说，系统被划分为具有较大的功能的子系统，每个子系统又由具有更小的功能块(组件)所实现。
UP方法是“分而治之”的思想和现在熟知的基于组件的开发(Component—BasedDevelop—ment，CBD)方法的有机结合。
统一过程模型是一种以“用例和风险驱动、以体系结构为核心、迭代及增量”为特征的软件过程框架，一般由UML方法和工具支持。用例是捕获需求的方法，因此，也可以说UP是需求驱动的。
UP的另一个驱动就是风险，因为如果你不主动预测和防范风险，风险就会主动攻击你。
UP需要对软件开发中的风险进行分析、预测并关注软件的构造。
在基于组件的开发中，体系结构描述了系统的整体框架：如何把系统划分成组件以及这些组件如何进行交互和部署在硬件上。UP方法实际上就是开发和演进一个健壮的系统体系结构。
此外，UP也是迭代和增量的。在UP的迭代构建中，每个迭代包括五个核心工作流：
需求R——捕捉系统应该做什么。
分析A——精化和结构化需求。
设计D——基于系统体系结构来实现需求。
实现I——构造软件系统。
测试T——验证实现是否达到预期效果。
尽管每次迭代都可以包含这5个核心工作流，但是特定工作流的重点依赖于项目生命周期中的迭代发生的位置。迭代的一些可能工作流图解。
把项目划分成一系列迭代，允许对项目进行灵活计划。最简单的方法是按照时间顺序的迭代序列，一个接一个。然而，常常可能并行安排迭代。这意味着需要理解每次迭代的制品之间的依赖，需要有方法指导基于构架和模型的并行迭代。并行迭代的好处是缩短面市时间，可以更好地利用团队，但是必须仔细计划。
UP的项目生命周期一般被划分成四个阶段，如图2-9所示，每个阶段由主要里程碑所终止，这四个阶段和对应主要里程碑如下：
初始阶段——获得项目的基础：生命期目标；
细化阶段——进化软件构架：生命期构架；
构造阶段——构造软件：初始运作功能；
移交阶段——把软件部署到用户环境：产品发布。
随着项目按uP的阶段进展，每个核心工作流的工作量会发生一定变化。
当然，UP模型是一个通用的软件开发过程模型，在针对某个具体组织和项目进行开发时，必须进行定制，定制过程可以考虑下面方面的内容：
内部标准；
文档模板；
工具——编译、配置管理工具等；
数据库——缺陷跟踪、项目跟踪等；
生命周期变更——例如，关键安全系统采用的、更加复杂的质量控制措施。

2．4软件过程中的并行工程
2．4．1软件并行工程的提出
20世纪60年代后期，为克服“软件危机”诞生了软件工程学，为软件的开发与维护注入了生机和活力。传统的软件工程学通常认为软件开发是一个串行的过程，从时间的延续上看需要顺序经历一些阶段才能完成软件系统的开发。正是基于这样的认识，软件过程模型把软件开发划分为若干分离的阶段，认为软件开发可以采用人类解决问题时最普遍采用的策略：“分而治之，各个击破”，并且认为能够像数学推导那样完美地保证前一步的正确结果能够产生后一步的正确结果，最终得到期望的结果。
随着时间的推移，以这种思想为主导的软件工程领域依然存在，许多人们认为可以解决但却没有解决的问题，其中生产率低下和质量欠佳最为突出。因此，如何提高软件生产率和软件质量是摆在软件工程界面前的重大课题。在制造业审，传统的产品开发模式是沿用“串行”、“顺序”和“试凑”的方法，开发过程是按顺序一步步完成的。即顺序地进行市场分析、产品设计、工艺设计、采购、加工和测试。每个部门分工明确，完成一项特定的工作，这种模式在制造业中称为串行工程。产品生存周期：市场分析→产品设计→工艺设计→采购→制造→检测→装配→销售→堆修
在串行工程中，产品开发过程只是一个静态的、顺序的和互相分离的流程。除了在设计后期和制造阶段发现问题能提出工程修改外，设计的上下游工序之间不存在经常性的信息交换，各阶段间仿佛存在一堵墙，每一个阶段结束时完成部门将结果抛过墙交给下一阶段，出现问题则抛回上一阶段。
随着商品市场竞争的加剧，顾客对产品质量、成本和种类的要求越来越高，对产品的生存周期要求越来越短。企业为了赢得市场，就不得不解决加速新产品开发、提高产品质量、降低成本和提供优质服务等一系列问题。此时串行工程的弊端日趋严重，因为这里追求的核心问题是时间和效率，这与串行工程模式格格不入。在此情况下，并行工程(ConcurrentEngineering)应运而生。并行工程是集成地、并行地设计产品及其相关的各种过程(包括制造过程和支持过程)的系统化方法。这种方法要求产品开发人员从设计一开始就考虑产品整个生存周期中从概念形成到产品报废处理的所有因素，包括质量、成本、进度、计划和用户的要求。
并行工程改变传统的串行进行工程实施的模式，组织多个开发小组并行协同工作，对产品生存周期中的各方面、各阶段进行同时考虑和并行交叉设计，把串行产品开发流程转变成集成的、并行的产品开发过程，使工程尽可能并行进行(实际上是串并行同时存在)，达到缩短产品开发周期、提高产品质量和降低成本的目的。
多年来，社会对软件的需求不断快速增长，对软件生产率提出了很高的要求。人们也一直在寻求提高软件生产率的有效途径，但是软件开发者对用户需求的满足却不能令人满意，软件生产率相当低下。提高软件生产率是人们所面对的困难而紧迫的任务之一。实施软件并行开发是提高软件生产率的有希望的突破口。软件并行开发使软件开发尽量并行进行，从而达到加快软件开发速度、提高软件生产率、缩短软件开发周期的目的。正如硬件运算能力的显著提高是由串行转向并行所引发的，实施软件并行开发是提高软件生产率最具有潜力的途径之一。要缩短一个目标的实现时间，最有效的方法莫过于有效地组织可以重复的资源，同时启动实现目标的过程。通过增加重复资源，附加额外控制管理技术为代价换取时间上的节约，是并行的根本意义所在。软件并行开发正是把这样一种思想运用于软件开发，以获得缩短软件开发周期、提高软件生产率的实际效益。
软件并行开发的意义不仅从方法学的层次阐述了一种软件并行开发方法，以提高软件生产率为目的，对实现软件并行开发的各个方面做了必要的分析，而且给出了可行的解决方案，直接面对软件工程的实施，因此具有重要的应用价值。

2．4．2软件并行开发模型
并行开发模型是一种演化模型。在软件开发的实践过程中。项目管理者注意到，试图根据传统过程的主要阶段来追踪项目的状态是根本不可能的。原因是，虽然一个项目正处在程序设计阶段，但同时可能有一些项目组人员在参与涉及开发多个阶段的活动。例如，需求分析、设计、程序设计、测试或集成，所有这些活动可能在同时进行。基于上述事实，Humphrey和Kellner提出的软件工程过程模型表达了这种任一阶段的活动之间存在的并行性。并行过程模型可以大致表示为一系列的主要技术活动、任务及它们的相关状态。主要方法是使用状态图来表示与一个特定事件(如开发后期的一个需求修改)相关活动之间存在的并行关系，但是，它不能捕获贯穿于一个项目中所有软件并行和管理活动的大量并行。
图2—11给出并行开发模型中一个活动的图形表示，该活动(分析活动)在任一给定时间可能处于任一状态。同样地，其他活动(如设计或程序设计)也能够用相同方式表示。所有活动并行存在，但处于不同的状态。如开发后期，分析活动可能处于等待修改状态，程序设计活动可能处于编制状态，而一个需求修改事件，可能触发分析活动进入修改状态，而触发程序设计活动进入等待状态。
并行开发模型主要是以开发过程中的主要技术活动和任务为框架，描述了开发过程中(开发过程是反复迭代的)主要技术活动和任务的并行性。并行开发模型关注开发活动之间的并行性以及它们的相互关系，使项目管理者能够了解其项目当前的总体状态，便于他们有针对性地实施有效的项目管理。但是，对于提高软件产品的质量和开发速度并无实质性的好处。
在软件开发的实践活动中，已经注意到并行性的存在，如主要技术活动和任务的并行性(并行开发模型)。但是，另一类的并行更值得关注，例如，传统软件开发过程的程序设计阶段，可以由多个小组同时对不同的模块进行程序设计。此时，开发活动具有真正的并行性，使开发速度加快。当然，此时的并行粒度是很细的。
现实的需求是软件技术发展最好的推动力。随着计算机应用领域的不断扩大和深人．软件现实的需求是软件技术发展最好的推动力。随着计算机应用领域的不断扩大和深入，软件成分也日益复杂和庞大，为了缩短开发周期，软件开发过程有必要改变它的风格。并行开发对于缩短软件开发周期，提高软件开发速度，不失为一条有效的途径。

2．4．3软件过程中的并行性分析
并行是软件过程中普遍存在的一类现象。在软件过程中，存在着许多并行性。直观上看，粒度较粗的并行性体现在过程一级。如软件开发过程、软件管理过程和软件文档编制过程等之间是并行的。粒度细一些，多个角色之间的活动往往也是并行的。软件并行开发通过挖掘各种并行成分，充分鼓励并行，并通过有效的过程控制，使各种并行成分统一协调地进行，达到加快软件开发速度的目的。软件并行开发还强调改变传统的串行进行软件开发的模式，将软件开发过程划分为若干可以并行进行的单位(称为子开发过程)，使其并行进行，从而将原来存在于软件开发过程中的局部并行性延拓到该过程的全局。本质上，子开发过程也是软件过程。
经过进一步的分析发现，软件过程中的并行性远不止以上两类。根据并行粒度的不同，将它们划分为以下五类(统称为软件过程并行)。
1．软件过程之间的并行(过程并行)
软件过程之间可以是顺序的，也可以是并行的。并行的软件过程之间可以存在同步关系。例如，开发过程和维护过程之间基本上是顺序进行的，开发过程在前而维护过程在后。而开发过程、管理过程和文档编制过程之间则是并行的。开发时有管理，管理的对象是开发；开发时需要产生文档，文档描述的对象是开发和开发结果。管理过程和文档编制过程之间也有类似的关系。这四个软件过程之间是并行的，而且还存在着同步关系。箭头表示存在交互作用。通过这些交互作用实现各并行软件过程之间的同步关系。
2．软件过程内部的全局性并行(子过程并行)
软件过程内部各活动之间是存在并行性的。例如，软件开发过程的程序设计活动，就存在多
个程序员同时程序设计的现象。事实上，可以提升软件过程内部的并行性粒度，将局部的并行性延拓到全局，构成相对独立的并行成分(称为子过程)，对于提高软件生产率具有重要的意义。例如，在延拓以后，软件开发过程(软件过程之一)内部的并行性。为避免繁琐，各子开发过程之间的同步关系图中从略。
3．阶段之间的并行(阶段并行)
制造业并行工程强调的重点是阶段之间的交叠与并行。类似地，软件并行开发也强调软件过程中阶段的交叠与并行。制造业并行工程似乎并不强调本节所分析的其他几类并行，而软件并行开发对这几类并行均加以同等地看待。阶段之间的并行交叠对提高生产率也具有重要意义。如软件开发过程内部某子开发过程各阶段的并行。箭头表示交互作用。
4．软件发行版本之间的并行(版本并行)
在开发一个软件发行版本的同时，就进行着下一个软件版本的开发。箭头表示交互作用。此类并行是粒度最粗的并行。
5．活动之间的并行(活动并行)
活动并行是软件过程中粒度最细的一类并行。活动是任务的集合，任务是把输入变成输出的操作。如软件开发过程中的程序设计阶段，程序员同时进行程序设计活动就是最常见到并被广泛应用的一种活动并行。
通常不再让任务并行，而把活动看成是任务序列。若需要让任务并行，不妨将其看成是活动即解决问题。
上述几类并行性按并行粒度的不同，从粗到细依次为：软件发行版本之间的并行(版本并行)、软件过程之间的并行(过程并行)、软件过程内部全局性并行成分之间的并行(子过程并行)、阶段之间的并行(阶段并行)、活动之间的并行(活动并行)。

2．4．4案例：一个软件并行开发的过程
下面通过一个酒店管理系统为例给出一个软件并行开发过程的例子。
假设经过初步需求分析，该酒店管理系统的各个子系统和各子系统的功能需求如下。
1)前台系统
(1)有效的预定处理，提高酒店入住率。
(2)简便迅捷的前台登记服务。
(3)完善、全面的综合查询。
2)餐饮系统
(1)订餐管理。
(2)收款管理。
(3)系统报表。
3)会议／宴会系统
(1)会议资源管理。
(2)会议安排管理。
4)康乐系统
(1)收费管理。
(2)月统计报表。
5)酒店资源管理系统
(1)人力资源管理。
(2)固定资产管理。
(3)仓库管理。
经过对该酒店管理系统的各个子系统(前台系统、餐饮系统、会议／宴会系统、康乐系统、酒店资源管理系统)及其功能进行分析可知，各个子系统可以进行并行开发，从而提高系统的开发效率。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com