论建立集成平台软件工程的进度管理

1、论建立集成平台软件工程的进度管理摘要本文讨论了信息集成平台的项冃标管理。在本项目管理屮，主要采 用了面向对象同传技术相结合的原则，在估算项目的工作量这方面尤其突出，面 向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。木文从 合理的估算项目的工作量和技术难度；识别关键技术；随吋了解项目进度，必要 时调整进度表以及跟踪和控制项口计划的执行等方面讨论了信息集成平台项 目管理活动的基本活动和方法，有效地控制了开发进度，确保项目如期按质量完 成，本系统第一期工程已经在我院如期完成并投入运行，状态良好。关键字集成平台软件工程进度管理引言4一、合理的估算项目工作量及技术难度5二、识别关键任务

2、7三随时了解项目进度，必要时调整进度8四、着重考虑人员在整个项目开发过程中的安排，减少开发人员之间的通讯障碍，提高生产率。10五、跟踪和控制项目计划的执行11结论13致谢语14引言2014年7月，我参加了厦门某医院信息集成平台的实施工作。 目前，国内医疗服务正在经历从封闭（单独一个医院）到开放（多家 医疗机构区域集合）转变的过程中，在这个转变的过程中医疗信息的 传输是关键一步，因而医疗健康信息传输与交换标准hl7在国内得到 了很大的认可，我们都希望借助于现有标准，加快我们医疗信息化的 进程，具体到医院，目前医院信息存在如下的诸多问题，1、信息系 统交互不透明，导致接口冗余、系统不稳定；2、信息

3、科缺乏对信息 系统的有效管理及控制机制；3、信息系统术语定义、统计口径无标 准、无规范；4、重要信息闲散存储于各业务系统中，统计、分析、 跨系统利用难；4、数据二次利用理念和思路匮乏，处于统计上报阶 段。因此，对医院而言，就需要使用建立一个系统集成平台，对各系 统进行整合，以达到时系统共享的目的，所谓信息集成平台esb,英 文全称为enterprise service bus,即企业服务总线。它是传统 中 间件技术与xmi八web服务等技术结合的产物。具有特点：1、高可 重用性 2、接口性能可视化3、接口数据标准化等特点。集成 平台可实现从任何地方到任何地方的通用的连接，支持一系列内设 传输方

4、式，协议和系统，支持广泛的数据格式，提供各种消息处理, 简单的编程，通过模式和图形映射来实现。有全面的管理，性能和可 扩充性。医院信息系统应用整合的首要需求是实现各医院应用系统之 间的互联互通：从集成的层面上，需要考虑三个层面：数据层面、应 用/服务层而和流程层面。即各应用系统在数据层面可以相互交换，在应用层面可以互相调用，在流程层面可以协同在一起实现全院级的 业务协同；从集成的手段上，包括点对点集成和通过平台来集成。要实现全 院级集成，应当通过平台化的手段来实现。互联互通的核心是数据层 面和应用层面的整合。具体来说，重点要解决医院信息系统的系统异 构集成、数据共享和数据交换传输标准等关键性技

5、术问题。全院各个 应用系统均与医院信息平台互联，并通过医院信息平台实现相互之间 的数据交换和应用服务的调用。在本系统的实施过程中，我通过合理 的估算项目的工作量及技术难度，识别关键任务，随时了解工程进度， 必要时调整进度表等方面对项目进行管理，确保系统如期按质量完成。一、合理的估算项目工作量及技术难度我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则。本系统采用了面向对象的分析，设计等一系列面向对象技术，在 本系统工作量的估算上根据某个独立的系统进行估算，将每个系统逐 步分解，直到具体服务为止。根据各个系统的提供商不同，我们在项 目一期工作中，将整个项目分解成多个服务模块

6、，比如his模块、cis 模块、lis模块、ris模块等，每个模块又根据功能划分成不同的队列， 各个队列组成队列管理器，根据项目所需要对外提供服务的数量和服 务的难易，合理安排人员。在对工作结构的分解粒度中要适中，不能 过大也不能过小，过大不易控制，过小容易产生过渡管理降低效率。对于该项目我基本掌握在工期在一周左右，以最大不大于两周，最小 不小于3个工作口为原则进行分解。项目组一共6人，在这个规模上， 实际的经验告诉我这个粒度时相对比较合适的，可以保证比较有效的 跟踪管理，同时我还可以有一定的时间负担一些技术工作。工作任务 按工作结构分解情况以任务单的形式安排跟踪，任务单下发到具体组 员，避免

7、将同一执行人的多个任务打包安排。我在项目中坚持按上述 工作结构分解后的任务进行单任务的分配跟踪，而不是几个相关任务 打包安排、跟踪。因为如果将同一执行人的几个任务打包安排，看似 节约时间，但实际经验告诉我，这样很容易造成这些任务与其相关联 任务（尤其是与别人关联的任务）的不同程度的脫节。因为作为同一 执行人在执行儿个任务时重点考虑的时保证这一包任务的总体完成 情况，会忽视单个任务的时间进度要求。而项目总体控制要求任务之 间的关联关系，尽管这种关联关系的脱节不会很严重，但会比较普遍。 而且这些任务有超前有延后，从总体上不容易发现问题。但正是由于 任务关联脱节的比较普遍，经过一定时间的积累很容易产

8、生影响项目 整体进度的大问题，而当问题比较明显时，往往已经很难调整和控制 to同时因为各个服务队列的功能在其它的项目中都有得到过体现, 以前有过不少的成功的案例供我们参考，各个队列提供的服务中输入 参数和输出参数大体相同，正因为如何，有大量的东西可以提供给我 们复用，如his中的病人基本信息服务，不仅提供给ris消费，还提供 给其它各个不同的系统进行消费，所以我们把各个队列中所需数据相近的服务提供者尽量合并成一个服务，以达到最大复用的目的。这样, 在工作量的估算上也有很好的借鉴作用，这对工作量的估算也是一个 重要的参考，为工作进度安排提供了依据。在技术上，我们重点考虑本系统与其它平台系统的不同

9、之处，相 同或者相似之处我们认为没有难点。集成平台主要的工作是使用esql 语言编写数据队列，在具体设计上我们使用了 ibm的websphere mq 进行队列设计，对客户端调用队列服务采用封闭了 mq的sdk进行。 这样大大减轻了配合改造系统方的工作量，配合系统改造方只需要调 用相应的sdk即可，而不必与繁琐的mq打交道，这样加快了工作进 度，提升了工作效率。在工作安排上，技术难度相对大一点的部分我 们安排给经验相对丰富的程序员，同时也同其它工作组的成员商讨技 术细节问题，同他们进行技术探讨，这样不至于因为某一技术细节而 影响整个工程进度。根据上述分析我们制定了一个详细的进度表并制定了相应的

10、里 程碑。二、识别关键任务his系统是整个系统的关基础，因为其它大多数系统所需要的服 务基木都是由这个系统所提供，比如病人索引、各类字典等，它是其 它系统的基础和起点。因此该系统所提供的服务是整个工程项目的关 键部分。其所提供的服务必须完整、准确，否则必然会影响整个项目 的进度和质量。在进行项目控制时，我们将其作为作为重点对象进行 监控。lis、pacs所提供的检查、检验报告服务也是其它各个系统所需 要的重要服务。直接而对用户，这部分的成功与否直接关系到系统的 质量，因此也是不容忽视的。如果上述两部分的进度受到影响，则整个项目的进度将受到威胁。 因此是本项目的关键任务，在进度控制时我们将其作为

11、重点对象进行 控制。除了首先确定好串行进行的关键路径任务外，还要充分灵活安排 与其他任务关联度不强的工作任务（我称之为“游离任务”），计划中 给予此类任务足够的“游离”空间，使其能在关键任务提前完成，或 关键人力资源有空余时可以穿插安排，以充分利用人力资源；而在关 键任务一旦延期或关键人力资源紧张时可以适当调整其时间安排，以 释放部分人力资源，保证关键路径的进度和人力资源的充分利用。三随时了解项目进度，必要时调整进度表在确定项目开发计划时，我们制定了详细的进度表，我们在确定每一项任务时都确定该项任务的工作量、开始时间、持续时 间、结束时间，同时让每个小组成员知道自己所承担任务的时间表，小组成员

12、根据自己的任务制定自己的详细工作计划。各负责 分组负责人对所分配的项目现场实施进度控制；具体实施进度表 要有相应负责人确认签名；每个分阶段的项目调试完成后需形成项冃实施进度表并交具体负责人确认签名。工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成员都对自己的工作要有自己的工作日志，对自己每天的工作做详细的 记录。每周对自己的工作进展做出结论，向项目组汇报，在做结 论时，不得使用“差不多”、“大概”、“完成了 9 0 %”等模糊字 眼。而是作用某任务“已全部完成”或者“再过一天全部完成” 等方式。每个小组成员对自己做出的结论负责，这样可以做到随 时了解项冃进度，为调整项冃计划提

13、供客观基础。同时我们在项目进度计划中根据项目设计定义了相关的里程碑, 在每个里程原告我们都采取小组会议形式对本阶段的工作进行确认、 总结，对本阶段的进度情况做出结论，并决定是否调整下一阶段的进 度计划。比如我们将消费系统中能够调用his中的队列服务定义为一 个里程碑，能成功调用lis或pacs的服务队列又定义为一个里程 碑，每个消费系统调用的全部完成又被视为一个里程碑，每个里 程碑的在系统设计时就已经定义好了。同时总体上合理规划各个环节 的时间安排和工时投入，适当加大调研、需求、概要设计以及测试阶 段的工时投入，控制开发实现以及安装实施阶段的工时投入。对于时 间紧急的项冃，我们的惯性思维往往要

14、求我们急于开展开发、编码等 所谓的“实质”工作，而不由自主的缩减调研、需求、概要设计以及 测试等所谓“虚”的环节。但这样往往适得英反，也不符合项目管理 的客观规律。如果调研不足，可能导致开发过程中出现意想不到的技 术问题；如果需求与客户没有足够的沟通并明确，可能导致重大功能 模块的调整；如果概要设计做得不充分，可能导致系统架构级的问题; 如果测试不充分，更可能导致施工调试过程中的巨大反复。而如果没有充分的前期投入，所有这些问题在其产生的阶段都是隐匿的，在后 续阶段才会逐步显露出来，而问题一旦出现，其影响和问题已经严重 扩散，后续的补救工作至少需要花费几倍甚至十几倍的时间和成本来 弥补，严重时这

15、无疑将导致项目进度的失控。对于像该项目这样时间 要求紧迫的项目来说，是容不得出现较大的反复的，严重时可能将导 致项冃的彻底失败。与之相对的，开发实现阶段虽然是项目的实质主 体，也是我们经验最丰富也最擅长的部分，在解决了关键的技术障碍 之后其实是最容易控制的部分。同时，前面各阶段，尤其是测试足够 充分的话安装实施自然就会比较顺利。从效果看，这个策略很好的保 证了项目的整体进度，各阶段进展都相对比较顺利。四.着重考虑人员在整个项目开发过程中的安排，减少开发人员之间 的沟通障碍，提高生产率。着重考虑人员在整个项目开发过程中的安排。从各职能科室抽调人员进行业务分析，提出并确认需求。考虑到本项目完成之后

16、的维护 需要，我方信息科人员全程跟踪乙方人员，分别参与各消费系统的了 设计，继而参与各服务队列实现的详细设计，编码实现。为后期的维 护做准备。减少开发人员之间的通讯障碍，提高牛产率是为了确保项目的如 期完成，我们事先规定了文档编写规范、命名规范，重视文档的编写、 保管等工作。重视文档与设计的一致性，先修改文档，再修改服务, 不至于因为文档与设计的不一致而影响工期，对跨越里程原告的文档修改设置严格评审。为了减少开发人员之间的通讯障碍，还启用了 notes系统，开发人员可以通过内部mail进行交流，及时沟通，减少 误解。同时，我们在项目中采取早会、周例会结合的例行沟通模式，强 调及时沟通、快速反应

17、。我们每天利用早晨10分钟左右时间，项目 组互相通报一下前一天的工作情况和问题。冃的是及时掌握项目进展 动态和问题，以便及时采取措施提高项目组反应的敏捷度。但早会上 主要是沟通和识别问题，不对具体问题做展开讨论，如有需要再专题 安排。周例会主要分析项目进展的重大问题和进展趋势，讨论和决策 相关措施。但要注意引导避免早会、例会形成形式主义，尤其是例会 在项冃进展顺利时可以缩短时间或隔周召开。五、跟踪和控制项目计划的执行跟踪和控制项目计划的执行，为确保本项目的如期完成，在项目 开始后，我们定期召开各系统负责人会议，让各系统负责人各自报告 各自小组的进展情况和所遇到的问题。通过交流开发过程中遇到的问

18、 题，共同探讨解决的方案。我对照计划，跟踪实际执行情况，如果项 目实施顺利，在预算范围之内，我会适当放松一些控制，但只要一遇 到问题，我会尽量帮助排解。例如，在编码和单元测试过程中，因为 时间比较紧，尤其是his组在编码过程中遇到了些阻挠，加之个别人 员流动，我只好调整计划，重新调整人员，还让his组人员加班加点， 有时我也找个别开发人员谈话，以了解他们对开发进展情况的评价以及他们个人遇到的问题，尽我所能帮助他们解决问题。同时定期（如一周）关注项目进展相关数据，关注项目进度趋势， 提前预判并决定是否及如何干预。比如，项目延期可能不大并完全在 可接受范围内，但连续两周在扩大，就需要加强关注，分析原因提前 采取措施，以免失控。当然，俗话说“计划不如变化快”，任何计划 在实施过程中都不可能完全依照计划进行，必然会出现不同程度的偏 离。但是否是偏离就一定要干预，一定要纠正呢，当然不是。因此要 分析对计划的偏离是否可控，呈现何种趋势。在可控范围内就没有必 要过多干预，以免过度管理降低工作效率和造成时间浪费。因此干预 调整的程度，需要把握在一个合适的火候，除了经验之外，很重要的 就是多利用工具软件提供的相关数据，进行分析和判断，找出趋势和 原因。在项目的开发过程