4.集成的项目管理
  当项目的交付物由多个独立的团队产品化了，可以应用集成的项目管理（IPM）。集成项目管理的因素有很多，比如：
  ● 功能分布的团队
  ● 地理位置分散的团队
  ● 产品大小
  ● 多种技术
  ● 软件外包
  这些因素使得项目沟通变得分散，以至于产生了需要直接应用于软件产品开发中的集成的需求。集成的需求越大，使用系统的和经过训练的项目管理原则更重要。
  4.1 集成项目管理的框架
  在第3部分讨论的过程模型形成了集成项目管理（IPM）的框架。在产品开发的启动阶段，许多功能组因许多工作特性而形成。但并不是所有的功能。例如，市场组的形成不同于开发组，但开发组可能会与产品支持组有所重叠。同时，应该有意识地努力来正式将团队组织到已经定义好的框架中。在以上所讨论的模型中，每一个组件是产品开发的一个子项目。每一个子项目都应该有明确定义的范围、进度、资源和成本边界。每一个子项目的项目经理对项目边界负责。下图表示项目体系结构如图2

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

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