论企业应用集成
摘要
2004年 10 月，我参加了XX车站综合信息平台项目的开发，承担项目的方案设计任务该项目力图通过对车站现有信息子系统的集成，以达到共享各子系统的数据，优化企业运输作业流程，提高企业经营管理水平之目的。
本文结合笔者的实践，以该综合信息平台建设项目为例，讨论了企业应用集成技术。在本着集成、开放标准、管理配套的原则下，提出了基于Java 技术的J2EE 应用服务器作为统一的应用集成平台，以集成适配器作为系统集成架构模式的总体设计思路，并着力介绍了该项目关键部件一一集成适配器的构建过程。还就项目的具体实施作了详细叙述。最后，提出了企业应用集成的持续性，并确定了下一步集成的目标。
正文
2004 年 10月，我单位承接了X服务器托管网X车站综合信息平台的建设任务。由于我具有多年的铁路行业软件项目开发经验，所以我有幸被单位指定为该项目的负责人，主要负责项目的方案设计工作。
该车站是一等客货运编组站，车站所在地是矿区，有规模不等的国有煤矿及个体煤矿数十个，车站主要以煤炭运输为主。近些年来，随着铁路 TMIS 系统(铁路运输管理信息系统)建设的逐步深入，该车站建立了若干相应的应用子系统，主要有列车确报系统、车站现在车系统、货票制票系统、车号红外线自动识别系统、货运计划系统、货运安全系统及货车轨道衡计重系统等。车站希望通过综合信息平台的建设达到以下几个目标:(1)实现各子系统间数据共享。(2)能够实时地向企业客户(货主)发布请车、承认车及货物运价调整等相关信息。(3)通过各子系统的应用集成，使车站运输作业流程得以优化
在设计综合信息平台建设总体方案时，我充分考虑了下面三个原则:
集成原则:综合信息平台最主要的目标是整合车站的信息资源，在考虑 最大化集成各个信息子系统时，应该避免产生新的“信息孤岛”
开放标准原则，在综合信息平台建设时，应该站在整个系统宏观的高度，采用开放的标准和统一的架构来集成各信息子系统，避免各子系统“点到点”的低效落后的集成方式，以利于将来其他新的系统能够便利、无缝的整合。
管理配套原则:建设综合信息平台的目的是通过信息共享，达到业务流程的优化，以提高车站各方面整体管理水平。
因此项目设计之时，应充分考虑企业管理方面的需求在遵循上述原则的基础上，经过对企业需求的认真分析，结合当今成熟的 EAI 技术，我提出了以基于Java技术的J2EE 应用服务器作为统一的应用集成平台，以集成适配器作为系统集成架构模式的总体设计方案。如下图所示:
本设计方案从集成的广度来说，既包括了数据的集成，也包括了应用的集成，在集成的方法论方面来讲，大部分系统采用可白盒集成方法，少数系统采用的是黑盒集成方法。
根据综合信息平台的总体设计方案，集成适配器是该信息平台的最关键部分，它负责不同子系统之间数据的采集、转换和交流。因此，集成适配器的选型或设计的合理与否，是项目成败的关键。由于车站各信息子系统存在操作系统平台和数据库的异构性，无法从现有的中间件中找到完全适合的产品，因此我们决定自行开发此中间件。由于铁路各车站的业务领域和业务流程存在高度相似性，所以，此中间件有较高的复用价值。
对于集成适配器的设计，我采用了一种“可插拔”的设计理念。即为每个需要集成的子系统单独设计一个插接件，该插接件负责为与之相连的子系统提供数据及应用接口。各插接件通过 XML格式的装配文件，自由组装到集成适配器这个容器中，集成适配器为所有插接件提供一个统一的调度模块，来协调和指挥所有插件，使之能够协同运作。
在集成适配器的开发中，我选用了开源的集成开发环境 Eclipse 作为开发平台对于集成适配器调度模块的开发，我们采用了 Eclipse 提供的 Jobs API，Jobs API封装了JDK(Java Development KitTools)的定时及同步方面底层API，降低了编程的复杂性，提高了开发效率在插接件的开发过程中，我们充分利用 Eclipse 的高度可扩展特性，在因特网上搜集该项目可用的插件，以这些插件为扩展点，来扩展我们自己的插接件，最后我们利用 Eclipse 提供的 RCP (Rich Client Platform) 技术，集成我们的功能插件，并生成独立于 Elipse 平台的可独立执行的集成适配器。
各信息子系统具体集成过程及效果如下所述:
(1)轨道衡计重系统
该车站的轨道衡设在矿区与车站之间，距车站站场大约 2 公里左右，从矿区到车站的重车要经过轨道衡检斤，对于超重货车，要通知车站相关部门处理，由于该系统是个独立的单机系统，计重软件采用的是 VFP 编制，数据库是单机的 DBF。因此，我们首先从网络方面进行了集成，利用一对网桥将该系统接入车站 TMIS 系统。重车通过轨道会产生结构为:(车辆顺位、车号、车种、铁重、计重)数据，与轨道衡相连的插件会通过 JDBC–ODBC 桥，将数据转换为两个不同格式的副本，一份写入中心数据库，一份作为矿区站发来的确报报文，写入确报系统的到确报库中
通过该系统的集成，轨道衡工作人员免去了每天去车站递送过衡报表的工作，车站相关部门可随时通过浏览器查询过衡数据，并能方便的生成各种统计数据，车站的车号员通过查收确报报文，即可学握过衡列车的组成内容，减去了每列车都要到现场抄车号，回去录入的工作流程，大大减轻了劳动强度，提高了工作效率
(2)货票制票系统
该系统的集成我们采用了批量文件传输(FTP)方式货票制机在制票完成后，会自动向分局传输货票数据。因此我们在货票传输地址表中增加一个条目，使货票数据在传送分局的同时也传送到集成适配器，与之相应的插件将到达的 80 列格式货票数据进行解析，形成结构为:(票号、车号、车种、计重、运价、发货人、收货人)的数据，利用JDBC，一份写入中心数据库，另一份通过车号与现车系统的车辆库匹配，写入相应信息。
通过该系统的集成，减轻了编制出发列车确报的工作量，因为输入车号后，与该车号相关的货票信息会自动生成，免去了去查阅货票步骤。另外，该系统的集成，使货主通过因特网查询货票信息成为了可能。
其他的信息子系统如确报、现车系统、货运计划系统、车号识别系统等等，也都通过各自的接口插件进行了数据或应用的集成，在此不再祥述。
(3)OA系统和企业信息发布平台
通过 TMIS 各子系统集成而建立的中心数据库，是办公自动化和企业信息发布平台的数据基础。通过设在货服大厅的大屏幕显示系统，能够实时动态地发布与货运业务相关的系统，方便了货主，提高了办公的透明度。
通过项目组成员努力工作，车站高层领导的高度重视，以及车站相关人员的通力合作，历时四个月，该车站的综合信息平台初步完成，达到了建设之初的需求目标，得到车站的一致好评，系统到目前为止运行稳定
我们应该知道，企业应用集成是一个持续集成过程，是一项长期、不断进行的工程，不能指望短时间内达到深度集成。随着铁路信息化建设的深入，还会有新的应用需要整合。我们下一步的目标是建立该企业的企业门户，使我们前期的后台整合成果，能够在 Internet 上得以展现。
论企业应用集成
摘要
本文讨论了某公司的应用系统集成项目。某公司为了应对市场变化的需要，决定把公司几个主要的应用系统 ERP 系统，PDM 系统，E-mail 系统集成在一起，系统集成完成后，ERF系统可以与 PDM系统交换数据，大大减少了重复工作。通过 ERP 系统与 E-mail 系统的集成可以把 ERP 出来的报表自动发送给相关人员。我作为该项目的主要负责人之一，担任了系统分析和设计的工作，通过分析需求，设计三层体系结构，选择合适的平台等措施使项目能顺利完成。在项目实施过程中，我发现 XML作为新的 WEB 开发语言，应是今后选择的一个方向，并且企业应用集成是一个不断发展的过程
企业的应用集成(EAI)是指在企业范围内将多个应用系统的过程，软件，标准和硬件集成起来，使其成为无缝运作的整体。目前企业应用集成正越来越受到人们的重视。我在 2004年 1月参加了公司应用系统集成项目，作为项目的主要负责人，我担任了系统分析和设计的工作。项目首先是和相关部门的用户一起讨论系统集成的内容，用户希望完成系统集成后能提供给什么样的功能和服务。确定了这些需求后，就进行软件开发平台的选择和集成方案的设计。最后进行开发测试。测试完成后上线正式使用。整个项目用了五个月的时间完成，在2004年6月交付使用
该企业的信息化程序比较高，主要的应用系统有：ERP 系统，实施了物流和财务模块，把公司的采购，财务集成到了一起，PDM 系统，产品的设计和开发在该系统上进行;E-mail 系统，主要是收发内部和外部的电子邮件。但是，随着企业的发展和市场竞争的激烈，问题也逐渐暴露出来。因为三个系统是独立的，没有数据的交换和共享，这样，大量相关的数据不得不重复输入。像 PD系统负责产品数据的的维护，当一个产品的 DOI(Bill of material物料清单)成熟后，要把该 BOM导入到 ERP 系统。因为两个系统没有关联，这样就需要安排人员专门负责数据的录入，往往要加班加点，且容易出错，很不利于产品快带地生产并推向市场，为此，要考试应用集成，把企业的这些“信息孤岛”联系起来实现信息的交流。我在分析了企业应用系统的现状后，分以下几个步骤来实现该企业应用集成。、仔细研究现有的系统之间的关系，确定要集成的内容并考虑实现的方法
首先是是 ERP 系统和 PDM系统的数据的交换，要求在 PDM系统开发出来的 BOM下达后要自动导入ERP 系统因为两者针对的是 BOM，结构是一致的，实现两者的数据集成，只需定义统一的数据接口和格式即可。其次是 E-mail 系统和 ERP 系统的集成n用户希望有 ERP 系统批准的采购订单能自动发送给供应商而不必手工要从 ERP 系统中下载下来整理后再发给供应商。驻外地的销售人员要求能每天收到关于成品库存的 E-mail。通过分析，发现公司用的E-mail系统是 Microsoft Exhange Server，而 Exchange 提供了与外界的API接口，只要照接口规定的格式填写，如发件人，收件人，信件标题，内容等，进行填写的文件，转送到了Exchange Server后，Exchange Server 就可以把将其发送到指定的收件人邮箱。利用这一功能，可以在 ERP 上开发接口程序，下载符合要求的文件到 Exchange Server 上实现 E-mail自动发送。
二、设计企业应用集成的体系结构
为了避免传统的点到点的系统集成的缺点，我提出了三层的系统集成体系结构，即把企业应用系统分成表示层，中间层和企业信息系统层(包括数据系统)，企业信息系统层由该企业的 ERP 系统，PDM 系统和 E-mail 系统组成，它们通过一个面向消息的中间件来实现数据的交换。中间层主要实现应用的业务逻辑和各种服务支持，它可以访问企业信息系统层运行且与应用相联系的数据和函数。比如前面说的 ERP 系统与 PDM的数据交换，ERP 系统与 E-mail系统的接口就在中间层实现。数据从底层进入中间层，在这一层完成数据交换和集成的功能。这样通过中间层就可以实现三个系统数据的共享。客户层则包括不同类型的客户端应用，之前三个系统都是c/s 结构，各自有自己的客户端程序运行在个人计算机上，集成后， 要开发出基于 WEB 的客户端程序，统一界面，方便访问，实现 B/S 与C/S 共享。这样，通过中间层实现不同系统的协调工作和对企业各种事务活动的支持，屏蔽了低层的接口和技术细节，使数据能方便地交流
三、选择合适的应用集成平台
目前，可作为开放式企业应用集成的规范和平台的主流技术有两种:一种是微软公司的COM++规范和 Windows .NET 平台，另一种是 SUN公司的EJB 规范和J2EE 平台。在平台的选择上我进行了反复的比较，最后选择了 J2EE 平台。因为J2EE 平台的开放性与支持异构性，可移植性，支持的广泛性。对企业现有遗产系统的继承性和技术优势等。更重要的是它具跨平台的功能。公司的 ERP 系统是运行在 Unix 服务上的，PDM 系统用的则是 Microsoft NT操作系统，E-mail是Microsoft的 Exchange Server，这些应用使用不同的操作系统和平台而微软的.NET 只能用在 Windows 的操作系统的所以基于公司的实际，J2EE 平台是合适的选择。选择J2EE 平台存在的间题在于，一是成本相对比较高。二是公司的IT 人员对 JAVA还不熟练。为此，我在确定选用该平台后，先了解该平台的软件构成，只购买了我们需要的开发软件，从而节省了成本。对 JAVA则安排了几次培训，使 IT 人员能很快地上手用 JAVA 开发程序
四、应用集成方案的实践
在J2EE 平台上，我通过JAVA在业务逻辑层的开发，实现了以下的业务流程首先，在PDM系统的产品结构成熟后将会有一个下达的动作，然后 BOM数据通过中间层的处理自动导入到ERP 系统，这能过之前已定义好的口规范和数据格式可以很空易地实现。ERP 接收到产品结构数据后，即可以运行 RP 产生采购订单和生产订单，投入产品的生产。此外，通过业务逻辑层，在 ERP 系统上下达 PO 后，采购订单的数据会自动传到 Exchange 服务器，然后通过E-mail自动发送给供应商产品库存的数据也可以从ERP 系统传到 E-mail 发给外地的销售人员。该应用系统集成后，用户不必再加班加点在地在 ERP 系统中维护产品数据，并且保证了ERP 的产品结构与 PDM 中的是一致的由于实现了 ERP 与 E-nail 系统的集成，用户也不用担心哪张 PO 没有发送给供应商了。
项目上线后，满足了用户的需求，运行半年多来，系统基本稳定，大大提高了工作效率,
得到用户和管理层的肯定，但也存在着一些问题。 在项目实施的后期，我们发现用 JAVA 编写代码效率比较低，运行速度慢，并且取数据还是不太方便。于是引入了 M 技术进行数据的抽取，组织和表现，结果大大增加了开发的效率。通过该项目我认识到 XML 将会是今后EB 开发和实现企业集的主要技术之一。此外，现在仅是实现了 PDI 系统和 ERP 系统的集成，之后随着企业的发展ERP 将运行在更开放的平台上。会从企业的内部应用转为一个连接到 WEB 上的分布式应用系统。即ERP II，这将是以后的发展方向。
财务数据仓库系统的设计与实现
[摘要]
近年来，数据仓库技术在信息系统的建设中得到了广泛应用，有效地为决策提供了支持。2004 年 6月，本人所在单位组织开发了财务管理决策系统，该系统主要是使高层领导学握企业的经营状况及进、销、存情况，分析市场趋势。
本文通过对财务数据的分析，结合数据仓库开发原理，完成对财务数据仓库的数据组织介绍了财务数据仓库的设计和实现方法方法。财务数据仓库的设计步骤主要是遵循数据库设计的过程，为分概念模型的设计、逻辑模型设计、物理模型设计和数据仓库生成等几个阶段目前，该项目已顺利上线，领导反映良好。在该项目中，本人担任系统分析师职务，主要负责系统架构设计和数据仓库的设计工作。
[正文]
2004 年6月，我所在的单位为了快速适应市场的变化，使高层领导及时学提企业的经营状况及进、销、存情况，分析市场趋势，决定开发财务数据仓库系统。在该项目中，本人担任系统分析师职务，主要负责系统架构设计和数据仓库的设计工作。在这个系统的设计过程中，我们遵循了数据库设计的过程，整个财务数据仓库的设计步骤如下:
(1)概念模型的设计
(2)模型设计
(3)物理模型设计
(4)数据仓库生成
1.概念模型的设计
进行概念设计所要完成的主要工作有:
(1)决策需求分析:对于数据仓库系统而言，决策者最为迫切的需求在于，更加准确的掌握企业的经营状况及进、销、存情况，包括分析进货趋势，分析销售市场波动趋势，分析企业存货情况，分析市场经营状况发展趋势。所要求的操作数据库的数据有商品进货数据、商品销售数据、商品库存数据、顾客信息和销售商信息。
(2)确定系统的主题域及内容在上述需求分析的基础之上，我们可以确定企业财务仓库系统的 3 个主题，分别是商品、顾客和销售商。如图 所示
2、逻辑模型设计
商品、顾客、销售商是财务数据仓库的 3 个主题，是其经营运作3 个框架。商品主题描述企业商品分类及销售情况，顾客主题描述了企业对顾客进行分类及有关顾客合同的管理情况，销售商主题描述了企业销售人员销售商品及销售地区情况。其中商品主题作为中心，将这3个主题联系起来。它们的内容列出如下:
(1)商品，商品固有信息(商品代码、商品名称、商品类别等)，商品库存信息(商品代码、库房号、库存量、日期等)，商品销售信息(商品代码、顾客代码、销售日期、销售单价销售数量等);
(2)顾客:顾客固有信息(顾客代码、顾客名称、地址号、电话等):顾客合同信息(顾客代码、合同代码、起始日期、终止日期、数量、价格等)，顾客购货信息(顾客代码、商品代码、单价、数量、日期等)
(3)销售商:销售商固有信息(销售商代码、销售商品、销售商品名、销售商地址等);销售商地区信息(销售商代码、销售地区名、电话等)。
以“商品”为主题可以看到，首先，在从面向应用到面向主题的转变过程中，丢弃了原来不必要、不适合分析的信息，如各类领料单、出库单、入库单等，棋次，在原有数据库模式中，有关商品的信息被分散在各个子系统中，如，商品销售信息存放于数据管理子系统，商品库存信息存放于商品库管理子系统中等，根本没有形成一个有关商品的完整一致的描述，而向主题的数据组织形式所实现的就是要形成商品一致的信息集合，以便在此基础上针对“商品”这一分析对象进行分析处理
3、物理模型设计
(1)确定数据的存储结构
通过定义功能/教据的交叉参照图，决定谁需要访问哪个范围的数据。每个数据仓库实施的最初阶段，必须标明最终用户的词汇表，定义恰当的商业术语，与底层数据联系起来。
- 由于数据仓库本身通常是面向主观意识的，基于最终用户的需求，创建数据仓库的第一步是识别和分析有关的内部数据和外部数据源。
- 数据模型在将内部和外部操作数据转换和集成到数据仓库里的过程中起着关键性的作用。在这个阶段，系统分析师必须收集信息，实施从数据源到数据模型的逻辑转换，确定数据按简要或详细的程度保存在数据仓库中。
- 创建词汇表、清除数据是产品数据与仓库数据之间的转化基础，词汇表是关于数据的数据。对于决策支持分析员来说，它是一个确定数据位置、理解计算法则的商业定位指导。清除数据和过滤数据包括转换数据、巩固数据和通过应用一致的命名法则协定解决在操作数据库中数据不一致的问题。
- 从长远的角度优化数据仓库，系统必须是灵活的，可扩充的，模块化的，以便有足够的能力去适应系统的不断增长。
(2)确定索引策略
由于数据仓库的数量比较大，因此在库结构设计时将每一个子库设计为树型索引结构，初始结点为所要决策的主题，其中间结点即为不同优先级的与该主题有关的查询角度与层次而最终结点为经过预处理的有定义的数据集合。
4、数据仓库的实现
(1)接口设计
在财务数据仓库中有几种方式:菜单式、问答式和图形式。接口设计涉及如下几个模式:输入响应模块、输出模块、人机对话管理模块和外围设备。由于时间和篇幅有限，这里就不详细介绍这些方式和模块了
(2)数据的采集
接口设计结束后，下一步工作就是将数据采集到数据仓库中。数据采集是将原始数据从多个传统事务处理数据库系统中提取出来进行清洗，集成等有关处理，使之符合数据仓库环境中对数据质量的要求后再装载入数据仓库中。数据采集的主要工作有确定数据源的次序、元数据的管理、粒度划分、数据分制和数据的定期维护，数据在装入数据仓库底层的目标数据库后，还要完成的任务包括数据的定期洁理、刷新、重建索引、初划分主题等工作
目前，该系统已经上线并顺利运行了一段时间，达到了开发的目标，为高层领导决策提供了可靠的数据来源和支持，得到了单位领导的一致好评。
数据仓库技术的发展包括数据抽取，存储管理，数据表现和方法论等方面。
在数据抽取方面，未来的技术发展将集服务器托管网中在系统集成化。它将互连、转换、复制、调度、监控纳入标准化的统一管理、以适应数据仓库本身或数据源可能的变化，使系统更便于管理和维护。
在数据管理方面，未来的发展将使数据库厂商明确推出数据仓库引擎，作为服务器产品与数据库服务器并驾齐驱。在这一方面，带有决策支持扩展的并行关系数据库将最具发展潜在数据表现方面，数理统计的算法和功能将普遍集成到联机分析产品中，同时与Internet/Web 技术紧密结合，推出适用于 Intranet 和终端免维护的数据仓库访问前端。
数据仓库实现过程的方法论将成为数据库设计的一个明确分支，并将成为管理信息系统设计的必备。
论软件需求分析方法和工具的选用
[摘要]
本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的工作，若重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解决方法，在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对吏用方法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户沟通的重要性
[正文]
近年，我一直从事某企业中有关IT 项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计(注，日式说法)到下流设计(注日式说法)的所有流程，如用于可设计百万门数量级的逻辑门电路。有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的需求分析以及设计
我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。
委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需求分析时的工作主要有两点:第一，对该软件的界面等详细需求要自己重新进行分析提取。第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。
在接到需求分析任务后，我分析了一下所要完成的工作，发现由于是专用领域的软件，对专业领城要求相当高，所以准备把此项目分成两部分
(1)界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改动可能是最大的。
(2)功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书面的简单需求，相应来说只是完成深化。对界面，我采用了部分 RUP 的思想迭代与渐进。而对功能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。
首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求分析。第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应，大体上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt(由于要支持 Windos 和 Unix 双平台，所以控件采用 Qt)的类库中选择相应的控件，在提取和抽象逻辑模型时，我采用了 Rose 2000 中的用例图，即以USE-CASE 图来描述与外部的关系。之所以采用 Rose，我是基于以下的原因，第一，在已开发的部分中，委托方统一要求我们使用 Rose 进行类和顺序图等的设计和代码生成。第二，Ros 提供了标准的图来描系统与外部的关系，在全球范围已是一种标准结构，第三，使用上的方便性，我用 Rose 的USE-CASE 图，理清了我们的软件窗口(日式说法，即，沟通人员)与委托方主窗口(日式说法同上)以及外部角色《操作者)之间的相互关系
在确定了界面元素后，考虑到文档的可理解性不是很强，我采用 visio 2000 把界面的外观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修改，委托方基本批准了我的方案
下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰的感觉。只能采用分层细化的原则，从最初的几条深入一层变成十几条。这样的话，不会一下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专业领域的了解，这样在设计中自己始终是层层推进的，不至于碰到无法逾越的专业障碍
在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅助设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司的 E-mail 系统所有不清楚的问题的提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶段，它起到了一个与客户的交流沟通和客户需求的提取作用所以，我认为在这一阶段,E-Mail系统是对我帮助最大的工具，其次是 Excel，我用它建立了问题跟踪图表，对每一个提出的问题，均需要记录上去，把问题结果 (可分为已清楚、仍不太清楚、不清楚、尚未回答)均记录下来，根据这些表，我可以很好地了解自己工作中的核心问题，并有了解决它的方向，提高了工作效率。
每进行一层的细化，我都把结果交付委托方审核，由他们进行提出何时能终止细化，大约在八层细化后，对方认为已达到了效果，确认可以结束。至此，分析工作全部完成，项目的需求分析基本成功了
在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己理清思路。选用了选代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工具不是万能的，需求分析的关键之关键，应是与客户的交流与沟通。通过这次案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用，应当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，而工具的选择不仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么帮助，而不是仅限于如何使用，我认为在需求分析中工具的作用不外予两个:一是实际系统与环境模型等的抽象工具，二是需求表达工具。第一类的代表是 Rose，第二类的代表是Word,WPS, Visio等,在这次项目中由于地理上的限制还用到了沟通工具,Web 浏览与E-mail服务系统。
最后我还是总结一下，在需求分析中工具方法都只是辅助项目成功的因素，真正的决定因素还是——“与客户的沟通”
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
相关推荐: 哪个公司的 CEO 不想拥有一个自己的数字克隆？
⚠️ FBI Warning：本文纯属作者自娱自乐，数字人的观点不代表 CEO 本人的观点，请大家不要上当受骗！！ 哪个公司的 CEO 不想拥有一个自己的数字克隆？ 想象🤔一下，如果 CEO 数字克隆上线了，那他是不是就可以一天约见 100 个投资人了？把他接…
