软件产品开发的集成项目管理(上)

软件产品开发的集成项目管理（上）

摘要

软件产品的开发比针对一个特定的用户的需求的开发涉及到更多的开发问题。集成的项目（多个子项目）管理的概念在管理具有更高复杂性的产品开发时是很有用的，本文主要讨论集成项目管理在软件产品开发中的应用。本文首先阐述了应用开发和产品开发的区别，简单介绍了产品开发的特殊领域，以及如何将整个产品开发组织成子项目，这些子项目如何组织以效地协作，如何管理解决细节问题的子项目间的接口。

关键字–产品管理，集成的项目管理

1.介绍

软件开发有两种业务模式。一个是针对特定用户需求的软件开发（应用开发），第二个是面向市场的软件开发（产品开发）。第一种模式，由唯一的客户承担全部开发费用，并提出软件需求。而第二种模式，开发费用来自多个用户（潜在的要购买此产品的用户）。没有特定的用户提出需求。而且产品要安装在不同的地点，所以在开发产品时还要考虑采用通用的解决方案。

2.在本文中区别项目开发和产品开发是很重要的。从管理的观点来看二者的区别主要有以下几点：

2 .1软件需求的所有者

在产品开发中，没有特定的用户提出软件需求。软件产品的特征是从不同来源获得，如客户、市场、技术支持组、当前的技术趋势等等。除此以外，还要有一个团队来实现需求，并管理产品开发中的任务。

2 .2市场和技术支持

当产品开发工作完成，开始产品销售时，还要有有力的市场活动，这就是需要售前售后的

技术支持。

2.3 打包和分发

产品打包和准备软件产品分发是产品经理的职责。这在应用开发中是很少关心的，因为应用开发不需要大量分发。

2.4许可证和合法发布

由于软件产品有很多用户，所以软件产品的许可证的管理成为一项重要任务。为此需要设计一种特殊的许可证控制机制。合法性方面如产品命名、整理专利文档、版权等，也是产品管理的职责。

2.5产品维护

由于用户和部署软件的站点的多样性，产品维护比应用开发要复杂得多。不同的站点要安装不同版本的软件。

2.6多线程开发

当软件演变成了大型产品时，开发的范围也扩展了，因而不易于在一个线程中管理所有的开发。可以将它分成多个线程，并对每个线程分别管理。这也给集成管理和版本管理增加了复杂性。

以上开发方面不在我们的标准软件开发过程（SDP）的讨论之列，SDP跨越了从需求收集、计划、系统测试和发布的过程。SDP模型不适合软件产品开发附加的需求，这里引进一种新的软件开发过程模型，目标是对整个软件产品的开发进行全局管理。这种模型，可以很实用地帮助将产品开发组织成有着多个子项目的主项目，这是集成项目管理的基础。

图1产品开发过程模型

3.产品开发过程模型

考虑软件产品开发的特殊性，并借用硬件行业的观点，以下方面构成产品开发的过程模型●市场

●技术支持

●产品策略描述

●侯选特性列表和版本计划

●体系结构开发

●软件开发

●集成和配置管理

图1解释了过程接口和逻辑流程。多数活动都是显然的和直观的，在这个案例的解释是合适的。以下部分对上述活动进行了解释。

3.1市场

市场是由促销和与客户联系的部门启动的前导工作。市场部负责从技术的观点和商业的观点识别客户需求。客户的需求形成了产品策略描述。其它的职责还有：为客户使用创建产品描述，报价单、宣传手册以及其它的市场材料。

3.2 技术支持

支持活动包括产品在客户处的安装，产品部署、咨询和客户培训。支持组还要负责收集并识别客户新的需求，并输入到产品策略决策和特性列表中。

3.3产品策略描述

产品策略描述是产品策略和产品路线过程的输出结果。要形成一个专门的团队来负责从市场、支持组或其它工程组收集信息并正确表示，这些策略决定被写在产品策略文档中。

3.4 特性侯选列表&版本计划

特性侯选列表（FCL）是一套在版本中要优先考虑的特性。FCL提供了一个起点，对于一个版本来说可以选择或确定一个更小的子集。特性控制委员会拥有FCL（产品的需求）。

3.5 体系结构开发

体系结构开发的开始和在软件生命周期中持续的进化都在体系结构开发这个活动中进行。独立的体系结构组确保设计的一致性和所有功能区域的互译性。体系结构组的权限和职责是：

●创建产品线的概念和原则

●标识层与接口

●标识通用机制和服务

●定义、原型和通用机制的增强，如错误处理和内部进程通讯协议

●与产品线、概念和原则的项目成员的沟通

体系结构组通常都是由有着扩展领域和工程经验的专家组成的全职的小团队。

3.6软件开发

依据版本计划和商业需求，项目经理要分配特定的项目组来开发软件。一个产品开发中不止一个开发组。这些开发项目中的每一个都可以看作一个应用开发（看前面的定义），有它自己的项目经理和项目计划。已存在的产品的维护也应该被看作另外一个开发项目，需要识别团队成员并进行责任分配。

3.7集成和配置管理

集成和配置管理（CM）组的责任是：

●增量开发（与体系结构组的协作）

●集成并发布经过验证的子系统

●客户版本库的配置管理

●除单元测试外，开发测试策略、测试计划、测试案例

●所有测试运行的协同

●确认并标识所有的软件组件

●创建软件分发介质

软件产品开发的集成项目管理（下）

4.集成的项目管理

当项目的交付物由多个独立的团队产品化了，就可以应用集成的项目管理（IPM）。集成项目管理的因素有很多，比如：

●功能分布的团队

●地理位置分散的团队

●产品大小

●多种技术

●软件外包

这些因素使得项目沟通变得分散，以至于产生了需要直接应用于软件产品开发中的集成的需求。集成的需求越大，使用系统的和经过训练的项目管理原则就更重要。

4.1 集成项目管理的框架

在第3部分讨论的过程模型形成了集成项目管理（IPM）的框架。在产品开发的启动阶段，许多功能组因许多工作特性而形成。但并不是所有的功能。例如，市场组的形成不同于开发