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

其根本目的是为了让软件项目尤其是大型软件项目的整个软件生命周期都能在管理者的控制之下,以预定成本按期、保质的完成并交付用户使用。

软件项目管理是项目管理在软件行业中的应用，但是和其他的项目管理相比有着自身的特殊性。

首先,软件是纯知识产品,其开发进度和质量有时难以估计和度量,生产效率也难以预测和保证。

其次,软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。

美国国防部曾专门就软件项目失败的原因进行调查，发现大多数软件开发项目的失败，并不是软件开发技术方面的原因，而是由于不适当的管理造成的。

为了解决这个问题，国外各大组织机构与研究者做了很多研究与总结工作，提出了一些典型的项目管理模型。

（1）传统模型
在20实际80年代之前，瀑布模型一直被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。

它的核心思想在于按工序化简，实现与设计分离和结构化的分析与设计方法。

采用瀑布模型可以保证系统在整体上的充分把握，但由于阶段划分过于严格，由大量文档驱动，导致最终开发出的软件产品不能真正满足用户的需要。

V模型是对瀑布模型的一种改进，开发活动和测试活动几乎同时进行，从而极大的减少bug和error出现的几率，但是这样也忽视了测试对需求分析，系统设计的验证，从而导致验收测试后延过长。

快速原型模型则是先建立一个满足基本要求的原型系统，通过测试和运行，有用户提出进一步细致的需求，然后修改和完善原型系统，并反复进行这个过程直到用户满意。

该模型擅于解决需求复杂且不确定的系统，但工作成果浪费的可能性也会很大。

增量模型又称演化模型，它不是在项目结束时一次性提交，而是分块逐次开发的提交。

其核心思想是认为所有的阶段都可以细分迭代，每一次迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

优点在于尽早得到用户反馈，降低风险，持续测试与集成，提高了软件的复用性。

但它要求软件体系结构必须具有开放性，且不能破坏原来已经开发出来的产品。

螺旋模型则吸收了上述几个模型的优点，并在整个开发过程中加入了风险分析，通过将瀑布模型的多个阶段转化为多个迭代过程中，以减少项目的风险。

但是可操作性不高，且不适合小型项目。

（2）RUP
RUP(Rational Unified Process)是Rational公司推出的软件过程模型，它是软件业界迄今为止商品化最成功的软件过程模型。

其目标是确保软件产品达到高质量，能够满足最终用户需求。

它汲取了面向对象的软件工程领域多年来的优秀研究成果，利用了新的可视化建模标准UML(Unified Modeling Language ) ，是软件工程发展的新成果。

RUP作为一个通用过程框架，可以应付种类广泛的软件
系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。

其关键技术包括可迭代的增量式开发、用例驱动和以软件体系结构为中心，这使得RUP非常适宜于开发复杂、技术难度大、需求多变、高风险的项目。

RUP又是可裁剪的软件开发过程框架,各组织可以根据自身及项目特点对RUP进行裁减,在某些情况下RUP甚至可以蜕化为瀑布式开发模型。

可以说RUP是一个非常好的开端,但并不完美,在实际的应用中可以根据需要对其进行改进并可以用OPEN 和OOSP等其他软件过程的相关内容对RUP进行补充和完善，但是RUP及其配套的工具面向高端客户，对客户的财力开发和管理能力要求都很高。

（3）敏捷开发
2001年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，17位软件界专家概括出了一些可以让软件开发团队具有快速工作、迅速响应客户需求的价值观和原则，他们自称为敏捷联盟(Agile Alliance)。

敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论，也不是事实上的标准，而是一种以人为核心、迭代、循序渐进的开发方法。

在高度协作的开发环境中，使用迭代的方式进行增量开发，经常使用反馈进行思考、反省和总结，不断地进行自我调整和完善。

采用敏捷开发不仅保证了软件的质量，而且开发速度也明显提升。

敏捷开发过程的方法很多，主要有：SCRUM，Crystal，特征驱动软件开发，自适应软件开发，以及极限编程XP等等。

然而敏捷开发方法对于提高个人、小型团队的工作效率可能是很有帮助的，但它的某些主张是局部观点而不是全局观点，部分原则也不符合中国国情，所以指导大中型软件企业的研发管理是有很高风险的。

（4）CMM/CMMI
CMM（Capability Maturity Model，软件能力成熟度模型），是评估软件能力与成熟度等级的一套标准，由卡内基·梅隆大学软件工程研究所于20世纪80年代末建立，并在2000年逐步演化成CMMI（Capacity Maturity Model Integration，能力成熟度模型集成），CMMI不仅适用于软件，而且适合软硬件结合的系统。

CMM的成熟度演进框架包含5个由低到高的等级，分别为初始级，可重复级，已定义级，已管理级和优化级，这五个等级是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，它们经过这些阶段逐步前进。

该模型使得确定当前过程能力的工作和识别软件质量和过程改进中的最关键的问题变得容易，从而引导软件组织从自己的实际状况出发进行过程持续改进。

CMMI与CMM相比，覆盖了更多的领域，是包括软件工程、系统工程和软件采购在内的诸模型的集合，以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。

从上个世纪90年代至今，软件过程改进成为软件工程学科的一个主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。

虽然人们对软件项目管理的重要性认识有所提高，但由于软件管理的复杂性，且没有成熟的经验可供借鉴，至今还提不出一套通用的指导原则。

事实上，由于项目的开发环境、需求、规模不一样，也很难有一套适用于所有软件项目的通用模型。

如何做好大型软件工程的需求开发。