系统架构师论文-论软件产品线技术(设计院信息管理平台)

论软件产品线技术

设计院信息管理平台

[摘要]

本人作为某软件公司负责人之一，通过対位于几个省的国家甲级、乙级、丙级设计院的考查和了解，我决定采用软件产品线方式开发系列《设计院信息管理平台》产品。 该产品线开发主要有如下功能： 1）知识、资源管理平台； 2）内部管理平台； 3）基于WEB的办公平台。软件产品线最难开发的是核心资产的分析与建模，如何从用户量多不同需求中抽象出共性的东西，如何使得核心资产通过继承、参数化等方式能够组装成用户实际需要的产品，我以及我们公司的系统分析员做了大量工作。概括起来我们用了如下三种方式： （1）加强核心资产开发的灵活度，部分产品作成用户能够自定义的功能，彻底免除产品化时的问题，但这样做难度很大，实施周期长； （2）说服客户微调管理模式，以使得管理适应我们的产品线功能。这样做无疑是双赢的，但是实际不见得会行得通； （3）根据流程最长的需求开发所有需要的构件，构件间的接口做成松耦合。演化成产品时进行构件组装。

[正文]

本人所在软件公司于2003年6月承接了某《化工乙级设计院管理平台》工作，主要功能包括： 1）知识、资源管理平台： 2）内部管理平台： 3）基于WEB的办公平台。 该项目于2004年2月成功投入运行，得到客户的肯定。该项目的开发成功以及通过与该设计院员工的接触，対我触动很大。我作为公司主要负责人与其他负责人研究后，决定进入“设计院信息工程"这样的一个行业领域做深度软件产品开发。理由有如下几点： 1）设计院是一类知识技术密集型单位，员工素质较高，管理比较规范，有完善的硬件设施,性能良好的局域网平台，具备了实施信息化管理的基础； 2）设计院的图形工作站所用的二维、三维软件或其它工程计算软件都用正版软件且价格比较昂贵，高层领导他们有支付软件费用的观念； 3）设计院开发一个项目，从可行性分析到项目实施、项目交付、到项目后期支持往往需要几年的时间，这期间产生巨量的、非常重要的各类文档（比如可行性分析报吿、进度计划、项目条件、变更记录、会议纪要、计算书）和大量工程图，在整个项目开发期间这些资料要提供给项目开发人员查阅或使用、修改，这些资料的安全性、完整性都是至关重耍的，这些资料既是知识、技术的承载体、又是法律的承载体；这些资料保存年限是30年或更长。目前,设计院大都设立专门的部门，但基本都是采用手工管理。 4）设计院的客户在项目开发期间以及项目上线以后一段时间都希望得到良好的技术服务。技术支持既包括现场技术服务，也包括远程服务。现在的远程技术支持是很被动的接听客户电话、传真或EMAIL,没有建立专门的平台也没有进行规范管理。有了対设计院内部运作的一般了解后，我们将已经开发成功的某《化工乙级设计院管理平台》精简做成演示原型，我带着这个原型以及対《设计院信息管理平台》的设想来到本市各类设计院：省级建筑设计院、市级建筑设计院、省级电力设计院、省级化工设计院、大型企业内部设计院等大大小小20家，征求他们的意见和建议，了解他们対该管理平台的认可度。 我感到很欣慰的是80%的设计院高层领导対我们的产品设想有兴趣，并提出了针対自己单位的需要扩充或压缩的功能。随后的一个多月我带着补充修改后的原型产品，来到另外几个省会的设计院征求意向， 结果：1）大部分的设计院目前没有完善的管理平台；2）如果我们真能设计出满足他们需要的产品，他们有兴趣购买。 通过持续2个月的调查我们公司于2004年5月决定投入这个行业的软件开发，因为要开发大量类同的软件产品，公司决定采用软件产品线开发。我们的対该系列产品的设想是：

这样划分的理由是：不同级别的设计院规模大小、管理模式、职能部门、待管理的资源区别非常大，国家甲级设计院除了设计以外，还能做技术咨询、工程总承包、建设监理、设备材料供货等工作，承接国际性工程。而丙级设计院一般隶属于相关厂矿企业，只能做本单位的项目开发，所以管理规模、管理资源相対较少，乙级设计院则界于两者之间。在同级别的设计院中，则因为设计院的性质不同，开发所采用的歩骤和侧重点不同。该系列产品主要 功能： 1）知识、资源管理平台：管理内容包括工程图纸、各类文档（可行性研究报吿、项目计划、条件变更单、项目会议纪要、来往传真等）、标准图库、标准及规范、招投标书、合同等; 2）内部管理平台：包括项目管理、人力资源管理、供应管理、客户关系管理、员工绩效管理等 3）基于WEB的办公平台：用于対客户的远程技术支持、保持与关键设备供应商、国家级研究机构的快速联系、快速获取新技术新行业值息、推厂公司形象。 确立了产品线开发的基本思路以后，我采用一种动态的组织结构进行开发，初始阶段将公司主要技术力量集中起来进行核心资产开发；计划当我们的核心资产开发已经有几个实际产品之后，逐歩将重点放到产品开发上并不断演化我们的核心资产。我决定核心资产的开发先重点考虑“乙级设计院"级别，这样做的好处：将来开发丙级设计院产品，只需做适当的功能裁剪；另外避免了开发甲级设计院管理平台的技术风险和项目风险。 建模我们采用ROSE 2003,対需求分析的评估则采用RequisitePro,软件开发平台选用J2EE,数据库选用ORACLE,这样做主要考虑J2EE的平台无关性。在开发平台的选择中我们曾经考虑选用.NET,因为.NET开发相対简单和快捷，但.NET限制服务器在WINDOWS平台上运行，考虑我们今后客户中的“甲级设计院"，服务器一般都采用UNIX系统， 为便于今后产品的移植，我们选择了 J2EE。版本控制工具选用ClearCase。核心资产开发最主要的是如何从众多不同需求中抽象出相同部分，并进行概括或分类。比如我们対员工绩效管理分析时就发现，相同的部分是：输入均为图纸量、其它文档、项目总利润、职工职称等，输出则为与项目相关的奖金。但是対奖金的算法，基本每个单位有自己的一套公式：有的対图纸量分专业计算复杂度系数；有的按本专业计算复杂度（比如关谜技术、新技术或普通技术）；有的按复用度（该图纸与原有图纸的相似度）计算折扣；有的不分职称只计算单纯的图纸量；有的则夸虑职称或工龄；有的将计算书折算为图纸进行考核；有的专门対计算书或其他文挡考核、有的计算考虑加既有的不夸虑。 面対我们从20来个设计院收集不同的考核方法，我以及我们的系统分析员确实伤透了脑筋。如果全部采用抽象类或接口来实现，那么抽象的层次肯定比较多，产品开发人员今后很难理解核心构件的意图，而通过组装类构造的话，组装类的开发工作量比较大。而最大的问题则是如何适应用户考核方法的变更。我们最终的做法是：收集和整理20来个设计院的考核方案中所有考虑因素的全集，対这些全集进行分类，然后使用MVC设计模式设计成用户自己可以控制的控件，在控件间设定一定的逻辑表达，由用户自定义计算公式计算奖金。这种设计虽然核心资产的开发周期相対较长，但我觉得是值得的。因为大大缩短了今后产品的开发周期，并减少了产品定制时的错误。 本次核心资产开发中公用部分较多的是対“知识、资源管理平台“的开发，虽然最初我们也了解到不同设计院管理方法也有所不同，我们在研究几家管理比较好的设计院方案后，拿出了一套比较规范的管理流程方案，这几个设计院表示愿意改进他们的管理措施以适应我们的方案。这一点是我本次产品线开发最值得骄傲的地方，实现了 “双贏"一一客户改进了他们的管理，我们节约了开发成本。 我觉得最为困难的是在众多不同需求中如何抽象出相同部分，而対不同部分进行灵活的组装或构造比如本次设计的核心模块：“项目管理"的流程：项目开发-可行性研究报吿-可行性评审-初歩设计-初歩设计评审-施工图设计-施工图交底-项目后期支持；但有的项目由生产厂家进行可行性研究，那么同样省略的就有可行性研究评审；还有的小型项目，不需要做初歩设计，项目开工后直接进入施工图设计。这种情况下我根据流程最长的需求开发所有需要的构件，构件间的接口做成松耦合。演化成产品时进行构件组装。 因为目前我们通过核心资产演化的产品还不多，所以很难评价核心资产开发的整体质量。这个问题的解决有赖于更多实际产品的开发以及更多的用户反馈。本次软件产品线开发，我觉得有如下一些收获： 1）対我们公司员工的素质是一个大锻炼， 2）在开发过程中我们也与设计院一些高层领导及部门领导结下了深厚的友谊，加深了対该类技术密集型单位的认识，非常便于我们今后推厂最终产品； 3）通过核心资产的史多开发，我们今后产品开发的工作量、产品开发质量都会有数量级的改善。