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

更多企业商业智能BI 信息化相关信息获取 / / 医疗信息化领域的软件工程 软件工程从来就不是一门精细的学问，在我看来，在没有弄清楚人类思维的核心规律之 前，任何力求精确的模型/度量/计算都是徒劳的。再加上一些管理者不断地拿一些现成的过 程和方法来进行换汤不换药的概念翻新，使得本来很多确实成效不错的过程和方法沦落成为 玩弄技术管理的工具，甚至企业管理的政治口号。最终，使得很多技术牛人对软件工程这个 领域嗤之以鼻。确实 ，没有任何两个个软件开发，可以用完全相同的方法学取得成功。然而， 当一部分技术牛人的兴趣，从机器的运行规律迁移到人脑以及人类组织的运行规律上面来的 时候，他们才惊奇地发现原来它们是如此的相似：整个世界就是一部计算机，而我们每个人 都是其中的一个计算单元。而软件工程领域所有的这些不确定性，也从他们厌恶的对象转化 为一种激动人心的挑战。 去伪存真，从一个实践者的角度来体验和找寻适合我们自己的工程方法。因为我们相信， 同一件事情，你可以用很多种方法来做，但只有少数几种方法能够让你获得成功。 最近医学信息论坛上的讨论，又让我得以重新审视一下一些工程方法在这个领域的应用 在软件工程过程体系的这么多繁文缛节背后，或者至少在实际操作层面，对最终项目的成 功发布真正起到决定性作用的只有两个：一个是需求管理，一个是配置管理（包括变更和发 布管理在内）。它们分别是项目的一进一出，把好这两道关，其他的东西，不管是分工，进 度，风险控制等等，都可以顺势衍生出来。 对于需求人员来说，最忌讳两种做法，一种是 “传声筒” ，一种是“捏造需求”。因此， 要做好用户和技术人员的桥梁，需求人员除了具备一定的沟通技巧之外，还需要： 1、深知沟通过程的基本原理，以及常见的沟通陷阱。 2、基本的需求分析（即对原始需求进行正确的提炼和整理）的技能。 更多企业商业智能BI 信息化相关信息获取 / / 关于第一点，玩过多人传话之类游戏的人应该都比较了解。而关于第二点，则需要具备一些 工程知识和技能。 举个例子，很多医院流程里面都有三查三对，有些还是三查七对。但有些新手设计的用 户界面，如果没有注意这一点，经常会把一些重要信息（比如病人姓名、性别、年龄）显示 得不够显眼。于是医生提出，你这个字体能不能大一点，这个属于一个原始的客户需求。一 般医生忙起来也不会跟你说得很细，或者最多跟你说姓名、年龄要大一点（可能因为他是妇 科医生，一般来的都是妇女，也不用关心性别了）。于是， “传声筒”型的需求人员就会原 样告诉技术人员，让他们把姓名、年龄搞大。哪天轮到另外一个科室要上这个系统了，又来 了一个需求，叫做把性别搞大。然后开发人员又要改，测试和变更管理等相关人员又要就类 似的问题再检查和跟踪一遍。或者，其中有一个人提出，干脆把整个界面的字体都搞大点好 了，省得每次都改。可能因为这个人在某些方面比较资深，或者比较能说会道比较有感染力， 或者在职务上本身就有一定的影响力，而刚好这个医院的老医生比较多，一些人可能认为这 些医生本来电脑操作就不熟练，眼睛又不好使，所以也同意了把整个界面的字体搞大。甚至， 还有人提出，干脆把整个界面的字体做成可配置的，听起来也不错，却没想到这又增加了测 试、实施和维护工作的复杂度。最后，系统一升级，医生吓了一跳，怎么整个界面的字体都 变大了。有些得过且过的医生倒也不再提了，越改越不像样，反正我要看的那些信息，我凑 近屏幕仔细找找就好了。这就是一个典型的 “捏造需求”案例。 从这个例子可以看出， “传声筒”相对还好一些，最多会让类似的需求反复提反复改（甚 至还会出现一些前后矛盾的需求，比如改过来又改过去），成本增加一些，需求变更的收敛 速率低一点而已；最可怕的是 “捏造需求” ，而且在小型项目里面，大多是项目经理充当需 求人员