�。ǘ� 軟件開發模型
為了指導軟件的開發，用不同的方式將軟件生存周期中的所有開發活動組織起來，形成不同的軟件開發模型。常見的軟件開發模型有瀑布模型、演化模型、螺旋模型、噴泉模型等。瀑布模型如下圖所示，它是1970年由W.Royce提出的。該模型給出了軟件生存周期各階段的固定順序，上一階段完成后才能進入到下一階段，整個過程就像流水下瀉，故稱之為瀑布模型。圖中的虛線部分表示在某一階段發現錯誤時，其錯誤可能是由上一階段造成的，因此開發過程可能要反饋到上一階段。在瀑布模型中，各階段結束后，都要進行嚴格的評審。
�。ㄈ� 軟件開發方法
軟件開發過程模型規定軟件開發活動的組合應用方式，要保證開發活動的高質量，還需要有相應的軟件開發方法作為技術支持。近10年來，軟件工作者研制出了許多工程化的軟件開發方法，例如70年代初提出的用于編寫程序的結構化程序設計方法，確實起到了提高效率，減少錯誤的效果。但是70年代中期，軟件工作者認識到編寫程序僅僅是軟件開發的一個環節，而合理地建立系統結構比編定程序更為重要。所以研究的重點前移到設計階段，出現了設計階段的結構化設計（SD）方法和JACKSON等方法，到了70年代后期，人們又發現事先對用戶的要求進行分析更為重要，故又把重點前移到分析階段。出現了用于分析階段的結構化分析（SA）方法、結構化分析與設計技術（SADT）等。隨著計算機技術的迅速發展，在80年代初期的實時、并發和網絡等軟件的開發過程中，特別是在第五代計算機研究工作中，又提出了面向對象的設計方法。現在流行的方法有多種，它們的適用范圍也各不相同。有的適用于一般的數據處理系統，如SA、SD（兩者統稱為結構化分析與設計方法，即Yourdon方法）、JACKSON方法;有的適用于大型的復雜系統，如SADT技術;有的適用于實時事務處理系統，如FSM方法;有的適用于并發軟件系統，如PETRI網方法;作為90年代代表作的面向對象方法，其應用已幾乎遍布各個領域。這些方法除了適用范圍不同外，方法形成的基礎、處理規則和對所開發軟件風格的要求等都各有側重。用什么方法來說明用戶的要求、用什么方法來設計軟件以及用什么方法對軟件進行測試和維護，直接影響所開發軟件的質量。
�。ㄋ模� 軟件開發工具
早期的軟件開發除了一般的程序設計語言外尚缺少工具的支持，致使編程工作量大，質量和進度卻難以保證，導致人們將很多的精力和時間花費在程序的編制和調試上;相比之下，在更重要的軟件的需求和設計上反而得不到必要的精力和時間投入。軟件開發工具的發展促進了軟件開發的高速度和高質量。工具的發展是從單項工具的開發逐步走向集成的工具發展的。同時，軟件開發方法的有效應用也必須得到相應工具的支持，否則方法將難以有效的實施。工具的完善和發展將促進軟件開發的進步和完善。原型化方法的實施基礎就是得到了開發工具的支持�？焖僭突阅軌驅崿F的基礎就是原型化人員在快速建模時得到了工具的支持，否則原型化方法是無法實施的。
�。ㄎ澹� 軟件開發環境
軟件工程環境或稱軟件開發環境是全面支持軟件開發全過程的軟件工具集合。這些軟件工具按照一定的方法或模式組合起來，并能支持軟件開發生命周期的各個階段和各項任務的完成。CASE，即計算機輔助軟件工程環境是當前軟件開發環境中富于特色的研究工作和發展方向，它的成功將最大限度地降低軟件工程的技術難度并使軟件開發的質量得到保證。
二、結構化生命周期方法
結構化分析與設計方法在軟件工程中應用已很普遍，并且越來越成熟。有許多大、中型項目都采用了這種方法進行開發并取得了顯著的成果。按B.W.Boehm的描述，瀑布模型的的軟件生命周期可劃分七個階段:系統需求分析、軟件需求分析、概要分析、詳細設計、編碼、測試和運行維護。
�。ㄒ唬� 系統需求
“系統需求”包括:問題定義、可行性研究及軟件計劃。
1.問題定義
軟件開發的第一步就是進行問題定義。問題定義階段必須回答的關鍵問題:“軟件要解決的問題是什么?”如果不知道問題是什么就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最常被忽視的一個步驟。這里所說的問題，就是指用戶的基本要求。說得通俗些，問題定義實際上就是了解用戶到底要建立什么系統，并確定分析員下一步應該做什么。因此，問題定義的來源是用戶。通過問題定義階段的工作，系統分析員應該提出關于問題性質、工程目標和規模的書面報告。這一階段的分析員應盡可能站在較高的角度去抽象、概括所要干的事情，不要拘泥于問題實現的細節。盡管用戶可能總是習慣于這樣做，但分析員在這一階段必須超脫出來，居高臨下鳥瞰系統的全貌。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，并在使用部門負責人的會議上認真討論這份書面報告，澄清含糊不清的地方，改正理解不正確的地方，最后得出一份雙方都滿意的文檔。當用戶的要求不是很多并且不太復雜時，一兩個分析員用上一兩天就可以完成這一工作了。但當系統比較大，且復雜時，恐怕就要組織一個問題定義小組，花上一兩個星期，甚至數月來定義用戶的問題。如果分析員和用戶及使用部門的負責人對所要解決的問題取得完全一致的看法，而且使用部門的負責人同意開發工程繼續進行下去，那么開發工程將轉入生命周期的下一個階段———可行性研究。
2.可行性研究
并不是所有問題都有簡單明顯的解決辦法，事實上，許多問題不能在預定的系統規模之內解決。如果問題沒有可行的解，那么花費在這項開發工程上的任何時間、資源、人力和經費和都是無謂的浪費�？尚行匝芯康哪康脑谟谟米钚〉拇鷥r確定在問題定義階段所確定的系統的目標和規模是否現實，所確定的問題是否可以解決，系統方案在經濟上、技術上和操作上是否可以接受�？尚行匝芯恐貙θ缦戮唧w方案考慮:
（1）經濟可行性。估計開發費用以及新系統可能帶來的收益，將兩者進行權衡，看結果是否可以接受。
�。�2）技術可行性。對要求的功能、性能以及限制條件進行分析，是否能夠做成一個可接受的系統。所考慮的因素通常還應包括開發的風險，是否能夠得到需要的軟件和硬件資源和一個熟練的有能力的開發隊伍，與系統開發有關的技術是否足以支持系統的研制。技術可行性的估計，需要有經驗的人員去完成。
�。�3）操作可行性。判斷系統的操作方式在該用戶組織內是否可行。分析、設計人員應以新系統的目標和作用范圍為依據提出一種以上的設計方案，從技術可行性、經濟可行性、操作可行性等方面進行比較，并選擇出綜合最優的方案。根據可行性研究結果要做出的決定是:是否繼續按預定目標進行這項開發工程，可行性分析人員必須清楚地表明他對這個關鍵性決定的建議。如果認為值得繼續進行這項開發工程，則應提供選擇一種最好的解法并說明理由。可行性分析是在問題的目標和約束之間的一種權衡，還可能有的結果則是修改目標或放寬約束。
3.軟件計劃
分析人員應該為推薦的系統草擬一份軟件計劃，其中描述的是為了成功地進行一個軟件項目，其所需要做的工作、需要的資源、需要的工作量和費用以及應遵循的進度安排。軟件計劃由兩項任務組成:分析和估算。分析是對系統內各軟件功能的界限的劃定。估算是指根據已有的定性數據和已往的經驗對系統開發的資源、費用和進度進行定量的估計。軟件開發項目的進度安排可以從兩種觀點來考慮:一是項目的交付日期已定，負責開發工作的軟件機構被限制在一個規定的時間范圍內分配其工作量。二是項目最后的交付日期由軟件機構自已確定，可以從最佳的利用各種資源的角度出發來分配工作量，項目最后的交付日期經過對軟件各部分仔細分析后才確定。在多數項目中，遇到的往往是第一種情況。軟件計劃的閱讀者可以包括軟件主管部門、用戶和技術人員。所確定的成本與進度可供主管部門復審。它同時也給出了整個軟件生命周期的基本成本預算的進度安排。
�。ǘ� 軟件需求分析
軟件需求分析工作是軟件生存期中重要的一步，也是決定性的一步。只有通過軟件需求分析，才能把軟件功能和性能的總體概念描述為具體的軟件需求規格說明，從而奠定軟件開發的基礎。軟件需求分析工作也是一個不斷認識和逐步細化的過程。該過程將軟件設計階段所確定的軟件范圍（工作域）逐步細化到可詳細定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決方法。制定軟件的需求規格說明不只是軟件開發人員的事，用戶也起著至關重要的作用。用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而軟件分析人員則要認真了解用戶的要求，細致地進行調查分析，把用戶“做什么”的要求最終轉換成一個完全的、精細的軟件邏輯模型并寫出軟件的需求規格說明，準確地表達用戶的要求。
1.軟件需求分析任務
需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節。定義軟件的其他有效性需求。分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數據域，并給軟件開發提供一種可轉化為數據設計、結構設計和過程設計的數據與功能表示。在軟件完成后，制定的軟件需求規格說明還要為評價軟件質量提供依據。需求分析階段研究的對象是軟件項目的用戶要求。需要注意的是，必須理解用戶的各項要求，但又不能全盤接受所有的要求。因為并非所有用戶要求都是合理的。對其中模糊的要求還需要澄清，然后才能決定是否可以采納。對于那些無法實現的要求應向用戶做充分的解釋，以求得諒解。準確地表達所接受的用戶要求，是需求分析的另一個重要方面。只有經過確切描述的軟件需求才能成為軟件設計基礎。通常軟件開發項目是要實現目標系統的物理模型，即確定待開發軟件系統的系統元素，并將功能和數據結構分配到這些系統元素中。它是軟件實現的基礎。但是目標系統的具體物理模型是由它的邏輯模型經實例化，即具體到某個業務領域而得到的。與物理模型不同，邏輯模型忽視實現機制與細節，只描述系統要完成的功能和要處理的數據。作為目標系統的參考，需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的“做什么”的問題。
�。�1）獲得當前系統的物理模型。當前系統可能是需要改進的某個已在計算機運行的數據處理系統，也可能是一個人工的數據處理過程。在這一步首先分析、理解當前系統是如何運行的，了解當前系統的組織機構、輸入輸出、資源利用情況和日常數據處理過程，并用一個具體模型來反映自己對當前系統的理解。這一模型應客觀地反映現實世界的實際情況。
�。�2）抽象出當前系統的邏輯模型。在理解當前系統“怎樣做”的基礎上，抽取其“做什么”的本質，從而從當前系統的物理模型抽象出當前系統的邏輯模型。在物理模型中有許多物理因素，隨著分析工作的深入，有些非本質的物理因素就成為不必要的負擔，因而需要對物理模型進行分析，區分出本質的和非本質的因素，去掉那些非本質的因素即可獲得反映系統本質的邏輯模型。
�。�3）建立目標系統的邏輯模型。分析目標系統與當前系統邏輯上的差別，明確目標系統統到底要“做什么”，從當前系統的邏輯模型導出目標系統的邏輯模型。（4）為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充。①說明目標系統的用戶界面。根據目標系統所處的應用環境及它與外界環境的相互關系，研究所有可能與它發生聯系和作用的部分，從而決定人機界面。②說明至今尚未詳細考慮的細節。這些細節包括系統的啟動和結束、出錯處理、系統的輸入輸出和系統性能方面的需求。③其他。例如系統的其他必須滿足的性能和限制等等。
希望與更多計算機等級考試的網友交流，請進入計算機等級考試論壇
更多信息請訪問：考試吧計算機等級考試欄目
