一种流动式领域工程分布层状结构图软件产品线组织方法技术领域
本发明属于计算机领域。
背景技术
软件产品线方法是软件体系结构和软件重用技术发展的结果, 基于产品线的重用十分符合软件重用发展趋势：从小粒度的重用（代码，对象）到构件重用，再发展到策略重用以及大粒度的部件（软件体系结构、结构框架、过程、测试实例和产品规划）重用,都对软件工程的发展起到了巨大的推动作用。为此，SEI提出了软件产品线的开发方法，并于1998年10月正式发表了软件产品线框架。
(1)什么是产品线
卡耐基·梅隆大学软件工程研究所（CMU/SEI）对软件产品线的定义是：“产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统遵循一个预描述的方式，在公共的核心资源（Core Assets）基础上开发的。”
（2）软件产品线的基本活动
软件产品线开发包括核心资源库的开发和利用核心资源库进行的产品的开发，这两者都需要技术和组织的管理。核心资源和产品开发可以同时进行也可以交叉进行。图1说明了各基本活动间的关系：每一个环代表一种基本活动，三个环交错连接在一起互相重叠，不停地变化，多个箭头表示各自的更新，这些更新可能是自发的，也可能是其他基本活动引发的。
发明内容
本发明提供一种流动式领域工分布层状结构图软件产品线组织方法，以解决软件产品线开发包括核心资源库的开发和利用核心资源库进行的产品的开发，这两者都需要技术和组织的管理的的问题。
本发明的技术方案是：软件产品线的基本活动有三类：
核心资源的开发（即领域工程）
产品线范围划分(Scoping):对组成产品线的产品的描述。
核心资源的生产：包含体系结构、组件、测试计划及用例、需求说明书、领域模型以及所有产品都需要的技术和非技术性资源的开发。
产品计划的制定：描述产品如何从核心资源中生成。
产品的开发（即应用工程）
在核心资源的基础上，结合各自产品的需求开发最终产品。
组织管理
主要是组织结构和人力资源的配备和演化，以及产品线技术活动之间的协调等。
软件项目组织管理
项目组织管理就是为了满足甚至超越项目干系人对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去的一种管理过程[4]。这个过程覆盖了项目开发中的各种活动，涉及人的因素、项目组织、资源管理、质量管理、项目进度计划和控制、报表与文档、交付验收等诸多方面。
软件项目组织管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现 70%的项目是因为管理不善引起的，而非技术原因，于是软件开发者开始逐渐重视起软件开发中的各项管理。
软件产品线组织管理
软件产品线的组织管理往往比传统单一系统的组织管理遇到更多问题，因为前者常常比后者规模大。在软件产品线工程组织内，需要更多的职责划分，例如一些员工负责领域工程，一些员工负责应用工程，还需要特殊的人员处理领域工程和应用工程之间的关系，以及高层次架构师和系统评估师等等。由于软件产品线强调复用、统筹级别高的特殊性，对人员能力的要求也相比开发单一系统的企业更加复杂，比如构架师应更加注重构架的健壮性，平台负责人需要有预估需要变化的前瞻性等等。因此企业或组织的软件产品线实现方式也十分复杂。
对于企业或组织来说，判断自身需要选择哪种组织结构至关重要，企业或者组织需要在考虑人员能力、偏好等人文因素的基础上选择一种适应的、高效的组织结构，即人员的分配方式来确保软件产品线能在企业或组织中高效的实施。
传统的软件产品线组织结构
传统的软件产品线有以下两种组织结构：分布式领域工程以及集中式领域工程（主要针对中型企业进行简介，大型企业只需将层状组织结构改成矩阵结构，功能划分为对应关系，特点基本相同）。
分布式领域工程
图2描述了一个面向项目（产品）的组织结构，它由基础的层状结构发展而来，灰色方块代表实施领域工程的组织单元，虚线框内的四个项目单元通常代表具体的具体的用户（群）或市场范围开发专门产品的部门。领域工程的任务分布在这些项目单元中。
在这种结构中，产品的责任依旧在项目单元内部，领域工程的责任是分布的。对于与领域工程相关的决策，工程项目的领导或领导的代表之间必须达成一致。项目经理的主要关注点还是在自己为特定客户开发的产品上，通用工件的决策制定将会变得简单耗时。组织只是在较低层次上实施了软件产品线工程的转变。
集中式领域工程
在这种组织结构中有一个独立部门专门负责领域工程，如上图的灰框部分。
从图3中可以看出，当存在专门的领域工程部门时，四个项目单元变小了。领域工程部门相对于（产品）项目部门的规模可以有所不同，这取决于领域工程部门的工作量与应用工程部门工作量之间的关系。在层状组织的最上层，领域工程部门与其他同属部门可能同属同一个管理者，或者属于一个独立的管理者。领域工程的责任清楚的分配到上图黑框表示的层状组织部门，责权清晰。领域工程部门负责确定平台、所包含的工件以及这些工件如何工作。因此这种结构的决策高效，额外开销比较低。
但是由于领域工程人员集中分组，当组织面临生产压力时，应用部门人员获得的报酬往往比领域人员要高。同时由于领域人员不参与项目开发，可能导致领域人员失去客户关注度，或者开发的通用工件不符合现实需求。
流动式领域工程分布层状结构图
针对以上两种结构的优缺点，同时结合CMU对软件产品线工程组织管理的最新理解，本文提出一种流动式领域工程分布层状结构图。
在图4中，可以清楚的看到领域工程人员是半集中式分布的，领域工程人员多数集中平台负责人的管理之下，但每个项目组内也有一名领域人员协助核心资产的实现工作。同时这种领域人员的分布也不是固定的，领域人员会根据个人特点方向等问题动态的参与到一种轮换中，即在项目部门工作一段时间便调回到领域部门，当有新的项目种类适合该人员时，再被调出。
对人员的分配的及其所对应的责权进行细致分析：
将结构划分为：企业高层、产品线评估师和构架师、项目部分和领域部门三层。
企业高层：在最上层，把持着资金，确定着软件企业具体参与的实践方向。由于软件产品线的特殊性，企业高层需要对软件产品线的高效性与正确性有坚定的信念，并允许企业在一定期限内低盈利甚至是负盈利。报告证明，软件产品线的在实现两个到三个系统间开始盈利。
产品线评估师：根据企业的资金状况、涉及领域、员工数量等使用评估工具及大量案例确定软件产品线范围。同时在企业的日常生产中时刻获取最新的动态以更新软件产品线的范围。
架构师：根据需求以及软件范围确定产品线的架构。其中尤其要注意确保架构的高效性的同时需要保证产品线的健壮性。使得组件在架构中以一种低耦合的方式相互调用，同时又不会相互影响，架构的健壮性保证系统在更替过多个版本之后仍然有稳定的结构。
项目经理：项目经理是企业开发生产的关键，最好是从具有丰富开发经验的开发人员中选出或将人员作为项目经理的备选人从头培养。在软件产品线中，项目经理需要确保每一个系统都是架构的一次实现而非独立开发的系统，需要与试点客户广泛交流以确保架构的本次实现符合需求，在必要时对平台进行变性的定制，
平台负责人：主要负责核心资产的管理，监督领域人员日常工件的维护，同时确定是否将新的变化点作为通用构件加入到核心资产库中，是否有通用构件需要被淘汰。
领域工程人员：作为软件产品线最基层的实现，领域工程人员开发通用构件，为每个构件编写使用说明书，确保构件接口的规范性。与传统结构项目，采用流动式分配中的领域人员大多数时间被管理在一个部门中，所以责权划分比较容易。同时由于流动的特性，领域人员会周期性的参与到项目的实现中，提高架构实现的效率，有利于领域人员获得最新的构件要求，不会失去客户的关注度。在薪酬方面，可以采用一种半计件的方式，即生产一个通用构件可以获得多少收益，构件被重用一次，又会获得多少收益，从而保证了领域与应用工程之间的平衡。
应用工程人员：即实现人员，将架构实现成产品。在这种结构中我们减少了实现人员的流动性，实现人员在相似的系统间工作，体现了人员重用的观点。由于每个通用工件都有明确的接口规范和使用说明书，每次实现过程中也有领域人员的指导，实现工作可以比传统生产变得更加高效。
本发明的优点在于：针对以上两种结构的优缺点，同时结合CMU对软件产品线工程组织管理的最新理解，本文提出一种流动式领域工程分布层状结构图。可以清楚的看到领域工程人员是半集中式分布的，领域工程人员多数集中平台负责人的管理之下，但每个项目组内也有一名领域人员协助核心资产的实现工作。同时这种领域人员的分布也不是固定的，领域人员会根据个人特点方向等问题动态的参与到一种轮换中，即在项目部门工作一段时间便调回到领域部门，当有新的项目种类适合该人员时，再被调出。
附图说明
图1是本发明的产品线基本活动示意图；
图2是本发明的领域工程分布在若干项目中的软件产品线工程组织结构图；
图3 具有集中领域工程的产品线工程组织结构图；
图4 流动式领域工程分布层状结构图。
具体实施方式
软件产品线的基本活动有三类：
核心资源的开发（即领域工程）
产品线范围划分(Scoping):对组成产品线的产品的描述。
核心资源的生产：包含体系结构、组件、测试计划及用例、需求说明书、领域模型以及所有产品都需要的技术和非技术性资源的开发。
产品计划的制定：描述产品如何从核心资源中生成。
产品的开发（即应用工程）
在核心资源的基础上，结合各自产品的需求开发最终产品。
组织管理
主要是组织结构和人力资源的配备和演化，以及产品线技术活动之间的协调等。
软件项目组织管理
项目组织管理就是为了满足甚至超越项目干系人对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去的一种管理过程[4]。这个过程覆盖了项目开发中的各种活动，涉及人的因素、项目组织、资源管理、质量管理、项目进度计划和控制、报表与文档、交付验收等诸多方面。
软件项目组织管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现 70%的项目是因为管理不善引起的，而非技术原因，于是软件开发者开始逐渐重视起软件开发中的各项管理。
软件产品线组织管理
软件产品线的组织管理往往比传统单一系统的组织管理遇到更多问题，因为前者常常比后者规模大。在软件产品线工程组织内，需要更多的职责划分，例如一些员工负责领域工程，一些员工负责应用工程，还需要特殊的人员处理领域工程和应用工程之间的关系，以及高层次架构师和系统评估师等等。由于软件产品线强调复用、统筹级别高的特殊性，对人员能力的要求也相比开发单一系统的企业更加复杂，比如构架师应更加注重构架的健壮性，平台负责人需要有预估需要变化的前瞻性等等。因此企业或组织的软件产品线实现方式也十分复杂。
对于企业或组织来说，判断自身需要选择哪种组织结构至关重要，企业或者组织需要在考虑人员能力、偏好等人文因素的基础上选择一种适应的、高效的组织结构，即人员的分配方式来确保软件产品线能在企业或组织中高效的实施。
传统的软件产品线组织结构
传统的软件产品线有以下两种组织结构：分布式领域工程以及集中式领域工程（主要针对中型企业进行简介，大型企业只需将层状组织结构改成矩阵结构，功能划分为对应关系，特点基本相同）。
分布式领域工程
图2描述了一个面向项目（产品）的组织结构，它由基础的层状结构发展而来，灰色方块代表实施领域工程的组织单元，虚线框内的四个项目单元通常代表具体的具体的用户（群）或市场范围开发专门产品的部门。领域工程的任务分布在这些项目单元中。
在这种结构中，产品的责任依旧在项目单元内部，领域工程的责任是分布的。对于与领域工程相关的决策，工程项目的领导或领导的代表之间必须达成一致。项目经理的主要关注点还是在自己为特定客户开发的产品上，通用工件的决策制定将会变得简单耗时。组织只是在较低层次上实施了软件产品线工程的转变。
集中式领域工程
在这种组织结构中有一个独立部门专门负责领域工程，如上图的灰框部分。
从图3中可以看出，当存在专门的领域工程部门时，四个项目单元变小了。领域工程部门相对于（产品）项目部门的规模可以有所不同，这取决于领域工程部门的工作量与应用工程部门工作量之间的关系。在层状组织的最上层，领域工程部门与其他同属部门可能同属同一个管理者，或者属于一个独立的管理者。领域工程的责任清楚的分配到上图黑框表示的层状组织部门，责权清晰。领域工程部门负责确定平台、所包含的工件以及这些工件如何工作。因此这种结构的决策高效，额外开销比较低。
但是由于领域工程人员集中分组，当组织面临生产压力时，应用部门人员获得的报酬往往比领域人员要高。同时由于领域人员不参与项目开发，可能导致领域人员失去客户关注度，或者开发的通用工件不符合现实需求。
流动式领域工程分布层状结构图
针对以上两种结构的优缺点，同时结合CMU对软件产品线工程组织管理的最新理解，本文提出一种流动式领域工程分布层状结构图。
在图4中，可以清楚的看到领域工程人员是半集中式分布的，领域工程人员多数集中平台负责人的管理之下，但每个项目组内也有一名领域人员协助核心资产的实现工作。同时这种领域人员的分布也不是固定的，领域人员会根据个人特点方向等问题动态的参与到一种轮换中，即在项目部门工作一段时间便调回到领域部门，当有新的项目种类适合该人员时，再被调出。
对人员的分配的及其所对应的责权进行细致分析：
将结构划分为：企业高层、产品线评估师和构架师、项目部分和领域部门三层。
企业高层：在最上层，把持着资金，确定着软件企业具体参与的实践方向。由于软件产品线的特殊性，企业高层需要对软件产品线的高效性与正确性有坚定的信念，并允许企业在一定期限内低盈利甚至是负盈利。报告证明，软件产品线的在实现两个到三个系统间开始盈利。
产品线评估师：根据企业的资金状况、涉及领域、员工数量等使用评估工具及大量案例确定软件产品线范围。同时在企业的日常生产中时刻获取最新的动态以更新软件产品线的范围。
架构师：根据需求以及软件范围确定产品线的架构。其中尤其要注意确保架构的高效性的同时需要保证产品线的健壮性。使得组件在架构中以一种低耦合的方式相互调用，同时又不会相互影响，架构的健壮性保证系统在更替过多个版本之后仍然有稳定的结构。
项目经理：项目经理是企业开发生产的关键，最好是从具有丰富开发经验的开发人员中选出或将人员作为项目经理的备选人从头培养。在软件产品线中，项目经理需要确保每一个系统都是架构的一次实现而非独立开发的系统，需要与试点客户广泛交流以确保架构的本次实现符合需求，在必要时对平台进行变性的定制，
平台负责人：主要负责核心资产的管理，监督领域人员日常工件的维护，同时确定是否将新的变化点作为通用构件加入到核心资产库中，是否有通用构件需要被淘汰。
领域工程人员：作为软件产品线最基层的实现，领域工程人员开发通用构件，为每个构件编写使用说明书，确保构件接口的规范性。与传统结构项目，采用流动式分配中的领域人员大多数时间被管理在一个部门中，所以责权划分比较容易。同时由于流动的特性，领域人员会周期性的参与到项目的实现中，提高架构实现的效率，有利于领域人员获得最新的构件要求，不会失去客户的关注度。在薪酬方面，可以采用一种半计件的方式，即生产一个通用构件可以获得多少收益，构件被重用一次，又会获得多少收益，从而保证了领域与应用工程之间的平衡。
应用工程人员：即实现人员，将架构实现成产品。在这种结构中我们减少了实现人员的流动性，实现人员在相似的系统间工作，体现了人员重用的观点。由于每个通用工件都有明确的接口规范和使用说明书，每次实现过程中也有领域人员的指导，实现工作可以比传统生产变得更加高效。