您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
 

项目管理

软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。 为使软件项目开发获得成功,关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。 这种管理在技术工作开始之前就应开始,在软件从概念到实现的过程中继续进行,当软件工程过程最后结束时才终止。


1
概述
6
编写计划
2
开发计划
7
配置管理
3
项目控制
8
组织管理
4
组织模式
9
能力评估
5
项目管理原则
10
范围界限

 

 
1
概述

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。

软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则,方法,同时避免前人的失误。

软件项目管理的提出是在20世纪70年代中期的美国,当时美国国防部专门研究了软件开发不能按时提交,预算超支和质量达不到用户要求的原因,结果发现70%的项目是因为管理不善引起的,而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期,软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。

1995年,据统计,美国共取消了810亿美元的商业软件项目,其中31%的项目未做完就被取消,53%的软件项目进度通常要延长50%的时间,只有9%的软件项目能够及时交付并且费用也控制在预算之内。

软件项目管理和其他的项目管理相比有相当的特殊性。首先,软件是纯知识产品,其开发进度和质量很难估计和度量,生产效率也难以预测和保证。其次,软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码,同时有数千个程序员在进行开发,项目经理都有上百个。这样庞大的系统如果没有很好的管理,其软件质量是难以想象的。

软件项目管理的内容主要包括如下几个方面:人员的组织与管理,软件度量,软件项目计划,风险管理,软件质量保证,软件过程能力评估,软件配置管理等。

这几个方面都是贯穿、交织于整个软件开发过程中的,其中人员的组织与管理把注意力集中在项目组人员的构成、优化;软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值,包括过程度量和产品度量两个方面;软件项目计划主要包括工作量、成本、开发时间的估计,并根据估计值制定和调整项目组的工作;风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划,有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣,下面就详细的对这两方面展开讨论。

 

 
2
开发计划

软件项目计划是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

软件项目管理过程从项目计划活动开始,而第一项计划活动就是估算:需要多长时间、需要多少工作量、以及需要多少人员。此外,我们还必须估算所需要的资源(硬件及软件)和可能涉及到的风险。

为了估算软件项目的工作量和完成期限,首先需要预测软件规模。度量软件规模的常用方法有直接的方法——LOC(代码行),间接的方法——FP(功能点)。这两种方法各有优缺点,应该根据软件项目的特点选择适用的软件规模度量方法。

根据项目的规模可以估算出完成项目所需的工作量,我们可以使用一种或多种技术进行估算,这些技术主要分为两大类:分解和经验建模。分解技术需要划分出主要的软件功能,接着估算实现每一个功能所需的程序规模或人月数。经验技术的使用是根据经验导出的公式来预测工作量和时间。可以使用自动工具来实现某一特定的经验模型。

精确的项目估算一般至少会用到上述技术中的两种。通过比较和协调使用不同技术导出的估算值,我们可能得到更精确的估算。软件项目估算永远不会是一门精确的科学,但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。

当对软件项目给予较高期望时,一般都会进行风险分析。在标识、分析和管理风险上花费的时间和人力可以从多个方面得到回报:更加平稳的项目进展过程;更高的跟踪和控制项目的能力;由于在问题发生之前已经做了周密计划而产生的信心。

对于一个项目管理者,他的目标是定义所有的项目任务,识别出关键任务,跟踪关键任务的进展情况,以保证能够及时发现拖延进度的情况。为此,项目管理者必须制定一个足够详细的进度表,以便监督项目进度并控制整个项目。

常用的制定进度计划的工具主要有Gantt图和工程网络两种。Gantt图具有悠久历史、直观简明、容易学习、容易绘制等优点,但是,它不能明显地表示各项任务彼此间的依赖关系,也不能明显地表示关键路径和关键任务,进度计划中的关键部分不明确。因此,在管理大型软件项目时,仅用Gantt图是不够的,不仅难于做出既节省资源又保证进度的计划,而且还容易发生差错。

工程网络不仅能描绘任务分解情况及每项作业的开始时间和结束时间,而且还能清楚地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务。因此,工程网络图是制定进度计划的强有力的工具。通常,联合使用Gantt图和工程网络这两种工具来制定和管理进度计划,使它们互相补充、取长补短。

进度安排是软件项目计划的首要任务,而项目计划则是软件项目管理的首要组成部分。与估算方法和风险分析相结合,进度安排将为项目管理者建立起一张计划图。

 

 
3
项目控制

对于软件开发项目而言,控制是十分重要的管理活动。下面介绍软件工程控制活动中的质量保证和配置管理。其实上面所提到的风险分析也可以算是软件工程控制活动的一类。而进度跟踪则起到连接软件项目计划和控制的作用。

软件质量保证(SQA,Software Quality Assurance)是在软件过程中的每一步都进行的“保护性活动”。SQA主要有基于非执行的测试(也称为评审)、基于执行的测试(即通常所说的测试)和程序正确性证明。

软件评审是最为重要的SQA活动之一。它的作用是,在发现及改正错误的成本相对较小时就及时发现并排除错误。审查和走查是进行正式技术评审的两类具体方法。审查过程不仅步数比走审多,而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大数是规格说明错误或设计错误,而正式的技术评审发现这两类错误的有效性高达75%,因此是非常有效的软件质量保证方法。

软件配置管理(SCM,Software configuration management)是应用于整个软件过程中的保护性活动,它是在软件整个生命周期内管理变化的一组活动。

软件配置由一组相互关联的对象组成,这些对象也称为软件配置项,它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外,用于开发软件的开发环境也可置于配置控制之下。

一旦一个配置对象已被开发出来并且通过了评审,它就变成了基线。对基线对象的修改导致建立该对象的版本。版本控制是用于管理这些对象而使用的一组规程和工具。

变更控制是一种规程活动,它能够在对配置对象进行修改时保证质量和一致性。配置审计是一项软件质量保证活动,它有助于确保在进行修改时仍然保持质量。状态报告向需要知道关于变化的信息的人,提供有关每项变化的信息。

 

 
4
组织模式

软件项目可以是一个单独的开发项目,也可以与产品项目组成一个完整的软件产品项目。如果是订单开发,则成立软件项目组即可;如果是产品开发,需成立软件项目组和产品项目(负责市场调研和销售),组成软件产品项目组。公司实行项目管理时,首先要成立项目管理委员会,项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。

3.1、项目管理委员会项目管理委员会是公司项目管理的最高决策机构,一般由公司总经理、副总经理组成。主要职责如下:

(1)依照项目管理相关制度管理项目;

(2)监督项目管理相关制度的执行;

(3)对项目立项、项目撤消进行决策;

(4)任命项目管理小组组长、项目评审委员会主任、项目组组长.

3.2、项目管理小组项目管理小组对项目管理委员会负责,一般由公司管理人员组成。主要职责如下:

(1)草拟项目管理的各项制度;

(2)组织项目阶段评审;

(3)保存项目过程中的相关文件和数据;

(4)为优化项目管理提出建议。

3.3、项目评审小组项目评审小组对项目管理委员会负责,可下设开发评审小组和产品评审小组,一般由公司技术专家和市场专家组成。主要职责如下:

(1)对项目可行性报告进行评审;

(2)对市场计划和阶段报告进行评审;

(3)对开发计划和阶段报告进行评审;

(4)项目结束时,对项目总结报告进行评审。

3.4、软件产品项目组软件产品项目组对项目管理委员会负责,可下设软件项目组和产品项目组。软件项目组和产品项目组分别设开发经理和产品经理。成员一般由公司技术人员和市场人员构成。主要职责是:根据项目管理委员会的安排具体负责项目的软件开发和市场调研及销售工作。

 

 
5
项目管理原则

从软件工程的角度讲,软件开发主要分为六个阶段:需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发,还是团队协作开发,这六个阶段都是不可缺少的。根据公司实际情况,公司在进行软件项目管理时,重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的整个阶段。在20世纪80年代初,著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则,同样,在进行软件项目管理时,也应该遵循这七条原则。它们是:

(1)用分阶段的生命周期计划严格管理;

(2)坚持进行阶段评审;

(3)实行严格的产品控制;

(4)采用现代程序设计技术;

(5)结果应能够清楚地审查;

(6)开发小组地人员应该少而精;

(7)承认不断改进软件工程实践的必要性。

 

 
6
编写计划

项目组成立的第一件事是编写《软件项目计划书》,在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。计划书主要向公司各相关人员发放,使他们大体了解该软件项目的情况。对于计划书的每个内容,都应有相应具体实施手册,这些手册是供项目组相关成员使用的。

 

 
7
配置管理

是否进行配置管理与软件的规模有关,软件的规模越大,配置管理就显得越重要。软件配置管理简称SCM(Software Configuration Management的缩写),是在团队开发中,标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。

6.1、目前软件开发中面临的问题:在有限的时间、资金内,要满足不断增长的软件产品质量要求;开发的环境日益复杂,代码共享日益困难,需跨越的平台增多;程序的规模越来越大;软件的重用性需要提高;软件的维护越来越困难。

6.2、软件配置管理应提供的功能:

在ISO9000.3中,对配置管理系统的功能作了如下描述:唯一地标识每个软件项的版本;标识共同构成一完整产品的特定版本的每一软件项的版本;控制由两个或多个独立工作的人员同时对一给定软件项的更新;按要求在一个或多个位置对复杂产品的更新进行协调;标识并跟踪所有的措施和更改;这些措施和更改是在从开始直到放行期间,由于更改请求或问题引起的。

6.3、版本管理软件配置管理分为版本管理、问题跟踪和建立管理三个部分,其中版本管理是基础。版本管理应完成以下主要任务:

建立项目;

重构任何修订版的某一项或某一文件;

利用加锁技术防止覆盖; ?当增加一个修订版时要求输入变更描述;

提供比较任意两个修订版的使用工具;

采用增量存储方式;

提供对修订版历史和锁定状态的报告功能;

提供归并功能;

允许在任何时候重构任何版本;

权限的设置;

晋升模型的建立;

提供各种报告。

 

 
8
组织管理

软件开发中的开发人员是最大的资源。对人员的配置、调度安排贯穿整个软件过程,人员的组织管理是否得当,是影响对软件项目质量的决定性因素。

首先在软件开发的一开始,要合理的配置人员,根据项目的工作量、所需要的专业技能,再参考各个人员的能力、性格、经验,组织一个高效、和谐的开发小组。一般来说,一个开发小组人数在5到10人之间最为合适,如果项目规模很大,可以采取层级式结构,配置若干个这样的开发小组。

在选择人员的问题上,要结合实际情况来决定是否选入一个开发组员。并不是一群高水平的程序员在一起就一定可以组成一个成功的小组。作为考察标准,技术水平、与本项目相关的技能和开发经验、以及团队工作能力都是很重要的因素。一个一天能写一万行代码但却不能与同事沟通融洽的程序员,未必适合一个对组员之间通讯要求很高的项目。还应该考虑分工的需要,合理配置各个专项的人员比例。例如一个网站开发项目,小组中有页面美工、后台服务程序、数据库几个部分,应该合理的组织各项工作的人员配比。对于一个中型农技110网站,对数据采集量要求较高,一个人员配比方案可以是2个美工、2个后台服务程序编写、3个数据采集整理人员。

可以用如下公式来对候选人员能力进行评分,达到一定分数的则可以考虑进入开发组,但这个公式不包含对人员数量配比的考虑。

Score=∑WiCi(i=1to8)

Ci是对项目组人员各项能力的评估。其值含义如下

在决定一个开发组的开发人员数量时,除了考虑候选人素质以外,还要综合考虑项目规模、工期、预算、开发环境等因素的影响,下面是一个基于规模、工期和开发环境的人员数量计算公式:

L=Ck*K1/3*td4/3

L:开发规模,以代码行LOC为度量td:开发时间K:人员数

Ck:技术常数表示开发环境的优劣

取值2000:表示开发环境差,没有系统的开发方法,缺乏文档规范化设计;

取值8000:表示开发环境较好;

取值11000:表示开发环境优。

在组建开发组时,还应充分估计到开发过程中的人员风险。由于工作环境、待遇、工作强度、公司的整体工作安排和其他无法预知的因素,一个项目尤其是开发周期较长的项目几乎无可避免的要面临人员的流入流出。如果不在项目初期对可能出现的人员风险进行充分的估计,作必要的准备,一旦风险转化为现实,将有可能给整个项目开发造成巨大的损失。以较低的代价进行及早的预防是降低这种人员风险的基本策略。具体来说可以从以下几个方面对人员风险进行控制:

a.保证开发组中全职人员的比例,且项目核心部分的工作应该尽量由全职人员来担任, 以减少兼职人员对项目组人员不稳定性的影响。

b.建立良好的文档管理机制,包扩项目组进度文档、个人进度文档、版本控制文档、整体技术文档、个人技术文档、源代码管理等。一旦出现人员的变动,比如某个组员因病退出,替补的组员能够根据完整的文档尽早接手工作。

c.加强项目组内技术交流,比如定期开技术交流会,或根据组内分工建立项目组内部的开发小组,是开发小组内的成员能够相互熟悉对方的工作和进度,能够在必要的时候替对方工作。

d.对于项目经理,可以从一开始就指派一个副经理在项目中协同项目经理管理项目开发工作,如果项目经理退出开发组,副经理可以很快接手。但是只建议在项目经理这样的高度重要的岗位采用这种冗余复制的策略来预防人员风险,否则将大大增加项目成本。

e.为项目开发提供尽可能好的开发环境,包括工作环境、待遇、工作进度安排等等,同 时一个优秀的项目经理应该能够在项目组内营造一种良好的人际关系和工作氛围。良好的开发环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。

 

 
9
能力评估

软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力。现行的国际标准主要有两个:ISO9000.3和CMM。

ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。它从管理职责、质量体系、合同评审、设计控制、文件和资料控制、采购、顾客提供产品的控制、产品标识和可追溯性、过程控制、检验和试验、检验/测量和试验设备的控制、检验和试验状态、不合格品的控制、纠正和预防措施、搬运/贮存/包装/防护和交付、质量记录的控制、内部质量审核、培训、服务、统计系统等二十个方面对软件质量进行了要求。

CMM(能力成熟度模型)是美国卡纳基梅隆大学软件工程研究所(CMU/SEI)于1987年提出的评估和指导软件研发项目管理的一系列方法,用5个不断进化的层次来描述软件过程能力。现在CMM是2.0版本。

ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是,ISO9000强调的是衡量的准则,但没有告诉软件开发人员如何达到好的目标,如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织,如果要在原有的水平上提高一个等级,应该关注哪些问题,而这正是改进软件过程的工作。

CMM描述了五个级别的软件过程成熟度(初始级,可重复级,已定义级,已定量管理级,优化级),成熟度反映了软件过程能力的大小。

初始级特点是软件机构缺乏对软件过程的有效管理,软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,其软件项目的成功来源于偶尔的个人英雄主义而非群体行为,因此它不是可重复的;可重复级的特点是软件机构的项目计划和跟踪稳定,项目过程可控,项目的成功是可重复的;已定义级的特点在于软件过程已被提升成标准化过程,从而更加具有稳定性、可重复性和可控性;已定量管理级的软件机构中软件过程和软件产品都有定量的目标,并被定量地管理,因而其软件过程能力是可预测的,其生产的软件产品是高质量的;优化级的特点是过程的量化反馈和先进的新思想、新技术促进过程不断改进,技术和过程的改进改进被作为常规的业务活动加以计划和管理。

CMM是科学评价一个软件企业开发能力的标准,但要达到较高的级别也非常困难,根据1995年美国所做的软件产业成熟度的调查,在美国的软件产业中,CMM成熟度等级为初始级的竟占70%,为可重复级的占15%,为定义级的所占比例小于10%,为管理级的所占比例小于5%,为优化级的所占比例小于l%。而国内企业的水平就更加堪优,到目前为止,只有东软一家达到优化级,少数几家能够达到可定义级。尽快改变这种局面,科学化、规范化、高效的进行软件开发活动,从整体提高我国软件行业的水平,是国内软件企业的当务之急,也是专业人员应该为自己制定的目标。如果有一天也能指挥一个数千人的庞大开发队伍,操作Windows这样巨型规模的软件项目,并生产出高质量的产品,才有理由宣称自己的软件项目管理能力达到了一个“自主自足”的水平。

 

 
10
范围界限

项目组的范围界限可以有三种划分:

1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员,包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责该项目开发的人员;

2、包括客户方项目经理、业务需求提出人和测试人,包括开发商具体负责该项目开发的人员;

3、仅包括开发商具体负责该项目开发的人员。

大部分人在思想上可以接受范围1,而在实务中接受的是范围3。而我个人认为项目经理,特别是开发商方面的项目经理应该采用的是范围2。

对项目组范围理解不同,将影响项目经理对工作的处理方式,范围1实际上是很虚的,在项目管理实务操作中没有太大的意义;而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来,也就是所谓的甲方、乙方。在这种对立的前提下处理项目的分歧和矛盾,效果肯定要打折扣。

而按范围2来理解,在项目管理实务中项目经理就必须要让客户方和该项目有密切关系的人也接受这一观点,从而拆除双方之间的"障碍",达到相互信任、相互尊重、共同协商解决问题的良性氛围,以达到降低项目外部风险的目的。当然,这样就增大了项目经理工作的难度,但对项目的成功则是很重要的。

 

   
次浏览       
     
 
相关文章

项目流程_IPD
EA中的项目管理-计划与跟踪
大型项目中的敏捷项目管理实践
敏捷项目管理概述
 
相关文档

IPD体系框架下的项目管理
项目管理基础与敏捷开发入门
IT项目管理培训
软件项目管理
 
相关课程

软件开发过程中的项目管理
基于IPD的项目管理方法与实践
敏捷项目管理实践
项目管理高级实践
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]

正视研发管理才是高水平竞争
需求是如何变成产品原型的
产品经理能力模型解说—把控
产品经理的正确定位
谁是合格的产品经理?
产品管理与产品营销的区别
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...