在上个世纪60年代中期爆发了众所周知的软件危机。为了克服这一危机，
在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。
与此同时，软件研究人员也在不断探索新的软件开发方法。至今已形成了八类软件开发方法。
中文名 软件开发方法
提出时间 1972年
原则 意外故障采取措施
1 Parnas方法
2 SASD方法
3 面向数据结构的软件开发方法
4 Jackson方法
5 Warnier方法
6 问题分析法
7 面向对象的软件开发方法
8 自底向上的归纳
9 自顶向下的分解
10 OMT的基础是对象模型
11 需求分析彻底
12 可维护性大大改善
13 可视化开发方法
14 ICASE
15 软件重用和组件连接
16 基于软件复用库的软件重用
17 与面向对象技术结合
18 组件连接
Parnas方法
最早的软件开发方法是由D．Parnas在1972年提出的。
由于当时软件在可维护性和可靠性方面存在着严重问题，因此Parnas提出的方法是针对这两个问题的。
首先，Parnas提出了信息隐蔽原则：在概要设计时列出将来可能发生变化的因素，并在模块划分时将这些因素放到个别模块的内部。
这样，在将来由于这些因素变化而需修改软件时，只需修改这些个别的模块，其它模块不受影响。
信息隐蔽技术不仅提高了软件的可维护性，而且也避免了错误的蔓延，改善了软件的可靠性。
现在信息隐蔽原则已成为软件工程学中的一条重要原则。
Parnas提出的第二条原则是在软件设计时应对可能发生的种种意外故障采取措施。
软件是很脆弱的，很可能因为一个微小的错误而引发严重的事故，所以必须加强防范。
如在分配使用设备前，应该取设备状态字，检查设备是否正常。
此外，模块之间也要加强检查，防止错误蔓延。
Parnas对软件开发提出了深刻的见解。
遗憾的是，他没有给出明确的工作流程。所以这一方法不能独立使用，只能作为其它方法的补充。
SASD方法
1978年，E．Yourdon和L．L．Constantine提出了结构化方法，即SASD方法，
也可称为面向功能的软件开发方法或面向数据流的软件开发方法。
1979年TomDeMarco对此方法作了进一步的完善。Yourdon方法是80年代使用最广泛的软件开发方法。
它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。
这一方法不仅开发步骤明确，SA、SD、SP相辅相成，一气呵成，而且给出了两类典型的软件结构（变换型和事务型），
便于参照，使软件开发的成功率大大提高，从而深受软件开发人员的青睐。
面向数据结构的软件开发方法
Jackson方法
1975年，M．A．Jackson提出了一类至今仍广泛使用的软件开发方法。
这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。
这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。
该方法也可与其它方法结合，用于模块的详细设计。
Jackson方法有时也称为面向数据结构的软件设计方法。
Warnier方法
1974年，J．D．Warnier提出的软件开发方法与Jackson方法类似。
差别有三点：
一是它们使用的图形工具不同，分别使用Warnier图和Jackson图；另一个差别是使用的伪码不同；
最主要的差别是在构造程序框架时，Warnier方法仅考虑输入数据结构，
而Jackson方法不仅考虑输入数据结构，而且还考虑输出数据结构。
问题分析法
PAM问题分析法。PAM（Problem Analysis Method）是80年代末由日立公司提出的一种软件开发方法。
PAM方法希望能兼顾Yourdon方法、Jackson方法和自底向上的软件开发方法的优点，而避免它们的缺陷。
它的基本思想是：考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综合。
这一方法的具体步骤是：
从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系； 按先后关系逐步综合处理框，直到画出整个系统的PAD图。 从上述步骤中可以看出，这一方法本质上是综合的自底向上的方法，
但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构。
PAM方法的另一个优点是使用PAD图。
这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一，远远优于NS图和PDL语言。
这一方法在日本较为流行，软件开发的成功率也很高。
由于在输入、输出数据结构与整个系统之间同样存在着鸿沟，这一方法仍只适用于中小型问题。
面向对象的软件开发方法
面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。
随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，
最终形成面向对象的软件开发方法OMT(Object Modelling Technique）。
这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，
实际上也包含了所有对象的数据结构。所以OMT彻底实现了PAM没有完全实现的目标。
不仅如此，OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破，
彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。
自底向上的归纳
OMT的第一步是从问题的陈述入手，构造系统模型。
从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联。
类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。因此这是一种自底向上的归纳过程。
在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。
由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务。
这与自顶向下的Yourdon方法构成鲜明的对照。在Yourdon方法中构造系统模型是最困难的一步，
因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。
而在OTM中这一工作可由一般开发人员较快地完成。
在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。这三个模型一起构成要求解的系统模型。
自顶向下的分解
系统模型建立后的工作就是分解。与Yourdon方法按功能分解不同，在OMT中通常按服务（Service）来分解。
服务是具有共同目标的相关功能的集合，如I/O处理、图形处理等。
这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。
所以OMT也具有自顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了Yourdon方法中功能分解的困难和不确定性。
OMT的基础是对象模型
每个对象类由数据结构（属性）和操作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。
因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。
OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。
更重要的是，在Jackson方法和PAM方法中，当它们的出发点--输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。
但在OMT中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
需求分析彻底
需求分析不彻底是软件失败的主要原因之一。即使在目前，这一危险依然存在。
传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。
正是由于这一原因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。
在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的成功率。
但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。
OMT彻底解决了这一问题。因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。
开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，避免了传统需求分析中可能产生的种种问题。
可维护性大大改善
在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。
但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。
更严重的是，在这种软件系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错误。
所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维护性有了质的改善。
OMT的基础是目标系统的对象模型，而不是功能的分解。
功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。
由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。
在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。
利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，
对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。
由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。
OO技术还提高了软件的可靠性和健壮性。
可视化开发方法
可视化开发是90年代软件界最大的两个热点之一。
随着图形用户界面的兴起，用户界面在软件系统中所占的比例也越来越大，有的甚至高达60～70%。
产生这一问题的原因是图形界面元素的生成很不方便。
为此Windows提供了应用程序设计接口API（Application Programming Interface），
它包含了600多个函数，极大地方便了图形用户界面的开发。
但是在这批函数中，大量的函数参数和使用数量更多的有关常量，使基于WindowsAPI的开发变得相当困难。
为此Borland C++推出了Object Windows编程。
它将API的各部分用对象类进行封装，提供了大量预定义的类，并为这些定义了许多成员函数。
利用子类对父类的继承性，以及实例对类的函数的引用，应用程序的开发可以省却大量类的定义，
省却大量成员函数的定义或只需作少量修改以定义子类。
Object Windows还提供了许多标准的缺省处理，大大减少了应用程序开发的工作量。
但要掌握它们，对非专业人员来说仍是一个沉重的负担。
为此人们利用Windows API或Borland C++的ObjectWindows开发了一批可视开发工具。
可视化开发就是在可视开发工具提供的图形用户界面上，通过操作界面元素，
诸如菜单、按钮、对话框、编辑框、单选框、复选框、列表框和滚动条等，由可视开发工具自动生成应用软件。
这类应用软件的工作方式是事件驱动。
对每一事件，由系统产生相应的消息，再传递给相应的消息响应函数。
这些消息响应函数是由可视开发工具在生成软件时自动装入的。
可视开发工具应提供的两大类服务
一:生成图形用户界面及相关的消息响应函数。
通常的方法是先生成基本窗口，并在它的外面以图标形式列出所有其它的界面元素，让开发人员挑选后放入窗口指定位置。
在逐一安排界面元素的同时，还可以用鼠标拖动，以使窗口的布局更趋合理。
二:为各种具体的子应用的各个常规执行步骤提供规范窗口，它包括对话框、菜单、列表框、组合框、按钮和编辑框等，以供用户挑选。
开发工具还应为所有的选择（事件）提供消息响应函数。
由于要生成与各种应用相关的消息响应函数，因此，可视化开发只能用于相当成熟的应用领域，
如目前流行的可视化开发工具基本上用于关系数据库的开发。
对一般的应用，目前的可视化开发工具只能提供用户界面的可视化开发。
至于消息响应函数（或称脚本），则仍需用通常的高级语言（3GL）编写。
只有在数据库领域才提供4GL，使消息响应函数的开发大大简化。
从原理上讲，与图形有关的所有应用都可采用可视化开发方式，如活塞表面设计中的热应力计算。
用户只需在界面上用鼠标修改活塞表面的曲线，应用软件就自动进行有限元划分、温度场计算、热应力计算，
并将热应力的等值曲线图显示在屏幕上。
最后几次生成的结果还可并列
显示在各窗口上，供用户比较，其中的一个主窗口还可让用户进一步修改活塞表面曲线。
许多工程科学计算都与图形有关，从而都可以开发相应的可视化计算的应用软件。
ICASE
提高人类的劳动生产率，提高生产的自动化程度，一直是人类坚持不懈的追求目标。软件开发也不例外。
早在1982年美国国防部就提出了STARS工程，希望建立一个"用以支持需求定义、程序生成以及软件维护等软件生存期全部活动的，并把它们集成在一起的整个体系"。
但早期的软件开发环境工具较少，且不配套，支持需求分析等高层次生存期阶段的工具更少，
因此要求支持某类软件开发方法的全过程已很不容易了。
如Your-don公司的Cradle软件开发环境支持Yourdon结构化开发方法，Jackson工具集支持Jackson开发方法。
随着软件开发工具的积累，自动化工具的增多，软件开发环境进入了第三代ICASE（Integrated Computer-Aided Software Engineering）。
系统集成方式经历了从数据交换（早期CA SE采用的集成方式:点到点的数据转换），
到公共用户界面（第二代CASE:在一致的界面下调用众多不同的工具），再到目前的信息中心库方式。这是ICASE的主要集成方式。
它不仅提供数据集成（1991年IEEE为工具互连提出了标准P1175）和控制集成（实现工具间的调用），
还提供了一组用户界面管理设施和一大批工具，
如垂直工具集（支持软件生存期各阶段，保证生成信息的完备性和一致性）、水平工具集（用于不同的软件开发方法）以及开放工具槽。
ICASE的进一步发展则是与其它软件开发方法的结合，如与面向对象技术、软件重用技术结合，以及智能化的I-CASE。
近几年已出现了能实现全自动软件开发的ICASE。
ICASE的最终目标是实现应用软件的全自动开发，即开发人员只要写好软件的需求规格说明书，
软件开发环境就自动完成从需求分析开始的所有的软件开发工作，自动生成供用户直接使用的软件及有关文档。
在应用最成熟的数据库领域，目前已有能实现全部自动生成的应用软件，如MSE公司的Magic系统。
它只要求软件开发人员填写一系列表格（相当于要求软件实现的各种功能），系统就会自动生成应用软件。
它不仅能节省90%以上的软件开发和维护的工作量，而且还能将应用软件的开发工作转交给熟练的用户。
软件重用和组件连接
软件重用（Reuse）又称软件复用或软件再用。早在1968年的NATO软件工程会议上就已提出可复用库的思想。
1983年，Freeman对软件重用给出了详细的定义:"在构造新的软件系统的过程中，对已存在的软件人工制品的使用技术。"软件人工制品可以是源代码片断、子系统的设计结构、模块的详细设计、文档和某一方面的规范说明等。
所以软件重用是利用已有的软件成份来构造新的软件。
它可以大大减少软件开发所需的费用和时间，且有利于提高软件的可维护性和可靠性。
目前软件重用沿着下面三个方向发展:
基于软件复用库的软件重用
它是一种传统的软件重用技术。这类软件开发方法要求提供软件可重用成份的模式分类和检索，
且要解决如何有效地组织、标识、描述和引用这些软件成份。
通常采用两种方式进行软件重用:
（1）生成技术 这是对模式的重用。由软件生成器通过替换特定参数，生成抽象软件成份的具体实例。
（2）组装方式
常用的组装方式有:子程序库技术、共享接口设计和嵌套函数调用等。
组装方式对软件重用成份通常不作修改，或仅作很少的修改。
与面向对象技术结合OO技术中类的聚集、实例对类的成员函数或操作的引用、子类对父类的继承等使软件的可重用性有了较大的提高。
而且这种类型的重用容易实现。所以这种方式的软件重用发展较快。
组件连接
这是目前发展最快的软件重用方式。
最早的组件连接技术OLE 1.0（Object Linking an d Embedding）是Microsoft公司于1990年11月在COMDEX展览会上推出的。
OLE 1.0的规范发表于1990年12月，1991年2月推出了第一批支持OLE 1.0规范的应用程序。
1993年5月发表了OLE 2.0。几个月后，第一批支持OLE 2.0的应用程序问世。
OLE给出了软件组件（Component Object）的接口标准。
这样任何人都可以按此标准独立地开发组件和增值组件（组件上添加一些功能构成新的组件），或由若干组件组建集成软件。
在这种软件开发方法中，应用系统的开发人员可以把主要精力放在应用系统本身的研究上，因为他们可在组件市场上购买所需的大部分组件。
软件组件市场/组件集成方式是一种社会化的软件开发方式，
因此也是软件开发方式上的一次革命，必将极大地提高软件开发的劳动生产率，而且应用软件开发周期将大大缩短，
软件质量将更好，所需开发费用会进一步降低，软件维护也更容易。
软件组件连接的另一个标准是1995年3月推出的OpenDoc。这是IBM、Apple等公司组成的 CI Labs集团使用的标准。
由于OpenDoc的编程接口比OLE小，因此OpenDoc的应用程序能与OL E兼容。
第三个组件连接标准是对象管理集团OMG于1991年发表的CORBA（Common Object Reques t Broker Architecture），
1994年OMG又发表了CORBA 2.0。
由于OLE 1.0、OLE 2.0的部分功能已放入Windows 3.1（在推出OLE 2.0的同时，推出Win dows 3.1的OLE 2.0），因此目前使用的组件连接开发技术大多基于OLE 2.0。
综上所述，今后的软件开发将是以OO技术为基础（指用它开发系统软件和软件开发环境） ，可视化开发、ICASE和软件组件连接三种方式并驾齐驱。它们四个将一起形成软件界新一轮的热点技术。
备注：随笔中内容来源于网上资料整理,仅供参考。