Agile is a method of managing a project, not a method of testing or verifying the safety of a finished project.
A safety critical system would still need extensive testing after it is complete (functionality wise) to be absolutly sure it is actually up-to-task. I would expect that this sort of work would be given over to a separate team of testers who are specifically focussed on such testing.
Agile is good with soft requirements, where the traditional product lifecycle is long enough for the business goals to have changed, though in a safety-critical environment, I think that rapidly changing requirements or under-specified requirements would be A Very Bad Thing.
I don't buy the idea that using waterfall would in some way give the code some intrinsic order or stability - if the individual sprints are well managed, the code tested and reviewed, then the shorter cycle would produce code of equal quality, just in chunks.
Using Scrum gives you a heads-up earlier in the project timeline when things are getting problematic - it's not going to do anything but remove hiding places for poor performing managers / devs / whoever.
In short, it is possible to build any sort of system using Agile methods, just so long as you don't expect it to test what you have built. Thats for the testers.
There are a number of high-profile software failures that illuminate this issue. In particular, Ariane 5 Flight 501 and the Therac-25 are both examples of software failures that bring this problem into sharp relief. The Ariane 5 rocket veered off its flight path 37 seconds after launch due to an integer overflow in the guidance software. The accident cost $370 million in lost equipment, but there was no loss of life. The same cannot be said of the Therac-25, a medical machine that killed several people with lethal doses of radiation.
Could these problems have been prevented with a better software methodology? I'm not so sure. The management decisions that contributed to the failure of the Ariane 5 had little to do with the manner in which the software was constructed, and the Therac-25 investigation was hampered by the belief that it was not possible for the machine to fail.
Better testing methodologies could have helped. It's hard to believe that a good statically typed compiler would have failed to find the integer overflow. New testing methodologies like Pex, with its built-in theorem prover, have the capability to search for corner cases, and could have identified the sensor anomalies that existed in the Therac-25.
But no technique is reliable unless you have an uncompromising commitment to safety, from the very highest levels of management all the way down to the people who box the product for shipment.
每个人似乎都忽略了关于安全关键系统的全部要点是，由于它们有可能造成生命损失（有时是大规模的），因此必须证明它们是正确的。 通常他们需要操作证书，除非许可机构确信系统的要求已被准确指定（通常使用 Z 和 VDM 等正式方法），并且设计反映了这些要求（并且可以证明是这样的） ）并且代码准确地反映了设计（再次证明如此）。
通常情况下，测试产品以提供此类证据的选项并不存在（好吧，伙计们，让我们继续使用核反应堆、波音 777、Therac 25 - 无论什么，看看问题出在哪里）。 安全关键系统（特别是那些分类为 SIL 3 及以上的系统）需要彻底且全面的文档，据我所知，这在各个方面都与敏捷宣言完全不一致。 安全关键系统的程序员甚至不允许在没有向许可机构请求对软件进行新的重新评估的情况下对发布的软件进行更改，考虑到证明第一个版本的正确性的严格性以及对系统的灾难性影响，这样做是正确的。搞砸了。
The WHOLE point about safety critical systems that everyone seems to be missing here is that because of their potential to cause loss of life (sometimes on a large scale), they have to be proven to be correct. Often they require an operating certificate unless a licensing authority that is satisfied that the system's requirements have been accurately specified, (often using formal methods like Z and VDM), that the design is a reflection of those requirements (and can be proven to be such) and that the code is an accurate reflection of the design (again proven to be so).
More often than not, the option to test the product to provide such proof doesn't exist (OK guys let's go life with the nuclear reactor, Boeing 777, Therac 25 - whatever and see where the bugs are). Safety critical systems (especially those categorised at S.I.L 3 and above) need thorough and comprehensive documentation which is totally at odds with the Agile manifesto in all respects as far as I can see. Programmers of safety critical systems are not even allowed to make changes to the relesed software without requesting a new revaluation of the software from the licensing authority and rightly so, given the rigour that goes into proving the correctness of the first version and the catestrophic implications for a screw up.
对于精确规划的应用程序（通常是安全关键型应用程序），您需要使用更多的静态开发模型，例如瀑布模型或 v 模型。
Agile is a dynamic development model - You use it when requirements of your application are to be changed fast and unforeseen. Also if the number of your developers are still countable. You do NOT use it just because it is modern/in/hip/cool.
Sure you can find errors with unit tests, but they never prove their absence. Changing/Adding requirements of the application during development greatly involves adding hidden errors.
For exactly planned applications which is typical for safety critical applications you want to use more static development models like waterfall or v-model.
Most safety critical or mission critical systems can benefit from a more standard development structure such as the waterfall model and formal code reviews. Such methods help maintain a more structured code base. Great Book about software construction - especially if the project has already begun using an Agile process - Code Complete 2 ed.
发布评论
评论（5）
敏捷是一种管理项目的方法，而不是测试或验证已完成项目的安全性的方法。
安全关键系统在完成（功能方面）后仍需要进行广泛的测试，以绝对确保它确实能够胜任任务。 我希望此类工作将交给专门负责此类测试的单独测试人员团队进行。
敏捷对于软需求很有好处，传统的产品生命周期足够长，足以改变业务目标，但在安全关键的环境中，我认为快速变化的需求或未明确的需求将是一件非常糟糕的事情。
我不认为使用瀑布会在某种程度上给代码带来一些内在的顺序或稳定性——如果各个冲刺管理得当，代码经过测试和审查，那么较短的周期将产生相同质量的代码，只是在大块。
当事情出现问题时，使用 Scrum 可以让您在项目时间表的早期得到提醒 - 它不会做任何事情，只会消除表现不佳的经理/开发人员/任何人的藏身之处。
简而言之，使用敏捷方法构建任何类型的系统都是可能的，只要您不期望它测试您所构建的系统。 那是给测试人员的。
Agile is a method of managing a project, not a method of testing or verifying the safety of a finished project.
A safety critical system would still need extensive testing after it is complete (functionality wise) to be absolutly sure it is actually up-to-task. I would expect that this sort of work would be given over to a separate team of testers who are specifically focussed on such testing.
Agile is good with soft requirements, where the traditional product lifecycle is long enough for the business goals to have changed, though in a safety-critical environment, I think that rapidly changing requirements or under-specified requirements would be A Very Bad Thing.
I don't buy the idea that using waterfall would in some way give the code some intrinsic order or stability - if the individual sprints are well managed, the code tested and reviewed, then the shorter cycle would produce code of equal quality, just in chunks.
Using Scrum gives you a heads-up earlier in the project timeline when things are getting problematic - it's not going to do anything but remove hiding places for poor performing managers / devs / whoever.
In short, it is possible to build any sort of system using Agile methods, just so long as you don't expect it to test what you have built. Thats for the testers.
许多引人注目的软件故障都说明了这个问题。 特别是 阿丽亚娜 5 号航班 501 和 Therac-25 都是软件故障的例子，使这个问题更加突出。 由于制导软件中的整数溢出，阿丽亚娜 5 号火箭在发射后 37 秒偏离了飞行路径。 此次事故造成设备损失 3.7 亿美元，但没有造成人员伤亡。 但 Therac-25 却并非如此，这款医疗机器曾用致命剂量的辐射杀死了数人。
可以通过更好的软件方法来预防这些问题吗？ 我不确定。 导致 Ariane 5 故障的管理决策与软件的构建方式几乎没有关系，并且 Therac-25 调查因认为机器不可能发生故障而受到阻碍。
更好的测试方法可能会有所帮助。 很难相信一个好的静态类型编译器无法发现整数溢出。 新的测试方法，如 Pex 及其内置定理证明器，具有搜索极端情况的能力，并且可以识别 Therac-25 中存在的传感器异常情况。
但是，除非您对安全有坚定的承诺，从最高层的管理人员一直到将产品装箱装运的人员，否则任何技术都是可靠的。
There are a number of high-profile software failures that illuminate this issue. In particular, Ariane 5 Flight 501 and the Therac-25 are both examples of software failures that bring this problem into sharp relief. The Ariane 5 rocket veered off its flight path 37 seconds after launch due to an integer overflow in the guidance software. The accident cost $370 million in lost equipment, but there was no loss of life. The same cannot be said of the Therac-25, a medical machine that killed several people with lethal doses of radiation.
Could these problems have been prevented with a better software methodology? I'm not so sure. The management decisions that contributed to the failure of the Ariane 5 had little to do with the manner in which the software was constructed, and the Therac-25 investigation was hampered by the belief that it was not possible for the machine to fail.
Better testing methodologies could have helped. It's hard to believe that a good statically typed compiler would have failed to find the integer overflow. New testing methodologies like Pex, with its built-in theorem prover, have the capability to search for corner cases, and could have identified the sensor anomalies that existed in the Therac-25.
But no technique is reliable unless you have an uncompromising commitment to safety, from the very highest levels of management all the way down to the people who box the product for shipment.
每个人似乎都忽略了关于安全关键系统的全部要点是，由于它们有可能造成生命损失（有时是大规模的），因此必须证明它们是正确的。 通常他们需要操作证书，除非许可机构确信系统的要求已被准确指定（通常使用 Z 和 VDM 等正式方法），并且设计反映了这些要求（并且可以证明是这样的） ）并且代码准确地反映了设计（再次证明如此）。
通常情况下，测试产品以提供此类证据的选项并不存在（好吧，伙计们，让我们继续使用核反应堆、波音 777、Therac 25 - 无论什么，看看问题出在哪里）。 安全关键系统（特别是那些分类为 SIL 3 及以上的系统）需要彻底且全面的文档，据我所知，这在各个方面都与敏捷宣言完全不一致。 安全关键系统的程序员甚至不允许在没有向许可机构请求对软件进行新的重新评估的情况下对发布的软件进行更改，考虑到证明第一个版本的正确性的严格性以及对系统的灾难性影响，这样做是正确的。搞砸了。
The WHOLE point about safety critical systems that everyone seems to be missing here is that because of their potential to cause loss of life (sometimes on a large scale), they have to be proven to be correct. Often they require an operating certificate unless a licensing authority that is satisfied that the system's requirements have been accurately specified, (often using formal methods like Z and VDM), that the design is a reflection of those requirements (and can be proven to be such) and that the code is an accurate reflection of the design (again proven to be so).
More often than not, the option to test the product to provide such proof doesn't exist (OK guys let's go life with the nuclear reactor, Boeing 777, Therac 25 - whatever and see where the bugs are). Safety critical systems (especially those categorised at S.I.L 3 and above) need thorough and comprehensive documentation which is totally at odds with the Agile manifesto in all respects as far as I can see. Programmers of safety critical systems are not even allowed to make changes to the relesed software without requesting a new revaluation of the software from the licensing authority and rightly so, given the rigour that goes into proving the correctness of the first version and the catestrophic implications for a screw up.
敏捷是一种动态开发模型 - 当应用程序的需求发生快速且不可预见的变化时，您可以使用它。 另外，如果您的开发人员数量仍然可数。
您不会仅仅因为它现代/时尚/时尚/酷而使用它。
当然，您可以通过单元测试发现错误，但它们永远无法证明它们不存在。 在开发过程中更改/添加应用程序的需求很大程度上涉及添加隐藏的错误。
对于精确规划的应用程序（通常是安全关键型应用程序），您需要使用更多的静态开发模型，例如瀑布模型或 v 模型。
Agile is a dynamic development model - You use it when requirements of your application are to be changed fast and unforeseen. Also if the number of your developers are still countable.
You do NOT use it just because it is modern/in/hip/cool.
Sure you can find errors with unit tests, but they never prove their absence. Changing/Adding requirements of the application during development greatly involves adding hidden errors.
For exactly planned applications which is typical for safety critical applications you want to use more static development models like waterfall or v-model.
大多数安全关键或任务关键系统可以受益于更标准的开发结构，例如瀑布模型和正式的代码审查。 此类方法有助于维护更加结构化的代码库。 关于软件构建的好书 - 特别是如果项目已经开始使用敏捷流程 - Code Complete 2 ed。
Most safety critical or mission critical systems can benefit from a more standard development structure such as the waterfall model and formal code reviews. Such methods help maintain a more structured code base. Great Book about software construction - especially if the project has already begun using an Agile process - Code Complete 2 ed.