软件工程第9章软件项目管理终Word文件下载.docx
- 文档编号:21697900
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:30
- 大小:104.54KB
软件工程第9章软件项目管理终Word文件下载.docx
《软件工程第9章软件项目管理终Word文件下载.docx》由会员分享,可在线阅读,更多相关《软件工程第9章软件项目管理终Word文件下载.docx(30页珍藏版)》请在冰豆网上搜索。
项目有时只涉及一个组织的某一部分,有时则可能需要跨越好几个组织。
通常,项目是执行组织商业战略的关键。
所谓项目,就是在既定的资源和要求的限制下,为实现某种目标而相互联系的一次性的工作任务。
中国项目管理研究委员会对项目的定义是:
项目是一个特殊的将被完成的有限任务;
它是在一定时间内,满足一系列特定目标的多项相关工作的总成。
从这个定义中可以发现项目实际包含以下含义:
项目是一项有待完成的任务,有特定的环境与眼球。
这一点明确了项目自身的动态概念,既项目是指一个过程,而不是只过程终结后所形成的成果。
项目必须在一定的组织机构内部,利用有限的资源(人力、物力、财力等)在规定的时间内完成任务。
任何项目的实施都会受到一定的条件约束,这些条件是来自多方面的,包括环境、资源、理念等,这些约束条件成为项目管理者必须努力促使其实现的项目管理的具体目标。
项目任务要满足一定性能、质量、数量、技术指标等要求。
项目是否能实现,是否能交付用户,必须达到事先规定的目标要求。
功能的实现、质量的可靠、技术指标的稳定,是任何可交付项目必须满足的要求,项目合同对于这些均具有严格的要求。
项目与日常生活的不同点体现在:
日常工作通常具有连续性和重复性。
,而项目则具有
时限性和唯一性。
因此,可以根据显著特征对项目做这样的定义:
项目是一项为了创造某一唯一的产品或服务的时限性工作。
所谓时限性是指每一个项目都具有明确的开端和明确的结束;
所谓唯一性是指该项产品或服务与同类产品或服务相比,在某些方面具有显著的不同。
项目管理是以目标为导向的,而日常管理是通过效率和有效性体现的;
项目通常是通过项目经理及其项目团队工作完成的,而日常工作于项目也有许多相似的地方,比如说受到资源的限制,他们都必须由人来完成。
2.项目的分类
项目可以按照不同的标志进行不同的分类。
对项目进行分类的主要目的是要对项目的特性有更为深入的了解和认识。
项目的主要分类有如下几种:
(1)业务项目和自我开发项目。
(2)企业项目、政府项目和非盈利机构的项目。
(3)盈利性项目和非盈利性项目。
(4)大项目、项目和子项目,“Program”、“Project”和“Subproject”三个。
其他分类标准如表9-1所示:
表9-1项目的分类
3项目的基本特征
一个项目可以是一事建造一栋大楼、一座工厂,也可以是解决某个研究课题,例如:
研制一种新药,设计开发一个信息系统或制造一种新型计算机。
无论项目的规模大小、复杂程度、性质差异如何不同,都会存在一些相同之处。
例如,都是一次性的,都要求在一定的期限内完成,不得超过一定的费用,并有一定的性能要求。
所以,认识项目的特征,了解项目管理的方法与技术,有利于项目的成功和达到目标要求。
一般来说,项目具有如下基本特征
明确的目标
项目可能是一种期望的产品,也可能是一种希望得到的服务。
每一个项目最终都有可以
交付的成果,这个成果就是项目的目标。
而一系列的项目计划和实施活动都是围绕目标进行的。
项目的目标一般包括:
项目可交付结果的列表;
制定项目最终完成及中间里程碑的截止日期;
制定可交付结果必须满足的质量准则;
项目不能超过的成本限制等。
项目的独特性
项目所涉及的某些内容是以前没有做过的,也就是说这些内容是唯一的。
即使一项产品
或服务属于某一大类别,它仍然可以被认为是唯一的。
例如,开发一个新的办公自动化系统,由于使用的用户不同,必然会有很强的独特性,虽然以前可能开发过类似的系统,但是每一个系统都是唯一的,他们是分属于不同的用户,具有特殊的要求,做了不同的设计,使用了不同的开发技术,等等。
具有重复的要素并不能够改变其整体根本的唯一性。
项目的时限性
时限性指每个项目都具有明确的开始和结束时间与标致,项目不能重复实施。
当项目的
目标都已经达到时,该项目就结束了,或者当已经可以确定项目的目标不可能达到时,该项目就会被终止。
时限性意味着持续的时间短,许多项目会持续好几年。
但是,无论如何,一个项目持续的时间是确定的。
另外,由项目所创造的产品或服务通常是不受项目的时限性的影响,大多数项目的实施是为了创造一个具有延续性的成果。
例如,企业信息系统项目就能够支持企业的长期运作。
项目的这种时限性特征也会在其他方面体现出来。
机遇或市场行情通常是暂时的——大多数项目需要在限定的时间框架内创造产品或服务。
项目工作组,作为一个团队,很少会在项目结束以后继续存在——大多数项目都是由一个工作组来实施完成的,而成立这个工作组的唯一目的也就是完成这个项目,当项目完成以后,这个项目团队就会被解散,成员也会被分配到其他的工作当中去。
项目的不确定性
在项目的具体实施中,外部因素和内部因素总是会发生一些变化,因此项目也会出现不
确定性。
一个项目开始前,一般在一定的假定和预算的基础上准备一份计划。
由于有时很难确切定义项目的目标或准确地估算出所需要的时间和成本,这种假定和预算的组合产生了一定程度的不确定性,影响项目目标的成功实现。
结果的不可逆转性
项目存在一个从开始到结束的过程,这称之为项目的生命周期。
通常将项目的生命周期
划分为若干个阶段:
项目启动阶段、项目计划阶段、项目实施阶段和项目收尾阶段。
不论结果如何,项目结束了,结果也就确定了,是不可逆转的。
4.软件项目的特征
软件是与计算机系统操作有关的程序,规程、规则及其文档和数据的统称。
软件由两部分组成:
一是及其可执行的程序和相关的数据;
二是与软件开发、运行、维护、使用和培训有关的文档。
程序是按事先设计的功能和性能要求执行的语句系列。
数据时程序所处理信息的数据结构。
文档则是与程序开发、维护和使用相关的各种图文资料,在文档中记录着软件开发的活动和阶段成果。
(1)软件的特点
软件是一种逻辑产品,而不是一种物理产品,软件功能的发挥依赖于硬件和软件的运行
环境没有计算机相关硬件的支持,软件毫无使用的价值。
若要对软件有一个全面而正确的理解,应从软件的本质、软件的生产等方面等剖析软件的特征。
软件固有的特性
复杂性
软件是一个庞大的逻辑系统,比人类构造的其他产品都要复杂。
一方面在软件中客观地
体现人类社会的事务,反应业务流程的自然规律,另一方面在软件中还集成了多种多样的功能,以满足用户在激烈的竞争中对大量信息及时处理、传输、存储等方面的需求,这就使得软件变得十分复杂。
抽象性
软件是人们经过大脑思维后加工出来的产品,一般寄生在内存、磁盘、光盘等载体上,人们无法观察到它的形态,这使得软件产品的可靠性、移植性、易使用性等方面的性能难以确定,缺少明确的度量标准,因此和有形产品的的质量检测的精确度相比有很大差距。
这就导致了软件开发不仅工作量难以估计,进度难以控制,而且质量也难以把握。
依赖性
软件必须和运行软件的机器(硬件)保持一致,软件的开发和运行往往受到计算机硬件的限制,对计算机系统有着不同程度的依赖性。
软件与计算机硬件的这种密切相关性与依赖性,是一般产品所没有的特性。
为了减少这种依赖性,在软件开发中提出了软件的可移植性问题。
软件的使用特性
软件的价值在于应用。
软件产品不会因多次反复使用而磨损老化,一个久经考验的优质软件,可以长期使用。
由于用户在选择新机型时,通常提出兼容性要求,所以一个成熟的软件可以再不同型号的计算机上运行。
软件开发特性
由于软件固有的特性,使得软件的开发不仅具有技术复杂性,还有管理复杂性。
技术复
杂性体现在软件提供的功能比一般硬件产品提供的功能多,而且功能的实现会有多样性,需要在各种实现中做出选择,更有实现算法上的优化带来的不同,而实现上的差异会带来使用上的差别。
管理上的复杂性表现在:
第一,软件产品的能见度低(包括如何使用文档表示的概念能见度),看到软件开发进度要比看到有形产品的进度困难的多;
第二,软件结构的合理性差,结构不合理使软件管理的复杂性随软件规模增大而呈指数级增长。
因此,领导一个庞大人员的项目组织进行规模化生产并非易事,软件开发比硬件开发更依赖于开发团队的团队精神,智力和对开发人员的组织与管理。
软件产品形式的特征
软件产品的设计成本高昂而生产成本极低。
硬件产品试制成功之后,批量生产需要建设生产线,投入大量的人力、物力和资金,生产过程中还要对产品进行质量控制,对每件产品进行严格的检验。
然而,软件是把人的知识与技术转化为信息的逻辑产品,开发成功之后,只需对原版软件进行复制即可。
大量人力、物理、资金的投入和质量控制、软件产品检验都是在软件开发中进行的。
由于软件的复制非常容易,软件的知识产权保护就显得极为重要。
软件维护特性
软件在运行过程中的维护性工作比硬件复杂得多。
首先,软件投入运行后,总会存在缺陷设置暴露出潜伏的错误,需要进行“纠错性维护”。
其次,用户可能要求完善软件性能,对软件产品进行修改,进行“完善性维护”。
当支撑软件产品运行的硬件或软件环境改变时,也需要对软件产品进行修改,进行“适应性维护”。
软件的缺陷或错误属于逻辑性的。
当软件产品规模庞大、内部的逻辑关系复杂时,经常会发生纠正一个错误而产生新的错误的情况,因此,软件产品的维护要比硬件产品的维护性工作量大而且复杂。
(2)软件项目的特点
软件项目除了具有一般项目的特征外,它具有自己的特殊性。
它不仅是一个新的领域,而且涉及的因素比较多,管理也比较复杂。
软件项目的特点主要在以下几个方面:
①目标的渐进性
作为项目,按说应该有明确的目标,软件项目也不例外。
但是实际的情况却是:
大多数软件项目的目标不是很明确,经常出现任务边界模糊的情况。
在软件系统开发前,用户常常在项目开始时只有一些初步的功能要求,没有明确的、精确的想法,也提不出确切的需求。
而软件项目的质量只要是由项目团队来定义的,而用户只是负责起审查的任务。
因为项目产品和服务事先不可见,在项目前期只能粗略进行项目定义,随着项目的进行才能逐步完善和明确。
在这个逐步明晰的过程中,一般会进行很多修改,产生很多变更,使得项目实施和管理难度加大。
②项目的阶段性
项目的阶段性决定了项目的历时有限,具有明确的起点和终点,当实现项目或被迫中止时项目结束。
随着计算机技术的发展,软件项目的生命周期却来越短,有的项目时间甚至是决定性因素,因为市场时机稍纵即逝,如果项目的实施阶段耗时过长,市场份额将被竞争对手抢走。
因此,软件项目的阶段性对实际工作有着重要的指导意义:
这就要求项目团队有非常强的时间观念,在项目开始之前,就必须明确时间的约束,对于每项任务都有明确的时间要求。
一旦没有按进度完成,必须要有充分的客观理由,否则要追究相关人员的责任。
不确定性
不确定性是指软件项目不可能完全在规定时间内、按规定的预算由规定的人员完成。
因为软件项目计划和预算本质上是一种预测,是一种对未来的“估计”和“假设”,在执行过程中与实际情况肯定会有差异。
另外,在执行过程中还会遇到各种始料未及的“风险”。
这些都是不确定的。
智力密集型
软件项目是智力密集、劳动密集型项目,受人力资源的影响最大。
项目成员的结构、责任心,工作能力和团队的稳定性对软件项目的质量、进度及是否成功有决定性的影响。
软件项目工作的技术性很强,需要大量高强度的脑力劳动。
虽然近年来软件辅助工具发展的很快,但项目的各个阶段还是需要大量的手工劳动。
这些劳动十分细致、复杂并容易出错,在开发中渗透了许多个人的因素,在软件开发中,人力资源的作用更为突出,必须在人才激励和团队管理问题上给予足够的重视。
9.1.2项目管理的概述
项目管理是以项目及其资源为对象,运用系统的理论和方法对项目进行高效率的计划、组织、实施和控制,以实现项目目标的管理方法体系。
(1)项目管理的主体是项目经理。
(2)项目管理的客体是项目本身。
(3)项目管理的职能由计划、组织、协调和控制组成。
(4)项目管理的任务是对项目及资源进行计划、组织、协调和控制。
项目管理的目的是实现项目的目标。
1.项目管理的产生与发展
●项目管理的产生
项目管理作为一种现代化管理方式,最早出现于美国,起源于建筑行业,它是伴随着社会建设和管理大型项目的需要而产生,是工程和工程管理实践的结果。
真正意义上的项目管理概念是美国在二战后期实施曼哈顿项目时提出的。
云南鲁布革水电站是我国第一个聘用外国专家采用国际标准应用项目管理建设的水电工程项目。
●项目管理科学的发展
项目管理从经验走向科学,经历了漫长的历程,大致经历了如下四个阶段:
潜意识的项目管理:
从远古到20世纪30年代以前
传统项目管理的形成:
从20世纪30年代初期到50年代初期
项目管理的传播和现代化:
20世纪50年代初期到70年代末
现代项目管理的发展:
从20世纪70年代末到现在
总的来讲,项目管理科学的发展是人类生产实践活动发展的必然产物。
2.项目管理的基本特性
普遍性:
我们现有的各种文化物质成果最初都是通过项目的方式实现的,一般是先有项目后又日常运营。
目的性:
一切项目管理活动都是为实现“满足或超越项目有关各方对项目的要求与期望”这一目的服务的。
独特性:
项目管理既不同于一般的生产服务运营管理,也不同于常规的行政管理,是一种完全不同的管理活动。
集成性:
项目管理要求必须充分强调管理的集成,对于项目各要素的集成管理和对项目各阶段的集成管理等等。
创新性:
项目管理是对于创新的管理,项目管理本省需要创新,没有一成不变的模式和方法。
9.2CMMI
早期的CMMI(CMMI-SE/SW/IPPD)1.02版本是应用于软件业项目的管理方法,SEI在部分国家和地区开始推广和试用。
随着应用的推广与模型本身的发展,演绎成为一种被广泛应用的综合性模型。
9.2.1简介
CMMI的全称为:
CapabilityMaturityModelIntegration,即能力成熟度模型集成。
CMMI家族包括CMMIforDevelopment,CMMIforService和CMMIforAcquisition三个套装产品。
CMMI是CMM模型的最新版本。
早期的CMMI(CMMI-SE/SW/IPPD)1.02版本是应用于软件业项目的管理方法,SEI在部分国家和地区开始推广和试用。
随着应用的推广与模型本身的发展,演绎成为一种被广泛应用的综合性模型
自从1994年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。
虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。
这时他们就会发现存在一些问题,其中主要问题体现在:
(1)不能集中其不同过程改进的能力以取得更大成绩;
(2)要进行一些重复的培训、评估和改进活动,因而增加了许多成本;
(3)遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚至相抵触。
于是,希望整合不同CMM模型的需求产生了。
1997年,美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM),该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM三个模型中的所有原则、概念和实践。
该模型被认为是第一个集成化的模型。
CMMI与CMM最大的不同点在于:
CMMISM-SE/SW/IPPD/SS1.1版本有四个集成成分,即:
系统工程(SE)和软件工程(SW)是基本的科目,对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容,如果涉及到供应商外包管理可以相应的应用SS(SupplierSourcing)部分。
CMMI有两种表示方法,一种是大家很熟悉的,和软件CMM一样的阶段式表现方法,另一种是连续式的表现方法。
这两种表现方法的区别是:
阶段式表现方法仍然把CMMI中的若干个过程区域分成了5个成熟度级别,帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。
而连续式表现方法则通过将CMMI中过程区域分为四大类:
过程管理、项目管理、工程以及支持。
对于每个大类中的过程区域,又进一步分为基本的和高级的。
这样,在按照连续式表示方法实施CMMI的时候,一个组织可以把项目管理或者其他某类的实践一直做到最好,而其他方面的过程区域可以完全不必考虑。
9.2.2预备工作
评估实践证明:
在进行CMMI评估之前,制定一个正确的评估计划并将其文档化,确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估,为执行评估过程做准备,是十分必要的。
我们所说的文档化CMMI评估计划的结果,包括:
要求,协定,估价,风险,剪裁方法,以及与评估相关的实际考虑(例如:
日程安排,后勤,组织的背景信息)。
此外,还应当获取并记录发起方对于CMMI评估计划的正式批准。
在制定评估计划之前,应对CMMI评估输入中反映出来的协议文档化,该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。
在对驱动计划过程的关键参数达成共同理解的基础上,CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致;
发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。
这个计划在执行其他的计划和准备阶段活动中需要进一步细化。
而通过CMMI评估小组的准备工作,将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。
该小组的成员都应当获得了完成他们各自的任务所必备的知识,或者他们之前所拥有的知识被证实足以完成相关任务。
评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会,或者证实这些技能在过去已经得到了示范。
小组成员相互了解,同时开始计划他们如何协调一致的工作。
还应该做到:
准备好的小组是为评估目标而服务的,小组的成员已提供培训且培训结果被记录,在必要的时候,对他们所做的因知识或技能不足的补救工作已经完成。
我们认为,无论CMMI评估小组领导者是从头培训一支全新的评估小组,还是通过从富有经验的小组成员中选择来组建一个小组,确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。
此外,在对CMMI评估进行的预备工作的过程中,我们还应当对模型剪裁的原则有所了解:
1.在某些应用中,计划模板和例行的程序能够根据评估的需要进行调整,这和当地的过程所有权一样,有助于交流;
2.一个结构化的计划工艺组有利于资源有限的评估经验的组织,这样一个工艺就像缓和策略样,对于发现风险是一个很有价值的机会;
3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那些更需要培训的重点;
4.富有经验的评估小组领导者在没有案例分析的情况下,同样可以管理和模拟评估行为;
5.在小组所有已获得培训成员的集合中,对小组的建立工作进行管理以确保其团队凝聚力是十分重要的,因此,很多的小组建立练习是可以利用的,小组的规模、技能、组成部分都是本方法的裁剪内容;
6.所采用工具可以包括评估计划模板,样例,和计划模板中嵌入式的程序上的帮助,此外,为了估计评估约束的影响,估算工作表和方法也是很有用处的。
总之,CMMI评估是一个十分复杂的过程,更由于其具有的不确定性,在评估的实践中,一定要做到有备无患。
真理来自于实践,我们相信,随着越来越多的软件组织着手CMMI评估,越来越多的成功经验将为我们所利用和借鉴。
9.2.3评估方法
自1991年起,CMM出现了很多模型,覆盖了各种各样的专业领域。
其中著名的模型有系统工程·
软件工程·
软件采购·
集成产品和流程开发等。
然而当企业想要在组织内不同专业领域的流程改进,这些针对不同专业领域的模型在架构·
内容和方法上的不同限制了组织成功实施改进的能力。
此外,将这样模型在组织内部集成也提高了培训·
认证和改进的费用。
一套包括多个专业领域的模型加上整合的培训和认证支持将解决这些问题。
CMMI(Capabilitymaturitymodelintegration)是为了合并三个模型到一个框架中
CapabilityMaturityModelforSoftware(SW-CMM)v2.0draftC,
ElectronicIndustriesAllianceInterimStandard(EIA/IS)731
IntegratedProductDevelopmentCapabilityMaturityModel(IPD-CMM)v0.98
正如其他CMM模型,CMMI提供了流程改进的指导,而不是流程或流程的描述。
组织使用的实际流程取决于很多因素,包括应用领域·
组织框架和规模。
CMMI将许多经过验证的方法加入架构中,来帮组组织评价成熟度·
某个软件流程的能力度,并且建立改进的优先顺序和实施改进。
从CMMI框架可以产生不同的CMMI模型,因此必须首先确定那种模型最适合企业流程改进的需要。
使用连续式描述可以根据企业需要选择流程改进顺序,降低企业风险,这给通过ISO做流程改进提供了一个方便的比较。
使用能力度(Capability)来衡量。
阶段式描述提供了已经过验证的流程改进顺序,方便从CMM移植过来。
使用成熟度(Maturity)来衡量流程改进。
系统工程包括整个系统的开发,可能包括软件也可能不包括。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程第9章 软件项目管理终 软件工程 软件 项目 管理