软件工程项目管理.docx

软件工程项目管理.docx

《软件工程项目管理.docx》由会员分享，可在线阅读，更多相关《软件工程项目管理.docx（22页珍藏版）》请在冰豆网上搜索。

软件工程项目管理

软件工程项目管理

第六章项目管理

本章要点

✧软件项目管理概念

✧项目管理组织及过程

✧软件质量及保证

✧CMM模型

本章学习目标

✧了解软件项目管理的任务与目标、软件的作用范围

✧理解可行性研究、成本估算技术与成本估算模型、软件项目的组织与计划、软件质量保证。

✧理解软件能力成熟度模型（CMM）的基本概念、软件过程的成熟度等级、关键过程区域、软件企业如何实施CMM。

✧掌握软件管理技术的基本方法。

6.1项目管理概述

软件项目管理同样体现出管理的四个基本职能，即计划、组织、领导和控制。

软件项目管理是项目管理方法的一个应用领域，项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。

要想满足或超过项目涉及人员的需求和期望，我们是需要在下面这些相互间有冲突的要求中寻求平衡：

范围、时间、成本和质量

有不同需求和期望的项目涉及人员

明确表示出来的要求（需求）和未明确表达的要求（期望）

项目管理关注计划和资源分配以保证在预算内按时完成质量合格的系统。

项目管理也面临技术开发同样的问题：

复杂和变化。

复杂的产品需要很多有着不同背景和能力的开发者参与开发。

市场竞争和需要使开发过程需要变化，带来了经常性的资源重新分配，并使得对项目状况的跟踪也变得困难。

管理者和开发者使用同样的方法处理和多变问题：

通用模型、交流、基本原理和配置。

项目管理已经成为一种广泛应用于各行各业的技术管理过程。

在软件行业，对项目实施有效的管理是软件成败的关键。

项目管理已经得到越来越多的企业和政府部门的重视，学习和借鉴国际上先进的项目管理经验是非常明智和有益的。

软件企业的项目规范是许多公司通过几十年的摸索和实践逐步发展形成的。

随着我国正式加入世界贸易组织（WTO），我国与国际上的交流与合作更加频繁，越来越多的国内软件将承接外包软件作为业务发展的一个方向。

外包软件指的是发达国家的企业将软件开发项目转移到他国。

利用他国廉价的劳动力成本来降低软件开发的成本。

国外企业选择外包软件的合作伙伴时，最看重的是项目管理的项目经理的综合素质要求较高，好的项目经理应该在软件开发技术，软件开发技术，软件工程理论与实践，项目管理，人际沟通等方面均要有较深的造诣。

6.1.1项目管理的特点

软件项目管理除涉及计算机软硬件领域技术外，还涉及到系统工程学、心理学、社会学、经济学、乃至法律等方面的问题。

需要用到多方面的综合知识，特别是要涉及到社会的因素、精神的因素、人的因素比技术问题复杂得多。

在相关领域的研究成果和实践已经比较丰富，但在具体的软件项目实践中，必须结合该项目的工作条件、人员和社会环境等多种因素来开展和实施。

软件工程发展的实践证明，软件项目成败的关键往往在于项目管理能力水平的高低，管理得好就能带来效率，赢得时间，最终将在技术前进的道路上取得领先地位。

软件项目的特点：

软件产品与其他任何产业产品相比有它自己的特点，它是无形的，没有物理属性，它是一个物理系统的逻辑影射，因此难以理解难于驾驶。

但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。

文档编制的工作量在整个项目过程研制过程中站有很大的比重，但往往人们并不重视，因而直接影响了软件的质量。

软件开发工作技术性很强，要求参加工作的人员具有一定的技术水平和实际工作的经验。

另外，人员的流动对项目的影响很大，离去的人员不但带走了重要信息，还带走了工作经验。

软件项目管理的困难

1.智力密集，可见性差：

软件工程充满了大量高强度的脑力劳动。

软件开发的成果是不可见的逻辑实体，软件产品的质量的尺度加以衡量，对于不深入掌握软件知识或缺乏软件经验的人员，是不可能领导做好软件管理工作的。

2.单位生产：

在内容、形式各异的基础上研制或生产，与其它领域中大规模现代化生产有着很大的差别，也自然会给管理工作造成许多实际困难。

3.劳动密集，自动化程度低：

软件项目经历的各个阶段都渗透了大量的手工劳动，这些劳动十分细致、复杂和容易出差。

尽管近年来已经有了软件工具和CASE的研究，但远未达到自动化的程度。

软件产品的提高自然受到了很大影响。

4.使用方法繁琐，维护困难：

软件工作渗透人的因素：

不仅要求软件人员具有一定的技术水平和工作经验，而且还要求他们具备良好的心理素质。

软件人员的情绪和他们的工作环境对他们工作有好大的影响。

在总结和分析足够数量失误的软件项目之后，看出其原因大都与管理工作有关问题渗透及到软件项目研制中的计划制定，进度估计资源使用，人员配备，组织机构和管理方法等管理的许多侧面。

软件项目管理的主要职能包括：

制定计划：

规定待完成的任务、要求、资源和进度等

建立组织：

为实施计划，保证任务的完成，需要建立分工明确的责任制度。

配备人员：

任何各种层次的技术人员和管理人员。

指导：

鼓励和动员软件人员完成所分配的工作。

检验：

对照计划和标准，监督和检查实施的情况。

6.1.2项目管理的过程

为使软件项目开发获得最终成功，必须对软件项目的工作范围，可能遇到的风险，需要的资源（人，软/硬件），要实现的任务，过程中的里程碑，花费的工作量（成本），以及进度的安排作到心中有数。

软件项目管理应该提供这些信息，这种管理开始于技术工作开始之前，在软件从概念到实现的过程中持续进行，最后终止于软件项目工程结束。

通常，软件项目管理包括以下过程：

1软件项目启动

通常，项目管理人员和用户是在系统工程启动阶段确定项目的目标和范围。

当明确了软件项目的目标和范围后，就考虑可能的解决方案，标明技术和管理上的要求，确定合理，精确成本估算，实际可行的任务分解以及可管的进度安排。

2度量

度量的工作是为了有效地定量地进行管理。

度量的目的是为了把握软件工程实际情况和它所生产的产品质量。

在对过去未度量的事项进行度量时，需要解决是哪些适合于过程和产品,如何使用收集到的数据，用于比较个人、过程或产品的度量是否合理。

3估算

在软件项目管理过程中一个关键的活动是制定项目计划。

在做计划时，必须就需要的人力、项目持续时间、成本作出估算。

这种估算大多是参考以前的花费作出的。

管理人员可使用各种估算技术，并可用一种估算技术作为另一种估算技术的交叉检查。

4风险分析

风险分析对软件项目管理是决定性的，风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括风险识别、风险估计、风险管理方案、风险解决和风险监督，它能让人们去主动“攻击”风险。

5进程安排

软件项目的进程安排与任何一个项目的进程安排没有实质上的不同。

首先识别一组项目任务，再建立任务之间的相互关联，然后估算各个任务的工作量，分配人力和其它资源，制定进度时序。

6追踪和控制

项目管理人员追踪在制度安排的每个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。

此外，还可以对资源重新定向，对任务重新安排或者可以修改交付日期以调整已经暴露的问题。

用这种方式可以较好地控制软件的开发。

6.2项目计划

计划是管理工作的重要职能，在软件项目管理中，软件项目从制定项目计划开始。

项目计划中需要确定以下几项内容：

目标：

定义了待完成的目标，迫切需要的资源，约束和优先级。

范围：

定义待开发系统的边界，什么包括在系统里，什么不包括在系统里。

产品技术说明：

说明软硬件信息以及有关功能、性能、安全性等方面的约束。

时间：

进度表。

资金：

预算。

地点：

工作空间分配。

人员：

参与人员以及项目组织。

在这里，我们强调，项目计划所需确定的内容最终必须以文档的形式保留下来，无论软件项目的规模多少，项目计划文档都是必需的。

因为：

1、撰写项目计划的过程也是一个澄清模糊认识，整理思路的过程，只有用文字记录下来的东西，才是明确的。

2、文档能够作为同其他人的沟通渠道。

项目计划可以帮助客户了解我们的开发活动，帮助项目组成员了解项目的约束和策略，帮助项目经理跟踪项目的进展。

3、项目计划文档可以作为数据基础和检查列表。

通过定期回顾，项目经理能清楚项目所处的状态以及哪些环节需要重点进行更改和调整。

很明显，在做这些计划时并为进行项目需求分析，所依据的基础是系统计划，以系统规格说明为依据。

要准确回答以上问题是比较困难的，主要靠的是估计，估计的准确程度也与项目的风险直接相关。

项目计划针对不同的工作目标，类型有如下几种:

项目实施计划，这是软件开发的综合性计划，包括人物、进度、人力、环境、资源，组织等。

质量保证计划，把软件开发的质量要求具体规定为在每

批个开发阶段中可以检查的质量保证活动。

软件测试计划，规定测试活动的人物、测试方法、进度、资源、人员职责等。

文档编制计划，规定所开发的项目应编制的文档种类、内容、进度、人员职责等。

用户培训计划，规定对用户进行培训的目标、要求、进度、人员职责等。

综合支持计划，规定软件开发过程中所需要的支持，以及如何获得和利用这些支持。

软件分发计划，软件项目完成后，如何提交给客户。

在以上各类计划中，软件项目实施计划是综合性的，进行工作的划分是该计划应首先解决的问题，常用的计划结构有按阶段进行项目的计划,任务分解结构和人物责任矩阵。

6.3进度安排

软件开发项目的进展安排有两种考虑方式：

1.统最终交付日期已经确定，软件开发部门必须在规定期限内完成任务。

2.系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定

进度安排的准确程度可能比成本估算程度更重要。

如果进度安排落空，会导致市场机会的丧失，使得用户不满意，而且也会导致成本的增加。

因此，在考虑进度安排时，要把人员的工作量与花费的时间联系起来

对于一个小型软件开发项目，一个人就可以完成需求分析、设计、编码和测试工作。

而对于一个稍大型的软件项目，一个人单独开发，时间太长。

因此，软件开发组是必要的。

一般软件开发组的规模不能太大，人数不能太多，2--8人左右较合适当参加同一软件工程项目的人数超过一人的时候，开发工作就会出现并行情况。

在软件开发过程的各个活动中，第一项任务是进行项目的需求分析和评审，此项工作为以后的并行工作打下了基础。

一旦软件的需求得到认可，并且通过了评审、概要设计（系统结构设计和数据设计）工作和测试计划制定工作就可以并行进行。

如果系统的模块结构已经建立，对各个模块的详细设计、编码、单元测试等工作也可以并行进行。

待到每个模块都已经完成，就可以对它们进行组织，并进行组装测试。

最后，进行确认测试，为软件交付进行确认工作。

软件工程项目的并行性提出一系列进度要求。

因为并行任务是同时发生的，以进度计划决定任务之间的从属关系，确定各个任务的先后次序和衔接，以及各个任务完成的持续时间。

此外，应注意构成关键路径的任务，即要保证整个项目能按进度要求完成，就必须保证这些关键任务要按进度要求完成。

这样，就可以确定在进度安排中应保证的重点。

前人在整个定义与开发的阶段工作量分配了一种建议方案。

这个分配方案称为40-20-40规则。

它指出在整个软件开发过程中，编码的工作量分配仅占20%，编码前的工作量占40%，编码后的工作量占40%。

40-20-40规则只是用来作为一个指南，实际的工作量分配比例必须按照每个项目的特点来决定。

一般在计划阶段的工作量很少超过总工作量的2%-3%，除非是具有高风险的巨额投资的项目。

需求分析可能占总工作量的10%-25%。

花费在分析或原型化方面的工作量应当随项目规模和复杂性成比例地增加。

通常用于软件设计的工作量在20%-25%之间，而在设计评审与反复修改的时间也必须考虑在内。

由于软件设计已经投入了工作量，因而其后的编码工作相对来说困难要小一些，用工作量的15%-20%就可以完成。

测试和随后的调试工作约占总工作量的30%-40%，所需要的测试量往往取决于软件的重要程序。

在项目实施过程中进行追踪和控制是软件项目管理的一项重要工作。

比如定期举行项目状态会议。

评价在软件工程过程中所产生的所有评审的结果。

确定由项目的计划进度所安排的可能选择的正式的里程碑，比较在项目计划表中所列出的每个想没的任务的实际开始时间和计划开始时间。

6.4项目估算

软件项目管理过程从一开始被称为项目计划的活动开始。

这些活动中的第一个是估算。

无论何时进行估算，我们都是在预测未来没，在做软件项目估算时往往存在某些不确定性，使得软件项目管理人员无法正常迟迟不能完成。

虽然估算是一门科学，但它更是一门艺术，可这个重要的活动不能以随意的方式开进行。

现在已使用的实用技术是时间和工作量估算。

因为估算是所有其他项目计划活动的基石，且项目计划又为软件工程提供了工作方向，所以不能没有计划就着手开发，否则将会陷入盲目开发。

对软件项目进行有效的估算，取决于掌握多少有关项目范围的原始资料。

通常，应当根据正式的需求描述进行估算。

正式的需求描述可以是需求说明书、系统规格说明书或软件需求说明书等。

如果开始时缺乏一些正式的资料，也可以采用口头描述或草稿的方式开始估算工作。

在得到项目范围的正式资料后，必须进行再估算。

估算的两个主要方法是：

第一种方法是根据项目特征和算法进行估算。

例如，根据软件系统的输入、输出、查询、文件及外部接口等信息、使用功能点估算出系统的规模。

基于功能点估算是按照用例（Usecase）来做的，而不是软件功能来做。

通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。

第二种方法是采用类比的方法，根据历史数据来进行估算。

如果有一个以前做过的类似项目并且掌握它的规模，就可以把新项目的各个主要部分与原有项目的相应部分进行比较，得出一个比例关系，将各部分相对于原项目规模比例相加，计算出新项目的规模。

如果估算者的经验丰富并且新项目与老项目具有足够的相似性，就能够得到合理的估算值。

但是采用类比法，往往还要解决可重用代码的估算问题。

估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。

6.4.1软件规模估算

软件项目的规模估计历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估计往往和实际情况相差甚远。

因此，估计错误已被列入软件项目失败的主要原因之一。

先介绍一个衡量软件项目规模最常用的概念--LOC（LineofCode），LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：

JobControlLanguage）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。

一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。

组织可以根据对历史项目的审计来核算组织的单行代码价值。

例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（.c和.h文件）约为250K。

某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中1LOC的价值为：

（240×10000）/150000＝16元/LOC

　　改项目的人月均代码行数为：

　　150000/240=625LOC/人月

　　方法一、Delphi法

　　Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家"专"的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。

Delphi法鼓励参加者就问题相互讨论。

这个技术，要求有多种软件相关经验人的参与，互相说服对方。

　　Delphi法的步骤是：

　　1、协调人向各专家提供项目规格和估计表格；

　　2、协调人召集小组会各专家讨论与规模相关的因素；

　　3、各专家匿名填写迭代表格；

　　4、协调人整理出一个估计总结，以迭代表的形式返回专家；

　　5、协调人召集小组会，讨论较大的估计差异；

　　6、专家复查估计总结并在迭代表上提交另一个匿名估计；

　　7、重复4-6，直到达到一个最低和最高估计的一致。

　　方法二、类比法

　　类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。

类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

　　其基本步骤是：

　　1、整理出项目功能列表和实现每个功能的代码行；

　　2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；

　　3、通过步骤1和2得出各个功能的估计值；

　　4、产生规模估计。

　　软件项目中用类比法，往往还要解决可重用代码的估算问题。

估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。

根据这三个百分比，可用下面的计算公式计算等价新代码行：

　　等价代码行=[（重新设计%+重新编码%+重新测试%）/3]×已有代码行

　　方法三、功能点估计法

　　功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。

通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。

通常的步骤是：

　　1、计算输入，输出，查询，主控文件，和接口需求的数目。

　　2、将这些数据进行加权乘。

下表为一个典型的权值表。

　　　　功能类型　权值

　　　　输入　　　4

　　　　输出　　　5

　　　　查询　　　4

　　　　主控文件　10

　　　　接口　　　10

　　3、估计者根据对复杂度的判断，总数可以用+25%、0、或-25%调整。

　　据发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。

然而，在了解产品越多后，功能点可以转换为软件规模测量更常用的LOC。

6.4.2软件开发成本估算

软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。

它不同于其他物理产品的成本，不包括原材料和能源的消耗，主要是人的劳动消耗。

人的劳动消耗所需代价就是软件产品的的开发成本。

另一方面，软件产品开发的计算方法不同于其他物理产品成本的计算。

软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。

因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发过程所花费的代价作为依据的。

对于一个大型的软件项目，要进行一系列的估算处理，主要靠分解和类推的方法进行。

基本估算方法分为3类：

1、自顶想下的估算方法。

这种方法的主要思想是：

从项目的整体出发，进行类推。

即估算人员根据以前已完成项目所消耗的总成本，来推算将要开发的软件的总成本，然后按比例将它分配到各开发任务单元中去。

这种方法的优点是估算工作量小，速度快。

缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。

2、自底向上的估算法。

这种方法的主要思想是：

把待开发的软件细分，直到没个子任务都已经明确所需要的开发工作量，然后把它们累加起来，得到软件开发的总工作量。

这是一种常见的估算方法。

它的优点是估算各部分的准确性高。

缺点是缺少各个子任务之间相互联系所需要的工作量，还缺少许多同软件开发有关的系统级工作量。

所以估算值往往偏低，必须用其他方法进行校验和校正。

3、差别估计法。

这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从各个子任务中区分出类似的部分和不同的部分。

类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。

这种方法的优点是提高估算的准确程度，缺点是不容易明确所谓“类似”的界限。

常见的几种估算模型为：

1、IBM模型

　　1977年，IBM的Walston和Felix提出了如下的估算公式：

　　E＝5.2×L0.91，L是源代码行数（以KLOC计），E是工作量（以PM计）

　　D＝4.1×L0.36，D是项目持续时间（以月计）

　　S＝0.54×E0.6，S是人员需要量（以人计）

　　DOC＝49×L1.01。

DOC是文档数量（以页计）

在此模型中，一般指一条机器指令为一行源代码。

一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。

对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。

2、Putnam模型

这是1978年Putnam提出的模型，是一种动态多变量模型。

它是假定在软件开发的整个生存期中工作量有特定的分布。

这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。

Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。

其中，td是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以LOC计），Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。

其典型值的选取如下表所示。

3、COCOMO模型

这是由TRW公司开发。

Boehm提出的结构型成本估算模型，是一种精确、易于使用的成本估算方法。

在该模型中使用的基本量有以下几个：

DSI（源指令条数）定义为代码或卡片形式的源程序行数。

若一行有两个语句，则算做一条指令。

它包括作业控制语句和格式语句，但不包括注释语句。

KDSI＝1000DSI。

MM（度量单位为人月）表示开发工作量。

TDEV（度量单位为月）表示开发进度。

它由工作量决定。

（1）软件开发项目的分类

在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种：

组织型、嵌入型和介于上述两种软件之间的半独立型。

（2）COCOMO模型的分类

COCOMO模型按其详细程度分成三级：

即基本COCOMO模型、中间COCOMO模型、详细COCOMO模型。

基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。

中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。

详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。

6.5项目组织

6.5.1组织原则

在建立项目组织时应注意到以下原则：

（1）早落实原则

（2）减少接口

（3）责权均衡

6.5.2人员配备

合理地配备人员是成功地完成软件项目的切实保证。

所谓合理地配备人员应包括：

按不同阶段适时任用人员，恰当掌握用人标准。

1.配备人员的原则：

配备软件人员时，应注意以下3个主要原则：

（1）重质量：

软件项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用教多的经验不足的人员更有限。

（2）重培训：

花力气培养所需的技术人员和管理人员是有效