第七讲软件项目管理(SoftwareProjectManagement)课件

第七讲软件项目管理（SoftwareProjectManagement）WelcometoSoftwareEngineeringLecture7目标了解软件项目管理者的主要任务；了解软件项目管理的特征及其和其他工程项目管理之间的区别；熟悉项目规划的概念及过程；掌握应用图形工具制作项目进度表的方法；了解软件成本的基本知识和COCOMO成本模型的基本原理；目标了解软件配置管理的重要意义；熟悉配置管理的主要活动，包括CM规划、变更管理、版本管理和系统构建。内容软件项目管理基础项目规划与调度软件成本估计

软件配置管理软件项目管理主要考虑如何保证软件能够按时、按计划并满足用户需求规格的交付，即如何用科学的管理手段保障软件项目的成功。软件项目管理是必要的活动，因为软件项目必然会受到时间和成本的约束，如何有效的利用时间与成本是不能仅凭工程分析与设计方法来解决的。1.软件项目管理基础软件产品是无形的；软件产品是易变的；软件开发过程不标准；很多软件项目都是“一次性”项目。软件项目管理的特点提出书面建议；项目规划与调度；项目成本计划；项目监督与评审；人员的选择与评价；书写并陈述工作报告。管理者的主要任务项目规划与调度；项目成本管理；项目监督与控制；人员管理。主要管理活动其他的管理活动质量管理配置管理风险管理过程改进2.项目规划与调度项目规划可能是项目管理活动中最为耗时的。有效的管理取决于全面的规划。在项目之初拟定的计划，应该成为整个项目的驱动器。管理者需要开发各种不同类型的计划来支持主要的软件项目活动。

2.1项目规划项目计划的类型项目规划过程EstablishtheprojectconstraintsMakeinitialassessmentsoftheprojectparametersDefineprojectmilestonesanddeliverableswhileprojecthasnotbeencompletedorcancelledloop Drawupprojectschedule Initiateactivitiesaccordingtoschedule Wait(forawhile)Reviewprojectprogress Reviseestimatesofprojectparameters Updatetheprojectschedule Re-negotiateprojectconstraintsanddeliverables if(problemsarise)then Initiatetechnicalreviewandpossiblerevision endifendloop项目计划项目计划通常包括：项目可用资源；工作分解；完成工作的进度安排。项目计划书的结构引言项目组织风险分析硬件和软件资源需求工作分解项目进度监控和报告机制活动组织项目中的活动应该被有效的组织以产生可见的切实的输出来使管理者得到评判项目进度的依据。里程碑

aretheend-pointofaprocessactivity.可交付文档areprojectresultsdeliveredtocustomers.软件需求过程的里程碑2.2项目调度这个管理活动中，管理者需要把项目分解成若干个任务，并估算每个任务完成所需要的时间与资源，然后按照一定的顺序把这些任务组织起来。应协调并行的任务，充分利用人力资源。要减少任务间的依赖，明确关键任务，保证按进度交付。项目调度过程条形图与活动网络图图形化的工具对说明项目进度是十分有用的。条形图可以表示每项活动的负责人以及该项活动的预计开始时间和结束时间。活动网络图标是构成一个项目的不同活动之间的依赖关系以及由开始到结束的关键活动路径。例：活动网络图的画法活动网络图条形图3.软件成本估计一个成功的项目应在不超预算的前提下按时交付。合理科学的估算对于项目管理者是至关重要的。3.1基本的估算问题估算通常要对以下问题做出回答：完成一个活动需要多少工作量？完成一个活动需要多少时间？活动的总成本是多少？项目估算与项目进度安排通常是一起进行的。软件成本的构成硬件和软件成本差旅费和培训费用工作成本(thedominantfactorinmost

projects)项目开发人员的薪水;社会保障和员工福利。经常性的管理费用办公场所、供暖和照明费用；网络和通信费用；图书馆、员工餐厅等方便设施的费用。3.2估算技术对开发软件系统工作量的精确估算，没有一种简单的方法。初始估算根据用户的不完全的需求定义做出；软件可能运行在抹些特殊的计算机上或需要运用新的开发技术；对项目开发人员的技术水平可能一无所知。所以，在开发过程早期对开发成本进行精确估算是相当困难的。估算技术自顶向下估算自底向上估算算法成本建模专家判定类比估算自顶向下估算自顶向下估算法，通常应用类比法从项目的整体出发，进行类推，即估算人员根据以往完成的类似项目所消耗的总工作量，来推算将要开发的软件的总工作量；然后，按比例将它分配到各个开发任务单元中，这就是所谓的自顶向下估算。自顶向下法是基于以往项目的经验，简单易行，但准确性差，常用于我们前面提到的项目的初期。自底向上估算自下向上估算法就是利用任务分解结构图（WBS），对各个具体的工作包进行详细的工作量估算，然后将结果累加起来得到项目总工作量。这种方法最为准确，但比较耗时耗力，通常与类比法和参数法结合使用。算法成本建模Costisestimatedasamathematicalfunctionofproduct,projectandprocessattributeswhosevaluesareestimatedbyprojectmanagers:Effort=A*SizeB

*

MAisanorganisation-dependentconstant,BreflectsthedisproportionateeffortforlargeprojectsandMisamultiplierreflectingproduct,processandpeopleattributes.COCOMO成本模型Anempiricalmodelbasedonprojectexperience.Well-documented,‘independent’modelwhichisnottiedtoaspecificsoftwarevendor.Longhistoryfrominitialversionpublishedin1981(COCOMO-81)throughvariousinstantiationstoCOCOMO2.COCOMO81专家判定为了较少个人偏见的影响，专家估算法通常有多位专家进行估算，取得多个估算值，最后得出综合的估算结果。专家估算法中最著名的是Deilphi方法，其基本步骤如下：1）

组织者发给每一位专家一份软件系统的规格说明和一张记录估算值的表格，请他们估算。2）

专家详细的研究软件规格说明之后，对该软件提出3个规模的估算值。l

最小值ail

最可能值mil

最大值bi3）

组织者对专家表格中的答复进行整理，计算每位专家的平均值Ei=(ai+4mi+bi)/6，然后计算出期望值：E=(E1+E2+…..+En)/n。4）

综合结果后，再组织专家无记名填表格，比较估算偏差，查找原因。5）重复上述过程多次，最终可以获得一个多位专家共识的软件估算。专家判定类比估算

类比法的使用也称作基于案例的推理。估计人员从已完成的项目（源案例）中找出与新项目（目标案例）有相似特征的项目，然后将匹配的原案例已经纪录的工作量作为目标案例的估计基础，接着标识出目标案例和源案例的所有不同之处，并对新案例的基本估计做出判断和修订。在选择类似项目时，我们可以通过标识项目之间的欧几里德距离来识别与待开发系统最为接近的类似项目。计算欧几里德距离，首先要定义老项目与新项目的类似特征的参数，然后依据公式：欧几里德距离=[（目标参数1-源参数1）2+…..+（目标参数n-源参数n）2]1/2

类比估算举一个简单的例子：假设要匹配的两个项目仅基于两个参数，输入和输出，已知新项目有7个输入和15个输出，过去有两个项目A和B，项目A有8个输入和17个输出，项目B又5个输入和11个输出，那麽，A与目标项目之间的欧几里德距离是[(7-8)2+(15-17)2]1/2=2.24，项目B与目标项目之间的欧几里德距离是[(5-7)2+(11-15)2]1/2=4.47，对比这两个数值，我们可以知道项目A比项目B更接近于我们的新项目。

类比估算对于类比法，我们可以灵活运用。我们可以把它与自顶向下法结合，得到项目总工作量的类比估计，也可以把它与自下向上法相结合，把WBS分解得到的任务模块与以往做过的类似模块比较，得到该模块的工作量估计，在把模块的工作量进行汇总得到总工作量。后者的估算精度比前者要高。类比估算3.3成本估算总结除上述的几种估算方法以外，还有功能点分析法和猜测法。在实际软件项目中，类比法、自下而上法和参数法是最常用的三种估算方法，其中自下而上法比较费时费力，参数法和类比法比较简单，参数法的估计精度较高，三者常结合使用，类比法常被用来验证自下而上法和参数法的结果。一种实际应用的估算过程对任务进行分解得到任务分解结构WBS估算每个任务的最大值max、最小值min和平均值avg计算每一个任务的估算值Ei=(max+4avg+min)/6计算项目工作量估算值E=E1+E2+…..+En软件系统总是出现变更，这就带来新版本软件的产生，引起版本变化的原因通常包括：变更建议和错误的修正；对不同的硬件与操作系统做出的适应性调整；提供不同的功能；按用户特定需求进行的修正。配置管理规程规定了如何记录和处理所提议的变更，如何使系统变更与系统组件相关联，以及如何识别系统不同版本的方法。CM的目的在于控制由变更带来的成本和人力消耗。4.配置管理配置管理配置管理设计开发和应用规程与标准去管理一个进化中的软件产品。CM有时被认为是更广泛的软件质量管理的一部分。当一个软件系统被置于配置管理之下，我们把它叫做“基线”（baselines），应为他们是受控进化的一个起点。配置管理规划描述配置管理应该使用的标准和规程。所有的软件产品都应该置于CM控制之下：Specifications;Designs;Programs;Testdata;Usermanuals.4.1配置管理规划配置管理规划包括以下内容：定义配置项以及使用什么模式来识别配置项；确定谁负责CM规程并把配置项提交给CM团队；定义变更控制和版本管理的策略；定义必须被维护的CM记录；描述CM使用的工具和使用这些工具的过程；描述配置数据库的结构既要维护的数据信息；对外协提供的软件的管理和CM规划对CM过程的审核过程。配置管理规划Largeprojectstypicallyproducethousandsofdocumentswhichmustbeuniquelyidentified.Documentnamingschemeshouldbedefined

sothatrelateddocumentshaverelatednames.Ahierarchicalschemewithmulti-levelnamesis

probablythemostflexibleapproach.PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE配置项识别配置层次AllCMinformationshouldbemaintainedina

configurationdatabase.Thisshouldallowqueriesaboutconfigurationstobe

answered:Whohasaparticularsystemversion?Whatplatformisrequiredforaparticularversion?WhatversionsareaffectedbyachangetocomponentX?HowmanyreportedfaultsinversionT?HowmanyreportedchangerequestsinversionT?TheCMdatabaseshouldpreferablybelinkedtothesoftwarebeingmanagedthroughintegratedwithversionmanagementtools.

配置数据库软件在生命周期内会接受来自各方面的变更请求：Fromusers;Fromdevelopers;Frommarketforces.变更管理的主要目的使通过对变更的跟踪和控制是变更实现的代价最小，效果最好。4.2变更管理变更管理过程对变更申请表的定义应该是CM规划过程的一部分。变更申请表除了记录需要的变更之外，还要记录变更的建议者，变更的原因和变更的紧密程度。CRF还要记录变更的成本估算，冲突的分析，变更的请求、核准、实现和验证日期等内容。变更申请表（CRF）的格式变更申请表（CRF）的格式变更控制委员会（CCB）是做出变更决策的极为重要的一个部门。CCB应独立于软件开发组织之外，由资深的客户和承包商职员组成。CCB应从战略的角度，而不是从技术的角度去考虑变更带来的影响。变更控制委员会（CCB）组件变更时，每个组件爱你的变更记录都应该得到维护，有时把这成为组件的导出历史。维护这种记录最佳的方式是在组件开始部分的标准注释部分说明它。导出历史应该建立变更请求到软件变更的链接。导出历史例：组件题头信息Inventanidentificationschemeforsystem

versions.Planwhenanewsystemversionistobe

produced.Ensurethatversionmanagementproceduresandtoolsareproperlyapplied.Plananddistributenewsystemreleases.4.3版本和发布管理（自学）VersionAninstanceofasystemwhichis

functionallydistinctinsomewayfromother

systeminstances.Variant

Aninstanceofasystemwhichis

functionallyidenticalbutnon-functionally

distinctfromotherinstancesofasystem.ReleaseAninstanceofasystemwhichis

distributedtousersoutsideofthedevelopmentteam.Versions/variants/releasesVersionidentificationProceduresforversionidentificationshoulddefineanunambiguouswayofidentifyingcomponentversions.TherearethreebasictechniquesforcomponentidentificationVersionnumbering;Attribute-basedidentification;Change-orientedidentification.SimplenamingschemeusesalinearderivationV1,V1.1,V1.2,V2.1,V2.2etc.Theactualderivationstructureisatreeoranetworkratherthanasequence.Namesarenotmeaningful.Ahierarchicalnamingschemeleadstofewererrorsinversionidentification.VersionnumberingVersionderivationstructureAttributescanbeassociatedwithaversionwith

thecombinationofattributesidentifyingthat

versionExamplesofattributesareDate,Creator,

ProgrammingLanguage,Customer,Statusetc.Thisismoreflexiblethananexplicitnamingscheme

forversionretrieval;However,itcancauseproblemswithuniqueness-thesetofattributeshavetobechosensothatallversionscanbeuniquelyidentified.Inpractice,aversionalsoneedsanassociatednameforeasyreference.Attribute-basedidentificationAttribute-basedqueriesAnimportantadvantageofattribute-basedidentificationisthatitcansupportqueriessothatyoucanfind‘themostrecentversioninJava’etc.ThequeryselectsaversiondependingonattributevaluesAC3D(language=Java,platform=XP,date=Jan2003).Change-orientedidentificationIntegratesversionsandthechangesmadetocreatetheseversions.Usedforsystemsratherthancomponents.Eachproposedchangehasachangesetthatdescribeschangesmadetoimplementthatchange.Changesetsareappliedinsequencesothat,inprinciple,aversionofthesystemthatincorporatesanarbitrarysetofchangesmaybecreated.Releasesmustincorporatechangesforcedonthesystembyerrorsdiscoveredbyusersandbyhardwarechanges.Theymustalsoincorporatenewsystem

functionality.Releaseplanningisconcernedwithwhento

issueasystemversionasarelease.ReleasemanagementSystemreleasesNotjustasetofexecutableprograms.Mayalsoinclude:Configurationfilesdefininghowthereleaseisconfiguredforaparticularinstallation;Datafilesneededforsystemoperation;Aninstallationprogramorshellscripttoinstallthesystemontargethardware;Electronicandpaperdocumentation;Packagingandassociatedpublicity.Systemsarenownormallyreleasedonopticaldisks(CDorDVD)orasdownloadableinstallationfilesfromtheweb.Customermaynotwantanewreleaseofthe

systemTheymaybehappywiththeircurrentsystemasthenewversionmayprovideunwantedfunctionality.Releasemanagementshouldnotassumethatallpreviousreleaseshavebeenaccepted.Allfilesrequiredforareleaseshouldbere-createdwhenanewreleaseisinstalled.ReleaseproblemsReleasedecisionmakingPreparinganddistributingasystemreleaseisanexpensiveprocess.Factorssuchast