各行各业都在使用和开发不同的软件，可以说软件无处不在，从分类上说，软件是一种最复杂的人造产品之一，是人们为了让机器实现一些功能，而去设计，分析并实现的产品。
我们先对典型的软件开发过程进行分析，一般从计划阶段的需求收集和需求分析，到实际的编码开发，测试和维护，是大多数软件项目的生命周期。但是我们可以看到的成本，是从分析，设计到编码测试过程中项目合同的成本，是水面上的一小部分，但是我们看不到的巨大隐藏冰山，是在系统维护过程中所耗费的巨大的成本，尽管我们在软件开发过程中，采取了一些质量保障手段，但可能还是会遇到软件危机。
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议提出软件危机（Software crisis）一词。而1960年代中期开始爆发众所周知的软件危机，为了解决问题，在1968、1969年连续召开两次著名的NATO会议（北约峰会），并同时提出软件工程的概念。软件危机一般产生的后果是：
1.开发成本高，投资一再追加，往往是实际成本比预算成本高出一个数量级。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量。
2进度难控制，拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉，也会耽误软件使用者的工作。
3质量无法保证，软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制上的困难。软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患。
我们以一组属性来描述评价产品质量，软件质量通常包括以下特性：功能正确、可靠、易用、效率、可维护、可测试等，质量属性相互之间也并不是独立的，而是有相关关系的，+表示行属性对列属性是正向相关的，—则是相反，因此软件架构设计对质量属性进行衡量和取舍，同时也要充分考虑软件在不同用户的核心要求。
对于不同用户来说，核心的质量方面的需求是不同的，但是重叠的部分有三点，其中最最重要的软件质量是软件的可靠性，是其他质量保证的基础，也是不可替代的基石。
软件为什么会失效呢，为什么不能按照要求完成最初设计的功能呢？人在设计软件时候，其实就存在一些错误Error，是指实际值偏离你最初的期望，往往是由人为造成的；error导致代码存在一些fault，fault通常是由于程序中不正确的步骤，过程或者数据定义，导致程序出现了非故意的、不可预料的行为。fault又会导致出现failure，是一个系统或者组件不能完成它被要求的功能。用比较流畅的话来说呢，一些人为的error，使得程序中产生了不正确的步骤、过程和数据定义，从而使程序出现了一些不可预料的fualt，这些 fault最终又致使系统或者组件不能完成了最初要求的功能，也就是failure。
那我们明白了失效的机理之后，如何去更好的设计，才能在实践中提高软件的质量呢？
形式化方法是一系列用于描述和分析系统的符号表示法及相关技术，它们以一些数学理论为基础，如逻辑、自动机和图论等，且都致力于提高软件系统的质量。针对软件系统的的形式化方法，包括软件系统的形式化规约(specification)和形式化验证(verification)例如：时序逻辑、有限自动机、Petri网、进程代数等。建模的过程就是对模型的抽象过程，既然是抽象的话，就不可能保留所有细节，需要对重要细节进行抽象，对不重要细节进行忽略，就像论文的摘要，可以概括地表达目的，内容和效果，忽略了方法实现的细节。
实际上，形式化方法是从硬件设计开始普及的。一个著名的例子是：当年Intel的Pentium CPU浮点运算单元出错(FDIV Bug)，数以万计的CPU不得不回收和替换，给Intel造成了巨大损失(475M $)。此后Intel开始在其芯片设计中广泛采用形式化方法。计算机硬件巨头如IBM，AMD， NVIDIA 和 CADENCE[2]等等也都是形式化方法的使用者。1996年，欧洲航天局首次发射的阿丽亚娜5型火箭，由于惯性导航系统发送的错误指令（浮点数转换为整数造成溢出），导致火箭在发射仅仅37秒后便偏离了预定轨道，最终坠毁。此后EADS公司开发阿丽亚娜火箭的任务调度模型就开始使用形式化方法。此外我国的玉兔号月球车控制系统和我国第一个自主研发的空间飞行器嵌入式实时操作系统SpaceOS[5]，也都是通过形式化方法验证其正确性。