摘要

软件产品的开发比针对一个特定的用户的需求的开发涉及到更多的开发问题。集成的项目（多个子项目）管理的概念在管理具有更高复杂性的产品开发时是很有用的，本文主要讨论集成项目管理在软件产品开发中的应用。 本文首先阐述了应用开发和产品开发的区别，简单介绍了产品开发的特殊领域，以及如何将整个产品开发组织成子项目，这些子项目如何组织以效地协作，如何管理解决细节问题的子项目间的接口。
关键字 –产品管理，集成的项目管理
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）的框架。在产品开发的启动阶段，许多功能组因许多工作特性而形成。但并不是所有的功能。例如，市场组的形成不同于开发组，但开发组可能会与产品支持组有所重叠。同时，应该有意识地努力来正式将团队组织到已经定义好的框架中。在以上所讨论的模型中，每一个组件是产品开发的一个子项目。每一个子项目都应该有明确定义的范围、进度、资源和成本边界。每一个子项目的项目经理对项目边界负责。下图表示项目体系结构如图2

  图2 子项目的接口体系结构
  产品经理由子项目经理辅助来负责产品管理。对于每个子项目，子项目经理（SPM）负责相应的团队的管理。这并不是新概念，但是这里所指的是，为了有一个成功的产品管理，这个框架并没有清晰地定义和组织，有许多实例都假定使用此结构，但是，团队间在范围、资源甚至成本方面都还实际上很模糊。
  4.2 高级WBS
  创建高级工作分解结构（WBS）是进行一个完整的集成项目的第一步。所选择的结构影响如何管理项目。功能结构增加了接口的数目和复杂性。WBS的级别可以用以下方式来选择：
  ● 产品开发中所涉及到的所有活动
  ● 可以给每一个活动分配一个或多个组
  ● 减少重叠
  ● 为每个子项目经理在子项目范围内确定功能留有余地
  如图3所示可以给出一个责任分配矩阵

  图3责任分配矩阵的例子
  4.3 管理接口
  高级别的工作分解结构定义了子项目的范围，自此，子项目的项目经理具有执行工作分解结构的任务的责任。每一个子项目与其它子项目都有独立的接口。一个子项目中一个任务的输出，形成另一个子项目中一个任务的输入，这就是接口（图4）。例如，错误消息编号模式，是体系结构组的输出，它又是形成更低一级设计的开发组的输入。

  图4 在子项目间的接口
  接口管理是管理这些内部依赖的系统的方法。图5表明了在定义和管理多项目系统中的接口所涉及的步骤。

  图5 接口管理
  5．SMCC经验
  SlimCIM XXX 单元控制器（SMCC）是一个监控软件产品，它借助于表面安装技术SMT行业的通用设备模型，来适应机器，监控机器的制造过程和设备使用，如今，SMCC已经成为XXX通讯企业工厂的标准的工厂过程和设备监控软件系统。
  SMCC产品在3年前开始开发。最初的2年，它在新加坡软件中心更象一个应用开发项目在运行。随着产品增长越来越大，有了更多的客户，必须有更多的开发进程，维护问题也大量涌现，将来产品的方向也变得更加复杂。于是需要特定的方法来进行产品开发，这不同于应用开发，它的实现与处理模型已经在3中阐述。看看上面的模型，有四个要增值的组件：
  ● 产品策略决策 （PSD：Product Strategy Decision）决定将来产品的路线。
  ● 产品特性控制组最终确定软件产品的需求。
  ● 独立的体系结构，对所有的开发组都一样，确保设计的完整性。
  ● 独立的集成和配置管理组，来负责集成、配置管理、测试、打包。
  一旦这个多功能框架工作正常，组与组之间的接口又成了问题。如果不集成进度，密切关注接口，就不能监控进度。这时就引入了集成项目管理的概念。我们感到集成的概念应该早点实施，尤其，将整个产品开发组织成不同的子项目，并且，在产品开发周期一开始就用集成项目管理方法来管理整个开发。否则功能组的僵化变得更加严重，以致于很难形成一个平滑产品管理的框架工作。
  这种方法的优点没有别的，就是用系统的方法来管理整个产品开发，可以更好地预测在规定的时间、成本下项目的交付成果。根据我们的经验，执行的困难是：
  ● 正确地从所涉及到的不同的组购入。
  ● 缺少对所有关心的问题的正确的培训。通用的语言和项目词汇在多个项目交互中是重要的。
  ● 就可交付物的可预测性而言的组织能力，一个子项目的不确定性也会影响其它的子项目。
  根据这些学习经验，产品开发过程可以在SSC上定义，以便将来的软件开发能从一开始就主动遵从系统的方法。
  6．结论
  产品开发的集成项目管理在硬件行业已经广为接受。在应用于软件产品时，就子项目的组织而言略有不同。通过合适的过程建摸，仔细考虑这些特殊的软件开发特性，IPM的原则可以有利地应用于软件产品开发。
  7．参考
  1） XXX数字系统分发（CIG）产品管理过程
  2） XXX新加坡软件中心软件开发过程
  3） CE-Q Gate系统生命周期文档---草案-C