|
|
知识路径： > 软件架构基础知识 > 软件产品线 > 软件产品线 >
|
|
相关知识点：5个
|
|
|
|
|
软件产品线开发过程分为领域工程和应用工程，相应的软件开发的组织结构也应该有两个基本组成部分，即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。
|
|
|
|
|
|
设有独立核心资源小组的组织结构通常适合于至少由50~100人组成的较大型的软件开发组织，设立独立的核心资源小组可以使小组成员将精力和时间集中在核心资源的设计和开发上，得到更通用的资源。但独立的核心资源小组很容易迷失于建立极好的高度抽象、高度可重用的核心资源上，而忽视了这些资源对应用工程中需求的满足程度，因为这样的结构容易抑制应用工程中的反馈，使得所开发的核心资源无法在整个产品线中获得良好的应用。
|
|
|
|
另外一种典型的组织结构不设立独立的核心资源小组，核心资源的开发融入各系统开发小组中，只是设立专人负责核心资源开发的管理。这种组织结构的重点不在核心资源的开发上，所以比较适合于组成产品线的产品共性相对较少，开发独立产品所需的工作量相对较大的情况。也是小型软件组织向软件产品线开发过渡时采用的一种方法。
|
|
|
|
|
|
Jan Bosch在研究了众多采用软件产品线开发方法的公司后，将软件产品线的组织结构归纳为四种组织模型。
|
|
|
|
（1）开发部门：所有的软件开发集中在一个部门，每个人都可承担领域工程和应用工程中适合的任务，简单、利于沟通，适用于不超过30人的组织。
|
|
|
|
（2）商务部门：每个部门负责产品线中一个和多个相似的系统，共性资源由需要使用它的一个和几个部门协作开发，整个团体都可享用。资源更容易共享，适用于30~100人的组织，主要缺点是商务部门更注重自己的产品而将产品线的整体利益放在第二位。
|
|
|
|
（3）领域工程部门：有一个专门的单位——领域工程部门负责核心资源库的开发和维护，其他商务单位使用这些核心资源来构建产品。这种结构可有效的降低通信的复杂度、保持资源的通用性，适用于超过100人的组织。缺点是难以管理领域工程部门和不同产品工程部门之间的需求冲突和因此导致的开发周期增长。
|
|
|
|
（4）层次领域工程部门：对于非常巨大和复杂的产品线，可以设立多层（一般为两层）领域工程部门，不同层部门服务的范围不同。这种模型趋向臃肿，对新需求的响应慢。
|
|
|
|
|
|
对于中小型软件开发组织来说，我们建议采用一种动态的组织结构，根据产品线的建立方式和发展阶段、成熟程度的变化，由一种组织结构向另一种组织结构演变。这种方法的主要依据是在产品线不同发展阶段，领域工程和应用工程的在总工作量中所占的比例是不同的。例如对于从零开始建立的产品线，在其建立初期，核心资源的开发工作量要大大多于产品的开发。此时集中力量组织成专门的小组进行核心资源的开发，当核心资源基本完成时，可以将该小组部分成员逐步转移到产品开发中。而对于已有多个产品的情况下建立产品线的演变过程使用相反的方向更为合适。
|
|
|
|
这种动态的组织结构可以使中小型组织采用产品线开发方式造成的在人力资源上的压力得到缓解，使人力资源的需求在产品线的整个开发工程中趋于平稳。人员在两种小组之间的流动可以使流动人员作为小组之间信息交流的一种补充方式，虽然这不是一种最好的、合乎规范的信息交流方式，但毕竟也是一种快速有效的方式。组织结构的变化对产品线来说是一个很重要的问题，需要制定相应的变化规划并要有良好的管理技术的支持来保证整个产品线的成功。
|
|
|
