保持关键生命的决策支持应用程序的可交付性

在早期的生活中，我编写了几个不同的关键生命的应用程序，它们在复杂领域中帮助决策支持。在这些领域中，一个错误可能导致人们受伤或死亡。随着代码的编写，新的用例被发现。如果有个两千磅重的婴儿肾衰竭怎么办?这是打错字还是真的?如果实验室里的科学家没有按照描述的公式来做呢?如果……如果……

自然地，对伤害的恐惧会减缓开发，因为大量的谨慎。合格的临床医生和科学家们能够描述出美妙的场景，并总是给出解决方案。我们将以以下格式记录每个场景或用例:

鉴于这些输入当我们做点什么然后返回此消息

随着产品的开发和新的用例的发现，临床医生总是会有一个答案。例如，即使是2000磅重的婴儿也需要处方的解决方案。

鉴于一个2000磅重的婴儿当规定的任何东西然后还“问一个合格的临床医生。”

如果所有的输入都能被发现，那么它就可以被编入正确的输出集合中。随着产品的成熟，一种模式开始出现——所有边缘情况都遵循相同的算法。任何患者或场景，如果我们不清楚解决方案，就会向临床医生或科学家提出明确的问题。所有边缘案例都遵循这个模式，然后我意识到——所有案例都遵循这个模式，一个默认的用例，“询问一个合格的临床医生”。

鉴于任何输入它不满足任何其他输入条件当我们做任何事然后返回“询问合格的临床医生”

如果第一个用例或场景是“询问一位合格的临床医生”，并仔细编码其他精确的场景，我们理论上可以每天发布，因为“询问一位合格的临床医生”场景将保护我们免受“假如，假如”场景的影响。

这是我们保持生命关键决策支持应用程序始终可交付的第一步。在以后的文章中，我们将讨论如何仔细地编写其他精确的场景。就像所有好的决策支持系统一样，在你采用这种做法之前，“问问你所在组织和领域的合格临床医生。”