第十三章 软件项目管理

第十三章软件项目管理,13.1概述,所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。（P277）软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理涉及对人员、过程、产品和项目本身等管理过程中发生的事件的计划和监控,13.1概述,项目：是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内依据规范完成。项目参数：项目范围、质量、成本、时间和资源项目管理是一种为实现既定目标而对技术、人力和资源所进行的系统集成，,13.1概述,软件项目管理针对软件开发的各个阶段进行管理启动阶段：用户提出需求，开发人员进行需求分析，确定可行性，编写项目实施计划计划阶段创建项目范围文档和项目计划，项目计划规定如何开展工作是项目得以实施实施阶段项目进一步设计、编码、测试应协调好实施阶段和控制阶段的关系，确保项目小组成员满足任务、时间和预算要求控制阶段项目经理监督小组成员的工作，收尾阶段正式认可过程,13.1概述,项目管理范围项目与过程项目职责：活动或任务人员人员资源计划协调与沟通软件团队组织软件度量软件过程度量风险管理软件配置管理软件项目管理计划文档（SoftwareProjectManagementPlanSPMP）,13.2计划,软件计划最详尽地描述了软件过程，它包括采用的生命周期模型、开发组织的组织结构、责任分配、管理目标和优先级、所用的技术和CASE工具，以及详细的进度、预算和资源分配。整个计划的基础是工作量估算和完成期限估算。软件项目管理过程从一组项目计划活动开始，而第一项计划活动是“估算”。,13.2.1估算软件规模,代码行技术是比较简单的定量估算软件规模的方法。这种方法根据以往开发类似产品的经验和历史数据，估计实现一个功能需要的源程序行数。当有以往开发类似项目的历史数据可供参考时，用这种方法估计出的数据还是比较准确的。把实现每个功能需要的源程序行数累加起来，就得到实现整个软件需要的源程序行数。为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别作出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这三种规模的平均值a，b，和m之后，再用下式计算程序规模的估计值：用代码行技术度量软件规模时，当程序较小时常用的单位是代码行数(LOC)，当程序较大时常用的单位是千行代码数(KLOC)。,13.2.1估算软件规模,软件科学方法例如：计算操作数和运算符的个数可测量数据针对软件开发中的可测量数据进行度量如：FFP即文件、流和过程文件：持久存在的关系记录集合（排除临时文件和事物文件）流：软件产品与环境之间的数据接口过程：数据的逻辑或算术的操作,功能点技术功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点(FP)为单位，度量软件的规模。1.信息域特性功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)，主文件数(Maf)和外部接口数(Inf)。2.估算功能点的步骤用下述三个步骤，可以估算出一个软件的功能点数(即软件规模)。(1)计算未调整的功能点数UFP首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类成简单级、平均级或复杂级。根据其等级，为每个特性都分配一个功能点数，例如，一个平均级的输入项分配4个功能点，一个简单级的输入项是3个功能点，而一个复杂级的输入项分配6个功能点。然后，用下式计算未调整的功能点数UFPUFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai(1i5)是信息域特性系数，其值由相应特性的复杂级别决定，如表所示。,13.2.1估算软件规模,13.2.1估算软件规模,(2)计算技术复杂性因子TCF这一步将度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准(例如，响应时间)、联机更新等，在表中列出了全部技术因素，并用Fi(1i14)代表这些因素。根据软件特点，为每个因素分配一个从0(不存在或对软件规模无影响)到5(有很大影响)的值。然后，用下式计算技术因素对软件规模的综合影响程度DI：技术复杂性因子TCF由下式计算：TCF=0.65+0.01DI因为DI的值在070之间，所以TCF的值在0.651.35之间。,13.2.1估算软件规模,13.2.1估算软件规模,(3)计算功能点数FP功能点数FP由下式计算：FP=UFPTCF功能点数与所用的编程语言无关，因此，功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别及技术因素的影响程度时，存在相当大的主观因素。,13.2.1估算软件规模,面向对象度量场景脚本数量关键类的数量支持类的数量每个关键类的平均支持类数量子系统的数量,13.2.1估算软件规模,13.2.2工作量估算,计算机软件估算模型使用由经验导出的公式来预测软件开发的工作量，工作量是软件规模(LOC或FP)的函数，工作量的单位通常是人月(pm)。支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型能够适用于所有类型的软件和开发环境。,静态单变量模型这类模型的总体结构形式如下：E=A+B(ev)C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量(LOC或FP)。此外，大多数模型都有某种形式的调整成分，使得E能够依据项目的其他特性(例如，问题的复杂程度、开发人员的经验、开发环境等)加以调整。下面给出几个典型的静态单变量模型。,13.2.2工作量估算,1.面向LOC的估算模型(1)WalstonFelix模型E=5.2(KLOC)0.91(2)BaileyBasili模型E=5.5+0.73(KLOC)1.16(3)Boehm简单模型E=3.2(KLOC)1.05(4)Doty模型(在KLOC9的情况下)E=5.288(KLOC)1.407,13.2.2工作量估算,2面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FP(2)Kemerer模型E=60.627.72810-8FP3(3)Maston、Barnett和Mellichamp模型E=585.7+5.12FP,13.2.2工作量估算,动态多变量模型动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。这种模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下：E=LOCB0.333/P3(1/t)4其中：E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B是“特殊技术因子”，它随着对集成、测试、质量保证、文档及管理技术的需求的增长而缓慢增加，对于较小的程序(KLOC=510)，B=0.16，对于超过70KLOC的程序，B=0.39；P是“生产率参数”，它反映了下述因素对工作量的影响：,13.2.2工作量估算,使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；总体的过程成熟度及管理水平；应用系统的复杂程度。,13.2.2工作量估算,当开发实时嵌入式软件时，典型值是P=2000；对于电信和系统软件来说，P=10000；对于商业系统应用，P=28000。适用于当前项目的生产率参数，可以从历史数据导出。应该注意，软件方程式有两个独立的变量：对软件规模的估算值(用LOC表示)；以月或年为单位的项目持续时间。从式可以看出，开发同一个软件(即LOC固定)的时候，如果把项目持续时间延长一些，则可降低完成项目所需要的工作量。,13.2.2工作量估算,COCOMO2模型所谓COCOMO模型就是Boehm提出的构造性成本模型(COnstructiveCOstMOdel)，COCOMO是一种层次结构的软件估算模型。三个层次的估算模型如下1、应用系统组成模型2、早期设计模型3、后体系结构模型以后体系结构模型为例,13.2.2工作量估算,13.2.3成本估算,Walston_Felix模型:T=2.5E0.35Cocomo模型:T=2.5E0.38Cocomo2模型:T=3.0E0.33+0.2(b-1.0)Putnam模型：T=2.4E1/3,13.2.4进度计划,项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为了做到这一点，管理者必须制定一个足够详细的进度表，以便监督项目进度，并控制整个项目。软件项目的进度安排是一项活动，它通过把工作量分配给特定的软件工程任务，并规定完成各项任务的起、止日期，从而将估算的工作量分布于计划好的项目持续期内。,13.2.4进度计划,目标是为项目负责人提供一个框架7个指导原则：（1）运用项目规划的方法进行协调而不是控制（2）在项目环境中利用不同个性的人（3）预先制定项目规划中需要经常修改的版本（4）授权员工对自己的工作进行评估（5）描述创造价值的任务而不仅仅是价值创造的活动（6）定义具体的可实现的里程碑式的事件（7）在项目规划中使用检查列表、矩阵模型等其他补充工具,项目计划的内容引入项目组织风险分析硬件和软件资源需求工作分解项目进度监控和报告机制,13.2.4进度计划,基本原则下述的基本原则能够指导软件项目的进度安排。1.划分2.相互依赖性3.时间分配4.工作量确认5.定义责任6.定义结果7.定义里程碑,13.2.4进度计划,Gantt图：为了醒目地表示里程碑，可以在Gantt图中加上菱形标记，一个菱形代表一个里程碑，工程网络图：一种有向图圆表示事件有向弧或箭头表示子任务的进行箭头上的数字称为权，该权表示此子任务的持续时间箭头下面括号中的数字表示该任务的机动时间,13.2.3进度计划,图9.1旧木板房刷漆工程的Gantt图,13.2.4进度计划,工程网络前面介绍的Gantt图能很形象地描绘任务分解情况，以及每个子任务(作业)的开始时间和结束时间，因此是进度计划和进度管理的有力工具。它具有直观简明和容易掌握、容易绘制的优点，但是Gantt图也有三个主要缺点：不能显式地描绘各项作业彼此间的依赖关系；进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。,13.2.4进度计划,13.2.4进度计划,事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述三条简单规则：考虑进入该事件的所有作业；对于每个作业都计算它的持续时间与起始事件的EET之和；选取上述和数中的最大值作为该事件的最早时刻EET事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。按惯例，最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟时刻LET使用下述三条规则：考虑离开该事件的所有作业；从每个作业的结束事件的最迟时刻中减去该作业的持续时间；选取上述差数中的最小值做为该事件的最迟时刻LET。,13.2.4进度计划,关键路径p290关键路径上的事件(关键事件)必须准时发生，组成关键路径的作业(关键作业)的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。机动时间p290不在关键路径上的作业有一定程度的机动余地实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预计的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：机动时间=(LET)结束-(EET)开始-持续时间,13.2.4进度计划,规划软件团队结构应考虑下列7个项目因素：待解决问题的难度程序的规模团队成员需要共同工作的时间对问题分解的程度待开发系统的质量要求和可靠性要求项目交付日期的严格程度项目的沟通程度软件团队组织范式民主分权式：小组没有固定的负责人，问题和解决方法由小组讨论决策。个人偏爱自己管理员难以管理太民主的小组控制集权式：团队的顶层问题和组内协调由团队负责人管理。负责人和组员之间的沟通是上下级的。专业化层次性控制分权最基本的概念是取消团队负责人的大部分管理工作。,13.3人员组织,民主制程序员组小组成员完全平等，通过协商作出技术决策主程序员组有主程序员作为主要人员现代程序员组,13.3人员组织,一般说来，所谓控制就是掌握被控制的对象，不让它任意活动或超出规定范围活动，尽量使一切活动都按照预定的计划进行，向预期的目标前进。,13.4控制,13.4控制,风险管理风险有两个显著特点。不确定性：标志风险的事件可能发生也可能不发生，也就是说，没有100%发生的风险(100%发生的风险是施加在软件项目上的约束)。损失：如果风险变成了现实，就会造成不好的后果或损失。软件开发几乎总会存在某些风险。对付风险应该采取主动的策略，也就是说，早在技术工作开始之前就应该启动风险管理活动：标识出潜在的风险，评估它们出现的概率和影响，并且按重要性把风险排序，然后，软件项目组制定一个计划来管理风险。风险管理：是评定风险对决策影响的一次决策制定活动被动风险策略、主动风险策略风险管理的主要目标是预防风险，但是，并非所有风险都能预防，因此，项目组还必须制定一个处理意外事件的计划，以便一旦风险变成现实时能够以可控的和有效的方式作出反应。风险管理的3个阶段风险识别风险评估风险处理,13.4控制,软件风险分类1.按照风险的影响范围分类(1)项目风险(2)技术风险(3)商业风险,软件风险分类按照风险的影响范围分类项目风险技术风险商业风险按照风险的可预测性分类已知风险可预测的风险不可预测的风险,13.4控制,风险识别通过识别已知的和可预测的风险，项目管理者就朝着在可能时避免风险并且在必要时控制风险的目标迈出了第一步。在上面中描述的每一类风险又可进一步分成两种类型：一般性风险和特定产品的风险。一般性风险对每个软件项目都是潜在的威胁。特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。为了识别出特定产品的风险，必须检查项目计划和软件范围说明，并且回答下述问题：“本项目有什么特殊的性质可能会威胁我们的项目计划”。事实上，“如果你不主动地攻击风险，风险将主动地攻击你”。因此，应该系统化地识别出一般性风险和特定产品的风险。,13.4控制,采用建立风险条目检查表的方法，人们可以集中精力识别下列已知的和可预测的风险。产品规模与要开发或要修改的软件总体规模相关的风险。商业影响与管理或市场所施加的约束相关的风险。客户特性与客户素质以及开发者和客户定期通信的能力相关的风险。过程定义与软件过程已被定义的程度以及软件开发组织遵守软件过程的程度相关的风险。开发环境与用来开发产品的工具的可用性和质量相关的风险。所用技术与待开发系统的复杂性及系统所包含的技术的“新奇性”相关的风险。人员数目与经验与参加工作的软件工程师的总体技术水平及项目经验相关的风险。,13.4控制,风险评估风险评估(也称为风险估算)试图从两个方面来评估每个风险：风险变成现实的可能性或概率，以及当风险变成现实时所造成的后果。评估风险后果,13.4控制,建立风险表表中第4列给出的是风险后果的整体等级值，其中，1代表灾难性的，2代表严重的，3代表轻微的，4代表可忽略的。一旦填好了风险表前4列的内容，就应该根据概率和影响来排序。高概率、高影响的风险放在表的上方，而低概率的风险放在表的下方，这样就完成了第一次风险排序。项目管理者研究排好序的风险表，并确定一条中止线。该中止线是经过表中某一点的水平直线，它的含义是，只有位于线的上方的那些风险才会得到进一步的关注。对于处于线下方的风险要再次评估，以完成第二次排序。从管理的角度看，风险影响和风险概率的作用是不同的。对一个具有高影响但发生概率很低的风险因素，不应该花费太多管理时间。但是，高影响且发生概率为中到高的风险，以及低影响且高概率的风险，应该进入风险管理的下一个步骤。应该在软件项目进展的过程中，迭代使用上述的风险预测与分析技术。项目组应该定期复查风险表，再次评估每个风险，以确定新情况是否引起它的概率和影响发生变化。作为这项活动的结果，可能在表中添加了一些新风险，删除了某些与项目不再有关系的风险，并且改变了表中风险的相对位置。,13.4控制,13.4控制,处理风险的策略对于绝大多数软件项目来说，上述的4个风险因素(性能、成本、支持和进度)都有一个临界值，超过临界值就会导致项目被迫终止。也就是说，如果性能下降、成本超支、支持困难或进度延迟(或这4种因素的组合)超过了预先定义的限度，则因风险过大项目将被迫终止。如果风险还没有严重到迫使项目终止的程度，则项目组应该制定一个处理风险的策略。一个有效的策略应该包括下述三方面的内容：风险避免(或缓解)；风险最小化；意外事件计划。1.风险避免如果软件项目组采用主动的策略来处理风险，则避免风险总是最好的策略。这可以通过建立风险缓解计划来达到。2.风险最小化随着项目的进展，风险监控活动也就开始了。项目管理者监控某些能指出风险概率正在变高还是变低的因素。3.风险管理和意外事件计划意外事件计划假设缓解风险的努力失败了，风险变成了现实。,13.4控制,13.5质量保证,质量是产品的生命，不论生产什么产品，质量都是极端重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。软件质量概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。上述定义强调了下述的三个要点。软件需求是度量软件质量的基础，与需求不一致就是质量不高。指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。通常，有一组没有显式描述的隐含需求(例如，期望软件是容易维护的)。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。,图软件质量因素与产品活动的关系,13.5质量保证,13.5质量保证,13.5质量保证,可靠性、可用性、可维护性（Reliability,availability,maintainability）,定义（Definitions）为了了解我们所指的可靠性，可用性和可维护性，可以想想汽车。如果一辆车在大多数情况下都工作正常，我们就认为汽车性能可靠。我们知道，有些功能会停止使用，有些磨损的部件需要修理或替换，但是我们希望一辆可靠的车在需要维修之前工作一段很长的时间。因此，在两次维修之间能长时间段的、稳固的、正常的、另人满意地工作的汽车就是稳定的、可靠的。可靠性指一段时间的行为，但可用性是描述在某一给定时间上发生的事。一辆汽车可用是指当你需要它时，可以使用它。这辆车可能已使用20年了，且只维修了2次，我们称这辆车具有很高的稳定性。但是恰巧它在修理厂时你却需要它，它仍是不可用的。因此有些东西有很高的稳定性，当在某一时刻仍不可用。假设你的车既可靠又可用，但生产它的厂商已经关闭了。这意味着一旦你的车出了故障（无可否认，很少发生），维修商将很难找到可替换的部件。因此你的汽车在修好返回给你需要很长的时间，在这种情况下，你的车具有很低的可维护性。,13.5质量保证,可靠性、可用性、可维护性（Reliability,availability,maintainability）,我们讲的软件可靠性（softwarereliability）是指系统在给定条件下，在一段时间内无故障工作的概率。我们用01之间的数表示可靠性。软件的可用性（softwareavailability）是在一特定时间点上，系统按要求操作成功的概率。软件可维护性（softwaremaintainability）是指在给定使用情况下，在一个规定的时间间隔和使用规定的资源，规定的过程，维护活动完成的概率。同样它的范围也在0与1之间。和硬件维护有很大不同，硬件维护在执行时总是要求系统不可用，而软件维护在系统工作时也能做。,13.5质量保证,评估软件的可靠性、可用性、可维护性系统平均无故障时间MTTF平均维修时间MTTR修复一个故障平均需要用的时间，它取决于维护人员的技术水平和对系统的熟悉程度，也和系统的可维护性有重要关系。平均无故障时间MTTF是系统按规格说明书规定成功地运行的平均时间，它主要取决于系统中潜伏的错误的数目，因此和测试的关系十分密切。错误之间的平均时间MTBF：系统会有多长时间不可用MTBF=MTTF+MTTRReliabilityR=MTTF/(1+MTTF)AvailabilityA=MTBF/(1+MTBF)MaintainabilityM=1/(1+MTTR),13.5质量保证,估算平均无故障时间Et测试之前程序中的错误数It程序长度(机器指令总数)测试(包括调试)时间Ed()在0到期间发现的错误数Ec()在0到期间改正的错误数,13.5质量保证,估计错误总数的方法(1)植入错误法使用这种估计方法，在测试之前由专人在程序中随机地植入一些错误，测试之后，根据测试小组发现的错误中原有的和植入的两种错误的比例，来估计程序中原有错误的总数。假设人为地植入的错误数为Ns，经过一段时间的测试之后发现ns个植入的错误，此外还发现了n个原有的错误。如果可以认为测试方案发现植入错误和发现原有错误的能力相同，则能够估计出程序中原有错误的总数为N=*Ns其中即是错误总数的估计值。,13.5质量保证,(2)分别测试法怎样随机地给一部分错误加标记，分别测试法使用两个测试员(或测试小组)，彼此独立地测试同一个程序的两个副本，把其中一个测试员发现的错误作为有标记的错误。具体做法是，在测试过程的早期阶段，由测试员甲和测试员乙分别测试同一个程序的两个副本，由另一名分析员分析他们的测试结果。用表示测试时间，假设=0时错误总数为B0；=1时测试员甲发现的错误数为B1；=1时测试员乙发现的错误数为B2；=1时两个测试员发现的相同错误的数目为bc。,13.5质量保证,如果认为测试员甲发现的错误是有标记的，即程序中有标记的错误总数为B1，则测试员乙发现的B2个错误中有bc个是有标记的。假定测试员乙发现有标记错误和发现无标记错误的概率相同，则可以估计出测试前程序中的错误总数为使用分别测试法，在测试阶段的早期，每隔一段时间分析员分析两名测试员的测试结果，并且用(5.8)式计算B0。如果几次估算的结果相差不多，则可用B0的平均值作为ET的估计值。此后一名测试员可以改做其他工作，由余下的一名测试员继续完成测试工作，因为他可以继承另一名测试员的测试结果，所以分别测试法增加的测试成本并不太多。,13.5质量保证,软件质量保证措施软件质量保证(SoftwareQualityAssurance，通常缩写为SQA)的措施主要有，基于非执行的测试(也称为复审)、基于执行的测试和程序正确性证明。1.技术复审的必要性正式技术复审的明显优点是，能够较早地发现错误，防止错误被传播到软件过程的后续阶段。正式技术复审实际上是一类复审方法，包括走查(Walkthrough)和审查(Inspection)等具体方法。走查的步骤比审查少，而且没有审查那样正规。,13.5质量保证,2.走查(1)参与者驱动法参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答，要么承认确实有错误，要么对质疑做出解释。(2)文档驱动法文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。,13.5质量保证,3.审查审查的范围要比走查广泛得多，它的步骤也比较多。一般来说，审查有5个基本步骤。(1)综述：由负责编写文档的一名成员向审查组成员综述该文档。在综述会议结束时把文档分发给每位与会者。(2)准备：评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作的进行。这些列表有助于评审员们把注意力集中到最常发生错误的区域。(3)审查：评审组仔细走查整个文档。和走查一样，这一步的目的也是找出文档中的错误，而不是改正它们。审查组组长必须在一天之内写出一份关