（1）我们经常遇到困难，是因为我们掌握的知识还不够。
安全关键软件是指应用于航天、航空、交通、医疗、军事、核能等领域，运行情况会影响到人身和设施安危的软件系统，该类软件无疑值得施以有效的方法追求“万无一失”。最有效的方法就是“高质量的过程产生高质量的产品”，在这一理念下，广为人知的是CMMI和DO-178C，前者评判一个组织的能力，而后者评判一个产品是否合格。
使用CMMI或DO-178C，无论开展研制还是检查，可能会牺牲一些“发挥”的空间，但是更强的可依据性、易判定性也将避免不少疑问与纠结的可能。
软件工程难题的根源是软件状态空间超大、需求抽象漂移、人为因素交织等内在特征，而与软件应用的领域并无太大关联，因此无论是IEC61508、IEC26262、EN50128还是DO-178C，其本质要求都是类似的。
大多数安全关键系统并不是从零开始开发的，相反，更多是建立在已有功能和产品之上的衍生式项目，因此，重要的是整个生命周期中要考虑基于原有的系统，建立一个能够同时满足客户需要和安全性目标的现实产品。
软件产品保证的目标是在开发过程中应用严格的过程，从而防止、识别以及去除错误。就算我们对于“无知之错”没有足够好的办法，我们至少可以努力避免“无能之错”，避免由于我们自己的不小心或失误而犯错。一个软件验证报告会总结验证活动的结果。
“无知之错”又分为两种，一种是全人类都还没有掌握的知识，另一种是世界上有人掌握了、而我们自己还没有掌握的知识。我们经常遇到困难，是因为我们掌握的知识还不够。幸运的是，有很多牛人发现了很多有趣的知识，等待我们去掌握。例如DO-332中的动态内存分配，绝对是一份完整的应用指南。
与软件安全性有关的知识包括：
ARP4761民用机载系统与设备的安全性评估过程指南与方法
MIL882E系统安全性标准
DO-278A通信、导航、监视与空中交通管理软件完整性保证
DO-330软件工具鉴定
DO-331基于模型的开发与验证
DO-332面向对象技术与相关技术
DO-333形式化方法
DO-248C常见问题和讨论纪要，澄清DO-178C
CAST-17目标码的结构覆盖
CAST-19陈述数据耦合与控制耦合
FAA 8110.49使用模拟器或仿真器时管理开发和验证环境的指南
Standish Group研究报告
CWE
OWSAP
（2）需求和验证中的重要目标
DO-178C把软件生命周期划分为若干目标，A级软件共有71个目标，其中需求和验证有关的目标最多。
需求应该具有实现无关性，但有时也会有一些例外，例如界面需求或导出需求。需求应该是可以验证的，否定性需求一般是不可验证的，需要重写。这点在我们的项目中经常会遇到，以后的需求评审中要注意。
好的需求是艺术与科学的结合，需要创造性的思维来开发优化的需求，捕捉想要的功能，剔除不需要的功能。经验表明，直接使用原型代码进行飞行试验和合格审定，是没有好结果的。在需求中包含理由是一个很好的实践，当需求中有些东西可能对读者不明显，或者可以帮助读者理解为何存在该需求时，就应当给出理由。
在编程实现时，注释应当总结代码的目的和意图，而不要注释显而易见的东西，并且不要过度注释，过多或过少的注释都会降低易理解性。
验证的独立性，既包括职责分离，也包括权威性，这从技术方面对IV&V机构提出了更高的要求。
验证包括评审、分析和测试。同行评审一般基于检查单开展，要确保目标的可追踪性、准确性和一致性，提供定性评估。分析需要提供正确性可重复的证据，应当有书面记录，包括分析规程和分析结果。典型的分析包括双向追踪分析、最坏情况执行时间分析、堆栈使用率分析、链接分析、负载分析、内存映射分析、覆盖分析等。测试需要动态执行软件。
DO-178C聚焦基于需求的测试，因此不管高层需求还是低层需求，都强调需求本身的正确性。《如何打破软件》一书中聚焦了攻击软件的4种能力，并提供了测试输入、测试输出、测试数据以及测试计算的建议。
执行结构覆盖分析是为了识别基于需求的测试中没有得到执行的任何代码结构。对未覆盖的代码，应采取如下行动：1）补充测试用例；2）补充需求、补充测试用例；3）去除无效代码；4）对非激活代码进行分析。
在多数情况下，测试中用到的模拟器或仿真器需要得到鉴定，而工具鉴定是DO-330中的要求。
