60年代中期開始爆發了眾所周知的軟件危機。為了克服這一危機，在1968、1969年連續召開的兩次著名的NATO會議上提出了軟件工程這一術語，并在以后不斷發展、完善。與此同時，軟件研究人員也在不斷探索新的軟件開發方法。至今已形成八類軟件開發方法。
一、Parnas方法
最早的軟件開發方法是由D. Parnas在1972年提出的。由于當時軟件在可維護性和可靠性方面存在著嚴重問題，因此Par-nas提出的方法是針對這兩個問題的。首先，Parnas提出了信息隱蔽原則:在概要設計時列出將來可能發生變化的因素，并在模塊劃分時將這些因素放到個別模塊的內部。這樣，在將來由于這些因素變化而需修改軟件時，只需修改這些個別的模塊，其它模塊不受影響。信息隱蔽技術不僅提高了軟件的可維護性，而且也避免了錯誤的蔓延，改善了軟件的可靠性。現在信息隱蔽原則已成為軟件工程學中的一條重要原則。
Parnas提出的第二條原則是在軟件設計時應對可能發生的種種意外故障采取措施。軟件是很脆弱的，很可能因為一個微小的錯誤而引發嚴重的事故，所以必須加強防范。如在分配使用設備前，應該取設備狀態字，檢查設備是否正常。此外，模塊之間也要加強檢查，防止錯誤蔓延。
Parnas對軟件開發提出了深刻的見解。遺憾的是，他沒有給出明確的工作流程。所以這一方法不能獨立使用，只能作為其它方法的補充。
二、Yourdon方法
1978年，E.Yourdon和L.L.Constan-tine提出了結構化方法，即SASD方法，也可稱為面向功能的軟件開發方法或面向數據流的軟件開發方法。1979年Tom DeMarco對此方法作了進一步的完善。
Yourdon方法是80年代使用最廣泛的軟件開發方法。它首先用結構化分析（SA）對軟件進行需求分析，然后用結構化設計（SD）方法進行總體設計，最后是結構化編程（SP）。這一方法不僅開發步驟明確，SA、SD、SP相輔相成，一氣呵成，而且給出了兩類典型的軟件結構（變換型和事務型），便于參照，使軟件開發的成功率大大提高，從而深受軟件開發人員的青睞。
三、面向數據結構的軟件開發方法
1.Jackson方法
1975年，M.A.Jackson提出了一類至今仍廣泛使用的軟件開發方法。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用于模塊的詳細設計。
Jackson方法有時也稱為面向數據結構的軟件設計方法。
2.Warnier方法
1974年，J.D.Warnier提出的軟件開發方法與Jackson方法類似。差別有三點:一是它們使用的圖形工具不同，分別使用Warnier圖和Jackson圖;另一個差別是使用的偽碼不同;最主要的差別是在構造程序框架時，Warnier方法僅考慮輸入數據結構，而Jackson方法不僅考慮輸入數據結構，而且還考慮輸出數據結構。
四、問題分析法PAM
問題分析法PAM（Problem Analysis bbbbbb）是80年代末由日立公司提出的一種軟件開發方法。
PAM方法希望能兼顧Yourdon方法、Jackson方法和自底向上的軟件開發方法的優點，而避免它們的缺陷。它的基本思想是:考慮到輸入、輸出數據結構，指導系統的分解，在系統分析指導下逐步綜合。這一方法的具體步驟是:從輸入、輸出數據結構導出基本處理框;分析這些處理框之間的先后關系;按先后關系逐步綜合處理框，直到畫出整個系統的PAD圖。從上述步驟中可以看出，這一方法本質上是綜合的自底向上的方法，但在逐步綜合之前已進行了有目的的分解，這個目的就是充分考慮系統的輸入、輸出數據結構。
PAM方法的另一個優點是使用PAD圖。這是一種二維樹形結構圖，是到目前為止最好的詳細設計表示方法之一，遠遠優于N-S圖和PDL語言。
這一方法在日本較為流行，軟件開發的成功率也很高。由于在輸入、輸出數據結構與整個系統之間同樣存在著鴻溝，這一方法仍只適用于中小型問題。
五、面向對象的軟件開發方法
面向對象技術是軟件技術的一次革命，在軟件開發史上具有里程碑的意義。
隨著OOP（面向對象編程）向OOD（面向對象設計）和OOA（面向對象分析）的發展，最終形成面向對象的軟件開發方法OMT（bbbbbb Modelling Technique）。這是一種自底向上和自頂向下相結合的方法，而且它以對象建模為基礎，從而不僅考慮了輸入、輸出數據結構，實際上也包含了所有對象的數據結構。所以OMT徹底實現了PAM沒有完全實現的目標。不僅如此，OO技術在需求分析、可維護性和可靠性這三個軟件開發的關鍵環節和質量指標上有了實質性的突破 ，徹底地解決了在這些方面存在的嚴重問題，從而宣告了軟件危機末日的來臨。
1.自底向上的歸納
OMT的第一步是從問題的陳述入手，構造系統模型。從真實系統導出類的體系，即對象模型包括類的屬性，與子類、父類的繼承關系，以及類之間的關聯。類是具有相似屬性和行為的一組具體實例（客觀對象）的抽象，父類是若干子類的歸納。因此這是一種自底向上的歸納過程。在自底向上的歸納過程中，為使子類能更合理地繼承父類的屬性和行為，可能需要自頂向下的修改，從而使整個類體系更加合理。由于這種類體系的構造是從具體到抽象，再從抽象到具體，符合人類的思維規律，因此能更快、更方便地完成任務。這與自頂向下的Yourdon方法構成鮮明的對照。在Yourdon方法中構造系統模型是最困難的一步，因為自頂向下的"頂"是一個空中樓閣，缺乏堅實的基礎，而且功能分解有相當大的任意性，因此需要開發人員有豐富的軟件開發經驗。而在OMT中這一工作可由一般開發人員較快地完成。在對象模型建立后，很容易在這一基礎上再導出動態模型和功能模型。這三個模型一起構成要求解的系統模型。
2.自頂向下的分解
系統模型建立后的工作就是分解。與Yourdon方法按功能分解不同，在OMT中通常按服務 （Service）來分解。服務是具有共同目標的相關功能的集合，如I/O處理、圖形處理等。這一步的分解通常很明確，而這些子系統的進一步分解因有較具體的系統模型為依據，也相對容易。所以OMT也具有自頂向下方法的優點，即能有效地控制模塊的復雜性，同時避免了Yourdon方法中功能分解的困難和不確定性。
3.OMT的基礎是對象模型
每個對象類由數據結構（屬性）和操作（行為）組成，有關的所有數據結構（包括輸入、輸出數據結構）都成了軟件開發的依據。因此Jackson方法和PAM中輸入、輸出數據結構與整個系統之間的鴻溝在OMT中不再存在。OMT不僅具有Jackson方法和PAM的優點，而且可以應用于大型系統。更重要的是，在Jackson方法和PAM方法中，當它們的出發點———輸入、輸出數據結構（即系統的邊界）發生變化時，整個軟件必須推倒重來。但在OMT中系統邊界的改變只是增加或減少一些對象而已，整個系統改動極小。
4.需求分析徹底
需求分析不徹底是軟件失敗的主要原因之一。即使在目前，這一危險依然存在。傳統的軟件開發方法不允許在開發過程中用戶的需求發生變化，從而導致種種問題。正是由于這一原因，人們提出了原型化方法，推出探索原型、實驗原型和進化原型，積極鼓勵用戶改進需求。在每次改進需求后又形成新的進化原型供用戶試用，直到用戶基本滿意，大大提高了軟件的成功率。但是它要求軟件開發人員能迅速生成這些原型，這就要求有自動生成代碼的工具的支持。
OMT徹底解決了這一問題。因為需求分析過程已與系統模型的形成過程一致，開發人員與用戶的討論是從用戶熟悉的具體實例（實體）開始的。開發人員必須搞清現實系統才能導出系統模型，這就使用戶與開發人員之間有了共同的語言，避免了傳統需求分析中可能產生的種種問題。
5.可維護性大大改善
在OMT之前的軟件開發方法都是基于功能分解的。盡管軟件工程學在可維護方面作出了極大的努力，使軟件的可維護性有較大的改進。但從本質上講，基于功能分解的軟件是不易維護的。因為功能一旦有變化都會使開發的軟件系統產生較大的變化，甚至推倒重來。更嚴重的是，在這種軟件系統中，修改是困難的。由于種種原因，即使是微小的修改也可能引入新的錯誤。所以傳統開發方法很可能會引起軟件成本增長失控、軟件質量得不到保證等一系列嚴重問題。正是OMT才使軟件的可維護性有了質的改善。
OMT的基礎是目標系統的對象模型，而不是功能的分解。功能是對象的使用，它依賴于應用的細節，并在開發過程中不斷變化。由于對象是客觀存在的，因此當需求變化時對象的性質要比對象的使用更為穩定，從而使建立在對象結構上的軟件系統也更為穩定。 [NextPage]
更重要的是OMT徹底解決了軟件的可維護性。在OO語言中，子類不僅可以繼承父類的屬性和行為，而且也可以重載父類的某個行為（虛函數）。利用這一特點，我們可以方便地進行功能修改:引入某類的一個子類，對要修改的一些行為（即虛函數或虛方法）進行重載，也就是對它們重新定義。由于不再在原來的程序模塊中引入修改，所以徹底解決了軟件的可修改性，從而也徹底解決了軟件的可維護性。OO技術還提高了軟件的可靠性和健壯性。
六、可視化開發方法
可視化開發是90年代軟件界最大的兩個熱點之一。隨著圖形用戶界面的興起，用戶界面在軟件系統中所占的比例也越來越大，有的甚至高達60～70%。產生這一問題的原因是圖形界面元素的生成很不方便。為此bbbbbbs提供了應用程序設計接口API（Application Programm ing Inter-face），它包含了600多個函數，極大地方便了圖形用戶界面的開發。但是在這批函數中，大量的函數參數和使用數量更多的有關常量，使基于bbbbbbs API的開發變得相當困難。為此Borland C++推出了bbbbbb bbbbbbs編程。它將API的各部分用對象類進行封裝，提供了大量預定義的類，并為這些定義了許多成員函數。利用子類對父類的繼承性，以及實例對類的函數的引用，應用程序的開發可以省卻大量類的定義，省卻大量成員函數的定義或只需作少量修改以定義子類。bbbbbb Win-dows還提供了許多標準的缺省處理，大大減少了應用程序開發的工作量。但要掌握它們，對非專業人員來說仍是一個沉重的負擔。為此人們利用bbbbbb s API或Borland C++的bbbbbb bbbbbbs開發了一批可視開發工具。
可視化開發就是在可視開發工具提供的圖形用戶界面上，通過操作界面元素，諸如菜單、按鈕、對話框、編輯框、單選框、復選框、列表框和滾動條等，由可視開發工具自動生成應用軟件。
這類應用軟件的工作方式是事件驅動。對每一事件，由系統產生相應的消息，再傳遞給相應的消息響應函數。這些消息響應函數是由可視開發工具在生成軟件時自動裝入的。
可視開發工具應提供兩大類服務。一類是生成圖形用戶界面及相關的消息響應函數。通常的方法是先生成基本窗口，并在它的外面以圖標形式列出所有其它的界面元素，讓開發人員挑選后放入窗口指定位置。在逐一安排界面元素的同時，還可以用鼠標拖動，以使窗口的布局更趨合理。
另一類服務是為各種具體的子應用的各個常規執行步驟提供規范窗口，它包括對話框、菜單、列表框、組合框、按鈕和編輯框等，以供用戶挑選。開發工具還應為所有的選擇（事件）提供消息響應函數。
由于要生成與各種應用相關的消息響應函數，因此，可視化開發只能用于相當成熟的應用領域，如目前流行的可視化開發工具基本上用于關系數據庫的開發。對一般的應用，目前的可視化開發工具只能提供用戶界面的可視化開發。至于消息響應函數（或稱腳本），則仍需用通常的高級語言（3GL）編寫。只有在數據庫領域才提供4GL，使消息響應函數的開發大大簡化。
從原理上講，與圖形有關的所有應用都可采用可視化開發方式，如活塞表面設計中的熱應力計算。用戶只需在界面上用鼠標修改活塞表面的曲線，應用軟件就自動進行有限元劃分、溫度場計算、熱應力計算，并將熱應力的等值曲線圖顯示在屏幕上。最后幾次生成的結果還可并列顯示在各窗口上，供用戶比較，其中的一個主窗口還可讓用戶進一步修改活塞表面曲線。
許多工程科學計算都與圖形有關，從而都可以開發相應的可視化計算的應用軟件。
可視化開發是軟件開發方式上的一場革命，它使軟件開發從專業人員的手中解放出來，對緩解80年代中后期爆發的應用軟件危機有重大作用。
七、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.基于軟件復用庫的軟件重用
它是一種傳統的軟件重用技術。這類軟件開發方法要求提供軟件可重用成份的模式分類和檢索，且要解決如何有效地組織、標識、描述和引用這些軟件成份。通常采用兩種方式進行軟件重用:
（1）生成技術 這是對模式的重用。由軟件生成器通過替換特定參數，生成抽象軟件成份的具體實例。
（2）組裝方式 常用的組裝方式有:子程序庫技術、共享接口設計和嵌套函數調用等。組裝方式對軟件重用成份通常不作修改，或僅作很少的修改。
2.與面向對象技術結合
OO技術中類的聚集、實例對類的成員函數或操作的引用、子類對父類的繼承等使軟件的可重用性有了較大的提高。而且這種類型的重用容易實現。所以這種方式的軟件重用發展較快。
3.組件連接
這是目前發展最快的軟件重用方式。最早的組件連接技術OLE 1.0（bbbbbb bbbbing an d bbbbbding）是Microsoft公司于1990年11月在COMDEX展覽會上推出的。OLE 1.0的規范發表于1990年12月，1991年2月推出了第一批支持OLE 1.0規范的應用程序。1993年5月發表了OLE 2.0。幾個月后，第一批支持OLE 2.0的應用程序問世。
OLE給出了軟件組件（Component bbbbbb）的接口標準。這樣任何人都可以按此標準獨立地開發組件和增值組件（組件上添加一些功能構成新的組件），或由若干組件組建集成軟件。在這種軟件開發方法中，應用系統的開發人員可以把主要精力放在應用系統本身的研究上，因為他們可在組件市場上購買所需的大部分組件。
軟件組件市場/組件集成方式是一種社會化的軟件開發方式，因此也是軟件開發方式上的一次革命，必將極大地提高軟件開發的勞動生產率，而且應用軟件開發周期將大大縮短，軟件質量將更好，所需開發費用會進一步降低，軟件維護也更容易。
軟件組件連接的另一個標準是1995年3月推出的OpenDoc。這是IBM、Apple等公司組成的 CI Labs集團使用的標準。由于OpenDoc的編程接口比OLE小，因此OpenDoc的應用程序能與OL E兼容。
第三個組件連接標準是對象管理集團OMG于1991年發表的CORBA（Common bbbbbb Reques t Broker Architecture），1994年OMG又發表了CORBA 2.0。
由于OLE 1.0、OLE 2.0的部分功能已放入bbbbbbs 3.1（在推出OLE 2.0的同時，推出Win dows 3.1的OLE 2.0），因此目前使用的組件連接開發技術大多基于OLE 2.0。
綜上所述，今后的軟件開發將是以OO技術為基礎（指用它開發系統軟件和軟件開發環境） ，可視化開發、ICASE和軟件組件連接三種方式并駕齊驅。它們四個將一起形成軟件界新一輪的熱點技術。
：鞏經理
：13915946763
：南京塞姆泵業有限公司
