看看我关于使用敏捷建造飞机的问题中评论的总体趋势,除了成本之外,最大的问题似乎是安全性。
人们是否觉得不可能使用敏捷构建一个安全的系统(或证明它是安全的)?不是所有的迭代测试都减轻了这一点吗?使用敏捷开发的软件有可能永远不会像瀑布这样的软件那样可靠吗?
看看我关于使用敏捷建造飞机的问题中评论的总体趋势,除了成本之外,最大的问题似乎是安全性。
人们是否觉得不可能使用敏捷构建一个安全的系统(或证明它是安全的)?不是所有的迭代测试都减轻了这一点吗?使用敏捷开发的软件有可能永远不会像瀑布这样的软件那样可靠吗?
敏捷是一种管理项目的方法,而不是一种测试或验证已完成项目安全性的方法。
安全关键系统在完成后(功能方面)仍需要进行广泛的测试,以绝对确定它实际上可以完成任务。我希望这类工作将交给一个单独的测试人员团队,他们专门专注于此类测试。
敏捷适用于软需求,传统的产品生命周期足够长,足以改变业务目标,但在安全关键型环境中,我认为快速变化的需求或未指定的需求将是一件非常糟糕的事情。
我不相信使用瀑布会以某种方式给代码一些内在的顺序或稳定性的想法 - 如果各个冲刺得到良好的管理,代码测试和审查,那么较短的周期将产生相同质量的代码,就在块。
当事情出现问题时,使用 Scrum 可以让您在项目时间线的早期提前提醒您——它不会做任何事情,只会为表现不佳的经理/开发人员/任何人移除藏身之处。
简而言之,可以使用敏捷方法构建任何类型的系统,只要您不希望它测试您构建的内容。那是给测试人员的。
有许多引人注目的软件故障说明了这个问题。特别是,Ariane 5 Flight 501和Therac-25都是软件故障的例子,它们使这个问题得到了极大的缓解。由于制导软件中的整数溢出,阿丽亚娜 5 号火箭在发射后 37 秒偏离了其飞行路径。事故造成设备损失 3.7 亿美元,但没有人员伤亡。Therac-25 的情况并非如此,这是一种医疗机器,用致命剂量的辐射杀死了几个人。
是否可以通过更好的软件方法避免这些问题?我不确定。导致 Ariane 5 失败的管理决策与软件的构建方式几乎没有关系,Therac-25 的调查因认为机器不可能发生故障而受到阻碍。
更好的测试方法可能会有所帮助。很难相信一个好的静态类型编译器会找不到整数溢出。新的测试方法,如Pex及其内置的定理证明器,能够搜索极端情况,并且可以识别 Therac-25 中存在的传感器异常。
但没有任何技术是可靠的,除非您对安全做出不妥协的承诺,从最高级别的管理人员一直到装箱产品的人员。
每个人似乎都在这里遗漏的关于安全关键系统的全部要点是,由于它们有可能导致生命损失(有时是大规模的),因此必须证明它们是正确的。他们通常需要操作证书,除非许可机构确信系统的要求已被准确指定,(通常使用 Z 和 VDM 等正式方法),设计反映了这些要求(并且可以证明是这样的) ) 并且代码是设计的准确反映(再次证明是这样)。
通常情况下,不存在测试产品以提供此类证明的选项(好吧,伙计们,让我们开始使用核反应堆、波音 777、Therac 25 - 随便看看错误在哪里)。安全关键系统(尤其是那些归类为 SIL 3 及以上的系统)需要全面而全面的文档,据我所知,这在所有方面都与敏捷宣言完全不一致。考虑到证明第一个版本的正确性的严格性以及搞砸了。
敏捷是一种动态开发模型——当您的应用程序的需求发生快速和不可预见的变化时,您可以使用它。此外,如果您的开发人员的数量仍然是可数的。您不会仅仅因为它是现代/时尚/时尚/酷而使用它。
当然,您可以通过单元测试找到错误,但它们永远不会证明它们不存在。在开发过程中更改/添加应用程序的需求很大程度上涉及添加隐藏错误。
对于安全关键应用程序的典型应用程序,您希望使用更多静态开发模型,如瀑布或 v-model。
大多数安全关键或任务关键系统可以受益于更标准的开发结构,例如瀑布模型和正式的代码审查。此类方法有助于维护更结构化的代码库。关于软件构建的好书 - 特别是如果项目已经开始使用敏捷过程 - Code Complete 2 ed。