《软件工程-理论、方法与实践》课件第14章

第14章软件计划管理14.1软件项目管理14.2成本估算14.3软件配置管理14.4IBMRational软件配置管理工具本章小结习题

14.1软件项目管理

14.1.1软件项目的特点

与其他项目相比，软件项目有其特殊性，主要表现在：

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

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

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

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

总而言之，“复杂”和“变化”给软件项目的管理带来了相当大的难度，降低复杂性和控制变化成为软件项目管理面临的关键问题。软件项目要想成功，需要大量的因素共同推动。调查研究表明，对信息系统项目成功起关键作用的最重要因素如下：

●清楚地界定目标及项目任务。

●高层管理者的支持。

●优秀的项目经理。

●有能力的项目团队。

●充足的资源。

●客户的参与协商。

●良好的沟通。

●对客户的积极反应。

●适当的监控和反馈。

●正确的技术。14.1.2软件项目管理活动

1．项目启动

在项目启动阶段，项目管理者需要与客户一起定义系统的范围，组建项目的开发团队，并建立项目的基础设施，具体活动内容包括：确定项目范围、组建项目团队和建立项目

环境。

首先，要求项目管理者了解客户的实际需求，从功能、性能和交付要求的角度定义软件的范围，研究系统的可行性和可能的解决方案，并与客户在软件范围、验收标准和交付日期等方面达成正式的协议。其次，项目管理者根据系统任务的要求组织开发团队，并明确每一位成员的角色和职责。

另外，项目管理者应与项目团队一起，建立软件开发所需的基础设施，包括网络环境、软件系统、配置管理工具、文档模板、会议程序和沟通系统等。

2．项目规划

在项目规划阶段，项目管理者对于项目的资源、成本和进度进行合理估算，制定软件开发计划，主要包括确定项目活动、预算项目成本和制定进度计划等活动。

项目管理者需要明确项目的各种活动、里程碑和可交付的文档，确定各种活动之间的依赖关系和执行顺序，估计软件开发所需要的资源；项目管理者还应根据每项活动所需的资源进行成本估算，确定项目的成本预算；并估算完成每一项活动所需花费的时间，制定出合理的开发进度计划，以确保项目在预定时间、预算资金与可利用资源的约束条件下完成。

3．项目实施

在项目实施阶段，项目管理者执行项目计划，及时发现和纠正实际情况与计划的偏差。具体活动内容包括：监控项目执行、管理项目风险和控制项目变更。

项目管理者需要跟踪项目的执行情况，综合评价整个项目的实际进展，及时发现和报告实际情况与计划的偏差，并在必要的情况下采取纠正行动。项目管理者应该识别可能造成项目进度推迟或预算超支的潜在问题，并采取有效的风险管理策略，以减少潜在问题发生的可能性和影响。

任何项目都不可避免地要发生变更，项目管理者应该建立有效的变更控制系统，包括变更控制委员会、软件配置管理和项目沟通体系，以便对项目变更进行控制和管理。

4．项目收尾

在项目收尾阶段，项目团队完成项目的交付，并进行项目总结，主要活动包括：客户验收项目、安装培训软件、总结项目经验。

根据项目协议中规定的验收标准，客户对所交付的软件产品进行评价，最终正式接受产品；项目团队在目标环境中安装软件系统，培训用户使用系统，并移交文档；项目团队分析和总结项目的经验教训，避免在以后的软件项目中犯同样的错误，不断提高软件开发管理水平。综上所述，软件项目管理不仅涉及软件开发过程的各个方面，而且包括开发前期的立项阶段和软件运行以及项目评价阶段的工作，强调了软件项目的生命周期全过程和全方位的管理，强调软件开发队伍与软件用户之间的沟通。软件项目管理的主要职能包括：

(1)制定计划。规定待完成的任务、要求、资源、人力和进度等。

(2)建立组织。为实施计划、保证完成任务，需要建立分工明确的责任制机构。

(3)配备人员。任用各种层次的技术人员和管理人员。

(4)指导。鼓励和动员软件人员完成所分配的工作。

(5)检验。对照计划或标准，监督、控制和检查实施情况。14.1.3软件计划和进度安排

在软件开发过程中，软件项目计划处于十分重要的地位，涉及实施项目的各个环节，是有条不紊地开展软件项目活动的基础，是跟踪、监督、评审计划执行情况的依据。没有完善的工作计划常常会导致事倍功半，或者使项目在质量、进度和成本上达不到要求，甚至使软件项目失败。因此，制定周密、简洁和精确的软件项目计划是成功开发软件产品的关键。软件项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。这些估算应当在软件项目开始的一个时间段内做出，并随着项目的进展定期更新。具体地讲，软件项目计划的主要内容包括确定软件范围，确定需要进行哪些活动，明确每项活动的职责，明确这些活动的完成顺序，估算资源、成本和进度，制定项目计划，编排进度等。

1．确定软件范围

确定软件范围是软件项目计划的首要任务，是制定软件开发计划的根据，是整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。因此，应该从管理角度和技术角度出发，对软件工程中分配给软件的功能和性能进行评价，确定明确的可理解的项目范围。具体地讲，软件范围包括功能、性能、限制、接口和可靠性。

软件范围的确立首先需要说明项目的目标与要求，给出该软件的主要功能描述(只涉及高层和较高层的系统功能)，指明总的性能特征及其约束条件。在估算项目之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用功能分解。软件性能的考虑包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储器或其他现行系统的限制，如主存、数据库、通信速率和负荷限制等。功能、性能和约束必须在一起进行评价。因为，当性能不同时，为实现同样的功能，开发工作量可能相差一个数量级。其次，给出系统接口描述与该软件有关的其他系统之间的关系。对于每个接口都要考虑其性质和复杂性，以便确定对开发资源、成本和进度的影响。接口可以细分为：运行软件的硬件(如处理机和外设)以及由该软件控制的各种间接设备；必须与该软件连接的现有软件(如操作系统、数据库、公用应用软件等)；通过终端或输入/输出设备使用该软件的操作人员。

同时，软件范围还必须描述软件质量的某些因素，如可靠性、实时性、安全性等方面的要求。

2．估算项目

软件项目计划的第二个任务就是估算该软件项目的规模及完成该软件项目所需的资源、成本和进度。

项目规模的度量可以是软件的功能点、特征点、代码行的数目。规模估计涉及的产品和活动有：运行软件和支持软件，可交付的和不可交付的产品，软件和非软件工作产品(如文档)、验证和确认工作产品的活动。为便于估计项目规模，需要将软件工作产品分解到满足估计对象所需要的粒度。为了使开发项目能够在规定的时间内完成，而且不超过预算，工作量与成本的估算和管理控制是关键。但由于影响软件工作量和成本的因素众多，因此对项目的工作量、人员配置和成本的估算，有一定难度，其方法目前还不太成熟。如果可能，应利用类似项目的经验，导出各种活动的时间段，做出工作量、人员配置和成本估算在软件生命周期上的分布。

项目所需资源包括人力资源、硬件资源和软件资源。对每种资源都应说明资源的描述、资源的有效性、资源的开始时间和持续时间。后两个特性又统称为时间窗口。软件项目是智力密集、劳动密集型项目，受人力资源影响最大。项目成员的结构、责任心、能力和稳定性对项目质量以及是否成功有着决定性的影响。因此，在项目计划中，必须认真考虑人员的技术水平、专业、人数以及在开发过程各阶段中对各种人员的需要。对于具有一定规模的项目，在软件开发的前期和后期，即软件计划与需求分析阶段和软件检验、评价与验收阶段，管理人员和高级技术人员需要投入大量精力，而初级技术人员参与较少。在详细设计、编码和单元测试阶段，大量的工作由初级技术人员完成，高级人员主要进行技术把关。在软件开发中，硬件也是一种软件开发工具。硬件资源包括宿主机(指软件开发阶段所使用的计算机和外围设备)、目标机(指运行所开发软件的计算机和外围设备)、其他硬件设备(指专用软件开发时所需要的特殊硬件资源)。

在软件开发过程中，需要使用许多软件工具来帮助软件开发，这些软件工具就是软件资源。主要的软件工具有业务数据工具、项目管理工具、支持工具、分析和设计工具、编程工具、组装和测试工具、原型化和模拟工具、维护工具、框架工具等。为了提高软件生产率和软件质量，应该建立可复用的软件标准件/部件库。当需要时，根据具体情况，对软件部件稍做加工、修改，就可以构成所需的软件。但有时在修改时可能出现新的问题，所以此时应特别小心。

3．编制项目进度表

项目进度表与软件产品的规模估计、软件工作量和成本估算有关。在编制软件进度表时，若有可能，要利用类似项目的经验。应注意的是：软件进度表受规定的里程碑日期、关键的相关日期及其他限制，软件进度表中的活动要有合适的时间间隔，里程碑要以适当的时间长度分开。为了让项目组成员各负其责，应明确规定他们在项目组分担的责任。一种有效的方法就是绘制技术编制表及责任表，在项目开始时就要恰当地搭配好人员、技术及工作任务。随着项目的进展，有可能要把已分的工作再细分或进行新的调整，为此，项目经理需要了解项目组的每个成员，清楚他们的特长、经验以及掌握的技术情况。首先，按照每个成员对专业领域的熟悉程度打分，形成专业领域技术编制表，如表14.1所示。具体方法是，假设将专业领域分为五种：系统分析员、系统设计员、程序员、测试员、硬件工程师，并将最高分定为5分。然后根据每个成员对上述专业领域的熟悉程度打分，熟悉程度越高，得分越高。这样就可以对项目组成员及技术状况一目了然，并据此分配工作。项目经理根据上述技术编制表，结合项目实际需求可以制定责任表，在责任表中确定项目的主要负责人和辅助负责人。每项任务只需要一个人负主要责任，但可以安排几个项目组成员辅助他。

对于具有一定规模的软件项目，通常参加的不止一人，这样开发工作就会出现并行情形。图14.1给出了一个典型的由多人参加的软件项目的任务图。图14.1软件项目的并行性在软件项目的各种活动中，首先是进行项目的需求分析和评审，此项工作是以后工作的基础。只要软件的需求分析通过评审，系统概要设计和测试计划制定工作就可以并行进行。如果系统模块结构已经建立，则对各个模块的详细设计、编码、单元测试等工作就可以并行进行。等到每一个模块都已经测试完成，就可以组装、测试，最后确认测试，以便软件交付。从图14.1所示可以看出，在软件开发过程中设置了许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。当一个软件工程任务成功地通过了评审并产生了文档，就完成了一个里程碑。

软件项目并行性对进度提出了要求，要求进度计划必须决定任务之间的从属关系，确定各任务的先后次序和衔接，确定各任务完成的持续时间，确定构成关键路径的任务。制定项目进度计划的第一步就是估计每项活动从开始到完成所需的时间，即估计工期。工期估计和预算分摊估计可以采用两种办法：一是自上而下法，即在项目建设总时间和总成本之内按照每一工作阶段的相关工作范围来考察，按项目总时间或总成本的一定比例分摊到各个工作阶段中；二是自下而上法，由每一工作阶段的具体负责人进行工期和预算估计，然后再进行平衡和调整。经验表明，行之有效的方法是由某项工作的具体负责人进行估计，因为这样做既可以得到该负责人的承诺，产生有效的参与激励，又可以减少由项目经理独自估计所有活动的工期所产生的偏差。在此估计的基础上，项目经理完成各工期的累计和分摊预算的累计，并与项目总建设时间和总成本进行比较，根据一定的规则进行调整。在进度安排中，为了清楚地表达各项任务之间进度的相互依赖关系，通常采用图示方法。常用的图示方法有甘特图和网络图。在这些图示方法中，必须明确标明以下信息：

(1)各个任务计划的开始时间、完成时间。

(2)各个任务完成的标志。

(3)各个任务与参与工作的人数，各个任务与工作量之间的衔接情况。

(4)完成各个任务所需的物理资源和数据资源。甘特图又称为条形图，如图14.2所示。用水平线段表示任务的工作阶段，线段的起点和终点分别对应着任务的开始时间和完成时间，线段的长度表示完成任务所需的时间。甘特图的优点是标明了各任务的计划进度与当前进度，能动态地反映软件开发进展情况，缺点是难以反映多个任务之间存在的复杂的逻辑关系。图14.2甘特图网络计划是一种在项目的计划、进度安排和控制工作中很有用的技术，它由许多相互关联的活动组成。两种网络计划方法：计划审评技术和关键路径法，都是应用网络图来表明活动的顺序流程以及它们之间的相互关系。通常用两张图来定义网络图，一张图绘出某一特定软件项目的所有任务即任务分解结构，另一张图给出应该按照什么次序来完成这些任务，给出各个任务之间的衔接关系。

如图14.3为旧木板房刷漆的工程网络图。图中1～11为刷漆工程中分解得到的不同任务。图14.3旧木板房刷漆的工程网络图

14.2成本估算

14.2.1软件规模估算

软件规模估算(SoftwareSizeEstimation)是在软件工作产品没有完成之前对软件工程产品的估算。软件规模是软件项目可量化的结果，可以直接采用代码行LOC(LineofCode)来表示，也可以间接采用功能点FP(FunctionPoints)或对象点OP(ObjectPoints)来测算。

代码行LOC是指系统交付的源代码行数。对于现代软件系统，显然直接估算代码行不太容易，而功能点FP和对象点OP则是基于交付系统相关功能度的测算，相对容易提取。功能点FP可以根据外部的输入输出、用户界面、与外部系统的接口、系统使用的文件数来确立。

对象点OP和功能点类似，主要用于数据库语言、脚本语言构成的系统。OP可以是用户界面的个数、报表个数、构造应用程序的所需要的组件个数。而每个对象点也可以依据其复杂度归为三个级别：简单的、中等的和复杂的。表14.2列出了各类对象点的加权因子。其中，组件是指由如Java、C++ 这类第三代语言实现的系统模块。对象点的估算应是系统中的对象点乘以对应加权因子的总和。

软件成本被认为是软件规模S的函数，而S通常采用源代码行作为计算参数，因此，通常需要根据历史的经验将FP/OP转换为代码行。对于不同的程序设计语言，实现每个FP所需要的平均代码行数AVC会有区别。如对于汇编语言，每个FP可能需要200～300行代码行；而对于数据库语言，每个FP只需要2～40行代码行。因此，软件规模S可以用以下公式计算：

S = AVC × FP14.2.2软件成本估算方法

对于一个大型的软件项目，由于项目的复杂性，开发成本的估算不是一件简单的事情，要进行一系列的估算处理，主要是靠分解和类推的手段进行。基本估算方法分为如下三类：

(1)自顶向下估算。这种方法是从项目的整体出发，进行类推。即估计人员根据已完成项目所耗费的总成本(或总工作量)，推算将要开发的软件的总成本(或总工作量)，然后按比例将它分配到各开发任务中，再检验它是否能满足要求。这种方法的优点是估算量小，速度快；缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。

(2)自底向上的估算。这种方法是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个部分的准确性高；缺点是不仅缺少各项任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量(配置管理、质量管理、项目管理)。所以往往估计值偏低，必须用其他方法进行校验和校正。

(3)差别估算。这种方法综合了上述两种方法的优点，是把待定的软件项目与已完成的软件项目进行比较，不同的部分则采用相应的方法进行估算。这种方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。14.2.3专家判定技术

目前，软件成本估算一般包括专家判定、类比估算和经验模型等三种技术。这些技术可以在自顶向下的方法中使用，也可以在自底向上的方法中使用。

Deiphi技术的步骤是：

(1)组织者发给每位专家所有软件系统的规格说明书和一张记录估算值的表格，请他们进行估算。

(2)专家详细研究软件规格说明书的内容。然后组织者召集小组会议，在会上，专家们与组织者一起对估算问题进行讨论。

(3)各位专家对该软件提出三个规模的估算值，即：

ai——该软件可能的最小规模(最少源代码行数)；

mi——该软件最可能的规模(最可能的源代码行数)；

bi——该软件可能的最大规模(最多源代码行数)。

无记名地填写表格，并说明做此估算的理由。

(4)组织者对各位专家在表中填写的估算值进行综合和分类。首先，计算各位专家(序号为i，i=1，2，…，n)的估算期望值Ei和估算值的期望中值E：

(n为专家数)

然后，对专家的估算结果进行分类摘要。

(5)组织者召集会议，请专家们对其估算值有很大变动之处进行讨论。专家对此估算另做一次估算。

(6)在综合专家估算结果的基础上，组织专家再次无记名地填写表格。

从(4)～(6)适当重复几次类比，根据过去完成项目的规模和成本等信息，推算出该软件每行源代码所需成本。然后再乘以该软件源代码行数的估计值，得到该软件的成本估算值。14.2.4COCOMO模型

成本估算是用数学模型来估算软件成本。现有的模型是根据长期的项目经验而总结出的经验公式。

构造性成本模型COCOMO(ConstructiveCostModel)最初出现的是COCOMO81版，是产业界最广泛应用的软件成本估算模型之一，Boehm在他的经典著作“软件工程经济学”中对COCOMO81模型进行了详尽的描述。

1．COCOMO81

Boehm定义了“基本的”、“中间的”和“详细的”三种形式的COCOMO模型，其两个核心公式为：

工作量(人月PM)： ED = rSc

开发时间(月)： TD = a(ED)b

其中，S为千行源代码数KLOC，经验常数r，c，a和b取决于项目的总体类型。在COCOMO81中，项目的类型被分为结构型、半独立型和嵌入型，三种类型的项目特点如表14.3所示。表14.4列出了根据项目类型确立的基本COCOMO公式。但显然，软件系统的三种简单分类并不能准确地估算工作量成本，因此，中间的COCOMO估算公式通过引入与17个成本因素有关的作用系数Mi将模型进一步细化。Mi用来修正公式中的系数r。

17个成本因素Mi列于表14.5中，表中也给出了Mi的取值范围，取值为1.00表示为该项要求正常时的修正系数。考虑成本因素的中间的COCOMO公式对基本公式进行了修正，修正后的公式为

ED = rScM

其中

表14.6列出了正常未经修正的中间COCOMO模型公式。实际应用时应根据项目的特性，对照表14.5来修正系数，参见表14.7给出的示例。详细的COCOMO模型应用自底向上的方式，首先把系统分为系统、子系统和模块多个层次，然后先在模块层应用估算方法得到它们的工作量，再估计子系统，最后算出系统层。详细的COCOMO对于生存期的各个阶段使用不同的工作量系数。

2．COCOMOⅡ

COCOMO81目前已演化为更为全面的COCOMOⅡ版，COCOMOⅡ模型也包含几个层次的模型：早期设计阶段模型、复用模型以及体系结构后阶段模型。

早期设计阶段模型适用于需求已建立、系统设计已处于初始阶段，目标是对软件系统的工作量做近似估计。其估算公式为

ED = 2.94ScM

这里，M是表14.5所列成本因素的简化集。

M = PERS × RCPX × RUSE × PDIF

× PREX × FCIL × SCED

其中，PERS为个人能力；RCPX为可靠性和复杂性；RUSE代表复用性要求；PDIF为使用的平台特性；PREX为个人经验；FCIL是项目支持设施；SCED是对进度的要求。复用模型用于估算集成可复用组件的工作量。由于目前软件系统大量采用可复用的组件来构造新的系统，其工作量计算也应体现面向复用的软件过程活动。复用模型采用对象点作为软件规模估算单位，工作量计算公式如下：

其中，PROD = 对象点数/人月，即软件生产效率。体系结构后阶段模型用于软件体系结构已建立，子系统已分解，是最详细的模型。其工作量计算模型与早期设计阶段模型相同，但此时软件规模的估算应该更精确，公式中的M则考虑表17.5中17个因素，而指数因子C则基于5个因素的值：已有项目经验、开发过程的灵活性、是否需要风险分析、团队合作状况和软件过程成熟度。因素值分为6级，从5到0对应非常低到极高。设Fi表示第i个因素，则表14.7给出一个例子，说明这些成本因素形成是如何影响工作量估算的，其中指数所取的值为1.17；假设指标RELY、CPLX、STOR、TOOL和SCED是项目中的主要成本形成因素，因子取值参见表14.5，所有其他因素取正常值1。

在这个例子中，对关键性的成本形成因素分别赋予了最大和最小值来说明它们对工作量估算带来的影响。从表中可以看出，对成本形成因素取较高值时的工作量估算是初始估算的一倍多，而对这些成本形成因素取低值时的工作量估算会降低到初始估算的大约1/3，这样就突出表示了不同类型项目之间的巨大差异，以及在将一个领域的经验移植到另一个领域时的巨大困难。

COCOMO模型的计算公式是由模型设计者提出来的，反映了设计者们的经验和所掌握的数据，但是，它在实际使用时未免过于复杂。公式中用到的属性太多，而且对这些值的估算带有太多的不确定性。原则上讲，模型的每个用户应该依照自己的历史项目数据来校准该模型，因为这将反映出局部环境对模型的影响，然而实际过程中，很少有机构对过去的项目数据进行长期细心的收集以支持对COCOMO模型的校准。因此，在COCOMO的实际使用中，模型参数的取值一般都用一些公开发表的取值。14.2.5面向对象项目的估算

Lorenz和Kidd给出了面向对象项目的估算建议：

(1)可以使用工作量分解、FP分析和适用传统应用的方法进行估算。

(2)使用面向对象的分析模型建立用例并确定用例数。

(3)对每个用例由分析模型确立系统核心类的数量。

(4)对系统的用户界面进行归类，确定用户界面支持类的加权因子，并计算用户界面支持类数。参考因子为：

●非图形用户界面：2.0。

●基于文本的用户界面：2.25。

●图形用户界面：2.5。

●复杂的图形用户界面：3.0。

(5)确立工作单元数(人日)。Lorenz和Kidd建议每个类的平均工作单元数为15～20人日。

14.3软件配置管理

14.3.1基线和配置项

1．基线(Baseline)

软件变更是软件开发中不可回避的事情。客户希望修改需求，开发者希望修改技术方法，管理者希望修改项目方法，这三个希望都可能引起软件变更。这是因为随着时间的流逝和开发过程的推进，系统相关人员可能会了解和掌握更多的信息，如客户真正需要什么？什么方法最好？项目如何实施代价更小等，这些开发过程中获取的知识促使软件不得不发生变更，而软件开发者也只能认可这类变更。基线是软件配置管理的概念，它帮助我们在不严重阻碍合理变化的情况下来控制变化。IEEE(IEEEStd．610.12-1990)定义基线如下：

基线是已经通过正式复审和批准的规格说明或中间产品，它因此可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变。简单地说，基线是指软件配置项通过正式复审而进入正式受控的一种状态。以软件需求规格说明为例，开发人员可以在需求开发阶段随时根据用户的要求修改该文档。一旦该文档通过正式评审形成基线之后，需求变更就必须受到严格的控制，原则上是不允许轻易变更的，必须按照规定的变更控制程序进行申请、评估、修改和验证。

基线标志着软件开发过程的各个里程碑，通常的软件基线如图14.4所示，它将软件开发各个阶段的工作划分得更加明确，有利于阶段成果的检查和确认。图14.4软件基线(里程碑)

2．软件配置项(SoftwareConfigurationItem，SCI)

软件配置项定义为部分软件开发过程中创建的信息，一个SCI可以是某个大的规约中的某个单独段落，或在某个大的测试用例集中的某种测试用例；一个SCI也可以是一个文档、一个全套的测试用例或一个已命名的程序组件。

软件配置项是配置控制下的一组相关程序、文档或数据的集合，包括：

●与合同、过程、计划和产品有关的文档和数据。

●源代码、目标代码和可执行代码。

●相关产品，包括软件工具、库内可复用软件、外购软件及用户提供的软件。随着软件开发过程的进展，软件配置项的数量将会迅速增加，其内容也会随时发生变化。因此，软件人员必须尽力保证所有软件配置项的正确性和一致性。

以下的SCI成为配置管理的目标并成为一组基线：

●系统规格说明。

●软件项目计划。

●软件需求规格说明。包括图形分析模型、处理规格说明、原型和形式规格说明等。

●初步的用户手册。

●设计规格说明。包括数据设计描述、体系结构设计规格说明、模块设计描述、界面设计描述、对象描述等。●源代码清单。

●测试规格说明。包括测试计划和过程、测试用例和结果记录等。

●操作和安全手册。

●可执行程序。包括模块的可执行代码、链接的模块等。

●数据库描述。

●联机用户手册。

●维护文档。包括软件问题报告、维护请求、软件变化指令等。

●软件工程的标准和规程。除了上面列出的SCI，很多软件工程组织也将软件工具列入配置之中，即特定版本的编辑器、编译器和其他CASE工具被“固定”作为软件配置的一部分。因为这些工具被用于生成文档、源代码和数据，所以当对软件配置进行改变时，必须要用到它们。虽然问题并不多见，但有可能某些工具的新版(如编辑)会产生和原版本不同的结果。为此，工具就像它们辅助产生的软件一样，可以被基线化，并作为综合的配置管理过程的一部分。在实现SCM时，应把SCI组织成配置对象，在项目数据库中用一个唯一的名字组织它们。一个配置对象有一个名字和一组属性，并通过某些关系“连接”到其他对象，如图14.5所示。

图14.5中分别对配置对象“设计规格说明”、“数据模块”、“模块N”、“源代码”和“测试规格说明”进行了定义，每个对象与其他对象的联系用箭头表示。这些箭头指名了一种构造关系，即“数据模块”和“模块N”是“设计规格说明”的一部分。双向箭头则表明一种相互关系。如果对“源代码”对象作了一个变更，软件工程师就可以根据这种相互关系确定哪些对象可能受到影响。图14.5配置对象14.3.2软件配置活动

软件配置管理是软件质量保证的重要一环，在软件开发过程中，其主要任务是控制软件的修改，涉及标识软件配置中各种对象、管理软件的各种版本、建立系统、控制对软件的变更和审计配置等活动。

1．标识配置对象

为了控制和管理，所有SCI都应按面向对象的方式命名并组织起来。此时，对象分为基本对象和组合对象。基本对象指在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”(UnitofText)，例如，需求说明书中某一节，某个模块的源代码，或按等价分类法制定的一套测试用例；复合对象指由若干基本对象和复合对象组合而成的对象，例如，图14.5的“设计规格说明”即为复合对象，它由“数据模块”和“模块N”等基本对象组合而成。每个配置对象都拥有名字、描述、资源列表和实际存在体四个部分。对象名一般为字符串；对象描述包括若干数据项，它们指明对象的类型(例如文档、程序或数据)、所属工程项目的标志及变动和版本的有关信息；资源列表给出该对象要求、引用、处理和提供的所有实体，如数据类型、特殊函数等，有时变量也被看做资源；只有基本对象才有实际存在体，它是指向该对象“文本单元”的一个指针，复合对象此项取null值。

除了标识配置外，还必须指明对象之间的关系。一个对象可标识为另一复合对象的一部分，即此两对象之间存在一个part-of关系。若干part-of关系可定义出对象之间的分层结构。例如：

“E-R图”(part-of)“数据模型”；“E-R图”为数据模型的一部分。

“数据模型”(part-of)“设计规格说明书”；“数据模型”是设计规格说明书的一部分。

由此描述出三个对象组成树状的层次结构。

因一个配置对象可能与其他多个对象有关系，所以SCI的分层结构不一定是简单的树状结构，也有可能是网状结构。此外，在标识对象时还应考虑对象随着开发过程的深入不断演化的因素。为此，可为每个对象创建如图14.6所示的一个进化图，它概述某对象演化的历史，图中每个节点都是SCI的一个版本。至于开发人员如何寻找与具体的SCI版本相协调的所有相关的SCI版本，市场部门又怎样得知哪些顾客有哪些版本，以及怎样通过选择合适的SCI版本配置出一个特定的软件系统等问题，都需要通过有效的标识和版本机制解决。图14.6进化图

2．版本控制

理想情况下，每个配置项只需保存一个版本。实际上因为软件的变更和满足不同用户的需求，往往一个项目保存多个版本，并且随着系统开发的展开，版本数目明显增多。配置管理的版本控制主要解决下列问题：

(1)根据不同用户的需要配置不同的系统。

(2)保存系统老版本，为以后系统追踪时使用。

(3)建立一个系统新版本，使它保留某些决策而舍弃另一些决策。

(4)支持两位以上工程师同时为一个项目工作。

(5)高效存储项目的多个版本。

3．变更控制

一个大型软件开发过程中，无控制的变更会迅速导致混乱。所谓变更控制，即建立一套机制，有意识地控制软件的变更，其过程如图14.7所示。图14.7变更控制过程

4．配置审计

软件配置审计作为一种补救措施，主要考虑下列在正式技术复审中未被考虑的因素：

(1)控制变更指令(ECO)指出的修改是否都已完成？是否另加了哪些修改？

(2)是否做过正式技术复审?

(3)是否严格遵守软件工程标准？

(4)修改过的SCI是否做了特别标记？修改的日期和执行修改的人员是否已经注册？该SCI的属性是否能够反映本次修改的结果？

(5)是否完成与本次修改有关的注释、记录和报告等事宜？

(6)所有相关的SCI是否已一并修改？

5．配置状况报告

配置状况报告(ConfigurationStatusReporting，CSR)作为软件配置管理的一项任务，主要概述发生了什么事情，谁做的，何时发生的以及有什么影响。

CSR的产生与图14.7所述过程紧密相关，当某个SCI被赋予新标记或更新标记时、或