您的当前位置:首页正文

软件项目管理的学习资料

2021-06-15 来源:步旅网
软件项目管理综述

一.引言

随着信息技术的飞速发展,软件产品的规模也越来越庞大,个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理引入开发活动中,对开发实行有效的管理。以四川托普软件公司为例,该公司是成都一家中型软件企业,在公司中已经实行了项目管理制度,软件项目管理是整个项目管理中的一个重要组成部分。从概念上讲,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上,软件项目管理的意义不仅仅如此,进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力,企业的软件开发能力越高,表明这个企业的软件生产越趋向于成熟,企业越能够稳定发展(即减小开发风险)。软件开发不同于其他产品的制造,软件的整个过程都是设计过程(没有制造过程);另外,软件开发不需要使用大量的物质资源,而主要是人力资源;并且,软件开发的产品只是程序代码和技术文件,并没有其他的物质结果。基于上述特点,软件项目管理与其他项目管理相比,有很大的特殊性。

二.什么是软件项目管理

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。

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

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

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

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

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

这几个方面都是贯穿、交织于整个软件开发过程中的,其中人员的组织与管理把注意力集中在项目组人员的构成、优化;软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值,包括过程度量和产品度量两个方面;软件项目计划主要包括工作量、成本、开发时间的估计,并根据估计值制定和调整项目组的工作;风险

管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划,有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。因为大家对人力资源管理和软件过程能力比较有兴趣,下面就详细的对这两方面展开讨论。

三、软件项目管理的组织模式

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

3.1、项目管理委员会

项目管理委员会是公司项目管理的最高决策机构,一般由公司总经理、副总经理组成。主要职责如下:(1)依照项目管理相关制度管理项目;(2)监督项目管理相关制度的执行;(3)对项目立项、项目撤消进行决策;(4)任命项目管理小组组长、项目评审委员会主任、项目组组长.

3.2、项目管理小组

项目管理小组对项目管理委员会负责,一般由公司管理人员组成。主要职责如下:(1)草拟项目管理的各项制度;(2)组织项目阶段评审;(3)保存项目过程中的相关文件和数据;(4)为优化项目管理提出建议。

3.3、项目评审小组

项目评审小组对项目管理委员会负责,可下设开发评审小组和产品评审小组,一般由公 司技术专家和市场专家组成。主要职责如下:(1)对项目可行性报告进行评审;(2)对市场计划和阶段报告进行评审;(3)对开发计划和阶段报告进行评审;(4)项目结束时,对项目总结报告进行评审。

3.4、软件产品项目组

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

四、软件项目管理的内容

从软件工程的角度讲,软件开发主要分为六个阶段:需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发,还是团队协作开发,这六个阶段都是不可缺少的。根据公司实际情况,公司在进行软件项目管理时,重点将软件配置管理、项目跟踪和控制管理、软件风险管理及项目策划活动管理四方面内容导入软件开发的

整个阶段。在20世纪80年代初,著名软件工程专家B.W.Boehm总结出了软件开发时需遵循的七条基本原则,同样,在进行软件项目管理时,也应该遵循这七条原则。它们是:(1)用分阶段的生命周期计划严格管理;(2)坚持进行阶段评审;(3)实行严格的产品控制;(4)采用现代程序设计技术;(5)结果应能够清楚地审查;(6)开发小组地人员应该少而精;(7)承认不断改进软件工程实践的必要性。

五、编写《软件项目计划书》

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

《软件项目计划书》一般应该包括下述内容: 1.引言 1.1计划的目的 1.2项目的范围和目标 1.2.1范围描述 1.2.2主要功能 1.2.3性能

1.2.4管理和技术约束 2.项目估算 2.1使用的历史数据 2.2使用的评估技术 2.3工作量、成本、时间估算 3.风险管理战略 3.1风险识别 3.2有关风险的讨论 3.3风险管理计划 3.3.1风险计划 3.3.2风险监视 3.3.3风险管理 4.日程

4.1项目工作分解结构 4.2时限图(甘特图) 4.3资源表 5.项目资源 5.1人员 5.2硬件和软件 5.3特别资源 6.人员组织 6.1组织结构 6.2管理报告

7.跟踪和控制机制 7.1质量保证和控制 7.2变化管理和控制 8.附录

六、软件配置管理

是否进行配置管理与软件的规模有关,软件的规模越大,配置管理就显得越重要。软件配置管理简称SCM(Software Configuration Management的缩写),是在团队开发中,标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。 6.1、目前软件开发中面临的问题:在有限的时间、资金内,要满足不断增长的软件产品质量要求;开发的环境日益复杂,代码共享日益困难,需跨越的平台增多;程序的规模越来越大;软件的重用性需要提高;软件的维护越来越困难。 6.2、软件配置管理应提供的功能:

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

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

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

•利用加锁技术防止覆盖; •当增加一个修订版时要求输入变更描述; •提供比较任意两个修订版的使用工具; •采用增量存储方式;

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

•允许在任何时候重构任何版本; •权限的设置; •晋升模型的建立; •提供各种报告。

七.人员组织与管理

软件开发中的开发人员是最大的资源。对人员的配置、调度安排贯穿整个软件过程,人

员的组织管理是否得当,是影响对软件项目质量的决定性因素。

首先在软件开发的一开始,要合理的配置人员,根据项目的工作量、所需要的专业技能,再参考各个人员的能力、性格、经验,组织一个高效、和谐的开发小组。一般来说,一个开发小组人数在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.为项目开发提供尽可能好的开发环境,包括工作环境、待遇、工作进度安排等等,同 时一个优秀的项目经理应该能够在项目组内营造一种良好的人际关系和工作氛围。良好的开发环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。

八.软件过程能力评估

软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力。现行的国际标准主要有两个: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这样巨型规模的软件项目,并生产出高质量的产品,才有理由宣称自己的软件项目管理能力达到了一个“自主自足”的水平。

九、软件质量管理

随着软件开发的规模越来越大,软件的质量问题显得越来越突出。软件质量的控制不单单是一个软件测试问题,在软件开发的所有阶段都应该引入质量管理。我公司除加强了国家标准\"信息技术软件生存期过程\"(GB/T8566--1995)的规范管理外,还积极为通过ISO 9000.3做准备。

1、软件质量保证计划

在进行软件开发前,需要有一个《软件质量保证计划》。目前较常用的是ANSI/IEEE STOL 730--1984,983--1986标准,包括以下内容: 1.计划目的 2.参考文献 3.管理 3.1.组织 3.2.任务 3.3.责任 4.文档 4.1.目的

4.2.要求的软件工程文档 4.3.其他文档 5.标准和约定 5.1.目的 5.2.约定

6.评审和审计 6.1.目的 6.2.评审要求

6.2.1.软件需求的评审 6.2.2.设计评审

6.2.3.软件验证和确认评审 6.2.4.功能评审 6.2.5.物理评审 6.2.6.内部过程评审 6.2.7.管理评审 7.测试

8.问题报告和改正活动 9.工具、技术和方法

10.媒体控制 11.供应者控制

12.记录、收集、维护和保密 13.培训 14.风险管理

2、质量管理的基本原则 。控制所有过程的质量;

。过程控制的出发点是预防不合格;

。质量管理的中心任务是建立并实施文件化的质量体系; 。持续的质量改进;

。有效的质量体系应满足顾客和组织内部双方的需要和利益; 。定期评价质量体系;

。搞好质量管理关键在于领导。 3、软件质量因素

正确性:系统满足规格说明和用户目标的程度,即,在预定环境下能正确地完成预期功能的程度。

健壮性:在硬件发生故障、输入的数据无效或操作错误等意外环境下,系统能做出适当响应的程度。

效率:为了完成预定的功能,系统需要的计算资源的多少。 完整性(安全性):对未经授权的人使用软件或数据的企图,系统能过控制(禁止)的程度。

可用性:系统在完成预定应该完成的功能时另人满意的程度。

风险:按预定的成本和进度把系统开发出来,并且为用户所满意的概率。 可理解性:理解和使用该系统的容易程度。

可维修性:诊断和改正在运行现场发现的错误所需要的工作量的大小。 灵活性(适应性):修改或改进正在运行的系统需要的工作量的多少。 可测试性:软件容易测试的程度。

可移植性:把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时,需要的工作量多少。有一种定量度量的方法是:用原来程序设计和调试的成本除移植时需用的费用。

可再用性:再其他应用中该程序可以被再次使用的程度(或范围)。 互运行性:把该系统和另一个系统结合起来需要的工作量的多少。 4、软件评审

软件评审并不是在软件开发完毕后进行评审,而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误,如果这些错误不及时发现并纠正,会不断地扩大,最后可能导致开 发的失败。下面这组数据可以清楚的看出前期的错误对后期的影响。

软件评审是相当重要的工作,也是目前国内开发最不重视的工作。 (1)评审目标

。发现任何形式表现的软件功能、逻辑或实现方面的错误; 。通过评审验证软件的需求;

。保证软件按预先定义的标准表示; 。已获得的软件是以统一的方式开发的; 。使项目更容易管理。

(2)评审过程

A、召开评审会议:一般应有3至5人参加,会前每个参加者做好准备,评审会每次一般不超过2小时。

B、会议结束使必须做出以下决策之一:接受该产品,不需做修改;由于错误严重,拒绝接受;暂时接受该产品。

C、评审报告与记录;所提出的问题都要进行记录,在评审会结束前产生一个评审问题表,另外必须完成评审简要报告。 (3)评审准则

。评审产品,而不是评审设计者(不能使设计者有任何压力); 。会场要有良好的气氛;

。建立议事日程并维持它(会议不能脱离主题);

。限制争论与反驳(评审会不是为了解决问题,而是为了发现问题; 。指明问题范围,而不是解决提到的问题;

。展示记录(最好有黑板,将问题随时写在黑板上); 。限制会议人数和坚持会前准备工作;

。对每个被评审的产品要尽力评审清单(帮助评审人员思考); 。对每个正式技术评审分配资源和时间进度表; 。对全部评审人员进行必要的培训;

。及早地对自己地评审做评审(对评审准则的评审)。 5、ISO9000.3软件质量认证体系

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

软件测试是软件开发的一个重要环节,同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统(或系统的部件)。测试一般包括单元测试、模块测试、集成测试和系统测试。如果测试结果与预期结果不一致,则很可能是发现了系统中的错误,测试过程中将产生下述基本文档:

(1)测试计划:确定测试范围、方法、和需要的资源等。

(2)测试过程:详细描述和每个测试方案有关的测试步骤和数据(包括测试数据及预期的结果)。

(3)测试结果:把每次测试运行的结果归入文档,如果运行出错,则应产生问题报告,并且必须经过调试解决所发现的问题。

因篇幅问题不能全部显示,请点此查看更多更全内容