医疗信息化领域的软件工程

《医疗信息化领域的软件工程》由会员分享，可在线阅读，更多相关《医疗信息化领域的软件工程（7页珍藏版）》请在金锄头文库上搜索。

1、 更多企业商业智能 BI 信息化相关信息获取 http:/ http:/ 医疗信息化领域的软件工程医疗信息化领域的软件工程 软件工程从来就不是一门精细的学问， 在我看来， 在没有弄清楚人类思维的核心规律之前，任何力求精确的模型/度量/计算都是徒劳的。再加上一些管理者不断地拿一些现成的过程和方法来进行换汤不换药的概念翻新， 使得本来很多确实成效不错的过程和方法沦落成为玩弄技术管理的工具，甚至企业管理的政治口号。最终，使得很多技术牛人对软件工程这个领域嗤之以鼻。 确实， 没有任何两个个软件开发， 可以用完全相同的方法学取得成功。 然而，当一部分技术牛人的兴趣， 从机器的运行规律迁移到人脑以及人类组

2、织的运行规律上面来的时候，他们才惊奇地发现原来它们是如此的相似：整个世界就是一部计算机，而我们每个人都是其中的一个计算单元。 而软件工程领域所有的这些不确定性， 也从他们厌恶的对象转化为一种激动人心的挑战。 去伪存真， 从一个实践者的角度来体验和找寻适合我们自己的工程方法。 因为我们相信，同一件事情，你可以用很多种方法来做，但只有少数几种方法能够让你获得成功。 最近医学信息论坛上的讨论，又让我得以重新审视一下一些工程方法在这个领域的应用 在软件工程过程体系的这么多繁文缛节背后， 或者至少在实际操作层面， 对最终项目的成功发布真正起到决定性作用的只有两个：一个是需求管理，一个是配置管理（包括变更

3、和发布管理在内）。它们分别是项目的一进一出，把好这两道关，其他的东西，不管是分工，进度，风险控制等等，都可以顺势衍生出来。 对于需求人员来说，最忌讳两种做法，一种是“传声筒”，一种是“捏造需求”。因此，要做好用户和技术人员的桥梁，需求人员除了具备一定的沟通技巧之外，还需要： 1、深知沟通过程的基本原理，以及常见的沟通陷阱。 2、基本的需求分析（即对原始需求进行正确的提炼和整理）的技能。 更多企业商业智能 BI 信息化相关信息获取 http:/ http:/ 关于第一点，玩过多人传话之类游戏的人应该都比较了解。而关于第二点，则需要具备一些工程知识和技能。 举个例子，很多医院流程里面都有三查三对，

4、有些还是三查七对。但有些新手设计的用户界面，如果没有注意这一点，经常会把一些重要信息（比如病人姓名、性别、年龄）显示得不够显眼。于是医生提出，你这个字体能不能大一点，这个属于一个原始的客户需求。一般医生忙起来也不会跟你说得很细，或者最多跟你说姓名、年龄要大一点（可能因为他是妇科医生，一般来的都是妇女，也不用关心性别了）。于是，“传声筒”型的需求人员就会原样告诉技术人员，让他们把姓名、年龄搞大。哪天轮到另外一个科室要上这个系统了，又来了一个需求，叫做把性别搞大。然后开发人员又要改，测试和变更管理等相关人员又要就类似的问题再检查和跟踪一遍。或者，其中有一个人提出，干脆把整个界面的字体都搞大点好了，

5、 省得每次都改。 可能因为这个人在某些方面比较资深， 或者比较能说会道比较有感染力，或者在职务上本身就有一定的影响力， 而刚好这个医院的老医生比较多， 一些人可能认为这些医生本来电脑操作就不熟练， 眼睛又不好使， 所以也同意了把整个界面的字体搞大。 甚至，还有人提出，干脆把整个界面的字体做成可配置的，听起来也不错，却没想到这又增加了测试、实施和维护工作的复杂度。最后，系统一升级，医生吓了一跳，怎么整个界面的字体都变大了。有些得过且过的医生倒也不再提了，越改越不像样，反正我要看的那些信息，我凑近屏幕仔细找找就好了。这就是一个典型的“捏造需求”案例。 从这个例子可以看出， “传声筒”相对还好一些，

6、 最多会让类似的需求反复提反复改 （甚至还会出现一些前后矛盾的需求，比如改过来又改过去），成本增加一些，需求变更的收敛速率低一点而已；最可怕的是“捏造需求”，而且在小型项目里面，大多是项目经理充当需求人员的角色，他一旦对需求判断错误，对项目产生的后果将不堪设想。 更多企业商业智能 BI 信息化相关信息获取 http:/ http:/ 以前曾经看到过一个诊所预约系统，由于前期需求不充分但客户又急要一个技术方案，在制定一些具体技术规格的时候， 项目经理为了能做出一些亮点， 提出让预约者直接看到被预约资源的使用情况，以便提高预约申请的通过率。如果是在办公楼里面，预订会议室，这是个很好的办法，但在医疗

7、行业是完全行不通的，这违反了病人、护士/接待员和医生的基本生产关系。幸运的是，在最终方案出台之前，经过多方努力，终于修正了这个想法。要不然，就算你好不容易把第一个版本的原型做出来了，拿给用户提意见，用户一看你就不懂医疗，别的也懒得跟你谈了。 实际项目中的这些问题，用软件工程的理论进行解释，就是缺少对于业务需求的把握。 软件工程里面虽然各家表述不尽相同，但一般都会提到几种需求：用户需求、业务需求、系统需求（包括硬件需求和软件需求）。这些需求，不管你是做项目还是做产品，都会用到。其中最关键的是业务需求，它的一个通俗说法，就是行业经验。当然，能称为业务需求的行业经验一般都是抽象化、模型化并且可以分享

8、的。因此，这样的业务需求就成为了所有需求变更所围绕的一个核心。 从用户要达到的最终业务目标的角度， 业务需求就是审查每一项需求变更是否合理的一根准绳。 因此，基于业务需求来分析和评估原始的用户需求，基于业务需求把原始需求提炼和整理成技术人员可以使用的系统需求，将会大大降低需求变更的频率和控制的难度。当然，并不要求所有的需求人员都具备这样的需求分析能力， 但至少在需求小组里面需要具备这样工程知识和技能的人，才能产出高质量的需求，从而产出高质量的产品。 1、为什么需要配置管理 在医疗信息化项目中，也许会出现这样的一些问题。有时，之前刚刚修改过的软件缺陷，或者前不久已经实现了的客户化需求，在最新版本

9、里竟然消失了。有时，面对好几个科室甚至好几家医院同时提出的问题， 需求人员和开发人员忙得不亦乐乎， 但一些关键的问题却石更多企业商业智能 BI 信息化相关信息获取 http:/ http:/ 沉大海，客户一直得不到回复。有时，发现一个共性的问题，需要大规模地升级系统，但由于各个科室安装的工作站太多， 每个科室可能还有一些特殊的用户设置或者客户化补丁， 到底哪些工作站适合升级，以及如何升级，才既能修复问题，又不影响系统稳定运行？有时，为了实现信息集成以及更加顺畅的工作流， 需要对某个已经上线运行的系统进行修改， 但是负责开发这个系统的程序员已经离职，负责维护这个系统的开发人员又找不到当时的代码，

10、或者在磁盘备份上好不容易找到了某个版本的代码，却无法编译。所有这些问题，都跟配置管理有关。 很多人会觉得配置管理的工作很虚。在项目经理看来，配置管理无非是管好各种文档，以及记录一下将要发布的版本；在开发人员看来，配置管理无非是每天例行的签入签出，以及定期的集成和构建； 在实施人员看来， 配置管理无非是记录和报告各种服务器和工作站的硬件设置和软件安装情况，不厌其烦，又枯燥无味。 的确，配置管理并不能像编写程序那样给项目带来直接的价值，但它最重要的意义之一在于让包括编写程序在内的各种原本不可见的工作任务可视化 （用配置管理的术语， 我们叫做配置项识别），这种可视化正是团队沟通协作，以及项目质量、风

11、险，进度和成本控制，甚至包括量化审计的基础。 正是配置管理所包含的这些看似简单和重复的工作， 却为项目的顺利运行提供了坚实的保障。 2、什么是配置管理 配置管理的主要任务是对项目中不断变化的各种工作产品进行记录、控制和报告这些工作产品可能包括需求和设计文档、每一台服务器和工作站、甚至细到每一个代码文件、以及记录用户操作喜好的个性化设置文件其目的是确保这些工作产品之间的关联一致性和质量完整性。对于整个项目周期来说，配置管理是一个重要的支持性工作，它是项目走向精细管理的必经之路。 更多企业商业智能 BI 信息化相关信息获取 http:/ http:/ 传统意义上的配置管理，包括配置项识别、变更控制

12、、配置状态报告和配置审计几大部分。在一些理论模型中，配置管理可能会跟变更管理、发布管理分开进行描述。但他们之间是密切相关的： 变更的评估必须在配置管理相关的状态监控活动， 以及涉及多方协作的流程控制之内进行，而变更的实施一般也是通过发布管理活动来执行的。因此，这里的讨论范围是包括了变更控制和发布管理在内的完整的配置管理。 当然，在具体的项目实践中，不同的医疗信息系统提供商，或者不同医疗机构中的 IT 服务部门，对配置管理工作内容的定义都略有不同。他们通常在传统的配置管理基础上，增加了配置管理工具的应用、维护、培训和支持，软件的集成、构建和版本发布，甚至包括制作软件自动安装包等工作内容。 3、如

13、何做配置管理 在一些人的印象中，实施配置管理，就意味着某些文档必须按照指定的格式来写，某些代码必须在指定的时间和地点（目录）上签入签出。原来开发人员发现代码中的一些技术性的小问题，可能马上就动手修改，现在却要经过层层审批。原来需求人员听到客户的一个抱怨，可以直接把怨气泄到技术人员头上，责令他们赶紧修改，现在不仅要讨论来讨论去，还要在各种文档上进行繁琐的记录， 甚至还要邮件通知一些以前认为似乎没有必要告知的那些人。难道配置管理真的就是这种繁琐枯燥，既增加项目成本，又拖长客户响应时间，还让人觉得碍手碍脚的过程累赘吗？ 其实，信息化项目比传统的工程领域项目更加容易失败的原因之一，就在于很多信息化的工

14、作产品的不可见性。比如，如果是某个机械零件长了或者短了几个毫米，不管是工程师还是管理者都能肉眼直观看到。 但如果是在设计数据库的时候遗漏了一个外键约束， 或者是不小心使用了另外一个版本的编译器， 使得同一段代码编译出来的程序略有不同， 有时可能难以觉察 （除非是专业的测试工程师， 利用精心设计的用例， 经过相当长一段时间的测试） 。更多企业商业智能 BI 信息化相关信息获取 http:/ http:/ 为了化解这些风险并防范于未然，IT 工程师和管理者们必须使用一些过程和方法来保证这些零部件在集成起来的时候能够正常工作， 并且满足客户需求。 配置管理就是这些过程和方法中非常基础又十分重要的一个

15、。 因此，配置管理并不是空穴来风，只是我们由于每天都在使用它，所以渐渐淡忘了而已。比如我们经常使用的“版本”这个词， 就来自于配置管理， 它是识别配置项变化的重要工具。又如我们常常谈到的“需求变更”。 其实任何变更都是发生在一个基准基础上的变化， 没有基准，变更根本无从谈起，而这个基准就是配置管理需要特别关注的“基线”。 当然，所有的配置管理方法得以实施的前提是高层的理解和支持。因此在信息化项目中，主要负责沟通的项目经理，有责任让你的领导，客户，以及团队的所有成员，理解相关的配置管理理念、策略、流程和工具，这是配置管理以及其他相关工作得以开展的必要前提。 4、谁来做配置管理 在很多理论模型中，都有一个配置管理员或者配置管理工程师的角色。因此，很多人会习惯性的认为项目中配置管理的工作都应该由这个角色来完成。 同时， 配置管理的工作本身看起来确实没有开发或者测试工作那样有技术含量， 所以这个角色常常由一些年轻的工程师担当。另外，开发团队一般总是聚在一起，比较好管理，实施团队则是经常出差，在客户现场安装硬件和软件，并进行必要的客户化设置，所以配置管理就先在开发团队里面做起来，保证发布给实施团队的版本没问题就行了。 以上这些错误的决策， 常常会导致配置管理的失效，并最终让项目陷入混乱。 在开发团队中，配置管理工程师必须具备以下几种素质。一、编程经