敏捷编程是否也…针对安全关键系统?[关闭]

我曾经使用一个基本上是瀑布式的过程来研究空中交通控制系统,这些项目肯定会从敏捷实践中受益。我不想考虑如果没有任何单元级的自动回归测试,这些代码中有多少是“偶然”工作的。前面的要求有点像是一条红鲱鱼。虽然航天系统很可能是你能达到的最接近预先设定的基本要求,但是你 仍然 对含糊不清的需求的含义有争论,这些需求只有在系统应该在验收测试时才会出现。或者你有吞吐量问题,没有人考虑过,由于大爆炸集成,这些问题会在游戏后期出现。首先测试,尖峰解决方案,持续集成,成对编程——我认为所有这些都会改进我所做的项目。

更新:更不用说在项目结束时“设计文档”是一堆谎言的频率了,因为设计必须在现实面前发展。敏捷认识到了紧急设计的事实,它在瀑布项目中和其他项目中一样真实,而不是试图假装在开始编写代码之前就可以得到设计。

我在航空航天(特别是卫星)工作,我们使用混合方法,因为我们面临两个不同的问题:现实需求和业务流程需求。

我们对航天器的要求和关键部分采用瀑布式的方法,因为卫星的变化缓慢且罕见,而且在那里搞砸是很糟糕的。

但是对于不断变化的业务流程,我们使用敏捷的方法,因为 怎样 他们驾驶的航天器是不断变化的,因为客户的需求。在那里搞砸意味着在最坏的情况下,用户得不到好的结果。

我在这个领域没有足够的经验(除了航空系统的用户)来形成我自己真正独立的观点。然而,我一直在阅读关于具有最佳跟踪记录的关键系统的所有内容,这让我相信瀑布实际上是最好的方法。这是有可能的,因为人们愿意考虑额外的浪费冻结要求,以促进安全。我想在这种情况下,折衷是有点不同的。

Determining the Applicability of Agile Practices to Mission and Life-Critical Systems

Agile Suitability Filters

简而言之,没有“敏捷”编程。有一套做法。有些项目比其他项目更适合自己,但总的来说,任何项目都会从一些实践中受益。

人们通常关心的最大领域是建模和体系结构。有很多团队使用敏捷实践——例如,我知道 Fun3d team 与美国国家航空航天局-他们使用敏捷的实践和处理像航天飞机支持。

有几个小组专门从事这类工作,所以这是可能的。你只需要像其他方法一样意识到你的风险。

敏捷应该是一个有纪律的过程。无论您的流程如何,在这种情况下的安全问题都应该提前解决。我不知道在迭代中交付、使用持续构建系统、计算程序员消耗率、举行站立会议、让客户积极参与等等都会对安全产生负面影响。

有很多考虑。首先是你的安全重要性。如果你的答案是“A”或“B”(实际上是“A”),那么绝对不是。无论以何种形式或形式做敏捷,你都无法逃脱。有非常严格的编码标准,文档标准和过程标准需要从一级软件(我的背景大约15年)。这包括:

• 完全上下可追溯性。
• 全部分支覆盖。
• 完全多条件覆盖。
• DO-178B列出的基本文件包括:SRD、SDD、SCI、SCMP、SDP、TQP、SCI……

因此,您不仅必须认证您的代码、设计和需求,而且还必须认证工具集、编译器、自动化测试设备等等。

简言之,这真的不是一个小壮举,也不会由一个小团队完成。同样地,接口是非常坚固的、非常具体的以及静态的。更改接口通常需要与3家以上公司(机身制造、供应商1和供应商2)进行协调。

老实说,12行代码更改的成本可能高达17万美元。当然,500行代码的更改将是19万美元。简而言之,有一个与A级代码相关的巨大的过程开销(与B级相比要少得多,与C级相比要少得多,与D级相比要少得多),这使得小的迭代非常昂贵;也就是说,要得到一个充满燃料的、飞行777来测试一个小的变更,需要花费大量的资金。即使是大型商用飞机的系统测试实验室的燃烧率也将达到10000美元/天。

例如: A级:抬头显示器、反推装置、动力系统、FADEC(发动机控制) B级:二次切换逻辑,语音通信系统。 C级:飞行数据链。 D级:飞行娱乐系统。

D级,也许C级,可能是敏捷的候选者。

我认为这取决于在这个过程中安全需求是如何集成的。如果它们是一组额外的测试,那么这与敏捷编程没有任何矛盾。我认为敏捷方法可以帮助您生成更安全的软件,因为敏捷项目往往比瀑布式项目质量更高。重要的是,您安装的附加质量保证也用于敏捷方法。

但是,如果将安全需求应用到构建过程中,这可能与敏捷方法相矛盾。

实际上,瀑布模型有一个变化称为V模型,这是IEC61508所支持的。它是瀑布式的,但是有重新迭代基本项目周期的规定。在这种情况下,重新迭代的主要目的是处理过程中各个阶段检测到的问题。基本的想法是,在以后遇到问题的时候,在你的过程中,你必须去处理和审查你的变化的影响。

所以它不是很敏捷,但是…-)

你可以使用敏捷的方法,但是第一步必须包括你的安全和保障方面,或者至少提供这些方面,这样你就不会自暴自弃,最终改写整个过程。但我同意布莱恩的观点,你最好在此类项目中使用瀑布方法。

在2009年欧洲之星会议上,Gittie Ottosen谈到了他们在公司如何做到敏捷。令人印象深刻的是这家公司 Systematic 正在为飞机、军事等创建软件。他们按照CMMI 5、ISO 9001和AQAP 150&2110进行创建。所以我想敏捷可以应用于高规则的系统。也许可以试着查一下那个报告,然后试着从他那里得到更多的信息。