在开发该系统之前，我们公司一直致力于电力领域单个软件系统的开发，在不同的时期为适应各电力公司需要开发过：电费核算系统、收入管理系统、客户服务系统、业务授理系统、电能管理系统、负控管理系统等局部范围的电力管理系统，这些系统之间存在很多的公用部分和联系，但由于是在不同的时间、由不同人的负责、客户的管理水平等制约因素下开发的，因此缺乏统一的规化。所以为了适应电力市场的发展要求，我们公司通过深入的领域分析，以“用电营销”和“客户服务”为核心理念，采用软件产品线技术统一规化以革新方式建立用电营销构件库。

　　作为项目经理的我，深感责任重大，由于初次使用产品线的方式开发软件，为了降低实施的风险我建议采用增量的实施方法，将整个工程分为三期工程。一期工程主要为电费核算系统、收入管理系统、业扩系统开发核心资源。收入管理系统是整个工程的核心部分。通过客户服务部分对用户进行报装注册与变更处理；通过电费核算系统对用户发行电费；通入收入管理系统的业务功能对用户发行的电费与违约金进行收取；通过收入管理模块的凭证处理功能完成业务处理数据的账务管理。二期工程主要将核心资产演化成产品，推向各个电力局，适应当前的“省、市、县、所“四级营销机构的需要。在这阶段关注：1、产品的客户满意度； 2、演化产品的周期，与以前的产品开发作比较、与其它同行提供的产品开发作比较。从这两点评估产品线实施的效果。为下一期工程的提供经验提导、并增强开发团队的信心。 三期工程在公司领导评估二期工程实施成功后，对客户服务系统、计量管理系统、用电检查系统、台区管理系统等进行核心资源开发，并演化成适合各个电力局的产品。

　　在工程实施时，我们首先对以前的可复用资产进行整理：

　　1、对以前开发的系统的设计结构、数据流程、管理规则做全面的分析，对所有系统文档做一次彻底地整理，将系统的原代码统一收集管理。

　　2、在上述的基础上，对原来系统一些好的业务流程，效率高、质量好的系统组件当满足当前体系统构的情况，分别从代码中抽取出来，并对有价值和文档和和代码、组件实行数据库管理。详细地记录了各组件在原系统中的使用环境，编程语言、接口定义等，为下一步新系统的设计提供了大量的“资产”。

　　通过与市场部的深入讨论，我们将产品的定位如下图所示：

　　这样划分的理由是：不同级别的电力公司规模大小、职能部门、功能版图区别非常大，省电力局主要需要决策功能，通过对下级的市电力局收集的数据做一些汇总和集中，不同的省电力局的所需要的功能虽然好多地方都大致相同，但也都有自己的“独特之处“。而市电力局一般隶属于省电力局，具有一定的决策功能和所有的业务处理功能，市电力局则界于省电力局和县电力局两者之间。

　　确立了产品线开发的基本思路以后，我采用一种动态的组织结构进行开发，初始阶段将公司主要技术力量集中起来进行核心资产开发；计划当我们的核心资产开发已经有几个实际产品之后，逐步将重点放到产品开发上并不断演化我们的核心资产。我决定核心资产的开发先重点考虑“市电力局”级别，这样做的好处：将来开发县电力局院产品，只需做适当的功能裁剪；另外为开发省电力局系统提供数据。

　　建模我们采用ROSE 2003，对需求分析的评估则采用RequisitePro，软件开发平台选用J2EE，数据库选用ORACLE，这样做主要考虑J2EE的平台无关性。在开发平台的选择中我们曾经考虑选用.NET，因为.NET开发相对简单和快捷，但.NET限制服务器在WINDOWS平台上运行，考虑我们今后客户中的“甲级设计院”，服务器一般都采用UNIX系统，为便于今后产品的移植，我们选择了J2EE。版本控制工具选用ClearCase。

　　核心资产开发最主要的是如何从众多不同需求中抽象出相同部分，并进行概括或分类。比如我们对电费核算子系统，输入的部分是：电表电量、抄见电量、分类电量、线损、变损、总有用功、总无用功等等，输出则为与用电用户的应交电费。但是对电费的算法，基本每个省电力局有自己的一套公式，有时连同一个省下的市电力局、县电力局都可能各不相同：有的要考虑滞纳金计算；有些情况要考虑异常情况的计算如用户换表、坏表等；有时对一些特殊用电用户采取一些优惠政策；有的采用二部制计法等等。如何解决电费计算时多目录电价、多附加电价、非规范收费政策以及多地域运行的特点，灵活的适应用户的要求是我们核心资产的重点。

　　面对我们从各个来个省电力局以及其下属市、县、所电力局的收集不同的电费计算方法，我以及我们的系统分析员确实伤透了脑筋。如果全部采用抽象类或接口来实现，那么抽象的层次肯定比较多，产品开发人员今后很难理解核心构件的意图，而通过组装类构造的话，组装类的开发工作量比较大。而最大的问题则是如何建立适应不同用电用户的电费计算（如各类特殊用电用户）的需要。我们最终的做法是：收集和整理各个电力局的电费计算方案中所有考虑因素的全集，对这些全集进行分类，然后我们设计两种方案：

　　1、通过程序自动的根据己定义好的电费计算模型进行自动的计算电费。
　　2、由于第一种方案在的计算模型某些方面的遗漏，并且电费计算模型处于不断的演化中，所以我们设计了第二种方案：使用MVC设计模式设计成用户自己可以控制的控件，在控件间设定一定的逻辑表达，由用户自定义计算电费；两种方法进行核对。这也是系统取名“电费核算”的由来。这种设计虽然核心资产的开发周期相对较长，但我觉得是值得的。因为大大缩短了今后产品的开发周期，并减少了产品定制时的错误，实现了用户的“兴奋需求”。

　　我觉得最为困难的是在众多不同需求中如何抽象出相同部分，而对不同部分进行灵活的组装或构造，比如业扩子系统中的新装业务包括高压新装、低压新装、零散居民、批量新装、紧急新装、紧急新装和大型客户新装。这些新装业务虽然存在一些不同，但存大量的通用过程，因此，我们参考各个新装业务，抽象出最长“新装业务”流程：业务受理→制定供电方案→方案审批→工程设计→工程施工→中间检查→工程验收→立户建卡→资料归档；各种新装类型在通用流程做一些裁剪满足各自的需要；紧急新装业务由于业务的紧急性裁剪成业务受理→工程施工→资料归档；还有零散居民新装业程裁剪成业务受理→制定供电方案→工程实施→立户建卡；等等。这种情况下我根据流程最长的需求开发所有需要的构件，构件间的接口做成松藕合。演化成产品时进行构件组装。

　　2005年3月一期工程完成。就目前我们通过核心资产演化的产品还不多，所以很难评价核心资产开发的整体质量。这个问题的解决有赖于更多实际产品的开发以及更多的用户反馈。本次软件产品线开发，我觉得有如下一些收获：1）对我们公司员工的素质是一个大锻炼，2）通过核心资产的更多开发，我们今后产品开发的工作量、产品开发质量都会有数量级的改善。