撞向山体是空中旅行遇难的主要原因。卡利坠机事件促使人们采用了近地警告系统(GPWS)来减少此类事故。较旧的基于雷达的系统有时在可能出现撞击之前的10秒钟才发出警告信息。近地警告系统包含一个数字世界地形图。如果飞机过于接近一座山，它可提前一分钟给飞行员警告，并自动显示附近山体的地形图。危险的山峰会被显示为红色。GPWS在几起事件中很可能帮助避免了坠机的发生，其中包括飞行员错误地设置了高度计，企图在能见度差的时候降落，还有把建筑灯误认为是机场灯的情形等。在GPWS实施之后，再也没有出现过美国商业客机撞到山体的事件。
为了讲解可以帮助建立更好的和更安全的系统的更多原则，我们以自动飞行系统为例，考虑它的几个方面。在这些方面的一位专家强调了以下几点内容[7]：
●用户需要反馈，来了解系统任何时刻正在干什么。如果自动飞行出现故障，或者飞行员因为某些原因必须关闭自动飞行，而飞行员必须要突然接管时，这是至关重要的。一个例子是，当自动化系统正在运行时，即使油门没必要产生移动，也可以让油门像手动操作一样移动。
●该系统的行为应该是有经验的用户所期望的表现。在接近飞行员自己想要的高度时，他们往往会减少飞机的爬升速率。在麦道MD-80飞机上，自动化系统所保持的爬升率会达到飞行员通常选择的速度的8倍。飞行员因为担心飞机可能会冲过目标高度，因此会手动作出调整，却没有意识到，他们的干预会导致飞机达到所需高度自动拉平的功能被关闭。因此，由于自动化功能表现出了意想不到的行为，会造成飞机爬升过高，而这正是飞行员试图阻止的。（随着培训加强，该问题出现的频率也下降了。）
●工作负荷过低也可能是危险的。显然，劳累过度的操作员会更容易犯错误。自动化的一个目标是减少人的工作量。然而，工作量过低也会导致厌倦、注意力不集中，或对现状缺乏认识。如果飞行员必须紧急接管的话，这也是一个危险。
冗余和自检
对于我们的生活和命运所依赖的系统来说，冗余和自检这两种技术都非常重要。冗余有几种形式。在飞机上，可能有几台计算机来控制一个襟翼的制动器。如果一台计算机出现故障，另一台还可以完成此项工作。软件模块可以检查自己的结果，通过一个标准进行比对；也可以通过两种不同的方式来计算同样的事情，然后对这两个结果进行比对。一种更复杂的冗余形式是，以飞机飞行控制系统为例，为了防止一个编程团队采用一贯错误的假设或方法。可以让三个独立的小组使用三种不同的编程语言编写模块，实现相同的功能。这些模块在三个不同的计算机上运行。用第四个单元检查这三个模块的输出，最后选择由至少两个获得的相同结果。安全专家认为，即使程序员独立工作，他们往往也倾向于犯同一类型的错误，特别是如果在程序需求说明中包含有错误、模糊或遗漏的地方。因此，这种类型的“投票”冗余，虽然在许多安全攸关应用中是有用的，但是也可能无法克服在软件开发过程中的其他方面的问题。
测试
对一个软件进行充分和精心设计的测试的重要性，是怎么强调都不为过的。测试不是随意的。使用一些原则和技术可以把测试做得更好。在许多以前可以正常工作的系统中，出现显著的计算机系统故障的时间点，都是在安装更新或升级后不久。即使是很小的变化都需要进行彻底的测试。不幸的是，许多精打细算的经理、程序员和软件开发人员都把测试看作是一种可有可无的奢侈品，或者是你为了赶最后期限或省钱就可以省略的一个步骤。这是一个很常见，但同时又很愚蠢和危险，而且往往是不负责任的态度。
在软件系统中寻找错误时，一种被称作是“独立验证和确认（IV&；V）”的实践也非常有用。IV&；V是指找一个独立的公司（即，不是开发程序的公司，也不是客户）来测试和验证软件。由独立机构来进行测试和验证并不是对所有项目都现实，但很多软件开发商都拥有自己的测试团队，他们独立于开发系统的程序员。IV&；V团队扮演的是“对手”的角色，试图找到软件中的缺陷。IV&；V之所以有帮助，出于两个原因。设计和/或开发系统的人会认为该系统能够正常工作。他们认为，他们想到了所有可能出现的问题，并且解决了它们。虽然拥有最好的意图，但是他们往往测试的是他们已经考虑过的问题。另外，在意识或潜意识里，建造该系统的人可能不愿意在里面找到存在的缺陷。他们的测试可能是半心半意的。独立测试人员可以带来不同的视角，对他们来说，找到缺陷的成功不会在情感上或职业上与这些缺陷的责任有任何关联。