软件工程基础之08-软件项目管理

第八章软件项目管理项目管理定义1风险管理4项目计划3项目度量2小结5软件项目管理定义：计划、协调、度量、监控、控制及报告等管理方法在软件开发和维护中的具体应用，以保证整个过程是系统的、有原则的、可量化的(IEEE610.12-90)。软件项目管理的四大要素•有效的软件项目管理集中在四个“P”：o人员(People)：关键业务领域：人员配备、沟通与协调、工作环境、业绩管理、培训、报酬、能力素质分析与开发、个人事业发展、工作组发展、团队精神和企业文化等。o产品(Product)：在策划一个项目以前，应当首先确定产品的目标和范围，还应考虑备选方案，供管理者和开发人员根据约束条件选择“最好”方案，约束条件包括：交付期限、预算限制、可用人员、技术接口等。o过程(Process)：软件开发的一个全面计划。框架、任务集合、普适性活动（QA、配置、测量等）。o项目(Project)：理解成功项目管理的关键因素，掌握项目计划、监控和控制的一般方法。1998-2004调查，10%符合计划。重要性人员•一个项目管理的成功与否，最重要的要素是团队的建设和管理，也就是人。•人力资源管理成熟度模型（PCMM）oPCMM是通过对人力资源管理的如人力资源规划、薪酬管理、绩效管理、组织管理、职业规划、培训管理、知识管理等模块，按初始级、重复级、定义级、定量级和优化级述五个递进层级进行详细描述和分级，建立企业人力资源管理的成熟程度评价模型，以此来对企业目前人力资源管理现状进行评级，寻找不足和差距，以此来明确未来的发展方向。团队成长形成forming震荡storming正规norming表现performing高低工作绩效团队精神时间人员•了解利益相关者：•高级管理者：业务定义者•项目（技术）管理者•开发人员•客户：需求来源和项目成败相关人员•最终客户：直接与软件交互的人•团队负责人特质：•激励：最重要，但无完整理论框架•组织能力•思想或创新：在约束下创新•解决问题能力•管理能力：掌控项目、允许个性•成就：奖优容错•影响和队伍建设：“理解”人，适度调整，高压下保持控制能力•团队负责人任务：用人扬长避短，培训知识、技能，但人格无法改变人员•团队建设：•封闭式范型：传统权利层次组织团队，擅于做过的相似软件开发，创新性弱。•随机式范型：松散组织，依赖成员主动性，创新性强，有序执行力弱。•开放式范型：封闭式控制，随机式方式组织，良好的沟通、集体决策，适合解决复杂问题，效率不高。•同步式范型：成员独立工作、交流少。•敏捷团队：自组织团队，拥有制定计划和技术决定自主权。强调个人能力和团队协作精神相结合。•如果你要做的更好，那就竞争，如果你要的非常好，那就要合作。产品•1、确定软件范围：•项目环境：业务环境、适应性、约束•信息目标：输入输出是什么？•功能和性能•2、问题分解：分而治之过程•1、选择过程框架•与产品内容合并，给出任务集合•2、过程分解项目•1、在正确的基础上开始工作•2、保持动力•3、跟踪进展•4、做出英明的决策•5、进行事后分析项目管理原则•为什么（Why）开发这个系统：项目价值•需要做什么（What）:项目任务集•什么时候做（When）:进度、里程碑•谁来做（Who）：团队成员角色和责任•位置（Where）：利益相关者也有责任•如何完成（How）：管理策略、技术策略•需要多少资源（Howmuch）：项目估算软件度量软件产品度量的定义•含义o一种量化衡量方法,使得人们可以理解和把握软件项目的(生产)效率(或者所需要的劳动量)•目的o描述（项目和过程）o评估（状态和质量）o预测（为计划）o改进（产品质量和过程性能）改进软件质量和组织绩效的决定因素产品技术人员过程客户特征业务条件开发环境关键因素：过程、人员、产品、技术过程处于三角的中心，连接其它三个因素软件测量o直接测量：如在一个特定时间内产生的代码行数（LOC）•一定时间产生的代码行数•执行速度•文件页数•错误和缺陷数o间接测量：如一个给定时间内生产出的功能点（FP）和目标点•功能性•可靠性•可维护性•复杂性•效率•其它质量指标直接测量—基于规模的度量•一个基于规模的度量的例子面向规模的度量标准每KLOC（千行代码）的错误数每KLOC（千行代码）的缺陷数每KLOC（千行代码）的成本每KLOC（千行代码）的文档页数生产率=？其他：每人月错误数每人月千行代码数每页文档的成本，基于代码行的度量方法的优缺点•优点oLOC、KLOC和相关度量容易计算o许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入o有大量的关于LOC的文献和数据•缺点oLOC依赖于使用的语言，这对短小精悍的程序不利o不太适用于非过程化语言oLOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得，例如，项目计划人员难于在分析和设计完成之前估算LOC间接测量—功能点度量•功能点数从直接度量软件信息域和评估软件复杂性的经验量化关系中获得•步骤：o先算总计数total_countso再算功能点FP间接测量—功能点度量•识别信息域参数：以外贸订单系统为例•外部输入数（EI）：从用户或其他系统来的外部输入，用于更新内部逻辑文件。录入订单、修改订单、删除订单。•外部输出数（EO）：系统中输出，为用户提供信息。如报告、屏幕、错误信息等，非报告中的单独数据项。查询订单。•外部查询数（EQ）：从在线输入到在线输出结果的方式产生某个即时软件相应，经常从内部逻辑文件中得到。统计订单•内部逻辑文件数（ILF）：一组以用户角度识别的，系统内维护的逻辑相关数据或控制信息。主要目的是通过应用程序的一个或多个基本处理过程来维护数据。订单和客户。•外部接口文件数（EIF）：一组由其他系统维护的ILF，以用户角度识别的，为本系统提供使用的逻辑上相关的数据。EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。汇率查询转换系统间接测量—功能点度量•计算总计数加权因数：由经验确定外部输入数外部输出数外部查询书内部逻辑文件数外部接口文件数总计数间接测量—功能点度量•例子：间接测量—功能点度量•计算功能点（FP）total_counts：总计数Fi(i取1到14)：复杂性调整值(_)(0.650.01))iFPtotalcountsFFi的取值含义0没有影响1偶有影响2轻微影响3平均影响4较大影响5严重影响复杂性调整值基于下列问题，每个问题可用从0到5（绝对必需）的值。1.系统需要可靠的备份和恢复么？2.需要进行数据通信么？3.有分布式处理功能么？4.性能重要么？5.将该系统运行在一个现有的操纵系统中么？6.系统要求在线输入数据么？7.在线输入数据要求在多个屏幕和操作之间建立输入事务么？复杂性调整值8.主文件是否在线更新？9.输入、输出、文件或查询是否复杂？10.内部处理是否复杂？11.代码是可重用的么？12.设计中包括数据（流程）转换或安装么？13.系统要为不同的机构设计不同的安装方法么？14.应用程序便于变更么？易于用户使用么？将每个选项的取值求和，得到∑Fi，计算0.65+0.01×∑Fi,得到复杂度调整因子计算上例的FP功能点度量—间接测量•功能点计算o每FP的错误数，即总的错误数除以总的FP数。o每FP的缺陷数，即总的缺陷数除以总的FP数。o每FP的文档页数，即总的文档页数除以总的FP数。o每人月的FP数，即总的FP数除以总的人月数基于LOC度量和基于FP度量的关系•代码行数和功能点之间的关系依赖于编程语言改进：利用历史数据建立基线，进行比较改进利用度量方法进行生产率估计的问题•问题o某个小组的LOC/人月（或FP/人月）的数据应该和另一个组的相比么？o项目经理应该使用这些度量方法来评价个人表现么？•对策o谨慎使用生产率度量，因为有很多因素可能影响生产率面向对象的度量•可用LOC和FP，也有一些其他的度量方法•建立指标测量，结合耦合、内聚、继承等性质加权计算。•常用指标•场景脚本的数量(用例)•关键类的度量：解决问题域的核心•支持类的数量(实现系统所必需的但又不与问题域直接相关的类)•每个关键类的平均支持类数量(分析类)•子系统的数量(实现某个功能的类的集合，该功能对系统最终用户可见)•花费的工作量、发现的错误和缺陷、建立的模型和文档等项目测量数据一起收集分析。项目工作量度量有哪些经验公式？……软件成本估算模型-基于经验的度量找到软件工作量的各种成本影响因子，并判断他们对工作量的影响是可加的、乘数的还是指数的，以期得到最佳的模型算法表达方式Effort=A+SizeB*MSize可以是软件代码规模的估算，也可以是功能点、目标点等。算法成本估算的例子050100150200250300123456789101112SizePMSize：项目规模PM：工作量（人月）不同软件开发阶段的估算的不确定性可行性需求设计编码交付4xx2x0.5x0.25x在软件过程的推进过程中，可利用的信息越多，估算的精确度越高COCOMO模型•COCOMO(构造性成本模型)是一个经验模型,通过收集大量的软件项目的数据而获得•好处o它已得到广泛的证明。可用于公共领域并且很多公共和商业工具都支持它。o它应用广泛，并得到了不同组织的评价。o它有较长的历史，于1981年第一次实例化[Boehm,1981]，为了适用于Ada进行了一次改进[BoehmandRoyce,1989]，最新版本COCOMOII发布于2000年[Boehmetal.,2000]。o分为三种模型：o基本模型：项目信息极少的情况下使用o中等模型：需求分析完成后使用o详细模型：系统设计完成后使用Effort=a*SizeB*Fa,b为系数Size为千行代码数F为调整因子基本的COCOMO模型•基本COCOMO模型的工作量和进度公式•F=1•项目类型工作量进度组织型MM=2.4（KDSI）1.05TDEV＝2.5（MM）0.38半独立型MM＝3.0（KDSI）1.12TDEV＝2.5（MM）0.35嵌入型MM＝3.6（KDSI）1.20TDEV＝2.5（MM）0.32MM:软件开发所需人月KDSI:千行代码数TDEV:以月为单位的开发进度项目类型:区别在于约束的严格程度，组织型最宽松估算示例•中等模型：F为15个成本因子对应的工作量乘数的乘积估算示例详细模型：F为15个成本因子对应的工作量乘数的乘积将待估算的软件分解为模块、子系统、系统三个等级增加了与开发阶段相关的工作量乘数，可以准确反映成本驱动因子对工作量阶段分布的影响RPD：需求与产品设计DD：详细设计CUT：编码与单位测试IT：集成与测试估算示例•DuBridge化学品公司是一家大型化工产品公司，公司计划开发一个新的计算机程序，用以跟踪原材料的使用情况。这个程序由一个公司内部的程序员和系统分析员组成的团队负责开发，他们已有多年类似程序的开发经验。•这是一个组织型软件项目开发的很好实例•最初的研究确定程序的规模大约是32000条交付的源指令（32KDSI）•数量FSP（Full–time–equivalentSoftwarePersonnel）代表的是相当于全职的软件人员，用以度量在某一给定时间为某项目工作的等价人员数•只有代码数信息，应用基本COCOMO模型，可估算出项目的如下特征：o工作量MM=2.4（32）1.05=91人月o生产率32000DSI/91MM=352DSI/MMo进度TDEV=2.5（91）0.38=14个月o平均配置人员91人月/14个月=6.5FSPCOCOMOII模型•COCOMOII模型引入对产品、硬件、人员及项目属性的客观评价）三个子模型1、应用组合模型：基于对象点对采用集成计算机辅助软件工程工具快速应用开发的软件工作量和进度进行估算，用于项目规划阶段。2、早期设计模型：基于功能点或代码行，以及5个规模指数因子、7个工作量乘数因子，选择体系结构和操作，用于信息还不足以支持详细的细粒度估算阶段。3、后体系结构模型：发生在软件体系结构完全定义和建立之后，基于功