软件项目管理.docx
《软件项目管理.docx》由会员分享，可在线阅读，更多相关《软件项目管理.docx（14页珍藏版）》请在冰豆网上搜索。
软件项目管理
软件项目管理
中程在线信息产业培训网（）
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。
而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则，方法，同时避免前人的失误。
软件项目管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。
于是软件开发者开始逐渐重视起软件开发中的各项管理。
到了20世纪90年代中期，软件研发项目管理不善的问题仍然存在。
据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10％的项目能够在预定的费用和进度下交付。
1995年，据统计，美国共取消了810亿美元的商业软件项目，其中31％的项目未做完就被取消，53％的软件项目进度通常要延长50%的时间，只有9％的软件项目能够及时交付并且费用也控制在预算之内。
软件项目管理和其他的项目管理相比有相当的特殊性。
首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。
其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。
Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。
这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。
软件项目管理的内容主要包括如下几个方面：
人员的组织与管理，软件度量，软件项目计划，风险管理，软件质量保证，软件过程能力评估，软件配置管理等。
这几个方面都是贯穿、交织于整个软件开发过程中的，其中人员的组织与管理把注意力集中在项目组人员的构成、优化；软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值，包括过程度量和产品度量两个方面；软件项目计划主要包括工作量、成本、开发时间的估计，并根据估计值制定和调整项目组的工作；风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防；质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划，有组织的活动；软件过程能力评估是对软件开发能力的高低进行衡量；软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。
因为大家对人力资源管理和软件过程能力比较有兴趣，下面就详细的对这两方面展开讨论。
一．软件项目的计划
软件项目计划是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:
确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。
软件项目管理过程从项目计划活动开始，而第一项计划活动就是估算：
需要多长时间、需要多少工作量、以及需要多少人员。
此外，我们还必须估算所需要的资源（硬件及软件）和可能涉及到的风险。
为了估算软件项目的工作量和完成期限，首先需要预测软件规模。
度量软件规模的常用方法有直接的方法——LOC（代码行），间接的方法——FP（功能点）。
这两种方法各有优缺点，应该根据软件项目的特点选择适用的软件规模度量方法。
根据项目的规模可以估算出完成项目所需的工作量，我们可以使用一种或多种技术进行估算，这些技术主要分为两大类：
分解和经验建模。
分解技术需要划分出主要的软件功能，接着估算实现每一个功能所需的程序规模或人月数。
经验技术的使用是根据经验导出的公式来预测工作量和时间。
可以使用自动工具来实现某一特定的经验模型。
精确的项目估算一般至少会用到上述技术中的两种。
通过比较和协调使用不同技术导出的估算值，我们可能得到更精确的估算。
软件项目估算永远不会是一门精确的科学，但将良好的历史数据与系统化的技术结合起来能够提高估算的精确度。
当对软件项目给予较高期望时，一般都会进行风险分析。
在标识、分析和管理风险上花费的时间和人力可以从多个方面得到回报：
更加平稳的项目进展过程；更高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的信心。
对于一个项目管理者，他的目标是定义所有的项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能够及时发现拖延进度的情况。
为此，项目管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。
常用的制定进度计划的工具主要有Gantt图和工程网络两种。
Gantt图具有悠久历史、直观简明、容易学习、容易绘制等优点，但是，它不能明显地表示各项任务彼此间的依赖关系，也不能明显地表示关键路径和关键任务，进度计划中的关键部分不明确。
因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。
工程网络不仅能描绘任务分解情况及每项作业的开始时间和结束时间，而且还能清楚地表示各个作业彼此间的依赖关系。
从工程网络图中容易识别出关键路径和关键任务。
因此，工程网络图是制定进度计划的强有力的工具。
通常，联合使用Gantt图和工程网络这两种工具来制定和管理进度计划，使它们互相补充、取长补短。
进度安排是软件项目计划的首要任务，而项目计划则是软件项目管理的首要组成部分。
与估算方法和风险分析相结合，进度安排将为项目管理者建立起一张计划图。
二．软件项目的控制
对于软件开发项目而言，控制是十分重要的管理活动。
下面介绍软件工程控制活动中的质量保证和配置管理。
其实上面所提到的风险分析也可以算是软件工程控制活动的一类。
而进度跟踪则起到连接软件项目计划和控制的作用。
软件质量保证（SQA，SoftwareQualityInsurance）是在软件过程中的每一步都进行的“保护性活动”。
SQA主要有基于非执行的测试（也称为评审）、基于执行的测试（即通常所说的测试）和程序正确性证明。
软件评审是最为重要的SQA活动之一。
它的作用是，在发现及改正错误的成本相对较小时就及时发现并排除错误。
审查和走查是进行正式技术评审的两类具体方法。
审查过程不仅步数比走审多，而且每个步骤都是正规的。
由于在开发大型软件过程中所犯的错误绝大数是规格说明错误或设计错误，而正式的技术评审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。
软件配置管理（SCM，Softwareconfigurationmanagement）是应用于整个软件过程中的保护性活动，它是在软件整个生命周期内管理变化的一组活动。
软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。
除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。
一旦一个配置对象已被开发出来并且通过了评审，它就变成了基线。
对基线对象的修改导致建立该对象的版本。
版本控制是用于管理这些对象而使用的一组规程和工具。
变更控制是一种规程活动，它能够在对配置对象进行修改时保证质量和一致性。
配置审计是一项软件质量保证活动，它有助于确保在进行修改时仍然保持质量。
状态报告向需要知道关于变化的信息的人，提供有关每项变化的信息。
三、软件项目管理的组织模式
软件项目可以是一个单独的开发项目，也可以与产品项目组成一个完整的软件产品项目。
如果是订单开发，则成立软件项目组即可；如果是产品开发，需成立软件项目组和产品项目（负责市场调研和销售），组成软件产品项目组。
公司实行项目管理时，首先要成立项目管理委员会，项目管理委员会下设项目管理小组、项目评审小组和软件产品项目组。
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）承认不断改进软件工程实践的必要性。
五、编写《软件项目计划书》
项目组成立的第一件事是编写《软件项目计划书》，在计划书中描述开发日程安排、资源需求、项目管理等各项情况的大体内容。
计划书主要向公司各相关人员发放，使他们大体了解该软件项目的情况。
对于计划书的每个内容，都应有相应具体实施手册，这些手册是供项目组相关成员使用的。
六、软件配置管理
是否进行配置管理与软件的规模有关，软件的规模越大，配置管理就显得越重要。
软件配置管理简称SCM（SoftwareConfigurationManagement的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。
配置管理的使用取决于项目规模和复杂性以及风险水平。
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这样巨型规模的软件项目，并生产出高质量的产品，才有理由宣称自己的软件项目管理能力达到了一个“自主自足”的水平。
九.为什么要有项目管理？
没有项目管理，项目也有可能成功。
但没有管理的项目，很难保证项目的利润空间，对公司来说，亏损的风险就大。
所以我们要有项目管理，以保证公司在总体上是盈利的，注意不是每一个项目都要盈利。
另外，有了项目管理，就有了管理改进的基础，无论刚开始的项目管理多么糟糕，只要有管理，就有了改进的可能性，至于能不能得到改进，以及改进的快慢，则取决于两个因素：
一个是人，特别是各级管理者；另一个是利益。
关键是"利益"，准确的说是"利益的分配"，在权责利明确的前提下，人才能充分的发挥作用。
还需要指出的是"利益"是多元的，这里的多元不仅指利益的具体形式，而且指利益的受众是多元的，包括客户方相关人员个人的利益。
十.为什么要有专职的项目经理？
专业化是一个趋势，因为在专业化的条件下，可以有效降低成本，提高利润率。
项目经理的工作内容归根到底只有一项：
识别并管理风险。
这项工作的目的是控制项目成本。
由于项目的风险是多方面的，而且风险的表现形式也是多种多样的。
从风险范围上来说，既有公司内部风险，也有和客户交流、合作的风险；从风险的类型上来说，既有管理风险，也有技术风险；从风险产生的阶段来说，包括了从业务分析到上线后维护的项目周期各个阶段。
我认为一个项目经理是否优秀，主要是看他/她能在多大程度上提前识别并消除风险，而不是弥补和解决了多少问题（风险未被及时识别或妥善处理，就会转换成问题）。
当然能弥补和解决问题的项目经理也是相当合格的，但还不够优秀。
十一.项目组的范围界限在哪里？
项目组的范围界限可以有三种划分：
1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员，包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责该项目开发的人员；
2、包括客户方项目经理、业务需求提出人和测试人，包括开发商具体负责该项目开发的人员；
3、仅包括开发商具体负责该项目开发的人员。
大部分人在思想上可以接受范围1，而在实务中接受的是范围3。
而我个人认为项目经理，特别是开发商方面的项目经理应该采用的是范围2。
对项目组范围理解不同，将影响项目经理对工作的处理方式，范围1实际上是很虚的，在项目管理实务操作中没有太大的意义；而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来，也就是所谓的甲方、乙方。
在这种对立的前提下处理项目的分歧和矛盾，效果肯定要打折扣。
而按范围2来理解，在项目管理实务中项目经理就必须要让客户方和该项目有密切关系的人也接受这一观点，从而拆除双方之间的"障碍"，达到相互信任、相互尊重、共同协商解决问题的良性氛围，以达到降低项目外部风险的目的。
当然，这样就增大了项目经理工作的难度，但对项目的成功则是很重要的。
十二.怎样才能算是一个成功的项目？
对"成功项目"的标准解释为：
项目范围、项目成本、项目开发时间、客户满意度四点达到要求。
我认为其实只有一点--利益。
项目范围、客户满意度主要代表客户的利益，项目成本主要代表开发商的利益，项目开发时间同时影响双方的利益。
但每一个人关心的"利益"是不同的。
十三.软件项目管理的成功原则
1平衡原则
在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是最容易忽视的，也是软件系统的用户、软件开发商、销售代理商最不想正视的，那就是：
需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了"做什么"，定义了系统的范围与规模，资源决定了项目的投入（人、财、物），工期定义了项目的交付日期，质量定义了做出的系统好到什么程度，这四个要素之间是有制约平衡关系的。
如果需求范围很大，要在较少的资源投入下，很短的工期内，很高的质量要求来完成某个项目，那是不现实的，要么需要增加投资，要么工程延期；如果需求界定清
升级会员 