第 15 章软件工程管理技术课件

15.1软件工程管理概述15.2软件项目计划

15.3软件配置管理

15.4软件工程标准化与软件文档第15章软件工程管理技术返回主目录第15章软件工程管理技术15.1软件工程管理概述

15.1.1软件产品的特点

软件是非物质性的产品，而且是知识密集型的逻辑思维的产品，它具有以下特性：

(1)软件具有高度抽象性，软件及软件生产过程具有不可见性。

(2)同一功能软件的多样性，软件生产过程中的易错性。(3)软件在开发和维护过程中的易变性。

(4)不同开发者之间思维碰撞的易发性。

15.1.2软件工程管理的重要性

由软件危机引出软件工程，这是计算机发展史上的一个重大进展。为了对付大型复杂的软件系统，须采用传统的“分解”方法。软件工程的分解是从横向和纵向(即空间和时间)两个方面进行的。横向分解就是把一个大系统分解为若干个小系统，一个小系统分解为若干个子系统，一个子系统分解为若干个模块，一个模块分解为若干个过程。纵向分解就是生存期，把软件开发分为几个阶段，每个阶段有不同的任务、特点和方法。为此，软件工程管理需要有相应的管理策略。

随着软件规模的不断增大，开发人员也随着增多，开发时间也相应持续增长，这些都增加了软件工程管理的难度，同时也突出了软件工程管理的必要性与重要性。事实证明，由管理失误造成的后果要比程序错误造成的后果更为严重。很少有软件项目的实施进程能准确地符合预定目标、进度和预算的，这也就足以说明软件工程管理的重要。软件工程管理目前还没有引起人们的足够重视。其原因:一方面是人的传统观念，工程管理不为人们所重视；另一方面软件工程是一个新兴的科学领域，软件工程管理的问题也是刚刚提出的。同时，由于软件产品的特殊性，使软件工程管理涉及到很多学科，如:系统工程学、标准化、管理学、逻辑学及数学等。因此，对软件工程管理人们还缺乏经验和技术。

在实际工作中，不管是否正式提出管理问题，但都在自觉或不自觉地进行着管理，只不过是管理的好坏程度不同而已。

15.1.3软件工程管理的内容

1.开发人员

软件开发人员一般分为:项目负责人、系统分析员、高级程序员、程序员、初级程序员、资料员和其他辅助人员。根据项目规模的大小，有可能一人兼数职，但职责必须明确。不同职责的人，要求的素质不同。如项目负责人需要有组织能力、判断能力和对重大问题能做出决策的能力；系统分析员需要有概括能力、分析能力和社交活动能力；程序员需要有熟练的编程能力等。人员要少而精，选人要慎重。软件生存期各个阶段的活动既要有分工又要互相联系。因此，要求选择各类人员既能胜任工作，又要能相互很好地配合，没有一个和谐的工作环境很难完成一个复杂的软件项目。

2.组织机构组织机构不等于开发人员的简单集合,要求有好的组织结构；合理的人员分工；有效的通讯。软件开发的组织机构没有统一的模式。下面简单介绍主程序员、专家组及民主组织3种组织机构：

(1)主程序员组织机构：是由一位高级工程师(主程序员)主持计划、协调和复审全部技术活动；一位辅助工程师（或辅助程序员）协助主程序员工作，并在必要时代替主程序员工作；若干名技术人员(程序员)负责分析和开发活动；可以有一位或几位专家和一位资料员协助软件开发机构的工作。资料员非常重要，负责保管和维护所有的软件文档资料，帮助收集软件的数据，并在研究、分析和评价文档资料的准备方面进行协助工作。

主程序员组的制度突出了主程序员的领导，责任集中在少数人身上，有利于提高软件质量。

(2)专家组组织机构：是由若干专家组成一个开发机构，强调每个专家的才能，充分发挥每个专家的作用。这种组织机构虽然能发挥所有工作人员的积极性，但往往有可能出现协调上的困难。

(3)民主组织机构：是由从事各方面工作的人员轮流担任组长。很显然，这种组织机构对调动积极性和个人的创造性是很值得称道的，但是，由于过多地进行组长信息“转移”，不符合软件工程化的方向。

3.用户软件是为用户开发的，在开发过程中自始至终必须得到用户的密切合作和支持。

作为项目负责人，要特别注意与用户保持联系，掌握用户的心理和动态，防止来自用户的各种干扰和阻力。其干扰和阻力主要有:(1)不积极配合:指当用户对采用先进技术有怀疑，或担心失去自己现有的工作时，可能有抵触情绪，因此在行动上表现为消极、漠不关心，有时不配合。在需求分析阶段，做好这部分人的工作是很重要的，通过他们中的业务骨干，才能真正了解到用户的要求。

(2)求快求全：指对使用计算机持积极态度的用户，他们中一部分人急切希望马上就能用上计算机。要他们认识到开发一个软件项目不是一朝一夕就能完成的，软件工程不是靠人海战术就能加快的工程；同时还要他们认识到计算机并不是万能的，有些杂乱无章的、随机的和没有规律的事物计算机是无法处理的。

另外，即使计算机能够处理的事情，系统也不能一下子包罗万象，贪大求全。

(3)功能变化：指在软件开发过程中，用户可能会不断提出新的要求和修改以前提出的要求。从软件工程的角度，不希望有这种变化。但实际上，不允许用户提出变动的要求是不可能的。因为一方面每个人对新事物有一个认识过程，不可能一下子提出全面的、正确的要求；另一方面还要考虑到与用户的关系。对来自用户的这种变化要正确对待，要向用户解释软件工程的规律，并在可能的条件下，部分或有条件地满足用户的合理要求。

4.控制

4.控制控制包括进度控制、人员控制、经费控制和质量控制。为保证软件开发按预定的计划进行，对开发过程要实施以计划为基础。由于软件产品的特殊性和软件工程的不成熟，制定软件进度计划比较困难。通常把一个大的开发任务分为若干期工程。例如，分一期工程、二期工程等。然后再制定各期工程的具体计划，这样才能保证计划实际可行，便于控制。在制定计划时要适当留有余地。

5.文档资料

软件工程管理很大程度上是通过对文档资料管理来实现的。因此，要把开发过程中的一切初步设计、中间过程和最后结果建立成一套完整的文档资料。文档标准化是文档管理的一个重要方面。15.2软件项目计划

15.2.1软件项目计划概念

在软件项目管理过程中，一个关键的活动是制定项目计划，它是软件开发工作的第一步。项目计划的目标是为项目负责人提供一个框架，使之能合理地估算软件项目开发所需资源、经费和开发进度，并控制软件项目开发过程按此计划进行。软件项目计划是由系统分析员与用户共同经过“可行性研究与计划”阶段后制定的。所以软件项目计划是可行性研究阶段的管理文档。但由于可行性研究是在高层次进行系统分析，未能考虑软件系统开发的细节情况，因此软件项目计划一般在需求分析阶段完成后才定稿的。

在做计划时，必须就需要的人力、项目持续时间及成本做出估算。这种估算大多是参考以前的花费做出的。软件项目计划包括研究与估算两个任务，即通过研究确定该软件项目的主要功能、性能和系统界面。估算是在软件项目开发前，估算项目开发所需的经费、所要使用的资源以及开发进度。在做软件项目估算时往往存在某些不确定性，使得软件项目管理人员无法正常进行管理而导致产品迟迟不能完成。现在所使用的技术是时间和工作量估算。因为估算是所有其他项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以不能没有计划就开始着手开发，否则将会陷入盲目性。15.2.2软件项目计划内容

软件项目计划有下列内容。

1.范围

对该软件项目的综合描述，定义其所要做的工作以及性能限制，它包括：

(1)项目目标：说明项目的目标与要求。

(2)主要功能：给出该软件的重要功能描述。该描述只涉及高层及较高层的系统逻辑模型。

(3)性能限制：描述总的性能特征及其他约束条件（如主存、数据库、通信速率和负荷限制等）。(4)系统接口：描述与此项目有关其他系统成分及其关系。(5)特殊要求：指对可靠性、实时性等方面的特殊要求。

(6)开发概述：概括说明软件开始过程各阶段的工作，重点集中于需求定义、设计和维护。

2.资源

软件项目计划所需的资源如下：

(1)人员资源：要求的人员数（系统分析员、高级程序员、程序员、操作员、资料员和测试员）；各类人员工作的时间阶段。人员参加程度如图15.1所示。(2)硬件资源：指软件项目开发所需的硬件支持和测试设备。

(3)软件资源：指软件项目开发所需的支持软件和应用软件，如各种开发和测试的软件。

(4)工具包：指操作系统和数据库软件等。

3.进度安排

进度安排的好坏往往会影响整个项目的按期完成，因此这一环节是十分重要的。制定软件进度与其他工程没有很大的区别，其主要的方法有：(1)工程网络图。

(2)cantt图。

(3)任务资源表。

4.成本估算为使开发项目能在规定的时间内完成，且不超过预算，成本估算是很重要的。软件成本估算是一门不成熟的技术，国外已有的技术只能作为我们的借鉴。

5.培训计划为用户各级人员制定培训计划。

15.2.3软件开发成本估算

为了使开发项目能够在规定的时间内完成，而且不超过预算，成本预算和管理控制是关键。对于一个大型的软件项目，由于项目的复杂性，开发成本的估算不是一件简单的事，要进行一系列的估算处理。一个项目是否开发，从经济上来说是否可行，归根结底是取决于对成本的估算。

1.成本估算方法

成本估算方法有自顶向下、自底向上和差别估算方法。

1)自顶向下估算方法

估算人员参照以前完成的项目所耗费的总成本（或总工作量），来推算将要开发的软件的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配，这种方法称为自顶向下估算方法。自顶向下估算方法的主要优点是对系统级工作的重视，所以估算中不会遗漏系统级的诸如集成、用户手册和配置管理之类的事务的成本估算，且估算工作量小、速度快。它的缺点是往往不清楚低层次上的技术性困难问题，而往往这些困难将会使成本上升。

2)自底向上估算方法

这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做，所以估算较为准确。其缺点是其估算往往缺少与软件开发有关的系统级工作量，如集成、配置管理、质量管理和项目管理等，所以估算往往偏低。

3)差别估算方法差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。该方法的优点是可以提高估算的准确度，缺点是不容易明确“差别”的界限除以上方法外，还有许多方法，大致分为专家、类推和算式估算法。1)专家估算法依靠一个或多个专家对要求的项目做出估算，其精确性取决于专家对估算项目的定性参数的了解和他们的经验。

2)类推估算法自顶向下的方法中，它是将估算项目的总体参数与类似项目进行直接比较相比得到结果。自底向上方法中，类推是在两个具有相似条件的工作单元之间进行。

3)算式估算法专家估算法和类推估算法的缺点在于，它们依靠带有一定盲目和主观的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响。用于估算的方法有两种基本类型：由理论导出和由经验得出。

2.成本估算模型

1)COCOMO估算模型结构性成本模型COCOMO(ConstructiveCostMode)是最精确、最易于使用的成本估算方法之一。该模型分为：基本COCOMO模型，它是一个静态单变量模型，对整个软件系统进行估算；中级COCOMO模型，它是一个静态多变量模型，将软件系统模型分为系统和部件两个层次，系统是由部件构成的，它把软件开发所需人力（成本）看作是程序大小和一系列“成本驱动属性”的函数，用于部件级的估算，更精确些；详细COCOMO模型，将软件系统模型分为系统、子系统和模块3个层次，它除包括中级模型中所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。2)基本COCOMO模型估算公式

E=ab(KLOC)exp(bb)D=cb(E)exp(db)

式中E为开发所需的人力（人-月），D为所需的开发时间（月），KLOC为估计提交的代码行。ab,bb,cb和db是指不同软件开发方式的值，见表15-1。有机方式意指在本机内部的开发环境中的小规模产品。嵌入式计算机开发环境往往受到严格限制，例如时间与空间的限制，因此对同样的软件规模，其开发难度要大些，估算工作量要大得多，生产率将低得多。半有机方式介于有机方式与嵌入方式之间。

生产率=（KLOC）/E（代码行/人月）人员数=E/D3)中级COCOMO模型中级COCOMO模型先产生一个与基本COCOMO模型一样形式的估算公式，然后对15个“成本驱动属性”进行打分，定出“乘法因子”，对公式进行修正。15个成本驱动属性分成如下4组：

(1)产品属性：指所需软件可靠性、数据基大小及产品复杂性。(2)计算机属性：即执行时间方面的限制、主存限制、虚拟机的易变性及计算机周转时间。

(3)人员属性：即分析员能力、应用领域中实践经验、程序员能力、虚拟机使用经验及程序语言使用经验。

(4)项目属性：即现代程序设计方法、软件工具的使用及所需的开发进度。其估算公式为：E=ai(KLOC)exp(bi)×乘法因子，ai，bi值见表15-2。4)Putnam成本估算经验模型

Putnam估算模型是一种动态多变量模型，它是假设在软件开发的整个生存期中工作量的分布。如一个30人年以上的大项目，其人力使用的分布如图15.2所示。根据曲线导出关于提交的代码行数L，人力K（人年）和开发时间td(年)之间的估算公式：

L=CkK1/3t4/3

d

式中Ck是技术状况有关的常数，它的典型值如下：对于差的开发环境Ck=2500

对于好的开发环境Ck=10000

对于优的开发环境Ck=12500

由上述公式可以得到所需开发工作量的公式：

K=L3C-3kt-4d（人年）

15.2.4软件项目进度安排

每一个软件项目都要求制定一个进度安排，但不是所有的进度都得一样安排。对于进度安排，需要考虑的是预先对进度如何计划？工作怎样就位？如何识别定义好的任务？管理人员对结束时间如何掌握，如何识别和控制关键路径以确保结束？对进展如何度量？以及如何建立分割任务的里程碑?软件项目的进度安排与任何一个工程项目的进度安排没有实质上的不同。首先识别一组项目任务，建立任务之间的相互关联，然后估算各个任务的工作量，分配人力和其他资源，指定进度时序。

1.软件开发任务的并行性

若软件项目有多人参加时，多个开发者的活动将并行进行，典型软件开发任务的网络如图15.3所示。从图15.3中可以看出，在需求分析完成并进行复审后，概要设计和制定测试计划可以并行进行；各模块的详细设计、编码与单元测试可以并行进行等。由于软件工程活动的并行性，并行任务是异步进行的，因此为保证开发任务的顺利进行，制定开发进度计划和制定任务之间的依赖关系是十分重要的。项目经理必须了解处于关键路径上的任务进展的情况，如果这些任务能及时完成，则整个项目就可以按计划完成。图15.3典型软件开发任务的并行图

2.Gantt图

Gantt图是先把任务分解成子任务，然后用水平线段来描述各个任务及子任务的进度安排。该图表示方法简单易懂，一目了然，动态反映软件开发进度情况，它是进度计划和进度管理的有力工具，在子任务之间依赖关系不复杂的情况下常使用此种方法。Gantt图的示例如图15.4所示，该图可以表示将任务分解成子任务的情况；表示每个子任务的开始时间和完成时间，线段的长度表示子任务完成所需要的时间；表示子任务之间的并行和串行关系。Gantt图只能表示任务之间的并行与串行的关系，难以反映多个任务之间存在的复杂关系，不能直观表示任务之间相互依赖制约关系，以及哪些任务是关键子任务等信息，因此仅仅用Gantt图作为进度的安排是不够的。图15.4Gantt图的示例

3.工程网络图

工程网络图是一种有向图,如图15.5所示，该图中用圆表示事件（事件表示一项子任务的开始与结束），有向弧或箭头表示子任务的进行，箭头上的数字称为权，该权表示此子任务的持续时间，箭头下面括号中的数字表示该任务的机动时间，图中的圆表示与某个子任务开始或结束事件的时间点。圆的左边部分中数字表示事件号，右上部分中的数字表示前一子任务结束或后一个子任务开始的最早时刻，右下部分中的数字则表示前一子任务结束或后一子任务开始的最迟时刻。对工程网络图只有一个开始点和一个终止点，开始点没有流入箭头，称为入度为零。终止点没有流出箭头，称为出度为零。中间的事件圆表示在它之前的子任务已经完成，在它之后的子任务可以开始。图15.5工程网络图

15.2.5软件质量控制软件质量控制是软件工程管理的重要内容，软件质量控制应做好以下几方面的工作：

(1)采用技术手段和工具:指质量控制活动要贯彻开发过程始终，必须采用技术手段和工具，尤其是使用软件开发环境来进行软件开发。

(2)组织正式技术评审:在软件开发的每一个阶段结束时，都要组织正式的技术评审。国家标准要求单位必须采用审查、文档评审、设计评审、审计和测试等具体手段来控制质量。(3)加强软件测试：指软件测试是质量保证的重要手段，可发现软件中大多数潜在的错误。(4)推行软件工程规范（标准）：指用户可以自己制定的软件工程规范（标准），但标准一旦确认就应贯彻执行。

(5)对软件的变更进行控制：软件的修改和变更常会引起潜伏的错误，因此必须严格控制软件的修改和变更。

(6)对软件质量进行度量：即对软件质量进行跟踪，及时记录和报告软件质量情况。15.3软件配置管理

在软件开发时，变更是不可避免的，而变更时由于没有进行变更控制，可能加剧了项目中的混乱。为协调软件开发使得混乱减到最小，使用配置管理技术，使变更所产生的错误达到最小并最有效地提高生产率。软件配置管理(SoftwareConfigurationManagement,简称SCM)用于整个软件工程过程。其主要目标是标识变更；控制变更；确保变更正确地实现；报告有关变更。SCM是一组管理整个软件生存期各阶段中变更的活动。

15.3.1基线

基线是软件生存期中各开发阶段的一个特定点，它的作用是把开发各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。因此基线可以作为一个检查点，在开发过程中，当采用的基线发生错误时，可以知道其所处的位置，返回到最近和最恰当的基线上。软件开发各阶段基线示例如图15.6所示。图15.6软件开发各阶段基线示例

15.3.2软件配置项随着软件工程过程的进展，软件配置项（SoftwareConfigurationItem,简称SCI）是软件工程中产生的信息项,它是配置管理的基本单位，对已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处的修改。以下的SCI是SCM的对象，并可形成如下基线：

(1)系统规格说明书。

(2)软件项目实施计划。

(3)软件需求规格说明书。

(4)设计规格说明书（数据设计、体系结构设计、模块设计、接口设计和对象描述（使用面向对象技术时））。(5)源代码清单。

(6)测试计划和过程、测试用例和测试结果记录。

(7)操作和安装手册。

(8)可执行程序（可执行程序模块、连接模块）。

(9)数据库描述（模式和文件结构、初始内容）。

(10)用户手册。

(11)维护文档（软件问题报告、维护请求和工程变更次序）。

(12)软件工程标准。

(13)项目开发小结。15.3.3版本控制

软件配置实际上是一动态的概念，它一方面随着软件生存期向前推进，SCI的数量在不断增多，一些文档经过转换生成另一些文档，并产生一些信息；另一方面又随时会有新的变更出现，形成新的版本。表达系统不同版本的一种表示如图15.7所示的演变图，在图中各个结点是一个完全的软件版本。软件的每一个版本都是SCI（源代码、文档及数据）的一个收集，且各个版本都可能由不同的变种组成。图的右边具体说明一个简单的程序版本：它由1，2，3，4和5版本组成，其中版本4在软件使用彩色显示器时使用，版本5在软件使用单色显示器时使用。因此，可以定义版本的两个变种。图15.7版本演变与变种图

15.3.4变更控制软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。变更控制包括建立控制点和建立报告与审查制度。对于一个大型软件来说，不加控制的变更很快就会引起混乱。因此变更控制是一项最重要的软件配置任务，变更控制的过程如图15.8所示。其中“检出”和“登入”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存取控制管理各个用户存取和修改一个特定软件配置对象的权限。同步控制可用来确保由不同用户所执行的并发变更。图15.8变更控制的过程15.4软件工程标准化与软件文档

15.4.1软件工程标准化的定义随着软件工程学的发展，人们对计算机软件的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写程序，扩展到整个软件生存期。诸如软件概念的形成、需求分析、设计、实现、测试、安装和检验、运行和维护，直到软件淘汰（为新的软件所取代）。同时还有许多技术管理工作（如过程管理、产品管理和资源管理）以及确认与验证工作（如评审和审计、产品分析及测试等）常是跨软件生存期各个阶段的专门工作。所有这些工作都应当逐步建立其标准或规范来。由于计算机发展迅速，未形成标准之前，在行业中先使用一些约定，然后逐渐形成标准。

软件工程标准的类型也是多方面的。它可能包括过程标准（如方法、技术及度量等）、产品标准（如需求、设计、部件、描述及计划报告等）、专业标准（如职别、道德准则、认证、特许及课程等）以及记法标准（如术语、表示法及语言等）。下面根据中国国家标准GB/T15538-2019《软件工程标准分类法》给出软件工程标准的分类。软件工程的标准主要有以下3个：

(1)FIPS135是美国国家标准局发布的《软件文档管理指南》（NationalBureauofStandards，GuidelineforSoftwareDocumentationManagement，FIPSPUB135，June1984）。(2)NSAC-39是美国核子安全分析中心发布的《安全参数显示系统的验证与确认》（NuclearSafetyAnalysisCenter，VerificationandValidationfroSafetyParameterDispllaySystems，NASC-39，December1981）。

(3)ISO5807是国际标准化组织公布（现已成为中国的国家标准）的《信息处理——数据流程图、程序流程图、程序网络图和系统资源图的文件编制符号及约定》。这个图表不仅表明了软件工程标准的范围和如何对标准分类，而且对标准的开发具有指导作用。已经制定的标准都可在表中找到相应的位置，而且它可启发人们去制定新的标准。

15.4.2软件工程标准化的意义积极推行软件工程标准化，其道理是显而易见的。仅就一个软件开发项目来说，有许多层次、不同分工的人员相互配合，在开发项目的各个部分以及各开发阶段之间也都存在着许多联系和衔接问题。如何把这些错综复杂的关系协调好，需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，需要进行阶段评审和验收测试。投入运行的软件其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行动规范和衡量准则，使得各种工作都能有章可循。

15.4.3软件工程标准的层次

根据软件工程标准制定的机构与适用的范围，它分为国际标准、国家标准、行业标准、企业规范及项目（课题）规范5个等级。

1.国际标准

由国际标准化组织ISO（InternationalStandardsOrganization）制定和公布，供世界各国参考的标准。该组织有很大的