软件项目管理(Software Project Management)_第1页
软件项目管理(Software Project Management)_第2页
软件项目管理(Software Project Management)_第3页
软件项目管理(Software Project Management)_第4页
软件项目管理(Software Project Management)_第5页
已阅读5页,还剩81页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第八讲软件项目管理(SoftwareProjectManagement)WelcometoSoftwareEngineeringLecture8ZhangJiannanjiannanz@163.com目标了解软件项目的基本概念及管理者的主要任务;了解软件项目管理的特征及其和其他工程项目管理之间的区别;熟悉项目策划的概念及任务过程;了解软件成本的基本知识和基本的估算方法;掌握应用图形工具制作项目进度表的方法;目标了解软件质量的影响因素及CMM基本概念。了解软件配置管理的重要意义;了解配置管理中CM规划、变更管理等主要活动;了解人员管理的基本内容与方法。内容软件项目管理基础软件项目策划与估算软件进度安排软件质量管理与CMM软件配置管理软件人员管理软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理主要考虑如何保证软件能够按时、按计划并满足用户需求规格的交付,即如何用科学的管理手段保障软件项目的成功。软件项目管理是必要的活动,因为软件项目必然会受到时间和成本的约束,如何有效的利用时间与成本是不能仅凭工程分析与设计方法来解决的。1.软件项目管理基础软件项目管理与其它的工程项目管理相比有其自身的独特性:软件产品是无形的;软件产品是易变的;软件开发过程不标准;很多软件项目都是“一次性”项目。软件项目不同于其它普通的工程项目,它属于智力密集型活动,其中,人员、抽象的文档和程序代码是管理的主要对象。因此,在实践中,软件工程管理人员不能照抄照搬,应做到因地制宜,确保管理行为具有针对性。软件项目管理的特点Pressman认为有效的软件项目管理集中在4个P上,即:人员(People)—“人的因素”是成功软件项目中最为重要的因素;产品(Product)—产品的目标与范围,成本与开发约束是划分项目任务,制定项目进度的依据;过程(Process)—软件过程提供了完成特定软件项目所需的框架活动和开发任务的集合;项目(Project)

—把软件置于有计划的、可控的项目之中,是保证其成功的唯一途径。软件项目管理中的4P’s项目策划与估算;项目进度安排;项目监督与控制;人员管理;质量管理;配置管理;风险管理;过程改进。主要管理活动2项目策划与估算

软件项目管理从一组统称为项目策划(projectplanning)的活动开始。项目策划的目标是建立一个能够对复杂的技术项目进行控制、跟踪和监测的有效策略,这个策略是在对资源、成本和进度做出合理估算的基础上做出的。

有效的项目管理取决于全面的项目策划。在项目之初拟定的计划,应该成为整个项目的驱动器。2.1

项目策划项目策划任务集确定项目范围;确定可行性;分析风险;确定所需的资源:确定需要的人力资源;确定可复用的软件资源;标识环境资源。项目策划任务集估算成本和工作量:分解问题;使用规模、功能点、过程任务或用例等方法进行两种以上的估算;调和不同的估算。制定项目进度计划:建立一组有意义的任务集合;定义任务网络;使用进度计划工具指定时间表;定义进度跟踪机制。WriteitDown!SoftwareProjectPlanProjectScopeEstimatesRisksScheduleControlstrategy什么是“范围”?“软件范围”描述了:交付给最终用户的软件功能与特征;输入和输出的数据;使用软件时要呈现给用户的“内容”;用于界定系统的性能、约束条件、接口和可靠性。范围可以使用以下两种方法定义:在于共同利益者交流之后得到对软件范围的叙述性描述;由最终用户开发一组用例。资源2.2项目估算合理科学的项目估算对于项目管理是至关重要的,要得到理想的估算结果必须注意:必须理解项目的范围;进行项目分解是必要的;历史信息是十分有用的;至少采用两种不同的技术进行估算;不确定性是软件估算的天然属性。软件项目的成本构成硬件和软件成本差旅费和培训费用工作成本(thedominantfactorinmost

projects)项目开发人员的薪水;社会保障和员工福利。经常性的管理费用办公场所、供暖和照明费用;网络和通信费用;图书馆、员工餐厅等方便设施的费用。估算技术根据已完成的类似项目进行估算(类比估算);传统估算技术:

任务分解与成果估算;

规模(如F.P)估算。经验模型(参数估算);自动化估算工具。估算精确度估算精确度取决于:计划者对产品规模估计的准确程度;把产品规模转换成人的工作量/人力成本的准确度;对软件团队能力的正确估计;软件产品需求与环境的稳定性。任务分解任务分解结构(WBS)软件范围描述进行“文法解析”传统估算方法:LOC/FP方法在得到软件的任务分解结构(WBS)后,可以分别估计每个功能的LOC或FP,从而估计出软件的整体规模。在估算过程中可以采用历史数据进行类比估算。估算人员通常要为每个功能分别估算一个乐观值(Sopt)、可能值(Sm)和悲观值(Spess),然后加权计算规模估计值S:S=(Sopt

+4

Sm+Spess)/6例:LOC方法该类系统的平均生产率=620LOC/pm;平均工资=$8000/月;每行代码的成本约$13;根据LOC估算与历史生产数据得到总成本约431000美元,工作量约54人.月。例:FP方法FP的估计值: FPestimated=321X[0.65+0.01X

Σ(Fi)] FPestimated=375组织平均生产率=6.5FP/pm.劳力价格=$8000permonth,每个FP成本约为$1230.根据FP估算与历史生产数据得到总成本约461000美元,工作量约58人.月。基于过程的估算从“过程框架”中获得框架活动(沟通、策划、风险分析、工程和构造发布)软件功能框架活动针对每个软件功能,估算完成各个过程活动所需的工作量(人.月)基于过程估算的实例如果平均一个劳力的价格是8000美元/月,则项目的总成本约为368000美元,总工作量约为46人.月。经验估算模型Generalform:effort=tuningcoefficient*sizeexponentusuallyderivedasperson-monthsofeffortrequiredeitheraconstantoranumberderivedbasedoncomplexityofprojectusuallyLOCbutmayalsobefunctionpointempiricallyderivedCOCOMO-IICOCOMO(构造成本模型)是由BarryBeohm提出的一种层次结构估算模型,是业内最广泛使用和讨论的经验估算模型。COCOMOII也是一种层次结构估算模型,主要应用于以下领域:应用组装模型。在软件工程早期使用,这时,用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的;早期设计阶段模型。在需求已经稳定并且基本的软件体系结构已经建立时使用;体系结构后阶段模型。在软件构造过程中使用。软件方程式软件方程式是一种多变量模型,它假定在软件开发项目的整个生命周期中有特定的工作量分布。 E=[LOCxB0.333/P]3x(1/t4) 其中: E=工作量,人.月或人.年 t=项目持续时间,以月或年为单位 B=“特殊技能因子”

P=“生产率参数”3项目进度安排(调度)这个管理活动中,管理者需要把项目分解成若干个任务,并估算每个任务完成所需要的时间与资源,然后按照一定的顺序把这些任务组织起来。应协调并行的任务,充分利用人力资源。要减少任务间的依赖,明确关键任务,保证按进度交付。项目调度过程活动网络图与甘特图图形化的工具对说明项目进度是十分有用的。活动网络图方法PERT(ProgramEvaluationandReviewTechnique),是美国海军和洛克希德公司60年代初发展起来的一种先进的管理技术。在国民经济中已经广为应用,并且受到用户的好评。

活动网络图表示构成一个项目的不同活动之间的依赖关系以及由开始到结束的关键活动路径。例:活动网络图的画法活动网络图甘特图是以水平线段表示每一项任务,线段的起始点表示任务的开始,结束点表示任务的结束,线段的长度表示任务的完成时间。甘特图的优点是简单明了,清楚地从图上看出任务时间上的对比关系,非常直观方便。它的缺点是各个任务之间的逻辑关系无法表示清楚。甘特图甘特图4软件质量管理

近些年来,软件人员正不懈的追求软件质量,虽然付出了巨大的努力,但是收效甚微。于是,大部分软件企业试图通过壮大软件测试队伍,希望通过加大测试力度来提高软件质量,然而,软件测试不能从根本上提高软件质量。究其原因,人们似乎对于软件质量的概念和内涵并不是很清楚,就更谈不上采取有效的方法提高软件的质量。我们认为,实施软件质量管理是软件开发过程不可缺少的一个重要环节。传统上,人们对软件质量的评价参数包括软件功能是否齐全、结构是否合理和层次是否分明等方面。不难发现,这些评价的描述是含糊不清的,不能对软件的质量做定性的分析。不精确的软件评价给用户和软件开发人员均带来消极作用,对用户而言,没有明确的软件评价,用户就没有选购软件的依据;同时,软件开发人员没有软件质量的评价标准,在软件的开发过程中就无“法”可依。因此,软件质量评价标准的制定有其必要性,也有重要意义。软件质量及其评价美国的B.W.Boehm和R.Brown提出了三个层次的评价度量模型,三个层次分别是软件质量要素、准则和度量。在此,仅对第一层次——软件质量要素作简单介绍。软件质量及其评价把软件质量分解成六个要素,通过如下的六个要素来评判软件质量:1.功能性:软件功能来源于软件的用户需求,用户需求分为显性需求和隐性需求,隐性需求泛指用户潜在的却不能陈述的软件需求;功能性是软件满足用户需求的程度描述。软件质量要素2.可靠性:软件可靠性包含两个方面的内容,一是软件在规定的运行环境下正常工作的程度;二是软件在非法操作或故障发生时继续运行的程度。软件可靠性在软件工程中具有较大的实际意义,可靠性差的软件在故障发生时不能正常运行,这将使得软件功能丧失。在必要时,可以建立软件保障系统,从根本上提高软件可靠性。软件质量要素3.易使用性:易使用性的内容包括软件用户界面的友好性和软件交互性,交互性和友好性是衡量软件使用是否方便的两个重要参数。4.效率:软件效率指软件运行时对所需的计算机资源利用的有效程度,软件效率的衡量通常从时间和存储需求两方面入手。软件质量要素5.可维护性:软件的可维护性是指用户需求改变或软件环境发生变更时,软件系统能进行相应修改的容易程度,可维护性一般与软件的可读性、可理解性和可修改性相关。软件质量要素6.可移植性:可移植性指软件整体或部分对运行的系统和环境的依赖程度,依赖程度越高,软件可移植性越差。软件质量要素虽然软件企业没有停止对软件质量的追求,但是事实表明他们并没有在提高软件质量方面取得突破性进展。软件质量问题的根源总的来说,较多质量不高的软件在软件开发中存在以下几点共性:缺乏软件产品检验标准,开发人员在提高软件质量上还具有一定盲目性;软件开发人员缺乏质量意识;软件项目时间短、计划紧;软件项目资金不足,开发方降低开发成本;没有有效的软件项目管理体制。软件质量问题的根源(一)CMM概念CMM(CapabilityMaturityModelforSoftware),英文缩写名是SM-CMM,它指“软件能力成熟度模型”,CMM是美国卡内基—梅隆大学软件工程研究所(简称SEI)的研究成果;SEI是美国国防部出资于1984年设立。软件质量与CMM从1986年开始,SEI针对软件组织改善其软件过程,特别是美国国防部对软件承包商的能力评价问题,研究“过程成熟度框架”。1987年9月,SEI发表了关于过程成熟度框架的简要说明和成熟度调查问卷。以这一过程成熟度框架为蓝本,在美国联邦政府促进下,从1987年到1991年在美国一些大公司的软件组织进行了软件过程能力成熟度模型的评估实践。(一)CMM概念根据这4年的实践经验,特别是从美国政府和工业界反馈的关于软件过程评估的信息,SEI在原过程成熟度框架的基础上开发出了“软件能力成熟度模型(CMM)1.0版”。SEI给CMM下的定义是:对于软件组织在定义,实现,度量,控制和改善其软件过程的进程中各个发展阶段的描述。(一)CMM概念这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键问题,从而为选择过程改进战略提供指南。SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架,它基于过去所有软件工程成果的过程改善的框架,吸取了以往软件工程的经验教训。它指明了一个成熟的软件组织在软件开发方面需要管理的那些主要工作、这些工作之间的关系、以及以怎样的先后次序,一步一步的做好这些工作使软件组织走向成熟,是目前国际上最流行也是最实用的软件生产过程标准。

(一)CMM概念SW-CMM为软件企业的过程能力提供了台阶式结构,共分五级,分别是初始级、可重级、定义级、管理级和优化级。初始级实际上是一个起点,任何准备按CMM结构进化的企业一般都处于这个起点上,并通过这个起点向可重级迈进。除初始级外,每一级都设定了一组目标,如果达到了这组目标,则表明达到了这个成熟级别,可以向下一个级别迈进。CMM从可重级起,每一个低的级别实现均是高的级别实现的基础,所以它不主张级别跨越。(二)CMM结构SW-CMM提供阶梯式的进化框架1.初始级初始级实际上是一个较为原始的阶段,初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。它的执行没有政策、资源等方面的保证时,那么它仍然被视为初始级。(二)CMM结构2.可重复级可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面,可重复级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复级的过程,一个可重级的过程则能逐渐进化和成熟。(二)CMM结构3.定义级定义级给出了定义执行的步骤标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程,剪裁出该项目的过程,并执行这些过程。过程的剪裁不是随意的,在使用前需经过企业有关人员的批准。(二)CMM结构4.管理级管理级的管理是量化的管理。所有过程需建立相应的度量方式,产品的质量需有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品,量化控制将使软件开发真正变成工业生产活动。(二)CMM结构5.优化级优化级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程,即优化执行步骤。如果一个企业达到了这一级,那么表明该企业能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。(二)CMM结构从效果而言,在上述不同阶段,软件开发生产的成熟程度给软件企业带来了完全不同的效果。从第一阶段到第五个阶段,软件开发生产的计划精度越来越高,每单位工程的生产周期越来越短,每单位工程的成本越来越低。CMM五级模型为软件质量的控制和质量的提高奠定了坚实的基础,它是当前软件质量控制领域研究的一个热点。(二)CMM结构软件系统总是出现变更,这就带来新版本软件的产生,引起版本变化的原因通常包括:变更建议和错误的修正;对不同的硬件与操作系统做出的适应性调整;提供不同的功能;按用户特定需求进行的修正。配置管理规程规定了如何记录和处理所提议的变更,如何使系统变更与系统组件相关联,以及如何识别系统不同版本的方法。CM的目的在于控制由变更带来的成本和人力消耗。4.配置管理配置管理配置管理涉及开发和应用规程与标准去管理一个进化中的软件产品。CM有时被认为是更广泛的软件质量管理的一部分。当一个软件系统被置于配置管理之下,我们把它叫做“基线”(baselines),因为它们是受控进化的一个起点。配置管理的主要活动配置管理的规划变更管理版本与发布管理系统构建配置管理规划描述配置管理应该使用的标准和规程。所有的软件产品都应该置于CM控制之下:Specifications;Designs;Programs;Testdata;Usermanuals.4.1配置管理规划配置管理规划包括以下内容:定义配置项以及使用什么模式来识别配置项;确定谁负责CM规程并把配置项提交给CM团队;定义变更控制和版本管理的策略;定义必须被维护的CM记录;描述CM使用的工具和使用这些工具的过程;描述配置数据库的结构既要维护的数据信息;对外协提供的软件的管理和CM规划对CM过程的审核过程。配置管理规划配置管理规划过程中,要严格确定对哪些项或哪类项进行控制。配置控制之下的文档成为配置项。CM中需要有一个关于所有配置项的一致性标识列表。分层命名模式是一种有效的命名方法:PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE配置项识别配置层次所有的CM信息都保存在一个配置数据库中。配置数据库必须能够对各种系统配置查询作出相应:Whohasaparticularsystemversion?Whatplatformisrequiredforaparticularversion?WhatversionsareaffectedbyachangetocomponentX?HowmanyreportedfaultsinversionT?HowmanyreportedchangerequestsinversionT?配置数据库应该和版本管理系统集成到一起以便与被配置管理控制的软件直接相连。

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

软件项目开发的资源主要是人员、开发时间、软件工具、运行所需要的软/硬件等。软件开发过程是人智力密集型的劳动。开发组织为提高软件生产率,必须最大限度地发挥每一个人的技术和能力。软件项目由项目负责人(项目经理)总负责。人员管理涉及到招募、选择、培训、业绩、报酬、专业发展,以及培养团队精神和企业文化等一系列“以人为本”的组织工作,通过吸引、培养、激励留住有创造力、技术水平高的人才,增强软件组织软件开发能力。人员资源计划

对开发人员资源的需求(计划),是随时间变化的一个指数函数曲线——Rayleigh-Norden曲线模式。td图9.1开发人员资源需求随时间变化的曲线时间人员资源需求人员协调和通信建立有效的人员通信交流机制,组织开发人员和协调他们的关系,并跟踪和协调开发进程。软件项目人员协调和通信方式可分成:

◆正式的(采用文字、视频会议等非直接交互的通信渠道)、非个人的方式; ◆正式的、个人的方式; ◆非正式的、个人的方式; ◆电子通信方式; ◆个人网络方式。人员组织范型大型软件产品的开发可采取分层次的组织结构,即软件经理→项目经理→开发小组,以保证组织和管理的有效性。一个项目科学而合理建立的组织结构取决于组织的管理风格、凝聚力、组内成员的人数和他们的技术水平,以及任务的难易程度。民主分权制 民主分权式开发组是一个没有领导者的,提倡无私精神的团体组织,民主氛围浓郁,组员们工作积极性高,这使得整个团队能多出、快出更高质量的产品。 民主分权组织方式比较强调个人的作用,所以希望小组成员都是经验丰富、技术和技能熟练的人员。 民主分权式开发组织方式特别适用于较小规模或研究型产品的开发。控制集权制

控制集权式组织的特点:一是专业化,每个成员分工明确,执行各自的专业任务;二是层次性,每个成员在组织中处于一定的领导或被领导地位。 控制集权式组由一名高级工程师(主程序员)、一名后备工程师、资料管理员,以及2~5个技术人员组成。 小组负责人由高级工程师(主程序员)担任,他既是管理者,又是高级专业人员,负责计划、协调和复审小组的所有技术活动;后备工程师是协助负责人工作的专业人员;资料管理员是专职的,职责是控制和维护所有的软件配置,协助小组进行研究、评估和文档准备。控制分权制 软件的开发通常采用一种更合理的、责任范围更清楚的人员组织方式——控制分权式开发组。 控制分权小组负责人由一个小组领导人(负责小组的技术活动),一个小组管理员(负责所有非技术的管理决策)两个人承担。小组领导人小组管理员技术人员技术人员技术人员图9.3控制分权式小组的结构示意ChiefProgrammerAssistantCPProgramManagerProgramManagerAdminis-trationLibrarianTestTeamSeniorProgrammerJuniorProgrammer全面负责设计、编码、测试和

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论