在我关于Building an Aircraft using Agile的问题中看到评论的总体趋势，除成本之外的最大问题似乎是安全性。
人们是否觉得使用敏捷建立一个安全系统（或证明它是安全的）是不可能的？并非所有的迭代测试都能缓解这个问题吗？使用敏捷开发的软件是否可能永远不会像瀑布那样可靠？
答案 0 :(得分：5)
敏捷是一种管理项目的方法，而不是测试或验证已完成项目安全性的方法。
安全关键系统在完成后（功能方面）仍然需要进行大量测试才能绝对确定它实际上是最重要的。我希望这种工作可以交给一个专门针对这种测试的测试人员组成。
敏捷对软性需求很好，传统的产品生命周期足够长，业务目标已经发生变化，但在安全关键环境中，我认为快速变化的需求或指定的要求不是很严重的事情。
我不认为使用瀑布会以某种方式为代码提供一些内在的顺序或稳定性 - 如果个别冲刺得到妥善管理，代码经过测试和审查，那么较短的周期就会产生相同质量的代码，只是大块。
当事情变得有问题时，使用Scrum会在项目时间线的早期为您提供一个单挑 - 除了为表现不佳的经理/开发者/无论谁删除隐藏位置之外，它不会做任何事情。
简而言之，只要您不希望它测试您构建的内容，就可以使用敏捷方法构建任何类型的系统。那是测试人员。
答案 1 :(得分：3)
关于每个人似乎都缺少的安全关键系统的全部观点是，由于它们可能导致生命损失（有时是大规模的），因此必须证明它们是正确的。通常它们需要操作证书，除非许可机构认为系统的要求已经准确指定（通常使用Z和VDM等正式方法），设计是这些要求的反映（并且可以证明是这样的）并且代码是设计的准确反映（再次证明是这样）。
通常情况下，测试产品提供此类证据的选项并不存在（好吧，让我们开始使用核反应堆，波音777，Therac 25 - 无论如何，看看错误在哪里）。安全关键系统（特别是那些在S.I.L 3及以上分类的系统）需要全面而全面的文档，据我所知，这些文档在所有方面都与敏捷宣言完全不一致。安全关键系统的程序员甚至不允许对发布的软件进行更改而不要求许可机构对软件进行新的重新评估，这是正确的，因为严格要求证明第一个版本的正确性以及对catetrophic的影响。搞砸了。
答案 2 :(得分：2)
有许多备受瞩目的软件故障可以解决这个问题。特别是，Ariane 5 Flight 501和Therac-25都是软件故障的例子，它们使这个问题得到了明显的缓解。由于导航软件中的整数溢出，阿丽亚娜5号火箭在发射后37秒偏离其飞行路径。事故造成的设备损失了3.7亿美元，但并没有造成人员伤亡。同样不能说是Therac-25，一种用致命剂量辐射杀死几个人的医疗机器。
使用更好的软件方法可以预防这些问题吗？我不确定。导致阿丽亚娜5失败的管理决策与软件构建的方式没有多大关系，而且Therac-25调查受到了机器不可能失败的信念的阻碍。 p>
更好的测试方法可能有所帮助。很难相信一个好的静态类型编译器无法找到整数溢出。新的测试方法如Pex及其内置的定理证明器，能够搜索极端情况，并且可以识别出Therac-25中存在的传感器异常。
但是，除非您对安全做出不妥协的承诺，否则任何技术都不可靠，从最高级别的管理层到装运产品的人员。
答案 3 :(得分：1)
敏捷是一种动态开发模型 - 当您的应用程序的需求快速且无法预料地更改时，您可以使用它。此外，如果您的开发人员数量仍然可数。 你不要仅仅因为它是现代/ in / hip / cool而使用它。
当然，您可以在单元测试中发现错误，但他们从未证明他们缺席。在开发期间更改/添加应用程序的要求极大地涉及添加隐藏的错误。
对于安全关键应用程序的典型计划应用程序，您希望使用更多静态开发模型，如瀑布或v模型。
答案 4 :(得分：-1)
大多数安全关键或关键任务系统都可以从更标准的开发结构中受益，例如瀑布模型和正式的代码审查。这些方法有助于维护更加结构化的代码库。关于软件构建的好书 - 特别是如果项目已经开始使用敏捷过程 - Code Complete 2 ed.