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

《医疗信息化领域的软件工程》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

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

2、功。然而，当一部分技术牛人的兴趣，从机器的运行规律迁移到人脑以及人类组织的运行规律上面来的时候，他们才惊奇地发现原来它们是如此的相似：整个世界就是一部计算机，而我们每个人都是其中的一个计算单元。而软件工程领域所有的这些不确定性，也从他们厌恶的对象转化为一种激动人心的挑战。去伪存真，从一个实践者的角度来体验和找寻适合我们自己的工程方法。因为我们相信，同一件事情，你可以用很多种方法来做，但只有少数几种方法能够让你获得成功。最近医学信息论坛上的讨论，又让我得以重新审视一下一些工程方法在这个领域的应用在软件工程过程体系的这么多繁文缛节背后，或者至少在

3、实际操作层面，对最终项目的成功发布真正起到决定性作用的只有两个：一个是需求管理，一个是配置管理（包括变更和发布管理在内）。它们分别是项目的一进一出，把好这两道关，其他的东西，不管是分工，进度，风险控制等等，都可以顺势衍生出来。对于需求人员来说，最忌讳两种做法，一种是“传声筒”，一种是“捏造需求”。因此，要做好用户和技术人员的桥梁，需求人员除了具备一定的沟通技巧之外，还需要：1、深知沟通过程的基本原理，以及常见的沟通陷阱。2、基本的需求分析（即对原始需求进行正确的提炼和整理）的技能。更多企业商业智能BI信息化相关信息获取http://www.f

4、inereport.com/http://www.finebi.com/关于第一点，玩过多人传话之类游戏的人应该都比较了解。而关于第二点，则需要具备一些工程知识和技能。举个例子，很多医院流程里面都有三查三对，有些还是三查七对。但有些新手设计的用户界面，如果没有注意这一点，经常会把一些重要信息（比如病人姓名、性别、年龄）显示得不够显眼。于是医生提出，你这个字体能不能大一点，这个属于一个原始的客户需求。一般医生忙起来也不会跟你说得很细，或者最多跟你说姓名、年龄要大一点（可能因为他是妇科医生，一般来的都是妇女，也不用关心性别了）。于是，“传声筒”型

5、的需求人员就会原样告诉技术人员，让他们把姓名、年龄搞大。哪天轮到另外一个科室要上这个系统了，又来了一个需求，叫做把性别搞大。然后开发人员又要改，测试和变更管理等相关人员又要就类似的问题再检查和跟踪一遍。或者，其中有一个人提出，干脆把整个界面的字体都搞大点好了，省得每次都改。可能因为这个人在某些方面比较资深，或者比较能说会道比较有感染力，或者在职务上本身就有一定的影响力，而刚好这个医院的老医生比较多，一些人可能认为这些医生本来电脑操作就不熟练，眼睛又不好使，所以也同意了把整个界面的字体搞大。甚至，还有人提出，干脆把整个界面的字体做成可配置的，听

6、起来也不错，却没想到这又增加了测试、实施和维护工作的复杂度。最后，系统一升级，医生吓了一跳，怎么整个界面的字体都变大了。有些得过且过的医生倒也不再提了，越改越不像样，反正我要看的那些信息，我凑近屏幕仔细找找就好了。这就是一个典型的“捏造需求”案例。从这个例子可以看出，“传声筒”相对还好一些，最多会让类似的需求反复提反复改（甚至还会出现一些前后矛盾的需求，比如改过来又改过去），成本增加一些，需求变更的收敛速率低一点而已；最可怕的是“捏造需求”，而且在小型项目里面，大多是项目经理充当需求人员的角色，他一旦对需求判断错误，对项目产生的后果将不堪设想

7、。更多企业商业智能BI信息化相关信息获取http://www.finereport.com/http://www.finebi.com/以前曾经看到过一个诊所预约系统，由于前期需求不充分但客户又急要一个技术方案，在制定一些具体技术规格的时候，项目经理为了能做出一些亮点，提出让预约者直接看到被预约资源的使用情况，以便提高预约申请的通过率。如果是在办公楼里面，预订会议室，这是个很好的办法，但在医疗行业是完全行不通的，这违反了病人、护士/接待员和医生的基本生产关系。幸运的是，在最终方案出台之前，经过多方努力，终于修正了这个想法。要不然，就算你好不容

8、易把第一个版本的原型做出来了，拿给用户提意见，用户一看你就不懂医疗，别的也懒得跟你谈了。实际项目中的这些问题，用软件工程的理论进行解释，就是缺少对于业务需求的把握。